summaryrefslogtreecommitdiffstats
path: root/docs/v2.3.0-ReleaseNotes
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-17 08:06:26 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-17 08:06:26 +0000
commit1660d4b7a65d9ad2ce0deaa19d35579ca4084ac5 (patch)
tree6cf8220b628ebd2ccfc1375dd6516c6996e9abcc /docs/v2.3.0-ReleaseNotes
parentInitial commit. (diff)
downloadcryptsetup-1660d4b7a65d9ad2ce0deaa19d35579ca4084ac5.tar.xz
cryptsetup-1660d4b7a65d9ad2ce0deaa19d35579ca4084ac5.zip
Adding upstream version 2:2.6.1.upstream/2%2.6.1upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'docs/v2.3.0-ReleaseNotes')
-rw-r--r--docs/v2.3.0-ReleaseNotes209
1 files changed, 209 insertions, 0 deletions
diff --git a/docs/v2.3.0-ReleaseNotes b/docs/v2.3.0-ReleaseNotes
new file mode 100644
index 0000000..a3eb3ec
--- /dev/null
+++ b/docs/v2.3.0-ReleaseNotes
@@ -0,0 +1,209 @@
+Cryptsetup 2.3.0 Release Notes
+==============================
+Stable release with new experimental features and bug fixes.
+
+Cryptsetup 2.3 version introduces support for BitLocker-compatible
+devices (BITLK format). This format is used in Windows systems,
+and in combination with a filesystem driver, cryptsetup now provides
+native read-write access to BitLocker Full Disk Encryption devices.
+
+The BITLK implementation is based on publicly available information
+and it is an independent and opensource implementation that allows
+one to access this proprietary disk encryption.
+
+Changes since version 2.2.2
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+* BITLK (Windows BitLocker compatible) device access
+
+ BITLK userspace implementation is based on the master thesis and code
+ provided by Vojtech Trefny. Also, thanks to other opensource projects
+ like libbde (that provide alternative approach to decode this format)
+ we were able to verify cryptsetup implementation.
+
+ NOTE: Support for the BITLK device is EXPERIMENTAL and will require
+ a lot of testing. If you get some error message (mainly unsupported
+ metadata in the on-disk header), please help us by submitting an issue
+ to cryptsetup project, so we can fix it. Thank you!
+
+ Cryptsetup supports BITLK activation through passphrase or recovery
+ passphrase for existing devices (BitLocker and Bitlocker to Go).
+
+ Activation through TPM, SmartCard, or any other key protector
+ is not supported. And in some situations, mainly for TPM bind to some
+ PCR registers, it could be even impossible on Linux in the future.
+
+ All metadata (key protectors) are handled read-only, cryptsetup cannot
+ create or modify them. Except for old devices (created in old Vista
+ systems), all format variants should be recognized.
+
+ Data devices can be activated read-write (followed by mounting through
+ the proper filesystem driver). To access filesystem on the decrypted device
+ you need properly installed driver (vfat, NTFS or exFAT).
+
+ Foe AES-XTS, activation is supported on all recent Linux kernels.
+
+ For older AES-CBC encryption, Linux Kernel version 5.3 is required
+ (support for special IV variant); for AES-CBC with Elephant diffuser,
+ Linux Kernel 5.6 is required.
+
+ Please note that CBC variants are legacy, and we provide it only
+ for backward compatibility (to be able to access old drives).
+
+ Cryptsetup command now supports the new "bitlk" format and implement dump,
+ open, status, and close actions.
+
+ To activate a BITLK device, use
+
+ # cryptsetup open --type bitlk <device> <name>
+ or with alias
+ # cryptsetup bitlkOpen <device> <name>
+
+ Then with properly installed fs driver (usually NTFS, vfat or exFAT),
+ you can mount the plaintext device /dev/mapper<name> device as a common
+ filesystem.
+
+ To print metadata information about BITLK device, use
+ # crypotsetup bitlkDump <device>
+
+ To print information about the active device, use
+ # cryptsetup status <name>
+
+ Example (activation of disk image):
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ # Recent blkid recognizes BitLocker device,just to verity
+ # blkid bitlocker_xts_ntfs.img
+ bitlocker_xts_ntfs.img: TYPE="BitLocker"
+
+ # Print visible metadata information (on-disk, form the image)
+ # cryptsetup bitlkDump bitlocker_xts_ntfs.img
+ Info for BITLK device bitlocker_xts_ntfs.img.
+ Version: 2
+ GUID: ...
+ Created: Wed Oct 23 17:38:15 2019
+ Description: DESKTOP-xxxxxxx E: 23.10.2019
+ Cipher name: aes
+ Cipher mode: xts-plain64
+ Cipher key: 128 bits
+
+ Keyslots:
+ 0: VMK
+ GUID: ...
+ Protection: VMK protected with passphrase
+ Salt: ...
+ Key data size: 44 [bytes]
+ 1: VMK
+ GUID: ...
+ Protection: VMK protected with recovery passphrase
+ Salt: ...
+ Key data size: 44 [bytes]
+ 2: FVEK
+ Key data size: 44 [bytes]
+
+ # Activation (recovery passphrase works the same as password)
+ # cryptsetup bitlkOpen bitlocker_xts_ntfs.img test -v
+ Enter passphrase for bitlocker_xts_ntfs.img:
+ Command successful.
+
+ # Information about the active device
+ # cryptsetup status test
+ /dev/mapper/test is active.
+ type: BITLK
+ cipher: aes-xts-plain64
+ keysize: 128 bits
+ ...
+
+ # Plaintext device should now contain decrypted NTFS filesystem
+ # blkid /dev/mapper/test
+ /dev/mapper/test: UUID="..." TYPE="ntfs"
+
+ # And can be mounted
+ # mount /dev/mapper/test /mnt/tst
+
+ # Deactivation
+ # umount /mnt/tst
+ # cryptsetup close test
+
+* Veritysetup now supports activation with additional PKCS7 signature
+ of root hash through --root-hash-signature option.
+ The signature uses an in-kernel trusted key to validate the signature
+ of the root hash during activation. This option requires Linux kernel
+ 5.4 with DM_VERITY_VERIFY_ROOTHASH_SIG option.
+
+ Verity devices activated with signature now has a special flag
+ (with signature) active in device status (veritysetup status <name>).
+
+ Usage:
+ # veritysetup open <data_device> name <hash_device> <root_hash> \
+ --root-hash-signature=<roothash_p7_sig_file>
+
+* Integritysetup now calculates hash integrity size according to algorithm
+ instead of requiring an explicit tag size.
+
+ Previously, when integritysetup formats a device with hash or
+ HMAC integrity checksums, it required explicitly tag size entry from
+ a user (or used default value).
+ This led to confusion and unexpected shortened tag sizes.
+
+ Now, libcryptsetup calculates tag size according to real hash output.
+ Tag size can also be specified, then it warns if these values differ.
+
+* Integritysetup now supports fixed padding for dm-integrity devices.
+
+ There was an in-kernel bug that wasted a lot of space when using metadata
+ areas for integrity-protected devices if a larger sector size than
+ 512 bytes was used.
+ This problem affects both stand-alone dm-integrity and also LUKS2 with
+ authenticated encryption and larger sector size.
+
+ The new extension to dm-integrity superblock is needed, so devices
+ with the new optimal padding cannot be activated on older systems.
+
+ Integritysetup/Cryptsetup will use new padding automatically if it
+ detects the proper kernel. To create a compatible device with
+ the old padding, use --integrity-legacy-padding option.
+
+* A lot of fixes to online LUKS2 reecryption.
+
+* Add crypt_resume_by_volume_key() function to libcryptsetup.
+ If a user has a volume key available, the LUKS device can be resumed
+ directly using the provided volume key.
+ No keyslot derivation is needed, only the key digest is checked.
+
+* Implement active device suspend info.
+ Add CRYPT_ACTIVATE_SUSPENDED bit to crypt_get_active_device() flags
+ that informs the caller that device is suspended (luksSuspend).
+
+* Allow --test-passphrase for a detached header.
+ Before this fix, we required a data device specified on the command
+ line even though it was not necessary for the passphrase check.
+
+* Allow --key-file option in legacy offline encryption.
+ The option was ignored for LUKS1 encryption initialization.
+
+* Export memory safe functions.
+ To make developing of some extensions simpler, we now export
+ functions to handle memory with proper wipe on deallocation.
+
+* Fail crypt_keyslot_get_pbkdf for inactive LUKS1 keyslot.
+
+Libcryptsetup API extensions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The libcryptsetup API is backward compatible for existing symbols.
+
+New symbols
+ crypt_set_compatibility
+ crypt_get_compatibility;
+ crypt_resume_by_volume_key;
+ crypt_activate_by_signed_key;
+ crypt_safe_alloc;
+ crypt_safe_realloc;
+ crypt_safe_free;
+ crypt_safe_memzero;
+
+New defines introduced :
+ CRYPT_BITLK "BITLK" - BITLK (BitLocker-compatible mode
+ CRYPT_COMPAT_LEGACY_INTEGRITY_PADDING - dm-integrity legacy padding
+ CRYPT_VERITY_ROOT_HASH_SIGNATURE - dm-verity root hash signature
+ CRYPT_ACTIVATE_SUSPENDED - device suspended info flag