Security and the Internet Original key design goals of Internet protocols: • resiliency Computer Networks • availability • scalability Security has not been a priority until mid 1990s Designed for simplicity: “on”-by-default Lecture 14: Unfortunately, readily available zombie machines Network Security and Attacks look like normal traffic Cryptographic Algorithms Internet’s federated operation obstructs cooperation for diagnosis/mitigation

[after Rexford]

Security Attacks Security Requirements

Cast of characters: Alice, Bob, and Trudy, three well- Attack against content: known characters in network security world Bob and Alice want to communicate “securely” Data integrity: sender and receiver(s) want to ensure that data is not altered (in transit, or afterwards) or if Trudy (intruder) may intercept, delete, and/or add altered, detectable messages

Alice data, control Bob Confidentiality/secrecy: only parties involved, the channel messages sender and the intended receiver(s) should know of secure secure data data (the content of) the transaction sender receiver

Trudy Security Requirements Security Requirements

Attack against content: Attack against infrastructure:

Authentication: sender, receiver(s) want to Access and availability: services must be accessible confirm each other’s identity and available to (authorized) users • compare: authorization (what’s the difference between • destroy hardware (cutting fiber) or software authentication and authorization?) • modify software in a subtle way Non-repudiation: involved parties cannot deny • corrupt packets in transit participation afterwards • denial of service (DoS)attack: • crashing the server • overwhelm the server (use up its resource)

Countermeasure: Cryptography Two Types of Encryption Algorithms The fundamental tool for achieving network security Symmetric key cryptography: • both parties share a secret key that is used Origin: Greek word for “secret” for both encryption and decryption Cryptographers invent secret codes (cipher) to try to hide messages from unauthorized observers Public-key cryptography: • asymmetric cryptography: involves use of two keys: a public Alice’s Bob’s key and a private (secret) key, data encrypted with the public encryption key decryption key key can be decrypted by the private key and vice versa KA KB

ciphertext plaintext encryption decryption plaintext Kerckhoff’s Principle: “The security of a cryptosystem algorithm algorithm must not depend on keeping secret the crypto- algorithm. The security depends only on keeping secret the key.” – La cryptographie militaire (1883) Symmetric-key Cryptography Key Escrow

Both parties share a secret key that is used for both Symmetric key cryptography requires participants encryption and decryption to know shared secret key Q: how to agree on shared key in the first place Assumes encryption algorithm is known to both parties (particularly if the participants never “met”)? Implies a secure channel to distribute key Was the only type of encryption prior to the invention Shared key can be distributed by key escrow or of public-key cryptography in 1970’s key distribution center (KDC): Typically more computationally efficient, often • escrow shares secret keys with both parties used in conjunction with public-key cryptography • generates a session key for each session between the two parties Example system: Kerberos Authentication Service • KA-KDC(KA-B, KB-KDC(A, KA-B)) sent to Alice to be passed to Bob

Authentication Authentication: IP Spoofing Fundamental trade-off: security vs. convenience Bob wants Alice to “prove” her identity to him

Most secure, least convenient: not networked, Threat model: Alice’s “I am Alice” placed in a secure locked room IP address Two options in access control: 1. challenge the users each time they want to use a service Alice’s “I am Alice” IP address 2. authenticate them once and grant them tickets to use several services without further Trudy can create (user-level) challenge for a a packet, “spoofing” duration of time (Kerberos) Alice’s address Authentication: Playback Attack Authentication: Use of Nonce Alice says “I am Alice” and sends her Nonce used to avoid playback attack encrypted secret password to “prove” it Nonce: a number (n) used only once-in-a-lifetime To prove Alice “live”, Bob sends Alice nonce, n Threat model: Alice must return n, encrypted with shared secret key encrypted Alice’s “I’m Alice” IP addr password Playback attack: Trudy records Alice’s Alice’s packet and “I am Alice” IP addr OK later spoofs Alice’s n IP address and plays back the Alice is live, and KA-B(n) recorded packet only Alice knows key to Bob to encrypt nonce, so it must be Alice! Alice’s encrypted IP addr password “I’m Alice”

Kerberos: an Authentication Service Kerberos Authentication Protocol Authentication Server (AS):

Kerberos generates a shared symmetric key for 1. keeps a list of all clients’ passwords (Kc’s)

each user-service pair 2. shares a key with each service (Kv) • key is valid for only a limited period of time Client (c): 1. asks AS for a session key for a specific server (v) for a period Three parties: of time, provides nonce (n) 1. Authentication Server (AS) 2. gets back (a) a session key (Kc,v) with expiration time, and 2. Principal: party whose ID is to be verified, usually a nonce, encrypted with client’s password (Kc) and (b) a client application (c) ticket (Tc,v) for server v, encrypted using server’s key (Kv),

