SlideShare una empresa de Scribd logo
1 de 31
Descargar para leer sin conexión
NETWORK SECURITY (10EC832)
8th SEM E&C
JAYANTHDWIJESH H P M.tech (DECS)
Assistant Professor – Dept of E&CE
B.G.S INSTITUTE OF TECHNOLOGY (B.G.S.I.T)
B.G Nagara, Nagamangala Tq, Mandya District- 571448
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 1
NETWORK SECURITY
PART-B
UNIT-5
UNIT - 5
Web Security Consideration, Security socket layer (SSL) and Transport layer security,
Secure Electronic Transaction.
TEXT BOOK:
1. Cryptography and Network Security, William Stalling, Pearson Education, 2003.
REFERENCE BOOKS:
1. Cryptography and Network Security, Behrouz A. Forouzan, TMH, 2007.
2. Cryptography and Network Security, Atul Kahate, TMH, 2003.
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 2
PART – B
UNIT - 5
Web Security Consideration, Security socket layer (SSL) and Transport layer security, Secure
Electronic Transaction.
1. WEB SECURITY CONSIDERATION
The World Wide Web is fundamentally a client/server application running over the
Internet and TCP/IP intranets.
The web provides the following Web Security Threats which make web security a must:
 The Internet is two way. Even unimportant systems like electronic publishing
systems, voice response, or fax-back are vulnerable to attacks on the Web servers
over the Internet.
 The Web is increasingly serving as a platform for corporate and product information
and as the platform for business transactions. Reputations can be damaged and money
can be lost if the Web servers are subverted.
 Although Web browsers, web servers are very easy to use and manage and web
content is easy to develop, the underlying software is extraordinarily complex. This
complex software may hide many potential security flaws and hence is more
vulnerable to a variety of security attacks.
 A Web server can be exploited as a launching pad into the corporation’s or agency’s
entire computer complex. 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’ common clients for Web-based services. Such users are
not always aware of the security risks.
1.1 WEB SECURITY THREATS JUNE/JULY-2013[8M]
Table 1 provides a summary of the types of security threats faced when using the
Web. One way to group these threats is in terms of passive and active attacks. Passive attacks
include eavesdropping on network traffic between browser and server and gaining access to
information on a Web site that is supposed to be restricted.
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 3
Active attacks include impersonating another user, altering messages in transit between client
and server, and altering information on a Web site. Another way to classify Web security
threats is in terms of the location of the threat: Web server, Web browser, and network traffic
between browser and server.
Table 1 A Comparison of Threats on the Web
1.2 WEB TRAFFIC SECURITY APPROACHES
Figure 1 Relative Location of Security Facilities in the TCP/IP Protocol Stack
 Figure illustrates that one way to provide Web security is to use IP security (IPsec)
(Figure 1 (a)).
 The advantage of using IPsec is that it is transparent to end users and applications and
provides a general purpose solution.
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 4
 Furthermore, IPsec includes a filtering capability so that only selected traffic need
incur the overhead of IPsec processing.
 Another relatively general-purpose solution is to implement security just above TCP
(Figure 1 (B)).
 The foremost example of this approaches the Secure Sockets Layer (SSL) and the
follow-on Internet standard known as Transport Layer Security (TLS).
 At this level, there are two implementation choices.
 For full generality, SSL (or TLS) could provide as part of the underlying protocol
suite and therefore be transparent to applications.
 Alternatively, SSL can embed in specific packages.
 For example, Netscape and Microsoft Explorer browsers come equipped with SSL,
and most Web servers have implemented the protocol.
 Application-specific security services embedded within the particular application.
 The figure shows (Figure 1 (C)). Examples of this architecture.
 The advantage of this approach is that the service can tailor to the specific needs of a
given application
2. SECURE SOCKET LAYER
2.1 SSL ARCHITECTURE MAY/JUNE-2010 [10M], JUN/JULY-2011 [10M], DEC-2011[4M],
DEC-2012[10M], JUNE/JULY-2013[8M], DEC/JAN-2016[10M]
Figure 2 SSL Protocol Stack
 Secure Socket Layer is designed to make use of TCP to provide a reliable end-to-end
secure service.
 Moreover, Secure Socket Layer is not a single protocol but rather two layers of
protocols, as illustrated in Figure (2) below.
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 5
 The SSL Record Protocol provides basic security services to various higher layer
protocols.
 In particular, the Hypertext Transfer Protocol (HTTP), which 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.
Two important SSL concepts are the SSL session and the SSL connection, which are
defined in the specification as follows. DEC-2012[4M]
 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 associated with one session.
 Session: An SSL session is an association between a client and a server. Sessions
are created by the Handshake Protocol. Sessions define a set of cryptographic
security parameters which can be shared among multiple connections. Sessions
are used to avoid the expensive negotiation of new security parameters for each
connection.
 There a number of states associated with each session. Once a session established,
there is a current operating state for both read and write (i.e., receive and send)
 In addition, during the Handshake Protocol, pending read and writes states created.
Upon successful conclusion of the Handshake Protocol, the pending states become the
current states
A session state is defined by the following parameters MAY/JUNE-2010 [10M], JUN/JULY-
2011[10M]
 Session identifier: An arbitrary byte sequence chosen by the server to identify an
active or resumable session state.
 Peer certificate: An X509.v3 certificate of the peer. This element of the state may be
null.
 Compression method: The algorithm used to compress data prior to encryption.
 Cipher spec: Specifies the bulk data encryption algorithm (such as null, AES, etc.)
and a hash algorithm (such as MD5 or SHA-1) used for MAC calculation. It also
defines cryptographic attributes such as the hash size.
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 6
 Master secret: 48-byte secret shared between the client and the server.
 Is resumable: A flag indicating whether the session can be used to initiate new
connections.
A connection state is defined by the following parameters. MAY/JUNE-2010 [10M],
JUN/JULY-2011[10M]
 Server and client random: Byte sequences that are chosen by the server and client
for each connection.
 Server write MAC secret: The secret key used in MAC operations on data sent by
the server.
 Client write MAC secret: The secret key used in MAC operations on data sent by
the client.
 Server write key: The secret encryption key for data encrypted by the server and
decrypted by the client.
 Client write key: The symmetric encryption key for data encrypted by the client and
decrypted by the server.
 Initialization vectors: When a block cipher in CBC mode is used, an initialization
vector (IV) is maintained for each key. This field is first initialized by the SSL
Handshake Protocol.
 Sequence numbers: Each party maintains separate sequence numbers for transmitted
and received messages for each connection. When a party sends or receives a change
cipher spec message, the appropriate sequence number is set to zero. Sequence
numbers may not exceed 264
- 1.
2.2 SSL RECORD PROTOCOL: SSL PROTOCOL JUN/JULY-2017[10M], JUNE-
2012[10M]
 The SSL Record Protocol provides two services for SSL
connections: Confidentiality and Message Integrity.
 Moreover, the overall operation of Record Protocol is:
 Fragmentation: Each upper-layer message fragmented into blocks of 214
bytes (16384
bytes) or less.
 Compression: Compression is optionally applied. Compression must be lossless and may
not increase the content length by more than 1024 bytes.
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 7
Figure 3 SSL Record Protocol Operation
 Add message authentication code: MAC calculated over the compressed data by the
following expression.
Hash (MAC_write_secret  pad_2  hash (MAC_write_secret  pad_1  seq _ num  SSL
Compressed. type  SSL Compressed. length  SSL Compressed. fragment))
Where
|| = concatenation.
MAC_write_secret = shared secret key.
Hash = cryptographic hash algorithm.
pad_1 = the byte 0x36 (0011 0110) repeated 48 times (384 bits) for MD5 and 40 times (320
Bits) for SHA-1.
pad_2 = the byte 0x5C (0101 1100) repeated 48 Times for MD5 and 40 times for SHA-1.
seq _ num = the sequence number for this message.
SSL Compressed .type = the higher-level protocol used to process this fragment.
SSL Compressed. Length = the length of the compressed fragment.
SSL Compressed. Fragment = the compressed fragment or plain text (if compression =not
used).
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 8
 Encryption: The compressed message plus the MAC encrypted using symmetric
encryption. Algorithms supported are AES, RC4-40, IDEA, RC2, DES, 3DES and
Fortezza.
 The final step of SSL Record Protocol processing is to prepare a header consisting of the
following fields:
 Content Type (8 bits): The higher-layer protocol used to process the fragment.
 Major Version (8 bits): Indicates major version of SSL in use. For SSLv3, the value
is 3.
 Minor Version (8 bits): Indicates minor version in use. For SSLv3, the value is 0.
 Compressed Length (16 bits): The length in bytes of the fragment.
 Figure 4 illustrates the SSL record format.
Figure 4 SSL Record Format
2.3 CHANGE CIPHER SPEC PROTOCOL
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 5(a)) of a single byte with the value 1.
The purpose of this message to cause the pending state to be copied into the current state,
which updates the cipher suite to be used on this connection.
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 9
Figure 5 SSL Record Protocol Payload
2.4 Alert Protocol
 The Alert Protocol used to convey SSL-related alerts to the peer entity.
 Moreover, each message in this protocol consists of two bytes (Figure 5(b)).
 The first byte takes the value warning (1) or fatal (2) to convey the severity of the
message.
 If the level is fatal, SSL immediately terminates the connection.
 Other connections on the same session may continue, but no new connections
established.
 The second byte contains a code that indicates the specific alert.
 First, we list those alerts that are always fatal (definitions from the SSL specification):
 Unexpected message: An inappropriate message was received.
 Bad _ record _ mac: An incorrect MAC was received.
 Decompression _ failure: The decompression function received improper input
(e.g., unable to decompress or decompress to greater than maximum allowable
length).
 Handshake _ failure: Sender was unable to negotiate an acceptable set of
security parameters given the options available.
 Illegal _ parameter: A field in a handshake message was out of range or
inconsistent with other fields.
 The remaining alerts are the following.
 Close _ notify: Notifies the recipient that the sender will not send any more
messages on this connection. Each party is required to send a close _ notify alert
before closing the write side of a connection.
 No_ certificate: May be sent in response to a certificate request if no appropriate
certificate is available.
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 10
 Bad _ certificate: A received certificate was corrupt (e.g., contained a signature
that did not verify).
 Unsupported _ certificate: The type of the received certificate is not supported.
 Certificate _ revoked: A certificate has been revoked by its signer.
 Certificate _ expired: A certificate has expired.
 Certificate _ unknown: Some other unspecified issue arose in processing the
certificate, rendering it unacceptable.
2.5 Handshake Protocol DEC-2010 [12M], DEC-2011[8M], JAN-2015[10M]
Table 2 SSL Handshake Protocol Message Types
This Handshake Protocol allows the server and client to authenticate each other and to
negotiate an encryption and MAC algorithm and cryptographic keys.
Moreover, The Handshake Protocol is used before any application data is transmitted.
A handshake message has the following format:
1. Type (1 byte): Indicates one of 10 messages of handshake protocol. Table 2 lists the
defined message types
2. Length (3 bytes): The length of the message in bytes.
3. Content (bytes): The parameters associated with this message.
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 11
Similarly, the algorithm has four phases
Phase 1. 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 with the
following parameters:
 Version: The highest SSL version understood by the client.
 Random: A client-generated random number which serves as the nonce.
 Session ID: A variable-length session identifier. A nonzero value indicates that the
client wishes to update the parameters of an existing session. A zero value indicates
that the client wishes to establish a new connection on a new session.
 Cipher Suite: This is a list that contains the cryptographic algorithms (key exchange,
encryption, and MAC) supported by the client, in decreasing order of preference.
 Compression Method: This is a list of the compression methods the client supports.
 After sending the client _ hello message, the client waits for the server _ hello
message, which contains the same parameters as the client _ hello message. The
parameters contain the values which client had sent to the server and the server has
chosen to use.
Phase 2: Server Authentication and Key Exchange:
This phase provides authentication of the server to the client. o The server sends its
certificate (one or more) if it needs to be authenticated.
 The server sends a server _ key _ exchange message which contains the list of secret
keys to be used for the subsequent data. The certificate _ request message is sent next
which includes two parameters: certificate _ type and certificate _ authorities.
 Moreover, the final message in phase 2, and one that always required is the server _
done message, which sent by the server to indicate the end of the server hello and
associated messages.
 After sending this message, the server will wait for a client response. This message has no
parameters.
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 12
Figure 6 Handshake Protocol Action
Phase 3. Client Authentication and Key Exchange:
This phase provides client authentication to the server.
 The client verifies the server certificates and checks whether the server _ hello parameters
are acceptable.
 Moreover, if all is satisfactory, the client sends a certificate message if the server has
requested a certificate. If no suitable certificate is available, the client sends a no _
certificate alert.
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 13
 Next is the client _ key _ exchange message which has the same parameters as the server
_key _ exchange message.
 Similarly, the client may send a certificate _ verify message to provide explicit
verification of a client certificate.
The client encrypts all the previous messages and master secret with its private key.
Phase 4. Finish
This phase completes the setting up of a secure connection.
 The client sends a change _ Cipher _ spec message and copies the pending Cipher
Spec into the current Cipher Spec.
 Moreover, The client then immediately sends the finished
 The server sends its own change _ cipher _ spec message, transfers the pending to
the current Cipher Spec, and sends it finished
 At this point, the handshake is complete and the client and server may begin to
exchange application-layer data.
3. TRANSPORT LAYER SECURITY (TLS)
 TLS is an IETF standardization initiative whose goal is to produce an Internet
standard version of SSL.
 Moreover, TLS is defined as a Proposed Internet Standard in RFC 5246. Which is
very similar to SSLv3.
 We highlight the differences.
Version Number
 The one difference is in version values. For the current version of TLS, the major version
is 3 and the minor version is 3.
Message Authentication Code: Transport Layer Security
 There are two differences between the SSLv3 and TLS MAC schemes:
 The actual algorithm and the scope of the MAC calculation.
 TLS makes use of the HMAC algorithm defined in RFC 2104.
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 14
 HMAC is defined as
where
H = embedded hash function (for TLS, either MD5 or SHA-1)
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 (for MD5 and SHA-1, block length = 512 bits)
Ipad = 00110110 (36 in hexadecimal) repeated 64 times (512 bits)
opad = 01011100 (5C in hexadecimal) repeated 64 times (512 bits)
 SSLv3 uses the same algorithm, except that the padding bytes are concatenated with the
secret key rather than being XORed with the secret key padded to the block length.
 Moreover, The level of security should be about the same in both cases.
 For TLS, the MAC calculation encompasses the fields indicated in the following
expression:
MAC(MAC_write_secret,seq_num || TLSCompressed.type ||
TLSCompressed.version || TLSCompressed.length ||
TLSCompressed.fragment)
 The MAC calculation covers all of the fields covered by the SSLv3 calculation, plus the
field version, which is the version of the protocol being employed.
3.1 PSEUDORANDOM FUNCTION:
 TLS makes use of a pseudorandom function referred to as PRF to expand secrets into
blocks of data for purposes of key generation or validation.
 Moreover, the objective is to make use of a relatively small shared secret value but to
generate longer blocks of data in a way that is secure from the kinds of attacks made on
hash functions and MACs.
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 15
Figure 7 TLS Function P _ hash (secret, seed)
 The PRF is based on the data expansion function (Figure 7) given as
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) )
 PRF defined as
PRF (secret, label, seed) = P _ hash (S1, label || seed)
PRF takes as input a secret value, an identifying label, and a seed value and produces an
output of arbitrary length.
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 16
Alert Codes: Transport Layer Security
 TLS supports all of the alert codes defined in SSLv3 with the exception of no _
certificate.
 A number of additional codes defined in TLS; of these, the following are always fatal.
 Record _ overflow: A TLS record was received with a payload (cipher text) whose
length exceeds 214 + 2048 bytes, or the cipher text decrypted to a length of greater
than 214 + 1024 bytes.
 Unknown _ ca: A valid certificate chain or partial chain was received, but the
certificate was not accepted because the CA certificate could not be located or could
not be matched with a known, trusted CA.
 Access _ denied: A valid certificate was received, but when access control was
applied, the sender decided not to proceed with the negotiation.
 Decode _ error: A message could not be decoded, because either a field was out of
its specified range or the length of the message was incorrect.
 Protocol _version: The protocol version the client attempted to negotiate is
recognized but not supported.
 Insufficient _ security: Returned instead of handshake _ failure when a negotiation
has failed specifically because the server requires ciphers more secure than those
supported by the client.
 Unsupported _ extension: Sent by clients that receives an extended server hello
containing an extension not in the corresponding client hello.
 Internal _ error: An internal error unrelated to the peer or the correctness of the
protocol makes it impossible to continue.
 Decrypt _ error: A handshake cryptographic operation failed, including being unable
to verify a signature, decrypt a key exchange, or validate a finished message.
 The remaining alerts include the following.
 User _ cancelled: This handshake is being cancelled for some reason unrelated to a
protocol failure.
 No _ renegotiation: Sent by a client in response to a hello request or by the server in
response to a client hello after initial handshaking. Either of these messages would
normally result in renegotiation, but this alert indicates that the sender is not able to
renegotiate. This message is always a warning.
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 17
Cipher Suites:
Moreover, 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 the exception of Fortezza.
4 SECURE ELECTRONIC TRANSACTIONS (SET) JUN/JULY-2011[10M]
is an open encryption and security specification designed to protect credit card
transactions on the Internet. The current version, SETv1, emerged from a call for security
standards by MasterCard and Visa in February 1996. A wide range of companies were
involved in developing the initial specification, including IBM, Microsoft, Netscape, RSA,
Terisa, and Verisign. Beginning in 1996.
SET is not itself a payment system. Rather it is a set of security protocols and formats that
enables users to employ the existing credit card payment infrastructure on an open network,
such as the Internet, in a secure fashion. In essence, SET provides three services:
 Provides a secure communications channel among all parties involved in a transaction
 Provides trust by the use of X.509v3 digital certificates
 Ensures privacy because the information is only available to parties in a transaction
when and where necessary.
4.1 SET Overview:
A good way to begin our discussion of SET is to look at the business requirements for
SET, its key features, and the participants in SET transactions.
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 18
4.2 SET Requirements: DEC-2010 [8M], JUN/JULY-2017[10M], JUN/JULY-2011[10M], JAN -
2014 [10M] , JAN-2015[10M]
The SET specification lists the following business requirements for secure payment
processing with credit cards over the Internet and other networks:
 Provide confidentiality of payment and ordering information: It is necessary to
assure cardholders that this information is safe and accessible only to the intended
recipient. Confidentiality also reduces the risk of fraud by either party to the
transaction or by malicious third parties. SET uses encryption to provide
confidentiality.
 Ensure the integrity of all transmitted data: That is, ensure that no changes in
content occur during transmission of SET messages. Digital signatures are used to
provide integrity.
 Provide authentication that a cardholder is a legitimate user of a credit card
account: A mechanism that links a cardholder to a specific account number reduces
the incidence of fraud and the overall cost of payment processing. Digital signatures
and certificates are used to verify that a cardholder is a legitimate user of a valid
account.
 Provide authentication that a merchant can accept credit card transactions
through its relationship with a financial institution: This is the complement to the
preceding requirement. Cardholders need to be able to identify merchants with whom
they can conduct secure transactions. Again, digital signatures and certificates are
used.
 Ensure the use of the best security practices and system design techniques to
protect all legitimate parties in an electronic commerce transaction: SET is a
well-tested specification based on highly secure cryptographic algorithms and
protocols.
 Create a protocol that neither depends on transport security mechanisms nor
prevents their use: SET can securely operate over a "raw" TCP/IP stack. However,
SET does not interfere with the use of other security mechanisms, such as IPSec and
SSL/TLS.
 Facilitate and encourage interoperability among software and network
providers: The SET protocols and formats are independent of hardware platform,
operating system, and Web software.
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 19
4.3 Key Features of SET DEC-2012[5M], JAN -2014[10M], JAN-2015[10M], DEC/JAN-2016[5M]
To meet the requirements just outlined, SET incorporates the following features:
 Confidentiality of information: Cardholder account and payment information is
secured as it travels across the network. An interesting and important feature of SET
is that it prevents the merchant from learning the cardholder's credit card number; this
is only provided to the issuing bank. Conventional encryption by DES is used to
provide confidentiality.
 Integrity of data: Payment information sent from cardholders to merchants includes
order information, personal data, and payment instructions. SET guarantees that these
message contents are not altered in transit. RSA digital signatures, using SHA-1 hash
codes, provide message integrity. Certain messages are also protected by HMAC
using SHA-1.
 Cardholder account authentication: SET enables merchants to verify that a
cardholder is a legitimate user of a valid card account number. SET uses X.509v3
digital certificates with RSA signatures for this purpose.
 Merchant authentication: SET enables cardholders to verify that a merchant has a
relationship with a financial institution allowing it to accept payment cards. SET uses
X.509v3 digital certificates with RSA signatures for this purpose. Note that unlike
IPSec and SSL/TLS, SET provides only one choice for each cryptographic algorithm.
This makes sense, because SET is a single application with a single set of
requirements, whereas IPSec and SSL/TLS are intended to support a range of
applications.
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 20
4.4 SET Participants JUNE-2012[10M]
Fig 8: secure electronic commerce components
 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 (MasterCard, Visa, and so on) that has been issued by an issuer.
 Merchant: A merchant is a person or organization with goods or services to sell to the
cardholder. Typically, these goods or 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, the issuer is responsible for the payment of the debt of the cardholder.
 Acquirer: This is a financial institution that establishes an account with a merchant and
