providing witness anonymity in peer to peer systems bo zhu sanjeev setia and sushil jajodia n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Providing Witness Anonymity in Peer-to-Peer Systems Bo Zhu, Sanjeev Setia and Sushil Jajodia PowerPoint Presentation
Download Presentation
Providing Witness Anonymity in Peer-to-Peer Systems Bo Zhu, Sanjeev Setia and Sushil Jajodia

Loading in 2 Seconds...

play fullscreen
1 / 26

Providing Witness Anonymity in Peer-to-Peer Systems Bo Zhu, Sanjeev Setia and Sushil Jajodia - PowerPoint PPT Presentation


  • 123 Views
  • Uploaded on

Providing Witness Anonymity in Peer-to-Peer Systems Bo Zhu, Sanjeev Setia and Sushil Jajodia. CSCE 715 Ankur Jain 11/16/2010. Outline. Introduction Design Goals Framework SDT Protocol Achievements of Goals Overhead of SDT Conclusion. Introduction. Peer-to-Peer systems

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Providing Witness Anonymity in Peer-to-Peer Systems Bo Zhu, Sanjeev Setia and Sushil Jajodia' - fauve


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
providing witness anonymity in peer to peer systems bo zhu sanjeev setia and sushil jajodia

Providing Witness Anonymity in Peer-to-Peer SystemsBo Zhu, SanjeevSetia and SushilJajodia

CSCE 715

Ankur Jain

11/16/2010

outline
Outline
  • Introduction
  • Design Goals
  • Framework
  • SDT Protocol
  • Achievements of Goals
  • Overhead of SDT
  • Conclusion
introduction
Introduction
  • Peer-to-Peer systems
    • Distributed application architecture
    • Partitions task between peers equivalently.
    • E.g. – Skype, Cloud Computing, P2PTV and many more.
  • Fundamental Challenge
    • Trust relationship between peers.
    • Several research studies.
    • To build trust and reputation between peers.
requirements for trust management
Requirements for Trust Management
  • Reliability
    • Computing true trust value.
    • Presence of malicious user.
  • Anonymity
    • Non Identification of peers
  • Accountability
    • Identification of malicious peers.
  • Previous research focused on reliability.
motivation
Motivation
  • Overall Goal
    • Extend P2P trust management systems
    • To provide Witness Anonymity
  • To provide anonymity to person reporting malicious behavior.
  • To preserve privacy of peers.
  • To hide trust topology from malicious parties.
design goals
Design Goals
  • Identity Anonymity
  • Backward Anonymity
  • Traceability
  • Non-slanderability.
  • Additional Goals
    • Efficiency
    • Decentralization.
framework
Framework
  • System Model
    • No Trusted Third Party.
    • 2 types of user
      • Offline Group Manager (OGM)
      • User
    • # of adversaries less than threshold t.
  • Adversary Model
    • 2 types of adversaries
      • Malicious user
      • Selfish user
    • Will collude together to maximize the attack.
framework1
Framework
  • Network Model
    • Mixnet based anonymous system
      • Consist of series of servers called MIXes.
      • Associated with public keys.
      • Receives encrypted messages.
      • Decrypts, batches, permutes, forwards messages.
      • Strips off sender’s name and identifying information.
    • Mechanism for monitoring claims sent
      • Irrespective of claims being generated or forwarded.
sdt protocol
SDT Protocol
  • SDT – Secure Deep Throat
    • Provide anonymity and accountability together.
    • Include tracing mechanism to identify user.
  • 4 step procedure
    • Setup
    • Registration
    • Claim Broadcasting
    • Public Tracing
  • Modes of Operation
    • Active: Real Time requirements.
    • Passive: Not strict Real Time requirements.
sdt protocol setup
SDT Protocol – Setup
  • OGM generates public and secret keys.
  • Identification list (LIST) initially empty.
  • Define tag bases
    • Used in claim broadcasting
    • To create anonymous claims.
    • Only one per type of misbehavior per user.
sdt protocol registration
SDT Protocol – Registration
  • User contacts OGM.
  • User selects identity.
  • Check its availability.
  • User obtains a member public/secret key pair.
  • OGM adds a new entry to LIST.
  • OGM select s items from LIST and sends it to user.
  • User sends confirmation for key pair and LIST items received.
sdt protocol claim broadcasting
SDT Protocol – Claim Broadcasting
  • User maintain two databases.
    • Maintains claim sent by herself.
    • Maintains claim received from other user.
  • On detecting malicious behavior
    • Checks database for previous entries for same type of behavior.
    • If not found generates new claim using tag base.
    • Broadcast through anonymous communication system.
    • Also stores claim in database.
sdt protocol claim broadcasting1
SDT Protocol – Claim Broadcasting
  • On receiving claim
    • Checks whether entry for that claim is present or not.
    • If yes, then drops the claim.
    • If not check its validity and stores the claim.
    • Also forwards it in the system.
  • Initializing Public Tracing
    • User finds t claims.
    • Checks distinctness of all t claims.
    • Generates a message including t claims and broadcast it to network
sdt protocol public tracing
SDT Protocol – Public Tracing
  • Check for entries in databases.
  • If found broadcast two entries as proof to disclose the identity of malicious user.
  • If no entries found broadcast message NO-ONE.
  • After receiving NO-ONE message other repeat the steps in their local LIST.
sdt protocol passive mode
SDT Protocol – Passive Mode
  • Used when real time requirement is not critical.
  • Achieve better efficiency.
  • Changes in claims broadcasting
    • Claims regarding malicious behavior not sent immediately.
    • Sent these claims only when queried about the behavior of user.
  • Public tracing will performed on all claims to prevent multiple claims from an adversary.
sdt protocol probabilistic forwarding
SDT Protocol – Probabilistic Forwarding
  • Peer forwards claim with a probability.
  • Instead of flooding entire network.
  • Lower the probability, lower is the number of peers storing the claim.
  • Lower is the probability that one peer stores every t distinct claims.
  • Require more number of witnesses in this case.
  • Also non zero probability that adversary may escape disclosure.
achievement of goals
Achievement of Goals
  • Identity Anonymity
    • May be broken using Traffic Analysis or Protocol Analysis
    • Traffic Analysis is prevented by Mixnet based communication system.
    • Protocol Analysis is also hard to perform
    • No public key in claim broadcasted
    • All parameter are calculated using discrete algorithm so very robust against brute force attack.
achievement of goals1
Achievement of Goals
  • Backward Anonymity
    • Adversaries can compromise multiple peers.
    • Claim does not provide information regarding identity.
    • No way to differentiate the user on basis of claims.
    • Also ensured when OGM and adversaries are in contact
    • User’s secret key is only known to user.
    • No way to extract secret key from OGM.
achievement of goals2
Achievement of Goals
  • Traceability
    • Good peers need to find a valid record of adversary from LIST.
    • LIST items are distributed among different peers.
    • Probability of all copies controlled by adversary group is very small.
achievement of goals3
Achievement of Goals
  • Non-Slanderability
    • Max number of claims sent by adversaries against a user
    • Total number of adversaries which is less than t.
    • Adversaries cannot collect enough claims to remove good user from the system.
overhead of sdt
Overhead of SDT
  • Distributed storage of LIST
    • OGM maintains LIST offline.
    • LIST is stored in distributed form.
    • Peers do not have knowledge of LIST items with other peers.
    • Helps in detecting a adversary even if adversary is controlling the majority of LIST.
overhead of sdt1
Overhead of SDT
  • Communication Costs
    • Major cost is forwarding claims.
    • Implemented using elliptic curve or hyper elliptic curve over a finite field.
    • Claim size not more than 409 bytes.
    • LIST distribution another cost.
    • Smaller the LIST, higher probability of message broadcast while tracing.
overhead of sdt2
Overhead of SDT
  • Storage Requirements
    • For cryptographic keys, LIST and local databases.
      • Storing personal keys and public key of OGM.
      • Only small part of the entire LIST.
      • Very small database requirement in passive mode.
      • A probabilistic forwarding approach may reduce database space in active mode.
conclusion
Conclusion
  • SDT provide witness anonymity to users reporting malicious behavior.
  • Two modes of operation: Active and Passive.
  • Overhead is acceptable in peer-to-peer systems.