Roger's Information Security Blog

Like a lot of companies we are trying to go to Windows 7 sooner rather than later. We skipped Vista and XP is starting to seem a bit old. One of the things holding us back is GuardianEdge’s Full Disk Encryption product. Here’s our timeline.

In October 2009 I asked GuardianEdge about Windows 7 support and Windows 7 64 bit support. They said both would available in version 9.5 due out in December 2009.

When GuardianEdge Hard Disk Encryption 9.5 was released (January or February), I found that there was no support for preboot authentication. Without preboot authentication, I think the encryption is pretty worthless. Support tells me 9.5.1 will include preboot authentication and be available in April 2010.

9.5.1 is released and I find it doesn’t work on my Toshiba Portege with windows 7 32 bit installed. I decide this may be a one-off. I’m the only one using the Toshiba so I try it out on a few Dell E6500 computers with Windows XP and Windows 7. This failed miserably. It turns out this was a known issue with Dell E6500 and GuardianEdge was working on a patch.

GEHD 9.5.1 patch 1 came out. While it fixed the assorted problems with the E6500, I now see in the release notes:

There are known issues with GuardianEdge Hard Disk on various configurations of the following Dell computer models
■ Dell E4310
■ Dell E6410
■ Dell E6510
■ Dell E5410, and
■ Dell E5510

Unfortunately the E6410 and the E6510 are two of the three systems listed on our standard configuration page. The third E4300, I suspect would really be the E4310.

GuardianEdge says this will be fixed in September 2010.

I wouldn’t this be surprised if this led to looking at other solutions and revisiting Bitlocker. I wrote about Bitlocker in March. These pretzels are making me thirsty.

GuardianEdge 9.5.1 patch 1 was released to address the Dell issues that I previously wrote about.

Support provided client installer packages so I could quickly see if this also fixed the issue I had with the Toshiba (sadly it did not).   Not sure if I’m going to get a chance to verify this patch resolves the Dell issue this week.   It is good news that this patch is out so quickly.   We need GEHD  9.5.1 working for our Windows 7 testing to progress.

<update>
I’ve tested with one Dell and Windows 7 32 bit.   patch 1 solved the original problem in that the computer now successfully boots when it has been shut down.   However when it is restarted it comes up with 5 dots on the screen after GuardianEdge authentication and goes no further.

I’ve been doing more testing with GuardianEdge 9.5.1 since my last post on the subject.   A Dell E6500 with Windows 7 64 bit wouldn’t get to the GuardianEdge pre-boot authentication screen.  I attributed that to issues specific to Windows 7 64 bit and possibly a OEM drive partition.   So I went ahead and tried to upgrade a Windows XP computer from GEHD 8.7 to 9.5.1.   It had the same issues.  I called support and apparently I didn’t get a memo they tried to send out to everyone who downloaded 9.5.1.

Since its release, we have confirmed reports of error conditions when the Hard Disk client v9.5.1 is installed or upgraded on a specific set of machines. 

The following machines are affected:

•     Dell E series ( excluding E6400 )
•     Dell M Series ( excluding M6500 )
•     Dell D830
•     Dell XT
•     Dell XT2

GuardianEdge is committed to releasing a software update that will address these machine-specific issues in the next few weeks and will inform you as soon as the update is available. We strongly recommend that you do not deploy the Hard Disk client v9.5.1 to these machines until this update is released.

Once again, things that could have been brought to my attention yesterday. 

Long time readers, and anyone who has ever Googled “Guardian Edge” recall my intense dissatisfaction with GuardianEdge 8.7 and Vista on my Toshiba Laptop. Everything old is new again.
GuardianEdge released 9.5.1 last month so we finally have support for Hard Disk Encryption with preboot authentication on Windows 7. The short version of the story is I’ll be finding out how good my Windows Backup is. I installed GuardianEdge Hard Disk 9.5.1 on my Toshiba Portege M780 and started encrypting. I shut the computer down, went home and the computer wont boot. When I hit the power button, I can get to the preboot authentication screen. The system fan is going full blast. It doesn’t do that normally. And 5 seconds later the computer turns itself off.
I called support and their advice is to use the GuardianEdge Access utility to recover my data and reinstall. Hope that backup worked. Not what I was planning to do tonight.
What am I supposed to do now. This gives me zero confidence to deploy this to others. While there are plenty of other dominos that need to fall in our Windows 7 project, getting a GE package for Windows 7 is an important one.
The recover /a option was grayed out. No problems were detected with the GEHD volume files. So I decrypted the drive and uninstalled GEHD. I was then able to use the computer. I have a lot of doubt right now about the ability of GEHD to encrypt Vista and Windows 7

