Radio Frequency Identification

Introduction
Radio Frequency Identification (RFID) devices have seen rapid adoption in recent years. RFID enabled a plethora of innovations across various industries, such as real-time inventory tracking in supply chain management. Implementations of the technology have gone far beyond the supply chain focus that had generated much hype for it in the last decade. The various uses of RFID devices have greatly influenced the landscape of the electronics industry as a whole.

Scenario and Assumptions
This report will cover an implementation of a Secure RFID Tag System for use in inventory management scenario in Company SEC. The company seeks to implement a secure RFID system so as to prevent unauthorized personnel from wirelessly collecting information from the RFID tags on Company SEC’s products.

This secure system must:
1. Prevent unauthorized RFID readers from collecting meaningful data from the Company SEC’s RFID Tags 2. Enable authentic RFID readers to detect rogue RFID tags that masquerade as authentic tags.

This project assumes the following conditions:
1. Company SEC has in place a secure database which contains the serial numbers of all the RFID tags in the company. The aspects of database security will hence not be covered. 2. Company SEC has in place a system that provides secure communication between RFID readers and the secure database aforementioned. We will therefore not cover aspects of secure communication between the simulated RFID reader and the databases. 3. Communication channel between RFID reader and tag will be considered as standard. Hence, we will merely simulate data transmission between RFID reader and tag. Focus will be placed on ensuring that unauthorized devices cannot decipher the contents of the data transmitted.

Security Concerns

Rogue RFID tags
Attackers looking to compromise Company SEC’s inventory management system can create tags that masquerade as authentic tags. These ‘fake’ tags could corrupt the supply-chain data or slow down the inventory system causing costly disruptions to business processes.

‘Eavesdropping’ with Unauthorized RFID readers
High-powered RFID readers can detect RFID tag data from several hundred meters away, which means that attackers can remotely ‘eavesdrop’ on RFID tag information of all tags inside Company SEC’s warehouses. Such information needs to be kept private as it would allow competitors to gain an unfair advantage over Company SEC, or thieves to know where the most valuable inventory is kept. RFID System Design

Figure 1: RFID System Design
Implementation

Key Initializer (RFIDInit.java)

Figure 2: Key Initializer GUI (RFIDInit.java)

This class creates a key for each RFID Tag Serial Number. It first reads directly from rfid-sn.txt and generates a random 128-bit key for each of the serial numbers. These keys, together with their corresponding serial number, are then written and stored in keys.txt.

RFID Tag (TagUI.java)

Figure 3: RFID Tag GUI (TagUI.java)

To enable the user to select a tag to be scanned, the tags are first retrieved from our backend database, keys.txt, and displayed on the user interface.

After the reader has scanned the tag, the tag receives the ciphertext C1 sent by the reader. The hash digest is then computed using ciphertext C1, its respective key and ciphertext C2. In our design, the ciphertext is computed using the SecureRandom class from the java.security package, whereas for the hash digest, it is computed using the DigestUtils class from the org.apache.commons.codec.digest package.

The following formula is applied:

Digest, R = SHA256(C1 + C2 + Key)*

*The Strings C1, C2 and Key are concatenated

After the hash has been computed, the hash digest R and ciphertext C2 is sent as a JSON object via a JMS Queue to the RFID Reader.

RFID Reader (ReaderUI.java)

Figure 4: RFID Tag and Reader GUI (ReaderUI.java) upon RFID Reader Scan

The scan is simulated when ‘Scan Tag’ button is clicked. In the process, the challenge to determine the identity of the tag is issued, as the reader sends a ciphertext C1 to the tag via a JMS Queue. Likewise, the ciphertext C1 is generated using the SecureRandom class from the java.security package.

The tag responds to the challenge by sending the computed hash digest R and C2 back to the reader. The reader then proceed to determine the identity of the tag using a method, getTagSerialNum, which takes in the ciphertext C1, ciphertext C2 and hash digest R as parameters. To find the serial number of the tag, the method iterates through each of the keys and applies the SHA256 hash function with the formula H (hash digest) = SHA256(C1 + C2 + Key). The key is found when hash digest R = H.

Backend Database

