PKI (Public Key Infrastructure), is a framework that enables the encryption of public keys and includes their affiliated crypto-mechanisms. The underlying purpose of any PKI setup is to manage the keys and certificates associated with it, thereby creating a highly secure network environment for use by applications and hardware. X.509 certificates and public keys form the cornerstone of PKI, acting as the mechanism through which cryptography can be established for an endpoint – consequently, PKI may refer to any software, policy, process, or procedure that may be employed while configuring and managing those certificates and keys.
In a nutshell, PKI is responsible for making online interactions more secure, and it does this by:
Establishing the identity of endpoints on a network
Encrypting the flow of data via the network’s communication channels
It does this by using private keys and public keys for encryption and decryption respectively, which are facilitated in turn by digital certificates.
In today’s hyper-connected world, the need for a robust PKI cannot be understated, especially since there is an explosion in the number of devices that are capable of leveraging the internet to communicate with each other – mobile devices, IoT-enabled hardware, and payment systems are just a few examples of infrastructures that require PKI for security, without which they would expose themselves to cyber risk and also failure of compliance standards imposed upon them by various bodies.
1.3 Where is PKI applied?
Secure Browsing (via SSL/TLS)
Securing Email (signing and encrypting messages)
File Security (via Encrypted File Systems)
…and so on.
2. The Workings of PKI
2.1 The Components of an Ideal PKI
PKI infrastructures involve the participation of some or all of the below entities:
Public and Private Keys: The single most important component(s) of PKI, public and private keys are used to encrypt and decrypt the information transmitted over the web, ensuring that the sending and receiving party are the only ones privy to that information. Public key information is available openly online, but can only be effectively leveraged when the receiving party has an approved private key in order to decrypt a message.
Public Key Certificates: Electronically signed documents that verify ownership of a public key. They are as important as keys, as they act as proof that a key-holder is legitimate. They are issued by Certificate Authorities.
Certificate Repository: An electronic, searchable storage facility for signed certificates with public keys that have been generated. It consists of important certificate information, such as certificate validity details, revocation lists, and root certificates. They are often equipped with LDAP (Lightweight Directory Access Protocol), an online directory service where entries are classified and indexed.
Certificate Authority (CA): A trusted body which enables organizations to get themselves verified as public key holders. It does this by verifying a requesting organization, and generating an electronic document called a digital certificate which also holds the public key. It then signs the certificate with its own private key, which acts as a seal of approval that it is trusted by a Certificate Authority.
Registration Authority (RA): Assists the PKI cycle by verifying that the body requesting a certificate is legitimate. Once the verification is complete, it carries out the request by allowing the request to reach the CA, who uses a certificate server to execute it.
Key encryption and storage facilities: Private keys are valuable documents that can be misused if malicious actors gain access to it. Hence, they are stored in encrypted vaults with secured periodic access.
Software to manage and automate PKI operations: Since certificates act as the face of a PKI system, they have to diligently managed, since invalid certificates often result from haphazard management, making them useless measures of security. Certificate Management is a blanket domain involving practices such as issuance, revocations, renewals, and a lot more.
2.2 How does PKI Work?
Now that the anatomy of PKI has been deciphered, let’s take a look at how they can be woven together into a working cryptographic system.
Public Key Infrastructure uses Public Key Cryptography as the basis for providing encryption, with the underlying principles, procedures, and policies being part of the overlying ‘infrastructure’ that is compatible with SSL/TLS protocols. Public Key Cryptography uses asymmetric key algorithms to perform its role. According to this principle, both communicating parties establish a working relationship by verifying each other’s identities. Consider the following exchange which enables a server and a web application, for instance, a browser, to communicate with each other:
When a browser wishes to establish a secure communication channel with a web server, it requests the server to present its public key.
The server possesses an asymmetric public key, whose copy it presents to the browser.
The browser generates a ‘session key’, a symmetric key that is encrypted using the public key that the server provided. This session key is then passed to the server.
The web server, which has a unique copy of a private key, uses the private key to decrypt the session key. If it is able to do this, the browser takes it as proof that the server is safe to communicate with, and an encrypted channel is opened.
The entire exchange is facilitated by x.509 certificates (also called digital certificates or PKI certificates), since only those public keys that have been signed by a Certificate Authority and bound to a certificate are considered acceptable for use online.
2.3 The Critical Role of Certificates in PKI
Certificates are the gatekeepers to ensuring that the underlying PKI works properly. We’ve covered how certificates are linked to the Public Key Cryptography process in the previous section already – now, let’s take a brief look at the anatomy of a digital certificate.
Certificate Authorities (CAs) provide much-needed trust for the entire PKI framework. Several major CAs are trusted across the globe to provide authenticity to certificates, and by extension, signed keys. A typical certificate consists of the following information:
A Distinguished Name (DN) which is simply a unique name that identifies the user who requested the certificate.
The date of issuance and the date of expiry, so as to estimate the certificate’s lifetime.
The public key.
The purpose of the certificate, which could range from signing code to encrypting communication channels.
A digital signature, which is the CA’s guarantee that the certificate is valid and belongs to the user in question.
A digital certificate, once issued, has to be diligently managed to ensure that it remains secure. An expired certificate is of no use to anyone, and neither is a compromised one. Certificate Management is a discipline that overlaps with PKI management, and has its own set of rules and protocols that have to be followed.
3.1 Best Practices for PKI Management
Establishing and managing an ideal PKI system would involve an impeccably managed infrastructure that included certificates and keys, CAs, HSMs, associated DevOps, ITSM, and IAM tools, and a lot more. The management of each of those systems is a vast topic that we will be covering in later articles. For now, here are some high-level considerations prior to (or during, or even after) a PKI implementation.
Maintain a certificate inventory: Ensure that every certificate – currently in use, discarded, or revoke – is tracked in a centralized inventory system, where every certificate is mapped to the endpoint it is (or was) installed on. This simplifies renewals and maintenance, and removes the risk associated with rogue or unused certificates that can be exploited.
Protect private keys: Too often, private keys are stored on and shared in the form of text documents, or password-protected files. This is a bad practice, since a compromised private key to a root or intermediate CA could sabotage an entire portion of a network. Ensure that you use HSMs that meet compliance requirements (FIPS 140-2) to store keys, and secure vaults to store passwords. Ideally, a private key should undergo automated rotation from within the HSM, and should never be manually handled by a human.
Use certificates issued by trusted CAs: For external use, ensure that you purchase certificates that are issued by globally trusted Certificate Authorities, as opposed to self-signed certificates. These self-signed certificates are usually issued for internal use, and are signed by your own organization – they are common in testing scenarios. However, using such certificates on external-facing applications or endpoints results in that endpoint not being trusted, and also highly vulnerable to misuse.
Rotate certificates, keys, and SSH keys: Public Key Infrastructure certificates are increasingly becoming more short-lived by the day. However, don’t restrict yourself to the limits set by browsers. Certificates with shorter validities are always more secure (new technology like DevOps, IoT, and cloud applications are already on board the short-lived certificate train), and naturally, the keys have to be rotated when the certificates are renewed, too. SSH keys must also be rotated on a frequent basis, since they’re password-based and can be cracked easily if left stale for a long period of time.
Establish policy: Create and enforce PKI management policies with regard to role-based access to crypto-assets, certificate renewal durations, and PKI audit/audit trails. By creating transparency and clearly defined rules, the chances of mismanagement-induced vulnerabilities are lowered, and errors, if any, can easily be tracked and remediated.
Practice crypto-agility: Imbue PKI with a system of control that allows for accelerated manipulation of its constituent systems. This includes the ability to quickly rotate certificates, expedite the enrollment/renewal/revocation process with CAs, and rapidly switch out outdated algorithms and protocols with new ones. The logic behind crypto-agility is that an administrator should be able to quickly remediate vulnerabilities in a crypto-system without disrupting the network environment as a whole. This is an ability that comes in handy when existing methods are phased out in favor of new ones. Some examples include the switch from SHA-1 to SHA-2, and the deprecation of TLS 1.0 and 1.1, in favor of 1.2 and 1.3.
3.2 Cloud PKI vs. On-Premise PKI
For reasons that involve security, accessibility, ease of use, and overhead costs, organizations may choose to pick either on-premise PKI deployments, or cloud-based ones.
On-premise is the deployment method traditionally used by most established PKI providers. Here, the PKI is installed on the organization’s own servers – it is administered and governed by the organization’s internal PKI team, and the root certificate is kept in a highly secure location within this infrastructure. Many providers of external CAs exclusively provide on-premise PKI, as it is considered to be more secure than the alternative (hosting a PKI elsewhere) – this is primarily because on-prem setups retain full control over the private keys and certificate issuance process. However, on-premise offerings have certain shortcomings, which come in the form of increased complexity and associated costs, including a need to procure:
Highly skilled PKI administrators/personnel
Secure physical facilities
Robust PKI management software
Disaster recovery mechanisms and backups
An characteristic that PKI deployments absolutely must possess is scalability i.e the ability to grow and change in an agile fashion, without requiring a complete overhaul of the system to do so. This is a challenge many on-premise PKI providers struggle with, as all of the infrastructure is on the client’s servers, and hence, requires significant physical efforts to redesign or upgrade.
Cloud PKI is the modern alternative to its on-premise cousin. Here, the entire PKI is hosted on the provider’s servers, and PKI is supplied to clients on-demand. This way, the client receives all the benefits of a full-fledged public PKI, without having to deal with the hosting, maintenance, and physical management costs involved. There is also the assurance of 100% availability, since the back-end is handled exclusively by the providers. This allows for relatively easier scalability, since the cloud PKI provider handles installations, maintenance, security, and backups, and provides only the necessary PKI to the client on-demand.
Furthermore, since cloud-based PKI usually operates on a pay-as-you-go basis, the costs incurred by customers are also significantly lower (as opposed to the considerable fixed costs incurred by practitioners of on-premise PKI).
3.3 Risks Associated with Improper PKI Management
‘Improper PKI Management’ is a blanket term for Public Key Infrastructure handling techniques that leave room for error, malfunction, or compromise. These less-than-ideal techniques usually fall into one of four categories: a lack of visibility, agility, integration, and/or automation. When best practices are not adhered to, crypto-systems run the risk of encountering service outages or data breaches and information compromise.
Lack of visibility into PKI: This is the most common cause of expired certificates, and by extension, certificate outages. With a deluge of certificates in the system, admins cannot effectively keep track of which certificate is installed on which endpoint, where it is located, and when it is expired. This makes it exponentially harder for operators to find, renew, and update every certificate well before its expiration – and when the number of certificates runs into the thousands, that’s just an outage waiting to happen.
Lack of crypto-agility: Crypto-agility is the ability of a system to rapidly switch between cryptographic assets (algorithms, hashes, certificates, kets etc.) in bulk without disrupting the rest of the system. This is critical, because Public Key Infrastructure is continually evolving, and so are threats. When a vulnerability in the system is discovered, it is in the Public Key Infrastructure owner’s best interest to resolve it as soon as possible by updating all applicable crypto mechanisms across the board. However, due to scattered, siloed, and non-centralized systems, this process may take months, which is a significantly large window during which the vulnerability can be exploited.
Lack of effective integration: PKI does not work as a standalone system – this is a known fact. It works in conjunction with several other pieces of software and hardware – browsers, servers, HSMs, ITSM systems, ticketing systems, password vaults, and so on. More recently, PKI has also been widely deployed across technology like cloud software, DevOps tools, CI/CD tools, containers, and IoT devices – new and unfamiliar territories for Public Key Infrastructure. It is imperative that there is a solid three-way synergy between the Public Key Infrastructure, the PKI management interface, and the third-party software/hardware in order for operations to remain smooth. The consequence of not having a functioning integration in place is the obvious latency – for instance, policy may dictate that outgoing code in a DevOps pipeline must be signed by a certificate. However, if certificate requisition is a slow, standalone process, this causes delays in the code/software being published. There is also the security risk associated with a disconnected between PKI and service provider – if an administrator relies on a HSM to circulate keys, and the integration between the PKI and the HSM is not airtight, there is a chance that the key can be snatched by malicious actors while it is in the process of being rotated between the endpoint and the HSM.
Lack of automation: Conventionally seen as a luxury and not a necessity, this viewpoint is rapidly changing, given the massive uptick in certificate and key counts in any given system. With hundreds of thousands of certificates in circulation, administrators simply cannot rely on manual management techniques to ensure that Public Key Infrastructure is constantly secure and up-to-date. Spreadsheets are not cut out for the management of ‘big’ data. There is a pressing need for a management system that includes alerting processes and automated workflows for Public Key Infrastructure tasks such as certificate renewal, requisition, revocation, deployment, and so on.
While no PKI management process can be perfect, organizations must strive to follow the mandated best practices to ensure that they minimize the chances of outages or breaches affecting their organizations.