[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20040430102451.A27433@slack.lne.com>
Date: Fri, 30 Apr 2004 10:24:52 -0700
From: Eric Murray <ericm@....com>
To: Peter Gutmann <pgut001@...auckland.ac.nz>
Cc: bugtraq@...urityfocus.com, secprog@...urityfocus.com,
silkm@...hmail.com
Subject: Re: Smart Card
On Sat, May 01, 2004 at 03:56:35AM +1200, Peter Gutmann wrote:
> "Michael Silk" <silkm@...hmail.com> writes:
>
> >I think that if the smart card reader (scr) and the client program (cp)
> >establish a ssl-type connection then the only opportunity to observe the
> >private key, certificate, is by inspecting the memory of cp. However I don't
> >believe that this (or any?) smart cards to this ...
>
> I'm not aware of any readers that establish SSL connections (they wouldn't be
> much use if they did, because the PC wouldn't be able to take advantage of the
> SSL channel). It's the host PC that does this, and once the host PC is
> compromised you're toast, smart card or none.
There's two diferent systems I know that attempt to address this
in some way.
In some readers there is a PIN pad on the reader. So the PIN that
unlocks the secret key is never sent through the PC. However that doesn't
defend against a rogue program on the PC using the private key once
the card's been unlocked.
The other is a system I helped develop, where the reader had
crypto capabilities and a PIN pad and an LCD, and the only things
that went to or from the PC were signed and/or encrypted as appropriate.
The problem with this, besides expense, is that the reader now has to
implement some part of the protocol that the PC would have been using to
do whatever secure thing it's doing that needs a smartcard in the first place.
In my case, this was the SET protocol (all together now: YUCK!).
There may be someone else who has implemented this type of thing
more recently.
Eric
Powered by blists - more mailing lists