Free Haven Mads Danquah Troels Krogh

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)

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

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.

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

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

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 ??”

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

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

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 R ers

R ers A r er service allows a client to send anonymous s. The r er hides the address of the original sender

“Routing” in a r er service Mails can be routed through several r ers to increase security But a r er on the route should only know where next hop goes

Onion routing - brief The address header of the 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 r er responsible for the next hop

R ers – Reply Blocks To allow other servers to communicate with it, the server S publishes a reply block. A reply block is a body less , 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 r er network A reply block makes a good pseudonym !

R ers R ers communicate via SMTP through TLS (Transport Layer Security) In order to protect from traffic analysis attacks, a r er could hold the mail for hours ! That’s a long time to wait for you data

And now to something completely different (Troels)

Publication 1.Locate server that wants to publish the document. 2.Make own server or store on public server 3.Server splits the file using IDA –Spilt file into k shares, only n is needed to recreate 4.Create key pair (PK doc, SK doc ) 5.Sign file with SK doc 6.Create buddy pairs 7.Publish file e.g. start trading

Publication cont.

A share should contain –Hash of public key –Share number –Buddy number –Expiration date –Data

Publication cont. Example of share

Retrieval Create PK client, SK client + one time r er reply block Obtain hash(PK dok ) by magic broadcast REQUEST(PK client, hash(PK dok ), reply block) Each server with a share returns PK client (SHARE x ) using the reply block

Retrieval example

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

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.

Where’s my Buddy ? Example :

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”

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

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

Trading - example

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

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

Back to you Mads

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

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”

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”

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

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 r ers which have very high latency As no implementation except from (unobtainable) proof-of-concept code exists, no tests have been made

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

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

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.

Anonymity Properties ProjectPublisherReaderServerDocumentQuery CP-FC C CC Free Haven Yes

The End

Anonymity in other systems

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

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

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