|
|
Storing encrypted dataThe Adobe® AIR® runtime provides a persistent encrypted local store 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 easily 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. 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 store information that must be secured, such as login credentials for web services. 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. By default, an AIR application cannot read the encrypted local store of another application. The stronglyBound setting provides extra binding (to the data in the application bits) that prevents an attacker application from attempting to read from your application’s encrypted local store by trying to hijack your application's publisher ID. If you update an application to use a different signing certificate (using a migration signature), the updated version will not be able to access any of the items in the original store even if the stronglyBound parameter was set to false. For more information see Changing certificates. When debugging an application in the AIR Debug Launcher (ADL), the application uses a different encrypted local store than the one used in the installed version of the application. 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. 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. Limitations of the encrypted local storeThe data in the encrypted local store is protected by the user’s authentication credentials. Other entities cannot access the data in the store unless they can login as that user. However, the data is not fully secure against access by other applications run by an authenticated user. Ordinarily, the runtime prevents one application from accessing the ELS of another. However, a user could re-sign an application with a different code signing certificate and access any data subsequently added to the ELS through another application having the same application and publisher IDs. (Data added to the ELS before the application was re-signed is still secure against access.) 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 an appropriate place for storing a user’s private data, such as passwords. Setting the stronglyBound parameter of the setItem() method to true only makes it slightly harder for a user to access information your application has stored in the ELS. Instead of reading the ELS with another application, the user must modify the original application such that they can read the ELS contents. Thus the level of sophistication required to access “secret” application data is only slightly higher than when not setting stronglyBound to true. At the same time, migrating stronglyBound items in the ELS when an application is updated can, itself, lead to data security risks. For example, if your application encrypts the data and stores it in a file during update, the data file is susceptible to access. In this case, the security risk may be even greater, since any user on the machine may be able to read the file and you must also keep the encryption keys secret somehow. The best practices for using the ELS include:
|
