Lecture 25 Secure Communications CPE 401 601

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

Secure Protocols q There a growing number of applications for secure protocols v v v email electronic commerce electronic voting q Many application protocols include the use of cryptography as part of application level protocol v v 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: q message originally came from Alice q message not changed since sent by Alice Cryptographic Hash: q takes input m, produces fixed length value, H(m) v e. g. , as in Internet checksum q computationally infeasible to find two different messages, x, y such that H(x) = H(y) v v 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 4 F 55 31 30 30 2 E 39 39 42 4 F 42 B 2 C 1 D 2 AC message I O U 9 0 0. 1 9 B O B ASCII format 49 4 F 55 39 30 30 2 E 31 39 42 4 F 42 B 2 C 1 D 2 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) s (shared secret) Secure Communications 5

MACs in practice q MD 5 hash function widely used (RFC 1321) computes 128 -bit MAC in 4 -step process. v arbitrary 128 -bit string x, appears difficult to construct msg m whose MD 5 hash is equal to x v • recent (2005) attacks on MD 5 q SHA-1 is also used US standard [NIST, FIPS PUB 180 -1] v 160 -bit MAC v Secure Communications 6

Digital Signatures cryptographic technique analogous to handwritten signatures. q sender (Bob) digitally signs document, establishing he is document owner/creator. q verifiable, nonforgeable: v 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: q 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) Bob K B Bob’s private key public key encryption algorithm (m) KB Bob’s message, m, signed (encrypted) with his private key Secure Communications 8

Digital Signatures (more) - q suppose Alice receives msg m, digital signature K B(m) q Alice verifies m signed by Bob by applying Bob’s + - public key KB to KB(m) then checks KB(KB(m) ) = m. + - q 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) equal ? Secure Communications 10

Public Key Certification public key problem: q 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: q trusted certification authority (CA) Secure Communications 11

Certification Authorities q Certification Authority (CA): binds public key to particular entity, E. q E registers its public key with CA. v v v 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 q when Alice wants Bob’s public key: gets Bob’s certificate (Bob or elsewhere). v apply CA’s public key to Bob’s certificate, get Bob’s public key v + KB - + K CA(KB ) digital signature (decrypt) CA public key Bob’s public + key KB + K CA Secure Communications 13

Secure e-mail q Alice wants to send confidential e-mail, m, to Bob. KS m KS K (. ) S + . K B( ) K+ B KS(m ) + + KB(KS ) Internet . K S( ) - KS + m K B( ) - KB(KS ) . KB Alice: q q 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 q Alice wants to send confidential e-mail, m, to Bob. KS m KS K (. ) S + . K B( ) K+ B KS(m ) + + KB(KS ) Internet . K S( ) - KS + m K B( ) - KB(KS ) . KB Bob: q uses his private key to decrypt and recover K S q uses KS to decrypt KS(m) to recover m Secure Communications 15

Secure e-mail (continued) • Alice wants to provide sender authentication message integrity. m H(. ) KA - - - . KA(H(m)) K A( ) + + KA Internet m - + . K A( ) 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. m . H( ) KA - - . KA(H(m)) K A( ) + . K S( ) m KS KS + . K B( ) K+ B + Internet + KB(KS ) Alice uses three keys: her private key, Bob’s public key, newly created symmetric key Secure Communications 17

Pretty good privacy (PGP) q Internet e-mail encryption scheme, v de-facto standard. q uses v v v symmetric key cryptography, public key cryptography, hash function, and digital signature as described. q provides v v v secrecy, sender authentication, integrity. A PGP signed message: ---BEGIN PGP SIGNED MESSAGE--Hash: SHA 1 Bob: My husband is out of town tonight. Passionately yours, Alice ---BEGIN PGP SIGNATURE--Version: PGP 5. 0 Charset: noconv yh. HJRHh. GJGhgg/12 Ep. J+lo 8 g. E 4 v. B 3 mq. Jh FEv. ZP 9 t 6 n 7 G 6 m 5 Gw 2 ---END PGP SIGNATURE--- Secure Communications 18

Secure sockets layer (SSL) q provides transport layer security to any TCP-based application using SSL services. v e. g. , between Web browsers, servers for e-commerce q security services: v server authentication, v data encryption, v 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 TCP SYN 1. Handshake: ACK P SYN TC q Bob establishes TCP connection to Alice q authenticates Alice via CA signed certificate q sends master secret key to Alice v v encrypted with Alice’s public key nonce exchange not shown TCP ACK SSL hello te ca certifi create Master Secret (MS) KA +(MS) decrypt using KA to get MS Secure Communications 20

SSL: three phases 2. Key Derivation: q Alice, Bob use shared secret (MS) to generate 4 keys: v v EB: Bob->Alice data encryption key EA: Alice->Bob data encryption key MB: Bob->Alice MAC key MA: Alice->Bob MAC key q encryption and MAC algorithms negotiable between Bob, Alice Secure Communications 21

SSL: three phases 3. Data transfer TCP byte stream block n bytes together b 1 b 2 b 3 … bn d . MB H( ) d H(d) . EB H( ) SSL d SSL record format H(d) Type Ver Len d compute MAC seq. # encrypt d, MAC, SSL seq. # H(d) unencrypted using EB Secure Communications 22

