Security

1. Security Lecture 17 COMP 416 Fall 2010 COMP 416 :: Fall 2010

2. Security • Often the most overlooked and misunderstood part of computer science. • We will not even attempt to be comprehensive. • For more: • Mike Reiter • UNC Undergrad / Ph.D from Cornell • Director of cyber-security lab at CMU • Now kicking ass at UNC • Fabian Monrose • Shamelessly stolen from Johns Hopkins COMP 416 :: Fall 2009

3. Where we need security • Model situation: • Where do we need security? • Protect client from script. • In this case, server is the “bad” guy • Protect communication between client and server. • In this case, anyone can be the “bad” guy. Server Client Data Web Server Browser Script CGI COMP 416 :: Fall 2009

4. Basic Security Needs • What are the basic security questions (or needs) of the client and the server: • Client: • Is the server who the server says it is? • Is the script safe to run? • Is the data correct? • Is the data private? In other words, are we sure that no one else can get/use this data? • Server: • Is the client who the client says it is? • Is the data correct and private? COMP 416 :: Fall 2009

5. Categories of Security Needs • Authentication • Make sure that you are talking to who you think you are talking to. • Privacy • Ensure that no one else can use or get the data. • Safety • Feel safe executing programs that were written by strangers. COMP 416 :: Fall 2009

6. Authentication • Fundamental fact: • You have to trust something or someone eventually. • Establishing trust: • Challenge/Response • Ask the other party questions that only it should know. What are some human context examples? • Call your bank, they ask you for your SS#, maiden name, address, etc. • Third party authentication • Ask someone else to vouch for the other party. COMP 416 :: Fall 2009

7. Certificates • A certificate is used to make a claim of identity and/or authenticity. • Parts of a certificate: • Name of party and any other information about themselves that they want to present as authentic. • Name of certificate authority • Digital signature of certificate authority (CA) • If you trust the CA, you can trust the info. • Key to the trust is in the signature. COMP 416 :: Fall 2009

8. Digital Signatures • Certificate authority issues certificates and “signs” them digitally for authenticity. • What functions must the signature provide? • Info. presented in certificate is the same info. originally presented to the CA in the first place. • Verify that signature is really from CA. • Digital signatures work by using “public-key cryptography” COMP 416 :: Fall 2009

9. Public-key Cryptography • Diffie-Hellman, 1976 • Trap-door function • A function with that can be used with two pieces of information (numbers) with the following property: • Call the two pieces of information PUB_KEY and PRIV_KEY • Message to be encrypted: P • E(P, PUB_KEY) => C, where C is encrypted message. • D(C, PRIV_KEY) => P • PRIV_KEY can’t be calculated from PUB_KEY COMP 416 :: Fall 2009

10. Using public key crypto Bob Alice 1) Alice generates a key-pair. COMP 416 :: Fall 2009

11. Using public key crypto Bob Alice 2) Alice gives Bob the public key COMP 416 :: Fall 2009

12. Using public key crypto Hello gekdisa3 Bob Alice 3) Bob encodes message using public key COMP 416 :: Fall 2009

13. Using public key crypto gekdisa3 Hello Bob Alice 3) Alice decodes with private key COMP 416 :: Fall 2009

14. Symmetric Keys • Public-key systems are symmetric • Only the private key can decode message encoded by the public key. • Only public key can decode messages encoded by the private key. A => f(private_key) => A` A` => f(public_key) => A COMP 416 :: Fall 2009

15. Back to authentication. • Quick review: • Server presents certificate with lots of info signed by trusted certificate authority. • Client must be assured that signature vouches for the info and that signature is from the CA. • How does public-key cryptography help? • Trusted CA publishes its public key. • What are the issues here? • Signature is simply a digest of the certificate encoded with CA’s private key. • Client uses public key to decode signature and check digest against the info. COMP 416 :: Fall 2009

16. Digests • What does “digest” mean? • A smaller version of the same information. • In security: a small message that is generated mathematically from a larger one. • What properties do we want from digest function? • Easy to calculate. • Hard to predict. • Sensitive to initial conditions. COMP 416 :: Fall 2009

17. RSA • RSA is one specific public-key system • Patent expired. • RSA stands for Rivest, Shamir, and Adleman • Based on numerical properties of... • Modular arithmetic • Prime numbers • Factorization COMP 416 :: Fall 2009

18. How RSA works. • Pick two prime numbers. • p, q • Roughly equal size in bits. • The number p*q is called the modulus m. • Now find two numbers e and d. • Relationship: e*d-1 = k * (p-1) (q-1) • Public key is (e, pq) • Private key is (d, pq) COMP 416 :: Fall 2009

19. How RSA works • To encode: • Break up message into fixed-size blocks. • Treat each block as one big number. • Must be sure that max. value is less than pq. • For each block bi, calculate ci = bie mod pq • To decode: • From ci calculate bi = cid mod pq • Notice the symmetry. COMP 416 :: Fall 2009

20. RSA cont’d. • Large number exponentiation. • Whenever intermediate results get larger than the modulus, simply mod them back into range. int mod_exp (int b, int e, int m) { int res = 1; while (e != 0) { if (e % 2 == 1) res = (res * b) % m; b = (b * b) % m; e = e >> 1; } return res; } COMP 416 :: Fall 2009

21. Breaking RSA • Inverting this is hard • ci = bie mod pq • That’s the “one-way” part. • Key to breaking RSA is figuring out p and q from p*q. • Then, given public key (e, pq), you can derive what d (the private key) is. • Fortunately, factorization is hard. COMP 416 :: Fall 2009

22. Private communication • Public-key systems are slow. • OK for things like digital signatures • Not so good for long streams of communication. • Private key systems • Both endpoints have the same key which is used to encrypt/decrypt the message. • Lots of algorithms (DES is very famous) • What’s the problem? • Key exchange • What’s the solution? • Use public-key system to exchange a “session” key and then use the session key for crypto. COMP 416 :: Fall 2009

23. SSL • Secure Sockets Layer • URL starts with “https” • Sits between HTTP and TCP. • SSL Handshake • Server provides certificate to client with public key • Client uses key to exchange info. with server and generate a session key. • HTTP works just the same. • TCP works just the same. • SSL acts like a filter between them encrypting/decrypting everything. COMP 416 :: Fall 2009

24. Client-side Programming • Sandbox • Limit execution privileges of scripts. • Same origin policy. • No local filesystem privileges. • Signed Scripts • Present a certificate that vouches for the script. • Expanded privileges granted to signed script either by policy or by user via dialog. COMP 416 :: Fall 2009

25. Discussion • Everything ties back to authentication. • Specifically, you need a way to trust that the public key for someone is really their public key. • Why should we trust a particular certificate? • Web of trust. • If enough people say that the certificate is valid, then we trust that it is valid. • Key point: no central point of failure. • Implication: centralized security (gov’t or otherwise) very vulnerable and highly suspect. COMP 416 :: Fall 2009

26. Last points • Trade-off between flexibility and modes of failure. • Security based on secret algorithms almost always fails. COMP 416 :: Fall 2009