WEB Security

Outline
• Web Security Considerations
• Secure Socket Layer (SSL) and
Transport Layer Security (TLS)
• Secure Electronic Transaction (SET)
• Recommended Reading and WEB Sites
Web Security Considerations

• WWW is Client server application over Internet

and TCP/IP intranets
• Web is vulnerable to attacks on web servers over
the Internet
• The WEB is visible outlet for corporates
• Web servers are easy to configure and manage.
• Complex software hide many security flaws.
• Subverted servers will provide access to intranet
systems
• Users are not aware of the risks.
Security facilities in the
TCP/IP protocol stack
 SSL and TLS
• SSL was originated by Netscape
• TLS working group was formed within
IETF
• First version of TLS can be viewed as
an SSLv3.1
 SSL
• Make use of TCP
• Provide reliable end to end secure communication
• Two layers of protocols
– Higher layer
• Handshake
• change cipher spec
• Alert
– Lower layer
• Record
SSL Architecture
 SSL connection
• A logical client/server link
• A peer-to-peer connection with two
network nodes.
• Transient.
• Every connection associated with one
session.
 SSL session
• An association between a client and a server
• Defines a set of parameters such as  algorithms used,
session number etc.
• An SSL session is created by the Handshake Protocol
– that allows parameters to be shared among the
connections made between the server and the client
– Sessions are used to avoid negotiation of new parameters
for each connection.
• A single session is shared among multiple SSL connections
between the client and the server.
• In theory, it may also be possible that multiple sessions are
shared by a single connection, but this feature is not used in
practice.
 SSL session
• The concepts of a SSL session and
connection involve several parameters that
are used for SSL-enabled communication
between the client and the server. During
the negotiations of the handshake
protocol, the encryption methods are
established and a series of parameters of
the Session State are subsequently used
within the session.
 SSL session state
• A session state is defined by the following parameters:
– session identifier: this is an identifier generated by the server
to identify a session with a chosen client,
– Peer certificate: X.509 certificate of the peer,
– compression method: a method used to compress data prior to
encryption, 
– CipherSpec: specifies the bulk data encryption algorithm (for
example DES) and the hash algorithm (for example MD5) used
during the session,
– Master secret: 48-byte data being a secret shared between
the client and server
– “is resumable”: this is a flag indicating whether the session can
be used to initiate new connections.
 SSL connection state
• The SSL connection state is defined by the following
parameters:
– Server and client random: random data generated by both the
client and server for each connection,
– Server write MAC secret: the secret key used for data written
by the server, 
– Client write MAC secret: the secret used for data written by
the client,
– Server write key: the bulk cipher key for data encrypted by
the server and decrypted by the client,
– Client write key: the bulk cipher key for data encrypted by the
client and decrypted by the server,
– Initialisation vectors: for CBC mode of block cipher
– Sequence number: sequence numbers maintained separately by
the server for messages transmitted and received during the
data session.
 Record protocol
• Services provided
– Confidentiality
• Encryption of payloads using shared
secret key obtained from handshake
protocol
– Message Integrity
• MAC using shared secret key obtained
from handshake protocol
SSL Record Protocol Operation
SSL Record Format
Change cipher spec protocol
• Payload of record protocol
• Consist of single message
– Single byte value = 1
• Purpose of message
– Cause copy of pending state to
current state
– Updates cipher suite to be used on
the current connection
 Alert protocol
• Conveys SSL alerts to peer
• Payload of record
• Consists of two bytes
– 1st byte : warning or fatal
– 2nd byte: code for specific alerts
SSL Record Protocol
Payload
 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.
 handshake protocol phases
• 1st phase
– Establish security capabilities
• 2nd phase
– Server authentication and key exchange
• 3rd phase
– Client authentication and key exchange
• 4th phase
– finish
Handshake Protocol Action
Full handshake
Re-establish old session
Cryptographic computations
• Shared master secret : 48 byte
• Creation in 2 stages
– Pre-master secret exchanged
• RSA
• Diffie Hellman
– Master secret calculated at both ends
• Use of master secret at client end
– Client write MAC secret
– Client write key
– Client write IV
• Use of master secret at client end
– Server write MAC secret
– Server write key
– Client write IV
 Transport Layer Security
• The same record format as the SSL record format.
• Defined in RFC 2246.
• Similar to SSLv3.
• Differences in the:
– version number (3.1)
– message authentication code (HMAC, TLScomressed.version)
– pseudorandom function ( different from SSL)
– alert codes ( more in TSL)
– cipher suites ( fortezza dropped)
– client certificate types ( fortezza schemes not included)
– certificate_verify and finished message ( calculation different)
– cryptographic computations ( different from SSL)
– Padding ( any amount for total length = Xblock length upto max 255
bytes )
 Master secret in SSL
