1

I wonder if my setup can be risky. To give a good starting point for answers I would briefly sketch the situation

setup:

  • 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)

situation:

  • 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 /tmp)
  • 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][1])?

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.

Improve this question

2 Answers 2

Reset to default
2

There is a Linux version of Skype however, I wouldn't recommend running it on bare metal. Have you considered running a virtual machine on your main Linux system (either Windows or Linux) and running Skype inside that? This way the software inside the virtual machine cannot access the ram of the host.

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?

This is a possibility. You may be interested in tresor which stores the encryption key inside a CPU register instead of in RAM. http://linuxaria.com/howto/protect-linux-from-cold-boot-attacks-with-tresor?lang=en

Improve this answer
5
  • I think the tresor patch really to be interessting, even more for cases where to expect a very sudden attack (i.e. no time for RAM wiping/sanitizing). Yet in my case I guess I would not want to go away from using LUKS containers, and hope there is a way to make certain to kill essential parts of the RAM? I think I will go for a "livecd-discard at shutdown" GNU/Linux and run Skype insight. Keeping Windows for Skype is stupid anyway. Thanks for the input.
    – humanityANDpeace
    Commented Apr 1, 2014 at 10:32
  • I have considered virutalization. Not wanting to open a new question I feared: (a) guest-system-escapes, (b) enabling hardware support as needed for acceptable vt performance would allow a bluepill attack!
    – humanityANDpeace
    Commented Apr 1, 2014 at 10:36
  • Won't the OS write registers to RAM on context switch?
    – kutschkem
    Commented Apr 1, 2014 at 11:43
  • 1
    @kutschkem Tresor uses debug registers that are not part of regular context switches. I suggest you read the documentation if you'd like to learn more about how it works.
    – user2675345
    Commented Apr 1, 2014 at 12:12
  • As @user2675345 says, the x86 debug registers are not saved on context switch. During the actual encryption, preemption and interrupts are disabled, which prevents general purpose registers containing key material from being spilled to memory. TRESOR refers to this as the atomic section. NMIs and SMIs however will still occur, but those are not nearly as common.
    – forest
    Commented Dec 1, 2017 at 10:34
0

Aside of Skype for linux you can also use a Pidgin plugin that connects to Skype network. This would eliminate need for Windows and be safer and more convenient overall.

Maybe there is no risk, because Linux does overwrite the RAM at shutdown to avoid a "cold boot attack" (as suggested in this question)?

I asked this question already. No, linux does not clear entire RAM on shutdown. It is likely that LUKS keys held in memory are erased on unmount before shutdown tho. So disk encryption keys specifically would not leak but other data would. This is also an argument for using only one system or using TRESOR or both.

Improve this answer
1
  • It does wipe the keys held in memory when a dm-crypt mapping is removed, if my own memory serves. It's part of the regular crypto API in the kernel.
    – forest
    Commented Mar 1, 2018 at 5:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .