W3C's suggestion for a Web Cryptography API

The World Wide Web Consortium or W3C as it is commonly known was founded in 1994 by the original architect of the World Wide Web, Tim Berners-Lee. It is a consortium of international companies that are involved with the Web and the Internet.

In one of the W3C’s latest proposed recommendations is the group’s suggestion for a Web Cryptography API. This would be a JavaScript API that would perform basic cryptographic operations in web applications, including:

• Hashing
• Signature generation and verification

• Encryption and decryption

The specifications also describe an API that could be used by applications to create and/or manage the keys that would be necessary to perform the above operations. It is proposed that there could be a broad range of uses for this API, ranging from:

• Authenticating users or services
• Signing documents or code
• Preserving the confidentiality and integrity of communications

The Web Cryptography API

The Web Cryptography API that the W3C proposes would define a low-level interface that would interact with cryptographic key material. This would be managed by a user agent. Regardless of what platform this agnostic API would be used on, it would be capable of providing a common set of interfaces that would allow rich web applications to perform cryptographic functions without having to require access to the raw keying material.

The cryptographic transformations would be exposed by the SubtleCrypto interface. This interface defines a group of methods for performing commonly used cryptographic operations. Along with common operations such as hashing and verification, signature generation and verification, and encryption and decryption, the API also would provide interfaces for:

• Key generation
• Key derivation
• Key import and export

How the Web Cryptography API Could Be Used

There are numerous applications that the Web Cryptography API would be suited.

Multi-factor authentication

Many web applications rely on multi-factor authentication to verify the identity of a user. Instead of having to use transport-layer authentication to authenticate a user’s access to secret keying material, the web application can be capable of providing authentication within itself. This in turn would provide a richer user experience.

With the Web Cryptography API, the application would locate suitable client keys that were previously created by the user agent (software that acts on the behalf of the user) or pre-provisioned by the web application. If the user does not have a key already associated with their account, the application would be able to give the user agent the option of generating a new key or re-use an existing key. This multi-factor authentication process could be strengthened by binding it to the TLS session from which the user is authenticating through deriving a key based on the underlying transport.

Protected document exchange

The Web Cryptography API can be used to limit the viewing of sensitive or confidential documents from within a web application, even if they have been securely received. The web application would use the API to encrypt the documents with a secret key that would be wrapped with public keys that are associated with those who are authorized to view the documents. When a user navigates to the web application, they would receive the encrypted document and be instructed to use their private key to unwrap the encryption key. They would then be able to decrypt and read the document.

Cloud storage

There are instances where a web application may want to allow users the ability to protect the confidentiality of their documents or data that is stored with a remote service provider, before uploading to their service. With the Web Cryptography API, the user would:

• Select a secret or private key
• Derive an encryption key from that key if they choose
• Encrypt the document
• Upload the encrypted data using existing APIs to the service provider

Document signing

Instead of requiring a written signature, many web applications choose to accept electronic signatures for documents. With the Web Cryptography API, the user would be directed to choose a key, which can be generated specifically for the application or be pre-provisioned. The application could then perform a signing operation using that key to prove that the user has accepted the document.

Protecting data integrity

Often a web application may cache data locally, but wants to ensure that this data will not be compromised if an offline attack occurs. The Web Cryptography API allows the application to use a public key from within itself to verify the contents of the data cache. This allows the client to ensure that the data in the cache has not been compromised.

Secure messaging

The Web Cryptography API can be used for off-the-record (OTR) and other message signing schemes by performing key agreement. The sender and receiver would negotiate shared encryption keys and message authentication code (MAC) keys. This would allow messages to be encrypted and decrypted to prevent tampering.

JavaScript Object Signing and Encryption (JOSE)

The Web Cryptography API allows a web application to interact with message formats and structures that are defined by the IETF JavaScript Object Signing and Encryption (JOSE) Working Group. The application can:

• Read and import JWK keys
• Validate messages protected by digital signatures or MACs
• Decrypt JWE messages

   

Conformance to the Web Cryptography API

It is recommended that vendor-specific proprietary extensions not be used with Web Cryptography API specifications. This reduces the API’s interoperability and breaks up the user base because only users of the specific user agents would be able to access that particular content. When a vendor-specific extension cannot be avoided, they should be prefixed by vendor-specific strings. This will help avoid clashes with future versions of the API’s specifications.

Scope of the Web Cryptography API

W3C’s specification for the Web Cryptography API focuses on the common functionality and features that exist between various platform-specific and standardized cryptographic APIs, instead of those where functionality and features are known only to a few implementations. With this API, developers do not need to care about implementing underlying key storage as it allows a level of abstraction for generating keys, management and exchange.

This scope; however, does not dictate a mandatory set of algorithms that need to be implemented. This is because the underlying cryptographic implementations will vary between the conforming user agents based on local policy, government regulations, security practices or concerns regarding intellectual property. The API does not specifically address particular types of key store when provisioning keys.

Concepts Associated with the Web Cryptographic API

It is assumed that user agents will not be directly implementing the API on the user agent itself. The CryptoKey object bridges the JavaScript environment to the underlying libraries that are a part of the operating system of the user agent. The specification also does not provide mechanisms for storing CryptoKey objects. Instead, the API allows CryptoKey to be used with the structured clone algorithm for storage.

Security Considerations when Implementing the Web Cryptography API

Because of the issue of not providing an explicit storage mechanism, it is assumed that CryptoKey objects will be stored to mechanisms available to or to the actual current execution environment. To prevent hostile applications from misusing the Web Cryptographic API CryptoKey objects should not be shared between two origins.

It is advisable that application developers do not invent new cryptographic protocols for use with the Web Cryptographic API. It has been designed to work with existing protocols for the best performance. It is not recommended to use fingerprinting or super-cookies with the API because of the risk of malicious applications interfering with user agents or devices.

Conclusion and Outlook

From a general perspective, the W3C's proposed recommendation of the Web Cryptography API specification offers the possibility of a centrally maintained standard javascript crypto library. There are a range of benefits, for both technology providers and online users that may arise from such an initiative, including: better security because, for example, exploits will generally get patched quicker; better take-up because there won’t be so many ‘competing’ libraries and this will drive up quality by creating a virtuous circle.

From Cryptomathic's perspective, supporting standardized JS libraries offers the opportunity to harmonize the client-side of solutions that secure e-commerce, such as remote digital signing solutions. The library would be leveraged allowing for quicker and simpler standardization.

 References and Further Reading

• Web Cryptography API - W3C Proposed Recommendation (15 December 2016), by W3C
• Selected articles on Electronic Signing and Digital Signatures (2014-16), by Ashiq JA, Guillaume Forget, Jan Kjaersgaard , Peter Landrock, Torben Pedersen, Dawn M. Turner, Tricia Wittig and more
• Selected articles on Authentication (2014-16), by Heather Walker, Luis Balbas, Guillaume Forget, Jan Kjaersgaard, Dawn M. Turner and more
• REGULATION (EU) No 910/2014  on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC (2014) by the European Parliament and the European Commission
• Recommendations for the Security of Internet Payments (Final Version) (2013), by the European Central Bank
• Draft NIST Special Publication 800-63-3: Digital Authentication Guideline (2016), by the National Institute of Standards and Technology, USA.
• NIST Special Publication 800-63-2: Electronic Authentication Guideline (2013), by the National Institute of Standards and Technology, USA.
• Security Controls Related to Internat Banking Services (2016), Hong Kong Monetary Authority

 Image: W3C-2-textorized (W3C Logo made with W3C's mission statement), courtesy of Max Froumentin, Flickr (CC BY 2.0)