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

OSR_Community_User · September 15, 2005, 2:49pm

xxxxx@lists.osr.com wrote on 09/15/2005 12:06:03 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: 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.
>
Like intentional backdoors?

To the best of my knowledge, Seagate isn’t putting any in. There has been
discussion of possible solutions to the problem of lost credentials. Don’t
know the POR at this point. I haven’t worked on it for a year, so what I
remember is pretty stale.

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

The password solution is just a more robust form of the existing ATA
SECURITY Feature set, wherein the data on the platters is encrypted. There
are also more interesting capabilities in development. AFAIK, there is no
way to regenerate the PW **or the key material** from data on the media,
only verify whether the PW that is offered is correct.

> 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, you would probably notice a bus analyzer.

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

I enthusiastically agree with that!

Phil

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

Michal_Vodicka-2 · September 15, 2005, 3:15pm

> ----------

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 8:54 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Full disk encryption … suggest better encryption method …

To the best of my knowledge, Seagate isn’t putting any in. There has been
discussion of possible solutions to the problem of lost credentials.

It should be easy to find out the result. If there is a big warning for users there is no way to recover data once password is lost, the solution can be really secure.

Don’t know the POR at this point. I haven’t worked on it for a year, so what I
remember is pretty stale.

What POR means? Never saw this acronym and Google doesn’t help.

The password solution is just a more robust form of the existing ATA
SECURITY Feature set, wherein the data on the platters is encrypted. There
are also more interesting capabilities in development. AFAIK, there is no
way to regenerate the PW **or the key material** from data on the media,
only verify whether the PW that is offered is correct.

Thanks, one of things I wanted to know. Hopefully verification is complex enough to make brute force attack impossible.

Yes, you would probably notice a bus analyzer.

Maybe

Best regards,

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

OSR_Community_User · September 15, 2005, 3:30pm

xxxxx@lists.osr.com wrote on 09/15/2005 01:14:42 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: Thursday, September 15, 2005 8:54 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Full disk encryption … suggest better
encryption method …
>
> To the best of my knowledge, Seagate isn’t putting any in. There has
been
> discussion of possible solutions to the problem of lost credentials.
>
It should be easy to find out the result. If there is a big warning
for users there is no way to recover data once password is lost, the
solution can be really secure.

> Don’t know the POR at this point. I haven’t worked on it for a
year, so what I
> remember is pretty stale.
>
What POR means? Never saw this acronym and Google doesn’t help.

Plan Of Record. The roadmap, if you will.

> The password solution is just a more robust form of the existing ATA
> SECURITY Feature set, wherein the data on the platters is encrypted.
There
> are also more interesting capabilities in development. AFAIK, there is
no
> way to regenerate the PW **or the key material** from data on the
media,
> only verify whether the PW that is offered is correct.
>
Thanks, one of things I wanted to know. Hopefully verification is
complex enough to make brute force attack impossible.

Standard cyrpto algorithms.

Phil

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

OSR_Community_User · September 16, 2005, 3:05am

Hi all

Thanks for your suggestions . I was also thinking of using contigous spaces
in the Hard disk rather than a 4k space in the first cylinder this might
decrease the number of writes but i still dont feel its the correct
solution.

About the password - Our system dosnt use passwords It uses
Smartcards/Tokens to store the key . The drivers to access these keys have
been incoperated in the Extended MBR .

Still looking for a better recovery procedure .

Alex dirk

amitr0-2 · September 16, 2005, 3:33am

hi Alex,

About the password - Our system dosnt use passwords It uses
Smartcards/Tokens to store the >key . The drivers to access these keys have
been incoperated in the Extended MBR .

If you are storing the tokens in the smart card and the BIOS level driver of
the device is in the extended MBR, I find two things intreaguing…

You have wirtten your own MBR code, which is more than onw sector long,
you have two options, either to store the extended MBR in a file and read it
into memory, or use the contiguous sectors to store it. If you do the second
option, antivirus programs might not like the idea very much and detect such
code as *malicious*, am i correct?
Heck, the machine needs to jump start from 7c00!! So the MBR code, if
encrypted, must be decrypted before it is copied to that location, so are
you really encrypting the MBR also? Yes, the data poriton of the MBR can be
encypted (where it strores the info about the partition tables) but then it
is not very easy either to load the partially encrypterd sector to memory
and decrypt it on the fly.

Amitrajit

amitr0-2 · September 16, 2005, 4:46am

Hello Philip Barila,

The password solution is just a more robust form of the existing ATA
SECURITY Feature set, wherein the data on the platters is encrypted. There
are also more interesting capabilities in development. AFAIK, there is no
way to regenerate the PW **or the key material** from data on the media,
only verify whether the PW that is offered is correct.

imagine this…

One fine day the screen of your notebook remains blank

disk boot failure, insert system disk and press Enter.

No unusual noises can be heard and the disk does register with the BIOS!

DOS bootable floppy/CD boots but cannot access the hard disk. Some diagnosis
tells you:
“Device is password protected and cannot be tested.” The hard disk is
password protected. And who did that? And what is more important still: What
is the password and how do you remove it?

Notebooks have been offering the password function for quite some time now,
as have a number of desktop PCs.

