[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