NETWORK SECURITY (15L019)

ASSIGNMENT PRESENTATION

WEB SECURITY
By
Rakesh Balaji V
17L238
INSTAGRAM PAGES
TWITTER: ELECTRONIC FUND TRANSFER:
WEB SECURITY
THREATS:
 Relative Location of Security Facilities in
the TCP/IP Protocol Stack:
In this chapter we look
into SSL/TSL and SET only.

NETWORK LEVEL: TRANSPORT LEVEL: APPLICATION LEVEL:

 Transparent to end users and Two implementation choices:  The service can be
applications.  As part of the underlying protocol suite and tailored to the specific
 IPSec includes a filtering therefore be transparent to applications. needs of a given
capability so that only selected  SSL can be embedded in specific packages. application.
traffic need incur the overhead of For example, Netscape and Microsoft  Important example of this
IPSec processing. Explorer browsers come equipped with SSL. approach is Secure
Electronic Transaction
(SET)
SSL (Secure Socket Layer):
 Transport layer security service
 Originally developed by Netscape
 Version 3 designed with public input
 Subsequently became Internet standard known as TLS (Transport
Layer Security)
 Uses TCP to provide a reliable end-to-end service
 SSL has two layers of protocols
SSL Architecture
Three higher layer protocols are part of SSL
SSL Architecture
SSL connection
• A transient, peer-to-peer, communications link
• Associated with 1 SSL session
SSL session
• An association between client & server
• Created by the Handshake Protocol
• Define a set of cryptographic parameters
• Can be shared among multiple SSL connections
• To avoid new security parameters of each connection
SESSION STATE AND CONNECTION
STATE PARAMETERS:
SESSION STATE: CONNECTION STATE:
• Session identifier • Server and Client random
• Peer certificate • Server write MAC secret
• Compression method • Client write MAC secret
• Cipher spec • Server write key
• Master secret • Client write key
• Is resumable • Initialization vectors
• Sequence numbers
SSL Record Protocol Services
Message integrity
• Using a MAC with shared secret key
• Similar to HMAC but with different padding
Confidentiality
• Using symmetric encryption with a shared secret key defined by Handshake
Protocol
• AES, IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40, RC4-128
• Message is compressed before encryption
SSL Record Protocol Operation

214 214 214

1024

1024

HEADER:
 Content type (8 bits)
 Major version (8 bits)
 Minor version (8 bits)
 Compressed length (16 bits)
SSL Change Cipher Spec Protocol
• One of 3 SSL specific protocols which use the SSL Record protocol
• A single message with 1 byte data.
• Causes pending state to become current
• Hence updating the cipher suite in use
• To indicate that the communication is shifted from unencrypted to
encrypted.
SSL Alert Protocol
LEVEL:
• Warning (value = 1)
• Fatal (value = 2)
If fatal, immediately terminates the connection. Other connections may
continue. But further connection won’t establish.
ALERT:
Contains code that indicates specific alert.
 Unexpected message  Handshake failure
 Bad record mac  Illegal parameter
 Decompression failure
SSL Handshake Protocol
Allows server & client to:
• Authenticate each other
• To negotiate encryption & MAC algorithms
• To negotiate cryptographic keys to be used

10 different messages
(refer book page 538
table 17.2)

Comprises a series of messages in phases

1. Establish Security Capabilities
2. Server Authentication and Key Exchange
3. Client Authentication and Key Exchange
4. Finish
SSL Handshake Protocol
TLS (Transport Layer Security) [SSLv3.1]
• IETF standard RFC 2246 similar to SSLv3
• With minor differences
1. in record format version number
2. uses HMAC for MAC
3. a pseudo-random function expands secrets
4. has additional alert codes
5. some changes in supported ciphers
6. changes in certificate types & negotiations
7. changes in crypto computations & padding
Secure Electronic Transactions (SET)
• Open encryption & security specification
• To protect Internet credit card transactions
• Developed in 1996 by Mastercard, Visa etc.
• Not a payment system
• Rather a set of security protocols & formats
1. secure communications among parties
2. trust from use of X.509v3 certificates SET is a complex specification defined in three
3. privacy by restricted info to those who books issued in May of 1997:
● Book 1: Business Description (80 pages)
need it ● Book 2: Programmer's Guide (629 pages)
● Book 3: Formal Protocol Definition (262
pages)
SET Components
SET Transaction
1. Customer opens account
2. Customer receives a certificate
3. Merchants have their own certificates
4. Customer places an order
5. Merchant is verified
6. Order and payment are sent
7. Merchant requests payment authorization
8. Merchant confirms order
9. Merchant provides goods or service
10. Merchant requests payment
Dual Signature
• Customer creates dual messages
• Order information (OI) for merchant
• Payment information (PI) for bank
• Neither party needs details of other
• But must know they are linked
• Use a dual signature for this
• Signed concatenated hashes of OI &
PI
DS=E(PRc, [H(H(PI)||H(OI))])
SET Purchase Request
SET purchase request exchange consists of four messages
1. Initiate Request - get certificates
2. Initiate Response - signed response
3. Purchase Request - of OI & PI
4. Purchase Response - ack order
Purchase Request – Customer
Purchase Request – Merchant
1. Verifies cardholder certificates using CA signature
2. Verifies dual signature using customer's public signature key to
ensure order has not been tampered with in transit & that it was
signed using cardholder's private signature key
3. Processes order and forwards the payment information to the
payment gateway for authorization (described later)
4. Sends a purchase response to cardholder
Purchase Request – Merchant
Payment Gateway Authorization
PAYMENT GATEWAY PERFORMS:
1. Verifies all certificates
2. Decrypts digital envelope of authorization block to obtain symmetric key & then decrypts
authorization block
3. Verifies merchant's signature on authorization block
4. Decrypts digital envelope of payment block to obtain symmetric key & then decrypts payment
block
5. Verifies dual signature on payment block
6. Verifies that transaction ID received from merchant matches that in PI received (indirectly)
from customer
7. Requests & receives an authorization from issuer
8. Sends authorization response back to merchant
Payment Capture
• Merchant sends payment gateway a payment capture request
• Gateway checks request
• Then causes funds to be transferred to merchants account
• Notifies merchant using capture response
Summary
Have considered:
• Need for web security
• SSL/TLS transport layer security protocols
• SET secure credit card payment protocols
THANK YOU