processes payment card authorizations and payments. Merchants will usually accept more
than one credit card brand but don't want to deal with multiple bankcard associations or
with multiple individual issuers. The acquirer provides authorization to the merchant that
a given card accounts is active and that the proposed purchase does not exceed the credit
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 21
limit. The acquirer also provides electronic transfer of payments to the merchant's
account. Subsequently, the acquirer is reimbursed by the issuer over some sort of
payment network for electronic funds transfer.
 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. The merchant exchanges SET messages with the payment gateway over the
Internet, while the payment gateway has some direct or network connection to the
acquirer's financial processing system.
 Certification Authority (CA): This is an entity that is trusted to issue X.509v3 public-
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. A hierarchy
of CAs is used, so that participants need not be directly certified by a root authority.
4.5 SET in Action
SET is a dynamic, automated scheme that allows a customer with a credit card to order
items over the Internet from merchants, in a secure fashion. A typical scenario goes like this:
1. The customer opens an account. The customer obtains a credit card account, such as
MasterCard or Visa, with a bank that supports electronic payment and SET.
2. The customer receives a certificate. After suitable verification of identity, the
customer receives an X.509v3 digital certificate, which is signed by the bank. The
certificate verifies the customer's RSA public key and its expiration date. It also
establishes a relationship, guaranteed by the bank, between the customer's key pair
and his or her credit card.
3. Merchants Have Their Own Certificates. A merchant who accepts a certain brand
of card must be in possession of two certificates for two public keys owned by the
merchant: one for signing messages, and one for key exchange. The merchant also
needs a copy of the payment gateway's public-key certificate.
4. The customer places an order. This is a process that may involve the customer first
browsing through the merchant's web site to select items and determine the price. The
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 22
customer then sends a list of the items to be purchased from the merchant, who
returns an order form containing the list of items, their individual prices, a total price,
and an order number.
5. The merchant is verified. In addition to the order form, the merchant sends a copy of
its certificate, so that the customer can verify that he or she is dealing with a valid
store.
6. The order and payment are sent. The customer sends both an order and payment
information to the merchant, along with the customer's certificate. The order confirms
the purchase of the items in the order form. The payment contains credit card details.
The payment information is encrypted in such a way that it cannot be read by the
merchant. The customer's certificate enables the merchant to verify the customer.
7. The merchant requests payment authorization. The merchant sends the payment
information to the payment gateway, requesting authorization that the customer's
available credit is sufficient for this purchase.
8. The merchant confirms the order. The merchant sends confirmation of the order to
the customer.
9. The merchant provides the goods or service. The merchant ships the goods or
provides the service to the customer.
10. The merchant requests payment. This request is sent to the payment gateway,
which handles all of the payment processing.
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 23
4.6 Dual Signature MAY/JUNE-2010[10M], DEC-2012[5M], JAN -2014[10M]
 Before looking at the details of the SET protocol, let's discuss an important innovation
introduced in SET: the 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 doesn't need to know the customer's credit card number, and the bank
doesn't 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 services.
 To see the need for the link, suppose that the customer sends the merchant two messages:
a signed OI and a signed PI, and the merchant passes the PI 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 9 shows the use of a dual signature to meet this
requirement.
Construction of dual signature
 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
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 24
 where K𝑅 𝐶 is the customer's private signature key:
Fig 9: construction of dual signature
 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.
 Then the merchant can compute the two quantities:
 where K𝑈 𝐶 is the customer's public signature key:
 If these two quantities are equal, the merchant has verified the signature. Similarly, if the
bank is in possession of DS, PI, the message digest for OI (OIMD), and the customer's
public key, the bank can compute the following.
 Again, if these two quantities are equal, the bank has verified the signature. 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.
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 25
4.7 PAYMENT PROCESSING
1. Purchase Request DEC-2011[8M]
Before the Purchase Request exchange begins, the cardholder has 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 exchange consists of four messages:
 Initiate Request.
 Initiate Response.
 Purchase Request.
 Purchase Response.
The cardholder prepares the Purchase Request message figure (10) and generates a onetime
symmetric encryption key, Ks. The message includes the following:
a. Purchase-related information. This information will be forwarded to the payment
gateway by the merchant and consists of
 The PI
 The dual signature, calculated over the PI and OI, signed with the customer's private
signature key
 The OI message digest (OIMD)
 The OIMD is needed for the payment gateway to verify the dual signature. All of these
items are encrypted with Ks. The final item is - The digital envelope. This is formed by
encrypting Ks with the payment gateway's public key-exchange key.
b. Order – related information. This information is needed by the merchant and consists
of
 The OI
 The dual signature, calculated over the PI and OI, signed with the customer's private
signature key
 The PI message digest (PIMD)
 The PIMD is needed for the merchant to verify the dual signature.
c. Cardholder certificate. This contains the cardholders’ public signature key. It is needed
by the merchant and by the payment gateway.
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 26
When the merchant receivers the purchase request message, it performs the following actions
(figure 11)
 Verifies the cardholder certificates by means of its CA signatures.
 Verify the dual signature using the customer’s public signature key.
 Processes the order and forward the payment information to the payment gateway for
authorization.
 Sends a purchase response to the cardholder.
Fig 10 cardholder sends purchase request
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 27
Fig 11 merchant verifies customer purchase request
2. Payment Authorization DEC-2011[8M]
 The payment authorization ensures that the transaction was approved by the issuer.
 This authorization guarantees that the merchant will receive payment; the merchant can
therefore provide the services or goods to the customer.
 The payment authorization exchange consists of two messages; authorization request and
authorization response.
 The merchant sends an authorization request message to the payment gateway consisting
of the following:
a. Payment -related information. This information was obtained from the customer and
consists of the following:
 The PI
 The dual signature, calculated over the PI and OI, signed with the customer's
private signature key
 The OI messages digest (OIMD).
 The digital envelope
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 28
b. Authorization – related information. This information is generated by the merchant and
consists of
 an authorization block that includes the transaction ID, signed with the mechant
private signature key and encrypted with a one time symmetric key generated by the
merchant
 a digital envelope. This is formed by encrypting the one time key with the payment
gateways public key exchange key.
c. Certificate. The merchant includes the cardholder’s signature key certificate, the
merchant’s signature key certificate and the merchants key exchange certificate.
3. 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
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 29
QUESTION BANK –NETWORK SECURITY
UNIT-5
MAY/JUNE-2010
1. Explain secure socket layer (SSL) protocol stack with a neat diagram and define the
different parameters used in session and connection states. (10M)
2. What is need of dual signature in SET? Describe with block diagram, how they are
constructed. (10M)
DEC-2010
1. Briefly explain the SET requirements. (08M)
2. Explain the various phases of SSL handshake protocol. (12M)
JUN/JULY-2017
1. Discuss security socket layer (SSL) record protocol in terms of fragmentation, compression
and encryption. (10M)
2. Describe the sequence of events that are required for a transaction in secure electronic
transaction (SET). (10M)
JUNE/JULY-2011
1. Explain the two SSL concepts with their parameters. (10M)
2. Describe the sequence of events that are required for a transaction in SET. (10M)
DEC-2011
1. With a diagram, explain handshake protocol action.(8M)
2. Explain in details the following transactions supported by SET: (8M)
1) Purchase request 2) payment authorization.
3. Explain SSL protocol stack. (4M)
JUNE-2012
1. Discuss SSL record protocol in terms of fragmentation, compression and encryption.(10M)
2. Discuss secure electronic transaction (SET) protocol with neat diagram.(10M)
DEC-2012
1. Explain SSL architecture with neat diagram. (10M)
2. What is the difference b/w SSL connection and SSL session? (04M)
3. Describe the purchase of dual signature. (05M)
4. Mention key features of SET. (05M)
JUNE/JULY-2013
NETWORK SECURITY 10EC832
Dept. of ECE, BGSIT, BG Nagara, Mandya Page 30
1. List different types of threats and consequence when using the web. Also countermeasures
to be taken. (08M)
2. Elucidate SSL architecture. (08M)
3. Explain approaches to intrusion detection system. (04M)
JAN -2014
1. What is the need for dual signature in SET? How are they constructed? (10M)
2. Discuss the key requirements and features of SET. (10M)
JAN-2015
1. Explain the key requirements and features of secure electronic transaction. (10M)
2. Explain the various phases of SSL handshake protocol. (10M)
DEC/JAN-2016
1. Explain the SSL architecture. (10M)
2. Highlight the key features of SET. (05M)
3. Explain in detail, the payment capture transaction supported by SET. (05M)

Más contenido relacionado

La actualidad más candente

BAIT1103 Chapter 6
BAIT1103 Chapter 6BAIT1103 Chapter 6
BAIT1103 Chapter 6limsh
 
Secure Socket Layer
Secure Socket LayerSecure Socket Layer
Secure Socket LayerNaveen Kumar
 
6. cryptography
6. cryptography6. cryptography
6. cryptography7wounders
 
Vtu network security(10 ec832) unit 1 notes
Vtu network security(10 ec832) unit 1 notesVtu network security(10 ec832) unit 1 notes
Vtu network security(10 ec832) unit 1 notesJayanth Dwijesh H P
 
Threshold-optimal DSAECDSA signatures and an application to Bitcoin wallet se...
Threshold-optimal DSAECDSA signatures and an application to Bitcoin wallet se...Threshold-optimal DSAECDSA signatures and an application to Bitcoin wallet se...
Threshold-optimal DSAECDSA signatures and an application to Bitcoin wallet se...National Chengchi University
 
Message Authentication Requirement-MAC
Message Authentication Requirement-MACMessage Authentication Requirement-MAC
Message Authentication Requirement-MACSou Jana
 
Encryption And Decryption Using AES Algorithm
Encryption And Decryption Using AES AlgorithmEncryption And Decryption Using AES Algorithm
Encryption And Decryption Using AES AlgorithmAhmed Raza Shaikh
 
CRYPTOGRAPHY AND NETWORK SECURITY
CRYPTOGRAPHY AND NETWORK SECURITYCRYPTOGRAPHY AND NETWORK SECURITY
CRYPTOGRAPHY AND NETWORK SECURITYKathirvel Ayyaswamy
 
Basic Cryptography unit 4 CSS
Basic Cryptography unit 4 CSSBasic Cryptography unit 4 CSS
Basic Cryptography unit 4 CSSSURBHI SAROHA
 
SSL/TLS Introduction with Practical Examples Including Wireshark Captures
SSL/TLS Introduction with Practical Examples Including Wireshark CapturesSSL/TLS Introduction with Practical Examples Including Wireshark Captures
SSL/TLS Introduction with Practical Examples Including Wireshark CapturesJaroslavChmurny
 
