Key derivation and passprhase wrapping

Key derivation and passprhase wrapping

[Wiebe Cazemier]

Hi, 

I was looking at the ecryptfs source code, and saw that the actual encryption key inserted into the kernel keyring is the *original* wrapped passphrase, SHA512'ed 65536 times. Why is a user-given passphrase encrypted as key, and not data from /dev/random? I unwrapped the passphrase on my Linux Mint system and saw it is actually a random string, so the Ubuntu/Mint installer took care of it for me. But why is that responsibility given to the user / outside world? One of the problems is that I can't change it. Had I made a ecryptfs archive myself and wrapped 'hello' as passphrase, that weak key will be used and cannot be changed by rewrapping.

Would it be possible/feasible to do something like:

* generate random encryption key A for insertion into kernel keyring.
* derive encryption key B from password with 'generate_passphrase_sig(...)' to encrypt key A.
* In v2 wrapped passphrase file, Octets 26-N1, store encrypted A, instead of encrypted passphrase.

Depending on how it's implemented, it could even be done completely backwards compatible (by ignoring the to-wrap passphrase).

Regards,

Wiebe

Re: Key derivation and passprhase wrapping

[Tyler Hicks]

[-- Attachment #1: Type: text/plain, Size: 2378 bytes --]

On 2016-01-18 11:27:37, Wiebe Cazemier wrote:
> Hi, 
> 
> I was looking at the ecryptfs source code, and saw that the actual
> encryption key inserted into the kernel keyring is the *original*
> wrapped passphrase, SHA512'ed 65536 times. Why is a user-given
> passphrase encrypted as key, and not data from /dev/random?

This assumes that the mount.ecryptfs helper is used and not the
mount.ecryptfs_private helper.

mount.ecryptfs does key stretching (SHA512 * 65536) on a user-provided
passphrase and uses that as the file encryption key encryption key
(FEKEK). This keeps things simple so that the only thing a user needs to
access their encrypted files is the passphrase. There's no chance of
losing track of a file containing a wrapped FEKEK that is randomly
generated. However, mount.ecryptfs could be extended to make use of
wrapped, randomly generated FEKEK which would provide a more secure
option.

> I unwrapped the passphrase on my Linux Mint system and saw it is
> actually a random string, so the Ubuntu/Mint installer took care of it
> for me. But why is that responsibility given to the user / outside
> world?

All of the logic that set up that random FEKEK is in upstream
ecryptfs-utils. The confusion is probably caused by the unfortunate
split between the mount.ecryptfs and mount.ecryptfs_private helpers.

> One of the problems is that I can't change it. Had I made a
> ecryptfs archive myself and wrapped 'hello' as passphrase, that weak
> key will be used and cannot be changed by rewrapping.
> 
> Would it be possible/feasible to do something like:
> 
> * generate random encryption key A for insertion into kernel keyring.
> * derive encryption key B from password with 'generate_passphrase_sig(...)' to encrypt key A.
> * In v2 wrapped passphrase file, Octets 26-N1, store encrypted A, instead of encrypted passphrase.

I'm not following the intent here. You're wanting to change the FEKEK
that the Ubuntu/Mint installer generated?

Tyler

> 
> Depending on how it's implemented, it could even be done completely backwards compatible (by ignoring the to-wrap passphrase).
> 
> Regards,
> 
> Wiebe
> --
> To unsubscribe from this list: send the line "unsubscribe ecryptfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Key derivation and passprhase wrapping

[Wiebe Cazemier]

----- Original Message -----
> From: "Tyler Hicks" <tyhicks@canonical.com>
> To: "Wiebe Cazemier" <wiebe@halfgaar.net>
> Cc: ecryptfs@vger.kernel.org
> Sent: Wednesday, 20 January, 2016 4:05:57 AM
> Subject: Re: Key derivation and passprhase wrapping
> 
> On 2016-01-18 11:27:37, Wiebe Cazemier wrote:
> > Hi,
> > 
> > I was looking at the ecryptfs source code, and saw that the actual
> > encryption key inserted into the kernel keyring is the *original*
> > wrapped passphrase, SHA512'ed 65536 times. Why is a user-given
> > passphrase encrypted as key, and not data from /dev/random?
> 
> This assumes that the mount.ecryptfs helper is used and not the
> mount.ecryptfs_private helper.
> 
> mount.ecryptfs does key stretching (SHA512 * 65536) on a user-provided
> passphrase and uses that as the file encryption key encryption key
> (FEKEK). This keeps things simple so that the only thing a user needs to
> access their encrypted files is the passphrase. There's no chance of
> losing track of a file containing a wrapped FEKEK that is randomly
> generated. However, mount.ecryptfs could be extended to make use of
> wrapped, randomly generated FEKEK which would provide a more secure
> option.
> 
> > I unwrapped the passphrase on my Linux Mint system and saw it is
> > actually a random string, so the Ubuntu/Mint installer took care of it
> > for me. But why is that responsibility given to the user / outside
> > world?
> 
> All of the logic that set up that random FEKEK is in upstream
> ecryptfs-utils. The confusion is probably caused by the unfortunate
> split between the mount.ecryptfs and mount.ecryptfs_private helpers.
> 
> > One of the problems is that I can't change it. Had I made a
> > ecryptfs archive myself and wrapped 'hello' as passphrase, that weak
> > key will be used and cannot be changed by rewrapping.
> > 
> > Would it be possible/feasible to do something like:
> > 
> > * generate random encryption key A for insertion into kernel keyring.
> > * derive encryption key B from password with 'generate_passphrase_sig(...)'
> > to encrypt key A.
> > * In v2 wrapped passphrase file, Octets 26-N1, store encrypted A, instead
> > of encrypted passphrase.
> 
> I'm not following the intent here. You're wanting to change the FEKEK
> that the Ubuntu/Mint installer generated?
> 
> Tyler
> 
> > 
> > Depending on how it's implemented, it could even be done completely
> > backwards compatible (by ignoring the to-wrap passphrase).
> > 
> > Regards,
> > 
> > Wiebe

I think I missed an important bit. I was looking at ecryptfs-wrap-passphrase, which makes you supply the FEK and FEKEK, but ecryptfs-setup-private actually already uses a random passphrase:

-m, --mountpass MOUNTPASS
    Passphrase for mounting the ecryptfs directory, default is 16 bytes from /dev/urandom if omitted

Never mind ;)

