w2kserver book hack proofing windowns 2000 server phần 4 docx

When a user encrypts a file, the Encrypting File System uses the user’s publickey to encrypt the FEK.This Windows 2000 design prevents users from sharingone decryption key.The public key

5 Right-click the Security Settings node, and select Import Policy.

Notice that the policies are template files with the inf extension.Youhave the option of merging the template’s entries into the present OU’ssecurity setup, or you can clear the present OU’s security settings andhave them replaced by the settings in the imported template Click

Opento enact the new policy

You are not given the option to test the template settings against the presentOU’s security configuration.The settings are enabled after you import the policyvia the inf file

Additional Security Policies

The following are a few additional security policies of which you should be aware:

■ IPSec policy IPSec security policies can be configured and analyzed inthe Security Configuration and Analysis snap-in For more information

on IPSec, see Chapter 7, “IP Security for Microsoft Windows 2000Server.”

■ Public key policies Included in the public key policies are theencrypted data recovery agents, root certificates, and certificate trust lists

These topics are covered in detail in Chapter 9, “Microsoft Windows

2000 Public Key Infrastructure,” and Chapter 6, “Encrypting File Systemfor Windows 2000.”

The Security Configuration Tool Set introduces a new and more efficient way tomanage security parameters in Windows 2000 Using this new set of configura-tion and management tools, the administrator can configure and manage thesecurity policies for a single machine or an entire domain or organizational unit.The Tool Set includes the Security Configuration and Analysis snap-in,Security templates, the secedit.exe command-line tool, and the security settingsextensions to the Group Policy Editor.Together, you can use these tools to createand configure security policies for local machines, domains, or OUs

The Security Configuration and Analysis snap-in allows the administrator tocreate a database with security configuration entries.These security configurationentries can be used to test against the existing security configuration of a localmachine After the security analysis is complete, the network manager can savethe database entries into a text file with the inf extension.This text file, which is

a template consisting of security configuration entries, can be saved or imported

in order to define the security definition of another local machine, a domain, or

an OU

The security variables in the database can also be applied to the localmachine, replacing the current security configuration.The new configuration isapplied after the analysis is complete

Security configuration can be saved as templates, which are text files that tain security configuration information.These templates are imported into theSecurity Configuration and Analysis snap-in database for analysis and application.The Security Configuration and Analysis snap-in cannot be used to configure

con-or analyze security configurations of a domain con-or OU At present, there is no way

to export extant domain or OU security configurations However, you can figure the security of a domain or OU via the security settings Group Policyextensions

con-The secedit.exe command-line tool allows the administrator to script securityanalyses, security configurations, security updates, and export of templates Itsfunctionality is almost equal to that of the Security Configuration and Analysissnap-in, except that you must use the graphical interface to review the results of asecurity analysis performed by secedit.exe

An administrator can use the security settings Group Policy extensions toconfigure domain or OU security policy In addition, you can import securitytemplates directly into the domain or OU.You should do this with great caution

if you have already customized the security settings for a domain or OU At

present, you cannot export the previous settings into a template that might berestored later However, if the administrator always reconfigures the securityparameters of a domain or OU by using templates, such templates can always berestored in the future.

Solutions Fast Track

Security Configuration Tool Set

; The main components of the Security Configuration Tool Set are theSecurity Configuration and Analysis snap-in, the security settingsextension to Group Policy, secedit.exe, and the Security Templates snap-in

; The Security Configuration and Analysis snap-in creates, configures, andtests security scenarios.You can create text-based inf files that containsecurity settings.You can apply these files to the computer or save themfor later use

; Microsoft provides templates for configuring security Default andincremental templates are available Default templates are applied duringfresh installs and during upgrades from Windows 9x.The incrementaltemplates provide additional security above the defaults

; Secedit.exe allows us to configure security from the command prompt

; The Security Templates snap-in allows us to view and customize thetemplate files stored in %windir%\security\templates

; The Restricted Groups setting configures group membership and group nesting.

; Registry Policy sets permissions on Registry keys

; The File System Security setting configures NTFS permission for alllocal drives

; The System Services setting controls the startup policy for all localservices

Analyzing Security

; Compare security policies in the template with the actual state of thelocal machine.This practice allows administrators to see the differencesbefore they apply the policy

; Use Security Configuration and Analysis to view the results of an analysis.

Group Policy Integration

; You can use the features of the Security Configuration Tool Set toconfigure group policies

; Security policy can be edited in the Group Policy object

Q:Can I use the Security Configuration and Analysis snap-in to analyze thesecurity configuration of a domain or OU?

A:Not at this time.This capability should be added in the future However, atpresent, you can test scenarios against the current configuration for the localmachine

Q:I would like to use scripts to analyze a number of computers in my domain

What tool would I use to accomplish this task?

A:The secedit.exe command-line tool allows the administrator to analyze anumber of machines by creating scripts that can be automated.You can thenview the results of the analysis by opening the database file against which theanalysis was run

Q:Why have the changes I made to the security policy on the local computernot taken effect?

A:Effective policy depends on whether a computer is a member of a domain or

an OU Policy precedence flows in the order in which policies are applied

First the local policy is applied, then site policy is applied, then domain policy

is applied, and finally OU policy is applied If there are conflicts among thepolicies, the last policy applied prevails

Q:Can I migrate my Windows NT 4.0 policies to Windows 2000?

A:No.The NT policies were stored in a pol file, which included things such asgroup memberships.There is no way for the Windows 2000 Group PolicyModel, which is centered on Active Directory, to interpret the entries in the.pol file Microsoft recommends configuring the settings in the old pol files inActive Directory.You can do this easily using the security settings extension tothe Group Policy Editor.The Windows NT 4.0 pol files were created by the

Frequently Asked Questions

The following Frequently Asked Questions, answered by the author of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts To have your questions about this chapter answered by the author, browse to

www.syngress.com/solutions and click on the “Ask the Author” form.

System Policy Editor, which used adm files as templates for the options figured in system policy.These files are compatible with Windows 2000 admfiles However, you should not import these templates, because you mightdamage the registries of client machines.This means that after a Registry set-ting is set using Windows NT 4.0 adm files, the setting will persist until thespecified policy is reversed or the Registry itself is directly edited.

con-Q:How do I reverse the changes I made after applying a security policy?

A:There is no direct mechanism, such as an Undo button, that will allow you toreverse the changes Before you enact any changes to the local computerpolicy, back up the present configuration by exporting the current settings to

an inf file.Then you can restore your system to its previous state byimporting the inf file into the database and reapplying the changes

Encrypting the File System for Windows 2000

Solutions in this chapter include:

■ Using the Encrypting File System

■ User Operations

■ EFS Architecture

; Summary

; Solutions Fast Track

; Frequently Asked Questions

Chapter 6

199

the process of file encryption, which replaces physical security.

If thieves want your data, they can achieve their goal in many ways.Tools onsome other operating systems can access NTFS volumes while bypassing theaccess control supplied by NTFS Furthermore, the lack of physical securityallows laptops to be stolen easily Laptops now come with removable hard drives.This is great for the thief, since there is less contraband to conceal.The laptopstill appears on the desk, so the thief has more time to exit a building before anyalarms go off A desktop computer’s second hard drive can be missing by the nextmorning

The protection of data via physical security would be very easily implemented

if all the rooms where equipment is used were locked and nothing were everallowed to leave the room Of course, this approach to data security has a tremen-dous negative side; portability comes to a screaming halt Physical security is notreally a solution in today’s world; the technological solution is file encryption.Many file encryption products currently offered on the market by third-partyvendors are designed around password keys.This kind of encryption is not verysecure, because the encrypted file can be hacked quickly by brute force Securityproducts that were available before Windows 2000 required the user to encryptand decrypt files manually with each usage Most users do not have the time toback up their hard drives daily, and it is just as difficult to make the time toencrypt or decrypt files If encryption isn’t convenient for users, they probablywon’t use it

On occasion, users encrypt a file and then forget the password.The party product can handle this major problem in one of two ways: the product canprovide data recovery, or it cannot provide recovery.The more secure encryptionsoftware at the application level will not provide data recovery.The downside ofthis limitation becomes evident when a person is authorized, needs to get to the

third-data, and has forgotten the password If the vendor did provide some form of data recovery, security is weakened, and the recovery code is now the system’sweak point.

Some of the Windows 2000 Encrypting File System code runs down in tected mode.The kernel mode must not be available to users, or the operatingsystem will crash Microsoft has built encryption into the operating system,making encrypted data more secure than ever before.The new feature of theEncrypting File System on Windows 2000 provides an element of security thatWindows NT and third-party encryption software never approached in the past

pro-Using the Encrypting File System

The Encrypting File System supported in Windows 2000 is a new piece of rity in the NTFS file system Both public key encryption and secret key encryp-tion are implemented within the complete process, so data is encrypted quicklyand in such a way that it can stand up against an attack from any cryptanalysts

secu-U.S customers who purchase Windows 2000 receive a 56-bit standard DES rithm for implementation, but they can also obtain a 128-bit encryption DESalgorithm Until export approval is received, Microsoft will also have a 40-bitDES algorithm for all international customers

algo-The encrypted file can be read by anyone with a private key that can decryptthe File Encryption Key If a user leaves a company or if a user’s private keybecomes corrupted or is accidentally deleted,Windows 2000 can implement datarecovery.This might sound like a security weak spot, but data recovery in

Windows 2000 is not a security weakness Microsoft has written code to establish

an Encrypted Data Recovery Policy (EDRP), which controls who can recoverthe data if the owner’s private key is lost or if an employee leaves the organiza-tion In a workgroup environment,Windows 2000 automatically sets up theEDRP on the local machine In a domain environment, the EDRP is set up inthe domain policy by the system administrator, and computers belonging to thedomain will receive the EDRP from that location

Encryption Fundamentals

Encryption is the process of taking a plaintext file and processing it so that the

original data is in a new ciphertext format.Typically the encryption process uses

an algorithm and a secret value that is referred to as the key Public key

cryptog-raphy is designed so that each person has two keys: a public and a private key

Table 6.1 identifies the differences between these two keys

Table 6.1Public and Private Keys

Key Description Use

Private Never made known to anyone but the user Decryption

Public key cryptography is also known as asymmetric cryptography, since

dif-ferent users employ difdif-ferent keys to encrypt and decrypt a file Public key-basedalgorithms usually are on a very high security level, but they are considered slow.The basic processes of public key encryption and decryption are illustrated inFigure 6.1

Instead of the key pair, symmetric cryptography uses a single secret key One

popular method of symmetric cryptography is Data Encryption Standard (DES),which the National Bureau of Standards defined in 1977 for commercial andnonclassified use Developed by a team of IBM engineers who used their Lucifercipher and input from the National Security Agency, DES is an encryption algo-rithm that uses a 56-bit binary number key

Secret key algorithms are implemented quickly Because the DES algorithm isthe key that is used for both encrypting and decrypting data, this security mecha-nism is weak in its design Figure 6.2 illustrates the secret key algorithm method

One major difference between symmetric and asymmetric algorithms is thenumber of keys that are used in the process Public key algorithms use a key pair,

Figure 6.1Public Key Encryption and Decryption

Plaintext Plaintext Cipher Text Plaintext

Public Key

Plaintext Private Key

Figure 6.2Secret Key Algorithm

Plaintext Plaintext Cipher Text Plaintext

Secret Key

Cipher Text

Secret Key

but secret key algorithms use a single key.This major difference can clearly beseen in Figures 6.1 and 6.2.What the figures do not show is the differencebetween the two algorithms in terms of the amount of time needed to processfully the encrypting and decrypting of the file At one end of the spectrum, thesymmetric algorithms are useful for large amounts of data; at the other end,asymmetric algorithms are useful for small amounts of data Public key encryp-tion is a slower process method than secret key encryption, so each should beimplemented appropriately.

How EFS Works

Microsoft implements both secret key encryption, which is a fast and less secureprocess, along with public key encryption, which is slow but more secure.When

a request is received to encrypt a file, Microsoft has the Encrypting File Systemgenerate a random number for the file; this random number is known as the file’s

File Encryption Key (FEK).With this FEK, a modified DES algorithm, called

DESX, is used to generate the encrypted file and store it on disk.The secret keyalgorithm is being implemented at this point

The Windows 2000 operating system encryption process can be shown in thefollowing way:

Plaintext➔ FEK and DESX➔ Ciphertext

When a file needs to be decrypted, the FEK is used again If we store theFEK on disk with the file, we have the FEK available for decryption at any time

Anyone who needs to decrypt the file and who has access to it also has access tothe file’s FEK

Keeping sensitive data secure is the most important concern.The FEK isstored on disk and is available whenever it is needed, so that result is achieved,but anyone who can get to the file will have available the one thing needed fordecrypting the file.What has been overlooked here is the FEK’s security Secretkey encryption is weak in this aspect, but public key encryption is most useful.Totighten the FEK’s security, we will encrypt it also

When a user encrypts a file, the Encrypting File System uses the user’s publickey to encrypt the FEK.This Windows 2000 design prevents users from sharingone decryption key.The public key encryption method is used only on the smallFEK, so there is no impact on the system’s performance.The ciphered FEK isstored with the encrypted file Only the user, with that user’s private key, candecrypt the ciphered FEK, which is needed to decrypt the actual file At thispoint, both the sensitive data and the FEK are secured.The slow method of

public key algorithm is not used on the large file.The final design of file tion for Windows 2000 allows us to get the best from both encryption worlds.Now it is time to pull all these loose ends together into a clear, precise pic-ture Figure 6.3 demonstrates the encrypting process on a nontechnical level.

encryp-User Operations

The Encrypting File System adds more security to the Windows operating system than ever before.This built-in encryption allows any user to protect sensi-tive data against unauthorized use.This much-needed security feature can be usedimmediately after the operating system installation.The only requirement for the Encrypting File System is an NTFS partition No new administrative tasksinvolving installation and configuration of the Encrypting File System need to

be completed in order for it to work.These are the user operations that use fileencryption:

■ Encrypting a file

■ Accessing an encrypted file

■ Copying an encrypted file

■ Moving and renaming an encrypted file

■ Decrypting a file

■ Directory encryption

■ Recovery operations

Figure 6.3A Nontechnical View of the Encrypting Process

FEK FEK Cipher Text FEK

Public Key

Plaintext Plaintext

Secret Key

Encrypted File Stored on Disk

Cipher Text

File Encryption

The Encrypting File System uses a public key pair and a secret key in theencryption and decryption process.When a user tries to encrypt a file, the EFSmust determine first whether a key pair exists for the user or whether it must becreated If a key pair needs to be created, the generation will occur on a domaincontroller or on the local computer, depending on the environment, unnoticed

by the user Other tasks completed by the Encrypting File System include ating the actual ciphered file, ciphering the FEK, creating a log, creating a backupfile, and deleting the log and backup file used in the encryption process.There is

cre-a grecre-at decre-al of cre-activity in the bcre-ackground, but the user is uncre-awcre-are of it

In order to manage encrypted file resources, the user must first identify whatdata needs to be protected and then use either the Windows Explorer interface orthe Cipher command utility to let the operating system know where EncryptingFile System should be implemented

The owner can encrypt any folder or file, as long as it is stored on a NTFS

The easiest way to maintain encrypted files is to first create an encrypted folder

in which you plan to store all sensitive data Marking the directory for encryptionhas no effect on the listing of the files in the directory when you use the

Figure 6.4A Directory Marked for Encryption

shown in Figure 6.5) explaining how far down in the directory structure tion should be set.You will see the window shown in Figure 6.6 while encryp-tion is taking place.This window gives you an estimated time of encryptioncompletion.

encryp-Any compressed or system file cannot be encrypted under Windows 2000.With the Windows 2000 operating system, you should not encrypt the files neededfor booting Much the way that stripe sets are not available under Windows NTuntil the system is fully booted, encryption is not available under Windows 2000until the boot process is completed, which is efficient, considering the complexity

of the encryption/decryption process

NOTE

Never try to encrypt the files the system uses in order to boot Microsoft wrote the Encrypting File System code to prevent the accidental

encrypting of system files.

Figure 6.5Confirming Attribute Changes

Figure 6.6Applying Attributes

The Encrypting File System process will fail if you try to encrypt a file thathas the system bit set.The Encrypting File System also will fail if you try toencrypt a file on the root An attempt to encrypt a system file—that is, a file inwhich the system attribute is set—produces the message, “An error occurredapplying attributes to the file Access is denied.”The safeguard seems to be inplace and currently working.

Encryption can be implemented at both the directory level and the file level

To encrypt a single file on a NTFS partition, follow these steps:

1 Using the Explorer, select the file you want to be encrypted.

2 Right-click to bring up the Context menu, and then select Properties.

3 Click Advanced on the General tab.

4 In the Advanced Attributes dialog box, select the check box Encrypt

contents to secure data

5 Click OK.

6 On the General tab, click OK or Apply to mark the file as encrypted.

Assessing an Encrypted File

Assessing an encrypted file involves no special action by the user.When theWindows 2000 operating system verifies that the user has an acceptable privatekey, it decrypts the file so the user can read and/or modify it.The stored file isstill encrypted on the disk As the bytes are moved from the disk into the user’sworking set, the bytes go through the decryption process Using the Windows

NT operating system and a third-party product, each encrypted file must bemanually decrypted before its contents can be read.This added user task makes itimpossible to protect sensitive data through encryption on Windows NT

It is important to back up encrypted files In the Windows 2000 operatingsystem, just as in earlier versions of Windows NT, a file owner can control access

to the file If owners want to remove all access except their own, they can do sothrough the NTFS permissions.The fact that only the owner has access to a filedoes not prevent system administrators from backing up the file on a regularbasis Any user who belongs to the Backup Operators group has the ability toexecute the Backup Utility and back up the file.The Backup Operators group istied to the Backup Files and Directories right, which, when it runs the BackupUtility, allows the file to be opened and read.The Backup Files and Directoriesright contains written code that will bypass the normal access control list

The Encrypting File System also provides Backup Utilities with the ability toback up and restore files in ciphertext format.The backup process will not beable to decrypt the sensitive information nor will it have to decrypt and encryptduring the backing-up operation.The ADVAPI32.DLL library will provide theEFS APIs necessary for access to the encrypted data.

Windows 2000 backs up encrypted files in much the same way No specialconfiguration is needed Members of the Backup Operators group will not have

a private key, so there is no chance of their reading the sensitive data that youhave encrypted Encrypted data is backed up during a backup operation as itexists on disk.The Backup Utility reads and records the ciphertext file withoutdecryption

Copying an Encrypted File

The copy command is extended, with two new switches, to export and import

an encrypted file.When an encrypted file is copied, that encryption always takeprecedence If either the file you want to copy or the destination directory isencrypted, the resulting new file will be encrypted.Table 6.2 lists various situa-tions and the status of the resulting created files

Table 6.2 Copying Encrypted Files

Starting Encryption Copy New File

Both the directory and file Directory that is not Encrypted

The directory encrypted but Directory that is not Unencrypted

Both the directory and file Directory that is encrypted Encrypted unencrypted

Both the directory and file Directory that is Unencrypted

When the copy command is used without the /E or /I switch,Windows

2000 will first decrypt the file and then make a copy in plain text.The originalencrypted file is still encrypted on the hard drive

The Copy Command

The Windows 2000 operating system adds to the copy command by including

two new switches.The /E switch is used for an export function, and the /Iswitch is used to do the converse, which is to import

The /E switch can be added to the copy command to export a ciphertext

file as a ciphertext file.This means that the newly created file is still protectingthe sensitive data If the new file is accessed without having the encryption bitset, it will display the ciphertext created from the encryption process.The secu-rity of the Windows 2000 Encrypting File System means that a cryptoanalystwould have to break both the public key encryption and the secret key encryp-tion in order to see the sensitive data in plaintext

The /I switch should be used to import a ciphertext file onto a NFTS tion as a ciphertext file.The newly created file from the import operation ismarked as encrypted.When the file is accessed, the NTFS driver knows the file isencrypted and decrypts the file before displaying the contents.This decryptionoccurs only if the user making the request has the proper private key

parti-Unlike the Backup Utility of older Windows NT systems, which limited the

media that could be used for backup operations, the Windows 2000 copy

com-mand can copy the ciphertext to any file structure on any media.That means that

it is now possible to export the sensitive file to a diskette that uses File AllocationTables (FAT) as a file system and then later, at a different location in the domain,

to import the file and use it

Moving or Renaming an Encrypted File

Renaming an encrypted file is no different from renaming a compressed file.Theoperating system changes the filename but makes no modification to any otherfields in the file’s header.The fact that the file is encrypted sets an encryption bit

in the file’s header Renaming changes the file’s name but does not touch theencryption attribute

When an encrypted file is moved, it retains its encrypted status, regardless ofthe destination folder if on the same Windows 2000 system and an NTFS parti-tion.When an encrypted file is moved on the same partition, there is no differ-ence to the file other than the resident directory of the file.When the encryptedfile is moved to a different NTFS partition, the file is first decrypted and thenencrypted before being stored at the new location

Decrypting a File

Decryption is never a necessary request by the user after the file is encrypted, as

long as only that user needs to access the file.That does not mean that the

decryption process will never occur on Windows 2000.The decryption processdoes occur in two instances:The Windows 2000 Encrypting File System goesthrough the decryption process when the file is accessed and when the ownerdecides that the added security method is no longer needed

When the user wants to read and/or modify the contents of the encryptedfile, the Windows 2000 operating system decrypts the file as it is moved from thehard drive into physical memory.The file’s decryption for use is transparent tothe user, and the ciphered file is still stored on the hard drive.The user does nothave to decrypt the file manually before each use.The Encrypting File Systemmust have the user’s private key in order to decrypt the file.The user works withencrypted files just as he or she works with normal, unencrypted files If the userdoes not have a valid private key to the file, the system message “Access is

denied” appears, just as when the user does not have the proper permission.Decryption must also occur when the user decides that the information is nolonger sensitive and therefore does not have to be encrypted.When the informa-tion stored in a secretive fashion is no longer needed, the user can implement thedecryption process at the file or the directory level.The user can use the

Windows Explorer interface to clear the encryption bit, or the user can use theCipher Utility and execute the appropriate command.When an individual file isselected for decryption, only that file is affected.When the user at the directorylevel requests decryption, a message appears in the Explorer asking whether theuser wants to decrypt all files and subdirectories found within this directory, asshown in Figure 6.7

Figure 6.7The Confirm Attribute Changes Window

This decryption process at the directory level is exactly like the process forchanging permissions at the directory level Use these steps to decrypt a file:

1 Using Explorer, select the file you want to be stored unencrypted.

2 Right-click to bring up the Context menu, and select Properties.

3 Click Advanced on the General tab.

4 In the Advanced Attributes dialog box, clear the check box to Encrypt

contents to secure data

5 Click OK.

6 On the General tab, click OK or Apply to mark the file as unencrypted.

Cipher Utility

Windows 2000 allows users to use file encryption from the command prompt

The general format of the Cipher Utility is:

>cipher [ /e ] [ /d ] [ /s [dir]] [ /a ] [ /i ] [ /f ] [ /q ] [filename]

When the cipher command is executed with no switches or filename, the

result is a display of the encryption status of the current directory and any files in

that directory.Table 6.3 identifies each switch of the cipher command.

Table 6.3 Cipher Command Switches

Switch Function

/e Encrypts the specified files The directory is marked for encryption,

so any files or subdirectories created and placed here will be encrypted.

/d Decrypts the specified files The directory will be cleared of the

encryption attribute so that files added here will not be encrypted.

/s Performs the specified operation on the files in the directory and

on all subdirectories.

/i Continues to perform the cipher command, even if errors occur,

overriding the default behavior of the cipher command stopping

if an error occurs.

/f Forces encryption to occur on all specified files, even those that are

already encrypted, overriding the default behavior of not encrypting already encrypted files.

/q Reports only the most essential information.

The filename can be replaced with a filename or directory.The filenamespecification allows for wildcard usage, thus allowing multiple listings to beaffected with a single command execution.

Figure 6.8 shows a cipher command that was executed with no switches at

the root level of the directory structure Every existing directory is listed, and it ispossible to see whether or not the directory is marked for encryption

Figure 6.9 shows the result of executing the cipher command at the

direc-tory level.The direcdirec-tory is marked for encryption, and any new objects storedhere will be encrypted All files and subdirectories are shown, along with theircurrent encryption status

Directory Encryption

The Windows 2000 Encrypting File System allows encryption to be set at thedirectory and file levels.When the directory is selected for encryption, whatreally happens is that any new object placed in this directory, including files and

Figure 6.8Executing the Cipher Command with No Switches

Figure 6.9Executing the Cipher Command at the Directory Level

subdirectories, is encrypted Any current existing file and subdirectory will not beencrypted unless the owner manually sets the encryption bit on the existingobject It is best to create a directory, mark it for encryption, and then store allsensitive data in that directory when you work with the Encrypting File System.

When you modify a directory’s attribute to include encryption, the directory

itself is not technically encrypted; rather, the directory is marked for encryption.

This encryption mark controls all the new objects becoming encrypted

Recovery Operations

As mentioned earlier,Windows 2000 contains an Encrypted Data RecoveryPolicy (EDRP), which is part of the local security policy in a workgroup envi-ronment or part of the domain security policy for Windows NT domains.TheSecurity Subsystem in user mode is responsible for the enforcement of thispolicy So users can use file encryption offline, the Security Subsystem is respon-sible for caching the Encrypting File System policy, much the way logon infor-mation is cached on the local machine

The recovery policy must first be set up by the system administrator.TheWindows 2000 operating system contains a Recovery Agent Wizard, in whichrecovery agents are assigned along with their corresponding key pairs.TheMicrosoft Base Cryptographic Provider is used to create a data recovery file foreach recovery agent.The default domain recovery policy is configured so that thedomain administrator account is the only recovery agent.This needs to be one ofthe first things that you change, for two reasons: No one should be logging onwith the Administrator account (it should be renamed and not in use), and youneed more than one recovery agent for fault tolerance

Exercise 6.1 walks you through the process of adding a recovery agent thatdoes not have an EFS recovery certificate Exercise 6.2 walks you through theprocess of adding a recovery agent that does have an EFS recovery certificate

Exercise 6.1 Configuring a Recovery Agent without an EFS Certificate

1 Open Active Directory Users and Computers (Start | Programs

|Administrative Tools | Active Directory Users and Computers), as shown in Figure 6.10

2 Right-click your domain, and choose Properties.You will see the

window shown in Figure 6.11

3 Click the Group Policy tab.

4 Select Default Domain Policy, and click Edit.You will see the

window shown in Figure 6.12

Figure 6.10Active Directory Users and Computers

Figure 6.11The Group Policy Tab of the Domain’s Properties

5 Expand Computer Configuration.

6 Expand Windows Settings.

7 Expand Security Settings.

8 Expand Public Key Policies.

9 Right-click Encrypted Data Recovery Agents, and choose Create.

This step starts the wizard shown in Figure 6.13

Figure 6.12Encrypted Data Recovery Agents

Figure 6.13Welcome to the Certificate Request Wizard

10 Click Next to continue the wizard.

11 Figure 6.14 shows the Certificate Template window.This is where we

pick the type of certificate that we want Select EFS Recovery Agent, and click Next.You will see the screen shown in Figure 6.15.

12 Enter a friendly name and description for the certificate, and click

Next

13 The Completing the Certificate Request Wizard window (Figure 6.16)

is now displayed Click Finish to complete the request process and start

installing the new certificate

Figure 6.14The Certificate Template Window

Figure 6.15The Description Window

14 After requesting the certificate and completing the wizard, you are given

the window shown in Figure 6.17 Click View Certificate to look at

the new certificate before you install it

15 Figure 6.18 shows the certificate.Verify that it is for File Recovery andthat it is assigned to the correct users

Figure 6.16Completing the Certificate Request Wizard

Figure 6.17Viewing or Installing a Certificate

Figure 6.18Viewing an EFS Recovery Certificate

16 Click OK to return to the window shown in Figure 6.17.

17 Click Install Certificate.You’ll see the window shown in Figure 6.19,

indicating that the certificate was installed successfully

Exercise 6.2 Adding a Recovery Agent

That Has an EFS Recovery Certificate

1 Open Active Directory Users and Computers (Start | Programs

|Administrative Tools | Active Directory Users and Computers), as shown in Figure 6.10

2 Right-click your domain, and choose Properties, as shown in

Figure 6.11

3 Click the Group Policy tab.

4 Select Default Domain Policy, and click Edit to open the Group

Policy Editor, as shown in Figure 6.12

5 Expand Computer Configuration.

6 Expand Windows Settings.

7 Expand Security Settings.

8 Expand Public Key Policies.

9 Right-click Encrypted Data Recovery Agents, and choose Add.The

Add Recovery Agent Wizard shown in Figure 6.20 starts

10 Click Next to continue the wizard and open the Select Recovery

Agents window shown in Figure 6.21

11 In the Select Recovery Agents window, click Browse Directory to

search Active Directory for recovery agents (Figure 6.22) Optionally,you could use Browse Folders to search for the certificate of yourrecovery agent

Figure 6.19The Certificate Request Successful Window

12 After choosing Browse Directory, you need to pick the users you want

to be recovery agents.Type the name of the user and choose Find

Now Alternatively, you can click Find Now without typing a name to see all users, then select the user from the list and click OK to return to

the Select Recovery Agents window shown in Figure 6.21

13 Click Next to continue.You will see the Completing the Add Recovery

Agent Wizard shown in Figure 6.23

14 Click Finish to complete the wizard.

Figure 6.20Welcome to the Add Recovery Agent Wizard

Figure 6.21The Select Recovery Agents Window

The recommended steps in the recovery of an encrypted file that the ownercannot manipulate are:

1 The person who will be doing the recovery—that is, the RecoveryAgent—should use a Backup utility and restore a copy of the user’sciphertext file on the computer that has the recovery certificates

Figure 6.22Finding Users to Be Recovery Agents

Figure 6.23Completing the Add Recovery Agent Wizard

2 Using Explorer, display the encrypted file’s Properties.

3 On the General tab, the recovery agent needs to click Advanced

4 The clearing of the “Encrypt contents to secure date” check box willuse the recovery agent’s private key and decrypt the file

5 The decrypted file should now be backed up and restored to the user

One other possible method of recovery is to export the recovery agent’srecovery certificate to a diskette and then import the diskette contents onto themachine that has the encrypted file

The Windows 2000 operating system also provides a command-line utilitythat can be used to recover an encrypted file If you decide to use the EfsRecvrutility, the same steps should be applied in order to back up the file and restore it

on the computer that contains the recovery keys

The EfsRecvr command-line utility uses this general format:

EFSRECVR [ /S [:dir] ] [ /I ] [ /Q ] [ filename […] ]Table 6.4 summarizes each of the items in the EfsRecvr command line

Table 6.4EfsRecvr Command-Line Syntax

Item Function

/S Recovers the files in the given directory and all subdirectories

The default directory is the current directory.

/I The recovery process will continue, even if an error occurs The

default behavior is to immediately stop the recovery process should an error occur.

/Q Limits the reporting of only essential information needed to load

the appropriate keys.

Filename Specifies a file, directory, or pattern.

EFS Architecture

The Encrypting File System components and the encryption process, along withthe Encrypting File System File information and the decryption process, areinvolved in file encryption on Windows 2000 Let’s examine this involvement

EFS Components

In order to understand the entire encryption/decryption process, you need tolook at the Windows 2000 operating system architecture Keeping the same struc-ture as previous releases of Windows NT, the Windows 2000 structure containsboth user mode and kernel mode.When they developed the data encryption pro-cess, the designers had to decide where the encryption code should run If dataencryption were left in user mode, temporary files that were not encryptedwould be created, which provides no security at all On Windows 2000, when theEncrypting File System is implemented, some of the activity occurs in each ofthese two modes

In earlier versions of the Windows NT operating system, the Local SecurityAuthority Subsystem (LSASS) was in user mode.With Windows 2000, this sub-system takes on additional tasks and includes some additional functions for theLocal Security Authority Server in order for the Encrypted File System to workproperly.The functions are grouped as EFS functions Applications still run inuser mode, so when a user requests encryption using the Explorer or the CipherUtility, the activity starts here

The NTFS driver, which was first introduced in Windows NT 3.1, is inkernel mode Since users can protect sensitive data only on a NTFS partition, thisdriver has an active role in the overall encryption process Figure 6.24 shows bothold and new components

These are new, key components of the Encrypting File System:

■ EFS driver EFS is really a device driver connected with the NTFSdriver, both of which run in Windows 2000’s kernel mode.Whenever auser needs encryption or decryption, the EFS driver works with the cryp-tography services in Windows 2000 user mode.The EFS communicates

Figure 6.24EFS Components

LSASS

User Mode

LSASRV EFS Fuctions

Microsoft Cryptographic Provider 1.0

KSecDD Kernel Mode EFS

Application

Registered EFS Callouts

NTFS Encrypted File Access

with the KsecDD (security device driver) to request many of the requiredkey management services.When the NTFS needs to complete an impos-sible encryption task, the EFS driver takes on that responsibility.

■ EFS Callouts These are functions that the EFS driver can handle forthe NTFS driver.When the EFS driver initializes, it registers these func-tions with the NTFS driver.The EFS Callouts are in the protected envi-ronment of the kernel mode, so they are not available for direct useraccess

■ KsecDD This takes the EFS request and talks with the SecuritySubsystem on behalf of the EFS driver.The KsecDD acts as a connec-tion between the needed LPC calls and the Local Security AuthoritySubsystem in user mode

■ EFS Services These are in the Local Security Authority Server, which

is part of the LSASS In user mode, the Encrypting File System Servicesinterface with the Microsoft Base Cryptographic Provider 1.0 to provideFEKs and to generate the needed data decryption fields and data

recovery fields.The Encrypting File System Service is used to obtain andenforce the encryption data recovery process and to locate the user’s keypair when it is needed

■ Cryptographic provider For file encryption on Windows 2000, this isthe Microsoft Base Cryptographic Provider 1.0 In the future releases ofWindows 2000, support will be added so that third-party vendors canwrite their own cryptographic providers and have them tied to theEncrypting File System functions One role of the cryptographicprovider is to provide RSA encryption operations

NOTE

When the EFS driver initializes, it registers seven EFS Callback functions with the NTFS driver These are the current Callback functions:

■ EfsOpenFile When an application opens an existing file that has

EFS attributes, the NTFS driver invokes the EFS callback function EfsOpenFile.

■ EfsFilePostCreate After an NTFS file has created or opened a

file for an application, the NTFS driver needs the EfsFilePostCreate EFS Callback function’s help.

■ EfsFileControl and EfsFsControl When a user modifies the

file’s encryption settings, the NTFS driver makes a request for the EFS Callback functions, EfsFileControl and EfsFsControl.

■ EfsRead When NTFS retrieves data for an application, it

peti-tions EFS for the function named EfsRead.

■ EfsWrite When the user writes information in an encrypted file,

the NTFS driver invokes the EFS Callback function known as EfsWrite, because NTFS cannot encrypt the data itself.

■ EfsFreeContext For the sake of security, which is what

encrypting sensitive data is all about, the NTFS driver invokes the EFS Callback function EfsFreeContext when the context data buffer is no longer required.

The Encryption Process

Before any encryption can be used on Windows 2000, the EFS device drivermust be installed.When the EFS driver initializes, it notifies the NTFS driver ofits existence, and it also registers seven related functions at that time In the regis-tration of these functions, the EFS driver seems to be telling the NTFS driver,

“Here is a list of things I can do for you.” (See the Note sidebar for the list of theEFS Callback functions.)

When the NTFS driver receives a request for EFS, it looks into the table ofEFS Callback functions and invokes the function that the EFS driver must exe-cute.The EFS driver will not communicate directly with the LSASS, which runs

in unprotected user mode.The EFS driver sends a request to encrypt or decrypt afile to the LSASS, but an additional driver intercepts this request in kernel mode.The driver used to send the actual LPC message to Local Security AuthoritySubsystem, KsecDD, resides in kernel mode.The Local Security Authority Server,which is part of the LSASS, listens for these LPCs.When the LSASRV receives acall from the File Encryption Client DLL (FEClient) to encrypt a file, it invokesthe internal function EfsRpcEncryptFileSrv

EfsRpcEncryptFileSrv handles these tasks in the early stages of a file tion request:

encryp-■ Impersonates the user making the encryption request

■ Creates a log file that LSASRV uses to keep a record of the encryptionprocess from start to finish

■ Loads the impersonated user’s profile into the Registry

■ Makes a call to the internal function EncryptFileSrvImpersonation occurs for a reason.The LSASS has always used the Systemaccount by default If this account were used for the encryption process, theSystem’s private key would be needed to decrypt the file.The Encrypting FileSystem’s objective is to encrypt the file and then require a unique private keybelonging to the user for any future usage By impersonating the user, the properprivate key is used to manipulate the file

The log file that is created when an encrypt file request is received is used torecord the events in the encrypting process.The log file is on the same drive asthe encrypted file in the System Volume Information subdirectory.The name ofthe log file is EFS0.log If an EFS0.log file already exists, the name of the log file

is generated by incrementing the numeric value by one digit

This need exists despite the fact that the user’s profile has already been loadedinto the Registry because logging on the system is mandatory In most circum-stances, the profile would already be loaded, but software engineers cannot leaveanything to chance, especially when it comes to security If the user executed thenew Run As command of the Windows 2000 operating system, which allows thelogged-on user to take on a different identity, the loaded profile would be theresult of logging on the system, not the profile of the user making the encryptionrequest

When control is passed to the EncryptFileSrv function, an entirely new list oftasks must be performed EncryptFileSrv is in user mode, and the EncryptFileSrvfunction will take on the remaining tasks in the encryption process.This function

is responsible for these tasks:

■ Queries the NTFS driver about the data stream being used in the file

■ Calls the GenerateFEK function

■ Constructs the EFS information that is stored with the encrypted file

■ Creates a backup file

■ Initializes the log file

■ Sends an encrypted command to the NTFS driver to encrypt the file

In order for the EncryptFileSrv function to generate a FEK, another functioncalled GenerateFek is used GenerateFek initiates a session with the MicrosoftBase Cryptographic Provider and requests to use the RSA encryption algorithm

When it has established the session, GenerateFek calls another function to havethe provider in fact generate the FEK After the FEK is created, the session withthe Microsoft Base Cryptographic Provider is closed, and control is returned tothe internal EncryptFileSrv function.

EncryptFileSrv uses the FEK and the user’s key pair to create the EFS fileinformation At this point in the encryption process, a key is created for a user whodoes not have one.The system can easily identify a user’s lack of a key pair by theabsence of the CertificateHash value found in the Registry for the current user.After the EFS file information is built, a backup file named EFS0.tmp is cre-ated for the original plaintext file.The security descriptor for this backup file isset up so that only the system account will have access to the file

EncryptFileSrv now sends an encrypted control command to the NTFSdriver to add the recently constructed EFS file information to the original file.The NTFS driver understands an encrypted command in this way: At boot time,the Encrypting File System receives from the LSASS a session key that is used todecrypt any control command received from user mode.When the NTFS driverreceives the encrypted control command, the driver makes a request to the EFSCallback function, EfsFileControl.The EFS driver applies the session key todecrypt the control command and adds the EFS file information to the originalfile.The EFS driver also creates the $EFS NTFS metadata attribute.This is a newattribute added to the Windows 2000 operating system that contains the EFS fileinformation

After the EFS file information is added to the file, the activity is once againhanded back to the EncryptFileSrv internal function EncryptFileSrv performsthese tasks:

■ Records in the log file that the backup file was created

■ Sends another encrypted control command to the NTFS driver toencrypt the file at this time

When the NTFS receives the encrypted control command, it makes a request

to the EFS Callback function, EfsWrite EfsWrite uses the unencrypted FEK to

do secret key encryption of the file one sector at a time.The data is encryptedbefore the NTFS driver writes the data to disk In the United States, the

Encrypting File System uses a 56-bit standard DESX encryption key

When the file is completely written to disk in ciphertext form,EncryptFileSrv is handed control once again.The EncryptFileSrv function completes the encryption process by doing these tasks:

■ Records in the log file that the encryption process was successfully pleted without errors

com-■ Deletes the backup copy of the original file

■ Deletes the log file

■ Passes control back to the userThese task draws together the built-in fault-tolerant side of the encryptionprocess A backup copy of the original file is always available until the encryptionprocess is completed successfully If a system crash or other fatal error occurs, thelog file indicates where the encryption process stopped, and the original copy ofthe file can be used to redo the entire process

The EFS File Information

After the FEK has been created, the EFS file information can be constructed.TheLSASRV function called EncryptFileSrv has the control of the creation of theEFS file information that is stored with the file.The user’s key pair is needed tosupply the necessary information in the encrypted file’s header.The functionCryptoAPI is called to get a handle to the needed key pair If the user does nothave a key pair, if this is the first file to be encrypted, a key pair must be created

The function GenerateUserKey is used in creating the key pair and returns thesigned certificate for the pair.The generation of the key pair will happen on adomain controller or on the local machine on the basis of the computer’s envi-ronment.When the signed certificate is received, it is stored in the Registry inthe subkey HKEY_CURRENT_USER\Software\Microsoft\WindowsNT\

CurrentVersion\EFS\CurrentKeys\CertificateHash

Now that EncryptFileSrv has the user’s key pair, a function is used to obtaininformation about the provider that was used to generate the key pair InWindows 2000, that provider is the Microsoft Base Cryptographic Provider 1.0

The user information that is needed at this point is the provider’s name and thecontainer used to store the key pair, which in fact is nothing more than a filespecification

An example of a container is as follows: D:\Documents and Settings\

Administrator\Application Data\Microsoft\SystemCertificates\My\Certificates\

1612DAFAD20E037F2DBACD4113FC755BC23B6711

EFS now uses the function CryptAcquireContext to set up a cryptographicsession with the provider, using the provider’s name, the container’s name, and the fact that it desires to use the RSA encryption service of the Windows 2000

operating system.The provider’s name must be identified at this point because theWindows 2000 operating system allows software vendors to write their ownproviders and implement them if they want to RSA is the public key encryptionalgorithm that was written by Rivest, Shamir, and Adleman.The provider creates

128 bits of random data that will become the file’s FEK, and then a function iscalled to close the session with the Microsoft Base Cryptographic Provider.Now that EncryptFileSrv has a FEK, the EFS file information can be con-structed and stored with the file.The function GetCurrentKey is used to read

|the Registry information and get a handle to the user’s public key A LocalSecurity Authority Server function uses the public key to store the EFS informa-tion with the file Figure 6.25 identifies the components that make up the EFSfile information

The data decryption field (DDF) contains entries for each user who has

access to the encrypted file Each individual entry is referred to as a DDF key

entry.The components of the DDF key entry provide information to represent a

user’s public key.The user’s SID is a component of the key entry Also included inthe key sentry is the provider name and container name, the public/private keypair certificate hash, and the encrypted FEK Any collection of multiple key

entries in the EFS file information is called a key ring.

The EFS file information component of the Encrypting File System is notyet completed.There is no entry that will provide recovery if the user’s privatekey somehow becomes corrupted

Figure 6.25EFS File Information

Header Version

Checksum

DDF Key Entries DDF Key Entry 1 DDF Key Entry 2

DDF Key Entry #

Data Decryption Field (DDF)

Data Recovery Field (DRF)

DRF Key Fields DRF Key Entry 1

EFS Information

User SID Container Name Provider Name EFS Certificate Hash Encrypted FEK KEY ENTRY

User SID Container Name Provider Name EFS Certificate Hash Encrypted FEK KEY ENTRY