Considerations for using encryption with a database
The section Uses for an encrypted database 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.
The following are additional security considerations that are
important to keep in mind when designing an application to use an
encrypted database:
A system is only as secure as its weakest link. If you
are using a user-entered password to generate an encryption key,
consider imposing minimum length and complexity restrictions on
passwords. A short password that uses only basic characters can
be guessed quickly.
The source code of an AIR application is stored on a user’s
machine in plain text (for HTML content) or an easily decompilable
binary format (for SWF content). Because the source code is accessible,
two points to remember are:
Never hard-code an encryption
key in your source code
Always assume that the technique used to generate an encryption
key (such as random character generator or a particular hashing
algorithm) can be easily worked out by an attacker
AIR database encryption uses the Advanced Encryption Standard
(AES) with Counter with CBC-MAC (CCM) mode. This encryption cipher
requires a user-entered key to be combined with a salt value to
be secure. For an example of this, see Example: Generating and using an encryption key.
When you elect to encrypt a database, all disk files used
by the database engine in conjunction with that database are encrypted.
However, the database engine holds some data temporarily in an in-memory
cache to improve read- and write-time performance in transactions.
Any memory-resident data is unencrypted. If an attacker is able
to access the memory used by an AIR application, for example by
using a debugger, the data in a database that is currently open
and unencrypted would be available.
