I noticed AWS KMS generates encryption keys based off of a master key, using a key derivation function (HKDF).

What's the practical advantage of deriving keys based on a master key? Isn't it simpler and typically more secure to just generate random keys with a CSPRNG?

Fewer keys to store?

Edit: to add context to AWS KMS, it uses a hardware security module, which would seem to add a storage constraint. However, given KMS basically just generates new data encryption keys (DEKs) and wraps (envelope encrypts) them with the master key for the user to store elsewhere, it doesn't seem to change storage requirements. So it begs the question, why derive the DEKs from the master key?

  • 1
    $\begingroup$ In a sense HKDF is a CSPRNG. $\endgroup$ – Squeamish Ossifrage Mar 8 '19 at 6:41
  • $\begingroup$ Right, but is there a practical advantage to HKDF when you can generate uniformly random numbers in the first place? $\endgroup$ – Shruggie Mar 8 '19 at 7:34
  • 3
    $\begingroup$ Test vectors, reproducible computation, storage reduction as you mentioned, no reliance on an entropy source later on which might be busted… $\endgroup$ – Squeamish Ossifrage Mar 8 '19 at 7:36
  • 2
    $\begingroup$ To @Squeamish Ossifrage's excellent comment/answer, add that with key derivation from a serial number or other form of ID, no backup of the generated keys is necessary; and that distribution of the derived keys is automagic with distribution of the master key. That's also called (key) diversification. $\endgroup$ – fgrieu Mar 8 '19 at 8:58
  • 1
    $\begingroup$ @MaartenBodewes here are two links that discuss AWS KMS's use of KDF csrc.nist.gov/csrc/media/projects/… rwc.iacr.org/2018/Slides/Gueron.pdf And the documentation docs.aws.amazon.com/kms/latest/developerguide/concepts.html $\endgroup$ – Shruggie Mar 8 '19 at 23:35

Here are various advantages. Maybe they don't all apply in this case—I don't know, but there are cases in the real world in which they do apply.

  • Test vectors. You can write known-answer tests for your entire cryptosystem, end-to-end. You can verify these test vectors in a power-on self-test to cheaply detect catastrophic failure. You can easily use these test vectors to debug an interoperable alternative implementation during development.
  • Reproducible subcomputations. If you need to add a branch to a tree of subcomputations with an independent key, you can simply use a distinct label for the HKDF info parameter, and all the other computations will remain unchanged. That way, e.g., you don't have to update your test vectors, whereas you would have to if you drew keys out of a sequential PRNG.
  • Reduced storage. You only need to store as many keys as there are independent privilege domains in your system. You can simply rederive any subkeys for different purposes within a privilege domain instead of having to store them separately.
  • Reduced reliance on entropy sources. You can flash a key onto an embedded microcontroller, and use it to derive subkeys for various purposes, and even rotate keys and erase old ones, without having to rely on an entropy source on the microcontroller itself.
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.