You are here: Resources > FIDIS Deliverables > HighTechID > D12.3: A Holistic Privacy Framework for RFID Applications > 
The Sleep-Command  Title:
BLOCKING
 Controlling the voluntary commitment

 

Blocking Access to the tags

The term “Blocking access” refers to practices which prevent any communication between reader and tag. 

A by principle quite basic approach is the Faraday cage. A Faraday cage in theory blocks all read or write attempts to tags by blocking the radio-waves from the reader to the tag, thus ensuring confidentiality and integrity of the data on tags. A popular example is wrapping an RFID-enabled electronic passport into aluminium folio. It is disadvantageous that the user has to actively act in order to get the protection. And it is difficult to determine if a certain Faraday cage can block read/write attempts in all situations. Furthermore, it does not seem feasible to put all tags into Faraday cages: e.g. tags which are sewn into clothes or which are merged with a product not working from within a Faraday cage, like a mobile phone. 

Blocker Tags

Instead of destroying, killing or putting to sleep, another approach is to block the communication between reader and tag. In , Juels et al. introduce such a concept. This is done by disturbing the anti-collision protocol which takes place at the network layer. Collision avoidance protocols are used in dense networks to prevent two or more tags to send at the same time. There are two popular collision avoidance protocols, the ALOHA protocol and the tree-walking protocol. The latter works by traversing a binary tree, which spans the available address space of the tag identifiers. The address space is narrowed down at each step, until only a single tag is answering, thus no collisions occur. The reader then communicates with this tag.

The blocker introduced in disturbs the reader’s selection process by simulating tags for each possible identifier, i.e. by answering each request of the reader. Thereby the reader will always get collisions, thus never stopping the tree-walking protocol and its attempts to single out one tag.

This simple approach has a couple of drawbacks. The blocking scheme by does not work with the ALOHA or other proprietary collision avoidance protocols. Then, the success of the blocking depends on the physical arrangement of the blocker and the tags and is therefore hard to predict by affected users. It seems difficult to block only the tags of the user wearing the blocker-tag and not tags of other users close-by. Another handicap is that the users have to actively apply the blocker-tag, which makes up an obstacle in usage. This is boosted by possible extensions of a simple blocking-tag, in which a user can define trusted readers which are not blocked.

Using external devices

The third example scenario is about blocking too, but at a more sophisticated level. In this scenario, a mobile phone takes over the control of tags and controls access to them via privacy policies, which are defined by the user (as illustrated in scenario S3). 

This section engages in proposed solutions which rely on some kind of external device to give the user control over his personal information and data. The basic idea is that external devices are much more powerful than any RFID-tag, especially the passive RFID-tags. Thus, the devices can take over privacy functions unfeasible to integrate into RFID-tags.  

In the so called “proxying approach” a trusted device (sometimes called “watchdog”) acts as a kind of surrogate between reader and tags and controls access to the tags according to user defined privacy rules. 

Instead of a direct communication between reader and tag, the reader first communicates with the proxy-device (watchdog), which analyses the request made by the reader and decides whether a reader may access the data of a given tag or not. Thus, this watchdog can secure the confidentiality of the tags (see Figure 6). 


Figure 6: Scheme of the “proxying approach”

The proxy-device first collects all the necessary data from the associated tags (1. and 2.) and afterwards communicates with the reader instead of the tag itself (4. and 5.). The tag is either send to a sleep mode or similar status, in which it cannot communicate with any reader, or the privacy-sensitive information on the tag are overwritten by the proxy-device (3.).

At this point a major drawback shows up: if the data is overwritten permanently, or if the tag is killed or destroyed instead of putted to sleep, the usability of the tags depends on the watchdog. Furthermore, the user has to carry a trusted device (which needs to exist at the first place, which is by far not the case right now!) and the watchdog device needs to be actively configured by the user according to his wishes. Further on, this trusted device needs some way to acquire and probably release the tags of the user. Problematic in particularly are cases when the tags have PINs associated with them, which control access to their data. These PINs have to be accessed and transferred in a secure way from the tags to the watchdog. 

Controlling Access by Authentication

Authentication is an important cornerstone of secure computing. In order for the tag to authenticate a reader, i.e. to check whether a reader has the rights to access the tag’s data, secure authentication methods must exist. This is also the case when a reader wants to authenticate a tag.  

In general, these secure authentication protocols and mechanisms exist, but it is difficult to port these schemes to low-cost, passive RFID-tags. The following text shows existing and newly developed measures for authentication. 

Symmetric cryptography

