An Overview of Cryptography

(Part III)
 Public Key Certificate
• Also known as Digital Certificate
• An electronic file that confirms the identity of the server
(the certificate subscriber/holder)
• Provide a way of authentication: to prove who they claim
to be
– For example, when we visit a bank’s web site, we can check the
digital certificate provided by the server to see if it is a legitimate
web site or a forged web site (owned by the hacker instead)
• Contain the certificate holder’s public key, which can be
used by the client for further actions, such as digital
signature and key exchange
• Prove the ownership of the public key

2
• A digital certificate is issued by a Certification Authority
(CA)
– Example: DigiCert, Comodo, Go Daddy Group, GlobalSign,
VeriSign, Hongkong Post
• A CA acts as a trusted third party to verify the identity of
certificate subscriber
• A server can also create a certificate by itself (a self-signed
certificate), but this will probably cause the client’s
browser to display a warning message since the browser
does not know whether this certificate can be trusted
– A self-signed certificate is less trusted than a certificate issued by a
trusted CA

3
 X.509 Authentication Service
• X.509 is a standard defining the format of public-key
certificate associated with each user.
• The X.509 certificate format is widely used, such as in
SSL/TLS, S/MIME, IP Security, and SET.
• These user certificates are assumed to be created by some
trusted CAs and placed in the directory by the CA or by
the user.

4
 5
Image source: Stallings, Cryptography and Network Security: Principles and Practice (6 Edition)
th
• Suppose a client trusts a CA
• The client obtains the certificate of this CA, say cert CA
– Browsers (or OSs) pre-install the certificates of the CAs they trust
– The user can also manually download the certificates of the CAs
from the CAs’ websites
• certCA contains the public key of CA
– This public key will be used for verification
• Further suppose the client visits a server, say S, with the
certificate issued and signed by CA, say certS
• The client obtains certS from S
• The client verifies certS by the public key of CA and know
that certS is indeed issued and signed by CA
• From certS, the client can obtain the public key of S

6
• Certificates are not just for web servers
• Individual users can also apply for digital certificates
• Characteristics of certificates generated by a CA
– Any users with access to the public key of the CA can obtain the
public keys of the users that were certified by the CA.
– No parties other than the CA can modify the certificate without
being detected.
• All users who subscribe to the same CA have the common
trust to that CA.
• All user certificates can be placed in the directory for
access by all other users.
• Since the number of users is huge, it is more practical to
have more than one CA.
– In practice, each CA provides its public key to some fractions of
the users

7
• Problem
– Suppose
• User A obtains a certificate from CA X1
• User B obtains a certificate from CA X2
– If A does not know the public key of X2, then A cannot
decide whether B’s certificate can be trusted
• Solution
– If the two CAs have securely exchanged their public
keys, A can obtain B’s public key.
• A obtains X2’s certificate signed by X1
• Then A can obtain X2’s public key.
• Hence A can verify the certificate of B signed by X 2.
• The chain is X1<<X2>>X2<<B>>
– where CA<<U>> = the certificate issued by CA to user U
8
• Similarly, B can obtain A’s public key X2<<X1>>X1<<A>>
– In general, a chain with N elements can be expressed as
X1<<X2>>X2<<X3>>…..XN<<B>>
– All these certificates of CAs by CAs need to appear in
the directory, and the user needs to know how they are
linked to follow a path.
– The directory of CA X includes two types of
certificates.
• Forward certificates
– Certificates of X generated by other CAs (e.g., W)
– Example: W<<X>> (see next page)
• Reverse certificates
– Certificates of other CAs (e.g., W) generated by X
– Example: X<<W>> (see next page)
– X.509 suggests that CAs be arranged in a hierarchy so
that navigation is straight forward.

9
 The connected circles
indicate the hierarchical
relationship among the CAs

The associated boxes indicate

certificates maintained in the
directory for each CA entry.

Flow B

10
Image source: Stallings, Cryptography and Network Security: Principles and Practice (6 Edition)
th
– Suppose A obtains a certificate from B and does not
know whether the certificate can be trusted:
• Certification path from A to B
X<<W>>W<<V>>V<<Y>>Y<<Z>>Z<<B>>
– Suppose B obtains a certificate from A and does not
know whether the certificate can be trusted:
• Certification path from B to A
Z<<Y>>Y<<V>>V<<W>>W<<X>>X<<A>>

11
• Revocation of certificate
– Certificate may be revoked because
• The user’s private key is assumed to be compromised.
• The user is no longer certified by this CA.
• The CA’s certificate is assumed to be compromised.
– Each CA must maintain a list consisting of all revoked
but not expired certificates issued by that CA.
– Users could check the directory each time a certificate
is received.
– Users may maintain a local cache of certificates and
lists of revoked certificates.

12
 13
Image source: Stallings, Cryptography and Network Security: Principles and Practice (6 Edition)
th
 Secure Socket Layer (SSL)
• SSL was originated by Netscape.
• Version 3 of the protocol was designed with public
review and input from industry.
• It is designed to make use of TCP to provide a
reliable end-to-end secure service, such as for
HTTP, FTP, and SMTP
– HTTPS: HTTP over SSL
• Also stands for HTTP Secure or HTTP over TLS (see later
slides)
– FTPS: FTP over SSL
• Note that FTPS is different from SFTP, which stands for
Secure File Transfer Protocol or SSH File Transfer Protocol
14
• Two important SSL concepts
– Session
• An association between a client and a server.
• Created by the handshake protocol.
• Define a set of cryptographic security parameters, which can be
shared by multiple connections.
– Connection
• A connection is a transport that provides a suitable type of
service.
• Connections are transient.
• Every connection is associated with one session.

