Management of signature keys for government

[Brian Gladman]

-----Original Message-----
From: Ross Anderson <Ross.Anderson@cl.cam.ac.uk>
To: ukcrypto@maillist.ox.ac.uk <ukcrypto@maillist.ox.ac.uk>
Date: 02 March 1998 09:05
Subject: Re: Management of signature keys for government


<much good material deleted>

>So if you switched from RSA to DSA and thus had a key generation time
>of 1/2 sec rather than 30 sec, then given a trustworthy terminal in
>the bank the customer can generate an initial signing key which can't
>be reconstructed unless both the bank and VISA cheat. Add tamper
>resistant boxes at both these places, add lots of audit, and ensure
>that if they do cheat they can acquire stupendous liabilities.
>Experience shows that you can just about make this work.


I assume here that the key is generated on card and the public component is
then exported into the trusted terminal?

It seems to me that we need complete open visibility of the algorithms and
hardware components used for key generation and I have been wondering how to
achieve this.  One possibility that I have been wondering about is that of
pursuing and openly publishing such a design in software down to the bits
that are loaded and then using digital signature techniques to ensure that
no changes are made.  The thought is that if the basic processor can (a)
check a digital signature and (b) has a ***very small*** area that can be
personalised during manufacture it might then be possible to ensure that a
card would only run a digitally signed, openly scrutinised key generation
process.  We still have to be sure that the basic card has not been
subverted but we might at least avoid subversion in other parts of the chain
from manufacture to the customer if this could be done.

I am not up on smartcards and the like but I imagine that even the smallest
amount of personalisation in manufacture is not possible?

Maybe, if we could really get an open key generation design that was widely
accepted it could simply be built into the basic smartcard anyway?  My point
here is that we have be be sure that the basic hardware has not been
subverted so we might as well do the key generation at this level and ensure
that it is subject to the scrutiny process that is necessary at this level
anyway.  There are counter arguments that I can think of but I wonder what
all the pros and cons of such an approach would be.

>
>It's not perfect, and you'll have the devil's own job dealing with
>`phantom withdrawals' when (say) carelessness at VISA is spotted and
>exploited by a programmer at a bank. The way to deal with this is in
>my view the line currently being advocated in the EU, namely a
>directive that a sworn statement by a customer will have equal force
>to a claim by a bank that its systems are secure. (HMG is of course
>going in the other direction by abolishing section 69 of the Police
>and Criminal Evidence Act, which will mean that people framed by GCHQ
>using escrowed copies of signature keys will have a hard time getting
>independent experts to examine the system. Hopefully the EU will
>frustrate this evil in one way or another.)
>
>You might conceivably make things work better by letting the customer
>bootstrap other keys for different applications in a variety of ways
>(card interaction with home PC, with M and S's eftpos terminal, with
>electricity meter, ...) and then verify the customer using available
>back channels (print your key fingerprint on your shop receipts). But
>there are substantial business problems here, such as `whose logo goes
>on the front?' These have killed all multi-function smartcard schemes
>so far and hopefully they'll also kill Mr Clark's obnoxious little
>scheme.

I am still trying to get information on Mr Clark's activity - have these
proposals been published anywhere?

     Brian