Bug 06 - Lifecycle Token Hash Compared Only on Lower 32 Bits (2^128 - 2^32)
Legacy reference: Bug #3 in the working set
Security feature bypassed
Lifecycle Controller token authentication - the KMAC-based 128-bit hash comparison gating all LC state transitions
Attack type
Type 2 - physical attacker with LC transition interface access
Finding
The 128-bit KMAC hash is compared only on its lower 32 bits. Both hashed_token_i and
hashed_token_mux are declared lc_token_t (128 bits), but the equality test uses [31:0],
reducing effective security from 2^128 to 2^32:
// lc_ctrl_fsm.sv:456 and :497
if (hashed_token_i[31:0] == hashed_token_mux[31:0] &&
!token_hash_err_i &&
&hashed_token_valid_mux) begin
Type declaration (lc_ctrl_state_pkg.sv:412-413): parameter int LcTokenWidth = 128;
Location or code reference
- hw/ip/lc_ctrl/rtl/lc_ctrl_fsm.sv:456 -
hashed_token_i[31:0] == hashed_token_mux[31:0](32-bit compare) - hw/ip/lc_ctrl/rtl/lc_ctrl_fsm.sv:497 - second comparison site with the same 32-bit truncation
- hw/ip/lc_ctrl/rtl/lc_ctrl_state_pkg.sv:412-413 -
LcTokenWidth = 128- the declared token width
New Tools
Yes - custom VCS (U-2023.03) token-matching fuzzer: generated token pairs differing in the
upper 96 bits but matching in the lower 32 bits; the buggy check accepts them, the correct
128-bit check rejects them. Verified with a directed testbench on the real lc_ctrl_fsm RTL
(tb_bug03_lc_fsm.sv, PROD-RMA transition, forged token accepted - see
exploit/logs/bug-003-lc-fsm-vcs-simulation.log). A standalone comparison testbench
(bug-003-tb-token-trunc.sv) exercised 100+ token pairs.
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 VCS fuzzing + manual width audit: compared the declared signal widths (128 bits)
against the bit-select in the equality expression ([31:0] = 32 bits). Confirmed on the real
lc_ctrl_fsm RTL - a token differing only in the upper 96 bits passes the buggy check and
authorizes the transition.
Security impact
Attacker brute-force reduced from 2^128 to 2^32 guesses (~4.3 × 10^9). Enables unauthorized LC transitions (RAW-TEST_UNLOCKED0, DEV-RMA, PROD-PROD_END). The OTP transition counter limits per-device attempts to 24, but multi-device attacks become feasible and the stated 128-bit security goal is violated.
Adversary profile
Type 2 - physical attacker with access to the LC transition interface (OTP token inputs) and the computational ability to brute-force 2^32.
Proposed mitigation
Compare the full hash width:
if (hashed_token_i == hashed_token_mux &&
!token_hash_err_i &&
&hashed_token_valid_mux) begin
CVSSv3.1 score and severity
6.4 - MEDIUM
CVSSv3.1 Details
CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H
- AV: Local - token inputs driven at the LC interface
- AC: High - requires 2^32 brute-force work
- PR: High - access to token interface / OTP
- S: Unchanged - within the LC domain
- C/I/A: High - unauthorized state transitions
Attachment links
Located in this repository (GitHub is the cloud storage for the submission):