MacOS – Does High Sierra erase FileVault key on hibernate

filevaulthigh sierramacosSecurity

Before today, with 10.12, and now (High Sierra 10.13), I had DestroyFVKeyOnStandby 1. With 10.12, I would open the lid to my laptop after it had been hibernating for a bit, hit the power button, and I would be prompted for 2 passwords (identical). I would enter the first password, a status bar would progress, and then I would be prompted for the second password.

With 10.13, everything is the same, but the first password prompt is missing. I always figured the status bar (in 10.12) meant it was decrypting the disk (or part of it). If that is the case, now it's decrypting before it even asks me for the one password to let me in. That is to say, there is the status bar, then the password prompt.

Any clarity on why this might be different and if there is anything we should know would be appreciated.

UPDATE
After toggling DestroyFVKeyOnStandby and restarting a few times (ultimately, I changed nothing), the situation is as follows:

After hibernating, I press power key, Apple logo appears, enter FileVault/Login PW, progress bar, finally desktop. This is the opposite of my previous situation [progress bar -> PW prompt]. Good, but still only one PW prompt. Why? My guess is the machine knows they are the same (set them at the same time)?

I can now recreate my previous situation by setting DestroyFVKeyOnStandby 0(it wasn't 0 before). This is what 0 should do.

Additionally if I set DestroyFVKeyOnStandby 1 and turn off sleep-screen-lock, I am still prompted for a PW. This leads me to believe my machine is asking for my FileVault PW, the intended outcome.

I guess my final advice would be to fiddle with your DestroyFVKeyOnStandby a bit and restart a few times. I know that's not very scientific, but it shouldn't hurt.

Best Answer

Apparently removing /Library/Preferences/com.apple.PowerManagement.plist, and then running an pmset -a DestroyFVKeyOnStandby 1 as Root has gotten things working reliably again.

I have no idea what is causing this file to take precedence over the com.apple.PowerManagement.<UUID>.plist file again on every update, but it is rather annoying to have to remember to remove the non-UUID config file every time.