Symmetric cryptography stands for cryptography using a shared secret between the involved entities. The secret is used to encrypt and decrypt data sent between the entities. By proofing the possession of the secret, authentication can be applied. 

The classic but weak authentication mechanism uses a password. The tag stores a password and only reveals its information upon receiving the correct one from a reader. Thus a shared secret exists between reader and tag (in Figure 7 it is ‘key’). Since the password should not be sent in clear-text, a challenge-response scheme is often used: the tag challenges the reader with a (randomly) chosen value (cp. step 1. in Figure 7); the reader encrypts (‘enc’) this with the key (steps 2., 3. and 4.) and sends the cipher text back, which can be evaluated by the tag. It is crucial that the value is chosen randomly; else replay-attacks are possible. Therefore a random number generator (RNG) is necessary at the tag and the possibility to en- and decrypt messages.


Figure 7: Reader to tag authentication via the shared secret ‘key

The current password functionality of the EPCglobal standards does not protect the reading of the stored tag identifier (EPC). To ensure privacy, the standards have to be extended for read-authentication without the provision of the tag EPC. 

In many industrial scenarios the authentication of tag to reader is very important, e.g. to detect forged goods, a tag has to authenticate itself to the reader in order to proof the objects originality the tag is fixed upon. Again, authenticating the tag to the reader via a pre-installed shared secret is possible, and again a challenge-response mechanism should be used in order to avoid sending the secret in clear text. 

The tag to reader authentication is also the key point in the scenario S2. A user identifies himself using his proximity card. The card authenticates itself to the reader, thus the bearer of the card gains access to the facility. Additionally, the reader authenticates itself to the card, too. But as the scenario states, a breach in security is possible by simply scanning the tag and creating a new tag with the scanned data. The new tag is a digital copy of the old tag, which the reader cannot recognise without further security measures. To prevent such attacks, more sophisticated security principles have to be applied. The next section deals with asymmetric cryptography, which can provide more security than mere passwords. 

Asymmetric cryptography

Two usage scenarios exist for asymmetric cryptography: encrypting a message with the public key and decryption with the private key, and the other scenario is signing with the private key and verifying a signature with the public key. A general drawback of asymmetric cryptography is that its mechanisms need more effort compared to symmetric cryptography. Thus asymmetric cryptography usually is much slower than the symmetric counterpart. 

Cryptography with private-public keys does not require a shared key, but a so called Public Key Infrastructure (PKI). A PKI is required for the mapping between a key and its holder, because a public key is only valuable if the ownership of the key can be verified. This also implies that a Certificate Authority (CA), which issues the public key certificates, has to be available. 

Certificates then can be used to verify the ownership of a certain public key to an entity, here tag or reader. Translated into the Scenario 2, both the reader and the tags should have been equipped with certificates. Upon a request by the reader the tag asks for the reader’s public key, signed by a higher ranking certificate authority. A challenge-response protocol could then verify that the reader is also in the possession of the according private key. Only when the public key is valid and the reader could proof that it has the appropriate private key, the tag will answer any requests. A request could be another challenge-response protocol, initialised by the reader. The reader sends a nonce to the tag, the tag encrypts this with its private key, which can be verified by the reader using the available tag’s public key.  

Using their public keys, the tag and reader could exchange securely a secret, which after a successful authentication could be used to encrypt data. Thus, the communication would be protected against eavesdropping. 

Using this kind of approach, the read-out of the proximity card in Scenario 2 through an unauthorised reader could be prevented. The attacker’s reader is not in possession of the required private key, thus it could not authenticate itself to the tag. 

Although this approach is realistic for a security-application like proximity-cards, it is not applicable for low cost scenarios. Asymmetric cryptography is expensive, not only in terms of power-consumption at the use, but also in terms of fabrication of the tags. Furthermore, a public key infrastructure has to be established, which is complex and expensive, too. 

Regardless of the kind of encryption used, key management stays a key factor. There is no easy solution in sight. 

Using cryptography to enhance privacy

As stated in the beginning of this section, it is vital that the tags can be produced very cheaply. Otherwise, it is very unlikely that any major support by RFID-vendors will take place. Thus, it is crucial that security and privacy methods are designed which can easily be integrated into the existing RFID-designs and which can be produced in a low-cost manner. Current cryptographic functions and measures often concentrate on achieving a maximum level of security. Resource consumption has sparely been the focus-point of research. But for RFID-tags resource-consumption is a key-issue. Tags have to be cheap in production, need to be small in (physical) size and can only work with a limited amount of energy which is provided by RFID readers. Hence it is vital that any cryptographic method is suitable for the special needs of RFID.  

“Minimalistic Cryptography”

