Chapter 28 — Quantum and post-quantum security: failure analysis | Bachelor's Quantum and post-quantum security

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Lesson map

Lesson 28 published. Map, example, EX055.

flowchart TD
  N0["Learning outcomes"]
  N1["28.1 FMEA for cryptographic change"]
  N2["28.2 Algorithm-break response"]
  N3["28.3 Practical activity — Lab A"]
  N4["28.4 Recovery and exit criteria"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX055"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["28.1 FMEA for cryptographic change"]
  N2["28.2 Algorithm-break response"]
  N3["28.3 Practical activity — Lab A"]
  N4["28.4 Recovery and exit criteria"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX055"]

[Learning outcomes]
    |
    v
[28.1 FMEA for cryptographic change]
    |
    v
[28.2 Algorithm-break response]
    |
    v
[28.3 Practical activity — Lab A]
    |
    v
[28.4 Recovery and exit criteria]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX055]

Learning outcomes

You will (1) apply failure-mode and effects analysis (FMEA) to a migration; (2) plan for an algorithm break; (3) use a policy-driven registry for agility; and (4) define recovery procedures and exit criteria.

28.1 FMEA for cryptographic change

FMEA lists, for each component, ways it can fail, the effect, the cause, how it would be detected and a risk priority. Migration failure modes include: handshake failure due to message size; silent fallback to classical; certificate validation failure in old clients; performance degradation on constrained devices; key-management mismatch between HSMs; and an algorithm becoming untrusted after cryptanalysis.

Scoring each failure mode on severity, likelihood and detectability makes the ranking explicit and open to challenge. Silent failures deserve special attention because nothing alerts on them by default.

28.2 Algorithm-break response

Rainbow and SIKE show that a scheme can fall suddenly. A response plan says who decides, how quickly configuration can remove the algorithm, which systems need a release and which need hardware, and what fallback is acceptable. Hybrids make this survivable: if ML-KEM were unexpectedly weakened, hybrid flows would still rest on X25519 while a replacement is deployed.

The plan should be rehearsed in the lab before it is needed. Without a plan, HCU would be deciding under pressure which branches and terminals to change first, and the answer would depend on who happened to be on call.

28.3 Practical activity — Lab A

# Lab A (ch 28): crypto-agility through a policy-driven registry instead of hard-coded algorithms.
import hashlib, hmac
REGISTRY = {"hmac-sha256": lambda k, m: hmac.new(k, m, hashlib.sha256).digest(),
            "hmac-sha3-256": lambda k, m: hmac.new(k, m, hashlib.sha3_256).digest()}
POLICY = {"tag-algorithm": "hmac-sha256", "accept": ["hmac-sha256", "hmac-sha3-256"]}
def protect(key, msg):
    alg = POLICY["tag-algorithm"]; return alg, REGISTRY[alg](key, msg)
def check(key, msg, alg, tag):
    if alg not in POLICY["accept"]: return False            # algorithm identifier is authenticated by policy
    return hmac.compare_digest(REGISTRY[alg](key, msg), tag)
k, m = b"k" * 32, b"member statement 42"
a1, t1 = protect(k, m)
POLICY["tag-algorithm"] = "hmac-sha3-256"                   # migration = one policy change
a2, t2 = protect(k, m)
print("old tag still verifies during transition:", check(k, m, a1, t1))
print("new tag verifies:", check(k, m, a2, t2), "| algorithms:", a1, "->", a2)
POLICY["accept"] = ["hmac-sha3-256"]                        # retire the old algorithm
print("old tag after retirement:", check(k, m, a1, t1))

Expected output:

old tag still verifies during transition: True
new tag verifies: True | algorithms: hmac-sha256 -> hmac-sha3-256
old tag after retirement: False

Migration is a policy change, not a code change. The algorithm identifier travels with the data; during transition both algorithms are accepted, and after retirement the old one is refused. Using a MAC here keeps the lab simple; the same pattern applies to signatures and KEMs.

In a real system the registry would hold KEM and signature identifiers, and the policy would be loaded from configuration rather than set in code. The lab also shows why retirement is a separate step: tags created under the old algorithm stop verifying, so data that must stay valid needs re-protecting first.

28.4 Recovery and exit criteria

Each stage needs a rollback procedure and an exit criterion. Rollback restores the previous configuration quickly if failures exceed budget. Exit criteria say when a transitional state ends, such as "classical-only negotiation below 0.5 % for 90 days", so that fallback does not become permanent.

Both should be agreed before the stage begins, not after a problem appears. HCU writes the rollback steps into the change ticket and tests them in the lab, because a rollback that has never been run tends to fail at the moment it is needed. The exit criterion is reviewed at each stage decision, and any extension is recorded with a reason and a new date.

28.5 Worked example

HCU's FMEA ranks "silent fallback to classical on branch VPN" highest: severe for HNDL, likely due to misconfiguration, hard to detect without monitoring. Control: alert when any branch negotiates without the post-quantum method, weekly report of fallback share. "Large ClientHello dropped by legacy proxy" ranks second: visible quickly, so the control is staged rollout and a rollback runbook.

The FMEA is reviewed after each rollout stage, since measured results may change the rankings. Both controls are tested in the lab before the pilot begins.

28.6 Common errors and limits

Considering only availability failures, not silent security failures.
No plan for an algorithm break.
Transitional fallbacks with no exit criteria.
Scoring detectability too generously for failures that produce no error.
Writing rollback procedures that have never been rehearsed.
Ranking failure modes once and never revisiting them after the rollout produces real data.
Leaving key-management mismatches out of scope because they sit with a different team.

Each one leaves a risk on the table that the analysis was supposed to expose.

Exercises

EX055 — FMEA row. Write one FMEA row for "certificate validation failure in legacy clients after post-quantum certificates". Rubric: 3 = mode, effect, cause, detection, priority.
EX056 — Break response. Outline five steps HCU takes if a serious weakness is announced in a deployed PQ algorithm. Rubric: 3 = decision owner, assessment, configuration change, releases/hardware, communication.

Synthesis

FMEA exposes both noisy and silent failures; agility, hybrids, rollback runbooks and exit criteria make algorithm change and algorithm breaks survivable.

Continue studying — chapter 28 of 40

← Chapter 27 (draft) · Course chapter index · Chapter 29 (draft) →