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

[Vlad Mihalcea]

Hi,

The easiest way to do it is to use Transparent Data Encryption in the RDBMS:

https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption-tde

For simple use cases, you can just use the @ColumnTransformer as explained
in this article:

https://vladmihalcea.com/2017/02/24/how-to-encrypt-and-decrypt-data-with-hibernate/

There used to be the Jasypt project which provided encryption for
Hibernate, but it does not look like it's very active:

http://www.jasypt.org/

Vlad

On Fri, Jun 23, 2017 at 8:25 PM, Sebastian Bicchi <
sebastian.bicchi at sec-research.com> wrote:

> 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
> --------------------------------------------------
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>