← Investigations

INV-000

Deliberately Un-Dependable Applications

Reliability as a security parameter: bounding key exposure in the presence of faults

A Pwnshow Investigation · 2003–2006 · Status: completed · Programs: Investigations

Deliberately Un-Dependable Applications — cover

1. The question

Cryptography’s mathematical models assume computation is exact. Physical devices are not: they occasionally, and inevitably, compute incorrectly — and a single faulty output from an RSA-CRT implementation is enough to expose the private key. INV-000 asks the quantitative question hiding behind that fact: how long may a key remain in service before the mere accumulation of naturally occurring faults makes its exposure more likely than an accepted error bound — and, inverting the same logic, what does an attacker gain by deliberately degrading an application’s dependability? The investigation reframes reliability, ordinarily a dependability property, as a security parameter. It is the origin of the series’ technical lineage: the conviction that systems fail at the component everyone assumed sound, and that silent failure is the adversary — the thread INV-002 later relocates to the certificate store and INV-007 to the safety layer of open-weight models.

2. Method note

Movements. Conceive the process; execute to the standard of evidence; translate across registers. The conceived process was to import classical reliability engineering — the mathematics used to predict when hardware fails — into cryptographic threat modelling, and to derive from it computable bounds on how long a key stays safe.

Instruments. Two original metrics: the Cryptographic Key Failure Tolerance (CKFT) — the maximum number of faulty outputs a scheme can emit, under a given fault model, before the key is exposed — and the Cryptographic Key Reliable Lifetime (CKRL) — the longest a key may remain in service before the device’s reliability falls below the level the security margin requires. The formal apparatus models a key as a pool of f+1 non-repairable subsystems under a two-parameter exponential failure law, and extends to active-active high-availability infrastructures as a series of systems. The threat model is named and bounded: Passive Fault Attacks, in which the adversary only observes faults as they naturally occur — for instance, erroneous digitally-signed objects (CRLs, X.509 certificates) sitting in a directory — and exploits them opportunistically, without inducing them.

Exclusions and boundaries. The quantitative framework is deliberately scoped to passive faults in standard environmental conditions (its stated Assumption 1); actively induced faults are out of scope for the estimates, and the framework is positioned as complementary to fault-detection and key-size guidance, not a replacement. The active, software-induced case is treated separately and conceptually in the companion “Deliberately Un-Dependable Applications” seminar — a boundary worth keeping visible, because the afterlife of that concept (§4) is a claim about ideas, not about the paper’s measured results.

3. Findings

  1. Reliability is a security parameter. Once the physical nature of computation is admitted, a key’s security is inseparable from the reliability of the device holding it — and security policy cannot be built on mathematical models of cryptography alone.
  2. Fault-resistance can be measured, and for some schemes it is zero. CKFT quantifies how many faulty outputs a scheme survives: an RSA-CRT key has CKFT = 0 — one faulty signature exposes it — whereas AES under a one-byte fault model tolerates a bounded, larger number. A metric on which the most widely deployed asymmetric configuration scores catastrophically.
  3. Key lifetimes follow from first principles. Given a fault model, an accepted error-bound, and an infrastructure’s failure rate, the CKRL yields the longest a key may safely stay in service — reducible to lookup tables rather than case-by-case argument.
  4. The headline bound is severe. To keep a zero-tolerance key (RSA-CRT) exposed with probability below 2⁻⁴⁰ for even a single year requires an infrastructure failing at less than ≈1.04×10⁻¹⁶ failures/hour — a rate so low that such keys are impractical in many real settings, and one that common deployments with month- or year-long key lifetimes (e-commerce and banking servers, smart cards) do not meet.
  5. Scaling out can be a hazard. Active-active high-availability pools behave as a series of systems: adding modules raises the aggregate failure rate and shortens the key’s reliable life. Redundancy adopted for availability can quietly degrade key security — the counter-intuitive result the paper flags explicitly.
  6. Dependability inverts into a threat model. If dependability protects keys, then applications engineered to be un-dependable — to induce faults deliberately — become a cryptanalytic instrument. This is the “Deliberately Un-Dependable Applications” (DUDA) framing: the attacker’s use of reduced dependability as a tool.

4. Consequence

Durability through peer selection. The work was first presented at FDTC 2005 (co-located with CHES, Edinburgh), which had no formal proceedings at the time; the following year it was selected among the best papers of prior FDTC editions for inclusion in the workshop’s first formal proceedings — Cryptographic Key Reliable Lifetimes: Bounding the Risk of Key Exposure in the Presence of Faults, Springer LNCS 4236 (FDTC 2006, Yokohama). A preliminary version had appeared as a COSIC Technical Report and on the IACR ePrint Archive (2004/320).

Invited seminar. The DUDA framing was presented as an invited COSIC Seminar at K.U. Leuven (2003), during the visiting-scholar period in Bart Preneel’s group under which this research was carried out.

Intellectual afterlife — a category named early. The DUDA concept was specific to cryptographic modules, but its underlying category — local, software-induced faults used as a cryptanalytic tool — re-emerged years later, independently, in micro-architectural fault attacks (the software-induced hardware bit-flips of the Rowhammer family being the familiar example). The honest form of this claim matters: the work named the threat category in 2003–2004; it did not foresee the micro-architectural mechanism. The computer architectures of the time did not yet have the isolation and sharing features those later attacks exploit, and the author has been explicit that he did not see that vector coming. Prescience of a structure, not of a technique.

5. Artefact record

#ArtefactTypeVenue / identifierDateAccess
1Cryptographic Key Reliable Lifetimes: Bounding the Risk of Key Exposure in the Presence of FaultspaperFDTC 2006 · Springer LNCS 4236, pp. 144–1582006link.springer.com/chapter/10.1007/11889700_14 · paper
2Upper Bounds for the Selection of Cryptographic Key Lifetimes — preliminary versionpreprintIACR ePrint Archive 2004/320 · COSIC Technical Report2004paper
3Cryptographic Key Reliable Lifetimes — conference presentationslidesFDTC 2005 (co-located with CHES), Edinburgh2005fdtc.deib.polimi.it/FDTC05/ · slides
4Deliberately Un-Dependable Applications: the Role of Dependability Metrics in Fault-Based Cryptanalysistalk (invited) + slidesCOSIC Seminar, ESAT/COSIC, K.U. Leuven2003slides

6. Continuity

Inherits: —. This is the origin of the series’ technical lineage and, chronologically, its earliest investigation. Feeds: INV-002 (illusoryTLS), which carries forward the concern with silent failure and with the reliability of the cryptographic primitives others build upon; INV-001 (BeeWise) sits alongside it as the origin of the separate economic lineage. Its DUDA framing also has the independent afterlife in micro-architectural fault research noted in §4.

7. What’s next

8. Provenance

Provenance. This investigation was produced without external research funding, during the author’s employment at Andxor and a visiting-scholar period at ESAT/COSIC, K.U. Leuven; neither is a current Related Entity, and no entity related to Pwnshow’s personnel has a material interest in its findings. The results are formal and quantitative, drawn from public and academic sources together with the author’s expertise, and contain no non-public commercial information.

This entry documents research predating this Policy; it is a historical record. Added 2026/07/08 under Policy v1.0.

Page last updated: 2026/07/08 · Part of the Pwnshow investigation series

← Investigations index

Let's outplay.

Pwnshow (formerly secYOUre) · Rome, Italy · Investigating vulnerability since 2010. © 2026 Pwnshow