How Fingerprint Sensors Can Help to Improve Mobile and Web App Security

Editor's Note: This is the second part of a two-part series that examines the degree to which built-in biometrics like Apple's Touch ID fingerprint sensor that's present on recent model iPhones improves or worsens device and application security. In the first part of this series (see FBI Apple Debacle Is A Reminder Of How Fingerprint Sensors Actually Worsen Security), ProgrammableWeb.com contributor Hitoshi Kokumai explains how, as implemented on smartphones today, the presence of such fingerprint sensors can easily mislead users into thinking their device security has been improved when in reality, it has not.

Whereas the first part of this series focused on the role that fingerprint sensors play in improving or diminishing device security, this part of the series explores the role that such device-based biometrics can play in securing mobile and Web app interactions with a server.  More simply put, if you have a mobile or browser-based application that "calls home" to a server, can the presence of a biometric device like a fingerprint sensor on a smartphone or tablet help to further secure that app's interactions with the server(s) and APIs it calls?  Or, does the absence of an AND/conjuction approach to unlocking a mobile device (as described in the first part of this series) also mean that AND/conjunction is not available when its time to communicate with a server (as many Web and mobile apps do)?

As it turns out, when a biometric option (ie: a fingerprint reader) is available on the local device (as is the case with Touch ID-equipped iPhones and some of the newer Android-based devices), a form of the AND/conjunction approach is available to developers of Web and mobile apps that require passwordless (biometric only) or two-factor authentication before successful access to a server can be achieved.  

First, and most importantly, developers should realize that they typically do not have any direct access to the fingerprint-based biometric data that's collected by a device's fingerprint reader. That data is stored in an allegedly tamper-proof lock-box (for example, the Secure Enclave in the case of iOS) on the device. In other words, a fingerprint cannot be collected from a smartphone's fingerprint reader and used in any context (ie: sending it to a server that's across a network like the Internet for the purposes of authentication).

However, one option (exemplified by the FIDO Alliance’s UAF/U2F Workflows) is for developers is to use the smartphone's biometric facilities to create a public/private key pair that serves as the foundation for a second factor of authentication to server-dependent applications. The APIs in iOS and Android make it possible to generate a public/private pair for a specific entity like an app or a Web service. The private key is stored and protected in the so-called lockbox and the corresponding public key would be enrolled with server as shown in this workflow (an Android example).

Take a social networking service for example. A user of that service could elect to secure their account via AND/conjunction; that is with both biometrics and a pin (or password) so long as the social network supported that form of security as an authentication option. In other words, a mobile application that interacts with that social network would require both a fingerprint and a password before the app could engage with the service. Or, using the same approach without a password/pin involved (thereby only involving one biometric factor of authentication), a local fingerprint sensor could be leveraged to design a passwordless means of authentication. 

A blog over on WillowTreeApps.com does a pretty good job of capturing the process when iOS is involved:

"The final method for utilizing the Secure Enclave is the storage of private keys. In asymmetric cryptography, a public and private key are generated and used to sign data. One API call, SecKeyGeneratePair(), creates a public and private key. The public key is returned to the app, and the private key is sent directly to the Secure Enclave. This private key cannot be retrieved. When data must be signed, the data is passed to the Secure Enclave. If the app has so requested, the system will then ask for Touch ID verification. If successful, the Secure Enclave will sign the data and return the signature. The private key is never returned to the app. The app can then use the signed data and the public key, for example, to verify that the correct device is attempting to access a Web service."

All this said, rolling your own biometrically-driven security workflow requires significant expertise. Although we're sure examples of such applications exist, we at ProgammableWeb have yet to witness one in action. The complexity has made room in the market for third party tool providers like SecSign Technologies that offer turnkey solutions that simplify implementation of biometrically-driven workflows. 

So, why is such an AND/conjunction approach available for applications that involve a server and not for the device itself? In the case of the device, if one of the two required factors fails (which it most certainly would for many users for a variety of reasons) after a user accepted the option to secure his or her device with both fingerprint and password/pin, that user will be permanently locked-out of the device. As evidenced by the Apple/FBI-case, s/he cannot call Apple or go to a Genius Bar to temporarily downgrade the security of the device to require one factor or no factors. There is no one to appeal to.

In contrast, allowing the AND/conjunction-based two-factor approach to securing Web and mobile apps that involve a server is less risky because the service operator has control over the server and could offer end-users a means for temporarily downgrading their accounts' security settings. The service would of course have to go to great lengths to ensure the authenticity of such a request (many financial institutions have such a rigorous process in place today).

So, whereas the biometrically-supported AND/conjunction approach is impractical for securing the device itself, it has very promising potential for securing mobile and Web applications with two tandem factors of authentication, thereby improving security over the password/pin-only authentication that’s commonly deployed today.

All this said, where AND/conjunction-based two-factor authentication is put into place for server-driven applications as described above, care must be taken in order for developers to avoid the introduction of OR/disjunction into the authentication workflow. In other words, if at any time that workflow allows for authentication using either the fingerprint or a password/pincode, the overall security will have been diminished over a password/pin-only approach much the same way that allowing either for unlocking a device further hinders the device’s security over a password/pin-only approach.

David Berlind is the editor-in-chief of ProgrammableWeb.com. You can reach him at david.berlind@programmableweb.com. Connect to David on Twitter at @dberlind or on LinkedIn, put him in a Google+ circle, or friend him on Facebook.

Comments