SSD and safety.

[ggg...@gmail.com]

Some months back I was going to send a computer in repair.  I discovered there is no program to clear an SSD.  

Some years ago I was reading about how an SSD did wear leveling, and recovered from errors.  The article claimed that often the SSD came with more memory than was listed.  If, in the course of normal operations if found a bad section, it would somehow mark that area for "Do Not See or Use" and use the extra, secret memory space to do the work that was for the disabled section.

I am guessing it is just that in normal operations for Qubes OS, such trivia does not matter.  Don't let the evil power groups get their hands on the SSD.   Then the potential loss of data is pretty small.   Unless the SSD firmware can be tricked out in some way.

[Steve Coleman]

On 2/26/20, ggg...@gmail.com <ggg...@gmail.com> 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.

Any used, free space, or damaged memory blocks get reset right along
with the user data. The entropy values stored internally on that
drive get reset so even someone having the prior password can still
not regenerate the same encryption key to unlock the drive. All memory
blocks that ever had your data will be meaningless 1's and 0's.

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
in an instant. If you think you need a non-recoverable "panic-button"
then the above command will do nicely. Nobody, not even you, is ever
going to see that data again. If you also used software based
encryption on top of that partition then you can be doublly sure that
your personal information can never be recovered.

If you install the "Pre-Boot Authentication" (PBA) to unlock the
encrypted drive during the initial boot cycle then you have the
additional advantage that the boot partition locking range can even be
made read-only while the data is at rest. When doing this even an
Evil-Maid system admin won't be messing with your system. Just
remember to make it writable again before trying to apply any updates
to your boot partition.

Note: With enabling these SED capabilities on your primary drive you
will likely be giving up laptop "suspend" capability. If you
absolutely need to protect your data then this is a fair trade-off
since the suspended memory image would be far too dangerous to leave
laying around anyway. A hot-plug attack is the achillies heel to an
Opal drive, so powering down is important anyway.

https://github.com/Drive-Trust-Alliance/sedutil/wiki/Encrypting-your-drive
https://github.com/Drive-Trust-Alliance/sedutil/tree/master/LinuxPBA
http://chrisarges.net/2018/02/16/using-sed-encryption-on-disks.html

[brenda...@gmail.com]

On Wednesday, February 26, 2020 at 3:37:27 PM UTC, Steve Coleman wrote:

On 2/26/20, ggg...@gmail.com <ggg...@gmail.com> 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.

[brenda...@gmail.com]

PS - don't experiment with erasing drives on your daily driver. the drive is going to do what you asked it to do, no matter, say, whether you booted on that drive or not. POOF!

[Daniil Travnikov]

What do you think about this product?

https://istorage-uk.com/product/diskashur-pro2/

Maybe this better then Opal?

[brenda...@gmail.com]

The diskashur and similar projects will come under the same scrutiny as SED devices’ built-in TCG Opal: that the encryption layer is closed source and not publicly auditable (unlike LUKS w/dm-crypt under Linux which is auditable).

The summary of my position is: use the hw encryption features available, but also use open-source software encryption on top. Belts and suspenders.

B