google-cloud-platformencryptiongoogle-cloud-kms

Data Encryption Keys and Key Encryption Keys

I hope someone can help me to understand how DEK and KEK works in layman term.

This is my understanding so far

Part 1 Uploaded data is stored in chunks. Each chunk is encrypted with DEK. DEK is stored near the chunked data.
Part 2 DEK of the data chunk is wrapped with KEK
Part 3 KEK is stored in KMS.

This sentence from a Google's course material really tripped me.

The wrapped data encryption keys are then stored with this data

My brain goes crazy with these questions:

  1. What is this wrapped data encryption keys? Isn't that the KEK in part 2?
  2. If that's the KEK in part 2, shouldn't that be in KMS?
  3. If yes, does KMS store data?
  4. If no, how many DEKs a chunk of data has? 2 DEKs?
  5. What keys do we(users/customers)keep?
  6. We store the data with which keys?
Solution

  • What is this wrapped data encryption keys? Isn't that the KEK in part 2?

    The wrapped DEK is the result of encrypting the DEK with the KEK. The key encryption key is called that because it encrypts (data encryption) keys.

    If that's the KEK in part 2, shouldn't that be in KMS?

    Does KMS store data?

    No. As the name suggests, a key management system only stores keys, and specifically KEKs.

    How many DEKs does a chunk of data have? 2 DEKs?

    One. Data is encrypted only once, so there is only one key.

    What keys do we (users/customers) keep?

    Only the KEK. When using a KMS, not even that key is known to you, the user of the KMS.

    We store the data with which keys?

    With the wrapped DEK.

    Here is a concrete example:

    Data (i.e. plaintext): yellow submarine KEK (aka. master key): my-secret-master DEK (randomly generated for each piece of data): ttlly-random-dek

    Ciphertext: Base64(AES(Data, DEK)) = TJ4SLFTy0sMdvGe55QCuYQ== Wrapped DEK: Base64(AES(DEK, KEK)) = lOEmql1JuSONZ8uLorc/vQ==

    The second operation is done by the KMS, if there is one (it has to be, because it's the only one in possession of the KEK, and it will never disclose it).

    What you store together: TJ4SLFTy0sMdvGe55QCuYQ== and lOEmql1JuSONZ8uLorc/vQ==.

    And to reconstruct the plaintext given TJ4SLFTy0sMdvGe55QCuYQ== + lOEmql1JuSONZ8uLorc/vQ==:

    DEK: AES'(Base64'(lOEmql1JuSONZ8uLorc/vQ==), KEK) // = ttlly-random-dek Plaintext: AES'(Base64'(TJ4SLFTy0sMdvGe55QCuYQ==), DEK)

    The first operation is done by the KMS if there is one (again, it has to be, because the KEK is involved).

    In the example above I conveniently chose 16 bytes of data and 16-byte keys, so I could gloss over block cipher modes and IVs/nonces. In practical applications the IVs for each encryption have to be retained as well, of course.

    Note that the KMS never sees your data, and it only has to encrypt and decrypt tiny amounts. That is why we do all of this; only you, the owner of the data ever sees it in plaintext (assuming the KMS is an honest party, obviously).