U.S. Gov't To Use Full Disk Encryption On All Computers

To address the issue of data leaks of the kind we've seen so often in the last year because of stolen or missing laptops, writes Saqib Ali, the Feds are planning to use Full Disk Encryption (FDE) on all Government-owned computers. "On June 23, 2006 a Presidential Mandate was put in place requiring all agency laptops to fully encrypt data on the HDD. The U.S. Government is currently conducting the largest single side-by-side comparison and competition for the selection of a Full Disk Encryption product. The selected product will be deployed on Millions of computers in the U.S. federal government space. This implementation will end up being the largest single implementation ever, and all of the information regarding the competition is in the public domain. The evaluation will come to an end in 90 days. You can view all the vendors competing and list of requirements."

Comments

But why?

[timeOday]

I mean, if you have nothing to hide, you have nothing to fear, right?

Re:But why?

[Anonymous Coward]

I, for one, welcome our new disk-encrypting overlords....

Re:But why?

[tajmorton]

I mean, if you have nothing to hide, you have nothing to fear, right?

Like your Social Security Number, right?

Re:But why?

[reset_button]

I don't think it's about hiding things from the people - it's preventing people from accessing people's private data. Think about the person that works for the IRS that has your tax records on his laptop, or the person that works for the FBI that has information about ongoing criminal investigations. You get the idea.

I hope they end up doing this in hardware. I know people who have worked for companies that required software-based encryption, and turned it off because it was too slow. With hardware, you get less overhead, and the average worker won't be able to turn it off.

Re:But why?

[SatanicPuppy]

Meh, they try to hide stuff all the time now, and how many things do we find out because someone left it written up on a poorly secured computer? Government "transparency" always depends on people on the inside leaking the information.

On the other hand, they're losing laptops full of veteran's records on a monthly basis. Either they need to take better care of the data, or they need to put tighter controls on who has access to the data.

Re:But why?

[Splab]

But they do have something to hide...

Re:But why?

[dekropisvol]

Until your President signs a law for what is common at the moment, it won't be after this and all your activities are monitored till years ago. Nice to have a friend in your cell who want's to have sex with you, only for walking funny before singing the law against funny walks. DON'T WALK FUNNY

Re:But why?

[WED Fan]

And, you'd be the first one to cry to the f*&king heavens as soon as the Government let YOUR secrets out in the open. Or when a government, controlled by a political party other than your chosen favorite, screwed up in a major way when Intelligence is released into the wild.

Find a government on the planet that does as you desire, I'll show you mythology. Only those seeking the downfall of a political system, or governing body require that body to release all its secrets. When that body is your government, then you meet the definition of "Traitor".

Whether controlled by Republicans, Democrats, Libertarians (mythological political party), The Raving Loons of Parump, the government must keep secrets and protect select information from release until such a time that its release is no longer a harm to the citizens and country.

Re:But why?

[jank1887]

Either they need to take better care of the data, or they need to put tighter controls on who has access to the data.
ding ding ding! we have a winner. Although it was funny, the way you stated that as an OR question. The encryption issue will help solve the problem of the stolen laptop. But not necessarily the problem of misused/leaked data. This is a typical government IT kneejerk reaction to something that is best addressed by proper use, practice and policy, rather than the opted for expensive technical fix. Well, at least someone's going to make a boatload of money.

Re:But why?

[Anonymous Coward]

Not all users of government equipment are government employees. I work for a volunteer organization called Tax Aide - there are 30,000 of us who do free tax returns for mid to low income tax payers. The IRS provides us with software and lends us some of the laptops we use. The mandate for this tax season is that all their laptops will be encrypted - we will have sensitive personal information stored on those computers. Seems like a reasonable requirement and one to be extended to all laptops we use.

Re: But why?

[Black Parrot]

> I mean, if you have nothing to hide, you have nothing to fear, right?

a) How many times per year do you hear about n million people's SSNs or medical records being on some public employee's stolen laptop?

b) Even on a system for purely personal use, do you want a thief or meddler to have access to your correspondence?

Re:But why?

[Anonymous Coward]

The weakest link will still be the social one: if there's a human being with the data, he can just copy it down.

As long as any part of the government (outside of the Social Security Administration) is using my SSN, there's potential for trouble.

Let's fix the root cause: get those fucktards to stop using a system which is supposed to save money for my retirement as a national ID card system.

Re:But why?

[Anonymous Coward]

Righto Whacko. The Empire must keep it's secrets. The citizens, OTOH, have no need of privacy. In fact, such demands should immediately arouse suspicion in any reponsible Empire.

Get back in your box, little Stasi fuckwit.

Re:But why?

[ralphdaugherty]

ding ding ding! we have a winner. Although it was funny, the way you stated that as an OR question. The encryption issue will help solve the problem of the stolen laptop. But not necessarily the problem of misused/leaked data. This is a typical government IT kneejerk reaction to something that is best addressed by proper use, practice and policy, rather than the opted for expensive technical fix. Well, at least someone's going to make a boatload of money.

      And your post is a loser. Look at a few informative posts in this thread, they explain why both the use and excryption of data on mobile devices is nexcessary, and not a "kneejerk reaction".

      And where did you come up with this "leaked" data thing?

  rd

Excel?

[Anonymous Coward]

Figures they'd have to put the list of vendors in an Excel spreadsheet which I cannot read at the moment.

Eh.

[SatanicPuppy]

Well, on the one hand, it's a good idea to encrypt machines that contain sensitive data.

On the other hand, this is just a bandaid on their terrible information policy...The reason that they have to encrypt a zillion machines is because they store sensitive personal data on a zillion machines. Then there are multiple operating systems, levels of security, etc. All this means that compromising one machine will still be pretty easy, because when you have encryption on the crappy desktop in the mailroom where everyone surfs porn, you stop taking it seriously.

They could kill the whole problem by centralizing their data stores, and developing some secure web interfaces across enhanced encryption. That way, instead of trying to encrypt every machine, you could encrypt 50 data centers and control access locally...Hell, if I were the government I'd push all my software needs toward think clients and terminal services anyway...The average user doesn't need more, and that makes all your security problems more managable.

Re:Eh.

[Billosaur]

They could kill the whole problem by centralizing their data stores, and developing some secure web interfaces across enhanced encryption. That way, instead of trying to encrypt every machine, you could encrypt 50 data centers and control access locally...Hell, if I were the government I'd push all my software needs toward think clients and terminal services anyway...The average user doesn't need more, and that makes all your security problems more managable.

Why would government people need to be dragging this stuff home on their laptops anyway? In this era of high bandwidth connections and VPN, why can't the data be accessed from home or via laptop without it existing physically on the hard drive? I mean, when you think about it, they could just print the data out on paper and lose that as easily, but it seems that the idea is to create centralized, secure data stores, not to allow multiple copies of the same data to go floating around. If nothing else, data dropped on a HD may get out of synch with the original data, leading to errors.

Re:Eh.

[pizpot]

Why would government people need to be dragging this stuff home on their laptops anyway?

This is not an IT question but a human one. You may as well ask:

Why would employees export files out of the database and copy them to their laptop rather than deal with the a network database managed by a phone desk IT department. Or, rather than deal with using a mainframe and a dumb terminal in the office and not using a laptop.

Yes they are just avoiding the IT department as much as possible. Haha. Just like in every organization, it needs to be broken up and distributed or something.

Re:Eh.

[axcessor]

While centralization of data storage is a good idea, it would not solve the entire problem. There are still multiple vectors for data leaks including USB drives, CDR, web-based email or forums, or even network transfers. Thin clients were a nice thought but a flash in the pan for the most part. No one has been able to make them practical. Blame the bloated OS's for that one.

Re:Eh.

[bbernard]

"They could kill the whole problem by centralizing their data stores, and developing some secure web interfaces across enhanced encryption."

Belts and Suspenders. Doing both would be even better. Besides, how do you prevent that government worker from saving a local copy? How do they do their work on a plane trip across country? How else do you ensure that the web cache, paging file, or any other place where even temporary data stored on the local hard drive is going to be protected?

This is a great development, and having a body such as the US government doing a trial like this and sharing the results will be a wonderful resource for InfoSec people looking at the same situation. I'd love to see what the rollout plans look like.

Re:Eh.

[pizpot]

Imagine, a federal government bureaucracy IT department. Gasp.

Re:Eh.

[msobkow]

It also means that even if physical evidence is seized, the people won't be able to get at the data necessary to prove graft or corruption. :(

The governments wanted a repository of keys, a back door to spy on the population. Turn about is fair play.

Bend over.

Re:Eh.

[throx]

In this era of high bandwidth connections and VPN, why can't the data be accessed from home or via laptop without it existing physically on the hard drive?

Because not every government employee has access to high bandwidth connections, especially if they are stationed outside the US. Disconnected operation is essential.

Re:Eh.

[CohibaVancouver]

Why would government people need to be dragging this stuff home on their laptops anyway?

It's not 'dragging this stuff home', it's people who go out in the field to do their job - One simple example is FEMA. When they go to a disaster they take along thousands of laptops in order to register people who need aid. There isn't a LAN they can "SSH into" and they can't phone this stuff in. Another example might be the IRS who would visit individuals and businesses to perform audits.... The list goes on.

Re:Eh.

[Chazmyrr]

Many offices don't have high bandwidth connections. Business travel may prevent access to secure high bandwidth connections. Soldiers in the field probably have a secure connection, but it definately isn't high bandwidth.

A certain amount of decentralization is necessary to allow fault tolerance. Wars don't stop because the network is down. Small units leaders carrying some sensitive information encrypted on an electronic device is greatly preferable to having the same information printed in plain text on pieces of paper.

Re:Eh.

[jank1887]

actually, we contract that out.

Re:Eh.

[ChrisA90278]

OK, let's say they do this, they keep the data only in a centralized location and you access it by an encrypted link. The problem is that the data must be decripted before it can be displayed to the user. So there is no way out of it the user's machine will hold, some place plain text data. Even if just in RAM. Once the data are in RAM it can "leak" onto the hard disk. For example the swap file is used to back up RAM or the user might have some program that saves the data so he can work off line. If the machine uses an encrypted disk then we don't have to care so much what is on the disk. I think you need to do other things too. Whole disk encryption does not solve the problem of spyware but does solve the stolen notebook problem But the BEST thing here is that the US Government will set the standard of care. Now when some company notebook is stolen and my data is compromised I have a chance of suing them because they failed to use whole disk encryption like the government does.

Re:Eh.

[Anonymous Coward]

Geez, you guys think like techs or something...

Government, in many agencies, is typically a little behind the technology curve. Having a centralized server that could be compromised is a *bad* idea, while having portions of your data decentralised gives both an order of protection and *somebody to blame other than the entire administration* if it goes missing.

And, yes, fieldwork is usually the only reason anybody gets a laptop with any real data on it. Its great to have the encryption, but I want it to explode like on Mission: Impossible, too.

Re:Eh.

[kcbrown]

While centralization of data storage is a good idea, it would not solve the entire problem. There are still multiple vectors for data leaks including USB drives, CDR, web-based email or forums, or even network transfers.

None of which are addressed by encrypting the client system's drive, of course.

The purpose of encrypting the drive is to make it difficult for the data to be compromised in the event the system gets lost or stolen. It does nothing to address intentional leaks, and neither does the use of thin clients.

I believe the point the GP was making is that using thin clients and leaving the data on the server accomplishes the same goal as encrypting the drives do, but in a more manageable way.

Re:Eh.

[Beardo the Bearded]

I was reading the paper this morning. I read an article about how a laptop with confidential ministry information on it went missing.

I had the same thought as you. Encryption is solving the wrong problem. Why on earth should the laptop even have this information on it? Secure the data in a few central locations, use some known secure protocol to access the information, and then you don't have to worry about the laptops.

It would be way cheaper to maintain and keep everyone's data up-to-date.

Re:Eh.

[Anonymous Coward]

More to the point, the government is frikkn huge. I'm a part of it with a laptop, and I'm a scientist with no sensitive info. on it (except to me if someone publishes first, and my academic colleagues haven't quite stooped to theft). Top-down one-size-fits all directives work no better here than in any large company. Personnel computers (with SSNs etc.) it makes sense for, we need to do better. But doing it on an emergency panic whim based on bad publicity is not smart.

Re:Eh.

[Chandon Seldon]

I've got decent speed data connectivity anywhere there's a Sprint cell network. Cell network Internet connections are more than fast enough for transferring textual data, and once you have a TCP/IP connection you can encrypt stuff all day long.

Re:Eh.

[Ancalimar]

I'm no web programmer, but (and correct me if I'm reading this wrong) I'm not a huge fan of the government using ANY kind of "web interfaces", enhanced or not. I don't think the problem is Microsoft, I don't think the problem is government, I think the problem is that any system is hackable. It's one thing for thousands of laptops to get encrypted, but it's another thing entirely to open your network up to potentially millions of people who want nothing more than to claim they "hacked" the U.S. government. I suppose a thin client would work, but I'd want to make sure it was modified so extensively that no outside software or hardware could recognize it.

Re:Eh.

[Anonymous Coward]

This would appear to be a good idea on the surface, and I think it is good in the general context of securing private and sensitive information, but...

1) This is the government we a talking about. I can't wait until The Big Switch Over and hearing about all the data that has been lost.

2) People won't initially trust full encryption and start to backup huge amounts of data in the clear. In the end you will have a massive spike in sensitive information being stored at home, in briefcases, in cars, etc on personal laptops, external drives, thumb drives, DVDs, etc. This will present an even larger (but short lived) security risk.

3) And let's not forget. In the end people are always the weekest link. So they encrypt everything. Well people will continue to copy in the clear, write down the information on notepads, use weak passwords, etc.

Re:Eh.

[pla]

Because not every government employee has access to high bandwidth connections, especially if they are stationed outside the US. Disconnected operation is essential.

If you work as a low-level US diplomat in Peru, do you really need to carry around the complete medical records of 20 million veterans?

Additionally, you can get a tolerable bandwidth connection anywhere on the planet - We now have these things circling the Earth far above, sort of artificial "satellites", if you will. Some of them have the purpose of facilitating bidirectional data communication between two points on the planet - Such as a cottage in the middle of nowhere, and a datacenter in the US.

A decent satellite net connection doesn't come cheap, but keep in mind the target audience here - The single most fiscally-irresponsible entity on the planet.

Re:Eh.

[canuck57]

It's not 'dragging this stuff home', it's people who go out in the field to do their job - One simple example is FEMA. When they go to a disaster they take along thousands of laptops in order to register people who need aid. There isn't a LAN they can "SSH into" and they can't phone this stuff in. Another example might be the IRS who would visit individuals and businesses to perform audits.... The list goes on.

With the wireless openly enabled no doubt.

Eventually all devices will need crypto on all of it's interfaces to be effective. Make a PC that can't talk off-board without crypto including floppy, USB, IEEE, CD/DVD, serial/parallel port etc. So even a malicious or stupid user can't get the information out or bot/worm/viruses in.

But why are they distributing the information in XLS files in the first place? How do we know if this isn't a new fangled way to add our PCs to the big bot net? I like Slashdot but if I see a DOC, XLS, EXE and others I am not going to click on it with a Windows PC I care about. That is where I use my Linux system...in a unprivileged account.

But this is a good first step.

Re:Eh.

[ichimunki]

What's so unmanageable about hard disk encryption?

Re:Eh.

[StikyPad]

It's worse than that. They need centralized access, which means... you guessed it, a semi-universal (within each facility at least) password to access the data on all of the computers.

Also, "thin clients" are neither novel nor inherently more secure. Distributed data may be highly vulnerable to attack on an individual case-by-case basis (i.e., 1 person losing a laptop could compromise all the data), but centralized data is vulnerable to a distributed attack (i.e., one or more attackers discover the IP/port and look for vulnerabilities or [less likely] brute force). If a single individual leaves his or her key (username/password or key on solid state device or whatever) somewhere and somebody else finds it, the data is potentially compromised all the same. Granted, someone has to recognize what they have, but that's no different in the case of a lost laptop, where a thief is probably going to just wipe the drive and install something else rather than scour it for information.

Security is the responsibility of everyone who uses a network, and is dependant on the weakest link, regardless of whether the data is centralized, distributed, and/or encrypted.

Re:Eh.

[kimvette]

Another example might be the IRS who would visit individuals and businesses to perform audits

Considering that the IRS is a private company and not actually part of the government, are their computers affected by this? Better yet, let's go another step: Close the IRS and institute a fair flat tax then audits will become largely a thing of the past.

Re:Eh.

[rtechie]

Close the IRS and institute a fair flat tax then audits will become largely a thing of the past.

Or, roughly translated: "Let's have an armed revolution and a new consitution!"

That's what you'd need in order to implement a FAIR flat tax.

Re:Eh.

[ralphdaugherty]

Sorry to reply to your insightful post, but you're the first post. :)

      This is the goofiest slashdot thread I've ever seen. I clicked on the link to the directive and it is a simple order to:


Encrypt all data on mobile computers/devices which carry agency data unless the data
is determined to be non-sensitive, in writing, by your Deputy Secretary.


      It goes on to talk about:


Personally Identifiable Information (PII) categorized in accordance with FIPS 199 as
moderate or high impact that is either:
  Accessed remotely; or
Physically transported outside of the agency's secured, physical perimeter (this
includes information transported on removable media and on portable/mobile
devices such as laptop computers and/or personal digital assistants).


      This is just common sense, and a direct result of the VA laptop that was stolen.

      The bottom line. Personally Identifiable Information won't be carried out of buildings anymore or FTP'd elsewhere like home, which was a mandate anyway.

      In the rare case it is required, the device will be encrypted.

      For the first time ever, a government document makes more sense than a slashdot thread.

  rd

Re:Eh.

[ralphdaugherty]

To address the issue of data leaks of the kind we've seen so often in the last year because of stolen or missing laptops, writes Saqib Ali, the Feds are planning to use Full Disk Encryption (FDE) on all Government-owned computers. "On June 23, 2006 a Presidential Mandate was put in place requiring all agency laptops to fully encrypt data on the HDD.

      Who is Saqib Ali, and is he getting this "all Government-owned computers" thing from the referenced Mandate (which refers to mobile devices with sensitive agency data on them) because of a reading comprehension problem or knows something not in the Mandate?

  rd

Re:Eh.

[ralphdaugherty]

It's not 'dragging this stuff home', it's people who go out in the field to do their job - One simple example is FEMA. When they go to a disaster they take along thousands of laptops in order to register people who need aid. There isn't a LAN they can "SSH into" and they can't phone this stuff in. Another example might be the IRS who would visit individuals and businesses to perform audits.... The list goes on.

      Yes, and very appropriate that those laptops are encrypted. Thanks for the info.

  rd

Re:Eh.

[ralphdaugherty]

I had the same thought as you. Encryption is solving the wrong problem. Why on earth should the laptop even have this information on it?

      That's what the Mandate addresses. A mobile device with sensitive data taken off premises has to be encrypted. Therefore sensitive data on mobile devices to be unexpectedly taken off premises will be questioned and need to be justified, as it should be.

      A previous poster gave some examples of when working with sensitive data offsite is part of the job, and those devices would be encrypted.

  rd

Re:Eh.

[ralphdaugherty]

I'm no web programmer, but (and correct me if I'm reading this wrong) I'm not a huge fan of the government using ANY kind of "web interfaces", enhanced or not. I don't think the problem is Microsoft, I don't think the problem is government, I think the problem is that any system is hackable. It's one thing for thousands of laptops to get encrypted, but it's another thing entirely to open your network up to potentially millions of people who want nothing more than to claim they "hacked" the U.S. government. I suppose a thin client would work, but I'd want to make sure it was modified so extensively that no outside software or hardware could recognize it.

      This is an excellent point. I wish this were crystal clear to every software decision maker in government.

  rd

Re:Eh.

[throx]

If you're in a HUMM-V in Iraq, do you really want to be setting up a satellite connection just to use your laptop? I stand by my case that disconnected operation is essential.

Re:Eh.

[pla]

If you're in a HUMM-V in Iraq, do you really want to be setting up a satellite connection just to use your laptop?

No, I don't suppose I would.

Now, sitting in that same vehicle in Iraq, why exactly would you need to know the complete VA medical benefits history of Frank Brown, age 84, current location (and residence), Chelsea WI?

Offline access to (nonclassified) maps, great. Offline access to somewhat sensitive information directly relevant to your mission, fine. Offline access to data that has no use and should never make it past the door of a cushy HR office somewhere inside the Pentagon? No. No reason at all.



You've conflated all government employees (keep in mind the US government employs over fifteen percent of the workforce) with the role of a deployed unit's SigInt officer. When people say the government needs to fix its IT policy to control where information goes rather than the media it goes there on, no one means that we should let soldiers die rather than give them encrypted laptops. But like it or not, "for the troops" has as much validity as "for the kids". An emotional hotbutton that can make truly absurd and ineffective changes sound appealing.

Re:Eh.

[ztynzo]

I used to work communications in the military... and this was my thought.

Some people might use their Hummer's to do office work, but there's no good reason that a person out in the field (ie: not at base camp) would need a satellite connection to do their office work... if it's important enough to warrant it being on a centralized secure system, it's important enough to do in a proper place.

I just think that requiring every computer to maintain an encrypted drive is poppycock. It's a huge overhead, it forces the average user who doesn't need the security to have to deal with it, then it becomes as hassle, then people start writing the authentication information on the keyboard (or near in the case of a laptop) and we're back where we started.

If you want to have offline capabilities, that's fine, but make it for a very small number of records, no more than 10.

Re:Eh.

[throx]

Who said I was talking about soldiers? You do understand there's a lot more people in Iraq (and in lots of other places around the world) employed by the US Government than just front line troops, right?

Same goes for your VA benefits line. This policy covers *any* sensitive data, and I'm sure you'll agree that government laptops can and do have data of varying degrees of sensitivity that make it sensible to adopt a broad policy to cover all of them rather than enact another level of bureaucracy just to decide what policy applies to which PC?

So, nice kneejerk assuming I was playing the "for the troops" card, but you're wrong.

Re:Eh.

[Anonymous Coward]

But why are they distributing the information in XLS files in the first place?

The VA medical system is similar to the DoD CHCS system, and that one doesn't contain very fast or friendly reporting mechanisms outside of what is stock. Fairly often, department heads and doctors have data requests that the system can't deal with in a reasonably fast (or even a reasonable fashion). It's not uncommon for superusers to have data mining access, and again, it's not uncommon to output the plain-text reports into a .csv or ^-separated format for easy import to Excel or Access, both of which provide better sub-searching functions than the data mining would easily allow.

Re:Eh.

[CohibaVancouver]

I've got decent speed data connectivity anywhere there's a Sprint cell network

I suspect if you'd been with FEMA in hurricane-battered New Orleans you might have had a problem. Or with the FBI at some Militia compound in rural Montana. Or...

Re:Eh.

[silas_moeckel]

What happens to the data in swap and temp files? Keeping the data in a secure location is a good idea but you still have to deal with keeping the data safe on machines used to view it. Keeping at data at rest secure is a good idea. You still have to deal with screen scrapers and other spyware.

File formats

[1u3hr]

Interesting the specifications are supplied in:
DOC
DOC
XLS
DOC
DOC
DOC
PPT
PDF
DOC

So much for open formats.

Re:File formats

[Anonymous Coward]

Of course. After all, these formats are more secure, no exploits ever found! Suits US Govt.

Re:File formats

[oneeyedelf1]

Dumbass, PDF is an open format.

Re:File formats

[1u3hr]

Dumbass, PDF is an open format.

Fuckwit, I know that. Eight out of nine documents referred to are not.

Assholes like you have modded my simple observation down as "troll", off-topic". I thought the implications were too obvious to need to be pointed out. But apparently not. It demonstrates how deeply embedded MS formats are, to the point that no one can do business with the Defense Department without a full MS Office setup. Not a great expense for a corporation, but unsettling. It strongly suggests that the severe security problems of MS systems still cannot force a rethink of what they should be using, that security will be bolted on rather than built in.

Great Business Opportunity

[Zeek40]

Time to start a business who's only service is reformatting and reinstalling disk images after federal employees forget their encryption keys/ passwords.

Re:Great Business Opportunity

[SRA8]

Good luck. You'll have IBM, BeringPoint, Booz and Accenture overbidding you 300% and still winning the contracts.

Re:Great Business Opportunity

[naked_biker]

Spoken like someone who doesn't know what he's talking about. I've implemented disk encryption at a federal agency and for the past 7 months and we have yet to format or reinstall an image. All the products being evaluated offer password reset/assistance features and key escrow for recovery purposes; and we know they work because, yes, people forget passwords or delete key files.

Re:Great Business Opportunity

[infolation]

they're using a central key repository of small yellow sticky pieces of paper.

Re:Great Business Opportunity

[Anonymous Coward]

Time to start a business who's only service is reformatting and reinstalling disk images after federal employees forget their encryption keys/ passwords.

What do you think government IT people do now? This won't change anything.

Re:Great Business Opportunity

[jank1887]

stuck under the keyboard on behind the monitor for security.

Re:Great Business Opportunity

[Cassini2]

stuck under the keyboard or behind the monitor for security.

Because you can't stick the password on the monitor. The annoying IT security types complain when that happens.

I just tell my friends my password, so they can remember it for me. I also keep a copy of it in the bottom of my desk drawer, underneath my pens.

Don't lose your pass-key

[G27 Radio]

In order to prevent the loss of pass-keys to these machines (and the resulting loss of important information,) users will be required to keep a copy of the pass-key taped to the bottom of their computers.

Re:Don't lose your pass-key

[Capt James McCarthy]

"In order to prevent the loss of pass-keys to these machines (and the resulting loss of important information,) users will be required to keep a copy of the pass-key taped to the bottom of their computers."

Don't you mean taped to their forehead?

Re:Don't lose your pass-key

[Frosty Piss]

In order to prevent the loss of pass-keys to these machines (and the resulting loss of important information,) users will be required to keep a copy of the pass-key taped to the bottom of their computers.

The Air Force currently requires ( in addition to the use of a "Smart Card" plugged into the machine to gain access ) a 15 char password consisting of 3 caps, 3 lower, 3 numbers, and 3 special char ( the rest is up to the user ), no proper names, dictionary words, more than 3 letters or numbers in sequence ( back or forward ), must not be the same or simular to your last 25 passwords, and you must change it every 90 days.

The net result is that most people are writing it down and storing it in some easy to access place. Previously, we had an 8 char pass that required 2 caps, 2 lower, 2 special, 2 numbers... It was short enough that you could actually remember it.

Re:Don't lose your pass-key

[MasterC]

...users will be required to keep a copy of the pass-key taped to the bottom of their computers.

I know you are kidding, but the truth isn't that far off. Someone I know's mother (names, exact relationship to me, and organization intentionally withheld) works for the government. The laptop had a BIOS password, which was written on a slip of paper in the laptop case. Her password for the account involved *only* the current month and year. And this was acceptable per policy as of a few months ago.

If I can't trust the government to keep information secret, then why should I trust them to do anything?

Re:Don't lose your pass-key

[sgt.greywar]

The Army is adopting the 15 character password policy as well. Additionally most systms are now auto-generating these passwords instead of allowing the user to create them. This means that for people with multiple accounts they have totally dissimilar 15 character passwords to "remember" and by remember I mean either write down in easy to grab notebooks, or composing emails to themselves listing all their passwords in them. Moronic.

Re:Don't lose your pass-key

[trianglman]

you mean like this?

Re:Don't lose your pass-key

[throx]

It's actually more secure to have an essentially random password that people secure on a laminated card in their wallet (appropriately obfuscated of course) than have passwords that people can easily remember. When you think about it, people are actually very good at securing their wallet independently of their laptops.

Re:Don't lose your pass-key

[trb]

LogOn! Apply directly to forehead!

Re:Don't lose your pass-key

[Gogo0]

Did the Air Force go to InfoCon 4 also? (Army DOIM, here)

Not to nag, but is login policy public information? I'm sure people can find out that we use CACs to log in now, but detailed (as detailed as Army Pacific gived the DOIM, at least) password requirements for InfoCons 4 and 5 probably fall into OpSec.

I may be wrong though ^_^

Re:Don't lose your pass-key

[Frosty Piss]

Not to nag, but is login policy public information?

Good question. It's available on publicly available web sites.

Re:Don't lose your pass-key

[slyfox]

As long as they remove the pass-key before they junk the machine, this is probably fine. I think the biggest issue they are worried about is avoiding the recent stories in which US government data found on used hard drives purchased from eBay... Using whole-disk encryption makes "erasing" the hard drive as easy as destroying a single key.

Re:Don't lose your pass-key

[Cthefuture]

Even better is to physically store it on something like a smartcard. Even with a simple 4 digit PIN it offers substantial security over plaintext. Then the card can authenticate the user using extremely complex methods if desired (PKI or very long/complex passwords). Plus it can store authentication for multiple systems easily.

Then you have decent physical security as well. Don't get me wrong, it's not perfect but it is still very effective.

Re:Don't lose your pass-key

[Anonymous Coward]

The Navy did. The order came from STRATCOM. so I would think that it is across all DOD.

Re:Don't lose your pass-key

[Martin Blank]

This is true from a practical sense for the moment, but it's still a good idea to erase the drive anyway. The reason is that you don't know what encryption technologies you now use are going to still be secure in five, ten, or even twenty years. It's possible that the hard drive encrypted with AES-256 that was lost last week will be subject to a key derivation attack within the usable lifetime of the data stored thereon. Remember, some data does need to be secured for decades, such as certain personal information about people who might be particularly long-lived. My SSN, for example, may still be valuable to me in 70 years. I'll be past the 100-year mark then, but I may still be alive and the SSN may still be in use.

Re:Don't lose your pass-key

[Anonymous Coward]

The Air Force currently requires ( in addition to the use of a "Smart Card" plugged into the machine to gain access ) a 15 char password consisting of 3 caps, 3 lower, 3 numbers, and 3 special char ( the rest is up to the user ), no proper names, dictionary words, more than 3 letters or numbers in sequence ( back or forward )

Excellent. That really helps me out with my brute forcing, by cutting down on the number of possible passwords. All passwords NOT matching the above description do not need to be checked.

Thanks guys!

Re:Don't lose your pass-key

[Goldenhawk]

This isn't a big step for the Navy or Marine Corps.

The NMCI system already requires all users (laptop AND desktop) to log in via a smart card which carries several encryption certificates (among many other things, including personnel data, med history, etc.).

Also, the drives are NTFS formatted, and each user's Docs and Settings directory is locked - you cannot view anyone else's directory without admin privs. Not encrypted, but at least prevented from casual view.

So it's not going to require any extra steps, I imagine, for NMCI users - just a yet-slower computer as it deals with encryption.

Of course the card itself isn't enough to log in - you still need to enter a memorized password. Interestingly, however, the code is purely numeric - a PIN - and unlike the passwords used prior to the smart card, they (so far) have not been required to be changed regularly. Hmmm. A security hole? So it is at least three-factor security: access to the machine, a valid smart card, and a matching PIN. And there is hack-prevention: if you get the PIN wrong three times, the card is locked pending a visit to the card reset office where you must have a separate photo ID to get it unlocked.

