SSL, TLS, SET - Carnegie Mellon University

Download Report

Transcript SSL, TLS, SET - Carnegie Mellon University

Electronic Payment Systems
20-763
Lecture 7
Credit Card Protocols:
SSL, TLS, SET
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Outline
•
•
•
•
•
•
Credit card participants (5)
Secure Sockets Layer (SSL)
Credit card economics
Secure Electronic Transactions (SET)
Fraud
Online card reading
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Participants
Processor
Processor
Card
Associations
Merchant
•Issuing Bank
•Issues card
•Extends credit
•Assumes risk of card
•Cardholder reporting
•Merchant Bank (Acquirer)
•Sets up merchant
•Extends credit
•Assumes risk of merchant
•Funds merchant
Consumer
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Credit Cards on the Internet
• Problem: communicate credit card and purchasing
data securely to gain consumer trust
– Authentication of buyer and merchant
– Confidential transmissions
• Systems vary by
–
–
–
–
–
type of public-key encryption
type of symmetric encryption
message digest algorithm
number of parties having private keys
number of parties having certificates
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Credit Card Protocols
• SSL 1 or 2 parties have private keys
• TLS (Transport Layer Security)
VERY IMPORTANT.
USAGE INCREASING
– IETF version of SSL
• i KP (IBM) i parties have private keys
• SEPP (Secure Encryption Payment Protocol)
– MasterCard, IBM, Netscape based on 3KP
OBSOLETE
• STT (Secure Transaction Technology)
– VISA, Microsoft
• SET (Secure Electronic Transactions)
– MasterCard, VISA all parties have certificates
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
VERY SLOW
ACCEPTANCE
COPYRIGHT © 2002 MICHAEL I. SHAMOS
SSL (Secure Sockets Layer)
• NOT a payment protocol -- can be used for any secure
communications, like credit card numbers
• SSL is a secure data exchange protocol providing
– Privacy between two Internet applications
– Authentication of server (authentication of browser optional)
• Uses enveloping: RSA used to exchange DES keys
• SSL Handshake Protocol
– Negotiates symmetric encryption protocol, authenticates
• SSL Record Protocol
– Packs/unpacks records, performs encryption/decryption
• Does not provide non-repudiation
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Secure Sockets Layer (SSL)
• Layered on top of TCP/IP but below the application
layer. (Requires reliable transport to operate.)
• SSL is increasing in importance for Internet security
• Invented by Phil Karlton (CMU Ph.D.) and others at
Netscape
• View protocol (63 pages)
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
SSL (Secure Sockets Layer)
ERROR HANDLING
INITIALIZES SECURE
COMMUNICATION
HANDLES COMMUNICATION
WITH THE APPLICATION
Protocols
INITIALIZES COMMUNCATION
BETWEEN CLIENT & SERVER
HANDLES DATA
COMPRESSION
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Cipher Suite
• For public-key, symmetric encryption and certificate
verification we need
– public-key algorithm
– symmetric encryption algorithm
– message digest (hash) algorithm
•
•
•
•
This collection is called a cipher suite
SSL supports many different suites
Client and server must decide on which one to use
The client offers a choice; the server picks one
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Cipher Suites
INITIAL (NULL) CIPHER SUITE
SSL_NULL_WITH_NULL_NULL = { 0, 0 }
PUBLIC-KEY
ALGORITHM
SYMMETRIC
ALGORITHM
HASH
ALGORITHM
SSL_RSA_WITH_NULL_MD5 = { 0, 1 }
CIPHER SUITE CODES USED
IN SSL MESSAGES
SSL_RSA_WITH_NULL_SHA = { 0, 2 }
SSL_RSA_EXPORT_WITH_RC4_40_MD5 = { 0, 3 }
SSL_RSA_WITH_RC4_128_MD5 = { 0, 4 }
SSL_RSA_WITH_RC4_128_SHA = { 0, 5 }
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0, 6 }
SSL_RSA_WITH_IDEA_CBC_SHA = { 0, 7 }
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0, 8 }
SSL_RSA_WITH_DES_CBC_SHA = { 0, 9 }
SSL_RSA_WITH_3DES_EDE_CBC_SHA = { 0, 10 }
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
SSL Handshake Messages
INTERNET
THE SSL PROTOCOL
DEFINES VARIOUS
MESSAGE TYPES
EXCHANGED BETWEEN
CLIENT AND SERVER
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
SSL Messages
SERVER SIDE
CLIENT SIDE
OFFER CIPHER SUITE
MENU TO SERVER
SELECT A CIPHER SUITE
SEND CERTIFICATE AND
CHAIN TO CA ROOT
SEND PUBLIC KEY TO
ENCRYPT SYMM KEY
SERVER NEGOTIATION
FINISHED
SEND ENCRYPTED
SYMMETRIC KEY
ACTIVATE
ENCRYPTION
( SERVER CHECKS OPTIONS )
CLIENT PORTION
DONE
ACTIVATESERVER
ENCRYPTION
( CLIENT CHECKS OPTIONS )
SERVER PORTION
DONE
NOW THE PARTIES CAN USE SYMMETRIC ENCRYPTION
SOURCE: THOMAS, SSL AND TLS ESSENTIALS
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
SSL Encryption
• Premaster secret
– Created by client; used to “seed” calculation of encryption
parameters
– Very simple: 2 bytes of SSL version + 46 random bytes
– Sent encrypted to server using server’s public key
• Master secret
– Generated by both parties from premaster secret and random
values generated by both client and server
• Key material
– Generated from the master secret and shared random values
• Encryption keys
– Extracted from the key material
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Forming the Master Secret
SERVER’S PUBLIC KEY
IS SENT BY SERVER IN
ServerKeyExchange
CLIENT GENERATES THE
PREMASTER SECRET
SENT BY SERVER
IN ServerHello
ENCRYPTS WITH PUBLIC
KEY OF SERVER
SENT BY CLIENT
IN ClientHello
CLIENT SENDS PREMASTER
SECRET IN ClientKeyExchange
MASTER SECRET IS 3 MD5
HASHES CONCATENATED
TOGETHER = 384 BITS
SOURCE: THOMAS, SSL AND TLS ESSENTIALS
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Forming the Key Material
JUST LIKE FORMING
THE MASTER SECRET
EXCEPT THE MASTER
SECRET IS USED HERE
INSTEAD OF THE
PREMASTER SECRET
...
SOURCE: THOMAS, SSL AND TLS ESSENTIALS
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Obtaining Keys from the Key Material
SECRET VALUES
INCLUDED IN MESSAGE
AUTHENTICATION CODES
SYMMETRIC KEYS
INITIALIZATION VECTORS
FOR DES CBC ENCRYPTION
SOURCE: THOMAS, SSL AND TLS ESSENTIALS
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
SSL Record Protocol
SOURCE: WILLIAM STALLINGS
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
SSL (Secure Sockets Layer)
Some payment services using SSL:
• Credit Card Network
• Secure-Bank.Com
• Web-Charge
• SecureTrans
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
TLS (Transport Layer Security)
• SSL is so important it was adopted by the Internet
Engineering Task Force (IETF)
• TLS Protocol 1.0 (RFC 2246)
• TLS is very similar to SSL but they do not
interoperate
• Goals
– Separate record and handshaking protocols
– Extensibility (add new cipher suites easily)
– Efficiency (minimize network activity)
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
3 . Acquiring Bank’s Processor
•direct connections to MC /VI
•obtains authorization from Issuer
•returns response to merchant
•five digit number that must be stored
2.Card Authorization
via dial, lease line,
satellite
4 . Issuing Bank / Processor
•receives auth request
•verifies available funds
•places hold on funds
8. MC / VI
debit issuers /
credit acquirers
9. Acquiring Bank
funds merchant
Authorizations
Batch Settlement
1. Customer
•pays with card
•card swiped
•mag data read
•(get signature)
5. Merchant
•stores authorizations
and sales conducted
•captures sales (at end
of day)
•submits batch for
funding
20-763 ELECTRONIC PAYMENT SYSTEMS
6. Acquiring Bank /
Processor
•scans settlement file
•verifies authorizations
match captured data
•prepares file for MC/VI
•prepares funding file
•records txs for reporting
FALL 2002
7. Issuing Bank / Processor
•receives settlement file from
MC / VI
•funds MC / VI
•matches txs to auths
•post txs to cardholder
•records transactions for
reporting
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Industry Update
Acquirer Market Share
Bank Issuer Market Share
12%
25%
19%
7%
34%
5%
19%
11%
6%
40%
Paymentech
Nova
First Data
NPC
B of A
All Others
9%
13%
First USA Citigroup
Chase
B of A
MBNA
All others
• Disintermediation of Bank issuers and acquirers
• Consolidation of the industry
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Card Economics
Issuing Bank
Acquiring Bank
• Revenue
• Revenue
– interest on revolving
balances
– interchange fee income on
card purchases
• Expenses
– cost of carrying asset
transactors vs. revolvers
– cardholder reporting,
chargeback processing,
customer service
– marketing fees / dues
– acquisition costs
– fraud - lost/stolen cards
– bankruptcy
20-763 ELECTRONIC PAYMENT SYSTEMS
– transaction fees charged
merchants net of
interchange expense
– earnings on deposits
• Expenses
– processing fees for
authorization, settlement,
funding, chargebacks,
customer service
– marketing fees / dues
– acquisition costs
– credit / fraud risk
– bankruptcy
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Parties in Secure eCommerce
SOURCE: WILLIAM STALLINGS
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
SET in Practice
SOURCE: http://www.software.ibm.com/commerce/payment/specsheetetill.html
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
SET Objectives
• Confidentiality of payment and order information
– Encryption
•
•
•
•
•
Integrity of all data (digital signatures)
Authentication of cardholder & account (certificates)
Authentication of merchant (certificates)
No reliance on secure transport protocols (uses TCP/IP)
Interoperability between SET software and network
– Standardized message formats
• SET is a payment protocol
– Messages relate to various steps in a credit card transaction
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Dual Signatures
• Links two messages securely but allows only one party to read
each. Used in SET.
MESSAGE 1
MESSAGE 2
HASH 1 & 2
WITH SHA
DIGEST 1
DIGEST 2
CONCATENATE DIGESTS
TOGETHER
HASH WITH SHA TO
CREATE NEW DIGEST
NEW DIGEST
ENCRYPT NEW DIGEST
WITH SIGNER’S PRIVATE KEY
PRIVATE KEY
DUAL SIGNATURE
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Using Dual Signatures
• Alice wants to send Message 1 to Bob and Message 2 to Carol
• Message 1 is order info; Message 2 is payment info
• Alice encrypts Message 1 with Bob’s public key; Message 2 with
Carol’s public key
• Both Bob and Carol must be convinced that the messages are
linked and unaltered
• Alice sends { PKBOB(Message 1), PKCAROL (Message 2), DualSig}
to both Bob and Carol
• Bob hashes PKBOB(Message 1), concatenates with PKCAROL
(Message 2), and hashes again to give the dual hash
• Bob decrypts the dual signature with Alice’s public key
• If the new hash and the decrypted signature match, all is OK
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Dual Signatures on Plaintext
• Alice wants to send Message 1 to Bob and Message 2 to Carol in
plaintext
• Bob can’t see Message 2; Carol can’t see Message 1
• Both Bob and Carol must be convinced that the messages are
linked and unaltered
• Alice sends Bob { Message 1, Digest 2, Dual Signature}
• Bob hashes Message 1, concatenates with Digest2 and hashes
• Bob decrypts the dual signature with Alice’s public key
• If the new hash and the decrypted signature match, all is OK
• Now Bob can send Carol Digest 2 and ask if she got the
message corresponding to it!
• (Carol got { Message 2, Digest 1, Dual Signature} )
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
SET in the Transaction Process
1.
2.
3.
4.
5.
6.
7.
8.
9.
Browsing
SET PROTOCOL
Product selection
FUNCTIONS:
Customer order entry
Selection of payment mechanism
Customer sends order and payment instructions
Merchant requests payment authorization
Merchant sends order confirmation
Merchant ships goods
Merchant requests payment from bank
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
SET Security
• Digital envelopes, nonces, salt
• Two public-private key pairs for each party
– One for digital signatures; one for key exchange messages
• 160-bit message digests
• Statistically globally unique IDs (XIDs)
• Certificates (5 kinds)
– Cardholder, Merchant, Acquirer, Issuer, Payment Gateway
• Hardware cryptographic modules (for high security)
• Idempotency (message can be received many times but is only
processed once) f (f (x)) = f (x)
• Complex protocol. Over 600 pages of detail
• Dual signatures
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
SET Process Steps (Simplified)
1. Merchant sends invoice and unique transaction ID (XID)
2. Merchant sends merchant certificate and bank certificate (encrypted
with CA’s private key)
3. Customer decrypts certificates, obtains public keys
4. Customer generates order information (OI) and payment info (PI)
encrypted with different session keys and dual-signed
5. Merchant sends payment request to bank encrypted with bankmerchant session key, PI, digest of OI and merchant’s certificate
6. Bank verifies that the XID matches the one in the PI
7. Bank sends authorization request to issuing bank via card network
8. Bank sends approval to merchant
9. Merchant sends acknowledgement to customer
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
SET Supported Transactions
 card holder registration
 purchase notification
 merchant registration
 sale transaction
 purchase request
 authorization reversal
 payment authorization
 capture reversal
 payment capture
 credit reversal
 certificate query
 purchase inquiry
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
SET Message Flow
SET messages come in pairs:
Request
followed by
Response
Customer asks Merchant
for digital certificates
Merchant asks Customer
for purchase information
Appropriate cryptography
is applied to message
wrappers
Merchant asks Acquirer
for authorization
[Merchant asks Acquirer
to reverse authorization]
Customer asks Merchant
for transaction status
Merchant asks Acquirer
to capture payment
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
SET Payment Initialization
Purpose: Allow customer to get
certificates from the Merchant
Customer’s
Language
Card Brand
(VISA, MC, etc.)
Bank ID #
PInitReq: { RRPID, Language, LID_C, [LID_M], Chall_C, BrandID, BIN, [Thumbs]}
Request/Response Pair ID
Customer’s local ID
Merchant’s local ID
20-763 ELECTRONIC PAYMENT SYSTEMS
Customer’s challenge
salt to Merchant’s
signature freshness
FALL 2002
Thumbnails (hashes) of
of certificates known to
Customer
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Customer Processing of PInitRes
PInitRes:
{ TransIDs,
RRPID,
Chall_C,
Chall_M,
PEThumb,
[Thumbs] }
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Customer Processing of PInitRes
PInitRes:
{ TransIDs,
RRPID,
Chall_C,
Chall_M,
PEThumb,
[Thumbs] }
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Security Fields in Order Information
TRANSACTION IDs: CUSTOMER,
MERCHANT, GLOBALLY UNIQUE
REQUEST/RESPONSE PAIR ID
CARDHOLDER’S CHALLENGE TO
MERCHANT SIG FRESHNESS
HASH OF ORDER DATA
ORDER DATA SALT (TO GUARD
AGAINST DICTIONARY ATTACK
ON ORDER DATA HASH!
MERCHANT’S CHALLENGE TO
CARDHOLDER SIG FRESHNESS
DD(x) means data +a hash of
the data per PKCS #7
SOURCE: SET STANDARD
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
SET Overhead
Simple purchase transaction:
•
•
•
•
•
•
Four messages between merchant and customer
Two messages between merchant and payment gateway
6 digital signatures
9 RSA encryption/decryption cycles
4 DES encryption/decryption cycles
4 certificate verifications
Scaling:
•
•
•
•
Multiple servers need copies of all certificates
Compaq sells SET software equipped for 5,000,000 certificates
NO ONE USES SET. WHY?
Check # of SET-enabled Visa Merchants in the U.S.
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
SET Certificate Hierarchy
Root CA
(SET Co)
Brand CA
(MasterCard, Visa)
Hosted by
Geo-Political CA (optional)
(only for VISA)
Cardholder CA
Merchant CA
Payment Gateway CA
(Banesto)
(Banesto)
(MasterCard, Banesto in VISA)
Cardholder
Merchant
Payment Gateway
SOURCE: INZA.COM
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Major Ideas
• SSL, TLS are secure message protocols, not payment
protocols
• SSL requires the vendor to have a certificate
• SSL is secure against breaking of any one form of
encryption
• SET is a payment protocol
• SET requires all parties to have certificates
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Q&A
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Secure Sockets Layer (SSL) Handshake
SYMMETRIC
if it has one
ASYMMETRIC
ASYMMETRIC
SYMMETRIC
20-763 ELECTRONIC PAYMENT SYSTEMS
SOURCE: WEB SECURITY
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
SECURE TRANSMISSION BEGINS HERE