Cloud Computing on the News Hour with Jim Lehrer

SPENCER MICHELS: What’s a peta-byte?

ERIC SCHMIDT: It’s not a crime. :) It’s just a very large number of tera-bytes.

SPENCER MICHELS: The obvious question is, you or salesforce or IBM or somebody else has MY data in YOUR servers, why should I rest easy? There is a chance that they could do something with it. They could give it to the government

ERIC SCHMIDT: If it is in your servers, the government can take it too.  So it is important to understand that we operate under exactly the same laws that you do. And if your information is so important you have to hide it from the government, we probably don't want you to give it to us anyway.

SPENCER MICHELS: Now those companies, and there are 5 or 6 of them I guess who are involved in this, seem to be competing with each other but they also seem to be cooperating with each other. Straighten that out for me.

ERIC SCHMIDT:  This competition and cooperation is the norm in the internet. We all benefit by having people move from the older systems, the locked PC systems if you will, to these open networks. But once you move there, we compete vigorously over this solution for that solution. That competition is very good for consumers.

Click here to watch the full interview with Eric Schmidt, CEO of Google.

Using cURL to download a Google Spreadsheet as .xls (Excel)

First obtain a Authentication Token:
# curl https://www.google.com/accounts/ClientLogin -d Email=user@quantumcrypto.de –d Passwd=mysecretpassword –d accountType=HOSTED_OR_GOOGLE  -d source=cURL-Example -d service=wise

This will return something that looks as follows:

SID=DQAAAHYBADCv2pSv7nflacDNwz3zEDUGtrSvNVDcpkSfddi77b3U5sEaHmP8YLWhmA36F9rk85mL8J5dqo4apn0T1vKz0fPGI9Xtnuet6cuE2ZzYvrNIwbSC_HjTqF4zudNQnnlDuD2wqZT-g1qXI8KhGAQZV4NexHZoQPlabTsGuRZeIBxj1A LSID=EUBBBIaBADCl-kNxvRVmcQghpt3cqSMfEooKR9flLOUZqwgP9OrZS83gse-KSdTNeXhxsET7FYenDhceP9lIPOmesH-t9qh-AWUHjjMdZEbUNeF9mWyzln6Z-FajaiG-cVFkqW0ZJ8ZbnCP30xXj6xFK6QxaAcqy_9Pej8jhEnxS9E61ftQGPg Auth=EUBBIacAAADK-kNxvRVmcQghpt3cqSMfEooLNMflLNIQqwgP9OrZS83gs-KSdTNeXhxsET7FYePWmaD8Vsy1V4LSUGMUP48Je2TO8OcjBj6HgAtPhiZeX-gKDfagZDK44j4n-Tkb44nhOnp2_QPSnBj3Z2vYwOEDjjG3Q53aQVC2132JKOuGh

To export a Google Spreadsheet as .xls (Excel):
# curl --silent --header "Authorization: GoogleLogin auth=AUTHKEY" http://spreadsheets.google.com/feeds/download/spreadsheets/Export?key=spreadsheetkey&exportFormat=xls

exportFormat Parameter Value	Format of the returned Spreadsheet
xls	XLS (Microsoft Excel)
csv	CSV (Comma Separated Value)
pdf	PDF (Portable Document Format)
ods	ODS (Open Document Spreadsheet)
tsv	TSV (Tab Separated Value)
html	HTML Format

Re: Weakness in Social Security Numbers Is Found

On Jul 8, 2009, at 8:46 PM, dan@geer.org wrote:
> I don't honestly think that this is new, but even
> if it is, a 9-digit random number has a 44% chance
> of being a valid SSN (442 million issued to date).
Different attack. What they are saying is that given date and place
of birth - not normally considered particularly sensitive - they have
a good chance of predicting *a particular person's* SSN.

For untargetted attacks, broad statistics about the number of SSN's
out there are fine. But much attention these days is on targetted
attacks against "high value" individuals. It's in fact probably
*easier* to find basic biographical information about date and place
of birth of such individuals - you can often get much of it for, say,
CEO's of public companies from their own brief bio's of their senior
officers; scan newspapers for charity birthday events and you can get
quite a bit more - than for a random member of the population.

Now, whether this really buys you all that much over other ways of
getting hold of SSN's is questionable - and in fact the researchers
are quoted as saying it's more of a demonstration of principle than
anything practical.

BTW, 442 million SSN's have been issued, but how many are for people
who have since died? For many attacks, you need one for a living
victim, which lowers the probability.
-- Jerry

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

