RE: Smart card proposal

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

Hi Mary Ann,

The size problem with a USB token is not with one token. Its once you
have 5. People are willing to carry 5 credit cards (you probably have as
much), but having 5 USB tokens is just too much on your key chain (and
the solution works fine, I would probably want 15!).

USB tokens are ideal for non consumer banking (on line trading, brokers)
and for employees.

And I'm sorry I did not mention, you are right and the iKey is processor
based.

~ 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 11:19 PM
> To: Ofer Shezaf; webappsec () securityfocus com
> Cc: maburns () safenet-inc com; hugo.fortier () gmail com;
> rms () computerbytesman com
> Subject: RE: Smart card proposal
>
>
>
> The iKey  token consists of a Microprocessor with a USB controller and
> memory (8k or 32k) all within a device small enough to store on your
key
> chain. The USB controller is USB 1.1/2.0 compliant device that acts
> similar
> to a smartcard reader and smartcard. The iKey also has support within
the
> microprocessor firmware to perform on-board MD5 hashing.
>
> I have been working with this two-factor issue for banking for the
last
> few
> years.  The truth of the matter is that the public isn't aware of the
> problem because most banking breaches are not talked about.  If the
public
> knew how often fraud in banking occurs, they would be asking their
banks
> for
> something more secure.  Here is another problem, the first bank that
> starts
> issuing a stronger authentication solution to its customers will
probably
> be
> criticized by its competition.  The same thing occurred in the 50s
with
> car
> makers when the Nash introduced seat belts.  The competitors
immediately
> started a campaign informing the public that seatbelts were needed on
> Nash's
> because their cars were unsafe.  Seatbelts aren't needed on our cars
> because
> they are safe.  The banking community would need to market a
two-factor
> device through an education process that informs their customers about
how
> difficult it is to combat fraud without the help and participation of
the
> consumer. Or it could offer customer the option, that way the first
bank
> that offers it is viewed as a technology leader and could possible
pick up
> new technical savvy customers. That what the business proposition is
all
> about.
>
> This is a classic case where technology and society are not on the
same
> track...but marketing to a technology savvy group could start the
trend
> that
> closes the gap.
>
> Mary Ann
>
>
> -----Original Message-----
> From: Ofer Shezaf [mailto:Ofer.Shezaf () breach com]
> Sent: Tuesday, January 25, 2005 1:01 PM
> To: webappsec () securityfocus com
> Cc: maburns () safenet-inc com; hugo.fortier () gmail com;
> rms () computerbytesman com
> Subject: RE: Smart card proposal
>
>
> 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"