markus reichelt wrote: > * Peter_22@xxxxxx wrote: > >> So as a conclusion of the mentioned time-limited vulnerability >> should I remount the side wall of my computer case again? Maybe >> even replace the original crossheads with tri-wing screws? To put >> it in a nutshell, I fiercely doubt todays police forces are that >> talented, since they fail to simply boot up a computer. > > I still keep my case open. > > But the one strategy against the attack is denying physical access to > the machine. Sure. If you can do this. Good luck though. In my country, the police can get what's called a 'sneak and peak' warrant. So when you go shopping or leave your house, you're in trouble because they can enter to trojan your computer systems or to bug your house. I don't really understand how this kind of action can be legal but apparently the courts in my country don't agree. > Apart from that, I have to slightly adapt my loop-AES > scheme now, I'm not worried. How do you plan to adapt it? Modification of the key schedule? A panic function tied into some sort of sensor hardware? I think these may be important modifications and if they are actually workable, it should be shared. If they aren't workable, it would be terrible if it was found to be the case after a seizure or a theft. > > >> The described attack has nothing to do with breaking the encryption >> as such. Compared to this it would also be an option to point with >> a gun at your temple and simply ask for keys/passphrases. As a >> reaction to this "attack" I wonder if it might be possible to use >> level 2 cache of the processor to store keys in highly volatile >> memory space. 2 or more megabytes on the CPU die might be a last >> resort. As gpg prevents leaking keys from kernel ram to swap >> partitions, newer disk encryption might prevent keys to be stored >> in DRAM cells. Of course, elderly processors might not do this >> stunt due to lack of level 1/2/3 cache but newer architectures >> offer ever increasing megabytes. Is that a worthwhile option? > > Hm. I doubt CPU level 2 (or so) cache is directly accessible but is > used by the CPU itself. Maybe it would be possible by using adapted > microcode (on Intel chips). > Indeed. > Thinking along those lines ... cache of other components might be > worth looking into: graphics cards, hard disk drive cache... Anything where memory can be mapped, it may be possible to use for key storage. I would like to point out that these solutions are not really solving the problem, they just change the way someone will carry out an attack. Regards, Jacob Appelbaum - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
