Postmortem: Incorrect rt-alias-key derivation in FMC

The key derivation done by the FMC (label "rt_alias_cdi") is not conformant with the HMAC-SHA-384 specification. The HMAC computation only includes the first HMAC block, and is missing a second block which includes padding and a length suffix. This is not believed to be a security issue, as (by luck) all measurements are in the first block. If circumstances were slightly different, the consequences to these mistakes could have been a lot worse, so a post-mortem is necessary.

Background

Issue #1520 was filed, noting that the rt-alias public key differed between the RTL and the sw-emulator. This occurred because the driver/hardware was ignoring all blocks except for the first one in the derivation, but the sw-emulator implementation processed all blocks "correctly".

Causes

When consuming keys from the keyvault, the combination of the HMAC peripheral and driver only include the first 128-byte data block in the computation. The multi-block case is decently well tested by driver tests when operating on data and keys supplied and retrieved by the CPU, but when operating with keys supplied by (and result written to) the key-vault, the hardware clears the key after processing the first block, and subsequent blocks are ignored. This behavior was not called out in the hardware spec. I think folks assumed there would never be a need for multi-block HMAC for key derivation; and there wasn't, until somebody tweaked the derivation logic to use HKDF, which expanded the data beyond what would fit in a single block. I believe the systemic root causes are miscommunication between the hardware and firmware teams, and missing validation at several layers of the stack:

hardware: missing validation for the multi-block HMAC key-vault use case.
- hardware spec: missing documentation of how the HMAC/key-vault multi-block usage differed from the non-key-vault usage.
- firmware: missing multi-block HMAC key-vault driver test case (this is somewhat tricky because the direct results of the computation are kept secret from the CPU)
- firmware: missing assertion in end-to-end tests to independently derive the rt-alias-key from UDS and measurements and confirm it matched the public key in the cert.

I have confirmed in PR #1528 that reloading the key from the keyvault and reprogramming the destination registers after each block works around this multi-block issue in the driver.

What went well?

The ROM was not affected. The smoke-tests independently confirm the derivation of the ROM-generated fmc-alias-key from the UDS and measurements.

What went wrong?

Validation at several layers of the stack failed to notice this issue.

Where we got lucky

The sw-emulator HMAC implementation diverged from the RTL implementation, and somebody noticed the derivations weren't consistent.

The ignored HMAC block doesn't include any actual measurements (it just has padding + length):

# block 0 (this block included in rt_alias_cdi)
00000000  00 00 00 01 72 74 5f 61  6c 69 61 73 5f 63 64 69  |....rt_alias_cdi|
00000010  00 03 91 03 63 1e f7 9d  36 a1 5c 5a 38 07 ca 6a  |....c...6.\Z8..j|
00000020  71 42 de c4 7e 3c 90 8c  aa 9c 41 2b be 83 71 92  |qB..~<....A+..q.|
00000030  0a fe a7 2b ed 4d 52 a4  f0 7b c3 bb 7d b6 50 3f  |...+.MR..{..}.P?|
00000040  7e cb 5a c2 23 45 70 96  84 6a 6c da 09 3a 03 f2  |~.Z.#Ep..jl..:..|
00000050  78 c5 52 19 5f bb e4 76  26 2b 4d 05 90 60 b5 18  |x.R._..v&+M..`..|
00000060  28 54 df 20 81 0f a8 fe  59 2a 3c 3c e9 a5 27 bc  |(T. ....Y*<<..'.|
00000070  27 80 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |'...............|
# block 1 (this block was skipped)
00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 07 88  |................|

Action Plan

(Do not mark this bug completed until all tasks are complete)

[ ] Add workaround to driver to support multi-block HMAC with keyvault keys (#1528)
[ ] Add driver test-case for multi-block keyvault-based HMAC (#1527)
[ ] Add end-to-end test assertion for FMC derivations (#1526)
[ ] Add end-to-end test assertions for runtime/DPE derivations (TBD)
[ ] Add HMAC/keyvault/multiblock validation test to RTL (TBD)
[ ] Update hardware specification with keyvault/multiblock usage details (TBD)

chipsalliance / caliptra-sw