Attacking Quantum Systems: The Gap Between the Proof and the Box

In 2010, a team including Vadim Makarov, then at the University of Waterloo’s Institute for Quantum Computing, shone a bright continuous laser down the fibre of two commercial quantum key distribution systems and walked away with the full secret key. Quantum key distribution, or QKD, uses single photons to establish a shared secret between two parties, and its whole selling point is that an eavesdropper who measures those photons disturbs them and shows up as a higher error rate. In this demonstration the error rate never moved. Nothing in quantum mechanics was violated and no protocol was broken. The detectors at the receiving end simply stopped doing the thing the security proof assumed they were doing, and the proof stopped applying at that moment.

Since then, a fairly consistent pattern has emerged across every kind of quantum system that has been attacked in public: quantum links, quantum random number generators, and now cloud-hosted quantum processors. The attacker never fights the physics. The attacker finds the place where a real device diverges from the idealised device in the security argument, and works there. This article is a working map of those divergences for engineers who have to secure the equipment rather than prove things about it.

Attacks live in the gap between the model and the device

A security proof is a statement about a model. The model of a QKD receiver says: single photons arrive, a detector registers them with some probability, and any interference by a third party raises the error rate above a threshold. The model of a quantum processor says: qubits evolve under the gates in the circuit, with errors that are random and independent. Both models are good. Neither is a device.

The device is a box of analogue components with datasheets, and datasheets have edges. A photodiode has a saturation point. A control line has an impedance and radiates. A power supply is shared. A random number generator has a refill rate. None of these appear in the security argument, which is precisely why they are the interesting part of the system.

This isn’t a new discovery, and we should say so plainly, because the classical precedent tells engineers what to expect next. In 1996 Paul Kocher showed that RSA private keys could be recovered by timing how long a device took to do modular exponentiation. The cipher was fine. The mathematics was untouched. The implementation leaked. Three years later Kocher and colleagues published differential power analysis, which pulled keys out of smartcards by measuring current draw during encryption, and an entire industry of countermeasures, evaluation labs and certification schemes grew up around the finding. Quantum systems security is roughly where smartcard security was in 1997. The proofs are strong, the implementations are young, and the people testing them are mostly friendly.

Four ways a device breaks its own model

Almost every published attack on a quantum system fits into one of four classes.

Pushed outside its operating regime

The blinding attack works like this. Single-photon detectors in QKD receivers are usually avalanche photodiodes running in Geiger mode, where the device is biased above its breakdown voltage so that one absorbed photon triggers a self-sustaining current pulse. Flood that diode with bright continuous light and it drops into linear mode, where output current tracks input power and single photons produce nothing at all. The detector still clicks, but only when a light pulse crosses a power threshold. An eavesdropper can now intercept the real photons, measure them, and send tailored bright pulses that make the receiver click exactly where she wants. The receiver reports a healthy link the whole time. Vendors patched this after 2010, mainly by monitoring detector photocurrent and adding alarms for out-of-spec illumination, and the underlying lesson survived the patch: a component operated outside its specified regime doesn’t fail loudly, it fails quietly and keeps reporting.

Quantum processors have the same exposure in a different medium. Today’s machines are what the field calls NISQ devices, for noisy intermediate-scale quantum, meaning tens to a few thousand physical qubits with error rates too high for full error correction. They hold their quantum states only inside a narrow band of temperature, vibration and electromagnetic conditions, and losing those states to environmental interaction is called decoherence. Anyone who can perturb that environment can force errors or a shutdown. That is a denial-of-service attack with an unusually low bar, and for a shared research facility or a cloud backend, availability is a real security property rather than an afterthought.

The class also includes deliberate fault injection. Superconducting qubits are driven by shaped microwave pulses and trapped-ion qubits by laser pulses, so anyone with access to those control paths can inject signals that change gate behaviour. Error correction doesn’t remove the concern. Correction codes assume errors are random and roughly independent across qubits, and an attacker who reaches a shared control line or a shared supply can produce correlated errors on many qubits at once, which is the one thing the code wasn’t built to absorb.

A channel nobody specified

The second class is the side channel: information leaking through a path the designer never counted as a path. Timing, power draw, electromagnetic emission, reflected light, thermal signature.

