1. Persistent Security for RFID Mike Burmester & Breno de Medeiros RFIDSec’07

2. 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

3. 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

4. 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!

5. RFIDSec’07 Why forward security?

6. 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

7. 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

8. 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

9. 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

10. RFIDSec’07 Security model

11. 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

12. 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)

13. 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

14. 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

15. 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

16. RFIDSec’07 Practical considerations

17. 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

18. 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

19. 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

20. RFIDSec’07 Results Forward-anonymous tag authentication Forward-secure mutual authentication and key-exchange Ongoing work on forward-secure group scanning

21. RFIDSec’07 Server/ reader Tag i r sys r tag || v 2 v3v3 O-FRAP (Optimistic Forward- secure RFID Auth. Protocol) Db r tag,k tag 1) v  F(k tag, r tag ||r sys ) (v 1,v 2,v 3, v 4 )  v 2) r tag  v 1 1),2) one of curr. k tag or v 4 for new k tag 3) k tag  v 4

22. 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!

23. 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