Common Weakness Enumeration

Integrated circuits and hardware engines may provide access to resources (device-configuration, encryption keys, etc.) belonging to trusted firmware or software modules (commonly set by a BIOS or a bootloader). These accesses are typically controlled and limited by the hardware. Hardware design access control is sometimes implemented using a policy. A policy defines which entity or agent may or may not be allowed to perform an action. When a system implements multiple levels of policies, a control policy may allow direct access to a resource as well as changes to the policies themselves.

Resources that include agents in their control policy but not in their write policy could unintentionally allow an untrusted agent to insert itself in the write policy register. Inclusion in the write policy register could allow a malicious or misbehaving agent write access to resources. This action could result in security compromises including leaked information, leaked encryption keys, or modification of device configuration.

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)

Nature	Type	ID	Name
ChildOf	Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.	284	Improper Access Control

Relevant to the view "Hardware Design" (CWE-1194)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1198	Privilege Separation and Access Control Issues

Languages

Operating Systems

Architectures

Technologies

Example 1

Consider a system with a register for storing an AES key for encryption or decryption. The key is composed of 128 bits implemented as a set of four 32-bit registers. The key registers are resources and registers, AES_KEY_CONTROL_POLICY, AES_KEY_READ_POLICY and AES_KEY_WRITE_POLICY, and are defined to provide necessary, access controls.

The control-policy register defines which agents can write to the read-policy and write-policy registers. The read-policy register defines which agents can read the AES-key registers, and write-policy register defines which agents can program or write to those registers. Each 32-bit register can support access control for a maximum of 32 agents. 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.

In the above example, the AES_KEY_CONTROL_POLICY register has agents with identities "4"and "3" in its policy. Assuming the agent with identity "4" is trusted and the agent with identity "3" is untrusted. The untrusted agent "3" can write to AES_KEY_WRITE_POLICY with a value of 0x0000000C thus allowing write access to AES_ENC_DEC_KEY_0 through AES_ENC_DEC_KEY_3 registers.

1. The AES_KEY_CONTROL_POLICY defines which agents have write access to the AES_KEY_CONTROL_POLICY, AES_KEY_READ_POLICY, and the AES_KEY_WRITE_POLICY registers,
2. The AES-key registers can only be read or used by a crypto agent with identity "1" when bit #1 is set.
3. The AES-key registers can only be programmed by a trusted firmware with identity "2" when bit #2 is set.

For the above example, the control, read-and-write-policy registers’ values are defined as below.

Maintenance