The hardware logic does not effectively handle when single-event upsets (SEUs) occur.
Modes of Introduction:
– Architecture and Design
Availability, Access Control: DoS: Crash, Exit, or Restart, DoS: Instability, Gain Privileges or Assume Identity, Bypass Protection Mechanism
Phase: Architecture and Design
Description:
Phase: Architecture and Design
Description:
The product allows address regions to overlap, which can result in the bypassing of intended memory protection.
Modes of Introduction:
– Architecture and Design
Confidentiality, Integrity, Availability: Modify Memory, Read Memory, DoS: Instability
Phase: Architecture and Design
Description:
Phase: Implementation
Effectiveness: High
Description:
The software reads from a buffer using buffer access mechanisms such as indexes or pointers that reference memory locations after the targeted buffer.
This typically occurs when the pointer or its index is incremented to a position beyond the bounds of the buffer or when pointer arithmetic results in a position outside of the valid memory location to name a few. This may result in exposure of sensitive information or possibly a crash.
Modes of Introduction:
– Implementation
Confidentiality: Read Memory
Confidentiality: Bypass Protection Mechanism
By reading out-of-bounds memory, an attacker might be able to get secret values, such as memory addresses, which can be bypass protection mechanisms such as ASLR in order to improve the reliability and likelihood of exploiting a separate weakness to achieve code execution instead of just denial of service.
The System-On-A-Chip (SoC) implements a Security Token mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Tokens are improperly protected.
Systems-On-A-Chip (Integrated circuits and hardware engines) implement Security Tokens to differentiate and identify which actions originated from which agent. These actions may be one of the directives: ‘read’, ‘write’, ‘program’, ‘reset’, ‘fetch’, ‘compute’, etc. Security Tokens are assigned to every agent in the System that is capable of generating an action or receiving an action from another agent. Multiple Security Tokens may be assigned to an agent and may be unique based on the agent’s trust level or allowed privileges. Since the Security Tokens are integral for the maintenence of security in an SoC, they need to be protected properly. A common weakness afflicting Security Tokens is improperly restricting the assignment to trusted components. Consequently, an improperly protected Security Token may be able to be programmed by a malicious agent (i.e., the Security Token is mutable) to spoof the action as if it originated from a trusted agent.
Modes of Introduction:
– Architecture and Design
Confidentiality, Integrity, Availability, Access Control: Modify Files or Directories, Execute Unauthorized Code or Commands, Bypass Protection Mechanism, Gain Privileges or Assume Identity, Modify Memory, Modify Memory, DoS: Crash, Exit, or Restart
Phase: Architecture and Design, Implementation
Description:
The hardware does not fully clear security-sensitive values, such as keys and intermediate values in cryptographic operations, when debug mode is entered.
Modes of Introduction:
– Architecture and Design
Confidentiality: Read Memory
Access Control: Bypass Protection Mechanism
Phase: Architecture and Design
Description:
Aliased or mirrored memory regions in hardware designs may have inconsistent read/write permissions enforced by the hardware. A possible result is that an untrusted agent is blocked from accessing a memory region but is not blocked from accessing the corresponding aliased memory region.
Modes of Introduction:
– Architecture and Design
Confidentiality: Read Memory
Integrity: Modify Memory
Availability: DoS: Instability
Phase: Architecture and Design, Implementation
Description:
The checks should be applied for consistency access rights between primary memory regions and any mirrored or aliased memory regions. If different memory protection units (MPU) are protecting the aliased regions, their protected range definitions and policies should be synchronized.
Phase: Architecture and Design, Implementation
Description:
The controls that allow enabling memory aliases or changing the size of mapped memory regions should only be programmable by trusted software components.
The product provides software-controllable
device functionality for capabilities such as power and
clock management, but it does not properly limit
functionality that can lead to modification of
hardware memory or register bits, or the ability to
observe physical side channels.
Modes of Introduction:
– Architecture and Design
Integrity: Modify Memory, Modify Application Data, Bypass Protection Mechanism
Phase: Architecture and Design, Implementation
Description:
A device’s real time power consumption may be monitored during security token evaluation and the information gleaned may be used to determine the value of the reference token.
Modes of Introduction:
– Architecture and Design
Confidentiality, Integrity, Availability, Access Control, Accountability, Authentication, Authorization, Non-Repudiation: Modify Memory, Read Memory, Read Files or Directories, Modify Files or Directories, Execute Unauthorized Code or Commands, Gain Privileges or Assume Identity, Bypass Protection Mechanism, Read Application Data, Modify Application Data, Hide Activities
As compromising a security token may result in complete system control, the impacts are relatively universal
Phase: Architecture and Design
Description:
The design phase must consider each check of a security token against a standard and the amount of power consumed during the check of a good token versus a bad token. The alternative is an all at once check where a retry counter is incremented PRIOR to the check.
Phase: Architecture and Design
Description:
Another potential mitigation is to parallelize shifting of secret data (see example 2 below). Note that the wider the bus the more effective the result.
Phase: Architecture and Design
Description:
An additional potential mitigation is to add random data to each crypto operation then subtract it out afterwards. This is highly effective but costly in performance, area, and power consumption. It also requires a random number generator.
Phase: Implementation
Description:
If the architecture is unable to prevent the attack, using filtering components may reduce the ability to implement an attack, however, consideration must be given to the physical removal of the filter elements.
Phase: Integration
Description:
During integration, avoid use of a single secret for an extended period (e.g. frequent key updates). This limits the amount of data compromised but at the cost of complexity of use.
The product’s comparison logic is performed over a series of steps rather than across the entire string in one operation. If there is a comparison logic failure on one of these steps, the operation may be vulnerable to a timing attack that can result in the interception of the process for nefarious purposes.
Modes of Introduction:
– Architecture and Design
Confidentiality, Authorization: Bypass Protection Mechanism
Phase: Implementation
Description:
The logic level used to set a system to a secure state relies on a fuse being unblown. An attacker can set the system to an insecure state merely by blowing the fuse.
Modes of Introduction:
– Architecture and Design
Access Control, Authorization: Bypass Protection Mechanism, Gain Privileges or Assume Identity
Availability: DoS: Crash, Exit, or Restart
Confidentiality: Read Memory
Integrity: Modify Memory, Execute Unauthorized Code or Commands
Phase: Architecture and Design
Description:
Logic should be designed in a way that blown fuses do not put the product into an insecure state that can be leveraged by an attacker.