Erased encrypted HDD, then secure erased 10% of it before selling it - is it safe?

Question

I have a 4TB mechanical hard drive that was encrypted before I ever wrote any file on it. I used a 25 character password with symbols.

Before I sold it, I unmounted the disk while it was still encrypted, then I formatted it to a new unencrypted volume. After I formatted it, it appeared on my Desktop as a new empty unencrypted disk. I used Disk Utility on Mac to write random data on it, but it was very slow, so I ended up writing on only 10% of the disk.

Has the data been securely erased beyond any doubt?

Answer 1

Has the data been securely erased beyond any doubt? No. Does it matter in practice? Probably not, at least for any sensible domestic/company threat model.

For the purposes of this answer I will presume that your disk was encrypted with a standard password unlock scheme and no TPM was involved. I will also presume a mechanical hard disk, as noted in your question, not an SSD. It is important to note that SSDs have special properties when it comes to FDE and data destruction which complicate the situation; there are other questions/answers on this site that discuss this in detail.

Typically, FDE volumes have a randomly generated volume key that is used for the bulk encryption of data on the disk. The volume key (and various other information) is placed into a volume header. Your disk unlock password is used to derive a volume unlock key, which is used to encrypt the volume header. This description is a bit of a simplification, but for the purposes of this question it is sufficient.

There are several reasons for using this volume header approach rather than just using your unlock key directly for bulk data encryption. The primary benefit is convenience: if you want to change your password, the only thing that needs to be re-encrypted is the volume header, rather than the entire disk. There are other benefits, too:

• It minimises the amount of data secured with the same key, since two disks that use the same password will utilise different bulk encryption keys.
• The bulk encryption key can be exported for recovery purposes, and if this key is compromised then it only compromises that one disk instead of all disks that use the same password.
• Implementing multi-user unlock schemes is simple. The volume header is duplicated for each user and encrypted with an unlock key derived from that user's password. Any one user can then unlock the disk.
• Alternative unlock schemes (e.g. TPM, hardware token / smart card, etc.) are easier to implement.
• Data destruction does not require that the whole disk be wiped, but only that the volume headers are destroyed, which saves time and disk wear. (The story is more complicated on SSDs but we're talking about HDDs here.)

That last point is a double-edged sword. If the FDE volume header is damaged or destroyed, e.g. due to disk corruption, all of your data is unrecoverable. If you lose the volume header, you lose the key that was used to encrypt the data on the disk, so the recovery problem becomes equivalent to cracking the randomly generated key. This is great if you're intentionally trying to destroy the data on the disk, but it sucks when it happens unintentionally.

To minimise the risk of unintentional damage to the volume header, FDE schemes typically make one or more backup copies of that header.

When you encrypt the drive you are usually prompted to save a recovery key or make some kind of recovery USB stick. The exact implementations vary, but these recovery processes either back up the plaintext bulk encryption key (and other necessary parameters like the IV) or the entire volume header block. This recovery material is usually designed to be able to decrypt the bulk data on the disk without needing an intact volume header or the unlock password.

However, this is usually not the only backup. Most FDE schemes store a primary and secondary volume header somewhere on the disk, with the secondary header being used as a built-in backup. Both headers are encrypted, so there's no security impact to making multiple copies. A common approach is to store one copy at the "start" of the disk (low logical block address) and another copy either at the "end" of the disk (high logical block address) or at some known offset. This ensures that the two copies are physically separate on the storage medium, so a bad sector or other corruption is unlikely to affect both copies. Corruption can be detected by comparing the two headers.

This volume header backup scheme has implications for data destruction. Exploring these implications is easiest if we think about the potential scenarios:

1. FDE was always in use on the drive (no risk of latent plaintext) but no data has been wiped.
2. A partial wipe was performed on the disk. The primary volume header was wiped, but not the secondary header (or vice versa). The bulk data was not wiped, or only a small part of it was.
3. A partial wipe was performed on the disk. Both primary and secondary volume headers were wiped. The bulk data was not wiped, or only a small part of it was.
4. A full wipe was performed on the disk.

The first scenario is no different to normal use of FDE. An attacker would need to guess or bruteforce your password, get access to your recovery key, or bruteforce the volume header key or bulk encryption key (which is computationally infeasible).

In the second scenario you've wiped one header but not the other. Since the disk contains a secondary header, it can be used to unlock the disk. Again, an attacker would need to guess or bruteforce your password, get access to your recovery key, or bruteforce the volume header key or bulk encryption key (computationally infeasible). If they do recover the bulk encryption key through one of these means, the difficulty of recovery depends on how much of the bulk data was wiped alongside the header.

In the third scenario you've wiped both headers. The disk no longer contains a copy of the bulk encryption key. An attacker no longer has the option to brute-force or otherwise crack your unlock password. They would need to get access to your recovery key, or bruteforce the bulk encryption key (again, computationally infeasible). If they do recover the bulk encryption key through one of these means, the difficulty of recovery depends on how much of the bulk data was wiped alongside the header.

In the fourth scenario you've wiped the whole disk. None of the data is left, so an attacker can't do anything. Ignore anyone who starts talking about multi-pass wiping and magical physical-layer recovery tricks like Magnetic Force Microscopy (MFM) - it's nonsense, and even if it did work nobody is going to bother (not even nation states). A full rant about wacky DoD disk erasure standards and their ongoing abuse by wiping software marketing teams is out of scope for this answer. Suffice to say that NIST SP 800-88 Rev.1 is the right place to look if you want a high quality media sanitisation standard.

Now the question arises: which of these situations applies to you? It depends, but the answer is almost certainly 2 or 3. If the FDE implementation you used puts the secondary volume header at a fixed offset, it's possible that you wiped both of them, which would put you in scenario 3. If the secondary volume header is at the "end" of the disk, then it may not have been wiped, which would put you in scenario 2. This is assuming that the disk wipe utility starts at the beginning of the disk (LBA 0) and writes sequentially from there - if it doesn't, all bets are off.

You can reasonably gather whether you're in scenario 2 or 3 by attempting to mount the disk. If you can get it to mount without needing a recovery key, you didn't get both of the headers. If you can't, you're probably in scenario 3. There may be edge cases where the backup volume header is present but the software still fails to mount/recover for some reason, so it's not a 100% guarantee, but it's a good indication. It's also important to note that you probably damaged the filesystem, so the FDE might unlock successfully but the underlying filesystem might not actually mount; this is an important distinction because unlocking is the bit we actually care about for security.

Given all this, the worst case scenario is that your data isn't unrecoverable but is still protected by FDE. Almost every single attacker (bored teenager, cybercriminals, law enforcement) will be defeated by this already, with an exception for the case where someone compels you to reveal your unlock password (highly unlikely).

The best case scenario is that you wiped the volume headers and the data is infeasible to recover even with all the computational resources in the world, unless someone gets at your recovery keys (if you have them). Since FDE already provides protection against everything except being legally compelled to reveal your password (I'll assume that someone hitting you with a wrench is out of scope for your threat model because you're not a character on the TV show "24") it's mostly a symbolic improvement in security for the bulk of sensible threat models.

TL;DR - I wouldn't worry about it too much. FDE alone is already a concrete security control as long as your password is good. Any amount of disk wiping you do afterwards is a tradeoff between time/effort and a little extra defence in depth.

Answer 2

Yes, your HDD is safe if:

If the encryption is secure they will never be able to recover any files. 25 character passwords are too long because smaller passwords are just as safe.

else:

But if they manage to bypass the encryption, then they will get most of the files. Especially if that 10% of disk writes were sequential: the other 90% of the disk area is untouched.

They will even get the parts of the files that were just partially overwritten.

Software like photorec is capable of recovering partial files.

Advice:

For future reference, the way I do it is to delete all the files and then do:

cat /dev/zero > file 

This will fill the disk with zeros. Do it on every partition.

It's much faster than writing random stuff.

But here's an upgraded, "with added randomness", version by user in the comments.

cat /dev/urandom > /dev/sdx; cat /dev/zero > /dev/sdx;

Note: There used to be some safety guides produced by the U.S. Army where they recommend writing random data a bunch of times, especially on magnetic drives. But nowadays they just seem to degauss the sensitive drives. Read as you will.