Question

I have a web application accessed over SSL. To beef up security on the back end we are looking at adding in symmetric encryption for the database.

The application is spread across 6 servers in a websphere cluster.

We were looking at a simple model of generating a common key, propagating the key across all clones in an isolated JCEKS keystore.

Settled on AES (256) for the cipher and key length.

Question I have is how safe is this approach? My fear is we create all of this and encrypt the data, but if we lose the keystore or they key all our data is essentially lost forever.

Is this just a matter of backing up the key and keystore to ensure we always have a copy somewhere in case of a disaster?

Is AES still a solid cipher? and symmetric encryption is generally faster than asymmetric. is there any major performance impacts to using a 256 bit key or is it more on the size of the data being encrypted?

Answer 1

AES

AES is sill the official “Avanced Encryption Standard”, so it’s still a very good choice for a symmetric cipher. The speed penalty for longer key sizes is negligible compared to the improved security.

Overall approach

First of all, the approach itself seems sound. But you should keep in mind the disadvantages that encrypted data in the database introduces: no more efficient indexing, no query optimization, no selective queries in general… If you intend to encrypt large parts of the database or even the whole database you should better look into encryption functionality offered by the database itself. If you use this approach, you should additionally secure the connections to your database with SSL/TLS, something that is easily overlooked. This keeps all the benefits of a “normal” database while providing the added security you are looking for.

You’re right about losing the keys: you’re in big trouble then 🙂 But not all is lost, you could still brute-force the password of the JCEKS key store file…

What brings us to that resource. It’s really a hen-and-egg problem with key stores and passwords. The only really clean solution to this is entering the passwords manually each time the app/database is started. But this tends to be a real problem (think of: crash in the middle of the night), so people tend to store the passwords in a text file on the file system. It’s acceptable as long as you follow some guidelines:

• ideally this file would be on a different machine that has restricted access
• if it has to be on the same machine, restrict access permissions to that folder – but don’t forget to allow the app to access it
• encrypting that file again is normally not useful, hen-and-egg problem again. Although BASE64-encoding the contents can be beneficial to have a first defense against the technically less savvy
• Few people should know the password (cannot be said often enough)
• You should keep a backup of the password in a safe.
• Avoid key store file proliferation at all cost

If you really want to be strict (let’s say just one or two persons should know the password), then you could additionally install a Secret Sharing scheme but that might be overkill depending on your requirements. Such a scheme would allow individuals with a (in itself useless) part of a secret to combine parts in order to restore the actual secret. This way you can mitigate the risk of loss by spreading the parts to a larger group.