On Tue, Jan 15, 2008 at 11:17:41PM +0100, Uwe Menges wrote: > On Monday 14 January 2008 14:26:48 Arno Wagner wrote: > >However serving, e.g., websites from > >an encrypted disk is a very bad idea in the first place. If you > >do such a thing, there could be a side channel. > > Could you elaborate that? I don't see why disk encryption could be a > "very bad idea" for a web server. It could very well guard against > recovery of eg. replaced RAID1 disks data, or data disclosure from > stolen server. Even if someone mounts a side channel attack on your > key, it's still more complicated to get your data than without any > encryption. Ok, true. It is a very bad idea, if you are paranoid. Sorry. In practice it can still be a reasonable precaution and against a lot of attackers, it will be entirely adequate. You disk replacement example is a good one. The first thing is that if your webserver can be compromised, then an attacker gets control of a pice of software that has access to your encrypted data. As to the key-leakage, this works as follows: The encrytion engine delays some operations. It can change the delay every second, say second 1 1ms delay, second 2 0ms delay, second 3 1ms delay, .... Thereby it would have signalled 101... to the outside. Typically you can distinguish requests served from disk and from cache, since the second ones are slower. And then you can use signal processing techniques to find the delays in the requests served from disk. Of coruse you would add more here, a repeating signal, maybe encryption of the signal itself (not the plain key), error correction coding, some special modulation, that is less obvious and the like. Far smaller time delays can also be enough. This just serves to illustrate the idea. This type of attack requires high effort. The problem with hardware is that it can be done as a system break, i.e. you break it once (design and put in the backdoor) and then all instances have the problem. With software this is far harder. First, it has to survive the compilation. Then, people may find it relatively easily. This is not somethign you can add as a single line of code. Then, you may have to get code into the Linux kernel (for example), which has high visibility and a high risk of getting caught. Then there are differences between CPUs. Such an attck can still work on software, but doing it in hardware is far, far easier. Arno -- Arno Wagner, Dipl. Inform., CISSP --- CSG, ETH Zurich, arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier --------------------------------------------------------------------- dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
