[tahoe-dev] can the disk be used securely to manage your data? Re: Tahoe-LAFS is widely misunderstood

[Zooko O'Whielacronx]

On Thu, Feb 3, 2011 at 8:20 AM, Greg Troxel <gdt at ir.bbn.com> wrote:
>
> In many ways this is the only sane position, but there's a big
> difference between "this machine doesn't have a keylogger" and "my caps
> are on this machines backup tapes".
...
> So a valid attack would be:
>
>  get control of a computer on which someone has used tahoe in the past
>  (accessing the WUI with a browser), and get at their files.

Never write sensitive information (including passwords, caps, secret
file contents, and other secrets) to disk -- treat memory as trusted
but disk as untrusted. This is a valid threat model for some people,
but not one that we've been trying to meet.

I currently think that it is mostly orthogonal to the rest of
Tahoe-LAFS. For example you could implement it by not using the WUI
and by encrypting your caps using GPG, I guess. (Or perhaps you can
use Firefox as you put it on a read-only partition so that it can't
write your secrets to that untrustworthy disk.)

You might also need to configure the "tempdir" (see
docs/configuration.rst) to be a RAM disk or something.

Of course there is the problem of the process's memory being written
to swap. Some crypto tools go to some effort to lock certain pages and
tell the operating system those pages can't be swapped, and to make
sure that all their most sensitive secrets are kept there and are
zeroed out as soon as they are no longer needed. Much easier would
probably be to turn off swap! :-) (I do that anyway. "Swap: an idea
whose time has come and gone.")

Shall we open issue tickets to track our progress on (a) documenting
this pattern of use, and (b) fixing any problems or adding any
features that it needs? :-)

Regards,

Zooko

P.S. Once we've nailed this one then we can move on to the "cold boot
attack" world in which RAM is also untrusted! (Tahoe-LAFS contributor
Jacob Appelbaum was one of the authors of that attack.) It turns out
to be theoretically possible to do useful work in that threat model,
relying on the confidentiality of your registers but not your RAM.
Also you can bet that the RAM will leak only *some* of its information
to the attacker and do tricks like take the secure hash of a lot of
the RAM in order to generate your secret. Not sure how practical these
defenses are...

http://citp.princeton.edu/pub/coldboot.pdf