SSD hardware encryption vulnerabilities (Radbound University)

[brenda...@gmail.com]

[Note: my position is that hardware disk encryption is useful for protecting against opportunistic attacks, whereas software disk encryption is best for protecting against targeted attacks. Use both.]

1. PR Notice: https://www.ru.nl/english/news-agenda/news/vm/icis/cyber-security/2018/radboud-university-researchers-discover-security/
2. Advisory: https://www.ru.nl/publish/pages/909275/advisory.pdf
3. Paper draft, very exciting read!: https://www.ru.nl/publish/pages/909282/draft-paper.pdf

There are two CVEs here, which I will attempt to summarize:

CVE-2018-12037: user supplied password is not (or not entirely) used to encrypt the disk encryption key stored in the flash. Key can be extracted via various techniques. Examples given:
- ATA password (Maximum and High modes) on internal SSDs such as Crucial MX100,MX200,MX300
- ATA password (only in HIGH mode) on internal SSDs such as Samsung 840 EVO and 850 EVO
- Proprietary unlock software on portable SSDs such as Samsung T3 and T5

CVE-2018-12038: user supplied password (or bitlocker(!)/OPAL key) *IS* used to encrypt the disk encryption key stored in the flash. However, care was not taken in firmware design to mitigate the logical->physical translation. Therefore the original unencrypted key (before reconfiguration) may still be recoverable somewhere in the flash if the original flash block was not erased fully as part of the wrapping of the key in the user-provided password/key.
- Samsung 840 EVO was vulnerable

Mitigations:
0. As suggested in the article (and in discussions on this list): always use software-based encryption. Note that Microsoft's Bitlocker utilizes hardware encryption when available by default for performance (using eDrive, a simple variant of OPAL). This can be disabled via group-policy, but it will not change the configuration of an already configured drive.
1. Don't use the Crucial MX100 and MX200. Oh, the horror. MX300 not much better either, so avoid.
2. If using ATA security on the Samsung drives, always set both the User *AND* Master passwords (utilize Maximum security mode).
3. TCG Opal implementation looks pretty solid on the Samsung drives. However 840 has a wear-leveling vulnerability in old key storage, so 850 or higher series is preferred.
4. Samsung claims their portable drive issues are resolved when moving to the v1.6.2 release of the unlocker. I'm doubtful.
5. Did I mention: always use software encryption as well?

My opinions:
1. Crucial and Samsung may have some excitement in their FIPS compliance workstreams.
2. I'm fairly certain the TCG Opal standards are written to require manufacturers to address these two issues: a) wrap the damn keys correctly and b) ensure old key material is erased. This is a failure of engineering, testing and compliance.
c) I've been peeved that the Samsung T3 and T5 drives, internally, are not TCG Opal, instead using a custom Samsung mechanism to lock/unlock their hardware encryption capabilities. The reason I was peeved: these are the only sources of 2TB mSATA drives which I would have loved to use with sedutil. Now I have a second reason to be peeved, which is that the custom mechanism was as crappy as Y2K-era ATA password protection.

Happy Monday,
Brendan

[jonbrown...@gmail.com]

Does this effect Qubes OS?

[Holger Levsen]

On Tue, Nov 06, 2018 at 07:09:52AM -0800, jonbrown...@gmail.com wrote:
> Does this effect Qubes OS?

no. (Qubes OS uses software encryption. You can however manually enable
hardware encryption like you can on any OS.)


--
cheers,
Holger

-------------------------------------------------------------------------------
holger@(debian|reproducible-builds|layer-acht).org
PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[brenda...@gmail.com]

On Tuesday, November 6, 2018 at 10:13:38 AM UTC-5, Holger Levsen wrote:

> On Tue, Nov 06, 2018 at 07:09:52AM -0800, jonbrx...@gmail.com wrote:
> > Does this effect Qubes OS?
>
> no. (Qubes OS uses software encryption. You can however manually enable
> hardware encryption like you can on any OS.)

Correct, it does not directly impact Qubes OS.

Based on my threat model (mostly laptop/data theft and criminal spyware...not things like NSA firmware implants), I have been considering utilizing OPAL/sedutil to enforce strict data separation on a dual booting QubesOS/Windows 10 system without having to pull hardware...where each booted system cannot see the existence of the other OS as the boot drive would appear to be a smaller physical drive to the OS.

The tiny, linux-based, *read-only* Pre-boot Authorization or PBA environment would require two different passwords to unlock the user-area of each OS to boot, and each OS area would be hardware encrypted with a key bound to the password used to unlock it (when properly implemented by the manufacturer!).

Without that kind of separation, I would never consider dual booting. If I had some different threats, dual-booting would likely not be appropriate, even with hardware-enforced separation on storage.

Therefore, attacks on TCG OPAL SSD implementations are interesting, to this QubesOS user anyway.

Brendan

PS - contemporary SATA/NVMe drives all come with this hardware capability and sedutil/PBA is free for personal use. The good-ish news that came out of the paper is that Samsung may have their OPAL stuff implemented securely in their 850/860/960/970 series devices.