Provisioning and securing security certificates

For most IPsec and TLS VPN connections, devices and gateways are required to utilize certificates derived from a centralized trust infrastructure to appropriately identify themselves to one another. End entity X.509v3 certificates need to be generated for all authorized endpoints and appropriately registered with the trust infrastructure. The processes involved must prevent unauthorized certificates from being registered, ensuring the integrity of the centralized infrastructure remains intact.

The trust infrastructure, commonly known as a Public Key Infrastructure (PKI), is typically maintained by the organization providing the encryption service. This local PKI may engage in trust relationships with other PKIs from various service providers and networks to facilitate encrypted connections among devices controlled by distinct organizations.

PKIs represent significant targets for cybercriminals. The sensitive data they harbor (particularly private keys) and their pivotal function in establishing trust means any security breach within a PKI can result in extensive and hard-to-detect ramifications. Therefore, securing PKIs against potential attacks is critical. Hence:

• It is strongly advised that PKIs not be shared among groups with substantially different security requirements or operational protocols (e.g., a PKI intended for commercial use should not be shared with public sector entities).
• The prospective diversity of services supported by the PKI (such as IPsec, TLS, and S/MIME) should be factored into the design phase. We recommend utilizing separate sub CAs for different technological functions to minimize the risk of a malicious actor exploiting a compromised certificate across various services. Alternative strategies might involve using various Certificate Policy OID (CPOID) values, key usage, and extended key usage fields.
• We discourage the use of Pre-Shared Keys (PSKs), Group Domain of Interpretation (GDOI), and similar methods for creating shared keys across end devices.
• All devices are responsible for confirming the validity of the certificates they depend on. This process should include accessing and employing mechanisms for checking certificate status within the PKI, like Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol (OCSP).
• Devices should be programmed to verify the validity of the complete certificate chain, encompassing the end entity certificate, any sub CA certificates, and the root certificate. It is advisable for PKI hierarchies to be structured with no more than three layers.

End entity certificates will be X.509v3 certificates that contain the necessary cryptographic elements for the chosen IPsec or TLS profile.

• Certificates should be created by an administrator directly on the device where they will be utilized, unless specific security protocols for that device suggest alternative generation methods.
• Private keys associated with certificates must never be transferred from the device used operationally.
• End entity certificates should typically have a lifespan of one year or match the anticipated duration of the device’s presence on the network (whichever is shorter).

Certificates for Low-Volume Connections

When only a minimal number of VPN endpoints are needed (as in the case of a long-term data center connection or peer relationships between network service providers), establishing a full PKI may not be necessary and could impose unnecessary overhead. Instead, each participating device can have the public keys of the other VPN devices directly installed.

Ensuring the integrity and authenticity of these public keys is vital. Should an attacker succeed in installing incorrect keys, they can intercept protected information.

Certificates for Broad Network Connections

For more intricate networks, a PKI will be essential. The PKI functions as a mechanism for each VPN endpoint to authenticate the identities of other endpoints, relying on a centralized set of services. The design, deployment, and management of a PKI warrants careful consideration, as they are appealing targets for attacks. If an attacker manages to manipulate the PKI into validating unauthorized devices or acquiring sensitive information (like signing keys), the security of the entire network could be compromised.

An X.509-based PKI will consist of various physical and logical components, including a Certificate Authority (CA), a Registration Authority (RA), a root of trust, and systems for revoking certificates. The organization managing this PKI will need to develop comprehensive processes concerning these elements.

In most scenarios where a PKI is pivotal for authenticating end entity cryptographic devices, its use will typically be confined within a single trusting organization, which must ensure that processes and technologies employed are tightly controlled by adhering to the following principles:

• Adopt an ‘offline root’ model that keeps the root of the PKI permanently disconnected and powered off until it is necessary to use.

• Define and document processes for enrolling and revoking devices within the PKI that align with related business functions, ensuring that only expected endpoints within the trusted infrastructure possess valid certificates, and that all PKI-related activities are authorized and logged.

