[OCP-LOCK]: Spec follow up fixes

[clundin25]

• Revisit Error code section
  • The error codes in Caliptra are densely packed, instead of an encode ascii string.
• Add KDF label for mix MPK
• Add KDF label for enabled MPK
• Add KDF label for VEK
• Add encryption order to MPK rewrap mailbox command
• Add locked MPK KDF label
• Add padding to SealedAccessKey
• Double check IANA code points for HPKE algorithms
• Add padding to OCP LOCK endorsement command
• Add KDF label for preconditioned AES in figure 12
• Add max bound for wrapped key metadata length
• Bound HPKE handles in enumerate HPKE handle command
• Add upper bound to info size for SealedAccessKey
• Replace HPKE-PQ spec with latest version
• Replace RFC9180 with HPKE draft 02
• Figure 20 add MEK secret seed KDF label
• Add label for EPK derivation
• Condense OCP LOCK error codes
• MCU to perform endorsement
• MCU to perform attestation
• Update EKP spec.
• Update HEK seed states.
• Address [OCP-LOCK]: Move endorsement to Drive firmware #625 (comment)
• Move AES equality check from Encryption Engine to Caliptra

[james000]

LOCK compliance requirement #11 requires that the encryption unit ensure the AES-XTS key1 and key2 are not the same. Should the engine use reserved error code 0x2 as the response to indicate this has happened?

[GwangbaeCHOI]

Hi @james000,

I'm actually checking if that requirement can be handled by the Caliptra RT itself. It will be technically feasible by comparing the first half and the second half of input to AES-ECB decryption. But I still need confirmation from our FIPS experts.

Once it's done, we will either remove the compliance requirement 11 or assign an error code 0x2 for that.

[bluegate010]

I think having Caliptra RT FW handle the check is feasible for encrypted MEKs but would be difficult for derived MEKs.

For encrypted MEKs, the actual MEK is visible to Caliptra firmware when it is first generated, before it is encrypted with MDK and then with the MEK secret. So firmware could perform the check there.

However, for derived MEKs, while the MEK seed (highlighted in the message just above) is visible to firmware, the MEK seed is not the actual MEK; that's gotten by decrypting the MEK seed using the MDK, and firmware never sees the results of that.

If we want to enable Caliptra firmware to perform this check, we would need firmware to have visibility into derived MEKs. To accomplish that, we could have firmware take what is currently called the MEK seed, AES-ECB encrypt it with MDK, and then immediately decrypt it into KV. The MEK seed would then simply be the plaintext MEK.

This would of course have the drawback of making derived MEKs always visible to Caliptra firmware when they are loaded. Currently, the only MEKs visible to firmware are generated MEKs, and only when they are first generated, never again afterwards.

[GwangbaeCHOI]

It's feasible because we are using the ECB mode. Since we are using the same MDK, AES-ECB encryption/decryption is simply a 128-bit-wise permutation. If the first 256-bit of the MEK seed (resp. single-encrypted MEK) and the second 256-bit of the MEK seed (resp. single-encrypted MEK) are equal, then the first 256-bit of MEK and the second 256-bit of MEK will also be equal. Therefore, it will be enough to compare the MEK seed or the single-encrypted MEK to accomplish the key1 and key2 comparison for the XTS mode.

[james000]

Is this comparison expected to be done by firmware or hardware? If we are passing all MEK's through firmware then that seems like a potential source of leaks (especially side channel leakage) in addition to the overhead to do this compare.

[bluegate010]

It's feasible because we are using the ECB mode. Since we are using the same MDK, AES-ECB encryption/decryption is simply a 128-bit-wise permutation. If the first 256-bit of the MEK seed (resp. single-encrypted MEK) and the second 256-bit of the MEK seed (resp. single-encrypted MEK) are equal, then the first 256-bit of MEK and the second 256-bit of MEK will also be equal. Therefore, it will be enough to compare the MEK seed or the single-encrypted MEK to accomplish the key1 and key2 comparison for the XTS mode.

Ah that is an excellent point. Thanks Gwangbae. Yeah so we should be able to have Caliptra take care of this rather than the encryption engine.

Is this comparison expected to be done by firmware or hardware? If we are passing all MEK's through firmware then that seems like a potential source of leaks (especially side channel leakage) in addition to the overhead to do this compare.

The comparison could be done by firmware. However, the comparison would be done on ECB ciphertext, not the raw MEK itself.

[bluegate010]

One thing to note: Caliptra is not aware of the actual encryption algorithm used by the encryption engine. All it's responsible for is providing high-entropy key material. In particular, it's not aware of whether the engine is using AES-XTS, nor whether it's using 128 or 256-bit keys.

All this to say, Caliptra should probably be performing two inequality checks: mek_seed[0..128] != mek_seed[128..256] && mek_seed[0..256] != mek_seed[256..512]