The volume key structure may often be in configuration
where 'key' member does not contain real data. Some
examples:
- volume key acquired by querring device-mapper where key
was originaly passed by kernel keyring reference.
- volume key allocated by crypt_alloc_volume_key(size, NULL)
With this patch access to internal 'uninitialized' data result
in failed assert().
For use cases where key data are not needed (keyring reference wrapper,
key length info only) we do not have to allocate and lock the safe
buffer in memory.
Further improvements might to completely hide the volume key internals
and access only via setter and getter functions.
Switch current code to use following volume key helpers
for accessing internal properties:
crypt_volume_key_length(), crypt_volume_key_get_key(),
crypt_volume_key_description() and crypt_volume_key_kernel_key_type()
Remaining direct access to volume key internals will be dealt with in
later commits since it requires some further changes.
There were two different use cases for weaker keys:
1) empty keys (zero filled buffer)
2) weak 'random' keys not sucking entropy while being generated
Those key types must not be used to encrypt real data. It's used either
to check cipher can be configured sucessfully on the system or as
a fake envelope during metadata repair.
The volume key uploaded attribute is respected only with
regard to volume keys uploaded in the thread keyring in logon key type.
Here the uploaded attribute was set for volume keys uploaded in
custom user keyrings in custome key descriptions.
For now, we used zeroed key for dm-integrity format, as there was not
data area. In future, there can be wrapped key scheme, that will require
to setup real key even in this situation.
This patch modifies the integrity format flow that the real key is used
during format.
Mostly based on code from Ingo Franzki <ifranzki@linux.ibm.com>
This patch add support for setting of integrity key size
for LUKS2 devices.
It adds new (optional) JSON "key_size" attribute in segment.integrity JSON object.
If not set, the code use hash length size (backward compatible).
For LUKS2, we do not allow smaller keys than 128 bits.
Mostly based on code from Ingo Franzki <ifranzki@linux.ibm.com>
This patch implement support for setting specific integrity key size
option in dm-crypt, available since dm-crypt version 1.28.0.
This can be used for setting non-standard HMAC key length.
Mostly based on code from Ingo Franzki <ifranzki@linux.ibm.com>
There is no functional change in this patch except it avoids
strange confusion during some static tests.
The cd->type must be set in this function anyway.
This is only preparation for an extension later, however, the volume
keys should not be unloaded unconditionally from keyring.
Note that all other places dropping keys already check that keys
were uploaded through key ID setting.
(And for suspend unconditional unlink make sense too.)
The key_decripion always contains only a key name,
keyring then contains type of keyring as defned un keyring utils.
For now, only LOGON type is used in commands, it will be extended later.
The luks2_internal.h contains specific JSON implementations while
luks2.h is generic. Code outside of luks2/ dir should not use internals.
Also luks2.h includes functions prototypes that are used from setup.c.
There was a bug in both crypt_token_assign_keyslot and
crypt_token_unsassign_keyslot where CRYPT_ANY_TOKEN
special value could be passed in token parameter.
It would correctly assign/unassign all tokens to/from
the specified keyslot (or from any in case of CRYPT_ANY_SLOT),
but it returned -1 (CRYPT_ANY_TOKEN) which fited error return
values as per API documentation.
We fixed that by not supporting CRYPT_ANY_TOKEN since it does
not make much sense. It can be workarounded by iterating over
all available tokens and calling crypt_token_assign_keyslot or
crypt_token_unassign_keyslot accodingly.
Fixes: #914.
After switching to reencryption by keyslot context,
the digest was not properly verified before crash recovery.
We need to reverify reencryption digest after metadata
reloads unconditionally.
The check did not work properly for stacked dm_crypt over
hw opal devices.
Also it did not work at all for active dm mappings with
missing (or detached) LUKS2 metadata.
For device without a type code shoud not try to use
strcmp function.
This can happen for example if deferref flag is used
for device without proper DM-UUID where init_by_name
does not set know device type.
Thanks Clément Guérin for the report.
Fixes: #910
For LUKS2 headers with non zero data offset LUKS2_wipe_header_areas
will always erase the smallest from following:
- metadata device size
- data offset value
- maximal LUKS2 metadata size (twice 2 MiBs json area including 128 MiB for
binary keyslot areas) even with detached header.
For zero value data offset (LUKS2 header can not be restored back to
data device), we erase up to smallest from the following values:
- metadata device size
- maximal LUKS2 metadata size (twice 2 MiBs json area including 128 MiB for
This patch switches code to SPDX one-line license identifiers according to
https://spdx.dev/learn/handling-license-info/
and replacing long license text headers.
I used C++ format on the first line in style
// SPDX-License-Identifier: <id>
except exported libcryptsetup.h, when only C comments are used.
The only additional changes are:
- switch backend utf8.c from LGPL2+ to LGPL2.1+ (as in systemd)
- add some additional formatting lines.
Some Opal devices contain a bug that device reports different logical
size for block device and Opal SED layer.
This can happen for NVMe after reformatting with different LBAF (512/4096).
We will not support such configuration as Opal then calculates sizes
differently for locking range (that could lead to data corruption or
a partially unecrypted area).
Zoned device cannot be written with direct-io
and cannot be used for LUKS header logic without
significant changes. Do not allow to use them for LUKS header
but allow it for data device, as dm-crypt supports it.
Fixes: #877
hw-opal segment does not receive volume key for data
encryption, unlike crypt segment or hw-opal-crypt segment.
It gets key encryption key that is passed to device fw which
later unlocks the locking range key sealed in the device.
The assert may be skipped while volume key is not set.
Fixes: #875.
