Chapters 8 Network Security Professor Rick Han University of Colorado at Boulder

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 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 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: m = c d mod n = (m e ) d mod n = (m d ) 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 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 = MD A decrypt the digital signature = MD B If MD A = MD B 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 MD5 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 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 RC4 stream cipher used to encrypt packet: Send ciphertext “RC4(key) XOR ” Attacker creates a delta packet: Attacker XOR’s delta packet with ciphertext: RC4(key) XOR XOR = RC4(key) XOR = RC4(key) XOR  checksum is linear, not 1-way = RC4(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 non- repudiation At receiver, if MD A = MD B then receiver knows that: Only the sender’s private key could have created this signature (Non- repudiation & Authentication) Sender can’t deny sending message MD A MD B

Prof. Rick Han, University of Colorado at Boulder 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 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 wishes to send to Z, but Y transparently sits in the middle between X and Z XZY “Z: Please send me your public key” “Z: Please send me your public key” Z’s public key Y’s public key, Y says it’s Z’s X’s data encrypted with Y’s public key Y decrypts With Y’s Private key X’s data encrypted with Z’s public key X and Z never know 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. YXZ “Send a pizza to X”, Here’s X’s signature (provides Y’s signature) Key Database I am X, here is my public key (provides Y’s public key) Retrieve public key of “X” X’s signature Verified! Pizza sent to X What’s this?

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

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