Re: [tor-talk] Revoking a hidden service key

[Domenico Andreoli <domenico.andreoli@xxxxxxxxx>]

Adrien,

  yes, something like that. thanks for the pointer.

Domenico

On Tue, Mar 3, 2015 at 4:58 PM, Adrien Johnson <adrienj@xxxxxxxxxxx> 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@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
-- 
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