H2: how to protect with encryption, without disclosing the file encryption key

Question

We use the Java + H2 database in server mode because we do not want users to access the database file.

To add additional protection to the database file, we plan to use AES encryption (add CIPHER = AES to the database URL) in case of storage theft.

However, each user will also have to provide a password to protect the files on connection ([file password] [space] [user password]).

Although users do not have access to the database file, knowing the encryption key (file protection password) will make encryption completely useless.

Any idea to keep the database file safe (encrypted) without providing a file encryption key to users?

Thanks.

Answer 1

There is currently no way to do this inside H2.

One solution is to use file system encryption, which is independent of H2.

But note that at some point you will need to provide a password (database file or file system). It can be at server startup (request to enter the password manually). Unfortunately, since someone had to enter a password, you could not fully automate the server startup.

Answer 2

One smart approach I've heard about is to write a simple web service that blocks all sites except your webapp server. Use SSL with certificate-based authentication.

This web service provides an encryption key.

It sounds very silly since it seems to provide a key without authentication, but certificate-based authentication covers that. It provides key encryption during transit (and if you are really paranoid, you can use a shared key to transfer the database key). It can only be called from the webapp server, and it is much more difficult to call the webservice call than to do SQL injection or even look at the file system.

If your risk model allows this, you can even run this web service in the same field as your webapp.

Answer 3

The second approach, if you have the necessary rights, is to create a virtual disk. Place the key on the virtual disk.

During startup, you mount the virtual disk, read the encryption key, then disconnect the virtual disk. In some projects, you can refuse operating system permissions that allow you to mount a virtual disk - then it would be impossible for an attacker to read the key through your webapp.

This comes from a much older strategy that reads sensitive information from a CD (or even from a floppy disk). The application will read the key, and then eject the media. It works, but requires manual intervention to reboot the media until the next restart. It also does not work in modern environments where there are no CDs on the servers, let alone floppy drives.