In Ari Jules presents a concept called “Minimalist Cryptography for Low-Cost RFID Tags”. The idea is to equip RFID-tags with a list of pseudonyms instead of just a single one. The tag rotates randomly through the pseudonym list and returns another pseudonym for each request. Instead of directly transmitting the pseudonyms to the reader, a kind of challenge-response protocol is executed, by which means the submitted value changes for each transmission, even if a pseudonym is requested more than once.

The tag communicates with verified readers only, i.e. with readers knowing a shared secret. Readers supply the tags with so called pads, which are used to “mask” the pseudonym before transmission. A tag combines a received pad with m previously transmitted pads, so that an attacker must eavesdrop all previously sent m pads to mount an attack. Attacks refer to swapping of tags and to breaking the confidentiality of the pseudonyms.

The paper introduces a couple of restrictions on the attacker. First, a weak attacker is assumed, i.e. an attacker may only interact a limited time with a tag before this tag communicates again with a trusted reader. Then there is the assumption that the attacker has a restriction on the ability to mount a man-in-the-middle attack, since it seems realistic to assume that a user is moving a lot with a tag, thus making it difficult for an attacker to mount a man-in-the-middle-attack at each point where the user moves to. Especially the later assumption only applies to weak attackers, because more sophisticated attackers can of course easily “simulate” a direct interaction between tag and reader by transmitting the necessary data over long distance networks like the nearly ubiquitous Internet.  

Practical problems arise from the fact that the proposed protocol requires multiple flows of data between the tag and the reader, which might diminish the effectiveness with which RFID‑tags can be read. Furthermore it is required that readers are online. All in all this seems to be an interesting proposal, but the attacker model has to be revised carefully. The proposed protocol would be an extension of the existing RFID-standard rather than a modification. 

Universal Re-encryption

An approach to minimise traceability could be to change the identifying part of the tag repeatedly. Problems occur when the changed identifier of the tag cannot be reversed to the original identifier, thus rendering desired functionality useless. A concept is needed, by which the ID of tags can be changed unpredictable for an attacker, but reversible for a valid user, e.g. the owner of the tag.  

In such a scheme is proposed, called “universal re-encryption”. The identifier of a tag is encrypted with the help of a public key, probably the one of the user, i.e. the owner of the tag. Whenever the user moves by an enabled RFID-reader, the reader reads out the current encrypted ID and re-encrypts it, without knowledge of the private or public key. The newly encrypted ID is written to the tag, and can be changed by the next reader. Thus, the tag identifiers change in a seemingly random way.

A common example is the scenario in which a user walks home from shopping and at certain points, e.g. banks or other publicly available trusted points, readers of these entities read-out all the tags the user carries in the shopping bag and change the IDs. At home, the user uses his private key to decrypt all the tags, in doing so restoring the original IDs, which can be used by the smart fridge afterwards.  

The proposed scheme does not require any cryptographic functionality at the tags themselves, but an infrastructure of RFID-readers, which can perform the re-encryption. Problematic is, that the scheme does not prevent tag-swapping nor does it offer integrity-safety. The latter is addressed by Ateniese et al. with an extension of the scheme („Untraceable RFID tags via insubvertible encryption”), which uses signatures of a central authority.

Proof for simultaneous scanning of tags

Cryptography can be used not only to avoid something, like traceability, but also to ensure certain properties, e.g. the integrity of data stored on the tags, or that two tags have been scanned simultaneous. Whereas the first example does not need further explanation, the latter needs some clarification on its usefulness. 

For example, medicine purchased in pharmacies must contain a leaflet describing the usage and side-effects of the medication. It would be desirable to have a proof by which can be stated that one tag has been scanned simultaneously with another tag.  

In such a method is described (see Figure 8). Every tag has a counter and a secret. A reader starts the protocol by requesting a = (A, ca, ra) from Tag A, where A is the identifier of A, ca is tags A current counter and ra is a secret (composed of the current counter and the secret key). Now the reader requests the so called MAC of B, which B computes using a and its counter: mb = MACxB[a, cb]. Now, this MAC is sent to tag A via the reader, which now can create its own MAC: mab = MACxA[a, b], whereas b=(B, cb, mb). mab is returned to the reader, which creates PAB = (A, B, ca, cb, mab), which can be used by a verifier V knowing the secrets of the tags A and B (i.e. xa and xb) to verify that both tags have been scanned at the same time.


Figure 8: Scheme of the simultaneous scanning of two tags with generated proof PAB

