Essentials of Security Zachary G Ives University of

Essentials of Security Zachary G. Ives University of Pennsylvania CIS 455 / 555 – Internet and Web Systems

Administrivia Midterm results returned today After +15 points bonus credit: § Mean 88, St. Dev 14. 8 § Max 115, Min 62 Please read PNUTs paper for Monday 2

Distributed Security and E-Commerce § Transactions make sure things happen when we want them to… § Security makes sure things don’t happen when we don’t want them to! § Let’s look at some essentials of security in distributed environments 3

Basic Terminology § Authorization: determines mode of access allowed Common solutions: access control lists, capabilities, … We previously discussed how views could be used to define authorization levels § Authentication: means of verifying identity Common cases: password/UID, PIN, fingerprint, demonstration of ability to encrypt with private key, etc. § Encryption: used to protect data A common notation, used in the chapter from Lewis/Bernstein/Kifer that appears in your reader: ciphertext = Ksender[plaintext ] plaintext = Kreceiver[Ksender[plaintext ]] Let’s look at encryption in detail… 4

Authorization (Access Control) Capabilities § Special, hard-to-forge “handles” or “pointers” to objects/services § Independent of authentication of who a user is § Possessing a capability you can use the service/object e. g. , pass-phrase; SHA-1 key; private key; etc. § Capabilities are easy to pass on to others, but hard to revoke Access Control Lists (ACLs) § During each access to an object/service, authorization is checked against a list Usually a notion of different groups, rights e. g. , Unix or Windows file system; most databases § Easy to revoke rights; hard to pass them on § Requires a scheme for authenticating a user Most common approach today 5

Granularity: What to Control § In a file system, ACLs are checked at the granularity of an open, a read, a write, etc. to a whole file § Analogous process holds HTTP server, when we protect directories, files § This is great for large, atomic units, e. g. , images § But sometimes we need finer-grained detail § If exporting XML, we may want to expose different data to marketing than we do order fulfillment § Add access control lists over views of the data, i. e. , query results 6

Hypothetical View-Based Protection Example define function Marketing. View() returns purchase* { for $p in doc(“purchases. xml”)/purchases/purchase where $p/date() >= fn: todays-date() – fn: date. Interval(0, 1, 0) return { $p/isbn } { $p/addr/state } } define function Order. Fulfillment. View() returns purchase* { for $p in doc(“purchases. xml”)/purchases/purchase return $p } grant permission read on Marketing. View to Marketer. Group grant permission read on Order. Fulfillment. View to Warehouse. Group 7

View-Based Security § Views restrict attributes and values that are visible § Thus restricting the queries that can be posed § Much more powerful than simply restricting documents § Caveat: not always enough to guarantee security – sometimes information is inadvertently “leaked” § Might correlate info from multiple tables with different attributes § Might know, e. g. , that there’s only one customer in a given state… § OK, so how do we enforce that data is limited only to those who are authorized to access it? § Let’s look at some attacks… 8

Common Single-Machine Attacks § “Social engineering” – e. g. , phishing, malware – enables a machine to authenticate as you § Often, this enables it to do things – e. g. , purchase items as you (on the Internet), or modify your files (on your machine) § Privilege escalation – finding a design flaw in software allowing normally-disallowed privileges § e. g. , finding a way to get root permissions through an exception § Code injection – finding a way to send data to a system, such that it will execute it as code § e. g. , SQL injection, stack smashing, cross-site scripting (one site injects data that gets interpreted as Java. Script in another protection zone) 9

Network-Centric Attacks § How do we ensure, on a TCP/IP network: § We know who we’re talking to, so we give them the right permissions? § Nobody can eavesdrop on our communication and steal our data? § Let’s start with some vulnerabilities 10

Message-Dropping Attacks § Can happen if someone manages to get between “us” and whomever we’re conversing with § How might this happen? § By and large, our protocols are resilient to occasional dropped messages § Not much happens without acknowledgement – we frequently time out C S “order” “confirm? ” C S 11

Replay Attacks § A very simple attack § Intruder doesn’t need to understand or alter the contents of a message – just send it multiple times § Can be all at once, or can play the message again a week later… “buy 5 copies” C I S 12

Message Forging Attacks § Generally more difficult than the first two classes § Needs the ability to modify messages from the sender “buy 5000 copies, ship to Hawaii” “buy 5 copies” C I S 13

“Man in the Middle” Attacks § The intruder impersonates both the client and the sender § Sometimes, this is by “IP spoofing” – pretending that packets originate from a different host § Intruder can masquerade as the client from then on “Hi, amazon. com, my password is 1234” C “Hi, amazon. com, my password is 1234…” S I “Welcome to amazon. com” “… and I’d like to buy a red Mazda Miata…” schuylkill. com amazon. com 14

Distributed Security Generally, we’re going to: § Try to ensure that messages can’t be replayed § Try to ensure that messages are unforgeable § See if we can avoid mostman-in-the-middle attacks 15

Encryption/Decryption Illustration from Lewis/Bernstein/Kifer 16

Symmetric Cryptography § Uses the same key for encryption and decryption § Aka secret key crytography § Block cipher: block of text ciphertext block § Substitution cipher – simple substitutions of char(s) for char(s) § Transposition cipher – reorder the chars in the block § DES (Data Encryption Standard) – only 56 b key Sequence of stages that encrypt one another’s output Makes it less vulnerable to frequency analysis attack § Non-block cipher § Bitstream cipher XORs plaintext with pseudo-random numbers generated when key is used as seed value What if the random number generator isn’t very random? 17

