[tor-talk] Revoking a hidden service key

[Adrien Johnson]

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 at adrienj.com> 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 at adrienj.com>
>>>>> 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 at lists.torproject.org
>>>>>> To unsubscribe or change other settings go to
>>>>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>>>>>>
>>>
>> --
>> tor-talk mailing list - tor-talk at lists.torproject.org
>> To unsubscribe or change other settings go to
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk