Ben Laurie <benl@google.com> writes:
On 2 July 2010 13:19, Eugen Leitl <eugen@leitl.org> wrote:
Tuesday, June 29, 2010
Nanoscale Random Number Circuit to Secure Future Chips
Intel unveils a circuit that can pump out truly random numbers at high speed.
Have they forgotten the enormous amount of suspicion last time they tried this?
You mean rampant paranoia from a small group of people... if you are genuinely worried about this, just use it as another input to mix into your entropy pool (which you should be doing anyway, never trust a single source of entropy). I'd be quite happy to use the RNG on a Loongson CPU (if there was one) in this manner, let alone an Intel CPU. What killed it wasn't paranoia about Intel but their almost total lack of interest in supporting it once the initial media attention waned. This doesn't look any different, note that it's not saying "This will be in Core2's starting August" but "We've done this in the lab". Peter.
On Tue, 13 Jul 2010 03:58:51 +1200 Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
Ben Laurie <benl@google.com> writes:
On 2 July 2010 13:19, Eugen Leitl <eugen@leitl.org> wrote:
Tuesday, June 29, 2010
Nanoscale Random Number Circuit to Secure Future Chips
Intel unveils a circuit that can pump out truly random numbers at high speed.
Have they forgotten the enormous amount of suspicion last time they tried this?
You mean rampant paranoia from a small group of people... if you are genuinely worried about this, just use it as another input to mix into your entropy pool (which you should be doing anyway, never trust a single source of entropy). I'd be quite happy to use the RNG on a Loongson CPU (if there was one) in this manner, let alone an Intel CPU.
What killed it wasn't paranoia about Intel but their almost total lack of interest in supporting it once the initial media attention waned. This doesn't look any different, note that it's not saying "This will be in Core2's starting August" but "We've done this in the lab".
It is disturbing to me that people oppose this so much. For a lot of applications -- servers run in isolation, networking equipment, etc. -- having hardware RNGs available is a really big win, because there is no good local source of randomness. (We had a long discussion of ways to mitigate this some time ago.) Plugging in an external unit is not going to happen in practice. If it isn't nearly free and built in, it won't be used. I would suggest that in most cases, you are better off with a very very mildly untrusted but ubiquitous hardware RNG than with the kinds of kludges to get random numbers on unattended hardware we end up with in the real world. BTW, let me note that if Intel wanted to gimmick their chips to make them untrustworthy, there is very little you could do about it. The literature makes it clear at this point that short of carefully tearing apart and analyzing the entire chip, you're not going to catch subtle behavioral changes designed to allow attackers backdoor access. Given that, I see little reason not to trust them on an RNG, and I wish they would make it a standard part of the architecture already. Perry -- Perry E. Metzger perry@piermont.com
On Mon, Jul 12, 2010 at 12:22:51PM -0400, Perry E. Metzger wrote:
Plugging in an external unit is not going to happen in practice. If it isn't nearly free and built in, it won't be used.
I completely agree. But HW RNGs are a pain in a lot of ways- modern chip design libraries don't include RNG modules. You have to make your own. Verification software won't verify it and considers it an error. When it runs it sucks a lot of power and generates a lot of heat. Not a problem for Intel, but if you're using a contract fab (TSMC) they probably won't guarantee that part of your chip will even work because according to chip design rules, it's wrong. Then there's FIPS- current 140 doesn't have a provision for HW RNG. They certify software RNG only, presumeably because proving a HW RNG to be random enough is very difficult. So what's probably the primary market (companies who want to meet FIPS) isn't available. So while I think it'd be great to have a decent RNG on chip (no more blocking on /dev/random!) I don't see it being much of a market advantage and would not be surprised if it never makes it in to a shipping product. Mixing the output with something else would address any lack of randomness either deliberate or accidental... but still wouldn't meet FIPS. BTW Intel isn't close to the first to put an RNG on a CPU chip. I worked for a company in the late 1990s that did it and I'm sure we wern't the first. Eric
Nanoscale Random Number Circuit to Secure Future Chips
Obviously there are costs associated with a HW RNG as someone enumerated. Since Intel can no doubt shut it off when not used, it is free. And die authors are always looking for more content to add. (And obviously to this list, without crypto tools the net is worse than useless, its deceptively reliable :-) So crypto hw will continue to be increasingly useful.) Since the crypto cluefull would never use a single raw RNG of any kind, and would even seek to use multiple diverse conditioning algorithms, cpu bandwidth allowing, a "hw" source can only help. (Unless they were implementing something useless like DRM) Except as someone wrote, if its the devil's hwrng, or can be clandestinely switched into that mode as useful.
On Tue, Jul 13, 2010 at 5:48 PM, <dahonig@cox.net> wrote:
... Obviously there are costs associated with a HW RNG as someone enumerated. Since Intel can no doubt shut it off when not used, it is free.
uh, what? you realize you're comparing a very noisy but very very small entity against the remaining core of a modern many hundred million gate processor right? you can certainly disable / idle the sources when not needed, but really, left wide open all the time they're a drop in the bucket.
... So crypto hw will continue to be increasingly useful.
it is the throughput and efficiency that makes it most useful. like the AES XCRYPT instruction in VIA Padlock cores. you may avoid a number of cache timing and other timing based side channel attacks on software cipher implementations using hw as well, since they often execute one or more rounds in a handful of cycles. there are probably other advantages.
Since the crypto cluefull would never use a single raw RNG of any kind,
the crypto cluefull know the value of mixing a high throughput, easily managed entropy source with host and application true random number facilities (/dev/random, /dev/urandom, OpenSSL random engine support, XSTORE instruction in userspace, etc.) the key to using a hw source properly: 1. initialize, measure, and mix the raw source(s) with a userspace entropy daemon. 2. continuously sanity check the read data over a large byte span and remove a hardware entropy source that is not functioning within comfortable tolerance. FIPS does have a nice suite of checks - again, this can't prove your source is robust, only that it doesn't suck horribly and obviously. :) 3. run the hw random data through a block cipher or hash digest to mask generator bias before adding to host entropy facilities with a conservative entropy density estimate. while the VIA and other good HW sources can produce very high density output i prefer at most an 80% estimation on input for robust distribution into the host pool as needed. 4. periodically save state for use with mixing initialization in step #1 on next restart. 5. monitor without writing if anomalies in the hw sources arise during operation. with VIA XSTORE on C5P or greater (not C5XL with single source) you have two independent sources which can be enabled or disabled as needed. on such systems you can fall back to half-rate throughput on the good source if the other goes bad. if you mean "raw" as in omitting all of the steps above and just reading /dev/hwrandom then i agree. otherwise, see above. :)
and would even seek to use multiple diverse conditioning algorithms, cpu bandwidth allowing, a "hw" source can only help.
i can get > 80Mbps of entropy on VIA hw entropy sources. have you ever tried to use /dev/random on a headless server? a recently booted workstation? for more than a few keys at a time? etc?
Except as someone wrote, if its the devil's hwrng, or can be clandestinely switched into that mode as useful.
keep secure state, properly mixed, and even a highly biased input would be whitened and obscured beyond utility. i'd like to see reasoning otherwise for XSTORE sources and XCRYPT AES mixing before conservatively mixed into properly seeded /dev/random kernel pool. if it is too biased (OpenSSL weak keys :) then the FIPS sanity checks will kick it out and you're denied entropy rather than compromised silently. it's really a shame crypto isn't standard on every DIE. although if they do a poor job of it the annoyance outweighs the utility. the SHA instruction on Padlock borders on unusable without hacks like interrupting the REP mode instruction with a fault/intr. so you can grab the un-finalized work-in-progress digest state for large lengths... best regards,
coderman <coderman@gmail.com> writes:
On Tue, Jul 13, 2010 at 5:48 PM, <dahonig@cox.net> wrote:
... Obviously there are costs associated with a HW RNG as someone enumerated.
uh, what? you realize you're comparing a very noisy but very very small entity against the remaining core of a modern many hundred million gate processor right?
A very small entity that (in its analog form) requires custom manufacturing steps, is affected by every minor change to the material, the process, die shrinks, you name it, and that most customers don't even know exists. So you need to rework, re-evaluate, and re-test it every time anything changes, and your customer won't pay extra for it. If you're Intel mgt I can't see this as being a very hard decision... Peter.
On Tue, Jul 13, 2010 at 10:04 PM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
... A very small entity that (in its analog form) requires custom manufacturing steps, is affected by every minor change to the material, the process, die shrinks, you name it, and that most customers don't even know exists. So you need to rework, re-evaluate, and re-test it every time anything changes, and your customer won't pay extra for it.
i agree completely on all of the sad realities related to the non-existence of pervasive hw crypto facilities. the power consumption argument is a strawman though. the VIA docs stated a power consumption difference when XSTORE is configured and polled frequently vs. explicitly disabled and unused. the details are fuzzy though, and i suspect it's the rest of the pipeline around actual use of HWRNG state and moving across cache/bus lines... i would be curious to know the power details on any of the hw entropy sources, if any are out there. best regards,
Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
A very small entity that (in its analog form) requires custom manufacturing steps
Depends on where they're getting their randomness from; avalanche breakdown in deep submicron CMOS isn't practical for this reason (and presumably this is the obvious way to do it), but I'd be curious if anyone's ever tried to make a thermal or 1/f noise source into an RNG; that'd take no additional process steps, though it would obviously be process dependent. -=rsw
participants (6)
-
coderman -
dahonig＠cox.net -
Eric Murray -
Perry E. Metzger -
Peter Gutmann -
Riad S. Wahby