AIR 1.5 encrypted SQLite database — how to use it, best practices, and new projects

Posted November 18, 2008 1:30 am
Filed under: AIR, Articles by Paul, Life at Adobe, Projects, Tutorials, Writing, local SQL database

Over a year ago I described a potential area of concern for using a SQLite database with an AIR application — because all apps use the same database engine, any AIR app can read any other app’s database (as long as it can find the database file).

As you may have heard among all the news that’s coming out from MAX right now, Adobe AIR 1.5 has just been released. Most of the features of AIR 1.5 are features that were introduced with Flash Player 10. However, one new feature in AIR 1.5 that helps address the easy-to-read database issue is AIR 1.5’s new support for AES encrypted databases.

I’ve had the interesting and at times complex job of writing the documentation for this new feature. The bulk of the new documentation is in a new section “Using encryption with SQL databases” in the SQL database chapter of the manual “Developing Adobe AIR Applications”.

It’s pretty straightforward to use an encrypted database. You have to create the database as an encrypted db. To create or open it, you call the SQLConnection class’s open() or openAsync() methods, just as you normally do, and there’s a new parameter where you provide a 16-byte ByteArray encryption key for the database. That’s all there is to it.

The SQLConnection class also has a new reencrypt() method, that you use to change the encryption key of an already encrypted database.

If you want to see some code examples, check out the documentation listed above, or see these quick start articles on the Adobe developer center:

There are a couple of parts of the new documentation that I think are particularly interesting (although I’m obviously biased since I wrote it all):

Now that AIR 1.5 is out the door, I’ve updated my AIR database admin tool to support encrypted databases (when you try to open an encrypted database it prompts you for an encryption key, which you enter as a Base-64 string). I already mentioned that I wrote the encryption key generator class that’s now in as3corelib. I’ve also got at least one more new encrypted database-related open-source project that I’m about to release…but I’ll wait until the MAX “firehose” dies down a bit before I write more about that one. =)

You can leave a comment, or trackback from your own site.

5 Comments so far

  1. November 24th, 2008 at 3:33 am
    davidderaedt is reported to have said:

    Hi Paul,

    Did you mean that your encryption class will be included in future releases of the core lib? Because, as far as I know, build .92.1 (latest build to date) does not include it.

  2. November 24th, 2008 at 10:00 am
    Paul Robertson is reported to have said:

    Hi David,
    Sorry about the confusion. You’re right that the current download .zip (.92.1) doesn’t include the encryption key generator class. The .zip hasn’t been updated yet with the newest changes. (All the project owners were at MAX last week when I posted the new content.)

    I’ll ping them to see if any of them can rebuild the .zip file. In the mean time, the class is available in the source, if you browse on the project web site or check it out via SVN.

    Paul

  3. December 3rd, 2008 at 2:18 pm
    JJ is reported to have said:

    Really good info, Paul. It gave me a good background for something that we need in an application we’re currently writing.

    I’m wondering if you can comment on a slightly different need that we have. We’re using the encrypted capabilities of AIR/SQLite to hold proprietary data from our server for offline use by our customers. That’s one of the huge advantages to AIR/encrypted SQLite - we can now give the user the option of running online and connected to our server, or offline (with our data on their desktop - allowing for synchonization issues, etc).

    Anyway, the encryption key that we need to use can’t be based on a user’s password because we only want them having access to the database through our AIR application - even if the key is further encrypted. What would stop someone from decompiling the SWF to uncover the mechanism or our own stored password? How can we protect our data that is local in the database?

    If I didn’t describe this well, please let me know and I’ll come up with another example of the problem.

  4. December 4th, 2008 at 6:21 am
    JJ is reported to have said:

    After doing a lot of research about this issue and sleeping on it, I’m coming to the conclusion that it is almost impossible to completely hide a password (even with the encrypted file store class). Decompiling seems to be always able to unravel the code and figure out the encoding. There is that very strong mode of file store encryption that is tied to the application that created it, but then you can’t update your AIR app because the decryption will fail.

    Am I missing something? Is the only way around all of this to encrypt the SWF with one of the commercial encrypters? Even those can be gotten around but I can make that pretty difficult to uncover.

    Are there any other ideas for really protecting the assets in a database?

  5. December 11th, 2008 at 7:06 am
    Ashish Mahajan is reported to have said:

    I have two issues I am still facing
    (A) What tool will I be able to manage structure and content of a encrypted database?
    (B) I am getting error from openSync method of SQLConnection that it only supports five arguments?

Add your comment





Comment notes

Please keep comments on topic. Comments that are inappropriate or offensive will be edited or removed.

Paragraphs and line breaks are automatically converted to HTML, and quotation marks are converted to “smart” quotes.

The following XHTML tags can be used: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> . All others will be removed.

Articles by Type

Articles by Topic

Random Reading

Currently...

Subscribe