(originally posted https://tisiphone.net/2018/03/07/the-infosec-amnesty-qa/ 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.
- 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.
- 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.
- Certificate databases store requests for certificates as opposed to the certificates themselves.
- 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.
- 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.
