JSON Web Encryption

JSON Web Encryption

JSON Web Encryption (JWE)
Abbreviation	JWE
Status	Proposed
Year started	16 January 2012 (2012-01-16)
First published	16 January 2012 (2012-01-16)
Latest version	May 2015
Organization	IETF
Series	JOSE
Authors	Michael Jones Joe Hildebrand
Domain	Encryption, authentication
Website	datatracker.ietf.org/doc/html/rfc7516

JSON Web Encryption (JWE) is an IETF standard providing a standardised syntax for the exchange of encrypted data, based on JSON and Base64.^[1] It is defined by RFC 7516. Along with JSON Web Signature (JWS), it is one of the two possible formats of a JWT (JSON Web Token). JWE forms part of the JavaScript Object Signing and Encryption (JOSE) suite of protocols.^[2]

Vulnerabilities

In March 2017, a serious flaw was discovered in many popular implementations of JWE, the invalid curve attack.^[3]

One implementation of an early (pre-finalised) version of JWE also suffered from Bleichenbacher’s attack.^[4]

References

1. Ng, Alex Chi Keung (26 January 2018). Contemporary Identity and Access Management Architectures: Emerging Research and Opportunities. IGI Global. p. 215. ISBN 978-1-5225-4829-4. JWE is a means of representing encrypted content using JSON data structures.
2. Fontana, John (January 21, 2013). "Developers getting JSON-based options for enterprise authentication". ZDNet. Retrieved 2018-06-08.
3. Rashid, Fahmida (27 March 2017). "Critical flaw alert! Stop using JSON encryption". InfoWorld. Retrieved 8 June 2018.
4. Jager, Tibor; Schinzel, Sebastian; Somorovsky, Juraj (2012), "Bleichenbacher's Attack Strikes again: Breaking PKCS#1 v1.5 in XML Encryption", Computer Security – ESORICS 2012, Springer Berlin Heidelberg, pp. 752–769, CiteSeerX 10.1.1.696.5641, doi:10.1007/978-3-642-33167-1_43, ISBN 9783642331664, Beyond XML Encryption, the recent JSON Web Encryption (JWE) specification prescribes PKCS#1 v1.5 as a mandatory cipher. This specification is under development and at the time of writing there existed only one implementation following this specification. We verified that this implementation was vulnerable to two versions of the Bleichenbacher's attack: the direct attack based on error messages and the timing-based attack.