What Is Pki and How Does It Work

What is PKI?

Today, organizations rely on PKI to manage security through encry ption . Specifically, the most common form of encryption used today involves a public key, which anyone can use to encrypt a message, and a private key (also known as a secret key), which only one person should be able to use to decrypt those messages. These keys can be used by people,  devices, and applications.

PKI security first emerged in the 1990s to help govern encryption keys through the issuance and management of digital certificates. These PKI certificates verify the owner of a private key and the authenticity of that relationship going forw ard to help maintain security. The certificates are akin to a driver's license or passport for the digital world.

Common examples of PKI security today are SSL certificates on websites so that site visitors know they're sending information to the intended recipie nt, digital signatures, and authentication for Internet of Things devices.

Is your PKI too complex? Try Cloud PKI as-a-Service.

How Does PKI Work?

So how does PKI work?

To understand how PKI works , it's important to go back t o the basics that govern encryption in the first place. With that in mind, let's dive into cryptographic algorithms and digital certificates.

Building Blocks of Public Key Cryptography

Cryptographic algorithms are defined, highly complex mathematical  formulas used to encrypt and decrypt messages. They are also the building blocks of PKI authentication. These algorithms range in complexity and the earliest ones  pre-date modern technology.

Symmetric Encryption

Symmetric encryption is a simple cryptographic algorithm by today's standards, however, it was once considered state of the art. In fact, the German army used it to send private communications during World War II. The movie The Imitation Game actually does  quite a good job of explaining how symmetric encryption w orks and the role it played during the war.

With symmetric encryption, a message that gets typed in plain text goes through mathematical permutations to become encrypted. The encrypted message is difficult to break because the same plain text letter does  not always come out the same in the encrypted message. For example, the message "HHH" would not encrypt to three of the same characters.

To both encrypt and decrypt the message, you need the same key, hence the name symmetric encryption. While decrypting  messages is exceedingly difficult without the key, the fact that the same key must be used to encrypt and decrypt the message carries significant risk. That's because if the distribution channel used to share the key gets compromised, the whole system for  secure messages is broken.

Asymmetric Encryption

Asymmetric encryption, or asymmetrical cryptography, solves the exchange problem that plagued symmetric encryption. It does so by creating two different cryptographic keys (hence the name asymmetric encryption) — a private key and a public key.

With asymmetric encryption, a message still goes throu gh mathematical permutations to become encrypted but  requires a private key (which should be known only to the recipient) to decrypt and a public key (which can be shared with anyone) to encrypt a message.

Here's how this works in action:

• Alice wants to  send a private message to Bob, so she uses Bob's public key to generate encrypted ciphertext that only Bob's private key can decrypt.
• Because only Bob's private key can decrypt the message, Alice can send it knowing that no one else can read it — not eve n an eavesdropper — so long as Bob is careful that no one else has his private key.
  

Asymmetric encryption also makes it possible to take other actions that are harder to do with symmetric encryption, like digital signatures, which work as follows:

• Bob c an send a message to Alice and encrypt a signature at the end using his private key.
• When Alice receives the message, she can use Bob's public key to verify two things:
  • Bob, or someone with Bob's private key, sent the message
  • The message was not modified i n transit, because if it does get modified the verification will fail
    

In both of these  examples, Alice has not generated her own key. Just with a public key exchange, Alice can send encrypted messages to Bob and verify documents that Bob has signed. Impor tantly, these actions are only one-way. To reverse the actions so Bob can send private messages to Alice and verify her signature, Alice would have to generate her own private key and share the corresponding public key.

Today, there are three popular m athematical properties used to generate private and public keys: RSA, ECC, and Diffie-Hellman. Each uses different algorithms to generate encryption keys  but they all rely on the same basic principles as far as the relationship between the public key and pr ivate key.

Let's look at the RSA 2048 bit  algorithm as an example. This algorithm randomly generates two prime numbers that are each 1024 bits long and then multiplies them together. The answer to that equation is the public key, while the two prime numb ers that created the answer are the private key.

This approach works because it's extremely difficult to reverse the computation when it involves two prime numbers of that size, making it relatively easy to compute the public key from the private key but n early impossible to compute the private key from the public key.

How Symmetric and Asymmetric Encryption Get Used Today

Both symmetric and asymmetric encryption get used often today. Asymmetric encryption is much slower than symmetric encryption, so the two are often used in tandem. For example, someone may encrypt a message using symmetric encryption and then send the key to decrypt the message using asymmetric encryption (which speeds up the decryption process since the key is much smaller than the entire message).

Today, asymmetric encryption powers things like:

• SSH algorithms
• SSL/TLS

• S/MIME encrypted email
• Code signing
• Bitcoin/Blockchain
• Signal private messenger
• Digital signatures
  

Most notably, asymmetric encryption powers PKI.

The Emergence of PKI to Govern Encryption Keys

Both symmetric and asymmetric encryption have one major chall enge: How do you know that the public key you received actually belongs  to the person you think it does?

Even with asymmetric encryption, the risk of the "man in the middle" exists. For example, what if someone intercepted Bob's public key, made his own private key, and then generated a new public key for Alice? In this case, Alice would encrypt messages for Bob, the man in the middle could decrypt them, change them and then re-encrypt them and neither Alice nor Bob would be any wiser.

PKI resolves this c hallenge by issuing and governing digital certificates that confirm the identity of people, devices or applications that own private keys and the corresponding public keys. In short, PKI assigns identities to keys so that recipients can accurately verify t he owners. This verification gives users confidence that if they send an encrypted message to that person (or device), the intended recipient is the one who will actually read  it and not anyone else who may be sitting as a "man in the middle."

The Role of Digital Certificates in PKI

PKI governs encryption keys by issuing and managing digital certificates. Digital certificates are also called X.509 certificates and PKI certificates.

However, you refer to them, a  digital certificate has these qualities:

• Is an electronic equivalent of a driver's license or passport
• Contains information about an individual or entity
• Is issued from a trusted third party
• Is tamper-resistant
• Contains information that can prove its authenticity
• Can be traced back to the issuer
• Has an expiration date
• Is presented to someone (or something) for validation
  

The easiest way to understand how PKI governs digital certificates to verify identities is to think of it as a digital DMV. Much like the DMV, PKI introduces a trusted third party to make decisions about assigning identities to a digital certificate. And much like driver's licenses, digital certificates are difficult to spoof, include information that identifies the owner and has an expiration date.

Finally, it's up to the person verifying the digital certificate to determine what that verification process  should be and how carefully the certificate should be vetted based on the use case.

Introducing Certification Authorities

Certification Authorities (CAs) are responsible for creating digital certificates and own the policies, practices, and procedures for vetting recipients and issuing the certificates.

Specifically, the owners and operators of a CA determine:

• Vetting methods for certificate recipients
• Types of certificates issued
• Parameters contained within the certificate
• Security and operations procedu res

Once CAs make these determinations, they must formally document their policies. From there, it's up to the consumers of certificates to decide how much trust they want to place in certificates from any given CA.

How the Certificate Creation Process Works

The certificate creation process relies heavily on asymmetric encryption and works as follows:

• A private key is created  and the corresponding public key gets computed
• The CA requests any identifying attributes of the private key owner and vets that  information
• The public key and identifying attributes get encoded into a Certificate Signing Request (CSR)
• The CSR is signed by the key owner to prove possession of that private key
• The issuing CA validates the request and signs the certificate with the C A's own private key

Anyone can use the public portion of a certificate to verify that it was actually issued  by the CA by confirming who owns the private key used to sign the certificate. And, assuming they deem that CA trustworthy, they can verify that anything they send to the certificate holder will actually go  to the intended recipient and that anything signed using that certificate holder's private key was indeed signed by that person/device.

One important part of this process to note is that the CA itself has its own pr ivate key and corresponding public key, which creates the need for CA hierarchies.

How CA Hierarchies and Root CAs Create Layers of Trust

Since each CA has a certificate of its own, layers of trust get created through CA hierarchies — in which CAs issue c ertificates for other CAs. However, this process is not circular, as there is ultimately a root certificate. Normally, certificates have an issuer and a subject as two separate parties, but these are the same parties for root CAs, meaning that root certifi cates are self-signed. As a result, people must inherently trust the root certificate authority to trust any certificates that trace back to it.

Root CA Security is of Utmost Importance

All of this makes the security of private keys extra important for CAs. A private key falling into the wrong hands is bad in any case, but it's particularly devastating  for CAs, because then someone can issue certificates fraudulently.

Security controls and th e impact of loss become even more severe as you move up the chain in a CA hierarchy because there is no way to revoke a root certificate. Should a root CA become compromised, the organization needs to make that security breach public. As a result, root CAs  have the most stringent security measures.

To meet the highest security standards, root CAs should almost never be online. As a best practice, root CAs should store their private keys in NSA-grade safes within state of the art  data centers with 24/7 secu rity via cameras and physical guards. All of  these measures might seem extreme, but they're necessary to protect the authenticity of a root certificate.

Although a root CA should be offline 99.9% of the time, there are certain instances where it does need  to come online. Specifically, root CAs need to come online for the creation of public keys, private keys and new certificates as well as to ensure that its own key material is still legitimate and hasn't been damaged or compromised in any way. Ideally, ro ot CAs should run these tests about 2-4 times a year.

Finally, it's important to note that root certificates do expire. Root certificates typically last for 15-20 years (compared to approximately seven years for certificates from subordinate CAs). Introdu cing and building trust in a new root isn't easy, but it's important that these certificates do expire because the longer they run, the more vulnerable they become to security risks.

