PKI — public key infrastructure, explained

(originally posted with thanks to Lesley “Hacks4Pancakes” Carhart)

Here’s why I know about this

My tech journey started in academia, where I spent my time writing math in Java. As I transitioned more and more to tech, I ended up as the de facto PKI manager for several projects. I handled certificate management while I was at Microsoft Game Studios working on Lips for Xbox and Halo for Xbox, and debugged the cert management process internally for two teams I worked on. On my own projects and for two startups, I used a 2009 Thawte initiative that provided certificates free to open source projects, and then rolled my own local CA out of that experience. I managed certs from Entrust for one startup. I handled part of certificate management at Silent Circle, the company founded by Phil Zimmermann and Jon Callas, the creators of PGP. I was Principal Security Advocate at Symantec, and Senior Director of Engineering in Website Security — the certificate authority that owns familiar words like VeriSign, Thawte, GeoTrust, and others. I was one of the Symantec representatives to the CA/B (Certification Authority/Browser) Forum, the international body that hosts fora on standards for certificates, adjudicates reliability/trustworthiness of certificate authorities, and provides a discussion ground for the appropriate issuance and implementation of certificates in browsers. Now, I use LetsEncrypt and Comodo certs for two WordPress servers. I have a varied and colorful, and fortunately broad experience with cert management, and it helped me get a perspective on the field and on good vs. bad policy.

Here’s the best, “500 words or less” explanation of what PKIs are and what they’re used for today

PKI or public key infrastructure is about how two entities learn to trust each other in order to exchange messages securely. You may already know that Kerberos and the KDC (Key Distribution Center) work on a shared-secrets principle, where users can go to a central authority and get authorization to communicate and act in a given network. PKI is a more complex system that understands lots of different networks which may or may not share a common trust authority. In PKI, you’re negotiating trust with a root which then tells you all the other entities that you can trust by default. The central idea of public key infrastructure is that some keys you already trust can delegate their trust (and hence yours) to other keys you don’t yet know. Think of it as a very warm introduction by a friend to someone you don’t yet know!

There are five parts of certificate or web PKI.

  1. Certificate authorities, the granting bodies for public/private keys, are in practice a form of verification to grease those wheels when there’s no other method of demonstrating that you are who you say you are…a function of identity. Yeah, I know I said that two entities can trust each other without a common authority, but humans aren’t good at that kind of trust without someone vouching for them. So, we have CAs.
  2. Registration authorities have what is essentially a license to issue certificates based on being trusted by the CA, and dependent upon their ability to validate organizational identity in a trustworthy way. Certificate authorities may perform their own registration, or they might outsource it. CAs issue certificates, and RAs verify the information provided in those certificates.
  3. Certificate databases store requests for certificates as opposed to the certificates themselves.
  4. Certificate stores hold the actual certificates. I wasn’t in charge of naming these bloody things or I’d have switched this one with certificate databases because it’s not intuitive.
  5. Key archival servers are a possible backup to the certificate database in case of some kind of disaster. This is optional and not used by all CAs.

Keys work like this: a pair of keys is generated from some kind of cryptographic algorithm. One common algorithm is the RSA (Rivest-Shamir-Adleman) algorithm, and ECDSA (Elliptic Curve Digital Signature Algorithm) is coming into more common use. Think of those as wildly complicated algebraic equations that spit out an ‘x’ string and a ‘y’ string at the end that are interrelated. You can give the ‘x’ to anyone anywhere, and they can encrypt any message, ‘m’ with that x. Now, while they know the original message, only you can unencrypt the message using your ‘y’ key. That’s why you can send the ‘x’ key to anyone who wants to talk to you, but you should protect the secrecy of your ‘y’ key with your teeth and nails.

The two major uses for PKI are for email and web traffic. On a very high level, remember that traffic over the Internet is just a series of packets — little chunks of bits and bytes. While we think of email messages and web requests as philosophically distinct, at the heart, they’re just packets with different port addresses. We define the difference between messages and web requests arbitrarily, but the bits and bytes are transmitted in an identical fashion. So, encrypting those packets is conceptually the same in PKI as well.

