10 ms·

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

114 points by goranmoomin 4y ago

jsiepkes 4y ago
> Flash storage, unlike traditional hard drives, can really be completely and irrecoverably erased, with no lingering magnetic ghosts that a sufficiently determined person could in theory reconstruct. I think people vastly overestimate the possibility to recover any data from a wiped HDD. See for example this article by SANS [1]. To recover a single bit you have a better chance of flipping a coin to see if the bit was a zero or a one then you have when you are actually trying to reconstruct it with lab equipment. [1] https://web.archive.org/web/20140621130410/https://digital-forensics.sans.org/blog/2009/01/15/overwriting-hard-drive-data/ https://web.archive.org/web/20140621130410/https://digital-f...
- germanier 4y ago
  This can't be true. Any method must be at least as good as a coin toss. If it's worse you can just bit flip the result and end up better than the coin.
  - detrites 4y ago
    Unbelievably, the paper actually makes that claim: > That is, if you toss a coin, you have a 50% chance of correctly choosing the value. In many instances, using a MFM to determine the prior value written to the hard drive was less successful than a simple coin toss. More believably, the paper was written by Dr Craig Wright.
    - kryps 4y ago
      The paper does not make that claim. According to the paper the probability of recovering the correct value of a single bit is 96% for a pristine drive and 56% for a used drive, both better than a coin toss. Of course the probability gets worse if one tries to recover more bits (but still better than n coin tosses for n bits).
    - marginalia_nu 4y ago
      Right, if you flip a hundred coins, about half of them land heads and the other half tails. The correct coins we'll call oracles, and the incorrect ones liars. Now you perform a hdd recovery that is successful 70% of the time. That is still worse than the performance of the oracle coins which were correct, and if you invert the performance of the liars, they also beat the performance of the recovery. If you have two coins, one which is always correct and one which is always incorrect, you can flip one of them to decide whether the other one is correct (and pick the opposite). Check mate, statisticians!
  - mecsred 4y ago
    I don't think that follows? Just because a better method exists (the inverse) doesn't make the original perform better. Imagine the following method: take whatever the bit was, and set it to the opposite of that. 0% < 50%. Of course you can invert and get 100%, but that's a different method. It doesn't make the original any better.
  - DSMan195276 4y ago
    The article isn't super clear, but I think what it's saying is that the data recovery method they were testing (when looking at recovering a single bit) was as good as 92%, and as bad as 32%, depending on how the data was overwritten and other factors like the specific drive. Thus you likely can't just flip the result to get better odds because in a real scenario you wouldn't know which category you fall into (whether it's really good, or really bad), and overall if you don't know that information then the odds are close to 50%. Edit: And of course even a high of 92% is abysmal for a single bit, since the combined odds of multiple bits quickly goes to zero for any sizable amount of data.
  - kmeisthax 4y ago
    Bits are correlated: we care about the order of the bits, not just their population count. Furthermore, <50% is only an antipredictor for a single coin flip. If you have two bits - two coin flips where you care about the order - then there's four values, and you have to be <25% to be an antipredictor. Even then, an antipredictor only removes one possibility[0], so flipping the bits will only slightly improve your terrible chances of recovering the data. [0] https://en.wikipedia.org/wiki/Monty_Hall_problem https://en.wikipedia.org/wiki/Monty_Hall_problem
- fdeee 4y ago
  I think you are right in that it is quite impossible to read data that has been overwritten from a sufficiently modern HDD. But all modern HDDs retire sectors that exhibit a higher correctable error rate and replace them by reserve sectors. Those retired sectors then still contain readable data (maybe with some bit errors) if you know the appropriate factory mode commands. Overwriting the entire disk also won't overwrite retired sectors, except if the disk has an explicit function for it and you trust that function to work properly. In short, you always need full disk encryption.
  - Dalewyn 4y ago
    Or a low level format.
- deleted 4y ago
  [deleted]
- throw0101a 4y ago
  > See for example this article by SANS [1]. According to NIST 800-88 Rev. 1 a single overwrite is fine: * https://en.wikipedia.org/wiki/Data_remanence#Feasibility_of_recovering_overwritten_data https://en.wikipedia.org/wiki/Data_remanence#Feasibility_of_...
- bcoates 4y ago
  Also it's not obvious that it works the other way. The only requirement of the flash reset operation is that it consistently causes bits to read as 1 and that the normal write operation allows them to read as 0 again; it doesn't actually follow from that that an erased-but-not-reprogrammed block will have cell charge levels that are indistinguishable from each other based on the pre-erasure charge level.
- Thaxll 4y ago
  All those articles are very theoretical, in reality 1 pass of dd /dev/zero makes things unrecoverable, for recent SSD since trim is enabled by default you can't recover anything, I deleted a document by mistake on an SSD and it was impossible to get back, the moment I pressed delete on windows the trim command was sent and everything was erased on the ssd. Pro recovery compagny that are not shady know that SSD recovery with TRIM is impossible.
  - luma 4y ago
    So ... you didn't read the article then?
    - Thaxll 4y ago
      The article is light on details and assume a lot of things. he doesn't prove anything, show us that after succesful trim you're able to recover anything. From my experience it's impossible.
h506001 4y ago
Super interested in this and would love to hear about some techniques. Used to work at a HealthTech co. We had an “appliance” that we’d send to doctor offices to integrate with other diagnostic machines on the network. Sometimes we would send out new ones to replace the old. When we got the old ones back, it was always unclear how to purge and recommission SSD/NVME drives. My best attempt was using GNU shred, but it wasn’t recommended for flash-based storage back then.
- fdeee 4y ago
  The only proper way of disposal is physical destruction, preferrably on site and under observation of inhouse staff. There are contractors you can hire in those: https://shredsupply.com/hard-drive-shredding-trucks/ https://shredsupply.com/hard-drive-shredding-trucks/ (no relation, just arbitrary google hit). I'm also unsure as to why you are getting drives back at all, any of your customers should not have any kinds of storage devices leave their site intact. At least that is the standard over here in Europe for healthcare and other industries dealing with sensitive data.
  - h506001 4y ago
    Oh, we did stuff like this for disposal. The tricky part is drives we desired to recommission.
  - bshipp 4y ago
    Shredding/sledgehammer is likely the best option for secure disposal of mechanical drives, but SSDs are a different animal and are likely reusable given some of the suggestions in this thread.
    - hedora 4y ago
      Most hard disks support hardware level encryption and full disk erase at this point. There’s very little need to sledgehammer anything given realistic attacker models.
      - 4y ago
aver4geredditor 4y ago
Also see: https://wiki.archlinux.org/title/Solid_state_drive/Memory_cell_clearing https://wiki.archlinux.org/title/Solid_state_drive/Memory_ce... https://www.usenix.org/events/fast11/tech/full_papers/Wei.pdf https://www.usenix.org/events/fast11/tech/full_papers/Wei.pd... Edit: see section 3.2.2 in the PDF (and the corresponding table 2): > In most cases, overwriting the entire disk twice was sufficient to sanitize the disk, regardless of the previous state of the drive. There were three exceptions: about 1% (1 GB) of the data remained on Drive A after twenty passes This is about normal overwriting, however. The fastest random overwriting program on Linux I know of is `shred`
generalizations 4y ago
Or you encrypt the entire drive. Then the secure erasure is a matter of throwing away the keys, and you don't have to bother with thinking through your threat model.
- wyager 4y ago
  Two issues with that - you have to make sure you dispose of the key(s), and this doesn't let you securely erase just part of the drive.
  - buildbot 4y ago
    3. Technically someone could uncover a flaw in whatever encryption you used.
    - rqtwteye 4y ago
      Once you have an attacker with that kind of technical skill, you are in a totally different world.
      - JosephRedfern 4y ago
        Not necessarily -- if the drive was found and decrypted after the exploit was leaked and made public (perhaps YEARS after it being a 0-day), it wouldn't necessarily be a skilled attack.
- deleted 4y ago
  [deleted]
- cryptonector 4y ago
  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 containing them. If there's any behind-the-scenes copy-on-write going on then re-writing a block doesn't necessarily lose its old contents. The only thing that's easy to throw away -maybe- is the top-level / root keys. But that means deleting the entire filesystem.
fdeee 4y ago
This is why you always want to use full disk encryption (FDE). Then it doesn't really matter whether some blocks are recoverable after TRIM. It also doesn't really matter whether the Secure Delete function works. It also doesn't matter whether the very expensive security-buzzword-compliant secure deletion snakeoil software really works. Also, TRIM is only possible with drives that are still in working order. Very often you can't TRIM or secure delete a drive that is defective and returned by RMA. In that case you either need a very expensive no-disk-return support contract. Or you just use FDE.
- tjoff 4y ago
  TRIM and FDE isn't perfect though as it leaks information about what parts have been written etc. And if you turn off TRIM you get a massive performance decrease.
  - vorticalbox 4y ago
    Why would someone turn off TRIM?
    - danuker 4y ago
      To mask the extent to which a drive has been filled, or to figure out how many blocks have been deleted since the last TRIM. I have yet to discover any use for this minuscule "leak", even when considering nation-state adversaries. It's much easier to find other channels to leak data through. The disadvantages are massive, such as significant slowdown when the drive gets filled. Yet the creators of dm-crypt are paranoid about enabling it by default: https://wiki.archlinux.org/title/Dm-crypt/Specialties#Discard/TRIM_support_for_solid_state_drives_(SSD) https://wiki.archlinux.org/title/Dm-crypt/Specialties#Discar... I couldn't understand ref 3: https://web.archive.org/web/20160709174950/http://www.saout.de/pipermail/dm-crypt/2011-September/002019.html https://web.archive.org/web/20160709174950/http://www.saout.... Ref 4: "you have an information leak where filesystem-discarded blocks (by TRIM) can be identified by an attacker with low effort" https://web.archive.org/web/20160709183108/http://www.saout.de/pipermail/dm-crypt/2012-April/002420.html https://web.archive.org/web/20160709183108/http://www.saout....
slicktux 4y ago
HDPARM secure-erase uses the OPAL standard which ensures unused bad blocks, that the drive normally ignores, are erased too. TRIMMING only cleared blocks normally accessible for reading/writing. It’s not as low level… But as someone has mentioned you can just enable encryption and forget the keys…most all SSDs are encrypting from new…user and master keys just have to be set.
LinuxBender 4y ago
As others have mentioned, use encryption. But that has gaps as someone can hold onto the drive and wait for impossible to break to become somewhat expensive to break to broke by mistake through bad encryption implementation. Put the encrypted drive into a hydraulic press and flatten it into a thin sheet, then run that sheet through a chop saw, or just use tin-snips if your hydraulic press was powerful enough. A hydraulic press and a chop saw are a few hundred bucks whereas drive shredders can range from $30k to $200k.
- ChoGGi 4y ago
  I think an angle grinder would be more accessible than a press.
  - fdeee 4y ago
    Open them, heat treat the disks in a bonfire, use the magnets as fridge magnets (those are quite strong, can fix entire books to the fridge instead of just notes).
    - chipsa 4y ago
      Last I checked, SSDs don't have those (see thread title).
- 13of40 4y ago
  Delete all the files then "dd" from the random device until the drive is full? Must we always jump straight to the hydraulic press?
  - bcoates 4y ago
    As mentioned in the article, that's not reliable. Drives have lots of overprovision blocks and there's no way of consistently forcing them to be used; and drives might mark blocks as too questionable/worn to reuse and never reset them. Also a standard failure mode of SSDs is refusing to accept writes, so you'll have to handle that case.
katdork 4y ago
The absurdity here that you can't do it because your BIOS won't let you, hdparm can do this! You can literally just boot a Live USB! https://wiki.archlinux.org/title/Solid_state_drive/Memory_cell_clearing https://wiki.archlinux.org/title/Solid_state_drive/Memory_ce... And anyone who thought TRIM would be a reliable way to get rid of data to begin with didn't have an understanding of TRIM!
mharsch 4y ago
The keyword / feature you're looking for is 'sanitization'. https://ieeexplore.ieee.org/document/10008943 https://ieeexplore.ieee.org/document/10008943
tracker1 4y ago
If security is your biggest concern, and not reuse... then using industrial shredding machinery is your best bet. If you want reuse... then a handful of fill/erase cycles with random data is probably your best bet, even then, there will still likely be some overprovisioned blocks with prior data. Encryption and throwing away the key doesn't do more than random data to fill said drive.
dark-star 4y ago
I'm surprised people actually think TRIMming is in any way a "secure delete" operation. It's basically the "quick format" of SSDs: "hey, all those blocks here, I don't care about them anymore, use them as if they were free..." Without OS-side encryption, Secure Erase is the only reliable option (SSD encrypts everything with an internal key which then gets deleted by the secure erase command, leaving only random data behind)
- marcosdumay 4y ago
  > It's basically the "quick format" of SSDs: "hey, all those blocks here, I don't care about them anymore, use them as if they were free..." Due to implementation details, SSDs can only use a block if it is clear. Thus trimming a block and waiting for long enough would be sufficient to erase the data if the driver actually enforced that the block will be reused. So, it's not good enough, but this is not obvious at all.
  - pkaye 4y ago
    But there is a logical to physical mapping table so that data might be spread across multiple physical blocks.
h2odragon 4y ago
https://en.wikipedia.org/wiki/Thermite https://en.wikipedia.org/wiki/Thermite Securely erases all known forms of electronic data storage. Cheap, reliable, fun for the whole family!
- wkat4242 4y ago
  That's it. You can't beat maximum entropy :D
- MarkusWandel 4y ago
  There was (is?) a type of hard disk where the platters are made out of glass. These are easy to dispose of securely... drop onto a concrete floor from about six feet up. Shake, feel finely pulverized glass rattling around inside. Done.
  - flangola7 4y ago
    How do you magnetize glass?
    - h2odragon 4y ago
      With a thin coating of "stuff" that peels off like metallic foil. Iron oxide spiced with rare earths I think it usually is. The pics in this article illustrate it: https://www.extremetech.com/computing/326292-why-lying-about-storage-products-is-bad-an-ibm-deskstar-story https://www.extremetech.com/computing/326292-why-lying-about...
Felminor 4y ago
Most relevant ssds are always encrypted. I don't think it's necessary to delete it. But if you want, write the disk fully
verall 4y ago
If your bios is not allowing secure ATA functionality ("frozen" in hdparm) try doing a pm-suspend and then waking back up. For me this unfroze the drive, although I have no idea why. I was then able to mess with ata security options, run secure erase, etc.
- calebio 4y ago
  IIRC it is often frozen by the BIOS on boot. I think the pm-suspend/wake 'reinits' (for lack of a better word) the drive and doesn't set the magic frozen bit. I'd love to know from someone who has the actual tech details vs. my half-remembering an explanation from a wiki.
avianlyric 4y ago
Somethings not mentioned in the article, but are pretty relevant. Modern SSD controllers encrypt all data by default. Not to increase security, to improve wear levelling. Encrypted data should be effectively random data (that’s what good encryption aims to produce). So encrypting the data ensures that patterns in data written to the SSD don’t end up creating uneven wear patterns in the flash chips. As a consequence, reading the raw data of an SDD would just produce garbage. You would need to also extract the encryption key from the SSD controller. Given this encryption isn’t meant to be secure, it’s quite possible to extracting that key is quite easy. But I believe that secure erase on SSDs is achieved by simply rotating the encryption key used for wear levelling, so maybe it’s reasonable well protected. I would expect an SSD to quite aggressively erase TRIMed blocks where possible. Erasing a block of flash memory is about 10x slower (2ms) than writing to flash memory (200microseconds), so there’s quite a large performance hit once a drive runs out of empty blocks and needs to start erasing blocks in the write path. Overall I suspect that simply TRIMing most SSD is secure enough for most applications. At least secure enough for anyone that even asks the question “is TRIMing secure enough”. For everyone else, you either don’t care at all, or your really care, in which case you’re using multiple layers of security such as full disk encryption, secure SSD erase, and shredding drives already.
- timbre1234 4y ago
  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 you do erase-ahead, you don't erase too far ahead of your writing and you certainly don't erase at TRIM time in most cases.
  - avianlyric 4y ago
    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?
wkat4242 4y ago
If you care about security then you'd have full disk encrypted the thing anyway. So really, it's not a problem.
adav 4y ago
Take the drive out and smash it to bits.
tripdout 4y ago
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?
- h506001 4y ago
  Not sure how secure erase works, but I’ve run into this a few times after “erasing”. I think it has something to do with boot records or partition tables. So there’s a piece of some drives (usually at the front) that contains this data. You can overwrite it properly with the appropriate tools. I always just used `dd` on the raw drive ref in Linux to blow it up.
- avianlyric 4y ago
  I think ZFS identifies drives by their serial number. So you can erase a drive in a pool, and ZFS on that machine will still recognise the drive based on its serial number, and know its pool membership. ZFS should then throw all kinds of errors once it notices that all the super locks and other FS metadata is missing. But a scrub should cause ZFS to simply fix that via normal resilvering.
  - anecdotal1 4y ago
    No, ZFS identifies by finding superblocks. This drive was not securely erased if any superblocks could still be found.
- ridgered4 4y ago
  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.
upofadown 4y ago
Why is this so hard? Why can't we just specify that a particular file needs to be actually deleteable and that we don't want the system (at any level) to leak copies of any of the data in that file? There is no technical reason this is not possible, it is just a convention that has caused problems since the dawn of computing. There is no point in making a file system that supports that filesystem would not be able to specify deleteabiliy to the hardware. There is no point in making hardware that supports this because there is no file system that exists that would have anything to tell the hardware. This situation exists simply because of inertia. Sure there would be performance implications, but who would care? You might just want to store a key for some full performance encrypted data that you would like to be able to actually remove access to. Sometimes performance is not the most important thing to optimize for.
- wtallis 4y ago
  > There is no technical reason this is not possible, it is just a convention that has caused problems since the dawn of computing. Technical reasons are all over the place, because the only "convention" you could possibly be referring to is the practice of having layers of abstraction for compatibility purposes. If you want to re-design your entire storage stack to accommodate every new technology, then it's trivial to ensure deleteability in each from-scratch re-design. But as soon as you want to use flash memory to build a drop-in replacement for hard drives, it gets quite difficult to retain this property without making huge sacrifices to more desirable properties.
  - upofadown 4y ago
    It would be possible to add this particular bit of information without changing anything that affects compatibility. The only difference would be that some files would actually be deleted when a delete operation was applied. It is a separate information channel that can be added on top. This has nothing in particular to do with flash vs spinning rust. A copy on write file system for example generates tons of information leaking copies all the time, but could trivially be be changed so that some files did not leak in that way. This is truly one of those issues that exists simply because no one can be bothered to fix it.
WirelessGigabit 4y ago
Edit: Below doesn't apply to T2 enabled Macs. If you erase the volume, regardless of whether you had FileVault enabled or not, the key is deleted [0]. If FileVault isn’t enabled on a Mac with the T2 chip during the initial Setup Assistant process, the volume is still encrypted, but the volume key is protected only by the hardware UID in the Secure Enclave. and When deleting a volume, its volume key is securely deleted by Secure Enclave [0] https://www.apple.com/mideast/mac/docs/Apple_T2_Security_Chip_Overview.pdf https://www.apple.com/mideast/mac/docs/Apple_T2_Security_Chi... ----------------------------------------------- Incorrect ramblings below: ----------------------------------------------- Apple recommends setting up FileVault on their SSDs. It is literally the only way to ensure that the data on the SSD is not recoverable. And you should do this before you put anything ON the Mac. If you add a file and only later encrypt the drive, you have no guarantee that that file still isn't somewhere readable one way or another. This is important when you think about buying a Mac and then choose to return it 3 days later. Apple states [0]: Note: With a solid-state drive (SSD), secure erase options are not available in Disk Utility. For more security, consider turning on FileVault encryption when you start using your SSD drive. On their dedicated encryption page [1] they do state that devices with T2 are encrypted by default: Note: If you have an iMac Pro or another Mac with an Apple T2 Security Chip, the data on your drive is already encrypted automatically. However, turning on FileVault provides further protection by requiring your login password to decrypt your data. However I can't find any reference to see how to reset that built-in key. [0] https://support.apple.com/guide/disk-utility/erase-and-reformat-a-storage-device-dskutl14079/mac https://support.apple.com/guide/disk-utility/erase-and-refor... [1] https://support.apple.com/guide/mac-help/encrypt-mac-data-with-filevault-mh11785/mac https://support.apple.com/guide/mac-help/encrypt-mac-data-wi...
TacticalCoder 4y ago
Full disk encryption that are decrypted using a U2F security keys are now here (latest LUKS/systemd allows to do that). And Yubikey don't leak secrets. If your system is compromised to the point that someone gets access to the full disk decryption key protected by your Yubikey, you've got bigger problem than securely erasing the disk. Need to recommission a disk? dd to the disk because why not. Some sectors didn't get dd'ed? Well, the bad guys need your Yubikey too. So, really, what do we think about Yubikeys? Are people now going to steal your Yubikey in addition to finding the sectors that weren't overwritten by dd?
- calebio 4y ago
  is the Yubikey protected by some kind of pin or password or something? and is there something that prevents someone from brute forcing that pin/password if they have access to the Yubikey? I've not used a Yubikey in this way before, sounds really neat.

114 points by goranmoomin 4y ago

> Flash storage, unlike traditional hard drives, can really be completely and irrecoverably erased, with no lingering magnetic ghosts that a sufficiently determined person could in theory reconstruct. I think people vastly overestimate the possibility to recover any data from a wiped HDD. See for example this article by SANS [1]. To recover a single bit you have a better chance of flipping a coin to see if the bit was a zero or a one then you have when you are actually trying to reconstruct it with lab equipment. [1] https://web.archive.org/web/20140621130410/https://digital-forensics.sans.org/blog/2009/01/15/overwriting-hard-drive-data/ https://web.archive.org/web/20140621130410/https://digital-f...

germanier 4y ago
This can't be true. Any method must be at least as good as a coin toss. If it's worse you can just bit flip the result and end up better than the coin.
- detrites 4y ago
  Unbelievably, the paper actually makes that claim: > That is, if you toss a coin, you have a 50% chance of correctly choosing the value. In many instances, using a MFM to determine the prior value written to the hard drive was less successful than a simple coin toss. More believably, the paper was written by Dr Craig Wright.
  - kryps 4y ago
    The paper does not make that claim. According to the paper the probability of recovering the correct value of a single bit is 96% for a pristine drive and 56% for a used drive, both better than a coin toss. Of course the probability gets worse if one tries to recover more bits (but still better than n coin tosses for n bits).
  - marginalia_nu 4y ago
    Right, if you flip a hundred coins, about half of them land heads and the other half tails. The correct coins we'll call oracles, and the incorrect ones liars. Now you perform a hdd recovery that is successful 70% of the time. That is still worse than the performance of the oracle coins which were correct, and if you invert the performance of the liars, they also beat the performance of the recovery. If you have two coins, one which is always correct and one which is always incorrect, you can flip one of them to decide whether the other one is correct (and pick the opposite). Check mate, statisticians!
- mecsred 4y ago
  I don't think that follows? Just because a better method exists (the inverse) doesn't make the original perform better. Imagine the following method: take whatever the bit was, and set it to the opposite of that. 0% < 50%. Of course you can invert and get 100%, but that's a different method. It doesn't make the original any better.
- DSMan195276 4y ago
  The article isn't super clear, but I think what it's saying is that the data recovery method they were testing (when looking at recovering a single bit) was as good as 92%, and as bad as 32%, depending on how the data was overwritten and other factors like the specific drive. Thus you likely can't just flip the result to get better odds because in a real scenario you wouldn't know which category you fall into (whether it's really good, or really bad), and overall if you don't know that information then the odds are close to 50%. Edit: And of course even a high of 92% is abysmal for a single bit, since the combined odds of multiple bits quickly goes to zero for any sizable amount of data.
- kmeisthax 4y ago
  Bits are correlated: we care about the order of the bits, not just their population count. Furthermore, <50% is only an antipredictor for a single coin flip. If you have two bits - two coin flips where you care about the order - then there's four values, and you have to be <25% to be an antipredictor. Even then, an antipredictor only removes one possibility[0], so flipping the bits will only slightly improve your terrible chances of recovering the data. [0] https://en.wikipedia.org/wiki/Monty_Hall_problem https://en.wikipedia.org/wiki/Monty_Hall_problem
fdeee 4y ago
I think you are right in that it is quite impossible to read data that has been overwritten from a sufficiently modern HDD. But all modern HDDs retire sectors that exhibit a higher correctable error rate and replace them by reserve sectors. Those retired sectors then still contain readable data (maybe with some bit errors) if you know the appropriate factory mode commands. Overwriting the entire disk also won't overwrite retired sectors, except if the disk has an explicit function for it and you trust that function to work properly. In short, you always need full disk encryption.
- Dalewyn 4y ago
  Or a low level format.
deleted 4y ago
[deleted]
throw0101a 4y ago
> See for example this article by SANS [1]. According to NIST 800-88 Rev. 1 a single overwrite is fine: * https://en.wikipedia.org/wiki/Data_remanence#Feasibility_of_recovering_overwritten_data https://en.wikipedia.org/wiki/Data_remanence#Feasibility_of_...
bcoates 4y ago
Also it's not obvious that it works the other way. The only requirement of the flash reset operation is that it consistently causes bits to read as 1 and that the normal write operation allows them to read as 0 again; it doesn't actually follow from that that an erased-but-not-reprogrammed block will have cell charge levels that are indistinguishable from each other based on the pre-erasure charge level.
Thaxll 4y ago
All those articles are very theoretical, in reality 1 pass of dd /dev/zero makes things unrecoverable, for recent SSD since trim is enabled by default you can't recover anything, I deleted a document by mistake on an SSD and it was impossible to get back, the moment I pressed delete on windows the trim command was sent and everything was erased on the ssd. Pro recovery compagny that are not shady know that SSD recovery with TRIM is impossible.
- luma 4y ago
  So ... you didn't read the article then?
  - Thaxll 4y ago
    The article is light on details and assume a lot of things. he doesn't prove anything, show us that after succesful trim you're able to recover anything. From my experience it's impossible.

h506001 4y ago

Super interested in this and would love to hear about some techniques. Used to work at a HealthTech co. We had an “appliance” that we’d send to doctor offices to integrate with other diagnostic machines on the network. Sometimes we would send out new ones to replace the old. When we got the old ones back, it was always unclear how to purge and recommission SSD/NVME drives. My best attempt was using GNU shred, but it wasn’t recommended for flash-based storage back then.

fdeee 4y ago
The only proper way of disposal is physical destruction, preferrably on site and under observation of inhouse staff. There are contractors you can hire in those: https://shredsupply.com/hard-drive-shredding-trucks/ https://shredsupply.com/hard-drive-shredding-trucks/ (no relation, just arbitrary google hit). I'm also unsure as to why you are getting drives back at all, any of your customers should not have any kinds of storage devices leave their site intact. At least that is the standard over here in Europe for healthcare and other industries dealing with sensitive data.
- h506001 4y ago
  Oh, we did stuff like this for disposal. The tricky part is drives we desired to recommission.
- bshipp 4y ago
  Shredding/sledgehammer is likely the best option for secure disposal of mechanical drives, but SSDs are a different animal and are likely reusable given some of the suggestions in this thread.
  - hedora 4y ago
    Most hard disks support hardware level encryption and full disk erase at this point. There’s very little need to sledgehammer anything given realistic attacker models.
    - 4y ago

aver4geredditor 4y ago

Also see: https://wiki.archlinux.org/title/Solid_state_drive/Memory_cell_clearing https://wiki.archlinux.org/title/Solid_state_drive/Memory_ce... https://www.usenix.org/events/fast11/tech/full_papers/Wei.pdf https://www.usenix.org/events/fast11/tech/full_papers/Wei.pd... Edit: see section 3.2.2 in the PDF (and the corresponding table 2): > In most cases, overwriting the entire disk twice was sufficient to sanitize the disk, regardless of the previous state of the drive. There were three exceptions: about 1% (1 GB) of the data remained on Drive A after twenty passes This is about normal overwriting, however. The fastest random overwriting program on Linux I know of is `shred`

generalizations 4y ago

Or you encrypt the entire drive. Then the secure erasure is a matter of throwing away the keys, and you don't have to bother with thinking through your threat model.

wyager 4y ago
Two issues with that - you have to make sure you dispose of the key(s), and this doesn't let you securely erase just part of the drive.
- buildbot 4y ago
  3. Technically someone could uncover a flaw in whatever encryption you used.
  - rqtwteye 4y ago
    Once you have an attacker with that kind of technical skill, you are in a totally different world.
    - JosephRedfern 4y ago
      Not necessarily -- if the drive was found and decrypted after the exploit was leaked and made public (perhaps YEARS after it being a 0-day), it wouldn't necessarily be a skilled attack.
deleted 4y ago
[deleted]
cryptonector 4y ago
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 containing them. If there's any behind-the-scenes copy-on-write going on then re-writing a block doesn't necessarily lose its old contents. The only thing that's easy to throw away -maybe- is the top-level / root keys. But that means deleting the entire filesystem.

fdeee 4y ago

This is why you always want to use full disk encryption (FDE). Then it doesn't really matter whether some blocks are recoverable after TRIM. It also doesn't really matter whether the Secure Delete function works. It also doesn't matter whether the very expensive security-buzzword-compliant secure deletion snakeoil software really works. Also, TRIM is only possible with drives that are still in working order. Very often you can't TRIM or secure delete a drive that is defective and returned by RMA. In that case you either need a very expensive no-disk-return support contract. Or you just use FDE.

tjoff 4y ago
TRIM and FDE isn't perfect though as it leaks information about what parts have been written etc. And if you turn off TRIM you get a massive performance decrease.
- vorticalbox 4y ago
  Why would someone turn off TRIM?
  - danuker 4y ago
    To mask the extent to which a drive has been filled, or to figure out how many blocks have been deleted since the last TRIM. I have yet to discover any use for this minuscule "leak", even when considering nation-state adversaries. It's much easier to find other channels to leak data through. The disadvantages are massive, such as significant slowdown when the drive gets filled. Yet the creators of dm-crypt are paranoid about enabling it by default: https://wiki.archlinux.org/title/Dm-crypt/Specialties#Discard/TRIM_support_for_solid_state_drives_(SSD) https://wiki.archlinux.org/title/Dm-crypt/Specialties#Discar... I couldn't understand ref 3: https://web.archive.org/web/20160709174950/http://www.saout.de/pipermail/dm-crypt/2011-September/002019.html https://web.archive.org/web/20160709174950/http://www.saout.... Ref 4: "you have an information leak where filesystem-discarded blocks (by TRIM) can be identified by an attacker with low effort" https://web.archive.org/web/20160709183108/http://www.saout.de/pipermail/dm-crypt/2012-April/002420.html https://web.archive.org/web/20160709183108/http://www.saout....

slicktux 4y ago

HDPARM secure-erase uses the OPAL standard which ensures unused bad blocks, that the drive normally ignores, are erased too. TRIMMING only cleared blocks normally accessible for reading/writing. It’s not as low level… But as someone has mentioned you can just enable encryption and forget the keys…most all SSDs are encrypting from new…user and master keys just have to be set.

LinuxBender 4y ago

As others have mentioned, use encryption. But that has gaps as someone can hold onto the drive and wait for impossible to break to become somewhat expensive to break to broke by mistake through bad encryption implementation. Put the encrypted drive into a hydraulic press and flatten it into a thin sheet, then run that sheet through a chop saw, or just use tin-snips if your hydraulic press was powerful enough. A hydraulic press and a chop saw are a few hundred bucks whereas drive shredders can range from $30k to $200k.

ChoGGi 4y ago
I think an angle grinder would be more accessible than a press.
- fdeee 4y ago
  Open them, heat treat the disks in a bonfire, use the magnets as fridge magnets (those are quite strong, can fix entire books to the fridge instead of just notes).
  - chipsa 4y ago
    Last I checked, SSDs don't have those (see thread title).
13of40 4y ago
Delete all the files then "dd" from the random device until the drive is full? Must we always jump straight to the hydraulic press?
- bcoates 4y ago
  As mentioned in the article, that's not reliable. Drives have lots of overprovision blocks and there's no way of consistently forcing them to be used; and drives might mark blocks as too questionable/worn to reuse and never reset them. Also a standard failure mode of SSDs is refusing to accept writes, so you'll have to handle that case.

katdork 4y ago

The absurdity here that you can't do it because your BIOS won't let you, hdparm can do this! You can literally just boot a Live USB! https://wiki.archlinux.org/title/Solid_state_drive/Memory_cell_clearing https://wiki.archlinux.org/title/Solid_state_drive/Memory_ce... And anyone who thought TRIM would be a reliable way to get rid of data to begin with didn't have an understanding of TRIM!

mharsch 4y ago

The keyword / feature you're looking for is 'sanitization'. https://ieeexplore.ieee.org/document/10008943 https://ieeexplore.ieee.org/document/10008943

tracker1 4y ago

If security is your biggest concern, and not reuse... then using industrial shredding machinery is your best bet. If you want reuse... then a handful of fill/erase cycles with random data is probably your best bet, even then, there will still likely be some overprovisioned blocks with prior data. Encryption and throwing away the key doesn't do more than random data to fill said drive.

dark-star 4y ago

I'm surprised people actually think TRIMming is in any way a "secure delete" operation. It's basically the "quick format" of SSDs: "hey, all those blocks here, I don't care about them anymore, use them as if they were free..." Without OS-side encryption, Secure Erase is the only reliable option (SSD encrypts everything with an internal key which then gets deleted by the secure erase command, leaving only random data behind)

marcosdumay 4y ago
> It's basically the "quick format" of SSDs: "hey, all those blocks here, I don't care about them anymore, use them as if they were free..." Due to implementation details, SSDs can only use a block if it is clear. Thus trimming a block and waiting for long enough would be sufficient to erase the data if the driver actually enforced that the block will be reused. So, it's not good enough, but this is not obvious at all.
- pkaye 4y ago
  But there is a logical to physical mapping table so that data might be spread across multiple physical blocks.

h2odragon 4y ago

https://en.wikipedia.org/wiki/Thermite https://en.wikipedia.org/wiki/Thermite Securely erases all known forms of electronic data storage. Cheap, reliable, fun for the whole family!

wkat4242 4y ago
That's it. You can't beat maximum entropy :D
MarkusWandel 4y ago
There was (is?) a type of hard disk where the platters are made out of glass. These are easy to dispose of securely... drop onto a concrete floor from about six feet up. Shake, feel finely pulverized glass rattling around inside. Done.
- flangola7 4y ago
  How do you magnetize glass?
  - h2odragon 4y ago
    With a thin coating of "stuff" that peels off like metallic foil. Iron oxide spiced with rare earths I think it usually is. The pics in this article illustrate it: https://www.extremetech.com/computing/326292-why-lying-about-storage-products-is-bad-an-ibm-deskstar-story https://www.extremetech.com/computing/326292-why-lying-about...

Felminor 4y ago

Most relevant ssds are always encrypted. I don't think it's necessary to delete it. But if you want, write the disk fully

verall 4y ago

If your bios is not allowing secure ATA functionality ("frozen" in hdparm) try doing a pm-suspend and then waking back up. For me this unfroze the drive, although I have no idea why. I was then able to mess with ata security options, run secure erase, etc.

calebio 4y ago
IIRC it is often frozen by the BIOS on boot. I think the pm-suspend/wake 'reinits' (for lack of a better word) the drive and doesn't set the magic frozen bit. I'd love to know from someone who has the actual tech details vs. my half-remembering an explanation from a wiki.

avianlyric 4y ago

Somethings not mentioned in the article, but are pretty relevant. Modern SSD controllers encrypt all data by default. Not to increase security, to improve wear levelling. Encrypted data should be effectively random data (that’s what good encryption aims to produce). So encrypting the data ensures that patterns in data written to the SSD don’t end up creating uneven wear patterns in the flash chips. As a consequence, reading the raw data of an SDD would just produce garbage. You would need to also extract the encryption key from the SSD controller. Given this encryption isn’t meant to be secure, it’s quite possible to extracting that key is quite easy. But I believe that secure erase on SSDs is achieved by simply rotating the encryption key used for wear levelling, so maybe it’s reasonable well protected. I would expect an SSD to quite aggressively erase TRIMed blocks where possible. Erasing a block of flash memory is about 10x slower (2ms) than writing to flash memory (200microseconds), so there’s quite a large performance hit once a drive runs out of empty blocks and needs to start erasing blocks in the write path. Overall I suspect that simply TRIMing most SSD is secure enough for most applications. At least secure enough for anyone that even asks the question “is TRIMing secure enough”. For everyone else, you either don’t care at all, or your really care, in which case you’re using multiple layers of security such as full disk encryption, secure SSD erase, and shredding drives already.

timbre1234 4y ago
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 you do erase-ahead, you don't erase too far ahead of your writing and you certainly don't erase at TRIM time in most cases.
- avianlyric 4y ago
  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?

wkat4242 4y ago

If you care about security then you'd have full disk encrypted the thing anyway. So really, it's not a problem.

adav 4y ago

Take the drive out and smash it to bits.

tripdout 4y ago

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?

h506001 4y ago
Not sure how secure erase works, but I’ve run into this a few times after “erasing”. I think it has something to do with boot records or partition tables. So there’s a piece of some drives (usually at the front) that contains this data. You can overwrite it properly with the appropriate tools. I always just used `dd` on the raw drive ref in Linux to blow it up.
avianlyric 4y ago
I think ZFS identifies drives by their serial number. So you can erase a drive in a pool, and ZFS on that machine will still recognise the drive based on its serial number, and know its pool membership. ZFS should then throw all kinds of errors once it notices that all the super locks and other FS metadata is missing. But a scrub should cause ZFS to simply fix that via normal resilvering.
- anecdotal1 4y ago
  No, ZFS identifies by finding superblocks. This drive was not securely erased if any superblocks could still be found.
ridgered4 4y ago
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.

upofadown 4y ago

Why is this so hard? Why can't we just specify that a particular file needs to be actually deleteable and that we don't want the system (at any level) to leak copies of any of the data in that file? There is no technical reason this is not possible, it is just a convention that has caused problems since the dawn of computing. There is no point in making a file system that supports that filesystem would not be able to specify deleteabiliy to the hardware. There is no point in making hardware that supports this because there is no file system that exists that would have anything to tell the hardware. This situation exists simply because of inertia. Sure there would be performance implications, but who would care? You might just want to store a key for some full performance encrypted data that you would like to be able to actually remove access to. Sometimes performance is not the most important thing to optimize for.

wtallis 4y ago
> There is no technical reason this is not possible, it is just a convention that has caused problems since the dawn of computing. Technical reasons are all over the place, because the only "convention" you could possibly be referring to is the practice of having layers of abstraction for compatibility purposes. If you want to re-design your entire storage stack to accommodate every new technology, then it's trivial to ensure deleteability in each from-scratch re-design. But as soon as you want to use flash memory to build a drop-in replacement for hard drives, it gets quite difficult to retain this property without making huge sacrifices to more desirable properties.
- upofadown 4y ago
  It would be possible to add this particular bit of information without changing anything that affects compatibility. The only difference would be that some files would actually be deleted when a delete operation was applied. It is a separate information channel that can be added on top. This has nothing in particular to do with flash vs spinning rust. A copy on write file system for example generates tons of information leaking copies all the time, but could trivially be be changed so that some files did not leak in that way. This is truly one of those issues that exists simply because no one can be bothered to fix it.

WirelessGigabit 4y ago

Edit: Below doesn't apply to T2 enabled Macs. If you erase the volume, regardless of whether you had FileVault enabled or not, the key is deleted [0]. If FileVault isn’t enabled on a Mac with the T2 chip during the initial Setup Assistant process, the volume is still encrypted, but the volume key is protected only by the hardware UID in the Secure Enclave. and When deleting a volume, its volume key is securely deleted by Secure Enclave [0] https://www.apple.com/mideast/mac/docs/Apple_T2_Security_Chip_Overview.pdf https://www.apple.com/mideast/mac/docs/Apple_T2_Security_Chi... ----------------------------------------------- Incorrect ramblings below: ----------------------------------------------- Apple recommends setting up FileVault on their SSDs. It is literally the only way to ensure that the data on the SSD is not recoverable. And you should do this before you put anything ON the Mac. If you add a file and only later encrypt the drive, you have no guarantee that that file still isn't somewhere readable one way or another. This is important when you think about buying a Mac and then choose to return it 3 days later. Apple states [0]: Note: With a solid-state drive (SSD), secure erase options are not available in Disk Utility. For more security, consider turning on FileVault encryption when you start using your SSD drive. On their dedicated encryption page [1] they do state that devices with T2 are encrypted by default: Note: If you have an iMac Pro or another Mac with an Apple T2 Security Chip, the data on your drive is already encrypted automatically. However, turning on FileVault provides further protection by requiring your login password to decrypt your data. However I can't find any reference to see how to reset that built-in key. [0] https://support.apple.com/guide/disk-utility/erase-and-reformat-a-storage-device-dskutl14079/mac https://support.apple.com/guide/disk-utility/erase-and-refor... [1] https://support.apple.com/guide/mac-help/encrypt-mac-data-with-filevault-mh11785/mac https://support.apple.com/guide/mac-help/encrypt-mac-data-wi...

TacticalCoder 4y ago

Full disk encryption that are decrypted using a U2F security keys are now here (latest LUKS/systemd allows to do that). And Yubikey don't leak secrets. If your system is compromised to the point that someone gets access to the full disk decryption key protected by your Yubikey, you've got bigger problem than securely erasing the disk. Need to recommission a disk? dd to the disk because why not. Some sectors didn't get dd'ed? Well, the bad guys need your Yubikey too. So, really, what do we think about Yubikeys? Are people now going to steal your Yubikey in addition to finding the sectors that weren't overwritten by dd?

calebio 4y ago
is the Yubikey protected by some kind of pin or password or something? and is there something that prevents someone from brute forcing that pin/password if they have access to the Yubikey? I've not used a Yubikey in this way before, sounds really neat.