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
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）に基づいています。同じ柔軟性を提供しながら、IDベース暗号（IBE）プロトコルの新興分野は、秘密鍵ジェネレータ（PKG）を経由してインフラストラクチャ要件の簡素化を可能にします。しかし、IBE方式の一つの重要な制限は、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 Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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 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.
最近では、IDベース暗号（IBE）プロトコルは、秘密鍵ジェネレータ（PKG）とPKIを置き換えることにより、公開鍵メソッドの実行可能な代替案として提案されています。しかし、IBE方式の一つの重要な制限は、PKGは望ましくない結果で、事実上のキーエスクローエンティティ（通信データを復号化するのに十分な情報を持っている、すなわち、エンティティ）になってしまうことができることです。他の制限は、通信当事者間の相互認証の欠如です。この文書では、キーエスクローの問題に悩まされないアイデンティティベースの認証鍵暗号（IBAKE）プロトコルを指定し、それが相互認証を提供します。また、この文書に記載方式が同一自体に示される期間の終了時に秘密鍵の自動満了をもたらす、時間結合パブリックアイデンティティと対応する公開鍵と秘密鍵の使用を可能にします。パブリックアイデンティティの自己満了すると、証明書で使用される伝統的なリアルタイムの妥当性の検証と失効手続きは必要ありません。公共のアイデンティティは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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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].
IDベース暗号（IBE）は、公開鍵はアイデンティティと公開パラメータのセット、および公開鍵から計算することに対応する秘密鍵から計算することを可能にする公開鍵暗号化技術です。公開鍵は、受信者が対応する秘密鍵を使って復号化することができ、メッセージを暗号化するためにイニシエータによって使用することができます。 IBEフレームワークは[RFC5091]、[RFC5408]及び[RFC5409]で定義されています。
EC Elliptic Curve
EC楕円曲線
IBE Identity-Based Encryption
IBE IDベース暗号化
IBAKE Identity-Based Authenticated Key Exchange
IBAKEアイデンティティベースの認証鍵交換
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は、Aは、通常、アイデンティティに基づいてE、上、すなわち、H1（A）= QA、文字列を受け取り、楕円曲線上の点に割り当て既知のハッシュ関数です。
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-IBAKE]を参照）。
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 this encrypted information in MESSAGE_1 sent to the Responder. In this step, encryption refers to IBE as described in [RFC5091] and [RFC5408].
イニシエータは、ランダムXを選択します。最初のステップでは、開始剤は、（それ自体に加えはEに添加法を使用して時間をX、E上の点として、即ち、P）XPを算出します。 XP、IDI、およびレスポンダの公開鍵を用いてIDRを暗号化（例えば、K_PUBr = H1（IDR ||日付））。そして、レスポンダに送信されたMESSAGE_1で、この暗号化された情報を含んでいます。 [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を選択し、y・Pとを計算します。レスポンダは、イニシエータの公開鍵（例えば、K_PUBi = H1（IDiと||日付））を使用して、イニシエータのID（IDiを）、自身のアイデンティティ（IDR）、XP、およびy・PとをIBEは、暗号化します。 Responderは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を受信し、IBE-復号化時に、y・Pとを取得します。その後、イニシエータはレスポンダに、IBE暗号化IDI、IDR、およびy・Pとを含みMESSAGE_3は、送信されます。この時点で、イニシエータとレスポンダの両方が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新鮮な、ランダムな値を使用しなければなりません。イニシエータは、次にXP、IDI、およびレスポンダの公開鍵（例えば、K_PUBr = H1（IDR ||日付））を用いて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を選択し、y・Pとを計算します。レスポンダは、プロトコルの各実行時に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、およびy・Pとを暗号化します。
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 y・Pとを取得します。
o Encrypt its own identity (IDi), the Responder's identity (IDr), and yP using the Responder's public key (K_PUBi).
Oレスポンダの公開鍵（K_PUBi）を使用して、独自のアイデンティティ（IDiを）、レスポンダのアイデンティティ（IDR）を暗号化、およびy・Pと。
Initiator ----> Responder
MESSAGE_3 = E(K_PUBr, IDi || IDr || yP)
Mesejtri = A（kepubra、インドラ|| ||このアプリ）
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受信アップメッセージ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のは、アクティブなMITM（中間者）攻撃をマウントされません）PKGのが信頼できると行儀されていることを前提として与えられ、彼らは、セッション鍵を計算することはできません。これは、楕円曲線のDiffie-Hellman問題の硬さです。言い換えれば、XPおよびy・Pと与えられ、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は、それが秘密鍵を発行するユーザーを偽装しません） - MESSAGE_2を受信すると、XP、以来、レスポンダの信憑性を確認することができますイニシエータ唯一のレスポンダによってMESSAGE_1のコンテンツの復号後MESSAGE_2で送られた可能性があります。 y・Pとは、唯一のイニシエータによってMESSAGE_2の内容を正しく復号化した後、バックMESSAGE_3で送られてきた可能性があるため同様に、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.
パスワードなし○：明らかに、IBAKEプロトコルは、パスワードやイニシエータとレスポンダの間で秘密鍵のいずれかのオフライン交換を必要としません。実際に、この方法は、任意の通信ネットワークを介して初めて通信する任意の二つの当事者にも適用可能です。唯一の要件は、イニシエータとレスポンダの両方が互いの公開鍵と対応する秘密鍵を生成した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の可用性：PKGのが劇的PKGの上の可用性の要件を低減IBAKEプロトコル交換、中に連絡する必要はないことを確認します。
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交換の両方のための楕円曲線の使用に依存しています。楕円曲線の選択に決定を行う際には、二つの異なる楕円曲線を選択することが有益である - 楕円曲線のDiffie-Hellmanの内部の計算のための非超特異曲線は、XPとy・Pとし、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の実装では、超特異曲線上NIST曲線上の2つの主要モジュール、すなわち、ポイント加算演算から成り、及びIBE操作だろう。両方のモジュールの実装は次のパラメータのみを認識する必要がある：（a）の（固定またはネゴシエート）使用されている曲線の完全な記述は、（b）は、PKGの公開パラメータは、IBE秘密を導出するために使用しましたキー、および（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の管理者によって行われた決定です。しかし、任意の参加者に適用される粒度は、一般に公開し、他の参加者に知らなければなりません。例えば、この情報は（即ち、P、SP）がIBEを実行するために必要なPKGサーバの「公開情報」を提供するのと同じ場所で利用可能にすることができます。
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 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のは信頼され、損なわれない、安全であることを想定して、独立して、アクティブな攻撃を開始してか、コラボレーション環境に従事しません。アクティブな敵が、それは正当なPKGであることを信じるように、当事者をだますことができればそれにもかかわらず、それが成功したのMITM攻撃を仕掛けることができます。 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.
最後に、アイデンティティに日付を連結すると、対応する秘密鍵が唯一のその日に適用可能であることを保証します。これは、ちょうどその日に、秘密鍵の漏洩や妥協に関連する損傷を制限するのに役立ちます。これは、特に、様々な証明書ベースの公開鍵プロトコルに典型的である失効メカニズムを排除します。
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 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.
次に、暗号化されたペイロード内のアイデンティティの使用はいくつかの基本的な反射攻撃を排除することを意図しています。例えば、我々はIBAKEプロトコル交換の最初の工程では、暗号化されたペイロードの一部としてのアイデンティティを使用しなかったと仮定し（すなわち、3.1節にある図1のMESSAGE_1）。さらに、敵は、イニシエータとレスポンダとの間の会話へのアクセス権を持ち、積極的/パケットドロップをスヌープ宛先にルーティングする前にそれらを変更することができると仮定する。例えば、IPソースアドレスと宛先アドレスは、敵によって改変することができると仮定する。最初のメッセージが（レスポンダ）はイニシエータによって送信された後、敵はパケットを引き継ぐおよびトラップすることができます。次に、敵はレスポンダにそれをルーティングする前に、敵のIPアドレスが含まれるように送信元IPアドレスを変更することができます。レスポンダはIBAKEセッションの要求が敵対から来たと仮定し、IBAKEプロトコル交換（すなわち、3.1節にある図1のMESSAGE_2）のステップ2を実行するが、敵対者の公開鍵を使って暗号化します。上記メッセージは、敵（とのみ敵による）によって復号することができます。 2番目のメッセージは、レスポンダにイニシエータによって送信されたチャレンジを含んでいるため、特に、敵は今、イニシエータによって送信された課題を学びます。これに続いて、敵がレスポンダする「ふり」、イニシエータとの会話を続けることができます。アイデンティティは暗号化されたペイロードの一部として使用されている場合は、この攻撃が排除されます。要約すると、為替の終わりに、イニシエータとレスポンダの両方が相互に認証することができ、セッションキーについては同意します。
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].
メッセージの受信者のみがメッセージの受信者の秘密鍵を生成したPKGは、同様のメッセージを復号化できることを警告して、秘密鍵を使用してメッセージを復号化できIBEを保証ことを思い出してください。しかし、PKGは、楕円曲線のDiffie-Hellman問題の硬度に基づいXPおよびy・Pと指定された公開鍵XYPを学ぶことができません。このPKGからパッシブキーエスクローに対する耐性のプロパティ[RFC5091]で提案されている基本的なIBEプロトコルに適用されない）、[RFC5408]及び[RFC5409]。
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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.
コンピューティング、巻上SIAM Journalで[BF] Boneh、D.とM.フランクリン、「ワイルペアリングからIDベース暗号化」、。 32、第3号、頁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-IBAKE] Cakulev、V.およびI. Broustis、 "IDベースの認証鍵交換に基づいて、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 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.マーチン、 "IDベース暗号化規格（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]アッペンツェル、G.、マーティン、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]マーティン、L.およびM. Schertler、RFC 5409 "暗号メッセージ構文（CMS）とBoneh-フランクリンとBoneh-Boyenアイデンティティベースの暗号化アルゴリズムを使用する" を、2009年1月。
Authors' Addresses
著者のアドレス
Violeta Cakulev Alcatel Lucent 600 Mountain Ave. 3D-517 Murray Hill, NJ 07974 US
するVioleta Cakulevアルカテル・ルーセント600マウンテンアベニュー3D-517マレーヒル、NJ 07974米国
Phone: +1 908 582 3207 EMail: violeta.cakulev@alcatel-lucent.com
電話：+1 908 582 3207 Eメール：violeta.cakulev@alcatel-lucent.com
Ganapathy S. Sundaram Alcatel Lucent 600 Mountain Ave. 3D-517 Murray Hill, NJ 07974 US
ガナパシーS. Sundaramアルカテル・ルーセント600マウンテンアベニュー3D-517マレーヒル、NJ 07974米国
Phone: +1 908 582 3209 EMail: ganesh.sundaram@alcatel-lucent.com
電話：+1 908 582 3209 Eメール：ganesh.sundaram@alcatel-lucent.com
Ioannis Broustis Alcatel Lucent 600 Mountain Ave. 3D-526 Murray Hill, NJ 07974 US
ジョンVroustisアルカテルLykent 600マウンテンアベニューxD-526マレーヒル、SG 07974米国
Phone: +1 908 582 3744 EMail: ioannis.broustis@alcatel-lucent.com
電話：+1 908 582 3744 Eメール：ioannis.broustis@alcatel-lucent.com