Stories
Slash Boxes
Comments

SoylentNews is people

posted by mrpg on Friday March 17 2017, @05:14AM   Printer-friendly
from the encrypt-for-the-win dept.

How do you destroy an SSD?

First, let's focus on some "dont's." These are tried and true methods used to make sure that your data is unrecoverable from spinning hard disk drives. But these don't carry over to the SSD world.

Degaussing – applying a very strong magnet – has been an accepted method for erasing data off of magnetic media like spinning hard drives for decades. But it doesn't work on SSDs. SSDs don't store data magnetically, so applying a strong magnetic field won't do anything.

Spinning hard drives are also susceptible to physical damage, so some folks take a hammer and nail or even a drill to the hard drive and pound holes through the top. That's an almost surefire way to make sure your data won't be read by anyone else. But inside an SSD chassis that looks like a 2.5-inch hard disk drive is actually just a series of memory chips. Drilling holes into the case may not do much, or may only damage a few of the chips. So that's off the table too.

Erasing free space or reformatting a drive by rewriting it zeroes is an effective way to clear data off on a hard drive, but not so much on an SSD. In fact, in a recent update to its Mac Disk Utility, Apple removed the secure erase feature altogether because they say it isn't necessary. So what's the best way to make sure your data is unrecoverable?


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Friday March 17 2017, @07:06AM (7 children)

    by Anonymous Coward on Friday March 17 2017, @07:06AM (#480260)

    I want to get rid of it anyway. Encrypt it, fill it full of anything and/or nothing, and lose the encryption key. That could be the first step, as well as the last step. Encrypt, fill with data, reformat, encrypt, fill with data, reformat, encrypt, fill with data. What are the flaws? You can repeat these steps as many times as you wish - two, twenty, or two hundred times.

  • (Score: 4, Informative) by Immerman on Friday March 17 2017, @08:10AM (5 children)

    by Immerman (3985) on Friday March 17 2017, @08:10AM (#480283)

    The flaw is if you didn't encrypt *before* writing the sensitive data in the first place.

    Because, as the most-extreme example, it's possible that that sensitive data was written to an about-to-fail cell, which was subsequently retired by the wear-leveling algorithm and completely removed from use. At that point it becomes completely impossible to access or change the data in it through any normal means - rewrite the drive a million times, and that cell will still never be touched. But desolder the chip and stick it in a chip reader, and whatever was written to it last will still be there.

    • (Score: 0) by Anonymous Coward on Friday March 17 2017, @09:29AM (3 children)

      by Anonymous Coward on Friday March 17 2017, @09:29AM (#480314)

      All modern SSD's are encrypted by default, with a unique key that is automatically applied at boot (unless you apply a secure passphrase in the BIOS, which actually changes the encryption key). This is to prevent wear on the cells when the drives are re-formatted. "Formatting" a modern SSD seems instantaneous because the process really just changes the encryption key to something unknown.

      So grandparent is sort of correct, but you would need an OS-level format of the drive as well to change the original key.

      • (Score: 2) by Immerman on Friday March 17 2017, @03:14PM (2 children)

        by Immerman (3985) on Friday March 17 2017, @03:14PM (#480434)

        Are you sure? I've found precious little documentation about the subject, and it would be good to know.

        On the general subject, it's also worth noting that the ultimate security of "erasing" in this manner is entirely dependent on
        1) the drives flawless implementation of a flawless encryption algorithm
        2) the use of a secure password (in the case of the default master password truly random, high-entropy, and unknown to anyone else?)

        Even with the encryption, if I were being just a tiny bit paranoid I'd still overwrite the drive with random noise a couple times to try to truly wipe out the sensitive data instead of just relying on the security of the encryption (not zeros, which might actually overwrite only a single cell if the firmware does de-duplication). Just on general principle. SSDs are fast, and it's not like a couple of extra writes is going to wear out the cells significantly.

        If I were a lot paranoid, I'd pulverize or incinerate the drive. There's just no way to get the same level of confidence in the security of an SSD wipe that you get from writing a few passes of random noise to a HDD.

    • (Score: 2) by darkfeline on Friday March 17 2017, @06:20PM

      by darkfeline (1030) on Friday March 17 2017, @06:20PM (#480537) Homepage

      Sensitive data should never be stored or transmitted unencrypted anyway.

      --
      Join the SDF Public Access UNIX System today!
  • (Score: 2) by Immerman on Friday March 17 2017, @03:27PM

    by Immerman (3985) on Friday March 17 2017, @03:27PM (#480448)

    Realized I forgot to address an important point:

    >Encrypt, fill with data, reformat, encrypt, fill with data....
    Encrypting during the attempt to overwrite is completely pointless - you're encrypting random noise to get...other random noise, which you then write to disk. The added layer of "randomness" from encryption contributes nothing to the process. You do want to use random noise rather than zeros though, just in case the firmware does any de-duplication, which could cause a "full disk" zero-wipe to actually only overwrite write a few cells)

    Though... if you're using the integrated disk encryption, I suppose repeated re-encryption with different keys could make the original internally stored keys more difficult to recover, essentially performing a multi-pass wipe of the key store. You wouldn't need to write any data, just encrypt/"eerase"/encrypt/"erase", since you're only targetting the key store with this part. But that might be total overkill - you'd *hope* that the drive would internally make $#@! sure that key was *gone* the first time you told it to get rid of it.