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]

JSON Web Encryption
JSON Web Encryption (JWE)
AbbreviationJWE
StatusProposed
Year started16 January 2012 (2012-01-16)
First published16 January 2012 (2012-01-16)
Latest versionMay 2015
OrganizationIETF
SeriesJOSE
Authors
  • Michael Jones
  • Joe Hildebrand
DomainEncryption, authentication
Websitedatatracker.ietf.org/doc/html/rfc7516

Vulnerabilities

edit

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

edit
  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.