Use of TPM chip for RNG?

A few weeks ago I asked for information on using the
increasingly
prevalent built-in TPM chips in computers (especially
laptops) as a
random number source.  I got some good advice and want to
summarize the
information for the benefit of others.

The TPM chip as spec'd by the Trusted Computing Group
(www.trustedcomputinggroup.org) is a complex and
controversial device.
Despite (or perhaps because of) all the fuss over it when
the technology
was introduced, nothing much has happened with it and they
are mostly
used to add a bit of security to encrypted files and such. 
TPMs do have
hardware RNGs and I wanted to find out how to access this
capability.

On Windows, there are several APIs available which can work.
The "native" API for the TPM is the Trusted
Software Stack (TSS).
https://www.trustedcomputinggroup.org/groups/software/
This provides a
wide range of TPM-specific functions, including ones to
access the RNG.
Another alternative is Microsoft's Crypto API (MS-CAPI). 
CAPI uses a
plug-in architecture where Crypto Service Providers (CSPs)
provide the
required functionality.  TPM-based CSPs allow access to TPM
functions
via CAPI.  Third, the PKCS-11 (Cryptoki) API is designed for
access
to smart cards, but TPM manufacturers often deliver PKCS-11
compatible
libraries for access to the chips.  Both CAPI and PKCS-11
have random
number functionality which can be used to access the TPM
RNG.

The main problem in practice with using this functionality
on Windows is
that there is as yet no standard for naming or locating the
DLL's which
supply the necessary functions.  I am testing on an IBM
Thinkpad with
an Atmel TPM, and it comes with DLL's that provide TSS,
CAPI and PKCS-11
interfaces.  But all are supplied with non-standard names
and located in
non-standard places.  Software to use these functions has to
know where
the DLLs are and what they are called in order to load them
explicitly.

The exception is MS-CAPI.  CAPI provides an interface to
enumerate all
the CSPs, so if you can figure out which one is the TPM CSP
you can then
use that one to generate random numbers.  One of the CAPI
functions lets
you query to see if the CSP has hardware RNG support.  On my
system,
this returns TRUE for the TPM CSP.  However, a colleague has
a Dell
system with a different TPM and different software, and that
TPM's CSP
does not set this bit.  So I don't have a foolproof method
of figuring
out which CSP to use in order to access the TPM.  It might
be possible
to hard-code the names of all known TPM CSPs but that would
not be very
flexible going forward.

At this point MS-CAPI still looks like the best choice for
machine-independent access to the TPM RNG on Windows.  The
ability to
reliably enumerate all the CSPs is much easier than hunting
through the
disk to try to find a DLL to implement the TSS or PKCS-11
APIs.  OTOH if
you are building the software for a particular system and
can build in
the location of the necessary DLL, one of the other APIs
could work too.

On Linux systems, as I mentioned earlier, the standard
appears
to be an open-source TSS implementation called Trousers, at
http://trousers.sourc
eforge.net .  This requires the Linux kernel to
have a TPM device driver built-in or as a loadable module. 
This has
been available in the kernel since 2.6.12, but many
distributions do
not enable it, even as a module, so some work is needed to
make a kernel
with TPM support.  Then the Trousers software builds a
daemon process,
tcsd, which opens /dev/tpm exclusively, and a library,
libtspi, for
remote access to tcsd and the TPM.

If you want a cross-platform solution, TSS is probably the
best approach
going forward.  As noted, at present the software support is
a little
immature and some local configuration will be necessary -
locating the
TSS DLL on Windows, and installing the TPM kernel support
and Trousers
software on Linux.  Once this is done, the TSS API should
provide for
cross-platform capability.  And of course it has additional
functionality
if you want to use the TPM for more than just random number
generation.

Intel Macs have TPM chips as well but I don't know of any
software yet
that can access them.  Eventually I would expect a TSS
solution to be
available on that platform as well.

Thanks again to the people who provided me information about
these
various solutions!

Hal Finney

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

On Thu, 29 Jun 2006, "Hal Finney" wrote:

> A few weeks ago I asked for information on using the
increasingly
> prevalent built-in TPM chips in computers (especially
laptops) as a
> random number source.  I got some good advice and want
to summarize the
> information for the benefit of others.

