MIT OpenCourseWare http://ocw.mit.edu 6.033 Computer System Engineering Spring 2009 For information about citing these materials or our Terms of Use, visit: http://ocw.mit.edu/terms.Nickolai Zeldovich key ideas for today:open designidentity vs authenticatorauthenticating messages vs principals (message integrity, bind data)public key authentication --- new board ---security modelC - I - S last time: talked about some general ideas for how to build secure systemsdefensive design: expect compromise, break into parts, reduce privilegelast recitation, saw examples of what can cause parts to be compromisedfor the rest of the lectures: assume that we can design end-points to be correct & secure (hard but let's go along with this for now) figure out how to achieve security in the face of attackers attackers can look at, modify, and send messages basic goals that we want to achieve inside the server: guard - service authentication authorization confidentiality --- new board ---basic building block: cryptolet's look at how you might implement encryptiontwo functions, Encrypt and Decrypt C -> E -> I -> D -> S military systems, E and D are secret closed design problem: if someone steals your design, you're in big trouble hard to analyze system without at the same time losing secrecy key principle in building secure systems: minimize secrets! --- new board ---open designbig advantage: if someone steals design & key, can just change keyscan analyze system separately from the specific secret keyminimizes the secrets important principle in designing systems:figure out precisely what secrets distinguish bad guys from good guysit's very hard to keep things secretknowing what's important will allow you to focus on the right things same diagram but with keys going into E & Dexample of symmetric key crypto: one-time padXOR the message with random bits, which are the keyquickly describe XOR, why you get the original message backproblem: key is giant (but scheme is perfectly secure) stream ciphers: various algorithms that generate random-looking bitsno longer perfectly unbreakable, just requires lots of computationSLIDE: RC4 attack if keys reusedC->S: Encrypt(k, "Credit card NNN")S->C: Encrypt(k, "Thank you, ...") XOR two ciphertexts and known response to get unknown request message!never reuse keys with symmetric crypto! (one-time pad!) --- new board ---previously needed shared keys, doesn't scale RSA: public-key cryptographykeys for encryption, decryption differSLIDE: RSA algorithmshort example computation? p = 31, q = 23, N = 713 e = 7, d = 283 m = 5 c = m^e mod N = 5^7 mod 713 = 408 m = c^d mod N = 408^283 mod 713 = 5 difficult to generate e from d, and vice-versa assumption: factoring N is hard! much more computationally expensive than symmetric-key crypto!important property: don't need a shared key between each partyencrypting a message for someone is diff. than decrypting itserver can use the same key for many clients sending to it similarly tricky to use in practice how to represent messages? small messages are weak large messages are inefficient can multiply messages together need something called padding crypto mechanisms rely on computational complexitypick key sizes appropriately -- "window of validity" --- new board ---principal authenticationprincipal/identity: a way of saying who you areauthenticator: something that convinces others of your identityopen design principle sort-of applies herewant to keep identity public, authenticator privatefocus on what's distinguishing good guy from bad guyusually there's a rendezvous to agree on an acceptable authenticator authenticator types: right side of the boardreal world: SSN bad design: confuses principal's identity and authenticatorpasswordsassuming user is the only one that knows password, can infer thatif someone knows the password, it must be the userserver stores list of passwords, which is a disaster if compromisedcommon solution: store hashes of passwordsdefine a cryptographic hash:H(m) -> v, v short (e.g. 256 bits)given H(m), hard to find m' such that H(m') = H(m)foils the timing attack we had last timein theory hard to reversedictionary attack: try short character sequences, wordsphysical object magnetic card: stores a long password, not very interesting smartcard: computer that authenticates using crypto biometric oldest form of authentication: people remember faces, voicescan be easy to steal (you leave fingerprints, face images everywhere)unlike a password, hard to change if compromisedmore of an identity than authentication mechanism need to trust/authenticate who you're providing your authenticator to!fake login screen, fake ATM machine can get a user's password/PINnext recitation you'll read more about what happens in the real worldweb phishing attacks: convincing you to authenticate to them --- new board ---suppose we trust our client (e.g. laptop, smartcard, ...)how to design protocol?board: C - I - S diagramclient sending a message saying "buy 10 shares of Google stock"simple version: just send password over the networkattacker has password, can now impersonate userbetter version? send a hash of a passwordattacker doesn't get our password (good, probably)but the hash is now just as good -- can splice it onto other msg! ** need both authentication AND integrity ** better? include checksum of message, eg CRC attacker can re-compute checksum! need checksum to be keyed better yet: send a hash of [ message + password ], called a MAC message authentication code if you're going to do this: look up HMAC best: establish a session key, minimize use of password (long-term secret)send a message to the other party saying "i will use this key for a bit"use that key to MAC individual
View Full Document
Unlocking...