Workshop on RFID Security 2009
June 30 - July 2, 2009, Leuven
Semi-Destructive Private Rfid Systems
by
Paolo D’Arco, Alessandra Scafuro and Ivan Visconti
University of Salerno
Italy
Focus of this paper
Vaudenay’s Privacy Model [Vau07]
Asiacrypt2007
It abstracts and extends in a clear, concise and general
framework some previous Rfid privacy models
[e.g. Avo05, JW06, DO06]
Contribution
 An “extension” of the model to take into account
certain physical attacks
 A new privacy notion – semi-destructive privacy - which
is achievable throught symmetric primitives
Rfid Scheme
Tag
Reader
secure
channel
Backend Server / DB
Rfid system
• SetupReader: generates key materials (Ks, Kp) + resets database DB
• SetupTag: tag ID receives an initial state S and (ID, data) is inserted into DB
• Protocols
Tag
(S)
Reader
(Ks, DB)
Output ID (if valid) or _|_
Functionality
Correctness: Identification under normal execution
Crypto properties
• Security: an Adversary cannot impersonate a tag
• Privacy: anonimity, unlinkability, …
Real World
Eavesdrop, intercept,
modify, corrupt tags…
Reader
Out-of-range tags
Adv
vtag1
vtag3
vtag2
Security and Privacy Definitions
Rules
GAME = Adversary’s Goal
Oracles and Oracle Queries
(vtag1, ID1)
(vtag2, ID2)
…
DrawTag
CreateTag
distr
vtag, b
SendTag
ID b
π
msg, vtag
msg, π
msg
msg
vtag
Free
Launch
vtag
S
Send
Reader
π
b
Corrupt
… Adv reproduces real executions of the protocol
Result
Security Game
Winning condition for Adv: the reader identified ID but
this (uncorrupted) tag did not have any matching
conversation with the reader
Definition
An Rfid scheme is secure if, for any polynomial bounded adversary,
the probability of success is negligible
Privacy Game
Intuition: the transcript of real protocol executions
does not provide any help to the adversary which is
trying to infer some relations about the tags which
played the protocol
Privacy Adversary
ADVERSARY
CreateTag, FreeTag, CorruptTag
Querying
Phase
Launch, SendReader, SendTag, result
DrawTag
Analysis
Phase
True/False
(vtag1, ID1)
(vtag2, ID2)
…
Table
Adversary winning condition = True
Blinder
A Blinder is an interface between the adversary and the oracles that:
• passively looks at the comm. to CreateTag, DrawTag, Free, Corrupt
• simulates the oracles Launch, SendReader, SendTag, and Result
CreateTa
g
DrawTag
distr
SendTag
Free
ID b
π
msg, π
vtag, b
msg, vtag
msg
msg
vtag
Launch
vtag
S
Corrupt
Send
Reader
π
b
Result
Blinder
CreateT, FreeT,
CorruptT
Launch, SendR,
SendT, Result
Query
Phase
DrawTag
Analysi
s
Phase
True/False
(vtag1, ID1)
(vtag2, ID2)
…
Table
BLINDED ADVERSARY
ADVERSARY
Privacy Game
CreateT, FreeT,
CorruptT
Launch, SendR,
SendT, Result
Query
Phase
DrawTag
Analysi
s
Phase
(vtag1, ID1)
(vtag2, ID2)
…
Table
True/False
An Rfid scheme protects privacy if, for any polynomial bounded
adversary A, there exists a polynomial bounded blinder B, such that
Pr[A wins] ≈Pr[AB wins]
Privacy Notions
Defined through restrictions imposed to Adv on the use
of the oracle queries
CorruptTag Query
With Result Query
No Result Query
Not allowed
Weak
Narrow Weak
Only at the end
Forward
Narrow Forward
Allowed
(but tag destroyed)
Destructive
Narrow Destructive
Allowed
Strong
Narrow Strong
State of Art
Privacy Notion
Cryptographic Tool
Weak
PRF
Forward
PKC
Destructive
?
Strong
Impossible
Narrow Destructive
In ROM model
Narrow Strong
PKC
… Weak and Forward are the only non-narrow notions achieved.
Destructive is an open problem …
Extensions/Revisitations of the Model
1. [NSMSN08] RFID Privacy Models Revisited, ESORICS08
… the eight notions collapse to three under certain assumptions
on the adversary capabilities and properties of the RFID scheme
2. [PV08] Mutual Authentication in RFID: Security and Privacy, ASIACCS08
… extension of the model to deal with mutual authentication
3. [SVW09] Anonymizer-Enabled Security and Privacy for RFID, RFIDSec09
… extension of the model with anonymizers
4. [BCI] Efficient ZK Identification Schemes which respect Privacy, ASIACCS09
… framework to transform ZK schemes in private schemes
Our work
A Narrow-Destructive protocol
Simplified version [Vau07]
F, G random oracles Tag and Reader have access to
Tag
Reader
state: K
{… (ID,K)…}
a
c=F(K,a)
replace K by G(K)
Pick a in {0,1}α
c
find (ID,K) s.t. c=F(K,a)
replace K by G(K)
output: ID
or _|_ if not found
Privacy Attack
1
Create(ID0)
Create(ID1)
vtag=Draw(ID0)
SendTag(vtag, x)
Free(vtag)
…tag ID0 has been desynchronised
Privacy Attack
2
vtag = DrawTag(-$-);
(π, τ ) ← Execute(vtag);
x ← Result(π);
Output Idx = Table(vtag)
…A always distinguishes desynch tag/synch tag
… the scheme is not weak private because there is no blinder
B such that AB can do the same
Tags “out of the game”
In real life, Adv has several ways to push “out of the game” a tag
• DoS attacks (at protocol level, like the above one)
• Physical attacks (a strong electromagnetic field to destroy the circuit)
1. Do we need to model such actions?
2. Do we need to consider the distinction between a
“working tag” and an “inactive” tag as a privacy breach?
Yes
May be no
New Oracle: Makeinactive
MakeInactive
Theorem 1. In the model of [Vau07], if an adversary is allowed
to query the MakeInactive oracle, then no privacy is achievable.
Proof
1
Create(ID0)
Create(ID1)
vtag=Draw(ID0)
MakeInactive(vtag)
Free(vtag)
…tag ID0 is now inactive
2
vtag = DrawTag(-$-);
(π, τ ) ← Execute(vtag);
x=0 if no tag message
Output Idx = Table(vtag)
…A always distinguishes inactive tag/active tag
… this result matches real life: an Adv can always distinguish a
working tag from an inactive one
Privacy game: working tags only
We look at what can be done if we consider only tags which have not been
ruled out of the game as possible targets of the privacy game
Changes to the Model:
• Makeinactive
• Draw (gives only active tags when invoked)
Destructive Privacy
… challenging notion and close to the real world
Note: with the Makeinactive oracle call, we do not need to change the semantic of
the CorruptTag oracle call (i.e., reading the state + destroy).
Destructive Privacy notion: “CorrupTag must be followed by Makeinactive”
GOAL
Target: Destructive privacy
Tools: symmetric crypto, standard assumptions
Up to now … we have not succeeded in getting an answer (or a protocol) on
Destructive Private, but we have got something close …
An Hardware Perspective
CorruptTag
Privacy Notion
Hardware
Requirement
No Corrupt
Weak
Tamper Proof Area
Corrupt at the end
Forward
Tamper Proof Area
Corrupt (tag destr)
Destructive
Some protection
Corrupt
Strong
No protection
Semi-Destructive Privacy
We assume an hardware capability of the tags,
reader, to detect corruption and kill themselves.
by a
Possible in real-life? Costly? As expensive as PK crypto? We do not know …
Like Destructive but Corruption cannot happen during
the instants in which the tag is powered by a reader
Semi-Destructive Privacy is Possible
Semi-Destructive Privacy is Possible
Theorem 2.
The above three-round RFID protocol is correct, secure and semidestructive private under the assumption that the underlying encryption
scheme is IND-CPA-secure and INT-CTXT-secure.
Authenticated Encryption
M. Bellare and C. Namprempre
[Asiacrypt00]
IND-CPA∧INT-CTXT
IND-CCA
NM-CCA
IND-CPA ∧ INT-PTXT
IND-CPA
NM-CPA
IND-CPA ∧INT-CTXT : Achievable through the Encrypt-Then-Mac paradigm.
• IND-CPA symmetric encryption scheme
• STRONG MAC
Open Problems
 Is the hardware safety measure identified realisable in real life?
 Is semi-destructive privacy of interest in applications (especially if
destructive turns out to be impossible)?
 Are our conditions on the encryption scheme necessary?
 Practical instances for implementation (using the composition paradigm
for authenticated encryption or direct constructions)?