Free Haven

1. Free Haven Mads Danquah Troels Krogh

2. Free Haven • Began as a research project started by a group of MIT students in December 1999 • Wanted to create a safe Data Haven where data could live happily in anonymity without fearing anything (including torture … more on that later)

3. Goals • Anonymity • For publishers that inserts data into the network, for servers that stores the data, and for readers that wants to retrieve the data • Persistence • Publishers of a document, and not the servers storing it, decides it’s lifetime, thus persistence can actually be achieved • Flexibility • The system should continue to function as servers leaves and joins the network • Accountability • The system should be able to limit the damage done by misbehaving servers

4. Free Haven • While the Free Haven article and project in general goes a long way to describe how to solve the different problems encountered, it does not provide any implementation of the solutions. • As for now, Free Haven is a research project without any concrete implementation. • Some of the of the mechanisms described in the following presentation will therefore rely on other systems that currently does not exist.

5. Design • The actors in this play are • Publishers (humans) that wants to store documents in the service • Servers that is a part of a network of servers (servnet) • Readers (humans) queries the network for documents

6. Design cont. • All servers maintain a database of public keys and “reply blocks” of all the other servers. Thus all servers know of all other servers in the Servnet

7. Anonymity • Anonymity protects the system from adversaries that tries to extract different kinds of information from the network • Anonymity provides plausible deniability for a server “nothing_else_matters.mp3 ? How where I supposed to know I stored that ??”

8. Different kinds of anonymity • Publisher Anonymity • An adversary cannot determine a connection between a document and its publisher • Reader Anonymity • An adversary cannot confirm that a reader is accessing a given document • Server Anonymity • An adversary cannot determine a connection between a document the server its stored on. • Query Anonymity • An server cannot determine which document it is serving when replying on a reader’s request

9. Different kinds of anonymity cont. • Document Anonymity • A server does not know which documents it is storing • Depends on the type of server: • Passive Server: the server only servers requests, and are not allowed to examine the data it is serving • Active server: the server is allowed to examine the data it is serving, and can participate in the network as a reader • Document anonymity, query anonymity in the right configuration should lead to plausible deniability

10. The Communication Channel • In order for the servers to communicate, Free Haven needs an anonymous communication channel • Despite the requirements for anonymity, participants in Free Haven still need to be able to address each other over the communication channel • Peers should address each others using pseudonyms • A pseudonym is an anonymous token that links to a “true name”, that is data which could reveal your real identity • Free Haven “currently” implements the communication channel via Remailers

11. Remailers • A remailer service allows a client to send anonymous emails. • The remailer hides the address of the original sender

12. “Routing” in a remailer service • Mails can be routed through several remailers to increase security • But a remailer on the route should only know where next hop goes

13. Onion routing - brief • The address header of the email consists of several layers of routing instructions, one for each hop • For each hop, a layer is removed • Each layer is encrypted with the public key of the remailer responsible for the next hop

14. Remailers – Reply Blocks • To allow other servers to communicate with it, the server S publishes a reply block. • A reply block is a body less email, addressed to the server itself • When another server Q wants to send a message to S, it obtains S’s replyblock, attaches the data it wants to sends, and ships it out on the remailer network • A reply block makes a good pseudonym !

15. Remailers • Remailers communicate via SMTP through TLS (Transport Layer Security) • In order to protect from traffic analysis attacks, a remailer could hold the mail for hours ! • That’s a long time to wait for you data

16. And now to something completely different (Troels)

17. Publication • Locate server that wants to publish the document. • Make own server or store on public server • Server splits the file using IDA • Spilt file into k shares, only n is needed to recreate • Create key pair (PKdoc, SKdoc) • Sign file with SKdoc • Create buddy pairs • Publish file e.g. start trading

18. Publication cont.

19. Publication cont. • A share should contain • Hash of public key • Share number • Buddy number • Expiration date • Data

20. Publication cont. • Example of share

21. Retrieval • Create PKclient, SKclient + one time remailer reply block • Obtain hash(PKdok) by magic • broadcast REQUEST(PKclient,hash(PKdok), reply block) • Each server with a share returns PKclient(SHAREx) using the reply block

22. Retrieval example

