[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-dev] A Proposal for a hidden service revocation system

Filename: xxx-rend-revoke.txt
Title: Hidden Service Revocation
Author: Adrien Johnson
Created: 2015-03-04
Status: Draft
Hidden service operators need to be able to revoke trust in their hidden service if they know or suspect their hidden service secret key has been compromised. 

1. Motivation
A Hidden service operator can determine that the hidden service secret key is compromised in several ways today. Forensic traces of intrusion may be detected on the hidden service server, or valid signed descriptors for the service may be published by someone other than the legitimate operator in a traffic hijacking attack. It is impossible for a compromised hidden service secret key to be used to hijack traffic in a way that is not detectable by 
    the latter method.
Even though it is easy for the operator to detect a hidden service key is compromised, there is no satisfactory way for a hidden service operator to 
    notify its users of this fact. The hidden service may display
a message to its users warning of the compromise and directing them to a new 
    supposedly uncompromised .onion domain, but a user has no way to know
whether such a message was posted by the legitimate hidden service operator 
    or a hijacker.
A revocation system where anyone possessing the hidden service secret key 
    can revoke trust in the key solves this problem.

2. Overview
This revocation system is built on the hidden service directory system. A revocation takes the form of a hidden service descriptor which provides no 
    way to contact the hidden service (i.e. zero introductory points).

    A hidden service directory which receives a revocation descriptor and
    verifies its signature should discard any non-revocation descriptors it
    possesses for that hidden service, and should propagate the revocation
    through the hidden service directory system as normal.

    Crucially, a hidden service directory which possesses a revocation
descriptor for a hidden service and receives a newer, valid descriptor for that hidden service which is not a revocation descriptor MUST retain the revocation descriptor and MUST discard the newer non-revocation descriptor. 
    This is the only change needed to support this revocation system at a
    basic level today.

3. Design considerations

    3.1 Revocation lifetime

        Ideally, a revocation should be permanent. The Tor network would
ideally remember forever that a hidden service has been revoked, and this would provide the maximum possible protection to the users of the 
        hidden service against imposter services.

        Indeed, any tor node which becomes aware a hidden service has been
revoked should remember this information forever, and should refuse to connect to any hidden service which it knows was revoked in the past 
        (unless the user disables this protection).
However, a permanent (or even just long-lived) revocation in the hidden 
        service directories present problems:

        1) Increased memory and bandwidth requirements on the Tor network
compared to a normal hidden service descriptor. For non-malicious use, this may not really be a problem, since once a service is revoked, there would be only a trickle of requests for updated information about it (from visitors who have not already found out it was revoked). However for a malicious user who attacks the Tor network by flooding it with 
        hidden service descriptors for fake hidden services, any increased
lifetime of a revocation descriptor over a normal descriptor represents 
        a multiplication of their attack power.

        2) For next generation hidden services as described in
224-rend-spec-ng.txt, a revocation which lasts longer than one blinded 
        signing key validity period weakens the privacy protection against
correlation which is provided by rotating blinded signing keys. If a 
        revocation were - for any amount of time - not expected to be
signed by the current normal blinded signing key for that service, but instead a separate 'blinded revocation signing key', then users seeking to check the revocation status of that service before visiting would have to make two requests for a hidden service descriptor: one to see if there is a revocation descriptor published by that service, and one to 
        see if there is a normal descriptor published by that service.
A malicious hidden service directory (or group of directories) could use this correlation to determine which hidden service descriptors belong to 
        the same hidden service between blinded signing key rotations.
[NOTE: Not sure how easy correlation based on request volume already 
        makes this attack if the attacker controls enough hidden server
directories to reliably monitor request volume between blinded signing 
        key rotations. I suspect the real danger of long-lived revocations
        compared to attacks based purely on request volume is that it lets
        attackers easily "pick up a lost trail" if they managed to link a
        revocation signing key and a normal blinded signing key at any time
in the past, whereas attacks based purely on request volume are likely to lose track of a service permanently when its descriptors shift to 
        a directory the attacker does not control]

        For these reasons, revocations which last no longer than
        a normal hidden service descriptor, and which the operator must
therefore constantly broadcast, are the safest option for implementing 
        hidden service revocations using hidden service descriptors.
Short lived revocations have the advantage that the Tor network does not need to make any hard-and-fast judgement about how long it is worthwhile 
        to remember a hidden service has been revoked, the hidden service
        operator can make that judgement for themselves and broadcast the
revocation for as long the operator feels hijacking and impersonation 
        is a concern.
If the operator is unable to maintain (or fears they will be unable to 
        maintain) a revocation broadcast for an appropriate amount of time,
        they can disclose their private key to a 3rd party service who will
broadcast the revocation on the operator's behalf. An operator would want to employ several of these services, since if only one service had 
        the private key, and if they were malicious, they could cease
        broadcasting the revocation and instead use the key to set up an
        impostor service.
Despite these minor difficulties that short-lived revocations impose, they are still a major improvement to the security of the Tor network. 

    3.2 Digression on the shape of a 3rd party Revocation Broadcast Service

        Though it is outside the scope of this proposal,
