Live data from Hacker News

How secure is merely discarding (TRIMing) all of a SSD's blocks?

utcc.utoronto.ca

111–117 of 117 posts

Re: How secure is merely discarding (TRIMing) all of a SSD's blocks?

#111

Unrelated to trim, but for some reason when I used secure erase on an SSD with a ZFS pool, the pool was still able to be found by ZFS. That shouldn't be the case, right?

Secure erase depends upon the drive firmware correctly implementing the function. The only study I've seen that actually tested this found about half of drives did not do it properly! But that was from 10 years ago now.

I once used secure erase on a nvme SSD and found some of the partition table was still present when going to reformat, even though the operation indicated success. I eventually tracked it down to the drive being mistakenly mounted at the time of the secure erase. So there is your other failure mode, making sure you and your software utilities also perform the secure erase correctly.

Re: How secure is merely discarding (TRIMing) all of a SSD's blocks?

#112

Earlier quoted context omitted.

Not got links to details, but you can think about wear levelling at two levels. The first and most obvious, is wear levelling between blocks of flash memory. Here the SSD controller tracks how often it erases blocks of memory which are probably tens to hundreds of bytes large, and tries to keep those counts nice and even. You’re probably already aware of that type of wear levelling. But wear levelling across multiple…

I'm not sure I follow. Am I correct in understanding that you're saying that if a block has some pattern, then overwriting that block with the same pattern will result in no extra wear on that block but neighboring blocks might overwrite and therefore would have worse wear. Thus encryption smears it out and ensures that you have consistently worst case wear always and that somehow improves reliability? I'm assuming t…

> Am I correct in understanding that you're saying that if a block has some pattern, then overwriting that block with the same pattern will result in no extra wear on that block

> I'm assuming the reason this works is because the underlying block that gets written isn't the same one that has the old data and thus the probability of overwriting with the same data is low because the encryption key for a given write is somehow derived from block offset

No, this has nothing to do with writing the same data to the same blocks, but rather how you handle a continuous stream of data being written (and eventually overwriting older data) to the drive over very long periods of time. You should assume that physical location of your data bears zero correlation to the address to write it to. The SSD controller will always redirect it to least worn available block.

In SSD it’s reasonable to assume that the flash memory can be erased and written at a more granular level than you would want to track for wear levelling purposes (because extra granularity cost more money). So writing repeated patterns of data to a disk that align with the wear levelling block size will result in some parts of your flash memory being written and erased more often. But this unevenness is too granular for the wear levelling algorithm to track and compensate for. Encryption removes the need to track more granular wear patterns because it ensures that every single bit of your flash memory is going to see very similar write patterns.

Additionally there’s an entirely separate aspect, which is that NAND flash is a physical storage medium, and economics mean manufacturers want to squeeze every last ounce of storage out of their silicon. This means pack flash cells physically close to each other, and storing multiple values in each cell. The consequence is that activity in one cell can cause changes in adjacent cells, if those changes are large enough value of a cell will change corrupting the stored data.

By encrypting the data you can eliminate the possibility of extreme edge cases occurring which have a high risk of data corruption. At better place to observe these types of issues is to look at RAM, and Row Hammer attacks. The basic principles are the same, even if the precise physical interactions are a little different.

Re: How secure is merely discarding (TRIMing) all of a SSD's blocks?

#113

Earlier quoted context omitted.

Didn’t know that. Don’t suppose you’ve got any links that describe the physical process that results in the correlation between write quality and erase-to-program delay?

How hard would it be to write custom firmware for an M.2 SSD? I'm not even sure where to start

A good one? Extremely hard. Pretty sure 90% of and SSD firmware is just secret sauce magic to deal with the mess and noise the physical world creates when you try to cram so much entropy into such a tiny physical space.

Re: How secure is merely discarding (TRIMing) all of a SSD's blocks?

#114
post #99

Earlier quoted context omitted.

Throwing away the keys is surprisingly hard to do. Say you have one root key and you derive per-file or per-block keys using various metadata (inode numbers, generation numbers, block addresses, whatever). You can't throw away derived keys though! Or say you generate random keys per-file and you store those somewhere (it's annoying to have to store them). Now to throw those keys away you need to re-write the blocks c…

> You can't throw away derived keys though! You can, AES-XTS does just this. Per-block keys can be derived on the fly from the root key and the block address. When the root key is gone, everything is gone.

Right, but clearly I meant that you can't arrange to delete individual files and lose their derived keys. The reason is that the bits you need to derive the keys may still be somewhere on disk, and one could -having access to the root keys- find them and "undelete" and re-derive the keys and recover the file contents.

Having to wipe an entire filesystem to securely delete a file is not useful.

Re: How secure is merely discarding (TRIMing) all of a SSD's blocks?

#115

Earlier quoted context omitted.

But the "encryption" need not be cryptographic strength for this, so it might be reversible even without the key. Consider an old cypher with a small key for example.

Certainly true, but again, anyone that really cares about data destruction is never going to trust TRIM to destroy their data. At a minimum they’re going to use a mechanism that’s designed to destroy data (Secure Erase), and more likely they’re going to use multiple methods to destroy that data. If you’re in a situation where you’re thinking that TRIM might be good enough, then you clearly don’t care that much about…

like this? https://i.imgur.com/mW0d1IE.gif

Re: How secure is merely discarding (TRIMing) all of a SSD's blocks?

#116

Earlier quoted context omitted.

The problem with this is that erase-to-program delay is a major factor in bad write quality.....you really don't want to erase a block and wait a long time before programming it. Where "long" is subjective and there are a lot of details here but the general rule is that the longer you wait after an erase to write, the less accurate your write is (colloquially, your zero decays as it sits)......so in practice while yo…

Didn’t know that. Don’t suppose you’ve got any links that describe the physical process that results in the correlation between write quality and erase-to-program delay?

Do you want research or do you want an analogy? I can give you both. On the research front:

    "An Experimental Analysis of Erase-to-Program Interference in Multi-Level Cell NAND Flash Memories" by F. X. Zhang, et al., in IEEE Transactions on Electron Devices, vol. 63, no. 4, pp. 1621-1628, April 2016.

    "Erase-to-Program Disturbance in NAND Flash Memory: Characterization, Modeling, and Mitigation Techniques" by M. H. Kim, et al., in IEEE Transactions on Very Large Scale Integration (VLSI) Systems, vol. 25, no. 9, pp. 2381-2392, Sept. 2017.

    "A Study of Erase to Program Disturbance in 3D NAND Flash Memory" by T. Wang, et al., in IEEE Transactions on Electron Devices, vol. 64, no. 7, pp. 3153-3159, July 2017.

    "Characterization and Modeling of the Erase-to-Program Disturbance in Multi-Level Cell NAND Flash Memories" by R. Micheloni, et al., in IEEE Transactions on Electron Devices, vol. 56, no. 11, pp. 2384-2392, Nov. 2009.

Re: How secure is merely discarding (TRIMing) all of a SSD's blocks?

#117

Earlier quoted context omitted.

Didn’t know that. Don’t suppose you’ve got any links that describe the physical process that results in the correlation between write quality and erase-to-program delay?

Do you want research or do you want an analogy? I can give you both. On the research front: "An Experimental Analysis of Erase-to-Program Interference in Multi-Level Cell NAND Flash Memories" by F. X. Zhang, et al., in IEEE Transactions on Electron Devices, vol. 63, no. 4, pp. 1621-1628, April 2016. "Erase-to-Program Disturbance in NAND Flash Memory: Characterization, Modeling, and Mitigation Techniques" by M. H. Kim…

Don’t suppose you could still provide the analogy. It’ll probably make it easier for me to understand the research as I only have a basic understanding of the physics at play here.
Post reply on HN