RE: Smart card proposal

[Michael Silk <michaelsilk () gmail com>]

Rogan,

I like it :)

But let me make some comments.

Implementation:
Assuming this does happen, home users would need a smart-carder reader
there, right ? (And at any location they wish to access the
banking...). Also, it wouldn't take place immediately, so for a while
(a long time...?) the current system would need to continue working,
unless the banks decided to provide these things (readers+cards) for
free.

So we can note that there may be a very long period in which this
system is practically useless (from the p.o.v of a phisher - as they
target the silly and lazy anyway...).


Pins:
We can note that the smart-card data is "locked" with the PIN, but how
does this _actually_ work? Is it possible to bypass it with some
software? (i really don't know...) or does it require hardware?

Also, when the user is at home, how do they enter the PIN? Has the
bank provided software to facilitate it? If so, why bother with the
cert on the credit card at all ? When not just install it on their
computer? (after all, it's alot of cost for the bank to do so ...)


Certificates:
How do the ATM's generate the certificates? Can they become
predictable? Could you predict the numbers "new" atms generate ?


Merchant Access:
I think this problem would be resolved by having a seperate PIN for
the website certificate.

Alternatively, the new and improved merchant reading systems could be
fitted to provide extra services to you. "Yes, I'll buy that suit, and
transfer $100 to my mother while you are at it!".


Single Point of Failure:
(we discussed this before, but) What about the poor fool that writes
his PIN(s) down inside his wallet, and then proceeds to lose it. But I
suppose this would be a problem with any physical system...


-- Michael


> -----Original Message-----
> From: Rogan Dawes [mailto:discard () dawes za net] 
> Sent: Wednesday, 19 January 2005 9:47 PM
> 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"