Network Security Primitives Design Fundamentals ET-IDA-082 Lecture-17 Network Security Primitives SSL 31.05.2011, v07 Prof. W. Adi

Outlines Introduction SSL (Secure Socket Layer) IPSEC Kerberos network security primitives and terminology SSL (Secure Socket Layer) IPSEC Kerberos

Recommended Textbooks: 1. Computer Networking: A Top Down Approach Featuring the Internet, 4th edition. Jim Kurose, Keith Ross Addison-Wesley, July 2007. 2. Network Security Essentials: Applications and Standards, 3rd Edition William Stallings, Prentice Hall, © 2007, ISBN: 0-13-238033-1 Copyright notice: Part of the slides (those without foot note) are adapted from the slides of the following text book adopted for this course: Computer Networking: A Top Down Approach Featuring the Internet, 4th edition. Jim Kurose, Keith Ross, Addison-Wesley, July 2007.

Chapter 8: Network Security [1] Chapter goals: understand principles of network security: cryptography and its many uses beyond “confidentiality” authentication key distribution message integrity

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

Security is dealing with 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 Bob channel data, control messages secure sender secure receiver data data Trudy

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?

Terminology: Symmetric key cryptography Same key K A-B K A-B encryption algorithm plaintext message, m ciphertext decryption algorithm plaintext K (m) K (m) A-B m = K ( ) A-B symmetric key crypto: Bob and Alice share know same (symmetric) key: K e.g., key is knowing substitution pattern in mono alphabetic substitution cipher A-B

Terminology: Public key cryptography + K Bob’s public key B - Bob’s private key K B plaintext message, m encryption algorithm ciphertext decryption algorithm plaintext message K (m) B + m = K (K (m)) B + -

Public-Key Secrecy Systems K (m) A - K-open K (m) A + K-close Every key can remove the effect of the other Knowing one of then does not lead to the other (K (m)) = m A - K + - Open and close with different keys!! - No Secret Key Agreement required (K (m)) = m A + K - Two Major Schemes in Public Key Cryptography: Diffie-Hellman Public Key exchange scheme RSA public Key secrecy system or

Authentication Primitives Goal: Bob wants Alice to “prove” her identity to him Protocol ap1.0: Alice says “I am Alice” “I am Alice” Failure scenario??

Authentication Primitives 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”

Authentication: another try Authentication Primitives Authentication: another try Protocol ap2.0: Alice says “I am Alice” in an IP packet containing her source IP address “I am Alice” Alice’s IP address Failure scenario??

Authentication: another try Authentication Primitives 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 “I am Alice” Alice’s IP address

Authentication: another try Authentication Primitives Authentication: another try Protocol ap3.0: Alice says “I am Alice” and sends her secret password to “prove” it. “I’m Alice” Alice’s IP addr password Failure scenario?? OK Alice’s IP addr

Authentication: another try Authentication Primitives Authentication: another try Protocol ap3.0: Alice says “I am Alice” and sends her secret password to “prove” it. Alice’s IP addr Alice’s password “I’m Alice” playback attack: Trudy records Alice’s packetand later plays it back to Bob OK Alice’s IP addr “I’m Alice” Alice’s IP addr password

Authentication: another try Authentication Primitives Authentication: another try Protocol ap3.1: Alice says “I am Alice” and sends her encrypted secret password to “prove” it. “I’m Alice” Alice’s IP addr encrypted password Failure scenario: Playback! OK Alice’s IP addr

Authentication: another try Authentication Primitives Authentication: another try Protocol ap3.1: Alice says “I am Alice” and sends her encrypted secret password to “prove” it. Alice’s IP addr encrypted password “I’m Alice” Record and playback still works! OK Alice’s IP addr “I’m Alice” Alice’s IP addr encrypted password

Authentication: another try [p] [s] Authentication Primitives Authentication: 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 K (R) A-B Alice is live, and only Alice knows key to encrypt nonce, so it must be Alice! Failures, drawbacks?

Authentication: another try [p] [s] Authentication Primitives Authentication: another try ap4.0 requires shared symmetric key can we authenticate using public key techniques? …. yes ap5.0: use nonce, public key cryptography “I am Alice” Bob computes R (K (R)) = R A - K + K (R) A - and knows only Alice could have the private key, that encrypted R such that “send me your public key” K A + (K (R)) = R A - K +

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 T K (R) - R A K (R) - Send me your public key T K + Send me your public key A K + T K (m) + Trudy gets T m = K (K (m)) + - A K (m) + sends m to Alice encrypted with Alice’s public key A m = K (K (m)) + -

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!