HTTPS Usage q HTTPS is HTTP running over SSL. v used for most secure web transactions. v HTTPS server usually runs on port 443. v v Include notion of verification of server via a certificate. Central trusted source of certificates. Secure Communications 23

IPsec: Network Layer Security q network-layer secrecy: sending host encrypts the data in IP datagram v TCP and UDP segments; ICMP and SNMP messages. q network-layer authentication v destination host can authenticate source IP address q two principal protocols: v authentication header (AH) protocol v encapsulation security payload (ESP) protocol v q for both AH and ESP, source, destination handshake: v create network-layer logical channel called a security association (SA) q each SA unidirectional. q uniquely determined by: v security protocol (AH or ESP) v source IP address v 32 -bit connection ID Secure Communications 24

Authentication Header (AH) Protocol q provides source authentication, data integrity, no confidentiality q AH header inserted between IP header, data field. q protocol field: 51 q intermediate routers process datagrams as usual IP header AH header includes: q connection identifier q authentication data: source- signed message digest calculated over original IP datagram. q next header field: specifies type of data (e. g. , TCP, UDP, ICMP) data (e. g. , TCP, UDP segment) Secure Communications 25

ESP Protocol q provides secrecy, host authentication, data integrity. q data, ESP trailer encrypted. q next header field is in ESP trailer. q ESP authentication field is similar to AH authentication field. q Protocol = 50. authenticated encrypted IP header ESP ESP TCP/UDP segment header trailer authent. Secure Communications 26

Kerberos q Trusted 3 rd party authentication scheme q Assumes that hosts are not trustworthy q Requires that each client (each request for service) prove it’s identity q Does not require user to enter password every time a service is requested! Kerberos 28

Kerberos Design q User must identify itself once at the beginning of a workstation session v login session q Passwords are never sent across the network in cleartext v or stored in memory q Every user has a password. q Every service has a password. q The only entity that knows all the passwords is the Authentication Server. Kerberos 29

Ticket Granting Server Kerberos Database Server Workstation Authentication Server Kerberos Key Distribution Service Kerberos 30

Secret Key Cryptography q The encryption used by current Kerberos implementations is DES, v Kerberos V 5 has hooks so that other algorithms can be used. encryption plaintext ciphertext key ciphertext plaintext decryption Kerberos 31

Tickets q Each request for a service requires a ticket. q A ticket provides a single client with access to a single server. q Tickets are dispensed by the “Ticket Granting Server” (TGS), v which has knowledge of all the encryption keys. q Tickets are meaningless to clients, v they simply use them to gain access to servers. Kerberos 32

Tickets (cont. ) q The TGS seals (encrypts) each ticket with the secret encryption key of the server. q Sealed tickets can be sent safely over a network v only the server can make sense out of it q Each ticket has a limited lifetime v a few hours Kerberos 33

Ticket Contents q Client name (user login name) q Server name q Client Host network address q Session Key for Client/Server q Ticket lifetime q Creation timestamp Kerberos 34

Session Key q Random number that is specific to a session. q Session Key is used to seal client requests to server. q Session Key can be used to seal responses v application specific usage Kerberos 35

Authenticators q Authenticators prove a client’s identity. q Includes: v Client user name. v Client network address. v Timestamp. q Authenticators are sealed with a session key. Kerberos 36

Bootstrap q Each time a client wants to contact a server, it must first ask the 3 rd party (TGS) for a ticket and session key. q 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 q The client sends a plaintext request to the AS asking for a ticket it can use to talk to the TGS. q REQUEST: v login name v TGS name q Since this request contains only well-known names, it does not need to be sealed. Kerberos 38

Authentication Server q The AS finds the keys corresponding to the login name and the TGS name. q The AS creates a ticket: v login name v TGS name v client network address v TGS session key • The AS seals the ticket with the TGS secret key. Kerberos 39

Authentication Server Response q The AS also creates a random session key for the client and the TGS to use. q 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 q The client decrypts the message using the user’s password as the secret key. q The client now has a session key and ticket that can be used to contact the TGS. q The client cannot see inside the ticket, since the client does not know the TGS secret key. Kerberos 41

Accessing a Server q When a client wants to start using a server (service), the client must first obtain a ticket. q 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 q The TGS decrypts the ticket using it’s secret key. Inside is the TGS session key. q The TGS decrypts the Authenticator using the session key. q The TGS check to make sure login names, client addresses and TGS server name are all OK. q TGS makes sure the Authenticator is recent. Kerberos 43

TGS Response Once everything checks out - the TGS: q builds a ticket for the client and requested server. The ticket is sealed with the server key. q creates a session key q seals the entire message with the TGS session key and sends it to the client. Kerberos 44

Client accesses Server q The client now decrypts the TGS response using the TGS session key. q The client now has a session key for use with the new server, and a ticket to use with that server. q The client can contact the new server using the same format used to access the TGS. Kerberos 45

Kerberos Summary q Every service request needs a ticket. q Tickets come from the TGS v except the ticket for the TGS! q Workstations cannot understand tickets, v they are encrypted using the server key. q Every ticket has an associated session key. q Tickets are reusable. q Tickets have a finite lifetime. q Authenticators are only used once v new connection to a server q Authenticators expire fast ! q Server maintains list of authenticators v prevent stolen authenticators Kerberos 46