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."
msg01741/pgp00000.pgp
Description: PGP signature
