[FDE] Q concerning hardware-based encryption/security

[Garrett M. Groff]

I have a concern about self-encrypting drives, specifically Seagate Momentus FDE. While the idea looks quite brilliant, my understanding is that the user is only prompted for credentials when booting from a cold machine (one that has been shut down completely). If that's correct, then that presents the following vector of attack:

 

Bad Guy catches machine in standby (or hibernate?) mode. Bad Guy wakes machine & then restarts it, booting to a USB stick (or CD) rather than the HDD. Since HDD is already authenticated, Bad Guy mounts file system & reads (or writes!) data directly off of HDD.

 

Can someone provide technical information that confirms or denies this potential attack vector? I'm specifically looking at Seagate's Momentus FDE drive w/ Wave's Embassy Suite, though other vendors would logically suffer the same vulnerability.

 

Thanks.

[Lark Allen]

Garrett,

 

The alternate boot threat you describe cannot be executed against the Seagate Momentus FDE drives.  Whenever power is removed from the drive, either at full system shutdown, or when the system goes into hibernation, the drive locks and all user data, including the hibernation file is encrypted and unavailable.  When the system is powered up the FDE drive is locked.  If an alternate system is booted, the drive will only appear to have a 128MB available, which is the protected read-only partition on the drive which stores the shadow master boot record which is used to provide the pre-boot authentication for unlocking the drive by an authorized user.  Once the drive is unlocked, then the normal boot process or return from hibernation will execute.  There is no possibility for alternate boot scenarios which will be able to find the drive in an unlocked state.   

 

The Wave Embassy software you mentioned for managing the setup and security settings for the Seagate FDE drive, forces Windows to use hibernate mode, even if standby mode is selected by the user.  In Dell systems, Seagate, Wave, and Dell worked together to create a solution for secure standby mode, so for Dell systems both hibernate and standby modes are supported with full security. 

 

Lark Allen

 

Wave Systems Corp.

[Garrett M. Groff]

Thanks for the info, Lark.

 

So the attack vector is reduced to:

1. the machine is on* (like if the user locks his screen & walks away for a moment), and then

2. someone steals the laptop (leaving it on), and then

3. restarts the machine using a boot disc or bootable USB stick.

 

Begging the question: Are there ways of mitigating that avenue of attack beyond just changing the boot sequence in the BIOS & password-protecting the BIOS setup?

 

* I understand many other vulnerabilities exist on running operating systems, such as buffer overflow attacks on system services via the network, but I find that avenue of attack less likely than simply using a boot disc (as described above), esp as self-encrypting drives become more widespread.

_______________________________________________
FDE mailing list
F...@www.xml-dev.com
http://www.xml-dev.com/mailman/listinfo/fde







_______________________________________________
FDE mailing list
F...@www.xml-dev.com
http://www.xml-dev.com/mailman/listinfo/fde

_______________________________________________
FDE mailing list
F...@www.xml-dev.com
http://www.xml-dev.com/mailman/listinfo/fde

---

---

_______________________________________________
FDE mailing list
F...@www.xml-dev.com
http://www.xml-dev.com/mailman/listinfo/fde

 

[Tim Hollebeek]

> Begging the question: Are there ways of mitigating that avenue of
> attack beyond just changing the boot sequence in the BIOS & password-
> protecting the BIOS setup?

Booting to an alternative operating system can be defeated by clever
choice of the physical memory location where the key material is stored.
This trick doesn't apply as well to hardware FDE systems, but works very
nicely for software systems.

See Defense #2 in this talk:

http://www.blackhat.com/presentations/bh-usa-08/McGregor/BH_US_08_McGregor_C
old_Boot_Attacks.pdf

Tim Hollebeek
BitArmor Systems

[Lark Allen]

Garrett,

 

It is important to note that there are some OS related security modes which do not engage the hardware level drive security.

 

