0

Posted this first on stackoverflow but was suggested to repost it here.

I am planning on using envelope encryption for data stored in a database in a multi-tenant solution. Envelope encryption suggest creating a separate DEK (Data Encryption Key) for each piece of data and then encrypt the data with the DEK and store encrypted data together with the wrapped DEK (wrapped by the Key Encryption Key).

When retrieving data we have to go through the process of unwrapping the DEK before doing decryption of the data, as the unwrapping is suggested to be done in a KMS (Key Management System) for security reasons it will take some time, like 10-50ms as it is a remote call.

As the unwrapping is costly keeping a separate DEK for each piece of data could have some major performance issues when having to decrypt a lot of data i.e. a SQL query that returns a lot of rows.

How to avoid this performance hit? The only solution I currently see is to use a DEK for multiple pieces of data, like the entire tenant, user or other group of data. Though this will probably bring in the need for rotating the DEK.

  1. Is it possible to have a separate DEK for each piece of data without the above performance issue? If so how are you solving this?
  2. The practical solution as I see it is to keep a DEK per tenant and rotate them, this will reduce the unwrapping operations to a couple per tenant. Is this viable or not recommended?

Any guidance is appreciated.

1 Answer 1

2

Yes, that's a valid approach to use a single DEK in multiple cases and rotate periodically. However, note that the same applies to the KMS key too: you've to rotate periodically.

I'd consider approaches like this that use KDFs instead.

2
  • Thanks for your response. I did not really get what KDF apparch you are refeering from the link, could you clarify that? I ended up with having a DEK per piece of information and keeping local tenant keys (that is rotated), these keys are wrapped/unwrapped by the KEK in KMS (also rotated). It seems practical and good. I have not seen that much resources describing having a local intermediate key closer to the data.
    – user579089
    Sep 11, 2023 at 7:21
  • I was thinking of giving the tenant key and some salt per data item into a KDF to generate a (DEK, nonce) pair. This way you may not need to worry about the rotation. (KMS keys remain the same tough.)
    – metemad
    Sep 11, 2023 at 22:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .