Hacker News Reader

Comment by digiown | Hacker News Reader

And this is why you always encrypt the drive with software. All of these methods seem to put a lot of faith into the drive controller doing what it claim it does, which you can never be all that sure about. Even Microsoft-backed Bitlocker would help here.

View on HN

Bitlocker can rely on the SSD encryption, so careful there too.

It has been software encryption for a many years now.

By default, yes. But it is possible to enable Bitlocker to use a SED directly.

Indeed, LUKS + F2FS for /home with an external key file imported into initrd solves a lot of issues.

Primarily, when an SSD slowly fails the sector replacement allotment has already bled data into read-only areas of the drive. As a user, there is no way to reliably scrub that data.

If the drive suddenly bricks, the warranty service will often not return the original hardware... and just the password protection on an embedded LUKS key is not great.

There are effective disposal methods:

1. shred the chips

2. incinerate the chips

Wiping/Trim sometimes doesn't even work if the Flash chips are malfunctioning. =3

> an external key file imported into initrd

This is exceptionally poor advice. This is why TPM exists. Unfortunately adoption is low with the Linux crowd because they still believe the misinformation from 20 years ago.

It is common to remote mount JBOD over initrd drop-bear ssh using sector level strip signature checking, predicted s.m.a.r.t power-cycle-count/hours/serial, proc structure, and an ephemeral key. SElinux is also quite robust in access permission handling.

TPM collocates a physical key on the same host, incurs its own set of trade-offs with failures or physical access in dormancy, and requires trusting yet another vendor supply chain. There are always better options, but since the Intel Management Engine can access TPM... such solutions incur new problems. Privilege escalation through TPM Sniffing is also rather trivial these days.

Have a great day. =3

People stopped using dedicated TPM about 10 years ago exactly because it's trivial to sniff it.

Nowadays you use the fTPM built inside the CPU. And if you don't trust the CPU maker, well, you have bigger problems.

A decade old hidden minix OS/IME probably shouldn't be trusted, regardless of company government ownership percentages. My point was the TPM method assumes no one with malicious intent works at these firms for $8/hour, patched your shipment en route as a state sponsored thief, or installs an OS that quietly mirrors keys into the cloud.

The best plans simply don't require secrecy. ymmv

Have a glorious day =3

You really shouldn't trust the CPU maker.

On Intel & AMD, both have a "hidden core" (i.e., a 4-core processor is really a 5-core processor), and they run proprietary, closed-source operating systems that literally no one outside of Intel or the NSA has any idea what they do.

We do know it has full access to the fTMP, RAM, and Network.

We also know that the NSA has a special contract to obtain Intel processors with the IME disabled... Why would they want that if the processors were trustworthy[1]?

[1] https://web.archive.org/web/20170830201623/https://hardocp.c...

I've lost faith that Linux distros will ever fix the problem where some PCR changes and the TPM refuses to unseal the key... the user is left with a recovery passphrase prompt & no way to verify whether they have been attacked by the 'evil maid', or whether it was just because of a kernel or kernel command line or initrd or initrd module change, etc.

What's wrong with the LUKS password protection?

There is nothing "wrong" with passwords, but they have trade-offs like most approaches. The actual LUKS key is usually wrapped in a password protected record(s) commonly on the storage media by default. That method is usually weaker than the key itself.

Note 10000 GPUs can brute force passwords rather quickly (a pre-sharded search space is fast), and key exfiltration for targeted individuals/firms still happens.

Options like modern TPM include anti-brute force features, but has other attack surfaces. Everyone has their own risk profile, and it is safer to assume if people want in... they will get in sooner or later. ymmv =3

For SATA SSDs i've used the hdparm secure erase and then verified that dd | hexdump is all zeros. That was good enough for me.

For Sata HDD shingled writes and SSD sector replacement it can't be cleaned that way.

Tools like dban stopped working once firmware sector re-mapping chips on modern storage became common. If you see the reported spare replacement count drop on your older s.m.a.r.t reports, than partial sectors may no longer be accessed from the OS without vendor specific forensic software. =3

https://sourceforge.net/projects/dban/

hdparm secure erase runs on the drive controller though, the "hdparm" utility just initiates it? So it's not depending on whether the OS can or cannot see specific sectors. At least that's my understanding.

Even with vendor specific forensic software it is unwise to trust the relocated sector mapping is handled cleanly. A cheap XGecu T76 Programmer can pull orphaned data fragments off most flash chips completely bypassing the drive controller.

In this case, the other posts suggesting a hammer is not sarcasm. =3

Depending on your threat model, your check is insufficient, since dd |hexdump will be all zeros even if you just trim all the blocks for a drive that is trim-to-zero.

Securely erasing flash drives with a threat model of "someone will dump the raw data of the chips" is only fully solvable for self-encrypting drives where you can replace the key. Even if you can issue a block-erase for every single block of the device, block erase doesn't always succeed on NAND.

100%. If you’re not encrypting your drive, along with a strong password, you’re fucking around.

Physical destruction as the only sure way? When your hardware is stolen, good luck physically destroying it.

Reply on news.ycombinator.com