So, what is DEFCON?

Every year I look forward to the CTF at Quantum Village as it’s a really surreal experience: if you want to find out what’s really going on with a particular tech, this is the place to be!

Last year was more about showing people how simple Quantum can be. This year was all about interactivity. It’s what I love about OQC, we are putting quantum into people’s hands. We’re getting people to engage with this technology — not go, “Quantum is somewhere” but go, “Quantum’s here — I can access it,  I can do something with it.” A quantum ‘Capture the Flag’ was the perfect opportunity to do this.

‘Capture the Flag’ is one of the oldest competitions at DEFCON, a popular hacking convention held each year in Las Vegas. We took part alongside Quantum Village, who formulated the World’s First Quantum Capture the Flag competition, and provided access to our quantum computers.

What is ‘Capture the Flag’?

In cybersecurity, Capture the Flag (CTF) competitions are exercises in which participants, either individually or as part of a team, are challenged to find and exploit vulnerabilities in a system to capture a “flag” or piece of information.  Put simply, CTFs are a way to gamify cybersecurity.

We had winners, people learnt quantum, and navigated interesting challenges. It’s amazing seeing people use the uq simulator, engaging with and understanding quantum, and really, genuinely getting excited to run their algorithms on real hardware.

From games to reality

Personally I love talking to the security folks, you’ll find out how they’re trying to break and protect the latest systems. Q-day, the day when quantum computers will reach a scale and quality where they are capable of running Shor’s algorithm. Long before quantum computers are ever a vague notion of a threat to modern cryptography and cybersecurity, cybersecurity will be a problem for quantum computers.

Quantum computers offer many incredible computational opportunities that simply are not possible on classical hardware. But we cannot forget we are building a new computing model, pitfalls and all. The week I originally gave this talk at QuantumVillage, we saw some devastating new hardware exploits against both Intel and Arm CPUs, namely, Downfall and Zenbleed. This is what keeps me up at night, as the complexity of a quantum computer’s runtime and hardware stack evolves, unless we start these discussions now then it will be inevitable that we introduce similar bugs into quantum computing. I don’t want to spend a fraught Sunday writing the equivalent of microcode updates to our latest quantum computer…

Starting the conversation

So let’s start that conversation today! I would like to go through an example of a row-hammer-inspired quantum attack again, a hypothetical (but very reasonable) potential quantum parallel runtime. Lots of terms in that previous sentence we need to define.

Row hammer attacks are a class of classical hardware vulnerabilities that exploit undesirable coupling of neighbouring bits of memory in DRAM through leaking charges. VERY loosely, if we have some chunk of memory that we own, shown here in purple. Then the kernel should (and does some of the time) do a good job at preventing other users that could be malicious (or just bad at memory management) from accessing my physical memory block.

However, if this malicious user, we’ll call them Eve, has access to the yellow rows of memory then they can play some tricks. If Eve is to switch her memory bits on and off very rapidly, then this will exacerbate those existing unwanted couplings for evil deeds. This isn’t just an interesting idea where the reality of the noisy small scale world comes crashing down around us, but the google security were able to use this idea to flip very particular bits of information in memory for a privilege escalation attack.

Superconducting QCs

Inspired by this, let’s talk a little bit about how superconducting quantum computers work. Here we have Lucy, OQC current live device’s topology.

What we mean by topology is the “hardwired” connections between different qubits. If you want to perform a two qubit operation, then those qubits require a physical connection. Here we can see Lucy has a ring topology, so if you wanted to perform a conditional not operation between 1 and 2 you can, but we have to perform some compiler tricks if you want to perform one between 2 and 3. Currently, the runtime model for a quantum computer is very simple. No persistent state (approximately), no memory, short lifetime of the computation and single threaded. If a user was to perform some computation that only requires 2 qubits, right now, they would get the entire device for their own personal use,

This was the same on early classical devices, too! Resource underutilisation is not ideal on any limited resource, or anyone who cares for performance. One natural, (but currently hypothetical) execution model we could develop would be to allow for multiple parallel executions to take place on un-allocated qubits, e.g.

This tiling gives us the most additional free space for any other additional users to come in too. I have somewhat buried the lead here by calling our second user Eve, so the immediate question is what can Eve do maliciously here? Much like the linux kernel does, we would never allow Eve permission to run anything in Alice’s space. But she doesn’t need to! Much like classical row hammer, we can exploit existing physical couplings.

Performing qubit gates

So how do we perform these two qubit gates? First let us understand how we perform one qubit gates. All we wish to do is flip a bit from zero to one. Classically, this difference is some applied voltage difference. Let’s say 5v difference, 0 is 0 volts and 1 is 5 volts. Keeping this in mind, in order to drive a bit flip operation on a quantum computer, we don’t think about voltages, but microwaves.

We send in a short pulse of microwaves into our system, just enough energy to jump up a qubit resting in the 0 state to land in the 1 state. Each qubit requires a slightly different amount of energy to make this jump. Because we’re thinking in terms of microwaves here, we’ll frame this as each qubit has its own frequency. Something like a classical CPU where each transistor has its own voltage difference. For two qubit operations, in particular that conditional not operation, we drive the “controlling qubit” at the “target qubit” frequency. For example, if we wanted to flip qubit 1 if qubit 8 was in state 1 and do nothing if 8 is in state 0, then we would drive qubit 8 at the frequency of qubit 1.

We can now take this knowledge and start to understand how we might be able to drive interactions and bit flips to neighbouring users without having to ask their permission. But how does Eve implement this attack?

If we start with Alice implementing a hello world experiment to see those results first:

Then Eve can use a quantum language called OpenPulse which grants the users the exact pulse level control needed to manipulate the timing and frequency of a given pulse. Here we give and implementation and the impact on Eve’s results.

Those results now look pretty terrible to me!

What are the remediations?

There are plenty of remediations and discussion points to be had on these results including:

• Move Eve away and accept we can’t have full device utilisations
• Turning off OpenPulse isn’t a good solution as similar attacks are possible with logical gates. But we must also start to consider the broader attack surface of quantum computer
• Quantum anti-virus 
• Tunable couplings that we can “turn off”

But naturally, this will be specific for each use case.

I hope this has been interesting, especially to the “classical” cybersecurity folks looking for their next challenge, please get in touch if you have any ideas on further potential quantum computing hardware vulnerabilities. We want to explore them all now and try to get ahead of this before I’m making a coffee at 1am to fix quantum heartbleed!

For more resources and researchers in this space, check out the below link:

• https://q-ctrl.com/learning-center https://www.classiq.io/academia https://qiskit.org/learn/
• https://www.thomaswong.net/introduction-to-classical-and-quantum-computing-1e3p.pdf
• https://craftinginterpreters.com/ https://hwsecuritybook.org/
• https://scholar.google.com/citations?hl=en&user=NO1Je2kAAAAJ&view_op=list_works&sortby=pubdate

If you missed the session at DEFCON, don’t worry you can watch the recording below.