W3C home > Mailing lists > Public > public-webcrypto@w3.org > March 2014

WebCrypto Security Analysis

From: Kelsey Cairns <kelsey.cairns@inria.fr>
Date: Wed, 19 Mar 2014 15:40:02 +0100 (CET)
To: public-webcrypto@w3.org
Message-ID: <319303951.9953446.1395240002241.JavaMail.zimbra@inria.fr>
Dear W3C Crypto API WG, 

Here at INRIA we're starting a security analysis on the current draft 
of the Crypto API, co-funded by INRIA and W3C. The idea is to try to 
get some results in before the end of the last call period. 

Doing analysis of an API spec is a slightly unusual activity, it can 
often lead to conclusions like "if the API is implemented this way.." 
or "if the application program uses the API like this.." which can 
seem a bit superficial, but we will aim to produce something concrete 
output in terms of implementation advice, test cases for 
implementations, etc. 

As an example of the kind of things we find, one of the things we were 
looking at in the spec this morning was padding oracles on key unwrap 
operations. These are common in implementations of PKCS#11, for 
example. Following the current WebCrypto spec, if you were to unwrap a key using 
AES-CBC or RSA PKCS1v1.5, incorrect padding would lead to "DataError" 
or " OperationError" respectively. Meanwhile, the error if the 
ciphertext is correctly padded but the key is too long or too short, 
the error is "SyntaxError". The fact that these are different *could* 
be enough to allow a network attacker to obtain the encrypted key by 
chosen ciphertext attack, which would be relevant say for use case 2.2 
(Protected Document Exchange). 

As a first step we were planning to look in more detail at the key 
management subset of the API, but if there are any areas that are of 
specific concern where you'd like us to take a closer look and you 
haven't had time please let us know. All feedback welcome. 


Graham Steel & Kelsey Cairns 
Received on Thursday, 20 March 2014 07:46:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:02:41 UTC