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

[Greg Troxel]

"Zooko O'Whielacronx" <zooko at zooko.com> writes:

> 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 think it's a very important threat model, second only to "my computer
is ok, the cloud is not"

> 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.

I agree that it would not be hugely difficult to achieve, and definitley
not architecturally challenging.

> 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.")

Sure, or encrypt swap with a per-boot rnadom key.  IMHO it's ok for
tahoe to punt on this area.

> 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? :-)

Sure.  My list for fixing is:

  something like gpg-agent or ssh-agent for storing caps.  Or perhaps
  store encryped in gpg and use gpg to decrypt, avoiding the work
  (optional of course).

  spiff up CLI so that people who have a mild preference for CLI over
  GUI have *no reason* to want to interact with the WUI, other than
  maybe looking at a status page (and entering no information)

  [tempdir as you say; I don't understand that yet]

I think that gets us most of the way there.

> 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

Sure, that's Level 4 of the Paranoia Maturity Model, developed at SEI
during the heyday of the Cold War.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20110204/2a74cea0/attachment.pgp>