Prior to commit 0113ac2d88 it did
not matter what resilince metadata we stored during initialization.
So we stored 'none' type unless 'datashift' operation was initialized.
After the commit, it triggered reencryption metadata digest refresh
almost each time (except 'datashift') which was suboptimal.
By storing proper resilience type during reencryption initialization
we will avoid the needless reencryption digest refresh later (after
update optimization).
Attribute unused is useless and makes code imcomprehensible
when decorates internal functions not exposed via API.
Let's cleanup internal funtion prototypes whenever possible.
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.
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.
The crypt_activate_by_pin_token may be used only from new
dynamicly loadable token plugins.
Also refactors code for dynamically loadable plugins so
that it does not use crypt_token_handler structure anymore.
Old structure remains used only in crypt_token_register call.
* TRUE/FALSE are not defined anymore. 1 and 0 are used instead.
* json_object_get_uint64() and json_object_new_uint64() are part
of the upstream API now.
auto-recovery triggers any time when only single correct LUKS2
header instance was found. That may be dangerous.
We should suppress auto-recovery in case blkid decided the
device is no longer LUKS device. For example if secondary (intact)
LUKS2 header was left behind and blkid declares the device is LVM2
member.
Moreover if at least one header instance is corrupted and blkid
declares device non-empty and non-LUKS in the same time, header load
operation will be aborted with error.
- do not run general LUKS2 format validation from inside the specific one
- validate luks2 json object only
- temporary move digests count restrictions, going to be fixed in next
commit
This patch fixes several problems:
- pbkdf benchmark should be run with keyslot encryption key length
instead volume key length
- run LUKS2 keyslot validation on final keyslot json object instead
temporary stub created in keyslot_alloc
- replace whole json kdf object during keyslot update. We left behind
old parameters from old pbkdf during transition to differnt type
