Improper Management of Sensitive Trace Data

Draft Base
Structure: Simple
Description

Trace data collected from several sources on the System-on-Chip (SoC) is stored in unprotected locations or transported to untrusted agents.

Extended Description

To facilitate verification of complex System-on-Chip (SoC) designs, SoC integrators add specific IP blocks that trace the SoC's internal signals in real-time. This infrastructure enables observability of the SoC's internal behavior, validation of its functional design, and detection of hardware and software bugs. Such tracing IP blocks collect traces from several sources on the SoC including the CPU, crypto coprocessors, and on-chip fabrics. Traces collected from these sources are then aggregated inside trace IP block and forwarded to trace sinks, such as debug-trace ports that facilitate debugging by external hardware and software debuggers. Since these traces are collected from several security-sensitive sources, they must be protected against untrusted debuggers. If they are stored in unprotected memory, an untrusted software debugger can access these traces and extract secret information. Additionally, if security-sensitive traces are not tagged as secure, an untrusted hardware debugger might access them to extract confidential information.

Common Consequences 1
Scope: Confidentiality

Impact: Read Memory

An adversary can read secret values if they are captured in debug traces and stored unsafely.

Potential Mitigations 1
Phase: Implementation
Tag traces to indicate owner and debugging privilege level (designer, OEM, or end user) needed to access that trace.
Demonstrative Examples 1
In a SoC, traces generated from sources include security-sensitive IP blocks such as CPU (with tracing information such as instructions executed and memory operands), on-chip fabric (e.g., memory-transfer signals, transaction type and destination, and on-chip-firewall-error signals), power-management IP blocks (e.g., clock- and power-gating signals), and cryptographic coprocessors (e.g., cryptographic keys and intermediate values of crypto operations), among other non-security-sensitive IP blocks including timers and other functional blocks. The collected traces are then forwarded to the debug and trace interface used by the external hardware debugger.

Code Example:

Bad
Other

The traces do not have any privilege level attached to them. All collected traces can be viewed by any debugger (i.e., SoC designer, OEM debugger, or end user).

Code Example:

Good
Other

Some of the traces are SoC-design-house secrets, while some are OEM secrets. Few are end-user secrets and the rest are not security-sensitive. Tag all traces with the appropriate, privilege level at the source. The bits indicating the privilege level must be immutable in their transit from trace source to the final, trace sink. Debugger privilege level must be checked before providing access to traces.

References 2
Secure design-for-debug for Systems-on-Chip
Jerry Backer, David Hely, and Ramesh Karri
06-10-2015
ID: REF-1150
Secure and Flexible Trace-Based Debugging of Systems-on-Chip
Jerry Backer, David Hely, and Ramesh Karri
12-2016
ID: REF-1151
Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Technologies:
System on Chip : Undetermined
Modes of Introduction
Architecture and Design
Implementation
Related Weaknesses