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

Re: [tor-talk] Theft of Tor relay private keys?

> Hello all, please help me understanding this:
> supposed, the NSA were able to break into a large scale of tor nodes,
> stealing the tor private server key. At the same time they were able
> to gather all traffic they can get. Wouldnt this increase the
> likelihood that data from complete circuits can be decrypted and
> traced back to the original sender?

If their intercepts are passive, merely stealing relays' private
identity key won't accomplish much because Tor uses Forward Secrecy for
both the relay TLS links and for circuit setup.

However, if their intercepts are active (as in they can arbitrarily
manipulate traffic in-flight), then stealing either Guard node keys or
directory authority keys allows complete route capture and traffic
discovery of targeted clients.

So you are right to worry about this, in my opinion. I am also very

I want to make some changes to Tor to make such key theft easier to
detect, less damaging, and harder to make use of:

However, I want to do a lot of other things in 0.2.5.x though too, and
there's this whole browser thing that I'm technically supposed to be
paying attention to too, so I might not get to those. :/

That first one (#7126) is probably a good volunteer/student project for
someone who likes Python, though. It would be easy to make a prototype
with Stem, txtorcon, or even TorCtl.
> Maybe this is paranoid, but this arises the question for me: what
> would happen when I stop my tor node once a week, throw away my keys
> and restart tor so that new server keys were generated. So NSA would
> have to break into my system again, but this would make it harder for
> NSA agency to decrypt circuits where my host is involved.

I am in favor of regular identity key rotation for relays, and I want to
work towards supporting that better by default:

I think keeping your keys on a ramdisk or encrypted filesystem with a
memory-only random key (so if you experience unexplained reboots, etc
they go away) is a good idea.

Also, since Tor reads/creates its identity key at startup and doesn't
need the file afterwords, you can even 'shred'/'wipe' it after that, so
the adversary can't easily pull them off the FS while the system is

Better still, you can load a Kernel module to disable gdb debugger
support so the adversary has to actually dig through/manipulate raw
memory to get the key (which will be error prone and is more likely to
lead to crashes/panics/reboots): https://gist.github.com/1216637

I started describing these and related ideas here:

But I got distracted by more pressing issues before I could finish the
scripts.. Also, many of those encrypted+authenticated Tor container
things probably don't make much sense without Secure Boot to
authenticate the boot process up until you can start up Tor. :/

> What were the disadvantages for the tor network? Would this confuse
> the tor director in any way?  

Sort of. Weekly identity key rotation is too frequent to recommend for
people to do for a few reasons. 

First, it takes the bandwidth measurement servers a couple days to ramp
up your capacity of your new identity key, so you will spend a lot of
time below your max throughput. Second, you would also likely never get
the Guard flag. Third, there are also load balancing issues with Guard
nodes where as soon as you get the Guard flag, it will take 1-2 months
before clients switch to your new Guard, so you will also likely spend
that time at less than your full capacity.

> Would it be able to keep the nickname or would it have to change also?
> Would this have effect on the onion address if I had a hidden server?

No and no, but your hidden server might have brief downtimes/descriptor
publish times that correlate with your key rotation. Not sure how severe
that is in practice.

Mike Perry

Attachment: signature.asc
Description: Digital signature

tor-talk mailing list