Smart card proposal

[Rogan Dawes <discard () dawes za net>]

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"