Your SlideShare is downloading. ×
0
Persistent Security for RFID
Persistent Security for RFID
Persistent Security for RFID
Persistent Security for RFID
Persistent Security for RFID
Persistent Security for RFID
Persistent Security for RFID
Persistent Security for RFID
Persistent Security for RFID
Persistent Security for RFID
Persistent Security for RFID
Persistent Security for RFID
Persistent Security for RFID
Persistent Security for RFID
Persistent Security for RFID
Persistent Security for RFID
Persistent Security for RFID
Persistent Security for RFID
Persistent Security for RFID
Persistent Security for RFID
Persistent Security for RFID
Persistent Security for RFID
Persistent Security for RFID
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Persistent Security for RFID

207

Published on

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
207
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Prevention of exploitation of “kill” functionality Resilience against de-synchronization attacks Protocols that provide location privacy require synchronization of state between tag and server (pseudonym update). Active attackers seeks to tamper with communication to cause the state to diverge between parties Tension between privacy and availability Persistent security: availability + forward security
  • For instance, fixed ID tags could be used in inventory/ shipment systems. In this case, cloning of a tag may allow for repeated exploitation of the system. In some systems, such as credit card numbers and SSN’s, the knowledge of patterns used to generate the numbers (in addition to the density of valid numbers) has led to some types of exploits that allow attackers to generate new valid credentials corresponding to existing ids without seeing them. The assumption that RFIDs may be more reliable than, say, passwords in an access control system may lead to poor support for revocation. To clone credit cards, attackers require physical control of the card, institutional break-in, or a phishing-type attack. These attacks leave traces that can be used by credit card agencies to evaluate the (non-)culpability of card holders. On the other hand, RFIDs may be cloned through covert interactions that leave no trace. In particular, in combination with delayed exploitation, cloned cards provide greater risks to both institutions and users. The same is true of other applications, such as access control and identification
  • While the PRF requires many invocations of the PRG, if the PRG is very efficient, this just increases clock cycles (control is very simple) so not a problem
  • Caveat: Ad-hoc strategies are available using time slicing, hash chains, etc.
  • Transcript

    • 1. Persistent Security for RFID Mike Burmester & Breno de Medeiros RFIDSec’07
    • 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. 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. 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. Why forward security?
    • 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. 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. 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. 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. Security model
    • 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. 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. 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. 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. 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. Practical considerations
    • 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. 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. 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. 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. 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. 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. 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>

    ×