Article by Steven.
Published: March 26, 2009 at 12:14
Category: AIR, ActionScript 3

Using the local encrypted database in AIR: theory and practise

< back to overview

I’ve just finished a rather technical AIR project in which I encountered some major and minor issues regarding the use of AIR technology and I thought I would share them with you all, hoping I can provide some solutions to problem you may encounter when you create your own AIR projects.

One of the key features for this particular project is the fact that it had to have a high level of security because of privacy legislation and confidentiality. So naturally, using an encrypted local database came to mind. Using the online help and the Adobe AIR 1.5 Cookbook (which by the way has some very good recipes by Koen De Weggheleire and Marco Cassario that helped me a lot. Thanks guys!) it didn’t take me long to set things up in their basic form. So, quickly I found myself having a working encrypted local SQLite database. But that is where some nasty problems came into view.

Because of the high level of security and the fact that data from different users are going to be synchronised on a remote centralised server, the data had to be encrypted with a personalised key, so no data from the user can accidentally be read by another user. And what better personalised key to use than the user password. But this brought along some complications, because of course the user can forget his password or just change it. For changing the password, the solution was very easy, because you have both the current password and the new one, so you log on to the database with the old password and just re-encrypt it with the new one. Then you update the remote user object to make sure the new password is set there for when the user logs in the next time Case closed. Or so you would think.

However, there is also the possibility that the user has installed the application on a second machine, so he or she could also change his or her password on another computer. When the user logs in on the first computer and there is no network connection available, he or she will still have to type the old password, because the database on the computer is still encrypted with the old password. When there is a network connection available, the user can log in with the new password, since again the login is validated on the remote server, but the local database is still encrypted with the old password. So this would be a problem, because the database cannot be accessed now.

To solve this problem, I made use of the EncryptedLocalStore feature of AIR. Here I always save the current password. Since it’s a bunch of encrypted files that contain the data that reside in the user directory, security on this is tight enough. Now, saving the current password may seem odd, since I would require the previous password in case the user changed the password on another computer. However, when you think it through, at the time we are going to need it, the current password that has been saved has actually become the previous one. So now I try to open the database with the new password and the encryption has changed, I try a second time with the password that has been saved in the EncryptedLocalStore. When this doesn’t work (maybe because the user has reset a backup from an earlier version, encrypted with a password that has been changed multiple times), I provide the user with a dialog to enter the particular password for that database. After the successful login, I then re-encrypt the database with the current password and save it again to the EncryptedLocalStore for future use.

When the user has forgotten his or her password, similar thing happen. First of all, he or she has to request a new password. At this time we cannot verify the password (of course) because the user has forgotten it. So next to the user name, I then verify the email address also to provide some additional security. When the user is verified, an email is sent with a randomly generated password. So when the user wants to log in again, he or she has to do this with an active network connection, because the password is only available in the remote database. When the login was successful, once again I use the password from the EncryptedLocalStore to try to open the local encrypted database and re-encrypt it with the new password. After that, the user can change the password again and things happen as I discussed before.

Then another problem arose. During development I used a self-signed code signing certificate and all went well. Just up until the point where the certificate had to become an official Thawte certificate. Apparently, when you change the certificate, you also change the identifier and therefore the location of the application’s database. However, this is a feature that is documented here in the online help.

So any data the user may have had, has been lost now. You should think that using a backup and restore procedure by means of copying the database file from the old location to the new one would work just fine, but for some strange reason, the encryption key doesn’t allow the access anymore, which strikes me as being very odd. I assume this would mean that the encryption generator uses (part of) the application ID to encrypt the password. Still trying to figure this one out though…

Now, when we used the automatic update framework provided by AIR, we encountered another problem. When we increased our version number because of the implementation of the official code signing certificate, the update process failed. Again, this has something to do with the fact that the application ID has been changed by applying a different certificate and this is something the update framework apparently cannot handle. This can easily be solved manually by re-installing the application. This doesn’t affected the EncryptedLocalStore or local database, so no data will be lost.

So, conclusion is that the use of the automatic update framework and a local encrypted database is a nice feature in AIR, especially when you have a fixed encryption key. But when you want to personalise the encryption for added security, well, then you have to keep in mind that there are a lot of combinations you have to provide a fix for. And adding a new certificate bring along some issues as well, but nothing that cannot be solved.

< back to overview

Name (required)

Mail (will not be published) (required)

Website