AIR: Encrypted local storage and Update framework

In a previous entry I wrote about the different ways you have to store data in an AIR application. One way is to use the encrypted local storage. The signature of the method that you use to place something in “vault” is:

EncryptedLocalStore.setItem(name:String, data:ByteArray, stronglyBound:Boolean = false):void

Usually, you use just the first two arguments: name – the key you use to store and to retrieve the data, and data – what you want to store. However the third argument is very interesting. If you set this to true, then the stored item is strongly bound to the digital signature and bits of the AIR application in addition to the publisher id. This means that if the bits of the installed application are changing, then the previous stored information in the encrypted storage cannot be read anymore.

This is great because it gives you all the security you might need – if somehow, some malicious files are injected into your application, the data are protected and cannot be read.

But in some situations, it is not so great. If you use the update framework, after each update the bits are changed and thus the information is lost. So, I spent some time thinking on this issue and I came to the conclusion that the only solution is this:

  • during the update detection read the data from the encrypted store and write back using stronglyBound set to false;
  • when the application is re-started, check if you have something in the above store, and if you have write it back to store with stronglyBound set to true and delete the transient data.

So, this is the only solution I came with for this. I am curious; how do you handle this?

4 thoughts on “AIR: Encrypted local storage and Update framework

  1. Mihai,

    approach you propose seems to be really only one possible.

    If I understood you correctly, update detection is performed in ‘old version’ just when app checks for updates. So, app have a chance to detect the next installation.

    But it has some limitations. If user just uninstalls the application using standard system tools and then installs new version again, application can’t detect it by itself and so isn’t able to make this trick with local storage.

    It seems it is very hard to overcome such issues without having real install / uninstall events in the AIR framework. While there’s no such events, developers should invent workarounds to detect such user actions by saving special version files in the application directory and then checking them each time application is run. What do you think, is this possible to have uninstall event in the future version of AIR Runtime?

    Here’s the another example, where such event is strongly needed: my customer asked me to clear user-sensitive data when AIR App is uninstalled. But there’s no way to do it now…

  2. Yes Rost, this is a problem indeed. When you unistall an application the user data remain on the disk.

    To your specific problem, for now I have only one solution. To create an uninstall procedure in the AIR application that does that: delete all the user data wrote by the application. And then the user uninstall the app from the disk. But this approach relies heavily on the user (he start the unistall in the AIR before he unistall the app from system).

  3. Thank you for the response, Mihai!

    Yes, we keep in mind that possibility, but strive to keep everything automatic where we can :)

    In our particular case, we came to a solution, which works in my tests now (our QA will let me know better does it really work as requested).

    So, our task is: detect the case when application is re-installed (installed after uninstall, the same version) and perform some actions, e.g. say to user: “Welcome back!” (actually, customer requested us to clean ELS in this case).

    Solution is: to compare time of application install with application last run time.

    In details:

    1. At runtime, get app install time from applicationDirectory.modificationTime.

    2. If ELS has variable ‘lastRunTime’, get it too and:

    2.1 Compare these values. If last run time is less than application install time, than our app was reinstalled and we can do our special actions. Else, we run in normal mode.

    This is the logic which can be unclear for someone who are going to maintain the code, but it seems to work :)

    Thank you,

  4. Very excellent idea, Rost :)

    I was having tough time cleaning the ELS cookie after the AIR app uninstall. While searching I read your idea of comparing the lastAppRun time with applicationDirectory.modificationDate and it worked well. Thanks a ton for sharing your solution :)

    Thanks, Prem
    AIR/Flex/Flash Solution Architect

Leave a Reply