RFID Security: In the Shoulder and on the Loading Dock Ari Juels RSA Laboratories Joint work with D....

Post on 13-Jan-2016

213 views 1 download

Tags:

transcript

RFID Security: In the Shoulder

and on the Loading Dock

Ari JuelsRSA Laboratories

Joint work with D. Boneh, E.-J. Goh, J. Halamka,

A. Stubblefield, B. Parno, R. Pappu, and J. Westhues

RFID on the Loading Dock

Recapping Ravi Pappu’s presentation…

Keeping the customer satisfied…

• “I want a rock-solid encryption algorithm…

with 20-bit keys.”

• “I want my database encrypted… but all my employees and customers need to have access.”

• “I want my retail stores to be able to read RFID-tagged items…

but I want tags to be unreadable after sale… and I don’t want to have to kill or rewrite them…

EPC tags and privacy

• EPC tags have no true cryptographic functionality

• One true, explicit EPC privacy feature: Kill– On receiving tag-specific PIN, tag self-destructs

• But commercial RFID users say:– They do not want to manage kill PINs– They have no channel to communicate secret

keys downstream in supply chain

“Privacy without killing” approach: Put the secret keys on the tags

• Encrypt tag data under secret key • Apply secret sharing to spread key across tags in crate

– E.g., (s1, s2,, s3)

E (m1) s1

E (m2) s2

E (m3) s3

• Encrypt tag data under secret key • Apply secret sharing to spread key across tags in crate

– E.g., (s1, s2,, s3)

E (m1) s1

E (m2) s2

E (m3) s3

“Privacy without killing” approach: Put the secret keys on the tags

Supersteroids 500mg; 100 countSerial #87263YHGMfg: ABC Inc.Exp: 6 Mar 2010

Privacy through dispersion

Privacy through dispersion E (m1) 1

E (m2) 2

E (m3) 3

Individual shares / small sets reveal no information about medication!

(Super-Steroids)

(Super-Steroids)

(Super-Steroids)

Challenges that Ravi discussed1. Storage is at a premium in EPC, but no secret-sharing

literature on “tiny” shares• “Short” shares are 128 bits, but we may want 16 bits or less!

2. Scanning errors• We need robustness in our secret-sharing scheme

Another place for RFID secret-sharing: Authentication

• A key is useful not just for consumer privacy– Read / write “unlock” codes for EPC tags– Anti-cloning for EPC tags [Juels ’05]– Symmetric key for challenge-response tag

authentication (again, anti-cloning)

• But putting on crate is bad if crate is diverted– Attacker can read / rewrite tags and re-inject goods– Attacker can clone tags

Secret-sharing across crates

s1 s2 s3

s’1 s’2 s’3

Dimension 1:

Dimension 2:

Secret-sharing across crates

s1 s2 s3

s1 s2 s3

Dimension 1:

Dimension 2:

s1(Or crate-specific tag)

But “windows” are not always neat…

s1 s2 s3 s1 s2 s3

Warehouse A Warehouse B

receivers cannot reconstruct and ’ !

SWISS(Sliding Window Information Secret-Sharing)

Given 2 out of 4 si, get corresponding i

s1 s2 s3 s4 s5 s6

Given 2 out of 4 si, get corresponding i

Given 2 out of 4 si, get corresponding i

1 2 3 4 5 6

SWISS(Sliding Window Information Secret-Sharing)

1 3Warehouse B 5

s1 s2 s3 s4 s5 s6

1 2 3 4 5 6

SWISS(Sliding Window Information Secret-Sharing)

????

Adversary with more sporadic crate access

s1 s2 s3 s4 s5 s6

1 2 3 4 5 6

SWISS(Sliding Window Information Secret-Sharing)

• A k-out-of-n-SWISS scheme is straightforward with share size si linear in n

• It’s not obvious how to get more compact si • That’s what our paper addresses…

– More pairings tricks– Basic RSA variant– Size of si is constant(!) in n

s1 s2 s3 s4 s5 s6

RFID in the Shoulder

We’ve talked about many different RFID devices at this workshop…

and many different threats

Proximity cards

Credit cards• RFID now offered in all major credit cards in

U.S.…• (See “Vulnerabilities in First-Generation

RFID-Enabled Credit Cards” [Heydt-Benjamin et al. ’07])

Transit cards

Passports

• Dozens of countries issuing RFID-enabled passports

• Other identity documents following, e.g., drivers’ licenses, WHTI

Animals too…“Not Really Mad”

• Livestock

• Housepets

The cat came back, the very next day…

50 million+

Human location tracking

• Schools• Amusement parks• Hospitals• In the same vein: mobile phones with GPS…

???

Human-implantable RFID

+ = VeriChipTM

Human-implantable RFID

+ = VeriChipTM

• Excellent test bed for privacy and security concepts!

• Proposed for medical-patient identification• Also proposed and used as an authenticator for physical

access control, a “prosthetic biometric”– E.g., Mexican attorney general purportedly used for access to

secure facility• What kind of cryptography does it have?

– None: It can be easily cloned [Halamka et al. ’06]• So shouldn’t we add a challenge-response protocol?• Cloning may actually be a good thing

Human-implantable RFID

• Physical coercion and attack– In 2005, a man in Malaysia had his fingertip

cut off by thieves stealing his biometric-enabled Mercedes

– What would happen if the VeriChip were used to access ATM machines and secure facilities?

• Perhaps better if tags can be cloned! • Tags should not be used for authentication

—only for identification

Cloneability + privacy

• Privacy means no linkability or information about identities• If a tag can be cloned, does that mean it can’t provide

privacy?– Surprisingly, no!

• A very simple scheme allows for simultaneous cloneability and privacy

Cloneability + privacy

Homomorphic public-key cryptosystem (e.g., El Gamal)

• Private / public key pair (SK, PK)• Randomized scheme: C = EPK,r [m]• Semantic security:

Adversary cannot distinguish C = EPK,r [“Alice”] from C’*= EPK,s [“Bob”]

• Re-encryption property: Given C only, can produce randomized C* = EPK,s [m], without knowing m

Cloneability + privacy

The scheme: When read, tag chooses fresh r and outputs C = EPK,r [“name”]

Then:• Reader with SK can decrypt name• Semantic Security: Adversary cannot

distinguish among tags, i.e., infringe privacy

• Re-encryption property: Adversary can clone a tag: records C and outputs randomized C*

The covert-channel problemSuppose there is an identification / authentication system…

AuthorizedEmployees

Only

Who’s there?

E[“Alice”]

It’s Alice!

The covert-channel problemSuppose there is an identification / authentication system…

AuthorizedEmployees

Only

Who’s there?

E[“Alice” + ?]

Alice has low bloodpressure andhigh blood-alcohol

Alice recently passed a casino’sRFID reader.

Mercury switchindicates thatAlice napped on job

How can we assure Alice of no covert channels?

• Outputs must be deterministic– Randomness always leaves room for covert emissions

• Could give Alice a secret key to check that outputs are formatted correctly– E.g., PRNG seed for device

• But we don’t want Alice (or a third party) to have to manage sensitive keying material!

• Can we enable Alice to verify covert-freeness publicly, i.e., without exposing secret keys?

• Simultaneous publicly verifiable covert-freeness and privacy are impossible!

Here’s why…Suppose there were a public CC detector…

X18 Ultra CC-DetectorTM

A1

A2

No CC

Yes, CC!

Here’s a covert channel!

1. Create identity for user “Bob”• Bob could be fictitious

• Just need output sequence B1, B2, …

2. Alice’s chip does following:• If no nap, output A1, A2, A3, etc. with

Alice’s identity• If Alice has taken a nap, then flip to Bob’s

identity, i.e., output A1, A2… B1, B2

Suppose we detect this covert channel

X18 Ultra CC-DetectorTM

A1

A2

No CCB

1

Yes, CC

Now if there really is a user Bob, we have a problem...

X18 Ultra CC-DetectorTM

A1

A2

No CC

Alice followed by Bob yields “Yes”

X18 Ultra CC-DetectorTM

A1

B1

Yes, CC

BobAlice

Alice Alice

Privacy is broken: We can distinguish between identities!

X18 Ultra CC-DetectorTM

Yes X18 Ultra CC-DetectorTM

No

So public CC-verifiability + privacy is impossible

• But we can achieve it anyway [Boneh et al. ’07]…• Idea:

– Change privacy definition to eliminate localized privacy, e.g., privacy across pairwise values

– Allow localized CC-checking, e.g., pairwise– Localized privacy is least important type of privacy

• Now we can do spot CC-checking…

A1 A2 A3 A4 A5 A6 A7 A8 A9

X18 Ultra CC-DetectorTM

yes / no

The message of this talk: Crypto is not the hard part!

We can do:• Challenge-response for

authentication• Mutual authentication

and/or encryption for privacy

AES

Side-channel countermeasures

But:

1. Moore’s Law vs. pricing pressure

2. The theme of today’s talk: The really hard part is key management…

The key-management problem

Okinawa, JapanKansas, USA

“Top secret:X-32 cone”

crypto key

“Top secret:X-32 cone”

The key poses its own “transport” problems:• It must be tag-specific (usually)• It must be highly available • It must be secured at all times • Like managing 10,000,000,000 passwords!

The RFID key-management problem

Keys / PINs for consumer privacy

Body passwords?

To learn more

• Papers available at RFID CUSP: www.rfid-cusp.org • J. Halamka, A. Juels, A. Stubblefield, and J. Westhues.

“The Security Implications of VeriChip Cloning.” Journal of the American Medical Informatics Association (JAMIA), 2006.

• D. Bailey, D. Boneh, E.-J. Goh, and A. Juels. “Covert Channels in Privacy-Preserving Identification Systems.” In ACM CCS, 2007.

• A. Juels, R. Pappu, and B. Parno. “Key Transport in Unidirectional Channels with Applications to RFID Security.” In submission.

• J. Westhues’s RFID cloning page: http://cq.cx.