CWE-1243 describes chips where debug access is not restricted for security-sensitive data that originates in fuses. Chip designers and SoC integrators are the audience. If you ship firmware on such a chip, it also matters to you, because your secrets may be reachable by anyone with a debugger.
How it happens
Fuses hold some of a chip's most sensitive values: root keys, encryption keys, manufacturing information, chip-manufacturer data and OEM data. When the chip powers on, those values are sensed from the fuses and copied into temporary registers and local memories for use during early boot and runtime.
Those temporary locations are normally protected. Untrusted agents are blocked, and even trusted agents usually get read-only access. The gap appears when the same locations are still wired to the debug interface.
MITRE gives two illustrations.
- Manufacturing data such as die information is read from fuses into microarchitectural registers. Software cannot touch them, but every register in the chip can be reached through debug, so even an untrusted debugger can retrieve it.
- An AES accelerator in a buggy contest SoC senses three AES keys from fuses at boot and stores them in registers key0, key1 and key2. The design is supposed to disconnect those registers during the debug state, and the vulnerable version fails to do so.
What an attacker gains
If those locations are not blocked during debug operations, a user can access the sensitive information. MITRE lists confidentiality, access control, reading and modifying memory, and bypassing protection mechanisms. A leaked root or encryption key undermines everything the key was protecting, not just one device function.
How to find it
The record lists no detection methods. A practical review looks like this:
- Make a list of every value that is loaded from fuses.
- Trace every register or memory that receives each value.
- For each one, check what the debug interface can reach in each debug state.
- Test with a debugger attached, as an untrusted user would.
How to fix it
MITRE's mitigation applies at design and implementation. Disable access to security-sensitive information stored in fuses, both directly and as reflected in temporary storage, when in debug mode.
The good example in the entry is specific. Registers that store sensitive values read from fuses should be blocked during debug and disconnected from the debug interface.
Quick check
Why are the temporary registers a problem if software cannot read them?
Because the debug interface may bypass the software access controls. A debugger attached to the chip can reach registers that software is blocked from.
What is the fix in one sentence?
Disconnect the registers holding fuse-derived secrets from the debug interface while debug mode is active.