dm-crypt
dm-crypt is a cryptography module of the device mapper in the Linux kernel . With dm-crypt, data can be encrypted and decrypted using various algorithms. This can be applied to any device files , in most cases partitions, hard disks or logical drives ( LVM ). An additional layer is created here between (encrypted) (raw) data and the file system. This is done completely transparently for the user . dm-crypt is thus suitable for hard disk encryption(Partitions, entire hard disks, but also all other block-oriented devices such as logical drives (LVM) or loop devices). dm-crypt supports a variety of encryption algorithms, as it uses the Linux kernel's Crypto API.
Another approach is followed by (transparent) file encryption , in which the file system is responsible for encryption and decryption.
application
- Hard disk encryption to protect sensitive data against (offline) theft (especially for mobile devices such as notebooks ).
- Protection against data recovery after the sale or disposal of data carriers. Otherwise, sometimes complex procedures would be necessary to securely delete the data, such as overwriting or physically destroying the data carrier.
Encryption parameters
dm-crypt supports various encryption algorithms and operating modes. They are given in a special format (optional parts are given in square brackets):
- cipher [: keycount ] - chainmode - ivmode [: ivopts ]
The individual fields mean:
- cipher
- Name of the encryption algorithm used. For example
aes
,twofish
- keycount
- optional field for encryption with multiple keys (to be compatible with loop-aes)
- chainmode
- Encryption mode, e.g. B.
ecb
,cbc
- ivmode
- Type of initialization vector if the encryption mode requires one. Examples:
plain
,essiv
,lmk
- ivopts
- Optional parameter for ivmode, if required. z. B. the hash used in essive mode:
sha256
Examples:
twofish-ecb |
Twofish algorithm in ECB mode (not recommended) |
aes:64-cbc-lmk |
AES algorithm in CBC mode , in 64-key mode, with initialization vector method compatible with loop-aes |
aes-cbc-essiv:ripemd160 |
AES in CBC mode, whereby the initialization vectors are calculated with the RIPEMD-160 hash algorithm |
Extension with LUKS
A common extension is LUKS ("Linux Unified Key Setup"), which adds a header to the encrypted data in which metadata and up to eight keys are stored. Advantages over "pure" dm-crypt are: a standardized format, information about the type of encryption in the header, allocation of up to eight keys and the change and deletion of keys without rewriting the encrypted data.
Since the header that LUKS writes into the container contains a clear text identifier, the encryption and hash algorithms used and the size of the master key, LUKS containers can be recognized automatically and easily managed. It also makes the encryption visible to third parties and attack programs. This makes credible deniability difficult or even impossible. The LUKS header including key data also reduces the usable storage space on the medium by 1028 KiB (standard setting). In contrast to the central metadata of various file systems, such as B. the superblock at ext2 , this data that is important for the operation of the data carrier is not stored in a distributed replication on the medium. If they are overwritten or can no longer be read due to a hardware defect, the user data on the medium can no longer be decrypted without a backup of the header ( made possible by the cryptsetup management program).
On-disk format
A hard drive partition encrypted with LUKS has the following header (multi-byte values are saved in Big Endian format, plain text identifiers are filled with zero bytes if they are shorter than the intended storage space):
Offset | Data type | content | |
---|---|---|---|
0 | 0 hex | char [6] | Magic number {'L', 'U', 'K', 'S', 0xBA, 0xBE} |
6th | 6 hex | uint16_t | LUKS version (currently always 0x0001) |
8th | 8 hex | char [32] | Name of the encryption algorithm (e.g. "twofish" or "aes") |
40 | 28 hex | char [32] | Name of the encryption mode (e.g. "cbc-essiv: sha256") |
72 | 48 hex | char [32] | Name of the hash function (e.g. "sha1" or "ripemd160") |
104 | 68 hex | uint32_t | Offset to the data (in sectors) |
108 | 6C hex | uint32_t | Number of key bytes |
112 | 70 hex | char [20] | Checksum of the PBKDF2 master key |
132 | 84 hex | char [32] | Salt of the PBKDF2 master key |
164 | A4 hex | uint32_t | Number of PBKDF2 iterations (default: 10) |
168 | A8 hex | char [40] | UUID of the partition (in the usual hex format, e.g. "504c9fa7-d080-4acf-a829-73227b48fb89") |
208 | D0 hex | (48 bytes) | Keyslot 1 (see below) |
... | |||
544 | 220 hex | (48 bytes) | Keyslot 8 (see below) |
592 bytes total |
Each of the eight key slots has the following format:
Offset | Data type | content |
---|---|---|
0 | uint32_t | Status: Active = 0x00AC71F3; Inactive = 0x0000DEAD |
4th | uint32_t | Number of iterations for PBKDF2 |
8th | char [32] | Salt for PBKDF2 |
40 | uint32_t | Start sector for key data |
44 | uint32_t | Number of anti-forensic stripes (default: 4000) |
48 bytes total |
Comparison of LUKS versus simple dm-crypt
The following list does not claim to be complete. The relevance of the individual properties also varies depending on the intended use, so that this list does not allow a generally valid evaluation of LUKS.
- Plain text header
- Pro enables scripts without external configuration for the automatic integration of the data container
- plausible deniability Contra prevents
- Contra requires space on the data carrier; This means that a 1: 1 sector-by-sector copy of a (unencrypted or directly used as storage space) data carrier / partition in an encrypted LUKS container of the same size is not possible; the target drive (for the LUKS container) must be correspondingly larger.
- Cons In the case of errors in the header sector (which directly affect the key data) it is almost impossible to restore the remaining data without a header backup, even if it can still be read (encrypted).
- Key setup
- salts for keys and master keys make attacks with precalculated hashes more difficult Pro
- PBKDF2 requires increased computing effort due to the iterations, which slows down dictionary attacks to any configurable extent (but to the same extent as the integration of the volume) Pro
- Contra PBKDF2 leads to a noticeable delay when integrating the container on slow computers (the specified time is multiplied accordingly)
- Keyslots
- Pro allow multiple passwords / passphrases per data container, which can also be easily changed and deleted
- Contra take up space on the disk; This means that a sector-wise 1: 1 copy of an unencrypted data carrier in an encrypted LUKS container (e.g. for backups) of the same size is not possible
- Contra alone the presence of several Keyslots and gaps in Keyslotliste reveal details about the use of the data container.
LUKS2
Since Linux kernel version 4.12 there is a new LUKS version that offers some new functions:
- Authenticated Encryption - requires the "dm-integrity" feature, which was also introduced with Kernel version 4.12, in order to store the additional metadata per sector.
- Password derivation function Argon2 (in the variants Argon2i and Argon2id) which makes parallel brute force attacks more difficult
- Metadata and headers are now in JSON format and can be stored redundantly and also on separate data carriers.
- Support for external keystores and authentication methods
- Conversion from LUKS1 to LUKS2 (and vice versa) is possible on-the-fly, provided that no new features of LUKS2 are used.
disadvantage
Throughput
Due to the additional computational effort of the encryption algorithms, as with any hard disk encryption carried out in software, performance losses can arise: the data throughput is reduced compared to unencrypted data carriers. An improvement can be achieved through faster processors, multi-core processors , the optimization of the algorithms for the respective architecture or an implementation as hardware encryption.
Cryptographic vulnerability
Cryptographic attacks are partially conceivable on data encrypted with dm-crypt:
- Watermark attack if not configured with ESSIV
- Attack via a content leak
- Attack via a data modification leak
- general attacks on hard disk encryption methods
Alternatives and ports
With FreeOTFE there was an implementation for Windows compatible with LUKS until 2013 . The source code has been transferred to DoxBox, which was renamed LibreCrypt in 2015 from version 6.2ß. LibreCrypt runs on Microsoft Windows 10 and the source code can be downloaded from GitHub.
VeraCrypt is an alternative product for Windows and Linux that is almost comparable in terms of functionality .
literature
- Clemens Fruhwirth, Markus Schuster: Secret writing. Hard disk encryption with DM-Crypt and Cryptsetup-LUKS: Technology and application In: Linux-Magazin 08/2005. Linux New Media AG, pp. 28-36, ISSN 1432-640X , available online
- Frank Becker, Konrad Rosenbaum: Disk key - Crypto file systems on Linux . (PDF, 400 kB) Lecture at Chemnitz Linuxtag 2005
- Christian Ney, Peter Gutmann: Cheese with holes. Encrypted file systems under Linux . In: Linux-Magazin , 10/2006, pp. 36–44. Linux New Media AG, ISSN 1432-640X
Web links
- Mini-Howto for cryptsetup
- Website of dm-crypt (English)
- Website LUKS (English)
- Extensive article on the topic of LUKS
- LibreCrypt source code on GitHub
Individual evidence
- ↑ dm-crypt: Linux kernel device-mapper crypto target. Retrieved April 23, 2013 .
- ↑ LUKS On-Disk Format Specification. (PDF) Version 1.2.2. Retrieved March 19, 2017 .
- ↑ gitlab.com (PDF)
- ↑ Linux hard disk encryption settings , English
- ↑ Appendix A: Version History ( English ) GitHub, Inc. Accessed March 14, 2019.