25815 2014-05-19 20:33:03 +0000 Spec encourages unsafe handling of secret data for JWK import of RSA/ECC keys 2014-10-22 21:26:55 +0000 1 1 1 Unclassified Web Cryptography Web Cryptography API Document unspecified PC Windows NT RESOLVED FIXED P2 normal --- 1 sleevi sleevi public-webcrypto virginie.galindo watsonm oldest_to_newest 106378 0 sleevi 2014-05-19 20:33:03 +0000 The current spec is somewhat underspecified with respect to handling secret data for RSA and ECC keys, and one possible interpretation leads to the unsafe handling of secret data in a manner which may leak information via timing, or require UA-specific cryptographic primitives. Specifically, language exists of the form "If jwk does not meet the requirements of Section X of JSON Web Algorithms, then return an error named DataError" However, this is underspecified for several reasons: - In the RSA case, d may be specified, but may be inconsistent with n/e - In the RSA case, d may be specified, but have inconsistent CRT parameters associated - In the RSA case, d may be specified, but have inconsistent p/q - In the ECC case, d may be specified, but be invalid according to the point All of these cases encourage an error return of DataError, which implies a degree of checking on the client side, as "implementation-deduced" errors are typically assigned the error code OperationError. The computation of consistency checks can leak timing information (and also requires the implementation of multi-precision integers), which are both things that are trying to be avoided in the requirements of UAs. 106379 1 sleevi 2014-05-19 20:38:11 +0000 On the Chromium side, we've encountered a number of issues where the inconsistency between DataError and OperationError has been difficult to ascertain in a UA that defers cryptographic operations to another library (eg: NSS, OpenSSL). Equally, the distinction between OperationError and DataError does not seem to be consistently applied. For example, in the case of RSA, inconsistent message sizes result in OperationError, whereas in AES, they're DataError. In ECDH derivation, if an invalid public key is specified (eg: perhaps its parameters are hostile towards the private key / on an invalid point) it's an OperationError. AES-GCM Decryption Failure is an OperationError (even though it's the data that is invalid for the tag) 109198 2 sleevi 2014-07-23 02:28:35 +0000 Another example: A number of language bindings that allow creating language/library-specific keys from primitives (e.g.: n,e,d for RSA) may not compute the other parameters (necessary for output). Further, if just n,e,d are specified, they can lead to unsafe handling of data. For example, in a number of Java JCE implementations, creating an RSA private key with JUST n,e,d will disable RSA blinding attacks, which exist to mitigating timing attacks against RSA. On the flip side, several cryptographic libraries require that the caller supply all the parameters, as they're required by PKCS#8. Handling the JWK case would require the UA to perform the MPI math itself. My proposed resolution for this is: - Normalize on operation error for any form of weirdness - Require that JWK RSA keys have all the parameters from JWA, which is valid according to JWA (from talking with Mike, it's assumed as the default) 111951 3 watsonm 2014-09-22 17:51:08 +0000 I agree with normalization to OperationError throughput the specification. 113092 4 virginie.galindo 2014-10-14 10:05:40 +0000 In order to progress towards exit to Last Call for the Web Crypto API, the chair suggests the following resolution for that bug. Resolution : Bug CLOSED. Editors will implement the changes as described in https://www.w3.org/Bugs/Public/show_bug.cgi?id=25815#c2. If none objects before the 20th of Oct @20:00 UTC, this resolution will be endorsed. 113264 5 watsonm 2014-10-16 00:29:43 +0000 In fact, there is actually only one example where import / export returns OperationError other than for the "underlying key material cannot be accessed" on export. This is for AES CMAC import where it does a check of the length of the data. So, it may actually be more convenient - and still very reasonable - to normalize on DataError for import. With this change and Bug 25741 the situation will be as follows: - Encrypt/Decrypt/Sign/Verify operations all return OperationError for all parameter validation. - Import operations will always return DataError for all parameter validation. It remains to check Generate (which I think should normalize on OperationError) and Export (which doesn't encounter anything not easily detectable by the UA). So, DataError for import ? 113603 6 watsonm 2014-10-22 21:26:55 +0000 Import Key: Normalize on DataError. Only AES-CMAC needs changes: https://dvcs.w3.org/hg/webcrypto-api/rev/4fcabd0b818a Generate Key: Normalize on OperationError excepy usages validation which is SyntaxError: - fix one instance where usages validation was specified twice (ECDH). The second was unreachable and invalid: https://dvcs.w3.org/hg/webcrypto-api/rev/3d94cb8ef334 - fix one instance of parameter validation which was not returning OperationError (HMAC): https://dvcs.w3.org/hg/webcrypto-api/rev/1e509576870d The issue referred to in this bug does not affect Export Key.