[要約] RFC 5409は、Boneh-FranklinとBoneh-BoyenのIdentity-Based EncryptionアルゴリズムをCryptographic Message Syntax（CMS）と組み合わせて使用するためのガイドラインです。このRFCの目的は、CMSを使用してIdentity-Based Encryptionを実装する際の手順とセキュリティ上の考慮事項を提供することです。
Network Working Group L. Martin
Request for Comments: 5409 Voltage Security
Category: Informational M. Schertler
Axway
January 2009
Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption Algorithms with the Cryptographic Message Syntax (CMS)
暗号メッセージ構文（CMS）でのBoneh-FranklinおよびBoneh-Boyen IDベースの暗号化アルゴリズムの使用
Status of This Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Abstract
概要
This document describes the conventions for using the Boneh-Franklin (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in the Cryptographic Message Syntax (CMS) to encrypt content-encryption keys. Object identifiers and the convention for encoding a recipient's identity are also defined.
このドキュメントでは、暗号化メッセージ構文（CMS）でBoneh-Franklin（BF）およびBoneh-Boyen（BB1）IDベースの暗号化アルゴリズムを使用してコンテンツ暗号化キーを暗号化するための規則について説明します。オブジェクト識別子と受信者のIDをエンコードするための規則も定義されています。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................3
1.2. IBE Overview ...............................................3
2. Using Identity-Based Encryption .................................3
3. Key Encryption Algorithm Identifiers ............................6
4. Processing by the Sender ........................................7
5. Processing by the Receiver ......................................7
6. ASN.1 Module ....................................................8
7. Security Considerations .........................................9
7.1. Attacks outside the Scope of This Document .................9
7.2. Attacks within the Scope of This Document .................10
7.3. Attacks to Which the Protocols Defined in This Document
Are Susceptible............................................11
8. References .....................................................12
8.1. Normative References ......................................12
8.2. Informative References ....................................12
This document defines the way to use the Boneh-Franklin [IBCS] and Boneh-Boyen [IBCS] identity-based encryption (IBE) public-key algorithms in the Cryptographic Message Syntax (CMS) [CMS]. IBE is a public-key technology for encrypting content-encryption keys (CEKs) that can be implemented within the framework of the CMS: the recipient's identity is incorporated into the EnvelopedData CMS content type using the OtherRecipientInfo CHOICE in the RecipientInfo field as defined in Section 6.2.5 of [CMS]. This document does not describe the implementation of the BF and BB1 algorithms, which are described in detail in [IBCS].
このドキュメントでは、暗号化メッセージ構文（CMS）[CMS]でBoneh-Franklin [IBCS]およびBoneh-Boyen [IBCS] IDベース暗号化（IBE）公開鍵アルゴリズムを使用する方法を定義します。 IBEは、CMSのフレームワーク内に実装できるコンテンツ暗号化キー（CEK）を暗号化するための公開キーテクノロジーです。受信者のIDは、セクションで定義されているように、RecipientInfoフィールドのOtherRecipientInfo CHOICEを使用してEnvelopedData CMSコンテンツタイプに組み込まれます。 [CMS]の6.2.5。このドキュメントでは、[IBCS]で詳細に説明されているBFおよびBB1アルゴリズムの実装については説明していません。
IBE algorithms are a type of public-key cryptographic algorithm in which the public key is calculated directly from a user's identity instead of being generated randomly. This requires a different set of steps for encryption and decryption than would be used with other public-key algorithms, and these steps are defined in Sections 4 and 5 of this document, respectively.
IBEアルゴリズムは、公開鍵暗号アルゴリズムの一種で、公開鍵はランダムに生成されるのではなく、ユーザーのIDから直接計算されます。これには、暗号化と復号化に、他の公開鍵アルゴリズムで使用されるのとは異なる一連の手順が必要です。これらの手順は、このドキュメントのセクション4と5でそれぞれ定義されています。
This document also defines the object identifiers and syntax of the object that is used to define the identity of a message recipient.
このドキュメントでは、メッセージ受信者のIDを定義するために使用されるオブジェクト識別子とオブジェクトの構文も定義しています。
CMS values and identity objects are defined using ASN.1 [ASN1].
CMS値とIDオブジェクトは、ASN.1 [ASN1]を使用して定義されます。
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 RFC 2119 [KEYWORDS].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [KEYWORDS]で説明されているように解釈されます。
In addition to the client components that are described in this document, the following additional components are required for a complete IBE messaging system.
このドキュメントで説明されているクライアントコンポーネントに加えて、次の追加コンポーネントが完全なIBEメッセージングシステムに必要です。
o A Private-Key Generator (PKG). The PKG contains the cryptographic material, known as a master secret, for generating an individual's IBE private key. A PKG accepts an IBE user's private key request and, after successfully authenticating them in some way, returns their IBE private key.
o 秘密鍵ジェネレーター（PKG）。 PKGには、個人のIBE秘密キーを生成するためのマスターシークレットと呼ばれる暗号化マテリアルが含まれています。 PKGはIBEユーザーの秘密鍵要求を受け入れ、何らかの方法でそれらを認証した後、IBE秘密鍵を返します。
o A Public Parameter Server (PPS). IBE system parameters include publicly sharable cryptographic material, known as IBE public parameters, and policy information for the PKG. A PPS provides a well-known location for distribution of IBE public parameters and policy information for the IBE PKG.
o パブリックパラメータサーバー（PPS）。 IBEシステムパラメータには、IBEパブリックパラメータと呼ばれるパブリックに共有可能な暗号化マテリアル、およびPKGのポリシー情報が含まれます。 PPSは、IBE PKGのIBEパブリックパラメータとポリシー情報を配布するための既知の場所を提供します。
The interactions of senders and receivers of IBE-encrypted messages are described in [IBE]. All communications between users of an IBE system and the PPS or PKG MUST be protected using TLS [TLS] as described in [IBE]. This provides confidentiality and integrity of all information that is delivered to users as well as authentication of the PPS and PKG.
IBE暗号化メッセージの送信者と受信者の相互作用は、[IBE]で説明されています。 [IBE]で説明されているように、IBEシステムのユーザーとPPSまたはPKG間のすべての通信は、TLS [TLS]を使用して保護する必要があります。これにより、ユーザーに配信されるすべての情報の機密性と整合性、およびPPSとPKGの認証が提供されます。
To use IBE, the ori field in RecipientInfo MUST be used. The fields are set as follows: oriType is set to ibeORIType; oriValue is set to ibeORIValue.
IBEを使用するには、RecipientInfoのoriフィールドを使用する必要があります。フィールドは次のように設定されます。oriTypeはibeORITypeに設定されます。 oriValueはibeORIValueに設定されます。
These fields have the following meanings:
これらのフィールドには次の意味があります。
ibeORIType defines the object identifier (OID) that indicates that the subsequent ibeORIValue is the information necessary to decrypt the message using IBE. This field MUST be set to the following:
ibeORITypeは、後続のibeORIValueがIBEを使用してメッセージを復号化するために必要な情報であることを示すオブジェクト識別子（OID）を定義します。このフィールドは次のように設定する必要があります。
ibeORIType OBJECT IDENTIFIER ::= {
joint-iso-itu(2) country(16) us(840)
organization(1) identicrypt(114334)
ibcs(1) cms(4) ori-oid(1) version(1)
}
ibeORIValue defines the identity that was used in the IBE algorithm
to encrypt the CEK. This is an IBERecipientInfo type, which is
defined as follows:
IBERecipientInfo ::= SEQUENCE {
cmsVersion INTEGER { v3(3) },
keyFetchMethod OBJECT IDENTIFIER,
recipientIdentity IBEIdentityInfo,
serverInfo SEQUENCE SIZE (1..MAX) OF
OIDValuePairs OPTIONAL,
encryptedKey EncryptedKey
}
The fields of IBERecipientInfo MUST be set as follows.
IBERecipientInfoのフィールドは、次のように設定する必要があります。
The cmsVersion MUST be set to 3.
cmsVersionは3に設定する必要があります。
The keyFetchMethod is the OID that defines the method of retrieving the private key that the recipient MUST use. This SHOULD be set to uriPPSOID [IBE], which is defined to be the following:
keyFetchMethodは、受信者が使用する必要がある秘密鍵を取得する方法を定義するOIDです。これは、次のように定義されているuriPPSOID [IBE]に設定する必要があります。
uriPPSOID OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334)
pps-schemas(3) ic-schemas(1) pps-uri(1) version(1)
}
The recipientIdentity is the data that the sender used to calculate the IBE public key that the sender used to encrypt the content-encryption key. This recipientIdentity is used to calculate IBE public and private keys as described in [IBCS]. This MUST be a DER-encoded [DER] IBEIdentityInfo type [IBE], which is defined as follows:
recipientIdentityは、送信者がコンテンツ暗号化キーの暗号化に使用したIBE公開キーの計算に使用したデータです。この受信者IDは、[IBCS]で説明されているように、IBE公開鍵と秘密鍵を計算するために使用されます。これは、DERでエンコードされた[DER] IBEIdentityInfoタイプ[IBE]である必要があり、次のように定義されます。
IBEIdentityInfo ::= SEQUENCE {
district IA5String,
serial INTEGER,
identityType OBJECT IDENTIFIER,
identityData OCTET STRING
}
The identityType defines the format that is used to encode the
information that defines the identity of the recipient. This MUST be
set to cmsIdentityOID to indicate that identityData contains an
EmailIdentityData type. The value of cmsIdentityOID is the
following:
cmsIdentityOID OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334)
keyschemas(2) icschemas(1) email(1) version(1)
}
The identityData MUST be an EmailIdentityData type, which is defined as follows:
identityDataは、次のように定義されるEmailIdentityDataタイプである必要があります。
EmailIdentityData ::= SEQUENCE {
rfc822Name IA5String,
time GeneralizedTime
}
The rfc822Name field is the email address of the recipient in the format defined in Section 4.2.1.6 of [PKIX] for the rfc822Name subjectAltName variant. Rules for encoding Internet mail addresses that include internationalized domain names are specified in Section 7.5 of [PKIX].
rfc822Nameフィールドは、rfc822Name subjectAltNameバリアントについて[PKIX]のセクション4.2.1.6で定義された形式の受信者の電子メールアドレスです。国際化ドメイン名を含むインターネットメールアドレスをエンコードするためのルールは、[PKIX]のセクション7.5で指定されています。
The value of the time field is the UTC time after which the sender wants to let the recipient decrypt the message, so it may be called the "not-before" time. This is usually set to the time when the message is encrypted, but MAY be set to a future time. The value of "time" MUST be expressed in Greenwich Mean Time (Zulu), MUST include seconds (i.e., times are always YYYYMMDDHHMMSSZ), even where the number of seconds is equal to zero, and MUST be expressed to the nearest second.
時間フィールドの値は、送信者が受信者にメッセージの暗号化を解除させたいと考えるUTC時間です。そのため、「前」の時間と呼ばれる場合があります。これは通常、メッセージが暗号化される時刻に設定されますが、将来の時刻に設定される場合があります。 「時間」の値はグリニッジ標準時（ズールー語）で表現する必要があり、秒数がゼロの場合でも秒を含める必要があります（つまり、時間は常にYYYYMMDDHHMMSSZです）。最も近い秒に表現する必要があります。
The sender of an IBE-encrypted message may want to express this time rounded to a time interval to create a key lifetime. A key lifetime reduces the number of IBE private keys that a recipient needs to retrieve, but still forces the IBE user to periodically re-authenticate. Based on the time interval chosen a recipient would only have to retrieve a new IBE key once during the interval. To do this, follow the steps below. Let "time-interval" be the number of seconds in this larger time interval.
IBE暗号化メッセージの送信者は、キーの有効期間を作成するために、時間間隔に丸められたこの時間を表現したい場合があります。キーの有効期間は、受信者が取得する必要があるIBE秘密キーの数を減らしますが、それでもIBEユーザーに定期的に再認証を強制します。選択した時間間隔に基づいて、受信者は新しいIBEキーをその間隔中に一度だけ取得する必要があります。これを行うには、以下の手順に従います。 「time-interval」を、このより大きな時間間隔の秒数とする。
1. Find the GeneralizedTime for the not-before value. 2. Convert this GeneralizedTime into the number of seconds since January 1, 1970. Call this "total-time". 3. Calculate reduced-time = (floor (total-time / time-interval)) * time-interval. 4. Convert reduced-time to a GeneralizedTime to get the not-before "time" value.
1. not-before値のGeneralizedTimeを見つけます。 2.このGeneralizedTimeを1970年1月1日からの秒数に変換します。これを「合計時間」と呼びます。 3.短縮時間=（フロア（合計時間/時間間隔））*時間間隔を計算します。 4.短縮時間をGeneralizedTimeに変換して、「前」でない値を取得します。
An example of this algorithm for computing a one-week time interval is as follows.
1週間の時間間隔を計算するこのアルゴリズムの例は次のとおりです。
1. Suppose that the GeneralizedTime is 20020401000000Z. 2. Then the total-time is 1017612000. 3. A time-interval of 1 week is 604800 seconds. So the reduced-time = (floor (1017612000 / 604800)) * 604800 = 1017273600. 4. This gives the GeneralizedTime form of the reduced-time of 20020328000000Z.
1. GeneralizedTimeが20020401000000Zであるとします。 2.次に、合計時間は1017612000です。3. 1週間の時間間隔は604800秒です。したがって、短縮された時間=（floor（1017612000/604800））* 604800 = 1017273600。
When issuing IBE private keys, a PKG SHOULD NOT issue them too far into the future. This restriction is to prevent an adversary who obtains an IBE user's authentication credentials from requesting private keys far into the future and therefore negating the periodic IBE user re-authentication that key lifetime provides. For example, if a one-week period is chosen for the key lifetime, then IBE private keys should not be issued more than one week in advance. Otherwise, once an adversary gains access to the PKG via the stolen IBE user credentials, they can request all future keys and negate the IBE user authentication restraints in place.
IBE秘密鍵を発行するとき、PKGはそれらをあまり遠くに発行してはなりません（SHOULD NOT）。この制限は、IBEユーザーの認証資格情報を取得する攻撃者が遠くまで秘密鍵を要求しないようにすることで、鍵の有効期間が提供する定期的なIBEユーザーの再認証を無効にします。たとえば、キーの有効期間として1週間を選択した場合、1週間以上前にIBE秘密キーを発行しないでください。それ以外の場合、攻撃者は、盗まれたIBEユーザー資格情報を介してPKGにアクセスすると、将来のすべてのキーを要求し、IBEユーザー認証の制限を無効にすることができます。
The serverInfo is an optional sequence of OID-value pairs that are defined to be the following:
serverInfoは、次のように定義されるOIDと値のペアのオプションのシーケンスです。
OIDValuePairs ::= SEQUENCE {
fieldID OBJECT IDENTIFIER,
fieldData OCTET STRING
}
These can be used to convey any other information that might be used by a PKG. Examples of such information could include the user interface that the recipient will experience. Differences in the user interface could include localization information or commercial branding information. A client MUST ignore any part of serverInfo that it is unable to process.
これらは、PKGで使用される可能性のある他の情報を伝えるために使用できます。このような情報の例には、受信者が体験するユーザーインターフェイスが含まれます。ユーザーインターフェイスの違いには、ローカリゼーション情報や商用ブランド情報が含まれる場合があります。クライアントは、処理できないserverInfoの部分を無視する必要があります。
The encryptedKey is the result of encrypting the CEK with an IBE algorithm using recipientIdentity as the IBE public key.
encryptedKeyは、recipientIdentityをIBE公開鍵として使用して、IBEアルゴリズムでCEKを暗号化した結果です。
The BF and BB1 algorithms as defined in [IBCS] have the following object identifiers. These object identifiers are also defined in the ASN.1 module in [IBCS].
[IBCS]で定義されているBFおよびBB1アルゴリズムには、次のオブジェクト識別子があります。これらのオブジェクト識別子は、[IBCS]のASN.1モジュールでも定義されています。
bf OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334)
ibcs(1) ibcs1(1) ibe-algorithms(2) bf(1)
}
This is the object identifier that MUST be inserted in the
keyEncryptionAlgorithm field in the CMS when the BF algorithm is used
to encrypt the CEK.
bb1 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334)
ibcs(1) ibcs1(1) ibe-algorithms(2) bb1(2)
}
This is the object identifier that MUST be inserted in the keyEncryptionAlgorithm field in the CMS when the BB1 algorithm is used to encrypt the CEK.
これは、BB1アルゴリズムを使用してCEKを暗号化する場合に、CMSのkeyEncryptionAlgorithmフィールドに挿入する必要があるオブジェクト識別子です。
The sender of a message that uses IBE to encrypt content-encryption keys performs the following steps:
IBEを使用してコンテンツ暗号化キーを暗号化するメッセージの送信者は、次の手順を実行します。
1. Selects a set of IBE public parameters to use in the subsequent steps in accordance with his local security policy. He then determines the URI where the public parameters can be obtained using the process described in [IBE]. This information MUST be encoded in the IBEIdentityInfo as described in Section 2.
1. 彼のローカルセキュリティポリシーに従って、後続の手順で使用するIBEパブリックパラメータのセットを選択します。次に、[IBE]で説明されているプロセスを使用してパブリックパラメータを取得できるURIを決定します。この情報は、セクション2で説明するように、IBEIdentityInfoでエンコードする必要があります。
2. Sets the fields of an OtherRecipientInfo object to their appropriate values as described in Section 2.
2. セクション2で説明されているように、OtherRecipientInfoオブジェクトのフィールドを適切な値に設定します。
3. Calculates an IBE public key as defined in [IBCS] using this IBEIdentityInfo as the identity information.
3. このIBEIdentityInfoをID情報として使用して、[IBCS]で定義されているIBE公開鍵を計算します。
4. This IBE public key is then used to encrypt the content-encryption key (CEK), using the algorithms that are defined in [IBCS].
4. このIBE公開キーは、[IBCS]で定義されているアルゴリズムを使用して、コンテンツ暗号化キー（CEK）を暗号化するために使用されます。
5. Sets encryptedKey to the IBE-encrypted CEK.
5. 暗号化キーをONE暗号化CEKに設定します。
6. Within the CMS, keyEncryptionAlgorithm MUST then be set to the appropriate OID for the IBE algorithm that was used (see Section 3).
6. CMS内では、keyEncryptionAlgorithmを、使用されたIBEアルゴリズムに適切なOIDに設定する必要があります（セクション3を参照）。
Upon receiving a message that has a CEK encrypted with IBE, the recipient performs the following steps to decrypt the CEK:
IBEで暗号化されたCEKを持つメッセージを受信すると、受信者は次の手順を実行してCEKを復号化します。
1. Determines that the CEK is IBE-encrypted by noting that the oriType of the OtherRecipientInfo type is set to ibeORIType.
1. OtherRecipientInfoタイプのoriTypeがibeORITypeに設定されていることに注意することにより、CEKがIBE暗号化されていると判断します。
2. Determines that the recipientIdentity was used as the identity in IBE encryption of the CEK.
2. CEKのIBE暗号化で、identityIdentityがIDとして使用されたことを判別します。
3. Determines the location of the IBE public parameters and the IBE Private Key Generator as described in [IBE].
3. [IBE]で説明されているように、IBE公開パラメーターとIBE秘密鍵ジェネレーターの場所を決定します。
4. Obtains the IBE public parameters from the location determined in Step 3 using the process defined in [IBE].
4. [IBE]で定義されたプロセスを使用して、ステップ3で決定された場所からIBEパブリックパラメータを取得します。
5. Obtains the IBE private key needed to decrypt the encrypted CEK using the process defined in [IBE].
5. [IBE]で定義されたプロセスを使用して、暗号化されたCEKを復号化するために必要なIBE秘密鍵を取得します。
6. Decrypts the CEK using the IBE private key obtained in Step 4 using the algorithms described in [IBCS].
6. [IBCS]で説明されているアルゴリズムを使用して、ステップ4で取得したIBE秘密鍵を使用してCEKを復号化します。
The following ASN.1 module summarizes the ASN.1 definitions defined by this document.
次のASN.1モジュールは、このドキュメントで定義されているASN.1定義を要約しています。
IBECMS-module {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334)
ibcs(1) cms(4) module(5) version(1)
}
DEFINITIONS IMPLICIT TAGS ::= BEGIN
IMPORTS IBEIdentityInfo, uriPPSOID FROM
IMPORTS IBEIdentityInfo、uriPPSOID FROM
IBEARCH-module { joint-iso-itu-t(2) country(16)
us(840) organization(1) identicrypt(114334) ibcs(1)
ibearch(5) module(5) version(1)
};
IBEOtherRecipientInfo ::= SEQUENCE {
oriType OBJECT IDENTIFIER,
oriValue IBERecipientInfo
}
ibeORIType OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334)
ibcs(1) cms(4) ori-oid(1) version(1)
}
IBERecipientInfo ::= SEQUENCE {
cmsVersion INTEGER { v3(3) },
keyFetchMethod OBJECT IDENTIFIER,
recipientIdentity IBEIdentityInfo,
serverInfo SEQUENCE SIZE (1..MAX) OF
OIDValuePairs OPTIONAL,
encryptedKey EncryptedKey
}
OIDValuePairs ::= SEQUENCE {
fieldID OBJECT IDENTIFIER,
fieldData OCTET STRING
}
EncryptedKey ::= OCTET STRING
EmailIdentityData ::= SEQUENCE {
rfc822Name IA5String,
time GeneralizedTime
}
cmsIdentityOID OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334)
keyschemas(2) icschemas(1) email(1) version(1)
}
END
終わり
This document is based on [CMS], [IBCS], and [IBE], and the relevant security considerations of those documents apply.
このドキュメントは、[CMS]、[IBCS]、および[IBE]に基づいており、これらのドキュメントの関連するセキュリティの考慮事項が適用されます。
Attacks on the cryptographic algorithms that are used to implement IBE are outside the scope of this document. Such attacks are detailed in [IBCS], which defines parameters that give 80-bit,
IBEの実装に使用される暗号アルゴリズムへの攻撃は、このドキュメントの範囲外です。そのような攻撃は、80ビットを与えるパラメータを定義する[IBCS]で詳しく説明されています。
112-bit, 128-bit, and 256-bit encryption strength. We assume that capable administrators of an IBE system will select parameters that provide a sufficient resistance to cryptanalytic attacks by adversaries.
112ビット、128ビット、および256ビットの暗号化強度。 IBEシステムの有能な管理者は、攻撃者による暗号解読攻撃に対して十分な耐性を提供するパラメーターを選択すると想定しています。
Attacks that give an adversary the ability to access or change the information on a PPS or PKG, especially the cryptographic material (referred to in this document as the master secret), will defeat the security of an IBE system. In particular, if the cryptographic material is compromised, the adversary will have the ability to recreate any user's private key and therefore decrypt all messages protected with the corresponding public key. To address this concern, it is highly RECOMMENDED that best practices for physical and operational security for PPS and PKG servers be followed and that these servers be configured (sometimes known as hardened) in accordance with best current practices [NIST]. An IBE system SHOULD be operated in an environment where illicit access to the PKG or the ability to modify the information distributed by the PPS is infeasible for attackers to obtain.
攻撃者にPPSまたはPKGの情報、特に暗号化資料（このドキュメントではマスターシークレットと呼ばれます）にアクセスまたは変更する能力を与える攻撃は、IBEシステムのセキュリティを無効にします。特に、暗号化素材が危険にさらされている場合、攻撃者はユーザーの秘密鍵を再作成できるため、対応する公開鍵で保護されているすべてのメッセージを復号化できます。この懸念に対処するために、PPSおよびPKGサーバーの物理的および運用上のセキュリティのベストプラクティスに従い、これらのサーバーを現在のベストプラクティスに従って構成する（ハード化とも呼ばれる）ことを強くお勧めします[NIST]。 IBEシステムは、PKGへの不正アクセス、またはPPSによって配布された情報を変更する機能が攻撃者が入手できない環境で運用する必要があります（SHOULD）。
Attacks that require administrative access or IBE-user-equivalent access to machines used by either the client or the server components defined in this document are also outside the scope of this document.
このドキュメントで定義されているクライアントまたはサーバーコンポーネントによって使用されるマシンへの管理アクセスまたはIBEユーザー相当のアクセスを必要とする攻撃も、このドキュメントの範囲外です。
We also assume that all administrators of a system implementing the protocols that are defined in this document are trustworthy and will not abuse their authority to bypass the security provided by an IBE system. This is of particular importance with an IBE system, for an administrator of a PKG could potentially abuse his authority and configure the PKG to grant him any IBE private key that the PKG is capable of calculating. To minimize the possibility of administrators doing this, a system implementing IBE SHOULD implement n-out-of-m control for critical administrative functions and SHOULD maintain auditable logs of all security-critical events that occur in an operating IBE system.
また、このドキュメントで定義されているプロトコルを実装するシステムのすべての管理者は信頼できるものであり、IBEシステムによって提供されるセキュリティをバイパスする権限を乱用しないと想定しています。これは、IBEシステムでは特に重要です。PKGの管理者は自分の権限を悪用し、PKGが計算できるIBE秘密キーを許可するようにPKGを構成する可能性があるためです。管理者がこれを行う可能性を最小限に抑えるために、IBEを実装するシステムは、重要な管理機能にn-out-of-m制御を実装する必要があり、オペレーティングIBEシステムで発生するすべてのセキュリティクリティカルイベントの監査可能なログを維持する必要があります。
Similarly, we assume that users of an IBE system will behave responsibly, not sharing their authentication credentials with others. Thus, attacks that require such assumptions are outside the scope of this document.
同様に、IBEシステムのユーザーは責任を持って行動し、自分の認証資格情報を他のユーザーと共有しないと想定しています。したがって、そのような想定を必要とする攻撃は、このドキュメントの範囲外です。
Attacks within the scope of this document are those that allow an adversary to:
このドキュメントの範囲内の攻撃は、攻撃者に次のことを許可する攻撃です。
o passively monitor information transmitted between users of an IBE system and the PPS and PKG
o IBEシステムのユーザーとPPSおよびPKGの間で送信される情報を受動的に監視する
o masquerade as a PPS or PKG
o PPSまたはPKGになりすます
o perform a denial-of-service (DoS) attack on a PPS or PKG
o PPSまたはPKGでサービス拒否（DoS）攻撃を実行する
o easily guess an IBE user's authentication credential
o IBEユーザーの認証資格情報を簡単に推測
7.3. Attacks to Which the Protocols Defined in This Document Are Susceptible
7.3. このドキュメントで定義されているプロトコルが影響を受ける攻撃
All communications between users of an IBE system and the PPS or PKG are protected using TLS [TLS]. The IBE system defined in this document provides no additional security for the communications between IBE users and the PPS or PKG. Therefore, the described IBE system is completely dependent on the TLS security mechanisms for authentication of the PKG or PPS server and for confidentiality and integrity of the communications. Should there be a compromise of the TLS security mechanisms, the integrity of all communications between an IBE user and the PPS or PKG will be suspect.
IBEシステムのユーザーとPPSまたはPKGの間のすべての通信は、TLS [TLS]を使用して保護されます。このドキュメントで定義されているIBEシステムは、IBEユーザーとPPSまたはPKG間の通信に追加のセキュリティを提供しません。したがって、説明されているIBEシステムは、PKGまたはPPSサーバーの認証、および通信の機密性と整合性のTLSセキュリティメカニズムに完全に依存しています。 TLSセキュリティメカニズムの侵害がある場合、IBEユーザーとPPSまたはPKGの間のすべての通信の整合性が疑われます。
The protocols defined in this document do not explicitly defend against an attacker masquerading as a legitimate IBE PPS or PKG. The protocols rely on the server authentication mechanism of TLS [TLS]. In addition to the TLS server authentication mechanism, IBE client software can provide protection against this possibility by providing user interface capabilities that allows users to visually determine that a connection to PPS and PKG servers is legitimate. This additional capability can help ensure that users cannot easily be tricked into providing valid authorization credentials to an attacker.
このドキュメントで定義されているプロトコルは、正当なIBE PPSまたはPKGを装った攻撃者を明示的に防御するものではありません。プロトコルは、TLS [TLS]のサーバー認証メカニズムに依存しています。 TLSサーバー認証メカニズムに加えて、IBEクライアントソフトウェアは、ユーザーがPPSおよびPKGサーバーへの接続が正当であることを視覚的に判断できるユーザーインターフェイス機能を提供することにより、この可能性に対する保護を提供できます。この追加機能により、ユーザーが簡単に騙されて有効な認証資格情報を攻撃者に提供できないようにすることができます。
The protocols defined in this document are also vulnerable to attacks against an IBE PPS or PKG. Denial-of-service attacks against either component can result in users unable to encrypt or decrypt using IBE, and users of an IBE system SHOULD take the appropriate countermeasures [DOS, BGPDOS] that their use of IBE requires.
このドキュメントで定義されているプロトコルは、IBE PPSまたはPKGに対する攻撃に対しても脆弱です。いずれかのコンポーネントに対するサービス拒否攻撃は、ユーザーがIBEを使用して暗号化または復号化できなくなる可能性があり、IBEシステムのユーザーは、IBEの使用に必要な適切な対策[DOS、BGPDOS]を実行する必要があります。
The IBE user authentication method used by an IBE PKG SHOULD be of sufficient strength to prevent attackers from easily guessing the IBE user's authentication credentials through trial and error.
IBE PKGが使用するIBEユーザー認証方法は、攻撃者が試行錯誤によってIBEユーザーの認証資格情報を簡単に推測できないように十分な強度を持つ必要があります。
[ASN1] ITU-T Recommendation X.680: Information Technology - "Abstract Syntax Notation One (ASN.1): Specification of Basic Notation", July 2002.
[ASN1] ITU-T勧告X.680：情報技術-「抽象構文記法1（ASN.1）：基本記法の仕様」、2002年7月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS] Housley、R。、「Cryptographic Message Syntax（CMS）」、RFC 3852、2004年7月。
[DER] ITU-T Recommendation X.690: OSI Networking and System Aspects: Abstract Syntax Notation One (ASN.1), July 2002.
[DER] ITU-T Recommendation X.690：OSI Networking and System Aspects：Abstract Syntax Notation One（ASN.1）、July 2002。
[DOS] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[DOS]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IP送信元アドレスのスプーフィングを採用するサービス拒否攻撃の克服」、BCP 38、RFC 2827、2000年5月。
[IBCS] Boyen, X. and L. Martin, "Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems", RFC 5091, December 2007.
[IBCS]ボイエン、X。およびL.マーティン、「IDベースの暗号化標準（IBCS）＃1：BFおよびBB1暗号システムの超特異曲線実装」、RFC 5091、2007年12月。
[IBE] Appenzeller, G., Martin, L., and M. Schertler, "Identity-Based Encryption Architecture and Supporting Data Structures", RFC 5408, January 2009.
[IBE] Appenzeller、G.、Martin、L。、およびM. Schertler、「Identity-Based Encryption Architecture and Supporting Data Structures」、RFC 5408、2009年1月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[PKIX] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。
[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月。
[BGPDOS] Turk, D., "Configuring BGP to Block Denial-of-Service Attacks", RFC 3882, September 2004.
[BGPDOS] Turk、D。、「DoS攻撃をブロックするためのBGPの構成」、RFC 3882、2004年9月。
[NIST] M. Souppaya, J. Wack and K. Kent, "Security Configuration Checklist Program for IT Products - Guidance for Checklist Users and Developers", NIST Special Publication SP 800-70, May 2005.
[NIST] M. Souppaya、J。WackおよびK. Kent、「IT製品のセキュリティ構成チェックリストプログラム-チェックリストユーザーおよび開発者向けガイダンス」、NIST特別刊行物SP 800-70、2005年5月。
Authors' Addresses
著者のアドレス
Luther Martin Voltage Security 1070 Arastradero Rd, Suite 100 Palo Alto, CA 94304 USA
Luther Martin Voltage Security 1070 Arastradero Rd、Suite 100 Palo Alto、CA 94304 USA
Phone: +1 650 543 1280
EMail: martin@voltage.com
Mark Schertler Axway 1600 Seaport Blvd, Suite 400 Redwood City, CA 94063 USA
Mark Schertler Axway 1600 Seaport Blvd、Suite 400 Redwood City、CA 94063 USA
Phone: +1 650 216 2039
EMail: mschertler@us.axway.com