Insufficient Granularity of Access Control
The product implements access controls via a policy or other feature with the intention to disable or restrict accesses (reads and/or writes) to assets in a system from untrusted agents. However, implemented access controls lack required granularity, which renders the control policy too broad because it allows accesses from unauthorized agents to the security-sensitive assets.
Description
Integrated circuits and hardware engines can expose accesses to assets (device configuration, keys, etc.) to trusted firmware or a software module (commonly set by BIOS/bootloader). This access is typically access-controlled. Upon a power reset, the hardware or system usually starts with default values in registers, and the trusted firmware (Boot firmware) configures the necessary access-control protection.
A common weakness that can exist in such protection schemes is that access controls or policies are not granular enough. This condition allows agents beyond trusted agents to access assets and could lead to a loss of functionality or the ability to set up the device securely. This further results in security risks from leaked, sensitive, key material to modification of device configuration.
Demonstrations
The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.
Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.
Example One
Consider a system with a register for storing AES key for encryption or decryption. The key is 128 bits, implemented as a set of four 32-bit registers. The key registers are assets and registers, AES_KEY_READ_POLICY and AES_KEY_WRITE_POLICY, and are defined to provide necessary access controls.
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 register is a 32-bit register, and it 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.
RegisterField descriptionAES_ENC_DEC_KEY_0AES key [0:31] for encryption or decryption
Default 0x00000000AES_ENC_DEC_KEY_1AES key [32:63] for encryption or decryption
Default 0x00000000AES_ENC_DEC_KEY_2AES key [64:95] for encryption or decryption
Default 0x00000000AES_ENC_DEC_KEY_4AES key [96:127] for encryption or decryption
Default 0x00000000AES_KEY_READ_WRITE_POLICY[31:0] Default 0x00000006 - meaning agent with identities "1" and "2" can both read from and write to key registersIn the above example, there is only one policy register that controls access to both read and write accesses to the AES-key registers, and thus the design is not granular enough to separate read and writes access for different agents. Here, agent with identities "1" and "2" can both read and write.
A good design should be granular enough to provide separate access controls to separate actions. Access control for reads should be separate from writes. Below is an example of such implementation where two policy registers are defined for each of these actions. The policy is defined such that: the AES-key registers can only be read or used by a crypto agent with identity "1" when bit #1 is set. The AES-key registers can only be programmed by a trusted firmware with identity "2" when bit #2 is set.
AES_KEY_READ_POLICY[31:0] Default 0x00000002 - meaning only Crypto engine with identity "1" can read registers: AES_ENC_DEC_KEY_0, AES_ENC_DEC_KEY_1, AES_ENC_DEC_KEY_2, AES_ENC_DEC_KEY_3AES_KEY_WRITE_POLICY[31:0] Default 0x00000004 - meaning only trusted firmware with identity "2" can program registers: AES_ENC_DEC_KEY_0, AES_ENC_DEC_KEY_1, AES_ENC_DEC_KEY_2, AES_ENC_DEC_KEY_3Example Two
Consider the following SoC design. The sram in HRoT has an address range that is readable and writable by unprivileged software and it has an area that is only readable by unprivileged software. The tbus interconnect enforces access control for slaves on the bus but uses only one bit to control both read and write access. Address 0xA0000000 - 0xA000FFFF is readable and writable by the untrusted cores core{0-N} and address 0xA0010000 - 0xA001FFFF is only readable by the untrusted cores core{0-N}.
The security policy access control is not granular enough, as it uses one bit to enable both read and write access. This gives write access to an area that should only be readable by unprivileged agents.
Access control logic should differentiate between read and write access and to have sufficient address granularity.
See Also
Weaknesses in this category are related to access control.
Weaknesses in this category are related to authorization components of a system. Frequently these deal with the ability to enforce that agents have the required permis...
Weaknesses in this category are related to features and mechanisms providing hardware-based isolation and access control (e.g., identity, policy, locking control) of s...
This view (slice) covers all the elements in CWE.
This view (slice) lists weaknesses that can be introduced during implementation.
This view (slice) lists weaknesses that can be introduced during design.
Common Weakness Enumeration content on this website is copyright of The MITRE Corporation unless otherwise specified. Use of the Common Weakness Enumeration and the associated references on this website are subject to the Terms of Use as specified by The MITRE Corporation.