Support Center

Secure Erasing Data on SSDs

Last Updated: Mar 25, 2019 10:33PM PDT
This article discusses the reality of attempting to secure-erase content on SSDs, giving justification to the need for formalized procedures around secure disposal of sensitive data.

Introduction
:xRecovery
provides a convenient mechanism for recovering Organization data, but how do you insure that you've removed plaintext content from Solid State Disk storage devices?

In short, you don't. You a) use disk encryption, and b) destroy the device when it is no longer in use.


The Reality of Simple Deletes
In reality, filesystem Delete operations remove filesystem directory entries, leaving materials intact. Though not directly accessible using standards filesystem tools, specialized tools search for and reclaim unmodified content (file fragments).

This is in fact how, "undelete" works - programs find content that's been erased in directory entries (allocation tables such such) but haven't otherwise been overwritten (the fragments). The files are then reconstructed by creating new index entries that present content back to the operating system in a valid way.

This is why some undelete operations only recover parts of files - in some cases, some fragments have been used by subsequent write operations. Those are removed from the undeleted file, leaving gaps between recovered and original content.


Magnetic Media and Secure Erase
You may have seen Security software with the claim to, "Secure Erase" information from a mass storage device. PGP first offered this many years (decades) ago, and (some) anti-virus vendor security "suites" offer this capability today. The motivation is, of course, to completely remove sensitive content such that it cannot be recovered.

In order to do this with magnetic spinning drives (HDDs), one has to not only remove directory indices while overwriting file fragments, but due to the nature of magnetic media, must do so in a certain way. This removes, "residual" magnetic signatures that forensic tools can detect and use to reconstruct valid data. As such, "real" secure erase algorithms use a sequence of write operations (usually 7 or more) with different and/ or random patterns, making certain the magnetic image didn't reflect original content in a recoverable way.

SSDs and Wear Leveling
Solid State Drives present a different problem. The technology is such that writes must be distributed evenly across device memory to evenly distribute memory cell usage. This is due to the relatively limited lifecycle of a memory cell, which can only be rewritten a certain number of times before it starts to fail (stops to work). These wear-leveling algorithms are implemented in the hardware associated with the SSD, as they are specific to the, "geometry" of the device and type of memory used for storage.

Without wear-leveling algorithms, the drive would wear out quickly, and use wouldn't be practical. As a result, it's nearly impossible to tell where the information is being physically written (since wear leveling is implemented in drive firmware, as noted).

That means it's virtually impossible to overwrite file fragments since you cannot control the physical destination of a write (not easily anyway - such information isn't generally published, even to those that purchase the hardware directly).

This makes SSD recycling critically important: Whereas traditional HDDs can be directly and fully erased, it isn't always possible to do so with an SSD (even if the manufacturer claims to support unique instructions to achieve that same result - these aren't always reliable claims).

Disposal Procedures
Every resource used to manage sensitive materials should be subject to proper use policies and procedures, more specifically processes designed to make certain sensitive content isn't transferred to a new user if the hardware is re-provisioned. Unless you can be certain a particular SSD permits low-level access to physical memory, it's best not to re-use SSDs that contain sensitive content - which in most cases means SSDs shouldn't ever be re-provisioned since even the most innocuous piece of information can be sold for profit in today's environment.

Physical destruction offers the most compelling and reasonable solution to the problem - when the hardware is no longer of use in its original form. Rather than re-purpose it for re-use, it should be physically destroyed (and perhaps recycled for raw materials, though the disposal market hasn't been well-regulated and has been ridden with fraudulent "buyers" literally dumping equipment in the desert rather than responsibly recycling materials as advertised).

Recommendations
When using SSDs, remember that low-level access is not possible and wear-leveling algorithms move data (seemingly) unpredictably. If an attacker gets his or her hands on an SSD with unencrypted sensitive content, it's highly possible he/she can extract useful information by reading the entire content of the drive to piece together chunks of information.

Because writes are different from HDDs and uncontrollable, SSDs should retain physical isolation, should always be externally encrypted w/ key isolation using something like a TPM, and should be completely destroyed and only then recycled for raw materials.

Question: Would you trust drive encryption technology, implemented in the firmware, and all claims given by a manufacturer when built in another country and in tandem being offered with a buyback program to recycle content for you? Though there are encryption standards like Opal, this is an area of increasing concern as nation-states have been accused of using their pervasive market coverage to extract data from foreign corporations.


For More Information
Send questions directly to support@definisec.com and our staff will respond as soon as possible.
 

This article was updated w/ v9.1.3 of the :Foundation Client


 

Contact Us

ed5301d112e75fde24d469c55568f50b@definisec.desk-mail.com
https://cdn.desk.com/
false
desk
Loading
seconds ago
a minute ago
minutes ago
an hour ago
hours ago
a day ago
days ago
about
false
Invalid characters found
/customer/en/portal/articles/autocomplete