diff options
Diffstat (limited to 'doc/old/handbook/chapters/keyconcepts.texi')
-rw-r--r-- | doc/old/handbook/chapters/keyconcepts.texi | 350 |
1 files changed, 350 insertions, 0 deletions
diff --git a/doc/old/handbook/chapters/keyconcepts.texi b/doc/old/handbook/chapters/keyconcepts.texi new file mode 100644 index 000000000..c8dd1599b --- /dev/null +++ b/doc/old/handbook/chapters/keyconcepts.texi | |||
@@ -0,0 +1,350 @@ | |||
1 | |||
2 | @cindex Key Concepts | ||
3 | @node Key Concepts | ||
4 | @chapter Key Concepts | ||
5 | |||
6 | In this section, the fundamental concepts of GNUnet are explained. | ||
7 | @c FIXME: Use @uref{https://docs.gnunet.org/bib/, research papers} | ||
8 | @c once we have the new bibliography + subdomain setup. | ||
9 | Most of them are also described in our research papers. | ||
10 | First, some of the concepts used in the GNUnet framework are detailed. | ||
11 | The second part describes concepts specific to anonymous file-sharing. | ||
12 | |||
13 | @menu | ||
14 | * Authentication:: | ||
15 | * Accounting to Encourage Resource Sharing:: | ||
16 | * Confidentiality:: | ||
17 | * Anonymity:: | ||
18 | * Deniability:: | ||
19 | * Peer Identities:: | ||
20 | * Zones in the GNU Name System (GNS Zones):: | ||
21 | * Egos:: | ||
22 | @end menu | ||
23 | |||
24 | @cindex Authentication | ||
25 | @node Authentication | ||
26 | @section Authentication | ||
27 | |||
28 | Almost all peer-to-peer communications in GNUnet are between mutually | ||
29 | authenticated peers. The authentication works by using ECDHE, that is a | ||
30 | DH (Diffie---Hellman) key exchange using ephemeral elliptic curve | ||
31 | cryptography. The ephemeral ECC (Elliptic Curve Cryptography) keys are | ||
32 | signed using ECDSA (@uref{http://en.wikipedia.org/wiki/ECDSA, ECDSA}). | ||
33 | The shared secret from ECDHE is used to create a pair of session keys | ||
34 | @c FIXME: Long word for HKDF. More FIXMEs: Explain MITM etc. | ||
35 | (using HKDF) which are then used to encrypt the communication between the | ||
36 | two peers using both 256-bit AES (Advanced Encryption Standard) | ||
37 | and 256-bit Twofish (with independently derived secret keys). | ||
38 | As only the two participating hosts know the shared secret, this | ||
39 | authenticates each packet | ||
40 | without requiring signatures each time. GNUnet uses SHA-512 | ||
41 | (Secure Hash Algorithm) hash codes to verify the integrity of messages. | ||
42 | |||
43 | @c FIXME: A while back I got the feedback that I should try and integrate | ||
44 | @c explanation boxes in the long-run. So we could explain | ||
45 | @c "man-in-the-middle" and "man-in-the-middle attacks" and other words | ||
46 | @c which are not common knowledge. MITM is not common knowledge. To be | ||
47 | @c selfcontained, we should be able to explain words and concepts used in | ||
48 | @c a chapter or paragraph without hinting at Wikipedia and other online | ||
49 | @c sources which might not be available or accessible to everyone. | ||
50 | @c On the other hand we could write an introductionary chapter or book | ||
51 | @c that we could then reference in each chapter, which sound like it | ||
52 | @c could be more reusable. | ||
53 | In GNUnet, the identity of a host is its public key. For that reason, | ||
54 | man-in-the-middle attacks will not break the authentication or accounting | ||
55 | goals. Essentially, for GNUnet, the IP of the host has nothing to do with | ||
56 | the identity of the host. As the public key is the only thing that truly | ||
57 | matters, faking an IP, a port or any other property of the underlying | ||
58 | transport protocol is irrelevant. In fact, GNUnet peers can use | ||
59 | multiple IPs (IPv4 and IPv6) on multiple ports --- or even not use the | ||
60 | IP protocol at all (by running directly on layer 2). | ||
61 | @c FIXME: "IP protocol" feels wrong, but could be what people expect, as | ||
62 | @c IP is "the number" and "IP protocol" the protocol itself in general | ||
63 | @c knowledge? | ||
64 | |||
65 | @c NOTE: For consistency we will use @code{HELLO}s throughout this Manual. | ||
66 | GNUnet uses a special type of message to communicate a binding between | ||
67 | public (ECC) keys to their current network address. These messages are | ||
68 | commonly called @code{HELLO}s or @code{peer advertisements}. | ||
69 | They contain the public key of the peer and its current network | ||
70 | addresses for various transport services. | ||
71 | A transport service is a special kind of shared library that | ||
72 | provides (possibly unreliable, out-of-order) message delivery between | ||
73 | peers. | ||
74 | For the UDP and TCP transport services, a network address is an IP and a | ||
75 | port. | ||
76 | GNUnet can also use other transports (HTTP, HTTPS, WLAN, etc.) which use | ||
77 | various other forms of addresses. Note that any node can have many | ||
78 | different active transport services at the same time, | ||
79 | and each of these can have a different addresses. | ||
80 | Binding messages expire after at most a week (the timeout can be | ||
81 | shorter if the user configures the node appropriately). | ||
82 | This expiration ensures that the network will eventually get rid of | ||
83 | outdated advertisements. | ||
84 | |||
85 | For more information, refer to the following paper: | ||
86 | |||
87 | Ronaldo A. Ferreira, Christian Grothoff, and Paul Ruth. | ||
88 | A Transport Layer Abstraction for Peer-to-Peer Networks | ||
89 | Proceedings of the 3rd International Symposium on Cluster Computing | ||
90 | and the Grid (GRID 2003), 2003. | ||
91 | (@uref{https://git.gnunet.org/bibliography.git/plain/docs/transport.pdf, https://git.gnunet.org/bibliography.git/plain/docs/transport.pdf}) | ||
92 | |||
93 | @cindex Accounting to Encourage Resource Sharing | ||
94 | @node Accounting to Encourage Resource Sharing | ||
95 | @section Accounting to Encourage Resource Sharing | ||
96 | |||
97 | Most distributed P2P networks suffer from a lack of defenses or | ||
98 | precautions against attacks in the form of freeloading. | ||
99 | While the intentions of an attacker and a freeloader are different, their | ||
100 | effect on the network is the same; they both render it useless. | ||
101 | Most simple attacks on networks such as @command{Gnutella} | ||
102 | involve flooding the network with traffic, particularly | ||
103 | with queries that are, in the worst case, multiplied by the network. | ||
104 | |||
105 | In order to ensure that freeloaders or attackers have a minimal impact | ||
106 | on the network, GNUnet's file-sharing implementation (@code{FS}) tries | ||
107 | to distinguish good (contributing) nodes from malicious (freeloading) | ||
108 | nodes. In GNUnet, every file-sharing node keeps track of the behavior | ||
109 | of every other node it has been in contact with. Many requests | ||
110 | (depending on the application) are transmitted with a priority (or | ||
111 | importance) level. That priority is used to establish how important | ||
112 | the sender believes this request is. If a peer responds to an | ||
113 | important request, the recipient will increase its trust in the | ||
114 | responder: the responder contributed resources. If a peer is too busy | ||
115 | to answer all requests, it needs to prioritize. For that, peers do | ||
116 | not take the priorities of the requests received at face value. | ||
117 | First, they check how much they trust the sender, and depending on | ||
118 | that amount of trust they assign the request a (possibly lower) | ||
119 | effective priority. Then, they drop the requests with the lowest | ||
120 | effective priority to satisfy their resource constraints. This way, | ||
121 | GNUnet's economic model ensures that nodes that are not currently | ||
122 | considered to have a surplus in contributions will not be served if | ||
123 | the network load is high. | ||
124 | |||
125 | For more information, refer to the following paper: | ||
126 | Christian Grothoff. An Excess-Based Economic Model for Resource | ||
127 | Allocation in Peer-to-Peer Networks. Wirtschaftsinformatik, June 2003. | ||
128 | (@uref{https://git.gnunet.org/bibliography.git/plain/docs/ebe.pdf, https://git.gnunet.org/bibliography.git/plain/docs/ebe.pdf}) | ||
129 | |||
130 | @cindex Confidentiality | ||
131 | @node Confidentiality | ||
132 | @section Confidentiality | ||
133 | |||
134 | Adversaries (malicious, bad actors) outside of GNUnet are not supposed | ||
135 | to know what kind of actions a peer is involved in. Only the specific | ||
136 | neighbor of a peer that is the corresponding sender or recipient of a | ||
137 | message may know its contents, and even then application protocols may | ||
138 | place further restrictions on that knowledge. In order to ensure | ||
139 | confidentiality, GNUnet uses link encryption, that is each message | ||
140 | exchanged between two peers is encrypted using a pair of keys only | ||
141 | known to these two peers. Encrypting traffic like this makes any kind | ||
142 | of traffic analysis much harder. Naturally, for some applications, it | ||
143 | may still be desirable if even neighbors cannot determine the concrete | ||
144 | contents of a message. In GNUnet, this problem is addressed by the | ||
145 | specific application-level protocols. See for example the following | ||
146 | sections @pxref{Anonymity}, @pxref{How file-sharing achieves Anonymity}, | ||
147 | and @pxref{Deniability}. | ||
148 | |||
149 | @cindex Anonymity | ||
150 | @node Anonymity | ||
151 | @section Anonymity | ||
152 | |||
153 | @menu | ||
154 | * How file-sharing achieves Anonymity:: | ||
155 | * How messaging provides Anonymity:: | ||
156 | @end menu | ||
157 | |||
158 | Providing anonymity for users is the central goal for the anonymous | ||
159 | file-sharing application. Many other design decisions follow in the | ||
160 | footsteps of this requirement. | ||
161 | Anonymity is never absolute. While there are various | ||
162 | scientific metrics | ||
163 | (Claudia Díaz, Stefaan Seys, Joris Claessens, | ||
164 | and Bart Preneel. Towards measuring anonymity. | ||
165 | 2002. | ||
166 | (@uref{https://git.gnunet.org/bibliography.git/plain/docs/article-89.pdf, https://git.gnunet.org/bibliography.git/plain/docs/article-89.pdf})) | ||
167 | that can help quantify the level of anonymity that a given mechanism | ||
168 | provides, there is no such thing as "complete anonymity". | ||
169 | |||
170 | GNUnet's file-sharing implementation allows users to select for each | ||
171 | operation (publish, search, download) the desired level of anonymity. | ||
172 | The metric used is based on the amount of cover traffic needed to hide | ||
173 | the request. | ||
174 | |||
175 | While there is no clear way to relate the amount of available cover | ||
176 | traffic to traditional scientific metrics such as the anonymity set or | ||
177 | information leakage, it is probably the best metric available to a | ||
178 | peer with a purely local view of the world, in that it does not rely | ||
179 | on unreliable external information or a particular adversary model. | ||
180 | |||
181 | The default anonymity level is @code{1}, which uses anonymous routing | ||
182 | but imposes no minimal requirements on cover traffic. It is possible | ||
183 | to forego anonymity when this is not required. The anonymity level of | ||
184 | @code{0} allows GNUnet to use more efficient, non-anonymous routing. | ||
185 | |||
186 | @cindex How file-sharing achieves Anonymity | ||
187 | @node How file-sharing achieves Anonymity | ||
188 | @subsection How file-sharing achieves Anonymity | ||
189 | |||
190 | Contrary to other designs, we do not believe that users achieve strong | ||
191 | anonymity just because their requests are obfuscated by a couple of | ||
192 | indirections. This is not sufficient if the adversary uses traffic | ||
193 | analysis. | ||
194 | The threat model used for anonymous file sharing in GNUnet assumes that | ||
195 | the adversary is quite powerful. | ||
196 | In particular, we assume that the adversary can see all the traffic on | ||
197 | the Internet. And while we assume that the adversary | ||
198 | can not break our encryption, we assume that the adversary has many | ||
199 | participating nodes in the network and that it can thus see many of the | ||
200 | node-to-node interactions since it controls some of the nodes. | ||
201 | |||
202 | The system tries to achieve anonymity based on the idea that users can be | ||
203 | anonymous if they can hide their actions in the traffic created by other | ||
204 | users. | ||
205 | Hiding actions in the traffic of other users requires participating in the | ||
206 | traffic, bringing back the traditional technique of using indirection and | ||
207 | source rewriting. Source rewriting is required to gain anonymity since | ||
208 | otherwise an adversary could tell if a message originated from a host by | ||
209 | looking at the source address. If all packets look like they originate | ||
210 | from one node, the adversary can not tell which ones originate from that | ||
211 | node and which ones were routed. | ||
212 | Note that in this mindset, any node can decide to break the | ||
213 | source-rewriting paradigm without violating the protocol, as this | ||
214 | only reduces the amount of traffic that a node can hide its own traffic | ||
215 | in. | ||
216 | |||
217 | If we want to hide our actions in the traffic of other nodes, we must make | ||
218 | our traffic indistinguishable from the traffic that we route for others. | ||
219 | As our queries must have us as the receiver of the reply | ||
220 | (otherwise they would be useless), we must put ourselves as the receiver | ||
221 | of replies that actually go to other hosts; in other words, we must | ||
222 | indirect replies. | ||
223 | Unlike other systems, in anonymous file-sharing as implemented on top of | ||
224 | GNUnet we do not have to indirect the replies if we don't think we need | ||
225 | more traffic to hide our own actions. | ||
226 | |||
227 | This increases the efficiency of the network as we can indirect less under | ||
228 | higher load. | ||
229 | Refer to the following paper for more: | ||
230 | Krista Bennett and Christian Grothoff. | ||
231 | GAP --- practical anonymous networking. In Proceedings of | ||
232 | Designing Privacy Enhancing Technologies, 2003. | ||
233 | (@uref{https://git.gnunet.org/bibliography.git/plain/docs/aff.pdf, https://git.gnunet.org/bibliography.git/plain/docs/aff.pdf}) | ||
234 | |||
235 | @cindex How messaging provides Anonymity | ||
236 | @node How messaging provides Anonymity | ||
237 | @subsection How messaging provides Anonymity | ||
238 | |||
239 | While the file-sharing tries to achieve anonymity through hiding actions in | ||
240 | other traffic, the messaging service provides a weaker form of protection | ||
241 | against identification. | ||
242 | |||
243 | The messaging service allows the use of an anonymous ego for the signing and | ||
244 | verification process of messages instead of a unique ego. This anonymous ego is | ||
245 | a publicly known key pair which is shared between all peers in GNUnet. | ||
246 | |||
247 | Using this ego only ensures that individual messages alone can't identify its | ||
248 | sender inside of a messenger room. It should be clarified that the route of | ||
249 | the traffic for each message can still be tracked to identify the senders peer | ||
250 | inside of a messenger room if the threat agent controls certain peers hosting | ||
251 | the room. | ||
252 | |||
253 | Also opening a room in the messenger service will potentially match your peer | ||
254 | identity with the internal member identity from the messenger service. So | ||
255 | despite using the anonymous ego you can reveal your peer identity. This means | ||
256 | to decrease the chance of being identified, it is recommended to enter rooms but | ||
257 | you should not open them for others. | ||
258 | |||
259 | @cindex Deniability | ||
260 | @node Deniability | ||
261 | @section Deniability | ||
262 | |||
263 | Even if the user that downloads data and the server that provides data are | ||
264 | anonymous, the intermediaries may still be targets. In particular, if the | ||
265 | intermediaries can find out which queries or which content they are | ||
266 | processing, a strong adversary could try to force them to censor | ||
267 | certain materials. | ||
268 | |||
269 | With the file-encoding used by GNUnet's anonymous file-sharing, this | ||
270 | problem does not arise. | ||
271 | The reason is that queries and replies are transmitted in | ||
272 | an encrypted format such that intermediaries cannot tell what the query | ||
273 | is for or what the content is about. Mind that this is not the same | ||
274 | encryption as the link-encryption between the nodes. GNUnet has | ||
275 | encryption on the network layer (link encryption, confidentiality, | ||
276 | authentication) and again on the application layer (provided | ||
277 | by @command{gnunet-publish}, @command{gnunet-download}, | ||
278 | @command{gnunet-search} and @command{gnunet-fs-gtk}). | ||
279 | |||
280 | Refer to the following paper for more: | ||
281 | Christian Grothoff, Krista Grothoff, Tzvetan Horozov, | ||
282 | and Jussi T. Lindgren. | ||
283 | An Encoding for Censorship-Resistant Sharing. | ||
284 | 2009. | ||
285 | (@uref{https://git.gnunet.org/bibliography.git/plain/docs/ecrs.pdf, https://git.gnunet.org/bibliography.git/plain/docs/ecrs.pdf}) | ||
286 | |||
287 | @cindex Peer Identities | ||
288 | @node Peer Identities | ||
289 | @section Peer Identities | ||
290 | |||
291 | Peer identities are used to identify peers in the network and are unique | ||
292 | for each peer. The identity for a peer is simply its public key, which is | ||
293 | generated along with a private key when the peer is started for the first | ||
294 | time. While the identity is binary data, it is often expressed as an ASCII | ||
295 | string. For example, the following is a peer identity as you might see it | ||
296 | in various places: | ||
297 | |||
298 | @example | ||
299 | UAT1S6PMPITLBKSJ2DGV341JI6KF7B66AC4JVCN9811NNEGQLUN0 | ||
300 | @end example | ||
301 | |||
302 | @noindent | ||
303 | You can find your peer identity by running @command{gnunet-peerinfo -s}. | ||
304 | |||
305 | @cindex Zones in the GNU Name System (GNS Zones) | ||
306 | @node Zones in the GNU Name System (GNS Zones) | ||
307 | @section Zones in the GNU Name System (GNS Zones) | ||
308 | |||
309 | @c FIXME: Explain or link to an explanation of the concept of public keys | ||
310 | @c and private keys. | ||
311 | @c FIXME: Rewrite for the latest GNS changes. | ||
312 | GNS zones are similar to those of DNS zones, but instead of a hierarchy of | ||
313 | authorities to governing their use, GNS zones are controlled by a private | ||
314 | key. | ||
315 | When you create a record in a DNS zone, that information is stored in your | ||
316 | nameserver. Anyone trying to resolve your domain then gets pointed | ||
317 | (hopefully) by the centralised authority to your nameserver. | ||
318 | Whereas GNS, being fully decentralized by design, stores that information | ||
319 | in DHT. The validity of the records is assured cryptographically, by | ||
320 | signing them with the private key of the respective zone. | ||
321 | |||
322 | Anyone trying to resolve records in a zone of your domain can then verify | ||
323 | the signature of the records they get from the DHT and be assured that | ||
324 | they are indeed from the respective zone. | ||
325 | To make this work, there is a 1:1 correspondence between zones and | ||
326 | their public-private key pairs. | ||
327 | So when we talk about the owner of a GNS zone, that's really the owner of | ||
328 | the private key. | ||
329 | And a user accessing a zone needs to somehow specify the corresponding | ||
330 | public key first. | ||
331 | |||
332 | For more information, refer to the following paper: | ||
333 | |||
334 | Matthias Wachs, Martin Schanzenbach, and Christian Grothoff. | ||
335 | A Censorship-Resistant, Privacy-Enhancing and Fully Decentralized Name | ||
336 | System. In proceedings of 13th International Conference on Cryptology and | ||
337 | Network Security (CANS 2014). 2014. | ||
338 | @uref{https://git.gnunet.org/bibliography.git/plain/docs/gns2014wachs.pdf, https://git.gnunet.org/bibliography.git/plain/docs/gns2014wachs.pdf} | ||
339 | |||
340 | @cindex Egos | ||
341 | @node Egos | ||
342 | @section Egos | ||
343 | |||
344 | @c what is the difference between peer identity and egos? It seems | ||
345 | @c like both are linked to public-private key pair. | ||
346 | Egos are your "identities" in GNUnet. Any user can assume multiple | ||
347 | identities, for example to separate their activities online. Egos can | ||
348 | correspond to "pseudonyms" or "real-world identities". Technically an | ||
349 | ego is first of all a key pair of a public- and private-key. | ||
350 | |||