rfc3218.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 396 行 · 第 1/2 页

   simply truncates then the probability that a random block will appear
   to be properly padded is roughly 1/32.  If the receiver checks all
   the padding bytes, then the probability is 1/256 + (1/256^2) + ...
   (roughly 1/255).

2.3.  Countermeasures

2.3.1.  Careful Checking

   Even without countermeasures, sufficiently careful checking can go
   quite a long way to mitigating the success of the MMA.  If the
   receiving implementation also checks the length of the CEK and the
   parity bits (if available) AND responds identically to all such
   errors, the chances of a given M' being properly formatted are
   substantially decreased.  This increases the number of probe messages
   required to recover M. However, this sort of checking only increases
   the workfactor and does not eliminate the attack entirely because
   some messages will still be properly formatted up to the point of
   keylength.  However, the combination of all three kinds of checking
   (padding, length, parity bits) increases the number of messages to
   the point where the attack is impractical.






Rescorla                     Informational                      [Page 4]

RFC 3218      Preventing the Million Message Attack on CMS  January 2002


2.3.2.  Random Filling

   The simplest countermeasure is to treat misformatted messages as if
   they were properly PKCS-1 formatted.  When the victim detects an
   improperly formatted message, instead of returning an error he
   substitutes a randomly generated message.  In CMS, since the message
   is always a wrapped content-encryption key (CEK) the victim should
   simply substitute a randomly generated CEK of appropriate length and
   continue.  Eventually this will result in a decryption or signature
   verification error but this is exactly what would have happened if M'
   happened to be properly formatted but contained an incorrect CEK.
   Note that this approach also prevents the attacker from
   distinguishing various failure cases via timing since all failures
   return roughly the same timing behavior.  (The time required to
   generate the random-padding is negligible in almost all cases.  If an
   implementation has a very slow PRNG it can generate random padding
   for every message and simply discard it if the CEK decrypts
   correctly).

   In a layered implementation it's quite possible that the PKCS-1 check
   occurs at a point in the code where the length of the expected CEK is
   not known.  In that case the implementation must ensure that bad
   PKCS-1 padding and ok-looking PKCS-1 padding with an incorrect length
   CEK behave the same.  An easy way to do this is to also randomize
   CEKs that are of the wrong length or otherwise improperly formatted
   when they are processed at the layer that knows the length.

   Note: It is a mistake to use a fixed CEK because the attacker could
   then produce a CMS message encrypted with that CEK.  This message
   would decrypt properly (i.e. appear to be a completely valid CMS
   application to the receiver), thus allowing the attacker to determine
   that the PKCS-1 formatting was incorrect.  In fact, the new CEK
   should be cryptographically random, thus preventing the attacker from
   guessing the next "random" CEK to be used.

2.3.3.  OAEP

   Optimal Asymmetric Encryption Padding (OAEP) [OAEP, PKCS-1-v2] is
   another technique for padding a message into an RSA encryption block.
   Implementations using OAEP are not susceptible to the MMA.  However,
   OAEP is incompatible with PKCS-1.  Implementations of S/MIME and CMS
   must therefore continue to use PKCS-1 for the foreseeable future if
   they wish to communicate with current widely deployed
   implementations.  OAEP is being specified for use with AES keys in
   CMS so this provides an upgrade path to OAEP.






Rescorla                     Informational                      [Page 5]

RFC 3218      Preventing the Million Message Attack on CMS  January 2002


2.4.  Security Considerations

   This entire document describes how to avoid a certain class of
   attacks when performing PKCS-1 decryption with RSA.

3.  Acknowledgments

   Thanks to Burt Kaliski and Russ Housley for their extensive and
   helpful comments.

4.  References

   [CMS]         Housley, R., "Cryptographic Message Syntax", RFC 2630,
                 June 1999.

   [MMA]         Bleichenbacher, D., "Chosen Ciphertext Attacks against
                 Protocols based on RSA Encryption Standard PKCS #1",
                 Advances in Cryptology -- CRYPTO 98.

   [MMAUPDATE]   D. Bleichenbacher, B. Kaliski, and J. Staddon, "Recent
                 Results on PKCS #1: RSA Encryption Standard", RSA
                 Laboratories' Bulletin #7, June 26, 1998.

   [OAEP]        Bellare, M., Rogaway, P., "Optimal Asymmetric
                 Encryption Padding", Advances in Cryptology --
                 Eurocrypt 94.

   [PKCS-1-v1.5] Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5.",
                 RFC 2313, March 1998.

   [PKCS-1-v2]   Kaliski, B., "PKCS #1: RSA Encryption, Version 2.0",
                 RFC 2347, October 1998.

5.  Author's Address

   Eric Rescorla
   RTFM, Inc.
   2064 Edgewood Drive
   Palo Alto, CA 94303

   Phone: [phone]
   EMail: [e-mail]









Rescorla                     Informational                      [Page 6]

RFC 3218      Preventing the Million Message Attack on CMS  January 2002


6.  Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Rescorla                     Informational                      [Page 7]