Hardware Based Full Disk Encryption Is Almost Here…Now what?

As many of you know, the Trusted Computing Group (TCG) was an initiative started by some well-known technology companies to help standardize and implement Trusted Computing.  One of the first “products” to come from this was the Trusted Platform Module (TPM).  There are various vendors that take advantage of the TPM chip for security related functions.  (Full disclosure:  Symantec is a member of the Trusted Computing Group.)

The next significant “product” to come from TCG is the Opal standards for Self Encrypting Drives (SED).  The Opal standard is an industry standard for any hard disk drive (HDD) manufacture to sell SEDs that would comply with these standards.  Now what this means, is that these HDDs will have encryption already built into the hardware.

“Great!  We won’t need to evaluate any of the software encryption vendors out there.  We can simply just buy SEDs from the major HDD manufactures and deploy them to our users and be fully encrypted and compliant,” you say.    

Well it’s never that simple…

Opal based HDDs have many advantages.  These include “always-on encryption,” full data-bus performance, and the ability to do a NIST approved cryptographic disk erase instantly.  These are all great reasons to move to an Opal based drive.  

However, there are some disadvantages as well.  Currently, one of the biggest disadvantages is that Opal based HDDs are difficult to procure.  If you check your favorite retailer or distributor, you’ll be hard-pressed to find an Opal drive that can be purchased immediately.  It is however expected that these drives will be much more available in the later half of 2012.  

Depending on your company’s requirements, you may or may not have a need for FIPS validated HDDs.  But, if you do need FIPS, then there’s a premium to pay for FIPS validated HDDs.  There are essentially two premiums to pay.  The first premium is the SED Opal compliant drive over a standard non-encrypting drive.  The second premium then becomes the FIPS certification.     If you really want to take advantage of the full data-bus performance for an encrypted HDD, then you’ll want a Solid State Drive (SSD), but you really will be paying a premium then!   I have to believe that only the truly hardcore users can fully take advantage of the increased performance of a SED and SSD combination.

The next issue with SEDs is how do you physically roll out the new HDDs to your user population?  For each user/endpoint, you would physically have to image their existing HDD to the SED HDD.  After that, you would then have to properly and securely erase or dispose of the original HDD.  If not, someone is going to have a field day dumpster diving.  Also, with today’s HDD capacities, it might take quite a bit of time to image a user’s 250GB+ HDD.  You multiply this by the number of users/endpoints you have and this could easily become a multi-year project.  Remember, each HDD you are replacing becomes a liability unless it is properly disposed of.  Time in this case, is not on your side since there’s always a probability that someone whose endpoint is not encrypted loses their device while waiting for the SED replacement.

The biggest issue for SEDs, however is the management.  Or, I should say, the lack of management out of the box.  How do you manage the users, the recovery keys, policies, and reporting?  You see, the HDD manufactures followed the Opal standard for software to interface with the HDDs.  They, however, do not provide any type of software to manage these HDDs at all.  This is where the various software vendors come into play.  You will still need the ability to manage these SEDs.  You will need the ability to recover the keys should the user forget their passphrase or need access for forensics.  You will need to enforce security policies.  You will need to be able to do reporting for compliance.  Merely having built-in encryption on the HDD that is Opal compliant will not pass an auditor’s audit.  You need to prove that the endpoint was properly encrypted at the time it went missing.  Saying it was encrypted will not be sufficient.  Per the various laws, you would then need to disclose the breach to the public and have your company’s reputation tarnished by the media and the public.  

Now you might be trying to figure out what my agenda is.  To be honest, there is no agenda; this is really just food for thought.  I believe in playing devil’s advocate and always looking at things from both sides – is the glass half empty or half full? With that said, the release of Symantec Endpoint Encryption Full Disk Edition will be able to manage Opal compliant hardware.  Thus, I have every reason to be pointing out the strengths of Opal and none of its weaknesses since Symantec sells the software to help manage, store recovery keys, enforce policies, and report on the status of the endpoints.  I should also point out that if absolute speed is not your first priority, then PGP Whole Disk Encryption (WDE) might be of better value.  You would really need to do a cost benefit analysis to see if SEDs are worth it for your company.  I will say that when PGP WDE is on hardware that has AES NI, the performance “hit” is not perceptible by users at all.  The only way to see the difference in performance would be to use performance-measuring software.  If you’d like even more performance, you can also choose the cipher bit strength.  By default, PGP WDE uses AES 256.  PGP allows the InfoSec admins (via policy) to use AES 128 as an option.  The combination of AES NI and AES 128 cipher on an SSD would satisfy even the most demanding SSD users.  (AES 128 can also be used on standard spindle HDDs.)

Don’t forget, you will have to pay for the SEDs (more if it’s FIPS validated), and also the management of the SEDs regardless of which software vendor you choose.  What is the true total cost of the increased performance?

Further reading:
For those of you that believe that AES 128 is not secure enough, please take a look at this blog posting:  http://lukenotricks.blogspot.com/2010/04/aes-128-versus-aes-256-encryption.html