Assignments

I Choice of topic: before Thursday, November 26th, 23:59.

I Assignment of topic: Friday, November 27th.
I Deadline of first assignment: Sunday, December 13th, 23:59.

The deadlines are strict!

/ department of mathematics and computer science

 IPsec and SSL/TLS
Applied Cryptography, Lecture 5

Ruben Niederhagen

Nov. 24th, 2015

/ department of mathematics and computer science
 Cryptography in the TCP/IP stack 2/45

application layer application data (HTTP, SMTP...) application layer

transport layer session (TCP, UDP, ...) transport layer

network layer IP packets network layer

data-link layer frames data-link layer

physical layer physical layer

Alice Bob

/ department of mathematics and computer science

 Cryptography in the TCP/IP stack 2/45

application layer application data (HTTP, SMTP...) application layer

transport layer session (TCP, UDP, ...) transport layer

network layer IP packets network layer

data-link layer frames data-link layer

physical layer physical layer

Alice Bob
I application layer security (SSH, S-MIME, PGP, . . . )
I transport layer security (TLS/SSL, . . . )
I network layer security (IPsec, . . . )
I data-link layer security (WEP, WPA, WPA2, . . . )

/ department of mathematics and computer science

 Data-Link Layer Security 3/45

I encrypt all network packets between network links, e.g., WPA2

I point-to-point security between network interfaces
I transparent encryption and decryption for higher layers
I authentication between endpoints

/ department of mathematics and computer science

 Data-Link Layer Security 3/45

data-link layer security

I encrypt all network packets between network links, e.g., WPA2

I point-to-point security between network interfaces
I transparent encryption and decryption for higher layers
I authentication between endpoints

/ department of mathematics and computer science

 Network Layer Security 4/45

Internet
LAN router ISP router

I encrypt IP packets, main protocol IPsec

I point-to-point security between entities identified by IP addresses,
e.g. routers, firewalls
I routers encrypt and decrypt unnoticed by higher layers
I authentication of routers to each other

/ department of mathematics and computer science

 Network Layer Security 4/45

network layer security

Internet
LAN router ISP router

I encrypt IP packets, main protocol IPsec

I point-to-point security between entities identified by IP addresses,
e.g. routers, firewalls
I routers encrypt and decrypt unnoticed by higher layers
I authentication of routers to each other

/ department of mathematics and computer science

 Transport Layer Security 5/45

Internet

web server application server

I encrypt sessions and messages, e.g. TLS/SSL

I communication between web browser and server,
or email clients and servers
I entities identified by connections, port numbers
I encrypt and authenticate sessions

/ department of mathematics and computer science

 Transport Layer Security 5/45

transport layer security

Internet

web server application server

I encrypt sessions and messages, e.g. TLS/SSL

I communication between web browser and server,
or email clients and servers
I entities identified by connections, port numbers
I encrypt and authenticate sessions

/ department of mathematics and computer science

 Transport Layer Security 5/45

transport layer security

Internet

web server application server

I encrypt sessions and messages, e.g. TLS/SSL

I communication between web browser and server,
or email clients and servers
I entities identified by connections, port numbers
I encrypt and authenticate sessions

/ department of mathematics and computer science

 Transport Layer Security 6/45

/ department of mathematics and computer science

 Transport Layer Security 7/45

mail server

Internet

mail server

/ department of mathematics and computer science

 Transport Layer Security 7/45

SMTP

transport layer security

mail server

Internet

IMAP

transport layer security

mail server

/ department of mathematics and computer science

 Transport Layer Security 7/45

SMTP

transport layer security

mail server

Internet

IMAP

transport layer security

mail server

/ department of mathematics and computer science

 Application Layer Security 8/45

Internet

mail server mail server

I add security to standard message formats (e.g. S/MIME, OTR)

I for email: entire link between two user mail clients is protected
I authentication of sender and receiver
I end users have control over their keys
(but need to know what they are doing, how to use PKI)
I end-to-end security

/ department of mathematics and computer science

 Application Layer Security 8/45

application layer security

Internet

mail server mail server

I add security to standard message formats (e.g. S/MIME, OTR)

I for email: entire link between two user mail clients is protected
I authentication of sender and receiver
I end users have control over their keys
(but need to know what they are doing, how to use PKI)
I end-to-end security

/ department of mathematics and computer science

 9/45

Network Layer Security

IPsec

/ department of mathematics and computer science

 IPsec 10/45

I Obvious first reflex: we want end-to-end security

/ department of mathematics and computer science

 IPsec 10/45

I Obvious first reflex: we want end-to-end security

I How many people here regularly encrypt e-mail?

/ department of mathematics and computer science

 IPsec 10/45

I Obvious first reflex: we want end-to-end security

I How many people here regularly encrypt e-mail?
I How many people here already did before their first “Security”
lecture?

/ department of mathematics and computer science

 IPsec 10/45

I Obvious first reflex: we want end-to-end security

I How many people here regularly encrypt e-mail?
I How many people here already did before their first “Security”
lecture?
I Problem with application-level security: users
• Need to rewrite every single application.
• Need users to switch to secured applications.
• Need users to take care of keys.

/ department of mathematics and computer science

 IPsec 10/45

I Obvious first reflex: we want end-to-end security

I How many people here regularly encrypt e-mail?
I How many people here already did before their first “Security”
lecture?
I Problem with application-level security: users
• Need to rewrite every single application.
• Need users to switch to secured applications.
• Need users to take care of keys.
I Transport-layer security needs applications to be modified to use
secure transport layer.

/ department of mathematics and computer science

 IPsec 10/45

I Obvious first reflex: we want end-to-end security

I How many people here regularly encrypt e-mail?
I How many people here already did before their first “Security”
lecture?
I Problem with application-level security: users
• Need to rewrite every single application.
• Need users to switch to secured applications.
• Need users to take care of keys.
I Transport-layer security needs applications to be modified to use
secure transport layer.
I Idea of network-layer security: No need to change applications (or
user behavior).
I IPsec’s promise: Network security happening without you even
noticing.

/ department of mathematics and computer science

 IPsec 11/45

IP packet: IP header IP data (payload)

IPsec was mandatory for IPv6 and is now optional; optional for IPv4.

IPsec provides cryptographic functionality to protect IP packets:

I packet integrity,
I packet origin authentication,
I confidentiality,
I some traffic flow confidentiality,
I protection against replay attacks.
IPsec protocols
I AH - Authentication Header,
I ESP - Encapsulating Security Payload.

/ department of mathematics and computer science

 IPsec – Modes of Operation 12/45

Transport mode:
I only the payload of the IP packet is protected,
I header is not encrypted in ESP, parts of it are authenticated in AH,
I data is protected from source to destination,
I header information is completely in the clear,
I used only between hosts.

/ department of mathematics and computer science

 IPsec – Modes of Operation 12/45

Transport mode:
I only the payload of the IP packet is protected,
I header is not encrypted in ESP, parts of it are authenticated in AH,
I data is protected from source to destination,
I header information is completely in the clear,
I used only between hosts.

Tunnel mode:
I entire IP packet is protected (i.e. IP header and data),
I becomes the payload of a new IP packet,
I may contain different source and destination addresses,
I provides data flow confidentiality to some extent,
I can be used between hosts, gateways or host-gateway.
/ department of mathematics and computer science
 IPsec – Modes of Operation 13/45

transport mode

Internet

host gateway gateway host

tunnel mode
Internet local network

host gateway

/ department of mathematics and computer science

 IPsec – Modes of Operation 13/45

transport mode

Internet

host gateway gateway host

tunnel mode
local network Internet local network

gateway gateway

/ department of mathematics and computer science

 IPsec – Authentication Header 14/45

The Authentication Header provides

