Public Key Infrastructure (PKI) In this video you will learn the quite a bit about Public Key Infrastructure and how it is used to authenticate clients and servers. <Click> The purpose of Public Key Infrastructure is to create and distribute X.509 digital certificates to trusted entities, and then to act as a trusted 3 rd party in that each of the entities trust the 3 rd party, therefore, each entity should trust each other. Basically, it enables cryptographic authentication over an untrusted network. The Software Defined Perimeter and PrecisionAccess use PKI for the mutual authentication of clients to controllers, clients to gateways, and gateways to controllers. Basically, all trust in the Software Defined Perimeter is derived from PKI. Importantly, the Software Defined Perimeter performs mutual authentication, not just the single ended authentication performed by the great majority of servers today. So, how does it work? Well, here s the short version. <Click> PKI defines a Certificate Authority, which will generate and sign X.509 digital certificates and distribute them to clients, servers, and users (but we won t be talking about users in this video). In order to receive a digital certificate, <Click> an entity must communicate with the Certificate Authority and prove that it is trustworthy. Somewhere in this communication, <Click> an asymmetric key pair will be generated. The key pair can be generated by the server, by the Certificate Authority, or by some other computer. The important parts are that the private key remains private and that the public key be signed by the Certificate Authority. In addition, the server <Click> will download the root certificate of the Certificate Authority, and the server will trust any certificate that was either directly or indirectly signed by this root. In order to perform mutual authentication, <Click> the client must also communicate with the Certificate Authority and prove that it is trustworthy. Like the server, <Click> it will then end up with both a private key and a public key, the later of which was put into an X.509 digital certificate and signed by the Certificate Authority. And, <Click> if will also get the trusted root certificate. With that infrastructure in place, <Click> the client and server can mutually authenticate each other over an untrusted network using protocols such as TLS (also known as SSL). OK, that was the short version. How about the long version? Well, we have to start <Click> with the initialization of the PKI Certificate Authority. For this, <Click> we need a server and <Click> a key pair. Here, the red key is the private key (it s red because we need to stop anyone else from seeing it), and the green key is the public key (go ahead and look at this one). The Certificate Authority will generate <Click> a root X.509 digital certificate from a template defined by the owner of the Public Key Infrastructure. Like all X.509 certificates, the root will have a subject and an issuer. The subject is the holder of the private key, and the issuer is the Certificate Authority that issued the certificate. For the
root certificate, and only for the root certificate, the subject and the issuer will be the same entity and have the same common name. Next, <Click> the public key is put into the certificate. Then, we need to cryptographically prove that nothing on the certificate has been altered. To do this, we <Click> hash the entire certificate, and, then, <Click> encrypt the hash with the Certificate Authority s private key. Together, hashing and encrypting are known as signing. As we will see in a minute, certificates that are derived from the root, can be cryptographically proven to be reliable, but we need a mechanism by which certificates can be revoked, and that one entity validating another entity s certificate can check whether or not the certificate has been revoked. To do that <Click> PKI invented the On- line Certificate Status Protocol responder, or OCSP responder, for short. The OCSP responder <Click> reaches out to the Certificate Authority and gets its list of revoked certificates, know as the Certificate Revocation List, or CRL s, or crils. At that point, the Certificate Authority has been set up and <Click> the X.509 certificate has been created. Now, the Certificate Authority can begin to ack as a trusted 3 rd party. We will begin <Click> by providing a private key and certificate to the server. As before, <Click> we start with a key pair, and, through a process called a Certificate Signing Request, or CSR, <Click> we give the public key to the Certificate Authority. The Certificate Authority <Click> generates a certificate from a template specifically for server certs. Note that here the subject and issuer are different. The subject is the entity that will end up with the certificate and the issuer is the Certificate Authority. The Certificate Authority <Click> puts the servers public key in the cert. Then, as before, <Click> we hash the cert, and encrypt the hash, <Click> with the private key of the Certificate Authority, and, <Click> return the certificate to the server. With our Public Key Infrastructure in place, let s take a look at how it is typically used on the Internet. We should note that what you are about to see is not exactly how PKI is used for the Software Defined Perimeter because it will lack mutual authentication. However, a later video will fully explain that handshake in detail. OK, <Click> let s look at the PKI part of a simple TLS handshake. Before the handshake can begin, the client must have downloaded <Click> the root certificate of the Public Key Infrastructure. Note that browsers download hundreds of root certificates as part of the browser installation process, and, in a minute, we ll see how that is a significant problem for PKI, and we ll see how Vidder and the Software Defined Perimeter fix that problem. But, we re getting ahead of ourselves. The PKI part of the TLS handshake begins <Click> with the server sending the server s certificate to the client. Now, the client must validate the authenticity of the certificate, to do this, <Click> it takes a hash of the certificate using the same hash algorithm as the signer used (it knows how to do this because the method is written on the certificate). Then, <Click> it decrypts the original hash using asymmetric key encryption, and checks if the two hashes are equal. If so, then the client knows that it has a valid certificate. It also knows that the certificate has not expired because the expiration time is on the certificate. However, it doesn t know whether or not the certificate has been revoked. Therefore, <Click> it gets the serial number from the certificate, and <Click>
sends it to the OCSP responder. Assuming the certificate has not been revoked, <Click> the OCSP responder will mark it as Good, and put that reply <Click> in an OCSP response, along with the serial number, and <Click> will sign the response. Note that his is not an X.509 certificate. Rather this is an OCSP signed response as defined by RFC. The OCSP responder, then, <Click> returns the response to the client. The client <Click> hashes the content of the message, decrypts the original hash, and, assuming they are equal, determines that the certificate has not been revoked, and, that, therefore, it can be trusted. Well, we ve certainly talked a lot about X.509 certificates. Let s open one up and take a look at it. <Click> Here s the 1 st half, and <Click> here s the rest of it. This happens to be the certificate for an SDP Client, and <Click> here s the client s Universal ID, which will also be the subject of the certificate. But first, <Click> note that this certificate is not trusted by my computer. That s because the Software Defined Perimeter uses a dedicated PKI with pinned certificates, which solves a number of problems associated with PKI, as we ll see in a minute. <Click> Here s the subject with the common name of the Client s UID, <Click> and the issuer with the common name of the root of this Software Defined Perimeter. Next, <Click> the serial number, which we just saw is used for checking its revocation status, among other things. And, <Click> here is its public key. Recall that when you can decrypt something with this public key, then you can cryptographically prove that it was encrypted with the associated private key, and, assuming the private key has not been stolen, discovered, or compromise by an adversary, and that the infrastructure with access to that key was not compromised either, and the certificate is valid, has not expired, and has not been revoked, then, you can trust it is associated with the entity named in the subject, above. Another attribute of a certificate <Click> is what the private key can be used to encrypt. The RFC shown here lists the possibilities, but the important thing to note is that the private key associated with this certificate cannot be used to generate certificates. Finally, the issuer of this certificate <Click> would have hashed the entire certificate and encrypted that hash with its private key. Note that there are two pairs of keys being discussed here. The key pair associated with this certificate has the public key on this certificate and the private key is held by the SDP client. However, the private key that was used to sign this certificate is held by the issuing Certificate Authority. If this is not clear, please go back to the previous slides to see how trust is conferred from the Certificate Authority to the server. If you talk with enough people about PKI, someone is bound to say that PKI is Broken. Well, <Click> is PKI broken? Well, <Click> no the technology is sound. But <Click> is it broken in some other way. Well, yes, it is. Previously, we talked about how the installation of a browser downloads hundreds of trusted root certificates. Any compromise in the chain of certificates to the root means a compromised PKI. That s what happened to Google when Iranian hackers compromised DigiNotar s issuing CA and issued certificates to the hackers that cryptographically proved they represented Google. Similarly, there s an attack known as a root cert injection attack, resulting in the victim s computer trusting the attacker for all certificates presented to the victim. In addition, for servers on the Internet,
the subject s common name in the server s certificate, is a name, not an IP address. Therefore, DNS spoofing can enable man- in- the- middle attacks. Finally, the fact that the PKI infrastructure enables revocation checking, also opens up a denial of service attack by flooding the OCSP responder with lots of requests. If the OCSP responder cannot reply to legitimate requests, the DoS attack effectively shuts down the servers using that PKI infrastructure. Wow. But, <Click> does Vidder fix those problems? Well, yes, Vidder does fix those problems. It uses a dedicated PKI with pinned certificates which means the SDP client won t trust the hundreds of root Certificate Authorities out there it will only trust the dedicated PKI associated with this specific Software Defined Perimeter. That also means that injecting additional certs won t affect SDP because the root cert of the SDP is not stored with the other root certs. Rather it is encrypted and stored outside of the certificate store. In addition, the common name of the Controllers and gateways is an IP address, which mitigates spoofing attacks. Finally, the Software Defined Perimeter s OCSP responder uses OCSP stapling, where the OCSP response is pre- fetched by the controller and sent to the clients during the TLS handshake. Therefore, the OCSP responder is not open to the Internet, and, therefore, not DoS able. OK, there was a lot of material here. Let s summarize. <Click> The purpose of Public Key Infrastructure is to create and distribute X.509 digital certificates to trusted entities, and then to act as a trusted 3 rd party in that each of the entities trust the 3 rd party, therefore, each entity should trust each other. Basically, it enables cryptographic authentication over an untrusted network. A PKI implementation consists of a root certificate authority that has a certificate whose subject names and issuer names are the same. All other certificates were signed directly or indirectly by it. Everyone inherently trusts the root. Certificates can be cryptographically proven to be valid and not revoked. The signature on the cert makes it possible to prove that the cert has not been altered. Recall that the signature consists of a hash of the rest of the certificate and then the encrypting of that hash with the issuing certificate authority s private key. PKI creates a chain of trust all the way back to the root certificate. Every link in the chain must be validated, but there is no way to validate the root it is inherently trusted. You will hear that the public implementation of PKI is broken, but the technology is not broken and SDP s implementation fixes the pieces that are broken in the public implementation.