It's occurred to me that we have yet to provide any official recommendations with respect to best practices for operating Tor relays.
This post is my attempt to define a reasonable threat model and use it to develop some recommendations. My plan is to post it here first, to subject it to review by the relay operator community. After operators have a chance to comment, the plan is to relocate the document to the Tor Wiki and/or a blog post.
As always, to focus our thoughts, we start with the adversary's goals.
Adversary Goals
There is a significant difference between adversaries that can see inside of router-to-router TLS vs those that cannot. I believe this capability distinction governs the adversary goals in terms of compromising relays as opposed to merely externally observing them.
Adversaries that can unwrap router TLS can perform every attack that an actual node can perform, at any location between the user and the node, and/or between the node and other nodes.
In particular, adversaries that can see inside router TLS can perform tagging attacks (see https://lists.torproject.org/pipermail/tor-dev/2012-March/003361.html) as well as perform circuit-specific active and passive timing analysis.
These attacks can be quite severe. An adversary that is able to obtain Guard identity keys is free to perform a tagging attack anywhere on the Internet. In other words, if the adversary is interested in monitoring a particular user, the adversary need only obtain the identity keys for that user's 3 guard nodes, and from that point on, the adversary will be able to transparently monitor everything that user does by way of using tagging to bias the users paths to connect only to surveilled exit nodes who also have had their identity keys compromised.
Based on this distinction, it seems that some simple best practices can increase the costs of an adversary that wishes to compromise tor traffic.
Let's now consider how the adversary goes about compromising router TLS.
Attack Vectors
There are two high-level vectors towards seeing inside node-to-node TLS (which uses ephemeral keys that are rotated daily and authenticated via the node's identity key). Both high-level vectors therefore revolve around node identity key theft.
Attack Vector #1: One-Time Key Theft
The one-time adversary is interested in performing a grab of keys and then operating transparently upstream afterwords. This adversary will take the form of a coercive request at a datacenter/ISP to extract identity node key material and from then on, operate externally as a transparent upstream MITM, creating fake ephemeral TLS keys authenticated with the stolen identity key. Tor nodes that encounter this adversary will likely see it in the form of unexplained reboots/mysterious downtime, which are inevitable in the lifespan of any Tor node.
Attack Vector #2: Advanced Persistent Threat Key Theft
If one-time methods fail or are beyond reach, the adversary has to resort to persistent machine compromise to retain access to node key material.
The APT attacker can use the same vector as #1 or perhaps an external vector such as daemon compromise, but they then must also plant a backdoor that would do something like trawl through the RAM of a machine, sniff out the keys (perhaps even grabbing the ephemeral TLS keys directly), and transmit them offsite for collection.
This is a significantly more expensive position for the adversary to maintain, because it is possible to notice upon a thorough forensic investigation during a perhaps unrelated incident, and it may trigger firewall warnings or other common least privilege defense alarms inadvertently.
Unfortunately, it is also a more expensive attack to defend against, because it requires extensive auditing and assurance mechanisms on the part of the relay operator.
Defenses
It seems clear that the above indicates that at minimum relays should protect against one-time key compromise. Some further thought shows that it is possible to make the APT adversary's task harder as well, albeit with significantly more effort.
Let's deal with defending against each vector in turn.
Prevent Vector #1 (One-Time Key Theft): Deploy Ephemeral Identity Keys
The simplest way to defend against the adversary who attempts to extract relay keys through a reboot is to take advantage of the fact that even node identity keys can be ephemeral, and do not need to persist long term (certainly not past a reboot). This can be achieved with a boot script that wipes your keys (they live in /var/lib/tor/keys) at startup, or by using a ramdisk: http://www.cyberciti.biz/faq/howto-create-linux-ram-disk-filesystem/
Of the two, the ramdisk option is superior, since it will prevent the adversary from easily re-using your old keys after you begin using the new ones.
Additionally, ssh server key theft is another one-time vector that can be used to quickly bootstrap into node key theft. For this reason, node admins should always use ssh key auth for tor node administration accounts, since it prevents ssh server key theft from implying continuous server compromise: http://www.gremwell.com/ssh-mitm-public-key-authentication
Issues With Ephemeral Identity Keys
There are a few issues with deploying ephemeral identity keys.
Issues With Ephemeral Identity Keys: Client guard node loss
The primary issue with ephemeral identity keys is client Guard node loss. If your relay obtains the Guard flag, you should endeavor to keep it. If you have planned maintenance and controlled reboots, you should copy your identity keys to a safe location prior to reboot so that clients aren't forced to rotate their guards prematurely due to unnecessary rekeying.
Issues With Ephemeral Identity Keys: MyFamily
The next issue is that identity key rotation makes the use of MyFamily very complicated. For large families, it's nearly impossible to update the MyFamily line of each node instance after every unexpected reboot.
We've filed a bug to see if we can find a more convenient way to provide the same feature, but it's not clear that MyFamily is worth maintaining: https://trac.torproject.org/projects/tor/ticket/5565
It is very likely that the security benefit from maintaining MyFamily pales in comparison the gain from deploying ephemeral identity keys, and MyFamily should be abandoned entirely.
Issues With Ephemeral Identity Keys: Tor Weather
The final issue with ephemeral identity keys is that node monitoring mechanisms such as Tor Weather become difficult to use in the face of rotating keys. We've filed this bug to improve Weather's subscription mechanisms: https://trac.torproject.org/projects/tor/ticket/5564
Preventing Vector #2: Isolation Hardening and Readonly Runtime
Once one-time key theft has been dealt with, you can begin to consider how to deal with the Advanced Persistent Threat.
The effort required to defend against this adversary is considerable, and it is not expected that all operators will devote the effort to do so.
To limit scope, we are not going to deal with the daemon compromise vector; for that see your OS least-privilege mechanisms (such as SElinux, AppArmor, Grsec RBAC, Seatbelt, etc). Instead, we will deal with how you can attempt to protect your identity keys once an adversary already has root access.
If you are serious about defending against this adversary, the first thing you will want to do is disable access to the 'ptrace' system call from userland, which allows easy key theft using debugging tools. Note that all current built-in kernel mechanisms to do this still allow root users to use ptrace on arbitrary processes. In order to disable ptrace for root users, you need to load a kernel module to patch the syscall table to remove access to the syscall itself. Two options for this are: https://gist.github.com/1216637 http://people.baicom.com/~agramajo/misc/no-ptrace.c
Once access to the ptrace system call is removed, you need to disable module loading to prevent it from being restored. On Linux, this is accomplished via 'sysctl kernel.modules_disabled=1'. You should perform this operation as early in the boot process as possible. One technique that works on Redhat-based systems is to place a shell script in /etc/rc.modules to load the modules you need for operation, insert the ptrace module, and then issue the sysctl to disable further module loading. Redhat-derivatives launch /etc/rc.modules first thing at the top of /etc/rc.sysinit.
After that comes ensuring runtime integrity. There are several ways to achieve this, but most are easily subverted by an attacker with direct access to the hardware. The most robust approach seems to be to create a small encrypted loopback filesystem that contains all of the libraries required to run the 'tor' process as well as all of the requisite configuration files. Requisite libraries can be determined via 'ldd /usr/bin/tor'. The encrypted loopback filesystem doesn't need to be more than ~25M in size, but you will also need an auxillary var loopback that needs to be a hundred megs or so.
Here are the commands for creating the root loopback filesystem:
dd if=/dev/urandom of=./tor-root.img bs=1k count=25k losetup /dev/loop1 ./tor-root.img cryptsetup luksFormat /dev/loop1 cryptsetup luksOpen /dev/loop1 tor-root mkfs.ext4 /dev/mapper/tor-root
Once this encrypted loop is created such that it can run your relay's Tor processes, you should take the sha1sum of the file and store it offsite.
When you use this loopback, you will mount it readonly, and mount an unencrypted var directory inside of it, and a ramdisk for your keys inside of that:
dd if=/dev/urandom of=./tor-var.img bs=1k count=200k losetup /dev/loop2 ./tor-var.img mkfs.ext4 /dev/loop2
mount /dev/mapper/tor-root /mnt/tor-root -o ro mount /dev/loop2 /mnt/tor-root/var
mkfs -q /dev/ram1 128 mount /dev/ram1 /mnt/tor-root/var/lib/tor/keys cd /mnt/tor-root/ chroot . start_tor.sh
Once you start your tor process(es), you will want to copy your identity key offsite, and then remove it. Tor does not need it to remain on disk after startup, and removing it ensures that an attacker must deploy a kernel exploit to obtain it from memory. While you should not re-use the identity key after unexplained reboots, you may want to retain a copy for planned reboots and tor maintenance.
scp /mnt/tor-root/var/lib/tor/keys/secret_id_key offsite_backup:/mnt/usb/tor_key rm /mnt/tor-root/var/lib/tor/keys/secret_id_key
Upon suspicious reboots, you can verify the integrity of your tor image by simply calculating the sha1sum (perhaps copying the image offsite first). You do not need to do anything special with the var loopback.
These steps should prevent even adversaries who compromise the root account on your system (by rebooting it, for example) from obtaining your identity keys directly, forcing them to resort to kernel exploits and memory gymnastics in order to do so.
Don't forget to periodically update the libraries stored on your loopback root using a trusted offsite source, as they won't receive security updates from your distribution.
One alternative to make your loopback fs creation, tor startup, and maintenance process simpler is to statically compile your image's tor binary on an offsite, trusted computer. If you do this, you should no longer need to bother with chrooting your tor processes or copying libraries around. However, it still does not save you from the need to recompile that binary whenever there is a security update to the underlying libraries, and it may come at a cost of exploit resistance due to the loss of per-library ASLR.
Ok, that's it. What do people think? Personally, I think that if we can require a kernel exploit and/or weird memory gymnastics for key compromise, that would be a *huge* improvement. Do the above recommendations actually accomplish that?
If so, should we work on providing scripts to make the loopback filesystem creation process easier, and/or provide loopback images themselves?
Even the APT defenses end up not working out, I would sleep a lot better at night if most relays deployed only the defenses to one-time key theft... Thoughts on that?
Mike Perry mikeperry@torproject.org wrote:
It's occurred to me that we have yet to provide any official recommendations with respect to best practices for operating Tor relays.
While you seem to be focused on improving the security, in my opinion a best practices document should also mention which practices will guarantee that the relay gets a bad exit flag if they become known.
Including parts of or linking to: https://trac.torproject.org/projects/tor/wiki/doc/badRelays probably wouldn't hurt.
I only became aware of the page recently myself. I was pleasantly surprised, as I previously was under the impression that running an intercepting HTTP cache on an exit relay "to safe traffic" was still considered acceptable.
Attack Vector #2: Advanced Persistent Threat Key Theft
I'm confused by the use of the buzzword APT. In my experience it's commonly used to describe an imaginary and nearly omnipotent attacker who has a more or less unlimited budget and isn't limited to actually using the network to achieve its goal.
This definition is great if the main goal is spreading FUD to increase ones budget or getting votes, but it makes coming up with effective defences kind of hard.
This might explain why the definition is often used by government agencies, political parties and snake-oil vendors, but it doesn't explain why you would want to use it in a technical document.
I assume "your" APT is somehow less capable then "my" APT, but without knowing your definition I can't really tell if the proposed defenses are effective against it.
Adding your definition to the document would help, but personally I would prefer it if the term APT wouldn't be used at all.
If one-time methods fail or are beyond reach, the adversary has to resort to persistent machine compromise to retain access to node key material.
The APT attacker can use the same vector as #1 or perhaps an external vector such as daemon compromise, but they then must also plant a backdoor that would do something like trawl through the RAM of a machine, sniff out the keys (perhaps even grabbing the ephemeral TLS keys directly), and transmit them offsite for collection.
This is a significantly more expensive position for the adversary to maintain, because it is possible to notice upon a thorough forensic investigation during a perhaps unrelated incident, and it may trigger firewall warnings or other common least privilege defense alarms inadvertently.
I think this attack would be a lot more expensive than motivating the right Debian developers to compromise a significant part of the interesting Tor relays the next time they get updated.
This attack would not only be harder to defend against, it also sounds cool if we call it the apt(8)-based APT attack.
"My" APT could do that, but I assume "yours" can't?
Unfortunately, it is also a more expensive attack to defend against, because it requires extensive auditing and assurance mechanisms on the part of the relay operator.
I wonder how many relay operators are even motivated to protect against a highly capable attacker. For example "my" APT is unlikely to be after me and a compromise of my (or any other) relays is unlikely to significantly affect me personally.
While I'm not intentionally using an insecure system configuration and I don't expect my relays to be less secure than the average relay, I certainly expect them to be less secure than the system I'm using to write this message.
Defenses
It seems clear that the above indicates that at minimum relays should protect against one-time key compromise. Some further thought shows that it is possible to make the APT adversary's task harder as well, albeit with significantly more effort.
That's not clear to me at all. Are you saying that a relay operator who doesn't want to follow the "minimum" best practices document (once it exists) shouldn't be running a relay (or at least be embarrassed)?
Once you start your tor process(es), you will want to copy your identity key offsite, and then remove it. Tor does not need it to remain on disk after startup, and removing it ensures that an attacker must deploy a kernel exploit to obtain it from memory. While you should not re-use the identity key after unexplained reboots, you may want to retain a copy for planned reboots and tor maintenance.
How often can a relay regenerate the identity key without becoming a burden to the network?
I reused the identity keys after unexplained reboots in the past as I assumed the cost of a new key (unknown to me) would be higher than the cost of a compromise (unknown) multiplied by the likelihood of the occurrence (also unknown to me, but estimated to be rather low compared to other possible reboot causes).
In cases where a reboot is assumed to have been caused by a system compromise, I wouldn't consider merely regenerating the key without re-installing the whole system from known-good media "best practice" anyway.
Ok, that's it. What do people think? Personally, I think that if we can require a kernel exploit and/or weird memory gymnastics for key compromise, that would be a *huge* improvement. Do the above recommendations actually accomplish that?
Are "weird memory gymnastics" really that much more effort than getting the relevant keys through ptrace directly?
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.
I think your proposed measures might be useful for a relay operator with a compatible system who is interested in spending more time on his relay's security than he already is.
It's not clear to me, though, that they improve the security of the Tor network significantly enough to be worth requiring them or even calling them best practices (which could demotivate operators who can't or don't want to implement them).
Trying to require the steps or shaming operators into following them might reduce the number of relay operators (or limit their growth) significantly enough to make the attacks you seem to be concerned about cheaper ...
Having said that, I don't see anything wrong with putting your suggestions in a section that starts with a paragraph like:
| Here are a couple of things you could do to improve your | relay's security some more. Whether or not you consider | them worthwhile is up to you and if you decide against some | or all of them or if they don't work on your system, your | relay is still appreciated.
Even the APT defenses end up not working out, I would sleep a lot better at night if most relays deployed only the defenses to one-time key theft... Thoughts on that?
I'm not too worried about the APT.
Fabian
Thus spake Fabian Keil (freebsd-listen@fabiankeil.de):
Attack Vector #2: Advanced Persistent Threat Key Theft
I assume "your" APT is somehow less capable then "my" APT, but without knowing your definition I can't really tell if the proposed defenses are effective against it.
Adding your definition to the document would help, but personally I would prefer it if the term APT wouldn't be used at all.
I thought I did in the very next paragraphs?
If one-time methods fail or are beyond reach, the adversary has to resort to persistent machine compromise to retain access to node key material.
The APT attacker can use the same vector as #1 or perhaps an external vector such as daemon compromise, but they then must also plant a backdoor that would do something like trawl through the RAM of a machine, sniff out the keys (perhaps even grabbing the ephemeral TLS keys directly), and transmit them offsite for collection.
This is a significantly more expensive position for the adversary to maintain, because it is possible to notice upon a thorough forensic investigation during a perhaps unrelated incident, and it may trigger firewall warnings or other common least privilege defense alarms inadvertently.
I think this attack would be a lot more expensive than motivating the right Debian developers to compromise a significant part of the interesting Tor relays the next time they get updated.
This attack would not only be harder to defend against, it also sounds cool if we call it the apt(8)-based APT attack.
"My" APT could do that, but I assume "yours" can't?
Hrmm. More accurately, your "apt APT" is not an attack against Tor, it's an attack against Debian. I classify that as out of scope. Similarly, attacks against Intel are also out of scope (even though they are quite possible and are even more terrifying). It's simply not our job to defend against them.
Defenses
It seems clear that the above indicates that at minimum relays should protect against one-time key compromise. Some further thought shows that it is possible to make the APT adversary's task harder as well, albeit with significantly more effort.
That's not clear to me at all. Are you saying that a relay operator who doesn't want to follow the "minimum" best practices document (once it exists) shouldn't be running a relay (or at least be embarrassed)?
Note the "should". My claim is that it's clear following from the motivations of the attacker that ephemeral keys are the minimum defense one could take against one-time key theft. They are the simplest thing you can do, and they do secure against that class of attacker.
Once you start your tor process(es), you will want to copy your identity key offsite, and then remove it. Tor does not need it to remain on disk after startup, and removing it ensures that an attacker must deploy a kernel exploit to obtain it from memory. While you should not re-use the identity key after unexplained reboots, you may want to retain a copy for planned reboots and tor maintenance.
How often can a relay regenerate the identity key without becoming a burden to the network?
I reused the identity keys after unexplained reboots in the past as I assumed the cost of a new key (unknown to me) would be higher than the cost of a compromise (unknown) multiplied by the likelihood of the occurrence (also unknown to me, but estimated to be rather low compared to other possible reboot causes).
In cases where a reboot is assumed to have been caused by a system compromise, I wouldn't consider merely regenerating the key without re-installing the whole system from known-good media "best practice" anyway.
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.
Ok, that's it. What do people think? Personally, I think that if we can require a kernel exploit and/or weird memory gymnastics for key compromise, that would be a *huge* improvement. Do the above recommendations actually accomplish that?
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.
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.
I think your proposed measures might be useful for a relay operator with a compatible system who is interested in spending more time on his relay's security than he already is.
It's not clear to me, though, that they improve the security of the Tor network significantly enough to be worth requiring them or even calling them best practices (which could demotivate operators who can't or don't want to implement them).
Did I fail to motivate the defenses? In what way can we establish "more realistic" best practice defenses that are grounded in real attack scenarios and ordered by attack cost vs defense cost? I thought I had accomplished that...
Trying to require the steps or shaming operators into following them might reduce the number of relay operators (or limit their growth) significantly enough to make the attacks you seem to be concerned about cheaper ...
Having said that, I don't see anything wrong with putting your suggestions in a section that starts with a paragraph like:
| Here are a couple of things you could do to improve your | relay's security some more. Whether or not you consider | them worthwhile is up to you and if you decide against some | or all of them or if they don't work on your system, your | relay is still appreciated.
Ok, yes, I have no intention of making anything mandatory. It's not really possible anyways, and heterogeneity probably trumps it.
For the paragraphs I've trimmed, assume I more or less agree with your statements.
Thus spake Mike Perry (mikeperry@torproject.org):
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 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.
Btw, before the above causes someone to jot "Enemy Combatant" down in a file somewhere, I just want to clarify that I believe "lawful intercept" is a total sham, dangerously weakening critical infrastructure for little gain. Once deployed (too late!), it can and will be exploited by a wide variety of actors (too late!).
Also, replace "NSL subpoena" with "any variety of intimidating thugs with guns (and/or money)". They're pretty much the same level of "due process" IMO.
Further, I think we can expect many/most relay operators to run straight to the EFF/ACLU/FBI in the event of coercion (destination depends on adversary). However, I do *not* believe we can expect the same from arbitrary datacenter admins. Hence, I feel that one-time key theft is a valid and realistic adversary, given current weaknesses in the Tor protocol and client software.
Mike Perry mikeperry@torproject.org wrote:
Thus spake Fabian Keil (freebsd-listen@fabiankeil.de):
Attack Vector #2: Advanced Persistent Threat Key Theft
I assume "your" APT is somehow less capable then "my" APT, but without knowing your definition I can't really tell if the proposed defenses are effective against it.
Adding your definition to the document would help, but personally I would prefer it if the term APT wouldn't be used at all.
I thought I did in the very next paragraphs?
Never mind. I assumed it was just an example for one of several attacks the APT might do.
If one-time methods fail or are beyond reach, the adversary has to resort to persistent machine compromise to retain access to node key material.
The APT attacker can use the same vector as #1 or perhaps an external vector such as daemon compromise, but they then must also plant a backdoor that would do something like trawl through the RAM of a machine, sniff out the keys (perhaps even grabbing the ephemeral TLS keys directly), and transmit them offsite for collection.
This is a significantly more expensive position for the adversary to maintain, because it is possible to notice upon a thorough forensic investigation during a perhaps unrelated incident, and it may trigger firewall warnings or other common least privilege defense alarms inadvertently.
I think this attack would be a lot more expensive than motivating the right Debian developers to compromise a significant part of the interesting Tor relays the next time they get updated.
This attack would not only be harder to defend against, it also sounds cool if we call it the apt(8)-based APT attack.
"My" APT could do that, but I assume "yours" can't?
Hrmm. More accurately, your "apt APT" is not an attack against Tor, it's an attack against Debian. I classify that as out of scope. Similarly, attacks against Intel are also out of scope (even though they are quite possible and are even more terrifying). It's simply not our job to defend against them.
I agree that defending against this is out of scope for the Tor project. If it's done with the intention of compromising Tor relay, I'd still count it as an attack against Tor, though.
Once you start your tor process(es), you will want to copy your identity key offsite, and then remove it. Tor does not need it to remain on disk after startup, and removing it ensures that an attacker must deploy a kernel exploit to obtain it from memory. While you should not re-use the identity key after unexplained reboots, you may want to retain a copy for planned reboots and tor maintenance.
How often can a relay regenerate the identity key without becoming a burden to the network?
I reused the identity keys after unexplained reboots in the past as I assumed the cost of a new key (unknown to me) would be higher than the cost of a compromise (unknown) multiplied by the likelihood of the occurrence (also unknown to me, but estimated to be rather low compared to other possible reboot causes).
In cases where a reboot is assumed to have been caused by a system compromise, I wouldn't consider merely regenerating the key without re-installing the whole system from known-good media "best practice" anyway.
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.
Ok, that's it. What do people think? Personally, I think that if we can require a kernel exploit and/or weird memory gymnastics for key compromise, that would be a *huge* improvement. Do the above recommendations actually accomplish that?
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.
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.
I think your proposed measures might be useful for a relay operator with a compatible system who is interested in spending more time on his relay's security than he already is.
It's not clear to me, though, that they improve the security of the Tor network significantly enough to be worth requiring them or even calling them best practices (which could demotivate operators who can't or don't want to implement them).
Did I fail to motivate the defenses? In what way can we establish "more realistic" best practice defenses that are grounded in real attack scenarios and ordered by attack cost vs defense cost? I thought I had accomplished that...
I have no idea.
Fabian
Thus spake Fabian Keil (freebsd-listen@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.
On Sun, Apr 29, 2012 at 1:59 PM, Mike Perry mikeperry@torproject.org wrote:
[snipped]
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...
What do you feel about promoting grsec?
[snipped]
-- Mike Perry
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Thanks, Kasimir
-- Kasimir Gabert
tor-relays@lists.torproject.org
-
Fabian Keil -
Kasimir Gabert -
Mike Perry