Transcript Pseudonym-based RFID Discovery Service to Mitigate

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
It could be easier for an attacker
to track information flow at the
system level, e.g. from a
compromised DS server.
1. Tag information
(e.g. EPC code, …)
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.
DS is designed to be
a restricted-access
search engine.
2. Location query by
unique identifier
e.g. EPC code
But it is still
possible to
compromise a DS
server deployed
on the Internet.
3. Location information
of associated IS servers
4. Request for
processing current tags
5. Response of
processing request
RFID discovery service enables tag-level tracking
in EPCglobal Network
Database Records on
Discovery Service:
Authorized User
(EPC1, L1, T1) (EPC1, L2, T2)
…
Discovery Service
1.Publish:
(EPC1, L1, T1)
…
Supply Chain
Partner A
2.Publish:
(EPC1, L2, T2)
…
Tags are transported from
Partner A to Partner B
Supply Chain
Partner B
Unauthorized tracking by RFID discovery service
through tag identifier grouping
Database Table
Tag
ID
EPC1
EPC1
EPC2
Location Time
L1
L2
L1
…
…
…
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
Tag
ID
P1
P2
P3
P4
Location Time
L1
L1
L2
L2
T1
T1
T2
T2
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)
Authorized Discovery
Service User
Database Records on
Discovery Service:
(P1, L1, ET1) (P2, L1, ET1’)
(P3, L2, ET2) (P4, L2, ET2’)
…
Discovery Service
1.Publish:
(P1<-EPC1, L1, ET1)
(P2<-EPC2, L1, ET1’)
Supply Chain
Partner A
2.Publish:
(P3<-EPC1, L2, ET2)
(P4<-EPC2, L2, ET2’)
Tags are transported from
Partner A to Partner B
Supply Chain
Partner B
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
Use random session
keys for pseudonym
indexing and timestamp
encryption. (generated
by supply chain partners)
1. Supply chain
structure or access
control policies change.
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.
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.