Help to understand the KDM in SP800-56A, and the usage of “FixedInfo”

Question

Can somebody help me to understand the LOGIC behind Key-Derivation Methods (SP800 56A CH5.8)? This is my common understanding and please correct me if any wrong..

1. Alice and Bob can general individual key-pair, by any public cryptography method (RSA, ECC, DL, etc..);
2. Based on the Key Exchange protocol (for exp ECDH), Alice and Bob can obtain the shared secret Z between them, and using Z as AES key for the afterwards communication.
3. If they like they can generate the new shared secret Z as they want--that is named as Ephemeral ECDH.

OK my question would be: here I don't really understand the Key-Derivation Methods (SP800 56A CH5.8) application scenarios--it looks like based on the common key agreement scheme (like ECDH), this KDM introduce a "FixedInfo" (which can be a readable text or just some hex string) concept.

I didn't find detail infor about how this "FixedInfo" works:

Does it use some Hash to process the "FixedInfo" and then derive new Secrete Key?

And does that mean each time a new FixedInfo shall be applied for both Alice and Bob?

Anyway, adding this "FixedInfo" looks NOT enhance security if compare to an Ephemeral ECDH--from my point-of-view..

---self update: OK after some study I have one explain but am not sure if that is correct--add such "FixedInfo" is actually a kinds of Ephemeral ECDH--it does not require a new ECC key-pair to be generated, so would reduce the key leakage risk? or from computing point-of-view this would save computing power?

Answer 1

There is a couple of reasons one would want to do SP800-56A key derivation in real life scenarios.

1. Computational and communication cost - while it's true that for each usage the two parties could negotiate a fresh Diffie-Hellman shared secret $Z$ and use it to derive a session key, usually this process is computationally expensive and requires communication between the parties. More frugal approach is to do the key exchange once to agree on a shared secret and then do key derivation to derive shared keys for various purposes.

2. Shared secret is not a cryptographic key - most likely the shared secret the parties agreed upon is not suitable for use as a cryptographic key. Usually, secrets agreed with DH are too long and (when seen as bit strings) not uniformly distributed. For example, the result of a Diffie-Hellman process over $\mathbb{F}_p^\ast$ would be a number with length 4096 bits. One cannot use it directly as e.g. AES key because it's too long and using only a part of it as a key is an extremely bad idea. So we need to do entropy extraction and this boils down to key derivation.

3. Many derived keys are required - usually, we need more than one key in a system. E.g. we may need symmetric encryption session keys, maybe HMAC key for integrity protection, etc... The good practice is to use a different cryptographic key for each usage. And in order to get the required number of different cryptographic keys from one "master secret" $Z$ we need key derivation. And here comes the FixedInfo parameter - it allows to parametrize the key derivation process and bind keys to their usages. For example, FixedInfo would contain the information about parties (so that we separate key derivations for different parties), purpose (so that we separate encryption keys from MAC keys), session (so that keys used for different sessions are different).

A drawback of the key derivation approach that is worth noting is that if the "master secret" $Z$ is compromised, all derived keys need to be treated as compromised as well. On the other hand, compromise of any of the derived keys does not constitute a compromise of other derived keys or the master secret.

Answer 2

Some days past and I did not receive good feedback regarding this particular question. Anyway, I have some thought and probably good to record here.

I think the motivation to introduce such "FixedInfo" is actually providing a kind of Ephemeral ECDH implementation.

That means for each communication session, the counterparty does not need to regenerate the ECC key, but only adding a little "salt" ("salt" can be a low entropy plaintext passcode, or a high entropy Random data) then get a new shared secret key.

Waiting for more professional update...