Apple’s Touch ID recognises fingerprints and tells you whether the fingerprint on the sensor has been registered. Every fingerprint authorised on a device is equivalent; this is an important design constraint to remember for anyone designing a security mechanism that depends on Touch ID. This is not a flaw, because it is behaving as designed; however, it limits the utility of the biometric for certain authentication applications.
When you present a finger and tell the iPhone to Add a Fingerprint, you are enrolling that fingerprint in Touch ID. In any other context where fingerprints are used, you typically find significant controls around whose fingerprint is being presented. In contexts such as immigration, cashing bank cheques, and law enforcement there are people who check the identity of the human before they enrol their fingerprint. They might check a driver’s license, passport, or other ID before they accept the finger and indicate that the finger belongs to that specific human.
Apple devices have a casual enrolment process — if you know a device’s passcode, you can enrol one or more fingerprints. There is no binding between the human presenting a finger and the digital identity the device represents. This might be okay when authorising the unlocking of a phone, but it becomes problematic when it might authorise payments or other highly sensitive actions.
Weak enrolment limits the assurances you can make about Touch ID and the user’s identity.
What this means for end users
Perhaps you want to allow a partner or a family member to be able to unlock your phone without knowing your phone’s passcode — enrolling their fingerprint might seem like a useful compromise. If you authorise a fingerprint, you allow that person to approve anything that your fingerprint could authorise.
This problem was fairly obvious with passwords. If I know your banking password, I can log in to your bank account. In our minds we have separate use cases like “unlock my phone” and “use my credit card to buy things at the store.” But these use cases are not separated on Touch ID, yet. All fingerprints are equal and can authorise everything.
Likewise, your passcode for your phone is the root of trust. If someone knows your passcode, they can enrol a fingerprint on your phone. Will you notice? Maybe. If you change your passcode to something they don’t know, their fingerprint remains authorised.
What this means for software developers
If you’re building an app that uses Touch ID to authorise an action, remember that you don’t know how many people are enrolled in Touch ID on a device or who they are. The authorised user might or might not be the owner of the phone and the iTunes accountholder. It is not a valid security assumption that only one person (or any person in particular) is enrolled on the device. A bank cannot, for example, assume that only legal accountholders are authorised on the device. As an app developer, the only assurance Touch ID gives is that one of the authorised fingerprints was presented when it was asked for.
Touch ID stores some digital representations of fingerprints in the secure element. An iOS app author can say, “Hey iOS, make the user provide a valid fingerprint.” The app’s creator can receive one of two responses: “a valid fingerprint was provided” or “no valid fingerprint was provided.” An app’s writer cannot, for example, identify which authorised fingerprint was provided. Thus, even if an app developer wanted to let users limit authorisation to only some of their authorised fingerprints, iOS doesn’t offer that option at the present time.
Touch ID is operating as designed, and we have to remember these constraints when designing our apps. We also have to make sure that its execution supports what we’re trying to do.
It is easy to think about fingerprints as being very personal and belonging to a single individual. But when designing mobile apps, we don’t currently know anything about whose fingerprint was used, so we have to be very careful what trust we assume based on it.
Note: TechRepublic, ZDNet, and CNET are CBS Interactive properties.