the Auto-ID Center [4] would uniquely identify each product, consisting ... automatic inventories. But on the ..... feasibility of a certificate management is available.
Hash-based Enhancement of Location Privacy for Radio-Frequency Identification Devices using Varying Identifiers Dirk Henrici and Paul Müller University of Kaiserslautern, Germany {henrici, pmueller}@informatik.uni-kl.de Abstract Radio-Frequency Identification Devices (RFID) may emerge as one of the most pervasive computing technologies in history. On the one hand, with tags affixed to consumer items as well as letters, packets or vehicles costs in the supply chain can be greatly reduced and new applications introduced. On the other hand, unique means of identification in each tag like serial numbers enable effortless traceability of persons and goods. But data protection and privacy are worthwhile civil liberties. This paper introduces a simple scheme relying on oneway hash-functions that greatly enhances location privacy by changing traceable identifiers on every read getting by with only a single, unreliable message exchange. Thereby the scheme is safe from many threats like eavesdropping, message interception, spoofing, and replay attacks.
1. Introduction RFID tags emerge as the successor of optical barcodes. Whereas the latter are typically only scanned during check-out at the cash desk, the contact-less readable RFID tags shall be the key element in automating the complete supply chain from manufacturing up to waste disposal. Other application fields like libraries [1], toll collect [2], and bank notes [3] are brought to mind as well. An “Electronic Product Code” (EPC) envisioned by the Auto-ID Center [4] would uniquely identify each product, consisting of manufacturer information, type of product, and a unique serial number [5]. This enables tracking of each item, for example for keeping automatic inventories. But on the other hand, products equipped with RFID tags containing unique identifiers enable tracking of persons by the tags they carry [6, 7]. Because of that, customers raised concerns that
recently even led to the boycott of a clothing maker [8]. In the popular press even “cradle-to-grave surveillance” scenarios are stated [9]. Already in 1948, the United Nations proclaimed in its “Universal Declaration of Human Rights” that “no one shall be subjected to arbitrary interference with his privacy,…” as a basic human right [10]. In consequence, security and privacy in RFID systems are an important aspect that needs particular attention. The most obvious solutions of removing the serial number and keeping only manufacturer and product type intact or even a complete “killing” of tags at checkout are not satisfactory [11]. In the first scenario, tracking is still possible examining the constellation of products; the second one prohibits legitimate applications, too, and does not render corporate espionage impossible as long as the tags are active. A more complex proposal is the “Hash Lock”approach. A tag does not reveal its information unless the reader has sent the right key being the preimage to the hash value sent by the tag. The scheme requires implementing cryptographic hash functions on the tag and managing keys on the back-end [12]. This is regarded as economic for the near future [13]. Unfortunately, the scheme offers data privacy but no location privacy since the tag can be uniquely identified by its hash value. Another drawback is that the key is sent in plain text over the forward channel which can be eavesdropped easily from a large distance. The extended scheme called “Randomized Hash Lock” [12] ensures location privacy but is not scalable for a huge number of tags since many hash-operations must be performed at the back-end and it additionally relies on the implementation of a random number generator in the tags to randomize tag responses. Such devices need sources for physical randomness so that the implementation is rather complex and expensive. Other approaches like “Blocker Tags” [11] prevent tags from being scanned to enhance consumer privacy. Below we present a simple to implement and to use scheme that is able to provide location privacy.
2. Hash-based ID variation
-
Relying on the same prerequisites as the “Hash Lock” (i.e. one-way hash function and key management at the back-end), we propose a scheme that not only provides data privacy but location privacy as well. The general idea is to change the ID of a tag on every read attempt in a secure manner. Secure means that attempts like eavesdropping, spoofing, modification, replay attacks, or man-in-the-middle attacks cannot compromise the scheme. In contrast to other approaches, if the data is additionally moved from the tag towards the back-end the reader/third party need not be trusted in any form. The methods used to accomplish the stated goals are one-way hash functions, transaction identifiers to counteract reply attacks, and reasoned use of random values generated at the back-end as well as a difference of transaction numbers so that the transaction numbers themselves cannot be employed for tracking purposes. As much computation and data storage as possible is moved to the back-end to keep tag costs low. The protocol is resilient to loss of messages. In the following a detailed description of the protocol is given. Afterwards the scheme is explained by means of an example.
-
Database-identifier (“DB-ID”) read only, optionally writable Current ID (“ID”) read/write Transaction number (“TID”) read/write Last successful transaction number (“LST”) read/write Additional fields for user data or a master key are conceivable but not required at all
The DB-ID depicts the database that is in charge of the tag. It could point directly to the database of the owner of the tag. But to conceal the owner, this database should favorably be operated by the manufacturer of the tag or an independent organization. All requests should be forwarded to the database of the tag-owner from there, additional “privacy proxies” in between are conceivable to prohibit traceability and to make parties anonymous if required. To keep focus on the scheme itself, the database of the manufacturer in which the tag owner is referenced (mapping of current ID to owner database) and the database of the tag owner are regarded as one component being denoted as “DB” in the following (see figure 1).
2.1. Preliminaries We define y = h(x) as a cryptographic one-way hash function [14]. Ideally, besides the function being difficult to invert, the output y should not reveal any substantial information on its preimage x. In fact, this is often assumed in practice without mathematical justification [15]. Hence, use of “Secure Keyed OneWay Hash Functions” [16] or “K-hash Functions” [17] should be considered for maximum security. However, standard heuristic hash functions sufficiently hide information in practice [13]. The proposed scheme uses identifiers with limited validity as source for keys thus limiting security implications further. Since the number of gates in RFID-tags must be kept as small as possible for keeping the cost per piece low, an efficient implementation for the hash function in hardware is required [18]. Besides the hash function, a suitable conjunction function y = conj (a, b) is needed. It will be depicted with the “◦”-sign in the following (like y = a ◦ b). A simple exclusive-or function is adequate for the purpose. Each RFID-tag needs to contain fields for the following entries:
Figure 1. Involved system components The DB needs to contain a table with the following entries for each record row: - Hash of current ID (“HID”), acting as primary index of the table - Current ID (“ID”) - Last transaction number (“TID”) - Last successful transaction number (“LST”) - Associated DB entry (“AE”) - A reference to tag data / user data (“DATA”) The transaction numbers and the AE have the purpose of counteracting replay attacks. Their manner of operation will be explained later on.
Figure 2. Message exchange
2.2. Initial Setup The data fields of the tag are initialized to the following values: The DB-ID is set according to the database which will be in charge of the tag. The ID is set to a random value. The TID and the LST are set to the same value which should be another random number. A corresponding row in the database must be created. The ID is set to the ID of the tag; the primary index HID is set to h(ID). The TID and LST fields get the value of TID/LST of the tag. The AE is not set since no associated entry exists initially.
2.3. Normal Operation A tag is singularized out of many as usual by any standard method like binary tree-walking or any other anti-collision protocol [11]. In this stage of operation a tag exposes no other information than the hash of its ID, namely h(ID), that is used for identifying and addressing the tag. When queried, the tag increases its transaction number (TID) by one and sends the following information (figure 2): h(ID) (if not already known to the reader out of the operation of the anti-collision protocol), its database-identifier (DB-ID), the hash h(TID◦ID), and the difference between its current transaction number and the number of the last successful transaction (ΔTID = TID – LST). In this message, h(ID) identifies the tag in the database DB-ID. h(TID◦ID) has the purpose of counteracting replay attacks: It changes in every read attempt and is checked by the legitimate receiver. Secondly, it authenticates the tag. Conjugating the TID with the current ID is not mandatory but may be useful if the number of bits used for TIDs is rather small. ΔTID is used at the legitimate receiver to recalculate the current TID used by the tag. Since it is only a difference with a value of always “1” if no error (i.e. loss or change of a message) has occurred, no information that could be utilized by an attacker for tracking the tag by its TID is revealed.
As the information got by the tag is of no use for the reader, the latter needs to forward the message to the database depicted by the DB-ID. In the database, the record with HID = h(ID) is selected. The stored last successful transaction number (LST) and the received ΔTID are added together, thus obtaining the current TID of the tag (TID*). Now the hash h(TID*◦ID) is calculated, if the value does not match the one in the message (h(TID◦ID)), the message is discarded. If the message proves to be valid so far the TID* and the stored TID are compared. If the TID* is not higher than the TID a reply attack is in progress and the message is discarded. If everything is fine the TID* is stored as TID in the record row and the message is processed further. Now a random number “RND” is created. With this number, a new ID (“ID*”) is generated performing ID* = RND◦ID. If an associated DB entry (AE) exists the ID field of this record row is updated to the ID* and its HID is updated to the hash h(ID*). Otherwise a new row is appended to the database inserting the ID* as ID and h(ID*) as HID and copying the reference DATA. The AE-entry of the row is updated to point to the other row and vice versa as well. The TID of the newly selected row is updated to the TID* value, its last successful transaction ID (LST) gets the same value. Now a reply message containing RND and a hash h(RND◦TID*◦ID) is created and send to the reader which forwards the message to the tag. The tag checks the hash. If it is not correct the message is discarded and no further action is taken. Otherwise the tag updates its stored ID to the value RND◦ID and sets its last successful transaction number (LST) to the TID value. Now the tag has a new ID whose hash h(ID) will be used as tag identifier at the next read attempt. Using the contents of the first message (h(ID), DBID, h(TID◦ID), ΔTID) as identifier and session key, the reader can query the database for the data it wants to gather. Arbitrary access restrictions might have been set up so that information about the tag is only revealed according to the identity and justifiable claim of the reader.
2.4. Example for the Scheme
3. Abnormal Operation and Attacks
For demonstration and for making the operation of the protocol clear, an example for normal operation is shown in this section. Lets assume we have a new tag with the values ID=14, DB-ID = “tagdb”, and TID = LST = 3.
Intercepting or blocking the request message is a denial-of-service attack preventing tag identification. This kind of attack is not inherent to the proposed scheme but an issue in any RFID-system. Loss, interception or blocking of the reply message results in preventing the tag ID from being changed but has no other implications. The tag will use its old ID in the next request which will match the unchanged table row in the database. A row in the database is never overwritten until the other entry has been addressed by the tag proving that one being currently valid and the one to be overwritten being obsolete. Errors in message transfer can be detected afterwards on the basis of a ΔTID value that is unequal to one. Suspiciously high values attract attention and counteractive measures can be taken. Replay attacks cannot compromise the scheme since the validity of messages is limited by means of the unique transaction numbers (TIDs). Any message of the tag that reaches the database renders all previous messages invalid. Further, the tag accepts only messages that are equipped with the current TID. Eavesdropping is no issue as well as long as an attacker is not able to gain a current ID and TID value by means of cryptanalysis. Therefore, as stated in the preliminaries, the hash function should be selected in such a way that no usable information upon its preimage is revealed. Spoofing is not possible as the tag and the owner authenticate themselves by knowing the current ID and TID value.
In the database “tagdb” there is an initial entry for h(14): HID ID TID LST AE DATA h(14) 14 3 3 N/A reference When queried by a reader, the tag will increment its TID value by one and send h(14) (i.e. h(ID)), tagdb (i.e. DB-ID), h(10) (i.e. h(TID◦ID) = h(4◦14)), and 1 (i.e. ΔTID = TID – LST = 4 – 3). Upon reception of the message at the database, the value TID* = LST + ΔTID = 3 + 1 = 4 is calculated. As h(TID*◦ID) = h(10) matches the value in the message and TID* = 4 is larger than the stored value TID = 3 the message is valid. The stored TID value is updated according to TID* and a new table row created since AE is not yet set. A random number RND is calculated, lets say 13. Now the new ID = 3 (i.e. ID* = RND◦ID = 13◦14) and HID = h(3) is stored in the new record row. The AE-field is updated in both rows so that they reference to each other. The TID* is stored in the TID field and in the LST field of the new row. With it all, the two table rows finally look like this: HID ID TID LST AE DATA h(14) 14 4 3 h(3) reference h(3) 3 4 4 h(14) reference The random value RND = 13 and the hash h(7) (i.e. h(RND◦TID*◦ID) = h(13◦4◦14)) is sent back to the tag. The tag verifies the hash value (RND is sent with the message, TID is 4, ID is 14) and on validity stores LST = 4 (i.e. TID) and ID = 3 (i.e. RND◦ID = 13◦14). Now the tag has a new ID and the LST value of the tag and the one in the database belonging to the new ID are in sync. Note that except for the time before the first update there are always two table rows for each tag in the database. The reason is that the updated row is invalid if the reply message from the database to the tag is lost or intercepted. Then in the next message exchange, the tag is further on referenced using the old table row and the invalid new row gets overwritten. The two rows always point to each other using the AE-field. After or within the explained message exchange, the reader can request the needed tag data from the database. The data is only disclosed according to the access restrictions of the database.
4. Further Security Considerations As long as there is no user data stored in the tag itself, securing these data and implementing a proper, secure access control mechanism is not an issue. Tracking an individual cannot be prevented employing the proposed scheme if traffic analysis (counting the number of items carried etc.) is used. But apart from that location privacy is enhanced considerably since no static, traceable IDs exist any more. An attacker can still prevent detection of a tag by blocking the communication or rendering the tag unusable. But this is not a flaw of the proposed scheme but a problem of RFID-systems themselves. If the tag’s current ID or its previous ID in combination with the corresponding LST value becomes known to an attacker he can imitate the tag or wipe out the link between the tag and the database rendering the tag unserviceable. Knowing a TID value is also an advantage for an attacker because guessing an LST value becomes quite simple.
Note that an attacker knowing a current ID value can employ it only as long as the scheme was not in operation twice or more successfully without eavesdropping. Afterwards the ID is completely useless. Knowing a TID or LST value without an ID is only useful for an attacker if he can track the tag or a group of tags physically. This is due to the fact that he needs to know or must be able to guess to which tag the value belongs.
5. Conclusion As stated above, the proposed scheme has a high inherent security rendering it a useful technique for many kinds of applications without relying on strong symmetric or even asymmetric encryption. Particularly the latter would be costly to implement and offers attackers many more opportunities for attacks [19] because of stored long term secrets (e.g. private key) employing various forms of attacks such as power or EM analysis [20]. Access control to data and changing ownership and other properties of a tag should be moved to the backend where plenty of computing power and the feasibility of a certificate management is available inexpensively [21]. In the back-end, security systems and access control schemes can be changed easily according to current requirements. The main benefit of the proposed scheme is its simplicity: It only requires a hash function in the tag and data management at the back-end. It offers a high degree of location privacy and is resistant to many forms of attacks. Further, only a single message exchange is required, the communications channel need not be reliable and the reader/third party need not be trusted, and no long-term secrets need to be stored in tags. Further, the scheme is compatible to the Electronic Product Code [5] promoted by the Auto-ID Center [4] if the EPC-value is stored in the database as tag data. Therefore we assume that the proposed scheme is advantageous: Albeit comparably simple to implement, it is enhancing location privacy greatly without restraining other applications. As consumers and organizations threatened by espionage are understandably concerned about traceability and surveillance, every gain of security and privacy at justifiable cost is worth the effort. As future work, we will extend the protocol with an additional, optional reply message from tag to DB. With such a message it can be assured that the ID of the tag was really changed. By issuing timestamps from the DB and including them in the message exchange and hash calculations, the scheme can be made usable for applications like access control.
6. References [1] Lindquist, M.: RFID in libraries – introduction to the issues, World Library and Information Congress: 69th IFLA General Conference and Council, 2003 [2] E-ZPass, Website, see http://www.ezpass.com [3] Yohida, J.: Euro bank notes to embed RFID chips by 2005, EE Times, 2001, available at http://www.eetimes.com/ story/OEG20011219s0016 [4] Auto-ID Center, see http://www.autoidcenter.com [5] Technology Guide, Auto-ID Center, available at http://www.autoidcenter.com/aboutthetech.asp [6] Black, J.: Playing Tag with Shoppers Anonymity, Business Week online, 2003, available at http://www.businessweek.com/technology/content/jul2003/tc 20030721_8408_tc073.htm [7] Garfinkel, S.: An RFID Bill of Rights, Technology Review, 2002, available at http://www.technologyreview.com/articles/garfinkel1002.asp [8] Consumer Group Calls for Immediate Worldwide Boycott of Benetton., Website, available at http://www.boycottbenetton.org/PR_030313a.html [9] McCullagh, D.: RFID tags: Big Brother in small packages, CNET, 2003, available at http://news.com.com/ 2010-1069-980325.html [10] United Nations: Universal Declaration of Human Rights, adopted and proclaimed by General Assembly resolution, 217 A(III), 1948 [11] Juels, A. et al.: The Blocker Tag: Selective Blocking of RFID Tags for Consumer Privacy, 10th ACM Conference on Computer and Communications Security, 2003 [12] Weis, S. et al.: Security and Privacy Aspects of LowCost Radio Frequency Identification Systems, First Intern. Conference on Security in Pervasive Computing (SPC), 2003 [13] Weis, S.: Security and Privacy in Radio-Frequency Identification Devices, MIT, 2003 [14] Bakhtiari, S. et al.: Cryptographic Hash Functions: A Survey, Technical Report 95-09, Department of Computer Science, University of Wollongong, 1995 [15] Canetti, R. et al.: Perfectly One-Way Probabilistic Hash Functions. 30th Annual Symposium on Theory of Computing, pages 131-140, 1998 [16] Berson, T. et al.: Secure, Keyed, and Collisionful Hash Functions, Technical Report SRI-CSL-94-08, SRI Int., 1994 [17] Bakhtiari, S. et al.: Keyed Hash Functions, Cryptography: Policy and Algorithms, E. Dawson and Jovan Golic (Eds), Lecture Notes in Computer Science, vol. 1029, pp. 201-214, Springer, 1996 [18] Sarma, S. et al.: Radio-Frequency Identification: Security Risks and Challenges, RSA Laboratories Cryptobytes, Vol. 6, No. 1, 2003 [19] Weingart, S.: Physical Security Devices for Computer Subsystems: A Survey of Attacks and Defenses, Cryptographic Hardware and Embedded Systems – CHES 2000, volume 1965, pages 302-317, Springer LNCS, 2000 [20] Agrawal. D. et al.: Advances in Side-Channel Cryptanalysis, RSA Cryptobytes Volume 6, No. 1, 2003 [21] Sarma, S. et al.: RFID Systems and Security and Privacy Implications, Workshop on Cryptographic Hardware and Embedded Systems, pages 454-470, Lecture Notes in Computer Science, 2002
