CWE-1270: Generation of Incorrect Security Identifiers
The product implements a Security Identifier mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Identifiers generated in the system are incorrect.
Systems-On-Chip (Integrated circuits and hardware engines) implement Security Identifiers to differentiate/identify actions originated from various agents. These actions could be ‘read’, ‘write’, ‘program’, ‘reset’, ‘fetch’, ‘compute’, etc. Security identifiers are generated and assigned to every agent in the System (SoC) that is either capable of generating an action or receiving an action from another agent. Every agent could be assigned a unique, Security Identifier based on its trust level or privileges. Hence the generation of the Security Identifiers is very important to achieve security in the SoC. A common weakness that can exist is that the generated Security Identifiers are incorrect. Consequently, the same agent may have multiple identifiers or multiple agents may have the same security identifier. In either case, the security consequences could be a Denial-of-Service (DoS) or execution of an action that in turn could result in privilege escalation or unintended access.
The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Class: Language-Independent (Undetermined Prevalence)
Class: OS-Independent (Undetermined Prevalence)
Class: Architecture-Independent (Undetermined Prevalence)
Processor IP Class: Technology-Independent (Undetermined Prevalence)
The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
For example, consider a system with a register for storing AES key for encryption or decryption. The key is of 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 necessary access controls. 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 access to the AES-key registers. The number of the bit when set (i.e., “1”) allows respective action from an agent whose identity matches the number of the bit and, if “0” (i.e., Clear), disallows the respective action to that corresponding agent.
Let’s assume the system has two agents: a Main-controller and an Aux-controller. The respective Security Identifiers are “1” and “2”.
An agent with Security Identifier “1” has access to AES_ENC_DEC_KEY_0 through AES_ENC_DEC_KEY_3 registers. As per the above access policy, the AES-Key-access policy allows access to the AES-key registers if the security identifier is “1”.
Example Language: Other
The SoC incorrectly generates cSecurity Identifier “1” for every agent. In other words, both Main-controller and Aux-controller are assigned Security Identifier "1".
Both agents have access to the AES-key registers.
Example Language: Other
The SoC should correctly generate Security Identifiers, assigning "1" to the Main-controller and "2" to the Aux-controller
More information is available — Please select a different filter.