One of the biggest challenges when using asymmetric encryption algorithms and digital certificates is providing secure distribution of public keys between the parties. In other words, how does the receiver know they have received a public key of the real system instead of the public key of an attacker pretending to be the real system?
The solution to this challenge comes from a framework consisting of processes, technologies, and policies that allow you to encrypt and sign data. This service framework is called Public Key Infrastructure (PKI). It supports scalable solutions that require the management of system and user identities. Moreover, it plays a vital role in HTTPS communications and VPN technologies.
In this article, we provide the following:
- an overview of the PKI,
- the terminology and components involved,
- the benefits it offers to modern security requirements, and
- review graphical examples to understand how the whole concept works.
View some of our other popular topics:
- The Best Wireless LAN Option: Aruba Wireless vs. Cisco Meraki Wireless
- Must-Have Port Security: Simple but Efficient Layer 2 Protection
- Telnet Versus SSH: How SSH Works and Why It's Better
PKI Overview and Its Components
The main idea behind using PKI is the third-party that guarantees that the identification presented by the remote peer can be trusted. Once that trust is established, any two entities can validate their identities and securely exchange data.
The PKI consists of two key terms: Certificate Authority (CA) and a certificate. The CA is the trusted third party responsible for signing the public keys of the entities in the form of an identity certificate. The certificate is a document that uniquely identifies an entity by binding together the personal information of the entity and its public key.
The goal is for entities to enroll with a PKI and download identity certificates that a CA of your choice signs. An identity certificate contains the entity's public key, and its legitimacy is proven by the CA's digital signature included on the certificate.
Once validated as legitimate, the certificate is accepted, and the public key is used by the peer later on in the process of establishing a session (symmetric encryption) key needed for protecting the data to be exchanged between the two entities.
Trusted Third-Party Example
Here's an analogy to understand the PKI third-party process better:
Let's say you apply for an ID card, which is the identity certificate in terms of PKI. You submit the requested information, and once the application is approved, the ID card is issued by the government agency, which represents the CA in terms of PKI.
Later on, when you withdraw money from the bank, you must show your ID card so they know who you are. Because the bank trusts the issuer of the ID card (the CA in our case), they allow the request to be processed.
Authenticating the CA
For an entity to verify a signature in an identity certificate presented by the peer entity, the user or entity must have the public key of the CA that issued that certificate in the first place.
This is done by requesting the CA's identity certificate, also known as the root certificate. This CA root certificate is self-signed and must be accepted by anyone that needs to verify the signatures in the identity certificates issued by that CA. The root certificates are free for download and, by default, pre-installed in mainstream web browsers.
As shown in the image above, the process can be broken down into two steps:
- Step 1: User A requests the root certificate of the CA.
- Step 2: Once downloaded, User A has the public key of the CA and can validate any identity certificate issued by that CA. Many vendors offer CA services, such as GoDaddy, VeriSign, Thawte, Comodo, and Verisign.
____________________
Still unsure of how all of this works? PivIT's EXTEND offering can step in to augment your team and remote in to configure your gear with expert-level engineers (SmartHands | EXTEND). If you need someone on-site, we have field services ready at a moment's notice.
____________________
PKI Enrollment: Issuing an Identity Certificate
PKI enrollment is the process where the entity gets an identity certificate from a CA.
As shown in the image above, the process can be broken down into five steps:
- Step 1: User A generates private and public keys.
- Step 2: The public key and other personal information are submitted to the CA of choice.
- Step 3: Once the CA verifies the enrolling user's identity and public key, the CA uses its private key to digitally sign (encrypt) the hashed version of the request.
- Step 4: After that, the signature is appended to the identity certificate (also called signing).
- Step 5: The identity certificate is sent to User A. From then on, User A can identify themselves to others by presenting this certificate until it expires or is revoked.
Keep in mind that certificates are not secret or encrypted because that is not needed in the PKI concept. The only protection involved is the digital signature, which proves authenticity and integrity.
Validating an Identity Certificate
Once the entities get their identity certificates and the CA's public key (root certificate), they can establish point-to-point relationships independently of the CA.
As shown in the image above, the process can be broken down into two steps:
- Step 1: Users A and B exchange their identity certificates.
- Step 2: The signatures are verified by using the public key from the root certificate of the CA. After being validated, the public keys from the identity certificates are considered trusted and can be used for other services required by both users.
X.509 Standard
X.509 is a well-known ITU-T standard that defines basic PKI data formats, such as the identity certificate format and the certificate validation algorithms. Currently, digital identity certificates use the X.509 version 3, which consists of numerous fields representing data such as the certificate serial number, expiration date, and signature. It also includes the issuer and subject public key.
Certificates play a considerable role in many different services used daily by enterprises, such as TLS connections, email protection, IPsec VPNs, etc. The image above is an example of what one identity certificate (in our case, it is from Google) looks like, what information might be included, and how it is structured.
____________________
OneCall's Sparing Integrity Program provides transparency by giving you the serial number, part ID, and location of your spare so you know it will be ready to deploy when needed.
____________________
Certificate Revocation Solutions
Like with any other technology, the PKI also has some setbacks. The biggest potential problem with PKI is the possibility for a key (private or public) to become compromised. In such a case, all CA clients must be alerted not to trust those keys (certificates) anymore. This process is called certificate revocation.
Two certificate revocation solutions can be applied:
- Cyclic Revocation List (CRL): A list containing all certificates no longer valid. It is stored on an HTTP server and is updated at regular intervals. It is the responsibility of the users to check the received identity certificate against the CRL. This is a manual method and often delays the newest information.
- Online Certificate Status Protocol (OCSP): A protocol for real-time verification of identity certificates against a database of revoked certificates. This approach eliminates the weakness of the CRL but heavily depends on highly available OSCP server infrastructure. OSCP is the recommended option.
Protect Your Legacy Hardware
Now that you are familiar with the PKI concept, you can quickly start implementing the PKI framework in your network and take advantage of its benefits. This will make things internally flawless and provide additional flexibility and broader support for other services.
Do you have legacy hardware that is coming up on its end-of-sale date? Roll those right onto PivIT's OneCall maintenance strategy, where you get dedicated spares so you can protect your critical infrastructure.
