On Wed, Mar 31, 2010 at 12:21 PM, Sanket Agarwal <[email protected]>wrote:
> > > On Wed, Mar 31, 2010 at 9:36 AM, Tom Keiser <[email protected]>wrote: > >> On Thu, Mar 25, 2010 at 5:44 AM, Simon Wilkinson <[email protected]> >> wrote: >> > >> > On 25 Mar 2010, at 08:54, Rod Widdowson wrote: >> > >> >>> I'll step back and ask: what's your threat model? What are you >> trying >> >>> 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 give >> it (and to back it up, etc) but they don't trust it not to eavesdrop on >> those contents, or to not disclose them to a third party. >> > >> > In GSoC, the problem I think is tractable is the single user case, >> modelled around a user who wishes to encrypt their home directory so that it >> cannot be read without access to their key. In my environment, this is >> functionality that is regularly requested. It has the additional benefit >> that it allows 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 > > > Simon would be a better person to what should and what should not be a part > of the GSoC proposal. But, as of now I think it should be deferred. > > The first thing for the project would be to integrate HCrypto into OpenAFS > and provide an API for future use at a Kernel Level. As Simon envisions, it > is necessary to put the Crypto API into at the Kernel level rather than > using rich User Mode libraries like OpenSSL etc, which can be used at the > Client[ Cache Manager ] side. > > The second task would be to get the Encryption Layer working. > File encryption would be targeted as of now. In order to encrypt the > Directory Structure, server's support shall be necessary. As I have to > technically complete the sated project within 3 months( I will obviously > continue to contribute :) ), I cannot form astronomical proposals! > > >> 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 >> metadata >> * 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 >> _______________________________________________ >> OpenAFS-devel mailing list >> [email protected] >> https://lists.openafs.org/mailman/listinfo/openafs-devel >> > >