The lifespans for root and sub CA certificates should match the expected lifespan of the network or adhere to the specified expiration dates noted below (whichever is shorter). We will review and update these dates as necessary.

If multiple entities will be relying on the certificates issued by a Certification Authority, it is essential to produce a Certificate Policy (CP) and Certification Practice Statement (CPS) for distribution to all involved parties:

• The CP outlines the general policy governing the PKI
• The CPS details the procedures applied by a CA to comply with the CP when issuing certificates, enabling organizations to assess whether those processes and practices are trustworthy; it is recommended to use RFC3647 as a template for their CPS.

The PKI provider is accountable for defining the CP and CPS, along with the various permissible attributes of the root, sub CA, and end entity certificates. It is recommended that the following elements be included in a CP/CPS:

• Designated certificate usage: end entity certificates should solely be employed for the establishment of encrypted links among endpoints either within or between organizations.
• Certificate Revocation Lists (CRLs) must be accessible to all entities utilizing certificates.
• Every CRL should feature a comprehensive listing of all unexpired and revoked certificates issued by the CA.
• For end entity certificates, CRLs should be published at least once every 24 hours, ideally with a validity period of 192 hours (8 days, to avoid conflicts with holidays). The root CA ought to publish a root CRL annually.
• Sub CA certificates should include one or more CRL Distribution Points (CDPs) that provide the URIs for the root CA CRL.
• Each issued certificate must have a non-null X.501 Distinguished Name in the subject name field, as specified in RFC5280. This must uniquely identify the device within the PKI.
• Certificate values should be treated as public information, hence careful consideration should be given to naming conventions to avoid unintentional inclusion of sensitive information.
• Anyone enrolling a device into the PKI must prove they have access to the private key linked to the public key in the certificate; this is generally validated by signing the request.
• Before issuing or reissuing a certificate, the RA or CA must confirm the validity of the requester’s signature and verify that the request is authorized.
• Certificates will be requested and utilized strictly on end entity devices that partake in the network.
• All certificate requests must correlate with a business process to guarantee that only the expected and appropriate devices receive and retain certificates.
• Information regarding any cross-certifications with other Certificate Authorities must be accessible to all relying parties.
• If a certificate has expired, been breached, or is suspected of a breach, routine re-keying should not be undertaken.
• Any modifications made to certificate information must be authenticated similarly to the initial registration.
• Upon the compromise of a certificate (or reasonable suspicion thereof), immediate revocation is required.
• A CA must maintain separation of duties, employing dual control where necessary, to prevent unauthorized exploitation of the CA system by a single individual.
• Users’ access should be limited to the actions they need to perform for their designated roles.
• An individual must be appointed to oversee the secure ongoing operation of the shared PKI service.
• PKI services should undergo a thorough penetration test conducted by qualified professionals. The scope of this assessment should include both internal and external threats as well as application-layer testing.
• Private keys for CAs and RAs must be stored in secure environments with appropriate access controls, permitting entry to authorized individuals only.
• Private keys must be generated utilizing methods or products approved by the NCSC.

4. Shared PKI Services

In certain circumstances, it is advantageous for multiple organizations to utilize a shared PKI service. This service may be operated by one organization on behalf of a larger community or provided by a commercial entity to support a VPN link community. If so, the following measures pertaining to the central PKI infrastructure should be enforced by the PKI provider when shared across different organizations.

PKI providers catering to multiple clients may opt to independently validate that their processes align with the principles outlined in their Certificate Policy and have been executed according to their Certificate Practice Statement by utilizing measures such as tScheme.

a. Data-in-Transit Protection

Application-layer safeguards should be employed to ensure the integrity and validation of requests and responses from the PKI service. Private keys must never be exchanged across these channels, and certificates should always be authenticated through established trust points or via out-of-band methods. For further insights, consult Cloud Security Principles.

b. Asset Protection and Resilience

Users of the PKI service must feel confident that their data, as well as the assets that process or store it, are shielded against physical tampering, loss, damage, or seizure.

In practice, this entails:

