Objective 2.1: Designing a Public Key Infrastructure

We need to understand the PKI basic concepts before we dive into Windows Server 2003 CAs. There are millions of messages traveling through public networks like the Internet every day. How do we authenticate these messages? How do we know whether the messages are being tampered with before they get to the receiver? E-commerce would not be possible on the Internet if these questions could not be answered adequately. Every e-commerce transaction must satisfy three basic needs to be secure and complete:

  • The sender has the authority to send the required message. The sender is authenticated to send the message to the receiver.

  • The message is authentic . The message has not been altered on the way to the receiver. A hacker can obtain this message by tapping into the communication route. This hacker might change the content of the message and impersonate the original sender

  • The sender cannot falsely deny sending the message or the content of the message. This is commonly referred to as nonrepudiation .

Therefore, we need to protect the data during the transmission process. We do that by encrypting the content of the message with mathematical algorithms. There are several ways to encrypt messages. All of them fall into two major categories: symmetric and asymmetric algorithms. The symmetric model works on a shared key that works well in a protected environment. The Automatic Teller Machine (ATM) activity at a bank is an example of a symmetric key exchange. The customer and the bank share the personal identification number (PIN) in a closed environment. The customer guards the key closely. He or she will not reveal it to others. The more people who know about the PIN number, the more the scalability of the security diminishes (more people can impersonate the customer). The bank and the customer know the same PIN number initially. However, this solution becomes increasingly insecure as soon as other people share the key ”the PIN.

The second encryption technology is referred to as asymmetric or public key cryptography . It involves two asymmetric key pairs. There are not like the PIN number. The two keys for the bank and the customer are different. The two keys are referred to as the private and the public key. The public key can be shared with other users; however, the private key is unique for a user or a resource. The sender s authenticity and nonrepudiation is based on the private key signing of the digital documents. The private key and the public key are mathematically related to each other. However, it is impossible to calculate the private key by hacking the public key. The keys also perform inverse roles (what a one key encrypts can be decrypted by the other).

Digital certificates are based on public key cryptography. These certificates are made by applying two levels of cryptography to a message: hashing algorithms and signing algorithms. Here are the steps involved in creating a digital certificate:

  1. A hashing algorithm is a very complex mathematical algorithm that is applied to the original message. The result will be a 160-bit string of digits that is unique to the original message. This is referred to as the message digest . There are several popular hashing algorithms used by the Microsoft platform: MD2, MD4, MD5, and SHA-1.

  2. The signature algorithm is then applied to the message digest. The sender s private key is built into this signing process. This will result in a unique set of characters that we refer to as the digital certificate . The default signature algorithm in Windows Server 2003 is the Microsoft strong cryptographic provider algorithm.

Anyone can download digital certificate generation software and generate private and public keys. Tools to accomplish this are readily available on the Internet. Knowing this, how do we trust a document that is digitally signed? A malicious attacker can create digitally signed software just as easily as a well-known manufacturer, and the digital signature might mislead us to install malicious software on our network. Luckily, there is a solution to this problem: we only accept users who sign their documents with a certificate from a well-known vendor or trusted party. These trusted parties are commonly referred to as certificate authorities (CAs). Several major CAs issue certificates for e-commerce transactions; VeriSign and RSA are two of the well-known companies. In this case, a typical end user will be more confident that his or her transactions are protected by a reputable CA.

You might also need to use certificates internally within your organization. You can restrict access to valuable resources using certificates. PKI is used with technologies such as File Encrypted Security and IPSec to protect enterprise resources; these topics are discussed at more length in later chapters. We can use the Windows Server 2003 CA service to enable this functionality.

Let s try to put all this theory into practice. Figure 3.1 illustrates the complete PKI process in which we are trying to send an e-mail message to a recipient.

click to expand
Figure 3.1: PKI Overview
  1. It begins with the sender requesting a certificate from the CA (1). We need to get a digital certificate to protect the e-mail message.

  2. The CA will check the user credentials and issue a digital certificate. The CA can use the Active Directory and the Windows logon data to assist the certification generation. The CA will also publish the certificate in a public certificate repository (this way, when the receiver gets the message, he or she can authenticate the sender). This is represented by (2).

  3. Then we try to sign the e-mail message with the key (3). The signing process is done in two phases.

  4. The first phase is to apply the hashing algorithm (4). We obtain a message digest as the result of this.

  5. Then we apply the signing algorithm with the private key on the message digest (5).

    The hashing algorithm and the signing data are contained in the certificate to assist step (4) and step (5). The result is the encrypted message.

  6. The encrypted message is sent to the receiver (6).

  7. The receiver will communicate to the public certificate repository to validate the certificate details (7).

  8. The public certificate repository will respond with a flag to indicate the authenticity of the message (8). The receiver will be able to decrypt the e-mail depending on this response.

This will complete the PKI implementation. Now let s try to understand the PKI process in more detail.

Understanding PKI

PKI could be described as a collection of standards, policies, laws, and procedures that will ensure security using public and private key pairs. PKI assists in electronic transactions with the help of digital certificates and CAs to verify and validate the potential users of our application.

The Windows Server 2003 PKI is based on the public key infrastructure X.509 (PKIX) standard and Internet Engineering Task Force (IETF) standards to ensure interoperability with other vendors . IETF also recommends some other security standards that work closely with the PKI architecture: Transport Layer Security (TLS), Secure Multipurpose Internet Mail Extensions (S/MIME), and IPSec.

start sidebar
Head of the Class
TLS, S/MIME, and IPSec

Let s try to learn a bit more about these protocols. These protocols are used with PKI to enhance security in enterprise applications. These protocols are independent of the PKI certificate authentication process. However, they work with the PKI infrastructure to avoid security breaches by intruders.

  • Transport Layer Security protocol (TLS) An industry standard that provides secure communication on Web sites (intranet and Internet). It provides a secure encrypted channel to transfer data between entities, and helps to authenticate the users. TLS is an advanced version of the SSL protocol.

  • Secure Multipurpose Internet Mail Extensions (S/MIME) An enhancement of MIME that provides secure e-mail exchange with digital signatures to prove the origin of the e-mail. S/MIME will also encrypt the e-mail content to preserve data integrity.

  • Internet Protocol Security (IPSec) A set of protocols that provide industry standard cryptography mechanisms to exchange data. IPSec implements algorithms for all the protocols in the TCP/IP stack, excluding the Address Resolution Protocol (ARP). IPSec is used with the Layer 2 Tunneling Protocol (L2TP) in virtual private networks (VPNs).

end sidebar

Let s look at the PKI architecture in detail. PKI is a combination of several key components. These components vary from actual certificates to lists that will authorize or revoke user access to the enterprise.

  • Digital certificates This is the core of the PKI technology, and holds the public key to validate the user. The public key is an electronic signature that we use to sign and encrypt the data that the users exchange with the enterprise. The digital certificate contains the version, serial number, signature, issuer, validity, subject, and subject public key information, and issues a unique ID, subject s unique ID, and extension information. This will enable third parties to establish the user s identity and the issuer s identity.

  • Certificate authorities (CA) CAs issue trusted certificates. The users need to obtain a certificate from a CA to own an electronic signature. There could be multiple CAs within an enterprise. These CAs will be arranged in a logical way to perform special tasks . Some might be configured to issue certificates to subordinate CAs, and others might be configured for internal or external issuing of certificates.

  • Certificate repositories The certificates need to be stored after they are issued by the CA. A certificate repository is the container where the certificates are stored. The preferred location for a certificate repository in Windows Server 2003 is the Active Directory. The Active Directory will provide the certificates to the users on demand. The certificates are physically stored on the CA hard drives . The Active Directory will have references to locate the correct certificates on demand.

  • Key retrieval and recovery This process recovers the private key portion of the public-private key pair in an emergency. (The user might have lost the key or the administrator needs to impersonate the user). This process does not recover any data or messages between the user and the enterprise server; it only recovers the private key credentials.

