[要約] RFC 6539は、Identity-Based Authenticated Key Exchange（IBAKE）プロトコルに関するものであり、IBAKEの要約と目的を以下のようにまとめることができます。1. IBAKEは、身元ベースの認証付き鍵交換プロトコルである。 2. 目的は、セキュアな通信を確保しながら、参加者の身元情報を利用して鍵交換を行うこと。 3. RFC 6539は、IBAKEプロトコルの仕様とセキュリティ上の考慮事項を提供する。
Independent Submission V. Cakulev
Request for Comments: 6539 G. Sundaram
Category: Informational I. Broustis
ISSN: 2070-1721 Alcatel Lucent
March 2012
IBAKE: Identity-Based Authenticated Key Exchange
Ibake：IDベースの認証されたキー交換
Abstract
概要
Cryptographic protocols based on public-key methods have been traditionally based on certificates and Public Key Infrastructure (PKI) to support certificate management. The emerging field of Identity-Based Encryption (IBE) protocols allows simplification of infrastructure requirements via a Private-Key Generator (PKG) while providing the same flexibility. However, one significant limitation of IBE methods is that the PKG can end up being a de facto key escrow server, with undesirable consequences. Another observed deficiency is a lack of mutual authentication of communicating parties. This document specifies the Identity-Based Authenticated Key Exchange (IBAKE) protocol. IBAKE does not suffer from the key escrow problem and in addition provides mutual authentication as well as perfect forward and backward secrecy.
パブリックキーメソッドに基づく暗号化プロトコルは、従来、証明書管理をサポートする証明書と公開キーインフラストラクチャ（PKI）に基づいています。アイデンティティベースの暗号化（IBE）プロトコルの新興分野により、同じ柔軟性を提供しながら、プライベートキージェネレーター（PKG）を介したインフラストラクチャ要件の簡素化が可能になります。ただし、IBEメソッドの重要な制限の1つは、PKGが最終的には、望ましくない結果をもたらす事実上のキーエスクローサーバーになる可能性があることです。別の観察された欠陥は、通信当事者の相互認証の欠如です。このドキュメントは、IDベースの認証されたキーエクスチェンジ（IBAKE）プロトコルを指定します。Ibakeは重要なエスクローの問題に悩まされておらず、さらに相互認証と完全な前方および後方の秘密を提供します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開が承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。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/rfc6539.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6539で取得できます。
Independent Submissions Editor Note
独立した提出エディターノート
This document specifies the Identity-Based Authenticated Key Exchange (IBAKE) protocol. Due to its specialized nature, this document experienced limited review within the Internet Community. Readers of this RFC should carefully evaluate its value for implementation and deployment.
このドキュメントは、IDベースの認証されたキーエクスチェンジ（IBAKE）プロトコルを指定します。その特殊な性質のため、この文書はインターネットコミュニティ内で限られたレビューを経験しました。このRFCの読者は、実装と展開の価値を慎重に評価する必要があります。
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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................2
2. Requirements Notation ...........................................3
2.1. IBE: Definition ............................................3
2.2. Abbreviations ..............................................3
2.3. Conventions ................................................4
3. Identity-Based Authenticated Key Exchange .......................5
3.1. Overview ...................................................5
3.2. IBAKE Message Exchange .....................................6
3.3. Discussion .................................................7
4. Security Considerations .........................................9
4.1. General ....................................................9
4.2. IBAKE Protocol ............................................10
5. References .....................................................12
5.1. Normative References ......................................12
5.2. Informative References ....................................12
Authenticated key agreements are cryptographic protocols where two or more participants authenticate each other and agree on key material used for securing future communication. These protocols could be symmetric key or asymmetric public-key protocols. Symmetric-key protocols require an out-of-band security mechanism to bootstrap a secret key. On the other hand, public-key protocols traditionally require certificates and a large-scale Public Key Infrastructure (PKI). Clearly, public-key methods are more flexible; however, the requirement for certificates and a large-scale PKI have proved to be challenging. In particular, efficient methods to support large-scale certificate revocation and management have proved to be elusive.
認証された主要な契約は、2人以上の参加者が互いに認証し、将来のコミュニケーションを確保するために使用される重要な資料に同意する暗号化プロトコルです。これらのプロトコルは、対称キーまたは非対称のパブリックキープロトコルである可能性があります。対称キープロトコルには、秘密の鍵をブートストラップするために、帯域外セキュリティメカニズムが必要です。一方、パブリックキープロトコルには、従来、証明書と大規模な公開インフラストラクチャ（PKI）が必要です。明らかに、パブリックキーの方法はより柔軟です。ただし、証明書と大規模なPKIの要件は挑戦的であることが証明されています。特に、大規模な証明書の取り消しと管理をサポートする効率的な方法は、とらえどころのないことが証明されています。
Recently, Identity-Based Encryption (IBE) protocols have been proposed as a viable alternative to public-key methods by replacing the PKI with a Private-Key Generator (PKG). However, one significant limitation of IBE methods is that the PKG can end up being a de facto
最近、IDベースの暗号化（IBE）プロトコルは、PKIをPrivate-Keyジェネレーター（PKG）に置き換えることにより、パブリックキーメソッドの実行可能な代替手段として提案されています。ただし、IBEメソッドの重要な制限の1つは、PKGが事実上のものになる可能性があることです。
key escrow entity (i.e., an entity that has sufficient information to decrypt communicated data), with undesirable consequences. Another limitation is a lack of mutual authentication between communicating parties. This document specifies an Identity-Based Authenticated Key Encryption (IBAKE) protocol that does not suffer from the key escrow problem and that provides mutual authentication. In addition, the scheme described in this document allows the use of time-bound public identities and corresponding public and private keys, resulting in automatic expiration of private keys at the end of a time span indicated in the identity itself. With the self-expiration of the public identities, the traditional real-time validity verification and revocation procedures used with certificates are not required. For example, if the public identity is bound to one day, then, at the end of the day, the public/private key pair issued to this peer will simply not be valid anymore. Nevertheless, just as with public-key-based certificate systems, if there is a need to revoke keys before the designated expiry time, communication with a third party will be needed. Finally, the protocol also provides forward and backward secrecy of session keys; i.e., a session key produced using IBAKE is always fresh and unrelated to any past or future sessions between the protocol participants.
主要なエスクローエンティティ（つまり、通信データを復号化するのに十分な情報があるエンティティ）、望ましくない結果をもたらします。もう1つの制限は、通信当事者間の相互認証の欠如です。このドキュメントは、主要なエスクローの問題に悩まされず、相互認証を提供するアイデンティティベースの認証されたキー暗号化（IBAKE）プロトコルを指定します。さらに、このドキュメントで説明されているスキームは、時間に縛られた公的アイデンティティと対応するパブリックキーおよびプライベートキーの使用を可能にし、その結果、アイデンティティ自体に示された期間の終わりにプライベートキーが自動的に有効になります。公的アイデンティティの自己称賛により、証明書で使用される従来のリアルタイムの妥当性の検証および取り消し手順は必要ありません。たとえば、パブリックアイデンティティが1日に拘束されている場合、1日の終わりに、このピアに発行されたパブリック/プライベートキーペアは、もはや有効ではありません。それにもかかわらず、パブリックキーベースの証明書システムと同様に、指定された有効期限の前にキーを取り消す必要がある場合、第三者との通信が必要になります。最後に、プロトコルはセッションキーの前後の秘密も提供します。つまり、Ibakeを使用して作成されたセッションキーは、常に新鮮で、プロトコル参加者間の過去または将来のセッションとは無関係です。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Identity-Based Encryption (IBE) is a public-key encryption technology that allows a public key to be calculated from an identity and a set of public parameters, and the corresponding private key to be calculated from the public key. The public key can then be used by an Initiator to encrypt messages that the recipient can decrypt using the corresponding private key. The IBE framework is defined in [RFC5091], [RFC5408], and [RFC5409].
アイデンティティベースの暗号化（IBE）は、公開キーをアイデンティティと一連の公開パラメーターから計算できるようにする公開キー暗号化テクノロジー、および対応する秘密鍵を公開鍵から計算することを可能にします。その後、公開キーをイニシエーターによって使用して、対応する秘密鍵を使用して受信者が復号化できるメッセージを暗号化できます。IBEフレームワークは、[RFC5091]、[RFC5408]、および[RFC5409]で定義されています。
EC Elliptic Curve
EC楕円曲線
IBE Identity-Based Encryption
IBE IDベースの暗号化
IBAKE Identity-Based Authenticated Key Exchange
Ibake Identityベースの認証されたキー交換
IDi Initiator's Identity
IDIイニシエーターのアイデンティティ
IDr Responder's Identity
IDRレスポンダーの身元
K_PUB Public Key
K_PUB公開キー
PKG Private-Key Generator
PKGプライベートキージェネレーター
PKI Public Key Infrastructure
PKI公開キーインフラストラクチャ
o E is an elliptic curve over a finite field F.
o Eは、有限フィールドFの上の楕円曲線です。
o P is a point on E of large prime order.
o Pは、大規模なプライムオーダーのEのポイントです。
o s is a non-zero positive integer. s is a secret stored in a PKG. This is a system-wide secret and not revealed outside the PKG.
o sはゼロ陽性の整数ではありません。SはPKGに保存されている秘密です。これはシステム全体の秘密であり、PKGの外では明らかにされていません。
o sP is the public key of the system that is known to all participants. sP denotes a point on E, and denotes the point P added to itself s times where addition refers to the group operation on E.
o SPは、すべての参加者に知られているシステムの公開鍵です。SPはEの点を示し、追加がE.のグループ操作を指すポイントPをそれ自体に追加します。
o H1 is a known hash function that takes a string and assigns it to a point on the elliptic curve, i.e., H1(A) = QA on E, where A is usually based on the identity.
o H1は、文字列を取得し、楕円曲線のポイント、つまりH1（a）= QAのeで、通常はアイデンティティに基づいている既知のハッシュ関数です。
o E(k, A) denotes that A is IBE-encrypted with the key k.
o E（k、a）は、aがキーkでibe暗号化されていることを示します。
o s||t denotes concatenation of the strings s and t.
o s || tは、弦sとtの連結を示します。
o K_PUBx denotes a public key of x.
o k_pubxはxの公開鍵を示します。
IBAKE consists of a three-way exchange between an Initiator and a Responder. In the figure below, a conceptual signaling diagram of IBAKE is depicted.
Ibakeは、イニシエーターとレスポンダーの間の3方向の交換で構成されています。以下の図では、Ibakeの概念的なシグナル伝達図が描かれています。
+---+ +---+
| I | | R |
+---+ +---+
MESSAGE_1
---------------------------------->
MESSAGE_2
<----------------------------------
MESSAGE_3
---------------------------------->
Figure 1: Example IBAKE Message Exchange
図1：Ibakeメッセージ交換の例
The Initiator (I) and Responder (R) are attempting to mutually authenticate each other and agree on a key using IBAKE. This specification assumes that the Initiator and the Responder trust a third party -- the PKG. Rather than a single PKG, different PKGs may be involved, e.g., one for the Initiator and one for the Responder. The Initiator and the Responder do not share any credentials; however, they know or can obtain each other's public identity (key) as well as the public parameters of each other's PKG. This specification does not make any assumption on when and how the private keys are obtained. However, to complete the protocol described (i.e., to decrypt encrypted messages in the IBAKE protocol exchange), the Initiator and the Responder need to have their respective private keys. The procedures needed to obtain the private keys and public parameters are outside the scope of this specification. The details of these procedures can be found in [RFC5091] and [RFC5408]. Finally, the protocol described in this document relies on the use of elliptic curves. Section 3.3 discusses the choice of elliptic curves. However, how the Initiator and the Responder agree on a specific elliptic curve is left to the application that is leveraging the IBAKE protocol (see [EAP-IBAKE], for example).
イニシエーター（i）とレスポンダー（R）は、相互に認証し、ibakeを使用してキーに同意しようとしています。この仕様は、イニシエーターとレスポンダーが第三者であるPKGを信頼することを前提としています。単一のPKGではなく、異なるPKGが関与する可能性があります。たとえば、イニシエーター用、もう1つはレスポンダー用です。イニシエーターとレスポンダーは資格情報を共有しません。しかし、彼らはお互いのパブリックアイデンティティ（鍵）とお互いのPKGのパブリックパラメーターを知っているか、得ることができます。この仕様では、プライベートキーがいつどのように取得されるかについての仮定はありません。ただし、説明されているプロトコルを完了するには（つまり、Ibakeプロトコル交換で暗号化されたメッセージを復号化するために）、イニシエーターとレスポンダーにはそれぞれのプライベートキーが必要です。プライベートキーとパブリックパラメーターを取得するために必要な手順は、この仕様の範囲外です。これらの手順の詳細は、[RFC5091]および[RFC5408]に記載されています。最後に、このドキュメントで説明されているプロトコルは、楕円曲線の使用に依存しています。セクション3.3では、楕円曲線の選択について説明します。ただし、特定の楕円曲線にイニシエーターと応答者がどのように同意するかは、Ibakeプロトコルを活用しているアプリケーションに任されています（たとえば、[eap-bake]を参照）。
The Initiator chooses a random x. In the first step, the Initiator computes xP (i.e., P, as a point on E, added to itself x times using the addition law on E); encrypts xP, the IDi, and the IDr using the Responder's public key (e.g., K_PUBr=H1(IDr||date)); and includes
イニシエーターはランダムxを選択します。最初のステップでは、イニシエーターはXPを計算します（すなわち、eの点として、eの追加法則を使用してx倍に追加）。Responderの公開キーを使用してXP、IDI、およびIDRを暗号化します（例：k_pubr = h1（idr || date））;および含まれる
this encrypted information in MESSAGE_1 sent to the Responder. In this step, encryption refers to IBE as described in [RFC5091] and [RFC5408].
この暗号化された情報は、Responderに送信されました。このステップでは、暗号化は[RFC5091]および[RFC5408]で説明されているようにIBEを指します。
The Responder, upon receiving the message, IBE-decrypts it using its private key (e.g., a private key for that date), and obtains xP. The Responder further chooses a random y and computes yP. The Responder then IBE-encrypts the Initiator's identity (IDi), its own identity (IDr), xP, and yP using the Initiator's public key (e.g., K_PUBi=H1(IDi||date)). The Responder includes this encrypted information in MESSAGE_2 sent to the Initiator.
応答者は、メッセージを受け取ると、Ibeは秘密鍵（その日付の秘密鍵など）を使用してそれを使用してXPを取得します。レスポンダーはランダムYをさらに選択し、YPを計算します。その後、レスポンダーは、イニシエーターの公開キー（例えば、K_PUBI = H1（IDI ||日付））を使用して、イニシエーターのID（IDI）、独自のアイデンティティ（IDR）、XP、およびYPを暗号化します。レスポンダーには、この暗号化された情報がInitiatorに送信されたMessage_2に含まれています。
The Initiator, upon receiving and IBE-decrypting MESSAGE_2, obtains yP. Subsequently, the Initiator sends MESSAGE_3, which includes the IBE-encrypted IDi, IDr, and yP, to the Responder. At this point, both the Initiator and the Responder are able to compute the same session key as xyP.
イニシエーターは、message_2を受信して排除すると、ypを取得します。その後、イニシエーターはメッセージ_3を送信します。これには、IBE暗号化されたIDI、IDR、YPを含む、Responderに送信されます。この時点で、イニシエーターとレスポンダーの両方がXYPと同じセッションキーを計算できます。
Initially, the Initiator selects a random x and computes xP; the Initiator MUST use a fresh, random value for x on each run of the protocol. The Initiator then encrypts xP, the IDi, and the IDr using the Responder's public key (e.g., K_PUBr=H1(IDr||date)). The Initiator includes this encrypted information in MESSAGE_1 and sends it to the Responder, as shown below.
最初に、イニシエーターはランダムXを選択し、XPを計算します。イニシエーターは、プロトコルの各実行時にxに対して新鮮でランダムな値を使用する必要があります。イニシエーターは、Responderの公開キー（k_pubr = h1（idr || date）など）を使用してXP、IDI、およびIDRを暗号化します。イニシエーターには、この暗号化された情報がmessage_1に含まれており、以下に示すようにレスポンダーに送信します。
Initiator ----> Responder
MESSAGE_1 = E(K_PUBr, IDi || IDr || xP)
message_1 = e（k_pubr、idi || idr || xp）
Upon receiving MESSAGE_1, the Responder SHALL perform the following:
message_1を受信すると、レスポンダーは以下を実行します。
o Decrypt the message as specified in [RFC5091] and [RFC5408].
o [RFC5091]および[RFC5408]で指定されているメッセージを復号化します。
o Obtain xP.
o XPを取得します。
o Select a random y and compute yP. The Responder MUST use a fresh, random value for x on each run of the protocol.
o ランダムYを選択し、YPを計算します。レスポンダーは、プロトコルの各実行時にxに対して新鮮でランダムな値を使用する必要があります。
o Encrypt the Initiator's identity (IDi), its own identity (IDr), xP, and yP using the Initiator's public key (K_PUBi).
o イニシエーターの公開キー（K_PUBI）を使用して、イニシエーターのID（IDI）、独自のアイデンティティ（IDR）、XP、およびYPを暗号化します。
Responder ----> Initiator
MESSAGE_2 = E(K_PUBi, IDi || IDr || xP || yP)
message_2 = e（k_pubi、idi || idr || xp || yp）
Upon receiving MESSAGE_2, the Initiator SHALL perform the following:
message_2を受信すると、イニシエーターは以下を実行するものとします。
o Decrypt the message as specified in [RFC5091] and [RFC5408].
o [RFC5091]および[RFC5408]で指定されているメッセージを復号化します。
o Verify that the received xP is the same as that sent in MESSAGE_1.
o 受信したXPがmessage_1で送信されたものと同じであることを確認します。
o Obtain yP.
o YPを取得します。
o Encrypt its own identity (IDi), the Responder's identity (IDr), and yP using the Responder's public key (K_PUBi).
o 独自のアイデンティティ（IDI）、ResponderのID（IDR）、およびResponderの公開鍵（K_Pubi）を使用してYPを暗号化します。
Initiator ----> Responder
MESSAGE_3 = E(K_PUBr, IDi || IDr || yP)
message_3 = e（k_pubr、idi || idr || yp）
Upon receiving MESSAGE_3, the Responder SHALL perform the following:
message_3を受信すると、レスポンダーは以下を実行します。
o Decrypt the message as specified in [RFC5091] and [RFC5408].
o [RFC5091]および[RFC5408]で指定されているメッセージを復号化します。
o Verify that the received yP is the same as that sent in MESSAGE_2.
o 受信したYPがmessage_2で送信されたものと同じであることを確認します。
If any of the above verifications fail, the protocol halts; otherwise, following this exchange, both the Initiator and the Responder have authenticated each other and are able to compute xyP as the session key. At this point, both protocol participants MUST discard all intermediate cryptographic values, including x and y. Similarly, both parties MUST immediately discard these values whenever the protocol terminates as a result of a verification failure or timeout.
上記の検証のいずれかが失敗した場合、プロトコルは停止します。それ以外の場合、この交換に続いて、イニシエーターとレスポンダーの両方が互いに認証されており、セッションキーとしてXYPを計算できます。この時点で、両方のプロトコル参加者は、xおよびyを含むすべての中間暗号値を破棄する必要があります。同様に、検証の失敗またはタイムアウトの結果としてプロトコルが終了する場合は、両当事者がこれらの値を直ちに破棄する必要があります。
Properties of the protocol are as follows:
プロトコルのプロパティは次のとおりです。
o Immunity from key escrow: Observe that all of the steps in the protocol exchange are encrypted using IBE. So, clearly, the PKG can decrypt all of the exchanges. However, given the assumption that PKGs are trusted and well behaved (e.g., PKGs will not mount an active man-in-the-middle (MitM) attack), they cannot compute the session key. This is because of the hardness of the Elliptic Curve Diffie-Hellman problem. In other words, given xP and yP, it is computationally hard to compute xyP.
o キーエスクローからの免疫：プロトコル交換のすべてのステップがIBEを使用して暗号化されていることを観察します。したがって、明らかに、PKGはすべての交換を復号化できます。ただし、PKGが信頼され、適切に動作されているという仮定を考えると（たとえば、PKGSは、アクティブなマンインザミドル（MITM）攻撃をマウントしません）、セッションキーを計算することはできません。これは、楕円曲線diffie-hellmanの問題の硬度のためです。言い換えれば、XPとYPが与えられた場合、XYPを計算することは計算が困難です。
o Mutually authenticated key agreement: Observe that all of the steps in the protocol exchange are encrypted using IBE. In particular, only the Responder and its corresponding PKG can decrypt the contents of MESSAGE_1 and MESSAGE_3 sent by the Initiator, and similarly only the Initiator and its corresponding
o 相互に認証された重要な合意：プロトコル交換のすべての手順がIBEを使用して暗号化されていることを観察します。特に、応答者とその対応するPKGのみが、イニシエーターによって送信されたmessage_1とmessage_3の内容を復号化できます。
PKG can decrypt the contents of MESSAGE_2 sent by the Responder. Again, given the assumption made above -- that PKGs are trusted and well behaved (e.g., a PKG will not impersonate a user to which it issued a private key) -- upon receiving MESSAGE_2, the Initiator can verify the Responder's authenticity, since xP could have been sent in MESSAGE_2 only after decryption of the contents of MESSAGE_1 by the Responder. Similarly, upon receiving MESSAGE_3, the Responder can verify the Initiator's authenticity, since yP could have been sent back in MESSAGE_3 only after correct decryption of the contents of MESSAGE_2 by the Initiator. Finally, both the Initiator and the Responder can agree on the same session key. In other words, IBAKE is a mutually authenticated key agreement protocol based on IBE. The hardness of the key agreement protocol relies on the hardness of the Elliptic Curve Diffie-Hellman problem. Thus, in any practical implementation, care should be devoted to the choice of elliptic curve.
PKGは、レスポンダーによって送信されたmessage_2の内容を復号化できます。繰り返しになりますが、上記の仮定を考えると、PKGは信頼され、十分に動作されているということです（例えば、PKGは秘密鍵を発行したユーザーになりすましません） - メッセージ_2を受信すると、イニシエーターはXP以降、レスポンダーの信頼性を確認できます。 Responderによってmessage_1の内容を復号化した後にのみ、message_2で送信された可能性があります。同様に、message_3を受信すると、Responderはイニシエーターの信ity性を検証できます。これは、YPがイニシエーターによってmessage_2の内容の正しい復号化の後にのみmessage_3で送信された可能性があるためです。最後に、イニシエーターとレスポンダーの両方が同じセッションキーに同意することができます。言い換えれば、IbakeはIBEに基づいた相互に認証されたキー契約プロトコルです。主要な合意プロトコルの硬度は、楕円曲線diffie-hellmanの問題の硬度に依存しています。したがって、実際の実装では、楕円曲線の選択に注意する必要があります。
o Perfect forward and backward secrecy: Since x and y are random, xyP is always fresh and unrelated to any past or future sessions between the Initiator and the Responder.
o 完全な前方と後方の秘密：XとYはランダムであるため、XYPは常に新鮮で、イニシエーターとレスポンダーの間の過去または将来のセッションとは無関係です。
o No passwords: Clearly, the IBAKE protocol does not require any offline exchange of passwords or secret keys between the Initiator and the Responder. In fact, the method is applicable to any two parties communicating for the first time through any communication network. The only requirement is to ensure that both the Initiator and the Responder are aware of each other's public keys and the public parameters of the PKG that generated the corresponding private keys.
o パスワードなし：明らかに、Ibakeプロトコルでは、イニシエーターとレスポンダーの間のパスワードや秘密キーのオフライン交換は必要ありません。実際、この方法は、通信ネットワークを介して初めて通信する2つの当事者に適用できます。唯一の要件は、イニシエーターとレスポンダーの両方が、対応するプライベートキーを生成したPKGのパブリックキーとPKGの公開パラメーターを認識していることを保証することです。
o PKG availability: Observe that PKGs need not be contacted during an IBAKE protocol exchange, which dramatically reduces the availability requirements on PKGs.
o PKGの可用性：IBAKEプロトコル交換中にPKGに接触する必要がないことを観察します。これにより、PKGの可用性要件が劇的に減少します。
o Choice of elliptic curves: This specification relies on the use of elliptic curves for both IBE and Elliptic Curve Diffie-Hellman exchange. When making a decision on the choice of elliptic curves, it is beneficial to choose two different elliptic curves -- a non-supersingular curve for the internal calculations of Elliptic Curve Diffie-Hellman values xP and yP, and a supersingular curve for the IBE encryption/decryption. For the calculations of Elliptic Curve Diffie-Hellman values, it is beneficial to use the curves recommended by NIST [FIPS-186]. These curves make the calculations simpler while keeping the security high. On the other hand, IBE systems are based on bilinear pairings. Therefore, the choice of an elliptic curve for
o 楕円曲線の選択：この仕様は、IBEと楕円曲線の両方のDiffie-Hellman Exchangeの両方で楕円曲線の使用に依存しています。楕円曲線の選択を決定する場合、2つの異なる楕円曲線を選択することが有益です - 楕円曲線diffie-hellman値xpとypの内部計算の非皮膚in膜曲線、およびIbe暗号化の補給曲線/復号化。楕円曲線diffie-hellman値の計算では、NIST [FIPS-186]が推奨する曲線を使用することが有益です。これらの曲線は、セキュリティを高く保ちながら計算をより簡単にします。一方、IBEシステムは双線形のペアリングに基づいています。したがって、楕円曲線の選択
IBE is restricted to a family of supersingular elliptic curves over finite fields of large prime characteristic. The appropriate elliptic curves for IBE are described in [RFC5091].
IBEは、大きなプライム特性の有限磁場上の上部象徴的な楕円曲線のファミリーに制限されています。IBEの適切な楕円曲線は[RFC5091]に記載されています。
o Implementation considerations: An implementation of IBAKE would consist of two primary modules, i.e., point addition operations over a NIST curve, and IBE operations over a supersingular curve. The implementation of both modules only needs to be aware of the following parameters: (a) the full description of the curves that are in use (fixed or negotiated), (b) the public parameters of the PKG used for the derivation of IBE private keys, and (c) the exact public identity of each IBAKE participant. The knowledge of these parameters is sufficient to perform Elliptic Curve Cryptography (ECC) operations in different terminals and produce the same results, independently of the implementation.
o 実装の考慮事項：IBakeの実装は、2つのプライマリモジュール、つまりNIST曲線上のポイント添加操作と、控えめな曲線上のIBE操作で構成されます。両方のモジュールの実装は、次のパラメーターのみを認識する必要があります：（a）使用中の曲線の完全な説明（固定または交渉）、（b）IBEプライベートの派生に使用されるPKGの公開パラメーターキー、および（c）各iBake参加者の正確な公的アイデンティティ。これらのパラメーターの知識は、異なる端子で楕円曲線暗号（ECC）操作を実行し、実装とは無関係に同じ結果を生成するのに十分です。
This document is based on the basic IBE protocol, as specified in [BF], [RFC5091]), [RFC5408], and [RFC5409], and as such inherits some properties of that protocol. For instance, by concatenating the "date" with the identity (to derive the public key), the need for any key revocation mechanisms is virtually eliminated. Moreover, by allowing the participants to acquire multiple private keys (e.g., for duration of contract) the availability requirements on the PKG are also reduced without any reduction in security. The granularity associated with the date is a matter of security policy and as such is a decision made by the PKG administrator. However, the granularity applicable to any given participant should be publicly available and known to other participants. For example, this information can be made available in the same venue that provides "public information" on a PKG server (i.e., P, sP) needed to execute IBE.
このドキュメントは、[BF]、[RFC5091]）、[RFC5408]、および[RFC5409]で指定されている基本的なIBEプロトコルに基づいており、そのようにそのプロトコルの一部の特性を継承します。たとえば、「日付」をアイデンティティと（公開鍵を導き出すために）連結することにより、キーの取り消しメカニズムの必要性は事実上排除されます。さらに、参加者が複数のプライベートキーを取得できるようにすることで（契約期間中など）、PKGの可用性要件もセキュリティを減らすことなく削減されます。日付に関連する粒度はセキュリティポリシーの問題であり、PKG管理者による決定です。ただし、特定の参加者に適用される粒度は、公開され、他の参加者に知られている必要があります。たとえば、この情報は、IBEを実行するために必要なPKGサーバー（つまり、P、SP）で「公開情報」を提供する同じ会場で利用できるようにすることができます。
Attacks on the cryptographic algorithms used in IBE are outside the scope of this document. It is assumed that any administrator will pay attention to the desired strengths of the relevant cryptographic algorithms based on an up-to-date understanding of the strength of these algorithms from published literature, as well as to known attacks.
IBEで使用される暗号化アルゴリズムへの攻撃は、このドキュメントの範囲外です。管理者は、公開された文献からのこれらのアルゴリズムの強さの最新の理解と既知の攻撃に基づいて、関連する暗号化アルゴリズムの望ましい強みに注意を払うと想定されています。
It is assumed that the PKGs are secure, not compromised, trusted, and will not engage in launching active attacks independently or in a collaborative environment. Nevertheless, if an active adversary can fool the parties into believing that it is a legitimate PKG, then it can mount a successful MitM attack. Therefore, care should be taken
PKGは安全であり、侵害されておらず、信頼されておらず、独立または共同環境でアクティブな攻撃を開始することはないと想定されています。それにもかかわらず、積極的な敵が当事者をだまして、それが正当なPKGであると信じることができれば、MITM攻撃を成功させることができます。したがって、注意を払う必要があります
when choosing a PKG. In addition, any malicious insider could potentially launch passive attacks (by decryption of one or more message exchanges offline). While it is in the best interest of administrators to prevent such an issue, it is hard to eliminate this problem. Hence, it is assumed that such problems will persist, and hence the session key agreement protocols are designed to protect participants from passive adversaries.
PKGを選択するとき。さらに、悪意のあるインサイダーは、パッシブ攻撃を発射する可能性があります（1つ以上のメッセージ交換をオフラインで復号化することにより）。そのような問題を防ぐことは管理者にとって最大の利益ですが、この問題を排除することは困難です。したがって、そのような問題が持続すると想定されているため、セッションキー契約プロトコルは、参加者を受動的な敵から保護するように設計されています。
It is also assumed that the communication between participants and their respective PKGs is secure. Therefore, in any implementation of the protocols described in this document, administrators of any PKG have to ensure that communication with participants is secure and not compromised.
また、参加者とそれぞれのPKGとの間のコミュニケーションが安全であると想定されています。したがって、このドキュメントに記載されているプロトコルの実装では、PKGの管理者は、参加者とのコミュニケーションが安全でないことを確認する必要があります。
Finally, concatenating the date to the identity ensures that the corresponding private key is applicable only to that date. This serves to limit the damage related to a leakage or compromise of private keys to just that date. This, in particular, eliminates the revocation mechanisms that are typical to various certificate-based public key protocols.
最後に、日付をIDに連結すると、対応する秘密鍵がその日にのみ適用できるようになります。これは、その日付の漏れまたはプライベートキーの妥協に関連する損害を制限するのに役立ちます。これにより、特に、さまざまな証明書ベースの公開キープロトコルに典型的な取り消しメカニズムが排除されます。
For the basic IBAKE protocol, from a cryptographic perspective, the following security considerations apply.
暗号化の観点から、基本的なIbakeプロトコルには、次のセキュリティに関する考慮事項が適用されます。
In every step, IBE is used, with the recipient's public key. This guarantees that only the intended recipient of the message and its corresponding PKG can decrypt the message [BF].
すべてのステップで、IBEが使用され、受信者の公開キーが使用されます。これにより、メッセージの意図された受信者とそれに対応するPKGのみがメッセージ[BF]を解読できることが保証されます。
Next, the use of identities within the encrypted payload is intended to eliminate some basic reflection attacks. For instance, suppose we did not use identities as part of the encrypted payload, in the first step of the IBAKE protocol exchange (i.e., MESSAGE_1 of Figure 1 in Section 3.1). Furthermore, assume that an adversary has access to the conversation between the Initiator and the Responder and can actively snoop packets and drop/modify them before routing them to the destination. For instance, assume that the IP source address and destination address can be modified by the adversary. After the first message is sent by the Initiator (to the Responder), the adversary can take over and trap the packet. Next, the adversary can modify the IP source address to include the adversary's IP address, before routing it on to the Responder. The Responder will assume that the request for an IBAKE session came from the adversary, and will execute step 2 of the IBAKE protocol exchange (i.e., MESSAGE_2 of Figure 1 in Section 3.1) but encrypt it using the adversary's public key. The above message can be decrypted by the adversary (and only by the adversary). In particular, since the second message
次に、暗号化されたペイロード内のアイデンティティの使用は、いくつかの基本的な反射攻撃を排除することを目的としています。たとえば、Ibakeプロトコル交換の最初のステップで、暗号化されたペイロードの一部としてIDを使用しなかったとします（つまり、セクション3.1の図1のメッセージ_1）。さらに、敵がイニシエーターとレスポンダーの間の会話にアクセスできると仮定し、宛先にルーティングする前にパケットを積極的にスヌープしてドロップ/変更できると仮定します。たとえば、IPソースアドレスと宛先アドレスが敵によって変更できると仮定します。最初のメッセージがイニシエーターによって（レスポンダーに）送信された後、敵はパケットを引き継いでトラップすることができます。次に、敵はIPソースアドレスを変更して、敵のIPアドレスを含めることができます。 Responderは、Ibakeセッションの要求が敵からのものであると想定し、Ibakeプロトコル交換のステップ2（つまり、セクション3.1の図1のMessage_2）を実行しますが、敵の公開鍵を使用して暗号化します。上記のメッセージは、敵によって（そして敵によってのみ）復号化される可能性があります。特に、2番目のメッセージ以降
includes the challenge sent by the Initiator to the Responder, the adversary will now learn the challenge sent by the Initiator. Following this, the adversary can carry on a conversation with the Initiator, "pretending" to be the Responder. This attack will be eliminated if identities are used as part of the encrypted payload. In summary, at the end of the exchange, both the Initiator and the Responder can mutually authenticate each other and agree on a session key.
イニシエーターからレスポンダーに送信された課題が含まれており、敵はイニシエーターから送られた課題を学びます。これに続いて、敵はイニシエーターと会話を続けることができます。この攻撃は、暗号化されたペイロードの一部としてIDが使用される場合、排除されます。要約すると、交換の終わりに、イニシエーターとレスポンダーの両方が相互に認証し、セッションキーに同意することができます。
Recall that IBE guarantees that only the recipient of the message can decrypt the message using the private key, with the caveat that the PKG that generated the private key of the recipient of the message can decrypt the message as well. However, the PKG cannot learn the public key xyP given xP and yP, based on the hardness of the Elliptic Curve Diffie-Hellman problem. This property of resistance to passive key escrow from the PKG is not applicable to the basic IBE protocols proposed in [RFC5091]), [RFC5408], and [RFC5409].
IBEは、メッセージの受信者を使用してメッセージの受信者のみがメッセージを使用してメッセージを解読できることを保証していることを思い出してください。メッセージの受信者の秘密鍵を生成したPKGがメッセージを復号化できることを保証します。ただし、楕円曲線diffie-hellmanの問題の硬度に基づいて、XPとYPが与えられたPKGは、XPとYPを与えられた公開キーXYPを学習することはできません。PKGからのパッシブキーエスクローに対する抵抗のこの特性は、[RFC5091]）、[RFC5408]、および[RFC5409]で提案されている基本的なIBEプロトコルには適用されません。
Observe that the protocol works even if the Initiator and Responder belong to two different PKGs. In particular, the parameters used for encryption to the Responder and parameters used for encryption to the Initiator can be completely different and independent of each other. Moreover, the elliptic curve used to generate the session key xyP can be completely different and can be chosen during the key exchange. If such flexibility is desired, then it would be required to add optional extra data to the protocol to exchange the algebraic primitives used in deriving the session key.
イニシエーターとレスポンダーが2つの異なるPKGに属している場合でも、プロトコルが機能することに注意してください。特に、暗号化に使用されるパラメーターと、イニシエーターへの暗号化に使用されるパラメーターは、まったく異なり、互いに独立している場合があります。さらに、セッションキーXYPを生成するために使用される楕円曲線は、まったく異なる場合があり、キー交換中に選択できます。このような柔軟性が必要な場合は、オプションの追加データをプロトコルに追加して、セッションキーの導出に使用される代数的プリミティブを交換する必要があります。
In addition to mutual authentication and resistance to passive escrow, the Diffie-Hellman property of the session key exchange guarantees perfect secrecy of keys. In other words, accidental leakage of one session key does not compromise past or future session keys between the same Initiator and Responder.
パッシブエスクローに対する相互認証と抵抗に加えて、セッションキーエクスチェンジのdiffie-hellmanプロパティは、キーの完全な秘密を保証します。言い換えれば、1つのセッションキーの偶発的な漏れは、同じイニシエーターとレスポンダーの間の過去または将来のセッションキーを妥協しません。
[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月。
[BF] Boneh, D. and M. Franklin, "Identity-Based Encryption from the Weil Pairing", in SIAM Journal on Computing, Vol. 32, No. 3, pp. 586-615, 2003.
[BF] Boneh、D。およびM. Franklin、「Weilペアリングからのアイデンティティベースの暗号化」、Siam Journal on Computing、Vol。32、No。3、pp。586-615、2003。
[EAP-IBAKE] Cakulev, V. and I. Broustis, "An EAP Authentication Method Based on Identity-Based Authenticated Key Exchange", Work in Progress, February 2012.
[eap-bake] Cakulev、V。and I. Broustis、「アイデンティティベースの認証されたキー交換に基づくEAP認証方法」、2012年2月の作業。
[FIPS-186] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS Pub 186-3, June 2009.
[FIPS-186]国立標準技術研究所、「デジタル署名標準（DSS）」、FIPS Pub 186-3、2009年6月。
[RFC5091] Boyen, X. and L. Martin, "Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems", RFC 5091, December 2007.
[RFC5091] Boyen、X。およびL. Martin、「アイデンティティベースの暗号標準（IBCS）＃1：BFおよびBB1暗号システムの上方向の曲線実装」、RFC 5091、2007年12月。
[RFC5408] Appenzeller, G., Martin, L., and M. Schertler, "Identity-Based Encryption Architecture and Supporting Data Structures", RFC 5408, January 2009.
[RFC5408] Appenzeller、G.、Martin、L。、およびM. Schertler、「アイデンティティベースの暗号化アーキテクチャとサポートデータ構造」、RFC 5408、2009年1月。
[RFC5409] Martin, L. and M. Schertler, "Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption Algorithms with the Cryptographic Message Syntax (CMS)", RFC 5409, January 2009.
[RFC5409] Martin、L。およびM. Schertler、「Boneh-Franklin and Boneh-Boyenのアイデンティティベースの暗号化アルゴリズムを暗号化メッセージ構文（CMS）とともに使用する」、RFC 5409、2009年1月。
Authors' Addresses
著者のアドレス
Violeta Cakulev Alcatel Lucent 600 Mountain Ave. 3D-517 Murray Hill, NJ 07974 US
Violeta Cakulev Alcatel Lucent 600 Mountain Ave. 3D-517 Murray Hill、NJ 07974 US
Phone: +1 908 582 3207
EMail: violeta.cakulev@alcatel-lucent.com
Ganapathy S. Sundaram Alcatel Lucent 600 Mountain Ave. 3D-517 Murray Hill, NJ 07974 US
Ganapathy S. Sundaram Alcatel Lucent 600 Mountain Ave. 3D-517 Murray Hill、NJ 07974 US
Phone: +1 908 582 3209
EMail: ganesh.sundaram@alcatel-lucent.com
Ioannis Broustis Alcatel Lucent 600 Mountain Ave. 3D-526 Murray Hill, NJ 07974 US
Ioannis Broustis Alcatel Lucent 600 Mountain Ave. 3D-526 Murray Hill、NJ 07974 US
Phone: +1 908 582 3744
EMail: ioannis.broustis@alcatel-lucent.com