Documente Academic
Documente Profesional
Documente Cultură
2. Location of the threat : Web server, Web browser & N/W traffic between browser & server
Threats Integrity * Modification of user data * Trojan horse browser * Modification of memory
Consequences
Countermeasures
* Loss of info. Cryptographic * Compromise of checksum machine * Vulnerability to all other threats
Threats
Consequences
Countermeasures
Confide * Eavesdropping on the Net * Loss of info. ntiality *Theft of info from server * Loss of privacy *Theft of data from client * Info about network config * Info about which client talks to server
Threats DOS
Consequences
* Killing of user threads * Disruptive * Flooding machine with * Annoying bogus request * Filling up disk or memory * Prevent user from getting work done * Isolating machine by DNS attack
Threats
Consequences
Countermeasures
Cryptographic technique
It is transparent to end users and applications and provides a general-purpose solution. It includes a filtering capability so that only selected traffic need incur the overhead of IPSec processing.
There are two implementation choices. For full generality, SSL or TLS could be provided as part of the underlying protocol suite and therefore be transparent to applications SSL can be embedded in specific packages, Netscape and Microsoft Explorer browser come equipped with SSL, & most Web servers have implemented the protocol
PGP
SET HTTP
UDP
The service can be tailored to the specific needs of a given application In the context of web security, an important example of this approach is Secure Electronic Transaction (SET)
Application Layer
SSL Layer Transport Layer
The SSL layer is located between the application layer and the transport layer
IP
HTTP provides the transfer service for Web client/server interaction, can operate on top of SSL Three higher-layer protocols are defined as part of SSL: the Handshake Protocol, The Change Cipher Spec Protocol and the Alert Protocol These SSL specific protocols are used in the management of SSL exchanges
Every successful person has a painful story. Every painful story has a successful ending.
* Type (1 byte) : Indicates one of 10 messages fields Each Handshake message has three * Length (3 byte) : The length of the message in bytes
Parameters
None Version, random, session id, cipher suite, compression method Version, random, session id, cipher suite, compression method Chain of X.509V3 certificate Parameters, signatures Type, authorities None Signature Parameters, signature Hash value
4. Finish
Web server
Web browser
Web server
The exchange is initiated by the client, which sends a client_hello message with the parameters as Version : The highest SSL version understood by the client Random : Useful for later commn Session ID : This is a variable length session identifier Cipher suite : This list contains the cryptographic algorithms supported by the client in decreasing order
Compression method : This is a list of the compression methods the client supports
The server hello message consists of Version Random Session ID Cipher suite
Client
Server
Step 1 : Certificate
Step 2 : Server key exchange Step 3 : Certificate request Step 4 : Server hello done
Web server
1. The server sends its digital certificate, authenticating 2. It is optional. Server sends its public key to the client
Client
Server
Phase 2 : Server may send certificate, key exchange & request certificate. Server signals end of hello message phase
Web server
1. It is optional, requires only if the server had requested for the clients digital certificate 2. Like server key exchange, it allows the client to send info. To the server, but in the opposite direction. 3. It is necessary only if the server had demanded client authentication
Client
Server
Phase 2 : Server may send certificate, key exchange & request certificate. Server signals end of hello message phase
Phase 3 : Client sends certificate if requested. Client sends key exchange. Client may send certificate verification
Phase 4 : Finish
The client initiates this phase, which the server ends This phase completes the setting up of a secure connection This phase contains four steps :
Web browser
Step 1 : Change cipher specs Step 2 : Finished Step 3 : Change cipher specs Step 4 : Finished
Web server
Client
Server
Phase 2 : Server may send certificate, key exchange & request certificate. Server signals end of hello message phase
Phase 3 : Client sends certificate if requested. Client sends key exchange. Client may send certificate verification
The SSL record protocol takes an application message as input Application data Fragment Fragmentation : The original application message is broken into blocks, so that theCompress size of each block is less than or equal to 214 bytes (16,384 bytes). Compression : The fragmented blocks are optionally compressed. Compression must be lossless. Add MAC Addition of MAC : Using the shared secret key established in handshake protocol, the MAC (message authentication code) Encrypt for each block is calculated. Encryption : Using symmetric key established in the handshake protocol, the output Append SSL record header encrypted. This of the previous step is now encryption may not increase the overall size of the block by Append header : Finally, a header is added to the encrypted block : more than 1024 bytes Content type (8 bits) Major version (8 bits) Minor version (8 bits) Compressed length (16 bits)
Fragmentation : The original application message is broken into blocks, so that the size of each block is less than or equal to 214 bytes (16,384 bytes). Compression : The fragmented blocks are optionally compressed. Compression must be lossless. Addition of MAC : Using the shared secret key established in handshake protocol, the MAC for each block is calculated. Encryption : Using symmetric key established in the handshake protocol, the output of the previous step is now encrypted. This encryption may not increase the overall size of the block by SSL Record Format more than 1024 bytes Append header : Finally, a header is added to the encrypted block : Content type (8 bits) Major version (8 bits) Minor version (8 bits) Compressed length (16 bits)
Content type Major version Minor Compressed version length
Encrypted
Both the parties also destroy the session identifiers, secrets and keys associated with this connection before it is terminated. Each alert message consists of two bytes. First byte signifies the type of error. If it is a warning, this byte contains 1. If the error is fatal, this byte contains 2.
The second specifies the actual error
Alert protocol message format
Severity Byte 1 Cause Byte 2
Fatal Alerts
Description An inappropriate message was received An incorrect MAC was received The decompression function received improper input
Handshake failure
Sender was unable to negotiate an acceptable set of security parameters given the options available
A field in the handshake message was out of range or was inconsistent with the other field
Illegal parameters
Non-Fatal Alerts
Alert No certificate Bad certificate Unsupported certificate Description Sent in response to certificate request if an appropriate certificate is not available The certificate was corrupt The type of received certificate is not supported
Certificate revoked
Certificate expired Certificate unknown
Close notify
Notifies the recipient that the sender will not send any more messages on this connection. Each party must send this message before closing its side of the connection
Byte 1
The sole purpose of this message is cause the pending state to be copied into the current state, which updates the cipher suite to be used on this connection.
31
SSL
TLS
3.0 1.0 Supports an algorithm Does not support Fortezza called as Fortezza Cryptography Computed Uses a pseudorandom function to create master secret
Alert Protocol As explained earlier
The No certificate alert message is deleted. The newly added : Decryption failed, Record overflow, Unknown CA, Access denied, Decode error, Export restriction, Protocol version, Insufficient security, Internal error.
Handshake Protocol
As explained earlier
32
34
Merchant authentication
35
SET Participants
Cardholder : A cardholder is an authorized holder of a payment card such as MasterCard or Visa, issued by issuer Merchant : A merchant is a person or organization that has goods or services to sell to the cardholder. A merchant that accepts payment cards must have a relationship with acquirer Issuer : The issuer is a financial institution, such as bank, that provides a payment card to a cardholder. Acquirer : This is a financial institution that establishes an account with a merchant & processes payment card authorizations & payments. Payment gateway : It acts as an interface between SET & the existing card payment network for payment authorizations Certificate authority : This is an authority that is trusted to provide public key certificates to cardholders, merchants and payment gateways
36
Computer Security Chapter-6
When a customer involved a the actualissues a merchants Three main parties receives is acquirer, therequests theis their The certificate to customer inissuedmake bank or it credit A financial institution, an merchant transaction for The merchant and the customer by certificate, are also assured that the merchant and the payment gateway The customer, whomerchant is the card to the accept payments 37 respective certificates issued authorized to customer certificate. card company the has for that brand of credit card
Three main parties involved in the actual transaction are The customer, the merchant and the payment gateway
The merchant and the customer make requests for their respective certificates
The certificate to customer is issued by the bank or the credit card company who has issued the card to the customer
A financial institution, an acquirer, issues a merchants certificate. When a customer receives a merchant certificate, it is also assured that the merchant is authorized to accept payments for that brand of credit card
38
Certificate Authority A
Request for a certificate
Merchants certificate
Certificate Authority B
Cardholders certificate
Purchase Request
Cardholder
Authorization Response
Payment Gateway
39
40
41
SSL Vs SET
Issue
Main aim
Certification Authentication Risk of merchant fraud Risk of customer fraud Action in case of Customer fraud Practical usage
SSL
Exchange of data in an Encrypted form
two parties exchange certificate Mechanisms in place, but not very strong Possible, since customer gives financial data to merchant Possible, no mechanisms exist if a customer refuses to pay later Merchant is liable High
Computer Security Chapter-6
SET
E-commerce related payment mechanism
All the involved parties must be certified Strong mechanisms for authenticating all parties Unlikely, since customer gives financial data to payment gateway Customer has to digitally sign payment instructions Payment gateway is liable No much
42
End of Chapter 6
End of Syllabus
Happy Diwali & Best of Luck for Exam