These are the major components of PKI. However, how do you administer the certificate issuing process? Can you prevent a malicious user from obtaining a certificate? We need to have some policies and technical controls in place to manage the certificate issue process. Here are some of the ways to dictate the structure of the PKI implementation:

  • Certificate policy and practice statements These will document the use of certificates in the enterprise. The details of how the certificates are used, the trust relationship between the certificates and the resources, and the consequence when the trust is broken are detailed in these documents.

  • Certificate Revocation List (CRL) This list specifies the certificates that should be revoked before the expiration date. Users on this list will no longer have access to resources secured by certificates.

    Exam Warning  

    The CRL could be a long list that consumes a lot of bandwidth. The Windows Server 2003 Certificate Server introduces a new concept called the Delta Certification Revoke List (Delta CRL). The Delta CRL will publish the recently revoked certificates to consume less bandwidth. This will only display the partial revocation list, not the full CRLs.

  • Certificate Trust List (CTL) The CTL documents the trusted certificates of the enterprise. This signed list is issued by the CAs. Management of a Windows Server 2003 CTL is done via Group Policy Objects (GPOs).

PKI could be used to perform many functions to secure the enterprise, including:

  • Digitally signing e-mail, applications, and sensitive documents

  • Secure remote access to computers over the Internet

  • Use smart cards to enable authentication and single sign-on in the enterprise

Designing a CA is the first step of a PKI implementation. This will identify the certificate requirements for the enterprise. You can either upgrade from an existing Windows implementation (NT 4.0 or Windows 2000) or a third-party certificate service and take advantage of the new Windows Server 2003 features. When the design phase is completed, we can deploy a PKI solution for all internal security requirements and exchange of secure data communication with our business partners . Let s look at how to design the CA implementation.

Objective 2.1.1: Designing a Certification Authority Implementation

The design of the CA is very important. The correct CA design will provide reliable service to the users, and an organic structure to delete and add users. This will also reduce maintenance costs. You need to consider several factors when implementing a CA:

  • Designing the root CAs An enterprise will have multiple CAs that will issue certificates to its users. These multiple CAs need to be controlled by a central figure, referred to as a root CA . The root CA will delegate the issuing of certificates to its subordinates . The root CA has to be implemented and correctly configured before we create a CA hierarchy. We need to consider some items before we design the root CA. The first item is the location of the CA. The ownership of the CA is also important. Who controls the CA and manages it (for example, the head office and its staff, or is it the responsibility of the IT department to host and manage)? Another important item is the functionality of the root CA? (Does the root CA just delegate to the CA hierarchy? Do we need to configure the root CA to issue certificates?) This will be discussed further in the next section.

  • Define CA types and roles Windows Server 2003 has two types of CAs: enterprise or stand-alone . Both types can be configured as the root CA or a subordinate CA. A subordinate CA can further be configured as an intermediate CA or an issuing CA.

start sidebar
Designing & Planning
Distinguishing Root CAs and Subordinate CAs

The root CA is the top of the CA hierarchy and should be trusted at all times. The certificate chain will ultimately end at the root CA. The enterprise can have a root CA as enterprise or a stand-alone CA (these topics are discussed later). The root CA is the only entity that can self sign, or issue self certificates in the enterprise. Windows Server 2003 only allows one machine to act as the root CA. The root CA is the most important CA. If the root CA is compromised, all the CAs in the enterprise will be compromised. Therefore, it is a good practice to disconnect the root CA from the network and use a subsidiary CA to issue certificates to users.

Any CAs that are not the root CA are classified as subordinate CAs. The first level of subordinate CAs will obtain their certificates from the root CA. These servers are commonly referred to as intermediary or policy CAs. They will pass on the certificate information to the issuing CAs down the chain. They are referred to as intermediary because they act as a go-between with the root CA and the issuing CAs.. The intermediary CA will instruct the issuing CAs with the certificates that are customized to the enterprise. This information is used by the issuing CAs to generate certificates for the end users. It is common in an enterprise to have an intermediary/policy CA that controls internal access, and then have another CA to control external access. A typical CA hierarchy of an enterprise is shown in Figure 3.2.

click to expand
Figure 3.2: Common Arrangements of the CA Hierarchy of an Enterprise
end sidebar
start sidebar
Head of the Class
Enterprise and Stand-Alone CAs

Enterprise CAs publish certificates and CRLs to the Active Directory. The Active Directory will store information on the user accounts, the user, and the policy to approve or deny certificates. Enterprise CAs use certificate templates, which are used to generate certificates for the users. Therefore, we can use the Enterprise CA to issue automated certificates and approve them. Enterprise CAs also enable smart card logons . The smart card certificates are automatically mapped the to Active Directory settings, hence enabling smart card authentication via Active Directory.

