0% found this document useful (0 votes)
12 views51 pages

Week 12

The document discusses various aspects of network security, focusing on denial-of-service attacks, firewalls, and cryptography. It explains reflection attacks, packet filtering methods, and the importance of firewalls in preventing unauthorized access and denial-of-service attacks. Additionally, it covers symmetric and public key cryptography, including algorithms like RSA and the concept of digital signatures.

Uploaded by

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

Week 12

The document discusses various aspects of network security, focusing on denial-of-service attacks, firewalls, and cryptography. It explains reflection attacks, packet filtering methods, and the importance of firewalls in preventing unauthorized access and denial-of-service attacks. Additionally, it covers symmetric and public key cryptography, including algorithms like RSA and the concept of digital signatures.

Uploaded by

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

Denial-of-Service Attacks: Reflection

— Reflection
— Cause one non-compromised host to attack another
— E.g., host A sends DNS request or TCP SYN with source V to
server R. R sends reply to V

Attacker (A) Reflector (R)


DATA V R

Internet

Victim (V)
432
Denial-of-Service Attacks: Reflection
— Reflection
— Cause one non-compromised host to attack another
— E.g., host A sends DNS request or TCP SYN with source V to
server R. R sends reply to V

Attacker (A) Reflector (R)

Internet
V R DATA

Victim (V)
433
IP Traceback
— Routers probabilistically tag packets
with an identifier
— Destination can infer path to true
source after receiving enough
packets

434
Firewalls
firewall
isolates organization’s internal net from larger Internet,
allowing some packets to pass, blocking others.

administered public
network Internet

firewall

435
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)
two types of firewalls:
• packet-filtering: stateless vs stateful
• application-level

436
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
— TCP SYN and ACK bits
437
Packet Filtering Example
— Example 1: block incoming and outgoing datagrams with IP
protocol field = 17 and with either source or dest port = 23.
— All incoming and outgoing UDP traffic and telnet connections
are blocked.
— Example 2: Block inbound TCP segments with ACK=0.
— Prevents external clients from making TCP connections with
internal clients, but allows internal clients to connect to
outside.

438
Stateful packet filtering
— stateless packet filter: heavy handed tool
— admits packets that “make no sense,” e.g., source 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

v 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: no longer admit packets

439
Stateful packet filtering
v Access control list (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

5-440
Application gateways host-to-gateway
gateway-to-remote
host telnet session

telnet session

— filters packets on application data


application router and filter
as well as on IP/TCP/UDP gateway

fields.
— example: allow selected internal
users to telnet outside.

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 originating from
gateway.
441
Limitations of firewalls and gateways
— IP spoofing: router can’t know — filters often use all or nothing
if data “really” comes from policy for UDP.
claimed source — tradeoff: degree of
— if multiple app’s. need special communication with outside
treatment, each has own app. world, level of security
gateway. — many highly protected sites
— For application gateways, still suffer from attacks.
client software must know
how to contact gateway.
— e.g., must set IP address of proxy
in Web browser

442
Outline
— Attacks and counter measures
— Security primer
— Security in different layers

443
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, etc.

Alice Bob
channel data, control
messages

secure secure
data data
sender receiver

Trudy

1-444
There are bad guys (and girls) out there!
Q:What can a “bad guy” do?
A: a lot!
— eavesdrop: intercept messages
— actively insert/modify 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 overloading resources)

more on this later ……

445
The language of cryptography
Alice’s Bob’s
KA encryption KB decryption
key key

plaintext encryption ciphertext decryption plaintext


algorithm algorithm

symmetric key crypto: sender, receiver keys identical


public-key crypto: encryption key public, decryption key secret (private)

446
Symmetric key cryptography
substitution cipher: substituting one thing for another
— monoalphabetic cipher: substitute one letter for another
plaintext: abcdefghijklmnopqrstuvwxyz

ciphertext: mnbvcxzasdfghjklpoiuytrewq

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


ciphertext: nkn. s gktc wky. mgsbc

Q: How hard to break this simple cipher?:


q brute force (how hard?)
q other?

447
Symmetric key cryptography
K K
A-B A-B

