Self-encrypting drives (SEDs) have this function built in:
1. Everything stored on the drive is always encrypted when at rest.
2. The drive has some sort of firmware, memory and microprocessor that stores a key and en/de-crypts data in transit to/from storage.
3. To 'erase' the drive, the SED simply erases the key.
Of course there are many potential flaws in implementation, but conceptually it's simple. And as with most drive encryption solutions, the fatal flaw is that the data is available if the computer is on or asleep, which means that for most users the security is disabled 99% of the time (but that problem doesn't apply to drive wiping).
AFAIK: Many common drives have SED functionality. Until the user "locks" the drive, the data is en/decrypted invisibly to the user and system. Locking the drive creates a passphrase and a pre-boot environment for authentication. Locking the drive requires an OS-level utility. Opal by TCG (the same people who provide the TPM spec) is the common standard.
Well your password could be brute-forced unless it's really long and random (about 20 chars). There might also be flaws in the encryption code. And changing it later won't work, because old sectors might still be recoverable, even if they are overwritten.
Usually with full-disk encryption, your supplied encryption passphrase is used to encrypt a single sector (or redundant set of sectors, spread across the disk) containing a much larger master key, which is in turn used to encrypt the rest of the sectors. When you change the disk password at the OS level, the master key remains the same (which is why you don't have to wait for the disk itself to re-encrypt); the single sector containing the key is just re-written to be encrypted with your new password.
Later, when you actually reformat the drive, you (or your OS) should spend some extra time writing over the sector(s) containing your encrypted FDE master key. But only those sector(s) need to be securely wiped. Even if someone can brute-force the password you used, they won't have that sector to use to turn it into a decryption key for the sectors; and they definitely won't be able to brute-force the FDE master key itself.
And, to make matters better, in systems with a TPM (most, these days), the TPM holds the FDE master key, and does the job of "shredding" it when it's no longer needed itself, as an async job kicked off by the OS along with the reformat. Also, in such systems, the FDE master key is never loaded into RAM, because the TPM itself does the sector-wise encryption/decryption as a DMA process.
You can overwrite a physical sector in modern drives, at least not in a standard way. That’s because they contain internal controllers that map physical to virtual sectors.
I take the point, and my passphrase is a phrase so perhaps subject to dictionary attack of a sophisticated nature. At the end of the day, this is all about the level of risk one expects. Mine is 'don't want some random petty thief finding my credit card number' rather than 'don't want some government agency reading my old emails'.
1. Everything stored on the drive is always encrypted when at rest.
2. The drive has some sort of firmware, memory and microprocessor that stores a key and en/de-crypts data in transit to/from storage.
3. To 'erase' the drive, the SED simply erases the key.
Of course there are many potential flaws in implementation, but conceptually it's simple. And as with most drive encryption solutions, the fatal flaw is that the data is available if the computer is on or asleep, which means that for most users the security is disabled 99% of the time (but that problem doesn't apply to drive wiping).
AFAIK: Many common drives have SED functionality. Until the user "locks" the drive, the data is en/decrypted invisibly to the user and system. Locking the drive creates a passphrase and a pre-boot environment for authentication. Locking the drive requires an OS-level utility. Opal by TCG (the same people who provide the TPM spec) is the common standard.