Storing encrypted data

The EncryptedLocalStore class (ELS) provides an encrypted local storage mechanism that you can be use as a small cache for an application's private data. ELS data cannot be shared between applications. The intent of ELS is to allow an application to store easily recreated items such as login credentials and other private information. ELS data should not be considered as permanent, as outlined in "Limitations of the encrypted local store" and "Best practices," below.

Note: In addition to the encrypted local store, AIR also provides encryption for content stored in SQL databases. For details, see Using encryption with SQL databases.

You may want to use the encrypted local store to cache information that must be secured, such as login credentials for web services. The ELS is appropriate for storing information that must be kept private from other users. It does not, however, protect the data from other processes run under the same user account. It is thus not appropriate for protecting secret application data, such as DRM or encryption keys.

AIR uses DPAPI on Windows, KeyChain on Mac OS, and KeyRing or KWallet on Linux to associate the encrypted local store to each application and user. The encrypted local store uses AES-CBC 128-bit encryption.

Information in the encrypted local store is only available to AIR application content in the application security sandbox.

If you update an AIR application, the updated version retains access to any existing data in the encrypted local store unless:

  • The items were added with the stronglyBound parameter set to true

  • The existing and update versions are both published prior to AIR 1.5.3 and the update is signed with a migration signature (for more information see Changing certificates)

Limitations of the encrypted local store

The data in the encrypted local store is protected by the user’s operating system account credentials. Other entities cannot access the data in the store unless they can login as that user. However, the data is not secure against access by other applications run by an authenticated user.

Because the user must be authenticated for these attacks to work, the user’s private data is still protected (unless the user account itself is compromised). However, data that your application may want to keep secret from users, such as keys used for licensing or digital rights management, is not secure. Thus the ELS is not an appropriate location for storing such information. It is only an appropriate place for storing a user’s private data, such as passwords.

Data in the ELS can be lost for a variety of reasons. For example, the user could uninstall the application and delete the encrypted file. Or, the publisher ID could be changed as a result of an update. Thus the ELS should be treated as a private cache, not a permanent data storage.

The stronglyBound parameter is deprecated and should not be set to true. Setting the parameter to true does not provide any additional protection for data. At the same time, access to the data is lost whenever the application is updated — even if the publisher ID stays the same.

The encrypted local store may perform more slowly if the stored data exceeds 10MB.

When you uninstall an AIR application, the uninstaller does not delete data stored in the encrypted local store.

Best practices

The best practices for using the ELS include:

  • Use the ELS to store sensitive user data such as passwords (setting stronglyBound to false)

  • Do not use the ELS to store applications secrets such as DRM keys or licensing tokens

  • Provide a way for your application to recreate the data stored in the ELS if the ELS data is lost. For example, by prompting the user to re-enter their account credentials when necessary.

  • Do not use the stronglyBound parameter.

  • If you do set stronglyBound to true, do not migrate stored items during an update. Recreate the data after the update instead.

  • Only store relatively small amounts of data. For larger amounts of data, use an AIR SQL database with encryption.