CWE

Common Weakness Enumeration

A Community-Developed List of Software & Hardware Weakness Types

CWE Top 25 Most Dangerous Software Errors
Home > CWE List > CWE- Individual Dictionary Definition (4.1)  
ID

CWE-1279: Cryptographic Primitives used without Successful Self-Test

Weakness ID: 1279
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
Using crypto primitives without ensuring that they have passed the self-tests might result in the exposure of sensitive information and/or other consequences.
+ Extended Description

Cryptographic primitives are hardware units that are supposed to perform certain cryptographic tasks. As is the case with many systems, for both hardware and software, in order to perform correctly, a system must first attain a certain state that can be considered a valid, starting point. In other words, it can be stated that the system has now been properly initialized. However, in order to reach this valid, initial state, the system needs to have performed certain tasks and/or obtained certain other data from other parts of the system. For example, a cryptographic unit that depends on an external, random-number-generator (RNG) unit for entropy must get a signal from the RNG unit that the RNG unit is ready to supply random numbers if asked. Or maybe a symmetric, cryptographic unit retrieves its private encryption key from a fuse unit; hence, it must ensure that the fuse unit is up and running before it can pull the fuse with the corresponding key.

However, even when the system reaches this supposedly valid, initial state, the system must “validate” that this state is indeed valid. To do this, the system performs a series of tests and compares the result with the expected values. This test is often called Power-On Self-Test (POST), Built-In Self-test (BIST), or just self-test in short. If the results of the self-test do not match the expected values, then the system assumes that something went wrong with the initialization process, and, resultingly, the system can no longer be trusted to perform its tasks reliably.

To ensure the sanctity of the self-test process, when the self-test goes on, usually the regular input, output, and other external interfaces are not made available.

+ Relationships

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)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.665Improper Initialization
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1205Security Primitives and Cryptography Issues
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and Design
ImplementationThe decision to continue using a crypto primitive despite unsuccessful self-test may be taken at any phase. As is the case with any process, any extra logic costs silicon real estate and resources. For example, in order to properly perform self-tests, one must store the “expected answers” somewhere. If there are many such answers that need to be stored, that consumes precious, non-volatile-storage space. An architect who wants to keep the silicon footprint to a minimum at any cost might choose to forego the self-test infrastructure. Or, it might be possible that silicon real estate is not a problem, but latency is – the crypto system must be up and running as soon as possible, and self-test takes time to execute. Therefore, a decision might be taken later that self-tests may be omitted to hasten up the boot process. Another possible scenario could be where the self-test is allowed to run, but, even if the result is not 100% correct, the system is still allowed to be used for business reasons (where the crypto system is not in the critical path).
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Verilog (Undetermined Prevalence)

VHDL (Undetermined Prevalence)

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Processor IP (Undetermined Prevalence)

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Access Control
Confidentiality
Integrity
Availability
Accountability
Authentication
Authorization
Non-Repudiation

Technical Impact: Varies by Context

Usage of crypto primitives without successful self-test could render the supposedly encrypted data as unencrypted plaintext in the worst case. This would compromise any security property, including the ones listed above.
+ Demonstrative Examples

Example 1

The following pseudocode demonstrates this vulnerability where the architect deemed it OK to ignore the result of a self-test from an RNG. Assume the output from the RNG is used to seed yet another pseudo-random-number generator.

(bad code)
Example Language: Other 

If random_number_generator_self_test_passed() == TRUE

then Seed = get_random_number_from_RNG()

else Seed = hardcoded_number

In the example above, first we are checking if the RNG is ready by performing a self-test on the RNG. If it fails, we just ignore the result and use some hardcoded, constant value. This action of ignoring the self-test result and using a constant seed is going to reduce the entropy of the cryptographic function using that seed and thereby weaken it.

(good code)
Example Language: Other 

If random_number_generator_self_test_passed() == TRUE

then Seed = get_random_number_from_RNG()

else enter_error_state()

+ Potential Mitigations

Phase: Architecture and Design

Follow sensible 'best practices' for crypto system design. For example, ensure the crypto system performs a power-on self-test at boot time, and that self-test results can't be ignored or overridden.

Effectiveness: High

Phase: Implementation

Depending on the specific cryptographic function the unit is providing, it might be necessary to perform additional, conditional self-tests periodically, e.g., using pairwise-consistency tests for RSA, DSA, and ECDSA signature keys. Also, the system should be insulated from all influences during self-test--no input signals allowed.

Effectiveness: High

+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-12Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
More information is available — Please select a different filter.
Page Last Updated: June 25, 2020