Lecture 5: Public Key Infrastructure

• Motivation for PKI

• PKI and its components

o Certificate, X.509, Certificate Authority

• Certificate types and Issuance

• Security Issues with PKI

• Certificate Revocation

• Certificate Transparency
0 Admin
Midterm Exam

• Date and time: 6th March 2025, Thursday, 10:15 AM to 11:15 AM

• Venue: MPSH 5 (venue changed since lecture 1), arrive by 10:00 AM

• Scope:
o Lecture 1 to 5
o Tutorial 1 to 5
o Assignment 1

• One A4 double-sided cheat sheet allowed, non-programmable calculator allowed.

• Seat allocation will be announced on Canvas.

Paper Format

• Pen and paper format, marking using Softmark

• MCQ questions
o15 - 20 questions
oChoose the most relevant/appropriate answers

• Short answer questions

o2 - 4 questions
oWrite within the space provided, no additional answer sheet will be provided
Consultation for Assignment 1
• 20th Feb 2024, Thursday (Today)
• Time: 1:30 PM – 3:30 PM
• Scope: Only Assignment 1
• Hybrid:
o Venue: COM3-02-61 - Meeting Rm 21 @ COM3 (capacity : 20)
o Link:
− https://nus-sg.zoom.us/j/87945549344?pwd=5lfKgu5SXYK9FfrE5Mv6oczoUVykm2.1
− Meeting ID: 879 4554 9344
Passcode: 408694
Midterm Survey
1 Overview
 Does the public key
Recall: Digital Signature actually belong to
VLC?
VLC public key: 0ea23cd002

VLC’s private key

VLC.exe download VLC'.exe

VLC.exe Sign verify
signature signature'

potentially being
Accept Reject
modified

Alice Verification

• If the user obtains a wrong public key from an attacker, the attacker could trick
the user to accept the wrong file.

Project Noun: Nurfajri Aldi

Attack Step
VLC public key = 2eeaff053
Mallory (i.e., Mallory public key)
Mallory' s private key

VLC'.exe download VLC'.exe

VLC'.exe Sign verify
signature signature'

Accept!!!

Alice Verification

• Distribution of public key: Need a secure way for user to obtain VLC’s public key.

Project Noun: Nurfajri Aldi

Key Distribution
• Need of a mechanism to securely distribute public keys
• An entity distribute/broadcast its public key once and doesn’t need to know the
receiver
• With the public key securely distributed, we can use it for encryption and signature
verification
• Methods:
1. Public Announcement or hard coded in verification programs
2. Publish in a publicly available directory
3. Public Key Infrastructure (PKI)
1. Key Distribution: Public Announcement /
Hardcoded
• The owner broadcasts her public key.
o For example, by sending it to friends via email, publishing in social media, blogs, web pages or
simply the physical name card.

• Hard coded:
o Some apps/software have the public key hardcoded in the programs. src

o For e.g., a game might have the developer’s public key hardcoded.
o The public key is to be used to verify data sent by the developer.
Public Announcement / Hardcoded: Limitations

• Not standardized
o Use different methods or formats for such announcements

• No systematic way to search/verify the public key

o Without additional verification mechanisms, there's no guarantee that the announced
key is genuine and not tampered with.

• Hard-coded keys are fixed within the software or hardware, making it

difficult to update keys.
2. Key Distribution: Publicly Available Directory

• Keys are stored in a directory accessible to the public, similar to a phone

directory
o If Bob wants to find the “public key” associated to a “name”, say [email protected]
o He can search the public directory by querying the directory server.
Public Directory [email protected] x1s34adf39
[email protected] asd3123411
[email protected] 2s3dasdf233
[email protected] a323fasdfas
......

Alice Bob

Project Noun:,Meko, Anwar Hossain

Publicly Available Directory: Issues

• Anyone can post their public keys in the server:

o Not clear how to verify the info.
o Suppose the server receives a request to post a public key, how does the server verify that the
information is authentic?
o For email, the server could verify by sending a confirmation email/OTP to the address.
o What about other types of name, such as web domain name?

• Not everyone trust the server.

We need a
o E.g., Certain entities might not trust mit.edu to host the server. distributed way to
broadcast the keys
• The server could be overwhelmed and can’t handle the load.
3. Public Key Infrastructure (PKI)

• PKI is a standardized system that distribute public keys to address limitation of

the previous methods.
• A main objective is to be deployable on a large scale.

• Types PKI:
o “Public PKI” refer to the PKI we adopted in Internet for domain name, emails address etc.
o “Private PKI” are systems for other applications, and it has its own set of “CA”.
− For e.g. it is possible for a company to set up a PKI for its own usage only.
2 PKI Components: Certificate and CA
PKI
• A framework that encompasses the software, policies, procedures, and standards
to required for secure key distribution

• Key features
o Key pair generation: public/private key pair
o Digital certificate: bind public key to identity; signed by trusted third party (TTP)
called Certificate Authority (CA)
o Certificate revocation: invalidating a certificate before its expiration
Digital Certificate
• Certificate binds an entity to some public key
• Correctness of this binding is asserted via a signature by a certificate authority
(CA)

• A CA is a trusted authority: Trusted Third Party (TTP)

• CA verifies and issues certificate to the entity requesting for it

• The CA also has its own public-private key
Digital Certificate
• Certificate Issuance:
o Alice’s key-pair (KA, KA-1), Charlie’s key-pair (KCA, KCA-1)
o certC→A: certificate for Alice’s key issued by Charlie
o Say Charlie knows that KA is Alice’s public key, then Charlie computes the following signature:
o If ‘Alice’ is not specific enough, use email address, URL, etc. certC→A = {Alice, KA}KCA-1

• Certificate Verification:
o Alice→ Bob: (KA, certC→A)
o Bob verifies certC→A
o If Bob knows Charlie’s key KCA and trusts Charlie (i.e., his word ‘Alice’s key is KA), then Bob
can believe that KA is indeed Alice’s key
 Digital Certificate Issuance
[email protected] asd3123411
2. Verifies depending on the [email protected] 2s3dasdf233
type of certificate request Certificate Authority [email protected] a323fasdfas
(KCA , K-1CA ) ......
[email protected] x1s34adf39

Directory Server (CA)

[email protected]
x1s34adf39 3. Issues the certificate signed by the CA,
certCA→A = {[email protected], x1s34adf39, 1 Sep 2025}KCA-1

Alice
• Minimally messages to be signed will
1. Alice request for a certificate from the CA have entity identify, public key, validity
for ([email protected], x1s34adf39 ) • CA can hash the message and then sign
Verification by Client
Mail, certCA→A
Alice Bob
Alice: This is an email from [email protected]
The email is “signed” using my private key.
This is my certificate. KCA
From: [email protected] certCA→A
Subject: Hello Bob name : [email protected]
Meeting 3pm at the “old” place public key: x1s34adf39 No need to contact
today. Valid until: 1 Sep 2025 the CA.
signature: xsdewsdesd signature of the CA

• Bob verifies that the signature in the certificate is indeed signed by the CA.
• No one except the CA can produce the valid signature.
• The authenticity of the certificate is as good as coming directly from the CA.
Why Digital Certificate?

• Consider the situation where Bob wants to obtain Alice’s public key.
• Bob can directly send a query to the CA.

• There are two limitations of querying the CA as-and-when needed:

o The CA became a bottleneck
o Bob needs to have online access to the CA at the point of verification

• Certificate is a “smart” work around to get the public key in an offline manner.
How about the CA's public key?

• The CA has its own public-private key.

• We first assume that at least some CA’s public keys have been securely
distributed via other means.
• Most OSes and browsers have a few pre-loaded CAs' public keys: they are
known as the “root” CAs.
• Not all CAs’ public keys are preloaded.
• Other CA’s public keys can be added through the chain-of-trust
Different PKI Models: Single CA
• Single CA : One CA responsible for issuing and managing certificate
o Everybody in the system trusts the single CA. E.g., organization, government
o KCA is installed in everyone’s machine over authenticated channel (e.g., USB stick, pre-installed)

