Even if you didn’t have the public docs explaining this, you could make an educated guess because resetting the iOS device takes the same amount of time regardless of how much data you put on it and that time is on the order of 10s of seconds. iPhones don’t have erase speeds of 12gigabit/s - I don’t think there’s any storage technology that could do that. Also remember that Apple takes seriously the concern about the data leaking because the OS decided* to blacklist a bad block. Once a block has gone bad you probably shouldn’t rely on attempts to erase it working out.
* 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)
> you could make an educated guess because resetting the iOS device takes the same amount of time regardless of how much data you put on it
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.
> 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.
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.
* 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)