Authentication and Secure Communication

1. Authentication and Secure Communication Jeff Chase Duke University

2. technology people Where are the boundaries of the “system” that you would like to secure? Where is the weakest link? What happens when the weakest link fails?

3. The First Axiom of Security • “Security is at least as much a social problem as it is a technical problem.” • Translation: humans are the weak link. • We will focus on the technical elements, but do not lose sight of the social dimension. • Keys left in lock • Phishing • Executable attachments • Trojan software • Post-it passwords • Bribes, torture, etc. • Etc.

4. Exhibit A This is a picture of a $2.5B move in the value of Emulex Corporation, in response to a fraudulent press release by short-sellers through InternetWire in 2000. The release was widely disseminated by news media as a statement from Emulex management, but media failed to authenticate it. EMLX [reproduced from clearstation.com]

5. “Humans are incapable of securely storing high-quality cryptographic keys, and they have unacceptable speed and accuracy when performing cryptographic operations. (They are also large, expensive to maintain, difficult to manage, and they pollute the environment.) It is astonishing that these devices continue to be manufactured and deployed. But they are sufficiently pervasive that we must design our protocols around their limitations.” - Kaufman, Perlman, and Speciner As quoted in:

6. Trusted vs. Trustworthy (NSA) • Trusted • A component that can break the security policy if it fails. (“It has power.”) • Integrity cannot be verified by external observation. (“You can’t tell if it breaks”.) • Trustworthy • A component that is unlikely to fail. • Trusted Computing Base (TCB) • The minimal core of a computer system that is trusted, and so must be trustworthy if the system is to remain safe.

7. Questions and Answers #1 • Who is the sender? • Authentication • Is the sender allowed to do this? • Authorization • Is this really what the sender said? • Integrity • Could anyone else have intercepted it? • Privacy

8. Questions and Answers #2 • Authentication? • Challenge/response: passwords, certificates • A subject bound to a strong identity is a principal. • Authorization? • Access control lists or capabilities (ticket/token) • Integrity? • Message digests and digital signatures • Privacy • Encryption (provides integrity too) All of these require some form of a shared secret or shared trust in a third party, or both.

9. Security Cryptography Security algorithms services Secret Public Message Privacy Authentication Message key key digest integrity (e.g., DES) (e.g., RSA) (e.g., MD5)

10. Alice First participant Bob Second participant Carol Participant in three- and four-party protocols Dave Participant in four-party protocols Eve Eavesdropper Mallory Malicious attacker Sara A server Familiar names for the protagonists in security protocols