I data integrity,
I authentication of IP packets,
I protection against replay attacks.
First two by use of a Message Authentication Code (MAC),
e.g. HMAC-SHA1-96.

IP packet is expanded with an AH that contains items such as:

I next header — type of the header following this header,
I payload length — length of AH,
I Security Parameter Index (SPI) — identifies a SA,
I sequence number,
I authentication data — contains the MAC of the packet,
also called Integrity Check Value (ICV).

/ department of mathematics and computer science

 IPsec – Authentication Header 15/45

Protocol TCP
TCP Segment Data
6 Header

IP Header IP Data

ICV (truncated HMAC) is computed over:

I immutable IP header fields (fields that do not change in transit),
e.g., source address, IP header length,
I Auth. Header (except authentication data field),
I IP data.
Excluded fields are set to zero for HMAC computation.

/ department of mathematics and computer science

 IPsec – Authentication Header 15/45

IPSec Transport Mode

Protocol Next Header TCP

TCP Segment Data
51 6 Header

IP Header Auth. Header IP Data

Authenticated Fields

ICV (truncated HMAC) is computed over:

I immutable IP header fields (fields that do not change in transit),
e.g., source address, IP header length,
I Auth. Header (except authentication data field),
I IP data.
Excluded fields are set to zero for HMAC computation.

/ department of mathematics and computer science

 IPsec – Authentication Header 15/45

IPSec Tunnel Mode

Protocol Next Header TCP
Protocol TCP Segment Data
51 4 Header
6

IP Header IP Data

IP Header Auth. Header original IP Datagram (encapsulated)

Authenticated Fields

ICV (truncated HMAC) is computed over:

I immutable IP header fields (fields that do not change in transit),
e.g., source address, IP header length,
I Auth. Header (except authentication data field),
I IP data.
Excluded fields are set to zero for HMAC computation.

/ department of mathematics and computer science

 IPsec – Authentication Header 16/45

Anti-replay protection prevents resending copies of authenticated packets.

I Uses sequence number field.
I For each new SA, sequence counter set to 0.
I Keep track of overflow (sequence number is 32 bits),
negotiate new SA when counter reaches 232 − 1.
I Check whether counter is in window of fixed size.
I Right edge = highest sequence number so far received
(with valid authentication).
I Mark numbers of received packets with valid authentication.
I Advance window if new sequence number falls to the right of window
and packet authenticates.
I Discard packet if number falls to the left of window or packet does
not authenticate.

/ department of mathematics and computer science

 IPsec – Encapsulating Security Payload 17/45

The Encapsulating Security Payload provides:

I confidentiality, i.e. encryption with block cipher in CBC mode, e.g.
AES-CBC,
I functionality as in AH like authentication, anti-replay (optional).
ESP adds an ESP header, encrypts the payload and adds an ESP trailer.
An ESP packet contains:
I security parameter index (SPI),
I sequence number,
I payload data (encrypted),
I padding – to achieve data length a multiple of 32 bits (encrypted),
I padding length (encrypted),
I next header (encrypted),
I (optional) authentication data.
/ department of mathematics and computer science
 IPsec – Encapsulating Security Payload 18/45

Protocol TCP
TCP Segment Data
6 Header

IP Header IP Data

I In transport mode, only data is encrypted,

i.e. source and destination are in the clear.
I In tunnel mode, the whole package is encrypted,
i.e. real source and destination addresses are hidden.
I Authentication not over IP header fields, only ESP header and data.

/ department of mathematics and computer science

 IPsec – Encapsulating Security Payload 18/45

IPSec Transport Mode

Protocol TCP Next Header

TCP Segment Data
50 Header 6
ESP Auth.
IP Header ESP Header IP Data ESP Trailer Data

Encrytped Fields

Authenticated Fields

I In transport mode, only data is encrypted,

