61–70 of 125 posts
Earlier quoted context omitted.
The solution i've seen is: sleep(float(hash(request_content)) % n) this assumes that the attacker cannot control any non-relevant part of request_content.
This seems like it's insecure if the attacker can predict request_content, too.
Earlier quoted context omitted.
This is only if the channel is a purely-external measurement of the computation, e.g. total turnaround time time to a result. A sleep won't do anything to mask a side-channel which involves (sometimes obscure) access to the actual work being done by the processor.
Up-voting the parent. There are attacks such as FLUSH-RELOAD which are today difficult to avoid on modern hardware and allow this sort of introspection into the CPU instructions and their timings. Of course, there are a whole range of active and valid side-channels that are readily exploitable today. These are no longer NOBUS vulnerabilities, but are increasingly within the range and scope of ordinary attackers.
The author's conclusion that side channel attacks are unpreventable because x86 instructions execute in a variable amount of time does not follow. Side channel attacks that rely on variable instruction timing rely on _content-dependent_ timing. For example, the time spent for a mov from a memory location does not depend on the contents of the memory, but it does depend on the address of that memory. If that address i…
Something interesting to note is that at least in the Pentium 4, the number of cycles spent on integer division instructions varies depending on the values of the operands [1]. [1] https://gmplib.org/~tege/x86-timing.pdf (pages 4 & 6)
I wonder if introducing a sleep that is longer than the computation could conceivably take would work to solve (or at least make it a lot harder to defeat) the actual problem. The failure case where the computation actually is slow enough to matter could be detected and thrown away. This of course would require a fully async crypto lib..
How about random sleeps distributed so that the mean sleep time is always the same for every computation? (and much longer than any likely computation). timer.start(); computation(); time = timer.stop(); sleep(random_centered_on(mean-time));
And it doesn't prevent against indirect sidechannels. For instance, seeing how long other requests take.
Earlier quoted context omitted.
I think that's the author's point: x86 is now a significant abstraction from the actual details of execution.
That's true of all superscalar machines. That's what killed RISC. The original idea of RISC was one instruction per clock and a very simple CPU control section. Early MIPS CPUs realized that. Then superscalar came to microprocessors with the Pentium Pro. It took 3000 engineers at Intel to design that CPU, but it did much better than one instruction per clock while still handling all the weird cases in x86 instruction…
1: https://neosmart.net/blog/2010/the-arm-the-ppc-the-x86-and-t...
Earlier quoted context omitted.
Up-voting the parent. There are attacks such as FLUSH-RELOAD which are today difficult to avoid on modern hardware and allow this sort of introspection into the CPU instructions and their timings. Of course, there are a whole range of active and valid side-channels that are readily exploitable today. These are no longer NOBUS vulnerabilities, but are increasingly within the range and scope of ordinary attackers.
And relevant to the post re: sleep, there are things like Cross-VM side channels[1], an important consideration given how much infrastructure runs in shared environments these days. [1] PDF: https://www.cs.unc.edu/~reiter/papers/2012/CCS.pdf
Earlier quoted context omitted.
The timing is a signal, and you're proposing to mask that signal by adding noise. This does work, but you can work around it by gathering more samples and averaging out the noise. You increase the work required from an attacker, but it's not insurmountable.
What if you use random noise from a Cauchy distribution? It (interestingly enough) has no mean, so the amount of time the attacker thinks she has to subtract from her average depends on the number of samples that she takes, and does not converge as she increases the number of samples.
Earlier quoted context omitted.
I think that's the author's point: x86 is now a significant abstraction from the actual details of execution.
That's true of all superscalar machines. That's what killed RISC. The original idea of RISC was one instruction per clock and a very simple CPU control section. Early MIPS CPUs realized that. Then superscalar came to microprocessors with the Pentium Pro. It took 3000 engineers at Intel to design that CPU, but it did much better than one instruction per clock while still handling all the weird cases in x86 instruction…
I'm not really sure that is a big deal today, however. Maybe it was when caches were much smaller, but AArch64 went back from a variable width encoding scheme (Thumb) to uniform width instructions in 64-bit mode, without any problems that I'm aware of, and the performance is quite good. At the same time, the x86-64 ISA has gotten quite a bit less space-efficient: because of the extension to 16 registers, REX prefixes are everywhere and eat up lots of bytes of the instruction stream.
Earlier quoted context omitted.
What if you use random noise from a Cauchy distribution? It (interestingly enough) has no mean, so the amount of time the attacker thinks she has to subtract from her average depends on the number of samples that she takes, and does not converge as she increases the number of samples.
Attacker uses the median
Earlier quoted context omitted.
There's a lot of fear surrounding in-hardware crypto primitives. See for example: http://arstechnica.com/security/2013/12/we-cannot-trust-inte... I personally would be very leery of OpenSSL relying on RdRand or AES-NI.
I think that you have extrapolated the legitimate concern around hardware random number generators to AES-NI, where it is not a legitimate concern. With random numbers, the point is that there's no good way to tell exactly how random something is, and it's quite easy to generate deterministic stuff that looks random. Furthermore, by changing a couple of transistors, you can destroy the randomness of Intel's generator…
I guess it would be difficult in practice to make a malicious hardware randomness source, but it's an interesting perspective; to have confidence in your algorithm you should carefully restrict where the randomness enters it.