• Advantages
o Easy to build and maintain
o Consistent approach to certificate issuance
o Users trust only a single CA

• Disadvantages
o Single point of failure
o Does not scale particularly well
Different PKI Models: Multiple CAs
• Commonly used in browser
• System has many trusted CAs in the form of a list, certificate issued by any of them is accepted
o E.g., Alice can obtain certCA1→A, certCA2→A, …

• How many CAs does your browser trust?

o macOS High Sierra: 100's root CAs are trusted (link1, link2)

• Advantages
o Redundancy
o Geographically distributed

• Disadvantages
o Complexity
CA Chain of Trust

• Multiple CAs are organized into a

hierarchy of trust
• Root CAs – trusted
• Intermediate CA – can be verified

• Hierarchy helps to delegate trust

and manage the issuance of
certificates in a scalable and
controlled manner
CA Hierarchy

Root CA Equifax CA KCA

Need to trust
“signs”

Intermediate CA GeoTrust: {T, KT}KCA-1 DigiTrust: {D, KD}KCA-1

Can be verified

Intermediate CA IBM: {I, KI}K -1 Google IA: {G, KG}KT-1

T

Domain/service Gmail: {M, KM}KG-1

Example: Certificate for DBS
Example: DBS Chain of Trust

Pre-installed,
Self-signed!
DBS Chain of Trust

The field “Basic Constraint” indicates whether the “name” can take the role of CA
X.509 Format

• Universally accepted standard for formatting public-key certificates: X.509

• The Public-Key Infrastructure (X.509) Working Group (PKIX):
o group focused on developing and maintaining standards related PKI using the X.509 standard

• Used in most network security applications, including IP security, secure sockets

layer (SSL), S/MIME, etc.

• X.509 version 3 (v3) is the most commonly used PKI standard.

X.509:
• Extensions to increase flexibility
• If Extensions marked as critical
cannot be processed by an
implementation, the certificate must
be rejected.
• Non-critical extensions may be
ignored.

Src: William Stalling

3 How to get a certificate?
Certificate Issuance: Self-Signed Certificate

• Self-generated, not CA signed, free

• Certificate is signed with organization’s own private key instead of by a CA

• How it works:
o Suppose a user wants to include a binding of name & public key of an entity, say D, but D doesn’t
have a certificate signed by CA.
o To handle this, D can “self-sign” a certificate and pass to the user.
o Next, the user manually accepts the certificate.

• By accepting the self-signed certificate, the user instructs the machine to accept the
binding takes the responsibility in ensuring that info in the certificate is correct.
Certificate Issuance: Self-Signed Certificate

• Advantage
o Fast and easy to issue
o Not dependent on others for certificate issuance

• Disadvantage
o Not via trusted CA, if compromised, security risk
o Not recommended for public-facing websites

• openssl - generate self-signed certificate