112-bit prime ECDLP solved

Hi all,

We are pleased to announce that we have set a new record for the elliptic
curve discrete logarithm problem (ECDLP) by solving it over a 112-bit
finite field. The previous record was for a 109-bit prime field and
dates back from October 2002. Our calculation was done on a cluster of
more than 200 PlayStation 3 game consoles at the EPFL.

See for more details our announcement at http://lacal.epfl.ch/page81774.html.

Best regards,

Joppe Bos

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Re: [FDE] Q concerning hardware-based encryption/security

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

From: fde-bounces@www.xml-dev.com [mailto:fde-bounces@www.xml-dev.com] On Behalf Of Garrett M. Groff
Sent: Wednesday, July 08, 2009 2:30 PM
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-bounces@www.xml-dev.com [mailto:fde-bounces@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-bounces@www.xml-dev.com [mailto:fde-bounces@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-bounces@www.xml-dev.com [mailto:fde-bounces@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

 

 

Re: Weakness in Social Security Numbers Is Found

dan@geer.org wrote:
> I don't honestly think that this is new, but even
> if it is, a 9-digit random number has a 44% chance
> of being a valid SSN (442 million issued to date).

I wonder if the UK NI numbers suffer from a similar problem.

The look a little like this: AB 12 34 56 C

Information on how they are strutured is here:

http://en.wikipedia.org/wiki/National_Insurance#National_Insurance_number

However given we don't use the NI number in the UK like the SSN is
abused in the US there isn't the same security risk in guessing them.
Although the Wikipedia article claims they are sometimes used for
identification I know I have never been asked for mine other than by an
employer or suitably authorised government body how has a real need to know.

--
Darren J Moffat

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Re: [FDE] Q concerning hardware-based encryption/security

> 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

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

Very high rate true random number generation

Randomness from quantum effects at Megabits per second (and they claim
they can get to Gb/s). I can't say I follow all the details of what
they're doing.

http://spie.org/x35516.xml
-- Jerry

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Re: Weakness in Social Security Numbers Is Found

I don't honestly think that this is new, but even
if it is, a 9-digit random number has a 44% chance
of being a valid SSN (442 million issued to date).

Similarly, with Chase and Citi each at about 100M
cards issued, and the 16-digit card number having
7 of those digits fixed-in-advance, a 16-digit
random number has a 10% chance of being a valid
card number. Amex cards are 15-digits and there
are 50M in play, so a random 15-digit number has
a 50% chance of being a valid card number. As such,
an attacker is better off holding the password
constant and cycling through account numbers than
holding the account number constant and cycling
through password guesses.

Yes, these are approximations for the purpose of
argument, but I don't see what the big deal is for
the "All The News That's Fit to Print" paper in
learning that there ain't much entropy in SSNs.
Hell, my brother and I have sequential numbers.

--dan

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Re: Weakness in Social Security Numbers Is Found

docbook.xml@gmail.com (Ali, Saqib) on Wednesday, July 8, 2009 wrote:

>Read more:
>http://www.nytimes.com/2009/07/07/us/07numbers.html?_r=2&ref=instapundit
>
>
>saqib
>http://www.capital-punishment.us
>
>[Moderator's note: this isn't really a weakness in SSNs, unless you're
>stupid enough to use them as a password -- which we already knew was
>bad. None the less, interesting work. --Perry]

How separate algorithms reduce security when used together:

The last 4 digits of the SSN are frequently used as an authenticator. These
may be the hardest digits to recover with the technique which, according to
the researchers (Alessandro Acquisti and Ralph Gross) at CMU, would not be
easy for cybercriminals to reconstruct but would be within the grasp of
sophisticated attackers.

My solution is to have the Social Security Administration announce that
they will publish names and SSNs for everyone in their database on a
certain date. Fat chance it will happen.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz |"Web security is like medicine - trying to do good for
408-356-8506 |an evolved body of kludges" - Mark Miller
www.periwinkle.com |

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

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-bounces@www.xml-dev.com [mailto:fde-bounces@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-bounces@www.xml-dev.com [mailto:fde-bounces@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-bounces@www.xml-dev.com [mailto:fde-bounces@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

 

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-bounces@www.xml-dev.com [mailto:fde-bounces@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.

Weakness in Social Security Numbers Is Found

Read more:
http://www.nytimes.com/2009/07/07/us/07numbers.html?_r=2&ref=instapundit

saqib
http://www.capital-punishment.us

[Moderator's note: this isn't really a weakness in SSNs, unless you're
stupid enough to use them as a password -- which we already knew was
bad. None the less, interesting work. --Perry]
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

[FDE] Weakness in Social Security Numbers Is Found

Read more:
http://www.nytimes.com/2009/07/07/us/07numbers.html?_r=2&ref=instapundit

Re: MD6 withdrawn from SHA-3 competition

Paul Hoffman wrote:
> At 10:39 AM -0700 7/4/09, Hal Finney wrote:
>
>> But how many other hash function candidates would also be excluded if
>> such a stringent criterion were applied? Or turning it around, if NIST
>> demanded a proof of immunity to differential attacks as Rivest proposed,
>> how many candidates have offered such a proof, in variants fast enough
>> to beat SHA-2?
>>
>
> The more important question, and one that I hope gets dealt with, is
> what is a sufficient proof. We know what proofs are, but we don't have
> a precise definition. We know what a proof should look like, sort
> of. Ron and his crew have their own definition, and they can't make
> MD6 work within that definition. But that doesn't mean that NIST
> wouldn't have accepted the fast-enough MD6 with a proof from someone
> else.

Mathematicians have a precise definition of what a proof is, thanks to
logicians like David Hilbert and Kurt Goedel. But people in all
disciplines have a terrible time formulating problems, and remembering
the conditions under which a statement was proved. They also quote
theorems incorrectly, and errors propagate through the less
well-reviewed parts of the literature.

--
Josh Rubin
jlrubin@gmail.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Re: MD6 withdrawn from SHA-3 competition

At 10:39 AM -0700 7/4/09, Hal Finney wrote:
>But how many other hash function candidates would also be excluded if
>such a stringent criterion were applied? Or turning it around, if NIST
>demanded a proof of immunity to differential attacks as Rivest proposed,
>how many candidates have offered such a proof, in variants fast enough
>to beat SHA-2?

Several hash candidates have proofs against differential attacks but only
four with such proofs are faster than SHA-2 (Edon-R, Shabal, Cheetah and
Keccak).
But according to http://eprint.iacr.org/2008/511.pdf
Keccak and Cheetah in 32-bit mode are not actually faster than SHA-2.

C.K.F. Lin

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Re: MD6 withdrawn from SHA-3 competition

On Sat, 2009-07-04 at 10:39 -0700, "Hal Finney" wrote:
> Rivest:
> > Thus, while MD6 appears to be a robust and secure cryptographic
> > hash algorithm, and has much merit for multi-core processors,
> > our inability to provide a proof of security for a
> > reduced-round (and possibly tweaked) version of MD6 against
> > differential attacks suggests that MD6 is not ready for
> > consideration for the next SHA-3 round.
>
> But how many other hash function candidates would also be excluded if
> such a stringent criterion were applied? Or turning it around, if NIST
> demanded a proof of immunity to differential attacks as Rivest proposed,
> how many candidates have offered such a proof, in variants fast enough
> to beat SHA-2?

I think "resistance to attacks" (note absence of any restrictive
adjective such as "differential") is a very important property
(indeed, one of the basic defining criteria) to demonstrate
in a hash algorithm. If someone can demonstrate an attack,
differential or otherwise, or show reason to believe that such
an attack may exist, then that should be sufficient grounds
to eliminate a vulnerable candidate from any standardization
competition.

In other words, the fact that MD6 can demonstrate resistance to
a class of attacks, if other candidates cannot, should stand in
its favor regardless of whether the competition administrators
say anything about proving resistance to any particular *kind*
of attacks. If that does not stand in its favor then the
competition is exposed as no more than a misguided effort to
standardize on one of the many Wrong Solutions.

Bear

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

[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.

Re: MD6 withdrawn from SHA-3 competition

At 10:39 AM -0700 7/4/09, Hal Finney wrote:
>But how many other hash function candidates would also be excluded if
>such a stringent criterion were applied? Or turning it around, if NIST
>demanded a proof of immunity to differential attacks as Rivest proposed,
>how many candidates have offered such a proof, in variants fast enough
>to beat SHA-2?

The more important question, and one that I hope gets dealt with, is what is a sufficient proof. We know what proofs are, but we don't have a precise definition. We know what a proof should look like, sort of. Ron and his crew have their own definition, and they can't make MD6 work within that definition. But that doesn't mean that NIST wouldn't have accepted the fast-enough MD6 with a proof from someone else.

--Paul Hoffman, Director
--VPN Consortium

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Re: MD6 withdrawn from SHA-3 competition

At 11:49 PM -0400 7/3/09, Steven M. Bellovin wrote:
>Here's the essential paragraph:
>
> Thus, while MD6 appears to be a robust and secure cryptographic
> hash algorithm, and has much merit for multi-core processors,
> our inability to provide a proof of security for a
> reduced-round (and possibly tweaked) version of MD6 against
> differential attacks suggests that MD6 is not ready for
> consideration for the next SHA-3 round.

At 10:12 AM +0000 7/4/09, Brandon Enright wrote:
>It wasn't entirely clear to me if it really was withdrawn. Ron Rivest
>posted on behalf of the MD6 team some thoughts on MD6 performance and
>specifically suggested/requested that NIST ask for submitted algorithms
>to be "provably resistant to differential attacks".

I agree more with Brandon than with Steve, but who knows. I read Ron's message as a challenge to NIST about whether or not NIST would really rely on the proofs. It was clear they didn't want to withdraw MD6, but that they felt like they had to because of the speed requirement.

--Paul Hoffman, Director
--VPN Consortium

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Re: MD6 withdrawn from SHA-3 competition

Rivest:
> Thus, while MD6 appears to be a robust and secure cryptographic
> hash algorithm, and has much merit for multi-core processors,
> our inability to provide a proof of security for a
> reduced-round (and possibly tweaked) version of MD6 against
> differential attacks suggests that MD6 is not ready for
> consideration for the next SHA-3 round.

But how many other hash function candidates would also be excluded if
such a stringent criterion were applied? Or turning it around, if NIST
demanded a proof of immunity to differential attacks as Rivest proposed,
how many candidates have offered such a proof, in variants fast enough
to beat SHA-2?

Hal Finney

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Re: MD6 withdrawn from SHA-3 competition

On Thu, 2 Jul 2009 20:51:47 -0700 or thereabouts "Joseph Ashwood"
<ashwood@msn.com> wrote:

> Sent: Wednesday, July 01, 2009 4:05 PM
> Subject: MD6 withdrawn from SHA-3 competition
>
> > Also from Bruce Schneier, a report that MD6 was withdrawn from the
> > SHA-3 competition because of performance considerations.
>
> I find this disappointing. With the rate of destruction of primitives
> in any such competition I would've liked to see them let it stay
> until it is either broken or at least until the second round. A quick
> glance at the SHA-3 zoo and you won't see much left with no attacks.
> It would be different if it was yet another M-D, using AES as a
> foundation, blah, blah, blah, but MD6 is a truly unique and
> interesting design.
>
> I hope the report is wrong, and in keeping that hope alive, the MD6
> page has no statement about the withdrawl.
> Joe
>

It wasn't entirely clear to me if it really was withdrawn. Ron Rivest
posted on behalf of the MD6 team some thoughts on MD6 performance and
specifically suggested/requested that NIST ask for submitted algorithms
to be "provably resistant to differential attacks".

The logic was that MD6 is slow because the high number of rounds is
needed in their proof. They won't tweak/submit a version that doesn't
meet this requirement of theirs and based on the current contest
requirements, they can't be competitive speed-wise without losing their
proof of resistance to differential attacks. Unless the contest
changes to require such a proof, there is no point in moving MD6
forward.

Brandon

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Re: What will happen to your crypto keys when you die?

On Fri, Jul 3, 2009 at 4:37 AM, Jack Lloyd<lloyd@randombit.net> wrote:
> On Thu, Jul 02, 2009 at 09:29:30AM +1000, silky wrote:
> > A potentially amusing/silly solution would be to have one strong key
> > that you change monthly, and then, encrypt *that* key, with a method
> > that will be brute-forceable in 2 months and make it public. As long
> > as you are constantly changing your key, no-one will decrypt it in
> > time, but assuming you do die, they can potentially decrypt it while
> > arranging your funeral :)
>
> This method would not work terribly well for data at rest. Copy the
> ciphertext, start the brute force process, and two months later you
> get out everything, regardless of the fact that in the meantime the
> data was reencrypted.

Indeed, hence the reason I suggested encrypting only your "real" key
with this method. By the time you're done decrypting that, you've only
gotten a stale key. Of course the approach isn't really practical in
principle, it's only cute.

> -Jack

--
noon silky
http://lets.coozi.com.au/

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com