Protection and Security

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 !! 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 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. Ø Recent systems: more flexible with respect to group creation Privileged user (becomes security hole) Ø Administrator in windows, root in Unix Ø Principle of least privlege

25 26 27

Enforcement Summary

Objectives: Joe Nolife develops a file system that responds to Ø Check password, enforce access control requests with digitally signed packets of data from a Security in systems is essential General approach content provider. Any untrusted machine can serve Ø Separation between “user” mode and “privileged” mode the data and clients can verify that the packets they receive were signed. So stonybrook.edu can give .. And is hard to achieve! In Unix: signed copies of the read-only portions of its web site Ø When you login, you authenticate to the system by providing password to untrusted servers. Joe’s FS provides which Ø Once authenticated – create a shell for specific userID property? Ø All system calls pass userID to the kernel Ø Kernel checks and enforces authorization constraints 1. Authentication of file system users Paradox 2. Integrity of file system contents Ø Any bug in the enforcer è you are hosed! 3. Privacy of file system data & metadata Ø Make enforcer as small and simple as possible ❖ Called the trusted computing base. 4. Authorization of access to data & metadata ❖ Easier to debug, but simple-minded protection (run a lot of services in privileged mode) Ø Support complex protection schemes ❖ Hard to get it right! 28 29 30