Hi Juraj, Thanks for looking at the security characteristics of JWE.
I don't think that either of your scenarios (a) or (b) apply to JWE. For (a), a server implementing JWE will not accept unsigned (really, non-integrity-protected) requests because encryption algorithms not providing integrity protection may not be used. For (b), it doesn't matter if the attacker has a valid public key that the server would accept for signatures, because the integrity protection applied to JWE is not simply a separate signature applied after the fact. The JWE's contents are protected using a randomly generated key that is encrypted by the key wrapping step. Unless the attacker already possess the key to decrypt the encrypted key (the objective of the attack in the first place!), he can't learn what key was used to apply the integrity protection, and without that key, the attacker can't apply a different signature. The description of the "enc" parameter in http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#section-4.1.2 begins with: The "enc" (encryption method) header parameter identifies the block encryption algorithm used to encrypt the Plaintext to produce the Ciphertext. This algorithm MUST be an Authenticated Encryption algorithm with a specified key length. If you think that's not clear enough, we could certainly say more - particularly in the Security Considerations section. Suggested text would be more than welcomed. Also, responding to Brian's scenario, I believe that the attack on RSA PKCS #1 1.5 requires the ability for the attacker to submit valid modified messages to the server. Because the JWE messages are integrity-protected using a wrapped key, the reasoning of (b) above applies in this case too. Specifically, without knowing the RSA key in the first place, it's not possible to learn the key used to provide the integrity check, and so not possible to create modified messages that pass the integrity check. But by all means, if any of my reasoning is wrong or incomplete, please do point it out! Thanks again, Juraj, -- Mike -----Original Message----- From: Juraj Somorovsky [mailto:[email protected]] Sent: Thursday, March 14, 2013 9:42 AM To: Mike Jones Cc: =JeffH; IETF JOSE WG; Tibor Jager Subject: Re: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) Hi Jeff, hi Mike, I am sorry, it seems that I have totally missed your previous email. I try to answer some of your questions... On 03/14/2013 04:48 PM, Mike Jones wrote: > I believe that these attacks are only possible on encryption without > integrity, which in turn was only possible, because Nimbus-JWT continued to > implement encryption algorithms without integrity protection. Someone should > please correct me if I'm misunderstanding the situation. These attacks were basically possible because: 1) Nimbus-JWT allowed us to use AES-CBC. As we explicitly state in our paper, this is not problem of the jose specification as it forbids AES-CBC in the newer versions 2) We were able to force the Nimbus-JWT framework to decrypt RSA-OAEP ciphertexts with RSA1_5. You are right, in our scenarios, the Headers were not signed and thus we were able to switch from RSA-OAEP to RSA1_5. However, if I take a look at the JSON Web Encryption standard, there is not explicitly written that the messages must be signed. And even if the messages would be signed, there could still exist scenarios where it is possible to apply these attacks. See below. > > As most of you know, JWE now only allows authenticated encryption algorithms > to be used, for reasons exactly such as these. It is great that you removed AES-CBC. RSA1_5 encryption is still however in the standard. > > -- Mike > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of =JeffH > Sent: Thursday, March 14, 2013 8:17 AM > To: IETF JOSE WG > Cc: Juraj Somorovsky > Subject: [jose] backwards compatibility attack on JWT impls (was: I-D > Action: draft-ietf-jose-json-web-algorithms-02.txt) > > 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. Yes, this is true, if the attacker is not able to create valid signatures AND he is not able to force the server to process unsigned elements. However, there are few scenarios, where the attacks could still be applied. I am not that familiar with all the JSON scenarios but I assume that they are very close to the scenarios where XML Security is applied. Thus, I would say it is possible to assume the following scenarios: a) If the server is not correctly configured, it could accept unsigned requests JSON elements. Thus, the attacker could simply extract the signature or create an additional encryption element. b) in some Public-Key scenarios, the attacker will have a valid key to sign his JSON requests. In that case, he is able to: 1) take an RSA_OAEP request from his victim 2) extract the signature from this request 3) replace the algorithm (RSA_OAEP -> RSA1_5) and 4) resign the request with his own key. Afterwards, he could send the request to the server and force it to process RSA1_5 Please see our paper for more details (Section 4): http://www.nds.ruhr-uni-bochum.de/research/publications/breaking-xml-encryption-countermeasures/ It describes some techniques how to apply such attacks on signed symmetrically encrypted XML documents. > > 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. Agreed. Some of these attacks are e.g. explicitly handled in the XML Encryption specification: http://www.w3.org/TR/xmlenc-core1/#sec-chosen-ciphertext-attacks You could include similar sections in your spec. If you would need some help, just let us know. Thanks Juraj _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
