[4022] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: Intel announcements at RSA '99

daemon@ATHENA.MIT.EDU (David Honig)
Wed Jan 20 19:14:13 1999

Date: Wed, 20 Jan 1999 14:42:19 -0800
To: Ben Laurie <ben@algroup.co.uk>, Steve Bellovin <smb@research.att.com>
From: David Honig <honig@sprynet.com>
Cc: cryptography@c2.net
In-Reply-To: <36A64303.59B60F0B@algroup.co.uk>

At 08:56 PM 1/20/99 +0000, Ben Laurie wrote:
>Steve Bellovin wrote:
>> 
>> Intel has announced a number of interesting things at the RSA conference.
>> The most important, to me, is the inclusion of a hardware random number
>> generator (based on thermal noise) in the Pentium III instruction set.
>> They also announced hardware support for IPSEC.
>
>An interesting question (for me, at least) is: how will I know that the
>hardware RNG is really producing stuff based on thermal noise, and not,
>say, on the serial number, some secret known to Intel, and a PRNG?
>

You would have to reverse engineer random samples of the chip to gain
*some* confidence.  Intel could make this easier by providing
their "source" and tool flow, from specs to a HDL to synthesis to layout.

There are, I am told, commercial firms who will give you a netlist given
*only* a sample chip and lots of money.

And there's of course Ross Anderson and Marcus Kuhn and their
chip-stripping labs..

If you can account for all the hardware in someone's chip in terms of a
specified
function, with no parts left over, you have some confidence that they're not
occasionally leaking something they shouldn't, or faking a true RNG.

Isn't that how you inspect crypto source code?  You look at the source,
explain
all the lines in terms of specified functions, look for covert channels, and
trust your compiler?





I suspect there'll be a niche for a Crypto-Underwriter's Labs which performs
'independent' (like that will ever be agreed upon!) analyses on hardware.

And even with these assurances, you still have to buy your equiptment
anonymously
and physically secure it at all times.

But it can be done, and is easier than verifying every possible interaction
in an OS.








  






home help back first fref pref prev next nref lref last post