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.The W3C’s purpose is to develop open standards and make recommendations to ensure that the Web continues to evolve in a single direction instead of becoming splintered among various factions competing against one another.
- 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.
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.
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
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.
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.
- 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
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 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