How to be a paranoid Dates of birth or just think like one - PowerPoint PPT Presentation

Leaking information Stealing 26.5 million veteran ’ s data Pro rotection a and S d Securi rity 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 Ø Integrity: Data has not been written by unauthorized entity Sony sued by Ø The Dead 60 ’ s Ø Privacy: Data has not been read by unauthorized entity Ø Texas Ø 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? Three challenges Authentication Ø 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 Integrity 3. Yes, for something else Ø Privacy Ø Adversary can not change contents of message ❖ Protect access to communication across hosts 4. No Ø But not necessarily private (public key) Solution: Encryption Ø Example: secure checksum Ø Achieves all these goals Privacy (confidentiality) Ø Transform data that can easily reversed given the correct key (and hard to reverse without the key) Ø Adversary can not read your message Ø 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 Basic idea: Bob wants to send Alice a message m Most implementations of E() and D() need a secret Ø E(m, k) à cipher text c key Does not want Eve to be able to read message Ø 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: Cryptographic hash Public key crypto is more expensive than shared key Ø Separate authentication from secrecy Ø 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) Ø Hard to find two messages with same hash. session key Ø If m != m ’ then H(m) != H(m ’ ) with high probability. H(m) is 256 Example: Ø 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 ❖ With public key crypto Message is confidential even if Eve knows Ka-public and Ø This is how SSL/TLS and other protocols work Ø Receiver: verify that H(m) == D(s) Kb-public Signature will only verify if: Ø No out-of-band protocol needed to exchange a shared secret Ø 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) 1. Authentication Ø {SHA-256 hash of message I just send is … }^K-private certificate Privacy (confidentiality) 2. Integrity certificate ok? Ø Public keys to exchange a secret 3. Privacy Ø Use shared-key cryptography (for speed) 4. Authorization {certificate valid}^CA-private Ø Strategy used by ssh 5. None Forward/backward security Ø 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) vulnerable Ø Passwords: shared secret between two parties Ø Original Unix: 2. Authentication (user to server) Ø Present password to verify identity 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 v Today: < 1us to compare a password è 12 seconds to Ø Encryption: Transformation that is difficult to reverse without crack a password 5. None right key Ø Choice of passwords Ø Example: Unix /etc/passwd file contains encrypted v English words: Shakespeare ’ s vocabulary: 30K words passwords v All English words, fictional characters, place names, words Ø When you type password, system encrypts it and then 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) Easier to remember passwords (visual recognition) Ø Can exploit the interaction with virtual memory to crack passwords! Key idea: Ø Considered to be a very secure system 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++) { Ø http://www.schneier.com/essay-083.html ❖ Arrange that the page with the first character is in memory if (userPasswd[i] != realPasswd[i]) ❖ Rest is on disk (e.g., a|bcdefgh) Ø What about a fake bank web site? (man in the middle) Report Error; ❖ Check how long does a password check take? } Ø Local Trojan program records second factor ◆ If fast è first character is wrong ◆ If slow è first character is right à page fault à one of the later character is Biometrics wrong Ø 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? Ø Number of checks required = 256 * 8 = 2048 !! Ø Is this good enough?? Facial recognition Fix: Ø 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