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
  • Related: [How can I securely wipe an SSD? duplicate] – wjandrea Feb 28 '17 at 04:01
  • Unfortunately this situation is a bit different because I have limited access to the disk due to a hardware issue. – jfa Feb 28 '17 at 15:48
  • Perhaps, then, you can explain what "My SSD has limited access due to hardware issues" means and how it affects any possible answers, otherwise it's impossible to help you. –  Mar 02 '17 at 11:55

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
  • So is the key only in the beginning or is it at the end as well? – jfa Feb 28 '17 at 15:44
  • 1
    @JFA, it is just at the beginning. Luks header is usually 2 MiB long. But in any case if your password is strong, your data is unrecoverable even if you don't do anything to the header. – Andrius Štikonas Mar 01 '17 at 12:09
  • @AndriusŠtikonas it's ok, but it's not completely random bits, so I don't trust the strength against big computers. If you make this an answer I'll accept it. – jfa Mar 01 '17 at 19:38
  • @Rich I think that destroying the disk, as much as I'd like to, would lead to it not being replaced under warranty. – jfa Mar 01 '17 at 21:30
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
  • 880