idnits 2.17.1 draft-campagna-suitee-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 12, 2012) is 4214 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '16' on line 524 == Missing Reference: 'Optional' is mentioned on line 1225, but not defined == Unused Reference: 'FIPS-180-3' is defined on line 1268, but no explicit reference was found in the text == Unused Reference: 'NIST-800-57' is defined on line 1317, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 1332, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1336, but no explicit reference was found in the text == Unused Reference: 'RFC3610' is defined on line 1339, but no explicit reference was found in the text == Unused Reference: 'RFC3766' is defined on line 1342, but no explicit reference was found in the text == Unused Reference: 'ZigBee' is defined on line 1367, but no explicit reference was found in the text == Unused Reference: 'IEEE1363' is defined on line 1381, but no explicit reference was found in the text == Unused Reference: 'LMQSV98' is defined on line 1391, but no explicit reference was found in the text == Unused Reference: 'ZigBeeSE' is defined on line 1419, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-197' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.15.4-2003' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-10118-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-800-108' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-800-38C' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-800-56' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-800-57' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-800-90' ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 3610 -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC2' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC4' -- Possible downref: Non-RFC (?) normative reference: ref. 'ZigBee' Summary: 4 errors (**), 0 flaws (~~), 12 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Campagna 3 Internet-Draft Certicom Corp. 4 Intended status: Standards Track October 12, 2012 5 Expires: April 15, 2013 7 A Cryptographic Suite for Embedded Systems (SuiteE) 8 draft-campagna-suitee-04 10 Abstract 12 This document describes a cryptographic suite of algorithms ideal for 13 constrained embedded systems. It uses the existing IEEE 802.15.4 14 standard as a starting point, builds upon existing embedded 15 cryptographic primitives and suggests additional elliptic curve 16 cryptography (ECC) algorithms and curves. The goal is to define a 17 complete suite of algorithms ideal for embedded systems. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 15, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 2.1. AES-CTR Mode . . . . . . . . . . . . . . . . . . . . . . . 6 56 2.2. AES-CBC-MAC Mode . . . . . . . . . . . . . . . . . . . . . 7 57 2.3. AES-CCM* Mode . . . . . . . . . . . . . . . . . . . . . . 7 58 2.3.1. AES-CCM* Encrypt . . . . . . . . . . . . . . . . . . . 8 59 2.3.2. AES-CCM* Decrypt . . . . . . . . . . . . . . . . . . . 10 60 3. Deterministic Random Number Generator . . . . . . . . . . . . 13 61 3.1. CTR_Update . . . . . . . . . . . . . . . . . . . . . . . . 13 62 3.2. CTR_Init . . . . . . . . . . . . . . . . . . . . . . . . . 14 63 3.3. CTR_Generate . . . . . . . . . . . . . . . . . . . . . . . 15 64 4. Hash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 65 4.1. Prefix-Free Encoding . . . . . . . . . . . . . . . . . . . 16 66 4.2. MD-strengthening . . . . . . . . . . . . . . . . . . . . . 16 67 4.2.1. MD-strengthening-1 . . . . . . . . . . . . . . . . . . 17 68 4.2.2. MD-strengthening-2 . . . . . . . . . . . . . . . . . . 17 69 4.2.3. MD-strengthening-3 . . . . . . . . . . . . . . . . . . 18 70 4.3. MMO Construction . . . . . . . . . . . . . . . . . . . . . 18 71 5. Key Derivation Function . . . . . . . . . . . . . . . . . . . 19 72 6. Curve Selection . . . . . . . . . . . . . . . . . . . . . . . 20 73 6.1. SECT283K1 Curve Parameters . . . . . . . . . . . . . . . . 21 74 7. Elliptic Curve Signatures with Partial Message Recovery . . . 22 75 7.1. Message Encoding and Decoding Methods . . . . . . . . . . 22 76 7.1.1. Message Encoding . . . . . . . . . . . . . . . . . . . 22 77 7.1.2. Decoding Messages . . . . . . . . . . . . . . . . . . 23 78 7.2. Elliptic Curve Pintsov-Vanstone Signatures (ECPVS) . . . . 23 79 7.2.1. Signature Generation . . . . . . . . . . . . . . . . . 24 80 7.2.2. Signature Verification . . . . . . . . . . . . . . . . 24 81 8. Elliptic Curve Implicit Certificates (ECQV) . . . . . . . . . 26 82 8.1. Certificate Request . . . . . . . . . . . . . . . . . . . 26 83 8.2. Certificate Generation . . . . . . . . . . . . . . . . . . 27 84 8.3. Certificate Reception . . . . . . . . . . . . . . . . . . 28 85 8.4. Certificate Public Key Extraction . . . . . . . . . . . . 28 86 9. Elliptic Curve Key Agreement Scheme . . . . . . . . . . . . . 30 87 9.1. ECMQV . . . . . . . . . . . . . . . . . . . . . . . . . . 30 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 89 10.1. Normative References . . . . . . . . . . . . . . . . . . . 32 90 10.2. Informative References . . . . . . . . . . . . . . . . . . 34 91 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 36 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37 94 1. Introduction 96 Constrained embedded systems and in particular devices for wireless 97 personal and body area networks (WPAN and BAN respectively), have 98 unique computation, power and bandwidth constraints. These systems 99 are seeing wider deployment in Smart Energy, Home Automation, 100 Personal Home and Health Care, and more broadly the so-called 101 Internet of Things. The environments in which they are being 102 deployed require varying degrees of security. 104 The Cryptographic Suite for Embedded Systems (SuiteE) aims to 105 optimally meet the wide variety of cryptographic requirements, by 106 providing a compact and complete collection of cryptographic 107 algorithms having minimal code space, computational requirements and 108 bandwidth usage. Additionally the selection of these algorithms are 109 tuned to minimize overall system costs in mass production by 110 selecting easily embeddable algorithms which will further reduce code 111 space, energy usage and increase computational performance. It is 112 expected that this suite of algorithms can be used to provide 113 security solutions in the 6lowpan and CoRE space. 115 Mass production economics see many benefits of placing fixed routines 116 in hardware. The benefits are in code space, performance, battery 117 life, and overall cost of the device. This is the fundamental reason 118 why most IEEE 802.15.4 devices implement AES in hardware today. 119 Considering the projected scale of the so-called Internet of things 120 (Cisco estimates the smart grid alone to be 100 to 1000 times the 121 size of the Internet today), efficiencies and cost savings realized 122 in embedding more of the lower level operations in hardware 123 transforms into a basic requirement - technology selection should 124 afford benefits to embedding in hardware. 126 Many of the environments in which these new embedded systems are 127 being deployed have a life expectancy of 20+ years. This requires 128 the selection of key lifecycle management mechanisms at a security 129 level adequate to deliver the desired security services for the 130 lifespan of the system. [NIST57] provides recommendations on general 131 key management and security levels. We summarize the comparable 132 strengths table and recommended minimum sizes: 134 +-----------+----------+-----------+-----------------+--------------+ 135 | Algorithm | Security | Symmetric | Integer | Elliptic | 136 | Lifetime | Strength | Key Size | Factorization | Curve | 137 | | | | Cryptography | Cryptography | 138 | | | | Key Size (e.g., | (ECC) Key | 139 | | | | RSA) Size | Size | 140 +-----------+----------+-----------+-----------------+--------------+ 141 | Through | 80 bits | 80 | 1024 | 160 | 142 | 2010 | | | | | 143 | | | | | | 144 | Through | 112 bit | 112 | 2048 | 256 | 145 | 2030 | | | | | 146 | | | | | | 147 | Beyond | 128 bit | 128 | 3072 | 256 | 148 | 2030 | | | | | 149 | | | | | | 150 | >Beyond | 192 bit | 192 | 7680 | 384 | 151 | 2030 | | | | | 152 | | | | | | 153 | >>Beyond | 256 bit | 256 | 15360 | 512 | 154 | 2030 | | | | | 155 +-----------+----------+-----------+-----------------+--------------+ 157 [NIST57] does not provide guidance on life span for security 158 strengths for 192 and 256 bit presumably because of the uncertainty 159 in forecasting technology 30+ years out. 161 Considering the expected life span of many of these systems and best 162 industry practice we target the 128 bit security strengths for 163 SuiteE. 165 The design goals of SuiteE are: 167 Provide re-usable primitives 169 Reduce code size 171 To be suitable for hardware implementation 173 Reduce computational costs 175 Reduce energy usage and increase battery lifespan 177 A complete cryptographic cipher suite should consist of primitives 178 from which the security services of identification and 179 authentication, confidentiality, data integrity and non-repudiation 180 can be provided. We prescribe an encryption scheme with 181 authentication, a deterministic random number generator, a hash 182 function, a key-agreement scheme, a digital signature scheme, and a 183 certificate scheme that achieves a 128-bit security level, and 184 achieves the goals identified above. 186 The remainder of this document is organized as follows. Section 2 187 provides an authenticated encryption mode AES-CCM*. Section 3 188 provides a deterministic random number generator. Section 4 189 describes a hashing algorithm using the existing AES core in an AES- 190 MMO mode. Section 6 indicates why elliptic curve technology is 191 selected and the specific curve selection sect283k1. Section 7 192 specifies the use of an elliptic curve signature scheme with partial 193 message recovery. Section 8 provides an implicit certificate scheme. 194 Section 9 describes an elliptic curve based mutual authenticated key 195 agreement scheme. 197 2. Encryption 199 IEEE 802.15.4 [IEEE-802.15.4-2003] specifies the use of AES-CCM*, a 200 variation of the Counter Mode with Cipher Block Chaining MAC (CBC- 201 MAC) using AES-128. AES-128 is specified in [FIPS-197]. Using 202 [IEEE-802.15.4-2003] as the normative reference we present a 203 description of AES-CCM* here. 205 In the sections that follow we will assume that the basic block 206 cipher is AES-128 as specified in [FIPS-197]. We will represent AES- 207 128 as a function E taking two 128-bit inputs, a message block M, and 208 key K, with 128-bit output C = E(M, K). 210 2.1. AES-CTR Mode 212 CTR mode or Counter Mode is a block cipher mode for providing 213 confidentiality. It has some specific advantages in that both the 214 encryption and decryption routines only require the block cipher to 215 operate in a forward, or encrypt-only, direction. 217 Input: a 128-bit symmetric key K, and a plaintext message P of length 218 Plen, and initial counter value CTR 220 1. Compute m = ceiling(Plen/128). 222 2. Apply the counter generator function to CTR to compute CTR_1, 223 CTR_2, ..., CTR_m. 225 3. Compute S_j = E(CTR_j, K), for j = 1,...,m. 227 4. Let S = S_1||S_2||...||S_m, where || indicates concatenation. 229 5. Compute C = P XOR MSB_Plen(S), where MSB_X( ) takes the X most 230 significant bits. 232 Output: C 234 The Decryption routine for CTR mode is symmetric. 236 Input: a 128-bit symmetric key K, and a ciphertext message C of 237 length Clen, and initial counter value CTR 239 1. Compute m = ceiling(Clen/128). 241 2. Apply the counter generator function to CTR to compute CTR_1, 242 CTR_2, ..., CTR_m. 244 3. Compute S_j = E(CTR_j, K), for j = 1,...,m. 246 4. Let S = S_1||S_2||...||S_m, where || indicates concatenation. 248 5. Compute P = C XOR MSB_Clen(S), where MSB_X( ) takes the X most 249 significant bits. 251 Output: P 253 2.2. AES-CBC-MAC Mode 255 Cipher Block Chaining MAC Mode, CBC-MAC mode uses a block cipher to 256 provide data integrity. Unlike CTR mode, that operates on arbitrary 257 length strings CBC-MAC requires message padding to be on a multiple 258 of the block length. The last message block will be padded out using 259 zero bytes. 261 Input: a 128-bit symmetric key K, a message M of length Mlen 263 1. Form B by padding message M on the right with 0-bytes to be on a 264 byte boundary of the block length (16-bytes). 266 2. Form B = B_1||B_2||...||B_m. 268 3. Set O_0 to a zeroized block-length byte string. 270 4. Compute O_j = E(O_j-1 XOR B_j, K). 272 5. Set MAC T = O_m. 274 Output: T 276 Verification is done by identical computation on input K, message M, 277 and purported MAC T' and an additional check where the computed MAC 278 value T is compared to the received MAC value T' and accepted only if 279 T = T'. 281 2.3. AES-CCM* Mode 283 CCM mode is an authenticate and encrypt mode for block ciphers 284 defined in [NIST-800-38C]. It is defined on a 128-bit block size 285 block cipher. CCM* modifies this description to allow for modes that 286 require only authentication, as well as variable length 287 authentication tags. 289 2.3.1. AES-CCM* Encrypt 291 We break this section up into 3 subsections, input transformation, 292 authentication transformation, and encryption transformation. We 293 will assume that the following inputs are provided to the routines. 295 Input: 297 a. A 128-bit symmetric key K. 299 b. A value 1 < L < 9. 301 c. A nonce N of 15 - L octets, unique within the usage of the key 302 K. 304 d. An octet string m of length l(m), where 0 <= l(m) < 2^8L. 306 e. An octet string a of length l(a), where 0 <= l(a) < 2^64. 308 2.3.1.1. Input Transformation 310 Input: 312 a. An octet string m of length l(m), where 0 <= l(m) < 2^8L. 314 b. An octet string a of length l(a), where 0 <= l(a) < 2^64. 316 1. Represent the length l(a) as an octet string L(a). 318 a. If l(a) = 0, then L(a) is an empty string. 320 b. If 0 < l(a) < 2^16 - 2^8, then L(a) is the 2-octet 321 representation of l(a). 323 c. If 2^16 - 2^8 <= l(a) < 2^32, then L(a) is the right- 324 concatenation of the octet 0xff, the octet 0xfe, and the 325 4-octet encoding of l(a). 327 d. If 2^32 <= l(a) < 2^64, then L(a) is the right- 328 concatenation of the octet 0xff, the octet 0xff, and the 329 8-octet encoding of l(a). 331 2. Form AddAuthData = L(a)||a||0^t, where 0^t is the smallest non- 332 negative string of t zero octets so that the resulting 333 AddAuthData octet length is a multiple of 16. 335 3. Form PlaintextData = m || 0^s, where 0^s is the smallest non- 336 negative string of s zero octets so that the resulting 337 PlaintextData octet length is a multiple of 16. 339 4. Form AuthData = AddAuthData || PlaintextData. 341 Output: AuthData 343 2.3.1.2. Authentication Transformation 345 Input: 347 a. A 128-bit symmetric key K. 349 b. The octet string AuthData, created in the input 350 transformation. 352 c. A nonce N of 15 - L octets, unique within the usage of the key 353 K. 355 d. The length l(m), where 0 <= l(m) < 2^8L. 357 1. Form the byte Flags = Reserved || Adata || M || L, where the 358 1-bit Reserved field is reserved for future expansions and shall 359 be set to '0'. The 1-bit Adata field is set to '0' if l(a) = 0 360 and set to '1' if l(a) > 0. The M field is the 3-bit 361 representation of the integer (M - 2)/2 if M > 0 and of the 362 integer 0 if M = 0, in most-significant-bit-first order. The L 363 field is the 3-bit representation of the integer L - 1, in most- 364 significant-bit-first order. 366 2. Form B0 = Flags || Nonce N || l(m) 368 3. Parse the message AuthData as B1 || B2 || ... ||Bt, where each 369 message block Bi is a 16-octet string. 371 4. The CBC-MAC value T = AES-CBC-MAC(B_0 || AuthData, K) as defined 372 by Section 2.2. 374 Output: T 376 2.3.1.3. Encryption Transformation 378 Input: 380 a. A 128-bit symmetric key K. 382 b. PlaintextData from Section 2.3.1.1. 384 c. The authentication tag output T from Section 2.3.1.2. 386 d. A nonce N of length 15-L bytes. 388 1. Form Flags = Reserved0 || Reserved1 || 000 || L', where the 389 reserved bits Reserved0 and Reserved1 is '0', and L' is the 3-bit 390 representation of the integer L - 1. 392 2. Form the A_i = Flags || Nonce N || Counter_i, where Counter_i is 393 an L-octet representation of the integer i = 0, 1, 2, ..., t. 395 3. Parse the PlaintextData from Section 2.3.1.1 into 16-octet blocks 396 M_1, ..., M_t. 398 4. Compute C_i = E(A_i, K) XOR M_i for i = 1, ..., t. 400 5. Compute Ciphertext as the leftmost l(m) bits of C_1 || ... || 401 C_t. 403 6. Compute S_0 = E(A_0, K) XOR T. 405 7. Compute AuthTag as the leftmost M octets of S_0. 407 Output: Ciphertext and AuthTag 409 2.3.2. AES-CCM* Decrypt 411 We break this section up into 2 subsections, decryption and 412 authentication verification. The AES-CCM* Decryption process should 413 both decrypt any encrypted portion of the message, and authenticate 414 the decrypted message. It will return an error code, or plaintext 415 data. We will assume that the following inputs are provided to the 416 routines. 418 Input: 420 a. A 128-bit symmetric key K. 422 b. A nonce N of 15 - L octets, unique within the usage of the key 423 K. 425 c. An M-octet tag AuthTag. 427 d. An octet string Ciphertext of length l(c), where 0 <= l(c) - M 428 < 2^8L. 430 2.3.2.1. Decryption Transformation 432 Input: 434 a. A 128-bit symmetric key K. 436 b. A nonce N of 15 - L octets, unique within the usage of the key 437 K. 439 c. An M-octet tag AuthTag. 441 d. An octet string Ciphertext of length l(c), where 0 <= l(c) - M 442 < 2^8L. 444 1. Form C_0 from AuthTag by padding on the right by the least number 445 of 0 octets so that C_0 is an octet string of length 16. 447 2. Form CiphertextData by right concatenation of C with the smallest 448 number of 0 octets so the resulting string is of octet length 449 divisible by 16. 451 3. Form Flags = Reserved0 || Reserved1 || 000 || L', where the 452 reserved bits Reserved0 and Reserved1 are '0', and L' is the 453 3-bit representation of the integer L - 1. 455 4. Form the A_i = Flags || Nonce N || Counter_i, where Counter_i is 456 an L-octet representation of the integer i = 0, 1, 2, ..., t. 458 5. Parse the C_0||CiphertextData into 16-octet blocks C_0, C_1, ..., 459 C_t. 461 6. Compute P_i = E(A_i, K) XOR C_i for i = 0, ..., t. 463 7. Form U as the rightmost M-octets of P_0. 465 8. Form Plaintext leftmost l(c) octets of P_1||...||P_t. 467 Output: U and Plaintext 469 2.3.2.2. Verification Transformation 471 Input: 473 a. A 128-bit symmetric key K. 475 b. Plaintext of length l(c), where 0 <= l(c) < 2^8L. 477 c. U, the purported MAC of Plaintext. 479 d. A nonce N of 15 - L octets, unique within the usage of the key 480 K. 482 1. Compute T as the output of the authentication transformation 483 Section 2.3.1.2 with the inputs, key K, Plaintext, nonce N, and 484 length value l(c). 486 2. Form T' as the leftmost M octets of T. 488 3. If T' = U output Plaintext, otherwise output error code INVALID. 490 Output: Plaintext or INVALID 492 3. Deterministic Random Number Generator 494 This section provides a reduced set of options to the CTR_DRBG 495 definition using AES as defined in [NIST-800-90]. 497 Restrict the CTR_DRBG to the use of AES-128 delivering 128-bit 498 security. 500 General assumption of a full-entropy seed, removing the extra 501 coding needed for the block_cipher_df and the BCC function as 502 defined in [NIST-800-90] 504 The personalization_string and additional_input options are not 505 supported. 507 Set maximum_number_of_bits_per_request = 2^16. (Based on 508 convenient word boundary.) 510 Set reseed_interval = 2^48. (Based on maximizing life of a device 511 that may not have an entropy source.) 513 We give a basic description of the AES block-cipher-based DRBG in the 514 next few subsections. The description includes an update function, 515 an initialization function, and a generate function. We will leave 516 it up to implementers to consider other optional functions such as 517 reseed. 519 We define the state of the CTR_DRBG using the following structure. 521 struct{ 522 uint64 counter; // 64-bit counter 523 uchar V[16]; // state 524 uchar K[16]; // key 525 }ctr_drbg; 527 3.1. CTR_Update 529 The update function CTR_Update() modifies the internal state 530 variables V and K of the DRBG structure using provided data. 532 Input: 534 a. The current state V. 536 b. The current key K. 538 c. A 32-byte input, data. 540 1. temp = AES(V+1 (mod 2^128), K) || AES(V+2 (mod 2^128), K). 542 2. temp = temp XOR data. 544 3. K = leftmost 16 bytes of temp. 546 4. V = rightmost 16 bytes of temp. 548 Output: 550 a. The updated state V. 552 b. The updated key K. 554 Functionally we write (V, K) = CTR_Update(V, K, data). 556 3.2. CTR_Init 558 The update function CTR_Update() modifies the internal state 559 variables V and K of the DRBG structure using provided data. 561 Input: 563 a. A full entropy 32-byte seed. 565 1. Set V = 0^128, K = 0^128, zeroize state V, and K. 567 2. (V, K) = CTR_Update(V, K, seed). 569 3. Set counter = 1. 571 Output: 573 a. State (counter, V, K) 575 Functionally we write (counter V, K) = CTR_Init(seed). 577 NOTE: The CTR_Init() function can be simplified by making the 578 observation that the resulting state is simply an XOR of the seed 579 value with the fixed output values of AES(0^127||1_2, 0^128)|| 580 AES(0^126||10_2, 0^128) = 58E2FCCEFA7E3061367F1D57A4E7455A0388DACE60B 581 6A392F328C2B971B2FE78_{16}, or (K||V) = 582 58E2FCCEFA7E3061367F1D57A4E7455A0388DACE60B6A392F328C2B971B2FE78 XOR 583 seed. 585 3.3. CTR_Generate 587 The function CTR_Generate() modifies the internal state variables V 588 and K of the DRBG structure, and generates a random output of the 589 requested length rlen bytes. If the counter has exceeded 2^48 or 590 rlen exceeds 2^16, an ERROR is returned, and the state is not 591 modified. 593 Input: 595 a. Current state (counter, V, K). 597 b. Requested number of bytes, rlen. 599 1. If counter > 2^48 return ERROR. 601 2. If rlen > 2^16 return ERROR. 603 3. Set output = NULL 605 4. while(length(temp) < rlen) 607 a. V = V + 1 (mod 2^128). 609 b. output ||= AES(V, K). 611 5. output = leftmost rlen bytes of output. 613 6. (V, K) = CTR_Update(V, K, 0^256). 615 7. Set counter = counter + 1. 617 Output: 619 a. State (counter, V, K) 621 b. Either NULL and ERROR, or output and SUCCESS 623 Functionally we write ((counter V, K), (output, RESULT_CODE)) = 624 CTR_Generate(V, K, data). 626 4. Hash 628 [ISO-10118-2] specifies hash functions using an n-bit block cipher. 629 The first function from [ISO-10118-2] ("Hash-function one") maps 630 arbitrary length inputs to n-bit outputs. This is the Matyas-Meyer- 631 Oseas (MMO) construction described in [MOV96]. In the first 632 subsection we specify a family of Merkle-Damgard strengthening (or 633 MD-strengthening) functions that aims to account for existing 634 deployments in ZigBee Smart Energy, and provide a gradual MD- 635 strengthening that reduces padding on small messages. 637 The following subsection details an MMO construction that utilizes 638 two input pre-processing steps. The first is a prefix-free encoding: 639 the bitlength of the message encoded as a 128-bit integer is 640 prepended to the input message. The second is the more common MD- 641 strengthening transform, which essentially appends an encoding of the 642 length and ensures the output is a multiple of the block length. 644 The hash function defined here is a not a general purpose hash 645 function at the 128-bit security level, as it does not provide 646 collision resistance. Application of this hash function should 647 conform to the usages defined in this specification. The use of this 648 hash function elsewhere requires careful consideration. 650 4.1. Prefix-Free Encoding 652 The prefix-free encoding step is defined as follows: 654 Input: message M of bitlength Mlen 656 Output: M' of bitlength Mlen + 128 658 1. If Mlen >= 2^64 return ERROR. 660 2. Convert Mlen to a bit string Mblen of length 128 bits, where 661 the first 64 where Mblen is the 128-bit little-endian integer 662 representation of Mlen. (Note that the leftmost 64 bits will 663 always be zero.) 665 3. Prepend (left-pad) and output Mblen to M, i.e., output M' = 666 Mblen||M. 668 4.2. MD-strengthening 670 This section defines an escalating MD-strengthening padding scheme to 671 account for minimizing additional blocks for small messages, and 672 expanding length encoding for larger messages. Additionally it 673 allows for compliance with existing applications of MMO hashing 674 defined in ZigBee Smart Energy 1.0. For messages less than 2^16 bits 675 we use MD-strengthening-1, for messages of length less than 2^32 bits 676 but greater than 2^16 - 1 bits we use MD-strengthening-2, and for 677 messages of length less than 2^64 bits but greater than 2^32 - 1 bits 678 we use MD-strengthening-3 680 4.2.1. MD-strengthening-1 682 Input: A message M of bitlength Mlen. 684 1. If Mlen >= 2^16 return ERROR. 686 2. Pad the message M: 688 a. Right concatenate the message M with a '1' bit followed by 689 k '0' bits where k is the least non-negative number such that 690 Mlen + 1 + k = 112 mod 128. 692 b. Form the padded message M' by right concatenating the 693 resulting string with a 16-bit string that is equal to the 694 value Mlen. 696 Output: M' = M_1, M_2, ..., M_m a padded message in 128-bit blocks. 698 4.2.2. MD-strengthening-2 700 Input: A message M of bitlength Mlen. 702 1. If Mlen < 2^16 or Mlen >= 2^32 return ERROR. 704 2. Pad the message M: 706 a. Right concatenate the message M with a '1' bit followed by 707 k '0' bits where k is the least non-negative number such that 708 Mlen + 1 + k = 80 mod 128. 710 b. Form the padded message M'' by right concatenating the 711 resulting string with a 32-bit string that is equal the value 712 Mlen. 714 c. Form the padded message M' by right concatenating M'' with 715 a 16-bit 0 string. 717 Output: M' = M_1, M_2, ..., M_m a padded message in 128-bit blocks. 719 4.2.3. MD-strengthening-3 721 Input: A message M of bitlength Mlen. 723 1. If Mlen < 2^32 or Mlen= >= 2^64 return ERROR. 725 2. Pad the message M: 727 a. Right concatenate the message M with a '1' bit followed by 728 k '0' bits where k is the least non-negative number such that 729 Mlen + 1 + k = 16 mod 128. 731 b. Form the padded message M'' by right concatenating the 732 resulting string with a 64-bit string that is equal the value 733 Mlen. 735 c. Form the padded message M' by right concatenating M'' with 736 a 48-bit 0 string. 738 Output: M' = M_1, M_2, ..., M_m a padded message in 128-bit blocks. 740 4.3. MMO Construction 742 We describe the basic MMO construction on a message M that has been 743 padded and MD-strengthened to be of length a multiple of the bit 744 length of AES, 128 bits. 746 Input: A message M of bitlength Mlen. 748 1. Apply the prefix-free encoding to M to form a bitstring M', with 749 bitlength Mlen' = Mlen + 128. 751 2. Pad and format M' in 128-bit blocks using one of the MD routines 752 specified above or return ERROR. 754 3. Set H_0 = 0^128, a zeroized 128-bit block. 756 4. Compute H_j = E(M_j, H_(j-1)) XOR M_j, for j = 1, ..., m. 758 Output: H = H_m as the hash value. 760 5. Key Derivation Function 762 At this time SuiteE does not recommend a particular key derivation 763 function (KDF) for compliance. That said, some of the SuiteE 764 primitives do require use of a KDF. One possible choice are the 765 pseudorandom function-based constructions of KDFs given in 766 [NIST-800-108] which are suitable, and may be instantiated with AES- 767 CMAC as a pseudo-random function. 769 6. Curve Selection 771 We will assume basic familiarity with Elliptic Curve Cryptography 772 (ECC) notation and specifications. Wherever possible we will refer 773 to freely available standards and indicate alignment of these 774 standards with other well known standards. We will assume the 775 notation in the Standards for Efficient Cryptography Group SEC 1, 776 [SEC1]. This specification defines the basic ECC operations as well 777 as the most widely standardized and used techniques. The overall 778 goal of [SEC1] is to provide a free standard that ensures conformance 779 with other standard specifications, and is instructive to 780 implementers on how to develop the necessary routines to build an 781 elliptic curve cryptosystem. 783 Elliptic curve cryptography is a natural public key technology to 784 select given a goal of providing public key operations at a 128-bit 785 security level on embedded systems. ECC, like RSA and other public 786 key cryptosystems provides security by the use of key pairs: a 787 private key and a public key. Security properties are built upon the 788 assumption that the private key is securely generated and maintained 789 within the confines of a cryptographic boundary. Ideally, this means 790 that private keys should be generated on the device in which the 791 private keys will be used operationally. 793 RSA key generation at the 128-bit security level requires the 794 generation 1536-bit prime numbers, and performing integer operations 795 on 3072-bit numbers. The inability of embedded systems to generate 796 these keys on devices today, and the future requirements to implement 797 this in hardware makes RSA a poor choice. 799 ECC key generation at the 128-bit security level requires the 800 generation of a 256-bit random number and scalar point 801 multiplication, which can be done efficiently in embedded systems 802 today. 804 Elliptic curves over binary fields have a distinct advantage over 805 elliptic curves over prime fields in that they are more efficient and 806 cost effective in hardware. The binary curve sect283k1 as specified 807 in [SEC2] is the most widely standardized and specified binary curve 808 at the 128-bit security level. It is a Koblitz curve, which has an 809 advantage over random curves in performing point multiplication 810 algorithms. 812 For a basic description of the algorithms the reader is referred to 813 [SEC1]. For a more complete background and optimizations for 814 elliptic curves the reader is referred to [HMV04]. 816 Throughout the following sections on elliptic curve cryptography we 817 will use the following notation 819 Fq - is a finite field with q elements. 821 E - an elliptic curve over Fq, given by the equation y^2 + xy = x^3 + 822 ax^2 + b. 824 E(Fq) - the group of elliptic curve points over Fq. 826 G - is a base point in E(Fq) of a large prime order. 828 n - is a large prime, and the order of the subgroup generated by G. 830 h - is the cofactor, h = #E(Fq)/n. 832 Further we will assume it is known how to generate elliptic curve key 833 pairs, and will refer the reader to the freely available 834 specification [SEC1]. In general a key pair is generated by taking a 835 random integer d, 1 < d < n, and computing Q = dG, the addition of 836 the point G to itself d times. In general all parties will have some 837 assurances that the elliptic curve domain parameters are valid, and 838 in particular are fixed to the selected sect283k1 curve parameters. 840 6.1. SECT283K1 Curve Parameters 842 Fq - is a finite field with q = 2^283. Fq = F_2[X]/(f(x)), where 843 f(x) = x^283 + x^12 + x^7 + x^5 + 1. 845 E - the elliptic curve is defined as E:y^2 + xy = x^3 + b. 847 G - is a base point in E of a large prime order, presented here in 848 uncompressed octet encoding 04 0503213F 78CA4488 3F1A3B81 62F188E5 849 53CD265F 23C1567A 16876913 B0C2AC24 58492836 01CCDA38 0F1C9E31 850 8D90F95D 07E5426F E87E45C0 E8184698 E4596236 4E341161 77DD2259. 852 n - is a large prime, and the order of the subgroup generated by G, n 853 = 01FFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFE9AE 2ED07577 265DFF7F 854 94451E06 1E163C61. 856 h - is the cofactor, #E(Fq)/n, h = 4. 858 7. Elliptic Curve Signatures with Partial Message Recovery 860 Elliptic Curve Pintsov-Vanstone Signatures (ECPVS) is an elliptic 861 curve variant of Nyberg-Rueppel signatures. ECPVS is standardized in 862 [X9.92.1] and [IEEE1363-A]. It has three distinct advantages over 863 ECDSA when it comes to constrained environments. The first being 864 that it allows for smaller signature sizes by the incorporation of 865 part of the message into a signature field. The second is a 866 simplification of the integer arithmetic. The signing transformation 867 does not require a modular inverse, improving both code size and 868 computational performance. The verification transformation requires 869 no integer arithmetic and so also removes a modular inverse and 870 modular multiplies in the verification transformation. The third is 871 that it is a Schnorr signature scheme which loosens the collision 872 resistance requirement on the underlying hash function [NSW07]. Thus 873 the AES-MMO hash primitive in SuiteE (see Section Section 4)is 874 sufficient for security. A second consequence is a performance 875 increase in the signature verification, where a scalar multiply with 876 a 256-bit integer (ECDSA) is replaced by a 128-bit integer (ECPVS). 878 We assume all parties possess the domain parameters for the elliptic 879 curve, as chosen in Section 6, and that the public keys of signers 880 are validated as described in [SEC1], Section 3.2.2. 882 The scheme presented here is a variant of ECPVS as presented in 883 [X9.92.1], it removes the redundancy requirement on the input message 884 by replacing the use of symmetric key encryption with the 885 authenticated encryption functionality of SuiteE, AES-CCM*. 887 ECPVS uses encoding and decoding routines to process signatures. 889 7.1. Message Encoding and Decoding Methods 891 The following subsections specify the encoding and decoding operation 892 primitives that shall be used to generate ECPVS signatures and to 893 verify ECPVS signatures. 895 7.1.1. Message Encoding 897 Input: The input to the encoding operation is: 899 a. A recoverable message part, which is a bit string M of length 900 Mlen bits. 902 b. A bit string Z (used to derive a key). 904 Steps 905 1. Form T = 00||M, by prepending a zero byte to the front of M. 907 2. Apply the key derivation function KDF to the bit string Z to 908 produce a 128-bit key K. 910 3. Let (C, MAC) = AES-CCM*-ENCRYPT(T, K, 128). 912 4. Form r = C||MAC, the concatenation of the cipher text value C 913 with the computed MAC value. 915 Output: r. 917 We will denote this process as r = EM(M, Z), for encode message. 919 7.1.2. Decoding Messages 921 Input: The input to the decoding operation is: 923 a. The message representative, which is a bit string r of length 924 rlen bits. 926 b. A bit string Z. 928 Steps 930 1. Apply the key derivation function KDF to the bit string Z to 931 produce a 128-bit key K. 933 2. Parse the message r = C||MAC, where MAC is the last 16 bytes, or 934 return ERROR. 936 3. Compute M' = AES-CCM*-DECRYPT(C, MAC, K, 128). 938 4. If M' is ERROR value return ERROR. 940 5. Parse M' = 00||M, where 00 is a zeroized byte, or return ERROR. 942 6. return M. 944 Output: ERROR or message value M. 946 We will denote this process as M = EM^-1(r, Z), for decode message. 948 7.2. Elliptic Curve Pintsov-Vanstone Signatures (ECPVS) 950 This section contains two subsections, signature generation and 951 signature verification. 953 7.2.1. Signature Generation 955 Input: The input to the signature generation transformation is: 957 a. A message (M, V), which is a pair of bit strings to be signed. 958 M is the recoverable portion of the message, and V is the visible 959 or plaintext portion of the message. 961 b. An elliptic curve private key d. 963 Steps: 965 1. Generate an ephemeral key pair (k, R) with R = (x, y). (see: 966 [SEC1] Section 3.2.1). 968 2. Convert the field element x to a bit string Z. (see: [SEC1] 969 Section 2.3.5 and 2.3.2). 971 3. Encode the recoverable portion of the message r = EM(M, Z). 973 4. Compute H = AES-MMO(r||V), where || represents concatenation. 975 5. Convert the bit string H to an integer e. (see: [SEC1] Section 976 2.3.1 and 2.3.8). 978 6. Compute s = k - de (mod n). 980 Output: (r, s) as the signature with partial message recovery on V. 982 7.2.2. Signature Verification 984 Input: The input to verification is: 986 a. A message V. 988 b. A signature with partial message recovery (r, s). 990 c. The elliptic curve public key Q belonging to the signer. 992 Steps: 994 1. If s is not an integer in the interval [1, n - 1], return ERROR. 996 2. Compute H = AES-MMO(r||V). 998 3. Convert the bit string H to an integer e. (see: [SEC1] Section 999 2.3.1 and 2.3.8). 1001 4. Compute the elliptic curve point R = sG + eQ. Let x denote the 1002 x-coordinate of R. 1004 5. Convert the field element x to a bit string Z. (see: [SEC1] 1005 Section 2.3.5 and 2.3.2). 1007 6. Use message decoding to compute: M = EM^-1(r, Z). 1009 7. If M is an ERROR value, return ERROR, else return M and VALID. 1011 Output: Either an ERROR, or a recovered message M and indication of a 1012 VALID signature. 1014 8. Elliptic Curve Implicit Certificates (ECQV) 1016 In this section we specify the Elliptic Curve Qu-Vanstone implicit 1017 certificate scheme (ECQV). 1019 A traditional certificate scheme consists of a certificate issuer 1020 with a key pair (d, Q) to produce a triplet binding an identity, I, 1021 and a public key, P, using a signature, sig, by invoking the issuer's 1022 private key d. We can represent this certificate as (I, P, sig). An 1023 implicit certificate binds an identity element with a public key 1024 without an explicit signature by creating a pair of elements; an 1025 identity, I, and a public key reconstruction value B. We can 1026 represent this certificate as (I, B). 1028 Verification of the certificate is implicit in the use of the public 1029 key. The public key is bound to the entity identified in the 1030 implicit certificate, and the certification process ensures that only 1031 this entity may recover the associated secret key. In effect, 1032 certificate verification is combined with the cryptographic primitive 1033 for which the signed key is being used. This provides two advantages 1034 over traditional certificates. The first is a cost savings on memory 1035 and bandwidth. Implicit certificates do not require an explicit 1036 signature, reducing the size of the cryptographic material to roughly 1037 1/3rd of a traditional certificate. The second is on computation, 1038 the public key reconstruction operation is computationally more 1039 efficient than a signature verification, and may be combined with 1040 other operations. 1042 The next five sections describe an implicit certificate scheme, 1043 defined in [SEC4]. As in the previous section the elliptic curve 1044 domain parameters and hash functions are assumed. It is also assumed 1045 that the CA has established a key pair (dCA, QCA), and all 1046 communicating parties have access to the public key QCA. 1048 We will assume that certificate validation routines have been 1049 established in regards to verifying certificate validity, key usage 1050 and certificate formatting. These checks will be assumed in steps in 1051 which certificate parsing takes place where possible error values may 1052 be returned. 1054 8.1. Certificate Request 1056 This section describes the basic operations by which an entity A 1057 generates a certificate request. It is assumed that A and CA have an 1058 authenticated channel, but the channel may not be private. 1060 Input: none 1061 Steps: 1063 1. Generate an elliptic curve key pair (kA, RA).(see: [SEC1] Section 1064 3.2.1). 1066 Output: a key pair (kA, RA). 1068 The entity A, requesting the certificate, sends the public key RA 1069 along with purported identity of A to the Certificate Authority, and 1070 stores (kA, RA) for future use, keeping kA secret. 1072 8.2. Certificate Generation 1074 This section describes the certificate generation process executed by 1075 a certificate authority. It is assumed that A and CA have an 1076 authenticated channel, but the channel may not be private. 1078 Input: the following items or equivalent 1080 a. The CA private key dCA. 1082 b. A certificate request consisting of a public key RA and an 1083 identifier for A. 1085 Steps: 1087 1. Validate the public key value RA, if it fails output ERROR. (see: 1088 [SEC1] Section 3.2.2). 1090 2. Generate an elliptic curve key pair (k, kG) (see: [SEC1] Section 1091 3.2.1). 1093 3. Compute the elliptic curve point BA = RA + kG. 1095 4. Convert BA to an octet string BAS (see: [SEC1] Section 2.3.3). 1097 5. Encode the certificate CertA as an octet string consisting of 1098 BAS, and the identity element I, consisting of the identifier for 1099 A and other certificate validity and key usage information. 1101 6. Compute H = AES-MMO(CertA). 1103 7. Convert the bit string H to an integer e (see: [SEC1] Section 1104 2.3.1 and 2.3.8). 1106 8. Compute the integer r = ek + dCA (mod n). 1108 Output: Either an implicit certificate CertA, and private key 1109 contribution value r, or an ERROR value. 1111 8.3. Certificate Reception 1113 This section describes the certificate reception process by which a 1114 certificate requester computes its private key. 1116 Input: the following items or equivalent 1118 a. The CA public key QCA. 1120 b. The key pair generated during the certificate request (kA, 1121 RA). 1123 c. The implicit certificate CertA. 1125 d. The private key contribution value r. 1127 Steps: 1129 1. Parse the certificate CertA into an octet string BAS and an 1130 identity element I or return ERROR. 1132 2. Convert BAS to a public key BA or return ERROR (see: [SEC1] 1133 Section 2.3.4). 1135 3. Validate the public key value BA or return ERROR (see: [SEC1] 1136 Section 3.2.2). 1138 4. Compute H = AES-MMO(CertA). 1140 5. Convert the bit string H to an integer e (see: [SEC1] Section 1141 2.3.1 and 2.3.8). 1143 6. Compute the private key dA = r + ekA (mod n). 1145 7. Compute QA = eBA + QCA. 1147 8. Verify QA = (dA)G otherwise halt and return ERROR. 1149 Output: Either a key pair (dA, QA), or an ERROR value. 1151 8.4. Certificate Public Key Extraction 1153 This section describes the certificate public key reconstruction 1154 operation. This would be done by any entity desiring to authenticate 1155 a cryptographic operation with entity A. 1157 Input: the following items or equivalent 1159 a. The CA public key QCA. 1161 b. The implicit certificate CertA. 1163 Steps: 1165 1. Parse the certificate CertA into an octet string BAS and an 1166 identity element I or return ERROR. 1168 2. Convert BAS to a public key BA or return ERROR.(see: [SEC1] 1169 Section 2.3.4). 1171 3. Validate the public key value BA or return ERROR.(see: [SEC1] 1172 Section 3.2.2). 1174 4. Compute H = AES-MMO(CertA). 1176 5. Convert the bit string H to an integer e. (see: [SEC1] Section 1177 2.3.1 and 2.3.8). 1179 6. Compute QA = eBA + QCA. 1181 Output: Either an alleged public key QA, or an ERROR value. 1183 We say the output is "alleged" since the party that extracted it does 1184 not at this point know that it belongs to the party identified in 1185 CertA. However, the scheme does guarantee that only the identified 1186 party possesses the secret key associated to QA. 1188 9. Elliptic Curve Key Agreement Scheme 1190 The elliptic curve MQV, or ECMQV scheme is a key agreement scheme 1191 based on ECC. We give a description here, but will refer to [SEC1] 1192 as the definitive normative reference. ECMQV can provide a variety 1193 of security properties and we refer the reader to [NIST-800-56] to 1194 use an instantiation of ECMQV that best satisfies their application 1195 security goals. We select ECMQV for SuiteE because of its well 1196 studied security properties, wide standardization, existing 1197 deployment in the constrained environment space and the computational 1198 and bandwidth savings it can provide over competing methods to 1199 provide an authenticated key agreement scheme. 1201 As in previous ECC sections we will assume all parties have agreed 1202 upon and access to validated elliptic curve parameters, and for the 1203 purpose of SuiteE this is the sect283k1 curve as defined in [SEC2]. 1205 9.1. ECMQV 1207 This section defines the basic operations of the ECMQV primitive. We 1208 will assume the two communicating parties A and B have established 1209 two key pairs (dA1, QA1) and (dA2, QA2), and (dB1, QB1) and (dB2, 1210 QB2) respectively. The description is presented from A's reference 1211 point, B would perform the same operations with analogous key pairs. 1212 The first of each public key may be a static public key derived from 1213 an implicit certificate and used to authenticate the entity. 1215 Input: The following or equivalent 1217 a. Two key pairs (dA1, QA1) and (dA2, QA2). 1219 b. Two partially validated public keys QB1, QB2 purportedly owned 1220 by B. 1222 c. A key derivation function KDF, and an agreed upon key data 1223 length klength. 1225 d. [Optional] shared information, SHARED_INFO for the KDF. 1227 Steps: 1229 1. Compute an integer QA2bar from QA2: 1231 a. Convert the x-coordinate of QA2 to an integer x. 1233 b. Set xbar = x (mod 2^(ceiling(log_2(n)/2)). (For SuiteE, 1234 xbar = x mod 2^142.) 1235 c. Set QA2bar = xbar + 2^(ceiling(log_2(n)/2). (For SuiteE 1236 QA2bar = xbar + 2^142.) 1238 2. Compute the integer s = dA2 + QA2bar*dA2 (mod n) 1240 3. Compute an integer QB2bar from QB2: 1242 a. Convert the x-coordinate of QB2 to an integer x'. 1244 b. Set xbar' = x' (mod 2^(ceiling(log_2(n)/2)). (For SuiteE, 1245 xbar' = x' mod 2^142.) 1247 c. Set QB2bar = xbar' + 2^(ceiling(log_2(n)/2). (For SuiteE 1248 QB2bar = xbar' + 2^142.) 1250 4. Compute the point P = h*s(QB2 + QB2bar*QB1), where h is the 1251 cofactor defined as #E(Fq)/n, which is 4 for the SuiteE curve 1252 sect283k1. 1254 5. If P = point at infinity output ERROR and exit. 1256 6. Convert the x-coordinate of P to an octet string Z. 1258 7. Use the KDF function with input Z, klength, and the optional 1259 SHARED_INFO, to generate either the shared key value K or return 1260 an ERROR. 1262 Output: Shared secret key K of klength, or an ERROR value. 1264 10. References 1266 10.1. Normative References 1268 [FIPS-180-3] 1269 National Institute of Standards and Technology, "Secure 1270 Hash Standard", FIPS 180-3, October 2008, . 1274 [FIPS-197] 1275 National Institute of Standards and Technology, "Advanced 1276 Encryption Standard", FIPS 197, November 2001, . 1279 [IEEE-802.15.4-2003] 1280 IEEE Computer Society, "IEEE Standard for Information 1281 technology -- Part 15.4: Wireless Medium Access Control 1282 (MAC) and Physical Layer (PHY) Specifications for Low-Rate 1283 Wireless Personal Area Networks (LR-WPANs)", IEEE Standard 1284 for Information technology 802.15.4, October 2003. 1286 [ISO-10118-2] 1287 International Organization for Standards and the 1288 International Electrotechnical Commission, "ISO/IEC 1289 10118-2, Information technology - Security techniques - 1290 Hash functions - Part 2: Hash-functions using an n-bit 1291 block cipher", Information technology - Security 1292 techniques 10118-2, December 2000. 1294 [NIST-800-108] 1295 National Institute of Standards and Technology, "NIST SP 1296 800-108, Recommendation for Key Derivation Using 1297 Pseudorandom Functions", NIST Special Publication 800-108, 1298 October 2009, . 1301 [NIST-800-38C] 1302 National Institute of Standards and Technology, "NIST SP 1303 800-38C, Recommendation for Block Cipher Modes of 1304 Operation: The CCM Mode for Authentication and 1305 Confidentiality", NIST Special Publication 800-38C, 1306 July 2007, . 1309 [NIST-800-56] 1310 National Institute of Standards and Technology, 1311 "Recommendation for Pair-wise Key Establishment Schemes 1312 Using Discrete Logarithm Cryptography (Revised)", NIST 1313 Special Publication 800-56a, March 2007, . 1317 [NIST-800-57] 1318 National Institute of Standards and Technology, 1319 "Recommendation for Key Management - Part 1: General 1320 (Revised)", NIST Special Publication 800-57, March 2007, < 1321 http://csrc.nist.gov/publications/nistpubs/800-57/ 1322 sp800-57-Part1-revised2_Mar08-2007.pdf>. 1324 [NIST-800-90] 1325 National Institute of Standards and Technology, "NIST SP 1326 800-90, Recommendation for Random Number Generation Using 1327 Deterministic Random Bit Generators(Revised)", NIST 1328 Special Publication 800-90, March 2007, . 1332 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1333 Hashing for Message Authentication", RFC 2104, 1334 February 1997. 1336 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1337 Requirement Levels", BCP 14, RFC 2119, March 1997. 1339 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 1340 CBC-MAC (CCM)", RFC 3610, September 2003. 1342 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 1343 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 1344 RFC 3766, April 2004. 1346 [SEC1] Standards for Efficient Cryptography Group, "SEC1: 1347 Elliptic Curve Cryptography", SEC 1, May 2009, 1348 . 1350 [SEC2] Standards for Efficient Cryptography Group, "SEC2: 1351 Recommended Elliptic Curve Domain Parameters", SEC 2, 1352 September 2010, 1353 . 1355 [SEC4] Standards for Efficient Cryptography Group, "Elliptic 1356 Curve Qu-Vanstone Implicit Certificate Scheme (ECQV), 1357 v0.97", SEC 4, March 2011, 1358 . 1360 [X9.92.1] Accredited Standards Committee X9, Inc., "Public Key 1361 Cryptography for the Financial Services Industry - Digital 1362 Signature Algorithms Giving Partial Message Recovery - 1363 Part 1: Elliptic Curve Pintsov-Vanstone Signatures 1364 (ECPVS)", X9 92-1, 2009, . 1367 [ZigBee] ZigBee Standards Organization, "ZigBee Specification, 1368 revision 17", October 2007, . 1372 Registration required. 1374 10.2. Informative References 1376 [HMV04] Hankerson, D., Menezes, A., and S. Vanstone, "Guide to 1377 Elliptic Curve Cryptography", 2004. 1379 Springer, ISBN 038795273X. 1381 [IEEE1363] 1382 Institute of Electrical and Electronics Engineers, 1383 "Standard Specifications for Public Key Cryptography", 1384 IEEE 1363, 2000. 1386 [IEEE1363-A] 1387 Institute of Electrical and Electronics Engineers, 1388 "Standard Specifications for Public Key Cryptography - 1389 Amendment 1: Additional Techniques", IEEE 1363a, 2004. 1391 [LMQSV98] Law, L., Menezes, A., Qu, M., Solinas, J., and S. 1392 Vanstone, "An Efficient Protocol for Authenticated Key 1393 Agreement", University of Waterloo Technical Report 1394 CORR 98-05, August 1998, . 1398 [MOV96] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook 1399 of Applied Cryptography", 1996, 1400 . 1402 CRC Press, ISBN 0-8493-8523-7. Available online. 1404 [NIST57] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, 1405 "Recommendation for Key Management - Part 1: General 1406 (revised)", March 2007, . 1410 NIST Special Publication 800-57 1412 [NSW07] Neven, G., Smart, N., and B. Warinschi, "Hash function 1413 requirements for Schnorr signatures", Journal of 1414 Mathematical Cryptology Volume 3 Number 1, May 2009. 1416 [X9.123] Accredited Standards Committee X9, Inc., "Elliptic Curve 1417 Qu-Vanstone Implicit Certificates (Draft)", X9 123, 2011. 1419 [ZigBeeSE] 1420 ZigBee Standards Organization, "ZigBee Smart Energy 1421 Profile Specification, revision 15", December 2008, . 1426 Registration required. 1428 Appendix A. Acknowledgments 1429 Author's Address 1431 Matthew Campagna 1432 Certicom Corp. 1433 4701 Tahoe Boulevard 1434 Mississauga, Ontario L4W 0B5 1435 Canada 1437 Email: mcampagna@certicom.com