Case Study 38.1: The Bank Link

The situation

A mid-sized bank runs two data centres 40 km apart, connected by leased dark fiber. Settlement traffic runs between them continuously.

The board has been briefed on "harvest now, decrypt later" — an adversary recording encrypted traffic today and decrypting it once a cryptographically relevant quantum computer exists. The briefing was accurate. Settlement records have a confidentiality requirement measured in decades, so traffic captured in 2026 could matter in 2046.

A vendor proposes QKD on the existing fiber pair. €340,000 for the two endpoints, €45,000 annual support. The security team is asked to evaluate.

Step 1: confirm the technology does what it says

The team's first finding is that the vendor's technical claims are true.

40 km is comfortably inside the range wall:

>>> from vqelab.qkd import QKDLink, max_secure_distance
>>> QKDLink(40, authenticated=True).describe()
'40 km, QBER 0.0100, secure'
>>> max_secure_distance()
240.4...

No trusted nodes. No repeaters. Key rates in the megabits per second at that distance. The security proof is real, the hardware is mature, and an eavesdropper splicing the fiber would be detected.

This is not a case study about a vendor overselling. Everything on the datasheet is accurate, which is what makes the evaluation interesting.

The security team writes down the threat they were briefed on and the threat QKD addresses, and discovers they are not the same threat.

Briefed threat: an adversary captures settlement traffic today and decrypts it in twenty years.

QKD's protection: an adversary tapping this fiber pair is detected, and the keys negotiated over it are information-theoretically secure.

The gap is that harvest-now-decrypt-later does not require tapping this fiber. It requires capturing the traffic anywhere — at the exchange the bank connects to, at a peering point, at either endpoint, or from a backup. QKD secures one 40 km segment of a path that is not 40 km long.

The team maps the actual data path and finds settlement traffic traverses six network segments, two of which are third-party. QKD covers one.

Step 3: find what it needs before it starts

The deeper finding comes from reading the protocol rather than the datasheet.

>>> from vqelab.qkd import secret_key_rate
>>> secret_key_rate(0.01, block_size=10**6, authenticated=False)
UnauthenticatedChannelError: a QBER of 0.0100 on an unauthenticated channel
proves nothing -- an attacker running separate BB84 sessions with each party
shows BOTH a clean QBER. Authenticate the classical channel first; QKD cannot
bootstrap that itself.

The QKD system's classical channel must be authenticated, and the vendor's manual specifies how: a pre-shared symmetric key, installed manually at commissioning, rotated annually by an engineer with physical access to both endpoints.

So the deployment adds a pre-shared-key management process that did not previously exist. The bank currently authenticates that link with certificates from an internal CA — automated, audited, rotated every 90 days without a site visit.

⚠️ The system's overall security is now bounded by the manual key installation, which is a human process at two sites, and by whatever the annual rotation procedure looks like when the engineer who wrote it has left. §38.5's point is not academic: QKD consumes authentication, it does not produce it, and the authentication it consumes has to come from somewhere less exotic.

Step 4: price the alternative

   ML-KEM-768   public key 1,184 bytes   ciphertext 1,088   shared secret 32
   ML-KEM-768 full exchange:  201.7 us
   X25519 full exchange:       76.6 us

The bank's TLS terminators already support hybrid X25519+ML-KEM key exchange. Enabling it is a configuration change and a certificate reissue. It costs 2.6× the CPU of the classical exchange, on hardware that is not CPU-bound, and it protects every segment of the path — including the two third-party ones, and including traffic to counterparties the bank has never met.

Against €340,000 plus €45,000 a year for one segment of six.

Step 5: the recommendation

Recommend: enable hybrid post-quantum TLS across all settlement paths this quarter. Decline the QKD proposal.

To be explicit, because the vendor's claims are accurate and we do not want this read as a rejection of the technology: QKD would work. At 40 km we are well inside the range limit, the key rates are ample, and an eavesdropper on that fiber would be detected. The physics is sound.

It addresses one of six segments on the settlement path, and the threat we were briefed on — harvest-now-decrypt-later — does not require access to that segment. An adversary capturing our traffic will do it somewhere else.

It would also replace an automated 90-day certificate rotation with a manual annual pre-shared-key installation, because QKD requires an authenticated classical channel and cannot create one. That is a net reduction in our operational security posture, and it is the part of the proposal we found hardest to see from the datasheet.

Hybrid PQC costs 2.6× the CPU of the exchange it replaces, covers every segment including third-party ones, requires no new hardware, and is already supported by our terminators.

What would change this recommendation: a requirement for information-theoretic security on a specific point-to-point link with a fifty-year confidentiality horizon, where we control both endpoints and can manage pre-shared keys properly. We do not currently have that requirement. If Treasury develops one for the vault link, this proposal should be revisited on its merits.

What this case study is about

The security team did not need to find anything wrong with QKD, and did not. They needed to notice three things:

  1. The protected segment was not the exposed segment. A guarantee applied to the wrong part of the path is not a weaker guarantee — it is an irrelevant one.
  2. The precondition was in the manual, not the datasheet. §38.5's authentication requirement is not hidden, but it is never on the front page, because it is a fact about what QKD is rather than about any particular product.
  3. The alternative had already shipped. ML-KEM was standardized in 2024 and the bank's own infrastructure supported it.

This is Chapter 37 Case Study 37.1's shape with different physics: evaluate what a technology produces against what the system actually needs, not against what the technology is impressive at.

Questions

  1. The team found QKD covers one of six segments. Would covering all six change the recommendation? Price it, and say what new problem you have created.
  2. The manual pre-shared-key rotation is called "a net reduction in operational security posture." Argue the opposite: construct the case that a manual annual PSK is stronger than automated 90-day certificates, and say what would have to be true for it to hold.
  3. The bank's confidentiality horizon is decades and ML-KEM's security is conjectured (lattice hardness), not proven. Does that asymmetry favour QKD? Work through it honestly — this is the strongest argument the vendor has.
  4. [measure] Model the link at 40 km and at 200 km. What changes operationally, and at what distance would the bank need its first trusted node?
  5. The hard one. The recommendation says the decision would change for a link with "a fifty-year confidentiality horizon where we control both endpoints." Write the specification for such a system, including how the initial pre-shared key is established and how it is rotated. Then estimate how many of your specification's failure modes QKD protects against.