Introduction
When thinking of security and quantum computers, many people may automatically think of using quantum computers for attacks on classical computers, by use of the Grover’s and Shor’s algorithms running on the quantum computers to break a number of existing cryptographic algorithms running on classical computers. Or, terms security and quantum computers are often associated with Quantum Key Distribution (QKD) or Quantum True Random Number (QTRNG) technologies. Yet, there is another aspect of security and quantum computers: security attacks on quantum computers. In particular, recent research has begun to demonstrate that it is possible to perform security attacks on quantum computers. The security attacks demonstrated so far, for example, show that it is possible to induce errors in qubits via crosstalk, fingerprint the quantum computer devices, or even leak information across reset gates. Although, only recently the security attacks on quantum computers have begun to be demonstrated, this brings to the forefront the need to consider security of quantum computer architectures as a first-class design objective. Especially, as physicists and architects race to build bigger and better quantum computers, the focus on performance alone should not overshadow need to make sure security is built into the architectures from the ground up. Otherwise, there is a risk of repeating many of the mistakes from classical computers where, for many years, security at the hardware and architecture levels was an afterthought.
Why Research Security of Quantum Computers?
There are many reasons for studying and ensuring security of quantum computers. They can be categorized into need to protect the computation and data on the quantum computers, and the quantum computer architectures themselves. Considering the computation and data, quantum computers have promise of delivering novel results in discovery of new drugs or materials, for example. When such sensitive data is generated, naturally adversaries may want to steal it, or try to force users to generate wrong results, or even deny service; and quantum computer architectures need to be ready to prevent these attacks. Considering the quantum computer architectures themselves, the architectures are results of years of research and huge amounts of financial investment. Adversaries may try to reverse engineer the architectures to extract the secret intellectual property or design ideas; and quantum computer architectures need to be designed to help mitigate reverse engineering efforts.
Today’s Noisy Intermediate-Scale Quantum (NISQ) quantum computers already have applications in optimization, chemistry, and other important areas. These NISQ quantum computers have on the order of 100 or fewer qubits, but the quantum computing hardware keeps evolving at a fast pace, with 1000-qubit quantum computers being projected to come online in the next few years. Given their promise, these computers are available, in some cases even freely, for access as cloud-based devices. Through services such as IBM Quantum, Amazon Braket, Microsoft Azure, and others, almost anybody can already run their quantum programs on real NISQ quantum computer hardware. Because of the cost and complexity of the quantum computer hardware, it can be almost certainly assumed that going forward, most if not all quantum computer deployments will keep the cloud-based usage model. With cloud-based access, anybody, including malicious users, can run their code on the real quantum computer hardware. And today there are almost no means to check whether malicious code is being executed on these machines.
On top of cloud-based access, computer architecture research community has been active in proposing means for multi-programming and multi-tenancy of quantum computers. Again, the complexity and cost of the machines makes it natural to expect that quantum computer providers will aim to share the hardware spatially and temporally to maximize utilization and minimize costs. Although no existing quantum computers provide multi-tenancy, architectures for multi-tenancy have been deployed in almost all classical computer settings, from CPUs, through GPUs, to proposals for FPGA multi-tenancy. It can be almost certainly assumed that eventually multi-tenancy will come to quantum computers. With multi-tenancy, we can expect many side and covert channel attacks to emerge to the sharing of the computers; and because of rather low-level gate or pulse access needed to run programs on NISQ machines, attackers will be able to develop circuits for crosstalk generation, information leakage, or even possibly to sense and reverse engineer the underlying hardware architecture.
Hardware Security Aspects of Quantum Computer Architectures
When considering the hardware, there are numerous security related question we can ask. Can programs, commonly referred to as circuits, running on qubits be protected from programs running on other quits? Can inputs and outputs of programs be isolated? Are there ways to protect the hardware so that it cannot be reverse engineered? Is it possible to reverse engineer a cloud-based quantum computer by running various quantum circuits, and if so, are protections possible? What physical attacks are possible to disturb operation of quantum computers, or to leak information from them? To answer these questions, we can analyze different parts of quantum computers and their architectures. Especially, beyond the qubits themselves, the architectures are actually composed of many other components. Many of which are classical: servers used to manage and schedule the jobs executing on the quantum computers, controllers (often built form FPGAs) used to interface with the qubits, and the actual fridges (in the case of superconducting qubit machines) wherein the qubits are located. Current research is only beginning to explore the security of all these parts, but already it is showing that qubits may not be immune to crosstalk attacks, or that outputs or resulting state of one circuit may leak across resets to the next circuit.
Software Security Aspects of Quantum Computer Architectures
When considering the software (i.e. programs or circuits), there are numerous security related question we can also ask. Is there a way to detect or prevent a user from running certain algorithms on a cloud-based quantum computer? What are the cybersecurity threats that are different between classical and quantum computing systems? To answer these questions, we can analyze different parts of the software development and the software stack of quantum computers. Many of the parts are quite analogous to classical computers. There is the input program (or circuit) described, for example, using Python-based Qiskit framework. The input gets complied into, eventually, set of control pulses to be executed on the quantum computer, and there is runtime that actually issues the pulses to the hardware. At each point, the input, compiler, or runtime, malicious code could be trying to compromise the system. Already, research has shown ways to implement some simple viruses which can execute on the quantum computers.
Analogies to Security of Classical Computer and Accelerator Architectures
A “feature” of classical computers that enables many of the security attacks is information leakage. Information leakage in classical computers occurs when an attacker can observe some information about a victim, often through some unexpected means, such as by observing timing changes or voltage changes associated with victim’s computation and correlating these changes back to some secret that victim holds and computes on. The open research question is what are the different types of possible information leakage for quantum computers. Once these are known, architects can design future quantum computer architectures to be resilient to the attacks.
Interestingly, at least today, quantum computer programs do not have equivalent of branches or jumps, thus various timing-based attacks are not possible. Also, as result, there is no run-time prediction and different classical computer speculative execution attacks do not translate to quantum computers. But as recent research has shown, it is possible to use crosstalk, akin in some aspects to crosstalk in FPGAs, for example, to leak information between two programs or users running on a shared quantum computer hardware. As more practical attacks, which do not require multi-tenancy, it has been shown that it is possible to leak information across reset gates, where a reset gate does not fully reset the state of a qubit. This is akin in some aspects to improper state cleanup in classical computers.
The information leakage my not be just about information leakage form one user to another, but, for example, it may be about learning information about the infrastructure. Akin to research showing it is possible to fingerprint FPGAs in cloud-based datacenters, it is possible to fingerprint quantum computers to uniquely identify each machine, even if not serial number or other identifier is given. Crosstalk and the effects that activation of certain qubits causes on other qubits is the basis for the fingerprinting attacks.
With quantum computers being already available as cloud-based devices, we should expect that malicious users will try to abuse them in different ways. While the computers are still small, now is perfect time to insert security into the design process of quantum computer architectures. We can learn a lot from classical computers and their (in)security, and apply the ideas to quantum computers. For example, early research is proposing a quantum computer antivirus, or means to protect computation from untrusted quantum computers cloud providers. Further, improving security and performance can mutually benefit each other; for example, limiting crosstalk can make quantum computers more reliable as well as fend off some of the security attacks. Thus in some cases, we may be able to get security without compromising performance. But today it is not yet clear what are all the threats in quantum computers. E.g. will multi-tenancy become available and thus crosstalk attacks will be really feasible? What is needed to analyze existing and expected features of quantum computers, develop demonstration attacks, and then design mitigations for them.
About the author: Jakub Szefer is an Associate Professor of Electrical Engineering at Yale University where he leads the Computer Architecture and Security Laboratory (CASLAB). His research interests broadly encompass computer architecture and hardware security of computing systems, including security of quantum computers. To follow Jakub’s updates about security of quantum computer hardware and architectures you can sign up for upcoming newsletter: https://quantumcybersecurity.substack.com/ (the newsletter is not endorsed by nor affiliated with the Computer Architecture Today blog).
Disclaimer: These posts are written by individual contributors to share their thoughts on the Computer Architecture Today blog for the benefit of the community. Any views or opinions represented in this blog are personal, belong solely to the blog author and do not represent those of ACM SIGARCH or its parent organization, ACM.
