Mitigate Unauthorized Tracking in RFID Discovery ServiceQiang Yan1, Robert H. Deng1, Zheng Yan2, Yingjiu Li1, Tieyan Li3

1Singapore Management University, Singapore2Nokia Research Center, Finland

3Institute for Infocomm Research, Singapore

September 2010

Outline

• Background & Motivation• Discovery Service based Tracking Attack• Pseudonym-based Design

– Basic ideas– Scheme I: supporting flexible tag level tracking– Scheme II: supporting user revocation

• Conclusion

Anti-tracking problem in EPCglobal RFID architecture

1. Tag information(e.g. EPC code, …)

2. Location query byunique identifiere.g. EPC code

3. Location information of associated IS servers

4. Request for processing current tags

5. Response of processing request

6. Update tag if necessary

Most of research works assume discovery service is trusted and focus on secure protocol design to defend unauthorized tracking at the physical level.

Most of research works assume discovery service is trusted and focus on secure protocol design to defend unauthorized tracking at the physical level.

It could be easier for an attacker to track information flow at the system level, e.g. from a compromised DS server.

It could be easier for an attacker to track information flow at the system level, e.g. from a compromised DS server.

DS is designed to be a restricted-access search engine.But it is still possible to compromise a DS server deployed on the Internet.

RFID discovery service enables tag-level tracking in EPCglobal Network

4

Tags are transported from Partner A to Partner B

Authorized User

1.Publish:(EPC1, L1, T1)…

2.Publish:(EPC1, L2, T2)…

3.Query: EPC14.Reply: (<L1, T1>,

<L2, T2>, …)

Supply Chain Partner A

Supply Chain Partner B

(EPC1, L1, T1) (EPC1, L2, T2)…

Discovery Service

Database Records on Discovery Service:

Unauthorized tracking by RFID discovery service through tag identifier grouping

Tag ID

Location Time

EPC1 L1 …EPC1 L2 …EPC2 L1 …

The adversary knows:A tag with tag ID EPC1 was transported from L1 to L2.

Database Table

Unauthorized tracking by RFID discovery service through timestamp correlating

Tag ID

Location Time

P1 L1 T1P2 L1 T1P3 L2 T2P4 L2 T2

Database Table

The adversary knows:A batch of two tags with pseudonyms P1, P2, P3, and P4 may have been transported from L1 to L2.

Threat Model – a semi-trusted RFID discovery service

• RFID discovery service will obey the regulations but try to learn the tracking information.

• It is always able to – understand the system design– read static contents of database

Threat Model – other roles

• Other outliers (weaker than RFID discovery service)– Only be able to eavesdrop network messages

• Supply chain partners and authorized users (Trusted)– Do not disclose the secret keys.– Do not collude with the adversaries.

Basic ideas to mitigate this threat

• For tag identifier grouping: – Minimize the correlation between records – by using different pseudonym to index multiple

records of the same tag

• For timestamp correlating:– Hide plaintext timestamps – by storing the ciphertext timestamps

Pseudonym Indexing

• Location records of each individual tag indexed by multiple pseudonyms.

• Pseudonym = Func (original tag ID, secret key)

• Func is a pseudonym generation function– Deterministic– Unlinkable– e.g. HMAC

Timestamp Encryption

• Supply chain partner should publish the encrypted timestamps to RFID discovery service.– RFID discovery service should not log the record

creation time.• Timestamp is not a index field.

– apply non-deterministic encryption algorithms., e.g. CPA-secure encryption algorithms, AES-CBC

– Easy for key management.

Revised Operation Model (Publish and Query)

Tags are transported from Partner A to Partner B

Authorized Discovery Service User

1.Publish:(P1<-EPC1, L1, ET1)(P2<-EPC2, L1, ET1’)

2.Publish:(P3<-EPC1, L2, ET2)(P4<-EPC2, L2, ET2’)

3.Query: {P1, P3}4.Reply: (<L1, ET1>,

<L2, ET2>, …)

Supply Chain Partner A

Supply Chain Partner B

Database Records on Discovery Service:

(P1, L1, ET1) (P2, L1, ET1’)(P3, L2, ET2) (P4, L2, ET2’)

…Discovery Service

Scheme I:Supporting flexible tag level tracking

KeyA KeyB KeyC KeyD KeyE

KeyA, KeyD, KeyE

Drawbacks of Scheme I

• Security manager has to be online– Who will be the security manager, after all?– Applies to static user group– User revocation is not supported

• To support user revocation– Assign new keys to supply chain partners– However, key update can not be handled well if

user group is large with frequent revocations.– How about periodic updating? Not so good, either.

Key Primitive Used in Scheme II• Security manager could be offline, we use Proxy Re-encryption

– Proxy re-encryption allows a proxy to transform a ciphertext computed under Alice's public key into one that can be decrypted using Bob's private key. During ciphertext transformation, referred to as re-encryption, the proxy learns nothing about the underlying plaintext.

– A proxy re-encryption scheme is represented as a tuple of (possibly probabilistic) polynomial time algorithms (KG, RG, E, R, D):

Scheme II: Supporting user revocation without online TTP

1. Supply chain structure or access control policies change.

4. Get the session keys by decrypting the ciphertext using his own private key.

3. Retrieve the encrypted

session keys after proxy re-encryption.

2. Send new access control policies and update re-encryption keys.

Security Manager stays offline if no structure or policies changes.

The only online service is discovery service that tells authorized users session keys by re-encrypting ciphertext of session keys.

Use random session keys for pseudonym indexing and timestamp encryption. (generated by supply chain partners)

Scheme II:When a user is granted for certain privilege,

1. Generate a key pair <pku, sku>.

2. Send pku

3. Generate re-encryption key rkSM->u from pku, pkSM, and skSM.

4. Send rkSM->u and updates of granting involved access control policies.

(If rkSM->u has been generated, Step 1~3 can be skipped.)

Scheme II:When a user is revoked for certain privilege,

1. Updates of revoking involved access control policies.

Other Privacy Issues

• Tracking information disclosure from access patterns– Split related pseudonyms into separate queries– Introduce delays or dummy data in publishing

location records to Discovery Service• Tracking information disclosure from collusion

attack– Trusted Computing Technique (use TPMs)

• The accomplices can use the secrets with knowing them.

Conclusion

• This work– Identified the threat of unauthorized

tracking by RFID discovery service.– Proposed pseudonym-based solutions to

mitigate this threat.