Bob’s message, m, signed (encrypted) with his private key Remedy: Simple digital signature for message m: Bob signs m by encrypting with his private key KB, creating “signed” message, KB(m) - - General Public Key signature scheme: K B - Bob’s private key Bob’s message, m K B - (m) Dear Alice Oh, how I have missed you. I think of you all the time! …(blah blah blah) Bob Bob’s message, m, signed (encrypted) with his private key Public key encryption algorithm signe Public key decryption algorithm K B + Bob’s public key (m) (K (m)) = m - If equal Then accept verify

Trusted Intermediaries Trusted Third Party TTP Symmetric key problem: How do two entities establish shared secret key over network? Solution: trusted key distribution center (KDC) acting as intermediary between entities 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)

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 KB-KDC KP-KDC KA-KDC KP-KDC KX-KDC KY-KDC KA-KDC KZ-KDC KB-KDC

Key Distribution Center (KDC) (Secret key) [p] [s] Key Distribution Center (KDC) (Secret key) Q: How does KDC allow Bob, Alice to determine shared symmetric secret key to communicate with each other? KDC generates R1 KA-KDC(A,B) KA-KDC(R1, KB-KDC(A,R1) ) Alice knows R1 Bob gets R1 to communicate with Alice KB-KDC(A,R1) Alice and Bob communicate: using R1 as session key for shared symmetric encryption

Certification Authorities (Public key) 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 E’s public key digitally signed by CA – CA says “this is E’s public key” digital signature (encrypt) Bob’s public key K B + CA private key K B + - Bob’s identifying information K CA certificate for Bob’s public key, signed by CA

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

Certificate Verification CA 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 digital signature (decrypt) Bob’s public key K B + CA public key =? K B + + K CA Acept or reject

Message Authentication Code MAC [p] [s] Message Authentication Code MAC A common integrity checking technique MAC H(.) H(m+s) s m m m | H(m+s) Internet | Compare Accept/Reject H(m+s) H(.) s H(m+s) m: Message S: Shared secret Keyed Hash Function

SSL Secure Socket Layer

Security on the Internet TCP/IP provides no security Must retrofit Internet for security Application layer PGP, S/MIME, SSH, … “Socket layer” SSL/TLS (really part of application layer) Network layer IPSec

Application Layer Security Pretty Good Privacy (PGP) Developed by Phil Zimmerman No backdoor? “We don’t hire that kind of person” Secure/Multipurpose Internet Mail Extensions (S/MIME) Secure email Secure Shell (SSH) Secure “tunnel” for remote access

SSL Secure Socket Layer (SSL) Transport Layer Security (TLS) Developed for Web, HTTP Can be used anywhere Elegant security protocol Transport Layer Security (TLS) Same, but incompatible

SSL Provides: Authentication, confidentiality, integrity You use SSL all the time Whenever “lock” (or “key”) appears in browser HTTPS == HTTP with SSL Secure transactions on Internet

SSL

SSL Secure Socket Layer

A Note on Notation E(X,K) == encrypt X with symmetric key K Key is known to sender and receiver And nobody else {X}Alice == encrypt X with Alice’s public key Key known to everybody Can only be decrypted with Alice’s private key Alice’s private key known only to Alice

Notation h(X) == cryptographic hash function Certificate Provides “fingerprint” of X Compresses data Certificate Contains (at least) public key, name Signed by a Certificate Authority (CA) CA vouches/certifies that corresponding private key belongs to “name” in certificate Anyone can verify signature (public key)

Simple SSL-like Protocol I’d like to talk to you securely Here’s my certificate {KAB}Bob protected HTTP Bob Alice Is Alice sure she’s talking to Bob? Is Bob sure he’s talking to Alice?

Simplified SSL Protocol Can we talk?, cipher list, RA certificate, cipher, RB {S}Bob, E(h(msgs,CLNT,K),K) h(msgs,SRVR,K) Data protected with key K Bob Alice S is pre-master secret K = h(S,RA,RB) Shared secret key msgs = all previous messages CLNT and SRVR are constants

SSL Authentication Alice authenticates Bob, not vice-versa How does client authenticate server? Why does server not authenticate client? Mutual authentication is possible: Bob sends certificate request in message 2 This requires client to have certificate If server wants to authenticate client, server could instead require (encrypted) password

SSL MiM Attack Q: What prevents this MiM attack? Alice Bob RA certificateT, RB {S1}Trudy,E(X1,K1) E(data,K1) h(Y1,K1) Trudy certificateB, RB {S2}Bob,E(X2,K2) E(data,K2) h(Y2,K2) Q: What prevents this MiM attack? A: Bob’s certificate must be signed by a trusted certificate authority (such as Verisign) What does browser do if signature not valid? What does user do if signature is not valid?