Touch ID in iOS 8: Explained

August 28, 2014

Touch ID is the name of Apple's personal fingerprint identity sensor. It's what currently lets you authenticate yourself to unlock your iPhone 5s and authorize iTunes and App Store purchases on your account. With iOS 8, Apple is making an application programming interface (API) available to developers as well so everything from your password manager to banking service to private photo vault can be both secure and convenient. But how's it going to work?

Token problems, KeyChain solutions

When you put your finger on a Touch ID-equipped Home button, the metal ring around it detects the capacitance and wakes up the sensor. A high resolution photo of your fingerprint is then taken, converted into a mathematical representation, and sent over a hard-wired connection to the secure enclave of the Apple A7 system-on-a-chip. If the data doesn't match, a "no" token is released and you need to try again, or enter a passcode or password. If the data does match, a "yes" token is released, you're iPhone 5s unlock is authorized, or your iTunes or App Store purchase gets authorized.

All of this launched back in 2013 as part iOS 7 on the iPhone 5s. What didn't launch with it at the time was a Touch ID API for developers. It's my understanding that, while Touch ID was secure against anything except physical spoofing when constrained to those two specific tasks, Apple hadn't had time to build out that security yet for developers. For example, what was to stop a malicious app from spoofing a Touch ID "yes" token?

Fast forward to 2014 and iOS 8 provides that security rather ingeniously — it hooks into Keychain and into a new framework called LocalAuthentication.

KeyChain is Apple's secure database for passwords. It started on the Mac but moved to iOS and then the iOS version moved back for iCloud KeyChain in iOS 7 and OS X Mavericks.

In iOS 8, it's KeyChain that receives the "yes" or "no" token from the secure enclave following a successful Touch ID authentication, and KeyChain that provides or withholds credentials to apps accordingly.

That means Touch ID, and your fingerprint data, can stay safely locked within the secure enclave, but it can still be used in place of a username/password combo to more conveniently fill in passwords and otherwise authorize any app on the App Store.

LocalAuthentication on the other hand provides a faster but more limited form of access. For example, with LocalAuthentication, Touch ID can be used to unlock certain features (imagine a secure photos app or a video player with parental controls).

Also, thankfully, while Touch ID can be used for fast and easy single-factor authenticate, it can also be used as a second factor to increase security. (i.e. Touch ID instead of passcode vs. Touch ID in addition to passcode.)

Touch ID for developers

With iOS 8, Apple is introducing item Access Control Lists (ACL) for accessibility and authentication. With those, developers can set when a KeyChain item is available, but also what happens when the item is accessed.

Accessibility is the same for Touch ID as it is for passcode — based on device state like "unlocked". Authentication is new and requires a policy to determine what conditions need to be satisfied for KeyChain provides information to the app.

User presence policies can include no passcode, in which case there's no access to KeyChain, passcode, in which case KeyChain will unlock once it's entered, and Touch ID, in which case KeyChain will unlock once it authenticates. (If Touch ID fails, or the person opts-out of using it, it can revert to passcode.)

Touch ID is given preference over passcode when available because a finger press is faster and easier than entering a string of numbers or alphanumeric characters.

Policies and enforced by the secure enclave of the Apple A7 processor, so they're protected against anything up to and including kernel compromise.

Because of that, developers and their apps also get the same fail-secure system as device unlock and store purchases — if Touch ID doesn't authenticate after four tries, if the device is rebooted, or if Touch ID isn't used in 48 hours, the secure enclave will disable it and the passcode will need to be re-entred to re-enable it.

To go along with the new API, Apple is also providing a new interface to handle Touch ID transactions in App Store apps. Similar to the look and feel of the existing iTunes and App Store Touch ID interface, it pops up and gives you the option of scanning a fingerprint or entering the passcode.

Apple presents the name of the app in the interface dialog, so you always know who's asking for your authentication. Developers can also — and are encouraged to — add an additional text string explaining why they're asking for authentication.

(If Touch ID is disabled, if it's been opted-out of, or if the device being used doesn't have Touch ID, the same framework will present a passcode entry interface instead.)

Obviously, since it has to present the interface, only an app in the foreground can request authorization. Apple cautions developers to remember, however, that any query could return secure items that require authentication. So, developers are encouraged not to query too broadly, and Apple is also providing a "no authentication mode" so that developers can suppress the interface and simply report back that, if those items are really wanted, authentication will be required.

Touch ID and action extensions

In addition to apps, Touch ID can also be integrated into action extensions. So, for example, a password manager app could use Touch ID to authenticate you before showing you your passwords inside its own app. A password manager action extension, however, could be called from within Safari and allow Touch ID to authenticate you so the extension can auto-fill your password fields.

If developers make their own frameworks, other developers can also integrate it into their own apps so, for example, a social network app could let you use the password managers extension to authenticate and auto-fill your passwords right inside the social networking app.

Touch ID API security

The Touch ID interface is owned and controlled by iOS, not by the App Store app that controls it. Only upon successful determination of authentication status, opt-out to password, or canceling out altogether can an app regain control.

Also, for security reasons, Apple and iCloud do not back up ACL protected items, and don't sync them between devices. In other words, your data is never put up on the internet or onto anyone's servers, including Apple's. Not ever.

Developers also never gain access to your fingerprint data in their apps. It all stays tucked away safely in the secure enclave.

Bottom line

Entering passwords on mobile devices, especially the kind of unique, long, strong pseudorandom passwords we're supposed to be using, is so onerous many of us simply stop using them at all. Touch ID helps by making a biometric authentication system available that's both easier and faster to use. However, it was only available on the iPhone 5s, and only for device unlock or iTunes purchase.

The Touch ID API removes the latter part of the limitation. With it, Touch ID authentication can be made available in any App Store app. As to the former part, it's hard not to imagine Apple won't fix that later this fall, and bring Touch ID to the iPhone 6 and iPad lineups both.

That should happen within days and weeks, respectively, of iOS 8 being released this fall. Are you looking forward to it, and which of your apps would you like to see implement the Touch ID API?

More of iOS 8: Explained

Sign In

Touch ID in iOS 8: Explained

Recommended Posts

Guest Rene Ritchie

Join the conversation

Browse

Activity

Store

Support