SSD Secure Erase

From Thomas-Krenn-Wiki
Jump to: navigation, search

In this article, we will show you how to perform a secure erase on a SSD under Linux. By doing this, you can increase the performance of frequently used SSDs for future use. But, all of the data will be lost. For Fusion-io’s ioDrives, see Low-level Formatting a Fusion-io ioDrive.

Update as of August 2011: Because an ATA trim will be performed by NTFS with Windows 7 or when formatting using Ext4 from mke2fs 1.41.10 or XFS from xfsprogs 3.1.0, the secure erase procedure is no longer necessary in these cases (see Goal of a Secure Erase below). If the spare area should be increased for a used SSD (such as by means of SSD Over-provisioning using hdparm), it is still reasonable to delete all blocks before increasing the size of the spare area (which is something like performing a format including trim across the entire disk capacity, or with a secure erase).

Goal of a Secure Erase

According to the ATA specification, a secure erase should guarantee the secure erasure of all stored data on a storage medium. Most SSDs support secure erase, executing it for the physical deletion of all blocks on the SSD. The SSD will then be usable at its original ideal performance level, since all pages can be written directly (see Solid State Drive - Writing).

For the newer SSDs with integrated encryption, secure erase may be implemented differently. Such SSDs automatically encrypt all data that has been written. Deleting the key would be sufficient to for a secure erase; the data could then no longer be decrypted, but would still physically exist.[1] When asked at the end of the Optimizing Solid-State Drive (SSD) Performance for Data Center Applications session at Intel Developer Forum 2011, Tahmid Rahman, Intel Senior Technical Marketing Engineer, informed us that the Intel 320 Series SSDs and Intel 710 Series SSDs with integrated encryption would also continue to delete the flash blocks despite this ability to delete only the key. The primary reason is that a secure erase should return performance to its initial state even with these SSDs. For Sandisk SSDs the behavior is differnt, a Secure Erase does not erase all NAND.[2]

For other SSDs with integrated encryption, which do not sufficiently document the behavior of a secure erase, deleting the SSD blocks using trim would be recommended in addition to a secure erase, in order to get the ideal performance for re-use of the SSDs. Windows 7 automatically performs a trim when formatting, as do the Ext4 from mke2fs 1.41.10 and XFS from xfsprogs 3.1.0.

The hdparm tool for Linux provides an additional option, however the man page advises against using the option with hdparm version 9.27 (Ubuntu 10.10):

       --trim-sector-ranges
              For  Solid  State  Drives (SSDs).  EXCEPTIONALLY DANGEROUS. DO NOT USE THIS FLAG!!  Tells
              the drive firmware to discard unneeded data sectors, destroying any data  that  may  have
              been  present  within  them.  This makes those sectors available for immediate use by the
              firmware's garbage collection mechanism, to improve scheduling for wear-leveling  of  the
              flash  media.   This  option expects one or more sector range pairs immediately after the
              flag: an LBA starting address, a colon, and a sector count, with no  intervening  spaces.
              EXCEPTIONALLY DANGEROUS. DO NOT USE THIS FLAG!!

              E.g.  hdparm --trim-sector-ranges 1000:4 7894:16 /dev/sdz

Steps necessary for a Secure Erase

We have taken the following steps from the ATA wiki at kernel.org.[3] In the example, the SSD to be deleted has the device name /dev/sdb. If you want to perform a secure erase, pay special attention to the correct device name, so that you will not erroneously delete the wrong drive.

Important Note: Only execute a secure erase when running the SSD directly from a SATA port, since problems may arise otherwise.[3]

Step 1: NOT Frozen

In the first step, check if the SSD is in the not frozen state and support SSD Secure Erase (supported: enhanced erase):

root@ubuntu-10-04:~# hdparm -I /dev/sdb

/dev/sdb:

ATA device, with non-removable media
	Model Number:       INTEL SSDSA2M160G2GC                    
	Serial Number:      CVPO014602FC160AGN  
	Firmware Revision:  2CV102HD
	Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6
[...]
Security: 
	Master password revision code = 65534
		supported
	not	enabled
	not	locked
	not	frozen
	not	expired: security count
		supported: enhanced erase
	2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.
[...]

Step 2: Set the User Passwords

So that you can execute a secure erase, you must first define a user password. In the example, we have used the password, Eins. The security feature will be enable thereafter.

Warning: If you set the user password, the SSD will entire the locked state after re-booting. The SSD will then block all normal access until it is re-locked with the correct password. However, if you perform the additional steps completely (without re-booting), the security feature will be automatically deactivated.

root@ubuntu-10-04:~# hdparm --user-master u --security-set-pass Eins /dev/sdb
security_password="Eins"

/dev/sdb:
 Issuing SECURITY_SET_PASS command, password="Eins", user=user, mode=high
root@ubuntu-10-04:~# hdparm -I /dev/sdb
[...]
Security: 
	Master password revision code = 65534
		supported
		enabled
	not	locked
	not	frozen
	not	expired: security count
		supported: enhanced erase
	Security level high
	2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.
[...]

Step 3: Secure Erase

Now, execute the secure erase procedure:

root@ubuntu-10-04:~# time hdparm --user-master u --security-erase Eins /dev/sdb
security_password="Eins"

/dev/sdb:
 Issuing SECURITY_ERASE command, password="Eins", user=user

real	0m55.408s
user	0m0.000s
sys	0m0.000s
root@ubuntu-10-04:~# 

Step 4: Checking

After the secure erase procedure has completed, the SSD security feature will be disabled.

root@ubuntu-10-04:~# hdparm -I /dev/sdb
[...]
Security: 
	Master password revision code = 65534
		supported
	not	enabled
	not	locked
	not	frozen
	not	expired: security count
		supported: enhanced erase
	2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.
[...]

References

  1. The Intel SSD 320 Review: 25nm G3 is Finally Here: TRIM Performance (anandtech.com): A side effect of having all data encrypted on the NAND is that secure erases happen much quicker. You can secure erase a SF drive in less than three seconds as the controller just throws away the encryption key and generates a new one. Intel's SSD 320 takes a bit longer but it's still very quick at roughly 30 seconds to complete a secure erase on a 300GB drive. [...] Without the encryption key, the data stored in the NAND array is meaningless.
  2. What is the difference between Secure Erase and Sanitize? (kb.sandisk.com)
  3. 3.0 3.1 https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase


Foto Werner Fischer.jpg

Author: Werner Fischer

Werner Fischer, working in the Web Operations & Knowledge Transfer team at Thomas-Krenn, completed his studies of Computer and Media Security at FH Hagenberg in Austria. He is a regular speaker at many conferences like LinuxTag, OSMC, OSDC, LinuxCon, and author for various IT magazines. In his spare time he enjoys playing the piano and training for a good result at the annual Linz marathon relay.


Related articles

Apache Performance Tuning
Bash redirect sdtout and stderr
KSM (Kernel Samepage Merging)