[OpenAFS-devel] [GSoC 2010] Encrypted storage

[Derrick Brashear]

On Wed, Mar 31, 2010 at 12:06 AM, Tom Keiser <tkeiser@sinenomine.net> wrote=
:
> 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 t=
rying
>>>> 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 =
cannot read them. That is, they trust the server to store the data they giv=
e it (and to back it up, etc) but they don't trust it not to eavesdrop on t=
hose contents, or to not disclose them to a third party.
>>
>> In GSoC, the problem I think is tractable is the single user case, model=
led around a user who wishes to encrypt their home directory so that it can=
not be read without access to their key. In my environment, this is functio=
nality that is regularly requested. It has the additional benefit that it a=
llows 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. =A0While this use case is quite compelling, it also raises
> a number of questions that still feel open to me.

Assuming I as an end user don't want the server admin to have access
to my data, what's a detailed way to express that?

Yes, that sounds excessively snarky. But during the time that I was
one, that was a question I got.
"Can you see my files?"
"Yes"

> 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? =A0The 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?

If this is a case of the user specifying that they with their data
encrypted, e.g. a user-activated function rather than an
admin-activated function, the policy engine would seem to be "I tell
my client to encrypt (some subset of) my files". If you have access to
my client, you can downgrade me. If you have access to my client, I
have already lost.

> 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. =A0It seems inevitable that we must change that
> model (e.g. rxgk departmental servers). =A0However, 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 don't think I'd want to use *this* project to address the
departmental fileserver problem. At all, in fact.

> I think others have brought up some of the following before. =A0For
> completeness, I'll note that I think we eventually need to discuss:
>
> * data key lifetime/byte lifetime/key rotation/byte range keys(?)

I think this can be deferred, because:

> * if file data keys are not immutable, cache coherence concerns

If you rekey, you are responsible for rewriting the file back to disk.
Old DV data is now stale, and no new code is require.

> * would it be worthwhile to also support checksumming/HMACs?

-only, e.g. clear payload?

> * finding a good, extensible, performant means of storing the keys as met=
adata
> * what, if any, block chaining modes are acceptable (and associated
> implications on chunk size and protocol semantic changes to enforce
> writes along block boundaries)

(agreed)

> * key escrow

none. my client my data.

> * required volume dump format changes (or are we considering that a
> separable xattr issue?)

i'd think so.

> * do we need to address directory objects?

i'd propose not.



--=20
Derrick