Just how protected are your passwords and credit card numbers when you enter them into websites? That's where PKI (public key infrastructure) comes in.
In today’s digital age, we transmit sensitive data across both the internet and the globe. You purchase items from e-commerce sites and transmit your credit card information to the supplier. Sometimes, you log in to your bank and plug in your user id and password. Other times, you log into a patient portal to schedule a doctor’s visit and provide the doctor with your social security number and information about your medical history. All of this data is sent across the wire daily, but do you know and understand how your data is being secured?
Defining “PKI”
A public key infrastructure, or PKI, allows this data transfer to occur securely. A PKI is a cryptographic system built on asymmetric encryption, or a public and private key pair. Many encryption examples use the analogy of a lock and a key to graphically represent a public and private key pair. The public key (or lock) can be used by anyone to encrypt (lock up) the information. The private key, like a physical key, is only held by one person – the person who can unlock or decrypt the information. The private key must always be protected so that it doesn’t fall into someone else’s hands.
Providing PKI Services
Public key infrastructure is the heart and soul of secure digital communications. A PKI provides four basic services to secure data transfers across the wire. These services include:
- Confidentiality – Ensures that your data can only be read by the person or endpoint you sent it to.
- Integrity – Ensures that the data that you sent is the data that is received, and that the data hasn’t been tampered with.
- Authentication – Establishes the identity of the person or endpoint you sent the data to, ensuring that someone or something isn’t pretending to be the endpoint.
- Non-repudiation – Ensures that you can prove the origin and contents of the data to a third party.
Differentiating Between External and Internal PKIs
An external, or public, PKI provides its services to any person or website on the public internet. There are companies that run external PKIs, such as Verisign, Entrust, and Thawte. If your business needs to secure communications across the internet, it will need PKI services from an external PKI. This service has a cost associated with it.
However, if a business needs to secure communication within its organizational or network boundaries, the business can choose to create its own internal PKI. Running an internal PKI has its own cost of management, so be sure to weigh both costs for your internal business communication.
Establishing a PKI Infrastructure with a Certification Authority
A PKI infrastructure can be made up of one or more tiers. The root Certification Authority, or CA for short, acts as the “root of trust” and provides the services that validate, or authenticate, the identity of the entity, person, or endpoint. The CA provides a Certification Practice Statement (CPS) that defines its policies and procedures for certificate lifecycle management, including verifying an entity’s authenticity.
A good PKI design contains one or more subordinate CAs in addition to the root CA. These CAs are always online and do the “heavy lifting” of the PKI infrastructure, including receiving certificate requests, issuing, and revoking certificates.
Securing the Root CA’s Private Key
A root CA’s private key is used to issue a self-signed certificate that contains the root’s public key. The most important secret of a PKI’s infrastructure is the root CA’s private key. If a malicious user were to obtain the root’s private key, the bad guys can issue fraudulent certificates for any website – and the browser would accept the certificate as valid. In addition, all websites with a certificate generated from that CA are susceptible to a man-in-the-middle attack.
Read: How To Use Syslog To Help Defend Against Network Attacks
Therefore, significant measures must be taken to protect a root’s private key. Root CAs should be built offline with no network access at all. There have even been suggestions to fill the Ethernet port on the server with glue so that it’s not possible to connect it to the network by accident. It’s also possible to have a hardware security module, or HSM, serve as the root CA in a PKI infrastructure.
Delegating Work Using Subordinate CAs
Since the root is offline (and should be powered off most of the time), there needs to be other servers in the infrastructure that do the work to issue the end-user certificates. Root CAs sign the certificates that are issued to the subordinate CAs, allowing them to issue endpoint certificates. Thus, subordinate CAs sign the endpoints’ certificates, establishing a chain of trust.
An end-user device needs to trust both the root CA’s certificate and the intermediate certificate to validate a certificate up the chain to the root. While the threat of interception of a subordinate CA’s private key still exists, the compromised private key can be revoked by the root and ultimately invalidate any certificates issued by the compromised subordinate.
Following Along - A Simple Example
Think for a moment about going to a bank’s website. For example, you type in https://www.bankofamerica.com and you are magically whisked away to a server or endpoint behind www.bankofamerica.com. How do you know it really is Bank of America, though? You can tell by its certificate.
In the browser, you will see a lock icon, and hopefully that lock is “shut”. This means that the site is “secure” – the site is the same site that you intended to go to and it has a certificate as proof. You can see for yourself. Most browsers support clicking on the lock icon and provide a method so that you can view both the certificate for the website as well as the certificate chain all the way up to the root.
To Trust or Distrust?
When it comes down to it, as end users, we place our trust in the public PKI infrastructure every day – by shopping, banking, and filling out forms online that contain our most precious information like passwords, credit card numbers, and social security numbers. While threats to our information always exist, we expect that businesses, whose job it is to protect our information, do so to the best of their ability by treating the security of that information as if it were their own. After all, if they don’t take the security of our data seriously, and a breach of extreme magnitude happens, they would likely no longer be in business.
Missy Januszko
Missy Januszko is an independent IT consultant, with more than 20 years of experience as an enterprise hosting architect, large-scale infrastructure designer, and hosted application designer. She specializes in DevOps, automation and configuration management, PowerShell, and Active Directory, and has broad experience across the entire line of Microsoft business technologies. Missy is a co-author of “The DSC Book” with Microsoft MVP Don Jones, and she is also a conference speaker on DSC-related topics. She is a contributor to a number of open-source projects, including “Tug”, the open-source DSC pull server, and “Autolab”, an automated, rapid-install lab build.