Thanks for the useful summary!  For the sake of
completeness, let me also add 
that RNGs in tamper-proof hardware are potentially rather
controversial, since 
there are several known ways to produce output which looks
very random to 
anyone who doesn't know some secret, but allows those who
do to predict what 
future outputs will be.  I believe one straightforward way
to do this would be 
to simply use a symmetric encryption function outputting
"random" data blocks

r_i=Encrypt(key, r_(i-1))

If you don't know the secret key, the output will look at
least somewhat 
random, but if you do, you can use any block to predict all
subsequent and 
prior ones.  (This topic has been discussed in the
literature, and my 
off-the-cuff example may not be particularly strong.)

I believe it's a fair summary to say that hardware RNG is a
neat and useful 
feature, but may be unsuitable for the sufficiently paranoid
when it comes in 
a tamper-proof package.

 						-J

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

| > A few weeks ago I asked for information on using the
increasingly
| > prevalent built-in TPM chips in computers (especially
laptops) as a
| > random number source.  I got some good advice and
want to summarize the
| > information for the benefit of others.
| 
| Thanks for the useful summary!  For the sake of
completeness, let me also add
| that RNGs in tamper-proof hardware are potentially rather
controversial, since
| there are several known ways to produce output which looks
very random to
| anyone who doesn't know some secret, but allows those who
do to predict what
| future outputs will be.  I believe one straightforward way
to do this would be
| to simply use a symmetric encryption function outputting
"random" data blocks
| 
| r_i=Encrypt(key, r_(i-1))
| 
| If you don't know the secret key, the output will look at
least somewhat
| random, but if you do, you can use any block to predict
all subsequent and
| prior ones.  (This topic has been discussed in the
literature, and my
| off-the-cuff example may not be particularly strong.)
Your example would, in fact, be as strong as any.  It's
generally
considered a significant - often disqualifying - fault of a
modern
cryptosystem if its output can be distinguished from that of
a random
function.  Feeding the input back is a common method for
testing for
such non-randomness, since the expected cycle length for
random
functions can be calculated and many older cryptographic
functions
showed weaknesses here.

| I believe it's a fair summary to say that hardware RNG is
a neat and useful
| feature, but may be unsuitable for the sufficiently
paranoid when it comes in
| a tamper-proof package.
You're damned if you do and damned if you don't.  Would
you want to use a
hardware RNG that was *not* inside a tamper-proof package -
i.e., inside
of a package that allows someone to tamper with it?

A "spiked" RNG of the kind you describe is at
least somewhat fixable:
Choose a fixed secret key and encrypt the output of the
generator with
the key before using it.  Assuming the cryptographic
function you use is
good - and in the end you're almost certain to make that
assumption
somewhere - the resulting bits can be treated as random. 
(Note that you
don't ever have to share that key with anyone, nor do you
have to fix it
for good.)  (And, yes, on a theoretical level, there is only
one block's
worth of entropy in such a generator, so it's not so good. 
Assuming the
same crypto algorithm throughout, one way or another, the
best you can
get is the difficulty of a brute-force attack on the smaller
of a key or
a block.  For repeated uses, an attack on the generator, of
course,
may give you access to much more than one key.)

As has been discussed here previously, there are other ways
to "spike"
hardware, including an RNG, that are much more insidious. 
An RNG that
only covers a small fraction of the possible outputs is one
possibility.
For example, r_i = Encrypt(key,i mod 2^32) will look quite
random unless
you get more than 2^32 samples, but there's a trivial
brute-force attack
against the output - which works just as well against the
"encrypt before
using" fix.
							-- Jerry


------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

halfinney.org ("Hal Finney") writes:

>A few weeks ago I asked for information on using the
increasingly prevalent
>built-in TPM chips in computers (especially laptops) as
a random number
>source.

You have to be pretty careful here.  Most of the TPM chips
are just rebadged
smart cards, and the RNGs on those are often rather dubious.
 A standard
technique is to repeatedly encrypt some stored seed with an
onboard block
cipher (e.g. DES) as your "RNG".  Beyond the
obvious attacks (DES as a PRNG
isn't particularly strong) there are the usual paranoia
concerns (how do we
know the manufacturer doesn't keep a log of the seed and
key?) and stupidity
concerns (all devices use the same hardwired key, which some
manufacturers
have done in the past).  There are also active attacks
possible, e.g. request
values from the device until the EEPROM locks up, after
which you get constant
"random" values.  Finally, some devices have
badly-designed challenge-response
protocols that give you an infinite amount of RNG output to
analyse, as well
as helping cycle the RNG to lockup.

So the only hardware RNG I'd trust is one of the
noise-based ones on full-
scale crypto processors like the Broadcom or HiFn devices,
or the Via x86's.
There are some smart-card vendors who've tried to replicate
this type of
generator in a card form-factor device, but from what little
technical info is
available about generators on smart cards it seems to be
mostly smoke and
mirrors.

(As an extension of this, the lack of access to a TPM's RNG
isn't really any
great loss.  If it's there, you can mix it
opportunistically into your own
RNG, but I wouldn't rely on it).

Peter.

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

On 7/2/06, Peter Gutmann <pgut001cs.auckland.ac.nz>
wrote:
> You have to be pretty careful here.  Most of the TPM
chips are just rebadged
> smart cards, and the RNGs on those are often rather
dubious.

My last email of the day, I promise 

And if you're interested in some of the smart card
developments, you
might want to check out these proceedings:

http://www.usenix.org/publicati
ons/library/proceedings/smartcard99/technical.html
http://www.usenix.org/publications/libr
ary/proceedings/cardis02/tech.html
-- 
Resolve is what distinguishes a person who has failed from a
failure.
Unix "guru" for sale or rent - http://www.li
ghtconsulting.com/~travis/ -><-
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098
0C55 1484

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

On 7/3/06, Leichter, Jerry <leichter_jerroldemc.com> wrote:
> You're damned if you do and damned if you don't. 
Would you want to use a
> hardware RNG that was *not* inside a tamper-proof
package - i.e., inside
> of a package that allows someone to tamper with it?

Yes.  If someone has physical access to your equipment, they
could
compromise it.  On the other hand, if you have access to it,
you can
establish a baseline and check it for changes.  I recall the
book
titled "Computer Security" by Carroll suggested
taking polaroids of
all your equipment, and from each window, and other even
more paranoid
things.  As a non-sequitur, in the first edition, he had the
following
wonderful quote on the dust jacket:

``Computer crime has become the "glamor crime"
of the 1970s...''

Perhaps he was a bit ahead of his time.

> A "spiked" RNG of the kind you describe is
at least somewhat fixable:
> Choose a fixed secret key and encrypt the output of the
generator with
> the key before using it....
> ... nor do you have to fix it for good.)

Were you to periodically take the output of the generator
and use it
as a new key, you would have something remarkably similar to
the
fortuna and yarrow PRNGs.  If you don't do something like
that, you
have cycle lengths equal to your input's cycle length,
which for the
designs we've been discussing, is fixed, so pretty easy to
distinguish
from random (assuming you have access to enough output).
-- 
Resolve is what distinguishes a person who has failed from a
failure.
Unix "guru" for sale or rent - http://www.li
ghtconsulting.com/~travis/ -><-
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098
0C55 1484

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

Peter Gutmann wrote:
> You have to be pretty careful here.  Most of the TPM
chips are just rebadged
> smart cards, and the RNGs on those are often rather
dubious.  A standard
> technique is to repeatedly encrypt some stored seed
with an onboard block
> cipher (e.g. DES) as your "RNG".  Beyond
the obvious attacks (DES as a PRNG
> isn't particularly strong) there are the usual
paranoia concerns (how do we
> know the manufacturer doesn't keep a log of the seed
and key?) and stupidity
> concerns (all devices use the same hardwired key, which
some manufacturers
> have done in the past).  There are also active attacks
possible, e.g. request
> values from the device until the EEPROM locks up, after
which you get constant
> "random" values.  Finally, some devices
have badly-designed challenge-response
> protocols that give you an infinite amount of RNG
output to analyse, as well
> as helping cycle the RNG to lockup.

One of the issues for a long time for that class of chips is
whether 
on-chip key-gen and/or supported DSA (and/or ECDSA) were in
use ... 
processes where reasonable good RNG are integral to the
operation.

at one point there was tests for a collection of chips in
that class 
that perform 65k power-cycle/RNG operations and found that
something 
like 30 percent of the numbers were repeated.

however, at least some of the TPM chips have RNGs that have
some level 
of certification (although you might have to do some
investigation to 
find out what specific chip is being used for TPM).

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

Peter Gutmann wrote:
> halfinney.org ("Hal Finney") writes:
> 
>> A few weeks ago I asked for information on using
the increasingly prevalent
>> built-in TPM chips in computers (especially
laptops) as a random number
>> source.
> 
> You have to be pretty careful here.  Most of the TPM
chips are just rebadged
> smart cards, and the RNGs on those are often rather
dubious.  A standard
> technique is to repeatedly encrypt some stored seed
with an onboard block
> cipher (e.g. DES) as your "RNG".  Beyond
the obvious attacks (DES as a PRNG
> isn't particularly strong) there are the usual
paranoia concerns (how do we
> know the manufacturer doesn't keep a log of the seed
and key?) and stupidity
> concerns (all devices use the same hardwired key, which
some manufacturers
> have done in the past).  There are also active attacks
possible, e.g. request
> values from the device until the EEPROM locks up, after
which you get constant
> "random" values.  Finally, some devices
have badly-designed challenge-response
> protocols that give you an infinite amount of RNG
output to analyse, as well
> as helping cycle the RNG to lockup.

Glad to see some new information in a thread that is
otherwise giving me
a huge sense of deja vu. So ... where are these rebadged
smartcards
deployed? Who rebadges them?

> 
> So the only hardware RNG I'd trust is one of the
noise-based ones on full-
> scale crypto processors like the Broadcom or HiFn
devices, or the Via x86's.
> There are some smart-card vendors who've tried to
replicate this type of
> generator in a card form-factor device, but from what
little technical info is
> available about generators on smart cards it seems to
be mostly smoke and
> mirrors.
> 
> (As an extension of this, the lack of access to a
TPM's RNG isn't really any
> great loss.  If it's there, you can mix it
opportunistically into your own
> RNG, but I wouldn't rely on it).

+1.

Cheers,

Ben.

-- 
http://www.apache-
ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he
can go if he
doesn't mind who gets the credit." - Robert Woodruff

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

Travis H. wrote:
> http://www.usenix.org/publicati
ons/library/proceedings/smartcard99/technical.html 
> 
> http://www.usenix.org/publications/libr
ary/proceedings/cardis02/tech.html

and even this ... having to resort to the wayback machine
http://we
b.archive.org/web/20030417083810/http://www.smartcard.co.uk/
resources/articles/cartes2002.html

includes mention of "yes card" attack (end of
last paragraph). however, 
the "yes card" attack is really an attack on the
terminals (and the 
infrastructure implementation) ... not on cards. a few posts
discussing 
"yes card"

http://www.
garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-AND-Pin 
Security Flaw
http://www
.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

Ben Laurie <benalgroup.co.uk> writes:

>So ... where are these rebadged smartcards deployed? Who
rebadges them?

System integrators usually.  The way it works is that the
company that fabs
the devices (typically Atmel, STMicroelectronics, or
Infineon) create the
silicon.  Then a second-level vendor (say, Gemplus) load
their firmware into
the basic device and bond out the serial lines (ISO 7816) or
USB lines (USB
key) and then it's a GemSAFE card or a USB token (OK,
Gemplus don't do USB
tokens, but you know what I mean).  Some companies (e.g.
Infineon) do both
steps themselves.

For the TPM, you bond out the LPC lines instead of the USB
or serial ones, and
load TPM firmware instead of smart-card firmware.

I'm simplifying that somewhat in that there isn't one
single device into which
you load one set of firmware and it's a TPM and another set
of firmware and
it's a smart card.  Smart cards and TPMs are part of the
same family of
devices, where you might have 20 variants on the same basic
device with 18 of
the variants targeted for smart-card use and 2 targeted for
TPM use.  Look at
Atmel's SecureAVRs for an example, there's a whole
shopping-list of variations
on that (ROM/RAM/EEPROM/with or without bignum
accelerator/etc), and some of
the shopping-list entries are targeted at TPM.  But under
the hood the
97SCwhatever TPM is a 90SC-family SecureAVR with different
firmware.  Same
with STM's ST19something smart card vs. ST19something-else
TPM, and Infineon's
SLE66CX smart card vs. SLE66CX TPM - they're just smart
cards with clever
marketing.

Peter.

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com