RFC 7859 - Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7859
タイトル : RFC 7859 - モバイルアドホックネットワーク（MANET）ルーティングプロトコルのIDベースの署名
翻訳編集 : 自動生成

[要約] 要約：RFC 7859は、モバイルアドホックネットワーク（MANET）ルーティングプロトコルのためのIDベースの署名に関するものである。目的：このRFCの目的は、MANETルーティングプロトコルにおいてセキュリティと認証を向上させるために、IDベースの署名を使用する方法を提案することである。

Internet Engineering Task Force (IETF)                       C. Dearlove
Request for Comments: 7859                                   BAE Systems
Category: Experimental                                          May 2016
ISSN: 2070-1721

Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols

モバイルアドホックネットワーク（MANET）ルーティングプロトコルのIDベースの署名

Abstract

概要

This document extends RFC 7182, which specifies a framework for (and specific examples of) Integrity Check Values (ICVs) for packets and messages using the generalized packet/message format specified in RFC 5444. It does so by defining an additional cryptographic function that allows the creation of an ICV that is an Identity-Based Signature (IBS), defined according to the Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI) algorithm specified in RFC 6507.

このドキュメントはRFC 7182を拡張します。RFC7182は、RFC 5444で指定されている一般化されたパケット/メッセージ形式を使用して、パケットおよびメッセージの整合性チェック値（ICV）のフレームワーク（および特定の例）を指定します。アイデンティティベースの署名（IBS）であるICVの作成。これは、RFC 6507で指定されたアイデンティティベースの暗号化（ECCSI）アルゴリズムの楕円曲線ベースの証明書なしの署名に従って定義されます。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.

このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。

This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7859.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7859で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Applicability Statement . . . . . . . . . . . . . . . . . . .   5
   4.  Specification . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Cryptographic Function  . . . . . . . . . . . . . . . . .   5
     4.2.  ECCSI Parameters  . . . . . . . . . . . . . . . . . . . .   6
     4.3.  Identity  . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
     6.1.  Experimental Status . . . . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Appendix A.  Example  . . . . . . . . . . . . . . . . . . . . . .  12
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17

1. Introduction

1. はじめに

[RFC7182] defines Integrity Check Value (ICV) TLVs for use in packets and messages that use the generalized MANET packet/message format defined in [RFC5444]. This specification extends the TLV definitions therein by defining two new cryptographic function code points from within the registries set up by [RFC7182]. This allows the use of an Identity-Based Signature (IBS) as an ICV. An IBS has an additional property that is not shared by all of the previously specified ICVs; it not only indicates that the protected packet or message is valid, but also verifies the originator of the packet/message.

[RFC7182]は、[RFC5444]で定義されている一般化されたMANETパケット/メッセージ形式を使用するパケットおよびメッセージで使用するための整合性チェック値（ICV）TLVを定義します。この仕様は、[RFC7182]によって設定されたレジストリ内から2つの新しい暗号化機能コードポイントを定義することにより、TLV定義を拡張します。これにより、IDベースの署名（IBS）をICVとして使用できます。 IBSには、以前に指定されたすべてのICVで共有されていない追加のプロパティがあります。これは、保護されたパケットまたはメッセージが有効であることを示すだけでなく、パケット/メッセージの発信者を確認します。

This specification assumes that each router (i.e., each originator of [RFC5444] format packets/messages) has an identity that may be tied to the packet or message. The router may have more than one identity but will only use one for each ICV TLV. The cryptographic strength of the IBS is not dependent on the choice of identity.

この仕様では、各ルーター（[RFC5444]形式のパケット/メッセージの各発信元）が、パケットまたはメッセージに関連付けられている可能性のあるIDを持っていると想定しています。ルーターには複数のIDがある場合がありますが、ICV TLVごとに1つしか使用しません。 IBSの暗号強度は、IDの選択に依存しません。

Two options for the choice of identity are supported (as reflected by the two code points allocated). In the first option, the identity can be any octet sequence (up to 255 octets) included in the ICV TLV. In the second option, the octet sequence is preceded by an address, either the IP source address for a Packet TLV or the message originator address for a Message TLV or an Address Block TLV. In particular, the second option allows just the address to be used as an identity.

IDの選択には2つのオプションがサポートされています（割り当てられた2つのコードポイントによって反映されます）。最初のオプションでは、IDはICV TLVに含まれる任意のオクテットシーケンス（最大255オクテット）にすることができます。 2番目のオプションでは、オクテットシーケンスの前に、パケットTLVのIP送信元アドレスか、メッセージTLVまたはアドレスブロックTLVのメッセージ発信者アドレスのいずれかのアドレスが続きます。特に、2番目のオプションでは、アドレスをIDとしてのみ使用できます。

Identity-based signatures allow identification of the originator of information in a packet or message. They thus allow additional security functions, such as revocation of an identity. (A router could also then remove all information recorded as from that revoked originator; the Optimized Link State Routing Protocol Version 2 (OLSRv2) [RFC7181], an expected user of this specification, can do this.) When applied to messages (rather than packets), this can significantly reduce the damage that a compromised router can inflict on the network.

IDベースの署名により、パケットまたはメッセージ内の情報の発信者を識別できます。したがって、IDの失効などの追加のセキュリティ機能を使用できます。（ルーターは、取り消された発信者から記録されたすべての情報を削除することもできます。この仕様の想定ユーザーであるOptimized Link State Routing Protocol Version 2（OLSRv2）[RFC7181]がこれを実行できます。）メッセージに適用される場合（パケット）、これにより、侵害されたルーターがネットワークに与える可能性のある損傷を大幅に減らすことができます。

Identity-based signatures are based on forms of asymmetric (public key) cryptography - Identity-Based Encryption (IBE). Compared to symmetric cryptographic methods (such as HMAC and AES), IBE and IBS methods avoid requiring a shared secret key that results in a single point of failure vulnerability. Compared to more widely used asymmetric (public key) cryptographic methods (such as RSA and ECDSA), IBE and IBS methods have a major advantage and a major disadvantage.

IDベースの署名は、非対称（公開キー）暗号化の形式-IDベースの暗号化（IBE）に基づいています。対称暗号化方式（HMACやAESなど）と比較して、IBEおよびIBS方式は、共有秘密鍵を必要としないため、単一障害点の脆弱性が発生します。広く使用されている非対称（公開キー）暗号化方式（RSAやECDSAなど）と比較すると、IBEとIBSの方式には大きな利点と欠点があります。

The advantage referred to is that each router can be configured once (for its key lifetime) by a trusted authority, independently of all other routers. Thus, a router can connect to the authority (typically in a secure environment) to receive a private key or can have a private key delivered securely (out of band) from the authority. During normal operation of the MANET, there is no need for the trusted authority to be connected to the MANET or even to still exist. Additional routers can be authorized with no reference to previously authorized routers (the trusted authority must still exist in this case). A router's public key is its identity, which when tied to a packet or message (as is the case when using an address as, or as part of, the identity) means that there is no need for public key certificates or a certificate authority, and a router need not retain key material for any other routers.

言及されている利点は、他のすべてのルーターとは無関係に、信頼できる機関が各ルーターを（そのキーの有効期間について）1回構成できることです。したがって、ルーターは（通常は安全な環境で）機関に接続して秘密鍵を受信したり、秘密鍵を機関から（帯域外で）安全に配信したりできます。 MANETの通常の動作中、信頼できる機関がMANETに接続されていたり、存在していたりする必要はありません。追加のルーターは、以前に承認されたルーターを参照せずに承認できます（この場合、信頼できる機関がまだ存在している必要があります）。ルーターの公開鍵はそのアイデンティティであり、パケットまたはメッセージに関連付けられている場合（アイデンティティとして、またはアイデンティティの一部としてアドレスを使用する場合のように）は、公開鍵証明書または認証局が必要ないことを意味します。また、ルーターは他のルーターの主要な資料を保持する必要はありません。

The disadvantage referred to is that the trusted authority has complete authority, even more so than a conventional certificate authority. Routers cannot generate their own private keys, only the trusted authority can do that. Through the master secret held by the trusted authority, it could impersonate any router (existing or not). When used for IBE (not part of this specification), the trusted authority can decrypt anything. However, note that the shared secret key options described in [RFC7182] also have this limitation.

言及されている不利な点は、信頼できる機関が完全な権限を持っていることです。ルーターは独自の秘密鍵を生成できません。信頼できる機関だけが生成できます。信頼できる機関が保持しているマスターシークレットを介して、ルーターの偽装（既存または不在）が可能です。 IBE（この仕様の一部ではない）に使用すると、信頼できる機関は何でも解読できます。ただし、[RFC7182]で説明されている共有秘密鍵オプションにもこの制限があることに注意してください。

There are alternative mathematical realizations of identity-based signatures. This specification uses one that has been previously published as [RFC6507], known as Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI). Similar to other IBE/IBS approaches, it is based on the use of elliptic curves. Unlike some, it does not use "pairings" (bilinear maps from a product of two elliptic curve groups to another group). It thus may be easier to implement and more efficient than some alternatives, although with a greater signature size than some. This specification allows the use of any elliptic curve that may be used by [RFC6507].

アイデンティティベースの署名には、代替の数学的実現があります。この仕様では、以前に[RFC6507]として公開されたものを使用します。これは、IDベースの暗号化（ECCSI）のための楕円曲線ベースの証明書なし署名として知られています。他のIBE / IBSアプローチと同様に、楕円曲線の使用に基づいています。一部とは異なり、「ペアリング」（2つの楕円曲線グループの積から別のグループへの双線形マップ）は使用しません。したがって、一部の署名サイズよりも署名サイズが大きくなりますが、一部の代替案よりも実装が簡単で効率的です。この仕様では、[RFC6507]で使用できる楕円曲線を使用できます。

The computational load imposed by ECCSI (and, perhaps more so by other IBS methods) is not trivial, though it depends significantly on the quality of implementation of the required elliptic curve and other mathematical functions. For a security level of 128 bits, the ICV data length is 129 octets, which is longer than for alternative ICVs specified in [RFC7182] (e.g., 32 octets for the similar strength HMAC-SHA-256). The signature format used could have been slightly shortened (to 97 octets) by using a compressed representation of an elliptic curve point, however, at the expense of some additional work when verifying a signature and loss of direct compatibility with [RFC6507], and implementations thereof.

必要な楕円曲線やその他の数学関数の実装の質に大きく依存しますが、ECCSIによって（そしておそらく他のIBSメソッドによってさらに多く）課せられる計算負荷は自明ではありません。 128ビットのセキュリティレベルの場合、ICVデータ長は129オクテットであり、[RFC7182]で指定された代替のICVよりも長くなります（たとえば、同様の強度のHMAC-SHA-256の場合は32オクテット）。使用される署名フォーマットは、楕円曲線ポイントの圧縮表現を使用することにより、わずかに（97オクテットに）短縮できた可能性がありますが、署名を検証する際の追加作業と[RFC6507]との直接の互換性の損失、および実装が犠牲になります。その。

The trusted authority is referred to in [RFC6507] as the Key Management Service (KMS). That term will be used in the rest of this specification.

信頼できる機関は、[RFC6507]でキー管理サービス（KMS）と呼ばれています。この用語は、この仕様の残りの部分で使用されます。

2. Terminology

2. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。

Additionally, this document uses the terminology of [RFC5444], [RFC6507], and [RFC7182].

また、このドキュメントでは、[RFC5444]、[RFC6507]、および[RFC7182]という用語を使用しています。

3. Applicability Statement

3. 適用性ステートメント

This specification adds an additional option to the framework specified in [RFC7182] for use by packets and messages formatted as described in [RFC5444]. It is applicable as described in [RFC7182] and is subject to the additional comments in Section 6, particularly regarding the role of the trusted authority (KMS).

この仕様は、[RFC7182]で指定されたフレームワークに、[RFC5444]で説明されているようにフォーマットされたパケットおよびメッセージで使用するための追加オプションを追加します。 [RFC7182]で説明されているように適用可能であり、特に信頼できる機関（KMS）の役割に関して、セクション6の追加コメントの対象となります。

Specific examples of protocols for which this specification is suitable are Neighborhood Discovery Protocol (NHDP) [RFC6130] and OLSRv2 [RFC7181].

この仕様が適しているプロトコルの具体例は、近隣探索プロトコル（NHDP）[RFC6130]とOLSRv2 [RFC7181]です。

4. Specification

4. 仕様

4.1. Cryptographic Function

4.1. 暗号化機能

This specification defines a cryptographic function named ECCSI that is implemented as specified as the "sign" function in Section 5.2.1 of [RFC6507]. To use that specification:

この仕様は、[RFC6507]のセクション5.2.1で「sign」関数として指定されたとおりに実装されるECCSIという名前の暗号化関数を定義します。その仕様を使用するには：

o The ICV is not calculated as cryptographic-function(hash-function(content)) as defined in [RFC7182] but (like the HMAC ICVs defined in [RFC7182]) uses the hash function within the cryptographic function. The option "none" is not permitted for hash-function, and the hash function must have a known fixed length of N octets (as specified in Section 4.2).

o ICVは、[RFC7182]で定義されているようにcryptographic-function（hash-function（content））として計算されませんが、（[RFC7182]で定義されているHMAC ICVと同様に）暗号化関数内のハッシュ関数を使用します。オプション "none"はハッシュ関数には使用できません。ハッシュ関数には既知の固定長Nオクテットが必要です（セクション4.2で指定）。

o M, used in [RFC6507], is "content" as specified in [RFC7182].

o [RFC6507]で使用されるMは、[RFC7182]で指定されている「コンテンツ」です。

o ID, used in [RFC6507], is as specified in Section 4.3.

o [RFC6507]で使用されるIDは、セクション4.3で指定されています。

o Key Management Service Public Authentication Key (KPAK), Secret Signing Key (SSK), and Public Validation Token (PVT), which are provided by the KMS, are as specified in Sections 4.2 and 5.1.1 of [RFC6507].

o 鍵管理サービスの公開認証鍵（KPAK）、秘密署名鍵（SSK）、および公開検証トークン（PVT）は、KMSによって提供され、[RFC6507]のセクション4.2および5.1.1で指定されています。

The length of the signature is 4N+1 octets (as specified in [RFC6507]) whose affine coordinate format (including an octet valued 0x04 to identify this) is used unchanged.

署名の長さは4N + 1オクテット（[RFC6507]で指定）であり、そのアフィン座標形式（これを識別するために0x04のオクテットを含む）がそのまま使用されます。

Verification of the ICV is not implemented by the receiver recalculating the ICV and comparing with the received ICV, as it is necessarily incapable of doing so. Instead, the receiver evaluates the "verify" function described in Section 5.2.2 of [RFC6507], which may pass or fail.

ICVの検証は、受信機がICVを再計算し、受信したICVと比較することによって実装されていません。代わりに、受信者は、[RFC6507]のセクション5.2.2で説明されている「検証」機能を評価します。この機能は、成功する場合と失敗する場合があります。

To use that function M, KPAK, SSK, and PVT are as specified above, while the Identifier (ID) is deduced from the received packet or message (as specified in Section 4.3) using the <key-id> element in the <ICV-value>. This element need not match that used by the receiver, and thus when using this cryptographic function, multiple ICV TLVs differing only in their <key-id> or in the choice of cryptographic function from the two defined in this specification SHOULD NOT be used unless routers are administratively configured to recognize which to verify.

その関数を使用するには、M、KPAK、SSK、およびPVTは上記のとおりですが、識別子（ID）は、<ICVの<key-id>要素を使用して、受信したパケットまたはメッセージ（セクション4.3で指定）から推定されます。 -value>。この要素は受信者が使用する要素と一致する必要はないため、この暗号機能を使用する場合、<key-id>のみ、またはこの仕様で定義されている2つの暗号機能の選択のみが異なる複数のICV TLVを使用しないでください。ルーターは、検証する対象を認識するように管理上構成されています。

Routers MAY be administratively configured to reject an ICV TLV using ECCSI based on part or all of <key-id>: for example, if this encodes a time after which this identity is no longer valid (as described in Section 4.3).

<key-id>の一部またはすべてに基づいてECCSIを使用してICV TLVを拒否するようにルーターを管理上構成できます（たとえば、これがこのIDが無効になるまでの時間をエンコードする場合（セクション4.3で説明））。

4.2. ECCSI Parameters

4.2. ECCSIパラメータ

Section 4.1 of [RFC6507] specifies parameters n, N, p, E, B, G, and q. The first of these, n, is specified as "A security parameter; the size in bits of the prime p over which elliptic curve cryptography is to be performed." For typical security levels (e.g., 128, 192, and 256 bits), n must be at least twice the required bits of security; see Section 5.6.1 of [NIST-SP-800-57].

[RFC6507]のセクション4.1は、パラメータn、N、p、E、B、G、およびqを指定しています。これらの最初のnは、「セキュリティパラメータ、楕円曲線暗号化が実行される素数pのビット単位のサイズ」として指定されます。一般的なセキュリティレベル（128、192、256ビットなど）では、nは必要なセキュリティビットの少なくとも2倍でなければなりません。 [NIST-SP-800-57]のセクション5.6.1を参照してください。

Selection of an elliptic curve, and all related parameters, MUST be made by administrative means, and known to all routers. Following [RFC6507], it is RECOMMENDED that the curves and base points defined in Appendix D.1.2 of [NIST-FIPS-186-4] be used (note that n in that document is q in [RFC6507]). However, an alternative curve MAY be used.

楕円曲線と関連するすべてのパラメーターの選択は、管理手段によって行われ、すべてのルーターに知られている必要があります。 [RFC6507]に続いて、[NIST-FIPS-186-4]の付録D.1.2で定義された曲線とベースポイントを使用することをお勧めします（そのドキュメントのnは[RFC6507]のqであることに注意してください）。ただし、別の曲線を使用してもかまいません。

The parameter that is required by this specification is N, which is defined as Ceiling(n/8). The hash function used must create an output of size N octets. For example, for 128 bit security, with n = 256 and N = 32, the RECOMMENDED hash function is SHA-256. The signature (i.e., <ICV-data>) length is 4N+1 octets, i.e., 129 octets for N = 32.

この仕様で必要なパラメータはNで、Ceiling（n / 8）として定義されています。使用されるハッシュ関数は、サイズNオクテットの出力を作成する必要があります。たとえば、128ビットのセキュリティで、n = 256およびN = 32の場合、RECOMMENDEDハッシュ関数はSHA-256です。署名（つまり、<ICV-data>）の長さは4N + 1オクテット、つまりN = 32の場合は129オクテットです。

Note that [RFC6507] actually refers to the predecessor to [NIST-FIPS-186-4], but the latest version is specified here; there are no significant differences in this regard.

[RFC6507]は実際には[NIST-FIPS-186-4]の前身を指しますが、最新バージョンがここに指定されています。この点で大きな違いはありません。

4.3. Identity

4.3. 身元

There are two options for ID as used by [RFC6507], which are indicated by there being two code points allocated for this cryptographic function, see Section 5.

[RFC6507]で使用されるIDには2つのオプションがあり、この暗号関数に2つのコードポイントが割り当てられていることで示されています。セクション5を参照してください。

o For the cryptographic function ECCSI, ID is the element <key-id> defined in Section 12.1 of [RFC7182]. This MUST NOT be empty.

o 暗号化機能ECCSIの場合、IDは[RFC7182]のセクション12.1で定義されている要素<key-id>です。これを空にすることはできません。

o For the cryptographic function ECCSI-ADDR, ID is the concatenation of an address (in network byte order) and the element <key-id> defined in Section 12.1 of [RFC7182], where the latter MAY be empty.

o 暗号化機能ECCSI-ADDRの場合、IDは（ネットワークバイト順の）アドレスと、[RFC7182]のセクション12.1で定義されている要素<key-id>を連結したもので、後者は空の場合があります。

* For a Packet TLV, this address is the IP source address of the IP datagram in which this packet is included.

* パケットTLVの場合、このアドレスは、このパケットが含まれるIPデータグラムのIP送信元アドレスです。

* For a Message TLV or an Address Block TLV, this address is the message originator address (the element <msg-orig-addr> defined in [RFC5444]) if that address is present; if it is not present and the message is known to have traveled only one hop, then the IP source address of the IP datagram in which this message is included is used. Otherwise, no address is defined and the message MUST be rejected. (Note that HELLO messages specified in NHDP [RFC6130] and used in OLSRv2 [RFC7181] always only travel one hop; hence, their IP source address SHOULD be used if no originator address is present.)

* メッセージTLVまたはアドレスブロックTLVの場合、このアドレスが存在する場合、このアドレスはメッセージ発信元アドレス（[RFC5444]で定義されている要素<msg-orig-addr>）です。メッセージが存在せず、メッセージが1ホップだけ移動したことがわかっている場合は、このメッセージが含まれているIPデータグラムのIP送信元アドレスが使用されます。それ以外の場合、アドレスは定義されず、メッセージは拒否される必要があります。（NHDP [RFC6130]で指定され、OLSRv2 [RFC7181]で使用されるHELLOメッセージは、常に1ホップしか移動しないことに注意してください。したがって、発信元アドレスが存在しない場合は、IP送信元アドレスを使用する必要があります。）

The element <key-id> MAY be (for the cryptographic function ECCSI-ADDR) or include (for either cryptographic function) a representation of the identity expiry time. This MAY use one of the representations of time defined for the TIMESTAMP TLV in [RFC7182]. A RECOMMENDED approach is to use the cryptographic function ECCSI-ADDR with element <key-id> containing the single octet representing the type of the time, normally used as the TIMESTAMP TLV Type Extension (defined in [RFC7182], Table 9), or any extension thereof, followed by the time as so represented, normally used as the TIMESTAMP TLV Value.

要素<key-id>は、IDの有効期限の表現（暗号化機能ECCSI-ADDRの場合）または含める（いずれかの暗号化機能の場合）ことができます（MAY）。これは[RFC7182]のTIMESTAMP TLVのために定義された時間の表現の1つを使用するかもしれません。推奨されるアプローチは、時間のタイプを表す単一のオクテットを含む要素<key-id>で暗号関数ECCSI-ADDRを使用することであり、通常はTIMESTAMP TLVタイプ拡張（[RFC7182]、表9で定義）として使用されます。またはその延長、通常はTIMESTAMP TLV値として使用される、そのように表される時間が後に続きます。

Note that the identity is formatted as specified in [RFC6507] and thus does not need a length field incorporated into it by this specification.

アイデンティティは[RFC6507]で指定されているようにフォーマットされているため、この仕様で組み込まれている長さフィールドは必要ありません。

5. IANA Considerations

5. IANAに関する考慮事項

IANA has allocated the following two new values in the "Cryptographic Functions" registry under "Mobile Ad Hoc NETwork Parameters" registry and modified the unassigned range accordingly.

IANAは、「モバイルアドホックネットワークパラメータ」レジストリの「暗号化機能」レジストリに次の2つの新しい値を割り当て、割り当てられていない範囲を適宜変更しました。

   +-------+------------+----------------------------------+-----------+
   | Value | Algorithm  |           Description            | Reference |
   +-------+------------+----------------------------------+-----------+
   |   7   |   ECCSI    |         ECCSI [RFC6507]          |  RFC 7859 |
   |   8   | ECCSI-ADDR | ECCSI [RFC6507] with an address  |  RFC 7859 |
   |       |            | (source or originator) joined to |           |
   |       |            |             identity             |           |
   | 9-251 |            |    Unassigned; Expert Review     |           |
   +-------+------------+----------------------------------+-----------+

Table 1: Cryptographic Function Registry

表1：暗号化機能レジストリ

6. Security Considerations

6. セキュリティに関する考慮事項

This specification extends the security framework for MANET routing protocols specified in [RFC7182] by adding cryptographic functions (in two forms, according to how identity is specified).

この仕様は、[RFC7182]で指定されたMANETルーティングプロトコルのセキュリティフレームワークを拡張し、暗号機能を追加します（IDの指定方法に応じて2つの形式で）。

This cryptographic function implements a form of IBS; a stronger form of ICV that verifies not just that the received packet or message is valid but that the packet or message originated at a router that was assigned a private key for the specified identity.

この暗号化機能は、IBSの形式を実装します。受信したパケットまたはメッセージが有効であることだけでなく、指定されたIDの秘密キーが割り当てられたルーターから発信されたパケットまたはメッセージであることを検証する、より強力な形式のICV。

It is recommended that the identity include an address unique to that router: for a message, its originator address, and for a packet, the corresponding IP packet source address. If additional information is included in the identity, this may be to indicate an expiry time for signatures created using that identity.

IDには、そのルーターに固有のアドレスを含めることをお勧めします。メッセージの場合は発信元アドレス、パケットの場合は対応するIPパケットの送信元アドレスです。 IDに追加情報が含まれている場合、これは、そのIDを使用して作成された署名の有効期限を示している可能性があります。

In common with other forms of IBS, a feature of the form of IBS (known as ECCSI) used in this specification is that it requires a trusted KMS that issues all private keys and has complete cryptographic information about all possible private keys. However, to set against that, the solution is scalable (as all routers can be independently keyed) and does not need the KMS in the network. If no future keys will be required, then the KMS's master secret can be destroyed. As routers are individually keyed, key revocation (by blacklist and/or time expiry of keys) is possible.

他のIBSの形式と同様に、この仕様で使用されるIBSの形式（ECCSIとして知られている）の機能は、すべての秘密鍵を発行し、すべての可能な秘密鍵に関する完全な暗号化情報を持つ信頼できるKMSを必要とすることです。ただし、これに対抗するために、ソリューションはスケーラブルであり（すべてのルーターを個別にキー設定できるため）、ネットワークでKMSを必要としません。今後のキーが不要になる場合は、KMSのマスターシークレットを破棄できます。ルーターには個別にキーが設定されているため、（ブラックリストやキーの期限切れによる）キーの取り消しが可能です。

ECCSI is based on elliptic curve mathematics. This specification follows [RFC6507] in its recommendation of elliptic curves, but any suitable (prime power) elliptic curve may be used; this must be administratively specified. Implementation of this specification will require an available implementation of suitable mathematical functions. Unlike some other forms of IBS, ECCSI requires only basic elliptic curve operations; it does not require "pairings" (bilinear functions of a product of two elliptic curve groups). This increases the available range of suitable mathematical libraries.

ECCSIは、楕円曲線数学に基づいています。この仕様は、[RFC6507]による楕円曲線の推奨に準拠していますが、任意の適切な（素数）楕円曲線を使用できます。これは管理上指定する必要があります。この仕様の実装には、適切な数学関数の利用可能な実装が必要です。 IBSの他のいくつかの形式とは異なり、ECCSIは基本的な楕円曲線演算のみを必要とします。「ペアリング」（2つの楕円曲線グループの積の双一次関数）は必要ありません。これにより、適切な数学ライブラリの利用可能な範囲が広がります。

6.1. Experimental Status

6.1. 実験状況

The idea of using identity-based signatures for authentication of ad hoc network signaling goes back at least as far as 2005 [Dearlove]. The specific implementation of an IBS used in this specification, ECCSI, was published as an Internet Draft in 2010 before publication as an Informational RFC [RFC6507]. ECCSI is now part of standards such as [ETSI] for LTE Proximity-based Services. An open-source implementation of cryptographic software that includes ECCSI is available, see [SecureChorus].

アドホックネットワークシグナリングの認証にIDベースの署名を使用するという考えは、少なくとも2005年まで遡ります[Dearlove]。この仕様で使用されるIBSの特定の実装であるECCSIは、情報RFC（RFC6507）として公開される前に、2010年にインターネットドラフトとして公開されました。 ECCSIは、LTE近接ベースのサービスの[ETSI]などの標準の一部になりました。 ECCSIを含む暗号化ソフトウェアのオープンソース実装が利用可能です。[SecureChorus]を参照してください。

However, although this specification has been implemented for use in an OLSRv2 [RFC7181] routed network, there are only limited reports of such use. There are also no reports of the use of ECCSI within the IETF, other than in this specification. There are no reports of independent public scrutiny of the algorithm, although ECCSI is reported [RFC6507] as being based on [ECDSA] with similar properties.

ただし、この仕様はOLSRv2 [RFC7181]ルーティングネットワークで使用するために実装されていますが、そのような使用についての報告は限られています。この仕様以外では、IETF内でのECCSIの使用に関する報告もありません。独立したアルゴリズムによるアルゴリズムの精査についての報告はありませんが、ECCSIは[RFC6507]が[ECDSA]に基づいており、同様の特性を持つと報告されています。

This specification is thus published as Experimental in order to encourage its use and encourage reports on its use. Once experiments have been carried out and reported on (and when some public analysis of the underlying cryptographic algorithms is available), it is intended to advance this specification, with any changes identified by such experimentation and analysis, to Standards Track.

したがって、この仕様は、その使用を奨励し、その使用に関するレポートを奨励するために、試験運用版として公開されています。実験が実施されて報告されたら（そして、基礎となる暗号アルゴリズムの公開分析が利用可能になったとき）、このような実験と分析によって特定された変更を含めて、この仕様を標準化トラックに進める予定です。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。

