20-771: Computer Security Lecture 3: SSL

1. 20-771: Computer SecurityLecture 3: SSL Robert Thibadeau School of Computer Science Carnegie Mellon University Institute for eCommerce, Fall 2002

2. Today’s lecture • Java Task • Linux Task • Review Crypto • Envelopes • PKI • Diffie-Hellman • SSL/TLS • X.509v3 Certificates

3. This Week Chapters 3 WS Should finish off Crypto Book by Levy New: Read and Study the 1.0 version Of TLS Go to www.rfc-editor.org Search on TLS Download the RFC. MidTerm Question: 150 Words TLS(and SSL) support both RSA and Diffie-Hellman, step through the protocol and explain what differences in protocol are required.

4. Cryptography • A key is just the parameter that makes a program do something to the plaintext or the cyphertext that is very hard to discover. • Symmetric Cryptography = Private Key Systems • Great for the Privacy Function, Hiding Secrets • One Way Hashes = Digest Functions = Integrity Checkers = Password Storage • Great for Integrity Checking, Hiding Secrets • Public Key Cryptography = Public/Private Key Pairs = RSA Patent (sept 21) • Private Reads, Public Writes : Send Secret to Authentic Person • Private Writes, Public Reads = Signing: Authenticate Writer, no secret • Certificates : Signing, used for Authorization • CA : Authority who guarantees Authentication • Where to hide Private Keys? Key Escrow, Smart Cards, Floppy • PKI – the total system of keys, CA

5. Digital Envelopes Since public-key cryptography is real slow upto 3 orders or magnitude slower than symmetric systems, combine both systems Sender: • Generate a secret key at random called the session key (which is discarded after the communication session is done) • Encrypt the message using the session key and the symmetric algorithm of your choice • Encrypt the session key with the recipient’s public key. This becomes the “digital envelope” • Send the encrypted message and the digital envelope to the recipient

6. Digital Envelopes (cont.) Recipient • Receive the envelope, uses private key to decrypt it recovering the session key. • The message is secure since it is encrypted using a symmetric session key that only the sender and recipient know. • The session key is also secure since only the recipient can decrypt it. • Can even act like a one time pad

7. RSAEncrypt to … • Sign • Public Key – To attest to authenticity • Hash – To attest to integrity • Symmetric Key – To attest to source of key • Exchange • Public Key (Avoids certification authorities, but loses authentication) • Symmetric Key – Make sure only the other party gets the shared secret key. • Hash – If you want to make sure the other guy is the only one who can confirm the integrity of something. • Can always Exchange(Sign(short_msg)) • Only he can get it, and you prove you attest to it. • Use hashes of long messages instead of long messages • Send symmetric keys for hiding long messages

8. Certifying Authoritieswho SIGN PUBLIC KEYS • There is a big hole in public key systems discussed so far (guess!) • you must know the public key of your recipient correctly • this is very tricky in itself: • too many keys may need to be stored locally • you cannot request it over the internet since you cannot know who is sending the response • Trusted third parties called “Certifying Authorities” (CAs) provide public key validation (like a notary) • a CA vouches for the identities of individuals and organizations • you only need to store the public keys of a few well-known/trusted CAs. • Before sending a message, ask your recipient to send you a digitial certificate signed by one of these CAs. • From the certificate, verify the recipient’s identity and recover his/her public key • For a complete sequence, see the steps on Page 26 of your textbook

9. Alice Private Signing Key Alice Public Signing Key for Bob to Verify Alice Private Exchange Key Alice Private Exchange Key for Bob to Send Msg to Alice Bob Public Signing Key to Verify Bob Msg Bob Public Exchange Key to Send Msg to Bob Send Symmetric Key Receive Symmetric Key Bob Private Signing Key Bob Public Signing Key for Alice to Verify Bob Private Exchange Key Bob Private Exhange Key for Alice to Sent Msg to Bob Alice Public Signing Key to Verify Alice Msg Alice Public Exchange Key to Send Msg to Alice Send Symmetric Key Receive Symmetric Key EIGHT KEYS (Actually 10) are needed twix two people Alice Bob 16-6 = 10