Enterprise CAs are closely bound to the enterprise s Active Directory structure. Therefore, the enterprise CA can only issues certificates to the users of the Active Directory. We will not be able to change the name of the CA server after CA service has been installed on the machine. This will make the certificates invalid. The enterprise CA machine cannot be removed form the domain structure of the enterprise either. Therefore, we need to consider the Active Directory structure before we plan the PKI implementation. Multiple Active Directory forests in an enterprise can complicate things. We need to assign an enterprise CA for each of the multiple Active Directory forests to facilitate multiple Active Directory forests. Enterprise CAs also rely on the existence of the Active Directory schema. We might need to upgrade the Active Directory schema from Windows 2000 to Windows Server 2003 schema to optimize enterprise CA use (some features such as certificate template version 2 are only supported in Windows Server 2003 schema).

Stand-alone CAs do not use the Active Directory or the certificate templates. The certificates need to contain all the user data if you use a stand-alone CA. (We can share this information between the certificate and the Active Directory in the Enterprise CA environment.) Because of this, certificate sizes are larger than for enterprise CA certificates. The certificates issued by a stand-alone CA need to be approved by an administrator. (They sit in a queue until they are approved. We can configure the stand-alone CA to issue automated certificates. This is not recommended since there is no authorization process with Active Directory.) Stand-alone CAs are configured to be a part of a workgroup (as opposed to a domain controller (DC)). Therefore, we can change the name of the CA server and it will not have an adverse affect on the certificate generation process.

It is advisable to use an enterprise CA within an enterprise, because enterprise users will have Windows accounts and Active Directory settings. We can automatically issue certificates to these users. Stand-alone CAs are more commonly used in extranets and Internet PKI applications. These certificates need to be approved by the CA administrator since they will not have Windows accounts in the enterprise.

end sidebar
  • Are we going to have internal CAs or delegate to third-party CAs? The answer to this question will depend on the structure and the budget of the PKI solution. It is advantageous to have an internal CA if the enterprise does a lot of internal business within the enterprise. If the enterprise conducts the majority of its business with external partners, an external CA would be better. The third-party CAs also add more confidence to the end user. Security audit experts will also feel more comfortable with an external third-party reputable vendor like VeriSign.

  • Evaluate the optimum level of capacity for the CAs. The stakeholders of the enterprise should agree on the performance and the scalability of the CA servers. This is dependent on the number of certificates that a CA issues, the hardware that the CA servers run, and the size of the certificates themselves . You also need to consider the quality of the network resources and the number of clients you need to configure.

start sidebar
Designing & Planning
Scalability of Windows Server 2003 PKI

A stand-alone Windows Server 2003 CA can host 35 million standard- sized certificates. The size of the certificates is a crucial factor. A Windows Server 2003 that runs on a dual processor with 512MB of memory can issue up to 2 million certificates per day. Network bandwidth and the quality of the network resources are the major concern for many CA implementations , and will dictate the number of CAs in the organization. The bandwidth for 2 million certificates exchanging information on the network can generate a considerable amount of traffic. While we can easily attach or disconnect CA servers from the network, a network upgrade is quite expensive and time consuming. Some other important factors to consider on CA servers include:

  • Number of CPUs The more CPUs, the greater the throughput.

  • Disk performance This depends on the number of certificates enrolled and the size of the certificates. A higher performing disk controller will be needed if the certificates are larger or the numbers of certificates exceeds 2 million a day.

  • Hard disk capacity The general size of a certificate is about 17k. The log entries for the certificate will be around 15K. The size of the certificate database increases with the number of certificate enrollments; therefore, we need to provide for this.

  • Number of CA administrators Some organizations have a distributed CA administrative model that spans multiple offices and IT departments. It is usually a good practice to centralize the control to a small team to save network bandwidth and administration costs.

end sidebar

These are the factors we need to consider when we design a CA. Now we need to understand how we arrange these CAs to issue certificates to the end users. There are several models to group or organize CAs to facilitate a PKI implementation. These are commonly referred to as trust hierarchies .

The Windows Server 2003 PKI model consists of well-defined parent-child relationships between CA servers. The child CA is certified by the parent CA and is trusted to issue certificates to the next layer of CA servers. A best practice is to organize the CA servers in a three- tier model, commonly referred to as the three-tier CA model . The three tiers are the root CA, intermediary CAs, and issuing CAs. Let s learn a bit more about these trust hierarchies with an example. We will be referring to a fictitious company, IronCladSecurity, for demonstration purposes. The company has subsidiaries in the United States, Germany, and Singapore. It is a large company with many business partners. IronCladSecurity employs 10,000 employees in these subsidiaries, and has a combination of employees and contractors as its workforce.

Geographical Hierarchy

The CAs in a geographical hierarchy are organized according to the geographical location of the subsidiaries of the enterprise. This model allows the regional CA administrators to manage their domains more efficiently . IronCladSecurity has offices in the United States, Germany, and Singapore. Therefore, the three-tier CA trust hierarchy for this company based on geography could be similar to Figure 3.3.

click to expand
Figure 3.3: Example of Geographical Hierarchy

There is one corporate root CA. This could be based in the United States, Germany, or Singapore. This is the first tier of the CA hierarchy. The second tier is the intermediary CAs. These CAs are based on location. Therefore, the United States, Germany, and Singapore will have CAs to manage their subsidiaries. The third tier is the issuing CAs. Figure 3.3 illustrates the issuing CA s hierarchy of the Singapore subsidiary. Two types of certificates need to be issued from the Singapore CA: high security certificates (which are for sensitive information and will be very detailed and expensive) and medium security certificates (which do not have the same sensitivity as high security). Medium security certificates are less verbose and less expensive than the high security certificates. We have designed a CA server each to facilitate the high and medium level security users.

Organizational Hierarchy

The trust hierarchy can also be designed to accommodate the organizational structure of an enterprise. IronCladSecurity employs both permanent employees and contractors. It could be risky to issue the permanent employee certificates to the contractors. IronCladSecurity also has multiple business partners. One partner might not want to share a common certificate with other partners. The issue of certificates for internal employees is another matter. These issues will justify a trust hierarchy based on organizational structure. The trust hierarchy for IronCladCompany might look similar to Figure 3.4.

click to expand
Figure 3.4: Example of Organizational Trust Hierarchy

The organization-based trust hierarchy of IronCladSecurity is also based on the three-tier CA model. There is one corporate root CA. The intermediary CAs are assigned to facilitate the organizational structure. There is one CA assigned for corporate certificate usage. The second CA is assigned to issue certificates to business partners. The third CA is used to issue certificates to the employees. IronCladSecurity has contractors and permanent employees; therefore, it is a better design to assign an issuing CA to both the contractors and permanent employees.

Network Trust Hierarchy

Some organizations have distributed and independent IT departments. It could be difficult to identify and implement a single entity as a root CA, and there might be little communication between these subsidiaries since they operate independently within their domain. A single root CA design would not be appropriate for this scenario.

We can overcome this issue by designing a network trust model. There is no single root CA in this model; instead, there are multiple CAs taking the role of the root CA. There are trust relationships between these CAs, which is achieved by each CA issuing the other a cross certificate . These cross certificates can be bidirectional or unidirectional. Let s try to explain this scenario with IronCladSecurity. IronCladSecurity has given permission to its various IT departments to implement a network trust model. Each IT department will have a CA server. The IT department will trust the other IT department with the help of a cross certificate. Figure 3.5 illustrates this model.

click to expand
Figure 3.5: Example of Network Trust Security

There are three IT departments at IronCladSecurity, and no corporate root CA. Each department has its own CA to issue certificates. There are cross certificates between the departments to enable access between departments. These relationships can be either one way or bidirectional. For example, departments A and B have a two-way trust relationship using cross certificates. Therefore, employees of both departments A and B can use resources of the two departments (in other words, a department A user can request a department B certificate and use a department B resource, and vice versa). However, there is only a one-way trust between departments B and C. Therefore, department C will not be able to obtain any certificates from department B. Hence, a department C user will not gain access to department B resources. Department B has one-way access to department C; therefore, department B user can gain access to department C resources.

Test Day Tip  

The network trust model is harder to maintain than the root CA model. It becomes more difficult to manage as the number of CAs in the enterprise increases. There can also be a negative impact on network bandwidth in this model. This is recommended when there is minimum communication between the departments.

