diff options
author | xrs <xrs@mail36.net> | 2018-11-03 12:46:25 +0100 |
---|---|---|
committer | xrs <xrs@mail36.net> | 2018-11-03 12:46:25 +0100 |
commit | cf4870390de2ff9ef4befc12aeb67aba538af385 (patch) | |
tree | db33bd658a80aa674ea3386fd5877cda66607b23 /doc/handbook/chapters/keyconcepts.texi | |
parent | 2770964bdd8f33c081e3b22c7295e7949e525188 (diff) | |
parent | 30ecc23f94aff98f1cfde23a82b455693f8aec15 (diff) | |
download | gnunet-cf4870390de2ff9ef4befc12aeb67aba538af385.tar.gz gnunet-cf4870390de2ff9ef4befc12aeb67aba538af385.zip |
Merge branch 'master' of ssh://gnunet.org/gnunet
Diffstat (limited to 'doc/handbook/chapters/keyconcepts.texi')
-rw-r--r-- | doc/handbook/chapters/keyconcepts.texi | 317 |
1 files changed, 317 insertions, 0 deletions
diff --git a/doc/handbook/chapters/keyconcepts.texi b/doc/handbook/chapters/keyconcepts.texi new file mode 100644 index 000000000..b4a60024c --- /dev/null +++ b/doc/handbook/chapters/keyconcepts.texi | |||
@@ -0,0 +1,317 @@ | |||
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://gnunet.org/git/bibliography.git/plain/docs/transport.pdf, https://gnunet.org/git/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://gnunet.org/git/bibliography.git/plain/docs/ebe.pdf, https://gnunet.org/git/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 | @end menu | ||
156 | |||
157 | Providing anonymity for users is the central goal for the anonymous | ||
158 | file-sharing application. Many other design decisions follow in the | ||
159 | footsteps of this requirement. | ||
160 | Anonymity is never absolute. While there are various | ||
161 | scientific metrics | ||
162 | (Claudia Díaz, Stefaan Seys, Joris Claessens, | ||
163 | and Bart Preneel. Towards measuring anonymity. | ||
164 | 2002. | ||
165 | (@uref{https://gnunet.org/git/bibliography.git/plain/docs/article-89.pdf, https://gnunet.org/git/bibliography.git/plain/docs/article-89.pdf})) | ||
166 | that can help quantify the level of anonymity that a given mechanism | ||
167 | provides, there is no such thing as "complete anonymity". | ||
168 | GNUnet's file-sharing implementation allows users to select for each | ||
169 | operation (publish, search, download) the desired level of anonymity. | ||
170 | The metric used is the amount of cover traffic available to hide the | ||
171 | request. | ||
172 | While this metric is not as good as, for example, the theoretical metric | ||
173 | given in scientific metrics, | ||
174 | it is probably the best metric available to a peer with a purely local | ||
175 | view of the world that does not rely on unreliable external information. | ||
176 | The default anonymity level is @code{1}, which uses anonymous routing but | ||
177 | imposes no minimal requirements on cover traffic. It is possible | ||
178 | to forego anonymity when this is not required. The anonymity level of | ||
179 | @code{0} allows GNUnet to use more efficient, non-anonymous routing. | ||
180 | |||
181 | @cindex How file-sharing achieves Anonymity | ||
182 | @node How file-sharing achieves Anonymity | ||
183 | @subsection How file-sharing achieves Anonymity | ||
184 | |||
185 | Contrary to other designs, we do not believe that users achieve strong | ||
186 | anonymity just because their requests are obfuscated by a couple of | ||
187 | indirections. This is not sufficient if the adversary uses traffic | ||
188 | analysis. | ||
189 | The threat model used for anonymous file sharing in GNUnet assumes that | ||
190 | the adversary is quite powerful. | ||
191 | In particular, we assume that the adversary can see all the traffic on | ||
192 | the Internet. And while we assume that the adversary | ||
193 | can not break our encryption, we assume that the adversary has many | ||
194 | participating nodes in the network and that it can thus see many of the | ||
195 | node-to-node interactions since it controls some of the nodes. | ||
196 | |||
197 | The system tries to achieve anonymity based on the idea that users can be | ||
198 | anonymous if they can hide their actions in the traffic created by other | ||
199 | users. | ||
200 | Hiding actions in the traffic of other users requires participating in the | ||
201 | traffic, bringing back the traditional technique of using indirection and | ||
202 | source rewriting. Source rewriting is required to gain anonymity since | ||
203 | otherwise an adversary could tell if a message originated from a host by | ||
204 | looking at the source address. If all packets look like they originate | ||
205 | from one node, the adversary can not tell which ones originate from that | ||
206 | node and which ones were routed. | ||
207 | Note that in this mindset, any node can decide to break the | ||
208 | source-rewriting paradigm without violating the protocol, as this | ||
209 | only reduces the amount of traffic that a node can hide its own traffic | ||
210 | in. | ||
211 | |||
212 | If we want to hide our actions in the traffic of other nodes, we must make | ||
213 | our traffic indistinguishable from the traffic that we route for others. | ||
214 | As our queries must have us as the receiver of the reply | ||
215 | (otherwise they would be useless), we must put ourselves as the receiver | ||
216 | of replies that actually go to other hosts; in other words, we must | ||
217 | indirect replies. | ||
218 | Unlike other systems, in anonymous file-sharing as implemented on top of | ||
219 | GNUnet we do not have to indirect the replies if we don't think we need | ||
220 | more traffic to hide our own actions. | ||
221 | |||
222 | This increases the efficiency of the network as we can indirect less under | ||
223 | higher load. | ||
224 | Refer to the following paper for more: | ||
225 | Krista Bennett and Christian Grothoff. | ||
226 | GAP --- practical anonymous networking. In Proceedings of | ||
227 | Designing Privacy Enhancing Technologies, 2003. | ||
228 | (@uref{https://gnunet.org/git/bibliography.git/plain/docs/aff.pdf, https://gnunet.org/git/bibliography.git/plain/docs/aff.pdf}) | ||
229 | |||
230 | @cindex Deniability | ||
231 | @node Deniability | ||
232 | @section Deniability | ||
233 | |||
234 | Even if the user that downloads data and the server that provides data are | ||
235 | anonymous, the intermediaries may still be targets. In particular, if the | ||
236 | intermediaries can find out which queries or which content they are | ||
237 | processing, a strong adversary could try to force them to censor | ||
238 | certain materials. | ||
239 | |||
240 | With the file-encoding used by GNUnet's anonymous file-sharing, this | ||
241 | problem does not arise. | ||
242 | The reason is that queries and replies are transmitted in | ||
243 | an encrypted format such that intermediaries cannot tell what the query | ||
244 | is for or what the content is about. Mind that this is not the same | ||
245 | encryption as the link-encryption between the nodes. GNUnet has | ||
246 | encryption on the network layer (link encryption, confidentiality, | ||
247 | authentication) and again on the application layer (provided | ||
248 | by @command{gnunet-publish}, @command{gnunet-download}, | ||
249 | @command{gnunet-search} and @command{gnunet-gtk}). | ||
250 | |||
251 | Refer to the following paper for more: | ||
252 | Christian Grothoff, Krista Grothoff, Tzvetan Horozov, | ||
253 | and Jussi T. Lindgren. | ||
254 | An Encoding for Censorship-Resistant Sharing. | ||
255 | 2009. | ||
256 | (@uref{https://gnunet.org/git/bibliography.git/plain/docs/ecrs.pdf, https://gnunet.org/git/bibliography.git/plain/docs/ecrs.pdf}) | ||
257 | |||
258 | @cindex Peer Identities | ||
259 | @node Peer Identities | ||
260 | @section Peer Identities | ||
261 | |||
262 | Peer identities are used to identify peers in the network and are unique | ||
263 | for each peer. The identity for a peer is simply its public key, which is | ||
264 | generated along with a private key the peer is started for the first time. | ||
265 | While the identity is binary data, it is often expressed as ASCII string. | ||
266 | For example, the following is a peer identity as you might see it in | ||
267 | various places: | ||
268 | |||
269 | @example | ||
270 | UAT1S6PMPITLBKSJ2DGV341JI6KF7B66AC4JVCN9811NNEGQLUN0 | ||
271 | @end example | ||
272 | |||
273 | @noindent | ||
274 | You can find your peer identity by running @command{gnunet-peerinfo -s}. | ||
275 | |||
276 | @cindex Zones in the GNU Name System (GNS Zones) | ||
277 | @node Zones in the GNU Name System (GNS Zones) | ||
278 | @section Zones in the GNU Name System (GNS Zones) | ||
279 | |||
280 | @c FIXME: Explain or link to an explanation of the concept of public keys | ||
281 | @c and private keys. | ||
282 | @c FIXME: Rewrite for the latest GNS changes. | ||
283 | GNS (Matthias Wachs, Martin Schanzenbach, and Christian Grothoff. | ||
284 | A Censorship-Resistant, Privacy-Enhancing and Fully Decentralized Name | ||
285 | System. In proceedings of 13th International Conference on Cryptology and | ||
286 | Network Security (CANS 2014). 2014. | ||
287 | @uref{https://gnunet.org/git/bibliography.git/plain/docs/gns2014wachs.pdf, https://gnunet.org/git/bibliography.git/plain/docs/gns2014wachs.pdf}) | ||
288 | zones are similar to those of DNS zones, but instead of a hierarchy of | ||
289 | authorities to governing their use, GNS zones are controlled by a private | ||
290 | key. | ||
291 | When you create a record in a DNS zone, that information is stored in your | ||
292 | nameserver. Anyone trying to resolve your domain then gets pointed | ||
293 | (hopefully) by the centralised authority to your nameserver. | ||
294 | Whereas GNS, being fully decentralized by design, stores that information | ||
295 | in DHT. The validity of the records is assured cryptographically, by | ||
296 | signing them with the private key of the respective zone. | ||
297 | |||
298 | Anyone trying to resolve records in a zone of your domain can then verify | ||
299 | the signature of the records they get from the DHT and be assured that | ||
300 | they are indeed from the respective zone. | ||
301 | To make this work, there is a 1:1 correspondence between zones and | ||
302 | their public-private key pairs. | ||
303 | So when we talk about the owner of a GNS zone, that's really the owner of | ||
304 | the private key. | ||
305 | And a user accessing a zone needs to somehow specify the corresponding | ||
306 | public key first. | ||
307 | |||
308 | @cindex Egos | ||
309 | @node Egos | ||
310 | @section Egos | ||
311 | |||
312 | @c what is the difference between peer identity and egos? It seems | ||
313 | @c like both are linked to public-private key pair. | ||
314 | Egos are your "identities" in GNUnet. Any user can assume multiple | ||
315 | identities, for example to separate their activities online. Egos can | ||
316 | correspond to "pseudonyms" or "real-world identities". Technically an | ||
317 | ego is first of all a key pair of a public- and private-key. | ||