48

For laptops with full disk encryption or home folder encryption, one of the risks if it is stolen while in sleep mode is that the encryption key is stored in memory and can be read if an attacker knows how. To me, it seems that, in theory, operating systems should be able to have a "secure sleep" option where the key is erased from memory prior to sleep mode, and on resume, the user must provide a password to unlock the encryption key, as through a cold boot. All processes except the lock screen would be prevented from continuing until the encryption key is restored to memory.

I realize that this would mean that the computer cannot do any scheduled tasks in sleep mode, but most users probably wouldn't care about that. And maybe drivers or other obstacles would prevent this from being realistic.

Are there any reasons why a "secure sleep" option cannot be easily implemented?

Peter Rankin
  • 591
  • 4
  • 6
  • I personally find it puzzling why Microsoft doesn't advertise this feature on the Windows family, because (as pointed out by answers) even a rookie kernel programmer may easily clear the key from RAM one istruction before telling the CPU to go sleep – usr-local-ΕΨΗΕΛΩΝ May 27 '17 at 11:33
  • 2
    This already exists with Apple's FileVault 2 (to a degree at least): https://security.stackexchange.com/a/34597/64411 – imas145 May 27 '17 at 14:36
  • As long as the computer is locked when resuming, what does it matter if the key is in ram? The attacker can't unlock the computer, then gain root access to get the key. – psusi May 27 '17 at 22:38
  • 4
    You don't need to login to read the contents of memory. DMA is possible through various interfaces like PCIe, Firewire and ExpressCard. – Dylan Knoll May 28 '17 at 07:46
  • @DylanKnoll Modern Windows-based operating systems will block DMA from those interfaces when the system is locked or a user is not actively logged in. – forest Jun 24 '18 at 02:14
  • Windows 10 and (I assume) Server 2016 do. Prior versions are vulnerable. Windows 7 and 8.1 are still supported and widely deployed. – Dylan Knoll Jun 24 '18 at 06:04

5 Answers5

37

Yes. It could be easily achievable, although it would require kernel support do this properly.

In the suspend-to-RAM case, the key should be deleted from the RAM, and in the suspend-to-disk case, from the RAM and also from the disk (or it can be stored encrypted on the disk).

A minimal input should be also provided to get the key/reauthentication credentials in the early boot/wakeup stage.

I don't see any technical obstacles; the probable reason that it wasn't developed until now was the lack of interest. Scenarios where direct RAM access of a working laptop is a real security risk are very rare.

Peter Mortensen
  • 877
  • 5
  • 10
peterh
  • 2,938
  • 6
  • 25
  • 31
  • 8
    I don't think that it's necessary to delete the key from the disk as the memory dump will be encrypted on the disk, therefore the key will be required to get the key. – wizzwizz4 May 26 '17 at 16:52
  • 1
    @wizzwizz4 Tricky :-) Right. I updated the post. Thanks. – peterh May 26 '17 at 16:57
  • And then this minimal input is the key to the key, and it has to be stored somewhere. – Mindwin May 27 '17 at 04:21
  • @Mindwin it looks like you are answering to a deleted comment. – guntbert May 27 '17 at 11:25
  • @wizzwizz4 the key can be retrieved using same boot-up authentication, like TPM or BitLocker password – usr-local-ΕΨΗΕΛΩΝ May 27 '17 at 11:32
  • @usr-local-ΕΨΗΕΛΩΝ The key would be required to get the copy of the key stored in the memory dump of memory containing the key on the key-encrypted hard disk. – wizzwizz4 May 27 '17 at 13:17
  • You said yourself in the very first comment, the key is encrypted along with the memory dump. So the kernel must only make sure that the physical RAM contains no trace of the plaintext key, which can be recovered when back to life using the same boot-up authentication, e.g. verifying hardware and asking the TPM – usr-local-ΕΨΗΕΛΩΝ May 27 '17 at 13:19
  • I believe Linux can do this if you use dm-crypt on your hibernate volume. – chrylis -cautiouslyoptimistic- May 28 '17 at 16:56
  • @chrylis You have to inject the key into the system on the wakeup sequence, as far I know, there is no in-kernel support for that. If you do this from userspace, then you can't wake up any more. – peterh May 28 '17 at 19:01
  • @chrylis On Linux, it may work by getting the credentials in the early boot scripts, and then restart the kernel with the kexec mechanism, providing them the credentials. This would make possible only a suspend-to-disk restart, but it would work. It wouldn't be a very big patch into the initramfs of any Linux distribution. – peterh May 28 '17 at 23:24
  • @peterh Perhaps what I saw was a hack using Grub to prompt for the passphrase? – chrylis -cautiouslyoptimistic- May 29 '17 at 01:52
  • @chrylis As far I know, the wakeup process kills everything in the running kernel. How do you save the key without kernel support? Btw, how can you even start the lvm (or any dm-crypt) volumes? – peterh May 29 '17 at 02:08
  • @peterh https://wiki.archlinux.org/index.php/GRUB#Boot_partition – chrylis -cautiouslyoptimistic- May 29 '17 at 02:25
  • @chrylis It is for booting the system from a crypto device, and not for waking it up from it. – peterh May 29 '17 at 02:26
  • As far as I am aware, the hibernate-restore sequence is essentially the same as the boot sequence, just taking an early exit from the usual flow. This setup pulls the FDE entry point up into Grub, so that the kernel has access to crypto keys on bootstrap. I've never used it myself, but I was mentioning it as a possible setup I've seen. – chrylis -cautiouslyoptimistic- May 29 '17 at 02:28
  • @chrylis As far I know, this "early exit" happens before the user space had been started. And the LVM init can happen only from user space. What is "FDE"? – peterh May 29 '17 at 02:31
