Subject: [nfsv4] Re: Encryption at rest

From: Benny Halevy <[email-masked]>
Date: Sat, 06 May 2006 10:08:19 +0300

Mike,

First, for interoperability reasons this feature needs to be specified 
at the generic NFSv4 protocol level so that you could encrypt the data 
on one client and decrypt it sometimes in the (possibly very far) future 
with a different client.  You never know, at decryption time linux may 
even no longer exist ;-), Therefore [email-masked] is a more appropriate 
forum to discuss your idea.

We've started discussing doing end-to-end data checksums that are 
computed by the client, stored on the server alongside the data, and 
later verified by the client when data plus checksums are read.  Your 
proposal for end-to-end data encryption seems to follow a somewhat 
similar model.
I doubt if the Kerberos keys can be used for encrypting/decrypting data 
since the keys must persist across client and server reboots, 
backup/restore, and across data migration.  Generally speaking the 
client should be able to recompute the key based on metadata that's 
stored persistently with the data and doesn't change when the file is 
copied, a new file attribute may suffice here.

Benny

mike wrote:
> I've noticed that sec=krb5p will encrypt NFS traffic from
> client<->server, which is awesome. No more needing to create an SSH
> tunnel or something else for the internal LAN NFS traffic.
>
> However, I've been looking around for some sort of encryption-at-rest
> options and I thought of an idea... which may or may not spur some
> discussion.
>
> The idea is simple: currently in krb5p, I assume the client and server
> negotiate a key, and then all data is encrypted with that key on the
> client, and then decrypted on the server prior to it being committed
> to disk. What if the decryption step was optional, and the data was
> kept in encrypted format on the disk? The NFS server would handle the
> authentication to pass it back to the client, and the client would
> then decrypt it (it would actually save the server decrypting it and
> then re-encrypting it to send back to the client) which would also
> give some performance gains. It would also allow for the clients
> (which are much easier to scale up/out) to handle all the encryption
> and allow the server to handle only accepting, committing and
> retrieving data, not encrypting and decrypting as well. This would
> solve storage "at rest" privacy concerns and address things such as
> HIPAA and other new regulations for storing sensative information.
>
> Obviously some of the implementation details are sketchy, but that's
> just my high level idea; it seems like it could work, as opposed to
> working on some sort of disk encryption on the NFS server, managing
> the keys/etc. (not to mention if it's remote, USB keys and such are
> useless) and the overhead of sending encrypted information back and
> forth to the server. This would effectively remove the need to buy
> beefy NFS servers to handle all the encryption work, any special
> encryption offloading cards, managing access to the machine and being
> able to mount the machine's encrypted drive from a remote location
> without needing someone onsite to have a copy of the keys.
>
> In short, the NFS server would never see the unencrypted data, it
> would blindly be storing data as it gets it, so the need to actually
> put a layer of encryption between it and the disk itself would not be
> required...
>
> Any comments are appreciated. Hopefully it sounds like an interesting
> idea or something possibly in the works by another project?
>
> Thanks,
> mike
> _______________________________________________
> NFSv4 mailing list
> [email-masked]
> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4