I envision these 3rd party key revocation services being simple websites where anyone can upload a hidden service private key and the website will broadcast the revocation indefinitely. They could employ simple abuse-mitigation like CAPCHAs or IP ratelimiting over the clearnet to prevent mass-upload of keys. This should keeps costs low enough that 
        these revocations services could operate for free.

        Alternatively (or additionally), a distributed 3rd party revocation
service could be built into the Tor network by enclosing the private key in the revocation descriptor. This would allow anyone who retrieves 
        the revocation descriptor (and knows which .onion it's for) to
broadcast updated 'echo' revocation descriptors of their own. This could 
        be built to avoid the problems with static long-lived revocations.
        [TODO: Expand in another document later]

4. Implementation

    4.1 Basic Support
For the Tor network to support hidden service revocations at a basic level, a large proportion of hidden service directories must recognize that a hidden service descriptor with zero introductory points has the special meaning of being a revocation. These hidden service directories must not allow a current unexpired revocation descriptor to be replaced by a non-revocation descriptor (so called 'un-revocation'). In all other ways, treatment of a revocation descriptor is identical to treatment of 
        a non-revocation descriptor for a hidden service.
[NOTE: Maybe we want a more explicitly requested revocation? Using a 
        zero introductory point descriptor as a revocation has the
advantage of being backward-compatible with older directory software, which will be able to accept and propagate the revocation to other more 
        up-to-date directories, even though the older directories will not
provide protection against un-revoking a hidden service if the attacker 
        delivers an un-revocation descriptor to them directly.
Is there a need for zero introductory point descriptors in any other 
        case? If a hidden service previously published introductory points
        and it now no longer can be contacted at those points, and it does
not have any new introductory points, it is unreachable. Publishing a 
        descriptor announcing all zero of its introductory points will not
change its reachability, though it may slightly reduce wasted effort by 
        tor nodes attempting to reach it.]

        4.1.1 Steps required to add support

            1) If current code results in hidden services publishing zero-
            introductory point descriptors, this is blocked to prevent
            accidental revocation. I would love to get this in 0.2.6.

            2) If a modification is needed in step 1, then a grace period
            is given for hidden service operators to update their
software. This grace period does not have to be long, we can move onto step 3 relatively fast, since the only penalty for accidental 
            revocation step 3 would create is forcing the hidden service to
upgrade their software, and the hidden service being unreachable for 
            a maximum of 25 hours (lifetime of a descriptor) after the
            hidden service upgrades.

            3) Hidden service directories are modified to not allow a
            current unexpired revocation descriptor to be replaced by an
un-revocation descriptor. Basic support for revocation is achieved! 

            4) A long upgrade grace period is now given. The vast majority
            of hidden services should be using software which includes the
            modifications made in step 1

            5) Expanded revocation capabilities may be added, as described
            below.

    4.2 Expanded Capabilities

        4.2.1 Cache of revoked services
A Tor node which tried to connect to a hidden service in the past and discovered that the service was revoked should remember that 
            revocation and refuse to connect indefinitely, even if the
            revocation ceases to be broadcast in the future.

        4.2.2 Presentation to the user
If an onion proxy that detects the user tried to visit a revoked 
            service, this information should be presented to the user
out-of-band. I.E not in a way that could be mistaken for a hidden service which is only temporarily unreachable, or as information sent by the service. This could be done via a system level popup, or 
            a taskbar notification. The presentation should be strongly
distinguished from a hidden service which is simple unreachable. 

        4.2.3 Automatic hijacking detection/revocation
Tor hidden service software could have a mode to detect if another party is using the hidden service private key to publish descriptors 
            for that service. If the hidden service operator configures it,
the Tor hidden service software could immediately begin to broadcast 
            the revocation for that service.

5. Future Compatibility with Next Generation Hidden Services

    Next generation Tor hidden services require a modified
revocation system because the hidden service master secret key is better protected, and does not need to live online on the hidden service tor node. The day-to-day operation of the service is carried out by a pre-loaded set of changing subordinate descriptor signing keys, which expire after a set 
    time (25 hours by default). If descriptor signing keys are compromised,
    they can be used to hijack traffic and impersonate the hidden service,
    but only until the descriptor signing keys expire. So there is a need
for a way to revoke descriptor signing keys and provide new ones, but not to 
    permanently revoke trust in the hidden service.

    Also, theft of descriptor signing keys should not allow an attacker to
    revoke the master secret key.

    The revocation permissions would looks something like the following.
    (Blinded signing keys are equivalent to the master secret key for
revocation purposes because an attacker which obtains any blinded signing 
    secret key can easily derive the master secret key.)
1) Current descriptor signing key can revoke current descriptor signing key.
2) Master secret key can revoke any descriptor signing key and provide a new 
    descriptor signing key for that time-period.

    3) Master secret key is the only one that can revoke master secret key.

    5.1 Descriptor Signing Keys Revoking Themselves

        [TODO: Finish later]

    5.1 Master Secret Key Revoking and Replacing Descriptor Signing Keys

        [TODO: Finish later]

    5.2 Master Secret Key Revoking Itself

        [TODO: Finish later]
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev