We used to preset compat cipher and cipher_mode values during
crypt_format() or crypt_load(). Since we can change 'default segment'
dynamically during reencryption (encryption, decryption included) we
need to parse those values from default segment json encryption field
each time crypt_get_cipher() or crypt_get_cipher_mode() is called.
All previous version of cryptsetup wiped only first 4k for LUKS1
and both JSON areas for LUKS2 (first 32k) and the allocated
keyslot area (as it contained the generated key).
Remaining areas (unused keyslots, padding, and alignment) were
not wiped and could contain some previous data.
Since this commit, the whole area up to the data offset is zeroed,
and subsequently, all keyslots areas are wiped with random data.
Only exceptions are
- padding/alignment areas for detached header
if the data offset is set to 0
- bogus LUKS1 keyslot areas (upstream code never
created such keyslots but someone could use that).
This operation could slow down luksFormat on some devices, but
it guarantees that after this operation LUKS header does not
contain any foreign data.
device_topology_alignment routine already returns alignment offset
in bytes. There's no need to divide it by sector size, since LUKS2
format have all offsets and sizes stored in bytes.
crypt_wipe_device was called incorrectly on metadata device even
though integrity header is always on data device from cryptsetup
pov. During LUKS2 crypt_format with detached header scenario we
would wiped first 8 sectors of metadata device instead of data
device.
Move all messages to cryptsetup tools and print these
verbose messages:
- Key slot X unlocked.
- Key slot X created.
- Key slot X removed.
and
- Token X created.
- Token X removed.
Also print error, if unknown token is tried to be removed.
Also moves FIXME comment lower to LUKS2 code with note that currently it's
safe to do crypt_repair on LUKS2 format without paying attention to LUKS2
requirements.
We call crypt_random_init in init_crypto, but never call
crypt_random_exit. This change just copies what the crypt_backend
functions do, and calls crypt_random_exit in the descructor.
A keyslot not bound to any segment can store any key for any purpose.
To easily check slot status, new enum value is introduced.
This status is valid only for LUKS2, so the functions are backward compatible
with LUKS1.
We can't wipe (overwrite with random noise) wrapped key in
kernel. Such keys are usually structured and not only random
bytes.
Also it doesn't make sense to wipe these keys. They are supposed
to be protected (encrypted) by keys sealed in hardware.
TODO: tests: 1) with header, 2) without header (dm-crypt only),
3) arch with working paes cipher (at least).
Some ciphers and key sizes created on-disk metadata that cannot be used.
Use the same test for length-preserving cipher as LUKS1.
Also check if key for integrity algorithm is not too small.
Fixes#373.
Move all keyring functions to one place and separate LUKS2 specific
code to generic handling.
Also fix possible mismatch if volume key is in keyring but it is not native
LUKS2 device (libarary cannot process such a device properly).
This fixes crypt_keyslot_add_by_key where we were unable to store
keyslot (unbound to segment) with different key_size.
The code used (new) volume key size implicitly which could be wrong
if new size was not compatible with cipher parameter for keyslot area.
For now, crypto API quietly used cipher witout IV if a cipher
algorithm wihtou IV specificaton was used (e.g. aes-xts).
This caused fail later during activation.
This patch allows only two specific backed use without specified IV
(ECB mode and NULL cipher).
Also check cipher string early during parsing of CLI options.
When loading first dm-crypt table (or action that triggers dm-crypt
module load) we do not know dm-crypt version yet. Let's assume all
kernels before 4.15.0 are flawed and reject VK load via kernel keyring
service.
When dm-crypt is already in kernel, check for correct target version
instead (v1.18.1 or later).
The keyfile interface was designed, well, for keyfiles.
Unfortunately, a keyfile can be placed on a device and the size_t offset
can overflow.
We have to introduce new set of fucntions that allows 64bit offsets even on 32bit systems:
- crypt_resume_by_keyfile_device_offset
- crypt_keyslot_add_by_keyfile_device_offset
- crypt_activate_by_keyfile_device_offset
- crypt_keyfile_device_read
The new functions have added _device_ in name.
Old functions are just internall wrappers around these.
Also cryptsetup --keyfile-offset and --new-keyfile-offset must now
process 64bit offsets.
For more info see issue 359.
Reduce bloated code in low level keyring utilities code.
Move log messages higher the library code.
Also return -ENOTSUP when code was compiled out by configure
option.
