Security in a UHF RFID tag

Do we need security in an RFID tag? What do we even mean by security?
 
In the UHF tags available today there really is no security, in fact in many of the RFID tags that are used in applications today, there is no security. It is not needed, and so there has been no attempts to include it.
 
The one area that this not true is in the area of financial transactions where the predominant standard is ISO/IEC 14443. This standard (the basis of NFC, Near Field Communications) is a High Frequency (13.56 MHz) standard that includes the capability for encryption of the information on a tag. This capability does not exist for UHF tags – at the moment.
 
There have been many meetings of the UHF RFID experts to talk about how to add true security to a UHF RFID system.
 
This majority of RFID applications do not need security. The unique number stored in the tag means nothing to someone reading the tag unless they have access to the databases that explain the meaning of the number. However, some applications want to have more information stored in the tag and some of that information may be sensitive. Hence the need for security.
 
There are several areas that require the use of security. These include untraceability, loss-identification and/or protection, memory-locking, and privilege-management. To allow some of these to be implemented we also need to add file-management capability.
 
In order to achieve security, the tag and the reader have to prove to each other that they are allowed to talk. This is called authentication and it is a necessary process before the tag tells the reader any information. This is the first stage of the secure process.
 
There are several parts to the Authentication process. The tag must declare and prove that it is capable of secure communications. The interrogator must declare that not only is it capable but that it is allowed to access certain information on the tag. There may be information on the tag that not all interrogators are allowed to access, and so there must be a method of creating privilege based access and hence file areas on the tag.
 
Once the tag and interrogator have authenticated each other, then the secure communication can start. By secure communication we mean the "real-time" encryption of the data that passes between the tag and interrogator. This is not the storing of encrypted data, it is the process where the tag has the ability to encrypt anything it communicates to an interrogator.
 
The implications of having an encryption engine on board a passive tag are obviously very wide. The loss of power to the tag during the encryption process means that the data does not get secured and transmitted, so a lot of work has to go into the design of these new tags.
 
One of the areas that the experts have been looking at is what encryption routines should be available.  The group has decided that there should be no restrictions as some applications may only require very simple security while others may need the power of an AES type encryption. the idea is to not include the encryption algorithm informatuon in the air interface standard but to create another document where all the algorithms are detailed.  The manufacturer of the tags would then be able to decide which encryption suite his tags will support.
 
In ISO, the air interface for UHF type C (ISO/IEC 18000-63) will be the first standard to be created for a secure RFID system. The basis for the security is already included in ISO/IEC 29167-1 which is currently in ballot.  The specific information for each type of tag is then included in the air interface standards (ISO/IEC 18000 series). The standard that will specify the security suites has not yet been decided, but there is a proposal that ISO/IEC 29167 be the home for these suites.
 
Not all tags will require security, and the extra cost for the tags will not be something that all applications can bear so these specifications will all be optional.
 
The work has begun to create the standards for this concept, but it will not be complete for a while. In fact we will probably not see the standards published until late in 2012. As the work progresses, I will update the blog with information.
Steve

About Steve