"Zooko O'Whielacronx" <[email protected]> writes: > On Thu, Feb 3, 2011 at 8:20 AM, Greg Troxel <[email protected]> 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.
pgpVRdjXjTted.pgp
Description: PGP signature
_______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