15
 • SSL consists of two layers of protocols.
– The SSL Record Protocol
• Provides basic security services to various higher layer
protocols.
– SSL-specific protocols
• Handshake protocol.
• Change Cipher Spec Protocol
• Alert Protocol.

16
Image source: Stallings, Cryptography and Network Security: Principles and Practice (6 Edition)
th
 • SSL Record Protocol
– Provide two services
– Confidentiality
• The handshake protocol defines a shared secret key that is
used for conventional encryption of SSL payload
– Message Integrity
• The handshake protocol also defines a shared secret key
that is used to form a Message Authentication Code
(MAC).

17
Image source: Stallings, Cryptography and Network Security: Principles and Practice (6 Edition)
th
 (optional)

18
Image source: Stallings, Cryptography and Network Security: Principles and Practice (6 Edition)
th
 • Handshake protocol
– Allows the server and the client to authenticate each
other.
– To negotiate an encryption and MAC algorithm and
cryptographic keys.
– Four phases:
1. Establish Security Capabilities
2. Server Authentication and Key Exchange
3. Client Authentication and Key Exchange
4. Finish
– See diagram on the next page

19
Image source: Stallings, Cryptography and Network Security: Principles and Practice (6 Edition)
th
 May

Image source: Stallings,

Cryptography and Network
Security: Principles and Practice
(6th Edition) 20
– Phase 1: Establish Security Capabilities
• Initiate a logical connection and establish the
security capabilities associates with it.
• The client initiates with a client_hello message with
– Version
» The highest SSL version understood by client
– Random (consist of a timestamp and a random number)
» Prevent replay attack.
– Session ID
» Session identifier
– cipherSuite
» List of cryptographic algorithms supported by the
client.
– Compression Method
» List of compression methods supported by the client.

21
• The server replies with a server_hello message with
– Version
» The highest SSL version understood by both sides
– Random (consist of a timestamp and a random number)
» Prevent replay attack.
– Session ID
» Session identifier
– cipherSuite
» Choose the strongest cryptographic algorithm
supported by both sides
» If no algorithm is supported by both sides, end the
session with a handshake failure alert
– Compression Method
» Specify the compression method (if any)

22
– Phase 2: Server Authentication and Key
Exchange
• Server sends certificate if necessary
– The message contains one or a chain of X.509 certificates.
– Required for any agreed-on key exchange.
• Send server_key_exchange message if necessary
– Not required in some cases such as when certificate
already contains necessary information
• Send certificate_request message if necessary
– Request the client to send its own certificate
– Certificate_type
» Indicates the public-key algorithm and its use.
– Certificate authorities
» A list of the distinguished names of acceptable
certificate authorities.
• Send server_done message
23
– Phase 3: Client Authentication and Key Exchange
• The client will first validate the certificate and the parameters
in the server_hello message.
• Send certificate if it is requested by server.
• Send client_key_exchange message
– Must be sent in this phase
– The content depends on the type of the key exchange
– If certificate already contains necessary information, this
message will be null
• Send certificate_verify message if necessary
– Provide explicit verification of the client’s certificate
» To avoid someone misusing the client’s certificate
– Verify the client’s ownership of the private key for the client
certificate, which contains the public key
» The client signs a hash code based on the preceding messages using
the private key
» The server verifies by using the public key on the client certificate

24
– Phase 4: Finish
• The client sends change_cipher_spec message
– Consists of a single byte with value 1.
– At this point, the client switched to the agreed cipher suite
• Client sends finish message
– Under the agreed algorithms, key, and secrets
– Verifies that the key exchange and authentication processes
were successful.
• Server send change_cipher_spec message
• Server sends its finished message.

25
 Transport Layer Security (TLS)
• In 2014, SSL 3.0 is found to be vulnerable to the POODLE
attack (a kind of MiM attack) and is considered broken.
• We should use Transport Layer Security (TLS) instead
• TLS 1.0 is an upgrade of SSL 3.0 with similar
functionalities, with some differences in:
– MAC scheme
– Alert code
– Cipher suite
– Client certificate type
– Cryptographic computation
– Padding
• Sometimes, TLS 1.0 is referred to as SSL 3.1
26
• However, some of the TLS 1.0 / 1.1 implementations are
still vulnerable to the POODLE attack
• To avoid the attack, we need to use TLS 1.2
– But a server that is not configured properly is still vulnerable to
attacks
• The latest version is TLS 1.3
– Approved by The Internet Engineering Task Force (IETF) in 2018
– More secure than TLS 1.2
• Remove the support of old and broken cryptographic primitives
– E.g., RSA (for key exchange), SHA-1, MD5
• Mandate forward secrecy: If a key is compromised in one session, the security
of earlier sessions will not be affected
– Faster to establish a secure connection than TLS 1.2
• Reduce the number of round-trips for handshake from 2 to 1
– 2-RTT  1-RTT
• Support 0-RTT for previously established connections
– At the cost of weaker security

27
TLS 1.2
2-RTT (before HTTP GET)

TLS 1.3
1-RTT (before HTTP GET)

28
Image source: https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a/
TLS 1.3
0-RTT (before HTTP GET)

29
Image source: https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a/