2 - IP Security2 - IP Security2 - IP Security2 - IP Security

agfaf

1. Web Security: SSL
(Secure Socket Layer)

2. Secure Socket Layer (SSL)
SSL is a certificate-based general-purpose protocol.
Developed by Netscape
Manage the encryption of information transmitted over
the internet
SSL uses public key infrastructures; encryption is
done using public key
SSL version 3.0 has been implemented in many web
browsers (e.g., Netscape Navigator and MS Internet
Explorer) and web servers and widely used on the
Internet
SSL v3.0 was specified in an Internet Draft (1996)
it evolved into TLS specified in RFC 2246

3. SSL runs over TCP
TCP/IP protocol controls transmission and routing of
data over the internet.

4. Secure Socket Layer (SSL)
SSL uses TCP/IP protocol and allows the server to
authenticate by showing its certificate.
Client is authenticated using User-ID and password.
Authentication enables client and server to communicate
securely.
Issuing authority is responsible for distribution of SSL key
and certificates.
Client and server exchange the encrypted information
using SSL Handshake protocol.
They knows encryption algorithm and each other’s public
key for encryption and decryption.

5. Set of Protocols
Record Protocol: Used to assure security and integrity of the data. It
defines the format used to transmit the data.
ChangeCipher SpecProtocol: cryptographic parameter management
This message is sent by both the server and the client to inform the
other third party that subsequent records will be protected under the
just-negotiated CipherSpec and keys.
It consist of a single message.
The message is encrypted and compressed under the current
CipherSpec.
The client sends a ChangeCipher Spec message followed by the key
exchange and certificate to the server and the server sends a value
one after successfully processing the key exchange message.

6. Set of Protocols
Alert Protocol: transferring of SSL messages b/w server & client
Used to inform SSL-related alerts to the communication parties.
The message is encrypted and compressed.
Two bytes in each message in the alert protocol.
First byte indicates the severity of a message. If value is 1
(warning), If value is 2 (fatal) – terminates the connection
immediately.
Second byte of the message contains preset error codes. Error
code may occur during an SSL communication session.
Handshake Protocol: session management
Responsible for establishing an SSL connection.
First time, it uses the record protocol to exchange the messages
between client and the server.

7. Why SSL? SSL Provides ...
Confidentiality (Privacy)
Data integrity (Tamper-proofing)
Server authentication (Proving a server is
what it claims it is)
–Used in typical B2C transaction
Optional client authentication
–Would be required in B2B (or Web services
environment in which program talks to program)

8. SSL Key Exchange (Simplified)

9. SSL Key Exchange Steps
1. SSL client connects to an SSL server
2. Server then sends its own certificate that contains its
public key
3. Client then creates a random key (premaster key) and
uses server's public key to encrypt it
4. Client then sends encrypted premaster key to the
server
5. Server then decrypts it (only the server that has the
matching private key can decrypt it) and uses
decrypted premaster key to create secret session key
6. Now both client and server uses secret session key for
further communication

10. SSL Communication Parameters
1.Session Identifier: Generated by server. For
identifying a session with a client.
2.Peer Certificate: X.509 is used for authentication
3.Compression method: Before encryption
4.Algorithm specification: Encryption, Hashing
algorithm during session
5.Master Secret: Share secret data of 384 bits length

11. SSL Record Protocol – Formation of records
1.Fragmentation
2.Compression
3.Append MAC (MD5 or SHA-1)
4.Encryption
5.Attach Header: 1 byte – Protocol definition, 2 bytes
– protocol version (SSL 3.0; minor 0, major 3 ), 2
bytes – length (message + padding)

12. SSL Handshake Protocol
Establish security capabilities, server authentication & key
exchange, client authentication & key exchange, Finish

13. Client Hello Message Fields
Version: This field indicates the highest SSL version supported by the client.
Random: It consists of 32-bit timestamp and randomly generated value
(nonce) of length 28 bytes. This information is used to secure the key exchange
session between the server and the client.
Session ID: It is a number (variable length) used to define the session (c)
identifier. Non-zero value of this field indicates that the client wants to
update the parameters of an existing connection or wants to establish a new
connection on the existing session. If the value of this field is zero,
it indicates that the client wishes to establish a new connection on a new
session.
Cipher Suite list: A list of different encryption algorithms in decreasing order
of priorities and key exchange method supported by the client is given.
Compression method: This field gives the list of methods supported by client.

14. Server Hello Message Fields
Version: This field indicates the lowest SSL version supported by the
server.
Random value: It follows the same fashion as used by the client, but
the data generated is completely independent.
Session ID: The same value is sent back to the client if the field value
is non-zero, otherwise the value for a new session is sent.
Cipher Suite: The encryption algorithm and key exchange method
selected by the server from the list received from the client is given. The
first element of this field indicates the key exchange method, and the
next element indicates the encryption algorithm and hash functions
along with all specific parameters.

15. SSL and Encryption
You need only server's certificate in order to
have encrypted data transfer
–This is the reason why you don't need to install
client certificate on your browser in order to send
your credit card number securely (with privacy
and data integrity)

16. SSL and Authentication
In a typical “browser talking to web server”
communication, only server authentication is
needed
–When you send your credit card to a server, you
want to make sure the server is who it claims it is
In the future of B2B environment, client
certification would be also required
–The server wants to make sure it is talking to a
client whose identity is verified

17. SET
(Secure Electronic Transactions)

18. SET
SET protocol was jointly developed by Visa and
MasterCard, in cooperation with IBM, GTE,
Microsoft, Netscape, SAIC, Terisa, Verisign and
American Express.
SET is used to protect the privacy and confirm the
authenticity of online transactions.
In SET protocol, both the symmetric and asymmetric
encryption techniques (key transfer) are used.
Asymmetric encryption is also used for
authentication

19. SET Requirements
It should provide confidentiality of payment information and the
order given by the customer.
It should ensure the integrity of all data transmitted between the
customer and the merchant.
It should provide authentication to the customer as well as to
the merchant.
It should ensure that the techniques used are sufficient to
protect an electronic commerce transaction between the two
parties.
It should create a protocol, which works independent of
transport security systems.

20. SET Features
Confidentiality of information
Integrity of data
Cardholder account authentication
Merchant authentication

21. SET Participants
A merchant may be a person or an organization that has goods
and services to sell using web sites
Card Holder: In e-commerce, the customers or purchasers
interact with merchants through mobile phones, laptops or
computers. A cardholder is an authorized holder of the
payment card (credit or debit card) that has been issued by an
issuer.
Payment Issuer: It is the issuer of the payment card. It may be
any bank or financial institution.
Certification authority (CA): It is the trusted party which issue
certificates to the merchants, cardholders, and payment issuer.
Acquirer: It is an organization which provides card authorization
and payment capture for merchants.

22. Payment Transactions
The customer sends a message that he wants to make a payment.
The merchant responds to the request of the customer.
The customer provides details of the payment to be paid with a copy of
certificate.
The merchant sends a request of the customer for authorization to the
payment processing organization.
Authorization is verified using offered processes.
After verification of authorization, the authorization certificate is sent to
the merchant.
The merchant sends a message about customer payment transaction.
The merchant receives confirmation about the transaction.
The merchant sends confirmation message to the customer about the
successful transaction of payment.

23. Thanks