plaintext encryption ciphertext decryption plaintext


message, m algorithm algorithm
K (m) m=K (K (m) )
A-B A-B A-B

symmetric key crypto: Bob and Alice share the same (symmetric) key: KA-B
— e.g., key is knowing substitution pattern in mono alphabetic substitution
cipher
— Q: how do Bob and Alice agree on key value?

448
Symmetric key crypto: DES
DES: Data Encryption Standard
— US encryption standard [NIST 1993]
— 56-bit symmetric key, 64-bit plaintext input
— How secure is DES?
— DES Challenge III was a joint effort between distributed.net and
Deep Crack. The key was found in just 22 hours 15 minutes in
January 1999, and the plaintext was "See you in Rome (second AES
Conference, March 22-23, 1999)”
— making DES more secure:
— use three keys sequentially (3-DES) on each datum
— use cipher-block chaining

449
AES: Advanced Encryption Standard
— new (Nov. 2001) symmetric-key NIST standard, replacing
DES
— processes data in 128 bit blocks
— 128, 192, or 256 bit keys
— If brute force decryption (try each key) taking 1 sec on DES,
takes 149 trillion years for AES

At present, there is no known practical attack that would


allow someone without knowledge of the key to read data
encrypted by AES when correctly implemented.
450
Key Distribution Center (KDC)
— Alice, Bob need shared symmetric key.
— KDC: server shares different secret key with each registered user
(many users)
— Alice, Bob know own symmetric keys, KA-KDC , KB-KDC , for
communicating with KDC.
KDC

KA-KDC KP-KDC
KX-KDC
KP-KDC KB-KDC
KY-KDC

KZ-KDC
KA-KDC KB-KDC

8-451
Key Distribution Center (KDC)
Q: How does KDC allow Bob, Alice to determine shared symmetric secret
key to communicate with each other?

KDC
KA-KDC(A,B) generates
R1

KA-KDC(R1, KB-KDC(A,R1) )
Alice Bob knows to
knows use R1 to
R1 KB-KDC(A,R1)
communicate
with Alice

Alice and Bob communicate: using R1 as


session key for shared symmetric encryption

452
Diffie-Hellman Key Agreement Protocol
Allow Alice and Bob to agree on a shared secret in a public channel
(against passive, i.e., eavesdropping only adversaries)
Setup: a prime p and a base g, both public.

ga mod p
gb mod p

Pick random, secret a Pick random, secret b

Compute and send ga mod p Compute and send gb mod p

453 K = (ga mod p)b mod p= gab mod p = (gb mod p)a mod p
Diffie-Hellman Example
— Alice and Bob agree on p = 23 and g = 5.
— Alice chooses a = 6 and sends 56 mod 23 = 8
— Bob chooses b = 15 and sends 515 mod 23 = 19
— Alice computes 196 mod 23 = 2.
— Bob computes 815 mod 23 = 2.
— Then 2 is the shared secret.

— Assumption: Finding 5?? mod 23 = 8 and 5?? mod 23 = 19 are


hard

454
Public Key Cryptography
public key cryptography
— public encryption key known to all
— private decryption key known only to receiver

1-455
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 = K -(K +(m))
B B

456
Public key encryption algorithms
Requirements:

1 need KB+( ) and KB-( ) such that


- +
K B (KB (m)) = m
2 given public key KB+ , it should be
impossible to compute private key KB-

RSA: Rivest, Shamir, Adelson algorithm

457
RSA: Choosing keys
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).

K+ K-
B B
458
RSA: Encryption, decryption
0. Given (n,e) and (n,d) as computed above
+ -
K K
B B
1.To encrypt bit pattern, m, compute
c = me mod n (i.e., remainder when me is divided by n)

2.To decrypt received bit pattern, c, compute


m = cd mod n (i.e., remainder when cd is divided by n)

Magic
m = (me mod n)d mod n
happens!
c

459
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)

e e
letter m m c = m mod n
encrypt:
L 12 1524832 17

d d
c c m = c mod n letter
decrypt:
17 481968572106750915091411825223071697 12 L

460
RSA: another important property
The following property will be very useful later:

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

