Rejecting faulty output does not prove that a cryptographic implementation leaks no information. DFA uses differences between correct and faulty outputs. SIFA conditions on ineffective faulted computations—the fault was induced, but the output stayed correct—and analyzes statistical bias in an intermediate value. Both require an explicit attacker and observation model.
Two different security questions
A food factory’s metal detector may stop a contaminant, yet production logs can still reveal which recipe line was active. The first is control safety; the second is information leakage. A crypto block may suppress faulty output and still leak through an error/valid flag, completion time, retries, or power differences. The analogy separates the questions; it does not model cryptanalytic statistics.
DFA often compares correct and faulty ciphertexts to derive key candidates from differences in selected rounds or bytes. Fault location, timing, round, and observable output determine feasibility. SIFA conditions on ineffective faulted computations: a fault was induced, but the output remained correct. The attacker analyzes the conditional bias in intermediate values from those samples to distinguish key candidates; a faulty ciphertext is not required. Here, effective and ineffective describe whether an induced fault changes the computation or output under the stated oracle. They do not refer to the DUT’s out_valid signal. Original SIFA paper.
Define the oracle first: can the attacker choose plaintexts, repeat injections, distinguish valid/timeout/alert/retry, or measure power/EM? Is the fault transient, permanent, skipped-cycle, or data corruption? Then test each observable’s relation to secrets. Constant-time alone is not a proof; sample size, noise, and multiple comparisons affect conclusions.
At RTL, assert that error state cannot create an unauthorized branch in valid/ready, retry, or key-release control. SVA cannot establish secret-independent power. Use gate-level/netlist and physical measurements for side-channel evaluation, and keep control properties separate from leakage evidence.
Interpret outcomes without conflating metrics
In a measured experiment, record the fault class, whether the computation changed, the error flag, latency, and whether the observation distinguishes outcome classes. A classifier that only performs well on its training samples has not shown generalization; hold out samples and report confidence. Failure to observe a distinction only means none was detected under these conditions.
Offline interactive lab
The lab uses fixed-seed synthetic samples to show how sample count, observation noise, and held-out samples affect a class comparison. The constant-comparison row reports only whether the repeated codes differ; the separate held-out accuracy reports the noisy exercise. This is a teaching model, not measured leakage, an RTL result, or an attack result.
RTL / SVA review direction
These are property sketches: define the harness transaction, reset and oracle, then confirm sampling boundaries before binding to the design. They have not been compiled or proven.
assert property (@(posedge clk) disable iff (!rst_n)
error_seen |-> !out_valid);
cover property (@(posedge clk) disable iff (!rst_n)
fault_class_applied && error_seen);This assertion checks only that out_valid is low when error_seen is high. It does not check ready, retry, or key release; each needs its own property. If error_seen never occurs, the assertion can still pass vacuously. The harness flag fault_class_applied records that the selected modeled fault was applied in this attempt. The cover checks that this flag and error_seen both occur; it does not prove successful injection into physical silicon or replace separate DFA, SIFA, or latency analysis. This snippet does not prove CDC, timing, side-channel, or physical injection behavior; each requires its own tool evidence or measurement.
Check your reasoning
- Recognition — What observation is central to DFA, and what can SIFA observe instead? Reasoning: DFA uses differences in correct and faulty outputs. SIFA conditions on ineffective faulted computations and analyzes the conditional bias in their intermediate values; the terms describe computation changes, not the DUT output-valid pin.
- Contrast — Why does rejecting faulty output not prove that a cryptographic block leaks no information? Reasoning: The reject decision is a control property. Error flags, validity, retries, latency, or power can still vary with secret-dependent state.
- Scenario — Faulty ciphertext is suppressed, but completion latency differs between two secret-dependent classes. What remains exposed? Reasoning: The timing channel remains observable. Suppressing data output only masks the faulty-ciphertext channel; it does not establish constant-time behavior.
- Failure diagnosis — A fault-outcome code separates the two classes in training samples. What evidence is still needed? Reasoning: Define the outcome classes first, then check sample counts, noise, repeated trials, and held-out data. A pattern in one small synthetic set is not a calibrated attack result.
- Design risk / transfer — After randomized latency or a new sample set, what changed in the oracle? If this sample shows no distinction, what may the reviewer conclude? Reasoning: Record the timing and sample conditions that changed. Only this sample and these observations failed to distinguish the classes; other channels, conditions, and physical measurements remain unexamined.
References
DFA of AES (IACR ePrint 2011/178) · Original SIFA paper (IACR ePrint 2018/071) · SIFA on masked AES (IACR ePrint 2018/357) · SIFA countermeasures (IACR ePrint 2019/536)
MY ACADEMY · LESSON FILM
Lesson video
The film explains this lesson’s data path. After a section, return to the interactive exercise and change the input or fault conditions. The animation presents a teaching model; it does not replace RTL simulation.
Swipe the film horizontally, or use the arrow keys to inspect the diagrams.
Diagram scope
Teaching model · Not RTL simulation or silicon testing
Concept / synthetic teaching scope; not a SIFA attack, key recovery or silicon measurement
Narration uses a synthetic voice. Both the interaction and animation have model boundaries; interpret results using this lesson’s sources and validation scope.
Wrap-up: take this lesson into a design review
- Threat model and assumptions
The attacker may repeat faults and observe ciphertext, validity, latency or power; the asset is the key/intermediate state.
- Why the design fails
DFA uses correct/faulty output differences; SIFA conditions on ineffective faulted computations and analyzes statistical bias in an intermediate value.
- Defenses
Constrain fault/oracle capabilities, verify output suppression/error handling, and assess physical side channels independently.
- Validation and checks to perform
Record fault classes and observable outcomes separately. Effective/ineffective describes computation or output changes, not the DUT out_valid pin. Control assertions do not replace attack-success or information analysis.
- Limits and unverified claims
Synthetic samples are not a crypto implementation test. No-model/no-detection does not prove zero leakage or cover all power/EM attacks.
Try a changed assumption
Add randomized latency and resampling; state which oracle changes and which attacks remain possible.
This wrap-up summarizes the lesson’s teaching cases, references and experiment scope. Checks not reported as completed remain future work.