The hardware world is full of badly thought out implementations, from the inconvenient to the utterly incompetent, and today we have one of the latter. Bitlocker and other popular encryption tools can use software or hardware to encrypt and store the data encryption key, with many opting for the accelerated hardware encryption baked into many SSDs. This has turned out to be a bad idea, as tests on a variety of models show you can grab an encrypted disk, plug into the debug ports and convince it to accept any value as an authorized DEK and give you full access to the data on that drive. This is in part due to the hardware not using the owner's password for encryption … at all. The Register's article offers a suggestion, which is to make use of software encryption methods which do incorporate the users password and can be set to actually not use the same DEK across the entire drive.
Read on for suggestions on solutions which should mitigate this flaw and which can coexist peacefully with hardware encryption.
"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."
Here is some more Tech News from around the web:
- Robots, Wearables, Renewable Energy, Oh My: The Winners of the 2018 Hackaday Prize Announced
- Intel Skylake and Kaby Lake CPUs vulnerable to Portsmash side-channel attack @ The Inquirer
- Strange snafu misroutes domestic US Internet traffic through China Telecom @ Ars Technica
- Apple's T2 chip is blocking Linux from booting on new Mac hardware @ The Inquirer
- What the PUC: SK Hynix next to join big boys in 96-layer 3D NAND land @ The Register
- Beyond the lithium-ion battery @ Physics World
- Microsoft is porting the SysInternals library to Linux @ The Inquirer
- Cougar Fortress Gaming Backpack @ TechPowerUp