The first article of the blog series „The Web Cryptography API: Do not trust anybody!“ explains the Web Cryptography specification. If you haven’t already, read it now before joining me in the security analysis in this article. The WCA does not specify explicit safety considerations, but only hints. A distinction is made between user-agent developers and application developers, who upgrade the later Web application with JavaScript code. Finally, the users of the web application must also be taken into account [4]. As a side note the whole bachelor thesis the blog series is based on was written in German and can be accessed freely (DOI: 10.13140/RG.2.2.11844.14724).
Safety Considerations
User-agent developers should ensure that no CryptoKey objects are shared between multiple origins. In other words, messages from two different applications cannot be distinguished and mutually decrypted. Because of this, the WCA specification assumes that the CryptoKey objects are only available in the current execution environment or all storage mechanisms available for this environment. However, if the objects have to be shared explicitly, the use of the function window.postMessage() is recommended [4]. The problem of Key Reuse refers to the multiple use of a key for different web applications. The WCA specification provides two possible solutions for this problem, which are not without challenges: [4]
- A Key Reuse happens automatically and is completely transparent for the user, taking into account predefined trust relationships. The Public Key Infrastructure (PKI) has become a special infrastructure for the administration of asymmetric cryptosystems. Such a certificate is used to issue a digital certificate of assignment to a natural or legal person. For this reason, a certain amount of trust can be placed in every user of a valid certificate because the Registration Authority (RA) guarantees the identity of the certificate owner for the connection of public keys [6, pp. 397-404]. According to the WCA, the way in which the reuse of existing keys takes place is not specified more precisely, so that, for example, decisions can be made on the basis of certificates. Only the Certification Authority (CA) has to be trusted, because the CA is only allowed to issue valid certificates to each holder.
- The user is made aware of the Key Reuse and possible security risks in order to provide him with a decision option. The problem with such a procedure lies in the detail because the user has to make a security decision without being able to estimate the consequences of the decision. A web application may be able to decrypt the communication or the transmitted data to others because the user agent shares the same key with several parties.
The specified algorithms perform computational intensive calculations, such as the generation of large prime numbers or recursive operations. As a result, malicious applications can attempt to misuse the WCA and deny access to the application itself. In these circumstances, some action must be taken: First, the number of operations that an implementation can perform simultaneously should be limited. In addition, user consent must be obtained when an operation is performed, which is disruptive to execution time. Finally, device-specific limits on key variables or iteration numbers should also be defined [4].
Application developers must basically comply with all the specified requirements of the WCA, as already described in Section 3.1.4. Developers must also be familiar with existing threats, such as XSS in web applications and the underlying security model, in order to be able to provide cryptographic assurances to the API. The specification only provides the necessary building blocks for using existing protocols or cryptosystems [4].
As already mentioned, application developers must be aware of possible Key Reuse. Furthermore, the developers must not make any normative demands on implementations as to how the underlying cryptographic key material is stored. The API assures that the key material may only be exposed to the two methods exportKey and wrapKey. For example, the cryptographic key material may be stored unencrypted on the hard disk or on a network drive. This is directly dependent on how the user-agent has been implemented or whether the user is allowed to store the keys independently. Furthermore, any application that has access to the device memory and finds unencrypted key material can restore it. Compliant user agents are also not obliged to disassemble the key material or delete it from the device memory if all references to the corresponding CryptoKey object have been removed [4].
Hickson does not give any exact information in the Web Storage specification of the WCWG regarding the location of the device memory of a user agent. Thus, the cryptographic key can be stored in the main memory or locally on the hard disk without access restriction [3]. The device memory can therefore be deleted or modified without further authorization by the user, so that the keys do not have to be available indefinitely. Alternatively, the web application must be implemented in such a robust way that it can handle the loss of keys [4].
Users of applications implementing the WCA specifications must ensure that the application has full access to the messages exchanged. The cryptography used is irrelevant. Consequently, the web application can read the encrypted messages in plain text [4].
Privacy Policy
A profile of the user can be created very easily by using keys that are often long-lived or can be clearly assigned to existing users.
Fingerprinting: A user can be uniquely identified by combining different information. This technique works sufficiently because information such as browser version, operating system, user name and IP address can already be read out. This unique fingerprint of the user can now be supplemented with WCA data. This includes, for example, whether the user has a special public key or which algorithms the user agent supports [4] Halpin also recommends that only authorized web applications should have access to the corresponding public key, so that the listing of all public keys can be prevented. From now on, web applications must specify the key that the user agent is to use. Finally, each web application should generally generate its own key pair to prevent Key Reuse [2, 4].
Super Cookies: If keys with a long lifetime are used, they serve as cookies. In principle, the keys behave like cookies and can be rejected or prevented but the keys are a necessary prerequisite for the functionality of the web applications. Each key is assigned to a user so that identification is also possible via different user agents. This can be used, for example, to authenticate a user. In addition, conventional cookies are irrelevant because the assignment is only possible via this bijective mapping between key and user [4]. Regular exchange or derivation of the keys is the only way to break the correlation between user and key. Consequently, the web application must never be able to bring the old and new key into a common context. However, in order to correctly exchange or derive the cryptographic keys, the user must be authenticated vis-à-vis the web application. This is the only way the application can correctly assign that key to a user and then calculate the new key. This also means that there is a connection between the old and new keys. For this reason the WCA is a real risk to be used as a permanent identification against the user’s wishes [4].
Tracking: A profile of the user behaviour can only be created if the different web applications exchange information with each other and if a user can be clearly identified in all applications. As long as each web application uses the same cryptographic key for communication, a set of web applications can be subjectively assigned to each key. For this reason it makes sense to use a separate key for each application.
Threats
The authors Cairns, Halpin and Steel discuss in their paper „Security Analysis of the W3C Web Cryptography API“ a security analysis of the WCA by formal modelling of the specification. Cairns, Halpin, and Steel also argue that formal modeling should be done before standardisation and that both simple and complex attack vectors can be detected, which the working group would not recognize [1, pp. 112-113].
In this conference report, formal modeling was performed with the programming language AVISPA (Automated Validation of Internet Security Protocols and Applications) using a SAT solver. It automatically validates and verifies security protocols based on the DY formalism. In particular, multiple model checkers can be used, allowing specification of protocols in both the high-level and low-level domains. Cairns, Halpin and Steel chose AVISPA for WCA analysis because it takes into account the changing global state between sessions. As a result, all keys in a keystore can be considered to change over time and influence the execution semantics of protocols for operations such as signing and encryption in an API [1, pp. 116-117].
The following assumptions are defined so that the threat model is realistic with respect to the actual attack vectors. The origin of the JavaScript source code is trusted, the WCA is correctly initialised, and the secrets have been successfully encrypted and stored on the client. In particular, access to the raw keys is only possible if the server is of the same origin. Finally, all assumptions mentioned here are integrated in the formal models, so that the rules are formulated as typed predicates within a finite state machine [1, pp. 121-123].
In the further course of the work „Security Analysis of the W3C Web Cryptography API“ the authors Cairns, Halpin and Steel examined different scenarios with different security properties and the selection of algorithms. In summary, the analysis revealed three attack vectors, two of which have already been fixed in the course of the WCA specification [14,pp. 126-134]. Especially when exporting keys, the attribute keyUsage of the CryptoKey object does not remain. This means that packed secret key material sent between client and server can be exposed and the authenticated key exchange can be interrupted. The exchanged key can now be used to perform all cryptographic operations that were previously restricted by the keyUsage attribute. In principle, the following approaches can solve the problem, but after further consideration they turned out to be naive: First of all, the use of a key can be bound to the entire life cycle, which prevents the change of the intended use. Alternatively, the keyUsage object is inherited when a key is wrapped, or, more restrictively, the wrapping or unveiling of keys is completely prevented [1, p. 134].
Cairns, Halpin, and Steel also mention that the handling of key attributes in the WCA is not clearly apparent to developers. The original host has no control over the purpose of a key, and thus it can always be changed unintentionally. If a symmetric key is to be replaced by an asymmetric cryptosystem, an extraction of the inner key is required. This also opens this attack vector if the web application is not implemented correctly. The security-critical responsibility now lies entirely with the developer [1, p. 135].
Furthermore, the authors of the conference paper „Security Analysis of the W3C Web Cryptography API“ discuss that the WCA does not specify how keys and their intended uses should be stored in a long-term memory. Developers can make poor decisions here because the raw key material is tied to the lifetime of the user agent. Therefore, developers must implement a persistent long-term keystore, which again requires the problematic routines for exporting and wrapping keys [1, p. 136].
Sources
[1] Kelsey Cairns, Harry Halpin and Graham Steel. „Security Analysis of the W3C Web Cryptography API“. In: Security Standardisation Research. Pub. Lidong Chen, David McGrew and Cris Mitchell. Bd. 10074. Cham: Springer International Publishing, 2016, S. 112–140. DOI: 10.1007/978-3-319-49100-4.
[2] Harry Halpin. „Re-igniting the Crypto Wars on the Web“. In:29th Chaos Communication Congress. Hamburg: Chaos Computer Club, 2012. URL: https://media.ccc.de/v/29c3-5374-en-re_igniting_the_crypto_wars_on_the_web_h264
[3] Ian Hickson. Web Storage (Second Edition). Tech. Rep. Cambridge: W3C, Apr. 2016. URL: https://www.w3.org/TR/webstorage.
[4] Mark Watson. Web Cryptography API. Tech. Rep. Cambridge: W3C, Jan. 2017. URL: https://www.w3.org/TR/WebCryptoAPI/.
