Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New vuln in Apple M-series allowing secret keys extraction can't be patched

twitter.com

Post reply on HN
Print view View original

41–50 of 145 posts

Re: New vuln in Apple M-series allowing secret keys extraction can't be patched

#41

Post by eru »

tsimionescu wrote: post #38
mort96 wrote: post #35

Earlier quoted context omitted.

OpenSSL is "trusted code". The problem isn't that OpenSSL is doing something nefarious, but that the CPU breaks assumptions it makes about how one can write constant-time algorithms.

But the problem is not OpenSSL, it's that malicious code on the system can read the keys OpenSSL is using. If you don't run malicious code on the same system as OpenSSL, this attack goes away - there's no way to run a CPU timing attack from a different network.

Anything you execute on behalf of a user, even if the binaries are trusted, can effectively become untrusted code.

Re: New vuln in Apple M-series allowing secret keys extraction can't be patched

#42

Post by eru »

tsimionescu wrote: post #36
amelius wrote: post #31

Earlier quoted context omitted.

> For cryptographic applications yes. Why only cryptographic applications? What if I'm writing a very sensitive e-mail, for instance?

For this type of attack to work, the algorithm being run needs to be very well understood, and the runtime of the algorithm needs to depend almost entirely on the secret key. In contrast, the timing of virtually any email operation is not dependent on the contents of the email, other than the size. That is, whether you wrote "my password is hunter2" or "my password is passwor", the timing of any operation running on…

> In contrast, the timing of virtually any email operation is not dependent on the contents of the email, other than the size.

What about spell checkers etc? Or even just whatever runs to figure out where to break the lines?

Re: New vuln in Apple M-series allowing secret keys extraction can't be patched

#44

Post by tsimionescu »

amelius wrote: post #32
midtake wrote: post #14

> The threat resides in the chips’ data memory-dependent prefetcher, a hardware optimization that predicts the memory addresses of data that running code is likely to access in the near future. Are we nearing any sort of consensus that any form of speculation is bad? Is there a fundamentally secure way to do it?

Perhaps we should do the crypto in constant time, and run all other applications using homomorphic encryption?

FHE is unusably slow even for the simplest operations, and there is no reason to be sure it will ever be fast enough for any normal computing.

Re: New vuln in Apple M-series allowing secret keys extraction can't be patched

#45

Post by legutierr »

bhawks wrote: post #21
midtake wrote: post #14

> The threat resides in the chips’ data memory-dependent prefetcher, a hardware optimization that predicts the memory addresses of data that running code is likely to access in the near future. Are we nearing any sort of consensus that any form of speculation is bad? Is there a fundamentally secure way to do it?

For cryptographic applications yes. That is why people have spent significant effort to implement constant time algorithms to replace standard math and bitwise operations. At the hardware level any optimizations that change performance characteristics locally (how long the crypto operation directly takes) or non locally (in this case the secrets leak via observation of cache timings in the attacker's untrusted code)…

> Where possible try utilizing HSMs, yubikeys, secure enclaves - any specialized hardware that has been hardened to protect key material.

Are there any circumstances where this hardware is accessible in the browser? As I understand, it is not generally available (if at all) for any cryptography you might want to do in the browser.

Re: New vuln in Apple M-series allowing secret keys extraction can't be patched

#47

Post by mort96 »

tsimionescu wrote: post #38
mort96 wrote: post #35

Earlier quoted context omitted.

OpenSSL is "trusted code". The problem isn't that OpenSSL is doing something nefarious, but that the CPU breaks assumptions it makes about how one can write constant-time algorithms.

But the problem is not OpenSSL, it's that malicious code on the system can read the keys OpenSSL is using. If you don't run malicious code on the same system as OpenSSL, this attack goes away - there's no way to run a CPU timing attack from a different network.

From what I understand, the problem is that algorithms which should be constant time are actually taking a variable amount of time depending on the data. If I have some server software whose security depends on those constant-time algorithms actually being constant time, why shouldn't this be exploitable over the network?

Re: New vuln in Apple M-series allowing secret keys extraction can't be patched

#48

Post by tsimionescu »

eru wrote: post #42
tsimionescu wrote: post #36

Earlier quoted context omitted.

For this type of attack to work, the algorithm being run needs to be very well understood, and the runtime of the algorithm needs to depend almost entirely on the secret key. In contrast, the timing of virtually any email operation is not dependent on the contents of the email, other than the size. That is, whether you wrote "my password is hunter2" or "my password is passwor", the timing of any operation running on…

> In contrast, the timing of virtually any email operation is not dependent on the contents of the email, other than the size. What about spell checkers etc? Or even just whatever runs to figure out where to break the lines?

Perhaps those could be attacked. It's possible though that it's not feasible, that the possible inputs leading to a certain timing signature are just too many to get any data out of it.

Consider that those programs are not making any effort whatsoever to run in constant time, and yet no one has shown any timing attack against them. OpenSSL has taken great pains to have constant execution time, and yet subtle processor features like this still introduce enough time differences to recover the keys.

Re: New vuln in Apple M-series allowing secret keys extraction can't be patched

#49

Post by tsimionescu »

mort96 wrote: post #47
tsimionescu wrote: post #38

Earlier quoted context omitted.

But the problem is not OpenSSL, it's that malicious code on the system can read the keys OpenSSL is using. If you don't run malicious code on the same system as OpenSSL, this attack goes away - there's no way to run a CPU timing attack from a different network.

From what I understand, the problem is that algorithms which should be constant time are actually taking a variable amount of time depending on the data. If I have some server software whose security depends on those constant-time algorithms actually being constant time, why shouldn't this be exploitable over the network?

Because the timing difference is extraordinarily subtle, far too small to measure compared to regular network timing noise.

Re: New vuln in Apple M-series allowing secret keys extraction can't be patched

#50

Post by pjc50 »

bhawks wrote: post #21
midtake wrote: post #14

> The threat resides in the chips’ data memory-dependent prefetcher, a hardware optimization that predicts the memory addresses of data that running code is likely to access in the near future. Are we nearing any sort of consensus that any form of speculation is bad? Is there a fundamentally secure way to do it?

For cryptographic applications yes. That is why people have spent significant effort to implement constant time algorithms to replace standard math and bitwise operations. At the hardware level any optimizations that change performance characteristics locally (how long the crypto operation directly takes) or non locally (in this case the secrets leak via observation of cache timings in the attacker's untrusted code)…

It's infuriating that all modern computers have a secure crypto TPM, but you're explicitly not allowed to use it for your own important keys, it's only for securing things against you like the DRM in certain drivers.
Post reply on HN