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

1. Providing Witness Anonymity in Peer-to-Peer SystemsBo Zhu, SanjeevSetia and SushilJajodia CSCE 715 Ankur Jain 11/16/2010

2. Outline • Introduction • Design Goals • Framework • SDT Protocol • Achievements of Goals • Overhead of SDT • Conclusion

3. 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.

4. 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.

5. 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.

6. Design Goals • Identity Anonymity • Backward Anonymity • Traceability • Non-slanderability. • Additional Goals • Efficiency • Decentralization.

7. 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.

8. 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.

9. 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.

10. 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.

11. 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.

12. 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.

13. 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

14. 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.

15. 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.

16. 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.

17. 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.

18. 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.

19. 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.

20. 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.

21. 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.

22. 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.

23. 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.

24. 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.

25. Questions