XML encryption

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.

 

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.

 

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

 

 

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?

 

 

 

this is related to my ACTION-857

 

Pratik