[OpenAFS-devel] [GSoC 2010] Encrypted storage

Wed, 31 Mar 2010 22:36:05 -0400

This is a cryptographically signed message in MIME format.

--------------ms030602010501090703000309
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 3/31/2010 3:56 AM, Sanket Agarwal wrote:
>=20
>=20
> On Wed, Mar 31, 2010 at 12:21 PM, Sanket Agarwal
> <sanket@sanketagarwal.com <mailto:sanket@sanketagarwal.com>> wrote:
>=20
>     Simon would be a better person to what should and what should not b=
e
>     a part of the GSoC proposal. But, as of now I think it should be
>     deferred.

If the result of this project is meant to be an architectural change
to the OpenAFS cache manager then by all means the full membership
of this list has the right to propose suggestions and discuss their
concerns.  However, it must be kept in mind that this project proposal
is for a GSoC project and as such the scope must be reasonable.

Simon, as the person that proposed the project, should be the one
to explain what his intentions were with regards to the GSoC goals.

>     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 OpenSS=
L
>     etc, which can be used at the Client[ Cache Manager ] side.

I suspect that this work has already been done by Simon as part of the
rxgk work.  I do not think this should be in scope for a GSoC project.

>     The second task would be to get the Encryption Layer working.
>     File encryption would be targeted as of now. In order to encrypt th=
e
>     Directory Structure, server's support shall be necessary. As I have=

>     to technically complete the stated project within 3 months( I will
>     obviously continue to contribute :) ), I cannot form astronomical
>     proposals!

Spenser Olsen replied in another response to this thread that he
believes that EncFS would provide equivalent functionality to this
proposed project when overlaid on top of /afs.  In a sense, EncFS is an
excellent comparison to this project proposal.  The functionality is
essentially the same.  The difference is that EncFS, being a FUSE file
system, is only available on a subset of the platforms that OpenAFS
supports.  One of the strengths of OpenAFS is that once data is stored
on Linux it can also be accessed or modified on Solaris, Windows, MacOS,
and many other file systems.  One way of describing this project would
be to implement EncFS as part of the OpenAFS cache manager.

If the goal of this project was to eventually produce a broader
cross-platform multi-user key management system, then I think that
architecture work would have to be developed and agreed to by the
community before a portion of its implementation can be submitted as a
GSoC project.  That is of course assuming that the goal of the project
is code that will be integrated into a future stable OpenAFS release
within a year.  If the goal is to produce a working prototype so that
the community can gain some experience developing such a solution, then
I believe going ahead with this project in GSoC is not a problem.

As with all GSoC projects, we hope the end results of the project will
be usable code that can be integrated.  My biggest concern is ensuring
that whatever is implemented as part of the OpenAFS Unix cache manager
can eventually be implemented on Windows or other platforms that do not
make the same internal assumptions.  I would also like to ensure that
the encryption functionality would be optional.  Perhaps loaded at
run-time.  As a result, I would like to see the design be two components:=

 * First, develop an abstraction layer that sits within the Unix
   cache manager but logically above the cache manager.

 * Second, an implementation of an encryption layer module that
   plugs into that interface.

There are several benefits to this approach.  First, separating the
encryption layer from the cache manager layer allows the encryption
layer's assumptions about block size to be independent from the cache
manager's assumptions about chunk size.  Second, the abstraction layer
is something that in theory can be shipped as part of a future OpenAFS
much sooner than a full encryption layer.  Third, such a layer permits
different encryption layers to be experimented with without further
modifications to the cache manager implementation.  Finally, if
implemented correctly, the encryption layer should be highly portable
permitting it to be reused in other cache manager implementations.

A beneficial side effect of such a design is that the contents of the
cache will be encrypted in exactly the same way as on the file server.
An attacker will not be able to read unencrypted data out of the cache
files.

Jeffrey Altman

Jeffrey Altman

