[OpenAFS-devel] [GSoC 2010] Encrypted storage

[Tom Keiser]

On Thu, Mar 25, 2010 at 5:44 AM, Simon Wilkinson <sxw@inf.ed.ac.uk> wrote:
>
> On 25 Mar 2010, at 08:54, Rod Widdowson wrote:
>
>>> I'll step back and ask: =A0what's your threat model? =A0What are you tr=
ying
>>> to protect against?
>
> The threat model is pretty clear, I think. It's for an environment where =
users want to be able to store files in a way that a server administrator c=
annot read them. That is, they trust the server to store the data they give=
 it (and to back it up, etc) but they don't trust it not to eavesdrop on th=
ose contents, or to not disclose them to a third party.
>
> In GSoC, the problem I think is tractable is the single user case, modell=
ed around a user who wishes to encrypt their home directory so that it cann=
ot be read without access to their key. In my environment, this is function=
ality that is regularly requested. It has the additional benefit that it al=
lows some of the harder issues around key management to be deferred.
>

I'll third Derek and Rod's calls for a detailed discussion of the
threat model.  While this use case is quite compelling, it also raises
a number of questions that still feel open to me.

Is the plan to get the encryption layer working as part of GSoC, while
deferring the issues regarding policy and key management until a later
date?  The reason I ask is it seems that a particularly hard part of
this problem, in addition to those issues broached by Derek and Rod,
is going to be policy enforcement.

For example, if we stipulate that specific volume IDs or FIDs are
encrypted, how are we going to protect against malicious servers
performing security downgrade attacks via policy metadata spoofing?
I'll certainly grant that feeding the file server ciphertext is an
excellent step in the right direction; will the new threat model
address casual attackers, while explicitly side-stepping active
attackers who attempt downgrade attacks?

My core concern is that the AFS security model has always assumed that
servers are trustworthy.  It seems inevitable that we must change that
model (e.g. rxgk departmental servers).  However, I think we need to
be careful about thinking through the implications of these changes.
For example, changing the trustworthy server assumption has
potentially far-reaching implications for other ongoing development
efforts (e.g. XCB, cooperative caching, ...).

I think others have brought up some of the following before.  For
completeness, I'll note that I think we eventually need to discuss:

* data key lifetime/byte lifetime/key rotation/byte range keys(?)
* if file data keys are not immutable, cache coherence concerns
* would it be worthwhile to also support checksumming/HMACs?
* finding a good, extensible, performant means of storing the keys as metad=
ata
* what, if any, block chaining modes are acceptable (and associated
implications on chunk size and protocol semantic changes to enforce
writes along block boundaries)
* key escrow
* required volume dump format changes (or are we considering that a
separable xattr issue?)
* do we need to address directory objects?

Cheers,

-Tom