Lecture 3, 20-771: Computer Security, Fall 2002 1 20-771: Computer Security Lecture 3: SSL Robert Thibadeau School of Computer Science Carnegie Mellon

Lecture 3, 20-771: Computer Security, Fall 2002 1

20-771: Computer SecurityLecture 3: SSL

Robert Thibadeau

School of Computer Science

Carnegie Mellon University

Institute for eCommerce, Fall 2002


Today’s lecture

• Java Task• Linux Task• Review Crypto • Envelopes• PKI• Diffie-Hellman• SSL/TLS• X.509v3 Certificates


This Week

Chapters 3 WSShould finish off Crypto Book by Levy

New: Read and Study the 1.0 versionOf TLS

Go to www.rfc-editor.orgSearch 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.


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


Digital EnvelopesSince 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


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


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


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


EIGHT KEYS (Actually 10) are needed twix two people

1. Alice Private Signing Key

2. Alice Public Signing Key for Bob to Verify

3. Alice Private Exchange Key

4. Alice Private Exchange Key for Bob to Send Msg to Alice

5. Bob Public Signing Key to Verify Bob Msg

6. Bob Public Exchange Key to Send Msg to Bob

7. Send Symmetric Key8. Receive Symmetric Key

1. Bob Private Signing Key

2. Bob Public Signing Key for Alice to Verify

3. Bob Private Exchange Key

4. Bob Private Exhange Key for Alice to Sent Msg to Bob

5. Alice Public Signing Key to Verify Alice Msg

6. Alice Public Exchange Key to Send Msg to Alice

7. Send Symmetric Key8. Receive Symmetric Key


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”


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


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


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 calculates public number PA

• 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


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 calculates public number PA 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


Example

Share Presecret P = 7

U = 11

P = 7

U = 11

Select Secrets A = 3 B = 4

Calculate Public Parts

PA mod u =

2 = 73 mod 11

PB mod u =

3 = 74 mod 11

Exchange Publics PB = 3 PA =2

Calculate Secret Key Z

Z = (PB)A mod u =

5 = 33 mod 11

Z = (PA)B mod u

5 = 24 mod 11


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


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


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?


Fundamental Elements of Security : IPAAAA

• Integrity

• Privacy

• Authentication

• Authorization

• Auditability

• Availability


Our Class

Whole Facility / Internet Security – Protocols/Policy/Publicity

Path Security-

Physical security

Proxy/Router Security- Kind of Server

Host Security

Server SecurityClient Security

Server ApplicationsClient Applications

Proxy/Router Applications –

Put in Hardware!

(buy CISCO)

Security Server Applications

WINDOWS 2000

Security Assurance

Applications

Web Server

Security

Web Client

Security

Technology The Law

CryptographyHow To

Integrity/Privacy/Authenticate/

Authorize/Record


SSL Transaction

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


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


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


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)


Protocol Stack

Physical Layer

Network Interface – EtherNet/etc.

Internet - IP

Transport - TCP

SSL Interface : Port N

HTTP

FTP

TELNET

NNTP

SMTP


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.


SSL Components

DIFFIE-HILLMAN

Session Encryption with Symmetric Key for Privacy

Message

Message Digest for Checking on Message Integrity

Public Key for Authentication

RSA

TRIPLE-DES/CBCRC4

RC3RC2

MD5 SHA

Establishing Symmetric SessionKey


SSL Cipher SuitesSuite Strength Description

DES-CBC3-MD5 ***** 168bit Session/1024bit RSA

DES-CBC3-SHA ***** 168bit Session/1024bit RSA

RC4-MD5 **** 128bit Session/1024bit RSA

RC4-SHA **** 128bit Session/1024bit RSA

RC2-CBC-MD5 **** 128bit Session/1024bit RSA

DES-CBC-MD5 *** 56bit Session/1024bit RSA

DES-CBC-SHA *** 56bit Session/1024bit RSA

EXP-DES-CBC-SHA ** 40bit Session/512bit RSA

EXP-DES-RC4-MD5 ** 40bit Session/512bit RSA

EXP-RC2-CBC-MD5 ** 40bit Session/512bit RSA

NULL-MD5 * None/RSA authentication

NULL-SHA * None/RSA authentication

CHECK YOUR BROWSER!!!!!!!


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??


BREAK!

Lincoln Stein


TLS Client Server ClientHello -------->

ServerHello

Certificate* ServerKeyExchange*

CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished -------->

[ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data

PLUS ALERTS


TLS Handshakehello_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)


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.


What Could Replace SSL?

Physical Layer

Network Interface – EtherNet/etc.

Internet - IP

Transport - TCP

SSL Interface : Port N

HTTP

FTP

TELNET

NNTP

SMTP

IPSec


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.


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


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)


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.


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


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


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.


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!!!


X.509 Basic Form

“Who you are” Plaintext

(Signed) Message Digest for Checking on Message Integrity

(Signed) Public Key for Authentication/Exchange RSA

MD5 SHA

Certificate Serial Number

DateTime and ExpirationSept 21, 2000!


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.


X.509 NomenclatureXp Public key of a user X

Xs Private key of a user X

Xp[I] Encryption of Information, I, using public key of X

Xs[I] Encryption of I using the private key of X

X{I} Signing I by X : I with hashed summary appended

CA(X) A certification authority of user X

Can(X) (where n>1): CA(CA(…n times(X)))

X1<<X2>> Certificate of user X2 issued by authority X1

X1<<X2>>X2<<X3>> Chain of certificates functionally equivalent to X1<<Xn+1>>

X1p*X1<<X2>> Unwrapping certificate to extract public key.

Ap * A<<B>> B<<C>> denotes using public key A to obtain B’s public key, Bp, from its certificate, followed by using Bp to unwrap C’s certificate. Outcome is the public key of C, Cp.

A -> B Certification path from A to B form of a chain of certificates starting with CA(A)<<CA2(A)>> and ending with CA(B)<<B>>

Note: X’s are names of users, I is arbitrary information


Certificate DefinitionCertificate ::= 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, }}


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


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!)


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


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?


Better root CAs

• There should not be a commercial monopoly here.

• Social Security Admin could issue free personal certificates FOR LIFE.

– This would make your private key very private

– Needs to be on a smart card you don’t lose

– Would make Certificate Revocation Work!

• Now, each individual person can become a CA! – He can establish expirations suitable to him

– He does not himself expire.

• Same for each company (IRS or United Nations through ASN.1 Object Identifiers maintained by United Nations.)

• September 21, 2000!!! Wanna be a root CA?September 21, 2000!!! Wanna be a root CA?

Documents

Lecture 3, 20-771: Computer Security, Fall 2002 1 20-771: Computer Security Lecture 3: SSL Robert Thibadeau School of Computer Science Carnegie Mellon