Thus spake Fabian Keil (freebsd-listen@xxxxxxxxxxxxx): > > 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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays