Security and Privacy for RFID Systems

Security and Privacy for RFID Systems PowerPoint PPT Presentation


  • 187 Views
  • Uploaded on
  • Presentation posted in: General

Objectives. Describe security and privacy attributes for RFID systemsExtensions of standard network security and privacy attributes, but more challenging and complexMotivate research and development into ?safe" RFID deployments, where security and privacy are built inPart of the benefit, also part of the costVariety of RFID systems are contemplated:Low-cost EPC tagsProximity cardsPayment cards?Attributes apply to differing extent to each type of system.

Download Presentation

Security and Privacy for RFID Systems

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


1. Security and Privacy for RFID Systems Burt Kaliski, RSA Security RSA Conference Japan 2004

2. Objectives Describe security and privacy attributes for RFID systems Extensions of standard network security and privacy attributes, but more challenging and complex Motivate research and development into “safe” RFID deployments, where security and privacy are built in Part of the benefit, also part of the cost Variety of RFID systems are contemplated: Low-cost EPC tags Proximity cards Payment cards … Attributes apply to differing extent to each type of system

3. General Model Readers interact with tags Readers report tag events to applications Applications record tag events in tag databases Users, applications implement business processes using tag databases

4. General Model

5. Security and Privacy Attributes Tag privacy Tag authenticity Reader security Tag database security Attributes are ideals, not necessarily requirements Applications need to make a cost/benefit tradeoff

6. #1 : Tag Privacy Ideal: Only authorized applications should be able to identify tags Identify = associate with other information e.g., determine actual identity; link to previous tag events Readers may be able to scan tags, but results should not be meaningful to application unless authorized Authorized = having permission according to some privacy policy “Store X can identify its own unpurchased tags, but not purchased ones” “Company Y can identify tags only for products it has ordered” Extension: Tag Access Management — Applications should not be able to access tag data or control tags without authorization e.g., “kill” command

7. Tag Privacy : Threats and Challenges Threats: Rogue scanning e.g., by stores, competitors, thieves Passive eavesdropping on reader-to-tag transmissions Eavesdropping on tag possible at a short distance, but some tag “singulation” protocols are vulnerable to long-distance eavesdropping on the reader Challenges: Tag cost, power may limit crypto capabilities Readers may be offline, so may need to be provisioned with authentication data for many tags

8. Eavesdropping at a Distance In the main EPC protocol for scanning RFID tags, the reader considers the tags as belonging to a binary tree The reader addresses or singulates individual tags by a tree-walking protocol using depth-first search: Each subtree T corresponds to an identifier prefix Reader searches T by sending prefix, asking tags for their next bit If all “0”, searches Left(T) If all “1”, searches Right(T) If both “0” and “1”, searches Left(T) and Right(T) Prefixes send by reader reveal tag identifiers — and can be heard at a long distance

9. Tag Privacy Approaches (1) Deactivation Tag “killed” at point of sale Protects against rogue scanning, but doesn’t defend against passive eavesdropping on authorized scanners And tags are too useful to kill universally, and not easy to reactivate securely Public-key protocol Tag interacts with reader by public-key protocol that authenticates reader, then encrypts tag identifier with reader’s public key Protects against both threats But too heavyweight for today’s low-end tags

10. The Reactivation Dilemma San Francisco Public Library announced in October 2003 a plan to identify library books with RFID tags Tag deactivation proposed to address privacy concerns If you deactivate the tag when a book is checked out, how do you reactivate it when checked in? Reactivation command must be authenticated … Public-key methods too heavyweight … So command needs a shared secret The dilemma: Which secret? If a tag-specific secret, how does reader know which one? And if not tag-specific, then it’s not a secret …

11. Tag Privacy Approaches (2) User intervention User presses button on tag to authorize scanning Protects against rogue scanning if user can identify unauthorized readers, but not passive eavesdropping Not suitable within supply chain Blocker tags (Juels, Rivest, Szydlo) User carries special blocker tag that interferes with singulation protocol within private subtrees Always answers “0” and “1” within subtree Protects against both threats for “private” tags when applied Again not suitable within supply chain

12. Tag Privacy Approaches (3) Silent tree-walking (Weis et al.) Singulation protocol modified so that search process doesn’t reveal actual identifier e.g., tag singulates with a random identifier, then quietly sends actual identifier Protects against passive eavesdropping from a distance, but not rogue scanning One-time identifiers (aka “pseudonym tag”) (Juels) Tag steps through multiple identifiers, linkable to tag’s actual identity only by authorized applications Protects against both threats if enough identifiers Or if scanning rate somehow limited by tag … But how to manage a large supply of identifiers?

13. #2 : Tag Authenticity Ideal: Only authorized applications should be able to produce valid tags Valid = having an identity recognized by authorized application Authorized = e.g.: “Only manufacturer Z can produce tags recognizable as being from Z”

14. Tag Authenticity : Threats, Challenges Threats: Cloning — copying existing tags Forgery — making new tags with a valid identity Relabeling (transferring a tag from one physical item to another) requires physical countermeasures, not addressed here “Grandmaster” attack (spoofing tag and reader simultaneously by relaying messages between them) also requires physical countermeasures Challenges: Tag cost, power may limit crypto capabilities Cost and form factor likewise may limit tamper-resistance

15. Tag Authenticity Approaches (1) Track and trace Application anticipates tag movements, detects and reports “fraud” anomalies and duplicates No secrets on tag Protects against both threats — but only after the fact Challenge-response Tag interacts with reader by challenge-response protocol based on tag-specific secret key Protects against both threats But a little (or a lot) heavyweight Feasible for payment cards

16. Tag Authenticity Approaches (2) Static authentication (e.g., as in EMV spec.) Tag identifier includes a digital signature or MAC, or is itself an application secret No crypto needed on tag Protects against forgery, but not cloning Static authentication with public-key protocol (e.g., SAML) Tag authenticates reader by public-key protocol, then encrypts “static authenticator” above with reader’s public key Only public-key operations needed on tag; no tag secret key Protects against both threats, assuming readers trustworthy Still too heavyweight for low-end tags Again feasible for payment cards

17. Tag Authenticity Approaches (3) Pseudonym tag with mutual authentication (Juels) Three-part protocol: Tag presents one-time identifier Reader sends corresponding one-time PIN Tag returns its own one-time PIN for authenticity Protects against both threats if enough identifiers But again, how to manage a large supply of identifiers?

18. #3 : Reader Security Ideal: a) Only authorized applications should be able to interact with readers (e.g., to obtain information about tag events) b) Only authorized readers should be able to provide information about tag events to an application Authorized = having permission under some policy “Company A can obtain information from its own readers, but not Company B’s readers” “Store C’s readers can provide tag events to Store C, but not Store D’s readers”

19. Reader Security : Threats, Challenges Threats: Eavesdropping on reader-to-application transmissions Insertion, deletion, modification of tag events e.g., bogus readers Reader compromise (e.g., by intrusion) requires IT security countermeasures, not addressed here Challenges: Readers need to be swapped in and out in the field, which complicates key management Reader cost, power may limit crypto capabilities though not nearly to the extent that tags are limited …

20. Reader Security Approaches Basically, standard security protocols Application, reader authenticate each other, establish a session key Public-key or symmetric-key based protocol But how to determine which keys (i.e., readers and applications) are authorized? Tag event data encrypted and integrity-protected with session key Examples: IPsec; TLS; WiFi Though some computational cost, crypto capabilities will continue to improve, following general trend in wireless and wired security Further research may yield more interesting approaches …

21. #4 : Tag Database Security Ideal: Only authorized applications and users should be able to access online tag information databases Authorized = having permission according to some policy among parties “Administrator E can read tag information from Company F’s database” “Applications at Supplier G can query only about Supplier G’s tags from Retailer H’s database”

22. Tag Database Security : Threats and Challenges Threats: Disclosure of information about tags Modification Traffic analysis, etc. Challenges: Tag databases potentially need to be available to many parties Suppliers, retailers, consumers, auditors, … Information about a given tag may be managed in many places, and/or may change hands over time Even referrals on lookups can reveal competitive information!

23. Tag Database Security Approaches Basically, good distributed database / Web services security Application, users authenticate, obtain authorization Database / Web service decides whether to accept request based on authorization But questions remain: Which database(s) to query about a given tag? Is the application or user authorized to find out even this much? How to manage authorizations across supply chain? More for another presentation …

24. Conclusions Security and privacy challenges are significant in the emerging RFID infrastructure, yet approaches are available or being developed to address them Solutions can combine approaches to achieve security and privacy attributes at various levels (and costs) according to policy, business requirements The reward from an RFID deployment tomorrow depends on the investment in security and privacy in the design today

25. For More Information S. Sarma et al., “Radio-Frequency Identification: Security Risks and Challenges,” CryptoBytes 6(1), Spring 2003, http://www.rsasecurity.com/rsalabs/cryptobytes/ S. Weis home page, http://theory.lcs.mit.edu/~sweis/ RFID privacy and security page, RSA Laboratories, http://www.rsasecurity.com/rsalabs/rfid/

26. Contact Information Burt Kaliski Chief Scientist, RSA Security Director, RSA Laboratories [email protected] http://www.rsasecurity.com/rsalabs/

  • Login