Windows Server 2003 Security Infrastructures: Core Security Features (HP Technologies)

In the following sections we look in detail at the core components of Windows Server 2003 and XP PKI: the certificate server, Active Directory, the CryptoAPI, certificates, and the Data Protection API.

13.4.1 Certificate Server

In this section we focus on the architecture of Microsoft’s Certificate Server; in Chapter 16 we return to the specific configuration options of Certificate Server.

The Windows Server 2003 certificate server provides the following core services: It receives and processes certificate requests, it identifies and validates certificate requests, it issues certificates according to the security policy, it renews and revokes certificates, it publishes certificates, it creates and publishes CRLs, and it logs all certificate and CRL transactions into a log database. A brand-new function of the Windows Server 2003 CA is that it can also take care of secure private key archival.

Certificate Server architecture

The architecture of the Microsoft Certificate Server is illustrated in Figure13.2. It is largely identical to the one that was used in the previous editions of the Certificate Server. An architectural feature not available in previous versions is that the CA database layout has been modified to let the CA cope with private key archival and recovery.

Figure 13.2: Certificate Server architecture.

At the heart of the Windows Certificate Server sits an engine (certsrv.exe) that generates certificates and CRLs and directs the message flow between the other components. The engine communicates with three important modules: the entry, policy, and exit module.

• The entry module accepts PKCS10 and CMC formatted certificate requests. Its only job is to place these requests in a queue for treatment by the policy module.

• The policy module implements and enforces the CA policy rules as set forward by the CA administrator. It informs the CA engine about the layout of a certificate and decides if a certificate request should be issued, denied, or left pending. To make the latter decision and to retrieve certificate layout information, the policy module can call on information stored in a directory or database. Windows Server 2003 comes with a policy module (called certpdef.dll) that supports two policy types: the enterprise policy and the stand-alone policy. Details on the two policy types are discussed later in this chapter. To check out the policy module installed on your CA, look at its properties (Policy Module tab) in the Certification Authority MMC snap-in.

• The exit module distributes and publishes certificates, certificate chains, CRLs, and delta CRLs. The exit module can write PKI data to a file or transport it across HTTP or RPC to a remote location. The Windows Server 2003 CA can support multiple exit modules. This enables it to publish and distribute certificates, certificate chains, CRLs, and delta CRLs to different locations in parallel: LDAP directories, file shares, Web directories, or even ODBC- compliant databases. The default Windows Server 2003 CA exit module (called certxds.dll) comes with LDAP, FTP, HTTP, and SMTP support. The last protocol was not supported in the Windows 2000 CA. It allows the CA to automatically send notification messages to PKI users and administrators. To check out the exit modules installed on your CA, look at its properties (Exit Module tab) in the Certification Authority MMC snap-in.

The exit and policy modules are both customizable and replaceable. If the policy module or the exit module does not correspond to the needs of an organization, it can develop modules in C++ or Visual Basic (VB) and plug them into the CA architecture. All this is documented in the Windows Server 2003 platform SDK.

The policy and exit modules can be configured using the Certification Authority MMC snap-in or using the certutil command-line utility. Using the properties of the CA-object in the Certification Authority MMC snap- in, you can do things like add another exit module, configure X.509 certificate extensions [CRL and delta CRL distribution (CDP) and Authority Information Access (AIA) points], and configure CRL and delta CRL publication parameters. I will return to the configuration capabilities of the certutil utility later in this book.

The Certificate Server obviously has its proper database and administration interfaces. It also interacts with entities known as intermediaries to communicate with PKI clients and the CryptoAPI to access the CA private key storage provider.

• The certificate server uses a database to store certificate transactions and status information, certificates, and optionally archived private keys. The database (<CAName>.edb) is by default located in the system32\certlog folder. The Certificate Server engine communicates with its database through the certdb.dll. In the Windows 2000 release of Certificate Server, Microsoft changed its database technology to JET Blue. The same technology is used for Active Directory and the Exchange databases. This switch gave the Windows 2000 CA a scalability injection.

• Windows Server 2003 CA management is primarily done from the Certification Authority MMC snap-in. Another option is to use the certutil.exe command-line utility. Both administration tools communicate with CA engine using the certadm.dll.

• Applications that help the client in generating correctly formatted PKCS10 or CMC certificate request files are known as intermediaries or Registration Authorities (RAs). An intermediary or RA gathers user-specific and request-specific data that are required for a valid certificate request. For example, a request that is sent to a Windows Server 2003 Enterprise CA should mention a certificate template. An intermediate can add a template specification to the request. Intermediaries are bound to a specific transport protocol. Thanks to this, the CA engine does not need to deal with different transport providers.

  Examples of Windows Server 2003 intermediaries are the Web enrollment pages—an HTTP intermediary—and the MMC Certificates snap-in, which calls on the Certificate Request Wizard—an RPC intermediary. The HTTP intermediary calls on the xenroll.dll to generate private keys on the client machine and the scenroll.dll to generate private keys on a smart card. The RPC intermediary calls on the certcli.dll to perform these tasks. Examples of third-party RA software are discussed later in this chapter.

• For all cryptographic functions—including accessing and using the CA’s private key—the CA calls on the CryptoAPI (CAPI). The CA’s private key can be stored on hard disk or on a dedicated hardware device [such as a Hardware Security Module (HSM)].

CA installation modes

When you install a Windows Server 2003 Certificate Server, you have the following installation options: You can install it as a root or a subordinate CA, or you can install it as an enterprise (AD integrated) or stand-alone CA (non-AD integrated). Installing the Certificate Server in Enterprise mode provides full integration with Active Directory. It activates the Enterprise mode of the Windows Server 2003 CA policy module. Let’s look now at what this really means and how this is different from a CA installed in stand-alone mode.

Comparing the two CA installation modes

Installation requirements To install a CA in enterprise mode, two requirements must be met:

1. The account installing the CA should be an Enterprise administrator and a domain administrator of the root domain of the AD forest.

2. The server on which the Enterprise CA is installed should be a member of a domain with a functioning AD.

If one of these two conditions is not met, the enterprise mode installation options will be grayed out during the CA installation, and you will only be able to install the CA in stand-alone mode.

To install a stand-alone CA, no AD is required; you can install it on a stand-alone server, member server, or domain controller. Also, there is no need for the account performing the installation to be an enterprise or domain administrator—local machine administrator permissions are sufficient. If you do install a stand-alone CA using enterprise administrator privileges, the CA will offer some additional features. For example, if an enterprise administrator installs it on a member server that is joined to the domain, the stand-alone CA will publish the certificates it issues to the AD.

Use of certificate templates An enterprise Certificate Server uses the certificate templates that are stored in the AD configuration naming context. Certificate templates define the content and characteristics of a certificate. Windows Server 2003 PKI supports version 2 certificate templates. Contrary to version 1 templates, version 2 templates are fully customizable. Certificate templates also provide a way to control which certificate types an enterprise CA can issue and which users can request which certificate type to an enterprise CA. Certificate templates are explained in detail in Section13.4.4, “Certificates.”

A stand-alone CA cannot use AD certificate templates. As a consequence, you cannot set which user can get which certificate type(s) from it. By default, a stand-alone CA can only issue Web authentication (SSL, TLS), e-mail protection (S/MIME), server authentication, code signing, time-stamp signing, and IPsec certificates. You can, however, modify the stand-alone CA’s Web interface (to list other certificate types) or simply request other certificate types using special OID values that are stored in a certificate’s Extended Key Usage (EKU) X.509 extension.

Information retrieval for certificate requests An enterprise CA retrieves user information from the AD during certificate enrollment. This information is used to populate certain certificate fields. For example, a certificate issued by an enterprise CA contains a reference to a user’s user principal name (UPN) in the certificate’s SubjectAltName X.509 field.

Because a stand-alone CA has no access to AD, user identification information that is required for the certificate must be filled in manually by the user on the CA’s enrollment Web site.

For both enterprise and stand-alone CAs, you can change the default values that are added to a certificate request at enrollment time. You can do so by editing the certdat.inc file that is located in the %SystemRoot%\ system32\certsrv directory. You can change the default values for the following certificate entries: sDefaultCompany, sDefaultOrgUnit, sDefault- Locality, sDefaultState, and sDefaultCountry.

Automated certificate enrollment support An enterprise certificate server supports automated certificate enrollment, or in short certificate autoenrollment. In Windows Server 2003, the latter feature has been extended to cover both users and machines. Automated certificate enrollment is explained in greater detail in Chapter 15.

A user who wants a certificate from a stand-alone CA has to start the enrollment process himself or herself. No automation is provided.

Certificate request approval An enterprise Certificate Server can support automatic or manual certificate request approval. Request-handling properties can be set in the properties of an enterprise CA (use the properties of the policy module) or in the properties of a version 2 certificate template (use the Issuance Requirements tab). In the first case it will apply to all certificates the CA issues, but in the second case only to one particular certificate type (as defined in the template).

The same options are available for a Windows Server 2003 stand-alone CA. The only difference is that a stand-alone CA cannot use certificate templates, and as a consequence request-handling properties cannot be set for individual certificate templates.

Certificate and CRL publication An Enterprise CA uses the Active Directory to store and publish certificates, CRLs, and delta CRLs. Each certificate published in the AD is automatically mapped to the Windows account of its requestor. The certificate is added to the multivalued usercertificate attribute of the user object. Not every certificate generated by an enterprise CA is automatically published in the AD. Examples of certificates that are not automatically published are an enrollment agent or a CTL signing certificate.

A stand-alone CA can publish the issued certificates to AD, but not automatically as a part of the certificate enrollment process. You can obviously publish the certificates manually to the AD.

Centralized key archival An enterprise CA supports centralized key archival in the CA database, a standalone CA doesn’t.

Conclusion

Enterprise mode typically targets enterprise certificate users that have an AD user account and that authenticated to your AD infrastructure using the Kerberos protocol. Stand-alone mode, on the other hand, is clearly targeting external users (like extranet users) that do not have an internal Windows account.

Table 13.1 compares the default characteristics of a Windows Server 2003 stand-alone and enterprise CA.

Registration authorities

In large PKI setups, PKI users use a Registration Authority as the primary point of contact for a CA. An RA typically deals with PKI user identification and enrollment. Like its predecessors, Windows Server 2003 PKI does not include a true Registration Authority function.

Windows Server 2003 supports some limited RA functionalities through special “Enrollment agent” certificates (OID 1.3.6.1.4.1.311.20.2.1—Certif- icate Request Agent). Enrollment agent certificates can be used for:

• Smart card bulk enrollment: Administrators with a special Certificate Request Agent certificate can bulk enroll users’ certificates on smart cards and act as a registration authority for smart card certificates.

• Integration with the Exchange Key Management Server (KMS): If your organization has implemented Exchange advanced mail security (S/MIME) in combination with Microsoft Certificate Server, the Exchange Key Management Server acts as an RA. It identifies users and passes the certificate requests to the Windows 2000 CA.

Advanced RA support for Windows Server 2003 PKI is available from third-party software vendors. Some examples are mentioned in Table 13.2, which does not provide an exhaustive list of RA software—also, it is not the goal of this book to provide a feature comparison between the different RA software products.

The reason why Microsoft did not include an RA function with the Windows Server 2003 OS probably has to do with the high level of customization that is required to fit an RA to an organization’s needs. One organization may require that the RA is linked to its ERM system, another one may require smart card enrollment and life-cycle management integration, and yet another one may require integration with its building access control mechanism. Some regions also have special legal requirements for an RA function: The European Union, for example, imposes very strict rules for the implementation of an RA that is dealing with qualified certificates and certificates that are used for advanced digital signatures.

13.4.2 Active directory

