This is a copy of an op-ed I wrote in IT News on 20 September.
It’s been suggested that with Apple’s introduction of biometric technology, the “i” in iPhone now stands for “identity”. Maybe “i” is for “ironic” because there is another long-awaited feature that would have had much more impact on the device’s identity credentials.
The fingerprint scanner has appeared in the new iPhone 5s, as predicted, and ahead of Near Field Communications capability. In my view, NFC is much more important for identity. NFC is usually thought of as a smartcard emulator, allowing mobile devices to appear to merchant terminals as payments instruments, but the technology has another lesser known mode: reader emulation.
NFC devices can be programmed to interface with any contactless card: smart driver licenses, health cards, employee ID and so on. The power to identify and authenticate to business and enterprise apps using real world credentials would be huge for identity management, but it seems we have to wait.
Meanwhile, what does the world’s instantly most famous fingerprint reader mean for privacy and security? As is the case with all things biometric, the answers are not immediately apparent.
Biometric authentication might appear to go with mobiles like strawberries and cream. Smartphones are an increasingly central fixture in daily life and yet something like 40% of users fail to protect this precious asset with a PIN. So automatic secure logon is an attractive idea.
There are plenty of options for biometrics in smartphones, thanks to the built in camera and other sensors. Android devices have had face unlock for a long time now, and iris authentication is also available. Start-up EyeVerify scans the vein pattern in the whites of the eye; gait recognition has been mooted; and voice recognition would seem an obvious alternative.
With its US$365M acquisition of Authentec in 2012, Apple made a conspicuous commitment to a biometric technology that was always going to involve significant new hardware in the handset. The iPhone 5s incorporates a capacitive fingerprint detector in a subtly modified Home button. Ostensibly the button operates as it always has, but it automatically scans the user’s finger in the time it takes to press and release. Self-enrolment is said to be quite painstaking, with the pad of the finger being comprehensively scanned and memorised. This allows the relatively small scanner to still do its job no matter what fraction of the fingertip happens to be presented. Up to five alternate fingers can be enrolled, which allows for a fall-back if the regular digit is damaged, as well as additional users like family members to be registered.
This much we know. What’s less clear is the security performance of the iPhone 5s.
Remember that all biometrics commit two types of error: False Rejects where an enrolled user is mistakenly blocked, and False Accepts where someone else is confused for the legitimate user. Both type of error are inevitable, because biometrics must be designed to tolerate a little variability. Each time a body part is presented, it will look a little different; fingers get dirty or scarred or old; sensors get scratched; angle and pressure vary. But in allowing for change, the biometric is liable to occasionally think similar people are the same.
The propensity to make either False Positive or False Negative errors must be traded off in every biometric application, to deliver reasonable security and convenience. Data centre biometrics for instance are skewed towards security and as a result can be quite tricky and time consuming to use. With consumer electronics, the biometric trade-off goes very much the other way. Consumers only ever directly experience one type of error – False Rejects – and they can be very frustrating. Most users don’t in fact ever lose their phone, so False Accepts are irrelevant.
Thus the iPhone 5s finger reader will be heavily biased towards convenience, but at what cost? Frustratingly, it is almost impossible to tell. Independent biometrics researchers like Jim Wayman have long warned that lab testing is a very poor predictor of biometric performance in the field. The FBI advises that field performance is always significantly worse than reported by vendors, especially in the face of determined attack.
All we have to go on is anecdotes. We’re assured that the Authentec technology has “liveness detection” to protect against fake fingers but it’s a hollow promise. There are no performance standards or test protocols for verifying the claim of liveness detection.
The other critical promise made by Apple is that the fingerprint templates stored securely with the handset will never made accessible to third party applications nor the cloud. This is a significant privacy measure, and is to be applauded. It’s vital that Apple stick to this policy.
But here’s the rub for identity: if the biometric matching is confined to the phone, then it’s nothing more than a high tech replacement for the PIN, with indeterminate effectiveness. Certainly smartphones have great potential for identity management, but the advantages are to be gained from digital wallets and NFC, not from biometrics.
Some have quipped that the “S” in iPhone 5S stands for “security” but to me it’s more like “speculation”.
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!