ecryptfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "James Johnston" <johnstonj.public@codenest.com>
To: ecryptfs@vger.kernel.org, keyrings@vger.kernel.org
Subject: Practical use of ecryptfs, encrypted keys, and TPM: how to convert existing user key to encrypted key?
Date: Sat, 26 Mar 2016 20:46:32 -0000	[thread overview]
Message-ID: <001301d187a0$95552f40$bfff8dc0$@codenest.com> (raw)

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


             reply	other threads:[~2016-03-26 20:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-26 20:46 James Johnston [this message]
2016-03-28 14:59 ` Practical use of ecryptfs, encrypted keys, and TPM: how to convert existing user key to encrypted key? Mimi Zohar
2016-03-28 15:34   ` James Johnston
2016-03-28 17:02     ` Mimi Zohar
2016-03-28 23:25       ` James Johnston

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='001301d187a0$95552f40$bfff8dc0$@codenest.com' \
    --to=johnstonj.public@codenest.com \
    --cc=ecryptfs@vger.kernel.org \
    --cc=keyrings@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).