Semi-Destructive Private Rfid Systems
description
Transcript of Semi-Destructive Private Rfid Systems
Semi-Destructive Private Rfid Systems
Paolo D’Arco, Alessandra Scafuro and Ivan Visconti
by
University of SalernoItaly
Workshop on RFID Security 2009June 30 - July 2, 2009, Leuven
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
Backend Server / DB
TagReader
securechannel
Rfid system
Rfid Scheme
• 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
Out-of-range tags Reader
Adv
Eavesdrop, intercept,modify, corrupt tags…
vtag1 vtag2
vtag3
Security and Privacy Definitions
Set of o
racles Oracle queries
Rules
GAME = Adversary’s Goal
Oracles and Oracle Queries
DrawTag
SendTag
Free
CreateTag Launch
SendReader
ResultCorrupt
(vtag1, ID1)(vtag2, ID2)
…
ID bπ
msg, π
msg
πb
vtag Svtag
msg
msg, vtag
distr
vtag, b
… Adv reproduces real executions of the protocol
Security Game
Winning condition for Adv: the reader identified ID but this (uncorrupted) tag did not have any matching conversation with the reader
DefinitionAn 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 winning condition = True
Querying Phase
Analysis Phase
CreateTag, FreeTag, CorruptTag
Launch, SendReader, SendTag, result
DrawTag
Table
(vtag1, ID1)(vtag2, ID2)
…
True/False
ADVE
RSAR
Y
DrawTag
SendTag
Free
CreateTag Launch
SendReader
ResultCorrupt
ID bπ
msg, π
msg
πb
vtag Svtag
msg
msg, vtag
distrvtag, b
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
Blinder
Blinder
Privacy Game
Query Phase
Analysis
Phase
CreateT, FreeT, CorruptTLaunch, SendR, SendT, Result
DrawTag
Table
(vtag1, ID1)(vtag2, ID2)
…
BLIN
DED
ADVE
RSAR
YTrue/False
Query Phase
Analysis
Phase
CreateT, FreeT, CorruptTLaunch, SendR, SendT, Result
DrawTag
Table
(vtag1, ID1)(vtag2, ID2)
…
ADVE
RSAR
Y
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 assumptionson 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 protocolSimplified version [Vau07]
Tag Readerstate: K {… (ID,K)…}
Pick a in {0,1}αa
F, G random oracles Tag and Reader have access to
c=F(K,a)replace K by G(K) c
find (ID,K) s.t. c=F(K,a)replace K by G(K)output: ID or _|_ if not found
Privacy Attack
Create(ID0) Create(ID1)
vtag=Draw(ID0)SendTag(vtag, x)Free(vtag)
…tag ID0 has been desynchronised
1
Privacy Attack
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 blinderB such that AB can do the same
2
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? May be no
Yes
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.
Create(ID0) Create(ID1)
vtag=Draw(ID0)MakeInactive(vtag)Free(vtag)
vtag = DrawTag(-$-); (π, τ ) ← Execute(vtag); x=0 if no tag messageOutput Idx = Table(vtag)
…A always distinguishes inactive tag/active tag
1 2
…tag ID0 is now inactive
… this result matches real life: an Adv can always distinguish a working tag from an inactive one
Proof
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)
GOALTarget: Destructive privacyTools: symmetric crypto, standard assumptions
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”
Up to now … we have not succeeded in getting an answer (or a protocol) on Destructive Private, but we have got something close …
Destructive Privacy… challenging notion and close to the real world
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
Like Destructive but Corruption cannot happen during the instants in which the tag is powered by a reader
We assume an hardware capability of the tags, when powered by a reader, to detect corruption and kill themselves.
Possible in real-life? Costly? As expensive as PK crypto? We do not know …
Semi-Destructive Privacy is Possible
Semi-Destructive Privacy is Possible
Theorem 2.
The above three-round RFID protocol is correct, secure and semi-destructive 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)?