[10405] in cryptography@c2.net mail archive
Re: Welome to the Internet, here's your private key
daemon@ATHENA.MIT.EDU (Wouter Slegers)
Wed Feb 6 11:53:55 2002
Date: Wed, 6 Feb 2002 08:10:49 +0100
From: Wouter Slegers <wouter@yourcreativesolutions.nl>
To: cryptography@wasabisystems.com
Message-ID: <20020206081049.B27462@tornado-openbsd.internal.yourcreativesolutions.nl>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
protocol="application/pgp-signature"; boundary="ZfOjI3PrQbgiZnxM"
Content-Disposition: inline
In-Reply-To: <20020205231835.GD31861@countersiege.com>; from mcbride@countersiege.com on Tue, Feb 05, 2002 at 06:18:35PM -0500
--ZfOjI3PrQbgiZnxM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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).=20
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.=20
>=20
> 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?=20
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
--=20
Wouter Slegers
Your Creative Solutions
"Security solutions you can trust and verify."
--ZfOjI3PrQbgiZnxM
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Comment: This is a digital signature. Use PGP or GPG to verify it.
iEYEARECAAYFAjxg1vkACgkQUWQi91IXwq9tVwCaA6emwC+mpN3R822Pp2dhxnr3
FLsAn11xLOO1N7WgrvBV2Y4SrRpdYHAG
=fbfb
-----END PGP SIGNATURE-----
--ZfOjI3PrQbgiZnxM--
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
