Practical use of ecryptfs, encrypted keys, and TPM: how to convert existing user key to encrypted key?

Practical use of ecryptfs, encrypted keys, and TPM: how to convert existing user key to encrypted key?

[James Johnston]

Hi,

Short version of this question is:  How do I convert a user key on the keyring
storing ecryptfs authentication token / FEFEK to an encrypted key on keyring?
(I.e. how to add an encrypted key with user-specified plaintext data, instead
of a randomly-generated key - such as a pre-existing mounting passphrase for
an existing ecryptfs file system.)  Read on for why...

I'm trying to figure out how to practically use ecryptfs with a TPM, and the
information I'm finding is generally out-of-date/obsolete.  All I've found is
blog articles or IBM whitepapers from a few years ago that appear to use
features that don't exist anymore / unmaintained features.  I've gathered that
the proper way to do this now involves trusted and encrypted kernel keys, as
per:

 * https://www.kernel.org/doc/Documentation/security/keys-ecryptfs.txt
 * https://www.kernel.org/doc/Documentation/security/keys-trusted-encrypted.txt

The strategy outlined in the above documentation indicates the idea would be to
make a new trusted key, sealed with the TPM, and then use it to make a new
encrypted key in the ecryptfs format, specifying the trusted key as the master.
That's easy enough to follow, and does what I'm looking for, except...

The problem is if the TPM dies, I need to recover my data (e.g. computer dies,
and need to restore from encrypted backups).  What I'm wanting to do is use a
passphrase to decrypt data if the TPM is not available, to be used only in
special circumstances.  Alternatively, users might have a pre-existing
ecryptfs file system with a mounting passphrase / FEFEK already chosen - i.e.
you don't want to re-encrypt all your files just to use the TPM.  This seems
like an obvious need, yet I'm have trouble figuring out the "how". 

From the above documentation:

    The data structure defined by eCryptfs to contain information required for the
    FEK decryption is called authentication token and, currently, can be stored in a
    kernel key of the 'user' type, inserted in the user's session specific keyring
    by the userspace utility 'mount.ecryptfs' shipped with the package
    'ecryptfs-utils'.

    Encrypted keys of the newly introduced [ecryptfs encrypted] format store an
    authentication token in its payload with a FEFEK randomly generated by the
    kernel and protected by the parent master key.  [What if I want to use an
    existing FEFEK?]

OK, so it sounds to me like the kernel is storing the encrypted key in the same
format as a regular user key that would be added to the keyring by the ecryptfs
userspace tools (e.g. by ecryptfs-add-passphrase or the mount helper).  That is,
the payload of the user key and the encrypted key are basically one and the
same, except the kernel won't allow userspace to read the encrypted key in
unencrypted format.  Right?

So I think what I want to do is this - am I on the right track here?

1.  Use ecryptfs-add-passphrase to add a mounting passphrase to the keyring.
    (It could be a mounting passphrase for an existing ecryptfs filesystem).
    Now I have a user key on the keyring storing an ecryptfs authentication
    token.  The mounting passphrase can be complex and stored in an offline
    secure location, perhaps protected by ecryptfs-wrap-passphrase, and only
    used in a data recovery scenario (e.g. if the TPM goes up in smoke). 
2.  Create a new trusted key in the keyring, as per above documentation.
3.  Convert the existing user key storing authentication token from
    ecrypt-add-passphrase in step #1 into an encrypted key on the keyring, using
    the trusted key as the master key.  (This is where I'm stuck.)
4.  Remove the user key from the keyring since we don't need it any more.
5.  Use "keyctl pipe" to save the encrypted key to a file on disk for later
    mounting.

Ordinary day-to-day mounting would work like:
1.  Load and unseal trusted key into keyring.
2.  Load encrypted key blob from step #5 above into encrypted key in keyring,
    using trusted key as master key. 
3.  Mount using the encrypted key from previous step.

If the TPM is destroyed or lost:
1.  Use ecryptfs-add-passphrase to add the mounting passphrase from backup into
    an authentication token stored in a user key.
2.  Mount using this user key.

So my key question is this:  How do I convert a user key storing authentication
token to an encrypted key, as in step #3 in the setup procedure above?  For
example, docs say this to decrypt an existing encrypted key previously exported
with keyctl pipe <encrypted ID>:

    keyctl add encrypted name "load hex_blob" ring

But I want to do something like this to make a new encrypted key from some
pre-existing plaintext:

    keyctl add encrypted name "load ecryptfs trusted:masterkey `keyctl print <id of user key holding plaintext authentication token / FEFEK / mounting passphrase>`" @u

(This as opposed to the random new key generated with
"add encrypted name "new ecryptfs"")

If the above isn't possible then what am I missing in my strategy?  Feels like
I'm missing some obvious information here.

Best regards,

James Johnston

Re: Practical use of ecryptfs, encrypted keys, and TPM: how to convert existing user key to encrypted key?

[Mimi Zohar]

On Sat, 2016-03-26 at 20:46 +0000, James Johnston wrote:
> Hi,
> 
> Short version of this question is:  How do I convert a user key on the keyring
> storing ecryptfs authentication token / FEFEK to an encrypted key on keyring?
> (I.e. how to add an encrypted key with user-specified plaintext data, instead
> of a randomly-generated key - such as a pre-existing mounting passphrase for
> an existing ecryptfs file system.)  Read on for why...
> 
> I'm trying to figure out how to practically use ecryptfs with a TPM, and the
> information I'm finding is generally out-of-date/obsolete.  All I've found is
> blog articles or IBM whitepapers from a few years ago that appear to use
> features that don't exist anymore / unmaintained features.  I've gathered that
> the proper way to do this now involves trusted and encrypted kernel keys, as
> per:

Support for using trusted/encrypted ecryptfs keys was added by Roberto
Sassu as soon as trusted/encrypted keys was upstreamed.  The only
documentation are those that you sited below.

>  * https://www.kernel.org/doc/Documentation/security/keys-ecryptfs.txt
>  * https://www.kernel.org/doc/Documentation/security/keys-trusted-encrypted.txt
> 
> The strategy outlined in the above documentation indicates the idea would be to
> make a new trusted key, sealed with the TPM, and then use it to make a new
> encrypted key in the ecryptfs format, specifying the trusted key as the master.
> That's easy enough to follow, and does what I'm looking for, except...
> 
> The problem is if the TPM dies, I need to recover my data (e.g. computer dies,
> and need to restore from encrypted backups).  What I'm wanting to do is use a
> passphrase to decrypt data if the TPM is not available, to be used only in
> special circumstances. 

Encrypted keys can be updated so that they're encrypted with a different
user or trusted key, but the key type (user | trusted) can not be
changed.  Allowing the key type to change would kind of defeat the
purpose of using a trusted key in the first place.

There was some initial discussions about adding support for trusted key
migration, but nothing was ever posted. 

Mimi

RE: Practical use of ecryptfs, encrypted keys, and TPM: how to convert existing user key to encrypted key?

[James Johnston]

Hi Mimi,

Thanks for taking a look at this question.

> > The problem is if the TPM dies, I need to recover my data (e.g. computer dies,
> > and need to restore from encrypted backups).  What I'm wanting to do is use a
> > passphrase to decrypt data if the TPM is not available, to be used only in
> > special circumstances.
> 
> Encrypted keys can be updated so that they're encrypted with a different
> user or trusted key, but the key type (user | trusted) can not be
> changed.  Allowing the key type to change would kind of defeat the
> purpose of using a trusted key in the first place.

Agree 100% that changing the master key type from trusted to user would defeat the
whole point.  But that's not really the request here.

What is the harm about initially populating the encrypted key type with a known
mounting passphrase instead of random data?  For example, if the user has an
existing ecryptfs file system they now wish to protect with the TPM?  I don't
think it's the kernel's place to judge whether I think my payload has been
compromised or not, or if it is sufficiently random.  I cannot think of any
problem with this, so it seems to me, if it's not currently possible, this would
be an area of needed improvement in the kernel to enable the proposed real-world
use?

I mean, as I currently understand it, the only way to use trusted & encrypted
keys together involves randomly-generated encrypted keys, whose plaintext
contents cannot be easily backed up since we cannot (and should not) be able
to change the master key type.  But now the potential for data loss if the TPM
fails seems certain, thus making this feature an interesting academic exercise
but useless in the real world where backups are needed when real-world hardware
stops working.  Am I missing something?

To contrast, with LUKS or BitLocker for example, the decryption key for the
block device can be recovered using multiple methods.  For example, a
passphrase can be used to decrypt the main key for the drive.  Alternatively,
one could conceivably use a different LUKS slot for use by the TPM, such as
done by the tpm-luks project.  So I can use TPM for day-to-day use, and then
put the passphrase in a safe offline place in case I have to recover when the
TPM stops working.

I thought about the problem some more yesterday.  I guess one could use
tpm_unsealdata and then ecryptfs-add-passphrase by hand from the command line.
But then the authentication token is stored in a regular user key, not within
the protection of an "encrypted" key type.  So the security is not as good
because userspace can read the authentication token in plaintext at any time.

Best regards,

James Johnston

Re: Practical use of ecryptfs, encrypted keys, and TPM: how to convert existing user key to encrypted key?

[Mimi Zohar]

On Mon, 2016-03-28 at 15:34 +0000, James Johnston wrote:
> Hi Mimi,
> 
> Thanks for taking a look at this question.
> 
> > > The problem is if the TPM dies, I need to recover my data (e.g. computer dies,
> > > and need to restore from encrypted backups).  What I'm wanting to do is use a
> > > passphrase to decrypt data if the TPM is not available, to be used only in
> > > special circumstances.
> > 
> > Encrypted keys can be updated so that they're encrypted with a different
> > user or trusted key, but the key type (user | trusted) can not be
> > changed.  Allowing the key type to change would kind of defeat the
> > purpose of using a trusted key in the first place.
> 
> Agree 100% that changing the master key type from trusted to user would defeat the
> whole point.  But that's not really the request here.
> 
> What is the harm about initially populating the encrypted key type with a known
> mounting passphrase instead of random data?  For example, if the user has an
> existing ecryptfs file system they now wish to protect with the TPM?  I don't
> think it's the kernel's place to judge whether I think my payload has been
> compromised or not, or if it is sufficiently random.  I cannot think of any
> problem with this, so it seems to me, if it's not currently possible, this would
> be an area of needed improvement in the kernel to enable the proposed real-world
> use?

Yes, this would resolve the existing ecryptfs key usecase scenario, but
I don't think it is needed for the initial use case scenario of a TPM
failure.   A concern with this approach is how to safely initialize the
encrypted key payload.   Its probably not a good idea to pass it on the
command line.  Maybe prompt for it?

> I mean, as I currently understand it, the only way to use trusted & encrypted
> keys together involves randomly-generated encrypted keys, whose plaintext
> contents cannot be easily backed up since we cannot (and should not) be able
> to change the master key type.  But now the potential for data loss if the TPM
> fails seems certain, thus making this feature an interesting academic exercise
> but useless in the real world where backups are needed when real-world hardware
> stops working.  Am I missing something?

Another option would to be migrate the TPM key, which was used to seal
the trusted (asymmetric) key, to a backup server.  If something happens
to the local TPM, the trusted key could be re-sealed on a new TPM.  (I
have not tried doing this.)

Mimi

> To contrast, with LUKS or BitLocker for example, the decryption key for the
> block device can be recovered using multiple methods.  For example, a
> passphrase can be used to decrypt the main key for the drive.  Alternatively,
> one could conceivably use a different LUKS slot for use by the TPM, such as
> done by the tpm-luks project.  So I can use TPM for day-to-day use, and then
> put the passphrase in a safe offline place in case I have to recover when the
> TPM stops working.
> 
> I thought about the problem some more yesterday.  I guess one could use
> tpm_unsealdata and then ecryptfs-add-passphrase by hand from the command line.
> But then the authentication token is stored in a regular user key, not within
> the protection of an "encrypted" key type.  So the security is not as good
> because userspace can read the authentication token in plaintext at any time.
> 
> Best regards,
> 
> James Johnston

RE: Practical use of ecryptfs, encrypted keys, and TPM: how to convert existing user key to encrypted key?

[James Johnston]

> > > > The problem is if the TPM dies, I need to recover my data (e.g. computer dies,
> > > > and need to restore from encrypted backups).  What I'm wanting to do is use a
> > > > passphrase to decrypt data if the TPM is not available, to be used only in
> > > > special circumstances.
> > >
> > > Encrypted keys can be updated so that they're encrypted with a different
> > > user or trusted key, but the key type (user | trusted) can not be
> > > changed.  Allowing the key type to change would kind of defeat the
> > > purpose of using a trusted key in the first place.
> >
> > Agree 100% that changing the master key type from trusted to user would defeat the
> > whole point.  But that's not really the request here.
> >
> > What is the harm about initially populating the encrypted key type with a known
> > mounting passphrase instead of random data?  For example, if the user has an
> > existing ecryptfs file system they now wish to protect with the TPM?  I don't
> > think it's the kernel's place to judge whether I think my payload has been
> > compromised or not, or if it is sufficiently random.  I cannot think of any
> > problem with this, so it seems to me, if it's not currently possible, this would
> > be an area of needed improvement in the kernel to enable the proposed real-world
> > use?
> 
> Yes, this would resolve the existing ecryptfs key usecase scenario, but
> I don't think it is needed for the initial use case scenario of a TPM
> failure.   A concern with this approach is how to safely initialize the
> encrypted key payload.   Its probably not a good idea to pass it on the
> command line.  Maybe prompt for it?

To clarify, there's not currently a way to do this then, right?  (i.e. I didn't
miss anything?)  After my initial e-mail, I examined kernel sources and I
couldn't spot anything that wasn't in the documentation, but I wanted to be
sure.

What if you just used a user key payload?  For example, specifying another key
instead of the key size like this:

    keyctl add encrypted mykey "new default trusted:master user:payload"

would read the payload of "payload" user key and use it as plaintext of the new
encrypted key, instead of generating a random key.  If <format> is ecryptfs,
then the user key would be expected to be an authentication token added to the
kernel by ecryptfs-add-passphrase (which handles prompting user).

James