Provisioning and securing security certificates

To establish secure IPsec and TLS VPN connections, certificates based on a centralized trust infrastructure are necessary for devices and gateways to recognize one another. X.509v3 certificates for all authorized endpoints must be generated and registered within the trust infrastructure. It is crucial to ensure that unauthorized certificates cannot be registered, maintaining the trustworthiness of the centralized infrastructure.

The trust infrastructure, often referred to as Public Key Infrastructure (PKI), is typically managed by the organization providing encryption services. Organizations may form trust relationships with other PKIs from different service providers and networks to facilitate encrypted connections among devices controlled by various entities.

Due to their critical role, PKIs are attractive targets for attackers. The sensitive information they hold, particularly private keys, and their trust-providing functionality mean any security breach within a PKI could lead to significant and hard-to-detect consequences. Therefore, it is vital to safeguard PKIs from potential threats. Accordingly:

• It is advisable to avoid sharing PKIs between communities with vastly different security needs or operational frameworks (e.g., using a commercial PKI for public sector organizations).
• At the design phase, assess the use of the PKI for various service types (IPsec, TLS, S/MIME, etc.). We recommend utilizing distinct sub Certificate Authorities (CAs) for different technology functions to hinder the malicious use of compromised certificates across services. Alternative strategies, such as applying separate Certificate Policy OID (CPOID) values, key usage, and extended key usage fields, may also be effective.
• Using Pre-Shared Keys (PSKs), Group Domain of Interpretation (GDOI), and similar methods for establishing shared keys across end devices is not recommended.
• All devices must verify that the certificates they depend on are valid. This should involve accessing and utilizing mechanisms that check certificate statuses in the PKI, like Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol (OCSP).
• Devices should be configured to verify the validity of the entire certificate chain, including the end entity certificate, any sub CA certificates, and the root certificate. PKI hierarchies are recommended to be no more than three layers deep.

End entity certificates will consist of X.509v3 certificates featuring the appropriate cryptographic components for the selected IPsec or TLS profile.

• Certificates should be generated by an administrator on the device that will utilize them, except where specific Security Procedures for that device propose alternative generation methods.
• Private keys associated with certificates must remain exclusively on the device being used operationally.
• Certificates for end entities should have a validity of one year or for the anticipated lifespan of the device on the network, whichever is shorter.

Certificates supporting single or low numbers of links

If only a limited number of VPN endpoints require establishing links (for instance, a long-term data center to data center connection or peering agreements between network service providers), deploying a PKI may be unnecessary. Instead, participating devices can have the relevant public keys of other VPN devices installed directly on them.

Maintaining the integrity and authenticity of these public keys is critical. If an attacker succeeds in installing incorrect keys, they could potentially intercept information that should remain confidential.

Certificates supporting multiple network links

In more complex network configurations, a PKI becomes essential. The PKI allows each VPN endpoint to confirm the identity of other endpoints, depending on a centralized set of services. The design, implementation, and management of a PKI is crucial, as these structures are prime targets for attackers. If a PKI is tricked into registering unauthorized devices or revealing private information (like signing keys), the network’s security could be compromised.

An X.509-based PKI necessitates several physical and logical components, including a Certificate Authority (CA), a Registration Authority (RA), a root of trust, and a system for revoking certificates. The organization managing this PKI must establish rigorous processes around these components.

In most scenarios where a PKI is essential for identifying end entity cryptographic devices, its use should be confined to a single relying organization. In such cases, the organization must adopt the following key practices to ensure secure operations:

• Implement an ‘offline root’ model, wherein the root of the PKI remains disconnected from the network and powered off until needed.

• Create robust protocols for enrolling and revoking devices in the PKI, in line with related business activities to ensure that only anticipated endpoints are granted valid certificates and all PKI actions are authorized and audited.

The lifetimes of the root and sub CAs should align with the expected lifespan of the network or follow specific dates (whichever comes first). The dates outlined in the table below will be periodically reviewed and updated as needed.

