Yup. A simple fast track for simple security problems.
1) work out solution 2) Implement & deploy solution as a hotfix same day 3) Spend 2 week massaging and validating the solution 4) Update the codebase with the validated solution (which may be identical).
I don't believe the authors attacked the Ivy Bridge RNG in the way described. They described a way, they didn't do it.
Why? 1) They show a plot of a DFFR_X1. This is a normal D type flip flop you would find in synopsis libraries and many other libraries you would use in an SoC process. These are not the flops used in the Ivy Bridge DRNG. Also the plot was from a layout program, not a micrograph.
2) The proposed attack required an average of 2.1 billion attacks (fixing k and v until you hit the right CRC). I don't think we sold 2 billion Ivy Bridges to these guys. The alternative they propose is to try it in simulation first. Running 2 billion simulations of full BIST would take a while and they don't have the code. If they had the RTL code they would be proposing other attacks.
3) They don't identify the site of the attack on the chip. They don't know where the site is.
4) They don't show RdRand output of a compromised chip. This would be trivial.
The main message of the article is sound. There are physical attacks that are hard to see optically. But the attack they describe against Ivy Bridge is hypothetical, based on the information in the CRI audit paper here: http://www.cryptography.com/public/pdf/Intel_TRNG_Report_20120312.pdf
I designed it (the SP800-90 part - much credit goes many other people for other parts). I understand the organization within which it was designed and manufactured. I know the vectors through which it could be subverted. It hasn't been subverted. I'd notice.
If it's for a crypto application that you want to be defended from a possible local attack, use it directly. The number is dropped straight into the register of the running application and hasn't visited cache or memory or disk or drivers or OS kernel or API. It's your problem to use is securely from then on, but the delivery path has a heck of a lot smaller attack surface.
If you are writing an OS for the general public, mix it into a pool, because that is what makes people happy. It doesn't make them more secure, but happy is good.
Don't read anything into expertise. Judge the quality of the argument.
That's why I said use have to take the values during successful packet reception so the receive chain is operating in a linear mode. Every receiver has a noise figure.
But this means it needs a custom kernel so adds complexity to an open source kernel like Linux when it has to work on a million different ARM based chips with undiscoverable busses.
Wireless devices without a quality hardware RNG (I.E. pretty much any phone without and intel processor in it) should get random noise from the radio receiver. Get it receiving packs (so the radio path is operating in a linear mode) and the demod is then working to separate symbols from noise. Just output the error vector of the modem during successful packet reception and you have an excellent and fast source of noise.
I don't think the kernel should use RdRand directly for/dev/urandom output unless the user provides a policy option to that effect, but without a policy option, the best thing for the OS to do is mix multiple sources. There are other reasons than tin-foil-hatdom to mistrust RdRand. You may mistrust your VM which could trap the instruction, so if running in a VM under the control of someone else, you may want to not credit RdRand (or anything else) with entropy. In fact, don't run anything security critical on a VM controlled by someone else. That's insane.
What is wrong is that RdRand is credited no entropy, so when RdRand is used, with its 70MB/s/thread output from the first post reset instruction, it doesn't prevent/dev/random blocking, which leads to people preferring/dev/urandom, which leaves them vulnerable to low entropy situations.
We provided an extremely conservative min-entropy for RdRand of 1/511 bits per bit. The actual is about 1 bit per bit, getting to no worse than 1/11 bits per bit when under maximum load (8+ threads executing RdRand as hard as they can on 4+ cores) but the design has a hard limit in hardware that prevents the answer being worse than 1/255.5 bits per bit. I.E. 'C' in the NIST SP800-90A CTR-DRBG cannot get to more that 511. So that's a maximum of 511 128 bit results for one fully entropic 256 bit seed. The bus can't pull fast enough to get C beyond 22.
I recommend you use RdRand directly. But I'm biased because RdRand is my thing.
Ted Tso, The linux kernel RNG maintainer said in the past couple of days on his Google+ page that he considers/dev/random unnecessary and is only keeping it around for backwards compatibility.
With that kind of commitment, what could possibly go wrong?
Yes. But I'm not going to give a well researched answer because I'm about to get on a plane.
Primarily the problem is that the Linux kernel RNG exists in many contexts and trusts that its random sources are random across all those contexts. This has been found to be false. The factorable.net study showing re-used primes between certs created on low-entropy router devices is an example of what can go wrong.
There are other more detailed things. The pool entropy calculations are flat out wrong. They are less wrong after Peter Anvin submitted a patch to have it do a piecwise approximation to a shannon entropy sum rather than an arithmetic sum, but it's not doing anything like a normal min-entropy computation for an entropy extraction algorithm.
The kernel trusts userland programs to be honest about the entropy in the sources. E.G. RNGd. However RNGd and other entropy gather daemon's have no basis on which to know the source entropy and so they make it up. The kernel takes this number and uses it in the pool entropy calculation. And so the whole calculation is built on sand.
The behavior of the kernel results in boot time entropy starvation, right at the point where you need it most.
This is RdRand changes the picture somewhat. The entropy source is well modeled and its min entropy is know. The resulting entropy from the condition is therefore known. The entropy seeding the DRBG is therefore know. It is therefore known how to extract full entropy output from RdRand, and it is known what the cryptographic resistance to brute for attack is (which is not quite the same thing). Such a chain of reasoning is what a good RNG should have.
You are better off using RdRand because it's available from the first instruction executed. It has known properties and the resulting numbers are not subject to the timing, memory API attacks that the kernel RNG numbers are subject to on the long winding path from device to RNGd to kernel API to kernel RNG to/dev/random to userland library to userland application.
Slashdot Mirror
This is no different to declaring the charge on an electron to be negative.
J.J Thompson only declared the electron negative because he wanted the pointy end of his Duracell to be positive.
Yup. A simple fast track for simple security problems.
1) work out solution
2) Implement & deploy solution as a hotfix same day
3) Spend 2 week massaging and validating the solution
4) Update the codebase with the validated solution (which may be identical).
I've never owned a car that doesn't have a TPMS light on, regardless of the state of the tires.
These ones of course:
ftp://ftp.apple.asimov.net/pub/apple_II/images/disk_utils/locksmith/
I used to have an Apple ][. I recently upgraded to an Apple //e.
With an uplink speed of 75bps.
And divine sauce.
His noodliness wishes to inform you that string theory is closer to the truth but the full truth is that the universe is made of strings of spaghetti.
This is wrong in so many ways.
I don't believe the authors attacked the Ivy Bridge RNG in the way described. They described a way, they didn't do it.
Why?
1) They show a plot of a DFFR_X1. This is a normal D type flip flop you would find in synopsis libraries and many other libraries you would use in an SoC process. These are not the flops used in the Ivy Bridge DRNG. Also the plot was from a layout program, not a micrograph.
2) The proposed attack required an average of 2.1 billion attacks (fixing k and v until you hit the right CRC). I don't think we sold 2 billion Ivy Bridges to these guys. The alternative they propose is to try it in simulation first. Running 2 billion simulations of full BIST would take a while and they don't have the code. If they had the RTL code they would be proposing other attacks.
3) They don't identify the site of the attack on the chip. They don't know where the site is.
4) They don't show RdRand output of a compromised chip. This would be trivial.
The main message of the article is sound. There are physical attacks that are hard to see optically. But the attack they describe against Ivy Bridge is hypothetical, based on the information in the CRI audit paper here: http://www.cryptography.com/public/pdf/Intel_TRNG_Report_20120312.pdf
It is not a defense against an attacker. It is a defense against manufacturing defects.
It is not news that if you re-wire a circuit, it changes.
Oracle? That explains it.
>What makes you sure it couldn't?
I designed it (the SP800-90 part - much credit goes many other people for other parts). I understand the organization within which it was designed and manufactured. I know the vectors through which it could be subverted. It hasn't been subverted. I'd notice.
If it's for a crypto application that you want to be defended from a possible local attack, use it directly. The number is dropped straight into the register of the running application and hasn't visited cache or memory or disk or drivers or OS kernel or API. It's your problem to use is securely from then on, but the delivery path has a heck of a lot smaller attack surface.
If you are writing an OS for the general public, mix it into a pool, because that is what makes people happy. It doesn't make them more secure, but happy is good.
Don't read anything into expertise. Judge the quality of the argument.
Now I'm drunk I can see that you were being funny, but I wasn't drunk earlier, so I though you were being serious and misinformed about radio systems.
That's why I said use have to take the values during successful packet reception so the receive chain is operating in a linear mode. Every receiver has a noise figure.
But this means it needs a custom kernel so adds complexity to an open source kernel like Linux when it has to work on a million different ARM based chips with undiscoverable busses.
Good god I can't type today. Argh.
Wireless devices without a quality hardware RNG (I.E. pretty much any phone without and intel processor in it) should get random noise from the radio receiver. Get it receiving packs (so the radio path is operating in a linear mode) and the demod is then working to separate symbols from noise. Just output the error vector of the modem during successful packet reception and you have an excellent and fast source of noise.
I don't think the kernel should use RdRand directly for /dev/urandom output unless the user provides a policy option to that effect, but without a policy option, the best thing for the OS to do is mix multiple sources. There are other reasons than tin-foil-hatdom to mistrust RdRand. You may mistrust your VM which could trap the instruction, so if running in a VM under the control of someone else, you may want to not credit RdRand (or anything else) with entropy. In fact, don't run anything security critical on a VM controlled by someone else. That's insane.
What is wrong is that RdRand is credited no entropy, so when RdRand is used, with its 70MB/s/thread output from the first post reset instruction, it doesn't prevent /dev/random blocking, which leads to people preferring /dev/urandom, which leaves them vulnerable to low entropy situations.
We provided an extremely conservative min-entropy for RdRand of 1/511 bits per bit. The actual is about 1 bit per bit, getting to no worse than 1/11 bits per bit when under maximum load (8+ threads executing RdRand as hard as they can on 4+ cores) but the design has a hard limit in hardware that prevents the answer being worse than 1/255.5 bits per bit. I.E. 'C' in the NIST SP800-90A CTR-DRBG cannot get to more that 511. So that's a maximum of 511 128 bit results for one fully entropic 256 bit seed. The bus can't pull fast enough to get C beyond 22.
That is only for hypervisors implementing lockstep mode.
I recommend you use RdRand directly. But I'm biased because RdRand is my thing.
Ted Tso, The linux kernel RNG maintainer said in the past couple of days on his Google+ page that he considers /dev/random unnecessary and is only keeping it around for backwards compatibility.
With that kind of commitment, what could possibly go wrong?
I am an RNG designer you dolt!
Yes. But I'm not going to give a well researched answer because I'm about to get on a plane.
Primarily the problem is that the Linux kernel RNG exists in many contexts and trusts that its random sources are random across all those contexts. This has been found to be false. The factorable.net study showing re-used primes between certs created on low-entropy router devices is an example of what can go wrong.
There are other more detailed things. The pool entropy calculations are flat out wrong. They are less wrong after Peter Anvin submitted a patch to have it do a piecwise approximation to a shannon entropy sum rather than an arithmetic sum, but it's not doing anything like a normal min-entropy computation for an entropy extraction algorithm.
The kernel trusts userland programs to be honest about the entropy in the sources. E.G. RNGd. However RNGd and other entropy gather daemon's have no basis on which to know the source entropy and so they make it up. The kernel takes this number and uses it in the pool entropy calculation. And so the whole calculation is built on sand.
The behavior of the kernel results in boot time entropy starvation, right at the point where you need it most.
This is RdRand changes the picture somewhat. The entropy source is well modeled and its min entropy is know. The resulting entropy from the condition is therefore known. The entropy seeding the DRBG is therefore know. It is therefore known how to extract full entropy output from RdRand, and it is known what the cryptographic resistance to brute for attack is (which is not quite the same thing). Such a chain of reasoning is what a good RNG should have.
You are better off using RdRand because it's available from the first instruction executed. It has known properties and the resulting numbers are not subject to the timing, memory API attacks that the kernel RNG numbers are subject to on the long winding path from device to RNGd to kernel API to kernel RNG to /dev/random to userland library to userland application.
It doesn't do that. What makes you think it does?