Public Key Infrastructure in Windows 2000

Authenticode
Microsoft's PKI offers a code-signing technology called Authenticode that ensures the integrity and origin of commercial and free software distributed over the Internet. Authenticode, based on digital signature technology, adds a digital signature, a code-signing certificate, and a time stamp into such software codes as Java applets, ActiveX controls, .dll files, executable files, cabinet files, and catalog files. Authenticode also verifies downloaded code before you run it on your system. To sign and verify code, Authenticode uses two techniques: code signing and code verification.

Before you can sign code to guarantee its integrity and origin, you must obtain a code-signing or software-publishing certificate from a CA. You can then use the Authenticode signing functions the ActiveX SDK provides to sign the code. You pass the code you want to authenticate through a hashing algorithm and use your private key to sign the hash, which results in a digital signature. You then build a signature block, which contains the digital signature and the code-signing certificate. Authenticode lets you time stamp the signature block based on the current date and time that a time stamping service provider, such as VeriSign, provides. Finally, you bind the time stamped signature block to the original software. Now you can publish the signed software on your Web site for download.

The ActiveX SDK also supplies a code-verification function to verify downloaded software before you execute it. Microsoft has incorporated this function in IE 3.0 and later versions. Before IE runs signed code, it will call up the code-verification function to check the signature, publisher's certificate, and time stamp. After verification, the code-verification function will display the name of the code, the name of the organization or person who published the code, when the publisher authenticated the code, and the name of the CA that issued the code-signing certificate. The user decides whether to trust the publisher. Screen 4, page 102, shows a sample code-verification display. The display confirms that the verified code is an ActiveX control to capture the product ID in the local computer, that Microsoft signed the code at 9:42 a.m. on July 16, 1998, and that VeriSign issued the code-signing certificate. When you click Yes in a code-verification display, your browser will install and run the verified code.

In IE, you can set up a security policy for Authenticode with four security levels: high, medium, low, and custom. The high level doesn't execute damaged code; the medium level warns you before running potentially damaged code; the low level always executes any code; and the custom level lets you choose security settings, such as to enable ActiveX or to disable Java applets. You can also define different levels for different security zones, such as the Internet, intranets, trusted sites, and restricted sites in IE.

Encrypting File System
Win2K introduces EFS, a new security feature, in NTFS. EFS lets you encrypt files and directories in a local or remote computer. Figure 4 shows how EFS uses public keys for data encryption, decryption, and recovery.

Before you can use EFS, you need to create a data recovery agent. You use Group Policy Editor in the Win2K domain in which you want to use EFS. The data recovery agent contains a pair of public keys. A domain's data recovery agent can recover encrypted data in any Win2K computers in the domain if an original file's owner loses a private key. You can create a local data recovery agent in a local computer if the computer doesn't belong to a domain.

When you encrypt a file, EFS randomly generates a file encryption key (FEK) and uses this FEK to encrypt the file. To encrypt the FEK, EFS uses your public key, which EFS retrieves from your certificate, and saves the encrypted FEK to the Data Decryption Field (DDF) along with the file.

If you don't have a certificate, EFS simply generates a pair of keys--­one public key and one private key--­for you. If multiple users share the file, EFS will use a user's public key to encrypt the FEK for that user and save each encrypted FEK to the DDF. EFS encrypts the FEK a second time using the data recovery agent's public key and inserts the encrypted FEK into the Data Recovery Field (DRF) of the file. The EFS process is transparent; you simply enable the file encryption attribute in the advanced attribute list of a file's properties in Windows Explorer.

When you access an encrypted file, EFS automatically decrypts and opens the file for you if you are on the DDF list. If you are not on the DDF list, EFS denies access. When EFS decrypts a file, it locates your private key, uses this key to decrypt the FEK in your DDF, and decrypts the file using the FEK. EFS uses the same method to recover data with the data recovery agent's private key.

Building Security on PKI
I've given you a brief outline of Microsoft's rich set of PKI solutions. Using these tools, your company can establish a comprehensive PKI that is powerful, flexible, and customizable. When Win2K arrives, I think you'll be pleased with the power you'll have to satisfy your business security needs and to build your network security on PKI in Win2K.