10. Public Key Infrastructure (PKI) • CAs and signed certificates are central components of an emerging public key distribution system called the “Public Key Infrastructure” (PKI). • Site certificates: used to authenticate Web servers. • Personal certificates: authenticate individual users. • Software publisher certificates: used by software companies to sign executables. • Certifying authority certificates: hold the CA’s own public keys. All the above share a common format called X.509v3 • Trusted CAs validate the identity of individuals and organizations through some rigorous steps • Root CAs: web browsers and other encrypting software are pre-installed with signed certificates of a small number of CAs • a root CA can sign another CA’s public key, granting it signing authority • this represents a CA chain with the latter signing the public key of another CA further down the chain • repeat unti l you find the end-user’s public key • this is called a “hierarchy of trust”

11. Certification Expiration • Certificates must be invalidated at times due to • loss, theft, corruption of private keys • change of information in certificate • loss of CA’s private key itself! • Certificate Revocation List (CRL) is a component of the Public Key Infrastructure (PKI) and maintains such invalidated certificates • check the CRL for a match before using a certificate • Typically, certificates will expire within a finite time-interval like a year • this can pose a problem if a certificate does get compromised and will not be caught up to a year hence

12. Diffie-Hellman: Encryption without Authentication Allows a session key to be negotiated without ever sending the key across the network • Two parties wanting to communicate pick a partial key independently • They exchange a limited amount of information such that each can compute the common key value but an eavesdropper cannot do the same • they can do this since both have a piece of the answer to start with but the eavesdropper does not Limitation: susceptible to a “man-in-the-middle” attack

13. Briefly … Some Math • Crypto Guys like Integers, very very big ones • Exponentiation Rule: Basis for Diffie-Hellman • (Nx)y = Nxy = Nyx = (Ny)x • Alice and Bob share a Pre-Secret Public Random Number, P, (Eve can have it too!) • Alice selects a secret number,A • Alice calculatespublic numberPA • Bob selects a secret number, B • Bob calculates public number PB • Alice and Bob send their public numbers to each other (Eve can inspect these numbers too!) • Key Z = (PB)A = (PA)B

14. Modulo Arithmetic • Crypto Guys like modulo arithmetic – apparent chaos but underlying order – confuses the bad guy • Exponentiation Rule: Basis for Diffie-Hellman • (Nx mod u)y mod u = (Ny mod u)x mod u = Nxy mod u • Alice and Bob share a Pre-Secret Public Random Number, P, and u – a Prime Modulus • Alice selects a secret number,A • Alice calculatespublic numberPA mod u • Bob selects a secret number, B • Bob calculates public number PB mod u • Alice and Bob send their public numbers to each other (Eve can inspect these numbers too!) • Key Z = (PB)A mod u = (PA)B mod u

15. Example

16. Other Issues • Securing Private Keys • the private key is stored in encrypted form on the hard disk and retrieved only with a password • private key stored in memory for subsequent encryption • can be compromised in multi-user machines and/or by viruses • store key in a “smart card” that never leaves the user’s possessions except for quick swipes • also use personal identification #s • the card gets destroyed if wrong PIN is used consecutively • very long key lengths can be used • Breaking of encrypted data is possible! • Using brute-force and parallelization techniques • Using special-purpose hardware • U.S. Encryption Policy • restricts export of any software containing longer than 40-bit keys

17. Online Resources • The Cryptography Source Pages: • www.cs.hut.fi/crypto • Ray Kopsa’s Shortcut to Cryptography • www.subject.com/crypto/crypto.html • RSA Data Security • www.rsa.com • Netscape’s Cryptography Pages • www.netscape.com/newsref/ref/rsa.html • Microsoft’s Cryptography Pages • www.microsoft.com/workshop/prog/security/pkcb/crypt1.htm • A long list of cryptography-enhanced software products • www.semper.org/sirene/people/gerrit/secprod.html • Information on DES cracking • www.frii.com/~rev/deschall.htm • Information on other brute-force key cracking attempts • www.cl.com.ac.uk/brute • “Cryptobytes”, an online Cryptography Newsletter • www.rsa.com/rsalabs/pubs/cryptobytes

