[hibernate-dev] Feature Request: Encrypt sensitive data with an "encrypted store/filter"

Sebastian Bicchi sebastian.bicchi at sec-research.com
Fri Jun 23 13:25:22 EDT 2017


Dear all,

this is my first Thread/Request on this mailing list and maybe I'm completely wrong here. If so - please excuse that and ignore this message.

Now back to topic: My small "start-up" was confronted with the problem of storing sensitive data in the database via hibernate. The data I cared most about were credentials to APIs, tokens, private keys for signing, etc., in other words: Data that our application needed in plaintext but also might help an attacker in case of a breach of the database. Also data that you not necessarily would reveal to an DBA, especially if you make use of managed databases (how much do you trust your database?).

So we implemented an encrypted key-value store. The encrypted key value store encrypts at the moment only the value of the stored key-value pair. We're working on encrypting the key (=ID) as well. Because you can't trust the file system of the web-app server as well as the database, the secure store needs to be initialized with a passphrase or keyfile at the start of the (web-)application. After initialization the encrypted kv store resides inside of "@Context HttpServletRequest" and is accessible by the Web-App. The key for de/encryption only resides inside the memory of the server. This is the big win - even if you get a database dump (and there are *a lot* of dumps on pastebin or in the darknet) you wont be able to decrypt the stored values. Also, if you get access to the file system - you wont be able to decipher the values.

The Class of the Encrypted Key Value store only lets you initialize it with a passphrase, but never read the passphrase nor the symmetric key. Nevertheless there is no perfect security: If an attacker obtains full root access to the web application server he will be able to get access to the keys by dumping the memory of the JVM. Also if there is an code execution weakness you might be able to obtain values - we counter measure that by using Java Security Manager. Only signed classes can will get access to the Encrypted Key Value Store. Also we set up a restriction on reflections. 

Now my request/question: Do you think it would make sense to add an annotation "@Encrypted" to encrypt fields at ORM Level? In my opinion this would be a great security win for hibernate (even if the JPA doesn't define an "Encrypted Entity"). It would be very nice if you just annotate a field with "@Encrypted" and let a transparent encryption do the work. 

There are several steps to archive this, but I think it is possible:
* Each entity needs an Initialization Vector
* It is possible to make use of "format preserving encryption" and therefore not breaking the schema with encryption
* Without format preserving encryption, the encrypted fields will be converted to an @Lob or at least some binary type
* The initialization of the application needs to be done by an user  - there is no generic way to archive this without breaking the security

If you think that might be a good thing for hibernate, please advice were it should be implemented and I will try to do so.


Kind regards
Sebastian Bicchi
 
--------------------------------------------------
Sec-Research GmbH
Graf Starhemberggasse 6/4
1040 Vienna
Tel.: +43 (0)660/228 25 77
https://www.sec-research.com
FN445069p, Handelsgericht Wien
--------------------------------------------------



More information about the hibernate-dev mailing list