Leakage of intermediate SHA digest during HMAC Computation

[anujdubey91]

Summary

• Overview: Intermediate state leakage of KV keys is occurring through the HMAC core unit. The leakage was identified using the Radix tool from Cycuity with Synopsys VCS.

  • RTL version: v0.8 release

• Potential Consequences

  • FIPS 198-1 documents the importance of keeping intermediate states confidential.

  • An adversary intercepting this intermediate state can potentially exploit a length-extension attack to break the security of HMAC.

  • The HMAC core module is not securely composable outside the Caliptra design–someone reusing this unit for their own custom design may end up implementing a vulnerability if they do not block the intermediate state leakage in their wrapper module.

• Exploitability Risks: The current weakness is low risk because the intermediate state does not leak to the AHB. The leakage does not proceed past the HMAC core’s wrapper module.

• Potential Mitigation: We propose writing zeros on the tag output from the HMAC core until it becomes valid.

Detailed Analysis

We analyzed this behavior using Cycuity’s Radix tool, which analyzes weaknesses in a design based on user specified security rules. Radix was used to track the information flow from the key vault through the HMAC to identify this behavior.

Details of the analysis are described below.

Security Requirement: The keys stored in the key vault should not flow to the AHB Slave through crypto cores.

Radix Security Rule for the Security Requirement

SANITY : assert iflow( key_vault1.kv_reg1.field_storage.KEY_ENTRY*.data.value 
            =/=> 
            {
            key_vault1.hrdata_o,
            key_vault1.hresp_o, 
            key_vault1.hreadyout_o,
            hmac.hrdata_o,
            hmac.hresp_o, 
            hmac.hreadyout_o,
            sha256.hrdata_o,
            sha256.hresp_o, 
            sha256.hreadyout_o,
            sha512.hrdata_o,
            sha512.hresp_o, 
            sha512.hreadyout_o,
            ecc_top1.hrdata_o,
            ecc_top1.hresp_o, 
            ecc_top1.hreadyout_o
            });

Testcase executed: smoke_test_kv_hmac_flow test in Synopsys VCS with Radix’s security rule.

The following figure is from the Radix UI after simulation with VCS.

We observed that the hmac_core module does not confine the intermediate hash value to just itself, and instead lets it propagate to its wrapper module (hmac_inst).

Potential Mitigation

We propose to fix this by simply qualifying the hmac_core’s tag output with its valid signal.

Current Implementation ($CALIPTRA_ROOT/src/hmac/rtl/hmac_core.v: Line 108) assign tag = H2_digest; Suggested Implementation ($CALIPTRA_ROOT/src/hmac/rtl/hmac_core.v: Line 108) assign tag = digest_valid_reg ? H2_digest : ‘0;

[mojtaba-bisheh]

I couldn't see any leakage with wiring tag to wrapper module in the current architecture. The intermediate state (tag) is wired to wrapper module and then is registered with the valid signal. Hence the mentioned potential mitigation has been already implemented in the hmac_inst. The key-dependent information is not propagated to anywhere else until the hmac process is completed. When the valid signal goes high, the tag will be stored in the interface registers. That's aligned with FIPS requirements.

[anujdubey91]

Hi Mojtaba, Thanks for your response. Indeed, this is not an issue with the current implementation of Caliptra, but confining the tag to just the core cryptographic module helps with secure reusability of the design.

Specifically, the leakage stops at the hmac_inst, but we recommend stopping the leakage inside the hmac_core module itself (i.e., one level down). We would like to define the functionality of the two modules first before explaining why it is a good idea to confine the tag visibility to the hmac_core module. hmac_core: the module that computes the actual HMAC tag by invoking SHA-384 twice. It is the implementation of the HMAC cryptographic primitive. hmac_inst: a wrapper module for hmac_core that registers the final tag into software registers for further visibility to the upper modules.

The reason we suggest the fix should be implemented inside hmac_core is as follows. The hmac_core is a self-complete cryptographic module that contains all the functionality to compute an HMAC-based tag. Thus, it can be a potentially reusable cryptographic primitive for someone who just wants to add an HMAC unit in their design or in other customizations of Caliptra. It would be a problem if the user forgets to fix the leakage in the wrapper module or decides to not use a wrapper at all.

Generally speaking from a security standpoint, all the cryptographic primitives should only produce the final cryptographic value at its outputs, like the ciphertext from 10th round in AES-128, or the final hash value in SHA, etc. That keeps the module composable across designs and keeps its security independent of the implementation of a wrapping logic (if any).

As a final thought, the current implementation of Caliptra HMAC is safe for all practical purposes, but adding this fix will enhance the reusability of the cryptographic primitives from Caliptra.

[mojtaba-bisheh]

Since both agreed there is no leakage issue for the current design, and that fix just enhances the hmac core from reusability point of view in other architectures, we will consider it as a future enhancement. Thank you!

[anujdubey91]

Sounds good, Mojtaba. Thanks!

[anujdubey91]

Hey Mojtaba, While analyzing the ECC unit, I noticed that the same hmac_core module is reused as a DRBG for key generation in the hmac_drbg module. The behavior of intermediate hash state leakage also exists in this context. While the information flow is blocked in the hmac_drbg module in a similar manner as the independent HMAC subsystem, we would still suggest making the enhancement once at the HMAC core level since it seems this core is being reused in other contexts. That would only require one change, and fix this issue in any potential reuse scenarios.