Re: Addition to xml encryption 1.1 security considerations section

Hi,

I would like to contribute with some comments to improve your new sections.

First of all, I think it would be reasonable to divide section 6.1 into
two new sections:
6.1.1 Attacks against the encrypted data (CBC-based attacks)
6.1.2 Attacks against the encrypted key (Bleichenbacher's Million
question attack on PKCS#1.5)
This would make the document better readable since these two attacks are
completely different, they are attacking different parts of the
encrypted xml documents and yielding different outputs.
> 
> 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:
Bleichenbacher attack is only the attack on PKCS#1.5.
> 
>   1.  The attacker knows a lot about the format of the cleartext.
Not necessarily "a lot": The attacker knows 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.
Better: The attacker is able to force the server to use the same key
(secret key by CBC-based attacks and server's private key by PKCS#1.5
attacks) for processing of the adapted ciphertext.
>   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.
6.1.1 Attacks against the encrypted data (<EncryptedData> part)

Using the CBC-based chosen-ciphertext attacks, the attacker sends to the
server XML document with modified encrypted data in the symmetric part
(<EncryptedData>). After a few requests, he is able to get the whole
cleartext without knowledge of the symmetric key.
> 
> 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,

6.1.2 Attacks against the encrypted key (Bleichenbacher's Million
question attack on PKCS#1.5)

The goal of the attacker applying the Bleichenbacher's attack is to get
the symmetric secret key, which is encrypted in the <EncryptedKey> part.
Afterwards, he would be able to decrypt the whole data carried in the
<EncryptedData> part.

The basic idea of this attack is to modify the data in the
<EncryptedKey> part, send the document to the server, and observe if the
modified ciphertext contained PKCS#1.5 conform data. This could be done by:
1) observing the fault messages of the server notifying directly that
the request was not PKCS#1.5 conform (this should not happen).
2) enlarging the data in the <EncryptedData> part and observing the
timing differences between inclusion of PKCS-valid and PKCS-invalid
keys: if the key is PKCS-valid, the session key is extracted, and the
large data is decrypted. Otherwise, the session key cannot be extracted
and the large data is not processed, which yields a timing difference.
3) specific modification of the <EncryptedData> part based on the CBC-
and padding-properties.

These problems are already described by Eric Rescorla
(http://tools.ietf.org/html/draft-ietf-smime-pkcs1-01).

The most effective countermeasure against the timing attack (2) is to
generate a random secret key every time when the decrypted data was not
PKCS#1-conform. This way, the attacker would not get any timing
side-channel.

Please note that this is however not a valid countermeasure against the
specific modification of the <EncryptedData> part (3). The attacker
could still use a few millions of requests to decrypt the encrypted
symmetric key. Therefore, we recommend the usage of RSA-OAEP.
> 
> ]]
> 
> (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.
I suggest keeping these considerations since they clearly describe the
problems with application of different countermeasures.

I hope my comments are useful.

Regards
Juraj
> 
> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> 
> 
> 
> 

-- 
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 Friday, 30 December 2011 17:25:08 UTC