Addition to xml encryption 1.1 security considerations section

Hal has provided a new section for the XML Encryption 1.1 security considerations section, for ACTION-850

I will add this to the Last Call publication draft so it can receive wider review. Please indicate any concern, comment or corrections on the public list before 30 December

(1) New section 6.1 in Security Considerations section (I corrected various spelling errors):
[[
6.1 Chosen-Ciphertext Attacks

A number of chosen-ciphertext against implementations of this specification have been published and demonstrated. Also known as Bleichenbacher attacks, from the author of the first attack of this type, they all involve the following elements:

  1.  The attacker knows a lot about the format of the cleartext.
  2.  The attacker is able to submit substantial numbers of ciphertext messages.
  3.  The attacker is able to send arbitrary ciphertext, based on previous results.
  4.  All the ciphertext purports to use the same encryption key.
  5.  The server attempting to decrypt the ciphertext in some way signals whether the decrypted text is well formed or not.

The attacker uses the knowledge of the format and the information about well formedness to construct a series of ciphertext guesses which reveal the plaintext with much less work than brute force. Attacks of this type have been demonstrated against symmetric encryption using CBC mode [XMLENC-CBC-ATTACK<file:///Materials/Builds/xmlsec2/Drafts/xmlenc-core-11/WD-2011-12/Overview.src.html#bib-XMLENC-CBC-ATTACK>] and on PKCS#1 v1.5. Other, future attacks can be expected whenever these conditions are met.

It would seem that these attacks can be countered by by disrupting any of the conditions, however in practice only preventing condition 3 is fully effective. To counter condition 3, it is necessary for the decrypting system to require authenticated integrity protection over the ciphertext. However, unless the mechanism used is bound to the encryption key, there will no way to be sure that the signer is not attempting to recover the plaintext. The simplest and most efficient way to do this is to use an authenticating block mode, such as GCM. An alternative would be an HMAC based on the encryption key over the ciphertext, but it is less efficient and provides no advantages.

Other countermeasures are not likely to be effective. Limiting the number of messages presented or the number of messages using the same key is not practical in large server farms. Attackers can spread their attempts over different servers and long or short periods of time, to foil attempts to detect attacks in progress or determine the location of the attacker.

Signaling wellformedness can occur by emitting different messages for distinct security errors or by exhibiting timing differences. Implementations should avoid these practices, however that is not sufficient to prevent such attacks in an XML protocol environment, such as SOAP. Using a technique called encryption wrapping, the attacker can insert the ciphertext in some schema-legal part of the message. If the decryption code notices a format error, an error will be returned, but if not the message will be passed to the application which will ignore the bogus plaintext and ultimately respond with an application level success or failure message,

]]

(2) Addition to end of  section on Nonce and IV

[[
6.4 Nonce and IV (Initialization Value or Vector)
....

Note: CBC block encryption algorithms should not be used without consideration of possibly severe security risks.

For the Galois/Counter Mode (GCM) used by this specification, the IV must not be reused for any key and should be random, but it need not be secret.

]]

(3) Hal suggested removing the security considerations on Error Messages and Timing but I suggest keeping them for Last Call, due to the short time for reviewing these changes, and since they are still good practices in general and may help mitigate various attacks, even if they are not able to prevent the CBC attack.

regards, Frederick

Frederick Hirsch
Nokia