Part 1: How to securely sanitize hard disks (June 21st, 2004)

Part 2: How to securely encrypt hard disks (June 21st, 2004)

Part 3: Defeating your enemy by learning from him (June 21st, 2004)

Part 4: How to hide your data (in preparation)

Part 5: How to stay invisible (in preparation)








1. Sanitizing Hard Disks
    1.1 Introduction
    1.2 Physical Destruction
    1.3 Degaussing
    1.4 Overwriting
       1.4.1 Official overwriting standards
       1.4.2 Bruce Schneier's 7-pass method
       1.4.3 Peter Gutmann's 35-pass method
       1.4.4 Defeating Intelligence
       1.4.5 Open Source matters
       1.4.6 About hard disk densities
    1.5 Conclusion

1. Sanitizing Hard Disks

    1.1 Introduction

Basically, there are 3 techniques for properly sanitizing hard disks:

i) Physical destruction
ii) Degaussing
iii) Overwriting the disk's data

While degaussing and overwriting considerably increase an attacker's effort, solely physical destruction provides 100% secure deletion of data from hard disks.

    1.2 Physical destruction

Smelting or pulverizing the platters of a hard drive seem to be the best ways to get rid of your data forever.
Just breaking the platters in a few pieces is probably not enough. Dean Devera (The Difficulty of Data Annihilation from Disk Drives: or Exnihilation Made Easy) remarks:

"It is exceedingly difficult, but not impossible if we're dealing with relatively few pieces. Once reassembled, high-powered magnetic microscopy could then be turned to the media surface. [...] But the possibility of platter reconstruction exists, however minute." [1]

If heat is used for physical destruction, one must take into account the Curie point, where the material looses its ferromagnetic properties. E.g. the Curie point for pure iron (Fe) is above 750 degrees Celsius. Consider that the drive's case gives some protection against temperature changes. The Curie point must be exceeded on the platters directly for quite a long time.

That physical destruction does have to be applied properly shows the following report from the Computer Crime Research Center:

"The detailed examination made it possible to restore most files that the criminal tried to damage through physical destruction of the computer hard disk. The technically correct investigation materials including expert examination results allowed proving guilty of Mr. F. and institute criminal proceedings against him." [Source]

    1.3 Degaussing

The coercivity used for proper degaussing depends on the drive and its materials. Generally, adequate magnetizing forces start with 0.8 Tesla. Unless working in a clinic, where magnetic resonance tomographs usually provide 1.5 or 2 Tesla (research facilities might have more sophisticated scanners up to 9 Tesla), the normal citizen is not equipped with means of creating these strong magnetic fields.

Nevertheless degaussing should be handled with care. Charles Preston (who attended the FBI National Academy and wrote the article "The Data Dilemma" Security Management, February 1995) once answered a question on Privacy Digest 4.06. Here's some short cutout:

"Degaussing (strong magnetic fields that destroy patterns on the media) with a very strong magnetic wand or strong degausser will make the data very expensive and difficult to recover.
A report from the Institute for Defense Analyses from several years ago stated that with enough processing power and time, data could be recovered almost regardless of the method used to erase it. The same report gave a rule of thumb about the necessary strength of magnetic fields used to erase data. If this holds true for newer media like high-density diskettes and DAT drives, it may be impossible to adequately erase this media, including hard drives, with current degaussers."

    1.4 Overwriting

Overwriting is, if properly applied, a thoroughly secure way of erasing data from hard disks.
Warning: There may occur errors in a hard drive. These bad sectors are then mapped and locked by the drive. I.e. no regular software will then be able to access these bad sectors and information in these will NOT be overwritten by what pattern ever. There do exist software tools that directly access the drive, but those are usually restricted to vendor staff.

       1.4.1 Official overwriting standards

There are several different overwriting patterns, proposed by various intelligence, the military and government organisations.
You should make yourself clear that no government in this world will ever publish a method that will protect you from its law enforcement and intelligence agencies at the date of publication. E.g. the DoD 5220.22-M pattern (3 passes) is not approved for sanitizing media that contains secret or top-secret information by the DoD itself!
Renowned security expert Peter Gutmann explains:

"The ... problem with official data destruction standards is that the information in them may be partially inaccurate in an attempt to fool opposing intelligence agencies (which is probably why a great many guidelines on sanitizing media are classified)." [2]

Furthermore, most of these official overwriting "standards" contain static elements, which means that a lot of passes consist of overwriting with Ones or Zeroes. Later on, we will learn that the best strategy is to apply a scrubbing with random data to the drive.


Not recommended patterns include:

-US NAVSO P-5239-26 (RLL) (3 passes)
-US NAVSO P-5239-26 (MFM) (3 passes)
-US DoD 5220.22-M (8-306./E) (3 passes)
-US DoD 5220.22-M (8-306./E,C and E) (7 passes)
-US AR 380-19 (3 passes)

-ACSI 33 605 (2 pass * n) ( Australia)
-BSI GSHB M2.167 (3 passes) (Germany)

Comment: The original NISPOM (National Industrial Security Program Operating Manual = DoD 5220.22 M) was first published in 1995. When you look at Chapter 8 section 306, you can see the "Clearing and Sanitization Matrix" which prescribes the well-known 3-pass pattern for hard drives. So far, so good. Since then NISPOM has been changed twice: in July 1997 and February 2001. After the 2001 change, the recommended 3-pass pattern vanished! The updated NISPOM now only contains a general description (8.301) of what Clearing(a) and Sanitization(b) mean. The same holds true for the Army Regulation 380-19. The version from August, 1st 1990 describes a 3-pass pattern for hard disks, whereas the updated version from February, 27th 1998 does not contain information on specific overwriting patterns any more.
This might indicate that the progress in hard disk technology with increasing densities causes considerable problems to those trying to recover deleted information. Maybe progress in computer forensics is much slower than required to fill the gap.

        1.4.2 Bruce Schneier's 7-pass method

Bruce Schneier in his book "Applied Cryptography" (1996):

"Most commercial programs that claim to implement the DoD standard overwrite three times: first with all ones, then with all zeros, and finally with a repeating one-zero pattern. Given my general level of paranoia, I recommend overwriting a deleted file seven times: the first time with all ones, the second time with all zeros, and five times with a cryptographically secure pseudo-random sequence." [3]

First, it must be criticized that Schneier does not explain why he recommends the described 7-pass pattern. "Given my general level of paranoia" is all we get to know.
Second, he himself admits:

"Recent developments at the National Institute of Standards and Technology with electron-tunnelling microscopes suggest even that might not be enough. Honestly, if your data is sufficiently valuable, assume that it is impossible to erase data completely off magnetic media. Burn or shred the media; it's cheaper to buy media new than to lose your secrets." [3]

        1.4.3 Peter Gutmann's 35-pass method

Here is Peter Gutmann's statement in the updated paper "Secure Deletion of Data from Magnetic and Solid-State Memory":

"Epilogue

In the time since this paper was published, some people have treated the 35-pass overwrite technique described in it more as a kind of voodoo incantation to banish evil spirits than the result of a technical analysis of drive encoding techniques. As a result, they advocate applying the voodoo to PRML and EPRML drives even though it will have no more effect than a simple scrubbing with random data. In fact performing the full 35-pass overwrite is pointless for any drive since it targets a blend of scenarios involving all types of (normally used) encoding technology, which covers everything back to 30+-year-old MFM methods (if you don't understand that statement, re-read the paper). If you're using a drive which uses encoding technology X, you only need to perform the passes specific to X, and you never need to perform all 35 passes. For any modern PRML/EPRML drive, a few passes of random scrubbing is the best you can do. As the paper says, "A good scrubbing with random data will do about as well as can be expected". This was true in 1996, and is still true now." [4]

I.e. overwriting with the Gutmann pattern makes only sense if you have a hard drive that uses MFM/RLL encoding. In general, MFM was used on most drives before IDE. The initial RLL encodings were used until the mid-1990s. All hard drives acquired after that time should be sanitized with random data.

        1.4.4 Defeating Intelligence

In December 2003, the German news magazine "Der Spiegel" (52/2003) published an article covering the issue of secure removal of data. Among others they quote Roy Pfitzner, an IT security consultant working for the Department of the Interior of the Federal State Brandenburg. Pfitzner wrote an so far unpublished paper in which he criticizes the BSI (Federal Office for IT security)-pattern (3-pass) and postulates maximum security for the average citizen that would even defy intelligence. Pfitzner explains that even after 20 times overwriting it is still possible to retrieve useful information. Secure deletion requires a "deep clearing process" which means that the data is overwritten with random data more than 30 times.
The interesting point is that Pfitzner, unlike others, is likely to have access to classified papers and resources that allow an assessment of what (German) law enforcement/intelligence agencies are able and of what not. If this holds true for foreign intelligence as well cannot be answered here.

His point of view is somewhat backed by David H. Schultz ("Beyond Fingerprints") who writes in a foot note:

"^xxii Until recently computer forensic and data recovery specialists agreed that data overwritten a total of nine times would ensure the data could not be recovered. With the development of Magnetic Force Microscopy, however, data can be recovered even after the hard disk has been overwritten a dozen or more times. The ability to detect each "layer" becomes progressively more difficult to recover the older it is. Michael Overly, Overly on Electronic Evidence in California, p. 2-25. (Eagan, MN: West Group, 1999)."

Though I personally would rely solely on physical destruction if absolute security is needed, Pfitzner's statement gives a good estimation of what is needed to reach a high security level with overwriting methods (given that no sensitive information is locked on bad sectors).

Overwriting with "random" data brings us to the next very important topic: The creation of strong random numbers.
Read more about the software generation of practically strong random numbers in Gutmann's Chapter about Random Number Generation.

            1.4.5 Open Source matters

I highly recommend not to use any, most often commercial, closed source Software. Use open source Software instead. Besides being available for free, the major advantage of open source tools is, that theoretically they can be checked by anyone for (intentionally implemented) flaws or security weaknesses which might leave your data not sufficiently erased. One example is Evidence Eliminator of which some think that it contains a booby-trap to silently disable itself.

To my knowledge there are only 3 active open source projects available:

-DBAN (boot and nuke program) by Darik Horn
-Wipe (Linux) by Tom Vier
-Eraser (WinNT/2000/XP, Win9x) by Sami Tolvanen, Garrett Trant, Bill Johnson

The latest releases of DBAN, Wipe and Eraser contain, besides the source, signatures which provide some good protection against program file manipulations.

        1.4.6 About hard disk densities

"Finally, however, the best defence against data remanence problems in semiconductor memory is, as with the related problem of data stored on magnetic media, the fact that ever-shrinking device dimensions (DRAM density is increasing by 50% per year), and the use of novel techniques such as multilevel storage (which is being used in flash memory and may eventually make an appearance in DRAM as well) is making it more and more difficult to recover data from devices. As the 1996 paper suggested for magnetic media, the easiest way to make the task of recovering data difficult is to use the newest, highest-density (and by extension most exotic) storage devices available." [5]

"Older disk drives left some space between tracks; data written to a track could occasionally be recovered from this inter-track region using special instruments. Today's disk drives have a write head that is significantly larger than the read head: tracks are thus overlapping, and there is no longer any recoverable data "between" the tracks. " [6]

    1.5 Conclusion

If absolute security is indicated, then physical destruction (through smelting or pulverizing) is the only solution.
Degaussing may be an alternative, though I have no data which might indicate magnetic forces that have been proven to be sufficient for securely erasing data from hard disks.

When the drive should be usable after the process of erasure, then overwriting with random numbers more than 30 times provides a high security level which may even beard intelligence. I personally suggest 10 passes random numbers for a medium security level and 2 passes random numbers for a low level.
Theoretically, true random numbers are preferred to CSPRNG and PRNG data.  However it's quite hard to gain unpredictable random numbers (unless you click here). In practice, random numbers from CSPRNG are desirable. Currently only Eraser uses a practically strong PRNG (ISAAC).
(It seems that enabling the ISAAC on Windows XP makes the Explorer crashing)
DBAN and Wipe use the Mersenne Twister; DBAN allows an optional seeding of the PRNG.
However, it seems plausible that having a strong PRNG is more important with less overwrite passes, while when overwriting e.g. 40 times, the Mersenne Twister should be perfectly enough.

The afore mentioned applies to modern hard drives. With older hard drives (more than ~10 years), the Gutmann Method might provide a sound mean of sanitization.

I strongly discourage the use of "official" patterns like DoD 5220.22-M or Bruce Schneier's method.

The use of modern hard drives should increase an attacker's effort significantly. In general, the higher the density, the higher the cost for recovery.

Furthermore, by using open source software you can reduce the risk of getting programs that have built-in mitigation of security features. If you want to wipe whole partitions/hard drives, then DBAN is the best choice. If you are operating from within your OS, you have to stick to Eraser or Wipe respectively.

In General, it is recommended to erase full partitions or better the complete drive than just single files. Remember that many applications create temp and/or dump files and that a lot of information is stored by your OS (esp. by the cheap ones from Redmond), e.g. the tracking features in Windows XP or the SWAP file.

The task of hard disk sanitization becomes clearly easier and more secure when the disk's contents have been properly encrypted before any wiping process. Look to it that every bit is written in encrypted form onto your disk. Notably, it wouldn't make any sense to write your data in plaintext onto the disk, encrypt it after that and then erase it.
If you properly applied a full disk encryption system and never stored your key on the disk, I bet even with a few single passes of random scrubbing no terrestrial attacker will be able to compromise your privacy within the next years.

In conclusion, a combination of strong full disk encryption on all your hard drives and the overwriting with strong random numbers more than 30 times will give you a sound position of defence (for an introduction see Sun Tzu's "The Art of War").




References:

1. Devera D: The Difficulty of Data Annihilation from Disk Drives: or Exnihilation Made Easy. (December, 11th 2001)
2. Gutmann P: Secure Deletion of Data from Magnetic and Solid-State Memory. Proceedings of The Sixth USENIX Security Symposium (1996). pp 77-90
3. Schneier B: Applied Cryptography. John Wiley & Sons, Inc. (1996). 2nd ed.
4. Gutmann P: Secure Deletion of Data from Magnetic and Solid-State Memory. updated paper
5. Gutmann P: Data Remanence in Semiconductor Devices. Proceedings of the 10th USENIX Security Symposium (2001). pp 39-54.
6. Garfinkel S and Shelat A: Remembrance of Data passed: A disk sanitization study. IEEE Security and Privacy, January/February 2003. pp 17-27









2. Encrypting Hard Disks
    2.1 Important preliminary information
    2.2 Full/partial disk encryption for Windows OS
        2.2.1 Full disk encryption: Commercial products
           2.2.1.1 Which software shall I use?
        2.2.2 Open Source solutions
        2.2.3 Know your enemy
        2.2.4 Removing insecure Windows components
    2.3 Disk encryption for Linux/Unix
        2.3.1 Introduction
        2.3.2 Survey of disk encryption approaches for Unix-like OS
        2.3.3 Which encryption system shall I employ?
    2.4 Discussion of encryption algorithms
       2.4.1 Recommendations

2. Encrypting Hard Disks

    2.1 Important preliminary information

- Never ever store your encryption key on your hard disk! Otherwise the password process that unlocks your key can be compromised with dictionary or brute-force attacks. Always put your key file on an external storage device, e.g. CD-ROM, USB-dongle or floppy. In case of emergency, having the key on a floppy may be your life insurance. A floppy disk can be easily destroyed by burning it. If you destroyed the key, your enemy is left with attacking the encryption scheme itself, which is almost certainly infeasable when you employed an encryption system with security in mind.

- Don't trust the Boot Partition on your hard disk! Always boot from external media like CD-ROM or an USB device if possible.

- No matter whether you use Linux/*BSD or Windows, you MUST harden your system. Most, if not all, disk encryption systems protect only your "cold" disk but offer no further protection in "online" mode. When your system is running and your encrypted disks/volumes are mounted, you have to rely on the security of your OS.
You may want to consider the use of a "secure" linux distro in the first place.

    2.2 Full/partial disk encryption for Windows OS

        2.2.1 Full disk encryption: Commercial products

Before you buy anything that boasts with slogans like "1344 bit Military Strength Encryption" I highly recommend to read this:

Snake Oil Warning Signs: Encryption Software to Avoid by Matt Curtin

Common criteria (EAL) validated products:


SafeGuard Easy (EAL 1) :  In August 2001, it was reported that the Danish police had successfully cracked 5 of 16 seized computers that were protected with SafeGuard Easy by German Utimaco AG in a tax evation case against Tvind. It was speculated that the British Scotland Yard had participated in the breaking. [Source]
Later, a Bo Elkjær (from Ekstra Bladet) claimed that he had interviewed the chief investigator Jens Kaasgaard (police in Holstebro) and that this Kaasgaard said:
"To avoid misunderstandings, we haven't broken Safeguard by technically breaking down the encryption. We have located the
passwords in different ways. We have done it like any hacker would have done, by trying to figure out the most probable passwords. This has payed success in five cases."
This explanation seems to be reasonable. If they really cracked Safeguard Easy, why did they crack only 5 of the 16 computers?
Nevertheless, this case should be a warning to all of us.

-SecureDoc (EAL 1)

<>Winmagic, the producer of SecureDoc, claims that Bruce Schneier (a renowned and well-known cryptographer) "has reviewed and crypto-analyzed SecureDoc source code. Bruce has verified the strength of SecureDoc's construction, and testified that there are no security holes."

Here's Bruce Schneier's statement:
"SecureDoc's sector based encryption is smart. It sits at the lowest level and intercepts all requests to read and write to the disk, so the entire disk is encrypted and no sectors are missed. With strong, trusted encryption algorithms, SecureDoc has a clean design."


-Pointsec for PC (EAL 4) : all Pointsec products are company solutions.

-Encryption Plus Hard Disk (EAL 1)



Common criteria (EAL) pending products:

-SafeBoot Professional

Neither validated nor pending products:

-DriveCrypt Plus Pack



CompuSec is a FREE full disk encryption program from CE-Infosys.  Unsurprisingly, it is NOT validated.
Personally, I would only use it if I had to protect my box from occasional, inexperienced script kiddies.
Businesses and people with sensitive data are advised to carefully select one of the Common Criteria validated products.
All paranoids MUST employ solutions from the open source crypto community, which means that they have to use a Linux or *BSD operating system.

        2.2.1.1 Which software should I use?

The NIAP (National Information Assurance Partnership; an U.S. Government initiative) maintains a list of Validated Products.
The section Sensitive Data Protection lists the following software solutions for a full hard disk encryption under Windows OS:

-Encryption Plus Hard Disk 7.0 (PC Guardian; USA) -> EAL 1

"PC Guardian has chosen to make a developer claim of compliance. This means that there has been no independent verification (by either the evaluators or a third party standards body, such as a FIPS laboratory) that the implementation of the cryptographic algorithms actually meets the claimed standards." [Source]
"The evaluation of PC Guardian Encryption Plus® Hard Disk Version 7.0 provides a basic level of independently assured security in a conventional TOE and is suitable for the environment specification in this ST. The assurance requirements were chosen to be consistent with this goal." [Source]

-Pointsec PC Version 4.3 (Pointsec Mobile Technologies, Inc; Sweden) -> EAL 4

"The TOEs cryptographic functionality is based upon code that has been certified as meeting the requirements of FIPS 140-1 Level 1. Cryptographic keys are generated, accessed, protected, and destroyed in accordance with requirements defined by FIPS 140-1 Level 1. Additionally, the TOE supports important cryptographic operations such as data and key encryption/decryption." [Source]

-SafeGuard Easy for Windows 2000, Version 1.0 (Utimaco Safeware AG; Germany) -> EAL 1

"Finally, the evaluators concluded that the independent tests carried out by them indicated that each aspect of TSFs tested are functioning correctly as one expects and would anticipate based on their descriptions given in ST [6], chapter 7 and Functional Specification respectively." [Source]

-SecureDoc Disk Encryption, version 2.0 for Windows 95/98 and Windows NT (WinMagic Inc.; Canada) -> EAL 1

"SecureDoc's use of the DES, Triple-DES and CAST5 algorithms and associated key lengths was validated under the Cryptographic Module Validation Program (CMVP). The Common Criteria evaluation verified that no plaintext remained in areas of disk media encrypted using SecureDoc. The cryptography, however, was not validated to FIPS 140-1, meaning that the ability of cryptography to withstand a concerted attack effort is unknown and cannot be inferred from the algorithm validation effort." [Source]

EAL stands for Evaluation Assurance Level. The higher the number, the more thorough the security testing. I.e. an EAL 4 certified product has undergone a more indepth testing of its security implementation than an EAL 1 solution.
BUT: how secure an EAL 4 product really is, can only be snatched from the certification report. The evaluation team tests the system in a given environment or for a special purpose. E.g. this allows a server manufacturer to let his product be tested in an environment that contains only a few threats. By this, a product can achieve EAL 4 without being secure from remote attacks!
The fact that Microsoft gained EAL 4 for its Windows 2000 OS should make your alarm system go off! Here you can read more about this "deal".

Nevertheless, it's much better to use certified software than not validated programs.

Based on the Certification Reports for the four above mentioned products, there is a clear recommendation for Pointsec PC Version 4.3. Unfortunately, all Pointsec products are company solutions. (more info soon)

Limitation: Though this seems to be paranoia, it is possible that the NIAP list of validated products (only) contains products that can be easily bypassed by US intelligence or law enforcement agencies.

Further Warning: All full disk encryption products for the Windows OS are commercial. These products are often used by companies. What if the CEO looses his key? It is possible and maybe even probable that these products contain "reset codes" or other "backdoors" whose primary intention are, to recover assets if keys of an authorised user are lost. These "backdoors" can also be used by any intelligence to compromise your system! Don't be too sure that companies won't implement such "recovery" functions because of their reputation. As long as you don't have the source code, you cannot proof that there is none.

        2.2.2 Open Source solutions

If you don't fear the police or your local intelligence agency, you can well live with one of the above mentioned products. Otherwise you have to stick to open source.
Cryptographic applications are often broken not because of the underlying encryption algorithm, but because of an improper implementation. Open source cannot guarantee that the implementation is strong, but at least it can be peer reviewed and if experts on that field don't find anything, you have a good chance of winning the race.

To my knowledge, there are only 2 open source hard disk encryption tools for Windows OS: Truecrypt and PGPdisk.
PGPi 6.02 also includes PGPdisk. PGPdisk lets you create "Container" files. You then mount these container files and they act as Virtual Drives.  Truecrypt even lets you encrypt whole partitions.
PGPdisk encrypts the data with CAST-128. Truecrypt lets you choose between Blowfish, CAST-128, TripleDES and IDEA.
Furthermore, Truecrypt offers "plausible deniability".
Truecrypt is quite a young project, so it has not undergone a lot of testing. An anonymous contributor once told me about his Truecrypt testing experience and he noted that it was working correctly with one exception: his p2p downloads became "corrupted", though I don't know which application he used.
Warning: At the moment truecrypt.org is not reachable. There are rumours that the authors of Truecrypt are bound by patent disputes.

Beware that both tools won't offer any FULL disk encryption. You cannot encrypt your root device. Much sensitive data stored by your OS will not get encrypted! Keyloggers are another problem. If someone installed a keylogger on your system without your knowledge, he won't need to do Brute Force or Cryptanalysis, because he gets the password as soon as you mount your encrypted volume.

        2.2.3 Know your enemy

Now that you know that there is no open source solution for a full disk encryption for Windows, you should reflect who your possible adversaries might be:


-Low Security Level:

Your enjoyable Grand Mother is a hacker novice and feels like hacking your computer.

-> Create an Encrypted Volume using Truecrypt/PGPdisk. Put all your sensitive data in it.
Additionally, disable every unneeded/unwanted Windoze function storing data on your disk you can! If no information is written to your hard drive, nothing can be recovered. If you've read the sanitization part, you know that wiping sensitive data is time consuming and not absolutely secure.
Disable the SWAP file, hibernation and system restoration (these are very important!). Disable user tracking, recent files history, recent files in media player etc.
Install every program that may create copies of your sensitive data (e.g. MS Office) into the encrypted volume. Be sure that these programs don't put any tmp files on your root filesystem. Otherwise these copies are laying in plaintext somewhere on your root or program partition.


-Medium Security Level:

Your angry Grand Mother became an elite hax0r and determined crypto expert.  She decided not to sell you to the FBI.

-> Get one of the validated commercial FULL disk encryption tools. You may want to disable the same things that apply to Low Level.


-High Security Level

Your now evil Grand Mother finally turned into an UberHax0r and CryptoGuru. She regularly hacks into various supercomputer grids and possesses more computing power than the NSA. She identified you as a threat to national security and hence calls the FBI.

-> Do NOT use any Windows OS! Use Linux or *BSD instead. Apply a strong open source encryption package. If you cannot get forced (torture) to reveal your key, you won't probably need Steganography.
Of course you should know what and where your Unix OS stores information. "Anonymizing UNIX systems" by THC's van Hauser may be a start.

        2.2.4 Removing insecure Windows components

If you still depend on Windows XP (or 2000), you should have a look at nLite and XPlite/2000lite.
These two little programs let you remove unwanted features from Windows XP (2000).
nLite (by Dino Nuhagic) is for pre-installation tweaking. It lets you slipstream Service Packs, remove the unwanted programs and then create a "fresh" ISO.
XPlite/2000lite are for post-installation only. Once you did a clean install, run the program and remove whatever you want.
Delete all features you do not explicitly need. A minimum system should be your goal.
By totally removing unneeded features you can significantly improve your security and privacy situation.
I advise you to do a backup before any Windows tweaking. Beware that nLite is still in beta phase and that you should wait for a final release before using it for a productive system.

    2.3 Disk encryption for Linux/Unix

       2.3.1 Introduction

Here's a statement from Poul-Henning Kamp, the creator of GBDE, on existing disk encryption approaches:

"Several implementations have been produced which implement a disk encryption feature by running the user provided passphrase through a good quality one-way hash function and used the output as a key to encrypt all the sectors using a standard block cipher in CBC mode. A per sector IV for the encryption is typically derived from the passphrase and sector address using a one-way hash function. Two typical examples are [CGD] and [LOOPAES]. Unfortunately this approach suffers from a number of significant drawbacks, both in terms of cryptographic strength and deployability.

Protecting a modern disk, typically having a few hundred millions of sectors, with the same single 128 or 256 bits of key material offers an incredibly large amount of data for statistical, differential or probabilistic attacks in the future.
Worse, because the sectors contain file system or database data and meta data which are optimised for speed, the plaintext sector data typically have both a high degree of structure and a high predictability, offering ample opportunities for statistical and known plaintext attacks.
This author would certainly not trust data so protected to be kept secret for more than maybe five or ten years against a determined attacker." [Source]

So far so bad. But is there any secure disk encryption system for Unix-like OS? Well, I cannot give you an answer like "The best system is ...", but I'll do my best to give you important information on the security of various approaches. Neither will I present a detailed technical explanation, nor will I focus on trusted network file systems.

       2.3.2 Survey of disk encryption approaches for Unix-like OS

- CFS: Cryptographic File System

CFS offers the user a "secure directory" (usually /crypt ) whose content is encrypted transparently.


+ No kernel modifications (works completely in user space)
+ System independent architecture, which makes deployment possible on almost all Unix Systems (basically only NFS compatibility needed).
+ Independent of employed file system
+ CFS supports the use of Smart Cards for storing the passphrase

- does not protect the filesystem meta-data (CFS encrypts each file separately and doesn't encrypt file system meta-data)
-> directory layout visible
-> position, count and size of files are in plaintext
-> possible "known plaintext" attack: files and file activities can be analyzed, file content (at least the beginning) can be deducted from size and position
- slow (because of user space and NFS server)
- one password for all files
- CFS does not secure the key while it is entered (as most other systems)
- As long as the key is in the memory of CFSd, you have to trust the security of your system (as with most other systems)
- CFS does not guarantee that no vital data appears in plaintext in a paging device or the system cache

You can find Matt Blaze's paper here.



-TCFS: Transparent Cryptographic File System

Based on CFS. 2 main differences compared to CFS:

i) encryption routines are implemented into the kernel -> you need a patched kernel
ii) no plaintext sent over the network -> better suited for networks


+ faster than CFS
+ Works transparently with the remote file system

- One cipher is used for all operations
- encrypted files are accessed simply by logging in. password length restricted to 8 characters
- encryption keys are stored on disk in a key database




- SFS / StegFS

Both SFS and StegFS are based on the work of Anderson et. al. and try not only to encrypt but also to hide the data.
SFS can be seen as a first implementation of the proposed ideas.
StegFS was independently developed from SFS in order to remove SFS's weaknesses and to provide a fully functional and secure steganographic filesystem.
This is accomplished through a modified Ext2 kernel driver that keeps a separate block-allocation table per security level.
The secret data is stored in unused blocks of a partition. In order to minimize the risk of data loss, several copies of the original file are created.
According to this work, 4 copies of the original file should be enough so that the risk of data loss becomes acceptably small.

"Although StegFS achieves plausible deniability of data's existence, the performance degradation is a factor of 6-196, making it impractical for most applications. " [Source]




- CryptFS

Kernel-based.
implemented for FreeBSD, Linux, Solaris.
Performance-tuned.
Uses Blowfish algorithm.
Uses "VNode-Stacking". Encrypted data is written through a loopback file system on the disk.
CryptFS works on file level, which means that it has to process file contents and file names separately. This leads to performance losses and various other problems. E.g. you are not allowed to encrypt "." and "..".
With this approach, the principal directory structure is always visible. Creating or deleting files is visible to an attacker, which reduces the security of CryptFS.

"Cryptfs was never designed to be a secure file system, but rather a proof-of-concept application of FiST [73]. Cryptfs supports only one cipher and implements a limited key management scheme." [Source]



- ZIA

"Zero-Interaction Authentication (ZIA) uses Cryptfs with Rijndael as a basis for a system that uses physical locality to authorize use on a laptop [11]. To effectively use file system encryption, users must provide the system with a passphrase. Normally, after the user provides the machine with the passphrase, anyone who physically possess the machine has access to the data. The laptop running ZIA communicates with an ancillary device that is always in the physical possession of the user, (e.g., a wrist-watch) that provides the laptop with the encryption key over a wireless channel. When the device leaves the vicinity of the laptop, all information in the file cache is encrypted. When the user returns, the information is automatically decrypted.
[...]
Zero-Interaction Authentication (ZIA), another encryption file system based on Cryptfs, takes the approach of encrypting all pages when an authentication expires [11]. This is less efficient than the NCryptfs method, because ZIA will also maintain copies of pages in the lower-level file system. ZIA requires the initial encryption of pages, and will use memory for these encrypted pages." [Source]



- NCryptFS

- security only as strong as the user password (as with most systems)
- directory structure not protected



- vncrypt

cryptographic disk driver for FreeBSD.
based on the vn(4) driver.
uses a normal file as a backing store.
similar to cryptoloop.




- CGD (NetBSD)

cryptographic disk driver for NetBSD.
similar to Linux loopback device, but uses a native disk or partition as backing store.
fully featured suite of user-space configuration utilities.
+ n-factor authentication and PKCS#5 used for transforming user passwords into encryption keys.
+ each block is encrypted separately from any other block.
+ different IV for each block (against structural analysis)

Also see The CryptoGraphic Disk Driver by Roland Dowdeswell and John Ioannidis




- GBDE (FreeBSD)

based on GEOM (provides modular framework to perform transformations for cryptographic protection of the data)
user-supplied passphrase is hashed into 512 bits of key material.
key material is then used to locate and encrypt a 2048 bit master key on four distinct lock sectors.
when a sector gets encrypted, the sector number and bits of the master key are hashed together with MD5 to create a kkey.
the sector key (randomly generated) is then encrypted with the kkey and then written onto the disk.
the data on the sector is encrypted with the sector key and written on the disk.
similar to Cryptoloop (using a raw device as backing store).

- no PKCS#5, PBKDF2 or any other iterated salted key generation -> no adequate protection from dictionary attacks against the pass phrase

Also see GBDE - GEOM Based Disk Encryption by Poul-Henning Kamp





- OpenBSD vnd(4)

OpenBSD's Vnode disk driver, vnd(4), supports encrypted file systems.
so far only Blowfish implemented.
similar to Cryptoloop with a file as backing store

- no cryptographic hash transform -> no protection against dictionary attacks


-> OpenBSD Encrypted Virtual Filesystem Mini-HOWTO by Kyle Amon




- PPDD: Practical Privacy Disk Driver

PPDD is based on the LoopFS device which allows creating file systems within files. These files can then be mounted like regular file systems. The Kerneli project offers patches for LoopFS. The whole file system structure gets encrypted, including Inodes and Superblocks.

PPDD extends the basic functionality of LoopFS: it is easy to use and makes backups more secure by offering to store the password-protected key separate from the user's data.
Another bonus of PPDD is the ability to encrypt the whole system (including swap partition) and then booting from a secure root partition. This allows a high security level to be accomplished.

PPDD device driver either is implemented directly into the kernel or done via kernel module.
PPDD uses Blowfish; cipher algorithm is written in assembler -> runs on x86 platforms only.

As long as the secret key is not within the system and the file system is not mounted, PPDD offers a high security level.
As soon as the file system gets mounted, the only protection are Linux file permissions. Therefore PPDD should reasonably only be employed on single-user systems (especially if the whole system is encrypted).

There exist PPDD-enabled rpms for Red Hat Linux.




- Loop-AES

loadable Linux kernel modules.
no kernel modifications.
uses AES.

For more info read the Loop-AES-Readme!


- Cryptoloop

"The Linux loopback device driver presents a file as a block device, optionally transforming the data before it is written and after it is read from the native file, usually to provide encryption. Linux kernels include a cryptographic framework, CryptoAPI [53] that exports a uniform interface for all ciphers and hashes. Presently, IPsec and the Cryptoloop driver use these facilities.
[...]
Using preallocated files is more secure than using sparse files, because an attacker can not distinguish random data in the file from encrypted data. However, to use a preallocated file, space must be set aside for encrypted files ahead of time. Using a sparse backing store means that space does not need to be preallocated for encrypted data, but reveals more about the structure of the file system (since the attacker knows where and how large the holes are)." [Source]


- Cryptoloop is vulnerable to optimized dictionary and watermark attacks

Cryptoloop HOWTO by Ralf Hoelzer January 15th 2004. (Cryptoloop/CryptoAPI; for Linux Kernel 2.6)




- dm-crypt

"In Linux 2.6.4, the Cryptoloop driver has been deprecated by dm-crypt. dm-crypt uses the generic device mapping API provided by 2.6 that is also used by the LVM subsystem. dm-crypt is similar to Cryptoloop, and the architectural overview remains the same. dm-crypt still uses the CryptoAPI, and the on-disk encryption format has remained the same. There are two key implementation advantages of dm-crypt over Cryptoloop: (1) encryption is separated from the loopback functionality, and (2) dm-crypt uses memory pools to prevent memory allocation from within the block device driver (eliminating deadlocks under memory pressure)." [Source]

- dm-crypt is, like Cryptoloop, vulnerable to optimized dictionary and watermark attacks





"The drawback is that a filesystem usually contains a lot of data that is known to the attacker, so a known plaintext attack becomes more feasible. The cryptanalyst might also glean knowledge about the filesystem and its contents by comparing blocks supposed to contain the same contents if constant IVs are used. Like in TCFS, the same key is used to encrypt the whole filesystem, so again the attacker has to compromise just one key to retrieve all the information stored. Since the filesystem has to be mounted to be accessed, and the key has to be in the kernel to mount it, any local user with adequate file permissions can access any file contained in the encrypted volume. Decrypted pages from encrypted files might end up getting swapped out to disk and remain there for a long time." [Source]

Also see: Vulnerability in encrypted loop device for Linux by Jerome Etienne December 27th 2001





- EncFS: Encrypted Filesystem module for Linux

encrypted file system in user space.
uses fuse libary and linux kernel module to provide the file system interface.
works on files, not on a block device.
pass-through-system (not an encrypted block device)

+ easy backups (on a file-by-file basis)

- much information visible to an attacker (count, permissions, size of files, approximate size of filename)




- CryptoFS

"CryptoFS is a encrypted filesystem for the Linux Userland FileSystem.
[...]
CryptoFS will use a normal directory to store files encrypted. The mountpoint will contain the decrypted files. Every file stored in this mountpoint will be written encrypted (data and filename) to the directory that was mounted. If you unmount the directory the encrypted data can only be access by mounting the directory with the correct key again.
[...]
When a filesystem is mounted CryptoFS first generates a key for the requested cipher algorithm (CRYPTOFS::cipher) using the message digest function (CRYPTOFS::md). Every algorithm has a specific key size and every message digest function has a specific length of the generated message digest. If the message digest size is smaller then the keysize the message digest will be repeated until the key size is reached.

After they primary key has been generated CRYPTOFS::salts subkeys (initialization vectors) will be generated by encrypting 0 bytes with a 0 initialization vector. These will later be used to encrypt blocks with different subkeys to make sure the cipher text will first repeat after (salts * blocksize) bytes (If the same data is encrypted).

When files or links are created or renamed the name will be encoded with the selected cipher, the primary key and the first subkey. The result will then be encoded using a modified Base64 algorithm because the encrypted filename could contain characters that are not allowed by the target filesystem. (The original Base64 algorithm uses '/' for encoding. This is the directory delimiter so it was replaced by '_')

When files are written the data will be encrypted. CryptoFS always has to write full blocks. So if only a part of a block should be written the original block will first be read, decrypted, the part replaced and then the result then written encrypted back to disk. To keep this performant that block size must not be too large. But to make sure the cipher text does not repeat to early, CryptoFS uses salts to encrypt blocks. Every block will be encoded with the (blocknumber module salts)th salt. (NOTE: Linux always reads or writes "pages" of size 4096 bytes, these writes will be forwarded by lufsd to CryptoFS. So if you use a blocksize of 4096 bytes reading the old block before writing can be omitted and writing should be faster)." [Source]



- Rubberhose

transparent encryption.
steganography.

        2.3.3 Which encryption system shall I employ?

As Gunnery Sergeant Hartman already indicated, my goal is to present encryption systems that were designed with security in mind.
Therefore, I will define requirements that secure systems should fulfill in order to separate the wheat from the chaff.
In my opinion, the most important questions are:

- Can I encrypt the swap partition?
- How are keys generated, stored and destroyed?
- Can I encrypt my root directory?
- Is the directory structure visible?

There are many other aspects that influence the strength of a system, but these will be discussed in detail when we narrowed the whole thing down.
Some of you may be bound to a specific OS or kernel and hence have a limited choice. However, I will not do a ranking for every OS.


First, we will check whether the various systems support swap encryption.
Why is this so important? - Many computers use a paging device for swapping data from the RAM to the hard disk for improved performance.
When your swap is not encrypted, you face 2 main problems:
i) the key you use for accessing your data may eventually be transferred to the paging file (probably this occurs only when you're short with RAM or running some heavy RAM-eating processes such as video encoding)
ii) sensitive data you're working with, is stored in the swap file
When you now turn off your computer, an attacker could simply investigate the swap file and maybe find your key or the data you normally encrypted in plaintext. So, even if the encryption system itself encrypts your root directory, stores your key(s) on external media, uses secure hash transforms and keeps the disk layout invisible, all this is in vain when your swap is not encrypted!


a) SWAP encryption possible?