Chapter 8

WEB Security

//Modified by Prof. M. Singhal//

Henric Johnson
Blekinge Institute of Technology, Sweden
http://www.its.bth.se/staff/hjo/
henric.johnson@bth.se
Henric Johnson 1
 Outline
• Web Security Considerations
• Secure Socket Layer (SSL) and
Transport Layer Security (TLS)
• Secure Electronic Transaction (SET)
• Recommended Reading and WEB Sites

Henric Johnson 2
Web Security Considerations

• The WEB is easily accessible worldwide.

//more vulnerability//
• Complex software hide many security flaws.
• Users are not trained in computer security
and are not aware of the risks.
• A Web server can be exploited as a launching
pad into a corporation’s entire computer
complex.

Henric Johnson 3
 Web Security Approaches
1. To use IPSec: (At Network Level)
>Provides a general purpose solution.
>Transparent to end users and
applications.
>IPSEc Filtering capability: only
selected traffic need incur the
overhead of IPSec processing.
Henric Johnson 4
 Web Security Approaches
2. Implement Just above TCP:
>Provides a general purpose solution.
>Examples: SSL/TLS.
>As a part of underlying protocol suite,
it is transparent to the applications.
>SSL can also be embedded in
applications. (Explorer browsers are
equipped with SSL.)
Henric Johnson 5
 Web Security Approaches
3. Application Level:
>Security services are embedded within
an application.
>Security service can be tailored for
specific needs of an application.
>Example: Secure Electronic
Transaction (SET).
Henric Johnson 6
Security facilities in the
TCP/IP protocol stack

Henric Johnson 7
 Secure Socket Layer (SSL)
• Implements three cryptographic assurances:
1. Authentication.
2. Confidentiality.
3. Message integrity.
> Also provides secure key exchange between a
browser (client) and server.
> Provides security parameters negotiation.
> Does not offer non-repudiation.

Henric Johnson 8
 SSL...
• SSL Architecture:
>SSL runs on the top of TCP to provide
reliable and secure end-to-end service.

>Consists of two layers (shown in next

Slide).

Henric Johnson 9
SSL Architecture

Henric Johnson 10
 SSL Record Protocol
• Provides two services for SSL
connections:
1. Confidentiality:
A shared secret key used for
conventional encryption of SSL payload.
2. Message Integrity:
A shared secret key is used to construct a
message authentication code.
Henric Johnson 11
 SSL Record Protocol…
• Record protocol takes an application
message and performs the following
operations:
>Fragmentation.
>Compression
> Add a MAC (a shared secret key is used)
>Encryption (symmetric encryption)
>Appends an SSL record header.
Henric Johnson 12
SSL Record Protocol Operation

Henric Johnson 13
SSL Record Format

Henric Johnson 14
 SSL Record Header
• Content Type (8): Used by higher layers
to process the enclosed fragment.
• Major Version (8): Indicates the major
version of SSL used.
• Minor Version (8): Indicates the minor
version of SSL used.
• Compressed length (16): The length of
fragment in bytes.
Henric Johnson 15
 Handshake Protocol
• The most complex part of SSL.
• Allows the server and client to
- authenticate each other.
- negotiate encryption, MAC
algorithm and cryptographic keys.
• Used before any application data are
transmitted.
Henric Johnson 16
Handshake Protocol Action

Henric Johnson 17
 An SSL Session
1. Negotiation of cryptographic parameters
//Two computers probably don’t know each
other’s capabilities.//
2. Key Agreement.
//C & S generate shared secret key.//
3. Authentication (client authenticates server).
4. Confidentiality and integrity.
//private messages exchanged between C &
S.//
Henric Johnson 18
1. Hello and Negotiate Parameters
• Client sends server a plaintext message to
suggest some parameters for conversation:
Version:
SSL 3.1 if you can, else SSL 3.0
Key Exchange:
RSA if you can, else Diffie-Hellman
Secret Key Cipher Method:
TripleDES if you can, else DES
Message Digest:
MD5 if you can, else SHA-1
Random #: 777,666,555
Henric Johnson 19
 1. Hello and Negotiate