The threat model for self-encrypting drives is protection for data at rest, that is, when the machine has been powered down such as when Windows has been put into hibernation mode or completely shut down.     I’m not sure, but I do not believe screen locking Windows has any affect on unpowering the disk drive, thereby causing it to lock.   If that is the case, then your scenario is likely correct and the machine could be rebooted with an alternate OS to defeat the OS security, not the drive security.  For instance, I know that just doing a warm reboot/restart of Windows does not unpower the drive, therefore, during the reboot, the drive will not require authentication since it has remained in an unlocked state. 

 

The correct procedure in order to engage the SED drive locking would be for the user to put the system into hibernation mode whenever they leave the system.  As I mentioned, the Embassy software will not allow Windows standby mode since it does not unpower the drive either, so if standby mode is selected it will be automatically defaulted to hibernation mode.    There is a notable exception for Dell systems shipping today with Seagate encrypting drives and Wave’s Embassy software.  Dell, Seagate, and Wave engineered a secure standby mode solution, but only on Dell’s platforms.  All other platforms will need hibernation mode or complete power off in order to engage drive locking. 

 

As a side point since there was much discussion about the Princeton Cold Boot attacks, the encryption keys and authentication credentials are always held and used inside the secure hardware of the self-encrypting drives, therefore, none of the described system memory attacks could discover any of these secrets since they are never held in memory. 

 

Thanks,    

 

Lark Allen

[Dmitry Obukhov]

Hi Garrett,

 

The described attack is not in the SED threat model. As Lark said, we are focusing on data-at-rest. Basically, you described hi-jack attack, when powered-on computer is stolen. You will need one more element in the system, proximity sensor, to mitigate this attack. There are plenty of sensors on the market:

 

For example:

http://www.officedepot.com/a/products/823445/Tripp-Lite-Wireless-USB-Proximity-Lock/?cm_mmc=Mercent-_-Google-_-Security_Tools_and_Cleaning-_-823445&mr:trackingCode=0DD648A0-CD65-DE11-B7F3-0019B9C043EB&mr:referralID=NA

 

If you have built-in Bluetooth, you can use software solution like this one: http://www.bluetoothpassport.com/

or even freeware open source: http://members.lycos.co.uk/wuul/bluelock/readme.html

 

You may need to change sensor software configuration to hibernate instead of sleep or starting screensaver. In combination with hardware disk encryption it will give you good protection against hijack and even against followed cold boot attack on hi-jacked machine.

 

Dmitry

 

 

---

[Darren Lasko]

It should be noted that a "Root of Trust for Measurement" (RTM), as defined in the TCG's TPM specs, in conjunction with the Platform Configuration Registers (PCRs) of a TPM, can be used to mitigate the threat of booting an alternate OS from a different boot device such as a USB stick.  If configured, the process measures the system BIOS, master boot record (MBR), OS Loader, etc. to make sure that nothing has changed, and halts the boot process if anything has changed.

