Internet DRAFT - draft-ietf-manet-ibs
draft-ietf-manet-ibs
Mobile Ad hoc Networking (MANET) C. Dearlove
Internet-Draft BAE Systems Applied Intelligence
Intended status: Experimental Laboratories
Expires: September 22, 2016 March 21, 2016
Identity-Based Signatures for MANET Routing Protocols
draft-ietf-manet-ibs-05
Abstract
This document extends RFC7182, 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
RFC5444. It does so by defining an additional cryptographic function
that allows the creation of an ICV that is an identity-based
signature, defined according to the ECCSI (Elliptic Curve-Based
Certificateless Signatures for Identity-Based Encryption) algorithm
specified in RFC6507.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 22, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
Dearlove Expires September 22, 2016 [Page 1]
Internet-Draft Identity-Based Signatures March 2016
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.
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 . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6.1. Experimental Status . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Dearlove Expires September 22, 2016 [Page 2]
Internet-Draft Identity-Based Signatures March 2016
1. Introduction
[RFC7182] defines ICV (integrity check value) 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.
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.
Two options for the choice of identity are supported (as reflected by
the two code points allocated). In the first the identity can be any
octet sequence (up to 255 octets) included in the ICV TLV. In the
second, 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 or address block TLV. In particular, the second option
allows just the address to be used as an identity.
Identity-based signatures allow identifying the originator of
information in a packet or message. They thus allow additional
security functions, such as revocation of an identity, and removing
all information with a specific originator, if this is recorded - as
it is for OLSRv2 [RFC7181], an expected user of this specification.
When applied to messages (rather than packets) this can significantly
reduce the damage that a compromised router can inflict on the
network.
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.
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
Dearlove Expires September 22, 2016 [Page 3]
Internet-Draft Identity-Based Signatures March 2016
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.
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 identity-based encryption (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.
There are alternative mathematical realizations of identity-based
signatures. This specification uses one that has been previously
published as [RFC6507], known as ECCSI (Elliptic Curve-Based
Certificateless Signatures for Identity-Based Encryption). In common
with other identity-based encryption/signature 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].
The computational load imposed by ECCSI (and, perhaps more so, other
IBS methods) is not trivial, though depending 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.
The trusted authority is referred to in [RFC6507] as the KMS (Key
Management Service). That term will be used in the rest of this
specification.
Dearlove Expires September 22, 2016 [Page 4]
Internet-Draft Identity-Based Signatures March 2016
2. Terminology
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].
Additionally, this document uses the terminology of [RFC5444],
[RFC6507], and [RFC7182].
3. Applicability Statement
This specification adds an additional option to the framework
specified in [RFC7182] for use by [RFC5444] formatted packets and
messages. It is applicable as described in [RFC7182], and subject to
the additional comments in Section 6, particularly regarding the role
of the trusted authority (KMS).
Specific examples of protocols for which this specification is
suitable are NHDP [RFC6130] and OLSRv2 [RFC7181].
4. Specification
4.1. Cryptographic Function
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:
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 M in [RFC6507] is "content" as specified in in [RFC7182].
o ID, used in [RFC6507], is as specified in Section 4.3.
o KPAK, SSK and PVT, used in [RFC6507], are as specified in Sections
4.2 and 5.1.1 of [RFC6507], provided by the KMS.
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.
Dearlove Expires September 22, 2016 [Page 5]
Internet-Draft Identity-Based Signatures March 2016
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.
To use that function M, KPAK, SSK and PVT are as specified above,
while 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.
Routers MAY be administratively configured to reject a packet or
message 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.
4.2. ECCSI parameters
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].
Selection of an elliptic curve, and all related parameters, MUST be
by administrative means, and known to all routers. This
specification follows [RFC6507] with a RECOMMENDED selection to
follow Appendix D.1.2 of [NIST-FIPS-186-4]. (Note that n in that
document is q in [RFC6507].) However an alternative curve MAY be
used.
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. In particular for 128 bit security, and
hence n = 256, N = 32, and 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.
Note: [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.
Dearlove Expires September 22, 2016 [Page 6]
Internet-Draft Identity-Based Signatures March 2016
4.3. Identity
There are two options for the identity ID used by [RFC6507], which
are indicated by there being two code points allocated for this
cryptographic function, see Section 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 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.
* For a packet TLV this address is the IP source address of the
IP datagram in which this packet is included.
* 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 not present and
the message is known to have travelled 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, and hence their IP source address SHOULD be
used if no originator address is present.)
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.
Note that the identity is formatted by [RFC6507], and thus does not
need a length field incorporated into it by this specification.
5. IANA Considerations
IANA has, in accordance with [RFC7182], defined a registry
"Cryptographic Functions" under "Mobile Ad Hoc NETwork Parameters".
IANA is requested to make two new allocations from this registry, and
modify the unassigned range, as indicated.
Dearlove Expires September 22, 2016 [Page 7]
Internet-Draft Identity-Based Signatures March 2016
+-------+------------+------------------------------+---------------+
| Value | Algorithm | Description | Reference |
+-------+------------+------------------------------+---------------+
| 7 | ECCSI | ECCSI [RFC6507] | This |
| | | | specification |
| 8 | ECCSI-ADDR | ECCSI [RFC6507] with an | This |
| | | address (source or | specification |
| | | originator) joined to | |
| | | identity | |
| 9-251 | | Unassigned; Expert Review | |
+-------+------------+------------------------------+---------------+
Table 1: Cryptographic Function Registry
6. Security Considerations
This specification extends the security framework for MANET routing
protocols specified in [RFC7182] by the addition of an additional
cryptographic function, in two forms according to how identity is
specified.
This cryptographic function implements a form of identity-based
signature (IBS), a stronger form of integrity check value (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.
It is recommended that the identity includes an address unique to
that router; for a message its originator address, 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.
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 Key Management Service (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.
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
Dearlove Expires September 22, 2016 [Page 8]
Internet-Draft Identity-Based Signatures March 2016
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.
6.1. Experimental Status
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 identity based signature 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].
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.
This specification is thus published as experimental, in order to
encourage its use and reports on its use. Once experiments have been
carried out and reported, 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. 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.
8. References
Dearlove Expires September 22, 2016 [Page 9]
Internet-Draft Identity-Based Signatures March 2016
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized Mobile Ad Hoc Network (MANET) Packet/Message
Format", RFC 5444, February 2009.
[RFC6507] Groves, M., "Elliptic Curve-Based Certificateless
Signatures for Identity-Based Encryption (ECCSI)",
RFC 6507, February 2012.
[RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity
Check Value and Timestamp TLV Definitions for Mobile Ad
Hoc Networks (MANETs)", RFC 7182, April 2014.
8.2. Informative References
[Dearlove]
Dearlove, C., "OLSR Developments and Extensions", 2nd OLSR
Interop and Workshop, Ecole Polytechnique, Palaiseau,
France, July 2005.
[ECDSA] ANSI, "Public Key Cryptography for the Financial Services
Industry: The Elliptic Curve Digital Signature Algorithm
(ECDSA)", ANSI X9.62-2005, November 2005.
[ETSI] ETSI/3GPP, "Universal Mobile Telecommunications System
(UMTS); LTE; Proximity-based Services (ProSe); Security
aspects", ETSI TS 133 303 V13.2.0 (2016-01), January 2016.
[NIST-FIPS-186-4]
National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", FIPS 186-4, July 2013.
[NIST-SP-800-57]
National Institute of Standards and Technology,
"Recommendation for Key Management - Part 1: General
(Revision 3)", SP 800-57, Part 1, Revision 3, July 2012.
[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value
Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497,
March 2009.
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, April 2011.
Dearlove Expires September 22, 2016 [Page 10]
Internet-Draft Identity-Based Signatures March 2016
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
"The Optimized Link State Routing Protocol Version 2",
RFC 7181, April 2014.
[SecureChorus]
"Secure Chorus", <http://www.securechorus.com/>.
Appendix A. Example
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.)
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
consists of:
Dearlove Expires September 22, 2016 [Page 11]
Internet-Draft Identity-Based Signatures March 2016
o The message sequence number will be zero.
o The five addresses will be 192.0.2.1 to 192.0.2.5.
o The message validity time will be 6 seconds, and the message
interval time will be 2 seconds, each encoded with a constant
value C = 1/1024 seconds, as described in [RFC5497], as referenced
from [RFC6130].
In addition, when calculating an ICV, the hop count and hop limit are
both set to zero. This results in the message:
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
Dearlove Expires September 22, 2016 [Page 12]
Internet-Draft Identity-Based Signatures March 2016
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:
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:
p := 0x FFFFFFFF 00000001 00000000 00000000
00000000 FFFFFFFF FFFFFFFF FFFFFFFF
B := 0x 5AC635D8 AA3A93E7 B3EBBD55 769886BC
651D06B0 CC53B0F6 3BCE3C3E 27D2604B
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
KSAK := 0x 12345;
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 ID use the same
"random" value v as Appendix A of [RFC6507] and are:
Dearlove Expires September 22, 2016 [Page 13]
Internet-Draft Identity-Based Signatures March 2016
v := 0x 23456
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 )
= 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:
Dearlove Expires September 22, 2016 [Page 14]
Internet-Draft Identity-Based Signatures March 2016
j := 0x 34567
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
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 )
= 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
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
Dearlove Expires September 22, 2016 [Page 15]
Internet-Draft Identity-Based Signatures March 2016
Author's Address
Christopher Dearlove
BAE Systems Applied Intelligence Laboratories
West Hanningfield Road
Great Baddow, Chelmsford
United Kingdom
Phone: +44 1245 242194
Email: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/
Dearlove Expires September 22, 2016 [Page 16]
