Apple Chip Flaw Lets Hackers Steal Encryption Keys

A group of researchers has found a serious security vulnerability in Apple’s M-series of chips that would allow attackers to steal secret keys from Mac and iPad devices.

The problem affects Apple M1, M2 and M3 chips — which have been used in Apple desktops, notebooks and tablets since late 2020 — and occurs when they’re performing cryptographic functions. Attackers could potentially exploit the issue to steal cryptographic keys from systems — for example, the keys for cryptographic wallets stored on devices or to secure email communication and cloud accounts.

There has been a lot of confusion about the severity and implications of the vulnerability since the researchers published their findings today, so I’m going to try to clarify what the problem entails and what can and cannot be done to mitigate it. I should warn you, though, that this is pretty technical — more technical than I usually publish here at Zero Day. I think it's important to cover this, however, because after I posted about this on Twitter, many people have assumed this is far worse than it is.

Arstechnica reporter Dan Goodin wrote a good original story about the issue, but his piece is even more technical so I’ll try to explain it here in language that’s simpler. The bottom line for users is that there is nothing you can do to address this. The fix lies with cryptographic application developers, who need to implement mitigations for the problem and then issue updates to their applications.

Robert Graham, CEO of security consultancy Errata Security, says to be on the safe side, anyone with a lot of money in a crypto wallet on their Apple device should probably remove it for the time being. “There are people right now hoping to do this [attack] and are working on it, I would assume,” he says.

Background

Apple’s chips, and other modern processors, have an optimization technique called prefetching that is designed to speed up processing by looking in the computer's memory for patterns in your activity — functions you frequently perform and data you frequently access. The prefetcher determines what data you’ve accessed before and places in the system’s cache memory a pointer, or address locator, for where that data or function code is located in memory so that the system can find and use it more quickly when you need it. The problem is that the cache can “leak” information stored in it, allowing attackers to grab it in so-called side-channel attacks. Because of this, it’s standard to prohibit systems from mixing data with addresses or address pointers; if data gets mixed with an address, then when the user accesses the address, it might get placed in the cache where it could get leaked.

But a team of seven researchers from universities across the U.S. released a paper and video today showing that the Apple M-series chips mix data and addresses, which can be exploited to obtain cryptographic keys. They were able to devise a malicious application that, when downloaded to a user's machine, tricks Apple’s prefetcher — known as the Data Memory-Dependent Prefetcher, or DMP — into placing secret key-related material in the cache by tricking it into believing the key material was an address. The research was partially funded by grants from the Air Force Office of Scientific Research and the Defense Advanced Research Projects Agency, according to the researchers’ web site.

The cryptographic key itself isn’t placed in cache. But bits of material derived from the key gets placed in the cache, and an attacker can piece these bits together in a way that allows them to reconstruct the key, after causing the processor to do this multiple times. The researchers were able to derive the key for four different cryptographic algorithms: Go, OpenSSL, CRYSTALS-Kyber and CRYSTALS-Dilithium. The latter two are considered quantum-resistant algorithms — algorithms believed to be so secure they could not be cracked using a quantum computer. They didn’t test their attack against other algorithms but believe it would be successful against others as well.

Goodin noted in his Arstechnica piece that the attack the researchers designed takes less than an hour to extract enough data from the cache to reconstruct a 2048-bit RSA key and “a little over 2 hours to extract a 2048-bit Diffie-Hellman key. The attack takes 54 minutes to extract the material required to assemble a Kyber-512 key and about 10 hrs for a Dilithium-2 key.”

Matthew Green, a cryptographer and computer science professor at Johns Hopkins University, calls it a clever attack.

“The Apple code … has a certain set of criteria that it applies [to determining] what’s an address,” he says. “The researchers figured out that if [their malware provides] a message to be decrypted, the decryption algorithm at some point will combine the key with part of [that] message…. And it looks enough like an address that it tricks this little prefetcher [into placing it into cache].”

He adds that determining what is and isn’t an address is a tough problem for prefetchers to solve.

“Lots of things look like an address, and [the prefetcher] just kind of has to guess what’s actually an address or not, and so [the researchers] are able to squeeze [through] that guess,” he says.

The researchers created a malicious program that they call GoFetch that performs this trick, as well as a video demonstrating the attack in action.

Engineers designing applications that perform cryptographic functions implement a technique called constant-time programming, which effectively prevents data from being mixed with addresses and getting placed in the cache and leaked. But in the case of the M-series chips, constant-time programming isn’t effective says Daniel Genkin, a cybersecurity and privacy professor at Georgia Institute of Technology and one of the researchers who discovered the flaw.

He says the problem with the prefetcher on the Apple M-series chips exists because unlike other prefetchers in other chips that only examine addresses, the prefetcher in the Apple chips are programmed to also look at values stored inside addresses and this therefore puts them in the vulnerable position of confusing a value with an address and placing it into the cache.

“If a value looks like an address, then [the prefetcher] might decide to treat it like an address,” he says.

The M3 chip does have a special bit in the processor that programmers can set to disable the prefetcher for cryptographic functions and preventing cryptographic data from being placed in the cache; but the M1 and M2 do not allow the prefetcher to be disabled.

Attack Vector

How does an attacker trick the processor? They can do this by slipping malicious code into an application that a user downloads to their computer. The GoFetch attack code they created doesn’t require root access on a machine to work; it can trick the processor into doing this with just the same level of access that any third-party application has on a machine.

It could also be conducted on a cloud server hosting virtual machines used by multiple parties.

“If I’m on Amazon on a cloud server using a virtual machine and there’s another virtual machine using keys there, that’s another example of a case where this could be a problem,” says Green. But he cautions that it’s not an easy attack to pull off.

It’s also theoretically possible for an attacker to pull this off by embedding malicious code into Javascript on a web site so that when a computer with an M-series chip visits the site, the attacker’s malicious code can conduct the attack to grab data from the cache. The researchers didn’t test a web site attack, but Green says the scenario is plausible. It would also be a more concerning attack, he notes, because attackers could scale it to attack thousands of computers quickly.

Green says the risk for most people from the GoFetch application-style attack is probably low.

“We’re talking about high-end users, like someone who has a cryptocurrency wallet with a lot of money,” he says. But he notes that in theory this attack might be used to break the TLS cryptography that a computer’s browser uses to encrypt communication between their computer and web sites, which could allow attackers to decrypt that communication to extract a user’s session cookie for their Gmail or other web-based email account and use it to log into the account as them.

“I’m not saying it’s a practical attack I’m just saying that’s the kind of threat you might be worried about,” he says, “You can get [other] very high-valued keys potentially” including their iCloud keys to access backed up data.

The researchers reported the issue to Apple in December, but other than thanking them for their work, Genkin says Apple didn’t indicate what, if anything, it might do to address the problem.

The Fix

Because this is not a flaw in the Apple operating system but instead is a hardware issue in the chip, Apple can’t just release a patch the way it would for software flaws. It could, however, address the problem in subsequent chip designs.

Asked for comment about the problem, an Apple spokesman didn’t answer my questions directly but said only, “We want to thank the researchers for their collaboration as this research advances our understanding of these types of threats.” He also sent me a link to an Apple site for application developers.

The site includes an instruction to developers of cryptographic applications to include code in their program that causes the processor to implement data-independent timing, or DIT, that effectively disables the prefetcher when the computer is performing cryptographic functions for their application. It’s not clear how long this instruction has been on Apple’s developers site; there’s no date on the page.

There are two issues with the DIT fix, however. 1) Disabling the prefetcher will likely slow down the processor during cryptographic functions, the researchers say. By how much, they don’t know. 2) The DIT works only for Apple’s M3 chips; as noted above, the M1 and M2 chips don’t have the ability to disable the prefetcher. Apple only debuted the M3 chip recently – the first Macbooks with M3 chips became available last October. This suggests that Apple may have become aware of the problem on its own, sometime after products with M1 and M2 chips were sold (and before the researchers notified them about the issue in December), and added this ability to disable the prefetcher in the M3 chip as a result. If this is the case, then it means Apple made the change without telling consumers about the issue with their M1 and M2 chips. But this is only speculation at this point.

Green says he was never aware of this instruction to developers to implement DIT.

“I implement crypto, and this is literally the first time I’ve heard of it,” he says, noting that other cryptographers have likely missed it as well. “I would say that the number of crypto libraries that are doing this has to be pretty low. Zero.”

[After this story published, Apple told me they just posted the instruction about the DIT to their web site yesterday, timed to the public release of the researchers' findings, which means that developers were not told to do this fix prior to yesterday's release and explains why Green had not heard of it before.]

Genkin says that Apple’s own crypto library, Core Crypto, does disable the prefetcher for the M3 chip. He doesn’t know if developers of other cryptography applications have followed the instructions on Apple’s developer page to implement the DIT fix. But he says the message to enable the DIT to avoid this problem makes it clear that developers shouldn’t consider it optional.

“To experienced application developers, if you say enable DIT to enable constant time, what I’m hearing is if you don’t do this it will be bad,” he says. “For cryptographic engineers that know the literature well, it’s more than sufficient.”

The researchers suggest some other mitigations that developers can implement in their cryptographic programs to protect the secret key data when a system performs cryptographic functions. But Green says they’re not clean fixes to address the problem in M1 and M2 chips.

UPDATED 3.22.23: To add speculation about when Apple may have learned about this issue and to add Apple's statement about when the DIT instruction to developers got added to its web site.