i.e. source and destination are in the clear.
I In tunnel mode, the whole package is encrypted,
i.e. real source and destination addresses are hidden.
I Authentication not over IP header fields, only ESP header and data.

/ department of mathematics and computer science

 IPsec – Encapsulating Security Payload 18/45

IPSec Tunnel Mode

Protocol TCP Next Header
Protocol TCP Segment Data
50 Header 4
6

IP Header IP Data
ESP Auth.
IP Header ESP Header original IP Datagram (encapsulated and encrypted) ESP Trailer Data

Encrypted Fields

Authenticated Fields

I In transport mode, only data is encrypted,

i.e. source and destination are in the clear.
I In tunnel mode, the whole package is encrypted,
i.e. real source and destination addresses are hidden.
I Authentication not over IP header fields, only ESP header and data.

/ department of mathematics and computer science

 IPsec – Security Associations 19/45

I Concept to formalize unidirectional security relationships between

two parties.
I Enforce security policy defined in Security Policy Database (SPDB).
I Security Association Database (SADB) contains list of active security
associations (SA).

/ department of mathematics and computer science

 IPsec – Security Associations 19/45

I Concept to formalize unidirectional security relationships between

two parties.
I Enforce security policy defined in Security Policy Database (SPDB).
I Security Association Database (SADB) contains list of active security
associations (SA).
SA parameters:
I sequence number, sequence number overflow,
I anti-replay window,
I AH information: authentication algorithm, key, key lifetime, etc.,
I ESP information: encryption algorithm, key, key lifetime, etc.,
I lifetime of the SA,
I IPsec protocol mode (tunnel, transport),
I maximal packet size.
/ department of mathematics and computer science
 IPsec – Security Associations 20/45

The Security Policy Database describes how to treat certain IP packets

(BYPASS, DISCARD, PROTECT).
Which SA to use for certain traffic is derived from selectors such as
I destination IP address,
I source IP address,
I transport layer protocol,
I source and destination ports.
Most selectors are read off from the IP packet (headers).

/ department of mathematics and computer science

 IPsec – Security Associations 20/45

The Security Policy Database describes how to treat certain IP packets

(BYPASS, DISCARD, PROTECT).
Which SA to use for certain traffic is derived from selectors such as
I destination IP address,
I source IP address,
I transport layer protocol,
I source and destination ports.
Most selectors are read off from the IP packet (headers).

A security association can be used

I for one communication direction (bidirectional needs two SAs),
I for AH or ESP; can be combined, e.g. ESP then AH.
SAs are negotiated by public-key mechanisms (see below).

/ department of mathematics and computer science

 Combining Security Associations 21/45

Using ESP in encryption-only mode is insecure:

I manipulate data of inner encrypted IP packets,
I use padding checks to build an ESP trailer oracle.
Degabriele/Paterson Attacking the IPsec Standards in Encryption-only
Configurations, IEEE Symposium on Security and Privacy 2007

/ department of mathematics and computer science

 Combining Security Associations 21/45

Using ESP in encryption-only mode is insecure:

I manipulate data of inner encrypted IP packets,
I use padding checks to build an ESP trailer oracle.
Degabriele/Paterson Attacking the IPsec Standards in Encryption-only
Configurations, IEEE Symposium on Security and Privacy 2007

Recall: SA can be combined for AH and ESP if ESP Auth. unavailable.

I For protecting communication against active adversary, need
authenticated encryption (security vs. Chosen Ciphertext attacks).
I AH covers more header fields than authentication in ESP,
in particular source and destination addresses in the IP header.
I Can do encrypt-then-MAC, i.e. first ESP then AH in transport mode,
this gives authenticated encryption.

/ department of mathematics and computer science

 Crypto Algorithms (until 2014) 22/45

See RFC 4835 (now obsolete)

I Encryption: block ciphers in Cipher Block Chaining (CBC) mode,
must have:
• NULL encryption (RFC 2410),
• AES-CBC with 128-bit keys,
• TripleDES-CBC (168-bit keys).

