Network Working Group M. Campagna
Internet-Draft Certicom Corp.
Intended status: Standards Track October 12, 2012
Expires: April 15, 2013
A Cryptographic Suite for Embedded Systems (SuiteE)
draft-campagna-suitee-04
Abstract
This document describes a cryptographic suite of algorithms ideal for
constrained embedded systems. It uses the existing IEEE 802.15.4
standard as a starting point, builds upon existing embedded
cryptographic primitives and suggests additional elliptic curve
cryptography (ECC) algorithms and curves. The goal is to define a
complete suite of algorithms ideal for embedded systems.
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 April 15, 2013.
Copyright Notice
Copyright (c) 2012 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
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Campagna Expires April 15, 2013 [Page 1]
Internet-Draft SuiteE October 2012
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. AES-CTR Mode . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. AES-CBC-MAC Mode . . . . . . . . . . . . . . . . . . . . . 7
2.3. AES-CCM* Mode . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1. AES-CCM* Encrypt . . . . . . . . . . . . . . . . . . . 8
2.3.2. AES-CCM* Decrypt . . . . . . . . . . . . . . . . . . . 10
3. Deterministic Random Number Generator . . . . . . . . . . . . 13
3.1. CTR_Update . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. CTR_Init . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3. CTR_Generate . . . . . . . . . . . . . . . . . . . . . . . 15
4. Hash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Prefix-Free Encoding . . . . . . . . . . . . . . . . . . . 16
4.2. MD-strengthening . . . . . . . . . . . . . . . . . . . . . 16
4.2.1. MD-strengthening-1 . . . . . . . . . . . . . . . . . . 17
4.2.2. MD-strengthening-2 . . . . . . . . . . . . . . . . . . 17
4.2.3. MD-strengthening-3 . . . . . . . . . . . . . . . . . . 18
4.3. MMO Construction . . . . . . . . . . . . . . . . . . . . . 18
5. Key Derivation Function . . . . . . . . . . . . . . . . . . . 19
6. Curve Selection . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. SECT283K1 Curve Parameters . . . . . . . . . . . . . . . . 21
7. Elliptic Curve Signatures with Partial Message Recovery . . . 22
7.1. Message Encoding and Decoding Methods . . . . . . . . . . 22
7.1.1. Message Encoding . . . . . . . . . . . . . . . . . . . 22
7.1.2. Decoding Messages . . . . . . . . . . . . . . . . . . 23
7.2. Elliptic Curve Pintsov-Vanstone Signatures (ECPVS) . . . . 23
7.2.1. Signature Generation . . . . . . . . . . . . . . . . . 24
7.2.2. Signature Verification . . . . . . . . . . . . . . . . 24
8. Elliptic Curve Implicit Certificates (ECQV) . . . . . . . . . 26
8.1. Certificate Request . . . . . . . . . . . . . . . . . . . 26
8.2. Certificate Generation . . . . . . . . . . . . . . . . . . 27
8.3. Certificate Reception . . . . . . . . . . . . . . . . . . 28
8.4. Certificate Public Key Extraction . . . . . . . . . . . . 28
9. Elliptic Curve Key Agreement Scheme . . . . . . . . . . . . . 30
9.1. ECMQV . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1. Normative References . . . . . . . . . . . . . . . . . . . 32
10.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 36
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37
Campagna Expires April 15, 2013 [Page 2]
Internet-Draft SuiteE October 2012
1. Introduction
Constrained embedded systems and in particular devices for wireless
personal and body area networks (WPAN and BAN respectively), have
unique computation, power and bandwidth constraints. These systems
are seeing wider deployment in Smart Energy, Home Automation,
Personal Home and Health Care, and more broadly the so-called
Internet of Things. The environments in which they are being
deployed require varying degrees of security.
The Cryptographic Suite for Embedded Systems (SuiteE) aims to
optimally meet the wide variety of cryptographic requirements, by
providing a compact and complete collection of cryptographic
algorithms having minimal code space, computational requirements and
bandwidth usage. Additionally the selection of these algorithms are
tuned to minimize overall system costs in mass production by
selecting easily embeddable algorithms which will further reduce code
space, energy usage and increase computational performance. It is
expected that this suite of algorithms can be used to provide
security solutions in the 6lowpan and CoRE space.
Mass production economics see many benefits of placing fixed routines
in hardware. The benefits are in code space, performance, battery
life, and overall cost of the device. This is the fundamental reason
why most IEEE 802.15.4 devices implement AES in hardware today.
Considering the projected scale of the so-called Internet of things
(Cisco estimates the smart grid alone to be 100 to 1000 times the
size of the Internet today), efficiencies and cost savings realized
in embedding more of the lower level operations in hardware
transforms into a basic requirement - technology selection should
afford benefits to embedding in hardware.
Many of the environments in which these new embedded systems are
being deployed have a life expectancy of 20+ years. This requires
the selection of key lifecycle management mechanisms at a security
level adequate to deliver the desired security services for the
lifespan of the system. [NIST57] provides recommendations on general
key management and security levels. We summarize the comparable
strengths table and recommended minimum sizes:
Campagna Expires April 15, 2013 [Page 3]
Internet-Draft SuiteE October 2012
+-----------+----------+-----------+-----------------+--------------+
| Algorithm | Security | Symmetric | Integer | Elliptic |
| Lifetime | Strength | Key Size | Factorization | Curve |
| | | | Cryptography | Cryptography |
| | | | Key Size (e.g., | (ECC) Key |
| | | | RSA) Size | Size |
+-----------+----------+-----------+-----------------+--------------+
| Through | 80 bits | 80 | 1024 | 160 |
| 2010 | | | | |
| | | | | |
| Through | 112 bit | 112 | 2048 | 256 |
| 2030 | | | | |
| | | | | |
| Beyond | 128 bit | 128 | 3072 | 256 |
| 2030 | | | | |
| | | | | |
| >Beyond | 192 bit | 192 | 7680 | 384 |
| 2030 | | | | |
| | | | | |
| >>Beyond | 256 bit | 256 | 15360 | 512 |
| 2030 | | | | |
+-----------+----------+-----------+-----------------+--------------+
[NIST57] does not provide guidance on life span for security
strengths for 192 and 256 bit presumably because of the uncertainty
in forecasting technology 30+ years out.
Considering the expected life span of many of these systems and best
industry practice we target the 128 bit security strengths for
SuiteE.
The design goals of SuiteE are:
Provide re-usable primitives
Reduce code size
To be suitable for hardware implementation
Reduce computational costs
Reduce energy usage and increase battery lifespan
A complete cryptographic cipher suite should consist of primitives
from which the security services of identification and
authentication, confidentiality, data integrity and non-repudiation
can be provided. We prescribe an encryption scheme with
authentication, a deterministic random number generator, a hash
Campagna Expires April 15, 2013 [Page 4]
Internet-Draft SuiteE October 2012
function, a key-agreement scheme, a digital signature scheme, and a
certificate scheme that achieves a 128-bit security level, and
achieves the goals identified above.
The remainder of this document is organized as follows. Section 2
provides an authenticated encryption mode AES-CCM*. Section 3
provides a deterministic random number generator. Section 4
describes a hashing algorithm using the existing AES core in an AES-
MMO mode. Section 6 indicates why elliptic curve technology is
selected and the specific curve selection sect283k1. Section 7
specifies the use of an elliptic curve signature scheme with partial
message recovery. Section 8 provides an implicit certificate scheme.
Section 9 describes an elliptic curve based mutual authenticated key
agreement scheme.
Campagna Expires April 15, 2013 [Page 5]
Internet-Draft SuiteE October 2012
2. Encryption
IEEE 802.15.4 [IEEE-802.15.4-2003] specifies the use of AES-CCM*, a
variation of the Counter Mode with Cipher Block Chaining MAC (CBC-
MAC) using AES-128. AES-128 is specified in [FIPS-197]. Using
[IEEE-802.15.4-2003] as the normative reference we present a
description of AES-CCM* here.
In the sections that follow we will assume that the basic block
cipher is AES-128 as specified in [FIPS-197]. We will represent AES-
128 as a function E taking two 128-bit inputs, a message block M, and
key K, with 128-bit output C = E(M, K).
2.1. AES-CTR Mode
CTR mode or Counter Mode is a block cipher mode for providing
confidentiality. It has some specific advantages in that both the
encryption and decryption routines only require the block cipher to
operate in a forward, or encrypt-only, direction.
Input: a 128-bit symmetric key K, and a plaintext message P of length
Plen, and initial counter value CTR
1. Compute m = ceiling(Plen/128).
2. Apply the counter generator function to CTR to compute CTR_1,
CTR_2, ..., CTR_m.
3. Compute S_j = E(CTR_j, K), for j = 1,...,m.
4. Let S = S_1||S_2||...||S_m, where || indicates concatenation.
5. Compute C = P XOR MSB_Plen(S), where MSB_X( ) takes the X most
significant bits.
Output: C
The Decryption routine for CTR mode is symmetric.
Input: a 128-bit symmetric key K, and a ciphertext message C of
length Clen, and initial counter value CTR
1. Compute m = ceiling(Clen/128).
2. Apply the counter generator function to CTR to compute CTR_1,
CTR_2, ..., CTR_m.
Campagna Expires April 15, 2013 [Page 6]
Internet-Draft SuiteE October 2012
3. Compute S_j = E(CTR_j, K), for j = 1,...,m.
4. Let S = S_1||S_2||...||S_m, where || indicates concatenation.
5. Compute P = C XOR MSB_Clen(S), where MSB_X( ) takes the X most
significant bits.
Output: P
2.2. AES-CBC-MAC Mode
Cipher Block Chaining MAC Mode, CBC-MAC mode uses a block cipher to
provide data integrity. Unlike CTR mode, that operates on arbitrary
length strings CBC-MAC requires message padding to be on a multiple
of the block length. The last message block will be padded out using
zero bytes.
Input: a 128-bit symmetric key K, a message M of length Mlen
1. Form B by padding message M on the right with 0-bytes to be on a
byte boundary of the block length (16-bytes).
2. Form B = B_1||B_2||...||B_m.
3. Set O_0 to a zeroized block-length byte string.
4. Compute O_j = E(O_j-1 XOR B_j, K).
5. Set MAC T = O_m.
Output: T
Verification is done by identical computation on input K, message M,
and purported MAC T' and an additional check where the computed MAC
value T is compared to the received MAC value T' and accepted only if
T = T'.
2.3. AES-CCM* Mode
CCM mode is an authenticate and encrypt mode for block ciphers
defined in [NIST-800-38C]. It is defined on a 128-bit block size
block cipher. CCM* modifies this description to allow for modes that
require only authentication, as well as variable length
authentication tags.
Campagna Expires April 15, 2013 [Page 7]
Internet-Draft SuiteE October 2012
2.3.1. AES-CCM* Encrypt
We break this section up into 3 subsections, input transformation,
authentication transformation, and encryption transformation. We
will assume that the following inputs are provided to the routines.
Input:
a. A 128-bit symmetric key K.
b. A value 1 < L < 9.
c. A nonce N of 15 - L octets, unique within the usage of the key
K.
d. An octet string m of length l(m), where 0 <= l(m) < 2^8L.
e. An octet string a of length l(a), where 0 <= l(a) < 2^64.
2.3.1.1. Input Transformation
Input:
a. An octet string m of length l(m), where 0 <= l(m) < 2^8L.
b. An octet string a of length l(a), where 0 <= l(a) < 2^64.
1. Represent the length l(a) as an octet string L(a).
a. If l(a) = 0, then L(a) is an empty string.
b. If 0 < l(a) < 2^16 - 2^8, then L(a) is the 2-octet
representation of l(a).
c. If 2^16 - 2^8 <= l(a) < 2^32, then L(a) is the right-
concatenation of the octet 0xff, the octet 0xfe, and the
4-octet encoding of l(a).
d. If 2^32 <= l(a) < 2^64, then L(a) is the right-
concatenation of the octet 0xff, the octet 0xff, and the
8-octet encoding of l(a).
2. Form AddAuthData = L(a)||a||0^t, where 0^t is the smallest non-
negative string of t zero octets so that the resulting
AddAuthData octet length is a multiple of 16.
3. Form PlaintextData = m || 0^s, where 0^s is the smallest non-
negative string of s zero octets so that the resulting
Campagna Expires April 15, 2013 [Page 8]
Internet-Draft SuiteE October 2012
PlaintextData octet length is a multiple of 16.
4. Form AuthData = AddAuthData || PlaintextData.
Output: AuthData
2.3.1.2. Authentication Transformation
Input:
a. A 128-bit symmetric key K.
b. The octet string AuthData, created in the input
transformation.
c. A nonce N of 15 - L octets, unique within the usage of the key
K.
d. The length l(m), where 0 <= l(m) < 2^8L.
1. Form the byte Flags = Reserved || Adata || M || L, where the
1-bit Reserved field is reserved for future expansions and shall
be set to '0'. The 1-bit Adata field is set to '0' if l(a) = 0
and set to '1' if l(a) > 0. The M field is the 3-bit
representation of the integer (M - 2)/2 if M > 0 and of the
integer 0 if M = 0, in most-significant-bit-first order. The L
field is the 3-bit representation of the integer L - 1, in most-
significant-bit-first order.
2. Form B0 = Flags || Nonce N || l(m)
3. Parse the message AuthData as B1 || B2 || ... ||Bt, where each
message block Bi is a 16-octet string.
4. The CBC-MAC value T = AES-CBC-MAC(B_0 || AuthData, K) as defined
by Section 2.2.
Output: T
2.3.1.3. Encryption Transformation
Input:
a. A 128-bit symmetric key K.
b. PlaintextData from Section 2.3.1.1.
Campagna Expires April 15, 2013 [Page 9]
Internet-Draft SuiteE October 2012
c. The authentication tag output T from Section 2.3.1.2.
d. A nonce N of length 15-L bytes.
1. Form Flags = Reserved0 || Reserved1 || 000 || L', where the
reserved bits Reserved0 and Reserved1 is '0', and L' is the 3-bit
representation of the integer L - 1.
2. Form the A_i = Flags || Nonce N || Counter_i, where Counter_i is
an L-octet representation of the integer i = 0, 1, 2, ..., t.
3. Parse the PlaintextData from Section 2.3.1.1 into 16-octet blocks
M_1, ..., M_t.
4. Compute C_i = E(A_i, K) XOR M_i for i = 1, ..., t.
5. Compute Ciphertext as the leftmost l(m) bits of C_1 || ... ||
C_t.
6. Compute S_0 = E(A_0, K) XOR T.
7. Compute AuthTag as the leftmost M octets of S_0.
Output: Ciphertext and AuthTag
2.3.2. AES-CCM* Decrypt
We break this section up into 2 subsections, decryption and
authentication verification. The AES-CCM* Decryption process should
both decrypt any encrypted portion of the message, and authenticate
the decrypted message. It will return an error code, or plaintext
data. We will assume that the following inputs are provided to the
routines.
Input:
a. A 128-bit symmetric key K.
b. A nonce N of 15 - L octets, unique within the usage of the key
K.
c. An M-octet tag AuthTag.
d. An octet string Ciphertext of length l(c), where 0 <= l(c) - M
< 2^8L.
Campagna Expires April 15, 2013 [Page 10]
Internet-Draft SuiteE October 2012
2.3.2.1. Decryption Transformation
Input:
a. A 128-bit symmetric key K.
b. A nonce N of 15 - L octets, unique within the usage of the key
K.
c. An M-octet tag AuthTag.
d. An octet string Ciphertext of length l(c), where 0 <= l(c) - M
< 2^8L.
1. Form C_0 from AuthTag by padding on the right by the least number
of 0 octets so that C_0 is an octet string of length 16.
2. Form CiphertextData by right concatenation of C with the smallest
number of 0 octets so the resulting string is of octet length
divisible by 16.
3. Form Flags = Reserved0 || Reserved1 || 000 || L', where the
reserved bits Reserved0 and Reserved1 are '0', and L' is the
3-bit representation of the integer L - 1.
4. Form the A_i = Flags || Nonce N || Counter_i, where Counter_i is
an L-octet representation of the integer i = 0, 1, 2, ..., t.
5. Parse the C_0||CiphertextData into 16-octet blocks C_0, C_1, ...,
C_t.
6. Compute P_i = E(A_i, K) XOR C_i for i = 0, ..., t.
7. Form U as the rightmost M-octets of P_0.
8. Form Plaintext leftmost l(c) octets of P_1||...||P_t.
Output: U and Plaintext
2.3.2.2. Verification Transformation
Input:
a. A 128-bit symmetric key K.
b. Plaintext of length l(c), where 0 <= l(c) < 2^8L.
Campagna Expires April 15, 2013 [Page 11]
Internet-Draft SuiteE October 2012
c. U, the purported MAC of Plaintext.
d. A nonce N of 15 - L octets, unique within the usage of the key
K.
1. Compute T as the output of the authentication transformation
Section 2.3.1.2 with the inputs, key K, Plaintext, nonce N, and
length value l(c).
2. Form T' as the leftmost M octets of T.
3. If T' = U output Plaintext, otherwise output error code INVALID.
Output: Plaintext or INVALID
Campagna Expires April 15, 2013 [Page 12]
Internet-Draft SuiteE October 2012
3. Deterministic Random Number Generator
This section provides a reduced set of options to the CTR_DRBG
definition using AES as defined in [NIST-800-90].
Restrict the CTR_DRBG to the use of AES-128 delivering 128-bit
security.
General assumption of a full-entropy seed, removing the extra
coding needed for the block_cipher_df and the BCC function as
defined in [NIST-800-90]
The personalization_string and additional_input options are not
supported.
Set maximum_number_of_bits_per_request = 2^16. (Based on
convenient word boundary.)
Set reseed_interval = 2^48. (Based on maximizing life of a device
that may not have an entropy source.)
We give a basic description of the AES block-cipher-based DRBG in the
next few subsections. The description includes an update function,
an initialization function, and a generate function. We will leave
it up to implementers to consider other optional functions such as
reseed.
We define the state of the CTR_DRBG using the following structure.
struct{
uint64 counter; // 64-bit counter
uchar V[16]; // state
uchar K[16]; // key
}ctr_drbg;
3.1. CTR_Update
The update function CTR_Update() modifies the internal state
variables V and K of the DRBG structure using provided data.
Input:
a. The current state V.
b. The current key K.
c. A 32-byte input, data.
Campagna Expires April 15, 2013 [Page 13]
Internet-Draft SuiteE October 2012
1. temp = AES(V+1 (mod 2^128), K) || AES(V+2 (mod 2^128), K).
2. temp = temp XOR data.
3. K = leftmost 16 bytes of temp.
4. V = rightmost 16 bytes of temp.
Output:
a. The updated state V.
b. The updated key K.
Functionally we write (V, K) = CTR_Update(V, K, data).
3.2. CTR_Init
The update function CTR_Update() modifies the internal state
variables V and K of the DRBG structure using provided data.
Input:
a. A full entropy 32-byte seed.
1. Set V = 0^128, K = 0^128, zeroize state V, and K.
2. (V, K) = CTR_Update(V, K, seed).
3. Set counter = 1.
Output:
a. State (counter, V, K)
Functionally we write (counter V, K) = CTR_Init(seed).
NOTE: The CTR_Init() function can be simplified by making the
observation that the resulting state is simply an XOR of the seed
value with the fixed output values of AES(0^127||1_2, 0^128)||
AES(0^126||10_2, 0^128) = 58E2FCCEFA7E3061367F1D57A4E7455A0388DACE60B
6A392F328C2B971B2FE78_{16}, or (K||V) =
58E2FCCEFA7E3061367F1D57A4E7455A0388DACE60B6A392F328C2B971B2FE78 XOR
seed.
Campagna Expires April 15, 2013 [Page 14]
Internet-Draft SuiteE October 2012
3.3. CTR_Generate
The function CTR_Generate() modifies the internal state variables V
and K of the DRBG structure, and generates a random output of the
requested length rlen bytes. If the counter has exceeded 2^48 or
rlen exceeds 2^16, an ERROR is returned, and the state is not
modified.
Input:
a. Current state (counter, V, K).
b. Requested number of bytes, rlen.
1. If counter > 2^48 return ERROR.
2. If rlen > 2^16 return ERROR.
3. Set output = NULL
4. while(length(temp) < rlen)
a. V = V + 1 (mod 2^128).
b. output ||= AES(V, K).
5. output = leftmost rlen bytes of output.
6. (V, K) = CTR_Update(V, K, 0^256).
7. Set counter = counter + 1.
Output:
a. State (counter, V, K)
b. Either NULL and ERROR, or output and SUCCESS
Functionally we write ((counter V, K), (output, RESULT_CODE)) =
CTR_Generate(V, K, data).
Campagna Expires April 15, 2013 [Page 15]
Internet-Draft SuiteE October 2012
4. Hash
[ISO-10118-2] specifies hash functions using an n-bit block cipher.
The first function from [ISO-10118-2] ("Hash-function one") maps
arbitrary length inputs to n-bit outputs. This is the Matyas-Meyer-
Oseas (MMO) construction described in [MOV96]. In the first
subsection we specify a family of Merkle-Damgard strengthening (or
MD-strengthening) functions that aims to account for existing
deployments in ZigBee Smart Energy, and provide a gradual MD-
strengthening that reduces padding on small messages.
The following subsection details an MMO construction that utilizes
two input pre-processing steps. The first is a prefix-free encoding:
the bitlength of the message encoded as a 128-bit integer is
prepended to the input message. The second is the more common MD-
strengthening transform, which essentially appends an encoding of the
length and ensures the output is a multiple of the block length.
The hash function defined here is a not a general purpose hash
function at the 128-bit security level, as it does not provide
collision resistance. Application of this hash function should
conform to the usages defined in this specification. The use of this
hash function elsewhere requires careful consideration.
4.1. Prefix-Free Encoding
The prefix-free encoding step is defined as follows:
Input: message M of bitlength Mlen
Output: M' of bitlength Mlen + 128
1. If Mlen >= 2^64 return ERROR.
2. Convert Mlen to a bit string Mblen of length 128 bits, where
the first 64 where Mblen is the 128-bit little-endian integer
representation of Mlen. (Note that the leftmost 64 bits will
always be zero.)
3. Prepend (left-pad) and output Mblen to M, i.e., output M' =
Mblen||M.
4.2. MD-strengthening
This section defines an escalating MD-strengthening padding scheme to
account for minimizing additional blocks for small messages, and
expanding length encoding for larger messages. Additionally it
allows for compliance with existing applications of MMO hashing
Campagna Expires April 15, 2013 [Page 16]
Internet-Draft SuiteE October 2012
defined in ZigBee Smart Energy 1.0. For messages less than 2^16 bits
we use MD-strengthening-1, for messages of length less than 2^32 bits
but greater than 2^16 - 1 bits we use MD-strengthening-2, and for
messages of length less than 2^64 bits but greater than 2^32 - 1 bits
we use MD-strengthening-3
4.2.1. MD-strengthening-1
Input: A message M of bitlength Mlen.
1. If Mlen >= 2^16 return ERROR.
2. Pad the message M:
a. Right concatenate the message M with a '1' bit followed by
k '0' bits where k is the least non-negative number such that
Mlen + 1 + k = 112 mod 128.
b. Form the padded message M' by right concatenating the
resulting string with a 16-bit string that is equal to the
value Mlen.
Output: M' = M_1, M_2, ..., M_m a padded message in 128-bit blocks.
4.2.2. MD-strengthening-2
Input: A message M of bitlength Mlen.
1. If Mlen < 2^16 or Mlen >= 2^32 return ERROR.
2. Pad the message M:
a. Right concatenate the message M with a '1' bit followed by
k '0' bits where k is the least non-negative number such that
Mlen + 1 + k = 80 mod 128.
b. Form the padded message M'' by right concatenating the
resulting string with a 32-bit string that is equal the value
Mlen.
c. Form the padded message M' by right concatenating M'' with
a 16-bit 0 string.
Output: M' = M_1, M_2, ..., M_m a padded message in 128-bit blocks.
Campagna Expires April 15, 2013 [Page 17]
Internet-Draft SuiteE October 2012
4.2.3. MD-strengthening-3
Input: A message M of bitlength Mlen.
1. If Mlen < 2^32 or Mlen= >= 2^64 return ERROR.
2. Pad the message M:
a. Right concatenate the message M with a '1' bit followed by
k '0' bits where k is the least non-negative number such that
Mlen + 1 + k = 16 mod 128.
b. Form the padded message M'' by right concatenating the
resulting string with a 64-bit string that is equal the value
Mlen.
c. Form the padded message M' by right concatenating M'' with
a 48-bit 0 string.
Output: M' = M_1, M_2, ..., M_m a padded message in 128-bit blocks.
4.3. MMO Construction
We describe the basic MMO construction on a message M that has been
padded and MD-strengthened to be of length a multiple of the bit
length of AES, 128 bits.
Input: A message M of bitlength Mlen.
1. Apply the prefix-free encoding to M to form a bitstring M', with
bitlength Mlen' = Mlen + 128.
2. Pad and format M' in 128-bit blocks using one of the MD routines
specified above or return ERROR.
3. Set H_0 = 0^128, a zeroized 128-bit block.
4. Compute H_j = E(M_j, H_(j-1)) XOR M_j, for j = 1, ..., m.
Output: H = H_m as the hash value.
Campagna Expires April 15, 2013 [Page 18]
Internet-Draft SuiteE October 2012
5. Key Derivation Function
At this time SuiteE does not recommend a particular key derivation
function (KDF) for compliance. That said, some of the SuiteE
primitives do require use of a KDF. One possible choice are the
pseudorandom function-based constructions of KDFs given in
[NIST-800-108] which are suitable, and may be instantiated with AES-
CMAC as a pseudo-random function.
Campagna Expires April 15, 2013 [Page 19]
Internet-Draft SuiteE October 2012
6. Curve Selection
We will assume basic familiarity with Elliptic Curve Cryptography
(ECC) notation and specifications. Wherever possible we will refer
to freely available standards and indicate alignment of these
standards with other well known standards. We will assume the
notation in the Standards for Efficient Cryptography Group SEC 1,
[SEC1]. This specification defines the basic ECC operations as well
as the most widely standardized and used techniques. The overall
goal of [SEC1] is to provide a free standard that ensures conformance
with other standard specifications, and is instructive to
implementers on how to develop the necessary routines to build an
elliptic curve cryptosystem.
Elliptic curve cryptography is a natural public key technology to
select given a goal of providing public key operations at a 128-bit
security level on embedded systems. ECC, like RSA and other public
key cryptosystems provides security by the use of key pairs: a
private key and a public key. Security properties are built upon the
assumption that the private key is securely generated and maintained
within the confines of a cryptographic boundary. Ideally, this means
that private keys should be generated on the device in which the
private keys will be used operationally.
RSA key generation at the 128-bit security level requires the
generation 1536-bit prime numbers, and performing integer operations
on 3072-bit numbers. The inability of embedded systems to generate
these keys on devices today, and the future requirements to implement
this in hardware makes RSA a poor choice.
ECC key generation at the 128-bit security level requires the
generation of a 256-bit random number and scalar point
multiplication, which can be done efficiently in embedded systems
today.
Elliptic curves over binary fields have a distinct advantage over
elliptic curves over prime fields in that they are more efficient and
cost effective in hardware. The binary curve sect283k1 as specified
in [SEC2] is the most widely standardized and specified binary curve
at the 128-bit security level. It is a Koblitz curve, which has an
advantage over random curves in performing point multiplication
algorithms.
For a basic description of the algorithms the reader is referred to
[SEC1]. For a more complete background and optimizations for
elliptic curves the reader is referred to [HMV04].
Throughout the following sections on elliptic curve cryptography we
Campagna Expires April 15, 2013 [Page 20]
Internet-Draft SuiteE October 2012
will use the following notation
Fq - is a finite field with q elements.
E - an elliptic curve over Fq, given by the equation y^2 + xy = x^3 +
ax^2 + b.
E(Fq) - the group of elliptic curve points over Fq.
G - is a base point in E(Fq) of a large prime order.
n - is a large prime, and the order of the subgroup generated by G.
h - is the cofactor, h = #E(Fq)/n.
Further we will assume it is known how to generate elliptic curve key
pairs, and will refer the reader to the freely available
specification [SEC1]. In general a key pair is generated by taking a
random integer d, 1 < d < n, and computing Q = dG, the addition of
the point G to itself d times. In general all parties will have some
assurances that the elliptic curve domain parameters are valid, and
in particular are fixed to the selected sect283k1 curve parameters.
6.1. SECT283K1 Curve Parameters
Fq - is a finite field with q = 2^283. Fq = F_2[X]/(f(x)), where
f(x) = x^283 + x^12 + x^7 + x^5 + 1.
E - the elliptic curve is defined as E:y^2 + xy = x^3 + b.
G - is a base point in E of a large prime order, presented here in
uncompressed octet encoding 04 0503213F 78CA4488 3F1A3B81 62F188E5
53CD265F 23C1567A 16876913 B0C2AC24 58492836 01CCDA38 0F1C9E31
8D90F95D 07E5426F E87E45C0 E8184698 E4596236 4E341161 77DD2259.
n - is a large prime, and the order of the subgroup generated by G, n
= 01FFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFE9AE 2ED07577 265DFF7F
94451E06 1E163C61.
h - is the cofactor, #E(Fq)/n, h = 4.
Campagna Expires April 15, 2013 [Page 21]
Internet-Draft SuiteE October 2012
7. Elliptic Curve Signatures with Partial Message Recovery
Elliptic Curve Pintsov-Vanstone Signatures (ECPVS) is an elliptic
curve variant of Nyberg-Rueppel signatures. ECPVS is standardized in
[X9.92.1] and [IEEE1363-A]. It has three distinct advantages over
ECDSA when it comes to constrained environments. The first being
that it allows for smaller signature sizes by the incorporation of
part of the message into a signature field. The second is a
simplification of the integer arithmetic. The signing transformation
does not require a modular inverse, improving both code size and
computational performance. The verification transformation requires
no integer arithmetic and so also removes a modular inverse and
modular multiplies in the verification transformation. The third is
that it is a Schnorr signature scheme which loosens the collision
resistance requirement on the underlying hash function [NSW07]. Thus
the AES-MMO hash primitive in SuiteE (see Section Section 4)is
sufficient for security. A second consequence is a performance
increase in the signature verification, where a scalar multiply with
a 256-bit integer (ECDSA) is replaced by a 128-bit integer (ECPVS).
We assume all parties possess the domain parameters for the elliptic
curve, as chosen in Section 6, and that the public keys of signers
are validated as described in [SEC1], Section 3.2.2.
The scheme presented here is a variant of ECPVS as presented in
[X9.92.1], it removes the redundancy requirement on the input message
by replacing the use of symmetric key encryption with the
authenticated encryption functionality of SuiteE, AES-CCM*.
ECPVS uses encoding and decoding routines to process signatures.
7.1. Message Encoding and Decoding Methods
The following subsections specify the encoding and decoding operation
primitives that shall be used to generate ECPVS signatures and to
verify ECPVS signatures.
7.1.1. Message Encoding
Input: The input to the encoding operation is:
a. A recoverable message part, which is a bit string M of length
Mlen bits.
b. A bit string Z (used to derive a key).
Steps
Campagna Expires April 15, 2013 [Page 22]
Internet-Draft SuiteE October 2012
1. Form T = 00||M, by prepending a zero byte to the front of M.
2. Apply the key derivation function KDF to the bit string Z to
produce a 128-bit key K.
3. Let (C, MAC) = AES-CCM*-ENCRYPT(T, K, 128).
4. Form r = C||MAC, the concatenation of the cipher text value C
with the computed MAC value.
Output: r.
We will denote this process as r = EM(M, Z), for encode message.
7.1.2. Decoding Messages
Input: The input to the decoding operation is:
a. The message representative, which is a bit string r of length
rlen bits.
b. A bit string Z.
Steps
1. Apply the key derivation function KDF to the bit string Z to
produce a 128-bit key K.
2. Parse the message r = C||MAC, where MAC is the last 16 bytes, or
return ERROR.
3. Compute M' = AES-CCM*-DECRYPT(C, MAC, K, 128).
4. If M' is ERROR value return ERROR.
5. Parse M' = 00||M, where 00 is a zeroized byte, or return ERROR.
6. return M.
Output: ERROR or message value M.
We will denote this process as M = EM^-1(r, Z), for decode message.
7.2. Elliptic Curve Pintsov-Vanstone Signatures (ECPVS)
This section contains two subsections, signature generation and
signature verification.
Campagna Expires April 15, 2013 [Page 23]
Internet-Draft SuiteE October 2012
7.2.1. Signature Generation
Input: The input to the signature generation transformation is:
a. A message (M, V), which is a pair of bit strings to be signed.
M is the recoverable portion of the message, and V is the visible
or plaintext portion of the message.
b. An elliptic curve private key d.
Steps:
1. Generate an ephemeral key pair (k, R) with R = (x, y). (see:
[SEC1] Section 3.2.1).
2. Convert the field element x to a bit string Z. (see: [SEC1]
Section 2.3.5 and 2.3.2).
3. Encode the recoverable portion of the message r = EM(M, Z).
4. Compute H = AES-MMO(r||V), where || represents concatenation.
5. Convert the bit string H to an integer e. (see: [SEC1] Section
2.3.1 and 2.3.8).
6. Compute s = k - de (mod n).
Output: (r, s) as the signature with partial message recovery on V.
7.2.2. Signature Verification
Input: The input to verification is:
a. A message V.
b. A signature with partial message recovery (r, s).
c. The elliptic curve public key Q belonging to the signer.
Steps:
1. If s is not an integer in the interval [1, n - 1], return ERROR.
2. Compute H = AES-MMO(r||V).
3. Convert the bit string H to an integer e. (see: [SEC1] Section
2.3.1 and 2.3.8).
Campagna Expires April 15, 2013 [Page 24]
Internet-Draft SuiteE October 2012
4. Compute the elliptic curve point R = sG + eQ. Let x denote the
x-coordinate of R.
5. Convert the field element x to a bit string Z. (see: [SEC1]
Section 2.3.5 and 2.3.2).
6. Use message decoding to compute: M = EM^-1(r, Z).
7. If M is an ERROR value, return ERROR, else return M and VALID.
Output: Either an ERROR, or a recovered message M and indication of a
VALID signature.
Campagna Expires April 15, 2013 [Page 25]
Internet-Draft SuiteE October 2012
8. Elliptic Curve Implicit Certificates (ECQV)
In this section we specify the Elliptic Curve Qu-Vanstone implicit
certificate scheme (ECQV).
A traditional certificate scheme consists of a certificate issuer
with a key pair (d, Q) to produce a triplet binding an identity, I,
and a public key, P, using a signature, sig, by invoking the issuer's
private key d. We can represent this certificate as (I, P, sig). An
implicit certificate binds an identity element with a public key
without an explicit signature by creating a pair of elements; an
identity, I, and a public key reconstruction value B. We can
represent this certificate as (I, B).
Verification of the certificate is implicit in the use of the public
key. The public key is bound to the entity identified in the
implicit certificate, and the certification process ensures that only
this entity may recover the associated secret key. In effect,
certificate verification is combined with the cryptographic primitive
for which the signed key is being used. This provides two advantages
over traditional certificates. The first is a cost savings on memory
and bandwidth. Implicit certificates do not require an explicit
signature, reducing the size of the cryptographic material to roughly
1/3rd of a traditional certificate. The second is on computation,
the public key reconstruction operation is computationally more
efficient than a signature verification, and may be combined with
other operations.
The next five sections describe an implicit certificate scheme,
defined in [SEC4]. As in the previous section the elliptic curve
domain parameters and hash functions are assumed. It is also assumed
that the CA has established a key pair (dCA, QCA), and all
communicating parties have access to the public key QCA.
We will assume that certificate validation routines have been
established in regards to verifying certificate validity, key usage
and certificate formatting. These checks will be assumed in steps in
which certificate parsing takes place where possible error values may
be returned.
8.1. Certificate Request
This section describes the basic operations by which an entity A
generates a certificate request. It is assumed that A and CA have an
authenticated channel, but the channel may not be private.
Input: none
Campagna Expires April 15, 2013 [Page 26]
Internet-Draft SuiteE October 2012
Steps:
1. Generate an elliptic curve key pair (kA, RA).(see: [SEC1] Section
3.2.1).
Output: a key pair (kA, RA).
The entity A, requesting the certificate, sends the public key RA
along with purported identity of A to the Certificate Authority, and
stores (kA, RA) for future use, keeping kA secret.
8.2. Certificate Generation
This section describes the certificate generation process executed by
a certificate authority. It is assumed that A and CA have an
authenticated channel, but the channel may not be private.
Input: the following items or equivalent
a. The CA private key dCA.
b. A certificate request consisting of a public key RA and an
identifier for A.
Steps:
1. Validate the public key value RA, if it fails output ERROR. (see:
[SEC1] Section 3.2.2).
2. Generate an elliptic curve key pair (k, kG) (see: [SEC1] Section
3.2.1).
3. Compute the elliptic curve point BA = RA + kG.
4. Convert BA to an octet string BAS (see: [SEC1] Section 2.3.3).
5. Encode the certificate CertA as an octet string consisting of
BAS, and the identity element I, consisting of the identifier for
A and other certificate validity and key usage information.
6. Compute H = AES-MMO(CertA).
7. Convert the bit string H to an integer e (see: [SEC1] Section
2.3.1 and 2.3.8).
8. Compute the integer r = ek + dCA (mod n).
Output: Either an implicit certificate CertA, and private key
Campagna Expires April 15, 2013 [Page 27]
Internet-Draft SuiteE October 2012
contribution value r, or an ERROR value.
8.3. Certificate Reception
This section describes the certificate reception process by which a
certificate requester computes its private key.
Input: the following items or equivalent
a. The CA public key QCA.
b. The key pair generated during the certificate request (kA,
RA).
c. The implicit certificate CertA.
d. The private key contribution value r.
Steps:
1. Parse the certificate CertA into an octet string BAS and an
identity element I or return ERROR.
2. Convert BAS to a public key BA or return ERROR (see: [SEC1]
Section 2.3.4).
3. Validate the public key value BA or return ERROR (see: [SEC1]
Section 3.2.2).
4. Compute H = AES-MMO(CertA).
5. Convert the bit string H to an integer e (see: [SEC1] Section
2.3.1 and 2.3.8).
6. Compute the private key dA = r + ekA (mod n).
7. Compute QA = eBA + QCA.
8. Verify QA = (dA)G otherwise halt and return ERROR.
Output: Either a key pair (dA, QA), or an ERROR value.
8.4. Certificate Public Key Extraction
This section describes the certificate public key reconstruction
operation. This would be done by any entity desiring to authenticate
a cryptographic operation with entity A.
Campagna Expires April 15, 2013 [Page 28]
Internet-Draft SuiteE October 2012
Input: the following items or equivalent
a. The CA public key QCA.
b. The implicit certificate CertA.
Steps:
1. Parse the certificate CertA into an octet string BAS and an
identity element I or return ERROR.
2. Convert BAS to a public key BA or return ERROR.(see: [SEC1]
Section 2.3.4).
3. Validate the public key value BA or return ERROR.(see: [SEC1]
Section 3.2.2).
4. Compute H = AES-MMO(CertA).
5. Convert the bit string H to an integer e. (see: [SEC1] Section
2.3.1 and 2.3.8).
6. Compute QA = eBA + QCA.
Output: Either an alleged public key QA, or an ERROR value.
We say the output is "alleged" since the party that extracted it does
not at this point know that it belongs to the party identified in
CertA. However, the scheme does guarantee that only the identified
party possesses the secret key associated to QA.
Campagna Expires April 15, 2013 [Page 29]
Internet-Draft SuiteE October 2012
9. Elliptic Curve Key Agreement Scheme
The elliptic curve MQV, or ECMQV scheme is a key agreement scheme
based on ECC. We give a description here, but will refer to [SEC1]
as the definitive normative reference. ECMQV can provide a variety
of security properties and we refer the reader to [NIST-800-56] to
use an instantiation of ECMQV that best satisfies their application
security goals. We select ECMQV for SuiteE because of its well
studied security properties, wide standardization, existing
deployment in the constrained environment space and the computational
and bandwidth savings it can provide over competing methods to
provide an authenticated key agreement scheme.
As in previous ECC sections we will assume all parties have agreed
upon and access to validated elliptic curve parameters, and for the
purpose of SuiteE this is the sect283k1 curve as defined in [SEC2].
9.1. ECMQV
This section defines the basic operations of the ECMQV primitive. We
will assume the two communicating parties A and B have established
two key pairs (dA1, QA1) and (dA2, QA2), and (dB1, QB1) and (dB2,
QB2) respectively. The description is presented from A's reference
point, B would perform the same operations with analogous key pairs.
The first of each public key may be a static public key derived from
an implicit certificate and used to authenticate the entity.
Input: The following or equivalent
a. Two key pairs (dA1, QA1) and (dA2, QA2).
b. Two partially validated public keys QB1, QB2 purportedly owned
by B.
c. A key derivation function KDF, and an agreed upon key data
length klength.
d. [Optional] shared information, SHARED_INFO for the KDF.
Steps:
1. Compute an integer QA2bar from QA2:
a. Convert the x-coordinate of QA2 to an integer x.
b. Set xbar = x (mod 2^(ceiling(log_2(n)/2)). (For SuiteE,
xbar = x mod 2^142.)
Campagna Expires April 15, 2013 [Page 30]
Internet-Draft SuiteE October 2012
c. Set QA2bar = xbar + 2^(ceiling(log_2(n)/2). (For SuiteE
QA2bar = xbar + 2^142.)
2. Compute the integer s = dA2 + QA2bar*dA2 (mod n)
3. Compute an integer QB2bar from QB2:
a. Convert the x-coordinate of QB2 to an integer x'.
b. Set xbar' = x' (mod 2^(ceiling(log_2(n)/2)). (For SuiteE,
xbar' = x' mod 2^142.)
c. Set QB2bar = xbar' + 2^(ceiling(log_2(n)/2). (For SuiteE
QB2bar = xbar' + 2^142.)
4. Compute the point P = h*s(QB2 + QB2bar*QB1), where h is the
cofactor defined as #E(Fq)/n, which is 4 for the SuiteE curve
sect283k1.
5. If P = point at infinity output ERROR and exit.
6. Convert the x-coordinate of P to an octet string Z.
7. Use the KDF function with input Z, klength, and the optional
SHARED_INFO, to generate either the shared key value K or return
an ERROR.
Output: Shared secret key K of klength, or an ERROR value.
Campagna Expires April 15, 2013 [Page 31]
Internet-Draft SuiteE October 2012
10. References
10.1. Normative References
[FIPS-180-3]
National Institute of Standards and Technology, "Secure
Hash Standard", FIPS 180-3, October 2008, <http://
csrc.nist.gov/publications/fips/fips180-3/
fips180-3_final.pdf>.
[FIPS-197]
National Institute of Standards and Technology, "Advanced
Encryption Standard", FIPS 197, November 2001, <http://
csrc.nist.gov/publications/fips/fips197/fips-197.pdf>.
[IEEE-802.15.4-2003]
IEEE Computer Society, "IEEE Standard for Information
technology -- Part 15.4: Wireless Medium Access Control
(MAC) and Physical Layer (PHY) Specifications for Low-Rate
Wireless Personal Area Networks (LR-WPANs)", IEEE Standard
for Information technology 802.15.4, October 2003.
[ISO-10118-2]
International Organization for Standards and the
International Electrotechnical Commission, "ISO/IEC
10118-2, Information technology - Security techniques -
Hash functions - Part 2: Hash-functions using an n-bit
block cipher", Information technology - Security
techniques 10118-2, December 2000.
[NIST-800-108]
National Institute of Standards and Technology, "NIST SP
800-108, Recommendation for Key Derivation Using
Pseudorandom Functions", NIST Special Publication 800-108,
October 2009, <http://csrc.nist.gov/publications/nistpubs/
800-108/sp800-108.pdf>.
[NIST-800-38C]
National Institute of Standards and Technology, "NIST SP
800-38C, Recommendation for Block Cipher Modes of
Operation: The CCM Mode for Authentication and
Confidentiality", NIST Special Publication 800-38C,
July 2007, <http://csrc.nist.gov/publications/nistpubs/
800-38C/SP800-38C_updated-July20_2007.pdf>.
[NIST-800-56]
National Institute of Standards and Technology,
"Recommendation for Pair-wise Key Establishment Schemes
Campagna Expires April 15, 2013 [Page 32]
Internet-Draft SuiteE October 2012
Using Discrete Logarithm Cryptography (Revised)", NIST
Special Publication 800-56a, March 2007, <http://
csrc.nist.gov/publications/nistpubs/800-56A/
SP800-56A_Revision1_Mar08-2007.pdf>.
[NIST-800-57]
National Institute of Standards and Technology,
"Recommendation for Key Management - Part 1: General
(Revised)", NIST Special Publication 800-57, March 2007, <
http://csrc.nist.gov/publications/nistpubs/800-57/
sp800-57-Part1-revised2_Mar08-2007.pdf>.
[NIST-800-90]
National Institute of Standards and Technology, "NIST SP
800-90, Recommendation for Random Number Generation Using
Deterministic Random Bit Generators(Revised)", NIST
Special Publication 800-90, March 2007, <http://
csrc.nist.gov/publications/nistpubs/800-90/
SP800-90revised_March2007.pdf>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with
CBC-MAC (CCM)", RFC 3610, September 2003.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, April 2004.
[SEC1] Standards for Efficient Cryptography Group, "SEC1:
Elliptic Curve Cryptography", SEC 1, May 2009,
<http://www.secg.org/download/aid-780/sec1-v2.pdf>.
[SEC2] Standards for Efficient Cryptography Group, "SEC2:
Recommended Elliptic Curve Domain Parameters", SEC 2,
September 2010,
<http://www.secg.org/download/aid-784/sec2-v2.pdf>.
[SEC4] Standards for Efficient Cryptography Group, "Elliptic
Curve Qu-Vanstone Implicit Certificate Scheme (ECQV),
v0.97", SEC 4, March 2011,
<http://www.secg.org/download/aid-785/sec4-0.97.pdf>.
Campagna Expires April 15, 2013 [Page 33]
Internet-Draft SuiteE October 2012
[X9.92.1] Accredited Standards Committee X9, Inc., "Public Key
Cryptography for the Financial Services Industry - Digital
Signature Algorithms Giving Partial Message Recovery -
Part 1: Elliptic Curve Pintsov-Vanstone Signatures
(ECPVS)", X9 92-1, 2009, <http://webstore.ansi.org/
RecordDetail.aspx?sku=ANSI+X9.92-1-2009>.
[ZigBee] ZigBee Standards Organization, "ZigBee Specification,
revision 17", October 2007, <http://www.zigbee.org/
ZigBeeSpecificationDownloadRequest/tabid/311/
Default.aspx>.
Registration required.
10.2. Informative References
[HMV04] Hankerson, D., Menezes, A., and S. Vanstone, "Guide to
Elliptic Curve Cryptography", 2004.
Springer, ISBN 038795273X.
[IEEE1363]
Institute of Electrical and Electronics Engineers,
"Standard Specifications for Public Key Cryptography",
IEEE 1363, 2000.
[IEEE1363-A]
Institute of Electrical and Electronics Engineers,
"Standard Specifications for Public Key Cryptography -
Amendment 1: Additional Techniques", IEEE 1363a, 2004.
[LMQSV98] Law, L., Menezes, A., Qu, M., Solinas, J., and S.
Vanstone, "An Efficient Protocol for Authenticated Key
Agreement", University of Waterloo Technical Report
CORR 98-05, August 1998, <http://
www.cacr.math.uwaterloo.ca/techreports/1998/
corr98-05.pdf>.
[MOV96] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook
of Applied Cryptography", 1996,
<http://www.cacr.math.uwaterloo.ca/hac>.
CRC Press, ISBN 0-8493-8523-7. Available online.
[NIST57] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
"Recommendation for Key Management - Part 1: General
(revised)", March 2007, <http://csrc.nist.gov/
publications/nistpubs/800-57/
Campagna Expires April 15, 2013 [Page 34]
Internet-Draft SuiteE October 2012
sp800-57-Part1-revised2_Mar08-2007.pdf>.
NIST Special Publication 800-57
[NSW07] Neven, G., Smart, N., and B. Warinschi, "Hash function
requirements for Schnorr signatures", Journal of
Mathematical Cryptology Volume 3 Number 1, May 2009.
[X9.123] Accredited Standards Committee X9, Inc., "Elliptic Curve
Qu-Vanstone Implicit Certificates (Draft)", X9 123, 2011.
[ZigBeeSE]
ZigBee Standards Organization, "ZigBee Smart Energy
Profile Specification, revision 15", December 2008, <http:
//www.zigbee.org/
ZigBeeSmartEnergyPublicApplicationProfile/tabid/312/
Default.aspx>.
Registration required.
Campagna Expires April 15, 2013 [Page 35]
Internet-Draft SuiteE October 2012
Appendix A. Acknowledgments
Campagna Expires April 15, 2013 [Page 36]
Internet-Draft SuiteE October 2012
Author's Address
Matthew Campagna
Certicom Corp.
4701 Tahoe Boulevard
Mississauga, Ontario L4W 0B5
Canada
Email: mcampagna@certicom.com
Campagna Expires April 15, 2013 [Page 37]