How to secure RAIN RFID tags for retail applications

When having deployed RAIN RFID tags to enhance your operation, you don’t want to realise that suddenly large quantities of tags are not working anymore.

This is a scenario that is not unthinkable if the tags haven’t been protected properly. Because protection mechanisms aren’t enabled by default, everybody with a RFID reader is capable of changing the contents of those tags; or even destroy them.

The risk of this happening is of course relatively small, but the impact would be disastrous. Receiving items in the DC will fail due to high levels of ‘missing items’, stock counts in the store would be inaccurate and the check-out process would slow down due to the fall back to barcodes. Preventing this is therefore of utmost importance, and the RFID standards (GS1 EPC Gen2v2) of course have capabilities of doing so. There are various mechanisms in place to prevent changes to programmed RFID tags.

However, making it impossible to change anything on the RFID tags is in direct conflict with the need for consumer privacy features: the ability to kill a tag — or more subtle: reduce the reading distance or hide the unique number in a tag are critical features. Therefore, a good balance needs to be stricken between security and privacy.

making it impossible to change anything on the RFID tags is in direct conflict with the need for consumer privacy features

This blog will learn you about the security and privacy capabilities of RAIN RFID and the best practises around using them.

Mechanisms for security: locking and passwords

There are two mechanisms for securing tags that are closely interrelated. They are:

• Passwords: a password is needed to execute certain actions
• Locking: defining what is possible with and without password

RAIN RFID tags have two passwords:

• Access password: used for (preventing) reading and writing specific memories in the chip
• Kill password: used for (preventing) killing the chip

Not all chips have passwords, as this is not mandatory according to the standard. An example: the Impinj Monza R6 has no access and kill password, which means that the chip cannot be killed or password-protected for writing. The Monza R6-P and R6-A however do have kill and access passwords. The lock command is mandatory in the standard.

Using the ‘lock’ command, you can define the behaviour of the chip in relation to the passwords. Just writing passwords doesn’t do anything — they need to be activated by ‘locking’ tags.

There are four possible configurations when using the lock command:

• You are able to write the memory — even without access password
• You are able to write the memory, when you provide the access password
• You are never able anymore to write to the memory — even when you have the access password
• You are always able to write to the memory — and you are never able to change that anymore or protect that with a password

The configuration can be defined for each memory area: EPC memory (where the product information and serial is stored) kill password, access password, etc. Of course, when the password is write protected, it is also read protected: otherwise everybody would be able to retrieve the password in an easy way. The EPC memory can not be protected against reading with passwords and locking.

When the password is all zeros, it is not possible to kill the tag. Therefore, you need to first write a kill password that consists of not all zeros before it can be used to kill a tag.

Writing the lock configuration and passwords typically happens when encoding the tags.

Mechanisms for privacy: read range reduction and hiding part of the EPC

The most ‘basic’ privacy enhancement feature of RFID tags is the ‘kill’ command. When issuing this command, the tag will never work again. This is perfect for consumer privacy, but makes it challenging to enable processes like automated returns management and would require the application of a new tag once the product has been returned.

Two more sophisticated privacy mechanisms have been introduced to overcome this:

• Read Range Reduction: dynamically change the read range to only a few centimetres (instead of a few meters)
• Hide the privacy sensitive part of the EPC: make the product identifier and/or serial number unreadable

Both mechanisms are protected with the Access password.

Those privacy features are currently only available on the NXP UCODE 8/8m chips — it is however expected that other chip manufacturers will follow soon.

So, while for security purposes it would be good enough to prevent any modifications to the chip by permanently locking all memories and passwords — it would also permanently disable all privacy features, which is definitely an unwanted situation.

Using passwords is therefore the way forward.

Managing passwords

The challenge of course is how to manage passwords. The most straightforward approach would be to use one password, that is the same for all tags in an organisation. However, once the password is leaked, all tags are vulnerable.

Even if the password would not be leaked, it is still possible to obtain it by ‘brute-forcing’ the password. In other words: try all passwords. When you assume a single reader would need approximately 5 milliseconds to try one password, and we know that there are 2 to the power of 32 is 4.294.967.296 possibilities, one can calculate that you need at maximum 248 days to ‘guess’ the password. On average, this would be 124 days. And, because tags are so cheap and easily available, you can easily run multiple readers in parallel that try to get the passwords of those. With a bit of effort, a password can be retrieved within days.

To make it significantly more secure, a solution is needed where the password is different in each and every tag, such that if one password is breached this has no impact for other tags. However, just having one password for one tag and storing that in a database would not be very scalable: it would require a client-server roundtrip every time you want to kill a tag, or enable a privacy feature.

Luckily, this problem has been solved many times in similar situations. Using a cryptographic one-way hash function it is possible to calculate a password based on the value of the EPC and a secret (another password that is unique per brand). A one-way hash function works in such a way that:

1. If you have the EPC and the secret, you can calculate the password.
2. If you have the password and the EPC, you cannot calculate the secret.

This means that even if you retrieve one or multiple passwords by brute-forcing, you cannot retrieve the passwords of other tags. It also means, that you just need one secret per brand which can be securely distributed. There is no need to have a database of passwords. This is a very scalable, safe and reliable mechanism.

Scaling the solution for multi-brand retailers

While this solution works well for a single-brand retailer, it becomes more challenging for multi-brand retailers that sells products of different origins. They will not be able to enforce their own password management strategy to the brands, because that would be impossible to implement in the supply chain.

We would proposed that each brand implements password management like described above, and distributes the security keys to the retailers that are selling their products. Each (series of) GS1 Company Prefixes would have their own secret. When the retailers wants to enable a privacy feature on an EPC, it gets the Company Prefix for that EPC and uses that to obtain the right secret — which can be used to generate the password needed to do so.

This solution combines the benefits of having unique passwords per tags, while making this easy for the brands and retailers to implement.

The obvious risk in this solution is in managing the keys of the brands: if one retailer accidentally leaks the key of one or more brands, you would still end-up in trouble. There are industry best-practises on key distribution that should be followed.

And if a brand doesn’t want to hand out the secret to retailers, it could still offer an API service where a retailer presents an EPC, to get a password in return. This obviously requires connectivity, but is the most secure way of working.

Conclusion: this needs standardisation

Taking this all together, with a proper configuration of the locking parameters on the chip — and by setting passwords, it is possible to secure the RFID chips against unauthorised modifications in a scalable way — and still allow for consumer privacy. Of course, this is all embedded by default in the Nedap !D Cloud solution.

Because this solution will only work when everybody is using those methods, we would strongly recommend the industry to standardise this approach in such a way that all retailers and consumers can benefit from a secure and privacy-aware way of deploying RAIN RFID.