6 SecurityProduct authentication ha

6 Security
Product authentication has to deal with degrees of uncertainty and some authentication methods are stronger than others. Thus, different verifications lead to different levels of confidence and in Lehtonen’s view (Lehtonen et al., 2007) because perfect security does not exist, the 100% confidence level is theoretical. In practice however, the 100% confidence level can be associated with the most secure techniques.
Each step in what is essentially a chain of trust network is a possible point of attack against a product authentication system. Lehtonen (Lehtonen et al., 2007) cite examples of threats and include tag removal and reapplication, tag cloning, attack against the RF communication, manipulation of equipment and forgery of product history among others and they outline security and functional requirements mitigation strategies to deal with these. While Lehtonen (Lehtonen et al., 2007) conclude their analysis with identifying some deficiencies with The EPC Network (i.e. the still conceptual nature of tag authentication, missing Discovery Services as a component of the network etc), Sandhu (Sandhu 2003) argues that the level of security of a system should always be good enough but not more because too high levels of security lead to unnecessary costs, decreased flexibility and reduced usability.
Security is a process by which an organisation protects its valuable assets. In general, assets are protected to reduce the risk of attack to acceptable levels with the elimination of risk an often unrealisable extreme. Because the level of acceptable risk differs widely from application to application, there is no standard security solution that can apply to all systems. The EPCglobal Architecture Framework cannot be pronounced secure or insecure, nor can any individual standard or service. As ‘security’ cannot be evaluated without detailed knowledge of the entire system, security, within the context of The EPCglobal Architecture Framework focuses on data protection methods and the mechanisms and specifically data protection when it is stored, shared and published within EPCglobal Standards and their relation to system attributes (Traub et al., 2014).
For operations both inside and outside an organisation’s four walls, The EPCglobal Architecture Framework promotes environments with security precautions that appropriately address risks and protect valuable assets and information. Security features are either built into the standards or recommend use of industry best security practices in accordance with the framework.
Traub (Traub et al., 2014) outlines the data protection mechanisms within the Standards and the Standards forming The EPCglobal Architecture Framework including underlying technical principles, network interfaces protocols, application level event interfaces, RFID reader protocols including low level reader protocols, reader management, EPC Information Services (EPCIS) interfaces, Object Naming Service (ONS), number assignment, tag air interfaces, tag data formats and standards, security and EPCglobal Electronic Pedigree standards.
In February 2014, GS1 ratified a new version of the EPC Generation 2 (Gen 2) Ultra High Frequency RFID Standard, which includes features that companies in many industries will find useful including added security features previously available only in active or proprietary passive systems, in an effort to counter counterfeiting.
Until recently, the EPC Gen 2 air interface protocol has been vulnerable to cloning, because a counterfeiter can read the unique Electronic Product Code in a RFID tag and programme it into a different tag that is indistinguishable to the reader. The tag manufacturer's tag identifier (TID) can also be cloned. Traub (Traub 2014) outlines that the new Generation 2, Version 2 (Gen2V2) solves the cloning issue by providing a secret authentication key that is programmed into the tag. Unlike an EPC or TID, this key cannot be read from the tag. Instead, a reader "challenges" the tag by sending it a random number. The tag encrypts that number using the secret key and sends the response back to the reader. The reader uses the secret key to decrypt the response. If the decrypted response matches the challenge, the tag is genuine. A counterfeiter cannot read the secret key or interpret it by listening to the conversation between a tag and a reader. Without the key, it is impossible to clone a tag that a reader will authenticate.
To use this feature, companies must consider three new software requirements when procuring or upgrading their RFID applications or middleware. The application that programmes the tag must choose a secret key - typically, a random number - and programme that along with the EPC and other information.