About Opentopia
Opentopia Directory Encyclopedia Tools

Disk encryption

Encyclopedia : D : DI : DIS : Disk encryption

 

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.

Contents

Problem definition

Implementation of encrypted data storage on a sector-level–random-access device faces several constraints:

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 non-authorized 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.

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).

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.

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 ([C = P \oplus V]) it follows that given several ciphertexts the adversary knows that [C \oplus C' = P \oplus P'] 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.

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 ([C_i = E(C_ \oplus P_i)]) using (padded) sector number as IV: [C^_ = n \| 0]. Here IV is not secret and thus this scheme is vulnerable to a watermark attack: if, for example, the sector number 5 has [P^_0=0] and the next sector has [P^_0=1] then [C^_0 = E(5 \oplus 0) = E(6 \oplus 1) = C^_0]. 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: [C^)}_ = E(\textrm\|\textrm)]. Unfortunately, since [C_i] does not depend on [C_] 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): [C_ = H(\textrm\|n\|P_1\|\ldots\|P_)]. Since in order to decrypt [P_1] one only needs [C_0] and [C_1] he can decrypt [P_1, \ldots, P_], calculate [C_] 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 [P_1, \ldots, P_] of any sector: he replaces the ciphertext of his sector and asks the system to decrypt his sector. If [C_] 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) [#endnote_siswg-lrw] is an instantiation of the mode of operations introduced by Liskov, Rivest, and Wagner [#endnote_lrw] (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: [E_K(P \oplus T) \oplus T,] where [T = F \otimes I.] Here multiplication [\otimes] and addition [\oplus] are performed in the finite field ([\textrm(2^)] 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): [F \otimes I = F \otimes (I_0 \oplus \delta) = F \otimes I_0 \oplus F \otimes \delta], where [F \otimes \delta] are precomputed for all possible values of [\delta]. 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.) This mode is considered for standardization by Security in Storage Working Group (SISWG).

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_ = E_A(I)]), the ciphertext is masked by xoring with [2(C'_0 \oplus C'_),] 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 order to solve this problem, Halevi and Rogaway introduced a parallelizable variant called EME (ECB-mask-ECB). It works in the following way:

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 [#endnote_uspto-cmc-eme], unlike LRW.

See also

Sources

 

From Wikipedia, the Free Encyclopedia. Original article here. Support Wikipedia by contributing or donating.
All text is available under the terms of the GNU Free Documentation License See Wikipedia Copyrights for details.

Search Titles
0123456789
ABCDEFGHIJ
KLMNOPQRST
UVWXYZ?

E-mail this article to:

Personal Message: