The Web Cryptography API is the World Wide Web Consortium’s (W3C) recommendation for a low-level interface that would increase the security of web applications by allowing them to perform cryptographic functions without having to access raw keying material.[1] This agnostic API would perform basic cryptographic operations, such as hashing, signature generation and verification and encryption as well as decryption from within a web application.[2]
On 26 January 2017, the W3C released its recommendation for a Web Cryptography API[3] that could perform basic cryptographic operations in web applications. This agnostic API would utilize JavaScript to perform operations that would increase the security of data exchange within web applications. The API would provide a low-level interface to create and/or manage public keys and private keys for hashing, digital signature generation and verification and encryption and decryption for use with web applications.
The Web Cryptography API could be used for a wide range of uses, including:
Because the Web Cryptography API is agnostic in nature, it can be used on any platform. It would provide a common set of interfaces that would permit web applications and progressive web applications to conduct cryptographic functions without the need to access raw keying material. This would be done with the assistance of the SubtleCrypto interface, which defines a group of methods to perform the above cryptographic operations. Additional interfaces within the Web Cryptography API would allow for key generation, key derivation and key import and export.
The W3C’s specification for the Web Cryptography API places focus on the common functionality and features that currently exist between platform-specific and standardized cryptographic APIs versus those that are known to just a few implementations. The group’s recommendation for the use of the Web Cryptography API does not dictate that a mandatory set of algorithms must be implemented. This is because of the awareness that cryptographic implementations will vary amongst conforming user agents because of government regulations, local policies, security practices and intellectual property concerns.
There are many types of existing web applications that the Web Cryptography API would be well suited for use with.
Today multi-factor authentication is considered one of the most reliable methods for verifying the identity of a user of a web application, such as online banking. Many web applications currently depend on this authentication method to protect both the user and the user agent. With the Web Cryptography API, a web application would have the ability to provide authentication from within itself instead of having to rely on transport-layer authentication to secret keying material to authenticate user access. This process would provide a richer experience for the user.
The Web Cryptography API would allow the application to locate suitable client keys that were previously created by the user agent or had been pre-provisioned by the web application. The application would be able to give the user agent the ability to either generate a new key or re-use an existing key in the event the user does not have a key already associated with their account. By binding this process to the Transport Layer Security that the user is authenticating through, the multi-factor authentication process can be additionally strengthened by the derivation of a key that is based on the underlying transport.
The API can be used to protect sensitive or confidential documents from unauthorized viewing from within a web application, even if they have been previously securely received. The web application would use the Web Cryptography API to encrypt the document with a secret key and then wrap it with public keys that have been associated with users who are authorized to view the document. Upon navigating to the web application, the authorized user would receive the document that had been encrypted and would be instructed to use their private key to begin the unwrapping process that would allow them to decrypt and view the document.
Many businesses and individuals rely on cloud storage. For protection, remote service provide might want their web application to give users the ability to protect their confidential documents before uploading their documents or other data. The Web Cryptography API would allow users to:
The ability to electronically sign documents saves time, enhances the security of important documents and can serve as legal proof of a user’s acceptance of a document. Many web applications choose to accept electronic signatures instead of requiring written signatures. With the Web Cryptography API, a user would be prompted to choose a key that could be generated or pre-provisioned specifically for the web application. The key could then be used during the signing operation.
Web applications often cache data locally, which puts the data at risk for compromise if an offline attack were to occur. The Web Cryptography API permits the web application to use a public key deployed from within itself to verify the integrity of the data cache.
The Web Cryptography API can enhance the security of messaging for use in off-the-record (OTR) and other types of message-signing schemes through the use of key agreement. The message sender and intended recipient would negotiate shared encryption and message authentication code (MAC) keys to encrypt and decrypt messages to prevent unauthorized access.
The Web Cryptography API can be used by web applications to interact with message formats and structures that are defined under JOSE Working Group.[4] The application can read and import JSON Web Signature (JWK) keys, validate messages that have been protected through electronic signing or MAC keys and decrypt JWE messages.
The W3C recommends that vendors avoid using vendor-specific proprietary extensions with specifications for the Web Cryptography API. This is because it could reduce the interoperability of the API and break up the user base since not all users would be able to access the particular content. It is recommended that when a vendor-specific extension cannot be avoided, the vendor should prefix it with vendor-specific strings to prevent clashes with future generations of the API’s specifications.