[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, DOI 10.17487/RFC5444, February 2009, <http://www.rfc-editor.org/info/rfc5444>.

[RFC5444] Clausen、T.、Dearlove、C.、Dean、J。、およびC. Adjih、「Generalized Mobile Ad Hoc Network（MANET）Packet / Message Format」、RFC 5444、DOI 10.17487 / RFC5444、2009年2月、< http://www.rfc-editor.org/info/rfc5444>。

[RFC6507] Groves, M., "Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI)", RFC 6507, DOI 10.17487/RFC6507, February 2012, <http://www.rfc-editor.org/info/rfc6507>.

[RFC6507] Groves、M。、「アイデンティティベースの暗号化（ECCSI）のための楕円曲線ベースの証明書なし署名」、RFC 6507、DOI 10.17487 / RFC6507、2012年2月、<http://www.rfc-editor.org/info / rfc6507>。

[RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182, April 2014, <http://www.rfc-editor.org/info/rfc7182>.

[RFC7182] Herberg、U.、Clauseen、T。、およびC. Dearlove、「モバイルアドホックネットワーク（MANET）の整合性チェック値およびタイムスタンプTLV定義」、RFC 7182、DOI 10.17487 / RFC7182、2014年4月、<http： //www.rfc-editor.org/info/rfc7182>。

7.2. Informative References

7.2. 参考引用

[Dearlove] Dearlove, C., "OLSR Developments and Extensions", Proceedings of the 2nd OLSR Interop and Workshop, July 2005, <http://interop.thomasclausen.org/Interop05/Papers/ Papers/paper-01.pdf>.

[Dearlove] Dearlove、C。、「OLSR開発と拡張機能」、第2回OLSR相互運用およびワークショップの議事録、2005年7月、<http://interop.thomasclausen.org/Interop05/Papers/ Papers / paper-01.pdf> 。

[ECDSA] American National Standards Institute, "Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62-2005, November 2005.

[ECDSA] American National Standards Institute、「金融サービス業界の公開鍵暗号化：楕円曲線デジタル署名アルゴリズム（ECDSA）」、ANSI X9.62-2005、2005年11月。

[ETSI] ETSI/3GPP, "Universal Mobile Telecommunications System (UMTS); LTE; Proximity-based Services (ProSe); Security aspects", ETSI TS 33.303, V13.2.0, Release 13, January 2016, <http://www.etsi.org/deliver/ etsi_ts/133300_133399/133303/13.02.00_60/ ts_133303v130200p.pdf>.

[ETSI] ETSI / 3GPP、「ユニバーサルモバイルテレコミュニケーションシステム（UMTS）; LTE;近接ベースのサービス（ProSe）;セキュリティの側面」、ETSI TS 33.303、V13.2.0、リリース13、2016年1月、<http：// www .etsi.org / deliver / etsi_ts / 133300_133399 / 133303 / 13.02.00_60 / ts_133303v130200p.pdf>。

[NIST-FIPS-186-4] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013.

[NIST-FIPS-186-4]国立標準技術研究所、「デジタル署名標準（DSS）」、FIPS 186-4、DOI 10.6028 / NIST.FIPS.186-4、2013年7月。

[NIST-SP-800-57] National Institute of Standards and Technology, "Recommendation for Key Management - Part 1: General (Revision 3)", NIST Special Publication 800-57, Part 1, Revision 3, DOI 10.6028/NIST.SP.800-57pt1r4, July 2012.

[NIST-SP-800-57] National Institute of Standards and Technology、「Recommendation for Key Management-Part 1：General（Revision 3）」、NIST Special Publication 800-57、Part 1、Revision 3、DOI 10.6028 / NIST。 SP.800-57pt1r4、2012年7月。

[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, DOI 10.17487/RFC5497, March 2009, <http://www.rfc-editor.org/info/rfc5497>.

[RFC5497] Clausen、T.およびC. Dearlove、「Representing Multi-Value Time in Mobile Ad Hoc Networks（MANETs）」、RFC 5497、DOI 10.17487 / RFC5497、2009年3月、<http：//www.rfc-editor。 org / info / rfc5497>。

[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, DOI 10.17487/RFC6130, April 2011, <http://www.rfc-editor.org/info/rfc6130>.

[RFC6130] Clausen、T.、Dearlove、C。、およびJ. Dean、「Mobile Ad Hoc Network（MANET）Neighborhood Discovery Protocol（NHDP）」、RFC 6130、DOI 10.17487 / RFC6130、2011年4月、<http：// www.rfc-editor.org/info/rfc6130>。

[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol Version 2", RFC 7181, DOI 10.17487/RFC7181, April 2014, <http://www.rfc-editor.org/info/rfc7181>.

[RFC7181] Clausen、T.、Dearlove、C.、Jacquet、P。、およびU. Herberg、「The Optimized Link State Routing Protocol Version 2」、RFC 7181、DOI 10.17487 / RFC7181、2014年4月、<http：// www.rfc-editor.org/info/rfc7181>。

[SecureChorus] "Secure Chorus: Interoperable and secure enterprise communications", <http://www.securechorus.com/>.

[SecureChorus]「Secure Chorus：相互運用可能で安全なエンタープライズ通信」、<http://www.securechorus.com/>。

Appendix A. Example

付録A.例

Appendix C of [RFC6130] contains this example of a HELLO message. (Note that normally a TIMESTAMP ICV would also be added before the ICV TLV, but for simplicity, that step has been omitted here.)

[RFC6130]の付録Cには、HELLOメッセージのこの例が含まれています。（通常、TIMESTAMP ICVもICV TLVの前に追加されますが、簡単にするために、ここではそのステップを省略しています。）

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     HELLO     | MF=7  | MAL=3 |      Message Length = 45      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Hop Limit = 1 | Hop Count = 0 |    Message Sequence Number    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message TLV Block Length = 8  | VALIDITY_TIME |  MTLVF = 16   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Value Len = 1 | Value (Time)  | INTERVAL_TIME |  MTLVF = 16   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Value Len = 1 | Value (Time)  | Num Addrs = 5 |   ABF = 128   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Head Len = 3  |                     Head                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Mid 0     |     Mid 1     |     Mid 2     |     Mid 3     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Mid 4     | Address TLV Block Length = 14 |   LOCAL_IF    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  ATLVF = 80   |   Index = 0   | Value Len = 1 |    THIS_IF    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  LINK_STATUS  |   ATLV = 52   | Strt Indx = 1 | Stop Indx = 4 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Value Len = 4 |     HEARD     |     HEARD     |   SYMMETRIC   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     LOST      |
     +-+-+-+-+-+-+-+-+

In order to provide an example of an ECCSI ICV Message TLV that may be added to this message, the fields shown need to all have numerical values, both by inserting defined numerical values (e.g., 0 for HELLO) and by selecting example values where needed. The latter means that

このメッセージに追加される可能性のあるECCSI ICVメッセージTLVの例を提供するために、定義された数値（HELLOの場合は0など）を挿入し、必要に応じて値の例を選択することにより、表示されるフィールドはすべて数値を持つ必要があります。。後者は、

o The message sequence number will be zero.

o メッセージのシーケンス番号はゼロになります。

o The five addresses will be 192.0.2.1 to 192.0.2.5.

o 5つのアドレスは192.0.2.1〜192.0.2.5になります。

o The message validity time will be six seconds and the message interval time will be two seconds, each encoded with a constant value C = 1/1024 seconds (as described in [RFC5497] and as referenced from [RFC6130]).

o メッセージの有効期間は6秒、メッセージの間隔は2秒で、それぞれが定数値C = 1/1024秒でエンコードされます（[RFC5497]で説明され、[RFC6130]から参照）。

In addition, when calculating an ICV, the hop count and hop limit are both set to zero. This results in the message:

さらに、ICVを計算するとき、ホップカウントとホップリミットはどちらもゼロに設定されます。これにより、次のメッセージが表示されます。

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0|0 1 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 0 1 1 0 1|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|0 0 0 0 0 0 0 1|0 0 0 1 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0|0 0 0 0 0 0 0 0|0 0 0 1 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 1|0 1 0 1 1 0 0 0|0 0 0 0 0 1 0 1|1 0 0 0 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 1 1|1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 1|0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 1|0 0 0 0 0 1 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 1 0 1|0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0|0 0 0 0 0 0 1 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 1 0 1 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 1 1|0 0 1 1 0 1 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 1 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 1 0 0|0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 1|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0|
     +-+-+-+-+-+-+-+-+

Or, in hexadecimal form:

または、16進形式で：

M := 0x 0073002D 00000000 00080110 01640010 01580580 03C00002 01020304 05000E02 50000100 03340104 04020201 00

M：= 0x 0073002D 00000000 00080110 01640010 01580580 03C00002 01020304 05000E02 50000100 03340104 04020201 00

The ICV TLV that will be added will have cryptographic function ECCSI-ADDR and hash function SHA-256. This message has no originator address, but it travels a single hop and its IP source address can be used. This will be assumed to be 192.0.2.0 with an empty <key-id>; thus, the sender's identity will be (in hexadecimal form):

追加されるICV TLVには、暗号化機能ECCSI-ADDRおよびハッシュ機能SHA-256が含まれます。このメッセージには発信元アドレスがありませんが、単一のホップを移動し、そのIP送信元アドレスを使用できます。これは、空の<key-id>を持つ192.0.2.0であると想定されます。したがって、送信者のIDは（16進形式）になります。

ID := 0x C0000200

ID：= 0x C0000200

Parameters for [RFC6507] will thus be n = 256, N = 32. The same parameters and master key will be used as in Appendix A of [RFC6507], i.e., the elliptic curve P-256, with parameters:

したがって、[RFC6507]のパラメーターはn = 256、N = 32になります。[RFC6507]の付録Aと同じパラメーターとマスターキー、つまり楕円曲線P-256がパラメーターとともに使用されます。

p := 0x FFFFFFFF 00000001 00000000 00000000 00000000 FFFFFFFF FFFFFFFF FFFFFFFF

p：= 0x FFFFFFFF 00000001 00000000 00000000 00000000 FFFFFFFF FFFFFFFF FFFFFFFF

B := 0x 5AC635D8 AA3A93E7 B3EBBD55 769886BC 651D06B0 CC53B0F6 3BCE3C3E 27D2604B

B：= 0x 5AC635D8 AA3A93E7 B3EBBD55 769886BC 651D06B0 CC53B0F6 3BCE3C3E 27D2604B

q := 0x FFFFFFFF 00000000 FFFFFFFF FFFFFFFF BCE6FAAD A7179E84 F3B9CAC2 FC632551

q：= 0x FFFFFFFF 00000000 FFFFFFFF FFFFFFFF BCE6FAAD A7179E84 F3B9CAC2 FC632551

G := 0x 04 6B17D1F2 E12C4247 F8BCE6E5 63A440F2 77037D81 2DEB33A0 F4A13945 D898C296 4FE342E2 FE1A7F9B 8EE7EB4A 7C0F9E16 2BCE3357 6B315ECE CBB64068 37BF51F5

G：= 0x 04 6B17D1F2 E12C4247 F8BCE6E5 63A440F2 77037D81 2DEB33A0 F4A13945 D898C296 4FE342E2 FE1A7F9B 8EE7EB4A 7C0F9E16 2BCE3357 6B315ECE CBB64068 37BF51F5

      KSAK      := 0x  12345;

KPAK := 0x 04 50D4670B DE75244F 28D2838A 0D25558A 7A72686D 4522D4C8 273FB644 2AEBFA93 DBDD3755 1AFD263B 5DFD617F 3960C65A 8C298850 FF99F203 66DCE7D4 367217F4

CBC：= 0x 04 50D4670B DE75244F 28D2838A 0D25558A 7A72686D 4522D4C8 273FB644 2AEBFA93 DBDD3755 1AFD263B 5DFD617F 3960C65A 8C298850 FF99F203 66DCE7D4 367217F4

The remaining steps to creating a private key for the ID use the same "random" value v as Appendix A of [RFC6507] and are:

IDの秘密鍵を作成する残りの手順では、[RFC6507]の付録Aと同じ「ランダム」値vを使用します。

v := 0x 23456

in：= 0 23456

PVT := 0x 04 758A1427 79BE89E8 29E71984 CB40EF75 8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9 A79D2476 92F4EDA3 A6BDAB77 D6AA6474 A464AE49 34663C52 65BA7018 BA091F79

PVT：= 0x 04 758A1427 79BE89E8 29E71984 CB40EF75 8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9 A79D2476 92F4EDA3 A6BDAB77 D6AA6474 A464AE49 34663C52 65BA7018 BA091F79

HS := hash( 0x 04 6B17D1F2 E12C4247 F8BCE6E5 63A440F2 77037D81 2DEB33A0 F4A13945 D898C296 4FE342E2 FE1A7F9B 8EE7EB4A 7C0F9E16 2BCE3357 6B315ECE CBB64068 37BF51F5 04 50D4670B DE75244F 28D2838A 0D25558A 7A72686D 4522D4C8 273FB644 2AEBFA93 DBDD3755 1AFD263B 5DFD617F 3960C65A 8C298850 FF99F203 66DCE7D4 367217F4 C0000200 04 758A1427 79BE89E8 29E71984 CB40EF75 8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9 A79D2476 92F4EDA3 A6BDAB77 D6AA6474 A464AE49 34663C52 65BA7018 BA091F79 )

HS：=ハッシュ（0X 04 6B17D1F2 E12C4247 F8BCE6E5 63A440F2 77037D81 2DEB33A0 F4A13945 D898C296 4FE342E2 FE1A7F9B 8EE7EB4A 7C0F9E16 2BCE3357 6B315ECE CBB64068 37BF51F5 04 50D4670B DE75244F 28D2838A 0D25558A 7A72686D 4522D4C8 273FB644 2AEBFA93 DBDD3755 1AFD263B 5DFD617F 3960C65A 8C298850 FF99F203 66DCE7D4 367217F4 C0000200 04 758A1427 79BE89E8 29E71984 CB40EF75 8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9 A79D2476 92F4EDA3 A6BDAB77 D6AA6474 A464AE49 34663C52 65BA7018 BA091F79）

= 0x F64FFD76 D2EC3E87 BA670866 C0832B80 B740C2BA 016034C8 1A6F5E5B 5F9AD8F3

The remaining steps to creating a signature for M use the same "random" value j as Appendix A of [RFC6507] and are:

Mの署名を作成する残りの手順では、[RFC6507]の付録Aと同じ「ランダムな」値jを使用します。

j := 0x 34567

j：= 0x 34567

J := 0x 04 269D4C8F DEB66A74 E4EF8C0D 5DCC597D DFE6029C 2AFFC493 6008CD2C C1045D81 6DDA6A13 10F4B067 BD5DABDA D741B7CE F36457E1 96B1BFA9 7FD5F8FB B3926ADB

J：= 0x 04 269D4C8F DEB66A74 E4EF8C0D 5DCC597D DFE6029C 2AFFC493 6008CD2C C1045D81 6DDA6A13 10F4B067 BD5DABDA D741B7CE F36457E1 96B1BFA9 7FD5F8FB B3926ADB

r := 0x 269D4C8F DEB66A74 E4EF8C0D 5DCC597D DFE6029C 2AFFC493 6008CD2C C1045D81

r：= 0x 269D4C8F DEB66A74 E4EF8C0D 5DCC597D DFE6029C 2AFFC493 6008CD2C C1045D81

HE := hash( 0x F64FFD76 D2EC3E87 BA670866 C0832B80 B740C2BA 016034C8 1A6F5E5B 5F9AD8F3 269D4C8F DEB66A74 E4EF8C0D 5DCC597D DFE6029C 2AFFC493 6008CD2C C1045D81 0073002D 00000000 00080110 01640010 01580580 03C00002 01020304 05000E02 50000100 03340104 04020201 00 )

HE：= hash（0x F64FFD76 D2EC3E87 BA670866 C0832B80 B740C2BA 016034C8 1A6F5E5B 5F9AD8F3 269D4C8F DEB66A74 E4EF8C0D 5DCC597D DFE6029C 010 0000 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

= 0x FE236B30 CF72E060 28E229ED 5751D796 91DED33C 24D2F661 28EA0804 30D8A832

s' := 0x C8C739D5 FB3EFB75 221CB818 8CAAB86A 2E2669CF 209EA622 7D7072BA A83C2509

s '：= 0x C8C739D5 FB3EFB75 221CB818 8CAAB86A 2E2669CF 209EA622 7D7072BA A83C2509

s := 0x C8C739D5 FB3EFB75 221CB818 8CAAB86A 2E2669CF 209EA622 7D7072BA A83C2509

s：= 0x C8C739D5 FB3EFB75 221CB818 8CAAB86A 2E2669CF 209EA622 7D7072BA A83C2509

Signature := 0x 269D4C8F DEB66A74 E4EF8C0D 5DCC597D DFE6029C 2AFFC493 6008CD2C C1045D81 C8C739D5 FB3EFB75 221CB818 8CAAB86A 2E2669CF 209EA622 7D7072BA A83C2509 04 758A1427 79BE89E8 29E71984 CB40EF75 8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9 A79D2476 92F4EDA3 A6BDAB77 D6AA6474 A464AE49 34663C52 65BA7018 BA091F79

署名：= 0X 269D4C8F DEB66A74 E4EF8C0D 5DCC597D DFE6029C 2AFFC493 6008CD2C C1045D81 C8C739D5 FB3EFB75 221CB818 8CAAB86A 2E2669CF 209EA622 7D7072BA A83C2509 04 758A1427 79BE89E8 29E71984 CB40EF75 8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9 A79D2476 92F4EDA3 A6BDAB77 D6AA6474 A464AE49 34663C52 65BA7018 BA091F79

Acknowledgments

謝辞

The author would like to thank his colleagues who have been involved in identity-based security for ad hoc networks, including (in alphabetical order) Alan Cullen, Peter Smith, and Bill Williams. He would also like to thank Benjamin Smith (INRIA/Ecole Polytechnique) for independently recreating the signature and other values in Appendix A to ensure their correctness, and Thomas Clausen (Ecole Polytechnique) for additional comments.

著者は、（アルファベット順で）アランカレン、ピータースミス、ビルウィリアムズなど、アドホックネットワークのIDベースのセキュリティに携わってきた同僚に感謝します。また、付録Aで署名とその他の値を個別に再作成してそれらの正確さを保証してくれたBenjamin Smith（INRIA / Ecole Polytechnique）と、追加のコメントを提供してくれたThomas Clausen（Ecole Polytechnique）にも感謝します。

Author's Address

著者のアドレス

Christopher Dearlove BAE Systems Applied Intelligence Laboratories West Hanningfield Road Great Baddow, Chelmsford United Kingdom

Christopher Dearlove BAE Systems Applied Intelligence Laboratoriesウェストハニングフィールドロードイギリス、チェルムズフォード、グレートバッドウ

   Phone: +44 1245 242194
   Email: chris.dearlove@baesystems.com
   URI:   http://www.baesystems.com/