This month, the NMCI folks locked down Outlook to prevent use of all non-text email (at least, by regulation; you can still work around it but it's a security violation), to limit the impact of trojan HTML content. Guess we're back to Pine.

Re:Don't lose your pass-key

[myowntrueself]

a 15 char password consisting of 3 caps, 3 lower, 3 numbers, and 3 special char ( the rest is up to the user ), no proper names, dictionary words, more than 3 letters or numbers in sequence ( back or forward )

I'm no crypto expert and my combinatorics is a bit rusty, but don't those constraints actually *reduce* the complexity of the password?

Re:Don't lose your pass-key

[wfberg]

It's actually more secure to have an essentially random password that people secure on a laminated card in their wallet (appropriately obfuscated of course) than have passwords that people can easily remember. When you think about it, people are actually very good at securing their wallet independently of their laptops.

Strangely enough, the parent post mentions something along the lines of ( in addition to the use of a "Smart Card" plugged into the machine to gain access ).

The best scheme is to have a smart card (preferably with an attached input device) that unlocks its public key authentication mechanism based on the entry of a password or PIN. A PIN should really suffice, as a smart card can simply lock out any repeated attempts at guessing after the first 3 tries. (It should still be fairly tamper resistant, but a smart card is in itself much better than, say, an easily copied magnetic stripe card).

One of the reasons to use smartcards in the first place is that the card can protect itself to some degree - which means you can make do with a PIN rather than a huge, complex password, which people WILL write down.

Re:Don't lose your pass-key

[mandelbr0t]

The link to "List of Requirements" should clear this up:

• Product uses an approved random number generator specified in FIPS 140-2 Annex C for key generation
• Capable of using DoD PKI certs for file encryption on removable storage devices
• For FDE, users encryption certificate contained in the DoD CAC shall be used to encrypt the file that contains the system generated full volume encryption key

(among others). As you can see, there's no requirement that a user actually type a password. In many cases, a certificate file will provide the appropriate credentials to unencrypt the data. From a cursory reading, this looks like Real Security(TM) as opposed to the Microsoft variety.

mandelbr0t

Re:Don't lose your pass-key

[LrdHghFxr]

99.9% of users do NOT need a password, nor do they have one. They rely on the use of the Common Access Card (CAC) and certificate based logon. This provides two-factor authentication, something you have, the CAC and something you know, a 6 digit PIN for the CAC.

The horrendous 15 character passwords are required for privileged accounts and the VERY rare situation where a user cannot use CAC authentication. Having a laptop is NOT one of those situtations, my GFE laptop has a smart card reader in it and is accessed via CAC.

Re:Don't lose your pass-key

[ralphdaugherty]

The Army is adopting the 15 character password policy as well. Additionally most systms are now auto-generating these passwords instead of allowing the user to create them. This means that for people with multiple accounts they have totally dissimilar 15 character passwords to "remember" and by remember I mean either write down in easy to grab notebooks, or composing emails to themselves listing all their passwords in them. Moronic.

      It truly is, and these are IT people who are the morons coming up with this. This is all about computations of how many decades of number crunching it would take to crack a password, and no computation whatsoever on how insecure an entire workforce is made when they can't remember their passwords.

      And I don't mean psychologically insecure.

      Every IT security person who comes up with password requirements that result in passwords that can't be remembered by the workforce should be made *the* helpdesk person for "can't login" problems.

      And yes, for all 32,000 of them they'll get the first day. Just bury the moron in help tickets until he figures out he's an idiot.

  rd

Re:Don't lose your pass-key

[ralphdaugherty]

It's actually more secure to have an essentially random password that people secure on a laminated card in their wallet (appropriately obfuscated of course) than have passwords that people can easily remember. When you think about it, people are actually very good at securing their wallet independently of their laptops.

      I can't believe this is considered insightful. Having to write a password down anywhere is less secure than not having to write it down because you can remember it.

      Having an impossible to remember password will be written down in much more accessible places than wallets appropriately obfuscated.

  rd

Re:Don't lose your pass-key

[ralphdaugherty]

I'm no crypto expert and my combinatorics is a bit rusty, but don't those constraints actually *reduce* the complexity of the password?

      I'm not either, but the answer is no. The purpose of requiring case sensitive keys with special characters and numbers is to add to the number of possible combinations.

      With special characters and numbers, the "not in a dictionary" requirement is redundant as it's impossible, but in an environment where numbers and special characters aren't required, the "dictionary" ban is in a way a "less complex" ban, that is, password cracking can't be accomplished by going through a dictionary rather than all combinations.

      I think the whole thing is silly. I doubt the people that come up with this stuff have any idea of a real cracker with a program that uses a dictionary instead of combinatorials. Most passwords are going to have some kind of name and numbers in them.

      The whole dictionary thing is as stupid as the people that come up with it.

  rd

Re:Don't lose your pass-key

[Cerebus]

"The Air Force currently requires ( in addition to the use of a "Smart Card" plugged into the machine to gain access ) a 15 char password consisting of 3 caps, 3 lower, 3 numbers, and 3 special char ( the rest is up to the user ), no proper names, dictionary words, more than 3 letters or numbers in sequence ( back or forward ), must not be the same or simular to your last 25 passwords, and you must change it every 90 days." ... for admin accounts. And it's 60 days now. Go reread your NOTAMs. :) MAJCOM requirements are allowed to be more stringent, but the baseline is 9-char for users and 15-char for admins, with a 60-day cycle.

The 15-char min for smartcard-exempted user accounts is coming, though. It was like pulling teeth to get it, let me tell you.

Re:Don't lose your pass-key

[Cerebus]

As others have noted, the *real* answer is "Stop using easily stolen single factor authentication credentials, dumbass!" Smartcard + PIN is my choice (I'm not a biometric fan; too easy to spoof still).

Re:Don't lose your pass-key

[ralphdaugherty]

As others have noted, the *real* answer is "Stop using easily stolen single factor authentication credentials, dumbass!" Smartcard + PIN is my choice (I'm not a biometric fan; too easy to spoof still).

      I agree, that's the right combination. All the technology for it is standard too.

  rd

Re:Don't lose your pass-key

[vrillusions]

Honestly, writing your password down isn't as bad as it first seems. I've heard this argument several times by security professionals. The trick is telling them "Protect that password like you protect your social security number." You always hear of the people that put their password on a post it note and then throw it under their keyboard or stick it to their monitor. I'll admit when I change the password for financial sites I access, the password is usually so complicated I don't immediately memorize. But I'll write down just the password, no login information or any indication of what it is, and I'll keep in a secure location. After a week or two I'll have it memorized and I can safely destroy the paper containing the password.

Re:Don't lose your pass-key

[throx]

My concern with smart cards is the transparency of implementation. How sure can you really be of tamper resistance, or even of its resistance to a MITM attack?

I tend to agree though - smart card+PIN can lead to a better security system than a straight password. I'm glad no one mentioned biometrics - that's a singularly bad idea for a number of reasons.

Re:Don't lose your pass-key

[WNight]

You are correct to question SCs because as password-generators (at heart) they offer only one type of authentication, and trade a shorter password for multiple longer ones, representing a security loss vs ideal memorization, but a theoretical real-world (heh) gain because the password wouldn't be rot-26 encoded on paper anymore. The gain is theoretical, as there are many ways to get past the best tamper-proof equipment and such - UV sensitive dust on the keypad and check for fingerprint on the PIN keys... It's a running battle.

As for MITM attacks though, the algorithms are what give you strength, not the device. Having a shared secret (a password) or a public key to their private key, allows you to write messages that only the other can understand. In this case the first message sent can be encrypted because the secret is already known - there is nothing plaintext for the MITM to overhear.

As for biometrics, they are usually bunk but in this case a biometric could be a free extra check - you have to put your fingers on it to use it anyways. It can't really reduce security as long as the same PIN is require, but it would introduce many modes of failure for the device and require bare-handed operation. Likely a loss.

Re:Don't lose your pass-key

[throx]

I understand that the algorithms are what is essential to a properly functioning SC, but my question was more one of validation that the SC you are holding actually implements those algorithms properly. I've found SC vendors generally rather tight on providing full implementation details to the public, not to mention the issue of a class break if the shared key or private key are found if there's no way to update them.

Re:Don't lose your pass-key

[ralphdaugherty]

The trick is telling them "Protect that password like you protect your social security number."

      I agree with that. I don't have my SSN in my wallet either. An unmemorizable password that must be used to login will be kept somewhere within reach of the keyboard, "hidden", but within reach.

      Any IT security type too ignorant to understand that will be ignorant enough to come up with unmemorizable passwords.

  rd

Re:Don't lose your pass-key

[jafac]

The gain is theoretical, as there are many ways to get past the best tamper-proof equipment and such - UV sensitive dust on the keypad and check for fingerprint on the PIN keys..

At one customer site, there was an access keypad for a door, where the buttons themselves had little LED numbers in them. Because of the lenses built into the buttons, it was difficult to read the numbers unless you were within about 12" of the keypad, and only directly in front. When you press the start button to activate the keypad, it scrambles the numbers under the buttons. You punch in the numbers in the entry code, and then press the enter key.

Fingerprints, UV-sensitive dust, not even a videocam over the shoulder wouldn't work here.

Of course, there's always torture.

Not to mention the fact that the number for this door was frequently given out to unauthorized persons - so even the best technology can be overcome by poor procedures.

Re:Don't lose your pass-key

[myowntrueself]

The purpose of requiring case sensitive keys with special characters and numbers is to add to the number of possible combinations.

Yes, in general it does.

But the specification which was outlined required very specific numbers of such characters and numbers.

Therefore, according to the GP post, the password *will* consist of:

3 caps, 3 lower, 3 numbers, 3 special char and 3 other characters from any of the previous 4 sets.

so, if I remember this right, the amount of distinct characters which could appear in the 15 character passphrase could be:

3x26 + 3x26 + 3x10 + 3x32 (if I got that right) + 3x(26+26+10+32)

Without those constraints, it would be 15x(26+26+10+32) which is a bigger number.

the "dictionary" ban is in a way a "less complex" ban, that is, password cracking can't be accomplished by going through a dictionary rather than all combinations.

Knowing that you can avoid names and dictionary words in your brute force attack and that there won't be "more than 3 letters or numbers in sequence ( back or forward )" surely reduces the search space considerably.

So when you set your "john the ripper" off you can exclude all dictionary words etc from your incremental search.

Like I said, my combinatorics are rusty, so if anyone else cares to do the math on this and prove me right or wrong, I'd be grateful!

Re:Don't lose your pass-key

[ralphdaugherty]

I agree, the set of special characters is less than 26, and the set of single digit numbers is less than 26, so yes, there would be less total combinations.

      And excluding the banned dictionary words and names limits the total even more. That's assuming these things are that clear, which they aren't. For example, I doubt this dictionary/name thing is programmatically enforced, on the other hand, as I posted somewhere the special characters and numbers rules it out anyway.

      Really goofy stuff, almost in the realm of security by urban myth.

  rd

Re:Don't lose your pass-key

[WNight]

Use one you can run your own code on - it's the old problem of trusting a black box.

As for security problems, I'd imagine those things have to be as air-tight a voting machines. Proprietary code and all.

Re:Don't lose your pass-key

[ralphdaugherty]

To clarify my earlier response, I understand the thinking that any position can contain upper/lower case, special character, or number increases the combinatorials greatly, and requiring a number or special character eliminates dictionary searches.

      Beyond that I don't understand how the given rules would make a password harder to break. On the other hand, it's hard for me to envision a crack program being able to do anything but consider that every position can have every combination, whether 1 of any other type or 3 of every type is required.

      But I am not a mathemetician or someone who writes crack programs. All I know is is that passwords will be tricked out of people in any number of ways, and used successfully once stolen, but failed login attempts should be limited to three attempts anyway and the IP address blocked after that until reset by the help desk, so this is all goofy stuff to me.

  rd

Will this impact private firms as well?

[Scothoser]

This is great news, and something that I wish a lot of companies would implement as well. What's really interesting is the comparison. I'm looking forward to the results, and see which vendor is chosen.

Of course, this brings up another question: Just how much is this going to cost the taxpayer? Granted, it should be spent regardless as government information about private citizens (i.e., social security numbers) should be protected at all costs, but if the final cost structure is less than many companies estimate, it could mean an implementation of this same scale across the business world. Imagine, no more calls or letters from your bank/credit union that your financial information and social security number has been stolen.

Re:Will this impact private firms as well?

[Qzukk]

Granted, it should be spent regardless as government information about private citizens (i.e., social security numbers) should be protected at all costs

Well, this should be fully analyzed to see whether it's actually going to protect anything, or whether it's just "Something must be done! This is something my brother who runs this one company told me about, therefore we must do it!" For instance, laptops are involved in the majority of data loss cases. If someone suspends a laptop and sets it down somewhere, will the OS purge the key from memory so that when Evil Dude picks it up he can't simply resume with full access to the drive? What about cases where people close the lid thinking the laptop will automatically hibernate, but for whatever reason it doesn't?

Here's a thought for you: how much would it cost me to get the government to quit putting sensitive information on so many laptops?

Re:Will this impact private firms as well?

[Trails]

Will this impact private firms as well?

Good question. I'd guess no. Part of the allure for the gov't in contracting out to private firms is that the gov't can delegate accountability to the contractor. "It wasn't our fault the terrorists/indentity thieves/Germans got the personal details of every registered voter/sex offender/childcare provider in Idaho, it's the fault of ACME Inc. They told us they were secure! It's right here in their sales pitch document! Let's lynch 'em!"

Re:Will this impact private firms as well?

[Geminii]

Because their VOIP passwords and mailmerge access have been stolen?

List of vendors

[Anonymous Coward]

Vendor POC Title POC Email Phone Number Mobile Website

Apptis, Inc. Bill Daus Sr. Manager, Business Development william.daus@apptis.com 703-272-7489 www.apptis.com
Apptis, Inc. Vic Jevsevar Business Development victor.jevsevar@apptis.com 239-283-1840
AT&T Kathy A. Ball Program Manager kball@att.com 443-259-8100
AT&T Government Solutions John C. Nagengast Director, Business Development nagengast@att.com 443-259-8366
Betis Group, Inc. Ron Hietala Director of Contracts RHietala@betis.com 703-532-2008
CDW•G Will Dolan Proposal Manager willdol@cdwg.com 703-262-8077
CipherOptics Corporation Jim Drain Federal Sales Director jim.drain@cipheroptics.com 703-547-7022
CipherOptics Corporation Mike Rose Federal Business Development Manager mike.rose@cipheroptics.com 301-432-0444
CREDANT Technologies Peter Morrison Dir Federal Operations pmorrison@Credant.com 703-282-6622
CREDANT Technologies Eric Hay Sr. Systems Engineer ehay@credant.com 703-517-0290
CREDANT Technologies Don Moran Account Executive dmoran@credant.com 703-969-7562
CREDANT Technologies Diane Pearson Sr Acct Exec dpearson@Credant.com 703-754-3778
David E. Sherrill & Associates David E. Sherrill President vsys2@comcast.net 703-481-4745 703-403-8582
Decru, Inc. Bill Harrison Account Executive, USAF billh@decru.com 703-499-6273 703-499-6273
Dell Inc. Joe Ayers Area Vice President joe_ayers@dell.com 703-622-3316
Encryption Solutions, Inc. Robert Cabanya Executive Director rcabanya@hotmail.com 484 824-1395 703 394-2362
Encryption Solutions, Inc. Kathy Powell Consultant KPowellConsults@aol.com 703-283-1175
EWA Chris Wickman Program mgr/Senior Analyst cwickman@ewa.com 571-283-5659
General Dynamics Julian Bubrouski Director of Engineering Julian.Bubrouski@gdc4s.com 781-455-3111
General Dynamics Deborah Cremin Business Development Manager Debbie.Cremin@gdc4s.com 781-455-5411
General Dynamics Ken Heist Business Development Manager ken.heist@gdc4s.com 410-487-0200
Green Hills John Warther Director of Government Programs john.warther@ghs.com 443-340-7881 443-340-7881
GuardianEdge Technologies Ray Ciesinski DOD Account Manager rayc@guardianedge.com 703-346-8777
GuardianEdge Technologies Andrew Oliver Senior Engineer aoliver@guardianedge.com 207-671-1127
GuardianEdge Technologies Dave Barrish Director, Channel Sales dbarrish@guardianedge.com 410-409-5839
GuardianEdge Technologies Bob McLernon Vice President rmclernon@guardianedge.com 240-818-8172
Harris Corporation Rick Blankenship Major Account Manager rblank02@harris.com 703-739-1932 703-303-0678
I.D. Rank Scott Cary Marketing Manager Scott@MTGC-Inc.us 877-566-2274
immixGroup Steve Limbert Senior Account Manager steve_limbert@immixgroup.com 703-752-0657 703-862-5194
immixGroup Steven Charles Co-Founder & EVP steve_charles@immixgroup.com 703-752-0630 301-332-0797
immixGroup Brian Begley Senior Account Manager brian_begley@immixgroup.com 703-752-0637 703-869-7201
infoLock Technologies Sean Steele CEO ssteele@infolocktech.com 703-310-6478
infoLock Technologies Chris Wargo President cwargo@infolocktech.com 703-310-7408
Information Security Corporation (ISC) Andy McDermott Vice President, Sales amcdermott@infoseccorp.com 585-370-3831
Information Security Corporation (ISC) Mike Markowitz Vice President, Technology markowitz@infoseccorp.com 708-445-1704
Ingrian Networks, Inc. Matt Fierce Federal Acct Manager mfierce@ingrian.com 703-597-2111
Ingrian Networks, Inc. Paul Earsy Distributed Encryption Specialist earsy@ingrian.com 508-308-3695
Ingrian Networks, Inc. Wayne Pambrun Director, Federal wpambrun@ingrian.com 703-655-4649
Intelligent Decisions, Inc. Gino Antonelli Executive Vice President gantonelli@intelligent.net 703-554-1610 703-203-5067
Intelligent Decisions, Inc. Harry Martin President

Why Full-Disk??

[EccentricAnomaly]

Why full disk encryption and not just the home directory?? Maybe things are so mixed up on Windows that you need full disk, but on OS X, Linux, and other Unixes it should be sufficient to encrypt only the home directory of users.

Are they just concentrating on a Windows-only solution that will lock out OS X and Linux??

As a government employee, I know there are a lot of people where I work who want to keep their Macs.

Re:Why Full-Disk??

[oohshiny]

Why full disk encryption and not just the home directory??

Because software frequently puts sensitive data in files outside your home directory.

Are they just concentrating on a Windows-only solution that will lock out OS X and Linux??

Linux supports full disk encryption. If OS X doesn't, well, it should, since home-directory-only encryption is not particularly secure.

Re:Why Full-Disk??

[RHIC]

What about page files/swap space, application generated temporary files etc. There are plenty of places that potentially sensitive information could leak into on just about any OS.

Re:Why Full-Disk??

[Anonymous Coward]

RTFA. The DoD wants support for flavors of Windows, Mac OS, Symbian, RIM & Linux.

Why not only home directories? - Because data can make its way anywhere. Better be safe than sorry.

Re:Why Full-Disk??

[BunnyClaws]

From the requirements listed it doesn't appear this is just for Windows systems. I would also disagree with just encrypting home directory of your users on Linux systems. If you are going to go with a software encryption on Linux you need to encrypt more than just the home directory.
That being said software encryption is just weak and doesn't even compare to FDE.

Re:Why Full-Disk??

[spellraiser]

Are they just concentrating on a Windows-only solution that will lock out OS X and Linux??

From the requirements:

SUPPORTED OPERATING SYSTEM, HARDWARE, FIRMWARE (NOTE: Vendors must support one or more of the following operating systems and it is important if you support multiple)

Microsoft Windows 2000
Microsoft Windows 2003
Microsoft Windows XP
Microsoft Windows Vista
Sun Open Solaris
Mac OS X
Windows Mobile 5.0
Windows CE
RIM/Blackberry
Palm
Symbian
Linux to include Red Hat, SuSE

Truth be told, this doesn't really say that much ... 'It is important if you support multiple' - what does that mean?

Re:Why Full-Disk??

[GodInHell]

Why full disk encryption and not just the home directory?? Maybe things are so mixed up on Windows that you need full disk, but on OS X, Linux, and other Unixes it should be sufficient to encrypt only the home directory of users. Sure, until some idiot user notices that placing his files in root makes them load marginally faster.. or on a share.. or in a memory dongel.. or in his e-mail.. stupid users... they ruin everything.

Seriously though, the less tech-saavy employees can be counted on to screw up through ignorance, and the tech-saavy will work around it because "they've got a good reason." People don't follow rules that aren't enforced - and on a PC that means all or nothing.

-GiH

Still think it's a pretty silly solution, but I can understand why it might appeal.

Re:Why Full-Disk??

[jasonmicron]

I seriously hope you were just trying to troll a little bit with that question.

Not everyone saves everything only in their home directories.

Re:Why Full-Disk??

[Anonymous Coward]

'It is important if you support multiple' - what does that mean? They mean multiple OS support is the same as an 'I' in column two, i.e.

IMPORTANT (I) - the capability is important so additional points will be assigned for products providing these capabilities

Re:Why Full-Disk??

[Blakey Rat]

The requirements call for multi-OS support. Also, there's virtual memory swap... it's not in the /home folder, (or \Documents And Settings or /Users) and it can quite easily contain sensitive information.

Re:Why Full-Disk??

[wonkavader]

Ok, on one hand, Yeah! WINDOWS SUCKS!

Ok, now that we have that out of our system, let's look at this logically.

The goverment is not planning on upgrading all their computers in order to do this. Neither are they planning to do some much, much harder: to verify that all the installed software is configured in such a way that it dosn't store information outside of the encrypted space, nor nail down systems so that their people cannot add software.

Yes, that would be much easier on Linux or OSX (or any just about any operating system) than on Windows. But it would be much, MUCH more labor intensive than their proposed solution no matter what OS they used.

What they're doing is a classic bad management decision which in a practical world is not an avoidable one. They're not spending the 40 hours per PC they need to now (utterly arbitraty number -- who really knows?) to change OS and apps, but spending an hour or less to do something which will slow down productivity (and increase data loss through hardware/user failure) for the life of the machine/employee.

What I'd like to see is a phase two of this project. Phase one, cripple everyone's machine so it's slow, but secure. Phase two, offer a program where you get a secured, fast laptop, where only one part is encrypted, but you can't boot it from anything but its one internal HD, can't single-user it, etc. can't add your own software, it phones home when it can to do centralized incremental backups of that secure area, patches, etc.

The second phase is harder and hits productivity more in the short term, but it makes a path where the machines and users get modernized, IT costs go way down, and in order to escape the sluggishness of the phase one change, some users will actually want this phase two solution. User buy in is the real key to such changes. If you don't get them to volunteer, they'll deliberately sabotage the project.

This whole thing is not a bad decision. Yet. If they install this on 486s and the machines turn into molassas, and they blunder forward on policy, such that workable machines become unworkable, and they don't upgrade them, such that people don't have computers, anymore, really... THEN, this will be a very bad decision.

Re:Why Full-Disk??

[Splab]

Because software frequently puts sensitive data in files outside your home directory.

Never mind the software, what about the users? I work for a small organization, and users drop sensitive information all over their drives, depending on when they started working with computers and what kind of habits they acquired, Documents and settings is a fairly new concept.

Re:Why Full-Disk??

[throx]

Why full disk encryption and not just the home directory?? Maybe things are so mixed up on Windows that you need full disk, but on OS X, Linux, and other Unixes it should be sufficient to encrypt only the home directory of users.

Yes, Windows is rather mixed up but *nix puts sensitive data outside the home directories all the time. Take the following examples:

• /var/log has dozens of email addresses, all sorts of handy info on networking connections etc.
• Databases can exist pretty much anywhere, though usually in /var. These are where the real data leaks happen anyway, not in ~.
• Consider a laptop that you just have access to for long enough to install a rootkit (using a boot cd)?

There's lots of good arguments for full disk encryption. The downsides are:

i) Key management and authentication. A USB dongle that you can lose along with the laptop, or a password policy that encourages people to tape post-its to their machines defeats any advantage.
ii) Retrofitting. Full disk encryption really requires BIOS level support in the true sense of the word.

Re:Why Full-Disk??

[Anonymous Coward]

This is not a management decision, it is a technical decision, at least for the security-minded. While it may have come from the big boss, a lot of us have been pushing this for some time. FDE is the only proper way to go here, and it isn't as slow as you think. I'm running it now on a 4+ year old laptop. I just hope we pick a decent system, some of the FDE products are very lacking or add useless features (single sign-on, easy password recovery).

Re:Why Full-Disk??

[jrockway]

Full-Disk encryption isn't slow. Performing the decryption is much faster than waiting for an IO buffer to be filled from disk.

Re:Why Full-Disk??

[PPH]

Hey, as long as I can still have my USB drive (unencrypted), I'm happy.

Re:Why Full-Disk??

[Fred_A]

In most orgs nowadays users no longer have admin rights on their machines and therefore cannot write outside of their $HOME (or whatever it's called in Windows). Granted there are still lots of places where this basic security policy isn't implemented but they are thankfully fewer every day (although their number will likely never drop to zero).

However as other contributors rightly pointed out, /tmp and the swap file(s) are two problematic areas that should be addressed by a comprehensive cryptographic solution. I wouldn't be surprised if several Windows products neglected to encrypt those.

Re:Why Full-Disk??

[NineNine]

Maybe things are so mixed up on Windows that you need full disk, but on OS X, Linux, and other Unixes it should be sufficient to encrypt only the home directory of users.

should be? You gonna personally guarantee that every possible Linux and Mac application store all of their information in the same place? If we're talking "should be"'s, then there wouldn't be this problem in the first place, because no sensitive data should be stored on laptops that walk out of buildings. "Should be" is what causes these problems in the first place.

Re:Why Full-Disk??

[Anonymous Coward]

They can still write new files to/create new directories in the root directory on Windows.

Re:Why Full-Disk??

[cygnus]

is it just me, or are the first four just versions of the same operating system? and is there really a big difference between windows mobile 5 and windows ce? but os x is one version, not 4, and linux is this one catchall category that includes every version of every distro.

Re:Why Full-Disk??

[Chazmyrr]

One of the requirements is to use DoD CAC cards for authentication. There are some substanial differences in the way smart cards are handled across versions of Windows or even across Service Packs. Most DoD computers run some version of Windows. It's understandable that they are more concerned with which versions of Windows are supported than other operating systems.

Re:Why Full-Disk??

[asuffield]

Inanely, a default Windows install permits everybody to write files anywhere outside \windows, \progra~1, and \docume~1, regardless of admin rights. You have to change the filesystem ACLs by hand to fix this stupidity. Most Windows "admins" don't know about it, so they don't fix it.

Re:Why Full-Disk??

[cduffy]

Not a troll. If your system is appropriately configured, you (and your applications) won't be *allowed* to save things anywhere on the local drive other than your home directory. Temp and swap space are also good candidates for encryption -- but putting temp space in a ramdisk and encrypting swap is a pretty reasonable way to do this. Anything other than those should be code, not data -- and thus nonsensitive. Why spend the cycles to encrypt and decrypt without a need to do so?

All that said, I think that giving a contract like this to a commercial vendor developing proprietary software would be... unfortunate. Funding addition of missing, necessary features to TrueCrypt would be a one-time expense (rather than one which scales with the number of systems deployed), and would benefit the private sector as well.

Re:Why Full-Disk??

[p3w-451]

Do any programs break if you do that?

Re:Why Full-Disk??

[Jugalator]

Why full disk encryption and not just the home directory?? Maybe things are so mixed up on Windows that you need full disk,

Windows? Home directories? Just kidding :) The directory specified by %USERPROFILE% is indeed the user's home directory, and in Vista, users are even more enforced to put stuff there, since there'll be UAC prompts if you place things elsewhere, then affecting the local system rather than just your own user. However, it's long been such an assumption that "everyone" on Windows is running admin rights, and apps are so sloppily coded that both applications and games tend to assume they can place their crap just about anywhere. MS has tried to move away from this behavior with their "Designed for Windows XP" logo program, but I guess that didn't help very much either. :-) Devs just didn't care for "Designed for XP" stickers enough.

Re:Why Full-Disk??

[mlts]

BIOS support merely adds features, such as how TPM 1.2 support allows Vista's BitLocker to allow for a PIN rather than a password. Guess the PIN wrong 3 times, BitLocker goes into locked mode, requiring the full key to be typed in. The hardest part about FDE is getting the drivers into the OS and ensuring that OS patches don't mess with the driver stack that converts read/written plaintext blocks into cyphertext blocks on the HDD.

Re:Why Full-Disk??

[DamnStupidElf]

Why full disk encryption and not just the home directory?? Maybe things are so mixed up on Windows that you need full disk, but on OS X, Linux, and other Unixes it should be sufficient to encrypt only the home directory of users.

C:\Windows\Temp, the swap file, and the registry are some good examples. On Unix, what about /tmp and /var/{log,spool}? There are many places that sensitive data can end up that aren't under /home or Documents and Settings. Furthermore, if the system volume is not encrypted it is very easy to insert trojans or other malware into the operating system while the computer is offline. Either pulling the drive and modifying it or just booting the computer from USB or CD gives an attacker full control over the computer and its data once the authorized user logs back on.

Re:Why Full-Disk??

[mr_mischief]

/var/log contains lots of email addresses on a mail server. Why would someone concerned about security let an end user run their own personal mail server on an agency laptop? Network connections can be set not to be logged, or to be logged somewhere else. A syslog daemon that does encryption isn't that hard, either.

Databases can only be placed where the user has rights to place them. The end-user of an agency laptop shouldn't even be the one setting up the DB software anyway. The directory containing the database files could be encrypted, or a database/database application that only stores encrypted data could be used.

So, I have a rootkit, and I'm now an admin. That doesn't give me access to a directory that's encrypted with a key from a smartcard or a remote server.

Still, full-disk encryption gets past all these little gotchas. It'd be great to see this accomplished this way:

1. have a small OS in non-flash ROM
2. the OS in ROM gets the key from the card/central server
3. have this OS decrypt the kernel from the encrypted partition into memory
4. pass the encryption key data to the now memory-resident kernel and hand it control of the system
5. the main OS kernel mounts the partition

I'm thinking LinuxBIOS, or maybe something based on OpenFirmware for the ROMable boot loader that handles decryption. TPM support is listed as a nice-to-have in the requirement document, BTW. That may actually be useful in this type of scenario -- use the TPM controller to help with the decryption and the storage of a PC-specific key in addition to the smartcard/central key server.

Re: Why Full-Disk??

[Black Parrot]

> Why full disk encryption and not just the home directory?? Maybe things are so mixed up on Windows that you need full disk, but on OS X, Linux, and other Unixes it should be sufficient to encrypt only the home directory of users.

No, you also need /var, /tmp, and your swap partitions (or the partitions your swap files are on), and any other directories/partitions where data is stored, even temporarily.

FWIW, you can now do this pretty easily with dm-crypt, though I can't remember whether it encrypts everything or just the data. (Some systems leave e.g. the filenames unincrypted.)

Re:Why Full-Disk??

[Splab]

Our system gives users basic rights, but they are certainly not admins, but they still have the "power" to write most places on the drive. (Windows XP).

Re: Why Full-Disk??

[Black Parrot]

> Not a troll. If your system is appropriately configured, you (and your applications) won't be *allowed* to save things anywhere on the local drive other than your home directory.

No, unless it's a personal application, its data should not be in your personal directory tree.

Re: Why Full-Disk??

[cduffy]

What do you mean, a "personal application"? Is that as opposed to an application installed or used for work-related purposes, or as opposed to an application installed for use by all folks with access to the system?

There are two scenarios that make sense:

- Application stores data on the other end of a network. Requires a net connection; doesn't make sense when you're working from a customer site or from home.

- Application stores data under home directory. File's (or directory's) owner may have permissions set to allow other users to read or write.

Any other scenario requires that an arbitrary, user-invoked application have write access to parts of the hard drive which are not under the user's home directory, which Just Shouldn't Happen. Even in cases (like databases) where files are owned and controlled by a daemon -- that daemon can darned well store its data under a home directory of its own on the encrypted partition; in this way, a daemon should be treated no differently from any other user. Obviously, the application code won't be encrypted -- but this action is in response to high-profile cases of data being lost; I haven't heard any situations from the public sector where there's been a particularly big fuss made about a proprietary binary getting into the wild.

There's a reason that modern versions of Windows have caught up with ancient versions of UNIX in requiring applications to store data under "Documents and Settings\<Username>\Application Data" (~/.<app> in UNIX, of course) when running as non-administrator and preventing access to HKEY_LOCAL_MACHINE (/etc). Doing anything else is stupid: It allows users to step on each others' toes or to change the operation of the system as a whole in a way that can't be reversed simply be wiping their home directory or restoring it from backup. In a security-conscious environment, this just isn't a good situation to have as standard operating procedure.

I'm referring, btw, only to dynamic data -- that which can be created or modified through user's actions. Static data required for a piece of software to operate, loaded at install-time and never modified thereafter typically has no need to be encrypted at all; it can be safely considered part of the software for such purposes. Data loaded at software install time and later user-modified, on the other hand, can have the modifications stored under the user-owned part of the filesystem tree, providing (again) for reversion to initial state simply by wiping the user account. It's the clean, obvious Right Way to do things -- and static data is almost never under the same kind of confidentiality requirements that dynamic data is. (If you're an IRS auditor, the information about the auditee you load before going on-site are dynamic; it thus has its rightful place under your home directory, and thus will be encrypted).

Re:Why Full-Disk??

[ClickOnThis]

'It is important if you support multiple' - what does that mean?

My guess: they want to reduce support costs by having common solutions for multiple platforms as much as possible. Of course there are arguments against this (e.g., fewer implementations of a solution create a more fragile software ecosystem.)

Re:Why Full-Disk??

[throx]

I'd imagine running a mail server on a laptop would be useful for sending mail when disconnected from the network. At least, that's why I use sendmail on my laptops. Remember, these people are concerned with quick fixes that don't reduce remote functionality - not reducing the laptops to a minimal install and minimal functionality.

Databases can be placed anywhere the account that the database server is running as has the rights to put them. I sure don't have access to /var/mysql on my laptop (as a regular user) but I can access databases just fine. It's that whole client/server model thing that lets this happen. Yes, you could encrypt them on a case by case basis, but full disk encryption guarantees that you catch everything.

If you have a rootkit and are admin you can just sniff whatever the user is doing. Smartcard doesn't help you there. Seriously, once you're root then ANYTHING that goes through the laptop is compromised.

I think the TPM solution is useful and shows the real use behind the TPM: corporate machines where it's clear the end user doesn't own the machine but is just an unprivileged user. I know the bitlocker stuff on Vista uses the TPM for full disk encryption, so seeing a *nix implementation of the same can't be hard to find.

Re:Why Full-Disk??

[asuffield]

Yes. You may have to spend time carefully crafting ACLs that will work with the programs you need to run. Some programs just don't support the concept of a multi-user system at all.

Such programs are nominally broken for causing this. If you want to get this working, you have to incorporate it into your approval process before buying new software (ie, don't buy stuff that won't work with it).

Re:Why Full-Disk??

[mr_mischief]

Yeah, running a mail server could be useful on a laptop, but I'm sure the Windows ones don't queue mail. Why should the Linux ones? /var could be one of the partitions that's encrypted as a partition.

The database server should be running setuid to the uid of the user on a single-user laptop where security is a top concern. The databases should be in ~/mysql or similar.

Having a rootkit to install while the smartcard is in the system lets you snoop what the user is doing. Having a rootkit to install while the smartcard is out of the machine gives you the ability to snoop the fact that the data you want is unable to be mounted and decrypted. A rootkit installed with the smartcard could give one the ability to send the data through the network or write the encrypted data of interest to the unencrypted portions of the disk for later. A rootkit without the smartcard still does squat unless the partition/file you need the key for has the key.

I'd be tempted to do full file system instead of file-by-file or full disk. Have a root directory read-only on one partition, and a data partition with encrypted loopback files for /var, /home, and possibly /usr (in case you have any super-secret software). That would make it easy to move the data to a new machine while keeping it encrypted, yet allows you to deal with a few big units instead of thousands of small ones. I'm not sure the disk partitioning utilities are yet up to imaging encrypted partitions other than byte-by-byte.

Re:Why Full-Disk??

[wonkavader]

And most access will be read (decryption) as opposed to writes (encryption) but I have to assume (please correct me) that the encryption phase is much slower than decryption.

And even if decryption isn't slow, it's an addition, unless there's compression involved, here too, in which case you're waiting for less IO. Is it a tangible slowdown, firstly, and is there compression, secondly?

Can you talk about any or all of these three points? I'm interested in knowing more.

Excel?!? Bah!

[Anonymous Coward]

The list of competetors:
Apptis, Inc.
AT&T
AT&T Government Solutions
Betis Group, Inc.
CDWG
CipherOptics Corporation
CREDANT Technologies
David E. Sherrill & Associates
Decru, Inc.
Dell Inc.
Encryption Solutions, Inc.
EWA
General Dynamics
Green Hills
GuardianEdge Technologies
Harris Corporation
I.D. Rank
immixGroup
infoLock Technologies
Information Security Corporation (ISC)
Intelligent Decisions, Inc.
Kanguru Solutions
L-3 Communications
Liquid Machines
Mary Fuller & Associates, LLC
McAfee, Inc.
Meganet Corporation
Merlin International, Inc.
Microsoft Corporation
MITA Group
Mobile Armor
NetApp
Onix Networking Corp.
Plans, Programs & Policy (P3) Consulting LLC.
PointSec Mobile Technologies
Progeny Systems Corporation
Rocky Mountain Ram
SafeNet
Seagate Technology
SolCent Corporation
Sprint Nextel
SPYRUS, Inc
Sybase, Inc.
TECHSOFT, Inc
Telos
Trust Digital
ViaSat
Vormetric, Inc.
Wave Systems Corp
Zelinger Associates, Inc.

A couple points

[HBI]

1. It's only a recommendation. Read it carefully.

2. DoD was already doing something with this but in its normal -very slow- manner. I don't expect it to be fully implemented for a couple years yet.

Shotgun

[Anonymous Coward]

To address the issue of data leaks of the kind we've seen so often in the last year because of stolen or missing laptops, writes Saqib Ali, the Feds are planning to use Full Disk Encryption (FDE) on all Government-owned computers.

Typical shotgun approach.

In the FAA each technician uses a laptop to document maintenance. In a addition, there may be a few terminal applications to communicate with equipment. Nothing secret or sensitive in there. A dual key password system is already in-place to upload logs to the central database, which is only accessible via the agency intranet anyway.

Believe me, these machines are already performance slaggards even without full-disk encryption.

Re:Shotgun

[SatanicPuppy]

I was thinking about that. Every time I've had to do government work, I've been surprised at how many obsolescent pos's I see lying around in their data centers.

Are they going to push a hardware/software upgrade to get everything to a level where it can even run this stuff? Seems like a total waste. They need to virtualize, and they need to move things off local machines.

I predict

[yagu]

I predict the government will lose more data this way than when storing data unencrypted. And, when they lose it this way, they won't be able to get it back. At least when they lose a stolen laptop and get it back, they usually still get their data.

And, stealing laptops isn't how people are trying to steal data from the government... stealing laptops is how people are trying to steal laptops. Those going after government data have better ways to approach it than stealing laptops.

So, when the government starts losing keys, and not finding anyone with the master key, we the people lose data. Hope it's not too important.

OTOH, the list of requirements is interesting... but, I remember the day of artificially created drives to save space on what used to be the precious commodity of hard drive storage. Can't remember the name of the product but it basically created a large blob on your drive and managed it transparently and compressed data into that blob. Of course that was fine until the first minor corruption.

Wouldn't it seem encryption is similar? It's hard enough to maintain perfect integrity with unperturbed data, what extra risk to failure does encryption introduce? There are so many points of potential corruption and failure: improper use (procedural); software bug introducing corruption; loss of keys resulting in lockout from data; incompatibilities with patches (regression testing for that is nice, but can't be perfect).

I'm not sure this is something the government can pull off.

Re:I predict

[SQL Error]

I predict the government will lose more data this way than when storing data unencrypted. And, when they lose it this way, they won't be able to get it back. At least when they lose a stolen laptop and get it back, they usually still get their data.

The data isn't supposed to be on the laptops in the first place.

Re:I predict

[jofny]

And, when they lose it this way, they won't be able to get it back. Yeah, but no one else will get it either. Fail Closed vs Fail Open.

Those going after government data have better ways to approach it than stealing laptops. This is true, but why open yourself up to dumb mistakes as well as targeted attacks? If you can just grab unencrypted data, why bother using something more complex to get it? Limit exposure. Besides, public opinion and CNN are huge drivers for the government, whether Slashdot (the plural) realizes it or not. If someone loses an unencrypted laptop and it makes the news, the media and people bemoan the lack of security...whether the losses are a real actual threat or not. If the data is encrypted, the government can at least focus on real threats instead of having to contend with (and be distracted by) uninformed public outcries as well.

Re:I predict

[Splab]

Users should never ever have sensitive information on their laptop unless it's encrypted. And important data should NEVER EVER! only exist in one place. So if the laptop is lost with encrypted data, you lost a laptop, easy to replace and you just reload the information. If you on the other hand lose a laptop with unencrypted sensitive information you got all sorts of bad problems, ranging from stolen ID to blackmail and espionage.

Not only should they be able to pull it off, someone should be fired for not having this in place already.

Re:I predict

[PPH]

If we want to steal information from someone in the gov't, we are going to have to go back to backmailing them with photos of their romps with teenage boys rather than stealing their laptops.

Re:I predict

[Anonymous Coward]

I predict the government will lose more data this way than when storing data unencrypted. And, when they lose it this way, they won't be able to get it back. At least when they lose a stolen laptop and get it back, they usually still get their data.

Anything important that originates from the laptop should already be backed up, and anything else can be retrieved from another source.

And, stealing laptops isn't how people are trying to steal data from the government... stealing laptops is how people are trying to steal laptops. Those going after government data have better ways to approach it than stealing laptops.

But they still get the sensitive data when they steal the laptops. This isn't aimed at stopping enemy agents, it is aimed at accidental loss of sensitive data, which can be just as damaging and even more embarrassing.

Key Escrow is a requirement

[dilute]

Note that in the requirements doc, one of the requirements is:

"Capable of secure escrow and recovery of the symetric [sic] encryption key"

Re:Key Escrow is a requirement

[meringuoid]

Note that in the requirements doc, one of the requirements is: "Capable of secure escrow and recovery of the symetric [sic] encryption key"

Obviously. What they want is:

1) Halfwit employee loses laptop. Finder cannot recover data.

2) Halfwit employee forgets password. Government can recover data.

Re:Key Escrow is a requirement

[dilute]

And a dishonest employee with the recovery key can compromise a large number of machines.

This is a no brainer!!! Try these:

[Anonymous Coward]

I've been doing it for years on my deskie and lappy. I mean, why wouldn't you?
You can travel or leave your Pc on without the worry of script kiddies on a borrowed trojan cavalry:

Here's a freeware package working under Linux and Windows.
I've been using them both for years. Never lost an bit of data:
Command line, but easy anyway:

http://www.scherrer.cc/crypt/

Also PGP has encrypted volumes with a nice GUI, though not sure if it's still free.
They yanked it a few years ago which is why I went to ccrypt.

Have been a few others I've looked at, but the above cover the field nicely.

Re:This is a no brainer!!! Try these:

[Lawrence_Bird]

I have been using this on my laptop; its free and seems to work well with no noticable
loss of speed.

http://www.freeotfe.org/docs/index.htm

Sid by side competition?

[MrTester]

Let me guess. The contract goes too....

Halliburtons new encryption subsidary.

Founded in 2006 by some guy who read a book on encryption.

Re:Sid by side competition?

[MrTester]

I am very sorry if my lack of grammer offended you.
I am very busy at work and suffer under the delusion that the idea of electronic communication is to get ones point accross and not to have it reviewed for grammer, spelling or punctuation or to be saved for posterity.

Just for the record, your paragraphs are too short, you did not reference your source material, and, oh-by-the-way, you (I guess I should say "we" now) are off topic.

Re:Sid by side competition?

[Anonymous Coward]

He did go to school in the USA that's why he is not a native English speaker. USA schools do not teach anymore. They indoctrinate like madrases!

'No Child Left Behind' means everyone gets taught at the same level as a class moron - Black from The Daily Show.

Re:Sid by side competition?

[Anonymous Coward]

I am very busy at work and suffer under the delusion that the idea of electronic communication is to get ones [sic] point accross and not to have it reviewed for grammer, [sic] spelling or punctuation or to be saved for posterity.

You mean "one's" and "grammar".

Re:Sid by side competition?

[jank1887]

and I won't even go into the usage issue with the word "one's"

Re:Sid by side competition?

[Anonymous Coward]

I believe that the point is that if one can't write clearly and correctly, one is effectively broadcasting the message, "I am an idiot, and it will take you extra time to understand any point I am trying to make. But since I'm an idiot, it likely isn't worth your time trying to make sense of the contents of my post anyway".

Or, to put it more succinctly: "Don't bother to read what I write".

You might not like that this happens, but it does.

If you don't mind people thinking any of the above, then go ahead and post without paying attention to detail.

Re:Sid by side competition?

[RAMMS EIN]

``Founded in 2006 by some guy who read a book on encryption.''

That would be at least something. Many security products (especially the so-called unbreakable ones) are made by people who obviously have no idea about encryption.

Re:Sid by side competition?

[kcbrown]

I am very busy at work and suffer under the delusion that the idea of electronic communication is to get ones point accross and not to have it reviewed for grammer, spelling or punctuation or to be saved for posterity.

Unfortunately, grammar, spelling, and punctuation all have an effect on how well you get your point across because they all contribute to the clarity of the communication. I'm not saying that if you have perfect grammar, spelling, and punctuation, that your point will magically come across clearly or anything, but rather that without those things your point will not come across as clearly as it would otherwise. Such is the nature of written communication, electronic or not.

All I can do is to encourage you and others to proofread your writings before firing them off. You might not catch all the errors but you will catch some, and you may even find that the effort improves your ability to write correctly the first time. That will be especially valuable to you when you find yourself having to write a document in a professional capacity.

Finally (and perhaps unfortunately), you might want to reexamine your thoughts about your electronic communications being saved for posterity. Chances are they will be, whether you want them to be or not. It's probably best to operate under the assumption that whatever you say will basically live forever. It's certainly best to write software that way. :-)

Re:Sid by side competition?

[mlts]

If someone read Applied Cryptography or another text, then put concepts learned into practice, I wouldn't mind using a product made from them.

What gets me is that PGP isn't competing for this DoD bid. Of all the FDE solutions I have used, I like PGP's because it offers not just a PKI, but an open, standardized PKI that has stood the test of time. This is not to say that other FDE software isn't good. Safeboot, SecureDoc, DriveCrypt, and CompuSec are all very good solutions too.

What is funny is that FDE solutions have been around a long time, almost to the days of PGP 1.0. In 1990, Casady and Greene had a program called A. M. E. (Access Managed Environment) for the Mac that would DES encrypt every sector on the hard disk. FWB also had a solution using their Hard Disk Toolkit for partition encryption on the driver level (only used 2 DES rounds though.)

Re:Sid by side competition?

[RealGrouchy]

Let me guess. The contract goes too....

Halliburtons new encryption subsidary.

Founded in 2006 by some guy who read a book on encryption.

Jeez! Give the man a break, he's over 70 and he just resigned his second term as Secretary of Defense. He needs something to do to profit off of it!

- RG>

Re:Sid by side competition?

[Vitriol Angst]

Why is this +5 Funny?

There should be a moderation setting for "+5 Scary/True."

Of course, the job will have to go to Incite! the Bush family software company that sells to Kaplan and Saudi Arabia. Leaving no "conflict of interest" behind.

Re:Sid by side competition?

[rohan972]

Don't pey attention to grammar nahtzees, if they can't spell a wird moor than wun whey, that's thair problem.

Re:Sid by side competition?

[Anonymous Coward]

Founded in 2006 by some guy who read a book on encryption.

I can just see it now...

Government agent flips through a manual... "Look! With teh Vista you can encrypt hard disks now! Huhuhuhuhu!"

Hey, Government!

[Rob T Firefly]

You've got to check out my hot new encryption scheme, I call it Rotational Oscillating Telecode no. 13. Fill your tubes with this stuff and I personally guarantee it foolproof against criminals and terrorists and journalists in every single test performed in my personal data-protection laboratory (my basement) with highly alert and cunning test subjects (my cats.)

Bidding starts at $47 Million.

Re:Hey, Government!

[UncleTogie]

Your name isn't Brutus, is it?

Re:Hey, Government!

[cain]

ObReply:

Mine, ROT 26, is twice as secure and I'll charge you only half as much.

Re:Hey, Government!

[Lucan Varo]

Rotational Oscillating Telecode no. 13 is obsolete you need number 26!

Re:Hey, Government!

[Anonymous Coward]

I personally guarantee it foolproof against criminals and terrorists and journalists

Sadly, it's probably true....

List as Text

[Anonymous Coward]

Apptis, Inc.
AT&T
AT&T Government Solutions
Betis Group, Inc.
CDWG
CipherOptics Corporation
CREDANT Technologies
David E. Sherrill & Associates
Decru, Inc.
Dell Inc.
Encryption Solutions, Inc.
EWA
General Dynamics
Green Hills
GuardianEdge Technologies
Halliburton Data Security
Harris Corporation
I.D. Rank
immixGroup
infoLock Technologies
Information Security Corporation (ISC)
Ingrian Networks, Inc.
Intelligent Decisions, Inc.
Kanguru Solutions
L-3 Communications
Liquid Machines
Mary Fuller & Associates, LLC
McAfee, Inc.
Meganet Corporation
Merlin International, Inc.
Microsoft Corporation
MITA Group
Mobile Armor
NetApp
Onix Networking Corp.
Plans, Programs & Policy (P3) Consulting LLC.
PointSec Mobile Technologies
Progeny Systems Corporation
Rocky Mountain Ram
SafeNet
SCO
Seagate Technology
SolCent Corporation\
Sprint Nextel
SPYRUS, Inc
Sybase, Inc.
TECHSOFT, Inc
Telos,
Trust Digital,
ViaSat
Vormetric, Inc.
Wave Systems Corp,
Zelinger Associates, Inc.

Re:List as Text

[thePowerOfGrayskull]

[quote]SCO[/quote] Now there's a name we can all trust.

Re:List as Text

[DSW-128]

Halliburton is on the list? If I wore a tin foil hat, I'd say the competition is rigged. But with MS also on the list, and no Diebold, ya gotta wonder - how will things pan out? Lots of evility abounds.

What for?

[Opportunist]

As long as any corp or fed agency with any threadbare reason can have access to the data, why bother encrpyting it?

Oh, right, so the peasants won't... Ok, I'll shut up now, I got it.

Oh my

[ewhenn]

In an unpredictable move the Bush administration has awarded the contract to.... Halliburton.

Damn the Spam!

[Anonymous Coward]

I guess all of those e-mail addresses were public anyway.

Maybe they should have encrypted the list for protection. Encryption solves everything after all.

Re:Damn the Spam!

[jimstapleton]

I still feel sorry for them? How many calls are they gonna get from slashdotters complaing that the files are not in an open format?

I know the people who's numbers are listed aren't responsible, but you can be sure there will be a number who act first, think later.

IT'S ABOUT FREAKING TIME!

[Crudely_Indecent]

It's not about having something to hide, it's about protecting the info present within. How many gov't laptops containing personal information of citizens or groups have been stolen in recent history?

Large corporations that deal with private data from their customers should also be required to use full-disk encryption as well. In fact, I recommend some form of encryption for sensitive data to everyone.

But if users don't run as Administrators

[EccentricAnomaly]

Because software frequently puts sensitive data in files outside your home directory.

If users don't run as administrators this can't happen. And I don't know of any Linux app that puts stuff outside home... and only a few Macs app do (and none should)

Re:But if users don't run as Administrators

[amliebsch]

What about system databases? What about swap?

Re:But if users don't run as Administrators

[Anonymous Coward]

Ever heard of /tmp?

Re:But if users don't run as Administrators

[BunnyClaws]

Swap, data is passed through swap and not just admins will push sensitive information through it.

Re:But if users don't run as Administrators

[DrScotsman]

And I don't know of any Linux app that puts stuff outside home...

So I take it everything in your /tmp directory is owned by root, yeah?

Re:But if users don't run as Administrators

[KonoWatakushi]

What sort of system databases are you concerned about? Passwd? Locate? The latter could be an an issue if it indexed home directories, but it usually doesn't. In fact, I can't think of anything critical on a typical desktop machine.

Most decent OSs provide encrypted swap, so that is not an issue.

Re:But if users don't run as Administrators

[Anonymous Coward]

If users don't run as administrators this can't happen.

Wrong. Swap, /tmp, and /usr/tmp all contain user data, as does /var and other locations used by system daemons.

And I don't know of any Linux app that puts stuff outside home...

That's merely a testament to your ignorance.

and only a few Macs app do

The Mac is no different in that regard from UNIX.

(and none should)

They don't have a choice; it's part of normal operations. It happens even if they don't explicitly open any files themselves.

Re:But if users don't run as Administrators

[asuffield]

Swap encryption is handled differently, because it's more secure this way: at boot, the OS generates a random encryption key. This key is held in memory and never written to disk or displayed to the user. It's used to create a fresh encrypted swap area. When you switch the computer off, it's gone. When you boot it next time, it creates a new key. Absolutely no way to recover any data from an old swap image.

Re:But if users don't run as Administrators

[asuffield]

Swap, /tmp, and /usr/tmp all contain user data

Swap is encrypted on its own, in a smarter way. /tmp is held in memory and never written to the disk (if appropriately configured) - and anyway, nothing should be writing sensitive data there. What kind of fucked up unix has a /usr/tmp? That's just wrong. Stop using it. /usr is a read-only filesystem.

Re:But if users don't run as Administrators

[really?]

Of course it is. But I always log in as root, 'cause if I don't the system always bitches about "Only root can do that." Never used to have this problem in Windows. :-)

Re:But if users don't run as Administrators

[Nasarius]

What kind of fucked up unix has a /usr/tmp? That's just wrong. Stop using it. /usr is a read-only filesystem.

GP probably meant /var/tmp, but otherwise I agree with you. The idea is that a secure Unix system should have RO partitions and directories that are pointless to encrypt. And there's nothing wrong with pointing apps to ~/.tmp instead of /tmp.

Re:But if users don't run as Administrators

[Anonymous Coward]

Swap is encrypted on its own, in a smarter way.

Bullshit. /tmp is held in memory and never written to the disk (if appropriately configured)

Bullshit. Not only is that not the case on most systems, it's a lousy idea.

What kind of fucked up unix has a /usr/tmp?

Historically, just about every UNIX system. On other systems, it's /var/tmp or somewhere else; the effect is the same. /usr is a read-only filesystem.

In recent years, many distributions have made /usr read-only. Historically, /usr was what /home is today. But people created /var instead.

Again, in addition to all that, there are keys and networking info in /etc and /usr/etc, log info in /var/log, and databases in /var, /usr, and other /home directories; those may, in fact, contain a lot of the sensitive information on the machine.

Overall, the fact remains: no matter which particular directory layout your UNIX system happens to use, you're a moron if you think that encrypting your home directory is sufficient for keeping private data private. Whole disk encryption is necessary.

Gee, I wonder Who Will Get It ?

[el cisne]

My Sense May Seem MoStly MiStaken, but no MyStery outcoMeS ManifeSt theMSelves.

Re:Gee, I wonder Who Will Get It ?

[cain]

I think you may be MStaken. Halliburton is on the list.

Four easy steps

[VP]

1. Make VMWare Player work on OpenBSD
2. Install OpenBSD on all government desktops and laptops.
3. Users who need a different OS, get an image of it, and run it with VMWare Player.
4. Profit!

Re:Four easy steps

[YrWrstNtmr]

1. Make VMWare Player work on OpenBSD
2. Install OpenBSD on all government desktops and laptops.
3. Users who need a different OS, get an image of it, and run it with VMWare Player.
4. Profit!

Whee! And we can all be driving biodiesel cars next week.
Oh please. Do you have any idea how long it would take to convert even one major US Govt department from Windows to [anything else]? This is not your mom's basement.

Re:Four easy steps

[kwilliam]

What does that have to do with encryption? Are virtual machines encrypted, or are you just advocating OpenBSD?

Re:Four easy steps

[Anonymous Coward]

Qemu already works on OpenBSD, so your plan can immediately be put into action.

Re:Four easy steps

[VP]

What does that have to do with encryption? Are virtual machines encrypted, or are you just advocating OpenBSD?

OpenBSD's main focus is security. Among its many security features is complete disk encryption (including encryption of the swap partition). The virtual machine is there so that users can run Windows, MacOS, Linux, whatever - they don't have to know anything about OpenBSD itself...

Re:Four easy steps

[VP]

Whee! And we can all be driving biodiesel cars next week.
Oh please. Do you have any idea how long it would take to convert even one major US Govt department from Windows to [anything else]? This is not your mom's basement. There is no need to convert anything, except few of the procedures a large IT organization would follow anyway. Any large IT shop would have standard images that are put on the hard drives of the desktops or laptops they support. An image that has OpenBSD with disk encryption enabled, and setup to load the VMWare player with a standard Windows install, will require no more work to setup than a native Windows image. There is some upfront and maintenance work that would be required, but it would be done by dedicated IT staff that can easily be educated in supporting OpenBSD (after all, there are a lot of government agancies that run at least some flavor of Unix or Linux). This is one place, where the economy of scale of the federal government can pay off...

Re:Four easy steps

[mandelbr0t]

Riiiight. The US government is going to offer a multi-billion dollar contract of the highest national security importance to a project that's run by one guy... ...and he's Canadian.

Not that I'd complain about having Canadians managing American national security, but somehow I don't see it happening.

mandelbr0t

Re:Four easy steps

[VP]

Why do you think the project needs to be run by the OpenBSD developers? There are plenty of US companies who specialize in providing secure solutions based on OpenBSD.

Re:Four easy steps

[Slashcrap]

1. Make VMWare Player work on OpenBSD

I bet that would be pretty difficult precisely because of the security features of OpenBSD. I bet you that VMWare uses all kinds of nasty tricks like self modifying code and executable data that would make the OpenBSD kernel (and Theo) shit itself in disgust.

Security > Convenience does have consequences.

Re:Four easy steps

[VP]

Finally a reasonable argument against my "suggestion" (which was meant mostly as a joke)...

I thought...

[Ingolfke]

information wanted to be free?

Re:I thought...

[Anonymous Coward]

mmmm.... yes, information wants to be free... and that is exactly why some people don't want it to be free: the one who controls information controls the world.

Re:I thought...

[jrockway]

It does, which is why much effort (encryption) is required to keep it non-free.

Re:I thought...

[Ingolfke]

What's your social security number and home address?

Re:I thought...

[jrockway]

You misunderstood my comment.

My point was: it's easy for you to get that information if I don't make an effort to keep it away from you. If I tell you, then everybody will eventually know.

You wanting some information to be free and "information wants to be free" are two completely different concepts.

No middle ground

[GodInHell]

This has that sick feeling of a joke a tech threw out on the table to show a beurocrat that he was being stupid - only to have the beaurocrat say "we can do that!"

Still, I wish them well with their (even yet slower) technology.

-GiH

Nice. Proprietary documents

[Anonymous Coward]

Publishing the contract information on Microsoft's proprietary document format? It goes to show how serious and knowledgeable those folks are. Incompetence..

Re:Nice. Proprietary documents

[dtfinch]

I can open them in OpenOffice and Gnumeric just fine.

What bugs me is their Microsoft Active Directory integration requirement. What does that have to do with disk encryption?

Re:Nice. Proprietary documents

[Crypto123]

The AD requirement is for the automated addition and deletion of users for parts of the DOD using AD.

Re:Nice. Proprietary documents

[Anonymous Coward]

Without AD integration, users of a shared computer will also have to share the same password to bypass the encryption prior to logging in, obviously a security risk. With AD integration, they can use their own AD password.

Wouldn't it be nice...

[Crudely_Indecent]

if the government introduced legislation that protected its citizens as well as it protects its data.

NOT US Government

[Anonymous Coward]

Go to http://www.fbo.gov/ and search for FA877107R0001

US Air Force

Agency: Department of the Air Force
Office: Air Force Materiel Command
Location: ESC - Electronic Systems Center

Re:NOT US Government

[Anonymous Coward]

Do you mean to assume that the US Air Force is not part of the US Government?

Allies

[LoonyMike]

I wonder if the computer owner will have to supply the decryption keys when in British soil...

Doomed to software failures...

[mcdtracy]

There have been several major computer projects that started as Government mandates.
Few have produced significant results...

Introducing encryption between the kernel and the hardware disk subsystem is bound to create
unexpected and unintended problems with applications. It's doable but the matrix of testing required
and the feedback loop with developers/vendors would have to be strong and immediate.

Can you imagine trying to debug an application that interoperates with an encrypted file system and
the encryption techniques are a secret...

It's going to be a mess but most government driven IT projects are nightmares anyway. Of course, no one
close to the project will be able to disclose any details. So, tech novelists need to start creating
plausible scenarios right away. "Wargames III - the day the laptops froze" : PLOT: the US Government believes their
portable computers have been hacked... in the end they determine it was a encryption software bug that
surfaced once every N years. (N to be determined by the potential funding for Wargames IV).

I'm going to see if I can get some encrypted business cards. Data needs protection... from use.

Re:Doomed to software failures...

[meringuoid]

There have been several major computer projects that started as Government mandates. Few have produced significant results...

That reminds me, whatever became of that ARPANET thing they were all talking about way back?

Re:Doomed to software failures...

[lancejjj]

That reminds me, whatever became of that ARPANET thing they were all talking about way back? Oh, that ARPANET thing sucks. Only that dumb-ass Gore would think that regular people would like to use ARPANET.

Instead, I recommend what the free market developed: The powerful, easy-to-use NetBEUI. Perfect for your home, and built into Windows!

Re:Doomed to software failures...

[Dread_ed]

I hear they got some retired plumbers involved and now its just a system of tubes.

Re:Doomed to software failures...

[Anonymous Coward]

That was looong time ago... back when nerds like us ruled the world.

Re:Doomed to software failures...

[Hymer]

NetBEUI was made by IBM and back then it was very important, primary because of it's size... you couldn't fit a full TCP/IP stack in to the RAM on a std. PC back then. The other alternative was IPX by Novell... there were three or four other solutions but they were designed for some special network hardware.

Re:Doomed to software failures...

[BitterOak]

That reminds me, whatever became of that ARPANET thing they were all talking about way back?

Or what about that GPS thingie? Didn't amount to much I guess. Or what about the AES?

Re:Doomed to software failures...

[Anonymous Coward]

Lets see:

ARPANET - started by military research, completed by university researchers and private sector researchers.
AES - created by university researchers, renamed to AES by government encryption standards group.
GPS - dunno ...

Re:Doomed to software failures...

[ScrewMaster]

ARPANET wasn't a government mandate, it was a military/scientific research project that happened to make good, and the private sector took it and ran with it. Bad example. Besides, for every such project that was a success, there have been a hundred failures. A more apropos example might be the systems upgrades that the FBI, FAA and IRS have all basically FAILED to achieve, and the disruption and cost overruns that were incurred because of those mandated projects. And I'm sure there are other organs of the Federal government that have screwed up just as significantly.

Software encryption AND anti-virus apps.

[khasim]

If you want to talk about S L O W.

Every file opened is decrypted, scanned and then viewed.

Re:Software encryption AND anti-virus apps.

[reset_button]

I agree with you, but want to point out that it is not necessary for anti-virus apps to read the entire file on open. Instead, they can keep state on what they have checked in the file so far (and what parts of what signatures have been matched), and check for viruses on read/write operations. I don't know of any real-world apps that do this, but I know of one research project.

Re:Software encryption AND anti-virus apps.

[da5idnetlimit.com]

Fist you give them Quad-Core AMD/Intel 3GHz Cpus
Then you give them Ultra-speedy flash memory HDDs and lots of Ram

And only then can you find back that speed feeling you had when you first launched Win95...

BTW, you forgot something :

"each file is decrypted, scanned" then encrypted again into a secure memory heap with a random location in Ram then reinterpreted and decrypted from memory by the CPU for processing "and then viewed" on a secured, shielded screen that itself is decrypting the secured data transmission from the HDMI so you can't divert the data to a VCR/PVR.

Also you are using a laser-interrupt shielded keyboard with a white noise generator, so we cannot infer the electromagnetic blip from hitting a key or reconstruct the words from typing noise frequency, a hardened mouse so you can hit and strangle the person who tried to read above your shoulder all that super secure multi-encrypted BBC newsfeed you have on your 7 vision angle screen.

Gosh I hope you also encrypt all internal network traffic with a multi-gigabit differential quantum thingy. that all you network equipment is in the hardened nuclear bio hazard bunker, with all Cat 10 titanium head hardened Ethernet cables screwed/glued/welded to the unapprochable High Voltage Switch (220 V on the inside, 10000V on the outside).

BTW, now that we finished securing you infrastructure, can you please remind me what OS you are using ?

[evil joy] MU HAH HAH HAH HAH [/evil joy]

Re:Software encryption AND anti-virus apps.

[RAMMS EIN]

``check for viruses on read/write operations. I don't know of any real-world apps that do this,''

I think VShield did that in DOS.

I wonder if it's really "all computers"

[Phat_Tony]

I wonder if they're really buying a single solution to use on ALL their computers- I mean, I wonder how the NSA would feel about that. I have the feeling that they feel they're secure enough already and aren't going to weaken their security using some off-the-shelf product instead of whatever they're using now. I wonder if this will pass quietly, or if anyone will try to force this prescribed method of security on them.

In general, this is another piece of typical monolithic bureaucracy command and control. Something the size of the federal government would probably be better off NOT going with a single mandated vendor. Just mandate the security policy- all government computers must have fully encrypted hard drives- along with sufficient stipulations to define what that means and how it works. Let branches find their own solution providers. If they want economies of scale, they're free to band together to research and purchase solutions. Or they can do it by branch, or a branch can just set the requirements and let each of their departments work it out. But let them try something different if they want to.

It maintains more competition in the marketplace. If some department is unhappy, they can switch without trying to get the entire federal government to switch. If a department's unhappy, the ask other departments about their providers and implementations. Get some freedom, variation, and competition into the process. Also, one crack wouldn't simultaneously render all government computers vulnerable.

Just hurry up

[alta]

This is something I would like to do for all of my mobile users, and I prefer something that will work on older hardware like 3 years old, still a P4 laptop...

I'm sure what's good enough for them will be good enough for me. I like the 'no vendor back door' requirements... that should keep out MS.

But wouldn't full disk be easier to crack??

[EccentricAnomaly]

But can't you only encrypt directories where the user has write permission and leave the system files alone? If you are encrypting system files (that everyone has access to un-encrypted versions of) doesn't that make the encryption much easier to break.

Re:But wouldn't full disk be easier to crack??

[jrockway]

Yes, it would make it easier in the sense that if every atom in the Universe were turned into the fastest computer known today, it would only take the lifetime of 10 Universes to crack the encryption, instead of 100. 256-bit encryption is hard to break, and AES has held up to a lot of scrutiny suggesting that a known-plaintext won't help you break anything very quickly.

Looks like they missed..

[Anonymous Coward]

.. SecurStar's DriveCrypt Plus Pack, which is a little surprising. However, as an ex-customer who had to deal with their heinous software licensing/activation/deactivation system I can't say I'm dissapointed.

Re:Mod Parent Insightful

[mpapet]

Not so much that Halliburon will get it, probably not.

But there's only a couple of IT contractors who handle stuff like this. And the way this works is the government wonks may select a product, but it's the IT project management firm that gets the contract to implement and this is where it starts going awry.

-The backroom politics is fierce and has nothing to do with public service. This is a good game of influence peddling where deep pockets wins. See the story last month where the details of Microsoft's dealings with Massachusets (sp?) after ODF was killed were dissected.
-Layers upon layers of management.
-Actual product vendor is squeezed for every last cent while the IT project managers get to bill time for squeezing their vendor.
-Implementation (if it ever gets that far) is handled by another firm with no interaction with the software vendor. And the IT project manager gets to squeeze the implementers and bill those hours as well.

This, ladies and gentlement is how even implementing a pilot project costs millions and never sees the light of day.

And the top-rated open source solutions are:

[Anonymous Coward]

Transparent on-the-fly full disk encryption:

For Windows: http://www.freeotfe.org/ (based on LUKS)

For Linux: http://luks.endorphin.org/ (LUKS, supported by all major Linux distributions, for any size Linux server/computer/device)

* Cross-platform and well-behaving on-disk standard.

