Windows 2000 extends security by supporting a number of technologies that are based on public key security, including the Secure Channel authentication package, smart cards, Authenticode, the Encrypting File System (EFS), and Internet Protocol Security (IPSec). This lesson reviews each of these technologies and explains how they fit into the PKI framework.
After this lesson, you will be able to
Estimated lesson time: 35 minutes
In Windows 2000, a Secure Channel (SChannel) authentication package is located below the Security Support Provider Interface (SSPI) as shown in Figure 27.7.
Figure 27.7 Authentication Services architecture in Windows 2000
The SChannel authentication package implements the Secure Sockets Layer (SSL) 3.0 protocol and the Transport Layer Security (TLS) 1.0 protocol. SSL and TLS are flexible security protocols that can be layered on top of other transport protocols. They rely on PK-based authentication technology and use PK-based key negotiation to generate a unique encryption key for each client/server session. They are most commonly associated with Web-based applications and the HTTP protocol (referred to as HTTPS).
The TLS protocol is based on the SSL 3.0 protocol and moves forward as the Internet Engineering Task Force (IETF) standard. The differences between TLS 1.0 and SSL 3.0 are not significant, but they are enough that TLS 1.0 and SSL 3.0 cannot interoperate. TLS 1.0, however, does have a negotiation mechanism whereby TLS can back down to and use SSL 3.0. Therefore, a client that supports only SSL 3.0 can still communicate with a server that supports TLS 1.0.
Both the SSL and TLS protocols provide secure data communication through data encryption and decryption, client authentication, and optional server authentication. Both are typically used to send and receive private communication across the Internet by using public key cryptography as its authentication method.
The SSL/TLS protocol is implemented by an SChannel provider (such as IIS, Proxy Server, and Exchange), and by client applications that transit the Internet (such as Internet Explorer and Microsoft Outlook e-mail clients). Applications request the services of SSL and TLS through the SSPI API.
The benefits of SSL and TLS include the following:
Smart cards, which are the size of credit cards, can be used to store a user's public key, private key, and certificate. Smart cards are a secure way to protect and control a user's keys, instead of storing them on a computer. A user's keys and certificates move with the user. Security-critical computations are performed by the smart card, instead of exposing a user's private key to the computer. In addition, smart cards enhance software-only solutions, such as logon and secure e-mail.
To use a smart card, a computer must have a smart card reader. A smart card is an ISO 7816-compatible device that contains an embedded microprocessor, an RSA or equivalent cryptography coprocessor, and local storage. The local storage includes the following:
Windows 2000 introduces PK-based smart card logon as an alternative to passwords for domain authentication. This relies on a PC/SC Workgroup-compliant smart card infrastructure, first introduced for Windows NT and Windows 95 in December 1997, and RSA-capable smart cards with supporting CryptoAPI CSPs. The authentication process makes use of the PKINIT protocol to integrate PK-based authentication with the Windows 2000 Kerberos protocol access-control system.
During operation, the system recognizes a smart card insertion event as an alternative to the standard Ctrl+Alt+Del secure attention sequence to initiate a logon. The user is then prompted for the smart card PIN code, which controls access to operations with the private key stored on the smart card. In this system, the smart card also contains a copy of the user's certificate (issued by an enterprise CA). This allows the user to roam within the domain.
The growing use of the Internet has led to an increased reliance on downloaded active content, such as Windows-based applications, ActiveX controls, and Java applets. The result has been a heightened concern for the safety of such downloads, since they often occur as a side effect of Web scripts without any specific user notification. In response to these concerns, Microsoft introduced Authenticode digital signature technology in 1996 and introduced significant enhancements of it in 1997.
Authenticode technology, a security feature in Microsoft Internet Explorer, assures accountability and authenticity for software components on the Internet. Authenticode verifies that the software hasn't been tampered with and identifies the publisher of the software. Users can decide on a case-by-case basis what code to download, based on their experience with and trust in a software publisher. By signing their code, developers can build an increasingly trusting relationship with their users.
Authenticode technology allows software publishers to digitally sign any form of active content, including multiple-file archives. These signatures may be used to verify both the publishers of the content and the content integrity at download time. This verification infrastructure scales to the worldwide base of users of Windows by relying on a hierarchical CA structure in which a small number of commercial CAs issue software-publishing certificates. For enterprise needs, the Windows 2000 PKI allows you to issue Authenticode certificates to internal developers or contractors and allows any employee to verify the origin and integrity of downloaded applications.
EFS is an extension to the NTFS file system that provides strong data protection and encryption for files and folders. The encryption technology is based on use of public keys and runs as an integrated system service, making it easy to manage, difficult to attack, and transparent to the user. This is particularly useful for securing data on computers that may be vulnerable to theft, such as mobile computers.
The encrypting user's public key is used in the encryption process, ensuring data privacy. Decryption is denied to any user without the corresponding private key. A special recovery key is also generated for each encrypted file. This key is for emergency use by a qualified administrator in the event that an employee leaves or a private key is lost.
Encryption and decryption are done transparently during the input/output (I/O) process. EFS imposes no discernible performance penalty during the encryption/decryption process.
EFS also supports encryption and decryption of files stored on remote NTFS volumes. However, EFS addresses only the encryption and decryption of stored data. Although encrypted files can be exported, data is transferred over the network in a clear (unencrypted) format by default. Windows 2000 provides network protocols such as SSL, TLS, and IPSec to encrypt data during transfer over the network.
EFS uses a combination of the user's public and private keys as well as a randomly generated file-encryption key (FEK). The FEK is a 128-bit key for North America and a 40-bit key for international releases. Windows 2000 uses the Data Encryption Standard X (DESX) algorithm to encrypt files.
The Encrypted Data Recovery Policy (EDRP) is used to specify who can recover data in case a user's private key is lost. An EDRP is automatically generated on standalone computers to minimize administration. Computers that are members of a domain receive the EDRP from the domain policy. For security, recovery is limited to the encrypted data; it is not possible to recover the users' keys.
Because members of the Backup Operators group do not have the keys necessary for decryption, encrypted data is read and stored in the backup as an opaque stream of data.
Encryption and decryption are sensitive operations because failure could result in data loss. Therefore, EFS makes all operations automatic. If an operation cannot be completed, it is completely undone. For example, if a computer loses power during an encryption operation, EFS undoes the operation on restart so that the file is in a consistent state.
Once a file is encrypted, the processes of encryption and decryption are automatic and transparent to users and applications whenever the file is used. It is possible to perform encryption one file at a time or one folder at a time.
You can encrypt a file or folder in Windows Explorer and from the command prompt.
It is not possible to use NTFS compression and encryption on the same file. Compression and encryption are mutually exclusive.
EFS encrypts, decrypts, and recovers files. Figure 27.8 provides an overview of the encryption process. The numbered steps shown in the illustration are described below.
Figure 27.8 EFS encryption process
When a user encrypts a file in EFS, the following process occurs:
The decryption process uses the DDF, created during encryption, to decrypt a file. Figure 27.9 provides an overview of the decryption process. The numbered steps shown in the illustration are described below.
Figure 27.9 EFS decryption process
When a file is decrypted in EFS, the following sequence of steps takes place:
The EFS recovery is much the same as the decryption process. Figure 27.10 provides an overview of the recovery process. The numbered steps shown in the illustration are described below.
Figure 27.10 EFS recovery process
When a file is recovered in EFS, the following process takes place:
The cipher command-line utility allows you to encrypt and decrypt files from a command prompt. The command uses the following syntax:
cipher [/e| /d] [/s:dir] [/a][/i] [/f] [/q] [/h] [/k] [pathname [...]]
If no parameters are used, the cipher command displays the encryption state of the current folder and any files it contains. Spaces must be put in between multiple parameters. Table 27.2 provides a description of each parameter.
Table 27.2 Cipher Command Parameters
|/e||Encrypts the specified folders. Folders are marked so thatfiles added to the folder later will be encrypted.|
|/d||Decrypts the specified folders. Folders are marked so thatfiles added to the folder later will not be encrypted.|
|/s:dir||Performs the selected operation on folders in the specified folder and all subfolders.|
|/a||Performs the selected operation on files with the specified names. If there is no matching file, this parameter is ignored.|
|/I||Continues performing the specified operation even after errors have occurred. By default, cipher stops when an error is encountered.|
|/f||Forces the encryption or decryption of all specified objects. By default, files that have already been encrypted or decrypted are skipped.|
|/q||Reports only the most essential information.|
|/h||Displays files with hidden or system attributes. By default, these files are not encrypted or decrypted.|
|/k||Creates a new file encryption certificate on the computer where CIPHER is run. This switch causes all other switches to be ignored. Therefore, run /k exclusive of the other switches.|
|pathname||Specifies a pattern, file, or folder. You can use multiple filenames and wildcards.|
To encrypt the C:\My Documents directory, type cipher /e "My Documents" at the C: command prompt.
To encrypt all files on the C: drive with the word "test" in the filename, type cipher /e /s *test* at the C: command prompt
In this practice you configure a data recovery policy in the domain, and then encrypt a folder. Complete this practice on Server01.
For additional practice, open the \chapt11\articles\efs-wp.doc on the Windows 2000 Training Supplemental CD-ROM and complete examples 2 to 7 (starting on page 12).
Recovery policy is configured by default when the first domain controller is installed. As a result, a self-signed certificate assigns the domain administrator as the recovery agent. In this exercise, you manually add the administrator as the recovery agent before using EFS.
Internet Explorer appears and it is displaying the Certificate Services enrollment page.
The Choose Request Type page appears.
The Advanced Certificate Requests page appears.
The Advanced Certificate Requests form page appears.
The Certificate Issued page appears.
A Certificate Installed page appears.
You can complete all of the preceding steps in this exercise from the Group Policy snap-in. In step 19 of this exercise, you choose Create rather than Add. The Create option creates the certificate and then allows you to assign the certificate to the group policy.
The Group Policy snap-in appears.
The Add Recovery Agent wizard appears.
The Select Recovery Agents screen appears.
The Find Users, Contacts, And Groups dialog box appears.
The Select Recover Agents screen appears.
The Completing The Add Recovery Agent wizard appears.
Administrator appears in the details pane of the Group Policy snap-in.
The Administrator Properties dialog box appears.
Notice that all purposes are enabled for this certificate. The only purpose currently available for this certificate is File Recovery.
The microsoft.com Properties dialog box appears.
The Active Directory Users And Computers snap-in appears.
The Administrator Properties dialog box appears.
The list of X.509 certificates published to this user account appears.
Notice that two certificates were published to the Administrator account and were issued by the Administrator account. The certificate listed as File Recovery under the Intended Purpose column is used to recover files encrypted with EFS if the original private key is lost or otherwise invalid.
In this exercise, you encrypt a folder using the Windows Explorer on Server01.
The My Computer window appears.
The Local Disk (C:) window appears.
The Document And Settings window appears.
The Administrator window appears.
The My Documents Properties dialog box appears.
The Advanced Attributes dialog box appears.
The My Documents Properties dialog box appears.
The Confirm Attribute Changes dialog box appears.
The My Documents Properties dialog box appears, and then the Applying Attributes status message box appears. When the operation has completed, the My Documents Properties dialog box closes.
Notice that the Attributes for the selected My Documents folder is Encrypted.
Chapter 9, "Managing Network Protocols", introduced IPSec. This chapter continues with the discussion of IPSec, providing more details about how IPSec is used to support public key security.
IPSec in Windows 2000 is designed to protect sensitive data on a TCP/IP network. IPSec is useful when the network between two communicating computers is not secure. It provides confidentiality, integrity, and authentication of IP traffic for each packet traversing the network.
When using IPSec, the two computers communicating over the network first agree on the highest common security policy; then each handles the IP Security at its respective end. Before sending data across the network, the computer initiating communication transparently encrypts the data by using IP Security. The destination computer transparently decrypts the data before passing it to the destination process. Because the data is passed down to and encrypted at the IP protocol level, separate security packages are not required for each protocol in the TCP/IP suite.
Using IPSec to encrypt all IP network traffic ensures that any TCP/IP-based communication is secure from network eavesdropping. Any routers or switches that are in the path between the communicating computers can simply forward the encrypted IP packets.
To ensure full compatibility with previous versions of Windows, a computer running Windows 2000 configured for IPSec sends the data without encryption to pre-Windows 2000 computers.
With Windows 2000 IPSec, you can create policies that define the type and level of security to be used during network communication.
Negotiation policies determine the security services used during network communication. The security protocol chosen for negotiation policies is the basis for the security services. For example, if the IP Authentication Header protocol is chosen, integrity, authentication, and anti-replay services are provided—but not confidentiality.
It is possible to set multiple security methods for each negotiation policy. If the first method is not acceptable for the security association, the service continues through an ordered list until it finds a policy it can use to establish the association. If the negotiation is not successful, the communication is established without IPSec.
IP filters direct actions based on the destination of an IP packet, what IP protocol is in effect, and the related ports that the protocol uses. Each IP packet is checked against the IP filter, and if a match is found, the properties of the associated security policy are used to send the communication. Filters need to be configured for both incoming and outgoing traffic.
Security policies are used to configure IPSec attributes. These policies are made up of associated negotiation policies and IP filters, and are associated with domain controller policies. Security policies define the type and level of security to use for any given IP network communication. An IP security policy can be assigned to the default domain policy, the default local policy, or a customized domain policy.
A computer logging on to a domain automatically obtains the properties of the default domain and local policies, including the IPSec policy assigned to the domain policy.
The Windows 2000 installation process installs the services, protocols, and drivers necessary for IPSec:
The ISAKMP and Oakly Key Management protocols are collectively referred to as IKE protocols.
During system initialization, the IPSec Policy Agent service retrieves IPSec polices from the Active Directory service. The IPSec Policy Agent service passes the policy information to the IPSec network driver and the IKE protocols. The IPSec Policy Agent service does not store policies locally; instead, it must retrieve them from the Active Directory store. The IPSec Policy Agent service also starts both the IKE protocols and the IPSec driver.
Using the information in the IPSec policy, the IKE protocols negotiate and establish a Security Association (SA) between computers. The Kerberos protocol service authenticates the identities of the communicating computers. Finally, the IKE protocols send the SA and key information to the IPSec driver.
This driver examines all IP packets for a match with an IP filter. If a match is found, the IPSec driver holds the packets in a queue while the IKE protocols generate the necessary SA and key to secure the packet. After the IPSec driver receives the information from the IKE protocols, the driver encrypts the IP packets and sends them to the destination computer.
In this example, User 1 on Computer A is sending data to User 2 on Computer B. IP Security has been implemented for both computers. Figure 27.11 provides an overview of the IPSec communication process. The numbered steps shown in the illustration are described below.
Figure 27.11 An example of the IPSec communication process
At the user level, the process of securing the IP packets is transparent and works as follows:
Windows 2000 extends security by supporting a number technologies that are based on public key security, including the SChannel authentication package, smart cards, Authenticode, the EFS, and IPSec. The SChannel authentication package implements SSL 3.0 and the TLS 1.0. SSL and TLS are flexible security protocols that can be layered on top of other transport protocols. Smart Cards are credit-card-sized devices that can be used to store a user's public key, private key, and certificate. Smart cards are a secure way to protect and control a user's keys instead of storing them on a computer. Authenticode technology allows software publishers to digitally sign any form of active content, including multiple-file archives. These signatures can be used to verify both the publishers of the content and the content integrity at download time. EFS is an extension to the NTFS file system that provides strong data protection and encryption for files and folders. The encryption technology is based on the use of public keys and runs as an integrated system service. IPSec in Windows 2000 is designed to protect sensitive data on a TCP/IP network. IPSec is useful when the network between two communicating computers is not secure. It provides confidentiality, integrity, and authentication of IP traffic per packet.