We identified a potential security issue in the aes0_wrapper module of the Hack@DAC21 design that does not appear in the documented bug list. Specifically, the AES key material does not appear to be cleared on reset.
Using Cadence JasperGold FPV, we constructed a trace demonstrating that:
- Reset occurs
- No key write happens after reset
- AES encryption is initiated
- The key used is non-zero and originates from pre-reset state
- The key is actively used in the AES computation
This indicates that key material is retained and reused across reset.
From a security perspective, this violates a commonly expected property: Cryptographic key material should be cleared upon reset.
For comparison, other AES implementations explicitly clear key on reset. For example: https://github.com/secworks/aes/blob/master/src/rtl/aes.v
In this implementation, key registers are explicitly cleared on reset.
Could you clarify whether this behavior is:
- An intended design choice,
- A bug that was unintentionally omitted from the documented bug list, or
- A bug native to the design?
We can provide the full JasperGold trace and assertion upon request. Thanks!
We identified a potential security issue in the aes0_wrapper module of the Hack@DAC21 design that does not appear in the documented bug list. Specifically, the AES key material does not appear to be cleared on reset.
Using Cadence JasperGold FPV, we constructed a trace demonstrating that:
This indicates that key material is retained and reused across reset.
From a security perspective, this violates a commonly expected property: Cryptographic key material should be cleared upon reset.
For comparison, other AES implementations explicitly clear key on reset. For example: https://github.com/secworks/aes/blob/master/src/rtl/aes.v
In this implementation, key registers are explicitly cleared on reset.
Could you clarify whether this behavior is:
We can provide the full JasperGold trace and assertion upon request. Thanks!