Determining the Optimal Level of Tiers in Your PKI's CA Hierarchy

A CA h ierarchy typically involves two tiers, following the chain of Root Certificate Authority → Subordinate Certificate Authorities → End-Entity Certificates.

A two-tier  hierarchy is absolutely necessary at a minimum because a root CA should be offline 99.9 % of the time, which is a difficult standard for subordinate CAs that regularly issue certificates to meet since they need to be online to issue new certificates.

While subordinate CAs do the best  they can to protect their certificates, they carry a much h igher security risk than root CAs. Unlike root CAs though, subordinate CAs do have the ability to revoke certificates, so any security breach that does happen is easier to recover from than it is for root CAs (which can't revoke certificates).

That said, a two-tier  hierarchy is also usually sufficient for security. That's because the more tiers that exist within a CA hierarchy, the more difficult usability and scalability of the PKI becomes because more tiers add complexity to the policies and procedures g overning the PKI.

Managing Revocation Through Certificate Revocation Lists

If a subordinate CA gets compromised in any way or wants to revoke a certificate for any reason, it must publish a revocation list of any issued certificates that should not be trus ted. This list is known as a Certificate Revocation List (CRL) and is critical to PKI design.

While CAs must issue CRLs, it's up to the discretion of certificate consumers if they check these lists and how they respond if a certificate has been revoked. Once again, this is a prime example of how digital certificates are similar to  driver's licenses  since the vetting process typically depends on the need for the certificate (think about the difference between using a recently expired license to buy alcohol vs. to pass a TSA checkpoint).

In many cases, certificate consumers choose not to check CRLs because doing so slows down the authentication process. Certificate consumers can also choose how far back to go within the CA hierarchy as part of the check, keeping in mind that the further back they go, the longer the process takes.

Although checking C RLs — and going all the way to the root CA to do so — slows down the authentication process, doing so is becoming more standard as more things go online and rely on digital certificates for security. Consider the case of web browsers. Many web browsers p reviously didn't check certificates because it slowed down the browsing experience, but now these checks are commonplace as internet security becomes more important.

Critically, the CRLs themselves have an expiration date, and if a CRL expires, every cert ificate issued by the CA becomes invalid. While CAs primarily focus on making sure certificates don't expire — which is important — it's also important they make sure CRLs don't expire because if that happens it can take down the entire PKI. When root C As do go online, they also check to make sure that CRLs from subordinate CAs have not expired for this reason.

Trusted Root Certificates

Today, every device and system that goes online  ( e.g. phones, laptops, servers, operating systems) needs to interact w ith certificates. This widespread interaction with certificates has led to the concept of a trusted root certificate within devices and operating systems.

For example, all Microsoft computers have a trusted root store. Any certificate that can be traced b ack to that trusted root store will be automatically trusted by the computer. Each device and operating system comes  with a pre-set trusted root store, but machine owners can set rules to trust additional certificates or to not trust certificates that were  pre-set as trusted.

Why is PKI so Important in Today's Digital Age?

PKI is so important in today's digital age because there are now millions of applications and connected devices that require certification. Properly authenticating and maintaining cert ificates for these technologies is essential to keeping our highly connected world secure.

To fully illustrate the importance of PKI in today's digital age, let's track its evolution since it first came about in the mid-1990s.

The First Wave: Beginnings of PKI (1995-2002)

The first wave of PKI included only a small number of certificates, which had a high value and were used only in very specific cases.

The biggest use case for PKI during this time was to issue certificates to eCommerce websites, which c ould then display the lock icon in the browser to give consumers the confidence they were visiting the right website and that there was a secure connection when sharing credit card information to make a purchase.

Some large organizations rolled out PKI, but these projects typically spanned two years and millions of dollars only to result in a handful of certificates actually being  issued, leaving a lot of unfulfilled potential.

During this time, nearly all certificates got purchased from public vendors and could cost thousands of dollars. This created a revenue stream for these vendors that guaranteed they would monitor certificate expirations and alert recipients accordingly. As a result, managing PKI was relatively easy for organizations that did get anyth ing off the ground.

The Second Wave: Enterprise PKI Emerges (2003-2010)

The second wave of PKI saw enterprise use cases explode  and led to a set of new challenges as a result.

The early 2000s saw the rise of the mobile workforce, when almost all employees received laptops and the ability to work remotely became commonplace. A ll of a sudden , employees needed to access assets outside of the office, usually through a VPN, which made authenticating devices and securing remote user access to systems more important than ever.

In response, organizations identified PKI as the best wa y to authenticate their newly mobile workforces. Specifically, they began to put certificates on employee laptops (and any other devices like mobile phones) to verify that devices connecting to the VPN or accessing assets from outside the office were indee d employee devices and had the right antivirus software required to access those systems.

During this time, enterprise-issued certificates became like corporate ID badges. Organizations could deploy their own certificates and even put SSL or TLS certific ates on internal web servers to improve security by preventing plaintext passwords from flying around the network.

While this approach to PKI allowed enterprises to solve important problems around authenticating a mobile workforce and encrypting internal systems, it also created a new set of challenges around ensuring a healthy program.

First, organizations needed to put a lot of effort into designing robust and secure PKIs that adhered to best practices. Second, they needed to find ways to properly track their PKIs to ensure certificates didn't expire and/or that they weren't compromised and needed to be revoked. To stem these challenges, most organizations introduced PKI management programs led in-house by employees with relevant expertise.

The Third Wave: New Uses and Growing Pains (2011-Today)

The third wave of PKI, which we're still experiencing today, includes several new uses around the Internet of Things (IoT) and some growing pains with scaling PKI  along the way.

Today, organizations issue millions of certificates to authenticate a fully mobile, multi-device workforce . Beyond employee devices, organizations also have to  manage embedded certificates in all sorts of cloud systems. Finally, the rise of the IoT has led to millions of new connected devices , each of which needs to be secured, authenticated, and able to get firmware updates. All of  these connections make PKI more important than ever and have l ed to enormous growth in this space.

But as PKI becomes more important and more prevalent, it also gets more challenging. Specifically, today's connected digital worl d creates PKI management challenges around getting certificates where they need to go, ensuring certificates are properly vetted and mapped, and monitoring already-issued certificates.

Overseeing, managing, and updating millions of certificates is such a b ig job that most organizations now rely on third-party managed service providers and specialized certificate management tools to handle their PKI . This trend is similar to  the move t o the cloud, as organizations shifted from owned data servers to third-party cloud computing providers.

Engaging a managed service provi der for PKI  allows each organization to focus their employee's expertise on areas directly related to their line of business (rather than operating infrastructure) and protects against turnover among PKI experts. Most importantly, it improves PKI management and security  by providing access to a large team that specializes in developing and running best practice PKI programs.

What are Common Challenges that PKI Solves?

A wide variety of use cases exist for PKI. Some of the most common PKI use cases include:

• SSL/TLS certificates to secure web browsing experiences and communications
• Digital signatures on software
• Restricted access to enterprise intranets and VPNs
• Password-free Wifi  access based on device ownership
• Email and data encryption
  

One of the most expl osive uses for PKI that is just now taking off centers around authenticating and securing a wide variety of IoT devices . These use cases span across industries, as any co nnected device — no matter how innocuous it may seem — requires security in this day and age . For instance, The Home Depot data breach first started because hackers were able to access the retailer's point of sale system by getting onto the network posin g as an unauthenticated HVAC unit.

Some of the most compelling PKI use cases today center around the IoT. Auto manufacturers  and medical device manufacturers  are two prime examples of industries currently introducing PKI for IoT devices.

Auto Manufacturers and PKI

The cars produced today are highly connected due to features like built-in GPS, call-for-help services like OnStar and vehicle parts that self-monitor for maintenance needs. These capabilities create a variety of connection points where things like data an d software updates get passed back and forth.

If any of these connections are insecure, the results could be catastrophic, as it would open the door for malicious parties to hack into the car to do things like gain access to sensitive data or send malwar e to vehicles so that they purposely harm people. As a result, it's critical that any piece of the car that's connected receives a digital certificate to ensure security.

Medical Device Manufacturers and PKI

Medical devices, such as surgical robots and next-generation pacemakers, are also becoming more connected and require higher security precautions as a result . Additionally, the FDA has now mandated t hat any software as part of a next-generation medical device must be updateable, that way manufacturers can easily shore up inadvertent bugs and patch security issues.

While this mandate does a lot of good in terms of making this next-generation software more advanced, it also opens up  vulnerabilities by creating more points of connection for malicious parties to hack into and take control over. PKI limits these vulnerabilities by issuing certificates to the devices and any software with which they communi cate so that each side can authenticate data sources to ensure they only accept data and updates from the intended source.

Ready to Get Started with PKI?

PKI helps secure our digital world by protecting sensitive data and communications and verifying digit al identities. And as the number of connected devices and applications explodes, this security continues to grow in importance.

For enterprises , in particular, introducing  PKI is critical — but it's also only the first step. Building and maintaining a be st practice PKI program that manages millions of digital certificates isn't easy, but that's the challenge facing today's enterprises.

Ready for more information? Whether you're first getting started with PKI or need help improving PKI program management,Key f actor  can help. Click here to learn more.

What Is Pki and How Does It Work

Source: https://www.keyfactor.com/resources/what-is-pki/

Share :