SQL Server Magazine

Securing a computer system entails employing measures that protect the computer's data from viewing or manipulation by unauthorized users. Security measures at the network interface prevent intruders from gaining entry to the computer, and file-system security prevents the computer's authorized users from accessing data they're not supposed to access. However, a computer that is isolated from the Internet behind a firewall and that has stringent file-system security policies in place remains unsecured if no strategy exists to guard the computer's physical security. If unauthorized users have physical access to a computer, they can remove the computer's hard disks and perform offline analysis of the disks' data. When users can view a hard disk's contents on a different computer, file-system security (e.g., the kind NTFS ACLs provide on Windows NT or Windows 2000— Win2K—systems) is of no value. This problem is especially acute for laptop computers because two NTFS file-system drivers that ignore NTFS security—NTFSDOS and an NTFS driver for Linux—let even casual thieves easily view NTFS files.

One way to address the physical security problem is to keep computers in locked rooms, but this solution is obviously not practical for laptop computers, whose main purpose is portability. Thus, to prevent access to file data in situations in which bypassing file-system security is a possibility, data encryption is necessary. Before Win2K, NT users have had to turn to third-party vendors for encryption solutions, but in Win2K a built-in encryption facility for NTFS files exists in the form of Encrypting File System (EFS). By building encryption into the OS, Microsoft can make the encryption and decryption process transparent to both applications and users.

Unfortunately, Microsoft has produced little documentation describing how EFS works. Because many people will undoubtedly rely on EFS to secure their sensitive data, having a solid understanding of what goes on under the hood is important. In this two-part series about EFS, I'll take you beneath the surface and let you know exactly how EFS works with NTFS and Win2K cryptography facilities to help you keep your data safe from prying eyes. This month, I provide an overview of EFS and begin walking you through the process by which EFS encrypts files. Next month, I'll finish the encryption walk-through, describe the decryption process, and introduce the data recovery mechanism EFS has built into the decryption process.

EFS Overview
EFS security relies on Win2K cryptography support, which Microsoft introduced in NT 4.0. The first time you encrypt a file, EFS assigns your account one public key and private key pair for use in file encryption. You can deliberately encrypt files via an NT Explorer dialog box, as Screen 1, page 52, shows, or a command-line utility. Win2K automatically encrypts files that reside in directories the OS designates as encrypted directories. When you encrypt a file, EFS generates a random number for the file that EFS calls the file's file encryption key (FEK). EFS uses the FEK to encrypt the file's contents with a stronger variant of the Data Encryption Standard (DES) algorithm—DESX. EFS stores the file's FEK with the file but encrypts the file with your EFS public key using the RSA public key-based encryption algorithm. After EFS completes these steps, the file is secure: Other users can't decrypt your data without the file's decrypted FEK, and they can't decrypt the FEK without your private key.

Why does EFS use a public key/private key algorithm to encrypt FEKs, and DESX to encrypt file data? Because DESX uses the same key to encrypt and decrypt data, it is a symmetric encryption algorithm. Symmetric encryption algorithms are typically very fast, which makes them suitable for encrypting large amounts of data, such as file data. However, symmetric encryption algorithms have a weakness: You can bypass their security if you obtain the key. If multiple users want to share one encrypted file protected only by DESX, each user would require access to the file's FEK. Leaving the FEK unencrypted would obviously be a security problem, but encrypting the FEK once would require all the users to share the same FEK decryption key—another potential security problem.

Keeping the FEK secure is the difficult problem EFS addresses with the public-key-based half of its encryption architecture. Encrypting a file's FEK for individual users who access the file lets multiple users share an encrypted file. EFS can encrypt a file's FEK with each user's public key and can store each user's encrypted FEK with the file. Anyone can access a user's public key, but no one can use a public key to decrypt the data that the public key encrypted. The only way users can decrypt a file is with their private key, which the OS must access and typically stores in a secure location. A user's private key decrypts the user's encrypted copy of a file's FEK. Win2K's first release will store private keys on a computer's hard disk (an arrangement that isn't terribly secure), but subsequent releases of the OS will let you store your private key on a smart card, for example. Public-key-based algorithms are usually slow, but EFS uses these algorithms only to encrypt FEKs. Splitting key management between a publicly available key and a private key makes key management a little easier than symmetric encryption algorithms do, and solves the dilemma of keeping the FEK secure.

   Prev. page   [1] 2 3 4     next page