The Certificate Lifecycle
Whether it is generally known outside of select groups, Public Key Infrastructure is at the heart of digital communication. PKI is a framework covering encryption, policies and procedures to protect communication and verify identities. PKI has at its core the concept of trust, digital certificates are used as a trusted and secure electronic signature providing verified user identity, document integrity, time stamp, and non-repudiation of signed electronic documents. As certificates are used as the basis of these trust relationships it is critical that the certificates are managed and secured in a robust procedural manner.
The Life of a Certificate
As with most assets a certificate goes through a number of defined phases throughout its life from creation through to destruction.
Enrollment
A certificate begins life when a request is made to a certificate authority(CA). The request made to the CA contains the public key and enrollment information. Once a request is made the CA follows strictly defined processes to verify and validate the information supplied. Once happy with the validation the CA creates the certificate, posts the certificate and sends an identifying certificate back to the user. With the distribution of the certificate the CA also sets what the certificate can be used for through policies.
Validation
When a certificate is used the certificate status is checked to verify that the certificate is valid. During the validation process, the CA checks the status of the certificate and that the certificate is not on its Certificate Revocation List (CRL).
Revocation
When a certificate is issued it has an expiration date after which it is no longer valid. If for some reason before that date a certificate needs to be withdrawn it can be added to the CA’s CRL. There are numerous reasons why a certificate may need to be revoked such as the certificate being lost or compromised, or the user who was issued the certificate leaving the company.
Renewal
When a certificate reaches its expiration it needs to be renewed. The renewal can happen automatically or manually. The renewal of a certificate can be completed with or without new public and private keys.
Destruction
When a certificate is no longer required it along with any backup copies and the private key should be destroyed. This ensures that the certificate cannot be compromised and used maliciously.
Auditing
For effective operation of a PKI infrastructure it is essential to track all lifecycle events for the certificates such as certificate creation, expiration, destruction and revocation. This ensures that you have a complete record of all activities pertaining to certificates that can be reviewed to maintain the integrity of the overall PKI infrastructure.
The Importance of Certificate Lifecycle Management
The lack of certificate management throughout the lifecycle poses many risks, the risks are evident from the beginning of the lifecycle with key generation and ending with the destruction or revocation of the certificate.
The most serious implications of poor security controls or a lack of proper processes throughout the lifecycle are where a public Certificate Authority(CA) is proven to be compromised resulting in the revocation of trust. Some examples of potentially compromised CA are DigiNotar in 2011 and more recently Comodo have been associated with a number of issues which are well documented elsewhere.
The processes implemented for the management of the certificate lifecycle should include checks to identify or prevent common risks such as:
- the use of weak algorithms
- appropriate choice of certificate type and options for the defined use case
- secure management and access control of private keys
- clear assignment of accountability and responsibility for keys and associated processes
- clearly defined process and mechanism for secure key distribution
- revocation of keys for unused/inactive systems and devices/people through JML or MACD processes
- maintenance and management of CRL
Appropriate management of certificates and PKI does not end with the policies surrounding the issuing, use and destruction of the certificates themselves. The methods and protocols used by the systems and infrastructure that utilise the certificates to provide secure access also need to be considered. One such example is ensuring that the versions of TLS being used are secure. This is often a compromise as for example compatibility is a huge consideration a current example is the transition from TLS1.2 to TLS1.3. TLS1.2 has some well known and documented vulnerabilities which may allow “man in the middle” attacks. TLS1.3 removes the mechanisms for these attacks to be perpetuated but the support for TLS1.3 is lacking at the time of writing meaning that currently closing these security holes could result in a loss of access for some users.
It is also vital that the keys are stored in a secure manner with a comprehensive access control and audit trail. An example of the implications of stolen keys is the distribution of malware signed with genuine keys. Commercial software is signed with digital certificates to verify that they originated from a verified source and have not been altered. Operating systems and devices verify that the signatures are valid before they will install the software. During Software Code Signing the software publisher generates a pair of cryptographic keys computes a cryptographic hash of the executable code and signs the hash with the private key. To prove that it owns the code signing key the software publisher requests a digital certificate from a CA. The certificate includes the name of the publisher, its public key. If the keys are stolen they can and are used to sign either purely malicious code or modified code that has had malware included. As this code is signed with genuine keys upon installation the code is verified as being genuine and installed as being distributed from the genuine software publisher.
The most secure way of securing digital keys is through using Hardware Securing Modules when associated with appropriate process and management.
Need help with your HSM?
KT Secure have extensive experience using and managing Hardware Security Modules. Whether you are looking for advice on how to use a HSM in your PKI infrastructure, offload your cryptographic operations to a HSM or looking for someone to deploy and manage your HSMs we can help. Look here for more information about our HSM service offerings.
Although it may seem counter intuitive as to why an organisation may want to outsource the management of its HSMs to a third party – there are numerous business benefits:
- Staff costs saved on both initial training and on-going certifications
- Allows key Staff to focus on less admin related tasks and focus on higher end business processes
- Utilising external supplier may provide more rapid deployment and business agility than internal resources
- Ability to leverage external experience in best practices, process definitions and documentation support
- Reduces vendor or solution tie in by utilising external expertise