A PKI uses a directory to store certificate revocation lists (CRLs), delta CRLs, user, CA, and cross-certification certificates. When setting up a Windows Server 2003 PKI, the Active Directory is an obvious directory choice. AD is the only possible directory option if you want to take advantage of some typical Window.NET AD-based PKI features (like the use of

Windows Server 2003 PKI in general is very tightly integrated with AD. A nice example of this integration is the use group policy objects to distribute trusted CA information to Windows 2000 or Windows XP Professional workstations. As explained in the previous sections, this integration is very tight when deploying Windows Server 2003 enterprise Certificate Servers. In that case Windows Server 2003 PKI also uses AD to store CA- and PKI- related configuration information.

PKI-related AD entries

Table 13.3 shows the Windows Server 2003 PKI-specific information that is added to the Active Directory and where it is created. Compared to Windows 2000 PKI, AD contains two brand-new PKI-related containers: the KRA and OID containers. Also, Windows Server 2003 PKI comes out of box with more predefined certificate templates: 29 instead of 24 in Windows 2000 PKI. Table 13.4 shows when this information is added to the Active Directory.

The official PKIX LDAP and directory schema extensions can be found in the IETF’s RFC 2587 and 2256 and the Internet draft titled “InternetX.509 Public Key Infrastructure LDAP Schema and Syntaxes for PKIs.” RFC 2587 describes some of the PKI subschema applicable to LDAPv2 servers. RFC 2256 describes some of the PKI-related subschema elements for LDAPv3 servers. The Internet draft supercedes both RFC2587 and RFC 2256 and provides the complete PKI subschema for LDAP v3 servers.

The AIA container contains a CA object for every CA (root or subordi- nate, enterprise or stand-alone CAs) that is located on a server that is a member of the Windows Server 2003 forest. Every CA object has a CaCertificate attribute holding the CA certificate and the CA certificate history. The Authority Information Access (AIA) certificate is used during certificate validation to locate CA certificates. Every certificate issued by a Windows Server 2003 enterprise CA contains an LDAP pointer to the CA object in the AD AIA container.

The CDP container is the Active Directory CRL and delta CRL Distribution Point (CDP) that allows PKI users to download the latest CRLs and delta CRLs from AD. The CDP container contains one subcontainer for every Windows Server 2003 server in the forest that has a CA installed. Every server container holds a CDP object that is named after the CA running on that server. The CDP object holds CRLs in its CertificateRevocationList attribute and delta CRLs in its DeltaRevocationList attribute. The CDP object is created independent of whether the CA is a root or a subordinate, an enterprise or a stand-alone CA. Every certificate issued by a Windows Server 2003 enterprise CA contains an LDAP CDP pointer to an AD CDP object.

The Certificate Templates container contains all certificate template definitions—both for version 1 and version 2 certificate templates. They are added to the AD’s configuration naming context when the first enterprise CA is installed in the Windows Server 2003 forest. The ACL that is set on the template objects allows or disallows a user or group to enroll and/or autoenroll for a particular certificate type. Note that because a template’s definition and ACL settings are part of the configuration naming context, they can be defined only once, for an entire forest.

The Certification Authorities container holds a CA object for every root enterprise or stand-alone CA in the Windows Server 2003 forest. Every CA object holds the CA certificate and certificate history in its CaCertificate attribute. The Certification Authorities container holds all CAs that are considered trust anchors for all the users in a Windows Server 2003 forest. The concept of trust anchors is explained in more detail in Chapter 14.

The Enrollment Services container contains a PKIEnrollmentService object for every CA (root or subordinate, enterprise or stand-alone CAs) in the Windows Server 2003 forest. The object is named after the CA to which it is linked. Every object’s “certificate templates” attribute lists the certificate templates that a particular CA supports and for which PKI users can enroll at that CA. For a stand-alone CA this attribute is empty. The Enrollment Services container can be used by Windows PKI-enabled applications to locate a machine that is hosting a CA in a Windows Server 2003 forest. The permissions that are set on a CA’s PKIEnrollmentService object are critical in order for users or machines to be able to locate a CA. If a user or machine does not have read permission on this object, it will not be able to find the CA.

The KRA container contains an msPKI-PrivateKeyRecoveryAgent object for every CA (root or subordinate, enterprise or stand-alone CAs) in the Windows Server 2003 forest. The object is named after the CA to which it is linked. Every object holds the certificates of the key recovery agents that are defined on a particular CA in its usercertificate attribute.

The NTAuthCertificates Object is used to determine which enterprise CAs in a Windows Server 2003 forest are authorized to issue smart card logon and other logon certificates. The authorized CAs’ certificates are stored in the NTAuthCertificates object’s CaCertificate attribute.

The OID container contains all PKI-related object identifiers (OIDs) and their characteristics that are defined in a Windows Server 2003 forest. They are added to the AD’s configuration naming context when the first enterprise CA is installed in the Windows Server 2003 forest.

If a CA is removed from your Windows 2000 or Windows Server 2003 forest, the CA object in the Enrollment Services container will be removed. All of the other AD entries remain. This will make it impossible for PKI clients to request new certificates from the CA, while still giving them the ability to retrieve the CA’s certificate, CRLs, and delta CRLs. If you want to remove all AD entries related to a particular CA from the AD, use the following certutil command-line command:

certutil –delds <CAName>

User certificates that an enterprise CA automatically publishes to AD are stored in a user object’s multivalued “UserCertificate” (as specified in the PKIX LDAP schema extensions). User certificates stored in the AD affect the size of the AD database. The average size of one certificate is about 1,200 bytes.

Querying AD for PKI-related information

To look at the PKI and CA related entries in the AD configuration naming context of your Windows Server 2003 forest, you can use several tools:

• The certutil command-line tool with the “-v -ds” switch

• The Sites and Services MMC snap-in: All PKI-related configuration naming context entries are visible from the Public Key Services container (as illustrated in Figure 13.3).

  Figure 13.3: Querying AD for PKI-related information using the Sites and Services MMC snap-in.

• The ADSIEdit tool (coming with the Windows Server 2003 Support tools)

• The LDP tool (coming with the Windows Server 2003 Support tools)

• The PKIView tool (coming with the Windows Server 2003 Resource

Kit): This tool can retrieve the content of the AIA, CDP, KRA, Certification Authorities, Enrollment Services, and NTAuthCertificates AD containers (as illustrated in Figure 13.4).

Figure 13.4: PKIView tool.

To query AD for user certificates, you can use the Search\For People… function available from the Windows Server 2003 or Windows XP start menu. The last tab of the user object properties is named Digital IDs and contains all the user certificates that are published in AD. The same inter- face can be used to export certificates to a file; afterward you can import the certificate-file into your personal certificate store.

13.4.3 CryptoAPI and cryptographic service providers

The CryptoAPI is an Application Programming Interface (API) that comes bundled with the Windows Server 2003 and XP operating systems. It enables programmers to add cryptography-based security services, such as authentication, confidentiality, and integrity protection, relatively easily to their applications. It also enables them to interact with certificates, private keys, and their secure storage providers. What is most important is that CryptoAPI hides the implementation details of the complex cryptographic algorithms to the programmer.

Late 2003 Microsoft released the CAPImon tool. This tool can be used to capture and display the calls PKI-enabled applications make to the CryptoAPI. The tool can be very useful for PKI troubleshooting (for example, to troubleshoot certificate chain validation or revocation checking). You can download the tool for free from the Microsoft Downloads website at http:// www.microsoft.com/downloads.

CryptoAPI architecture

The CryptoAPI architecture (which is illustrated in Figure 13.5) consists of a programmatic interface, a set of software modules, and a set of pluggable Cryptographic Service Providers (CSPs). The CryptoAPI and its interfaces are fully documented in the Windows Server 2003 platform SDK.

Figure 13.5: CryptoAPI architecture.

The software modules can be categorized in software modules providing certificate-related functions and others providing message-related functions:

• The modules providing message-related functions can be called to generate cryptographic keys, perform hashing, digitally sign data, or perform data encryption and decryption. They also deal with message encoding and decoding services to and from the PKCS7, PKCS10, and ASN.1 message formats.

• The modules providing certificate-related functions deal with certificate management services: They can be called to generate, manage, and validate certificates, to interact with the certificate stores, and to encode and decode certificates.

The CryptoAPI functions can also be called through CAPICOM. CAPICOM is a COM client that can perform cryptographic functions using ActiveX and COM objects. CAPICOM can be used from applications created in Visual Basic, Visual Basic Scripting Edition, or C++. CAPICOM version 2.0 includes support for the generation and verification of digital signatures, encryption and decryption of data, certificate store searching, hashing, and the AES algorithm. CAPICOM is not available from a default Windows Server 2003 installation. CAPICOM version 2.0.0.3 (cc2rinst.exe) can be downloaded from the Windows Platform SDK Redistributables Web site at http://www.microsoft.com/ downloads/details.aspx?displaylang=en&familyid=860ee43a-a843-462fabb5-ff88ea5896f6.

Cryptographic Service Providers (CSPs) are software libraries that contain implementations of cryptographic algorithms and ciphers. The use of libraries creates a pluggable architecture: Third-party vendors can plug their proper CSP in the OS and provide security services to applications.

CSPs can be implemented in both hardware and software. A hardware- based CSP implementation provides better security than a software-based implementation. This is because hardware security devices such as smart cards, security tokens, and hardware security modules (HSMs) typically offer better protection against tampering.

To embed a CSP into Windows Server 2003 or XP, it must be cryptographically signed by Microsoft. How to do this is described in the CSP Development Kit available from Microsoft.

A CSP does more than just providing the implementation of a cryptographic cipher. CryptoAPI also deals with sensitive key (session keys and private keys) storage. It stores them into key databases that are embedded in the CSPs. The CSP key database contains a key container for each user, named after the user’s logon name. The key containers can be stored in the registry, on the file system, or on a smart card. The key containers can never be accessed directly: They can only be accessed through the CryptoAPI and by using the appropriate CryptoAPI functions.

CSPs located on different machines cannot directly communicate. It happens though that keys need to be exchanged between different CSPs. CryptoAPI allows sensitive keys to be exported from a CSP’s key container and transported in a secure way to another CSP. You can, for example, export and import certificates and private keys between different CSP key containers using a PKCS12-formatted file. When exporting a private key to a PKCS12 file, CryptoAPI forces you to protect it using a password. This password functions as a symmetric key and provides confidentiality protection for the exported private key.

Cryptographic service providers

Table 13.4 gives an overview of the CSPs that come preinstalled with Windows Server 2003 and Windows XP. To get an overview of all CSPs available on your machine, query the following registry folder: HKEY_LOCAL_ MACHINE\Software\Microsoft\Cryptography\Defaults\Provider.

Windows Server 2003 and Windows XP come preinstalled with the enhanced CSPs. The Enhanced CSPs include support for 56-bit DES, 3 DES (112-bit 2key and 168-bit 3key), 16,384-bit RSA, 128-bit RC2, and RC4. The Base CSPs only support 512-bit RSA, 40-bit RC2, and RC4. In Windows 2000, users had to install the High Encryption Pack to get access to these CSPs. These enhanced CSPs are only available to users living in countries to which the export of strong crypto from the United States is permitted and to organizations that are on the exception list of the U.S. crypto export regulations. If you still have Windows 2000 clients, the High Encryption Pack for Windows 2000 can be downloaded from http://windowsupdate.microsoft.com. In Windows Server 2003 and XP, Microsoft also added a new CSP implementing the AES algorithm, the new U.S. standard for symmetric encryption.

Table 13.5 shows that Windows Server 2003 and XP contain both hardware and software implementations of CSPs. So far, Windows Server 2003 and XP include by default three smart card vendors’ CSPs: Infineon, Gem- plus, and Schlumberger.

Microsoft received a FIPS 140-1 Level 1 security certification for the following CSPs:^[2] the MS Enhanced Cryptographic Provider, the MS Enhanced DSS and Diffie-Hellman Cryptographic Provider, and the MS Enhanced RSA and AES Cryptographic Provider. If your IT environment requires a higher level of FIPS 140-1 compliance, have a look at the hardware-based private key storage solutions discussed at the end of this chapter.

13.4.4 Certificates

In this section we focus on the characteristics of the certificates that are generated by Windows Server 2003 Certification Authorities. Critical to understanding the Windows Server 2003 and XP certificate layout are certificate templates. We also look in detail at how certificates are stored on the Windows Server 2003 and XP OS platforms.

Certificate layout and viewer

A certificate’s format is defined in the ITU-T X.509 version 3 standard. This standard was later adopted by the IETF in RFC 2459. A copy of the ITU standard can be downloaded from the ITU-T Web site at http:// www.itu.int/ITU-T/. The RFC is available from http://www.ietf.org. Appendix 1 contains an overview of the X.509 certificate version 3 and certificate revocation list (CRL) version 2 format.

Three key tools when dealing with certificates in Windows Server 2003 and XP are the certificate viewer and the Certificate Templates and Certificates MMC snap-ins. The latter two are covered in detail in the following sections. The certificate viewer displays a certificate’s content (as illustrated in Figure 13.6). The Windows default certificate viewer is automatically started when you double-click a certificate file. The first tab of the viewer shows general information such as the applications for which the certificate can be used, the subject name, the issuer name, the validity period of the certificate, and whether the certificate has a corresponding private key stored in the user’s profile. The second tab shows all X.509 certificate entries: the standard fields and the critical and noncritical certificate extensions. The third tab shows the certification path and the certificate status.

Figure 13.6: The Windows certificate viewer.

Certificate templates

To let a CA cope with different certificate types, Microsoft has chosen to implement a flexible and modular architecture. The characteristics of a certificate—including the applications for which it can be used—are defined in a certificate template that is stored in the AD. Windows Server 2003 comes with support for version 2 certificate templates. The key difference between V1 and V2 templates is that V2 templates can be modified. Thanks to the support for V2 templates, a CA administrator can now also create its own templates, reflecting the certificate needs of the organization.

Certificate templates can also be used to define an enterprise CA’s certificate issuance policy.

• You can use them to set the certificate types a CA can issue. This is done by loading the appropriate templates in the CA’s policy module. To do so use the Certification Authority MMC snap-in, right-click the Certificate Templates container, and select New\Certificate Template to Issue.

• On the Windows Server 2003 AD forest level, you can use them to set which users can enroll and/or autoenroll for which certificate types. Like any other AD object, certificate templates have an ACL you can use to set which users can enroll and/or autoenroll for a particular certificate type. To set the ACLs,^[3] use the Certificate Templates MMC snap-in (use the security tab in the properties of a certificate template).

Because Windows stand-alone CAs lack AD integration, you cannot use certificate templates to customize a stand-alone CA’s issuance policy.

To administer certificate templates in Windows Server 2003 you must be a member of the Enterprise Admins group or the Domain Admins group of the forest root domain. In Windows 2000 only members of the Domain Admins group of the root domain can administer certificate templates.

Certificate templates are stored together with their properties in the system registry of servers hosting a Windows Server 2003 CA (HKLM\Software\Microsoft\Cryptography\Certificatetemplatecache) and in the Active Directory configuration naming context (cn=certificate templates, cn=public key services, cn=services, cn=configuration).

To administer version 2 certificate templates, use the Certificate Templates MMC snap-in (illustrated in Figure 13.7). You can invoke the Certificate Templates snap-in from the Certification Authority MMC snap-in by selecting the Certificate Templates folder, right-clicking it and selecting Manage. A subset of a certificate template’s definition is displayed in the MMC Certification Authority snap-in: Right-click a template in the Certificate Templates container and select properties.

Figure 13.7: The Windows Server 2003 Certificate Templates MMC snap-in.

Support for version 2 certificate templates requires specific AD schema extensions. This is not a problem in a native Windows Server 2003 environment where all Domain Controllers (DCs) are running the Windows Server 2003 Enterprise Server OS. If you have a mixed Windows Server 2003–Windows 2000 domain controller environment, you can extend the AD schema using the adprep.exe utility (use the /forestprep switch), which is available from the Windows Server 2003 CD. Also, in this case at least, Windows 2000 Service Pack 3 will be required on the Windows 2000 DCs. Certificates that are rooted on version 2 certificate templates can also only be issued from a Windows Server 2003 Enterprise or Datacenter edition CA installation.

From a PKI client point of view, all clients can enroll for certificates that are based on V2 templates from a CA’s Web enrollment interface. Enrollment for a certificate that is based on a V2 template from the Certificates MMC snap-in can only be done from a Windows XP or Windows Server 2003 OS platform. A user running the Windows 2000 OS can only request certificates that are based on V1 templates from the Certificates MMC snap-in.

Default certificate templates

Table 13.6 lists the default certificate templates that are loaded to AD when you install the first Windows Server 2003 enterprise CA in your AD forest. For every template it lists the supported applications (in the EKU/Application Policies column), the OIDs corresponding to the different applications (in the Corresponding OIDs column), whether the corresponding certificates are automatically published in Active Directory (in the AD? column), and the certificate template version (1 or 2) (in the Version column). The names between brackets in the first column are the templates’ registry names: This name sometimes differs from the template name and is interesting to know when you are requesting certificates using the certreq command-line utility.^[4]

The certificate templates that are marked as offline are certificates for which the CA will not retrieve user information from the Active Directory at certificate request time. This means that the requestor has to provide the information himself. Offline templates are used for non-Windows PKI clients, like non-Microsoft IPsec clients or non-AD integrated Web servers. Because these entities do not have an AD object entry, their information cannot be retrieved from AD. Offline templates can also be very useful to deploy IPsec machine certificates to clients that are not part of a Windows domain.

Table 13.6 also shows that Windows Server 2003 supports both single- use (having a single OID) and multiple-use certificates (having multiple OIDs).

* The applications that a certificate supports are kept in the Extended Key Usage (EKU) certificate extension (for certificates based on V1 templates) or in the Application Policies certificate extension (for certificates based on V2 templates).

Certificate template properties

Table 13.7 provides an overview of the certificate template properties that can be administered from a template’s properties dialog box in the Certificate Templates MMC snap-in. The properties dialog box is illustrated in Figure 13.8: It shows the General tab in the cross-certification authority certificate template’s properties. Note that you can only modify version 2 certificate template properties. The properties of version 1 certificate templates can be viewed from the MMC snap-in, but they cannot be changed.

Figure 13.8: General tab in the cross-certification authority certificate template’s properties.

The meaning of the different certificate template permissions (configurable from the security tab in a template’s properties) can be summarized as follows:

• The Read permission allows the template to be discovered by a user.

• The Enroll permission allows a user to enroll for a particular certificate type.

• The Full Control permission allows a user to set or modify the permissions of a template.

• The Autoenroll permission is set when a user or computer can automatically enroll for a particular certificate template.

• The Write permission allows a user to modify the properties of a certificate template.

Certificate storage

In Windows, certificates are stored in a PKI entity’s personal certificate store. In the following section we go more in detail on architecture of the Windows Server 2003 and XP certificate stores. Besides certificates, an entity’s certificate store can also contain Certificate Trust Lists (CTLs), Certificate Revocation Lists (CRLs), and delta CRLs. Each Windows Server 2003 and XP user, machine, and service has its proper certificate store.

Figure 13.9 illustrates the certificate store architecture. As mentioned in Section 13.4.3, one of the CryptoAPI’s tasks is certificate management. CryptoAPI provides tools to attach certificates to messages and to store, retrieve, delete, list, and verify certificates.

Figure 13.9: Windows Server 2003 and XP physical and logical certificate stores.

The Windows Server 2003 and XP certificate store is divided into two abstraction layers: the logical certificate store and the physical certificate store. The purpose of this architecture is to abstract physical certificate storage from logical certificate categories. A Windows PKI user should not bother about where a certificate is stored physically but rather about what he or she can do with it and to what category of PKI entity it belongs. The Windows certificate store architecture provides ways to make the content of multiple physical stores visible in one logical store or, the other way around, to provide content inheritance from one physical store to multiple logical stores.

Table 13.8 and Figure 13.9 show the different logical and physical certificate containers available in Windows Server 2003 and XP. Table 13.8 also shows in which PKI entities’ certificate stores these containers are available: user, machine, or service entities. The name in parentheses in the first column is the corresponding registry name for the logical store containers.

To look at the content of a user, machine, or service certificate store and its different containers, use the MMC Certificates snap-in. A user can also use the Lightweight certificate viewer. The latter is accessible from the Internet Options/Content/Certificates menu in Internet Explorer.

By default, the MMC snap-in only shows the logical certificate containers. If you want, you can also see the physical certificate containers. To do this, select Options in the MMC View menu, and select the Physical certificate stores checkbox. To look at the user or machine certificate store from the command prompt, you can use the certutil command-line utility: Use it with the -store switch to display the machine certificate store; with the -user -store switches to display the user certificate store; and replace the -store with –verifystore switch if you not only want to list but also to verify the certificates in a store. Certutil is only available on Windows Server 2003 platforms.

Windows Server 2003 and XP automatically archive expired and renewed certificates and their private keys in the certificate store. This happens as part of the autoenrollment process. Archiving enables a user to decrypt old documents, even if the original certificate has expired or been renewed. To look at the archived certificates that are part of an entity’s certificate store, select Archived certificates in the view options of the MMC certificates snap-in. The same menu contains a checkbox to look at the certificates in an entity’s certificate store, based on the purpose or application for which they can be used (as illustrated in Figure 13.10).

Figure 13.10: Classifying certificates in a certificate store based on certificate purpose.

In the following sections we look in more detail at the physical and logical certificate store layers.

Logical certificate stores

Figure 13.11 shows the logical certificate store layer as you can view it from the Certificates MMC snap-in. Let’s run through the different default^[5] containers and look at their content:

• The Personal container contains the certificates that are stored in a user’s profile. Certificates in this folder have their corresponding private key stored in a secured user portion of the system registry (which is also a part of the user profile).

  Figure 13.11: Viewing logical certificates stores from theCertificates MMC snap-in.

• The Trusted Root Certification Authorities container holds by definition only self-signed root CA certificates. In practice, however, non- root CA certificates can also be added to this store. These CAs can be internal Windows 2000 CAs as well as CAs that are external to the company. This container is also referred to as the root store, which basically means that the certificates in this store are considered trust anchors. PKI trust and trust anchors are discussed in more detail in Chapter 14.

• The Enterprise Trust container holds Certificate Trust Lists (CTLs). CTLs are signed lists containing CA certificates. They are automatically downloaded to Windows Server 2003 or XP clients using GPOs. The CA certificates that are part of a CTL are considered trust anchors if the CTL signing certificate is valid.

• The Intermediate Certification Authorities container holds by definition only intermediate CA certificates and their CRLs and delta CRLs. Again, in practice you can also add root CA certificates to this store. These intermediate CAs can be internal Windows 2000 CAs as well as CAs external to the company. The certificates in the Intermediate Certification Authorities store are not trust anchors. If they are marked as trustworthy, this is because their certificate chain contains the certificate of a CA that is kept in the Trusted Root CA or Third- Party Root CA container or in a valid CTL.

• The Active Directory User Object container holds user certificates that are published in the Active Directory. In AD certificates are stored in a user object’s usercertificate attribute. This store only exists for user accounts: It does not exist for machine or service accounts.

• The Trusted Publishers container (previously known as the SPC container) holds Software Publisher Certificates. These certificates are used to verify code that was signed using the Authenticode code-signing technology.

• The Untrusted Certificates container holds certificates that are not trustworthy. The presence of this container (which did not exist in Windows 2000) is Microsoft’s reaction to an incident that took place in 2001 where a malicious person obtained a certificate for Microsoft’s identity.

• The Third-Party Root Certification Authorities container holds theoretically only third-party root certificates and CRLs. Again, in practice you can also add root CA certificates to this store. Like the Trusted Root Certification Authorities container, the certificates in this container are by default considered trust anchors. Unlike the Trusted Root Certification Authorities, the certificates in this container can also not be considered trust anchors. The latter is controlled using a Group Policy Object setting that is explained in more detail in Chapter 14.

• The Trusted People container holds certificates of people who are explicitly marked as trustworthy. These are typically self signed certificates that do not chain to a trusted root CA.

• The Other People container holds the certificates of people with whom a user shares encrypted documents such as S/MIME secured e-mail messages. It is the general cache for certificates that do chain to a trusted root CA.

• The Certificate Enrollment Requests container holds certificate request files. These files are created when a user is requesting a certificate to a stand-alone Windows 2000 CA or when an enterprise CA goes offline during a certificate enrollment request.

Knowing all this, you can perform the following operations on the level of the MMC Certificates snap-in:

• Publish user certificates to the Active Directory. The MMC certificates snap-in has built-in drag-and-drop functionalities. To publish one of your certificates to AD, simply pull it to the Active Directory User Object container.

• Trust or untrust root CA certificates. To untrust a CA certificate, simply cut it out of the Trusted Root Certification Authorities container and paste it into the Untrusted Certificates container. From a security point of view it is a best practice to move all CA entries that Microsoft put in the OS from the Trusted Root Certification Authorities to the Untrusted Certificates container, unless you implicitly trust Microsoft to embed trustworthy trust anchors in your software.

New to Windows Server 2003 is that in a domain environment the user’s ability to make his or her proper root CA trust decisions can be controlled by the domain administrator: The latter is controlled using a GPO setting and is explained in more detail in Chapter 14.

Physical certificate stores

Figure 13.12 shows the physical certificate store layer as you can view it from the MMC Certificates snap-in. Let’s run through the different containers and look at their content:

Figure 13.12: Viewing physical certificates stores from theCertificates MMC snap-in.

• The Registry container is an entity’s personal certificate and CTL store. For a user it is part of the user portion of the system registry, which is part of the user’s profile. The Registry container holds both certificates that have their corresponding private key stored in the user profile and others that have not. The Trusted Root Certification Authorities part of this container on the user level is also known as the user’s root store. Because certificates (and private keys) are stored in the user profile, they can be made accessible from any computer the user logs on to if your environment supports roaming profiles.

• The Local Computer container holds the local machine’s certificate, CRL, delta CRL, and CTL store. It is part of all users’ user profiles. You may have noticed in Table 13.8 that user and service accounts have a physical local computer container for most of the logical stores. This is a very nice feature because it takes away unnecessary duplication of certificates, CRLs, and CTLs. For example, external root CA certificates should not be stored in every certificate store. They are stored once in the machine certificate store, and automatically a pointer to this store is added in every other user and service’s certificate store that is logging on to that particular machine.

• The Group Policy container holds the certificates (Trusted Root Certification Authorities) and CTLs that are distributed using GPO settings.

• The User Certificate container holds the user certificates that are published in a user’s usercertificate Active Directory attribute.

• The Enterprise container holds the certificates of root CAs that are stored in the Active Directory configuration naming context. These certificates are registered in the AD when an enterprise or root domain Administrator installs a root CA in the Windows 2000 forest.

Table 13.9 shows where the physical stores’ content is originally located, where it is stored on the client side, and when it is copied from its original location to the PKI client certificate store.

Knowing all this, you can perform the following operation on the level of the MMC Certificates snap-in. You can make a CA certificate available to every user logging on to the machine. To do so, drag the certificate from the registry\certificates to the local computer\certificates physical container in the Trusted Root Certification Authorities logical container. Doing this will bring up a dialog box requesting whether you really want to add or delete a certificate to or from the Root store.

13.4.5 Private key storage

In asymmetric cryptography—on which both PKI and PKI-enabled applications (PKA) are built—access to and secure storage of the private key are critical. Because public keys are public entities, we should not bother about secure public key storage. (This does not mean you should not worry about the authenticity of the public key.) Let’s look at some examples of how you could misuse someone else’s private key.

• If you gain access to someone’s private e-mail encryption key, you will be able to decrypt all the messages encrypted using the corresponding public key. If you get access to someone’s e-mail signing key, you will be capable of signing messages on that person’s behalf.

• If you gain access to a Certification Authority’s private key, you become even more powerful: This will enable you to issue fraudulent certificates and make CA users believe that you are the acting trusted third party. As such, you will have succeeded in compromising the complete CA trust system.

• If you gain access to a software vendor’s code-signing private key, you could sign your code with the vendor’s key. Users would then, without their knowledge, download and execute your (possibly malicious) code.

Physical private key storage options

Private keys can be stored in different places. There are two main approaches to storing private keys: You can either place them on dedicated hardware devices or use software to hide them.

Software-based storage

The bulk of today’s operating systems—including Windows Server 2003 and XP—and PKI-enabled applications store private key material in an encrypted format on the file system. Windows stores private keys or point- ers to them (in case a hardware storage device is used) in the user’s profile. They are stored in the subdirectory %UserProfile%\Application Data\ Microsoft\Crypto\RSA. The security of Microsoft’s private key storage on the file system is rooted on what Microsoft calls the Data Protection API (DPAPI). More details on DPAPI are provided later.

Dedicated hardware device storage

Examples of dedicated hardware devices used for private key storage are smart cards, USB tokens, and Hardware Security Modules (HSM). A smart card or USB token is used to store the private key of a user. HSMs are used to store the private keys belonging to services or machines. A good example of HSM usage is for secure CA private key storage. Table 13.10 lists some popular vendors of these hardware devices (this list does not provide a complete overview).

Most dedicated hardware devices serve more goals than just secure private key storage. They can also provide secure onboard key-generation capabilities and cryptographic processing capabilities to accelerate digital signing and other cryptographic operations. A key advantage of using external devices to store encryption and signing algorithms is that the private key never makes it to the user’s PC.

Neither smart cards nor USB tokens are perfect, although they have an excellent reputation for providing secure private key storage. Over the past few years, several researchers conducted successful private key chases on both types of devices. Two important details are: (1) To conduct an attack on such a device, you need very expensive and highly specialized hardware; (2) most attacks require that you uncover the chip in the device. This means that usually you cannot perform an attack without physically damaging the device. A couple of successful USB token attacks are explained in detail at http:// www.atstake.com/research/reports/usb_hardware_token.pdf. For an over- view of possible smart card attacks, see the Cryptography Research Web site at http://www.cryptography.com/dpa/technical/index.htm.

To protect against physical tampering with a device, there is only one better category of solutions available on the market: Hardware Security Modules (HSMs). HSMs are extremely expensive devices; that is why they are only used to protect very important keys such as Certificate Authority (CA) private keys.

When evaluating hardware devices for secure private key storage, make sure that you check compliance with important security standards such as the Common Criteria (http://www.commoncriteria.org), the U.S. govern- ment’s FIPS 140-1 (http://csrc.nist.gov/cryptval/), and the U.K. govern- ment’s ITsec (http://www.cesg.gov.uk/assurance/iacs/itsec/index.htm). Next we will pay special attention to the FIPS 140-1 compliance of HSM devices.

We return to smart card integration in Windows Server 2003 and XP in Chapter 17. In the following sections we look in more detail at some of the security technologies behind the HSMs supported in Windows Server 2003. The goal is not to make a competitive comparison between different HSMs but rather to facilitate understanding of the security technologies they use. We use the examples of the nCipher and Chrysalis HSM.

The nCipher Hardware Security Module The nCipher’s HSM is called nShield. It can be used from many different operating systems (including NT, Windows 2000, Solaris, AIX, and HP-UX) and can protect the cryptographic keys used by a variety of applications, including Microsoft Certificate Server, the Apache Web server, Netscape’s Certificate Management Server, Enterprise Server, and many others. The nShield device is available with a PCI, internal, or external SCSI connector. Figure 13.13 shows the internal SCSI connector model. nShield’s front panel contains a smart card reader.

Figure 13.13: nShield device with internal SCSI connector.

nShield’s advanced key protection is built around the concept of a “security world,” which provides a multilayered, secure approach to managing HSMs, valuable application keys, and backup and disaster recovery processes.

From a high-level point of view, a security world (as illustrated in Figure13.14) is made up of one or more nShield HSM modules, a set of data (cryptographic keys) maintained in the secure memory of the HSM, and a set of encrypted data stored on the hard disk of the host machine.

Figure 13.14: An nShield security world and its different components.

An nShield module and its security world’s primary reason for existence are protecting cryptographic keys. This includes making sure that only the legitimate users and applications are authorized to access and use the keys.

Let’s first look at how a cryptographic key that is used by a particular application is securely stored in a module’s security world. Such a key is referred to in the nShield documentation as an “application key.” A good example of an application key would be the private key used by a Windows Certification Authority. Application keys can be stored securely in two different ways: They can be encrypted using the security world key or additionally using an operator key. This brings up two other key types: a security world key (also known as the “module key”) and an operator key (this type of key is also referred to as an “operator logical token”).

An operator key is not stored on the nShield module but is shared over a set of operator smart cards—also known as an operator card set (OCS). An OCS stores an operator key in a very special way: The key is never stored entirely on a single smart card (unless you have only a single card in your OCS) but in fragments that are spread across several different cards. In order to restore the operator key and thus to enable the decryption of application keys, one needs access to a predefined number of operator key fragments, each of which is stored on another operator smart card. The reason why nCipher splits operator keys is to let the access to an application key depend on the decision of more than one different person. In military terms this is known as the “missile silo” principle: A general can never decide all by himself to launch a nuclear missile; before he can do so, he needs—for example—the approval of at least one another general, the minister of defense, and the president.

nCipher calls this key fragmentation mechanism the k-of-n mechanism. The number k defines the number of cards that is needed to gain access to the operator key. The number n defines the total number of cards in the OCS. Coming back to the military example, you can look at the number k as the number defining how many cards are needed to authorize the decryption of an application key.

A security world may contain many different OCSs. This allows an nShield module to be shared between different applications that have different administration needs. The security world in Figure 13.2, for example, contains two OCSs. Application keys 2 and 3 are both protected by the operator key linked to OCS number 1. Application key 4 is protected by the operator key linked to OCS number 2.

A security world key (also known as the module key) is a cryptographic key that is created when the security world is created. It is stored securely on the nShield module and is used to encrypt application keys that must be available to several applications at all times—this means without needing multiple smart cards.

By default, any nShield device is FIPS 140-1 Level 2 compliant. FIPS 140-1 Level 3 compliance requires the use of a specific device type (nC4032W-xxx or nC3031S-xxx modules). It also requires you to set a configuration option during the initialization of the nShield security world. One of the most visible changes when an nShield device is FIPS 140-1 Level 3 compliant is the requirement to have an extra authorization (which can come from a card in the ACS or any OCS) before an OCS can be created or erased.

The Chrysalis Hardware Security Module Chrysalis has two HSM models that can be used in a Windows Server 2003 PKI environment: the Luna CA and Luna RA. The CA model targets advanced CA security, and the RA model targets advanced RA security. Like the nCipher nShield HSM, both of the Chrysalis models can be used from many different operating systems (including NT, Windows 2000, Solaris, Redhat Linux AIX, and HP-UX) and can protect the cryptographic keys used by a variety of applications. The Luna CA HSM requires a PCI connector. The Luna RA HSM requires a PCMCIA Type II slot. The CA device is FIPS 140-1 Level 3 compliant; the RA device is only Level 2 compliant.

In the following section we focus on the Luna CA device (illustrated in Figure 13.15). Figure 13.15 shows clockwise from the top the Luna DOCK token reader, the Luna CA cryptographic token, the color-coded PED keys, and the Luna PED authentication device. The Luna CA securely stores the cryptographic keys on the cryptographic token.

Figure 13.15: The Luna CA HSM.

The security model used by the Luna CA is very similar to the one used by the nCipher nShield device (use of a multilayered security model, support for a k-of-n key splitting mechanism, and so forth) with the following exceptions:

• A Luna CA HSM is by default FIPS 140-1 Level 3 compliant.

• For cryptographic key backup, the Luna CA uses a technique known as “Key Cloning.” Luna CA backs up cryptographic keys to another cryptographic token (every Luna CA device comes by default with two tokens). nShield backs up the cryptographic keys to the hard disk of the computer host.

• To authenticate the HSM administrators, the Luna CA uses a host- independent authentication scheme. This scheme uses the Luna PIN Entry Device (PED) and a set of PED keys. PED keys are key-like security tokens that have a role identical to the smart cards used in an nShield Security World. Contrary to the nShield solution, the Luna CA’s two-factor identification scheme is host-independent: the PIN associated to a PED key has to be entered on the PED. An nShield administrator enters his or her PIN in a dialog box that pops up on the screen of a possibly insecure host.

The Windows private key storage architecture

Windows 2000, Windows Server 2003, and Windows XP are using an architecture called the Data Protection API (DPAPI) to securely store private keys on a Windows computer system. In previous operating system releases, Microsoft used a technology known as the protected store. The DPAPI is explained next.

The data protection API

The DPAPI provides a password-based data protection service. In this context, data protection means that DPAPI provides data confidentiality and integrity protection services. DPAPI is bundled with the kernel of the Windows OS (its public interfaces are part of the crypt32.dll). DPAPI data decryption and encryption occur in the security context of a Windows system’s local system account. Figure 13.16 shows the DPAPI key protection architecture.

Figure 13.16: DPAPI key protection architecture.

The data encryption key that the DPAPI uses to securely store data is called the symmetric encryption key. The symmetric encryption key is never stored on a system—it is derived from the encryption key and the master key.

• The encryption key consists of a set of user- and/or machine-specific data that are not secret.

• Access to the symmetric session key is really based on the master key.

That is why the master key is the most important key in the DPAPI. The master key is securely stored in the protect folder of a user’s profile (file system path: %UserProfile%\Application Data\Microsoft\ Protect\<UserSID>).

Figure 13.16 shows how the master key is protected using the master key encryption key. The latter is cryptographically derived from a user’s password credentials. The cryptographic algorithms involved in this protection scheme are the 3DES (CBC mode) encryption algorithm, the SHA-1 hash function, and the Password-based Key Derivation Function (PBKDF2). The latter is described as part of the PKCS#5 standard.

DPAPI provides the following master key backup and recovery mechanisms:

• On stand-alone machines a secure backup of the user’s password can be stored on a password recovery disk (PRD). This secured copy of the user’s password is referred to as the recovery key. The PRD and its recovery key allow users to access a system when they forgot their password and to reset their old password to a new one. Indirectly, this system also provides a recovery mechanism to access the master key. The security of the data on the PRD is based on a public-private key– based encryption scheme.

• Domain controllers and workstations and servers that are part of a domain also store a secured copy of the master key. In this case the master key is secured using a DC’s public key. This system allows DPAPI to access the master key if it cannot get to the master key encryption key.

• For every user, an encrypted copy of the user’s password is stored in the credential history folder (which is a part of the user profile). In this folder the user’s password is securely stored using a credential encryption key. This system allows for master key encryption key recovery when a user’s password has changed and access to an old master key encryption key (encrypted with an old user password) is needed.

An important drawback of using a user’s password to secure access to its protected data is that all the applications that are running in the user’s security context can access all of a user’s protected data. To counteract this, DPAPI allows an application to use an additional secret to protect the data.

The additional secret is then required to unprotect the data. In PKI terminology, this feature is referred to as strong private key protection (which is explained in a following section).

Important private key properties

Two private key properties that impact the key’s security level and that are both driven by the DPAPI are whether the key is exportable and whether it has strong private key protection enabled.

Private key exportability To enable all-time data recovery and to protect against cracking attacks, private keys used for recovery of encrypted data should be backed up or exported from the Windows system and stored on some other secure medium. To make the private key exportable, the user should check Mark keys as exportable in the Advanced Certificate Request options on the Web enrollment pages. This option is only available if the certificate will be used for key exchange only. A key can also be made exportable programmatically, by setting the CRYPT_EXPORTABLE property. How to do this is explained in detail in the platform SDK. If you want more than just backup and you really want to delete the local private key (to protect against cracking attacks), don’t forget to check the option to delete the private key if the export succeeds. The DPAPI also defines a CRYPT_ARCHIVABLE flag to allow a one-time export during a key archival operation.

Private key exportability is a predefined property that is set in the certificate templates that are used when requesting certificates to an Enterprise CA. The private keys of certificates for user signature, user, CTL signing, smart card user, smart card logon, enrollment agent, code signing, client authentication, and administrator are, by default, marked as nonexportable. Windows private signing keys are always marked as nonexportable. Signing keys should never be copied or stored on a medium different from the one that was used to store the private key when it was generated. This could be a serious security risk: A malicious person could export another person’s private key and impersonate him or her. The private keys of EFS and EFS recovery certificates are by default exportable for data recovery reasons.

Strong private key protection In both the Web enrollment pages and the Certificate Request Wizard, a user can choose to enable strong private key protection. Strong private key protection means that the user will be prompted every time the private key is used by an application. Two levels of strong private key protection can be set: high and medium (this is the default). High means that the user will, besides being prompted, also be asked to enter a password. The password is used by the DPAPI to add another security level for private key storage. Figure 13.17 shows the dialog box that pops up when you select strong private key protection.

Figure 13.17: Setting strong private key protection.

^[2]More information is available at http://csrc.nist.gov/cryptval/140-1/1401val2002.htm.

^[3]Certificate template ACLs can also be set from the AD Sites and Services MMC snap-in: The templates are available from the Certificate Templates container in the Public Key Services container. I recommend, however, using the Certificate Templates MMC snap-in.

^[4]When using the certreq command line you can reference the certificate template that must be used with the –attrib switch. For example: certreq –attrib “CertificateTemplate:CrossCA”

^[5]PKI-enabled applications may create application-specific logical certificate containers.