This blog post is a companion to a presentation made at the 2017 International Cryptographic Module Conference and refers to the presentation slides, revised after the conference. Karen Lewison is a co-author of the presentation and of this blog post.
Slide 2: Key storage in web clients
Most Web applications today use TLS, thus relying on cryptography to provide a secure channel between client and server, and to authenticate the server to the client by means of a cryptographic credential, consisting of a TLS server certificate and its associated private key. But other uses of cryptography by Web applications are still rare. Client authentication still relies primarily on traditional username-and-password, one-time passwords, proof of possession of a mobile phone, biometrics, or combinations of two or more of such authentication factors. Web payments still rely on a credit card number being considered a secret. Encrypted messaging is on the rise, but is not Web-based.
A major obstacle to broader use of cryptography by Web applications is the problem of where to store cryptographic keys on the client side. Smartcards provide strong security for the storage of cryptographic keys, but most Web app developers cannot ask their users to use smartcards and card readers. Windows machines have Trusted Platform Modules (TPM), which can be used to implement “virtual smart cards”, obviating the need for physical smart cards and readers; but most developers cannot require their users to use Windows machines. A few years ago Microsoft introduced Windows CardSpace, which allowed users to authenticate with “InfoCards” containing various kinds of credentials, including traditional certified key pairs consisting of a public key certificate and its associated private key, and U-Prove tokens that provided selective disclosure of attributes and issue-show unlinkability; but CardSpace was soon discontinued, due to lack of acceptance, which was not surprising since it was Windows-specific. It used to be possible to store cryptographic keys in ordinary files, accessed by Java applets, but Java applets are now being deprecated by Web browsers.
TLS supports client authentication in addition to server authentication, but TLS client authentication is only suitable for specific use cases. Using client authentication requires creating a TLS client certificate and importing it into the browser. This can be done manually or automatically. Doing it manually involves creating a certificate-signing request using, e.g., OpenSSL, submitting it to a certificate authority, retrieving the resulting certificate, and using a browser user interface to import it. Web app developers cannot ask non-technical users to do this. Doing it automatically requires a computing environment set up by professional IT personnel, such as Active Directory and/or Mobile Device Management, and is therefore only feasible within an enterprise or other large organization.
Several attempts have been made to make it easier for web applications to store cryptographic keys on the client side.
HTML5 introduced the <keygen> HTML tag, which was intended to allow a Web server to issue a TLS client certificate that would be automatically imported into the browser. But it was not supported by Internet Explorer, which at the time was still the dominant browser, and it has recently been deprecated.
The recent FIDO specifications allow a browser to authenticate to the back-end of a Web application using a key pair generated and stored by an “authenticator” accessible to the browser. The authenticator could be a hardware device or component such as a USB dongle, a TPM, a secure element or a TEE, or could be implemented in software. The authenticator attests to the application back-end that it belongs to a particular class of devices by signing the authentication public key with an attestation private key, all devices in the class carrying the same attestation private key.
In FIDO UAF, where UAF stands for “Universal Authentication Framework”, the user activates the authenticator by authenticating to it with a biometric sample or a PIN. In FIDO U2F, where U2F stands for “Universal Second Factor”, the authenticator should be a separate hardware device whose possession serves as a second authentication factor. The authenticator device may communicate with the user’s primary computing device via USB or NFC. The user activates the authenticator device by pressing a button on the device, or, if an NFC device, by tapping it against the primary computing device. This does not count as an authentication factor; the other authentication factor is instead an ordinary username and password. The W3C has adopted FIDO U2F as the foundation for the Web Authentication API.
FIDO requires browser plugins, but new web technologies have appeared over the last few years that enable new key storage solutions without plugins. This post and the companion presentation focus on the storage of keys used in cryptographic credentials, but the techniques discussed below can also be adapted for other purposes, briefly mentioned below in connection with Slide 27.
Slide 3: New Web technologies
Slide 4: The Web Authentication API
The Web Authentication API is based on the FIDO U2F specification described above, whose adoption by the W3C may eliminate the need for browser plugins. It is scheduled to become available without plugins on Chrome, Firefox and Edge later this year.
The Web Authentication API provides a new solution to the problem faced by web applications of how to store client-side cryptographic credentials. The authentication key pair is stored in the authenticator, which is accessible to the browser. Since the authenticator should be a separate hardware device, this does not seem very different from storing credentials in a smart card. But the same authenticator may be shared by any number of web applications, and provisioning is automated. On the other hand the authenticator can only store uncertified key pairs, and the Web Authentication API can only be used to authenticate repeat visits of a user who has previously registered with the application. It cannot be used for identity proofing or for claiming attributes certified by an authoritative third party. Therefore it does not provide a general purpose key-storage solution.
The other four web technologies are not specifically intended for the storage of cryptographic keys, but they can be combined in several ways to obtain general purpose key-storage solutions. They are reviewed in chronological order in slides 5-8.
Slide 5: The Web Storage API
Slide 6: The IndexedDB API
Slide 7: The Web Cryptography API
The Web Cryptography API has been supported by most browsers since 2014. It is available in all browsers today, but Internet Explorer only supports an old version of the specification, and Safari requires API references to be prefixed with webkit. It provides a random bit generator, and a number of cryptographic primitives invoked via a complex asynchronous interface. The cryptographic primitives include two RSA signature schemes, RSASSA-PSS and RSASSA-PKCS1-v1_5 (described in RFC 3447), and ECDSA with NIST curves P-256, P-384 and P-512 (described, e.g., in the ECDSA Certicom white paper). Other primitives include ECDH, AES (including AES-GCM), HMAC, SHA (including SHA-1, SHA-256, SHA-384 and SHA-512), HKDF and PBKDF2. Surprisingly, DSA is not included.
Slide 8: The Service Worker API
The Service Worker API is a crucial web technology that allows the front-end of a web app to work “offline”, without communicating with the back-end. Besides its usage in connection with key storage, it has the potential to allow apps to become fully competitive with native apps, without requiring app installation. It is available in Chrome, Firefox and Opera, under development in Edge, and under consideration for Safari.
Slide 9: Two combinations of web technologies
The table in Slide 9 has entries to be filled in with four solutions for storing cryptographic keys, or more specifically cryptographic credentials, in persistent browser storage. The entries are filled in in Slide 19 after describing the first solution in Slides 10-18.
The two columns of the table refer to two possible combinations of the new web technologies.
The first column refers to the combination of localStorage for storing a credential with the Service Worker API for presenting the credential as described below. This combination supports the storage and presentation of any kind of cryptographic credential, including traditional certified key pairs, but also anonymous credentials such as Idemix (now available on Github from IBM) or rich credentials.
The meaning of the two rows is described below in connection with Slide 19, after Solution 1 is described in Slides 10-18.
Slides 10-13: issuance of a cryptographic credential in Solution 1
Slides 10-13 are an animation that illustrates the issuance of a cryptographic credential and its storage in localStorage in Solution 1.
Slides 14-18: presentation of a cryptographic credential in Solution 1
Slides 14-18 are an animation that illustrates the presentation of a cryptographic credential in Solution 1.
In Slide 14 the user visits a web site that requires presentation of the credential in order for the user to identify him/herself or demonstrate possession or one or more attributes certified by the credential. (If the credential supports selective disclosure, as anonymous credentials and rich credentials do, the user may only need to disclose the attributes required by the verifier rather than disclosing all the attributes included in the credential.) This web site is called here the credential verifier, and could also be referred to as the relying party.
In Slide 15 the user clicks a button on a verifier web page, thus sending an HTTP request that the verifier redirects to the credential issuer, exactly as in a federated login protocol such as a login with Facebook or Twitter. However, whereas in federated login the identity provider has to be online and involved in each login (a tough availability and performance requirement) and therefore observes each login (a serious privacy drawback), here the redirected request is intercepted by the service worker and never seen by the back-end of the issuer. If the credential supports selective disclosure, the redirected request also specifies the attributes required by the verifier.
In Slide 16 the service worker generates a web page on the fly that asks the user for consent to present the credential. If the credential supports selective disclosure, the consent request page also asks the user for permission to disclose the required attributes to the verifier.
In the simple case of a certified key pair, the presentation protocol consists of sending the certificate and proving knowledge of the associated private key.
In the case of a credential that supports selective disclosure, only those attributes required by the verifier are disclosed.
In the case of an anonymous credential, such as Idemix, that provides multishow and issue-show unlinkability in addition to selective disclosure, multiple presentations cannot be linked to each other or to issuance.
A rich credential, besides supporting selective disclosure, also supports presentation of multiple verification factors, including proof of knowledge of a password and proof of possession of one or more biometric traits in addition to proof of knowledge of a private key. Furthermore, it supports selective presentation of those factors. Therefore, if the credential is a rich credential: (i) the presentation protocol may include submission of a biometric sample, with presentation attack detection by the verifier; (ii) in the redirected request the verifier may specify the factors to be presented in addition to specifying the attributes to be disclosed; and (iii) the consent request page may ask the user for permission to present the required factors in addition to requesting permission to disclose the required attributes.
Slide 19: Three other solutions
Slides 20-26: comparative security postures
Slides 20-26 show a table that compares the security postures of the four solutions of Slide 19 to other methods of storing a cryptographic credential. The slides refer to the user as the “subject” because the table is concerned with a credential issued to the user. The rows in the table refer to storage methods while the columns refer to attacks. As explained in the overlay of Slide 20 that goes away in Slide 21, each entry in the table is labeled “Capture” if the corresponding attack succeeds in capturing the credential, or “Use” if the attack succeeds in using the credential on the subject’s computing device but cannot extract it for use on another device, or “Secure” if the attack does not succeed in capturing or using the credential.
The first two rows of the table refer to Solutions 1 and 2. The third row refers to Solutions 3 and 4, which rely on a trusted consent manager; no distinction is made between those two solutions because the trusted consent manager is assumed to be honest and secure. The next three rows are concerned with storing the credential in a smart card. In the fourth row, the credential is provided to the subject by the credential issuer with a preloaded credential. In the fifth row, the credential is generated in the smartcard after the smartcard has been provided to the subject by the issuer; e.g., if the credential is a certified key pair, the key pair is generated on the card, then the public key is certified by the issuer and the resulting certificate is imported into the card. In the sixth row the credential is generated on a card that the subject obtains from a trusted card manufacturer, so that credential generation is performed by trusted firmware. In the last two rows the credential is stored in secure hardware embedded within the subject’s device, either tamper-proof hardware such as a secure element or a TPM, or a Trusted Execution Environment that provides protection against malware but not necessarily against physical tampering.
Slides 22-26 highlight a few observations that can be made by examining the entries in the table.
Slide 23 highlights the fact that the four solutions of Slide 19 are not secure against malware on the subject’s device or physical capture of the device.
Slide 25 highlights the fact localStorage may be more
secure than smartcard storage under certain assumptions.
Specifically, if it can be assumed that the subject’s device is free
of malware and is not captured by the adversary, then Solution 3,
where a trusted consent manager, assumed to be honest and secure,
stores the credential in
Finally, Slide 26 highlights the fact that secure hardware embedded in the subject’s device, either tamper-proof hardware or a TEE, provide good security. Unfortunately, such credential storage solutions cannot be used today by developers of Web applications. We heard at the conference, however, that GlobalPlatform may be working on making credential storage in a TEE available to Web applications.
Slide 27: Potential applications
Most of the talk has focused on the storage of cryptographic credentials, which can be used for remote identity proofing, recurring authentication, or privilege escalation. But persistent browser storage can also be used for storing cryptographic keys used for other purposes.
One possible application is end-to-end encrypted Web mail. Secure messaging is becoming popular, but at this time it requires either a native email client that supports S/MIME, or a native app that implements ad-hoc encrypted messaging. Web mail is a Web application. Messages are stored in a server, but are composed and read in the browser. End-to-end encryption would require the messages to be encrypted in the sender’s browser, and decrypted in the recipient’s browser using the recipient’s private key. The above solutions could be adapted to store the private key used to decrypt messages in the recipient’s browser together with the associated certificate, as well as the private key used for signing messages in the sender’s browser with its associated certificate.
Another possible application would be cryptographically secured online payments.