[jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt)
=JeffH <Jeff.Hodges@KingsMountain.com> Thu, 14 March 2013 15:17 UTC
Return-Path: <Jeff.Hodges@KingsMountain.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764D311E8292 for <jose@ietfa.amsl.com>; Thu, 14 Mar 2013 08:17:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.999
X-Spam-Level:
X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlvvUsXVZnVb for <jose@ietfa.amsl.com>; Thu, 14 Mar 2013 08:17:01 -0700 (PDT)
Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 97F5B11E828D for <jose@ietf.org>; Thu, 14 Mar 2013 08:17:01 -0700 (PDT)
Received: (qmail 5717 invoked by uid 0); 14 Mar 2013 15:16:40 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy12.bluehost.com with SMTP; 14 Mar 2013 15:16:40 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=wT8yywc3Cn/uPdBDwejoErkKJYZuuQX0iD/QX3EtdVM=; b=wRLYy53LIUX2aZ7klyPLEvd8fIo7t85S+j2vtY1Zcz0o3SkDJbMEhHd8sxudkOTPmr4l/kKzR2eDhUHzTf5MWWvOGzlYgnHK0bLB2kulU59o5RtFYzSyoX4eBimg5BS1;
Received: from [130.129.19.55] (port=40198) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1UG9tY-0000i2-2N; Thu, 14 Mar 2013 09:16:40 -0600
Message-ID: <5141E9D6.6030003@KingsMountain.com>
Date: Thu, 14 Mar 2013 08:16:38 -0700
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: IETF JOSE WG <jose@ietf.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 130.129.19.55 authed with jeff.hodges+kingsmountain.com}
Cc: Juraj Somorovsky <juraj.somorovsky@rub.de>
Subject: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt)
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Mar 2013 15:17:06 -0000
back on Fri, 6 Jul 2012 Mike Jones said: > > Looking at this again, it seems to me that because JWE provides integrity > protection for the algorithm, it should be impossible for you to replace > "RSA-OAEP" with "RSA1_5" in the header because then the integrity check will > fail. Thus, the attack that you describe below is prevented by the integrity > protection of the header. > > Hence, correct JWE implementations do no provide the OAEP decryption oracle > that you describe. However if I'm missing something, please point it out to > me, since if there's an issue, I'd like to understand it and how to mitigate > it. just fyi/fwiw...apologies if this has already been followed up on, but I didn't find further discussion of this after the above-quoted msg... Juraj Somorovsky et al's NDSS-2013 "Backwards Compatibility (BC) attacks" paper [1] is now out, and it may help answer the above questions. There's also Kenny Patterson's talk [2] from the recent Workshop on Real-World Cryptography. It seems, from an admittedly cursory glance at both draft-ietf-jose-json-web-algorithms (-08) and the above paper/slides, that perhaps there should be more implementation advice and security considerations in (at least) the -json-web-algorithms spec. Here's some excerpts from the paper for context... ... In the public-key setting, we show how the well-known attack of Bleichenbacher [13] gives rise to a BC [Backwards Compatibility] attack that allows an attacker to decrypt ciphertexts of PKCS#1 v2.0 encryption in both XML Encryption [27] and JSON Web Encryption [42], and to forge signatures for arbitrary messages in XML Signature [30] and JSON Web Signature [41]. The attack principle is described in Section 4. We furthermore report on our experimental results, executed against the Java implementation of JSON Web Encryption and JSON Web Signature Nimbus-JWT [53], in Section 5.3. ... Platform for Experimental Analysis: We investigate the practicality and performance of our attacks on JWE and JWS by applying them to the Nimbus-JWT library [53]. Nimbus-JWT is a Java implementation of JSON Web Encryption (JWE) and JSON Web Signature (JWS), developed by NimbusDS to support their Cloud Identity management portfolio. Even though Nimbus-JWT claims to implement version 02 of the JWE standard draft, it still supports usage of AESCBC (without MAC), which was available in version 01, but not in version 02 or any subsequent versions. ... 5.2.3 Evaluation We evaluated performance of our attacks against both WSS4J and Nimbus-JWT. We first used the libraries to generate valid messages containing AES-GCM ciphertexts. Then we modified the algorithm parameters in the messages, forcing the receiver to process the ciphertexts using AES-CBC, and executed the attack described in Algorithm 1. The required ciphertext validity oracles were based on error messages generated by the libraries. ... Experimental Results. In order to assess the practicability and performance of the attack, we implemented Bleichenbacher’s attack on XML Encryption [13, 38] and applied it to the Nimbus-JWT library. The PKCS#1 v1.5 validity oracle was provided by exceptions thrown by this library.11 ... 11 In practice one would instead use the more elaborate attack techniques of [38] to determine whether a given ciphertext is PKCS#1 v1.5 valid. ... [13] D. Bleichenbacher. Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS#1. In H. Krawczyk, editor, Advances in Cryptology – CRYPTO’98, volume 1462 of Lecture Notes in Computer Science, pages 1–12. Springer, Aug. 1998. [38] T. Jager, S. Schinzel, and J. Somorovsky. Bleichenbacher’s attack strikes again: breaking PKCS#1 v1.5 in XML Encryption. In S. Foresti and M. Yung, editors, Computer Security - ESORICS 2012 - 17th European Symposium on Research in Computer Security, Pisa, Italy, September 10-14, 2012. Proceedings, LNCS. Springer, 2012. [53] Nimbus Directory Services. Nimbus JSON Web Token, May 2012. https://bitbucket.org/nimbusds/nimbus-jwt. ### [1] One Bad Apple: Backwards Compatibility Attacks on State-of-the-Art Cryptography http://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2013/03/08/BackwardsCompatibilityAttacks.pdf [2] Key Reuse: Theory and Practice http://crypto.stanford.edu/RealWorldCrypto/slides/kenny.pdf HTH, =JeffH
- [jose] backwards compatibility attack on JWT impl… =JeffH
- Re: [jose] backwards compatibility attack on JWT … Mike Jones
- Re: [jose] backwards compatibility attack on JWT … Brian Campbell
- Re: [jose] backwards compatibility attack on JWT … Mike Jones
- Re: [jose] backwards compatibility attack on JWT … Justin Richer
- Re: [jose] backwards compatibility attack on JWT … Juraj Somorovsky
- Re: [jose] backwards compatibility attack on JWT … Juraj Somorovsky
- Re: [jose] backwards compatibility attack on JWT … Juraj Somorovsky
- Re: [jose] backwards compatibility attack on JWT … Juraj Somorovsky
- Re: [jose] backwards compatibility attack on JWT … Brian Campbell
- Re: [jose] backwards compatibility attack on JWT … Richard Barnes
- Re: [jose] backwards compatibility attack on JWT … Richard Barnes
- Re: [jose] backwards compatibility attack on JWT … Juraj Somorovsky
- Re: [jose] backwards compatibility attack on JWT … Juraj Somorovsky
- Re: [jose] backwards compatibility attack on JWT … Vladimir Dzhuvinov / NimbusDS
- Re: [jose] backwards compatibility attack on JWT … Peck, Michael A
- Re: [jose] backwards compatibility attack on JWT … Juraj Somorovsky
- Re: [jose] backwards compatibility attack on JWT … Richard Barnes
- Re: [jose] backwards compatibility attack on JWT … Manger, James H
- Re: [jose] backwards compatibility attack on JWT … Manger, James H
- Re: [jose] backwards compatibility attack on JWT … Juraj Somorovsky
- Re: [jose] backwards compatibility attack on JWT … Vladimir Dzhuvinov / NimbusDS
- Re: [jose] backwards compatibility attack on JWT … Manger, James H
- Re: [jose] backwards compatibility attack on JWT … Juraj Somorovsky