Security Analysis of the W3C Web Cryptography API

Abstract

Abstract. Due to the success of formal modeling of protocols such as TLS, there is a revival of interest in applying formal modeling to standardized APIs. We argue that formal modeling should happen as the standard is being developed (not afterwards) as it can detect complex or even simple attacks that the standardization group may not otherwise detect. As a case example of this, we discuss in detail the W3C Web Cryptography API. We demonstrate how a formal analysis of the API using the modeling language AVISPA with a SAT solver demonstrates that while the API has no errors in basic API operations and maintains its security properties for the most part, there are nonetheless attacks on secret key material due to how key wrapping and usages are implemented. Furthermore, there were a number of basic problems in terms of algorithm selection and a weakness that led to a padding attack. The results of this study led to the removal of algorithms before its completed standardization and the removal of the padding attack via normalization of error codes, although the key wrapping attack is still open. We expect this sort of formal methodology to be applied to new standardization efforts at the W3C such as the W3C Web Authentication API.

A client-based encryption model for secure data storing in publicly available storages

“…• JavaScript -the application core was written with the use of several external libraries and built-in tools like WebCrypto [1] (provides cryptographical tools) and TaffyDB (provides database support). Encryption, decryption, the execution of queries, and the preparation of a user interface are done in JavaScript.…”

Formal verification of the W3C web authentication protocol

“…In general, the methodology of formal veri cation would be more productively applied during the development of a new protocol itself, so that the standard's speci cation is assured to ful ll its security and privacy requirements. There has been work on API analysis like the W3C Web Cryptography API [10], but this analysis was done after the standard itself was completed, although e orts in TLS 1.3 have incorporated formal veri cation into the standardization process [5].…”

A Roadmap for High Assurance Cryptography

“…For example, one would hope that an API like PKCS#11 that provides access to key material in hardware tokens would prevent any private key material from being tampered with, regardless of the application [10]. These kinds of security properties are particularly critical in many applications, and classically security APIs have been studied in the realm of hardware security modules [5] and increasingly in developer-facing APIs such as the W3C WebCrypto API for Javascript [7]. Most early work did not use generalizable formal techniques, but customized each technique for the API at hand [5], although some work allowed the automatic discovery of common errors in key management [15].…”

“…These account for the vast majority of errors in code and the "top errors" in APIs that have recently been collated by Google's Project Wycheproof 6 . Key management is often underspecified in APIs, and is a common source of errors in systems relying for example on PKCS#11 [10] and the WebCrypto API [7], and simply putting the key material in "trusted hardware" such as hardware tokens may end up having little effect, as shown by errors discovered via formal analysis Yubico's YubiHSM. 7 APIs created by standards committees seem to fare no better: implementations of standardized APIs such as PKCS#11 are often susceptible to multiple attacks.…”

“…Key management is often underspecified in APIs, and is a common source of errors in systems relying for example on PKCS#11 [10] and the WebCrypto API [7], and simply putting the key material in "trusted hardware" such as hardware tokens may end up having little effect, as shown by errors discovered via formal analysis Yubico's YubiHSM. 7 APIs created by standards committees seem to fare no better: implementations of standardized APIs such as PKCS#11 are often susceptible to multiple attacks. 8 Even worse, when APIs such as PKCS#11 and OpenSSL are used in hardware tokens, errors in the API can cause expensive withdrawal of hardware tokens [14].…”