Self-encrypting deception: Weaknesses in the encryption of solid state drives (SSDs)

In the past few weeks I have been looking into the fallout from the paper [PDF] by Carlo Meijer and Bernard van Gastel from Radboud University, the Netherlands titled “Self-encrypting deception: weaknesses in the encryption of solid state drives (SSDs)”.

From the paper’s abstract:  “In theory, the security guarantees offered by hardware encryption are similar to or better than software implementations. In reality, we found that many hardware implementations have critical security weaknesses, for many models allowing for complete recovery of the data without knowledge of any secret” … “This challenges the view that hardware encryption is preferable over software encryption. We conclude that one should not rely solely on hardware encryption offered by SSDs.”

That is a pretty alarming conclusion for customers that rely on SEDs. Having worked in the development of software FDE and the management of hardware FDE for more than 15 years, I have a view about what the industry needs to do differently moving forward.

However, before I share that opinion let me provide some practical advice for those customers who have SEDs today:  Don’t Panic;  I polled the SSD manufacturers whose SED models and firmware combinations are listed on our web site as being combatable with SecureDoc https://www.winmagic.com/drive-compatibility?manufacturer=All.  I asked them if their TCG Opal implementations were vulnerable, and if so, what recommendations they offer to mitigate the vulnerabilities.  Some came back and told me that only older versions of their drive are impacted, and others said none of their drives are impacted. (And some had not responded yet at the time of posting, but I will update the website when they do).

Based on the drive manufacturer responses, I have marked impacted drives on our compatibility list as:

“*SW: Consider SecureDoc software encryption to mitigate SED vulnerabilities”

or

“*FW: Update firmware else consider SecureDoc software encryption to mitigate SED vulnerabilities”

By “consider”, I mean for you to do your own risk assessment.  Use SecureDoc SES to get a report of the SEDs in use in your organization.  Cross-match them with the *SW and *FW marked drives on our web site.  If you get matches, and the drive is likely to contain very sensitive info, for example your CEO’s laptop, then replace the SED or encrypt with SecureDoc software encryption.   If an SED firmware fix is available (*FW) from the drive manufacturer, you can consider that too. WinMagic IT performed this analysis internally and found only a small percentage of our drives in use here at WinMagic were impacted.  Thus, the “Don’t Panic” advice.

In the longer term, I believe the solution for preventing some, or most of these types of these security implementation mistakes are a formal security evaluation.   The Meijer and Gastel paper lists a number of possible security issues with hardware encryption:

V: POSSIBLE SECURITY ISSUES WITH HARDWARE ENCRYPTION:

A. Password and DEK not linked
B. Single DEK used for the entire disk
C. Lack of entropy in randomly generated DEKs
D. Wear leveling
E. Power-saving mode: DEVSLP
F. General Implementation Issues

WinMagic is a member of the Common Criteria international Technical Community for Full Drive Encryption and contributed to the collaborative Protection Profile for the Encryption Engine.  (CC iTC for FDE / cPP EE).  (A PDF of my presentation on the “Development of cPPs for Full Disk Encryption” can be found here, for background.) Within the collaboration, we had a look at the Security Functional Requirements (SFRs) in cPP EE, and I would say that it pretty much has A to F covered.  Having a cPP EE security evaluation is no absolute guarantee that a product (Target of Evaluation) is free of implementation issues, but it is certainly a huge step forward.

The last sentence of the body of the Meijer and Gastel paper states: “Opal’s compliance tests should cover the implementation of the cryptography and these tests should be independently assessed.”  However, the paper does not acknowledge cPP EE or the TCG Storage Work Group’s Storage Certification Program. (WinMagic is a member of the TCG Storage Work Group, as well):
TCG Storage Work Group Storage Certification Program PDF

The good news is that the Storage Certification Program already is in place.  It already requires that each participating device vendor be required to have their product successfully evaluated against the most recent version of cPP EE using a Common Criteria licensed laboratory, as well as pass a set of interface compliance tests.  The way forward is for customers to seek out and demand Opal drives that passed the Storage Certification Program.  The program is relatively new. There were no drives published on the certified list as of posting this blog, but let’s hope Meijer and Gastel’s excellent work spur some drive manufacturers to get certification soon.

Previous Post
Your Feedback Is Important To Us
Next Post
Full Drive Encryption, Key management and MBAM