Plundervolt – Yet Another Attack on SGX

A new yet another attack on SGX, called Plundervolt, works by playing around with the clock speed and voltage to the chip in order to induce an error in the computation that can be used to extract cryptographic secret keys. To an ordinary person, this sounds extremely strange. First, how is it possible for an attacker to play around with the voltage and clock speed of the processor? Does this require an attacker to physically stand next to the machine and apply electric shocks? Second, what does inducing faults in a computation have to do with extracting secret cryptographic key material?

The answers to these questions are surprising. First, since power is a serious issue in modern chips that carry out heavy computations, modern Intel chips provide instructions that can be called by software running on the chip to modify the processing speed and voltage. In a non-adversarial setting, this can be helpful to control the power, overheating and so on. However, our world is unfortunately extremely adversarial, and as shown in Plundervolt, this can be a disaster. It is true that in order for malware to be able to call these instructions, it must have root privileges. Typically, software should not be given such privileges, although in many cases malware is able to get them. More importantly, the entire motivation for using SGX is to provide protection even when an attacker does have root privileges on the machine. Otherwise, regular software protections are supposed to be sufficient. Thus, this constitutes yet another devastating break of what SGX is supposed to protect against.

However, the question still remains as to how inducing computation faults can help. This actually goes back to research in 1997 by Boneh, DeMillo and Lipton, in a paper called On the Importance of Checking Cryptographic Protocols for Faults. Their theoretical work (yes, they call it theoretical) showed how even slight faults in cryptographic computations are devastating and can completely break the scheme. For example, a single fault in a single RSA computation suffices for completely extracting the secret key! They called their work “theoretical” since how is it possible to utilize this, and induce a fault? In 2007, additional work in this area was published by Biham, Carmeli and Shamir in a paper called Bug Attacks, which extended this work. The example given in this later paper was to induce a fault by putting a smartcard, for example, in a microwave oven and hoping that this would induce faults. At that time, we called these “microwave attacks”, and as such it sounded extremely far-fetched. Well, once again, the long game of research reared its head. It took over 20 years, but modern processors actually provide the ability to practically induce faults, by utilizing the instructions provided by the chip manufacturer itself! The new work in Plundervolt combines over 20 year-old research with a sophisticated understanding of how modern processors work in order to once again break SGX.

What can we learn from this? First, SGX is good as a secondary security measure, but certainly cannot be relied on for a primary solution to protect cryptographic keys and other sensitive secrets. The number of times that attacks on SGX have been discovered, patched, and discovered again, is enough evidence to make it clear that trusted execution environments cannot be co-located with attack software. If the environment is not completely isolated from all other software, it will not be secure. This is the consensus amongst researchers involved in this space, and I am convinced of it. In addition, it should be clear that if your secrets are inside an SGX enclave of someone else, you need to trust them and their security environment. They clearly have root privileges.

The second take away is just the request that we have respect for theoretical research. We have no idea at all what will become useful and important, and it can take many years to know. The applied researchers behind Plundervolt, and other similar attacks, utilized their knowledge of past theoretical work together with a deep understanding of modern processor architecture, in order to cast light on the true (in)security of our modern computing environments.