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
prev parent 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.