The serial number of the RFID Tags and their assigned keys are stored in a text file named keys.txt. This text file functions as our database containing the serial number and keys of the 1000 RFID tags. Each serial number of the RFID Tag and its respective key are comma delimited.

Communication between components
Java Message Service is used as a communication medium between the tag and reader. The tag sends C1 and the tag serial number via a JMS Queue to the reader,similarly, the reader sends C2 and the hash digest to the tag via a JMS Queue.

Security and Efficiency

Computational security of java.security.SecureRandom class
The SecureRandom class provides a computationally secure method of generating a random key. This class is able to generate keys from a set of 2^160 possible sequences, and is hence capable of generating keys up to 160 bits. We have decided to generate keys that are 128 bit, as attackers will need to make 2^127 guesses on average to be able to discover any key.

The java.util.Random class is not used as it is only able to generate keys from a subset of 2^48 possible keys. An attacker would hence be able to find the key by trial and error within 2^47 trials on average. This is not considered suitable for use in cryptography, as the maximum effective bit size is only 48 bits, which is not computationally secure. Keys generated using the Random class could possibly be discovered using standard computing power within a few days.

Another method of generating random keys is using the XORShift generator, created by George Marsaglia, which is able to produce keys from a subset of 2^64 possible number sequences. The 64 bit key size, while an improvement to java’s Random class, is still computationally insecure and insufficient in size for use in cryptography.

Quality of randomness
We use the “SHA1PRNG” implementation of the SecureRandom class.

This SecureRandom implementation is able to provide a high quality of randomness as it seeds itself internally using sources of entropy within the Operating System (OS) such as the CPU temperature or mouse pointer movement. This internal seeding occurs upon calling the nextBytes method after instantiation of the SecureRandom class. The randomness of the seed used is important as this implementation of SecureRandom’s psuedo-random number generator (PRNG) uses a “deterministic algorithm to produce a pseudo-random sequence”. This means that if one discovers the seed that was used to generate the pseudo-random keys, one would be able to predict the keys generated by the SecureRandom PRNG.

Likewise, PRNG implementations such as the java.util.Random class and the XORShift method also require seeding, from which the pseudo-random numbers are generated. However, java.util.Random obtains its seed from System.nanoTime, which is the number of nanoseconds elapsed since the system was turned on. This means that the bit size of the seed generated will be lower when the computer was just turned on. This is a weak source of entropy. Similarly, XORShift does not inherently like SecureRandom have access to high quality sources of entropy, and is dependent on the randomness of the seed supplied manually by the user. Hence, random keys generated by java.util.Random and XORShift have lower quality of randomness compared to our chosen SecureRandom implementation.

Efficiency of key generation
The SecureRandom class generates keys 20-30 times slower than java.util.Random class or the XORShift method. However, the slower performance is a necessary trade-off to obtain a high-quality, cryptographically secure key that other methods highlighted cannot provide. A high quality key is essential as this it enables this system to meet the security objectives discussed earlier. Attackers will not be able to create rogue tags without raising alarm, and unauthorized readers would not be able to decipher the information obtained by scanning an authentic tag.

Hash function implementation

Apache Commons Codec – DigestUtils
We utilise org.apache.commons.codec.digest.DigestUtils class found in the Apache Commons library to compute the hash digests required. The DigestUtils class contains operations that simplify common hashing tasks provided by java.security.MessageDigest, which helps in brevity of code.

Secure Hash Algorithm (SHA)
The SHA256 algorithm of the SHA-2 family is used to calculate the hash digest in both the RFID reader and RFID tag. SHA256 is selected as at time of writing, there is no known weakness to the algorithm, and it fully adheres to the standards of a hash functions to be used in cryptographic purposes. SHA256 generates a digest of 256 bits, which should require 2^255 guesses to find another String that evaluates to an identical digest. This large bit size makes it computationally secure.

Why SHA256?
SHA256 is chosen over the Message-Digest Algorithm (MD5), as weaknesses in the algorithm have been discovered. MD5 produces a 128 bit digest, which should theoretically take 2^128 trials to find another string with a matching digest (collision). However, it is found that one can reliably find collision in 2^40 steps, making the function disqualified as a cryptographically secure hash function as it needs to be “infeasible to find two different messages with the same hash”. Similarly, mathematical weaknesses have been identified in the SHA-1 algorithm, which have prompted migration away from SHA-1 in Government agencies in the USA.

