Full disk encryption ... suggest better encryption method ...

Hi all

We are building a full disk encryption ( including MBR ) most of the things
are done . Now we have to make a installer for the system . We plan that the
encryption system will encrypt the drive in the backend and let the user to
continue work .

So we have a problem … If there is a sudden power surge the user will end
up with a half encrypted disk . We plan to over come this by keeping a
scratch space ( all data being encrypted is first stored here to prevent
data corruption ) and a counter of the last Logical Block Address (LBA)
encrypted this way the pre boot system and the post boot driver will read
the disk accordingly ( enc / dec on the fly accordingly ) and on next start
the encryption installer will continue .

But the problem with this method is that the scratch space is being kept on
the MBR and the size is 8 Kb ( right now ) so this means we will write this
space when we encrypt every 8k of data and the lba is increased accordingly
. But it leads to 128 writes to this space for encrypting 1 MB of data and
similarly we end up with 10485760 writes for encrypting 80 GB disk . I think
the number is quite big and if multiplied with disk latency it’ll slow down
the encryption and also these many writes might corrupt the disk sector .

So i would like to ask you experts is there a better way of doing this which
is faster and better .

Thanking you all in advace …

Alex Dirk

Hello Alex,

just a thought…
what if you could allocate a file on contiguous sectors .
http://www.sysinternals.com/Information/DiskDefragmenting.html
has some information ( undoc apis at that time … maybe now they
are available ? ). Then you could lock the file so that you can
use it as a buffer. I think you may even try with non-contiguous
files and use a small list of sectors+sizes…

Then in the 8Kb you can store information about that file (
size, starting sector or event a bitmap of sectors in case you
can’t find enough free contiguous sectors… 8 Kb ought to be
enough for everybody :wink: ).

Do you think this would work ?


Best regards,
Alex mailto:xxxxx@bitdefender.com

Wednesday, September 14, 2005, 9:48:41 AM, you wrote:

Hi all

We are building a full disk encryption ( including MBR ) most of the things
are done . Now we have to make a installer for the system . We plan that the
encryption system will encrypt the drive in the backend and let the user to
continue work .

So we have a problem … If there is a sudden power surge the user will end
up with a half encrypted disk . We plan to over come this by keeping a
scratch space ( all data being encrypted is first stored here to prevent
data corruption ) and a counter of the last Logical Block Address (LBA)
encrypted this way the pre boot system and the post boot driver will read
the disk accordingly ( enc / dec on the fly accordingly ) and on next start
the encryption installer will continue .

But the problem with this method is that the scratch space is being kept on
the MBR and the size is 8 Kb ( right now ) so this means we will write this
space when we encrypt every 8k of data and the lba is increased accordingly
. But it leads to 128 writes to this space for encrypting 1 MB of data and
similarly we end up with 10485760 writes for encrypting 80 GB disk . I think
the number is quite big and if multiplied with disk latency it’ll slow down
the encryption and also these many writes might corrupt the disk sector .

So i would like to ask you experts is there a better way of doing this which
is faster and better .

Thanking you all in advace …

Alex Dirk


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


This message was scanned for spam and viruses by BitDefender.
For more information please visit http://www.bitdefender.com/

The best way to do full disc encryption is to have the disc firmware do the
deed. This way, everything on the disc is encrypted, from MBR to pagefile to
MFT$, and totally inaccessible unless the disc is unlocked by presenting the
proper credentials; e.g. password. FDE will not even allow you to access the
disc media unless you totally disassemble the disc and move the media to
another carrier and head assembly.


The personal opinion of
Gary G. Little

“Alex Dirk” wrote in message news:xxxxx@ntdev…
Hi all

We are building a full disk encryption ( including MBR ) most of the things
are done . Now we have to make a installer for the system . We plan that
the encryption system will encrypt the drive in the backend and let the user
to continue work .

