Am 29/06/2010 08:15 μμ, schrieb Tobias Hunger: [...] > There are proposals on encrypted storage in the owncloud wiki, covering (parts > of) this. Please comment on them!
OK, some thoughts on the first encrypted file storage proposal. First wrt key management. I think there should be different key pairs for different sets of data, so that the damage is contained when one secret key is compromised. One of my requirements would be to be able to access (pre-designated) parts of my data from machines that I don't necessarily trust. In that case, if the value of the data is such that I'd be willing to risk someone getting access to my key in order to access that data *now*, I could make that tradeoff more easily. In addition, the server could enforce stricter limitations on the kind of access that I'd have (say, on access time, volume of data transferred, allowed operations etc). In addition you would be able to specify different expiration times for the keys (I'm assuming you're also using the keypair for authentication purposes so that when it expires one wouldn't have access to the data without breaking into the server;). This is all in order to minimize the value of the key (which, given the nature of the data one would typically store in an owncloud instance, is already very low to begin with). On a tangent, the reason we're using encryption here is to defend against the server administrator and random people who might break into the server. It is possible that they would be specifically after the owncloud data (especially someone breaking in a large hosting provider), but our threat model is not a determined opponent who is targeting any individual user; there are way more cost-effective ways to get to the data of an individual. If one trusts the server enough to store their data unencrypted, it is easy enough to also use one-time passwords (again, with additional limitations) for access from untrusted machines. I've argued in a previous mail that it is important that the user identity is connected with a keypair instead of a URL to allow for (semi-)transparent migration to different servers. This keypair would be the master keypair with which the other keypairs are signed. Now, for that keypair, you really want it to only be used from a trusted client. Writing a standalone client is conceptually straightforward, but involves some administrative overhead. I'd definitely want to use one, but a complementary approach might be to make use of a javascript-heavy webpage to provide a cross-platform client that is always available, has little dependency issues and is always automatically upgraded to the latest version. This would of course require the user to be able to verify that the code the server sent them actually corresponds to the latest version of the publically-reviewed code. Now, the best way I can think of to do that is to have the (trusted) browser display a hash of all the page content and publish that hash on many places on the net. I started searching around a bit and it seems that (naturally) somebody has started exploring that direction, including a prototype of a firefox extension: http://corte.si/posts/security/crypsr-evolution.html (see the previous blog posts as well). Now, as for the issues of (public, which also implies unencrypted) object propagation, it is seems to me that the storage model would be very similar to the git content repository, right up to using signed tags. In fact, one could probably argue that git is 90% there already and could be used as is, possibly with the addition of a simple layer on top of blobs for meta-information. I don't see propagation of encrypted objects as something desireable at this point; it would be useful if you had large, closed (invitation only or centrally managed) user groups (say, for collaboration) but there you have much more important issues with diverging versions of objects that we'd have to talk about first. My approach would probably be to only act as a rendezvous point for application-specific protocols. Anyway, most of you are probably at Akademy and these are more notes to myself than a complete proposal, but I'd be happy to read any comments that you might have. Thanks, Aggelos _______________________________________________ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
