From: "James Johnston" <johnstonj.public@codenest.com>
To: 'Mimi Zohar' <zohar@linux.vnet.ibm.com>
Cc: ecryptfs@vger.kernel.org, keyrings@vger.kernel.org
Subject: RE: Practical use of ecryptfs, encrypted keys, and TPM: how to convert existing user key to encrypted key?
Date: Mon, 28 Mar 2016 23:25:11 -0000 [thread overview]
Message-ID: <007801d18949$141d56a0$3c5803e0$@codenest.com> (raw)
In-Reply-To: <1459184523.2751.142.camel@linux.vnet.ibm.com>
> > > > 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
prev parent reply other threads:[~2016-03-28 23:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-26 20:46 Practical use of ecryptfs, encrypted keys, and TPM: how to convert existing user key to encrypted key? James Johnston
2016-03-28 14:59 ` Mimi Zohar
2016-03-28 15:34 ` James Johnston
2016-03-28 17:02 ` Mimi Zohar
2016-03-28 23:25 ` James Johnston [this message]
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='007801d18949$141d56a0$3c5803e0$@codenest.com' \
--to=johnstonj.public@codenest.com \
--cc=ecryptfs@vger.kernel.org \
--cc=keyrings@vger.kernel.org \
--cc=zohar@linux.vnet.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.