M
Martin Gregorie
I don't see how you can avoid re-keying the challenge and still guarantee
that the smartcard isn't accessible by trojans, etc.
The authentication page is published by the card issuer from their own
website using SSL and read by them, so the URL on the browser should
match the heading on the page and the SSL flag should be displayed. Its
hard to see how you can do better than that.
There's message separation involved: the vendor only knows your name,
address (for goods dispatch) and the card number, which he sends to the
card issuer. If these match the card issuer's database then control
switches to the card issuer.
The card issuer uses this detail to find the challenge seed in his
database and sends you a page containing the card number and your name
for confirmation together with the challenge. He also calculates a one-
time response and stores it in your account record. You only send the
response code from your card reader to the issuer, who compares it with
their expected response. If it matches the vendor gets an ACCEPTED
response and the issuer debits your account and credits the vendor.
The only field on this screen that accepts your input is the response box.
So, the message flow is:
Message Content
you->vendor your card number, name and address
vendor->CI your card number, name (and address?)
CI->you card number, name, challenge code
you->CI response code
CI->vendor ACCEPT or DECLINE
vendor->you transaction accepted or refused
which gives good separation: no message contains all the details that
would be needed to complete the transaction and the additional details
used in card-present or phone transactions (expiry date, security code)
are never part of any message.
Looked at it this way, its hard to see how a fake CI website, key logging
or sniffing the traffic can benefit a fraudster: the most they can get by
sniffing your traffic is card number, name, address and a one-time
challenge code. OK, and a one-time response code
I can't prove this, but I think the card reader just powers the card,
passes the challenge into it and displays the response when its returned
by the card. That way the card reader is kept simple and never stored
anything: it purely acts as a terminal for the smartcard.
BTW, I've head of, but not yet seen, another smartcard design that builds
the keypad and display into the card rather than requiring a reader, but
I have no idea what it uses for batteries or how they get charged: that
wasn't mentioned. All I'd say is that getting all that into a card that
still goes into an ATM is a pretty neat trick.