Re: the cold-boot attack

[email protected] wrote:
> Hello everyone!
>
> 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.
> 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?
>
> Best regards,
> Peter
>   
While I do not know all details of current processors, cache is 
primarily supposed to be a working copy of the DRAM. Since the cache is 
there for performance reasons, is is possible to mark that something is 
going to be in cache, but not to mark that it not is going to be in DRAM 
as far as I know, but I may be wrong on this.

If it is possible (for some processors) to mark that some memory to stay 
in cache only, that should be done at OS level, preferable in the 
virtual memory subsystem, and then make it possible to mark segments of 
memory as locked. It is not something that cryptographic systems like 
loop-AES should do on their own, other than to provide patches to the
virtual subsystem maintainers to add this feature. This problem affects 
all cryptosystems running on Linux, both in kernel and user space, so it 
should be solved in an as general manner as possible.

The only processor I know  can make sure that something is not found in 
DRAM is the Cell BE processor. This does not have cache for it's SPE 
cores but local memory that must be manually managed, thus nothing will 
be copied automagically to DRAM like normal cache does.

Keys always has to stay in memory somehow, since we want to encrypt and 
decrypt stuff  continously when using our computers. It is of cause 
possible to mask keys and use other security by obscurity tricks, but 
they are basicly just that. If there is no way to prevent the key from 
staying in DRAM as opposed to SRAM/cache, then there is in theory always 
possible to find the keys. This is the same problems as faced by DRM 
makers. You can obfuscate but not hide the key completely. In Linux you 
cannot even get the false security it gives to keep the implementation 
secret.

So, does any people know about the gory details of caching on different 
processors?

-Gisle

-
Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/