0

I was erasing a SSD with ATA secure erase and thought about the following:

When enhanced secure erase is performed on a SSD or NVMe which supports this operation, the master key which is used to encrypt all data is erased and newly generated, so that all written data can't be read anymore. So far so good. The process only took a few seconds.

After that I looked at the SSD with a hex editor and noticed - all data was erased, everthing was 0.

If only the master key was new generated, should't I see some sort of gibberish data? With the new key, all previous data shouldn't make sense now.

brot
  • 3
  • 2
  • Secure erase should just overwrite the data (as opposed to marking the sectors as available)... there shouldn't be any encryption involved. Though I think some "enhanced" methods try to hide the fact that it had ever been erased by putting dummy data in..(?) – pcalkins Mar 09 '22 at 18:16
  • 1
    I'm referring to this links: https://security.stackexchange.com/questions/62253/what-is-the-difference-between-ata-secure-erase-and-security-erase-how-can-i-en and https://security.stackexchange.com/questions/241268/ata-secure-erase-is-too-fast?rq=1 - both state that only the key will get erased and generated with secure erase on ssd – brot Mar 09 '22 at 18:36

1 Answers1

1

SSDs keep track of which blocks contain useful data, to minimize write amplification. (The OS helps by sending TRIM commands to the drive). After a secure erase this tracking will update to reflect that all blocks are unused.

Evidently your drive checks the usage metadata during a read command and sends back all-zeros if the requested sector is not listed as used, which saves it from having to fetch and decrypt the data for such unused sectors.

Ben Voigt
  • 760
  • 1
  • 10
  • 17
  • Thanks! That makes sense. I've read the write amplification article, which explains it very good how blocks are allocated and marked as used. – brot Mar 09 '22 at 19:45
  • @brot: Most likely the drive also checks the payload of write commands and recognizes all-zeros sectors. This saves it from having to write encrypt(zeros) somewhere, possibly having to erase somewhere first. Instead it can just mark that block as unused, which causes future reads to return zeros. This was a poor-man's way for a filesystem to indicate blocks that weren't used, before the TRIM command got standardized. – Ben Voigt Mar 09 '22 at 19:49
  • Neat and simple. So in my case, secure erase erased both, the mastee key and the metadata of used/unused blocks, right? – brot Mar 09 '22 at 19:59
  • @brot: Yes, secure erase should completely overwrite both the master key and the sector occupancy metadata (each block can actually be in one of three states: occupied, ripe, erased) and might actually do a mass-erase on the entire flash. Note that "erase" on flash memory generally means only that the flash is ready to be written to, not that forensic tools cannot distinguish the previous contents. "secure erase" guarantees, by losing the old key, that the contents can't be decrypted even if they can be forensically read. – Ben Voigt Mar 09 '22 at 20:19