Touch ID in iOS 8: Explained

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

Rene Ritchie

Editor-in-Chief of iMore, co-host of Iterate, Debug, Review, Vector, and MacBreak Weekly podcasts. Cook, grappler, photon wrangler. Follow him on Twitter and Google+.

More Posts

 

11
loading...
34
loading...
79
loading...
0
loading...

← Previously

T-Mobile to cut prices on iPhones by up to $50 starting Wednesday

Next up →

How to tweak the Mac's display settings for better visual accessibility

Reader comments

Touch ID in iOS 8: Explained

14 Comments

I think the number one thing I am looking forward to in the new iPhone (I have the iPhone 5 now) and iOS 8 is using Touch ID with 1 Password. If the folks at 1PW can tie my database directly into the Touch ID, I will be a very happy camper.

+1 I can't wait to see what the good folks at 1Password have in store for us. The correct implementation will make this app even more convenient to use than it already is.

I love how all of iOS 8's features are so well thought out from top to bottom. It echoes their "if everyone is busy making everything, how can anyone perfect anything?" mantra.

Sent from the iMore App

Hell Yea, this is the Mobile Platform 2b on.
Security first, then add Features that Make the Platform more Powerful & Useful.
No wonder Apple is the Most Trusted and Profitable Tech Company & will be for a Long time to Come because they care More about the Consumers Privacy than any other.
(Hear that Google & Samscum), All ur Thievery won't Matter without the People's Trust.

(R.I.P Steve Jobs) !!

Rene,
Keychain only works in Safari at this point in time. For Apps to start using Keychain to store credentials would there be another API suite in combo with touch ID? Is the ability for apps to use Keychain also a nee feature in iOS 8?
-AB

Sent from the iMore App

I'm not a developer, so I may be missing something, but I believe so, yes. Developers can access KeyChain or LocalAuthentication, and request passcode or TouchID/passcode. (Devs please correct me if I'm wrong here.)

Ok its clear Apple has their grip on security but what about privacy when it comes to NSA requesting users' information such as fingerprints?

Sent from the iMore App

Apple doesn't have access to the fingerprints so they can't give them up.

  1. After scanning, the fingerprint is turned into math, and the scan destroyed, so there's no source info left.
  2. The math is store only on the secure enclave, so there's no way to get it off or out, not even for Apple. (That's why, for example, fingerprints can't sync between devices)
  3. Any attempt to remove or alter the hardware destroys the original pairing key, rendering the data inaccessible to anything.

It seems like Apple has designed it smartly from the get go.

I like touch id a lot but i find more often than not i have to enter my password when buying iTunes content, which defeats the purpose.

Did some more research thanks to this WWDC session:
http://devstreaming.apple.com/videos/wwdc/2014/711xx6j5wzufu78/711/711_h... (cue to the 40 min mark for a brief demo)
Turns out iOS 8 allows for Apps to use TouchID either through Keychain or though LocalAuthentication. These are completely distinct methods. The Keychain option will allow you to type in a passcode in case of a failed TouchID sense attempt and retrieve a secret stored in Keychain for a given app. For this to work, a 3rd party app would have to implement Keychain API's to store authentication info. Whereas LocalAuthentication which does not go through Keychain will default to the local App's password authentication method if TouchID authentication fails. This method does not require an app to store authentication info in Keychain and instead simply gets a 'Yes/No' answer back from a TouchID API call. This maybe seen as an easier to implement option by 3rd party apps with minimal changes to their existing authentication interface.

Sent from the iMore App