Closed LuiSzee closed 4 months ago
Thanks @LuiSzee, we're taking a look. I'll update you as soon as I know more.
Incorrect derivation confirmed on FPGA in #1526 :
thread 'smoke_test::smoke_test' panicked at 'assertion failed: expected_rt_alias_key.derive_public_key().public_eq(&rt_alias_cert.public_key().unwrap())', test/tests/caliptra_integration_tests/smoke_test.rs:430:5
Passes in emulator. I'm pretty sure this is because the FMC is using a 96-byte kdf context, which leads to a 113-byte HMAC operation, which triggers a second padding block, which the hardware doesn't like. The ROM uses a 48-byte kdf context (PCR0) that doesn't trigger this problem.
Will follow up with some lower level tests.
If the block data extends beyond a single block, the key from KV will get cleared from the HMAC and needs to be re-loaded from the KV for the next block iteration. I believe the internal state of HMAC is maintained (we don't zeroize everything) after a KV transaction, so reloading the key should work.
Nitsirks: Where is this procedure documented?
Apparently it is not. I just checked the hardware specification and keyvault section does not mention the clearing of secrets after use.
I'll get this updated asap.
This feature came after an ask some time last year to ensure a key from the keyvault could never be used to generate a firmware readable digest, as that could expose device secrets.
Postmortem for this issue: #1550
Hello, I am doing the fmc::test_hand_off test and found that the RT Cert obtained from the sw-emulator is inconsistent with that on verilator. Before conducting the test, I made the following modifications in order to ensure that the Caliptra Image remains consistent throughout multiple runs. Additionally, I have printed the tci value.
When running for the first time, I used the command "cargo test --package caliptra-fmc --test fmc_integration_tests -- test_hand_off::test_hand_off --exact --nocapture" And I got RT Cert:
When running for the second time, I made modifications to the "sw-emulator/lib/crypto/src/hmac512.rs" by renaming the "update" function to "orig_update" and calling it in the "init" function. I also implemented an empty function for the original "update" function, so that the sw-emulator only processes the first block.
And I got RT Cert:
On the third run, I used "cargo test --features=verilator --package caliptra-fmc --test fmc_integration_tests -- test_hand_off::test_hand_off --exact --nocapture". ran the same case using verilator. And I got RT Cert:
The result is the same as the second time, but the second time I ran the modified sw-emulator code, and the hmac only processed the first block. Therefore, I suspect that there may be a problem with the key vault-related code in the caliptra-rtl hmac, and I raised an issue: https://github.com/chipsalliance/caliptra-rtl/issues/515 At the same time, I checked the code of the sw-emulator, and personally, I think there is no problem with the implementation of hmac512.rs in the sw-emulator. Please help confirm whether the inconsistency here is caused by an error in the implementation of sw-emulator in caliptra-sw or an error in the implementation of caliptra-rtl. Thank you.
My Full log: