{"id":22545,"date":"2024-03-29T17:51:04","date_gmt":"2024-03-29T13:51:04","guid":{"rendered":"https:\/\/me-en.kaspersky.com\/blog\/apple-cpu-encryption-vulnerability\/22545\/"},"modified":"2024-03-29T17:51:16","modified_gmt":"2024-03-29T13:51:16","slug":"apple-cpu-encryption-vulnerability","status":"publish","type":"post","link":"https:\/\/me-en.kaspersky.com\/blog\/apple-cpu-encryption-vulnerability\/22545\/","title":{"rendered":"Apple CPU encryption hack"},"content":{"rendered":"

In mid-March, researchers from several U.S. universities published a paper<\/a> demonstrating a hardware vulnerability in Apple\u2019s \u201cM\u201d series CPUs. These CPUs, based on the ARM architecture and designed by Apple, power most of its newer laptops and desktops, as well as some iPad models. The issue could potentially be exploited to break encryption algorithms. The attack that uses this vulnerability was dubbed \u201cGoFetch\u201d.<\/p>\n

The combination of a juicy topic and a big-name manufacturer like Apple led to this highly technical paper being picked up by a wide range of media outlets \u2014 both technical and not so much. Many ran with alarmist headlines like \u201cDon\u2019t Trust Your Private Data to Apple Laptops\u201d. In reality, the situation isn\u2019t quite that dire. However, to really get to the bottom of this new problem, we need to delve a little into how CPUs work \u2014 specifically by discussing three concepts: data prefetching, constant-time programming, and side-channel attacks. As always, we\u2019ll try to explain everything in the simplest terms possible.\n<\/p>\n

Data prefetching<\/h2>\n

\nThe CPU of a desktop computer or laptop executes programs represented as machine code. Loosely speaking, it\u2019s a bunch of numbers \u2014 some representing instructions and others representing data for calculations. At this fundamental level, we\u2019re talking about very basic commands: fetch some data from memory, compute something with this data, and write the result back to memory.<\/p>\n

You\u2019d think these operations should be executed in this order. Here\u2019s a simple example: a user enters their password to access a cryptocurrency wallet. The computer needs to read the password from RAM, run a few computing operations, check that this is the correct password, and only then grant access to the confidential data. If this were the way today\u2019s CPUs executed all code, our computers would be painfully slow. So how do you speed things up? You do a lot of optimization \u2014 such as data prefetching.<\/p>\n

Data prefetching works like this: if the program code contains a command to fetch data, why not load it ahead of time to speed things up? Then, should the data come in handy at some point, we\u2019ve just made the program run a bit faster. No big deal if it doesn\u2019t come in handy: we\u2019d just discard it from the CPU\u2019s cache and fetch something else.<\/p>\n

That\u2019s how basic data prefetching works. Apple CPUs make use of a newer prefetcher known as \u201cdata memory-dependent prefetcher\u201d, or DMP. In a nutshell, DMP is more aggressive. Commands to fetch data from memory are not always explicit. Pointers<\/em> to specific memory locations might be the result of computing work that still needs to be performed, or they might be stored in a data array that the program will access later. DMP tries to guess which data in the program is a pointer<\/em> to a memory location. The logic is the same: if something looks like a pointer, try fetching data at that address. The guessing process<\/em> relies on the history of recent operations \u2014 even if they belong to a completely different program.<\/p>\n

In 2022, another study demonstrated<\/a> that DMP tends to confuse pointers with other data the program is working with. This isn\u2019t necessarily a problem by itself \u2014 loading the wrong stuff into the CPU cache isn\u2019t a big deal. But it becomes a problem when it comes to encryption algorithms. DMP can break constant-time programming under certain conditions<\/em>. Let\u2019s talk about this next.\n<\/p>\n

Constant-time programming<\/h2>\n

\nThere\u2019s a simple rule: the time it takes to process data must not depend on the nature of that data. In cryptography, this is a fundamental principle for protecting encryption algorithms from attacks. Often, malicious actors try to attack the encryption algorithm by feeding it data and observing the encrypted output. The attacker doesn\u2019t know the private key used to encrypt the data. If they figure out this key, they can decrypt other data, such as network traffic or passwords saved in the system.<\/p>\n

Poor encryption algorithms process some data faster than others. This gives the malicious actor a powerful hack tool: simply by observing the algorithm\u2019s runtime, they can potentially reconstruct the private key.<\/p>\n

Most encryption algorithms are immune to this type of attack: their creators made sure that computing time is always the same, regardless of the input data. Algorithm robustness-tests always include attempts at violating this principle. This is what happened, for example, in the Hertzbleed<\/a> attack. However, to make actual key theft possible, the attack must use a side channel.\n<\/p>\n

Side-channel attack<\/h2>\n

\nIf DMP prefetching sometimes confuses regular application data with a memory pointer, does that mean it can mistake a piece of a private key for a pointer? It turns out it can. The researchers demonstrated this in practice using two popular data encryption libraries: Go Crypto (Go developers\u2019 standard library), and OpenSSL (used for network traffic encryption and many other things). They investigated various encryption algorithms \u2014 including the ubiquitous RSA and Diffie-Hellman, as well as Kyber-512 and Dilithium-2, which are considered resistant to quantum computing attacks. By trying to fetch data from a false pointer that\u2019s actually a piece of a private key, DMP essentially \u201cleaks\u201d the key to the attacker.<\/p>\n

There\u2019s one catch: the hypothetical malware needed for this attack has no access to the cache. We don\u2019t know what DMP loaded there or which RAM address it fetched the data from. However, if a direct attack isn\u2019t possible, there\u2019s still a chance of extracting information through a side channel. What makes this possible is a simple feature of any computer: data loaded into the CPU cache is processed faster than data residing in regular RAM.<\/p>\n

Let\u2019s put this attack together. So, we have malware that can feed arbitrary data to the encryption algorithm. The latter loads various data into the cache, including a secret encryption key. DMP sometimes mistakenly fetches data from an address that\u2019s actually a piece of this key. The attacker can find out indirectly that data has been prefetched from a certain address by measuring the time it takes the CPU to access certain pieces of data: if the data was cached, accessing it will be slightly faster than otherwise. This was exactly how the researchers broke the constant-time programming principle: we can feed arbitrary text to the algorithm and watch the processing time vary.\n<\/p>\n

So, is your data at risk?<\/h2>\n

\nIn practice, extracting an encryption key requires dozens to hundreds of thousands of computing operations as we feed data into the algorithm and indirectly monitor cache status. This is a sure-fire attack, but a very resource-intensive one: stealing a key takes an hour at best \u2014 more than ten hours at worst. And for all this time, the computing effort will keep the device running almost at full capacity. The GoFetch website has a video demonstration of the attack, where the private key is extracted bit by bit \u2014 literally.<\/p>\n

\"Screenshot<\/a>

Screenshot from the research demo video. Source<\/a><\/p><\/div>\n

However, that\u2019s not what makes the attack impractical. We\u2019ve repeatedly mentioned that the attack requires malware to be installed on the victim\u2019s computer. As you can imagine, if this is the case, the data is already compromised by definition. There are likely far simpler ways to get to it at this point. This is the reason why the OpenSSL developers didn\u2019t even consider the researchers\u2019 report: such attacks fall outside their security model.<\/p>\n

All studies like this can be compared to civil engineering. To make a structure robust, engineers need to study the characteristics of the materials to be used, the given location\u2019s soil properties, make provisions for the risk of earthquakes, and do many other things. In most cases, even a poorly constructed building will stand for decades without problems. However, a rare combination of circumstances may lead to disaster. Attack scenarios like GoFetch are designed to avert such disasters that lead to mass leaks of user secrets.<\/p>\n

The researchers are going to continue studying this fairly new prefetching mechanism. Intel processors also use it starting with the 13th<\/sup> generation, but they\u2019ve proved insusceptible to this particular kind of attack proposed in the research paper. What\u2019s important is that the vulnerability can\u2019t be patched: it will continue to affect Apple\u2019s M1 and M2 CPUs for their entire lifespan. The only way to prevent this type of attack is by modifying encryption algorithms. One possibility involves restricting the calculations to the CPU\u2019s \u201cenergy-efficient\u201d cores, as DMP only works on \u201chigh-performance\u201d cores. Another one is obfuscating encryption keys before loading them into RAM. A side effect of these methods is performance degradation \u2014 but the user would hardly even notice. In turn, Apple M3 CPUs feature a special flag that disables DMP optimization for particularly sensitive operations.<\/p>\n

Let\u2019s summarize. There\u2019s no immediate threat to data stored on Apple devices \u2014 hardly anyone would try using a technique this complex to steal that data. Nevertheless, the work of these U.S. researchers is still valuable because it sheds some light on hitherto-unknown operating aspects of how the latest CPUs work. Their efforts aim to prevent future problems that might arise if an easier exploit is discovered.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

We review a recent research paper highlighting a major hardware vulnerability in Apple M1, M2, and M3 CPUs.<\/p>\n","protected":false},"author":665,"featured_media":22548,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1318,1916,1917],"tags":[14,1997,268],"class_list":{"0":"post-22545","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-apple","11":"tag-cpu","12":"tag-vulnerabilities"},"hreflang":[{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/apple-cpu-encryption-vulnerability\/22545\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/apple-cpu-encryption-vulnerability\/27240\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/apple-cpu-encryption-vulnerability\/29914\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/apple-cpu-encryption-vulnerability\/27412\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/apple-cpu-encryption-vulnerability\/37217\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/apple-cpu-encryption-vulnerability\/50869\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/apple-cpu-encryption-vulnerability\/27590\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/apple-cpu-encryption-vulnerability\/33419\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/apple-cpu-encryption-vulnerability\/33046\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/me-en.kaspersky.com\/blog\/tag\/cpu\/","name":"CPU"},"_links":{"self":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/22545","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/665"}],"replies":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=22545"}],"version-history":[{"count":1,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/22545\/revisions"}],"predecessor-version":[{"id":22547,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/22545\/revisions\/22547"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/22548"}],"wp:attachment":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=22545"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=22545"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=22545"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}