Asymmetric Encryption § This is public/private-key encryption (public key cryptography) § Here: M = KCpriv [KCpub [M]] § For two-way communication, use a second key-pair § (Often public key algorithm is commutative, though) § First proposed public-key encryption scheme was Diffie. Hellman ’ 76 § But we generally use RSA 18

RSA Algorithm 1. Create two large, e. g. 1024 b, relatively prime numbers, p and q Choose decryption int. d relatively prime to (p - 1)(q - 1) Choose encryption int. e so gcd(e, d) = 1 (commonly 3, 17, or 65537) 2. Break message into blocks, M, treated as ints from 0 to pq – 1 Encryption key = (e, pq) Decryption key = (d, pq) 3. 4. To encrypt, C = Me (mod pq) To decrypt, M = C d (mod pq) § Works because M = (Me (mod pq))d (mod pq) due to “elementary number theory” Relies on fact that factoring pq is (believed to be) expensive § 19

Digital Signatures -- I/II § Frequently, we need to sign a message to verify it came from us (or our server) § Can use asymmetric cryptography if M = KCpub [KCpriv [M]] § Encrypt message with private key; validate with public key § (Obviously, others need to get the public key) 20

Digital Signatures – II/II § Less costly: message digests § Compute a one-way hash, f(M), with these properties: All values in f’s range are equally likely s Unlikely that we can find M’ where f(M) = f(M’) because large number of Ms map to same region If any bit of the message is changed, every bit in f(M) has a 50% chance of changing s f(M), f(M’) aren’t same simply because M, M’ are similar § Encrypt this, KCpriv[f(M)] and send with M § Just given this, what attacks might be possible? 21

Nonces Prevent Replay Attacks § To prevent replay attacks, we need to ensure that a message would be different each time it’s sent, and we keep track of what we’ve already seen § A nonce is a special bit string that’s difficult to forge but easy to authenticate § Commonly, the client or server will pick some value N and encrypt it § Responses will return N+1 (encrypted), etc. § Frequently, the initial N is a timestamp or message counter § A form of a nonce called salt is often added not for authentication, but to make it harder to guess the message content 22

Key Distribution § Whether public or secret key cryptography is used, must be able to tell who we’re talking with: § Need to negotiate a session key (Kerberos) § or need to get a public key (SSL) § Why is authentication critical? 23

The Kerberos Protocol (from MIT) § Used commonly to authenticate to a server § Relies on a trusted third party Key Distribution , a Server § Users and servers have kerberos authentication keys, KC, KDS, used to authenticate with the KDS § The KDS creates a session key and distributes it in a ticketthat’s used for conversing with the server S § Can also provide single sign-on: one authentication that’s shared across machines § Give a ticket-granting ticket is used to talk with a that ticket-granting server a way that’s similar in 24

Tickets and Kerberos names of C, S in cleartext KC, KS[Ksess, S, TTL] KS, KS[Ksess, C, TTL] KC, KS = f(PC) Illustration from Lewis/Bernstein/Kifer Ksess[C, time] 25

E-Commerce § Clearly, one of the biggest uses of authentication on the Web today § B 2 B: can often negotiate secret keys between pairs § Selling to consumer (B 2 C/C 2 B) often requires several levels of authorization and authentication: § Want to authenticate the user § Want to authenticate the credit card company server § Want to check for user authorization to purchase § … And obviously, want to prevent eavesdropping and replay! 26

Secure Sockets Layer (SSL) § Like Kerberos, relies on a trusted third party § Certificate authority (CA) issues certificates to certify a server and its public key § Verisign is perhaps the best known of these § A server S generates public-private keypair § Sends the public key, other info (plus $$$) to Verisign (etc. ) § Gets back a certificate with: CA name S’s name, URL, public key Timestamp and expiration info 27

Example Certificate Owner: CN=GTE Cyber. Trust Root, O=GTE Corporation, C=US Issuer: CN=GTE Cyber. Trust Root, O=GTE Corporation, C=US Serial number: 1 a 3 Valid from: Fri Feb 23 23: 01: 00 GMT 1996 until: Thu Feb 23 23: 59: 00 GMT 2006 Certificate fingerprints: MD 5: C 4: D 7: F 0: B 2: A 3: C 5: 7 D: 61: 67: F 0: 04: CD: 43: D 3: BA: 58 SHA 1: 90: DE: 9 E: 4 C: 4 E: 9 F: 6 F: D 8: 86: 17: 57: 9 D: D 3: 91: BC: 65: A 6: 89: 64 28

The SSL Protocol § Client C connects to server S from enterprise E § S sends E’s certificate (cleartext) § C validates the certificate using the CA (e. g. , Verisign)’s public key § C generates and sends to S a session key encrypted with E’s public key § Java has built-in support for SSL (Java Secure Socket Extension, integrated in 1. 4) and a tool for managing certificates (keytool) 29

So… § The client and server know each other given SSL § How do we go ahead and make a purchase? § Most commonly: you enter your credit card number § Sometimes this is stored in the retailer’s system for future purposes! Best case: s The CC info is stored in a special, firewalled server, not part of the web site s Web server has other account info about you s When a transaction goes through, web site sends order to this special server, which combines it with CC info and sends it onward But often it’s not quite so secure! § Protocols have been proposed (e. g. , SET from VISA) that don’t use credit card info – but not really adopted 30