[tor-talk] Revoking a hidden service key

Tue Mar 3 16:51:15 UTC 2015

A correction,

The purpose of the blinded secret keys is not to give an extra layer of 
protection against secret key compromise, but to prevent hidden service 
harvesting and cataloging by hidden service directories. This is 
achieved by deriving the blinded signing keys from the master secret key 
in a way that someone knowing the .onion address (the master public key) 
and the current time period knows what the current blinded signing key 
for that service must be. The visitor who knows the .onion address can 
then query the hidden service directories for a hidden service 
descriptor signed by a descriptor signing key which was signed by the 
current blinded signing key. But a malicious hidden service directory 
seeking to catalog .onion sites cannot determine from the blinded 
signing keys of the hidden service descriptors it receives what the 
.onion domain is.

This is a clever bit of cryptography, but the key derivation method is 
uses means an attacker who steals any blinded signing secret key can 
derive the master secret key. Any system storing the blinded signing 
master keys becomes a single point of failure for the whole hidden 
service. Fortunately, the "blinded signing key activation system" I 
described does not actually have to exist. The blinded signing secret 
keys are not used for anything except signing the descriptor signing 
keys, which can be done in advance and the blinded signing secret keys 
discarded. The automated system which distributes new descriptor signing 
keys to the hidden service node at the start of every 25 hour time 
period does not need to know any blinded signing master keys

So the security model of the proposed next generation Rendezvous system 
is still as strong as I described earlier. Stealing the current 
descriptor signing key from the hidden service onion node only lets an 
attacker impersonate the service until the current time period is over. 
Compromising the automated descriptor signing key activation system lets 
an attacker impersonate the service until the latest descriptor signing 
key that was preloaded expires. The master secret key can still be 
stored securely offline in distributed pieces. The only single point of 
failure that permanently compromises the hidden service is when the 
master secret key is assembled and a batch of new descriptor signing 
keys must be produced.

Regards,
Adrien

On 2015-03-03 11:17 AM, Domenico Andreoli wrote:
> Adrien,
>
>    yes, something like that. thanks for the pointer.
>
> Domenico
>
> On Tue, Mar 3, 2015 at 4:58 PM, Adrien Johnson <adrienj at adrienj.com> wrote:
>> 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
>>
>> --
>> 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