The network trust model also presents a challenge in that there is no root CA. Therefore, a global directory (such as Active Directory) must be installed in this enterprise. The only way we can find/ locate other department s CAs is using a mechanism like Active Directory.

Objective 2.2: Designing a Logical Authentication Strategy

A logical authentication strategy for an enterprise could be very complex. We need to provide a secure environment to communicate with our business partners. The enterprise might consist of many employees situated in many locations. Those employees might work at company premises and external locations (using remote services from their homes ). These employees could also travel for their work purposes. The most important feature of the authentication strategy is to prevent intruders from accessing sensitive data. We need to consider all these features to build a logical authentication strategy for the enterprise.

Windows Server 2003 provides a secure framework for users, computers, and services of the enterprise. This is achieved by creating Active Directory accounts for each resource that needs to be accessed in the enterprise. The first step of the strategy is to review the existing authentication strategy. We should take note of the resources that are not supported in the old authentication regime . Then, we need to create the users in Active Directory that can access these resources. These users need to be created with the assistance of a user account management plan . This plan will document the users, their access, and the reason for them to have access to the resources. Then, we have to configure the computer accounts for the resources. This computer information should be documented in the computer account management plan . These accounts will be individual user accounts or service accounts. (service accounts are common accounts that can be used by multiple users). The next step is to secure the authentication process of the enterprise. This can be done in many ways:

  • Create a strong password policy for users and service accounts in the enterprise. We should have an alphanumeric combination that should exceed at least eight characters.

  • Configure an account lockout policy. Intruders automate sophisticated algorithms to discover passwords for user accounts. Therefore, we have to configure Windows Server 2003 to deal with repeated failures of password authentication. The account should be locked out if the user is unable to submit the correct password in a specified amount of attempts (t is common to lock the account after three invalid password submissions).

  • Limit the usage according to time. Accounts can be configured to operate on a time table (for example, the accounts can be configured only to work from 9:00 a.m. to 9:00 p.m . Monday through Friday). This will deter the hackers who are trying to penetrate the system on other time slots.

  • Monitor the expiration time frames of the PKI certificates. We need to set the expiration dates on all certificates issued by the enterprise. The time frame that a certificate is valid changes from organization to organization. We need to revisit this time frame regularly to analyze the best certificate life span for an enterprise. This will prevent disgruntled former employees from trying to compromise the system.

We can use PKI certificates to authenticate many users and resources. We can implement the Web Enrollment Support System (discussed later) to issue certificates to Web pages. These Web pages can easily authenticate onto other enterprise resources with the help of these certificates. We can use role-based security with the help of a PKI architecture. The certificate has all the details about the users and their access. Therefore, we can import the security information to any resource of the enterprise. The resource can accept or deny access according to the certificate information. We can put the necessary roles for a user in the Active Directory. The CA server will examine the Active Directory entries (using Windows logon API) in order to generate a certificate for this user. The roles information will be embedded into the user s certificate. The roles will be examined by the resources (with the help of Active Directory) each time the user tries to gain access to the resource. We will issue a new certificate to the user when the roles are modified.

We can also use smart cards to extend the PKI security infrastructure. The employees need to enter the smart card to every device they want to access. The smart cards force the employee to use the asymmetric key and a PIN to authenticate (this is discussed later in the chapter). We will also discuss using 802.1x certificates to authenticate into wireless devices in a later chapter.

We also need to take steps to protect enterprise and stand-alone CAs . The enterprise CAs communicate to Active Directory regularly. Therefore, it is advised to have the enterprise CA in the same subnet as the Active Directory servers. This will minimize the network traffic and latency. (Most enterprises will have a high security server farm with sophisticated security; for example, armed guards, secure doors, and technical security such as smart cards authentication. Therefore, the enterprise CA server will plug in to this special high security farm.) The enterprise CA needs to authenticate to a DC to access Active Directory. Therefore, it is difficult to take the enterprise CAs offline. Hence, we need to carefully plan the enterprise CA addition to the network (once the name of the enterprise CA is set, it will be difficult to alter the machine name without compromising the existing certificates). The stand-alone CA implementation is discussed in the section Securing a Stand-Alone CA .

Objective 2.1.4: Designing Security for CA Servers

Securing enterprise CA servers is a very important step in a PKI implementation. Hackers can inflict a myriad of attacks on sensitive data if the CA servers are compromised. They can modify the certificates or alter the configuration of the CA servers, thus impacting all systems within the enterprise IT systems. We should take steps to protect the CA servers. Let s discuss this topic in more detail. We will first investigate the common threats against CAs.

Common Threats Against Certificate Services

The root CA is the most important CA in the enterprise. The entire PKI implementation will be in jeopardy if the root CA is compromised, because the root CA provides all certificate information through policy CAs to issuing CAs within an organization. If the root CA is compromised, intruders can tamper with certificate information or issue fraudulent certificates by misusing the issuing CAs. The issuing CAs will be helpless since they will merely follow the root CA s lead.

How do we protect the root CA from being compromised? The most common way for an intruder to hack into the CA is via a network attack. Networks in a large enterprise can be very complex; therefore, they are very difficult to maintain and audit. This can enable intelligent hackers to penetrate systems through unpatched or undetected loopholes. These loopholes could be simple as a stolen access card belonging to a system administrator, or a sophisticated software algorithm that scans the open ports on an enterprise firewall. A successful attacker could retrieve the private key of the root CA and manipulate or destroy enterprise resources. The important fact is to protect the CA before an intruder strikes.

The best way to protect the root CA is to disconnect it from the network. That way, even if the network is compromised, the intruder will not gain access to the root CA. The same steps can also be applied to intermediate or policy CAs; they should be disconnected from the network in a high-security environment. Doing so will prevent the private key from being compromised by intruders. We can make the CA servers offline using any of the following steps:

  • Install a stand-alone Windows Server 2003 as the root CA. Configure it to be physically disconnected from the network.

    Test Day Tip  

    The best practice is not to install the CA server as a member of a domain. This will be an issue when the CA administrators bring the server online for maintenance or backup. The password for domain accounts expires every 30 days by default. Therefore, the CA s server passwords will be invalid after the 30-day period. The solution for this is to make the offline CA a member of a workgroup.

    We should not configure an enterprise CA as the root CA. The enterprise CAs communicate with a global directory (in other words, the Active Directory). The Active Directory updates will have issues when the root CA is offline; therefore, the root CA should be a stand-alone CA.

  • Shut down the CA service. The CA server can be online; however, we can disable or stop the CA service of the computer. This step will restrict the certification generation process and disable the activities of the certificate generation. It will stop the CA from issuing, denying , updating, or viewing certificate data and will disable the auto-enrollment of certificates. However, the CA server is still vulnerable to a hacker who scans the file system to obtain certificate data.

  • Physically shut down the CA server. This is commonly practiced on high-security root CA servers. The root CA servers are physically shut down until they are needed to issue new certificates to policy/intermediary CAs. However, this will prevent CA auditing on the CA server.

    Exam Warning  

    The offline CAs can still publish certificates and certificate revocation lists (CRLs) in Active Directory. They need to be online to communicate with the Active Directory to publish CRLs. You should take steps to coordinate the CRL updates so that the CA server is online to interact with Active Directory. It is a good practice to bring the CA online on an agreed time schedule to populate the new CRL. (This could be done by making the CA server ˜visible to the network; in other words, starting the CA service or powering up the CA machine.) The parent CAs should also be online to instruct the subordinate CAs to process certificate update information.

    The Authority Information Access (AIA) is the endpoint to obtain the certificate data. This is usually the local HTTP server. The CRL default location is a directory on the local machine. These local file paths and HTTP virtual directories are invalid when the CA is offline. Therefore, they have to be modified to point at online resources when we take the parent CA offline.

Let s try to put all this information into practice. We will be designing a sample best-practice Windows Server 2003 PKI solution for a fictitious company. We will initially look at the enterprise hierarchy of the CA server. Then, we will discuss the steps to secure the stand-alone CA server.

Securing an Enterprise Hierarchy

An enterprise hierarchy can consist of many CAs. We need to organize them in a logical structure. The enterprise can only have one root CA. The root CA should not depend on any other resources of the enterprise (for example, Active Directory). Therefore, we should not use an enterprise CA as the root CA. The interaction with Active Directory might cause some issues. (The updates will not be reflected in real-time since the CA is offline.) The solution is to implement the root CA as a stand-alone CA.

start sidebar
Head of the Class
Impact of Offline CAs

