Just some thoughts, and as always I may be 100% offbase. Feel free to
send flames my way...
--
If you encrypt the cachemanager, what happens to the cache when you
use multiple local accounts and a single afs account, or single afs
account and multiple afs accounts? or mults of each in combinations?
(I do this a lot..) Do i end up having to recache everything for each
local and afs account? If so, doesn't this defeat part of the purpose
of the cachemgr?
---
Tertiary to the thread, but with all the interest in encryption with
our GSoC...
If I understand this correctly,
I have a single master key, that encrypts all the volumes..
If I want to change this key, I have to unencrypt the volumes with the
old key and re-encrypt them with the new key. If this is correct, what
happens when my key gets compromised, or if I just want to change the
key as part of a standard security measure eg a stronger key? I have
say a million volumes, and it is an essential part to my
infrastructure so scheduling downtime is extremely hard.
If my understanding is correct, and we have a ton of interest in
encryption.. can we make it so we can use multiple master keys? So i
can migrate from master key A to master key B more transparently? Then
use some mechanism, like a pthreaded bu to dump the volume with the
old key and re-encrypt and restore the volume with the new key? It
does take the individual volumes offline but not the whole cell. (you
also need something in the vldb that lets you figure out what volume
is using what key too.)
If so what happens to the data that is already cached out in userland
with the old key?
---
With all the encryption going on, I worry about filesystem performance
and the cpu overhead. I like abstraction layers and I agree with Mr.
Altman's development plan especially about the abstraction. Because
even if you get it to work, in 3 months, it is probably going to take
some time to really get it tweaked, and then by the time you do that,
someone will have broken the encryption algorithm...
Hcrypt may have the algorithm already, but there was one algorithm,
and it was written for cell phones, and I forgot the name of it, (new
in the last 7 years..) but it was designed to be less processor
intensive. It was based on ellipses. (i think it ended up tot be 1
quadrant of the ellipse or an arc)/ I don't think it has been broken
yet. Which the concept actually fits especially the client side of
AFS, where you might be running an older computer or porting to say
something on the Android platform.
--
Oh, just one more thing...
If you are going to be using the exact same way to encrypt the cache
as you do your volumes on the fileserver, wouldn't this make it easier
for an attacker to decrypt your master key? IE I make a change in my
local cache, and then I can see what changes were made to the cache,
then I probe for the differences and I can get the master key? (or
does way refer to the algorithm and not the key?)
I would think you would need to issue a key from the afs cell to each
individual cachemgr. Or the more I think about it this is what is done..
Quoting Jeffrey Altman <[email protected]>:
On 3/31/2010 3:56 AM, Sanket Agarwal wrote:
On Wed, Mar 31, 2010 at 12:21 PM, Sanket Agarwal
<[email protected] <mailto:[email protected]>> wrote:
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.
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 OpenSSL
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 the
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
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
