Chapter 8

Security

A note on the use of these Powerpoint slides:

We’re making these slides freely available to all (faculty, students, readers).
They’re in PowerPoint form so you see the animations; and can add, modify,
and delete slides (including this one) and slide content to suit your needs.
They obviously represent a lot of work on our part. In return for use, we only
ask the following: Computer
 If you use these slides (e.g., in a class) that you mention their source
(after all, we’d like people to use our book!)
Networking: A Top
 If you post any slides on a www site, that you note that they are adapted
from (or perhaps identical to) our slides, and note our copyright of this
Down Approach
material.
7th Edition, Global Edition
Thanks and enjoy! JFK/KWR
Jim Kurose, Keith Ross
All material copyright 1996-2016 Pearson
J.F Kurose and K.W. Ross, All Rights Reserved April 2016
Securit 8-1
Chapter 8: Network
Security
Chapter goals:
 understand principles of network security:
• cryptography and its many uses beyond
“confidentiality”
• authentication
• message integrity
 security in practice:
• firewalls and intrusion detection systems
• security in application, transport, network, link
layers

Securit 8-2
Chapter 8 roadmap
8.1 What is network security?
8.2 Principles of cryptography
8.3 Message integrity and digital
signatures
8.4 End-point authentication
8.5 Securing e-mail
8.6 Securing TCP connections: SSL
8.7 Network layer security: IPsec and
VPNs
8.8 Securing wireless LANs
8.9 Operational security: firewalls and IDS
Securit 8-3
What is network security?
confidentiality: only sender, intended receiver
should “understand” message contents
• sender encrypts message
• receiver decrypts message
authentication: sender, receiver want to
confirm identity of each other
message integrity: sender, receiver want to
ensure message not altered (in transit, or
afterwards) without detection
access and availability: services must be
accessible and available to users

Securit 8-4
Friends and enemies: Alice,
Bob, Trudy
 well-known in network security world
 Bob, Alice (lovers!) want to communicate
“securely”
 Trudy (intruder) may intercept, delete, add
messages
Alice Bob
channel data, control
messages

data secure secure data

s
sender receiver

Trudy

Securit 8-5
Who might Bob, Alice be?
 … well, real-life Bobs and Alices!
 Web browser/server for electronic
transactions (e.g., on-line purchases)
 on-line banking client/server
 DNS servers
 routers exchanging routing table
updates
 other examples?

Securit 8-6
There are bad guys (and girls)
out there!
Q: What can a “bad guy” do?
A: A lot! See section 1.6
• eavesdrop: intercept messages
• actively insert messages into
connection
• impersonation: can fake (spoof) source
address in packet (or any field in
packet)
• hijacking: “take over” ongoing
connection by removing sender or
receiver, inserting himself in place
• denial of service: prevent service from
being used by others (e.g., by Securit 8-7
Chapter 8 roadmap
8.1 What is network security?
8.2 Principles of cryptography
8.3 Message integrity and digital
signatures
8.4 End-point authentication
8.5 Securing e-mail
8.6 Securing TCP connections: SSL
8.7 Network layer security: IPsec and
VPNs
8.8 Securing wireless LANs
8.9 Operational security: firewalls and IDS
Securit 8-8
 The language of cryptography

Alice’s Bob’s
K encryption K decryption
A
key Bkey

plaintext encryption ciphertext decryption plaintext

algorithm algorithm

m plaintext message
KA(m) ciphertext, encrypted with key KA
m = KB(KA(m))

Securit 8-9
Breaking an encryption
scheme
 cipher-text only attack: Trudy
known-plaintext
has ciphertext
she can analyze attack: Trudy has
 two approaches: plaintext
corresponding
• brute force: search through all keys to
ciphertext
• statistical analysis
• e.g., in
monoalphabetic
cipher, Trudy
determines pairings
for a,l,i,c,e,b,o,
 chosen-plaintext
attack: Trudy can get
ciphertext for chosen
plaintext

Securit 8-10
Symmetric key cryptography

KS KS

plaintext encryption ciphertext decryption plaintext

message, m algorithm algorithm
K (m) m = KS(KS(m))
S

symmetric key crypto: Bob and Alice share same

(symmetric)
S key: K
 e.g., key is knowing substitution pattern in mono
alphabetic substitution cipher
Q: how do Bob and Alice agree on key value?

Securit 8-11
Simple encryption scheme
substitution cipher: substituting one thing for
another
 monoalphabetic cipher: substitute one letter
for another abcdefghijklmnopqrstuvwxyz
plaintext:

ciphertext: mnbvcxzasdfghjklpoiuytrewq

e.g.: Plaintext: bob. i love you. alice

ciphertext: nkn. s gktc wky. mgsbc

Encryption key: mapping from set of

26 letters
to set of 26 letters Securit 8-12
A more sophisticated encryption
approach
 n substitution ciphers, M1,M2,…,Mn
 cycling pattern:
• e.g., n=4: M1,M3,M4,M3,M2; M1,M3,M4,M3,M2; ..
 for each new plaintext symbol, use
subsequent substitution pattern in cyclic
pattern
• dog: d from M1, o from M3, g from M4

Encryption key: n substitution ciphers,

and cyclic pattern
• key need not be just n-bit pattern

Securit 8-13
Symmetric key crypto: DES
DES: Data Encryption Standard
 US encryption standard [NIST 1993]
 56-bit symmetric key, 64-bit plaintext input
 block cipher with cipher block chaining
 how secure is DES?
• DES Challenge: 56-bit-key-encrypted phrase
decrypted (brute force) in less than a day
• no known good analytic attack
 making DES more secure:
• 3DES: encrypt 3 times with 3 different keys

Securit 8-14
Symmetric key
crypto: DES

DES operation
initial permutation
16 identical “rounds”
of function
application, each
using different 48
bits of key
final permutation

Securit 8-15
AES: Advanced Encryption
Standard
 symmetric-key NIST standard, replaced
DES (Nov 2001)
 processes data in 128 bit blocks
 128, 192, or 256 bit keys
 brute force decryption (try each key)
taking 1 sec on DES, takes 149 trillion
years for AES

Securit 8-16
Public Key Cryptography
symmetric key public key crypto
crypto  radically different
 requires sender, approach [Diffie-
receiver know shared
secret key Hellman76, RSA78]
 Q: how to agree on  sender, receiver do
key in first place not share secret key
(particularly if never  public encryption
“met”)? key known to all
 private decryption
key known only to
receiver

Securit 8-17
Public key cryptography
+ Bob’s public
K
B key

- Bob’s private
K
B key

plaintext encryption ciphertext decryption plaintext

message, m algorithm + algorithm message
K (m) - +
B m = KB (K (m))
B

Securit 8-18
Public key encryption
algorithms
requirements:

1 need K
B
. B
.
+ ( ) and K - ( ) such that
- +
K (K (m)) = m
B B

2 given public key K +, it should be

B
impossible to compute private
-
key K
B

RSA: Rivest, Shamir, Adelson algorithm

Securit 8-19
Prerequisite: modular
arithmetic
 x mod n = remainder of x when divide by
n
 facts:
[(a mod n) + (b mod n)] mod n = (a+b) mod n
[(a mod n) - (b mod n)] mod n = (a-b) mod n
[(a mod n) * (b mod n)] mod n = (a*b) mod n
 thus
(a mod n)d mod n = ad mod n
 example: x=14, n=10, d=2:
(x mod n)d mod n = 42 mod 10 = 6
xd = 142 = 196 xd mod 10 = 6
Securit 8-20
RSA: getting ready
 message: just a bit pattern
 bit pattern can be uniquely represented
by an integer number
 thus, encrypting a message is
equivalent to encrypting a number
example:
 m= 10010001 . This message is uniquely
represented by the decimal number 145.
 to encrypt m, we encrypt the corresponding
number, which gives a new number (the
ciphertext).

Securit 8-21
 RSA: Creating public/private key
pair
1. choose two large prime numbers p, q.
(e.g., 1024 bits each)
2. compute n = pq, z = (p-1)(q-1)
3. choose e (with e<n) that has no common factors
with z (e, z are “relatively prime”).
4. choose d such that ed-1 is exactly divisible by z.
(in other words: ed mod z = 1 ).
5. public key is (n,e). private key is (n,d).
+ -
KB KB
Securit 8-22
 RSA: encryption,
decryption
0. given (n,e) and (n,d) as computed above
1. to encrypt message m (<n), compute
c= em
mod n
2. to decrypt received bit pattern, c, compute
m d= c
mod n
magic m = (me mod n) d mod n
happens!
c

Securit 8-23
RSA example:
Bob chooses p=5, q=7. Then n=35, z=24.
e=5 (so e, z relatively prime).
d=29 (so ed-1 exactly divisible by z).
encrypting 8-bit messages.

e
bit pattern m m c = me mod n
encrypt:
0000l000 12 24832 17

d
c c m = cd mod n
decrypt:
17 481968572106750915091411825223071697 12

Securit 8-24
Why does RSA work?
 must show that cd mod n = m
where c = me mod n
 fact: for any x and y: xy mod n = x(y mod z)
mod n
• where n= pq and z = (p-1)(q-1)
 thus,
cd mod n = (me mod n)d mod n
= med mod n
= m(ed mod z) mod n
= m1 mod n
=m
Securit 8-25
 RSA: another important
property
The following property will be very useful later:

- + + -
K (K (m)) = m = K (K (m))
B B B B

use public key use private key

first, followed first, followed
by private key by public key

result is the
same!
Securit 8-26
 - + + -
Why K (K (m)) = m = K (K (m))
B B B B
?

follows directly from modular arithmetic:

(me mod n)d mod n = med mod n

= mde mod n
= (md mod n)e mod n

Securit 8-27
Why is RSA secure?
 suppose you know Bob’s public key
(n,e). How hard is it to determine d?
 essentially need to find factors of n
without knowing the two factors p and q
• fact: factoring a big number is hard

Securit 8-28
RSA in practice: session
keys
 exponentiation in RSA is
computationally intensive
 DES is at least 100 times faster than
RSA
 use public key crypto to establish
secure connection, then establish
second key – symmetric session key –
for encrypting data
session key, KS
 Bob and Alice use RSA to exchange a
symmetric key KS
 once both have KS, they use symmetric key
cryptography
Securit 8-29
Chapter 8 roadmap
8.1 What is network security?
8.2 Principles of cryptography
8.3 Message integrity and digital
signatures
8.4 End-point authentication
8.5 Securing e-mail
8.6 Securing TCP connections: SSL
8.7 Network layer security: IPsec and
VPNs
8.8 Securing wireless LANs
8.9 Operational security: firewalls and IDS
Securit 8-30
Digital
signatures
cryptographic technique analogous to
hand-written signatures:
 sender (Bob) digitally signs document,
establishing he is document owner/creator.
 verifiable, nonforgeable: recipient (Alice)
can prove to someone that Bob, and no
one else (including Alice), must have
signed document

Securit 8-31
Digital
signatures
simple digital signature for message m:
 Bob signs m by encrypting with his private
-
- message, KB(m)
key KB, creating “signed”

- Bob’s private -
Bob’s message, m KB m,K B(m)
key
Dear Alice
Bob’s message, m,
Oh, how I have missed
you. I think of you all the
Public key signed (encrypted)
time! …(blah blah blah) encryption with his private key
Bob algorithm

Securit 8-32
Digital
signatures
 -
suppose Alice receives msg m, with signature: m,
KB(m)
+ - + -
 Alice verifies m signed by Bob by applying Bob’s
+ -
public key KB to KB(m) then checks KB(KB(m) ) =
m.
 Alice
If KB(Kthus
B(m)verifies
) = m, whoever
that: signed m must have
used Bob
Bob’s private
signed m key.
 no one else signed m
 Bob signed m and not m‘
non-repudiation:
-
 Alice can take m, and signature KB(m) to
court and prove that Bob signed m
Securit 8-33
Message digestslarge H: Hash
message Function
m
computationally
expensive to public-
H(m)
key-encrypt long
messages Hash function
goal: fixed-length, properties:
easy- to-compute  many-to-1
digital “fingerprint”  produces fixed-size
 apply hash function H msg digest
to m, get fixed size (fingerprint)
message digest,  given message digest
H(m). x, computationally
infeasible to find m
such that x = H(m)
Securit 8-34
Internet checksum: poor crypto hash
function
Internet checksum has some properties of hash
function:
 produces fixed length digest (16-bit sum) of
message
 is many-to-one
But given message with given hash value, it is easy
to find another message with same hash value:

message ASCII format message ASCII format

IOU1 49 4F 55 31 IOU9 49 4F 55 39
00.9 30 30 2E 39 00.1 30 30 2E 31
9BOB 39 42 D2 42 9BOB 39 42 D2 42
B2 C1 D2 AC different messages B2 C1 D2 AC
but identical checksums!

Securit 8-35
Digital signature = signed
message digest
Bob sends digitally Alice verifies signature,
signed message: integrity of digitally
signed message:
large
message H: Hash
encrypted
m function H(m)
msg digest
-
KB(H(m))
Bob’s digital large
private signature message
- Bob’s
key KB (encrypt) m digital
public
+ signature
key KB
encrypted H: Hash (decrypt)
msg digest function
-
+ KB(H(m))
H(m) H(m)

equal
?
Securit 8-36
Hash function algorithms
 MD5 hash function widely used (RFC
1321)
• computes 128-bit message digest in 4-step
process.
• arbitrary 128-bit string x, appears difficult to
construct msg m whose MD5 hash is equal to
x
 SHA-1 is also used
• US standard [NIST, FIPS PUB 180-1]
• 160-bit message digest

Securit 8-37
Public-key certification
 motivation: Trudy plays pizza prank on
Bob
• Trudy creates e-mail order:
Dear Pizza Store, Please deliver to me four
pepperoni pizzas. Thank you, Bob
• Trudy signs order with her private key
• Trudy sends order to Pizza Store
• Trudy sends to Pizza Store her public key,
but says it’s Bob’s public key
• Pizza Store verifies signature; then delivers
four pepperoni pizzas to Bob
• Bob doesn’t even like pepperoni

Securit 8-38
Certification
authorities
 certification authority (CA): binds public
key to particular entity, E.
 E (person, router) registers its public key with
CA.
• E provides “proof of identity” to CA.
• CA creates certificate binding E to its public key.
• certificate containing E’s public key digitally signed by
CA – CA says “this is E’s public key”

Bob’s digital
+
public +
signature KB
key KB (encrypt)
CA
private - certificate for
Bob’s K
identifying key CA Bob’s public key,
information signed by CA
Securit 8-39
Certification
authorities
 when Alice wants Bob’s public key:
• gets Bob’s certificate (Bob or elsewhere).
• apply CA’s public key to Bob’s certificate,
get Bob’s public key

+ digital Bob’s
KB signature public
+
(decrypt) K B key

CA
public K+
CA
key

Securit 8-40
Chapter 8 roadmap
8.1 What is network security?
8.2 Principles of cryptography
8.3 Message integrity and digital
signatures
8.4 End-point authentication
8.5 Securing e-mail
8.6 Securing TCP connections: SSL
8.7 Network layer security: IPsec and
VPNs
8.8 Securing wireless LANs
8.9 Operational security: firewalls and IDS
Securit 8-41
 Authenticatio
n
Goal: Bob wants Alice to “prove” her
identity to him
Protocol ap1.0: Alice says “I am Alice”

“I am Alice”
Failure scenario??

Securit 8-42
 Authenticatio
n
Goal: Bob wants Alice to “prove” her
identity to him
Protocol ap1.0: Alice says “I am Alice”

in a network,
Bob can not “see” Alice,
so Trudy simply declares
“I am Alice” herself to be Alice

Securit 8-43
Authentication: another
try
Protocol ap2.0: Alice says “I am Alice” in an IP packet
containing her source IP address

Alice’s
IP address
“I am Alice”

Failure scenario??

Securit 8-44
Authentication: another
try
Protocol ap2.0: Alice says “I am Alice” in an IP packet
containing her source IP address

Trudy can create

a packet “spoofing”
Alice’s
Alice’s address
IP address
“I am Alice”

Securit 8-45
 Authentication: another
try
Protocol ap3.0: Alice says “I am Alice” and sends he
secret password to “prove” i

Alice’s Alice’s
“I’m Alice”
IP addr password

Alice’s Failure scenario??

OK
IP addr

Securit 8-46
 Authentication: another
try
Protocol ap3.0: Alice says “I am Alice” and sends he
secret password to “prove” i

Alice’s Alice’s
“I’m Alice”
IP addr password
playback attack: Trudy
Alice’s records Alice’s packet
OK
IP addr and later
plays it back to Bob

Alice’s Alice’s
“I’m Alice”
IP addr password

Securit 8-47
 Authentication: yet
another try
Protocol ap3.1: Alice says “I am Alice” and sends he
encrypted secret password to “prove” i

Alice’s encrypted
“I’m Alice”
IP addr password

Alice’s Failure scenario??

OK
IP addr

Securit 8-48
 Authentication: yet
another try
Protocol ap3.1: Alice says “I am Alice” and sends he
encrypted secret password to “prove” i

Alice’s encrypted
“I’m Alice” record
IP addr password
and
Alice’s
OK playback
IP addr
still works!

Alice’s encrypted
“I’m Alice”
IP addr password

Securit 8-49
 Authentication: yet
another try
Goal: avoid playback attack
nonce: number (R) used only once-in-a-lifetime
ap4.0: to prove Alice “live”, Bob sends Alice
nonce, R. Alice
must return R, encrypted with shared secret
“I am Alice” key

R
KA-B(R) Alice is live, and
only Alice knows
key to encrypt
nonce, so it must
Failures, drawbacks? be Alice!
Securit 8-50
Authentication: ap5.0
ap4.0 requires shared symmetric key
 can we authenticate using public key
techniques?
ap5.0: use nonce, public key cryptography
“I am Alice”
Bob computes
R + -
- K A(K A(R)) = R
K A (R)
and knows only Alice
“send me your public key” could have the private
+ key, that encrypted R
KA such that
+ -
K (K (R)) = R
A A

Securit 8-51
 ap5.0: security
hole
man (or woman) in the middle attack: Trudy
poses as Alice (to Bob) and as Bob (to Alice)

I am Alice I am Alice
R -
K (R)
T
R - Send me your public key
K (R) +
A K
T
Send me your public key
+
K
A +
K (m)
Trudy gets T
- +
+ m = K (K (m))
K (m) T T
A sends m to Alice
- +
m = K (K (m)) encrypted with
A A Alice’s public key
Securit 8-52
ap5.0: security
hole
man (or woman) in the middle attack: Trudy
poses as Alice (to Bob) and as Bob (to Alice)

difficult to detect:
 Bob receives everything that Alice sends, and
vice versa. (e.g., so Bob, Alice can meet one
week later and recall conversation!)
 problem is that Trudy receives all messages as
well!

Securit 8-53
Chapter 8 roadmap
8.1 What is network security?
8.2 Principles of cryptography
8.3 Message integrity and digital
signatures
8.4 End-point authentication
8.5 Securing e-mail
8.6 Securing TCP connections: SSL
8.7 Network layer security: IPsec and
VPNs
8.8 Securing wireless LANs
8.9 Operational security: firewalls and IDS
Securit 8-54
 Secure e-mail
Alice wants to send confidential e-mail, m, to Bob.
KS

m K ( .)
S
KS(m ) KS(m )
KS ( ) . m

+ Internet
- KS

KS
+ .
KB ( ) + +
- .
KB ( )
KB(KS ) KB(KS )
K+
B K-B

Alice:
 generates random symmetric private key, KS
 encrypts message with KS (for efficiency)
 also encrypts KS with Bob’s public key
 sends both KS(m) and KB(KS) to Bob Securit 8-55
 Secure e-mail
Alice wants to send confidential e-mail, m, to Bob.
KS

m K ( .)
S
KS(m ) KS(m )
KS ( ) . m

+ Internet
- KS

KS
+ .
KB ( ) + +
- .
KB ( )
KB(KS ) KB(KS )
K+
B K-B

Bob:
 uses his private key to decrypt and
recover KS
 uses KS to decrypt KS(m) to recover m
Securit 8-56
 Secure e-mail (continued)
Alice wants to provide sender authentication
message integrity
K-A K+
A
- -
m .
H( ) K (.)
-
A
KA(H(m)) KA(H(m)) + .
KA ( ) H(m )

+ Internet
- compare

m H( ). H(m )
m

Alice digitally signs message

sends both message (in the clear) and digital signature

Securit 8-57
Secure e-mail (continued)
Alice wants to provide secrecy, sender
authentication, message integrity.
-
KA
-
m .
H( )
- .
KA ( )
KA(H(m))
KS

+ KS ( ) .
m + Internet

KS
+
KB ( ) . +
KB(KS )
K+
B

Alice uses three keys: her private key, Bob’s

public key, newly created symmetric key
Securit 8-58
Chapter 8 roadmap
8.1 What is network security?
8.2 Principles of cryptography
8.3 Message integrity and digital
signatures
8.4 End-point authentication
8.5 Securing e-mail
8.6 Securing TCP connections: SSL
8.7 Network layer security: IPsec and
VPNs
8.8 Securing wireless LANs
8.9 Operational security: firewalls and IDS
Securit 8-59
SSL: Secure Sockets Layer
 widely deployed
 original goals:
security protocol
• supported by almost all • Web e-commerce
browsers, web servers transactions
• https • encryption (especially
• billions $/year over SSL credit-card numbers)
 mechanisms: [Woo • Web-server
1994], implementation: authentication
Netscape • optional client
 variation -TLS: transport authentication
layer security, RFC • minimum hassle in
2246 doing business with
 provides new merchant
• confidentiality  available to all TCP
• integrity applications
• authentication • secure socket
interface Securit 8-60
SSL and TCP/IP

Application Application

SSL
TCP
TCP
IP IP

normal application application with SSL

 SSL provides application programming

interface (API) to applications
 C and Java SSL libraries/classes readily
available
Securit 8-61
Could do something like
PGP: K
-
A
-
m .
H( )
-.
K ()
A
KA(H(m))
KS

+ KS( ) .
m + Internet

KS
+
KB( )
. +
KB(KS )
+
KB

 but want to send byte streams & interactive data

 want set of secret keys for entire connection
 want certificate exchange as part of protocol:
handshake phase
Securit 8-62
Toy SSL: a simple secure
channel
 handshake: Alice and Bob use their
certificates, private keys to authenticate
each other and exchange shared secret
 key derivation: Alice and Bob use
shared secret to derive set of keys
 data transfer: data to be transferred is
broken up into series of records
 connection closure: special messages to
securely close connection

Securit 8-63
Toy: a simple handshake
hello

rtificate
public key ce

KB +(MS) = EMS

MS: master secret

EMS: encrypted master secret

Securit 8-64
Toy: key derivation
 considered bad to use same key for more than
one cryptographic operation
• use different keys for message authentication code
(MAC) and encryption
 four keys:
• Kc = encryption key for data sent from client
to server
• Mc = MAC key for data sent from client to
server
• Ks = encryption key for data sent from
server to client
• Ms = MAC key for data sent from server to
client
 keys derived from key derivation function
(KDF) Securit 8-65
Toy: data records
 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?
 instead, break stream in series of records
• each record carries a MAC
• receiver can act on each record as it arrives
 issue: in record, receiver needs to distinguish
MAC from data
• want to use variable-length records

length data MAC

Securit 8-66
Toy: sequence numbers
 problem: attacker can capture and
replay record or re-order records
 solution: put sequence number into
MAC:
 MAC = MAC(Mx, sequence||data)
 note: no sequence number field

 problem: attacker could replay all

records
 solution: use nonce

Securit 8-67
Toy: control information
 problem: truncation attack:
• attacker forges TCP connection close
segment
• one or both sides thinks there is less data
than there actually is.
 solution: record types, with one type for
closure
• type 0 for data; type 1 for closure
 MAC = MAC(Mx, sequence||type||data)

length type data MAC

Securit 8-68
Toy SSL: summary
hello

certificate, nonce
KB +(MS) = EMS
type 0, seq 1, data
bob.com
type 0, seq 2, data

1, data
type 0, seq
encrypted

type 0, seq 3, data

type 1, seq 4, close

lose
type 1, seq 2, c
Securit 8-69
Toy SSL isn’t complete
 how long are fields?
 which encryption protocols?
 want negotiation?
• allow client and server to support different
encryption algorithms
• allow client and server to choose together
specific algorithm before data transfer

Securit 8-70
SSL cipher suite
 cipher suite
• public-key algorithm
common SSL symmetric
• symmetric encryption ciphers
algorithm  DES – Data Encryption
• MAC algorithm Standard: block
 3DES – Triple strength: block
 SSL supports several  RC2 – Rivest Cipher 2: block
cipher suites  RC4 – Rivest Cipher 4: stream
 negotiation: client, SSL Public key encryption
server agree on  RSA
cipher suite
• client offers choice
• server picks one

Securit 8-71
Real SSL: handshake (1)
Purpose
1. server authentication
2. negotiation: agree on crypto
algorithms
3. establish keys
4. client authentication (optional)

Securit 8-72
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 Securit 8-73
Real SSL: handshaking (3)
last 2 steps protect handshake from
tampering
 client typically offers range of algorithms,
some strong, some weak
 man-in-the middle could delete stronger
algorithms from list
 last 2 steps prevent this
• last two messages are encrypted

Securit 8-74
Real SSL: handshaking (4)
 why two random nonces?
 suppose Trudy sniffs all messages
between Alice & Bob
 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
Securit 8-75
 SSL record protocol
data

data data
MAC MAC
fragment fragment

record encrypted record encrypted

header data and MAC header data and MAC

record header: content type; version; length

MAC: includes sequence number, MAC key Mx
fragment: each SSL fragment 214 bytes (~16 Kbytes)
Securit 8-76
SSL record format
1 byte 2 bytes 3 bytes
content
type SSL version length

data

MAC

data and MAC encrypted (symmetric algorithm)

Securit 8-77
Real SSL handshake: ClientHel
lo

connectio handshake:
ServerHello

n hands h

handshak
ak
e
e
:
:
S
C
e
ertificate
rv e rHe lloDone

handshake: ClientK
eyExchange
ChangeCipherS
pec

everything handshake: Finish

e d
henceforth
is encrypted ChangeCipherS
pec

ds ha k e: Finished
han

application_data

ata
application_d

Alert: warning, close

_notify
TCP FIN follows
Securit 8-78
Key derivation
 client nonce, server nonce, and pre-master
secret input into pseudo random-number
generator.
• produces master secret
 master secret and new nonces input into
another random-number generator: “key
block”
• because of resumption: TBD
 key block sliced and diced:
• client MAC key
• server MAC key
• client encryption key
• server encryption key
• client initialization vector (IV)
• server initialization vector (IV)
Securit 8-79
Chapter 8 roadmap
8.1 What is network security?
8.2 Principles of cryptography
8.3 Message integrity and digital
signatures
8.4 End-point authentication
8.5 Securing e-mail
8.6 Securing TCP connections: SSL
8.7 Network layer security: IPsec and
VPNs
8.8 Securing wireless LANs
8.9 Operational security: firewalls and IDS
Securit 8-80
What is network-layer
confidentiality ?
between two network entities:
 sending entity encrypts datagram
payload, payload could be:
• TCP or UDP segment, ICMP message, OSPF
message ….
 all data sent from one entity to other
would be hidden:
• web pages, e-mail, P2P file transfers, TCP SYN
packets …
 “blanket coverage”

Securit 8-81
IPsec services
 data integrity
 origin authentication
 replay attack prevention
 confidentiality

 two protocols providing different service

models:
• AH
• ESP

Securit 8-82
IPsec transport mode

IPsec IPsec

 IPsec datagram emitted and received by

end-system
 protects upper level protocols

Securit 8-83
IPsec – tunneling mode

IPsec IPsec
IPsec IPsec

 edge routers IPsec-  hosts IPsec-aware

aware

Securit 8-84
Two IPsec protocols
 Authentication Header (AH) protocol
• provides source authentication & data
integrity but not confidentiality
 Encapsulation Security Protocol (ESP)
• provides source authentication, data
integrity, and confidentiality
• more widely used than AH

Securit 8-85
Four combinations are
possible!
Host mode Host mode
with AH with ESP

Tunnel mode Tunnel mode

with AH with ESP

most common and

most important

Securit 8-86
Security associations (SAs)
 before sending data, “security
association (SA)” established from
sending to receiving entity
• SAs are simplex: for only one direction
 ending, receiving entitles maintain state
information about SA
• recall: TCP endpoints also maintain state info
• IP is connectionless; IPsec is connection-
oriented!
 how many SAs in VPN w/ headquarters,
branch office, and n traveling
salespeople?

Securit 8-87
Example SA from R1 to R2
headquarters Internet
branch office

200.168.1.100 193.68.2.23

R1 security association
172.16.1/24
R2
172.16.2/24

R1 stores for SA:

 32-bit SA identifier: Security Parameter Index (SPI)
 origin SA interface (200.168.1.100)
 destination SA interface (193.68.2.23)
 type of encryption used (e.g., 3DES with CBC)
 encryption key
 type of integrity check used (e.g., HMAC with MD5)
 authentication key
Securit 8-88
Security Association Database
(SAD)
 endpoint holds SA state in security
association database (SAD), where it
can locate them during processing.
 with n salespersons, 2 + 2n SAs in R1’s
SAD
 when sending IPsec datagram, R1
accesses SAD to determine how to
process datagram.
 when IPsec datagram arrives to R2, R2
examines SPI in IPsec datagram,
indexes SAD with SPI, and processes
Securit 8-89
IPsec datagram
focus for now on tunnel mode with ESP

“enchilada” authenticated
encrypted
new IP ESP original Original IP ESP ESP
header hdr IP hdr datagram payload trl auth

Seq pad next

SPI padding
# length header

Securit 8-90
What happens?
headquarters Internet
branch office

200.168.1.100 193.68.2.23

R1 security association
172.16.1/24
R2
172.16.2/24

“enchilada” authenticated
encrypted
new IP ESP original Original IP ESP ESP
header hdr IP hdr datagram payload trl auth

Seq pad next

SPI padding
# length header
Securit 8-91
R1: convert original datagram to IPsec
datagram

 appends to back of original datagram (which

includes original header fields!) an “ESP trailer”
field.
 encrypts result using algorithm & key specified by
SA.
 appends to front of this encrypted quantity the
“ESP header, creating “enchilada”.
 creates authentication MAC over the whole
enchilada, using algorithm and key specified in
SA;
 appends MAC to back of enchilada, forming
payload;
 creates brand new IP header, with all the classic
IPv4 header fields, which it appends before
payload
Securit 8-92
 Inside the enchilada:
“enchilada” authenticated
encrypted
new IP ESP original Original IP ESP ESP
header hdr IP hdr datagram payload trl auth

Seq pad next

SPI padding
# length header

 ESP trailer: Padding for block ciphers

 ESP header:
• SPI, so receiving entity knows what to do
• Sequence number, to thwart replay attacks
 MAC in ESP auth field is created with shared
secret key
Securit 8-93
IPsec sequence numbers
 for new SA, sender initializes seq. # to 0
 each time datagram is sent on SA:
• sender increments seq # counter
• places value in seq # field
 goal:
• prevent attacker from sniffing and replaying
a packet
• receipt of duplicate, authenticated IP
packets may disrupt service
 method:
• destination checks for duplicates
• doesn’t keep track of all received packets;
instead uses a window
Securit 8-94
Security Policy Database
(SPD)
 policy: For a given datagram, sending
entity needs to know if it should use
IPsec
 needs also to know which SA to use
• may use: source and destination IP address;
protocol number
 info in SPD indicates “what” to do with
arriving datagram
 info in SAD indicates “how” to do it

Securit 8-95
Summary: IPsec services

 suppose Trudy sits somewhere between

R1 and R2. she doesn’t know the keys.
• will Trudy be able to see original contents of
datagram? How about source, dest IP
address, transport protocol, application
port?
• flip bits without detection?
• masquerade as R1 using R1’s IP address?
• replay a datagram?

Securit 8-96
IKE: Internet Key Exchange
 previous examples: manual establishment of
IPsec SAs in IPsec endpoints:
Example SA
SPI: 12345
Source IP: 200.168.1.100
Dest IP: 193.68.2.23
Protocol: ESP
Encryption algorithm: 3DES-cbc
HMAC algorithm: MD5
Encryption key: 0x7aeaca…
HMAC key:0xc0291f…
 manual keying is impractical for VPN with 100s
of endpoints
 instead use IPsec IKE (Internet Key Exchange)

Securit 8-97
IKE: PSK and PKI
 authentication (prove who you are) with
either
• pre-shared secret (PSK) or
• with PKI (pubic/private keys and certificates).
 PSK: both sides start with secret
• run IKE to authenticate each other and to
generate IPsec SAs (one in each direction),
including encryption, authentication keys
 PKI: both sides start with public/private key
pair, certificate
• run IKE to authenticate each other, obtain IPsec
SAs (one in each direction).
• similar with handshake in SSL.
Securit 8-98
IKE phases
 IKE has two phases
• phase 1: establish bi-directional IKE SA
• note: IKE SA different from IPsec SA
• aka ISAKMP security association
• phase 2: ISAKMP is used to securely
negotiate IPsec pair of SAs
 phase 1 has two modes: aggressive
mode and main mode
• aggressive mode uses fewer messages
• main mode provides identity protection and
is more flexible

Securit 8-99
IPsec summary
 IKE message exchange for algorithms,
secret keys, SPI numbers
 either AH or ESP protocol (or both)
• AH provides integrity, source
authentication
• ESP protocol (with AH) additionally
provides encryption
 IPsec peers can be two end systems,
two routers/firewalls, or a router/firewall
and an end system

Securit 8-100
Virtual Private Networks
(VPNs)
motivation:
 institutions often want private networks
for security.
• costly: separate routers, links, DNS
infrastructure.
 VPN: institution’s inter-office traffic is sent
over public Internet instead
• encrypted before entering public Internet
• logically separate from other traffic

Securit 8-101
Virtual Private Networks
(VPNs) IP laptop
public header IPsec
Secure
Internet
header
payloa w/ IPsec
d
e
ad

he
Secur

IP r
paylo

ad
e
salesperson

IPs der
he
in hotel

a
ec
r
IPsec
heade

Se load
pa
cur
r

y
router w/
heade

router w/
IP

e
IPv4 and IPsec IPv4 and IPsec
ad

he
IP er
ylo

ad
pa

pa
er

ylo
he IP
ad

ad
branch office
headquarters
Securit 8-102
Chapter 8 roadmap
8.1 What is network security?
8.2 Principles of cryptography
8.3 Message integrity and digital
signatures
8.4 End-point authentication
8.5 Securing e-mail
8.6 Securing TCP connections: SSL
8.7 Network layer security: IPsec and
VPNs
8.8 Securing wireless LANs
8.9 Operational security: firewalls and IDS
Securit 8-103
WEP design goals
 symmetric key crypto
• confidentiality
• end host authorization
• data integrity
 self-synchronizing: each packet
separately encrypted
• given encrypted packet and key, can decrypt;
can continue to decrypt packets when
preceding packet was lost (unlike Cipher Block
Chaining (CBC) in block ciphers)
 Efficient
• implementable in hardware or software

Securit 8-104
Review: symmetric stream
ciphers
keystream
key keystream
generator

 combine each byte of keystream with byte of

plaintext to get ciphertext:
• m(i) = ith unit of message
• ks(i) = ith unit of keystream
• c(i) = ith unit of ciphertext
• c(i) = ks(i)  m(i) ( = exclusive or)
• m(i) = ks(i)  c(i)
 WEP uses RC4

Securit 8-105
Stream cipher and packet
independence
 recall design goal: each packet separately
encrypted
 if for frame n+1, use keystream from where we
left off for frame n, then each frame is not
separately encrypted
• need to know where we left off for packet n
 WEP approach: initialize keystream with key +
new IV for each packet:

keystream
Key+IVpacket keystreampacket
generator

Securit 8-106
WEP encryption (1)
 sender calculates Integrity Check Value (ICV, four-
byte hash/CRC over data
 each side has 104-bit shared key
 sender creates 24-bit initialization vector (IV),
appends to key: gives 128-bit key
 sender also appends keyID (in 8-bit field)
 128-bit key inputted into pseudo random number
generator to get keystream
 data in frame + ICV is encrypted with RC4:
• bytes of keystream are XORed with bytes of data & ICV
• IV & keyID are appended to encrypted data to create
payload
• payload inserted into 802.11 frame
encrypted

Key
IV data ICV
ID

MAC payload Securit 8-107

 WEP encryption (2)
IV
(per frame)
KS: 104-bit key sequence generator
secret ( for given KS, IV)
symmetric
k1IV k2IV k3IV … kNIV kN+1IV… kN+1IV 802.11 WEP-encrypted data
key IV
header plus ICV
plaintext &
frame data d1 d2 d3 … dN CRC1 … CRC4
plus CRC
c1 c2 c3 … cN cN+1 … cN+4

new IV for each

Figure 7.8-new1: 802.11 WEP protocol

frame

Securit 8-108
WEP decryption overview
encrypted

Key
IV data ICV
ID

MAC payload
 receiver extracts IV
 inputs IV, shared secret key into pseudo
random generator, gets keystream
 XORs keystream with encrypted data to
decrypt data + ICV
 verifies integrity of data with ICV
• note: message integrity approach used here
is different from MAC (message
authentication code) and signatures (using
PKI).
Securit 8-109
 End-point authentication w/
nonce
Nonce: number (R) used only once –in-a-lifetime
How to prove Alice “live”: Bob sends Alice
nonce, R. Alice
must return R, encrypted with shared secret key
“I am Alice”

R
KA-B (R) Alice is live, and
only Alice knows
key to encrypt
nonce, so it
must be Alice!
Securit 8-110
WEP authentication
authentication request

nonce (128 bytes)

nonce encrypted shared key

success if decrypted value equals nonce

Notes:
 not all APs do it, even if WEP is being used
 AP indicates if authentication is necessary in
beacon frame
 done before association
Securit 8-111
Breaking 802.11 WEP
encryption
security hole:
 24-bit IV, one IV per frame, -> IV’s eventually
reused
 IV transmitted in plaintext -> IV reuse detected
attack:
• Trudy causes Alice to encrypt known plaintext d1
d2 d 3 d 4 …
• Trudy sees: ci = di XOR kiIV
• Trudy knows ci di, so can compute kiIV
• Trudy knows encrypting key sequence k1IV k2IV k3IV
…
• Next time IV is used, Trudy can decrypt!
Securit 8-112
 802.11i: improved
security
 numerous (stronger) forms of
encryption possible
 provides key distribution
 uses authentication server separate
from access point

Securit 8-113
 802.11i: four phases of
operation
AP: access point
STA: AS:
wired
client station Authentication
network
server

1 Discovery of
security capabilities

2 STA and AS mutually authenticate, together

generate Master Key (MK). AP serves as “pass through”

3 STA derives
Pairwise Master 3 AS derives
same PMK,
Key (PMK)
sends to AP

4 STA, AP use PMK to derive

Temporal Key (TK) used for message
encryption, integrity
Securit 8-114
EAP: extensible authentication
protocol
 EAP: end-end client (mobile) to
authentication server protocol
 EAP sent over separate “links”
• mobile-to-AP (EAP over LAN)
• AP to authentication server (RADIUS over UDP)

wired
network

EAP TLS
EAP
EAP over LAN (EAPoL) RADIUS
IEEE 802.11 UDP/IP
Securit 8-115
Chapter 8 roadmap
8.1 What is network security?
8.2 Principles of cryptography
8.3 Message integrity and digital
signatures
8.4 End-point authentication
8.5 Securing e-mail
8.6 Securing TCP connections: SSL
8.7 Network layer security: IPsec and
VPNs
8.8 Securing wireless LANs
8.9 Operational security: firewalls and IDS
Securit 8-116
Firewalls
firewall
isolates organization’s internal net from
larger Internet, allowing some packets to
pass, blocking others

administered public
network Internet
trusted “good guys” untrusted “bad guys”
firewall
Securit 8-117
Firewalls: why
prevent denial of service attacks:
 SYN flooding: attacker establishes many bogus
TCP connections, no resources left for “real”
connections
prevent illegal modification/access of internal data
 e.g., attacker replaces CIA’s homepage with
something else
allow only authorized access to inside network
 set of authenticated users/hosts
three types of firewalls:
 stateless packet filters
 stateful packet filters
 application gateways Securit 8-118
Stateless packet filtering
Should arriving
packet be allowed in?
Departing packet let
out?

 internal network connected to Internet via

router firewall
 router filters packet-by-packet, decision to
forward/drop packet based on:
• source IP address, destination IP address
• TCP/UDP source and destination port
numbers
• ICMP message type Securit 8-119
Stateless packet filtering:
example
 example 1: block incoming and outgoing
datagrams with IP protocol field = 17 and
with either source or dest port = 23
• result: all incoming, outgoing UDP flows
and telnet connections are blocked
 example 2: block inbound TCP segments with
ACK=0.
• result: prevents external clients from
making TCP connections with internal
clients, but allows internal clients to
connect to outside.

Securit 8-120
Stateless packet filtering: more
examples
Policy Firewall Setting
No outside Web access. Drop all outgoing packets to any IP
address, port 80
No incoming TCP connections, Drop all incoming TCP SYN packets
except those for institution’s to any IP except 130.207.244.203,
public Web server only. port 80

Prevent Web-radios from eating Drop all incoming UDP packets -

up the available bandwidth. except DNS and router broadcasts.

Prevent your network from being Drop all ICMP packets going to a
used for a smurf DoS attack. “broadcast” address (e.g.
130.207.255.255).
Prevent your network from being Drop all outgoing ICMP TTL expired
tracerouted traffic

Securit 8-121
Access Control Lists
ACL: table of rules, applied top to bottom to
incoming packets: (action, condition) pairs: looks
like OpenFlow forwarding (Ch. 4)!
source dest source dest flag
action protocol
address address port port bit
outside of any
allow 222.22/16 TCP > 1023 80
222.22/16
allow outside of 222.22/16
TCP 80 > 1023 ACK
222.22/16
outside of
allow 222.22/16 UDP > 1023 53 ---
222.22/16
allow outside of 222.22/16
UDP 53 > 1023 ----
222.22/16
deny all all all all all all

Securit 8-122
Stateful packet filtering
 stateless packet filter: heavy handed tool
• admits packets that “make no sense,” e.g.,
dest port = 80, ACK bit set, even though no
TCP connection established:
source dest source dest flag
action protocol
address address port port bit
allow outside of 222.22/16
TCP 80 > 1023 ACK
222.22/16

 stateful packet filter: track status of every TCP

connection
• track connection setup (SYN), teardown (FIN):
determine whether incoming, outgoing packets
“makes sense”
• timeout inactive connections at firewall: noSecurit 8-123
Stateful packet filtering
ACL augmented to indicate need to check
connection state table before admitting packet

source dest source dest flag check

action proto
address address port port bit conxion
outside of any
allow 222.22/16 TCP > 1023 80
222.22/16

allow outside of 222.22/16

TCP 80 > 1023 ACK x
222.22/16

outside of
allow 222.22/16 UDP > 1023 53 ---
222.22/16

allow outside of 222.22/16 x

UDP 53 > 1023 ----
222.22/16

deny all all all all all all

Securit 8-124
 Application gateways
 filter packets on host-to-gateway
application data as telnet session application
gateway
well as on IP/TCP/UDP router and filter
fields.
 example: allow select
internal users to gateway-to-remote
telnet outside host telnet session

1. require all telnet users to telnet through

gateway.
2. for authorized users, gateway sets up telnet
connection to dest host. Gateway relays data
between 2 connections
3. router filter blocks all telnet connections not Securit 8-125
Limitations of firewalls,
gateways
 IP spoofing: router  filters often use all or
can’t know if data nothing policy for
“really” comes from UDP
claimed source  tradeoff: degree of
 if multiple app’s. communication with
need special outside world, level
treatment, each has of security
own app. gateway  many highly
 client software must protected sites still
know how to contact suffer from attacks
gateway.
• e.g., must set IP
address of proxy in
Web browser

Securit 8-126
Intrusion detection
systems
 packet filtering:
• operates on TCP/IP headers only
• no correlation check among sessions
 IDS: intrusion detection system
• deep packet inspection: look at packet
contents (e.g., check character strings in
packet against database of known virus,
attack strings)
• examine correlation among multiple packets
• port scanning
• network mapping
• DoS attack

Securit 8-127
Intrusion detection
systems
multiple IDSs: different types of checking
at different locations

firewall

internal
network
Internet

IDS Web DNS

server FTP server
sensors server demilitarized
zone

Securit 8-128
Network Security
(summary)
basic techniques…...
• cryptography (symmetric and public)
• message integrity
• end-point authentication
…. used in many different security scenarios
• secure email
• secure transport (SSL)
• IP sec
• 802.11
operational security: firewalls and IDS

Securit 8-129