代写代考 COMP30023 – Computer Systems

COMP30023 – Computer Systems
2022– Semester 1 – Week 5 – Lecture 1

Certificates, Public Key Infrastructure,

• Week 6 Thursday: during lecture time
• Length: 40 mins
• 10% of the total mark
• Canvas quiz
– 10 multiple choice questions
– 5 short answer questions

• More details/instructions on LMS

Mid-Semester Test (MST)

– Message authentication code
– Authenticated encryption
– Diffie Exchange
– Public Key Infrastructure (Certificates)

What does the lock mean?

Confidentiality – Authentication – Integrity

Objective is to provide secure private communication between
two end-points, with integrity checks to ensure data does not
change in transit, and authentication to establish identities of
one or both of the end-points.

Recap: Secure Communication

Goal: Secure Communication

2 problems:
– How does Alice know ciphertext has not been modified?
– How does Alice know PKB is Bob’s public key?

: symmetric encryption
secret key

(PKB, SKB)

Enc(PKB, S)

: symmetric encryption
secret key

(PKB, SKB)

Enc(PKE, S)

Human-in-the-middle Attack
aka Man-in-the-Middle (MITM) attack

: network traffic between Alice and Bob goes via Eve who:
– Trick Alice into thinking it is communicating with Bob and vice
versa by modifying the messages (impersonation)
– Silently snoops on the messages sent between Alice and Bob
(eavesdropping)

• Is DH secure against impersonation attack?
• Is DH secure against eavesdropping attack?

Diffie- Exchange and

g,p publicly known

• Securely associate identities with cryptographic public keys
– Name, domain, organisation, etc.
– e.g., for SSL/TLS and HTTPS for authenticated and encrypted web

browsing, code signing, client authentications

• The certificate itself is signed (Certificate Signature) – often
by a third party

Purpose of certificates

Certificate Example

• certificate = (PKAlice, Alice, …)
• Signing: s = Sign (SKIssuer, certificate), certificate also contains

