Re: Intel to also add RNG

[Sandy Harris]

On 7/13/10, Perry E. Metzger  wrote:

> It is disturbing to me that people oppose this so much.

Yes. A hardware RNG seems an obvious Good Thing. Not
a complete solution, but a very useful component.

>  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.

IPsec gateways and web servers doing a lot of SSL are obvious
cases. Neither has much mouse or keyboard activity, they may
have solid state drives or smart RAID so disk timings are not
random. Packet timings might be somewhat random, but they
may also be knowable by an enemy.

>  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.

In some cases, a non-kludge alternative is Turbid:
http://www.av8n.com/turbid/paper/turbid.htm
That uses a sound card or on-board equivalent. Some boards
will have this, or it is cheap & easy to stick in a slot.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: Intel to also add RNG

[Ben Laurie]

On 12 July 2010 18:13, Jack Lloyd  wrote:
> On Mon, Jul 12, 2010 at 12:22:51PM -0400, Perry E. Metzger wrote:
>
>> 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.
>
> I think it's important to make the distinction between trusting Intel
> not to have made it actively malicious, and trusting them to have
> gotten it perfectly correct in such a way that it cannot fail.
> Fortunately, the second problem, that it is a well-intentioned but
> perhaps slightly flawed RNG [*], could be easily alleviated by feeding
> the output into a software CSPRNG (X9.31, a FIPS 186-3 design, take
> your pick I guess). And the first could be solved by also feeding your
> CSPRNG with anything that you would have fed it with in the absense of
> the hardware RNG - in that case, you're at least no worse off than you
> were before. (Unless your PRNG's security can be negatively affected
> by non-random or maliciously chosen inputs, in which case you've got
> larger problems).

Several years ago I reviewed a new design for FreeBSD's PRNG. It was
vulnerable to sources that had high data rates but low entropy (they
effectively "drowned out" lower data rate sources). This was fixed,
but I wonder how common an error it is?

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: Intel to also add RNG

[Thor Lancelot Simon]

On Tue, Jul 13, 2010 at 05:46:36PM +1200, Peter Gutmann wrote:
> Paul Wouters  writes:
> 
> >Which is what you should do anyway, in case of a hardware failure.  I
> >know the Linux intel-rng and amd-rng used to produce nice series of zeros.
> 
> Do you have any more details on this?  Was it a hardware problem, software
> problem, ...?  How was it caught?

I couldn't say, as regards AMD's chipset RNG.  Intel's, however, was on
an optional component of one of their motherboard chipsets.  Many
motherboard vendors chose to buy that component from other sources, who
implemented something register-compatible to the Intel part but with
the RNG register not actually connected to a random number source.

Worse, when Intel increased chipset integration and pulled the optional
chip "into" one of the host bridge chips, they did the exact same thing.

The basic problem was that the register indicating presence-of-RNG was
not on the same piece of silicon (originally) as the actual RNG.  So the
register really indicated only that this Intel chipset *was capable of
interfacing to the chip with the RNG on it*; nothing more.

Worse, a lot of people read noise -- but not really random noise --
from those notional RNG registers and persuaded themselves that since
the output wasn't continuous, there must really be an RNG present.
Oops.

Thor

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: Intel to also add RNG

[Francois Grieu]

 On 12/07/2010 22:13, Eric Murray wrote:/
> On Mon, Jul 12, 2010 at 03:37:45PM -0400, Paul Wouters wrote:
>> On Mon, 12 Jul 2010, Eric Murray wrote:
>>
>>> 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 you can do HWRNG -> SWRNG -> Fips ?
> Last FIPS cert I did (140-2, a couple years ago), it was SWRNG only. 
> X9.62 or FIPS 186 or X9.31 or SP 800-90.
>
> I couldn't even use a HW RNG for the seed.  /dev/random was acceptable.
>

The Smart Card industry uses True RNG a lot. There, a common line of
thought is to use:
- a hardware RNG, which raw output (perhaps biased) is directly
accessible for testing purposes (only), so that the software can check
it in depth at startup and from time to time to ascertain that it is at
least generating a fair amount of entropy
- followed by appropriate post-processing in hardware (so as to gather
entropy at all time), acting as a mixer/debiaser:; e.g. something LFSR-based
- followed by a crude software test (e.g. no bit stuck)
- optionally followed by software postprocessing (the subject is
debated; this software has to be proven to not include weakness, and the
hardware + crude software test is certified to eliminate such weakness,
so why bother, some say)

There is a standard, known as AIS31, on evaluating True RNG, which
de-facto enforces the first three steps

which references


For German-reading audience, the page linking to that is

Google does good work when fed with AIS31.

  François Grieu

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: Intel to also add RNG

[Peter Gutmann]

Paul Wouters  writes:

>Which is what you should do anyway, in case of a hardware failure. I know the 
>Linux intel-rng and amd-rng used to produce nice series of zeros.