But what if an unauthorized party were to lock a hard disk with a password?
And what if that party was a virus? Then a set of simple tools won’t suffice
to give you access to your data. The options would be to throw the disk away

or place it in the hands of someone who specializes in retrieving data. He
or she will in all probability be able to remove the password protection the
costs would be sky high.

Should such a calamity happen in a small company with a record of not
looking after its data and in which back-ups were a weekly event, the data
loss would be tremendous or at least the downtime until a specialist had
unlocked the disk again would present massive problems. Then again, the
computer administrator of a major company would surely break out into quite
some sweat too if a worm succeeded in “locking” several hundred hard disks
at the same time. We are hence dealing here with a full-blown security
loophole affects all computers with ATA hard disks regardless of the
operating system.

Fortunately, to date no virtual pest is known that can set hard disk
passwords. There are indications, however, that one might already exist.
Some tie back I remember reading in a forum someone who said that his hard
disk had suddenly been locked with a password unknown to him. High time then
to look in detail at the mechanism which for some years now has been
implemented in almost all ATA hard disks (IDE and Serial ATA). In many
computers this mechanism rests unused making it possible, to use - or abuse

it with one’s own software.

Gary_Little · September 16, 2005, 9:49am

As I understand it, it takes a password to change the password, unless this is the initial setting of the password. Which brings up two points:

If you don’t intend to use the password then why do have the drive? Ok … some bean counter found a REALLY good deal on a truckload of stolen drives and now even the janitor has one. There is an issuance process to initialize the drive. It is not just a matter of opening a box, shoving the drive into a slot, and then going into the bios and setting the password the first time. There is an authentication process, and yes it requires certificates and keys for authentication. That truckload of drives was “issued” (for lack of a better term) for Framis and Widgets Inc. The janitor at Bogus Inc can’t use the drive because he doesn’t have the keys that Framis and Widgets have, unless F & W was stupid enough to broadcast them in a clear email to all of their centers getting the drives. See 2 below.
Security is only as good as individual discipline associated with that security; e.g. the genius that uses 12345678 or the schmuck that puts their password on a post-it on the monitor.
The ATA SECURE PASSWORD, tain’t the best, but it is 32 bytes in length and can effectively parry light to medium attacks. Given time, money and power, there really isn’t much of anything that can withstand a long duration heavy duty attack. Besides, as I understand it, most security is breached via social engineering and not hardline cracking of an encrypted password. We have more to fear from the president of a company using his birthday or his Social Security Number as a password than a bad guy hooking an FDE up to mainframe powered cracking software.

–
The personal opinion of
Gary G. Little
“Developer” wrote in message news:xxxxx@ntdev…
Hello Philip Barila,

>The password solution is just a more robust form of the existing ATA
>SECURITY Feature set, wherein the data on the platters is encrypted. There
>are also more interesting capabilities in development. AFAIK, there is no
>way to regenerate the PW or the key material from data on the media,
>only verify whether the PW that is offered is correct.

imagine this…

One fine day the screen of your notebook remains blank
- disk boot failure, insert system disk and press Enter.

No unusual noises can be heard and the disk does register with the BIOS!

DOS bootable floppy/CD boots but cannot access the hard disk. Some diagnosis tells you:
“Device is password protected and cannot be tested.” The hard disk is password protected. And who did that? And what is more important still: What is the password and how do you remove it?

Notebooks have been offering the password function for quite some time now, as have a number of desktop PCs.

But what if an unauthorized party were to lock a hard disk with a password? And what if that party was a virus? Then a set of simple tools won’t suffice to give you access to your data. The options would be to throw the disk away - or place it in the hands of someone who specializes in retrieving data. He or she will in all probability be able to remove the password protection the costs would be sky high.

Should such a calamity happen in a small company with a record of not looking after its data and in which back-ups were a weekly event, the data loss would be tremendous or at least the downtime until a specialist had unlocked the disk again would present massive problems. Then again, the computer administrator of a major company would surely break out into quite some sweat too if a worm succeeded in “locking” several hundred hard disks at the same time. We are hence dealing here with a full-blown security loophole affects all computers with ATA hard disks regardless of the operating system.

Fortunately, to date no virtual pest is known that can set hard disk passwords. There are indications, however, that one might already exist. Some tie back I remember reading in a forum someone who said that his hard disk had suddenly been locked with a password unknown to him. High time then to look in detail at the mechanism which for some years now has been implemented in almost all ATA hard disks (IDE and Serial ATA). In many computers this mechanism rests unused making it possible, to use - or abuse - it with one’s own software.

OSR_Community_User · September 16, 2005, 11:20am

xxxxx@lists.osr.com wrote on 09/16/2005 02:46:15 AM:

imagine this…

[long description of a known issue with the ATA SECURITY Feature Set,
dependent on the user not enabling a PW, and the BIOS not locking the
security mechanism, snipped]

The ATA SECURITY FREEZE LOCK command exists exactly to prevent this. The
BIOS is the most appropriate place to issue it, and at one time, a lot of
BIOSen did that. Not sure what happened that so many dropped it, but any
BIOS shipping today that doesn’t issue a SECURITY FREEZE LOCK command is
broken, and should be fixed or avoided. It’s a complete no-op if the
thing’s already locked or security isn’t supported or enabled on a device,
so there’s no reason not to.

Phil

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