**Disk encryption** is a special case of *data at rest* protection when the storage media is a sector-addressable device (e.g., a hard disk). This article presents cryptographic aspects of the problem. For discussion of different software packages devoted to this problem see disk encryption software. Hardware encryption devices for hard drives are discussed in disk encryption hardware. To protect confidentiality of the data stored on a computer disk a computer security technique called disk encryption is used. ...
To protect confidentiality of the data stored on a computer disk a computer security technique called disk encryption is used. ...
## Problem definition
Implementation of encrypted data storage on a sector-level–random-access device faces several constraints: - implementation shall efficiently encrypt and decrypt data in any sector,
- implementation shall use only constant amount of additional storage for a device of arbitrary size.
The strongest definition of security is as follows: An implementation is secure if an adversary, who can observe the raw device, provide plaintexts to be stored, and modify some ciphertexts, cannot deduce **any** information about the plaintext of each sector, except the information that sector *i* at time *t*_{0} was the same as the same sector *i* at time *t*_{1} (since we want to update only a single encrypted sector for each plain sector update this information cannot be hidden). The above definition addresses only the confidentiality requirements, the integrity requirement is that any unauthorized modifications of the raw device shall be noticed before the modified data is used. Unfortunately, it is impossible to implement this requirement in its totality because an adversary can rollback the device to one of its previous states. If we ignore the rollback attack of separate sectors then this requirement is straightforward to implement: an implementation needs to store a MAC of each sector: MAC (SectorNumber, SectorData) and verify the tag before decryption of each sector. In real life this scheme is almost never implemented, arguably, due to the fact that advanced disk encryption methods (such as LRW and CMC / EME) support pseudo-integrity: an adversary can replace some block (for LRW) or sector (CMC / EME) with some of its previous values, but if he uses some other data (e.g., some previous value of some other block or sector) then the decryption will be some random data which adversary cannot predict. Note that if we want to prevent **inconsistent** rollbacks, that is an attack where some sectors are replaced with the data they contain a week ago whereas some other sectors are not changed, then we need to use a hash tree with MAC of the root. A cryptographic message authentication code (MAC) is a short piece of information used to authenticate a message. ...
In computer science, hash trees, also known as Merkle (hash) trees or Tiger tree hashes, are an extension of the simpler concept hash list, which in turn is an extension of the old concept of hashing, for instance, a file. ...
## Simple approaches Note that (as usual in security) any implementation can be secure depending on the **threat model**. For example, if we want to "protect" a PC disk partition from the proverbial "kid sister" (ie, low technical capability snoop), it is likely to be enough to change the MBR to make the disk unreadable by standard OS tools. At the other extreme it may be enough for an adversary, who has lured the user to store some file, to know that the file is actually stored (e.g., to convince some Court that a chunk of random data found on the user's PC is actually an encrypted volume). The master boot record (MBR), also the partition sector, in IBM PC architecture, is the 512-byte (1/2 kilobyte) boot sector, i. ...
Although we want to encrypt a single sector (e.g., 512 bytes) a block cipher operates on a single block (commonly, 8 or 16 bytes) and thus to encrypt all *k* (64 or 32) blocks in the sector we have to use some mode of operation. Since the ECB mode always encrypts the same plaintext block into the same ciphertext it reveals data patterns and is thus insecure. Other simple modes of operation (CBC, CFB, OFB and CTR) require an IV (Initialization Vector—an auxiliary random input) for each chunk of blocks which are to be encrypted independently. Encryption Decryption In cryptography, a block cipher is a symmetric key cipher which operates on fixed-length groups of bits, termed blocks, with an unvarying transformation. ...
In cryptography, a block cipher operates on blocks of fixed length, often 64 or 128 bits. ...
In cryptography, a block cipher operates on blocks of fixed length, often 64 or 128 bits. ...
The plain text term has a different meaning. ...
In cryptography, a block cipher operates on blocks of fixed length, often 64 or 128 bits. ...
In cryptography, a block cipher operates on blocks of fixed length, often 64 or 128 bits. ...
Despite the fact that it is possible in practice to use the counter (CTR) mode with a single IV per volume, such uses are insecure if an adversary is able to gather several encrypted versions of the same sector. Since, in this particular mode of operation, the ciphertext of each fixed sector is a plaintext xored with a fixed value () it follows that given several ciphertexts the adversary knows that and thus (if enough information is known about possible values of the plaintexts, e.g., that they are from a file with English text) cryptanalysis will be straightforward. It is not always easy to tell if such a threat model is applicable. For example, it can be used if we want to protect the hard disk of a laptop so that, if stolen (only once!), no data can be recovered. On the other hand, if the encrypted volume is stored as a file it is possible that, due to inner working of a journaling file system, several versions of (some sectors of) the encrypted volume will be available to an adversary. This article is about algorithms for encryption and decryption. ...
A journaling file system is a file system that logs changes to a journal (usually a circular log in a specially-allocated area) before actually writing them to the main file system. ...
## CBC-based approaches Despite its deficiencies (described below) the CBC mode is still the most commonly used for disk encryption. Since we are not allowed to store an auxiliary information for IV of each sector we have to derive it from the sector number, its content, and some static information. Several such methods were proposed and used. The simplest method is to encrypt each sector in CBC mode () using (padded) sector number as IV: . Here IV is not secret and thus this scheme is vulnerable to a watermark attack: if, for example, the sector number 5 has and the next sector has then . So, for example, if the user stores a specially crafted file (sent to him by adversary) then an adversary has a proof that the file is indeed stored. In order to prevent this attack the ESSIV was introduced: . Unfortunately, since *C*_{i} does not depend on *C*_{i + 1} it follows that if only a block in the end of a sector is changed then all the preceding blocks stays the same, and thus an adversary who see the same sector before and after such a change knows that only part of it was changed. It is possible to prevent this attack if we derive IV from the data stored in the sector. One approach is to use hash of all the blocks starting from the second one (since we count from zero it has number 1): . Since in order to decrypt *P*_{1} one only needs *C*_{0} and *C*_{1} he can decrypt , calculate *C* _{− 1} and when decrypt *P*_{0}. With this method a change of any plaintext block inside a sector can change all the ciphertexts. Unfortunately, this method is about twice as slow as the previous one: each block (except the first one) has to be processed twice. And still there is an attack against it (and all the CBC-based approaches): suppose that an attacker is allowed to read some files on the device (but not all of them) and he can change the ciphertext. Using these capabilities he can read of any sector: he replaces the ciphertext of his sector and asks the system to decrypt his sector. If *C* _{− 1} depends on *n* then the first block is garbage, but all the other blocks depend only on the ciphertext and thus he receives the original plaintext.
## LRW In order to prevent such elaborate attacks, different modes of operation were introduced: tweakable narrow-block encryption (LRW) and wide-block encryption (CMC or EME). The narrow-block encryption (LRW) ^{[1]} is an instantiation of the mode of operations introduced by Liskov, Rivest, and Wagner ^{[2]} (see Theorem 2). This mode uses two keys: *K* is the key for the block cipher and *F* is an additional key of the same size as block. For example, if we want to use AES with a 256-bit key, then *K* is a 256-bit number and *F* is a 128-bit number. To encrypt block *P* with logical index *I* we use the following formula: where Here multiplication and addition are performed in the finite field (GF(2^{128}) for AES). With some precomputation only a single multiplication per sector is required (note that addition in a binary finite field is simple bitwise addition, also known as xor): , where are precomputed for all possible values of δ. This mode of operation needs only a single encryption per block and protects against all the above attacks except a minor leak: if the user changes a single plaintext block in a sector then only a single ciphertext block changes. (Note that this is not the same leak the ECB mode has: with LRW mode equal plaintexts in different positions are encrypted to random ciphertexts.) Arithmetic in a finite field is different from standard integer arithmetic. ...
LRW mode has been considered for the P1619 disk encryption standard developed by the IEEE Security in Storage Working Group (SISWG). In the Aug 30, 2006 meeting of the SISWG, by unanimous poll, decided to not go forward with LRW as specified in P1619.0 Draft 5 (which matches the above LRW description) because: - Significant key material can be leaked when LRW encrypts data that contains the LRW key
- LRW tweak collisions can lead to discovery of 1/2 of the LRW key and reduces LRW to the equivalent of ECB mode
- It can be shown by computing LRW collision probabilities that in order to keep the tweak collision below 1 in 2**40, one must not encrypt more than 141 terabytes with a single LRW key
The SISWG is looking into possible alternatives including a replacement tweak function and a completely new mode. This is subject to ongoing discussion within SISWG as of September 2006. The probability of the tweak key encrypting itself may be high for operating system encryption where the LRW (or a low-Hamming weight variant) may be written to swap that being encrypted with the same LRW key. In other situations such as when using on-the-fly volume encryption software like TrueCrypt the issue of encrypting the LRW key (or a low-Hamming weight variant) may be less of an issue due to the nature of how they handle LRW keys. There also exist methods that may further mitigate this issue such as the Encryption-Scheme Security in the Presence of Key-Dependent Messages method. TrueCrypt is a free open source on-the-fly encryption (OTFE) program for Microsoft Windows XP/2000/2003 and Linux. ...
Note that the above SWSIG concerns with P1619-LRW do not represent an exhaustive set of concerns with the LRW mode in general. For example, other concerns exist such as encrypting a low-Hamming weight variant of the key or when K2 resembles the plaintext but is not identical to the plaintext. The basic blocks of the LRW mode (AES cipher and Galois field multiplication are the same as the ones used in the Galois/Counter Mode (GCM) thus permitting a compact implementation of the universal LRW/GCM hardware. In abstract algebra, a finite field or Galois field (so named in honor of Evariste Galois) is a field that contains only finitely many elements. ...
GCM mode (Galois/Counter Mode) is a mode of operation for symmetric key cryptographic block ciphers. ...
## CMC and EME CMC and EME protect even against the minor leak mentioned above. Unfortunately, the price is a twofold degradation of performance: each block must be encrypted twice; many consider this to be too high a cost, since the same leak on a sector level is unavoidable anyway. CMC, introduced by Halevi and Rogaway, stands for CBC-mask-CBC: the whole sector encrypted in CBC mode (with *C* _{− 1} = *E*_{A}(*I*)), the ciphertext is masked by xoring with and decrypted in CBC mode starting from the last block. When the underlying block cipher is a strong pseudorandom permutation (PRP) then on the sector level the scheme is a tweakable PRP. One problem is that in order to decrypt *P*_{0} one must sequentially pass over all the data twice. In cryptography, a pseudorandom permutation, abbreviated PRP, is an idealized block cipher. ...
In order to solve this problem, Halevi and Rogaway introduced a parallelizable variant called EME (ECB-mask-ECB). It works in the following way: - the plaintexts are xored with
*L* = *E*_{K}(0), shifted by different amount to the left, and are encrypted: - the mask is calculated: where and
*M*_{C} = *E*_{K}(*M*_{P}); - intermediate ciphertexts are masked: for and
- the final plaintexts are calculated: for
Note that unlike LRW and CMC there is only a single key *K*. CMC and EME were considered for standardization by SISWG. However, eventually these modes were rejected because they are both patented ^{[3]} and because EME has been shown to be cryptographically flawed.^{[citation needed]}
**Warning: The use of EME mode is cryptographically unsound and is not recommended.**^{[citation needed]}
## See also To protect confidentiality of the data stored on a computer disk a computer security technique called disk encryption is used. ...
## Sources **↑** M. Liskov, R. Rivest, and D. Wagner. *Tweakable block ciphers* [4], CRYPTO '02 (LNCS, volume 2442), 2002. - S. Halevi and P. Rogaway,
*A Tweakable Enciphering Mode*, CRYPTO '03 (LNCS, volume 2729), 2003. - S. Halevi and P. Rogaway,
*A Parallelizable Enciphering Mode* [5], 2003. - Security in Storage Working Group SISWG.
- Standard Architecture for Encrypted Shared Storage Media, IEEE Project 1619 (P1619), PAR FORM.
- SISWG,
*Draft Proposal for Key Backup Format* [6], 2004. **↑** SISWG P1619 and P1619.1 up-to-date drafts can be obtained by searching email archives in Google [7] 2004. - SISWG,
*Draft Proposal for Tweakable Wide-block Encryption* [8], 2004. - James Hughes,
*Encrypted Storage - Challenges and Methods* [9] **↑** P. Rogaway, *Block cipher mode of operation for constructing a wide-blocksize block cipher from a conventional block cipher*, US Patent Application 20040131182 A1, [10] ## External links |