What Is PKI?
Have you ever tried to download random software and, upon attempted installation, gotten a horrifying security message alerting you that the software developer was not trusted? Perhaps you were even unable to install this untrusted software because of your system's built-in security settings or antivirus software. How does your computer know who to trust? It is not out of a mysterious intelligence your laptop has; it's because of PKI.
Simply put, critical public infrastructure is as it sounds: infrastructure that enables cryptographically verifiable issuance of a public certificate (the public part of a key pair). Encryption fundamentally is this public text that looks like garbage. When run through the generated crypto algorithm, it can decrypt information encrypted with the private key's public counterpart. Typically that public cert is publically accessible, allowing people to encrypt stuff to you and will enable you to decrypt it.
If you want a pretty thorough technical background on PKI, check out this from Thales. PKI is a mind-melting technology with many moving parts, but it's critical to nearly all modern networking and security related to authentication, authorization, and software supply chain integrity.
PKI, aka Public Key Infrastructure, is one of those integral pieces of connected life that most technology users know nothing about. The simplest, most non-technical way to define the function of PKI is: PKI enables trust. Trust can be used to authenticate users and ensure the users showing are who you believe them to be with high assurance. It also allows your computer's web browser to connect to this website. The browser trusts this website is legitimate. Legitimate, in this case, means your browser sent out a request for this website; this website told your browser, "hey, this is who I am," and your browser can verify that the website isn't lying. This can only happen because of specific trust standards defined by the wizards of public trust: The CA Browser Forum.
Defining Trust
To simplify the context, I will use Apple software as an example. Apple has a developer program. Apple has quite a robust vetting process should you wish to distribute software in their App Store for Mac, iPhone, Apple Watch, or whatever.
If SHE BASH decided tomorrow that we wanted to develop applications for users to download through the App Store, we would have to go through the following process:
In addition to the vetting process, we'd have to pay Apple $99/year. That buys us trusted status with Apple and thereby buys your trust in our software. Apple vets the application; thus, the user's risk is more around data collection and abusive privacy tactics rather than device-level exploits or malware.
If you have ever gotten the error: "Apple blocked opening ___ because..." basically, we don't know who made this and cannot attest to the contents within. Sometimes, it takes system-level, root, and permissions to allow the software to run on Apple macOS. These are excellent ways to mitigate malware distribution by side-stepping the defined supply chain for Apple software.
Windows has a similar program, although the exact process I not quite sure. The bottom line is a need for trust. Ideally, everyone would trust SHE BASH, and in turn, SHE BASH could give you our software, and you would download and install it. No need for this middle man to get legal in the process.
This trust is not established because SHE BASH is trying to profit from this software we want to give you. This trust exists to ensure the security of what is being installed on your system. Would you appreciate it if, along with the software you downloaded and wanted from SHE BASH, we snuck in something like a Monero miner that used your computer's processor to send us an anonymous digital currency without you knowing about it, in essence stealing your computer's power, draining your laptops' battery, making your computer slower so we could siphon cryptocurrency back to ourselves? I'd imagine disclosing that to you would not make our software very popular.
If I had a link to download the "SHE BASH Photo Editor," the free photo editor we claimed was better than Adobe Photoshop, would you still download it? Do you trust us not to stick that Monero miner in some application? If you do, I will make this easy: you should not.
This is about as much laypeople's background on PKI use cases and reasons for it across technology. PKI is a daily part of our lives, whether you know it or not. Architecting it for a purpose takes a good understanding of authorization and authentication, a topic too broad to get into in this post.
Building Your Own PKI
Applications can use PKI to authenticate all an organization's users, machine identity, git commit signing, and code (artifact) signing. These use cases (and other missing ones) can be part of a PKI architecture and should be. Modern security is about having zero trust. The only way to account for transactions on your network is to verify them and architect a suitable way to delegate trust.
There are many reasons one may find one has their own private PKI. That seems oxymoronic on the first pass, but the public in technical contexts does not mean public to the general public. Recently I was tasked to assist in architecting, engineering, and implementing a PKI solution fit for enterprise compliance and security requirements. Without diving into any of the why or the how I want to offer some insight into lessons learned from that process and key technologies that enable robust PKI implementations at a massive scale.
Understanding PKI is complex; truthfully, there are still many use cases I have yet to explore. To build a PKI from scratch is a ridiculously tall order. I will follow up this write-up with the "how-to" create a certificate authority with intermediate CAs that can issue these certificates via an API. This is an emerging trend in microservice architectures at the service mesh and transport layer (layer 4), e.g., TLS/mTLS. This is accomplished via Hashicorp Vault to achieve high-grade and compliant security, specifically Hashicorp Vault Enterprise and FIPS 140-2 Level 2 and Level 3 certified.
To be continued
