[tor-relays] Towards a Tor Node Best Best Practices Document

[Mike Perry]

Thus spake Fabian Keil (freebsd-listen at fabiankeil.de):

> > You're failing to see the distinction made between adversaries, which
> > was the entire point of the motivating section of the document. Rekeying
> > *will* thwart some adversaries.
> 
> I'm not arguing that rekeying is useless. I just think that for
> most Tor relays reboots are usually not the result of a compromise
> and the lack of reboots doesn't proof anything either (I'm aware
> that you weren't implying this).
> 
> For a relay operator concerned about key theft, rekeying after
> a certain amount of time, even if there's no sign of a compromise,
> seems to make more sense to me.

They seem orthogonal, but yes, I should mention periodic rekeying if
your relay machine uptime exceeds something like 6mos? 1yr? RSA-1024
probably doesn't have a very long shelf-life as-is...

> > > Are "weird memory gymnastics" really that much more effort
> > > than getting the relevant keys through ptrace directly?
> > 
> > If they require a kernel exploit to perform, absolutely. If there are
> > memory tricks root can perform without a kernel exploit, we should see
> > if we can enumerate them so as to develop countermeasures.
> 
> My assumption was that a root user could get the key (or reenable
> ptrace) through /dev/mem without relying on kernel exploits.

Apparently /dev/mem only allows access to low physical memory (<1M) and
BIOS regions on most distros due to CONFIG_STRICT_DEVMEM, so it's not a
sure shot by any means. 

After reading a few mailinglist archives about kernel.modules_disabled,
it looks like there is a contingent of kernel developers who are arguing
for "layered security" over "perfect security", and they are working to
enumerate and close holes that elevate root directly to ring0. Even if
the LKML people occasionally refuse to take their patches for old
unixbeard dogmatic reasons, it looks like they are still being picked up
by RHEL/CentOS and Ubuntu.

But, this reminds me that I might need to add a "Auditing
Recommendations" section to the APT.  Technically, the truly paranoid
should also keep pristine copies of their initrd, kernel, modules, and
init itself, and veryify/replace them in the event of sketchy activity.
But the question of how to actually verify/replace these files while
using an untrusted kernel is another matter..  A few ways come to mind,
but if we specify just One True Way, obviously custom rootkits could
still be written to cloak against it...

In my mind it's OK if some methods fail, because it's all about taking
away full certainty of success and certainty of undiscoverability from
the adversary. That alone will change their incentives to use the
attack.

> > > I suspect getting the keys through either mechanism might be
> > > trivial compared to getting the infrastructure in place to use
> > > the keys for a non-theoretical attack that is cost-effective.
> > 
> > The infrastructure is already there for other reasons. See for example,
> > the CALEA broadband intercept enhancements of 2007 in the USA. Those can
> > absolutely be used to target specific Tor users and completely
> > transparently deanonymize their Tor traffic today, with one-time key
> > theft (via NSL subpoena) of Guard node keys. 
> 
> CALEA might provide access to the traffic, but the attacker still
> has to analyze it. I'm not saying that is impossible or inconceivably
> hard, but I'd expect it to be a lot more complicated than getting the
> keys from a system the attacker already have root access.

Wrt to analysis, for tagging there is none needed. It's a fire and
forget method that can be deployed as an extension module to existing
intercept solutions. You just use a modified stunnel (or similar TLS
proxy) to embed a unique identifier into the circuits of clients you're
interested in, read it out again at compromised exits, and log the
traffic along with its unique ID.  If a tagged circuit is created to a
non-compromised exit, that exit just kills it for you instantly before
streams even get attached (for example, during the client bootstrap
process or during predictive circuit building), and the client happily
transparently retries until it creates a successful circuit to a
compromised exit.

Yes, there are things we can do to defend against these attacks in the
client. See https://trac.torproject.org/projects/tor/ticket/5456 for
some of those. But I think we should also take this opportunity to think
a little deeper about protecting and rotating relay keys in the first
place.


-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20120429/baa6af1e/attachment.pgp>