[OpenAFS-devel] [GSoC 2010] Encrypted storage
Sanket Agarwal
sanket@sanketagarwal.com
Wed, 31 Mar 2010 13:26:52 +0530
--001485f19a30d3a65e0483141643
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Mar 31, 2010 at 12:21 PM, Sanket Agarwal
<sanket@sanketagarwal.com>wrote:
>
>
> On Wed, Mar 31, 2010 at 9:36 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: 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
>> OpenAFS-devel@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-devel
>>
>
>
--001485f19a30d3a65e0483141643
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br><div class=3D"gmail_quote">On Wed, Mar 31, 2010 at 12:21 PM, Sanket=
Agarwal <span dir=3D"ltr"><<a href=3D"mailto:sanket@sanketagarwal.com">=
sanket@sanketagarwal.com</a>></span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0p=
t 0pt 0.8ex; padding-left: 1ex;">
<br><br><div class=3D"gmail_quote"><div class=3D"im">On Wed, Mar 31, 2010 a=
t 9:36 AM, Tom Keiser <span dir=3D"ltr"><<a href=3D"mailto:tkeiser@sinen=
omine.net" target=3D"_blank">tkeiser@sinenomine.net</a>></span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204=
, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>On Thu, Mar 25, 2010 at 5:44 AM, Simon Wilkinson <<a href=3D"mailto=
:sxw@inf.ed.ac.uk" target=3D"_blank">sxw@inf.ed.ac.uk</a>> wrote:<br>
><br>
> On 25 Mar 2010, at 08:54, Rod Widdowson wrote:<br>
><br>
>>> I'll step back and ask: =A0what's your threat model? =
=A0What are you trying<br>
>>> to protect against?<br>
><br>
> 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 administ=
rator cannot read them. That is, they trust the server to store the data th=
ey give it (and to back it up, etc) but they don't trust it not to eave=
sdrop on those contents, or to not disclose them to a third party.<br>
><br>
> In GSoC, the problem I think is tractable is the single user case, mod=
elled around a user who wishes to encrypt their home directory so that it c=
annot be read without access to their key. In my environment, this is funct=
ionality that is regularly requested. It has the additional benefit that it=
allows some of the harder issues around key management to be deferred.<br>
><br>
<br>
</div>I'll third Derek and Rod's calls for a detailed discussion of=
the<br>
threat model. =A0While this use case is quite compelling, it also raises<br=
>
a number of questions that still feel open to me.<br>
<br>
Is the plan to get the encryption layer working as part of GSoC, while<br>
deferring the issues regarding policy and key management until a later<br>
date</blockquote><div>=A0</div></div><div>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.<br>=A0</div><div>The first thing for th=
e 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 t=
he Crypto API into at the Kernel level rather than using rich User Mode lib=
raries like OpenSSL etc, which can be used at the Client[ Cache Manager ] s=
ide.<br>
<br>The second task would be to get the Encryption Layer working.<br>File e=
ncryption would be targeted as of now. In order to encrypt the Directory St=
ructure, server's support shall be necessary. As I have to technically =
complete the sated project within 3 months( I will obviously continue to co=
ntribute :) ), I cannot form astronomical proposals!<br>
=A0<br></div><div><div></div><div class=3D"h5"><blockquote class=3D"gmail_q=
uote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0=
pt 0.8ex; padding-left: 1ex;">The reason I ask is it seems that a particula=
rly hard part of<br>
this problem, in addition to those issues broached by Derek and Rod,<br>
is going to be policy enforcement.<br>
<br>
For example, if we stipulate that specific volume IDs or FIDs are<br>
encrypted, how are we going to protect against malicious servers<br>
performing security downgrade attacks via policy metadata spoofing?<br>
I'll certainly grant that feeding the file server ciphertext is an<br>
excellent step in the right direction; will the new threat model<br>
address casual attackers, while explicitly side-stepping active<br>
attackers who attempt downgrade attacks?<br>
<br>
My core concern is that the AFS security model has always assumed that<br>
servers are trustworthy. =A0It seems inevitable that we must change that<br=
>
model (e.g. rxgk departmental servers). =A0However, I think we need to<br>
be careful about thinking through the implications of these changes.<br>
For example, changing the trustworthy server assumption has<br>
potentially far-reaching implications for other ongoing development<br>
efforts (e.g. XCB, cooperative caching, ...).<br>
<br>
I think others have brought up some of the following before. =A0For<br>
completeness, I'll note that I think we eventually need to discuss:<br>
<br>
* data key lifetime/byte lifetime/key rotation/byte range keys(?)<br>
* if file data keys are not immutable, cache coherence concerns<br>
* would it be worthwhile to also support checksumming/HMACs?<br>
* finding a good, extensible, performant means of storing the keys as metad=
ata<br>
* what, if any, block chaining modes are acceptable (and associated<br>
implications on chunk size and protocol semantic changes to enforce<br>
writes along block boundaries)<br>
* key escrow<br>
* required volume dump format changes (or are we considering that a<br>
separable xattr issue?)<br>
* do we need to address directory objects?=A0<br></blockquote><blockquote c=
lass=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); ma=
rgin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Cheers,<br>
<font color=3D"#888888"><br>
-Tom<br>
</font><div><div></div><div>_______________________________________________=
<br>
OpenAFS-devel mailing list<br>
<a href=3D"mailto:OpenAFS-devel@openafs.org" target=3D"_blank">OpenAFS-deve=
l@openafs.org</a><br>
<a href=3D"https://lists.openafs.org/mailman/listinfo/openafs-devel" target=
=3D"_blank">https://lists.openafs.org/mailman/listinfo/openafs-devel</a><br=
>
</div></div></blockquote></div></div></div><br>
</blockquote></div><br>
--001485f19a30d3a65e0483141643--