n Fri, mep 03, 1999 at 08:00:40PM +0100, Peter Lister wrote:
> I'm thinking here about iButtons in particular, but the question is valid
> for all authentication tokens, smart cards, etc. Sorry if it's off-topic
> by not being Linux specific, but I've yet to find an answer anywhere.
>
> Assuming that I do *not* have control of the hardware into which my SC is
> currently plugged via a reader, how can a program (which, e.g. we have
> licensed to a client) be sure that it is talking to the genuine SC, and
> not an emulator? I really don't care how well tamper proofed the chip is
> if, or if it self destructs after 30 days free trial, if I can simply
> reproduce an unlimited number of copies in software which will have the
> same supposedly "unique" serial number, or have electronic wallets
> permanently charged up with credit which never decrements. Anything that
> passes along the serial interface can be intercepted and replayed, right?
Right. Although you can use the usual cryptographic techniques
to prevent replay and to prevent a snooper from listening in
to the RS232 traffic. You might need a higher-capability card
or a programmable card (i.e. Javacard) although the GPK4000
does have a DES-based protection for the traffic.
> One answer is if a crypto based key system generates an asymmetric
> key pair internally, and never reveals the private key or allows it to be
> set I understand that the crypto Java iButton will does this).
Many smart cards will do this, although the RNGs on smart cards
(used to generating the keys) is sometimes suspect.
> If the
> only traffic out of the SC is signed responses by that key pair and all
> the critical logic is internal, then any traffic on the serial line is
> only useful exactly once, which defeats replays. The software must
> contain code that checks for the smart card (and cannot easily by
> bypassed, which is an art in itself) - and this will be identical for all
> instances of the code.
>
> But even if the private key never leaves the SC, the corresponding public
> key must be stored *somewhere*, essentially in clear, though possibly
> obfuscated, and will be different for each different SC - and clearly any
> difference between otherwise identical distributions essentially *is* the
> key, and can be replaced with something else that an emulator would
> happily accept; back to square one.
>
> I do appreciate that I'm being really *quite* paranoid here, and that
> almost anything represents an improvement over current ways of
> doing things - essentially nothing. Can come up with characteristics which
> would be hard to beat, or is this a fundamentally insoluble problem?
It's impossible to make this 100% secure. The assumption that
you make is that the host can't be secured. This is true with Linux
or any other OS (execpting Orange Book type B1 or better OSs).
So, even with a perfect protocol between card and host, the
protocol can be attacked on the host side by running the communications
program through SoftICE or gdb or whatever to find it's secrets.
One solution is to fix your system so that host-based attacks don't
break the security model. I.e. the host is in a steel box
with only a network connection and smartcard slot to communicate
with the outside world. Problem is, this isn't very useful (and
someone could still break in via the net connection).
Or you can apply the usual software protection tricks (obfuscating
code, checking for being stepped in a debugger, etc) to your
software which authenticates the smart card and hope that is good enough.
--
Eric Murray www.lne.com/~ericm ericm at the site lne.com PGP keyid:E03F65E5
***************************************************************
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***************************************************************