So we have a problem … If there is a sudden power surge the user will end
up with a half encrypted disk . We plan to over come this by keeping a
scratch space ( all data being encrypted is first stored here to prevent
data corruption ) and a counter of the last Logical Block Address (LBA)
encrypted this way the pre boot system and the post boot driver will read
the disk accordingly ( enc / dec on the fly accordingly ) and on next start
the encryption installer will continue .

But the problem with this method is that the scratch space is being kept on
the MBR and the size is 8 Kb ( right now ) so this means we will write this
space when we encrypt every 8k of data and the lba is increased accordingly
. But it leads to 128 writes to this space for encrypting 1 MB of data and
similarly we end up with 10485760 writes for encrypting 80 GB disk . I think
the number is quite big and if multiplied with disk latency it’ll slow down
the encryption and also these many writes might corrupt the disk sector .

So i would like to ask you experts is there a better way of doing this which
is faster and better .

Thanking you all in advace …

Alex Dirk

I would actually suggest that rather than use a password based
encryption scheme, a physical token (smart card, biometric device) plus
password would be stronger.

The risk with passwords is that they can be compromised. By using two
points of identification (something you have - like a fingerprint,
something you know - like a password).

Another interesting point here is that you don’t want to necessarily
disclose that the media is itself encrypted, so you don’t want the disk
drive to be specially identified. In that way, someone analyzing it
will merely see a “pile of garbage”. I haven’t done detailed analysis
of disk drives but I know that there are often regions of the drive that
are unused; provided that those unused regions return the same values on
your firmware encrypted drive that they would on an ordinary drive it
would further lower the detection threshold.

Of course, all of this depends very much upon your threat model, too.
I’m assuming a rather hostile environment in which the physical device
itself has been compromised and is available for a leisurely study.
Fortunately, if this came out of a PC class machine I at least have a
good idea of what I expect to “see” in the MBR so it will simplify my
differential cryptanalysis attacks (for example). In that type of
hostile environment I want a biometric device with feedback capabilities
(e.g., a fingerprint reader that checks for stress levels - galvanic
response, heart rate, blood pressure).

I’m assuming that these are standard options for this disk drive - e.g.,
standard model number so there’s no way to determine (externally) that
it supports encryption and it has some interface mechanism for a
biometric key system? This sounds wonderful - I want a 120GB one for my
laptop. :slight_smile:

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the next OSR File Systems class in Los
Angeles, CA October 24-27, 2005.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Wednesday, September 14, 2005 9:09 AM
To: ntdev redirect
Subject: Re:[ntdev] Full disk encryption … suggest better encryption
method …

The best way to do full disc encryption is to have the disc firmware do
the
deed. This way, everything on the disc is encrypted, from MBR to
pagefile to
MFT$, and totally inaccessible unless the disc is unlocked by presenting
the
proper credentials; e.g. password. FDE will not even allow you to access
the
disc media unless you totally disassemble the disc and move the media to

another carrier and head assembly.


The personal opinion of
Gary G. Little

“Alex Dirk” wrote in message news:xxxxx@ntdev…
Hi all

We are building a full disk encryption ( including MBR ) most of the
things
are done . Now we have to make a installer for the system . We plan
that
the encryption system will encrypt the drive in the backend and let the
user
to continue work .

So we have a problem … If there is a sudden power surge the user will
end
up with a half encrypted disk . We plan to over come this by keeping a
scratch space ( all data being encrypted is first stored here to prevent

data corruption ) and a counter of the last Logical Block Address (LBA)
encrypted this way the pre boot system and the post boot driver will
read
the disk accordingly ( enc / dec on the fly accordingly ) and on next
start
the encryption installer will continue .

But the problem with this method is that the scratch space is being kept
on
the MBR and the size is 8 Kb ( right now ) so this means we will write
this
space when we encrypt every 8k of data and the lba is increased
accordingly
. But it leads to 128 writes to this space for encrypting 1 MB of data
and
similarly we end up with 10485760 writes for encrypting 80 GB disk . I
think
the number is quite big and if multiplied with disk latency it’ll slow
down
the encryption and also these many writes might corrupt the disk sector
.

So i would like to ask you experts is there a better way of doing this
which
is faster and better .

Thanking you all in advace …

Alex Dirk


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

xxxxx@lists.osr.com wrote on 09/14/2005 09:15:45 AM:

I would actually suggest that rather than use a password based
encryption scheme, a physical token (smart card, biometric device) plus
password would be stronger.

This is certainly feasible. :wink:

The risk with passwords is that they can be compromised. By using two
points of identification (something you have - like a fingerprint,
something you know - like a password).

Another interesting point here is that you don’t want to necessarily
disclose that the media is itself encrypted, so you don’t want the disk
drive to be specially identified. In that way, someone analyzing it
will merely see a “pile of garbage”. I haven’t done detailed analysis
of disk drives but I know that there are often regions of the drive that
are unused; provided that those unused regions return the same values on
your firmware encrypted drive that they would on an ordinary drive it
would further lower the detection threshold.

There’s no secret sauce here, just industry standard algorithms that have
stood up quite well so far. If you can crypto-analyze the industry
standards in use, you can do that with the drive. Though you have to
persuade the drive to give you the data off the platters in the first
place, and the way it comes out of the box, it won’t. Spin-stands and such
aren’t much use any more, as the tracks are so narrow and the bits so close
together, not to mention the black magic inherent in the various flavors of
PRML, anyway, that you pretty much have to have the original heads and
nonvolatile adaptives to read the media reliably.

Of course, all of this depends very much upon your threat model, too.
I’m assuming a rather hostile environment in which the physical device
itself has been compromised and is available for a leisurely study.
Fortunately, if this came out of a PC class machine I at least have a
good idea of what I expect to “see” in the MBR so it will simplify my
differential cryptanalysis attacks (for example). In that type of
hostile environment I want a biometric device with feedback capabilities
(e.g., a fingerprint reader that checks for stress levels - galvanic
response, heart rate, blood pressure).

As I said, if you have enough horsepower to cryptanalyze some very robust
industry standard algorithms, you can probably figure out the data from the
drive. But first you have to get the data off the platters, and that’s no
simple task. I do suspect that with enough budget, like those agencies
that don’t admit their existence, funded through $5000 hammers, you could
do this. Aside from that, it’s a pretty robust data hiding repository.

I’m assuming that these are standard options for this disk drive - e.g.,
standard model number so there’s no way to determine (externally) that
it supports encryption and it has some interface mechanism for a
biometric key system? This sounds wonderful - I want a 120GB one for my
laptop. :slight_smile:

Umm, no, if you want to do biometrics, you are going to have to trust the
host to provide whatever biometric attestation you choose to use. But the
capability is there to validate the biometric data inside the drive, as
part of your decision to allow data off the drive, if you choose to arrange
things that way.

Sorry for the blatant advertising, but you asked… :slight_smile: I don’t know of
any release dates yet, but take a look at http://www.seagate.com, there is
some preliminary info on this thing there.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

Tony,

I’m not sure not sure of the released capacity, but it has a side benefit of
providing an optional Smartcard interface with LOTS of dCards, once I get
the IFD through WHQL – tough to do when the first thing IfdTest asks you to
do is eject and insert a card. :slight_smile:

As to unused space, given that the entire disc is encrypted, which would you
prefer? Tapioca with specific lumps of encrypted globs, or perhaps Cream of
Wheat where everything is a lovely bland texture with no lumps. With the
firmware doing encryption, any write access is going to write encrypted
data. Over a period of time you will end up with Cream of Wheat from an
outside view, or you could force a task that “touches” every sector to
ensure everything looks like CoW. I’m not sure, but I do believe an
encrypted sector of FF’s or 00’s will appear the same as an encrypted sector
of “War and Peace” or “Bambi Vs Godzilla.avi”.

And like Phil said … the OP asked for a better encryption method!!!


The personal opinion of
Gary G. Little

“Tony Mason” wrote in message news:xxxxx@ntdev…
I would actually suggest that rather than use a password based
encryption scheme, a physical token (smart card, biometric device) plus
password would be stronger.

