[FDE] how FDE is implemented at system layer
Fran Baena
i'm a newbie in FDE and i'm interested in how all this protecting
methods are implemented in OS level. I mean, the cryptographic
mechanism is more or less clear, but how does it interact with the
file system layer? Does the OS vendor provide an API to manage all the
I/O operations that implies disk encryption/decryption?
Thanks for your help
Fran
_______________________________________________
FDE mailing list
F...@www.xml-dev.com
http://www.xml-dev.com/mailman/listinfo/fde
Garrett M. Groff
disk sectors on-demand.
G
Dmitry Obukhov
Typically the software FDE solution should intercept BIOS interrupt (I'm not
Windows programmer, but back in old DOS times it was int 13h and 76h) and
individually encrypt/decrypt each 512 bytes sector. It is very CPU-consuming
process. Up to 48% of the CPU power can be spent on encryption. The HW FDE
(SED, self-encrypting drives) is much more efficient, and no changes in OS
is required.
Dmitry
sharat...@wipro.com
I have a request for a solution to encrypt disks on HPUX servers.
Warm Regards
SJ
-----Original Message-----
From: fde-b...@www.xml-dev.com [mailto:fde-b...@www.xml-dev.com]
On Behalf Of Garrett M. Groff
G
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
Daniel Feenberg
On Thu, 9 Apr 2009, Dmitry Obukhov wrote:
> Fran,
>
> Typically the software FDE solution should intercept BIOS interrupt (I'm not
> Windows programmer, but back in old DOS times it was int 13h and 76h) and
> individually encrypt/decrypt each 512 bytes sector. It is very CPU-consuming
> process. Up to 48% of the CPU power can be spent on encryption. The HW FDE
> (SED, self-encrypting drives) is much more efficient, and no changes in OS
> is required.
I would love to have some FDE hardware drives, but the hour I spent at the
Seagate website didn't tell me how the key was established. Can I just buy
such a drive and install it in a white-box computer and have it work?
WIthout any evidence on the website to the contrary, I just assumed the
drive came with a windows driver for setting the key, and that a special
motherboard with a tpm circuit was required for the driver to work.
If that isn't the case, it makes the drives much more attractive. Are
there instructions somewhere on the net? This would be of interest to us
for both Windows and Linux.
Daniel Feenberg
DPW 401
solution at the application layer and secure network path to the servers,
don't you?
> -----Original Message-----
> From: sharath.jeppu-at-wipro.com |FDE081212|
> Sent: Tuesday, April 07, 2009 10:19 AM
>
> Are there FDE solutions for Servers as well?
> I have a request for a solution to encrypt disks on HPUX servers.
Lance Spitzner
> (I'm not
> Windows programmer, but back in old DOS times it was int 13h and
> 76h) and
> individually encrypt/decrypt each 512 bytes sector. It is very CPU-
> consuming
> process. Up to 48% of the CPU power can be spent on encryption.
Really? I have PGP on my Mac and absolutely love it. In addition, I
have not seen any noticeable latency or performance impact, and I
hammer my system. Bruce Schneier also brings up a good
perspective[1], you may want to consider leaving your FDE to the
encryption experts (such as PGP) as opposed to hard drive
manufacturers. Don't get me wrong, I'm all for HD FDE as it can
simplifies things at the enterprise level, but lets not just start
throwing around numbers and poo pooing the software side.
lance
[1] http://www.schneier.com/blog/archives/2009/02/hard_drive_encr.html
Fran Baena
> Windows programmer, but back in old DOS times it was int 13h and 76h) and
> individually encrypt/decrypt each 512 bytes sector. It is very CPU-consuming
> process. Up to 48% of the CPU power can be spent on encryption. The HW FDE
> (SED, self-encrypting drives) is much more efficient, and no changes in OS
> is required.
>
> Dmitry
Hi Dmitry,
when you talk about BIOS interruptions, are you talking about I/O
interruptions (read/write from/to disk)? what is the difference
between monitoring BIOS and monitoring Windows I/O layer with a filter
driver?
Best Regards.
Simson Garfinkel
I would love to have some FDE hardware drives, but the hour I spent at the
Seagate website didn't tell me how the key was established. Can I just buy
such a drive and install it in a white-box computer and have it work?
WIthout any evidence on the website to the contrary, I just assumed the
drive came with a windows driver for setting the key, and that a special
motherboard with a tpm circuit was required for the driver to work.
If that isn't the case, it makes the drives much more attractive. Are
there instructions somewhere on the net? This would be of interest to us
for both Windows and Linux.
Dmitry Obukhov
Being engineering manager, I can't announce any dates for the products.
However, if you will have a chance to visit RSA conference in San Francisco,
you will see TCG Opal drives from many vendors. Please stop by at Wave
Systems booth; we (Samsung) will have good informative demo of our SED
product and I will be glad to answer your questions.
Regarding our product, you have to configure the drive with special software
compatible with TCG specification. The configured drive doesn't need any OS
driver or motherboard modifications to work. Basically, in enterprise
environment the configuration should be done by IT department. They have to
create Admin account for IT (and keep it for a case of recovery) and user
account(s) for end user(s). Then IT should install the drive in the system,
optionally install OS, and give it to user. In case of personal computer the
user plays the role of IT and doing the same, but stays in charge for
everything. There is no restrictions to OS or requirements for the software
to run, after pre-boot authentication it behaves as any other drive.
Dmitry Obukhov
It is not true; file base encryption is very resource consuming. To spend
your server CPU load for encryption is the last thing you want to do.
Unless you have endless budget, of course.
For the servers I can recommend to look on TCG Enterprise specification.
Seagate announced their TCG Enterprise product, you may want to contact them
directly.
WBR,
Dmitry
-----Original Message-----
From: fde-b...@www.xml-dev.com [mailto:fde-b...@www.xml-dev.com] On
Behalf Of DPW 401
Sent: Saturday, April 11, 2009 7:51 AM
To: f...@www.xml-dev.com
Subject: Re: [FDE] how FDE is implemented at system layer
Dmitry Obukhov
I'm not windows software engineer, I left to firmware when Windows 3.1 was
the latest OS :)
You can look on the open source TrueCrypt to find out how it is implemented.
Dmitry
-----Original Message-----
From: fde-b...@www.xml-dev.com [mailto:fde-b...@www.xml-dev.com] On
Behalf Of Fran Baena
Sent: Monday, April 13, 2009 12:51 AM
To: f...@www.xml-dev.com
Subject: Re: [FDE] how FDE is implemented at system layer
Dmitry Obukhov
From: fde-b...@www.xml-dev.com [mailto:fde-b...@www.xml-dev.com] On Behalf Of Simson Garfinkel
Sent: Sunday, April 12, 2009 7:49 AM
Scott S
was pointed out if the hard drives are in a secure location, the need for
security diminishes. However, in many situations, that is not the case.
Also failing drives can be hotwapped out at any time, or drives need to be
disposed off due to upgrade. These types of drives are still carrying open
data that require protection.
Scott
Scott S
The use of Seagate FDE drives is very simple:
First of all, there is no special driver that needs to be installed at
any level to use an FDE drive. An FDE drive operates like a normal drive
from the getgo. It is just that it is always encrypting the data that
gets saved on the drive, totally transparent to you or to the OS. And it
is only when you set the password on the drive that you are taking advange
of encryption security. And you don't need anything to do that either (more
on this later).
Second, there is no key generation you need to worry about. The
drive doesn't use your password to generate a key. The
drive has a secret encryption key unrelated to your password, and the
drive is the only one that has access to it.
Third, when you set the password and authenticate to the drive at the
start of the computer, in essence, what you are doing is providing
permission to the drive to use its secret encryption key to read and
write the data. Once this happens, the FDE drive is a normal drive to the
OS and applications.
Four, so how do you set the password on the FDE drive? There are two
ways. The simple, cheap, and quick way is via the drive lock in the BIOS
(not to be confused with the system BIOS password). For this you don't
need anything else, just go into the BIOS and look for it under the hard
drive or SATA section to set it. Once set, the password gets save on the
drive so that if you were to connect the drive to a diffent computer, it
will still ask for the password. The drive lock password is ideal for
single users and don't need anything fancy. The second way is via a 3rd
party client software that you will have to purchase. Besides being more
user friendly, the client software provide enhance features like password
synchronization with OS, remote password reset, and multiple account
access. For a company these features are must.
One last thing, it was stated at the beginning that "there is no key
generation". This doens't mean that the key can not be generated. It can
be, and it is a feature. A generation of a new key happens when you want
to do a cryptographical erase of the entire drive (also called
secure wipe). However, you will still not know what the new keys is.
Scott
Tim Hollebeek
> > It is very CPU-consuming
> > process. Up to 48% of the CPU power can be spent on encryption.
>
> Really?
Maybe on archaic hardware. The numbers we've seen are closer to 3%.
And of course, the marginal cost of additional CPU usage is zero unless
your CPU meter is pegged. "Up to" can be very misleading. Up to 100%
of the information in this email might be wrong. That doesn't mean it is.
Encryption is not a CPU intensive operation on modern machines.
I run our FDE product on my machines, and I often forget it's there.
The overhead is not noticeable.
-Tim
Jan Meijer
>> Typically the software FDE solution should intercept BIOS interrupt
>> (I'm not
>> Windows programmer, but back in old DOS times it was int 13h and
>> 76h) and
>> individually encrypt/decrypt each 512 bytes sector. It is very CPU-
>> consuming
>> process. Up to 48% of the CPU power can be spent on encryption.
>
> Really? I have PGP on my Mac and absolutely love it. In addition, I
> have not seen any noticeable latency or performance impact, and I
> hammer my system. Bruce Schneier also brings up a good
Like TrueCrypt, which also is without noticeable latency or performance
impact. Or the Linux file system encryption stuff.
> perspective[1], you may want to consider leaving your FDE to the
> encryption experts (such as PGP) as opposed to hard drive
> manufacturers. Don't get me wrong, I'm all for HD FDE as it can
> simplifies things at the enterprise level, but lets not just start
> throwing around numbers and poo pooing the software side.
Last time I checked on HD FDE, from what sparse documentation I could find
I concluded that it all boils down to your bootup password. From an
enterprise point of view this is -I'm guessing- a bit unpractical as it
hinders data recovery in case of password (ehr, carbon-based memory) loss.
We decided to not go for HD FDE, even though a number of our Lenovo
laptops supports it: if a laptop breaks you *must* have one again that
supports it (not all do), and if a disk breaks you *must* have a spare
disk that supports it. In our case with a rather mixed environment, this
is not practical.
But wasn't the question where to find information on this? I'd first and
foremost dive into the linux partition encryption, and into the FreeBSD
disk encryption (GBDE). Should be well documented and with readable
code..
--
Jan
Tim Hollebeek
> when you talk about BIOS interruptions, are you talking about I/O
> interruptions (read/write from/to disk)? what is the difference
> between monitoring BIOS and monitoring Windows I/O layer with a filter
> driver?
The Windows I/O layer doesn't initialize until fairly late in the Windows
loader. During much of the initial boot sequence, Windows switches to
16 bit mode and uses BIOS interrupts for disk I/O. So if you want to
encrypt the entire disk, including the boot loaders, and you want to
provide pre-boot authentication (which you should, because otherwise it
isn't secure), you need to handle both BIOS interrupts and Windows I/O.
What people want is security.
What they buy is encryption.
What they pay is as little as possible (both $ and user effort).
What they get it is no security.
There are Fortune 500 companies that encrypt all their laptops WITHOUT
pre-boot encryption. There are hardware encryption products that write
the key to the drive in plaintext. Just because a product uses FIPS
approved cryptography doesn't mean it is secure.
If you want real security, buy it from people who actually care about
security, and listen to their recommendations about best practices.
Tim Hollebeek
BitArmor Systems
http://www.bitarmor.com
Simson Garfinkel
I think that it is a common misconception that drives which are used
on servers in a secure location do not need FDE. In my research I
have purchased thousands of hard drives on the secondary market and
examined those drives for an indication of the data left on them by
previous users. The most sensitive (and potentially damaging) data
comes from drives that were used in servers, were taken out of
service, and then ended up in my hands.
* In one case, I bought a RAID array. Most of the drives were wiped,
but some were not. It looked like some drives had failed in service
and the wiping wiped the logical RAID containers, not the physical
drives.
* In another case, drives were partially wiped. It looked like the
power failed or the person just got bored.
* In another case, the drives had disk errors. On the other side of
the disk error there was valid data.
* In another case, the company had called for the drives to be wiped,
but the subcontractor "wiped" them by erasing the partition table. The
drives were resold on eBay.
You simply cannot assure that a drive will be physically wiped. If the
drive will not be physically destroyed at the end of its life --- and
it is hard to assure that a drive will be physically destroyed --- the
drive should be encrypted with FDE.
On Apr 14, 2009, at 11:41 AM, Scott S wrote:
> There are Seagate FDE hard drives for server or network storage. But
> as it
> was pointed out if the hard drives are in a secure location, the
> need for
> security diminishes. However, in many situations, that is not the
> case.
> Also failing drives can be hotwapped out at any time, or drives need
> to be
> disposed off due to upgrade. These types of drives are still
> carrying open
> data that require protection.
_______________________________________________
Daniel Feenberg
On Tue, 14 Apr 2009, Scott S wrote:
> Daniel,
>
> The use of Seagate FDE drives is very simple:
>
> First of all, there is no special driver that needs to be installed at
> any level to use an FDE drive. An FDE drive operates like a normal drive
> from the getgo. It is just that it is always encrypting the data that
> gets saved on the drive, totally transparent to you or to the OS. And it
> is only when you set the password on the drive that you are taking advange
> of encryption security. And you don't need anything to do that either (more
> on this later).
You can count on vendors to ignore the best features of their products in
advertising.
>
> Second, there is no key generation you need to worry about. The
> drive doesn't use your password to generate a key. The
> drive has a secret encryption key unrelated to your password, and the
> drive is the only one that has access to it.
>
> Third, when you set the password and authenticate to the drive at the
> start of the computer, in essence, what you are doing is providing
> permission to the drive to use its secret encryption key to read and
> write the data. Once this happens, the FDE drive is a normal drive to the
> OS and applications.
>
> Four, so how do you set the password on the FDE drive? There are two
> ways. The simple, cheap, and quick way is via the drive lock in the BIOS
> (not to be confused with the system BIOS password). For this you don't
> need anything else, just go into the BIOS and look for it under the hard
> drive or SATA section to set it. Once set, the password gets save on the
How do I tell (before purchase) if a motherboard has this BIOS feature?
The boards I buy (mostly Gigabyte) don't seem to support this.
> drive so that if you were to connect the drive to a diffent computer, it
> will still ask for the password. The drive lock password is ideal for
> single users and don't need anything fancy. The second way is via a 3rd
> party client software that you will have to purchase. Besides being more
> user friendly, the client software provide enhance features like password
> synchronization with OS, remote password reset, and multiple account
> access. For a company these features are must.
>
Can you suggest a particular brand? Or is there a keyword I can use for
searching for this software? Any Linux compatible? If a salesdroid is
reading this, I would take your call!
Thank you, and I will certainly be giving this a trial soon.
Daniel Feenberg
feenberg isat nber dotte org
617-588-0343
> One last thing, it was stated at the beginning that "there is no key
> generation". This doens't mean that the key can not be generated. It can
> be, and it is a feature. A generation of a new key happens when you want
> to do a cryptographical erase of the entire drive (also called
> secure wipe). However, you will still not know what the new keys is.
>
> Scott
>
Daniel Feenberg
On Mon, 20 Apr 2009, Simson Garfinkel wrote:
> I would like to amplify what Scott has said below.
>
> I think that it is a common misconception that drives which are used
> on servers in a secure location do not need FDE. In my research I
> have purchased thousands of hard drives on the secondary market and
> examined those drives for an indication of the data left on them by
> previous users. The most sensitive (and potentially damaging) data
> comes from drives that were used in servers, were taken out of
> service, and then ended up in my hands.
>
I am curious - how do you arrange for key entry in a server? Does the
operator enter it from the console on each boot? Doesn't that make "lights
out" operation difficult? I wouldn't like to give up the ability of
machines to reboot unattended. If it is stored somewhere on the computer,
don't you still have the problem that possesion of the hardware implies
access to the data?
Anyway, how often do used drives have cash value greater than the cost
differential of regular and FDE drives? Wouldn't it be more efficient to
just destroy used drives if you can't erase the contents?
Daniel Feenberg
Ali, Saqib
> searching for this software? Any Linux compatible? If a salesdroid is
> reading this, I would take your call!
Check with Winmagic. I saw their demo on a MacBook with Seagate's FDE
drive at RSA. I am pretty sure they support Linux as well, but can't
guarantee.
Garry Mccracken
and software FDE. Drop by the WinMagic booth (#831) and we can explain
how software FDE works. As well we will be demonstrating pre-boot
authentication and enterprise management for Seagate HW FDE drives and
Opal FDE drives.
Garry
-----Original Message-----
From: fde-b...@www.xml-dev.com [mailto:fde-b...@www.xml-dev.com]
On Behalf Of Dmitry Obukhov
Sent: Monday, April 13, 2009 1:12 PM
To: f...@www.xml-dev.com
Subject: Re: [FDE] how FDE is implemented at system layer
Hi Daniel,
Dmitry
-----Original Message-----
From: fde-b...@www.xml-dev.com [mailto:fde-b...@www.xml-dev.com]
On
Behalf Of Daniel Feenberg
Sent: Saturday, April 11, 2009 3:34 PM
To: f...@www.xml-dev.com
Subject: Re: [FDE] how FDE is implemented at system layer
On Thu, 9 Apr 2009, Dmitry Obukhov wrote:
> Fran,
>
> Typically the software FDE solution should intercept BIOS interrupt
> (I'm not Windows programmer, but back in old DOS times it was int 13h
> and 76h) and individually encrypt/decrypt each 512 bytes sector. It is
> very CPU-consuming process. Up to 48% of the CPU power can be spent on
> encryption. The HW FDE (SED, self-encrypting drives) is much more
> efficient, and no changes in OS is required.
I would love to have some FDE hardware drives, but the hour I spent at
Daniel Feenberg
Patrick Cahalan
> You simply cannot assure that a drive will be physically wiped. If
> the drive will not be physically destroyed at the end of its life ---
> and it is hard to assure that a drive will be physically destroyed
> --- the drive should be encrypted with FDE.
While it's true that there are millions of examples of bad data security
policy, that doesn't mean that FDE "makes your problems go away". You
cannot rely on hardware or software to solve your security problems; all
you can do is implement mitigation efforts. Simson didn't precisely say
this in the above paragraph, but there's a lot of absolutes in that one
paragraph and there's hardly ever any absolutes in the real world.
Certainly, you can't have 100% confidence (regardless of your process)
that every drive will be forensically zeroed out. You can't have 100%
confidence that every drive will be shredded. You also can't have 100%
confidence that some beanhead in your data center will use a P-touch to
put the FDE boot password on the exterior of your file server, right
next to the IP address, MAC address, and root password in violation of
your security policy, either.
You should take the mitigation steps that make the most sense in your
organization, given the value of the data that you're trying to protect
(both internally to your organization and externally, because as a
professional you have an ethical if not legal obligation to protect your
customers).
IME, 95% of the time the most efficient solution is *not to store the
sensitive data in the first place*. The remaining 5% of the time, a
combination of software, hardware, and human processes are going to be
required to properly protect your data. FDE has a place in that
equation, but it's just a part of the overall picture.
Simson Garfinkel
I am curious - how do you arrange for key entry in a server? Does the
operator enter it from the console on each boot? Doesn't that make "lights
out" operation difficult? I wouldn't like to give up the ability of
machines to reboot unattended. If it is stored somewhere on the computer,
don't you still have the problem that possesion of the hardware implies
access to the data?
Anyway, how often do used drives have cash value greater than the cost
differential of regular and FDE drives? Wouldn't it be more efficient to
just destroy used drives if you can't erase the contents?
Scott S
Some of the technical details that you asked may be answered in the
presentation that were given Monday at the 2009 RSA conference:
http://www.trustedcomputinggroup.org/solutions/data_protection
Scott
Simson Garfinkel
You are absolutely right that FDE doesn't make your data problems go
away. But your proposed 95% solution of "not storing sensitive data in
the first place" isn't a workable one for most organizations. Yes,
they shouldn't store the whole CCN and CCV2. But how about customer
names? Or email messages? Or Microsoft SQL Server databases of
customers?
Also, in many organizations, it is simply not possible to keep track
of which hard drives have been exposed to confidential information and
which have not.
There are two really big wins for FDE. One is when the drive becomes
separated from the server in which it formerly resided. The second is
for remote kill situations where you know the laptop or desktop is out
there, and you just need to get it a message to erase its key. Yes,
you can't overcome the p-touch password on the server. And I have
bought servers on the secondary market and found its password written
on them. But in every case that I've bought a server, the hard drive
wasn't wiped, and the data wasn't encrypted, and I was able to recover
stuff. FDE would make it much easier to do an instant wipe in those
cases.
Garrett M. Groff
"I am curious - how do you arrange for key entry in a server?"
Transparent operation (such as that afforded by TPMs) are a viable option. Not quite as
secure (cold boot attack or some other direct memory-based attack [eg, firewire]), but the
convenience might be worth it.
----- Original Message -----
From: "Daniel Feenberg" <feen...@nber.org>
To: <f...@www.xml-dev.com>
Sent: Wednesday, April 22, 2009 7:34 AM
Subject: Re: [FDE] how FDE is implemented at system layer
>
>
Patrick Cahalan
> the first place" isn't a workable one for most organizations. Yes, they
> shouldn't store the whole CCN and CCV2. But how about customer names? Or
> email messages? Or Microsoft SQL Server databases of customers?
There's sensitive data, and there's sensitive data. Still, I'll take
being called out for "exaggerating for effect" in good grace.
It's probably more like 65%. Of the remaining 35%, when it comes to
protecting it, you're doing it wrong.
> Also, in many organizations, it is simply not possible to keep track of
> which hard drives have been exposed to confidential information and
> which have not.
This I'll disagree with; or more to the point, I agree this is true,
but this is not a problem that FDE can "solve", and it *is* a critical
problem that needs to be tackled in most organizations, right now. In
fact, from an organizational security standpoint, introducing FDE can
make this problem worse: "Oh, I can carry the customer database home
on my laptop because it's encrypted."
No, you can't take the customer database home because you don't
actually need it. You find it convenient. You don't like the VPN
setup. You don't like to have to plan ahead. You're on a deadline.
Whatever the reason is (and many of them have legitimate
organizational value), the right answer is, "If you need access to
this information that badly, stay late. If you don't like to stay
late, fix your project management so that you can meet your deadlines.
If the SEC audits us and finds out that I let you take that home,
I'll get fired." Enabling this sort of thing should be the very rare
exception, not the rule. Make any executive who wants to do this
justify it by making a business case for it, and make them sign a
policy on the dotted line. If they lose the data, there needs to be
consequences. If you can't enforce this, you've got problems.
While it's certainly true that people in an organization will email
sensitive documents around (leaving them all over a bunch of different
desktops) and it's also true you can mitigate this by encrypting the
drives... encrypting the desktop drives introduces a bunch of other
issues. Who has the boot password? The employee, or the helpdesk?
Do you reset them when a helpdesk person leaves? The employee? Do
you really reset them? No, really? If you go to that trouble, why
can't you just blast the drive, or yank the drive and shred it, which
(from an organizational standpoint) is probably at least as easy if
not easier? If a box crashes due to hardware failure on the
motherboard at EOL, am I *really* going to replace the motherboard
just so I can boot the box and zero the drive? Or am I just going to
chuck the thing in the trash? Wouldn't it make much more sense to
have a trash can sitting in your hardware closet just for hard drives,
and when it's half-full take it down to the e-disposer and shred it?
If you're worried about your email store, forget about encrypting your
desktops (or your exchange server or IMAP server, for that matter)...
are you doing any sort of auditing on your outgoing mail? If I allow
people to email "sensitive data".doc files, what's to stop them from
emailing those docs to your competitor's gmail account? Can you even
catch that?
Your employees surf the web, their machines get hacked, and all the
juicy data on those machines gets delightedly nabbed by actual
criminals, while the box is running and the disk is unencrypted.
Maybe preventing employees from having access to that data in the
first place is where you should be starting your attack on this problem.
What if you have high turnover? In the helpdesk? If the employee has
the password, how does the helpdesk fix the box if the employee isn't
around? Do they *both* have a password? What's your password policy?
How do you enforce it? You can no longer boot desktops remotely,
unless you have KVM over IP, or serial console, or some other method
which enables you to enter the password without sitting at the desk.
How do you enable that? What effect does it have on your network
security policy? What if you have 9 different locations with three
employees each... and one guy in a truck who is your entire helpdesk
staff, and the remote boot capability is broken in two places at once?
When a critical update needs to be applied because a worm is in the
wild? If someone loses or forgets their boot password and they're in
China, how do you get it to them? Do you just let them call to get
it? That means the helpdesk has a list of cleartext passwords for
every bootable device (oy). How do you protect that list? How do you
prevent social engineering in a large organization? If I can call a
phone number and get a password over the phone without any sort of
real authentication, you've got a truck sized hole in your security
policy. You can't revoke an FDE password remotely, what if an
employee walks off with a bunch of your encrypted drives?
> But in every case that I've bought a server, the hard drive wasn't
> wiped, and the data wasn't encrypted, and I was able to recover
> stuff. FDE would make it much easier to do an instant wipe in
> those cases.
I'll bet you dollars to donuts that *if* encrypted drives were the
norm (as opposed to the exception), *and* every organization in the
world used them, you would *still* be able to get piles and piles and
piles of used drives that you could crack open in relatively short
order since the passwords would be trivial. People wouldn't bother to
do the instant wipe, for the same reasons that they don't bother to do
wipes on drives now... because they're lazy and their security policy
is garbage.
Look, I'm not trying to badmouth full disk encryption. It has a
valuable place in any organization's overall security policy. But far
too often FDE is regarded as a patch to cover up some other problem,
and introducing it organization-wide will just open up so many other
issues that it will wind up being worked around almost immediately.
You've just spent a ton of money on hard drives and motherboards to
mask a bunch of symptoms when your real problem is that you've
marginalized your IT security folks to the point where everybody in
the org just ignores them entirely and doesn't give too cents about
security.
You can't do that anymore, or more to the point you can still get away
with it today, but the situation isn't getting any better, and sooner
or later (10 years, tops) you're going to see real civil and criminal
penalties for letting this data get loose. SB 1386 and SOX aren't the
end of this sort of regulation, they're the beginning.
Simson Garfinkel
This is really a beautiful rant. You should publish it somewhere.
DPW 401
side, but then I would be wrong about also needing to encipher the
connection payload (since it would then be encrypted). My point is that
hardware FDE on the disks won't protect the files on your server from
permissions failures.
> -----Original Message-----
> From: fde-b...@www.xml-dev.com [mailto:fde-b...@www.xml-dev.com]
> On Behalf Of Dmitry Obukhov d.obukhov-at-samsung.com |FDE081212|
> Sent: Monday, April 13, 2009 1:16 PM
> To: ....................
> Subject: Re: [FDE] how FDE is implemented at system layer
>
> DPW,
>
> It is not true; file base encryption is very resource consuming. To
> spend
> your server CPU load for encryption is the last thing you want to do.
> Unless you have endless budget, of course.
>
> For the servers I can recommend to look on TCG Enterprise
> specification.
> Seagate announced their TCG Enterprise product, you may want to contact
> them directly.
Dmitry Obukhov
>> Can you suggest a particular brand? Or is there a keyword I can use
>> for searching for this software? Any Linux compatible? If a salesdroid
>> is reading this, I would take your call!
> Check with Winmagic. I saw their demo on a MacBook with Seagate's FDE
drive at RSA. I am pretty sure they support Linux as well, but can't
guarantee.
During the RSA show I was running dual boot D630 on our self-encrypting SSD
(Vista and Ubuntu).
Dmitry,
Samsung Secure Storage
Daniel Feenberg
On Fri, 24 Apr 2009, Dmitry Obukhov wrote:
>
>>> Can you suggest a particular brand? Or is there a keyword I can use
>>> for searching for this software? Any Linux compatible? If a salesdroid
>>> is reading this, I would take your call!
>> Check with Winmagic. I saw their demo on a MacBook with Seagate's FDE
> drive at RSA. I am pretty sure they support Linux as well, but can't
> guarantee.
Winmagic isn't so easy to deal with. I wrote and a sales person called
back, but she was not authorized to give me any price information or
answer detailed questions. I have been playing telephone tag with her
superior for several days now, and don't have any real information yet. I
think the problem is that the sale of 5 units doesn't interest them that
much, and they are not set up for retail sales.
Are there any other suppliers of similar systems?
Daniel Feenberg
Joseph Belsanti
interest in dual boot capabilities and FDE. WinMagic demonstrated
multiple boot with Vista / XP/ and Linux at last year's RSA and at this
year's RSA Conference /Expo. It is good to see some validation of the
demand for Linux and multiple boot capabilities with Samsung
demonstrating dual boot in the booth next door.
Cheers,
WinMagic Inc.
Joseph Belsanti
Vice President, Marketing
-----Original Message-----
From: fde-b...@www.xml-dev.com [mailto:fde-b...@www.xml-dev.com]
On Behalf Of Dmitry Obukhov
Sent: April-24-09 4:53 PM
To: f...@www.xml-dev.com
Subject: Re: [FDE] how FDE is implemented at system layer
Dmitry Obukhov
It is not about "archaic". It is about ratio between storage throughput and
CPU computational power. If you use very fast storage (SSD, as I did, or
RAID controller), it can make any CPU relatively "archaic".
"Up to" was received on Dell D630 with SSD (fresh Vista Ultimate) and
intensive read access. On the same machine you can get lower values of CPU
load with lower intensity of storage access. Obviously, CPU load will be 0
if you don't access the data at all. If your results are about 3%, it means
that your storage is "archaic" relatively to CPU or you do not exercise it
on its full speed.
WBR,
Dmitry
-----Original Message-----
From: fde-b...@www.xml-dev.com [mailto:fde-b...@www.xml-dev.com] On
Behalf Of Tim Hollebeek
Sent: Thursday, April 16, 2009 8:19 AM
To: f...@www.xml-dev.com
Subject: Re: [FDE] how FDE is implemented at system layer
Darren Lasko
Hi Tim,
I'd also like to make a point regarding your statement that, "the marginal cost of additional CPU usage is zero unless your CPU meter is pegged." This might be true if you are running software-based FDE on a desktop system or on a notebook PC that is using wall power. However, for notebook PCs that are on BATTERY, additional CPU usage greatly impacts your on-battery time.
I've experimented with software-based FDE (granted, not BitArmor, but I can't imagine the results will be much different), and there is a SIGNIFICANT decrease in the amount of time you can stay on battery when using software-based FDE compared to using a self-encrypting drive. The difference is significant even under light workloads where the drive I/O activity is low.
Best regards,
Darren Lasko
Principal Engineer
Advanced Development Group, Storage Products
Fujitsu Computer Products of America
| Dmitry Obukhov <d.ob...@samsung.com>
Sent by: fde-b...@www.xml-dev.com 04/27/2009 02:40 PM
|
|
This message contains information which may be confidential and privileged. Unless you are the addressee (or authorized to receive for the addressee), you may not use, copy or disclose to anyone the message or any information contained in the message. If you have received the message in error, please advise the sender by reply [email], and delete the message.
Glancey, Bryan
Darren –
There is extensive scientific data on this, no need to speculate. Software FDE does cause some extra battery usage due to extra CPU utilization (Bias stated, Mobile Armor makes BOTH software FDE and authentication and management modules for encrypting hardware drives like Opal SSC).
I wouldn’t categorize the data as ‘significant’, unless your use of mathematical exponentials differs from mine. Given that we make both drives with embedded authentication and software based FDE, we have seen battery time changes in minutes – not hours as your use of SIGNIFICANT would denote.
Perhaps your calculus is different than mine?
Regards;
Bryan
------------------------------------
Mobile Armor
Bryan E. Glancey
Senior Vice President & Chief Technology Officer
br...@mobilearmor.com
400 South Woods Mill Rd.
Suite 300
Chesterfield, MO 63017
http://www.mobilearmor.com/
------------------------------------
Darren Lasko
Hi Bryan,
I never did any digging for scientific data. If you have some pointers I'd be interested in taking a look.
My personal experience was on a Fujitsu Lifebook S7110 (Intel Core 2 Duo T7200) running TrueCrypt. The difference in battery life was about an hour (~4 hours instead of ~5 hours). According to my calculus, that's about a 20% decrease, which to me is significant.
Maybe TrueCrypt has higher CPU overhead than some of the commercial solutions? I don't know.
Best regards,
Darren Lasko
Principal Engineer
Advanced Development Group, Storage Products
Fujitsu Computer Products of America
| "Glancey, Bryan"
<br...@mobilearmor.com>
Sent by: fde-b...@www.xml-dev.com 06/05/2009 11:17 AM
|
|
This message contains information which may be confidential and privileged.
Unless you are the addressee (or authorized to receive for the addressee),
you may not use, copy or disclose to anyone the message or any information
contained in the message. If you have received the message in error, please
advise the sender by reply [email], and delete the message._______________________________________________
FDE mailing list
F...@www.xml-dev.com
http://www.xml-dev.com/mailman/listinfo/fde
Scott S
I would agree that with increase processing power of computers, the
performance hit by software encryption diminishes. However, this also does
not fully capture the picture of performance. The setup of the initial
encryption process or the removal of the encryption task few hours to
complete, whereas with self-encrypting hard drive it is instant on and
instant off.
One could argue that these tasks do not occur that often, and if they
happens, they are the background processes and don't impede the user from
using the computer. True, but if one needs to wait for these tasks to be
completed it is a major impact. For example, due to letigations and
layoffs, I have seen repeated request first hand for whole batches of
drives to be encrypted or decrypted for archival or discovery purposes.
Scott
On Thu, 4 Jun 2009, Glancey, Bryan wrote:
>
> Darren ?
>
>
>
> There is extensive scientific data on this, no need to
> speculate. Software FDE does cause some extra battery usage due to extra CPU
> utilization (Bias stated, Mobile Armor makes BOTH software FDE and
> authentication and management modules for encrypting hardware drives like
> Opal SSC).
>
>
>
> I wouldn?t categorize the data as ?significant?, unless your
> use of mathematical exponentials differs from mine. Given that we make both
> drives with embedded authentication and software based FDE, we have seen
> battery time changes in minutes ? not hours as your use of SIGNIFICANT would
Dmitry Obukhov
The increase of main CPU computational power will change the picture only
when taken out of the context.
In the reality the storage throughput is growing too. This holds the ratio
pretty much stable. For example the
Introduction of 6G SATA products will require encrypt/decrypt 4.8Gb/s of
data instead of 2.4Gb/s for 3G SATA.
4K sectors will increase the latency of software solutions ~8 times.
SED hardware can be considered as cryptographic co-processor that always
match the throughput of the storage.
Do we need graphic co-processor? Do we need floating point co-processor? It
depends on the definition of "need".
Coming back to the power consumption, the experimental measurement is
complicated. The theoretical part is:
Please pay attention that I intentionally used only generic public
information, for the info on specific products, please contact their
vendors.
SW Cipher performance 30 I/B (true for ECB, CBC
will require as minimum 4 more operations)
Throughput 200000000 B/S
(http://en.wikipedia.org/wiki/Solid-state_drive)
Cipher load 6000 MIPS
CPU, max 14564 MIPS -->
http://en.wikipedia.org/wiki/Instructions_per_second
Cipher overhead 41.1975 %
CPU pwr cons 89 Watt -->
http://en.wikipedia.org/wiki/Athlon_64_X2
Cipher pwr cons 36.6658 Watt
So, on the active read operations 41% of the computational power will be
spent on decryption. This matches my experimental data.
If we will assume that electrical power overhead is proportional to the
computational power overhead, we will have ~37 Watt.
WBR,
Dmitry Obukhov,
Samsung Secure Storage