[OpenAFS-devel] Encrypted Storage -- GSoC Proposal
Sanket Agarwal
sanket@sanketagarwal.com
Mon, 31 May 2010 15:45:35 +0200
--00c09f88ce8146fa640487e41226
Content-Type: text/plain; charset=ISO-8859-1
Sorry to be late to let you all know about the project proposal. But here is
the proposal picked up straight from socghop( I am lazy enough :D ):
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Title: Encrypted storage
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Abstract:
The AFS protocol offers encryption for data transport from client to server.
However, that data is stored on the server in cleartext, where it can
potentially be read by the administrators of that server. This poses a real
world problem for organisations who wish to outsource the provision of their
file storage, whilst keeping their data confidential. This project would
augment the existing AFS client to support encrypting data blocks before
sending them to the file server.
Proposal:
As mentioned above the idea is to develop an encrypting mechanism at the
client side to send cipher text data to the file servers. The scope of such
encryption shall be limited to Files as Directory structure modification
will need the server's support. The idea is to provide a working prototype
in the given time frame of 3 months.
Assuming user has a user key( a Public key pair ) a Use Case is as follows,
The general work flow of the encryption mechanism would be:
*) User writes to a new file on the CM side and tells the client to
*encrypt* the data before being sent over the wire.
*) The Client generates a Random Key and encrypts the data using an
encryption algorithm.
*) The Client then constructs a metadata file which contains
information+random key and encrypts that using the user key.
*) The Client while sending the file also sends the metadata file. This is
to identify later if a file was encrypted or not.
While requesting for an encrypted file:
*) Cache manager checks whether the metadata file exists on the server.
*) If no, then no decryption is required.
*) If yes, metadata is decrypted using the private key and random key is
obtained.
*) Any request for a new block from the server will have to be processed
through a decryption mechanism.
There are several points that need to be noted:
*) It is assumed that libhcrypto is available as a part of my project. I
will be using it for developing the required interface.
*) Regarding the metadata files, there is a GSoC based on Providing common
Extended Attribute Support similar to POSIX Xattributes. The future plan
would be to fold the metadata files into those xattrbs.
*) OpenAFS maintains a 2 level cache, one which resides on the Secondary
Memory, and one which resides in the Main Memory. If there is a new block
request it is first brought in the Secondary Mem and loaded to Main Memory
when User Application requests it. My scheme will be something like this:
-> If a new block request is made for an encrypted file, the encrypted
block will be kept *as-it-is* w/o any decryption. Only when the block is
moved to the Main Memory will it be decrypted. This will
avoid issues with chunking.
-> Similarly if a block from Main Memory is written back to AFS cache,
it'll be encrypted. Assuming MM hits are large, this would not incur much
Encryption Call overhead.
-> Hence there will be a logial partition b/w Secondary Cache which is
on Fileserver's end and Main Cache which is at User Application end.
*) In effect, what I'll be doing is adding an interface to the cache manager
that allows manipulation of data in the process of it being read from the
disk cache, and placed in the page cache (and similarly, when it is being
written to the disk cache from the page cache) [ As directed by Simon. ]
-> Firstly, a no-op interface which'll intercept the calls but make no
changes to the scheme. Some debug messages may be output.
-> Inspecting metadata on the disk.
-> Implementing the encryption scheme.
--00c09f88ce8146fa640487e41226
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Sorry to be late to let you all know about the project proposal. But here i=
s the proposal picked up straight from socghop( I am lazy enough :D ):<br><=
br><p>---------------------------------------------------------------------=
---------------------------------------------------------------------------=
----------------------------------</p>
<p>Title: Encrypted storage</p>
<p>------------------------------------------------------------------------=
---------------------------------------------------------------------------=
-------------------------------</p>
<p>Abstract:</p>
<p>=A0</p>
<p>The AFS protocol offers encryption for data transport from client to=20
server. However, that data is stored on the server in cleartext, where=20
it can potentially be read by the administrators of that server. This=20
poses a real world problem for organisations who wish to outsource the=20
provision of their file storage, whilst keeping their data confidential.
This project would augment the existing AFS client to support=20
encrypting data blocks before sending them to the file server.</p>
<p>=A0</p>
<p>Proposal:</p>
<p>=A0</p>
<p>As mentioned above the idea is to develop an encrypting mechanism at=20
the client side to send cipher text data to the file servers. The scope=20
of such encryption shall be limited to Files as Directory structure=20
modification will need the server's support. The idea is to provide a=
=20
working prototype in the given time frame of 3 months.</p>
<p>=A0</p>
<p>Assuming user has a user key( a Public key pair ) a Use Case is as=20
follows,</p>
<p>=A0</p>
<p>The general work flow of the encryption mechanism would be:</p>
<p>=A0</p>
<p>*) User writes to a new file on the CM side and tells the client to=20
*encrypt* the data before being sent over the wire.</p>
<p>*) The Client generates a Random Key and encrypts the data using an=20
encryption algorithm.</p>
<p>*) The Client then constructs a metadata file which contains=20
information+random key and encrypts that using the user key.</p>
<p>*) The Client while=A0 sending the file also sends the metadata file.=20
This is to identify later if a file was encrypted or not.</p>
<p>=A0</p>
<p>While requesting for an encrypted file:</p>
<p>=A0</p>
<p>*) Cache manager checks whether the metadata file exists on the=20
server.</p>
<p>*) If no, then no decryption is required.</p>
<p>*) If yes, metadata is decrypted using the private key and random key
is obtained.</p>
<p>*) Any request for a new block from the server will have to be=20
processed through a decryption mechanism.</p>
<p>=A0</p>
<p>There are several points that need to be noted:</p>
<p>=A0</p>
<p>*) It is assumed that libhcrypto is available as a part of my=20
project. I will be using it for developing the required interface.</p>
<p>*) Regarding the metadata files, there is a GSoC based on Providing=20
common Extended Attribute Support similar to POSIX Xattributes. The=20
future plan would be to fold the metadata files into those xattrbs.</p>
<p>*) OpenAFS maintains a 2 level cache, one which resides on the=20
Secondary Memory, and one which resides in the Main Memory. If there is a
new block request it is first brought in the Secondary Mem and loaded=20
to Main Memory when User Application requests it. My scheme will be=20
something like this:</p>
<p>=A0=A0=A0 -> If a new block request is made for an encrypted file, th=
e=20
encrypted block will be kept *as-it-is* w/o any decryption. Only when=20
the block is moved to the Main Memory will it be =A0=A0 =A0=A0=A0 =A0=A0=A0=
=A0=A0=A0=20
=A0decrypted. This will avoid issues with chunking.</p>
<p>=A0=A0=A0 -> Similarly if a block from Main Memory is written back to=
=20
AFS cache, it'll be encrypted. Assuming MM hits are large, this would=
=20
not incur much Encryption Call overhead.</p>
<p>=A0=A0=A0 -> Hence there will be a logial partition b/w Secondary Cac=
he=20
which is on Fileserver's end and Main Cache which is at User Applicatio=
n
end.</p>
<p>*) In effect, what I'll be doing is adding an interface to the cache=
=20
manager that allows manipulation of data in the process of it being read
from the disk cache, and placed in the page cache (and similarly, when=20
it is being written to the disk cache from the page cache) [ As directed
by Simon. ]</p>
<p>=A0=A0=A0 -> Firstly, a no-op interface which'll intercept the ca=
lls but
make no changes to the scheme. Some debug messages may be output.</p>
<p>=A0=A0=A0 -> Inspecting metadata on the disk.</p>
<p>=A0=A0=A0 -> Implementing the encryption scheme.</p><br>
--00c09f88ce8146fa640487e41226--