Master secret =
MD5(pre_master_secret||SHA(“A”||
pre_master_secret||ClientHello.random||
serverHello.random))||
MD5(pre_master_secret||SHA(“BB”||
pre_master_secret||ClientHello.random||
serverHello.random))||
MD5(pre_master_secret||SHA(“CCC”||
pre_master_secret||ClientHello.random||
serverHello.random))||
 Key block in SSL
Key block =
MD5(master_secret||SHA(“A”||
master_secret||serverHello.random||
ClientHello.random))||
MD5(master_secret||SHA(“BB”||
pre_master_secret|| serverHello.random||
ClientHello.random))||
MD5(master_secret||SHA(“CCC”||
pre_master_secret|| serverHello.random||
ClientHello.random))||…..
 Master secret and Key block
in TLS
Master secret =
PRF(pre_master_secret, “master secret”,
ClientHello.random||serverHello.random)
Key block =
PRF(master_secret, “key expansion”, Security
Parameters.server_random||
SecurityParameters.client_random)
PRF(secret,label,seed) = P_MD5(S1,label||seed)XOR
P_SHA-1(S2,label||seed)
Secure Electronic Transactions

• An open encryption and security

specification.
• 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.
 SET Services
• Provides a secure communication
channel in a transaction.
• Provides tust by the use of X.509v3
digital certificates.
• Ensures privacy.
 SET Overview
• Key Features of SET:
– Confidentiality of information
– Integrity of data
– Cardholder account authentication
– Merchant authentication
SET Participants
 SET participants
• Cardholder: authorised holder of credit card
issued by issuer. Interacts with merchants over
internet
• Merchant : Seller of goods over internet
• Issuer : Bank which issues credit card to card
holder.
• Acquirer : Fin institution which has an account
with a merchant, processes card authorisation and
payments.
• Payment gateway: Interfaces between SET and
Payment network
• CA: Issues X.509 certificates to All players
 Sequence of events for
transactions
1. The customer opens an account.
2. The customer receives a certificate.
3. Merchants have their own certificates.
4. The customer places an order.
5. The merchant is verified.
6. The order and payment are sent.
7. The merchant request payment authorization.
8. The merchant confirm the order.
9. The merchant provides the goods or service.
10. The merchant requests payments.
Dual Signature
DS = E KRc [ H ( H ( PI ) || H(OI))]
 Payment processing

Cardholder sends Purchase Request

 Payment processing

Merchant Verifies Customer Purchase Request

 Payment processing
• Payment Request:
– Initiate request
– Initiate response
– Purchase request
– Purchase response
• Payment Authorization:
– Authorization Request
– Authorization Response
• Payment Capture:
– Capture Request
– Capture Response
 Payment Request
• Initiate request from card holder
– Request certificates to merchant
– Incl: Brand of cc, ID req/resp, nonce
• Initiate response by merchant
– Response signed by Kr of merchant
– Incl: Cust nonce, new nonce, trans ID, merchant’s
signature certificate, payment gateways key exchange
certificate
Cardholder
– verifies merchant and gateway’s certificates
– Generates
• OI- ref to order
• PI – card number, value etc
 Payment Request
• Purchase request by card holder
– Forwarded to payment gateway
• Incl: EKs[PI+Dual sig+OIMD], EKUch[Ks]
– To merchant
• OI+dual sig+PIMD, CH certificate
• Purchase response by merchant
– Incl: Trans ID, response block with order ack
signed by merchant using Kr, merchant’s
signature certificate
Card holder
– Verifies merchant’s signature on response block
 Payment Authorization
• Authorization Request to payment gateway from merchant
– forwarded
• PI+dual sig+OIMD+EKUch[Ks]
– Generated
• Auth block: EKms[SignKrm[Trans ID]]
• EKUpg[EKms]
– Certificates
• Card holder signature key, merchant signature key and merchant key exchange
certificates
Payment gateway
– Verifies all certificates, obtains EKms, decrypts auth block, verifies merchant’s sign, verifies
dual sign, verifies trans ID, requests and receives an auth from issuer
• Authorisation response by payment gateway to merchant
– Auth block:
• EKpgs[SignKrpg[authorisation]]
• EKUm[EKpgs]
– Capture token info:
• EKpgs[SignKrpg[capture token]]
– Certificate
• Gateway’s signature key certifixcate
 Payment capture
• Capture Request by merchant to payment
gateway
– Capture req block
• Amount+Trand ID+token signed and
encrypted by merchant
This is verified by payment gateway. Req
issuer to release payment
• Capture Response by payment gateway to
merchant confirmation of payment
 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)