CWE-1291 — Vulnerability Class 1

1 vulnerabilities classified as CWE-1291. AI Chinese analysis included.

CWE-1291 represents a critical cryptographic weakness where a single public key pair is utilized to sign both debug and production code artifacts. This practice fundamentally undermines the security model by allowing attackers to exploit the debug signing keys to inject malicious code into production environments. Since debug keys are often less rigorously protected and may be accessible to a broader range of personnel or build systems, adversaries can forge valid signatures for compromised binaries. To mitigate this risk, developers must enforce strict separation of duties by generating distinct, isolated key pairs for development and production phases. Implementing robust key management policies ensures that production verification relies exclusively on hardened, restricted keys, thereby preventing the unauthorized execution of tampered software and maintaining the integrity of the deployment pipeline.

MITRE CWE Description

The same public key is used for signing both debug and production code. A common usage of public-key cryptography is to verify the integrity and authenticity of another entity (for example a firmware binary). If a company wants to ensure that its firmware runs only on its own hardware, before the firmware runs, an encrypted hash of the firmware image will be decrypted with the public key and then verified against the now-computed hash of the firmware image. This means that the public key forms the root of trust, which necessitates that the public key itself must be protected and used properly. During the development phase, debug firmware enables many hardware debug hooks, debug modes, and debug messages for testing. Those debug facilities provide significant, additional views about the firmware's capability and, in some cases, additional capability into the chip or SoC. If compromised, these capabilities could be exploited by an attacker to take full control of the system. Once the product exits the manufacturing stage and enters production, it is good practice to use a different public key. Debug firmware images are known to leak. With the debug key being reused as the production key, the debug image will also work on the production image. Thus, it will open all the internal, debug capabilities to the attacker. If a different public key is used for the production image, even if the attacker gains access to the debug firmware image, they will not be able to run it on a produ…

Common Consequences (1)

Confidentiality, Integrity, Availability, Access Control, Accountability, Authentication, Authorization, Non-Repudiation, OtherRead Memory, Modify Memory, Execute Unauthorized Code or Commands, Gain Privileges or Assume Identity, Varies by Context

Mitigations (1)

ImplementationUse different keys for Production and Debug.

Examples (1)

This example illustrates the danger of using the same public key for debug and production.

Suppose the product design requires frugality of silicon real estate. Assume that originally the architecture allows just enough storage for two 2048-bit RSA keys in the fuse: one to be used for debug and the other for production. However, in the meantime, a business decision is taken to make the security future-proof beyond 2030, which means the architecture needs to use the NIST-recommended 3072-bit keys instead of the originally-planned 2048-bit keys. This means that, at most, one key can be fully stored in the fuses, not two. So the product design team decides to use the same public key fo

Bad · Other

Increase the storage so that two different keys of the required size can be stored.

Informative · Other

CVE ID	Title	CVSS	Severity	Published
CVE-2022-1665	IBM Power System 安全漏洞 — Red Hat Enterprise Linux	8.2	-	2022-06-21

Vulnerabilities classified as CWE-1291 represent 1 CVEs. The CWE taxonomy describes the weakness; review individual CVEs for product-specific impact.

Goal Reached Thanks to every supporter — we hit 100%!

CWE-1291 — Vulnerability Class 1