Secure UHF Tags with Strong Cryptography Development of ISO/IEC 18000-63 Compatible Secure RFID Tags and Presentation of First Results
Walter Hinz, Klaus Finkenzeller and Martin Seysen Giesecke & Devrient GmbH, Prinzregentenstrasse 159, 81677, Munich, Germany
Keywords: UHF Tag, Public Key Cryptosystem, Rabin, Montgomery.
Abstract: This paper presents a concept for an UHF tag supporting cryptographically strong authentication which is based on the Rabin-Montgomery public key cryptosystem in accordance with the framework of ISO/IEC 29167-1. It uses an easily computable long integer square operation for the public key encryption of a tag ID record. Only a legitimate interrogator who is in possession of the private key can decrypt this message and retrieve the authentic tag ID. A working prototype based on a standard FPGA is shown which demonstrates the feasibility of the proposed cryptographic function.
1 INTRODUCTION
Backscatter-coupled RFID systems are being used in a large number of applications such as logistics, supply chain, warehouse management, retail stores, and similar applications. Backscatter-coupled RFID systems are mainly operated in the UHF frequency ranges 868 MHz Figure 1: Principle of UHF RFID. (Europe) and 915 MHz (USA, Asia). These UHF- RFID Systems are primarily covered by the standard Another class of transponder uses an on-board (ISO/IEC 18000-6, 2010). battery to supply the silicon chip with energy. The The majority of the applications mentioned operating range of these battery assisted passive above operate according to ISO/IEC 18000-6 (BAP) tags is mainly limited by the interrogator’s Type_C (ISO/IEC 18000-6C will be published as ability to receive and detect the modulated backscat- Part -63 in the future (ISO/IEC FDIS 18000-63)) ter signal from the transponder, in addition to its which describes the physical characteristics and pro- own high-power signal. Typical maximum operating tocol behaviour of the so called “Electronic Product distances of BAP transponders are up to 25 m. Code”, the EPC. This standard is designed for the Despite of these range limitations, there are real fast detection of huge numbers of transponders in time locating systems (RTLS), which are able to the field at the same time, and for a small amount of detect a locally powered transponder from a distance data to be transferred between an interrogator and a of 100 m and above. These systems are much more tag. sensitive than RFID readers, because they do not A typical transponder is field-powered and uses suffer from the strong signal carrier emitted at the modulated backscatter signals to transmit data back same antenna, as an interrogator does. to the interrogator. The operating range of these pas- With special equipment like communication re- sive (or field-powered) transponders is mainly lim- ceivers and high gain directional antennas, there is ited by the ability to get sufficient power from the always the possibility to eavesdrop a communication field into the transponder in order to operate the sili- between an UHF-RFID interrogator and a tran- con chip. Typical maximum operating distances of sponder from a considerable distance up to several such passive transponders are between 3 and 10 m. hundreds of meters.
Hinz W., Finkenzeller K. and Seysen M.. 5 Secure UHF Tags with Strong Cryptography - Development of ISO/IEC 18000-63 Compatible Secure RFID Tags and Presentation of First Results. DOI: 10.5220/0004194800050013 In Proceedings of the 2nd International Conference on Sensor Networks (SENSORNETS-2013), pages 5-13 ISBN: 978-989-8565-45-7 Copyright c 2013 SCITEPRESS (Science and Technology Publications, Lda.) SENSORNETS2013-2ndInternationalConferenceonSensorNetworks
In many cases it is not desirable that an object or In the remainder of this paper a concept for a se- subject carrying an RFID tag can be identified or cure UHF tag with strong cryptography will be pre- tracked, either with a standard RFID interrogator or sented in section 2. As the required protocol exten- by eavesdropping the communication between the sion is not yet available, a first prototype working tag and an interrogator. For example, whenever the with currently defined standards, and first results are tag is associated with a person, privacy rules apply. shown in sections 3 and 4. Furthermore, it could be possible to transmit strong It is paramount that the secure RFID tag shall be backscatter signals with forged information which fully compatible with ISO/IEC 18000-6, such that superimpose the original data sent by the tag. interrogators conforming to this standard can be con- Therefore, it is desirable to have a secure variant tinued to be used. The proposed protocol is designed of RFID, where cryptographic functions allow only along the command structure which is currently be- a legitimate interrogator to identify a tag, to impede ing discussed in the context of security suites in eavesdropping and to prevent the infiltration of false ISO/IEC WD 29167. information. Especially because suitable interrogators are not yet available, a preliminary workaround protocol had to be used to achieve first results.
2 PROTOCOL CONCEPT FOR A SECURE RFID TAG
2.1 General Concept
In accordance with WD 29167-1 we developed a secure protocol for authentication and identification of a tag by use of the Authenticate command as de- Figure 2: Technology leap with Secure UHF. fined in the working draft. Within this framework we defined a specific format for the payload field. In For inductively coupled RFID devices, mainly the following the content of this payload is ex- operated in the 13.56 MHz RF frequency range, plained. cryptographic functions and even complex smart The authentication protocol comprises the en- card operating systems (SCOS) are available for cryption of a message by the tag containing the tag’s nearly one and a half decades now. Inductively cou- identification information. In order to guarantee the pled RFID devices however are operated close to the freshness of the encrypted message, random num- reader, typically at a distance of up to 10 cm. Due to bers originating both from the interrogator and the the strong coupling between the reader and the tag’s tag are also included. Because the confidentiality of antenna inductive RFID systems have sufficient a key stored in the tag cannot be assured, it is neces- power to operate complex microprocessors even sary to employ a public key cryptosystem with the with cryptographic co-processors. UHF RFID tags public key stored in the tag(s) and the private key on on the other hand have to be operated with about 10 the interrogator side. to 100 times less power. Therefore, UHF RFID tags In the following, the particular cryptosystem and in the past provided no cryptographic security at all the format of the plaintext message is explained. In (Finkenzeller, 2012). the context of public key cryptosystems the message Over the years however, silicon technology con- is considered as a long integer number M, which tinuously improved, resulting in ever-decreasing constitutes the payload field as defined in WD power consumption. In the recent years a point has 29167-1. been reached, where cryptographic functions on UHF RFID tags seem to become feasible. For that 2.2 The Rabin Cryptosystem reason, ISO/IEC JTC1/SC31 has recently started standardisation activities to provide crypto suites for For the authentication part we used the Rabin public future UHF RFID tags. The results will be published key cryptosystem which is based on the modular in a new standard series ISO/IEC 29167 with differ- multiplication of long integers (Rabin, 1979). A step ent parts, which are currently available in first work- by step explanation of the algorithm can be found in ing drafts (WD). (Menezes et al., 1997).
6 SecureUHFTagswithStrongCryptography-DevelopmentofISO/IEC18000-63CompatibleSecureRFIDTagsand PresentationofFirstResults
A proof that breaking a particular encryption r n r (11) scheme is as difficult as solving a computational problem which is believed to be difficult, is a desir- s (y p p mq yq q mp ) mod n (12) able property. The Rabin public key encryption s n s (13) scheme was the first example of provable security, because the problem of breaking it is computational- Which one of the four roots (±r, ±s) is the de- ly equivalent to factoring. sired clear text message M has to be determined by In order to generate a public key and the corre- searching for a specific characteristic, such as an sponding private key, two random and distinct embedded checksum or other redundant information. primes p and q of roughly the same size need to be generated. To keep the decryption algorithm simple, 2.3 Montgomery Multiplication we assume that these primes satisfy the congruence condition Modular reduction as in equation (3) is usually quite cumbersome to calculate for a microprocessor with p q 3 (mod4) (1) low capabilities, because of the division involved. Here p and q together constitute the private key The paper (Montgomery, 1985) proposes an alterna- while the product tive computation scheme which requires only multi- n p q plication. The cost of multiplication is much less (2) than that of division, especially if a hardware multi- is the public key. plier is available. The plaintexts in the Rabin encryption scheme Consider a residue R where R is a power of 2 are the integers 0 < M < n. The ciphertext C corre- and an odd modulus n 2k R . In other words, R sponding to M is defined as the square of the long a power of 2 which is larger than n. Usually k is a number M modulo n multiple of the word size w of the processor per- C M 2 modn (3) forming the hardware multiplication. For a suitable Rabin decryption thus means taking the modular R one calculates square root of cipher text C, C * M 2 R 1 modn (14) M C mod n (4) Without the cost for squaring M, the quantity C* 2 can be computed with (k/w) + O(k/w) multiplica- In the general case there is no efficient algorithm tions of w-bit numbers, and without any divisions, to find M. For a modulus n = p q, with p and q see (Montgomery, 1985) for details. Squaring M prime, the following roots can be determined: costs 0.5(k/w)2 + O(k/w) more multiplications, so 2 m C mod p (5) that in total we need 1.5(k/w) + O(k/w) multiplica- p tions of w-bit numbers. One should be aware that C*≠ C, and before we mq C modq (6) can proceed with calculating the roots, we have to By virtue of the congruence condition (1) the two undo the effect of the Montgomery multiplication roots are given by * 2 1 p1 C C R modn (M R )R modn (15) 4 (7) m p C mod p The final calculation needs, apart from approxi- q1 mately the double length operands, just one conven- 4 (8) mq C modq tional modular reduction, but this is made on the host system connected to the interrogator where By means of the extended Euclidian algorithm it computing power and space requirements should not is possible to determine integers yp and yq which pose any problem. satisfy the equation If the modulus n is chosen to satisfy the condi- tion y p p yq q 1 (9) n 1(mod2k / 2 ) (16) Finally four roots of C, namely +r, -r, +s, and -s, can be calculated by application of the Chinese Re- which means that about one half of the least signifi- mainder Theorem as cant bits of n (except for the last one) are zeroes, r (y p m y q m ) mod n (10) about one third of the necessary multiplications to p q q p evaluate equation (14) can be saved.
7 SENSORNETS2013-2ndInternationalConferenceonSensorNetworks
Figure 3: Identification message (before MIX).
Unlike modular reduction the Montgomery mul- data in order to provide the required total of 128 tiplication method does not guarantee that the result bytes. in equation (14) is actually smaller than the modulus Figure 3 shows the composition of the identifica- n, therefore a final reduction step may be necessary tion message described so far. If we used this ID which causes high computational load and leaks side message for encryption there would be some risk of channel information due to different timing with and leaking information, because to a large extent (the n without reduction. The probability for a modulus bytes signed tag ID) these data are static. The intro- overflow in equation (14) can be significantly re- duction of a MIX function neutralises this problem, duced by choosing the residual exponent k a bit larg- because it interleaves static and dynamic compo- er than actually required. In practical terms one se- nents. lects the exponent as k ≈ log2 n + d where d is a se- The following C-like pseudo code describes the curity parameter, so that k is a multiple of the tag operation of the MIX function: microprocessor hardware multiplier’s word length. for (i=0;;++i) { In our example we chose n = 1024 and d = 64 for get 5 bytes from signed ID; if out a 1616 multiplier unit, giving k = 1088 and R = 2k. of data, get random bytes; if (i == 10) break; get 1 byte from reader challenge; 2.4 The Identification Message get 5 bytes from signed ID; if out of data, get random bytes; The most important part of the identification mes- get 1 byte random as tag challenge; sage is the unique tag ID. In order to preserve its } append checksum; authenticity it is digitally signed before it is person- append 0x00; alised into the tag during production. The signature method is out of scope for these considerations; 2.5 Overall Message Flow however, for practical purposes one would choose an appropriate Elliptic Curve Cryptosystem (ECC), The overall message flow for a secure tag authenti- because the size has to fit into the tag authentication cation is as follows: message. First the interrogator generates a 10 byte random With the parameters chosen, the authentication challenge and sends it to the tag. message has a size of 128 bytes. To resolve the am- Then the tag processes the identification record biguity of the four possible square roots two bytes as described above, mixing the interrogator chal- are reserved for a checksum and the most significant lenge into the message and encrypting it according byte must contain 0x00. Only the root with the cor- to the Ramon-Montgomery scheme. The result is rect checksum will be processed by the interrogator. backscattered to the tag. This leaves 125 bytes for the actual ID content. The interrogator has to decrypt the message and As discussed earlier we need some random bytes find the correct root out of the four presented by the to guarantee the freshness of the encrypted ID mes- algorithm. Then it has to roll back the effects of the sage and to prevent the recycling of an eavesdropped MIX function and check whether the returned inter- ID record. We chose 10 random bytes to be contrib- rogator challenge is identical to the one sent. This uted by the interrogator and another 10 bytes con- approves that the tag is in possession of the public tributed by the tag. key. After these considerations 105 bytes remain for Afterwards the interrogator investigates the the ID information. To gain flexibility in the size of signed ID record. If the signature can be verified the individual elements of the signed tag ID these with the public ECC key, the tag is identified and are TLV (tag-length-value) encoded. If the ID in- authenticated. The tag challenge can be preserved formation does not fill the whole space available, the for further processing, as it can authenticate the in- tag will insert the necessary amount of fresh random terrogator to the tag.
8 SecureUHFTagswithStrongCryptography-DevelopmentofISO/IEC18000-63CompatibleSecureRFIDTagsand PresentationofFirstResults
expecting an Authenticate command with payload for step 2. When the tag receives the first Authenti- cate command for step 2, it processes the command, sends the response and remains in TAM1.2 as long as there are authentication data bytes remaining to be sent. In TAM1.2 the interrogator sends as many Authenticate commands as required to fetch the entire authentication data produced by the tag. The interrogator indicates the length of the au- thentication cryptogram in the payload of the Au- thenticate command for step 1. The tag indicates the number of bytes still available to fetch in the pay- load of the response message. Whenever the tag receives an Authenticate command with payload for step 1, it resets all varia- bles, transitions to TAM1.1 and starts processing the command. The tag transitions to Init state once it has sent out the last fragment of authentication crypto- gram. In case of failure during one of the steps of the protocol, the crypto suite transitions to the ‘Init’ state. When Rabin-Montgomery encryption and I/O are overlapping in the tag there can be a couple of short response packets from the tag, the exact behav- iour being dependent on tag firmware optimization. Figure 4: Tag state diagram. In any case, the final packet carries a success status word in its payload or an error indicator, if applica- 2.5.1 Tag State Diagram ble.
The logical process flow as developed above is now 2.5.2 Tag Authentication embedded into the framework as defined in WD 29167-1. In accordance with the working draft the The sequence of exchanged messages for tag authen- tag can assume the states as depicted in figure 4. tication is depicted in figure 5. The first message A sequence of Authenticate commands needs to includes a random challenge generated by the inter- be sent to the tag to complete a full tag authentica- rogator and sent to the tag. The tag response is an tion protocol. For a successful authentication the encrypted message that only the legitimate interro- entire sequence needs to be executed successfully. gator can decrypt, since it possesses the necessary The crypto suite state transitions triggered by the private key. authentication payloads are summarized in the next subsection below. State transitions and tag responses are according to the payloads of the Authenticate command sent by the interrogator. The processing of the Authenticate command may include generation of an authentication crypto- gram that will be returned in the tag’s response; the tag may also return some buffered data. Because the Figure 5: Message exchange for tag authentication. authentication protocol produces the output data consecutively in the correct order, it is advantageous In Step 1, the interrogator challenge is delivered to split the response in small pieces and to return to the tag. This message is used to request the tag to these pieces in parallel to the ongoing calculation. perform authentication. The response to this mes- After power-up the tag transitions to the ‘Init’ sage returns only the number of bytes to expect. In state. Once the tag receives an Authenticate com- Step 2, the interrogator retrieves the data fragments mand with payload for step 1, it processes the com- by chaining further Authenticate commands and mand, sends the response and transitions to TAM1.1 responses. Once the interrogator has fetched the en-
9 SENSORNETS2013-2ndInternationalConferenceonSensorNetworks
tire authentication record it is able to authenticate 2.6 Tag Life Cycle and Key the tag. Management If the tag receives a message that is not formatted as described in the following section it shall respond We will now briefly discuss aspects of the tag’s life with an error code and transition to ‘Init’ state. cycle, the key management, and the roles involved. In figure 6 we can see the System Integrator and the 2.5.3 Authentication Command Tag Issuer shown as different roles. In this scenario the System Integrator owns the asymmetric key pair The authentication is performed in two distinct KE, KD (the RAMON encryption and decryption steps. In step 1 of the Authenticate command the keys), marked with blue and red colour, respectively interrogator sends a 10 byte random challenge to the (in b/w print these keys show up as grey and dark tag as indicated in the specification of the cipher. grey). The System Integrator hands over the public As the tag cannot process the authentication key KE to the Tag Issuer. within the response timeout, it answers with a mes- Now the Tag Issuer produces a couple of tags sage indicating the expected size of the Ramon- with uniquely generated tag IDs and signs them with Montgomery encrypted cipher test. The tag assumes its private signature key KS. The signature key pair state TAM1.1 and begins the calculation of the ci- is marked with light yellow colour (or light grey). pher. Note that the generation of tag ID signatures is op- In order to fetch the result, the interrogator issues tional. In each tag the Tag Issuer stores the (signed) step 2 of the Authenticate command after some tag ID and the Ramon encryption key KE. No secret time. The tag assumes state TAM1.2 and responds key needs to be stored in the tag. with the first fragment of the resulting message, to- In addition the Tag Issuer gives the signature gether with an indication of the number of bytes verification key KV and a list of (signed) tag IDs to missing. The size of the fragment returned is deter- the System Integrator. Now the System Integrator mined by the progress of message calculation and can verify the authenticity of this ID list. the maximum which can be transferred in a single The System Integrator sets up Interrogator sites message. with a secure store containing the tag IDs and the If there are message bytes remaining in the tag, private RAMON decryption key KD. Thus the Inter- the interrogator waits a while and then repeats Au- rogator can decrypt the RAMON messages, identify thenticate for step 2 until the response from the tag the tag and eventually authenticate it if the signature indicates that the message is complete and that no matches. more data is available from the tag. Now the interro- gator begins with message processing.
Figure 6: Tag Life Cycle and Key Management.
10 SecureUHFTagswithStrongCryptography-DevelopmentofISO/IEC18000-63CompatibleSecureRFIDTagsand PresentationofFirstResults
3 PRELIMINARY PROTOTYPE that purpose. The attached device is represented by a Spartan 6 The authentication protocol specified so far requires FPGA which is located on a suitable evaluation modified tags which support the secure authentica- board where the connections to the external world tion procedure, but it also requires UHF interroga- are provided. The whole setup is shown in figure 7. tors which implement the Authenticate command Within the FPGA the state machine for an that is still in the standardisation process. However, ISO/IEC 18000-6 Type C compliant tag is replicat- such an interrogator is currently not available. ed, but with some modifications which facilitate the For that reason it is necessary to emulate the be- implementation of the secure functions presented in haviour of the secure UHF tag on hardware which is this paper compatible with the current ISO/IEC 18000-6 Type In the FPGA prototype all memory is provided as C standard and use commands which are available in non-persistent RAM. this standard. In order to achieve maximum flexibility in the 3.2 Add-ons for Security Functions implementation of cryptographic functions we de- cided to extend a standard state machine controlled The additional processing elements represented in UHF tag with a microprocessor. Both units are the FPGA comprise a Texas Instruments MSP430X closely coupled with shared volatile memory which compatible CPU together with a couple of periph- permits the microcontroller to receive messages via erals which are also compatible with the original the UHF channel and to return responses. peripherals to some extent. The most important one of these peripherals for our purpose is a hardware 3.1 Hardware Description multiplier capable of calculating a 32 bit result of a 16 16 bit integer multiplication within one clock In order to provide a smooth migration path we cycle. By using the multiply-add mode of this multi- started with an already existing standard UHF tag. plication unit it is possible to implement the long This device, when mounted on a PCB, can com- integer arithmetic functions required for Public Key municate its digital data stream to an external device cryptography in a very efficient way. and can backscatter the data received from that de- Another valuable peripheral for strong cryptog- vice. Thus the function of the former UHF tag is raphy is an AES coprocessor capable of supporting reduced to an analogue front end (AFE). all the three standardised key sizes, i.e. 128, 129, The switch from autonomous mode of the tag to and 256 bits. AFE mode is made by means of a command se- Other peripherals comprise a timer and a couple quence sent to the tag’s state machine from the at- of free programmable port bits. One of these bits is tached device via an I²C bus specially provided for used to generate serial output which can be dis
Figure 7: FPGA board and analogue front end.
11 SENSORNETS2013-2ndInternationalConferenceonSensorNetworks
played in a terminal window on the controlling PC. fers a specified number of such words from The microprocessor itself is controlled through a adjacent locations. special USB-to-I²C interface from a debugger run- . For writing data from outside into the commu- ning on the PC. nication buffer the commands Write and The MSP430X currently runs at a clock rate of BlockWrite are provided in the standard. 1,25 MHz which is significantly below the maxi- There is an issue with BlockWrite though: as any mum speed for this processor architecture. The ISO/IEC 18000-6 Type C command has to be com- speed was chosen to achieve command execution pleted within 20 ms, this may be too short for writ- performance close to that when a final tag design has ing to an extended number of E²PROM cells within to operate in a power-limited environment. a single command. As standard tags normally use this memory type, they often do not support Block- 3.3 Tag-CPU Communication Write, or only with a length of just a single word. This situation is completely different for a RAM The tag (i.e. the part within the FPGA which is buffer. based on the ISO/IEC 18000-6 Type C state ma- Our prototype is currently confined to use chine) and the CPU are loosely coupled by means of BlockRead for reading from the tag and repeated a common memory buffer of 128 16-bit words Write for writing to the tag. which is within the address space of the tag’s state machine. Specifically, it is located within the TID 3.5 The Transport Protocol (tag ID) memory bank. The CPU can access (read and write) all the tag In the proposed preliminary setup any messages be- memory by means of a special peripheral memory tween the interrogator and the tag’s CPU have to be access controller which also solves the task of arbi- passed through the shared memory. In order to fa- tration in case of conflicting access attempts. The cilitate this transfer the transport protocol T=1 which access rules are simple: is widely used in the smart card environment was . After the CPU posted a request for a specific chosen. address, it has to wait for an interrupt which Although this protocol introduces some over- signals the access grant. head, it provides a couple of useful features, like . If the tag tries to access the memory while the consistency checking with repetition of messages if CPU has access, it is delayed until the CPU is necessary, buffer size negotiation, chaining of long done. This may sometimes lead to a timeout messages, and others. on the tag’s air interface. . In all other cases the tag state machine and the 3.6 The Application Protocol CPU may run independently. Whenever the tag writes to a specific address in- The application protocol layer is also taken from the to the TID bank, a specific interrupt is generated for smart card domain as specified in ISO/IEC 7816. In the CPU to signal that a command message was re- this standard an application protocol data unit ceived over the air interface. This mechanism facili- (APDU) comprises a class byte, an instruction byte, tates the CPU to stay in a power-save sleep state two parameter bytes, an optional length specification most of the time until it has to respond to an external followed by the indicated number of data bytes, and request. eventually an optional specification of the expected response size. This makes up a command message. 3.4 Over the Air Data Transfer Response messages comprise the response data, if any, followed by a two-byte status word. As we saw above any data from outside the CPU has In the ISO/IEC 7816 paradigm the smart card or to be passed across the communication buffer in the secure token or, in our case, the secure UHF tag al- TID bank. The ISO/IEC 18000-6 Type C standard ways takes the role of a server while the interroga- defines (sometimes optional) commands to serve tor, or rather the device which controls the interroga- this purpose. tor, takes the role of a client. Thus, during a message sequence, the secure UHF tag receives a command . For reading data from the communication buff- APDU, processes the command, and eventually re- er the Read and BlockRead commands are turns a response APDU. available. The first reads a single 16 bit word from a specific address while the latter trans-
12 SecureUHFTagswithStrongCryptography-DevelopmentofISO/IEC18000-63CompatibleSecureRFIDTagsand PresentationofFirstResults
3.7 Secure Messaging communication times. However, we do not expect to have buffers big enough to transfer the whole mes- Within the authentication method as proposed for WD sage within a single block. 29167-1 in a previous section, the confidential and The performance of the secure messaging tests authentic exchange of arbitrary data is not envisaged. was less satisfactory. This was due to the fact that a However, in some applications it is desirable to BlockWrite command with sufficient data length communicate in a secure manner which is known as was neither supported by our AFE nor by the UHF secure messaging. Basically there are two stages of reader firmware. Therefore, we had to fall back to an secure messaging which can be applied separately or appropriate number of Write commands which im- combined. posed a considerable time overhead. Thanks to the . Message Authentication: this ensures the in- AES coprocessor, the AES-based encryptions were tegrity of a message, No one other than the calculated with considerable performance as ex- originator can generate or alter such a message pected,. However, overall execution times were after a message authentication code (“MAC”) dominated by the communication. is attached to the message, nor can the origina- tor deny his authorship. The MAC is calculat- ed over that part of the message which is to be 5 CONCLUSIONS secured. . Message Encryption; this ensures the confi- As we expect the standardisation to take some time dentiality of a message. Only the originator we will continue to experiment with setups based on and the receiver of the message can see its the shared memory approach taken with the FPGA. clear content. For further evaluations and estimations on power consumption and operating range the FPGA should As mentioned, both security mechanisms can be be replaced with an ASIC implementing basically combined. In that case the state of the art requires the same functionality. applying the encryption first and message authenti- After the completion of ISO/IEC WD 29167 as a cation afterwards. standard and the availability of compatible readers we For both security mechanisms a number of cryp- will continue to implement this technology in order to tographic algorithms are available. In our prototype enhance the performance of secure UHF tags. we used AES-CBC-128 for the encryption and AES- CMAC- 128 for message authentication. This choice was based on the availability of coprocessor support for the AES crypto-primitive. REFERENCES Finkenzeller, Klaus, 2012: RFID Handbuch (RFID Handbook), Hanser Verlag, Munich, 6th edition, ISBN 4 RESULTS 978-3446429925, http://rfid-handbook.de ISO/IEC 18000-6, 2010: Information technology - Radio With the FPGA setup we were able to execute a se- frequency identification for item management - Part 6: Parameters for air interface communications at 860 cure authentication test suite comprising a Rabin- MHz to 960 MHz, International Organization for Montgomery authentication of the tag, followed by Standardization, Geneva, Switzerland an AES based mutual authentication, writing a data ISO/IEC FDIS 18000-63, 2012: Information technology - record with secure messaging (encrypted and au- Radio frequency identification for item management - thenticated), and then securely reading back the data Part 63: Parameters for air interface communications just written. at 860 MHz to 960 MHz Type C, International Or- With the microprocessor running at a clock rate ganization for Standardization, Geneva, Switzerland. of 1.25 MHz we obtained satisfactory results. Mendezes, Alfred J., van Oorschot, Paul C., Vanstone, Thanks to the integrated multiplication unit the Rab- Scott A., 1997: Handbook of Applied Cryptography, CRC Press, Inc., NewYork, ISBN 0-8493-8523-7. in-Montgomery authentication with a modulus of Montgomery, Peter L: 1985. Modular Multiplication with- 1024 bit size was performed within 134 ms. This out Trial Division. In Math. Computation, Vol. 44, does not include the time required to transmit the 1985, p. 519–521. result to the interrogator which takes more than Rabin, Michael O., 1979: Digitalized Signatures and Public- 330 ms. The buffer determines if the components Key Functions as Intractable as Factorization. In MIT- involved require the authentication message to be LCS-TR 212, MIT Laboratory for Computer Science, split into at least two fragments, which adds to the January 1979.
13