* Free as in both beer and freedom. open sourced.

What more can a government ask for?

I had to do this

[Anonymous Coward]

I work through the Department of Energy, and we've all had to encrypt our laptops using Pointsec. My computer has essentially been rendered useless because of it. Not only does everything that requires disk operations take forever because of the encryption, slowing it down noticeably, but it has also made hibernate impossible. I used to be able to open my laptop and wait 30 seconds to be up and running. Now I have to wait over 7 minutes and log in twice before I can even open a browser. It completely ruined the point of a laptop. To add insult to injury, the only thing I ever did on it was use the web and VPN in and use remote desktop to my office machine. I don't store sensitive information on the machine itself.

My hope is that when the higher-ups have this done to their laptops and see how horrible it is they will relax the policy somewhat.

PS...

[Frosty Piss]

I'm sorry, I should have said, this is in AMC ( Air Mobility Command ) within the AIr Force. The rest of the Air Force may be the same, but I don't know that.

Re:PS...

[YrWrstNtmr]

ACC is not quite that bad (yet). 9 char pwd. We ARE, however, going to the Standard Desktop Configuration (SDC) as of Jan 31. No admin accounts, no Outlook webmail, everything very much locked down. Which is fine for 99% of the poeple out there, but as a developer, I find it a real a real PITA.
"What?? I can't change the clock on the PC? How am I supposed to test this function that generates a string based on the time?"
"What? I can't defrag my own harddrive?"
"What? I can't create a folder in C:\?"

The SDC is good, but damn...some of us need a little more.

Re:PS...

[Frosty Piss]

We still have webmail in AMC, but only for "key personnel". But as to Admin accounts, the SDC does not prohibit that, so for you it must be an ACC or local rule. As the Organizational Computer Manager, I have an Admin account...

Re:PS...

[WhiteWolf666]

Why not use a virtual machine?

VMware or even QEmu

Re:PS...

[jank1887]

the non-standard software install request is still working through the approval chain...

Re:PS...

[YrWrstNtmr]

Why not use a virtual machine?

Let's see. To install VMWare (or anything), you need to be an administrator on that machine. If I was an administrator, I wouldn't need VMWare. And getting temp admin status requires a specific reason why. "I need to install VMWare so I can get around your stupid restrictions" is not a valid reason.

This is all new, and will shake out over time. But for now, it is very frustrating.

Re:PS...

[Pollardito]

if you could narrow it down a little further they can more easily find you and fire you for complaining

Re:PS...

[ender81b]

You'd think they'd have a sms/app package with VMware for the developers. That's what most people do -- or have a test lab on a separate VPN/domain for the developers.

Re:PS...

[kcbrown]

ACC is not quite that bad (yet). 9 char pwd. We ARE, however, going to the Standard Desktop Configuration (SDC) as of Jan 31. No admin accounts, no Outlook webmail, everything very much locked down. Which is fine for 99% of the poeple out there, but as a developer, I find it a real a real PITA.
"What?? I can't change the clock on the PC? How am I supposed to test this function that generates a string based on the time?"
"What? I can't defrag my own harddrive?"
"What? I can't create a folder in C:\?"

I hate to sound like a dick, but....good!

By being forced to develop your software as a restricted user, you're forced to ensure that your software will run with restricted user privileges. You're forced to use the proper means of determining the user's home directory, their temp directory, etc. You're forced to use the HKCU registry to store any registry items. You're forced to make the software multiuser-capable.

That's the way it should be. If most software had been written like that from the beginning, Windows would probably be a lot more secure for the general population because they would be able to comfortably run as a restricted user and know that all their software would Just Work.

So while it may be more painful as a developer to run as a restricted user, the pain does have a rather substantial payoff. Hopefully that'll make the pain a bit more bearable.

Re:PS...

[Phleg]

"What?? I can't change the clock on the PC? How am I supposed to test this function that generates a string based on the time?"

Uh, bad example. Good design would normally dictate you prototype this function as follows:

char* generate_string(time_t time);

Now you can call it using the output of time(), or in a unit test, try a bunch of different time_t values. What, were you going to have your unit test keep changing your system time?

Then, if you area always going to call it using the current time, simply write a small wrapper that does just that.

Re:PS...

[Anonymous Coward]

I'm a programmer, not an admin. The career field is not big enough for ACC to know who we are.

Re:PS...

[Lord Ender]

You don't have an air-gap development lab?

You shouldn't be developing on your primary office machine, anyway!

Re:PS...

[Anonymous Coward]

Why would you need any of the privileges you described? Maybe this will force developers to write programs that don't require admin rights to install or run correctly.

Re:PS...

[Anonymous Coward]

yeah, that'd be nice but do you not know how govt IT works? and networks and cross-connectedness (or lack thereof) within and between orgs? clearance levels? contractor access?

widespread sms? whatev! using sms for anything other critical patching even if it is present? ha! vmware? riiight! diagnostic tool and/or boot floppy/usb drive etc? get lost!

the implementation drivers for many of these systems was (and is) not managability or patching or configuration...it's control and operation to a particular set of standards that were defined at some point in the past and are not easy to change or update (by design).

it's not entirely a case of "stoopid bureaucracy"...it's a case of valuing org/infr stability and control of the env. for all kinds of compliance and security and whatnot over flexibility or even (sometimes) practical workflow.

it's not perfect but it's understood from a process and procedures standpoint that if you start to fuzz lines of what can be installed and how things can be configured and what you can and cannot attach to a machine to add or removed data and software, you very quickly lose the ability to guarantee with any certainty whether or not data is flowing inappropriately in or out of any system.

ideally, the procs will catch up and provide some basic level of flexibility but it's not a fast change and that end state is not the only or even primary driver of any shift in policy.

Re:PS...

[ender81b]

Well I do work in government, not federal, I guess I just assumed (how silly of me) that nearly everyone was using SMS or similar to handle software management & updates. It makes allot of these type of problems go away. To be replaced by entirely different problems of course.

Makes sense though, what you said -- not designed for maintenance just to do one job and that's it. I feel sorry for their IT people.

Re:PS...

[Anonymous Coward]

FWIW, adding directories (well, more than one) under the root of C: is absolutely horrible. It can be a nightmare when migrating someone's data. If you do it yourself, then it's less of an issue, but I keep my stuff under my own profile. I wish it wasn't such a long path to the profile though. It's a real bitch sometimes, especially since I work at the command line so much.

Re:PS...

[Anonymous Coward]

as a developer, I find it a real a real PITA.

Hopefully it will make you a better developer. One that knows what to import from existing libraries and what to code from scratch.
One that understands that data is not to be stored in program files or in a folder in the root directory.

Your users will be thankful for it.

Re:PS...

[Cerebus]

Bingo. This was a topic of discussion at the SDC meetings. The consensus was: 1) don't do that, and 2) if you *must* do that, your org will have to ask for an exemption from policy.

Re:PS...

[Anonymous Coward]

Use SUBST to map a drive to the long path

Re:PS...

[jafac]

SDC applies ONLY to desktop systems (not servers) and ONLY to NIPRNET-connected systems.

Put your dev box on an isolated test LAN, and just about anything goes.

Plus - there's always security waivers for functionality that's required for any particular conops. Just because some non-standard rights and privileges are granted in some cases, doesn't always mean there's a vulnerability. In a lot of cases, security is applied in a layered approach, so taking down one layer doesn't compromise them all.

Re:PS...

[jafac]

Forcing developers to develop "as a User" is not the answer.

Developers DO need to understand LUP principles in their development (it's all part of "know your trade") - but they also DO need special rights and privileges on their development machines.

I agree, that stuff should be (successfully) tested and should run under unprivileged logons - and that there are far too many developers who abuse the privilege of running as Admin, and just plain have no clue about writing software for LUP environments. It's probably one of the biggest problems facing the software industry today. But the answer to this problem is to educate developers. Not put chains on them.

Re:PS...

[YrWrstNtmr]

So while it may be more painful as a developer to run as a restricted user, the pain does have a rather substantial payoff. Hopefully that'll make the pain a bit more bearable.

Test as restricted, yes. Design and build, not so much.

What about Linux laptops?

[DoofusOfDeath]

I hear that lots of Navy developers use Linux laptops. I wonder if/how this will apply to them.

Re:What about Linux laptops?

[DoofusOfDeath]

I wonder what they'll do when the answer to encryption on Linux laptops is *free* ? There's no vendor to apply for it. Hopefully whoever is managing this effort won't be so stupid as to only consider techniques that cost money.

Re: What about Linux laptops?

[Black Parrot]

> I hear that lots of Navy developers use Linux laptops. I wonder if/how this will apply to them.

Don't know whether it meets the requirements, but you can encrypt Linux partitions with dm-crypt. I did a couple on a new system I built recently, and haven't had any problems with it.

Sticky Notes with Passwords

[Esion Modnar]

So, when the laptops get lost, the password to the FDE will be conveniently found on a Post-It note stuck to the side of the screen.

Re:Sticky Notes with Passwords

[Crypto123]

Note that one of the requirements is authentication via Common Access Card (CAC) with is mandated for DOD. With HSPD-12 everyone will be using standard two-factor authenticaion methods.

Full Disk Encryption -OR- File Encryption

[Anonymous Coward]

From TFA: "Provides Full Disk Encryption (FDE) or File Encryption System (FES)". Please read the actual requirements before writing your summary...

no news

[dochin]

This post is misleading. The FedBizOps notice is for the Air Force ESC, not the federal government. I don't even think it's related to the Presidential mandate. Most agencies implemented this when it was required (in August). Can anybody verify that the info on this FDE site is legit?

my experience with this

[Phylarr]

At the company where I work, they just did a similar full-disk encryption mandate. Some highlights follow: 1) It doesn't work with Mac, Linux, or anything other than Windows 1a) For now, that means any dual-boot computer is exempt 1b) Later, that might mean and dual-boot computer is re-formatted 1c) A whole lot of computers became dual-boot after the encryption announcement was made 2) Because Windows is encrypted, if any single file becomes corrupt, you are completely screwed 2a) The data cannot be recovered by putting a working HD with a hosed Windows install in another computer, nor by re-installing Windows 2b) Daily backups are more important now 2c) Nobody does daily backups 2d) Most people who do backups do them by copying their files to an external (unencrypted) USB HD. 2e) Those external, portable, USB HDs are easier to steal than any laptop or desktop computer. 3) There has been a huge expense to implement this, a minor slow-down in performance due to it, an increased chance of data loss due to computer problems, and no real increase in the security of any of the data.

Re:my experience with this

[Anonymous Coward]

You left out (4): computers become de facto assigned to one person, and can't be booted unless the person with the password is there.

Also, I'm posting this from a company that deals with financial matters. When I had a computer with full-disk encryption crash (as in Windows wouldn't come up - not that that ever happens), they were in a bind. Since this is a financial company, they couldn't wipe the disk without backing up the data. There was no way to access it. They finally pulled the hard disk out and put in on a shelf, where by either legal or company policy restrictions it is a mandatory paperweight until the designated period expires.

I'm not against full-disk encryption, particularly for a government worker dragging my personal data all over the place, but it does have its problems.

Re:my experience with this

[rdebath]

This depends A LOT on the software/hardware that you use.

1.1) Some variants work at the hardware level (Special cards, The new Seagate drives) they are OS independent.

1.2) Some software varients have drivers for multiple OSes (eg: CompuSec).

1.3) The initial boot screen should allow multiple users; the cost is around 50..100 bytes per user, at least one of these will probably be an IT administrator. It is possible to change any of the passwords or even safely re-encrypt the drive knowing only one password.

1.4) If the users are into yellow stickies then they need a keyfob that can be used to boot any computer they have access to. The keyfob belongs to them NOT the machine.

2.1) The encryption works at the block level, it's no more susceptible to corruption than an unencrypted disk EXCEPT for the key block. This block needs to be backed up once. (There is of course the possibility of driver bugs ...)

2.2) Decryption of the whole drive SHOULD be possible before the OS starts from the initial boot screen or a special boot disk. This lets you run standard recovery tools.

2.3) The backup software should put the backups into secure archives; even without FDE. If the user wants to just copy the files onto a USB Drive NTFS file encryption should be sufficient.

3.1) Speed, yes it will slow the disk down; but disks are REALLY slow anyway. If this is a problem you need the hardware solutions.

3.2) Data loss is no more likely as long as you keep the primary hard disk keys safe; that's the key that's actually used to encrypt the hard disk. This key cannot be changed unless the user first decrypts and then re-encrypts the entire drive. (ie it takes hours!)

4) FDE ONLY protects the data in the event that the disk is 'misplaced' and only works if the machine gets turned off (no 'warm' suspend, but hibernate is ok). I would say it's only relevant if you or your company have a legal requirement to protect the data. If you have it's now fast becoming a 'reasonable measure' that you need a REALLY good reason to ignore.

Re:my experience with this

[Cassini2]

Wasn't there a problem in Afghanistan where the locals were swiping the USB Memory Keys / Hard Drives and reselling them on the local flee market? Military secrets included ...

Irony

[Anonymous Coward]

So, comparisons of the FDE software packages by the government are to be published, BUT http://yro.slashdot.org/article.pl?sid=06/12/15/21 45254 the FCC giving out carrier reliability threatens national secutiry.

Hmm...i guess the telcos have much deeper pockets!

This is my job...

[BenEnglishAtHome]

...at the moment. I'm hip-deep in user handholding and re-imaging crashed machines. Here are a few random points, dashed off quickly. If anyone has any questions, feel free to post.

The June 23 White House memo had a 45-day deadline. Everyone has already blown the deadline.

Big props to WinMagic for their marketing. They've been all over the government computer press for the last 1-2 years with press releases and random mentions that make it appear they are the only workable solution. As a result, the agencies that jumped on the bandwagon in time to meet a (seemingly common) end of year deadline have grabbed their SecureDoc software and started installing. My experience with it has been semi-OK. Given that the software is touching every single file on every machine that leaves our physical space, the number of screwups has been acceptable at less than 2%. Our most widespread problems have mostly been a result of insufficient server capacity to deal with all the machines being encrypted at the same time within the last couple of weeks. Whether that was a result of us going cheap on the server side or WinMagic promising that the servers could handle a bigger load than is actually the case, I don't know. I suspect it's a bit of both. Still, things are slowly working out, even if our frontline support staff is going to wind up losing, literally, a month of productivity to the project.

A bunch of the requirements on that DOD checksheet are being ignored by civilian agencies. With no PKI infrastructure in lots of places, plenty of things have to be done "hands on" and the ability to do things like silent installs is out the window.

A bunch of the names on that vendor list are just resellers and of little interest to the slashdot crowd. What's more interesting is the list of products that do the job. THAT list is much, much shorter.

I haven't heard of anyone doing their encryption in hardware, which irritates me. I use hardware-encrypted drives at home and I was looking forward to doing the same thing at work. There is a widespread rumor in my agency that 2 or 3 generations of computer refreshment down the road, we'll transition to encryption in hardware. I hope so.

Re:This is my job...

[mreckhof]

Any reason why Gov't employees are using their personal email accounts in regards to this effort? Notice in 2006_12_20_DAR_Vendor_Day_List__2.xls on the Gov't tab, there's one person whose email address sticks out like a sore thumb. If HockeyPuk.com is a secure email site for Gov't email, then please, ignore my post. Otherwise, seems like the Gov't IT department has quite a bit of education to do that encrypted drives isn't going to solve.

Re:This is my job...

[Anonymous Coward]

I have used WinMagic for years, and find them the best of whats currently available.

A few years ago, after a number of laptop thefts, I recommended WinMagic to a major bank, which ultimately decided against an encryption solution because of the load it would place on their IT infrastructure.

That's right, boys and girls, it was too expensive and too tough for them to protect your credit card data.

The bank? Cant say. *Cough-Wells-Fargo-Cough* oops, did I do that? Sorry!

Re:This is my job...

[Anonymous Coward]

A bit of investigation points to the hockeypuk.com SMTP server residing under the control of a company called FowGroup who, from their homepage are "a leading provider of information technology services and solutions to clients in DoD, civil government as well as the commercial sector."

The list of clients includes;

        * Department of Defense - Chief Information Officer
        * Office of the Secretary of Defense - Chief Information Officer
        * Department of Army - Chief Information Officer
        * Department of Defense Education Activity
        * Army SoCom (Tampa, Florida)
        * Air Force Office of Special Investigations
        * Army NETCOM
        * Army HQDA

..and while the DIAP is not listed there, I guess that Robby Carter is important enough to get to use them for his email.

Re:This is my job...

[Anonymous Coward]

....oh, and the adminitrative contact for the hockeypuk.com domain is Will Alberts (the other DIAP employee listed in the spreadsheet) so I guess it's legit.

Re:This is my job...

[ortholattice]

Big props to WinMagic for their marketing. They've been all over the government computer press for the last 1-2 years with press releases and random mentions that make it appear they are the only workable solution. As a result, the agencies that jumped on the bandwagon in time to meet a (seemingly common) end of year deadline have grabbed their SecureDoc software and started installing.

Wow, if they win, someone is going to be obscenely wealthy. Talk about growing money on trees.... It looks like they're privately held - too bad, it would have made an interesting investment gamble.

I wonder if there are any open-source contenders (where the government effectively just pays for the vendor's support). That would save a huge amount of our tax dollars. Not that there would be a chance in hell it would happen even if there were; it sounds like WinMagic has probably saturated the hallowed halls of Washington with their sales reps.

Re:This is my job...

[Cerebus]

Current hardware disk encryptors are generally a little bulky for laptops, and the solution has to be fitted to deployed hardware *now* vs. at the next tech refresh (which is typically on a 3-year cycle). Desktops are a lower priority at the moment.

Plus, I've not yet seen a hardware disk encryptor that supports CAC authentication. :)

Re:This is my job...

[BenEnglishAtHome]

Current hardware disk encryptors are generally a little bulky for laptops,

Really? I didn't realize that.

We've been doing this for 5+ years now

[Terje Mathisen]

I work for a multinational corporation with more than 10 K laptops, we decided to use full disk encryption more than 5 years ago.

At that time we found just 5 vendors who were qualified to deliver (after an initial pre-qualification round), and we invited them all to a specially setup testing lab: Of these 5 vendors, 3 were selling pure snake oil (encrypt the partition table and/or root directory only), it took less than 5 minutes to break into each of these.

Nr 4 seemed a lot better, but after 20 minutes work I found the crucial 'compare password, JE decrypt' sequence in the driver, and we were in. :-(

Only the final entry (from a german company) had understood how you design a product like this:

First you encrypt, using your preferred symmetric key algorithm (AES-256 these days?), all sectors on the disk. You use some form of hash of the logical sector number as a salt when encrypting, this makes each block unique, even those that contain the same 'FDFDFDFD' freshly formatted pattern. The key you use for this is the master disk key, it is a random number generated during installation.

Next you make a small table, with room for at least two entries: User and admin.

The user entry can be modified as often as you like (we default to slightly less than once/month), while the admin key/password is constant, but unique to this particular PC.

Each password (user/admin) is used as the key when encrypting the master key, which means that there is no way, even for the crypto architect, to recover the master key without knowing at least one of these passwords. (The passwords are never stored anywhere on the disk of course!)

The admin key/password is saved both as a printout and on disk on a secure system (without any form of network connection), so that you can use it each time a user manages to forget his/her user disk password.

There are lots of nice to have features as well, one of the more important is the ability to use a challenge/response setup to safely regenerate a user password remotely, without ever having to transmit the relevant admin key. This does require some kind of side channel to verify the identity of the user who owns the particular laptop: We use a combination of RSA's SecureID cards and the user's cell phone for this (each user has such a card to be able to use the corporate VPN connection which requires strong authentication).

Terje

Re:We've been doing this for 5+ years now

[Pike]

curious: what was the name of this German company? also, was guardian edge among the 5 you looked at and if so what did you think of their product?

Re:We've been doing this for 5+ years now

[throx]

Just curious - does the system support multiple "user" entries? What is the boot sequence and does it require specialized hardware, or just has an unencrypted bootloader? What defenses does it have against someone putting a trojan bootloader in that grabs the key?

Re:We've been doing this for 5+ years now

[wonderlan]

Way easier... thin clients and fat servers. Citrix, Terminal Services, UNIX, or whatever the hell you like. If no data is ever on the end machine its a hell of a lot harder to pull it out. Security can be controlled way easier, backups are consolidated, redundancy is way easier, just make sure you get a backup internet line. Even you want to push it a little further, you can go so far as to point push thin client applications using citrix or 2x's product, thereby only thin-clienting the applications that actually need it and let the user still browse the web, get viruses, Trojans, watch some porn, or whatever on their local computer; the data is not exposed. This frees up way more server resources anyway, and provides a much better user experience. Hell most of our clients on this don't even realize whats going on. Now that you can trap the data inside your data center you can safely control how data is allowed in an out of the organization (email being the main pipe here). Enforce a good email encryption product and make sure to examine every piece of software you pinpoint thin client on the ways it allows information in and out, shore up those. Finally, if you do let users on full blown virtual desktops, for the love of god don't give them permissions to run any form of executables on the servers, and hire some amazing IT pros to help you build an awesome server image. Finally, to really make all this work perfect... install QOS switches at the branches, QOS routers (Mikrotiks are AMAZING!!!) prioritize traffic, implement queue trees, keeping your bandwidth clean and optimized is the key to making all this work really well. Encrypting the whole hard drive to me seems like a bullshit solution full of holes. The data shouldn't even be allowed on end user machines in the first place. I am sure you guys will tear this apart, but I can tell you from experience this system can work wonders. Oh yeah, and now that you have all that lovely bandwidth control, you might as well start dropping in Voip since you should be able to maintain great quality. While your at it start taking vacations as your cost devoted to desktop support just plummeted. - "oops" means it's fixable. "oh shit" does not.

Re:We've been doing this for 5+ years now

[gbjbaanb]

and if your user is in an area with no internet connection? What happens then?

Not just places with no wireless or mobile coverage (and believe me, they'd notice trying to run citrix-style thin clients over a gsm modem) but places with no coverage of any kind. These are military and government systems, so they can be expected to crop up in places where there is no network infrastructure - eg. New Orleans after the hurricane, African countries, Iraq, etc etc.

In short, your solution does not even begin to address the problem the client actually wanted to solve.

Re:We've been doing this for 5+ years now

[DamnStupidElf]

The user entry can be modified as often as you like (we default to slightly less than once/month), while the admin key/password is constant, but unique to this particular PC.

Do they use PKCS#5 or similar to strengthen the user supplied passphrases? It also seems like it would be easier and safer to just encrypt the master key with an administrative public key and store it on the laptop and a server somewhere. That way individual admin keys aren't required for every single laptop, and laptops never need to know the private administrative key.

Re:We've been doing this for 5+ years now

[Terje Mathisen]

Re: Multiple user entries:

Not initially, but I believe the current version does so.

The boot sequence is to load (from a reserved area) the FDE sw which first tries to verify that it is running in plain unprotected DOS mode, then it takes over the keyboard hw so that it can read keystrokes without risking a trojan/keylogger attack.

After getting the password/passphrase it uses this to decrypt the user entry which contains the master disk key: If this doesn't succeed it goes into a sw timeout loop, taking progressively longer each time, before letting you retry.

When Windows loads, it must run in bios mode, until the protected mode crypto driver can be loaded.

Terje

Re:We've been doing this for 5+ years now

[Breakfast Pants]

What prevents someone who has stolen the disk from modifying the program to not do the sw timeout loop?

Re:We've been doing this for 5+ years now

[Vitriol Angst]

Is this a Windows or Unix variant machine?

I was under the impression, that only some flavors of UNIX were even able to "encrypt" their Cache files (not Linux).

The Next Mac OS X will be able to encrypt all of the user space, as well as the cache (I think there are ways on the command line to set the cache to encrypt -- but no support in the GUI). But even then, not the entire drive with the OS.

I think IBM had an encrypted drive with a hardware-level encrypt/decrypt so the OS doesn't see it -- that might be the way to go.

>> Anyway, I think it's more important that our government just quit promoting criminals to power -- they are way more of a security issue than stolen laptops.

Re:We've been doing this for 5+ years now

[throx]

Makes sense.

The primary attack vector I can see is not booting from the disk and replacing the boot loader with something more "friendly" to attack (or sniffing of a proper passphrase), but without a TPM there's not much you can do to avoid that.

Re:We've been doing this for 5+ years now

[Kjella]

And for all the "must have" features but not the "nice to have" ones, LUKS got it covered. Should be part of the next Debian installer to be released next month (hopefully), and some various other distros too. Full disk encryption, encrypted swap (with random key, no less) using AES256 (or whatever you feel is your choice, but if it's good enough for Top Secret, it's good enough for me). Oh yeah and ESSIV, which improved on the sector number salt. Still quite a bit of usability/GUI work left though (like PW popup when you try to access a LUKS volume), I think Gnome has gotten the furthest.

Re:We've been doing this for 5+ years now

[khchung]

Each password (user/admin) is used as the key when encrypting the master key, which means that there is no way, even for the crypto architect, to recover the master key without knowing at least one of these passwords. (The passwords are never stored anywhere on the disk of course!) I have done a similar design for a imaging system that required the stored images not accessible by simply reading the disks without knowing the passwords.

I always wondered if that is the right way to do it. It is good to know I at least got that part right.

Everything will be classified, by default

[Anonymous Coward]

Unless someone actively declassfies it (decrypts it), it will be unavailable. Consider how it will affect:

  * Subpoenas -- They can more easily deny the existence of the info. And how can anyone execute a search without the decryption key.

  * Archives -- Not only do archivists have to deal with electronic documents and all their formats, they will now need. What was the President thinking when he ordered the invasion of Iran in 2009? We will never know.

  * Coverups -- Oops! Lost the key.

Hope the cure isn't worse than the disease

[banerjek]

Although encrypting the entire disk is definitely useful for protecting data on stolen laptops, it won't do a bit of good against inside jobs, hardware key loggers, social engineering based attacks, and a lot of low tech approaches that don't require breaking encryption to work.

Encryption is an important tool, but I won't be surprised when news stories emerge because enormous amounts critical data was lost because encrypted files could not be read due to efforts by a disgruntled worker or ineptness.

As others have suggested, centralizing where data is kept, focusing on making that as secure and reliable as possible, and not implementing bonehead security mechanisms (such as impossible to remember passwords) that leave systems more vulnerable than before.

Public Domain

[Anonymous Coward]

A significant percentange of all of these files properly belong in the public domain: we paid for them. A universal encryption policy really highlights the need for a policy mandating submission of all public domain documents to the National Archives in a publically accessable format, so that they are not lost forever.

Presumably we will not be requiring the National Archives to encrypt all documents.

FDE Requires Gov't ID Card

[mpapet]

How this will probably work is the end solution uses a smart card to do some authentication and key storage.

All gov't employees will at some point get an ID card similar to the Common Access Card. This will have a number of public keys on it. One of which probably decrypts their workstation.

The U.S. gov't is building the capacity to issue millions of smart cards on their own. See this: http://www.fcw.com/article94813-06-07-06-Web There was a proper publicly available contract up for bid for this project but it wouldn't surprise me if it has been pulled in favor of a no-bid award.

Before anyone says, "Well it should be a secret! What if the terrists get a badge?!" There are two things to remember.

1. Lots of bad people have proper ID in their country of choice. Identification has little if any relationship to their activities. The failure points remain the usual human factors out in the field.

2. There's no need for secrecy in the production environment. Every half-decent perso system/PKI properly manages such an obvious point of failure. If a Visa-certified card plant can manage to keep track of 10's of millions of cards anyone can. It's not rocket science.

I for one welcome our fully encrypted overlords.

Re:FDE Requires Gov't ID Card

[HBI]

The idea of someone on the road forgetting their pin, wiping their card somehow, or damaging the POS card readers just gives me that warm fuzzy.

The experience of hearing some numbnuts claim "I'm the head of a $2B program! Make my computer work!" when they are in the armpit of the earth...yeah, this one will be a winner.

What the White House Directive Actually States

[JusticeISaid]

The White House directive applies only to laptops (and presumably desktops) that (1) store or process "personally identifiable information" and (2) are used outside an agency's security perimeter. The memorandum from the Office of Management and Budget to all U.S. agencies also outlines additional requirements that are intended to reduce the risk that Social Security numbers and other sensitive personal information are compromised by the physical loss of a computer and to better control external access to such information.

If the concern is about laptops....

[Dcnjoe60]

If the concern is with stolen laptops, wouldn't it be simpler to just have some kind of wireless cell phone built in to the laptop? Then when it is turned on, it receives a signal saying it's okay to boot? If the laptop is reported stolen, then it won't get the boot signal. As an additional step, it could have a built in gps, like most cell phones do, to alert the authorities to where the stolen laptop is located.

I'm all for encryption keys, etc. But to expect all of the government workers to use them and keep them secure is crazy. The human is the weakest link in the process. How many people have passwords taped to their screens or keyboards? Why would anyone think this would be any different? Unless of course, they are going to also have those fancy key creators that many online banking sites use. But then, that would probably be in the bag with the computer, so the encryption drive would be accessible anyway.

If I recall, the first rule to data security is to control access to the equipment. If the government is having problems with stolen laptops, which by their very nature are easily accessible, it seems the next best thing would be to control the access by keeping the equipment from working without the proper authorization signal (and then do a thorough investigation as to how all of these laptops are getting stolen in the first place).

Just a thought.

Re:If the concern is about laptops....

[openldev]

I agree with your point about using GPS to add locators to the machines. The problem is that, if someone steals it, what's stopping the thief from pulling out the hard drive and just mounting the partition. You need the encryption to prevent this as well.

Re:If the concern is about laptops....

[jonbryce]

No, that wouldn't work, because all the attacker has to do is take the hard drive out and put it as a second drive in another machine. That's most likely what they do anyway.

Requirement list

[The Second Horseman]

It's actually pretty good - the overall list, for administration & configuration, the management console, symmetric key recovery (essential in any enterprise deployment), and even the way they want the licensing to work shows that they have a pretty good grasp of the issue. A lot of this stuff would be good for any organization that was going from a departmental model for licensing and evaluating software to a more centrallized approach.

Right and Wrong and Gravity

[Toby The Economist]

This is absolutely the right thing to do.

I can however confidently predict that since a very large number of people are involved in making the decision, the worst possible product will be chosen.

So it won't be TrueCrypt, or something decent - it'll be something like the latest commerical version of PGP.

Re:Right and Wrong and Gravity

[Anonymous Coward]

You are completely full of shit. TrueCrypt does not do full disk encryption and is therefore unsuitable. We use PGP's FDE product and it works rather well, with a secure implementation.

eh

[EdMack]

The same govenment that wanted the keys to other people's encryption, claiming 'if your up to good, you got nothing to hide'. Hopefully they are on our side now :)

000000?

[sribe]

Sooo, I wonder if the encryption keys will be set like ICBM launch codes, all at "000000"???

Re:000000?

[Anonymous Coward]

That was a secret... now we have to kill -9 you...

MacOSX already as that functionality built-in

[Anonymous Coward]

Stupid users!

The requested functionality is already built-in into MacOSX!

i.e. it will encrypt the home directory.

Bad idea -- data recovery implications!

[defile]

Data recovery is only a viable business (and a useful life-saving service) because of the peculiarities of how data loss occurs. Serious data loss is hard. It involves wiping the entire disk, block by block. It can take hours. In the grand majority of data loss cases, 99% of the data is still intact. The operating software has simply lost the ability to manage it. A human being with the proper tools can eyeball the raw data and come up with a plan to reconstruct it. This is a pretty costly procedure, but feasible enough for the average business that REALLY needs data back (almost always because they discover their backup procedure was broken).

The costs involved in recovering data when you're dealing with encrypted volumes are orders of magnitude higher, well into the range where only intelligence agencies would bother trying.

Unless there are corresponding improvements in backup policies (doubtful) this is going to make a really bad situation.

A stake through the heart of non-commerical linux

[goombah99]

At my intitution were worried about all sorts of personally identifiable information. There does not seem to be any quantitative guidelines for this. Even one SS number is apparently too much. And it's not just the info I might be aware of but the info that might be there that I'm not aware of that counts too. For example, if someone sends me a resume. Even if I never read it, It might contain birth dates and other personal info. Hence I need to protect all the e-mail.

Now the hackles being raised are that this means we can't use Macs and maybe not linux since there are no acceptable enterprise-worthy full disk encryption systems. If you know of some, expecially for macs please reply with details below. But the term "acceptable" and "enterprise-worthy" matter a great deal. You can't just go installing full disk encryption based on some open source solution that might or might not get updated to work with the next version of say debian or fedora in a timely way. It has to have a method of key escrow that is usable. etc...
Hence people are looking to windows.

Another raging argument is what full disk encryption means. Surely something like mac's built in encryption of home directories and if need be combined with secure virtual memory would be sufficient to protect anything but very critical information. The answer we are hearing is No and "maybe". We are beinf pushed to use Entrust which all users I have heard from say is a disaster. There's going to be huge data recovery issues. And I don't see it as likely that Entrust will always be assured of working across OS upgrades

Personally I'd prefer to see encryption done in a transparent hardware layer.

In the long run this going to be good for the branded commerical OS, and the Linuxes backed by commerical vendors. The reason is that in the end you'd have to be pretty stupid to encrypt your whole disk with anything not supplied by the OS vendor because it simply has to work right under all circumstances and there simply has to be one person you can call when it fails. It woul dbe intolerable to have to have the OS vendor say well it's not our problem and the encryption vendor saying they are trying to work with the OS vendor to figure out why the kernel upgrade broke it.

And when it does break after you hit the "Software update" button or worse corporate HQ pushes the update overnight to your computer there is no failsafe mode! the computer won't boot. Corprorate HQ can't even contact your computer to undo the problem after the reboot. you can't even donwload a patch from the vendor or let them know it was broken. You can't even look up their phone number. Nor can you go to your neighbors computer to download a patch since his machine is broken too.

Other arguments people are unsure of
1) is home directory encryption enough
2) what about removable media?
3) what about FAT tables?
4) boot tracks?
5) virtual memory?

The fact that this order is zero tolerance with no asseement of risk seems to prove it is ill conceived.

It's a stake through the heart for all non-comercial linux

Comment removed

[account_deleted]

Comment removed based on user account deletion

FDE and FIPS 140-2 certification

[mephistus]

I work for a company that independently tests and certifies products to the FIPS 140-2 standard. After looking over the requirements for FDE, it's not anything particularly new or exciting. All FDE seems to be is a directive to use FIPS 140-2 (soon to be 140-3 http://csrc.ncsl.nist.gov/cryptval/140-3.htm) certified products that have some requested features, on government machines. Even the requirements themselves are just specific highlights of FIPS and Common Criteria requirements. I definitely think it's well past due that mandates like this are being pushed in the government.

The federal government has used certification programs like FIPS, Common Criteria, and others to give agencies choices in what they can buy to improve their own security. However the biggest problem is that most branches don't take advantage of the technology because either they don't want to fund it, or don't understand the importance of how vulnerable they may be. Some parts of the government are ridiculously advanced with their security standards and practices, but it's absolutely woeful how other departments lag behind, like Education, HUD, and others.

What really needs to be done is something more streamlined and efficient to get technology certified faster and according to the right standards. Take a look at the FIPS 140-2 standard if you can survive the mind numbing guhb'mentese. It's geared more towards hardware based designs as opposed to software. 140-3 is going to be much better, but it's not great. Algorithms like AES256 are a good start, but there's definitely better encryption out there. The good thing is that a great deal of really smart people work on encryption products. With the kind of money that just one or two government purchases can bring, those who are certified early will make beaucoup bucks.

There are already look to be 3 or 4 products (http://csrc.ncsl.nist.gov/cryptval/140-1/140val-a ll.htm) that are FIPS certified, but I'm not sure if they meet the EAL 3 requirements. Expect to see more of these mandates for all kinds of things from networking, to the new PIV project http://csrc.nist.gov/piv-program/index.html. Actually, I'm kind of suprised that FDE doesn't specifically require PIV for it's user authentication. That's the problem with government projects like these, too many cooks and not enough kitchen. :)

Just two thoughts...

[lionchild]

First, how will FDE help when government contractors laptops are lost/stolen with sensitive data on them? Which, I thought, I could be wrong, was more often the case than an actual government laptop being lost/stolen.

And second, this will presume there's no need to get data back from a drive if a machine fails, even if it's not lost/stolen, right? The idea of FDE would be that a drive would only work with it's installed machine, right? One would -hope- there would be a way to retrieve useful data on a system where...say the system board goes bad.

Just my $0.02 in thought-form.

Eureka

[PopeRatzo]

We've finally found this administration's area of competency. They clearly can't govern, can't fight a war, can't balance a budget or tell the truth. They can't solve a problem or secure the borders or prevent a terrorist attack (this thing happened back on 9/11/01).

But they know how to make stuff secret. Yessir, they sure know how to use that super-double-secret ink-stamp.

Can you smell a coverup

[cpuffer_hammer]

It will be nice to loose the key or keys for laptops that contain evedence of wringdoing.

Or

Will there be an independant storage agancy/site for "administrator keys"
Or we be depending on the smart Boys and Girls and Langly every time someone and their admin don't want or cant't tell us what the passwords are.

Will encryption prevent stupid leaks?

[Anonymous Coward]

Did anyone else notice that the vendor list leaks the email address and telephone number(s) of a lot of people who probably don't want that information posted on the internet? Doh!

Re:unpopular data/facts, not "personal data"

[Martin Blank]

Among the requirements is "For FDE, allows multiple users of same laptop or device using DoD CAC for boot authentication by each user," "Allows administrators to provide remote assistance to users who are locked out, and "Allows for decryption and uninstallation of encryption solution by a system administrator only." This means that every device will have multiple keys protecting the data (a user key and an administrative key at the very least) to allow the data to be retrieved. Otherwise, the government could not pursue its own employees in the situation where it needs to develop a case such as espionage.

Re:A stake through the heart of non-commerical lin

[goombah99]

Of course, if they require the system partition to be encrypted too that might prevent Vista from working.

A lot of the arguments in favor of it are bogus. For example in TFA they give as the number one reason that temporary files and Virtual memory are protected. This is pretty silly. First even right now VM can be done securely. Massive compromises of data are not likely to happen via either. And if someone is concurrently logged in so that they could even access the temporary files then they can access the encrypted hard disk in general. They seem to be confusing access permission with FDE. Moreover If one is worried about data leaks via tmp and VM then one should be even more worried about data leaks via content indexing like spotlight, google desktop, and MS's next Filesystem (Whenever that happens)

Depending upon what layer this happens at it seems to me it could wrench a lot of virtual machine implementations too.

The problem with just encrypting home directories only matters if the machine is shared. FOr example, if there is some shared database on the machine that is supposed to be accessible to more than one user, encrypting the home directory only is a problem. On the otherhand for most laptops (in the fed gov) one assumes they are single user nearly always.

Not full disk encryption - RTFA !!!

[fluffy99]

Congratulations on another BS story. Can I filter out idiot editors who post this crap? It would be nice if the original poster would actually bother reading the mandate, because it doesn't require full disk encryption. It only sets out requirements for encrypting personally identifiable info, PII category, information when remotely accessible, being transported, or on mobile devices. Basically if there is a chance of it being long it must be encrypted.

Re:Bad Moderation &

[Anonymous Coward]

I don't think MS has something like FDE does it?

start your own company

[SethJohnson]

I work for a multinational corporation with more than 10 K laptops

Just wanted to give you a reality check:

If you work for a company like that and know this technology to the level you are describing in this post, you should leave your employer to start your own company providing this solution. There's no way you're getting paid at a multinational corporation as much as you would make in your own (successful) company. If you had launched your company back when you had performed the aformentioned evaluation, you'd probably have enough progress with your own product to pitch it in this govt. bidding process.

Not trying to criticize you. Just trying to inspire people.

Seth

Re:start your own company

[tayhimself]

Seriously though, google Terje Mathisen before mouthing off about who he works for or what he should do with his life. He is an extremely highly regarded authority on computer architecture and program optimization. Hell, his name was one of the first that John Carmack thought of when asked about the fdiv() function in Quake. Check comp.arch for more...

Re:start your own company

[Terje Mathisen]

Been there, Done that.

Before taking a one-year sabbathical (91-92) which I spent in the US, writing networking code, I had a company that sold terminal emulation/file transfer software. I sold enough licenses to make it one of the top 5 bestselling norwegian programs. During the last year the norwegian IRS grabbed 83% of every Krone I invoiced my customers.

At that point I realized that I'd much rather work less and spend more time with my wife & kids, so I closed the company.

I still write/optimize code, but always because I enjoy it, not to make money. (Sometimes I do get paid as well (in addition to my regular salary), but that's not the important part.)

Re. "know this (crypto) technology": I want to know a lot more than just crypto, and the job I have, which is a sort of IT Fire Brigade Chief, means that I get to work on all sorts of interesting technology, including everything that's new, as well as everything that doesn't perform as well as it has to. The Full Disk Encryption requirements I mentioned in my first post were obvious to me at the time, but not to most of the vendors unfortunately.

I spend my leisure time on orienteering http://orienteering.org/, which is the perfect thinking person's sport.

I'm also the Scandinavian coordinator of the Confluence project http://confluence.org/

Check google for my other interests!

Terje

Re:start your own company

[FooAtWFU]

During the last year the norwegian IRS grabbed 83% of every Krone I invoiced my customers. At that point I realized that I'd much rather work less and spend more time with my wife & kids, so I closed the company.

Wow. Talk about the Laffer curve in action there.

Re:start your own company

[jafac]

I spend my leisure time on orienteering http://orienteering.org/, which is the perfect thinking person's sport.

Heh - when we did our orienteering badge training for BSA, that's exactly how they phrased it; "the thinking man's sport."

We've yet to find a GPS receiver that reads fast enough to beat a good orienteer with a magnetic compass. . .

If it is that important

[Anonymous Coward]

If it is that important to have all drives encrypted, why only make the change now? Because that's when Windows had released with native support for it?!? Nice to see our security's in such good hands...

/swap, /tmp, /usr/tmp

[flyingfsck]

There are many places Linux write stuff outside the home directory. However, the government mainly uses Windows, which is even worse, since it uses a swap file. Whole disk encryption on Windows has been used for many years in the military industry.

Re:/swap, /tmp, /usr/tmp

[catfood]

Windows is worse than Linux because Windows uses a swap file?

Huh?

Good News

[Anonymous Coward]

The good news about this case is that it will set the trend and soon a proper FDE will become mainstream.

Common current OS:s (Windows, Linux, OS-X) std out of the box disk encryption solutions are still more addhoc than anything else compared to a feature-rich manageable solutions that don't let you down not even the most worst situations, install/removal (encryption, decrypting) is transparent background job that won't even bother if you shut down the system and reboot later -- it will just continue where it was etc, hierarcial management of keys and other credentials, removable media automatic encryption and sharing between same organization. Lot's of very useful features even for the home user once you know those are available for you .

There are good solutions, like pointsec.com have, but I just wish I didn't have to pay exra for personal use and that all common OS:ses (mentioned above) would be supported, currently OS X isn't by pointsec.

Cheers.

Oh boy, Lotus Notes Disk Encryption!

[Anonymous Coward]

I'll believe it when I see it. Laptop management is still non-standard, and support in some agencies is nonexistent.

My wife works for the USDA, and she still endures multiple-day email outages. Support has been cut to the bone (guess where all the money is going.) Everything is based on Lotus Notes.

OTOH my former employer, a Very large Bank, did this with their laptops and it worked well. The only side-effect was that the BIOS based part of the thing prompted you for a (complicated) password at every power up, then locked you out after three tries, so support got hundreds of password reset requests daily. Even I occasionally bricked my laptop this way. Still, better than losing data.

Improve the ATA encryption system ?

[Anonymous Coward]

Many ATA hard drives support drive level locking - given the power of the embedded CPU's on drives these days why not simply improve it there ?

At least that way you could have the crypto implementation separate from the opeating system.

No, no, no.

[Sod A Dog]

You have to keep in mind that this is the government we're dealing with here. See, what you're saying actually makes sense, so obviously it's completely out of the question.

Remember, government policy decisions (of all kinds) are usually made like this: "Ok, so this is fucked up? It's not going to work? It's going to cost too much and piss off everybody in the world? Perfect, let's do it that way, then."

Re:No, no, no.

[ralphdaugherty]

You have to keep in mind that this is the government we're dealing with here. See, what you're saying actually makes sense, so obviously it's completely out of the question.

      Reading the government document link is what would actually make sense.

  rd

mod up PARENT

[Anonymous Coward]

interesting

It takes more than knowledge to start a company...

[Vellmont]

There's a myth out there that the hardest part of technology is understanding the technology. That's certainly a part of it, but there's a lot more too it than that. You have to have funding or know how to get funding. You have to know how to run a company, or find someone that does. You also obviously have to take a lot of personal risk.

Maybe the GP has all those skills and is willing to take the risk, maybe he doesn't. The point is though that the lure of making more money, or having more control over the product isn't necessarily enough.

qemu doesn't need permissions

[jhantin]

qemu will run perfectly well as an unprivileged user on either Linux or Windows with no installation required. Just grab a package from here, unzip it, and launch qemu-win.bat. If you want it to use the native memory management hardware and directly execute user code (read: go faster) then you can use the shared-source kqemu kernel driver on either platform.

tagging beta: oldjoke

[mandelbr0t]

WTF? Why is there always someone with mod points that thinks the ROT-13/ROT-26 encryption joke is funny? I stopped using ROT-13 15 years ago.

mandelbr0t

Re:tagging beta: oldjoke

[Rob T Firefly]

Because this is Slashdot, and in this post-Columbine world Netcraft confirms that I for one welcome our Soviet Russian old joke overlords, you insensitive clod.

Software Development is a Privilege Not a Right

[Anonymous Coward]

...in the corporate world.

In order to run a compiler you need the privilege to generate and modify executable files. This privilege might be denied to ordinary users in order to prevent them from downloading and installing games -- or being clever and downloading a compiler and writing their own games.

In order to run a debugger you need the privilege to run a debugger. A debugger can attach to any process with privileges equal to or lower than itself, but that means that your debugger can attach to any application you have permission to run. You could use that to write to its variables and thus subvert restrictions that are written into the software. For example, if the program keeps a boolean variable indicating whether you are privileged to access Corporate Accounts, and that boolean is normally initialized when you log into the database and is not modified again, and you have a debugger, you can set that boolean, even if it is not supposed to be set.

What you hope to accomplish can only be properly achieved by requiring every developer to test under an unprivileged login.

Virtual machines make this easier.

Remember: ordinary users are not allowed to develop or debug software.

Re:Software Development is a Privilege Not a Right

[WNight]

runas - the Windows equivalent to sudo. Launch the compiler and debugger as admin. Alternatively, login as admin, and use runas to launch your executable as a low-priv user. The former is a "better" development platform, the latter is easier to get used to. Both are world better than developing an app that needs admin but shouldn't.

Even if part of the app needs admin the UI shouldn't, and the installer should use the least privilege possible for everything.

I hope they've allowed for password support

[idan]

Disk encryption is all well and good, but in an enterprise setting it can be a tad
expensive to deploy and support. Keep in mind that the disk is typically encrypted using a key
unlocked using or derived from a pre-boot-authentication password.

A big problem that comes up again and again is that users forget their PBA password
at the most inopportune of times. Imagine a user off in the middle of nowhere, calling
a central help desk on his satellite phone or some such, asking for help because he
forgot his PBA password.

A smart vendor has workarounds for this, such as single-use override passwords to
unlock the workstation until the user can "come in from the cold." An even smarter
vendor enables access to this using a phone plus an automated IVR system, so that
said user can self-authenticate (example: voice print) and fix his own problem.

This is a big deal because help desk calls cost money (typically $20 to $50 per call),
and in an enterprise (the RFP calls for 50k users minimum), we're talking tens of
thousands of such calls annually.

I know that at least one vendor handles this stuff right (PointSec). Not sure about
the others, but it's a very important consideration...

-- Idan

Re:Mod Parent Insightful

[Brandybuck]

But there's only a couple of IT contractors who handle stuff like this.

People need to understand this. Government rules, regulations and procedures disqualify most possbible bids. Only those companies *specialized* in government contracts get these jobs. In addition, the margins on these jobs are so small, that larger companies have a huge advantage in the bidding process. Throw in several layers of lawyers and you end up with a system several realities removed from any semblance of a market.

NSA to the rescue

[rbarreira]

What do you think the NSA is for? ;)

Re:A stake through the heart of non-commerical lin

[ScrewMaster]

It's a stake through the heart for all non-comercial linux.

Not necessarily. You're assuming that this gigantic government-mandated undertaking is going to work. I think that is a mistake.

Ask yourself how many times such major overhauls have ever worked right, when the Feds are in charge. The FBI botched a big upgrade, the IRS is still botching theirs, the FAA botched theirs ... and now we're talking about a critical change affecting hundreds of thousands of computers running everything from Windows to Unix to DOS, implemented across multiple bureaucracies and departments. My guess is that it's going to fail, fail on a massive scale, and that it's going to result in far more data loss and operational disruption than the people in charge of this impending train-wreck are willing to admit (or will ever be held accountable, which is just too bad.)

When all is said and done Linux. branded or otherwise, will be damned lucky not to be too heavily involved, and may come out looking pretty good.

Well, well

[SeaFox]

Look who's on the list...

AT&T: Kathy A. Ball, Program Manager, kball@att.com, 443-259-8100
AT&T Government Solutions: John C. Nagengast, Director, Business Development, nagengast@att.com , 443-259-8366

Wonder if the NSA wrote them a letter of recommendation.

Remove disk, use live boot cd

[Anonymous Coward]

I plan to remove the hard disk, boot a knoppix CD, and ssh back to machines and data in my secure building. No, not everyone can do this, but *I* can. It means I can't work if I don't have net access, but that's something my boss will have to deal with. Security has a cost, and that's the cost at my level.

me: my laptop was stolen.

CIO: Crikey! What PII or sensitive information was on it? You never had it encrypted!

me: It had no hard disk. No data was lost. The hard disk is locked in my office - check the serial number for proof.

CIO: you SOB!

Re:A stake through the heart of non-commerical lin

[Anonymous Coward]

I think you're absolutely right. This story wasn't making any sense to me until I read your post. Now it's clear as day. This is just another ruse to push someone's favorite commercial OS onto everyone else.

The reason is that in the end you'd have to be pretty stupid to encrypt your whole disk with anything not supplied by the OS vendor because it simply has to work right under all circumstances and there simply has to be one person you can call when it fails.

That, of course, is the reason people will give for why the solution has to be a "commercial" (read: proprietary) one. Personally, however, I can attest that I've never recieved support from any commercial vendor that surpassed the support I've recieved from the F/OSS community. If support and stability are really a concern, then the proper answer would be for the gov't to fund a fully open solution. It would cost a fraction of any proprietary solution, and would be more secure to boot.

So maybe this could work out for the best, but I don't think that's how it's going to be played. Getting this right will take some education and advocacy.

Re:A stake through the heart of non-commerical lin

[Anonymous Coward]

You can't just go installing full disk encryption based on some open source solution that might or might not get updated

Right. So you make sure it gets updated. By paying someone to make sure it gets updated. How does paying a third party to sell you a proprietary solution make you less amenable to misfortune than maintaining the effort directly? I'd trust a publically funded open venture far more than I'd trust any shrinkwrap binary. Leading commercial vendors go belly up all the time. Then what do you have? On the other hand, F/OSS solutions can be maintained as long as necessary. Furthermore, if the specifications are open, there can be real competition to produce the best implementation. If the solution is proprietary, there's really no competition at all.

Stop using my taxes to subsidize crapware.

Re:unpopular data/facts, not "personal data"

[Cerebus]

DoD CACs have three key pairs; two for signing operations and the third for encryption. The encryption key is escrowed at generation to allow recovery by both user (when getting a new set of keys) and by law enforcement. It's the encryption key that will be used for FDE, generally by wrapping the bulk encryption key. Additional administrator keys are not strictly necessary where the CAC encryption key is being used to wrap the bulk volume encryption key, but the ability is desirable from an operational point of view. FWIW, the admin keys will be CAC keys as well, anyway.

It's understood that it's a requirement to be able to boot the system *without* admin involvement--it might be the admin you're investigating, or LE is worried about alerting the investigation target. That's why the CAC requirement is there, among a couple of other good reasons (for example, strong identification of who booted the system).

FWIW, it's fun to see things I work on show up in /. :)

Re:A stake through the heart of non-commerical lin

[Cerebus]

The built-in FileVault on OS X is pretty good. It's not full volume (it's per home directory), but since on OS X all user data is in the home directory anyway that should be less of a concern. Basically, FileVault creates an encrypted disk image, copies the homedir into it, and erases the homedir. The disk image bulk key is wrapped with a key derived from the user's password, and with the recovery credential. At login, the encrypted disk image is mounted over the user's homedir and away we go.

In re: enterprise management, FileVault recovery credentials are actually an RSA private key and a certificate stored in the System's FileVault keychain. While a recovery *password* is used, the password *only* unlocks the RSA private key. The certificate is used to wrap each disk image's bulk key, and the RSA private key is used to unwsrap it. This is actually very neat, and here's why:

An admin creates a single recovery credential on one machine. He copies the FileVault keychain to secure media and stores it away. Then he *deletes the RSA private key* from the FileVault keychain. New FileVaults can still be created because the certificate is still there. This stripped-down FileVault keychain is then deployed to systems in the enterprise (pick your poison here; it's *just a regular file*), and users can turn on FileVault at will.

If you do it this way, you now have a single recovery credential to manage for the entire organization. No actual recovery key exists on the system, so there's no chance an intruder can get access to the encrypted images (assuming they're unmounted) by exploiting the recovery credential. But an admin can recover FileVault users simply: log in, copy the master FileVault keychain (the one with the RSA public key in it) over the existing one, and do a recover operation.

Note also that OS X can encrypt the page file as well. It's on the Security prefpane separate from FileVault.

Link to Story on Lost Memory Keys in Afghanistan

[Cassini2]

http://it.slashdot.org/article.pl?sid=06/04/13/041 7200

Mod parent Informative

[Anonymous Coward]

Mod parent Informative, please

with all respect to Terje

[SethJohnson]

I know when you start spouting off unrequested advice, you run the risk of condescending the other person. I mainly wanted to take advantage of the post to illustrate to readers that it's scenarios like that where people go 'ah-hah!' and strike it rich by putting their own company together. By no means do I want to tell people what to do with their lives. Whatever company that Terje works for is lucky to have him.

Seth

Re:A stake through the heart of non-commerical lin

[tbo]

Be careful with trusting FileVault on a newer Mac laptop. By default, any reasonably new Mac laptop has Safe Sleep enabled, which means the unencrypted contents of memory will be written to disk every time you sleep the computer, thus negating most of the security benefits of FileVault. You can turn off Safe Sleep using the pmset command to change the hibernatemode, but it may be reset any time any Energy Saver preference is changed.

Because of these issues, I wouldn't consider FileVault ready for high security on laptops in an enterprise environment.

Re:unpopular data/facts, not "personal data"

[Anonymous Coward]

"Users should require minimal or no training to utilize the product".

There we go again, no reminders not to leave it on the backseat of the car, or to write the password down on a post-it note. Process people - process. Or - can you email me a new certificate - I misplaced the old one.

There are hardware based devices that already widely in use that secure sensitive information. So now a software solution for lesser departments, that will have a backdoor, and note, *silent* updating.

This puppy is doomed, and like voting machines, the list of wants does not match availability. They should add one more thing to the list - "Willingness to be audited by someone like Schneier or the BSD group" , because the nitwits fail to mention key management, and key exchange, because the update is going to have to store the key.

Re:Fear: When you see B8 00 4C CD 21 and know what

[Terje Mathisen]

I haven't written pure asm programs for the last 10+ years, but I'm willing to be the sequence in your .sig is:

  B8 - MOV to AX
  00 4C Immediate 16-bit constant, in LE order

I.e. MOV AX,4C00h

  CD 21 is of course INT 21h which is the Dos OS interface.

Since 4Ch in AH is the 'Exit program' Dos call, and AL = 0 is the return value, the code above will stop the current program, with an errorlevel of zero, i.e. no error.

OK? :-)

Terje

Re:A stake through the heart of non-commerical lin

[goombah99]

yes but that kind of information security is not the objective of the FDE push.

Re:Fear: When you see B8 00 4C CD 21 and know what

[throx]

Yep, exactly. :)

Although, someone pointed out to me once that it makes sense in 6502 assembly as well.

Re:Fear: When you see B8 00 4C CD 21 and know what

[ralphdaugherty]

Although the premise of the thread was bogus, I'm glad I got to see your posts, Terje.

  rd

What NEEDS to be done (by us)

[RedBear]

All that said, I think that giving a contract like this to a commercial vendor developing proprietary software would be... unfortunate. Funding addition of missing, necessary features to TrueCrypt would be a one-time expense (rather than one which scales with the number of systems deployed), and would benefit the private sector as well.

Unfortunately we're never going to get the government to use free/open source software, no matter how good, especially for something like this, i.e. security related. What really needs to be done is for a number of genius Linux and Mac OS X developers to join the TrueCrypt project in order to bring it up to feature parity on all three of the most common platforms. Of course TrueCrypt doesn't actually do "full disk encryption" as in encrypting the entire system drive so that you have to input a password to even boot up. AFAIK TrueCrypt can only encrypt non-system partitions, disk images and disks. So that's a big hurdle to overcome, which may require assistance and cooperation from both Apple and Microsoft. Good luck with that, of course. But TrueCrypt is the only thing out there that even comes close to being able to do this.

At the same time the community needs to start a foundation to market a commercially rebranded and "certified" version of the resulting open-source product that would be acceptable to governmental and corporate entities. Sort of like the way corporations go with Netscape when they won't touch Firefox.

Without these steps, non-Windows platforms haven't got a snowball's chance in hell of being allowed in government offices after this program hits the street. Which is very unfortunate indeed.

Re:A stake through the heart of non-commerical lin

[Cerebus]

Actually, it is. Securing the page and hibernation files are as important as the data residing elsewhere on the disk. "Data at rest" refers to sleeping systems as much as powered down systems. This is why EFS doesn't suffice by itself to meet the OMB mandate for FDE; EFS doesn't protect page or sleep files, while FDE solutions work at the FS driver level and can do so (properly configured, of course).

I remember a previous time this arose, back in 1999 in a discussion with the Kerberos PM at Microsoft. It had occurred to me on the plane out to Seattle that MS's new support for power management--even on servers!--put Kerberos tickets at risk if the system was put to sleep. It was a fun conversation: "Tickets are held in LSA memory, right?" "Yes." "And as part of its protections, LSA memory is never swapped out to disk, right?" "Yes." "What happens when the system goes to sleep?" "... We'll get back to you on that."

Re:A stake through the heart of non-commerical lin

[goombah99]

Actually it's not. It could be as you say. And it would be desirabe too. Indeed macs already implement a secure swap. Not sure about hiberation. But as I said it's not what the government is concerned about when it mandates FDE. Others might have other objectives. in this case it's not high level security but simply low probability of data spillage. Obvious you are right there is some exposure if the hiberantion swap is theoretically accessible. But it's not a big exposure given the normal usage pattern.

0-day 'sploit in -

[Geminii]

3, 2, 1...

Re:A stake through the heart of non-commerical lin

[tbo]

But it's not a big exposure given the normal usage pattern.

Actually, it's a major real-world vulnerability in Apple's FileVault home directory encryption. The default hibernation mode ("Safe Sleep", in Apple's terminology) writes the text of any documents you might have open and in memory to disk, as well as also writing out the login password in plaintext. I've personally verified the former claim, and heard fairly reliable reports of the latter. In a typical Mac setup, the login password will decrypt the FileVault "protected" home directory.

From what I've seen, given root access (or physical access, which amounts to root) to a Mac laptop that had been put to sleep with "Safe Sleep" enabled, an attacked could have access to all the data within minutes.