0% found this document useful (0 votes)
50 views

L16 Ch16 Transport Level Security

The document discusses transport layer security (TLS) and the Secure Sockets Layer (SSL) protocol. It describes the SSL/TLS handshake protocol which establishes an encrypted connection in 4 phases: 1) agreeing security capabilities, 2) server authentication and key exchange, 3) client authentication and key exchange, 4) finishing the handshake. It explains the messages involved in each phase, including ClientHello, ServerHello, Certificate, ServerKeyExchange, CertificateRequest, ClientKeyExchange, ChangeCipherSpec, and Finished.

Uploaded by

mca.2022
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
50 views

L16 Ch16 Transport Level Security

The document discusses transport layer security (TLS) and the Secure Sockets Layer (SSL) protocol. It describes the SSL/TLS handshake protocol which establishes an encrypted connection in 4 phases: 1) agreeing security capabilities, 2) server authentication and key exchange, 3) client authentication and key exchange, 4) finishing the handshake. It explains the messages involved in each phase, including ClientHello, ServerHello, Certificate, ServerKeyExchange, CertificateRequest, ClientKeyExchange, ChangeCipherSpec, and Finished.

Uploaded by

mca.2022
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 45

Cryptography and

Network Security
Chapter 16
Fifth Edition
by William Stallings
Chapter 16 –
Transport-Level Security
Use your mentality
Wake up to reality
—From the song, "I've Got You under My
Skin“ by Cole Porter
Web Security
 Web now widely used by business,
government, individuals
 But Internet & Web are vulnerable
 Have a variety of threats
 Integrity
 Confidentiality
 Denial of service
 Authentication
 need added security mechanisms
Threats on the Web
Web Traffic Security
Approaches
SSL (Secure Socket Layer)
 Transport layer security service
 Originally developed by Netscape
 Version 3 designed with public input
 Subsequently became Internet standard
known as TLS (Transport Layer Security)
 Uses TCP to provide a reliable end-to-end
service
 SSL has two layers of protocols
SSL Connection Properties
 Confidentiality
 Transmitted data is encrypted. A handshake
procedure is used to agree upon the
parameters of symmetric encryption to be
use, including the encryption key.
 Authetication
 Identity of the communicating parties can be
established using public key cryptography.
 Integrity
 Uses MAC to detect loss or alteration of data.
SSL Architecture
SSL Architecture
 SSL connection
 A transient, peer-to-peer, communications link
 Associated with 1 SSL session
 SSL session
 An association between client & server
 Created by the Handshake Protocol
 Define a set of cryptographic parameters
 May be shared by multiple SSL connections
Session State
 Session Identifier
 Peer certificate
 Compression Method
 Cipher Specs
 Encryption Algorithm, Hash Algorithm
 Master Secret (48 byte shared secret
between client and server)
 Is resumable (can be used to initiate new
connection)?
Connection State
 Server and Client random
 Server write MAC secret
 Client write MAC secret
 Server write key (server encryption key)
 Client write key (client encryption key)
 Initialization vectors
 Sequence numbers
SSL Record Protocol
Services
 Confidentiality
 Using symmetric encryption with a shared
secret key defined by Handshake Protocol
 AES, IDEA, RC2-40, DES-40, DES, 3DES,
Fortezza
 RC4-40, RC4-128
 Message is compressed before encryption
 Message integrity
 Using a MAC with shared secret key
 Similar to HMAC but with different padding
SSL Record Protocol
Operation
SSL Record Protocol Header
 Content type ( 8 bits)
 The higher-layer protocol used to process the
enclosed fragment. (SSL Handshake, SSL Change
Cipher Spec, SSL Alert, Application data)
 Major version number (8 bits)
 Minor version number (8 bits)
 Compressed length (16 bits)
SSL Handshake Protocol
 Allows server & client to:
 Authenticate each other
 To negotiate encryption & MAC algorithms
 To negotiate cryptographic keys to be used
 Comprises a series of messages in
phases (10 different types of messages)
1. Establish Security Capabilities
2. Server Authentication and Key Exchange
3. Client Authentication and Key Exchange
4. Finish
TLS Handshake Message Type
SSL
Handshake
Protocol
client_hello Message
 Version:
 The highest SSL version understood by the