If you want to secure email back and forth between two people, the two most common forms of PKI are PGP (Pretty Good Privacy) and S/MIME (Secure/Multipurpose Internet Mail Extensions). PGP is the first commonly used form of email encryption. Created by Phil Zimmermann and Jon Callas in the early 1990s, PGP is notoriously both secure and difficult to configure for actual human usage, but remains the standard for hyper-secure communication such as with journalists or in government usage. S/MIME is the outsourced version of PKI that your email provider almost certainly uses (once they’ve machine-read your email for whatever commercial/advertising purposes they have) to transmit your email to another person over open Internet traffic. While S/MIME is something most users don’t have to think about, you’ll want to think about whether you trust both your email provider and the provider of the person you’re sending your email to.

The other major use for PKI is a web server authenticating and encrypting communications back and forth between a client — an SSL/TLS certificate that’s installed and working when you see “https” instead of “http” at the beginning of a URL. Most of the time, when we’re talking about PKI in a policy sense or in industry, this is what we mean. Certificate authorities such as DigiCert, Comodo, LetsEncrypt, and others will create those paired keys for websites to use to both verify that they are who they say they are, and to encrypt traffic between a client who’s then been assured that they’re talking to the correct web server and not a visually similar fake site created by an attacker.

This is the major way that we who create the Internet protect people’s personal information in transit from a client to a server.

Quick tangent: I’m casually using the terms “identification,” “authentication,” and “authorization,” and to make sure we’re on the same page: authentication is making sure someone is who they identify themselves to be. Authorization is making sure they’re allowed to do what they say they’re allowed to do. If I’m a night-time security guard, I can demand ID and authenticate the identity of anybody with their driver’s license, but that doesn’t tell me if they’re allowed to be in the building they’re in. The most famous example in literature of authorization without authenticated identity is the carte blanche letter Cardinal de Richelieu wrote for Madame de Winter in “The Three Musketeers,” saying that “By My Hand, and for the good of the State, the bearer has done what has been done.” Notably, D’Artagnan got away with literal murder by being authorized without authentication of identity when he presented this letter to Louis XIII at the end of the novel. Also: yes, this is a spoiler, but Alexandre Dumas wrote it in 1844. You’ve had 174 years to read it, so I’m calling it fair game.

There are a few other uses for PKI, including encrypting documents in XML and some Internet Of Things applications (but far, far fewer IoT products are using PKI well than should be, if I can mount my saponified standing cube for a brief moment).

Why do we use PKI and why do information security experts continue to push people and businesses to use encryption everywhere? It’s because encryption is the key (pun absolutely intended) to increasing the expense in terms of time for people who have no business watching your traffic to watch your traffic. Simple tools like Wireshark can sniff and read your mail and web traffic in open wireless access points without it.

A couple of really critical concepts we should understand with regards to how a modern PKI functions

The difference between identity and security/encryption. We as security people understand the difference, but most of the time, the way we explain it to people is to say “are you at PayPal? See the big green bar? That’s how you know you’re at PayPal” as opposed to “whatever the site is that you’re at, your comms are encrypted on the way to them and back.”

There’s a bit of a polite war on between people who think that CAs should help to verify identity and those who think it is solely a function of encryption/security. Extended validation (“EV certs”) certificates show up as those green bars in many desktop browsers, and are often used to show that a company is who they say they are, not just whether your traffic back and forth is safe.

Whether they *should* be used to identify websites and companies is a topic still up for debate and there are excellent arguments on both sides. An extended validation certificate can prove there’s a real company registered with the correct company name to own that site, but in rare cases, it may still not be the company you’re looking for. However, in practice and especially for nontechnical people, identifying the site is still a step up from being phished and is often the shortcut explanation we give our families at holidays when asked how to avoid bad links and giving out credit card info to the wrong site.

Here’s how to conceptualize PKI

