Provisioning and securing security certificates

For most IPsec and TLS VPN connections, it’s necessary for devices and gateways to utilize certificates established through a central trust infrastructure to effectively recognize each other. End entity X.509v3 certificates must be generated for all authorized endpoints and registered with this trust infrastructure. This system must guarantee that unauthorized certificates are not allowed, ensuring the central infrastructure’s reliability.

The trust infrastructure, often called a Public Key Infrastructure (PKI), is typically managed by the organization delivering the encryption service. The local PKI may maintain trust relationships with other PKIs across different services and networks, facilitating encrypted connections among devices governed by distinct organizations.

Due to the sensitive nature of information held by PKIs (particularly private keys) and the essential trust function they serve, any security breach within a PKI can yield severe and difficult-to-detect repercussions. Therefore, robust protection against potential attackers is non-negotiable. As a result:

• It is highly advisable to avoid sharing PKIs among communities with substantially different security requirements or operational frameworks (e.g., using a PKI intended for commercial entities in conjunction with public sector organizations).
• The potential to utilize the PKI for various service types (such as IPsec, TLS, S/MIME, etc.) should be evaluated during the design phase. Implementing separate subordinate Certificate Authorities (CAs) for distinct functionalities is recommended to mitigate the risk of a compromised certificate being exploited across different services. Alternative strategies, like assigning different Certificate Policy OID (CPOID) values, adjusting key usage, and extending key usage fields, can also be explored.
• The use of Pre-Shared Keys (PSKs), Group Domain of Interpretation (GDOI), and alternative methods for establishing shared keys among end devices is not recommended.
• All devices must verify the legitimacy of the certificates they rely upon. This verification should utilize mechanisms available within the PKI, such as Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP).
• Devices should be configured to validate the entire certificate chain, including the end entity certificate, all subordinate CA certificates, and the root certificate. It is advisable to maintain a PKI hierarchy that does not exceed three layers in depth.

End entity certificates must be X.509v3 certificates that possess the necessary cryptographic elements for the selected IPsec or TLS profile.

• Certificates should be generated by an administrator on the device where they will be operationally deployed, unless device-specific Security Procedures dictate alternative generation methods.
• Private keys associated with certificates must never leave the device where they are being utilized.
• End entity certificates should remain valid for a duration of one year, or for as long as the device is anticipated to be active in the network, whichever is shorter.

Certificates for Low-Number Link Support

In scenarios where only a minimal number of VPN endpoints must establish connections (e.g., long-standing data center interconnections or peering arrangements among network service providers), creating a PKI may be deemed an unnecessary burden and might not be essential. Instead, participating devices could simply have the requisite public keys of other VPN devices installed directly.

Maintaining the integrity and authenticity of these public keys is crucial; if malicious actors succeed in substituting inauthentic keys, they could effectively intercept protected information.

Certificates for Multiple Network Link Support

For more intricate networks, a PKI is vital, as it enables each VPN endpoint to authenticate the identities of other endpoints, relying on a centrally managed set of services. Careful design, implementation, and maintenance of the PKI are crucial since they are prime targets for hackers. If attackers can manipulate the PKI to register unauthorized devices or expose confidential information (such as signing keys), the network’s security may be at risk.

An x509-based PKI necessitates several physical and logical components, including a Certificate Authority (CA), a Registration Authority (RA), a root of trust, and a way to revoke certificates. The organization managing the PKI must also establish protocols and methods surrounding these components.

In most cases where a PKI is required to validate end entity cryptographic devices, its use is confined within a singular relying organization. In such situations, this organization should ensure that the employed processes and technologies are adequately secured by adhering to these key principles:

• Adopt an ‘offline root’ model, wherein the root of the PKI remains permanently disconnected from the network and powered down until necessary.
• Formulate clear procedures for enrolling and revoking devices from the PKI. These should align with associated business activities to guarantee that only anticipated endpoints possess valid certificates, and that all actions linked to the PKI are authorized and logged.

The key lifetimes for the root and subordinate CAs should align with the projected life of the network, or with the specified expiration dates (whichever is earlier). Below is a table outlining these dates:

