I have written about the security implications of using sleep with encrypted drives in the past and have offered both short term and longer term solutions that would allow users to use sleep under some conditions and not risk (too much) a data breach. Today I am writing to offer another, common sense, alternative: Just don’t use sleep because you don’t really need it.
Before I get to the alternative first let me recap the security problem. Sleep (S3) is a low power mode where memory is kept active but the screen; drive and other hardware are powered off to save battery life. When the user hits the power button the machine jumps back to life very quickly because everything is already in memory. In the case of software Full Drive Encryption (FDE) this includes the DEK (Data Encryption Key) or with Self-Encrypting Drives (SED) the credential required to unlock the drive. Keeping such security sensitive variables in memory when the computer is not in the possession of the user is risky. If the user were to leave at the end of the day to go home with their laptop in sleep mode it could be lost or stolen in a vulnerable state.
If software encryption was employed the attacker could employ a cold boot attack, cooled RAM attack or a DMA port to get access to the memory to extract the DEK. More importantly, memory attacks are not the only possible attacks. Once booted into Windows and the drive is “unlocked”, full drive encryption is no longer providing any cryptographic protection, which is orders of magnitude stronger than the “programmed” security an OS can provide. If you let your computer boot automatically up to the OS prompt you are putting all your faith in OS security and that of the machine hardware. You have to trust that even though the DEK is sitting in plain text in memory and the data is all readable that the OS login screen is going to keep attackers out and that OS is not going to let data leak out of the device via LAN, WAN or other ports or connections. Or, as Wikipedia states there is “the possibility that one of the millions of lines of OS code can compromise the privacy of personal or company data”.
If a self-encrypting drive (SED) is used then the problem with sleep is even worse. This post, “4 SED Attacks and How to Mitigate Them” lists the attacks presented in a paper at Black Hat 2015, “Bypassing Self Encrypting Drives (SED) in Enterprise Environments”. Some of the attacks are easier than others but the easiest is the “Hot Plug Attack” which requires that the computer be configured to automatically resume (unlock) from Sleep. With the “Hot Plug Attack” they install a SATA data and power extension cable while the machine is in Sleep mode. When the computer resumes from sleep the drive is automatically unlocked but the cable supplies power from another source and allows the drive to be connected as a second drive (already unlocked) to the attacker’s computer. Once connected the attacker has access to all the data.
As you can see sleep mode has some serious security issues with both software encryption and hardware encryption. The common sense alternative to sleep is hibernate (s4). Hibernate is a mode where the contents of the memory are written to the drive before all power to the computer is removed and the contents of memory fades away. With software FDE or SEDs the hibernation file is encrypted and with PBA (Pre-boot Authentication) enabled hibernation is a secure state.
What makes hibernate a feasible alternative to sleep? – Windows 10 and Solid State Drives. Windows 10 resume from hibernate is about 20% faster than Windows 7. That helps a bit but SSDs, which are really fast and becoming much more prevalent, make a really big difference.
I use hibernate on my laptop because sleep is too risky for me but for the sake of the blog I did some comparisons between sleep and hibernate on my work machine (Windows 10, 8 GB, i5 laptop, Opal-SED-SATA-SSD).
First I configured SecureDoc to support sleep and loaded up my applications into memory (~4.4 GB memory in use). Then I power cycled my laptop and measured the time from power on until I was back at my desk top. Resume from sleep took 11 seconds including the ~ 5 seconds it took me to enter my Windows password.
Second I hibernated which invokes pre-boot authentication on power up. I used the same password at pre-boot with password sync and single sign-on into Windows. Then I power cycled my laptop and measured the time from power on until I was back at my desk top. Resume from hibernate took 46 seconds including the time it took me to enter my pre-boot/Windows password.
Therefore resume from hibernation took only 35 seconds more than resume from sleep. In my view that few extra seconds is well worth the wait given the compliance and security risks posed by using the insecure sleep option.
