Opened 7 years ago

Closed 2 years ago

#5563 closed enhancement (wontfix)

Better support for ephemeral relay identity keys

Reported by: mikeperry Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: key-theft needs-proposal tor-relay path-bias prop220
Cc: mo, nusenu@… Actual Points:
Parent ID: #5456 Points:
Reviewer: Sponsor:

Description

Tagging-based amplification attacks are primarily an issue of node integrity. For the most part, they are impossible to perform if you are external to the tor network, and they are detectable if the adversary's proportion of compromised nodes on the network is low, due to excessive circuit failure at non-colluding nodes.

However, this all changes if most nodes have easily accessible identity keys. All the adversary need do is make a quick stop at each high capacity tor relay, freeze the ram/reboot the box, and extract the keys. From that point on, the adversary is free to intercept and tag traffic transparently upstream. Worse, as the adversary performs this procedure at more and more nodes, their circuit failure rate will fall. At least according to the math of some dude who claims to be a raccoon: https://lists.torproject.org/pipermail/tor-dev/2012-March/003361.html

I believe the best stopgap solution to this (at least until whatever comes out of #5460 is deployed) is to encourage relay operators to keep their relay keys on a ramdisk, so they are discarded in the event of reboot. This would at least require the adversary to retain persistent access to the machine, which risks discovery via auditing mechanisms.

Unfortunately, there are a few issues with how Tor treats relay identity keys that makes it extremely inconvenient for relay operators if they ever change.

This ticket is to serve as the parent ticket for enumerating these inconveniences.

Child Tickets

TicketTypeStatusOwnerSummary
#5564enhancementclosedkanerWeather should allow subscription by IP+Port

Change History (23)

comment:1 Changed 7 years ago by arma

Are you confusing long-term relay identity keys with (weekly rotated) onion keys?

comment:2 Changed 7 years ago by nickm

The alternative to ephemeral ID keys, I think, is two-layer identity keys, like authorities have.

comment:3 Changed 7 years ago by mikeperry

arma: I don't think so. I think I'm actually most concerned about our TLS keys, which I believe are rotated daily. But this rotation doesn't help if you assume an active adversary operating upstream from you. Can't they just take whatever keys you create and toss them away and re-sign new ones they control, using the identity key?

nickm: I don't think relays have as much need for persistent identity as the dirauths do. At worst, if your OS crashes, you spend a few days being remeasured by the bandwidth auths... Also, personally I wouldn't want to deal with the hassle of creating a revocation statement and issuing a new "relay" key every time my box rebooted. I can barely keep up with rotating the things manually right now every reboot, hence the ramdisk suggestion to make it automatic.

comment:4 in reply to:  3 ; Changed 7 years ago by arma

Replying to mikeperry:

arma: I don't think so. I think I'm actually most concerned about our TLS keys, which I believe a

are rotated daily.

Every 2 hours:

  /** 1b. Every MAX_SSL_KEY_LIFETIME_INTERNAL seconds, we change our
   * TLS context. */

But this rotation doesn't help if you assume an active adversary operating upstream from you. Can't they just take whatever keys you create and toss them away and re-sign new ones they control, using the identity key?

Yes. But then when you send them a CREATE cell they won't be able to decrypt it unless they know your onion key too. So the attack they need to do is publish a new descriptor in your name, signed by your identity key, listing their own onion key -- and then also be able to "be" you from the perspective of the network. If the attacker can do all that, how will shorter identity key lifetimes help?

(Note that the above sentence about the CREATE cell does not apply to guards, since they do the create_fast trick. I could see an argument for going back to involving the onion key in the circuit handshake for guards too.)

comment:5 in reply to:  4 ; Changed 7 years ago by mikeperry

Replying to arma:

Replying to mikeperry:

arma: I don't think so. I think I'm actually most concerned about our TLS keys, which I believe are rotated daily.

Every 2 hours:

  /** 1b. Every MAX_SSL_KEY_LIFETIME_INTERNAL seconds, we change our
   * TLS context. */

Ah, tor-spec.txt says "should".. "at least once a day".

But this rotation doesn't help if you assume an active adversary operating upstream from you. Can't they just take whatever keys you create and toss them away and re-sign new ones they control, using the identity key?

Yes. But then when you send them a CREATE cell they won't be able to decrypt it unless they know your onion key too. So the attack they need to do is publish a new descriptor in your name, signed by your identity key, listing their own onion key -- and then also be able to "be" you from the perspective of the network. If the attacker can do all that, how will shorter identity key lifetimes help?

Well first off, I'm pretty sure that the onion key is irrelevant to tagging-based amplification. An attacker interested in tagging-based amplification need only unwrap the TLS link key, which is authenticated only by the identity key (according to my read of tor-spec). Once the adversary has have the ability to see inside TLS, they can read the command field of cell payloads. The adversary then happily lets the original onionskin negotiation in CREATE complete, which negotiates a symmetric key unknown to the adversary. This doesn't matter, because AES CTR allows them to then embed an arbitrary tag in the following RELAY cell which sets up the stream. Nodes unable to undo the tag in the RELAY cell fail the circuit, which provides the amplification.

Also, if I've missed something and the onion key *is* needed, what actually verifies that the onion key you try to publish is what gets published?

comment:6 in reply to:  5 ; Changed 7 years ago by rransom

Replying to mikeperry:

Replying to arma:

Replying to mikeperry:

arma: I don't think so. I think I'm actually most concerned about our TLS keys, which I believe are rotated daily.

Every 2 hours:

  /** 1b. Every MAX_SSL_KEY_LIFETIME_INTERNAL seconds, we change our
   * TLS context. */

Ah, tor-spec.txt says "should".. "at least once a day".

If I remember correctly, MAX_SSL_KEY_LIFETIME_INTERNAL is greater than 7200.

comment:7 in reply to:  6 Changed 7 years ago by arma

Replying to rransom:

If I remember correctly, MAX_SSL_KEY_LIFETIME_INTERNAL is greater than 7200.

or.h:#define MAX_SSL_KEY_LIFETIME_INTERNAL (2*60*60)

comment:8 in reply to:  5 Changed 7 years ago by arma

Replying to mikeperry:

the TLS link key, which is authenticated only by the identity key (according to my read of tor-spec).

Correct.

what actually verifies that the onion key you try to publish is what gets published?

If you're talking about an adversary who controls your network, what stops them from publishing a descriptor for a new relay near you on the network, making up their own identity key?

I worry you're trying to block a particular attack scenario while not considering a big pile of equivalently bad attack scenarios.

comment:9 in reply to:  description Changed 7 years ago by arma

Replying to mikeperry:

Unfortunately, there are a few issues with how Tor treats relay identity keys that makes it extremely inconvenient for relay operators if they ever change.

Frequently changing identity keys will also endanger the protection that clients get from using guards (https://blog.torproject.org/blog/research-problem-better-guard-rotation-parameters), since it's unclear how a client will correctly realize how to keep using you if it thinks of you as an identity key that went away.

comment:10 Changed 7 years ago by mikeperry

How frequent is frequent? In datacenters that don't store your machine in a cardboard box, uptime is measured in months, if not years, and reboots are entirely under your control. Note that there is no reason why controlled reboots can't preserve identity keys...

comment:11 in reply to:  10 Changed 7 years ago by rransom

Replying to mikeperry:

Note that there is no reason why controlled reboots can't preserve identity keys...

User error/forgetfulness/sloppiness is one reason.

comment:12 Changed 7 years ago by mikeperry

I've noted the need to preserve ephemeral keys in my notes for #5570.

comment:13 in reply to:  12 Changed 7 years ago by mikeperry

Replying to mikeperry:

I've noted the need to preserve ephemeral keys in my notes for #5570.

err, I meant across controlled reboots.

comment:14 Changed 7 years ago by nickm

Milestone: Tor: unspecified

comment:15 Changed 7 years ago by nickm

Keywords: needs-proposal added

comment:16 Changed 7 years ago by nickm

Keywords: tor-relay added

comment:17 Changed 7 years ago by nickm

Component: Tor RelayTor

comment:18 Changed 7 years ago by mo

Cc: mo added

comment:19 Changed 6 years ago by mikeperry

Keywords: path-bias added

comment:20 Changed 6 years ago by mikeperry

Keywords: key-theft added

comment:21 Changed 4 years ago by tyseom

Cc: nusenu@… added

comment:22 Changed 4 years ago by nickm

Keywords: prop220 added

See also proposal 220 and ticket #13642 .

comment:23 Changed 2 years ago by nickm

Resolution: wontfix
Severity: Normal
Status: newclosed

Going to call this "wontfix" now that prop220 makes offline master identity keys easy.

Note: See TracTickets for help on using tickets.