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

X86 is a high-level language

blog.erratasec.com

Post reply on HN
Print view View original

81–90 of 125 posts

Re: X86 is a high-level language

#81

Post by nightcracker »

CHY872 wrote: post #46
xenophonf wrote: post #37

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 disagree. The risk is not that the hardware encryption module like AES-NI encrypts _wrong_, at all.

The risk is that it's possible to escrow the last N used AES-NI keys within the chip, and extract them using custom non-public microcode or physical access.

Re: X86 is a high-level language

#82

Post by wtallis »

vilhelm_s wrote: post #70
CHY872 wrote: post #46

Earlier quoted context omitted.

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…

Incidentally, D.J. Bernstein argues that hashing an additional randomness source sometimes _can_ hurt: http://blog.cr.yp.to/20140205-entropy.html 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.

Yeah, I've always found it odd how proponents of various entropy combining methods think it's reasonable to be afraid of hardware smart enough to know when to sabotage the RNG, but think it's unrealistic to postulate that it would also know the right way to poison their entropy pool.

Re: X86 is a high-level language

#83

Post by matthewmacleod »

JonnieCache wrote: post #23
matthewmacleod wrote: post #18

Earlier quoted context omitted.

That's not an effective technique, unfortunately. You still end up leaking timing information. Lets say you add a small, random sleep after each operation – this still leaks information, as the delay can be averaged out over multiple runs. A fixed sleep after each operation is no use either, for obvious reasons. One approach I've seen is to break time into discrete quanta – for example, you could guarantee that every…

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.

As far as I can tell, that would not be secure – wouldn't it end up being essentially cryptographically secure random timing noise? We already know that random jitter doesn't work, because it can be averaged out given enough samples.

I'm not a cryptography guy though, so I could well be wrong!

Re: X86 is a high-level language

#84

Post by matthewmacleod »

mreiland wrote: post #77
matthewmacleod wrote: post #31

Earlier quoted context omitted.

The problem there is that sleeping alters the performance characteristics of your system. If an attacker submits multiple requests simultaneously, it would be possible for them to determine if you were actually working, or just sleeping - and you're back to leaking. Sure, every confounding factor makes it more difficult to extract information. But there are many effective techniques for doing so, and we keep getting…

> If an attacker submits multiple requests simultaneously, it would be possible for them to determine if you were actually working, or just sleeping - and you're back to leaking. how?

The basic cause of a timing attack is that if cryptographic operations can take different amounts of time depending on the content, then we can potentially be leaking information to an attacker. If we try to solve this by padding our work using sleep() or similar, we might reveal less information directly – but the performance characteristics of our machine will still be different when we complete and operation quickly then sleep, versus when we complete an option slowly and sleep for less time.

Here's a not-at-all real-world example – say an attacker causes a cryptographic operation to happen, while at the same time monitoring the time taken to respond to a ping request. Ignoring loads of complexity, we might find that a machine takes slightly longer to respond to a ping when it is performing an operation (i.e. the CPU is busy) than when it is sleeping. If that's the case, we're suddenly leaking timing information again.

Re: X86 is a high-level language

#85

Post by [deleted] »

JonnieCache wrote: post #23
matthewmacleod wrote: post #18

Earlier quoted context omitted.

That's not an effective technique, unfortunately. You still end up leaking timing information. Lets say you add a small, random sleep after each operation – this still leaks information, as the delay can be averaged out over multiple runs. A fixed sleep after each operation is no use either, for obvious reasons. One approach I've seen is to break time into discrete quanta – for example, you could guarantee that every…

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.

[deleted]

Re: X86 is a high-level language

#86

Post by CHY872 »

nightcracker wrote: post #81
CHY872 wrote: post #46

Earlier quoted context omitted.

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 disagree. The risk is not that the hardware encryption module like AES-NI encrypts _wrong_, at all. The risk is that it's possible to escrow the last N used AES-NI keys within the chip, and extract them using custom non-public microcode or physical access.

That's fanciful. If your hardware is vulnerable to such an extent, you might as well keel over and give up on any security. For example, such hardware could reasonably be expected to occasionally scan main memory for crypto keys in the first place, or perhaps install an SSH server and a root user, or...

Again, the reason why people care (or rather, should care) about RNGs is because it's theoretically very easy to tamper with them and very hard to then detect such tampering unless you're actively looking for it: http://arstechnica.com/security/2013/09/researchers-can-slip...

Re: X86 is a high-level language

#87

Post by [deleted] »

nightcracker wrote: post #81
CHY872 wrote: post #46

Earlier quoted context omitted.

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 disagree. The risk is not that the hardware encryption module like AES-NI encrypts _wrong_, at all. The risk is that it's possible to escrow the last N used AES-NI keys within the chip, and extract them using custom non-public microcode or physical access.

[deleted]

Re: X86 is a high-level language

#88

Post by DrJokepu »

stephencanon wrote: post #74
DrJokepu wrote: post #72

Forget the controversial opinion and drama, let's talk about something technical, how does the mov eax, ebx thing work? He said it will update eax to point to the same underlying register ebx points to. But then what happens when something like mov ebx, 9000h is executed? How does the CPU know that this will only apply to ebx, not eax?

The subsequent mov ebx, 9000h will cause ebx to "point to" a new underlying register, leaving the one that corresponds to eax intact.

So every time a new value is loaded into one of the "high level" registers, it's actually loaded into a new underlying register? So the underlying registers are basically immutable?

Re: X86 is a high-level language

#89

Post by CHY872 »

vilhelm_s wrote: post #70
CHY872 wrote: post #46

Earlier quoted context omitted.

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…

Incidentally, D.J. Bernstein argues that hashing an additional randomness source sometimes _can_ hurt: http://blog.cr.yp.to/20140205-entropy.html 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.

This sort of attack would be easy to defeat, though. For example, one fix would be to precompute a few megs of randomness data from your hardware source, and only use it after a few minutes have passed since generation. If the malicious RNG can predict the contents of the rest of the pool after this time (without modifying them) then there are bigger problems with the randomness generation.

Re: X86 is a high-level language

#90

Post by na85 »

kazinator wrote: post #71
scott_s wrote: post #43

Earlier quoted context omitted.

It used to be that the x86 instruction set was representative of the processor architecture that it programmed. That is no longer the case. Now, it is valid to view the x86 instruction set as an abstraction of the processor architecture. That is, you can mostly pretend that the processor you're programming for is accurately represented by the architecture implied by the x86 instruction set, but it is not. And when it…

I would say that the x86 abstraction is now more distant from the actual design of the hardware, not higher .

>I would say that the x86 abstraction is now more distant from the actual design of the hardware, not higher.

Those are equivalent terms to all but the most obstinate pedants.

Post reply on HN