secured socket layers

8/12/2019 Secured Socket Layers

1/20

Credit Card Protocols/ Web Security:

SSL, SET

SANDEEP SARASWAT

AMOG S. MIRASHITANIA SHAR

MUHURTHA BEKAL

JAI DURGA

POOJA YATI


2/20

SSL (Secure Sockets Layer)

NOT a payment protocol -- can be used for any securecommunications, 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


3/20

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.


4/20

SSL (Secure Sockets Layer)

HANDLES COMMUNICATIONWITH THE APPLICATION

ProtocolsINITIALIZES COMMUNCATION

BETWEEN CLIENT & SERVER

INITIALIZES SECURE

COMMUNICATION

HANDLES DATA

COMPRESSION

ERROR HANDLING


5/20

Cipher Suite

For public-key, symmetric encryption and certificateverification 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


6/20

Secure Sockets Layer (SSL) Handshake

if it has one

SOURCE: WEB SECURITY

SYMMETRIC

SYMMETRIC

ASYMMETRIC

ASYMMETRIC

SECURE TRANSMISSION BEGINS HERE


7/20

SSL Messages

OFFER CIPHER SUITE

MENU TO SERVERSELECT A CIPHER SUITE

SEND CERTIFICATE AND

CHAIN TO CA ROOT

CLIENT SIDE SERVER SIDE

SEND PUBLIC KEY TO

ENCRYPT SYMM KEYSERVER NEGOTIATION

FINISHEDSEND ENCRYPTED

SYMMETRIC KEY

SOURCE: THOMAS, SSL AND TLS ESSENTIALS

ACTIVATE

ENCRYPTION

CLIENT PORTION

DONE

( SERVER CHECKS OPTIONS )

ACTIVATESERVER

ENCRYPTION

SERVER PORTION

DONE

( CLIENT CHECKS OPTIONS )

NOW THE PARTIES CAN USE SYMMETRIC ENCRYPTION


8/20

SSL Encryption

Premaster secret Created by client; used to seed calculation of encryptionparameters

Very simple: 2 bytes of SSL version + 46 random bytes

Sent encrypted to server using servers 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


9/20

SSL Record Protocol

SOURCE: WILLIAM STALLINGS


10/20

SET in Practice

SOURCE: http://www.software.ibm.com/commerce/payment/specsheetetill.html
http://www.software.ibm.com/commerce/payment/specsheetetill.htmlhttp://www.software.ibm.com/commerce/payment/specsheetetill.html


11/20

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


12/20

Dual Signatures

Links two messages securely but allows only one party to read each.

Used in SET.

MESSAGE 1

DIGEST 1

NEW DIGEST

HASH 1 & 2

WITH SHA

MESSAGE 2

DIGEST 2

CONCATENATE DIGESTS

TOGETHER

HASH WITH SHA TO

CREATE NEW DIGEST

DUAL SIGNATURE

PRIVATE KEYENCRYPT NEW DIGEST

WITH SIGNERS PRIVATE KEY


13/20

SET in the Transaction Process

1. Browsing2. Product selection

3. Customer order entry

4. Selection of payment mechanism

5. Customer sends order and payment instructions6. Merchant requests payment authorization

7. Merchant sends order confirmation

8. Merchant ships goods

9. Merchant requests payment from bank

SET PROTOCOL

FUNCTIONS:


14/20

SET Security

Digital envelopes, nonce, 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)

Idem potency (message can be received many times but isonly processed once) f (f (x)) =f (x)

Complex protocol Over 600 pages of detail

Dual signatures


15/20

SET Process Steps (Simplified)

1. Merchant sends invoice and unique transaction ID (XID)2. Merchant sends merchant certificate and bank certificate (encrypted

with CAs 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-signed5. Merchant sends payment request to bank encrypted with bank-

merchant session key, PI, digest of OI and merchants 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


16/20

SET Supported Transactions

card holder registration

merchant registration

purchase request

payment authorizationpayment capture

certificate query

purchase inquiry

purchase notification

sale transaction

authorization reversal

capture reversal

credit reversal


17/20

SET Message Flow

Customer asks Merchant

for digital certificates

Merchant asks Customer

for purchase information

Merchant asks Acquirerfor authorization

[Merchant asks Acquirer

to reverse authorization]

Merchant asks Acquirer

to capture payment

Customer asks Merchant

for transaction status

SET messages come in pairs:

Requestfollowed by Response

Appropriate cryptography isapplied to message Wrappers.


18/20

SET Payment Initialization

PInitReq: { RRPID, Language, LID_C, [LID_M], Chall_C, BrandID, BIN, [Thumbs]}

Card Brand

(VISA, MC, etc.)Bank ID #Customers

Language

Request/Response Pair ID

Thumbnails (hashes) of

of certificates known to

Customer

Customers local ID

Merchants local ID

Customers challenge

salt to Merchants

signature freshness

Purpose: Allow customer to get

certificates from the Merchant


19/20

Security Fields in Order Information

TRANSACTION IDs: CUSTOMER,

MERCHANT, GLOBALLY UNIQUE

REQUEST/RESPONSE PAIR ID

CARDHOLDERS CHALLENGE TO

MERCHANT SIG FRESHNESS

MERCHANTS CHALLENGE TO

CARDHOLDER SIG FRESHNESS

HASH OF ORDER DATA

ORDER DATA SALT (TO GUARDAGAINST DICTIONARY ATTACK

ON ORDER DATA HASH!

DD(x) means data +a hash of

the data per PKCS #7

SOURCE:SET STANDARD
http://www.cis.ohio-state.edu/htbin/rfc/rfc2315.htmlhttp://www.setco.org/download/set_bk3.pdfhttp://www.setco.org/download/set_bk3.pdfhttp://www.cis.ohio-state.edu/htbin/rfc/rfc2315.html


20/20

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.

secured socket layers

Documents