The risk with passwords is that they can be compromised. By using two
points of identification (something you have - like a fingerprint,
something you know - like a password).

Another interesting point here is that you don’t want to necessarily
disclose that the media is itself encrypted, so you don’t want the disk
drive to be specially identified. In that way, someone analyzing it
will merely see a “pile of garbage”. I haven’t done detailed analysis
of disk drives but I know that there are often regions of the drive that
are unused; provided that those unused regions return the same values on
your firmware encrypted drive that they would on an ordinary drive it
would further lower the detection threshold.

Of course, all of this depends very much upon your threat model, too.
I’m assuming a rather hostile environment in which the physical device
itself has been compromised and is available for a leisurely study.
Fortunately, if this came out of a PC class machine I at least have a
good idea of what I expect to “see” in the MBR so it will simplify my
differential cryptanalysis attacks (for example). In that type of
hostile environment I want a biometric device with feedback capabilities
(e.g., a fingerprint reader that checks for stress levels - galvanic
response, heart rate, blood pressure).

I’m assuming that these are standard options for this disk drive - e.g.,
standard model number so there’s no way to determine (externally) that
it supports encryption and it has some interface mechanism for a
biometric key system? This sounds wonderful - I want a 120GB one for my
laptop. :slight_smile:

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the next OSR File Systems class in Los
Angeles, CA October 24-27, 2005.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Wednesday, September 14, 2005 9:09 AM
To: ntdev redirect
Subject: Re:[ntdev] Full disk encryption … suggest better encryption
method …

The best way to do full disc encryption is to have the disc firmware do
the
deed. This way, everything on the disc is encrypted, from MBR to
pagefile to
MFT$, and totally inaccessible unless the disc is unlocked by presenting
the
proper credentials; e.g. password. FDE will not even allow you to access
the
disc media unless you totally disassemble the disc and move the media to

another carrier and head assembly.


The personal opinion of
Gary G. Little

“Alex Dirk” wrote in message news:xxxxx@ntdev…
Hi all

We are building a full disk encryption ( including MBR ) most of the
things
are done . Now we have to make a installer for the system . We plan
that
the encryption system will encrypt the drive in the backend and let the
user
to continue work .

So we have a problem … If there is a sudden power surge the user will
end
up with a half encrypted disk . We plan to over come this by keeping a
scratch space ( all data being encrypted is first stored here to prevent

data corruption ) and a counter of the last Logical Block Address (LBA)
encrypted this way the pre boot system and the post boot driver will
read
the disk accordingly ( enc / dec on the fly accordingly ) and on next
start
the encryption installer will continue .

But the problem with this method is that the scratch space is being kept
on
the MBR and the size is 8 Kb ( right now ) so this means we will write
this
space when we encrypt every 8k of data and the lba is increased
accordingly
. But it leads to 128 writes to this space for encrypting 1 MB of data
and
similarly we end up with 10485760 writes for encrypting 80 GB disk . I
think
the number is quite big and if multiplied with disk latency it’ll slow
down
the encryption and also these many writes might corrupt the disk sector
.

So i would like to ask you experts is there a better way of doing this
which
is faster and better .

Thanking you all in advace …

Alex Dirk


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Philip D Barila[SMTP:xxxxx@seagate.com]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, September 14, 2005 6:02 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Full disk encryption … suggest better encryption method …

There’s no secret sauce here, just industry standard algorithms that have
stood up quite well so far. If you can crypto-analyze the industry
standards in use, you can do that with the drive.

Good encryption algorithm should be resistant even to known plain text attack so there shouldn’t be a problem. What can be more susceptible are encryption keys; it depends on the way how firmware obtains them. I asked this question several times when Gary advertised these drives here and never got the answer (so I have to expect security through obscurity). So again: are keys stored somewhere on drive or firmware or are they generated accroding to password and if so, how they’re verified? The brute force attack against industry standard algorithm with long enough key should be impossible even for three letters agencies but finding the key some other way can be much easier.

