SSL/TLS provides encryption and authentication for secure internet communications. It originated from efforts by IETF, ANSI, and Netscape in the 1990s. SSL/TLS establishes a secure channel through a handshake to negotiate encryption keys before data transfer. SET builds on SSL/TLS to provide additional privacy, authentication, and integrity specifically for online credit card transactions through the use of digital signatures and certificates. It establishes separate encryption for payment and order information that is only revealed to authorized parties.

1. email : rameshogania@gmail.com
Gsm : 9969 37 44 37
Intro to SSL/TLS & SET

2. SSL Origins
• Internet Engineering Task Force (IETF)
– www.ietf.org
– Documents: RFC 2246
• ANSI
– X9.42
• ITU
– X.509
• Netscape

3. Architecture
IP
TCP
SSL
Application (HTTP)

4. SSL security services
• Server authentication
– Client authentication is optional
• Encryption
• Message integrity

5. SSL phases
• Handshake
• Set protocol details
– Authenticate server
– Establish keys
• Data transfer
2/2/2016 Gene Itkis: CS558 Network Security 5

6. Handshake
• ClientHello
– Supported options
• ServerHello
– Options to be used
• ServerCertificate (ServerKeyExchange)
• ServerHelloDone
• ClientKeyExchange
• Finished (sent by client)
2/2/2016 Gene Itkis: CS558 Network Security 6

7. SSL Handshake - First PartTime
Gray areas are optional in some circumstances.
7

8. SSL Handshake - Second PartTime
Gray areas are optional in some circumstances.
8
Client Server

9. 9
Application
Transport
Layer
(TCP,UDP)
Network
Layer (IP)
E'net Data
Link Layer
Ethernet
Phys. Layer
Network
Layer
E'net Data
Link Layer
E'net Phys.
Layer
Network
Layer
Process Process
Router
Buffers Packets that
need to be forwarded
(based on IP address).
Application
Transport
Layer
(TCP,UDP)
Network
Layer (IP)
Token Ring
Data-Link Layer
Token Ring
Phys. Layer
Token Ring
Data Link Layer
Token Ring
Phys. Layer
IPsec IPsec
SSL SSL

10. HTTPS is HTTP with SSL (Secure Socket Layer).
HTTPS uses the TLS/SSL default TCP port, port 443
10
Encrypt
HTTPS
:"Network Security Essentials: Applications and
Standards," Prentice Hall, by Wm. Stallings (ECE6612)
Web Browser or Web Server

11. 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

12. WireShark* View of HTTPS (TLS = SSL) Connection
*Capture Filter: ether host 00:D0:**:**:**:*c

13. 13
SET (Secure Electronic Transactions)
• Provides a secure communications channel among all the parties involved in a
transaction: Customer, Seller, Customer’s credit provider, Seller’s bank.
• Provides trust by the use of X.509v3 certificates.
• Ensures privacy because information is only made available to the parties that need it.
* Cardholder account authentication to the Merchant (Cardholder must have a
Certificate issued by the credit company). Merchant may issue a temporary Certificate
to issue the session is not hijacked).
* Verifies Merchant's relationship with financial institution.
* Integrity of data customer sends to Merchant (order info tied to funds transfer).

14. 14
SET - Steps in a Transaction
1. Customer opens account with credit company or bank.
2. Bank issues X.509 cert. to the Customer with RSA Keys.
3. Merchant has two certificates, signing and key exchange.
----
4. Customer places an order.
5. The Merchant sends the customer a copy of his certificate.
6. The Customer sends Order Information (OI) encrypted so the Merchant can read
it, and Payment Information (PI) encrypted so the Merchant can not read it.
---
7. Merchant requests payment by sending PI to the “Payment Gateway” (who can
decrypt it) and verifies Customer’s credit.
8. Merchant confirms the order to the Customer.
9. Merchant ships goods to Customer.
10. Merchant sends request for payment to the Payment Gateway which handles
transfer of funds.

15. 15
Secure Electronic Transactions (SET)

16. Electronic Payment Systems
Credit Card Protocols:
SSL, TLS, SET

17. Participants
•Issuing Bank
•Issues card
•Extends credit
•Assumes risk of card
•Cardholder reporting
Card
Associations
Merchant
•Merchant Bank (Acquirer)
•Sets up merchant
•Extends credit
•Assumes risk of merchant
•Funds merchant
Consumer
Processor Processor

18. 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)

19. 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
Authorizations
Batch Settlement
2.Card Authorization
via dial, lease line,
satellite
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
6. Acquiring Bank /
Processor
•scans settlement file
•verifies authorizations
match captured data
•prepares file for MC/VI
•prepares funding file
•records txs for reporting
4 . Issuing Bank / Processor
•receives auth request
•verifies available funds
•places hold on funds
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
8. MC / VI
debit issuers /
credit acquirers9. Acquiring Bank
funds merchant

20. Parties in Secure eCommerce

21. SET in Practice
SOURCE: http://www.software.ibm.com/commerce/payment/specsheetetill.html

22. 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

23. Root CA
(SET Co)
Geo-Political CA (optional)
(only for VISA)
Brand CA
(MasterCard, Visa)
Merchant CA
(Banesto)
Cardholder CA
(Banesto)
Cardholder
Payment Gateway CA
(MasterCard, Banesto in VISA
Merchant Payment Gateway
SET Certificate Hierarchy
Hosted by
SOURCE: INZA.COM

24. SSL Vs. SET
• A part of SSL (Secure Socket Layer) is available on
customers’ browsers
– it is basically an encryption mechanism for order taking, queries and
other applications
– it does not protect against all security hazards
– it is mature, simple, and widely use
• SET ( Secure Electronic Transaction) is a very
comprehensive security protocol
– it provides for privacy, authenticity, integrity, and, or repudiation
– it is used very infrequently due to its complexity and the need for a
special card reader by the user
– it may be abandoned if it is not simplified/improved

25. SET Vs. SSL
Secure Electronic Transaction (SET) Secure Socket Layer (SSL)
Complex Simple
SET is tailored to the credit card
payment to the merchants.
SSL is a protocol for general-
purpose secure message
exchanges (encryption).
SET protocol hides the customer’s
credit card information from
merchants, and also hides the order
information to banks, to protect
privacy. This scheme is called dual
signature.
SSL protocol may use a certificate,
but there is no payment gateway.
So, the merchants need to receive
both the ordering information and
credit card information, because
the capturing process should be
initiated by the merchants.

26. Payments, Protocols and Related Issues
• SET Protocol is for Credit Card Payments
• Electronic Cash and Micropayments
• Electronic Fund Transfer on the Internet
• Stored Value Cards and Electronic Cash
• Electronic Check Systems

27. • Security requirements
Payments, Protocols and Related Issues (cont.)
Authentication: A way to verify the buyer’s identity before
payments are made
Integrity: Ensuring that information will not be accidentally or
maliciously altered or destroyed, usually during transmission
Encryption: A process of making messages indecipherable
except by those who have an authorized decryption key
Non-repudiation: Merchants need protection against the
customer’s unjustifiable denial of placed orders, and customers need
protection against the merchants’ unjustifiable denial of past payment

28. Electronic Credit Card System
on the Internet
• The Players
Cardholder
Merchant (seller)
Issuer (your bank)
Acquirer (merchant’s financial institution,
acquires the sales slips)
Brand (VISA, Master Card)

29. Secure Electronic Transaction (SET) Protocol
1. The message is hashed to a prefixed length of message digest.
2. The message digest is encrypted with the sender’s private signature
key, and a digital signature is created.
3. The composition of message, digital signature, and Sender’s
certificate is encrypted with the symmetric key which is generated at
sender’s computer for every transaction. The result is an encrypted
message. SET protocol uses the DES algorithm instead of RSA for
encryption because DES can be executed much faster than RSA.
4. The Symmetric key itself is encrypted with the receiver’s public key
which was sent to the sender in advance. The result is a digital
envelope.
29
Sender’s Computer

30. 5. The encrypted message and digital envelope are transmitted to
receiver’s computer via the Internet.
6. The digital envelope is decrypted with receiver’s private exchange key.
7. Using the restored symmetric key, the encrypted message can be
restored to the message, digital signature, and sender’s certificate.
8. To confirm the integrity, the digital signature is decrypted by sender’s
public key, obtaining the message digest.
9. The delivered message is hashed to generate message digest.
10. The message digests obtained by steps 8 and 9 respectively, are
compared by the receiver to confirm whether there was any change
during the transmission. This step confirms the integrity.
Receiver’s Computer
Secure Electronic Transaction (SET)
Protocol (cont.)
30© Prentice Hall, 2000

31. Five Security Tips
• Don’t reveal your online Passcode to anyone. If you think your
online Passcode has been compromised, change it immediately.
• Don’t walk away from your computer if you are in the middle of a
session.
• Once you have finished conducting your banking on the Internet,
always sign off before visiting other Internet sites.
• If anyone else is likely to use your computer, clear your cache or
turn off and re-initiate your browser in order to eliminate copies of
Web pages that have been stored in your hard drive.
• Banks strongly recommends that you use a browser with 128-bit
encryption to conduct secure financial transactions over the
Internet.

32. Questions ?
email : rameshogania@gmail.com
Gsm : 9969 37 44 37