idnits 2.17.1 draft-songlee-aes-cmac-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1060. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1037. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1044. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1050. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** There are 6 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 32 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 243 has weird spacing: '...onst_Rb is 0...' == Line 332 has weird spacing: '...onst_Rb is 0...' == Line 340 has weird spacing: '... flag for ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '256' on line 606 -- Looks like a reference, but probably isn't: '16' on line 989 -- Looks like a reference, but probably isn't: '4' on line 838 -- Looks like a reference, but probably isn't: '12' on line 978 -- Looks like a reference, but probably isn't: '0' on line 911 -- Looks like a reference, but probably isn't: '13' on line 745 -- Looks like a reference, but probably isn't: '1' on line 801 -- Looks like a reference, but probably isn't: '14' on line 746 -- Looks like a reference, but probably isn't: '2' on line 802 -- Looks like a reference, but probably isn't: '15' on line 747 -- Looks like a reference, but probably isn't: '3' on line 803 -- Looks like a reference, but probably isn't: '8' on line 839 -- Looks like a reference, but probably isn't: '5' on line 737 -- Looks like a reference, but probably isn't: '10' on line 742 -- Looks like a reference, but probably isn't: '9' on line 741 -- Looks like a reference, but probably isn't: '6' on line 746 -- Looks like a reference, but probably isn't: '7' on line 743 -- Looks like a reference, but probably isn't: '11' on line 747 -- Looks like a reference, but probably isn't: '64' on line 979 == Unused Reference: 'OMAC1' is defined on line 548, but no explicit reference was found in the text == Unused Reference: 'XCBC' is defined on line 552, but no explicit reference was found in the text == Unused Reference: 'RFC1750' is defined on line 589, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-CMAC' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'OMAC1' -- Possible downref: Non-RFC (?) normative reference: ref. 'XCBC' -- Possible downref: Non-RFC (?) normative reference: ref. 'OMAC1a' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'RFC-HMAC') -- Possible downref: Non-RFC (?) normative reference: ref. 'OMAC1b' -- Possible downref: Non-RFC (?) normative reference: ref. 'XCBCa' -- Possible downref: Non-RFC (?) normative reference: ref. 'XCBCb' ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 35 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 JunHyuk Song 2 Radha Poovendran 3 University of Washington 4 Jicheol Lee 5 Samsung Electronics 6 Tetsu Iwata 7 INTERNET DRAFT Ibaraki University 8 Expires: June 8, 2006 December 9 2005 10 The AES-CMAC Algorithm 11 draft-songlee-aes-cmac-03.txt 13 Status of This Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 National Institute of Standards and Technology (NIST) has newly 43 specified the Cipher-based Message Authentication Code (CMAC) 44 which is equivalent to the One-Key CBC MAC1 (OMAC1) submitted by 45 Iwata and Kurosawa. This memo specifies the authentication algorithm 46 based on CMAC with 128-bit Advanced Encryption Standard (AES). 47 This new authentication algorithm is named AES-CMAC. 48 The purpose of this document is to make the AES-CMAC algorithm 49 conveniently available to the Internet Community. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Specification of AES-CMAC . . . . . . . . . . . . . . . . 3 55 2.1 Basic definitions . . . . . . . . . . . . . . . . . . . . 3 56 2.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.3 Subkey Generation Algorithm . . . . . . . . . . . . . . . 5 58 2.4 MAC Generation Algorithm . . . . . . . . . . . . . . . . . 7 59 2.5 MAC Verification Algorithm . . . . . . . . . . . . . . . . 9 60 3. Security Considerations . . . . . . . . . . . . . . . . . . 10 61 4. Test Vector . . . . . . . . . . . . . . . . . . . . . . . . 11 62 5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . 11 63 6. Authors address . . . . . . . . . . . . . . . . . . . . . . 12 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . 13 65 Appendix A. Test Code . . . . . . . . . . . . . . . . . . . . 14 67 1. Introduction 69 National Institute of Standards and Technology (NIST) has newly 70 specified the Cipher-based Message Authentication Code (CMAC). 71 CMAC [NIST-CMAC] is a keyed hash function that is based on a 72 symmetric key block cipher such as the Advanced Encryption 73 Standard [NIST-AES]. CMAC is equivalent to the One-Key CBC MAC1 74 (OMAC1) submitted by Iwata and Kurosawa [OMAC1a, OMAC1b]. OMAC1 75 is an improvement of the eXtended Cipher Block Chaining mode (XCBC) 76 submitted by Black and Rogaway [XCBCa, XCBCb], which itself is an 77 improvement of the basic CBC-MAC. XCBC efficiently addresses the 78 security deficiencies of CBC-MAC, and OMAC1 efficiently reduces the 79 key size of XCBC. 81 AES-CMAC provides stronger assurance of data integrity than a 82 checksum or an error detecting code. The verification of a checksum 83 or an error detecting code detects only accidental modifications of 84 the data, while CMAC is designed to detect intentional, unauthorized 85 modifications of the data, as well as accidental modifications. 87 AES-CMAC achieves the similar security goal of HMAC [RFC-HMAC]. 88 Since AES-CMAC is based on a symmetric key block cipher, AES, 89 while HMAC is based on a hash function, such as SHA-1, AES-CMAC 90 is appropriate for information systems in which AES is more readily 91 available than a hash function. 93 This memo specifies the authentication algorithm based on CMAC with 94 AES-128. This new authentication algorithm is named AES-CMAC. 96 2. Specification of AES-CMAC 98 2.1 Basic definitions 100 The following table describes the basic definitions necessary to 101 explain the specification of AES-CMAC. 103 x || y Concatenation. 104 x || y is the string x concatenated with string y. 105 0000 || 1111 is 00001111. 107 x XOR y Exclusive-OR operation. 108 For two equal length strings x and y, 109 x XOR y is their bit-wise exclusive-OR. 111 ceil(x) Ceiling function. 112 The smallest integer no smaller than x. 113 ceil(3.5) is 4. ceil(5) is 5. 115 x << 1 Left-shift of the string x by 1 bit. 116 The most significant bit disappears and a zero 117 comes into the least significant bit. 118 10010001 << 1 is 00100010. 120 0^n The string that consists of n zero-bits. 121 0^3 means that 000 in binary format. 122 10^4 means that 10000 in binary format. 123 10^i means that 1 followed by i-times repeated 124 zero's. 126 MSB(x) The most-significant bit of the string x. 127 MSB(10010000) means 1. 129 padding(x) 10^i padded output of input x. 130 It is described in detail in section 2.4. 132 Key 128 bits (16 bytes) long key for AES-128. 133 Denoted by K. 135 First subkey 128 bits (16 bytes) long first subkey, 136 derived through the subkey 137 generation algorithm from the key K. 138 Denoted by K1. 140 Second subkey 128 bits (16 bytes) long second subkey, 141 derived through the subkey 142 generation algorithm from the key K. 143 Denoted by K2. 145 Message A message to be authenticated. 146 Denoted by M. 147 The message can be null, which means that the length 148 of M is 0. 150 Message length The length of the message M in bytes. 151 Denoted by len. 152 Minimum value of the length can be 0. The maximum 153 value of the length is not specified in this document. 155 AES-128(K,M) AES-128(K,M) is the 128-bit ciphertext of AES-128 156 for a 128-bit key K and a 128-bit message M. 158 MAC A 128-bit string which is the output of AES-CMAC. 159 Denoted by T. 160 Validating the MAC provides assurance of the 161 integrity and authenticity over the message from 162 the source. 164 MAC length By default, the length of the output of AES-CMAC is 165 128 bits. It is possible to truncate the MAC. 166 Result of truncation should be taken in most 167 significant bits first order. MAC length must be 168 specified before the communication starts, and 169 it must not be changed during the life time of the key. 171 2.2 Overview 173 AES-CMAC uses the Advanced Encryption Standard [NIST-AES] as a 174 building block. To generate a MAC, AES-CMAC takes a secret key, 175 a message of variable length and the length of the message in bytes 176 as inputs, and returns a fixed bit string called a MAC. 178 The core of AES-CMAC is the basic CBC-MAC. For a message M to be 179 authenticated, the CBC-MAC is applied to M. There are two cases of 180 operation in CMAC. Figure 2.1 illustrated the operation of CBC-MAC 181 with two cases. If the size of input message block is equal to 182 multiple of block size namely 128 bits, the last block processing 183 shall be exclusive-OR'ed with K1. Otherwise, the last block shall 184 be padded with 10^i (notation is described in section 2.1) and 185 exclusive-OR'ed with K2. The result of the previous process will be 186 the input of the last CBC operation. The output of AES-CMAC provides 187 data integrity over whole input message. 189 +-----+ +-----+ +-----+ +-----+ +-----+ +---+----+ 190 | M_1 | | M_2 | | M_n | | M_1 | | M_2 | |M_n|10^i| 191 +-----+ +-----+ +-----+ +-----+ +-----+ +---+----+ 192 | | | +--+ | | | +--+ 193 | +--->(+) +--->(+)<-|K1| | +--->(+) +--->(+)<-|K2| 194 | | | | | +--+ | | | | | +--+ 195 +-----+ | +-----+ | +-----+ +-----+ | +-----+ | +-----+ 196 |AES_K| | |AES_K| | |AES_K| |AES_K| | |AES_K| | |AES_K| 197 +-----+ | +-----+ | +-----+ +-----+ | +-----+ | +-----+ 198 | | | | | | | | | | 199 +-----+ +-----+ | +-----+ +-----+ | 200 | | 201 +-----+ +-----+ 202 | T | | T | 203 +-----+ +-----+ 205 (a) positive multiple block length (b) otherwise 207 Figure 2.1 Illustration of two cases of AES-CMAC. 209 AES_K is AES-128 with key K. 210 The message M is divided into blocks M_1,...,M_n, 211 where M_i is the i-th message block. 212 The length of M_i is 128 bits for i = 1,...,n-1, and 213 the length of the last block M_n is less than or equal to 128 bits. 214 K1 is the subkey for the case (a), and 215 K2 is the subkey for the case (b). 216 K1 and K2 are generated by the subkey generation algorithm 217 described in section 2.3. 219 2.3 Subkey Generation Algorithm 221 The subkey generation algorithm, Generate_Subkey(), takes a secret 222 key, K, which is just the key for AES-128. 224 The output of the subkey generation algorithm is two subkeys, K1 225 and K2. We write (K1,K2) := Generate_Subkey(K). 227 Subkeys K1 and K2 are used in both MAC generation and MAC 228 verification algorithms. K1 is used for the case where the length 229 of the last block is equal to the block length. K2 is used for the 230 case where the length of the last block is less than the block 231 length. 233 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 234 + Algorithm Generate_Subkey + 235 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 236 + + 237 + Input : K (128-bit key) + 238 + Output : K1 (128-bit first subkey) + 239 + K2 (128-bit second subkey) + 240 +-------------------------------------------------------------------+ 241 + + 242 + Constants: const_Zero is 0x00000000000000000000000000000000 + 243 + const_Rb is 0x00000000000000000000000000000087 + 244 + Variables: L for output of AES-128 applied to 0^128 + 245 + + 246 + Step 1. L := AES-128(K, const_Zero); + 247 + Step 2. if MSB(L) is equal to 0 + 248 + then K1 := L << 1; + 249 + else K1 := (L << 1) XOR const_Rb; + 250 + Step 3. if MSB(K1) is equal to 0 + 251 + then K2 := K1 << 1; + 252 + else K2 := (K1 << 1) XOR const_Rb; + 253 + Step 4. return K1, K2; + 254 + + 255 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 257 Figure 2.2 Algorithm Generate_Subkey 259 Figure 2.2 specifies the subkey generation algorithm. 260 In step 1, AES-128 is applied to all zero bits with the input 261 key K. 263 In step 2, K1 is derived through the following operation: 264 If the most significant bit of L is equal to 0, K1 is 265 the left-shift of L by 1-bit. 266 Otherwise, K1 is the exclusive-OR of const_Rb and 267 the left-shift of L by 1-bit. 269 In step 3, K2 is derived through the following operation: 270 If the most significant bit of K1 is equal to 0, K2 is 271 the left-shift of K1 by 1-bit. 272 Otherwise, K2 is the exclusive-OR of const_Rb and 273 the left-shift of K1 by 1-bit. 275 In step 4, (K1,K2) := Generate_Subkey(K) is returned. 277 The mathematical meaning of procedure in step 2 and step 3 278 including const_Rb can be found in [OMAC1a]. 280 2.4 MAC Generation Algorithm 282 The MAC generation algorithm, AES-CMAC(), takes three inputs, 283 a secret key, a message, and the length of the message in bytes. 284 The secret key, denoted by K, is just the key for AES-128. 285 The message and its length in bytes are denoted by M and len, 286 respectively. The message M is denoted by the sequence of M_i 287 where M_i is the i-th message block. That is, if M consists of 288 n blocks, then M is written as 290 - M = M_1 || M_2 || ... || M_{n-1} || M_n 292 The length of M_i is 128 bits for i = 1,...,n-1, and the length of 293 the last block M_n is less than or equal to 128 bits. 295 The output of the MAC generation algorithm is a 128-bit string, 296 called a MAC, which can be used to validate the input message. 297 The MAC is denoted by T and we write T := AES-CMAC(K,M,len). 298 Validating the MAC provides assurance of the integrity and 299 authenticity over the message from the source. 301 It is possible to truncate the MAC. According to [NIST-CMAC] at 302 least 64-bit MAC should be used for against guessing attack. 303 Result of truncation should be taken in most significant bits first 304 order. 306 The block length of AES-128 is 128 bits (16 bytes). There is a 307 special treatment in case that the length of the message is 308 not a positive multiple of the block length. The special treatment 309 is to pad 10^i bit-string for adjusting the length of the last 310 block up to the block length. 312 For the input string x of r-bytes, where r < 16, the padding 313 function, padding(x), is defined as follows. 315 - padding(x) = x || 10^i where i is 128-8*r-1 317 That is, padding(x) is the concatenation of x and a single '1' 318 followed by the minimum number of '0's so that the total length is 319 equal to 128 bits. 321 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 322 + Algorithm AES-CMAC + 323 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 324 + + 325 + Input : K ( 128-bit key ) + 326 + : M ( message to be authenticated ) + 327 + : len ( length of the message in bytes ) + 328 + Output : T ( message authenticated code ) + 329 + + 330 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 331 + Constants: const_Zero is 0x00000000000000000000000000000000 + 332 + const_Rb is 0x00000000000000000000000000000087 + 333 + const_Bsize is 16 + 334 + + 335 + Variables: K1, K2 for 128-bit subkeys + 336 + M_i is the i-th block (i=1..ceil(len/const_Bsize)) + 337 + M_last is the last block xor-ed with K1 or K2 + 338 + n for number of blocks to be processed + 339 + r for number of bytes of last block + 340 + flag for denoting if last block is complete or not + 341 + + 342 + Step 1. (K1,K2) := Generate_Subkey(K); + 343 + Step 2. n := ceil(len/const_Bsize); + 344 + Step 3. if n = 0 + 345 + then + 346 + n := 1; + 347 + flag := false; + 348 + else + 349 + if len mod const_Bsize is 0 + 350 + then flag := true; + 351 + else flag := false; + 352 + + 353 + Step 4. if flag is true + 354 + then M_last := M_n XOR K1; + 355 + else M_last := padding(M_n) XOR K2; + 356 + Step 5. X := const_Zero; + 357 + Step 6. for i := 1 to n-1 do + 358 + begin + 359 + Y := X XOR M_i; + 360 + X := AES-128(K,Y); + 361 + end + 362 + Y := M_last XOR X; + 363 + T := AES-128(K,Y); + 364 + Step 7. return T; + 365 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 366 Figure 2.3 Algorithm AES-CMAC 368 Figure 2.3 describes the MAC generation algorithm. 370 In step 1, subkeys K1 and K2 are derived from K through the subkey 371 generation algorithm. 373 In step 2, the number of blocks, n, is calculated. The number of 374 blocks is the smallest integer value greater than or equal to 375 quotient by dividing length parameter by the block length, 16 376 bytes. 378 In step 3, the length of the input message is checked. 379 If the input length is less than 128 bits (including null), the 380 number of blocks to be processed shall be 1 and mark the flag as 381 not-complete-block (false). Otherwise, if the last block length 382 is 128 bits, mark the flag as complete-block (true), else mark the 383 flag as not-complete-block (false). 385 In step 4, M_last is calculated by exclusive-OR'ing 386 M_n and previously calculated subkeys. If the last block is a 387 complete block (true), then M_last is the exclusive-OR of M_n and 388 K1. Otherwise, M_last is the exclusive-OR of padding(M_n) and K2. 390 In step 5, the variable X is initialized. 392 In step 6, the basic CBC-MAC is applied to M_1,...,M_{n-1},M_last. 394 In step 7, the 128-bit MAC, T := AES-CMAC(K,M,len), is returned. 396 If necessary, truncation of the MAC is done before returning the 397 MAC. 399 2.5 MAC Verification Algorithm 401 The verification of the MAC is simply done by a MAC recomputation. 402 We use the MAC generation algorithm which is described in section 403 2.4. 405 The MAC verification algorithm, Verify_MAC(), takes four inputs, 406 a secret key, a message, the length of the message in bytes, and 407 the received MAC. 408 They are denoted by K, M, len, and T' respectively. 410 The output of the MAC verification algorithm is either INVALID or 411 VALID. 413 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 414 + Algorithm Verify_MAC + 415 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 416 + + 417 + Input : K ( 128-bit Key ) + 418 + : M ( message to be verified ) + 419 + : len ( length of the message in bytes ) + 420 + : T' ( the received MAC to be verified ) + 421 + Output : INVALID or VALID + 422 + + 423 +-------------------------------------------------------------------+ 424 + + 425 + Step 1. T* := AES-CMAC(K,M,len); + 426 + Step 2. if T* = T' + 427 + then + 428 + return VALID; + 429 + else + 430 + return INVALID; + 431 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 432 Figure 2.4 Algorithm Verify_MAC 434 Figure 2.4 describes the MAC verification algorithm. 436 In step 1, T* is derived from K, M and len through the MAC generation 437 algorithm. 439 In step 2, T* and T' are compared. If T*=T', then return VALID, 440 otherwise return INVALID. 442 If the output is INVALID, then the message is definitely not 443 authentic, i.e., it did not originate from a source that executed 444 the generation process on the message to produce the purported MAC. 446 If the output is VALID, then the design of the AES-CMAC provides 447 assurance that the message is authentic and, hence, was not 448 corrupted in transit; however, this assurance, as for any MAC 449 algorithm, is not absolute. 451 3. Security Considerations 453 The security provided by AES-CMAC are built on strong cryptographic 454 algorithm AES. However as is true with any cryptographic algorithm, 455 part of its strength lies in the secret key, 'K' and the correctness 456 of the implementation in all of the participating systems. 457 If the secret key 'K' is compromised or inappropriately shared, it 458 no longer guarantee either authentication or integrity of message. 459 The secret key shall be generated in a way that meet the pseudo 460 randomness requirement of RFC 4086 [RFC4086] and should be kept 461 in safe. If and only if AES-CMAC used properly it can provide the 462 Authentication and Integrity that meet the best current practice 463 of message authentication. 465 4. Test Vectors 467 Following test vectors are the same as those of [NIST-CMAC]. 468 The following vectors are also output of the test program in 469 appendix A. 471 -------------------------------------------------- 472 Subkey Generation 473 K 2b7e1516 28aed2a6 abf71588 09cf4f3c 474 AES-128(key,0) 7df76b0c 1ab899b3 3e42f047 b91b546f 475 K1 fbeed618 35713366 7c85e08f 7236a8de 476 K2 f7ddac30 6ae266cc f90bc11e e46d513b 477 -------------------------------------------------- 479 -------------------------------------------------- 480 Example 1: len = 0 481 M 482 AES-CMAC bb1d6929 e9593728 7fa37d12 9b756746 483 -------------------------------------------------- 485 Example 2: len = 16 486 M 6bc1bee2 2e409f96 e93d7e11 7393172a 487 AES-CMAC 070a16b4 6b4d4144 f79bdd9d d04a287c 488 -------------------------------------------------- 490 Example 3: len = 40 491 M 6bc1bee2 2e409f96 e93d7e11 7393172a 492 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 493 30c81c46 a35ce411 494 AES-CMAC dfa66747 de9ae630 30ca3261 1497c827 495 -------------------------------------------------- 497 Example 4: len = 64 498 M 6bc1bee2 2e409f96 e93d7e11 7393172a 499 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 500 30c81c46 a35ce411 e5fbc119 1a0a52ef 501 f69f2445 df4f9b17 ad2b417b e66c3710 502 AES-CMAC 51f0bebf 7e3b9d92 fc497417 79363cfe 503 -------------------------------------------------- 505 5. Acknowledgement 507 Portions of this text here in is borrowed from [NIST-CMAC]. 508 We appreciate OMAC1 authors and SP 800-38B author, and Russ Housley 509 for his useful comments and guidance that have been incorporated 510 herein. We also appreciate David Johnston for providing code of 511 the AES block cipher. 513 6. Author's Address 515 Junhyuk Song 516 University of Washington 517 Samsung Electronics 518 (206) 853-5843 519 songlee@ee.washington.edu 520 junhyuk.song@samsung.com 522 Jicheol Lee 523 Samsung Electronics 524 +82-31-279-3605 525 jicheol.lee@samsung.com 527 Radha Poovendran 528 Network Security Lab 529 University of Washington 530 (206) 221-6512 531 radha@ee.washington.edu 533 Tetsu Iwata 534 Ibaraki University 535 iwata@cis.ibaraki.ac.jp 537 7. References 539 7.1. Normative References 540 [NIST-CMAC] NIST, Special Publication 800-38B Draft,"Recommendation 541 for Block Cipher Modes of Operation: The CMAC Method 542 for Authentication," March 9, 2005 544 [NIST-AES] NIST, FIPS 197, "Advanced Encryption Standard (AES)," 545 November 2001. 546 http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf 548 [OMAC1] "OMAC: One-Key CBC MAC," Tetsu Iwata and Kaoru Kurosawa, 549 Department of Computer and Information Sciences, 550 Ilbaraki University, March 10, 2003. 552 [XCBC] Black, J. and P. Rogaway, "A Suggestion for Handling 553 Arbitrary-Length Messages with the CBC MAC," NIST 554 Second Modes of Operation Workshop, August 2001. 555 http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ 556 xcbc-mac/xcbc-mac-spec.pdf 558 [RFC4086] Eastlake 3rd, D., Crocker, S., and J. Schiller, 559 "Randomness Requirements for Security", RFC 4086 560 June 2005 561 7.2. Informative References 563 [OMAC1a] Tetsu Iwata and Kaoru Kurosawa, "OMAC: One-Key CBC MAC," 564 Fast Software Encryption, FSE 2003, LNCS 2887, 565 pp. 129-153, Springer-Verlag, 2003. 567 [RFC-HMAC] Hugo Krawczyk, Mihir Bellare and Ran Canetti, 568 "HMAC: Keyed-Hashing for Message Authentication," 569 RFC2104, February 1997. 571 [OMAC1b] Tetsu Iwata and Kaoru Kurosawa, "OMAC: One-Key CBC MAC," 572 Submission to NIST, December 2002. 573 Available from the NIST modes of operation web site at 574 http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ 575 omac/omac-spec.pdf 577 [XCBCa] John Black and Phillip Rogaway, "A Suggestion for 578 Handling Arbitrary-Length Messages with the CBC MAC," 579 NIST Second Modes of Operation Workshop, August 2001. 580 Available from the NIST modes of operation web site at 581 http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ 582 xcbc-mac/xcbc-mac-spec.pdf 584 [XCBCb] John Black and Phillip Rogaway, "CBC MACs for 585 Arbitrary-Length Messages: The Three-Key 586 Constructions," Journal of Cryptology, Vol. 18, No. 2, 587 pp. 111-132, Springer-Verlag, Spring 2005. 589 [RFC1750] Eastlake 3rd, D., Crocker, S., and J. Schiller, 590 "Randomness Recommendations for Security", RFC 1750, 591 December 1994. 593 Appendix A. Test Code 595 /****************************************************************/ 596 /* AES-CMAC with AES-128 bit */ 597 /* AES-128 from David Johnston (802.16) */ 598 /* CMAC Algorithm described in SP800-38B draft */ 599 /* Author: Junhyuk Song (junhyuk.song@samsung.com) */ 600 /* Jicheol Lee (jicheol.lee@samsung.com) */ 601 /****************************************************************/ 603 #include 605 /******** SBOX Table *********/ 606 unsigned char sbox_table[256] = { 607 0x63, 0x7c, 0x77, 0x7b, 0xf2, 0x6b, 0x6f, 0xc5, 608 0x30, 0x01, 0x67, 0x2b, 0xfe, 0xd7, 0xab, 0x76, 609 0xca, 0x82, 0xc9, 0x7d, 0xfa, 0x59, 0x47, 0xf0, 610 0xad, 0xd4, 0xa2, 0xaf, 0x9c, 0xa4, 0x72, 0xc0, 611 0xb7, 0xfd, 0x93, 0x26, 0x36, 0x3f, 0xf7, 0xcc, 612 0x34, 0xa5, 0xe5, 0xf1, 0x71, 0xd8, 0x31, 0x15, 613 0x04, 0xc7, 0x23, 0xc3, 0x18, 0x96, 0x05, 0x9a, 614 0x07, 0x12, 0x80, 0xe2, 0xeb, 0x27, 0xb2, 0x75, 615 0x09, 0x83, 0x2c, 0x1a, 0x1b, 0x6e, 0x5a, 0xa0, 616 0x52, 0x3b, 0xd6, 0xb3, 0x29, 0xe3, 0x2f, 0x84, 617 0x53, 0xd1, 0x00, 0xed, 0x20, 0xfc, 0xb1, 0x5b, 618 0x6a, 0xcb, 0xbe, 0x39, 0x4a, 0x4c, 0x58, 0xcf, 619 0xd0, 0xef, 0xaa, 0xfb, 0x43, 0x4d, 0x33, 0x85, 620 0x45, 0xf9, 0x02, 0x7f, 0x50, 0x3c, 0x9f, 0xa8, 621 0x51, 0xa3, 0x40, 0x8f, 0x92, 0x9d, 0x38, 0xf5, 622 0xbc, 0xb6, 0xda, 0x21, 0x10, 0xff, 0xf3, 0xd2, 623 0xcd, 0x0c, 0x13, 0xec, 0x5f, 0x97, 0x44, 0x17, 624 0xc4, 0xa7, 0x7e, 0x3d, 0x64, 0x5d, 0x19, 0x73, 625 0x60, 0x81, 0x4f, 0xdc, 0x22, 0x2a, 0x90, 0x88, 626 0x46, 0xee, 0xb8, 0x14, 0xde, 0x5e, 0x0b, 0xdb, 627 0xe0, 0x32, 0x3a, 0x0a, 0x49, 0x06, 0x24, 0x5c, 628 0xc2, 0xd3, 0xac, 0x62, 0x91, 0x95, 0xe4, 0x79, 629 0xe7, 0xc8, 0x37, 0x6d, 0x8d, 0xd5, 0x4e, 0xa9, 630 0x6c, 0x56, 0xf4, 0xea, 0x65, 0x7a, 0xae, 0x08, 631 0xba, 0x78, 0x25, 0x2e, 0x1c, 0xa6, 0xb4, 0xc6, 632 0xe8, 0xdd, 0x74, 0x1f, 0x4b, 0xbd, 0x8b, 0x8a, 633 0x70, 0x3e, 0xb5, 0x66, 0x48, 0x03, 0xf6, 0x0e, 634 0x61, 0x35, 0x57, 0xb9, 0x86, 0xc1, 0x1d, 0x9e, 635 0xe1, 0xf8, 0x98, 0x11, 0x69, 0xd9, 0x8e, 0x94, 636 0x9b, 0x1e, 0x87, 0xe9, 0xce, 0x55, 0x28, 0xdf, 637 0x8c, 0xa1, 0x89, 0x0d, 0xbf, 0xe6, 0x42, 0x68, 638 0x41, 0x99, 0x2d, 0x0f, 0xb0, 0x54, 0xbb, 0x16 639 }; 640 /* For CMAC Calculation */ 641 unsigned char const_Rb[16] = { 642 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 643 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x87 644 }; 645 unsigned char const_Zero[16] = { 646 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 647 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 648 }; 650 /*****************************/ 651 /**** Function Prototypes ****/ 652 /*****************************/ 654 void xor_128(unsigned char *a, unsigned char *b, unsigned char *out); 655 void xor_32(unsigned char *a, unsigned char *b, unsigned char *out); 656 unsigned char sbox(unsigned char a); 657 void next_key(unsigned char *key, int round); 658 void byte_sub(unsigned char *in, unsigned char *out); 659 void shift_row(unsigned char *in, unsigned char *out); 660 void mix_column(unsigned char *in, unsigned char *out); 661 void add_round_key( unsigned char *shiftrow_in, 662 unsigned char *mcol_in, 663 unsigned char *block_in, 664 int round, 665 unsigned char *out); 667 void AES_128(unsigned char *key, unsigned char *data, unsigned char 668 *ciphertext); 669 void leftshift_onebit(unsigned char *input,unsigned char *output); 671 /****************************************/ 672 /* AES_128() */ 673 /* Performs a 128 bit AES encrypt with */ 674 /* 128 bit data. */ 675 /****************************************/ 677 void xor_128(unsigned char *a, unsigned char *b, unsigned char *out) 678 { 679 int i; 680 for (i=0;i<16; i++) 681 { 682 out[i] = a[i] ^ b[i]; 683 } 684 } 685 void xor_32(unsigned char *a, unsigned char *b, unsigned char *out) 686 { 687 int i; 688 for (i=0;i<4; i++) 689 { 690 out[i] = a[i] ^ b[i]; 691 } 692 } 694 unsigned char sbox(unsigned char a) 695 { 696 return sbox_table[(int)a]; 697 } 699 void next_key(unsigned char *key, int round) 700 { 701 unsigned char rcon; 702 unsigned char sbox_key[4]; 703 unsigned char rcon_table[12] = { 704 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80, 705 0x1b, 0x36, 0x36, 0x36 706 }; 708 sbox_key[0] = sbox(key[13]); 709 sbox_key[1] = sbox(key[14]); 710 sbox_key[2] = sbox(key[15]); 711 sbox_key[3] = sbox(key[12]); 712 rcon = rcon_table[round]; 714 xor_32(&key[0], sbox_key, &key[0]); 715 key[0] = key[0] ^ rcon; 717 xor_32(&key[4], &key[0], &key[4]); 718 xor_32(&key[8], &key[4], &key[8]); 719 xor_32(&key[12], &key[8], &key[12]); 720 } 722 void byte_sub(unsigned char *in, unsigned char *out) 723 { 724 int i; 725 for (i=0; i< 16; i++) 726 { 727 out[i] = sbox(in[i]); 728 } 729 } 730 void shift_row(unsigned char *in, unsigned char *out) 731 { 732 out[0] = in[0]; 733 out[1] = in[5]; 734 out[2] = in[10]; 735 out[3] = in[15]; 736 out[4] = in[4]; 737 out[5] = in[9]; 738 out[6] = in[14]; 739 out[7] = in[3]; 740 out[8] = in[8]; 741 out[9] = in[13]; 742 out[10] = in[2]; 743 out[11] = in[7]; 744 out[12] = in[12]; 745 out[13] = in[1]; 746 out[14] = in[6]; 747 out[15] = in[11]; 748 } 750 void mix_column(unsigned char *in, unsigned char *out) 751 { 752 int i; 753 unsigned char add1b[4]; 754 unsigned char add1bf7[4]; 755 unsigned char rotl[4]; 756 unsigned char swap_halfs[4]; 757 unsigned char andf7[4]; 758 unsigned char rotr[4]; 759 unsigned char temp[4]; 760 unsigned char tempb[4]; 762 for (i=0 ; i<4; i++) 763 { 764 if ((in[i] & 0x80)== 0x80) 765 add1b[i] = 0x1b; 766 else 767 add1b[i] = 0x00; 768 } 770 swap_halfs[0] = in[2]; /* Swap halfs */ 771 swap_halfs[1] = in[3]; 772 swap_halfs[2] = in[0]; 773 swap_halfs[3] = in[1]; 775 rotl[0] = in[3]; /* Rotate left 8 bits */ 776 rotl[1] = in[0]; 777 rotl[2] = in[1]; 778 rotl[3] = in[2]; 779 andf7[0] = in[0] & 0x7f; 780 andf7[1] = in[1] & 0x7f; 781 andf7[2] = in[2] & 0x7f; 782 andf7[3] = in[3] & 0x7f; 784 for (i = 3; i>0; i--) /* logical shift left 1 bit */ 785 { 786 andf7[i] = andf7[i] << 1; 787 if ((andf7[i-1] & 0x80) == 0x80) 788 { 789 andf7[i] = (andf7[i] | 0x01); 790 } 791 } 792 andf7[0] = andf7[0] << 1; 793 andf7[0] = andf7[0] & 0xfe; 795 xor_32(add1b, andf7, add1bf7); 797 xor_32(in, add1bf7, rotr); 799 temp[0] = rotr[0]; /* Rotate right 8 bits */ 800 rotr[0] = rotr[1]; 801 rotr[1] = rotr[2]; 802 rotr[2] = rotr[3]; 803 rotr[3] = temp[0]; 804 xor_32(add1bf7, rotr, temp); 805 xor_32(swap_halfs, rotl,tempb); 806 xor_32(temp, tempb, out); 807 } 809 void AES_128(unsigned char *key, unsigned char *data, unsigned char 810 *ciphertext) 811 { 812 int round; 813 int i; 814 unsigned char intermediatea[16]; 815 unsigned char intermediateb[16]; 816 unsigned char round_key[16]; 818 for(i=0; i<16; i++) round_key[i] = key[i]; 819 for (round = 0; round < 11; round++) 820 { 821 if (round == 0) 822 { 823 xor_128(round_key, data, ciphertext); 824 next_key(round_key, round); 825 } 827 else if (round == 10) 828 { 829 byte_sub(ciphertext, intermediatea); 830 shift_row(intermediatea, intermediateb); 831 xor_128(intermediateb, round_key, ciphertext); 832 } 833 else /* 1 - 9 */ 834 { 835 byte_sub(ciphertext, intermediatea); 836 shift_row(intermediatea, intermediateb); 837 mix_column(&intermediateb[0], &intermediatea[0]); 838 mix_column(&intermediateb[4], &intermediatea[4]); 839 mix_column(&intermediateb[8], &intermediatea[8]); 840 mix_column(&intermediateb[12], &intermediatea[12]); 841 xor_128(intermediatea, round_key, ciphertext); 842 next_key(round_key, round); 843 } 844 } 845 } 847 void print_hex(char *str, unsigned char *buf, int len) 848 { 849 int i; 851 for ( i=0; i=0; i-- ) { 885 output[i] = input[i] << 1; 886 output[i] |= overflow; 887 overflow = (input[i] & 0x80)?1:0; 888 } 889 return; 890 } 892 void generate_subkey(unsigned char *key, unsigned char *K1, unsigned 893 char *K2) 894 { 895 unsigned char L[16]; 896 unsigned char Z[16]; 897 unsigned char tmp[16]; 898 int i; 900 for ( i=0; i<16; i++ ) Z[i] = 0; 902 AES_128(key,Z,L); 904 if ( (L[0] & 0x80) == 0 ) { /* If MSB(L) = 0, then K1 = L << 1 */ 905 leftshift_onebit(L,K1); 906 } else { /* Else K1 = ( L << 1 ) (+) Rb */ 907 leftshift_onebit(L,tmp); 908 xor_128(tmp,const_Rb,K1); 909 } 911 if ( (K1[0] & 0x80) == 0 ) { 912 leftshift_onebit(K1,K2); 913 } else { 914 leftshift_onebit(K1,tmp); 915 xor_128(tmp,const_Rb,K2); 916 } 917 return; 918 } 919 void padding ( unsigned char *lastb, unsigned char *pad, int length ) 920 { 921 int j; 923 /* original last block */ 924 for ( j=0; j<16; j++ ) { 925 if ( j < length ) { 926 pad[j] = lastb[j]; 927 } else if ( j == length ) { 928 pad[j] = 0x80; 929 } else { 930 pad[j] = 0x00; 931 } 932 } 933 } 935 void AES_CMAC ( unsigned char *key, unsigned char *input, int length, 936 unsigned char *mac ) 937 { 938 unsigned char X[16],Y[16], M_last[16], padded[16]; 939 unsigned char K1[16], K2[16]; 940 int n, i, flag; 941 generate_subkey(key,K1,K2); 943 n = (length+15) / 16; /* n is number of rounds */ 945 if ( n == 0 ) { 946 n = 1; 947 flag = 0; 948 } else { 949 if ( (length%16) == 0 ) { /* last block is a complete block */ 950 flag = 1; 951 } else { /* last block is not complete block */ 952 flag = 0; 953 } 954 } 956 if ( flag ) { /* last block is complete block */ 957 xor_128(&input[16*(n-1)],K1,M_last); 958 } else { 959 padding(&input[16*(n-1)],padded,length%16); 960 xor_128(padded,K2,M_last); 961 } 963 for ( i=0; i<16; i++ ) X[i] = 0; 964 for ( i=0; i\n"); 1007 AES_CMAC(key,M,0,T); 1008 printf("AES_CMAC "); print128(T); printf("\n"); 1010 printf("\nExample 2: len = 16\n"); 1011 printf("M "); print_hex(" ",M,16); 1012 AES_CMAC(key,M,16,T); 1013 printf("AES_CMAC "); print128(T); printf("\n"); 1014 printf("\nExample 3: len = 40\n"); 1015 printf("M "); print_hex(" ",M,40); 1016 AES_CMAC(key,M,40,T); 1017 printf("AES_CMAC "); print128(T); printf("\n"); 1018 printf("\nExample 4: len = 64\n"); 1019 printf("M "); print_hex(" ",M,64); 1020 AES_CMAC(key,M,64,T); 1021 printf("AES_CMAC "); print128(T); printf("\n"); 1023 printf("--------------------------------------------------\n"); 1025 return 0; 1026 } 1028 Intellectual Property Statement 1030 The IETF takes no position regarding the validity or scope of any 1031 Intellectual Property Rights or other rights that might be claimed to 1032 pertain to the implementation or use of the technology described in 1033 this document or the extent to which any license under such rights 1034 might or might not be available; nor does it represent that it has 1035 made any independent effort to identify any such rights. Information 1036 on the procedures with respect to rights in RFC documents can be 1037 found in BCP 78 and BCP 79. 1039 Copies of IPR disclosures made to the IETF Secretariat and any 1040 assurances of licenses to be made available, or the result of an 1041 attempt made to obtain a general license or permission for the use of 1042 such proprietary rights by implementers or users of this 1043 specification can be obtained from the IETF on-line IPR repository at 1044 http://www.ietf.org/ipr. 1046 The IETF invites any interested party to bring to its attention any 1047 copyrights, patents or patent applications, or other proprietary 1048 rights that may cover technology that may be required to implement 1049 this standard. Please address the information to the IETF at 1050 ietf-ipr@ietf.org. 1052 Disclaimer of Validity 1054 This document and the information contained herein are provided on an 1055 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1056 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1057 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1058 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1059 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1060 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1062 Copyright Statement 1064 Copyright (C) The Internet Society (2005). This document is subject 1065 to the rights, licenses and restrictions contained in BCP 78, and 1066 except as set forth therein, the authors retain all their rights. 1068 Acknowledgment 1070 Funding for the RFC Editor function is currently provided by the 1071 Internet Society.