![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
erek
[H]F Junkie
- Joined
- Dec 19, 2005
- Messages
- 10,900
Apple's M-based CPUs are at fault
"Like other microarchitectural CPU side channels, the one that makes GoFetch possible can’t be patched in the silicon. Instead, responsibility for mitigating the harmful effects of the vulnerability falls on the people developing code for Apple hardware. For developers of cryptographic software running on M1 and M2 processors, this means that in addition to constant-time programming, they will have to employ other defenses, almost all of which come with significant performance penalties.
One of the most effective mitigations, known as ciphertext blinding, is a good example. Blinding works by adding/removing masks to sensitive values before/after being stored to/loaded from memory. This effectively randomizes the internal state of the cryptographic algorithm, preventing the attacker from controlling it and thus neutralizing GoFetch attacks. Unfortunately, the researchers said, this defense is both algorithm-specific and often costly, potentially even doubling the computing resources needed in some cases, such as for Diffie-Hellman key exchanges.
One other defense is to run cryptographic processes on the previously mentioned efficiency cores, also known as Icestorm cores, which don't have DMP. One approach is to run all cryptographic code on these cores. This defense, too, is hardly ideal. Not only is it possible for unannounced changes to add DMP functionality to efficiency cores, running cryptographic processes here will also likely increase the time required to complete operations by a nontrivial margin. The researchers mention several ad-hoc defenses, but they are equally problematic.
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.)
Advertisement
Readers should remember that whatever penalties result will only be felt when affected software is performing specific cryptographic operations. For browsers and many other types of apps, the performance cost may not be noticeable.
“Longer term, we view the right solution to be to broaden the hardware-software contract to account for the DMP,” the researchers wrote. “At a minimum, hardware should expose to software a way to selectively disable the DMP when running security-critical applications. This already has nascent industry precedent. For example, Intel’s DOIT extensions specifically mention disabling their DMP through an ISA extension. Longer term, one would ideally like finer-grain control, e.g., to constrain the DMP to only prefetch from specific buffers or designated non-sensitive memory regions.”
Apple representatives declined to comment on the record about the GoFetch research.
End users who are concerned should check for GoFetch mitigation updates that become available for macOS software that implements any of the four encryption protocols known to be vulnerable. Out of an abundance of caution, it’s probably also wise to assume, at least for now, that other cryptographic protocols are likely also susceptible.
“Unfortunately, to assess if an implementation is vulnerable, cryptanalysis and code inspection are required to understand when and how intermediate values can be made to look like pointers in a way that leaks secrets,” the researchers advised. “This process is manual and slow and does not rule out other attack approaches.”"
Source: https://arstechnica.com/security/20...secret-encryption-keys-from-apples-mac-chips/
"Like other microarchitectural CPU side channels, the one that makes GoFetch possible can’t be patched in the silicon. Instead, responsibility for mitigating the harmful effects of the vulnerability falls on the people developing code for Apple hardware. For developers of cryptographic software running on M1 and M2 processors, this means that in addition to constant-time programming, they will have to employ other defenses, almost all of which come with significant performance penalties.
One of the most effective mitigations, known as ciphertext blinding, is a good example. Blinding works by adding/removing masks to sensitive values before/after being stored to/loaded from memory. This effectively randomizes the internal state of the cryptographic algorithm, preventing the attacker from controlling it and thus neutralizing GoFetch attacks. Unfortunately, the researchers said, this defense is both algorithm-specific and often costly, potentially even doubling the computing resources needed in some cases, such as for Diffie-Hellman key exchanges.
One other defense is to run cryptographic processes on the previously mentioned efficiency cores, also known as Icestorm cores, which don't have DMP. One approach is to run all cryptographic code on these cores. This defense, too, is hardly ideal. Not only is it possible for unannounced changes to add DMP functionality to efficiency cores, running cryptographic processes here will also likely increase the time required to complete operations by a nontrivial margin. The researchers mention several ad-hoc defenses, but they are equally problematic.
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.)
Advertisement
Readers should remember that whatever penalties result will only be felt when affected software is performing specific cryptographic operations. For browsers and many other types of apps, the performance cost may not be noticeable.
“Longer term, we view the right solution to be to broaden the hardware-software contract to account for the DMP,” the researchers wrote. “At a minimum, hardware should expose to software a way to selectively disable the DMP when running security-critical applications. This already has nascent industry precedent. For example, Intel’s DOIT extensions specifically mention disabling their DMP through an ISA extension. Longer term, one would ideally like finer-grain control, e.g., to constrain the DMP to only prefetch from specific buffers or designated non-sensitive memory regions.”
Apple representatives declined to comment on the record about the GoFetch research.
End users who are concerned should check for GoFetch mitigation updates that become available for macOS software that implements any of the four encryption protocols known to be vulnerable. Out of an abundance of caution, it’s probably also wise to assume, at least for now, that other cryptographic protocols are likely also susceptible.
“Unfortunately, to assess if an implementation is vulnerable, cryptanalysis and code inspection are required to understand when and how intermediate values can be made to look like pointers in a way that leaks secrets,” the researchers advised. “This process is manual and slow and does not rule out other attack approaches.”"
Source: https://arstechnica.com/security/20...secret-encryption-keys-from-apples-mac-chips/
![Zarathustra[H]](https://cdn.hardforum.com/data/avatars/m/9/9298.jpg?1707758471){kind=avatar}
