One document matched: draft-campagna-suitee-04.xml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2104 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2104.xml'>
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2246 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2246.xml'>
<!ENTITY rfc3610 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3610.xml'>
<!ENTITY rfc3766 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3766.xml'>
<!ENTITY rfc4346 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4346.xml'>
<!ENTITY rfc4366 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4366.xml'>
<!ENTITY rfc4492 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4492.xml'>
<!ENTITY rfc5246 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml'>
]>
<rfc category="std" ipr="trust200902" docName="draft-campagna-suitee-04">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<front>
<title abbrev="SuiteE">A Cryptographic Suite for Embedded Systems (SuiteE)</title>
<author initials="M." surname="Campagna" fullname="Matthew Campagna">
<organization>Certicom Corp.</organization>
<address>
<postal>
<street>4701 Tahoe Boulevard</street>
<city>Mississauga</city>
<region>Ontario</region>
<code>L4W 0B5</code>
<country>Canada</country>
</postal>
<email>mcampagna@certicom.com</email>
</address>
</author>
<date month="October" day="12" year="2012" />
<area>Security</area>
<workgroup>Network Working Group</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>Elliptic Curve Cryptography (ECC)</keyword>
<keyword>Constrained Embedded Systems</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction" toc="default">
<t>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. </t>
<t>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.</t>
<t>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.</t>
<t>
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. <xref target="NIST57" pageno="false" format="default" /> provides recommendations on
general key management and security levels. We summarize the comparable
strengths table and recommended minimum sizes:
</t>
<texttable title="" suppress-title="false" align="center" style="full">
<ttcol align="center">Algorithm Lifetime</ttcol>
<ttcol align="center">Security Strength</ttcol>
<ttcol align="center">Symmetric Key Size</ttcol>
<ttcol align="center">Integer Factorization Cryptography Key Size (e.g., RSA) Size</ttcol>
<ttcol align="center">Elliptic Curve Cryptography (ECC) Key Size</ttcol>
<c> Through 2010 </c>
<c> 80 bits </c>
<c> 80 </c>
<c> 1024</c>
<c> 160 </c>
<c> Through 2030 </c>
<c> 112 bit </c>
<c> 112</c>
<c> 2048 </c>
<c> 256 </c>
<c> Beyond 2030</c>
<c> 128 bit</c>
<c> 128 </c>
<c> 3072 </c>
<c> 256 </c>
<c> >Beyond 2030</c>
<c> 192 bit </c>
<c> 192 </c>
<c> 7680 </c>
<c> 384</c>
<c> >>Beyond 2030</c>
<c> 256 bit </c>
<c> 256 </c>
<c> 15360 </c>
<c> 512</c>
</texttable>
<t>
<xref target="NIST57" pageno="false" format="default" /> 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.
</t>
<t>Considering the expected life span of many of these systems and best
industry practice we target the 128 bit security strengths for SuiteE.</t>
<t> The design goals of SuiteE are: </t>
<list>
<t>Provide re-usable primitives </t>
<t>Reduce code size </t>
<t>To be suitable for hardware implementation </t>
<t>Reduce computational costs </t>
<t>Reduce energy usage and increase battery lifespan </t>
</list>
<t>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 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.</t>
<t>
The remainder of this document is organized as follows. <xref target="encryption" /> provides an authenticated encryption mode AES-CCM*. <xref target="DRBG"/> provides a deterministic random number generator. <xref target="hash" /> describes a hashing algorithm using the existing AES core in an AES-MMO mode. <xref target="curve"/> indicates why elliptic curve technology is selected and the specific curve selection sect283k1. <xref target="signature" /> specifies the use of an elliptic curve signature scheme with partial message recovery. <xref target="implicitcertificates" /> provides an implicit certificate scheme. <xref target="keyagreement" /> describes an elliptic curve based mutual authenticated key agreement scheme.
</t>
</section>
<section anchor="encryption" title="Encryption" toc="default">
<t>
IEEE 802.15.4 <xref target="IEEE-802.15.4-2003" pageno="false" format="default" /> 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 <xref target = "FIPS-197" pageno="false" format="default"/>. Using <xref target="IEEE-802.15.4-2003" pageno="false" format="default" /> as the normative reference we present a description of AES-CCM* here.
</t>
<t>
In the sections that follow we will assume that the basic block cipher
is AES-128 as specified in <xref target = "FIPS-197" pageno="false"
format="defeat"/>. 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).
</t>
<section anchor="AES-CTR" title ="AES-CTR Mode">
<t>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.</t>
<t>Input: a 128-bit symmetric key K, and a plaintext message P of length Plen, and initial counter value CTR</t>
<list style="numbers">
<t>Compute m = ceiling(Plen/128). </t>
<t>Apply the counter generator function to CTR to compute CTR_1, CTR_2, ..., CTR_m.</t>
<t>Compute S_j = E(CTR_j, K), for j = 1,...,m.</t>
<t>Let S = S_1||S_2||...||S_m, where || indicates concatenation.</t>
<t>Compute C = P XOR MSB_Plen(S), where MSB_X( ) takes the X most significant bits.</t>
</list>
<t>Output: C</t>
<t>The Decryption routine for CTR mode is symmetric.</t>
<t>Input: a 128-bit symmetric key K, and a ciphertext message C of length Clen, and initial counter value CTR</t>
<list style="numbers">
<t>Compute m = ceiling(Clen/128). </t>
<t>Apply the counter generator function to CTR to compute CTR_1, CTR_2, ..., CTR_m.</t>
<t>Compute S_j = E(CTR_j, K), for j = 1,...,m.</t>
<t>Let S = S_1||S_2||...||S_m, where || indicates concatenation.</t>
<t>Compute P = C XOR MSB_Clen(S), where MSB_X( ) takes the X most significant bits.</t>
</list>
<t>Output: P</t>
</section>
<section anchor="AES-CBC-MAC" title="AES-CBC-MAC Mode">
<t>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. </t>
<t>Input: a 128-bit symmetric key K, a message M of length Mlen</t>
<list style="numbers">
<t>Form B by padding message M on the right with 0-bytes to be on a byte boundary of the block length (16-bytes).</t>
<t>Form B = B_1||B_2||...||B_m.</t>
<t>Set O_0 to a zeroized block-length byte string.</t>
<t>Compute O_j = E(O_j-1 XOR B_j, K).</t>
<t>Set MAC T = O_m.</t>
</list>
<t>Output: T</t>
<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'.</t>
</section>
<section anchor="AES-CCM*" title="AES-CCM* Mode">
<t>
CCM mode is an authenticate and encrypt mode for block ciphers defined in <xref target="NIST-800-38C" pageno="false" format="default"/>. 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.
</t>
<section anchor="AES-CCM*-Encrypt" title="AES-CCM* Encrypt">
<t>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.</t>
<t>Input:</t>
<list style="empty">
<t>a. A 128-bit symmetric key K.</t>
<t>b. A value 1 < L < 9.</t>
<t>c. A nonce N of 15 - L octets, unique within the usage of the key K.</t>
<t>d. An octet string m of length l(m), where 0 <= l(m) < 2^8L.</t>
<t>e. An octet string a of length l(a), where 0 <= l(a) < 2^64.</t>
</list>
<section anchor="input_transformation" title="Input Transformation">
<t>Input:</t>
<list style="empty">
<t>a. An octet string m of length l(m), where 0 <= l(m) < 2^8L.</t>
<t>b. An octet string a of length l(a), where 0 <= l(a) < 2^64.</t>
</list>
<list style="numbers">
<t>Represent the length l(a) as an octet string L(a).</t>
<list style="empty">
<t>a. If l(a) = 0, then L(a) is an empty string.</t>
<t>b. If 0 < l(a) < 2^16 - 2^8, then L(a) is the 2-octet representation of l(a).</t>
<t>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).</t>
<t>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).</t>
</list>
<t>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.</t>
<t>Form PlaintextData = m || 0^s, where 0^s is the smallest non-negative string of s zero octets so that the resulting PlaintextData octet length is a multiple of 16.</t>
<t>Form AuthData = AddAuthData || PlaintextData.</t>
</list>
<t>Output: AuthData</t>
</section>
<section anchor="authentication_transformation" title="Authentication Transformation">
<t>Input:</t>
<list style="empty">
<t>a. A 128-bit symmetric key K.</t>
<t>b. The octet string AuthData, created in the input transformation.</t>
<t>c. A nonce N of 15 - L octets, unique within the usage of the key K.</t>
<t>d. The length l(m), where 0 <= l(m) < 2^8L.</t>
</list>
<list style="numbers">
<t>
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.
</t>
<t>Form B0 = Flags || Nonce N || l(m)</t>
<t>Parse the message AuthData as B1 || B2 || ... ||Bt, where each message block Bi is a 16-octet string.</t>
<t>The CBC-MAC value T = AES-CBC-MAC(B_0 || AuthData, K) as defined by <xref target="AES-CBC-MAC"/>.</t>
</list>
<t>Output: T</t>
</section>
<section anchor="encryption_transformation" title="Encryption Transformation">
<t>Input:</t>
<list style="empty">
<t>a. A 128-bit symmetric key K.</t>
<t>
b. PlaintextData from <xref target="input_transformation"/>.
</t>
<t>
c. The authentication tag output T from <xref target="authentication_transformation"/>.
</t>
<t>d. A nonce N of length 15-L bytes. </t>
</list>
<list style="numbers">
<t>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.</t>
<t>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. </t>
<t>
Parse the PlaintextData from <xref target="input_transformation"/> into 16-octet blocks M_1, ..., M_t.
</t>
<t>Compute C_i = E(A_i, K) XOR M_i for i = 1, ..., t.</t>
<t>Compute Ciphertext as the leftmost l(m) bits of C_1 || ... || C_t.</t>
<t>Compute S_0 = E(A_0, K) XOR T. </t>
<t>Compute AuthTag as the leftmost M octets of S_0. </t>
</list>
<t>Output: Ciphertext and AuthTag</t>
</section>
</section>
<section anchor="AES-CCM*-Decrypt" title="AES-CCM* Decrypt">
<t>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.</t>
<t>Input:</t>
<list style="empty">
<t>a. A 128-bit symmetric key K.</t>
<t>b. A nonce N of 15 - L octets, unique within the usage of the key K.</t>
<t>c. An M-octet tag AuthTag.</t>
<t>d. An octet string Ciphertext of length l(c), where 0 <= l(c) - M < 2^8L.</t>
</list>
<section anchor="decryption_transformation" title="Decryption Transformation">
<t>Input:</t>
<list style="empty">
<t>a. A 128-bit symmetric key K.</t>
<t>b. A nonce N of 15 - L octets, unique within the usage of the key K.</t>
<t>c. An M-octet tag AuthTag.</t>
<t>d. An octet string Ciphertext of length l(c), where 0 <= l(c) - M < 2^8L.</t>
</list>
<list style="numbers">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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. </t>
<t>Parse the C_0||CiphertextData into 16-octet blocks C_0, C_1, ..., C_t.</t>
<t>Compute P_i = E(A_i, K) XOR C_i for i = 0, ..., t.</t>
<t>Form U as the rightmost M-octets of P_0.</t>
<t>Form Plaintext leftmost l(c) octets of P_1||...||P_t.</t>
</list>
<t>Output: U and Plaintext</t>
</section>
<section anchor="verification_transformation" title="Verification Transformation">
<t>Input:</t>
<list style="empty">
<t>a. A 128-bit symmetric key K.</t>
<t>b. Plaintext of length l(c), where 0 <= l(c) < 2^8L.</t>
<t>c. U, the purported MAC of Plaintext.</t>
<t>d. A nonce N of 15 - L octets, unique within the usage of the key K.</t>
</list>
<list style="numbers">
<t>
Compute T as the output of the authentication transformation <xref target="authentication_transformation"/> with the inputs, key K, Plaintext, nonce N, and length value l(c).
</t>
<t>Form T' as the leftmost M octets of T.</t>
<t>If T' = U output Plaintext, otherwise output error code INVALID.</t>
</list>
<t>Output: Plaintext or INVALID</t>
</section>
</section>
</section>
</section>
<section anchor="DRBG" title="Deterministic Random Number Generator" toc="default">
<t>
This section provides a reduced set of options to the CTR_DRBG definition using AES as defined in <xref target="NIST-800-90"/>.
</t>
<list>
<t>Restrict the CTR_DRBG to the use of AES-128 delivering 128-bit security.</t>
<t>General assumption of a full-entropy seed, removing the extra coding
needed for the block_cipher_df and the BCC function as defined in <xref
target="NIST-800-90"/>
</t>
<t>The personalization_string and additional_input options are not supported.</t>
<t>Set maximum_number_of_bits_per_request = 2^16. (Based on convenient word boundary.)</t>
<t>Set reseed_interval = 2^48. (Based on maximizing life of a device that may not have an entropy source.)</t>
</list>
<t>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.</t>
<t>We define the state of the CTR_DRBG using the following structure.</t>
<artwork>
struct{
uint64 counter; // 64-bit counter
uchar V[16]; // state
uchar K[16]; // key
}ctr_drbg;
</artwork>
<section anchor="DRBG_UPDATE" title="CTR_Update" toc="default">
<t>The update function CTR_Update() modifies the internal state variables V and
K of the DRBG structure using provided data.</t>
<t>Input:</t>
<list style="empty">
<t>a. The current state V.</t>
<t>b. The current key K.</t>
<t>c. A 32-byte input, data.</t>
</list>
<list style="numbers">
<t>temp = AES(V+1 (mod 2^128), K) || AES(V+2 (mod 2^128), K).</t>
<t>temp = temp XOR data.</t>
<t>K = leftmost 16 bytes of temp.</t>
<t>V = rightmost 16 bytes of temp.</t>
</list>
<t>Output:</t>
<list style="empty">
<t>a. The updated state V.</t>
<t>b. The updated key K.</t>
</list>
<t>Functionally we write (V, K) = CTR_Update(V, K, data).</t>
</section>
<section anchor="DRBG_INIT" title="CTR_Init" toc="default">
<t>The update function CTR_Update() modifies the internal state variables
V and K of the DRBG structure using provided data.</t>
<t>Input:</t>
<list style="empty">
<t>a. A full entropy 32-byte seed.</t>
</list>
<list style="numbers">
<t>Set V = 0^128, K = 0^128, zeroize state V, and K.</t>
<t>(V, K) = CTR_Update(V, K, seed).</t>
<t>Set counter = 1.</t>
</list>
<t>Output:</t>
<list style="empty">
<t>a. State (counter, V, K)</t>
</list>
<t>Functionally we write (counter V, K) = CTR_Init(seed).</t>
<t>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) = 58E2FCCEFA7E3061367F1D57A4E7455A0388DACE60B6A392F328C2B971B2FE78_{16},
or (K||V) = 58E2FCCEFA7E3061367F1D57A4E7455A0388DACE60B6A392F328C2B971B2FE78 XOR seed.</t>
</section>
<section anchor="DRBG_GEN" title="CTR_Generate" toc="default">
<t>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.</t>
<t>Input:</t>
<list style="empty">
<t>a. Current state (counter, V, K).</t>
<t>b. Requested number of bytes, rlen.</t>
</list>
<list style="numbers">
<t>If counter > 2^48 return ERROR.</t>
<t>If rlen > 2^16 return ERROR.</t>
<t>Set output = NULL</t>
<t>while(length(temp) < rlen)</t>
<list style="empty">
<t>a. V = V + 1 (mod 2^128).</t>
<t>b. output ||= AES(V, K).</t>
</list>
<t>output = leftmost rlen bytes of output.</t>
<t>(V, K) = CTR_Update(V, K, 0^256).</t>
<t>Set counter = counter + 1.</t>
</list>
<t>Output:</t>
<list style="empty">
<t>a. State (counter, V, K)</t>
<t>b. Either NULL and ERROR, or output and SUCCESS</t>
</list>
<t>Functionally we write ((counter V, K), (output, RESULT_CODE)) = CTR_Generate(V, K, data).</t>
</section>
</section>
<section anchor="hash" title="Hash" toc="default">
<t>
<xref target = "ISO-10118-2" pageno="false" format="default"/>
specifies hash functions using an n-bit block cipher. The first function
from <xref target = "ISO-10118-2" pageno="false" format="default"/> ("Hash-function one") maps
arbitrary length inputs to n-bit outputs. This is the Matyas-Meyer-Oseas (MMO) construction described in <xref target = "MOV96"
pageno="false" format="default"/>. 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.
</t>
<t>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. </t>
<t>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.</t>
<section anchor="pre-Padding" title="Prefix-Free Encoding" toc="default">
<t>The prefix-free encoding step is defined as follows:</t>
<t>Input: message M of bitlength Mlen</t>
<t>Output: M' of bitlength Mlen + 128</t>
<list style="empty">
<t>1. If Mlen >= 2^64 return ERROR.</t>
<t>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.) </t>
<t>3. Prepend (left-pad) and output Mblen to M, i.e., output M' = Mblen||M.</t>
</list>
</section>
<section anchor="Padding" title="MD-strengthening" toc="default">
<t>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 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</t>
<section anchor="MD1" title="MD-strengthening-1" toc="default">
<t>Input: A message M of bitlength Mlen.</t>
<list style="numbers">
<t>If Mlen >= 2^16 return ERROR.</t>
<t>Pad the message M:</t>
<list style="empty">
<t>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. </t>
<t>b. Form the padded message M' by right concatenating the resulting string with a 16-bit
string that is equal to the value Mlen.</t>
</list>
</list>
<t>Output: M' = M_1, M_2, ..., M_m a padded message in 128-bit blocks.</t>
</section>
<section anchor="MD2" title="MD-strengthening-2" toc="default">
<t>Input: A message M of bitlength Mlen.</t>
<list style="numbers">
<t>If Mlen < 2^16 or Mlen >= 2^32 return ERROR.</t>
<t>Pad the message M:</t>
<list style="empty">
<t>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. </t>
<t>b. Form the padded message M'' by right concatenating the resulting string with a 32-bit string that is equal the value Mlen.</t>
<t>c. Form the padded message M' by right concatenating M'' with a 16-bit 0 string.</t>
</list>
</list>
<t>Output: M' = M_1, M_2, ..., M_m a padded message in 128-bit blocks.</t>
</section>
<section anchor="MD3" title="MD-strengthening-3" toc="default">
<t>Input: A message M of bitlength Mlen.</t>
<list style="numbers">
<t>
If Mlen < 2^32 or Mlen= >= 2^64 return ERROR.
</t>
<t>Pad the message M:</t>
<list style="empty">
<t>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. </t>
<t>b. Form the padded message M'' by right concatenating the resulting string with a 64-bit string that is equal the value Mlen.</t>
<t>c. Form the padded message M' by right concatenating M'' with a 48-bit 0 string.</t>
</list>
</list>
<t>Output: M' = M_1, M_2, ..., M_m a padded message in 128-bit blocks.</t>
</section>
</section>
<section anchor="MMO" title ="MMO Construction" toc="default">
<t>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.</t>
<t>Input: A message M of bitlength Mlen.</t>
<list style="numbers">
<t>Apply the prefix-free encoding to M to form a bitstring M', with bitlength Mlen' = Mlen + 128.</t>
<t>Pad and format M' in 128-bit blocks using one of the MD
routines specified above or return ERROR.</t>
<t>Set H_0 = 0^128, a zeroized 128-bit block.</t>
<t>Compute H_j = E(M_j, H_(j-1)) XOR M_j, for j = 1, ..., m.</t>
</list>
<t>Output: H = H_m as the hash value.</t>
</section>
</section>
<section anchor="kdf" title="Key Derivation Function" toc="default">
<t>
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 <xref target="NIST-800-108" pageno="false"/> which are suitable,
and may be instantiated with AES-CMAC as a pseudo-random function.
</t>
</section>
<section anchor="curve" title="Curve Selection" toc="default">
<t>
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, <xref target = "SEC1" pageno="false"
format="default"/>. This specification defines the basic ECC operations as
well as the most widely standardized and used techniques. The overall goal of
<xref target = "SEC1" pageno="false" format="default"/> 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.
</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>
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 <xref target="SEC2" pageno="false" format="default"/> 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.
</t>
<t>
For a basic description of the algorithms the reader is referred to
<xref target="SEC1" pageno="false" format="default"/>. For a more complete
background and optimizations for elliptic curves the reader is referred to
<xref target="HMV04" pageno="false" format="default"/>.
</t>
<t>Throughout the following sections on elliptic curve cryptography we will use the following notation</t>
<t>Fq - is a finite field with q elements.</t>
<t>E - an elliptic curve over Fq, given by the equation y^2 + xy = x^3 + ax^2 + b.</t>
<t>E(Fq) - the group of elliptic curve points over Fq.</t>
<t>G - is a base point in E(Fq) of a large prime order.</t>
<t>n - is a large prime, and the order of the subgroup generated by G.</t>
<t>h - is the cofactor, h = #E(Fq)/n.</t>
<t>
Further we will assume it is known how to generate elliptic curve key
pairs, and will refer the reader to the freely available specification <xref
target = "SEC1" pageno="false" format="default"/>. 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.
</t>
<section anchor="sect283k1" title="SECT283K1 Curve Parameters" toc="default">
<t>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.</t>
<t>E - the elliptic curve is defined as E:y^2 + xy = x^3 + b.</t>
<t>
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.
</t>
<t>n - is a large prime, and the order of the subgroup generated by G, n = 01FFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFE9AE 2ED07577 265DFF7F 94451E06 1E163C61.</t>
<t>h - is the cofactor, #E(Fq)/n, h = 4.</t>
</section>
</section>
<section anchor="signature" title="Elliptic Curve Signatures with Partial Message Recovery" toc="default">
<t>
Elliptic Curve Pintsov-Vanstone Signatures (ECPVS) is an elliptic
curve variant of Nyberg-Rueppel signatures. ECPVS is standardized in <xref
target = "X9.92.1" pageno="false" format="default"/> and
<xref target = "IEEE1363-A" pageno="false" format="default"/>. 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 <xref target = "NSW07" pageno="false" format="default"/>.
Thus the AES-MMO hash primitive in SuiteE (see Section <xref target="hash"/>)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).
</t>
<t>
We assume all parties possess the domain parameters for the elliptic curve, as chosen
in <xref target="curve"/>, and that the public keys of signers are validated as described in <xref target="SEC1"/>, Section 3.2.2.
</t>
<t>
The scheme presented here is a variant of ECPVS as presented in
<xref target = "X9.92.1" pageno="false" format="default"/>,
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*.
</t>
<t>ECPVS uses encoding and decoding routines to process signatures.</t>
<section anchor="message formatting" title ="Message Encoding and Decoding Methods" toc ="default">
<t>
The following subsections specify the encoding and decoding
operation primitives that shall be used to generate ECPVS
signatures and to verify ECPVS signatures.
</t>
<section anchor="encoding" title="Message Encoding">
<t>Input: The input to the encoding operation is:</t>
<list>
<t>a. A recoverable message part, which is a bit string M of length Mlen bits.</t>
<t>b. A bit string Z (used to derive a key).</t>
</list>
<t>Steps</t>
<list style="numbers">
<t>Form T = 00||M, by prepending a zero byte to the front of M.</t>
<t>Apply the key derivation function KDF to the bit string Z to produce a 128-bit key K.</t>
<t>Let (C, MAC) = AES-CCM*-ENCRYPT(T, K, 128).</t>
<t>Form r = C||MAC, the concatenation of the cipher text value C with the computed MAC value.</t>
</list>
<t>Output: r.</t>
<t>We will denote this process as r = EM(M, Z), for encode message.</t>
</section>
<section anchor="decoding" title="Decoding Messages">
<t> Input: The input to the decoding operation is:</t>
<list>
<t>a. The message representative, which is a bit string r of length rlen bits.</t>
<t>b. A bit string Z.</t>
</list>
<t>Steps</t>
<list style="numbers">
<t>Apply the key derivation function KDF to the bit string Z to produce a 128-bit key K.</t>
<t>Parse the message r = C||MAC, where MAC is the last 16 bytes, or return ERROR.</t>
<t>Compute M' = AES-CCM*-DECRYPT(C, MAC, K, 128).</t>
<t>If M' is ERROR value return ERROR.</t>
<t>Parse M' = 00||M, where 00 is a zeroized byte, or return ERROR.</t>
<t>return M.</t>
</list>
<t>Output: ERROR or message value M.</t>
<t>We will denote this process as M = EM^-1(r, Z), for decode message.</t>
</section>
</section>
<!-- end msg formatting section -->
<section anchor="ECPVS" title="Elliptic Curve Pintsov-Vanstone Signatures (ECPVS)">
<t>This section contains two subsections, signature generation and signature verification.</t>
<section anchor="ECPVSSign" title="Signature Generation">
<t>Input: The input to the signature generation transformation is:</t>
<list>
<t>
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.
</t>
<t>b. An elliptic curve private key d.</t>
</list>
<t>Steps:</t>
<list style="numbers">
<t>
Generate an ephemeral key pair (k, R) with R = (x, y). (see: <xref target="SEC1"/> Section 3.2.1).
</t>
<t>
Convert the field element x to a bit string Z. (see: <xref target="SEC1"/> Section 2.3.5 and 2.3.2).
</t>
<t>Encode the recoverable portion of the message r = EM(M, Z).</t>
<t>Compute H = AES-MMO(r||V), where || represents concatenation.</t>
<t>
Convert the bit string H to an integer e. (see: <xref target="SEC1"/> Section 2.3.1 and 2.3.8).
</t>
<t>Compute s = k - de (mod n).</t>
</list>
<t>Output: (r, s) as the signature with partial message recovery on V.</t>
</section>
<section anchor="ECPVSVerify" title="Signature Verification">
<t>Input: The input to verification is:</t>
<list>
<t>a. A message V.</t>
<t>b. A signature with partial message recovery (r, s).</t>
<t>c. The elliptic curve public key Q belonging to the signer.</t>
</list>
<t>Steps:</t>
<list style="numbers">
<t>If s is not an integer in the interval [1, n – 1], return ERROR.</t>
<t>Compute H = AES-MMO(r||V).</t>
<t>
Convert the bit string H to an integer e. (see: <xref target="SEC1"/> Section 2.3.1 and 2.3.8).
</t>
<t>Compute the elliptic curve point R = sG + eQ. Let x denote the x-coordinate of R. </t>
<t>
Convert the field element x to a bit string Z. (see: <xref target="SEC1"/> Section 2.3.5 and 2.3.2).
</t>
<t>Use message decoding to compute: M = EM^–1(r, Z).</t>
<t>If M is an ERROR value, return ERROR, else return M and VALID.</t>
</list>
<t>Output: Either an ERROR, or a recovered message M and indication of a VALID signature.</t>
</section>
</section>
<!-- end sign/verify description -->
</section>
<!-- end ecpvs chapter -->
<section anchor="implicitcertificates" title="Elliptic Curve Implicit Certificates (ECQV)" toc="default">
<t> In this section we specify the Elliptic Curve Qu-Vanstone implicit certificate scheme (ECQV).</t>
<t>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).</t>
<t>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.</t>
<t>
The next five sections describe an implicit certificate scheme, defined in <xref target="SEC4" pageno="false" format="default"/>. 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.
</t>
<t>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.</t>
<section anchor="CertRequest" title="Certificate Request" toc="default">
<t>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.</t>
<t>Input: none</t>
<t>Steps:</t>
<list style="numbers">
<t>
Generate an elliptic curve key pair (kA, RA).(see: <xref target="SEC1"/> Section 3.2.1).
</t>
</list>
<t>Output: a key pair (kA, RA).</t>
<t>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.</t>
</section>
<section anchor="CertGeneration" title="Certificate Generation" toc="default">
<t>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.</t>
<t>Input: the following items or equivalent</t>
<list>
<t>a. The CA private key dCA.</t>
<t>b. A certificate request consisting of a public key RA and an identifier for A.</t>
</list>
<t>Steps:</t>
<list style="numbers">
<t>
Validate the public key value RA, if it fails output ERROR. (see: <xref target="SEC1"/> Section 3.2.2).
</t>
<t>
Generate an elliptic curve key pair (k, kG) (see: <xref target="SEC1"/> Section 3.2.1).
</t>
<t>Compute the elliptic curve point BA = RA + kG.</t>
<t>
Convert BA to an octet string BAS (see: <xref target="SEC1"/> Section 2.3.3).
</t>
<t>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.</t>
<t>Compute H = AES-MMO(CertA).</t>
<t>
Convert the bit string H to an integer e (see: <xref target="SEC1"/> Section 2.3.1 and 2.3.8).
</t>
<t>Compute the integer r = ek + dCA (mod n).</t>
</list>
<t>Output: Either an implicit certificate CertA, and private key contribution value r, or an ERROR value.</t>
</section>
<section anchor="CertRec" title="Certificate Reception" toc="default">
<t>This section describes the certificate reception process by which a certificate requester computes its private key.</t>
<t>Input: the following items or equivalent</t>
<list>
<t>a. The CA public key QCA.</t>
<t>b. The key pair generated during the certificate request (kA, RA).</t>
<t>c. The implicit certificate CertA.</t>
<t>d. The private key contribution value r.</t>
</list>
<t>Steps:</t>
<list style="numbers">
<t>Parse the certificate CertA into an octet string BAS and an identity element I or return ERROR.</t>
<t>
Convert BAS to a public key BA or return ERROR (see: <xref target="SEC1"/> Section 2.3.4).
</t>
<t>
Validate the public key value BA or return ERROR (see: <xref target="SEC1"/> Section 3.2.2).
</t>
<t>Compute H = AES-MMO(CertA).</t>
<t>
Convert the bit string H to an integer e (see: <xref target="SEC1"/> Section 2.3.1 and 2.3.8).
</t>
<t>Compute the private key dA = r + ekA (mod n).</t>
<t>Compute QA = eBA + QCA.</t>
<t>Verify QA = (dA)G otherwise halt and return ERROR.</t>
</list>
<t>Output: Either a key pair (dA, QA), or an ERROR value.</t>
</section>
<section anchor="CertUse" title="Certificate Public Key Extraction" toc="default">
<t>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.</t>
<t>Input: the following items or equivalent</t>
<list>
<t>a. The CA public key QCA.</t>
<t>b. The implicit certificate CertA.</t>
</list>
<t>Steps:</t>
<list style="numbers">
<t>Parse the certificate CertA into an octet string BAS and an identity element I or return ERROR.</t>
<t>
Convert BAS to a public key BA or return ERROR.(see: <xref target="SEC1"/> Section 2.3.4).
</t>
<t>
Validate the public key value BA or return ERROR.(see: <xref target="SEC1"/> Section 3.2.2).
</t>
<t>Compute H = AES-MMO(CertA).</t>
<t>
Convert the bit string H to an integer e. (see: <xref target="SEC1"/> Section 2.3.1 and 2.3.8).
</t>
<t>Compute QA = eBA + QCA.</t>
</list>
<t>Output: Either an alleged public key QA, or an ERROR value.</t>
<t> 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. </t>
</section>
</section>
<section anchor="keyagreement" title="Elliptic Curve Key Agreement Scheme" toc="default">
<t>
The elliptic curve MQV, or ECMQV scheme is a key agreement scheme based
on ECC. We give a description here, but will refer to <xref target="SEC1"
pageno="false" format="default"/> as the definitive normative reference. ECMQV
can provide a variety of security properties and we refer the reader to <xref
target="NIST-800-56" pageno="false" format="default"/> 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.
</t>
<t>
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 <xref target="SEC2"
pageno="false" format="default"/>.
</t>
<section anchor="ECMQV" title="ECMQV" toc="default">
<t>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.</t>
<t>Input: The following or equivalent</t>
<list>
<t>a. Two key pairs (dA1, QA1) and (dA2, QA2).</t>
<t>b. Two partially validated public keys QB1, QB2 purportedly owned by B.</t>
<t>c. A key derivation function KDF, and an agreed upon key data length klength.</t>
<t>d. [Optional] shared information, SHARED_INFO for the KDF. </t>
</list>
<t>Steps:</t>
<list style ="numbers">
<t>Compute an integer QA2bar from QA2:</t>
<list style="empty">
<t>a. Convert the x-coordinate of QA2 to an integer x.</t>
<t>b. Set xbar = x (mod 2^(ceiling(log_2(n)/2)). (For SuiteE, xbar = x mod 2^142.)</t>
<t>c. Set QA2bar = xbar + 2^(ceiling(log_2(n)/2). (For SuiteE QA2bar = xbar + 2^142.)</t>
</list>
<t>Compute the integer s = dA2 + QA2bar*dA2 (mod n)</t>
<t>Compute an integer QB2bar from QB2:</t>
<list style="empty">
<t>a. Convert the x-coordinate of QB2 to an integer x'.</t>
<t>b. Set xbar' = x' (mod 2^(ceiling(log_2(n)/2)). (For SuiteE, xbar' = x' mod 2^142.)</t>
<t>c. Set QB2bar = xbar' + 2^(ceiling(log_2(n)/2). (For SuiteE QB2bar = xbar' + 2^142.)</t>
</list>
<t>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.</t>
<t>If P = point at infinity output ERROR and exit.</t>
<t>Convert the x-coordinate of P to an octet string Z.</t>
<t>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.</t>
</list>
<t>Output: Shared secret key K of klength, or an ERROR value.</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="X9.92.1" target="http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI+X9.92-1-2009">
<front>
<title>Public Key Cryptography for the Financial Services Industry - Digital Signature Algorithms Giving Partial Message Recovery - Part 1: Elliptic Curve Pintsov-Vanstone Signatures (ECPVS)</title>
<author>
<organization>Accredited Standards Committee X9, Inc.</organization>
</author>
<date year="2009" />
</front>
<seriesInfo name="X9" value="92-1" />
<format type="PDF" target="http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI+X9.92-1-2009" />
</reference>
<reference anchor="FIPS-180-3" target="http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf">
<front>
<title>Secure Hash Standard</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="October" year="2008" />
</front>
<seriesInfo name="FIPS" value="180-3" />
<format type="PDF" target="http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf" />
</reference>
<reference anchor="FIPS-197" target="http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf">
<front>
<title>Advanced Encryption Standard</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="November" year="2001" />
</front>
<seriesInfo name="FIPS" value="197" />
<format type="PDF" target="http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf" />
</reference>
<reference anchor="IEEE-802.15.4-2003" target="" >
<front>
<title>
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)
</title>
<author>
<organization>IEEE Computer Society</organization>
</author>
<date month="October" year="2003" />
</front>
<seriesInfo name="IEEE Standard for Information technology" value="802.15.4" />
</reference>
<reference anchor="ISO-10118-2" target="">
<front>
<title>ISO/IEC 10118-2, Information technology - Security techniques - Hash functions - Part 2: Hash-functions using an n-bit block cipher</title>
<author>
<organization>International Organization for Standards and the International Electrotechnical Commission </organization>
</author>
<date month="December" year="2000" />
</front>
<seriesInfo name="Information technology - Security techniques" value="10118-2" />
</reference>
<reference anchor="NIST-800-38C" target="http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C_updated-July20_2007.pdf">
<front>
<title>NIST SP 800-38C, Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="July" year="2007" />
</front>
<seriesInfo name="NIST Special Publication" value="800-38C" />
<format type="PDF" target="http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C_updated-July20_2007.pdf" />
</reference>
<reference anchor="NIST-800-56" target="http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf">
<front>
<title>Recommendation for Pair-wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="March" year="2007" />
</front>
<seriesInfo name="NIST Special Publication" value="800-56a" />
<format type="PDF" target="http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf" />
</reference>
<reference anchor="NIST-800-57" target="http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf">
<front>
<title>Recommendation for Key Management - Part 1: General (Revised)</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="March" year="2007" />
</front>
<seriesInfo name="NIST Special Publication" value="800-57" />
<format type="PDF" target="http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf" />
</reference>
<reference anchor="NIST-800-90" target="http://csrc.nist.gov/publications/nistpubs/800-90/SP800-90revised_March2007.pdf">
<front>
<title>NIST SP 800-90, Recommendation for Random Number Generation Using Deterministic Random Bit Generators(Revised)</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="March" year="2007" />
</front>
<seriesInfo name="NIST Special Publication" value="800-90" />
<format type="PDF" target="http://csrc.nist.gov/publications/nistpubs/800-90/SP800-90revised_March2007.pdf" />
</reference>
<reference anchor="NIST-800-108" target="http://csrc.nist.gov/publications/nistpubs/800-108/sp800-108.pdf">
<front>
<title>NIST SP 800-108, Recommendation for Key Derivation Using Pseudorandom Functions </title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="October" year="2009" />
</front>
<seriesInfo name="NIST Special Publication" value="800-108" />
<format type="PDF" target="http://csrc.nist.gov/publications/nistpubs/800-108/sp800-108.pdf" />
</reference>
&rfc2104;
&rfc2119;
&rfc3610;
&rfc3766;
<reference anchor="SEC1" target="http://www.secg.org/download/aid-780/sec1-v2.pdf">
<front>
<title>SEC1: Elliptic Curve Cryptography</title>
<author>
<organization>Standards for Efficient Cryptography Group</organization>
</author>
<date month="May" day="21" year="2009" />
</front>
<seriesInfo name="SEC" value="1" />
<format type="PDF" target="http://www.secg.org/download/aid-780/sec1-v2.pdf" />
</reference>
<reference anchor="SEC2" target="http://www.secg.org/download/aid-784/sec2-v2.pdf">
<front>
<title>SEC2: Recommended Elliptic Curve Domain Parameters</title>
<author>
<organization>Standards for Efficient Cryptography Group</organization>
</author>
<date month="September" day="27" year="2010" />
</front>
<seriesInfo name="SEC" value="2" />
<format type="PDF" target="http://www.secg.org/download/aid-784/sec2-v2.pdf" />
</reference>
<reference anchor="SEC4" target="http://www.secg.org/download/aid-785/sec4-0.97.pdf">
<front>
<title>Elliptic Curve Qu-Vanstone Implicit Certificate Scheme (ECQV), v0.97</title>
<author>
<organization>Standards for Efficient Cryptography Group</organization>
</author>
<date month="March" day="16" year="2011" />
</front>
<seriesInfo name="SEC" value="4" />
<format type="PDF" target="http://www.secg.org/download/aid-785/sec4-0.97.pdf" />
</reference>
<reference anchor="ZigBee" target="http://www.zigbee.org/ZigBeeSpecificationDownloadRequest/tabid/311/Default.aspx">
<front>
<title>ZigBee Specification, revision 17</title>
<author>
<organization>ZigBee Standards Organization</organization>
</author>
<date month="October" day="19" year="2007" />
</front>
<format type="PDF" target="http://www.zigbee.org/ZigBeeSpecificationDownloadRequest/tabid/311/Default.aspx" />
<annotation>Registration required.</annotation>
</reference>
</references>
<references title="Informative References">
<reference anchor="X9.123" target="">
<front>
<title>Elliptic Curve Qu-Vanstone Implicit Certificates (Draft)</title>
<author>
<organization>Accredited Standards Committee X9, Inc.</organization>
</author>
<date year="2011" />
</front>
<seriesInfo name="X9" value="123" />
</reference>
<reference anchor="HMV04">
<front>
<title>Guide to Elliptic Curve Cryptography</title>
<author initials="D." surname="Hankerson" fullname="Darrel Hankerson">
<organization />
</author>
<author initials="A. J." surname="Menezes" fullname="Alfred J. Menezes">
<organization />
</author>
<author initials="S." surname="Vanstone" fullname="Scott Vanstone">
<organization />
</author>
<date month="" year="2004" />
</front>
<annotation>Springer, ISBN 038795273X.</annotation>
</reference>
<reference anchor="IEEE1363">
<front>
<title>Standard Specifications for Public Key Cryptography</title>
<author>
<organization>Institute of Electrical and Electronics Engineers</organization>
</author>
<date month="" year="2000" />
</front>
<seriesInfo name="IEEE" value="1363" />
</reference>
<reference anchor="IEEE1363-A">
<front>
<title>Standard Specifications for Public Key Cryptography - Amendment 1: Additional Techniques</title>
<author>
<organization>Institute of Electrical and Electronics Engineers</organization>
</author>
<date month="" year="2004" />
</front>
<seriesInfo name="IEEE" value="1363a" />
</reference>
<reference anchor="LMQSV98" target="http://www.cacr.math.uwaterloo.ca/techreports/1998/corr98-05.pdf">
<front>
<title>An Efficient Protocol for Authenticated Key Agreement</title>
<author initials="L." surname="Law" fullname="Laurie Law">
<organization />
</author>
<author initials="A. J." surname="Menezes" fullname="Alfred J. Menezes">
<organization />
</author>
<author initials="M." surname="Qu" fullname="Minghua Qu">
<organization />
</author>
<author initials="J." surname="Solinas" fullname="Jerry Solinas">
<organization />
</author>
<author initials="S." surname="Vanstone" fullname="Scott Vanstone">
<organization />
</author>
<date month="August" year="1998" />
</front>
<seriesInfo name="University of Waterloo Technical Report CORR" value="98-05" />
<format type="PDF" target="http://www.cacr.math.uwaterloo.ca/techreports/1998/corr98-05.pdf" />
</reference>
<reference anchor="NSW07" >
<front>
<title>Hash function requirements for Schnorr signatures</title>
<author initials="G." surname="Neven" fullname ="G. Neven"/>
<author initials="N." surname="Smart" fullname="N. Smart"/>
<author initials="B." surname="Warinschi" fullname="B. Warinschi"/>
<date year ="2009" month="May"/>
</front>
<seriesInfo name="Journal of Mathematical Cryptology" value="Volume 3 Number 1"/>
</reference>
<reference anchor="MOV96" target="http://www.cacr.math.uwaterloo.ca/hac">
<front>
<title>Handbook of Applied Cryptography</title>
<author initials="A. J." surname="Menezes" fullname="Alfred J. Menezes">
<organization />
</author>
<author initials="P. C." surname="van Oorschot" fullname="Paul C. van Oorschot">
<organization />
</author>
<author initials="S." surname="Vanstone" fullname="Scott Vanstone">
<organization />
</author>
<date month="" year="1996" />
</front>
<annotation>CRC Press, ISBN 0-8493-8523-7. Available online.</annotation>
<format type="HTML" target="http://www.cacr.math.uwaterloo.ca/hac/" />
</reference>
<reference anchor="NIST57" target="http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf">
<front>
<title>Recommendation for Key Management - Part 1: General (revised)</title>
<author initials="E." surname="Barker" fullname="Elaine Barker">
<organization />
</author>
<author initials="W." surname="Barker" fullname="William Barker">
<organization />
</author>
<author initials="W." surname="Burr" fullname="William Burr">
<organization />
</author>
<author initials="W." surname="Polk" fullname="William Polk">
<organization />
</author>
<author initials="M." surname="Smid" fullname="Miles Smid">
<organization />
</author>
<date month="March" year="2007" />
</front>
<annotation>NIST Special Publication 800-57</annotation>
<format type="HTML" target="http://www.cacr.math.uwaterloo.ca/hac/" />
</reference>
<reference anchor="ZigBeeSE" target="http://www.zigbee.org/ZigBeeSmartEnergyPublicApplicationProfile/tabid/312/Default.aspx">
<front>
<title>ZigBee Smart Energy Profile Specification, revision 15</title>
<author>
<organization>ZigBee Standards Organization</organization>
</author>
<date month="December" day="1" year="2008" />
</front>
<format type="PDF" target="http://www.zigbee.org/ZigBeeSmartEnergyPublicApplicationProfile/tabid/312/Default.aspx" />
<annotation>Registration required.</annotation>
</reference>
</references>
<section anchor="ack" title="Acknowledgments" toc="default">
<t></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:27:40 |