What is PKI?

What is a public-key infrastructure (PKI)?

PKI is an acronym for public key infrastructure, which is the technology behind digital certificates. A digital certificate fulfills a similar purpose to a driver’s license or a passport – it is a piece of identification that proves your identity and provides certain allowances. A digital certificate allows its owner to encrypt, sign, and authenticate. Accordingly, PKI is the technology that allows you to encrypt data, digitally sign documents, and authenticate yourself using certificates.

As the word “infrastructure” in public key infrastructure implies, PKI is the underlying framework for the technology as a whole; it is not a single, physical entity. PKI encapsulates various “pieces” that make up the technology, including the hardware, software, people, policies, and procedures needed to create, manage, store, distribute, and revoke digital certificates. An important piece of the PKI technology is the CA, which is the certification authority. The CA is the entity that issues digital certificates.

Video: Entrust PKI Overview

Entrust’s industry-leading PKI solution is trusted to keep people, systems, and things securely connected. Available in on-premises, managed, and as-a-service deployment models to support many use cases.

WATCH VIDEO

What are the components that make up an effective public key infrastructure?

There are a number of requirements that businesses have with respect to implementing effective public key infrastructures. First and foremost, if users cannot take advantage of encryption and digital signatures in applications, a PKI is not valuable. Consequently, the most important constraint on a PKI is transparency. The term transparency means that users do not have to understand how the PKI manages keys and certificates to take advantage of encryption and digital signature services. An effective PKI is transparent. In addition to user transparency, a business must implement the following items in a PKI to provide the required key and certificate management services:

• Public key certificates
• A certificate repository
• Certificate revocation
• Key backup and recovery
• Support for non-repudiation of digital signatures
• Automatic update of key pairs and certificates
• Management of key histories
• Support for cross-certification
• Client-side software interacting with all of the above in a secure, consistent, and trustworthy manner

Note: The term “client-side” refers to application clients and application servers. PKI requirements are the same for both application clients and servers, and both are “clients” of the infrastructure services.

All of these requirements must also be met to have an automatic, transparent, usable PKI.

What are the roles of certificates and certification authorities?

For public key cryptography to be valuable, users must be assured that the other parties with whom they communicate are “safe” – that is, their identities and keys are valid and trustworthy. To provide this assurance, all users of a PKI must have a registered identity.

These identities are stored in a standard X.509 digital public key certificate format. Certification authorities (CAs) represent the people, processes, and tools to create digital certificates that securely bind the names of users to their public keys. In creating certificates, CAs act as agents of trust in a PKI. As long as users trust a CA and its business policies for issuing and managing certificates, they can trust certificates issued by the CA. This is known as third-party trust.

CAs create certificates for users by digitally signing a set of data that includes the following information (and additional items):

1. The user’s name in the format of a distinguished name (DN). The DN specifies the user’s name and any additional attributes required to uniquely identify the user (for example, the DN could contain the user’s employee number).
2. A public key of the user. The public key is required so that others can encrypt for the user or verify the user’s digital signature.
3. The validity period (or lifetime) of the certificate (a start date and an end date).
4. The specific operations for which the public key is to be used (whether for encrypting data, verifying digital signatures, or both).

The CA’s signature on a certificate means any tampering with the contents of the certificate will be easily detected. The CA’s signature on a certificate is like a tamper-detection seal on a bottle of pills – any tampering with the contents of a certificate is easily detected. As long as the CA’s signature on a certificate can be verified, the certificate has integrity. Since the integrity of a certificate can be determined by verifying the CA’s signature, certificates are inherently secure and can be distributed in a completely public manner (for example, through publicly accessible directory systems).

Users retrieving a public key from a certificate can be assured that the public key is valid. That is, users can trust that the certificate and its associated public key belong to the entity specified by the distinguished name. Users also trust that the public key is still within its defined validity period. In addition, users are assured that the public key may be used safely in the manner for which it was certified by the CA.

Why is PKI important?

PKI is a critical part of the IT strategic backbone. PKI is important because the certificate-based technology helps organizations establish trusted signature, encryption, and identity between people, systems, and things.

With evolving business models becoming more dependent on electronic transactions and digital documents, and with more Internet-aware devices connected to corporate networks, the role of a public key infrastructure is no longer limited to isolated systems such as secure email, smart cards for physical access or encrypted web traffic. PKIs today are expected to support larger numbers of applications, users and devices across complex ecosystems. And with stricter government and industry data security regulations, mainstream operating systems and business applications are becoming more reliant than ever on an organizational PKI to guarantee trust.

What is certification authority or root private key theft?

The theft of certification authority (CA) or root private keys enables an attacker to take over an organization’s public key infrastructure (PKI) and issue bogus certificates, as was done in the Stuxnet attack. Any such compromise may force revocation and reissuance of some or all of the previously issued certificates. A root compromise, such as a stolen root private key, destroys the trust of your PKI and can easily drive you to reestablish a new root and subsidiary issuing CA infrastructure. This can be very expensive in addition to damaging to an enterprise’s corporate identity.

The integrity of an organization’s private keys, throughout the infrastructure from root to issuing CAs, provides the core trust foundation of its PKI and, as such, must be safeguarded. The recognized best practice for securing these critical keys is to use a FIPS 140-2 Level 3 certified hardware security module (HSM), a tamper-resistant device that meets the highest security and assurance standards.

What’s the difference between PKI and SSL?

PKI and SSL, while different, are both certificate-based solutions that establish “trust” with certificates issued by a certificate authority (CA) – whether it’s public trust (SSL) or private trust (PKI).

PKI is an entire framework that consists of hardware, software, policies, and more. A PKI also includes a CA, which is what issues the digital certificates to establish trust. Typically that CA is governed internally according to policies and procedures that align with the security and assurance levels required of the organization.

SSL is one of the top use cases of PKI. It also involves a CA that issues certificates, but it must be recognized by browsers as a publicly trusted CA. And while there are many use cases for PKI , the purpose of SSL is to secure sensitive data transferred via online communications, like online banking or ecommerce transactions.

• More on PKI
• More on SSL

What are common use cases for PKI?

The primary use cases for PKI can be determined by looking at the applications that most commonly use digital certificates, such as:

Traditional use cases
These business-critical applications make it clear that PKI is a strategic part of the core IT backbone.

• SSL certificates for public-facing websites and services
• Private networks and virtual private networks (VPNs)
• Public cloud-based applications and services
• Private cloud-based applications
• Email security
• Enterprise user authentication
• Device authentication
• Private cloud-based authentication
• Document/message signing
• Code signing

(See details in chart below.)

New and emerging use cases
There has also been a resurgence of PKI from DevOps-related use cases that are driving increased adoption, such as:

• Cloud-based services
• Consumer mobile
• Internet of things (IoT)
• Consumer-oriented mobile applications
• Bring-your-own-device (BYOD) policies and internal mobile device management
• e-commerce

(See details in chart below.)

And some experts are predicting future use cases as technology and artificial intelligence gets even more advanced.

What’s the difference between private keys and public keys?

The difference between private and public keys is one is used to encrypt, while the other is used to decrypt.

A public key is used to encrypt information, essentially making it unreadable to anyone who is not the intended recipient. Then that recipient holds a private key with which they are then able to decrypt the information.

Also, a public key is publicly available to a set of users who would need to confidentially send information confidentially. For example, someone’s public key would be available to their colleagues within an organization via a shared directory. Conversely a private key is accessible only by the person receiving the information, and therefore would be the only person able to successfully decrypt what was encrypted.

Together, public and private keys ensure information, data, and communications are encrypted before it is then safely transmitted and decrypted by the appropriate party.

What is key backup and recovery?

A business must be able to retrieve encrypted data when users lose their decryption keys. This means that the enterprise to which the user belongs requires a system for backing up and recovering the decryption keys.

There are two reasons why key backup and recovery are so important to businesses:

1. Users forget passwords. It’s potentially catastrophic for a business to lose data when users forget the passwords required to access their decryption keys. Valuable information would be lost forever if there was no ability to securely recover those keys. Furthermore, unless users know they can always recover their encrypted data (even if they forget their passwords), some users will not encrypt their most valuable and sensitive information for fear of losing it ¬– even though that information needs to be protected the most.
2. Users may lose, break, or corrupt the devices in which their decryption keys are stored. For instance, if a user’s decryption keys are stored on a magnetic card, the magnetic field on the card can become corrupted. Again, permanent loss of those decryption keys can be disastrous. Users are prevented from recovering encrypted data unless their decryption keys are backed up.

The difference between key backup and key escrow Commercial requirements for key backup and recovery can be completely separated from law enforcement requirements for key escrow – a topic widely discussed in the media.

• Key escrow means that a third party (such as a federal agent) can obtain the decryption keys required to access encrypted information. The purpose of key escrow is to help with law enforcement, and is heavily-debated because of the fine line between public interest (such as national security) and individual freedom and privacy.
• Key backup and recovery requirements focus on fundamental commercial needs that exist, regardless of law enforcement requirements.

Which keys require backup? The only keys requiring backup are users’ decryption keys. As long as a trusted agent (for example, the CA) securely backs up users’ decryption keys, security is not compromised and the user’s data can always be recovered. However, signing keys have different requirements from decryption keys. In fact, as the next section describes, backing up signing keys destroys a basic requirement of a PKI.

What is non-repudiation and how does PKI support it?

Repudiation occurs when an individual denies involvement in a transaction. For example, when someone claims a credit card is stolen, he or she is repudiating liability for transactions that occur with that card any time after reporting the theft.

Non-repudiation means that an individual cannot successfully deny involvement in a transaction. In the paper world, an individual’s signature legally binds them to their transactions (credit card charges, business contracts, etc.). The signature prevents repudiation of those transactions.

In the electronic world, the replacement for the pen-based signature is a digital signature. All types of e-commerce require digital signatures because e-commerce makes traditional pen-based signatures obsolete.

The signing private key
The most basic requirement for non-repudiation is that the key used to create digital signatures – the signing key – be generated and securely stored in a manner under the sole control of the user at all times. It is not acceptable to back up the signing key. Unlike encryption key pairs, there is no technical or business requirement to back up or restore previous signing key pairs when users forget their passwords or lose, break, or corrupt their signing keys. In such cases, it’s acceptable for users to generate new signing key pairs and continue using them from that time forward.

The need for two key pairs
It’s difficult to simultaneously support key backup and recovery and non-repudiation. To support key backup and recovery, the decryption keys must be backed up securely. But to support non-repudiation, the keys used for digital signature cannot be backed up and must be under the sole control of the user at all times.

To meet these requirements, a PKI must support two key pairs for each user. At any point in time, a user must have one current key pair for encryption and decryption, and a second key pair for digital signature and signature verification. Over time, users will have numerous key pairs that must be managed appropriately.

What are key update and management of key histories?

Cryptographic key pairs should not be used forever – they must be updated over time. As a result, every organization needs to consider two important issues:

1. Updating users’ key pairs
   The process of updating keys pairs should be transparent to users. This transparency means users don’t have to understand what key update needs to take place and they will never experience a “denial of service” because their keys are no longer valid. To ensure transparency and prevent denial of service, users’ key pairs must be automatically updated before they expire.
2. Maintaining, where appropriate, the history of previous key pairs
   When encryption key pairs are updated, the history of previous decryption keys must be maintained. This “key history” allows users to access any of their prior decryption keys to decrypt data. (When data is encrypted with a user’s encryption key, only the corresponding decryption key – the paired key – can be used for decrypting). To ensure transparency, the client-side software must automatically manage users’ histories of decryption keys.

The key history must also be securely managed by the key backup and recovery system. This allows encrypted data to be recovered securely, regardless of what encryption public key was used to originally encrypt the data (and, by extension, regardless of when the data was encrypted).