As Dmitry indicated, booting up an alternate OS using a different boot device is something that the actual SED can't protect against... no more than it can protect against a virus infection in the OS.  You need a separate, complementing solution like the ones Dmitry mentioned or the TPM/RTM.  The SED is a very important piece of an overall security solution, but on its own doesn't make your system 100% secure.  You'll still need your firewall, virus scanner, and even a way to ensure alternate operating systems can't be loaded (if that's a concern in your threat model).

Best regards,
Darren Lasko
Principal Engineer
Advanced Development Group, Storage Products
Fujitsu Computer Products of America

Dmitry Obukhov <d.ob...@samsung.com> Sent by: fde-b...@www.xml-dev.com 07/15/2009 02:53 PM Please respond to f...@www.xml-dev.com

To f...@www.xml-dev.com cc

This message contains information which may be confidential and privileged. Unless you are the addressee (or authorized to receive for the addressee), you may not use, copy or disclose to anyone the message or any information contained in the message. If you have received the message in error, please advise the sender by reply [email], and delete the message.

[Garrett M. Groff]

I'm definitely not suggesting that hardware-based FDE should also handle OS attacks, attacks on RAM, etc. That would certainly fall out of scope with the purpose of the drive. The only remaining concern I have is that hardware FDE doesn't require re-authentication on reboot. Again, hibernation or shutdown defeat this attack scenario, but security is about risk assessment, so that is what I'm trying to gauge here (the relative risks associated with hardware FDE vs software FDE).

 

------------------

 

Changing gears slightly...

 

Can anyone describe the anti-hammering that is built into the Seagate FDE drive (to preclude brute-forcing the authentication passphrase)?

 

G

----- Original Message -----
From: Dmitry Obukhov
To: f...@www.xml-dev.com
Sent: Tuesday, July 14, 2009 3:52 PM
Subject: Re: [FDE] Q concerning hardware-based encryption/security

Hi Garrett,
 
The described attack is not in the SED threat model. As Lark said, we are focusing on data-at-rest. Basically, you described hi-jack attack, when powered-on computer is stolen. You will need one more element in the system, proximity sensor, to mitigate this attack. There are plenty of sensors on the market:
 
For example:
http://www.officedepot.com/a/products/823445/Tripp-Lite-Wireless-USB-Proximity-Lock/?cm_mmc=Mercent-_-Google-_-Security_Tools_and_Cleaning-_-823445&mr:trackingCode=0DD648A0-CD65-DE11-B7F3-0019B9C043EB&mr:referralID=NA
 
If you have built-in Bluetooth, you can use software solution like this one: http://www.bluetoothpassport.com/
or even freeware open source: http://members.lycos.co.uk/wuul/bluelock/readme.html
 
You may need to change sensor software configuration to hibernate instead of sleep or starting screensaver. In combination with hardware disk encryption it will give you good protection against hijack and even against followed cold boot attack on hi-jacked machine.
 
Dmitry
 
 

[Scott S]

Garrett,

If you are just using just BIOS's drive lock password feature, the drive
will lock after three password failures, and requires a power off/on to
reset the FDE drive.

If one is using a management software for the FDE drive, one can choose
from multiple types of responses to a brute force attack. In
addition to drive locking after some number of password failures, it can
be made so that the password becomes disabled (requiring a
"administrative" password that is more complex) or wipes the drive clean.

Scott

[Robert Wann]

There exists an effective solution to mitigate the OS attacks (warm boot as being described by Garrett) using all disk drives including SED and FDE. This can be done without a TPM or any other extra components as suggested by Dmitry & Darren.

 

Garrett said:

<Thanks for the info, Lark.
 
So the attack vector is reduced to:
1. the machine is on* (like if the user locks his screen & walks away for a moment), and then
2. someone steals the laptop (leaving it on), and then
3. restarts the machine using a boot disc or bootable USB stick.>

A warm boot such as Ctl-Alt-Del causes SATA host to issue COMRESET which in turn resets device protocol stacks without power being interrupted. What SED and FDE would need to perform is to reset the crypto engine upon COMRESET to invalidate the AES secret key of either the disk controller (if the crypto engine is embedded within the disk controller) or the separate crypto controller working in conjunction with the disk controller. The solution is indifferent to the boot sequence.

 

The X-Wall MX (http://www.enovatech.net/products/mx_info.htm) does just that.

 

Thanks,

 

Robert Wann

CTO

Enova Technology Corp.

www.enovatech.com; in...@enovatech.com;

 

[Darren Lasko]

Robert,

Unfortunately, resetting the crypto on a COMRESET can cause many other problems.  Other things can cause a COMRESET to occur on the SATA bus besides a warm boot.  Some COMRESETs are "commanded", i.e. the OS might explicitly request a COMRESET to be sent to the device if a pending command is taking too long to complete.  Other COMRESETs are "non-commanded", and might occur as a result of temporary loss of synchronization between the host and the device (e.g. due to a flaky SATA cable) or possibly when exiting a SATA low-power state such as Partial or Slumber.  Some chipsets are notorious for sending many non-commanded COMRESETs.

If the device resets its crypto (i.e. forgets the key) every time a COMRESET is received, you could be headed for many system crashes.

Best regards,
Darren Lasko
Principal Engineer
Advanced Development Group, Storage Products
Fujitsu Computer Products of America

"Robert Wann" <rw...@enovatech.com> Sent by: fde-b...@www.xml-dev.com 07/16/2009 11:13 AM Please respond to Robert Wann <rw...@enovatech.com>; Please respond to f...@www.xml-dev.com

To <f...@www.xml-dev.com> cc

http://www.xml-dev.com/mailman/listinfo/fde_______________________________________________

FDE mailing list
F...@www.xml-dev.com
http://www.xml-dev.com/mailman/listinfo/fde

[Robert Wann]

Darren,

 

Indeed there are occasions, in addition to the warm boot, that a host would issue a COMRESET. A host timeout (as you described the situation of pending unexecuted commands) might have issued COMRESET but it only happens whenever there is a deadlock condition. In modern disk drive controller design, an IDLE state, other than deadlock, would have been presented such that host would re-issue the commands. If indeed a COMRESET is issued, there are command layer protocols to be exchanged to get ready for the data transfer from both the host and device. If the device isn't ready (in this case, assuming the crypto engine of the FDE and SED devices isn't ready), the data transfer won't occur, situation that causes a system hang not crash. A cold boot would be required to back to normal state.

 

An additional software AP or hardware logic can handle the COMRESET for re-authentication If the ownership of a system remains righteous. I suspect that anyone would care of a disk crash if the system is in the wrong hands.

 

More, COMWAKE is normally used to revive the disk drive from power management mode instead of issuing COMRESET as COMWAKE does not reset the entire protocol stacks.

 

Thanks,

 

Robert Wann 

[Daniel Feenberg]

On Thu, 16 Jul 2009, Robert Wann wrote:

> There exists an effective solution to mitigate the OS attacks (warm boot
> as being described by Garrett) using all disk drives including SED and
> FDE. This can be done without a TPM or any other extra components as
> suggested by Dmitry & Darren.
>
> Garrett said:
> <Thanks for the info, Lark.
>
> So the attack vector is reduced to:
> 1. the machine is on* (like if the user locks his screen & walks away for a moment), and then
> 2. someone steals the laptop (leaving it on), and then
> 3. restarts the machine using a boot disc or bootable USB stick.>

I am missing something very elementary here - why shouldn't the screen
lock turn off decryption? Why would the system need to wait for the reset?
Is it so that threads can continue to execute? Is that a widespread
requirement on a laptop?

Daniel Feenberg

> ------------------------------------------------------------------------------

[Dmitry Obukhov]

Robert,

 

All this discussion doesn’t mean that we, manufacturers, developers, specification writers, can not change locking state on COMRESET. Yes, we can, and it is trivial change.

 

However, primum noli no cere. The consequences of the trivial change are not trivial at all. Without support from OS/RAID vendors, comprehensive testing with different OS and applications, this feature is very dangerous. It can damage user’s data on the level of file system, slow down RAID controllers, and will break backward compatibility, because old OS doesn’t handle it. And all this is just to defeat a threat that is not in the scope of the solution and can be defeated in ten better ways?

 

WBR,

Dmitry Obukhov,

Samsung Secure Storage

 

 

---

[Dmitry Obukhov]

Daniel,

When screen lock is activated, the system can continue actively use its
drive. For example, you may be downloading Ubuntu distributive from slow
server, or running long test, or just running Outlook and writing to PST
file every time new e-mail received.
Any of these activities require access to the drive, so screen lock can
not lock the drive.

WBR,
Dmitry Obukhov
Samsung Secure Storage

-----Original Message-----
From: fde-b...@www.xml-dev.com [mailto:fde-b...@www.xml-dev.com] On
Behalf Of Daniel Feenberg
Sent: Thursday, July 16, 2009 1:50 PM
To: Robert Wann; f...@www.xml-dev.com
Subject: Re: [FDE] Q concerning hardware-based encryption/security