Persistent Security for RFID

Mike Burmester &

Breno de Medeiros

RFIDSec’07

RFIDSec’07

Talkthrough

Why persistent security?

What exactly is persistent security? An extensive list of requirements (still minimalist) A strong (composable) security model

Is it affordable? Persistent secure solution for each budget

Example: forward-secure tag authentication

RFIDSec’07

RFID: discardable technology? RFID tags

low cost replaceable relatively short-lived

Other RFID system components: Not necessarily low-cost upgradeable mid- to long-term life

Both: May protect high-value assets

RFIDSec’07

RFID Security Services

Authentication Cloning protection re-play protection Authenticity of

exchanged keys

Location privacy Unlinkable anonymous

transactions

Data confidentiality (Re-)encryption

Forward-privacy Forward-anonymity Forward-secrecy of

exchanged keys

Availability De-synchronization Unauthorized “killing”

Persistent security: A long wish list!

RFIDSec’07

Why forward security?

RFIDSec’07

Lasting effects of compromise

If tags compromised, is exposure temporally limited?

Examples of potential long-term effects Compromise of a ID/pseudonym that is recycled Compromise of the pattern used to generate

IDs/pseudonyms System built without consideration for revocation of

credentials Covert compromise combined with delayed exploitation

RFIDSec’07

Generic Concerns

In the presence of a large-scale adversary E.g., military or industrial espionage

Compromise of RFID secrets E.g. through discarded tags May reveal identities of parties involved in previously

recorded interactions May disclose session keys of previously exchanged

confidential communication

RFIDSec’07

Technology-specific concerns

RFID vulnerability to physical attacks makes it likely that keys will be compromised

Forward-security provides mechanism to prevent “delayed exploitation” particularly insidious in combination with covert

key extraction Periodic key changes will limit the ability of an

adversary to exploit a vulnerability

RFIDSec’07

Flexibility of Trust Design

RFID security protocols often assume readers untrusted (all security at back-end server)

In some cases it is useful to transfer some trust to the readers What happens if readers

compromised? May require large-scale replacement of secrets

Possibly unmanageable

Forward-security strategies build in mechanisms for key replacement

Protocols designed for forward-security (against reader compromise) more resilient under flexible trust assumptions

RFIDSec’07

Security model

RFIDSec’07

Multiple security requirements

Functionality provided by RFID still simple Authentication + simple

additional semantics

Less than “wireless smart card”

More than “smart label”

Security requirements multi-faceted Simultaneous provision of

multiple services

Example: tension between availability and privacy requirements

RFIDSec’07

History

First formal security model for RFID entity authentication (SecureComm’06)

Considers availability threats in addition to authentication and anonymity

Has been extended for forward-secure key-exchange (AsiaCCS’07)

RFIDSec’07

Unified Security Modeling

Guarantees that tensions between different requirements are resolved, or at least clarifies the existence of such tensions

Common ground allows for comparison of the virtues and weaknesses of different schemes

Modularity and composition

RFIDSec’07

Composability Tidbits

Composable security modeling is based on indistinguishability between real (protocol) and ideal (specification) simulations

Adversary allowed to interact with environment: “not a test tube adversary!” Black-box adversarial simulation No re-winding of the adversary

RFIDSec’07

Forward Security

Limitations in adversary simulation in composable models make it tricky to define forward-security

Forward-security requires that old keys be unpredictable from new keys Easiest way: ideal process generates new keys as truly random

What if adversary extracts keys during session? It can detect deterministic behavior for key update

Solution: Ideal process must enforce forward-security only among boundaries of fully-completed sessions

RFIDSec’07

Practical considerations

RFIDSec’07

Practical accommodation

Composability framework favors the adoption of as few setup assumptions as possible, to achieve the most general result

Strong restrictions in RFID capabilities impose instead a pragmatic approach Aggressive adoption of setup assumptions are needed in

order to use basic symmetric-key primitives

RFIDSec’07

Basic ingredient: PRGs +

= 1-way, “randomness preserving” function r, F(k || r || ...) Implied by the simultaneous requirements of

authentication and unlinkable anonymity Randomness-preserving function provided by:

PRG itself: Use GGM PRG-to-PRF construction. PRF certainly a randomness preserving function. Not so crazy for RFID: adds simple control over PRG code Little additional code footprint or per-cycle power usage

Stream cipher: similar

RFIDSec’07

Other candidates for Heuristic constructions based on block ciphers

Example: trick to make the block cipher one-way

Shamir’s on-the-fly squaring?

LFSR-based generators

Trade-offs between security and efficiency abound

RFIDSec’07

Results

Forward-anonymous tag authentication Forward-secure mutual authentication and

key-exchange Ongoing work on forward-secure group

scanning

RFIDSec’07

Server/reader

Tag i

rsys

rtag || v2

v3

O-FRAP (Optimistic Forward-secure RFID Auth. Protocol)

Db rtag ,ktag

1) v F(ktag, rtag||rsys)

(v1,v2,v3, v4) v

2) rtag v11),2)one ofcurr. ktag

or v4

for newktag

3) ktag v4

RFIDSec’07

Availability Availability requires mechanisms to “recover” synchronicity when adversary

interferes with session and causes divergence between computed outputs Linear search: Onerous for back-end server (effort of back-end server

does not scale with attack)

Use of hierarchical keys can be problematic when key compromises are considered

Reconciling availability and privacy in a scalable way still a challenge!

RFIDSec’07

Persistent Security: Recap

Security model simultaneously captures multiple requirements Shows any tension between requirements Facilitates meaningful comparison between competing

alternatives Key updates (forward-security) desirable Security modeling makes clear the requirement

on primitives Allow maximum flexibility by providing informed choice