github.com/jlmucb/cloudproxy@v0.0.0-20170830161738-b5aa0b619bc4/go/apps/mixnet/README.md (about) 1 Mixnet over CloudProxy 2 ====================== 3 4 A mixnet router facilitates anonymous communications among a set of peers. 5 Alice wants to send Msg to Bob; she encrypts, authenticates, and sends the 6 message (Msg, Bob) to Molly, a mixnet router. Molly waits until she has _n-1_ 7 more messages from _n-1_ other peers, then transmits the messages to their 8 respective destinations simultaneously, thus anonymizing Alice among a set of n 9 peers. Such a service is only useful if Molly can be trusted to not divulge the 10 link (Alice, Bob). This document specifies a simple mixnet built on the 11 CloudProxy platform that reduces this trust to the knowledge of a public key 12 and trust in the owner of that key. 13 14 Security goals and threat model 15 ------------------------------- 16 There are three principals in our protocol: the sender, recipient, and the 17 policy owner. Our goal is to design a protocol that provides anonymity for 18 senders without requiring the recipient to execute the protocol. The policy 19 owner controls the root policy private key that is used to attest to the 20 instantiation of mixnet routers using the CloudProxy platform. CloudProxy 21 exposes the code to the users, as well as the operating system in which it is 22 running. To instantiate a mixnet router, a TPM coupled with the hardware 23 platform generates a public key, which is attested to by the policy owner by 24 signing it with the private policy key. When the machine boots, the OS is 25 measured and generates a private/public key pair, which is attested to by the 26 TPM; finally, the mixnet code itself is measured and generates a private/public 27 key pair, which is attested to by the OS. Hence, trust in the mixnet 28 routers to faithfully carry out the protocol is reduced to correct 29 provisioning of the policy key. 30 31 We consider a global passive adversary who observes all communications between 32 senders and mixnet routers, mixnet routers and other mixnet routers, and mixnet 33 routers and recipients. The adversary may also send messages on channels it 34 observes. Since the service is anonymous, the adversary is allowed to control 35 any number of senders or recipients. The effect is that the state of that peer 36 is exposed, including any and all cryptographic keys. We assume that the policy 37 key was correctly provisioned; if the code implements the protocol correctly and 38 is properly isolated during its execution, we claim this precludes the 39 possibility of exposing a router’s state. (This is a strong claim offered here 40 without proof. CloudProxy provides assurance that the expected program is 41 running; assuming the code does not contain any bugs that allow it to be 42 comprimised, a formal treatment of our protocol should reduce the adversary's 43 control of the routers to standard cryptographic assumptions: in particular, 44 CDH on elliptic curves, as well as the integrity and confidentiality of the 45 cipher suite underyling TLS.) 46 47 The intended property of communications over the mixnet is unlinkability in the 48 sense of [1]. Consider a set of senders _S_ where _|S| = n_ and a set of 49 recipients _T_. Each sender chooses one recipient as well as a message to send 50 so that _M : S → T_ is an onto mapping. The messages are transmitted to their 51 respective recipients over the mixnet; the adversary succeeds if it outputs 52 _(s, t)_ such that _M(s) = t_, unless it controls both _s_ and _t_. We say that 53 communication over the mixnet is _unlinkable_ if for any adversary the 54 probability of success is less than _1/n_ plus some negligible value. 55 56 _Alternative definition:_ as above, except the adversary chooses the messages to 57 be sent. This change may make it easier to analyze the unlinkability of a 58 particular protocol. However, this would require the recipients to participate 59 in the protocol, since messages exiting the mixnet must be encrypted. 60 61 For a protocol to achieve security in this sense, the messages must all have the 62 same length; of course, this is not always reasonable in practice. Mixnets 63 address this by splitting messages into fixed-length cells. Senders split 64 messages into cells (zero-padding the last cell as needed) and send them to the 65 first router where they are added to a queue. At each round the router waits 66 until there are _m_ cells in the queue from _m_ distinct senders and transmits 67 these simultaneously to achieve anonymity. 68 69 Extending the definition of unlinkability to a mixnet that divides messages into 70 cells and transmits at rounds is challenging: the presence of 71 variable-length messages exposes traffic patterns to the adversary. One way to 72 mitigate this problem is to zero-pad all messages to the length of the longest 73 message. This achieves a property called _unobservability_ [1] which is too 74 expensive for our purposes. 75 76 Another appraoch is to weaken the security model to one in which the adversary 77 may only observe a fraction of the network at any one time; relaying messages 78 over circuits of routers may make it more difficult to perform traffic 79 analysis. This is the case for the design of the Tor onion-routing protocol [2]. 80 We will consider extending our protocol to a network of routers to achieve 81 security in this model. This approach may have the added benifit of reducing 82 latency of messages traversing the mixnet. 83 84 Design Overview 85 --------------- 86 87 Our mixnet design consists of two major component, _router_ and _proxy_, and one 88 administrative component, _directory_. A router (`mixnet_router`), or a _mix_, 89 shuffles and routes users' messages, and a proxy (`mixnet_proxy`) accepts any 90 TCP connections via a SOCKS5 proxy from a user and relays the packets through 91 the mixnet. A directory (`mixnet_directory`) acts as a synchronization point, 92 and manages a list of available routers in the mixnet currently for other 93 routers and proxies to use. 94 95 At a high level, our design is, at least at the moment, an asynchronous 96 free-flow mixnet. Unlike cascade-mixnets, a free-flow mixnet allows different 97 messages to be routed through different paths through the network of mixes. It 98 is also asynchronous in the sense that each mix makes their own routing 99 decisions without coordinating with rest of the mixes in the network. 100 101 A typical messaging session for two end-to-end users, Alice and Bob, works as 102 follows. 103 104 1. Proxy accepts a connection from Alice, and receives a message to send to Bob. 105 106 2. Proxy picks an _entry_ mix. It then establishes a one-way authenticated TLS 107 connection with the entry (the mix attests that it is running CloudProxy), 108 and requests to establish a _circuit_ to Bob. A circuit is a path of mixes in 109 the network the messages for this particular end-to-end connection will be 110 routed through. 111 112 3. The entry mix selects random mixes to form a circuit. It establishes a 113 two-way authenticated TLS connection to the next mix in the circuit, and it 114 relays the circuit creation request to the next hop. The next mix does the 115 same until the circuit reaches the _exit_ mix. 116 117 4. Once the circuit is established, the proxy sends the message over to the 118 entry mix. Every packet exchanged between a mix and a proxy, called a _cell_, 119 is of fixed length. If the message is shorter than a cell, then the message 120 is padded to the fixed length. If the message is longer, then it is broken 121 down into multiple cells. 122 123 5. Once enough cells from different proxies are available at the entry mix, it 124 permutes the cells, and sends the cells to the next mix in the circuit. 125 Similarly, the intermediate mixes in circuits wait for enough cells from 126 different circuits, and permute the cells, and send the cells to the next 127 hops. The exit mix reconstructs the message from cells, and send the message 128 to Bob. 129 130 6. Bob can respond to the message, and the message will traverse the mixnet 131 using the same circuit in reverse. 132 133 Note that in step 3, the entry mix picks the circuit through the network, not 134 Bob. This is because the entry mix, which is CloudProxy authenticated, is 135 assumed to be secure, and disabling malicious users (who are not authenticated) 136 from selecting the path will likely enable better security. 137 138 The design also made several design decisions that trades-off security and 139 performance. For instance, it may result in less latency to allow a mix in step 140 5 to treat connections from proxies and other routers the same way, and thus 141 requires less connections from proxies. This, however, could reduce the 142 anonymity set size of the proxies. Such design choices may change as we analyze 143 the security of the system further. 144 145 Code Overview 146 ------------- 147 148 Some of the important files are 149 150 * `queue.go`: Implements the batching and mixing functionality for cells. 151 * `router.go` Handles connections from/to proxies, routers, and end points. Uses 152 a queue from `queue.go` to maintain 3 different queues for (1) cells sent from 153 proxies, (2) cells sent to proxies, and (3) cells to/from other routers. This 154 is required to be run in CloudProxy environment. 155 * `socks5.go`: Implements a simple SOCKS5 proxy that proxy uses to listen to 156 end users. 157 * `proxy.go`: Uses socks5 to receive messages from end-users, breaks the 158 messages into cells, and handles communication with the entry mix. 159 * `conn.go`, `listener.go`, `circuit.go`: Used to manage different network 160 connections and circuits. 161 * `mixnet.proto`: Specifies the directives (e.g., creating/destroying circuits) 162 used by proxies and routers. 163 164 Parameters 165 ---------- 166 167 There are server system wide parameters that impact the security and performance 168 of the system. 169 170 * Batch size (`batchsize`): This determines how many cells from different circuits 171 or proxies a router needs to collect before mixing and sending them to the next 172 hop in the circuit. 173 174 * Hop length: Currently, the default number of hops in the circuit is set to 3. 175 Longer circuits will likely provide better anonymity, at the cost of increased 176 latency, and vice-versa. The hop count also need not be fixed for all circuits, 177 but we assume it is for simpler design and analysis. 178 179 * Cell size: Each cell is fixed at 1024B currently. This should be at most 65KB, 180 the maximum packet length for TCP. 181 182 183 Tests 184 ----- 185 186 `mixnet_test.go` and other test files contain unit tests and integration tests 187 that can be run natively in Go. The largest integration test uses 20 proxies, 188 6 routers, and there are four paths through the routers used by 20 proxies. 189 The messages are then echoed back to the proxies by a simple server at the 190 end of the circuit. 191 192 The scripts in `scripts` runs a full Tao test (currently with soft-tao). It 193 implements essentially the same integration test as the one in `mixnet_test.go`, 194 except it runs it with real Tao (though SoftTao at the moment). The script 195 assumes that CloudProxy is installed already. Please take a look at the README 196 in the `scripts` directory for instructions to run the scripts. 197 198 References 199 ---------- 200 201 [1] Andreas Pfitzman, 2010. _A terminology for talking about privacy by data_ 202 _minimization: Anonymity, Unlinkability, Undetectability, Unobservability,_ 203 _Pseudonymity, and Identity Management._ 204 https://dud.inf.tu-dresden.de/literatur/Anon_Terminology_v0.34.pdf 205 206 [2] Tor specification. https://svn.torproject.org/svn/projects/design-paper/tor-design.pdf 207 208 [3] SOCKS Protocol Version 5. http://tools.ietf.org/html/rfc1928