rfc3211.txt

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

Network Working Group                                         P. Gutmann
Request for Comments: 3211                        University of Auckland
Category: Standards Track                                  December 2001


                   Password-based Encryption for CMS

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   This document provides a method of encrypting data using user-
   supplied passwords and, by extension, any form of variable-length
   keying material which is not necessarily an algorithm-specific
   fixed-format key.  The Cryptographic Message Syntax data format does
   not currently contain any provisions for password-based data
   encryption.

1. Introduction

   This document describes a password-based content encryption mechanism
   for CMS.  This is implemented as a new RecipientInfo type and is an
   extension to the RecipientInfo types currently defined in RFC 2630.

   The format of the messages are described in ASN.1 [ASN1].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
   interpreted as described in RFC 2119.












Gutmann                     Standards Track                     [Page 1]

RFC 3211           Password-based Encryption for CMS       December 2001


1.1 Password-based Content Encryption

   CMS currently defined three recipient information types for public-
   key key wrapping (KeyTransRecipientInfo), conventional key wrapping
   (KEKRecipientInfo), and key agreement (KeyAgreeRecipientInfo).  The
   recipient information described here adds a fourth type,
   PasswordRecipientInfo, which provides for password-based key
   wrapping.

1.2 RecipientInfo Types

   The new recipient information type is an extension to the
   RecipientInfo type defined in section 6.2 of CMS, extending the types
   to:

      RecipientInfo ::= CHOICE {
        ktri KeyTransRecipientInfo,
        kari [1] KeyAgreeRecipientInfo,
        kekri [2] KEKRecipientInfo,
        pwri [3] PasswordRecipientinfo   -- New RecipientInfo type
        }

   Although the recipient information generation process is described in
   terms of a password-based operation (since this will be its most
   common use), the transformation employed is a general-purpose key
   derivation one which allows any type of keying material to be
   converted into a key specific to a particular content-encryption
   algorithm.  Since the most common use for password-based encryption
   is to encrypt files which are stored locally (rather than being
   transmitted across a network), the term "recipient" is somewhat
   misleading, but is used here because the other key transport
   mechanisms have always been described in similar terms.

1.2.1  PasswordRecipientInfo Type

   Recipient information using a user-supplied password or previously
   agreed-upon key is represented in the type PasswordRecipientInfo.
   Each instance of PasswordRecipientInfo will transfer the content-
   encryption key (CEK) to one or more recipients who have the
   previously agreed-upon password or key-encryption key (KEK).

      PasswordRecipientInfo ::= SEQUENCE {
        version CMSVersion,   -- Always set to 0
        keyDerivationAlgorithm
                         [0] KeyDerivationAlgorithmIdentifier OPTIONAL,
        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
        encryptedKey EncryptedKey }




Gutmann                     Standards Track                     [Page 2]

RFC 3211           Password-based Encryption for CMS       December 2001


   The fields of type PasswordRecipientInfo have the following meanings:

      version is the syntax version number.  It MUST be 0.  Details of
      the CMSVersion type are discussed in CMS [RFC2630], section
      10.2.5.

      keyDerivationAlgorithm identifies the key-derivation algorithm,
      and any associated parameters, used to derive the KEK from the
      user-supplied password.  If this field is absent, the KEK is
      supplied from an external source, for example a crypto token such
      as a smart card.

      keyEncryptionAlgorithm identifies the key-encryption algorithm,
      and any associated parameters, used to encrypt the CEK with the
      KEK.

      encryptedKey is the result of encrypting the content-encryption
      key with the KEK.

1.2.2 Rationale

   Password-based key wrapping is a two-stage process, a first stage in
   which a user-supplied password is converted into a KEK if required,
   and a second stage in which the KEK is used to encrypt a CEK.  These
   two stages are identified by the two algorithm identifiers.  Although
   the PKCS #5v2 standard [RFC2898] goes one step further to wrap these
   up into a single algorithm identifier, this design is particular to
   that standard and may not be applicable for other key wrapping
   mechanisms.  For this reason the two steps are specified separately.

   The current format doesn't provide any means of differentiating
   between multiple password recipient infos, which would occur for
   example if two passwords are used to encrypt the same data.
   Unfortunately there is a lack of existing practice in this area,
   since typical applications follow the model of encrypting data such
   as a file with a single password obtained from the user.  Without any
   clear requirements, an appropriate multiple password mechanism would
   be difficult (perhaps impossible) to define at this time.  If
   sufficient demand emerges then this may be addressed in a future
   version of this document, for example by adding an optional
   identification field of an appropriate form.

2 Supported Algorithms

   This section lists the algorithms that must be implemented.
   Additional algorithms that should be implemented are also included.





Gutmann                     Standards Track                     [Page 3]

RFC 3211           Password-based Encryption for CMS       December 2001


