Welome to the Internet, here's your private key

[Wouter Slegers]

On Tue, Feb 05, 2002 at 06:18:35PM -0500, Ryan McBride wrote:
> Having the manufacturer provide the random data changes the burden of
> proof drastically - there is no way for to _prove_ that they did not
> retain a copy of the random data, while it can be proved that they did
> not try to cheat simply by testing all the cards.
If all of the random data is provided by the manufacturer, this is a
good point. However you can use such random data to strengthen the
security if the card contains no, or an untrustworthy, random generator
by using the manufaturers randomness as a seed or encryption key for the
generator part (in Yarrow style random generators). 
If done correctly, this makes the output at least as random (or more
specificly: unpredictable) as the minimum of the sources. With
non-random seeding data (e.g. manufacturing fault or foul play) the
security of such a scheme against attacks by the manufacturer is as low
as it was before, but against others still high.
Of course, if you can keep some random pool on the chip, you can keep
mixing in randomness from sessions, which will make an attack on the
random generator much less interesting. A backdoor is then more
interesting for a rogue manufacturer.

> Additionally, if the manufacturer is providing the secrets on the card
> it appers that one weakens the non-repudiation property of signatures
> derived from this secret. 
> 
> All in all, it seems like manufacturer provided secrets are not a Good
> Thing(tm).
Only if they are the _only_ randoms provided. For seeding the random
generater I think they are a Good Thing(tm)

> The whole idea with smartcards is that _nobody_ knows the secrets,
> right? 
For non-repudiation, nobody must be able to duplicate the secrets, with
or without seeing it. A secure cloning operation (such as many of the
HSM SSL-cards provide) is also not allowed.

With kind regards,
Wouter Slegers

-- 
Wouter Slegers
Your Creative Solutions
"Security solutions you can trust and verify."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20020206/05967ffa/attachment.pgp>