I wonder if my setup can be risky. To give a good starting point for answers I would briefly sketch the situation
- double boot system GNU/Linux and Microsoft Windows
- GNU/Linux is on 2 partitions which are both LUKS encrypted using AES cipher with a considered "safe" block-chaining mode and keylength
- Windows is not encrypted and distrusted anyway (I use it to run skype)
- Latop computer (Lenovo Thinkpad) with a battery (if that matters to RAM or not)
- The boot partition with GRUP and KERNEL is on a SD-Card not plugged while Windows runs. (Clearly it needs to be plaintext)
- Generally work's done in Linux ( which can work with the encrypted partitions because I supply the key during the boot; no swap partition; yet an tmpfs for
- When I want to Skype I reboot the computer (having ejected the SD with the bootloader and kernel) and start Windows
I assume that in such a case the RAM is still absolutely readable and hence the key for decrypting and accessing the encrypted linux is still somewhere in the RAM? Additionally all the data of
/tmp/ is initially still there?
An answer would confirm if this is reasonable to assume!
An even better answer would include (assuming the risk exists) ideas how to remedy this (at present I shutdown and take out the battery for 2-20 secs).
Maybe there is no risk, because Linux does overwrite the RAM at shutdown to avoid a "cold boot attack" (as suggested in [this question])?
Also I thought I have additional risk as distrusted Mircosoft Software can help attackers to access my hardware and hence even without accessing directly my linux partition (by retrieval of the cipher-key via "cold boot attack") firmware can be changed to attack my system. I am not paranoid about that (though it might seem) and aware that firmware has always been a "risky business" I just think that having the double boot I invite a constant update of this risk, while GNU/Linux in theory would make an update of potential firmware spy mechanisms much harder.