Domenico,
In the proposed next generation Rendezvous specification
<https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt>,
there are some major improvements to the security model for hidden services.
The hidden service master secret key no longer has to be live on the hidden
service node. Instead, the master secret key is used to create a batch of
medium-term blinded signing keys, which in turn are used to sign descriptor
signing keys. Descriptor signing keys are the only ones that must be
constantly online in the hidden service node. Each blinded signing key is
valid for a single time period lasting 25 hours by default, and any
descriptor signing key signed by a blinded signing key is only valid for the
period of time the blinded signing key is valid.
So if an online descriptor signing key or the currently valid blinded
signing key is stolen, it may only be used to impersonate the service for
the remainder of the current time-period. Depending on how many blinded
signing keys for future time periods the hidden service operator has
generated in advance, and how well-protected they are from the online hidden
service node, it would be difficult for a compromise of the hidden service
node to allow an attacker to steal blinded signing keys valid for the
future. Realistically, there will be an automated system to activate the
next blinded signing key as the 25 hour time period rolls over, and to
create and distribute new descriptor signing keys derived from the blinded
signing key. Even if this blinded key activation system is compromised, the
maximum amount of keys that can be stolen is limited by the number of future
blinded signing keys the hidden service operator has chosen to generate and
has loaded into the blinded key activator.
Since the master secret key is not used for long periods of time, it may be
broken into pieces with a secret sharing scheme, eliminating the single
point of failure of the stored master secret key being stolen. Periodically,
when new batches of blinded secret keys need to be generated, the master
secret must be reassembled by bringing together all the pieces (or whatever
threshold number of them the secret sharing system is configured to
require), and this reassembled key does become a single point of failure
again, albeit a much better protected one than in the current hidden service
design.
Currently there is no revocation system in the proposed design, only a TODO
note. The only recourse if a descriptor signing key or blinded signing key
is stolen is to wait for the time period they are valid for to be over. If
future blinded signing keys are stolen, this may be a very long wait. And
there is no recourse if the master secret is stolen.
A revocation system for the proposed next gen Rendezvous specification is
important, but it's even more important to implement a revocation system for
the current hidden service design since the the threat (and reality) of
master secret keys being stolen is so much greater.
Regards,
Adrien
On 2015-03-03 9:23 AM, Domenico Andreoli wrote:
The unvoidable single point of failure is the loss of control on a
given onion node.
Isn't possible to require multiple nodes to sustain a single hidden
service?
So that loosing control of a single node doesn't compromise the whole
service.
Domenico
On Tue, Mar 3, 2015 at 2:40 PM, Adrien Johnson <adrienj@xxxxxxxxxxx>
wrote:
A client receiving a revocation descriptor would want to remember not to
trust that hidden service for as long as possible, so there's still going
to
be long-term storage somewhere in the chain. Putting it in the
directories
would mean that as many client as possible could be notified of the
hidden
service's revocation, even long after the initial revocation is
published,
in cases where the hidden service operator is unwilling or unable to
continue to announce the revocation.
Consider that for long-validity revocations, there would actually be less
load placed on the network than for a regular short term descriptor. The
hidden service would not need to frequently publish a new descriptor
about
itself. Once a client knows a hidden service is revoked, they do not need
to
ask about it again. Old revocations could conceivably be stored to disk.
The need to revoke hidden service keys is real. It doesn't take long to
dig
up anecdotes and news reports of .onion sites that have been compromised,
but even when detected there is no reliable way for a legitimate hidden
service operator to notify the network his service cannot be trusted.
Detecting if someone has stolen your hidden service key is easy and is
hijacking your traffic is easy, you only have to look out for hidden
service
descriptors for your service that you did not publish, but there is
currently not much that can be done with this information. The hidden
service operator could include a notice on his hidden website warning of
the
compromise and telling users to divert to a different .onion address, but
a
user has no way of knowing if that warning was published by the attacker
and
directs to another malicious site.
On 2015-03-03 5:19 AM, Donncha O'Cearbhaill wrote:
Alternatively the original hidden service operator could publish hidden
service descriptors with a normal validity period which contain a
revocation field. A HSDir which receives a descriptor containing the
revocation could replace the (potentially malicious) HS descriptor
stored in its cache.
A client could be show an alert that the hidden service they are
attempting to access has been compromised/revoked and should not be used
in future. A HS operator would then keep broadcasting the revocation
descriptor until such time that all clients are likely to have been
notified. This kind of replacement approach would allow revocation
without placing any more load or memory demands on the network.
In practice do HS operators have a need to revoke hidden service keys?
On 03/03/15 03:05, Adrien Johnson wrote:
An solution might be to allow hidden service revocation descriptors to
expire after a long time, and to be updated by the hidden service
operator, but only as a new revocation descriptor which has a later
expiration date. That way the Tor network can eventually forget about
revoked hidden services which are no longer used and where the operator
no longer feels there is a threat of impersonation.
On 2015-03-02 9:50 PM, Max Bond wrote:
It seems like the only way this scheme could work is if the
directories
remembered which services had issued revocations, making compromises
expensive for the whole network and opening the door for
denial-of-service
attacks that effect hidden services as a whole.
I would counter propose that you set up a Twitter account which tweets
about the status of your hidden service, where you could make an
emergency
announcement. Perhaps you could have a passcode required to enter the
site
that changes on a daily basis and is announced from twitter, so that
your
users get in the habit of checking twitter before logging in to your
site.
On Mon, Mar 2, 2015 at 6:40 PM, Adrien Johnson <adrienj@xxxxxxxxxxx>
wrote:
Deleting your key and taking down your service would prevent further
compromise of your system, but if your private key was already
stolen, it
wouldn't stop an attacker from continuing to announce your key and
running
an imposter service.
--
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
--
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
--
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk