Chapters 8 Network Security

1. Chapters 8Network Security Professor Rick Han University of Colorado at Boulder rhan@cs.colorado.edu

2. Announcements • HW #5 (short) due May 2 • Programming Assignment #3 due May 2 • HW #4 solutions on Web • Final Exam May 7, 4:30-7:00 pm • Comprehensive • In this room • In Chapter 8, read all sections. • FCQ’s last 10 minutes. • Next, Network Security Prof. Rick Han, University of Colorado at Boulder

3. Recap of Previous Lecture • Principles of • Confusion = substitution • Diffusion = permutation • Symmetric-Key Cryptography • Keys are same on both sides • Example: DES • 16 stages combining confusion and diffusion • Block cipher • Cipher Block Chaining (CBC) mode • Stream cipher • Generate a pseudo-random stream of bits with key • XOR pseudo-random stream with data stream Prof. Rick Han, University of Colorado at Boulder

4. Recap of Previous Lecture (2) • Public-Key Cryptography • Public key and a private key • Example: RSA encryption • One-way function: difficult to factor the product of two large prime numbers • Exponentiate and modulo to encrypt, exponentiate again and modulo to decrypt • Authentication • Simple scenarios can’t provide authentication • Using public-key cryptography and digital signatures… Prof. Rick Han, University of Colorado at Boulder

5. Authentication via Digital Signatures • Similar conceptually to handwritten signatures • Uses a property of public-key cryptography: • m = cd mod n = (me)d mod n = (md)e mod n • Thus, can swap the order: use private key for encryption and a public key for decryption • Method I: Bob encrypts entire message with Bob’s private key. This is Bob’s digital signature. • Bob send both the message and his digital signature Prof. Rick Han, University of Colorado at Boulder

6. Authentication via Digital Signatures (2) • Alice decrypts Bob’s message using Bob’s public key • If decrypted message matches the message, Alice knows that • The signed message could only have come from Bob (assuming only Bob knows his private key) Prof. Rick Han, University of Colorado at Boulder

7. Authentication via Digital Signatures (3) • In Method I, signing the entire document/message is computationally expensive • Method II: Instead, compute a hash on the document/message • The hash is much smaller than the document, resembles a CRC. Also called a message digest • Hash function H generates the hash • Use private key to encrypt only the message digest • Encrypted digest commonly called a digital signature • Computationally inexpensive Prof. Rick Han, University of Colorado at Boulder

8. Authentication via Digital Signatures (4) • Send both the document and the digitally signed message digest • At receiver • hash the document = MDA • decrypt the digital signature = MDB • If MDA = MDB then receiver knows that: • the identity of sender correctly matches the advertiser of the public key (Authentication) • that the document hasn’t been tampered with (Data Integrity) • Caveat: the hash function must be “one-way” to make these claims Prof. Rick Han, University of Colorado at Boulder

9. Bob sends digitally signed message: Alice verifies signature and integrity of digitally signed message: Digital signature = Signed message digest Prof. Rick Han, University of Colorado at Boulder

10. Data Integrity via One-Way Hash Functions • The hash function H has the property that it is one-way: • Given a message digest value MD, it is computationally infeasible to find a message y such that H(y)=MD, • It is computationally infeasible to find any two messages x and y such that H(x)=H(y) • Otherwise, could substitute a forged message y for original message without changing the hash/MD • Violates Data Integrity – tampering must be detectable • MD5 and SHA-1 are examples of one-way hashes Prof. Rick Han, University of Colorado at Boulder

11. Data Integrity via One-Way Hash Functions (2) • Example: the TCP/IP checksum is a hash function that is not one-way • One’s complement 16-bit sum • Example: Easy to forge the message x with y yet keep the checksum the same, H(x)=H(y) without detection • flip two bits from different 16-bit blocks but with the same offset n within a 16-bit block: checksum unchanged • Example: Easy to forge the message x with y and modify the checksum H(x) to H(y) without detection • Lack of one-way hash enables forgery Prof. Rick Han, University of Colorado at Boulder

12. Data Integrity via One-Way Hash Functions (3) • Wireless 802.11b uses a security standard called the Wired Equivalent Privacy (WEP) protocol that has a hash-based security flaw • Given a message m, compute a 32-bit checksum c(m), and form a packet <m,c(m)> • RC4 stream cipher used to encrypt packet: • Send ciphertext “RC4(key) XOR <m,c(m)>” • Attacker creates a delta packet: <D,c(D)> • Attacker XOR’s delta packet with ciphertext: • RC4(key) XOR <m,c(m)> XOR <D,c(D)> • = RC4(key) XOR <m XOR D, c(m) XOR c(D)> • = RC4(key) XOR <m’, c(m XOR D)>  checksum is linear, not 1-way • = RC4(key) XOR <m’, c(m’)>  undetectable tampering of WEP Prof. Rick Han, University of Colorado at Boulder

13. Non-Repudiation via Digital Signatures • Digital Signatures provide authentication, integrity, and non-repudiation • At receiver, if MDA = MDB then receiver knows that: • Only the sender’s private key could have created this signature (Non-repudiation & Authentication) • Sender can’t deny sending message MDA MDB Prof. Rick Han, University of Colorado at Boulder

14. Authentication: Other Methods • The method of authentication via digital signatures just described is classified in section 8.2 as “MD5 with RSA Signature” • Textbook discusses 3 other useful techniques for authentication where one or both sides choose random #’s. You’re responsible for knowing these: • 3-way handshake • Trusted 3rd party (Kerberos) • Public-key authentication Prof. Rick Han, University of Colorado at Boulder

15. X Z Y Key Distribution & Certification • Public keys which are not securely certified can suffer from a man-in-the-middle attack: • X wishes to send to Z, but Y transparently sits in the middle between X and Z “Z: Please send me your public key” “Z: Please send me your public key” Y’s public key, Y says it’s Z’s Z’s public key X’s data encrypted with Y’s public key X’s data encrypted with Z’s public key Y decrypts With Y’s Private key X and Z never know that Y has seen their data Prof. Rick Han, University of Colorado at Boulder

16. Y X Z Key Distribution & Certification (2) • Another type of attack on non-certified public keys: • Y pretends to be X. Y advertises a public key under the name of X. I am X, here is my public key (provides Y’s public key) Key Database Retrieve public key of “X” “Send a pizza to X”, Here’s X’s signature (provides Y’s signature) X’s signature Verified! Pizza sent to X What’s this? Prof. Rick Han, University of Colorado at Boulder

17. Key Distribution & Certification (3) • Basic problem exploited by both attacks: • The public key was not certified as belonging to an entity (a person, a router, a company, etc.) • Use a trusted Certification Authority (CA) to bind a key to an entity • Public key of CA is available at a well-known address that can’t be spoofed • Or, public key of CA is pre-installed, e.g. Netscape browser has embedded public key of the Netscape CA • Assume there exists an out-of-band procedure (perhaps non-electronic), where an entity registers its public key with a CA in a verifiable way • Trust the CA to have verified all public keys and have removed the possibility of spoofing an identity Prof. Rick Han, University of Colorado at Boulder

18. Key Distribution & Certification (4) • Use a trusted Certification Authority (CA) to bind a key to an entity (cont.) • When host X wants to securely talk with host Y, host X first asks host Y (or CA) for host Y’s public key • Host Y returns host Y’s public key, signed with the CA’s signature: • “This is host Y’s public key, signed by the trusted CA” • Constitutes a digital certificate (conforms to X.509 standard) • Host X receives the CA’s digital certificate and uses CA’s public key to verify that the certificate was signed by the trusted CA • Now, host X has the verified public key for host Y for secure communication Prof. Rick Han, University of Colorado at Boulder

19. SSL/TLS • Secure Sockets Layer (SSL) and its follow-on Transport Layer Security (TLS) • Phase 1: Handshake phase • Negotiate an encryption algorithm (e.g. DES) • Authenticate the server to the client • Decide on keys • Phase 2: Data transfer phase via a “record” protocol HTTPS SSL/TLS TCP IP Prof. Rick Han, University of Colorado at Boulder

20. SSL/TLS (2) • Handshake protocol: public key, then common case is symmetric key • Client (browser) sends a “Hello” to Server (Web), including client’s cryptographic preferences • Server replies with Hello + server’s certificate • Client uses CA’s public key to verify server’s certificate, extracts server’s public key – server is now authenticated • Client generates a symmetric session key (actually a pre-master secret), encrypts it with the server’s public key, and sends it back to server • Both sides now have symmetric session key and can use DES-like encryption/decryption. • Some additional messaging to complete SSL handshake. Also, supports client authentication. Prof. Rick Han, University of Colorado at Boulder

21. SSL/TLS (3) • Any application-layer protocol can use SSL, e.g. http, smtp, ftp, telnet, ssh, etc. • HTTP over SSL is called HTTPS • A secure URL is often preceded by https:// • Other technologies • S-HTTP (or “Secure HTTP”) differs from HTTPS • Message-based transactions (SSL is connection-based) • Specific to HTTP (SSL works with all application layer protocols). URL is preceded by shttp:// • Less popular than HTTPS • SET (Secure Electronic Transactions) • Public-key technology for secure financial payments by VISA. Technically, can work on top of SSL. Prof. Rick Han, University of Colorado at Boulder