Management of signature keys for government

[Richard Watts]

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).

>It is feasible to reverse engineer smartcards (cost in the
>order of 10^4 USD per processor type) and these capabilities could be
>used for sample quality control of a manufacturer's output. This would
>not be possible any more with modern high-grade tamper-resistant modules that
>not even government labs can open. Tamper-resistance and quality assurance
>(including security evaluation) seem unfortunately to be conflicting
>design goals.

 Well, obviously: the former requires that no information leak, the
latter requires that all information leak.

 What we want is to be able to reverse-engineer the program (ie. the
smartcard logic), but not the key. It shouldn't be hard to come up
with some nearly-provably secure design[1] such that the stored key
can't possibly affect the computation. That's when you have to start
worrying about the possibility of duff keys being inserted, and you
might even be able to get around that if you could design one-time
programmable hardware such that the key can only be written, once, by
a program loaded onto the card, and that program can never be erased
without obvious results.

 Given that only a small portion of smartcards will be verified, this
gives the spooks the chance to target some (small) number of people
with modified smartcards which (eg.) leak key or are escrowed. Just so
long as none of those cards are ever sent in for verification, they'll
be fine (and if they are, the spooks can just claim it was a
manufacturing error).

 Of course, the point about setting up large targets applies here
as well (though not to as great a degree): once you introduce a 
single signature algorithm for almost all purposes, and cheerfully
declare that all the real-world safeguards we currently use to
prevent forgery (postal addresses, witnesses, real paper documents
etc.) are now redundant, the value of an attack goes through the 
roof. The logical scheme would be for every government department
to support any major digital signature system that came along
(modulo a security audit).


Richard.
[1] Implementing the design is left as an exercise for the reader :-).