eCryptfs

Bug #376580
Comment #8

Comment 8 for bug 376580

Revision history for this message

Tyler Hicks (tyhicks) wrote on 2009-06-08: Re: [Bug 376580] Re: support "reverse" mode

Witold Baryluk wrote:
> Dnia 2009-05-16, sob o godzinie 18:50 +0000, Witold Baryluk pisze:
>> Dnia 2009-05-14, czw o godzinie 18:17 +0000, Witold Baryluk pisze:
>>> Dnia 2009-05-14, czw o godzinie 17:54 +0000, Tyler Hicks pisze:
>>>> Can you elaborate on what random data in the header are you talking
>>>> about? Each file has a unique file encryption key (FEK) that is
>>>> encrypted with your mount key and stored in the header. As long as you
>>>> have your mount key, you will be able to decrypt the encrypted FEK and
>>>> then decrypt the file contents. Is that the random date you were
>>>> referring to?
>>>>
>>> Yes, exactly this random data.
>>>
>
>> Some new thoughts...
>
> Was thinking more about FEKs and FNEKs.
>
> I think i found general and flexible solution:
>
> 1. mount plain filesystem in reverse mode
> 2. start user space daemon which will be asked for FEKs of this files.
> - it can open already (possibly remote) encrypted file, read header
> and use the same FEKS (they can be locally, they can be on sshfs,
> anywhere, or download it using rsync or anything)

This is a possibility, but sounds a little too over-engineered. I like
your next idea much better.

> - or it can maintain local copy of headers (which is safer, because
> remote server can change headers to something easier to crack).
> - in standard files (but with only header)
> - or in DB (sqlite or Berkley DB)

Better yet, store the metadata in an xattr along with the plaintext file
itself. We already support storing the metadata in xattrs. I had been
thinking it wasn't a very useful feature and was wanting to rip that
code out, but this is a valid use case for it.

> - or provide the same FEK or some deterministic function of available
> informations (like file name + private key)

Deterministic FEK generation is not a good idea. Using the same FEK is
doable, but I still like idea #2 much more.

> 3. kernel space will ask for this FEKs, and use them for encryption,
> preferably in ECB or CTR mode, so rsync will be quite happy.

Kernel space can read the xattrs itself, so it won't have to switch out
to user space. eCryptfs only supports CBC mode, but each 4k extent is
encrypted with a unique IV, so rsync should still be pretty happy.

> 4. additionally kernel will not ask for this keys if this file isn't
> going to be opened (rsync for example first check modification time)
> Maybe only FNEK will be needed to ask, so we will know what filenames
> to give to opendir()
>
> The last point can be optimised to allow asking for multiple keys,
> (reducing context switches). This also makes kernel part simple.
>
> Part of this infrastructure is already present in ecryptfsd, right?
>

If we store the metadata in the xattr, there probably won't be a lot of
new code that will need to be written. We should be able to use many
functions that already exist and minimal user space changes will be needed.

Witold Baryluk wrote:
> Dnia 2009-05-16, sob o godzinie 18:50 +0000, Witold Baryluk pisze:
>> Dnia 2009-05-14, czw o godzinie 18:17 +0000, Witold Baryluk pisze:
>>> Dnia 2009-05-14, czw o godzinie 17:54 +0000, Tyler Hicks pisze:
>>>> Can you elaborate on what random data in the header are you talking
>>>> about?  Each file has a unique file encryption key (FEK) that is
>>>> encrypted with your mount key and stored in the header.  As long as you
>>>> have your mount key, you will be able to decrypt the encrypted FEK and
>>>> then decrypt the file contents.  Is that the random date you were
>>>> referring to?
>>>>
>>> Yes, exactly this random data.
>>>
> 
>> Some new thoughts...
> 
> Was thinking more about FEKs and FNEKs.
> 
> I think i found general and flexible solution:
> 
> 1. mount plain filesystem in reverse mode
> 2. start user space daemon which will be asked for FEKs of this files.
>    - it can open already (possibly remote) encrypted file, read header
>      and use the same  FEKS (they can be locally, they can be on sshfs,
>       anywhere, or download it using rsync or anything)

This is a possibility, but sounds a little too over-engineered.  I like
your next idea much better.

>    - or it can maintain local copy of headers (which is safer, because
>      remote server can change headers to something easier to crack).
>       - in standard files (but with only header)
>       - or in DB (sqlite or Berkley DB)

Better yet, store the metadata in an xattr along with the plaintext file
itself.  We already support storing the metadata in xattrs.  I had been
thinking it wasn't a very useful feature and was wanting to rip that
code out, but this is a valid use case for it.

>    - or provide the same FEK or some deterministic function of available
>      informations (like file name + private key)

Deterministic FEK generation is not a good idea.  Using the same FEK is
doable, but I still like idea #2 much more.

> 3. kernel space will ask for this FEKs, and use them for encryption,
>    preferably in ECB or CTR mode, so rsync will be quite happy.

Kernel space can read the xattrs itself, so it won't have to switch out
to user space.  eCryptfs only supports CBC mode, but each 4k extent is
encrypted with a unique IV, so rsync should still be pretty happy.

> 4. additionally kernel will not ask for this keys if this file isn't
>    going to be opened (rsync for example first check modification time)
>    Maybe only FNEK will be needed to ask, so we will know what filenames
>    to give to opendir()
> 
> The last point can be optimised to allow asking for multiple keys,
> (reducing context switches). This also makes kernel part simple.
> 
> Part of this infrastructure is already present in ecryptfsd, right?
>

If we store the metadata in the xattr, there probably won't be a lot of
new code that will need to be written.  We should be able to use many
functions that already exist and minimal user space changes will be needed.