18. IPAAAA • Integrity (message integrity : Hashes like MD5 SHA) • Privacy (message is secret : Symmetric and Asymmetric Encryption) • Authentication (source is who he says he is : Asymmetric Encryption) • Authorization (source is permitted : Signed Certificates) • Auditability (the message can be proven to be passed successfully – Asymmetric Encryption, Signing) • Availability – not really crypto?

19. Fundamental Elements of Security : IPAAAA • Integrity • Privacy • Authentication • Authorization • Auditability • Availability

20. Our Class Client Applications Server Applications SSL Web Client Security Web Server Security Security Assurance Applications Security Server Applications WINDOWS 2000 Proxy/Router Applications – Put in Hardware! (buy CISCO) Client Security Server Security Path Security - Physical security Proxy/Router Security - Kind of Server Host Security Whole Facility / Internet Security – Protocols/Policy/Publicity Technology The Law How To Integrity/Privacy/Authenticate/Authorize/Record Cryptography

21. 1. Client says Hello & Stuff 2. Server says Hello & Stuff 3. Server sends Certificate 4. (opt) Server requests client Certificate 5. Client sends Certificate 6. Client sends ClientKeyExchange 7. Client sends a Certificate Verify message 8. Both send ChangeCipherSpec Messages 9. Both send Finished Messages SSL Transaction message

22. A few Internet Cryptographic Protocols • Cybercash : Electronic Funds Transactions, RFC1898 • DNSSEC : Domain Name System, RFC2065 • IPSec : Packet-Level Encryption, RFC2401 • PCT : TCP/IP-level Encryption • PGP : E-Mail, RFC2015 • S/MIME : E-Mail, RFC2311,RFC2634 • S-HTTP : Web Browsing, RFC2660 • SET : Electronic Funds Transactions • SSL : TCP/IP-level Encryption, Netscape • SSH : Remote Login • http://search.ietf.org/internet-drafts/draft-ietf-secsh-transport-07.txt • http://search.ietf.org/internet-drafts/draft-provos-secsh-dh-group-exchange-00.txt • TLS : TCP/IP-level Encryption, RFC2246

23. Secure Socket Layer History • SSL 1.0 Netscape 1994 • S-HTTP (web only) • SSL 2.0 Netscape (buggy) • PCT Microsoft (loser) 1996 • SSL 3.0 Netscape • TLS 1.0 IETF (now dominant) 1999

24. SSL • “TLS, more commonly known as SSL” • RFC2246 : TLS Protocol Version 1.0 1/99 • RFC2487 : SMTP over TLS • RFC2712 : Adding Kerberos to TLS • RFC2716 : PPP TLS • RFC2817 : Upgrading to TLS within HTTP/1.1 • RFC2818 : HTTP over TLS • RFC2830 : TLS for Lightweight Directory Access Protocol (LDAP) • The Lock or Non-broken Key on Your Browser • Get the picture? (yes, we like it)

25. Protocol Stack TELNET HTTP SMTP NNTP SSL Interface : Port N FTP Transport - TCP Internet - IP Network Interface – EtherNet/etc. Physical Layer

26. TLS/SSL • Crypto Solves the Problems – You just need to select among good alternatives for each task. • The “cypher suite” • X.509 Certificates (1991) too. • First, cypher suite agreement between the TCP peers.

27. SSL Components Establishing Symmetric SessionKey DIFFIE-HILLMAN RSA Public Key for Authentication Session Encryption with Symmetric Key for Privacy TRIPLE-DES/CBC RC4 RC3 RC2 Message Message Digest for Checking on Message Integrity SHA MD5

