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

51–60 of 145 posts

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

#51

Post by adrianN »

tsimionescu wrote: post #49
mort96 wrote: post #47

Earlier quoted context omitted.

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.

That usually just means that you need to collect more data to filter out the network noise.

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

#52

Post by mort96 »

tsimionescu wrote: post #49
mort96 wrote: post #47

Earlier quoted context omitted.

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.

Noise doesn't protect against that, statistics is a thing.

But I think you might overall be right that this requires two colocated processes: the paper talks about how the DMP breaks assumptions made by "the constant-time programming model", and I took this to mean that constant-time algorithms aren't constant-time any more. Reading more closely, I think maybe the issue is that "the constant-time programming model" was also assumed to make secrets safe from cache timing side-channels leaking the secrets to other processes on the same CPU, and this seems like it might be the assumption that's broken by the DMP...

I'll have to read more, I've just skimmed the abstract and introduction so far.

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

#54

Post by realjhol »

pjc50 wrote: post #50
bhawks wrote: post #21

Earlier quoted context omitted.

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.

[dead]

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

#55

Post by robin_reala »

PhilipRoman wrote: post #37
bhawks wrote: post #28

Earlier quoted context omitted.

So you browse the Internet with JavaScript turned off? You're a bigger person than I am ;). The risk here is that there are more individuals with the skills to take this type of attack and bring it to a browser near you. One apps data is another apps code.

Indeed, the scary thing is that there is no theoretical limit to how sophisticated a side channel attack could be. Imagine all the timing data that could in theory be gathered from html layout engines and css, even without javascript, just by resource loading times. I would like to salute my shitty ISP for keeping me safe from timing attacks using their unreliable network infrastructure.

This attack is now why browsers segment caching into a combination of requesting domain and asset URL, rather than just caching the asset on its own. It slows down for example Google Fonts, but means that a site can’t check to see that you’ve visited a competitor by timing an asset load from their site to see whether it’s in the cache.

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

#56

Post by bhawks »

pjc50 wrote: post #50
bhawks wrote: post #21

Earlier quoted context omitted.

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.

Android has user visible APIs to interact with secure crypto hardware.

https://developer.android.com/privacy-and-security/keystore#...

But I agree in general with your point

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

#58

Post by bawolff »

mort96 wrote: post #33
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?

This isn't speculative execution. EDIT: The downvotes make no sense. What this bug has in common with Spectre is that it has to do with cache timing. But in Spectre, the cache is affected by speculative execution; with "GoFetch", it's the pre-fetcher pre-fetching things which look like memory addresses. Pre-fetching is not speculative execution.

Unless the comment was edited, the person you are responded to did not use the phrase "speculative execution"

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

#59

Post by pmontra »

PhilipRoman wrote: post #24
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?

My personal opinion is that we should solve it the opposite way - don't run untrusted code in the first place (with rare exceptions like dedicating an entire cpu core and a region of memory to a virtual machine, etc). Speculation is one of many side channel attacks, who knows what kind of crazy RF-based exploits are out there. AFAIK we still haven't fully solved rowhammer. I think for "normal" users the main risk is…

So, CPUs or cores (and maybe RAM) dedicated to run only trusted and only untrusted code?

Examples (I'm running Debian)

The kernel, the X11 server, terminal, ssh, bash, anything coming from the official Debian repos including the password manager: in the trusted environment.

browsers, electron apps, anything installed from unofficial repos or language and package managers (npm, rvm, asdf, etc): in the untrusted environment.

It reminds me of mainframes and their redundant and compartmentalized hardware architecture.

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

#60

Post by layer8 »

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?

Disabling all hardware optimizations becomes an option long before homomorphic encryption becomes an option, performance-wise.
Post reply on HN