Trusted RFID Readers for Secure Multi-Party Services Andrea Soppera BT Research [email protected]

Trevor Burbridge BT Research [email protected]

Valentijn Broekhuizen University of Twente [email protected]

Abstract. Passive, small and inexpensive RFID tags are likely to serve as a future replacement of the barcodes. These tags fulfill the needs of current supply chain applications. Nevertheless, the lack of security features will prevent their usage in a broad range of applications where product authentication, data confidentiality and consumer privacy are requirements.

without notification or consent. Confidentiality is not just a consumer problem. End-to-end supply chain visibility can be very attractive proposition, but in practice supply chain partners will wish to manage the exposure of information to reduce the threat of competitive business intelligence.

We propose a variant on the current RFID reader called a Trusted RFID Reader. The concept is to allow secure modules to be installed in the reader to control the capture of RFID information. These modules can be validated by remote parties trough an automatic auditing process. A Trusted RFID reader can be used to allow voluntary privacy protection to passive tags, along with decryption and authentication services for secure tags. Furthermore, a Trusted RFID reader is fully compatible with current standards and can offer guarantees for supply chain integrity. These functions can be used to enable applications such as product authentication or drug pedigree.

Molnar, Soppera and Wagner [4] introduced the concept of a “Trusted RFID Reader” as a mechanism to mitigate consumer privacy concerns. The work in this paper extends the concept to more generic RFID applications by supporting multi-party managed services.

I. INTRODUCTION Radio Frequency Identification (RFID) tags and standard information architectures (e.g. EPCglobal) represent the future of collaborative supply chains. The full benefits of visibility across open loop supply chains will only be realised if there is trust among all the participants. This will allow each participant to share the maximum amount of information with partners while maintaining confidentiality and consumer privacy. As RFID tags are used in more open environments, and transferred along dynamic supply chains, then the requirement for integrity of data and processes increases. Introducing false data into the supply chain applications can subvert processes and can cause massive financial loss. There is a rising interest around RFID security. In particular “secure track and trace” for the pharmaceutical sector and “product authentication” to prevent counterfeit luxury goods and after sales components are areas requiring collaborative RFID systems. One major challenge is preventing false information entering into the supply chain from a supply chain partner. Another problem that has captured the attention of media and politicians is the privacy of tags attached to consumer goods. The problem is that RFID can enable the tracking of items and people

A Trusted RFID Reader can allow applications and control policies to be installed and operate securely on the reader. Operators can use remote attestation to confirm that the reader is operating as expected, and their service has not been corrupted. For example, in a secure track and trace scenario, the reader can authenticate a secure tag with a shared secret or by verifying the manufacture tag id. This can be performed locally without exposing the tag secrets to other parties. With a Trusted Reader, the goal is to enable the operation of assured processes over a shared infrastructure. This is achieved through the installation of multi-party services onto the Trusted RFID Reader. In this paper, we outline our motivation for this work. We explain how our early design can meet the requirements for a Trusted RFID Reader and summarise the operations involved in installing and operating services on the reader. We detail some of the security functions that we expect to be installed on such readers, and go on to explain how these secure functions can be used to construct multi-user services. Finally we discuss our experience with implementing a proof of concept Trusted Reader using a TPM [2] enabled laptop, and discuss the evolution of this work into a commercial RFID Reader within the EU BRIDGE Integrated Project [1].

II. MOTIVATIONS FOR A TRUSTED RFID READER It is important to begin by recognizing that is impossible to design a fixed RFID architecture that will meet the security requirements of all future applications. Only as such applications evolve will

reader can enable a voluntary mechanism to provide privacy protection for inexpensive passive tags. Organisations can operate their readers in accordance to strict policies. At the same time external agencies can operate auditing processes on the reader, with the needs of both parties protected by the Trusted RFID Reader. A secure reader can also ensure that information is not passed between multiple organisations requiring information from the same reader.

we understand the value of attacks against these systems and be able to deploy appropriate security mechanisms. One major motivation for this work is to allow some flexibility in the RFID architecture to deal with the needs of these unknown future applications. In this section we focus on the motivations for implementing a Trusted RFID Reader. The reader is the gateway between the ‘physical world’ and the ‘information world’ (such as the EPCglobal network). It is a common assumption the RFID tags have computational limitations and that tags without security will be widely deployed due to their low cost. For this reason a secure reader must be able to support future emerging secure tags, along with providing a initial point of security for tags that have little security capability. The following points discuss the further motivations for a secure open-service RFID reader: •

•

•

Identification vs. Authentication. A barcode commonly identifies the type of product to which it is attached. RFID allows this identification to be performed without line-ofsight and provides an extended architecture to support serial level data. Unfortunately identification does not provide authentication. An attacker can simply copy the code from a tag and apply it to another (potentially counterfeit) product. Future uses of RFID will require a combination of e-pedigree and anticloning measures on the tag, label or product to ensure authenticity. Such functions require support in the reader to ensure authentication checks are not corrupted. Open-Loop Systems. Today the EPCglobal network does not fully exist. Most applications are vertically integrated and RFID infrastructures are scarce and fragmented. Nevertheless, specific applications sectors such as the pharmaceutical industry are pushing for global solutions for combating counterfeiting and preventing ‘grey market’ distribution. Readers will not always be operated by fully trusted partners, or those with good internal IT security. The reader should offer an environment where parties can install application functionality and check the operation of their services and business processes. Privacy and Confidentiality. We have already mentioned the media interest on privacy issues for consumer applications. Increasing supply chain visibility will also create a requirement to limit the exposure of tag data. Security on the

•

Supply Chain Data Integrity. Process disruption and more specifically threats of false information injection can be considered major concerns in open loop systems. Closed loop systems are less affected due to their scale and the levels of trust between participants. Attacks on the reader could result in the modification of RFID read event data. Genuine reads may be blocked or modified, and false read events introduced. Another spoofing attack would be impersonating the reader. A secure reader should prevent such attacks by securing the operation of the reader and authenticating the identity of the reader.

•

Key Management. Future applications will require tags with cryptographic measures and anti-cloning features. These tags use secret keys to control access and to perform encryption and authentication. The distribution of these secret keys will pose major problems in terms of security and key management. Using a back-end system to perform all tag security functions is not scalable, yet the reader operator may not be trusted to perform these operations or securely store the tag secrets. Furthermore readers may have to operate on tags with different security capabilities. This means that we need a reader with flexible support for security features.

This paper focuses on building a reader that allows multiple parties to protect their interests in the RFID reader. Such parties may be the consumer, government agencies, the reader operator or applications of the RFID data. We believe that a Trusted RFID Reader that allows the secure operation of services from multiple parties is a key building block in a global RFID Architecture.

III. DESIGN OF A TRUSTED RFID READER In this section we discuss the requirements for a secure RFID reader that protects the interests of multiple parties. This includes both the confidentiality of data, and of the integrity of

processes. We show how these requirements can be met through the use of a layered open service architecture using a Trusted Computing Module, and illustrate the key operations involved in installing and operating secure services.

•

Enforcement. The Trusted RFID Reader needs to enforce the actions that an operator or user is able to perform. Underlying this are the actions of the individual software components of the system. Such components should be identified before being allowed access to system resources. For example the platform should not allow the execution of newly introduced or modified components. This can be achieved by validating system state against a previously known trusted state. This is implemented throughout the different layers of the reader to create a “chain of trust”. For example the boot loader will verify the Operating System before allowing it to load.

•

Attestation. The operator and users of the Trusted RFID Reader should have a means to communicate with the reader to check the current operating state. Attestation is the process of reliable integrity reporting to local or remote entities can be used to (remotely) verify the state of the platform.

•

Secure Storage. The Trusted RFID Reader must provide secure storage capabilities available to the application services. Information stored using this capability should not be available to other users, the reader operator, or attackers who have compromised the reader. Only the correct application should be able to retrieve the keys to unlock data, and only if the overall system has not been compromised (matches the known secure state).

•

Identity. The reader should have a unique secret key that can be used to identify the reader. Application services may also present unique identification credentials, in which case these should be protected by the secure storage.

•

Open Services Platform. The reader should support the rapid deployment and management of services composed from reusable functions. We require service life-cycle management: services need to be installed, started, stopped, updated and uninstalled. Services may be stand-alone or rely existing services. Different components in the service platform need to be able to authenticate each other to prevent impersonation and need support from the service environment to check the state of the deployed service. The service platform furthermore needs to be able to manage resource rights for service components, to control access between services and to other resources such as the file

A. Requirements A Trusted RFID Reader must provide a platform for local application execution that protects both the confidentiality and integrity of our business processes. This includes data transferred between the reader and RFID tags, along with data communicated with RFID middleware and business applications. Such local applications running on the reader may be owned by parties that do not have complete trust in the owner or operator of the reader. The Trusted RFID Reader should therefore provide a platform that securely separates the users of the reader from the reader operator, and provides confidence to the users that the application services are operating correctly and not leaking information to the reader operator. In addition mutually untrusted parties may operate multiple application services on the same reader. A user of the Trusted RFID Reader should be invisible to another user. Furthermore it should not be possible for a user to disrupt the application services of a second user. If secure RFID tags are used, for example with access control for reading or writing tag data, the Trusted RFID Reader should provide a platform to assist these operations. This means that the Trusted Reader should be capable of securely storing secrets that allow the reader to mutually authenticate with the tag before exchanging data. In addition the reader may store other sensitive business data that is used during the operation of the local application services. All such data should be owned by the user’s local application and maintained separately from other users or the reader operator. In communication with external applications the reader should be able to provide an authenticated identity to prevent impersonation of the reader. This allows applications to securely determine the source of communications received from the reader. This includes the origin of RFID tag read events, other communications from the local reader applications, and management communications from the reader platform. From these requirements we are able to define a set of capabilities that the Trusted RFID Reader must implement:

system. The service environment must maintain separation between services to protect a wellbehaved service from rogue peers.

for the reader hardware, along with encryption and secure storage functions that are used to record and test the state of the layers above the

B. Roles To manage the Trusted RFID Reader, loaded functions and instantiated services we distinguish between three roles: •

•

•

Manufacturer. The manufacturer is the vendor of the base Trusted RFID Reader. The manufacturer is not expected to ship the reader with any services although some manufacturers may include these to add value. The manufacturer must include the Reader Module and OSGi Service environment, along with some additional security modules. These components provide the basic operation of the reader, allow the installation of functions by the reader operator, and service instantiation by the reader users. Operator. The reader operator is typically the owner of the RFID reader. In our design the reader operator is solely responsible for the installation of new functions onto the reader, and the configuration of user access rights. The operator has the ability to perform attestation of the base reader operation and audit the installed service components. Users. Users of the Trusted RFID Reader are granted permissions by the reader operator. These permissions allow the user to select functional components to compose into instantiated services. In addition the user gains default rights to perform attestation of the reader, and check the operation of their own services. Where services rely upon other services, users may wish to grant rights to other users to check their operation. Users may build services from functions that include interfaces for other parties. The implementation of access control of such interfaces (such as an audit interface) is left to the installed function and does not relate to the roles, identities or access controls of the Trusted RFID Reader. C. Components

To realize the Trusted RFID Reader architecture, we make use of a set of open technologies. The layers of the architecture all build from the capabilities of a Trusted Platform Module (TPM) [2]. The TPM is critical to establishing a chain of trust from the reader hardware. This prevents the subversion of the application services through attacks at a lower layer. The TPM provides a unique identifier

TPM. Figure 1 shows how these layers are constructed. Figure 1. Trusted RFID Reader Architecture Above the TPM, we create a chain of trust through to the application services on the Trusted Reader and beyond to external applications. The layers between the TPM and the service environment consist of the reader BIOS, secure boot loader and a secure OS. The BIOS and boot loader should record the state of the layer immediately above for later attestation. The Operating System should support attestation of applications, but should also provide enforcement. The OS enforcement is used to restrict the applications allowed on the reader to a known set. This known set includes the base RFID reader capability, along with the open service environment. Any additional user application services must be executed within the service environment rather than directly above the Operating System. For the service framework we selected the Javabased Open Services Gateway initiative (OSGi) [3] framework. OSGi offers a resource friendly way to (re-)use collaborative service components in the form of bundles, including a security model based on Java2 Security [7] that allows role-based authentication and access control. Service components can be registered into a Service Registry, and service component life-cycle activity is monitored by a Service Logger. Furthermore, we introduce an Attestation Service, which provides an interface to (remotely) verify the state compliance of the platform.

In section VI we discuss our choices for these software building blocks in more detail. D. Establishing a Chain of Trust When the reader is booted, the components of the chain of trust will start loading step-by-step, starting from the TPM, followed by the BIOS, the boot loader, the Secure OS, Trusted Reader modules and service environment, followed finally by user services. Each time a component is executed, a hash measurement of the next layer is taken, and compared with a securely stored known state. Only if there is a match should the execution control be turned over to the next step. The last step before the user services is the execution of the OSGi framework, including the Service Registry, Service Logger and Attestation Service logic. All the components outside the service environment are assumed to be long-lived and common between many Trusted RFID Readers. We assume that the upgrade to such components should be performed only with the permission of the reader manufacturer, and that both the reader operator and users of the reader trust the manufacturer to install well-behaved components. The upgrade of these components requires the resetting of the known secure state for each of these components, and this ability should be tightly controlled.

trusted. The action taken in such instances should derive from an operator policy and user preferences. Common actions will include stopping the service, and alerting the user and operator. The operator also defines user roles in the service registry, along with access control rights for service components. This allows users to use particular service components, while preventing other users from using it. F. Instantiating Services Any user that has access to a particular service component installed into the registry can deploy the service component as part of a user service. At this time the integrity of the component is verified against known secure state and the Service Logger records the result of the deployment activity. These service logs are, like the service registry data, securely stored and only alterable by a Service Logger in a known secure state. In addition to logging the failure of any component to pass this test, the component may be prevented from deploying and the user notified. Users and the operator are able to audit the service activity within the framework and the installed components through inspection of the

We can consider that the chain of trust also extends through the users’ business applications. Known service components executed within a known service environment can be trusted by external applications. E. Installing Functions To add new functionality to the framework by means of service components, an operator installs and registers the new service components in a service registry. The authenticated reader operator should perform this operation. Alternatively the reader operator may sign service components to allow their installation by other parties. This model is similar to that used by mobile phone operators and supported by device operating systems such as Symbian [12]. To support the later auditing of service components, a hash is taken from the component and securely stored by means of a platform tied encryption key. Only a reader in the correct known state can update the expected values for the service components. Components that fail this check on instantiation into a user service are not

service registry and service log. Figure 2. Building Services on the Trusted Reader G. Attestation Users and operator can verify the correct working of the framework by means of attestation of the enforced software state. Although each layer may apply enforcement during the execution of components in the next layer, attestation is

required for external parties to check the compliance of the Trusted RFID Reader. For example, a user of the reader will require attestation of the reader before trusting it to instantiate a user service correctly. The attestation process is based on sending an attestation request together with a random value or nonce to the attestation service. This attestation service sends a response consisting of the current system state. This returned state, along with the authenticated identity of the reader are then used to verify the compliance to an expected state. The attestation can be considered to be performed in two parts. The first part is the attestation of the fixed functionality of the Trusted Reader. The reader operator along with users of the reader may perform this part. The second part of the attestation is the state of the service components deployed within user’s service. To maintain separation between users this attestation should only be allowed for the service owner.

IV. EXAMPLE SECURE SERVICE COMPONENTS Although potentially any service component can be installed onto the Trusted RFID Reader, those that gain the most advantage are those with strong security requirements. In this section we outline several such functions and discuss how the Trusted RFID Reader can meet their security needs. A. Privacy Filtering Function The purpose of a privacy filtering function is to restrict the visibility of RFID read events. Such a function can enhance the operation of the Trusted Reader with both secure and public RFID tags. For tags without security functions, the privacy filter on the Trusted RFID reader provides a mechanism to build consumer trust without the cost and management burden of using secure RFID tags. For secure tags the privacy filter may be operated after a function to decode the tag to allow policies specific to the tag data. Any privacy filter will implement a privacy policy. This policy will express which RFID tags are visible to different applications. A simple policy held by the reader may state that tags that implement and set a ‘privacy bit’ will not be read. In this manner the policy is distributed between the Trusted RFID Reader and the RFID tag itself. Such privacy bits can be extended to indicate public privacy policies that may be fetched from external systems [11]. More complicated policies held by the reader may state that only certain number

ranges may be read and passed to specific applications. Since the privacy filter operates within the Trusted RFID Reader, external parties can be assured that the privacy filter is operating correctly and enforcing the specified privacy policy. A different authority to the applications that use the resulting RFID event stream may set this privacy policy. In this case the policy setter must be trusted by the applications, since manipulation of the policy could disrupt their business operations. The policy setter must also ensure that the applications are not permitted to receive a raw unfiltered RFID event stream. This can be performed by remote attestation of the application service (to check that a privacy filter function is being operated by the service) along with checks that no alternative application service is operating on the reader without such a privacy function. We believe that such a model places too much control with the policy setter. This exposes the system to external attacks and hinders the alteration of the reader application since the policy setter must be involved in the agreement. Instead we propose that privacy policy is set by the application service and audited by an external agency. B. Privacy Filter Audit Function In this model the application service implements a privacy filter and specifies the policy for their application. This allows dynamic changes to the reader (such as movement between sites), along with changes in the application services installed on the reader. Instead of setting policy, the external agency audits the policy implemented by the application. The auditing agency must also audit the historical record of policy changes, and thus such logging must be implemented by the privacy filtering function. An external auditor must perform several steps: 1. Check that no application services (with access to the RFID event stream) that are not included in the audit are operating on the Trusted RFID Reader. 2. Attest that the application service is operating correctly including a privacy filter function and an auditing function. 3. Connect to the Privacy Filter Audit function to retrieve the current privacy policy and historical change log. The Audit function should also retrieve the uptime log of the Trusted RFID Reader. During periods of downtime the reader may have been operating in breach of the privacy policy.

4. Compare the current state of the reader against declared operating parameters and take action in event of a policy breach. For example, the application owner may have informed the audit agency that only RFID products stored in their inventory may be read and the reader will have no downtime periods during the opening times of the retail store. C. Secure Tag Decryption/Authentication The use of secure RFID tags without a Trusted RFID Reader presents a problem. Tags that implement access control require a secret to read the tag. Similarly, tags that implement authentication also require such secrets. Since the reader is not trusted, the secret storage and decryption/authentication function must be performed by a secure back-end system. If the network or decryption system is unavailable then RFID data (the identifier and other data such as authentication) will not be retrieved. In addition such continuous network lookups are costly in terms of network and server provision and reduce the maximum read rate of tags past the reader. Tags must be maintained within the reader field while the decryption or authentication takes place. The Trusted RFID Reader allows the implementation of a local decryption or authentication function. A lightweight key server can download secrets to these functions with assurances that the secrets will be stored securely (should the reader be compromised), and that such secrets will not be leaked to other application services on the reader, or to the reader operator. Such secrets can be downloaded in advance of the tag arriving at the reader based upon intelligent analysis of the supply chain process. If the decryption function on the reader does not have the correct key, then occasional communications with a back-end system can retrieve the key for that tag along with a cache of keys that may be required in the near future (such as products in the same batch). The decryption or authentication function should use the secure storage capability of the Trusted Reader. For example, the database of secrets should be encrypted with a key that is held in the secure storage of the TPM. Only the component that placed the key into the storage will be able to retrieve it. D. Secure Message Transport Function Applications designed along SOA Oriented Architecture) principles

(Service typically

separate transport services and other ‘middleware’ functions from the business logic of the application. The use of the Trusted Reader allows such transport services to be operated on the reader for the shared use between multiple applications. Each application needs to assurance that the messages sent to the transport function are delivered correctly and not leaked to other parties. Where such a transport operates a publish/subscribe paradigm, the client subscriptions are also potentially sensitive information. The transport may also authenticate messages as originating from the Trusted Reader. In this case the authentication keys should be maintained using the secure storage capability to avoid impersonation of readers. The message service can also act as a mutually trusted party between the service on the reader and the external party, for example in an e-pedigree scenario where there are contractual obligations to submit data.

V. BUILDING SECURE APPLICATIONS As discussed above, we can load application functions onto the Trusted RFID Reader. Although such functions may be built by many different parties, we have assumed that these functions are loaded by the reader operator to aid the management of the Trusted RFID Reader (avoiding the requirement for access control policies for who can load new functions). Once the functions are installed on the Trusted Reader, one or more functions may be instantiated by a user into a service. Such instantiation should verify that the function component being instantiated is the same as the function initially loaded by the operator and has not been compromised during the storage on the Trusted RFID Reader. The user should perform a remote attestation of the Trusted Reader during the instantiation of their service to assure that the Trusted Reader will perform such integrity checks correctly. After their service is running, the user should periodically repeat the attestation process. This ensures that the reader has not been compromised, and that the expected service functions are still operating and malicious functions have not been introduced into the service. By default a user should only be allowed to check the integrity of services and resulting file storage that they own. This prevents a user from discovering which services other parties operate. Some services may wish to allow other users to perform checks. For example a shared message

transport service may allow all other services to check its operation since they depend upon its correct function.

OSGi, we can force other service components to use the policy filter, thereby preventing the circumvention of this service.

VI. IMPLEMENTATION OF A PROOF-OF-CONCEPT TRUSTED RFID READER

The policy filter is accompanied by a policy logging and audit function that maintains keeps a record of all policy filtering activities. These logs are protected by the TPM and can be audited by external agencies to ensure that the policy filter is operating as expected.

We have constructed a prototype according to the design introduced earlier, based on an IBM Thinkpad T42 with an integrated Atmel TPM. To create a chain of trust, we included the TrustedGRUB boot loader [6], Enforcer security module [5] and the TrouSerS [9] application level trusted computing stack, and placed the Knopflerfish [10] OSGi framework on top of it. The RFID Reader Module for our prototype is a lightweight interface to an external commercial CAEN RFID Reader [8]. This was necessary since the current commercial controller board for the CAEN reader is not available with a TPM, or extended memory and processing capabilities. These modules provide the persistent part of the Trusted RFID Reader together with Service Registry, Service Logger and Attestation Service. These latter software components are build on the APIs provided by OSGi and TrouSerS. The Service Registry and Service Logger need to securely store the service registry data and the service log data respectively. When the component is installed a hash of the component is taken. This hash value is added to the registry, which is encrypted with a public encryption key protected by the TPM. If the system is not in the expected state then this key cannot be retrieved from the TPM and the registry file cannot be opened for modification. During the deployment of the component a hash of the current state is checked against the hash retrieved from the service registry, to ensure that the component has not been compromised while stored on the reader. The new hash is recorded in the service log. If the two hash values do not match either an alarm is raised or the component is prevented from deploying. We have implemented example service components in our prototype to enact the privacy filtering scenario described above, and to enable the multi-service Trusted RFID reader to fulfil the role described in the earlier work of Molnar, Wagner and Soppera from which this paper is extended [4]. The privacy filtering component allows users to define policies for RFID tag filtering. In our proof-of-concept these policies consist of simple lists of tag ID ranges that are allowed to be read. Due to the dependency mechanisms in

We have also created two additional user components that combine with the privacy filtering and audit components to form a complete application service. These consist of a checkout service, which mimics a virtual shop counter, and a product authentication service, which authenticates tags against a database. Finally, we have implemented the external management consoles to perform remote attestation and auditing of the service registry data and service logs.

VII. CONCLUSIONS AND FURTHER WORK We have shown that previous work in Trusted Computing and open service environments can be applied to design a Trusted RFID Reader. Such a reader can maintain the interests of multiple parties. Implementation these capabilities in the reader is critical for operations involving secure RFID tags, and other processes where the cost of subversion is high and the confidence in business partners is low. The later stages of this work have been developed within the EU BRIDGE project, where we plan to continue to development of proof-of-concept into a prototype based on a commercially available RFID reader. We can then demonstrate how secure tag protocols also developed within the BRIDGE project can be quickly and easily supported and deliver information to multiple parties and a variety of business scenarios.

VIII. REFERENCES [1] [2] [3] [4]

BRIDGE EU Integrated Project. www.bridge-project.eu TCG (Trusted Computing Group). https://www.trustedcomputinggroup.org OSGi. http://www.osgi.org/ D. Molnar, A. Soppera & D. Wagner. “Privacy for RFID Through Trusted Computing”, Proceedings of the 2005 ACM workshop on Privacy in the Electronic Society.

[5]

Enforcer. http://enforcer.sourceforge.net/

[6]

TrustedGRUB. http://www.prosec.rub.de/trusted_grub.html

[7]

Java 2 Security. http://java.sun.com/j2se/1.3/docs/guide/security/

[8]

CAEN RFID Reader. http://www.caen.it/rfid/index.php

[9]

TrouSerS. http://trousers.sourceforge.net/

[10] [11]

[12]

Knopflerfish. http://www.knopflerfish.org/ C. Floerkemeier, R. Schneider, M. Langheinrich. “Scanning with a Purpose - Supporting the Fair Information Principles in RFID protocols”, Revised Selected Papers from the 2nd International Symposium on Ubiquitous Computing Systems (UCS 2004), November 8-9, 2004, Tokyo, Japan Symbian OS. http://www.symbian.com/