Leaking information Stealing 26.5 million veteran’s data Protection and Security Data on laptop stolen from employee’s home (5/06) Ø Veterans’ names Ø Social Security numbers How to be a paranoid Ø Dates of birth or just think like one Exposure to identity theft CardSystems exposes data of 40 million cards (2005) Ø Data on 70,000 cards downloaded from ftp server These are attacks on privacy (confidentiality, anonymity) 1 2 3 The Sony rootkit The Sony rootkit The Problem Types of misuse Ø Accidental Ø Intentional (malicious) Sony’s rootkit enforced DRM but exposed computer Ø CDs recalled Protection and security objective Ø Classified as spyware by anti-virus software Ø Protect against/prevent misuse “Protected” albums included Ø Rootkit removal software distrubuted Ø Billie Holiday Ø Removal software had exposure vulnerability Three key components: Ø Louis Armstrong Ø New removal software distrubuted Ø Authentication: Verify user identity Ø Switchfoot Sony sued by Ø Integrity: Data has not been written by unauthorized entity Ø The Dead 60’s Ø Texas Ø Privacy: Data has not been read by unauthorized entity Ø Flatt & Scruggs, etc. Ø New York Rootkits modify files to infiltrate & hide Ø California Ø System configuration files This is an attack on integrity Ø Drivers (executable files) 4 5 6 Have you used an anonymizing service? What are your security goals? What About Security in Distributed Systems? Authentication Three challenges Ø Authentication 1. Yes, for email Ø User is who s/he says they are. ❖ Verify user identity 2. Yes, for web browsing Ø Example: Certificate authority (verisign) Ø Integrity ❖ Verify that the communication has not been tempered with 3. Yes, for something else Integrity Ø Privacy Ø Adversary can not change contents of message ❖ Protect access to communication across hosts 4. No Ø But not necessarily private (public key) Ø Example: secure checksum Solution: Encryption Ø Achieves all these goals Privacy (confidentiality) Ø Transform data that can easily reversed given the correct key (and Ø Adversary can not read your message hard to reverse without the key) Ø If adversary eventually breaks your system can they decode all stored communication? Ø Example: Anonymous remailer (how to reply?) Authorization, repudiation (or non-repudiation), forward security (crack now, not crack future), backward security (crack now, not cracked past) 7 8 9 Encryption (big idea) Keyed encryption Symmetric Key (Shared Key) Encryption Bob wants to send Alice a message m Most implementations of E() and D() need a secret Basic idea: Ø E(m, k) à cipher text c Does not want Eve to be able to read message key Ø D(c, k) à plain text m Ø Eve can know E() and D() code Somehow, Alice and Bob exchange the key out of band Ø Exercise for the reader ❖ Not many cryptographic algorithms in the world Idea: Need to keep the shared key secret! Ø Alice and Bob just need to pick secret keys Eve doesn’t Bob: E(m) -> c // Sends c over the network to Alice know (and each other may not know) Alice: D(c) -> m ❖ Some mathematical constraints Two types: Function E encrypts plaintext message to ciphertext (c) Ø Symmetric key Function D decrypts ciphertext to plaintext Ø Public/private key Eve can only read c, which looks like garbage 10 11 12 Public Key Encryption Mitigating costs Digital signatures Basic idea: Ø Separate authentication from secrecy Public key crypto is more expensive than shared key Cryptographic hash Ø Hash is a fixed sized byte string which represents arbitrary length Ø Each key is a pair: K-public and K-private Idea: Use public key crypto to exchange a temporary, data. Ø Alice and Bob both have key pairs (Ka and Kb) session key Ø Hard to find two messages with same hash. Example: Ø If m != m’ then H(m) != H(m’) with high probability. H(m) is 256 Ø During a session, exchange messages using shared key bits Ø Alice: E(m, Ka-private, Kb-public) -> c Message integrity with digital signatures Ø Only Bob can decrypt c with: One expensive public key message to set up session Ø For message m: hash m, encrypt the hash (E(H(m)) = s ❖ D(c, Ka-public, Kb-private) -> m Ø All future messages cheap Message is confidential even if Eve knows Ka-public and ❖ With public key crypto Kb-public Ø This is how SSL/TLS and other protocols work Ø Receiver: verify that H(m) == D(s) Ø No out-of-band protocol needed to exchange a shared secret Signature will only verify if: Ø But Alice does have to trust that Kb-public belongs to Bob Ø Hash was encrypted by owner of K-public ❖ Typically managed by some trusted certificate Ø Message did not change authority or key distribution network Also provides non-repudiation ◆ Debian developers meet and sign each others’ keys at conferences 13 14 15 Implementing your security goals Securing HTTP: HTTPS (HTTP+SSL/TLS) When you log into a website using an http URL, which Authentication property are you missing? Ø {I’m Don}^K-private client server CA Integrity hello(client) Ø {SHA-256 hash of message I just send is …}^K-private 1. Authentication Privacy (confidentiality) 2. Integrity certificate Ø Public keys to exchange a secret certificate ok? 3. Privacy Ø Use shared-key cryptography (for speed) Ø Strategy used by ssh 4. Authorization {certificate valid}^CA-private Forward/backward security 5. None Ø Rotate shared keys every hour {send random shared key}^S-public Repudiation Ø Public list of cracked keys switch to encrypted connection using shared key 16 17 18 Authentication Authentication (Cont’d.) When you visit a website using an https URL, which 2. Passwords must be long and obscure property are you missing? Objective: Verify user identity Ø Paradox: v Short passwords are easy to crack Common approach: v Long passwords – users write down to remember è 1. Authentication (server to user) Ø Passwords: shared secret between two parties vulnerable 2. Authentication (user to server) Ø Present password to verify identity Ø Original Unix: v 5 letter, lower case password 3. Integrity 1. How can the system maintain a copy of passwords? v Exhaustive search requires 26^5 = 12 million comparisons 4. Privacy Ø Encryption: Transformation that is difficult to reverse without v Today: < 1us to compare a password è 12 seconds to 5. None right key crack a password Ø Example: Unix /etc/passwd file contains encrypted Ø Choice of passwords passwords v English words: Shakespeare’s vocabulary: 30K words Ø When you type password, system encrypts it and then v All English words, fictional characters, place names, words compared encrypted versions reversed, … still too few words v (Partial) solution: More complex passwords Ø At least 8 characters long, with upper/lower case, numbers, and special characters 19 20 21 Are Long Passwords Sufficient? Are Long Passwords Sufficient? (Cont’d.) Alternatives/enhancements to Passwords Problem: Example: Tenex system (1970s – BBN) Ø Can exploit the interaction with virtual memory to crack passwords! Easier to remember passwords (visual recognition) Ø Considered to be a very secure system Key idea: Two-factor authentication Ø Force page faults at carefully designed times to reveal password Ø Code for password check: Ø Password and some other channel, e.g., physical device Ø Approach with key that changes every minute ❖ Arrange first character in string to be the last character in a page For (i=0, i<8, i++) { ❖ Arrange that the page with the first character is in memory Ø http://www.schneier.com/essay-083.html if (userPasswd[i] != realPasswd[i]) ❖ Rest is on disk (e.g., a|bcdefgh) Report Error; Ø What about a fake bank web site? (man in the middle) ❖ Check how long does a password check take? } ◆ If fast è first character is wrong Ø Local Trojan program records second factor ◆ If slow è first character is right à page fault à one of the later character is wrong Biometrics Ø Looks innocuous – need to try 256^8 (= 1.8E+19) ❖ Try all first characters until the password check takes long Ø Fingerprint, retinal scan combinations to crack a password ❖ Repeat with two characters in memory, … Ø What if I have a cut? What if someone wants my finger? Ø Is this good enough?? Ø Number of checks required = 256 * 8 = 2048 !! Fix: Facial recognition Ø Don’t report error until you have checked all characters! No!!! Ø But, how do you figure this out in advance?? Ø Timing bugs are REALLY hard to avoid 22 23 24 Password security Authorization Authorization § Instead of hashing your password, I will hash your password concatenated with a random salt. Then I Objective: Ø Specify access rights: who can do what? Capability lists (a capability is like a ticket) store the unhashed salt along with the hash. Ø Each process stores information about objects it has § (password . salt)^H salt Access control: formalize all permissions in the permission to touch Ø Processes present capability to objects to access (e.g., file § What attack does this address? system File1 File2 File3 … descriptor) User A RW R -- … Ø Lots of capability-based systems built in the past but idea User B -- RW RW .. out of favor today User C RW RW RW … Problem: 1. Brute force password guessing for all accounts. Ø Potentially huge number of users, objects that dynamically 2. Brute force password guessing for one account. change è impractical Access control lists 3. Trojan horse password value Ø Store permissions for all users with objects 4. Man-in-the-middle attack when user gives Ø Unix approach: three categories of access rights (owner, group, world) password at login prompt.