Parameters…
• Server responds by its choice of parameters
in a plaintext message:
Version:
SSL 3.1
Key Exchange:
RSA
Secret Key Cipher Method:
TripleDES
Message Digest:
SHA-1
Random #: 444,333,222
Henric Johnson 20
 1. Hello and Negotiate
Parameters…
• After responding to the hello message, the
server sends the client its digital
certificate.
//A trusted CA signed this certificate.//
• The client uses the trusted CA’s public key
to decrypt the certificate and obtains
server’s public key and verifies the server.

Henric Johnson 21
 2. Key Agreement and
Exchange
• The client generates
a 48-byte random DES secret DES secret
value (called pre- Key Key
master secret),
encrypts it with Secret key Secret key
server’s public RSA for message for message
key, and sends it to integrity integrity
server.
Secret key Secret key
• The server decrypts
this message and to initialize to initialize
generates six keys. the cipher. the cipher.

Henric Johnson 22
 2. Key Agreement and
Exchange…
• Generation of six shared secret keys:
<> Random values exchanged.
<> Pre-master secret.
<> Pseudo-random function generator.
Example:
PRF(pre-master secret, random1+ random2)
Computed repeatedly.

Henric Johnson 23
 3. Authentication
The client authenticates the server:
• The clients sends the server a message that is
encrypted with the generated secret keys.
//called the “finished handshake” message//
• The server responds with its own encrypted finished
handshake message.
<> The clients is now convinced that it is communicating
with right server.
//pre-master secret could only be decrypted with the
server’s private key.//

Henric Johnson 24
 3. Authentication…
Does server need to authenticate the client?
• In general yes, but in this situation it may not
be necessary:
Reasons:
1. It is not necessary because it will be done
when the client gives his/her CC number.
2. A client may not have information to
authenticate itself to the server.
3. It is time-consuming for server.

Henric Johnson 25
 4. Confidentiality and
Integrity
• Client and server use the generated secret keys
for confidential data transfer.
<> The client uses its secret key to generate a
HMAC for the message.
<> The client encrypts message data + HMAC with its
secret key and sends it to server.
<> The server decrypts the received message with
its secret key.
<> The server checks the integrity of the message
using HMAC.

Henric Johnson 26
 Transport Layer Security
(TLS)
• The same record format as the SSL record format.
• Defined in RFC 2246.
• Similar to SSLv3.
• Differences:
– version number
For current version of TLS, the major version is 3
and minor version is 1.
– message authentication code
TLS differs in actual algorithm and scope of the
MAC calculation.

Henric Johnson 27
 Transport Layer Security
(TLS)
>TLS uses HMAC algorithm.
(difference is how padding bits are used.)
>TLS also covers the field
”TLSCompressed.version” field in MAC
calculation.
– pseudorandom function
TLS makes use of a different function.
(objective is to expand secret into blocks of
data for purpose of key generation.)

Henric Johnson 28
 Transport Layer Security
(TLS)
- alert codes
>TLS does not support ”no_certificate”.
>In addition, TLS supports some additional
alerts.
– cipher suites
>TLS does not support ”Fortezza” method of
key exchange.
>TLS does not support ”Fortezza” method
of encryption.

Henric Johnson 29
 Transport Layer Security
(TLS)
- client certificate types
>TLS does not support ”Fortezza”.
– certificate_verify and finished message
>In TLS, for certificate_cerify message,
MD5 and SHA-1 hashes are calculated only
over handshake_messages.
(In SSL, hash calculation also includes the
master secret and pads.)

Henric Johnson 30
 Transport Layer Security
(TLS)
>For finished_message, the calculation of hash is
based on a different function.
- cryptographic computations
>Master secret computation in TLS uses different
computation.
(uses the same parameters as in SSL)
– Padding
>Can be of any size (<=255 bytes) so that the total
length is a multiple of cipher’s block length.