2.1 Key Derivation Algorithms

   These algorithms are used to convert the password into a KEK.  The
   key derivation algorithms are:

      KeyDerivationAlgorithmIdentifer ::= AlgorithmIdentifier

   Conforming implementations MUST include PBKDF2 [RFC2898].  Appendix B
   contains a more precise definition of the allowed algorithm type than
   is possible using 1988 ASN.1.

2.2 Key Encryption Algorithms

   These algorithms are used to encrypt the CEK using the derived KEK.
   The key encryption algorithms are:

      KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

   The PasswordRecipientInfo key encryption algorithm identifier is:

      id-alg-PWRI-KEK OBJECT IDENTIFIER ::= { iso(1) member-body(2)
        us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 9 }

   The AlgorithmIdentifier parameters field for this algorithm contains
   the KEK encryption algorithm used with the the key wrap algorithm
   specified in section 2.3.

   There is no requirement that the CEK algorithm match the KEK
   encryption algorithm, although care should be taken to ensure that,
   if different algorithms are used, they offer an equivalent level of
   security (for example wrapping a Triple-DES key with an RC2/40 key
   leads to a severe impedance mismatch in encryption strength).

   Conforming implementations MUST implement the id-alg-PWRI-KEK key
   wrap algorithm.  For the KEK encryption algorithms used by id-alg-
   PWRI-KEK, conforming implementations MUST include Triple-DES in CBC
   mode and MAY include other algorithms such as AES, CAST-128, RC5,
   IDEA, Skipjack, Blowfish, and encryption modes as required.
   Implementations SHOULD NOT include any KSG (keystream generator)
   ciphers such as RC4 or a block cipher in OFB mode, and SHOULD NOT
   include a block cipher in ECB mode.

2.2.1 Rationale

   The use of a level of indirection in specifying the
   KeyEncryptionAlgorithmIdentifier allows alternative wrapping
   algorithms to be used in the future.  If the KEK algorithm were
   specified directly in this field then any use of an alternative



Gutmann                     Standards Track                     [Page 4]

RFC 3211           Password-based Encryption for CMS       December 2001


   wrapping algorithm would require a change to the
   PasswordRecipientInfo structure rather than simply a change to the
   key encryption algorithm identifier.

   The parameter field for this algorithm identifier could be specified
   to default to triple-DES, however due to the confusion over NULL vs
   absent parameters in algorithm identifiers it's left explicit with no
   default value.

2.3.1 Key Wrap

   The key wrap algorithm encrypts a CEK with a KEK in a manner which
   ensures that every bit of plaintext effects every bit of ciphertext.
   This makes it equivalent in function to the package transform
   [PACKAGE] without requiring additional mechanisms or resources such
   as hash functions or cryptographically strong random numbers.  The
   key wrap algorithm is performed in two phases, a first phase which
   formats the CEK into a form suitable for encryption by the KEK, and a
   second phase which wraps the formatted CEK using the KEK.

   Key formatting: Create a formatted CEK block consisting of the
   following:

      1. A one-byte count of the number of bytes in the CEK.

      2. A check value containing the bitwise complement of the first
         three bytes of the CEK.

      3. The CEK.

      4. Enough random padding data to make the CEK data block a
         multiple of the KEK block length and at least two KEK cipher
         blocks long (the fact that 32 bits of count+check value are
         used means that even with a 40-bit CEK, the resulting data size
         will always be at least two (64-bit) cipher blocks long).  The
         padding data does not have to be cryptographically strong,
         although unpredictability helps.  Note that PKCS #5 padding is
         not used, since the length of the data is already known.

   The formatted CEK block then looks as follows:

      CEK byte count || check value || CEK || padding (if required)

   Key wrapping:

      1. Encrypt the padded key using the KEK.





Gutmann                     Standards Track                     [Page 5]

RFC 3211           Password-based Encryption for CMS       December 2001


      2. Without resetting the IV (that is, using the last ciphertext
         block as the IV), encrypt the encrypted padded key a second
         time.

   The resulting double-encrypted data is the EncryptedKey.

2.3.2 Key Unwrap

   Key unwrapping:

      1. Using the n-1'th ciphertext block as the IV, decrypt the n'th
         ciphertext block.

      2. Using the decrypted n'th ciphertext block as the IV, decrypt
         the 1st ... n-1'th ciphertext blocks.  This strips the outer
         layer of encryption.

      3. Decrypt the inner layer of encryption using the KEK.

   Key format verification:

      1a. If the CEK byte count is less than the minimum allowed key
          size (usually 5 bytes for 40-bit keys) or greater than the
          wrapped CEK length or not valid for the CEK algorithm (eg not
          16 or 24 bytes for triple DES), the KEK was invalid.

      1b. If the bitwise complement of the key check value doesn't match
          the first three bytes of the key, the KEK was invalid.

2.3.3 Example

   Given a content-encryption algorithm of Skipjack and a KEK algorithm
   of Triple-DES, the wrap steps are as follows: