[Owncloud] Scaling considerations

[Aggelos Economopoulos]

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