The security-sensitive hardware module contains semiconductor defects.
Modes of Introduction:
– Manufacturing
Availability, Access Control: DoS: Instability
Phase: Testing
Description:
Phase: Operation
Description:
The device does not contain or contains incorrectly implemented circuitry or sensors to detect and mitigate voltage and clock glitches and protect sensitive information or software contained on the device.
Modes of Introduction:
– Operation
Confidentiality, Integrity, Availability, Access Control: Gain Privileges or Assume Identity, Bypass Protection Mechanism, Read Memory, Modify Memory, Execute Unauthorized Code or Commands
Phase: Architecture and Design, Implementation
Description:
The product does not implement or incorrectly implements wear leveling operations in limited-write non-volatile memories.
Modes of Introduction:
– Architecture and Design
Availability: DoS: Instability
Phase: Architecture and Design, Implementation, Testing
Effectiveness: High
Description:
Include secure wear leveling algorithms and ensure they may not be bypassed.
Faulty finite state machines (FSMs) in the hardware logic allow an attacker to put the system in an undefined state, to cause a denial of service (DoS) or gain privileges on the victim’s system.
Modes of Introduction:
– Architecture and Design
Availability, Access Control: Unexpected State, DoS: Crash, Exit, or Restart, DoS: Instability, Gain Privileges or Assume Identity
Phase: Architecture and Design, Implementation
Effectiveness: High
Description:
Define all possible states and handle all unused states through default statements. Ensure that system defaults to a secure state.
The product uses physical debug or test
interfaces with support for multiple access levels, but it
assigns the wrong debug access level to an internal asset,
providing unintended access to the asset from untrusted debug
agents.
Modes of Introduction:
– Architecture and Design
Confidentiality: Read Memory
Integrity: Modify Memory
Authorization, Access Control: Gain Privileges or Assume Identity, Bypass Protection Mechanism
Phase: Architecture and Design, Implementation
Effectiveness: High
Description:
Phase: Architecture and Design
Effectiveness: Limited
Description:
Apply blinding [REF-1219] or masking techniques in strategic areas.
Phase: Implementation
Effectiveness: Limited
Description:
Add shielding or tamper-resistant protections to the device, which increases the difficulty and cost for accessing debug/test interfaces.
Access to security-sensitive information stored in fuses is not limited during debug.
Modes of Introduction:
– Architecture and Design
Confidentiality, Access Control: Modify Memory, Bypass Protection Mechanism
Phase: Architecture and Design, Implementation
Description:
The device includes chicken bits or undocumented features that can create entry points for unauthorized actors.
Modes of Introduction:
– Architecture and Design
Confidentiality, Integrity, Availability, Access Control: Modify Memory, Read Memory, Execute Unauthorized Code or Commands, Gain Privileges or Assume Identity, Bypass Protection Mechanism
Phase: Architecture and Design, Implementation
Effectiveness: High
Description:
The device uses an algorithm that is predictable and generates a pseudo-random number.
Modes of Introduction:
– Architecture and Design
Confidentiality: Read Application Data
Phase: Architecture and Design
Description:
A true random number generator should be specified for cryptographic algorithms.
Phase: Implementation
Description:
A true random number generator should be implemented for cryptographic algorithms.
To fulfill the need for a cryptographic primitive, the product implements a cryptographic algorithm using a non-standard, unproven, or disallowed/non-compliant cryptographic implementation.
Modes of Introduction:
– Architecture and Design
Confidentiality: Read Application Data
Incorrect usage of crypto primitives could render the supposedly encrypted data as unencrypted plaintext in the worst case.
Phase: Requirements
Effectiveness: High
Description:
Require compliance with the strongest-available recommendations from trusted parties, and require that compliance must be kept up-to-date, since recommendations evolve over time. For example, US government systems require FIPS 140-3 certification, which supersedes FIPS 140-2 [REF-1192] [REF-1226].
Phase: Architecture and Design
Effectiveness: High
Description:
Ensure that the architecture/design uses the strongest-available primitives and algorithms from trusted parties. For example, US government systems require FIPS 140-3 certification, which supersedes FIPS 140-2 [REF-1192] [REF-1226].
Phase: Architecture and Design
Effectiveness: Discouraged Common Practice
Description:
Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. As with all cryptographic mechanisms, the source code should be available for analysis. If the algorithm may be compromised when attackers find out how it works, then it is especially weak.
Phase: Architecture and Design
Effectiveness: Discouraged Common Practice
Description:
Try not to use cryptographic algorithms in novel ways or with new modes of operation even when you “know” it is secure. For example, using SHA-2 chaining to create a 1-time pad for encryption might sound like a good idea, but one should not do this.
Phase: Architecture and Design
Effectiveness: Defense in Depth
Description:
Ensure that the design can replace one cryptographic primitive or algorithm with another in the next generation (“cryptographic agility”). Where possible, use wrappers to make the interfaces uniform. This will make it easier to upgrade to stronger algorithms. This is especially important for hardware, which can be more difficult to upgrade quickly than software; design the hardware at a replaceable block level.
Phase: Architecture and Design
Effectiveness: Discouraged Common Practice
Description:
Do not use outdated or non-compliant cryptography algorithms. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong [REF-267].
Phase: Architecture and Design, Implementation
Effectiveness: Discouraged Common Practice
Description:
Do not use a linear-feedback shift register (LFSR) or other legacy methods as a substitute for an accepted and standard Random Number Generator.
Phase: Architecture and Design, Implementation
Effectiveness: Discouraged Common Practice
Description:
Do not use a checksum as a substitute for a cryptographically generated hash.
Phase: Architecture and Design
Effectiveness: High
Description:
Use a vetted cryptographic library or framework. Industry-standard implementations will save development time and are more likely to avoid errors that can occur during implementation of cryptographic algorithms. However, the library/framework could be used incorrectly during implementation.
Phase: Architecture and Design, Implementation
Effectiveness: Moderate
Description:
When using industry-approved techniques, use them correctly. Don’t cut corners by skipping resource-intensive steps (CWE-325). These steps are often essential for the prevention of common attacks.
Phase: Architecture and Design, Implementation
Effectiveness: Moderate
Description:
Do not store keys in areas accessible to untrusted agents. Carefully manage and protect the cryptographic keys (see CWE-320). If the keys can be guessed or stolen, then the strength of the cryptography algorithm is irrelevant.
The software writes to a buffer using an index or pointer that references a memory location prior to the beginning of the buffer.
This typically occurs when a pointer or its index is decremented to a position before the buffer, when pointer arithmetic results in a position before the beginning of the valid memory location, or when a negative index is used.
Modes of Introduction:
– Architecture and Design
Likelihood of Exploit: Medium
Integrity, Availability: Modify Memory, DoS: Crash, Exit, or Restart
Out of bounds memory access will very likely result in the corruption of relevant memory, and perhaps instructions, possibly leading to a crash.
Integrity, Confidentiality, Availability, Access Control, Other: Execute Unauthorized Code or Commands, Modify Memory, Bypass Protection Mechanism, Other
If the corrupted memory can be effectively controlled, it may be possible to execute arbitrary code. If the corrupted memory is data rather than instructions, the system will continue to function with improper changes, possibly in violation of an implicit or explicit policy. The consequences would only be limited by how the affected data is used, such as an adjacent memory location that is used to specify whether the user has special privileges.
Access Control, Other: Bypass Protection Mechanism, Other
When the consequence is arbitrary code execution, this can often be used to subvert any other security service.
Phase: Requirements
Description:
Choose a language that is not susceptible to these issues.
Phase: Implementation
Description:
All calculated values that are used as index or for pointer arithmetic should be validated to ensure that they are within an expected range.