Adonis Fung and I worked on a project where we defined and built PKI (Public Key Infrastructure) for our local development and deployed environments. I gave a talk to our engineers on how PKI works, covering encryption, signing, trust stores, and how the HTTPS handshake works.

1. Introduction to Public Key
Infrastructure
Theo Gravity
Viv Labs
Reviewed and Edited by
Adonis Fung, Viv Labs
Feb, 2019

2. Why talk about
PKI?
● It is used everywhere in your daily life (you
just don't know it!)
● Your browser makes use of it to provide
security for your web traffic
● Your OS uses it to provide a layer of security
for user credentials / access, app
installations, etc
● Banks use it to encrypt your data
● We use it at Viv to secure our networks and
user data

3. PKI Topics
Very high level on how the following works, does not go into mathematics / algorithms:
● Part 1: PKI Concepts
○ Background: Symmetric Cryptography / Shared Key Cryptography
○ Asymmetric Cryptography / Public Key Cryptography
○ Certificates & Certificate Authorities
○ Trusting Certificates
● Part 2: Encrypted HTTP
○ How Server-Side TLS works (eg HTTPS)
○ How Mutual TLS Authentication works (ie server and client-side TLS)

4. Part 1: PKI Concepts

5. What is PKI?
Public Key Infrastructure
(PKI) describes the
procedures and
hardware/software
infrastructure on how to store,
issue, revoke certificates and
manage public keys.
Image Source: Tech Guru, "Implementing public key infrastructure"
https://www.youtube.com/watch?v=QnhbZz7kLkQ

6. Asymmetric Key
Cryptography (aka Public
Key Cryptography) Basics

7. Background: Symmetric Cryptography
● In Symmetric Cryptography, (aka Secret Key /
Shared Key Cryptography) involves a single
key to encrypt and decrypt data
● This operation is much faster than
asymmetric cryptography
● Problems with using a symmetric key involve
○ Sharing key in a secure out-of-band channel
○ Key management and distribution among each
communicating party (it’s unscalable for a
HTTPS website to bootstrap and maintain a
key individual to each guest/customer)
Source:
http://www.informit.com/articles/article.aspx?p=102212 Image Source:
https://www.c-sharpcorner.com/article/implement-symmetric-and-
asymmetric-cryptography-algorithms-with-c-sharp/

8. Asymmetric Cryptography: Two keys
In Asymmetric Cryptography, a pair
of digital keys are used to encrypt
and/or sign data.
The keys are linked by a
mathematical formula.
● Private key
○ Kept private to oneself
● Public key
○ Can be shared with anyone Source: https://courses.cs.ut.ee/2015/infsec/fall/Main/PKC-PKI

9. Asymmetric Cryptography: Encryption
Encrypt sensitive data to hide it
in transit.
In Asymmetric Key Encryption
(aka Public Key Encryption), a
different key is used to encrypt
and decrypt data.
● The public key is used to encrypt
data
● The private key is used to
decrypt it
Source: https://docs.microsoft.com/en-us/previous-versions/msp-
n-p/ff647097(v=pandp.10)

10. Asymmetric Cryptography: Signing
Used to verify the integrity of the data
and/or sender. Data is sent in its
original form, but comes with a
signature attached to it.
● Input data is hashed, hash is
encrypted with private key ( =
the signature)
● Sender gets original data +
signature, decrypts signature
with public key, and compares
signature hash with data hash
● Valid if hashes match
● tl;dr: generate hash, private key
encrypts hash = signature
Source: https://medium.com/@xragrawal/digital-signature-from-blockchain-context-
cedcd563eee5

11. Just to reiterate….
● You cannot use the same key to do the
inverse operation in asymmetric encryption.
The opposing key must be used to do the
operation.
● This means you cannot:
○ Encrypt data with public key, decrypt same
data with public key
○ Encrypt data with private key, decrypt with
same private key
○ Same situation with decrypting
● Summary:
○ Encryption with private key, must use public
key to do opposite
○ Encryption with public key must use private
key to do opposite
○ hash of data + encryption w/ private key =
signature
Public keyPublic key
Can't do this with same key in
asymmetric encryption

12. Certificates and
Authorities

13. What is a digital certificate?
● Contains identifiers that identify an
entity and ties ownership to a public
key
● These identifiers are called subjects
○ An example of a subject would
be the Common Name (eg,
viv.ai) in a certificate used for
HTTPS
● Contains the public key of the entity
(the entity itself is assumed to have
the private key)
● Is issued by an entity
● Can be used for encryption and
verifying signatures (since it has the
public key)
Image Source:
https://smallstep.com/blog/everything-pki.html

14. Think of a certificate as an ID card
Image Source:
https://smallstep.com/blog/everything-pki.html

15. How do I know the server I talk to is the real server?
The Client wants to share data with the Server but
the Client needs to know the Server is who it says it
is during key exchange.
A Man-in-the-Middle (MitM) can present its own
public key to the Client along with a forged
certificate, pretending to be the Server.
How do we ensure the Server is the Server?
We use Certificate Authorities and PKI to verify
identity.
Image Source:
https://blog.netwrix.com/2018/05/15/top-10-most-common-types-
of-cyber-attacks/
(Man-in-the-Middle)
(Man-in-the-Middle)

16. Certificate
Authorities
● Certificate Authorities (aka, CA), is an entity that
issues and revokes certificates using its digital
signature (via private key signing of the issued
certificate)
● A CA can create a set of CAs that are authorized
to issue certificates on behalf of it
● CAs have their own certificates that identify
them
The example to the left defines a certificate chain:
● GlobalSign is the top CA entity, or root CA
● It has authorized the "Google Internet Authority
G3" (GIA) entity to issue certificates on behalf of
GlobalSign
● GIA issued the certificate with the subject of
*.google.com
● The browser trusts the *.google.com end-user /
leaf certificate because it trusts the GlobalSign
CA (and therefore can trust the GIA), i.e., chain of
trust

17. What is really inside of a certificate?
● Public Key: Contains the public key of the key pair that is
associated with the certificate.
● Subject: Provides the name of the computer, user, network
device, or service that the CA issues the certificate to.
● Serial Number: Provides a unique identifier for each
certificate that a CA issues.
● Issuer: Provides a distinguished name for the CA that issued
the certificate.
● Valid From: Provides the date and time when the certificate
becomes valid.
● Valid To: Provides the date and time when the certificate is
no longer considered valid. The date when an application or
service evaluates the certificate must fall between the Valid
From and Valid To fields of the certificate for the certificate to
be considered valid.
● Signature Algorithm: The algorithm used to sign the
certificate.
● Signature Value: Bit string containing the digital signature.
Image and text from:
https://sites.google.com/site/ddmwsst/digital-certificates

18. Inside a certificate (cont)

19. Certificate Authority
Hierarchies
In a prior example, you saw an example of a multi-
tiered CA setup, where there was a root CA
(GlobalSign) and an intermediate (aka subordinate)
CA (GIA).
An organization can have a single-to-multiple tiered
setup.
In the example to the left, a three-tiered CA setup is
used:
● A root CA has designated CAs for each
region (think of a DMV for each state)
● Each intermediate (region) CA has a CA for
each department
● Those departmental CAs can issue end-user
certificates that would identify entities under
their department
Image Source:
https://docs.oracle.com/cd/E19424-01/820-4811/gdzen/index.html

20. Revoking
Certificates
A CA has the ability to revoke certificates.
● A CA can revoke any intermediate CA's
certificate under it
● It can also revoke end-entity certificates
The revocation lists are stored in databases, which
a client would access to know if a certificate has
been revoked.
In the example to the left:
● GlobalSign revoked the certificate of the
AlphaSSL intermediate CA
● In revoking the AlphaSSL CA, all certificates
issued by AlphaSSL are now invalid
Example: California DMV Real IDs are considered
invalid for travel past a certain date - Federal
Government will revoke trust on the "DMV Real ID
CA" (hypothetical) soon, so all Real IDs issued by it
will be invalid
Image Source:
https://apple.stackexchange.com/questions/257801/alphassl-
intermediate-ca-certificate-revoked

21. Certificate Signing
Requests
Certificates are issued using Certificate Signing
Requests (aka CSR).
An entity generates:
● The public/private keys
● A CSR with Subject Identifiers (eg Common
Name = viv.ai) - things that would identify an
entity
● Attaches the public key to it
● Signs the certificate with the private key
The entity submits it to the CA. The CA:
● Checks the signature with the attached
public key in the CSR (it may do more
validation checks than just signature)
● Creates the certificate using the CSR details
● It adds information about itself as the issuer,
along with other details like validity, serial #
● Signs the certificate with the CA private key
Image Source:
http://help.bizagi.com/bpm-
suite/en/index.html?cloud_auth_certificates.htm

22. CA and Certificate
Summary
Certificate Authorities:
● Issue and revoke certificates
● Has their own certificates and key pairs used
to sign other certificates
● Can authorize other CAs to issue certificates
on behalf of itself
Certificates:
● Identify an entity via Subject Identifiers
● Contains the public key of the entity
● Is signed by the private key of the entity
● Is issued and signed by a CA
Certificate Chain:
● Is the end-user certificate and set of CA
certificates for tracing the chain of trust back
to the root
Image Source:
https://www.slashroot.in/how-does-ssltls-chain-certificates-
and-its-validation-work

23. Trusting and Verifying
Certificates

24. Establishing Trust
Through Trust
Stores
The CAs we trust are stored in a trust store /
certificate store / CA store, which is a database of
trusted certificates.
Examples of trust stores:
● Your OS has its own trust store (MacOS:
Keychain > .. > Certificates)
● Firefox has its own trust store (maintained by
Mozilla)
● Node.js uses Mozilla's trust database to
build its own trust store into the executable
List of global trust stores:
https://fpki.idmanagement.gov/truststores/
Image Source:
https://markusholtermann.eu/2016/07/ssl-all-the-things/

25. Trust stores can set
policy for
certificate usage
Trust stores can also specify that a certificate can
only be used to validate certain things.
In the example to the left, certificates issued by this
self-generated CA can be used for… everything.
Generally, you don't want to be too permissive for
security reasons.
This where many companies may use a
hierarchical CA setup, with intermediate CAs that
issues certs to be trusted for certain things only.
Image Source:
http://www.webtrust.org/principles-and-criteria/docs/item83987.pdf

26. Certificate (Identity) Verification Procedure
When the client is presented with a certificate chain
from the server
At end-entity cert,
● Check the Subject Name matches an identifier
(eg Common / Subject Alt Name matches
domain name)
Repeat up the chain of certificates, check:
● not on a revocation list
● certificate signature is valid against the
certificate public key
● falls within the dates of validity
● issuing CA's public key against the issuer
signature
● issuing CA is in the trust store
Sources:
https://www.ibm.com/support/knowledgecenter/en/SSB23S_1.1.0.15/gtps7/
s7vctch.html

27. Trust Store
Summary
● CA Certificates are stored in trust stores
● While an OS has a trust store, applications
may maintain their own (or alter) and use
that instead of the OS'
● Trust stores can set policies on how a
certificate can be used
● An application follows many verification
steps to verify the entity that is presenting
the certificate
● One of the verification steps of the trust
chain requires that one of the issuing CA
certificates is registered in the trust store

28. Part 2: Encrypted HTTP

29. Why you may be using
the words "TLS",
"SSL", and "HTTPS"
incorrectly
● SSL - Secure Sockets Layer, is a security
protocol that describes how to communicate
between a client and server in an encrypted
fashion
○ SSL 3.0 was the last version, deprecated
in 2005
● TLS - Transport Layer Security is the
successor to SSL
○ 1.0 defined in Jan 1999
○ Current version is 1.3, Aug 2018
● HTTPS - HyperText Transfer Protocol
Secure is HTTP over TLS/SSL
TLS + HTTP = HTTPS
When we refer to "HTTPS/SSL/TLS Certificate", we
generally refer to the certificate used in TLS
communication over HTTP.
Sources:
https://en.wikipedia.org/wiki/Transport_Layer_Security
https://blogs.msdn.microsoft.com/kaushal/2013/08/02/ssl-handshake-
and-https-bindings-on-iis/
https://chrisshort.net/drawings/osi-model/

30. Server-Side TLS Basics
Source:
https://stackoverflow.com/questions/6241991/how-exactly-https-ssl-works
● Browser requests https://www.google.com
● The www.google.com server responds with its SSL certificate (which contains the public key)
● It performs the Certificate Verification Procedure to verify the validity of the certificate and the
and that the server actually represents www.google.com

31. Server-Side TLS Basics (Cont)
Source:
https://stackoverflow.com/questions/6241991/how-exactly-https-ssl-works
● On successful validation of the certificate by the browser, the browser
○ Generates a symmetric session key (a key that is both shared by the server and client)
○ Uses the server certificate public key to encrypt the session key (and additional data), and
sends it to the server
● After this (TLS) handshake, all traffic is encrypted using the session key (both browser and server
uses it)

32. Server-Side TLS
Summary
● One key pair (from the server) is used for the
handshake
● To establish an encrypted connection, keys are
exchanged between the Server and Client
(Browser)
● The Server sends the Client its certificate
● The Client verifies the certificate and creates a
Session Key, and shares it with the server
● After TLS handshake, all data encrypted with
the Session Key
The Session Key is encrypted with the public key so it
cannot be intercepted in-transit to the Server.
This key exchange allows both the Server and Client to
be able to communicate with each other in an
encrypted and secure fashion.

33. Mutual TLS
Authentication
Mutual TLS involves the server asking the client to
present a valid certificate to it in order to proceed.
It has similarities to Server-Side TLS, but with some
differences:
● The server has a dedicated trust store
specific for verifying the client certificate
chain
○ This means the client certificate's issuer CA
must have presence in the server trust store
as part of the validation process
● During the initial handshake (described in
Server-Side TLS Basics), the server will tell
the client the list of Subject Names it has in
its trust store, which the client can use to
determine the certificate to offer to the
server
After both the server and client validates the
respective certificates, normal procedure of
generating and sharing the Session Key follows.
Source:
https://comodosslstore.com/blog/what-is-ssl-tls-client-authentication-
how-does-it-work.html
New Steps

34. References
● Asymmetric Cryptography
○ http://www.informit.com/articles/article.aspx?p=102212
● Everything you should know about certificates and PKI but are too afraid to ask by Mike Malone (must read!)
○ https://smallstep.com/blog/everything-pki.html
● Basics of Digital Certificates and Certificate Authority
○ https://sites.google.com/site/ddmwsst/digital-certificates
● Certificate signing request
○ https://en.wikipedia.org/wiki/Certificate_signing_request
● Certificate chain verification
○ https://www.ibm.com/support/knowledgecenter/en/SSB23S_1.1.0.15/gtps7/s7vctch.html
● How exactly HTTPS (ssl) works - response by JerryGoyal
○ https://stackoverflow.com/questions/6241991/how-exactly-https-ssl-works
● What is SSL/TLS Client Authentication? How does it work?
○ https://comodosslstore.com/blog/what-is-ssl-tls-client-authentication-how-does-it-work.html
● Adonis Fung, Ph.D, Information Engineering
○ https://ierg4210.github.io/web/lectures/10-lecture-TransportLayerAndBrowserSecurity.pdf
○ In-person editing / review of the slides and advice

35. References Cont.
● Digital Signature from Blockchain context
○ https://medium.com/@xragrawal/digital-signature-from-blockchain-context-cedcd563eee5
● Transport Layer Security
○ https://en.wikipedia.org/wiki/Transport_Layer_Security
● SSL Handshake and Bindings on IIS
○ https://blogs.msdn.microsoft.com/kaushal/2013/08/02/ssl-handshake-and-https-bindings-on-iis/
● OSI Model
○ https://chrisshort.net/drawings/osi-model/
● Client Authentication During SSL Handshake
○ https://docs.oracle.com/cd/E19424-01/820-4811/aakhe/index.html