Public Key Infrastructure (PKI)

Public Key Infrastructure (PKI) is a foundational framework that enables secure digital communication, authentication, and encryption across various networks and internet-based applications. At the heart of PKI are digital certificates, which serve as digital passports, allowing individuals, systems, and devices to prove their identity and establish trust. The integrity and reliability of PKI hinge on a well-structured hierarchy of Certificate Authorities (CAs), which issue and manage these digital certificates. This section delves into the critical components of PKI, including the pivotal roles of the Root and Subordinate Certificate Authorities, the functionality of Certification Authority Web Enrollment for streamlined certificate issuance, and the essential service provided by Online Certificate Status Protocol (OCSP) responders for real-time certificate validation. Together, these components form the backbone of PKI, ensuring secure and trusted digital interactions in today’s interconnected world.

Certificate Authorities (CAs)

Root CA

The Root Certificate Authority (Root CA) sits at the top of the PKI hierarchy and is the most trusted entity within the PKI framework. Its primary role is to issue certificates to Subordinate (or Intermediate) CAs, establishing a chain of trust. The Root CA’s certificate is self-signed, meaning it is generated and signed by the Root CA itself. Due to its critical importance and to minimize the risk of compromise, the Root CA is often kept offline (not directly accessible over the network) and activated only when needed, such as when issuing or renewing a Subordinate CA’s certificate or performing other high-trust administrative tasks.

Subordinate CAs

Subordinate Certificate Authorities, also known as Intermediate CAs, operate under the trust established by the Root CA. They are responsible for issuing certificates to end entities such as users, devices, or servers. There can be multiple levels of Subordinate CAs, creating a deeper hierarchy, which allows for a more segmented and manageable trust structure. Subordinate CAs handle the bulk of day-to-day certificate issuance and management tasks within the PKI. Their operations include validating certificate requests, issuing certificates based on predefined templates, and handling certificate renewals and revocation.

Certification Authority Web Enrollment

Certification Authority Web Enrollment is a service that facilitates the process of requesting and retrieving certificates via a web interface. This service is part of the Active Directory Certificate Services (AD CS) in Windows Server environments. It allows end-users and administrators to request certificates through a browser by accessing a web page hosted by the CA. Users can submit certificate signing requests (CSRs), and upon approval, download their issued certificates directly through the web interface.

This service simplifies the certificate enrollment process, especially in environments with a large number of users or devices requiring certificates. It supports various certificate types, including user certificates, computer certificates, and specific application certificates. The web enrollment feature is particularly useful for scenarios where automation or direct access to the CA is not feasible or desired.

Online Responder and OCSP

The Online Certificate Status Protocol (OCSP) responder is a crucial component for maintaining the real-time validity status of issued certificates. Unlike traditional Certificate Revocation Lists (CRLs), which require clients to download a list of all revoked certificates, OCSP allows for on-demand, real-time queries of a certificate’s revocation status. When a client needs to verify the status of a certificate, it sends a request to the OCSP responder, which checks the current status and responds with the certificate’s validity information.

The OCSP responder improves the efficiency of revocation checking by reducing network bandwidth and processing time required for clients to ascertain the status of a certificate. This is particularly important in high-performance environments or where timely information about the revocation status is critical. The OCSP responder must be highly available and securely managed to ensure reliable and trustworthy responses to revocation status queries.

Each of these components plays a vital role in the PKI ecosystem, ensuring the secure issuance, management, and validation of digital certificates, which are foundational to secure communications and trust within and across organizational boundaries.

Microsoft Active Directory Certificate Services (AD CS) is a critical component in implementing a Public Key Infrastructure (PKI) within a Windows Server environment. AD CS provides customizable services for creating, managing, and revoking public key certificates used in software security systems employing public key technologies. Within the PKI structure, AD CS acts as the backbone, enabling the setup and management of Certificate Authorities (CAs) that issue digital certificates to users, devices, and services.

One of the key features of AD CS is the management of certificate templates. These templates define the purpose, validity period, renewal policies, and other settings for the types of certificates the CA can issue. This allows for standardized issuance policies across the organization, ensuring consistency and compliance with security policies.

AD CS also manages the issuance policies, which govern the rules and processes for certificate issuance. These policies can include authentication requirements for certificate requests, approval workflows, and automatic enrollment settings. The issuance policies ensure that certificates are issued securely and only to verified entities.

Revocation lists, specifically Certificate Revocation Lists (CRLs), are another critical aspect managed by AD CS. CRLs provide a list of certificates that have been revoked before their scheduled expiration date, allowing users and systems to verify the validity of a certificate. AD CS facilitates the creation, distribution, and updating of CRLs, ensuring that entities within the network can check the revocation status of certificates in real-time.

Policy and Certification Authority Web Services

Policy and Certification Authority (CA) Web Services are integral to managing certificate enrollment and issuance, especially in environments with network boundaries or where direct access to the CA is restricted. These services facilitate the communication between CAs and clients across different domains or network segments, enabling secure certificate enrollment and issuance processes.

For Subordinate CAs, these web services are particularly useful as they allow for the delegation of certificate issuance tasks across organizational units or geographical locations. By utilizing Policy and CA Web Services, Subordinate CAs can adhere to centralized policies and templates while serving the specific needs of their domain, ensuring a cohesive and secure PKI structure across the entire organization.

Data Flow and Interactions

This section outlines the critical processes within a PKI system, detailing the journey of digital certificates from their initial enrollment to potential revocation. It covers the steps involved in requesting, validating, and issuing certificates, as well as the methods used to check their validity over time, such as Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP). This section aims to provide a clear understanding of the essential interactions that maintain the security and trust of digital certificates in a PKI framework.

Certificate Enrollment Process

The certificate enrollment process in a PKI system involves several key steps:

1. Enrollment Request: An end entity, such as a user or device, initiates the process by generating a Certificate Signing Request (CSR). The CSR contains the entity’s public key and identifying information.
2. Request Submission: The CSR is submitted to the CA, often via a web interface provided by Certification Authority Web Enrollment or through automated processes like auto-enrollment in Active Directory environments.
3. Request Validation: The CA validates the request. This validation can involve checking the identity of the requester against a directory service, requiring managerial approval, or other authentication methods as defined by the CA’s policies.
4. Certificate Issuance: Once the request is approved, the CA signs the certificate using its private key, effectively binding the requester’s public key to their identity as specified in the CSR.
5. Certificate Retrieval: The signed certificate is made available to the requester, either through a direct download from the web interface or via automatic installation onto the requester’s system or device.
6. Certificate Installation: The end entity installs the certificate, enabling it to be used for secure communications, digital signatures, or other cryptographic functions.

Revocation Checking

Revocation checking is crucial for verifying the current validity of certificates. There are two primary methods for this:

• Certificate Revocation Lists (CRLs): CAs publish CRLs at regular intervals, listing all certificates revoked before their expiration. Clients download the CRL from a specified CDP and check if a given certificate is listed. This method can be resource-intensive for clients, especially when dealing with large CRLs.
• Online Certificate Status Protocol (OCSP): OCSP allows clients to query the revocation status of a specific certificate in real-time. The client sends a request to an OCSP responder, which checks the current status of the certificate and returns a response indicating whether the certificate is valid, revoked, or unknown. OCSP provides a more efficient and timely method for revocation checking compared to CRLs.

Both methods ensure that entities within the PKI ecosystem can verify the trustworthiness of certificates, maintaining the integrity and security of digital communications and transactions.

individual Certificate Distribution Points (CDPs) have been designated for each Subordinate CA. This configuration permits every Subordinate CA to independently manage and disseminate its Certificate Revocation Lists (CRLs), thereby bolstering the system’s security and operational efficiency. The decentralization of CRL dissemination guarantees dependable access to revocation data and supports the customization of revocation policies to meet the unique requirements of each Subordinate CA. This strategy enhances the strength and agility of our PKI framework.

In line with the Low side PKI setup, there will be no Authority Information Access (AIA) extension used in this design.

Application Process View

This section of the HLSD outlines the key operational processes within the PKI system, detailing the interactions between different components to ensure secure certificate management, from issuance to revocation.

Certificate Issuance Workflow

The process begins when an entity (user, device, or system) requests a digital certificate. This involves generating a Certificate Signing Request (CSR) and submitting it to the Certification Authority (CA). The CA then validates the CSR against organizational policies and, upon approval, signs and issues the certificate. The issued certificate is made available to the requester, either through direct download or automatic installation.

Certificate Validation and Chain Building

When a certificate needs to be validated, the client software builds the certificate chain up to a trusted root CA, using the Authority Information Access (AIA) extension if necessary. Each certificate in the chain is checked for validity, expiration, and revocation status, employing CRLs or OCSP to ensure no certificate in the chain has been revoked.

Certificate Revocation Process

Certificate revocation can be initiated by various stakeholders for reasons such as compromise or loss of private keys. The CA updates the CRL and, if configured, the OCSP database, to reflect the revocation. The updated CRL is then published to the designated Certificate Distribution Points (CDPs), ensuring all entities in the network can access the revocation information.

Application Use Case

Client-Server Authentication

In this scenario, a user attempts to access a secure web service. The server presents its digital certificate to the user’s browser to prove its identity. The browser validates the server’s certificate, checking the validity, expiration, and revocation status. Upon successful validation, a secure connection is established using SSL/TLS, enabling secure communication between the user and the web service. This use case demonstrates the PKI’s role in facilitating secure, authenticated connections over the internet.

Step 1: Secure Connection Request

• The user initiates a secure session by entering an HTTPS URL into their browser, signaling a request to establish a secure connection with the server.

Step 2: Server Presents Its Certificate

• The server responds to the request by sending a copy of its digital certificate to the user’s browser. This certificate contains the server’s public key and identity information, along with the digital signature of the issuing Certificate Authority (CA).

Step 3: Certificate Validation by the Browser

1. Check Certificate Authenticity: The browser examines the certificate to ensure it was signed by a trusted CA. Browsers come pre-installed with a list of trusted CAs, and the certificate’s signature is verified against these.
2. Verify Certificate’s Validity Period: The browser checks the validity dates of the certificate to ensure it is currently valid and not expired.
3. Check for Revocation: The browser checks if the certificate has been revoked by the issuing CA, using either a Certificate Revocation List (CRL) or the Online Certificate Status Protocol (OCSP).
4. Hostname Verification: The browser verifies that the certificate’s subject name (or SAN – Subject Alternative Name) matches the server’s domain name in the URL.

Step 4: Session Key Generation

• If the certificate is valid, the browser generates a symmetric session key for encrypting data during the session. This key is then encrypted with the server’s public key (from the server’s certificate) and sent back to the server.

Step 5: Server Decrypts Session Key

• The server uses its private key to decrypt the symmetric session key sent by the browser.

Step 6: Secure Session Establishment

• With both the browser and server in possession of the same symmetric session key, they establish a secure, encrypted connection using SSL/TLS protocols. All data transmitted during the session is encrypted with the session key.

Step 7: Data Exchange

• The user and the web server can now exchange data securely. The browser displays a padlock icon or similar indicator to inform the user that the connection is secure.

Step 8: Session Closure

• Once the session is completed, the session key is discarded. Any new session will require a new key, ensuring the security of each individual session.

Step 1: Connection Request

• A user requests a secure connection by navigating to an HTTPS website, prompting the server to share its digital certificate.

Step 2: Server Certificate

• The server sends its digital certificate, containing its public key and a CA’s digital signature, to the user’s browser.

Step 3: Certificate Validation

• The browser validates the server’s certificate by checking the CA’s signature, the certificate’s validity period, revocation status using CRL or OCSP, and that the certificate’s subject name matches the server’s domain.