I’ve been waiting for Symantec to buy GuardianEdge ever since they started selling a rebranded GuardianEdge encryption product. It seems every other endpoint security company bought a dancing partner over the past year or two and Symantec was merely renting.
When Symantec bought MessageLabs, I was very concerned. I like MessageLabs and was afraid of what Symantec would do to it. When Symantec bought IMLogic, I felt the technical support and the product vision totally went in the crapper. Fortunately MessageLabs had a strong position to prevent that from happening to them as well.
Regular readers of my blog will know I’ve had a lot of issues with GuardianEdge support over the years. At this point I don’t know if GuardianEdge support will be internalized by Symantec or remain as a separate team. Either way it can only get better.
I’m wondering what it means that they bought both PGP and GuardianEdge. It seems kind of redundant. PGP adds secure email. But I’m not sure what else. Not sure if PGP already has the mobile encryption that GuardianEdge currently licenses from TrustDigital.
I would expect that by the time of our next renewal encryption will be an option for a Symantec Endpoint Suite and our overall dollar spent will go down. I expect this purchase to be a good thing.

Like many organizations, we skipped Vista. So with Windows 7 we are facing the question “is Windows 7 good enough” or do we still need to pay for a third-party full disk encryption (FDE) product.
This question was asked back in 2006 at the SANS Desktop Encryption Summit. The FDE vender’s felt their product was better because:
1. Better Management tools
2. Mature product
3. Multiple OS support
4. No requirement for TPM.
BitLocker is no longer a first gen product. Let’s look at today’s reasons for purchasing or continuing to use a third-party FDE product.
BitLocker Minimum Requirements
“BitLocker stores its own encryption and decryption key in a hardware device that is separate from your hard disk, so you must have either a computer with a Trusted Platform Module (TPM) or a removable USB memory device.”
USB memory devices would tend to be stored in the laptop bag, so that isn’t a secure solution.
TPMs are an additional thing to manage. Perhaps it’s not as difficult as I envision. When I did a WAVE eval, I had to go into the BIOS to enable the TPM and set a master TPM password. That doesn’t scale.
“The computer must have been configured with an additional separate active partition to be used as a system partition.”
This extra step now happens automatically, so I don’t think that is a big deal.
“The BIOS must be compatible with TPM and/or support usb devices during computer startup”
It may be necessary to upgrade the BIOS. While probably not an issue on the newer computers we would be using, this could be an issue on upgrades in place.
None of these prerequisite requirements is particularly burdensome. However it leaves out one key minimum requirement: Vista or Windows 7 Enterprise. Our XP systems would still be on the current FDE product requiring two management methods.
OTHER BitLocker Considerations
1. Provable Encryption
With the current FDE product, if a computer is lost I would be able to tell that it was actually encrypted when it was last seen on $date $time. Can BitLocker say the same? I don’t know.
Many states have an encryption state harbor. Meaning if the lost system was provably encrypted, breach notification provisions do not apply.
2. Usability
The current FDE product syncs the domain password to the pre-boot environment. The user does not need to know a second password. The normal password requirements apply.
With BitLocker the PIN is just that. An enhanced PIN can be required but it is possible that some system BIOS will not support alphanumeric entry in the pre-boot environment. Does this PIN ever expire? It doesn’t seem like it.
3. Recoverability
The standard recovery method is to use a recovery password. This is a 48 digit number backed up to Active Directory. Enjoy typing that in when the user forgets their password.
This method is not FIPS compliant and must be disabled. Instead there are other two options
A recovery key is a 256 bit key that is saved to a flash drive. This method must be done by the end-user and they need to store the key securely. Obviously that isn’t enterprise ready.
The third option is a data recovery agent. A public key is distributed to all BitLocker protected devices. Someone with the matching private key (e.g. me) would need to be physically present at the computer. Apparently even then the OS drive must be installed on another computer running Windows 7 as a data drive.
So basically no recovery options work for us.
4. Standby
BitLocker protection is in effect only when the computer is turned off or in hibernation.
Our current FDE product protects in standby, hibernation or when the computer is off.
5. Enterprise Manageability
While BitLocker has caught up with third-party encryption products in its ability to encrypt USB drives there are still other areas where FDE vender’s shine. Many FDE vender’s can also encrypt phones and managed hardware based encryption products. It’s a lot more convenient to manage these devices through one vendor.
From my limited reading it seems that there are still a number of items that argue for the continued use of a non-Microsoft FDE product.

GuardianEdge put out a press release this week announcing Encrypted Drive Manager. This software will allow you to managed hardware encrypted hard drives as well as drives encrypted with GuardianEdge Hard Disk all from one platform. This will be released in Q2 2010. When I was evaluating GuardianEdge in 2007 they talked about these features so its nice to see it finally (soon to be) making it to market.
Hardware based encryption may finally be ready to ignite. The Trusted Computing Group has been working on standards so its not such a mishmash. Performing the encryption on hardware keeps the encryption keys out of memory so it isn’t vulnerable to cold boot attacks. There isn’t a CPU performance penalty as there can be with software encryption. Wiping a drive is as simple as removing the encryption key.
The main problem has been manageability. You need to be able to corporately manage accounts on the hardware encrypted drive just as you do with the software encryption. It has to be enterprise ready. Its necessary to be able to manage both software and hardware based Full Disk Encryption and GuardianEdge is going to allow for that.
I anticipate a time when the drives we order in our standard systems will all be hardware FDE capable and managed by GuardianEdge.

Recently I decided to look at upgrading our Guardian Edge Hard Disk Encryption to version 8.7. I was hoping it would resolve some of the flakiness with the version we currently have deployed.
What I found instead was more flakiness and tech support that I’m pretty sure must be sent through the babelfish before it sent to me.
One of the first things I ran into is that when upgrading you need to copy the old installation MSIs into the new installation directory. I sent Guardian Edge support an email and asked them:

• Why are the old files needed?
• Isn’t it normal for a MSI install to keep the installation files cached locally for repair and/or uninstall
• Isn’t it normal if the original install files are needed and they aren’t cached locally to silently check the original install source?
• Isn’t it normally to then prompt the user for the needed files rather than exiting the install with a “file not found” error
• If some clients are on 8.2.4 and others are on 8.5 and I’m upgrading to 8.7 can I just put the 8.5 install files in the directory or do I need to make a separate install package for upgrading from 8.2.4 (since 8.2.4 and 8.5 install files use the same name.

Which one of these questions was answered by support? If you answered not a one, you are correct.
Next I ran into a couple of strange issues. On a few XP computers, the Guardian Edge Framework upgraded to 8.7 but the Guardian Edge Hard Disk did not upgrade.
On my Vista computer, it would not install at all. I opened a ticket about the second case and was told that when creating the MSI install package the destination folder needs to be “full control”. Having read the install/upgrade guide, I had seen that. I asked what is meant by full control. The install directory already had permissions of Administrators:Full Control and System: Full Control. Guardian Edge support then wanted to set up a phone call for followup. I felt I’d asked a rather vanilla question, and decided to review the manuals. I found that the permissions on the folders where the MSI files are created is actually incorporated into the MSI. I’ve never seen anything like that before! I set the destination folder for the MSIs to Everyone:Full Control and recreated the install packages. This time I was able to install Guardian Edge Hard Disk Encryption onto my Vista computer.
At this point I thought everything was ok, in spite of the lack of support I’d received from Guardian Edge. A reasonable explanation was found for my install errors. I’d be able to go forward with a 8.7 upgrade.
Monday morning came and I booted the Vista laptop on which I had installed GE 8.7. Instead of booting I received an error “The EAFS volumes contain errors. Run Recover.”
I booted to a USB drive and ran “recover /a” to repair the Guardian Edge databases. This did not solve the problem so I opened another case with Guardian Edge. First I attempted to call their 866 number. That resulted in a long pause followed by a fast busy signal. Next I opened a case through salesforce.com. I described the error and what I had done thus far and asked if it was ok to use the 8.2.0 Hard Disk Access Utility on a 8.7 client. The response I got was to use the latest version but it didn’t answer what is the latest version or where to get it. I’m following up on that. I’m concerned because last time I asked for this utility they sent it FedEx rather than providing a ISO download.
I was so hoping to write something positive about Guardian Edge this month.

I am planning to upgrade to Guardian Edge Hard Disk Encryption 8.7. Its been over a year since we deployed 8.2.4 and I wanted to get some of the assorted fixes out to our computers.
While reading the release notes, I noticed a known issue with Symantec Endpoint Protection 11.

“Following the installation of GuardianEdge
Hard Disk on the Client Computer, a
Network Threat Protection message may
be displayed, alerting the end user to a
change in the EAFRCliADSI application.”

The solution is to allow IP6 over IPv4.
Personally I am not a big fan of this solution. Until I have a personal firewall that works with IPv6, I think we should default deny it. Until there is a need for IPv6, we should default deny it.
The solution doesn’t adequately explain the problem to me. I don’t use SEP11 to monitor what applications can go out (management overruled me). I’m thinking users would never be alerted if an application changed. Thus their workaround should be unnecessary.
I called support but that only resulted in a guy reading the release note back to me. I guess I’m going to upgrade the server and install 8.7 on my computer and see what happens.

After reading about a firewire memory attack against windows (also effects other operating systems). I figured it wouldn’t take long before someone demonstrated the use of that against full disk encryption. After all, why bother booting to USB, or freezing the RAM if you can just hook up a firewire connection and access the memory.
Today, I saw a Dark Reading article where a group/vendor has penetrated a Pointsec encrypted computer through the use of the firewire technique.

This simple attack takes advantage of the FireWire protocol and its ability to directly access and modify the RAM of a target machine with a FireWire port installed. Using a simple and readily available forensics software tool, it is possible to connect a FireWire cable to a computer, and within seconds bypass the Windows authentication and log in as a local administrator.

It is important to note that pre-boot authentication was not enabled on this computer. If it had been the attack would not have succeeded. I can’t imagine deploying FDE without pre-boot authentication. This article could have described an attack against any FDE vendor not using pre-boot authentication.
I’ve disabled the firewire port on my laptop. I haven’t looked at what it would take to disable the firewire port in an enterprise. Perhaps its time for more spelunking in devcon. Or may google will have an easy answer. I wonder how many “port control” products include firewire.