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:
View some of our other popular topics:
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.
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.
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:
____________________
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 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:
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.
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:
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.
____________________
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:
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.