[tahoe-dev] So how do *you* manage your keys, then? Re: cleversafe says: 3 Reasons Why Encryption isOverrated

[Shawn Willden]

On Tuesday 18 August 2009 01:03:42 am Jason Resch wrote:
> Users of Tahoe-LAFS are faced with a difficult choice:
>
> 1. Keep data highly confidential, by not making copies of the identifiers
> 2. Keep data highly reliable, by replicating the identifiers

It is certainly possible, and not even terribly difficult, to have both good 
confidentiality and high reliability.  The approach I use is to have two 
copies.  One is my "working" copy, which is as secure as my computer -- and 
exactly as secure as my data would be if I didn't use Tahoe's "cloud" 
storage.  If I want to make my working copy more secure, I can put it in an 
encrypted, password-protected container, and enable privacy mode on my 
browser before using it (so the browser doesn't cache the results).  The 
other is my "backup" copy, which is on a piece of paper in a safe deposit 
box, along with other important papers.

A more sophisticated approach could use an information theoretically-secure 
m-of-n splitting operation to provide a backup with very high reliability and 
very high confidentiality.  Hmm...  In fact, that would be a useful tool for 
Tahoe to provide -- generating the URI shares, I mean.  Share storage could 
then be handled by whatever means the user deems appropriate, including 
pieces of paper distributed to trustworthy people (I'm a big fan of 
paper-based key management for non-geeks, because people already know how to 
secure important papers).

More importantly, I fail to see how Tahoe's approach is fundamentally 
different in this regard from Cleversafe's.  It seems to me that whatever 
authentication credential is used with Cleversafe has very nearly the same 
confidentiality/availability tradeoff as a Tahoe URI.  The one advantage 
Cleversafe has is that the authenticator could be memorizable, but if it is 
memorized, it has all the well-known disadvantages inherent to passwords.  In 
particular, the reliability of human memory is often poor, which may 
necessitate a password reset process which creates additional security 
vulnerabilities, and of course the confidentiality provided is limited by 
what might be memorized.

On the positive side for Cleversafe, username/password management is a 
thoroughly-understood if not fully solvable problem.  Management of Tahoe 
caps is less well-understood.

On the negative side for Cleversafe, as has been discussed, an attacker who 
can gain control of sufficient storage servers can bypass the authentication 
system entirely.  This is a weakness that Tahoe-LAFS does not have; as long 
as your uploads/downloads are done through a Tahoe node that you control, you 
don't have to worry about the security of the rest of the grid.

> While secret sharing schemes are the ideal method for key storage,
> Tahoe-LAFS doesn't provide this feature and given its current design,
> cannot support it.  To have a secret sharing system, there must be some
> way to authenticate those who request shares.

Authentication is not necessary for secret sharing, unless the shares are 
stored in some centralized (if distributed) system.  In decentralized secret 
sharing, possession of the share is all that is required.

> There is flexibility in having a separate key for each file but it also
> means one needs to take the time to make backups of the newly generated
> keys following each upload session.  Although I suppose if one restricts
> uploads to children of directories whose key is already backed up this
> step can be avoided.  Is that correct?

Yes.  A common approach with Tahoe-LAFS is to make a "root" directory and find 
a way to securely manage the URI of that directory, then place everything 
else in a tree under that.  If there's a desire to segment the stored data 
into multiple security levels, entirely separate trees may be used (and their 
URIs individually backed-up), or lower-security subtrees may be embedded into 
a higher security tree, with their keys backed up in a less secure manner.  
Possession of the high-security key allows transitive access to the 
lower-security subtree, or possession of the lower-security key allows direct 
access to the subtree.

Also, files and directories may be linked into multiple directories, so a 
nominally high-security tree and a nominally low-security tree may share 
common files or directories.

All of this does push the security onto the user, but the result is a very 
flexible framework that allows sophisticated users to construct a wide 
variety of security structures.  For less sophisticated users, the 
recommended policy is simple:  put everything under a single root, print out 
a copy of that URI and put it somewhere safe (or multiple safe locations).  
If you want, you can also memorize part of the URI and omit that from your 
printed copies.  If I needed to store files related to illegal or subversive 
activities or something, that's the approach I'd take.

> How is the immutability enforced?  In particular it isn't clear to me
> how a write-cap allows one to update a file, is this something the
> servers check via a digital signature or HMAC on updated data?

For immutable files, immutability is inherent because the decryption key and 
storage ID are derived by hashing the file content.  If you "change" the 
file, it's a different file (modulo hash collisions).  Note that immutable 
files do not use PK, just a symmetric cipher and a secure hash function.

For mutable files, the shares are versioned.  Uploading a new version means 
storing shares with a higher version number than previously used.  
Downloading a mutable file means downloading a set of shares with the 
highest-available version number.  The shares are signed with a private key 
to ensure that an attacker may not fake shares.  The private key is encrypted 
with a hash of itself and stored with each share.  The key used to encrypt 
the private key is called the "write key".  The write key is hashed to create 
the "read key".  The read key is hashed to create the "storage ID", which is 
the file's identifier in the system (its 'inode', if you will).  The public 
key (aka the "verification key") is stored with the share, unencrypted so 
that storage servers can validate the share signature.

The write cap contains the write key and the verification key hash.
The read cap contains the read key and the verification key hash.
The verify cap contains the storage ID and the verification key hash.

> The freedom for the user to use anything is a double-edged sword.  Those
> having the right resources, infrastructure and know-how may be able to
> store their keys in an extremely reliable and secure manner, but the
> average user with less expertise or equipment may be left with a less
> than ideal system for securing keys.  The advantage of Tahoe-LAFS
> approach is that its upper-bound for key management can be as high as
> one is willing to make it, because it is not defined.  The downside is
> that the lower-bound can also be as low as one allows.

This is true.  On the other hand, I find that even non-technical people are 
very comfortable with managing the security of their URIs, for two reasons.  
First, the recommendation is for them to use a single root for everything, so 
they only have a single key to manage.  Second, I tell them to print out a 
copy of this root URI and then treat it like a physical key to a safe.  
Although a URI is easier to copy than a physical key, most people have had 
copies of keys made and understand that it's not safe to leave important keys 
lying around.

	Shawn.