1 / 34

Security Considerations for CAN [2]

Security Considerations for CAN [2]. Peng Wang 1/31/2003. Outline. P2P Networks for file sharing & Napster CAN Security considerations Discussion References. P2P Networks for file sharing. P2P networks for file sharing involve two phases:

marva
Download Presentation

Security Considerations for CAN [2]

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Security Considerations for CAN[2] Peng Wang 1/31/2003

  2. Outline • P2P Networks for file sharing & Napster • CAN • Security considerations • Discussion • References

  3. P2P Networks for file sharing • P2P networks for file sharing involve two phases: 1. find out the peer storing the requested file. 2. Download the requested file from the exporting peer.

  4. Napster [1] • A central server stores a “index table”. • (file name, IP address) pairs • The index table contains location info of all the files available within the Napster user community • To retrieve a file, a initiator queries this central server using the name of the desired file, and obtains the IP address of the supplier storing that file. • The file is downloaded directly from this supplier.

  5. Napster con’t • Napster uses a p2p communication model for the actual file transfer. • The process of locating a file is still centralized. • To decentralize this process, one way is to break down the index table into small pieces. Each peer stores a piece of the table How to find the peer which stores the piece containing the location info of the desired file? -- CAN: Content-Addressable Network

  6. CAN • The lookup protocol (CAN) maps a desired key (hash value of file name) to the IP address of the node responsible for that key. • A storage protocol layered on top of the lookup protocol then takes care of storing, replicating, caching, retrieving, and authenticating the files.

  7. CAN -- basic model • Each file is associated with a hash value (e.g. input file name to MD5) • To retrieve a file, a initiator computes the hash value and queries CAN using this value and obtains the IP address of the supplier • File -- (hash value, IP address) pair • A hash value is deterministically mapped onto a point P in a d-dimensional Cartesian coordinate space

  8. (0,111) (111,111) P (111,0) (0,0) 6 bits hash value, 2-d space File A’s hash value is 110101. -- (110, 101) A is mapped to point P

  9. This space is partitioned among all the peers. Each peer “owns” one individual, distinct zone. A zone can be identified by its vertices. (hash value, IP address) pair of a file is stored at the peer that owns the zone containing the corresponding point. e.g. (hash value, IP address) pair of File A is stored at Peer 5. 1 2 3 4 5 P 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

  10. Routing Peer 16 wants to download file A. 16 computes file A’s hash value: 110101 -- (110, 101) A is mapped to point P How to reach the peer owning the zone containing P ? P 16 Each peer maintains a routing table that holds the IP address and zone of each of its neighbors in the space.

  11. 12, 15, 17 are neighbors of 16. Peer 16 maintains zones and IPs of 12,15 and 17. Messages are forwarded following the straight lines from source to destination. Query message (hash value, IP of 16) is send to 12. 12 forwards this message to 8… Peer 5 finds the (hash value, IP address) pair, and sends it back to peer 16 5 P 8 12 15 16 17

  12. Join • a new node that joins the system must be allocated its own zone of the coordinate space. • an existing node splitting its zone in half, retaining half and handing the other half to the new node. • Bootstrap • Finding a zone • Joining the routing

  13. Bootstrap • A new CAN peer N first finds the IP address of any peer currently in the system. • Ask system administrators about the IP address of entrance node E. • DNS domain name resolves to the IP address of one or more CAN bootstrap nodes. A bootstrap node maintains a partial list of CAN nodes it believes are currently in the system.

  14. Finding a zone 1 2 3 4 5 • The new peer must find a peer whose zone will be split. • N Randomly chooses a joining point J • N sends a JOIN request message destined for point J via the node E. • E routes the JOIN message. JOIN reaches the node O in whose zone J lies. 6 7 8 9 10 J 11 12 13 14 15 16 17 18 19 20 21

  15. Finding a zone con’t • O splits its zone in half and assigns one half to N • The (hash value, IP) pairs from the half zone to be handed over are also transferred to the new node. 1 2 3 4 5 6 7 8 9 21 10 11 12 13 14 15 16 17 18 19 20 After 21 joins

  16. Joining the Routing • the neighbors of the split zone must be notified so that routing can include the new node. • O sends its routing table to N ( IPs and Zones of O’s neighbors) • Having O’s routing table, N may figure out its routing table. • O re-computes its routing table. • Both O’s and N’s neighbors must be informed of this reallocation of space. • All of their neighbors update their own routing table.

  17. 1 2 3 4 5 1 2 3 4 5 6 7 8 9 10 6 7 8 9 21 10 11 12 13 14 11 12 13 14 15 16 17 18 19 15 16 17 18 19 20 20 Before 21 joins: 9: 4,8,10,13 4: 3,5,9 8: 2,3,7,9,12 10: 5,9,14 13: 9,12,14,17 After 21 joins: 9: 4,8, 21,13 4: 3,5,9, 21 8: 2,3,7,9,12 10: 5, 21 ,14 13: 9,12,14,17, 21 21: 4,9,10,13

  18. Departure • The zone of leaving node L must be taken over by the remaining nodes. • L explicitly hands over its zone and the associated (hash value, IP address) pair database to one of its neighbors. • Neighbors update their routing tables

  19. Node failure • Timer and beacon message • A beacon contains sender’s routing table. • Neighbors of the failed node F, elect a node taking over F’s zone • The (hash value, IP address) pair database of F is lost • Periodical refresh messages sent by supplier (file holder) to handle stale, lost pairs

  20. Design improvements • Reduce the latency of routing, increase system robustness • Increase per-node state and system complexity e.g. Multiple hash functions • use k different hash functions • a single file is mapped onto k points in the space • and corresponding (hash value, IP) pairs are stored at k distinct nodes • k replicas, parallel routing, but more query traffic

  21. Security Considerations • Assumption of attackers • Node ID • Message forwarding • DoS • Rapid Joins and Leaves • Forged routing table update • Inconsistent behavior

  22. Assumption of Attackers • Participants who do not follow the protocol correctly • Provide false information, forge source IP address • Modify, drop message passing them • May conspire together • Cannot overhear or modify direct communication between other nodes

  23. Attacks related to NodeID • Join attack --A node may choose its joining point J • Control victim node’s access to the CAN • Control other nodes accessing victim file.

  24. 1 2 3 4 5 1 2 3 4 22 5 6 7 8 9 10 6 7 8 9 21 10 23 24 11 12 13 14 11 12 13 14 15 16 17 18 19 15 16 17 18 19 20 20 Attackers may control victim node’s (5 and 10) access to the CAN.

  25. 1 2 3 4 5 1 2 3 4 5 6 7 8 9 10 6 7 8 9 21 10 D D 11 12 13 14 11 12 13 14 15 16 17 18 19 15 16 17 18 19 20 20 • Attacker wants to control the access of a file. • compute the hash value of the file and associated point (D) in the space • Use D as the join point and send JOIN • With the probability 0.5, it may get the zone containing D and (hash value, IP) pairs

  26. Secure NodeID generation • Prevent attackers from choosing joining point as they want !!! • A node generates its ID by applying secure hash function on its public key PK. • Using same secure hash function, so the space of files’ hash value and ID space are same. • Like hash value of a file, ID is deterministically mapped to a point J in the space.

  27. Secure NodeID generation con’t • Use J as the joining point. • JOIN includes ID, PK and signature. • Receiving a JOIN, a node O does: • checks if J is in O’s zone, • validates ID by applying the hash function on PK, • validates the signature. • Use the NodeID as the joining Point !!!

  28. Sybil attacks [5] • Attackers cannot choose nodeIDs or joining points • But they can obtain a large number of legitimate nodeIDs easily. • Attacker may control large amount of nodes • Trusted Certification Authorities (CA) assign nodeID and sign a certificate (ID, IP, PK). • Entrance fee, or offline, or bind nodeID to real word ID. • CA’s PK can be installed as part of the CAN node software

  29. Attacks on message routing • Attacker is on the path: • drops the message –timer ? • modifies or sends wrong answer back • Detect –check responder’s ID and signature ? • Non-deterministic routing – change route ? • Attacker is the destination or neighbors. • Multi hash functions – replicas • Attacker cannot control all replicas (secure nodeID assign)

  30. (0,111) (111,111) 1 2 3 4 5 P 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 (111,0) (0,0)

  31. DoS on CAN • Attacker generates huge amount of query messages. Victim node can not serve other nodes • Incoming Allocation Strategy [6] • Processor scheduling strategy • E.g. Round-Robin (RR) scheduling • Check neighbors’ IDs

  32. 8 12 11 13 16

  33. Discussion • Rapid Joins and Leaves ? • Forged routing table update ? • Inconsistent behavior ? • We have to have Secure NodeID generation & Multi hash functions !!!

  34. References • Napster. http://www.napster.com • Ratnassamy, S., Francis, P., Handley, M., Karp, R., Shenker, S. A Scalable Content-Addressable Network August 2001 • Sit, E. and Morris R. Security Considerations for Peer-to-Peer Distributed Hash Tables March 2002 • Castro, M., Druschel, P., Ganesh, A., Rowstron, A. and Wallach,D., Secure routing for structured peer-to-peer overlay networks December 2002 • John R. Douceur. The Sybil attack. March 2002 • Neil Daswani and Hector Garcia-Molina Query-flood DoS attacks in Gnutella November 2002

More Related