If FEC was enabled, the error for bad root hash was replaced
by error correction (datga were ok, only root hash was wrong).
Do not run recovery test if root hash is incorrect.
To avoid confusion, use just one lib include and specify sub-directories
for format inclusions.
This should also help some analysis tools to find proper includes.
Add API call that can directly print JSON metadata area from LUKS2 device.
For commandline it also adds --dump-json-metadata option for luksDump action.
Note that the binary metadata (UUID, version etc) is not part of this output.
(We reserve flags parameter to be able to add this later.)
Fixes: #511
The code expects that change key is done in-place if there is not
a free space in keyslot area for safe key swap.
This patch makes the code behaves the same as in LUKS1,
luksChangeKey now works the same.
With JSON, we can actually retain the slot number in all cases
(except user intentionally set new slot #).
This patch changes the crypt_keyslot_change_by_passphrase() API
call to retain keyslot number for LUKS2.
Fixes: #464
This patch adds support for Linux kernel (since version 5.11) dm-integrity
fixes that disables integrity recalculation if keyed algorithms (HMAC) is used.
Original dm-integrity superblock version <=4 is recalculation offset
field not protected by HMAC. An attacker can move this pointer and force
the kernel to recalculate the data area, ignoring original HMAC tags.
N.B. dm-integrity was not intended to protect against intentional changes.
Better use authenticated encryption (AEAD) in combination with dm-crypt.
It is designed to protect against random data corruption caused by hardware
or storage medium faults.
Despite that, we try to keep the system secure if keyed algorithms are used.
There are two possible keyed algorithms in dm-integrity - algorithm used
to protect journal and superblock (--journal-integrity) and algorithms
for protecting data (--integrity).
The dm-integrity superblock is guarded by --journal-integrity, so if you want
to protect data with HMAC, you should always also use HMAC for --journal-integrity.
The keys are independent. If HMAC is used for data but not for the journal,
recalculation is disabled by default.
For new kernel dm-integrity, the HMAC option also uses salt in superblock
to avoid an easy way to distinguish that the HMAC key is the same for two devices
(if data are the same).
The new HMAC and superblock are enabled automatically if the kernel supports it
(you can see superblock version 5 and fix_hmac flag in dump command).
If you need to use (insecure) backward compatibility, then two new integritysetup
options are introduced:
Use --integrity-legacy-recalc (instead of --integrity-recalc) to allow recalculation
on legacy devices.
Use --integrity-legacy-hmac in format action to force old insecure version
format (with HMAC).
Libcryptsetup API also introduces flags
CRYPT_COMPAT_LEGACY_INTEGRITY_HMAC and
CRYPT_COMPAT_LEGACY_INTEGRITY_RECALC
to set these through crypt_set_compatibility() call.
LUKS2 decryption is currently not supported for devices
with LUKS2 metadata placed in head of data devices. The decryption
still works correctly, but resulting plaintext device has data on
unexpected (original) offset. For example at offset of 16MiB in case
of default LUKS2 header.
Fixes: #614.
crypt_header_is_detached checks if initialized LUKS context uses detached header
(LUKS header located on a different device than data.)
This is a runtime attribute, it does not say if a LUKS device requires detached header.
If user knows which particular PBKDF2 hash or cipher is used for
True/VeraCrypt container, using --hash of --cipher option in tcryptDump
and tcryptOpen can scan only these variants.
Note for the cipher it means substring (all cipher chains containing
the cipher are tried).
For example, you can use
cryptsetup tcryptDump --hash sha512 <container>
Note: for speed up, usually the hash option matters, cipher variants
are scanned very quickly.
Use witch care, in a script it can reveal some sensitive attribute
of the container.
Fixes#608.
We zero data parts of the test images to make them as small as
possible and for the latest startup key image I deleted bigger
portion of the NTFS header by accident which caused older blkid
on CentOS/RHEL 6 to not identify the NTFS filesystem on the
cleartext device.
These performance options, introduced in kernel 5.9, configures
dm-crypt to bypass read or write workqueues and run encryption
synchronously.
Also support persistent storage of these flags for LUKS2.
The issue can be reproduced very easily by starting 2 veritysetup processes
at the same time:
$ sudo veritysetup open -v ./img.raw img ./img.verity & sudo veritysetup open -v ./img.raw img ./img.verity
[1] 814021
device-mapper: create ioctl on img CRYPT-VERITY-cea03b7bc5b94e088e5754ff33be71d6-img failed: Device or resource busy
Verity device detected corruption after activation.
Command successful.
Command failed with code -1 (wrong or missing parameters).
Note how veritysetup open is reporting -EINVAL as the return code.
After the fix:
$ sudo veritysetup open -v ./img.raw img ./img.verity & sudo veritysetup open -v ./img.raw img ./img.verity
[1] 814649
Verity device detected corruption after activation.
Command successful.
Device img already exists.
Command failed with code -5 (device already exists or device is busy).
Introducing new version of crypt_reencrypt symbol including
previously missing usrptr parameter. This change should be
backward compatible for existing libcryptsetup users
until next recompilation where it needs to be fixed.
If users want to use blake2b/blake2s, the kernel algorithm name
includes dash - like "blake2s-256".
Because we use dash as a separator, this patch adds an exception
for this case.
Fixes: #581.
When creating LUKS2 header with specified --offset much larger
then LUKS2 header size we needlessly also wipe (allocate up to
--offset) much larger file than needed.
The iv_large_sector option is supported in dm-crypt since introduction
of larger sectors encryption.
It counts Initialization Vector (IV) in larger sector size (if set) instead
of 512 bytes sectors.
This option does not have any performance or security impact, but it can be
used for accessing incompatible existing disk images from other systems.
(It is used internally in BitLocker compatibily code).
This patch allows it to be used for plain type device, so users
can manually map foreign disk images.
Only open action with plain device and sector size > 512 bytes is supported.
We need to use the iv_large_sectors flag and correct sector size
for the crypt segments for these devices. Used sector size is
read from the device header. This commit also adds two new test
images with 4k sectors.
Fixes: #557
Adds option to dump content of LUKS2 unbound keyslot
in to a file:
'cryptsetup luksDump --unbound --master-key-file /file -S 12 /dev/luks2'
or to terminal:
'cryptsetup luksDump --unbound -S 12 /dev/luks2'
Parameters -S (specific keyslot) is mandatory with --unbound.
Fixes: #549
