Management of signature keys for government

[David Hopwood]

-----BEGIN PGP SIGNED MESSAGE-----

In message <E0y9DFz-0002Ry-00@canada.cl.cam.ac.uk>
  Richard Watts <Richard.Watts@cl.cam.ac.uk> wrote:

> On Sun 1 March 1998, Markus Kuhn
> <Markus.Kuhn@cl.cam.ac.uk> wrote:

> >Brian Gladman wrote on 1998-03-01 13:35 UTC:
> >> Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> wrote:
> >> >I hope this makes clear that in-card key generation does not
> >> >make it unnecessary to include the personalization facilities into
> >> >the trusted computing base.
> [snip]
> >You have to realize that these tamper-resistance feature work *against*
> >you in an in-module signature key generation scheme: If the device that
> >generates your key is ultra-tamper-resistant, then you have no way of
> >ensuring that the algorithms applied are sound, most notably that the
> >key generator has not been tampered with. 

>  True, but this holds for everything, not just key generation: 
> if you're going to trust your card not to leak key material, why not 
> trust it to generate your key for you ? (wrt. malice, anyway: 
> carelessness is another matter).

One approach is to design the protocols so that both the smartcard, and
the software on the PC/NC/whatever would need to be compromised.

For example, suppose the requirement is for a secure login protocol,
where the user must possess three factors to log in: their passphrase,
a smartcard, and a private key stored on a PC. One way of implementing
this is to do a three-way key exchange between the smartcard, PC, and
host, treating them as mutually untrusting parties (i.e. with three
independent key pairs). The passphrase can be used to protect either
the PC's private key, or (if it has a keypad) the smartcard's private
key.

The three-way Diffie-Hellman protocol described in Applied Cryptography
section 22.1 can be used as a starting point for this. (That protocol
won't do as it stands, since it doesn't protect against man-in-the-
middle attacks, and the PC is a man-in-the-middle between the smartcard
and the host. However, it can fairly easily be modified to fix that.)

Of course, this doesn't prevent the PC's software from being modified
to leak the plaintext, but it does make sure that even in that case,
the smartcard must be present. If the smartcard is untrustworthy, it
can only leak its own key, not the one stored on the PC.

- -- 
David Hopwood <hopwood@zetnet.co.uk>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
Key fingerprint = 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Key type/length = RSA 2048-bit (always check this as well as the fingerprint)

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBNPyOyTkCAxeYt5gVAQGnWAf/dE2OZbR7od2LvSHG7VLt+dOPF8fO4tn/
i/t2hPTBqApwpyOIPMGkeXcXPptGuMkeOw6TFA02QNmvrGvpy7QAKGWCPAlPTjHK
r0cmwjC+/aCYVToj9iHtTFpT/WtR8fDC/sP9Yrq3pPwFxY8Mnx0KW3CQ10i10vNy
/E29K6U5J78ksfk5XivhiQZX1U+KAeOBMYeynm6inN5nVLZM9pageWUwKtEktTpK
gUjFOIUa+TTuyAMozsIsiGeFctefBqHxHf4evT8LhVbPpNgdcCtXsO0LmPFWJtnd
wiiVhkG2N/PGUEOiBAuhurNYQcmyzVc1zgfEBq0Ad6ZnJzfbW0H5fw==
=OHGh
-----END PGP SIGNATURE-----