3

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?

ir01
  • 383
  • 1
  • 4
  • 13
Keibosh
  • 1,237
  • 1
  • 9
  • 18
  • Against what kind of threat do you want to protect the data? Maybe it's sufficient to use the database's encryption mechanisms (depends on the product)? – home Aug 01 '11 at 15:39
  • We need to protect against someone simply reading the data out of the DB. Its DB2 v9. I would rather put something in that will stand the test of time versus something product specific. – Keibosh Aug 01 '11 at 15:46
  • 1
    The problem is, if you encrypt on the application layer (e.g. fields in database are encrypted), you first have a performance degradation depnding on algorithm strength, second your queries won't work any more (e.g. where conditions). Or do you plan to only encrypt certain fields (credit card #s, dates of birth, etc.)? – home Aug 01 '11 at 15:56
  • The intent was only sensitive information would be encrypted. This information is generally not search able directly in the application anyway. If we did need to search on these fields though would using the built in encryption mechanism in the DB allow us to keep our existing queries as is? Is it all transparent to the application tier? – Keibosh Aug 01 '11 at 16:09
  • 1
    In general, yes. I only did this with Oracle, but if you encrypt on the database level, it's transparent to you. BTW: Remember that you may want to encrypt on the wire as well (TCP traffic)? – home Aug 01 '11 at 16:15
  • Thanks will have to take a hard look at the built in DB encryption. We are running over SSL to cover the TCP traffic. – Keibosh Aug 01 '11 at 16:23
  • @Keibosh: I added something to my post - people often forget to secure their database connections on the transport level... doesn't make much sense to encrypt the database if the plain-text data could still be traced on the network level. – emboss Aug 01 '11 at 16:35

1 Answers1

3

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.

emboss
  • 38,880
  • 7
  • 101
  • 108
  • thanks for the update on the App - DB communication we certainly did not have that on our radar. – Keibosh Aug 01 '11 at 18:01