Chapters 8 Network Security Professor Rick Han University

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

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

Recap of Previous Lecture • Principles of • • Confusion = substitution Diffusion = permutation • • 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 • Symmetric-Key Cryptography • • Prof. Rick Han, University of Colorado at Boulder

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

Authentication via Digital Signatures • • Similar conceptually to handwritten signatures Uses a property of public-key cryptography: • 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 • • • 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 Prof. Rick Han, University of Colorado at Boulder

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

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

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

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

Data Integrity via One-Way Hash Functions • The hash function H has the property that it is one-way: 1. Given a message digest value MD, it is computationally infeasible to find a message y such that H(y)=MD, 2. 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 • MD 5 and SHA-1 are examples of one-way hashes Prof. Rick Han, University of Colorado at Boulder

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 1. 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 2. 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

Data Integrity via One-Way Hash Functions (3) • Wireless 802. 11 b 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 RC 4 stream cipher used to encrypt packet: • Send ciphertext “RC 4(key) XOR ” Attacker creates a delta packet: Attacker XOR’s delta packet with ciphertext: • RC 4(key) XOR XOR = RC 4(key) XOR = RC 4(key) XOR checksum is linear, not 1 -way = RC 4(key) XOR undetectable tampering of WEP Prof. Rick Han, University of Colorado at Boulder

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

Authentication: Other Methods • The method of authentication via digital signatures just described is classified in section 8. 2 as “MD 5 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 3 rd party (Kerberos) Public-key authentication Prof. Rick Han, University of Colorado at Boulder

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

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 Retrieve public Key Database public key (provides key of “X” Y’s public key) “Send a pizza to X”, Here’s X’s signature (provides Y’s signature) Y Z Pizza sent to X What’s this? X Prof. Rick Han, University of Colorado at Boulder X’s signature Verified!

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

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 of Prof. Rick Han, University Colorado at Boulder

SSL/TLS • Secure Sockets Layer (SSL) and its follow-on Transport Layer Security (TLS) HTTPS SSL/TLS TCP IP • • 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 Prof. Rick Han, University of Colorado at Boulder

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, Rick Han, Universityclient authentication. Prof. supports of Colorado at Boulder

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: // • S-HTTP (or “Secure HTTP”) differs from HTTPS • Other technologies • • 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