23. The Buddy System • Pairs of shares are associated as buddies • Each share is responsible for keeping an eye out for its buddy. • If a server fails to store a share, it’s buddy should detect the failure, and report the server to the reputation system

24. The Buddy System cont. • When a share is moved (due to trading) the buddy is notified • Due to latency of the underlying network (hours !) the buddy could also have moved when the notice arrives. • Previous holders of shares are required to forward notifications to the shares new location.

25. Where’s my Buddy ? Example:

26. Buddy System cont. • It should be possible to recreate the lost buddy from the remaining shares, but Free Haven leaves this option out due to of fear of an “exponential buddy population explosion”

27. Persistence • Publisher defines expiration date • Could be indefinitely • Revocation • Suggested by Free Haven • Make a hash of some value hash(x) • Sign the document with the hash(x) • Later revoke document using hash(x) • But they don’t

28. Persistence cont. • Problems • Complicates buddy system • Provides ownership • Links documents • Promotes torture

29. Trading - example

30. Trading • Provide cover for publishing • To let servers join and leave • To permit longer expiration dates • Ethical concerns • Moving target

31. Receipts • Receipts • Proof of half a transaction • Used in complains • Contains • Public keys of both servers involved • Information about shares • Timestamp • For each share it contains • Hash of the document key • Share number • Expiration date • size

32. Back to you Mads

33. Reputation • Free Haven uses a reputation system to protect itself from misbehaving servers • As long as a server behaves well, it gains reputation • Reputation is not gained right away, this forces even malicious servers to behave well at least some of the time • The reputation System is not described in any detail, but they do seem to have some problems with it

34. Accountability • The purpose of the Accountability property of Free Haven, is to keep malicious servers from hurting the service “to much™” • One attack by malicious servers could be to accept shares, and then fail to store them • To prevent this, Free Haven suggests a “Buddy System”

35. Flexibility - Server Join • Servers joins the network through Introducers • A Introducer is a server that are already a member of the network, and which is trusted by the others servers due to a high reputation • When a server has joined the network, it still needs to prove itself, and gain reputation. • To gain trust, the new server must offer storage space to the network and make one-way “trades”

36. Flexibility – Server Leave • If a server wants to leave the network it must first loose all it’s shares. • A server accomplishes this by trading away all of it’s shares for short-lived shares • This of cause requires that there are other servers in the network willing to make the trade … and that operator of the server are a very patient person

37. Free Haven - Status • The development of the Free Haven project is currently on hold for a number of reasons • The implementation of the Reputation System has proved more difficult to implement than they had expected • Search queries are done via broadcasting, inefficient • Free Haven requires a underlying anonymous communication channel. For now they suggest that you use remailers which have very high latency • As no implementation except from (unobtainable) proof-of-concept code exists, no tests have been made

38. Measurements • None • From the Free Haven article: “When designing Free Haven, we made some choices, such as the choice to include trading, based on only our intuition of what would make a robust, anonymous system. A mathematical model of anonymous storage would allow us to test this intuition and run simulations. We also need metrics” • Instead they’ve made some thoughts on how well they fulfill their anonymity goal

39. Anonymity recap • Publisher Anonymity • An adversary cannot determine a connection between a document and its publisher • Reader Anonymity • An adversary cannot confirm that a reader is accessing a given document • Server Anonymity • An adversary cannot determine a connection between a document the server its stored on. • Query Anonymity • An server cannot determine which document it is serving when replying on a reader’s request

40. Anonymity Properties • Perfect forward anonymity • There is no way to tell that a given transaction has taken place, once it is completed • Computational anonymity • There is no way an adversary can with ”reasonable” computing power can break protected data.

41. Anonymity Properties

42. The End

43. Anonymity in other systems

44. Attacks on documents • Physical attack: You only hit a small fraction • Legal action: You have deniability • Denial of service: You’re f***** • Data flooding: You must trade

45. Attacks on reputation • Simple betrayal: pretending to be nice • Buddy coopting: gain control of buddy pairs

46. Attacks on anonymity • Attacks on reader anonymity • Auto loading Urls • Both mix- and servnet server • Attacks on server anonymity • Large shares • Trojan horse • Attacks on publisher anonymity • Log publishing • Look at server activety