Archive for July, 2008

AIR: tight security for your apps. Pt 2. Bound to Bits

Following up from the previous post, it’s worth mentioning ‘strongly binding’ data in the EncryptedLocalStore (ELS). When storing your data with EncryptedLocalStore.setItem() , setting the optional ‘stronglyBound’ parameter to true will result in your data being strongly bound to the actual bits of the AIR application.

This is important to understand because it means that ANY modification of your application files will result in making that data inaccessible. So this means if the user were to update to a new version of the app, the data will not be accessible to the new version. I asked members of the Flex/Air team about this feature, specifically what risks you run by not strongly binding your data, and got back some useful feedback, particularly on i) what an attacker might attempt and ii) how one might account for version updates:

“An attacker can replace an app’s publisher ID by re-signing the victim app using a certificate that the attacker controls. After doing so, the attacker can then create his own app (with the same publisher ID), and have both the victim app and the attacking app use the same ELS files. For [an application that tracks user behavior], this is very useful to perform track fraud [if such an app were to rely] on ELS to store [the tracked data].

Strongly bound ELS items would not be accessible anymore [once] the storing app is updated (since then its bytes on disk would have been modified). To migrate these items, the older app will need to retrieve all ELS data and then encrypt them using its own [custom, non ELS] key and writes them to [local] disk. The newer app will then use the same key to retrieve them. How this key is generated is up to the developer (and directly influences the security of this migration process).

[Strong Binding] is implemented through hashing the storing and the retrieving Air apps’ bytes on disk, which means strongly bound ELS items will not typically survive from one Flex Builder debugging session to the next if the app’s code has been changed in between.”

Now tell me that isn’t good to know… Hope you guys find the above as helpful as I have.

Much thanks to Sunil Agrawal and the rest of the team for providing insight into this!


AIR: tight security for your apps. Pt 1. EncryptedLocalStore

Recently I looked into AIR security, specifically re: storing local data on the user’s machine. I’ve seen storing on the disk, and storing to SQLLite, but neither of these are secure and the data can be accessed by other apps. Fortunately your next resort doesnt have to be writing your own encryption algorithim, because we have the EncryptedLocalStore class (*)

From Adobe livedocs:
A persistent encrypted local store is available for each AIR application installed on a user’s computer. This lets you save and retrieve data that is stored on the user’s local hard drive in an encrypted format that cannot be deciphered by other applications or users. A separate encrypted local store is used for each AIR application, and each AIR application uses a separate encrypted local store for each user. Encrypted local store data is put in a subdirectory of the user’s application data directory; the subdirectory path is Adobe/AIR/ELS/ followed by the application ID.

Similar to how one would use setProperty() when dealing with shared objects, you can call the static method EncryptedLocalStore.setItem(), passing it a ‘key’ or identifier along with your data, and store up to 10 MB of ByteArray data in the encrypted store. So, using the read/write methods of the ByteArray class, you can store much of your sensitive application data securely. To retrieve the data, call EncryptedLocalStore.getItem() with the appropriate key.

One good thing to note is that it is not by the Application ID that access rights are verified, rather by the signing certificate and publisher ID; to impersonate another application, you’d have to have stolen a signing key or have hacked AIR.

Learn more on LiveDocs: EncryptedLocalStore