Henric Johnson 31
Secure Electronic Transactions

• An open encryption and security specification.

• Designed to protect credit card transaction on the
Internet.
• Companies involved:
– MasterCard, Visa, IBM, Microsoft, Netscape,
RSA, Terisa and Verisign
• Not a payment system.
• Set of security protocols and formats
(enables users to employ existing CC payment
infrastructure securely in an open environment).

Henric Johnson 32
 SET Services
• Provides three services:
1. Provides a secure communication
channel among all parties involved in a
transaction.
2. Provides trust by the use of X.509v3
digital certificates.
3. Ensures privacy: information is only
available to involved parties.
Henric Johnson 33
 SET Overview
• Key Features of SET:
– Confidentiality of information
– Integrity of data
– Cardholder account authentication
– Merchant authentication

Henric Johnson 34
SET Participants

Henric Johnson 35
 Sequence of events for
transactions
1. The customer opens an account.
2. The customer receives a certificate.
(contains customer’s public key)
3. Merchants have their own certificates.
(Two certificates: one for signing messages and the
other for key exchange.)
4. The customer places an order.
5. The merchant is verified.
(merchant sends a copy of its certificate;
the customer can verify it.)

Henric Johnson 36
 Sequence of events for
transactions
6. The order and payment are sent.
>The payment information is encrypted in such a
way that it can not be read by the merchant.
> Customer’s certificate enables the merchant to
verify the customer.
7. The merchant requests payment authorization.
>Merchant sends the payment information to
payment gateway, requesting authorization.
8. The merchant confirms the order.
>Merchant sends confirmation to customer.

Henric Johnson 37
 Sequence of events for
transactions
9. The merchant provides the goods or service.
>Merchant ships goods to customer.

10. The merchant requests payments.

>Merchant sends payment request to the
payment gateway, which handles payment
processing.

Henric Johnson 38
 Dual Signature
• Objective: to link two messages that are
intended for two different recipients.
• Customer wants to send:
1. Order Information (OI) to merchant.
2. Payment information (PI) to bank.
>Customer wants to link these two items
and also wants to keep them separate.

Henric Johnson 39
 Dual Signature…
>Merchant need not know about CC#.
>Bank need not know the details of
customer’s order.
>> However, these two items must be
linked to resolve any dispute.
>>Customer can prove that this payment
was intended for this order.
//protects customer and merchant.//

Henric Johnson 40
 Generation of Dual Sign.
• Customer takes the hash (SHA-1) of
PI.
• Customer takes the hash of OI.
• Concatenates these two and takes
hash of the result.
• Customer signs the final hash with his
private key.
DS = EKRc[H(H(PI)||H(OI))]
Henric Johnson 41
Dual Signature
DS  E KRc [ H ( H ( PI ) || H(OI))]

Henric Johnson 42
 Dual Signature
• Merchant has DS, OI, and PIMD.
>Merchant computers H(PIMD||H(OI)).
>Merchant decrypts DS using
customer’s public key.
>If both these items are equal, the
merchant has verified the DS.
//Merchant is never sent the PI//
Henric Johnson 43
 Dual Signature
• The bank has DS, PI, and OIMD.
>The bank computers H(H(PI)||OIMD).
>The bank decrypts DS using
customer’s public key.
>If both these items are equal, the
merchant has verified the DS.
//The bank is never sent the OI.//
Henric Johnson 44
 Payment Processing
• Look at three steps:

1. Purchase request
2. Payment authorization
3. Payment capture

Henric Johnson 45
 Payment Processing…
1. Purchase request:
Cardholder prepares a “purchase
request” message and sends it to
merchant.
The message has following information:
A. Purchase-Related Information:
//Forwarded to payment gateway by
the merchant.//
Henric Johnson 46
 Payment Processing…
A. Purchase-Related Information:…
>PI
>Dual signature (DS)
>OIMD (needed to verify the DS)
//all above items encrypted with a secret key Ks.//
//Ks is not known to merchant. It is known to
payment gateway.//
>Digital envelope: formed by encrypting Ks by the
public key of payment GTW.

Henric Johnson 47
 Payment Processing…
B. Order-Related Information:…
>OI //sent in clear//
>Dual signature (DS)
>PIMD (needed to verify the DS)

C. Cardholder certificate:
>Contains cardholder’s public key.
>Needed by merchant and payment GTW.

Henric Johnson 48
 Payment processing

Cardholder sends Purchase Request

Henric Johnson 49
 Payment Processing
• The merchant processes the message in
the following way:
1. Verifies cardholder certificate with
the CA’s key.
2. Verifies the dual signature.
Insures:
>Message integrity
>Message authentication.

Henric Johnson 50
 Payment Processing
3. Processes the order and forwards
the payment information to payment
GTW for authorization.
4. Sends a “purchase response”
message to the cardholder.

Henric Johnson 51
 Payment processing

Merchant Verifies Customer Purchase Request

Henric Johnson 52
 Payment processing
• Payment Authorization:
>Mercahnt authorizes the transaction
with payment GTW.
> Guarantees that the merchant will
receive payment.
> Consists of two messages:
– Authorization Request
– Authorization Response
Henric Johnson 53
 Payment processing
Authorization Request:
>Merchant to payment GTW.
>Consists of the following three items:
1. Purchase-Related Information:
//Obtained from the customer.//
>PI
>Dual Signature
>OIMD
>The digital envelope

Henric Johnson 54
 Payment processing
2. Authorization-Related Information:
//generated by the merchant.//
>An authorization block
//consists of transaction ID signed with
merchant’s private key and encrypted with
one time symmeric key.//
>A digital envelope
//Formed by encrypting one time key with
the payment GTW’s public key.//
Henric Johnson 55
 Payment processing
3. Certificates:
The following certificates are sent:
>Cardholder’s certificate
//to verify DS.//
>The Merchant’s certificate
//to verify merchant’s signatures.//
>The merchant’s key-exchange cert.
//for the payment GTW’s response.//
Henric Johnson 56
 Payment processing
Authorization Response:
-Payment GTW processes the received
information.
-Obtains authorization from issuer.
-Returns an ”authorization response” to
merchant.
-Authorization response contains three
items.
Henric Johnson 57
 Payment processing
Authorization Response:
1. Authorization-related information:
>Authorization block signed by payment
GTW’s private key and encrypted with a
one-time symmetric key.
>A digital envelop that contains the one
time symmetric key (encrypted with
merchant’s public key).
Henric Johnson 58
 Payment processing
Authorization Response:
2. Capture token information:
//Used to effect the payment later.//
>A signed, encrypted capture token.
//Returned with payment request later.//
>A digital envelope.
//contains the one time symmetric key
encrypted with merchant’s public key.//
Henric Johnson 59
 Payment processing
• Payment Capture:
To obtain payment from payment GTW.
– Capture Request
//Merchant sends this message to
payment GTW.//
//Merchant generates, signs, and
encrypts a capture block that
consists of the following items.//
Henric Johnson 60
 Payment processing
– Capture Request...
>Payment amount
>Transaction ID
>Capture token received earlier for
this transaction.
>Merchant’s certificate.
>Merchant’s key-exchange
certificate.
Henric Johnson 61
 Payment processing
Payment Capture:
>The Payment GTW verifies the
information in the capture request.
>Sends a clearing request to the issuer
over the private payment network.
>The funds are transferred to merchant’s
account.
>The GTW notifies the merchant of the
payment in a Capture Response msg.

Henric Johnson 62
 Recommended Reading and
WEB sites
• Drew, G. Using SET for Secure Electronic
Commerce. Prentice Hall, 1999
• Garfinkel, S., and Spafford, G. Web
Security & Commerce. O’Reilly and
Associates, 1997
• MasterCard SET site
• Visa Electronic Commerce Site
• SETCo (documents and glossary of terms)

Henric Johnson 63