Week 14.a CS3650 04/08 2024 1. Eclipse 2. Intro to security 3. Authentication --------------------------- 1. Eclipse - Boston will be able to see the eclipse between 2:16PM to 4:39PM. - The max eclipse (93%) will be at 3:29PM. - Will have 20min break: 3:20PM -- 3:40PM - In class: https://science.nasa.gov/eclipses/future-eclipses/eclipse-2024/live/ Notes: - do not see the sun with your bare eyes or sun glasses - use your phone or borrow eclipse glasses from your peers - This eclipse is not unique; there will be eclipses in 2026, 2027, 2028 - Lottery does not count today Admin: - lab3 regrading -- resubmission of any labs is possible (with 50% late penalty) - lab5 2. Intro to security security is a pervasive design issue which is context sensitive. Before commenting a system to be "secure" or "insecure", there are a bunch of questions to make clear: -- what're the security assumptions? (are you assuming the entire OS is trustworthy and bug-free?) -- how strong the adversaries are? (computational resources + what they can/cannot do) -- what are entities to be protected? (data? code? execution? or what?) -- ... --In OS security, there are three main goals: * confidentiality: protecting data or other information from being fetched by other parties. * integrity: protecting the data or executions to be in the "incorrect" state, without being tampered by adversaries * availability: allow systems to function when valid users require services [skipped] --an example: [with some possible security topics] calculating "1 + 2" And you want... // regarding confidentiality: ...to prevent other processes/users to see the results [memory isolation, file system permission, cryptography] ...to prevent the OS to see the computation [Trust Execution Environment, Intel SGX Homomorphic Encryption] ...(if you've run many programs) to retrieve one result without letting others know which one result you fetch [Private Information Retrieval, Oblivious RAM] // regarding integrity: ...to prevent the data ("1", "2", and the result "3") from being modified [data integrity storage, memory integrity] ...to prevent the computation from being tampered with [Execution Integrity: replication, attestation, and verifiable computation] // regarding availability: ...to prevent adversaries from disrupting the calculation and making the machine unavailable (deny-of-service attack) [DoS and DDoS defense] --In fact, security is a broad topic that include: (see slides, S&P'24 CFP, https://www.ieee-security.org/TC/SP2024/cfpapers.html) --a set of interesting problems: -- crypto: zero-knowledge proof -- ML security: adversarial attacks -- hardware security: meltdown & spectre 3. Authentication * Motivating example: -- you have a top secret in a secure room -- there is only one entrance, allowing one person at a time -- how to design a system that only allows you to get into the room? -- assuming very powerful attackers (for example, aliens) --Question: can we be able to defend this attack at all? --"rubber hose attack" --torture users to get their passwords (or any secret in general) --idea: plant a secret directly into human brain without having any conscious knowledge of the secret --concrete approach: --playing a game (similar to typing practice) --a sequence of chars appears often --people will have muscle memory of the char-sequence --without explicitly learn what is the string [Bojinov, Hristo, Daniel Sanchez, Paul Reber, Dan Boneh, and Patrick Lincoln. "Neuroscience meets cryptography: designing crypto primitives secure against rubber hose attacks." USENIX Security 2012.] --but sometimes hard to be available to everyone (for example, requiring special hardware support) * This is authentication. Authentication is the process of verifying one's identity. Approach 1: password --more broadly, this is based on something that the user **knows**. (other examples are security questions, PIN, ...) Passwords were originally deployed in the 1960s for access to time-shared mainframe computers. --plaintext passwords stored in files --attack: read the file --hashed passwords (assumption: you cannot revert a hash function) --attack: rainbow table attack --pre-compute hashes for all possible strings --find the users' password hashes in the rainbow table --return the plaintext password --hashed and salted password (in 1979, Robert Morris and Ken Thompson) --pair a password wit ha "salt" (a random number, like 128bits) --store the salted hash [=hash(password + salt)] --the password file contains: salted-hash and salt --Question: why rainbow table attack is not effective in this case? [answer: because a comprehensive rainbow table would be 2^128 times larger than the original rainbow table!] However, here is the password status quo: --Empirical estimates suggest that over 40% of sites store passwords unhashed --plaintext passwords: Rockyou and Tianya --hashed but unsalted: LinkedIn --improperly hashed: Gawker [J. Bonneau and S. Preibusch. The password thicket: technical and market failures in human authentication on the web. WEIS 2010.] Approach 2: based on what you have (like cell phone) --idea: something the user has can prove identity, for example, ID card, security token, smart card, ... --NEU's two factor authentication Approach 3: authentication by what you are --idea: unique biology features or behaviors can identify one person, for example, fingerprints, DNA, Apple face id, ... -Question: any example of using all three approaches? NEU's two factor authentication + iPhone (face id) OR NEU's two factor authentication + Android (fingerprint) -As an aside, question: which option will you choose: option 1: 50% losing 500 dollars option 2: 0.1% losing all the money you have [results: #option1 : #option2 = 14 : 27] [expected answer: option 2, because the probability is so low that it is unlikely to happen. BUT, the consequences is devastating!] --this reflects why many security approaches usually have lower priority than other features --and some security-enhanced systems have never been widely deployed