Step 4: Key Exchange

• Upon successful validation, the browser generates a symmetric session key, encrypts it with the server’s public key, and sends it to the server.

Step 5: Secure Session

• The server decrypts the session key, establishing a secure, encrypted connection using SSL/TLS for data exchange.

Step 6: Data Exchange

• Secure data transmission occurs, with the browser displaying a security indicator like a padlock icon.

Step 7: Session End

• After the session, the session key is discarded, ensuring the security of future sessions.

Security Considerations

Having the Primary Certificate Authority (CA) online presents a critical risk by exposing it to cyber threats, increasing the attack surface, and complicating continuous security maintenance. A breach could lead to unauthorized certificate issuance, enabling severe security breaches such as impersonation and data interception, thus jeopardizing the trust and integrity of the entire Public Key Infrastructure (PKI) system.

Its recommended to implement a strategy to keep the Root Certificate Authority (CA) in a secure offline state. Specifically, the Root CA’s virtual machine (VM) will remain powered off, and its network adapter disconnected, effectively isolating it from online threats. Activation of the Root CA will be limited to specific and controlled tasks, primarily the issuance or signing of Intermediate CA certificates. This approach is aimed at significantly reducing the Root CA’s vulnerability to cyber threats, enhancing the security of our Public Key Infrastructure (PKI) system.

it’s crucial to establish a comprehensive framework that addresses the confidentiality, integrity, and availability (CIA) of the PKI system. Here’s an outline of what could be included in the Security Requirements:

When drafting the Security Requirements section of a High-Level Security Design (HLSD) for a Public Key Infrastructure (PKI) solution, it’s crucial to establish a comprehensive framework that addresses the confidentiality, integrity, and availability (CIA) of the PKI system. This section should outline the specific security measures needed to protect the system’s components and data from various threats. Here’s an outline of what could be included in the Security Requirements section:

Security Requirements for PKI System

1. Confidentiality
   • Ensure that sensitive information, such as private keys and personal identification information, is accessible only to authorized individuals.
   • Implement encryption for data at rest and in transit within the PKI system to prevent unauthorized access.
2. Integrity
   • Protect the integrity of digital certificates and cryptographic keys to prevent unauthorized modification.
   • Employ mechanisms such as digital signatures and secure hashing algorithms to verify the authenticity and integrity of data.
3. Availability
   • Guarantee the availability of the PKI services, including certificate issuance, validation, and revocation services, to authorized users when needed.
   • Implement redundancy, failover systems, and regular backups to ensure continuous operation even in the event of system failures or attacks.
4. Authentication and Authorization
   • Enforce strong authentication mechanisms for users and systems interacting with the PKI, ensuring that only authorized entities can issue, revoke, or manage certificates.
   • Define and enforce access control policies based on the principle of least privilege, limiting users’ and systems’ access rights to the minimum necessary to perform their duties.
5. Audit and Accountability
   • Maintain comprehensive logs of all critical operations within the PKI system, including certificate issuance, renewal, revocation, and administrative actions.
   • Implement regular audit procedures to review and analyze logs for signs of unauthorized or suspicious activities.
6. Physical Security
   • Secure the physical infrastructure supporting the PKI, including data centers and server rooms, against unauthorized access, tampering, and environmental hazards.
7. Compliance
   • Adhere to relevant legal, regulatory, and industry standards governing the management and operation of PKI systems, such as those established by NIST, ETSI, or specific industry regulations.
8. Incident Response and Recovery
   • Develop and maintain an incident response plan that outlines procedures for detecting, responding to, and recovering from security incidents affecting the PKI system.
   • Establish a disaster recovery plan to restore normal operations in the aftermath of significant disruptions or disasters.
9. Cryptographic Security
   • Specify the cryptographic algorithms, key lengths, and protocols to be used within the PKI system, ensuring they align with current best practices and standards for cryptographic security.