- From: <Frederick.Hirsch@nokia.com>
- Date: Sat, 31 Dec 2011 19:55:04 +0000
- To: <juraj.somorovsky@rub.de>
- CC: <Frederick.Hirsch@nokia.com>, <public-xmlsec@w3.org>, <hal.lockhart@oracle.com>, <tlr@w3.org>
I've updated the editors draft as well as the Last Call publication draft. regards, Frederick Frederick Hirsch Nokia On Dec 31, 2011, at 9:11 AM, ext Juraj Somorovsky wrote: > Hi Frederick, > > that looks perfect. > > Thanks for the acknowledgement. > > Regards > Juraj > > On 12/31/2011 02:22 PM, Frederick.Hirsch@nokia.com wrote: >> Juraj >> >> >> Would the following addition be good addition >> >> after "Therefore, we recommend the usage of RSA-OAEP. " add >> >> "RSA-OAEP also has a risk of a chosen ciphertext attack [[OAEP-ATTACK]] which >> can be mitigated in security library implementations." >> >> I also would like to add to acknowledgements the following >> >> "The working group also acknowledges the contribution of Juraj Somorovsky raising the issue of the CBC chosen ciphertext attack and revising the security considerations of XML Encryption 1.1." >> >> suggestions welcome >> >> Thanks >> >> regards, Frederick >> >> Frederick Hirsch >> Nokia >> >> >> >> On Dec 31, 2011, at 6:50 AM, ext Juraj Somorovsky wrote: >> >>> Hi Frederick, >>> >>> I have checked it, the document looks good to me now. >>> >>> RFC3218 already mentions the possibilities for exploiting of the >>> Bleichenbacher attack in Section 2.2. It considers timing as well as >>> specific CBC-attacks in Section 2.2.1 (please note that the padding >>> scheme used in xmlenc is different, but the attack applies similarly). >>> >>> The countermeasures against these attacks are then introduced in Section >>> 2.3. I wanted however to explicitly mention that these countermeasures >>> cannot 100% thwart the CBC-based attacks as the attacker can guess >>> correct padding in the encrypted data. Guessing of the correct padding >>> takes 256 requests so the attack is 256-times slower but not infeasible. >>> It could be applied to some ciphertexts also if careful checking would >>> be used as introduced in 2.3.1. >>> >>> To complete the chosen ciphertext section, maybe you could also >>> explicitly mention that the developers should be aware of the chosen >>> ciphertext attack against RSA-OAEP[1] (I think that this attack should >>> be however thwarted in the most of the security libraries implicitly). >>> >>> Regards >>> Juraj >>> >>> [1] J.Manger: A Chosen Ciphertext Attack on RSA Optimal Asymmetric >>> Encryption Padding (OAEP) as Standardized in PKCS #1 v2.0 >>> >>> >>> On 12/30/2011 07:57 PM, Frederick.Hirsch@nokia.com wrote: >>>> Juraj >>>> >>>> These changes look good and improve the document. I have incorporated them into the editors draft with some minor editorial update (and will update the draft for Last Call publication). >>>> >>>> Perhaps you can please take a look to see if section 6.1 looks good to you now. >>>> >>>> http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.html#sec-chosen-ciphertext-attacks >>>> >>>> Is the text referring to RFC3218 applicable to all three bullet items? >>>> >>>> Thanks! >>>> >>>> regards, Frederick >>>> >>>> Frederick Hirsch >>>> Nokia >>>> >>>> >>>> >>>> On Dec 30, 2011, at 12:23 PM, ext Juraj Somorovsky wrote: >>>> >>>>> 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 >>>> >>> >>> -- >>> 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 >> > > -- > 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 Saturday, 31 December 2011 19:55:46 UTC