logo

Incorrect Conversion of Security Identifiers

Draft Base
Structure: Simple
Description

The product implements a conversion mechanism to map certain bus-transaction signals to security identifiers. However, if the conversion is incorrectly implemented, untrusted agents can gain unauthorized access to the asset.

Extended Description

In a System-On-Chip (SoC), various integrated circuits and hardware engines generate transactions such as to access (reads/writes) assets or perform certain actions (e.g., reset, fetch, compute, etc.). Among various types of message information, a typical transaction is comprised of source identity (to identify the originator of the transaction) and a destination identity (to route the transaction to the respective entity). Sometimes the transactions are qualified with a security identifier. This security identifier helps the destination agent decide on the set of allowed actions (e.g., access an asset for read and writes). A typical bus connects several leader and follower agents. Some follower agents implement bus protocols differently from leader agents. A protocol conversion happens at a bridge to seamlessly connect different protocols on the bus. One example is a system that implements a leader with the Advanced High-performance Bus (AHB) protocol and a follower with the Open-Core Protocol (OCP). A bridge AHB-to-OCP is needed to translate the transaction from one form to the other. A common weakness that can exist in this scenario is that this conversion between protocols is implemented incorrectly, whereupon an untrusted agent may gain unauthorized access to an asset.

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
Related Weaknesses
ChildOf: Improper Access Control (CWE-284)
ChildOf: Insecure Security Identifier Mechanism (CWE-1294)