1 2 3 4 S E C U R E D E L E T E 5 6 7 (c) 1997-2003 by van Hauser / THC <vh@thc.org> 8 9 http://www.thc.org 10 11 12 13 14 15 " Does the average person really need this kind of security? 16 I say yes. [...] He may be living in a country that does not 17 respect the rights of privacy of it's citizens. He may be 18 doing something that he feels shouldn't be illegal, but is. 19 Whatever his reasons, his data and communications are 20 personal, private, and nobody's business but his own. " 21 22 Bruce Schneier in the Preface of his book "Applied Cryptography" 23 24 25 26 " A Puritan is someone who is deathly afraid that someone, 27 somewhere, is having fun. " 28 29 Unknown 30 31 32 33 34 35 1. INTRODUCTION 36 2. HOW THESE PROGRAMS WORK 37 3. COMMANDLINE OPTIONS 38 4. LIMITATIONS 39 5. COMPARISON 40 6. LAST WORDS 41 42 43 44 45 46 47 1. INTRODUCTION 48 49 Years ago, people using the old msdos, simply deleted a file by 50 doing "del filename" and thought the the erase was forever. 51 Then Norton's undelete was released and everyone could get 52 back the files most of the time. After that people who wanted to 53 keep people of their deleted files erased them by overwriting the 54 file with random or 0x00 bytes and felt secure. 55 56 In 1996 Peter Gutmann published a paper called "Secure Deletion of Data 57 from Magnetic and Solid-State Memory" at the 6th Usenix Security 58 Symposium, where he pointed out that the data could even be recovered 59 if you overwrote them triple times and more - using cheap equipment 60 for about 1000-2500$. 61 The three utilities presented here try to cover this new area of secure 62 deletion and prevent file recovery. 63 This release includes the full paper of Peter Gutmann from the 64 6th Usenix Security Proceeding (usenix6-gutmann.doc). 65 66 The four utilities do the following : 67 68 srm does secure deletion of files. 69 sfill does a secure overwriting of the unused diskspace on the harddisk. 70 sswap does a secure overwriting and cleaning of the swap filesystem. 71 (note that sswap was only tested on linux so far. 72 you must unmount your swap first!) 73 smem does a secure overwriting of unused memory (RAM) 74 75 For Linux, there's a diff (rm.diff) patch for rm.c which puts the 76 overwriting feature into it. (You need the fileutil sources) 77 78 79 80 81 2. HOW THESE PROGRAMS WORK 82 83 The deletion process is as follows: 84 85 1. The overwriting procedure (in the secure mode) does a 38 times 86 overwriting. After each pass, the disk cache is flushed. 87 2. truncating the file, so that an attacker don't know which 88 diskblocks belonged to the file. 89 3. renaming of the file, so that an attacker can't draw any conclusion 90 from the filename on the contents of the deleted file. 91 4. finally deleting the file (unlink). 92 93 Note that with v2.0 all secure_delete utilities work in secure mode 94 (38 special passes). To lower the security and make it faster, you 95 may add -l (onf 0xff pass, one random pass) or -ll (one random pass) to 96 the parameters. 97 98 The secure overwrite mode works that way: 99 100 1x overwrite with 0xff 101 5x random passes 102 27x overwriting with special values to make the recovery from MFM and 103 RLL encoded harddisks hard/impossible - see Gutmann's paper on that 104 which is also included. 105 5x random passes 106 107 108 109 Some statistics : 110 111 in 1 second you can approx. overwrite 1 to 2 MB of data, depending 112 on your harddrive performance. 113 114 In totally insecure mode, a 100 MB file/free-disk-space takes 115 approx. 15 seconds, and in the totally secure mode approx. 60 minutes. 116 117 118 119 120 121 3. COMMANDLINE OPTIONS 122 123 Here are the commandline options: 124 125 srm [-d] [-f] [-l] [-l] [-v] [-z] file [file] [another file] [etc.] 126 sfill [-i] [-I] [-f] [-l] [-l] [-v] [-z] target-directory 127 sswap [-f] [-l] [-l] [-v] [-z] /dev/of_swap_filesystem 128 smem [-f] [-l] [-l] [-v] 129 130 The -s options are depricated now, and will be ignored. 131 132 -d don't delete the dot special files "." and ".." on the 133 commandline (only srm) 134 -i wipe only free inode space, not free disk space on the filesystem 135 (only sfill) 136 -I wipe only free disk space, not free inode space on the filesystem 137 (only sfill) 138 -f fast writes without O_SYNC and sync() between writes. Much faster 139 but less secure. 140 -l lessens the security. Only one random plus one pass with 0xff are 141 written. 142 -l a seconds time as parameter switches into the insecurest mode, 143 it overwrites the file only once with 0xff. 144 -v turn verbose mode on. 145 -z last wipe mode writes zeros instead of random data 146 file file to delete. Wildcards are of course allowed. 147 For unix: you need write permissions. For msdos: It may be hidden, 148 system, readonly etc. we don't care. 149 target-directory target is a directory in the filesystem to write to. 150 swap_filesystem your swap filesystem. Unmount it first!! 151 only tested on linux 152 153 Options may be applied like "-lfv", "-l -f -v" or a mix. 154 155 Note: If you use a gnu-compactible linux, you can use the patch rm.diff 156 included in the package to put the features from srm into your normal 157 rm. Just enter your fileutils-3.16 directory, type "patch < rm.diff" 158 and then "make". You need at least one -s switch to activate 159 (1 overwrite). Note that -sss is needed for full security. 160 161 162 163 164 4. LIMITATIONS 165 166 This section discusses limitations of the programs presented and general 167 problems and threats of secure data deletion - and how to handle them. 168 As you can see from the sourcecode, these are very small and generic 169 programs. That means that they aren't perfect and doesn't cover any 170 aspect of secure data deletion. Please read this section carefully 171 to learn against which problems it does NOT help. 172 173 174 - Random Number Generation 175 Since v2.0, secure_deletion uses the /dev/urandom as a random 176 source if available. This should fix this problem. However, 177 for completeness, read on: 178 The numbers which WERE generated by the programs were far away 179 being "real" random. Standard random number generators are 180 used and they are easy to predict. 181 This is a major risk if you are using them for online crypting 182 purpose, for the purpose of overwriting it is nearly enough. 183 However, I added two extra random overwrites to be sure. 184 A solution for paranoid people : change the random number generator 185 in the programs to something you trust. 186 Here's an extract from an answer Peter Gutmann wrote me as 187 I asked him about that problem : 188 189 > 1st to be compactible with all platforms i didn t use a crypt-random 190 > library, I use a simple (256*rand()/(RAND_MAX+1.0)) seeded 1st time with 191 > the pid. For every byte to overwrite the file I call that function. 192 > I know that this random stuff is not "secure" for online crypting, 193 > but is it enough for deletion? 194 > I added 2 more random overwrite modes in the source to minimize that risk. 195 > What do you think? 196 A strong RNG isn't that essential, as long as you're not writing a constant 197 pattern. I use RC4 in SFS because it's faster than most RNG's provided in 198 compiler libraries. 199 200[/dev/urandom is used if available. This is a very good RNG] 201 202 203 - Disk Caching 204 Note that this is only important for FILE DELETION (srm) for free 205 diskspace wiping the data which will be overwritten is large 206 enough. 207 Imagine that you overwrite a file for 50 times, you feel secure, 208 but only one - the last overwrite - is really made. 209 This can be the case if you use smart software caches, hardware 210 cache-controllers - or the cachebuffers which are present on 211 all (E)IDE and SCSI harddisks. 212 This programs uses fsync() - it depends on your unix and hardware 213 if this is enough. 214 If you use an hardware cache-controller you must remove it. 215 For the cachebuffers of the harddisks you must overwrite a file 216 which is greater in size than the diskbuffer. You can either 217 add data to the file until it reachs that size or you define 218 the BLOCKSIZE definition to a size big enough 219 Here again is en extract of an answer Peter Gutmann wrote in 220 regard of this threat : 221 222 > 2nd is the chaching problem. For msdos i flush smartdrive after every 223 > write of a pattern, on unix I use sync. That makes it easy to compile 224 > on all platforms, yes, but it won't flush the harddisks internal caches. 225 > how big must be the file to force the internal cache to write to disk? 226 > at the moment I do only full 16 kb writes to a) overwrite the whole block 227 > and also to reach the limit of the internal cache. 228 I don't think there's an easy answer to this. Most cheap commercial drives 229 have tiny caches (typically 96KB or 128KB with 16KB (EIDE) or 32KB (SCSI) 230 used by the firmware), but larger SCSI drives designed for servers and/or 231 controllers on servers can have considerable caches. I'd say 16KB or 32KB 232 would be reasonably safe. 233 234[secure_deletion uses 32kb, and since 2.2 enlarges this if the blocksize 235 of the filesystem is larger] 236 237 238 - Temporary files and disks 239 Windows 3.x, Win95 and WinNT support virtuell memory which means 240 that if more memory is needed, some space of the harddisk will 241 be used. Unix does the same, using the swap space partition (and 242 additionally swap files can be created). Some other programs do 243 the same, especially databases. 244 Other programs you use, f.e. a word processor etc. writes recovery 245 and/or backup files. Those must be secure deleted too - which is 246 a major problem if the programs delete them after the program exit. 247 Solution, regardless of the operating system of your choice : 248 - All disk partitions must be set write protected in some way 249 before you want to do something which shouldn't be saved 250 anywhere. MsDos tools are available, on unix they can be 251 mounted readonly, Win95/WinNT : don't know if thats possible. 252 - Install a ramdisk from which you start all applications 253 (for Windows set the working directory on the ramdisk) 254 and ensure that all temporary stuff, etc. points to that disk. 255 If you can't afford ram, repartition your disks so that you 256 get an 20+ MB diskspace either ensure a complete wiping of 257 that partition after every session (use "sfill -v") 258 or use a crypted filesystem (see next step). 259 For unix you should set a ramdrive for the swap partition, 260 and use an additional ramdisk or crypted partition for 261 /tmp and ensure that /usr/tmp and /var/tmp point to it. 262 If you can't afford buying ram so you don't need swap, you 263 can use the secure swap cleaner, included in this package. 264 With v1.8 of secure_deletion, you can also use sswap to 265 clean your swap space after you unmounted it. 266 - If you really need the data you produced or analysed, 267 then create a crypted filesystem on a disk partition. 268 For unix you can use CFS (newest version v1.4.x), for MsDos 269 and Windows 3.x there are SFS v1.7 and SecureDrive v1.4a 270 available. I don't know any for Win95 and WinNT - but these 271 have special problems anyway so see the next topic : 272 273 274 - Windows 95 and WinNT 275 As you can see, the programs were NOT programmed for any Windows 276 environment and this has got the following reasons : 277 - I don't know enough about these systems to make the programs 278 secure, also I know that they've got an internal function to 279 flush their caches without any problems. 280 - Special problems like in the NTFS, the WinNT Filesystem, which 281 holds too much information on the files, so that real secure 282 data deletion is tricky. 283 - Windows machines swap very often - and where and how to 284 control that - I don't know, in my opinion it would be too 285 difficult to make it a secure system (against data recovery). 286 So why writing a secure deletion programs when fragments of 287 the files are everywhere on the harddisk? 288 289 - Networks 290 Before we'll discuss further matters of that topic let me put it 291 short and straight : YOU CAN'T ENSURE SECURE DATA DELETION WHEN 292 WORKING OVER A NETWORK YOU DO NOT *COMPLETLY* CONTROL ! 293 Because : 294 - The network servers and maybe even your local computer 295 caches the data to be written. See "Disk Caching" above 296 why this is a problem - and this one can't be solved. 297 - How long are your files present on the server? Long enough 298 that they are written on a backup? 299 - A hacker or law enforcement/spies could have trojanized the 300 server in a way that your files won't be overwritten and 301 removed but those files are written to a special place waiting 302 to be retrieved by them. Nearly all known network operating 303 systems and also some firewalls can be penetrated from remote, 304 no kidding. So don't think that you are not vulnerable. 305 Another possiblity is that the memory of the server is 306 surveilled and all reading/writing processes own by you or 307 anyone copied. 308 - Even if everything is ensured there might be still problems 309 on high-end systems, which use f.e. Raid5 or similar redunant 310 harddisk systems which prevent data loss by keeping copies 311 and checksums, and you must find a way to trash those 312 information too. 313 The solution is easy: don't put any private and important stuff 314 you don't want anybody to see on the network - crypt it before 315 transfering it on a server. 316 317 318 - Paranoia 319 Finally two points which are for very paranoid guys. 320 Imagine a temporary file was written by a program you used for 321 your important files and they were deleted. You run "sfill" 322 f.e. to clean all unused diskspace to trash all information. 323 But another file, f.e. a config file, was written when exiting the 324 program and parts of the temporary file are now owned and 325 overwritten by the config file. sfill or any similar program won't 326 trash that filearea because it's used by a file. And the data on 327 this area can be recovered with cheap hardware. 328 Solution : see above, "temporary files and disks" 329 If you really care about your files that they can't be recovered 330 you should also ensure that the "others" can't get the data by 331 other means, f.e. by either hacking your computer or analyzing 332 the electromagnetic/sound/wave emissions from the monitor, printer, 333 fax and cables. 334 Solution : pull out your network/modem cable when working and 335 try to shield your computer (search the inet for more info on that) 336 337 - But there is help 338 Watch out. Soon there will be a new release from THC which 339 shows how to make a Linux machine anonymous. When followed, 340 nothing will be recoverable for someone having your harddisks. 341 -> This was released looong ago now :-) Go the the THC website, 342 enter the articles/papers section and look for "anonymizing unix 343 systems". 344 345 346 5. COMPARISON 347 348Program secure_delete (srm) wipe wipe 349Version 2.1 0.2 0.56-2a 350Programmer van Hauser / THC Berke Durak Tom Vier 351Email vh@thc.org bedrettin@chez.com thomassr@erols.com 352 353Standard Passes 38 35 35 354More passes via cmd no no yes 355Fewer passes via cmd yes yes yes 356Good RNG yes yes yes 357Blocksize (larger is better) 32k 1k 0 358Truncates file yes no yes 359Rename file/directory yes no no 360 361recursive mode yes yes yes 362secure recursive (link races) yes no no 363verbose mode yes yes yes 364 365additional wipe tools yes no no 366 367Time: 1 File, 1MB 25s 40s 26s 368Time: 10 Files, 10kb 12s 6s 4s 369(Parameters for tests) <none> -f -fTe 370 (needed for the 371 fastest mode) 372 [otherwise it needs x12 time] 373 374Why is secure_delete that fast with big files but slower with many small 375ones? It's fast, because it uses a big buffer for writing. It's slow because 376the additional security features (rename, truncating, more passes, better 377RNG [against wipe-0.2] and by far the biggest blocksize). 378It's also the only one which comes with a free diskspace wiper and a special 379cleaner for swap space and memory. 380I think the choice is easy ,-) I hope the other programmers will make their 381programs better too, the more good & secure & fast programs, the better. 382Competition helps us all. 383 384 385 6. LAST WORDS 386 387 I hope these little utilities help those who really need them. 388 For any bugs, ideas or ongoing discussion feel free to email me at 389 vh@thc.org using the public pgp key below. 390 391 http://www.thc.org 392 393 Have fun ... 394 van Hauser / [THC] - The Hacker's Choice 395 396 397Type Bits/KeyID Date User ID 398pub 2048/CDD6A571 1998/04/27 van Hauser / THC <vh@reptile.rug.ac.be> 399 400-----BEGIN PGP PUBLIC KEY BLOCK----- 401Version: 2.6.3i 402 403mQENAzVE0A4AAAEIAOzKPhKBDFDyeTvMKQ1xx6781tEdIYgrkrsUEL6VoJ8H8CIU 404SeXDuCVu3JlMKITD6nPMFJ/DT0iKHgnHUZGdCQEk/b1YHUYOcig1DPGsg3WeTX7L 405XL1M4DwqDvPz5QUQ+U+VHuNOUzgxfcjhHsjJj2qorVZ/T5x4k3U960CMJ11eOVNC 406meD/+c6a2FfLZJG0sJ/kIZ9HUkY/dvXDInOJaalQc1mYjkvfcPsSzas4ddiXiDyc 407QcKX+HAXIdmT7bjq5+JS6yspnBvIZC55tB7ci2axTjwpkdzJBZIkCoBlWsDXNwyq 408s70Lo3H9dcaNt4ubz5OMVIvJHFMCEtIGS83WpXEABRG0J3ZhbiBIYXVzZXIgLyBU 409SEMgPHZoQHJlcHRpbGUucnVnLmFjLmJlPokAlQMFEDVE0D7Kb9wCOxiMfQEBvpAD 410/3UCDgJs1CNg/zpLhRuUBlYsZ1kimb9cbB/ufL1I4lYM5WMyw+YfGN0p02oY4pVn 411CQN6ca5OsqeXHWfn7LxBT3lXEPCckd+vb9LPPCzuDPS/zYnOkUXgUQdPo69B04dl 412C9C1YXcZjplYso2q3NYnuc0lu7WVD0qT52snNUDkd19ciQEVAwUQNUTQDhLSBkvN 4131qVxAQGRTwgA05OmurXHVByFcvDaBRMhX6pKbTiVKh8HdJa8IdvuqHOcYFZ2L+xZ 414PAQy2WCqeakvss9Xn9I28/PQZ+6TmqWUmG0qgxe5MwkaXWxszKwRsQ8hH+bcppsZ 4152/Q3BxSfPege4PPwFWsajnymsnmhdVvvrt69grzJDm+iMK0WR33+RvtgjUj+i22X 416lpt5hLHufDatQzukMu4R84M1tbGnUCNF0wICrU4U503yCA4DT/1eMoDXI0BQXmM/ 417Ygk9bO2Icy+lw1WPodrWmg4TJhdIgxuYlNLIu6TyqDYxjA/c525cBbdqwoE+YvUI 418o7CN/bJN0bKg1Y/BMTHEK3mpRLLWxVMRYw== 419=MdzX 420-----END PGP PUBLIC KEY BLOCK----- 421