Incorrect Conversion of Security Identifiers

Draft Base
Structure: Simple
Description

This vulnerability occurs when a hardware system incorrectly translates security identifiers during bus protocol conversion. An improper mapping allows untrusted agents to bypass security checks and gain unauthorized access to protected assets or functions.

Extended Description

In a System-on-Chip (SoC), different hardware components communicate via transactions that include security identifiers. These identifiers act like permissions, telling the receiving component what actions the sender is allowed to perform, such as reading or writing to a memory region. When a leader agent (e.g., using AHB protocol) needs to talk to a follower agent (e.g., using OCP protocol), a bridge performs a protocol conversion. If this bridge incorrectly maps or drops the security identifiers during translation, the transaction's permissions can be elevated or misrepresented. This flawed conversion creates a critical security gap. An untrusted or lower-privileged agent can send a transaction that, after incorrect translation, appears to have higher privileges than intended. The destination agent then grants unauthorized access based on this faulty security context, potentially leading to data exposure, corruption, or unauthorized control of hardware functions. The core issue is a mismatch between the intended security policy and its implementation in the protocol bridge.

Common Consequences 1
Scope: ConfidentialityIntegrityAvailabilityAccess Control

Impact: Modify MemoryRead MemoryDoS: Resource Consumption (Other)Execute Unauthorized Code or CommandsGain Privileges or Assume IdentityQuality Degradation

Potential Mitigations 2
Phase: Architecture and Design
Security identifier decoders must be reviewed for design inconsistency and common weaknesses.
Phase: Implementation
Access and programming flows must be tested in pre-silicon and post-silicon testing.
Demonstrative Examples 1
Consider a system that supports AHB. Let us assume we have a follower agent that only understands OCP. To connect this follower to the leader, a bridge is introduced, i.e., AHB to OCP. The follower has assets to protect accesses from untrusted leaders, and it employs access controls based on policy, (e.g., AES-Key registers for encryption or decryption). The key is 128 bits implemented as a set of four 32-bit registers. The key registers are assets, and register AES_KEY_ACCESS_POLICY is defined to provide the necessary access controls. The AES_KEY_ACCESS_POLICY access-policy register defines which agents with a security identifier in the transaction can access the AES-key registers. The implemented AES_KEY_ACCESS_POLICY has 4 bits where each bit when "Set" allows access to the AES-Key registers to the corresponding agent that has the security identifier. The other bits from 31 through 4 are reserved and not used. | | | | Register | Field Description | | AES_ENC_DEC_KEY_0 | AES key [0:31] for encryption or decryption Default 0x00000000 | | AES_ENC_DEC_KEY_1 | AES key [32:63] for encryption or decryption Default 0x00000000 | | AES_ENC_DEC_KEY_2 | AES key [64:95] for encryption or decryption Default 0x00000000 | | AES_ENC_DEC_KEY_3 | AES key [96:127] for encryption or decryption Default 0x00000000 | | AES_KEY_ACCESS_POLICY | [31:4] Default 0x000000 [3:0] - 0x02 agent with Security Identifier "1" has access to AES_ENC_DEC_KEY_0 through AES_ENC_DEC_KEY_4 registers | During conversion of the AHB-to-OCP transaction, the security identifier information must be preserved and passed on to the follower correctly.

Code Example:

Bad
Other

In AHB-to-OCP bridge, the security identifier information conversion is done incorrectly.

Because of the incorrect conversion, the security identifier information is either lost or could be modified in such a way that an untrusted leader can access the AES-Key registers.

Code Example:

Good
Other

The conversion of the signals from one protocol (AHB) to another (OCP) must be done while preserving the security identifier correctly.

Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Technologies:
Bus/Interface Hardware : UndeterminedNot Technology-Specific : Undetermined
Modes of Introduction
Architecture and Design
Implementation