Semi-Destructive Private Rfid Systems Paolo D’Arco, Alessandra Scafuro and Ivan Visconti by University of Salerno Italy Workshop on RFID Security 2009 June 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 Tag Reader secure channel Rfid system Rfid Scheme SetupReader: generates key materials (K s, K p ) + resets database DB SetupTag: tag ID receives an initial state S and (ID, data) is inserted into DB Protocols Tag (S) Reader (K s, 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… vtag 1 vtag 2 vtag 3

Security and Privacy Definitions Set of oracles Oracle queries Rules GAME = Adversary’s Goal

Oracles and Oracle Queries DrawTag SendTag Free CreateTag Launch Send Reader Send Reader Result Corrupt (vtag 1, ID 1 ) (vtag 2, ID 2 ) … IDb π msg, π msg π b vtag S 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 Definition An Rfid scheme is secure if, for any polynomial bounded adversary, the probability of success is negligible 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 winning condition = True Querying Phase Analysis Phase CreateTag, FreeTag, CorruptTag Launch, SendReader, SendTag, result DrawTag Table (vtag 1, ID 1 ) (vtag 2, ID 2 ) … True/False ADVERSARY

DrawTag SendTag Free CreateTa g Launch Send Reader Send Reader Result Corrupt IDb π msg, π msg π b vtag S msg msg, vtag distr vtag, 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 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

Privacy Game Query Phase Analysi s Phase CreateT, FreeT, CorruptT Launch, SendR, SendT, Result DrawTag Table (vtag 1, ID 1 ) (vtag 2, ID 2 ) … BLINDED ADVERSARY True/False Query Phase Analysi s Phase CreateT, FreeT, CorruptT Launch, SendR, SendT, Result DrawTag Table (vtag 1, ID 1 ) (vtag 2, ID 2 ) … ADVERSARY 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[A B wins] 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[A B wins]

Privacy Notions Defined through restrictions imposed to Adv on the use of the oracle queries CorruptTag QueryWith Result QueryNo Result Query Not allowedWeakNarrow Weak Only at the endForwardNarrow Forward Allowed (but tag destroyed) DestructiveNarrow Destructive AllowedStrongNarrow Strong

State of Art Privacy NotionCryptographic Tool WeakPRF ForwardPKC Destructive? StrongImpossible Narrow DestructiveIn ROM model Narrow StrongPKC … 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] Tag Reader state: 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(ID 0 ) Create(ID 1 ) vtag=Draw(ID 0 ) SendTag(vtag, x) Free(vtag) …tag ID 0 has been desynchronised 1

Privacy Attack vtag = DrawTag(-$-); (π, τ ) ← Execute(vtag); x ← Result(π); Output Id x = Table(vtag) …A always distinguishes desynch tag/synch tag … the scheme is not weak private because there is no blinder B such that A B 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(ID 0 ) Create(ID 1 ) vtag=Draw(ID 0 ) MakeInactive(vtag) Free(vtag) vtag = DrawTag(-$-); (π, τ ) ← Execute(vtag); x=0 if no tag message Output Id x = Table(vtag) …A always distinguishes inactive tag/active tag 12 …tag ID 0 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)

GOAL Target: Destructive privacy Tools: 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 CorruptTagPrivacy NotionHardware Requirement No CorruptWeakTamper Proof Area Corrupt at the endForwardTamper Proof Area Corrupt (tag destr)DestructiveSome protection CorruptStrongNo protection

Semi-Destructive Privacy Like Destructive but Corruption cannot happen during the instants in which the tag is powered by a reader

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)?