2174
The access-policy register defines which agents with a security identifier in the transaction can
access the AES-key registers. Each bit in this 32-bit register defines a security identifier. There
could be a maximum of 32 security identifiers that are allowed accesses to the AES-key registers.
The number of the bit when set (i.e., "1") allows for a respective action from an agent whose
identity matches the number of the bit; if set to "0" (i.e., Clear), it disallows the respective action to
that corresponding agent.
Example Language: (Bad)
The originator sends a transaction with no security identifier, i.e., meaning the value is "0" or NULL.
The AES-Key-access register does not allow the necessary action and drops the transaction
because the originator failed to include the required security identifier.
Example Language: (Good)
The originator should send a transaction with Security Identifier "2" which will allow access to the
AES-Key-access register and allow encryption and decryption operations.
MemberOf Relationships
This MemberOf relationships table shows additional CWE Catgeories and Views that reference this
weakness as a member. This information is often useful in understanding where a weakness fits
within the context of external information sources.
Nature Type ID Name Page
MemberOf 1198 Privilege Separation and Access Control Issues 1194 2470
MemberOf 1396 Comprehensive Categorization: Access Control 1400 2519
Related Attack Patterns
CAPEC-ID Attack Pattern Name
121 Exploit Non-Production Interfaces
681 Exploitation of Improperly Controlled Hardware Security Identifiers
CWE-1303: Non-Transparent Sharing of Microarchitectural Resources
Weakness ID : 1303
Structure : Simple
Abstraction : Base
Description
Hardware structures shared across execution contexts (e.g., caches and branch predictors) can
violate the expected architecture isolation between contexts.
Extended Description
Modern processors use techniques such as out-of-order execution, speculation, prefetching,
data forwarding, and caching to increase performance. Details about the implementation of these
techniques are hidden from the programmer's view. This is problematic when the hardware
implementation of these techniques results in resources being shared across supposedly isolated
contexts. Contention for shared resources between different contexts opens covert channels that
allow malicious programs executing in one context to recover information from another context.
Some examples of shared micro-architectural resources that have been used to leak information
between contexts are caches, branch prediction logic, and load or store buffers. Speculative
CWE Version 4.14
CWE-1303: Non-Transparent Sharing of Microarchitectural Resources
CWE-1303: Non-Transparent Sharing of Microarchitectural Resources