Peter_22@xxxxxx 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/
