Plans or suggested schemes to incorporate W7 Sleep? about sedutil HOT 16 CLOSED

tarruda, in response to your request...

Disclaimer. This works for me but it may not work for you. You should have a tested SEDUTIL rescue boot flash and know how to use it. Use this approach at your own risk, I can't help if it causes problems. And, this method is only for Windows.

Note that the scripts expose your password. Another reason you must be very careful if you use this approach.

You need a script to do the following commands before the system is suspended:
msed --disableLockingRange 0 \.\physicaldrive0
msed --setMBREnable off \.\physicaldrive0

Remember, this leaves the drive unprotected during sleep!

You need a second script to do the following commands after the system is resumed:
msed --setMBRDone on \.\physicaldrive0
msed --setMBREnable on \.\physicaldrive0
msed --enableLockingRange 0 \.\physicaldrive0

This will re-protect the drive so that it is secured when you power down.

YOU CAN AUTOMATE THIS PROCESS, but you WILL NOT be able to use the built-in Windows task scheduler to run these scripts. It doesn't run the scripts fast enough. If all the commands are not completed before sleep occurs, the drive will not be "ready" for a resume and you will need to use the SEDUTIL rescue disk to recover.

Instead of task scheduler, I use an open source program called PowerTriggers, where you can configure a "Suspend" task and a "Resume" task. I have each configured to run a command file which contains the first set of commands for suspend and a different command file with the second set of commands for resume. In PowerTriggers, configure them as "StartProcess" and "WaitForExit" (you'll see these choices).

This should get you started, but again, I recommend this only if you are absolutely determined to use SLEEP and understand all the risks. Most users will not be able to get themselves out of trouble they might encounter if they set this up wrong.

from sedutil.

Not to hijack the thread, but I too had asked this same question a short while ago and the answer was there was interest but no timetable for this.

It would really be handy. But I had another product (SecureDoc) which offered SED support and that too had problems with sleep (sleep was actually disabled when that product was installed). So, there may be some less-than-obvious technical obstacles to getting this working.

My alternative is simply to shut down, not hibernate. It only takes my machine 10-15 seconds to boot with the SSD. Shutting all apps down is a nuisance but this might offer greater security since the drive is locked after a power cycle.

I'm still interested in genuine sleep support, too, of course.

from sedutil.

Yes, sleep support is desirable, but hard. We would need to write a driver that intercepted the wake from sleep processing and unlocked the drives. If we don't store the passphrase (presumably in the TPM) then we need to have access to the UI BEFORE any disk access is required. Searching for documentation on doing this has been less than fruitful.

I guess the short answer is that yes we would like to do it but the research and planning are still in the very early stages.

from sedutil.

I'd love to see this working on linux too(ref: https://github.com/r0m30/msed/issues/38).

Yes, sleep support is desirable, but hard. We would need to write a driver that intercepted the wake from sleep processing and unlocked the drives. If we don't store the passphrase (presumably in the TPM) then we need to have access to the UI BEFORE any disk access is required. Searching for documentation on doing this has been less than fruitful.

@r0m30 Would it be reasonable for a first version of this feature to support only the simplest approach(which I assume is to store passphrase in the TPM and load automatically on wakeup)?

Another question: Since the laptop is only sleeping and the power is not actually interrupted, would it be possible to put the drive in some kind of "sleep mode" where it doesn't lock itself but also drains less power? If so, I imagine this approach would be simpler, not requiring any special actions during wakeup.

from sedutil.

The simplest solution is always a great design goal, but any automatic unlock implementation reduces the security provided by the SED.

The issue is still documentation, which type of driver and where to insert in the driver stack. Linux is a little simpler as you have the source and the ATA driver code is reasonably stable.

In sleep mode the "standard" behavior is to power off the drives so we would again need to insert ourselves in the system and override this behavior. This would undoubtedly reduce battery life and leave the drive unencrypted, I'm not sure that the "average" user would understand that they are giving up the security they expect for the convenience of not having to unlock the drive.

from sedutil.

In sleep mode the "standard" behavior is to power off the drives so we would again need to insert ourselves in the system and override this behavior

Do you know if changing this standard behavior is too difficult? What is the main obstacle to achieve this in linux?

This would undoubtedly reduce battery life and leave the drive unencrypted, I'm not sure that the "average" user would understand that they are giving up the security they expect for the convenience of not having to unlock the drive.

True, but as long as the passphrase is never stored in the main memory(the idea is to leave the drive unlocked by simply not turning it off), won't it still be protected against pure software attacks? AFAIK this is one of the selling points of SED vs plain software-based full disk encryption: You can't access the encryption key without physical access to the drive.

As for battery life, I've read that samsung evo 850(and possibly other drives) have idle power consumption of about 2mW(reference). Perhaps offering a "don't shut down ssd on sleep" option(not default) would be a reasonable way to add partial support for sleep without compromising security or battery life(at least for drives that support samsung evo sleep mode)

from sedutil.

I speculate that the vast majority of SEDUTIL users will not have a TPM, making that a poor choice as the sole option for caching any credentials. Conversely, corporate users with TPMs might opt for one of the commercial choices for SED management, since those products often integrate with AD or provide other group-level management which reduces the requirements for expertise on the part of end-users.

Expert end-users who don't mind having the drive unlocked while in sleep mode (though they should!) can support sleep by disabling locking before sleep and re-enabling it on resume. This requires configuring some SEDUTIL scripts and using a tool to trigger them at the right power transition event. It's not for the faint of heart but I do this & it works flawlessly for me.

Of course the right answer is SEDUTIL-integrated support for sleep; but in my mind, having to re-enter the pwd on resume will eliminate much of the appeal and there is the aforementioned security risk associated with any form of caching.

from sedutil.

This requires configuring some SEDUTIL scripts and using a tool to trigger them at the right power transition event. It's not for the faint of heart but I do this & it works flawlessly for me.

Could you point which scripts need to be edited and which edits must be applied to achieve this? It would be really helpful if you shared more details about this method.

from sedutil.

@lellis1936 thanks, I will give it a shot. Even though the drive remains unlocked while sleeping, it is still better than leaving it always unlocked(which is what I do ATM due to making heavy use of sleep)

@r0m30 I found a paper with ideas for possible attacks on SEDs. A one of the attacks take advantage of the fact that ATA passwords are stored in order to automatically wakeup from S3. Here's the relevant section:

So the question we were faced with was: How can we
deploy hot plug attacks against laptops that are suspended
to RAM? Rather surprisingly, this is often possible although
the disk is locked. Here we profit from another implementation
flaw available on virtually all laptops today. Laptops
require an ATA password on boot, but they unlock the disk
automatically on wakeup from S3

If this is true, then is the ATA password is automatically stored in memory by the operating system?

from sedutil.

ATA password has nothing to do with Opal. 

from sedutil.

Anyone who is considering using the scripts above across sleep events should make sure they are using at least PBA version 1.10. This prevents boot problems if the following sequence:

msed --disableLockingRange 0 \.\physicaldrive0
msed --setMBREnable off \.\physicaldrive0

...does not complete before transitioning to sleep. For example, if only the first command executes, you will have trouble booting Windows from PBA unless you are running a recent PBA version (1.10).

Should such problems occur and you are using an old PBA, you will need to use a SEDUTIL rescue disk to run the 2nd command (note: the syntax for the drive is different when using rescue disk). This will make Windows bootable again. See my comments in this posting for more information:

https://github.com/r0m30/msed/issues/9#

from sedutil.

@lellis1936 What happens if you put your computer to sleep and then physically disconnect the power?

from sedutil.

The disk would still be unlocked, so there would be no prompt for an OPAL password on reboot. The method I talked about relies on a power-resume event trigger to re-lock the drive. It's the risk you take to do things this way, since there is no real sleep support in MSED/SEDUTIL. I try to do a normal shutdown if I'm leaving the house or won't be using the computer for a while.

from sedutil.

I'm using sedutil and I think is a good option to other proprietary solutions but suspend is a problem. I think that for security reason it's not good to store passwords when suspending but would be useful that sedutil ask for a password on resume.

from sedutil.

Due to various issues encountered, I no longer recommend the technique I described earlier in this thread as a workaround for lack of sleep support in sedutil.

However, sedutil does support hibernate, I am using it, and it works well. A fair bit of data does get written to your disk at hibernate (depending on memory size), and you are prompted for the sedutil password when resuming. But it's secure, reliable, and is the method recommended by the sedutil author; so that's the price you pay if you want a robust "standby" method with the current sedutil version.

from sedutil.

Using the lellis1936's idea, why not adding a line to create a new password before the system is suspended and use it in the boot command ? I don't know if we can run a script stored in ram without a disk IO for S3 sleep. If so, it should be better than storing the real password and letting the disk without encryption.

If the system has been shut down, we still can use our own password and we have a more secured system. (The disk won't stay without encryption and the attacker needs to know the password)

It's not a perfect solution but depending on your need, can be a better one.

from sedutil.