When a signing key pair is updated, the previous signing key must be securely destroyed. This prevents any other person from gaining access to the signing key, and is acceptable because there’s no need to retain previous signing keys.

What are certificate repositories and certificate distribution?

As mentioned earlier, the CA acts as a trusted third party, issuing certificates to users. Businesses also must distribute those certificates so they can be used by applications. Certificate repositories store certificates so applications can retrieve them on behalf of users.

The term “repository” refers to a network service that allows for distribution of certificates. Over the past few years, the consensus in the IT industry is that the best technology for certificate repositories is provided by directory systems that are LDAP (Lightweight Directory Access Protocol)-compliant. LDAP defines the standard protocol to access directory systems.

Several factors drive this consensus position:

• Storing certificates in directories and having applications retrieve certificates on behalf of users provides the transparency required for use in most businesses
• Many directory technologies supporting LDAP can be scaled to:
  • support a very large number of entries
  • respond efficiently to search requests due to their information storage and retrieval methods
  • be distributed throughout the network to meet the requirements of even the most highly distributed organizations

In addition, the directories that support certificate distribution can store other organizational information. As discussed in the next section, the PKI can also use the directory to distribute certificate revocation information.

What is certificate revocation?

In addition to verifying the CA’s signature on a certificate (as discussed earlier in What are the roles of certificates and certification authorities?), the application software must also be sure that the certificate is still trustworthy at the time of use. Certificates that are no longer trustworthy must be revoked by the CA. There are numerous reasons why a certificate may need to be revoked prior to the end of its validity period. For instance, the private key (either the signing key or the decryption key) corresponding to the public key in the certificate may be compromised. Alternatively, an organization’s security policy may dictate that the certificates of employees leaving the organization must be revoked.

In these situations, users in the system must be informed that continued use of the certificate is no longer considered secure. The revocation status of a certificate must be checked prior to each use. As a result, a PKI must incorporate a scalable certificate revocation system. The CA must be able to securely publish information regarding the status of each certificate in the system. Application software, on behalf of users, must then verify the revocation information prior to each use of a certificate.

The combination of publishing and consistently using certificate revocation information constitutes a complete revocation system. The most popular means for distributing certificate revocation information is for the CA to create secure certificate revocation lists (CRLs) and publish these CRLs to a directory system. CRLs specify the unique serial numbers of all revoked certificates.

Prior to using a certificate, the client-side application must check the appropriate CRL to determine if the certificate is still trustworthy. Client-side applications must check for revoked certificates consistently and transparently on behalf of users.

What is cross-certification?

Cross-certification extends third-party trust relationships between Certification Authority domains. For example, two trading partners, each with their own CA, may want to validate certificates issued by the other partner’s CA. Alternatively, a large, distributed organization may require multiple CAs in various geographic regions. Cross-certification allows different CA domains to establish and maintain trustworthy electronic relationships.

The term cross-certification refers to two operations:

1. Establishing a trust relationship between two CAs (executed infrequently). In the case of bilateral cross-certification, two CAs securely exchange their verification keys. These are the keys used to verify the CAs’ signatures on certificates. To complete the operation, each CA signs the other CA’s verification key in a certificate referred to as a “cross-certificate.”
2. Verifying the trustworthiness of a user certificate signed by a cross-certified CA (executed frequently). This is. The operation, done by the client-side software, is often referred to as “walking a chain of trust.” The “chain” refers to a list of cross-certificate validations that are “walked” (or traced) from the CA key of the verifying user to the CA key required to validate the other user’s certificate. When walking a chain of cross-certificates, each cross-certificate must be checked to ensure that it is still trusted. User certificates must be able to be revoked; so must cross-certificates. This requirement is frequently overlooked in discussions regarding cross-certification.

What is client-side software?