In instances where multiple organizations rely on certificates issued by a Certification Authority, a Certificate Policy (CP) and a Certification Practice Statement (CPS) should be created and made available for all stakeholders. Key components may include:

• The CP outlines the overarching policy for the PKI.
• The CPS delineates the processes and practices that the CA adheres to when issuing certificates, enabling others to evaluate the appropriateness of these methods for reliance. Organizations are encouraged to use RFC3647 as a template for their CPS.

It is the obligation of the PKI provider to establish the CP and CPS, along with the various attributes permitted for root, subordinate, and end entity certificates. We recommend including the following in the CP/CPS:

• Appropriate certificate usage: end entity certificates shall solely be utilized for establishing encrypted links between endpoints within and across organizations.
• Certificate Revocation Lists (CRLs) must be accessible by all endpoints utilizing certificates.
• Each CRL must comprise a comprehensive listing of all unexpired certificates issued by the CA that have been revoked.
• CRLs for end entity certificates should be published at least once every 24 hours, with a recommended validity period of 192 hours (8 days, avoiding conflicts with holidays). The root CA should issue a root CRL a minimum of once per year.
• Sub CA certificates must incorporate one or more CRL Distribution Points (CDPs) with root CA CRL URIs.
• Each certificate issued must contain a non-null X.501 Distinguished Name in the certificate’s ‘subject’ name field as mandated by RFC5280. This must uniquely identify the device within the PKI.
• Values included in certificates should be considered public information, necessitating careful consideration of naming conventions to avoid accidental inclusion of sensitive or personal information.
• Anyone enrolling a device into the PKI must provide proof of access to the private key corresponding to the public key within the certificate; this is typically achieved by signing the request.
• Prior to issuing or renewing a certificate, the RA or CA must authenticate the validity of the requester’s signature and confirm approval for the request.
• Certificates will only be solicited and employed on end entity devices integrated within the network.
• All certificate requests must be associated with a business process to ensure that only anticipated devices receive or renew certificates.
• Information regarding any cross-certification with other Certification Authorities must be accessible to reliant parties.
• If any certificate has expired, been compromised, or is suspected of being compromised, routine re-keying will not take place.
• Any alterations to the information contained in the certificate should be validated through the same process as the initial registration.
• In the event of a compromised certificate (or if there is reasonable suspicion of compromise), immediate revocation is required.
• A CA must ensure a separation of duties and, when necessary, employ dual controls for critical CA functions to prevent unauthorized misuse without detection.
• User access must be limited to actions necessary for fulfilling their specific responsibilities.
• There should be a designated individual accountable for the secure ongoing operation of the shared PKI service.
• PKI services should undergo a thoroughly scoped penetration test by qualified individuals. This test should encompass both internal and external attack scenarios, along with application-layer testing.
• CA and RA private keys within PKIs should be stored in secure facilities, equipped with adequate access controls to permit entry solely by authorized personnel.
• CA and RA private keys within PKIs should be generated utilizing a mechanism or product acknowledged for this purpose by the NCSC.

4. Shared PKI Services

In certain instances, it may be beneficial for multiple organizations to utilize a single shared PKI service. This service may be managed by one organization on behalf of a broader community or supplied commercially for supporting a network of VPN links. In these cases, specific conditions regarding the central PKI infrastructure must be fulfilled by the PKI provider if the service is to be shared across several organizations.

Providers delivering PKI services to numerous clients may seek to independently verify that their processes align with the principles outlined in their Certificate Policy and that these have been executed as described in their Certificate Practice Statement, through methods like tScheme.

a. Data-in-Transit Protection

Application-layer protection should be applied to ensure the integrity and authentication of requests and responses from the PKI service. Private keys must never be exchanged through such pathways, and certificates should invariably be validated, either through established trust points or out-of-band methods. For comprehensive guidelines, refer to Cloud Security Principles.

b. Asset Protection and Resilience

Users of the PKI service must be assured that their data, as well as the assets that store or process this data, are safeguarded against physical tampering, loss, destruction, or seizure.

Practically, this entails:

• Organizations utilizing the PKI should receive details on where their data will be stored, processed, and managed.
• Physical security measures at locations providing the PKI service should be independently verified through CSA CCM v3.0, ISO/IEC 27001, or SSAE-16/ISAE 3402.
• The PKI service provider’s protocols for physical security concerning media should be independently confirmed using CSA CCM v3.0, ISO/IEC 27001, or SSAE-16/ISAE 3402.
• Components within the service provider’s infrastructure that enforce security functions should be validated to Foundation Grade where applicable.
• Assured products must be deployed to conduct the sanitization of media containing user data prior to its disposal.

c. Separation between PKI Service Customers

Logical separation among different customers of the PKI must be designed and implemented to prevent a single malicious or compromised customer from impacting another’s data or service.

Network and logical access to the PKI service should be limited to only those organizations and individuals with a legitimate business need.

A competent security architect (preferably someone with CCP-certified ‘IA Architect’ at Senior or Lead level) should be engaged. This involvement ensures that the architecture is resilient against common attacks, incorporates suitable security controls, and enables the secure operation of the PKI service.

d. Governance Framework

The PKI service provider should establish a security governance framework that orchestrates and channels their overall strategy for managing the PKI and the information contained within it.

In practice, this includes:

• The identification of a clearly named board representative (or an individual with direct delegated authority) accountable for the security of the PKI service. This is typically a Chief Security Officer, Chief Information Officer, or Chief Technical Officer.
• A documented framework for security governance must exist, comprising policies governing the critical aspects of information security relevant to the PKI.
• Security and information security must be integrated into the provider’s financial and operational risk reporting mechanisms.
• Processes must be in place to identify and ensure compliance with applicable legal and regulatory standards concerning the PKI.

e. Operational Security

The PKI service provider should implement processes and procedures assuring the operational security of the PKI. The secure operation and management of the PKI are critical for deterring, identifying, or preventing attacks against it.

In practice, this necessitates:

• Continuous tracking of the status, location, and configuration of service components (including both hardware and software) throughout their lifecycle within the PKI.
• Changes to the PKI must be evaluated for potential security impacts and managed through to completion.
• The PKI provider should monitor relevant sources for information regarding threats, vulnerabilities, and exploitation techniques.
• Any known vulnerabilities within the PKI must be monitored until suitable mitigations are implemented through an effective change management process.
• Critical patches must be deployed within 14 calendar days of availability, while important patches should be deployed within 30 calendar days.
• Events generated within PKI components must be collected to facilitate effective identification of suspicious activities and analyzed systematically.
• Incident management protocols for the PKI must be in place and activated in response to security incidents, which should be validated using ISO/IEC 27035:2011, CSA CCM v3.0, or ISO/IEC 27001.

f. Supply Chain Security

PKI service providers often depend on third-party products and services, which may affect the overall security of the PKI service. The service provider needs to confirm that any third parties it relies upon to deliver the PKI service securely meet relevant security standards outlined in this document to an appropriate degree.

g. Identity and Authentication

Access to all PKI interfaces by consumers and service providers must be limited to authenticated and authorized individuals. Weak authentication or access controls could allow unauthorized changes to the PKI, which may lead to data theft, modification, or service disruptions. Secure channels must be utilized for authentication; insecure methods such as email, HTTP, or telephone can be more vulnerable to interception or social engineering attacks.

h. External Interface Protection

All external or less trusted interfaces of the PKI service must be identified and fortified with adequate protections to guard against potential attacks. Any interface that is exposed to PKI consumers or outsiders, if inadequately secured, can be exploited by attackers to gain access to the PKI or the data it contains. If these exposed interfaces include private ones (such as management interfaces), the impact could be significantly severe.

i. Audit and Monitoring

The PKI service provider must ensure that all activities which:

• Alter the set of certificates issued by the CA (e.g., addition, deletion, modification), or
• Impact the secure operation of the PKI

are subject to audit to guarantee traceability of actions, identification of individuals involved, and, where relevant, alignment with business processes.

Access to audit logs must be restricted to read-only for appropriately authorized personnel, and audit mechanisms should be designed to protect the integrity of audit information post-creation, ensuring a failure or breach does not compromise prior records.