121-hidden-service-authentication.txt 34 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650
  1. Filename: 121-hidden-service-authentication.txt
  2. Title: Hidden Service Authentication
  3. Version: $LastChangedRevision$
  4. Last-Modified: $LastChangedDate$
  5. Author: Tobias Kamm, Thomas Lauterbach, Karsten Loesing, Ferdinand Rieger,
  6. Christoph Weingarten
  7. Created: 10-Sep-2007
  8. Status: Open
  9. Change history:
  10. 26-Sep-2007 Initial proposal for or-dev
  11. 08-Dec-2007 Incorporated comments by Nick posted to or-dev on 10-Oct-2007
  12. 15-Dec-2007 Rewrote complete proposal for better readability, modified
  13. authentication protocol, merged in personal notes
  14. 24-Dec-2007 Replaced misleading term "authentication" by "authorization"
  15. and added some clarifications (comments by Sven Kaffille)
  16. Overview:
  17. This proposal deals with a general infrastructure for performing
  18. authorization (not necessarily implying authentication) of requests to
  19. hidden services at three points: (1) when downloading and decrypting
  20. parts of the hidden service descriptor, (2) at the introduction point,
  21. and (3) at Bob's onion proxy before contacting the rendezvous point. A
  22. service provider will be able to restrict access to his service at these
  23. three points to authorized clients only. Further, the proposal contains a
  24. first instance of an authorization protocol for the presented
  25. infrastructure.
  26. This proposal is based on v2 hidden service descriptors as described in
  27. proposal 114 and introduced in version 0.2.0.10-alpha.
  28. The proposal is structured as follows: The next section motivates the
  29. integration of authorization mechanisms in the hidden service protocol.
  30. Then we describe a general infrastructure for authorization in hidden
  31. services, followed by a specific authorization protocol for this
  32. infrastructure. At the end we discuss a number of attacks and non-attacks
  33. as well as compatibility issues.
  34. Motivation:
  35. The major part of hidden services does not require client authorization
  36. now and won't do so in the future. To the contrary, many clients would
  37. not want to be (pseudonymously) identifiable by the service (though this
  38. is unavoidable to some extent), but rather use the service
  39. anonymously. These services are not addressed by this proposal.
  40. However, there may be certain services which are intended to be accessed
  41. by a limited set of clients only. A possible application might be a
  42. wiki or forum that should only be accessible for a closed user group.
  43. Another, less intuitive example might be a real-time communication
  44. service, where someone provides a presence and messaging service only to
  45. his buddies. Finally, a possible application would be a personal home
  46. server that should be remotely accessed by its owner.
  47. Performing authorization for a hidden service within the Tor network, as
  48. proposed here, offers a range of advantages compared to allowing all
  49. client connections in the first instance and deferring authorization to
  50. the transported protocol:
  51. (1) Reduced traffic: Unauthorized requests would be rejected as early as
  52. possible, thereby reducing the overall traffic in the network generated
  53. by establishing circuits and sending cells.
  54. (2) Better protection of service location: Unauthorized clients could not
  55. force Bob to create circuits to their rendezvous points, thus preventing
  56. the attack described by Øverlier and Syverson in their paper "Locating
  57. Hidden Servers" even without the need for guards.
  58. (3) Hiding activity: Apart from performing the actual authorization, a
  59. service provider could also hide the mere presence of his service from
  60. unauthorized clients when not providing hidden service descriptors to
  61. them and rejecting unauthorized requests already at the introduction
  62. point (ideally without leaking presence information at any of these
  63. points).
  64. (4) Better protection of introduction points: When providing hidden
  65. service descriptors to authorized clients only and encrypting the
  66. introduction points as described in proposal 114, the introduction points
  67. would be unknown to unauthorized clients and thereby protected from DoS
  68. attacks.
  69. (5) Protocol independence: Authorization could be performed for all
  70. transported protocols, regardless of their own capabilities to do so.
  71. (6) Ease of administration: A service provider running multiple hidden
  72. services would be able to configure access at a single place uniformly
  73. instead of doing so for all services separately.
  74. (7) Optional QoS support: Bob could adapt his node selection algorithm
  75. for building the circuit to Alice's rendezvous point depending on a
  76. previously guaranteed QoS level, thus providing better latency or
  77. bandwidth for selected clients.
  78. A disadvantage of performing authorization within the Tor network is
  79. that a hidden service cannot make use of authorization data in
  80. the transported protocol. Tor hidden services were designed to be
  81. independent of the transported protocol. Therefore it's only possible to
  82. either grant or deny access to the whole service, but not to specific
  83. resources of the service.
  84. Authorization often implies authentication, i.e. proving one's identity.
  85. However, when performing authorization within the Tor network, untrusted
  86. points should not gain any useful information about the identities of
  87. communicating parties, neither server nor client. A crucial challenge is
  88. to remain anonymous towards directory servers and introduction points.
  89. However, trying to hide identity from the hidden service is a futile
  90. task, because a client would never know if he is the only authorized
  91. client and therefore perfectly identifiable. Therefore, hiding identity
  92. from the hidden service is not aimed by this proposal.
  93. The current implementation of hidden services does not provide any kind
  94. of authorization. The hidden service descriptor version 2, introduced by
  95. proposal 114, was designed to use a descriptor cookie for downloading and
  96. decrypting parts of the descriptor content, but this feature is not yet
  97. in use. Further, most relevant cell formats specified in rend-spec
  98. contain fields for authorization data, but those fields are neither
  99. implemented nor do they suffice entirely.
  100. Details:
  101. 1. General infrastructure for authorization to hidden services
  102. We spotted three possible authorization points in the hidden service
  103. protocol:
  104. (1) when downloading and decrypting parts of the hidden service
  105. descriptor,
  106. (2) at the introduction point, and
  107. (3) at Bob's onion proxy before contacting the rendezvous point.
  108. The general idea of this proposal is to allow service providers to
  109. restrict access to all of these points to authorized clients only.
  110. 1.1. Client authorization at directory
  111. Since the implementation of proposal 114 it is possible to combine a
  112. hidden service descriptor with a so-called descriptor cookie. If done so,
  113. the descriptor cookie becomes part of the descriptor ID, thus having an
  114. effect on the storage location of the descriptor. Someone who has learned
  115. about a service, but is not aware of the descriptor cookie, won't be able
  116. to determine the descriptor ID and download the current hidden service
  117. descriptor; he won't even know whether the service has uploaded a
  118. descriptor recently. Descriptor IDs are calculated as follows (see
  119. section 1.2 of rend-spec for the complete specification of v2 hidden
  120. service descriptors):
  121. descriptor-id =
  122. H(permanent-id | H(time-period | descriptor-cookie | replica))
  123. The second purpose of the descriptor cookie is to encrypt the list of
  124. introduction points, including optional authorization data. Hence, the
  125. hidden service directories won't learn any introduction information from
  126. storing a hidden service descriptor. This feature is implemented but
  127. unused at the moment, so that this proposal will harness the advantages
  128. of proposal 114.
  129. The descriptor cookie can be used for authorization by keeping it secret
  130. from everyone but authorized clients. A service could then decide whether
  131. to publish hidden service descriptors using that descriptor cookie later
  132. on. An authorized client being aware of the descriptor cookie would be
  133. able to download and decrypt the hidden service descriptor.
  134. The number of concurrently used descriptor cookies for one hidden service
  135. is not restricted. A service could use a single descriptor cookie for all
  136. users, a distinct cookie per user, or something in between, like one
  137. cookie per group of users. It is up to the specific protocol and how it
  138. is applied by a service provider. However, we advise to use a small
  139. number of descriptor cookies for efficiency reasons and for improving the
  140. ability to hide presence of a service (see security implications at the
  141. end of this document).
  142. Although this part of the proposal is meant to describe a general
  143. infrastructure for authorization, changing the way of using the
  144. descriptor cookie to look up hidden service descriptors, e.g. applying
  145. some sort of asymmetric crypto system, would require in-depth changes
  146. that would be incompatible to v2 hidden service descriptors. On the
  147. contrary, using another key for en-/decrypting the introduction point
  148. part of a hidden service descriptor, e.g. a different symmetric key or
  149. asymmetric encryption, would be easy to implement and compatible to v2
  150. hidden service descriptors as understood by hidden service directories
  151. (clients and servers would have to be upgraded anyway for using the new
  152. features).
  153. 1.2. Client authorization at introduction point
  154. The next possible authorization point after downloading and decrypting
  155. a hidden service descriptor is the introduction point. It is important
  156. for authorization, because it bears the last chance of hiding presence
  157. of a hidden service from unauthorized clients. Further, performing
  158. authorization at the introduction point might reduce traffic in the
  159. network, because unauthorized requests would not be passed to the
  160. hidden service. This applies to those clients who are aware of a
  161. descriptor cookie and thereby of the hidden service descriptor, but do
  162. not have authorization data to pass the introduction point or access the
  163. service (such a situation might occur when authorization data for
  164. authorization at the directory is not issued on a per-user base as
  165. opposed to authorization data for authorization at the introduction
  166. point).
  167. It is important to note that the introduction point must be considered
  168. untrustworthy, and therefore cannot replace authorization at the hidden
  169. service itself. Nor should the introduction point learn any sensitive
  170. identifiable information from either server or client.
  171. In order to perform authorization at the introduction point, three
  172. message formats need to be modified: (1) v2 hidden service descriptors,
  173. (2) ESTABLISH_INTRO cells, and (3) INTRODUCE1 cells.
  174. A v2 hidden service descriptor needs to contain authorization data that
  175. is introduction-point-specific and sometimes also authorization data
  176. that is introduction-point-independent. Therefore, v2 hidden service
  177. descriptors as specified in section 1.2 of rend-spec already contain two
  178. reserved fields "intro-authorization" and "service-authorization"
  179. (originally, the names of these fields were "...-authentication")
  180. containing an authorization type number and arbitrary authorization
  181. data. We propose that authorization data consists of base64 encoded
  182. objects of arbitrary length, surrounded by "-----BEGIN MESSAGE-----" and
  183. "-----END MESSAGE-----". This will increase the size of hidden service
  184. descriptors, which however is possible, as there is no strict upper
  185. limit.
  186. The current ESTABLISH_INTRO cells as described in section 1.3 of
  187. rend-spec don't contain either authorization data or version
  188. information. Therefore, we propose a new version 1 of the ESTABLISH_INTRO
  189. cells adding these two issues as follows:
  190. V Format byte: set to 255 [1 octet]
  191. V Version byte: set to 1 [1 octet]
  192. KL Key length [2 octets]
  193. PK Bob's public key [KL octets]
  194. HS Hash of session info [20 octets]
  195. AUTHT The auth type that is supported [1 octet]
  196. AUTHL Length of auth data [2 octets]
  197. AUTHD Auth data [variable]
  198. SIG Signature of above information [variable]
  199. From the format it is possible to determine the maximum allowed size for
  200. authorization data: given the fact that cells are 512 octets long, of
  201. which 498 octets are usable (see section 6.1 of tor-spec), and assuming
  202. 1024 bit = 128 octet long keys, there are 215 octets left for
  203. authorization data. Hence, authorization protocols are bound to use no
  204. more than these 215 octets, regardless of the number of clients that
  205. shall be authenticated at the introduction point. Otherwise, one would
  206. need to send multiple ESTABLISH_INTRO cells or split them up, what we do
  207. not specify here.
  208. In order to understand a v1 ESTABLISH_INTRO cell, the implementation of
  209. a relay must have a certain Tor version, which would probably be some
  210. 0.2.1.x. Hidden services need to be able to distinguish relays being
  211. capable of understanding the new v1 cell formats and perform
  212. authorization. We propose to use the version number that is contained in
  213. networkstatus documents to find capable introduction points.
  214. The current INTRODUCE1 cells as described in section 1.8 of rend-spec is
  215. not designed to carry authorization data and has no version number, too.
  216. We propose the following version 1 of INTRODUCE1 cells:
  217. Cleartext
  218. V Version byte: set to 1 [1 octet]
  219. PK_ID Identifier for Bob's PK [20 octets]
  220. AUTHT The auth type that is supported [1 octet]
  221. AUTHL Length of auth data [2 octets]
  222. AUTHD Auth data [variable]
  223. Encrypted to Bob's PK:
  224. (RELAY_INTRODUCE2 cell)
  225. The maximum length of contained authorization data depends on the length
  226. of the contained INTRODUCE2 cell. A calculation follows below when
  227. describing the INTRODUCE2 cell format we propose to use.
  228. Unfortunately, v0 INTRODUCE1 cells consist only of a fixed-size,
  229. seemingly random PK_ID, followed by the encrypted INTRODUCE2 cell. This
  230. makes it impossible to distinguish v0 INTRODUCE1 cells from any later
  231. format. In particular, it is not possible to introduce some kind of
  232. format and version byte for newer versions of this cell. That's probably
  233. where the comment "[XXX011 want to put intro-level auth info here, but no
  234. version. crap. -RD]" that was part of rend-spec some time ago comes from.
  235. Processing of v1 INTRODUCE1 cells therefore requires knowledge about the
  236. context in which they are used. As a result, we propose that when
  237. receiving a v1 ESTABLISH_INTRO cell, an introduction point only accepts
  238. v1 INTRODUCE1 cells later on. Hence, the same introduction point cannot
  239. be used to accept both v0 and v1 INTRODUCE1 cells for the same service.
  240. (Another solution would be to distinguish v0 and v1 INTRODUCE1 cells by
  241. their size, as v0 INTRODUCE1 cells can only have specific cell sizes,
  242. depending on the version of the contained INTRODUCE2 cell; however, this
  243. approach does not appear very clean.)
  244. 1.3. Client authorization at hidden service
  245. The time when a hidden service receives an INTRODUCE2 cell constitutes
  246. the last possible authorization point during the hidden service
  247. protocol. Performing authorization here is easier than at the other two
  248. authorization points, because there are no possibly untrusted entities
  249. involved.
  250. In general, a client that is successfully authorized at the introduction
  251. point should be granted access at the hidden service, too. Otherwise, the
  252. client would receive a positive INTRODUCE_ACK cell from the introduction
  253. point and conclude that it may connect to the service, but the request
  254. will be dropped without notice. This would appear as a failure to
  255. clients. Therefore, the number of cases in which a client successfully
  256. passes the introduction point, but fails at the hidden service should be
  257. zero. However, this does not lead to the conclusion, that the
  258. authorization data used at the introduction point and the hidden service
  259. must be the same, but only that both authorization data should lead to
  260. the same authorization result.
  261. Authorization data is transmitted from client to server via an
  262. INTRODUCE2 cell that is forwarded by the introduction point. There are
  263. versions 0 to 2 specified in section 1.8 of rend-spec, but none of these
  264. contains fields for carrying authorization data. We propose a slightly
  265. modified version of v3 INTRODUCE2 cells that is specified in section
  266. 1.8.1 and which is not implemented as of December 2007. The only change
  267. is to switch the lengths of AUTHT and AUTHL, which we assume to be a typo
  268. in current rend-spec. The proposed format of v3 INTRODUCE2 cells is as
  269. follows:
  270. VER Version byte: set to 3. [1 octet]
  271. ATYPE An address type (typically 4) [1 octet]
  272. ADDR Rendezvous point's IP address [4 or 16 octets]
  273. PORT Rendezvous point's OR port [2 octets]
  274. AUTHT The auth type that is supported [1 octet]
  275. AUTHL Length of auth data [2 octets]
  276. AUTHD Auth data [variable]
  277. ID Rendezvous point identity ID [20 octets]
  278. KLEN Length of onion key [2 octets]
  279. KEY Rendezvous point onion key [KLEN octets]
  280. RC Rendezvous cookie [20 octets]
  281. g^x Diffie-Hellman data, part 1 [128 octets]
  282. The maximum possible length of authorization data is related to the
  283. enclosing INTRODUCE1 cell. A v3 INTRODUCE2 cell with IPv6 address and
  284. 1024 bit = 128 octets long public keys without any authorization data
  285. occupies 321 octets, plus 58 octets for hybrid public key encryption (see
  286. section 5.1 of tor-spec on hybrid encryption of CREATE cells). The
  287. surrounding v1 INTRODUCE1 cell requires 24 octets. This leaves only 95
  288. of the 498 available octets free, which must be shared between
  289. authorization data to the introduction point _and_ to the hidden
  290. service.
  291. When receiving a v3 INTRODUCE2 cell, Bob checks whether a client has
  292. provided valid authorization data to him. He will only then build a
  293. circuit to the provided rendezvous point and otherwise will drop the
  294. cell.
  295. There might be several attacks based on the idea of replaying existing
  296. cells to the hidden service. In particular, someone (the introduction
  297. point or an evil authenticated client) might replay valid INTRODUCE2
  298. cells to make the hidden service build an arbitrary number of circuits to
  299. (maybe long gone) rendezvous points. Therefore, we propose that hidden
  300. services maintain a history of received INTRODUCE2 cells within the last
  301. hour and only accept INTRODUCE2 cells matching the following rules:
  302. (1) a maximum of 3 cells coming from the same client and containing the
  303. same rendezvous cookie, and
  304. (2) a maximum of 10 cells coming from the same client with different
  305. rendezvous cookies.
  306. This allows a client to retry connection establishment using the same
  307. rendezvous point for 3 times and a total number of 10 connection
  308. establishments (not requests in the transported protocol) per hour.
  309. 1.4. Summary of authorization data fields
  310. In summary, the proposed descriptor format and cell formats provide the
  311. following fields for carrying authorization data:
  312. (1) The v2 hidden service descriptor contains:
  313. - a descriptor cookie that is used for the lookup process, and
  314. - an arbitrary encryption schema to ensure authorization to access
  315. introduction information (currently symmetric encryption with the
  316. descriptor cookie).
  317. (2) For performing authorization at the introduction point we can use:
  318. - the fields intro-authorization and service-authorization in
  319. hidden service descriptors,
  320. - a maximum of 215 octets in the ESTABLISH_INTRO cell, and
  321. - one part of 95 octets in the INTRODUCE1 cell.
  322. (3) For performing authorization at the hidden service we can use:
  323. - the fields intro-authorization and service-authorization in
  324. hidden service descriptors,
  325. - the other part of 95 octets in the INTRODUCE2 cell.
  326. It will also still be possible to access a hidden service without any
  327. authorization or only use a part of the authorization infrastructure.
  328. However, this requires to consider all parts of the infrastructure. For
  329. example, authorization at the introduction point relying on confidential
  330. intro-authorization data transported in the hidden service descriptor
  331. cannot be performed without using an encryption schema for introduction
  332. information.
  333. 1.5. Managing authorization data at servers and clients
  334. In order to provide authorization data at the hidden server and the
  335. authenticated clients, we propose to use files---either the tor
  336. configuration file or separate files. In the latter case a hidden server
  337. would use one file per provided service, and a client would use one file
  338. per server she wants to access. The exact format of these special files
  339. depends on the authorization protocol used.
  340. Currently, rend-spec contains the proposition to encode client-side
  341. authorization data in the URL, like in x.y.z.onion. This was never used
  342. and is also a bad idea, because in case of HTTP the requested URL may be
  343. contained in the Host and Referer fields.
  344. 2. An authorization protocol based on group and user passwords
  345. In the following we discuss an authorization protocol for the proposed
  346. authorization architecture that performs authorization at all three
  347. proposed authorization points. The protocol relies on two symmetrically
  348. shared keys: a group key and a user key. The reason for this separation
  349. as compared to using a single key for each user is the fact that the
  350. number of descriptor cookies should be limited, so that the group key
  351. will be used for authenticating at the directory, whereas two keys
  352. derived from the user key will be used for performing authorization at
  353. the introduction and the hidden service.
  354. 2.1. Client authorization at directory
  355. The server creates groups of users that shall be able to access his
  356. service. He provides all users of a certain group with the same group key
  357. which is a password of arbitrary length.
  358. The group key is used as input to derive a 128 bit descriptor cookie from
  359. it. We propose to apply a secure hash function and use the first 128 bits
  360. of output:
  361. descriptor-cookie = H(group-key)
  362. Hence, there will be a distinct hidden service descriptor for every group
  363. of users. All descriptors contain the same introduction points and the
  364. authorization data required by the users of the given group. Whenever a
  365. server decides to remove authorization for a group, he can simply stop
  366. publishing hidden service descriptors using the descriptor cookie.
  367. 2.2. Client authorization at introduction point
  368. The idea for authenticating at the introduction point is borrowed from
  369. authorization at the rendezvous point using a rendezvous cookie. A
  370. rendezvous cookie is created by the client and encrypted for the server
  371. in order to authenticate the server at the rendezvous point. Likewise,
  372. the so-called introduction cookie is created by the server and encrypted
  373. for the client in order to authenticate the client at the introduction
  374. point.
  375. More precise, the server creates a new introduction cookie when
  376. establishing an introduction point and includes it in the ESTABLISH_INTRO
  377. cell that it sends to the introduction point. This introduction cookie
  378. will be used by all clients during the complete time of using this
  379. introduction point. The server then encrypts the introduction cookie for
  380. all authorized clients (as described in the next paragraph) and includes
  381. it in the introduction-point-specific part of the hidden service
  382. descriptor. A client reads and decrypts the introduction cookie from the
  383. hidden service descriptor and includes it in the INTRODUCE1 cell that it
  384. sends to the introduction point. The introduction point can then compare
  385. the introduction cookie included in the INTRODUCE1 cell with the value
  386. that it previously received in the ESTABLISH_INTRO cell. If both values
  387. match, the introduction point passes the INTRODUCE2 cell to the hidden
  388. service.
  389. For the sake of simplicity, the size of an introduction cookie should be
  390. only 16 bytes so that they can be encrypted using AES-128 without using
  391. a block mode. Although rendezvous cookies are 20 bytes long, the 16 bytes
  392. of an introduction cookie should still provide similar, or at least
  393. sufficient security.
  394. Encryption of the introduction cookie is done on a per user base. Every
  395. client shares a password of arbitrary length with the server, which is
  396. the so-called user key. The server derives a symmetric key from the
  397. client's user key by applying a secure hash function and using the first
  398. 128 bits of output as follows:
  399. encryption-key = H(user-key | "INTRO")
  400. It is important that the encryption key does not allow any inference on
  401. the user key, because the latter will also be used for authorization at
  402. the hidden service. This is ensured by applying the secure one-way
  403. function H.
  404. The 16 bytes long, symmetrically encrypted introduction cookies are
  405. encoded in binary form in the authorization data object of a hidden
  406. service descriptor. Additionally, for every client there is a 20 byte
  407. long client identifier that is also derived from the user key, so that
  408. the client can identify which value to decrypt. The client identifier is
  409. determined as follows:
  410. client-id = H(user-key | "CLIENT")
  411. The authorization data encoded to the hidden service descriptor consists
  412. of the concatenation of pairs consisting of 20 byte client identifiers
  413. and 16 byte encrypted introduction cookies. The authorization type
  414. number for the encrypted introduction cookies as well as for
  415. ESTABLISH_INTRO and INTRODUCE1 cells is "1".
  416. 2.3. Client authorization at hidden service
  417. Authorization at the hidden service also makes use of the user key,
  418. because whoever is authorized to pass the introduction point shall be
  419. authorized to access the hidden service. Therefore, the server and client
  420. derive a common value from the user key, which is called service cookie
  421. and which is 20 bytes long:
  422. service-cookie = H(user-key | "SERVICE")
  423. The client is supposed to include this service cookie, preceded by the 20
  424. bytes long client ID, in INTRODUCE2 cells that it sends to the server.
  425. The server compares authorization data of incoming INTRODUCE2 cells with
  426. the locally stored value that it would expect. The authorization type
  427. number of this protocol for INTRODUCE2 cells is "1".
  428. Passing a derived value of a client's user key will make clients
  429. identifiable to the hidden service. Although there might be ways to limit
  430. identifiability, an authorized client can never be sure that he stays
  431. anonymous to the hidden service. For example, if we created a service
  432. cookie that is the same for all users and encrypted it for all users, and
  433. if we further included a checksum of this service cookie in the
  434. descriptor to prove that all users have the same value, a client would
  435. never know if he is the only valid user contained in this descriptor,
  436. with the other users only be fakes created by the hidden service.
  437. Therefore, we did not make attempts to hide a client's identity from a
  438. hidden service. Another reason was that we would not be able to apply a
  439. connection limit of 10 requests per hour and user that helps prevent some
  440. threats.
  441. 2.4. Providing authorization data
  442. The authorization data that needs to be provided by servers consists of
  443. a number of group keys, each having a number of user keys assigned. These
  444. data items could be provided by two new configuration options
  445. "HiddenServiceAuthGroup group-name group-key" and "HiddenServiceAuthUser
  446. user-name user-key" with the semantics that a group contains all users
  447. directly following the group key definition and before reaching the next
  448. group key definition for a hidden service.
  449. On client side, authorization data also consists of a group and a user
  450. key. Therefore, a new configuration option "HiddenServiceAuthClient
  451. onion-address group-key user-key" could be introduced that could be
  452. written to any place in the configuration file. Whenever the user would
  453. try to access the given onion address, the given group and user key
  454. would be used for authorization.
  455. Security implications:
  456. In the following we want to discuss attacks and non-attacks by dishonest
  457. entities in the presented infrastructure and specific protocol. These
  458. security implications would have to be verified once more when adding
  459. another protocol. The dishonest entities (theoretically) include the
  460. hidden server itself, the authenticated clients, hidden service directory
  461. nodes, introduction points, and rendezvous points. The relays that are
  462. part of circuits used during protocol execution, but never learn about
  463. the exchanged descriptors or cells by design, are not considered.
  464. Obviously, this list makes no claim to be complete. The discussed attacks
  465. are sorted by the difficulty to perform them, in ascending order,
  466. starting with roles that everyone could attempt to take and ending with
  467. partially trusted entities abusing the trust put in them.
  468. (1) A hidden service directory could attempt to conclude presence of a
  469. server from the existence of a locally stored hidden service descriptor:
  470. This passive attack is possible, because descriptors need to contain a
  471. publicly visible signature of the server (see proposal 114 for a more
  472. extensive discussion of the v2 descriptor format). A possible protection
  473. would be to reduce the number of concurrently used descriptor cookies and
  474. increase the number of hidden service directories in the network.
  475. (2) A hidden service directory could try to break the descriptor cookies
  476. of locally stored descriptors: This attack can be performed offline. The
  477. only useful countermeasure against it might be using safe passwords that
  478. are generated by Tor.
  479. (3) An introduction point could try to identify the pseudonym of the
  480. hidden service on behalf of which it operates: This is impossible by
  481. design, because the service uses a fresh public key for every
  482. establishment of an introduction point (see proposal 114) and the
  483. introduction point receives a fresh introduction cookie, so that there is
  484. no identifiable information about the service that the introduction point
  485. could learn. The introduction point cannot even tell if client accesses
  486. belong to the same client or not, nor can it know the total number of
  487. authorized clients. The only information might be the pattern of
  488. anonymous client accesses, but that is hardly enough to reliably identify
  489. a specific server.
  490. (4) An introduction point could want to learn the identities of accessing
  491. clients: This is also impossible by design, because all clients use the
  492. same introduction cookie for authorization at the introduction point.
  493. (5) An introduction point could try to replay a correct INTRODUCE1 cell
  494. to other introduction points of the same service, e.g. in order to force
  495. the service to create a huge number of useless circuits: This attack is
  496. not possible by design, because INTRODUCE1 cells need to contain an
  497. introduction cookie that is different for every introduction point.
  498. (6) An introduction point could attempt to replay a correct INTRODUCE2
  499. cell to the hidden service, e.g. for the same reason as in the last
  500. attack: This attack is very limited by the fact that a server will only
  501. accept 3 INTRODUCE2 cells containing the same rendezvous cookie and drop
  502. all further replayed cells.
  503. (7) An introduction point could block client requests by sending either
  504. positive or negative INTRODUCE_ACK cells back to the client, but without
  505. forwarding INTRODUCE2 cells to the server: This attack is an annoyance
  506. for clients, because they might wait for a timeout to elapse until trying
  507. another introduction point. However, this attack is not introduced by
  508. performing authorization and it cannot be targeted towards a specific
  509. client. A countermeasure might be for the server to periodically perform
  510. introduction requests to his own service to see if introduction points
  511. are working correctly.
  512. (8) The rendezvous point could attempt to identify either server or
  513. client: No, this remains impossible as it was before, because the
  514. rendezvous cookie does not contain any identifiable information.
  515. (9) An authenticated client could try to break the encryption keys of the
  516. other authenticated clients that have their introduction cookies
  517. encrypted in the hidden service descriptor: This known-plaintext attack
  518. can be performed offline. The only useful countermeasure against it could
  519. be safe passwords that are generated by Tor. However, the attack would
  520. not be very useful as long as encryption keys do not reveal information
  521. on the contained user key.
  522. (10) An authenticated client could swamp the server with valid INTRODUCE1
  523. and INTRODUCE2 cells, e.g. in order to force the service to create
  524. useless circuits to rendezvous points; as opposed to an introduction
  525. point replaying the same INTRODUCE2 cell, a client could include a new
  526. rendezvous cookie for every request: The countermeasure for this attack
  527. is the restriction to 10 connection establishments per client and hour.
  528. (11) An authenticated client could attempt to break the service cookie of
  529. another authenticated client to obtain access at the hidden service: This
  530. requires a brute-force online attack. There are no countermeasures
  531. provided, but the question arises whether the outcome of this attack is
  532. worth the cost. The service cookie from one authenticated client is as
  533. good as from another, with the only exception of possible better QoS
  534. properties of certain clients.
  535. Compatibility:
  536. An implementation of this proposal would require changes to hidden
  537. servers and clients to process authorization data and encode and
  538. understand the new formats. However, both servers and clients would
  539. remain compatible to regular hidden services without authorization.
  540. Further, the implementation of introduction points would have to be
  541. changed, so that they understand the new cell versions and perform
  542. authorization. But again, the new introduction points would remain
  543. compatible to the existing hidden service protocol.