 Great. Thank you all for coming. So my name is Jackie Elliott, and I'm a software engineer at Microsoft, and today we'll be talking about PKI fundamentals and how you can use these fundamentals to build your mental model. So this is a beginner-level talk, so I'm gonna assume that you've either only heard of a PKI, you're just getting used to the fundamentals, or you're not really sure how those fundamentals interact. So this talk is gonna be a lot, so let's dive in together. Okay, so first we'll cover what is a PKI. I'll share my definition with you, and then we'll dig into what the purpose is of a PKI. Then we'll look at the core components of a PKI to build our mental model, and then lastly, we'll review the benefits of having built this mental model. So let's first establish how I'm gonna define public key infrastructure. Also, formally, it's a set of technologies, processes used to establish and manage and maintain public key encryption to secure and authenticate digital communication. See, like, great Jackie, thanks, I still don't know what it is. So more simply put, implementing a public key infrastructure helps you establish encrypted and trusted communication between entities in your ecosystem. Okay, so that's a little bit more digestible. Okay, so what does a PKI accomplish for you? Well, it helps facilitate secure communication over a digital network, and this really goes beyond the scope of the cloud-native ecosystem. It's one of the most widely adopted frameworks for securing communication. You know, it's broadly used to secure websites, emails, VPNs, IoT devices, beyond, and when implemented properly, it can help prevent various cyber attacks. And there are numerous tools available in this ecosystem that vary in complexity and barriers to entry. So under the hood of a PKI, there are several core components working together to establish secure communication. And these are the ones that I'm gonna dive into today. Understanding these core components and how they interact will help you understand PKIs and their fundamentals and build your mental model. So these fundamental concepts are encryption, authentication, and integrity. Okay, so let's just jump right into encryption. So simply put, encryption is the process of transforming information in such a way that only authorized parties can access it. So without encryption, some bad actor with access to your network could obtain and read your data, which is not desirable. So encryption leverages cryptographic keys to encrypt and decrypt your data. So one type of encryption relies on the use of symmetric keys. So this means that data is encrypted. It's translated from plain text that you can actually understand yourself to cipher text. And decrypted back to plain text using the same key. And the key is the same key here is used for both encryption and decryption. So this type of encryption is fast and great for large amounts of data. Okay, so while it's fast and it's great, one challenge of symmetric keys is securely sharing this key that you're gonna use to securely communicate. So in this scenario, we have a client and server, Alice and Bob. I'll use them throughout, so get used to them. And they must have the same key to securely encrypt and decrypt their communication. Any bad actor with access to your network can obtain the key while it's being shared, potentially, and use this key to decrypt any future communication between Alice and Bob. Not so good. So another type of encryption is asymmetric encryption. So instead of having the same key as we had for symmetric encryption, you have a cryptographic key pair. So one key is the public key. It's used to... It's broadly distributed to all entities that wish to send an encrypted message to the holder of the private key. So this private key should be securely maintained by an entity, which is why it's represented as a lock. So I don't need anyone to dig into why one's a key and one's a lock and they're gonna unlock each other. The lock just means that you should keep it secure. It can decrypt any... the data that's encrypted by the public key. So both keys are actually capable of encryption and decryption of writing and reading. But for this example, the public key is gonna be doing the writing or encrypting, and the private key is gonna be doing the reading or decrypting. So one advantage of this solution is that you can keep these private keys secure. They can be shared broadly without fear of compromising the security of your encrypted data. So let's look at an example of how this public key exchange works. Okay, so we see Alice and Bob again. In this example, Bob has an asymmetric key pair. So he has both a private and a public key. Alice wants to send a message to Bob. So Bob shares his public key with Alice. So the bad actor with access to your network maybe could get this public key. But let's not panic. So Alice uses this public key to write her message. She encrypts the message that she wants to send to Bob. Okay, Alice sends this encrypted message. This bad actor can get it. Okay, but let's not panic again. So even though the bad actor has access to your public key, or your encrypted message, they don't have the private key. So they're not able to decrypt or read this message. So only the private key is doing the reading or decrypting in this configuration. So any entity with a public key can encrypt a message, but only one person has this private key. So despite the benefit of asymmetric keys, asymmetric encryption is slower and can encrypt less data than symmetric encryption. The strengths and weaknesses of each encryption mechanism influence when you use each key. Okay, so in summary, encryption in the context of a PKI provides data security in transit. So your data is only as secure as your encryption mechanism and the means by which your keys are distributed and stored. So asymmetric keys somewhat address this concern, but leave the question open as to how you know the key belongs to who it says it belongs to. So how does Alice know that the key that Bob shared was really Bob's? It could be anyone saying that they're Bob. She doesn't know that it's actually Bob's key. All right, so to examine how encryption is achieved in the concept of PKI, we need to discuss authentication. What's authentication, you may ask? Well, it's the next core component of PKI. And it's the process of verifying identity and legitimacy of the parties involved in the digital communication. So, again, we have this bad actor I've talked about. So not all entities have good intent when initiating communication or requesting information. They might impersonate a known entity to gain access to sensitive data. So he really wanted Alice's message that she sent to Bob. So authentication limits the implicit trust in your ecosystem by enabling entities to verify identities and as a result, the authenticity of the public keys that you're sharing. Okay, so how do PKI's help you achieve authenticated communication? Well, PKI's define this framework of trust. Great, what does that mean? So this framework includes trusted authorities that verify and manage the distribution of these verified identity documents or proofs of trust. The entities present these documents when initiating communication to enforce that the public key is their own. Okay, so there's three components in a PKI that come together to help achieve this authenticated communication, such as identity documents, trusted authorities, and some procedure or communication protocol. So there are many different types of identity documents. And the most common tool for demonstrating identity and trust and sharing a public key within the context of a PKI is a digital certificate. So for the rest of the time, I'm gonna be talking about digital certificate when I talk about verified identity. A trusted authority is responsible for managing and issuing these digital certificates. And this is typically a certificate authority. And again, this is what I'm gonna be talking about for the rest of the time. And then the most common procedure used by entities to share certificates and keys is the Transport Layer Security Protocol, or TLS. Okay, so let's first dig into what makes up a digital certificate. So this is obviously, or not obviously, I'm here to tell you this is not all of the fields within a digital certificate. These are just some of the common fields that I'm gonna highlight and are relevant to the rest of the presentation. So first you have the issuer. This is the name of the trusted entity that issued or signed your certificate. Then you have the validity period. This specifies how long the verified identity document can be used to establish trust. So a shorter validity period helps reduce the length of vulnerability if the issuer's validity is ever compromised. So you can ensure even if it's compromised, this certificate isn't valid for long. So the subject name contains the identity of the information, and the subject's public key is the actual public key related to that identity. So again, this helps tie that public key that we've talked about to the identity of the person or user entity. And then lastly, there's the signature of the trusted entity. So this signature signifies that the public key contained in the cert belongs to that person. It's trusted. And there are many different types of certificates, but for the sake of this presentation, I'm gonna be focusing just on TLS certificates. So that just really means that there's a public key and identity in this identity document. Okay, so now let's look at the role of a certificate authority and how it distributes trust. So at a high level, it receives requests for these verified identity documents from entities. It goes through a process of verifying that identity. I'm not gonna be talking about in this presentation, but there is a process to do that. And then it goes about signing certificates for that entity if it can verify it is who it says it is. So it's responsible for really binding that identity, again, to that public key. And it also maintains a record of all of the certificates that it's issued. And this depends slightly on whatever certificate authority that you're using, but that's relatively common. And then it distributes this chain of trust to this requested entity. So you might be thinking, Jackie, what's this chain of trust you've now brought up? And I'll get to that later. Okay, so the last major component of PKI authentication and encryption is this transport layer security protocol. So this protocol described as the exchange of TLS certificates and cryptographic keys between entities. So one of the most common implementations of TLS with an application level protocol is HTTPS, where the S is TLS. The fundamental mechanisms for authentication and encryption are achieved through the signed certificates from trusted authorities and through the cryptographic key pairs, which play a part in creating digital signatures, verifying those signatures and establishing future communications after exchanging those verified identity documents. Okay, so I think maybe people are familiar with the TLS handshake, but I just wanted to call out this process. So the actual handshake is the process which a certificate or certificates, in the case of mutual TLS, are exchanged, verified, and an encryption strategy is agreed upon. So there are several different TLS virgins and the exact process of this handshake varies. It's not necessarily standard, but there's some common threads throughout, and I haven't even touched on all of the common threads. So but first, both the client and the server must agree on which version of TLS they're doing or they're going to be using. If they don't agree on how they're going to be trying to trust each other, then that's just not going to go well. And then they also exchange their authenticated identities and they authenticate those identities and then they generate keys for future communications. But again, that part varies depending on the version of TLS that you're using and what Cypher Suite you're using. So now I'm giving you a lot of information so let's look at some workflows so maybe we can put this all together. So how do you go about obtaining a certificate? So this workflow we're going to be looking at is how certificates are commonly requested by an entity from a certificate authority, and this is in the form of a certificate signing request. So an entity will create this certificate signing request and generate its own asymmetric key pair. So this will be my public key and my private key, private key which I'm keeping private. And then when the certificate is issued, its signature will represent that that public key belongs to me, like I am who I say I am. Okay, so next the entity adds its identifying information. So it, you know, descriptors of me. So for a TLS certificate, the subject might contain the name, the organization, the address, et cetera. Okay, so once I've completed the certificate signing request or creating it, I can send this to the certificate authority. The certificate authority has its own cryptographic key pair, so it has its own public and private key. The CA begins the process of verifying who I am. Again, I'm not going to go into this, but it does. And for the sake of this presentation, let's assume I am who I say I am. So yeah, I'm not going to be going into that. And it really depends on the implementation of your certificate authority. So once the CA has verified I am who I say I am, it can create a certificate. So it adds the subject info and public key to the certificate and also my identifying information. It specifies the algorithm that was used to sign the certificate. And at a high level, this explains how the certificate data was hashed and digitally signed. And I'll go into that a little bit more later. Okay, the CA then creates the digital signature using its private key. A little bit more is involved there, but at a high level, the private key is involved. The signing process follows the previously specified algorithm that I just mentioned. And this signature can be decrypted using the public key of that certificate authority. And decrypted really means just verified in this sense. Okay, so when a CA responds to a certificate signing request, it doesn't just return your certificate for that entity, but it also returns this chain of trust. I mentioned that earlier, so we're coming back. So why do you need more than just one certificate? What is this chain of trust? So in simpler PKI infrastructures, there's only a root certificate authority and the leaf certificates that have been issued to entities. So the root certificate authority is literally the root of trust, meaning its own certificate is self-signed. There is no higher authority in the chain to verify the authenticity of this route. So all entities must implicitly trust the identity and public key of the root certificate authority. So the problem with this architecture is if the private key of this root certificate authority is ever compromised or the root certificate that's associated with that root certificate authority ever becomes invalid, then all leafs or entities will become invalid or be compromised. Okay, so now we're bringing in the intermediate certificate authority. This is an additional CA type that is authorized to sign certificates and is trusted by the root certificate authority. It can respond to entities' certificate signing requests, which we talked about earlier, and issue certificates, so it has that power. And the certificates issued by this intermediate CA have the same common root of trust. What's the benefit of this? Why did I introduce more complexity to this? Well, in general, this allows you to keep the private key of your root certificate authority, which again, remember the lock, it should be kept secure. It can be maintained offline, and it only needs to be occasionally used when you're issuing new certificates for your intermediate certificate authorities. So you can keep that relatively secure. And it reduces the chances of compromising that private key and mitigates the consequences of compromising the intermediate certificate authority. Okay, so what does this have to do with this chain of trust? Okay, well, the leaf certificate, the intermediate certificate, the root certificate, all those together make your chain of trust or trust bundle. And this is required to validate the validity of this leaf certificate, or this end entity certificate. Okay, so now let's go back into familiar territory with Alice and Bob. So Alice has shared her trust chain with Bob. Bob is inspecting her certificate. And he sees that their certificate has been signed by an intermediate CA. Now, a reminder that Bob only implicitly trusts the root CA. He only has the root CA's public key. So let's take a closer look into Alice's certificate so we can understand how Bob's going to go about verifying that Alice is who she says she is. Okay, so this is Alice's leaf certificate. So let's quickly review the contents again, so we're all on the same page. So we have the subject name, Alice, that makes sense. Alice's public key, which we can see. And then you can see that it was issued by the intermediate CA, which is what we just saw. And so that means that it was also signed by the intermediate CA. And it was made by the intermediate CA's private key. So Bob doesn't have or implicitly trust the intermediate CA's public key, which he would need to verify the signature. Because, again, remember, you can verify a signature using the public key of that certificate authority. So he needs to go and look at this intermediate certificate. Great, we have it, because it's in our chain of trust. So Bob sees that the issuer of the intermediate certificate is the root CA. That makes sense, based on the diagram that we went through. He can't trust the intermediate certificate until he verifies the root. So let's look at the root certificate. Okay, this makes sense. So Bob implicitly trusts the public key of the root CA, so he knows that it belongs to the root certificate authority. And as a reminder, this root certificate is self-signed. So you can see that its signature comes from its own private key. And it can be verified using its own public key. And that's pretty much, yeah, he can verify the signature of the root CA certificate using his public key, which is what I just said. Okay, so now he's verified it. He ensures that the root CA is trusted. So he can use now this root CA's public key to verify the signature on the intermediate certificate. Okay, so once he's able to verify that signature, he can trust that the public key actually belongs to that intermediate CA. So there's no implicit trust going on. He actually is verified that the intermediate CA is who it says it is and that its public key belongs to it. That's great. Now I can finally get to where I was trying to go, which is where I'm trying to verify that Alice's certificate is her own. So I can use the public key of the intermediate CA to verify Alice's signature on Alice's certificate. So let's just say I was able to verify it. Great. I can trust that Alice is who she says she is. It's great. We made it through chain of trust, so that's exciting. Okay, so we've navigated the chain of trust to verify that the public key contained in the certificate belongs to Alice. So while the certificate may be valid, it also might have been revoked. So realistically, this is something you might have discovered while working your way through the chain of trust, but it's really important to call out. So what does it mean by a certificate being revoked? So this might be when either your system or your private key was compromised. And there's various different mechanisms to go about checking for certificate revocation. There's lists that you can go and verify to see if a certificate was revoked. But this is just another important thing that you need to check when you're verifying identity. It's not just enough to have the certificate and be able to verify those, but you also need to check if this really is valid anymore, if this intermediate CA is really... can be trusted. Okay, so the last thing I'm going to briefly touch on is integrity. This is the last main component of a PKI. So we've covered how to keep your data secure in transit with encryption and how to verify the identity of all parties involved in this digital communication. So today I'll just be talking about digital certificate integrity, but data integrity goes way beyond that. But integrity ensures that the data included in the subject's identity and public key has not been modified. So it helps all parties trust that the certificate sent was the certificate received. So the main method for achieving certificate data integrity is through digital signatures. So we've mentioned digital signatures, so bring that back up in your mind. And this signature is formed by applying a hashing algorithm to your certificate's data. The private key of the certificate's issuer signs... The private key of your certificate issuer encrypts this hash. This encrypted hash together forms the digital signature. And if you recall the algorithm that I described in the certificate, it was the certificate signing algorithm. This is where that process is described, both the hashing and the signature. Okay, so verifying the integrity of the certificate's data is validating the hash in that digital signature. So to verify the hash, you can compute your own hash from the certificate's data and then compare the two. So if the entity's computed hash matches the decrypted hash from their certificate, then the certificate's data integrity has been verified. This is a little complicated, but this digital signature does provide data integrity for your certificate. So the integrity of the data, again, is not limited to just verifying the integrity of certificates. It also implies the integrity of the data transferred in a digital communication. So this explanation really just helps you dip your toes into integrity. It certainly does not cover everything, but it gives you a high-level understanding of what integrity really means. Okay, so what are our next steps to reviewing these core concepts or core components of a PKI? So like, we made it through the core concepts. Okay, so let's reflect on this mental model you've begun building with these PKI fundamentals. So you now know how public key certificates, cryptographic keys, and certificate authorities all work together to form a public key infrastructure. So what's the point of this mental model that we built? We understand how the core tooling and components interact to form a secure infrastructure for digital communication. You have better access to understanding buzzwords, such as zero-trust environments, secure supply chains, I mean, even basically encryption and authentication. Those are really core words to be able to recall and understand. Also, you can better identify security risks and gaps in any proposed or existing architecture. You have the tools to better evaluate and learn new PKI technologies and tooling. And ultimately understanding these fundamentals will enable you to design a more secure infrastructure. So in the cloud-native ecosystem, there are many tools and frameworks relevant to public key infrastructure. So I totally could have missed some, but this is just meant to show you that there are a lot. So if you choose to attend a talk at KubeCon related to any of these toolings, I hope this talk will leave you more prepared to jump into learning those technologies so that you have a good understanding of these fundamentals so you can evaluate whether these tools are something that you want to use and bring to your own infrastructure. So in conclusion, ensuring that you have a good baseline understanding of PKI fundamentals will help you establish trust with your customers. And when your customers are happy, that's good business. So it's always important also to keep in mind that your infrastructure is only as secure as your least secure component. Understanding the components in play will help you maintain a more realistic understanding of the system security. So you're not overstating the security that you offer. So if you understand your security infrastructure, you can be realistic about what you're offering. And this truth and realism is really important. And lastly, your trust and security needs evolve. And so does this PKI landscape. So to offer the best solution, your mental model of these fundamentals needs to be continuously evolving so that you can continue to evaluate new tools and technologies and reevaluate the security of your infrastructure. So yeah, thank you so much. My name is Jackie Elliott. I'm from Microsoft. So I'd love your feedback. So please scan the QR code so I can get your feedback. And I'd be happy to take questions afterwards. So yeah, thank you so much.