Today’s Lecture

1. Today’s Lecture • intro to security in networking • confidentiality • integrity • authentication • authorization • orientation for assignment 3

2. Security Goals • confidentiality: Who can read this data? • integrity: Who can modify this data? • authentication: Who am I talking to? • authorization: Is this person allowed to do this operation?

3. Network Security Challenges • on the net, often communicate indirectly, through intermediaries • intermediaries can eavesdrop or corrupt messages • interact with unlimited number of parties • frequent interactions with untrusted people

4. key key ciphertext plaintext plaintext encrypt decrypt Private Communication Practical issues: - security of end systems - how to establish a shared secret key

5. In Assignment 3... • use AcmeNet.Util.AcmeCipher cipher • constructor • cipher = new AcmeCipher(long key); • to encrypt a byte • ciphertext = cipher.crypt(plaintext); • same to decrypt • 64-bit (Java long) key

6. Key Establishment • use armed courier • slow and expensive • use face-to-face meeting • doesn’t scale • use cryptographic tricks • good: no face-to-face meeting required • bad: hard to get right

7. Diffie-Hellman Algorithm • the big picture • two strangers have a public conversation • result is a secret shared between them • eavesdroppers can’t learn the secret • patented; patent expired in September • relies on difficulty of finding “discrete log” • assume g and p are chosen cleverly • given gx mod p, very hard to determine x

8. Alice Bob agree on g and p generate random A generate random B Ma = gA mod p Mb = gB mod p Mb Ma compute K = MbA mod p = gBA mod p compute K = MaB mod p = gAB mod p Diffie-Hellman in Action

9. Ma Ea Mb Eb encrypted data encrypted data But Wait... Dr. Evil Bob Alice

10. What’s Going On? • Diffie-Hellman gives you a private connection to somebody • but you don’t know who is at the other end • need to take separate steps to prevent man-in-the-middle attack • digitally sign Diffie-Hellman messages, or • do separate authentication phase later

11. In Assignment 3... • AcmeNet.Util.DiffieHellman class implements the math • built-in choice of g, p • to do an exchange • make a new DiffieHellman object • read its gx field and send it across • get arriving message and pass it to the gotMessage method of your Diffie-Hellman object • use the key field of the Diffie-Hellman object

12. In Assignment 3... • PrivateConnection class extends Connection, adding privacy • start with an ordinary Connection • do a Diffie-Hellman exchange on the connection to generate a private key • encrypt subsequent data on the connection with the DH-generated key • no guarantees about who is on the other end

13. Authentication • How can we protect against impersonation? • two approaches • digital signatures (and similar schemes) • trusted third party • usual approach: claim identity, then prove it • sometimes, authenticate and exchange keys in a single protocol

14. Digital Signatures • everybody has two keys • a private key for signing • a public key for verifying signatures • need a secure way to find the keys of others • trusted certification authority signs “key certificates”, or • “letter of introduction” approach

15. Using Signatures (First Try) • challenge/response protocol • how Alice proves her identity to Bob • Bob sends a random “challenge” to Alice • Alice signs the challenge and sends it back • Bob verifies the signature • prone to man-in-the-middle attack

16. Signatures and Diffie-Hellman • after D-H exchange, each side concatenates the message it sent and the message it received, and signs the pair • verify the other side’s signature • nice synergy • message sent by D-H acts as a challenge • signatures protect D-H from man-in-the-middle

17. Trusted Third Party Auth. • Alice and Bob have a three-way conversation with a third party (“Trent”) • result is a key that only Alice and Bob know • no need for signatures or public-key crypto • Trent must be completely trustworthy or all is lost • each party must share a key with Trent

18. Needham-Schroeder Protocol • steps • Alice and Bob state their identities • they could be lying! • Alice sends to Trent (“Alice”, “Bob”, na) • Trent generates a key K, creates a “ticket” (“Alice”, K) and encrypts it with Bob’s key • Trent sends to Alice (na, “Bob”, K, encrypted-ticket), all encrypted with Alice’s key • Alice sends the encrypted ticket to Bob

19. Needham-Schroeder • in the end, either • Both parties are telling the truth about their identities, and both know the key K, or • at least one party is lying, and the liar doesn’t know K • do a challenge-response handshake to verify knowledge of K in both directions • if handshake works, use K to encrypt data

20. Key Verification Handshake • steps • set up encryption using the new key K • actually, use K in one direction, K+1 in the other • send a random challenge to the other side • receive the other side’s challenge, and add one to it; send the result back • verify the other side’s response

21. In Assignment 3... • use a modified version of Needham-Schroeder protocol • set up PrivateConnection • do key-exchange/auth protocol • switch to newly generated shared key • trusted AuthenticationService lives at a well-known location • talk to AuthService via PrivateConnection

22. In Assignment 3... • each student has his/her own identity • String identity equal to Unix userid • each student shares a key with the AuthService • 64-bit value • think of it as a password • stored in protected file accessible to AuthService

23. Generating Your Key • can use AcmeNet.Util.Login to translate a String or byte-array into a Java long • can use text passphrase rather than a number • email exchange to set up keys • please don’t • use a serious secret as your key • use an easily guessable key • use the Assn 3 algorithms for high security applications

24. More About Security • public-key cryptography • key management issues • tamper-proof devices • authorization • logging, auditing and post-mortem repair • intrusion detection • policy creation and enforcement • etc.