Llewellyn
/
Tomb
mirror of https://github.com/Llewellynvdm/Tomb.git
1
1
Fork 0
Code Issues Packages Projects Releases Wiki Activity
Tomb/doc/LinuxHDEncSettings.txt

405 lines
20 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Linux hard disk encryption settings
This page intends to educate the reader about the existing weaknesses
of the public-IV on-disk format commonly used with cryptoloop and
dm-crypt (used in IV-plain mode). This page aims to facilitate risk
calculation when utilising Linux hard disk encryption. The attacks
presented on this page may pose a thread to you, but at the same time
may be totally irrelevant for others. At the end of this document, the
reader should be able to make a good choice according to his security
needs.
A good quote with respect to this topic is ''All security involves
trade-offs'' from Beyond Fear (Bruce Schneier). You should keep in mind
that perfect security is unachievable and by all means shouldn't be
your goal. For instance, when using pass phrase based cryptography, you
have to trust in that the underlying system is secure, the computer
system has not been tampered with, and nobody is watching you. The most
obvious weakness is the last one, but even if you make sure nobody nor
any camera is around, how about the keyboard you're typing on? Has it
been manipulated while you have been getting your lunch?
So security comes for a price, and the price when designing
cryptography security algorithms is performance. You will be introduced
to the fastest of all setups available, the "public-IV", which
sacrifices security properties for speed. After that we will talk about
ESSIV, the newest of IV modes implemented. It comes for a small price,
but it can deal with watermarking for a relatively small price. Then
you'll be introduced to the draft specifications of the Security in
Storage Working Group ([18]SISWG). Currently SISWG is considering EME
and LRW for standardisation. EME along with it's cousin CMC seems to
provide the best security level, but imposes additional encryption
steps. Plumb-IV is discussed only for reference, because it has the
same performance penalty as CMC, but in contrast suffers from
weaknesses of CBC encryption.
As convention, this document will use the term "blocks", when it
refers to a single block of plain or cipher text (usually 16 byte),
and will use the term "sectors", when it refers to a 512-byte wide hard
disk block.
CBC Mode: The basic level
Most hard disk encryption systems utilise CBC to encrypt bulk data.
Good descriptions on CBC and other common cipher modes are available at
* [19]Wikipedia
* [20]Connected: An Internet Encyclopedia
* [21]NIST: Recommendation for Block Cipher Modes of Operation (CBC
is at PDF Page 17)
Please make sure you're familiar with CBC before proceeding.
Since CBC encryption is a recursive algorithm, the encryption of the
n-th block requires the encryption of all preceding blocks, 0 till n-1.
Thus, if we would run the whole hard disk encryption in CBC mode, one
would have to re-encrypt the whole hard disk, if the first computation
step changed, this is, when the first plain text block changed. Of
course, this is an undesired property, therefore the CBC chaining is
cut every sector and restarted with a new initialisation vector (IV),
so we can encrypt sectors individually. The choice of the sector as
smallest unit matches with the smallest unit of hard disks, where a
sector is also atomic in terms of access.
For reference, I will give a formal definition of CBC encryption and
decryption. Note, that decryption is not recursive, in contrast to
encryption, since it's a function only of C[n-1] and C[n].
Encryption:
C[-1] = IV
C[n] = E(P[n] ⊕ C[n-1])
Decryption:
C[-1] = IV
P[n] = C[n-1] ⊕ D(C[n])
The next sections will deal with how this IV is chosen.
The IV Modes
The "public-IV"
The IV for sector n is simply the 32-bit version of the number n
encoded in little-endian padded with zeros to the block-size of the
cipher used, if necessary. This is the most simple IV mode, but at the
same the most vulnerable.
ESSIV
E(Sector|Salt) IV, short ESSIV, derives the IV from key material via
encryption of the sector number with a hashed version of the key
material, the salt. ESSIV does not specify a particular hash algorithm,
but the digest size of the hash must be an accepted key size for the
block cipher in use. As the IV depends on a none public piece of
information, the key, the sequence of IV is not known, and the attacks
based on this can't be launched.
plumb IV
The IV is computed by hashing (or MAC-ing) the plain text from the
second block till the last. Additionally, the sector number and the key
are used as input as well. If a byte changes in the plain text of the
blocks 2 till n, the first block is influenced by the change of the IV.
As the first encryption effects all subsequent encryption steps due to
the nature of CBC, the whole sector is changed.
Decryption is possible because CBC is not recursive for decryption. The
prerequisites for a successful CBC decryption are two subsequent cipher
blocks. The former one is decrypted and the first one is XOR-ed into
the decryption result yielding the original plain text. Therefore
independent of the IV scheme, decryption is possible from the 2nd to
the last block. After the recovery of these plain text blocks, the IV
can be computed, and finally the first block can be decrypted as well.
The only weakness of this scheme is it's performance. It has to process
data twice: first for obtaining the IV, and then to produce the CBC
encryption with this IV. With the same performance penalty CMC is able
to achieve better security properties (CMC is discussed later), thus
plumb-IV will remain unimplemented.
The attack arsenal
Content leaks
This attack can be mounted against any system operating in CBC Mode. It
rests on the property, that in CBC decryption, the preceding cipher
block's influence is simple, that is, it's XORed into the plain text.
The preceding cipher block, C[n-1], is readily available on disk (for n
> 0) or may be deduced from the IV (for n = 0). If an attacker finds
two blocks with identical cipher text, he knows that both cipher texts
have been formed according to:
C[m] = E(P[m] ⊕ C[m-1] )
C[n] = E(P[n] ⊕ C[n-1] )
Since he found that C[m] = C[n], it holds
P[m] ⊕ C[m-1] = P[n] ⊕ C[n-1]
which can be rewritten as
C[m-1] ⊕ C[n-1] = P[n] ⊕ P[m]
The left hand side is known to the attacker by reading the preceding
cipher text from disk. If one of the blocks is the first block of a
sector, the IV must be examined instead (when it's available as it is
in public-IV). The attacker is now able to deduce the difference
between the plain texts by examining the difference of C[m-1] and
C[n-1]. If one of the plain text blocks happens to be zero, the
difference yields the original content of the other related plain text
block.
Another information is available to the attacker. Any succeeding
identical pair of cipher text, that follows the initial identical
cipher pair, is equal. No information about the content of those pairs
can be extracted, since the information is extracted from the
respective preceding cipher blocks, but those are all required to be
equal.
Let's have a look at the chance of succeeding with this attack.
Assuming the output of a cipher forms an uniform distribution, the
chance, p, of finding an identical block is 2^-blocksize. For instance,
p = 1/2^128 for a 128-bit cipher. Because the number of possible pairs
develops as an arithmetic series in n, the number of sectors, the
chance of not finding two identical blocks is given by
(1-p)^n(n-1)/2
As p is very small, but in contrast the power is very big, we apply the
logarithm to get meaningful answers, that is
n(n-1)/2 ln (1-p)
An example: The number of cipher blocks available on 200GB disk with
known C[n-1] is 200GB × 1024^2 KB/GB × 64/1KB ^1. Or in other words, a
128-bit block is 16 bytes, so the number of 16-byte blocks in a 200GB
hard disk is 13.4 billion. Therefore, n = 1.342e10. For a 128-bit
cipher, p = 2^-128. Hence,
ln(1-p) = -2.939e-39
n(n-1)/2 = 9.007e19
n(n-1)/2 ln (1-p) = -2.647e-19
1-e^-2.776e-13 = 2.647e-19
The last term is the chance of finding at least one pair of identical
cipher blocks. But how does this number grow in n? Obviously
exponentially. Plotting a few a decimal powers shows that the chance
for finding at least on identical cipher pair flips to 1 around n =
10^20 (n = 10^40 for a 256-bit cipher). This inflection point is reached
for a 146 million TB storage (or a hundred thousand trillion trillions
TB storage for a 256-bit cipher).
^1The blocks with available preceding cipher blocks is 62/1KB for all
non-public IV schemes, i.e. ESSIV/plumb IV
Data existence leak: The Watermark
No IV format discussed on this page allows the user to deny the
existence of encrypted data. Neither cryptoloop nor dm-crypt is an
implementation of a deniable cryptography system. But the problem is
more serious with public-IV.
With public IV and the predicable difference it introduces in the first
blocks of a sequence of plain text, data can be watermarked, which
means, the watermarked data is detectable even when the key has not
been recovered. As shown in the paragraph above, the existence of two
blocks with identical cipher text is very unlikely and coincidence can
be excluded, which is relevant when somebody tries to demonstrate
before the law that certain data is in an encrypted partition.
As the IV progresses with a foreseeable pattern and is guaranteed to
change the least significant bit ever step, we can build identical pair
of cipher text by writing three consecutive sectors each with a flipped
LSB relative to the previous. (The reason it's three instead of two is,
that the second least significant bit might change as well.) This
"public-IV"-driven CBC encryption will output exactly the same cipher
text for two consecutive sectors. An attacker can search the disk for
identical consecutive blocks to find the watermark. This can be done in
a single pass, and is much more feasible than finding to identical
blocks, that are scattered on the disk, as in the previous attack. A
few bits of information can be encoded into the watermarks, which might
serve as tag to prove the existence copyright infringing material.
A complete description of watermarking can be found in [22]Encrypted
Watermarks and Linux Laptop Security. The attack can be defeated by
using ESSIV.
Data modification leak
CBC encryption is recursive, so the n-th block depends on all previous
blocks. But the other way round would also be nice. Why? The weakness
becomes visible, if storage on a remote computer is used, or more
likely, the hard disk exhibits good forensic properties. The point is,
the attacker has to have access to preceding (in time) cipher text of a
sector, either by recording it from the network, or by using forensic
methods.
An attacker can now guess data modification patterns by examining the
historic data. If a sector is overwritten with a partial changed plain
text, there is an amount of bytes at the beginning, which are
unchanged. This point of change^2 is directly reflected in the cipher
text. So an attacker can deduce the point of the change in plain text
by finding the point where the cipher text starts to differ.
This weakness is present in public-IV and ESSIV.
^2aligned to the cipher block size boundaries
Malleable plain text
The decryption structure of CBC is the source of this weakness.
Malleability (with respect to cryptography) is defined as a
modification of the cipher text that will resulting in a predictable
change in plain text. To put it formally, there is a function f(C),
that, if applied to the cipher text, C' = f(C), will result in a known
function f', which will predict the resulting plain text, P' = D(C'),
correctly assuming P is known, that is P' = f'(P).
As we can see in it's definition, CBC decryption depends on C[n-1]. An
attacker can flip arbitrary bits in the plain text by flipping bit in
C[n-1]. More formally^3, if
P = P[1] || P[2] || ... || P[i] || ... || P[n]
C = E[CBC](P)
C = C[1] || C[2] || ... || C[i-1] || ... || C[n]
the function
f(C[1] || ... || C[n]) = C[1] || ... || C[i-1] XOR M || ... || C[n]
follows the function f', which predicts the resulting plain text
correctly as,
f'(P[1] || ... || P[n]) = P[1] || ... || P[i] XOR M || ... || P[n]
The first block of the CBC cipher text stream is not malleable, because
it depends on the IV, which is not modifiable for an attacker.
^3The IV parameter for E[CBC] has been intentionally omitted.
Movable
On the expense of one block decrypting to garbage, an attacker can move
around plain text as he likes. CBC decryption depends on two variables,
C[n-1] and C[n]. Both can be modified at free will. To make meaningful
modifications, an attacker has to replace the pair C[n-1] and C[n] with
other cipher text pair from disk. The first block C[n-1] will decrypt
to garbage, but the second block C[n] will yield a copy of the plain
text of the copied cipher block. This attack is also known as
copy&paste attack. This attack is mountable against any CBC setup. The
only limitation is, the first block, C[0], can't be replaced with
something meaningful, as C[-1] can't be modified, because it's the IV.
CMC and EME: Tweakable wide block cipher modes
CMC is a new chaining mode. It stands for ''CBC-Mask-CBC''. It works by
processing the data in three steps, first CBC, then masking the cipher
text, and then another CBC step, but this time backwards. The last step
introduces a dependency from the last block to the first block. The
authors of the CMC paper provide a prove for the security of this mode,
making a secure 128-bit cipher a secure 4096-bit cipher (sector size).
As in normal CBC, this scheme also takes an IV, but the authors call it
tweak.
EME is CMC's cousin. EME has also been authored by Haveli and Rogaway
as well been authored for the same purpose. The difference to CMC is,
that EME is parallelizable, that is, all operations of the underlying
cipher can be evaluated in parallel. To introduce an interdependency
among the resulting cipher blocks, the encryption happens in two
stages. Between these stages a mask is computed from all intermediate
blocks and applied to each intermediate block. This step causes an
interdependency among the cipher blocks. After applying the mask,
another encryption step diffuses the mask.
The interdependency among the resulting blocks allow CMC and EME to be
nonmovable, nonmalleable, to prevent content leaks and in-sector data
modification patterns. The tweaks are encrypted by both cipher modes,
thus both are nonwatermarkable.
For simplicity, the EME description above omitted the pre- and post-
whitening steps as well as the multiplications in GF(2^128). An
in-depth specification can be found at the [23]Cryptology ePrint
Archive. An applicable draft specification for EME-32-AES can be found
at [24]SISWG. I have written an EME-32-AES test implementation for
Linux 2.6. It's available [25]here. The CMC paper is available from the
[26]Cryptology ePrint Archive as well.
LRW: A tweakable narrow block cipher mode
EME as well as CMC are comparatively secure cipher modes, but heavy in
terms of performance. LRW tries to cope with most of security
requirements, and at the same time provide a good performance. LRW is a
narrow block cipher mode, that is, it operates only on one block,
instead of a whole sector. To make a cipher block tied to a location on
disk (to make it unmovable), a logical index is included in the
computation. For LRW you have to provide two keys, one for the cipher
and one for the cipher mode. The second key is multiplied with a
logical index under GF(2^128) and used as pre- and post- whitening for
encryption. With those whitening steps the block is effectively tied to
a logical index. The logical index is usually the absolute position on
disk measured with the block size of the cipher algorithm. The
different choice of the measuring unit is the only different between
the logical index and the public-IV.
The LRW draft is available from the [27]SISWG mailing list archive.
Summarising
The following table shows a comparison between the security properties
of different encryption setups and their computational costs. The
number of cipher calls, XOR operations and additional operations are
stated in terms of encryption blocks, n.
IV mode cipher mode content leaks watermarkable malleable movable
modification detection^5 cipher calls XOR ops additional op.
public-IV CBC Yes Yes Yes Yes Yes n n None
ESSIV CBC Yes No Yes Yes Yes n+1 n None
Plumb-IV1^4 CBC Yes No Yes Yes No 2n-1 2n None
public-IV CMC No No No No No 2n+1 2n+1 1 LW GF ⊗
public-IV EME No No No No No 2n+1 5n 3n-1 LW GF ⊗
public-IV LRW No No No No Yes n 2n n HW GF ⊗
Legend:
* LW GF ⊗: light-weight Galois field multiplication, that is, a
multiplication with a constant x^2^i, which can be computed in
θ(1).
* HW GF ⊗: heavy-weight Galois field multiplication, that is, a
multiplication with an arbitrary constant, which can be computed in
θ(bits).
^4plumb-IV1 uses CBC-MAC instead of hashing, so we can make a good
comparison with other ciphers in terms of cipher/XOR calls.
^5detectable partial in-sector modification
__________________________________________________________________
Clemens Fruhwirth, , also author of LUKS and ESSIV, porter of
cryptoloop, aes-i586 for 2.6., twofish-i586, and implementor of
EME-32-AES. This text is an excerpt of my diploma thesis.
This page has been reviewed by
Dr. Ernst Molitor
Arno Wagner
James Hughes , "Security in Storage Working Group" chair
Additional thanks to Pascal Brisset, for pointing out an error in the
Bernoulli estimation in an earlier version of this document, further
Adam J. Richter for pointing out an error in the KB/GB ratio.
Content and design, Copyright © 2004-2008 Clemens Fruhwirth, unless
stated otherwise
Original design by [28]haran | Additional art by [29]LinuxArt | | Blog
by [30]NanoBlogger
References
1. http://clemens.endorphin.org/
2. http://clemens.endorphin.org/credits
3. http://clemens.endorphin.org/aboutme
4. http://clemens.endorphin.org/cryptography
5. http://blog.clemens.endorphin.org/
6. http://clemens.endorphin.org/patches
7. http://clemens.endorphin.org/archive
8. http://clemens.endorphin.org/Cryptoloop_Migration_Guide
9. http://clemens.endorphin.org/LUKS
10. http://clemens.endorphin.org/AFsplitter
11. http://clemens.endorphin.org/lo-tracker
12. http://blog.clemens.endorphin.org/2008/12/luks-on-disk-format-revision-111.html
13. http://blog.clemens.endorphin.org/2008/11/xmonad-gridselect.html
14. http://blog.clemens.endorphin.org/2008/11/workaround-for-bittorrent-traffic.html
15. http://blog.clemens.endorphin.org/2008/09/i-love-lolcat-meme.html
16. http://blog.clemens.endorphin.org/2008/09/counter-steganography-research.html
17. http://clemens.endorphin.org/cryptography
18. http://www.siswg.org/
19. http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
20. http://www.freesoft.org/CIE/Topics/143.htm
21. http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
22. http://www.tcs.hut.fi/~mjos/doc/wisa2004.pdf
23. http://eprint.iacr.org/2003/147/
24. http://grouper.ieee.org/groups/1619/email/pdf00011.pdf
25. http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/544
26. http://eprint.iacr.org/2003/148/
27. http://grouper.ieee.org/groups/1619/email/msg00160.html
28. http://www.oswd.org/user/profile/id/3013
29. http://www.linuxart.com/
30. http://nanoblogger.sourceforge.net/
Reference in New Issue View Git Blame Copy Permalink