CEG5105

Cybersecurity for Computer

Systems
Internet Security – part 1

1
Outline

• Secure Communication in Practice

• Public Key Infrastructure (PKI)
• Transport Layer Security: TLS
• Denial-of-service (DoS) attacks
• Domain Name System (DNS) security
• Routing security

2
Secure Communication in Practice

Establish session keys from permanent

keys, using Handshaking
• Shared symmetric key (also called authentication
• Key Distribution Center protocol )
• PKI
Typically, for a session of
communication involving
communication many rounds of messages, a
protected by session key is first established
session keys using the permanent key
Messages are encrypted for Communication
confidentiality.
Integrity and authenticity are
protected by MACs.

3
 Secure Communication in Practice

• We can use public key cryptography to securely

(with privacy and authenticity) establish session
keys

1. Generate session key: s

2. Encrypt s using Bob’s public key: Encpk_B (s)
3. Sign Encpk_B (s): σ = Signsk_A(Encpk_B (s))
4. Send Encpk_B (s), σ
1. Verify: σ
2. Decrypt Decsk_B (Encpk_B (s)) using private key
3. Obtain s
Alice and Bob can now use s as session key

4
Secure Communication in Practice

• But how do Alice and Bob establish each other’s

public keys in the first place?
• A (terrible) idea: Since public key is not private, they can
simply send each other their public keys.
• In the Internet typically PKI (Public-key
infrastructure) establishes the public key.
• PKI functionality is known as the key distribution or
key management
• Typically done through (digital) certificates and
certificate authorities

5
Digital Certificate and
Certificate Authority
• Digital Certificate: issued by Certificate Authority
(CA)
• Certificate binds public key to a particular entity.
Has 4 components:
1. ID of entity
2. Public key associated with entity
3. Time frame this certificate is valid
4. Signature of the Certificate Authority (CA)

6
 Public-key Certification
Signsk_CA(certificate)
Bob’s
public pkB digital
key signature
CA
Bob’s private certificate for Bob’s
identifying key public key, signed
information by CA
sk
CA

Verify digital
signature
pkB
Bob’s
CA
Public key
public
verified
pkCA key

7
Public-key Certification

• But how does Alice obtain the Certificate Authority’s

public key in the first place?
• Everybody trusts the single CA?
• Hierarchy of CAs?
• Root CA public key comes with popular software. E.g.,
browser
• All web browsers come with a built-in list of trusted
root certificates
• Lesson: never use untrusted browsers!
• What if a CA is compromised and starts issuing
malicious certificates?

8
Certificate Transparency

• Can we just make certificates transparent?

• If all (both authentic and malicious) certificates are
visible to everyone, misbehavior would be also visible
• Uses append only Certificate Logs
• Each CL server maintains an ever-growing list of
certificates
• Public, verifiable, append-only log of certificates
• Browser rejects if the certificate is not in CL
• But, there are so many certificates. How to verify
the integrity of the CL log?

9
 Certificate Transparency

• CL server builds a
Merkle tree over the
certificates
• Signs and sends the root
• To verify if a certificate is
in CL:
• Query certificate from CL
• CL sends Merkle Proof
• Verify Merkle Proof

10
Certificate Transparency

• New certificates can be

added
• Older version is included
in the new version

11
KDC vs PKI

• KDC plays similar roles as the CA in PKI in managing

keys.
• KDC: symmetric keys. PKI: asymmetric keys.
• A KDC knows all the secret keys it shares with the
users.
• In PKI, a CA does not know the private key of any
user, even if it has signed the user’s certificate.
• KDC must be online at least during key distribution
phase.
• CA can be offline after certificates are issued.

12
Security in IP Networks –
Protocol Stack
These aren’t
present in Internet.

E.g., URL

Port number E.g., 80

IP Address
E.g., 8.8.8.8

(Network Access Layer)

MAC Address
E.g., 28:cf:e9:04:59:a5

13
Security in IP Networks
My address is 1.1.1.1

• Packet claims source and destination IP addresses

• Receiver assumes the sender address is the claimed
address
• What are potential issues?

14
Transport Layer Security (TLS)

• Standard for Internet Security

• Most recent version is TLS 1.3 published in 2018
• Offers privacy and message authentication
between communication applications
• Integrated to Web’s application layer protocol:
HTTPS
• Previously called Secure Socket Layer (SSL), now
deprecated but uses similar design

15
Transport Layer Security (TLS)

• TLS consists of two parts

• TLS Handshake:
• Agree on encryption algorithm to be used
• Establish shared secret keys using PKI (Certificate)
• TLS Record:
• Use shared secret keys to protect communication
• Typically, unilateral authentication, bilateral
encryption and message authentication
• Client contacts server
• Server provides digital certificate
• Client authenticates server
• Data is encrypted and authenticated in both directions
16
 TLS – high level overview
(inaccurate)
1. Client initiates a connection to a
server
2. Server presents its TLS certificate
3. Client validates the server by
verifying the certificate
information
4. A session key is then generated
through information exchange
between the two parties.
5. The generated session key is used
for encryption of traffic
and between
authentication
the two parties.
of traffic between the two parties.

Transport Layer Security (TLS) | Cyber Security Agency of Singapore

17
 TLS Handshake (TLS 1.2)
(1) Client hello, rA negotiation
Client Server
negotiate the cipher
(2) Server hello, rB suite to be used
 (skS, pkS)
(3) Server’s certificate (signed by CA)  Certificate
Masterkey
Key exchange +
= H(S,rA,rB) (4) Encpk (S) authentication
S Masterkey
= H(S,rA,rB)
(5) ChangeCipherSpec

(6) A finish message, containing a MAC over the previous

handshake messages, computed using the master key.
client says I’m done

(7) ChangeCipherSpec

(8) A finish message, containing a MAC over the previous

handshake messages, computed using the master key.
server says I’m done
18
TLS Handshake (TLS 1.2)
• rA, rB, and S are to randomly generated nonces. Some bits are derived
from time, so they are assured to be different for different sessions.
• Step 1: Client indicates a list of suggested ciphers they can use
• Step 2: Server chooses a cipher among this list
• Step 4: Client sends a random number S (known as the premaster key)
encrypted with the server’s public key
• The Master key is derived by both parties from S, rA, rB using a hash
function: h(S,rA,rB)
• All keys for agreed upon ciphers are derived from Master key.
• Steps 5 & 7: ChangeCipherSpec: “Everything I send you from now on will
be authenticated (and encrypted)”. Clear boundary between plaintext
messages and using agreed upon ciphers
• Steps 6 & 8: include a MAC of all previously exchanged messages. Why?

19
TLS Master Key
• Master key is “root key” used to derive all session keys
• Master key is partitioned and transformed to generate
keys for message authentication and encryption
Client MAC key
PRF Server MAC key
Master Key
Client Encryption key
Server Encryption Key
• TLS 1.3 no longer uses a single “master secret” in the
same sense. Instead, it uses a sophisticated key
schedule

20
 TLS Record

• Messages are protected with MACs and symmetric-

key encryption

Data m
Fragment m1 m2 m3

Append MAC m1 MACk(m1)

Encrypt c It is Authenticate then Encrypt

Add TLS header c TLS header not protected

21