What are the five steps to consider before implementing PKI Security?

Read time: 10 minutes

Public Key Infrastructure (PKI) is the hardware, software, processes, and policies to manage certificates and keys. PKIs are the foundation for using digital signatures and various techniques of encryption for large user populations. It is also responsible for delivering essential elements for a secure and trusted business environment for IoT and other technical sectors. New-generation applications rely greatly on PKI technology for high assurance of securing electronic interactions using authentication and compliance with security regulations. Also, it helps in identifying devices, services, and users by enabling controlled access to systems and resources, data protection, and accountability in transactions. 

Role of Certificate Authorities (CAs)

For binding public keys with their associated users, PKIs make use of digital certificates. The main target is to verify the trustworthiness and authenticity of a domain, website, and organization for secure and trusted communication between the entity and users. A user will know whether a website is official and not a fake or spoofed one if a CA issues a digital certificate. This ensures that an attacker does not steal private data, information, or money from the user.

The key or crucial roles of a CA are:

• Issuing digital certificate.
• Helping establish trust between entities communicating over the Internet.
• Verifying and validating identities of domain names and organizations.
• Maintaining the Certificate Revocation lists.

How does a Digital Certificate work?

A digital certificate acts as a credential for validating the identity of the selected entity to whom it is being issued. It contains information about the entity, including its name, organization, contact information, public key, domain name, certificate issue, expiry date of the issued certificate, and so on. Also, the name of the issuing CA for that certificate and its digital signature is included in the digital certificate. It is also beneficial for encrypting and securing communication over the internet, maintaining the integrity of signed documents using it, and ensuring that no third party can corrupt the documents while they are in transit. 

How do SSL/TLS certificates work?

The Transport Layer Security (TLS) protocol makes use of SSL certificates to authenticate and encrypt data for streaming for Hypertext Transfer Protocol Secure (HTTPS). The SSL protocol is used for creating a secure connection over the internet through web browsers that connect to websites. To create an HTTPS connection, SSL works on top of HTTP, while TLS is an upgraded version of SSL. When a web browser starts a secure connection over the HTTPS, the digital certificate (SSL/TLS digital certificate) is sent to the web browser. Now, the browser verifies the information in the certificate against its root certificate store. This way, a digital certificate establishes a secure and encrypted connection between a user’s browser and a website’s or organization’s web server.

How does a Certificate Authority issue a digital certificate?

As an important component of PKI, a digital certificate is required by the SSL/TLS certificates to work properly, and this is where the CA comes in.

An organization or a person can request a digital certificate from a CA, but first, it needs to generate a key pair consisting of the following:

• Private key

  This key is always kept secret and is not supposed to be shown to anyone, not even the CA.

• Public key

  This key is mentioned in the digital certificate that the CA issues, where the applicant also must generate Certificate Signing Request (CSR). A CSR is an encoded text file specifying the information that is supposed to be included in the certificate, like domain name, organization, contact details, and alternative or additional domain names (which include subdomains).

Types of Digital Certificates

CAs can issue various types of certificates for different use cases, which are:

• Code Signing certificates

  These certificates are used by developers and publishers to sign their software distributions. Users use them for authenticating and validating software downloads from the developer or vendor.

• Email Signing certificates

  These certificates let entities sign, authenticate, and encrypt email using the Secure/Multipurpose Internet Mail Extensions protocol for securing mail attachments.

• User/Client certificates or Signature Verification certificates help individuals handle various authentication needs.

• Object Signing certificates

  These certificates accommodate signing and authenticating any software object.

What are the PKI Pitfalls?

PKI implementation is important to securing an enterprise, but more importantly, whether a PKI is implemented correctly needs to be ensured. Despite PKI technology’s critical nature, tasks related to it are often not viewed as a priority and are assigned to non-experts. This results in PKI errors and misconfigurations, leading to unnecessary risks. The few major PKI pitfalls that arise within an enterprise are:

• Certificate Problems.
• Deployment Problems.
• Security Problems.
• Governance Problems.
• Visibility Problems.

Certificate Problems

The most common issue for setting up PKI systems at the beginning of implementation is using weak keys. Weak keys can become a point of exposure which may ultimately lead to an underlying problem for PKI implementation. Users or enterprises tend to keep longer certificate lifespans, as changing out certificates can be troublesome. But this also leads to expanding the attack surface through time. So, rotating certificates often leads to less risk of attack. Long certificate terms can also mean outdated cryptographic algorithms are present, which may lead to long-term problems even after having easy solutions. For example, RSA and ECC encryption techniques are effective now, but they will be rendered obsolete by advanced computing techniques like – quantum computing within the next several years. 

Deployment Problems

It is very risky to reuse certificates across devices when deploying certificates. This may look like a cheaper and less time-consuming process to users, but if one certificate needs to be better or is bad, all other certificates will also be good. Similarly, if even a single certificate gets breached, this potential risk may spread across multiple devices. So, keeping each device separate is better to minimize the risk across devices and certificates. 

Security Problems

Improper protection of private keys is one of the most common issues in setting up PKI systems. Whether the device is a laptop with a Trusted Platform Module (TPM) or an IoT device with a secure enclave, it is important to ensure that private keys remain secure. Failure to respond to vulnerabilities and to apply patches is another common issue. This should be considered a part of proper system maintenance, and an appropriate level of attention should be given.

Governance Problems

With rules and guidance, running teams effectively and efficiently is possible. The lack of policy consistency in organizations leads to further inconsistencies in PKI implementation, creating major risks for the same organizations. Rules and order need to be created to prevent any such issue, and these need to be followed and applied consistently. Another major issue is deciding when to use private or public roots, as the wrong choice may lead to greater security risks. 

Visibility Problems

The most common issues in visibility are rogue CAs and rogue certificates. Generally, rogue certificates are preferred to those trusted ones issued by a trusted CA but are either issued to the wrong party or compromised. Permitting rogue certificates or CAs to continue operating in the environment without bringing them under management can cause many more issues. This may also allow attackers to create illegitimate websites which are indistinguishable from the original or real ones.

Five Steps to Building a Scalable PKI 

Managing PKI is an important role and task for enterprise security teams, where errors, outdated tools and processes, and lack of visibility lead to expensive outrages and vulnerabilities. It is impossible to manage manually because of the rise in connected devices, so organizations must consider implementing various processes to secure their certificate infrastructure properly. There are five simplified actions for building a PKI, and those are the following:

• Identifying the non-negotiable network security risks.
• Pinpointing the network security risks PKI can mitigate.
• Developing the right mix of public and private PKI.
• Choosing whether to build or buy CA, i.e., internal CA or hosted CA.
• Discovering how to automate the delivery of certificates to devices.

Identifying the non-negotiable network security risks

There may not be only technical issues related to setting up a PKI but also other kinds of security risks that a user must mitigate. A few of the security risks are:

• To prevent unauthorized access to web services.
• Prevent unauthorized access to knowledge stored in databases.
• Preventing unauthorized access to users’ or organizations’ networks.
• Verifying the authenticity of messages transferred on the network of users or organizations.

Pinpointing the network security risks PKI can mitigate

PKI can benefit by increasing the network’s security level by binding an identity to a public key and allowing it to mitigate risks through encryption authentication and digital signatures. Encryption helps mitigate confidentiality risks, authentication certificates help mitigate risks to access controls, and digital certificates help to mitigate risks to integrity. So, PKI can be applied to various applications like:

• To secure various web pages.
• To encrypt files and secure them.
• To authenticate logins with the use of smart cards.
• Encrypting and authenticating email messages by using S/MIME.
• To authenticate connections to a specific VPN.
• To authenticate nodes that are to be connected to a wireless network.

Developing the right mix of public and private PKI

After identifying the network security risks and procedures to mitigate them, a user or an organization is ready to plan the architecture of the PKI system. The most mature setup is to build a hybrid architecture, including private and public PKI. This typically uses public PKI for securing public-facing websites and other services, while private PKI secures internal ones. With PKI, an identity is bent to the public key through the signing process. That signature is either performed by a Root or intermediate chaining up to the Root. Certificates which are issued by the trusted Roots are valid. If the Root that bound the identity to the general store is present in the trust store, it is okay to rely on the identity bound to the public key.

Choosing whether to build or buy CA, i.e., Internal CA or Hosted CA

After deciding where private certificates are needed for internal services, the next step is to determine whether CA needs to be built (internal PKI) or bought (hosted PKI). Both are good options, but the decision comes down to the resources and personnel to dedicate to this PKI setup. A hosted service helps create Root and secures it at the level commensurate with public trust. Still, an internal CA can give full access and control of the issuance process while needing to bear the costs of software, licensing, hardware, and training. But the biggest question is whether an internally managed PKI is worth the investment in money, time, and personnel, as managing an internal PKI system has both benefits and hidden costs.

Discovering how to automate the delivery of certificates to devices

For running PKI smoothly on a large scale, it is necessary to automate the certificate deployment process. Changing the industry standards and decreasing the certificate validity periods means automation won’t be an option shortly but rather a necessity. There will be hundreds or thousands of devices to manage. Only by leveraging automation can this be handled efficiently and help maintain security by reducing chances of human errors and certificate-caused outrages. The four most common methods of handling automation are:

• RESTful APIs

  The chosen CA must allow using RESTful API endpoints as a part of the programming to use enterprise device management software.

• Simple Certificate Enrolment Protocol (SCEP)

  This route does require a SCEP agent on the devices for working in conjunction with enterprise device management software. After that, the software sends the script to the device, telling it to get a cert.

• Enrolment over Secure Transport (EST)

  EST is the successor to SCEP. It is almost similar, except that it supports Elliptic Curve Cryptography (ECC), a type of cryptography that helps create faster, shorter, and more efficient cryptographic keys.

• Microsoft AD Auto-enrolment

  This is used for automating certificate delivery directly to the Microsoft Key Store for all Windows PCs and servers.

Conclusion

After successfully planning for building a PKI into the network, it is possible to make it happen for both public and private PKI. It is necessary to build a PKI, as the security situation nowadays is crucially high.