ACTIONSCRIPT 3 Developer’s Guide en

ACTIONSCRIPT 3.0 DEVELOPER’S GUIDE
Working with local SQL databases in AIR
var newKey:ByteArray = new ByteArray();
// ... generate the new key and store it in newKey
conn.addEventListener(SQLEvent.REENCRYPT, reencryptHandler);
conn.reencrypt(newKey);
function reencryptHandler(event:SQLEvent):void
{
// save the fact that the key changed
}
The reencrypt() operation runs in its own transaction. If the operation is interrupted or fails (for example, if the
application is closed before the operation finishes) the transaction is rolled back. In that case, the original encryption
key is still the encryption key for the database.
The reencrypt() method can’t be used to remove encryption from a database. Passing a null value or encryption
key that’s not a 16-byte ByteArray to the reencrypt() method results in an error.
Considerations for using encryption with a database
Adobe AIR 1.5 and later
The section “Uses for an encrypted database” on page 757 presents several cases in which you would want to use an
encrypted database. It’s obvious that the usage scenarios of different applications (including these and other scenarios)
have different privacy requirements. The way you architect the use of encryption in your application plays an
important part in controlling how private a database’s data is. For example, if you are using an encrypted database to
keep personal data private, even from other users of the same machine, then each user’s database needs its own
encryption key. For the greatest security, your application can generate the key from a user-entered password. Basing
the encryption key on a password ensures that even if another person is able to impersonate the user’s account on the
machine, the data still can’t be accessed. On the other end of the privacy spectrum, suppose you want a database file to
be readable by any user of your application but not to other applications. In that case every installed copy of the
application needs access to a shared encryption key.
You can design your application, and in particular the technique used to generate the encryption key, according to the
level of privacy that you want for your application data. The following list provides design suggestions for various levels
of data privacy:
To make a database accessible to any user who has access to the application on any machine, use a single key that’s
available to all instances of the application. For example, the first time an application runs it can download the
shared encryption key from a server using a secure protocol such as SSL. It can then save the key in the encrypted
local store for future use. As an alternative, encrypt the data per-user on the machine, and synchronize the data with
a remote data store such as a server to make the data portable.
To make a database accessible to a single user on any machine, generate the encryption key from a user secret (such
as a password). In particular, do not use any value that’s tied to a particular computer (such as a value stored in the
encrypted local store) to generate the key. As an alternative, encrypt the data per-user on the machine, and
synchronize the data with a remote data store such as a server to make the data portable.
To make a database accessible only to a single individual on a single machine, generate the key from a password
and a generated salt. For an example of this technique, see “Example: Generating and using an encryption key” on
page 762.
Last updated 6/6/2012
761