Transcript Lecture #25

Lecture 25
Secure Communications
CPE 401 / 601
Computer Network Systems
slides are modified from Jim Kurose & Keith Ross and Dave Hollinger
Secure Protocols
 There are a growing number of applications for secure
protocols



email
electronic commerce
electronic voting
 Many application protocols include the use of
cryptography as part of application level protocol


The Cryptographic scheme employed is part of the protocol
If stronger cryptographic tools become available we need to
change the protocol
Secure Communications
2
Message Integrity
Bob receives msg from Alice, wants to ensure:
 message originally came from Alice
 message not changed since sent by Alice
Cryptographic Hash:
 takes input m, produces fixed length value, H(m)
 e.g., as in Internet checksum
 computationally infeasible to find two different
messages, x, y such that H(x) = H(y)


equivalently: given m = H(x), (x unknown), can not determine x.
note: Internet checksum fails this requirement!
Secure Communications
3
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
I O U 1
0 0 . 9
9 B O B
ASCII format
49 4F 55 31
30 30 2E 39
39 42 4F 42
B2 C1 D2 AC
message
I O U 9
0 0 . 1
9 B O B
ASCII format
49 4F 55 39
30 30 2E 31
39 42 4F 42
B2 C1 D2 AC
different messages
but identical checksums!
Secure Communications
4
Message Authentication Code
(shared secret)
s
H(.)
(message)
m
append
H(.)
m
H(m+s)
public
Internet
H(m+s)
m
compare
H(m+s)
H(m+s)
s
(shared secret)
Secure Communications
5
MACs in practice
 MD5 hash function widely used (RFC 1321)
computes 128-bit MAC in 4-step process.
 arbitrary 128-bit string x, appears difficult to
construct msg m whose MD5 hash is equal to x

• recent (2005) attacks on MD5
 SHA-1 is also used
US standard [NIST, FIPS PUB 180-1]
 160-bit MAC

Secure Communications
6
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
Secure Communications
7
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 message, m
Dear Alice
Oh, how I have missed
you. I think of you all the
time! …(blah blah blah)
Bob
K B Bob’s private
key
public key
encryption
algorithm
-
K B(m)
Bob’s message,
m, signed
(encrypted) with
his private key
Secure Communications
8
Digital Signatures (more)
-
 suppose Alice receives msg m, digital signature KB(m)
 Alice verifies m signed by Bob by applying Bob’s
+
-
+
-
public key KB 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.
Secure Communications
9
Digital signature = signed MAC
Alice verifies signature and
integrity of digitally signed
message:
Bob sends digitally signed
message:
large
message
m
H: hash
function
Bob’s
private
key
+
-
KB
encrypted
msg digest
H(m)
digital
signature
(encrypt)
encrypted
msg digest
KB(H(m))
large
message
m
H: hash
function
KB(H(m))
Bob’s
public
key
+
KB
digital
signature
(decrypt)
H(m)
H(m)
equal
?
Secure Communications
10
Public Key Certification
public key problem:
 When Alice obtains Bob’s public key (from web
site, e-mail, diskette), how does she know it is
Bob’s public key, not Trudy’s?
solution:
 trusted certification authority (CA)
Secure Communications
11
Certification Authorities
 Certification Authority (CA): binds public key to
particular entity, E.
 E 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
public
key
Bob’s
identifying
information
+
KB
digital
signature
(encrypt)
CA
private
key
K-
CA
-
+
K CA(KB )
+
KB
certificate for
Bob’s public key,
signed by CA
Secure Communications
12
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

+
KB
-
+
K CA(KB )
digital
signature
(decrypt)
CA
public
key
Bob’s
public
+
key
KB
+
K CA
Secure Communications
13
Secure e-mail

Alice wants to send confidential e-mail, m, to Bob.
KS
m
K (.)
S
+
KS
+
.
K B( )
+
KS(m )
KS(m )
+
KB(KS )
Internet
.
KS( )
-
KS
+
K B( )
-
KB(KS )
m
.
-
KB
KB
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.
Secure Communications
14
Secure e-mail

Alice wants to send confidential e-mail, m, to Bob.
KS
m
K (.)
S
+
KS
+
.
K B( )
+
KS(m )
KS(m )
+
KB(KS )
Internet
.
KS( )
-
KS
+
K B( )
-
KB(KS )
m
.
-
KB
KB
Bob:
 uses his private key to decrypt and recover KS
 uses KS to decrypt KS(m) to recover m
Secure Communications
15
Secure e-mail (continued)
• Alice wants to provide sender authentication
message integrity.
+
-
KA
m
H(.)
-
-
-
KA(H(m))
KA(H(m))
.
KA( )
+
Internet
m
-
KA
+
.
KA( )
H(m )
compare
m
.
H( )
H(m )
• Alice digitally signs message.
• sends both message (in the clear) and digital signature.
Secure Communications
16
Secure e-mail (continued)
• Alice wants to provide secrecy, sender authentication,
message integrity.
-
KA
m
.
H( )
-
-
KA(H(m))
.
KA( )
+
KS
.
KS( )
+
m
KS
+
.
K B( )
+
Internet
+
KB(KS )
KB
Alice uses three keys: her private key, Bob’s public
key, newly created symmetric key
Secure Communications
17
Pretty good privacy (PGP)
 Internet e-mail encryption
scheme,

de-facto standard.
 uses





symmetric key cryptography,
public key cryptography,
hash function, and
digital signature as described
.
 provides



secrecy,
sender authentication,
integrity.
A PGP signed message:
---BEGIN PGP SIGNED MESSAGE--Hash: SHA1
Bob:My husband is out of town
tonight.Passionately yours,
Alice
---BEGIN PGP SIGNATURE--Version: PGP 5.0
Charset: noconv
yhHJRHhGJGhgg/12EpJ+lo8gE4vB3mqJ
hFEvZP9t6n7G6m5Gw2
---END PGP SIGNATURE---
Secure Communications
18
Secure sockets layer (SSL)
 provides transport layer security to any TCP-based
application using SSL services.

e.g., between Web browsers, servers for e-commerce
 security services:
 server authentication,
 data encryption,
 client authentication (optional)
Application
TCP
socket
Application
TCP
SSL sublayer
TCP
IP
IP
TCP API
SSL
socket
TCP enhanced with SSL
Secure Communications
19
SSL: three phases
1. Handshake:
 Bob establishes TCP
connection to Alice
 authenticates Alice via
CA signed certificate
 sends master secret
key to Alice


encrypted with Alice’s
public key
nonce exchange not
shown
create
Master
Secret
(MS)
decrypt using
KAto get MS
Secure Communications
20
SSL: three phases
2. Key Derivation:
 Alice, Bob use shared secret (MS) to generate 4
keys:




EB: Bob->Alice data encryption key
EA: Alice->Bob data encryption key
MB: Bob->Alice MAC key
MA: Alice->Bob MAC key
 encryption and MAC algorithms negotiable
between Bob, Alice
Secure Communications
21
SSL: three phases
3. Data transfer
TCP byte stream
b1b2b3 … bn
block n bytes together
d
.
MB
H( )
d
EB
H(d)
.
H( ) SSL
SSL record
format
Type Ver Len
d
H(d)
d
H(d)
seq. #
compute
MAC
encrypt d,
MAC, SSL
seq. #
unencrypted encrypted using EB
Secure Communications
22
HTTPS Usage
 HTTPS is HTTP running over SSL.

used for most secure web transactions.

HTTPS server usually runs on port 443.


Include notion of verification of server via a
certificate.
Central trusted source of certificates.
Secure Communications
23
IPsec: Network Layer Security
 network-layer secrecy:
sending host encrypts the
data in IP datagram
 TCP and UDP segments;
ICMP and SNMP messages.
 network-layer authentication
 destination host can
authenticate source IP
address
 two principal protocols:
 authentication header (AH)
protocol
 encapsulation security
payload (ESP) protocol

 for both AH and ESP, source,
destination handshake:
 create network-layer
logical channel called a
security association (SA)
 each SA unidirectional.
 uniquely determined by:
 security protocol (AH or
ESP)
 source IP address
 32-bit connection ID
Secure Communications
24
Authentication Header (AH) Protocol
 provides source
authentication, data
integrity, no
confidentiality
 AH header inserted
between IP header, data
field.
 protocol field: 51
 intermediate routers
process datagrams as
usual
IP header
AH header
AH header includes:
 connection identifier
 authentication data:
source- signed message
digest calculated over
original IP datagram.
 next header field:
specifies type of data
(e.g., TCP, UDP, ICMP)
data (e.g., TCP, UDP segment)
Secure Communications
25
ESP Protocol
 provides secrecy, host
authentication, data
integrity.
 data, ESP trailer encrypted.
 next header field is in ESP
trailer.
 ESP authentication
field is similar to AH
authentication field.
 Protocol = 50.
authenticated
encrypted
IP header
ESP
ESP
ESP
TCP/UDP segment
header
trailer authent.
Secure Communications
26
Kerberos
 Trusted 3rd party authentication scheme
 Assumes that hosts are not trustworthy
 Requires that each client (each request for
service) prove it’s identity
 Does not require user to enter password