Well, maybe better question would be how will Seagate solve inevitable support calls from desperate users who forgot their passwords? :wink:

Other interesting question is if used keys and all footprint which could be used for their verification can be destroyed permanetly when user decides to get rid of used drive. Currently I guess the only safe way is to break the drive with a big hammer which might not be necessary with encrypted one.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Smartcards cannot, except theoretically, be forced to yield their embedded
keys. I don’t know if the new drives will wipe the password after some
number of wrong tries. I also don’t know if the smartcard can export the
keys for recovery. It would be possible to have the smartcards contain a
RSA key that is used to encrypt the symmetric key and only Seagate has the
other key that can extract that information in their data recovery center.

I know it can be done right. Whether that ‘right’ is most secure or must
customer friendly, only specific details on the hardware, software and
firmware would provide us that information.

“Michal Vodicka” wrote in message
news:xxxxx@ntdev…
> ----------
> From:
> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
> on behalf of Philip D Barila[SMTP:xxxxx@seagate.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Wednesday, September 14, 2005 6:02 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Full disk encryption … suggest better encryption
> method …
>
> There’s no secret sauce here, just industry standard algorithms that have
> stood up quite well so far. If you can crypto-analyze the industry
> standards in use, you can do that with the drive.
>
Good encryption algorithm should be resistant even to known plain text
attack so there shouldn’t be a problem. What can be more susceptible are
encryption keys; it depends on the way how firmware obtains them. I asked
this question several times when Gary advertised these drives here and never
got the answer (so I have to expect security through obscurity). So again:
are keys stored somewhere on drive or firmware or are they generated
accroding to password and if so, how they’re verified? The brute force
attack against industry standard algorithm with long enough key should be
impossible even for three letters agencies but finding the key some other
way can be much easier.

Well, maybe better question would be how will Seagate solve inevitable
support calls from desperate users who forgot their passwords? :wink:

Other interesting question is if used keys and all footprint which could be
used for their verification can be destroyed permanetly when user decides to
get rid of used drive. Currently I guess the only safe way is to break the
drive with a big hammer which might not be necessary with encrypted one.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

well alex Dirk,

if you have an encrypted MBR how do you boot?

amitrajit

I’d never even envisioned storing a password directly on the drive -
such a scheme seems to me to be fundamentally flawed and likely the
focus of direct attack. Hence my comment about using smart cards or
biometrics or some other personal characteristic plus a password to
retrieve the (external to the drive) password.

It would require some intelligence in the bootstrap loader that runs
prior to reading the MBR. If *everything* on the drive is encrypted and
it is the responsibility of the boot ROM to get the secret key to the
drive (no doubt through some specialized command, right?) then that
would be the best - you wouldn’t know if this drive came from a PC or a
Macintosh or a Linux box…

As has frequently been observed in the security community, just because
something is encrypted doesn’t mean you can’t figure out something from
the pretty box in which it arrives, or infer from the mere fact that it
DID arrive.

Bottom line: mathematics (encryption) is one small piece of the puzzle.
Usually, the weak link is in fact the user. As usual, the computer
business really would be terrific if it weren’t for the users.

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com

Looking forward to seeing you at the next OSR File Systems class in Los
Angeles, CA October 24-27, 2005.


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Developer
Sent: Thursday, September 15, 2005 1:21 AM
To: ntdev redirect
Subject: Re: [ntdev] Full disk encryption … suggest better encryption
method …

well alex Dirk,

if you have an encrypted MBR how do you boot?

amitrajit

— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 You are currently subscribed
to ntdev as: unknown lmsubst tag argument: ‘’ To unsubscribe send a
blank email to xxxxx@lists.osr.com

>It would require some intelligence in the bootstrap loader that runs prior
to reading the MBR. If >**everything** on the drive is encrypted and it is
the responsibility of the boot ROM to get the secret >key to the drive (no
doubt through some specialized command, right?)

such a command has to be in the disk firmware, or else u gotta flash the
bios to add your own code. Or am I missing something else…

amitrajit

Simple. Your BIOS/EFI works with the drive to authenticate the user. Much the same thing has to be done now to unlock a drive with ATA SECURE PASSWORD set. Once unlocked, the MBR is read and the system booted.


The personal opinion of
Gary G. Little
“Developer” wrote in message news:xxxxx@ntdev…
well alex Dirk,

if you have an encrypted MBR how do you boot?

amitrajit

Sorry Michal, I did not mean to ignore you, and no, we are not doing
security by obscurity. The drive can function as a Smartcard reader with
multiple dCards stored on the drive, and it uses that capability to for
authentication and security. I only wrote the IFD and a bus enumerator and
did not get deep into the ability of the drive to handle authentication. We
do have information on the disks on our web site at www.seagate.com. Look
for a Momentus 5400 FDE.


The personal opinion of
Gary G. Little

“Michal Vodicka” wrote in message
news:xxxxx@ntdev…
> ----------
> From:
> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
> on behalf of Philip D Barila[SMTP:xxxxx@seagate.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Wednesday, September 14, 2005 6:02 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Full disk encryption … suggest better encryption
> method …
>
> There’s no secret sauce here, just industry standard algorithms that have
> stood up quite well so far. If you can crypto-analyze the industry
> standards in use, you can do that with the drive.
>
Good encryption algorithm should be resistant even to known plain text
attack so there shouldn’t be a problem. What can be more susceptible are
encryption keys; it depends on the way how firmware obtains them. I asked
this question several times when Gary advertised these drives here and never
got the answer (so I have to expect security through obscurity). So again:
are keys stored somewhere on drive or firmware or are they generated
accroding to password and if so, how they’re verified? The brute force
attack against industry standard algorithm with long enough key should be
impossible even for three letters agencies but finding the key some other
way can be much easier.

Well, maybe better question would be how will Seagate solve inevitable
support calls from desperate users who forgot their passwords? :wink:

Other interesting question is if used keys and all footprint which could be
used for their verification can be destroyed permanetly when user decides to
get rid of used drive. Currently I guess the only safe way is to break the
drive with a big hammer which might not be necessary with encrypted one.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

>Simple. Your BIOS/EFI works with the drive to authenticate the user. Much
the same thing has to >be done now to unlock a drive with ATA SECURE
PASSWORD set. Once unlocked, the MBR is >read and the system booted.

Yes Gary, that can be done, but Extended Firmware interface is still
relatively new, the product then cannot be supported on older machines.
which still do exist!!

Never say “can’t”.

I’m no BIOS or EFI expert, but most BIOS’s I am aware of have had the ability to use the ATA SECURE PASSWORD command for some time. Since this is an ATA spec’d drive and ATA has a SECURE command set, unlocking the drive with the proper password should not be impossible for most existing systems. The drive’s firmware is handling the unlocking of the drive via the ATA specification at this point.


The personal opinion of
Gary G. Little

“Developer” wrote in message news:xxxxx@ntdev…
>Simple. Your BIOS/EFI works with the drive to authenticate the user. Much the same thing has to >be done now to unlock a drive with ATA SECURE PASSWORD set. Once unlocked, the MBR is >read and the system booted.

Yes Gary, that can be done, but Extended Firmware interface is still relatively new, the product then cannot be supported on older machines. which still do exist!!

xxxxx@lists.osr.com wrote on 09/14/2005 07:04:11 PM:

> ----------
> From: xxxxx@lists.osr.com[SMTP:
xxxxx@lists.osr.com] on behalf of Philip D
Barila[SMTP:xxxxx@seagate.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Wednesday, September 14, 2005 6:02 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Full disk encryption … suggest better
encryption method …
>
> There’s no secret sauce here, just industry standard algorithms that
have
> stood up quite well so far. If you can crypto-analyze the industry
> standards in use, you can do that with the drive.
>
Good encryption algorithm should be resistant even to known plain
text attack so there shouldn’t be a problem. What can be more
susceptible are encryption keys; it depends on the way how firmware
obtains them. I asked this question several times when Gary
advertised these drives here and never got the answer (so I have to
expect security through obscurity). So again: are keys stored
somewhere on drive or firmware or are they generated accroding to
password and if so, how they’re verified? The brute force attack
against industry standard algorithm with long enough key should be
impossible even for three letters agencies but finding the key some
other way can be much easier.

It’s not security by obscurity, there are other reasons for not revealing
things. :slight_smile:

You have to keep something resident, even if it’s just a public key from
the outside agent’s (bio-sensor, external SmartCard) RSA key pair so you
can securely exchange some other material, such as a 3DES key, to unlock
the data. Note I’m not necessarily describing our implementation, it’s
just an example. That’s (almost) how the SSL web session you have with
your bank works.

I don’t believe that there are any passwords in plaintext on the media, for
those deployments that use simple passwords over more robust methods. Keep
in mind that, unless you are using some kind of secure password submission,
which we can support, the PW is transmitted in clear text over the
interface. That’s one of the many weaknesses of today’s implementation of
the ATA SECURITY FEATURE SET.

There are a lot of different ways to do this. Some more robust than
others. Last time I looked, we were giving the users multiple usage
options. I don’t know the current POR, so I’m not going to go any farther
out on that limb.

Well, maybe better question would be how will Seagate solve
inevitable support calls from desperate users who forgot their passwords?
:wink:

Other interesting question is if used keys and all footprint which
could be used for their verification can be destroyed permanetly
when user decides to get rid of used drive. Currently I guess the
only safe way is to break the drive with a big hammer which might
not be necessary with encrypted one.

Yes, that is one beneficial side-effect, cryptographically complete erase
is achieved by forgetting (over-writing with noise, all zeros, known value)
all relevant stored crypto material.

I think we’re probably way off topic here…

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

>Never say “can’t”.
>I’m no BIOS or EFI expert, but most BIOS’s I am aware of have had the
ability to use the ATA >SECURE PASSWORD command for some time. Since this is
an ATA spec’d drive and ATA has a >SECURE command set, unlocking the drive
with the proper password should not be impossible for >most existing
systems. The drive’s firmware is handling the unlocking of the drive via the
ATA >specification at this point.

Yes you are right, but…

The ATA Security Feature Set is hard disk firmware-implemented password
lock. Though performance is not affected by it, it provides less security
than strong encryption. The moment someone outwits the firmware all data are
up for grabs.

The hard disk manufacturers have repeatedly assured the public that they
have not built into their devices backdoors in the form of secret master
keys and are hence themselves unable to unlock a password-secured hard disk.
Even swapping the electronics of the protected hard disk for that of an
unprotected one will not suffice to outwit the protection, because large
sections of the firmware and the password itself are stored on the hard disk
itself and not as one might have expected in flash memory on the
motherboard.

People working for data retrieval companies have nonetheless found ways and
means of circumventing the password. How the trick works is unknown to mew,
what is apparent though is that it is not necessary to open the hard disk to
get at the data.

Thus the sobering upshot to the topic of ATA Security is: As data retrieval
companies have found a way around it, the mechanism must be considered too
unsafe for truly sensitive data. As *only* data retrieval companies have
found a way around it the mechanism can be (ab)used to wreak considerable
havoc.

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of David J. Craig[SMTP:xxxxx@yoshimuni.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, September 15, 2005 5:31 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Full disk encryption … suggest better encryption method …

I know it can be done right. Whether that ‘right’ is most secure or must
customer friendly, only specific details on the hardware, software and
firmware would provide us that information.

That’s why I’m asking for details :slight_smile:

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Philip D Barila[SMTP:xxxxx@seagate.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, September 15, 2005 5:25 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Full disk encryption … suggest better encryption method …

It’s not security by obscurity, there are other reasons for not revealing
things. :slight_smile:

Like intentional backdoors? :wink:

You have to keep something resident, even if it’s just a public key from
the outside agent’s (bio-sensor, external SmartCard) RSA key pair so you
can securely exchange some other material, such as a 3DES key, to unlock
the data. Note I’m not necessarily describing our implementation, it’s
just an example. That’s (almost) how the SSL web session you have with
your bank works.

That’s obvious but any external datastore can be a problem for users who just want to use such drives the same way as current one. I don’t question SmartCard solution; the password one.

I don’t believe that there are any passwords in plaintext on the media, for
those deployments that use simple passwords over more robust methods. Keep
in mind that, unless you are using some kind of secure password submission,
which we can support, the PW is transmitted in clear text over the
interface. That’s one of the many weaknesses of today’s implementation of
the ATA SECURITY FEATURE SET.

I wouldn’t see it as a big problem because I guess I’d notice if somebody changes my hw to capture the interface. For some users it can be important but they’d probably use something better than password.

Yes, that is one beneficial side-effect, cryptographically complete erase
is achieved by forgetting (over-writing with noise, all zeros, known value)
all relevant stored crypto material.

I’d take it as great benefit.

I think we’re probably way off topic here…

I don’t think so. As you can see, a lot of people here and in NTFSD write drivers which encrypt whole drive, its part or a virtual drive. Seagate drives can potentially replace all such software which wouldn’t be a bad thing but only if they’re really secure. False sense of security is worse than no security.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Gary,

if you told before you don't know details, I wouldn't bother you :wink:

I tried to get FDE tech paper, filed Quick Registration Form (grrrr...) and got web error. So the only relevant thing I found was following:


Seagate FDE puts all security keys and cryptographic operations within the drive, separating them from the operating system to provide greater protection against hacking and tampering than traditional software alternatives, which can give thieves backdoor access to encryption keys and are more vulnerable to viruses.

It can be pure marketing newspeak or it can mean encryption keys are stored on the drive. Well, hopefuly tech paper will be available sometimes.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]


From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Gary G. Little[SMTP:glittle@mn.rr.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, September 15, 2005 4:30 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Full disk encryption ... suggest better encryption method ...

Sorry Michal, I did not mean to ignore you, and no, we are not doing
security by obscurity. The drive can function as a Smartcard reader with
multiple dCards stored on the drive, and it uses that capability to for
authentication and security. I only wrote the IFD and a bus enumerator and
did not get deep into the ability of the drive to handle authentication. We
do have information on the disks on our web site at www.seagate.com. Look
for a Momentus 5400 FDE.

--
The personal opinion of
Gary G. Little

"Michal Vodicka" wrote in message
> news:xxxxx@ntdev...
> > ----------
> > From:
> > xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
> > on behalf of Philip D Barila[SMTP:xxxxx@seagate.com]
> > Reply To: Windows System Software Devs Interest List
> > Sent: Wednesday, September 14, 2005 6:02 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] Full disk encryption ... suggest better encryption
> > method ...
> >
> > There's no secret sauce here, just industry standard algorithms that have
> > stood up quite well so far. If you can crypto-analyze the industry
> > standards in use, you can do that with the drive.
> >
> Good encryption algorithm should be resistant even to known plain text
> attack so there shouldn't be a problem. What can be more susceptible are
> encryption keys; it depends on the way how firmware obtains them. I asked
> this question several times when Gary advertised these drives here and never
> got the answer (so I have to expect security through obscurity). So again:
> are keys stored somewhere on drive or firmware or are they generated
> accroding to password and if so, how they're verified? The brute force
> attack against industry standard algorithm with long enough key should be
> impossible even for three letters agencies but finding the key some other
> way can be much easier.
>
> Well, maybe better question would be how will Seagate solve inevitable
> support calls from desperate users who forgot their passwords? :wink:
>
> Other interesting question is if used keys and all footprint which could be
> used for their verification can be destroyed permanetly when user decides to
> get rid of used drive. Currently I guess the only safe way is to break the
> drive with a big hammer which might not be necessary with encrypted one.
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
>
>
>
> ---
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@upek.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com>
>