Transparent encryption with Hibernate

December 7, 2006 @ 5:07 pm · Filed under Software Development, Java

The security people at my were suggesting that we needed to create an encryption service, to securely store passwords so that even rogue DBAs could not get at them. The idea is that no matter how good your access is to the database, you shouldn’t be able to decrypt the passwords unless you have the secret key. In a solution like this, the key is generally stored offline with the application and loaded into memory sometime during startup. The encrypted data never leaves the database.

Here is what I want:


public void testRetrieveWithCorrectKey() {
    EncryptedStringUserType.setKey(masterKey);
    String secretMessage = "this is the secret message";
    EncryptedEntity entity = new EncryptedEntity(secretMessage);

    Long id = dao.store(entity);
    dao.evictAll();
    EncryptedEntity retrievedCopy = dao.get(id);
    assertEquals(entity.getSecretMessage(), retrievedCopy.getSecretMessage());
}

public void testRetrievedWithIncorrectKey() {
    EncryptedStringUserType.setKey(masterKey);
    String secretMessage = "this is teh secret message";

    EncryptedEntity entity = new EncryptedEntity(secretMessage);
    Long id = dao.store(entity);
    dao.evictAll();

    EncryptedStringUserType.setKey(wrongKey);
    try {
        dao.get(id);
        fail(”should fail to read message”);
    } catch (RuntimeException e) {
        assertEquals(”Whoa! Master password wrong”, e.getMessage());
    }
}

Here, EncryptedEntity is an entity that has some property encrypted. The EncryptedEntity.secretMessage property is just a String variable. All the magic happens in the Hibernate mapping file:


<class name="EncryptedEntity">
    <id name="key" column="id">
        <generator class="native" />
    </id>
    <property name="secretMessage"
            type="no.brodwall.insanejava.crypto.EncryptedStringUserType” />
</class>

The interesting bits are in EncryptedStringUserType, which implements org.hibernate.usertype.UserType. Here is the code for saving the String property.


protected void noNullSet(PreparedStatement st, Object value, int index) throws SQLException {
    byte[] clearText = ((String)value).getBytes();

    try {
        Cipher encryptCipher = Cipher.getInstance(CIPHER_ALGORITHM);
        encryptCipher.init(Cipher.ENCRYPT_MODE, masterKey, paramSpec);
        st.setBytes(index, encryptCipher.doFinal(clearText));
    } catch (GeneralSecurityException e) {
        throw new RuntimeException("should never happen", e);
    }
}

Reading and decrypting is the same, mutatis mutandis. The master key is of course set by the tests. One example may be as a global variable:


public static void setKey(char[] masterKeyText) {
    try {
        SecretKeyFactory secretKeyFactory = SecretKeyFactory.getInstance(KEY_ALGORITHM);
        PBEKeySpec keySpec = new PBEKeySpec(masterKeyText);
        masterKey = secretKeyFactory.generateSecret(keySpec);
    } catch (GeneralSecurityException e) {
        throw new RuntimeException("should never happen", e);
    }
}

Get the full EncryptedStringUserType to see the not so gory details (notice: This is implemented with “Password Based Encryption”, but it should be simple to replace it with any Java Encryption algorithm you’d like.

Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 License.

Print This Post Print This Post

Viewing 8 Comments

    • ^
    • v
    Why do you want to store the passwords encrypted? Do you have any special requirements that requires you to be able to retrieve the password in clear-text? If not, hashing the password with a secure hash-algorithm is the only way to go.
    • ^
    • v
    Good question, Erlend. But the answer is obvious: The passwords are passwords that we use to log in to other systems. (Actually, the primary use case is private cryptographic keys)

    If these were passwords of users that we wanted to authenticate, I agree that hashing the passwords would be the correct solution.
    • ^
    • v
    Hello,

    I found this post, four months old, doing some research on already existing things "out there" for transparent encryption.

    I am the the founder of the Jasypt (Java Simplified Encryption) project, which among other things, provides a hibernate integration module for doing precisely this, transparent encryption of stored data.

    You can have a look at it at http://www.jasypt.org

    Regards,
    Daniel.
    • ^
    • v
    Hi, Daniel

    These tools look real cool (and simple to use). Have you considered implementing signing data in the same way?
    • ^
    • v
    Hello Johannes,

    If you mean adding asymmetric encryption techniques to jasypt, yes, that is in my to-do (maybe in a couple of versions). For the moment only message digests and password-based encryption are supported.

    And by the way, version 1.2 of jasypt (to be released early in April) will add support for transparent hibernate encryption of: BigIntegers, BigDecimals, Bytes, Shorts, Integers, Longs, Floats, Doubles, Dates, Calendars, Booleans and byte[]'s (blobs). This way it will cover the full range of data types most frequently used for attributes of persistent entities.

    Thanks for your interest.

    Regards,
    Daniel.
    • ^
    • v
    Hi, Daniel

    Signatures requires a little more than asymmetric encryption, most notably, one has to consider where to store the actual signature. There's also a danger of replay-attacks if you don't include the primary key in the hash, so there are a few issues to consider to make it transparent. Nothing very impossible, though.

    With regard to the different data types, have you analyzed whether encryption like this is appropriate for very short data types? It seems to me that the shorter the data type, the easier it will be to somehow brute force it. But I might have misunderstood the fundamentals of encryption here.


    ~Johannes
    • ^
    • v
    Hello Johannes,

    About short data types - yes, they could be easier to brute force, but only if we didn't generate the encryption key with the enough strength. In PBE, if we follow the RSA standards (and jasypt does), for generating the encryption key, the password is added a (preferably random) salt, and then it is applied a hash function a number of times (iteration count).

    The addition of a random salt, and the application of a hash function many times (RSA recommends at least 1,000) adds an important strength to the resulting encryption key (it is the same process as described in "Encrypting Passwords" in the jasypt website http://www.jasypt.org/encrypting-passwords.html), and, among other desirable effects, allow the domain of the result of the encryption of a small domain like a Byte object be much more diverse and big than the original domain.

    This is, with a Byte object we will have 256 possible values; but once encrypted, we will have much more. (And also we will need more space to store it, of course). Brute force won't be that easy, here.

    Regards,
    Daniel.
    • ^
    • v
    Hi, Daniel

    Thanks for a good introduction on how to encrypt small amounts of data. Your comment helped correct some of my confusion on the subject.
blog comments powered by Disqus
Creative Commons Attribution 3.0 Unported
Creative Commons Attribution 3.0 Unported