Unsolved
6 Posts
0
1549
XPS 13 9360 and lack of SED support
It would be nice of Dell to add support for self encrypting NVME SSD's to their BIOS. I know there isn't a massive performance improvement over Bitlocker's software encryption, none the less it's annoying to have a drive that is capable of this functionality and to not be able to use it.
I noticed that issues with SED were fixed on the Latitude 7480 back in 2017, yet still none of the possible options work on the XPS 13.
- Fixed SED (NVMe type) issue in AHCI mode when with DDP|E. 5/25/2017
- Fixed NVMe SED booting issue (in AHCI mode) with DELL DDP|E Pre-Boot Authentication activated. 8/14/2017
jphughan
9 Legend
9 Legend
•
14K Posts
0
December 13th, 2018 07:00
First, to be clear, it's not that self-encrypting NVMe drives aren't supported. It's that Class 0 hardware encryption, implemented by setting an HDD password, isn't supported on NVMe SSDs. Other mechanisms of hardware encryption such as TCG/Opal and BitLocker eDrive are both supported on NVMe SSDs, but those aren't used as frequently.
That said, Class 0 hardware encryption can create more trouble than they're worth over software encryption in a lot of scenarios. I just went through the ordeal of helping a friend recover data from his 860 Evo that he'd installed into his Latitude E7440. He'd enabled encryption via HDD password, and later his laptop died. I installed the SSD into my XPS 15 9530 and saw the HDD password prompt, but the password wasn't accepted -- and yes we were definitely entering the right password because my friend had been entering it every day for years. We even tried different keyboards. I ended up having to find another Latitude E7440 to get the drive to unlock -- so apparently HDD passwords aren't fully standardized across the industry, or even within a given company's laptop models. Fortunately a family member had one, but that is not ideal. With BitLocker I could have recovered that drive from anywhere.
There's also the fact that self-encrypting drives were recently shown to be almost useless due to massive flaws in their encryption implementations. Did you not see articles like this one about that disclosure? Granted, the researchers only tested a handful of SSDs, but on the other hand they found huge problems in 100% of the SSDs they tested, which wouldn't leave me with a lot of confidence in the others.
jmdomini
6 Posts
0
December 14th, 2018 15:00
I was thinking more along the line of OPAL, like at the link below. It's a no go however because the BIOS isn't capable of seeing the shadow MBR and booting from it to unlock the drive.
https://github.com/Drive-Trust-Alliance/sedutil/wiki/Encrypting-your-drive
That said, if it's truly as easy to defeat hardware encryption as the article you linked makes it sound then you're right that it isn't worth it.
ZManWithThePlan
1 Message
0
April 24th, 2020 10:00
TCG/OPAL 2 hasn't been defeated to this day. The hardware encryption that was easily defeated was related to drive firmware bugs in Class 0 encryption (BIOS HDD password).
With that said... I have had terrible luck trying to get the ShadowMBR working, even on a SATA III SSD. I have been able to mitigate that issue by just booting off the RESCUE64 USB image, unlocking the drive by running `linuxpba` after logging in as root. It prompts for the password, you enter it, and the computer reboots. Remove the USB before it restarts and you are in.
UPDATE: I tried to to do this with a Samsung EVO 960 on a Dell Inspiron i7-7779 and was not able to boot into the OS after installing QuebesOS. The OS installation appeared to go well, but after unlocking the drive and rebooting, "No bootable devices found". It seems likely that Dell BIOS does not play nice with TCG Opal 2 boot drives.