Certificate Issuance: Domain Validated (DV)
Certificate
• Entry-level SSL certificate; least stringent validation
• Only verification check: if applicant owns the domain (web site address)
associated with certificate
o No checks to ensure that domain owner is a valid business entity
• Advantages
oEasy and quick issuance
oCost-effective (around $25 - $100's )
• Disadvantages
o Only confirm ownership of domain; no identity validation
Certificate Issuance: Extended Validation (EV)
Certificate
• Much more stringent identity validation and takes time to issue
o Additional verification: organization details, registration number and jurisdiction, etc.

• Advantages
o Highest level of trust
o Rigours identify verification

• Disadvantages
o Cost ($300-$1700)
o Time-consuming
DV vs EV
4 Security Issues with PKI
Number of Trusted CAs
CA
• As of August 2020 [link]
o 147 root certificates, representing 52 organizations, are trusted in the Firefox web
browser
o 168 root certificates, representing 60 organizations, are trusted by macOS
o 255 root certificates, representing 101 organizations, are trusted by Windows
o Android currently contains over 100 CAs that are updated with each release.

• Issue?
CA Single Point of Failure

Security of the weakest link

o Security breach of a single CA → Compromise security of sites protected by any other CA!
o Any website can be impersonated using a rogue certificate issued by a rogue CA [link].

Trusted CAs
Equifax Gmail Equifax
BAD CA
…
Alice’s
browser BAD CA
Fake Gmail
Well-Know Incident

• Trustwave issued a “subordinate root certificate” to an organization for monitoring

the network.
o With this certificate, the organization is able to act as the man-in-the-middle of any SSL/TLS
connection.

• Timeline of Certificate Authority Failures

src src
Compelled Certificates

• Compelled certificate creation attack [link]

• Government agencies compel (via court order) a CA to issue false
certificates for website to be spoofed
• Can used by law enforcement or intelligence agencies to covertly intercept
and hijack individuals’ secure communications

• That is, govt becomes man-in-the-middle

MitM Device using Compelled Certificates

Trusted CAs
Verisign Compelled certificate by CA1 Authentic certificate
CA1
…
(1) Hello (2) Hello Equifax

(4) Key KD’, CertCA1(KD’) (3) Key KD, Certorig (KD)

(5) Establish keys (5) Establish keys
DBS
Bob (KD’ , K-1D’)
Fake DBS (KD , K-1D )
(KB , K-1B )
Government
Social Engineering: Typo Squatting

1. An attacker registered for a domain name (e.g., mus.edu.sg) and obtained a

valid certificate of the above name.
2. The attacker employed “phishing attack”, tricking the victim to click on the
above link, which was a spoofed site of: nus.edu.sg
3. The address bar of the victim’s browser correctly displayed https://mus.edu.sg
but the victim didn’t notice that and logged in using the victim’s password.
Social Engineering: Subdomain Takeover

• A more commonly deployed method uses sub domain

• E.g., Attacker is the rightful owner of 134566.com

• Attacker creates a sub domain: nus.edu.sg.134566.com

• Since attacker is the owner of 134566.com, it can get a valid certificate of
nus.edu.sg.134566.com or *.134566.com
• Users may be tricked into visiting these look-alike subdomains
5 Revocation: When Things go Wrong
Certificate Revocation

• Certificate revocation is a mechanism to invalidate certificates

o After a private key is disclosed

o Change of information in the certificate such as organization name or domain
o If the certificate holder is no longer trusted (e.g., an employee leaves an organization)
o If a CA is compromised, revoke affected certificates
o Certificate expiration time is usually chosen too long (updating certificates is a lot of work)
Approaches for Revocation

1. Certificate revocation list

o Complete CRL (full posting)
o Delta CRL

2. Short-lived certificate, no need to revoke

3. On-line certificate verification

o e.g., Online Certificate Status Protocol (OCSP)
1. Certificate Revocation List X.509

• CA periodically publishes Certificate Revocation List

(CRL)
o contains a complete list of all the unexpired, revoked certificates
o Disadvantage: large size, high overhead.

• Delta CRLs only contain changes from the last complete

CRL
o Short
o Issuing delta CRL periodically removes need to issue full CRL

Src: William Stalling

2. Short-Lived Certificates

• Certificates have short validity lifetime (e.g., few days)

o Servers update certificates from CAs daily
o If unable to update → previous certificate is still valid for next few days

• Advantage
o Risk associated with a compromised certificate is minimized

• Disadvantage
o Too much overhead to CAs and domain owners
3. OCSP Extension
• Online Certificate Status Protocol (OCSP): Client query to get revocation status
1. Client connect to site
2. Server sends certificate to client

Alice’s
browser Gmail Equifax
4. Return good, revoked or
valid
3. Client send OCSP
request to OCSP responder
to check status

CA
Certificate Revocation Server

From Project Noun Alzam

3. OCSP Extension
• Advantages
o Timely information regarding the revocation status
o Reduced latency since OCSP responses is smaller in size than CRLs

• Disadvantages
o Traffic overhead to CAs for querying
o Privacy: CA learns user’s activity

• Better method?
3. OCSP Stapling
2. Client connect to site
3. Server sends certificate + OCSP to client

Alice’s OCSP
browser Gmail Equifax response

1. Periodically refreshed

CA
Certificate Revocation
Server

From Project Noun Alzam

6 Certificate Transparency
Issues with PKI

• Forged Certificates: CA might incorrectly issue forged certificates

• Delayed Detection: rogue CA could issue fraudulent certificates cannot be

immediately detected

• Reporting Breaches: Many CA won't report a breach because of losing

trust and credibility
Certificate Transparency (2013- by Google)

• Can’t we just make certificates transparent?

o If all (either authorized or unauthorized) certificates are visible to everyone, misbehavior would
be also visible

• Certificate log (CL): Public, verifiable, and append-only log of certificates

• Browsers reject if certificate is NOT in one of the CLs

o Client decline to connect to sites whose certificates have not been logged
o Trust the certificate only if logged

• Server can monitor the log for mis-issued certificate.

How it works?

(5) Hello (1) Request cert

Browser Domain
D CA
(6) certC→D , proof of (4) certC→D , proof
inclusion of inclusion

(3) proof of inclusion (2) certC→D

Certificate
Log
How to build a public, verifiable, and append-only
log?
• One obvious approach
o One global log maintained as a lists
o Each client continuously downloads the entire log and verify

• Any problem with this approach?

o Huge waste of bandwidth and storage

• Better approach:
o Merkle Tree
A better Approach: Merkle tree

• Leaves -> are the hashes of individual certificates

that have been appended to the log.
= TH
• Nodes -> are the hashes of paired child leaves or
paired child nodes.
• Tree head (TH) or root of the tree is a summary of all
the certificates
• Distribute signed tree head (STH): {TH}Klog-1
• STH is public src
Verification with Merkle tree

• To show that a particular certificate is in the log,

o need the hash of that leaf
o a list of neighbouring hashes working up the tree

• Proof of inclusion
o E.g., to verify d3, server shares node hashes of c,i,n with
the client

• Client can recalculate the root by working up the tree

• Compare it with public STH

src
Availability vs. Consistency

• Log must be highly available

o Multiple log instances in distributed geographical regions

• How to make these logs consistent?

o Logs reach a consensus among them

• What about latency (e.g., time to register a new certificate and get the proof of
inclusion)?
CT’s Design choice: SCT and MMD

• When CA wishes to register a certificate to CT:

o CA sends the certificate to the log server

o Log server immediately issues a signed certificate timestamp (SCT) as a promise

that it will insert this certificate to its Merkle tree
− With a promise that the actual insertion will take place within a maximum merge
delay (MMD) (e.g., 24 hours)

o CA can use the certificate + SCT from that moment

CT’s Design choice: SCT and MMD

(5) Hello (1) Request cert

Browser Domain
D CA
(6) certC→D , SCT (4) certC→D , SCT

(3) SCT (2) certC→D

CL issues Signed Certificate Timestamp (SCT);

Certificate
e.g., “OK, I will add your cert in the log in next 24 hr” Log

• SCT list can be embedded directly within the X.509 certificate itself as an extension.
A Good Ecosystem

• Any interested parties (e.g., CAs, domain owners, clients) can monitor logs to
ensure:
o CAs do not register improper certificates
o Logs do not misbehave; for example,
− violating append-only property
− presenting different logs to different clients

• Community effort needed

o Monitors: continuously observe CT logs for any suspicious or unauthorized certificates
o Auditors: verify the integrity and correctness of CT logs.
Summary

• PKC requires a “secure broadcast channel” to distribute the public keys: PKI.
• PKI: infrastructure to broadcast the key. Comprise of
o Certificate issued by Certificate Authority (CA)
o CA issues, verifies, and revokes certificates

• CA chain-of-trust
o A root CA can certificate other CA. Root CA’s public keys are pre-installed or “manually”
installed.

• Certificate transparency complements PKI