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
Enova Technology Corp.
www.enovatech.com; i...@enovatech.com;
----- Original Message -----
From: Darren Lasko
To: Robert Wann ; fde@www.xml-dev.com
Sent: Friday, July 17, 2009 2:15 AM
Subject: Re: [FDE] Q concerning hardware-based encryption/security
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-boun...@www.xml-dev.com
07/16/2009 11:13 AM Please respond to
Robert Wann <rw...@enovatech.com>; Please respond to
fde@www.xml-dev.com
To <fde@www.xml-dev.com>
cc
Subject Re: [FDE] Q concerning hardware-based encryption/security
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; i...@enovatech.com;
----- Original Message -----
From: Garrett M. Groff
To: fde@www.xml-dev.com
Sent: Thursday, July 16, 2009 5:54 AM
Subject: Re: [FDE] Q concerning hardware-based encryption/security
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: fde@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
From: fde-boun...@www.xml-dev.com [mailto:fde-boun...@www.xml-dev.com] On
Behalf Of Garrett M. Groff
Sent: Wednesday, July 08, 2009 11:30 AM
To: fde@www.xml-dev.com
Subject: Re: [FDE] Q concerning hardware-based encryption/security
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.
----- Original Message -----
From: Lark Allen
To: fde@www.xml-dev.com
Sent: Wednesday, July 08, 2009 11:42 AM
Subject: Re: [FDE] Q concerning hardware-based encryption/security
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.
From: fde-boun...@www.xml-dev.com [mailto:fde-boun...@www.xml-dev.com] On
Behalf Of Garrett M. Groff
Sent: Monday, July 06, 2009 11:23 AM
To: fde@www.xml-dev.com
Subject: [FDE] Q concerning hardware-based encryption/security
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.
_______________________________________________
FDE mailing list
FDE@www.xml-dev.com
http://www.xml-dev.com/mailman/listinfo/fde
_______________________________________________
FDE mailing list
FDE@www.xml-dev.com
http://www.xml-dev.com/mailman/listinfo/fde
----- Original Message -----
From: Lark Allen
To: fde@www.xml-dev.com
Sent: Wednesday, July 08, 2009 11:42 AM
Subject: Re: [FDE] Q concerning hardware-based encryption/security
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.
From: fde-boun...@www.xml-dev.com [mailto:fde-boun...@www.xml-dev.com] On
Behalf Of Garrett M. Groff
Sent: Monday, July 06, 2009 11:23 AM
To: fde@www.xml-dev.com
Subject: [FDE] Q concerning hardware-based encryption/security
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.
_______________________________________________
FDE mailing list
FDE@www.xml-dev.com
http://www.xml-dev.com/mailman/listinfo/fde
----- Original Message -----
From: Lark Allen
To: fde@www.xml-dev.com
Sent: Wednesday, July 08, 2009 11:42 AM
Subject: Re: [FDE] Q concerning hardware-based encryption/security
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.
From: fde-boun...@www.xml-dev.com [mailto:fde-boun...@www.xml-dev.com] On
Behalf Of Garrett M. Groff
Sent: Monday, July 06, 2009 11:23 AM
To: fde@www.xml-dev.com
Subject: [FDE] Q concerning hardware-based encryption/security
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.
_______________________________________________
FDE mailing list
FDE@www.xml-dev.com
http://www.xml-dev.com/mailman/listinfo/fde
_______________________________________________
FDE mailing list
FDE@www.xml-dev.com
http://www.xml-dev.com/mailman/listinfo/fde
------------------------------------------------------------------------------
_______________________________________________
FDE mailing list
FDE@www.xml-dev.com
http://www.xml-dev.com/mailman/listinfo/fde_______________________________________________
FDE mailing list
FDE@www.xml-dev.com
http://www.xml-dev.com/mailman/listinfo/fde
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.
_______________________________________________
FDE mailing list
FDE@www.xml-dev.com
http://www.xml-dev.com/mailman/listinfo/fde
