|
| 1 | +======== |
| 2 | +dm-inlinecrypt |
| 3 | +======== |
| 4 | + |
| 5 | +Device-Mapper's "inlinecrypt" target provides transparent encryption of block devices |
| 6 | +using the inline encryption hardware. |
| 7 | + |
| 8 | +For a more detailed description of inline encryption, see: |
| 9 | +https://docs.kernel.org/block/inline-encryption.html |
| 10 | + |
| 11 | +Parameters:: |
| 12 | + |
| 13 | + <cipher> <key> <iv_offset> <device path> \ |
| 14 | + <offset> [<#opt_params> <opt_params>] |
| 15 | + |
| 16 | +<cipher> |
| 17 | + Encryption cipher type. |
| 18 | + |
| 19 | + The cipher specifications format is:: |
| 20 | + |
| 21 | + cipher |
| 22 | + |
| 23 | + Examples:: |
| 24 | + |
| 25 | + aes-xts-plain64 |
| 26 | + |
| 27 | + The cipher type is correspond one-to-one with encryption modes. For |
| 28 | + instance, the corresponding crypto mode of aes-xts-plain64 is |
| 29 | + BLK_ENCRYPTION_MODE_AES_256_XTS. |
| 30 | + |
| 31 | +<key> |
| 32 | + Key used for encryption. It is encoded either as a hexadecimal number |
| 33 | + or it can be passed as <key_string> prefixed with single colon |
| 34 | + character (':') for keys residing in kernel keyring service. |
| 35 | + You can only use key sizes that are valid for the selected cipher. |
| 36 | + Note that the size in bytes of a valid key must be in bellow range. |
| 37 | + |
| 38 | + [BLK_CRYPTO_KEY_TYPE_RAW, BLK_CRYPTO_KEY_TYPE_HW_WRAPPED] |
| 39 | + |
| 40 | +<key_string> |
| 41 | + The kernel keyring key is identified by string in following format: |
| 42 | + <key_size>:<key_type>:<key_description>. |
| 43 | + |
| 44 | +<key_size> |
| 45 | + The encryption key size in bytes. The kernel key payload size must match |
| 46 | + the value passed in <key_size>. |
| 47 | + |
| 48 | +<key_type> |
| 49 | + Either 'logon', or 'trusted' kernel key type. |
| 50 | + |
| 51 | +<key_description> |
| 52 | + The kernel keyring key description inlinecrypt target should look for |
| 53 | + when loading key of <key_type>. |
| 54 | + |
| 55 | +<iv_offset> |
| 56 | + The IV offset is a sector count that is added to the sector number |
| 57 | + before creating the IV. |
| 58 | + |
| 59 | +<device path> |
| 60 | + This is the device that is going to be used as backend and contains the |
| 61 | + encrypted data. You can specify it as a path like /dev/xxx or a device |
| 62 | + number <major>:<minor>. |
| 63 | + |
| 64 | +<offset> |
| 65 | + Starting sector within the device where the encrypted data begins. |
| 66 | + |
| 67 | +<#opt_params> |
| 68 | + Number of optional parameters. If there are no optional parameters, |
| 69 | + the optional parameters section can be skipped or #opt_params can be zero. |
| 70 | + Otherwise #opt_params is the number of following arguments. |
| 71 | + |
| 72 | + Example of optional parameters section: |
| 73 | + allow_discards sector_size:4096 iv_large_sectors |
| 74 | + |
| 75 | +allow_discards |
| 76 | + Block discard requests (a.k.a. TRIM) are passed through the inlinecrypt |
| 77 | + device. The default is to ignore discard requests. |
| 78 | + |
| 79 | + WARNING: Assess the specific security risks carefully before enabling this |
| 80 | + option. For example, allowing discards on encrypted devices may lead to |
| 81 | + the leak of information about the ciphertext device (filesystem type, |
| 82 | + used space etc.) if the discarded blocks can be located easily on the |
| 83 | + device later. |
| 84 | + |
| 85 | +sector_size:<bytes> |
| 86 | + Use <bytes> as the encryption unit instead of 512 bytes sectors. |
| 87 | + This option can be in range 512 - 4096 bytes and must be power of two. |
| 88 | + Virtual device will announce this size as a minimal IO and logical sector. |
| 89 | + |
| 90 | +iv_large_sectors |
| 91 | + IV generators will use sector number counted in <sector_size> units |
| 92 | + instead of default 512 bytes sectors. |
| 93 | + |
| 94 | + For example, if <sector_size> is 4096 bytes, plain64 IV for the second |
| 95 | + sector will be 8 (without flag) and 1 if iv_large_sectors is present. |
| 96 | + The <iv_offset> must be multiple of <sector_size> (in 512 bytes units) |
| 97 | + if this flag is specified. |
| 98 | + |
| 99 | +Example scripts |
| 100 | +=============== |
| 101 | +LUKS (Linux Unified Key Setup) is now the preferred way to set up disk |
| 102 | +encryption with dm-inlinecrypt using the 'cryptsetup' utility, see |
| 103 | +https://gitlab.com/cryptsetup/cryptsetup |
| 104 | + |
| 105 | +:: |
| 106 | + |
| 107 | + #!/bin/sh |
| 108 | + # Create a inlinecrypt device using dmsetup |
| 109 | + dmsetup create inlinecrypt1 --table "0 `blockdev --getsz $1` inlinecrypt aes-xts-plain64 babebabebabebabebabebabebabebabebabebabebabebabebabebabebabebabe 0 $1 0" |
| 110 | + |
| 111 | +:: |
| 112 | + |
| 113 | + #!/bin/sh |
| 114 | + # Create a inlinecrypt device using dmsetup when encryption key is stored in keyring service |
| 115 | + dmsetup create inlinecrypt2 --table "0 `blockdev --getsz $1` inlinecrypt aes-xts-plain64 :64:logon:fde:dminlinecrypt_test_key 0 $1 0" |
| 116 | + |
| 117 | +:: |
| 118 | + |
| 119 | + #!/bin/sh |
| 120 | + # Create a inlinecrypt device using cryptsetup and LUKS header with default cipher |
| 121 | + cryptsetup luksFormat $1 |
| 122 | + cryptsetup luksOpen $1 inlinecrypt1 |
0 commit comments