Encrypting Data and recover Unencrypted

Support
#1

Is there anyway to encrypt data into the database and pull it back out unencrypted so that the database data is secured. It was recommended to me before to Hash with a similar structure of com.haulmont.cuba.core.sys.encryption.Sha1EncryptionModule but doing this only allows for a 1 way hashing. Recovery of the data did not work.

Are there any other built in methods that I could leverage?

#2

Hi,

could you elaborate a little bit on what do you mean by ā€œdatabase data is securedā€? Are you talking about the the connection that the application server (the CUBA app) is using to connect to the database server is encrypted - like a TLS based communication? Or are you talking about the data that getā€™s stored in the database? This can either be the content of the data that getā€™s inserted, or it can be the physical files on the filesystem that are encrypted.

Depending on what you mean this might or might not have anything to do with CUBA. Oftentimes it is a feature of the DBMS or the hosted solution (you take a look at the AWS RDS encryption docs as an example of what database vendors / hosted database solutions are able to provide, doesnā€™t really matter if you are using AWS at all).

SHA1 in general is a hashing algorithm, meaning that it is not supposed to be used as a way to encrypt and decrypt your data.

Bye
Mario

1 Like
#3

Just the storage of the data. I am looking to encrypt the data at the application end instead of at the database. I can perform the work at the database no problem, but if I perform the encryption at the application level instead the data will be encrypted during the transfer to and from the database.

I only attempted the Sha1 as that was recommended to me previously but as it is hashing instead of encrypting it did not work. Since hashing is generally doing the same thing to encrypt in transfer the data is encrypted then verified at the database that it is the same.

I actually need the field to re display the data at a later time so the decryption is important, but wish to secure the database information in the event that the database gets compromised.

Thanks!

#4

> but if I perform the encryption at the application level instead the data will be encrypted during the transfer to and from the database.

This is true, but this is true for communicating to your database with TLS as well.

I donā€™t think there is any already implemented support for encrypting content to the relational database from CUBA or any other web app full stack framework. The reason for that is that this is a pretty rare case. You can do it on your own with something like the Java cryptographic extensions (JCE) and a common implementation lib Bouncy castle).
This would mean that you will before a certain entity is stored you have to replace the content of the object with the encrypted one and when the data is loaded, you do the reverse.

> but wish to secure the database information in the event that the database gets compromised.
Well, there is the underlying security architecture problem with your approach i think. So you assume that your DB server gets compromised. Ok, so the first thing to do would be to secure it in a way i described above. But letā€™s assume you donā€™t trust your DB instance nontheless, because you think it can be hacked, what makes you think that your tomcat instances canā€™t or at least there is a smaller likelihood that this situation will occur?

The problem with the above described JCE approach (letā€™s assume you do a symmetric encryption like AES), is that you have to store the secret key somewhere (at least you donā€™t take this stuff really seriously with something like Hashicorp vault.

So when you think of a scenario where you get hacked and it is not a general use of a security vulnerability, so your application gets picked before and because of any content of the app, then it will actually just be another indirection. Because the tomcat can get hacked as well and the secret key can get be taken to decrypt your data. So basically it would be security by obscurity.

The downside of that would be that you canā€™t use a lot of features of a relational database any longer. Take a date column for example: If the DB schema assumes you can only store dates in this column, how would you be able to insert encrypted dates into it? What would it look like? For a string column it would be possible, but nontheless, you will lose a lot of the query capabilities. It is not possible any longer to define a search query that says: select e from customer e where e.name like ā€˜%mario%ā€™, because the DB will not know how to compare stuff with encrypted strings.

You can do that, but i would suggest to really think about what you want to achieve before encrypting the content and explore alternative solutions that might fit your needs like the described above.

Bye
Mario

1 Like
#5

Hi,

you can perform automatic data encryption/decryption using special entity life cycle handlers called Entity Listeners: Entity Listeners - CUBA Platform. Developerā€™s Manual

For instance, if you want to store encrypted sensitive data in an entity CreditCard in a secretValue property then you can follow these steps:

  1. Add one more transitive attribute in CreditCard , e.g. decryptedValue
  2. Create Entity Listener with interfaces: BeforeDetachEntityListener, BeforeInsertEntityListener and BeforeAttachEntityListener
  3. Implement your encryption/decryption in onBeforeInsert+onBeforeAttach / onBeforeDetach methods of this entity listener.

These methods will be called automatically by the framework on the middleware and encrypt data before commit to DB and decrypt data after loading from DB. In your UI you have to use decryptedValue property that will contain decrypted sensitive data.

Iā€™ve created a small demo project that implements this feature: GitHub - cuba-labs/db-data-encryption

Please not that, framework cannot guarantee safety of your private encryption key, you have to keep it in a reliable place, not in the database and you cannot use hard-coded constant.

2 Likes