Web Security
Web Security
• Web now widely used by business,
government, individuals
• but Internet & Web are vulnerable
• have a variety of threats
– integrity
– confidentiality
– denial of service
– authentication
• need added security mechanisms
Web Security
Web Traffic Security Approaches
IPSec: The advantage of using IPSec is that it is transparent to end users and
applications and provides a general-purpose solution.
Transport Level: SSL or TLS could be provided as part of the underlying
protocol suite and therefore be transparent to applications. Alternatively, SSL
can be embedded in specific packages. (e.g. Netscape and Microsoft Explorer
browsers come equipped with SSL, and most Web servers have implemented
the protocol.)
Application-specific security: Services are embedded within the particular
application. The advantage of this approach is that the service can be tailored
to the specific needs of a given application. (e.g. SET).
Web Security
SSL (Secure Socket Layer)
• transport layer security service
• originally developed by Netscape
• version3 designed with public review & input
• subsequently became Internet standard
known as TLS (Transport Layer Security)
• uses TCP to provide a reliable end-to-end
service
• SSL has two layers of protocols
Web Security
SSL Architecture
Web Security
SSL Architecture
• SSL session
– an association between client & server
– created by the Handshake Protocol
– define a set of cryptographic parameters
– may be shared by multiple SSL connections
• SSL connection
– a transient, peer-to-peer, communications link
– associated with one SSL session
Web Security
TLS (Transport Layer Security)
• IETF standard RFC 2246 similar to SSLv3
• with minor differences
– in record format version number
– uses HMAC for MAC
– a pseudo-random function expands secrets
– has additional alert codes
– some changes in supported ciphers
– changes in certificate negotiations
– changes in use of padding
Web Security
Secure Electronic Transactions (SET)
• open encryption & security specification
• to protect Internet credit card transactions
• developed in 1996 by Mastercard, Visa etc
• not a payment system
• rather a set of security protocols & formats
– secure communications amongst parties
– trust from use of X.509v3 certificates
– privacy by restricted info to those who need it
Web Security
SET Requirements
❑ Provide confidentiality of payment and ordering information
❑ Ensure the integrity of all transmitted data
❑ Provide authentication that a cardholder is a legitimate user of a credit
card account
❑ Provide authentication that a merchant can accept credit card transactions
through its relationship with a financial institution.
❑ Ensure the use of the best security practices and system design
techniques to protect all legitimate parties in an electronic commerce
transaction
❑ Create a protocol that neither depends on transport security mechanisms
nor prevents their use
❑ Facilitate and encourage interoperability among software and network
providers.
Web Security
Key Features of SET
❑ 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.
❑ 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.
❑ Cardholder account authentication:
✓ SET enables merchants to verify that a cardholder is a legitimate user of a valid card
account number
✓ SET usesx509.v3 digital certificates with RSA signatures for this purpose
❑ Merchant authentication:
✓ SET enables cardholders to verify that a merchant has relationship with a financial
institution allowing it to accept payment cards.
Web Security
SET Components
Web Security
SET Parcipants
❑ Cardholder: In the electronic environment, consumers and corporate purchasers interact
with merchants from personal computers over the Internet. A cardholder is an
authorized holder of a payment card (e.g., MasterCard, Visa) that has been issued by
an issuer.
❑ Merchant: A merchant is a person or organization that has goods or services to sell to the
cardholder.
❑ Issuer: This is a financial institution, such as a bank, that provides the cardholder with the
payment card.
❑ Acquirer:
✓ financial institution that establishes an account with a merchant and processes
payment card authorizations and payments.
✓provides authorization to the merchant that a given card account is active and that
the proposed purchase does not exceed the credit limit.
✓acquirer also provides electronic transfer of payments to the merchant's account.
❑ Payment gateway:
✓ a function operated by the acquirer or a designated third party that processes
merchant payment messages.
✓ payment gateway interfaces between SET and the existing bankcard payment
networks for authorization and payment functions.
❑ Certification authority (CA): an entity that is trusted to issue X.509v3 public-key
certificates for cardholders, merchants, and payment gateways.
Web Security
SET Transaction
1. customer opens account
2. customer receives a certificate
3. merchants have their own certificates
4. customer places an order
5. merchant is verified
6. order and payment are sent
7. merchant requests payment authorization
8. merchant confirms order
9. merchant provides goods or service
10. merchant requests payment
Web Security
Dual Signature
• customer creates dual messages
– order information (OI) for merchant
– payment information (PI) for bank
• neither party needs details of other
• but must know they are linked
• use a dual signature for this
– signed concatenated hashes of OI & PI
Web Security
Dual 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.
Web Security
Payment Processing
SET Transaction Types (Table 17.3)
Following transactions occurs :
➢ Purchase request
➢ Payment authorization
➢ Payment capture
Web Security
Purchase Request
Purchase request exchange consists of four messages:
➢ Initiate Request
➢Initiate Response
➢ Purchase Request and
➢ Purchase Response
Initiate Request: The customer requests the certificates in the Initiate Request message, sent
to the merchant. Also contains nonce to ensure timeliness
Initiate Response: The merchant generates a response and signs it with its private
signature key. The response includes the nonce from the customer, another
nonce for the customer to return in the next message, and a transaction ID
for this purchase transaction.,merchant's signature certificate and the
payment gateway's key exchange certificate.
Web Security
Purchase Request – Customer
Web Security
Purchase Request – Merchant
Web Security
Purchase Request – Merchant
1. verifies cardholder certificates using CA signatures
2. verifies dual signature using customer's public signature key to
ensure order has not been tampered with in transit & that it was
signed using cardholder's private signature key
3. processes order and forwards the payment information to the
payment gateway for authorization (described later)
4. sends a purchase response to cardholder
➢ The Purchase Response message includes a response block
that acknowledges the order and references the corresponding
transaction number.
➢ This block is signed by the merchant using its private signature
key.
Web Security
Payment Gateway Authorization
1. verifies all certificates
2. decrypts digital envelope of authorization block to obtain
symmetric key & then decrypts authorization block
3. verifies merchant's signature on authorization block
4. decrypts digital envelope of payment block to obtain
symmetric key & then decrypts payment block
5. verifies dual signature on payment block
6. verifies that transaction ID received from merchant
matches that in PI received (indirectly) from customer
7. requests & receives an authorization from issuer
8. sends authorization response back to merchant
Web Security
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
Web Security
SSL TLS
Secure Socket Layer. Transport Layer Security.
Supports the Fortezza algorithm
Does not support the Fortezza algorithm.
(Encryption, Hashing, DSA)
Common in the 3.0 version. Common in the 1.0 version.
Message digest is used to create a IPseudo-random function is used to
master secret. create a master secret.
MAC based protocol is used. HMAC based protocol is used.
More complex than TLS. simple.
Less secured as compared to TLS. provides high security.
Highly reliable and upgraded. It provides
Less reliable and slower.
less latency.
SSL has been depreciated. TLS is still widely used.
Uses protocol to set up implicit
Uses port to set up explicit connection.
connection.