diff options
author | Ondrej Kozina <okozina@redhat.com> | 2016-11-21 15:58:51 +0100 |
---|---|---|
committer | Mike Snitzer <snitzer@redhat.com> | 2016-12-08 14:13:09 -0500 |
commit | c538f6ec9f56996677c58cfd1f7f8108b0a944cb (patch) | |
tree | e035520dd97d5cd8644a66e28c65879287e42082 /Documentation/device-mapper | |
parent | 0637018dff106e2591c1baa628e27a24a37ccf44 (diff) | |
download | linux-c538f6ec9f56996677c58cfd1f7f8108b0a944cb.tar.gz linux-c538f6ec9f56996677c58cfd1f7f8108b0a944cb.tar.bz2 linux-c538f6ec9f56996677c58cfd1f7f8108b0a944cb.zip |
dm crypt: add ability to use keys from the kernel key retention service
The kernel key service is a generic way to store keys for the use of
other subsystems. Currently there is no way to use kernel keys in dm-crypt.
This patch aims to fix that. Instead of key userspace may pass a key
description with preceding ':'. So message that constructs encryption
mapping now looks like this:
<cipher> [<key>|:<key_string>] <iv_offset> <dev_path> <start> [<#opt_params> <opt_params>]
where <key_string> is in format: <key_size>:<key_type>:<key_description>
Currently we only support two elementary key types: 'user' and 'logon'.
Keys may be loaded in dm-crypt either via <key_string> or using
classical method and pass the key in hex representation directly.
dm-crypt device initialised with a key passed in hex representation may be
replaced with key passed in key_string format and vice versa.
(Based on original work by Andrey Ryabinin)
Signed-off-by: Ondrej Kozina <okozina@redhat.com>
Reviewed-by: David Howells <dhowells@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Diffstat (limited to 'Documentation/device-mapper')
-rw-r--r-- | Documentation/device-mapper/dm-crypt.txt | 25 |
1 files changed, 24 insertions, 1 deletions
diff --git a/Documentation/device-mapper/dm-crypt.txt b/Documentation/device-mapper/dm-crypt.txt index 692171fe9da0..6f15fcea9566 100644 --- a/Documentation/device-mapper/dm-crypt.txt +++ b/Documentation/device-mapper/dm-crypt.txt @@ -21,13 +21,30 @@ Parameters: <cipher> <key> <iv_offset> <device path> \ /proc/crypto contains supported crypto modes <key> - Key used for encryption. It is encoded as a hexadecimal number. + Key used for encryption. It is encoded either as a hexadecimal number + or it can be passed as <key_string> prefixed with single colon + character (':') for keys residing in kernel keyring service. You can only use key sizes that are valid for the selected cipher in combination with the selected iv mode. Note that for some iv modes the key string can contain additional keys (for example IV seed) so the key contains more parts concatenated into a single string. +<key_string> + The kernel keyring key is identified by string in following format: + <key_size>:<key_type>:<key_description>. + +<key_size> + The encryption key size in bytes. The kernel key payload size must match + the value passed in <key_size>. + +<key_type> + Either 'logon' or 'user' kernel key type. + +<key_description> + The kernel keyring key description crypt target should look for + when loading key of <key_type>. + <keycount> Multi-key compatibility mode. You can define <keycount> keys and then sectors are encrypted according to their offsets (sector 0 uses key0; @@ -90,6 +107,12 @@ dmsetup create crypt1 --table "0 `blockdev --getsize $1` crypt aes-cbc-essiv:sha [[ #!/bin/sh +# Create a crypt device using dmsetup when encryption key is stored in keyring service +dmsetup create crypt2 --table "0 `blockdev --getsize $1` crypt aes-cbc-essiv:sha256 :32:logon:my_prefix:my_key 0 $1 0" +]] + +[[ +#!/bin/sh # Create a crypt device using cryptsetup and LUKS header with default cipher cryptsetup luksFormat $1 cryptsetup luksOpen $1 crypt1 |