11. Cryptography for Busy People • Encrypt and Decrypt functions • M = Decrypt(Encrypt(M) • Standard and efficient enough to be practical. • Crypto functions are parameterized by keys. • Fixed-width “random” value (length matters) • M = Decrypt(Encrypt(M,K1), K2) • Two fundamental variants: • Public-key or asymmetric crypto (e.g., RSA) • Secret-key, private-key, symmetric crypto (e.g., DES) • Foundation of many/all protection systems.

12. Crypto Properties • Given Encrypt(K1, M) • cannot compute M (without K2). • Given M and Encrypt(K1, M) • cannot compute K1 or K2 • Given M • cannot compute M1 such thatDecrypt(K2, M1) = M (without K1) • “Cannot” means “it is believed to be computationally infeasible to”.

13. Using Crypto: the Basics • Privacy • Attacker cannot read encrypted data. • Integrity • Encrypt a hash/checksum/digest of the message. • Digital signature • Append signature to the message • Authentication • Force party to prove it possesses some key that only the “right” entity would/could/should know. • How to do that safely?

14. Simple shared-secret based cryptographic authentication shuque@isc.upenn.edu

15. Replay Attacks and Nonces • The “random” challenge is a nonce • “number used once” • Receiver encrypts the nonce and sends it back. • Why is the challenge “random” or “only used once”? • An attacker could replay a previous response • The replay could falsely authenticate the attacker as Alice • Nonces can be timestamps, serial numbers, etc. • Replay attacks are a common threat, and nonces are widely used in security protocols.

16. Symmetric Crypto • “Secret key” or “private key” cryptography. • DES, 3DES, DESX, IDEA, AES • Sender and receiver must possess a shared secret • Shared key K • K = K1 = K2 • Message M, Key K {M}K = Encrypt(M, K) M = Decrypt({M}K , K)

17. Asymmetric Crypto • Sometimes called “public key” cryptography. • Each subject/principal possesses a keypair: K-1 and K • Decrypt(K, Encrypt(K-1, M)) = M • Each principal keeps one key private. • The inverse key may be public. • Either key can be used to encrypt/decrypt. • Encrypt() = Decrypt() • K1 = K and K2 = K-1 OR K2 = K and K1 = K-1

18. Pros and Cons Symmetric crypto (DES, AES, …) • Pro: cheap and easily supported by hardware • Con: need a shared secret. • Shared secrets are harder to keep secret. • key distribution problem Asymmetric crypto (RSA, etc.) • Con: expensive • Pro: no need for a shared secret • The recipient just needs to know sender’s public key. • Multicast or broadcast? Message storage? No problem. • Solves the private-key distribution problem • Con: introduces a new public-key distribution problem • How to bind public key to identity securely?

19. KA Alice’s secret key KB Bob’s secret key KAB Secret key shared between Alice and Bob KApriv Alice’s private key (known only to Alice) KApub Alice’s public key (published by Alice for all to read) { M } K Message M encrypted with key K [ M ]K Message M signed with key K Figure 7.3Cryptography notations

20. Key size/hash size Extrapolated PRB optimized (bits) speed (kbytes/s) (kbytes/sec.) TEA 128 700 - DES 56 350 7746 112 120 2842 Triple-DES IDEA 128 700 4469 512 7 - RSA RSA 2048 1 - MD5 128 1740 62425 160 750 25162 SHA Performance of encryption and secure digest algorithms

21. Secure Communication with an Untrusted Infrastructure Mallory ISP D ISP B Bob ISP C ISP A Alice

22. Better Together, Part 1 • Use asymmetric crypto just to “handshake” and establish a secret session key. • Converse with the efficiency of symmetric crypto. • Example: Secure Sockets Layer (SSL) or Transport-Layer Security (TLS), used in HTTPS. • End-to-end security above TCP. “SYN, etc.” “My public key is K.” “Let’s establish a session key: {S}K.” Server Client {M}S …

23. SSL is not so simple… • How do we know who we are talking to? • Do we care? Somebody does… • How do we prevent replays of encrypted content? • SSL/TLS uses this basic handshake protocol, but there are many other aspects: • Nonces, serial numbers, timestamps • Hashes and MACs • Certificates • First some background…

24. Authenticity on the Cheap • How can the sender/writer A of M allow any receiver B to verify or prove that A sent/stored M? • authenticity • Answer: encrypt the message, or just a digest. • A computes digest h(M) using a secure hash. • A encrypts digest: {h(M)}K • A appends encrypted digest to M • B decrypts digest with matching key • B computes h(M) and compares to digest. • Proves that sender of M was in possession of K.

25. Secure Hash / Message Digest • Well-known, standard, hash functions digest = h(M). • MD5, SHA1 (Secure Hash Algorithm) • Very efficient to compute. • M is arbitrary length • Digest is a small, fixed-width quantity: i.e., it is a hash. • Often called a fingerprint or cryptographic checksum. • An encrypted digest can be thought of as a “signature”. • Unforgeable: need the right key to encrypt • Securely bound to a specific document! • Easy to check

26. Properties of Secure Hashing • Collision-resistant • There exist distinct M1 and M2 such that h(M1) == h(M2). • Such collisions are “hard” to find. • One way • Given digest, cannot generate an M with h(M) == digest. • Such collisions are “hard” to find. • Secure • The digest does not help to discover any part of M. Hasn’t SHA-1 been broken? Sort of…it turns out collisions are easier to find than thought, at least in some instances.

27. Two Flavors of “Signature” • A digest encrypted with a private asymmetric key is called a digital signature • “Proves” that a particular identity sent the message. • “Unforgeable” • The sender cannot deny sending the message. • “non-repudiable” • Legally binding in the US (if using strong policies to protect and endorse keys). • A digest encrypted with a shared symmetric key is called a message authentication code (MAC). • faster, but…

28. Digital signatures with public keys

29. Low-cost signatures with a shared secret key Message authentication code (MAC) • Pro: fast • Con: repudiable • Con: shared secret

30. Certifying Public Keys • Digital signatures enable any entity to endorse the (public key, identity) binding of another entity. • A certificate is a special type of digitally signed document: • “I certify that the public key in this document belongs to the entity named in this document, signed X.” • E.g., certificate format standard X.509 • Provides a “toehold” to address the crucial problem of public-key distribution. • Recipient must trust the issuer X, and must know the public key of X.

31. S u b jec t D i s t i n g u is he d N a m e, Pu b l ic K e y Iss ue r D i s t i n g u is he d N a m e, Si g n at u r e Pe ri o d o f v a li d i t y N o t Be f o r e Da t e, No t A f t e r D ate A d m i ni str a t ive i n fo rma ti o n V er si o n , S e r i a l N u mb e r Ex t en d e d I n f or m a t i o n Figure 7.13X509 Certificate format

32. Certifying Authorities and Trust Management • What (id)entities do you trust? • To do what? • I trust Amazon if I want to buy stuff, but I don’t give them the keys to my house. (?) • In general, your trust in a public key depends on: • Security attributes of the identity bound to it. • Who endorsed it for me. • A certifying authority (CA) is an identity trusted by some community to issue/endorse certificates. • Public key of CA is widely available to community. • E.g., the public key of Verisign is wired into every browser.

33. Approaches to Public Key Distribution • The “key” challenge today is public key distribution (and revocation). • Approach #1: trust e-mail/web (i.e., assume DNS and IP really go where you want, and authenticate the source.) • Example: PGP, GPG, “pretty good”…or do it in person. • Approach #2 : use a Public Key Infrastructure (PKI) • Requires everyone to agree on a central point of trust (Certifying Authority or CA). • Difficult to understand and deploy. • Hierarchy helps. • Approach #3: “web of trust” in which parties establish pairwise trust and endorse public keys of third parties. • Local example: SHARP. Involves transitive trust.

34. Certificate Hierarchyor Web of Trust • Chain of Trust • If X certifies that a certain public key belongs to Y, and Y certifies that another public key belongs to Z, then there exists a chain of certificates from X to Z • Someone that wants to verify Z’s public key has to know X’s public key and follow the chain • X forms the root of a tree (web?) • Certificate Revocation List • What happens when a private key is compromised? [Vahdat]

35. PKI • Public Key Infrastructure • Everyone trusts some root CAs. • Sure…. • Institutions/organizations set up their own CAs, and the root CAs endorse them to issue certificates for their members. • $$$ • And so on, recursively, to form a hierarchy like DNS. • Network applications will have access to the keypairs and certificates of their users, and will validate the certificates of servers. • Any day now…

36. What happens… • How to authenticate shop.com? • How to assure integrity/privacy of communications? • How to prevent man-in-the-middle attack? • How does shop.com authenticate you? https://www.shop.com/shop.html

37. Secure HTTP • Uses SSL/TLS over TCP. • Browser always authenticates the server. • Server presents certificate signed by root CA. • Domain name must match the certificate, etc. • Browser has some set of public keys for root CAs wired into it, so it can check the signature. • Server optionally requests to authenticate the browser. • Browser presents certificate. • Password authentication is much more common. • Browser and server negotiate a bulk cipher and secret session key.

38. A Short Quiz • What is the most important advantage of symmetric crypto (DES) relative to asymmetric crypto (RSA)? • What is the most important advantage of asymmetric crypto relative to symmetric crypto? • What is the most important limitation/challenge for asymmetric crypto with respect to security? • Why does SSL “change ciphers” during the handshake? • How does SSL solve the key distribution problem for symmetric crypto? • Is key exchange vulnerable to man-in-the-middle attacks?

39. CPS 110, Fall 2008 • All the preceding material is “fair game”. • The preceding material is also presented in a different way on Landon Cox’s slides. • The following details of SSH, Kerberos, TPM, etc. are left in for completeness, but will not be tested. • I discussed TPM briefly in class, but I only expect you to understand the key idea: the hardware platform makes signed assertions to software about the software running below it, and it can hide data (keys) if the software stack is not “right”.

40. CPS 110 Fall 2008, continued • We discussed TPM with reference to Butler Lampson’s “Accountability and Freedom”, which can be found through Google. • Key ideas from Lampson’s presentation that are “fair game”: • Concept of “reference monitor” • Classical security based on Authentication, Authorization, and Auditing • Alternative approaches based on reputation and accountability: punishing transgressions after the fact.

41. Handshake Protocol Structure ClientHello S C ServerHello, [Certificate], [ServerKeyExchange], [CertificateRequest], ServerHelloDone [Certificate], ClientKeyExchange, [CertificateVerify] Finished switch to negotiated cipher switch to negotiated cipher Finished

42. Figure 7.18SSL handshake protocol

43. SSL SSL Change SSL Alert Handshake HTTP Telnet Cipher Spec Protocol protocol SSL Record Protocol Transport layer (usually TCP) Network layer (usually IP) SSL protocols: Other protocols: Figure 7.17SSL protocol stack

44. Component Description Example Key exchange the method to be used for RSA with public-key method exchange of a session key certificates Cipher for data the block or stream cipher to be IDEA transfer used for data Message digest for creating message SHA function authentication codes (MACs) Figure 7.19SSL handshake configuration options

47. OpenSSH • Uses SSL • User’s public key installed on host side • Host’s public key installed on client side • Or Kerberos

48. SSL Questions • How do SSL endpoints verify the integrity of certificates (IDs)? • Does s-http guarantee non-repudiation for electronic transactions? Why/how or why not? • Does SSL guarantee security of (say) credit numbers in electronic commerce?

49. "Using encryption on the Internet is the equivalent of arranging an armored car to deliver credit-card information from someone living in a cardboard box to someone living on a park bench" - Gene Spafford, CERIAS @ Purdue

50. More PKI • (Public key) infrastructures • Many organizations now have set up their own • Many have not (e.g., Duke) • Public (key infrastructure) • Still elusive • Failure of Secure Electronic Transactions (SET)