[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-dev] Draft of proposal "Stop HS address enumeration by HSDirs"
Greetz,
I'm posting the draft of a proposal that specifies how to hide HS
descriptors and addresses from the hidden service directories.
This proposal is supposed to go along with the proposal that specifies
how to upgrade HS identity keys to use Ed25519. I posted that proposal
some seconds ago.
This proposal (like the other one) is incredibly drafty in the sense
that I might have forgotten to specify things that need to be
specified. On the other hand, "release early; release often" they say,
so here it goes.
Inlining:
Filename: xxx-onion-antienumeration-hsdirs.txt
Title: Stop HS address enumeration by HSDirs
Author: George Kadianakis
Created: 16 August 2013
Target: 0.2.5.x
Status: Draft
[More draft than Guiness.]
0. Proposal overview and motivation:
Currently, it is the case that, HSDirs can read the descriptors of the
Hidden Services they host. Even if the descriptor was encrypted,
HSDirs could still learn the address of the HSes by logging the client
directory requests (which contain the hidden service address).
This proposal:
a) Defines cryptographic procedures to be followed by Tor clients
and hidden services to allow HS address antienumeration.
b) Defines a new descriptor format which hides the descriptor
content from entities who don't know the public key of the HS.
c) Changes the size (and semantics) of Hidden Service addresses.
1. Acknowledgments
The cryptography behind this proposal was originally proposed by
Robert Ransom in a private email threadi and subsequently posted in
tor-dev [0]. Discussion was continued in trac ticket #8106 [1].
During the past 6 months many bright people have looked at the
cryptography behind this scheme. The list of people includes Nadia
Heninger, Leonid Reyzin, Nick Hopper, Aggelos Kiayias, Tanja Lange,
Dan J. Bernstein and probably others that I can't recall at this
point. Thanks!
2. Parameters
TIME_PERIOD is XXX
3. Scheme overview
Currently, Hidden Services upload their unencrypted descriptor to
hidden service directories (HSDirs). HSDirs store the unencrypted
descriptor in an internal map of: <hs address> -> <hs descriptor>
When a client wants the descriptor of an HS, it asks an HSDir for
the descriptor that corresponds to <hs address>. If the HSDir has
such an index in its map, it returns the <hs descriptor> to the
client.
This proposal asks Hidden Services, to periodically derive a new
ephemeral keypair from its long-term identity key; the new keypair
is a function of the identity key and a time-dependent nonce. The
derivation should be one-way; if you know the identity key you
should be able to derive the ephemeral key, but not the other way
around. Finally, a client should be able to derive the ephemeral HS
public key from the long-term HS public key without knowing the
long-term HS private key (#KEYPAIRDERIVATION)
Hidden Services then encrypt their descriptor with a symmetric key
(derived from the ephemeral public key) and sign the ciphertext and
the ephemeral public key with their ephemeral private key. Then they
place the ephemeral public key, the encrypted descriptor and the
signature in a "metadescriptor" document (#METADESC) and send it to
the HSDir (#DESCPUBLISH).
The HSDir validates the signature of the "metadescriptor", and if
it's legit it stores the metadescriptor in an internal map of:
<ephemeral public key> -> <metadescriptor> .
(#DESCPUBLISH)
Now, out of band, the HS gives to its clients a <z>.onion
address. <z> in this case is the long-term public key of the HS
(this is different from the current situation where <z> is the hash
of the long-term public key).
A client that knows the <z>.onion address and wants to acquire the
HS descriptor, derives the <ephemeral public key> of the HS by using
<z> and the same key derivation procedure that the HS uses. She also
derives the symmetric key that decrypts the encrypted HS descriptor
(#DESCFETCH).
The client then contacts the appropriate HSDir and inquires for the
descriptor with index <ephemeral public key>. If the HSDir has such
an index in its internal map, it passes the <metadescriptor> to the
client (#DESCFETCH).
The client then verifies the signature of the metadescriptor, and if
it's legit she decrypts the encrypted descriptor with the symmetric
key. The client now has the Hidden Servide descriptor she was so
looking for (#DESCDECRYPTION).
4. Security proof
XXX A security proof of the above scheme is under development. We
are not going to implement or deploy anything before we have a solid
proof of this.
5. Changes to the current HS protocol
5.0. Related proposals
This proposal is supposed to be applied on top of the "Migrate HS
identity keys to Ed25519" proposal.
5.1. Ephemeral keypair derivation (#KEYPAIRDERIVATION)
XXX Leaving this unpsecified for now till the security proof comes
along.
For now, let's assume that after this paragraph each HS has a
per-TIME_PERIOD ephemeral keypair. It also has a symmetric key
derived from the ephemeral public key (maybe even the hash of the
ephemeral public key) to encrypt its descriptor.
Let's also assume that each client can generate the ephemeral public
key of a HS given only its long-term public key (and knowledge of
the current time-dependent nonce).
5.2. HS descriptor publishing
5.2.1. Metadescriptor format (#METADESC)
The format of the metadescriptor that is uploaded to the HSDir is:
"ephemeral-public-key" NL public-key
[At start, exactly once]
The ephemeral public key for this time period in base64 encoding.
"encrypted-descriptor" NL encrypted-descriptor
[Exactly once]
An encrypted v3 hidden service descriptor (as specified in
xxx-hs-ecc-id-keys.txt). It's encrypted using the ephemeral
symmetric key of the HS, encoded in base64 and surrounded with
"-----BEGIN MESSAGE-----" and "-----END MESSAGE-----".
"signature" NL signature
[At end, exactly once]
A signature of all fields above with the ephemeral private key
of the hidden service.
5.2.2. Metadescriptor publishing (#DESCPUBLISH)
The metadescriptor specified above is published to the appropriate
HSDir by sending an HTTP 'POST' request to
"/tor/rendezvous3/publish" as specified in the "Migrate HS
identity keys to Ed25519" proposal.
# XXX should this get its own URI, even though we assume that these
two proposals will be implemented and deployed simultaneously?
Upon receiving a descriptor, the directory server checks the
signature, and discards the descriptor if the signature does not
match the enclosed public key. If the signature matches, the
directory server saves the descriptor in a map of:
<ephemeral-public-key> -> <metadescriptor>.
5.3. Metadescriptor fetching (#DESCFETCH)
A client that knows the long-term public key (onion address) of a
hidden service can derive the ephemeral public key and the
ephemeral symmetric key as specified in section 5.1.
A client that wants to fetch the metadescriptor of an HS, does an
HTTP 'GET' request to the appropriate directory server asking for
"/tor/rendezvous3/<z>" where <z> is the ephemeral public key of the
HS.
# XXX should this get its own URI, even though we assume that these
two proposals will be implemented and deployed simultaneously?
5.4. Metadescriptor decryption (#DESCDECRYPTION)
The client then verifies the signature of the metadescriptor, and
discards it if it doesn't match the ephemeral public key that was
previously derived.
If the signature matches, the client uses the derived ephemeral
symmetric key to decrypt the 'encrypted-descriptor' part of the
metadescriptor.
6. Discussion
[Points here might deserve their own sections]
Do we need the HSDir hash ring, even though the HS address and the
descriptor are now hidden from HSDirs?
An ed25519 public key is 32 bytes. 32 bytes in base32 encoding is 56
characters (or 52 with the '=' padding removed). Do we want a
different URL encoding or are we happy with addresses like:
mfrggzdfmztwq2lknnwg23tpobyxe43uov3ho6dzpjaueq2eivda.onion ?
Refs:
[0]: https://lists.torproject.org/pipermail/tor-dev/2012-September/004026.html .
[1]: https://trac.torproject.org/projects/tor/ticket/8106
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev