This paper focuses on digitally signing documents as a speci c use case for making secure hardware available to a web application. We explore the current options available to implementers and the drawbacks associated with each option. Then we look at the emerging Web Cryptography API developed by the W3C and discover missing functionality needed to implement this use case. Finally, we suggest a way to extend the API in order to support digitally signing documents using secure hardware.
1.1
The European Union recognizes three levels of digital signatures [
The requirement that a key should be kept under the sole control of the owner for quali ed certi cation is interpreted to mean the key should be embedded in a hardware device. This to make sure undetected copying is impossible. In order to create a quali ed signature, a European citizen will therefore always need a smart card or key dongle. A web application creating digital signatures should therefore be able to access the secure hardware of the user. 1.2
The requirement for secure hardware prompted several European countries to issue electronic identity cards to their citizens. Currently countries like Belgium, Germany and many others provide electronic identity cards capable of creating electronic signatures [2{10] and more countries are planning on issuing them.
These cards, many of them issued mandatory, create a large group of users with access to secure hardware and a certi cate ready to create legally binding electronic signatures. Governments have begun using these cards in web applications for the retrieval of o cial documents like birth certi cates (after authentication) or submitting online tax forms (requiring a signature). Many more use cases for government and corporate applications can be thought of, but in this paper we will be focussing on signing documents. 2
Using these identity cards in web applications today is possible, but serious drawbacks exist. 2.1
The rst applications that popped up were using client-side TLS for authentication. The user navigates to a website and is asked to authenticate herself. Most if not all of the identity cards come with middleware that either adds the certi cate to the operating system's key ring allowing it to be accessed by browsers, or installs speci c browser plug-ins registering the certi cate for client-side use.
After the user has authenticated herself, consent with the content to be submitted to the application (like a tax form for example) is typically given by pushing a button. Proof of this consent is then carried by the auditing information logged by the web application. No real electronic signature is created and consent can only be inferred from the audit logs of the web application.
Even this simple scheme can lead to problems when one is not careful. In particular, revocation checks often need to be explicitly enabled at the SSL termination point as it is typically disabled by default. Additionally, client-side authentication su ers from a few other problems like not being able to log out of a session and somewhat bad usability due to it being needed before a connection to the server is established and a web page providing guidance can be shown. While this can be worked around using di erent domains, it would be preferable if the authentication process is initiated by the web page itself to allow for a richer user experience.
In any case, no actual quali ed electronic signature is created, only an audit trail. 2.2
If a quali ed electronic signature needs to be created to sign a PDF document,
or to create an archive containing a XAdES signature for example, the browser
needs to access the smart card. This can be done using a custom plug-in, but a
better option is to use a more widely available general purpose plug-in for this
task. Chances are the user already has this plug-in installed which avoids going
through an additional installation procedure. Using javascript and a Java applet,
data can be shipped to and signed by the secure hardware. Typically, one of two
methods is used. Either the applet probes for a library installed as part of the
card's middleware using JNI, or the smart card is accessed directly using APDU
commands available in standard java runtimes starting from version 6 [
The Java plug-in needs to be installed and the applet needs to be granted additional privileges. This is cumbersome, but until recently it was a reasonable approach. After a series of vulnerabilities in Java however, browsers either disable the plug-in, or only allow it to run when it is the latest version and has been given explicit permission. This degrades the user experience so much that using an applet is no longer a viable option. 3
Mainly driven by mobile applications being implemented as web applications,
more and more functionality, including access to hardware like GPS sensors [
In order to keep the scope of the API limited, the Working group has de ned a very narrow scope for its main document. In order to stay away from concepts that are not portable between operating systems, cryptographic libraries or user agent implementations, provisioning operations or the discovery of cryptographic modules is considered out of scope.
While this might seem like a severe restriction, by supporting key generation functions it still allows for many cryptographic use cases. Indeed, as long as the keys are generated by the api, the provided operations (encrypt, decrypt, sign, verify, digest, deriveKey, importKey and exportKey) allow for a wide array of applications like secure messaging, data integrity protection of cached data and cloud storage.
On the more practical side of designing the API, the working group follows JavaScript best practices and tries to make every call that might take some time, or that might conceivably require user interaction to be asynchronous. This allows for the program ow of the javascript application to continue while waiting for the user the grant permissions, enter a pin number or calculations to be completed. 3.2
The key types and sign operations supported by the API are suited for the use case we have in mind. The issue has been raised whether \broken" cryptography algorithms like SHA1 and PKCS#1 v1.15 should be included, but for the sake of backwards compatibility and integration with server-side software it has been decided they remain. While we hope the world quickly moves on to the more modern alternatives which are supported as well, given the number of deployed smartcards implementing only these older algorithms, excluding them would seriously limit the applicability of the API today. 3.3
Recognizing that not all use cases work with keys generated by the application itself, the group started work on key discovery in a separate working draft [16]. In order to limit the scope and driven by a use case focussing on trusted platform modules (TPMs) and digital rights management (DRM), the speci cation currently limits itself to \discovering named, origin-speci c pre-provisioned cryptographic keys for use with the Web Cryptography API". While this allows for user agents to make keys stored on secure elements like TPMs available to web applications originating from a given domain under a known name, none of those adjectives are a good match for the signing use case.
While it might be possible to assign names to the keys provided by the secure hardware, in all naming schemes we could come up with it would be impossible for the web application to guess what that name might be. Additionally, the keys contained in the secure hardware wouldn't be origin-speci c either. A user shall want to use her smart card to authenticate herself to di erent web applications. Finally, the keys are not pre-provisioned. A way to prompt the user to (re)insert her smart card or USB dongle would be needed.
Key discovery as currently conceived by the WebCrypto Key Discovery draft isn't useful for discovering keys that reside on users' smart cards. 3.4
Instead of name-based key discovery we believe attribute-based discovery of keys based on the key's algorithm or the accompanying certi cate is necessary. By limiting the keys known to the browser by algorithm, issuing certi cate authority, intended usage and other relevant properties, a short list could be presented to the user where she can pick the key needed to complete the action she started.
While this operation closely resembles selecting the appropriate key to use when setting up client-side TLS, it should be noted that this operation can be made asynchronous and can be initiated after a page has been presented to the user. It is conceivable that the user prompt takes the same form as other requests for access to speci c resources like your location or camera. The main di erence might be that this wouldn't have an \Allow" and \Disallow" button, but a \Select..." one popping up a dialog requiring further interaction. 4
Despite its current shortcomings, we believe the Web Cryptography API forms a solid basis. We joined the working group to help shape the API and make the use case outlined in this paper possible. We're currently working on a proposal that will extend the current API to enable the creation of web applications that use secure hardware for the creation of digital signatures. 4.1
We propose a new X509Certificate class, and two new asynchronous methods. A rst one to search for certi cates and related keys, and a second one to enable exporting certi cates to a byte array.
The X509CertificateSelector will take a dictionary containing lters. Filters include things like issuing certi cate authority, usage ags, key algorithm, validity dates and others.
Invoking the X509CertificateSelector will create a subset of all known certi cates known to the browser and initiate a selection procedure by the user agent. This procedure can start with a subtle banner to request access like the location or media capture API's. When clicked, the subset can be presented as a list to the user. Confronted with the list, the user will pick the certi cate appropriate for the action she started and grant the web application access to the associated keys. This grant is origin-speci c. When the keys are used an additional dialog window prompting for a pin code may be shown.
By keeping the user in the loop and requiring her to explicitly allow access to the certi cate and keys stored in the operating system's store, this API can't be used to ngerprint users or glance information from unrelated certi cates stored in the store.
The export functionality is necessary because the certi cate (or certi cates as you probably need the entire chain) used will likely have to be embedded in or associated with the digital signature that is being created. 4.2
We are implementing enough of the WebCrypto API and the proposed extensions as a browser plug-in to validate this proposal [20]. The code is available under an Apache license on github [21].
Note This is an initial proposal and not all issues have been discovered or indeed resolved. We welcome comments, insights and code contributions you may have or want to share. 16. World Wide Web Consortium. WebCrypto Key Discovery. W3C Working Draft 08 January 2013. Retrieved from http://www.w3.org/TR/2013/WD-webcrypto-keydiscovery-20130108/ 17. Cryptographic Token Interface Standard. Version 2.30, Editor Simon McMahon with Robert Gri n of RSA as project coordinator. RSA PSS mechanism parameters.
Retrieved from http://www.cryptsoft.com/pkcs11doc/v230/ 18. Mac Developer Library. kSecInputIsDigest constant de nition. Retrieved from https://developer.apple.com/library/mac/search/?q=kSecInputIsDigest 19. Windows Dev Center. CryptSignHash function documentation. Retrieved from http://msdn.microsoft.com/en-us/library/windows/desktop/aa380280 20. Inventive Designers API proposal, version 79f54d9 Retrieved from https://github.com/InventiveDesigners/webcrypto-key-certi cate-discoveryjs/wiki/API 21. GitHub, Inc. Inventive Designers' webcrypto-key-certi cate-discovery-js repository.
Retrieved from https://github.com/InventiveDesigners/webcrypto-key-certi catediscovery-js