Vous êtes sur la page 1sur 59

Network Security

8: Network Security 8-1

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
8: Network Security 8-2

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

data

channel
secure
sender

Bob

data, control
messages

secure
receiver

data

Trudy
8: Network Security 8-3

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?

8: Network Security 8-4

There are bad guys (and girls) out there!


Q: What can a bad guy do?
A: a lot!

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 overloading resources)

8: Network Security 8-5

The language of cryptography


Alices
K encryption
A
key
plaintext

encryption
algorithm

Bobs
K decryption
B key
ciphertext

decryption plaintext
algorithm

symmetric key crypto: sender, receiver keys identical


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

8: Network Security 8-6

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

8: Network Security 8-7

Symmetric key cryptography


KA-B

KA-B
plaintext
message, m

encryption ciphertext
algorithm
K (m)
A-B

decryption plaintext
algorithm
m=K

A-B

( KA-B(m) )

symmetric key crypto: Bob and Alice share know 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?
8: Network Security 8-8

Public Key Cryptography


symmetric key crypto
requires sender,
receiver know shared
secret key
Q: how to agree on key
in first place
(particularly if never
met)?

public key cryptography


radically different
approach [DiffieHellman76, RSA78]
sender, receiver do
not share secret key
public encryption key
known to all
private decryption
key known only to
receiver
8: Network Security 8-9

Public key cryptography


+ Bobs public
B key

plaintext
message, m

encryption ciphertext
algorithm
+
K (m)
B

- Bobs private
B key

decryption plaintext
algorithm message
+
m = K B(K (m))
B

8: Network Security 8-

Public key encryption algorithms


Requirements:
+

1 need K B( ) and K - ( ) such that


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

given public key K , it should+be impossible to


compute private key K
B

RSA: Rivest, Shamir, Adelson algorithm


8: Network Security8-11

RSA: another important property


The following property will be very useful later:
-

K (K (m))

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

use public key


first, followed
by private key

use private key


first, followed
by public key

Result is the same!


8: Network Security 8-

Authentication
Goal: Bob wants Alice to prove her identity
to him
Protocol ap1.0: Alice says I am Alice
I am Alice

Failure scenario??

8: Network Security 8-

Authentication
Goal: Bob wants Alice to prove her identity
to him
Protocol ap1.0: Alice says I am Alice

I am Alice

in a network,
Bob can not see
Alice, so Trudy simply
declares
herself to be Alice
8: Network Security 8-

Authentication: another try


Protocol ap2.0: Alice says I am Alice in an IP packet
containing her source IP address

Alices
I am Alice
IP address

Failure scenario??

8: Network Security 8-

Authentication: another try


Protocol ap2.0: Alice says I am Alice in an IP packet
containing her source IP address

Alices
IP address

Trudy can create


a packet
spoofing
I am Alice
Alices address

8: Network Security 8-

Authentication: another try


Protocol ap3.0: Alice says I am Alice and sends her
secret password to prove it.

Alices
Alices
Im Alice
IP addr password
Alices
IP addr

OK

Failure scenario??

8: Network Security 8-

Authentication: another try


Protocol ap3.0: Alice says I am Alice and sends her
secret password to prove it.

Alices
Alices
Im Alice
IP addr password
Alices
IP addr

OK

playback attack: Trudy


records Alices packet
and later
plays it back to Bob

Alices
Alices
Im Alice
IP addr password

8: Network Security 8-

Authentication: yet another try


Protocol ap3.1: Alice says I am Alice and sends her
encrypted secret password to prove it.

Alices encrypted
Im Alice
IP addr password
Alices
IP addr

OK

Failure scenario??

8: Network Security 8-

Authentication: another try


Protocol ap3.1: Alice says I am Alice and sends her
encrypted secret password to prove it.

Alices encrypted
Im Alice
IP addr password
Alices
IP addr

record
and
playback
still works!

OK

Alices encrypted
Im Alice
IP addr password

8: Network Security 8-

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
R
KA-B(R)
Failures, drawbacks?

Alice is live, and


only Alice knows
key to encrypt
nonce, so it must
be Alice!

8: Network Security 8-

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
R

Bob computes
+ -

K A (R)

send me your public key

KA

KA(KA (R)) = R

and knows only Alice


could have the private
key, that encrypted R
such that
+ K (K (R)) = R
A A

8: Network Security 8-

ap5.0: security hole


Man (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

K (R)
A

Send me your public key

+
K
T

Send me your public key

+
K
A

- +
m = K (K (m))
A A

+
K (m)
A

Trudy gets
- +
m = K (K (m))
T Alice
sends T
m to

+
K (m)
T

encrypted with
Alices public key

8: Network Security 8-

ap5.0: security hole


Man (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!

8: Network Security 8-

Digital Signatures
Cryptographic technique analogous to handwritten 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

8: Network Security 8-

Digital Signatures
Simple digital signature for message m:
Bob signs m by encrypting with his private key
-

KB, creating signed message, KB(m)

Bobs message, m
Dear Alice
Oh, how I have
missed you. I think of
you all the time!
(blah blah blah)

K B Bobs private

key

Public key
encryption
algorithm

K B(m)
Bobs message,
m, signed
(encrypted) with
his private key

Bob

8: Network Security 8-

Digital Signatures (more)


-

Suppose Alice receives msg m, digital signature K B(m)


Alice verifies m signed by Bob by applying Bobs
+

public key KB to KB(m) then checks KB(KB(m) ) = m.


+

If KB(KB(m) ) = m, whoever signed m must have used

Bobs 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 K B(m) to court and prove
that Bob signed m.

8: Network Security 8-

Message Digests
Computationally expensive
to public-key-encrypt
long messages
Goal: fixed-length, easy- tocompute digital
fingerprint
apply hash function H to
m, get fixed size message
digest, H(m).

large
message
m

H: Hash
Function

H(m)

Hash function properties:


produces fixed-size msg
digest (fingerprint)
given message digest x,
computationally
infeasible to find m such
that x = H(m)
8: Network Security 8-

Digital signature = signed message digest


Alice verifies signature and
integrity of digitally signed
message:

Bob sends digitally signed


message:
large
message
m

H: Hash
function

Bobs
private
key

KB

encrypted
msg digest

H(m)
digital
signature
(encrypt)
encrypted
msg digest

KB(H(m))

large
message
m
H: Hash
function

H(m)

KB(H(m))

Bobs
public
key

KB

digital
signature
(decrypt)

H(m)

equal
?
8: Network Security 8-

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

8: Network Security 8-

Trusted Intermediaries
Symmetric key problem:

Public key problem:

How do two entities

When Alice obtains

establish shared secret


key over network?

Solution:
trusted key distribution

center (KDC) acting as


intermediary between
entities

Bobs public key (from


web site, e-mail,
diskette), how does she
know it is Bobs public
key, not Trudys?

Solution:
trusted certification

authority (CA)

8: Network Security 8-

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
KP-KDC

KB-KDC

KA-KDC

KX-KDC
KY-KDC

KB-KDC

KZ-KDC

8: Network Security 8-

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 Es public key digitally signed by CA
CA says this is Es public key
Bobs
public
key

Bobs
identifying
information

KB

digital
signature
(encrypt)
CA
private
key

K-

CA

KB
certificate for
Bobs public key,
signed by CA

8: Network Security 8-

Certification Authorities
When Alice wants Bobs public key:

gets Bobs certificate (Bob or elsewhere).


apply CAs public key to Bobs certificate, get
Bobs public key

+
KB

digital
signature
(decrypt)
CA
public
key

Bobs
public
+
K B key

+
K CA

8: Network Security 8-

A certificate contains:
Serial number (unique to issuer)
info about certificate owner, including algorithm

and key value itself (not shown)

info about certificate

issuer
valid dates
digital signature by issuer

8: Network Security 8-

Secure sockets layer (SSL)


transport layer

security to any TCPbased app using SSL


services.
used between Web
browsers, servers for
e-commerce (shttp).
security services:

server authentication
data encryption
client authentication
(optional)

server authentication:
SSL-enabled browser
includes public keys for
trusted CAs.
Browser requests
server certificate,
issued by trusted CA.
Browser uses CAs
public key to extract
servers public key from
certificate.
check your browsers

security menu to see


its trusted CAs.

8: Network Security 8-

SSL (continued)
Client

Server
Open secure socket
Certificate (CA signed Pub Key)

Verify CA trusted
Extract Server Pub Key
Generate symmetric Session Key
Encrypt Session Key with Server Pub Key
Encrypted Session Key
Extract Session Key
(using Private Key)
In Java all of this happens behind the scenes!
SSLSocket s = (SSLSocket)sslFact.createSocket(host, port);

8: Network Security 8-

SSL Observations
Previous example does not
Show how public/private key pairs are
generated
Manually

Enable the Server to authenticate the client


Client can use trusted certificate, or another scheme
such as passwords

Show how the Server receives a signed


certificate
CA!

8: Network Security 8-

Project 3

Project 3 Overview

Secure your time/date client and server


Mutual authentication between client and server
Implement a trusted CA that can generate
certificates for the client and server (by signing
their public keys)

Offline, manual tasks


1.
2.
3.

CA, Client, and Server generate public/private keys


CA generates self-signed certificate
Client and Server import CA certificate
8: Network Security 8-

Project 3
CA behavior
1. Accepts connections from clients does not
require SSL-based client authentication
Note: The T/D Server can act as a client when connecting
to the CA
2.
3.
4.
5.

Authenticates clients using passwords can be sent


in plaintext
Receives Public Key from client
Generates certificate by signing client Public Key
with CA Private Key
Returns certificate to client
8: Network Security 8-

Project 3
Server behavior
1. Connect to trusted CA
2. Send password for CA authentication of Server
3. Send Public Key to CA
4. Receive certificate from CA
5. Wait for secure client connection
6. Require client authentication client must have CAsigned certificate
7. Allow client to request time or date
8. Send response

8: Network Security 8-

Project 3
Client behavior
1. Connect to trusted CA
2. Send password for CA authentication of Server
3. Send Public Key to CA
4. Receive certificate from CA
5. Securely connect to server
6. Request time or date
7. Receive/display response

8: Network Security 8-

Java and SSL


keytool command line tool used to generate

public/private keys, generate self-signed


certificates, and import other trusted
certificates
javax.net.ssl java.security java.security.[spec,cert]
org.bouncycastle.[x509,jce,asn1]
KeyManager object that stores my
keys/certificates

used during handshake with server

TrustManager object that stores trusted

certificates

can be initialized from same file as KeyStore

8: Network Security 8-

Java and SSL


SSLContext context that specifies keys,

certificates, and trusted certificates

initialize context with appropriate KeyManagers


and TrustManagers

SSLSocketFactory/SSLServerSocketFact

ory will create socket based on given


context

default context will not contain appropriate


certificates

SSLSocket performs regular socket-like

communication only with encryption

8: Network Security 8-

Java and SSL


CertificateFactory can create a

certificate from an InputStream

used to create certificate sent from CA

Certificate, PublicKey, PrivateKey what

youd expect

8: Network Security 8-

Java and SSL


X509Certificate certificate based on X.509

standard

defines structure of certificate, etc

X509Name object to represent distinguished

name of subject/issuer of certificate


X509EncodedKeySpec/KeyFactory create public
key from byte stream
X509V3CertificateGenerator use to generate
certificate

use specified private key to generate certificate for


holder of specified public key

8: Network Security 8-

Firewalls
firewall
isolates organizations internal net from larger
Internet, allowing some packets to pass,
blocking others.

public
Internet

administered
network
firewall

8: Network Security 8-

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 CIAs homepage with
something else
allow only authorized access to inside network (set of
authenticated users/hosts)
two types of firewalls:
application-level
packet-filtering

8: Network Security 8-

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

8: Network Security 8-

Packet Filtering
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 flows 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.

8: Network Security 8-

Application gateways
Filters packets on

application data as well as


on IP/TCP/UDP fields.
Example: allow select
internal users to telnet
outside.

host-to-gateway
telnet session
application
gateway

gateway-to-remote
host telnet session

router and filter

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.

8: Network Security 8-

Internet security threats


Mapping:
before attacking: case the joint find out
what services are implemented on network
Use ping to determine what hosts have
addresses on network
Port-scanning: try to establish TCP connection
to each port in sequence (see what happens)
nmap (http://www.insecure.org/nmap/) mapper:
network exploration and security auditing

Countermeasures?
8: Network Security 8-

Internet security threats


Mapping: countermeasures
record traffic entering network
look for suspicious activity (IP addresses, pots
being scanned sequentially)

8: Network Security 8-

Internet security threats


Packet sniffing:
broadcast media
promiscuous NIC reads all packets passing by
can read all unencrypted data (e.g. passwords)
e.g.: C sniffs Bs packets

src:B dest:A

payload

Countermeasures?
8: Network Security 8-

Internet security threats


Packet sniffing: countermeasures

all hosts in organization run software that checks periodically if


host interface in promiscuous mode.
one host per segment of broadcast media (switched Ethernet at
hub)

src:B dest:A

payload

8: Network Security 8-

Internet security threats


IP Spoofing:
can generate raw IP packets directly from application, putting any value
into IP source address field
receiver cant tell if source is spoofed
e.g.: C pretends to be B

A
src:B dest:A

Countermeasures?

payload

B
8: Network Security 8-

Internet security threats


IP Spoofing: ingress filtering
routers should not forward outgoing packets with invalid source
addresses (e.g., datagram source address not in routers network)
great, but ingress filtering can not be mandated for all networks

A
src:B dest:A

payload

B
8: Network Security 8-

Internet security threats


Denial of service (DOS):
flood of maliciously generated packets swamp receiver
Distributed DOS (DDOS): multiple coordinated sources swamp receiver
e.g., C and remote host SYN-attack A

SYN

SYN
SYN

SYN

SYN

B
Countermeasures?

SYN
SYN

8: Network Security 8-

Internet security threats


Denial of service (DOS): countermeasures

filter out flooded packets (e.g., SYN) before reaching host: throw
out good with bad
traceback to source of floods (most likely an innocent,
compromised machine)

SYN

SYN
SYN

SYN

SYN

B
SYN
SYN

8: Network Security 8-

Vous aimerez peut-être aussi