client.
 Random:
 A client-generated random structure
consisting of a 32-bit timestamp and 28 bytes
generated by a secure random number
generator.
 These values serve as nonces and are used
during key exchange to prevent replay
client_hello Message
 Session ID:
 A variable-length session identifier. A nonzero
value indicates that the client wishes to
update the parameters of an existing
connection or to create a new connection on
this session.
 A zero value indicates that the client wishes to
establish a new connection on a new session.
client_hello Message
 Cipher Suit Parameters
 A list that contains the combinations of
cryptographic algorithms supported by the
client, in decreasing order of preference.
 Each element of the list (each cipher suite)
defines both a key exchange algorithm and a
CipherSpec.
 TLS_RSA_WITH_NULL_MD5
 TLS_RSA_WITH_RC4_128_SHA
 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
 TLS_RSA_WITH_NULL_MD5
 TLS_NULL_WITH_NULL_NULL
Key Exchange Methods
 RSA
 Secret key is encrypted with RSA public key (in server certificate)

 Fixed Diffie-Hellman
 DH public key parameters in certificate signed by CA.Fixed secret key

 Ephemeral Diffie-Hellman
 Temporary, one time DH public key parameters exchanged using
senders private RSA, DSS key. Can be verified by using certified
public keys ( in CA issued certificate). Most secure.

 Anonymous Diffie-Hellman
 DH public key exchange with no authentication
 Not secure due to man in the middle attack

 Fortezza
CipherSpec
 CipherAlgorithm
 Any of the algorithms mentioned earlier: RC4,
RC2, DES, 3DES, DES40, IDEA, or Fortezza
 MACAlgorithm
 MD5 or SHA-1
 CipherType
 Stream or Block
 IsExportable
 True or False
CipherSpec
 HashSize
 0, 16 (for MD5), or 20 (for SHA-1) bytes
 Key Material
 A sequence of bytes that contain data used in
generating the write keys
 IV Size
 The size of the Initialization Value for Cipher
Block Chaining (CBC) encryption
Server certificate Message
 Required when using
 Fixed DH - certificate contains servers public
DH parameters.
 Ephemeral DH – certificate must have
signature capability.
 RSA – certificate should have secret key
encryption capability.
 Contains a single or chain of X.509
certificates.
server_key_exchange
Message
 Required when using
 Anonymous DH (contains prime number,
primitive root, public DH key)
 Ephemeral DH (same as above with
signature)
 RSA key exchange (When server cannot
send encrypted secret key as it has signature
only RSA key). Creates a temporary RSA
public private key pair and send the public key
along with signature
server_key_exchange
Message
 Not required for
 RSA (client will later on send the secret key
encrypted using the server public key in the
certificate exchanged in earlier certificate
message)
 Fixed DH – ( DH public parameters already
exchanged in earlier certificate message)
 Hash (required for signature) is computed
using
 Hash(ClientHello.random||ServerHello.random||
Server params)
certificate _request Message
 Required when using
 Ephemeral DH
 Fixed DH
 RSA key exchange (signature only)
 Not required for
 Anonymous DH
 Contains information about kind of
certificate requested and accepted CAs.
client_key_exchange
Message
 Required for
 RSA
• 48 byte pre-master secret sent encrypted using RSA public
key
 Ephemeral and Anonymous DH
• Client public DH parameters
 Fixed DH
• This message not required.

 Incase of DH pre-master secret is


computed using public parameters
exchanged
Finished message
 Contains pseudo random value generated
over (PRF function used)
 Master secret
 Finished label
 All handshake messages exchanged so far.
 Both MD5 and SHA-1 hashes are used

PRF( master secret, finished label,


MD5(handshake messages )||SHA1(handshake messages))
client_h
Client ello Server
Phase 1
hello Protocol version, session ID, cipher
server_ suit,compression method, initial random
numbers.

a te
certific Phase 2
y_ex ch a n g e Server may send certificate, key exchange
ke
server_ and request certificate.
u e st
e rt if ic ate_req
c
ne
r v e r_ h ello_do
se
Time
certific
a te Phase 3
client_ Client sends certificate if requested. Client
key_ex
c han ge sends key exchange.
certific
a te _ ve
rify

ch a n g e
_ciphe
r_spec
s Phase 4
finished Change cipher suit and finish handshake
protocol.
s
ciphe r_spec
c ha nge _
d
finishe
client_h
Client ello Server
Phase 1
hello Protocol version, session ID, cipher
server_ suit,compression method, initial random
numbers.

a te
certific
Phase 2
certificate_request message is optional.
Required only if client is to be authenticated
u e st
e rt if ic ate_req using a certificate.
c
ne
r v e r_ h ello_do
se
Time
certific Phase 3
a te
client_ certificate message is optional. Required
key_ex only if certificate_request message was sent
c han ge
earlier by server.
certific
a te _ ve client_key_exchange message will contain
rify
48 byte pre-master-secret encrypted using
public key of server (taken from server
certificate).
ch a n g e
_ciphe
r_spec
s Phase 4
finished Change cipher suit and finish handshake
protocol.
s
ciphe r_spec Key Exchange Protocol – RSA
c ha nge _
d
finishe
Server certificate containing RSA public key
meant for encryption/decryption of data/key.
client_h
Client ello Server
Phase 1
hello Protocol version, session ID, cipher
server_ suit,compression method, initial random
numbers.

a te Phase 2
certific Server certificate can only be used for
c ha nge signature verification.
key_ex
server_ Server creates temporary RSA public-
u e st private key pair for the purpose of
e rt if ic ate_req
c encryption/decryption and signs this
ne
r v e r_ h ello_do temporary public key using his private key
se and sends it to client inside
Time server_key_exchange message.

certific
a te Phase 3
client_ client_key_exchange message will contain
key_ex
c han ge 48 byte pre-master-secret encrypted using
certific temporary RSA public key sent by server.
a te _ ve
rify Temporary RSA public key is verified by
using RSA key contained in Server certificate
message.
ch a n g e
_ciphe
r_spec Phase 4
s
finished Change cipher suit and finish handshake
protocol.

s
ciphe r_spec Key Exchange Protocol – RSA*
c ha nge _
d
finishe
* Server certificate containing RSA public key
meant for verifying signatures.
client_h
Client ello Server
Phase 1
hello Protocol version, session ID, cipher
server_ suit,compression method, initial random
numbers.

a te
certific Phase 2
Server certificate message contains
certificate containing servers DH public
parameters (a, p, Y).

hello_ d one
server_
Time
certific
a te Phase 3
Client certificate message contains certificate
containing clients DH public parameters.

Shared DH public parameters are used to


compute pre-master-secret.

ch a n g e
_ciphe
r_spec Phase 4
s
finished Change cipher suit and finish handshake
protocol.

s
ciphe r_spec Key Exchange Protocol – Fixed DH
c ha nge _
d
finishe
Server and Clients have certificate containing
their DH public parameters (a, p,Y).
client_h
Client ello Server
Phase 1
hello Protocol version, session ID, cipher
server_ suit,compression method, initial random
numbers.

a te
certific Phase 2
y_ex ch a n g e Server certificate can only be used for
ke
server_ signature verification.
u e st Server creates temporary DH public-private
e rt if ic ate_req
c key pair signs this temporary public key
ne
r v e r_ h ello_do using his private key and sends all public
se parameters (a, p, Y) to client inside
Time server_key_exchange message.

certific Phase 3
a te
client_ Clients creates temporary DH public-private
key_ex key pair and sends public key to server
c han ge
inside client_key_exchange message.
certific
a te _ ve
rify
Shared temparory DH public parameters are
used to compute pre-master-secret.
ch a n g e
_ciphe
r_spec Phase 4
s
finished Change cipher suit and finish handshake
protocol.

s
ciphe r_spec Key Exchange Protocol –Ephemeral DH
c ha nge _
d
finishe
Server certificate containing RSA/DSS public key
meant for verifying signatures.
client_h
Client ello Server
Phase 1
hello Protocol version, session ID, cipher
server_ suit,compression method, initial random
numbers.

Phase 2
y_ex ch a n g e Server creates temporary DH public-private
ke
server_ key pair and sends all public parameters (a,
p, Y) to client inside server_key_exchange
message. (not encrypted, not signed)
hello_ d one
server_
Time
Phase 3
client_ Client creates temporary DH public-private
key_ex key pair and sends public key to server
c han ge
inside client_key_exchange message. (not
encrypted, not signed).

Shared temparory DH public parameters are


ch a n g e used to compute pre-master-secret.
_ciphe
r_spec
s
finished Phase 4
Change cipher suit and finish handshake
protocol.
s
ciphe r_spec
c ha nge _ Key Exchange Protocol – Anonymous DH
d
finishe
Not Secure. Susceptible to man-in-the-middle
attack.
Cryptographic Computations
 Master secret creation from pre-master
secret
 A one-time 48-byte value generated using 48
byte secret value exchanged using secure
key exchange (RSA / Diffie-Hellman).
 Generation of cryptographic parameters
 client write MAC secret, a server write MAC
secret, a client write key, a server write key, a
client write IV, and a server write IV
 Generated by hashing master secret
 Master secret =
PRF( pre-master secret, “master secret”,
ClientHello.random||ServerHello.random )
 Key Block =
PRF( master secret, “key expansion”,
ClientHello.random||ServerHello.random )
 PRF is used on master secret till enough
bits are generated to cover, MAC secrets,
encryption keys and IVs
Pseudo Random Function
PRF
 SSL
MD5(master_secret || SHA('A' || master_secret ||
ServerHello.random || ClientHello.random)) ||
MD5(master_secret || SHA('BB' || master_secret ||
ServerHello.random || ClientHello.random)) ||
MD5(master_secret || SHA('CCC' || master_secret ||
ServerHello.random || ClientHello.random)) ||...

 TLS
HMAC(master secret, A(1) || seed ) ||
HMAC(master secret, A(2) || seed ) ||
HMAC(master secret, A(3) || seed ) || …
Where A(0) = seed ( “master secret” ||
ServerHello.random||ClientHello.random)
A(i) = HMAC(master secret, A(i-1))
SSL Change Cipher Spec
Protocol
 One of 3 SSL specific protocols which use
the SSL Record protocol
 A single message
 Causes pending state to become current
 Hence updating the cipher suite in use
SSL Alert Protocol
 Conveys SSL-related alerts to peer entity
 Severity
• warning or fatal
 Specific alert
• fatal: unexpected message, bad record mac,
decompression failure, handshake failure, illegal
parameter
• warning: close notify, no certificate, bad certificate,
unsupported certificate, certificate revoked,
certificate expired, certificate unknown
 Compressed & encrypted like all SSL data
TLS (Transport Layer
Security)
 IETF standard RFC 2246 similar to SSLv3
 with minor differences
 in record format version number
 uses HMAC for MAC
 a pseudo-random function expands secrets
• based on HMAC using SHA-1 or MD5
 has additional alert codes
 some changes in supported ciphers
 changes in certificate types & negotiations
 changes in crypto computations & padding
HTTPS
 HTTPS (HTTP over SSL)
 combination of HTTP & SSL/TLS to secure
communications between browser & server
• documented in RFC2818
• no fundamental change using either SSL or TLS
 use https:// URL rather than http://
 and port 443 rather than 80
 encrypts
 URL, document contents, form data, cookies,
HTTP headers
HTTPS Use
 Connection initiation
 TLS handshake then HTTP request(s)
 Connection closure
 have “Connection: close” in HTTP record
 TLS level exchange close_notify alerts
 can then close TCP connection
 must handle TCP close before alert exchange
sent or completed
Secure Shell (SSH)
 Protocol for secure network communications
 Designed to be simple & inexpensive
 SSH1 provided secure remote logon facility
 Replace TELNET & other insecure schemes
 Also has more general client/server capability
 SSH2 fixes a number of security flaws
 Documented in RFCs 4250 through 4254
 SSH clients & servers are widely available
 Method of choice for remote login/ X tunnels
Summary
 have considered:
 need for web security
 SSL/TLS transport layer security protocols
 HTTPS

You might also like