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?

  • 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 Commented May 27, 2017 at 11:33
  • 2
    This already exists with Apple's FileVault 2 (to a degree at least): security.stackexchange.com/a/34597/64411
    – imas145
    Commented May 27, 2017 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
    Commented May 27, 2017 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. Commented May 28, 2017 at 7: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
    Commented Jun 24, 2018 at 2:14

5 Answers 5


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.

  • 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
    Commented May 26, 2017 at 16:52
  • 1
    @wizzwizz4 Tricky :-) Right. I updated the post. Thanks.
    – peterh
    Commented May 26, 2017 at 16:57
  • And then this minimal input is the key to the key, and it has to be stored somewhere. Commented May 27, 2017 at 4:21
  • @Mindwin it looks like you are answering to a deleted comment.
    – guntbert
    Commented May 27, 2017 at 11:25
  • @wizzwizz4 the key can be retrieved using same boot-up authentication, like TPM or BitLocker password Commented May 27, 2017 at 11:32

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.

  • 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? Commented May 26, 2017 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.
    Commented May 26, 2017 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. Commented May 26, 2017 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
    Commented May 26, 2017 at 22:52

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.


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.

  • 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
    Commented May 26, 2017 at 16:05
  • Very interesting about DDR4. Do you have a source confirming this? Commented May 26, 2017 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: web.eecs.umich.edu/~taustin/papers/HPCA17-coldboot.pdf
    – Fis
    Commented May 26, 2017 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." Commented May 26, 2017 at 19:36
  • I am pretty sure it will be at least very very hard :)
    – Fis
    Commented May 26, 2017 at 20:30

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

You must log in to answer this question.

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