UNIT-7
1) IPSec Overview(Notebook)
Figure: IPSec scenario
2) IPSec Architecture(Notebook)
------------------------------------------------------------------------------------------------------------
3) AUTHENTICATION HEADER (AH)
AH covers the packet format and general issues related to the use of AH for packet authentication. Authentication makes use of the HMAC(MD5, SHA-1, RIPEMD-160). Authentication can be applied to all of theentireIP packet except for the IP Header i.e called as transport mode. Authentication can be applied to the entire original IP packet i.e called as tunnel mode. The IPSec AH is shown below.
Next Header (8 bits): Identifies the type of header immediately following this header.
Payload Length (8 bits): Length of Authentication Header in 32-bit words, minus 2.
Example:suppose the data field is 96 bits(6 words)
Then, the payload length = 6-2
=4 words
Reserved (16 bits): For future use.
Security Parameters Index (32 bits): Identifies a security association.
Sequence Number (32 bits): A monotonically increasing counter value.
Authentication Data (variable): A variable-length field (must be an integral number of 32-bit words) that contains the Integrity Check Value (ICV), or MAC, for this packet, discussed later.
3.1 Anti-Replay Service
A replay attack is one in which an attacker obtains a copy of an authenticated packet and later transmits it to the intended destination. Thereceipt of duplicate, authenticated IP packets may disrupt service in some way or may have some other undesired consequence. The Sequence Number field is designed to thwart such attacks. First, we discuss sequence number generation by the sender, and then we look at how it is processed by the recipient.
When a new SA is established, the sender initializes a sequence number counter to 0. Each time that a packet is sent on this SA, the sender increments the counter and places the value in the Sequence Number field. Thus, the first value to be used is 1. If anti-replayisenabled (the default), the sender must not allow the sequence number to cycle past 232-1 back to zero. Otherwise, there would be multiple valid packets with the same sequence number. If the limit of 232-1 is reached, the sender should terminate this SA and negotiate a new SA with a new key.
Because IP is a connectionless, unreliable service, the protocol does not guarantee that packets will be delivered in order and does not guarantee that all packets will be delivered. Therefore, the IPSec authentication document dictates that the receiver should implement a window of size W, with a default of W = 64. The right edge of the window represents the highest sequence number, N, so far received for a valid packet. For any packet with a sequence number in the range from N - W + 1 to N that has been correctly received (i.e., properly authenticated), the corresponding slot in the window is marked (shown in Figure). Inbound processing proceeds as follows when a packet is received:
1. If the received packet falls within the window and is new, the MAC is checked. If the packet is authenticated, the correspondingslot in the window is marked.
2. If the received packet is to the right of the window and is new, the MAC is checked. If the packet is authenticated, the windowis advanced so that this sequence number is the right edge of the window, and the corresponding slot in the window is marked.
3. If the received packet is to the left of the window, or if authentication fails, the packet is discarded; this is an auditable event.
3.2 Integrity Check Value
The Authentication Data field holds a value referred to as the Integrity Check Value. The ICV is a message authentication code or a truncated version of a code produced by a MAC algorithm. The current specification dictates that a compliant implementation must support
· HMAC-MD5-96
· HMAC-SHA-1-96
Both of these use the HMAC algorithm. In both cases, the full HMAC value is calculated.
The MAC is calculated over
· IP header fields that either do not change in transit (immutable) or that are predictable in value upon arrival at the endpoint for the AH SA. Fields that may change in transit and whose value on arrival are unpredictable are set to zero for purposes of calculation at both source and destination.
· The AH header other than the Authentication Data field. The Authentication Data field is set to zero for purposes of calculationat both source and destination.
· The entire upper-level protocol data, which is assumed to be immutable in transit (e.g., a TCP segment or an inner IP packet in tunnel mode).
3.3 Transport and Tunnel modes
Figure 1shows two ways in which the IPSec authentication service can be used. In one case, authentication is provided directly between a server and client workstations; the workstation can be either on the same network as the server or on an external network. As long as the workstation and the server share a protected secret key, the authentication process is secure. This case uses a transport mode SA. In the other case, a remote workstation authenticates itself to the corporate firewall, either for access to the entire internal network or because the requested server does not support the authentication feature. This case uses a tunnel mode SA.
Figure 1: End-to-End versus End-to-Intermediate Authentication
Figure 2shows typical IPv4 and IPv6 packets. In this case, the IP payload isa TCP segment; it could also be a data unit for any other protocol that uses IP, such as UDP or ICMP.
Figure 2: Before applying AH
For transport mode AH using IPv4, the AH is inserted after the original IP header and before the IP payload (e.g., a TCP segment); this is shown in the Figure 3(upper part).
In the context of IPv6, AH is viewed as an end-to-end payload; that is, it is not examined or processed by intermediate routers. Therefore, the AH appears after the IPv6 base header and the hop-by-hop, routing, and fragment extension headers. The destination options extension header could appear before or after the AH header, depending on the semantics desired. Again, authentication covers the entire packet, excluding mutable fields that are set to zero for MAC calculation.
Figure 3: Transport Mode
For tunnel mode AH, the entire original IP packet is authenticated, and the AH is inserted between the original IP header and a new outer IP header (Figure 4). The inner IP header carries the ultimate source and destination addresses, while an outer IP header may contain different IP addresses (e.g., addresses of firewalls or other security gateways).
With tunnel mode, the entire inner IP packet, including the entire inner IP header is protected by AH. The outer IP header (and in the case of IPv6, the outer IP extension headers) is protected except for mutable and unpredictable fields.
Figure 4: Tunnel Mode
-----------------------------------------------------THANK U---------------------------------------------------------------
4) ENCAPSULATING SECURITY PAYLOAD (ESP)
The Encapsulating Security Payload provides confidentiality services, including confidentiality of message contents and limited traffic flowconfidentiality. As an optional feature, ESP can also provide an authentication service.
4.1 ESP FORMAT
Given figure shows the format of an ESP packet. It contains the following fields:
Security Parameters Index (32 bits): Identifies a security association.
Sequence Number (32 bits): A monotonically increasing counter value; this provides an anti-replay function, as discussed for AH.
Payload Data (variable): This is a transport-level segment (transport mode) or IP packet (tunnel mode) that is protected by encryption.
Padding (0-255 bytes): The Padding field serves several purposes:
· If an encryption algorithm requires the plaintext to be a multiple of some number of bytes, the Padding field is used to expand the plaintext to the required length.
· Additional padding may be added to provide partial traffic flow confidentiality by concealing the actual length of the payload.
· The ESP format requires that the Pad Length and Next Header fields.
Pad Length (8 bits): Indicates the number of pad bytes immediately preceding this field.
Next Header (8 bits): Identifies the type of data contained in the payload data field by identifying the first header in that payload (for example, an extension header in IPv6, or an upper-layer protocol such as TCP).
Authentication Data (variable): A variable-length field (must be an integral number of 32-bit words) that contains the Integrity Check Value computed over the ESP packet minus the Authentication Data field.
4.2 Encryption and Authentication Algorithms
The Payload Data, Padding, Pad Length, and Next Header fields are encrypted by the ESP service. If the algorithm used to encrypt the payload requires cryptographic synchronization data, such as an initialization vector (IV), then these data may be carried explicitly at the beginning of the Payload Data field. A number of algorithms have been assigned identifiers in the DOI document and could therefore easily be used for encryption; these include
· Three-key triple DES
· RC5
· IDEA
· Three-key triple IDEA
· CAST
· Blowfish
As with AH, ESP supports the use of a MAC with a default length of 96 bits. Also as with AH, the current specification dictates that a compliant implementation must support
· HMAC-MD5-96
· HMAC-SHA-1-96
4.3 Transport and Tunnel Modes
Given two figures shows two ways in which the IPSec ESP service can be used. In thefigure 1, encryption (and optionally authentication) is provided directly between two hosts. Figure 2 shows how tunnel mode operation can be used to set up a virtual private network.
Figure 1:Transport level security
Figure 2:A virtual Private Network via tunnel mode
Figure 3shows typical IPv4 and IPv6 packets. In this case, the IP payload isa TCP segment; it could also be a data unit for any other protocol that uses IP, such as UDP or ICMP.
Figure 2: Before applying ESP
Transport mode ESP is used to encrypt and optionally authenticate the data carried by IP (e.g., a TCP segment), as shown in Figure 3. For this mode using IPv4, the ESP header is inserted into the IP packet immediately prior to the transport-layer header (e.g., TCP, UDP, ICMP) and an ESP trailer (Padding, Pad Length, and Next Header fields) is placed after the IP packet; if authentication is selected, the ESP Authentication Data field is added after the ESP trailer. The entire transport-level segment plus the ESP trailer are encrypted. Authentication covers all of the ciphertext plus the ESP header.In the context of IPv6, ESP is viewed as an end-to-end payload; that is, it is not examined or processed by intermediate routers. Therefore, the ESP header appears after the IPv6 base header and the hop-by-hop, routing, and fragment extension headers. The destination options extension header could appear before or after the ESP header, depending on the semantics desired. For IPv6, encryption covers the entire transport-level segment plus the ESP trailer plus the destination options extension header if it occurs after the ESP header. Again, authentication covers the ciphertext plus the ESP header.
Figure 3:Transport mode
Tunnel mode ESP is used to encrypt an entire IP packet (Figure 4). For this mode, the ESP header is prefixed to the packet and then the packet plus the ESP trailer is encrypted. This method can be used to counter traffic analysis.
Figure 4:Tunnel mode
-----------------------------------------------------------------------------THANK U--------------------------------------------------
5) COMBINING SECURITY ASSOCIATIONS(Notebook)
---------------------------------------------------------------------------------------------------------------------
6) KEY MANAGEMENT
The default automated key management protocol in IPSec is Oakley key determination protocol or ISAKMP
Oakley key exchange protocol:is based on diffie-hellan and provides added security. It is a generic protocol and does not dictate specific formats.
ISAKMP protocol:providesaframeworkforinternet key management and specific protocol support, including formats, for negotiation of security attributes.
6.1 Oakley Key Determination Protocol(Notebook)
6.2 ISAKMP (Internet Security Association & Key Management Protocol)or IKE (Internet Key Exchange)
ISAKMP defines procedures and packet formats to establish, negotiate, modify, and delete security associations. As part of SA establishment, ISAKMP defines payloads for exchanging key generation and authentication data. These payload formats provide a consistent framework independent of the specific key exchange protocol, encryption algorithm, and authentication mechanism.
ISAKMP Header Format:
An ISAKMP message consists of an ISAKMP header followed by one or more payloads. All of this is carried in a transport protocol. The given figure shows the header format for an ISAKMP message.
Figure: ISAKMP Header
· Initiator Cookie (64 bits):Cookie of entity that initiated SA establishment, SA notification, or SA deletion.
· Responder Cookie (64 bits):Cookie of responding entity; null in first message from initiator.
· Next Payload (8 bits):Indicates the type of the first payload in the message; payloads are discussed in the next subsection.
· Major Version (4 bits):Indicates major version of ISAKMP in use.
· Minor Version (4 bits):Indicates minor version in use.
· Exchange Type (8 bits):Indicates the type of exchange;
· Flags (8 bits):Indicates specific options set for this ISAKMP exchange. Two bits so far defined: The Encryption bit is set if all payloads following the header are encrypted using the encryption algorithm for this SA. The Commit bit is used to ensure that encrypted material is not received prior to completion of SA establishment.
· Message ID (32 bits):Unique ID for this message.
· Length (32 bits):Length of total message (header plus all payloads) in octets.
ISAKMP Payload Types:
All ISAKMP payloads begin with the same generic payload header shown in below figure.
Figure: Generic payload header
· Next payload:Next Payload field has a value of 0 if this is the last payload in the message; otherwise its value is the type of the next payload.
· Reserved: this is used for the future purpose.
· Payload Length:indicates the length in octets of this payload, including the generic payload header.
Different ISAKMP Payload types are
· Security Association payload (SA)
· Proposal payload (P)
· Transform payload (T)
· Key Exchange payload (KE)
· Identification payload (ID)
· Certificate payload (CERT)
· Certificate Request payload (CR)
· Hash payload (HASH)
· Signature payload (SIG)
· Nonce payload (NONCE)
· Notification payload (N)
· Delete payload (D)
The given table summarizes the parameters and description of payload types.
ISAKMP Exchanges:
ISAKMPprovides a framework for message exchange, with the payload types serving as the building blocks. Different ISAKMP exchange types are
· Base Exchange
· Identity Protection Exchange
· Authentication Only Exchange
· Aggressive Exchange
· Informational Exchange
i) Base Exchange:
Exchange Note
(1)I àR: SA; NONCE Begin ISAKMP-SA negotiation
(2)Rà I: SA; NONCE Basic SA agreed upon
(3)Ià R: KE; IDI; AUTH Key generated; Initiator identity verified by responder
(4)Rà I: KE; IDR; AUTH Responder identity verified by initiator; Key generated; SA established
The Base Exchange allows key exchange and authentication material to be transmitted together. This minimizes the number ofexchanges at the expense of not providing identity protection. The first two messages provide cookies and establish an SA with agreed protocol and transforms; both sides use a nonce to ensure against replay attacks. The last two messages exchange the key material and user IDs, with an authentication mechanism used to authenticate keys, identities, and the nonces from the first two messages.
ii) Identity Protection Exchange:
Exchange Note
(1)I àR: SA Begin ISAKMP-SA negotiation
(2)R àI: SA Basic SA agreed upon
(3)I àR: KE; NONCE Key generated
(4)R àI: KE; NONCE Key generated
(5)*I àR: IDI; AUTH Initiator identity verified by responder
(6)*R àI: IDR; AUTH Responder identity verified by initiator; SA established
The Identity Protection Exchange expands the Base Exchange to protect the users' identities. The first two messages establish the SA.The next two messages perform key exchange, with nonces for replay protection. Once the session key has been computed, the two parties exchange encrypted messages that contain authentication information, such as digital signatures and optionally certificates validating the public keys.
iii) Authentication Only Exchange:
Exchange Note
(1)Ià R: SA; NONCE Begin ISAKMP-SA negotiation
(2)Rà I: SA; NONCE; IDR; AUTH Basic SA agreed upon; Responder identity verified by initiator
(3)I àR: IDI; AUTH Initiator identity verified by responder; SA established
The Authentication Only Exchange is used to perform mutual authentication, without a key exchange. The first two messages establishthe SA. In addition, the responder uses the second message to convey its ID and uses authentication to protect the message. The initiator sends the third message to transmit its authenticated ID.
iv) Aggressive Exchange:
Exchange Note
(1)Ià R: SA; KE; NONCE; IDI; Begin ISAKMP-SA negotiation and key exchange
(2)R àI: SA; KE; NONCE; IDR; AUTH Initiator identity verified by responder; Key generated; Basic SA agreed upon
(3)*I àR: AUTH Responder identity verified by initiator; SA established
The Aggressive Exchange minimizes the number of exchanges at the expense of not providing identity protection. In the first message,the initiator proposes an SA with associated offered protocol and transform options. The initiator also begins the key exchange and provides its ID. In the second message, the responder indicates its acceptance of the SA with a particular protocol and transform, completes the key exchange, and authenticates the transmitted information. In the third message, the initiator transmits an authentication result that covers the previous information, encrypted using the shared secret session key.
v) Informational Exchange:
Exchange Note
(1)*I R: N/D Error or status notification, or deletion
The Informational Exchange is used for one-way transmittal of information for SA management.
Notation:
I = initiator
R = responder
* = signifies payload encryption after the ISAKMP header
AUTH = authentication mechanism used
---------------------------------------------------------------------------------THANK U----------------------------------------------
7) WEB SECURITY CONSIDERATIONS
The World Wide Web is fundamentally a client/server application running over the Internet and TCP/IP intranets. The Challenges in the web are
· The Internet is two way. Unlike traditional publishing environments, even electronic publishing systems involving teletext, voice response, or fax-back, the Web is vulnerable to attacks on the Web servers over the Internet.
· The Web is a platform for businesstransactions. Reputations can be damaged and money can be lost if the Web servers are subverted.
· Although Web browsers are very easy to use, Web servers are relatively easy to configure and manage, and Web content is increasingly easy to develop, the underlying software is extraordinarily complex. This complex software may hide many potential security flaws.
· Once the Web server is subverted, an attacker may be able to gain access to data and systems not part of the Web itself but connected to the server at the local site.
· Casual and untrained users are common clients for Web-based services. Such users are not necessarily aware of the security risks that exist and do not have the tools or knowledge to take effective countermeasures.
7.1 Web Security Threats
World Wide Webis widely used in business, government and by individuals. But the data on internet and web are vulnerable to different threats. Different types of security threats faced in using the web are
· Threats on integrity
· Threats on confidentiality
· Threats on Denial of service
· Threats on Authentication
The given table provides a summary of the types of security threats faced in the web.
7.2 Web Traffic Security Approaches
A number of approaches to providing web security are possible. Now we discuss how to provide the Security facilities in TCP/IP.
At Network Level:Security is implemented in end-systems. One way to provide web security is to use IP Security (As shown in Fig(a) )
At Transport level:Security is implemented in end-systems. Secure Socket Layer(SSL) and Transport Layer Security(TLS) are security applications implemented at transport layer. (as shown in Fig(b))
At Application Level:Security is implemented in end-systems. PGP, S/MIME, SET, Kerberos are some security applications implemented in application layer. (as shown in Fig(c))
-------------------------------------------------------------------------THANK U------------------------------------------------------
8) SECURE SOCKET LAYER(SSL)
SSL is designed to make use of TCP to provide a reliable end-to-end secure service. SSL is not a single protocol but rather two layers of protocols. The SSL Architecture is shown in given Fig.
Figure: SSL protocol stack/ SSL Architecture
Two important SSL concepts are the SSL session and the SSL connection, which are defined in the specification as follows:
SSL Session:An SSL session is an association between a client and a server. Sessions are created by the Handshake Protocol. Sessions are used to avoid the expensive negotiation of new security parameters for each connection. A session state is defined by the following parameters.
· Session Identifier
· Peer certificate
· Compression method
· Cipher spec
· Master secret
· Is resumable
SSL Connection:A connection is a transport that provides a suitable type of service. For SSL, such connections are peer-to-peer relationships. The connections are transient. Every connection is associated with one session. A connection state is defined by the following parameters.
· Server and Client random
· Server write MAC secret
· Client write MAC secret
· Server write key
· Client write key
· Initialization vectors
· Sequence numbers
8.1SSL Record Protocol
The SSL Record Protocol provides two services for SSL connections:
Confidentiality:The Handshake Protocol defines a shared secret key that is used for conventional encryption of SSL payloads.
Message Integrity:The Handshake Protocol also defines a shared secret key that is used to form a message authentication code (MAC).
The Given Figure indicates the overall operation of the SSL Record Protocol.
Figure: SSL record Protocol Operation
· The first step is Fragmentation. Each upper-layer message is fragmented into blocks of 214 bytes or less.
· Next step is Compression. It is optionally applied. Compression must be lossless and may not increase the content length by more than 1024 bytes.
· Next step is Message authentication code over the compressed data. For this purpose, a shared secret key is used.
· In next step, the compressed message plus the Message authentication code are encrypted using symmetric encryption.
· The final step of SSL Record protocol processing is Append SSL record headerwith following fields.
Content type(8 bits):Thehigher layer protocol used to process the enclosed fragment.
Major Version (8 bits): Indicates major version of SSL in use.
Minor Version (8 bits): Indicates minor version in use.
Compressed Length (16 bits): The length can be calculated in bytes. The maximum length is 214 + 2048.
The given Figure illustrates the SSL record format
Figure: SSL Record format
8.2Change Cipher Spec Protocol
Figure: SSL Record Protocol Payload
The Change Cipher Spec Protocol is one of the three SSL-specific protocols that use the SSL Record Protocol, and it is the simplest. This protocol consists of a single message (Figure (a)), which consists of a single byte with the value 1. Thepurpose of this message is to cause the pending state to be copied into the current state, which updates the cipher suite to be used on this connection.
8.3 Alert Protocol
The Alert Protocol is one of the three SSL-specific protocols that use the SSL Record Protocol. The Alert Protocol is used to convey SSL-related alerts to the peer entity.As with other applications that use SSL, alert messages are
Compressed and encrypted, as specified by the current state. Each message in this protocol consists of two bytes (Figure (b)). The first byte takes the value warning (1) or fatal (2) to convey the severity of the message. The second byte contains a code that indicates the specific alert.
8.4 Handshake Protocol
The Handshake Protocol is one of the three SSL-specific protocols that use the SSL Record Protocol. The most complex part of SSL is the Handshake Protocol.Each message in this protocol consists of three Fields (Figure (c)).
· Type(1 byte)
· Length(3 bytes)
· Content(>= 0 bytes)
The given Figure shows the initial exchange needed to establish a logical connection between client and server. The exchange can be viewed as having four phases.
Phase1: Establish Security Capabilities
Phase2: Server Authentication and Key Exchange
Phase3:Client Authentication and Key Exchange
Phase4:Finish
Figure: Handshake Protocol Action
Phase1: Establish Security Capabilities
This phase is used to initiate a logical connection and to establish the security capabilities that will be associated with it. The exchange is initiated by the client, which sends a client_hello message. After sending the client_hello message, the client waits for the server_hello message, which containsthe same parameters as the client_hello message. For the server_hello message, the followingconventions apply.
· Version
· Random
· Session ID
· CipherSuite
· Compression Method
Phase 2: Server Authentication and Key Exchange
The server begins this phase by sending its certificate, if it needs to be authenticated;Next, a server_key_exchange message may be sent if it is required. It is not required in two instances: (1) The server has sent a certificate with fixed Diffie-Hellman parameters, or (2) RSA key exchange is to be used. Next, anonanonymous server can request a certificatefrom the client. The certificate_request message includes two parameters: certificate_typeandcertificate_authorities. The final message in Phase 2, and one that is always required, is the server_done message, which issent by the server to indicate the end of the server hello and associated messages. After sending thismessage, the server will wait for a client response.
Phase3:Client Authentication and Key Exchange
Client sends certificate if requested.
Client sends key exchange.
Client may send certificate verification.
Phase4:Finish
This phase completes the setting up of a secure connection. The client sends a change_cipher_specmessageand copies the pending CipherSpec into the current CipherSpec.Theclientthen immediately sends the finished message under the new algorithms, keys, and secrets. Thefinished message verifies that the key exchange and authentication processes were successful.
-----------------------------------------------------------------THANK U--------------------------------------------------------------
9) TRANSPORT LAYER SECURITY (TLS)
The Goalof TLS is to produce an Internet standard version of SSL. The differences between SSLv3 and TLS are:
· Version Number
· Message Authentication Code(MAC)
· Pseudo-Random Function(PRF)
· Alert codes
· Cipher Suits
Version Number
The TLS Record Format is the same as that of the SSL Record Format, and the fields in theheader have the same meanings. The one difference is in version values. For the current version of TLS,the Major Version is 3 and the Minor Version is 1.
Message Authentication Code(MAC)
There are two differences between the SSLv3 and TLS MAC schemes: the actual algorithm and the scopeof the MAC calculation. TLS makes use of the HMAC algorithm defined in RFC 2104. HMAC is defined as follows:
Where,
H = embedded hash function
M = message input to HMAC
K+ = secret key padded with zeros on the left so that the result is equal to the block length of the hash code
ipad = 00110110 repeated 64 times
opad = 01011100 repeated 64 times
The MAC calculation covers all of the fields covered by the SSLv3 calculation, plus the fieldTLSCompressed.Version, which is the version of the protocol being employed.
Pseudo-Random Function
TLS makes use of a pseudorandom function referred to as PRF to expand secrets into blocks of data forpurposes of key generation or validation. The PRF is based on the following data expansion function (shown in given Figure):
P_hash (secret, seed) = HMAC_hash (secret, A(1) || seed) ||
=HMAC_hash (secret, A(2) || seed) ||
= HMAC_hash (secret, A(3) || seed) || ......
where A() is defined as
A(0) = seed
A(i) = HMAC_hash (secret, A(i - 1))
Figure: TLS Function P_hash(secret, seed)
The data expansion function makes use of the HMAC algorithm, with either MD5 or SHA-1 as theunderlying hash function. As can be seen, P_hash can be iterated as many times as necessary toproduce the required quantity of data. For example, if P_SHA-1 was used to generate 64 bytes of data, it would have to be iterated four times, producing 80 bytes of data, of which the last 16 would bediscarded. In this case, P_MD5 would also have to be iterated four times, producing exactly 64 bytes ofdata. Note that each iteration involves two executions of HMAC, each of which in turn involves twoexecutions of the underlying hash algorithm.
Alert Codes
TLS supports all of the alert codes defined in SSLv3 with the exception of no_certificate. A number of additional codes are defined in TLS; of these, the following are always fatal:
· Decryption_failed
· Record_overflow
· Unknown_ca
· Access_denied
· Decode_error
· Export_restriction
· Protocol_version
· Insufficient_security
· Internal_error
Cipher Suits
There are several small differences between the cipher suites available under SSLv3 and under TLS:
· Key Exchange: TLS supports all of the key exchange techniques of SSLv3 with the exception of Fortezza.
· Symmetric Encryption Algorithms: TLS includes all of the symmetric encryption algorithms found in SSLv3, with theexception of Fortezza algorithm.
----------------------------------------------------------------------- THANK U-------------------------------------------------------
10) SECURE ELECTRONIC TRANSACTION(SET)
SET is an open encryption and security specification designed to protectcredit card transactions on the Internet. The current version, SETv1, emerged from a call for security standards by MasterCard and Visa card.
10.1 SET Participants
Figure: Secure Electronic commerce components
The above figure indicates the participants in the SET system, which includes Cardholder, Merchant, Issuer, Acquirer, Payment gateway, Certificate authority (CA).
Cardholder: In the electronic environment, consumers and corporate purchasers interact with merchants from personal computers over the Internet. A cardholder is an authorized holder of a payment card (e.g., MasterCard, Visa) that has been issued by an issuer.
Merchant:A merchant is a person or organization that has goods or services to sell to the cardholder. Typically, these goods and services are offered via a Web site or by electronic mail. A merchant that accepts payment cards must have a relationship with an acquirer.
Issuer:This is a financial institution, such as a bank, that provides the cardholder with the payment card. Typically, accounts are applied for and opened by mail or in person. Ultimately, it is the issuer that is responsible for the payment of the debt of the cardholder.
Acquirer:The acquirer provides authorization to the merchant that a given card account is active and that the proposed purchase does not exceed the credit limit. The acquirer also provides electronic transfer of payments to the merchant's account.
Payment gateway:This is a function operated by the acquirer or a designated third party that processes merchant payment messages. The payment gateway interfaces between SET and the existing bankcard payment networks for authorization and payment functions.
Certification Authority (CA): This is an entity that is trusted to issuepublic-key certificates for cardholders, merchants, and payment gateways. The success of SET will depend on the existence of a CA infrastructure available for this purpose.
We now briefly describe the sequence of events that are required for a transaction. We will then look at some of the cryptographic details.
1. The customer opens an account
2. The customer receives a certificate
3. Merchants have their own certificates
4. The customer places an order
5. The merchant is verified
6. The order and payment are sent
7. The merchant requests payment authorization
8. The merchant confirms the order
9. The merchant provides the goods or services
10. The merchant requests payment
10.2 DUAL SIGNATURE
The purpose of the dual signature is to link two messages that are intended for two different recipients. In this case, the customer wants to send the order information (OI) to the merchant and the payment information (PI) to the bank. The merchant does not need to know the customer's credit card number, and the bank does not need to know the details of the customer's order. The customer is afforded extra protection in terms of privacy by keeping these two items separate. However, the two items must be linked in a way that can be used to resolve disputes if necessary. The link is needed so that the customer can prove that this payment is intended for this order and not for some other goods or service.
To see the need for the link, suppose that the customers send the merchant two messages: a signed OI and a signed PI, and the merchant passes the PI on to the bank. If the merchant can capture another OI from this customer, the merchant could claim that this OI goes with the PI rather than the original OI. The linkage prevents this.
Figure: Construction of Dual Signature
The above figure shows the use of a dual signature to meet the requirement of the preceding paragraph. The customer takes the hash (using SHA-1) of the PI and the hash of the OI. These two hashes are then concatenated and the hash of the result is taken. Finally, the customer encrypts the final hash with his or her private signature key, creating the dual signature. The operation can be summarized as
DS = E(PRc, [H(H(PI)||H(OI)])
wherePRcis the customer's private signature key. Now suppose that the merchant is in possession of the dual signature (DS), the OI, and the message digest for the PI (PIMD). The merchant also has the public key of the customer, taken from the customer's certificate.
In summary,
1. The merchant has received OI and verified the signature.
2. The bank has received PI and verified the signature.
3. The customer has linked the OI and PI and can prove the linkage.
10.3Payment Processing
In payment processing we discuss following transactions in detail:
· Purchase request
· Payment authorization
· Payment capture
10.3.1. Purchase request:Before the Purchase Request exchange begins, the Cardholderhas completed browsing, selecting, and ordering. The end of this preliminary phase occurs when the merchant sends a completed order form to the customer. All of the preceding occurs without the use of SET. The purchase request consists of four messages: Initiate Request, Initiate Response, Purchase Request and Purchase Response.
Ø Initiate Request: The customer requests the certificates in the Initiate Request message, sent to the merchant. This message includes the brand of the credit card that the customer is using.
Ø Initiate Response: The merchant generates a response and signs it with its private signature key.In addition to the signedresponse, the Initiate Response message includes the merchant's signature certificate and the payment gateway's key exchange certificate.
Ø Purchase Request:Next, the cardholder prepares the Purchase Request message (shown in given Figure).
Figure: Cardholder sends Purchase Request
For this purpose, the cardholder generates a one-time symmetric encryption key, Ks. The message includes the following:
1. Purchase-related information:This information will be forwarded to the payment-gateway by the merchant.
2.Order-related information:This information is needed by the merchant.
3. Cardholder certificate: This contains the cardholder’s public signature key. It is needed by the merchant and by the payment gateway.
Ø Purchase Response:When the merchant receives the Purchase Request message, it performs the following actions(shown in given figure)
1. Verifies the cardholder certificates by means of its CA signatures.
2. Verifies the dual signature using the customer's public signature key.
3. Processes the order and forwards the payment information to the payment gateway for authorization.
4. Sends a purchase response to the cardholder.
10.3.2. Payment Authorization:During the processing of an order form a cardholder, the merchant authorizes the transaction with the payment gateway. The payment authorization consists of two messages:Authorization Request and Authorization Response.
Ø Authorization Request: Themerchant sends an Authorization Request message to the payment gateway consisting of the following:
1. Purchase-related information: This information was obtained from the customer.
2.Authorization-related information:This information is generated by the merchant.
3. Certificates:The merchant includes the cardholder's signature key certificate, themerchant's signature key certificate, and the merchant's key-exchange certificate.
Ø Authorization Response:The payment gateway returns an Authorization Responsemessage to the merchant. It includes the following elements:
1.Authorization-related information
2. Capture token information
3. Certificate
10.3.3. Payment Capture:To obtain payment, the merchant engages the payment gateway in a payment capture transaction. The payment capture consists of two messages: capture request and capture response.
Ø Capture Request: For the Capture Request message, the merchant generates, signs, and encrypts a capture request block, which includes the payment amount and the transaction ID.
Ø Capture Response:The gateway then notifies the merchant of payment in a Capture Response message. The message includes a capture response block that the gateway signs and encrypts.
--------------------------------------------------------------THANK U-----------------------------------------------------------------
No comments:
Post a Comment