[要約] RFC 6476は、Cryptographic Message Syntax (CMS) でのMessage Authentication Code (MAC) 暗号化の使用に関するものです。この文書の目的は、データの完全性と認証を保証するためにMACを使用する方法を定義することにあります。CMSは電子メール、証明書管理、その他のデータ交換システムで広く利用されており、RFC 6476はこれらのシステムにおけるデータ保護を強化するために貢献します。関連するRFCには、CMSを定義するRFC 5652や、他の暗号化技術に関するRFCが含まれます。RFC 6476は、セキュリティが重要な通信においてデータの機密性と完全性を確保するための重要な役割を果たします。
Internet Engineering Task Force (IETF) P. Gutmann
Request for Comments: 6476 University of Auckland
Category: Standards Track January 2012
ISSN: 2070-1721
Using Message Authentication Code (MAC) Encryption in the Cryptographic Message Syntax (CMS)
暗号化メッセージ構文（CMS）でのメッセージ認証コード（MAC）暗号化の使用
Abstract
概要
This document specifies the conventions for using Message Authentication Code (MAC) encryption with the Cryptographic Message Syntax (CMS) authenticated-enveloped-data content type. This mirrors the use of a MAC combined with an encryption algorithm that's already employed in IPsec, Secure Socket Layer / Transport Layer Security (SSL/TLS) and Secure SHell (SSH), which is widely supported in existing crypto libraries and hardware and has been extensively analysed by the crypto community.
このドキュメントでは、暗号化メッセージ構文（CMS）のauthenticated-enveloped-dataコンテンツタイプでメッセージ認証コード（MAC）暗号化を使用するための規則を規定しています。これは、IPsec、Secure Socket Layer / Transport Layer Security（SSL / TLS）、Secure SHell（SSH）ですでに採用されている暗号化アルゴリズムと組み合わせたMACの使用を反映しています。これは、既存の暗号ライブラリとハードウェアで広くサポートされており、暗号化コミュニティによって広範囲に分析されています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6476.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6476で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. Background ......................................................2
3. CMS Encrypt-and-Authenticate Overview ...........................3
3.1. Rationale ..................................................3
4. CMS Encrypt-and-Authenticate ....................................4
4.1. Encrypt-and-Authenticate Message Processing ................5
4.2. Rationale ..................................................6
4.3. Test Vectors ...............................................8
5. SMIMECapabilities Attribute ....................................12
6. Security Considerations ........................................12
7. IANA Considerations ............................................13
8. Acknowledgements ...............................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................14
This document specifies the conventions for using MAC-authenticated encryption with the Cryptographic Message Syntax (CMS) authenticated-enveloped-data content type. This mirrors the use of a MAC combined with an encryption algorithm that's already employed in IPsec, SSL/ TLS and SSH, which is widely supported in existing crypto libraries and hardware and has been extensively analysed by the crypto community.
このドキュメントでは、暗号化メッセージ構文（CMS）authentication-enveloped-dataコンテンツタイプでMAC認証暗号化を使用するための規則を指定します。これは、IPsec、SSL / TLS、SSHですでに採用されている暗号化アルゴリズムと組み合わせたMACの使用を反映しています。これは、既存の暗号ライブラリとハードウェアで広くサポートされており、暗号コミュニティによって広く分析されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Integrity-protected encryption is a standard feature of session-oriented security protocols like [IPsec], [SSH], and [TLS]. Until recently, however, integrity-protected encryption wasn't available for message-based security protocols like CMS, although [OpenPGP] added a form of integrity protection by encrypting a SHA-1 hash of the message alongside the message contents to provide authenticate-and-encrypt protection. Usability studies have shown that users expect encryption to provide integrity protection [Garfinkel], creating cognitive dissonance problems when the security mechanisms don't in fact provide this assurance.
完全性保護された暗号化は、[IPsec]、[SSH]、[TLS]などのセッション指向のセキュリティプロトコルの標準機能です。ただし、最近まで、CMSなどのメッセージベースのセキュリティプロトコルでは整合性保護された暗号化を利用できませんでしたが、[OpenPGP]は、メッセージのSHA-1ハッシュを暗号化して認証を提供することにより、整合性保護の形式を追加しました。および暗号化保護。ユーザビリティ調査は、ユーザーが暗号化により完全性保護を提供することを期待していることを示しており[Garfinkel]、セキュリティメカニズムが実際にこの保証を提供しない場合に認知的不協和問題が発生します。
This document applies the same encrypt-and-authenticate mechanism already employed in IPsec, SSH, and SSL/TLS to CMS (technically some of these actually use authenticate-and-encrypt rather than encrypt-and-authenticate, since what's authenticated is the plaintext and not the ciphertext). This mechanism is widely supported in existing crypto libraries and hardware and has been extensively analysed by the crypto community [EncryptThenAuth].
このドキュメントでは、IPsec、SSH、SSL / TLSですでに採用されているものと同じ暗号化と認証のメカニズムをCMSに適用します（技術的には、暗号化と認証ではなく実際に認証と暗号化を使用します。暗号文ではありません）。このメカニズムは、既存の暗号ライブラリとハードウェアで広くサポートされており、暗号コミュニティ[EncryptThenAuth]によって広範囲に分析されています。
Conventional CMS encryption uses a content-encryption key (CEK) to encrypt a message payload, with the CEK typically being in turn encrypted by a key-encryption key (KEK). Authenticated encryption requires two keys: one for encryption and a second one for authentication. Like other mechanisms that use authenticated encryption, this document employs a pseudorandom function (PRF) to convert a single block of keying material into the two keys required for encryption and authentication. This converts the standard CMS encryption operation:
従来のCMS暗号化では、コンテンツ暗号化キー（CEK）を使用してメッセージペイロードを暗号化します。CEKは通常、キー暗号化キー（KEK）によって暗号化されます。認証された暗号化には2つのキーが必要です。1つは暗号化用、もう1つは認証用です。認証された暗号化を使用する他のメカニズムと同様に、このドキュメントでは、疑似ランダム関数（PRF）を使用して、キー情報の単一ブロックを暗号化と認証に必要な2つのキーに変換します。これにより、標準のCMS暗号化操作が変換されます。
KEK( CEK ) || CEK( data )
KEK（CEK）||チェック（データ）
into:
に：
KEK( master_secret ) || MAC( CEK( data ) )
where the MAC key MAC-K and encryption key CEK-K are derived from the master_secret via:
ここで、MACキーMAC-Kおよび暗号化キーCEK-Kは、master_secretから次のように導出されます。
MAC-K := PRF( master_secret, "authentication" );
CEK-K := PRF( master_secret, "encryption" );
There are several possible means of deriving the two keys required for the encrypt-and-authenticate process from the single key normally provided by the key exchange or key transport mechanisms. Several of these, however, have security or practical issues. For example, any mechanism that uses the single exchanged key in its entirety for encryption (using, perhaps, PRF( key ) as the MAC key) can be converted back to unauthenticated data by removing the outer MAC layer and rewriting the CMS envelope back to plain EnvelopedData or EncryptedData. By applying the PRF intermediate step, any attempt at a rollback attack will result in a decryption failure.
暗号化と認証のプロセスに必要な2つのキーを、通常はキー交換またはキー転送メカニズムによって提供される単一のキーから導出するには、いくつかの可能な方法があります。ただし、これらのいくつかにはセキュリティまたは実用上の問題があります。たとえば、単一の交換されたキー全体を暗号化に使用するメカニズム（MACキーとしておそらくPRF（key）を使用）は、外側のMACレイヤーを削除し、CMSエンベロープを次のように書き直すことにより、認証されていないデータに変換できます。プレーンなEnvelopedDataまたはEncryptedData。 PRF中間ステップを適用することにより、ロールバック攻撃を試みると、復号化が失敗します。
The option chosen here -- the use of a PRF to derive the necessary sets of keying material from a master secret -- is well-established through its use in IPsec, SSH, and SSL/TLS and is widely supported in both crypto libraries and in encryption hardware.
ここで選択したオプション（マスターシークレットから必要なキー情報セットを取得するためのPRFの使用）は、IPsec、SSH、SSL / TLSでの使用を通じて十分に確立されており、両方の暗号ライブラリと暗号化ハードウェアで。
The PRF used is Password-Based Key Derivation Function 2 (PBKDF2) because its existing use in CMS makes it the most obvious candidate for such a function. In the future, if a universal PRF -- for example, [HKDF] -- is adopted, then this can be substituted for PBKDF2 by specifying it in the prfAlgorithm field covered in Section 4.
使用されるPRFは、パスワードベースのキー導出関数2（PBKDF2）です。これは、CMSでの既存の使用により、そのような関数の最も明白な候補になるためです。将来、ユニバーサルPRF（たとえば、[HKDF]）が採用された場合、セクション4で説明されているprfAlgorithmフィールドで指定することにより、PBKDF2の代わりに使用できます。
The resulting processing operations consist of a combination of the operations used for the existing CMS content types EncryptedData and AuthenticatedData, allowing them to be implemented relatively simply using existing code.
結果として生じる処理操作は、既存のCMSコンテンツタイプEncryptedDataおよびAuthenticatedDataに使用される操作の組み合わせで構成され、既存のコードを使用して比較的簡単に実装できるようにします。
The encrypt-and-authenticate mechanism is implemented within the existing CMS RecipientInfo framework by defining a new pseudo-algorithm type, authEnc, which is used in place of a monolithic encrypt and hash algorithm. The RecipientInfo is used as a key container for the master secret used by the pseudo-algorithm from which the encryption and authentication keys for existing single-purpose encrypt-only and MAC-only algorithms are derived. Thus, instead of using the RecipientInfo to communicate (for example) an AES or HMAC-SHA1 key, it communicates a master secret from which the required AES encryption and HMAC-SHA1 authentication keys are derived.
暗号化と認証のメカニズムは、モノリシック暗号化とハッシュアルゴリズムの代わりに使用される新しい擬似アルゴリズムタイプauthEncを定義することにより、既存のCMS RecipientInfoフレームワーク内に実装されます。 RecipientInfoは、既存の単一目的の暗号化専用およびMAC専用アルゴリズムの暗号化および認証キーの派生元である疑似アルゴリズムによって使用されるマスターシークレットのキーコンテナーとして使用されます。したがって、RecipientInfoを使用して（たとえば）AESまたはHMAC-SHA1キーを通信する代わりに、必要なAES暗号化およびHMAC-SHA1認証キーが導出されるマスターシークレットを通信します。
The authEnc pseudo-algorithm comes in two forms: one conveying 128 bits of keying material and one conveying 256 bits:
authEnc疑似アルゴリズムには2つの形式があります。1つは128ビットのキー素材を伝達するもの、もう1つは256ビットを伝達するものです。
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-alg OBJECT IDENTIFIER ::= { id-smime 3 }
id-alg-authEnc-128 OBJECT IDENTIFIER ::= { id-alg 15 }
id-alg-authEnc-256 OBJECT IDENTIFIER ::= { id-alg 16 }
The algorithm parameters are as follows:
アルゴリズムパラメータは次のとおりです。
AuthEncParams ::= SEQUENCE {
prfAlgorithm [0] AlgorithmIdentifier DEFAULT PBKDF2,
encAlgorithm AlgorithmIdentifier,
macAlgorithm AlgorithmIdentifier
}
prfAlgorithm is the PRF algorithm used to convert the master secret into the encryption and MAC keys. The default PRF is [PBKDF2], which in turn has a default PRF algorithm of HMAC-SHA1. When this default setting is used, the PBKDF2-params 'salt' parameter is an empty string, and the 'iterationCount' parameter is one, turning the KDF into a pure PRF.
prfAlgorithmは、マスターシークレットを暗号化およびMACキーに変換するために使用されるPRFアルゴリズムです。デフォルトのPRFは[PBKDF2]であり、これにはHMAC-SHA1のデフォルトのPRFアルゴリズムがあります。このデフォルト設定を使用すると、PBKDF2-paramsの「salt」パラメーターは空の文字列になり、「iterationCount」パラメーターは1になり、KDFが純粋なPRFに変わります。
encAlgorithm is the encryption algorithm and associated parameters to be used to encrypt the content.
encAlgorithmは、コンテンツの暗号化に使用される暗号化アルゴリズムと関連パラメーターです。
macAlgorithm is the MAC algorithm and associated parameters to be used to authenticate/integrity-protect the content.
macAlgorithmは、コンテンツの認証/完全性保護に使用されるMACアルゴリズムと関連パラメーターです。
When the prfAlgorithm AlgorithmIdentifier is used in conjunction with PBKDF2 to specify a PRF other than the default PBKDF2-with-HMAC-SHA1 one, the PBKDF2-params require that two additional algorithm parameters be specified. The 'salt' parameter MUST be an empty (zero-length) string, and the 'iterationCount' parameter MUST be one, since these values aren't used in the PRF process. In their encoded form as used for the PBKDF2-params, these two parameters have the value 08 00 02 01 01.
prfAlgorithm AlgorithmIdentifierをPBKDF2と組み合わせて使用して、デフォルトのPBKDF2-with-HMAC-SHA1以外のPRFを指定する場合、PBKDF2-paramsには2つの追加のアルゴリズムパラメーターを指定する必要があります。これらの値はPRFプロセスで使用されないため、「salt」パラメーターは空（長さがゼロ）のストリングでなければならず、「iterationCount」パラメーターは1でなければなりません。 PBKDF2-paramsに使用されるエンコードされた形式では、これらの2つのパラメーターの値は08 00 02 01 01です。
As a guideline for authors specifying the use of PRFs other than PBKDF2, any additional parameters such as salts, tags, and identification strings SHOULD be set to empty strings, and any iteration count SHOULD be set to one.
PBKDF2以外のPRFの使用を指定する作成者のガイドラインとして、ソルト、タグ、識別文字列などの追加のパラメーターは空の文字列に設定し、反復回数を1に設定する必要があります（SHOULD）。
The randomly generated master secret to be communicated via the RecipientInfo(s) is converted to separate encryption and authentication keys and applied to the encrypt-and-authenticate process as follows. The notation "PRF( key, salt, iterations )" is used to denote an application of the PRF to the given keying value and salt, for the given number of iterations: 1. The MAC algorithm key is derived from the master secret via:
RecipientInfo（s）を介して通信されるランダムに生成されたマスターシークレットは、次のように個別の暗号化キーと認証キーに変換され、暗号化および認証プロセスに適用されます。 「PRF（key、salt、iterations）」という表記は、指定された反復回数に対する、指定されたキーイング値およびソルトへのPRFの適用を示すために使用されます。1. MACアルゴリズムキーは、以下を介してマスターシークレットから導出されます。
MAC-K ::= PRF( master_secret, "authentication", 1 );
2. The encryption algorithm key is derived from the master secret via:
2. 暗号化アルゴリズムキーは、マスターシークレットから次の方法で取得されます。
Enc-K ::= PRF( master_secret, "encryption", 1 );
3. The data is processed as described in [AuthEnv], and specifically since the mechanisms used are a union of EncryptedData and AuthenticatedData, as per [CMS]. The one exception to this is that the EncryptedContentInfo.ContentEncryptionAlgorithmIdentifier data is MACed before the encrypted content is MACed. The EncryptedData processing is applied to the data first, and then the AuthenticatedData processing is applied to the result, so that the nesting is as follows:
3. データは、[AuthEnv]で説明されているように処理されます。特に、使用されるメカニズムは、[CMS]のように、EncryptedDataとAuthenticatedDataの結合であるためです。これに対する1つの例外は、暗号化されたコンテンツがMAC化される前に、EncryptedContentInfo.ContentEncryptionAlgorithmIdentifierデータがMAC化されることです。 EncryptedData処理が最初にデータに適用され、次にAuthenticatedData処理が結果に適用されるため、ネストは次のようになります。
MAC( contentEncrAlgoID || encrypt( content ) );
4. If authenticated attributes are present, then they are encoded as described in [AuthEnv] and MACed after the encrypted content, so that the processing is as follows:
4. 認証された属性が存在する場合、[AuthEnv]で説明されているようにエンコードされ、暗号化されたコンテンツの後にMAC処理されるため、処理は次のようになります。
MAC( contentEncrAlgoID || encrypt( content ) || authAttr );
When choosing between encrypt-and-authenticate and authenticate-and-encrypt, the more secure option is encrypt-and-authenticate. There has been extensive analysis of this in the literature; the best coverage is probably [EncryptThenAuth].
暗号化して認証するか、認証して暗号化するかを選択する場合、より安全なオプションは暗号化して認証することです。文献ではこれについて広範な分析が行われています。最良のカバレッジはおそらく[EncryptThenAuth]です。
The EncryptedContentInfo.ContentEncryptionAlgorithmIdentifier is the SEQUENCE containing the id-alg-authEnc-128/id-alg-authEnc-256 OBJECT IDENTIFIER and its associated AuthEncParams. This data is MACed exactly as encoded, without any attempt to re-code it into a canonical form like DER.
EncryptedContentInfo.ContentEncryptionAlgorithmIdentifierは、id-alg-authEnc-128 / id-alg-authEnc-256 OBJECT IDENTIFIERとそれに関連付けられたAuthEncParamsを含むシーケンスです。このデータは、DERのような正規形式に再コード化することなく、エンコードされたとおりにMAC処理されます。
The EncryptedContentInfo.ContentEncryptionAlgorithmIdentifier must be protected alongside the encrypted content; otherwise, an attacker could manipulate the encrypted data indirectly by manipulating the encryption algorithm parameters, which wouldn't be detected through MACing the encrypted content alone. For example, by changing the encryption IV, it's possible to modify the results of the decryption after the encrypted data has been verified via a MAC check.
EncryptedContentInfo.ContentEncryptionAlgorithmIdentifierは、暗号化されたコンテンツと一緒に保護する必要があります。それ以外の場合、攻撃者は暗号化アルゴリズムのパラメーターを操作することにより、暗号化されたデータを間接的に操作する可能性があります。これは、暗号化されたコンテンツのみをMAC処理しても検出されません。たとえば、暗号化IVを変更することにより、暗号化されたデータがMACチェックを介して検証された後に、復号化の結果を変更することが可能です。
The authEnc pseudo-algorithm has two "key sizes" rather than the one-size-fits-all that the PRF impedance-matching would provide. This is done to address real-world experience in the use of AES keys, where users demanded AES-256 alongside AES-128 because of some perception that the former was "twice as good" as the latter. Providing an option for keys that go to 11 avoids potential user acceptance problems when someone notices that the authEnc pseudo-key has "only" 128 bits when they expect their AES keys to be 256 bits long.
authEnc疑似アルゴリズムには、PRFインピーダンスマッチングが提供するone-size-fits-allではなく、2つの「キーサイズ」があります。これは、AESキーの使用における実際の経験に対処するために行われます。ユーザーは、AES-128と一緒にAES-256を要求しました。 11になるキーのオプションを提供すると、AESキーの長さが256ビットであると予想されるときにauthEnc疑似キーの128ビットが「のみ」であることに誰かが気付いた場合に、ユーザーの受け入れに関する潜在的な問題を回避できます。
Using a fixed-length key rather than making it a user-selectable parameter is done for the same reason as AES's quantised key lengths: there's no benefit to allowing, say, 137-bit keys over basic 128- and 256-bit lengths; it adds unnecessary complexity; if the lengths are user-defined, then there'll always be someone who wants keys that go up to 12. Providing a choice of two commonly used lengths gives users the option of choosing a "better" key size should they feel the need, while not overloading the system with unneeded flexibility.
ユーザーが選択可能なパラメーターにするのではなく、固定長キーを使用するのは、AESの量子化キー長と同じ理由で行われます。たとえば、基本的な128ビット長と256ビット長で137ビットキーを許可してもメリットはありません。不要な複雑さを追加します。長さがユーザー定義の場合、常に最大12のキーが必要な人がいます。一般的に使用される2つの長さの選択肢を提供することで、ユーザーは必要に応じて「より良い」キーサイズを選択できます。不要な柔軟性でシステムに過負荷をかけない。
The use of the PRF AlgorithmIdentifier presents some problems, because it's usually not specified in a manner that allows it to be easily used as a straight KDF. For example, PBKDF2 has the following parameters:
PRF AlgorithmIdentifierを使用すると、通常はストレートKDFとして簡単に使用できるように指定されないため、いくつかの問題が発生します。たとえば、PBKDF2には次のパラメータがあります。
PBKDF2-params ::= SEQUENCE {
salt OCTET STRING,
iterationCount INTEGER (1..MAX),
prf AlgorithmIdentifier {{PBKDF2-PRFs}}
DEFAULT algid-hmacWithSHA1
}
of which only the prf AlgorithmIdentifier is used here. In order to avoid having to define new AlgorithmIdentifiers for each possible PRF, this specification sets any parameters not required for KDF functionality to no-op values. In the case of PBKDF2, this means that the salt has length zero and the iteration count is set to one, with only the prf AlgorithmIdentifier playing a part in the processing. Although it's not possible to know what form other PRFs-as-KDFs will take, a general note for their application within this specification is that any non-PRF parameters should similarly be set to no-op values.
ここでは、prf AlgorithmIdentifierのみが使用されます。可能なPRFごとに新しいAlgorithmIdentifiersを定義する必要を回避するために、この仕様では、KDF機能に不要なすべてのパラメーターをno-op値に設定します。 PBKDF2の場合、これはソルトの長さがゼロであり、反復カウントが1に設定されていることを意味します。prfAlgorithmIdentifierのみが処理に関与します。他のPRF-as-KDFがどのような形式になるかを知ることはできませんが、この仕様内でのそれらのアプリケーションに関する一般的な注意事項は、非PRFパラメーターは同様にno-op値に設定する必要があるということです。
Specifying a MAC key size gets a bit tricky; most MAC algorithms have some de facto standard key size, and for HMAC algorithms, this is usually the same as the hash output size. For example, for HMAC-MD5, it's 128 bits; for HMAC-SHA1, it's 160 bits; and for HMAC-SHA256, it's 256 bits. Other MAC algorithms also have de facto standard key sizes. For example, for AES-based MACs, it's the AES key size -- 128 bits for AES-128 and 256 bits for AES-256. This situation makes it difficult to specify the key size in a normative fashion, since it's dependent on the algorithm type that's being used. If there is any ambiguity over which key size should be used, then it's RECOMMENDED that either the size be specified explicitly in the macAlgorithm AlgorithmIdentifier or that an RFC or similar standards document be created that makes the key sizes explicit.
MACキーのサイズを指定するのは少し難しいです。ほとんどのMACアルゴリズムには、事実上の標準の鍵サイズがあり、HMACアルゴリズムの場合、これは通常、ハッシュ出力サイズと同じです。たとえば、HMAC-MD5の場合、128ビットです。 HMAC-SHA1の場合は160ビットです。 HMAC-SHA256の場合は256ビットです。他のMACアルゴリズムにも、事実上の標準の鍵サイズがあります。たとえば、AESベースのMACの場合、これはAESキーサイズです。AES-128の場合は128ビット、AES-256の場合は256ビットです。この状況では、使用されているアルゴリズムタイプに依存するため、規範的な方法でキーサイズを指定することが困難になります。使用するキーのサイズにあいまいさが存在する場合は、macAlgorithm AlgorithmIdentifierでサイズを明示的に指定するか、キーサイズを明示するRFCまたは類似の標準ドキュメントを作成することをお勧めします。
As with other uses of PRFs for crypto impedance-matching in protocols, like IPsec, SSL/TLS, and SSH, the amount of input to the PRF generally doesn't match the amount of output. The general philosophical implications of this are covered in various analyses of the properties and uses of PRFs. If you're worried about this, then you can try and approximately match the authEnc "key size" to the key size of the encryption algorithm being used, although even there, a perfect match for algorithms like Blowfish (448 bits) or RC5 (832 bits) is going to be difficult.
IPsec、SSL / TLS、SSHなどのプロトコルでの暗号インピーダンスマッチングのための他のPRFの使用と同様に、PRFへの入力の量は通常、出力の量と一致しません。これの一般的な哲学的影響は、PRFの特性と用途のさまざまな分析でカバーされています。これが心配な場合は、authEncの「キーサイズ」を、使用している暗号化アルゴリズムのキーサイズにほぼ一致させることができますが、Blowfish（448ビット）やRC5（ 832ビット）は難しいでしょう。
The term "master secret" comes from its use in SSL/TLS, which uses a similar PRF-based mechanism to convert its master_secret value into encryption and MAC keys (as do SSH and IPsec). The master_secret value isn't a key in the conventional sense, but merely a secret value that's then used to derive two (or, in the cases of SSL/TLS, SSH, and IPsec, several) keys and related cryptovariables.
「マスターシークレット」という用語は、同様のPRFベースのメカニズムを使用してmaster_secret値を暗号化およびMACキー（SSHおよびIPsecと同様）に変換するSSL / TLSでの使用に由来します。 master_secret値は従来の意味でのキーではなく、2つの（またはSSL / TLS、SSH、およびIPsecの場合はいくつかの）キーと関連する暗号変数を導出するために使用される単なる秘密値です。
Apart from the extra step added to key management, all of the processing is already specified as part of the definition of the standard CMS content-types Encrypted/EnvelopedData and AuthenticatedData. This significantly simplifies both the specification and the implementation task, as no new content-processing mechanisms are introduced.
キー管理に追加された追加のステップとは別に、すべての処理は標準のCMSコンテンツタイプEncrypted / EnvelopedDataおよびAuthenticatedDataの定義の一部としてすでに指定されています。これにより、新しいコンテンツ処理メカニズムが導入されないため、仕様と実装タスクの両方が大幅に簡略化されます。
The following test vectors may be used to verify an implementation of MAC-authenticated encryption. This represents a text string encrypted and authenticated using the ever-popular password "password" via CMS PasswordRecipientInfo. The encryption algorithm used for the first value is triple DES, whose short block size (compared to AES) makes it easier to corrupt arbitrary bytes for testing purposes within the self-healing Cipher Block Chaining (CBC) mode, which will result in correct decryption but a failed MAC check. The encryption algorithm used for the second value is AES.
次のテストベクタを使用して、MAC認証暗号化の実装を検証できます。これは、CMS PasswordRecipientInfoを介して定評のあるパスワード「password」を使用して暗号化および認証されたテキスト文字列を表します。最初の値に使用される暗号化アルゴリズムはトリプルDESであり、（AESと比較して）ブロックサイズが短いため、自己修復型暗号ブロックチェーン（CBC）モード内でテスト目的で任意のバイトを破損しやすくなり、正しい復号が行われます。しかし、失敗したMACチェック。 2番目の値に使用される暗号化アルゴリズムはAESです。
For the triple DES-encrypted data, corrupting a byte at positions 192-208 can be used to check that payload-data corruption is detected, and corrupting a byte at positions 168-174 can be used to check that metadata corruption is detected. The corruption in these byte ranges doesn't affect normal processing and so wouldn't normally be detected.
トリプルDESで暗号化されたデータの場合、192〜280のバイトの破損を使用してペイロードデータの破損が検出されたことを確認し、168〜174のバイトの破損を使用してメタデータの破損が検出されたことを確認できます。これらのバイト範囲の破損は通常の処理には影響しないため、通常は検出されません。
The test data has the following characteristics:
テストデータには次の特性があります。
version is set to 0.
バージョンは0に設定されます。
originatorInfo isn't needed and is omitted.
originatorInfoは不要であり、省略されます。
recipientInfo uses passwordRecipientInfo to allow easy testing with a fixed text string.
recipientInfoはpasswordRecipientInfoを使用して、固定テキスト文字列で簡単にテストできるようにします。
authEncryptedContentInfo uses the authEnc128 pseudo-algorithm with a key of 128 bits used to derive triple DES/AES and HMAC-SHA1 keys.
authEncryptedContentInfoは、トリプルDES / AESおよびHMAC-SHA1鍵の導出に使用される128ビットの鍵を持つauthEnc128擬似アルゴリズムを使用します。
authAttrs aren't used and are omitted.
authAttrsは使用されず、省略されます。
mac is the 20-byte HMAC-SHA1 MAC value.
macは、20バイトのHMAC-SHA1 MAC値です。
unauthAttrs aren't used and are omitted.
unauthAttrsは使用されず、省略されます。
0 227: SEQUENCE {
3 11: OBJECT IDENTIFIER id-ct-authEnvelopedData
(1 2 840 113549 1 9 16 1 23)
16 211: [0] {
19 208: SEQUENCE {
22 1: INTEGER 0
25 97: SET {
27 95: [3] {
29 1: INTEGER 0
32 27: [0] {
34 9: OBJECT IDENTIFIER pkcs5PBKDF2
(1 2 840 113549 1 5 12)
45 14: SEQUENCE {
47 8: OCTET STRING B7 EB 23 A7 6B D2 05 16
57 2: INTEGER 5000
: }
: }
61 35: SEQUENCE {
63 11: OBJECT IDENTIFIER pwriKEK
(1 2 840 113549 1 9 16 3 9)
76 20: SEQUENCE {
78 8: OBJECT IDENTIFIER des-EDE3-CBC
(1 2 840 113549 3 7)
88 8: OCTET STRING 66 91 02 45 6B 73 BB 99
: }
: }
98 24: OCTET STRING
: 30 A3 7A B5 D8 F2 87 50 EC 41 04 AE 89 99 26 F0
: 2E AE 4F E3 F3 52 2B A3
: }
: }
124 82: SEQUENCE {
126 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
137 51: SEQUENCE {
139 11: OBJECT IDENTIFIER authEnc128
(1 2 840 113549 1 9 16 3 15)
152 36: SEQUENCE {
154 20: SEQUENCE {
156 8: OBJECT IDENTIFIER des-EDE3-CBC
(1 2 840 113549 3 7)
166 8: OCTET STRING D2 D0 81 71 4D 3D 9F 11
: }
176 12: SEQUENCE {
178 8: OBJECT IDENTIFIER hmacSHA (1 3 6 1 5 5 8 1 2)
188 0: NULL
: }
: }
: }
190 16: [0] 3A C6 06 61 41 5D 00 7D 11 35 CD 69 E1 56 CA 10
: }
208 20: OCTET STRING
: 33 65 E8 F0 F3 07 06 86 1D A8 47 2C 6D 3A 1D 94
: 21 40 64 7E
: }
: }
: }
-----BEGIN PKCS7-----
MIHjBgsqhkiG9w0BCRABF6CB0zCB0AIBADFho18CAQCgGwYJKoZIhvcNAQUMMA4E
CLfrI6dr0gUWAgITiDAjBgsqhkiG9w0BCRADCTAUBggqhkiG9w0DBwQIZpECRWtz
u5kEGDCjerXY8odQ7EEEromZJvAurk/j81IrozBSBgkqhkiG9w0BBwEwMwYLKoZI
hvcNAQkQAw8wJDAUBggqhkiG9w0DBwQI0tCBcU09nxEwDAYIKwYBBQUIAQIFAIAQ
OsYGYUFdAH0RNc1p4VbKEAQUM2Xo8PMHBoYdqEcsbTodlCFAZH4=
-----END PKCS7-----
0 253: SEQUENCE {
3 11: OBJECT IDENTIFIER id-ct-authEnvelopedData
(1 2 840 113549 1 9 16 1 23)
16 237: [0] {
19 234: SEQUENCE {
22 1: INTEGER 0
25 114: SET {
27 112: [3] {
29 1: INTEGER 0
32 27: [0] {
34 9: OBJECT IDENTIFIER pkcs5PBKDF2
(1 2 840 113549 1 5 12)
45 14: SEQUENCE {
47 8: OCTET STRING E7 B7 87 DF 82 1D 12 CC
57 2: INTEGER 5000
: }
: }
61 44: SEQUENCE {
63 11: OBJECT IDENTIFIER pwriKEK
(1 2 840 113549 1 9 16 3 9)
76 29: SEQUENCE {
78 9: OBJECT IDENTIFIER aes128-CBC
(2 16 840 1 101 3 4 1 2)
89 16: OCTET STRING
: 11 D9 5C 52 0A 3A BF 22 B2 30 70 EF F4 7D 6E F6
: }
: }
107 32: OCTET STRING
: 18 39 22 27 C3 C2 2C 2A A6 9F 2A B0 77 24 75 AA
: D8 58 9C CD BB 4C AE D3 0D C2 CB 1D 83 94 6C 37
: }
: }
141 91: SEQUENCE {
143 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
154 60: SEQUENCE {
156 11: OBJECT IDENTIFIER authEnc128
(1 2 840 113549 1 9 16 3 15)
169 45: SEQUENCE {
171 29: SEQUENCE {
173 9: OBJECT IDENTIFIER aes128-CBC
(2 16 840 1 101 3 4 1 2)
184 16: OCTET STRING
: B7 25 02 76 84 3C 58 1B A5 30 E2 40 27 EE C3 06
: }
202 12: SEQUENCE {
204 8: OBJECT IDENTIFIER hmacSHA (1 3 6 1 5 5 8 1 2)
214 0: NULL
: }
: }
: }
216 16: [0] 98 36 0F 0C 79 62 36 B5 2D 2D 9E 1C 62 85 1E 10
: }
234 20: OCTET STRING
: 88 A4 C1 B2 BA 78 1B CA F9 14 B0 E5 FC D1 8D F8
: 02 E2 B2 9E
: }
: }
: }
-----BEGIN PKCS7-----
MIH9BgsqhkiG9w0BCRABF6CB7TCB6gIBADFyo3ACAQCgGwYJKoZIhvcNAQUMMA4E
COe3h9+CHRLMAgITiDAsBgsqhkiG9w0BCRADCTAdBglghkgBZQMEAQIEEBHZXFIK
Or8isjBw7/R9bvYEIBg5IifDwiwqpp8qsHckdarYWJzNu0yu0w3Cyx2DlGw3MFsG
CSqGSIb3DQEHATA8BgsqhkiG9w0BCRADDzAtMB0GCWCGSAFlAwQBAgQQtyUCdoQ8
WBulMOJAJ+7DBjAMBggrBgEFBQgBAgUAgBCYNg8MeWI2tS0tnhxihR4QBBSIpMGy
ungbyvkUsOX80Y34AuKyng==
-----END PKCS7-----
An S/MIME client SHOULD announce the set of cryptographic functions that it supports by using the SMIMECapabilities attribute [SMIME]. If the client wishes to indicate support for MAC-authenticated encryption, the capabilities attribute MUST contain the authEnc128 and/or authEnc256 OID specified above with algorithm parameters ABSENT. The other algorithms used in the authEnc algorithm, such as the MAC and encryption algorithm, are selected based on the presence of these algorithms in the SMIMECapabilities attribute or by mutual agreement.
S / MIMEクライアントは、SMIMECapabilities属性[SMIME]を使用して、サポートする暗号化機能のセットを通知する必要があります（SHOULD）。クライアントがMAC認証された暗号化のサポートを示すことを望む場合、機能属性はアルゴリズムパラメータABSENTで上で指定されたauthEnc128および/またはauthEnc256 OIDを含まなければなりません（MUST）。 MACや暗号化アルゴリズムなど、authEncアルゴリズムで使用される他のアルゴリズムは、SMIMECapabilities属性内のこれらのアルゴリズムの存在に基づいて、または相互の合意によって選択されます。
Unlike other CMS authenticated-data mechanisms, such as SignedData and AuthenticatedData, AuthEnv's primary transformation isn't authentication but encryption; so AuthEnvData may decrypt successfully (in other words, the primary data transformation present in the mechanism will succeed), but the secondary function of authentication using the MAC value that follows the encrypted data could still fail. This can lead to a situation in which an implementation might output decrypted data before it reaches and verifies the MAC value. In other words, decryption is performed inline and the result is available immediately, while the authentication result isn't available until all of the content has been processed. If the implementation prematurely provides data to the user and later comes back to inform them that the earlier data was, in retrospect, tainted, this may cause users to act prematurely on the tainted data.
SignedDataやAuthenticatedDataなどの他のCMS認証データメカニズムとは異なり、AuthEnvの主な変換は認証ではなく暗号化です。そのため、AuthEnvDataは正常に復号化できます（つまり、メカニズムに存在する主要なデータ変換は成功します）が、暗号化されたデータに続くMAC値を使用した認証の二次機能は依然として失敗する可能性があります。これにより、MAC値に到達して検証する前に、実装が復号化されたデータを出力する可能性があります。つまり、復号化はインラインで実行され、結果はすぐに利用できますが、認証結果はすべてのコンテンツが処理されるまで利用できません。実装がデータを時期尚早にユーザーに提供し、後で戻って以前のデータが汚染されていたことをユーザーに通知した場合、これによりユーザーは汚染されたデータに対して時期尚早に行動する可能性があります。
This situation could occur in a streaming implementation where data has to be made available as soon as possible (so that the initial plaintext is emitted before the final ciphertext and MAC value are read), or one where the quantity of data involved rules out buffering the recovered plaintext until the MAC value can be read and verified. In addition, an implementation that tries to be overly helpful may treat missing non-payload trailing data as non-fatal, allowing an attacker to truncate the data somewhere before the MAC value and thereby defeat the data authentication. This is complicated even further by the fact that an implementation may not be able to determine, when it encounters truncated data, whether the remainder (including the MAC value) will arrive presently (a non-failure) or whether it's been truncated by an attacker and should therefore be treated as a MAC failure. (Note that this same issue affects other types of data authentication like signed and MACed data as well, since an over-optimistic implementation may return data to the user before checking for a verification failure is possible.)
この状況は、データをできるだけ早く利用可能にする必要があるストリーミング実装（最終的な暗号文とMAC値が読み取られる前に最初の平文が送信されるようにする）で発生する可能性があります。 MAC値を読み取って検証できるようになるまでプレーンテキストを復元しました。さらに、過度に役に立とうとする実装では、ペイロードの後続の欠落データを致命的でないものとして扱い、攻撃者がMAC値の前のどこかでデータを切り捨てて、データ認証を無効にする可能性があります。これは、切り捨てられたデータに遭遇したときに、残り（MAC値を含む）が現在到着するか（失敗ではない）、または攻撃者によって切り捨てられたかどうかを実装が判別できない場合があるという事実により、さらに複雑になります。したがって、MAC障害として処理する必要があります。 （この同じ問題は、署名されたデータやMACedデータなどの他のタイプのデータ認証にも影響を与えることに注意してください。過度に楽観的な実装では、検証エラーをチェックする前にユーザーにデータが返される可能性があるためです。）
The exact solution to these issues is somewhat implementation-specific, with some suggested mitigations being as follows: implementations should buffer the entire message if possible and verify the MAC before performing any decryption. If this isn't possible due to streaming or message-size constraints, then implementations should consider breaking long messages into a sequence of smaller ones, each of which can be processed atomically as above. If even this isn't possible, then implementations should make obvious to the caller or user that an authentication failure has occurred and that the previously returned or output data shouldn't be used. Finally, any data-formatting problem, such as obviously truncated data or missing trailing data, should be treated as a MAC verification failure even if the rest of the data was processed correctly.
これらの問題の正確な解決策は実装に固有であり、推奨される緩和策は次のとおりです。実装は、可能な場合はメッセージ全体をバッファリングし、復号化を実行する前にMACを確認する必要があります。ストリーミングまたはメッセージサイズの制約のためにこれが不可能な場合、実装では、長いメッセージを一連の小さなメッセージに分割することを検討する必要があります。それぞれを上記のようにアトミックに処理できます。これが不可能な場合でも、認証の失敗が発生したこと、および以前に返されたデータや出力されたデータを使用してはならないことを呼び出し側またはユーザーに明らかにする必要があります。最後に、明らかに切り捨てられたデータや末尾のデータが欠落しているなどのデータ形式の問題は、残りのデータが正しく処理されたとしても、MAC検証エラーとして処理する必要があります。
This document contains two algorithm identifiers defined by the S/MIME Working Group Registrar in an arc delegated by RSA to the S/MIME Working Group: iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0).
このドキュメントには、RSAによってS / MIMEワーキンググループに委任された弧でS / MIMEワーキンググループレジストラーによって定義された2つのアルゴリズム識別子が含まれています。iso（1）member-body（2）us（840）rsadsi（113549）pkcs（1 ）pkcs-9（9）smime（16）modules（0）。
The author would like to thank Jim Schaad and the members of the S/MIME mailing list for their feedback on this document, and David Ireland for help with the test vectors.
著者は、このドキュメントに関するフィードバックを提供してくれたJim SchaadとS / MIMEメーリングリストのメンバー、およびテストベクトルの支援をしてくれたDavid Irelandに感謝します。
[AuthEnv] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, November 2007.
[AuthEnv] Housley、R。、「Cryptographic Message Syntax（CMS）Authenticated-Enveloped-Data Content Type」、RFC 5083、2007年11月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[CMS] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、2009年9月。
[PBKDF2] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2", RFC 2898, September 2000.
[PBKDF2] Kaliski、B。、「PKCS＃5：Password-Based Cryptography Specification Version 2」、RFC 2898、2000年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[SMIME] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、2010年1月。
[EncryptThenAuth] Krawczyk, H., "The Order of Encryption and Authentication for Protecting Communications (or: How Secure Is SSL?)", Springer-Verlag LNCS 2139, August 2001.
[EncryptThenAuth] Krawczyk、H。、「通信を保護するための暗号化と認証の順序（または、SSLの安全性はどうですか？）」、Springer-Verlag LNCS 2139、2001年8月。
[Garfinkel] Garfinkel, S., "Design Principles and Patterns for Computer Systems That Are Simultaneously Secure and Usable", May 2005.
[Garfinkel] Garfinkel、S.、「同時に安全で使用可能なコンピュータシステムの設計原則とパターン」、2005年5月。
[HKDF] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, May 2010.
[HKDF] Krawczyk、H。およびP. Eronen、「HMACベースの抽出および拡張キー導出関数（HKDF）」、RFC 5869、2010年5月。
[IPsec] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPsec] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[OpenPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[OpenPGP] Callas、J.、Donnerhacke、L.、Finney、H.、Shaw、D。、およびR. Thayer、「OpenPGP Message Format」、RFC 4880、2007年11月。
[SSH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[SSH] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Transport Layer Protocol」、RFC 4253、2006年1月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
Author's Address
著者のアドレス
Peter Gutmann University of Auckland Department of Computer Science New Zealand
ピーターグットマンオークランド大学コンピュータサイエンス学科ニュージーランド
EMail: pgut001@cs.auckland.ac.nz