A 'wipe' then definitively erases that key - making further overwrites of the freed data unnecessary.
If the crypto is strong, and the key never exfiltrated, then this may be even better than an explicit overwrite, which on some media (like magnetic drives) may still leave trace hints of the old data that advanced techniques could recover.
The idea that magnetic drives left readable traces behind after an overwrite is a myth (especially of modern drives; if I recall the article I'm thinking of correctly the myth may have had a _slim_ chance of being true with old drives [like 100MB days]).
1 overwritten by 0: 10% field strength
0 overwritten by 0: 0% field strength
1 overwritten by 1: 100% field strength
0 overwritten by 1: 90% field strength
But I guess that's not quite true.
ATA Secure Erase is an optional security feature implemented by many flash-based disk devices specifically because write degradation and overprovisioning preclude them from being wiped via overwrite as you would magnetic media.
More SSD disk controllers than you may realize have an AES encryption engine and persistent storage for the key. The controller is encrypting/decrypting on the fly transparent to the user/system. A secure erase simply rolls that key (and flags all the cells as empty).
As noted in the sibling comment, there must be trust in the device itself that the old key is unrecoverable (or the data recoverable if the prior key had been compromised).
hdparm on any linux liveusb (e.g. Clonezilla) and an eSATA dock and you can nuke a few disks a minute with two commands:
hdparm --user-master u --security-set-pass p /dev/sdX
hdparm --user-master u --security-erase-enhanced p /dev/sdX
The other standard is TCG's OPAL. An AES media encryption key (MEK) is generated to encrypt/decrypt all data on the fly. The MEK is encrypted with a user-defined key encrypting key (KEK) and that encrypted MEK is stored on the drive. At boot the user (or some external process) needs to supply the drive with the KEK to decrypt the MEK and begin transparently decrypting/encrypting data on the fly. Splitting the disk into multiple "locking ranges" with independent MEKs and KEKs is also described in the spec enabling secure wipe of just a portion of the disk. Lose the KEK or destroy the MEK and the data is unrecoverable.
I'd say this option still requires trust in the disk itself but since TCG dictates not just the interface but also the implementation and has a corresponding certification process (as well as reliance on an off-device key), I reckon TCG OPAL devices should be more trusted than those that simply claim to implement the ATA Secure Erase command, but I haven't had an opportunity to test any.
It's interesting that even the drives themselves use this strategy to "erase" data; it doesn't actually overwrite the cells, it just always encrypts all data that goes to cells and rotates the key when it's asked to erase. This strategy is clearly superior, it doesn't cost any wear on the cells to perform, and it's instant.
The multiple locking ranges is pretty neat, I'd never heard of that.
* If any part of a block is found to be corrupted for any reason, the block is transparently set aside and never used again, but its contents may still be present to read for someone that is willing to bypass the drive's firmware.
* To prevent uneven wear, ssd capacity is over provisioned which means it has more cells than what it tells the OS. In general, when you "overwrite" a block on your drive, that data likely does not actually overwrite the cell where the data used to be. The drive picks some other unused cell, writes the data there, and does some bookkeeping so it knows that this new cell is what the OS means when it asks for that block again. When the OS "fills the disk" it may not end up overwriting some of those cells due to the firmware's arbitrary wear leveling algorithm.
* Many drives have a local write buffer that uses different, faster persistent storage to temporarily save writes to the drive as it takes its time to write out cells. This is to prevent data loss in the case of a power outage. In case the drive hadn't fully written all the blocks to the main storage when it boots back up again, it finds the data in the write buffer and finishes the job. The write buffer has both of the previous issues except its even more arbitrary and depends on load profile which your random filling routine is not guaranteed to hit.
There is no such thing as securely overwriting blocks anymore, because "blocks" are a fiction presented to your OS by the drive's firmware. There is only one way to be sure the data on the drive is filled with random data: make it random to begin with, and ensure that it stays random by destroying the decryption key.
How useful is one block of recovered data?
Edit: HDDs typically have 4K blocks though ("advanced-format drives"), but we're not talking about HDDs.
But yeah, it depends on the manufacturer of the drive, so you don't want to take the chance, Full encryption is unbeatable.
Extra cells are used both reactively and proactively.
Reactively: Error when erasing or write/verifying a cell? Copy contents to spare cell, flag old cell as bad, update the map, maybe complain if running low on spare cells but otherwise call it a day.
Proactively: Cells are only rated for so many erase operations which directly informs the longevity (total bytes written) of a drive. MLC cells can be written to 3,000 times and SLC 20,000 but the latter is much more expensive. For use cases where greater longevity is required (without spending SLC money), why not put a disk together that has twice as many cells as it needs and wear level across all of them? If you `dd if=/dev/zero of=/dev/sdX bs=64k status=progress` your 32GB drive and it'll complete after 32GB but you have no way of knowing how many more cells that drive has that you didn't touch.
(Also as one of the parents pointed out, disk controllers are getting smart. You don't know if it was transparently compressing data too causing you to touch even fewer cells. ATA Secure Erase is the way to go.)
Or if I’m feeling spicy, do all this then hit it with a hammer until it’s shattered in a million pieces like my dreams of working in tech.
The only better is less wear on the disk
2) Nonetheless, there is an appreciable risk of data remaining on the device due to non-volatile caches, remapped disk areas, and other factors that are not always well understood or disclosed by the manufacturer. Manufacturers have also been found to be unreliable in their implementation of ATA security features (e.g. embedded secure erase). As a result, with few exceptions it is U. S. government policy to permanently destroy all storage devices rather than trusting any kind of secure erasure. The typical NSA-approved method is either to degauss (surprisingly tricky to do right) and then crush, or reduce to 2mm particles with a device resembling a large, terrifying blender.
And as a result, (probably) Iron Mountain makes bucketloads because we don't just encrypt the drives (let's face it, that would be perfectly acceptable for 99% of US government computers - maybe Top Secret stuff deserves proper destruction).
If that were true, we'd have infinite storage capacity.
Of course deleting data on an SSD is tricky due to wear-leveling, anything short of telling the drive to erase the entire disk with the secure erase command isn't guaranteed to work.
1: https://support.microsoft.com/en-us/windows/how-to-refresh-r...
The problem here is that the Echo is closed so those options aren’t available to you. However, this is also a problem on other custom devices like printers.
Your iPhone 11 zeroizes the cryptographic key used for the user data partition. It doesn't have to wipe it per se, but rather it renders it eternally inaccessible; then it creates a new key and sets up a new filesystem right over top of the old one (which now just has random data in the unallocated space).
> The “Erase all content and settings” option in Settings obliterates all the keys in Effaceable Storage, rendering all user data on the device cryptographically inaccessible.
Semantics debate around whether leaving data practically inaccessible is the same as removing it, but considering where we are, I'd say it isn't.
Granted, this is from 2018, but I doubt the defaults and concept have changed.
Personally, that's not a risk that I would care about (especially in the context of an Echo Dot or even an iPhone), but deleting the keys will not be better than inaccessible forever.
* if I recall correctly iOS devices don’t use a traditional flash controller and Apple does that mapping themselves (it’s also largely why Apple devices have better flash performance than competitors)
This is incorrect. Secure deletion should cover the entire disk no matter how much data was used before, in order to deny an attacker any information or to guide their recovery efforts. I would absolutely expect a secure deletion process to take the exact same amount of time regardless of how much data is used.
A better tell is the difference between the same model of phone with different storage sizes. A 512GB iPhone should take 2x as long to securely wipe compared to a 256GB one, assuming they’re actually overwriting the encrypted data with random noise.
> iPhones don’t have erase speeds of 12gigabit/s
It’s worth pointing out that a true secure delete is actually a write not a delete. But it’s true that your typical iPhone could not possibly overwrite its entire disk in 10s or so, although last time I did a reset it took much longer than that.
That's a fair point. Still, mobile devices typically employ FDE to avoid the need for scribbling over the entire flash (also improves the lifetime of the flash in that way).
> It’s worth pointing out that a true secure delete is actually a write not a delete
Flash storage doesn't work that way unless you're referring to something else. To write a block you have to erase it first (makes the block all 1s or all 0s depending on the chip). An update of a block is technically then a read/erase/modify/write (although flash translation layers will elide the first 3 steps by writing to a free block & marking the old one as GC'able). Writing random patterns into flash to my knowledge generally isn't needed anyway as it was with magnetic storage. The only purpose of writing in a secure erase scenario is to try to overwhelm the flash translation layer to force every block to be touched.
> although last time I did a reset it took much longer than that.
I haven't profiled it, but any slowness erasing an iOS device is probably because the flash storage backing the secure element is optimized for reads rather than writes. Additionally, it may be erasing various metadata/caches in the OS storage that aren't covered by the encryption key.
There is the further belief that state sponsored actors would be able to read them, but this relies that state sponsored actors 1) have hardware capable and 2) would only go to those lengths to get the data.
I recently learned that the "zero out data" options are not available in Disk Utility for SSDs. This probably fine if you were using full disk encryption, especially on modern T2-chip Macs that always encrypt the built-in storage even if you haven't enabled FileVault, but it was a little concerning when I was getting rid of an old failing Mac that had an aftermarket SSD installed without encryption enabled.
On the other hand, it's a nightmare for data recovery, especially the "I didn't ever mean to encrypt this drive, what do you mean you can't recover it?" situation.
There's some discussion of the older version of that scheme (not encryption-based) here: https://joshuawise.com/projects/ndfrecovery
The non-clickbait is that the previous token is still valid as far as Amazon is concerned. They absolutely should have a process for invalidating tokens.
It’s not impossible to have a flash memory without a user data eeprom that you could “burn out” (in reality make less reliable).
I have no idea if it’s true in this case, but the straight comparison / jump to iPhone 11 might also be speculative.
If those work the same way, then no, they don't.
If lots of other devices have the same problem, that doesn't make it better!
>Accessing flash memory that has been factory reset in this way does require some amount of technical skill and specialized equipment, but nothing that is a real barrier to the average enthusiast working at home.
By that logic my iPhone 11, my Android phone, my Mac or my Windows PC doesn't wipe personal content either after factory reset
Feels like a bit clickbait-ish
But at least Macs have a built-in 7-pass erase option to comply with DOD standards https://techpatio.com/wp-content/uploads/2012/09/disk-utilit...