Card readers for online banking
The Chip Authentication Programme (CAP) has been introduced by banks
in Europe to deal with the soaring losses due to online banking fraud.
A handheld reader is used together with the customer’s debit card to
generate one-time codes for both login and transaction authentication.
The CAP protocol is not public, and was rolled out without any public
scrutiny. We reverse engineered the UK variant of card readers and
smart cards and here provide the first public description of the
protocol. We found numerous design errors, which could be exploited by
criminals.
Banks throughout Europe are now issuing hand-held smart card readers
to their customers. These are used, along with the customer’s bank
card, for performing online banking transactions. In this talk I will
describe how we reversed-engineered the cryptographic protocol used by
these readers, using some custom-designed smart card analysis hardware.
We discovered several flaws in this protocol, which could be exploited
by criminals (and some already are). This talk will explain what
vulnerabilities exist, and what the impact on customers could be.
Online banking fraud has increased 185% between 2007 and 2008.
Simple fraud techniques dominate due to poor overall security and awareness :
- Phishing emails
- Keyboard loggers
Some common security measures that UK banks have implemented :
- On-Screen keyboards
- Picture passwords
- Device fingerprinting (using HTTP header information to track and block)
- One-time-passwords/iTAN
All of these are bypassable in one way or another. Whether it’s through MitM style attacks, of faking headers. Commonly however Man in the Browser attacks are used, as it offers a complete control over the victim’s machine. What the victim sees, isn’t what they send/receive.
To combat this, the response must be bound to the transaction to be authorised. Various methods have been implemented, including several UK banks that are now using hardware based challenge/response for authorisation of transactions. These devices conform to the EMV specification v4.2
- Customer enters PIN
- Customer enters transaction details
- Reader displays authorisation code
- Customer enters code into the browser
- Bank verifies the authorisation code in the background
How this protocol works is a closed box.
By building a smart card snooper (based on the Xilinx FPGA development board from Opal Kelly) it was possible to discover information about the underlying protocols.
- Protocol very similar to EMV (used for smartcard payments in Europe)
- Looks like a transaction but cancelled at the last stage
- Contains 2 data items not listed in the EMV specification
Changing some data
By modifying specific pieces of data and leaving others the same, it was possible to observe the reaction of the device. By flipping 1 bit, sometimes the transaction failed, other times the resulting code was different.
- The authentication code comes from the cryptogram generated by the card at the end of the transaction
- The mysterious tag 9f56 was a ‘bit filter’ which selects which bits from the cryptogram are used for the response
- The filtered cryptogram is then converted to decimal
It was found that there were no cryptographic secrets within the device itself. This means that a software implementation was easy to achieve (a number are available).
Useability failures aid fraudsters
The different banks use varied features of the devices. This leads to confusion where a fraudster can fool a user into using the device in a way that the input is what the fraudster wants and not what the bank expects.
Nonce is small or absent
- No nonce in Barclays variant, so response stays valid
- Only a 4 digit nonce with Natwest (weak 100 guesses = 63% success rate)
Fake point of sales devices can get responses in advance.
CAP readers help muggers – CAP readers can be used to check if the PIN number is correct or not.
Supply chain infiltration – In the past chip & pin terminals with GSM modules have already been found in the wild. The control of CAP readers is significantly less controlled.
What does this mean for customers
- CAP is far better than existing UK systems
- Authentication codes are dynamic
- Authentication codes are bound to transaction
However, banks are now claiming that any transaction using this process must have been authorised by the user. This means that if you are a victim of fraud, the bank will probably deny your claims. Currently ~20% of claims are turned down.
Recent attempts to test this in court failed, with the Bank winning (Halifax). The evidence provided by the bank was simply a log file showing that the transaction was chip read (04 in the log).
HHD 1.3
Standard from ZKA, Germany
Stronger than UK CAP, but more user input required
- Many more modes
- Mode number alters meaningful prompts
- Up to 7 digit nonce
- Nonce, and mode number are included in MAC
- PIN verification
Other solutions
- Flicker TAN – Device reads information from a flickering animation (using sensors)
- USB connected readers – Require drivers, so could be an issue without Admin permissions
- Cronto PhotoTAN – Uses a 2D barcode read by a mobile phone application (uses a cryptographic key to prevent MitM)
More information can be found on the CCC wiki. Access to the slides (PDF)
Cатсн²² (in)sесuяitу / ChrisJohnRiley 