# Configuring database encryption

Derby provides a way for you to encrypt your data on disk.

By default, Derby stores its data unencrypted in ordinary operating system files. An attacker who can view those files can simply type them out, exposing all sorts of data stored in string columns. Knowing Derby's file formats, a clever attacker could even view numeric data stored in those files. Even worse, a clever attacker could change the data itself.

Fortunately, Derby can encrypt databases. On a shared machine, that helps protect data from other users, including disgruntled or curious superusers. Encryption helps protect private financial data from thieves who physically steal your laptop.

Before encrypting a database, you need to make two choices:

- A boot password: This is the password that unlocks your encrypted data when you want to use it.
- An encryption algorithm: This is a transformation name as described in the API documentation for the `javax.crypto.Cipher` class. Derby encryption relies on the JCE libraries supplied with the virtual machine. For more information on those libraries, see the Java Cryptography Architecture (JCA) Reference Guide (http://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html).

Here is a `ij` command that creates an encrypted database. Notice the additional attributes in bold on the database creation URL: `dataEncryption`, `encryptionAlgorithm`, and `bootPassword`. The URL string must be all on one line.

    connect 'jdbc:derby:myEncryptedDatabaseName;create=true;
    dataEncryption=true;encryptionAlgorithm=Blowfish/CBC/NoPadding;
    bootPassword=mySuperSecretBootPassword';

Once you have created an encrypted database, you can work in it. After you shut down the encrypted database, you can reconnect to it by simply supplying your boot password in the connection URL, as shown in the following `ij` command:

    connect 'jdbc:derby:myEncryptedDatabaseName;
    bootPassword=mySuperSecretBootPassword';

Keep in mind that by booting a database with its boot password, you unlock the database for the lifetime of the virtual machine. This means that other threads can connect to the database without supplying the boot password. This situation lasts until the database is explicitly shut down or the virtual machine exits. For a single-user, shrink-wrapped application, this is generally not a problem. However, for a multi-user application, you need to take steps to keep the data secure during the various stages of working with the database:

1. Unlocking the database: The boot password is used to initially unlock encrypted data. Once the Database Owner has unlocked the database, other users can connect to it without supplying the boot password.
2. Working with the database: For that reason, you should configure Derby authorization (see below) to restrict the users who may access the unlocked data.
3. Relocking the database: To relock your data, simply shut down the database.

The following sections provide detailed information about database encryption.

Note: Jar files stored in a database are not encrypted.

- Requirements for Derby encryption
  Derby supports disk encryption and requires an encryption provider.
- Working with encryption
  This section describes using encryption in Derby.

Parent topic: Part Two: Configuring security for Derby
Related concepts
Basic security configuration tasks
Using signed jar files
Configuring SSL/TLS
Understanding identity in Derby
Configuring user authentication
Configuring user authorization
Restricting file permissions
Putting it all together