every time a service is requested!
Kerberos
28
Kerberos Design
 User must identify itself once at the
beginning of a workstation session

login session
 Passwords are never sent across the
network in cleartext

or stored in memory
 Every user has a password.
 Every service has a password.
 The only entity that knows all the
passwords is the Authentication Server.
Kerberos
29
Ticket Granting
Server
Kerberos
Database
Server
Server
Server
Server
Workstation
Authentication
Server
Kerberos Key Distribution Service
Kerberos
30
Secret Key Cryptography
 The encryption used by current Kerberos
implementations is DES,

Kerberos V5 has hooks so that other algorithms
can be used.
encryption
plaintext
ciphertext
key
ciphertext
plaintext
decryption
Kerberos
31
Tickets
 Each request for a service requires a ticket.
 A ticket provides a single client with access
to a single server.
 Tickets are dispensed by the “Ticket
Granting Server” (TGS),

which has knowledge of all the encryption keys.
 Tickets are meaningless to clients,
 they simply use them to gain access to servers.
Kerberos
32
Tickets (cont.)
 The TGS seals (encrypts) each ticket with
the secret encryption key of the server.
 Sealed tickets can be sent safely over a
network

only the server can make sense out of it
 Each ticket has a limited lifetime
 a few hours
Kerberos
33
Ticket Contents
 Client name (user login name)
 Server name
 Client Host network address
 Session Key for Client/Server
 Ticket lifetime
 Creation timestamp
Kerberos
34
Session Key
 Random number that is specific to a
session.
 Session Key is used to seal client requests
to server.
 Session Key can be used to seal responses

application specific usage
Kerberos
35
Authenticators
 Authenticators prove a client’s identity.
 Includes:
 Client user name.
 Client network address.
 Timestamp.
 Authenticators are sealed with a session key.
Kerberos
36
Bootstrap
 Each time a client wants to contact a server,
it must first ask the 3rd party (TGS) for a
ticket and session key.
 In order to request a ticket from the TGS,
the client must already have a TG ticket and
a session key for communicating with the
TGS !
Kerberos
37
Authentication Server
 The client sends a plaintext request to the
AS asking for a ticket it can use to talk to
the TGS.
 REQUEST:
 login name
 TGS name
 Since this request contains only well-known
names, it does not need to be sealed.
Kerberos
38
Authentication Server
 The AS finds the keys corresponding to the
login name and the TGS name.
 The AS creates a ticket:
 login name
 TGS name
 client network address
 TGS session key
•
The AS seals the ticket with the TGS secret
key.
Kerberos
39
Authentication Server Response
 The AS also creates a random session key for
the client and the TGS to use.
 The session key and the sealed ticket are
sealed with the user (login name) secret key.
Sealed with TGS key
TGS session key
Sealed with user key
Ticket:
login name
TGS name
net address
TGS session key
Kerberos
40
Accessing the TGS
 The client decrypts the message using the
user’s password as the secret key.
 The client now has a session key and ticket
that can be used to contact the TGS.
 The client cannot see inside the ticket,
since the client does not know the TGS
secret key.
Kerberos
41
Accessing a Server
 When a client wants to start using a server
(service), the client must first obtain a
ticket.
 The client composes a request to send to the
TGS:
TGS Ticket
Authenticator
Server Name
sealed with
TGS key
sealed with
session key
Kerberos
42
TGS response
 The TGS decrypts the ticket using it’s secret
key. Inside is the TGS session key.
 The TGS decrypts the Authenticator using the
session key.
 The TGS check to make sure login names, client
addresses and TGS server name are all OK.
 TGS makes sure the Authenticator is recent.
Kerberos
43
TGS Response
Once everything checks out - the TGS:
 builds a ticket for the client and requested
server. The ticket is sealed with the server
key.
 creates a session key
 seals the entire message with the TGS
session key and sends it to the client.
Kerberos
44
Client accesses Server
 The client now decrypts the TGS response
using the TGS session key.
 The client now has a session key for use with
the new server, and a ticket to use with that
server.
 The client can contact the new server using
the same format used to access the TGS.
Kerberos
45
Kerberos Summary
 Every service request needs a ticket.
 Tickets come from the TGS
 except the ticket for the TGS!
 Workstations cannot understand tickets,
 they are encrypted using the server key.
 Every ticket has an associated session key.
 Tickets are reusable.
 Tickets have a finite lifetime.
 Authenticators are only used once
 new connection to a server
 Authenticators expire fast !
 Server maintains list of authenticators
 prevent stolen authenticators
Kerberos
46