This is the fifth of a series of posts discussing the paper
A Comprehensive Approach to Cryptographic and Biometric Authentication
from a Mobile Perspective.
Everybody agrees that passwords provide very poor security for user
authentication, being vulnerable to capture by phishing attacks or
database breaches, or by being reused at malicious sites.
Authentication using public key cryptography does not have any of
these vulnerabilities, and yet, after being available for several
decades, it is only used in limited contexts. As computing shifts
from traditional PCs to mobile devices, everybody agrees that
passwords are terribly inconvenient on touchscreen keyboards, in
addition to being insecure; and yet I don’t see a rush to adopting
cryptographic authentication methods on mobile devices.
What obstacles stand in the way of widespread adoption of
One obstacle is no doubt the complexity of cryptography. Implementing
cryptographic functionality is difficult even when cryptographic
libraries are available. Using a cryptographic API is no trivial
matter, as documented by Martin Georgiev et al. in a recent paper
(reference  in the paper).
Another obstacle is poor support by web browsers for the deployment
and use of cryptographic credentials. In particular, there are no
easy-to-use standards generally supported by browser vendors for
issuing cryptographic credentials to a browser and requesting the
presentation by the browser of particular credentials or credentials
asserting particular attributes.
In Section 7 the paper proposes an architecture for cryptographic
authentication on mobile devices that addresses these two obstacles.
It does that by encapsulating cryptographic authentication of a mobile
device to an application back-end inside a Prover Black Box (PBB)
located in the device and a Verifier Black Box (VBB) located in the
cloud, as shown in figures 6 (page 48) and 7 (page 54).
The PBB may contain one or more protocredentials for multifactor
closed-loop authentication, or credentials for single factor
closed-loop or open-loop authentication; and it takes care of proving
possession of credentials to the VBB. After a cryptographic
authentication event in which the PBB proves possession of one or more
credentials, the VBB creates an authentication object that records the
event and contains authentication data such as the hash of a public
key or attributes asserted by a public key certificate, a U-Prove
token, or an Idemix anonymous credential. The authentication object
is retrievable by a one-time authentication token, which the VBB
passes to the PBB and the PBB passes to the application back-end via a
native front-end or via the web browser. The authentication token
plays the role of a bearer token in a secondary non-cryptographic
authentication of the native front-end or web browser to the back-end,
and allows the application back-end to retrieve the authentication
In Figure 6 the native front-end of a mobile application receives the
authentication token from the PBB and uses it to authenticate to the
back-end of the same application, which presents it to the VBB to
retrieve the authentication data.
In Figure 7, the PBB sends the token via the browser to the back-end
of a web-based application, thus authenticating the browser to the
back-end, which again uses the token to retrieve the authentication
data from the VBB. (As a matter of terminology, we view a web-based
application as having a back-end and a front-end, the back-end being
its cloud portion, while the front-end consists of web pages and
client-side code running in the browser.)
This architecture circumvents the two obstacles identified above to
the adoption of cryptographic authentication.
The browser obstacle is avoided in Figure 6 because no browser is
involved, and in Figure 7 because the browser is not involved in
storing or presenting credentials, and no modification of standard
browser functionality is required.
The obstacle presented by the complexity of cryptography is avoided by
the encapsulation of cryptographic functionality in the PBB and the
VBB and by making the PBB and the VBB accessible through
non-cryptographic APIs in a manner familiar to native and web-based
In Figure 6, arrows (1) and (4) represent messages sent via the
operating system of the mobile device using inter-application
communication mechanisms available in iOS and Android; each message is
a URL having a custom scheme, with message parameters embedded as
usual in the query portion of the URL. Arrow (6) represents an HTTP
POST request, and arrow (7) the corresponding response. Arrow (5) is
internal to the application and can be implemented as part of a
standard web API through which the native front-end accesses its
In Figure 7, arrow (1) represents an HTTP response that redirects the
browser to a custom scheme that targets the PBB, with parameters
included in the query portion of the URL; when the browser receives
the response, it forwards it to the PBB as a message, using the
inter-application communication mechanism provided by the operating
system. Arrow (4) represents a message sent by the PBB using the same
mechanism, with scheme https; the operating system delivers it
to the browser, which forwards it as an HTTP GET request to the
application back-end. Arrow (5) represents an HTTP POST request, and
arrow (6) the corresponding response.
The architecture is very flexible. It covers a wide variety of use
cases, some of which are sketched out in Section 7.1.
A PBB-VBB pair may be used for returning-user authentication to one
particular application. In that case the PBB contains a single
credential (for one-factor authentication) or protocredential (for
Alternatively, a general purpose PBB may be made available to any
mobile application that has a native front-end on the device or is
accessed from the device through a browser, each application having
its own VBB. In that case the PBB may contain any number of
credentials or protocredentials used for closed-loop authentication,
as well as credentials used for open-loop authentication.
An application may ask a general purpose PBB to prove possession of an
uncertified key pair to the application’s VBB for returning-user
authentication, or to the VBB of an identity/attribute provider or a
social network for third-party closed-loop authentication or social
login. The VBB of an identity/attribute provider delivers the user’s
identity or attributes to the application back-end as authentication
data upon presentation of the authentication token. The VBB of a
social network may instead deliver an access token that provides
limited access to the user’s account, thus allowing the application to
obtain the user’s identity and attributes from the user’s profile, to
issue social updates on behalf of the user, and more generally to
provide an alternative user interface to the social network.
An application may also ask a general purpose PBB to demonstrate that
the user has certain attributes by presenting public key certificates,
U-Prove tokens or Idemix anonymous credentials to the application’s
VBB in open-loop authentication.
For enterprise use, a PBB-VBB pair may be shared by a group of
enterprise applications, including web-based applications and
applications with native front-ends, with single sign-on based on
shared login sessions. I will discuss this functionality in the next
A security analysis of the architecture is provided in Section 8.
Among other security considerations, it discusses protection against
leaks through so-called Referer headers, protection against
misuse of an authentication token by its recipient to impersonate the
user, a countermeasure against a form of Login CSRF,
identification of the application that requests presentation of one or
more credentials kept by a general purpose browser, and
countermeasures against a malicious application masquerading as a
different application or as the system browser.