4 ms·

I'm really surprised that they implement "destroy all data" by physically overwriting the flash cells. This is commonly (e.g. iPhone) done by storing all data e

I'm really surprised that they implement "destroy all data" by physically overwriting the flash cells. This is commonly (e.g. iPhone) done by storing all data encrypted with a randomly-chosen key and just throwing away the key to "delete" it, which is a much faster way to destroy a drive. And it's not like Flash drives can function without a somewhat complicated controller anyway... EDIT: clarified in response to DanBlake (and hackermom, who has just been hellbanned.)

hackermom 14y ago
So reading the data, applying crypto on the data, and then writing it back, is faster than just writing random data to the same cells to erase the data? How? Edit - Adding my response here for later reading when the ridiculous hellbanning that filtered me and another user from the discussion is lifted...: There's a problem with your theory here, in how you (and others responding to DanBlake's question) have misunderstood how a flash memory device works. How can the user or operating system, on software level, select a definite block of data for "zeroing out" when the storage medium is an SSD where wear-levelling is always present and ultimately what controls, on lowest possible level, what memory cell data is going to be written to? To my knowledge - and do correct me if I'm wrong - this is not doable on an SSD, and you thusly have to overwrite the entire SSD to be certain that the memory cell holding the key is erased. This is how flash memory controllers work - they always write data to the next free block, remap the old block and then marks it as unoccupied in the BAM. If the case is a mobile unit that may have a small portion of separate PRAM or similar where you can store crypto keys, the principle is the same there as that's also a flash type memory, even if a much smaller one that is faster to erase. However, that solution isn't usually available in a "normal computer", nor available to a "normal OS", which are the two targets of SSD drives.
DanBlake 14y ago
Can you explain why adding a encryption routine is faster than just blind overwriting the data with 0's? Genuinely curious as it seems that would not make sense, if you overwrote it with zeros in a comparable, logical manner.
- JonnieCache 14y ago
  If you encrypt the data, you only have to zero out the key (nanoseconds? maybe microseconds) instead of zeroing all the data. Assuming there is no backup of the key, the data is just as gone as if you'd zeroed it.
- DanBC 14y ago
  The drive is always encrypted. In an emergency you only have to destroy a little bit of the drive; the part that stores the key.
- JoachimSchipper 14y ago
  What JonnieCache and DanBC say: keep the data encrypted at all times, then you can just overwrite the few bytes of the encryption key to render the data unreadable. This has the additional advantage that you only need to really securely erase a very small amount of storage (plus the controller's memory.) (Editing my original post to make this more clear. Sorry.)
  - DanBlake 14y ago
    Oh, I thought you mean "as you push it" encryption. When I was in the military, Encrypting data was not acceptable for disposal though. They make you physically destroy it, which is why I imagine they do things in this manner.
    - JoachimSchipper 14y ago
      Yes, physically destroying drives prevents problems ("oh that wasn't encrypted?", "turns out it still had parts of unencrypted data on it from the previous server it was installed in", "what do you mean 'encrypted according to 1995 standards' (DES) is no longer secure?"). It's a good policy; but if you offer both "destroy" and "erase", "my" crypto implementation of "erase" has a lot to recommend it. (And there's no reason you can't follow it with a good zero-everything.)
  - deleted 14y ago
    [deleted]
ArchD 14y ago
Theoretically, information is information, encrypted or not, and just because the key is zeroed out doesn't mean part of the original information cannot be obtained from encrypted data. For example, an infinitely fast brute-force algorithm could crack it, as well as a lucky guess, however unlikely. If the key is weak relative to the strength of the cracking algorithm/hardware and the cost of leaking information, then this doesn't work.
hellbanmom 14y ago
Due to the ridiculous hellban that occured I'm posting my intended but disallowed response using this temporary user, because I feel that getting the explanation out about how solid state memory devices operate is important to the discussion and to clear misunderstandings that people may have regarding safe erasion of data on flash memory: There's a problem with your theory here, in how you (and others responding to DanBlake's question) have misunderstood how a flash memory device works. How can the user or operating system, on software level, select a definite block of data for "zeroing out" when the storage medium is an SSD where wear-levelling is always present and ultimately what controls, on lowest possible level, what memory cell data is going to be written to? To my knowledge - and do correct me if I'm wrong - this is not doable on an SSD, and you thusly have to overwrite the entire SSD to be certain that the memory cell holding the key is erased. This is how flash memory controllers work - they always write data to the next free block, remap the old block and then marks it as unoccupied in the BAM. If the case is a mobile unit that may have a small portion of separate PRAM or similar where you can store crypto keys, the principle is the same there as that's also a flash type memory, even if a much smaller one that is faster to erase. However, that solution isn't usually available in a "normal computer", nor available to a "normal OS", which are the two targets of SSD drives. / hackermom
- wmf 14y ago
  Those problems don't exist if the SSD itself performs the encryption/key management, as in SandForce.
- JoachimSchipper 14y ago
  Yes, SSDs set a portion of the disk aside for wear-leveling, so even writing zeroes to the entire disk from the OS does not guarantee that the data is completely destroyed. (Similarly, hard disks may hold secret data in bad sectors.) However, this device has these capabilities baked into it at the firmware level, and the firmware can address individual cells. (Similarly, the controller can include a small amount of non-volatile securely-erasable memory for the key.)

hackermom 14y ago

So reading the data, applying crypto on the data, and then writing it back, is faster than just writing random data to the same cells to erase the data? How? Edit - Adding my response here for later reading when the ridiculous hellbanning that filtered me and another user from the discussion is lifted...: There's a problem with your theory here, in how you (and others responding to DanBlake's question) have misunderstood how a flash memory device works. How can the user or operating system, on software level, select a definite block of data for "zeroing out" when the storage medium is an SSD where wear-levelling is always present and ultimately what controls, on lowest possible level, what memory cell data is going to be written to? To my knowledge - and do correct me if I'm wrong - this is not doable on an SSD, and you thusly have to overwrite the entire SSD to be certain that the memory cell holding the key is erased. This is how flash memory controllers work - they always write data to the next free block, remap the old block and then marks it as unoccupied in the BAM. If the case is a mobile unit that may have a small portion of separate PRAM or similar where you can store crypto keys, the principle is the same there as that's also a flash type memory, even if a much smaller one that is faster to erase. However, that solution isn't usually available in a "normal computer", nor available to a "normal OS", which are the two targets of SSD drives.

DanBlake 14y ago

Can you explain why adding a encryption routine is faster than just blind overwriting the data with 0's? Genuinely curious as it seems that would not make sense, if you overwrote it with zeros in a comparable, logical manner.

JonnieCache 14y ago
If you encrypt the data, you only have to zero out the key (nanoseconds? maybe microseconds) instead of zeroing all the data. Assuming there is no backup of the key, the data is just as gone as if you'd zeroed it.
DanBC 14y ago
The drive is always encrypted. In an emergency you only have to destroy a little bit of the drive; the part that stores the key.
JoachimSchipper 14y ago
What JonnieCache and DanBC say: keep the data encrypted at all times, then you can just overwrite the few bytes of the encryption key to render the data unreadable. This has the additional advantage that you only need to really securely erase a very small amount of storage (plus the controller's memory.) (Editing my original post to make this more clear. Sorry.)
- DanBlake 14y ago
  Oh, I thought you mean "as you push it" encryption. When I was in the military, Encrypting data was not acceptable for disposal though. They make you physically destroy it, which is why I imagine they do things in this manner.
  - JoachimSchipper 14y ago
    Yes, physically destroying drives prevents problems ("oh that wasn't encrypted?", "turns out it still had parts of unencrypted data on it from the previous server it was installed in", "what do you mean 'encrypted according to 1995 standards' (DES) is no longer secure?"). It's a good policy; but if you offer both "destroy" and "erase", "my" crypto implementation of "erase" has a lot to recommend it. (And there's no reason you can't follow it with a good zero-everything.)
- deleted 14y ago
  [deleted]

ArchD 14y ago

Theoretically, information is information, encrypted or not, and just because the key is zeroed out doesn't mean part of the original information cannot be obtained from encrypted data. For example, an infinitely fast brute-force algorithm could crack it, as well as a lucky guess, however unlikely. If the key is weak relative to the strength of the cracking algorithm/hardware and the cost of leaking information, then this doesn't work.

hellbanmom 14y ago

Due to the ridiculous hellban that occured I'm posting my intended but disallowed response using this temporary user, because I feel that getting the explanation out about how solid state memory devices operate is important to the discussion and to clear misunderstandings that people may have regarding safe erasion of data on flash memory: There's a problem with your theory here, in how you (and others responding to DanBlake's question) have misunderstood how a flash memory device works. How can the user or operating system, on software level, select a definite block of data for "zeroing out" when the storage medium is an SSD where wear-levelling is always present and ultimately what controls, on lowest possible level, what memory cell data is going to be written to? To my knowledge - and do correct me if I'm wrong - this is not doable on an SSD, and you thusly have to overwrite the entire SSD to be certain that the memory cell holding the key is erased. This is how flash memory controllers work - they always write data to the next free block, remap the old block and then marks it as unoccupied in the BAM. If the case is a mobile unit that may have a small portion of separate PRAM or similar where you can store crypto keys, the principle is the same there as that's also a flash type memory, even if a much smaller one that is faster to erase. However, that solution isn't usually available in a "normal computer", nor available to a "normal OS", which are the two targets of SSD drives. / hackermom

wmf 14y ago
Those problems don't exist if the SSD itself performs the encryption/key management, as in SandForce.
JoachimSchipper 14y ago
Yes, SSDs set a portion of the disk aside for wear-leveling, so even writing zeroes to the entire disk from the OS does not guarantee that the data is completely destroyed. (Similarly, hard disks may hold secret data in bad sectors.) However, this device has these capabilities baked into it at the firmware level, and the firmware can address individual cells. (Similarly, the controller can include a small amount of non-volatile securely-erasable memory for the key.)