use public key use private key


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

Result is the same!

462
Digital Signatures
Application of public key crypto
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

463
Digital Signatures
Simple digital signature for message m:
— Bob signs m by encrypting with his private key KB-, creating
-
“signed” message, KB(m)

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

464
Digital Signatures (more)
-
— Suppose Alice receives msg m, digital signature KB(m)
— Alice verifies m signed by Bob by applying Bob’s public key K+B to
- + -
KB(m) then checks KB(KB(m) ) = m.
+ -
— If KB(KB(m) ) = m, whoever signed m must have used Bob’s private
key.
Alice thus verifies that:
Bob signed m.
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.

465
Message Digests large
message
H: Hash
Function
m
Computationally expensive to
public-key-encrypt long
H(m)
messages
Goal: fixed-length, easy- to- Hash function properties:
compute digital “fingerprint” — many-to-1
— apply hash function H to m, get
— produces fixed-size msg digest
fixed size message digest, H(m). (fingerprint)
— given message digest x,
computationally infeasible to
find m such that x = H(m)

466
Digital signature = signed message digest
Alice verifies signature and integrity of
Bob sends digitally signed digitally signed message:
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
?
8-467
8-468
Hash Function Algorithms
— MD5 hash function widely used (RFC 1321)
— computes 128-bit message digest in 4-step process.
— In 1996 a flaw was found in the design of MD5 L -- “should
be considered cryptographically broken and unsuitable for
further use”
— SHA-2, SHA-3
— 224, 256, 384 or 512 bits in digests

469
Certification for Public Key
Symmetric key problem: Public key problem:
— How do two entities establish — When Alice obtains Bob’s
shared secret key over network? public key (from web site, e-
Solution: mail, diskette), how does she
know it is Bob’s public key, not
— trusted key distribution center
Trudy’s?
(KDC) acting as intermediary
between entities Solution:
— DH — trusted certification authority
(CA)

470
Certification Authorities
— Certification authority (CA): binds public key to particular entity,
E.
— E (person, server) 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 encrypt
+
public + KB
key KB
CA
private - certificate for
Bob’s K CA
identifying key Bob’s public key,
information signed by CA
8-471
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
— Agree or not?

+ Decrypt Bob’s
KB public
+
KB key

CA
public +
K CA
key

8-472
What we learned so far?
— Message confidentiality: shared key or public key crypto
— Message integrity: hash
— Authenticity of a digital message: digital signature

What about authenticity of sender/receiver?


— ARP poisoning
— phishing attacks

473
Authentication
Goal: Bob wants Alice to “prove” her identity to him

Protocol ap1.0: Alice says “I am Alice”

“I am Alice”
Failure scenario??

474
Authentication
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
herself to be Alice
“I am Alice”

475
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??

476
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 address
Alice’s
IP address
“I am Alice”

477
Authentication: another try
Protocol ap3.0: Alice says “I am Alice” and sends her
secret password to “prove” it.

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

Failure scenario??
Alice’s
OK
IP addr

478
Authentication: another try
Protocol ap3.0: Alice says “I am Alice” and sends her
secret password to “prove” it.

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

479
Authentication: yet another try
Protocol ap3.1: Alice says “I am Alice” and sends her
encrypted secret password to “prove” it.

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

Failure scenario??
Alice’s
OK
IP addr

480
Authentication: another try
Protocol ap3.1: Alice says “I am Alice” and sends her
encrypted secret password to “prove” it.

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

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

481
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 key

“I am Alice”

K (R) Alice is live, and


A-B only Alice knows
key to encrypt
nonce, so it must
Failures, drawbacks? be Alice!
482
Authentication: ap5.0
ap4.0 requires shared symmetric key
— can we authenticate using public key techniques?
ap5.0: use nonce, public key cryptography + -
K (K (R)) = R
A A
“I am Alice” and knows only Alice
could have the private
R key, that encrypted R
-
K (R) such that
A + -
K (K (R)) = R
A A
“send me your certificate”
digital Alic’s
signature +
public
+ (decrypt) KA key
KA
+
K CA
483

You might also like