Do you have any more details on this?  Was it a hardware problem, software
problem, ...?  How was it caught?

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: Intel to also add RNG

[Eric Murray]

On Mon, Jul 12, 2010 at 03:37:45PM -0400, Paul Wouters wrote:
> On Mon, 12 Jul 2010, Eric Murray wrote:
>
>> 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 you can do HWRNG -> SWRNG -> Fips ?

Last FIPS cert I did (140-2, a couple years ago), it was SWRNG only. 
X9.62 or FIPS 186 or X9.31 or SP 800-90.

I couldn't even use a HW RNG for the seed.  /dev/random was acceptable.

> Also,
> the VIA PadLock already ships with an HWRNG on die. It's been shipping
> for years.

True that.

Eric


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: Intel to also add RNG

[Paul Wouters]

On Mon, 12 Jul 2010, Eric Murray wrote:


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 you can do HWRNG -> SWRNG -> Fips ?

Which is what you should do anyway, in case of a hardware failure. I
know the Linux intel-rng and amd-rng used to produce nice series of
zeros. The padlock rng has never produced warnings piping it through
rngd.


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.


With every phone doing crypto these days, I'd think you are wrong. Also,
the VIA PadLock already ships with an HWRNG on die. It's been shipping
for years.

Paul

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: Intel to also add RNG

[Paul Wouters]

On Mon, 12 Jul 2010, Ben Laurie wrote:


On 2 July 2010 13:19, Eugen Leitl  wrote:


http://www.technologyreview.com/printer_friendly_article.aspx?id=25670&channel=Briefings§ion=Microprocessors

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?


I love how they pretend to be the first ones with this, totally ignoring others
who have had this for years, such as the VIA PadLock.

The article lists NIST having done tests, but does not mention any CPU model 
where
this is on. Anyone knows?

Paul

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: Intel to also add RNG

[Nicolas Williams]

On Mon, Jul 12, 2010 at 01:13:10PM -0400, Jack Lloyd wrote:
> I think it's important to make the distinction between trusting Intel
> not to have made it actively malicious, and trusting them to have
> gotten it perfectly correct in such a way that it cannot fail.
> Fortunately, the second problem, that it is a well-intentioned but
> perhaps slightly flawed RNG [*], could be easily alleviated by feeding
> the output into a software CSPRNG (X9.31, a FIPS 186-3 design, take
> your pick I guess). And the first could be solved by also feeding your
> CSPRNG with anything that you would have fed it with in the absense of
> the hardware RNG - in that case, you're at least no worse off than you
> were before. (Unless your PRNG's security can be negatively affected
> by non-random or maliciously chosen inputs, in which case you've got
> larger problems).

You need an entropy pool anyways.  Adding entropy (from the CPU's RNG,
from hopefully-random event timings, ...) and non-entropy (from a flawed
HW RNG, from sadly-not-random event timings, ...) to the pool results in
having enough entropy (once enough entropy has been added to begin
with).  You'll want multiple entropy sources no matter what, to deal
with HW RNG failures for example.

BTW, SPARC CPUs have shipped with on-board HW RNGs; Intel is hardly
first.

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: Intel to also add RNG

[Eric Murray]

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

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: Intel to also add RNG

[Jack Lloyd]

On Mon, Jul 12, 2010 at 12:22:51PM -0400, Perry E. Metzger wrote:

> 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.

I think it's important to make the distinction between trusting Intel
not to have made it actively malicious, and trusting them to have
gotten it perfectly correct in such a way that it cannot fail.
Fortunately, the second problem, that it is a well-intentioned but
perhaps slightly flawed RNG [*], could be easily alleviated by feeding
the output into a software CSPRNG (X9.31, a FIPS 186-3 design, take
your pick I guess). And the first could be solved by also feeding your
CSPRNG with anything that you would have fed it with in the absense of
the hardware RNG - in that case, you're at least no worse off than you
were before. (Unless your PRNG's security can be negatively affected
by non-random or maliciously chosen inputs, in which case you've got
larger problems).

-Jack

[*] Even if it were perfectly designed, it seems plausible to me that
manufacturing defects and/or any number of runtime problems (age,
overheating, bad voltage control, cosmic rays, dirty power, etc, etc)
might cause subtle failures/biases that might be difficult to detect
reliably; I would personally be dubious of using any hardware RNGs
output directly for this reason.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: Intel to also add RNG

[Matt Crawford]

On Jul 12, 2010, at 11:22 AM, Perry E. Metzger wrote:

> 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.

I happen to be re-reading Vernor Vinge's _A Deepness in the Sky_ right now. In 
it, a conquering power needs to use the computing and communication technology 
of its subjugated foe, and has unusual resources to carry out a thorough code 
audit. However, the foe has been hiding secrets since before the victors were 
fooling with electricity ...



smime.p7s
Description: S/MIME cryptographic signature

Re: Intel to also add RNG

[Perry E. Metzger]

On Tue, 13 Jul 2010 03:58:51 +1200 Peter Gutmann
 wrote:
> Ben Laurie  writes:
> >On 2 July 2010 13:19, Eugen Leitl  wrote:
> >>
> >>http://www.technologyreview.com/printer_friendly_article.aspx?id=25670&channel=Briefings§ion=Microprocessors
> >>
> >>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. Metzgerpe...@piermont.com

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: Intel to also add RNG

[Peter Gutmann]

Ben Laurie  writes:
>On 2 July 2010 13:19, Eugen Leitl  wrote:
>>
>>http://www.technologyreview.com/printer_friendly_article.aspx?id=25670&channel=Briefings§ion=Microprocessors
>>
>>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.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: Intel to also add RNG

[Richard Salz]

> Have they forgotten the enormous amount of suspicion last time they 
> tried this?

More likely they're expecting everyone else to have forgotten about being 
suspicious.

/r$

--
STSM, WebSphere Appliance Architect
https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: Intel to also add RNG

[Ben Laurie]

On 2 July 2010 13:19, Eugen Leitl  wrote:
>
> http://www.technologyreview.com/printer_friendly_article.aspx?id=25670&channel=Briefings§ion=Microprocessors
>
> 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?

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Intel to also add RNG

[Eugen Leitl]

http://www.technologyreview.com/printer_friendly_article.aspx?id=25670&channel=Briefings§ion=Microprocessors
 

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.

By Tom Simonite

It might sound like the last thing you need in a precise piece of hardware,
but engineers at Intel are pretty pleased to have found a way to build a
circuit capable of random behavior into computer processors.

Generating randomness--an unpredictable stream of numbers--is much harder
than you might think. It's also crucial to creating the secure cryptographic
keys needed to keep data safe. Building a random-number-generating ability
into the Central Processing Unit (CPU) at a computer's heart is ideal, says
Ram Krishnamurthy, an engineer at Intel's Microprocessor Technology Labs, in
Hillsboro, OR. It should speed up any process that requires the generation of
an encrypted key, for example securing sensitive data on a hard drive, and
make it harder for an attacker to compromise that encryption.

Building circuitry capable of producing random numbers into a CPU has proved
difficult. "Today random numbers are either generated in software, or in the
chip set outside the microprocessor," explains Krishnamurthy, one of the
Intel researchers on the project.

Neither solution is ideal. Software produces only pseudo random numbers
(given enough computing power, patterns can be found within that randomness).

"If the random numbers are not truly random, for example, if they are biased
in some way, then an adversary has a better chance of guessing/determining
the value," explains mathematician Elaine Barker, at the National Institute
for Standards and Technology (NIST), in Gaithersburg, MD. "In the case of
cryptographic keys, if the adversary can determine the key without an
excessive amount of computing power, then he can breach the confidentiality
of that data."

Installing a source of random numbers outside of a computer's core
microprocessor provides another avenue of opportunity to attackers, says
Krishnamurthy. "You are vulnerable to side channel attacks," he explains,
"there are many ways by which the key can be directly read off of the bus, or
attacks that look at how the power supply varies and look for signatures that
indicate what the key looks like."

Building the circuit into the main processor shuts off that possibility, says
Krishnamurthy, although the barrier to doing that has been practicality. The
best-established methods of generating random numbers use analog circuits
that rely on thermal noise as a source of randomness, and those circuits are
not easily fabricated with the techniques used to make the digital circuits
of a microprocessor. Nor are they easily scaled down to the size of
components on modern chips.

Intel's new circuit has a fully-digital design, making it possible to
incorporate it into the microprocessor die. At the heart of the new design is
a cross-coupled inverter, a combination of two basic circuit components that
is essentially a memory capable of storing a single 1 or 0. This memory,
though, is designed to be unreliable; it can be tipped between its two
possible outputs by the influence of thermal noise from the surrounding
silicon. Since that thermal noise is random, the circuit's output should be,
too.

In reality, though, the influence of fluctuations in voltage and temperature
normal inside a chip could bias that output to be less-than-random, requiring
Krishnamurthy and colleagues to develop additional measures to counteract
their influence. Benchmarks for "true" randomness maintained by NIST were
used to confirm they had been successful. "We exceeded all of those
thresholds," he says. The speed at which the new circuit cranks out
numbers--2.4 billion a second or 2.4Gbps--is also around 200 times faster
than anything before, Krishnamurthy adds.

Having built the circuit with a smallest feature size of 45 nanometers, he
and colleagues are now working toward proving it can be built using 32 and 22
nanometer manufacturing processes with minimal design tweaks.

Passing existing benchmarks of randomness, though, does not mean the new
circuit is perfect. Current techniques do not make it possible to be certain
that any source of randomness is truly random, says Barker. "We just don't
know enough to design tests that catch all the problems, and tests may not
always catch the point at which a noise source starts to go bad if the change
is subtle." Research by groups like that at NIST will generate smarter tests
that help industry engineers raise the bar further.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com