idnits 2.17.1 draft-irtf-hiprg-rfid-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 434 has weird spacing: '...MAY be a fi...' == Line 473 has weird spacing: '...ID has recei...' == Line 579 has weird spacing: '...-Length paddi...' == Line 618 has weird spacing: '...-Length paddi...' == Line 635 has weird spacing: '...-Length paddi...' == (3 more instances...) -- The document date (April 2013) is 4022 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'HEP' is mentioned on line 218, but not defined == Missing Reference: 'RFC 5201' is mentioned on line 444, but not defined ** Obsolete undefined reference: RFC 5201 (Obsoleted by RFC 7401) -- Looks like a reference, but probably isn't: '6' on line 1217 -- Looks like a reference, but probably isn't: '1' on line 1284 == Unused Reference: 'NIST-800-108' is defined on line 994, but no explicit reference was found in the text == Unused Reference: 'HIP-TAG-EXP' is defined on line 1004, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5201 (ref. 'HIP') (Obsoleted by RFC 7401) == Outdated reference: A later version (-04) exists of draft-zhang-hip-privacy-protection-00 Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP Research Group Pascal Urien 3 Internet Draft Telecom ParisTech 4 Intended status: Experimental Gyu Myoung Lee 5 Telecom SudParis 6 Expires: October 2013 Guy Pujolle 7 LIP6 8 April 2013 10 HIP support for RFIDs 11 draft-irtf-hiprg-rfid-07 13 Abstract 15 This document describes an architecture based on the Host Identity 16 Protocol (HIP), for active RFIDs, i.e. Radio Frequency Identifiers 17 including tamper resistant computing resources, as specified for 18 example in the ISO 14443 or 15693 standards. HIP-RFIDs never expose 19 their identity in clear text, but hide this value (typically an EPC- 20 Code) by a particular equation that can be only solved by a dedicated 21 entity, referred as the portal. HIP exchanges occur between HIP-RFIDs 22 and portals; they are transported by IP packets, through the Internet 23 cloud. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute working 38 documents as Internet-Drafts. The list of current Internet-Drafts is 39 at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on October 2013. 48 Copyright Notice 50 Copyright (c) 2013 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. 60 All IETF Documents and the information contained therein are provided 61 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 62 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 63 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 64 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 65 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 66 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 67 FOR A PARTICULAR PURPOSE. 69 Table of Contents 71 Abstract........................................................... 1 72 Requirements Language.............................................. 1 73 Status of this Memo................................................ 1 74 Copyright Notice................................................... 2 75 Table of Contents.................................................. 3 76 1 Overview......................................................... 5 77 1.1 Motivation.................................................. 5 78 1.2 Passive and active RFIDs.................................... 5 79 1.3 About the Internet of Things (IoT).......................... 6 80 1.4 HIP-RFIDs................................................... 6 81 1.5 Main differences between HIP-RFID and HIP................... 7 82 2. Basic Exchange.................................................. 8 83 2.1 I1-T........................................................ 9 84 2.2 R1-T........................................................ 9 85 2.3 I2-T........................................................ 9 86 2.4 R2-T....................................................... 10 87 2.5 HIT format................................................. 10 88 2.6 State Machine.............................................. 11 89 2.6.1 Unassociated. ....................................... 11 90 2.6.2 I1-Sent ............................................. 11 91 2.6.3 R1-Sent ............................................. 11 92 2.6.4 I2-Sent ............................................. 11 93 2.6.5 R2-Sent ............................................. 11 94 2.6.6 Established ......................................... 11 95 3. Formats........................................................ 12 96 3.1 Payload.................................................... 12 97 3.2 Packet types............................................... 13 98 3.3 Summary of HIP parameters.................................. 14 99 3.4 R-T........................................................ 14 100 3.5 HIP-T-Transform............................................ 15 101 3.6 F-T........................................................ 15 102 3.7 MAC-T...................................................... 16 103 3.8 ESP-Transform.............................................. 16 104 3.9 ESP-Info................................................... 16 105 4. BEX Example.................................................... 17 106 4.1 Generic example............................................ 17 107 4.1.1 I1-T ................................................ 17 108 4.1.2 R1-T ................................................ 17 109 4.1.3 I2-T ................................................ 18 110 4.1.4 R2-T ................................................ 19 111 4.2 HIP-T Transform 0x0001, HMAC............................... 19 112 4.2.1 I1-T ................................................ 19 113 4.2.2 R1-T ................................................ 19 114 4.2.3 I2-T ................................................ 20 115 5. HIP-T-Transforms Definition.................................... 20 116 5.1 Type 0x0001, HMAC.......................................... 20 117 5.1.1 Suite-ID ............................................ 20 118 5.1.2 F-T computing (f function) .......................... 20 119 5.1.3 K-Auth-Key computing (g function) ................... 21 120 5.1.4 MAC-T computing ..................................... 21 121 5.2 Type 0x0002, Keys-Tree..................................... 21 122 5.2.1 Suite-ID ............................................ 21 123 5.2.2 F-T computing (f function) .......................... 21 124 5.2.3 K-Auth-Key computing (g function) ................... 22 125 5.2.4 MAC-T computing ..................................... 22 126 6. Security Considerations........................................ 22 127 7. IANA Considerations............................................ 23 128 8 References...................................................... 24 129 8.1 Normative references....................................... 24 130 8.2 Informative references..................................... 24 131 9 Annex I......................................................... 24 132 9.1 Binary Interface with HIP RFIDs............................ 25 133 9.3 Exchanged data............................................. 25 134 9.3 Javacard code sample....................................... 26 135 Author's Addresses................................................ 31 136 1 Overview 138 1.1 Motivation 140 RFIDs are electronic devices, associated to things or computers, 141 which transmit their identifier (usually a serial number) via radio 142 links. The Host Identity Protocol [HIP] is a security protocol based 143 on the use of cryptographic identifiers, and specified for IP-based 144 networks [HIP]. 146 The first motivation for designing HIP support for RFIDs is to 147 enforce a strong privacy for the Internet of Things, e.g. identity is 148 protected by cryptographic procedures compatible with RFID computing 149 resources. As an illustration, EPC codes or IP addresses are today 150 transmitted in the clear. 152 The second motivation is to define an identity layer for RFIDs 153 logically independent from the transport facilities, which may 154 optionally support IP stacks. 156 In other words, we believe that the Internet of Things will be 157 Identity oriented; RFIDs will act as electronic ID for objects to 158 which they are linked. In this context, privacy is a major challenge. 160 1.2 Passive and active RFIDs 162 An RFID is a slice of silicon whose area is about 1 mm2 for 163 components used as cheap electronic RFIDs, and around 25 mm2 for 164 chips like contact-less smart cards inserted in passports and mobile 165 phones. 167 RFIDs are divided into two classes, the first includes devices that 168 embed CPU and memory (RAM, ROM, E2PROM) such as contact-less smart 169 cards, and the second comprises electronic chips based on cabled 170 logic circuits. 172 There are multiple standards relative to RFIDs. The ISO 14443 173 standard introduces components dealing with the 13.56 MHz frequency 174 that embed a CPU and consume about 10mW; data throughput is about 100 175 Kbits/s and the maximum working distance (from the reader) is around 176 10cm. 178 The ISO 15693 standard also uses the same 13.56 MHz frequency, but 179 enables working distances as high as one meter, with a data 180 throughput of a few Kbits/s. 182 The ISO 18000 standard defines parameters for air interface 183 communications associated with frequency such as 135 KHz, 13.56 MHz, 184 2.45 GHz, 5.8 GHz, 860 to 960 MHz and 433 MHz. The ISO 18000-6 185 standard uses the 860-960 MHz range and is the basis for the Class-1 186 Generation-2 UHF RFID, introduced by the EPCglobal [EPCGLOBAL] 187 consortium. 189 1.3 About the Internet of Things (IoT) 191 The term "Internet of Thing (IoT)" was invented by the MIT Auto-ID 192 Center, in 2001, and refers to an architecture that comprises four 193 levels, 195 - Passive RFIDs, such as Class-1 Generation-2 UHF RFIDs, introduced 196 by the EPC Global consortium and operating in the 860-960 MHz range. 198 - Readers plugged to a local (computing) system, which read the 199 Electronic Product Code [EPC]. 201 - A local system, offering IP connectivity, which collects 202 information pointed by the EPC thanks to a protocol called Object 203 Naming Service (ONS) 205 - EPCIS (EPC Information Services) servers, which process incoming 206 ONS requests and returns PML (Physical Markup Language) files [PML], 207 e.g. XML documents that carry meaningful information linked to RFIDs. 209 1.4 HIP-RFIDs 211 PORTAL READER RFID 213 +-----------------------+ 214 ! ! +-----------+ 215 ! +-----+ ! ! +-------+ ! 216 ! +---------+ + HIP + !<=========================>! + HIP + ! 217 ! + IDENTITY+ +-----+ ! +-------------------+ ! +-------+ ! 218 ! + SOLVER + [HEP] !<=>! [HEP] ! ! | ! 219 ! +---------+ +-----+ ! ! +------+-------+ ! ! +-------+ ! 220 ! + + ! ! + + RFID + ! ! + RFID + ! 221 ! EPC-Code + IP + !<=>! + IP + Radio + !<=>! + Radio + ! 222 ! + + ! ! + + Ptcol + ! ! + Ptcol + ! 223 ! +-----+ ! ! +------+-------+ ! ! +-------+ ! 224 ! ! ! ! ! ! 225 +----------+------------+ +-------------------+ +-----------+ 226 ! 227 V 228 TO EPC GLOBAL 229 SERVICES 231 Figure 1. HIP-RFID Architecture 233 This document suggests embedding a modified version of a HIP-enabled 234 stack in active RFIDs, named HIP-RFIDs. It assumes that such devices 235 would not support an IP stack, but should be rather identity 236 oriented, i.e. will use readers' IP resources in order to unveil 237 their EPC-Code only to trusted entities (called portals in the 238 architecture shown by Figure 1). Privacy, e.g. identity protection 239 seems a key prerequisite [SEC] before the effective massive 240 deployment of these devices. 242 The HIP-RFID architecture includes three functional entities: HIP 243 RFIDs, RFID readers, and portals, and defines a new HIP encapsulation 244 protocol (HEP): 246 - HIP RFIDs. HIP, as defined in [HIP], is transported by IP packets. 247 HIP-RFIDs support a modified version of this protocol but do not 248 require end-to-end IP transport. 250 - RFID readers. These provide IP connectivity and communicate with 251 RFIDs through radio links either defined by EPC Global or ISO 252 standards. The IP layer transports HIP messages between RFIDs and 253 other HIP entities. According to HIP, an SPI (Security Parameter 254 Index) associated to an IPsec tunnel MAY be used by the IP host (e.g. 255 a reader) in order to route HIP packets to/from the right software 256 identity. 258 - HEP, HIP Encapsulation Protocol. HIP messages MAY be encapsulated 259 by protocols such as UDP or TCP in order to facilitate HIP transport 260 in existing software and networking architectures. The HEP does not 261 modify the content of an HIP packet. This class of protocol is not 262 specified by this document. 264 - PORTAL entity. This device manages a set of readers; it is a HIP 265 entity that includes a full IP stack. Communications between portal 266 and RFIDs logically work as peer to peer HIP exchanges. RFID 267 identifier (HIT) is hidden and appears as a pseudo random value; 268 within the portal a software block called the IDENTITY SOLVER 269 resolves an equation f, whose solution is an EPC Code. The portal 270 accesses EPCIS services; when required privacy may be enforced by 271 legacy protocol such as SSL or IPsec. 273 - The portal maintains a table linking HIT and EPC-Code. It acts as a 274 router for that purpose it MUST provide an identity resolution 275 mechanism, i.e. a relation between HIT and EPC-Code. 277 1.5 Main differences between HIP-RFID and HIP 279 In HIP [HIP], the HIT (Host Identifier Tag) is a fixed value obtained 280 from the hash of an RSA public key. This parameter is therefore 281 linked to a unique identity, and can be used for traceability 282 purposes; in other words HIP does not natively include privacy 283 features. 285 In [BLIND], it is proposed to hide the HIT with a random number 286 thanks to a hash function, i.e. 288 B-HIT = sha1(HIT || N), with N a random value and || the 289 concatenation operation. 291 The case in which only one HIT (either initiator or responder) is 292 blinded looks similar to the HIP-RFID protocol described in this 293 draft working with a particular transform (HMAC Transform, 0x0001). 295 2. Basic Exchange 297 The HIP-RFID base exchange (T-BEX) is derived from the "classical" 298 base exchange (BEX), introduced in [HIP]. It is a four way handshake 299 illustrated by Figure 2. 301 RFID READER PORTAL 302 --+-- --+-- ---+--- 303 ! START ! ! 304 !<---------------! ! 305 ! ! ! 306 ! I1-T ! 307 ! HIT-I HIT-R ! 308 ! ----------------------------------------------------> ! 309 ! ! 310 ! ! 311 ! R1-T ! 312 ! HIT-I HIT-R R-T(r1) HIP-T-Transforms ! 313 ! [*ESP-Transforms] ! 314 ! <---------------------------------------------------- ! 315 ! ! 316 ! ! 317 ! I2-T ! 318 ! HIT-I HIT-R HIP-T-Transform [*ESP-Transform] R-T(r2) ! 319 ! F-T=f(r1, r2, EPC-Code) [*ESP-Info] MAC-T ! 320 ! ----------------------------------------------------> ! 321 ! ! 322 ! ! 323 ! R2-T ! 324 ! HIT-I HIT-R [*ESP-Info] MAC-T ! 325 ! <---------------------------------------------------- ! 326 ! ! 327 ! ! 328 ! Optional ESP Dialog ! 329 ! <---------------------------------------------------> ! 330 ! ! 331 ! ! 333 Figure 2. HIP-RFIDs Base Exchange (T-BEX), *means optional attributes 335 A HEP layer MAY be used to transport HIP messages in a non-IP 336 context, but this optional facility is out of scope for this 337 document. 339 2.1 I1-T 341 When a reader detects an RFID, it realizes all low level operations 342 in order to set up a radio communication link. Finally the reader 343 delivers a START message that triggers the RFID. 345 The HIP-RFID sends the I1-T packet (I suffix meaning initiator), in 346 which HIT-I is a pseudorandom value internally generated by the HIP- 347 RFID. 349 If the RFID doesn't known the portal HIT it sets the HIT-R value to 350 zero; in that case the reader MAY modify this field in order to 351 identify the appropriate entity. 353 The I1-T message is not MACed. 355 2.2 R1-T 357 The portal produces the R1-T (R suffix meaning responder) packet, 358 which includes a nonce r1 and optional parameters. These fields 359 indicate a list of supported authentication schemes (HIP-T- 360 TRANSFORMs) and a list of ESP-TRANSFORMs, i.e. secure channels that 361 could be opened between portal and RFIDs. 363 This message includes the following fields: 364 - HIT-I, a random number which identifies a RFID 365 - HIT-R, the portal HIP, either a null or fixed value. 366 - HIT-T-TRANSFORMs, a list of authentication schemes 367 - ESP-T-TRANSFORMs, an optional list of ESP secure channels 369 The R1-T message is not MACed. 371 2.3 I2-T 373 The HIP-RFID builds the I2-T message, which contains 375 - The selected HIP-T-TRANSFORM (the current authentication scheme). 376 - An optional ESP-TRANSFORM (a class of secure channel between RFID 377 and portal). 378 - A nonce r2, included in the R-T attribute. 379 - An equation f(r1, r2, EPC-Code), whose solution, according to the 380 selected HIP-T-TRANSFORM, unveils the EPC-Code value. 381 - An optional ESP-Info attribute that gives information about the 382 secure (ESP) channel, and which includes the SPI-I value. 383 - A keyed MAC (MAC-T), which works with a KI-Auth-key deduced from 384 r1, r2 and the hidden EPC-Code value. 386 KI-Auth-key = g(r1, r2, EPC-Code) 388 The keyed MAC is by default computed over the complete I2-T message, 389 the content of MAC-T resulting from this calculation is initially set 390 to a null value. Particular HIP-T-TRANSFORMs MAY work with different 391 rules (see section 6). 393 The portal and the RFID shares secret keys. The meaning of these keys 394 are dependent upon the f equation. 396 In some cases the EPC-Code is the only shared key. The portal knows a 397 list of EPC-Code and tries all solutions for solving f, according to 398 brute force techniques. As an illustration a hash function may be 399 used for f: 401 f= sha1(r1 || r2 || EPC-Code), where || is the concatenation 402 operation. 404 In other cases a set of keys is shared between portal and RFIDs. For 405 example a binary tree of HMAC procedure MAY be used, each HMAC beeing 406 associated to a particular key. A binary tree of depth n may identify 407 2**n RFIDs, each of them stores n keys (ki:j). The f function is a 408 list of n values such as 410 HMAC(r1 || r2, ki:j) 412 Where ki:j is a secret key, and j the bit value (either 0 or 1) at 413 the rank i (ranging between 0 and n-1) for the EPC-Code (or the RFID 414 index). 416 2.4 R2-T 418 The fourth and last R2-T packet is optional. It includes 420 - A keyed MAC (MAC-T) computed with the KI-Auth-key deduced from r1, 421 r2 and the hidden EPC-Code value. 423 KI-Auth-key = g(r1, r2, EPC-Code) 425 - An optional ESP-Info attribute that gives information about the 426 secure (ESP) channel, and which includes the SPI-R value. 428 The R2-T packet is mandatory when an ESP channel has been previously 429 negotiated. ESP channel is required if the portal intends to perform 430 read or write operations with the RFIDs. 432 2.5 HIT format 434 HIT-R MAY be a fixed value embedded in the RFID during the 435 manufacturing process or a null value if no specific portal is 436 required. 438 HIT-I MAY comprise an optional header given coded according to 439 various hierarchical rules and MUST include a trailer, which is a 440 true random number. 442 2.6 State Machine 444 The state machine is similar to the one described in [RFC 5201]. No 445 retry operations are performed, because the communication with the 446 RFID may be lost at any time. Furthermore RFIDs are generally not 447 equipped with timers. 449 2.6.1 Unassociated. 451 The state machine starts. 453 2.6.2 I1-Sent 455 The RFID has been reset by the reader, and has sent the I1-T message. 457 2.6.3 R1-Sent 459 The responder has received the I1-T message and has sent the R1-T 460 packet. 462 2.6.4 I2-Sent 464 The RFID has received the R1-T packet, and has sent the I2-T message. 466 2.6.5 R2-Sent 468 The responder has received the I2-T message and has sent the optional 469 R2-T packet. 471 2.6.6 Established 473 The RFID has received the R2-T message. A secure channel is 474 established. 476 3. Formats 478 3.1 Payload 480 The payload format is imported from the [HIP] specification. 482 0 1 2 3 483 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Next Header | Header Length |0| Packet Type | VER. | RES.|1| 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Checksum | Controls | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Sender's Host Identity RFID (HIT) | 490 | | 491 | | 492 | | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Receiver's Host Identity RFID (HIT) | 495 | | 496 | | 497 | | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | | 500 / HIP Parameters / 501 / / 502 | | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 Next Header : normal value is decimal 59, IPPROTO_NONE. 507 Header Length: the length of the HIP Header and HIP parameters in 8 508 bytes units, excluding the first 8 bytes 510 Packet Type: Detailed in section 4.2 512 VER: 0001 514 RES: 000 516 Checksum: This checksum covers the source and destination addresses 517 in the IP header. 519 HIP-RFIDs always deliver HIP packets with the null value for the 520 checksum field. The reader MUST compute the checksum. 522 HIP-RFIDs do not check the checksum of received packets. 524 Controls: this field is reserved for future use (RFU) 526 Sender's Host Identity RFID: 16 bytes HIT 527 Receiver's Host Identity RFID: 16 bytes HIT 529 HIP Parameters: a list of attributes encoded in the TLV format 531 3.2 Packet types 533 +-----------------+--------------------------------------------+ 534 | Packet type | Packet name | 535 +-----------------+--------------------------------------------+ 536 | 0x40 | I1-T - The HIP-RFID Initiator Packet | 537 | | | 538 | 0x41 | R1-T - The HIP-RFID Responder Packet | 539 | | | 540 | 0x42 | I2-T - The Second HIP-RFID Initiator Packet| 541 | | | 542 | 0x43 | R2-T - The Second HIP-RFID Responder Packet| 543 | | | 544 +-----------------+--------------------------------------------+ 545 3.3 Summary of HIP parameters 547 +----------------------+-------+----------+-----------------------+ 548 | TLV | Type | Length | Data | 549 +----------------------+-------+----------+-----------------------+ 550 | R-T | 0x400 | variable | Random value r1 or r2 | 551 | | | | | 552 | HIP-T-TRANSFORM | 0x402 | variable | HIP-RFID transform(s) | 553 | | | | | 554 | F-T | 0x404 | variable | f function value | 555 | | | | | 556 | MAC-T | 0x406 | variable | Keyed MAC | 557 | | | | | 558 | ESP-Transform | 0x408 | variable | ESP transform(s) | 559 | | | | | 560 | ESP-Info | 0x40A | variable | ESP parameter(s) | 561 | | | | | 562 +----------------------+-------+----------+-----------------------+ 564 3.4 R-T 566 0 1 2 3 567 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Type | Length | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Padding-Length | value / 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 / value | Padding | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 Type 0x400 577 Length total length in bytes 578 Value random value 579 Padding-Length padding length in bytes 580 Padding padding bytes 581 3.5 HIP-T-Transform 583 0 1 2 3 584 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Type | Length | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Padding-Length | Suite-ID#1 | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 + Length-of-Suite-ID#1 | value + 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 / value | Suite-ID#2 | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | | Padding | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 Type 0x402 598 Length Total length 599 Padding-Length Number of padding bytes 600 Suite-ID Defines the HIP Cipher Suite to be used 601 Length-of-Suite-ID Defines the length of optional data 602 Padding Padding bytes 604 3.6 F-T 606 0 1 2 3 607 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Type | Length | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Padding-Length | value | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | | Padding | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 Type 0x404 617 Length total length, in bytes 618 Padding-Length padding length in bytes 619 Value the f value with a variable length 620 Padding padding bytes 621 3.7 MAC-T 623 0 1 2 3 624 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Type | Length | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Padding-Length | MAC / 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 / | Padding | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 Type 0x406 634 Length total length, in bytes 635 Padding-Length padding length, in bytes 636 Value Keyed MAC value 637 Padding padding bytes 639 A MAC procedure works with the K-Auth-Key and is computed over the 640 whole HIP message according to the following rules 642 - The checksum field of the HIP header is set to a null value. 644 - The MAC field of the MAC-T attribute is set to a null value 646 3.8 ESP-Transform 648 Details of the attribute will be specified by another document. 650 3.9 ESP-Info 652 Details of the attribute will be specified by another document. 654 4. BEX Example 656 4.1 Generic example 658 4.1.1 I1-T 660 Next Header: 0x3B 661 Header Length: 0x4 662 Packet Type: 0x40 663 Version: 0x1 664 Reserved: 0x1 665 Control: 0x0 666 Checksum: 0x0000 667 Sender's HIT (RFID) : 0x0123456789ABCDEF 668 0123456789ABCDEF 669 Receiver's HIT (Portal) : 0x0000000000000000 670 0000000000000000 672 The checksum is computed by portal and reader according to rules 673 specified in [HIP]; it covers the source and destination IP 674 addresses. 676 4.1.2 R1-T 678 Next Header: 0x3B 679 Header Length: 0xB 680 Packet Type: 0x41 681 Version: 0x1 682 Reserved: 0x1 683 Control: 0x0 684 Checksum: 0xabcd 685 Sender's HIT (Portal) 0xA5A5A5A5A5A5A5A5 686 5A5A5A5A5A5A5A5A 687 Receiver's HIT (RFID) 0x0123456789ABCDEF 688 0123456789ABCDEF 689 R-T 0x040000280002rrrr 690 rrrrrrrrrrrrrrrr 691 rrrrrrrrrrrrrrrr 692 rrrrrrrrrrrrrrrr 693 rrrrrrrrrrrrpppp 694 HIP-T-Transforms 0x0402001000020001 695 000000020000pppp 697 r1 is a 128 bits value 698 Transforms 1, 2 are supported by the reader. 700 4.1.3 I2-T 702 Next Header: 0x3B 703 Header Length: 0x14 704 Packet Type: 0x42 705 Version: 0x1 706 Reserved: 0x1 707 Control: 0x0 708 Checksum: 0x0000 709 Sender's HIT (RFID) : 0x0123456789ABCDEF 710 0123456789ABCDEF 711 Sender's HIT (Portal) : 0xA5A5A5A5A5A5A5A5 712 5A5A5A5A5A5A5A5A 713 HIP-T-Transform 0x0402001000060001 714 0000pppppppppppp 715 R-T 0x040000280002rrrr 716 rrrrrrrrrrrrrrrr 717 rrrrrrrrrrrrrrrr 718 rrrrrrrrrrrrrrrr 719 rrrrrrrrrrrrpppp 720 F-T 0x040400280002ffff 721 ffffffffffffffff 722 ffffffffffffffff 723 ffffffffffffffff 724 ffffffffffffpppp 725 MAC-T 0x040600040006ssss 726 ssssssssssssssss 727 ssssssssssssssss 728 sssspppppppppppp 730 The RFID selects the HIP-Transform number one. It produces an r2 731 nonce and computes a f value. It appends a 20 bytes keyed MAC. 733 4.1.4 R2-T 735 Next Header: 0x3B 736 Header Length: 0x08 737 Packet Type: 0x40 738 Version: 0x1 739 Reserved: 0x1 740 Control: 0x0 741 Checksum: 0xabcd 742 Sender's HIT (RFID) : 0x0123456789ABCDEF 743 0123456789ABCDEF 744 Sender's HIT (Portal) : 0xA5A5A5A5A5A5A5A5 745 5A5A5A5A5A5A5A5A 746 MAC-T 0x040600040006ssss 747 ssssssssssssssss 748 ssssssssssssssss 749 sssspppppppppppp 751 Reader ends the BEX-T. 753 4.2 HIP-T Transform 0x0001, HMAC 755 EPC = 0123456789abcdefcdab 757 4.2.1 I1-T 759 << 3B 04 40 11 00 00 00 00 6A 68 2E 53 51 6B 51 6F 760 2F 58 CE 60 25 42 1A E6 00 00 00 00 00 00 00 00 761 00 00 00 00 00 00 00 00 763 HEAD 3b04401100000000 764 sHIT 6a682e53516b516f2f58ce6025421ae6 765 dHIT 00000000000000000000000000000000 767 4.2.2 R1-T 769 >> 3B 0A 41 11 00 00 00 00 00 00 00 00 00 00 00 00 770 00 00 00 00 00 00 00 00 6A 68 2E 53 51 6B 51 6F 771 2F 58 CE 60 25 42 1A E6 04 00 00 20 00 06 27 6D 772 03 4D DD 2D 52 79 3B 17 2C B9 5B CD 02 97 E2 DF 773 61 15 00 00 00 00 00 00 04 02 00 10 00 06 00 02 774 00 00 00 00 00 00 00 00 776 HEAD 3b0a411100000000 777 sHIT 00000000000000000000000000000000 778 dHIT 6a682e53516b516f2f58ce6025421ae6 780 ATT 0400 20 bytes 276d034ddd2d52793b172cb95bcd0297e2df6115 781 ATT 0402 04 bytes 00020000 782 4.2.3 I2-T 784 << 3B 13 40 11 00 00 00 00 6A 68 2E 53 51 6B 51 6F 785 2F 58 CE 60 25 42 1A E6 00 00 00 00 00 00 00 00 786 00 00 00 00 00 00 00 00 04 02 00 10 00 06 00 01 787 00 00 00 00 00 00 00 00 04 00 00 20 00 06 C5 95 788 8B 23 6B 9B 0E AA 7A BB 25 F2 7D 24 C5 04 6E 89 789 19 9E 00 00 00 00 00 00 04 04 00 20 00 06 80 1D 790 BC 55 C5 F3 97 89 F8 3C 6C BA 14 50 18 7D 83 83 791 3C AF 00 00 00 00 00 00 04 06 00 20 00 06 2A 23 792 68 93 2B F7 3A BE C4 6B DD B8 3F 1B 3F 7F 9D ED 793 8B 83 00 00 00 00 00 00 795 HEAD 3b13401100000000 796 sHIT 6a682e53516b516f2f58ce6025421ae6 797 dHIT 00000000000000000000000000000000 799 ATT 0402 04 bytes 00010000 800 ATT 0400 20 bytes c5958b236b9b0eaa7abb25f27d24c5046e89199e 801 ATT 0404 20 bytes 801dbc55c5f39789f83c6cba1450187d83833caf 802 ATT 0406 20 bytes 2a2368932bf73abec46bddb83f1b3f7f9ded8b83 804 5. HIP-T-Transforms Definition 806 5.1 Type 0x0001, HMAC 808 5.1.1 Suite-ID 810 Suite-ID: 0x0001 811 Length-of-Suite-ID: 0x0000 813 5.1.2 F-T computing (f function) 815 The F-T function produces a 20 bytes result, according to the 816 relation: 818 K = HMAC-SHA1(r1 | r2, EPC-Code) 820 Y = f(r1, r2, EPC-Code) = HMAC-SHA1(K, CT1 | "Type 0001 key") 822 Where: 824 - SHA1 is the SHA1 digest function 826 - EPC-Code is the RFID identity 828 - HMAC-SHA1 is the keyed MAC algorithm based on the SHA1 digest 829 procedure. 831 - CT1 is a 32 bits string, whose value is equal to 0x00000001 832 - r1 and r2 are the two random values exchanged by the BEX 834 5.1.3 K-Auth-Key computing (g function) 836 The K-Auth-Key is computing according to the relation: 838 K = HMAC-SHA1(r1 | r2, EPC-Code) 840 Y = HMAC-SHA1(K, CT2 | "Type 0001 key") 842 Where: 844 - SHA1 is the SHA1 digest function 846 - EPC-Code is the RFID identity 848 - HMAC-SHA1 is the keyed MAC algorithm based on the SHA1 digest 849 procedure. 851 - CT2 is a 32 bits string, whose value is equal to 0x00000002 853 - r1 and r2 are the two random values exchanged by the BEX 855 5.1.4 MAC-T computing 857 The HMAC-SHA1 function is used with the K-Auth-Key secret value: 859 MAC-T(HIT-T packet) = HMAC-SHA1(K-Auth-Key, HIP-T packet) 861 5.2 Type 0x0002, Keys-Tree 863 5.2.1 Suite-ID 865 Suite-ID: 0x0002 866 Length-of-Suite-ID: 0x0006 867 Value1: an index, a two bytes number, identifying a HASH function 868 (H), which produces h bytes. 869 Value2: n, the depth of the tree, a two bytes number. 870 Value3: p, the maximum number of child nodes, for each node, a two 871 bytes number. 873 The maximum elements of a keys-tree is therefore p**n 875 5.2.2 F-T computing (f function) 877 The F-T function produces a list of Hi, 1<= i <= n, of nh bytes 878 results, according to the relation: 880 Y = f(r1, r2, EPC-Code) = H1 | H2 | Hi | Hn 881 With 882 Hi = HMAC-SHA1(r1 | r2, Ki:j) 884 Where: 886 - H is digest function producing t bytes 888 - Ki:j is a set of pn secret keys. 890 Each EPC-Code is associated with an index, whose value is written as: 892 RFID-Index = an p**(n-1) + an-1 p**(n-2) + a1 894 Each ai digit( ai p**(i-1) )whose value ranges between 0 and p-1, is 895 associated with a key Ki:j (i.e. the tree is made with pn keys, but 896 only n values are stored in a given RFID), with j=ai 898 - HMAC-H is the keyed MAC algorithm based on the H digest procedure. 900 - r1 and r2 are the two random values exchanged by the BEX. 902 5.2.3 K-Auth-Key computing (g function) 904 The K-Auth-Key is computing according to the relation: 906 K-Auth-Key = HMAC-H(r1 | r2, RFID-Index) 908 Where: 910 - H is a digest function producing t bytes 912 - HMAC-H is the keyed MAC algorithm based on the H digest procedure. 914 - RFID INDEX is the RFID index. 916 - r1 and r2 are the two random values exchanged by the BEX. 918 5.2.4 MAC-T computing 920 The HMAC-H function is used with the K-Auth-Key secret value: 922 MAC-T(HIT-T packet) = HMAC-H(K-Auth-Key, HIP-T packet) 924 6. Security Considerations 926 In this section we only discuss the case where no ESP channel is 927 negotiated, i.e. a three ways handshake is performed thanks to the 928 I1-T, R1-T and I2-T packets. 930 The HIP-RFID infrastructure comprises a set readers establishing 931 sessions with a PORTAL. The exchanged packets MUST be protected by 932 secure tunnels such as IPSEC or any appropriate means. Readers feed 933 RFIDs and consequently deliver information about their position. 934 Without security association between readers and PORTALs rogue 935 devices can inject malicious packets such as I1-T and I2-T whose goal 936 is to forward a fake f equation that could not be solved by the 937 IDENTITY-SOLVER entity. This class of attack targets a Denial of 938 Service (DoS) threat; computing resources will be consumed by the 939 PORTAL that will stop its solving process after a given timeout. 941 Malicious RFIDs can also perform DoS attacks. However upon detection, 942 they could be discarded by their associated reader. 944 The I1-T packet includes no security feature. It may be forged by any 945 entity. 947 The R1-T packet includes no security feature. It may be forged by any 948 entity. A rogue portal SHOULD NOT expect to retrieve the HIP-RFID 949 identity thanks to cryptographic weaknesses of the f equation. 950 Nerveless hardware or software implementation of the HIP-RFID 951 protocol MUST be aware that the R1-T packet MUST be carefully parsed 952 and checked. 954 The I2-T packet includes a pseudo unique value r2, the f equation and 955 is MACed. The MAC field proves this packet integrity and optionally 956 the whole dialog integrity (dealing with I1-T, R1-T and I2-T). 957 Although HIP-T-TRANSFORMs detailed in this document only deal with 958 I2-T integrity, other transforms MAY use different schemes. 960 The two main classes of the f(r1,r2,EPC-Code) equation are bijections 961 (such as cipher algorithms) and surjections (such as digest 962 procedures). In the first case the solution (EPC-Code) is unique; its 963 correctness is checked via the keyed MAC. In the second case there 964 are multiples solutions, with very low probability of collisions; the 965 correctness of the highly probable solution is checked by the keyed 966 MAC. 968 7. IANA Considerations 970 This draft does not require any action from IANA. 972 8 References 974 8.1 Normative references 976 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 977 Requirement Levels", BCP 14, RFC 2119, March 1997. 979 [HIP] R. Moskowitz, P. Nikander, P. Jokela, T. Henderson, Host 980 Identity Protocol, RFC 5201, April 2008. 982 8.2 Informative references 984 [EPC] Brock, D.L, The Electronic Product Code (EPC), A Naming Scheme 985 for Physical Objects, MIT AUTO-ID CENTER, 2001. 987 [PML] Brock, D.L - The Physical Markup Language, MIT AUTO-ID CENTER, 988 2001. 990 [EPCGLOBAL] EPCglobal, EPC Radio Frequency Identity Protocols Class 1 991 1516 Generation 2 UHF RFID Protocol for Communications at 860 MHz-960 992 MHz Version 1517 1.0.9, EPCglobal Standard, January 2005. 994 [NIST-800-108] NIST Special Publication 800-108, Recommendation for 995 Key Derivation Using Pseudorandom Functions. 997 [SEC] S. Weis, S. Sarma, R. Rivest and D. Engels. "Security and 998 privacy aspects of low-cost radio frequency identification systems" 999 In D. Hutter, G. Muller, W. Stephan and M. Ullman, editors, 1000 International Conference on Security in Pervasive Computing - SPC 1001 2003, volume 2802 of Lecture Notes in computer Science, pages 454- 1002 469. Springer-Verlag, 2003. 1004 [HIP-TAG-EXP] Pascal Urien, Simon Elrharbi, Dorice Nyamy, Herve 1005 Chabanne, Thomas Icart, Francois Lecocq, Cyrille Pepin, Khalifa 1006 Toumi, Mathieu Bouet, Guy Pujolle, Patrice Krzanik, Jean-Ferdinand 1007 Susini, "HIP-Tags architecture implementation for the Internet of 1008 Things", AH-ICI 2009. First Asian Himalayas International Conference 1009 on Internet, 3-5 Nov. 2009. 1011 [BLIND] Dacheng Zhang, Miika Komu, "An Extension of HIP Base Exchange 1012 to Support Identity Privacy", draft-zhang-hip-privacy-protection-00, 1013 work in progress, March 2010. 1015 9 Annex I 1017 This annex provides a sample code, for NFC RFIDs working at 13.56 Mhz 1018 and implementing a Java Virtual Machine. 1020 9.1 Binary Interface with HIP RFIDs 1022 According to the ISO 7816 standards, embedded RFID applications are 1023 identified by an AID attribute (Application IDentifier) whose size 1024 ranges between 5 and 16 bytes. 1026 Commands exchanged between RFIDs and readers are named APDUs and are 1027 associated with a short prefix, whose size is usually 5 bytes 1028 referred as CLA, INS, P1, P2, P3. 1030 In our sample we choose an arbitrary value for the AID 1031 (11223344556601, in hexadecimal representation) and a unique command 1032 CLA=00, INS=C2, P1=00, P2=00. The P3 byte is set to null in order to 1033 trig the RFID (which resets its state machine and returns the I1 1034 packet, or a non null value when it pushes the R1 packet. 1036 9.3 Exchanged data 1038 The reader selects the embedded HIP-RFID application. 1039 >> 00 A4 04 00 07 11 22 33 44 55 66 01 1040 << 90 00 1042 The reader trigs the first packet I1-T. 1044 >> 00 C2 00 00 00 1046 The RFID delivers the R1-T packet. 1048 << 3B 04 40 11 00 00 00 00 A3 12 9D 5E 28 16 67 4F FC 4F A8 08 4E 30 1049 55 E8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90 00 1051 The reader forwards the R1-T packet to the HIP RFID. 1053 >> 00 C2 00 00 58 3B 0A 41 11 00 00 00 00 00 00 00 00 00 00 00 00 00 1054 00 00 00 00 00 00 00 A3 12 9D 5E 28 16 67 4F FC 4F A8 08 4E 30 55 E8 1055 04 00 00 20 00 06 68 46 95 15 02 10 32 C2 B7 8D 13 E7 53 F6 25 0F 09 1056 AD 7A BD 00 00 00 00 00 00 04 02 00 10 00 06 00 01 00 00 00 00 00 00 1057 00 00 1059 The RFID produces the I2-T packet. 1061 << 3B 13 40 11 00 00 00 00 A3 12 9D 5E 28 16 67 4F FC 4F A8 08 4E 30 1062 55 E8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 02 00 10 00 1063 06 00 01 00 00 00 00 00 00 00 00 04 00 00 20 00 06 71 3A DD 19 C4 CB 1064 59 D4 AF D0 2B FD F9 7C 2F 8A D1 23 32 E0 00 00 00 00 00 00 04 04 00 1065 20 00 06 70 DA C1 F7 0B CA 63 15 57 CB D7 AA 66 A9 FD 36 B4 1F DB E3 1066 00 00 00 00 00 00 04 06 00 20 00 06 A6 A7 00 67 5D FD A9 2F 3E 5C 00 1067 D6 B0 8A 55 A2 99 D8 86 79 00 00 00 00 00 00 90 00 1068 9.3 Javacard code sample 1070 package hiprfid; 1072 // Author Pascal Urien 1074 import javacard.framework.*; 1075 import javacard.security.* ; 1077 public class rfid extends Applet 1078 { 1079 final static byte SELECT = (byte)0xA4 ; 1080 final static byte INS-HIP = (byte)0xC2 ; 1082 final static short R-T = (short)0x400 ; 1083 final static short HIP-T-TRANSFORM = (short)0x402 ; 1084 final static short F-T = (short)0x404 ; 1085 final static short Signature-T = (short)0x406 ; 1086 final static short ESP-Transform = (short)0x408 ; 1087 final static short ESP-Info = (short)0x40A ; 1089 final static short ALIGN = 8; 1090 final static short len-r2 =(short)20; 1091 final byte[] algo1 = {(byte)0x00,(byte)0x01,(byte)0x00,(byte)0x00 }; 1093 final byte[] ct1 = { 1094 (byte)0x00,(byte)0x00,(byte)0x00,(byte)0x01, 1095 (byte)'T',(byte)'y', (byte)'p',(byte)'e', 1096 (byte)' ',(byte)'0',(byte)'0',(byte)'0',(byte)'1', 1097 (byte)' ',(byte)'k',(byte)'e',(byte)'y' }; 1099 final byte[] ct2 = { 1100 (byte)0x00,(byte)0x00,(byte)0x00,(byte)0x02, 1101 (byte)'T',(byte)'y',(byte)'p',(byte)'e', 1102 (byte)' ',(byte)'0',(byte)'0',(byte)'0',(byte)'1', 1103 (byte)' ',(byte)'k',(byte)'e',(byte)'y' }; 1105 MessageDigest sha1=null ; 1106 RandomData rnd=null; 1107 byte[] DB =null; 1108 final static short DBSIZE=(short)200; 1109 final static short off-myHIT = (short)0 ; 1110 final static short off-rHIT = (short)16 ; 1111 final static short off-R1 = (short)32 ; 1112 final static short off-R2 = (short)64 ; 1113 final static short off-kaut = (short)96 ; 1114 final static short off-k = (short)128 ; 1115 final static short off-FT = (short)160 ; 1116 final byte[] HEADER= { 1117 (byte)0x3b,(byte)0x04,(byte)0x40,(byte)0x11, 1118 (byte)0x00,(byte)0x00,(byte)0x00,(byte)0x00 }; 1120 final byte[] MyEPCCODE = { 1121 (byte)0x01,(byte)0x23,(byte)0x45,(byte)0x67,(byte)0x89, 1122 (byte)0xab,(byte)0xcd,(byte)0xef,(byte)0xcd,(byte)0xab }; 1124 public void init(){ 1125 try { sha1=MessageDigest.getInstance(MessageDigest.ALG-SHA,false);} 1126 catch (CryptoException e){sha1=null;} 1128 try { rnd = RandomData.getInstance(RandomData.ALG-SECURE-RANDOM);} 1129 catch (CryptoException e){rnd=null;} 1131 DB = JCSystem.makeTransientByteArray(DBSIZE, 1132 JCSystem.CLEAR-ON-DESELECT); 1134 } 1136 public short GetAttOffset(byte[] pkt, short off, short len,short att) 1137 { boolean more=true; 1138 short type=(short)0; 1139 short tl=(short)0; 1141 if (len <= (short)40) return (short)-1 ; 1143 while (more) 1144 { type = Util.getShort(pkt,off) ; 1145 tl = Util.getShort(pkt,(short)(off+2)); 1146 if (type == att) return off ; 1147 off =(short)(off+tl) ; 1148 if (off >= (short)(off+len))more=false; 1149 } 1151 return -1; 1152 } 1154 public static short GetPadLength(short size) 1155 { 1156 if ( (short)(size % ALIGN) == (short)0) return (short)0; 1157 return (short)(ALIGN - size % ALIGN ); 1158 } 1160 public static short Set_Att(short att, byte[] ref-att, short off-att, 1161 short len-att, byte[] pkt, short off) 1162 { 1163 short tl = (short) (len-att + 6) ; 1164 short tp = GetPadLength(tl) ; 1166 tl= (short) (tp+tl); 1168 Util.setShort(pkt,off,att) ; 1169 Util.setShort(pkt,(short)(off+2),tl); 1170 Util.setShort(pkt,(short)(off+4),tp); 1172 if (ref_att != null) 1173 Util.arrayCopy(ref-att,off-att,pkt,(short)(off+6),len-att); 1174 else 1175 Util.arrayFillNonAtomic(pkt,(short)(off+6),len-att,(byte)0); 1177 if (tp != (short)0) 1178 Util.arrayFillNonAtomic(pkt,(short)(off+6+len-att),tp,(byte)0); 1180 return tl ; 1181 } 1183 public void process(APDU apdu) throws ISOException 1184 { 1185 short len=(short)0, readCount=(short)0; 1186 short off=(short)0,pad=(short)0,len-r1=(short)0; 1187 short size=(short)0; 1189 byte[] buffer = apdu.getBuffer() ; // CLA INS P1 P2 P3 1191 byte cla = buffer[ISO7816.OFFSET_CLA]; 1192 byte ins = buffer[ISO7816.OFFSET_INS]; 1193 byte P1 = buffer[ISO7816.OFFSET_P1] ; 1194 byte P2 = buffer[ISO7816.OFFSET_P2] ; 1195 byte P3 = buffer[ISO7816.OFFSET_LC] ; 1197 switch (ins) 1198 { 1199 case SELECT: 1200 size = apdu.setIncomingAndReceive(); 1201 return; 1203 case INS_HIP: 1205 if (P3 == (byte)0) 1206 { 1207 rnd.generateData(DB,off_myHIT,(short)16); 1208 Util.arrayCopy(HEADER,(short)0,buffer,(short)0,(short)8); 1209 Util.arrayCopy(DB,off-myHIT,buffer,(short)8,(short)16) ; 1210 Util.arrayFillNonAtomic(DB,(short)24,(short)16,(byte)0) ; 1211 apdu.setOutgoingAndSend((short)0,(short)40) ; 1212 break; 1213 } 1214 else 1215 { 1216 size = apdu.setIncomingAndReceive(); 1217 len = Util.makeShort((byte)0,buffer[6]); 1218 len = (short)(len << 3); 1219 len = (short)(len+(short)8) ; 1221 if (len != size) ISOException.throwIt(ISO7816.SW-DATA-INVALID) ; 1222 size = (short)(len-(short)40); 1224 // HEADER 00...08 1225 // HIT-S 08...24 1226 // HIT-D 24...40 1228 Util.arrayCopy(buffer,(short)13,DB,off_rHIT,(short)16); 1229 off= GetAttOffset(buffer,(short)45,size,R-T); 1230 if (off==(short)-1) ISOException.throwIt(ISO7816.SW-DATA-INVALID) ; 1231 len = Util.getShort(buffer,(short)(off+2)); 1232 pad = Util.getShort(buffer,(short)(off+4)); 1233 len = (short)(len-pad-6); 1235 len-r1=len; 1236 Util.arrayCopy(buffer,(short)(off+6),DB,off-R1,len); 1237 off= GetAttOffset(buffer,(short)45,size,HIP-T-TRANSFORM) ; 1239 if (off==(short)-1) ISOException.throwIt(ISO7816.SW-DATA-INVALID) ; 1240 len = Util.getShort(buffer,(short)(off+2)); 1241 pad = Util.getShort(buffer,(short)(off+4)); 1242 len = (short)(len-pad-6); 1244 // algo=Util.getShort(buffer,(short)(off+6) 1245 rnd.generateData(DB,(short)(off-R1+len-r1),len-r2); // r1 || r2 1247 Util.arrayCopy(MyEPCCODE,(short)0,buffer, 1248 (short)0,(short)MyEPCCODE.length); 1250 hmac(DB,off_R1,(short)(len-r1 + len-r2), 1251 buffer,(short)0,(short)MyEPCCODE.length, 1252 sha1, 1253 DB,off-k); 1255 Util.arrayCopy(ct1,(short)0,buffer,(short)0,(short)ct1.length); 1257 hmac(DB,off_k,(short)20, 1258 buffer,(short)0,(short)ct1.length, 1259 sha1, 1260 DB, off-FT); 1262 Util.arrayCopy(ct2,(short)0,buffer,(short)0,(short)ct2.length); 1263 hmac(DB,off-k,(short)20, 1264 buffer,(short)0,(short)ct2.length, 1265 sha1, 1266 DB, off-kaut); 1268 Util.arrayCopy(HEADER,(short)0,buffer, 1269 (short)0,(short)HEADER.length); 1271 Util.arrayCopy(DB,off-myHIT, buffer, (short)8,(short)16); 1272 Util.arrayCopy(DB, off-rHIT, buffer,(short)24,(short)16); 1274 off=(short)40; 1275 len = Set-Att(HIP-T-TRANSFORM,algo1, 1276 (short)0,(short)algo1.length,buffer,off); 1277 off = (short)(off+len); 1278 len = Set-Att(R-T,DB,(short)(off-R1+len-r1),len-r2,buffer,off); 1279 off = (short)(off+len); 1280 len = Set-Att(F-T,DB,off-FT,(short)20,buffer,off); 1281 off = (short)(off+len); 1282 len = Set-Att(Signature-T,null,(short)0,(short)20,buffer,off); 1283 size= (short)(off+len); 1284 buffer[1] = (byte) (size >>3); 1286 hmac(DB,off-kaut,(short)20, 1287 buffer,(short)0,size, 1288 sha1, 1289 buffer,(short)(off+6)); 1291 apdu.setOutgoingAndSend((short)0,size); 1292 break; 1293 } 1295 default: 1296 ISOException.throwIt(ISO7816.SW-INS-NOT-SUPPORTED); 1297 } 1299 } 1301 protected rfid(byte[] bArray,short bOffset,byte bLength) 1302 {init(); 1303 register(); 1304 } 1306 public static void install( byte[] bArray, short bOffset, byte 1307 bLength ) 1308 { 1309 new rfid(bArray,bOffset,bLength); 1310 } 1311 public boolean select() 1312 { 1313 return true; 1314 } 1316 public void deselect() 1317 { 1318 } 1320 Author's Addresses 1322 Pascal Urien 1323 Telecom ParisTech 1324 23 avenue d'italie, 75013 Paris, France 1326 Email: Pascal.Urien@telecom-paristech.fr 1328 Gyu Myoung Lee 1329 Telecom SudParis 1330 9 rue Charles Fourier, 91011 Evry, France 1332 Email: gm.lee@it-sudparis.eu 1334 Guy Pujolle 1335 Laboratoire d'informatique de Paris 6 (LIP6) 1336 4 place Jussieu 1337 75005 Paris France 1339 Email: Guy.Pujolle@lip6.fr