SHA256 versus SHA512 efficiency
The SHA-2 family consists of several configurations of the same algorithm, each only differing in the bit size of the output digest. While SHA512 will output a larger 512 bit digest and theoretically provide higher security, we feel that SHA256 is more appropriate for a realistic simulation as computing a large hash digest will affect the response time of the tag being read. This issue is more significant in reality since RFID tag will likely have very weak computing power due to cost and hardware constraints.

Trade-offs and Weaknesses

Trade-offs
For the purposes of demonstration, we have made choices for the hash function and PRNG implementation based on the core security objectives of this secure RFID protocol implementation.

While the SecureRandom implementation requires higher computational power, the quality of randomness it brings is essential. Similarly, while SHA-1 and MD5 are computationally less intensive, their security weaknesses disqualify them as cryptographically secure hash functions. Finally, we choose from the SHA-2 family – SHA256 over SHA512 as the latter does not provide significant advantage over the former. Here, we place efficiency over security, as the RFID tag should save on computing power by generating a smaller but sufficiently sized digest.

Given more information on the RFID tag’s hardware capabilities, we would be more equipped to choose a suitable hash function and PRNG implementation. In reality, the computing power in the RFID tag may be too weak to perform the SHA256 hash and SecureRandom tasks outlined in this report.

Conclusion

Strength of the solution depends on real-world context
As aforementioned, we are given insufficient information of the RFID tag’s hardware capabilities. In addition, we do not know how many products this RFID implementation has to handle. These factors compel us to choose the strongest, cryptographically secure hash function, which may not be the most suitable solution. For example, if Company SEC has an extremely large number of products in its warehouse, and had to keep the cost of each RFID tag very low; forcing each RFID tag to compute a SHA256 digest and generate a key every time it is scanned is computationally intensive and probably lead to slow tag response time overall. Depending on the business requirements, this shortcoming may be unacceptable, which would render the whole solution completely ineffective.

Also, the assumptions made at the start of this report assume that other potential security risks such as the database in which the keys are stored, the wireless communication channel between RFID reader and tag, as well as communication between RFID reader and backend database are secure. These pieces are all critical to ensuring a secure RFID implementation.

In conclusion, we have brought forward a recommendation for a strong RFID implementation within the scope of this project. However, the robustness of an RFID implementation is not dependent only on ensuring that messages passed between RFID reader and tag is indecipherable by unauthorized devices. It also relies the effectiveness of security measures implemented for the databases, the network connecting the RFID reader to the database, and the radio frequency technology implemented in the Company SEC.

Bibliography

Claburn T., Hulme G. (2004) RFID’s Security Challenge. Retrieved on 12 March 2012 from http://www.informationweek.com/news/52601030?pgno=2

Coffey N. (n.d) Password-based encryption in Java: salt and key derivation. Retrieved on 18 March 2012 from http://www.javamex.com/tutorials/cryptography/pbe_salt.shtml

Coffey N. (n.d) The Java SecureRandom class. Retrieved on 15 March 2012 from
http://javamex.com/tutorials/random_numbers/securerandom.shtml

Coffey N. (n.d) XORShift random number generator. Retrieved on 15 March 2012 from http://javamex.com/tutorials/random_numbers/xorshift.shtml

Marsaglia G. (2003) Xorshift RNGs. Retrieved on 15 March 2012 from http://www.jstatsoft.org/v08/i14/

Oracle Java 6 SecureRandom API. Retrieved on 15 March 2012 from http://docs.oracle.com/javase/6/docs/api/java/security/SecureRandom.html

Apache Commons Digest Utils Documentation retrieved on 15 March 2012 from http://commons.apache.org/codec/apidocs/org/apache/commons/codec/digest/DigestUtils.html

Bogdanov A.,Leander G., Paar C. (2008) Hash Functions and RFID Tags: Mind the Gap. Retrieved on 1 April 2012 from http://www.iacr.org/archive/ches2008/51540279/51540279.pdf