[dm-crypt] LUKS2 and persistent keyrings to enable convenient EOL data destruction

[dm-crypt] LUKS2 and persistent keyrings to enable convenient EOL data destruction

[GMilos]

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.

Re: [dm-crypt] LUKS2 and persistent keyrings to enable convenient EOL data destruction

[Arno Wagner]

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