Internet Engineering Task Force (IETF) C. Dearlove
Request for Comments: 7859 BAE Systems
Category: Experimental May 2016
ISSN: 2070-1721
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）路由协议中基于身份的签名
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，它使用RFC 5444中指定的通用数据包/消息格式为数据包和消息指定了完整性检查值（ICV）框架（以及具体示例）。它通过定义一个额外的加密函数来实现，该函数允许创建一个ICV，该ICV是一个基于身份的签名（IBS），根据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.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
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）的产品。它代表了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.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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. 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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 . . . . . . . . . . . . . . . . . . . . . . . . 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
[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]定义完整性检查值（ICV）TLV，用于使用[RFC5444]中定义的通用MANET数据包/消息格式的数据包和消息中。本规范通过从[RFC7182]设置的注册表中定义两个新的加密功能代码点，扩展了其中的TLV定义。这允许使用基于身份的签名（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]格式数据包/消息的每个发起者）具有可绑定到数据包或消息的标识。路由器可能有多个标识，但每个ICV TLV只使用一个标识。IBS的加密强度不取决于身份的选择。
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.
支持选择标识的两个选项（由分配的两个代码点反映）。在第一个选项中，标识可以是ICV TLV中包含的任何八位字节序列（最多255个八位字节）。在第二个选项中，八位字节序列前面有一个地址，数据包TLV的IP源地址或消息TLV的消息发起人地址或地址块TLV。特别是，第二个选项只允许将地址用作标识。
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.
基于身份的签名允许识别数据包或消息中信息的发起人。因此，它们允许额外的安全功能，例如撤销身份。（然后，路由器还可以删除从该撤销的发起者记录的所有信息；本规范的预期用户优化链路状态路由协议版本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.
基于身份的签名基于非对称（公钥）加密的形式——基于身份的加密（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.
其他路由器。因此，路由器可以连接到授权机构（通常在安全环境中）以接收私钥，或者可以从授权机构安全地（带外）交付私钥。在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]的规范，称为基于椭圆曲线的无证书签名，用于基于身份的加密（ECCSI）。与其他IBE/IBS方法类似，它基于椭圆曲线的使用。与一些不同，它不使用“配对”（从两个椭圆曲线组的乘积到另一个组的双线性映射）。因此，它可能比某些替代方案更容易实现，也更高效，尽管其签名大小比某些替代方案更大。本规范允许使用[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）。该术语将在本规范的其余部分中使用。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
Additionally, this document uses the terminology of [RFC5444], [RFC6507], and [RFC7182].
此外，本文件使用了[RFC5444]、[RFC6507]和[RFC7182]的术语。
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]所述适用，并受第6节附加注释的约束，特别是关于受信任机构（KMS）的作用。
Specific examples of protocols for which this specification is suitable are Neighborhood Discovery Protocol (NHDP) [RFC6130] and OLSRv2 [RFC7181].
本规范适用的协议的具体示例为邻域发现协议（NHDP）[RFC6130]和OLSRv2[RFC7181]。
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:
本规范定义了一个名为ECCSI的加密函数，该函数按照[RFC6507]第5.2.1节中规定的“符号”函数实现。要使用该规范：
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]中定义的加密函数（哈希函数（内容））计算，但（与[RFC7182]中定义的HMAC ICV一样）在加密函数中使用哈希函数。哈希函数不允许使用“无”选项，哈希函数的已知固定长度必须为N个八位字节（如第4.2节所述）。
o M, used in [RFC6507], is "content" as specified in [RFC7182].
o M、 [RFC6507]中使用的是[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 KMS提供的密钥管理服务公共认证密钥（KPAK）、秘密签名密钥（SSK）和公共验证令牌（PVT）如[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 value>中的<key ID>元素从接收到的数据包或消息（如第4.3节所述）推导出来的。此元件不需要与接收器使用的元件匹配，因此，当使用此加密功能时，不应使用多个ICV TLV，这些ICV TLV仅在<密钥id>或在加密功能选择方面与本规范中定义的两个不同，除非路由器经管理配置以识别要验证的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).
路由器可以管理性地配置为基于部分或全部<密钥id>，使用ECCSI拒绝ICV TLV：例如，如果这编码了该标识不再有效的时间（如第4.3节所述）。
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必须至少是所需安全位的两倍；见[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，定义为天花板（N/8）。使用的哈希函数必须创建大小为N个八位字节的输出。例如，对于128位安全性，当n=256和n=32时，建议使用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]的前身，但此处指定了最新版本；在这方面没有重大差异。
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有两个选项，这两个选项由分配给此加密函数的两个代码点表示，请参见第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节中定义的元素<密钥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节中定义的元素<密钥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>）；如果不存在，并且已知消息只经过一个跃点，则使用包含此消息的IP数据报的IP源地址。否则，未定义地址，必须拒绝该消息。（请注意，NHDP[RFC6130]中指定并在OLSRv2[RFC7181]中使用的HELLO消息始终仅传输一个跃点；因此，如果不存在发起者地址，则应使用其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>可以是（对于加密函数ECCSI-ADDR）或包括（对于任一加密函数）标识到期时间的表示。这可以使用[RFC7182]中为时间戳TLV定义的时间表示之一。推荐的方法是使用加密函数ECCSI-ADDR，其元素<key id>包含表示时间类型的单个八位字节，通常用作时间戳TLV类型扩展（在[RFC7182]，表9中定义），或其任何扩展，后跟如此表示的时间，通常用作时间戳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]中的规定进行格式化，因此不需要本规范中包含的长度字段。
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在“移动自组织网络参数”注册表下的“加密功能”注册表中分配了以下两个新值，并相应地修改了未分配的范围。
+-------+------------+----------------------------------+-----------+
| 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 | |
+-------+------------+----------------------------------+-----------+
+-------+------------+----------------------------------+-----------+
| 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：加密函数注册表
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路由协议的安全框架。
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的一种形式；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.
建议标识包括该路由器特有的地址：对于消息，其发起者地址，对于数据包，相应的IP数据包源地址。如果标识中包含其他信息，这可能表示使用该标识创建的签名的到期时间。
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。如果未来不需要密钥，则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
ECCSI基于椭圆曲线数学。本规范遵循[RFC6507]对椭圆曲线的建议，但可使用任何合适的（素数幂）椭圆曲线；这一定是
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.
行政指定的。本规范的实施需要适当数学函数的可用实施。与其他形式的IBS不同，ECCSI只需要基本的椭圆曲线运算；它不需要“配对”（两个椭圆曲线群乘积的双线性函数）。这增加了适当数学库的可用范围。
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].
使用基于身份的签名进行adhoc网络信令认证的想法至少可以追溯到2005年[Dearlove]。本规范中使用的IBS的具体实现ECCSI于2010年作为互联网草案发布，之后作为信息RFC[RFC6507]发布。ECCSI现在是基于LTE近距离服务的[ETSI]等标准的一部分。包含ECCSI的加密软件的开放源代码实现可用，请参阅[SecureColus]。
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.
因此，本规范作为实验性规范发布，以鼓励其使用，并鼓励其使用报告。一旦进行了实验并报告了实验结果（以及对底层加密算法的一些公开分析可用时），就打算将本规范以及通过此类实验和分析确定的任何变更推进到标准轨道。
[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，“通用移动自组网（MANET）数据包/消息格式”，RFC 5444，DOI 10.17487/RFC54442009年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.，Clausen，T.，和C.Dearlove，“移动自组网（MANET）的完整性检查值和时间戳TLV定义”，RFC 7182，DOI 10.17487/RFC7182，2014年4月<http://www.rfc-editor.org/info/rfc7182>.
[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开发和扩展”，第二届OLSR互操作和研讨会论文集，2005年7月<http://interop.thomasclausen.org/Interop05/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]美国国家标准协会，“金融服务业的公钥加密：椭圆曲线数字签名算法（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_133303; v130200p.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-42013年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]国家标准与技术研究所，“关键管理建议-第1部分：总则（第3版）”，NIST专门出版物800-57，第1部分，第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，“在移动自组网（MANET）中表示多值时间”，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，“移动自组织网络（MANET）邻域发现协议（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，“优化链路状态路由协议版本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/>.
[安全合唱团]“安全合唱团：可互操作且安全的企业通信”<http://www.securechorus.com/>.
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消息的示例。（请注意，通常情况下，时间戳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 |
+-+-+-+-+-+-+-+-+
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的示例，所示字段需要全部具有数值，包括插入定义的数值（例如，0表示HELLO）和在需要时选择示例值。后者意味着
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 这五个地址将是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|
+-+-+-+-+-+-+-+-+
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:
或者，以十六进制形式：
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 0402002001 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源地址。假设为192.0.2.0，且<key id>为空；因此，发送者的身份将是（十六进制形式）：
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 FFFFFF00000001 00000000 00000000 FFFFFFFFFFFFFFFFFFFF
B := 0x 5AC635D8 AA3A93E7 B3EBBD55 769886BC 651D06B0 CC53B0F6 3BCE3C3E 27D2604B
B:=0x 5AC635D8 AA3A93E7 B3EBBD55 769886BC 651D06B0 CC53B0F6 3BE3C3E 27D2604B
q := 0x FFFFFFFF 00000000 FFFFFFFF FFFFFFFF BCE6FAAD A7179E84 F3B9CAC2 FC632551
q:=0x FFFFFFFF00000000 FFFFFFFFFFFFFFBCE6FAAD 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;
KSAK := 0x 12345;
KPAK := 0x 04 50D4670B DE75244F 28D2838A 0D25558A 7A72686D 4522D4C8 273FB644 2AEBFA93 DBDD3755 1AFD263B 5DFD617F 3960C65A 8C298850 FF99F203 66DCE7D4 367217F4
KPAK:=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
v:=0x 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 2CE3357 6B315 ECE CBB64068 37BF51F5 04 50D4670B DE75244F 28388A 0D25558A 7A72686D 4522D4C8 273FB644 2EBFA93 DBDD3755 1AFD263B 5DFD617F 3960C65A 8C298850 FF9903 DCE7D7D4D467D467D487C8F4E987C4AD77 5FC5B9A3 E1C8ED52 F6FA36D9 A79D2476 92F4EDA3 A6BDAB77 D6AA6474 A464AE49 34663C52 65BA7018 BA091F79）
= 0x F64FFD76 D2EC3E87 BA670866 C0832B80 B740C2BA 016034C8 1A6F5E5B 5F9AD8F3
=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:=散列（0x F64FFD76 D2EC3E87 BA670866 C0832B80 B740C2BA 016034C8 1A6F5E5B 5F9AD8F3 269D4C8F DEB66A74 E4EF8C0D 5DCC597D DFE6029C 2AFC493 6008CD2C C1045D81 0073002D 00000000 00080110 01640010 01580 03C00002 01020304 05000E02 50000100 0334004 0402000）
= 0x FE236B30 CF72E060 28E229ED 5751D796 91DED33C 24D2F661 28EA0804 30D8A832
=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 79BE89E71984 CB40EF75 8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9 A79D2476 92F4EDA3 A6BD77 D6AA6474 A464AE647B79
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.
作者要感谢他的同事们，他们参与了adhoc网络的基于身份的安全，包括（按字母顺序）Alan Cullen、Peter Smith和Bill Williams。他还要感谢Benjamin Smith（INRIA/Ecole Polytechnique）独立地重新创建了附录A中的签名和其他值，以确保其正确性，并感谢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应用情报实验室英国切姆斯福德大巴德西汉宁菲尔德路
Phone: +44 1245 242194
Email: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/
Phone: +44 1245 242194
Email: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/