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-boun...@www.xml-dev.com [mailto:fde-boun...@www.xml-dev.com] On Behalf Of Daniel Feenberg Sent: Thursday, July 16, 2009 1:50 PM To: Robert Wann; fde@www.xml-dev.com Subject: Re: [FDE] Q concerning hardware-based encryption/security 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 > > 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-Proximi ty-Lock/?cm_mmc=Mercent-_-Google-_-Security_Tools_and_Cleaning-_-823445&mr:t rackingCode=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 _______________________________________________ FDE mailing list FDE@www.xml-dev.com http://www.xml-dev.com/mailman/listinfo/fde
