- Solid state drive/Memory cell clearing
- Contents
- SATA drive
- Step 1 — Make sure the drive security is not frozen
- Dell Systems
- Step 2 — Enable security by setting a user password
- Step 3 — Issue the ATA Secure Erase command
- NVMe drive
- Format command
- Sanitize command
- Troubleshooting
- UEFI boot entries get removed after wiping a drive
- Securely wipe disk
- Contents
- Common use cases
- Wipe all data left on the device
- Preparations for block device encryption
- Data remanence
- Operating system, programs and filesystem
- Hardware-specific issues
- Flash memory
- Marked Bad Sectors
- Residual magnetism
- Select a target
- Select a data source
- Zeros
- Random data
- Select a block size
- Calculate blocks to wipe manually
- Overwrite the target
- By redirecting output
- shred
- Badblocks
- hdparm
Solid state drive/Memory cell clearing
On occasion, users may wish to completely reset the SSD to the initial «clean» state it was manufactured with, thus restoring it to its factory default write performance. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.
Performing the Secure Erase does not reset the wear leveling status of SSD cells — a drive close to the end of its lifespan may become writable for a short while, but it will still fail after a limited amount of writes.
Contents
SATA drive
Step 1 — Make sure the drive security is not frozen
Issue the following command:
In the security section of the output it should say «not frozen». If it shows as just «frozen» then you cannot continue to the next step. Some BIOSes block the ATA Secure Erase command by issuing a «SECURITY FREEZE» command to «freeze» the drive before booting an operating system.
A possible solution is to simply suspend the system. Upon waking up, it is likely that the freeze will be lifted. If unsuccessful, one can try hot-(re)plug the data cable (which might crash the kernel). If hot-(re)plugging the SATA data cable crashes the kernel try letting the operating system fully boot up, then quickly hot-(re)plug both the SATA power and data cables. If hot-(re)plugging of SATA cables still crashes the kernel, make sure that AHCI is enabled in the BIOS (AHCI allows hot-(re)plugging operations without a crash). Using a USB-to-SATA adapter is an option if it supports hotplugging. One can also use hdparm via USB.
Dell Systems
If the command output shows «frozen», you may be able to work around it by:
- Reboot into the Dell BIOS by pressing F2 on startup.
- Set the Internal HDD Password in the BIOS (be careful, the keymap is en_US / qwerty).
- Apply the changes and reboot.
- When prompted for the password by Dell Security Manager, press Escape rather than entering it. The drive will remain locked but not frozen.
- Skip step 2, and go directly to Step 3 below.
Step 2 — Enable security by setting a user password
Any password will do, as this should only be temporary. After the secure erase the password will be set back to NULL. In this example, the password is PasSWorD as shown:
As a sanity check, issue the following command
The command output should display «enabled»:
Step 3 — Issue the ATA Secure Erase command
The final step is to issue the secure erase command, instructing the device’s BIOS to erase its contents. Note for the device used in this example, earlier output states:
As per ATA specification the enhanced security erase ( —security-erase-enhanced ) performs a more elaborate wipe. If the estimated completion time for both commands is equal, it indicates the drive manufacturer shortcut the specification and uses the same erase function for both. A short time (like 2 minutes) in turn indicates the device is self-encrypting and its BIOS function will wipe the internal encryption key instead of overwriting all data cells.[2]
Wait until the command completes. This example output shows it took about 40 seconds for an Intel X25-M 80GB SSD.
The drive is now erased. After a successful erasure the drive security should automatically be set to disabled (thus no longer requiring a password for access). Verify this by running the following command:
The command output should display «not enabled»:
NVMe drive
The NVMe specification defines a standardized way to format NVMe drives, since those do not use the SATA interface protocol and therefore cannot be cleared in the same way as SATA SSDs. Originally it was the nvme-format(1) command (part of the nvme-cli ) which provided this feature, but while it still does Specification 1.3 added support for a dedicated nvme-sanitize(1) command. As described by Jonmichael Hands, NVMe MWG Co-Chair, Sr. Strategic Planner / Product Manager, Intel[3]:
«These commands are used to securely erase user data from the device. This can be used when deploying a new device, retiring or at device end-of-life, using an SSD for a new application and so on. Sanitize was introduced in NVMe 1.3 specification, so before then NVMe Format was used exclusively to perform secure erase. While both options work, Sanitize is more robust for ensuring the data was properly wiped; format is good for everyday use and testing.«
In order to verify what is supported by your drive, use the Identify Controller command:
Then proceed with either format or sanitize.
Format command
The Format command is conceptually closer to a mix of hdparm and fdisk, as it allows to set low-level parameters for the drive and additionally to send a secure erase command.
nvme-format(1) gives the following details about the Secure Erase Settings ( -s , —ses= ) option:
Secure Erase Settings: This field specifies whether a secure erase should be performed as part of the format and the type of the secure erase operation. The erase applies to all user data, regardless of location (e.g., within an exposed LBA, within a cache, within deallocated LBAs, etc). Defaults to 0.
Value | Definitions |
---|---|
0 | No secure erase operation requested |
1 | User Data Erase: All user data shall be erased, contents of the user data after the erase is indeterminate (e.g., the user data may be zero filled, one filled, etc). The controller may perform a cryptographic erase when a User Data Erase is requested if all user data is encrypted. |
2 | Cryptographic Erase: All user data shall be erased cryptographically. This is accomplished by deleting the encryption key. |
While the Format command accepts either the whole NVMe character device (e.g. /dev/nvme0 ) or a specific namespace block device (e.g. /dev/nvme0n1 ), make sure this feature is supported by your drive before triggering it. E.g. in the output of the Identify Controller command above, we see that the Crypto Erase Applies to Single Namespace(s) and Format Applies to Single Namespace(s) bits are set to zero, which according to the spec means that «the controller supports format on a per namespace basis» (see figure 249 byte row 524 «Format NVM Attributes (FNA)»).
For example, to format /dev/nvme0 with a crypto erase to namespace 1:
See nvme-format(1) for more information and important warnings regarding device/namespace selection.
Sanitize command
The Sanitize command was created to be «functionally equivalent to the command of the same name in SATA and SAS implementations»[4]. From the aforementionned article[5]:
«According to the NVMe 1.4 specification, “a sanitize operation alters all user data in the NVM subsystem such that recovery of any previous user data from any cache, the non-volatile media, or any Controller Memory Buffer is not possible.” The big difference between Sanitize and Format is that sanitize ensures caches are deleted, and the process starts again after an unexpected power loss. Sanitize also supports a pattern overwrite for a secure erase operation, which is terrible for NAND endurance but can be used with other types of storage and memory classes, or for more certainty that user data cannot be recovered.»
Usage and possible values for the -a/—sanact options are[6]:
See nvme-sanitize(1) for more informations.
You can get an estimation of the time the various methods would take on your drive (if supported):
If instead you get a result such as:
Then be sure that the operation will take a long time to complete. For reference, a Block Erase took around 2-3 hours to complete on the Intel 660p 512GB reporting those results.
To start a Crypto Erase sanitize operation:
For a Block Erase:
You can follow the progress with the Sanitize Log:
Example output for a drive with a Crypto Erase in progress:
When the command has completed successfully:
Troubleshooting
UEFI boot entries get removed after wiping a drive
Some UEFI implementations remove boot entries referencing nonexistent files upon system startup. If you plan to restore the system from a backup after memory cell clearing, make sure to also restore the boot entry using efibootmgr or by reinstalling the boot loader.
Источник
Securely wipe disk
Wiping a disk is done by writing new data over every single bit.
Contents
Common use cases
Wipe all data left on the device
The most common usecase for completely and irrevocably wiping a device is when the device is going to be given away or sold. There may be (unencrypted) data left on the device and you want to protect against simple forensic investigation that is mere child’s play with for example File recovery software.
If you want to quickly wipe everything from the disk, /dev/zero or simple patterns allow maximum performance while adequate randomness can be advantageous in some cases that should be covered up in #Data remanence.
Every overwritten bit means to provide a level of data erasure not allowing recovery with normal system functions (like standard ATA/SCSI commands) and hardware interfaces. Any file recovery software mentioned above then would need to be specialized on proprietary storage-hardware features.
In case of a HDD, data recreation will not be possible without at least undocumented drive commands or tinkering with the device’s controller or firmware to make them read out for example reallocated sectors (bad blocks that S.M.A.R.T. retired from use).
There are different wiping issues with different physical storage technologies. Most notably, all Flash memory based devices and older magnetic storage (old HDDs, floppy disks, tape).
Preparations for block device encryption
To prepare a drive for block device encryption inside the wiped area afterwards, it is recommended to use #Random data generated by a cryptographically strong random number generator (referred to as RNG in this article from now on).
Data remanence
See also Wikipedia:Data remanence. The representation of data may remain even after attempts have been made to remove or erase the data.
Operating system, programs and filesystem
The operating system, executed programs or journaling file systems may copy your unencrypted data throughout the block device. When writing to plain disks, this should only be relevant in conjunction with one of the above.
If the data can be exactly located on the disk and was never copied anywhere else, wiping with random data can be thoroughgoing and impressively quick as long there is enough entropy in the pool.
A good example is cryptsetup using /dev/urandom for wiping the LUKS keyslots.
Hardware-specific issues
Flash memory
Write amplification and other characteristics make Flash memory, including SSDs, a stubborn target for reliable wiping. As there is a lot of transparent abstraction in between data as seen by a device’s controller chip and the operating system, sight data is never overwritten in place and wiping particular blocks or files is not reliable.
Other «features» like transparent compression (all SandForce SSDs) can compress your zeros or repetitive patterns, so if wiping is fast beyond belief this might be the cause.
Disassembling Flash memory devices, unsoldering the chips and analyzing data content without the controller in between is feasible without difficulty using simple hardware. Data recovery companies do it for cheap money.
For more information see:
Marked Bad Sectors
If a hard drive marks a sector as bad, it cordons it off, and the section becomes impossible to write to via software. Thus a full overwrite would not reach it. However because of block sizes, these sections would only amount to a few theoretically recoverable KiB.
Residual magnetism
A single, full overwrite with zeros or random data does not lead to any recoverable data on a modern high-density storage device. Note that repeating the operation should not be necessary nowadays. [1] Indications otherwise refer to single residual bits; reconstruction of byte patterns is generally not feasible.[2] See also [3], [4] and [5].
Select a target
Use fdisk to locate all read/write devices the user has read access to.
Check the output for lines that start with devices such as /dev/sd»X» .
This is an example for a HDD formatted to boot a linux system:
Or another example with the Arch Linux image written to a 4GB USB thumb drive:
If you are worried about unintentional damage of important data on the primary computer, consider using an isolated environment such as a virtual environment (VirtualBox, VMWare, QEMU, etc. ) with direct connected disk drives to it or a single computer only with a storage disk(s) that need to be wiped booted from a Live Media (USB, CD, PXE, etc. ) or use a script to prevent wiping mounted partitions by typo.
Select a data source
To wipe sensitive data, one can use any data pattern matching the needs.
Zeros
Overwriting with /dev/zero or simple patterns is considered secure in most situations. With today’s HDDs, it is deemed appropriate and fast for disk wiping.
However, a drive that is abnormally fast in writing patterns or zeroing could be doing transparent compression. It is obviously presumable not all blocks get wiped this way. Some #Flash memory devices do «feature» that.
To setup block device encryption afterwards, one should wipe the area with random data (see next section) to avoid weakening the encryption.
Random data
True random data source using /dev/random is impractical for wiping large capacities as it will take too long to wait for the entropy generation. /dev/urandom can be used as a reasonable source of pseudorandom data. For differences between random and pseudorandom data as source, please see Random number generation.
Another alternative for pseudorandom data generation is to use an encrypted datastream. For example, if one wants to prepare a device for block encryption and will use AES for the encrypted partition, it is appropriate to wipe it with a similar cipher prior to creating the filesystem to make the empty space not distinguishable from the used space.
Select a block size
If you have an Advanced Format hard drive it is recommended that you specify a block size larger than the default 512 bytes. To speed up the overwriting process choose a block size matching your drive’s physical geometry by appending the block size option to the dd command (i.e. bs=4096 for 4 KiB).
fdisk prints physical and logical sector size for every disk. Alternatively sysfs does expose information:
Calculate blocks to wipe manually
A block storage devices contains sectors and a size of a single sector that can be used to calculate the whole size of device in bytes. You can do it by multiplying sectors with size of the sector.
As an example we use the parameters with the dd command to wipe a partition:
Here, to illustrate with a practical example, we will show the output of the fdisk command on the partition /dev/sdX :
- The first line of the fdisk output shows the disk size in bytes and in logical sectors.
- The size in bytes of the storage device or of the partition can also be obtained with the command blockdev —getsize64 /dev/sdXY .
- The Units line of the fdisk output shows the size of single logical sector; the logical sector size can also be derived from the number of bytes divided by the number of logical sectors, here use: echo $((2000398934016 / 3907029168)) .
- To know the physical sector size in bytes (that will make it work faster), we can use the next line.
- To get the disk size in physical sectors, one can divide the disk size in bytes by the size of a single physical sector, here echo $((2000398934016 / 4096)) ,
To wipe partition /dev/sdX1 , the example parameters with logical sectors would be used like follows.
- By using the starting address of the partition on the device using the seek= parameter:
with Start=2048 , End=3839711231 and BytesInSector=512 .
- Or by using the partitions size in logical sectors:
Or, to wipe the whole disk by using physical sectors:
with AllDiskPhysicalSectors=488378646 and PhysicalSectorSizeBytes=4096 .
Overwrite the target
You can choose from several utilities to overwrite a drive. If you only want to wipe a single file, Securely wipe disk/Tips and tricks#Wipe a single file has considerations in addition to the utilities mentioned below.
By redirecting output
The redirected output can be used to create files, rewrite free space on the partition, and to wipe the whole device or a single partition on it.
The following examples show how to rewrite the partition or a block device by redirecting stdout from other utilities:
The file copy command cp can also be used to rewrite the device, because it ignores the type of the destination:
To show speed and time you can use pv :
Zero-fill the disk by writing a zero byte to every addressable location on the disk using the /dev/zero stream.
The process is finished when dd reports No space left on device and returns control back:
To speed up wiping a large drive, see also:
A program specialized on wiping files. It is available as part of the wipe package. To make a quick wipe of a destination, you can use something like:
See also wipe(1) . The tool was last updated in 2009. Its SourceForge page suggests that it is currently unmaintained.
shred
shred (from the coreutils package) is a Unix command that can be used to securely delete individual files or full devices so that they can be recovered only with great difficulty with specialised hardware, if at all. By default shred uses three passes, writing pseudo-random data to the device during each pass. This can be reduced or increased.
The following command invokes shred with its default settings and displays the progress.
Shred can also be used on a single partition, e.g. to wipe the first partition use shred -v /dev/sdX1 .
Alternatively, shred can be instructed to do only one pass, with entropy from e.g. /dev/urandom .
Badblocks
The tool badblocks from e2fsprogs is able to perform destructive read-write test, effectively wiping the device. By default, it performs four passes and can take very long.
hdparm
hdparm supports ATA Secure Erase, which is functionally equivalent to zero-filling a disk. It is however handled by the hard drive firmware itself, and includes «hidden data areas». As such, it can be seen as a modern-day «low-level format» command. SSD drives reportedly achieve factory performance after issuing this command, but may not be sufficiently wiped (see #Flash memory).
Some drives support Enhanced Secure Erase, which uses distinct patterns defined by the manufacturer. If the output of hdparm -I for the device indicates a manifold time advantage for the Enhanced erasure, the device probably has a hardware encryption feature and the wipe will be performed to the encryption keys only.
For detailed instructions on using ATA Secure Erase, see Solid state drive/Memory cell clearing and the Linux ATA wiki.
Источник