by Diego A. Ortiz-Yepes
In the past few months, a mobile phone-based authentication mechanism for eBanking has been developed at the IBM Zurich Research Laboratory. At the core of this mechanism, we have used NFC and CAP. The latter, Chip Authentication Program (CAP), is a specification developed by MasterCard that provides mechanisms for customer authentication based on smart cards compliant with EMV (Europay - MasterCard - Visa). The former, Near-Field Communication (NFC), is an emerging technology related to RFID that is already being incorporated into commercially available mobile phones, allowing them to communicate over very short distances (in the order of a few centimetres) with other NFC-enabled devices. This ability, when employed in tandem with CAP - as we have done in our authentication mechanism - greatly enhances the overall usability of the authentication system.
Our NFC-based authentication mechanism relies on dual-interface smart cards, that is, cards with both contact and contactless interfaces. These cards might also be used for other financially related purposes, eg as debit or credit cards. In fact, this situation is desirable in order to avoid burdening the customer with an additional card for eBanking purposes.
The customer authentication mechanism works by having the customer produce an appropriate response to an unpredictable challenge generated by the bank. In order to do so, she must use her card and its PIN, which is used to authenticate the customer to the card. More precisely, when the customer wishes to engage in eBanking, she visits the Internet site of her bank, which requests her customer ID, eg her account or contract number. Once such an ID has been received by the bank, it replies with a challenge, which consists of an unpredictable number of between 6 and 8 digits. Having received this challenge, the customer starts the phone application by touching her bank card to the back of the phone (see Figure 1). She then selects the log-in mode and types in the server-issued challenge. Prior to generating the corresponding response, the phone requests that the customer provide her PIN in order to authenticate herself to the card. Once the customer has been authenticated by the card, the phone sends the challenge to the card obtaining a cryptogram in return. Using this cryptogram a bit-string cryptographically bound to the challenge and the internal card state the phone generates a numeric code, ie the response, which is displayed to the customer. Subsequently, she sends the response to the bank server by typing it into the PC. When the response is received by the bank, the latter checks whether it corresponds to the previously issued challenge. If this is the case, the bank presents the customer with her account(s) summary, as well as some appropriate transaction options.
The mechanism outlined above replaces the Personal Card Reader (PCR) required by some authentication schemes currently in use, yielding a more convenient authentication mechanism. This follows from the fact that the user needs only her phone and her card in order to authenticate herself to the bank. On the one hand, phones are truly ubiquitous devices that can hardly be considered a burden; on the other, most people carry their bank cards with them in their wallets or purses, making the requirements of our authentication mechanism quite low.
Note that both the challenge and the response could be sent directly from the bank server to the phone and back via SMS, or some other suitable mechanism using the mobile phone network. This would not only simplify the mechanism, but would also increase the level of security as a consequence of using the phone and a secondary channel, whose compromise is much less likely than the PC alone.
In conclusion, we have developed an eBanking authentication mechanism whose security properties are comparable to PCR-based CAP. NFC-enabled mobile phones are a key component of this mechanism, providing an enhanced level of usability, not only by replacing the PCR altogether, but also being able to offer a more pleasant user experience. Additionally, we have implemented this mechanism in such a way that it integrates seamlessly with an existing CAP infrastructure, allowing it to be used in a real-life pilot by the end of 2008.
Please contact:
Michael Baentsch, Michael Osborne, Diego A. Ortiz-Yepes
IBM Zurich Research Lab, Switzerland
E-mail: mib
zurich.ibm.com, osbzurich.ibm.com, ortzurich.ibm.com
