This security advisory came after two security researchers from the Netherlands, Carlo Meijer and Bernard van Gastel, issued a draft paper outlining vulnerabilities they discovered. Here is the abstract summarising the problem:
We have analyzed the hardware full-disk encryption of several SSDs by reverse engineering their firmware. 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.
If you have seen the paper, you can read about all the different vulnerabilities. I will concentrate on the two main ones.
SSD Hardware Encryption Security
Microsoft knew there was a problem with SSDs. So in cases of self-encrypted SSDs, Bitlocker would allow the encryption used by the SSDs to take over. Unfortunately, for Microsoft, this didn’t solve the problem. More from Meijer and van Gastel:
BitLocker, the encryption software built into Microsoft Windows will rely exclusively on hardware full-disk encryption if the SSD advertises supported for it. Thus, for these drives, data protected by BitLocker is also compromised.
The vulnerability means that any attacker who can read the SEDs user manual, can access the master password. By getting access to the master password, attackers can bypass the user-generated password and access the data.
Fix Master Password Vulnerabilities
In reality, this vulnerability would seem to be quite easy to fix. Firstly, the user can set their own master password, replacing the one generated by the SED vendor. This user-generated password would not then be accessible to an attacker.
The other option would seem to be to set the Master Password Capability to ‘maximum’, thus disabling the master password altogether.
Of course, the security advisory comes from the assumption that the average user believes that an SED would be safe from attackers, so why would anyone do either of these things.
User Passwords and Disc Encryption Keys
Another vulnerability is that there is no cryptographic binding between the user password and the disc encryption key (DEK) used to encrypt the password.
In other words, someone could look inside the SED chip to find the values of the DEK and then use those values to steal the local data. In this case, the attacker would not require the user password to get access to the data.
There are other vulnerabilities, but following the lead of pretty much everyone else, I’m just going to give you the link to the draft paper, and you can read about them all there.
Not All SSDs May Be Affected
However, I would like to point out two things. Firstly, Meijer and van Gastel only tested a fraction of all SSDs. Do the research of your SSD and see if it may have a problem. Here are the SSDs the two researchers did test:
Attackers Need Local Access
Also note that this needs local access to the SSD as attackers need to access and manipulate the firmware. This means that your SSD and the data it holds is, theoretically, safe.
Having said that, I don’t mean that this situation should be treated lightly. I will leave the last word to Meijer and van Gastel,
This [report] 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.
Wise words indeed.
Have you discovered an unlisted SSD that has the same security issue? Let us know in the comments below.
RELATED POSTS TO CHECK OUT: