1. Home
  2. Countermeasure
  3. Fault Injection Redundancy

Fault Injection Redundancy

Fault injection attacks deliberately induce errors in executing hardware or software, typically by manipulating voltage, clock signals, electromagnetic fields, or radiation, to corrupt computation and extract sensitive information or bypass security controls through observable fault effects. For mission-critical functions that must be protected against fault-based side-channel attacks, particularly cryptographic operations, redundancy-based countermeasures provide a robust detection and mitigation mechanism. The approach executes a protected function through two or more spatially or temporally redundant computations and compares their results. A mismatch indicates a computation fault or implementation discrepancy but does not by itself establish that fault injection occurred. With two results, the system can generally detect disagreement but cannot determine which result is valid. A voter or selection mechanism may provide fault masking only when the number of replicas, independence assumptions, and defined fault model support reliable adjudication; otherwise, the result must be rejected and a mission-approved protective response initiated. Although spacecraft sensor nodes and embedded processors operate under constrained resources, the functions most critical to protect through redundancy are typically cryptographic routines, whose execution footprint is bounded and whose compromise would have disproportionate mission security consequences.

Sources

ID: CM0051
Tier: III
Onboard SV CM 
Created: 2022/10/19
Last Modified: 2026/08/06

Pre-Operations Government

Acquisition requirements should address fault injection resistance as a security design requirement for mission-critical functions, particularly cryptographic implementations, with specifications requiring that a formal fault analysis be conducted to identify which functions are susceptible to fault-based side-channel exploitation and what level of redundancy is required to achieve adequate protection. Requirements should specify that the selection module logic used to adjudicate among redundant implementation outputs be itself hardened against fault injection, as an adversary who can corrupt the selection module may be able to force selection of a faulted output despite redundancy being present. Applicable protections may include replicated comparison logic, hardened control flow, error-detecting state, independent validation, or fail-secure rejection. Contract language should require that fault injection countermeasures be verified through testing using representative fault injection techniques, including voltage glitching, clock manipulation, and electromagnetic fault injection, demonstrating that the redundancy scheme successfully detects and responds to injected faults under realistic attack conditions. Evaluation criteria should assess offerors' experience with fault injection analysis and countermeasure implementation in space or similarly constrained embedded security contexts, and their proposed verification methodology. Verification should include documentation that the redundancy architecture covers all identified high-risk functions and that the selection module responds correctly to both single and multiple simultaneous fault injection attempts.

Pre-Operations Developer/Supplier

Fault injection vulnerability analysis must be conducted during the security design phase to identify which onboard functions are exploitable through fault injection, with priority given to cryptographic routines, authentication logic, access control checks, and any function whose output directly gates a security-relevant decision. The redundancy architecture must provide sufficient independence for the approved fault model. The analysis must consider shared power, clock, reset, input, memory, compiler, processor, and control paths through which one injected fault could affect multiple computations or the comparison mechanism. Spatial separation, temporal separation, diversified execution, separate processing resources, independent checks, or other controls should be selected where they materially reduce the applicable common-mode fault risk. Resource budget analysis must account for the computational, memory, and timing overhead of running multiple implementations of protected functions, with the overhead quantified and verified to be within the platform's resource margins before the architecture is finalized, particularly for resource-constrained sensor nodes where margin may be limited. The selection module must be implemented with its own fault resistance measures, as it represents a single point of failure in the redundancy scheme whose corruption would defeat the protection provided by the multiple implementations it adjudicates. Implementation diversity, including algorithm-level variations, independent code development, and use of different compiler optimizations or instruction sequences, should be considered to further reduce the probability that a single fault injection technique can simultaneously corrupt all redundant implementations. The selected diversity must be tested against the applicable fault model because different compilers or implementations do not automatically provide meaningful fault independence and may introduce additional defects or verification complexity.