Delivery-Date: Tue, 03 Mar 2015 11:17:47 -0500
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	RCVD_IN_DNSWL_MED,T_DKIM_INVALID,T_RP_MATCHES_RCVD,URIBL_BLOCKED
	autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id C39F91E0A40
	for <archiver@seul.org>; Tue,  3 Mar 2015 11:17:45 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 1C18133E4C;
	Tue,  3 Mar 2015 16:17:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 7171433E41
 for <tor-talk@lists.torproject.org>; Tue,  3 Mar 2015 16:17:38 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id FCSYe1XHqpQz for <tor-talk@lists.torproject.org>;
 Tue,  3 Mar 2015 16:17:38 +0000 (UTC)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com
 [IPv6:2607:f8b0:4003:c06::233])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 4798033E3E
 for <tor-talk@lists.torproject.org>; Tue,  3 Mar 2015 16:17:38 +0000 (UTC)
Received: by oiav1 with SMTP id v1so371445oia.9
 for <tor-talk@lists.torproject.org>; Tue, 03 Mar 2015 08:17:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:sender:in-reply-to:references:date:message-id:subject
 :from:to:content-type;
 bh=EHi52zsoTbQXs2PNZW4YNS4Q7I62sGX1qL1u/8qV2/c=;
 b=Sd6akd5e8wEnZlqwQVLgHlk+6eX0fqpS886Fh0f3OFbThxiNw/kQ0mEWWRLJCNm+9S
 l7+0fXOfNPD/QRS6FNfsEercwP23+05pYPyq2BqqNNARHzSrsZJBY8/nbwqyAbOBv3V4
 iWgvgmlGDS+BuzI7vF4z88CyL5ttx/CgMRs8NzG9M80UX/sooz8ic4HX5QDz0jtDnsMN
 7GF1JR19Xx/zMt+IMWZ1T/s5sewz1p4xAsPs74p376PU7SRkL3eNLVNtQU8BpphPvRxu
 UyfLo6SqYANhlc/Nm+EP7yB9e4PuvG6v7widM1yVKSA6CFxdHE5Wh11dNC6+L61IwFfj
 3f5g==
MIME-Version: 1.0
X-Received: by 10.202.1.200 with SMTP id 191mr22349409oib.82.1425399455720;
 Tue, 03 Mar 2015 08:17:35 -0800 (PST)
Received: by 10.76.55.136 with HTTP; Tue, 3 Mar 2015 08:17:35 -0800 (PST)
In-Reply-To: <54F5DA0C.3090403@adrienj.com>
References: <54F506C7.6020202@adrienj.com>
 <CALoT2zYkwUEguD-bN+hsePTK8a+G=HRWju6s3yGtiQA5+G5Waw@mail.gmail.com>
 <54F51F38.30902@adrienj.com>
 <CAKrUFkh4fd9tkssVXiUs0g_X5vRYH2FBA4Te0nJGRtyM2Qy0dw@mail.gmail.com>
 <54F524EE.3050400@adrienj.com> <54F58AAD.5010000@donncha.is>
 <54F5B9DC.9010101@adrienj.com>
 <CAGH6_ppvP-1B8F_7w2QN95x4Dy8j0rjwhbbeYB1tUCk4GNzVGw@mail.gmail.com>
 <54F5DA0C.3090403@adrienj.com>
Date: Tue, 3 Mar 2015 17:17:35 +0100
X-Google-Sender-Auth: EgZgMPC1ul5IXG-xzWTYvg1qemc
Message-ID: <CAGH6_pr7gVxRRdGqaDhJdSL3yMhN4w6ZHfFnjJFWDubuWZjiig@mail.gmail.com>
From: Domenico Andreoli <domenico.andreoli@linux.com>
To: tor-talk@lists.torproject.org
Subject: Re: [tor-talk] Revoking a hidden service key
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

Adrien,

  yes, something like that. thanks for the pointer.

Domenico

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