For this scheme to work the following prerequisites have to be met: First, the tags have to be tamper resistant, then the tags need some kind of timeout functionality to detect problems and last of all the readers have to be trustworthy. If these conditions are fulfilled, proofs can be created. Right now, this concept works only for two tags; it has to be investigated, if and how this scheme can be modified to support arbitrary many tags 

Tracking

As mentioned earlier, one of the risks which may emerge with a new quality by utilising RFID in every-day applications is the problem of tracking. RFID tags can be read out without direct contact, without the knowledge or consent of the person concerned and without leaving any traces.  


Figure 9: Tracking at different RFID layers

Tracking is a multi-layer problem. Next to tracking a tag via its EPC (unique global identifier), i.e. at the application layer, tracking may occur as well at the communication and the network layer (the three different layers are illustrated in Figure 9).  

Tracking at the communication layer

The communication layer defines the communication between reader and tag, e.g. collision-avoidance protocols resides at this layer. One popular collision-avoidance protocol is the tree-walking protocol, which has been described in chapter . When this protocol is used, tracking can take place by monitoring the tree-walking protocol and its results instead of the EPC.

To avoid tracking at the communication layer when using the tree-walking protocol, introduces the so called “silent tree-walking protocol”. It differs from the normal tree-walking concept insofar that the bits sent from the reader to the tags are encrypted. For the encryption, the reader and all the tags must share a secret.

To avoid key management issues, the shared secret can be derived from something the tags have in common. For example, assume that the tags have the same vendor, thus the first part of their EPC is equal. The reader asks for the “next” bit after the equal part of the EPC, i.e. the first “next bit” is the first bit of the object-specific part. At some point the first collision will occur, i.e. some tags will send a 0, some a 1. Now the reader must specify which tags should go on, and which should be singled out. Therefore, the reader sends lastBit XOR nextBit. The tags know which bit they sent last, so they can XOR the received value and determine if their next bit matches the requested bit. If so, they answer again. If a collision occurs, the reader request the next bit, encrypted by the previous bit, else if no collision occurs the reader just requests the next bit. In this way, the data from the reader to the tags is encrypted by the previous sent data. But the data from the tags to the reader is not encrypted but sent in plaintext.

This can only work, if we adjust the attacker model, so that an attacker may only eavesdrop on the forward-channel (from reader to tag) and not on the backward-channel, i.e. the channel from tag to reader. If this assumption is valid, this scheme yields in confidentiality of the tag-data. Additionally, the tags need to have the ability to compute XOR functions. 

In a more general scenario, one can use the limited range of the backward-channel to submit secrets from a tag to the reader. For example, a tag generates a random number and sends this to the reader via the short-range backward-channel. The reader can use this data to encrypt the data sent on the forward-channel. Again, if an attacker has access to the backward-channel (i.e. can eavesdrop the backward-channel), he learns the secret and thus breaks the encryption. 

Another approach to avoid tracking at the communication layer is given in . The singulation process requires an identifier for a tag which can be different from the EPC. Also, it is not required that this identifier is static. Avoine and Oechslin suggest using random numbers to provide identifiers. The random numbers change on a session-based manner. I.e., when a reader requests an identifier for the singulation process, the tag starts a session, for which a random number as a new identifier is created. The session is closed when the reader signals that the singulation process is finished or after a timeout. The timeout could be implemented using a capacitor.

Next to the technical problems like random number generation and reliable timeout at passive tags, this scheme is particularly problematic since it requires changes to current specifications like the EPC draft 5 or existing products like the ICode1 Label IC. Furthermore, the collision avoidance protocols used in current RFID systems are often proprietary closed source algorithms, making an in-depth analysis difficult. 

Tracking at the physical layer

The physical layer of the communication between RFID reader and tag defines the used transmission modulation, the frequency, timing etc. Tracking at this layer does not take place by using some identifier like the EPC, but rather by analysing certain patterns and behaviour of different tags. The basic assumption is that each tag is in some way unique, even if it has been produced by the same vendor in the same factory at the same production line. Minor differences in the way the transmission modulation, the frequency or the timing can lead to a kind of unique fingerprint for each tag.  

These properties cannot be avoided, but by reducing the diversity of standards used for the physical layer of tag to reader communication the differences between the tags can be reduced, thus leading to more similar fingerprints, which are harder to keep apart, at least at a reliable level. But it is likely that manufactures want to experiment with different technologies to produce tags in order to optimise performance, prize or size, rather than sticking to a few standards. 

Privacy enhancements by pseudonym usage

The use of pseudonyms could prevent the leakage of the EPC where a secure communication between reader and tag is not possible. 

The Hash-Lock method uses pseudonyms. In chapter the concept of putting a tag to sleep is introduced, which can be seen as a way of supplying a tag with a pseudonym. The tag always replies with its meta-id as a pseudonym, until a reader can provide it with the correct key. The key is used to build the pseudonym in the first place.


Figure 10: Scheme of the Hash-Lock method

Figure 10 depicts the hash-lock method. A tag replies to a request (1.) with its pseudonym, i.e. its metaId (2.). The reader then connects to a back-end database (3.). In the database (metaId – key) pairs are stored, which are returned to the reader (4.). The reader then sends the retrieved key to the tag (5.), which runs a hash-function with the key as input and compares the result with its stored metaId. Upon a match the tag returns the id (6.). The main disadvantage of this approach is that the metaId can be used for tracking, too, since it is static.

An advanced scheme is the “Random Hash-Lock” method that returns a hash-value with the tag-id and a random number r as input to the reader (2. in Figure 11). The reader has to execute a brute-force search in a database for a match (3.), i.e. the database has to execute the hash function for all ids in the database with the given random number r. Because of the brute-force search this method is only applicable in settings with a relatively small amount of tags.


Figure 11: Randomised Hash-Lock scheme

An interesting problem occurs when thinking about forward security. Assume a scheme like proposed by , i.e. where each tag has a bunch of pseudonyms which it uses randomly, thus avoiding traceability. A user carrying such a tag will leave weak traces, because databases will store different pseudonyms over the time, thus only giving an imperfect image of the movement of a user. But if sometime in the future an attacker gains access to the list of pseudonyms stored on a particular tag, the attacker could re-trace all steps, since he now knows all used pseudonyms. A late tracing process could start. To avoid problems like “back-tracing” in the future must be prevented, even if a tag or the data stored on the tag is compromised.

proposes the following solution: Each tag has an initial secret s. When a reader request the id of the tag, the tag sends ai=G(si), whereas G is a one-way hash function. After sending this hashed secret, the tag renews its secret to si+1=H(si), whereat H is another hash function. The reader needs access to a database where si is stored in. After receiving ai=G(si), the reader has to do a brute-force search in the database, matching ai to the secrets. After finding si, the database can identify the tag. Now si has to be updated at the backend to ai. The backend-database and the value stored at the tag are equal, again.


Figure 12: Forward security with chained-hashes; H and G are hash functions

This scheme is forward-secure because even if an attacker gains knowledge of the current secret stored at the tag, this attacker can only reconstruct the last point of access by a reader. All previous scans cannot be checked by the attacker, since the current value is a hash-value of the previous value. And since the hash-functions are one-way only, it is near to impossible to recap the previous id. Thus an attacker cannot track the movement of the tag. 

The problems with this scheme are evident: the reader must conduct a brute-force search, which takes a lot of resources. Then, the secret stored at the tag and the data stored in the database have to match. This property makes the scheme vulnerable to denial of service attacks. The method can be adjusted to be more fault-tolerant (thus less vulnerable to DoS attacks), at the expense of a more expensive search. And thirdly, the tags have to implement two one-way hash-functions, which is expensive. 

Privacy by voluntary commitment

Enforcing privacy via technical measures like cryptography or watchdog tags etc. is one way. Another way could be some kind of self-control or voluntary commitment, meaning that companies commit themselves to not misusing collected data and additionally to only collect data the users have given consent to. 

Soft-Blocking

Juels and Brainard propose the so called “Soft Blocking” . The idea is that users define a privacy policy in which they determine which data can be collected by which readers at which time etc. RFID-readers have to implement a policy-engine (either hard- or software) which evaluates privacy policies and determines, if a scanning of a certain tag is valid and in which way the collected data may be used. Thus the concept relies on individual user-made privacy policies which the readers respect and obey to.

The three main problems with this concept are: 

  1. The user has to define complex privacy policies, and vendors and operators have to implement according (complex) policy-engines. 

  2. The user has to trust that the readers will comply with the given rules, a control is hard to give (see below Section ).

  3. Attackers would not adhere to any rules, no matter how many privacy policies a user defines. 

The main-danger with concepts like this is that they are complex for the users to apply, which will lower the acceptance and usage, and that even if users embrace this concept, no real security and privacy is given, but the users imagine themselves in safety, which is not given! The P3P project aims to bring voluntary commitment to web-pages (mainly commercial ones), but it seems that this project cannot accomplish its self-imposed goals, the industry has no real interest in adhering to any privacy regulations in a voluntary way.  

 

The Sleep-Command  fidis-wp12-d12.3_Holistic_Privacy_Framework_for_RFID_Applications.sxw  Controlling the voluntary commitment
33 / 38