When multiple organizations rely on certificates from a Certification Authority, a Certificate Policy (CP) and Certification Practice Statement (CPS) must be created and shared with all involved parties:

• The CP outlines the overarching policy for the PKI.
• The CPS describes the processes a CA follows to adhere to the CP during certificate issuance and enables others to evaluate whether these methods are reliable; organizations should use RFC3647 as a guideline for their CPS.

The PKI provider is responsible for defining the CP and CPS, along with the various permitted attributes for the root, sub CA, and end entity certificates. We advise that the following items are included in a CP/CPS:

• Appropriate certificate usage: end entity certificates shall only be employed for creating encrypted links between endpoints within and between organizations.
• Certificate Revocation Lists (CRLs) must be readily accessible to all endpoints utilizing certificates.
• Each CRL must comprehensively list all unexpired certificates issued by the CA that have been revoked.
• CRLs for end entity certificates should be published at least every 24 hours, with a recommended validity period of 192 hours (8 days to avoid collisions with bank holidays). The root CA should issue a root CRL at least once a year.
• Sub CA certificates should include one or more CRL Distribution Points (CDPs), reflecting the root CA CRL URIs.
• Each issued certificate must have a non-null X.501 Distinguished Name in the ‘subject’ name field in accordance with RFC5280. This should uniquely identify the device within the PKI.
• Values included in certificates must be treated as public information; hence, careful attention should be given to naming conventions to avoid unintentionally revealing sensitive or personal data.
• Anyone enrolling a device into the PKI must prove they have access to the private key corresponding to the public key in the certificate, typically by signing the request.
• Before issuing or renewing a certificate, the RA or CA must verify that the signature on the request is valid and that it is authorized.
• Certificates will only be requested and utilized on end entity devices that form a part of the network.
• All certificate requests must be linked to a business process to ensure that only expected and legitimate devices are granted or reissued certificates.
• Details on any cross-certification with other Certificate Authorities must be transparent to relying parties.
• In the event of a certificate expiring, being compromised, or suspected of compromise, routine re-keying must be avoided.
• If any information in the certificate changes, modifications must be authenticated similarly to the initial registration.
• If a certificate is suspected to be compromised, it should be revoked immediately.
• A CA must ensure separation of duties, employing dual control where necessary for critical CA functions to protect against malicious exploitation without detection.
• Each user’s access must be limited to actions necessary for fulfilling their designated responsibilities.
• An accountable individual should be designated to oversee the secure, ongoing operation of the shared PKI service.
• PKI services should undergo rigorous penetration testing by competent individuals, covering both internal and external threats, along with application-layer evaluations.
• CA and RA private keys must be stored in secure environments, with robust access controls allowing entry only for authorized personnel.
• Private keys for CA and RA must be generated using methods or products certified by the NCSC.

4. Shared PKI services

In certain cases, it may be beneficial for several organizations to utilize a single shared PKI service. This service might be managed by one organization on behalf of a broader community or provided by a commercial vendor to support a group of VPN links. If this occurs, the PKI provider must implement specific measures regarding the central PKI infrastructure if their PKI is intended for shared use across multiple organizations.

Providers offering PKI services to various customers should consider demonstrating that their processes align with the principles established in their Certificate Policy and are executed as documented in their Certificate Practice Statement using frameworks like tScheme.

a. Data-in-transit protection

Application-layer protections need to be applied to ensure the integrity and authentication of requests and responses from the PKI service. Private keys should never be exchanged over these links, and certificates should consistently be validated either through recognized trust points or via out-of-band mechanisms. For additional details, refer to Cloud Security Principles.

b. Asset protection and resilience

Users of the PKI service should be assured that their data, as well as the assets that store or process that data, are safeguarded against physical interference, loss, damage, or theft.

This entails:

• Organizations using the PKI should be informed about the locations where their data will be stored, processed, and managed.
• The physical security of facilities providing the PKI service should be independently verified against standards such as CSA CCM v3.0, ISO/IEC 27001, or SSAE-16 / ISAE 3402.
• The PKI provider’s procedures for the physical security of data storage media should also be validated independently through the aforementioned standards.
• Security-enforcing components within the service provider’s architecture should be validated to Foundation Grade where feasible.
• Assured products should be utilized for the sanitization of media containing user information prior to disposal.

c. Separation between customers of the PKI service

A logical separation between different PKI customers should be architected and implemented to prevent a singular malicious or compromised customer from influencing the service or data of others.

Network access and logical access to the PKI service should be restricted only to organizations and individuals with a business justification.

A qualified security architect, such as an individual certified as a ‘Senior’ or ‘Lead’ IA Architect, should be involved to ensure the architecture effectively counters common attacks, incorporates suitable security controls, and allows secure operational functionality of the PKI service.

d. Governance framework

The PKI service provider should implement a security governance framework that guides and organizes their approach to managing the PKI and the information therein.

This means:

• A designated, identifiable, and accountable individual (often a Chief Security Officer, Chief Information Officer, or Chief Technical Officer) is tasked with the security of the PKI service.
• A documented governance structure regarding security must exist, encapsulating policies that govern essential aspects of information security linked to the PKI.
• Security concerns must be incorporated into the provider’s financial and operational risk reporting systems.
• Processes to ensure compliance with applicable legal and regulatory requirements pertaining to the PKI should be established.

e. Operational security

The PKI service provider should establish processes and procedures to guarantee the operational integrity of the PKI. Secure operation and management are required to detect, impede, or prevent attacks against it.

This entails:

• The status, location, and configuration of service components (including both hardware and software) must be consistently tracked throughout their life cycle in the PKI.
• Changes within the PKI should be evaluated for potential security impacts. All changes must be managed and monitored to completion.
• Information regarding threats, vulnerabilities, and exploitation techniques must be diligently monitored by the PKI provider.
• Known vulnerabilities within the PKI should be documented until appropriate mitigation measures have been implemented through a systematic change management process.
• ‘Critical’ patches should be applied within 14 calendar days of their availability; ‘important’ patches should be deployed within 30 calendar days.
• Events created in PKI components that are necessary for detecting suspicious activities should be collected and analyzed.
• Incident management procedures should be in place for the PKI, enacted in response to security incidents, and validated against standards such as ISO/IEC 27035:2011, CSA CCM v3.0, or ISO/IEC 27001.

f. Supply chain security

PKI service providers frequently rely on third-party products and services, which can influence the overall security of the PKI service. The provider must ensure any third parties they depend upon for securely delivering their PKI service (such as hosting services) also adhere to relevant security principles outlined in this document at an appropriate level.

g. Identity and authentication

Access to all PKI interfaces by consumers and service providers must be restricted to authenticated and authorized individuals. Weak authentication methods or lax access controls could allow unauthorized modifications to the PKI, potentially leading to data theft or alteration, or denial of service. Furthermore, authenticated communications must occur over secure channels to mitigate the risk of interception or social engineering attacks through insecure mediums like email or unencrypted traffic.

h. External interface protection

All external or less secure interfaces of the PKI service should be individuated and subject to appropriate protections to defend against possible attacks. If an interface exposed to PKI consumers or external parties is inadequate, attackers might exploit it to gain access to the PKI or its information. The consequences would be even more severe if management interfaces are also exposed.

i. Audit and monitoring

The PKI service provider must ensure that all actions that:

• alter the certificates issued by the CA (e.g., addition, deletion, modification), or
• affect the secure functioning of the PKI

are logged in a manner that maintains action traceability, identifies the responsible individuals, and connects to the appropriate business processes.

Access to audit logs must be restricted to authorized personnel, and auditing mechanisms should be designed to safeguard the integrity of the audit information post-creation to prevent any prior audit data from being compromised in case of a failure or breach.