[tahoe-dev] so how do *you* manage your keys, then? part 3

[Zooko Wilcox-O'Hearn]

[added Cc: tahoe-dev at allmydata.org, and I added kevin at guarana.org on  
the whitelist so his posts will go through to tahoe-dev even if he  
isn't subscribed]


On Tuesday,2009-09-08, at 5:54 , Kevin Easton wrote:

>> Possession of the read-cap to the mutable file gives you two  
>> things: it gives you the symmetric encryption key with which you  
>> decrypt the file contents, and it gives you the public key with  
>> which you check a digital signature in order to be sure that the  
>> file contents were written by an authorized writer.
>
> How do you prevent someone possessing the read-cap for a mutable  
> file from rolling the file back to an earlier version that they  
> have seen, without the consent of the write-cap possessor(s)?

You don't even need a read-cap to perform a roll-back attack -- if  
you can control the ciphertext that the reader gets, then you can  
give them a copy of an older ciphertext, even if you yourself are  
incapable of decrypting it.  This is a difficult attack to defend  
against.  In the current version of Tahoe-LAFS we already have one  
interesting defense -- we the reader is communicating with many  
different servers, and if *any* of the servers is honest and up-to- 
date and informs the reader about the existence of a newer version,  
then the reader knows that the older version that he can read is not  
the latest.  Readers in Tahoe-LAFS always download shares of the file  
from multiple servers, and all of the servers that it uses would have  
to agree on the version number.  Therefore, to perform a rollback  
attack you need to control at least that many servers as well as you  
have to control or deny-access-to any other servers which the reader  
would query and which would inform him about the newer version  
number.  See section 5 of [1].

Does that answer your question about rollback?

It would be interesting to build stronger defenses against rollback  
attack.  For starters, if the same reader reads the same file  
multiple times and gets new contents each time, he might as well  
remember the version number so that he will detect whether that file  
rolled back during his inspection of it.  Also, it would be  
interesting if a file handle to a mutable file included the version  
number that the mutable file was at when the file handle was  
created.  Building on that, it would be really cool if, in a future  
version of Tahoe-LAFS, we could make it so that you can take a cheap  
snapshot of the current contents and then give someone a file-handle  
which *both* securely identified "the most recent version that you  
can find of this file" and *also* "the specific (immutable) version  
of this file that existed when I created this file-handle".


> Also, am I correct in assuming that once write-caps have been  
> distributed, they cannot be revoked, and a new file handle must be  
> created?


Currently, yes.  An improvement that I would like to make in the next  
version of Tahoe-LAFS is to allow the holder of a write-cap to revoke  
it.  While some kinds of revocation are tantamount to DRM ("Digital  
Restrictions Management") and seem to be sufficiently difficult that  
we're not even going to try to implement them, the specific kind of  
revocation that you asked about seems to be quite doable.  Also, it  
happens to be the kind of revocation that I have already wanted for  
my own personal use of Tahoe-LAFS (to host my blog).  :-)

Here is a letter about that which explains why I needed this and how  
I envision it working: [2]


Stronger defenses against rollback attack, and revocation of write- 
caps -- these are only a few of the many possible extensions to the  
Tahoe-LAFS secure storage design.  We have a rich library of such  
designs documented on our issue tracker and our wiki.  We are  
currently having a detailed design discussion on the tahoe-dev list  
to which several cryptographers are contributing [e.g. 3, 4].  The  
primary goal for the next version of Tahoe-LAFS caps is to reduce the  
size of the caps and improve performance, but we're also cataloguing  
new features such as these to see if we can work them in.  Here is  
the wiki page where we're keeping our notes: [5].

If any smart cryptographer or hacker reading this wants to create  
secure, decentralized storage, please join us!  We could use the  
help!  :-)

Regards,

Zooko

[1] http://allmydata.org/~zooko/lafs.pdf
[2] http://allmydata.org/pipermail/tahoe-dev/2009-June/001995.html
[3] http://allmydata.org/pipermail/tahoe-dev/2009-July/002345.html
[4] http://allmydata.org/pipermail/tahoe-dev/2009-September/002808.html
[5] http://allmydata.org/trac/tahoe/wiki/NewCapDesign