1 Filename: 121-hidden-service-authentication.txt
2 Title: Hidden Service Authentication
5 Author: Tobias Kamm, Thomas Lauterbach, Karsten Loesing, Ferdinand Rieger,
13 26-Sep-2007 Initial proposal for or-dev
14 08-Dec-2007 Incorporated comments by Nick posted to or-dev on 10-Oct-2007
15 15-Dec-2007 Rewrote complete proposal for better readability, modified
16 authentication protocol, merged in personal notes
17 24-Dec-2007 Replaced misleading term "authentication" by "authorization"
18 and added some clarifications (comments by Sven Kaffille)
19 28-Apr-2008 Updated most parts of the concrete authorization protocol
20 04-Jul-2008 Add a simple algorithm to delay descriptor publication for
21 different clients of a hidden service
22 19-Jul-2008 Added INTRODUCE1V cell type (1.2), improved replay
23 protection for INTRODUCE2 cells (1.3), described limitations
24 for auth protocols (1.6), improved hidden service protocol
25 without client authorization (2.1), added second, more
26 scalable authorization protocol (2.2), rewrote existing
27 authorization protocol (2.3); changes based on discussion
29 31-Jul-2008 Limit maximum descriptor size to 20 kilobytes to prevent
31 01-Aug-2008 Use first part of Diffie-Hellman handshake for replay
32 protection instead of rendezvous cookie.
36 This proposal deals with a general infrastructure for performing
37 authorization (not necessarily implying authentication) of requests to
38 hidden services at three points: (1) when downloading and decrypting
39 parts of the hidden service descriptor, (2) at the introduction point,
40 and (3) at Bob's Tor client before contacting the rendezvous point. A
41 service provider will be able to restrict access to his service at these
42 three points to authorized clients only. Further, the proposal contains
43 specific authorization protocols as instances that implement the
44 presented authorization infrastructure.
46 This proposal is based on v2 hidden service descriptors as described in
47 proposal 114 and introduced in version 0.2.0.10-alpha.
49 The proposal is structured as follows: The next section motivates the
50 integration of authorization mechanisms in the hidden service protocol.
51 Then we describe a general infrastructure for authorization in hidden
52 services, followed by specific authorization protocols for this
53 infrastructure. At the end we discuss a number of attacks and non-attacks
54 as well as compatibility issues.
58 The major part of hidden services does not require client authorization
59 now and won't do so in the future. To the contrary, many clients would
60 not want to be (pseudonymously) identifiable by the service (though this
61 is unavoidable to some extent), but rather use the service
62 anonymously. These services are not addressed by this proposal.
64 However, there may be certain services which are intended to be accessed
65 by a limited set of clients only. A possible application might be a
66 wiki or forum that should only be accessible for a closed user group.
67 Another, less intuitive example might be a real-time communication
68 service, where someone provides a presence and messaging service only to
69 his buddies. Finally, a possible application would be a personal home
70 server that should be remotely accessed by its owner.
72 Performing authorization for a hidden service within the Tor network, as
73 proposed here, offers a range of advantages compared to allowing all
74 client connections in the first instance and deferring authorization to
75 the transported protocol:
77 (1) Reduced traffic: Unauthorized requests would be rejected as early as
78 possible, thereby reducing the overall traffic in the network generated
79 by establishing circuits and sending cells.
81 (2) Better protection of service location: Unauthorized clients could not
82 force Bob to create circuits to their rendezvous points, thus preventing
83 the attack described by Ă˜verlier and Syverson in their paper "Locating
84 Hidden Servers" even without the need for guards.
86 (3) Hiding activity: Apart from performing the actual authorization, a
87 service provider could also hide the mere presence of his service from
88 unauthorized clients when not providing hidden service descriptors to
89 them, rejecting unauthorized requests already at the introduction
90 point (ideally without leaking presence information at any of these
91 points), or not answering unauthorized introduction requests.
93 (4) Better protection of introduction points: When providing hidden
94 service descriptors to authorized clients only and encrypting the
95 introduction points as described in proposal 114, the introduction points
96 would be unknown to unauthorized clients and thereby protected from DoS
99 (5) Protocol independence: Authorization could be performed for all
100 transported protocols, regardless of their own capabilities to do so.
102 (6) Ease of administration: A service provider running multiple hidden
103 services would be able to configure access at a single place uniformly
104 instead of doing so for all services separately.
106 (7) Optional QoS support: Bob could adapt his node selection algorithm
107 for building the circuit to Alice's rendezvous point depending on a
108 previously guaranteed QoS level, thus providing better latency or
109 bandwidth for selected clients.
111 A disadvantage of performing authorization within the Tor network is
112 that a hidden service cannot make use of authorization data in
113 the transported protocol. Tor hidden services were designed to be
114 independent of the transported protocol. Therefore it's only possible to
115 either grant or deny access to the whole service, but not to specific
116 resources of the service.
118 Authorization often implies authentication, i.e. proving one's identity.
119 However, when performing authorization within the Tor network, untrusted
120 points should not gain any useful information about the identities of
121 communicating parties, neither server nor client. A crucial challenge is
122 to remain anonymous towards directory servers and introduction points.
123 However, trying to hide identity from the hidden service is a futile
124 task, because a client would never know if he is the only authorized
125 client and therefore perfectly identifiable. Therefore, hiding client
126 identity from the hidden service is not aimed by this proposal.
128 The current implementation of hidden services does not provide any kind
129 of authorization. The hidden service descriptor version 2, introduced by
130 proposal 114, was designed to use a descriptor cookie for downloading and
131 decrypting parts of the descriptor content, but this feature is not yet
132 in use. Further, most relevant cell formats specified in rend-spec
133 contain fields for authorization data, but those fields are neither
134 implemented nor do they suffice entirely.
138 1. General infrastructure for authorization to hidden services
140 We spotted three possible authorization points in the hidden service
143 (1) when downloading and decrypting parts of the hidden service
145 (2) at the introduction point, and
146 (3) at Bob's Tor client before contacting the rendezvous point.
148 The general idea of this proposal is to allow service providers to
149 restrict access to some or all of these points to authorized clients
152 1.1. Client authorization at directory
154 Since the implementation of proposal 114 it is possible to combine a
155 hidden service descriptor with a so-called descriptor cookie. If done so,
156 the descriptor cookie becomes part of the descriptor ID, thus having an
157 effect on the storage location of the descriptor. Someone who has learned
158 about a service, but is not aware of the descriptor cookie, won't be able
159 to determine the descriptor ID and download the current hidden service
160 descriptor; he won't even know whether the service has uploaded a
161 descriptor recently. Descriptor IDs are calculated as follows (see
162 section 1.2 of rend-spec for the complete specification of v2 hidden
163 service descriptors):
166 H(service-id | H(time-period | descriptor-cookie | replica))
168 Currently, service-id is equivalent to permanent-id which is calculated
169 as in the following formula. But in principle it could be any public
172 permanent-id = H(permanent-key)[:10]
174 The second purpose of the descriptor cookie is to encrypt the list of
175 introduction points, including optional authorization data. Hence, the
176 hidden service directories won't learn any introduction information from
177 storing a hidden service descriptor. This feature is implemented but
178 unused at the moment, so that this proposal will harness the advantages
181 The descriptor cookie can be used for authorization by keeping it secret
182 from everyone but authorized clients. A service could then decide whether
183 to publish hidden service descriptors using that descriptor cookie later
184 on. An authorized client being aware of the descriptor cookie would be
185 able to download and decrypt the hidden service descriptor.
187 The number of concurrently used descriptor cookies for one hidden service
188 is not restricted. A service could use a single descriptor cookie for all
189 users, a distinct cookie per user, or something in between, like one
190 cookie per group of users. It is up to the specific protocol and how it
191 is applied by a service provider.
193 Two or more hidden service descriptors for different groups or users
194 should not be uploaded at the same time. A directory node could conclude
195 easily that the descriptors, were issued by the same hidden service, thus
196 being able to link the two groups or users. Therefore, descriptors for
197 different users or clients that ought to be stored on the same directory
198 are delayed, so that only one descriptor is uploaded to a directory at a
199 time. The remaining descriptors are uploaded with a delay of 30 seconds.
200 Further, descriptors for different groups or users that are to be stored
201 on different directories are delayed for a random time of up to 30
202 seconds to hide relations from colluding directories. Certainly, this
203 does not prevent linking entirely, but it makes it somewhat harder.
204 There is a conflict between hiding links between clients and making a
205 service available in a timely manner.
207 Although this part of the proposal is meant to describe a general
208 infrastructure for authorization, changing the way of using the
209 descriptor cookie to look up hidden service descriptors, e.g. applying
210 some sort of asymmetric crypto system, would require in-depth changes
211 that would be incompatible to v2 hidden service descriptors. On the
212 contrary, using another key for en-/decrypting the introduction point
213 part of a hidden service descriptor, e.g. a different symmetric key or
214 asymmetric encryption, would be easy to implement and compatible to v2
215 hidden service descriptors as understood by hidden service directories
216 (clients and servers would have to be upgraded anyway for using the new
219 An adversary could try to abuse the fact that introduction points can be
220 encrypted by storing arbitrary, unrelated data in the hidden service
221 directory. This abuse can be limited by setting a hard descriptor size
222 limit, forcing the adversary to split data into multiple chunks. There
223 are some limitations that make splitting data across multiple descriptors
224 unattractive: 1) The adversary would not be able to choose descriptor IDs
225 freely and have to implement an own indexing structure. 2) Validity of
226 descriptors is limited to at most 24 hours after which descriptors need
229 The regular descriptor size in bytes is 745 + num_ipos * 837 + auth_data.
230 A large descriptor with 7 introduction points and 5 kilobytes of
231 authorization data would be 11724 bytes in size. The upper size limit of
232 descriptors should be set to 20 kilobytes, which limits the effect of
233 abuse while retaining enough flexibility in designing authorization
236 1.2. Client authorization at introduction point
238 The next possible authorization point after downloading and decrypting
239 a hidden service descriptor is the introduction point. It may be important
240 for authorization, because it bears the last chance of hiding presence
241 of a hidden service from unauthorized clients. Further, performing
242 authorization at the introduction point might reduce traffic in the
243 network, because unauthorized requests would not be passed to the
244 hidden service. This applies to those clients who are aware of a
245 descriptor cookie and thereby of the hidden service descriptor, but do
246 not have authorization data to pass the introduction point or access the
247 service (such a situation might occur when authorization data for
248 authorization at the directory is not issued on a per-user base as
249 opposed to authorization data for authorization at the introduction
252 It is important to note that the introduction point must be considered
253 untrustworthy, and therefore cannot replace authorization at the hidden
254 service itself. Nor should the introduction point learn any sensitive
255 identifiable information from either server or client.
257 In order to perform authorization at the introduction point, three
258 message formats need to be modified: (1) v2 hidden service descriptors,
259 (2) ESTABLISH_INTRO cells, and (3) INTRODUCE1 cells.
261 A v2 hidden service descriptor needs to contain authorization data that
262 is introduction-point-specific and sometimes also authorization data
263 that is introduction-point-independent. Therefore, v2 hidden service
264 descriptors as specified in section 1.2 of rend-spec already contain two
265 reserved fields "intro-authorization" and "service-authorization"
266 (originally, the names of these fields were "...-authentication")
267 containing an authorization type number and arbitrary authorization
268 data. We propose that authorization data consists of base64 encoded
269 objects of arbitrary length, surrounded by "-----BEGIN MESSAGE-----" and
270 "-----END MESSAGE-----". This will increase the size of hidden service
271 descriptors, which however is possible, as there is no strict upper
274 The current ESTABLISH_INTRO cells as described in section 1.3 of
275 rend-spec do not contain either authorization data or version
276 information. Therefore, we propose a new version 1 of the ESTABLISH_INTRO
277 cells adding these two issues as follows:
279 V Format byte: set to 255 [1 octet]
280 V Version byte: set to 1 [1 octet]
281 KL Key length [2 octets]
282 PK Bob's public key [KL octets]
283 HS Hash of session info [20 octets]
284 AUTHT The auth type that is supported [1 octet]
285 AUTHL Length of auth data [2 octets]
286 AUTHD Auth data [variable]
287 SIG Signature of above information [variable]
289 From the format it is possible to determine the maximum allowed size for
290 authorization data: given the fact that cells are 512 octets long, of
291 which 498 octets are usable (see section 6.1 of tor-spec), and assuming
292 1024 bit = 128 octet long keys, there are 215 octets left for
293 authorization data. Hence, authorization protocols are bound to use no
294 more than these 215 octets, regardless of the number of clients that
295 shall be authenticated at the introduction point. Otherwise, one would
296 need to send multiple ESTABLISH_INTRO cells or split them up, what we do
299 In order to understand a v1 ESTABLISH_INTRO cell, the implementation of
300 a relay must have a certain Tor version. Hidden services need to be able
301 to distinguish relays being capable of understanding the new v1 cell
302 formats and perform authorization. We propose to use the version number
303 that is contained in networkstatus documents to find capable
306 The current INTRODUCE1 cells as described in section 1.8 of rend-spec is
307 not designed to carry authorization data and has no version number, too.
308 Unfortunately, unversioned INTRODUCE1 cells consist only of a fixed-size,
309 seemingly random PK_ID, followed by the encrypted INTRODUCE2 cell. This
310 makes it impossible to distinguish unversioned INTRODUCE1 cells from any
311 later format. In particular, it is not possible to introduce some kind of
312 format and version byte for newer versions of this cell. That's probably
313 where the comment "[XXX011 want to put intro-level auth info here, but no
314 version. crap. -RD]" that was part of rend-spec some time ago comes from.
316 We propose that new versioned INTRODUCE1 cells use the new cell type 41
317 RELAY_INTRODUCE1V (where V stands for versioned):
320 V Version byte: set to 1 [1 octet]
321 PK_ID Identifier for Bob's PK [20 octets]
322 AUTHT The auth type that is supported [1 octet]
323 AUTHL Length of auth data [2 octets]
324 AUTHD Auth data [variable]
325 Encrypted to Bob's PK:
326 (RELAY_INTRODUCE2 cell)
328 The maximum length of contained authorization data depends on the length
329 of the contained INTRODUCE2 cell. A calculation follows below when
330 describing the INTRODUCE2 cell format we propose to use.
332 1.3. Client authorization at hidden service
334 The time when a hidden service receives an INTRODUCE2 cell constitutes
335 the last possible authorization point during the hidden service
336 protocol. Performing authorization here is easier than at the other two
337 authorization points, because there are no possibly untrusted entities
340 In general, a client that is successfully authorized at the introduction
341 point should be granted access at the hidden service, too. Otherwise, the
342 client would receive a positive INTRODUCE_ACK cell from the introduction
343 point and conclude that it may connect to the service, but the request
344 will be dropped without notice. This would appear as a failure to
345 clients. Therefore, the number of cases in which a client successfully
346 passes the introduction point, but fails at the hidden service should be
347 zero. However, this does not lead to the conclusion, that the
348 authorization data used at the introduction point and the hidden service
349 must be the same, but only that both authorization data should lead to
350 the same authorization result.
352 Authorization data is transmitted from client to server via an
353 INTRODUCE2 cell that is forwarded by the introduction point. There are
354 versions 0 to 2 specified in section 1.8 of rend-spec, but none of these
355 contains fields for carrying authorization data. We propose a slightly
356 modified version of v3 INTRODUCE2 cells that is specified in section
357 1.8.1 and which is not implemented as of December 2007. In contrast to
358 the specified v3 we avoid specifying (and implementing) IPv6 capabilities,
359 because Tor relays will be required to support IPv4 addresses for a long
360 time in the future, so that this seems unnecessary at the moment. The
361 proposed format of v3 INTRODUCE2 cells is as follows:
363 VER Version byte: set to 3. [1 octet]
364 AUTHT The auth type that is used [1 octet]
365 AUTHL Length of auth data [2 octets]
366 AUTHD Auth data [variable]
367 TS Timestamp (seconds since 1-1-1970) [4 octets]
368 IP Rendezvous point's address [4 octets]
369 PORT Rendezvous point's OR port [2 octets]
370 ID Rendezvous point identity ID [20 octets]
371 KLEN Length of onion key [2 octets]
372 KEY Rendezvous point onion key [KLEN octets]
373 RC Rendezvous cookie [20 octets]
374 g^x Diffie-Hellman data, part 1 [128 octets]
376 The maximum possible length of authorization data is related to the
377 enclosing INTRODUCE1V cell. A v3 INTRODUCE2 cell with
378 1024 bit = 128 octets long public keys without any authorization data
379 occupies 306 octets (AUTHL is only used when AUTHT has a value != 0),
380 plus 58 octets for hybrid public key encryption (see
381 section 5.1 of tor-spec on hybrid encryption of CREATE cells). The
382 surrounding INTRODUCE1V cell requires 24 octets. This leaves only 110
383 of the 498 available octets free, which must be shared between
384 authorization data to the introduction point _and_ to the hidden
387 When receiving a v3 INTRODUCE2 cell, Bob checks whether a client has
388 provided valid authorization data to him. He also requires that the
389 timestamp is no more than 30 minutes in the past or future and that the
390 first part of the Diffie-Hellman handshake has not been used in the past
391 60 minutes to prevent replay attacks by rogue introduction points. (The
392 reason for not using the rendezvous cookie to detect replays---even
393 though it is only sent once in the current design---is that it might be
394 desirable to re-use rendezvous cookies for multiple introduction requests
395 in the future.) If all checks pass, Bob builds a circuit to the provided
396 rendezvous point and otherwise drops the cell.
398 1.4. Summary of authorization data fields
400 In summary, the proposed descriptor format and cell formats provide the
401 following fields for carrying authorization data:
403 (1) The v2 hidden service descriptor contains:
404 - a descriptor cookie that is used for the lookup process, and
405 - an arbitrary encryption schema to ensure authorization to access
406 introduction information (currently symmetric encryption with the
409 (2) For performing authorization at the introduction point we can use:
410 - the fields intro-authorization and service-authorization in
411 hidden service descriptors,
412 - a maximum of 215 octets in the ESTABLISH_INTRO cell, and
413 - one part of 110 octets in the INTRODUCE1V cell.
415 (3) For performing authorization at the hidden service we can use:
416 - the fields intro-authorization and service-authorization in
417 hidden service descriptors,
418 - the other part of 110 octets in the INTRODUCE2 cell.
420 It will also still be possible to access a hidden service without any
421 authorization or only use a part of the authorization infrastructure.
422 However, this requires to consider all parts of the infrastructure. For
423 example, authorization at the introduction point relying on confidential
424 intro-authorization data transported in the hidden service descriptor
425 cannot be performed without using an encryption schema for introduction
428 1.5. Managing authorization data at servers and clients
430 In order to provide authorization data at the hidden server and the
431 authenticated clients, we propose to use files---either the tor
432 configuration file or separate files. The exact format of these special
433 files depends on the authorization protocol used.
435 Currently, rend-spec contains the proposition to encode client-side
436 authorization data in the URL, like in x.y.z.onion. This was never used
437 and is also a bad idea, because in case of HTTP the requested URL may be
438 contained in the Host and Referer fields.
440 1.6. Limitations for authorization protocols
442 There are two limitations of the current hidden service protocol for
443 authorization protocols that shall be identified here.
445 1. The three cell types ESTABLISH_INTRO, INTRODUCE1V, and INTRODUCE2
446 restricts the amount of data that can be used for authorization.
447 This forces authorization protocols that require per-user
448 authorization data at the introduction point to restrict the number
449 of authorized clients artifically. A possible solution could be to
450 split contents among multiple cells and reassemble them at the
453 2. The current hidden service protocol does not specify cell types to
454 perform interactive authorization between client and introduction
455 point or hidden service. If there should be an authorization
456 protocol that requires interaction, new cell types would have to be
457 defined and integrated into the hidden service protocol.
460 2. Specific authorization protocol instances
462 In the following we present three specific authorization protocols that
463 make use of (parts of) the new authorization infrastructure:
465 1. The first protocol does not really perform client authorization, but
466 requires clients to have downloaded a service descriptor before
467 establishing a connection in order to prevent introduction points
468 from accessing a service.
470 2. The second protocol allows a service provider to restrict access
471 to clients with a previously received secret key only, but does not
472 attempt to hide service activity from others.
474 3. The third protocol, albeit being feasible for a limited set of about
475 16 clients, performs client authorization and hides service activity
476 from everyone but the authorized clients.
478 These three protocol instances together are intended to replace the
479 existing hidden service protocol versions 0 and 2 in the long run and
480 shall therefore be considered hidden service protocol version 3. All
481 changes in this version 3 are designed to be fully backward-compatible to
482 version 2 and can be run in parallel to version 0.
484 2.1. Services without client authorization
486 Although hidden services without client authorization could be run as
487 before, this proposal allows us to add a new security property at almost
488 no costs: Denying the introduction points to access the hidden service.
489 While this constitutes a defense against rogue introduction points, it
490 also reduces responsibility of a Tor node operator for the doings of a
491 hidden service offering illegal or unethical contents.
493 The original hidden service design used the service's permanent key to
494 establish introduction points. If an introduction point wanted to access
495 the service, it could easily download the service's descriptor using its
496 permanent key ID and establish a connection or generate an INTRODUCE2
497 cell itself and forward it directly to the service.
499 Hidden service protocol version 2 made it more difficult for introduction
500 points to find out which service they are serving. Here, the hidden
501 service created a fresh introduction key for each introduction point
502 which 1) did not reveal the hidden service's identity and 2) did not
503 allow downloading the service's descriptor. However, the introduction
504 point could still generate an INTRODUCE2 cell itself and establish a
505 connection to the service to find out what it is serving.
507 Beginning with this proposal can include a so-called "introduction
508 cookie" in v2 hidden service descriptors and v3 INTRODUCE2 cells. If
509 both, service and client implement this proposal, a service receiving a
510 v3 INTRODUCE2 cell with an introduction cookie in it can be sure that the
511 client has downloaded its descriptor before. As long as hidden services
512 also permit v2 INTRODUCE2 cells, introduction points can work around this
513 safeguard. But the earlier this protocol is introduced, the earlier the
514 services can stop supporting version 2 introductions.
516 A hidden service generates a unique introduction cookie for each
517 established introduction point and puts it in the "intro-authentication"
518 field in its descriptor for auth-type "1". Further, the service sets the
519 "protocol-versions" field to "2,3" to announce that it understands both,
520 requests with and without introduction cookie. Clients that understand
521 protocol version 3 include the introduction cookie in the v3 INTRODUCE2
522 cell as auth-type "1" that they send to the service. (Clients that don't
523 understand the protocol v3 do not recognize the authorization data and
524 send a v2 INTRODUCE2 cell as usual.) The hidden service can compare a
525 received introduction cookie with the value that it expects and grant or
526 deny service correspondingly.
528 2.2. Service with large-scale client authorization
530 The first client authorization protocol aims at performing access control
531 while consuming as little additional resources as possible. A service
532 provider should be able to permit access to a large number of clients
533 while denying access for everyone else. However, the price for
534 scalability is that the service won't be able to hide its activity from
535 unauthorized or formerly authorized clients.
537 The main idea of this protocol is to encrypt the introduction-point part
538 in hidden service descriptors to authorized clients using symmetric keys.
539 This ensures that nobody else but authorized clients can learn which
540 introduction points a service currently uses, nor can someone send a
541 valid INTRODUCE1 message without knowing the introduction key. Therefore,
542 a subsequent authorization at the introduction point is not required.
544 A service provider generates symmetric "descriptor cookies" for his
545 clients and distributes them outside of Tor. The suggested key size is
546 128 bits, so that descriptor cookies can be encoded in 22 base64 chars
547 (which can hold up to 22 * 5 = 132 bits, leaving 4 bits to encode the
548 authorization type "2" and allow a client to distinguish this
549 authorization protocol from others like the one proposed below).
550 Typically, the contact information for a hidden service using this
551 authorization protocol looks like this:
553 v2cbb2l4lsnpio4q.onion Ll3X7Xgz9eHGKCCnlFH0uz
555 When generating a hidden service descriptor, the service encrypts the
556 introduction-point part with a single randomly generated symmetric
557 128-bit session key using AES-CTR as described for v2 hidden service
558 descriptors in rend-spec. Afterwards, the service encrypts the session
559 key to all descriptor cookies using AES.
561 ### What would be a simple solution to include n encrypted session keys
562 ### in the descriptor? The format may be binary and has no strict upper
563 ### size limit. An authorized client should be able to efficiently find
564 ### the session key that is encrypted for him/her. It should be
565 ### impossible to track certain authorized clients over time by finding
566 ### that the session key was encrypted for them in different descriptors.
567 ### It should be hard to determine the exact number of authorized
570 ### Here comes the voodoo I've conceived:
572 ### ATYPE Authorization type: set to 2. [1 octet]
573 ### ALEN Number of authorized clients div 16 [1 octet]
574 ### for each symmetric descriptor cookie:
575 ### ID Client ID: H(descriptor cookie | IV)[:4] [4 octets]
576 ### SKEY Session key encrypted with descriptor cookie [16 octets]
577 ### (end of client-specific part)
578 ### RND Random data [(16 - (number-of-clients mod 16)) * 20 octets]
579 ### IV AES initialization vector [16 octets]
580 ### IPOS Intro points, encrypted with session key [remaining octets]
582 An authorized client needs to configure Tor to use the descriptor cookie
583 when accessing the hidden service. Therefore, a user adds the contact
584 information that she received from the service provider to her torrc
585 file. Upon downloading a hidden service descriptor, Tor finds the
586 encrypted introduction-point part and attempts to decrypt it using the
587 configured descriptor cookie. (In the rare event of two or more client
588 IDs being equal a client tries to decrypt all of them.)
590 Upon sending the introduction, the client includes her descriptor cookie
591 as auth type "2" in the INTRODUCE2 cell that she sends to the service.
592 The hidden service checks whether the included descriptor cookie is
593 authorized to access the service and either responds to the introduction
596 2.3. Authorization for limited number of clients
598 A second, more sophisticated client authorization protocol goes the extra
599 mile of hiding service activity from unauthorized clients. With all else
600 being equal to the preceding authorization protocol, the second protocol
601 publishes hidden service descriptors for each user separately and gets
602 along with encrypting the introduction-point part of descriptors to a
603 single client. This allows the service to stop publishing descriptors for
604 removed clients. As long as a removed client cannot link descriptors
605 issued for other clients to the service, it cannot derive service
606 activity any more. The downside of this approach is limited scalability.
607 Even though the distributed storage of descriptors (cf. proposal 114)
608 tackles the problem of limited scalability to a certain extent, this
609 protocol should not be used for services with more than 16 clients. (In
610 fact, Tor should refuse to advertise services for more than this number
613 A hidden service generates an asymmetric "client key" and a symmetric
614 "descriptor cookie" for each client. The client key is used as
615 replacement for the service's permanent key, so that the service uses a
616 different identity for each of his clients. The descriptor cookie is used
617 to store descriptors at changing directory nodes that are unpredictable
618 for anyone but service and client, to encrypt the introduction-point
619 part, and to be included in INTRODUCE2 cells. Once the service has
620 created client key and descriptor cookie, he tells them to the client
621 outside of Tor. The contact information string looks similar to the one
622 used by the preceding authorization protocol (with the only difference
623 that it has "3" encoded as auth-type in the remaining 4 of 132 bits
624 instead of "2" as before).
626 When creating a hidden service descriptor for an authorized client, the
627 hidden service uses the client key and descriptor cookie to compute
628 secret ID part and descriptor ID:
630 secret-id-part = H(time-period | descriptor-cookie | replica)
632 descriptor-id = H(client-key[:10] | secret-id-part)
634 The hidden service also replaces permanent-key in the descriptor with
635 client-key and encrypts introduction-points with the descriptor cookie.
637 ATYPE Authorization type: set to 3. [1 octet]
638 IV AES initialization vector [16 octets]
639 IPOS Intro points, encr. with descriptor cookie [remaining octets]
641 When uploading descriptors, the hidden service needs to make sure that
642 descriptors for different clients are not uploaded at the same time (cf.
643 Section 1.1) which is also a limiting factor for the number of clients.
645 When a client is requested to establish a connection to a hidden service
646 it looks up whether it has any authorization data configured for that
647 service. If the user has configured authorization data for authorization
648 protocol "3", the descriptor ID is determined as described in the last
649 paragraph. Upon receiving a descriptor, the client decrypts the
650 introduction-point part using its descriptor cookie. Further, the client
651 includes its descriptor cookie as auth-type "3" in INTRODUCE2 cells that
652 it sends to the service.
654 2.4. Hidden service configuration
656 A hidden service that implements this proposal and that is meant to use
657 the new protocols (including the protocol without client authorization as
658 described in 2.1) adds version 3 to the list of supported hidden service
661 HiddenServiceVersion version,version,... (Default: 0, 2, 3)
663 If the service shall perform client authorization, another config option
664 is set to either "1" for the protocol described in 2.2 or "2" for the
665 protocol in 2.3 (auth type numbers differ from the internally used
666 numbers primarily to avoid user questions about the whereabouts of auth
667 type 1). This config option also includes a comma-separated list of
668 human-readable client names, so that Tor can create authorization data
671 HiddenServiceAuthorizeClient auth-type client-name,client-name,...
673 If this option is configured, HiddenServiceVersion is automatically
674 reconfigured to contain only version numbers of 3 or higher. If this
675 config option is not set but the configured hidden service version
676 includes 3, the protocol without client authorization as described in 2.1
677 is offered to clients (possibly in parallel to versions 0 and 2).
679 Tor stores all generated authorization data for the authorization
680 protocols described in Sections 2.2 and 2.3 in a new file using the
681 following file format:
683 "client-name" human-readable client identifier NL
684 "descriptor-cookie" 128-bit key ^= 22 base64 chars NL
686 If the authorization protocol of Section 2.3 is used, Tor also generates
687 and stores the following data:
689 "service-address" client-specific-onion-address NL
690 "client-key" NL a public key in PEM format
692 2.5. Client configuration
694 Clients need to make their authorization data known to Tor using another
695 configuration option that contains a service name (mainly for the sake of
696 convenience), the service address, and the descriptor cookie that is
697 required to access a hidden service (the authorization protocol number is
698 encoded in the descriptor cookie):
700 HidServAuth service-name service-address descriptor-cookie
702 Security implications:
704 In the following we want to discuss possible attacks by dishonest
705 entities in the presented infrastructure and specific protocol. These
706 security implications would have to be verified once more when adding
707 another protocol. The dishonest entities (theoretically) include the
708 hidden server itself, the authenticated clients, hidden service directory
709 nodes, introduction points, and rendezvous points. The relays that are
710 part of circuits used during protocol execution, but never learn about
711 the exchanged descriptors or cells by design, are not considered.
712 Obviously, this list makes no claim to be complete. The discussed attacks
713 are sorted by the difficulty to perform them, in ascending order,
714 starting with roles that everyone could attempt to take and ending with
715 partially trusted entities abusing the trust put in them.
717 (1) A hidden service directory could attempt to conclude presence of a
718 server from the existence of a locally stored hidden service descriptor:
719 This passive attack is possible only for a single client-service
720 relation, because descriptors need to contain a
721 publicly visible signature of the server using the client key
722 A possible protection
723 would be to increase the number of hidden service directories in the
726 (2) A hidden service directory could try to break the descriptor cookies
727 of locally stored descriptors: This attack can be performed offline. The
728 only useful countermeasure against it might be using safe passwords that
729 are generated by Tor.
731 (3) An introduction point could try to identify the pseudonym of the
732 hidden service on behalf of which it operates: This is impossible by
733 design, because the service uses a fresh public key for every
734 establishment of an introduction point (see proposal 114) and the
735 introduction point receives a fresh introduction cookie, so that there is
736 no identifiable information about the service that the introduction point
737 could learn. The introduction point cannot even tell if client accesses
738 belong to the same client or not, nor can it know the total number of
739 authorized clients. The only information might be the pattern of
740 anonymous client accesses, but that is hardly enough to reliably identify
743 (4) An introduction point could want to learn the identities of accessing
744 clients: This is also impossible by design, because all clients use the
745 same introduction cookie for authorization at the introduction point.
747 (5) An introduction point could try to replay a correct INTRODUCE1 cell
748 to other introduction points of the same service, e.g. in order to force
749 the service to create a huge number of useless circuits: This attack is
750 not possible by design, because INTRODUCE1 cells are encrypted using a
751 freshly created introduction key that is only known to authorized
754 (6) An introduction point could attempt to replay a correct INTRODUCE2
755 cell to the hidden service, e.g. for the same reason as in the last
756 attack: This attack is very limited by the fact that a server will only
757 accept 3 INTRODUCE2 cells containing the same rendezvous cookie and drop
758 all further replayed cells.
760 (7) An introduction point could block client requests by sending either
761 positive or negative INTRODUCE_ACK cells back to the client, but without
762 forwarding INTRODUCE2 cells to the server: This attack is an annoyance
763 for clients, because they might wait for a timeout to elapse until trying
764 another introduction point. However, this attack is not introduced by
765 performing authorization and it cannot be targeted towards a specific
766 client. A countermeasure might be for the server to periodically perform
767 introduction requests to his own service to see if introduction points
768 are working correctly.
770 (8) The rendezvous point could attempt to identify either server or
771 client: This remains impossible as it was before, because the
772 rendezvous cookie does not contain any identifiable information.
774 (9) An authenticated client could swamp the server with valid INTRODUCE1
775 and INTRODUCE2 cells, e.g. in order to force the service to create
776 useless circuits to rendezvous points; as opposed to an introduction
777 point replaying the same INTRODUCE2 cell, a client could include a new
778 rendezvous cookie for every request: The countermeasure for this attack
779 is the restriction to 10 connection establishments per client and hour.
783 An implementation of this proposal would require changes to hidden
784 servers and clients to process authorization data and encode and
785 understand the new formats. However, both servers and clients would
786 remain compatible to regular hidden services without authorization.
790 The implementation of this proposal can be divided into a number of
791 changes to hidden service and client side. There are no
792 changes necessary on directory, introduction, or rendezvous nodes. All
793 changes are marked with either [service] or [client] do denote on which
794 side they need to be made.
796 /1/ Configure client authorization [service]
798 - Parse configuration option HiddenServiceAuthorizeClient containing
799 authorized client names.
800 - Load previously created client keys and descriptor cookies.
801 - Generate missing client keys and descriptor cookies, add them to
803 - Rewrite the hostname file.
804 - Keep client keys and descriptor cookies of authorized clients in
806 [- In case of reconfiguration, mark which client authorizations were
807 added and whether any were removed. This can be used later when
808 deciding whether to rebuild introduction points and publish new
809 hidden service descriptors. Not implemented yet.]
811 /2/ Publish hidden service descriptors [service]
813 - Create and upload hidden service descriptors for all authorized
815 [- See /1/ for the case of reconfiguration.]
817 /3/ Configure permission for hidden services [client]
819 - Parse configuration option HidServAuth containing service
820 authorization, store authorization data in memory.
822 /5/ Fetch hidden service descriptors [client]
824 - Look up client authorization upon receiving a hidden service request.
825 - Request hidden service descriptor ID including client key and
826 descriptor cookie. Only request v2 descriptors, no v0.
828 /6/ Process hidden service descriptor [client]
830 - Decrypt introduction points with descriptor cookie.
832 /7/ Create introduction request [client]
834 - Include descriptor cookie in INTRODUCE2 cell to introduction point.
835 - Pass descriptor cookie around between involved connections and
838 /8/ Process introduction request [service]
840 - Read descriptor cookie from INTRODUCE2 cell.
841 - Check whether descriptor cookie is authorized for access, including
842 checking access counters.
843 - Log access for accountability.