GitLab Commit is coming up on August 3-4. Learn how to innovate together using GitLab, the DevOps platform. Register for free: gitlabcommitvirtual2021.com

v2.3.0-ReleaseNotes 7.79 KB
Newer Older
Milan Broz's avatar
Milan Broz committed
1
2
3
Cryptsetup 2.3.0 Release Notes
==============================
Stable release with new experimental features and bug fixes.
Milan Broz's avatar
Milan Broz committed
4
5
6
7

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
Milan Broz's avatar
Milan Broz committed
8
native read-write access to BitLocker Full Disk Encryption devices.
Milan Broz's avatar
Milan Broz committed
9
10

The BITLK implementation is based on publicly available information
Milan Broz's avatar
Milan Broz committed
11
12
and it is an independent and opensource implementation that allows
to access this proprietary disk encryption.
Milan Broz's avatar
Milan Broz committed
13
14
15
16
17
18
19
20

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
Milan Broz's avatar
Milan Broz committed
21
22
  like libbde (that provide alternative approach to decode this format)
  we were able to verify cryptsetup implementation.
Milan Broz's avatar
Milan Broz committed
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

  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
Milan Broz's avatar
Milan Broz committed
41
42
  the proper filesystem driver). To access filesystem on the decrypted device
  you need properly installed driver (vfat, NTFS or exFAT).
Milan Broz's avatar
Milan Broz committed
43

Milan Broz's avatar
Milan Broz committed
44
  Foe AES-XTS, activation is supported on all recent Linux kernels.
Milan Broz's avatar
Milan Broz committed
45
46

  For older AES-CBC encryption, Linux Kernel version 5.3 is required
Milan Broz's avatar
Milan Broz committed
47
48
  (support for special IV variant); for AES-CBC with Elephant diffuser,
  Linux Kernel 5.6 is required.
Milan Broz's avatar
Milan Broz committed
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188

  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.

Milan Broz's avatar
Milan Broz committed
189
190
* Fail crypt_keyslot_get_pbkdf for inactive LUKS1 keyslot.

Milan Broz's avatar
Milan Broz committed
191
192
Libcryptsetup API extensions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Milan Broz's avatar
Milan Broz committed
193
The libcryptsetup API is backward compatible for existing symbols.
Milan Broz's avatar
Milan Broz committed
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209

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