All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] LUKS2 and persistent keyrings to enable convenient EOL data destruction
Date: Mon, 17 Dec 2018 12:31:25 +0100	[thread overview]
Message-ID: <20181217113125.GA15131@tansi.org> (raw)
In-Reply-To: <MTAwMDAyOC50aHdhcnRuZXQ.1544959828@quikprotect>

We have a situaion a bit like that: We need a person wth a specific
physical key (sealed envelope) to be able to (re-)boot a server with
encrypted storage. For that we have an USB key with hardcoded passphrase 
in the initrd. The key USB key is only plugged in at boot and then 
removed and locked into a safe.

Rapit detruction is not a feature but could be easily added
by wiping the LUKS header of the disk. A possible improvement
would be to delay network start until the USB key has been removed.

For the initrd, refer to the example in the crytsetup FAQ.

Regards,
Arno



On Sun, Dec 16, 2018 at 12:30:28 CET, GMilos wrote:
> The example by fossies (here:
> https://fossies.org/linux/cryptsetup/docs/Keyring.txt ) shows how to
> create a key bound to the thread keyring: the key is not persistent
> across sessions.
> 
> In my model, I am concerned about threats post disposal of the
> underlying device.  I also require unattended startup during the
> in-use lifetime (e.g. no manual passphrase entry).  Finally, I need
> rapid data destruction (e.g. faster than overwriting the underlying
> media).
> 
> One conceivable design is to use LUKS2-encrypted storage with a token
> linked to a persistent keyring (e.g. persistent across reboots).  Data
> destruction would be cost-effectively achieved by destroying the
> master-passphrase.
> 
> I note that there is a kernel feature for persistent keyrings, but
> such keyrings are not accessible to users (only authorized processes).
>  Is there a way to create a persistent token for this purpose?
> 
> Question:
> Can someone provide a line-by-line example of how to unlock a LUKS2
> container using a persistent token, if indeed it is  possible to do
> so.
> 
> An alternative design could be to place a key on removable media (also
> problematic; see separate post).  I would like to understand
> persistent tokens regardless.
> 
> Many thanks.
> 
> 
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

      reply	other threads:[~2018-12-17 11:37 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-16 11:30 [dm-crypt] LUKS2 and persistent keyrings to enable convenient EOL data destruction GMilos
2018-12-17 11:31 ` Arno Wagner [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=20181217113125.GA15131@tansi.org \
    --to=arno@wagner.name \
    --cc=dm-crypt@saout.de \
    /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.