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