Bug 03 - Key Manager Source-Key Validity Gating Bypass
Legacy reference: Bug #10 in the working set
Security feature bypassed
Key Manager source-key validity gating - the key_i.valid trust bit carried by hw_key_req_t
Attack type
Type 1 - unprivileged software
Finding
In keymgr_input_checks.sv, key_i.valid is captured into a wire named unused_key_vld
(a standard lint-suppression idiom) and is never included in the key_vld_o computation.
The validity output depends solely on a content check (&key_chk) that only rejects all-zero
and all-ones keys:
// keymgr_input_checks.sv:80-81
logic unused_key_vld;
assign unused_key_vld = key_i.valid; // DISCARDED - lint suppression
// keymgr_input_checks.sv:99
assign key_vld_o = &key_chk; // key_i.valid NOT included
Contrast with the correct rom_digest handling at line 104:
rom_digest_vld_o &= rom_digest_i[k].valid && valid_chk(...);
If a key source (OTP / flash) signals valid=0 while key bytes are partially programmed
(non-zero, non-all-ones), the Key Manager still derives session keys from that unvalidated
material.
Location or code reference
- hw/ip/keymgr/rtl/keymgr_input_checks.sv:80-81 -
unused_key_vld = key_i.valid- the trust bit is discarded as lint-suppression - hw/ip/keymgr/rtl/keymgr_input_checks.sv:99 -
assign key_vld_o = &key_chk;- key_i.valid NOT included - hw/ip/keymgr/rtl/keymgr_input_checks.sv:104 - correct reference: rom_digest validity DOES include the valid bit
New Tools
Yes - custom HWF-AFL pipeline (coverage-guided AFL++ 4.09c + Verilator 4.210), differential fuzzing mode:
- Two minimal Verilator models: buggy (exact RTL logic) and fixed (
key_vld_o = key_i.valid & &key_chk) - Both instantiated side-by-side in a wrapper; AFL feeds identical random inputs (valid bit + 2×256-bit key shares)
- Any
key_vld_omismatch triggersabort()(SIGABRT); AFL records the crash input
Result: 2 unique crash inputs found within 60 s from safe seeds - both valid_i=0 with key
shares passing the content check: buggy returns 1, fixed correctly returns 0.
AI Tools
No.
LLM
No.
LLM Details
PLACEHOLDER - to be completed (model name/version, parameters, download link or API endpoint).
Online LLM Details
PLACEHOLDER - to be completed (input/output/total token counts, verification script).
LLM Prompts
PLACEHOLDER - to be completed (complete prompt, full model response, step-by-step explanation).
Detection method
Automated detection with the HWF-AFL differential fuzzer (security property: key_vld_o
must be 0 whenever key_i.valid=0). Finding then confirmed on the actual OpenTitan RTL:
keymgr_input_checks_tb.sv instantiates the real keymgr_input_checks.sv with its genuine
dependency chain and observes key_vld_o=1 while key_i.valid=0
(see testbench/logs/rtl-test-simulation.log: *** BUG #10 CONFIRMED on actual OpenTitan RTL ***).
Security impact
Session keys are derived from unvalidated / attacker-influenced key material. AES, HMAC, KMAC and OTBN keys derived from attacker-controlled source material; known-key scenarios enable cryptanalysis of supposedly secure channels. A software attacker can write key material to the source registers, configure shares to pass the content check, and trigger derivation via the CONTROL register.
Adversary profile
Type 1 - unprivileged software on the Ibex core with MMIO access to the Key Manager (0x41100000). Fully software-driven; no physical access.
Proposed mitigation
assign key_vld_o = key_i.valid & &key_chk;
CVSSv3.1 score and severity
5.5 - MEDIUM
CVSSv3.1 Details
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
- AV: Local - requires code execution on the core
- PR: Low - user-level software with MMIO access
- S: Unchanged - key derivation within the Key Manager domain
- C: High - confidentiality of derived keys compromised
Attachment links
Located in this repository (GitHub is the cloud storage for the submission):