This is the sixth and last post of a series discussing the paper A Comprehensive Approach to Cryptographic and Biometric Authentication from a Mobile Perspective.
To conclude this series I am going to discuss briefly two methods of single sign-on (SSO) described in the paper, one based on data protection, the other on shared login sessions.
SSO Based on Data Protection
Section 5 of the paper explains how the multifactor closed-loop authentication method described in the third and fourth posts of the series provides an effective mechanism for protecting data stored in a mobile device against an adversary who captures the device. The data is encrypted under a data encryption key that is entrusted to a key storage service. To retrieve the key, the user provides a PIN and/or a biometric that are used to regenerate an uncertified key pair, which is used to authenticate to the storage service.
An adversary who captures the device needs the PIN and/or the biometric sample to regenerate the key pair, and cannot mount an offline attack to guess the PIN or to guess a biometric key derived from the biometric sample; so the adversary cannot authenticate to the key storage service, and cannot retrieve the key. For additional security the data encryption key can be cryptographically split in several portions entrusted to different storages services. Furthermore a protokey can be entrusted to those services instead of the data encryption key, the key being then derived from the protokey and the same non-stored secrets that are used to regenerate the authentication key pair as described in Section 5.4.
This data protection mechanism can be used to protect any kind of data. In particular, it can be used to protect credentials used for open-loop authentication or one-factor closed-loop authentication to any number of mobile applications or, more precisely, to the back-ends of those applications, which may be have browser-based or native front-ends. As discussed in Section 5.5, this amounts to single sign-on to those applications because, after the user enters a PIN and/or provides a biometric sample, the data encryption key retrieved from the storage service(s) can be kept in memory for a certain amount of time, making it possible to authenticate to the applications without further user intervention.
SSO Based On Shared Login Sessions
Whereas SSO based on data protection can be used for any collection of applications, SSO based on shared login sessions, described in Section 7.5, is best suited for authenticating to enterprise applications from a mobile device. A dedicated PBB in the mobile device and a VBB in the enterprise cloud are used to that purpose. The PBB contains a single protocredential shared by all the enterprise applications, which is used to regenerate an uncertified key pair, in conjunction with a PIN and/or a biometric sample supplied by the user. The VBB has access to an enterprise database that contains device and user records and where the VBB stores shared session records, as illustrated in Figure 8.
It is not difficult to share login sessions among a group of web-based applications owned by an enterprise, using a mechanism readily available on the web. Once the user has logged in to one of the web-based applications in the group, that application can set in the browser a session cookie whose scope (defined explicitly or implicitly by the domain and path attributes of the cookie) comprises the applications in the group and no others. The browser will send the cookie along with every HTTP request targeting an application in the scope of the cookie, thus authenticating the request without user intervention.
But we want to share login sessions among a group of enterprise applications comprising applications with native front-ends in addition to web-based applications. To that purpose we use the mobile authentication architecture that I discussed in the previous post, modifying it as follows.
Recall that an authentication event in the architecture consists of a cryptographic authentication of the PBB to the VBB, followed by a secondary non-cryptographic authentication using a one-time authentication token, which plays the role of a bearer token, as illustrated in Figure 6 for the case of an application with a native front-end, and in Figure 7 for the case of a web-based application. The authentication token is only used once because of the risk of a Referer leak in the case of a web-based application. However there is no such risk in the case of an application with a native front-end.
To implement shared login sessions we replace the one-time authentication token with a pair of session tokens, a one-time session token and a reusable session token. After successful cryptographic authentication of the PBB to the VBB, the VBB creates a pair of session tokens and a shared session record containing the two tokens, and sends the two tokens to the PBB, which stores them.
A native front-end obtains a reusable session token from the PBB and uses it repeatedly to authenticate to its back-end until the back-end rejects it because the session referenced by the token has expired because an expiration time in the shared session record has been reached or some other reason. Then the native front-end sends the reusable token to the PBB asking for a replacement. If the PBB has a different reusable token, it sends it to the native front-end. If not, it prompts the user for a PIN and/or a biometric sample, regenerates the uncertified key pair, authenticates cryptographically to the VBB, obtains from the VBB a pair of session tokens pertaining to a new session, and sends the new reusable token to the native front-end.
A web-based application obtains a one-time session token from the PBB and uses it to locate a shared session record and retrieve a reusable session token, which it sets in the browser as the value of a session cookie. After the PBB sends the one-time token to the application, it erases the one-time token from its storage; and after the application uses the one-time token to retrieve the reusable token, it erases the one-time token from the shared session record. The session cookie is used to authenticate HTTP requests sent by the browser to web-based applications in the group, until one of the applications finds that the session referenced by the reusable token contained in the cookie has expired. Then that application sends the reusable token to the PBB and asks for a one-time token. If the PBB has a one-time token paired with a reusable token different from the one sent by the application, it sends the one-time token to the application. Otherwise it authenticates cryptographically to the VBB as in the case of a native front-end, obtaining a pair of fresh tokens and sending the new one-time token to the application.
Pros and Cons of the Two Methods
The method based on data protection is more flexible than the method based on shared sessions. It can be used to implement SSO for any set of applications, whether or not those applications are related to each other. By contrast, the method based on shared sessions can only be used to implement SSO for a group of related applications: the set of web-based applications in the group must be circumscribable by the scope of a cookie; and, as explained in Section 8.2.2, native front-ends of applications in the group must be signed with the same code-signing key pair in Android, or must have the same Team ID in iOS, so that the PBB can refuse requests from applications not in the group.
On the other, the method based on shared login sessions has performance and security advantages, as explained in Section 7.5.3. In the method based on data protection, SSO is accomplished by making cryptographic authentication transparent to the user, whereas in the method based on shared login sessions cryptographic authentication is avoided altogether; hence the performance advantage. In the method based on data protection, the data encryption key must be present in the device while the user interacts with the applications, whereas in the method based on shared login sessions the uncertified key pair is only needed when a new session is created, and can be erased after it is used; hence the security advantage.