How to use a JPA Attribute Converter to encrypt your data

A few days ago, I read an interesting article by Bear Giles about Database encryption using JPA listeners from 2012. He discusses his requirements for an encryption solution and provides a code example with JPA listeners. His main requirements are:

  • provide a transparent encryption that does not affect the application,
  • be able to add the encryption at deployment time,
  • develop application and security/encryption by two different teams/persons.

And I completely agree with him. But after 1.5 years and a spec update to JPA 2.1, JPA listeners are not the only solution anymore. JPA 2.1 introduced Attribute Converter, which can be used to create a maybe better solution.

General information and setup

This example expects, that you have some basic knowledge about JPA Attribute Converter. If you want to read in more detail about Attribute Converters, check my previous article on JPA 2.1 – How to implement an Attribute Converter and this free cheat sheet with all new features introduced in JPA 2.1.

The setup for the following example is quiet small. You just need a Java EE 7 compatible application server. I used Wildfly 8.0.0.Final which contains Hibernate 4.3.2.Final as JPA implementation.

Creating the CryptoConverter

Payment information like a credit card number are confidential information that should be encrypted. The following code snippet shows the CreditCard entity which we will use for this example.

As we pointed out in the beginning, the encryption should work in a transparent way. That means, that the application is not affected by the encryption and that it can be added without any changes to the existing code base. For me, this also includes the data model in the database because it is often created by some application specific scripts which shall not be changed. So we need a Attribute Converter that does not change the data type while encrypting and decrypting the information.

The following code snippet shows an example of such a converter. As you can see, the converter is quite simple. The convertToDatabaseColumn method is called by hibernate before the entity is persisted to the database. It gets the unencrypted String from the entity and uses the AES algorithm with a PKCS5Padding for encryption. Then a base64 encoding is used to convert the encrypted byte[] into a String which will be persisted to the database.
When the persistence provider reads the entity from the database, the method convertToEntityAttribute gets called. It takes the encrypted String from the database, uses a base64 decoding to transform it to a byte[] and performs the decryption. The decrypted String is assigned to the attribute of the entity.

For a real application, you might want to put some more effort into the encryption or move it to a separate class. But this should be good enough explain the general idea.

OK, we have a Attribute Converter that encrypts and decrypts a String. Now we need to tell hibernate to use this converter to persist the ccNumber attribute of the CreditCard entity. As described in one of my previous articles, we could use the @Convert annotation for this. But that would change the code of our application.
Another and for our requirements the better option is to assign the converter in the XML configuration. This can be done in the orm.xml file. The following snippet assigns the CryptoConverter to the ccNumber attribute of the CreditCard entity.

That is everything we need to do to implement and configure a Attribute Converter based encryption for a single database field.

Entity Listeners or Attribute Converter?

The answer for this question is not as easy as it seems. Both solutions have their advantages and disadvantages.
The entity listener described by Bear Giles can use multiple attributes of the entity during encryption. So you can join multiple attributes, encrypt them and store the encrypted data in one database field. Or you can use different attributes for the encrypted and decrypted data to avoid the serialization of the decrypted data (as described by Bear Giles). But using an entity listener has also drawbacks. Its implementation is specific for an entity and more complex than the implementation of a Attribute Converter. And if you need to encrypt an additional attribute, you need to change the implementation.
As you saw in the example above, the implementation of a Attribute Converter is easy and reusable. The CryptoConverter can be used to encrypt any String attribute of any entity. And by using the XML based configuration to register the converter to the entity attribute, it requires no change in the source code of the application. You could even add it to the application at a later point in time, if you migrate the existing data. A drawback of this solution is, that the encrypted entity attribute cannot be marked as transient. This might result in vulnerabilities if the entity gets written to the disk.

You see, both approaches have their pros and cons. You have to decide which advantages and disadvantages are more important to you.


In the beginning of this post, we defined 3 requirements:

  • provide a transparent encryption that does not affect the application,
  • be able to add the encryption at deployment time,
  • develop application and security/encryption by two different teams/persons.

The described implementation of the CryptoConverter fulfills all of them. The encryption can be added at deployment time and does not affect the application, if the XML configuration is used to assign the Attribute Converter. The development of the application and the encryption is completely independent and can be done by different teams. On top of this, the CryptoConverter can be used to convert any String attribute of any entity. So it has a high reusability. But this solution has also some drawbacks as we saw in the last paragraph.

You have to make the decision which approach you want to use. Please write me a comment about your choice.

If you enjoyed this article and like to learn more about Java EE, make sure to download the New in JPA 2.1 Cheat Sheet and follow me on twitter or google+.

Print Friendly
Secure your early bird discount for the Hibernate Performance Online Training

Enjoyed this post?

Signup to receive regular updates and the "What's new in JPA 2.1" cheat sheet for free!

I respect your privacy and will keep your email address safe.


    • Thorben Janssen says

      Not out of the box because the used Hibernate version does not implement JPA 2.1. You need to update Hibernate to a version >4.3.0 or you switch to Wildfly 8.

  1. Svetoslav says

    Thank you for the excellent article! I have successfully implemented my AttributeConverter and it is being triggered as it should be. But now I have a problem using an @Inject in it. I already use @Inject at many other places and can not figure out why it won’t work at this specific place. Hence my questions:

    1. Is it not possible to use CDI in an AttributeConverter?
    2. Which container manages those AttributeConverters?

    Any help will be appreciated!

    • Thorben Janssen says

      Hi Svetoslav,

      sorry for the late response. As far as I could find out so far, it’s not possible to use CDI in AttributeConverters. That’s really annoying but not completely unexpected, as it had to be specifically added to EntityListeners (and is still not working correctly).


  2. Raj says

    Nice post, Helpful.

    But unfortunately , @Converter does not support when using Hibernate Envers for auditing at the same time.
    If you have any thoughts on it that would be great.

    Thanks Anyway.

Leave a Reply

Your email address will not be published. Required fields are marked *