There is no impact on the client-side certification because the CA is offline. The client needs the CRL and AIA data to verify the certificate credentials. The client will check the certificate chain and make sure that the entry is not in the CRL. These CRLs and AIA information are obtained from other online subordinates issuing CAs. These online CAs issue information according to the instructions given by the offline parent CAs. The offline CAs process a very small number of requests from subordinates issuing CAs. Therefore, administrative costs on offline CAs are negligible. Let s try to explain this with our IronCladSecurity example form the previous section.

IronCladSecurity follows a geographical hierarchy CA structure. It has a root CA in the U.S. office. There are policy CAs in the United States, Germany, and Singapore. There are issuing CAs at each geographical location. The root CA in the United States will be disconnected from the corporate network. The root CA will only be available to update or issue new certificates to policy CAs in the United States, Germany, or Singapore. The policy CAs are also offline most of the time. They are only online to issue certificates to issuing CAs. The issuing CA servers on the corporate LAN will be the only visible CA servers most of the time. The root CA and policy CA will be online for predefined time periods for maintenance (for example, to update Active Directory information) and certificate updates.

end sidebar

We will apply the three-tiered CA model to this enterprise. There will be a single offline root CA at the top. The root CA will delegate to policy CAs. The distribution of policy CAs depends on the organizational structure or the business model. We recognize three main areas of certificate distribution in this fictitious company. There is an external need to issue certificates to business partners. The internal security needs to dictate two types of certificates. Certificates issued by an internal high-security CA server protect the sensitive data. The medium security certificates are issued by an internal medium security CA. Figure 3.6 illustrates this CA architecture.

This structure will enable a secure and flexible mechanism to issue certificates for the enterprise. The architecture will also scale to add or delete any CA servers. We can add or delete policy and issuing CAs at our discretion. Let s investigate how to secure stand-alone CAs and cryptographic service providers (CSPs).

Securing a Stand-Alone CA

Securing a stand-alone CA can be done in several ways. It is best practice to implement the root CAs and the intermediary CAs as stand-alone CAs. We can make these servers offline and disconnect them form the network. These steps were discussed in the section Common Threats Against Certificate Services . The certificates issued by the CAs need to be stored in a secure environment, commonly referred to as a CSP. Here are some of the other ways to secure them:

click to expand
Figure 3.6: Example of a Three-Tiered CA Enterprise Hierarchy
  • Using hardware CSPs There are hardware CSPs that can handle complex cryptography and key storage. Hardware CSP key storage is more secure than software CSP. They cannot be easily tampered as opposed to software CSPs where the keys can be stored on local hard disks. This will enable CA administrators to enable more life time on certificates on hardware CSPs.

    Exam Warning  

    Some hackers are sophisticated enough to obtain memory dumps of a software CSP. This can lead to compromising the private keys of the organization. Hardware CSP does not have this issue. The hardware CSPs do not store the key information in memory; they are kept in hardware devices. This will restrict the hackers from obtaining sensitive private key information.

    You also need to take into account the physical access to the hardware CSP. The hardware should be stored in a secure area of the building with limited access. You must also take necessary steps to back up the access accounts information and private key data.

  • Hardware CSPs can be expensive to purchase and maintain. An alternative is to use smart cards to store the keys.

    Exam Warning  

    The smart card implementation adds another level of security to the enterprise. Smart cards store a cryptographic key on the card. These cards are only accessible with the correct PIN); therefore, you need both the smart card and the PIN number to access or revoke certificate information. This will eliminate the risk of theft of a smart card and it being used for fraudulent purposes. It could be an expensive exercise to issue every employee a smart card. However, it is recommended that at least the CA administrators are equipped with smart cards to manage the CA servers. The smart cards will also enable a Single Sign On regime in the enterprise (since the user carries his own certificate from one location/machine to another).

  • You also need to take into account the physical access to the CAs and CSPs. These should be physically stored in a secure environment and accessed only by a small administrator team. Auditing on these servers is highly recommended to track any intruders or misuse by malicious employees. It is also recommend to back up this information on a regular basis.

MCSE Designing Security for a Windows Server 2003 Network. Exam 70-298
MCSE Designing Security for a Windows Server 2003 Network: Exam 70-298
ISBN: 1932266550
EAN: 2147483647
Year: 2003
Pages: 122

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net