Case Study: Evaluating a QKD Procurement Proposal

Executive Summary

A national bank receives a proposal: €4.2 million to deploy quantum key distribution between its two data centres, marketed as "future-proof security guaranteed by the laws of physics." The board is inclined to approve it — the physics is genuinely unbreakable, after all.

The physics is unbreakable. The system is not, and more importantly the system solves a small fraction of the bank's actual problem. This case study is the technical assessment: what QKD guarantees, what it does not, where implementations have been broken, and how it compares against the software alternative. It is a deliberately unglamorous application of Chapter 10, and it is the decision most organizations will actually face.

Skills applied

• Separating protocol-level security proofs from implementation security (§10.14).
• Mapping a cryptographic requirement to the right primitive.
• Assessing the trusted-node problem (§10.13).
• Comparing QKD against post-quantum cryptography on scope and cost.

Background: the proposal

Phase 1: What the bank actually needs protected

Inventory first, as in the Chapter 1 hospital case study:

Finding 1. QKD addresses exactly one line of this table. Six of seven requirements need digital signatures or public-key infrastructure, which QKD does not provide in principle — not as a product limitation, but because key distribution is not authentication.

Phase 2: Even the applicable line is subtle

At 1.2 kbps, the link generates about 10.4 Mbit of key per day. For 40 Gbps of traffic, a one-time pad — the only use where QKD's information-theoretic security is fully preserved — would need 40 Gbit per second. The shortfall is roughly six orders of magnitude.

So in practice the QKD key seeds AES-256 and is rotated periodically. That is a perfectly sensible design, and it has a consequence the marketing omits: the security of the bulk channel is now AES-256's computational security, not information-theoretic security. QKD has improved the key rotation story, not the security class.

Finding 2. Once the key feeds a symmetric cipher, the system's security is computational. The "guaranteed by physics" claim applies to a component, not to the deployed system.

And AES-256 was never the weak link. Grover halves its effective strength to $2^{128}$, which is not a threat.

Phase 3: The authentication bootstrap

BB84 requires an authenticated classical channel. Without authentication, Eve simply man-in-the-middles both the quantum and classical channels, running BB84 with Alice and separately with Bob; neither detects anything.

So the bank must authenticate the classical channel. Options:

• Pre-shared symmetric keys — secure, but requires manual key distribution to every endpoint, the very problem QKD claims to solve. It also does not scale.
• Digital signatures — which must be quantum-resistant, i.e. ML-DSA. Post-quantum cryptography.

Finding 3. QKD does not remove the need for post-quantum cryptography; it depends on it. The system requires ML-DSA to bootstrap the authenticated channel.

Phase 4: The trusted node

The link is 82 km with one relay. Without quantum repeaters — which do not exist as products — the relay must decrypt and re-encrypt: it holds the key in plaintext.

The security model is therefore: DC-A to relay is physics-secured; relay is trusted; relay to DC-B is physics-secured. A compromise of the relay compromises everything, and the relay is a box in a facility with power, cooling, staff, and a maintenance contract.

This is the same trust model as a conventional key-management server, and it reintroduces exactly the assumption the proposal claims to eliminate. It is not a flaw in the vendor's implementation; it is inherent to trusted-node QKD at any distance beyond a single fibre span.

Phase 5: Implementation attacks

The protocol's security proof assumes an idealized device model. Real devices violate it, and QKD systems have been broken in the laboratory repeatedly:

• Detector blinding — bright illumination forces avalanche photodiodes into linear mode, where they respond classically and Eve controls Bob's outcomes without raising QBER.
• Photon-number splitting — imperfect single-photon sources occasionally emit two photons; Eve keeps one. (Decoy states, which this proposal includes, mitigate this specific attack.)
• Time-shift and efficiency-mismatch attacks — exploiting differences in detector response between the two bases.
• Trojan-horse attacks — probing the sender's modulator with injected light to read the basis choice directly.

The general pattern: security proofs cover the protocol; attacks target the apparatus. This is not a criticism unique to QKD — but the marketing claim of "unbreakable" makes the gap uniquely misleading.

Finding 4. "Information-theoretically secure" describes the protocol under an idealized device model. Deployed QKD systems require the same continuous security engineering as any other cryptographic product.

Phase 6: The alternative, and the recommendation

Post-quantum cryptography for the same requirements:

Recommendation: decline. Spend a fraction of the capital on a PQC migration covering all seven requirements, following the tiering method from the Chapter 1 case study.

Where QKD does make sense — and it is worth being fair about this: a small number of point-to-point links, under one operator's physical control, carrying secrets whose value justifies the cost, where information-theoretic key exchange is a regulatory requirement rather than an engineering one. Some national-security and inter-governmental links meet that bar. A commercial bank's inter-DC traffic does not.

Discussion Questions

1. QKD requires an authenticated classical channel, which in practice means PQC signatures. Does that make QKD redundant, or complementary? Defend your position.
2. The trusted relay holds keys in plaintext. Compare this honestly against a conventional key-management server — is QKD's model better, worse, or the same?
3. Detector blinding defeats a protocol with an information-theoretic security proof. Explain how both facts can be true simultaneously.
4. Construct the strongest possible case for the proposal. What would have to be true about the bank for it to be right?

Your Turn: Extensions

• Compute the key rate needed for a true one-time pad on a 40 Gbps link and compare to the state of the art in QKD key rates.
• Read a published detector-blinding paper and write the countermeasure the vendor should be asked about.
• Build the seven-row requirement table for an organization you know and see how many rows QKD touches.
• Cost out a PQC migration for the same bank and compare total cost of ownership over ten years.

Key Takeaways

• QKD secures key exchange over a dedicated quantum channel. It provides no signatures, no PKI, and no protection for data at rest — most cryptographic requirements are outside its scope entirely.
• QKD requires an authenticated classical channel, so it depends on post-quantum signatures rather than replacing them.
• Beyond one fibre span, trusted nodes hold keys in plaintext, reintroducing the trust assumption the technology claims to remove.
• Protocol-level information-theoretic security does not confer implementation security; deployed systems have been broken through detectors, sources, and side channels.
• For nearly every organization, post-quantum cryptography covers vastly more of the requirement at a small fraction of the cost. QKD's real niche is narrow and mostly regulatory.