RE: XML Encryption CBC attack

Some suggestions to circumvent the attack, these need to be discussed further.


1) For message protocols based on XML encryption like WS-Security and ebXML,  sending the encrypted messages over with 1-way-SSL should be an effective countermeasure. This attack relies on the attacker being able to get the ciphertext and replay it. But with 1-way-SSL, the attacker cannot even get hold of the initial ciphertext, so he cannot carry out the attack.  Although this very expensive in terms of performance because of the two layers of security - XML encryption as well as SSL encryption,  it is a quite practical solution.  Many sensitive deployments already use 1-way-SSL for all external traffic,  they can be assured that they are not affected by this attack. Also deployments can turn on SSL temporarily till they get a proper patch to this issue.



 
2) XML encryption implementations should limit reuse of content encryption symmetric key.   I.e the server side should disallow reusing the same encrypted key many times. Many servers already maintain a cache of SignatureValues and nonces, to prevent the replay of the same signature value or same nonce.   They can do a similar thing for EncryptedKey, to prevent replay of the encrypted data with the same encrypted key, as it is done in this attack.

Note In some situations the same symmetric key is used for encrypting all messages for the entire duration of a session e.g. with WS-SecureConversation , kerberos tokens, SAML Holder of key with symmetric key.  But in these cases the best practice is to not use the session key directly for content encryption, instead one should derive a fresh content encryption key from the session key for every message. So even in these situation it is ok for XML encryption implementations to reject content encryption keys that have already been used before.



 
3) Combining signing and encryption can be an effective countermeasure, if the implementation is not vulnerable to signing and encryption wrapping attacks referred in this paper.  In WS-Security, "sign and then encrypt" is the normal way to send and receive messages.  But the WS-Security implementation has to be careful to 
a) not blindly decrypt everything that is encrypted in the message. Instead the service should selectively decrypt only the things that it expects to be encrypted e.g. the soap:Body, UsernameToken etc. For example if an attacker sends a encrypted body wrapped away in the dummy soap header, the service should not decrypt it and throw errors when decryption of the wrapped body fails.
b) send the same error message back to client when the decryption fails, vs when the decryption succeeds and signature fails. In many implementations the XML signature verification library comes from a different source than the crypto decryption library, so error messages in crypto decryption e.g. BadPaddingException can potentially be reported differently from error messages resulting from signature verification.  The service has to be careful to unify these error messages.
c) address timing attacks. One can argue that with "Decrypt and Verify"   there is a timing difference between decrypt-fails and  decrypt-succeeds-but-verify-fails.  But in pratice there is probably not a big timing difference at least for small messages. With RSA keys a decrypt operation is 50 times slower than a verify operation, (RSA is purposely designed with small public exponents so that public key operations are much faster than private key operations)  So the decrypt operation time greatly overshadows the verify operation, hence it is difficult to distinguish when verify fails vs when decrypt fails.


 
4)AES_GCM: Since this attack is based on the malleability of CBC, using AES-GCM instead of AES-CBC thwarts the attacks. 
XML encryption 1.1 already includes AES-GCM



Pratik

-----Original Message-----
From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com] 
Sent: Saturday, October 29, 2011 8:25 AM
To: public-xmlsec@w3.org
Cc: Frederick.Hirsch@nokia.com
Subject: XML Encryption CBC attack

The paper describing the CBC attack on XML Encryption is available at http://www.nds.rub.de/research/publications/breaking-xml-encryption/

A blog post from Thomas related to this is at: http://www.w3.org/QA/2011/10/some_notes_on_the_recent_xml_e.html

regards, Frederick

Frederick Hirsch, Nokia
Chair XML Security WG

Received on Wednesday, 2 November 2011 20:59:38 UTC