--------------ms030602010501090703000309
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC
AxcwggKAoAMCAQICEAMF9RTCGOz151fTpHLih+cwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyODA0MDExOVoX
DTEwMDgyODA0MDExOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy
aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt
YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDZNscYIvF6xzGSAfa/QUIqiElyn0EUxL2b86eKiYqe91bj0gLr/MJoErLnb+OmokxqSAH6
y0zlFqSbiFwgNM8m69K6m/6YO+x3+5zBc+u6snwTWMEWygnhx3rQ/lMhoQOgArraL+/k9aWL
kNdaXQKk6EZVW9pfV2A4Lk4DoZGFjY8tJRWWDLlFkYnxDuIEpLYwJpwakv3QHOaq/G8KW0iE
jVhVzPobuZzwD2tuepY/bsClwqxz/gfAEpUvAn/lYTqnoT7RYljZlCIdbrgcG/HSYMxAy1Zp
Yh8Fx+9cqsG8O4nqo26SVfYZvrYhh8m6OqW8Vakdt7vBLCTa/QhIdJ4hAgMBAAGjOTA3MCcG
A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQBvbvJNXUJ4atv1CExIe0J38jZqoEUTttkXOfCDT9e3mSmVboOK
ifHDyLZQC4qSsCUfP7vdwAXjKtjak22HbfX2sEKCUgtnOkxRqXMM2V/NW/ESNVQZF0TO7L/Z
cW3icObO9FIZCSmgFMt2Al7VPfMQmaJNlqu9SLmXSwbRFJ5b4zCCAxcwggKAoAMCAQICEAMF
9RTCGOz151fTpHLih+cwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyODA0MDExOVoXDTEwMDgyODA0MDExOVow
czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl
ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv
aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZNscYIvF6xzGSAfa/
QUIqiElyn0EUxL2b86eKiYqe91bj0gLr/MJoErLnb+OmokxqSAH6y0zlFqSbiFwgNM8m69K6
m/6YO+x3+5zBc+u6snwTWMEWygnhx3rQ/lMhoQOgArraL+/k9aWLkNdaXQKk6EZVW9pfV2A4
Lk4DoZGFjY8tJRWWDLlFkYnxDuIEpLYwJpwakv3QHOaq/G8KW0iEjVhVzPobuZzwD2tuepY/
bsClwqxz/gfAEpUvAn/lYTqnoT7RYljZlCIdbrgcG/HSYMxAy1ZpYh8Fx+9cqsG8O4nqo26S
VfYZvrYhh8m6OqW8Vakdt7vBLCTa/QhIdJ4hAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt
YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB
gQBvbvJNXUJ4atv1CExIe0J38jZqoEUTttkXOfCDT9e3mSmVboOKifHDyLZQC4qSsCUfP7vd
wAXjKtjak22HbfX2sEKCUgtnOkxRqXMM2V/NW/ESNVQZF0TO7L/ZcW3icObO9FIZCSmgFMt2
Al7VPfMQmaJNlqu9SLmXSwbRFJ5b4zCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw
gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp
bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w
MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU
aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg
RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV
+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr
hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/
p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8
MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls
Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh
YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/
TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc
OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIID
bQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5
KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ
AwX1FMIY7PXnV9OkcuKH5zAJBgUrDgMCGgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA0MDEwMjM2MDVaMCMGCSqGSIb3DQEJBDEWBBR7MOOY
i0CUrIL7lbY5AwVLPNm7cDBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0
ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAhADBfUUwhjs9edX06Ry4ofnMIGHBgsqhkiG9w0BCRACCzF4oHYw
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x
LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhADBfUUwhjs
9edX06Ry4ofnMA0GCSqGSIb3DQEBAQUABIIBAFGiqkkSVXhgCatP0VQWMPxjLj+kKBe2KEHR
/jfKnGgDlwzt2vb58D1Y1u71+npb+u1UggupMAUm/5hfkZbXsf/piSHEfSfzLo9v/9Dry2Fa
IFAgx2eZK5xcv6veAdjKn2fZiccMx6syHz+lj1AlHq98lo6MyvfGJSrcKit3vgdXuoisbykG
kErb8zW67d3ot+cJlsHteOSlxcg3gUWpxARKLf0C/dt6emnFrPaFxWt0cKHTK6BaF0FKIz+k
yEMCROvgZM0xEz8C4niSUlC/TPEiJH23oIHujbuX2eHxeqJAj6jAfKRMtEZO6UOOfuiXcumz
qsO/DNT7m3y/MVyGJ3kAAAAAAAA=
--------------ms030602010501090703000309--