When discussing requirements for PKIs, businesses often neglect the requirement for client-side software. (For instance, many people only focus on the CA component when discussing PKIs). Ultimately, however, the value of a PKI is tied to the ability of users to use encryption and digital signatures. For this reason, the PKI must include client-side software that operates consistently and transparently across applications on the desktop (email, web browsing, e-forms, file/folder encryption, etc.).

A consistent, easy-to-use PKI implementation within client-side software lowers PKI operating costs. In addition, client-side software must be technologically enabled to support all of the elements of a PKI. The following list summarizes the requirements client-side software must meet to ensure that users in a business receive a usable, transparent (and thus, acceptable) PKI.

• Public key certificates To provide third-party trust, all PKI-enabled applications must use certificates in a consistent, trustworthy manner. The client-side software must validate the CA’s signature on certificates and ensure that the certificates are within their validity periods.
• Key backup and recovery To ensure users are protected against loss of data, the PKI must support a system for backup and recovery of decryption keys. With respect to administrative costs, it is unacceptable for each application to provide its own key backup and recovery. Instead, all PKI-enabled client applications should interact with a single key backup and recovery system. The interactions between the client-side software and the key backup and recovery system must be secure, and the interaction method must be consistent across all PKI-enabled applications.
• Support for non-repudiation To provide basic support for non-repudiation, the client-side software must generate the key pairs used for digital signature. In addition, the client-side software must ensure that the signing keys are never backed up and remain under the users’ control at all times. This type of support must be consistent across all PKI-enabled applications.
• Automatic update of key pairs To enable transparency, client-side applications must automatically initiate updating of users’ key pairs. This must be done in accordance with the security policies of the organization. It is unacceptable for users to have to know that their key pairs require updating. To meet this requirement across all PKI-enabled applications, the client-side software must update key pairs transparently and consistently.
• Management of key histories To enable users to easily access all data encrypted for them (regardless of when it was encrypted), PKI-enabled applications must have access to users’ key histories. And the client-side software must be able to securely recover users’ key histories.
• Scalable certificate repository To minimize the costs of distributing certificates, all PKI-enabled applications must use a common, scalable certificate repository.

What are common PKI management mistakes/challenges?

Supporting new applications
It is often difficult for applications to use PKI. According to Ponemon Institute's 2019 PKI and IoT Trends Report, the two most significant challenges organizations will continue to face, with respect to enabling applications to use PKI, is the inability of an existing PKI to support new applications and the inability to change legacy applications.

(See details in chart below.)

Lack of clear ownership
The same survey also found that the main PKI deployment challenge continues to be the lack of clear ownership of the PKI function. But in today’s PKI environment, there’s a need for proper management, especially when you consider:

• Infrastructure is distributed, with many certificates are issued to many people, places, and things
• We need to secure more “things” now than ever, and deal with shorter life certificates
• Certificates secure critical business applications, and outages can be costly and hard to diagnose

For proper visibility into the certificates in your infrastructure, it helps to not only centralize PKI management within a specific department, but also with a software tool that provides a single pane of glass for certificate monitoring and reporting.

What security certifications and standards are important for PKI?

There are several different standards and regulations, especially at a regional and/or government level, but the top two more important security certifications when deploying PKI are:

• Common Criteria EAL Level 4+
• FIPS 140-2 Level 3

Summary

A comprehensive PKI solution must implement the following items:

• Public key certificates
• Certificate repository
• Certificate revocation
• Key backup and recovery
• Support for non-repudiation of digital signatures
• Automatic update of key pairs and certificates
• Management of key histories
• Support for cross-certification
• Client-side software interacting with all of the above in a secure, consistent, and trustworthy manner

Only a comprehensive PKI can achieve the goal of establishing and maintaining a trustworthy networking environment, while at the same time providing an automatic and transparent system that is usable.

Reduced costs, streamlined business processes, and improved customer service provide tangible returns on an investment in PKI. Organizations have already realized cost savings of $1-$5.4 million per year. A focus on particular business applications will enable your PKI to provide the returns you seek. Your existing network can be leveraged to provide secure email, desktop security, web-based security, e-commerce, access control, or virtual private networks.