This article is more than 1 year old
Solid state of fear: Euro boffins bust open SSD, Bitlocker encryption (it's really, really dumb)
Security experts frantically facepalming at stupid design
Fundamental flaws in the encryption system used by popular solid-state drives (SSDs) can be exploited by miscreants to easily decrypt data, once they've got their hands on the equipment.
A paper [PDF] drawn up by researchers Carlo Meijer and Bernard van Gastel at Radboud University in the Netherlands, and made public today, describes these critical weaknesses. The bottom line is: the drives require a password to encrypt and decrypt their contents, however this password can be bypassed, allowing crooks and snoops to access ciphered data.
Basically, the cryptographic keys used to encrypt and decrypt the data are not derived from the owner's password, meaning, you can seize a drive and, via a debug port, reprogram it to accept any password. At that point, the SSD will use its stored keys to cipher and decipher its contents. Yes, it's that dumb.
The egghead duo tested three Crucial and four Samsung models of SSDs, and found them more or less vulnerable to the aforementioned attack, although it does depend on their final configuration. Check the table below for the specific findings and settings to determine if your rig is vulnerable. All of the drives tried, and failed, to securely implement the TCG Opal standard of encryption.
"The analysis uncovers a pattern of critical issues across vendors," according to the researchers. "For multiple models, it is possible to bypass the encryption entirely, allowing for a complete recovery of the data without any knowledge of passwords or keys."
Rowhammer RAM attack adapted to hit flash storageREAD MORE
In particular, the researchers said, the SSDs fail to cryptographically tie the owner's password to the actual data encryption key (DEK), both of which are stored in the drive. The SSD's builtin processor and firmware are free to use the DEK whenever they like, but only choose to do so when the correct password is supplied. If the firmware is reprogrammed or manipulated by someone with physical access to the device's debug ports, it can be made to skip the password stuff, and go straight to using the DEK.
Really, the DEK should in some way be derived from the owner's passphrase. No passphrase, no complete key. In reality, the SSDs cheat. What's more, many drives use a single DEK for the entire flash disk, even though they offer to secure different sections with different passwords.
In practice, the Radboud duo say they were able to decrypt the data on a number of SSDs simply by connecting to the drive's debug interface on its circuit board, and modify the password-checking routine in the firmware to accept any passphrase before accessing the DEK to encrypt or decrypt the device.
In other cases, the researchers could retrieve the keys by modifying the drive's firmware, or by exploiting a code injection vulnerability that would also allow an attacker to modify the password routine – both require physical access to the drive.
One possible way to secure these devices, the boffins stated in their paper, is to ensure the secrets needed to decrypt a drive are stored off the equipment itself. That can be achieved by using full-disk encryption software that runs on the host computer, and encrypts and decrypts data before it enters and after it leaves the drive using a key derived from a passphrase supplied by the user.
"The results presented in this paper show that one should not rely solely on hardware encryption as offered by SSDs for confidentiality," the paper explained. "We recommend users that depend on hardware encryption implemented in SSDs to employ also a software full-disk encryption solution, preferably an open-source and audited one."
Unfortunately, the pair also note that some popular data encryption systems, including the BitLocker tool Microsoft uses in Windows 10, do not use software encryption for SSDs and rely on the drive's vulnerable hardware encryption.
Cryptography guru Matt Green pulled no punches today...
Being earnest now: Microsoft trusting these devices to implement Bitlocker has to be the single dumbest thing that company has ever done. It’s like jumping out of a plane with an umbrella instead of a parachute.— Matthew Green (@matthew_d_green) November 5, 2018
In those cases, Meijer and van Gastel recommend users and admins look to instead use something like VeraCrypt, or switch BitLocker to use software encryption rather than the drive's baked-in crypto.
"In particular, VeraCrypt allows for in-place encryption while the operating system is running, and can coexist with hardware encryption," they said. "Furthermore, BitLocker users can change their preference to enforce software encryption even if hardware encryption is supported by adjusting the Group Policy setting."
In an email to El Reg, one of the researchers, Bernard van Gastel, told us:
We only looked at the aforementioned models, due to our expertise with e.g. the Arm architecture used in these drives. That being said, the TCG Opal standard that is used is very difficult to implement correctly. The specification has many requirements, and is rather involved.
An easier standard would help vendors with their implementation and making these implementations more secure. From a security standpoint a reference implementation should be made available publicly, so the security community can look into the design and its implementation. This makes it easier for vendors to implements these encryption schemes.
Our general advice to all users of hardware encryption in SSDs is to not solely rely on hardware encryption as currently offered and take additional measures such as installing the VeraCrypt software encryption.
We've pinged Microsoft, Crucial, and Samsung for comment. ®