200 likes | 333 Views
Mitigate Unauthorized Tracking in RFID Discovery Service. Qiang Yan 1 , Robert H. Deng 1 , Zheng Yan 2 , Yingjiu Li 1 , Tieyan Li 3 1 Singapore Management University, Singapore 2 Nokia Research Center, Finland 3 Institute for Infocomm Research, Singapore September 2010. Outline.
E N D
Mitigate Unauthorized Tracking in RFID Discovery Service Qiang Yan1, Robert H. Deng1, Zheng Yan2, Yingjiu Li1, Tieyan Li3 1Singapore Management University, Singapore 2Nokia 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 DS is designed to be a restricted-access search engine. It could be easier for an attacker to track information flow at the system level, e.g. from a compromised DS server. But it is still possible to compromise a DS server deployed on the Internet. 2. Location query by unique identifier e.g. EPC code 1. Tag information (e.g. EPC code, …) 3. Location information of associated IS servers 4. Request for processing current tags 6. Update tag if necessary 5. Response of processing request Most of research works assume discovery service is trusted and focus on secure protocol design to defend unauthorized tracking at the physical level.
RFID discovery service enables tag-level tracking in EPCglobal Network Database Records on Discovery Service: Authorized User (EPC1, L1, T1) (EPC1, L2, T2) … 3.Query: EPC1 4.Reply: (<L1, T1>, <L2, T2>, …) Discovery Service 1.Publish: (EPC1, L1, T1) … 2.Publish: (EPC1, L2, T2) … Supply Chain Partner A Supply Chain Partner B Tags are transported from PartnerA to PartnerB
Unauthorized tracking by RFID discovery service through tag identifier grouping Database Table The adversary knows: A tag with tag ID EPC1 was transported from L1 to L2.
Unauthorized tracking by RFID discovery service through timestamp correlating 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 servicewill 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) Authorized Discovery Service User Database Records on Discovery Service: (P1, L1, ET1) (P2, L1, ET1’) (P3, L2, ET2) (P4, L2, ET2’) … 3.Query: {P1, P3} 4.Reply: (<L1, ET1>, <L2, ET2>, …) Discovery Service 2.Publish: (P3<-EPC1, L2, ET2) (P4<-EPC2, L2, ET2’) 1.Publish: (P1<-EPC1, L1, ET1) (P2<-EPC2, L1, ET1’) Supply Chain Partner A Supply Chain Partner B Tags are transported from PartnerA to PartnerB
Scheme I:Supporting flexible tag level tracking KeyA, KeyD, KeyE KeyA KeyB KeyC 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 3. Retrieve the encrypted session keys after proxy re-encryption. 4. Get the session keys by decrypting the ciphertext using his own private key. 2. Send new access control policies and update re-encryption keys. Use random session keys for pseudonym indexing and timestamp encryption. (generated by supply chain partners) 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. 1. Supply chain structure or access control policies change.
Scheme II:When a user is granted for certain privilege, 2. Send pku 1. Generate a key pair <pku, sku>. 4. Send rkSM->u and updates of granting involved access control policies. 3. Generate re-encryption key rkSM->u from pku, pkSM, and skSM. (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.