RE: Smart card proposal

["Ofer Shezaf" <Ofer.Shezaf () breach com>]

I think that Mary Ann provides the most complete overview of the
technical aspects of things.

One addition is that we should distinguish between processor based
devices and memory based devices. Both smartcard and USB tokens can be
both processor based and memory based. Only processor based devices can
perform public key based challenge response without letting out the
private key. Such a mechanism makes duplicating the hardware device very
difficult (that is to say impossible for now).

As far as I know most smart cards based credit cards are EMV based, a
standard developed by Visa, MasterCard and Europay (www.emvco.com) and
are processor based. Other smartcards or USB tokens out there may be
memory based.

But my experience in banking security shows that the issue is probably
more business, marketing and security awareness than technology:

While USB drives don't require a drive, they don't fit consumer
applications as customers are not would be reluctant to carry multiple
USB tokens. On the other hand, credit card size smart cards are perfect
- but require a drive.

Interestingly enough, there where a few attempts to use smart card based
authentication for consumer banking. For example American Express have
been offering smart card readers for free to use with their Blue Chip
cards
(https://www124.americanexpress.com/cards/loyalty.do?page=blue.idkeeper)
. Did any one of you seleted AmEx for that? Has it?

A startup which I met developed a credit card size challenge response
authentication that does not require a drive (actually communication
with the PC was audio based) without much success. Banks did not buy it.

Why these attempts failed? Lack of real security concern by vendors? By
consumers? Price of the technology (and the required customer service)?
Probably all. Maybe the sharp rise in phishing and related identity
theft issues will make consumer and the industry adapt such a solution.
Another encouraging fact is that the credit card companies for using
smart cards instead of magnetic stripes.

~ Ofer

Ofer Shezaf
CTO, Breach Security

Tel: +972.9.956.0036 ext.212
Cell: +972.54.443.1119
ofers () breach com
http://www.breach.com 


> -----Original Message-----
> From: maburns () safenet-inc com [mailto:maburns () safenet-inc com]
> Sent: Tuesday, January 25, 2005 2:27 AM
> To: hugo.fortier () gmail com; rms () computerbytesman com
> Cc: webappsec () securityfocus com
> Subject: RE: Smart card proposal
>
>
> Hugo
>
> The USB Key token would eliminate the need for the smartcard reader
and
> the
> pin can be typed on the keyboard since It does not really matter if
the
> keystrokes are copied since with two-factor authentication you need
the
> combination of the physical device and the pin# ( two factor is -
> something
> you have (USB key) with something you know (pin#).
>
> The RSA random password generator won't work for the reason below. The
RSA
> secure ID are more expense  than an USB token like Rainbow iKey and
need a
> battery replacement (USB token does not). Plus RSA is a random
password
> generator and is not really two factor authentication and the
deployment
> on
> a RSA Radius server is such that all remote users need to be on the
system
> since the sever cannot allow some to have the RSA token and others in
the
> directory to have user name and passwords.
>
> USB tokens can be issued to some users (who want high security) and
the
> others can remain on user names and password. Thus providing the bank
with
> the answer they need. Use the USB key for top security and be
protected or
> continue to use user name and password but at your own risk.
>
> If the user loses their key they call the help desk and get a temp
user
> name
> and password and the bank sends out another key same as if they lost
their
> ATM card, they get a replacement. Or they can elect to switch over the
> username and password if they don't like the key.
>
> Mary Ann
>
> -----Original Message-----
> From: Hugo Fortier [mailto:hugo.fortier () gmail com]
> Sent: Monday, January 24, 2005 10:20 AM
> To: Richard M. Smith
> Cc: Webappsec List
> Subject: Re: Smart card proposal
>
> USB Flash drive and Credit Card sized CD are't to be compaired with
> SmardCard. They have none of the propriety that a smartcard have...
> While it's is somewhat better than storing the key directly on the
> computer,
> it should't be considered a lot more secure. And it be a lot cheaper
tu
> just
> use a crypto key stored on the PC.
>
> SmartCard readers are getting cheaper and cheaper, only issue is that
> inexpensive one does not have PIN Pad included in the reader. It's a
bad
> idea to enter your pin on your computer keyboard.
>
> I agree with you that PIN number generator are interesting, but for a
> online
> bank they does't provide the advantage a smart card would give them
(Aka
> Digital Signature).
>
> Also those RSA Token have short lifetime, due to the fact that they
have
> built-in battery and are easy to break. I doubt RSA Token are cost
> effective
> on big deployment like Online banking...
>
> We have to remember that the cost of the solution have to be lower
than
> the
> lost caused by fraud.
>
> Hugo
>
> On Mon, 24 Jan 2005 07:27:54 -0500, Richard M. Smith
> <rms () computerbytesman com> wrote:
> > Since almost no PCs that I am aware of have SmardCard readers, I
don't
> > see how this scheme works.  Could a USB flash drive or a credit
> > card-sized CD ROM be used instead? (See
> > http://www.mediaheaven.co.uk/cd-business-cards.htm)  These devices
> > typically don't require new software.
> >
> > I still like a PIN-number generator device for a key ring as the
best
> > method to improve security beyond passwords and PINS.  One of these
> > devices generates random PIN numbers that are only known by the bank
> > and the person who is holding the device.  They are popular her in
the
> > States in remote access systems to corporate networks.  (See
> > http://www.rsasecurity.com/node.asp?id=1173).
> >
> > Richard
> >
> > -----Original Message-----
> > From: Rogan Dawes [mailto:discard () dawes za net]
> > Sent: Wednesday, January 19, 2005 5:47 AM
> > To: Webappsec List
> > Subject: Smart card proposal
> >
> > Hi folks,
> >
> > As part of the discussion recently about phishing, I was thinking
> > about how a hardware token (and a smart card in particular) could be
> > used to secure web transactions.
> >
> > It also struck me that more and more banks are issuing credit or
debit
> > cards with smart-card capabilities.
> >
> > This led to the thought that banks could use the smart-card
> > capabilities (via a smart-card reader) to store a private key and
SSL
> > client certificate, which would be used to authenticate their
clients
> > when they wish to perform internet banking.
> >
> > Positive consequences:
> >
> > The bank is performing the same effective authentication as they do
at
> > their ATM's. Something you have (the card) and something you know
(the
> > PIN). This may or may not be the same PIN as would be used in an
ATM.
> > This would be a policy decision, made by the issuing bank.
> >
> > Policy decisions can be enforced on the smart card, because the
smart
> > card can run applications. So policies such as PIN complexity,
> > lockout, etc can all be specified by the bank, and enforced. This is
> > platform independent, browser independent, CPU independent, etc.
> >
> > Users already have an idea of how to protect their credit cards.
They
> > know what the implications are if they get lost or stolen. They tend
> > to keep them in a safe place. Even if they do get compromised, the
> > card is still protected by a PIN, and is effectively unusable.
> >
> > ATM's mostly already have infrastructure to read and communicate
with
> > smart cards. Users can use ATM's as self-service terminals to set up
> > their internet banking. e.g. the user enters their PIN at the ATM,
> > selects Internet Banking, Register. The ATM instructs the smart card
> > to generate a private key, takes a copy of the public key, generates
a
> > CSR, requests the Bank's CA to sign the cert, and installs the cert
> > into the smart card. It then asks the user to choose a PIN for the
> > certificate, so that it cannot be accessed without it. At the same
> > time, it links the certificate to the same accounts that the user
can
> > access via the ATM, so that Internet banking is effectively
seamless.
> > If the user forgets the certificate PIN, and tries to guess it more
> > than ${policy} times, the smart card locks it out. Then, the user
can
> > go to an ATM, enter his ATM PIN, request a certificate PIN reset,
the
> > ATM then supplies a (card specific) PIN Unlock Key, which allows the
> > user to enter a new PIN for the cert.
> >
> > The certificate lifetime would be the same as the validity period of
> > the credit card. When the bank issues a new credit card, the user
> > should go back to an ATM, and reregister for Internet banking.
> > Alternatively, if the user is already registered, the bank can
> > pregenerate a key and certificate in the card, register it with
> > Internet Banking, and provide the user with the certificate PIN in
the
> > same way as they do with the ATM PIN.
> >
> > Depending on the bank's policy, the user may be able to change the
PIN
> > at their own computer. This would however mean that the bank would
not
> > be in a position to know what the current certificate PIN actually
is.
> > An alternative is to require the PUK before allowing PIN changes.
The
> > PUK could only be provided by the ATM . . . allowing the bank to
> > obtain a copy of the certificate PIN . . .
> >
> > Negative Implications:
> >
> > If the credit card is stolen, there is a risk of access via the
> > Internet as well. This may or may not already be an issue, if users
> > can self-register using their credit card PIN. (possible in some
> > countries)
> >
> > Using the smart card at a merchant might allow the merchant to issue
> > additional internet banking transactions while the card is inserted
in
> > the slot, and the PIN has been entered into their card processing
> > device. I think the close coincidence of the fraudulent transactions
> > with a legitimate transaction would be suspicious. Note that it
would
> > (should) not be possible to delay the transaction until after the
card
> > is taken out. (Question: If I connect using a client cert, establish
a
> > SSL shared session key, then remove the smart card, can I continue
to
> > use that session key?) Also, most merchants do not have access to
> > reprogram their card terminals, this is generally done by the
supplier.
> > Session Riding:
> >
> > One thing that I have ignored up until now is the issue of session
> > riding, where an attacker makes use of the fact that the SSL
> > connection is transparently created.
> >
> > One thing mitigating against that is the requirement for the user to
> > have entered their PIN to access the certificate on the card. It may
> > be possible to set a timeout on the card, so that the PIN must be
> reentered
> >   to continue transacting.
> >
> > Thoughts? Comments?
> >
> > Rogan
> > --
> > Rogan Dawes
> >
> > *ALL* messages to discard () dawes za net will be dropped, and added to
> > my blacklist. Please respond to "lists AT dawes DOT za DOT net"