Difference between revisions of "Securely wipe disk"
m (→Preparations for block device encryption: typo) |
Kynikos.bot (talk | contribs) (update link(s) (avoid redirect)) |
||
(28 intermediate revisions by 8 users not shown) | |||
Line 1: | Line 1: | ||
[[Category:Security]] | [[Category:Security]] | ||
[[Category:File systems]] | [[Category:File systems]] | ||
− | {{ | + | {{Related articles start}} |
− | {{ | + | {{Related|File Recovery}} |
− | + | {{Related|Benchmarking disk wipes}} | |
− | + | {{Related|Frandom}} | |
− | {{ | + | {{Related|Disk encryption#Preparing the disk}} |
− | {{ | + | {{Related|dm-crypt}} |
− | {{ | + | {{Related articles end}} |
− | {{ | ||
− | {{ | ||
− | |||
Wiping a disk is done by writing new data over every single bit. | Wiping a disk is done by writing new data over every single bit. | ||
Line 28: | Line 25: | ||
=== Preparations for block device encryption === | === Preparations for block device encryption === | ||
− | If you want to prepare your drive to securely set up [[Disk | + | If you want to prepare your drive to securely set up [[Disk encryption#Block device encryption]] inside the wiped area afterwards you really should use [[#Random data]] generated by a trusted cryptographically strong random number generator (referred to as RNG in this article from now on). |
{{Wikipedia|Random number generation}} | {{Wikipedia|Random number generation}} | ||
Line 40: | Line 37: | ||
If you want to setup block device encryption afterwards you should always wipe at least with Pseudorandom data. | If you want to setup block device encryption afterwards you should always wipe at least with Pseudorandom data. | ||
− | For | + | For data that is not truly random your disk's writing speed should be the only limiting factor. If you need random data, the required system performance to generate it may extremely depend on what you choose as source of entropy. |
{{Note|Everything regarding [[Benchmarking disk wipes]] should get merged there.}} | {{Note|Everything regarding [[Benchmarking disk wipes]] should get merged there.}} | ||
Line 50: | Line 47: | ||
==== Pattern write test ==== | ==== Pattern write test ==== | ||
− | [[#Badblocks]] can write simple patterns to every block of a device and then read and check them searching for damaged areas | + | [[#Badblocks]] can write simple patterns to every block of a device and then read and check them searching for damaged areas (just like memtest86* does with memory). |
As the pattern is written to every accesible block this effectively wipes the device. | As the pattern is written to every accesible block this effectively wipes the device. | ||
=== Random data === | === Random data === | ||
− | |||
− | + | For differences between random and pseudorandom data as source, please see [[Random number generation]]. | |
− | |||
− | + | {{Note|Data that is hard to compress (random data) will get written slower, if the drive logic mentioned in the [[#Unrandom data]] warning tries compressing it. This should not lead to [[#Data remanence]] though. As maximum write-speed is not the performance-bottleneck it can get completely neglected while wiping disks with random data.}} | |
− | |||
− | |||
− | |||
== Select a program == | == Select a program == | ||
{{ic|/dev/<drive>}} is the drive to be encrypted. | {{ic|/dev/<drive>}} is the drive to be encrypted. | ||
− | === | + | === dd === |
− | + | See [[Core utilities#dd]]. | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | === shred === | |
− | + | See [[Core utilities#shred]]. | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
=== Badblocks === | === Badblocks === | ||
Line 123: | Line 72: | ||
== Select a target == | == Select a target == | ||
− | {{Note|Fdisk will not work on [[GUID Partition Table|GPT]] formatted devices. Use {{Pkg| | + | {{Note|Fdisk will not work on [[GUID Partition Table|GPT]] formatted devices. Use gdisk ({{Pkg|gptfdisk}}) instead.}} |
Use fdisk to locate all read/write devices the user has read acess to. | Use fdisk to locate all read/write devices the user has read acess to. | ||
Line 165: | Line 114: | ||
{{warning|There is no confirmation regarding the sanity of this command so '''repeatedly check''' that the correct drive or partition has been targeted. Make certain that the {{ic|<nowiki>of=...</nowiki>}} option points to the target drive and not to a system disk.}} | {{warning|There is no confirmation regarding the sanity of this command so '''repeatedly check''' that the correct drive or partition has been targeted. Make certain that the {{ic|<nowiki>of=...</nowiki>}} option points to the target drive and not to a system disk.}} | ||
− | Zero-fill the disk by writing a zero byte to every addressable location on the disk using the [[Wikipedia:/dev/zero|/dev/zero]] stream. | + | Zero-fill the disk by writing a zero byte to every addressable location on the disk using the [[Wikipedia:/dev/zero|/dev/zero]] stream. {{ic|iflag}} and {{ic|oflag}} as below will try to disable buffering, which is senseless for a constant stream. |
− | # dd if=/dev/zero of=/dev/sdX bs=4096 | + | # dd if=/dev/zero of=/dev/sdX iflag=nocache oflag=direct bs=4096 |
− | + | Or the [[Wikipedia:/dev/random|/dev/urandom]] stream: | |
# dd if=/dev/urandom of=/dev/sdX bs=4096 | # dd if=/dev/urandom of=/dev/sdX bs=4096 | ||
Line 189: | Line 138: | ||
If the data can get 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. | If the data can get 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 [[Dm- | + | A good example is cryptsetup using /dev/urandom for [[Dm-crypt/Device_Encryption#Keyslot_management|wiping the LUKS keyslots]]. |
=== Hardware specific issues === | === Hardware specific issues === | ||
Line 213: | Line 162: | ||
{{Note|This is not specific to any hardware obviously.}} | {{Note|This is not specific to any hardware obviously.}} | ||
The operating system, executed programs or [[Wikipedia:Journaling file system|journaling file system]]s 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. | The operating system, executed programs or [[Wikipedia:Journaling file system|journaling file system]]s 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. | ||
− | |||
− | |||
− | |||
− | |||
− |
Revision as of 00:47, 5 April 2014
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 will be when the device it going to be given away or also maybe 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 fiddling about 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 technologys, most notably all Flash memory based devices and older magnetic storage (old HDD's, floppy disks, tape).
Preparations for block device encryption
If you want to prepare your drive to securely set up Disk encryption#Block device encryption inside the wiped area afterwards you really should use #Random data generated by a trusted cryptographically strong random number generator (referred to as RNG in this article from now on).
Select a data source for overwriting
As just said If you want to wipe sensitive data you can use anything matching your needs.
If you want to setup block device encryption afterwards you should always wipe at least with Pseudorandom data.
For data that is not truly random your disk's writing speed should be the only limiting factor. If you need random data, the required system performance to generate it may extremely depend on what you choose as source of entropy.
Unrandom data
Overwriting with /dev/zero
or simple patterns is considered secure in most resources. In the case of current HDD's it should be sufficient for fast disk wipes.
Pattern write test
#Badblocks can write simple patterns to every block of a device and then read and check them searching for damaged areas (just like memtest86* does with memory).
As the pattern is written to every accesible block this effectively wipes the device.
Random data
For differences between random and pseudorandom data as source, please see Random number generation.
Select a program
/dev/<drive>
is the drive to be encrypted.
dd
See Core utilities#dd.
shred
See Core utilities#shred.
Badblocks
For letting badblocks perform a disk wipe a destructive read-write test has to be done.
# badblocks -c 10240 -wsv /dev/<drive>
Select a target
Use fdisk to locate all read/write devices the user has read acess to.
Check the output for lines that start with devices such as /dev/sdX
.
This is an example for a HDD formatted to boot a linux system:
# fdisk -l
Disk /dev/sda: 250.1 GB, 250059350016 bytes, 488397168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00ff784a Device Boot Start End Blocks Id System /dev/sda1 * 2048 206847 102400 83 Linux /dev/sda2 206848 488397167 244095160 83 Linux
Or the Arch Install Medium written to a 4GB USB thumb drive:
# fdisk -l
Disk /dev/sdb: 4075 MB, 4075290624 bytes, 7959552 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x526e236e Device Boot Start End Blocks Id System /dev/sdb1 * 0 802815 401408 17 Hidden HPFS/NTFS
Block size
Template:Wikipedia
If you have a 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 4KB).
Fdisk prints physical and logical sector size for every disk.
Alternatively sysfs does expose information:
/sys/block/sdX/queue/physical_block_size /sys/block/sdX/queue/logical_block_size /sys/block/sdX/alignment_offset
Overwrite the disk
of=...
option points to the target drive and not to a system disk.Zero-fill the disk by writing a zero byte to every addressable location on the disk using the /dev/zero stream. iflag
and oflag
as below will try to disable buffering, which is senseless for a constant stream.
# dd if=/dev/zero of=/dev/sdX iflag=nocache oflag=direct bs=4096
Or the /dev/urandom stream:
# dd if=/dev/urandom of=/dev/sdX bs=4096
The process is finished when dd reports, No space left on device
:
dd: writing to ‘/dev/sdb’: No space left on device 7959553+0 records in 7959552+0 records out 4075290624 bytes (4.1 GB) copied, 1247.7 s, 3.3 MB/s
Data remanence
Template:WikipediaThe residual representation of data may remain even after attempts have been made to remove or erase the data.
Residual data may get wiped by writing (random) data to the disk with a single or even more than one iteration. However, more than one iteration may not significantly decrease the possibility to reconstruct the data of hard disk drives. For more information see Secure deletion: a single overwrite will do it - The H Security.
Random data
If the data can get 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
Wikipedia:Write amplification and other characteristics make Flash memory 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 SSD's) can compress your /dev/zero or pattern stream so if wiping is fast beyond belief this might be the case.
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 companys do it for cheap money.
For more information see: Reliably Erasing Data From Flash-Based Solid State Drives.
Residual magnetism
Wiped hard disk drives and other magnetic storage can get disassembled in a cleanroom and then analyzed with equipment like a magnetic force microscope. This may allow the overwritten data to be reconstructed by analyzing the measured residual magnetics.
This method of data recovery for current HDD's is largely theoretical and would require substantial financial resources. Nevertheless degaussing is still a practiced countermeasure.
Old magnetic storage
Securely wiping old magnetic storage (e.g. floppy disks, magnetic tape) is much harder due to much lower memory storage density. Many iterations with random data might be needed to wipe any sensitive data. To ensure that data has been completely erased most resources advise physical destruction.
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.