Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Persistent Security for RFID

407 views

Published on

Published in: Business, Technology
  • Be the first to comment

Persistent Security for RFID

  1. 1. Persistent Security for RFID Mike Burmester & Breno de Medeiros RFIDSec’07
  2. 2. Talkthrough <ul><li>Why persistent security? </li></ul><ul><li>What exactly is persistent security? </li></ul><ul><ul><li>An extensive list of requirements (still minimalist) </li></ul></ul><ul><ul><li>A strong (composable) security model </li></ul></ul><ul><li>Is it affordable? </li></ul><ul><ul><li>Persistent secure solution for each budget </li></ul></ul><ul><li>Example: forward-secure tag authentication </li></ul>
  3. 3. RFID: discardable technology? <ul><li>RFID tags </li></ul><ul><ul><li>low cost </li></ul></ul><ul><ul><li>replaceable </li></ul></ul><ul><ul><li>relatively short-lived </li></ul></ul><ul><li>Other RFID system components: </li></ul><ul><ul><li>Not necessarily low-cost </li></ul></ul><ul><ul><li>upgradeable </li></ul></ul><ul><ul><li>mid- to long-term life </li></ul></ul><ul><li>Both: May protect high-value assets </li></ul>
  4. 4. RFID Security Services <ul><li>Authentication </li></ul><ul><ul><li>Cloning protection </li></ul></ul><ul><ul><li>re-play protection </li></ul></ul><ul><ul><li>Authenticity of exchanged keys </li></ul></ul><ul><li>Location privacy </li></ul><ul><ul><li>Unlinkable anonymous transactions </li></ul></ul><ul><li>Data confidentiality </li></ul><ul><ul><li>(Re-)encryption </li></ul></ul><ul><li>Forward-privacy </li></ul><ul><ul><li>Forward-anonymity </li></ul></ul><ul><ul><li>Forward-secrecy of exchanged keys </li></ul></ul><ul><li>Availability </li></ul><ul><ul><li>De-synchronization </li></ul></ul><ul><ul><li>Unauthorized “killing” </li></ul></ul><ul><li>Persistent security: A long wish list! </li></ul>
  5. 5. Why forward security?
  6. 6. Lasting effects of compromise <ul><li>If tags compromised, is exposure temporally limited? </li></ul><ul><li>Examples of potential long-term effects </li></ul><ul><ul><li>Compromise of a ID/pseudonym that is recycled </li></ul></ul><ul><ul><li>Compromise of the pattern used to generate IDs/pseudonyms </li></ul></ul><ul><ul><li>System built without consideration for revocation of credentials </li></ul></ul><ul><ul><li>Covert compromise combined with delayed exploitation </li></ul></ul>
  7. 7. Generic Concerns <ul><li>In the presence of a large-scale adversary </li></ul><ul><ul><li>E.g., military or industrial espionage </li></ul></ul><ul><li>Compromise of RFID secrets </li></ul><ul><ul><li>E.g. through discarded tags </li></ul></ul><ul><ul><li>May reveal identities of parties involved in previously recorded interactions </li></ul></ul><ul><ul><li>May disclose session keys of previously exchanged confidential communication </li></ul></ul>
  8. 8. Technology-specific concerns <ul><li>RFID vulnerability to physical attacks </li></ul><ul><ul><li>makes it likely that keys will be compromised </li></ul></ul><ul><li>Forward-security provides mechanism to prevent “delayed exploitation” </li></ul><ul><ul><li>particularly insidious in combination with covert key extraction </li></ul></ul><ul><ul><li>Periodic key changes will limit the ability of an adversary to exploit a vulnerability </li></ul></ul>
  9. 9. Flexibility of Trust Design <ul><li>RFID security protocols often assume readers untrusted (all security at back-end server) </li></ul><ul><li>In some cases it is useful to transfer some trust to the readers </li></ul><ul><ul><li>What happens if readers compromised? May require large-scale replacement of secrets </li></ul></ul><ul><ul><li>Possibly unmanageable </li></ul></ul><ul><li>Forward-security strategies build in mechanisms for key replacement </li></ul><ul><li>Protocols designed for forward-security (against reader compromise) more resilient under flexible trust assumptions </li></ul>
  10. 10. Security model
  11. 11. Multiple security requirements <ul><li>Functionality provided by RFID still simple </li></ul><ul><ul><li>Authentication + simple additional semantics </li></ul></ul><ul><ul><li>Less than “wireless smart card” </li></ul></ul><ul><ul><li>More than “smart label” </li></ul></ul><ul><li>Security requirements multi-faceted </li></ul><ul><ul><li>Simultaneous provision of multiple services </li></ul></ul><ul><ul><li>Example: tension between availability and privacy requirements </li></ul></ul>
  12. 12. History <ul><li>First formal security model for RFID entity authentication (SecureComm’06) </li></ul><ul><li>Considers availability threats in addition to authentication and anonymity </li></ul><ul><li>Has been extended for forward-secure key-exchange (AsiaCCS’07) </li></ul>
  13. 13. Unified Security Modeling <ul><li>Guarantees that tensions between different requirements are resolved, or </li></ul><ul><ul><li>at least clarifies the existence of such tensions </li></ul></ul><ul><li>Common ground allows for comparison of the virtues and weaknesses of different schemes </li></ul><ul><li>Modularity and composition </li></ul>
  14. 14. Composability Tidbits <ul><li>Composable security modeling is based on indistinguishability between real (protocol) and ideal (specification) simulations </li></ul><ul><li>Adversary allowed to interact with environment: “not a test tube adversary!” </li></ul><ul><ul><li>Black-box adversarial simulation </li></ul></ul><ul><ul><li>No re-winding of the adversary </li></ul></ul>
  15. 15. Forward Security <ul><li>Limitations in adversary simulation in composable models make it tricky to define forward-security </li></ul><ul><li>Forward-security requires that old keys be unpredictable from new keys </li></ul><ul><ul><li>Easiest way: ideal process generates new keys as truly random </li></ul></ul><ul><ul><li>What if adversary extracts keys during session? It can detect deterministic behavior for key update </li></ul></ul><ul><ul><li>Solution: Ideal process must enforce forward-security only among boundaries of fully-completed sessions </li></ul></ul>
  16. 16. Practical considerations
  17. 17. Practical accommodation <ul><li>Composability framework favors the adoption of as few setup assumptions as possible, to achieve the most general result </li></ul><ul><li>Strong restrictions in RFID capabilities impose instead a pragmatic approach </li></ul><ul><ul><li>Aggressive adoption of setup assumptions are needed in order to use basic symmetric-key primitives </li></ul></ul>
  18. 18. Basic ingredient: PRGs +  <ul><li> = 1-way, “randomness preserving” function </li></ul><ul><ul><li>r, F(k || r || ...) </li></ul></ul><ul><ul><li>Implied by the simultaneous requirements of authentication and unlinkable anonymity </li></ul></ul><ul><li>Randomness-preserving function provided by: </li></ul><ul><ul><li>PRG itself: Use GGM PRG-to-PRF construction. PRF certainly a randomness preserving function. </li></ul></ul><ul><ul><ul><li>Not so crazy for RFID: adds simple control over PRG code </li></ul></ul></ul><ul><ul><ul><li>Little additional code footprint or per-cycle power usage </li></ul></ul></ul><ul><ul><li>Stream cipher: similar </li></ul></ul>
  19. 19. Other candidates for  <ul><li>Heuristic constructions based on block ciphers </li></ul><ul><ul><li>Example: trick to make the block cipher one-way </li></ul></ul><ul><li>Shamir’s on-the-fly squaring? </li></ul><ul><li>LFSR-based generators </li></ul><ul><li>Trade-offs between security and efficiency abound </li></ul>
  20. 20. Results <ul><li>Forward-anonymous tag authentication </li></ul><ul><li>Forward-secure mutual authentication and key-exchange </li></ul><ul><li>Ongoing work on forward-secure group scanning </li></ul>
  21. 21. O-FRAP (Optimistic Forward-secure RFID Auth. Protocol) Server/ reader Tag i r sys r tag || v 2 v 3 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. 22. Availability <ul><li>Availability requires mechanisms to “recover” synchronicity when adversary interferes with session and causes divergence between computed outputs </li></ul><ul><ul><li>Linear search: Onerous for back-end server (effort of back-end server does not scale with attack) </li></ul></ul><ul><ul><li>Use of hierarchical keys can be problematic when key compromises are considered </li></ul></ul><ul><ul><li>Reconciling availability and privacy in a scalable way still a challenge! </li></ul></ul>
  23. 23. Persistent Security: Recap <ul><li>Security model simultaneously captures multiple requirements </li></ul><ul><ul><li>Shows any tension between requirements </li></ul></ul><ul><ul><li>Facilitates meaningful comparison between competing alternatives </li></ul></ul><ul><li>Key updates (forward-security) desirable </li></ul><ul><li>Security modeling makes clear the requirement on primitives </li></ul><ul><ul><li>Allow maximum flexibility by providing informed choice </li></ul></ul>

×