Lecture 25 Secure Communications CPE 401 / 601 Computer Network Systems slides are modified from Jim Kurose & Keith Ross and Dave Hollinger

Lecture 25

Secure Communications

CPE 401 / 601Computer 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!


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:

I O U 10 0 . 99 B O B

49 4F 55 3130 30 2E 3939 42 4F 42

message ASCII format

B2 C1 D2 AC

I O U 90 0 . 19 B O B

49 4F 55 3930 30 2E 3139 42 4F 42

message ASCII format

B2 C1 D2 ACdifferent messagesbut identical checksums!


Message Authentication Code

m

s(shared secret)

(message)

H(.)H(m+s)

publicInternetappend

m H(m+s)

s

compare

m

H(m+s)

H(.)

H(m+s)

(shared secret)


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


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


Digital Signatures

simple digital signature for message m: Bob “signs” m by encrypting with his private

key KB, creating “signed” message, KB(m)--

Dear Alice

Oh, how I have missed you. I think of you all the time! …(blah blah blah)

Bob

Bob’s message, m

public keyencryptionalgorithm

Bob’s privatekey

K B-

Bob’s message, m, signed (encrypted) with his private key

K B-(m)


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.

+ +

-

-

- -

+

-


Digital signature = signed MAC

Alice verifies signature and integrity of digitally signed message:

large messagem

H: hashfunction H(m)

digitalsignature(encrypt)

Bob’s private

key K B-

+

Bob sends digitally signed message:

KB(H(m))-

encrypted msg digest

KB(H(m))-

encrypted msg digest

large messagemH: hashfunction

H(m)

digitalsignature(decrypt)

H(m)

Bob’s public

key K B+

equal ?


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)


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.”

Certification Authorities

Bob’s public

key K B+

Bob’s identifying informatio

n

digitalsignature(encrypt)

CA private

key K CA-

K B+

certificate for Bob’s public

key, signed by CA

-K CA(K ) B+


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

Certification Authorities

Bob’s public

key K B+

digitalsignature(decrypt)

CA public

key K CA+

K B+

-K CA(K ) B+


Secure e-mail

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.

Alice wants to send confidential e-mail, m, to Bob.

KS( ).

KB( ).+

+ -

KS(m

)

KB(KS )+

m

KS

KS

KB+

Internet

KS( ).

KB( ).-

KB-

KS

mKS(m

)

KB(KS )+


Secure e-mail

Bob: uses his private key to decrypt and recover KS

uses KS to decrypt KS(m) to recover m

Alice wants to send confidential e-mail, m, to Bob.

KS( ).

KB( ).+

+ -

KS(m

)

KB(KS )+

m

KS

KS

KB+

Internet

KS( ).

KB( ).-

KB-

KS

mKS(m

)

KB(KS )+


Secure e-mail (continued)

• Alice wants to provide sender authentication message integrity.

• Alice digitally signs message.• sends both message (in the clear) and digital signature.

H( ). KA( ).-

+ -

H(m )KA(H(m))-

m

KA-

Internet

m

KA( ).+

KA+

KA(H(m))-

mH( ). H(m )

compare


Secure e-mail (continued)• Alice wants to provide secrecy, sender authentication, message integrity.

Alice uses three keys: her private key, Bob’s public key, newly created symmetric key

H( ). KA( ).-

+

KA(H(m))-

m

KA-

m

KS( ).

KB( ).+

+

KB(KS )+

KS

KB+

Internet

KS


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.

---BEGIN PGP SIGNED MESSAGE---Hash: SHA1

Bob:My husband is out of town tonight.Passionately yours, Alice

---BEGIN PGP SIGNATURE---Version: PGP 5.0Charset: noconvyhHJRHhGJGhgg/

12EpJ+lo8gE4vB3mqJhFEvZP9t6n7G6m5Gw2

---END PGP SIGNATURE---

A PGP signed message:


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)

TCP

IP

TCP enhanced with SSL

TCP socket

Application

TCP

IP

TCP API

SSL sublayer

Application

SSLsocket


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

SSL hello

certificate

KA+(MS)

TCP SYN

TCP SYNACK

TCP ACK

decrypt using KA

-

to get MS

create MasterSecret (MS)


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


SSL: three phases3. Data transfer

H( ).MB

b1b2b3 … bn

d

d H(d)

d H(d)

H( ).EB

TCP byte stream

block n bytes together compute MAC

encrypt d, MAC, SSL seq. #

SSL seq. #

d H(d)Type Ver Len

SSL record format

encrypted using EBunencrypted


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.


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


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

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)

IP header data (e.g., TCP, UDP segment)AH header


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.

IP header TCP/UDP segmentESPheader

ESPtrailer

ESPauthent.

encryptedauthenticated


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

Kerberos 30

ServerServerServerServerServerServerServerServer

ServerServerServerServerServerServerServerServer

KerberosKerberosDatabaseDatabase

Ticket GrantingTicket Granting ServerServer

Ticket GrantingTicket Granting ServerServer

AuthenticationAuthentication ServerServer

AuthenticationAuthentication ServerServer

WorkstationWorkstationWorkstationWorkstation

Kerberos Key Distribution ServiceKerberos Key Distribution Service

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

keyciphertext 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.

Kerberos 40

TGS session key

Ticket:login nameTGS namenet addressTGS session key

Sealed with user keySealed with user key

Sealed with TGS keySealed with TGS key

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:

Kerberos 42

TGS Ticket

Authenticator

Server Name

sealed withsealed withTGS keyTGS key

sealed withsession key

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

Documents

Lecture 25 Secure Communications CPE 401 / 601 Computer Network Systems slides are modified from Jim Kurose & Keith Ross and Dave Hollinger