This is the second of a series of posts discussing the paper A Comprehensive Approach to Cryptographic and Biometric Authentication from a Mobile Perspective.
In this post I want to take the time to explain and emphasize the distinction made in the paper between closed-loop authentication and open-loop authentication. This may seem an unimportant matter of vocabulary, but the distinction is essential for two reasons: first, because it helps understand the privacy posture of authentication technologies; second, because it leads to what we think is the best choice of cryptographic authentication technologies for mobile devices.
The concepts of closed-loop and open-loop authentication are defined in the introduction, and examples are given. In open-loop authentication, a party such as a certificate authority or, more generally a credential authority, issues a cryptographic credential to the user’s device, and then is “out of the loop” when the device presents the credential to a relying party. Credentials used in open-loop authentication are typically public key certificates, but could also be U-Prove tokens or Idemix anonymous credentials. In closed-loop authentication, on the other hand, the credential authority is involved in the authentication process, taking care of verifying possession of the credential by the device. In third-party closed-loop authentication, the credential authority is an identity or attribute provider, which communicates user attributes to a relying party after verifying that the device possesses the credential. In two-party authentication, there is only one party besides the user’s device, so two-party authentication can only be closed-loop authentication.
The distinction between closed-loop and open-loop authentication makes it possible to make two observations.
The first observation is that closed-loop authentication can rely on an uncertified key pair, i.e. a key pair that is not bound to any attributes by a certificate. (As a matter of vocabulary, we say that an uncertified key pair is registered by the device with the credential authority, rather than issued by the credential authority to the device, because the credential authority plays no role in generating the key pair; the paper refers to the credential authority as “the party that issues or registers the credential”.) An uncertified key pair can be used because the credential authority can store user attributes in its internal storage and retrieve them at authentication time. Therefore the attributes need not be included in the credential.
The second observation is that, in third-party closed-loop authentication, the credential authority, i.e. the identity or attribute provider, is informed of the authentication transaction and, typically, is told what relying party the user is authenticating to. This impinges on the user’s privacy, especially if the user has no choice of identity or attribute provider and does not trust the provider. This is not just a theoretical consideration. The identity providers most commonly used today have track records of privacy violations, and users are wary of being spied upon.
Some time ago, before being concerned with mobile authentication, we wrote a white paper proposing to eliminate this privacy drawback by using the browser to hide the identity of the relying party. However, this would require substantial modifications of core browser functionality. More recently, in an ICAM blog post, Anil John has proposed hiding the identity of the relying party behind a proxy. But that complicates authentication and serves only to shift the trust issue from the identity provider to the proxy.
Open-loop authentication, on the other hand, does not suffer from this privacy drawback.
These observations led us to the following choice of technologies for cryptographic authentication on mobile devices:
- For the sake of simplicity, an uncertified key pair should be used for two-party authentication.
- For the sake of privacy, open-loop authentication should be used when attributes are asserted by a third party, except in special cases. Credentials used in open-loop authentication could be public key certificates, U-Prove tokens, or Idemix anonymous credentials, depending on the privacy requirements, as explained in section 6.1.
There are two special cases where it makes sense to use third-party closed-loop authentication. One is social login, where an application is granted limited access to the user’s account at a social network such as Facebook or Twitter and authenticates the user as side-effect, by obtaining user attributes from the user’s profile. In social login, the social network is necessarily involved in the authentication transaction. The other is third-party login using as identity provider a personal data repository service that emphasizes privacy and is freely chosen and trusted by the user. A company participating in the Personal Data Ecosystem Consortium (PDEC), for example, could play the role of identity provider.
However, this choice of technologies posed the problem of how to protect the credentials used in open-loop authentication against an adversary who captures the user’s mobile device, because the key pair regeneration method, which I mentioned in the previous post and will discuss in more detail in the next post, does not work for open-loop authentication.
We were happy to find a simple solution to that problem. As described in Section 5, key pair regeneration can be used to implement effective data protection against an adversary who captures the device, by encrypting the data under a data-encryption key, entrusting the key to a key storage service (or splitting it cryptographically across multiple services), and authenticating to the service(s) with a regenerated key pair to retrieve the key. A credential used in open-loop authentication can be protected as data in this way, thus benefiting indirectly from the security provided by the key pair regeneration technique.
In the next post I will finally get into the technical details of the paper.
I wonder if open-loop authentication is really the solution to the non-observability requirement. Revocation can close the loop. May be not completely, but enough for the credential provider to learn about the user’s behavior.
Do you mean that the revocation check can close the loop? When OCSP is used to check for certificate revocation, yes, the credential issuer learns that the credential was used at a particular time, and learns the IP address from which the OCSP request was sent, which may reveal the identity of the relying party. OTOH the issuer learns nothing when the relying party looks up a certificate in a CRL.
CRLs are problematic for use on the web at large, because a relying party has to maintain internally (by issuing CRL update requests) a CRL for every CA that is used by any of its users. But here is an idea: relying parties outsource CRL maintanance to a certificate revocation checking service. The service maintains any number of CRLs, and any number of relying parties subscribe to the service, using OCSP to ask for whether a particular certificate has been revoked, and paying a micro fee for each OCSP transaction. That way the cost of maintaining URLs is amortized over many relying parties.