Quantum Threat Modelling
Some ideas and considerations for assessing the threats in quantum technology stacks
TL;DR - we are commencing a project to identify and enumerate threats to quantum technology stacks by bringing together experts in cybersecurity with quantum technology SMEs. The outputs of this project will be wide and varied, and this blog post serves some initial ideas and considerations for threat modelling with quantum tech.
Threat Modelling is a methodology for identifying and analysing risks and their mitigations in a given system. It has grown significantly in popularity and usage, gaining methodology protocols from companies and government entities (such as NIST) alike. Threat Modelling is now considered an important part of any Secure SDLC (Software Development Lifecycle), and is becoming required in many regulatory scenarios.
Overview
Threat modelling requires an understanding of several parts of a given technology (here paraphrased from NIST SP800-154):
An abstraction model of the system that allows you to view all of its constituent parts.
An analysis of the attack surface (a broad term for the collection of attack vectors) for the system.
A characterisation of mitigations for each of the threats identified.
Evaluate how everything that has been enumerated above and find the most effective controls that solve the attack vectors detailed.
In principle it’s a relatively straightforward process if you are aware of exploit/attack TTPs (techniques, tactics, and procedures) and defensive methods and options. However, we have found that many of the people aware of these things are not aware of the specifics regarding quantum technologies.
One way in which cybersecurity teams within organisations identify threats is through the STRIDE acronym:
Spoofing - accessing or pretending to be someone else.
Tampering - malicious manipulation of data.
Repudiation - performing malicious activities without any detection.
Information Disclosure - reading data that should not be accessible.
Denial of Service - deny access/service to valid users.
Elevation of Privilege - gaining privileged access without authorization.
Many threats posed to systems are covered by these main types. For a more detailed view of ‘how hackers hack’, you can also reference MITRE’s Adversarial Tactics, Techniques, & Common Knowledge (ATT&CK) Matrix, which you can find here.
Most of the physicists and engineers on the quantum side are not aware of the realities of many of the attacks they face. Beginning the work of bridging this gap is the main goal of this project.
Considerations for Quantum vs. Classical
There are several things that must be taken into account when analysing quantum technology stacks, which we have noticed and want to mention first.
Most of the technology components are classical
We are probably at risk of abusing this diagram from Mark C’s talk at QV1 in 2022, but here is a diagram of the main components for a quantum computer that is accessible via the cloud (true for IBM, IonQ, OQC, Rigetti, and many more!):
As you can see, the vast majority of components in a quantum computer stack are not quantum! This means that they are potentially vulnerable to any relevant classical attack! The quantum doesn’t help you here at all - at the time of writing, this means that there is a easily identifiable subset from 237,000+ total possible vulnerabilities that you have to consider.
Given how well classical attacks are tooled and easily exploited (IF an exploit is available, of course, which is another consideration) then
Most Quantum Attacks Are Not Conveniently Enumerated
Many know that the theory for Quantum Key Distribution began with the 1984 paper by Bennet and Brassard; “Quantum cryptography: Public key distribution and coin tossing”
Not many know that the hacking of QKD began with a paper from 2008 by Makarov; “Exploiting the saturation mode of passively quenched avalanche photodiodes to attack quantum cryptosystems” - see: http://www.vad1.com/publications/ProcOptSocKoreaAnnualMeeting2008-417.pdf
Still lesser known are the following papers:
Gisin et al. - “Trojan-Horse Attacks on QKD Systems”, https://journals.aps.org/pra/abstract/10.1103/PhysRevA.73.022320
Pang et al. - “Hacking QKD via Injection Locking”, https://journals.aps.org/prapplied/abstract/10.1103/PhysRevApplied.13.034008
…as well as possibly a dozen more papers that affect QKD’s security and/or operation - see slide 5 in this slide deck from a talk by Makarov.
There are two things important to note: First, that NONE of these vulnerabilities are enumerated against specific vendors. Even though it is very clear that [Makarov, 2022] is referencing ID Quantique, ID Quantique have never issued CVE’s to the general CVE database so that cybersecurity professionals (and yes, it’s a cybersecurity department risk analysis) can check what issues are present and advance whether they think it has been properly mitigated.
Secondly, all of these attacks focus entirely on the quantum side. None of them use any classical influence or techniques - as such, there is a waiting body of exploration in how a ‘full stack’ exploit on QKD, or indeed any quantum system, might look like and what might be possible.
Theaterwide Contextual Details are Really Important
Take this example: space-based QKD (aka ‘security space lasers’) has a very different threat model compared to QKD over a bespoke fibre connection or using some experimental dark fibre.
This probably should not need to be said, but detecting some eavesdropper on a fibre line is much more straightforward owing to known channel characteristics (such as loss) vs. the great difficulty in analysing the atmospheric effects on QKD from space to ground, and whether these are natural or someone putting a malicious satellite/drone/mirror-on-a-stick in the way. This difference changes the underlying theoretical guarantees of the quantum system.
There is no ‘one true threat model’ for quantum computing or quantum sensing. But that doesn’t mean we cannot enumerate the most common threats and issues - and then contrast these based on specific contexts or common use cases. This is in part why we think this project is so important.
Supply Chains Are Important
Quantum Key Distribution of the BB84/B92 kinds have their security almost entirely at the behest of a random number generator. E91-type protocols do not use RNG, but in BB84 and B92, the choices made by Alice and Bob are only secure if they are made totally at random. As such, if you seed them with a QRNG, then it’s probably all fine. Same for a TRNG, or a CSPRNG. But if you seed your QKD with libc’s LCG then you have a problem!
Thinking about your threat model immediately makes you consider the various sources of input that you consume - from the obvious ones (user input) to the much less obvious ones (randomness from clock jitter or some other source, and what algo they are fed into). These conversations about supply chain and where/what your sources are can be quite difficult to have, but they are incredibly important.
A Brief Example Threat Model: QRNG
It is often better to show by example what we are getting at, so let’s do just this! Below are some of the considerations for Quantum Random Number generation - taking the form of a dedicated device (context) installed on a network to provide randomness on demand to different parts of a business. You can preview this in the main image for this post above.
We identified at least three modes for attack; software, physical/hardware, and quantum. Whilst a lot of the ‘quantum attacks’ are physical they do usually have higher complexities and requirements. So here they have their own category so that they can be distinguished from other hardware attacks of varying complexity.
Definition of QRNG
Of course, we first have to define what differentiates QRNG from TRNG. In most cases, this is the existence of some form of ‘certificate’ that validates that the system was operating ‘in a quantum manner’ - cf. Quantum Dice and QuSide. This then certifies the output as being quantum-ly random, which is (as far as we know from our best scientific theories) optimal.
Attack Surface
Taking these areas as a starting point, our attack surface might be:
Software
API Vulnerabilities - essentially, anything in the OWASP top 10 or other common web API vulnerability frameworks that might/could apply!
Supply Chain Attacks - what are the in-place open source or closed source libraries that are being used to make the QRNG work. These might be packages that handle the API to bespoke drivers that interface with optical components.
Spoofing Attacks - can the output from the QRNG be spoofed by a malicious actor with some given level of access to give users ‘all 1’s’ instead of their random output? Can the quantum certification mechanisms be spoofed?
Physical/Hardware
Denial of Service (DoS) - can we cause the device to malfunction or simply stop responding?
Side Channel Attacks - can a well-positioned user divulge the randomness by external means? If we suppose the API uses strong encryption (and is so unreadable to someone sniffing the wire), is there a way to divulge the randomness and know what a given user has received?
It should be noted that some very creative variants of this exist, including extracting RSA keys from the coil whine on a heatsink with a microphone!
Loss of Calibration - most quantum tech systems are incredibly sensitive to loss of calibration. So from an attack perspective, is this a threat? Is there a screw that, if loosened, might ruin the calibration of the overall system?
Quantum
For Optical QRNG - Trojan State injection? Can the ‘Trojan-horse’ method be used against optical QRNG systems?
Part of the problem of not enumerating attacks on one type of quantum system (say QKD) is that there is no knowledge about how these might affect other quantum technologies.
Other Interference/Bias attacks - are there quantum states that may be introduced (using lasers or other communications equipment) that can affect the balance of a QRNG, maybe inducing bias or making the QRNG predictable?
Raising Error Rate - perhaps I cannot make the QRNG predictable, but I might be able to make it un-certifiable by raising the error rate such that the certification processes determines that the system is not ‘quantum enough’.
Possible Mitigations
Of course, most of these are entirely contextual, but here are some considerations we have as an initial exercise:
Software
API Vulnerabilities - What monitoring can be applied? (e.g. EDR or some network security appliance) What pentests/cybersecurity scans can be performed?
Supply Chain Attacks - Does the QRNG provider also provide an SBOM? If they did this, then it would feed into other standard practices.
Spoofing Attacks - is there some cryptography that might prevent this and provide some kind of authentication?
Physical/Hardware
Denial of Service (DoS) - can a network device/load balancer prevent this?
Side Channel Attacks - can an assessment be performed that identifies possible vectors so they can be mitigated? What is the turnaround time for fixes from the QRNG provider?
Loss of Calibration - Is there an alert for loss of calibration on the device? OR a failsafe logic that prevents the QRNG being used for, say, high-risk use cases (e.g. cryptographic key generation) if calibration is lost?
Quantum
For Optical QRNG - Can the ‘Trojan-horse’ method be detected? Or is there some good way to mitigate it?
Other Interference/Bias attacks - Is there a log of the performance of the QRNG that can be continually compared so that anomalies can be identified? Is that done automatically?
Raising Error Rate - Similar to the last points, is there are manner of pausing the QRNG for certain use cases (or all output?) if the certification fails?
Concluding Thoughts
This is a very short blog post for a topic that we could write about for reams and reams of paper. The important thing that we want to convey is that we think this is a really good exercise to do early in tech maturity stages.
If you are at DEF CON32 this year and want to come by the Quantum Village, we will be running threat modelling for quantum sessions throughout the conference! :D
Happy Threat Modelling!