3. Verifier: party requesting verification, typically servers Tc,v = Kv (Kc,v, c, timeexp, …) (v) for various services, e.g., name server, file server, 3. sends data (encrypted with session key), along print server, etc. with ticket and authenticator (a timestamp/nonce and an optional sub-session key, encrypted using session key) Kerberos Authentication Protocol Kerberos Authentication Protocol

v Server ( ): Inconvenience: 1. decrypts and “unpacks” T to obtain K , makes sure it c,v c,v • each service requires a separate ticket belongs to c and time hasn’t expired • client prompts user for password for each ticket 2. decrypts authenticator (K (t , K )), checks that c,v s subsession nonce, t , is within window (5 min) and has not been used s More convenient: use a ticket-granting service 3. decrypts data using K (optional) subsession with TGS ticket that lives for a “short” period 4. responds with {t }K (optional) s c,v of time (8 hours)

Kerberos still relies on password, which could be “spoofed”

One-time Passcode Public-key Cryptography Protection against password spoofing • generates a random number as passcode Symmetric key cryptography requires participants • each passcode is good for 4 minutes to know a shared secret key • login challenge comprises user’s password Two “key” issues: plus the random number • key distribution: how to secure communication if you won’t trust a key distribution center with your key?

RSA SecurID tokens • digital signatures: how to verify message arrives intact (has a built-in accurate clock) from claimed sender (w/o prior authentication)

[after Rexford] Public-key Cryptography How to Obtain Public Key? A radically different approach [Diffie-Hellman76, RSA78] Certificates and Certification Authorities (CAs) • known earlier in classified community Bob’s • example algorithm: RSA (Rivest, Shamir, Adelson) public key + + K Sender and receiver do not share a secret key K digital B B signature • + public key (K ) known to all (encrypt) • private key (K−) known only to owner CA’s − certificate for • given public key, it should be impossible to compute private key K private key CA Bob’s public key, • ciphertext encrypted using the public key can be decrypted using − + Bob’s K − (K + ) the private key K (K (M)) = M, used for message integrity, CA B secrecy identifying information • data encrypted with private key, can be decrypted with public key K+(K−(M)) = M, used for digital signature, sender verification, CA is in effect asserting that “this is Bob’s public key” non-repudiation

Public Key Distribution Certificate Revocation When Alice wants Bob’s public key: CA periodically publishes a Certification • Alice obtains CA’s public key in an offline, secure manner (comes with browser code download, how secure is that?) Revocation List (CRL) for revoked public-keys • not currently done • Alice gets Bob’s certificate (from Bob or from elsewhere, doesn’t have to be secure channel, why not?) How to revoke CA’s public key? • Alice decrypts Bob’s certificate using the CA’s public key to • currently as part of browser updates get Bob’s public key + K B digital Bob’s signature + public (decrypt) K B key

CA’s K + public key CA Performance of Public-key Schemes Public Key Infrastructure (PKI) Like symmetric key schemes brute force exhaustive search attack is theoretically possible A hierarchy of CAs • but keys used are so large (e.g., ≥ 1024bits) as to be impractical to crack Relies on a chain of trust (speak-for relationship) • the requirement to use very large numbers makes public-key Examples: cryptography slow compared to symmetric key schemes • Verisign, Entrust, thawte, Symantec, GlobalSign, Visa, For example [cryptopp.com/becnhmarks.html]: on a DigiCert, etc. 1.83 GHz Intel Core 2 running 32-bit Windows Vista, • see ChromeSettingsAdvanced SettingsHTTPS/ • symmetric AES 128-bit key performs at 109 MB/s (1.2 µs/Mbits) SSL Manage certificates... System Roots • RSA 1024-bit key encrypt speed: 1.56 MB/s (80 µs/Mbits) • RSA 1024-bit key decrypt speed: 85.6 KB/s (1,460 µs/Mbits) • RSA decryption is 12-19 times slower than encryption, depending on key size

[after Rexford]

Security of Public-key Schemes Digital Signatures

Symmetric keys are also more Symmetric- and Public-key Cryptographic technique analogous to hand-written Key Lengths with Similar signatures resistant to brute-force attacks Resistances to Brute-Force Attacks [Schneier] Common practice, due to message Sender (Bob) digitally signs document by encrypting symmetric public the document using his private key, establishing he is size and algorithm performance: 56 bits 384 bits the document owner/creator use public-key to distribute 64 bits 512 bits symmetric session key 80 bits 768 bits Verifiable, non-forgeable: recipient (Alice) can prove • generate random symmetric key r 112 bits 1,792 bits to anyone that only Bob, and no one else (including • use public key encryption to encrypt 128 bits 2,304 bits Alice), could have signed the document and distribute r • use symmetric key encryption under r to encrypt message M Non-repudiation: Alice can take message M, and − signature K B (M ) to court and proves that Bob signed M

