Thursday, February 28, 2008

Buzz and reality about cold boot analysis of computer memory

I can hardly remember so widespread coverage of any computer security issue, that the recent analysis report has got. From the first glance the attack is very serious. But is it really that serious?

Bruce Schneier has published his review of the question with references to other discussions. This saves me a couple of keyboard clicks that I would have to do in order to explain the problem.

So ... if the bad guy has stolen your notebook, he can get access to the encryption key for whole-disk encryption software. No remedy so far. In fact, there's no remedy for the particular problem, where the parts of the problem are (a) physical access to the device and it's memory, (b) applications that store the keys in memory.

Neither of these parts are key parts. Physical access is not necessary, the rootkit will do the job perfectly. You have much bigger chance to catch a malware, than to be attacked by the thief hunting for your data. The best attack is the one that remains undiscovered by the legitimate user, and stealing the notebook is probably not the best way to hide the attack. And if the thief is that serious about physical actions, then thermorectal cryptoanalysis will work quite efficiently - with a bit of brute human force or other methods of conviction you will tell all the passwords the thief wants to know.

Applications that store the keys in memory are not a problem at all - just don't use them. It's not that hard to not keep the keys in memory unprotected. The vendors already announced that the keys are kept in memory which is not flushed to disk, but this is just a part of the solution. The application can easily use some encryption on the key and decrypt the key for the tiny period of time when this key is used. Decryption would be made to specially allocated memory, whose location is random and changing for each operation. The key for encryption can be derived from the data, specific to the process that does encryption. Such approach will make it much harder if not impossible for the attacker (both thief of the RAM and various malware) to get access to the key itself.

There's one more solution available, but it's too slow nowadays. The solution is to keep the session key in some hardware device, which doesn't give it away. I am talking about my favorite USB tokens and smartcards. The problem with this hardware is that one security operation can take a second or two, making it very slow for use with whole-disk encryption solutions. But I think one needs to try.

Our Solid File System product can be used to create secure virtual disk solutions. We are going to introduce key protection in one of the upcoming builds of SolFS (both Standard and Driver editions). And it is possible to plug the above mentioned harware protection of the key to Solid File System if needed. More detailed information about the above listed techniques can be obtained by contacting me privately.

No comments: