8-1
Network Security
All material copyright 1996-2012
J.F Kurose and K.W. Ross, All Rights Reserved
George Parisis
School of Engineering and Informatics
University of Sussex
8-2 Network Security
Network Security
v What is network security?
v Principles of cryptography
v Message integrity, authentication
v Securing e-mail
v Securing TCP connections: SSL
v Network layer security: IPsec
v Operational security: firewalls and IDS
8-3 Network Security
Secure e-mail
Alice:
v generates random symmetric private key, KS
v encrypts message with KS (for efficiency)
v also encrypts KS with Bob’s public key
v sends both KS(m) and KB(KS) to Bob
v Alice wants to send confidential e-mail, m, to Bob.
KS( ) .
KB( ) . +
+ –
KS(m )
KB(KS )
+
m
KS
KS
KB +
Internet
KS( ) .
KB( ) . –
KB –
KS
m
KS(m )
KB(KS )
+
8-4 Network Security
Secure e-mail
Bob:
v uses his private key to decrypt and recover KS
v uses KS to decrypt KS(m) to recover m
v Alice wants to send confidential e-mail, m, to Bob.
KS( ) .
KB( ) . +
+ –
KS(m )
KB(KS )
+
m
KS
KS
KB +
Internet
KS( ) .
KB( ) . –
KB –
KS
m
KS(m )
KB(KS )
+
8-5 Network Security
Secure e-mail (continued)
v Alice wants to provide sender authentication message
integrity
v Alice digitally signs message
v sends both message (in the clear) and digital signature
H( ) . KA( ) . –
+ –
H(m ) KA(H(m))
–
m
KA –
Internet
m
KA( ) . +
KA +
KA(H(m))
–
m
H( ) . H(m )
compare
8-6 Network Security
Secure e-mail (continued)
v Alice wants to provide secrecy, sender authentication,
message integrity.
Alice uses three keys: her private key, Bob’s public
key, newly created symmetric key
H( ) . KA( ) . –
+
KA(H(m))
–
m
KA
–
m
KS( ) .
KB( ) . +
+
KB(KS )
+
KS
KB +
Internet
KS
8-7 Network Security
Network Security
v What is network security?
v Principles of cryptography
v Message integrity, authentication
v Securing e-mail
v Securing TCP connections: SSL
v Network layer security: IPsec
v Operational security: firewalls and IDS
8-8 Network Security
SSL: Secure Sockets Layer
v widely deployed security
protocol
§ supported by almost all
browsers, web servers
§ https
§ billions $/year over SSL
v variation -TLS: transport
layer security, RFC 2246
v provides
§ confidentiality
§ integrity
§ authentication
v original goals:
§ Web e-commerce
transactions
§ encryption (especially credit-
card numbers)
§ Web-server authentication
§ optional client authentication
§ minimum hassle in doing
business with new merchant
v available to all TCP
applications
§ secure socket interface
8-9 Network Security
SSL and TCP/IP
Application
TCP
IP
normal application
Application
SSL
TCP
IP
application with SSL
v SSL provides application programming
interface (API) to applications
8-10 Network Security
Toy SSL: a simple secure channel
v handshake: Alice and Bob use their
certificates, private keys to authenticate each
other and exchange shared secret
v key derivation: Alice and Bob use shared
secret to derive set of keys
v data transfer: data to be transferred is broken
up into series of records
v connection closure: special messages to
securely close connection
8-11 Network Security
Toy: a simple handshake
MS: master secret
EMS: encrypted master secret
hello
public key certif
icate
KB+(MS) = EMS
8-12 Network Security
Toy: key derivation
v considered bad to use same key for more than one
cryptographic operation
§ use different keys for message authentication code (MAC) and
encryption
v four keys:
§ Kc = encryption key for data sent from client to server
§ Mc = MAC key for data sent from client to server (appended)
§ Ks = encryption key for data sent from server to client
§ Ms = MAC key for data sent from server to client (appended)
v keys derived from key derivation function (KDF)
§ takes master secret and (possibly) some additional random
data and creates the keys
8-13 Network Security
Toy: data records
v why not encrypt data in constant stream as we write it
to TCP?
§ where would we put the MAC? If at end, no message
integrity until all data processed.
§ e.g., with instant messaging, how can we do integrity check
over all bytes sent before displaying?
v instead, break stream in series of records
§ each record carries a MAC
§ receiver can act on each record as it arrives
v issue: in record, receiver needs to distinguish MAC
from data
§ want to use variable-length records
length data MAC
8-14 Network Security
Toy: sequence numbers
v problem: Trudy could capture two segments sent by
Bob, reverse the order of the segments, adjust the TCP
sequence numbers (which are not encrypted), and then
send the two reverse-ordered segments to Alice.
v solution: put sequence number into MAC:
§ MAC = MAC(Mx, sequence||data)
§ note: no sequence number field (number of records)
v problem: attacker could replay all records
v solution: use nonce
8-15 Network Security
Toy: control information
v problem: truncation attack:
§ attacker forges TCP connection close segment
§ one or both sides thinks there is less data than
there actually is.
v solution: record types, with one type for
closure
§ type 0 for data; type 1 for closure
v MAC = MAC(Mx, sequence||type||data)
length type data MAC
8-16 Network Security
Toy SSL: summary
hello
certificate, nonce
KB+(MS) = EMS
type 0, seq 1, data
type 0, seq 2, data
type 0, seq 1
, data
type 0, seq 3, data
type 1, seq 4, close
type 1, seq 2, clo
se
en
cr
yp
te
d
bob.com
8-17 Network Security
Toy SSL isn’t complete
v how long are fields?
v which encryption protocols?
v want negotiation?
§ allow client and server to support different
encryption algorithms
§ allow client and server to choose together
specific algorithm before data transfer
8-18 Network Security
SSL cipher suite
v cipher suite
§ key exchange algorithm
§ bulk encryption algorithm
§ message authentication code
§ pseudorandom function
v SSL supports several cipher suites
§ TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
v negotiation: client, server agree on cipher suite
§ client offers choice
§ server picks one
8-19 Network Security
Real SSL: handshake (1)
Purpose
1. server authentication
2. negotiation: agree on crypto algorithms
3. establish keys
4. client authentication (optional)
8-20 Network Security
Real SSL: handshake (2)
1. client sends list of algorithms it supports, along with
client nonce
2. server chooses algorithms from list; sends back:
choice + certificate + server nonce
3. client verifies certificate, extracts server’s public
key, generates pre_master_secret, encrypts with
server’s public key, sends to server
4. client and server independently compute encryption
and MAC keys from pre_master_secret and
nonces
5. client sends a MAC of all the handshake messages
6. server sends a MAC of all the handshake messages
8-21 Network Security
Real SSL: handshaking (3)
last 2 steps protect handshake from tampering
v client typically offers range of algorithms, some
strong, some weak
v man-in-the middle could delete stronger
algorithms from list
v last 2 steps prevent this
§ last two messages are encrypted
8-22 Network Security
Real SSL: handshaking (4)
v why two random nonces?
v suppose Trudy sniffs all messages between
Alice & Bob
v next day, Trudy sets up TCP connection with
Bob, sends exact same sequence of records
§ Bob (Amazon) thinks Alice made two separate
orders for the same thing
§ solution: Bob sends different random nonce for
each connection. This causes encryption keys to
be different on the two days
§ Trudy’s messages will fail Bob’s integrity check
8-23 Network Security
handshake: ClientHello
handshake: Se
rverHello
handshake: Ce
rtificate
handshake: Se
rverHelloDone
handshake: ClientKeyExchange ChangeCipherSpec
handshake: Finished
ChangeCipherSpe
c
handshake:
Finished
application_data
application_data
Alert: warning, close_notify
Real SSL
connection
TCP FIN follows
everything
henceforth
is encrypted
8-24 Network Security
Key derivation
v client nonce, server nonce, and pre-master
secret input into pseudo random-number
generator.
§ produces master secret
v master secret sliced:
§ client MAC key
§ server MAC key
§ client encryption key
§ server encryption key
§ client initialization vector (IV)
§ server initialization vector (IV)
8-25 Network Security
Network Security (summary)
…. used in many different security scenarios
§ secure transport (SSL)