• Organizations using the PKI should be informed about where their data is being stored, processed, and managed.
• The physical security of locations providing the PKI service should be independently validated by CSA CCM v3.0, ISO/IEC 27001, or SSAE-16 / ISAE 3402.
• The PKI service provider’s protocols for the physical security of media must be independently validated via CSA CCM v3.0, ISO/IEC 27001, or SSAE-16 / ISAE 3402.
• Components within the service provider’s architecture that perform security functions should attain Foundation Grade where applicable.
• Secure products must be utilized for the sanitization of media containing user information prior to disposal.

c. Separation between PKI Service Customers

Logical separation between various users of the PKI must be designed and executed to prevent a single compromised or malicious customer from affecting the service or data of another.

Access to the PKI service should be restricted to those organizations and individuals with a legitimate business need.

Engaging a skilled security architect (such as someone certified in CCP-certified ‘IA Architect’ at Senior or Lead level) is essential. This will ensure that the architecture is resistant to common attacks, features appropriate security controls, and facilitates the secure operation of the PKI service.

d. Governance Framework

The PKI service provider must have a security governance framework that coordinates and guides their overall approach to managing the PKI and the information it contains.

In practical terms, this means:

• A clearly identified and named board representative (or a designated individual with direct authority) must be in charge of the security of the PKI service. Typically, this will be a Chief Security Officer, Chief Information Officer, or Chief Technical Officer.
• A documented governance framework must exist, outlining security policies that govern key aspects of information security related to the PKI.
• Security and information security considerations should be integrated into the service provider’s financial and operational risk reporting mechanisms.
• Processes must be in place to identify and ensure compliance with applicable legal and regulatory obligations pertinent to the PKI.

e. Operational Security

The PKI service provider should establish processes and procedures to ensure the operational security of the PKI. Securing and managing the PKI efficiently is pivotal to thwarting, recognizing, or preventing attacks targeting it.

Practically, this entails:

• Monitoring the status, location, and configuration of service components (including both hardware and software) throughout their lifecycle within the PKI.
• Assessing the security implications of any alterations to the PKI, managing and tracking changes until completion.
• The PKI provider must stay informed by tracking relevant information regarding potential threats, vulnerabilities, and exploitation methods.
• Tracking known vulnerabilities until adequate mitigations are implemented through a suitable change management process.
• Deploying ‘critical’ patches within 14 calendar days of their announcement; deploying ‘important’ patches within 30 calendar days.
• Collecting event data from PKI components required to assist in identifying suspicious activities, and integrating these into an analysis system.
• Establishing incident management processes applicable to the PKI and acting upon any security incidents, validated using standards such as ISO/IEC 27035:2011, CSA CCM v3.0, or ISO/IEC 27001.

f. Supply Chain Security

PKI service providers often rely on external products and services. These third parties can negatively impact the security of the overall PKI service. The service provider should ensure that any third parties involved in securely delivering the PKI service (like hosting services) meet relevant security principles outlined in this document to an acceptable standard.

g. Identity and Authentication

Access to all PKI interfaces by consumers and service providers must be restricted to authenticated and duly authorized individuals. Weak authentication or access control may enable unauthorized modifications to the PKI, potentially resulting in data theft, alteration, or denial of service. Additionally, authentication processes must be conducted over secure channels; utilizing insecure methods such as email, HTTP, or telephone can increase vulnerability to interception or social engineering attacks.

h. External Interface Protection

All external or less secure interfaces of the PKI service should be identified and equipped with adequate protections to fend off attacks. If an interface is accessible to PKI consumers or outsiders and lacks robustness, attackers may exploit it to gain access to the PKI or its data. The risk may escalate significantly if exposed interfaces include private management ones.

i. Audit and Monitoring

The PKI service provider must ensure to audit all activities that:

• result in changes to the certificates issued by the CA (e.g., addition, deletion, or modification), or
• impact the secure operation of the PKI.

These audits must enable traceability of actions, identify responsible individuals, and link to the corresponding business process when applicable. Access to the audit log should be restricted to authorized personnel, and auditing mechanisms ought to be designed to safeguard the integrity of audit data post-creation to prevent loss of evidence in case of a breach or failure.