Advanced Encryption Standard (AES) Implementaion using Java
Advanced Encryption Standard (AES) Implementaion using JavaAdvanced Encryption Standard (AES) Implementaion using Java
Advanced Encryption Standard (AES) Implementaion using JavaSunil Kumar R
 
Ssl (Secure Sockets Layer)
Ssl (Secure Sockets Layer)Ssl (Secure Sockets Layer)
Ssl (Secure Sockets Layer)Asad Ali
 

La actualidad más candente (20)

BAIT1103 Chapter 6
BAIT1103 Chapter 6BAIT1103 Chapter 6
BAIT1103 Chapter 6
 
Secure Socket Layer
Secure Socket LayerSecure Socket Layer
Secure Socket Layer
 
6. cryptography
6. cryptography6. cryptography
6. cryptography
 
Vtu network security(10 ec832) unit 1 notes
Vtu network security(10 ec832) unit 1 notesVtu network security(10 ec832) unit 1 notes
Vtu network security(10 ec832) unit 1 notes
 
Threshold-optimal DSAECDSA signatures and an application to Bitcoin wallet se...
Threshold-optimal DSAECDSA signatures and an application to Bitcoin wallet se...Threshold-optimal DSAECDSA signatures and an application to Bitcoin wallet se...
Threshold-optimal DSAECDSA signatures and an application to Bitcoin wallet se...
 
Message Authentication Requirement-MAC
Message Authentication Requirement-MACMessage Authentication Requirement-MAC
Message Authentication Requirement-MAC
 
Encryption And Decryption Using AES Algorithm
Encryption And Decryption Using AES AlgorithmEncryption And Decryption Using AES Algorithm
Encryption And Decryption Using AES Algorithm
 
Steganography
SteganographySteganography
Steganography
 
Secure Your Encryption with HSM
Secure Your Encryption with HSMSecure Your Encryption with HSM
Secure Your Encryption with HSM
 
Cryptography
CryptographyCryptography
Cryptography
 
CRYPTOGRAPHY AND NETWORK SECURITY
CRYPTOGRAPHY AND NETWORK SECURITYCRYPTOGRAPHY AND NETWORK SECURITY
CRYPTOGRAPHY AND NETWORK SECURITY
 
Encryption
EncryptionEncryption
Encryption
 
Ipsec
IpsecIpsec
Ipsec
 
Overview of cryptography
Overview of cryptographyOverview of cryptography
Overview of cryptography
 
Basic Cryptography unit 4 CSS
Basic Cryptography unit 4 CSSBasic Cryptography unit 4 CSS
Basic Cryptography unit 4 CSS
 
SSL/TLS Introduction with Practical Examples Including Wireshark Captures
SSL/TLS Introduction with Practical Examples Including Wireshark CapturesSSL/TLS Introduction with Practical Examples Including Wireshark Captures
SSL/TLS Introduction with Practical Examples Including Wireshark Captures
 
IPSec and VPN
IPSec and VPNIPSec and VPN
IPSec and VPN
 
Advanced Encryption Standard (AES) Implementaion using Java
Advanced Encryption Standard (AES) Implementaion using JavaAdvanced Encryption Standard (AES) Implementaion using Java
Advanced Encryption Standard (AES) Implementaion using Java
 
Ssl (Secure Sockets Layer)
Ssl (Secure Sockets Layer)Ssl (Secure Sockets Layer)
Ssl (Secure Sockets Layer)
 
IP Sec - Basic Concepts
IP Sec - Basic ConceptsIP Sec - Basic Concepts
IP Sec - Basic Concepts
 

Similar a Vtu network security(10 ec832) unit 5 notes.

Network Security_Module_2.pdf
Network Security_Module_2.pdfNetwork Security_Module_2.pdf
Network Security_Module_2.pdfDr. Shivashankar
 
SSL Secure socket layer
SSL Secure socket layerSSL Secure socket layer
SSL Secure socket layerAhmed Elnaggar
 
Vulnerabilities of the SSL/TLS Protocol
Vulnerabilities of the SSL/TLS ProtocolVulnerabilities of the SSL/TLS Protocol
Vulnerabilities of the SSL/TLS Protocolcsandit
 
VULNERABILITIES OF THE SSL/TLS PROTOCOL
VULNERABILITIES OF THE SSL/TLS PROTOCOLVULNERABILITIES OF THE SSL/TLS PROTOCOL
VULNERABILITIES OF THE SSL/TLS PROTOCOLcscpconf
 
Improving the Secure Socket Layer by Modifying the RSA Algorithm
Improving the Secure Socket Layer by Modifying the RSA AlgorithmImproving the Secure Socket Layer by Modifying the RSA Algorithm
Improving the Secure Socket Layer by Modifying the RSA AlgorithmIJCSEA Journal
 
Developed security and privacy algorithms for cyber physical system
Developed security and privacy algorithms for cyber physical system Developed security and privacy algorithms for cyber physical system
Developed security and privacy algorithms for cyber physical system IJECEIAES
 
Network Security_Module_2_Dr Shivashankar
Network Security_Module_2_Dr ShivashankarNetwork Security_Module_2_Dr Shivashankar
Network Security_Module_2_Dr ShivashankarDr. Shivashankar
 
Communications Technologies
Communications TechnologiesCommunications Technologies
Communications TechnologiesSarah Jimenez
 
Welcome to International Journal of Engineering Research and Development (IJERD)
Welcome to International Journal of Engineering Research and Development (IJERD)Welcome to International Journal of Engineering Research and Development (IJERD)
Welcome to International Journal of Engineering Research and Development (IJERD)IJERD Editor
 
TAM new report
TAM new reportTAM new report
TAM new reportSuzit Punk
 
Analysis Of Internet Protocol ( IP ) Datagrams
Analysis Of Internet Protocol ( IP ) DatagramsAnalysis Of Internet Protocol ( IP ) Datagrams
Analysis Of Internet Protocol ( IP ) DatagramsEmily Jones
 
An authenticated key management scheme for securing big data environment
An authenticated key management scheme for securing big data  environmentAn authenticated key management scheme for securing big data  environment
An authenticated key management scheme for securing big data environmentIJECEIAES
 
Secure Sockets Layer (SSL)
Secure Sockets Layer (SSL)Secure Sockets Layer (SSL)
Secure Sockets Layer (SSL)BGSBU Rajouri
 

Similar a Vtu network security(10 ec832) unit 5 notes. (20)

Unit 6
Unit 6Unit 6
Unit 6
 
Network Security_Module_2.pdf
Network Security_Module_2.pdfNetwork Security_Module_2.pdf
Network Security_Module_2.pdf
 
SSL Secure socket layer
SSL Secure socket layerSSL Secure socket layer
SSL Secure socket layer
 
Vulnerabilities of the SSL/TLS Protocol
Vulnerabilities of the SSL/TLS ProtocolVulnerabilities of the SSL/TLS Protocol
Vulnerabilities of the SSL/TLS Protocol
 
VULNERABILITIES OF THE SSL/TLS PROTOCOL
VULNERABILITIES OF THE SSL/TLS PROTOCOLVULNERABILITIES OF THE SSL/TLS PROTOCOL
VULNERABILITIES OF THE SSL/TLS PROTOCOL
 
Improving the Secure Socket Layer by Modifying the RSA Algorithm
Improving the Secure Socket Layer by Modifying the RSA AlgorithmImproving the Secure Socket Layer by Modifying the RSA Algorithm
Improving the Secure Socket Layer by Modifying the RSA Algorithm
 
Web Security
Web SecurityWeb Security
Web Security
 
Developed security and privacy algorithms for cyber physical system
Developed security and privacy algorithms for cyber physical system Developed security and privacy algorithms for cyber physical system
Developed security and privacy algorithms for cyber physical system
 
Ssl and tls
Ssl and tlsSsl and tls
Ssl and tls
 
Wireless networks security
Wireless networks securityWireless networks security
Wireless networks security
 
Network Security_Module_2_Dr Shivashankar
Network Security_Module_2_Dr ShivashankarNetwork Security_Module_2_Dr Shivashankar
Network Security_Module_2_Dr Shivashankar
 
Communications Technologies
Communications TechnologiesCommunications Technologies
Communications Technologies
 
Lec 2.pptx
Lec 2.pptxLec 2.pptx
Lec 2.pptx
 
Welcome to International Journal of Engineering Research and Development (IJERD)
Welcome to International Journal of Engineering Research and Development (IJERD)Welcome to International Journal of Engineering Research and Development (IJERD)
Welcome to International Journal of Engineering Research and Development (IJERD)
 
Transport Layer Security
Transport Layer SecurityTransport Layer Security
Transport Layer Security
 
Ecommerce final ppt
Ecommerce final pptEcommerce final ppt
Ecommerce final ppt
 
TAM new report
TAM new reportTAM new report
TAM new report
 
Analysis Of Internet Protocol ( IP ) Datagrams
Analysis Of Internet Protocol ( IP ) DatagramsAnalysis Of Internet Protocol ( IP ) Datagrams
Analysis Of Internet Protocol ( IP ) Datagrams
 
An authenticated key management scheme for securing big data environment
An authenticated key management scheme for securing big data  environmentAn authenticated key management scheme for securing big data  environment
An authenticated key management scheme for securing big data environment
 
Secure Sockets Layer (SSL)
Secure Sockets Layer (SSL)Secure Sockets Layer (SSL)
Secure Sockets Layer (SSL)
 

Más de Jayanth Dwijesh H P

VTU Network & cyber security (1-5 Module) Full notes
VTU Network & cyber security (1-5 Module) Full notesVTU Network & cyber security (1-5 Module) Full notes
VTU Network & cyber security (1-5 Module) Full notesJayanth Dwijesh H P
 
Vtu network security(10 ec832) unit 3 notes.
Vtu network security(10 ec832) unit 3 notes.Vtu network security(10 ec832) unit 3 notes.
Vtu network security(10 ec832) unit 3 notes.Jayanth Dwijesh H P
 
VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-5 notes(15...
VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-5 notes(15...VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-5 notes(15...
VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-5 notes(15...Jayanth Dwijesh H P
 
VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-4 notes(15...
VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-4 notes(15...VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-4 notes(15...
VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-4 notes(15...Jayanth Dwijesh H P
 
VTU E&C,TCE CBCS[NEW]5th Sem Information Theory and Coding Module-3 notes(15&...
VTU E&C,TCE CBCS[NEW]5th Sem Information Theory and Coding Module-3 notes(15&...VTU E&C,TCE CBCS[NEW]5th Sem Information Theory and Coding Module-3 notes(15&...
VTU E&C,TCE CBCS[NEW]5th Sem Information Theory and Coding Module-3 notes(15&...Jayanth Dwijesh H P
 
VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-2 notes(15...
VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-2 notes(15...VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-2 notes(15...
VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-2 notes(15...Jayanth Dwijesh H P
 
VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-1 notes(15...
VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-1 notes(15...VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-1 notes(15...
VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-1 notes(15...Jayanth Dwijesh H P
 
Network security 10EC832 vtu notes
Network security 10EC832 vtu notesNetwork security 10EC832 vtu notes
Network security 10EC832 vtu notesJayanth Dwijesh H P
 
VTU network security(10 ec832) unit 6 notes
VTU network security(10 ec832) unit 6 notesVTU network security(10 ec832) unit 6 notes
VTU network security(10 ec832) unit 6 notesJayanth Dwijesh H P
 
Vtu network security(10 ec832) unit 2 notes..
Vtu network security(10 ec832) unit 2 notes..Vtu network security(10 ec832) unit 2 notes..
Vtu network security(10 ec832) unit 2 notes..Jayanth Dwijesh H P
 
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -1notes
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -1notesVTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -1notes
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -1notesJayanth Dwijesh H P
 
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -5 notes
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -5 notesVTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -5 notes
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -5 notesJayanth Dwijesh H P
 
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -3 notes
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -3 notesVTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -3 notes
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -3 notesJayanth Dwijesh H P
 
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -4 notes
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -4 notesVTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -4 notes
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -4 notesJayanth Dwijesh H P
 
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -2notes
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -2notesVTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -2notes
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -2notesJayanth Dwijesh H P
 

Más de Jayanth Dwijesh H P (15)

VTU Network & cyber security (1-5 Module) Full notes
VTU Network & cyber security (1-5 Module) Full notesVTU Network & cyber security (1-5 Module) Full notes
VTU Network & cyber security (1-5 Module) Full notes
 
Vtu network security(10 ec832) unit 3 notes.
Vtu network security(10 ec832) unit 3 notes.Vtu network security(10 ec832) unit 3 notes.
Vtu network security(10 ec832) unit 3 notes.
 
VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-5 notes(15...
VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-5 notes(15...VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-5 notes(15...
VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-5 notes(15...
 
VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-4 notes(15...
VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-4 notes(15...VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-4 notes(15...
VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-4 notes(15...
 
VTU E&C,TCE CBCS[NEW]5th Sem Information Theory and Coding Module-3 notes(15&...
VTU E&C,TCE CBCS[NEW]5th Sem Information Theory and Coding Module-3 notes(15&...VTU E&C,TCE CBCS[NEW]5th Sem Information Theory and Coding Module-3 notes(15&...
VTU E&C,TCE CBCS[NEW]5th Sem Information Theory and Coding Module-3 notes(15&...
 
VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-2 notes(15...
VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-2 notes(15...VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-2 notes(15...
VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-2 notes(15...
 
VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-1 notes(15...
VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-1 notes(15...VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-1 notes(15...
VTU E&C,TCE CBCS[NEW] 5th Sem Information Theory and Coding Module-1 notes(15...
 
Network security 10EC832 vtu notes
Network security 10EC832 vtu notesNetwork security 10EC832 vtu notes
Network security 10EC832 vtu notes
 
VTU network security(10 ec832) unit 6 notes
VTU network security(10 ec832) unit 6 notesVTU network security(10 ec832) unit 6 notes
VTU network security(10 ec832) unit 6 notes
 
Vtu network security(10 ec832) unit 2 notes..
Vtu network security(10 ec832) unit 2 notes..Vtu network security(10 ec832) unit 2 notes..
Vtu network security(10 ec832) unit 2 notes..
 
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -1notes
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -1notesVTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -1notes
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -1notes
 
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -5 notes
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -5 notesVTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -5 notes
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -5 notes
 
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -3 notes
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -3 notesVTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -3 notes
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -3 notes
 
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -4 notes
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -4 notesVTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -4 notes
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -4 notes
 
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -2notes
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -2notesVTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -2notes
VTU CBCS E&C 5th sem Information theory and coding(15EC54) Module -2notes
 

Último

Oracle_PLSQL_basic_tutorial_with_workon_Exercises.ppt
Oracle_PLSQL_basic_tutorial_with_workon_Exercises.pptOracle_PLSQL_basic_tutorial_with_workon_Exercises.ppt
Oracle_PLSQL_basic_tutorial_with_workon_Exercises.pptDheerajKashnyal
 
A Seminar on Electric Vehicle Software Simulation
A Seminar on Electric Vehicle Software SimulationA Seminar on Electric Vehicle Software Simulation
A Seminar on Electric Vehicle Software SimulationMohsinKhanA
 
GENERAL CONDITIONS FOR CONTRACTS OF CIVIL ENGINEERING WORKS
GENERAL CONDITIONS  FOR  CONTRACTS OF CIVIL ENGINEERING WORKS GENERAL CONDITIONS  FOR  CONTRACTS OF CIVIL ENGINEERING WORKS
GENERAL CONDITIONS FOR CONTRACTS OF CIVIL ENGINEERING WORKS Bahzad5
 
Power System electrical and electronics .pptx
Power System electrical and electronics .pptxPower System electrical and electronics .pptx
Power System electrical and electronics .pptxMUKULKUMAR210
 
Introduction to Machine Learning Unit-3 for II MECH
Introduction to Machine Learning Unit-3 for II MECHIntroduction to Machine Learning Unit-3 for II MECH
Introduction to Machine Learning Unit-3 for II MECHC Sai Kiran
 
Technical Management of cement industry.pdf
Technical Management of cement industry.pdfTechnical Management of cement industry.pdf
Technical Management of cement industry.pdfMadan Karki
 
Lecture 1: Basics of trigonometry (surveying)
Lecture 1: Basics of trigonometry (surveying)Lecture 1: Basics of trigonometry (surveying)
Lecture 1: Basics of trigonometry (surveying)Bahzad5
 
Gender Bias in Engineer, Honors 203 Project
Gender Bias in Engineer, Honors 203 ProjectGender Bias in Engineer, Honors 203 Project
Gender Bias in Engineer, Honors 203 Projectreemakb03
 
Vertical- Machining - Center - VMC -LMW-Machine-Tool-Division.pptx
Vertical- Machining - Center - VMC -LMW-Machine-Tool-Division.pptxVertical- Machining - Center - VMC -LMW-Machine-Tool-Division.pptx
Vertical- Machining - Center - VMC -LMW-Machine-Tool-Division.pptxLMW Machine Tool Division
 
nvidia AI-gtc 2024 partial slide deck.pptx
nvidia AI-gtc 2024 partial slide deck.pptxnvidia AI-gtc 2024 partial slide deck.pptx
nvidia AI-gtc 2024 partial slide deck.pptxjasonsedano2
 
Engineering Mechanics Chapter 5 Equilibrium of a Rigid Body
Engineering Mechanics  Chapter 5  Equilibrium of a Rigid BodyEngineering Mechanics  Chapter 5  Equilibrium of a Rigid Body
Engineering Mechanics Chapter 5 Equilibrium of a Rigid BodyAhmadHajasad2
 
cme397 surface engineering unit 5 part A questions and answers
cme397 surface engineering unit 5 part A questions and answerscme397 surface engineering unit 5 part A questions and answers
cme397 surface engineering unit 5 part A questions and answerskarthi keyan
 
Modelling Guide for Timber Structures - FPInnovations
Modelling Guide for Timber Structures - FPInnovationsModelling Guide for Timber Structures - FPInnovations
Modelling Guide for Timber Structures - FPInnovationsYusuf Yıldız
 
Technology Features of Apollo HDD Machine, Its Technical Specification with C...
Technology Features of Apollo HDD Machine, Its Technical Specification with C...Technology Features of Apollo HDD Machine, Its Technical Specification with C...
Technology Features of Apollo HDD Machine, Its Technical Specification with C...Apollo Techno Industries Pvt Ltd
 
me3493 manufacturing technology unit 1 Part A
me3493 manufacturing technology unit 1 Part Ame3493 manufacturing technology unit 1 Part A
me3493 manufacturing technology unit 1 Part Akarthi keyan
 
Popular-NO1 Kala Jadu Expert Specialist In Germany Kala Jadu Expert Specialis...
Popular-NO1 Kala Jadu Expert Specialist In Germany Kala Jadu Expert Specialis...Popular-NO1 Kala Jadu Expert Specialist In Germany Kala Jadu Expert Specialis...
Popular-NO1 Kala Jadu Expert Specialist In Germany Kala Jadu Expert Specialis...Amil baba
 
sdfsadopkjpiosufoiasdoifjasldkjfl a asldkjflaskdjflkjsdsdf
sdfsadopkjpiosufoiasdoifjasldkjfl a asldkjflaskdjflkjsdsdfsdfsadopkjpiosufoiasdoifjasldkjfl a asldkjflaskdjflkjsdsdf
sdfsadopkjpiosufoiasdoifjasldkjfl a asldkjflaskdjflkjsdsdfJulia Kaye
 
Phase noise transfer functions.pptx
Phase noise transfer      functions.pptxPhase noise transfer      functions.pptx
Phase noise transfer functions.pptxSaiGouthamSunkara
 

Último (20)

Oracle_PLSQL_basic_tutorial_with_workon_Exercises.ppt
Oracle_PLSQL_basic_tutorial_with_workon_Exercises.pptOracle_PLSQL_basic_tutorial_with_workon_Exercises.ppt
Oracle_PLSQL_basic_tutorial_with_workon_Exercises.ppt
 
A Seminar on Electric Vehicle Software Simulation
A Seminar on Electric Vehicle Software SimulationA Seminar on Electric Vehicle Software Simulation
A Seminar on Electric Vehicle Software Simulation
 
計劃趕得上變化
計劃趕得上變化計劃趕得上變化
計劃趕得上變化
 
GENERAL CONDITIONS FOR CONTRACTS OF CIVIL ENGINEERING WORKS
GENERAL CONDITIONS  FOR  CONTRACTS OF CIVIL ENGINEERING WORKS GENERAL CONDITIONS  FOR  CONTRACTS OF CIVIL ENGINEERING WORKS
GENERAL CONDITIONS FOR CONTRACTS OF CIVIL ENGINEERING WORKS
 
Power System electrical and electronics .pptx
Power System electrical and electronics .pptxPower System electrical and electronics .pptx
Power System electrical and electronics .pptx
 
Présentation IIRB 2024 Marine Cordonnier.pdf
Présentation IIRB 2024 Marine Cordonnier.pdfPrésentation IIRB 2024 Marine Cordonnier.pdf
Présentation IIRB 2024 Marine Cordonnier.pdf
 
Introduction to Machine Learning Unit-3 for II MECH
Introduction to Machine Learning Unit-3 for II MECHIntroduction to Machine Learning Unit-3 for II MECH
Introduction to Machine Learning Unit-3 for II MECH
 
Technical Management of cement industry.pdf
Technical Management of cement industry.pdfTechnical Management of cement industry.pdf
Technical Management of cement industry.pdf
 
Lecture 1: Basics of trigonometry (surveying)
Lecture 1: Basics of trigonometry (surveying)Lecture 1: Basics of trigonometry (surveying)
Lecture 1: Basics of trigonometry (surveying)
 
Gender Bias in Engineer, Honors 203 Project
Gender Bias in Engineer, Honors 203 ProjectGender Bias in Engineer, Honors 203 Project
Gender Bias in Engineer, Honors 203 Project
 
Vertical- Machining - Center - VMC -LMW-Machine-Tool-Division.pptx
Vertical- Machining - Center - VMC -LMW-Machine-Tool-Division.pptxVertical- Machining - Center - VMC -LMW-Machine-Tool-Division.pptx
Vertical- Machining - Center - VMC -LMW-Machine-Tool-Division.pptx
 
nvidia AI-gtc 2024 partial slide deck.pptx
nvidia AI-gtc 2024 partial slide deck.pptxnvidia AI-gtc 2024 partial slide deck.pptx
nvidia AI-gtc 2024 partial slide deck.pptx
 
Engineering Mechanics Chapter 5 Equilibrium of a Rigid Body
Engineering Mechanics  Chapter 5  Equilibrium of a Rigid BodyEngineering Mechanics  Chapter 5  Equilibrium of a Rigid Body
Engineering Mechanics Chapter 5 Equilibrium of a Rigid Body
 
cme397 surface engineering unit 5 part A questions and answers
cme397 surface engineering unit 5 part A questions and answerscme397 surface engineering unit 5 part A questions and answers
cme397 surface engineering unit 5 part A questions and answers
 
Modelling Guide for Timber Structures - FPInnovations
Modelling Guide for Timber Structures - FPInnovationsModelling Guide for Timber Structures - FPInnovations
Modelling Guide for Timber Structures - FPInnovations
 
Technology Features of Apollo HDD Machine, Its Technical Specification with C...
Technology Features of Apollo HDD Machine, Its Technical Specification with C...Technology Features of Apollo HDD Machine, Its Technical Specification with C...
Technology Features of Apollo HDD Machine, Its Technical Specification with C...
 
me3493 manufacturing technology unit 1 Part A
me3493 manufacturing technology unit 1 Part Ame3493 manufacturing technology unit 1 Part A
me3493 manufacturing technology unit 1 Part A
 
Popular-NO1 Kala Jadu Expert Specialist In Germany Kala Jadu Expert Specialis...
Popular-NO1 Kala Jadu Expert Specialist In Germany Kala Jadu Expert Specialis...Popular-NO1 Kala Jadu Expert Specialist In Germany Kala Jadu Expert Specialis...
Popular-NO1 Kala Jadu Expert Specialist In Germany Kala Jadu Expert Specialis...
 
sdfsadopkjpiosufoiasdoifjasldkjfl a asldkjflaskdjflkjsdsdf
sdfsadopkjpiosufoiasdoifjasldkjfl a asldkjflaskdjflkjsdsdfsdfsadopkjpiosufoiasdoifjasldkjfl a asldkjflaskdjflkjsdsdf
sdfsadopkjpiosufoiasdoifjasldkjfl a asldkjflaskdjflkjsdsdf
 
Phase noise transfer functions.pptx
Phase noise transfer      functions.pptxPhase noise transfer      functions.pptx
Phase noise transfer functions.pptx
 

Vtu network security(10 ec832) unit 5 notes.

  • 1. NETWORK SECURITY (10EC832) 8th SEM E&C JAYANTHDWIJESH H P M.tech (DECS) Assistant Professor – Dept of E&CE B.G.S INSTITUTE OF TECHNOLOGY (B.G.S.I.T) B.G Nagara, Nagamangala Tq, Mandya District- 571448
  • 2. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 1 NETWORK SECURITY PART-B UNIT-5 UNIT - 5 Web Security Consideration, Security socket layer (SSL) and Transport layer security, Secure Electronic Transaction. TEXT BOOK: 1. Cryptography and Network Security, William Stalling, Pearson Education, 2003. REFERENCE BOOKS: 1. Cryptography and Network Security, Behrouz A. Forouzan, TMH, 2007. 2. Cryptography and Network Security, Atul Kahate, TMH, 2003.
  • 3. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 2 PART – B UNIT - 5 Web Security Consideration, Security socket layer (SSL) and Transport layer security, Secure Electronic Transaction. 1. WEB SECURITY CONSIDERATION The World Wide Web is fundamentally a client/server application running over the Internet and TCP/IP intranets. The web provides the following Web Security Threats which make web security a must:  The Internet is two way. Even unimportant systems like electronic publishing systems, voice response, or fax-back are vulnerable to attacks on the Web servers over the Internet.  The Web is increasingly serving as a platform for corporate and product information and as the platform for business transactions. Reputations can be damaged and money can be lost if the Web servers are subverted.  Although Web browsers, web servers are very easy to use and manage and web content is easy to develop, the underlying software is extraordinarily complex. This complex software may hide many potential security flaws and hence is more vulnerable to a variety of security attacks.  A Web server can be exploited as a launching pad into the corporation’s or agency’s entire computer complex. 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’ common clients for Web-based services. Such users are not always aware of the security risks. 1.1 WEB SECURITY THREATS JUNE/JULY-2013[8M] Table 1 provides a summary of the types of security threats faced when using the Web. One way to group these threats is in terms of passive and active attacks. Passive attacks include eavesdropping on network traffic between browser and server and gaining access to information on a Web site that is supposed to be restricted.
  • 4. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 3 Active attacks include impersonating another user, altering messages in transit between client and server, and altering information on a Web site. Another way to classify Web security threats is in terms of the location of the threat: Web server, Web browser, and network traffic between browser and server. Table 1 A Comparison of Threats on the Web 1.2 WEB TRAFFIC SECURITY APPROACHES Figure 1 Relative Location of Security Facilities in the TCP/IP Protocol Stack  Figure illustrates that one way to provide Web security is to use IP security (IPsec) (Figure 1 (a)).  The advantage of using IPsec is that it is transparent to end users and applications and provides a general purpose solution.
  • 5. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 4  Furthermore, IPsec includes a filtering capability so that only selected traffic need incur the overhead of IPsec processing.  Another relatively general-purpose solution is to implement security just above TCP (Figure 1 (B)).  The foremost example of this approaches the Secure Sockets Layer (SSL) and the follow-on Internet standard known as Transport Layer Security (TLS).  At this level, there are two implementation choices.  For full generality, SSL (or TLS) could provide as part of the underlying protocol suite and therefore be transparent to applications.  Alternatively, SSL can embed in specific packages.  For example, Netscape and Microsoft Explorer browsers come equipped with SSL, and most Web servers have implemented the protocol.  Application-specific security services embedded within the particular application.  The figure shows (Figure 1 (C)). Examples of this architecture.  The advantage of this approach is that the service can tailor to the specific needs of a given application 2. SECURE SOCKET LAYER 2.1 SSL ARCHITECTURE MAY/JUNE-2010 [10M], JUN/JULY-2011 [10M], DEC-2011[4M], DEC-2012[10M], JUNE/JULY-2013[8M], DEC/JAN-2016[10M] Figure 2 SSL Protocol Stack  Secure Socket Layer is designed to make use of TCP to provide a reliable end-to-end secure service.  Moreover, Secure Socket Layer is not a single protocol but rather two layers of protocols, as illustrated in Figure (2) below.
  • 6. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 5  The SSL Record Protocol provides basic security services to various higher layer protocols.  In particular, the Hypertext Transfer Protocol (HTTP), which 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. Two important SSL concepts are the SSL session and the SSL connection, which are defined in the specification as follows. DEC-2012[4M]  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 associated with one session.  Session: An SSL session is an association between a client and a server. Sessions are created by the Handshake Protocol. Sessions define a set of cryptographic security parameters which can be shared among multiple connections. Sessions are used to avoid the expensive negotiation of new security parameters for each connection.  There a number of states associated with each session. Once a session established, there is a current operating state for both read and write (i.e., receive and send)  In addition, during the Handshake Protocol, pending read and writes states created. Upon successful conclusion of the Handshake Protocol, the pending states become the current states A session state is defined by the following parameters MAY/JUNE-2010 [10M], JUN/JULY- 2011[10M]  Session identifier: An arbitrary byte sequence chosen by the server to identify an active or resumable session state.  Peer certificate: An X509.v3 certificate of the peer. This element of the state may be null.  Compression method: The algorithm used to compress data prior to encryption.  Cipher spec: Specifies the bulk data encryption algorithm (such as null, AES, etc.) and a hash algorithm (such as MD5 or SHA-1) used for MAC calculation. It also defines cryptographic attributes such as the hash size.
  • 7. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 6  Master secret: 48-byte secret shared between the client and the server.  Is resumable: A flag indicating whether the session can be used to initiate new connections. A connection state is defined by the following parameters. MAY/JUNE-2010 [10M], JUN/JULY-2011[10M]  Server and client random: Byte sequences that are chosen by the server and client for each connection.  Server write MAC secret: The secret key used in MAC operations on data sent by the server.  Client write MAC secret: The secret key used in MAC operations on data sent by the client.  Server write key: The secret encryption key for data encrypted by the server and decrypted by the client.  Client write key: The symmetric encryption key for data encrypted by the client and decrypted by the server.  Initialization vectors: When a block cipher in CBC mode is used, an initialization vector (IV) is maintained for each key. This field is first initialized by the SSL Handshake Protocol.  Sequence numbers: Each party maintains separate sequence numbers for transmitted and received messages for each connection. When a party sends or receives a change cipher spec message, the appropriate sequence number is set to zero. Sequence numbers may not exceed 264 - 1. 2.2 SSL RECORD PROTOCOL: SSL PROTOCOL JUN/JULY-2017[10M], JUNE- 2012[10M]  The SSL Record Protocol provides two services for SSL connections: Confidentiality and Message Integrity.  Moreover, the overall operation of Record Protocol is:  Fragmentation: Each upper-layer message fragmented into blocks of 214 bytes (16384 bytes) or less.  Compression: Compression is optionally applied. Compression must be lossless and may not increase the content length by more than 1024 bytes.
  • 8. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 7 Figure 3 SSL Record Protocol Operation  Add message authentication code: MAC calculated over the compressed data by the following expression. Hash (MAC_write_secret  pad_2  hash (MAC_write_secret  pad_1  seq _ num  SSL Compressed. type  SSL Compressed. length  SSL Compressed. fragment)) Where || = concatenation. MAC_write_secret = shared secret key. Hash = cryptographic hash algorithm. pad_1 = the byte 0x36 (0011 0110) repeated 48 times (384 bits) for MD5 and 40 times (320 Bits) for SHA-1. pad_2 = the byte 0x5C (0101 1100) repeated 48 Times for MD5 and 40 times for SHA-1. seq _ num = the sequence number for this message. SSL Compressed .type = the higher-level protocol used to process this fragment. SSL Compressed. Length = the length of the compressed fragment. SSL Compressed. Fragment = the compressed fragment or plain text (if compression =not used).
  • 9. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 8  Encryption: The compressed message plus the MAC encrypted using symmetric encryption. Algorithms supported are AES, RC4-40, IDEA, RC2, DES, 3DES and Fortezza.  The final step of SSL Record Protocol processing is to prepare a header consisting of the following fields:  Content Type (8 bits): The higher-layer protocol used to process the fragment.  Major Version (8 bits): Indicates major version of SSL in use. For SSLv3, the value is 3.  Minor Version (8 bits): Indicates minor version in use. For SSLv3, the value is 0.  Compressed Length (16 bits): The length in bytes of the fragment.  Figure 4 illustrates the SSL record format. Figure 4 SSL Record Format 2.3 CHANGE CIPHER SPEC PROTOCOL 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 5(a)) of a single byte with the value 1. The purpose of this message to cause the pending state to be copied into the current state, which updates the cipher suite to be used on this connection.
  • 10. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 9 Figure 5 SSL Record Protocol Payload 2.4 Alert Protocol  The Alert Protocol used to convey SSL-related alerts to the peer entity.  Moreover, each message in this protocol consists of two bytes (Figure 5(b)).  The first byte takes the value warning (1) or fatal (2) to convey the severity of the message.  If the level is fatal, SSL immediately terminates the connection.  Other connections on the same session may continue, but no new connections established.  The second byte contains a code that indicates the specific alert.  First, we list those alerts that are always fatal (definitions from the SSL specification):  Unexpected message: An inappropriate message was received.  Bad _ record _ mac: An incorrect MAC was received.  Decompression _ failure: The decompression function received improper input (e.g., unable to decompress or decompress to greater than maximum allowable length).  Handshake _ failure: Sender was unable to negotiate an acceptable set of security parameters given the options available.  Illegal _ parameter: A field in a handshake message was out of range or inconsistent with other fields.  The remaining alerts are the following.  Close _ notify: Notifies the recipient that the sender will not send any more messages on this connection. Each party is required to send a close _ notify alert before closing the write side of a connection.  No_ certificate: May be sent in response to a certificate request if no appropriate certificate is available.
  • 11. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 10  Bad _ certificate: A received certificate was corrupt (e.g., contained a signature that did not verify).  Unsupported _ certificate: The type of the received certificate is not supported.  Certificate _ revoked: A certificate has been revoked by its signer.  Certificate _ expired: A certificate has expired.  Certificate _ unknown: Some other unspecified issue arose in processing the certificate, rendering it unacceptable. 2.5 Handshake Protocol DEC-2010 [12M], DEC-2011[8M], JAN-2015[10M] Table 2 SSL Handshake Protocol Message Types This Handshake Protocol allows the server and client to authenticate each other and to negotiate an encryption and MAC algorithm and cryptographic keys. Moreover, The Handshake Protocol is used before any application data is transmitted. A handshake message has the following format: 1. Type (1 byte): Indicates one of 10 messages of handshake protocol. Table 2 lists the defined message types 2. Length (3 bytes): The length of the message in bytes. 3. Content (bytes): The parameters associated with this message.
  • 12. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 11 Similarly, the algorithm has four phases Phase 1. 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 with the following parameters:  Version: The highest SSL version understood by the client.  Random: A client-generated random number which serves as the nonce.  Session ID: A variable-length session identifier. A nonzero value indicates that the client wishes to update the parameters of an existing session. A zero value indicates that the client wishes to establish a new connection on a new session.  Cipher Suite: This is a list that contains the cryptographic algorithms (key exchange, encryption, and MAC) supported by the client, in decreasing order of preference.  Compression Method: This is a list of the compression methods the client supports.  After sending the client _ hello message, the client waits for the server _ hello message, which contains the same parameters as the client _ hello message. The parameters contain the values which client had sent to the server and the server has chosen to use. Phase 2: Server Authentication and Key Exchange: This phase provides authentication of the server to the client. o The server sends its certificate (one or more) if it needs to be authenticated.  The server sends a server _ key _ exchange message which contains the list of secret keys to be used for the subsequent data. The certificate _ request message is sent next which includes two parameters: certificate _ type and certificate _ authorities.  Moreover, the final message in phase 2, and one that always required is the server _ done message, which sent by the server to indicate the end of the server hello and associated messages.  After sending this message, the server will wait for a client response. This message has no parameters.
  • 13. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 12 Figure 6 Handshake Protocol Action Phase 3. Client Authentication and Key Exchange: This phase provides client authentication to the server.  The client verifies the server certificates and checks whether the server _ hello parameters are acceptable.  Moreover, if all is satisfactory, the client sends a certificate message if the server has requested a certificate. If no suitable certificate is available, the client sends a no _ certificate alert.
  • 14. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 13  Next is the client _ key _ exchange message which has the same parameters as the server _key _ exchange message.  Similarly, the client may send a certificate _ verify message to provide explicit verification of a client certificate. The client encrypts all the previous messages and master secret with its private key. Phase 4. Finish This phase completes the setting up of a secure connection.  The client sends a change _ Cipher _ spec message and copies the pending Cipher Spec into the current Cipher Spec.  Moreover, The client then immediately sends the finished  The server sends its own change _ cipher _ spec message, transfers the pending to the current Cipher Spec, and sends it finished  At this point, the handshake is complete and the client and server may begin to exchange application-layer data. 3. TRANSPORT LAYER SECURITY (TLS)  TLS is an IETF standardization initiative whose goal is to produce an Internet standard version of SSL.  Moreover, TLS is defined as a Proposed Internet Standard in RFC 5246. Which is very similar to SSLv3.  We highlight the differences. Version Number  The one difference is in version values. For the current version of TLS, the major version is 3 and the minor version is 3. Message Authentication Code: Transport Layer Security  There are two differences between the SSLv3 and TLS MAC schemes:  The actual algorithm and the scope of the MAC calculation.  TLS makes use of the HMAC algorithm defined in RFC 2104.
  • 15. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 14  HMAC is defined as where H = embedded hash function (for TLS, either MD5 or SHA-1) 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 (for MD5 and SHA-1, block length = 512 bits) Ipad = 00110110 (36 in hexadecimal) repeated 64 times (512 bits) opad = 01011100 (5C in hexadecimal) repeated 64 times (512 bits)  SSLv3 uses the same algorithm, except that the padding bytes are concatenated with the secret key rather than being XORed with the secret key padded to the block length.  Moreover, The level of security should be about the same in both cases.  For TLS, the MAC calculation encompasses the fields indicated in the following expression: MAC(MAC_write_secret,seq_num || TLSCompressed.type || TLSCompressed.version || TLSCompressed.length || TLSCompressed.fragment)  The MAC calculation covers all of the fields covered by the SSLv3 calculation, plus the field version, which is the version of the protocol being employed. 3.1 PSEUDORANDOM FUNCTION:  TLS makes use of a pseudorandom function referred to as PRF to expand secrets into blocks of data for purposes of key generation or validation.  Moreover, the objective is to make use of a relatively small shared secret value but to generate longer blocks of data in a way that is secure from the kinds of attacks made on hash functions and MACs.
  • 16. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 15 Figure 7 TLS Function P _ hash (secret, seed)  The PRF is based on the data expansion function (Figure 7) given as 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) )  PRF defined as PRF (secret, label, seed) = P _ hash (S1, label || seed) PRF takes as input a secret value, an identifying label, and a seed value and produces an output of arbitrary length.
  • 17. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 16 Alert Codes: Transport Layer Security  TLS supports all of the alert codes defined in SSLv3 with the exception of no _ certificate.  A number of additional codes defined in TLS; of these, the following are always fatal.  Record _ overflow: A TLS record was received with a payload (cipher text) whose length exceeds 214 + 2048 bytes, or the cipher text decrypted to a length of greater than 214 + 1024 bytes.  Unknown _ ca: A valid certificate chain or partial chain was received, but the certificate was not accepted because the CA certificate could not be located or could not be matched with a known, trusted CA.  Access _ denied: A valid certificate was received, but when access control was applied, the sender decided not to proceed with the negotiation.  Decode _ error: A message could not be decoded, because either a field was out of its specified range or the length of the message was incorrect.  Protocol _version: The protocol version the client attempted to negotiate is recognized but not supported.  Insufficient _ security: Returned instead of handshake _ failure when a negotiation has failed specifically because the server requires ciphers more secure than those supported by the client.  Unsupported _ extension: Sent by clients that receives an extended server hello containing an extension not in the corresponding client hello.  Internal _ error: An internal error unrelated to the peer or the correctness of the protocol makes it impossible to continue.  Decrypt _ error: A handshake cryptographic operation failed, including being unable to verify a signature, decrypt a key exchange, or validate a finished message.  The remaining alerts include the following.  User _ cancelled: This handshake is being cancelled for some reason unrelated to a protocol failure.  No _ renegotiation: Sent by a client in response to a hello request or by the server in response to a client hello after initial handshaking. Either of these messages would normally result in renegotiation, but this alert indicates that the sender is not able to renegotiate. This message is always a warning.
  • 18. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 17 Cipher Suites: Moreover, 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 the exception of Fortezza. 4 SECURE ELECTRONIC TRANSACTIONS (SET) JUN/JULY-2011[10M] is an open encryption and security specification designed to protect credit card transactions on the Internet. The current version, SETv1, emerged from a call for security standards by MasterCard and Visa in February 1996. A wide range of companies were involved in developing the initial specification, including IBM, Microsoft, Netscape, RSA, Terisa, and Verisign. Beginning in 1996. SET is not itself a payment system. Rather it is a set of security protocols and formats that enables users to employ the existing credit card payment infrastructure on an open network, such as the Internet, in a secure fashion. In essence, SET provides three services:  Provides a secure communications channel among all parties involved in a transaction  Provides trust by the use of X.509v3 digital certificates  Ensures privacy because the information is only available to parties in a transaction when and where necessary. 4.1 SET Overview: A good way to begin our discussion of SET is to look at the business requirements for SET, its key features, and the participants in SET transactions.
  • 19. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 18 4.2 SET Requirements: DEC-2010 [8M], JUN/JULY-2017[10M], JUN/JULY-2011[10M], JAN - 2014 [10M] , JAN-2015[10M] The SET specification lists the following business requirements for secure payment processing with credit cards over the Internet and other networks:  Provide confidentiality of payment and ordering information: It is necessary to assure cardholders that this information is safe and accessible only to the intended recipient. Confidentiality also reduces the risk of fraud by either party to the transaction or by malicious third parties. SET uses encryption to provide confidentiality.  Ensure the integrity of all transmitted data: That is, ensure that no changes in content occur during transmission of SET messages. Digital signatures are used to provide integrity.  Provide authentication that a cardholder is a legitimate user of a credit card account: A mechanism that links a cardholder to a specific account number reduces the incidence of fraud and the overall cost of payment processing. Digital signatures and certificates are used to verify that a cardholder is a legitimate user of a valid account.  Provide authentication that a merchant can accept credit card transactions through its relationship with a financial institution: This is the complement to the preceding requirement. Cardholders need to be able to identify merchants with whom they can conduct secure transactions. Again, digital signatures and certificates are used.  Ensure the use of the best security practices and system design techniques to protect all legitimate parties in an electronic commerce transaction: SET is a well-tested specification based on highly secure cryptographic algorithms and protocols.  Create a protocol that neither depends on transport security mechanisms nor prevents their use: SET can securely operate over a "raw" TCP/IP stack. However, SET does not interfere with the use of other security mechanisms, such as IPSec and SSL/TLS.  Facilitate and encourage interoperability among software and network providers: The SET protocols and formats are independent of hardware platform, operating system, and Web software.
  • 20. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 19 4.3 Key Features of SET DEC-2012[5M], JAN -2014[10M], JAN-2015[10M], DEC/JAN-2016[5M] To meet the requirements just outlined, SET incorporates the following features:  Confidentiality of information: Cardholder account and payment information is secured as it travels across the network. An interesting and important feature of SET is that it prevents the merchant from learning the cardholder's credit card number; this is only provided to the issuing bank. Conventional encryption by DES is used to provide confidentiality.  Integrity of data: Payment information sent from cardholders to merchants includes order information, personal data, and payment instructions. SET guarantees that these message contents are not altered in transit. RSA digital signatures, using SHA-1 hash codes, provide message integrity. Certain messages are also protected by HMAC using SHA-1.  Cardholder account authentication: SET enables merchants to verify that a cardholder is a legitimate user of a valid card account number. SET uses X.509v3 digital certificates with RSA signatures for this purpose.  Merchant authentication: SET enables cardholders to verify that a merchant has a relationship with a financial institution allowing it to accept payment cards. SET uses X.509v3 digital certificates with RSA signatures for this purpose. Note that unlike IPSec and SSL/TLS, SET provides only one choice for each cryptographic algorithm. This makes sense, because SET is a single application with a single set of requirements, whereas IPSec and SSL/TLS are intended to support a range of applications.
  • 21. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 20 4.4 SET Participants JUNE-2012[10M] Fig 8: secure electronic commerce components  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 (MasterCard, Visa, and so on) that has been issued by an issuer.  Merchant: A merchant is a person or organization with goods or services to sell to the cardholder. Typically, these goods or 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, the issuer is responsible for the payment of the debt of the cardholder.  Acquirer: This is a financial institution that establishes an account with a merchant and processes payment card authorizations and payments. Merchants will usually accept more than one credit card brand but don't want to deal with multiple bankcard associations or with multiple individual issuers. The acquirer provides authorization to the merchant that a given card accounts is active and that the proposed purchase does not exceed the credit
  • 22. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 21 limit. The acquirer also provides electronic transfer of payments to the merchant's account. Subsequently, the acquirer is reimbursed by the issuer over some sort of payment network for electronic funds transfer.  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. The merchant exchanges SET messages with the payment gateway over the Internet, while the payment gateway has some direct or network connection to the acquirer's financial processing system.  Certification Authority (CA): This is an entity that is trusted to issue X.509v3 public- 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. A hierarchy of CAs is used, so that participants need not be directly certified by a root authority. 4.5 SET in Action SET is a dynamic, automated scheme that allows a customer with a credit card to order items over the Internet from merchants, in a secure fashion. A typical scenario goes like this: 1. The customer opens an account. The customer obtains a credit card account, such as MasterCard or Visa, with a bank that supports electronic payment and SET. 2. The customer receives a certificate. After suitable verification of identity, the customer receives an X.509v3 digital certificate, which is signed by the bank. The certificate verifies the customer's RSA public key and its expiration date. It also establishes a relationship, guaranteed by the bank, between the customer's key pair and his or her credit card. 3. Merchants Have Their Own Certificates. A merchant who accepts a certain brand of card must be in possession of two certificates for two public keys owned by the merchant: one for signing messages, and one for key exchange. The merchant also needs a copy of the payment gateway's public-key certificate. 4. The customer places an order. This is a process that may involve the customer first browsing through the merchant's web site to select items and determine the price. The
  • 23. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 22 customer then sends a list of the items to be purchased from the merchant, who returns an order form containing the list of items, their individual prices, a total price, and an order number. 5. The merchant is verified. In addition to the order form, the merchant sends a copy of its certificate, so that the customer can verify that he or she is dealing with a valid store. 6. The order and payment are sent. The customer sends both an order and payment information to the merchant, along with the customer's certificate. The order confirms the purchase of the items in the order form. The payment contains credit card details. The payment information is encrypted in such a way that it cannot be read by the merchant. The customer's certificate enables the merchant to verify the customer. 7. The merchant requests payment authorization. The merchant sends the payment information to the payment gateway, requesting authorization that the customer's available credit is sufficient for this purchase. 8. The merchant confirms the order. The merchant sends confirmation of the order to the customer. 9. The merchant provides the goods or service. The merchant ships the goods or provides the service to the customer. 10. The merchant requests payment. This request is sent to the payment gateway, which handles all of the payment processing.
  • 24. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 23 4.6 Dual Signature MAY/JUNE-2010[10M], DEC-2012[5M], JAN -2014[10M]  Before looking at the details of the SET protocol, let's discuss an important innovation introduced in SET: the 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 doesn't need to know the customer's credit card number, and the bank doesn't 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 services.  To see the need for the link, suppose that the customer sends the merchant two messages: a signed OI and a signed PI, and the merchant passes the PI 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 9 shows the use of a dual signature to meet this requirement. Construction of dual signature  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
  • 25. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 24  where K𝑅 𝐶 is the customer's private signature key: Fig 9: construction of dual signature  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.  Then the merchant can compute the two quantities:  where K𝑈 𝐶 is the customer's public signature key:  If these two quantities are equal, the merchant has verified the signature. Similarly, if the bank is in possession of DS, PI, the message digest for OI (OIMD), and the customer's public key, the bank can compute the following.  Again, if these two quantities are equal, the bank has verified the signature. 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.
  • 26. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 25 4.7 PAYMENT PROCESSING 1. Purchase Request DEC-2011[8M] Before the Purchase Request exchange begins, the cardholder has 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 exchange consists of four messages:  Initiate Request.  Initiate Response.  Purchase Request.  Purchase Response. The cardholder prepares the Purchase Request message figure (10) and generates a onetime symmetric encryption key, Ks. The message includes the following: a. Purchase-related information. This information will be forwarded to the payment gateway by the merchant and consists of  The PI  The dual signature, calculated over the PI and OI, signed with the customer's private signature key  The OI message digest (OIMD)  The OIMD is needed for the payment gateway to verify the dual signature. All of these items are encrypted with Ks. The final item is - The digital envelope. This is formed by encrypting Ks with the payment gateway's public key-exchange key. b. Order – related information. This information is needed by the merchant and consists of  The OI  The dual signature, calculated over the PI and OI, signed with the customer's private signature key  The PI message digest (PIMD)  The PIMD is needed for the merchant to verify the dual signature. c. Cardholder certificate. This contains the cardholders’ public signature key. It is needed by the merchant and by the payment gateway.
  • 27. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 26 When the merchant receivers the purchase request message, it performs the following actions (figure 11)  Verifies the cardholder certificates by means of its CA signatures.  Verify the dual signature using the customer’s public signature key.  Processes the order and forward the payment information to the payment gateway for authorization.  Sends a purchase response to the cardholder. Fig 10 cardholder sends purchase request
  • 28. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 27 Fig 11 merchant verifies customer purchase request 2. Payment Authorization DEC-2011[8M]  The payment authorization ensures that the transaction was approved by the issuer.  This authorization guarantees that the merchant will receive payment; the merchant can therefore provide the services or goods to the customer.  The payment authorization exchange consists of two messages; authorization request and authorization response.  The merchant sends an authorization request message to the payment gateway consisting of the following: a. Payment -related information. This information was obtained from the customer and consists of the following:  The PI  The dual signature, calculated over the PI and OI, signed with the customer's private signature key  The OI messages digest (OIMD).  The digital envelope
  • 29. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 28 b. Authorization – related information. This information is generated by the merchant and consists of  an authorization block that includes the transaction ID, signed with the mechant private signature key and encrypted with a one time symmetric key generated by the merchant  a digital envelope. This is formed by encrypting the one time key with the payment gateways public key exchange key. c. Certificate. The merchant includes the cardholder’s signature key certificate, the merchant’s signature key certificate and the merchants key exchange certificate. 3. 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
  • 30. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 29 QUESTION BANK –NETWORK SECURITY UNIT-5 MAY/JUNE-2010 1. Explain secure socket layer (SSL) protocol stack with a neat diagram and define the different parameters used in session and connection states. (10M) 2. What is need of dual signature in SET? Describe with block diagram, how they are constructed. (10M) DEC-2010 1. Briefly explain the SET requirements. (08M) 2. Explain the various phases of SSL handshake protocol. (12M) JUN/JULY-2017 1. Discuss security socket layer (SSL) record protocol in terms of fragmentation, compression and encryption. (10M) 2. Describe the sequence of events that are required for a transaction in secure electronic transaction (SET). (10M) JUNE/JULY-2011 1. Explain the two SSL concepts with their parameters. (10M) 2. Describe the sequence of events that are required for a transaction in SET. (10M) DEC-2011 1. With a diagram, explain handshake protocol action.(8M) 2. Explain in details the following transactions supported by SET: (8M) 1) Purchase request 2) payment authorization. 3. Explain SSL protocol stack. (4M) JUNE-2012 1. Discuss SSL record protocol in terms of fragmentation, compression and encryption.(10M) 2. Discuss secure electronic transaction (SET) protocol with neat diagram.(10M) DEC-2012 1. Explain SSL architecture with neat diagram. (10M) 2. What is the difference b/w SSL connection and SSL session? (04M) 3. Describe the purchase of dual signature. (05M) 4. Mention key features of SET. (05M) JUNE/JULY-2013
  • 31. NETWORK SECURITY 10EC832 Dept. of ECE, BGSIT, BG Nagara, Mandya Page 30 1. List different types of threats and consequence when using the web. Also countermeasures to be taken. (08M) 2. Elucidate SSL architecture. (08M) 3. Explain approaches to intrusion detection system. (04M) JAN -2014 1. What is the need for dual signature in SET? How are they constructed? (10M) 2. Discuss the key requirements and features of SET. (10M) JAN-2015 1. Explain the key requirements and features of secure electronic transaction. (10M) 2. Explain the various phases of SSL handshake protocol. (10M) DEC/JAN-2016 1. Explain the SSL architecture. (10M) 2. Highlight the key features of SET. (05M) 3. Explain in detail, the payment capture transaction supported by SET. (05M)