[after Rexford] Message Digest Digital Signature = Signed Message Digest But it is computationally expensive to encrypt long Bob sends digitally signed message: Alice verifies signature and integrity messages with public-key cryptography of digitally signed message: large message H(•): hash encrypted For purposes of authentication and certification, it is M H(M) function msg digest sufficient to encrypt a digest of the original message − K B (M ) Bob’s digital large Want: a fixed-length, easy-to-compute digital private signature message K − (encrypt) M Bob’s digital “fingerprint” or digest to uniquely represent a message key B public + signature key K B H(•): hash (decrypt) Solution: apply a one-way hash large encrypted function H(•): hash function H(•) to M to get a message + msg digest function K − (M ) fixed-size message digest, H(M) M B H(M) H(M)

same? H(M)

Hash Function Criteria Birthday Paradox Required criteria of the hash function: 1. many-to-1 “compression”, but 1-1 mapping What is the smallest number of people in a room 2. produces fixed-size message digest (fingerprint), fast for a better-than-even odds (probability ≥ 0.5) 3. “one-way”: given message digest h, computationally that two persons share the same birthday? infeasible to find M such that h = H(M) Assumptions: Checksum would not be a good one-way hash function: • 366 days to a year message ASCII format message ASCII format • birthdays are independent (no twins) I O U 1 49 4F 55 31 I O U 9 49 4F 55 39 • birthdays are uniformly distributed (equally likely, in 0 0 . 9 30 30 2E 39 0 0 . 1 30 30 2E 31 9 B O B 39 42 D2 42 9 B O B 39 42 D2 42 reality, more likely 9 months after a holiday) B2 C1 D2 AC different messages B2 C1 D2 AC but identical checksums! Birthday Paradox Birthday Paradox

Probability that each person in the room has a birthday Assuming independence, the probability that all k different from all the other persons in the room: people in the room have different birthdays is:

st 365 364 367 k Probability!for!the!1 !person:!1 − pk = 1⋅ ⋅ ⋅…⋅ 366 −1 366 366 366 Probability!for!the!2nd !person:! 366 The probability that not “all k people in the room 366 − 2 Probability!for!the!3rd !person:! have different birthdays”, i.e., at least 2 out of the 366 k persons have the same birthday is: ε = 1 – p ! k 366 − ( j −1) 367 − j Probability!for!the!j3th!person:! = ! 366 366

Hashing Collision Birthday Paradox How many items (k) does it take to hash two items into the same bucket, with probability ≥ 0.5, for a ε = 1 – pk table of size M? By brute force calculations, we find that: Assuming: for k = 22, ε ≈ 0.475, for k = 23, ε ≈ 0.506 • items are independent • all possible items are equally likely So you only need 23 people in a room for 2 (clearly not true for English words, for example) persons to share the same birthday! • hash function hashes uniformly 1 More generally, k ≈ 2M log For: For SHA-1, n = 160, 1− ε M = 7, k = 4 it takes 280 items to M = 9, k = 4 for!ε = 0.5,!k ≈ 1.17 M have a collision with ! M = 11, k = 4 probability ≥ 0.5 For the birthday paradox, M = 366 M = 240, k = 1 226 834 M = 2n, it takes on the order of √M or 2n/2 Example Hash Function Algorithms Example Hash Function Algorithms MD5 (Message Digest): SHA-1 (Secure Hash Algorithm): • MD4 developed by Rivest (the ‘R’ in RSA) in 1990, MD5 in 1992 • SHA developed by the NSA (1993), revised SHA-1 in 1995 • computes 128-bit message digest in 4-step process • produces 160-bit message digest • collision found in 218 calculations (< 1 sec) in 2013 • collisions in SHA-1 can be found in 269 (not 280) calculations • cryptographically broken

RIPEMD-160 SHA-2 family: SHA-256, SHA-512, and truncated • developed by a team of European researchers at RIPE versions (2001) • produces 160-bit hash • SHA-256 and SHA-512 are structurally identical, differ only • less popular, less scrutinized in rounds (but different from SHA-1) • produce 256- and 512-bit digests respectively Speed: MD5 > RIPEMD-160 > SHA-1 • successful attacks on reduced round, none extends to full round of the hash functions

Example Hash Function Algorithms Other Uses of One-Way Hash Password hashing: SHA-3: • can’t store passwords in a file that could be read • how to compare input passwords to stored passwords? • winner of the NIST hash function competition 2012 • solution: hash(input) == hash(stored) ? • not to replace SHA-2, but as an alternative, dissimilar • often “salt” is used: hash(input||salt) cryptographic hash • known as hash message authentication code (HMAC) • standardized by NIST on Aug. 5th, 2015 • can also be used to generate a different password for • SHA3-224, SHA3-256, SHA3-384, SHA3-512 are the drop- each web account from one password 2 in replacements for SHA , with identical security claims • don’t use MD5 or SHA-1

Integrity of downloaded file: • file tagged with hash(data) • users verify that hash(downloaded) == hash(data)

[after Rexford]