On Wednesday, February 26, 2020 at 3:37:27 PM UTC, Steve Coleman wrote: > > On 2/26/20, ggg...@gmail.com <javascript:> <ggg...@gmail.com <javascript:>> > wrote: > > > I discovered there is no program to clear an SSD. > > If you are using an Opal 2 compliant SSD and had created an encrypted > range before formatting your partition then all that data disappears > instantly when you reset the SSD. The one requirement is the SSD drive > must be functional in oder to reset it, and it won't matter much if > there are unuseable blocks or file corruption as all the bits on the > drive, good or bad, get flipped all at once. > ...
> On the label of the Opal 2 SSD drive there would be a long hex PSID > number printed on it, and if you supply that # to the sedutil-cli > command: > > # sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID MYPSID /dev/sdc > > then everything previously stored on that drive becomes unrecoverable [Many users of Qubes aren't too keen on relying on the black-box/closed-source hardware encryption that comes on SED SSDs - can they trust it? They can't review the code/implementation. There have been in-depth analysis showing issues with both design as well as implementations with many devices. Their points are valid. However, I don't want to get into a long digression on the pros/cons.] In addition to what Steve said about ranges or PSID revert, most tcg opal devices support utilizing the same hardware crypto engine for "CLASS 0" encryption, which allows use of the ATA PASSWORD as an alternate unlocking scheme. This generally allows suspend if, say, your laptop supports the ATA PASSWORD method. Flipside is that generally the complexity of the password data sent to the drive is < 90 bits no matter what you choose. Sometimes substantially less (depends upon BIOS). I don't recommend relying on that for all of your security. If you use it, use LUKS on top of it as well. There's no performance loss, it's transparent (the drive was always doing it anyway, you just chose to lock it). My point, however, is that the ATA Password support under "TCG OPAL CLASS 0" comes with a nice side-benefit Generally, when utilizing TCG OPAL CLASS 0, when you send an ATA SECURE ERASE ENHANCED request to the drive, it actually simply rekeys the hardware crypto engine of the drive. So, if you have non-zero data in a block, then use the ATA SECURE ERASE ENHANCED command and then read the block, it will be scrambled. Send the command again, it's scrambled a different way. So, other than throwing the device into the Sun, my recommendation is always to: 1. Sample (non-zero) data (random block list) on the device. 2. Execute ATA SECURE ERASE ENHANCED. 3. Verify sampled data (same block list) is all scrambled. 4. Execute ATA SECURE ERASE ENHANCED again. 5. Verify sampled data (same block list) is all scrambled again. 6. TRIM the entire drive. 7. Verify sampled data (same block list) is all now zero'd data. 8. Execute ATA SCURE ERASE *NORMAL* (might erase additional data beyond user-readable data, depending upon manufacturer). BTW, if ATA SECURE ERASE ENHANCED does not scramble the data, but the drive supports the ATA SANITIZE command, then use ATA SANITIZE CRYPTO instead, should do the same thing. Brendan PS - paranoid people might say "well, maybe the drive is keeping a list of all keys, hey they are small". Possible. Maybe a flash-thrashing "fill entire drive full of random data" step will help a bit, assuming you're worried about user data left behind and not targeted exfiltration into non-user-accesible flash by a nation-state agency, etc. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/faff5ede-8399-4977-848f-54a3dc35af13%40googlegroups.com.
