During a recent discussion, I was surprised to find that what I
thought I knew about database key rotation was not all correct!
background: KEK and DEK
Any bulk data is normally encrypted using a
symmetric key which is usually called a Data
Encryption Key (DEK). This in turn is protected using another
key called a Key Encryption Key (KEK).
Key rotation is a process whereby, in a scheduled
manner, you remove an old key and replace it with a new key. Naturally,
for a DEK this means you have to decrypt and re-encrypt all the
data – something that is generally pretty darn hard to do for most
enterprise data sizes (heck I’d have trouble doing that even on all the
laptops I’m responsible for at home!)
So my impression was that it was either this untenable/impractical
process, or just rotate the KEK and be done.
various DBs take the
shortcut!
Spurred by some discussion at work, I went digging. At first
everything I found corroborated the more relaxed “rotate the KEK only”
school of thought. The threat model here seems to be:
the DEK is stored with the database, and is not considered
to be under any threat that is different than the rest of the database
itself. The decrypted form of it stays in ephemeral storage
only. Brute forcing the DEK is out of the question.
It is protected by the KEK, which is often an asymmetric key, which
in turn may be protected by other means – and that is where you focus
all your protections.
Some example links for the “relaxed” mode:
https://www.sqlservercentral.com/articles/key-rotation-in-tde –
The DEK is a symmetric key and doesn’t change…
https://matthewmcgiffen.com/2018/03/28/rotating-tde-certificates-without-re-encrypting-data/
says With TDE we have the database encryption key (DEK) – the key
that is actually used to encrypt/decrypt the data, stored encrypted in
the database itself. In the normal run of things, we never access this
key directly and never store it anywhere else, so it should be fairly
safe, i.e. we should rarely have to worry about replacing it – though
the functionality exists to allow us to do so if we require.
https://www.oracle.com/database/technologies/faq-tde.html – question
“How are TDE encryption keys managed?” under “Key Management” says
TDE master keys can be rotated periodically according to your
security policies with zero downtime and without having to re-encrypt
any stored data. Historical master keys are retained in the keystore in
case encrypted database backups must be restored later.
https://github.com/MicrosoftDocs/sql-docs/blob/live/azure-sql/database/transparent-data-encryption-byok-key-rotation.md
says (somewhere!) Rotating the logical TDE protector for a server
means to switch to a new asymmetric key that protects the databases on
the server. Key rotation is an online operation and should only take a
few seconds to complete, because this only decrypts and re-encrypts the
database’s data encryption key, not the entire database
PCI-DSS takes the high road!
There was literally only one site I found which said something
different. PCI-DSS
Key Rotation requirements basically say you have to rotate the
DEK, not just rotate the KEK and “call it a day” :)
The reasons given are:
Key rotation limits the amount of information available for
cryptanalysis, protected by a particular key.
Key rotation limits exposure when malicious or unknowingly
compromised a particular key.
Protects against current or future algorithmic vulnerability that
shortens key life.
The process it outlines is quite complex, but it is much more
scalable than “decrypt and re-encrypt all your data”:
Securely store and distribute multiple Data Encryption Keys (DEK)
and associated Key Encryption Keys (KEK)
Authorize decryption via legacy DEKs.
Issue a new cryptographically secure DEK.
Have newer data only use this new key authorized for the current
time range.
Monitor the dynamic mapping between each piece of data; this is the
data encryption key, their key encryption keys, and master encryption
keys.
Optionally, decrypt all old data and completely re-encrypt it with
the latest encryption key.
Of course, it’s kinda hard to imagine how this would work in practice
– it certainly won’t work with what databases call “Transparent Data
Encryption” – which can (I think) use only one key. Think of your hard
disk encryption – you can’t say “all files created after today will now
use a different key”.
Thus, it is almost certainly something that the database has to
explicitly support, perhaps using “row level security” or something
similar. And the bookkeeping associated with mixing records with
different keys is likely to be horrendous, and almost certainly
error-prone and requiring rigorous testing.
But for some people, it may be cheaper than the alternative!
my take
I find myself not completely agreeing with the reasons that
PCI-DSS outlines. Perhaps for really large sites it makes a difference,
but I think cryptanalytic methods are easier said than done, and I
really think protecting the DEK is not that hard (on a proper
system).
The best I will say is that, sure if you can rotate the DEK,
by all means go ahead, but you and your threat model have to decide if
it’s worth it or not.