18

This would be a case for choosing Hibernate options over sleep. Sleep needs to keep the memory active, which allows for a quick boot; in sleep mode, the machine isn't completely off.

In hibernate the memory is written out to disk to allow the computer to have its power removed. This, in turn, removes the encryption key as well. This is why, in hibernate, you must enter the boot decryption key.

If security is more important than speed of 'booting' with sleep, go with hibernate.

One of the risks if it is stolen while in sleep mode is that the encryption key is stored in memory and can be read if an attacker knows how.

It's more likely that the attacker wouldn't bother recovering the encryption key. They would attempt to get OS level access at this point if they were attempting to steal your data.

ISMSDEV
  • 3,272
  • 12
  • 22
  • 4
    If the OS cleared the encryption key before sleeping, even OS-level access wouldn't help an attacker, since the OS itself doesn't know the encryption key without the password on a cold boot, correct? – Peter Rankin May 26 '17 at 14:17
  • 1
    Yes correct, but in sleep the key isn't cleared as you state. The attacker in this example I meant would attempt to login to windows to get to your data, why bother with the encryption key at this stage? It's already decrypted. On the otherhand if the OS cleared the key on sleep it would be without the encryption key and cannot do much. Things may still be unencrypted in main memory, which isn't ideal when the laptop is left. The OS would also not be able to read/write anything at all to the disk. – ISMSDEV May 26 '17 at 14:24
  • 3
    @ISMSDEV The question asked whether it's possible, not whether it is currently done, and deleting the key from memory certainly is possible. – Reinstate Monica May 26 '17 at 18:53
  • 1
    @Solomonoff'sSecret: The quoted portion of the question is talking about how things currently are. The question says that the attacker can currently read the encryption key if (s)he knows how; ISMSDEV is just saying that a more realistic attack is to use the OS normally, rather than doing anything fancy to extract the contents of RAM. (That's a side-note, of course. I don't think it's an essential part of this answer.) – ruakh May 26 '17 at 22:52
6

Secure sensitive data (like texts of the E-mails viewed) can be anywhere in RAM, it is not enough just to preserve some encryption key (if already to go into this direction).

Having encrypted RAM may be possible but would require developments in hardware layer. RAM is random access, any cell must be possible to read at any time. This limits the choice of ciphers. But it may be possible to use a very large key that is encrypted during the sleep with the cipher of your choice.

h22
  • 901
  • 6
  • 10
3

It depends how the enc/dec key is obtained. For example, if the key is stored on TPM and the NVRAM read is locked once the key is unsealed and read by OS there is no option how to read it again until next reboot. I would say sleep mode can't be considered as hard or soft reboot in this case.

Another encryption software can use the user password to open the enc/dec key store stored on the disk and obtain the enc/dec key from it so in such case it would not be a problem.

Fis
  • 1,200
  • 7
  • 10
  • 1
    By the way, theese days with DDR3 it is really hard to obtain the key from the memory. There were some studies on the internet about cooling memory modules down and read them in another PC but with no success. We also tested this with no success. and with DDR4 its completely impossible. – Fis May 26 '17 at 16:05
  • Very interesting about DDR4. Do you have a source confirming this? – I say Reinstate Monica May 26 '17 at 16:48
  • 3
    I amnot sure if it is still the same doc I have read in past but try this one, looks good: https://web.eecs.umich.edu/~taustin/papers/HPCA17-coldboot.pdf – Fis May 26 '17 at 16:55
  • Well according to the paper - "...DDR4 scramblers still do not provide sufficient protection against cold boot attacks. We detail a proof-of-concept attack that extracts memory resident AES keys, including disk encryption keys." – Byron Whitlock May 26 '17 at 19:36
  • I am pretty sure it will be at least very very hard :) – Fis May 26 '17 at 20:30
  • In the case of the key coming from a TPM, simply have the OS suspend IO and encrypt the key in memory before suspending. Then, on resume, before resuming IO, prompt for the password to unlock the key. – Perkins May 26 '17 at 22:23
  • :) Although it can sound interesting, you just moved the problem one step further. With what key you will encrypt the key in the memory? Probably withanother key stored in memory or hard coded to the software itself. – Fis May 27 '17 at 04:25
  • @fis It doesn't look terribly hard. The scrambler was designed with data integrity in mind, not security. The scambling is simple XOR. When you XOR a 0, you get the key. They just searched through memory to find what is likely scrambled 0s, and used that as the key. – Steve Sether May 30 '17 at 14:32
1

As @h22 points out, you would need to encrypt RAM on suspend. Actually it is either that or quitting any programs that may have sensitive information loaded in memory and clearing the freed memory and unmounting any file systems containing the sensitive information (and clear any caches that might be involved). Which kind of disrupts one's workflow and makes suspend to RAM a moot point at best (comfort-wise).

Thus if you want to be on the safe side, you should suspend to disk - the encryption in this case is a solved problem. An alternative is encrypting the ram on suspend and decrypting on resume - yet that would get you on the order of suspend to disk (time- and power-wise).

peterph
  • 368
  • 1
  • 7