WebApp Sec mailing list archives
RE: Smart card proposal
From: "Ofer Shezaf" <Ofer.Shezaf () breach com>
Date: Tue, 25 Jan 2005 16:26:45 -0500
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 readerandthe pin can be typed on the keyboard since It does not really matter ifthekeystrokes are copied since with two-factor authentication you needthecombination 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
RSAsecure ID are more expense than an USB token like Rainbow iKey andneed abattery replacement (USB token does not). Plus RSA is a randompasswordgenerator and is not really two factor authentication and thedeploymenton a RSA Radius server is such that all remote users need to be on thesystemsince the sever cannot allow some to have the RSA token and others
in
thedirectory to have user name and passwords. USB tokens can be issued to some users (who want high security) andtheothers can remain on user names and password. Thus providing the
bank
withthe answer they need. Use the USB key for top security and beprotected orcontinue 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 tempusername and password and the bank sends out another key same as if they losttheirATM 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
cheapertujust 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 abadidea 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(AkaDigital Signature). Also those RSA Token have short lifetime, due to the fact that theyhavebuilt-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 lowerthanthe 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, Idon'tsee 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 thebestmethod 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 intheStates 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 ordebitcards 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 andSSLclient certificate, which would be used to authenticate theirclientswhen they wish to perform internet banking. Positive consequences: The bank is performing the same effective authentication as they
do
attheir ATM's. Something you have (the card) and something you know(thePIN). This may or may not be the same PIN as would be used in anATM.This would be a policy decision, made by the issuing bank. Policy decisions can be enforced on the smart card, because thesmartcard 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.Theyknow 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 communicatewithsmart 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
aCSR, 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 usercanaccess via the ATM, so that Internet banking is effectivelyseamless.If the user forgets the certificate PIN, and tries to guess it
more
than ${policy} times, the smart card locks it out. Then, the usercango to an ATM, enter his ATM PIN, request a certificate PIN reset,theATM 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 inthesame way as they do with the ATM PIN. Depending on the bank's policy, the user may be able to change thePINat their own computer. This would however mean that the bank wouldnotbe in a position to know what the current certificate PIN actuallyis.An alternative is to require the PUK before allowing PIN changes.ThePUK 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
inthe 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 itwould(should) not be possible to delay the transaction until after thecardis taken out. (Question: If I connect using a client cert,
establish
aSSL shared session key, then remove the smart card, can I continuetouse that session key?) Also, most merchants do not have access to reprogram their card terminals, this is generally done by thesupplier.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 bereenteredto 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"
Current thread:
- Re: Smart card proposal, (continued)
- Re: Smart card proposal Rishi Pande (Jan 24)
- Re: Smart card proposal Rogan Dawes (Jan 24)
- Re: Smart card proposal Hugo Fortier (Jan 24)
- Re: Smart card proposal Rogan Dawes (Jan 27)
- Re: Smart card proposal Hugo Fortier (Jan 24)
- RE: Smart card proposal Richard M. Smith (Jan 24)
- Re: Smart card proposal Rogan Dawes (Jan 27)
- RE: Smart card proposal Richard M. Smith (Jan 27)
- Re: Smart card proposal DE Gustafson (Jan 27)
- Re: Smart card proposal Koh Gim Leng (Jan 28)
- RE: Smart card proposal Lyal Collins (Jan 28)
- Security Webcast Series JoeStagner (Feb 02)
- RE: Smart card proposal Lyal Collins (Feb 03)