On 13 August 2013 11:51, Steve Snyder swsnyder@snydernet.net wrote:

Well, any VM host can mount and read an unencrypted disk image.

I guess the difference is ease of snooping. While access to disk contents and process info can be gotten by any hypervisor, some platforms make it easier than others.

Exactly, that's the name of the game here. Let's raise the bar. (Same with censorship bypassing - it's always going to be an arms race.)

What one person I respect does is

In my case, I keep all the keys and [other sensitive data] on a partition that's created with a random key at boot time. If the machine dies, the keys and messages are lost but, such is the reliability of Debian, this hasn't happened yet. I probably reboot about once a year on average and have to remember to take copies of these files prior to doing it.

So the hypervisor can, as always, look into the memory* of the running guest and get that data, but if they shut down the node or machine unexpectedly, you gain a little bit more security.

All that said... Tor nodes don't store state. You aren't keeping people's email, or even a pool of data for a couple of hours. So this level of security for a tor exit node is nice, but IMO you shouldn't _not_ do an exit node because you aren't ready to set up a complicated encrypted filesystem just yet.

-tom

* Steve Weis is a cryptographer who's working on a (commercial) product that encrypts memory. http://privatecore.com/

On Tue, Aug 13, 2013 <various_people> wrote:

VPS, containers, dedicated, encrypted disk, whatever... it's all the same, the filesystem and bits on disk, particular when running, are exposed to whoever is holding the box. Since it's not your box in your DC where you stand guard 24x7, nor have you audited Tor against remote exploit, all bets regarding the Tor keys are void.

That said, reasonable gains to the limit of what tpo could do: I've suggested that the controller be enhanced so that you can add/drop/mod the controller access token and Tor keys directly to a Tor in standby mode without ever requiring disk. Some modes of node deployment/use are disposable anyway so just autogenerate them and never write them out in that case.

It's better than most people's weak passphrase on a disk based Tor key (not yet possible either) or cryptdisk would be. And better than FS mounted ramdisk too. Yet there's still dump memory or cold boot, but it's harder and not immediately obvious as being necessary to do.

privatecore.com? Userland requires cleartext. At the app level you could have the equivalent of the user kernel doing encryption within its malloc(3/9), as with zeroing/randomizing today. And if the hypervisor is doing it above and for the user kernel, then the whole per VM space under that is internally accesible. Depending on what parts of the system are exploited you could get some protection against trolling the ram of other containers through non-zeroed ram and top level dumb dma/cold dumps, excluding the encryption buffers. But that's probably it. And it won't be fast. They don't have publicly posted whitepapers. Its software and could be reimplemented by opensource projects.

Ultimately, if you don't own the entire physical and logical path to your app, you can't trust it.