Securely wiping SSDs
I have, for many years, used "Darik's Boot and Nuke" on a USB stick to securely wipe spinning hard disks. It takes a long time, but I mostly understand and trust the process. I'm now at the point that I have to wipe and dispose of SSDs, and I'm feeling a bit shaky on the methodology. Here's what I did: # hdparm -I /dev/sdX Looked for enabled/locked/frozen in the output ... I won't go into making sure those are toggled correctly, but that appears to be needed. This also lists what appears to be info about doing a wipe on the drive: 6min for SECURITY ERASE UNIT, 60min for ENHANCED SECURITY ERASE UNIT Then, set a password (why? but seems to be needed): # hdparm --user-master u --security-set-pass foobar /dev/sdX Last, run the wipe: # hdparm --user-master u --security-erase-enhanced foobar /dev/sdX Doing something like `dd if=/dev/sdX bs=5M count=5 | strings` (or sending it to `less`) definitely shows that it's changed from something organized to something full of identical characters. But I've never seen this wipe process take more than 60 seconds, which makes me wonder about the `hdparm` declaration about the time required for a secure wipe. So I guess the big question is: should I trust this process? Do we really think it's securely wiped? Or should I be taking a hammer to the chips on the SSD because that's the only way to ensure it's fully wiped? -- Giles https://www.gilesorr.com/ gilesorr@gmail.com
We used to have a simple wipe and an enhanced wipe on SunOS. The first one overwrote the disk with a fixed bit pattern, the latter wrote and rewrote it with different patterns. The idea was to make it hard to detect residual magnetism from some older data. Definitely spinning-rust stuff. For anything from Confidential and up, we used the "large grinder" approach (:-)) --dave On 2024-03-23 10:50, Giles Orr via talk wrote:
I have, for many years, used "Darik's Boot and Nuke" on a USB stick to securely wipe spinning hard disks. It takes a long time, but I mostly understand and trust the process.
I'm now at the point that I have to wipe and dispose of SSDs, and I'm feeling a bit shaky on the methodology. Here's what I did:
# hdparm -I /dev/sdX
Looked for enabled/locked/frozen in the output ... I won't go into making sure those are toggled correctly, but that appears to be needed. This also lists what appears to be info about doing a wipe on the drive:
6min for SECURITY ERASE UNIT, 60min for ENHANCED SECURITY ERASE UNIT
Then, set a password (why? but seems to be needed):
# hdparm --user-master u --security-set-pass foobar /dev/sdX
Last, run the wipe:
# hdparm --user-master u --security-erase-enhanced foobar /dev/sdX
Doing something like `dd if=/dev/sdX bs=5M count=5 | strings` (or sending it to `less`) definitely shows that it's changed from something organized to something full of identical characters. But I've never seen this wipe process take more than 60 seconds, which makes me wonder about the `hdparm` declaration about the time required for a secure wipe.
So I guess the big question is: should I trust this process? Do we really think it's securely wiped? Or should I be taking a hammer to the chips on the SSD because that's the only way to ensure it's fully wiped?
-- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest dave.collier-brown@indexexchange.com | -- Mark Twain CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including any and all attachments, contains confidential information intended only for the person(s) to whom it is addressed. Any dissemination, distribution, copying or disclosure is strictly prohibited and is not a waiver of confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and delete the message from your inbox and deleted items folders. This telecommunication does not constitute an express or implied agreement to conduct transactions by electronic means, nor does it constitute a contract offer, a contract amendment or an acceptance of a contract offer. Contract terms contained in this telecommunication are subject to legal review and the completion of formal documentation and are not binding until same is confirmed in writing and has been signed by an authorized signatory.
Not that long ago I had to erase an SSD, and found that DBAN doesn't work with SSDs :-( . So, I did find the following, which does seem to happily erase (securly I hope) SSDs, HDs and other read/write media (different code base, but exactly the same concept as DBAN) : https://aban.derobert.net/ Hope this helps. Colin. On Sat, Mar 23, 2024 at 10:50 AM Giles Orr via talk <talk@gtalug.org> wrote:
I have, for many years, used "Darik's Boot and Nuke" on a USB stick to securely wipe spinning hard disks. It takes a long time, but I mostly understand and trust the process.
I'm now at the point that I have to wipe and dispose of SSDs, and I'm feeling a bit shaky on the methodology. Here's what I did:
# hdparm -I /dev/sdX
Looked for enabled/locked/frozen in the output ... I won't go into making sure those are toggled correctly, but that appears to be needed. This also lists what appears to be info about doing a wipe on the drive:
6min for SECURITY ERASE UNIT, 60min for ENHANCED SECURITY ERASE UNIT
Then, set a password (why? but seems to be needed):
# hdparm --user-master u --security-set-pass foobar /dev/sdX
Last, run the wipe:
# hdparm --user-master u --security-erase-enhanced foobar /dev/sdX
Doing something like `dd if=/dev/sdX bs=5M count=5 | strings` (or sending it to `less`) definitely shows that it's changed from something organized to something full of identical characters. But I've never seen this wipe process take more than 60 seconds, which makes me wonder about the `hdparm` declaration about the time required for a secure wipe.
So I guess the big question is: should I trust this process? Do we really think it's securely wiped? Or should I be taking a hammer to the chips on the SSD because that's the only way to ensure it's fully wiped?
-- Giles https://www.gilesorr.com/ gilesorr@gmail.com --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
It depends on your paranoia level. In the good old days, there were no levels hiding the disk sectors from the computer. Then came automatic sector mapping for bad blocks. Really convenient. But how are you going to wipe those mapped-out blocks? As far as I know, there is no way to do so. But there are probably only a few such blocks and they are probably somewhat defective. We'll ostrich the problem away. Then came flash memory with wear-levelling firmware between the computer and the bulk flash. And the devices are over-provisioned: there is more flash than "simulate" disk space. I don't think you can be sure to have erased it. Maybe I'm wrong. Some disks have a feature where they have a key that encrypts every block. The key persists in the drive. But if you want to wipe the disk, you change this key. Then every block is nonsense until it is rewitten. I haven't got time to look up the name for this feature. It is optional. I think that most enterprise drives have it.
| From: D. Hugh Redelmeier via talk <talk@gtalug.org> | Some disks have a feature where they have a key that encrypts every block. | The key persists in the drive. But if you want to wipe the disk, you | change this key. Then every block is nonsense until it is rewritten. | I haven't got time to look up the name for this feature. It is optional. | I think that most enterprise drives have it. The feature is called "Self-Encrypting Drive" (SED). This seems like the only way to safely allow a drive to be re-used by a someone you don't trust. <https://www.techspot.com/guides/869-self-encrypting-drives/> Note: that's an old article. The simplest way of using it makes the encryption / decryption invisible to the computer. You just have to change the key to do a "secure erase". There is a next level in which the drive requires a password when powered on. This isn't needed for Secure Erase. Apparently a lot of drives have Secure Erase but the feature is rarely advertised. Sad fact: you may only realize that you want this feature long after you bought it.
In addition to 'hdparm', I have 'shred' and 'blkdiscard' on my computer. Other distros may vary. -- On 2024-03-23 10:50, Giles Orr via talk wrote:
I have, for many years, used "Darik's Boot and Nuke" on a USB stick to securely wipe spinning hard disks. It takes a long time, but I mostly understand and trust the process.
I'm now at the point that I have to wipe and dispose of SSDs, and I'm feeling a bit shaky on the methodology. Here's what I did:
# hdparm -I /dev/sdX
Looked for enabled/locked/frozen in the output ... I won't go into making sure those are toggled correctly, but that appears to be needed. This also lists what appears to be info about doing a wipe on the drive:
6min for SECURITY ERASE UNIT, 60min for ENHANCED SECURITY ERASE UNIT
Then, set a password (why? but seems to be needed):
# hdparm --user-master u --security-set-pass foobar /dev/sdX
Last, run the wipe:
# hdparm --user-master u --security-erase-enhanced foobar /dev/sdX
Doing something like `dd if=/dev/sdX bs=5M count=5 | strings` (or sending it to `less`) definitely shows that it's changed from something organized to something full of identical characters. But I've never seen this wipe process take more than 60 seconds, which makes me wonder about the `hdparm` declaration about the time required for a secure wipe.
So I guess the big question is: should I trust this process? Do we really think it's securely wiped? Or should I be taking a hammer to the chips on the SSD because that's the only way to ensure it's fully wiped?
The original request was for a Linux command line utility. However, if any O/S and control interface is acceptable (E.g. Windows GUI program), and possibly having to trust closed-source code, then you may wish to check if the manufacturer of the SSD drive has a utility targeted to wiping your particular model. For example: Intel: https://www.intel.com/content/www/us/en/support/articles/000006084/memory-an... Samsung: https://semiconductor.samsung.com/us/consumer-storage/magician/ -- Scott
On 2024-03-23 10:50, Giles Orr via talk wrote:
I have, for many years, used "Darik's Boot and Nuke" on a USB stick to securely wipe spinning hard disks. It takes a long time, but I mostly understand and trust the process.
I'm now at the point that I have to wipe and dispose of SSDs, and I'm feeling a bit shaky on the methodology. Here's what I did:
# hdparm -I /dev/sdX
If the disks are destine for the electronic waste bin the lowest tech solution is a hammer with a sharp pointy end. Or a hammer and a center punch. Pierce the cover and bend the disks, at that point only a government level lab may be able to reconstruct the data. The same center punch on a chip will also make the data unrecoverable. Also pounding the crap out of a disk drive is very cathartic. -- Alvin Starr || land: (647)478-6285 Netvel Inc. || Cell: (416)806-0133 alvin@netvel.net ||
If the data that will be stored on a new drive is confidential enough that a privacy leak would be Bad then the current standard of care would seem to be encryption so that if the media did go walkabout it would not be readable. If you’re going to reuse a device for a new project then losing the encryption pass phase and reformatting should suffice, with maybe one pass of zeros to be sure. And on disposal, the golden standard has always been physical destruction. I understand the Pentagon uses thermite for this purpose, but I have access to a pneumatic chisel and reshape the device with that. Anthony
On 2024-03-23 22:25, James Knott via talk wrote: On 3/23/24 22:02, Anthony de Boer via talk wrote: And on disposal, the golden standard has always been physical destruction. I don't know if it's been mentioned, but what about the shred command? Quite good for rotating magnetic drives that aren't log-structured. --dave -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest dave.collier-brown@indexexchange.com<mailto:dave.collier-brown@indexexchange.com> | -- Mark Twain CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including any and all attachments, contains confidential information intended only for the person(s) to whom it is addressed. Any dissemination, distribution, copying or disclosure is strictly prohibited and is not a waiver of confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and delete the message from your inbox and deleted items folders. This telecommunication does not constitute an express or implied agreement to conduct transactions by electronic means, nor does it constitute a contract offer, a contract amendment or an acceptance of a contract offer. Contract terms contained in this telecommunication are subject to legal review and the completion of formal documentation and are not binding until same is confirmed in writing and has been signed by an authorized signatory.
From academic papers: dd was found to work on local devices in article 1, remote wiping of phones was found to be immature/buggy in 2.
1. Secure State Deletion: Testing the efficacy and integrity of secure deletion tools on Solid State Drives, M Freeman, A Woodward - ro.ecu.edu.au Secure State Deletion: Testing the efficacy and integrity of secure deletion tools onSolid State Drives The research aimed to determine the efficacy and integrity of several hard-drive disk deletion tools on solid state drives (SSDs). SSDs contain new technologies such as wear-levelling and device under provisioning to provide efficient functionality and speed for data management, but the same technologies may also provide obstacles to ensuring that all information is fully removed from the drive. Furthermore SSDs stores files in 4KB pages, yet data can only be deleted in 512KB blocks. This function uses the disk controller to remove all the pages from the block a file is being deleted from, storing the pages in a disk controlled cache. Once the whole block has been reset, the valid data is retrieved from the cache and replaced on an available block. The reset block is added to the SSDs free space. The specific purpose of this paper was to discover if any data was recovered, especially from the disk controlled cache while testing various tools and methods for their effectiveness of securely wiping data off SSDs. All tools except the GNU core utility DD left some file information which was recovered, though none of the recovered files was loadable. Additionally, the paper introduces the concept of the TRIM functionality and provides a baseline further research into this feature. Finally, a comparison of methods for securely deleting Solid State Drives is provided. 🔗 https://ro.ecu.edu.au/adf/65/<https://ro.ecu.edu.au/adf/65/> 2. Remote wiping and secure deletion on mobile devices: A review, MD Leom, KKR Choo, R Hunt - Journal of forensic sciences, 2016 https://onlinelibrary.wiley.com/doi/abs/10.1111/1556-4029.13203 -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest dave.collier-brown@indexexchange.com<mailto:dave.collier-brown@indexexchange.com> | -- Mark Twain CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including any and all attachments, contains confidential information intended only for the person(s) to whom it is addressed. Any dissemination, distribution, copying or disclosure is strictly prohibited and is not a waiver of confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and delete the message from your inbox and deleted items folders. This telecommunication does not constitute an express or implied agreement to conduct transactions by electronic means, nor does it constitute a contract offer, a contract amendment or an acceptance of a contract offer. Contract terms contained in this telecommunication are subject to legal review and the completion of formal documentation and are not binding until same is confirmed in writing and has been signed by an authorized signatory.
I grilled my local hardware security friend who said you should never trust the secure delete feature in ssd . In general it has been found insecure. As mentioned the "Large grinder" seems like the only way to be sure. On Sat., Mar. 23, 2024, 10:50 Giles Orr via talk, <talk@gtalug.org> wrote:
I have, for many years, used "Darik's Boot and Nuke" on a USB stick to securely wipe spinning hard disks. It takes a long time, but I mostly understand and trust the process.
I'm now at the point that I have to wipe and dispose of SSDs, and I'm feeling a bit shaky on the methodology. Here's what I did:
# hdparm -I /dev/sdX
Looked for enabled/locked/frozen in the output ... I won't go into making sure those are toggled correctly, but that appears to be needed. This also lists what appears to be info about doing a wipe on the drive:
6min for SECURITY ERASE UNIT, 60min for ENHANCED SECURITY ERASE UNIT
Then, set a password (why? but seems to be needed):
# hdparm --user-master u --security-set-pass foobar /dev/sdX
Last, run the wipe:
# hdparm --user-master u --security-erase-enhanced foobar /dev/sdX
Doing something like `dd if=/dev/sdX bs=5M count=5 | strings` (or sending it to `less`) definitely shows that it's changed from something organized to something full of identical characters. But I've never seen this wipe process take more than 60 seconds, which makes me wonder about the `hdparm` declaration about the time required for a secure wipe.
So I guess the big question is: should I trust this process? Do we really think it's securely wiped? Or should I be taking a hammer to the chips on the SSD because that's the only way to ensure it's fully wiped?
-- Giles https://www.gilesorr.com/ gilesorr@gmail.com --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
| From: David Thornton via talk <talk@gtalug.org> | I grilled my local hardware security friend who said you should never trust | the secure delete feature in ssd . In general it has been found insecure. It seems hard to accidentally screw up Secure Delete: - everything written to the flash layer is encode - everything read from the flash layer is decoded - secure erase simply changes the key It is fairly easy to intentionally screw up Secure Delete. Trusting Secure Delete involves trusting the manufacturer: there is no sure way to test for this failing. Does your guy have examples or even indications of Secure Delete failing? In particular, what does "In general it has been found insecure." mean? What has been found? How has it been found?
There might have been too much alcohol involved in the conversation to consider it production Ready 🤣 On Mon., Mar. 25, 2024, 09:47 D. Hugh Redelmeier via talk, <talk@gtalug.org> wrote:
| From: David Thornton via talk <talk@gtalug.org>
| I grilled my local hardware security friend who said you should never trust | the secure delete feature in ssd . In general it has been found insecure.
It seems hard to accidentally screw up Secure Delete:
- everything written to the flash layer is encode - everything read from the flash layer is decoded - secure erase simply changes the key
It is fairly easy to intentionally screw up Secure Delete. Trusting Secure Delete involves trusting the manufacturer: there is no sure way to test for this failing.
Does your guy have examples or even indications of Secure Delete failing? In particular, what does "In general it has been found insecure." mean? What has been found? How has it been found? --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Giles Orr via talk wrote on 2024-03-23 07:50:
I have, for many years, used "Darik's Boot and Nuke" on a USB stick to securely wipe spinning hard disks. It takes a long time, but I mostly understand and trust the process.
I'm going to take a contrarian stance and suggest that the best way is to run a pass or two of `dd if=/dev/urandom of=/dev/$disk ...` then just sell or donate the otherwise usable device. Our data is valuable, but not *that* valuable. Anyone coming into possession of a new device is going to think "new storage!" not "if I can pull a few bits of data from this device, I can destroy someone's life and finances". They'll plug it in to a computer, it won't be readable at all since it's not NTFS, and they'll format it NTFS and store their data on it. The NSA, etc. isn't out to get us (through forensic data recovery on discarded devices). https://xkcd.com/538/ Also, reduce e-waste and support those that are in dire financial straights. Pre-format it with NTFS, download https://gtalug.org onto the drive, donate it to someone who'll use it and be thankful for the opportunity. rb
On 2024-03-23 10:50, Giles Orr via talk wrote:
I have, for many years, used "Darik's Boot and Nuke" on a USB stick to securely wipe spinning hard disks. It takes a long time, but I mostly understand and trust the process.
I'm now at the point that I have to wipe and dispose of SSDs, and I'm feeling a bit shaky on the methodology.
In the days of spinning disks I have used the program called 'wipe' to wipe out the contents of a hard drive. It can do multiple passes to make it (almost?) impossible to analyse the magnetic fields of the platters to recover data. To securely wipe data from an SSDs depends on how secure you need to be that the data can not be recovered. I wouldn't trust the use of any software to wipe an SSD due to their wear levelling features. The most reliable method would be to shred the drive or at least take a hammer to the chips that hold the data. -- Cheers! Kevin. https://www.patreon.com/KevinCozens | "Nerds make the shiny things that | distract the mouth-breathers, and Owner of Elecraft K2 #2172 | that's why we're powerful" #include <disclaimer/favourite> | --Chris Hardwick
participants (12)
-
Alvin Starr -
Anthony de Boer -
Colin McGregor -
D. Hugh Redelmeier -
Dave Collier-Brown -
David Thornton -
Giles Orr -
James Knott -
Kevin Cozens -
Ron / BCLUG -
Scott Allen -
William Park