While initially very excited about the potential involved in the iPhone5S fingerprint reader (I’m particularly hopeful for increased locking of handsets) I’ve grown sour on the expansion of the fingerprint beyond the initial lock screen, and perhaps some specific Apple usage.


Because while Apple is incredibly careful to say no-one can access your fingerprint, articles such as this by Wired means that if the API is opened up, you will lose the ability to maintain that certain actions taken on the phone were not taken by you. While this doesn’t worry me too much personally, the real issue for me, is a little deeper.

If the API is open, what is the restriction on applications, while not actually getting access to the fingerprint, gaining access to the knowledge of the fingerprint ID, and collecting additional information, matching that ID on the phone to the fingerprint activity?  In fact, this is natural and would be absolutely required for the apps to do personalisation.  However, if this ID is common between apps, and the OS itself, the usage of this fingerprint with SSO would allow people to profile that individual user to a fingerprint.

What’s the difference with SSO you ask?  Rejection.  Or the ability to physically map these items to someone else under duress.  Later, when people map their fingerprints to passwords, their internet banking etc. the incidence of robbing resulting in the attacker taking your entire fortune away will increase significantly.

So two main issues, the profiling with very strong physical user mapping, and users with SSO over-using the convenience factor are what worries me if they open the API.

Two main solutions:

  1. If the API is opened, apps should never be able to map an ID to a user.  This means the fingerprint sensor (and SSO API) should profile per-app IDs completely random.  The side-channel aspects of this will be hard to contain, such as apps performing per-ID mapping based on real-time usage reported to a server.  But completely random ID’s should make this essentially the same issue as now.
  2. Rejecting App usage of fingerprint should be an OS level function, also resetting the ID used by a particular fingerprint.
  3. Requiring apps to use fingerprint + password, for things like banking apps, should be an API-supported function.  As should things like a duress password.

Managing all of this in a typically Apple “simple, magic” way with all of a sudden the worlds most popular fingerprint reader is going to be a monumental task.  And one that will take a great deal of care.

Kudos to Apple for not taking this as an early launch feature and harming peoples security.  One of the only issues I have is that it is likely some in the Android camp won’t take a measured view on this, and might mess up the party for everyone…