H2 database: how to protect with encryption, without exposing file encryption key

Question

We are using Java + H2 Database in server mode, because we do not want users from accessing database file.

To add more protection to database file, we plan to use AES encryption (add CIPHER=AES to database URL) in case the storage is stolen.

However, each user will also need to supply file protection password when connecting ([file password][space][user password]).

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

Any idea to keep the database file secure (encrypted) without exposing file encryption key to users?

Thank you.

Answer 1

There is currently no way to do that within H2.

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

But please note at some point you would have to provide the (database file or file system) password. This could be when starting the server (prompting for the password to be entered manually). Unfortunately, because somebody would have to enter the password, you couldn't fully automate starting the server.

Answer 2

One clever approach I've heard of is to write a simple webservice that blocks all sites but your webapp's server. Use SSL with certificate-based authentication.

This webservice provides the encryption key.

It sounds really stupid since it seems to provide the key without authentication but the certificate-based authentication covers that. It provides encryption of the key during transit (and if you're really paranoid you could use a shared key to wrap the database key). It can only be called from the webapp's server and it's a lot harder to trigger a webservice call than to do SQL injection or even looking at the filesystem.

If your risk model allows it you could even run this webservice on the same box as your webapp.

Answer 3

A second approach, if you have the necessary permissions, is to create a virtual disk. Put the key on the virtual disk.

During startup you mount the virtual disk, read the encryption key, then unmount the virtual disk. In some designs you could drop the operating system permissions that allow you to mount the virtual disk - it would then be literally impossible for an attacker to read the key via your webapp.

This comes from a much older strategy that read sensitive information from a CD-ROM (or even floppy disk). The app would read the key and then eject the media. It works but requires manual intervention to reload the media before the next restart. It also doesn't work in modern environments where servers don't have CD-ROMs, much less floppy drives.