Management of signature keys for government

[Markus Kuhn]

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.
> 
> It seems so and this makes smartcards an inadequate vehicle for really good
> security at the moment.  For some defence applications in which I have been
> involved we had to adopt the PCMCIA card format for just this reason.

This is not the issue. I am very well aware that EEPROM-based smartcards
provide only a medium level of tamper-resistance and that state-of-the-art
miniature tamper-resistant modules such as say the DalSemi DS1954 CryptoButton
or the various IBM security modules are based on battery buffered SRAM
combined with a whole range of alarm zeroisation and anti-tampering features
that go far beyond of what smartcard processor manufacturers do today
<http://www.cl.cam.ac.uk/~mgk25/tamper.pdf>.

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

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>