In QKD the classic example is the Trojan-horse attack, described by Nicolas Gisin and colleagues in 2006 and demonstrated on real hardware by Nitin Jain’s group at Erlangen in 2014. The eavesdropper sends bright pulses into the transmitter between the legitimate single-photon pulses. Some of that light reflects off internal optics and comes back down the same fibre, carrying information about the state of the modulator, which is to say the basis and bit the sender chose. No interception of the key photons is required. The related backflash channel runs the other way: avalanche photodiodes emit a faint burst of light when they fire, and that burst can reveal which detector fired, which reveals a bit.

On the computing side the same class is opening up now. Work from Jakub Szefer’s group at Yale showed that power traces taken from the control electronics of a superconducting machine carry enough structure to reconstruct the circuit that produced them, which puts proprietary algorithms and input data at risk from anyone with visibility into the control rack. Separately, analysis from Swaroop Ghosh’s group at Penn State on multi-programming, where several users’ circuits run on one chip at once, found that crosstalk between neighbouring qubits produces correlated error patterns that one tenant can measure to infer another tenant’s state. Most cloud providers currently time-slice access rather than share a chip, so the exposure is limited today. Commercial pressure to raise utilisation will push in the other direction, and the mitigation has to be designed before the multiplexing arrives, not after.

Randomness that isn’t

Every QKD security proof rests on the sender and receiver making unpredictable choices of basis and bit. Predict those choices and you predict the key, and no photon has to be touched. The same dependency shows up in the classical parts of any quantum deployment, where session keys and nonces come from somewhere.

Two failure modes are worth designing against. The first is entropy starvation: a generator drawn on faster than it refills, which produces output that passes a casual smoke test and carries far less unpredictability than the proof assumed. The second is active biasing. Quantum random number generators derive their output from a physical process, often photon arrivals at a detector, and researchers have shown that injecting light into such a device shifts its output distribution. A generator that can be biased from outside the enclosure is a generator that needs continuous health monitoring rather than a one-time factory characterisation.

The classical wrapper

The fourth class is the largest and the least glamorous. A quantum system is a small quantum core wrapped in a great deal of ordinary computing, and the wrapper is where most of the practical risk sits.

QKD doesn’t authenticate its endpoints. The protocol establishes a shared secret between whoever is at the two ends of the fibre, and it has no way of telling you who that is, so a QKD link without a separate authentication mechanism is open to a straightforward man-in-the-middle. That mechanism is classical: a pre-shared key, or a post-quantum digital signature. The US National Security Agency’s published guidance on quantum key distribution and quantum cryptography lists this and several other practical limitations, including susceptibility to denial of service and the insider risk introduced by trusted relay nodes, and on that basis recommends post-quantum cryptography for national security systems rather than QKD.

For cloud quantum computing the wrapper is a web API, a job queue, a scheduler, a calibration database and a control server. All of it is attackable with entirely conventional techniques. Stolen credentials give an attacker other tenants’ circuits and results. A compromised calibration pipeline lets an attacker degrade a machine subtly enough that users blame noise. Compute theft is a live concern too, since machine time is scarce and expensive. And the hardware supply chain for cryogenic and control components is narrow, specialised and thinly audited, which makes a tampered control board a credible rather than a theoretical worry.

Two worked threat models

The four classes are only useful if they turn into a boundary diagram.

A two-node QKD link

Draw the link as five boundaries and write the assumption sitting on each one.

• The transmitter enclosure. Assumption: no light enters, and no light leaves except the intended signal. Test it. Is there an optical isolator on the output? Is there a watchdog detector that aborts on unexpected incoming power? Are there unfiltered openings for cooling or maintenance?
• The fibre. Assumption: an eavesdropper can read and modify anything on this path, and the protocol survives that. This one is usually correct, and it is the only boundary where the physics does the work.
• The receiver’s detectors. Assumption: they operate in Geiger mode throughout. Test it. Is photocurrent monitored? Is there an alarm on illumination above the single-photon range? What happens on the alarm, and who sees it?
• The randomness source. Assumption: basis and bit choices are unpredictable to an adversary. Test it. What is the generator, what is its refill rate under peak load, and is its output health-checked continuously?
• The authentication of the classical channel. Assumption: the two parties are who they claim. This is not provided by QKD, so name the mechanism explicitly or record it as an open risk.

Four of those five boundaries are engineering questions about equipment. One is physics.

A quantum job submitted to a cloud backend

The same exercise on the computing side produces a different shape, because the sensitive asset is usually the circuit and its results rather than a key.