/ department of mathematics and computer science

 Crypto Algorithms (until 2014) 22/45

See RFC 4835 (now obsolete)

I Encryption: block ciphers in Cipher Block Chaining (CBC) mode,
must have:
• NULL encryption (RFC 2410),
• AES-CBC with 128-bit keys,
• TripleDES-CBC (168-bit keys).
I Message authentication/integrity: Hash-based Message
Authentication Code (HMAC),
must have:
• HMAC-SHA1-96,
may have:
• HMAC-MD5-96.

/ department of mathematics and computer science

 Crypto Algorithms (since 2014) 23/45

See RFC 7321

Old Requirement New Requirement Algorithm

MAY SHOULD AES-GCM with a 16 octet ICV
MAY SHOULD AES-GMAC with AES-128
MUST MAY TripleDES-CBC
SHOULD NOT MUST NOT DES-CBC
SHOULD SHOULD AES-XCBC-MAC-96
SHOULD MAY AES-CTR

/ department of mathematics and computer science

 Crypto Algorithms (since 2014) 23/45

See RFC 7321

Old Requirement New Requirement Algorithm

MAY SHOULD AES-GCM with a 16 octet ICV
MAY SHOULD AES-GMAC with AES-128
MUST MAY TripleDES-CBC
SHOULD NOT MUST NOT DES-CBC
SHOULD SHOULD AES-XCBC-MAC-96
SHOULD MAY AES-CTR

I These are symmetric algorithms, need a pre-shared secret key.

I Different options for key-agreement protocols: PSK, Internet Key
Exchange (IKE, IKE2), Kerberos (KINK), IPSECKEY DNS records.

/ department of mathematics and computer science

 IPsec Problems 24/45

I Crypto of IPsec is not really state of the art.

/ department of mathematics and computer science

 IPsec Problems 24/45

I Crypto of IPsec is not really state of the art.

I IPsec ESP allows (in principle) encryption without authentication.
I Attack by Degabriele and Paterson, 2007.
I Consequence: don’t use encrypt-only!

/ department of mathematics and computer science

 IPsec Problems 24/45

I Crypto of IPsec is not really state of the art.

I IPsec ESP allows (in principle) encryption without authentication.
I Attack by Degabriele and Paterson, 2007.
I Consequence: don’t use encrypt-only!
I IPsec AH authenticates IP header (incl. source and dest.).
I NAT changes IP header (source or dest.).
I Possible to get IPsec through NAT, but requires extra effort.

/ department of mathematics and computer science

 IPsec Problems 24/45

I Crypto of IPsec is not really state of the art.

I IPsec ESP allows (in principle) encryption without authentication.
I Attack by Degabriele and Paterson, 2007.
I Consequence: don’t use encrypt-only!
I IPsec AH authenticates IP header (incl. source and dest.).
I NAT changes IP header (source or dest.).
I Possible to get IPsec through NAT, but requires extra effort.
I Most important problem: It’s complicated!

/ department of mathematics and computer science

 Quotes on IPsec 25/45

“The first two generations of these documents (principally RFCs

1825–1829, published in 1995, and 2401–2412, published in
1998) are really only intended to provide a guide for
implementors and are notoriously complex, difficult to interpret
and lacking in overall structure.
...
The third and latest incarnation of the core IPsec standards
were published as RFCs 4301–4309 in December 2005, and are
somewhat more accessible.
...
However, the new RFCs are still a long and complex set of
documents, totalling over 300 pages.” – Paterson, 2006

/ department of mathematics and computer science

 More Quotes on IPsec 26/45

“We are of two minds about IPsec. On the one hand, IPsec is
far better than any IP security protocol that has come before:
Microsoft PPTP, L2TP, etc. On the other hand, we do not
believe that it will ever result in a secure operational system. It
is far too complex, and the complexity has lead to a large
number of ambiguities, contradictions, inefficiencies, and
weaknesses. It has been very hard work to perform any kind of
security analysis; we do not feel that we fully understand the
system, let alone have fully analyzed it.”
– Ferguson, Schneier, 2003

/ department of mathematics and computer science

 27/45

Transport Layer Security

SSL/TLS

/ department of mathematics and computer science

 Timeline of SSL/TLS 28/45

1995 2000 2005 2010 2015 2020

TL
SS

SS .0

TL

TL

TL .1

TL
L

S
S

S
2

3.

1.
1.

1.

1.
0

3
0

(d
re
fin

ra
ft)
ed
/ department of mathematics and computer science
 SSL/TLS 29/45

Secure Sockets Layer (SSL) and Transport Layer Security (TLS):

I TLS is a variant of SSLv3,
I SSL originally designed for web environment by Netscape,
I design goals: security of web traffic, email, etc.,
I had to work well with HTTP,
I provides transparency for higher layers.

/ department of mathematics and computer science

 SSL/TLS 29/45

Secure Sockets Layer (SSL) and Transport Layer Security (TLS):

I TLS is a variant of SSLv3,
I SSL originally designed for web environment by Netscape,
I design goals: security of web traffic, email, etc.,
I had to work well with HTTP,
I provides transparency for higher layers.

SSL/TLS provides a secure channel between server and client:

I confidentiality,
I server/client authentication,
I message integrity.

/ department of mathematics and computer science

 SSL/TLS 30/45

SSL/TLS runs on top of TCP:

I Transparent for application layer protocols,
I SSL/TLS connection acts like a secured TCP connection,
I most protocols running over TCP can be run over SSL/TLS instead,
e.g., HTTP → HTTPS, SMTP → SMTPS, . . .

/ department of mathematics and computer science

 SSL/TLS 30/45

SSL/TLS runs on top of TCP:

I Transparent for application layer protocols,
I SSL/TLS connection acts like a secured TCP connection,
I most protocols running over TCP can be run over SSL/TLS instead,
e.g., HTTP → HTTPS, SMTP → SMTPS, . . .

Protocols in SSL/TLS:
I Handshake Protocol: initiate session.
Authenticate server/client, establish keys.
I Record Protocol: data transfer.
Compute MAC for integrity, encrypt MAC and data.
I Alert Protocol: alert the other side of exceptional conditions.
E.g., errors and warnings.

/ department of mathematics and computer science

 SSL/TLS Handshake 31/45

I Client → Server: ClientHello

• ClientRandom: random number,
• Session ID (when resuming a session),
• List of available CipherSuites:
pk key exchange, pk auth, sym encryption, hash alg.
Example: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
ECDH Elliptic curve Diffie Hellman key exchange.
ECDSA Elliptic curve digital signature algorithm.
AES_128_CBC AES with 128-bit key in CBC mode.
SHA256 SHA with 256-bit output for HMAC.

/ department of mathematics and computer science

 SSL/TLS Handshake (cont.) 32/45

I Server → Client: ServerHello

• ServerRandom: random number,
• Session ID: implementation specific, random number,
• Chosen CipherSuite.
I Server → Client: Certificate
• Server sends server certificate to client,
client obtains server’s public key and verifies certificate.
I Server → Client: ServerKeyExchange
P a , random a,

for DHE:
signed
for ECDHE: [a]P, random a,
for RSA: –
I (Server → Client: CertificateRequest)
I Server → Client: ServerHelloDone
• Message marks end of server messages.

/ department of mathematics and computer science

 SSL/TLS Handshake (cont.) 33/45

I Client → Server: ClientKeyExchange

for DH(E): P b , random b,
for ECDH(E): [b]P, random b,
for RSA: random value encrypted with server public key.
I (Client → Server: CertificateVerify)
I Client → Server: ChangeCipherSpec
• Notify that client switched to new CipherSuite.
I Client → Server: Finished
• Encrypted Finished massaged contaning hash over the previous
handshake messages.

For DHE and ECDHE, client and server compute joint session key.

/ department of mathematics and computer science

 SSL/TLS Handshake (cont.) 34/45

I Server → Client: ChangeCipherSpec

• Notify that client switched to new CipherSuite.
I Server → Client: Finished
• Encrypted Finished massaged contaning hash over the previous
handshake messages.

/ department of mathematics and computer science

 SSL/TLS Handshake (cont.) 34/45

I Server → Client: ChangeCipherSpec

• Notify that client switched to new CipherSuite.
I Server → Client: Finished
• Encrypted Finished massaged contaning hash over the previous
handshake messages.

Interrupted session can be resumed:

I Server and client are supposed to store session ID and MasterSecret,
I client sends session ID in ClientHello,
I reduced protocol: Hello, ChangeCipherSpec and Finished messages,
I new keying data is exchanged,
I new session keys are derived.

/ department of mathematics and computer science

 TLS 1.2 key derivation 35/45

Pseudo-random function:
Define a pseudo-random function (PRF) as

PRF(secret, label, seed) = PSHA256 (secret, label || seed).

/ department of mathematics and computer science

 TLS 1.2 key derivation 35/45

Pseudo-random function:
Define a pseudo-random function (PRF) as

PRF(secret, label, seed) = PSHA256 (secret, label || seed).

The function P in PRF is an expansion function defined as

PH (secret, seed) = HMACH (secret, A(1) || seed) ||

HMACH (secret, A(2) || seed) || ...

and is iterated as often as necessary. The A(i) are defined as

A(0) = seed, A(i) = HMACH (secret, A(i-1)).

/ department of mathematics and computer science

 TLS 1.2 key derivation 36/45

Figure of the PRF at http://www.cs.bham.ac.uk/~mdr/teaching/

modules06/netsec/lectures/tls/tls.html.

/ department of mathematics and computer science

 TLS 1.2 key derivation 37/45

Message authentication code:

The message authentication code HMACH is constructed from a
hash function H as


HMACH (k, m) = H (k ⊕ opad) || H (k ⊕ ipad) || m

where
I opad is the outer padding (0x5c5c5...5c5c),
I and ipad is the inner padding (0x363636...3636).

/ department of mathematics and computer science

 HMACSHA1 38/45

key key
i_pad XOR o_pad XOR

i key pad o key pad

64 Byte 64 Byte

<= 64 Byte <= 64 Byte

i key pad message

SHA1 - 1st pass
hash sum 1

o key pad hash sum 1

SHA1 - 2nd pass
hash sum 2
64 Byte

20 Byte

/ department of mathematics and computer science

 TLS 1.2 key derivation 39/45

Computing the MasterSecret:

MasterSecret = PRF(PreMasterSecret, "master secret",
ClientRandom || ServerRandom)[0..47];

/ department of mathematics and computer science

 TLS 1.2 key derivation 39/45

Computing the MasterSecret:

MasterSecret = PRF(PreMasterSecret, "master secret",
ClientRandom || ServerRandom)[0..47];

Computing the MAC keys for the Finished messages:

PRF(MasterSecret, FinishedLabel, SHA256(handshake-messages))[0..95]

FinishedLabel: "client finished" of "server finished".

/ department of mathematics and computer science

 TLS 1.2 key derivation 40/45

Computing the KeyBlock for session keys:

KeyBlock = PRF(MasterSecret, "key expansion",
ServerRandom || ClientRandom)

Compute as many bits as needed to obtain six values from the key block:i
I client MAC key,
I server MAC key,
I client encryption key,
I server encryption key,
I client IV, server IV.

/ department of mathematics and computer science

 SSL/TLS Record Protocol 41/45

Record protocol to exchange encrypted and authenticated data:

I Payload data is split into fragments
which are protected and transmitted independently;
when received, fragments are decrypted and verified independently.
I Each fragment is authenticated with a MAC which is appended;
MAC is over a sequential number (anti-replay) and the content.
I Data fragment and MAC are encrypted.
I A record header is attached to the encrypted data,
containing information necessary for interpreting the record
such as type of data (e.g. Handshake or ApplicationData),
length, and SSL version.
I (header || encrypted fragment and MAC) is sent.

/ department of mathematics and computer science

 SSL/TLS Record 42/45

Byte +0 Byte +1 Byte +2 Byte +3

Byte 0 Content type

Version Length
Bytes 1...4
(Major) (Minor) (bits 15..8) (bits 7..0)
Bytes 5...(m–1) Protocol message(s)

Bytes m...(p–1) MAC (optional)

Bytes p...(q–1) Padding (block ciphers only)

Type ChangeCipherSpec Alert Handshake Application Heartbeat

Hex 0x14 0x15 0x16 0x17 0x18
Dec 20 21 22 23 24

/ department of mathematics and computer science

 SSL/TLS — Authentication, Key Exchange 43/45

Algorithm SSL 2.0 SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3
RSA Yes Yes Yes Yes Yes No
DH-RSA No Yes Yes Yes Yes No
DHE-RSA No Yes Yes Yes Yes Yes
ECDH-RSA No No Yes Yes Yes No
ECDHE-RSA No No Yes Yes Yes Yes
DH-DSS No Yes Yes Yes Yes No
DHE-DSS No Yes Yes Yes Yes No
ECDH-ECDSA No No Yes Yes Yes No
ECDHE-ECDSA No No Yes Yes Yes Yes
PSK No No Yes Yes Yes No
PSK-RSA No No Yes Yes Yes No
DHE-PSK No No Yes Yes Yes Yes∗
ECDHE-PSK No No Yes Yes Yes Yes∗
SRP No No Yes Yes Yes No
SRP-DSS No No Yes Yes Yes No
SRP-RSA No No Yes Yes Yes No
Kerberos No No Yes Yes Yes No
DH-ANON No Yes Yes Yes Yes No
ECDH-ANON No No Yes Yes Yes No
GOST No No Yes Yes Yes No
∗ Session Resumption

/ department of mathematics and computer science

 SSL/TLS — Cipher Security 44/45

Cipher Protocol Version

Algorithm Strength (bits) SSL 2.0 SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3
AES GCM N/A N/A N/A N/A Secure Secure
AES CCM 256, 128 N/A N/A N/A N/A Secure Secure
AES CBC N/A N/A Depends Secure Secure N/A
Camellia GCM N/A N/A N/A N/A Secure Secure
256, 128
Camellia CBC N/A N/A Depends Secure Secure N/A
ARIA GCM N/A N/A N/A N/A Secure Secure
256, 128
ARIA CBC N/A N/A Depends Secure Secure N/A
SEED CBC 128 N/A N/A Depends Secure Secure N/A
3DES EDE CBC 112 Insecure Insecure Low/Dep. Low Low N/A
GOST CNT 256 N/A N/A Secure Secure Secure N/A
IDEA CBC 128 Insecure Insecure Depends Secure N/A N/A
40 Insecure Insecure N/A N/A N/A N/A
DES CBC
56 Insecure Insecure Insecure N/A N/A N/A
RC2 CBC 56 Insecure Insecure Insecure N/A N/A N/A
ChaCha20-Poly1305 256 N/A N/A N/A N/A Secure Secure
40 Insecure Insecure Insecure N/A N/A N/A
RC4
128 Insecure Insecure Insecure Insecure Insecure N/A
NULL – N/A Insecure Insecure Insecure Insecure Insecure

/ department of mathematics and computer science

 Assignments 45/45

I Choice of topic: before Thursday, November 26th, 23:59.

I Assignment of topic: Friday, November 27th.
I Deadline of first assignment: Sunday, December 13th, 23:59.

The deadlines are strict!

/ department of mathematics and computer science