[tahoe-dev] protecting caps

[Joseph Ming]

The opposite question is also relevant I think: what extra precautions does tahoe take to protect the user from losing their root cap? If I understand the design correctly, without the root cap (or access to some stored cap somewhere) the user won't be able to access any of their data (or the portion of their data for which they don't have caps).

Assuming I store everything in tahoe and never share my caps with anyone else and then my harddisk where my cap was stored dies is stolen etc., have I lost everything? Is there some other way to try to recover my data, maybe by scouring all nodes involved in storing it for caps that belong to me?

Are users encouraged to save a copy of their root cap somewhere other than their harddrive? Is there any mechanism to help the user do something like that?

Joseph


________________________________
From: Greg Troxel <gdt at ir.bbn.com>
To: Joseph Ming <josephming at ymail.com>
Cc: "tahoe-dev at tahoe-lafs.org" <tahoe-dev at tahoe-lafs.org>
Sent: Monday, August 1, 2011 5:20 PM
Subject: Re: [tahoe-dev] protecting caps


Joseph Ming <josephming at ymail.com> writes:

> This might be an amateur question but how does tahoe protect caps once
> used by clients?
>
> By that I mean that it seems like if I wanted to attack a tahoe user,
> the easiest way in would be to try to capture someone's root
> read-write cap. That is stored locally on all that user's clients?
> What does tahoe do to protect that data? I looked at the android
> client and see that it gets stored as a resource. I believe resources
> are siloed away on that platform from other processes so it should be
> safe assuming the device hasn't been rooted or have apps that get in
> through a security hole in the platform, and that it doesn't fall into
> the wrong physical hands. Most mainstream OSes don't silo in the same
> way, so any process run by a user might be able to access that value
> if it is stored in a file right? So maybe my attack vector would be to
> get a piece of malicious software installed alongside tahoe, to try to
> pick off that cap value and send it to me?
>
> I've seen the criticism of using the web interface for the same reason
> http://www.lexort.com/blog/tahoe-lafs.html#sec-4_1. Is that valid? If
> so, that's an even bigger hole, but I'm not worried about that
> one. It's easy to avoid using the browser as an interface to tahoe.

It's a fair question that has not had extensive discussion.

The prevailing notion is that clients are trustworthy and storage
servers are untrusted.  Of course, people realize that this might not
match everyone's threat models - but it seems to be the most-common
threat model.

It's hard to imagine a filesystem that could safely make files available
on untrustworthy clients.  (One could do something like use time-limited
tokens to make read/write only last some number of hours, but that
doesn't remove access during enabled times.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20110801/2636bdc7/attachment.html>