Adrien, yes, something like that. thanks for the pointer.
Domenico On Tue, Mar 3, 2015 at 4:58 PM, Adrien Johnson <adri...@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 <adri...@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 <adri...@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@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@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@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@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