other details such as issuer, algorithms, validity date
• Certificate: Issuer, Signature s, certificate = (Issuer, PKAlice,

• Verification: Verify (PKIssuer, s, certificate)

X.509 the most common standard format

Consists of: Version Number, Serial Number, Signature
Algorithm ID, Issuer Name, Validity Period (not before and not
after), Subject name, Subject Public Key Info (Public Key
Algorithm and Subject Public Key) , Issuer Unique Identifier
(optional) Subject Unique Identifier (optional), Extensions
(optional), Certificate Signing Algorithm, Certificate Signature,
subject alternative names

Certificate format

• The signer is vouching for the identity behind the
public/private key pair

• Certificates can be chained: A signs B’s Certificate, B signs
C’s certificate and C runs a website or issues digital
signatures

• Trust flows down the hierarchy, if you trust A, then you trust
all certificates A signs, and in turn, all certificates signed
with certificates signed by A, i.e. trusting A implies trusting C

• Limiting purpose is critical (BasicConstraints – id-ce 19)

Certificate Hierarchies

• PKA, SKA, PKB, SKB, verification/signing keys of a digital

• A signs B’s certificate, B signs C’s certificate
– A: sB = Sign (SKA, certificateB), certificateB contains PKB
– B: sC = Sign (SKB, certificateC), certificateC contains Charlie’s domain

address www.foobar

• Alice wants to verify www.foobar is Charlie’s using certificateC :
– Verify(PKB, sC , certificateC)
– Verify(PKA, sB , certificateB)

Chained Signing & Verification:

• Trust anchors are entities that are explicitly trusted
– Most commonly found as root certificates

• They are the points from which all other trust is derived
• Certificate Authorities (CA) are the most common trust anchors

– Sign certificates for others
– Root certificates are shipped, pre-loaded, with your Operating

System/Browser
– Root certificate is self-signed
– Sub-CA – intermediate CA that is not a root, but has been signed by a

– Cross-signing – Sub-CA signed by multiple root CAs

(compatibility/robustness)

Trust anchors and certificate
authorities

Certificate Hierarchy (Image)

Browsers and Certificate Validation

Self-signed certificate
Keep own secret key safe

• Machine will contain 50+ root certificates
– issued by governments, companies

• Should we really trust all those organisations?

Trusting root certificates

• Domain Validation (DV)
– Most common
– Ties a certificate to a domain and checks the requester has some

control over the domain
– Validation via email/DNS/URL – possible weakness

• Organisation Validation (OV)
– Ties a certificate to a domain and a legal entity (e.g., an operating

• Extended Validation (EV)

– Establishes legal entity, jurisdiction, and presence of authorised
officer (e.g., physical address, phone #)

– Offline process + expensive

Certificate Issuance

Domain Validation Example

https://letsencrypt.org/how-it-works/

Domain Validation Example

https://letsencrypt.org/how-it-works/

Domain Validation Example

https://letsencrypt.org/how-it-works/

Domain Validation Example

https://letsencrypt.org/how-it-works/

: why verify ownership of PK AND domain address?

• DV certificates do not establish a link between the domain
and a real world entity
– LetsEncrypt has issued 14,000 Certificates containing the word

– WoSign incorrectly issued certificates for github2

• Even EV certificates are not immune
– Symmantec issued an EV certificate for Google.com3

Certificate Issuance – problems

1 https://www.thesslstore.com/blog/lets-encrypt-phishing/
2 https://www.schrauger.com/the-story-of-how-wosign-gave-me-an-ssl-certificate-for-github-com
3 http://www.pcworld.com/article/2999146/encryption/google-threatens-action-against-symantec-issued-certificates-following-botched-investigation.html

• Revocation occurs when a certificate is:
– Mistakenly issued (Let’s Encrypt, February 2020)
– Private key is compromised

• Performed via Certificate Revocation Lists and OCSP (Online
Certificate Status Protocol)

• When root certificates are revoked all certificates below
that become untrusted
– Example: DigiNotar, CNNIC, WoSign
– Hence cross-signing root certificates

• Only useful if aware of incorrectly issued certificate

Certificate Revocation

• Revocation occurs when a certificate is:
– Mistakenly issued (Let’s Encrypt, February 2020)
– Private key is compromised

• Performed via Certificate Revocation Lists and OCSP (Online
Certificate Status Protocol)

• When root certificates are revoked all certificates below
that become untrusted
– Example: DigiNotar, CNNIC, WoSign
– Hence cross-signing root certificates

• Only useful if aware of incorrectly issued certificate

Certificate Revocation

https://arstechnica.com/information-technology/2020/03/lets-encrypt-revoking-https-certs-due-to-certificate-
authority-bug/

• Revocation occurs when a certificate is:
– Mistakenly issued (Let’s Encrypt, February 2020)
– Private key is compromised

• Performed via Certificate Revocation Lists and OCSP (Online
Certificate Status Protocol) [CRLite, Mozilla]
– Performance vs privacy

• When root certificates are revoked all certificates below
that become untrusted
– Example: DigiNotar, CNNIC, WoSign
– Hence cross-signing root certificates

• Only useful if aware of incorrectly issued certificate

Certificate Revocation

• Open framework for monitoring and auditing certificates
• Intended to provide a way of monitoring certificates that

have been issued
– misissued certificates
– maliciously acquired certificates
– rogue CAs

Certificate Transparency

• Uses a cryptographic append-only log to record the issuance of
certificates
– : consistency and membership verification

• Server should send SCT (signed certificate timestamp)
– SCT is issued by CT log to prove inclusion

• Browser may choose to decline certificates not on CT log
• SCT is an extension in X.509

Certificate Transparency (CT)

https://www.certificate-transparency.org/what-is-ct

As of Mar 24, 2022, there have been
17,910,600,871 entries made to the set of
Certificate Transparency logs that Google

Certificates and CAs examples

Certificates and CAs examples
https://support.apple.com/en-au/HT212140

Subject alternative names

– Public Key Infrastructure
– Certificate authorities
– Certificates

Protocol for secure communication over Internet
Transport Layer Security protocol

• Supported by all popular web browsers , web servers,
internet commerce sites

• HTTPS: implementation of TLS over HTTP

• This objective has been explored since the early days of
networks, with proposals as early as 1993

• It is a good case study on why security is difficult, how
things can go wrong, and how fixing those problems can be
challenging

• Even with the best of intentions and extremely smart
people, flaws in security persist

Secure Communication

• SSL (Secure Socket Layer)
– Secure TCP connection
– Designed by Netscape in 1994
– Version 1.0 was never released because of security flaws
– Version 2.0 was the first to be made public

• It too had security flaws
– Version 3.0 (1996) – complete redesign, the basis on which TLS was

History of the SSL/TLS Protocol

• TLS 1.0 (1999) – upgrade to SSL 3.0, with further improvements
to security

• TLS 1.1 (2006) – further upgrades and defences against known

• TLS 1.2 (2008) – updated primitives (moves from MD5-SHA1 to
SHA-256 for pseudorandom number generation)
– Added support for AES and various advanced modes of AES
– 2011 further update to prevent downgrade attacks

• Where a server can be tricked into downgrading to weaker SSL 2.0
• TLS 1.3 – significant differences, not backwards compatible,

removing weaker crypto primitives, enforcing forward secrecy
– 11 years and nearly 30 IETF drafts
– dropped support for less/in secure cryptographic features (MD5)
– performance (number of roundtrips 0 or 1)

TLS – Transport Layer Security

• Handshake protocol:
– Uses public-key cryptography to establish several shared secret keys

between the client and the server
– An initial negotiation between client and server that establishes the

parameters of their subsequent interactions within TLS

• Record protocol:
– Uses the secret keys established in the handshake protocol to

protect confidentiality, integrity, and authenticity of data exchange
between the client and the server

TLS Basics

https://www.bbc.com/news/health-51711227

Runs between a client and a server
For example, client = Web browser, server = website

Negotiate version of the protocol and the set of cryptographic
algorithms to be used:

– Interoperability between different implementations
Authenticate server and client (optional)

– Use digital certificates to learn each other’s public keys
and verify each other’s identity

– Often only the server is authenticated
Use public keys to establish a shared secret

Handshake Protocol

ClientHello

Client (in plaintext):

• Protocol version

• Cryptographic algorithms

• random nonce

ServerHello

Server (in plaintext) :
• Highest protocol version supported by both
the client and the server
• Strongest cryptographic suite selected from
those offered by the client

ServerKeyExchange

Server (in plaintext) :
• Highest protocol version supported by both
the client and the server
• Strongest cryptographic suite selected from
those offered by the client

Server sends its public-key certificate
containing either its public key, or its Diffie-
Hellman public key gy (depending on chosen
crypto suite)Validate the certificate

ClientKeyExchange

The client generates secret key material and
sends it to the server encrypted with the
server’s public key or gxy if DH

[over a reliable network connection]
• Client sends ClientHello to server asking for secure connection,

listing its supported cipher suites
• Server responds with ServerHello and selects one of the cipher

suites presented that it supports, also includes its certificate, and
can request the client send its certificate (mutual authentication)

• Client confirms validity of certificate
• Client generates session key

– Either directly by picking a random key and encrypting it with the public
key of the server, or

– By running the Diffie- Exchange protocol that provides
better security

• Handshake concludes and both parties share a key that is then
used for encrypting/decrypting messages

TLS Handshake

• Certificates and Certificate Authorities provide authentication
• TLS provides private communication with integrity guarantees
• It’s on this basis that the public are told to check for the padlock

to know their communication is secure and protected between
their web browser and the server, and is with the genuine server

Beyond TLS

• Secure communication is complex
• Relies on several cryptographic protocols
• TLS (see LMS for links on attacks against TLS)
• Next lectue

• The slides were prepared by based on
some material developed previously by

• Reference: KR 8.3, 8.6

Acknowledgement

程序代写 CS代考加微信: powcoder QQ: 1823890830 Email: powcoder@163.com

Related Posts