Re: XML encryption

Hi Pratik,

I include answers to your questions.

On 11/28/2011 10:52 PM, Pratik Datta wrote:
> Juraj,
>
>
>
> Few questions related to
http://www.nds.rub.de/research/publications/breaking-xml-encryption/
>
>
>
> We are trying to see if we can do some easy to implement countermeasures.
>
>
>
> 1) Use AES-CBC, but prevent encryption key reuse:  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.

This *may* work in certain scenarios. However, how long is your history?
Can you make sure that *all* previous keys are stored? If you store
only, say, the last 1000 encryption keys, then an attacker may apply a
round-robin strategy to apply the attack again.

Moreover, it requires shared state across servers that are working in a
cluster. Even if this state would be achieved, it would potentially be
possible to get some responses back before all the servers know about
the revoked key.

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

Modifying the key derivation sounds like really deep changes in the
implementation. Is it really that much easier to implement this solution
than replacing the mode-of-operation with a really good one, or at least
adding mandatory MACs to each ciphertext?

>
> 2) Use a counter mode encryption like  AES-CTR or AES-GCM (but without
authentication tag):  This attack depends on the fact in that in CBC
mode, block Ci-1 is the initialization vector to Ci . Let us say the
messag! e is 20 blocks long. One can send only  the 18th and 19th
ciphertext block to decryption oracle , as if it were a 2 block
encrypted message.  Just by fiddling around with the last byte of the
18th block, one can get a valid response from the oracle.  However in
the counter mode this should not be possible, because the counter
increments for every block, so the IV depends on the position of the block.

Why without authentication tag? If you are already modifying the mode of
operation, why don't use one which provably defeats all these kinds of
attacks?

If you take a closer look e.g. at AES-CTR
(http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Counter_.28CTR.29),
you will see that without authentication tag you can do the same as with
CBC. You have to just flip the bits directly in the ciphertext and not
in the IV. If you would have more blocks, you would have to proceed as
follows (assuming that you know the nonce and the counter starts with 0,
which is a valid assumption):
1) take C1, apply the attack to this block. At the end, extract all '<'
from the first block, create C1'.
2) take C2, send it to the server together with C1'. Apply the attack to
C2 (as you are sending a correct number of blocks, the counter stays
valid). Extract all '<' from C2, create C2'.
3) repeat 2) for all the next blocks by sending C1'...Ci'Cx, where Cx is
the block which must be decrypted.

(Have a look at
http://blog.cryptographyengineering.com/2011/10/attack-of-week-xml-encryption.html,
in particular the section "Is there anything else to say about this?")

Right now we cannot recommend to use GCM or another mode of operation
*without* authentication.

>
> 3) Use CBC mode, but switch to PKCS5Padding:   XML encryption uses a
padding scheme, in which it ignores all the padding bytes except the
last one.  On the other hand PKCS5padding requires all padding bytes to
be same as last byte.  This attack seems to use this property of the XML
encryption padding scheme,  in the FindIVWith3BitMask algorithm.   Do
you think  using PKCS5Padding can be a countermeasure?

No. The attack would be only a little bit harder to apply while
extracting left parenthesis '<' from the message. But in general, you
could do the same: you would try to set the last byte in the block to
0x01 by iterating over all the 256 byte values. If there is no valid
response, you know that there is at least one '<'. Therefore, you could
simply flip some bits in the ciphertext bytes (e.g. last bit in each
ciphertext byte) and then again iterate over all the 256 values of the
last padding byte. If you set the last byte to 0x01, you win since you
can again apply our attack.

The attack should work with any padding scheme we could think of, since
the underlying weakness originates from the malleability of CBC in
combination with ASCII encoding, but not from the padding.

Our recommendation is:
- If you are able to change the mode of operation, use an "authenticated
encryption" mode like GCM with authentication tag
- otherwise, add an explicit authentication tag (MAC) to CBC which is
mandatory to be checked on each decryption. No ciphertext must be
processed without valid MAC over the ciphertext.

If you are applying XML Encryption in scenarios, where all the parties
are honest (there is no attacker who could generate a valid signature),
you could also enforce the server to process only the signed encrypted
parts. Thereby, also public-key XML Signatures could be used. However,
this countermeasure must also be implemented explicitly, since e.g. in
Web Services, there is no way to do it using WS-Security Policies.


Best Regards
Tibor and Juraj
-- 
M.Sc. Juraj Somorovsky

Lehrstuhl für Netz- und Datensicherheit
Ruhr Universität Bochum
-----------------------------------
Universitätsstr. 150, Geb. ID 2/411
D-44780 Bochum

Telefon: +49 (0) 234 / 32-26551
Fax: +49 (0) 234 / 32-14347
http://www.nds.rub.de

Received on Tuesday, 29 November 2011 00:05:45 UTC