28. SSL Cipher Suites

29. SSL Encrypts • ALL Browser-Server and Server-Browser except which-browser is talking to which-server • URL of requested document • Contents of requested document • Contents of any submitted form fill-outs • Cookies sent from browser to server • Cookies sent from server to browser • Contents of HTTP header • Javascript communications • Etc. ??NetShow—cause that’s UDP??

30. BREAK! Lincoln Stein

31. TLS Client Server  ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data PLUS ALERTS 

32. TLS Handshake hello_request(0) ; sent anytime by server to tell client to say hello again. client_hello(1) = protocolversion, rnd = unixtime + 28 random bytes, (opt)sessionID, ciphersuiteLIST, compressionmethod. server_hello(2) = protocolversion, independent rnd = unixtime + 28 random bytes, sessionID decided, ciphersuiteSELECTED, compressionmethod (encrpt(compress(msg)) certificate(11), A certificate list, RSA Exchange Key & Signing Key  server_key_exchange (12), NOT USED FOR RSA (pre-master secret for DH)  certificate_request(13), Request Client Certificate, asking for specific types, e.g., RSA sign. Also list of cert authorities required.  server_hello_done(14), Server is finished with his hello.  certificate_verify(15), server_key_exchange (12), NOT USED FOR RSA (pre-master secret for DH)  certificate_request(13), Request Client Certificate, asking for specific types, e.g., RSA sign. Also list of cert authorities required.  server_hello_done(14), Server is finished with his hello.  client_key_exchange(16) Client sends symmetric key (master secret) or DH certificate_verify(15)Client Signs Hash of all Handshake messages to this point to prove he is the client claimed in the client certificate finished(20), (255) = mastersecret + label + SHA(handshake) + MD5(handshake)

33. SSL Summary • An excellent study in a careful protocol • Read TLS and try to follow some of the reasoning behind the security measures. • Expect only to have time to think about a few of them. It would take a long time to think through all the security built into TLS.

34. What Could Replace SSL? TELNET HTTP SMTP NNTP SSL Interface : Port N FTP Transport - TCP IPSec Internet - IP Network Interface – EtherNet/etc. Physical Layer

35. IPSec Does Not • Authenticate Participants • But then, neither does SSL in practice • Its does authenticate computers … not done by SSL except during session. SSL can’t stop a proxy.

36. Rules of Thumb • Always get 128 Bit Browsers • This is called “US” as opposed to “International” Even though it really means the opposite!!!!!!! • 128 bits is really really good for securing your transaction against spies • Unfortunately, hides employee behavior. • Unfortunately, false sense of security: • Most theft of credit cards is by the employees of credit card processing operations including retailer, clearing, etc. • Do you really trust Amazon? Read their privacy statement at http://www.amazon.com/privacy-notice

37. SETJust SKIM the Chapter • Authentication : All parties use certificates including customer, merchant, bank, merchant’s bank. • Confidentiality : Encrypted and Private • Message Integrity : Can’t be tampered • Linkage : Verification of encrypted attachments (blind forwarding)

38. Set Protocol Supports all Features of Credit Card System • Cardholder registration • Merchant registration • Purchase requests • Payment authorizations • Payment capture (funds transfer) • Chargebacks (refunds to customers) • Credits • Credit reversals • Debit Card (check card) transactions • Real-time, batch, installment payments, etc.

39. Problems with SET • Risk Management leads Banks to use Intermediaries • Intermediaries have access to the credit card purchasing information • This is where most theft occurs. • To be adopted SET really needs to be accompanied with a change in credit card processing. • BUT: the rate of Internet Charge Backs is HUGE! (Particularly on download purchases and subscriptions). Retailers are now being fined in the hope of reducing this. • SET does not create a non-repudiatable confirmation of the successful obtaining and use of the product sold. It hides critical information from the retailer! • SLOW SLOW SLOW SLOW SLOW SLOW

40. X.509v3 Certificates • More generally used than SSL • Used by SSL • Used by nearly every major computer security system • From Older Standards Groups • ISO/ITU • International Standards Organization/ANSI • International Telecommunications Union (was CCITT – fax, TIFF) • Part of United Nations as of 1988 • ASN.1 (Abstract Syntax Notation 1) – see www.asn1.com • This is instead of BNF and is pretty arcane, but includes encoding rules (DER) • SGML (predecessor of HTML) used this, X.10 Financial Systems. • Object Identifier • Tree starting with world, down through countries, companies, etc., www.hyperstamps.com fun • Your international phone number is a legal Object Identifier • It is a felony in nearly every country of the world to counterfeit an ISO issued Object Identifiers

41. X.509v3 Where to Get • You have to pay 34 Swiss Francs! • www.itu.org -- search on X.509 • But WAIT! X.509v4 is out, but not yet published! • Those typical Swiss…always getting rich • No, this is how nearly all older standards bodies have worked – they sell copies of their standards • Buy them. They are like the RFCs and the W3 Specifications. They will make you one of the few real experts.

42. What is X.509? • A means of authenticating a “directory” • Uses public/private key exclusively (and that means RSA for all practical purposes … Sept 21, remember?) • A means for chaining certificate authorities • Didn’t work, people really just chain certificates • The information about who you are is hashed and signed so this can be compared with the plaintext about who you are in the certificate • Serial Number : an Object Identifier – It’s a FELONY to copy this even in IRAQ!!!

43. X.509 Basic Form Certificate Serial Number (Signed) Public Key for Authentication/Exchange RSA DateTime and Expiration Sept 21, 2000! “Who you are” Plaintext (Signed) Message Digest for Checking on Message Integrity SHA MD5

44. Concepts behind X.509 • user certificate; public key certificate; certificate: • The public keys of a user, together with some other information, rendered unforgeable by encipherment with the private key of the certification authority which issued it. • certification path: • An ordered sequence of certificates of objects in the directory information tree which, together with the public key of the initial object in the path, can be processed to obtain that of the final object in the path.

45. X.509 Nomenclature

46. Certificate Definition Certificate ::= SIGNED{SEQUENCE{ version version Default v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueIdentifier ObjectIdentifier, - v3 subjectUniqueIdentifier ObjectIdentifier, - v3 extensions Extensions, }}

47. Certificate Defined (cont) Version :== Integer (for v1, v2, v3) CertificateSerialNumber ::= Integer AlgorithmIdentifier ::= SEQUENCE{ ..stuff about crypto } Validity ::= SEQUENCE { notBefore Time, notAfter Time} SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BITSTRING } Time ::= CHOICE { utcTime UTCTime, generalizedTime GeneralizedTime } Extensions ::== SEQUENCE OF extensions like, critical TrueORFalse – v3

48. Date Time • Great Security Technique for Authentication • Challenge-Response, let mother nature be the challenge. • Very hard to defeat since you have to crack the code too quickly … can be used to put a time limit on things. This is used by many certificates. • Kerberos uses this in issuing “tickets” for a time. • Great Security Technique for Auditability • Hash the date-time and sign it. • Requires an authority or both members of transaction to maintain copy (you can’t deny your signature even if you “fix” your copy!)

49. X.509 certificate types • For people • For web sites • For companies • For organizations inside companies • For software • Etc. etc. etc. • You could have X.509 certificates that certify a toaster made a piece of toast. http://dollar.ecom.cmu.edu/sec/509.doc

50. What’s Wrong with Them • Classic HORRIBLE USER INTERFACE ASSOCIATED WITH GOOD CRYPTOGRAPHY • You have to apply to a root CA for one • They invade your privacy • They make you PAY • They make them last only one Year • And you pay again. • Hey…their cost is a few cpu seconds… • Funwork: Go to Thawte (www.verisign.com) and get a free personal certificate for your mail browser (outlook, eudora, or netscape). • See what I mean?