There is a fundamental problem with your argumentation. Of course all this is possible by attacking the software as well. Maybe I was not clear, but I was talking about additional risks from using hardware, as anything else does not make sense. Arno On Mon, Jan 14, 2008 at 10:32:34PM +0100, oguh@xxxxxxx wrote: > > > This is pretty naive. Every modern hardware contains software stored > > > for example in EEPROMs or flash. If a malicious software is good > > > enough it can do a lot of possible things that needs not only > > > local attacks. > > > > I would consider these local attacks. You do not? > > No, it could be part of a site channel attack that works remote. > > > > > There are a lot of possible attacks for malicious implementations. > > > It can for example store the AES key in a flash memeory on the hardware > > > and reveal on special commands or it can be exploited by site channel > > > attacks. > > > > The flash again is a local attack. > > If you use the flash only to store a key you are right. > If you use the flash to buffer the key for a site channel attack > it is a remote attack. > > > As to side-channels, this is disk encryption. Sure, if in was > > something going over the network, leaking key material via timing > > information would be easy. 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. > > If you don't use network for your computer, nearly all attack vectors > go to local attacks. > > If you like to encrypt data from your server you have to do this. > You could also see your browser as service because it interprets > Javascript. > > I see no architectural problem on that. > Yes, there could always be a site channel. But its much better than > no encryption. Also you could use different keys for the disk space > used from the service and the other one. > > > > > The objections actually go one step further. After all > > the design documents would be doctored and, unlike software > > available as source code, hardware is not easily alanysed or > > checked to match its suppodes documantation. > > I also have this objections. Its not easy to verify correctness of software > and for hardware this is much harder. > > > greetings > > wof > -- > GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. > Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail > > --------------------------------------------------------------------- > 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 > -- 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
