2

I'm having an issue with my OCZ SSD where it "disappears" to the OS when stressed or, it seems, when it heats up. If I do too many read/write cycles, the drive seems to disappear. I was able to cool it off by putting my refrigerator and backed it up. Some large files seem to be missing portions; when rsyncing, it will pass half the file then the operation will stop. Some folders that are supposed to have files in them return nothing when opened.

I'm returning it to Toshiba under warranty, but I'm mildly concerned that some of my files may be available if the drive is repairable. This may include private files, family pictures, my password keychain, research, etc., and while I suspect the people at Toshiba will act professionally, due diligence tells me I should erase the drive.

I have overwritten the first portion of the disk in an attempt to test whether my drive or my computer was at fault. The drive was encrypted; it overwrote the key and at least part of the index, but I'm wondering if there's a key at the end.

I know that TruCrypt has a backup key at the end so that you can recover the drive; does Ubuntu do the same thing? The drive is encrypted, so I think that if I erase the keys, it won't be recoverable.

Also, I know that there are tools to flip bits in windows, is there a way to do this from Ubuntu?

jfa
  • 234

2 Answers2

3

If you overwrite the keys of an LVM encrypted volume the data is unrecoverable. However, see below.

There are several tools available to flip bits. Examples are 'wipe' 'sdelete' and 'eraser'. you can apt-get install wipe or apt-get install secure-delete (or nwipe, or nautilus-wipe ...)

The paranoid viewpoint (and also mine) is that these do not provide a reliable deletion on modern disks, and maybe especially on SSDs. The reason is that disks have controllers that may be able to cache "interesting" data in invisible locations. SSDs definitely rotate memory addresses for "wear leveling" purposes, and thus it is conceivable that "bit-flipped" data may have copies somewhere that is not addressable -- and thus doesn't get bit-flipped.

It is even possible that a disk's firmware may invisibly copy disk encryption keys. (What could me more "interesting" than these?)

You will need to decide how much risk is acceptable, with the most extreme option being physical destruction of the disk.

Respectfully, Rich

Rich
  • 776
1

LUKS header is located at the start of partition, by default it is 2 MiB but can be checked with sudo cryptsetup luksDump /dev/your_device. Payload offset (usually 4096) times 512 bytes is where encrypted data starts.

You can overwrite those first 2 MiB, with e.g.

dd if=/dev/urandom of=/dev/your_device bs=1M count=2.

There is a very small chance that SSD reallocated sectors of LUKS header somewhere else, but it is fairly unlikely as LUKS header is not modified often (only when you change passphrase).

If you want you can also try to use SSD internal erase mechanism: for details see: https://www.thomas-krenn.com/en/wiki/SSD_Secure_Erase Of course SSD firmware is proprietary, so there is no way to reliably now whether it really does secure erasing. But for all practical purposes you should be safe.

Andrius Štikonas
  • 910