PKI has become an appliance with service providers and a functional oligopoly of certificate authorities that play well with the major browsers. That isn’t necessarily a bad thing; it’s simply how this technology evolved into its current form of staid usefulness and occasional security hiccups. In reality, most people would do better knowing how best to implement PKI, since vulnerabilities are in general about the endpoints of encryption, not in the encryption itself. For instance: don’t leave 777 perms on the directory with your private keys. If your security is compromised, it’s likely not because someone cracked your key encryption — they just snagged the files from a directory they shouldn’t have been allowed in. Most PKI security issues are actually sysadmin issues. A new 384-bit ECDSA key isn’t going to be cracked by the NSA brute forcing it. It’ll be stolen from a thumb drive at a coffee shop. PKI security is the same as all other kinds of security; if you don’t track your assets and keep them updated, you’ve got Schroedinger’s Vulnerability on your hands.

PKI isn’t the lowest-hanging fruit on the security tree, but having gaping network/system security holes is like leaving a convenient orchard ladder lying about.

Here’s some self-study suggestions

Roll your own certs and create your own CA. Do it for the practice. I was on Ubuntu years ago when I was rolling my own, and I used the excellent help docs. One best security practice is to regularly generate and use new keys, instead of keeping the same key for years and years, for the same reasons that changing your password regularly for high-security sites is a good idea — and that’s true whether you’re creating your own certs and local CA or if you’re simply purchasing a certificate from a CA. As with so much else, rolling your own crypto means that YMMV, so if you’re thinking of doing so formally and for a company or project that holds critical or personal information, get a pro to assess it. Think of this like a hobbyist building cars or airplanes at home. Most may be fine with riding in their own homebrewed contraptions, but wouldn’t put a child in it. If you don’t have the time to be a PKI professional, don’t keep other people’s data safe with your home-brewed certificate authority.

Most of the time, security issues aren’t with the encryption itself, but with how it’s been implemented and what happens on the endpoints — not with the math, but with the people. Focus on keeping your keys safe, your networks segmented, and your passwords unique, and you’ll be ok!

*I would like to thank Ryan Sleevi for feedback, and especially for providing the Kerberos/PKI analogy for comparison. All errors are mine.

How much should startups spend on information security

When you have little to no budget, how do you start spending on information security in a startup to protect customer data and operations? I was asked to comment on this via email by Zack Whittaker for a story he was doing on TechCrunch, and in responding, I found myself getting writer-mad, so I knew I had something to say. Here’s his original article (it’s paywalled as an Extra Crunchy article).

And here are my original thoughts, slightly edited to remove unnecessary emoji and “I know, right???”s from the text.


This is a fascinating question, and in fact, my good friend and longtime collaborator Liz Dahlstrom and I did a talk on this at SOURCE Seattle 2013 on “Implementing Security In A Pre-Investment Startup.”

The biggest thing startups need to recognize is that fractions of a role are a thing. If you have a ten person company that stores no or very little user data on prem, your fraction of infosec (responding to phishing or prepping for potential ransomware spillover effects) is going to be less than one. Like, one person in that company is going to be doing IT all together, and maybe 1/4th of that person’s time will be infosec as opposed to IT contracts management, setting up environments, handling domain issues while collaborating with marketing and sales (which are also often the same person in a small company).

The biggest thing I’ve seen is that if you’re going to have that fractional component in someone’s job, then the leader of that company must jealously guard that person’s fractional commitments. If you as the CEO of a small company have an IT human, and you have told them to dedicate 1/4 time to infosec, take that seriously. That quadrant of the person’s job will grow as the company grows, and when IT needs to hire another person, then the first person might have 1/2 their time on infosec with the second person wholly in IT. Then infosec will grow again, and somewhere around 50 people, you’ll hire the first infosec engineer and generalist who can do things like make sure there’s a corp VPN, or dedicate a day of training to the company each year, while monitoring a nascent SOC and perhaps around 100–200 people, starting to get a SIEM put together. No company under 2000 people without dedicated financial information really needs a fully built-out internal red team with all the skills; that’s simply too expensive compared to the company’s appetite for consuming their results and implementing changes.

The first dedicated person a company should be hiring is the person managing a third party monitoring service that is a SOC in a box. They’re fundamentally blue team. That’s why blue team is so much more important initially. I have found, anecdotally, that you need about one red teamer per ten blue teamers, depending on the company’s business. Basically, after that, red teamers will provide so much fixable data that blue team can’t keep up. That’s the offensive advantage you’re always hearing about in corporate environments.

The smartest thing a startup can do is have their risk person (usually whoever is running finance) figure out their risk profile and threat model, and allocate resources according to that…but very plainly, I’ve never seen the need for a dedicated offensive security pro inside a company until that company is at least 500–750 people. It’s just too easy to knock over targets before that, and you can buy those assessments for much, much cheaper than a FTE salary of one of the most desirable, hottest skillsets in the world right now.

Sometime around 250–500 people, you’ll have that fractional time from one of your infosec people in doing network pentesting/red teaming, and then it will start to expand out, just as I described when moving from IT to a fractional infosec role that will eventually grow. Then the infosec role will start to split from 100% blue team (SOC management) to security awareness. If the company’s big enough to have a real office and real money and real grups on the board, they’re big enough to get phished, to be burglarized for their laptops, to have their data breached. That’s a security awareness pro’s job.

dark server hallway

No company too small to have a person with skills in risk profiling and financial management of liability should be storing customer financial data on-prem. Outsource that liability and responsibility to AWS; it’s what they’re there for. Buy at least one security assessment a year, and it should be more like once a quarter, if you can get to continuous integration and automation of security improvements (which is incredibly hard to do and I’ve almost never seen done well).

Change my mind.

Yes, there was a hidden epic cryptographic puzzle story inside my book, “Women In Tech.”

And the champions just received their solid silver medals for solving the series.

EDIT: the writeup in Techdirt by Mike Masnick was lovely. Five Years Later, Team Solves Puzzles In Women In Tech Book

I wrote a book called Women In Tech that came out in 2016 which has become one of the top books on Amazon in their Career Guides lists, floating between top 10 and top 100 much of the time and is the #1 bestseller right now.

Let’s look back to the middle of 2015. I’d just run the biggest anthology Kickstarter of all time according to the project manager there who’d reached out to me as the site featured it as the Project Of The Day. The level of hatred and anger I’d seen directed at me — and the women I’d asked to contribute vignettes to the book — was at an all-time high. My first marriage had started to suffer. All I heard from the Internet was how much the right wing hated me for helping women who didn’t deserve to be in tech or making “a man’s salary”, and the left wing hated me for giving practical advice like “don’t wear a skirt to a sysadmin interview” instead of burning down the system. Conspiracy theorists thought I’d had it ghostwritten (trust me, you can’t pay a ghostwriter to pun as badly as I did while suffering through that first draft), and my job, my home, my cats, and my life were endlessly threatened.

I hated this fucking book. I hated it while I was writing it. I didn’t think that would happen. But I did. It was my biggest source of misery and success at the same time until my Foreign Policy article on cyberwar came out in 2018.

And yet…

There was a secret in that book. It’s a secret that I’ve kept for half a decade, and while I’ve loved the wonderful messages and notes of support from people who’ve benefitted from this work, the puzzles I hid in it are the only unmitigated, unsoured, pure joy I’ve experienced in creating this Frankenstein’s Creature of a book.

I filled it with puzzles. I plastered it with puzzles. I was filled with anticipation at the thought that someday, people would see it.

Then some people noticed the codes and puzzles. A few people tried to solve them. Teams formed on Reddit and Twitter and Discord. And one small crew of four people finally journeyed to the end of the epic. And that’s how they won the secret buried treasure of pounds of precious silver.

Here’s what I’ve waited a half decade to say: some of the people I admire most in the world helped create these cryptographic challenges. Some of you might have heard of DEF CON and its incredible contests, games, and challenges. The globally-known creator of those puzzles, 1o57 (or as we call him, LosT) is the first person of whom I thought when my publisher said “You know, there will be some pages that back up against chapter openings that we like to do on the right hand side of a page spread; do you have anything you would like to put on the left hand side of the page?”

Why, yes. Yes, I would.

Crypto puzzle inside Women In Tech

Then I thought to myself about the world I came from. Not as a professional, but as a kid coming from the comics, gaming, and geek world. There’s such beauty and joy in games, and one of the most famous designers in the world, Mike Selinker — president of Lone Shark Games, creator of the Pathfinder RPG card game, and writer for Dungeons & Dragons, Axis & Allies, Betrayal at House on the Hill, the Harry Potter CCG, and cryptic crosswords for the New York Times and much, much more — happens to be here in Seattle. I tracked Mike down and took him to lunch, and talked him into participating in these puzzles and games. Mike introduced me to Gaby Weidling, the pre-eminent Seattle-based escape room designer, the lead for the Magic: The Gathering’s Shadows Over Innistrad escape rooms, Maze of Games book developer, co-design lead on the Mummy’s Mask set for the Pathfinder Adventure card game, and instructor in puzzle design at DigiPen. She became the leader that drove this story and the coherent, sequential placement of the puzzles into the book.

Braille puzzle inside Women In Tech

I’ll give total credit to my editor, Hannah Elnan, at the Penguin Random House imprint Sasquatch Books, for her asking me the question one day, “say, do you want to do anything cool with the cover? We could add some kind of embossing or patterning if you like. Do you have any thoughts?” I sat on that question for a day or two, and then I had an idea. What if the cover had code on it?

What if the cover had REAL code on it?

What if the cover’s code was just the start of the puzzle journey?

When we tell people to start learning code or scripting now, we say “just learn Python.”

So, quaking in my stylish yet affordable boots, I emailed Guido van Rossum, the creator of the Python computer language, to ask him to contribute the Python code that is hidden on the cover of the Women In Tech book.

Reader, he said yes.

Embossed code on the cover of Women In Tech

When the book came out, I saw Guido’s code, Gaby/Lost/Mike’s puzzles, and a hidden journey all the way through it.

And I silently waited.

For four years.

One year ago today, on July 11th, 2019, I got the email with the solution phrase I’d been waiting for. That day, I met DA FREQS: wagwan piffting, JoyKil, variable.label, and cr4mb0. Find them on Twitter here.

I’d known I wanted to do something really special for the winners. I collaborated with two amazing humans to make the prizes. My lovely (now) spouse, Deviant Ollam is a physical penetration specialist, an artist, and the person with the original idea and sketch for these cipher wheels. My friend Jon Callas is a brilliant and kind human, Senior Technology Fellow at the ACLU, one of the greatest living cryptographers — if you enjoy full disk encryption and email privacy then feel free to send him a thank you note — and he worked with me to create the crypto for the silver cipher wheels.

The wheels are elegant, complex but decipherable, and about 5 ounces of solid silver each. The winner wheels contain a pangram of a 26-letter English sentence.

I’m a writer, not a filmmaker, but I’m married to one. Deviant not only was the manufacturing lead on the silversmithing with the STL files (side note: manufacturing physical materials is both hard and time-consuming), but also made this video of me explaining what the puzzles represent and how they led to the silver cipher wheels that became the prizes for finding — and solving — the epic cryptography journey in my book. Secret In The Book: Cipher Wheel In Silver

This all makes me so proud.

Learn more and create your own codewheels here at my GitHub where I have the STL files you can mix and match for 3D printing or physical manufacturing.

HERE THEY ARE, THE CHAMPIONS! Here you can see the 4-person team who spent years painstakingly pulling these puzzles apart and solving them. Spending time with the four winners, Mike, Gaby, Jon, Guido, and LosT as well as my lovely husband was basically the Video Meeting To Rule Them All.

JoyKil (MaryBeth Panagos) said “The community around cryptographic puzzles is a welcoming and progressive one. At first, I’d joined this community anonymously, not wanting to be known as a woman. Over time, I found a crew who encouraged each other — no matter our gender — and found joy in the journey — exploring rabbit holes and ideas as we homed in on these solutions.”

Everyone got to meet each other, and the puzzle designers were thrilled to hear how much the winners agonized over the puzzles before finally solving them! It was an honor to be in this meeting and I am so filled with joy over this whole project. Much love to you all.

***SPOILERS Here’s the winning team’s writeup SPOILERS***