markus reichelt, June 2004
v1.5.7, last modified: 2010-06-04, status: actively maintained
This text is intented for linux users who want to set up a secure and stable encrypted file system. A succinct overview about mainline cryptoloop is provided, as well as alleged advantages of its use, and proof is given why you should not use the built-in cryptoloop of modern vendor and kernel.org kernels, respectively, for file system de/encryption. Mainline cryptoloop is vulnerable to watermark attacks as well as optimized dictionary attacks, and therefore insecure. A possible solution is given by strongly advising the use of loop-AES in multi-key mode with encrypted swap. Up-to-date versions of dm-crypt (with LUKS) and truecrypt are also ok to use.
The issues of mainline cryptoloop have been known for years and yet they have not been addressed, so using mainline cryptoloop cannot be recommended.
As it seems this document is now linked in David Braun's Disk Encryption HOWTO at The Linux Documentation Project.
This document is located at http://mareichelt.de/pub/texts.cryptoloop.php
[top]
The kernel 2.6 series features built-in cryptography. It's called "Cryptographic API" in the kernel configuration menu and works out of the box with the loop-device (this combination is also known as "cryptoloop" or "mainline cryptoloop"). That's convenient, because some organizations only allow vendor or kernel.org kernels. Thus it's widely considered an advantage - it's not necessary anymore to patch the kernel to be able to use cryptoloop.
For kernel versions prior to 2.6, cryptoloop was available as a patch you needed to apply to your kernel. That was a hassle and additionally, it was not always possible (i.e. allowed) to patch the kernel in certain environments. When I was originally writing this text, kernel 2.6.7 was about to be being released soon. Since the built-in cryptoloop implementation is relatively easy to set up and use and more and more people will update to the new 2.6 kernel branch (as up to date major linux distributions are using it), it can surely be assumed that also more and more people will start using the built-in cryptography to protect their data.
So, let's summarize. Apart from the disability to change the password easily (yeah, that's a nasty one), the mainline kernel cryptoloop is
Seemingly plenty of advantages mainline cryptoloop provides. So why exactly should it not be used?
[top]
Markku-Juhani O. Saarinen, a researcher in cryptography, has discovered a watermark attack against cryptoloop, and his findings apply to all ciphers available in the Cryptographic API. Not because the ciphers themselves are flawed but because of how cryptoloop works. Read about it in his paper "Linux for the Information Smuggler" available [here], or [here] in case his site is inaccessible.
In 2004 he published "Encrypted Watermarks and Linux Laptop Security" in the proceedings of The 5th International Workshop on Information Security Applications (WISA2004), Jeju Island, Republic of Korea, August 23-25, 2004. The scientific paper is available [here], or [here] in case his site is inaccessible.
You might be surprised about this severe security vulnerability of mainline linux kernels, but it is true. Jari Ruusu, author of loop-AES, wrote about it on the linux kernel mailing list, attaching to his message the source code of two programmes adequate for a proof of concept. An excerpt of his message follows in the next subchapter, the source code of the programmes is available [here].
Additionally, both kerneli.org and mainline crypto implementations are vulnerable to optimized dictionary attacks, according to Jari Ruusu (emphasis added):
Kerneli.org loop crypto implementation (and derived versions such as Debian, SuSE and others) are vulnerable to optimized dictionary attacks because they use unseeded (unsalted) and uniterated key setup. Mainline linux implementation is equally vulnerable. Most, if not all, file systems have known plaintext. On popular file systems such as ext2, ext3, reiserfs and not so popular minix, first 16 bytes of fourth 512 byte sector is such good known plaintext.[...] When encryption key setup does not include seed, there will be direct connection from password to ciphertext. The problem is that these ciphertexts can be precomputed in advance, and if the database is kept sorted by ciphertext value, optimized attack is reduced to doing binary search of precomputed ciphertext values.
In other words, and to simplify things a little bit let's choose a figurative real life example: Let's say you plan to go on holiday. By plane, but you keep the method of travelling secret, as well as your destination. The duration of your stay doesn't matter. Since you are a celebrity, you appreciate your privacy of course, so let's assume you get on the flight unrecognized and nobody recognized you at the airport either (sorry, no whistle-blower :-). The trip takes several hours which you spend as you wish.
But when you arrive at the airport, you are surprised that the local yellow press is already waiting for you at the gate. How could this have happened? Well, the yellow press is very curious and definitely knows where to look. So you have to pay attention as to what kind of information you reveal, especially unwillingly. So let's replay this story:
When they learned that you would be going on holiday they first checked their sources if they could possibly learn the method of travelling you had chosen. Second, they started a search for a person exactly matching your description (on a specific route, at a specific place, ...on a flight list). In the end, it was no wonder they found out about your plans.
The resemblances should be clear... The direct connection from password to ciphertext is represented by you having chosen to travel by plane, which you thought secret. The exploited watermark left behind by exactly you is represented by the flight list.
I know, it's a far-fetched and limpering analogy - but analogies always limper to some extend. Fact is, there are the ones who want to keep their privacy and the curious ones who know where to look first. Do not take for granted what you do not expect. More to the point, do not expect crypto implementations to be safe just because they are included in official kernels. Obviously, the reasons to keep weak crypto implementations in the kernel have nothing to do at all with security considerations, they are dominated by design and maintenance issues.
After all, chosen plaintext attacks helped decipher Enigma messages during WW2.
[top]
To make a long story short, I quote Jari Ruusu summarizing the issue on the linux kernel
mailing list (typos corrected, status quo incorporated):
- cryptoloop and dm-crypt on-disk formats are FUBAR. cryptoloop and dm-crypto developers and users don't have any choice here. They have to start using stronger crypto. - Used cipher or key length or password does not matter. - loop-AES single-key mode on-disk format is equally FUBAR. - loop-AES multi-key mode is not vulnerable. - Anyone still setting up new encrypted file systems using cryptoloop orcurrentdm-crypt [prior to 2.6.10] or single-key loop-AES, is committing security malpractice.
Bestcrypt and truecrypt (versions prior to 4.1) are bad as well, see Jari's message about this posted on linux-crypto (text between [ ] added).
Unfortunately truecrypt [versions prior to 4.1] is just another broken device crypto implementation that uses good ciphers in insecure way. Specially crafted static bit patterns are easily detectable through that kind of bad crypto. Requirements: (1) used ciphers must have 128-bit block size and (2) file system where bit patterns are stored must have 2K or larger soft block size. Many popular linux file systems meet those requirements.
Proof-of-concept code for watermark attacks on cryptoloop, bestcrypt and truecrypt versions prior to 4.1 is available as attachement of the aforementioned message or here.
So we learn that older versions of dm-crypt (device mapper crypto target) and loop-AES in single-key mode are also affected. Although kernel 2.6.10 includes a patch that adds a new IV mode "encrypted sector|salt IV" that improves the security of dm-crypt (according to the author of the patch), loop-AES's crypto implementation is still stronger than recent dm-crypt:
Jim MacBaine wrote: > Since then, dm-crypt has obviously caught up. No it has not. Loop-AES still has stronger and better IV computation, and multi-key mode that reduces amount of data encrypted with one encryption key. Try modifying last byte of 512 byte sector, and observe how many 128 bit ciphertext blocks change; loop-AES: 32, dm-crypt: 1
This means that loop-AES hides the position of changed ciphertext better than dm-crypt. Although this is relevant only in uncommon scenarios, an adversary is able to abuse this given that he is able to obtain snapshots of ciphertext or even monitor read/write traffic (in which case the system is compromised already by some kind of rootkit).
It's considered A Very Bad Idea to use insecure means to protect your data.
To emphasize the point, have a look at the following images taken from slides of a talk Markku-Juhani O. Saarinen gave at the Finnish National Defence Academy late in 2003. On the left you see the original image, on the right is the result of a statistical analysis of a system using ECB-mode, like F-Secure's FileCrypto does (and older cryptoloop versions did as well).
|
|
A merged version of both images is linked here.
Although this does not visualize an attack on the Cryptographic API, it's pretty self-explanatory, in my opinion. Cryptograhic API is almost as bad as systems using ECB-mode, just look at the slides mentioned above, available [here], or [here] in case the site is inaccessible.
In case you want to know more about ECB and CBC, check wikipedia's entry on block cipher modes of operation.
[top]
First of all, because too many people confuse the terms "cryptoloop/Cryptographic API/dm-crypt/loop-AES", let me point out that cryptoloop, dm-crypt, and loop-AES are three different crypto implementations on linux systems:
Both cryptoloop and dm-crypt in kernels prior to 2.6.10 are vulnerable, and even recent dm-crypt still suffers from a weak crypto implementation.
Provided that loop-AES is set up in v3-multi-key mode (with encrypted swap, in case you use swap), it's safe to use. Its README is a step-by-step guide for multiple setups, covering 99% of its applications. Even commercial webhosters offer packages prepared with loop-AES, and with good reason!
My recommendation is plain and simple: Do not use cryptoloop, dm-crypt in kernels prior to 2.6.10, bestcrypt (all versions), truecrypt versions prior to 4.1, or loop-AES in single-key mode. It would be security malpractice to do so.
Get it done right and use loop-AES in v3-multi-key mode (and encrypted swap, if you use swap). Available ciphers are AES (aka Rijndael), Blowfish, Twofish, and Serpent.
[top]
In October 2006 there was an article published in the German "Linux Magazin" by Gutmann/Ney about crypted filesystems under linux, by now freely available here. Concerning loop-AES the authors solely dealt with loop-AES' compatibility mode (single-key mode!). The latest v3-multikey mode was not addressed at all, despite of its recommendation in loop-AES' readme for quite some time. Jari Ruusu's reply to the article can be found here, and is quoted in full length because of its importance (we all know how tricky mailinglist archives can be):
Jari Ruusu wrote: > Jens Lechtenboerger wrote: > > 3. The German Linux-Magazin 10/06 (http://www.linux-magazin.de) > > features an article by Peter Gutmann and Christian Ney, where > > they analyze different types of crypto filesystems. They > > recommend Truecrypt, dm-crypt is second, and they essentially > > warn against loop-aes: > > I tried to look for that Linux-Magazin article, but I didn't find it > on-line. Do you have a URL for it? Christian Ney was kind enough to send me english language draft of the article. It might not be exactly what was printed, but at least I have something to quote and respond to. Quote from the article: | Loop AES is available as a series of Linux kernel patches One patch for 2.6 kernels, one patch for 2.4 kernels, or alternatively, outside of kernel tree buildable kernel module that builds for all recent 2.6, 2.4, 2.2, and 2.0 kernels. Module version doesn't need any kernel patching. | the behaviour of the encryption can change radically depending on which | compile or runtime configuration options are chosen Compile time configuration options do not change on-disk format. Having optimized assembler implementations available for popular processors (x86 and amd64) and instruction set extensions (VIA padlock) are good things to have. Runtime configuration options are needed for compatibility with old on-disk formats. Killing compatibility with old on-disk formats is not responsible thing to do. | the code makes it quite difficult to pin down exactly what's going on, or | whether it's actually doing what it's supposed to be doing. The code is difficult to read, I agree. Short version of what it does, is here: http://mail.nl.linux.org/linux-crypto/2006-05/msg00049.html | LoopAES uses an unsalted hash of the password, applying a single iteration | of a hash function like SHA-256 or SHA-512 to obtain the disk key [snip] | makes it trivially vulnerable to a precomputed dictionary attack That obsolete code path is there for backward compatibility only. All examples in the README file and losetup man page use version 3 multi-key mode, and none of above applies to those examples. For many years, the recommended way has been to use gpg encrypted key files. gpg uses salted+iterated key setup, so precomputed dictionary attacks won't work. | Data is encrypted with AES in CBC mode kernel-2.6.15.diff, line 737, | with a confusing array of IV-processing options using either the raw | sector number or an MD5 hash as the IV. Raw sector number IV is there for backward compatibility only. | no function return codes are ever checked, so if anything goes wrong the | code continues with all-zero keys or unencrypted data. aes_set_key(), aes_encrypt(), and aes_decrypt() functions return void type. To check return value of void returning function would be a bug that compiler would refuse to compile. Those functions never return any error because they do not have any error situations that can make them return failed status. If above mentioned functions, or other kernel called driver hooks, are passed invalid pointers, then pointer dereferencing will cause kernel mode exception, and the process will cease executing with kernel "Oops", and the function never returns. As for RAM pre-allocations that are done at loop device set up time, all pointers are checked at least once at allocation time, but not thereafter. This claim of "continues with all-zero keys or unencrypted data" is completely bogus. My conclusion of this article's loop-AES section is that the technical review was done in hurry, and for some unknown reason seems to focus on bits that were obsoleted years ago. Maybe the reason of such mistake is because the source code does not have explicit comments about which sections of code are for handling obsolete compatibility bits.
"Beware of all experts. Experts are wrong as much as anybody else. Experts are just wrong with much greater authority." --Robert J. Hansen
[top]
The following files are available for download:
[top]
loop-AES related:
About linux crypto implementations:
Misc:
[top]
This text is basically a write-up of what I find on the net, read on mailinglists etc, spiced with personal experience. It was originally written as a very basic guideline for some friends. I keep it up to date because (they bugged me about it! and) I have a keen interest in using a solid crypto implementation myself. And if you go through the hassle of encrypting your system, you probably want the best you can get. So far, I rank loop-AES top, not only because of encryption-strength but also concerning stability. Commercial hosters offer it with good reason.
I know that most people go for the compromise between "solid" crypto and ease of use. I feel sympathetic to their cause, and thus add info about alternative crypto implementations, their pitfalls as I learn of them etc., so people can pick what they deem worthy.
Given the steadily increasing numbers of disk encryption howtos and similar texts, also consider the following quote:
Disk encryption is not a performance bottleneck nor does it significantly decrease the usability of the system. Therefore there are few excuses for not deploying it where ever possible. --Linux for the Information Smuggler, p8, Concluding Remarks
To be precise, it is possible that an attacker modifies contents of a device that has been set up via loop-AES in multi-key mode, and remains undetected. However, though preventing this is undoubtedly a goal to strive for, this is not what loop-AES tries to achieve - to safely and reliably de/encrypt one's data. If an attacker gains root access on a machine that uses loop-AES (or dm-crypt, cryptoloop, bestcrypt, truecrypt): it's game over right there. So even if your encrypted data falls into false hands (f.e. stolen laptop), it has to be utterly useless to the attacker. So far, loop-AES is the best way there is to achieve just this, and both dm-crypt, and truecrypt are not far behind.
Just for the record: None of the current implementations are immune to changed ciphertext attacks. Changed ciphertext attacks are more of a theoretical nature, but they work flawlessly on each crypto implementation mentioned on this page. This should give you a hint that it's all about your level of paranoia, and that the encryption algorithm itself is attacked always at last, so you won't get much more security by choosing serpent over AES, for example. A motivated attacker just takes the path of least resistance, and that's obviously the encryption key itself, and/or its passphrase, respectively.
Ditch passwords altogether, solely use passphrases.
Regarding the cold-boot attack, you really should consider means of denying direct physical access to your (running/hibernating) system, it's the only working strategy against it (because the attack exploits a design flaw). You can always try to slow down the attacker though.
Make it a habbit to check up crypto news. Crank up your level of paranoia. Periodically check mainstream blogs such as Schneier's, or read the Cryptology ePrint Archive, if you like.
Setting up loop-AES is not difficult, you don't have to patch the kernel (and never had to, actually). You can use it in combination with jounaling file systems, and there are lots of examples for different setups mentioned in the loop-AES.README. You even can encrypt an existing (cleartext) partition non-destructively using aespipe. Check if your distro supports loop-AES out of the box. Additionally there's the linux crypto mailing list for help, some howtos are linked. And there's a FAQ.
[top]
Copyright (c) 2004 - 2010 markus reichelt.
If you want to contact me, send an email in plain text only to the address listed below; encrypted email is preferred. Have a look at my GnuPG Key Signing Policy.
Encrypted and anonymous message box available at https://privacybox.de/mareichelt.msg, or as Tor Hidden Service in case you prefer such a method of contact. Be advised that the subject will not be encrypted, only the text message itself. Also, in case you want a reply, please provide secure means of contact.
[top]
[top]
[ return to publications page ]
| markus reichelt <markus.reichelt@gmx.net>Last modified: 2010-06-04 | angstklausel - site policy - imprint | - Gegen Stasi 2.0 | - FSFE | - valid html | - valid CSS | - any browser |
