DTR07044 Consultation Comments Resolution



|SOURCE-ABBREVIATION |Email |Name |Organisation |Comment |

|AIM |hansen@AIM-D.de |Wolf-Ruediger Hansen |AIM Germany, AIM-D e.V. | |

|AIM UK Ltd |AndrewC@ |Andrew Callaway |AIM UK Ltd (UK Association for Automatic Identification & Mobility) | |

|BSI-Germany |hansen@AIM-D.de |Wolf-Ruediger Hansen |BSI Germany |Mr. Hansen forwarded the document for |

| |(Harald.Kelter@bsi.bund.de) |Harald Kelter | |BSI Germany |

|CEN TC225 CAG |henri.barthel@ |Henri Barthel |CEN TC 225 |NOTE The CEN TC225 Chairman's Advisory|

| | | | |Group, comprises the Chair of CEB |

| | | | |TC225, the four Work Group Convenors, |

| | | | |and the Secretariat |

|Christian Schenk |dr.c.schenk@t-online.de |Christian Schenk |SILVERLINE CONSULTING | |

|Daimler |stephan.bourguignon@ |Stephan Bourguignon |Daimler AG | |

|DanLib |lea@BIBLIOTEKOGMEDIER.DK |Leif Andresen |Danish Agency for Libraries and Media | |

|DIN NIA 17.8 |michael@ |Michael HEGENBARTH |German national standardization group, i.e. DIN NIA-17.08 | |

|EDItEUR |brian@ |Brian Green |EDItEUR |EDItEUR on behalf of the European |

| | | | |library community |

|ENISA |Steve.Purser@enisa.europa.eu |Steve Purser |ENISA | |

|France Telecom |nicolas.desmoulins@ORANGE- |Nicolas Desmoulins |France Telecom | |

|GB - BSI IST/34 |Peter.Slot@ |Peter Slot |GB – BSI IST/34 | |

|GS1 EPCglobal |marisa.jimenez@ |Marisa Jimenez |GS1 Global Office | |

|Ian Brooker |ibrooker@ |Ian Brooker |Member of the Coordination Group | |

|JPP |j.preishuber-pfluegl@cisc.at |Josef Preishuber-Pflügl |CISC Semiconductor Design+Consulting GmbH | |

|JSC |j-schuermann@JSCONSULT.DE |Josef Schuermann |JSConsulting | |

|Michelin |gad13@orange.fr |Gérard Dessenne |For Michelin |Inputs sent directly to Gérard |

| | | | |Dessenne instead of defined email |

| | | | |address |

|SC17 |Chris.Starr@.UK |Chris Starr |SC17 | |

|TG34 |jfalck@ |John Falck |ETSI ERM TG 34 | |

NOTE#1: All Editorial comments are accepted in principal and will be addressed in final editing. Detail resolution of such comments is not given in the present document.

NOTE#2: Comments from STF members are not addressed as part of consultation as these should have been addressed by STF contribution during the development of the document or as a contribution to the resolution of comments from non-STF members.

NOTE#3: The document has to be very clear that it is presentation that RFID exists within systems and that the analysis applies to the systems with some significant part given over to the security and privacy issues that RFID may introduce (particularly when RFID is used as a replacement of an existing non-radiating input element). Need to reinforce that the document is not an RFID document but a response to concerns of privacy and security in systems of which RFID is a part.

For clause 10: From Trevor's updated document we keep "It is recommended that the ISO RFID Emblem option expressing “RFID” as it is defined today is adopted for the purpose of notifying the public of the presence of tags in retail and optionally elsewhere and that the ISO RFID Emblem is used as a basis for the development of a revised ISO standard which enables it to perform the role of a “reader” sign reflecting the requirements of the Recommendation and the wider stakeholder input as outlined in the requirements specification.

There are a number of emblem and logo standards which can or do contribute to public notification and of these the ISO Emblem goes the furthest to meeting the requirements." Much of the remaining text we move to annexes as analysis and gap determination.

Summary of document restructuring to meet the bulk of these requirements:

Background: Clauses 4 and 5

Requirements: The bulk of clauses 7/8/9

Phase 2 plan and work: Refinement of requirements to identify what is new and what may need rescoped/refined.

|AIM 01 |

|AIM 07 | |Page 4 contents |

|TS |RFID implementation guidelines for operational requirements and privacy and security implications |C, D, G |

| |Series of Standing Documents to support the RFID implementation guidelines |C, D, G |

|TS |Notification of RFID: The information sign |1, 4 |

|TR |Notification of RFID: Additional information to be provided by operators |1, 4 |

|TS |Guidelines for undertaking a privacy impact assessment (PIA) of an RFID system |B, 2, H, I, J, K, L |

| |Series of Standing Documents to support the RFID PIA guidelines |B, 2, H, I, J, K, L |

|TR |Application program interface for interrogator authorisation in an application |H |

|TR |Mobile telephone "apps" for authorising the devices as RFID interrogators in an application |H |

|TS |Device interface to support ISO/IEC 18000-3 Mode 1 and Mode 3 tags |N |

|TR |RFID terminology |(see below) |

|We have also included a Technical Report on RFID terminology. The nature of the work on privacy and security, and some of the technical aspects of RFID (even the consultation report itself), when presented in English does |

|present an obstacle to technology experts and application experts who do not have this as a first language. |

| |

|There is an established RFID terminology standard (ISO/IEC 19762-3) but even this document does not carry all the necessary terms even in the English language. Therefore, we propose a three-stage process: |

|To work with ISO/IEC JTC1 SC31 to extend ISO/IEC 19762-3 to cover the additional terms required, or to develop a European extension in the English language to support this. |

|This entire new document could then be formally translated into French and English, as is the practice for some European standards. |

|Then, a standing document could be prepared that takes selected key terms that are required for the purposes of privacy and security and identify these in a multi-lingual matrix document. This document can also include a |

|basic set of technology terms to support the SME sector to understand RFID technology. This standing document could be continually updated, so that it provides as up-to-date a resource as possible. |

| |

|It can then be left to individual national standards bodies to choose whether to translate the definitions themselves as national documents. |

In addition the work items detailed above, CEN TC 225 will undertake these activities to support the process:

• Adopt and adapt ISO/IEC 29160 RFID emblem as a European standard

• Continue to work with JTC1 SC31 WG7 on existing projects for security features of RFID

• Continue to work with JTC1 SC31 WG7 on additional privacy by design features for RFID

• Continue to work with JTC1 SC31 WG4 SG1 on developments of ISO/IEC 24791 to ensure reader authentication for the technologies covered by that set of standards

• Continue to work with European Liaison organisations and other users bodies to promote best practices for the use of RFID.

• Support and actively maintain the GRIFS database of RFID standards

• Promote the registration of RFID applications to the rules of ISO/IEC 15961-2

• Promote the use of the ISO/IEC 15962 data protocol to provide filtering of encoded data

• Promote the use of the ISO/IEC 15459 unique identification standards to European sectors

Analysis of Standardisation Gaps Identified in the Phase 1 Public Consultation Report

For reference we use the letters and numbers used in the table on pages 90 to 95 of the consultation report.

A Tag access and security

This is defined in the report as being applicable to the tag (so we assume that this refers to the memory structure) and to the air interface protocol.

All passive RFID tags harvest energy from the basic signal from the interrogator, which means that all tags compliant with a particular air interface protocol will reply to any interrogator using the same air interface protocol. The Phase 1 report is concerned about tags being used for track and trace purposes. Some technologies require a permanently encoded chip ID for anti-collision purposes and this, therefore, remains a permanent association with the tagged item. Some of the newer technologies use a session Id that is dynamically changed when the tag is involved in a communication process. It is impossible to retro-engineer the session Id onto tags that use the chip id for anti-collision purposes.

Access to data can be restricted using a password as in ISO/IEC 18000-6C, and the newer access control methods are being developed in ISO/IEC 29167.

CEN TC225 recognises that making such major changes requires a considerable investment by each integrated circuit manufacturer (up to 1 million Euro). It also recognises that any of these more secure features at the tag and air interface level can only be added as optional features to existing standards, therefore offering users of RFID a choice of compliant tags with different capabilities. Unless tags with enhanced security are legally required, those purchasing the tags will evaluate all features including cost. This applies equally to government users adopting the technology as well a private enterprise.

CEN TC225 will continue its support for the work already started in ISO/IEC JTC1 SC31 WG7 on the development of the ISO/IEC 29167 standards. We will liaise with CEN TC224, Personal identification, electronic signature and cards, which deals with associated RF card technologies. It might be that some of the features used in card technology could be features that are incorporated in some of the ISO/IEC 18000 series of standards. We will also explore whether there are proprietary solutions in other tag technologies that might be possible to standardise.

Conclusions: Such major developments depend on at least one of these factors:

• the willingness of major manufacturers to support the level of standardisation, as with ISO/IEC 29167

• government investment for new security features to be developed, possibly by being a major customer

• legislation requiring the use of a secure technology, taking into account international trade issues

These solutions are unlikely to be applied to the oldest technologies where an infrastructure change will be costly to the manufacturers and users, and the extent of migration being uncertain. So there is a requirement to address security in other areas of an RFID system for some technologies.

B Control of data read by the application

In the consultation report, this is identified as being associated with a reader (interrogator), but we consider it to be more associated with the encoding rules used and the specific application standards. On this basis, there is no need for an explicit technology standard, but to increase awareness of some of the existing standards.

ISO/IEC 15961-2 defines the role of a Registration Authority managed by NEN. The process requires administrations of applications to register certain features to ensure interoperability between their RFID application and all other registered applications. This process identifies the name of the organisation and, by inference, details of the application standard. An analysis of these application standards not only defines their scope, but also the requirements for data content. The EPCglobal standards are interoperable with this registration, and those details are also publicly available. CEN TC225 is already embarking on a process to increase awareness of this Registration Authority, so that more RFID applications can be properly registered.

The implementation of particular encoding and decoding rules, as in ISO/IEC 15962, is also a mechanism that can be used to avoid some types of attack on a system. When used with an application standard, there is even greater control of data transferred between the RFID tag and application.

Standards associated with CEN TC224 are more likely to encode personal data. We therefore consider that CEN TC224 undertakes its own investigation into the control of data.

Conclusions: Existing standards at the application interface (ISO/IEC 15962 and 24791), combined with register application standard, provides a good control on data exchanges. When combined with a PIA procedure, this will increase the awareness and responsibilities of operators. CEN TC 225 will promote the use of the Registration Authority and the application interface standards.

CEN TC224 should review data communications from cards compliant with its standards, not least because of the greater likelihood that such cards encode personal details.

C Killing the tag

Our interpretation of this issue is a desire to either make the tag unreadable after its final transaction, or to reduce the read range significantly at this stage of processing. Our concern is that to implement a true kill function needs the certainty that this is the last RFID process that is likely to be applied to the tag. We can see three circumstances – even in the retail sector – where a blanket "kill" might not be the most appropriate action to take:

• For items with a high return rate (e.g. retail clothing) a kill function would make it extremely difficult to deal with returns processing, not so much for the consumer, as for the retailer having to re-tag items.

• As new applications develop in RFID that will bring benefits to the consumer (e.g. assisting blind people and those with reading capabilities), a kill function might even remove the incentive to develop such applications. The same applies to applications that might be able to monitor food safety as sensors are attached to RFID tags.

• The third issue is associated with the environmental aspects associated with the item itself for end-of-life purposes, where the RFID tag might be the best means of identifying the process requirements. This is certainly the approach being adopted by some Japanese manufacturing sectors supplying to consumers.

In addition, any features to permanently kill or reduce the functionality of the RFID tag need to be supported both in the tag architecture and in the air interface protocol commands. Currently, such features are only available in a limited number of tags such as ISO/IEC 18000-6 Type C tag and ISO/IEC 18000-3 Mode 3 tag, which is in its final stages of standardisation. Such technologies might not be the best choice for operational aspects of an application. If they are considered to be appropriate, then there is still the requirement for migration from existing technologies.

Features such as reducing the range might be more appropriate, and one model of the ISO/IEC 18000-6C tag does support this using proprietary commands.

An additional factor to take into account is that many tags are used multiple times in the same application. This means that permanently killing a tag is completely inappropriate, and even switching the capability to read at different distances will add operational requirements.

CEN TC225 considers that two actions need to be taken. The first is to provide support to JTC1 SC31 in the development of any air interface protocol standards and to adopt these as European Standards. In addition, we consider that some of the options facing application designers need to be fully explained and incorporated in the RFID implementation guidelines.

Conclusions: Permanently killing a tag might not suit all applications, and the feature is not available in all technologies. An alternative might be to reduce the read range, but this feature is currently only available on a proprietary basis. While CEN TC225 will continue to support the standardisation of the technology, it also considers it important to provide relevant guidelines to user organisations in order to assist in a better understanding of the technology.

1 Notification of reading process

CEN TC225 interprets this as supporting the requirement for RFID signage to identify RFID applications. This is something that is fully supported by CEN TC225. We consider that three new Work Items are required:

• To adopt and adapt ISO/IEC 29160 to selectively identify the emblem or logo. This work has been initiated independently of Phase 2 of the RFID Mandate.

• To create a New Work Item for a project that will probably need to begin as a Technical Specification and eventually migrate to being a full European Standard. The reason that we favour a Technical Specification is that there are a number of components associated with the RFID signage, as identified by the Commission and by the RACE project, that are not yet in place.

• A Technical Report that specifies the additional information requirements that need to be provided by an operator of an RFID system. As some of the essential references features, such as the privacy impact assessment framework, do not yet exist some co-ordination of the standardisation documents needs to take place.

Conclusion: This is considered to be a set of important work items that CEN TC225 is prepared to undertake as part of Phase 2 of the Mandate.

2 Informed consent procedural standard

CEN TC225 certainly accepts the need of individuals to provide consent to the use of any personal data associated with an RFID system. However, we do not see the need for an explicit standard to deal with informed consent. This should be part of the Privacy Impact Assessment, with indications of where individuals need to provide informed consent of the use of their personal data in an RFID system.

D Authentication

As this is shown in the table on the consultation document at the junction of Gathering Personal Information and Tag to Reader Interface, we have assumed that this is calling for some type of secure authentication of tag and interrogator across the air interface. This is generally not possible with existing technology. The only known implementation, using a complex inter-relationship of different AIDC technologies, is for the mutual authentication of tag and interrogator for e-passport control. Here, the "read" transaction begins by processing an AIDC technology other than RFID. This is not possible when reading the tag at a distance.

We are aware that with the development of ISO/IEC 29167, different levels of authentication are being established, but this is one layer deeper than that of being able to identify the tag. In other words, authentication is achieved before information is exchanged and not at a more basic level of identifying the tag itself. We also note that even with the secure e-passport protocol for exchanging data, that some national implementations of the ICAO 9303 passport standard still retain the ISO/IEC 14443 unique chip id. So the data is more secure, but the passport can still be tracked.

CEN TC225 considers that special applications such as passports – which are probably completely within the domain of CEN TC224 – are addressed separately. For ordinary RFID transactions the best way forward is to continue supporting the International Standards developments of ISO/IEC 29167. It also has to be recognised that such standards add additional layers to the basic technology, and cannot be transferred economically and technically to all the existing RFID technologies.

Conclusions: The main objective should be to continue supporting the development of ISO/IEC 29167, particularly extending to other air interface protocols.

As these technologies are developed, we consider that the RFID implementation guidelines should include some detailed advice of the capabilities of different RFID technologies and how they support authentication. We would also see this Technical Specification (TS) being supported by a series of Standing Documents. These could provide more up-to-date information both during the development of the TS, and certainly in the period once the TS is available and until work is completed in the future to convert the TS to a full European Standard.

E Access control

It is not clear what "access control" means when applied to the reader. There is no explanatory text in the report, other than this term being used elsewhere in the report to define a particular type of application. Therefore we cannot comment.

G System operational standards

We do not consider that there is a need for a standard from an ESO addressed explicitly at applications. We consider that the proposed RFID implementation guidelines are sufficient to enable an industry sector to develop an RFID application standard. It is the application standard (as discussed above) that determines the capability of RFID to operate in an open system environment. This has already been proven by the standards from EPCglobal, IATA, and the library community to name just three.

CEN TC225 considers that there is a requirement for a generic privacy impact assessment to assist operators in undertaking their individual privacy impact assessment. Furthermore, we consider that it should be possible for a particular sector to prepare a pro forma PIA based on a given application standard and associated operation. This would enable individual operators to undertakes a PIA and declare their specific variants in a more economic and efficient manner. It will also enable any data protection authority having access to the sector's pro forma PIA documentation to understand the vulnerabilities and mitigations that are identified.

The PIA guidelines need to include information about specific tags, because it is the tag technology in terms of read range, features supported by the tag, and air interface commands that will largely determine the privacy and security capabilities of the application. To supplement the privacy impact assessment guidelines, CEN TC225 will produce a series of Standing Documents as new technology features are introduced. This will provide operators of any new RFID implementation with up-to-date information on the capabilities of the technology.

3 RFID application management standards, including PIA and mitigation

We consider that our approach to the notification of reading processes (labelled no 1) will address this point.

4 Consumer information standards both for signs and applications

We consider that our approach to the notification of reading processes (labelled no 1) will address this point.

H Reader authorisation by application

CEN TC225 interprets this as only allowing authorised interrogators to access the application system.

Currently, there are two standards that have relevance in this area: ISO/IEC 24791-5 for the device interface (which is concerned with moving data and other information between the interrogator and the application), and ISO/IEC 24791-3 for device management (which is concerned about the device infrastructure). Both of these standards are currently only applicable to the ISO/IEC 18000-6C tag. Therefore, TC225 will work with SC31 to ensure that these standards provide the necessary requirements for authentication of interrogators on an RFID network.

There are two other associated concerns:

• All of the existing RFID implementations have virtually no possibility to retro-engineer features in standards such as ISO/IEC 24791.

• The potential increase in the use of mobile phones as RFID readers, and the increased probability that operators will allow these to access the system.

In the case of dealing with established RFID implementations, CEN TC225 considers that the most appropriate way to achieve this is to research and develop an Application Program Interface (API). This API can be used as an "wrapper" or "envelop" of the basic communications to ensure that all interrogators can be identified by the host application system. This is particularly important in applications where members of the public have access to the RFID system.

The situation with mobile phones is slightly different, and solutions will vary depending on whether the phone has the capabilities of reading 18000-6C tags or of reading high frequency tags as defined by the NFC Forum. Although the RFID technology is different, we consider that a viable approach might be to develop pro forma "Apps" that establish a handshake with the host application system, identifying the particular mobile phone as being permitted to undertake such communications. We see a distinction between these RFID issues and the mobile phone being used simply as a highly portable computer for receiving and sending basic messages such as text messages or downloading web pages associated with the RFID application. As an example, a mobile phone capable of accessing an airline website or receiving an SMS message about an item of luggage is outside the scope of the issue. In contrast, a phone that can read an RFID bag tag and then communicate its data to the airline system should require prior approval and require authentication. The fundamental difference, as we see it, is that a mobile phone with an RFID encoding and /or decoding capability might be capable of undertaking processes that are intended only for the operator of the system. There is also the additional risk that if such phones are not authorised, they might be used for "man-in-the-middle" attacks.

I RFID system privacy by design standard

CEN TC225 certainly appreciates that the way forward for the future of RFID is to adopt the principles of privacy by design. We are less certain that it requires a specific standard to achieve this. What we consider more likely is that as privacy and security aspects are taken into account, there will be a number of revisions to existing RFID technology standards. This is currently the case with ISO/IEC 29167, which is applying an additional layer of privacy and security features onto a more basic technology.

We do see that the design of an application standard can certainly merit from taking into account privacy and security features that are available in the prevailing tag technology, and by applying mitigation techniques that might be used to reduce any of the inherent vulnerabilities.

Conclusions: Therefore, CEN TC225 considers that it should continue to work with the JTC1 SC31 Work Groups to help develop enhancements to the technology in the air interface protocol standards and other related standards.

Based on the prevailing technology, CEN TC225 will incorporate privacy by design features into the proposed RFID implementation guidelines. It will also accelerate the dissemination process through the publication of Standing Documents,

J Operational audit standards

We consider that the most rapid, and effective, way of implementing robust privacy impact assessments for RFID implementations is to place some responsibility on the sectors developing application standards. Not only will this reduce the inertia for individual operators to carry out their implementation-specific assessment but can also be used as a means of formally registering a PIA with an appropriate authority. We understand that the Information Commissioner in the UK has welcomed this generic approach for PIAs in general. Here, either trade bodies or specialist software developers are encouraged to produce generic framework PIA documents.

If this approach is accepted, then the requirement for an audit of an individual implementation is greatly reduced and only required when a problem is reported. The danger otherwise is that, as happened with early quality control standards, the minimum details of the processing will be recorded, assuring an easy pass compared with a detailed recording of the processes were there is a risk of being failed on a minor point of detail. The PIA process for RFID needs to be rigorous, but not a burden economically.

K RFID system data access by design standard

CEN TC225 thinks that this gap needs to be addressed in the process to develop application standards. We do see that the design of an application standard can certainly merit from taking into account privacy features for handling and processing data. We are prepared to provide assistance to support user organisations to develop such application standards. We do not consider that it requires a specific technology standard to achieve this.

Conclusions: Therefore, CEN TC225 considers that it should continue to work with liaison organisations and other user bodies to help them Incorporate an appropriate level of data access in their RFID application standards.

CEN TC225 will incorporate data access by design features into the proposed RFID implementation guidelines. It will also accelerate the dissemination process through the publication of Standing Documents,

L Addition of tag facilities (to delete the tag)

These tag facilities are defined in the table in the consultation document as:

• tag deletion

• rendering a tag non-readable (reversible)

• tag user selected non-readability (reversible). We assume that providing the user with such a capability will require the user to have access to some form of interrogator to carry out the switching operation off, and then on.

We have already raised some of the challenges with permanently rendering the tag unusable in our discussions on killing the tag, where we indicated that having such a feature is inappropriate for multiple use tags, as with libraries and travel tickets.

Even with the switching mechanism, whether automated or user-controlled, there is the additional complication that the existing low frequency and high frequency tags (as used for travel tickets and in libraries) have a permanent chip Id for anti-collision purposes. The tag needs to be physically destroyed to render this chip id unreadable, immediately negating the requirement for the tag to be used multiple times.

CEN TC225 considers that there are some technological advances that can take place, but will take time to develop. These include developing technologies that depend on a session identifier as opposed to a permanent chip identifier for anti-collision purposes. Although the session ID can still be readable, the fact that it is dynamically updated reduces a permanent association with an individual or item. However, it will take years for such technologies to be developed and adopted.

In addition to the kill function, other functions to reduce functionality (such as reduced read range) can be developed by extending the set of commands supported by the RFID tag. Efforts need to be made to "convert" proprietary solutions into generally available ones, and address the inherent intellectual property issues. Because these features are likely to be implemented at the hardware level, it is unlikely that the individual user will directly be able to control an on and off switch on the tag but need to do so by using a compliant interrogator.

Features such as removing the uniqueness of a serial number by deleting part of the code might be a useful alternative mechanism when there is the probability of products being returned, but generally this type of solution would have specific and limited applications.

Some mechanical – non-RFID – means (such as shielding a tag) can be applied to certain types of tag to reduce the capability of the tags being read or to reduce their read range. It is interesting that the report considers this to be an unfair burden on the user, which we find difficult to understand. If a means of shielding the tag is described and products are available, this might be the best way to protect the functionality of multiple use tags, yet still contribute to privacy. However, shielding some types of tag could increase the risk of the theft of the associated item, e.g. a library book.

Conclusions: We feel that most of the technology solutions will need to be developed at the international level with the co-operation of at least some of the major vendors of any given technology. Therefore, CEN TC225 will continue to support JTC1 SC31 WG4 and WG7 in their work.

We also consider that some useful advice can be provided to operators and even end users of particular technologies, especially where the tags are used repeatedly. To this end, the subject would be addressed in the RFID implementation guidelines.

M Deletion and modification in multiple application environments

There are no means at the RFID chip manufacturing stage of determining that the RFID tag / RF card will be used in a multiple application environment. Nor is this possible during the manufacturing process of the RFID tag. Therefore CEN TC225 considers that there is no need for an explicit standard for multiple application environments. The issues need to be addressed by other means. Any development of new features for tag deletion, or rendering a tag non readable (reversible), and making this user selectable needs to be assessed specifically for single use, multiple use (as with libraries) and multiple applications

We recognise that if an organisation invests in the purchase of RFID tags, it might look for multiple uses to amortise the costs. This certainly has happened with a number of applications that use membership cards. In recent years, we have seen travel cards and even credit cards used as electronic purses. Certainly, in university environments, the student card can be used for multiple purposes. The technology can provide the solutions, but the system designers need to take into account whether a feature is invoked, especially if it constrains the opportunity for multiple applications. However, the issuers of such tags and cards clearly need to seek the consent of the user when they implement new functionality.

We would also expect to see an increasing trend of using one RFID tag for multiple applications. The obvious example is with lifecycle management of the associated item, where encoded data on the tag can be used for manufacturing purposes, supply chain transactions including to the consumer, warranty purposes, service engineer records, and end of life use. Another example might be the safe disposal of pharmaceutical products to avoid polluting landfill and watercourses by returning unused or partially used prescription medication for safe processing. One possible technological solution, which is being explored by ISO, is for an RFID tag to carry separate records or even files for each of the functions supported by encoding of data.

If developments such as the Internet of Things are to become a reality, then RFID tags will probably be used multiple times (including after a retail purchase) and have multiple uses.

Conclusions: We do not see this as a requirement for technology standards, but as a significantly good practice to be employed by the issuers of cards.

N Open system interoperability design standards

CEN TC225 considers that the air interface protocol is only the very basic component needed to achieve interoperability in an RFID system. Standards such as ISO/IEC 24791-5 Device Interface or equivalents are considered to be another major requirement. Although the data encoding standards such as ISO/IEC 15962 have an important role to play, they do not directly interface with hardware devices, whereas the device interface standards do – resulting in a device interface protocol.

At present, ISO/IEC 24791-5 is only applicable to one tag technology (ISO/IEC 18000-6C) and our concern is really with the older established technology which may still be in use for many years to come. Even assuming that a better RFID technology solution was immediately available today, it would probably take 12 to 15 years (a conservative estimate) before the established 18000-3 Mode 1 technology could be replaced in the library sector.

If the stakeholders are serious about interoperability – not just the latest technology - then some of the older technologies need to be addressed. We have proposed the development of an API to ensure that interrogators can be authenticated, but this still leaves a significant gap for any 18000-3 Mode 1 interrogator being able to communicate properly with any application using that technology. One achievable step in this direction might be for a major application, such as that in the library community, to be assisted in the development of a common interface. Another possible candidate sector is the international blood transfusion service where the same tag is being used.

Because of the implications for privacy and security, there might be an advantage in a European initiative to develop the equivalent of ISO/IEC 24791-5 to address the two high frequency tag technologies:

• The new ISO/IEC 18000-3 Mode 3

• The established ISO/IEC 18000-3 Mode 1

As there is a high probability that these two tags will need to be interoperable, with existing interrogators upgraded to support the new tag, it might be possible to develop a device interface standard that supported both technologies.

Given that there are many European manufacturers of RFID high frequency integrated circuits, tags and interrogators, it might be appropriate for such a standard to be developed by CEN TC225 invoking the Vienna Agreement.

There is probably less of a requirement to address this gap with other air interface protocols. Therefore, additional advice might need to be given within the RFID implementation guidelines.

O Systems interoperability service / procedures standards

We see the interoperability of services and procedures as being completely separate from the type of work undertaken by an ESO. This aspect needs to be addressed by the various application sectors, and incorporated into their application standards.

A contribution that can be made by CEN TC225 is to encourage the registration of applications under the rules of ISO/IEC 15961-2. This itself might act as a catalyst for further levels of interoperability in the marketplace, but independent of the need for technology standards.

5 Interoperability management: agreements, service level, et cetera standards

We see the management of interoperability agreements and service levels as being completely separate from the type of work undertaken by an ESO. This aspect needs to be addressed between the various application sectors, and incorporated into their application standards.

However, CEN TC225 does see that there is a significant advantage in increasing the capability for interoperability of different applications within a sector, and even applications between sectors. To this end, we see the ongoing promotion of standardised data and traceability code as defined in ISO/IEC 15459 continuing to be promoted, not just for bar codes but for RFID also. Interoperability can also be increased between sectors as more applications are registered as part of ISO/IEC 15961-2. As the registration authority for both of these schemes is held by NEN, the Secretariat of CEN TC225, this all seems to be feasible.

Conclusions: The emphasis that CEN TC225 considers necessary is to increase the promotion of standards to various sectors operating in Europe, and to the SME community so that interoperability can be built on the basis of established standards.

6 Dissemination of standards role in reducing privacy risks with publicly credible compliance regime

CEN TC225 is slightly confused by this particular gap. The dissemination of the standards role is a normal function that is undertaken by CEN TC225 and other committees. So, to this extent, we are in full agreement of the requirements, but do not see it as a gap in the standards at all. One of the activities that CEN TC225 will undertake is to continue to support the GRIFS database – which, unfortunately, was barely mentioned in the consultation document – to provide a source of information of relevant RFID standards.

What is difficult to understand is the part of the description that deals with a "publicly credible compliance regime". We consider that privacy risks will be reduced by adopting a privacy-by-design process by all the relevant standards organisations, complemented by a rigorous privacy impact assessment undertaken by sectors and individual operators. Therefore, it remains unclear how, other than this, the standards can contribute to a compliance regime.

P System penetration testing standards (for different categories of app privacy etc risk)

7 EU Penetration tests followed by acceptable penetration resistance standard with respect to those tests

We have combined our comments on these two points, because the "resistance" or mitigation simply follows as the next step in the process.

CEN TC 225 considers that the penetration tests should focus on three components of RFID technology and vulnerabilities associated with:

• The mandatory and optional features of the RFID tag itself

• the air interface protocol characteristics

• the means of communication (standards-based or otherwise) between the interrogator and the application (back end system)

There is a requirement for a technical report identifying the methodology and penetration test results for each RFID technology. In addition, there should be a procedural standard presented in a manner that system designers can use. The definition of "system designer" needs to cover experts in sector work groups developing application standards, system integrators and technical staff of RFID operators. All of this is aligned with this abstract of Annex C of the consultation document:

Annex C (page 85)

As a consequence, RFID PEN test guidelines must be developed for all components of the RFID ecosystem (for some of the components it will be possible to reuse existing PEN testing methodology) and to analyse the specific RFID application deployment (system integration PEN testing). We envision specific PEN testing guidelines for the RFID technology (tag and interrogator) and the reuse of existing PEN testing methodology and analysis for the RF link, the network connection to the back end system and the back end system. We also envision the need for a specific RFID system integration PEN test guidance and standards.

Where CEN TC225 differs significantly is with what follows in Annex C, particularly " We therefore need to identify and describe these RFID sectors and analyse their privacy and security needs." and the 8 steps defined to carry out the PEN tests. We disagree for a number of reasons:

• A particular RFID technology needs to be selected for each application, as none of the individual technologies are fully interoperable with another (a basic rule in the selection of RFID technologies to be part of ISO/IEC 18000 is that a new technology has to have some additional characteristic)

• Therefore system designers select the technology on it being fit-for purpose. Currently, this might be over-focused on business operations. So the availability of technology-specific penetration tests will add new criteria to the selection process.

• The concept of privacy by design requires some proactive development. What is proposed by analysing applications is a reaction – almost continually following on after the event. We consider that this will present problems if a penetration test is undertaken after a number of implementations on a particular application standard has taken place and requires changes.

• An alternative, which also places the responsibility on the RFID operator, is that all the PEN standards based on the technology need to be considered during the development of the PIA.

Conclusions: If the penetration tests focus on the privacy and security aspects of the technology and the communication from the interrogator, we consider that this work is best undertaken by the relevant security groups within ETSI.

By focusing on the technology, including all the variations on a theme of a particular air interface protocol, each specific technical report will provide all the essential information necessary for a system design to take into consideration as part of the criteria of choosing a particular technology. It might not necessarily lead to the most secure technology being adopted, because some of the operational characteristics of such a technology might be unsuitable.

The other advantage of focusing on the technology is that the standards should be delivered within the same time scale in Phase 2 as all the other standards.

If a sector, or operator, decides that a specific penetration test is required for its application, then this can be addressed independently of the work of the ESOs.

Q System design for security standard

This particular gap is by row SO-5 Access to ECO system outside legitimate system. It is also mentioned in rows SO-6 to SO-9, were the emphasis on protecting against illegal activities. We interpret this as a requirement to protect any given application from external threats. Therefore, we consider that the penetration tests should be extended to address the external security vulnerabilities of the tag, the air interface, the interrogator and communications from the interrogator to the application.

This technical analysis should be included in the technical report for each of the RFID technologies and presented in a manner that the system designer can take into consideration.

AIM UK Ltd Annex to comment:

AIM UK Statements and Comments on the Radio Frequency Identification (RFID): coordinated ESO Response to Phase 1of EU Mandate M436

Introduction

This paper provides a review and a set comments on the coordinated ESO Response to Phase 1of EU Mandate M436 concerning the European commission Recommendation of 12 May 2009 on the Implementation of Privacy and Data Protection Principles in Applications Supported by Radio Frequency Identification.

It raises some concerns over the extent to which inappropriate standardisation and mandates could impact detrimentally upon RFID as a group of enabling technologies and associated products that offer considerable commercial and application potential, not least with respect to the emphasis being placed upon RFID by the European Commission with regard to the emerging Internet of Things (IoT). This is not to diminish the importance of standards, for which AIM UK has the highest regard, or to lessen the importance of privacy and security with regard to RFID. However, the considerations concerning these issues require putting into context, particularly with respect to use of technology and design of applications rather that technology per se.

It would certainly appear that RFID has been rather singled out as a ‘rogue’ technology as far as privacy and security is concerned, even suggesting there is some intrinsic capability of the technology to invade. The problems with privacy invariably come down to inappropriate application design and to intent, criminal or otherwise, to obtain data or information without consent and in covert manner. Design methodology, with appropriate impact and compliance assessment, supported too by appropriate protection laws, would appear to be more powerful tools in achieving privacy and security protection.

With covert identification of behavioral patterns entering the equation from other technological sectors that facilitate social networking - cell phones, blogging and twitter sites and the like[2]- is it to be expected that the RFID industry will have to accommodate demands in this respect at the technological level? Such developments are indicative of the changes taking place and these changes are better accommodated by application design methodology than mandates. Such developments may also point to technological opportunities for introducing new protective features to assist in the realisation of better solutions. The industry can be flexible and responsive to change in this way and should not be severely restricted by mandates, particularly where the impact of the mandate in achieving the desired result may be dubious, difficult or impossible to implement or cause severe commercial expense in effectively outlawing products already on the market.

AIM UK has promoted the design methodology approach to privacy and security since the issues were first raised with regard to RFID[3], and continues to do so. It therefore supports the needs for such standards as those being proposed in the response to the mandate for design. Alternatively, it may be in the form of comprehensive Guidelines, which also accommodate guidelines for risk or impact assessment and assessment of compliance. Such guidelines should also include liaison with industry on needs identified for device or systems development.

Background

The present public consultation document to which this response is directed is the Radio Frequency Identification (RFID): co-ordinated ESO Response to Phase 1of EU Mandate M436, obtainable from

It is a lengthy document (101 pages) and unfortunately lacks an executive summary. As a public consultation document such a summary is seen as essential as a means of rapidly putting the response into context and its links with the two important documents to which it relates. These documents are:

1. Commission Recommendation of 12 May 2009 on the Implementation of Privacy and Data Protection Principles in Applications Supported by Radio Frequency Identification



As the title indicates it is concerned with the implementation of privacy and data protection principles in applications supported by RFID. The Recommendation is essentially a precursor to the realisation of an EU Directive to be adopted in law by all its Member States. The Recommendation has required a number of actions to have been undertaken within a year by the Member States to ensure that operators (viewed here as those implementing RFID applications):

• develop and publish a concise, accurate and easy to understand information policy for each of their applications.

• provide a summary of the privacy and data protection impact assessment carried out on the RFID application.

• inform individuals of the presence of readers on the basis of a common European sign.

From AIM UK’s standpoint on design methodology these requirements fit in with the framework for:

• Design for user acceptance

• Design for legislative conformance and governance, inclusive of data protection measures

• Design for protection against abuse from prospective attacks, based upon risk assessment and guidelines on attack scenarios

• Selection of technology appropriate to needs and understanding of technology attributes and limitations.

2. European Commission Standardisation Mandate M436



This Mandate was issued to the European Standards Organisation (ESOs) with a view to developing standards to support the Recommendation of 12 May 2009 on the Implementation of Privacy and Data Protection Principles in Applications Supported by Radio Frequency Identification.

The Mandate identifies two phases of activity, Phase 1 requiring research by a group of experts to facilitate specific standardisation by the European Standards Organisations (CEN, CENELEC and ETSI). Phase 2 is concerned with development of those standards, identified in Phase 1 that are supported through public consultation. The document, Radio Frequency Identification (RFID): coordinated ESO Response to Phase 1of EU Mandate M436, is the outcome of Phase 1 and subject of the present consultation.

The object of the coordinated ESO Response to Phase 1of EU Mandate M436 has been to address the fourteen bullet points listed in the Mandate in order to satisfy the EC requirements and to raise awareness and confidence among the public by analyzing any standardisation gaps, so that the necessary standards can be developed within phase 2. Being directed at public consultation it would have been appropriate to list the fourteen points and reference the responses clearly to these fourteen points. Instead there is reference to 17 specific points in part 4, the ‘Summary of findings and recommendations’. Section 4 does not really fulfil its scope in providing findings and recommendations. It would have been helpful and clearer for stakeholders to have been presented with a table listing the Mandate requirements, along with findings and associated recommendations, including a list of standards being proposed for development.

The scope (1) defined in the document is specifically concerned with privacy, data protection and information security in relation to RFID and recommends a plan of activities for phase 2. Unfortunately, the scope does not translate clearly into the summary of findings and recommendations of part 4. Since the document is also concerned with gaps in standardisation the analysis presented in Annex D is perhaps a more poignant focus for attention as a summary of what is being proposed than part 4. Unfortunately that too lacks clarity.

In view of the paucity of section 4 with respect to the absence of recommendations and the statement that the document is not complete in all areas raises the question as to whether the report is ready for public consultation. To simply suggest that these areas have been left open for the consultation process to provide insight and direction is really not acceptable. The document is esoteric in some respects and vague in others, it lacks continuity and rigor in respect of some arguments being presented, and demands a level of technical understanding that the public by and large may not have, and indeed some of those involved in producing the report. Moreover, the emotive nature of privacy and security can, in the absence of sufficient technical awareness, lead to unreasonably biased opinion and influence upon developments.

As stakeholders in the RFID industry members of AIM UK do not feel that the document has been structured or positioned correctly to serve as a vehicle for public consultation. There is insufficient and suitable regard to:

• application requirements for RFID in areas such as libraries, requiring the reuse of tags (the consultation document indicates a bias towards a level of security and privacy that is currently not possible to implement using RFID in libraries)

• application design and the means of accommodating change and the diversity of application specific needs

• RFID in the context of other technological impacts upon privacy, security and identification of behavioral patterns

• successful adoption, to date, of RFID technology in many areas of application

• responsible way in which RFID stakeholders (including members of the public, RFID manufacturers and providers, Government and industry organisations) have implemented applications, paying due care and attention to data protection, security, privacy and legal requirements

• accommodation of the European Commission’s recommendations of May 12th 2009.

AIM UK feels it critical that these points, and the comments presented above, should have been covered in the public consultation document. Failure to do so causes concern for the industry and presents a distorted view of the issues for the public to consider.

Ian Brooker Annex 1 to comments:

Basic Use Scenarios, standards applicable and gaps:

Scenario 1 – The tag contains no data except a unique non-specific code which is a pointer to data in a back-end system

In this scenario the tag contains a unique code which has no association to the item or person attached or carrying the tag. The only association between the two, if any, is entirely within the back-end system. This is very common in access control and most basic RFID tagging applications (including retail). Even if the tag code is known, or intercepted, the only access to the personal or item information is by gaining access to the back-end system. The data protection requirements for Region A apply to the data.

Scenario 2 – The tag contains no data except a unique non-specific code which is a pointer to data in the Interrogator or back-end system

This is very similar to Scenario 1. In this scenario the tag contains a unique code which has no association to the item or person attached or carrying the tag. The only association between the two, if any, is contained in the Interrogator and/or in the back-end system. This is sometimes used in access control applications so that access can be granted even when the data connection to the back-end system is not functional. In such cases the data held on the interrogator may be limited to a small subset of any data held in the back-end. Even if the tag code is known, or intercepted, the only access to the personal or item information is by gaining access to the back-end system or to the data storage in the interrogator (which either means physical removal of the interrogator or access via the back-end network. It is not possible to extract the data via the RFID air interface. The data protection requirements for Region A can apply to the data.

Scenario 3 – The tag contains no data except data which is a pointer to additional data in the back-end system but has some relevance to the tagged item

This is very similar to Scenario 1. In this scenario the tag contains data which has no direct association to the specific item or person attached or carrying the tag but may be relevant in some way. The association between the two is contained in the Interrogator and/or in the back-end system. This is sometimes used in retail where the data in the tag corresponds to an item type and effectively duplicates the bar-code. Thus a product type, size etc may be apparent from reading the code (provided the schema was based on standard published coding) but not a specific product (there could be multiple products with that data). A unique non specific code may also be included.

[Does this require additional standards/protocols above the ones identified as applicable for Region A and B ?]

[Does this require additional standards/requirements in Region C? – for the air interface, or not]

[Is there an impact based on potential read range for the radio/air interface?]

[Does this require additional standards/requirements in Region D? – for the attachment or operation of the process, or not]

[Identify any specific standards gap]

Scenario 4 – The tag contains no data except a unique code which is a pointer to data in the Interrogator or back-end system but in use facilitates access into the back-end system

This is similar to Scenario 1 or 2. In this scenario the tag contains a unique code which is used as part of the access security protocols into the back-end system. As an example this could apply when an RFID tag was used as part of an authentication system, perhaps also together with a username, password etc.

[Does this require additional standards/protocols above the ones identified as applicable for Region A and B ?]

[Does this require additional standards/requirements in Region C? – for the air interface, or not]

[Is there an impact based on potential read range for the radio/air interface?]

[Does this require additional standards/requirements in Region D? – for the attachment or operation of the process, or not]

[Identify any specific standards gap]

Scenario 5 – The tag contains data which has direct relevance to a tagged item but not to any person

In this scenario the tag contains data which has association to the specific item it is attached to. This might be item information or transit information. It could be used where there is no connection between back-end systems and the necessary data is all contained in the tag itself. This might be used in specific transit or coding information. This could include specific drug/pharmacy or high security traceable products, product content and service information etc. This might become more common when used for cradle-to-grave eco-tracking (manufacture to waste disposal). If there is any link to a person or persons, then this is in the back-end system.

[Does this require additional standards/protocols above the ones identified as applicable for Region A and B ?]

[Does this require additional standards/requirements in Region C? – for the air interface, or not]

[Is there an impact based on potential read range for the radio/air interface?]

[Does this require additional standards/requirements in Region D? – for the attachment or operation of the process, or not]

[Identify any specific standards gap]

Scenario 6 – The tag contains data which has direct relevance to a person

In this scenario the tag contains data which has association to a person (usually the person holding/wearing the tag). This might be medical information or transit information. It could be used where a person has specific medical conditions and drug requirements and the necessary data is all contained in the tag itself in case of accident and need by paramedics (for example). It could also be used for financial information.

[Does this require additional standards/protocols above the ones identified as applicable for Region A and B ?]

[Does this require additional standards/requirements in Region C? – for the air interface, or not]

[Is there an impact based on potential read range for the radio/air interface?]

[Does this require additional standards/requirements in Region D? – for the attachment or operation of the process, or not]

[Identify any specific standards gap]

[Are there differences in requirements/standards if the tag holder agrees to the data being on the tag?]

[Is the closure of any standards gap likely to cause an additional security threat (for example would a “kill” function be exploited to give denial of service or worse)?]

Other Risks

The previous scenarios covered data type/location as the prime driver for security needs. It is based on the proviso that there are security requirements and standards which protect data in back-end systems. Thus it focuses on additional requirements that might become necessary by the addition of RFID in the different data scenarios. In cases where there are external, unauthorized, tag reading or writing there may be risks not fully covered. These could be included in a similar fashion. However they should be related back to the basic data scenarios as, for example the risk of unauthorized access to personal data by unauthorized tag reading in scenario 1, above, is almost non-existent, since not only does the pointer code have to be read from the tag but also unauthorized access into the back-end system has to be achieved in order to get the associated personal data.

One area not covered is scenario 1, but where the back-end system automatically visibly displays personal data on tag read. In a car park situation it might be a display that reads “Welcome Mr. XXXX”. There might be a need to look at these types of situation as it would provide information to prospective trackers located within a couple of metres; similarly to web pre-paid car-park entry using vehicle registration plate recognition systems.

EDItEUR ANNEX: BACKGROUND TO RFID IN LIBRARIES

EDItEUR's Role

EDItEUR is the international group coordinating development of the standards infrastructure for electronic commerce in the book and serials sectors. EDItEUR provides its membership with research, standards and guidance, including radio frequency identification tags. Established in 1991, EDItEUR is a truly international organisation with 90 members from 17 countries, including Australia, Canada, Japan, South Africa, United States and most of the European countries. EDItEUR works globally on behalf of:

Book and journal publishers, of all sizes and in all sectors

Book wholesalers and retailers

Subscription agents and other intermediaries in the library supply chain

Online content aggregators

Libraries (national, academic, special, public) and library consortia

Rights management organisations in these sectors

Systems vendors supplying any of these sectors

Other national and international standards organisations operating in the same or contiguous sectors

Trade associations representing any of these groups, at global, regional or national level

It was in its role that EDItEUR registered a set of data constructs with the ISO/IEC 15961-2 Registration Authority to preserve the integrity of RFID systems in libraries. It is in this role that EDItEUR has undertaken the review of the EU public consultation document with input from members in the library community including professional librarians managing RFID-enabled libraries and RFID system suppliers.

The Development of RFID in Libraries

A key point that we want to stress is that there is significant experience of RFID in the library community that .

The growth since then is reflected in these figures:

1998 1 library (Singapore)[4]

2005 300 libraries 120 million tagged items[5]

2009 2500 libraries 50 system integrators[6]

Our view is that this is an under-estimate and the number of libraries that use RFID for circulation control is between 4000 to 5000 globally. Most of the implementations are in public and university libraries, but there installations in schools (including Eton) and the Vatican.

The cost of the initial implementation of an RFID system has been calculated by Boss[7] as:

100,000 loan items $121,000

250,000 loan items $277,000

So using a coarse figure of $200,000 for the initial installation of a typical library, the total investment for 4000 RFID-enabled libraries is $800,000,000. With replacement RFID tags for new stock, an estimate of $1 billion dollars might be conservative, but it does indicate the significance of this application.

Another set of statistics is worth noting. There is a global catalogue of library loan items, known as WorldCat[8] and the current data shows that 1,634,869,510 items are on the catalogue from 72,000 libraries from 171 countries. As WorldCat is not used by all libraries, we can safely state that the estimated installed based of libraries using RFID is less than 5% of the total. So even though the sector can probably claim the largest installed base across more countries of any other item level RFID application, the potential market is largely untapped.

Main Applications

• Circulation control, especially self service check-out and returns

• Security

• Stock control

• Acquisitions

• External book returns

• Smart shelves

• Navigating the library …in development

The Process

The majority of applications use ISO/IEC 18000-3 Mode 1 tags operating at 13.56 MHz. Some Asian countries are using UHF technology, because of promotions by less experienced vendors. The scenario (below) is based on using the ISO/IEC 18000-3 Mode 1 tag on the loan items.

There are a number of different applications that library management are introducing, but currently only two interface with the customer (or member or patron): self service checkout and returns. In the near future customers might be provided with search facilities, but there are some technical challenges because of the closeness of books and that fact that many are displayed spine out. For simplicity, only books will be discussed, but this also applies to CD, DVD, BlueRay and other media when these are part of the self-service system.

After a collection of books have been selected, the customer takes them to a self service check out. The borrowing procedure is as follows: The borrower is identified by scanning his or her library membership card. This card can use bar code, RFID, or smart card (using ISO/IEC 15693 or 14443 technology). The books to be loaned are placed on the reading panel. The tags in the articles are read automatically. If the membership card uses RFID or smart card technology this can be read at the same time. The membership cards sometimes have additional functions, especially if the cards are assigned by a local government or university authority.

Libraries use different anti-theft mechanisms. The RFID based mechanisms are:

• Changing the AFI code from the code for "in stock" to the code for "on loan"

• Using a proprietary security feature on the tag that is deactivated

• Writing the unique chip id to a log

The security gates then uses one of the security features to ensure that all books that leave the library have been properly loaned, and not removed by accident or stolen. Library security gate systems also use separate EAS technology at 8.2 MHz or 10.5MHz frequencies.

The customer leaves the library with the RFID tags still in a readable state; so too is any RFID or smart card membership card.

At a later date, the customer returns the books that had been borrowed. In some libraries the returns, or check-in, system is very similar to the check-out system. In other libraries there is a book drop system that enables books to be returned at any time of the day or night.

RFID Tag and Data

The RFID tag contains the following data, which is now being specified in ISO 28560-2 (awaiting its FDIS ballot); but similar data applies to proprietary schemes too:

• A permanent 64-bit unique chip identifier that is encoded in a read only part of the memory.

• An AFI that indicates that this is a library book. The AFI is registered under ISO/IEC 15961-2. If the library does not toggle between two AFI codes, then the code equivalent to the "on loan" code is used, and in this case it recommended that this is locked.

• A unique loan item that is only unique within the library authority. In the UK this is one city, county, or university. In The Netherlands this is a national code. It is recommended that the code for the loan item is locked.

• Additional data is encoded on an optional basis. Migration is to a flexible structure defined in ISO 28560-2, or a fixed memory structure defined in ISO 28560-3. A code - International Standard Identifier for Libraries (ISIL) - may be used to identify the library on a global basis using a code defined in ISO 15511. If encoded, the ISIL is recommended to be locked. The combination of ISIL and unique loan item provides assurance to the library that it owns the book.

The Loan Item In Public

The AFI is intended to reduce interference with other applications that might be use the same RFID technology. A DSFID code is also used with ISO 28560 encoded tags to distinguish between the two encoding rules and any proprietary encoding.

While the customer is carrying the book, the use of the AFI avoids systems clash with other RFID applications, but obviously identifies the associated Item as something on loan from a library. The unique chip Id is readable with any basic 18000-3 Mode 1 (or 15693) reader. given that the book is in the possession of the customer for a limited amount of days, and then probably intermittently there is no permanent association. Also the fact that a book is returned and can immediately borrowed breaks the direct association.

Threats & Mitigation

Some of these are associated with the nature and structure of the sector covering libraries and the vendor community. Other are associated with features of the application.

There are a number of vendors of RFID system for the library sector. In turn, the majority of these companies do not provide the back end system, known as the Library Management System (LMS). So to find out more details of the loan item (other than reading the title of the book) and details of the customer, the following is necessary:

1 The RFID tag has to identify that it is for a library loan item – possible from the AFI.

2 The encoding rules (28560-2, 28560-3, national standard, proprietary) need to be identified – possible for 28560-2 and 28560-3 from the DSFID.

3 The library needs to be identified. The ISIL is optional encoded data and can only be found by decoding all the data on the tag with an understanding of ISO 28560. Interpreting the ISIL requires four pieces of information: that it is an ISIL, the decoding rules for the ISIL, access to the ISIL database, access to the national ISIL database. Alternatively, the library could be identified by association (location = probability of known library) but this breaks down in cities and for commuters. Also, because of inter-library loans a book can be borrowed from a library that does not own it.

NOTE: This is the basic purpose of WorldCat.

4 Assume that the library has been identified, there is now a possibility to access the LMS through the RFID front end system.

• Generally speaking the self-service check-in systems are networked to the LMS, so the network system might have a countermeasure to anyone using any hand held RFID device. The book drop returns system generally requires the book to be returned and the simpler ones have no computer (display) to the customer.

• An attempt could be made to access the data by cloning the data from the real RFID tag and presenting this to the system on a tag emulator. The membership card might be required to access any data on the LMS, so this might be a countermeasure. There might be additional membership authentication procedures.

• The alternative of hacking the system through the front end requires knowledge of the interface between the front end and LMS. Although 3M's SIP2 protocol is common it is not the only one. Then the data has to be presented to the interface in the way designed for the particular RFID / LMS interface, and qualified by any optional requirements by the library management.

5 Assume that an attempt is made to hack directly into the LMS. The RFID front end provides no clues as to which LMS is in operation and there are about twenty established systems. Each will have completely different database structures and security features.

All the previous steps (1 to 5) depend on using the user data, i.e. that actually encoded onto the tag as part of the system. There is one potential vulnerability based on the use made of the 64-bit chip ID. Given that more than one item is normally borrowed, this chip id is required to isolate each tag at the checkout station. If this is passed forward and matched with a record on the LMS then there is a more direct relationship, because all the other encoded data (AFI, DSFID, item identifier) are not required as part of a filtering process. So avoiding to hold this code on the LMS reduces some vulnerabilities. In fact, once the chip has been isolated for communication purposes, the front end system can used the loan item id.

Similarly if the chip id is used at the security gates, this should be the only data on the log for the interrogator at the security gate to assess. This way when the alarm is signalled, additional reading of encoded data is necessary.

In all libraries, the presence of the self-checkout station is an obvious indicator that the library is employing RFID data capture. However, the roll-out of RFID for a library authority probably results in a progressive investment programme. This will result in RFID enabled stock being in libraries where there is no RFID data capture. In The Netherlands this is taken to an extreme where all books supplied to libraries carry an RFID compliant with the national standard adopted by the library community.

Customer Reactions

There are direct benefits to customers in a faster transaction, and a general increase in the use of the library when measured in terms of visits or increases in number of transactions.

"Usage of the Library has increased by over 15% per week 28,000 visitors per week to 32,000, with over 150,000 additional visits. The entrance and exit figures show that students are spending more time in the Library than previously. Book usage has increased by over 5%, books issued 430,000 to 450,000."[9]

The Future

With the development of ISO 28560, there is certainly an opportunity to increase the number of applications in an RFID-enabled library at reasonable marginal costs, given that the items are tagged and a basic infrastructure is in place. A number of the applications, like inventory control, are purely aimed at internal efficiencies. However, others are likely to provide additional functionality to the customer.

The most obvious is to provide applications on mobile phones. Some will have no interaction with the tag, RFID data capture and the LMS: maps of the library layout. Others like item location might require access to the LMS and the capability to read RFID tags to find a specific item; this is still a challenge with special purpose readers because of the way books are stored on shelves and potential interference from other tags and even the shelves. The devices could also be used for remote renewal, which does not depend on RFID just access to the LMS. University libraries already provide such facilities over the Internet.

ISO 28560-2 has been written to anticipate new RFID technologies as it is based on ISO/IEC 15962 encoding rules. For example there is an anticipated development and product release of the 18000-3 Mode 3 tag. Therefore at some time in the future there could be a further migration in technology. The unique chip Id will not be a requirement for anti-collision purposes, But the Unique Item Identifier (UII) might need to be globally unique i.e. the ISIL (library identifier) + the unique item code within the library. Such tags might have password features, which will be much easier to manage with each library authority than an open supply chain.

The "holy grail" for the library community is to be able to use tags source-encoded by publishers for the retail sector, i.e. EPCglobal tags and then to overwrite then with ISO 28560 data. This will provide the library sector with free tags. The issue then is whether to use the EPCglobal UII (already encoded) or the ISO 28560 UII.

Existing Privacy Recommendations

The Guidelines for Using RFID Tags in Ontario Public Libraries prepared in June 2004 by Ann Cavoukian Ph.D., the Information and Privacy Commissioner for the Province of Ontario, Canada are provided under separate cover.

SC17 Annex

Canadian contribution to support Comment CA59

|Category/Issues |Explanation/comments |Threats and Risks |Ecosystem component |Control/measure |Standardization gaps |

| | | |involved | | |

|Retention limitation |The length of time for which the|Retention period |Backend systems |Automatic deletion or |Details are in clause |

| |data is kept |exceeds the period | |disabling of data at end|12 |

| | |of time necessary | |of retention period | |

| |Note that retention periods may | | | | |

| |be specified by other laws, | | | | |

| |regulations and so on (e.g., for| | | | |

| |financial or medical records) | | | | |

Canadian contribution to support Comment CA88

Annex D Table 3

DPPO-4 DPPO-3

DPPO-5 DPPO-4

DPPO-6 DPPO-5

DPPO-7 DPPO-6

DPPO-8 DPPO-7

DPPO-9 DPPO-7

DPPO-10 DPPO-8

DPPO-11 DPPO-8

DPPO-12 DPPO-9

DPPO-13 DPPO-7, DPPO-9

DPPO-14 DPPO-10

DPPO-15 DPPO-10

DPPO-16 DPPO-10

DPPO-17 DPPO-10 (Note that second column should read "tag content deletion")

DPPO-18 DPPO-11

DPPO-19 DPPO-11

DPPO-20 No counterpart

DPPO-21 No counterpart

DPPO-22 No counterpart

DPPO-23 No counterpart

DPPO-24 DPPO-2 (?)

DPPO-25 DPPO-3 (?)

DPPO-26 DPPO-3 (?)

-----------------------

[1] RACE Network RFID Deliverable 5.1.2

[2] Buchanan, M (2010) The greatest experiment of all time…, New Scientist, July 24, 2010.

[3] Furness, A (2007) The Need for Risk Assessment and Design Standard for supporting Privacy and Associated Security in RFID systems, UK Centre for RFID Paper based upon submission to the EC Expert Group on RFID.

[4] Palmer,M: "Making the Most of RFID in Libraries", pub: Facet Publishing ISBN 978-1-85604-634-3

[5] Birgit Lindl, Bibliotheca

[6] Bernd Tetyczka, NXP

[7] Richard Boss, at the ALA Conference, 2007

[8] 59:^_`op¬­ÓÔÕæçJ K o p q € ? ƒ „ ² ³ ´ Í Î êØÁاÁØÁØÁØ?Á€ÁØÁØfÁØÁØÁØLÁØÁ2[9]?j][pic]hB/Øh¢¯CJU[pic]hmH nH |sH tH |2[10]?j‚[pic]hB/Øh¢¯CJU[pic]hmH nH |sH tH |hB/Øh¢¯CJ

[11] University of Central Lancashire

-----------------------

A

B

C

D

Tagged Item or Person carrying tag

RFID Tag

RFID Interrogator/Reader

Control Computer, or back end system

Database or other data storage

Radio/Air Interface

Physical or locational connection

Network or data interface

Network or data interface

Region A

The data or information is contained within a computer, network or database system as a back end. Existing data security provisions are provided by:

[EU Directives & Regulations - List required]

[Standards - List required]

etc

Region B

The data or information is contained within the RFID Reader/Interrogator which is attached/controlled to/by a back-end system or database..

Existing data security provisions are provided by:

As for Region A (I assume the same requirements apply)

[Standards - List of any additional ones required]

etc

Region C

The data or information is transferred over a radio/air interface. Existing data security provisions are provided by:

RTTE Directive Article 3(c)

[Standards - List required]

Etc

Region D

The data or information is stored in the tag. Existing data security provisions are provided by:

[RTTE Directive Article ]

[Standards - List required]

etc

The physical or locational attachment does not make the tagged item or person part of the RFID System but security aspects may be needed.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download