crypt_reencrypt_status() returns this flag if old
online-reencrypt requirement is detected and reencryption
keyslot digest is missing.
crypt_reencrypt_init_by_passphrase() with same flag applied
repairs (upgrade) reencryption metadata so that
automatic reencryption recovery during activation
is again possible and reencryption operation can be resumed
post CVE-2021-4122 fix.
The function never writes on-disk. Also removed validation
function call-in since it will be called later before
writing on-disk and metadata does not have to be complete
at the moment of LUKS2_keyslot_reencrypt_allocate call.
The option --disable-luks2-reencryption completely disable
LUKS2 reencryption code.
When used, the libcryptsetup library can read metadata with
reencryption code, but all reencryption API calls and cryptsetup
reencrypt commands are disabled.
Devices with online reencryption in progress cannot be activated.
This option can cause some incompatibilities. Please use with care.
Fix possible attacks against data confidentiality through LUKS2 online
reencryption extension crash recovery.
An attacker can modify on-disk metadata to simulate decryption in
progress with crashed (unfinished) reencryption step and persistently
decrypt part of the LUKS device.
This attack requires repeated physical access to the LUKS device but
no knowledge of user passphrases.
The decryption step is performed after a valid user activates
the device with a correct passphrase and modified metadata.
There are no visible warnings for the user that such recovery happened
(except using the luksDump command). The attack can also be reversed
afterward (simulating crashed encryption from a plaintext) with
possible modification of revealed plaintext.
The problem was caused by reusing a mechanism designed for actual
reencryption operation without reassessing the security impact for new
encryption and decryption operations. While the reencryption requires
calculating and verifying both key digests, no digest was needed to
initiate decryption recovery if the destination is plaintext (no
encryption key). Also, some metadata (like encryption cipher) is not
protected, and an attacker could change it. Note that LUKS2 protects
visible metadata only when a random change occurs. It does not protect
against intentional modification but such modification must not cause
a violation of data confidentiality.
The fix introduces additional digest protection of reencryption
metadata. The digest is calculated from known keys and critical
reencryption metadata. Now an attacker cannot create correct metadata
digest without knowledge of a passphrase for used keyslots.
For more details, see LUKS2 On-Disk Format Specification version 1.1.0.
Original messages could evoke reencryption is currently
in progress. That was inaccurate because code only
detected flag marking such device is in transition state
from metadata pov. We should not imply anything about
running processes. That's detected via reencryption locks.
Currently hard memory limit is 1 GiB. Soft limit is
1/4 of system memory.
Note that --hotzone-size cryptsetup parameter can only further
lower hard and soft memory limit on hotzone size and not bypass
it.
If device properly exposes optimal io size, let's align
reencryption hotzone to it. Otherwise device-mapper driver
complaints about misaligned tables and reencryption performance
is not optimal.
Commit 4c73da31 exposed another bug in minimal device size check.
During reencryption initialization wrong data offset value was used
and adjusted as if device was already undergoing reencryption. The
bug fixed by commit 4c73da31 hid this bug.
This is hotfix only and following functions needs more review:
- LUKS2_reencrypt_data_offset
- LUKS2_get_data_offset
- luks2_check_device_size
- LUKS2_get_data_size
- Remove all 'LUKS2_' name prefixes from internal routines
- Make all internal routines prefixed with 'reencrypt_' instead
- Drop few static routines by refactoring
- Rename all variables and routines containing 'pre' prefix to
contain 'hot' prefix instead (when referring to segments
undergoing reencryption)
- Rename all variables and routines containing 'after' prefix to
contain 'post' prefix instead
- Rename all routines prefixed with '_' to 'reencrypt_' instead
If we initialized encryption with data shift and only single
segment the resulting metadata were missing
CRYPT_REENCRYPT_MOVE_FIRST_SEGMENT flag and also segments json section was
invalid.