Re: Key derivation and passprhase wrapping

[Wiebe Cazemier]

----- Original Message -----
> From: "Wiebe Cazemier" <wiebe@halfgaar.net>
> To: "Tyler Hicks" <tyhicks@canonical.com>
> Cc: ecryptfs@vger.kernel.org
> Sent: Wednesday, 20 January, 2016 8:51:43 PM
> Subject: Re: Key derivation and passprhase wrapping
> 
> I think I missed an important bit. I was looking at ecryptfs-wrap-passphrase,
> which makes you supply the FEK and FEKEK, but ecryptfs-setup-private
> actually already uses a random passphrase:
> 
> -m, --mountpass MOUNTPASS
>     Passphrase for mounting the ecryptfs directory, default is 16 bytes from
>     /dev/urandom if omitted
> 

I do see an issue though. The bash script says:

  random_data=`head -c 16000 /dev/urandom | od -x` || error_testing "$temp" "$(gettext 'Could not generate random data')"

But when urandom can't be read (doesn't exist, no file handles, whatever):

  random_data=`head -c 16000 /dev/urando | od -x` || echo "fail"
  head: cannot open ‘/dev/urando’ for reading: No such file or directory

Note, no 'fail' and $? == 0. And:

  echo $random_data
  0000000


Regards,

Wiebe

Re: Key derivation and passprhase wrapping

[Tyler Hicks]

[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]

On 2016-01-20 21:03:13, Wiebe Cazemier wrote:
> ----- Original Message -----
> > From: "Wiebe Cazemier" <wiebe@halfgaar.net>
> > To: "Tyler Hicks" <tyhicks@canonical.com>
> > Cc: ecryptfs@vger.kernel.org
> > Sent: Wednesday, 20 January, 2016 8:51:43 PM
> > Subject: Re: Key derivation and passprhase wrapping
> > 
> > I think I missed an important bit. I was looking at ecryptfs-wrap-passphrase,
> > which makes you supply the FEK and FEKEK, but ecryptfs-setup-private
> > actually already uses a random passphrase:
> > 
> > -m, --mountpass MOUNTPASS
> >     Passphrase for mounting the ecryptfs directory, default is 16 bytes from
> >     /dev/urandom if omitted
> > 
> 
> I do see an issue though. The bash script says:
> 
>   random_data=`head -c 16000 /dev/urandom | od -x` || error_testing "$temp" "$(gettext 'Could not generate random data')"
> 
> But when urandom can't be read (doesn't exist, no file handles, whatever):
> 
>   random_data=`head -c 16000 /dev/urando | od -x` || echo "fail"
>   head: cannot open ‘/dev/urando’ for reading: No such file or directory
> 
> Note, no 'fail' and $? == 0. And:
> 
>   echo $random_data
>   0000000

For completeness, we should mention that this is being tracked in
Launchpad:

 https://launchpad.net/bugs/1539553

Tyler

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]