persistent security for rfid mike burmester & breno de medeiros rfidsec’07
TRANSCRIPT
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