• Identity and the API. Ordinary application security. Credential hygiene, token scope, rate limiting, audit logging.
• The job queue and scheduler. Who can read queued circuits? Are results at rest encrypted with keys the provider cannot use unilaterally?
• The control plane. The classical machinery generating pulses. Segment it from general IT, authenticate control messages, sign calibration data, and apply least privilege so a foothold in one service doesn’t become control of the processor.
• The chip itself. If the provider multiplexes users, ask how qubit allocation is isolated and whether readout resonators are shared. If they do not multiplex, ask what happens to the answer when utilisation targets rise.
• Verification of the result. You can’t inspect a qubit mid-computation without disturbing it, and a remote provider can return a plausible answer to a circuit it never ran. Blind and verified quantum computation protocols are being developed to close this, and until they are deployed, the honest position is that trust in the result rests on trust in the operator.

What actually shrinks the attack surface

Three lines of defence have real substance behind them, and they work at different layers.

Protocol changes that remove trust

Most successful QKD attacks target the detectors. Measurement-device-independent QKD, proposed by Hoi-Kwong Lo, Marcos Curty and Bing Qi in 2012, removes the detectors from the trust boundary entirely. Both parties send states to a central node that performs a joint measurement, and the security argument holds even if that node is fully controlled by an adversary. The cost is a lower key rate and a more complex deployment, and the benefit is that blinding, time-shift and detector-efficiency attacks stop being relevant by construction.

Device-independent QKD goes further, deriving security from an observed violation of a Bell inequality rather than from any assumption about what is inside the boxes. Laboratory demonstrations arrived in 2022. Rates and distances remain far below anything deployable, so treat it as the direction of travel rather than an option on a current procurement.

Hardware countermeasures

The vendor response to the last fifteen years of quantum hacking is largely defensive engineering: photocurrent monitoring and out-of-spec illumination alarms on detectors, optical isolators and narrowband filters on transmitter outputs, watchdog detectors that abort a session when unexpected light arrives, filtered enclosures, and tamper evidence on the physical unit. On the computing side the equivalent work is shielding and filtering the control electronics, isolating power domains so traces from one rack don’t describe another, and, where chips are shared, randomising qubit allocation and time slots so that whatever a co-tenant measures is hard to attribute. Ask a vendor which of these are present and which are on a roadmap. The answer is a good proxy for how seriously the product has been attacked.

Treating the control plane as the perimeter

The highest-value work for most organisations is the least exotic. Segment the quantum control network from enterprise IT. Authenticate and encrypt control traffic. Sign calibration artefacts. Log and monitor the job pipeline as you would any other production system. And run a post-quantum cryptographic layer underneath everything, using the algorithms NIST standardised in August 2024 – ML-KEM for key establishment and ML-DSA for signatures – so that a compromised quantum channel does not leave data unprotected, and so that the authentication a QKD link needs is itself quantum-resistant. The NIST post-quantum cryptography project publishes the standards, and pqcframework.org covers the migration methodology in depth.

The two technologies are complementary rather than competing. Post-quantum cryptography protects the classical layer that every quantum deployment depends on. Physics-based key distribution, where it is deployed, adds a detection property that mathematics cannot provide. An attacker then has to break both, in different domains, which is a much harder job than either alone.

A short checklist

Before signing off on any quantum deployment, we would want written answers to these:

1. Which components does the security argument assume are behaving correctly, and how would we know if one stopped?
2. What monitors the detectors, and what does an alarm actually trigger?
3. Where does the randomness come from, and is it health-checked in production or characterised once at the factory?
4. How are the endpoints authenticated, and with what algorithms?
5. Who and what can reach the control plane, and is it separated from general IT?
6. Are calibration data and firmware signed, and by whom?
7. If the chip is shared, what isolates tenants, and what is the plan when utilisation targets rise?
8. What is the availability plan when someone jams the link or heats the fridge?

Not one of those questions is about quantum mechanics. That is the point of the exercise.

Where to build the skill

Attacking and defending quantum systems sits at an awkward junction. Physicists understand the devices and rarely think like attackers. Security engineers think like attackers and often lack the device knowledge to know where an avalanche photodiode bends. The people who found these attacks worked across both, and the people who will find the next ones will too.

Quantum Academy’s quantum cybersecurity certification track is built for that crossing: the physics an engineer needs in order to reason about hardware assumptions, the threat-modelling discipline to turn those assumptions into boundaries, and the post-quantum cryptography work that secures the classical layer underneath. You can review the programs and the assessment structure at quantumacademy.com/.