11. Security Considerations
All of the security issues that are pertinent to any cryptographic application are relevant to JWS/JWE/JWK agents. These issues include protecting the user's asymmetric private keys and symmetric secret keys and employing countermeasures against various attacks.
All of the security considerations in the JWS specification also apply to this specification. Likewise, all the security considerations in XML Encryption 1.1 [W3C.REC-xmlenc-core1-20130411] also apply, other than those that are XML specific.
11.1 Key Entropy and Random Values
See Section 10.1 of [JWS] for security considerations on key entropy and random values. In addition to the uses of random values listed there, note that random values are also used for Content Encryption Keys (CEKs) and Initialization Vectors (IVs) when performing encryption.
11.2 Key Protection
See Section 10.2 of [JWS] for security considerations on key protection. In addition to the keys that must be protected listed there, implementations performing encryption must also protect key encryption keys and Content Encryption Keys. Compromise of a key encryption key may result in the compromise of all content protected with that key. Similarly, compromise of a Content Encryption Key may result in compromise of the associated encrypted content.
11.3 Using Matching Algorithm Strengths
Algorithms of matching strengths should be used together whenever possible. For instance, when AES Key Wrap is used with a given key size, it is recommended that AES GCM be used with the same key size if also being used. If the key encryption and content encryption algorithms are different, the effective security is determined by the weaker of the two algorithms.
Also, see RFC 3766 [RFC3766] for information about determining strengths for public keys used for exchanging symmetric keys.
11.4 Adaptive Chosen-Ciphertext Attacks
When decrypting, particular care must be taken not to allow the JWE recipient to be used as an oracle for decrypting messages. RFC 3218 [RFC3218] should be consulted for specific countermeasures to attacks on RSAES-PKCS1-v1_5. An attacker might modify the contents of the "alg" Header Parameter from "RSA-OAEP" to "RSA1_5" in order to generate a formatting error that can be detected and used to recover the CEK even if the CEK was encrypted using RSAES-OAEP. It is therefore particularly important to report all formatting errors, Content Encryption Key, Additional Authenticated Data, or ciphertext errors as a single error when the encrypted content is rejected.
Additionally, this type of attack can be prevented by restricting the use of a key to a limited set of algorithms -- typically one. For example, this means that, if a key is marked as being for "RSA-OAEP" only, any attempt to decrypt a message using that key with the "RSA1_5" algorithm should fail immediately because of invalid use of the key.
11.5 Timing Attacks
To mitigate the attacks described in RFC 3218 [RFC3218], the recipient MUST NOT distinguish between format, padding, and length errors on the encryption key. It is strongly recommended that upon receipt of a malformed key, the recipient substitute a randomly generated CEK and proceed to the next step, to mitigate timing attacks.