Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 15 submissions in the queue.
posted by mrpg on Sunday March 24, @02:59AM   Printer-friendly
from the oops dept.

https://arstechnica.com/security/2024/03/hackers-can-extract-secret-encryption-keys-from-apples-mac-chips/

A newly discovered vulnerability baked into Apple's M-series of chips allows attackers to extract secret keys from Macs when they perform widely used cryptographic operations, academic researchers have revealed in a paper published Thursday.

The flaw—a side channel allowing end-to-end key extractions when Apple chips run implementations of widely used cryptographic protocols—can't be patched directly because it stems from the microarchitectural design of the silicon itself.
[...]
cryptographic engineers have devised constant-time programming, an approach that ensures that all operations take the same amount of time to complete, regardless of their operands. It does this by keeping code free of secret-dependent memory accesses or structures.

The breakthrough of the new research is that it exposes a previously overlooked behavior of DMPs in Apple silicon: Sometimes they confuse memory content, such as key material, with the pointer value that is used to load other data. As a result, the DMP often reads the data and attempts to treat it as an address to perform memory access. This "dereferencing" of "pointers"—meaning the reading of data and leaking it through a side channel—is a flagrant violation of the constant-time paradigm.
[...]
The attack, which the researchers have named GoFetch, uses an application that doesn't require root access, only the same user privileges needed by most third-party applications installed on a macOS system.
[...]
The GoFetch app connects to the targeted app and feeds it inputs that it signs or decrypts. As its doing this, it extracts the app secret key that it uses to perform these cryptographic operations. This mechanism means the targeted app need not perform any cryptographic operations on its own during the collection period.
[...]
The DMP on the M3, Apple's latest chip, has a special bit that developers can invoke to disable the feature. The researchers don't yet know what kind of penalty will occur when this performance optimization is turned off. (The researchers noted that the DMP found in Intel's Raptor Lake processors doesn't leak the same sorts of cryptographic secrets. What's more, setting a special DOIT bit also effectively turns off the DMP.)

Arthur T Knackerbracket has processed the following story:

A new vulnerability was found on M1 Mac and newer models that allow hackers to extract encryption keys. This issue is unpatchable, which means every Mac user could be compromised, but it doesn’t mean you should freak out. [Physical access to the computer is required--JR]

[...] The researcher named this vulnerability GoFetch, a “microarchitectural side-channel attack that can extract secret keys from constant-time cryptographic implementations via data memory-dependent prefetchers (DMPs).”

They have found this issue with M1 Mac devices but found that M2 and M3 CPUs also exhibit “similar exploitable DMP behavior.” They have not tested with other chip variants, such as M1 Max, M2 Pro, etc., but the researchers hypothesize that they’re likely to be exploited as well.

The researchers say that the best way to protect yourself is by constantly updating your Mac to the latest version of macOS. For developers of cryptographic libraries, they can either set the DOIT bit and DIT bit bits, which disable the DMP on some CPUs, such as M3 processors.

Still, the best way to avoid this attack is by preventing others from physically accessing your M1 Mac computer: “Preventing attackers from measuring DMP activation in the first place, for example, by avoiding hardware sharing, can further enhance the security of cryptographic protocols.”


Original Submission

This discussion was created by mrpg (5708) for logged-in users only, but now has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 2) by hendrikboom on Sunday March 24, @01:11PM (3 children)

    by hendrikboom (1125) Subscriber Badge on Sunday March 24, @01:11PM (#1350091) Homepage Journal

    I cannot understand the attack without knowing what the DMP is and does.

    • (Score: 3, Informative) by janrinok on Sunday March 24, @01:37PM

      by janrinok (52) Subscriber Badge on Sunday March 24, @01:37PM (#1350093) Journal

      Data Operand Independent Timing (DOIT)

      Data Memory-dependent Prefetcher (DMP)

      --
      I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
    • (Score: 5, Informative) by janrinok on Sunday March 24, @01:40PM

      by janrinok (52) Subscriber Badge on Sunday March 24, @01:40PM (#1350095) Journal

      (From the source)

      Prefetchers usually look at addresses of accessed data (ignoring values of accessed data) and try to guess future addresses that might be useful. The DMP is different in this sense as in addition to addresses it also uses the data values in order to make predictions (predict addresses to go to and prefetch). In particular, if a data value “looks like” a pointer, it will be treated as an “address” (where in fact it's actually not!) and the data from this “address” will be brought to the cache. The arrival of this address into the cache is visible, leaking over cache side channels.

      Our attack exploits this fact. We cannot leak encryption keys directly, but what we can do is manipulate intermediate data inside the encryption algorithm to look like a pointer via a chosen input attack. The DMP then sees that the data value “looks like” an address, and brings the data from this “address” into the cache, which leaks the “address.” We don’t care about the data value being prefetched, but the fact that the intermediate data looked like an address is visible via a cache channel and is sufficient to reveal the secret key over time

      .

      --
      I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
    • (Score: 4, Interesting) by VLM on Sunday March 24, @04:43PM

      by VLM (445) on Sunday March 24, @04:43PM (#1350109)

      As for what it does I have no good automobile analogy, but I have a bad one.

      Let's say you are stopped at an onramp waiting your turn to enter the interstate. You can predict ahead of time when you'll be moving before you need to move if you look ahead, so if everyone plays along intelligently (good luck) you can take your foot off the brake before the car ahead actually moves and by the time it moves you'll also move, efficient! So if you know the pattern of green lights ahead of time you are kind of leaking the information about how many (if any) cars are in front of you at the light. This was NOT baked into the traffic design but the people implementing driving did it all on their own.

      I bet, if you had short range doppler radar signal and the streetlight signal, a smart traffic light could predict pretty accurately how many cars in in line without directly counting them, just knowing the pattern of movement. Thats not something they intentionally teach you to do at driving school but it is an inadverent implementation dependent information leak.

(1)