Re: so how do *you* manage your keys, then? part 3
[added Cc: tahoe-...@allmydata.org, and I added ke...@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
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
so how do *you* manage your keys, then? part 3
So How Do You Manage Your Keys Then, part 3 of 5 In part one of this series [1] I described how Tahoe-LAFS combines decryption, integrity-checking, identification, and access into one bitstring, called an "immutable file read-cap" (short for "capability"). In part two [2] I described how users can build tree- like structures of files which contain caps pointing to other files, and how the cap pointing to the root of such a structure can reside on a different computer than the ciphertext. (Which is necessary if you want someone to store the ciphertext for you but you don't want to give them the ability to read the file contents.) In this installment, consider the question of whether you can give someone a cap (which acts as a file handle) and then change the contents of the file that the cap points to, while preserving their ability to read with the original cap. This would be impossible with the immutable file read-caps that we have been using so far, because each immutable file read cap uses a secure hash function to identify and integrity-check exactly one file's contents -- one unique byte pattern. Any change to the file contents will cause the immutable file read-cap to no longer match. This can be a desirable property if what you want is a permanent identifier of one specific, immutable file. With this property nobody -- not even the person who wrote the file in the first place -- is able to cause anyone else's read-caps to point to any file contents other than the original file contents. But sometimes you want a different property, namely that an authorized writer *can* change the file contents and readers will be able to read the new file contents without first having to acquire a new file handle. To accomplish this requires the use of public key cryptography, specifically digital signatures. Using digital signatures, Tahoe- LAFS implements a second kind of capability, in addition to the immutable-file capability, which is called a "mutable file capability". Whenever you create a new mutable file, you get *two* caps to it: a write-cap and a read-cap. (Actually you can always derive the read-cap from the write-cap, so for API simplicity you get just the write-cap to your newly created mutable file.) 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. The decryption and signature verification both happen automatically whenever you read data from that file handle (it downloads the digital signature which is stored with the ciphertext). Possession of the write-cap gives two things: the symmetric key with which you can encrypt the ciphertext, and the private key with which you can sign the contents. Both are done automatically whenever you write data to that file handle. The important thing about this scheme is that what we crypto geeks call "key management" is almost completely invisible to the users. As far as the users can tell, there aren't any "keys" here! The only objects in sight are the file handles, which they already use all the time. All users need to know is that a write-cap grants write authority (only to that one file), and the read-cap grants read authority. They can conveniently delegate some of their read- or write- authority to another user, simply by giving that user a copy of that cap, without delegating their other authorities. They can bundle multiple caps (of any kind) together into a file and then use the capability to that file as a handle to that bundle of authorities. At least, this is the theory that the object-capability community taught me, and I'm pleased to see that -- so far -- it has worked out in practice. Programmers and end users appear to have no difficulty understanding the access control consequences of this scheme and then using the scheme appropriately to achieve their desired ends. Installment 4 of this series will be about Tahoe-LAFS directories (those are the most convenient way to bundle together multiple caps -- put them all into a directory and then use the cap which points to that directory). Installment 5 will be about future work and new crypto ideas. Regards, Zooko [1] http://allmydata.org/pipermail/tahoe-dev/2009-August/002637.html # installment 1: immutable file caps [2] http://allmydata.org/pipermail/tahoe-dev/2009-August/002656.html # installment 2: tree-like structure (like encrypted git) - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
