IBM Zurich researcher Diego Ortiz-Yepes recently revealed a new Two Factor Authentication technique in which the bona fides of a user of a mobile app are demonstrated via a contactless smartcard waved over the mobile device. The technique leverages NFC -- but as a communications medium, not as a payments protocol. The method appears to be compatible with a variety of smartcards, capable of carrying a key specific to the user and performing some simple cryptographic operations.
This is actually really big.
I hope the significance is not lost in the relentless noise of new security gadget announcements, because it's the most important new approach to authentication we've seen for a long long time. The method can easily be adopted by the NFC and smartcard ecosystems with no hardware changes. And with mobile adoption at a tipping point, we need true advances in security like this to be adopted as widely and as quickly as possible. If we ignore it, future generations will look back on the dawn of m-business as another opportunity lost.
A golden opportunity to address an urgent problem
Mobile represents the first greenfield computing platform in thirty years. Not since the PC have we seen a whole new hardware/software/services/solutions environment emerge.
It's universally acknowledged that general purpose PCs and Internet Protocol for that matter were never engineered with security much in mind. The PC and the Internet were independently architected years before the advent of e-commerce, and without any real sense of the types of mission critical applications they would come to support.
I remember visiting Silicon Valley in 1998 when I was with KPMG's pioneering PKI team, working on, amongst other things, the American Bar Association e-signature guidelines. We were meeting with visionaries, asking Will anyone ever actually shop "online"?. Nobody really knew! But at startling speed, commodity PCs and the Internet were indeed being joined up for shopping and so much more: payments, and e-health, and the most sensitive corporate communications. Yet no mainstream computer manufacturer or standards body ever re-visited their designs with these uses in mind.
And so today, a decade and a half on (or a century in "Internet years") we have security boffins earnestly pronouncing "well you know, there is no identity layer in the Internet". No kidding! Identity theft and fraud are rife, with as yet no industry-wide coordinated response. Phishing and pharming continue at remarkable rates. "Advanced Persistent Threats" (APTs) have been industrialised, through malware exploit kits like Blackhole which even come with licensing deals and help desk support that rivals that of legitimate software companies. Even one of the world's very best security companies, RSA, fell victim to an APT attack that started with an trusted employee opening a piece of spam.
But in the nick of time, along comes the mobile platform, with all the right attributes to make safe the next generation of digital transactions. Most mobile devices come with built-in "Secure Elements": certifiably secure, tamper-resistant chips in which critical cryptographic operations take place. Historically the SIM card (Subscriber Identification Module) has been the main Secure Element; "NFC" technology (Near Field Communications) introduces a new generation of Secure Elements, with vastly more computing power and flexibility than SIMs, including the ability to run mission critical apps entirely within the safe chip.
The Secure Element should be a godsend. It is supported in the NFC architecture by Trusted Service Managers (TSMs) which securely transfer critical data and apps from verified participants (like banks) into the consumers' devices. Technically, the TSMs are a lot like the cell phone personalisation infrastructure that seamlessly governs SIM cards worldwide, and secures mobile billing and roaming. Admittedly, TSMs have been a bit hard to engage with; to date, they're monopolised by telcos that control access to the Secure Elements and have sought to lease memory at exorbitant rates. But if we collectively have the appetite at this time to solve cyberspace security then mobile devices and the NFC architecture in particular provide a once-in-a-generation opportunity. We could properly secure the platform of choice for the foreseeable future.
The IBM Two Factor Authentication demo
Before explaining what IBM's Ortiz-Yepes has done, let's briefly review NFC, because it is often misconstrued. NFC technology has a strong brand that identifies it with contactless payments, but there is much more to it.
"Near Field Communications" is a short range radio frequency comms protocol, suited to automatic device-to-device interfaces. To the layperson, NFC is much the same as Bluetooth or Wi-Fi, the main difference being the intended operating range: 10s of metres for Wi-Fi; metres for Bluetooth; and mere centimetres for NFC.
NFC has come to be most often used for carrying wireless payments instructions from a mobile phone to a merchant terminal. It's the technology underneath MasterCard PayPass and Visa payWave, in which your phone is loaded with an app and account information to make it behave like a contactless credit card.
The NFC system has a few modes of operation. The one used for PayPass and payWave is "Card Emulation Mode" which is pretty self explanatory. Here an NFC phone appears to a merchant terminal as though it (the phone) is a contactless payment card. As such, the terminal and phone exchange payments messages exactly as if a card was involved; cardholder details and payment amount are confirmed and send on to the merchant's bank for processing. NFC payments has turned out to be a contentious business, with disconcertingly few success stories, and a great deal of push-back from analysts. The jury is still out on whether NFC payments will ever be sustainable.
However, NFC technology has other tricks. Another mode is "Reader Emulation Mode" in which the mobile phone reads from (and writes to) a contactless smartcard. As an identity analyst, I find this by far the more interesting option, and it's the one that IBM researchers have exploited in their new 2FA method.
According to what's been reported at CNET and other news outlets, a mobile and a smartcard are used in what we call a "challenge-response" combo. The basic authentication problem is to get the user to prove who she is, to the app's satisfaction. In the demo, the user is invited to authenticate herself to an app using her smartcard. Under the covers, a random challenge number is generated at a server, passed over the Internet or phone network to the mobile device which in turn sends it over NFC to the smartcard. The card then 'transforms' the challenge code into a response using a key specific to the user, and returns it to the app, which passes it back to the server. The server then verifies that the response corresponds to the challenge, and if it does, we know that the right card and therefore the right user is present.
NOTE:Technically there are a number of ways the challenge can be transformed into a response code capable of being linked back to the original number. The most elegant way is to use asymmetric cryptography, aka digital signatures. The card would use a unique private key to encrypt the challenge into a response; the server subsequently uses a public key to try and decrypt the response. If the decrypted response matches the challenge, then we know the public key matches the private key. A PKI verifies that the expected user controls the given public-private key pair, thus authenticating that user to the card and the app.
Further, I'd suggest the challenge-response can be effected without a server, if a public key certificate binding the user to the key pair is made available to the app. The challenge could be created in the app, sent over NFC to the card, signed by the private key in the card, and returned by NFC to be verified in the app. Local processing in this way is faster and more private involving a central server.
Significance of the demo
The IBM demonstration is a terrific use of the native cryptographic powers now commonplace in smartcards and mobile apps. No hardware modifications are needed to deploy the 2FA solution; all that's required is that a private key specific to the user be loaded into their smartcard at the time the card is personalised. Almost all advanced payments, entitlements and government services cards today can be provisioned in such a manner. So we can envisage a wonderful range of authorization scenarios where existing smartcards would be used by their holders for strong access control. For example:
- Employee ID card (including US Govt PIV-I) presented to an enterprise mobile app, to access and control corporate applications, authorize purchase orders, sign company documents etc
- Government ID card presented to a services app, for G2C functions
- Patient ID or health insurance card presented to a health management app, for patient access to personal health records, prescriptions, claims etc.
- Health Provider ID card presented to a professional app, to launch e-health functions like dispensing, orders, admissions, insurance payments etc,
- Credit Card presented to a payment app, for online shopping.
I can't believe the security industry won't now turn to use smartcards and similar chipped devices for authenticating users to mobile devices for a whole range of applications. We now have a golden opportunity to build identity and authorization security into the mobile platform in its formative stages, avoiding the awful misadventures that continue to plague PCs. Let's not blow it!
Great article, thanks for your support.If your readers are interested in watching the video demo here is the link: http://www.youtube.com/watch?v=3sT6D1IdBH8
At my previous employer, ACI Worldwide, I was the Director for Security Engineering. ACI offers a commercial Web banking product that is used my many U.S. banks.
We looked very carefully at the IBM ZTIC technology from the Zurich Labs, which is used in this new offering. We concluded that it would solve many of our fraud problems. The only drawback was that they used an EMV card to personalize the device and of course, this wouldn't work in the U.S. where we offered our product.
The ZTIC had several key features. It had a small display and a yes/no keyboard that were on the device and not controlled by software. No malware could be loaded in the device. So the Zeus-malware based threats that were our nemesis could not spoof the transaction. From a practical point, personalizing the device using an inserted EMV card meant that the devices could be generically manufactured and distributed easily. Since this was a banking app, the banks could do their cryptography using the secrets in the EMV chip.
Vasco offered the ZTIC commercially as an option for the Digipass 865.
I see that the folks in Zurich have not been idle. They have moved on to the next generation of this concept.