\documentstyle[twoside, fancyheadings, doublespace, fullpage, epsf]{article} \setstretch{1.5} \textheight 8.8 in \lhead{Michael Freedman ({\it mfreed@mit.edu}) \\ David Molnar ({\it dmolnar@hcs.harvard.edu})} \rhead{Free Haven Project: Threat Model and Attacks \\ \today} \begin{document} \pagestyle{fancy} \pagenumbering{arabic} \section{What This Is} This document describes the threat model for the Free Haven project. It states the security goals of the Free Haven system, and then describes classes of adversaries according to their motivation and capabilities. Specific attacks against the system are discussed, along with some possible countermeasures. \section{Security Goals and Failure Modes} This section is more or less taken from Roger Dingledine's definition of anonymity circulated on the freehaven-dev list and expanded a bit. Free Haven is a distributed storage system with these goals : \begin{itemize} \item Anonymity \item Integrity \end{itemize} \section{Adversaries and Their Goals} Global failure - the system is unusable Local failure - one node gets screwed. \section{Adversary Capabilities and Specific Attacks} Please note that attacks and exploits are listed in plain-text. Some possible solutions follow attacks in {\it italics}. \subsection{Servnet Node Adversaries} These adversaries try to take control of the node itself. Communication to and from other nodes gets through, but is no longer following protocol. \subsubsection{Active} \begin{itemize} \item Exploit trust model: \begin{itemize} \item Gain trust quickly: Trust \\ {\it Users have the planned ability to weight storage size versus duration accordingly to their needs. Systems in which size is relatively important in relation to trust might quickly gain trust in adversaries with large storage capacities.} %Current concept of storage is in Meg-Months. Change trust weight %to $(size)*(n*time)$, where $n$ is some constant which tells how much %more to weight time over size. Assumption: 10 gig storage for a 1000 %days is preferable to 1 terabyte for a 10 days.} \end{itemize} \item Access to share DB: \begin{itemize} \item Change number of failed attempts: System Integrity \item Change last known buddy location: Trust, System Integrity \\ {\it Target responds ``I never had it'' - trust db comparison.} \item Change size of share (how many required to reconstruct): System Integrity \\ {\it Compare information with buddy. Unlikely both will be modified.} \item Change public key of signer: System Integrity \\ Share no longer verifiable. Similar attack to dropping share, except much harder to pin blame. \\ {\it Rely on other means to reclaim: presense of buddy, robust information dispersal algorithm. Alternatively: trading protocol includes verifying share signature upon receiving file. Broadcast that signature bad when found.} \end{itemize} \item Make up receipts: Trust \\ {\it Receipts signed with private key} \item Make Data Unrecoverable: \begin{itemize} \item Destroy received share: System Integrity \item Ignore get requests for shares: System Integrity \item Content-specific share destruction: System Integrity \\ Trade constantly for a specific share. Then drop it. Worse, continually trade for a number of shares that are used to reconstruct a specific file, then attempt to destroy enough of them to make the entire file unrecoverable. \\ {\it If node is very choosy about what it will trade for, other nodes do not seek to trade with it as much.} \end{itemize} {\it All of these attacks are similar: shares appear lost in the system. We rely on our robust information dispersal algorithm to still be able to reconstruct share. Also, the node's trust will diminish with repeated attacks as such.} \item False broadcast messages: \begin{itemize} \item Dropped share: Trust \\ {\it Target responds with negative} \item Target lost buddy: Trust \\ {\it Target responds with negative} \item Target is bad trading partner: Trust \\ {\it Target responds with negative. These last three attacks } \item Flood servnet with messages: DoS \\ Generally, only some subset of servnet wants to make itself explicitly public. However, any node that has existed on servnet for a while will learn its geography, and thus be able to flood mixnet with messages to all the nodes. \end{itemize} \item Marking attack: Anonymity \\ Given a specific reply block to different persistent IDs, be able to determine which messages come from that ID, given a different final hop. \end{itemize} \subsubsection{Passive} \begin{itemize} \item Access to encrypted messages: \begin{itemize} \item Reply headers: Anonymity \item Actual message: Anonymity \end{itemize} \item Make Data Unrecoverable: \begin{itemize} \item Go offline: System Integrity \item Lose shares: System Integrity \end{itemize} {\it Robust information dispersal and recovery. Node loses trust.} \item Attempt to reconstruct everything known \item Content-biased: \begin{itemize} \item Check for ``bad'' data: System Goals, Secrecy \item Try to share ``bad'' data away: System Goals, Secrecy \end{itemize} Both of these passive attacks move away from the content-unbiased concept of FreeHaven that we are trying to develop. Not only is this somewhat counter to one of the goals/design motivations, but an edge adversary might gain some information from such via traffic analysis. If a node is known to dislike certain content-types, then refusals to trade or quickly trading certain shares suggests that these shares have a certain content. \\ {\it If a node is very choosy during trades, other nodes lose trust in it and will trade less. As mentioned before: possibility of detecting excessive trades, suggesting content-biased searching (described above) or offloading (described here).} \end{itemize} \subsection{Adversaries within the Mixnet} These adversaries attack the communication links between nodes. That is, they attack mix-nets or just cut off nodes from the outside world. For more in-depth description of some attacks, see Mixmaster notes.\footnote{http://www.obscura.com/\~{}loki/remailer/remailer-essay.html} \begin{itemize} \item Timing packets through mixnet nodes: Anonymity \\ Relate timing of traffic in and out of node, in order to determine last-hop / next-hop route of packet. \\ {\it Initial solution to include delays in resending messages. Adds extra latency and still open to traffic analysis attack, especially if traffic through mixnet node is small. \\ Reordering of packets witnesses mixnet node keeping N packets. When (N+1) packet arrives, send out random packet chosen from (N+1) pool. Attack: flood node with many more than N packets, able to determine which is yours. \\ Current implemention of Mixmaster uses both delay and reordering. Periodically send out all but N messages. Possible flood attack still available, provided DoS attack keeps any other real messages from entering pool.} \item Size of mixnet packets: Anonymity \\ Analyze traffic through node, examining packet size to determine last-hop / next-hop route of packet. \\ {\it All packets should be same size: pad messages.} \item Replay attack: Anonymity \\ A node receives a message with a certain reply block or persistent id. Either follow message to destination by resending same message to dest many times, or attempt to reverse-traceroute the sending by flooding the mixnet with messages for that sender. The attacker can then perform traffic analysis to detect which edges of the mixnet see a rise in traffic, suggesting the route to the given destination. \\ {\it Mixmaster suggests adding a random id number for each message. This stops the forward-traceroute, as a mixnet node will not resend a message that is already sent (by performing a db lookup on the id or, more advanced, implement some double-spending policy through digital cash. \\ Unresolved: how does this stop reverse tracerouting? An adversary can simply flood the mixnet with different messages, all for the same destination. Link padding and high traffic might help, but traffic analysis might exposure routing information.} \item Recover and read mixnet messages: Anonymity \\ {\it The cryptographic security of layered encryption scheme should prevent an adversary from computationally cracking the onion.} \item Lossyness of mixnet: System Integrity \\ Messages may be lost due to both active adversaries or passive system failure. This loss might have several effects on the system: \begin{itemize} \item Trading protocol and receipts \item Broadcasts \\ {\it Termination awareness: knowledge that all nodes have received an identical message.} \item Retrieving shares \\ {\it Robust information dispersal and recovery.} \item Trust system \\ {\it The quantity of trust considerations due to node interactions should far outweigh possible effects of mixnet lossyness.} \end{itemize} \end{itemize} \subsection{Adversaries between the Servnet nodes and Mixnet} \subsection{Rogue Users} \end{document}