161–170 of 406 posts
Earlier quoted context omitted.
Simplest solution here is to implement the algorithm in hardware, with a new instruction that has all the security attributes. (Including resistance to power differential and timing differential attacks.) Downthread: https://news.ycombinator.com/item?id=31745105
But this is inflexible.
But did you want a microcode vulnerability? That'd make for another one of these awesome HN discussions...
Earlier quoted context omitted.
> What can you do about it? Nerf your CPU performance by disabling "turbo boost" or equivalent. A server running a multithreaded load is probably disabling turbo boost anyway because of the thermal load on the package already. Instead, you should disable speedstep and set your systems to maximum performance. However, this will increase the heat and your power bill considerably.
I was thinking about busy servers running mixed workloads. I would think that, with the CPU running a bunch of workloads on different cores, context switching, etc, it wouldn't be a practical attack. Maybe that's incorrect. Mostly idle servers are a different story, obviously.
In that scenario, mixed loads won't help. You'll have at least one pinned core, and it can scale relative to the VMs load (considering you also pin hypervisor cores, etc). So, it's possible to hit that pinned core and execute the same timing attack.
I know it's a niche scenario, but it's not an impossible or implausible one. Another possibility is the servers which fill critical roles, but they're idle or in a constant low-load state to have headspace for high loads. Again, attacking these servers are plausible. Considering these servers are not open to internet most of the time, we're bordering on corporate espionage, but it's not the subject here.
Ok, I See how this works in theory. But until I see an exploit that uses this method in real life to extract keys (or maybe any memory content) from a server running real life workloads, I am extremely skeptical. How much samples are needed to get anything useful? And wouldn't the time required to acquire these samples be longer than the time required to detect the attack (or even all keys to be shifted)?
Seems like the simplest way to mitigate is to randomly throw some junk at the problem. Some random cypto code, some random no-purpose cryptographic calculations, should prevent any listener from gaining any useful information. It shouldn't take much, a single-digit percentage increase during cypto functions would be enough imho.
like most things, i expect the reason they’re not adopted for consumer devices is because they use notably more power/area/are slower.
[1] enter "Provably Secure Masking of AES" into scihub and you'll find a useful paper by Blömer, Merchan and Krummel from 2004.
Earlier quoted context omitted.
This is not inconsistent with what I said.
Isn't it? It probably wouldn't require any novel statistical techniques.
But I would like to see some statistical expectations on 'how long you'd have to wait on an average open network for each key bit to reach 95% confidence'.
Earlier quoted context omitted.
> What can you do about it? Nerf your CPU performance by disabling "turbo boost" or equivalent. A server running a multithreaded load is probably disabling turbo boost anyway because of the thermal load on the package already. Instead, you should disable speedstep and set your systems to maximum performance. However, this will increase the heat and your power bill considerably.
A spike performance up, random delay in down might be sufficient mitigation on a multi-tenant platform.
A random hysteresis is bad from a system responsiveness aspect, because frequency scaling is not free (in terms of time) when observed from the CPU perspective.
We need an industry-wide effort for coordination between cryptography library owners & device/chip vendors to ensure the use of constant CPU frequencies during cryptographic operations. It's odd that the authors haven't chosen to initiate this themselves, as it seems like the proper solution to this vulnerability.
There are special CPU instructions to help speed up cryptographic algorithms, but applying countermeasures to these is not always crucial. They only matter if an attacker could otherwise create a side-channel. This applies in TLS, but not, e.g., when verifying checksums of downloaded software.
Interesting, and seems like a natural followup to this side channel: http://www.cs.tau.ac.il/~tromer/papers/acoustic-20131218.pdf (RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis), in which researchers deduced that the high-pitched sounds made by CPUs could leak the operations that GPG was performing to decrypt some encrypted content, and thus leak the private key. All you need is a microphone and the abi…
I'm not a hardware expert, and I was a bit surprised at this.
Is that because the transistors heat up more with certain input values, which then results in a lower frequency when the CPU gets hot enough? Something like AND(1,1) using more energy than AND(1,0) on the transistor level?
As far as I can tell [1], addition typically takes a constant number of cycles on x86 CPUs at least, so any difference should happen at a very low level.
> This means that, on modern processors, the same program can run at a different CPU frequency (and therefore take a different wall time) when computing, for example, 2022 + 23823 compared to 2022 + 24436. I'm not a hardware expert, and I was a bit surprised at this. Is that because the transistors heat up more with certain input values, which then results in a lower frequency when the CPU gets hot enough? Something…
As such it's possible that 0x00000000 + 1 uses up significantly less energy than 0xffffffff + 1, just because of all the bit flips.
That's just a guess though.