WEB Security & SET. Outline. Web Security Considerations. Web Security Considerations. Secure Socket Layer (SSL) and Transport Layer Security (TLS)

(1)

WEB Security & SET

(Chapter 19 & Stalling Chapter 7)

Spring 2012 EE5723/EE4723

Outline

 Web Security Considerations

 Secure Socket Layer (SSL) and Transport Layer Security (TLS)

Spring 2012 EE5723/EE4723

 Secure Electronic Transaction (SET)

Web Security Considerations



Internet is two way



WWW is essentially client/server application running th I t t

over the Internet



the Web is vulnerale to attacks on the Web server over the Internet



Web is highly visible



If the Web servers are subverted...



Web servers are easy to configure and manage.



Users are not aware of the risks.

Security facilities in the TCP/IP protocol stack



IPSec:

Transparentto end users & applications. IPsec includes a filtering capability->only the selected traffic incur its overhead



SSL/TLS



SSL/TLS

Generalsolution or embedded in specificapplication package



Application-specific security services embedded within

the particular application (e.g, PGP, SET).

(2)

Spring 2012 EE5723/EE4723

SSL & TLS



SSL was originated by Netscape



TLS working group was formed within IETF



TLS working group was formed within IETF



First version of TLS can be viewed as a SSLv3.1



SSLv1 (Netscape)->SSLv3, SSLv2 (MS)->PCT



“SSL intend to provide a practical, widely

Spring 2012 EE5723/EE4723

applicable connection-oriented mechanism for Internet client-server communications security”

Characteristics of SSL



Generic enough to be incorporated into many applications



Provides security between the transport (TCP protocol) and upper application layer protocol



Supports encryption authentication and key exchange



Supports encryption, authentication, and key exchange

Encryptsdata so that anyone who intercepts is unable to read it.

Assuresclients that they are dealing with the server they intend to connect to (server authentication).

Prevents any unauthorized clientsfrom connecting to the server.

Prevents anyone from meddlingwith data going to or coming from the server (message integrity).

Characteristics of SSL



Provides a secure channel



Works for any TCP-based protocol:

HTTP (https://, port 443); SIMAP (port 993); SPOP (port 995); NNTP;

telnet

Can’t protect UDP-based protocol:

 SNMP; NFS; DNS; voice-over-IP for ITU R323



Widely used in Web browsers and servers



Server nearly always authenticated, client more rarely



usually by RSA signature, but other signature schemes y y g g supported, e.g. DSS (Digital Signature Standard)



Key agreement usually by client sending RSA- encrypted secret to server



Diffie-Hellman also supported

(3)

Functional Model of SSL

Spring 2012 EE5723/EE4723

SSL Architecture

 Two layers:

 3 higher-layer protocols: management of SSL exchange

Handshake, change cipher spec, alert

 SSL record protocolprovides basic security services to various higher-layer protocol (e.g., http)

Spring 2012 EE5723/EE4723

SSL protocols



Handshake Protocol :

authentication of the partiesin the comm.,

negotiation of the encryption and hash algorithms,

exchangeof the PreMasterSecret, which will be used later to generate the a th and encr ptionke sthro gh the se ofMasterSecret the auth. and encryption keysthrough the use of MasterSecret.



ChangeCipherSpec (CCS) Protocol:

Indicates the record layerany changes in the security parameters



Alert Protocol:

Indicate errorsencountered during message verificationand any incompatibility during Handshake



Record Protocol:

Applies all the negotiated security parameters between the two parties wishing to exchange info. , and protects the data coming from the application layeras well as all the messages originated in the other three sub-protocols

Exchange of information in SSL

 Exchange of information in SSL occurs in two phases:



Preliminary phase: SSL identifies the parties, negotiates the cryp. attributes, generate and distribute the keys (handshake)



Second phase: date exchange occur, security depends on alg. and parameters p g p



It is possible to signal an intrusion or an error at

any time by Alert Protocol

(4)

Session & Connection



Session



Created by handshake, defines same cryptographic security parameters for multiple connections



Authentication is done once for each session



Session parameters:

ID, peer certificate, compression method, cipher spec, master secret, is resumable.



Connection



A transport with some services, associated with a

Spring 2012 EE5723/EE4723

p session



Connection parameters:

Server and client random no.; parameters of the hashing algorithm at both client/server; block encryption keys for both client/server; IV for both sides; A sequence number for each connection

Session



A SSL session is uniquely identified w/ six state variables

Session Identifier:

 an arbitrary byte sequence chosen by the servery y q y to identify an active or y resumable session state

Peer Certificate:

 X509 certificate of the peer

Compression Method:

 The alg. used to compress data prior to encryption

Cipher Spec: -Cipher suite

 bulk data encryption algorithm (e.g., null, DES), a MAC alg. (e.g. MD5 or SHA 1) etc

Spring 2012 EE5723/EE4723

or SHA-1), etc

MasterSecret:

 48-byte secret sharedbetween the client and server

Resumable:

 A flag indicating whether the session can be used to initiate new connections

Recognized suites in SSL

 Cipher Suite:the set of encryption & hash algorithms

 In order to establish a session key, client & server must agree on a shared secret key.

Cipher Spec.



Used for encrypting the traffic sent between client and server.



RC4 -128-bit or 40-bit keys



RC4 128 bit or 40 bit keys



TripleDES - 168-bit keys, with 112 bits of effective strength



IDEA - 128-bit keys



Fortezza - 80-bit keys



DES - 56-bit keys



RC2 - 40 bit keys



RC2 40 bit keys



Not all SSL/TLS implementation support all algorithms.



For sensitive data use secret key ciphers of 128

bits or more.

(5)

Generation of MasterSecret at the Startup of a session

 A pre-master-secret is exchanged first: RSA, or Diffie-Hellman.

 Both sides compute master secret based on pre-master-secret.

Spring 2012 EE5723/EE4723

Cryptographic Computations: Details

 Client generates a 48-byte pre-master- secret s

_p_p

 Master secret :



s

_m

=MD5(s

_p

|SHA(‘A’| s

_p

|r

_c

|r

_s

)) | MD5(s

_p

|SHA(‘BB’| s

_p

|r

_c

|r

_s

)) | MD5(s

_p

|SHA(‘CCC’| s

_p

|r

_c

|r

_s

))

Spring 2012 EE5723/EE4723

MD5(s

_p

|SHA( CCC | s

_p

|r

_c

|r

_s

))



Where r

_c,s

: client, server random

Connection



Parameters to define the state of a connection:



Server & Client-random

32-bytes, generated at the establishment of a sessionand for each new connection



Server/client write MAC secret (encryption)

Secret used in MAC operationson data written by the server/client



Server/client write key

Bulk cipher keyfor data encrypted by the server/client and d t db th li t/

decrypted by the client/server



IV: for CBC mode (one for client, one for server)

initialized by SSL handshake protocol



Sequence number (both sides): prevent replay attack

Generation of secrets & IV at the startup of a connection



Session key: same as previous, but use the master secretin place of sp

to generate byte stream to cut out:

Cli t MAC t Cli t it k Cli t IV

 Client, server MAC secret; Client, server write key; Client, server IV

sm=MD5(sp|SHA(‘A’| sp|rc|rs)) | MD5(s5(spp|SHA(‘BB’| s|S ( | spp|r|cc|r|ss)) | )) | MD5(sp|SHA(‘CCC’| sp|rc|rs)) Where r_c,s: client, server random

(6)

Handshake Protocol



The most complex part of SSL.



Allows the server & client to authenticate each other.

N ti t ti MAC l ith d



Negotiate encryption, MAC algorithm and cryptographic keys.

Spring 2012 EE5723/EE4723

SSL Handshake protocol: steps



exchange Hello messages to

agree algorithms(“ciphersuites”)

exchangefresh nonces

exchange fresh nonces

check for session resumption



agree secret material for “pre_master_secret”



authenticate by exchanging certificates and proving knowledge of related private key

Spring 2012 EE5723/EE4723



generate master_secret from pre_master_secret and nonces



verify integrity of these messages

Message exchange of handshake protocol:

the establishment of a new session Message of Handshake Protocol

(7)

Message exchange of handshake protocol:

a connection establishment

Spring 2012 EE5723/EE4723

SSL Change Cipher Spec Protocol



Consists a single 1-byte message to indicate to the Record protocol that the encryption can start w/ the security parameters that have been negotiated



It cause the pending Cipher Spec state to be

Spring 2012 EE5723/EE4723

copied into the current Cipher Spec state, which updates the cipher suite to be used on this connection by the Record Layer

SSL Record Protocol



RP participates only after the transmission of the ChangeCipherSpec message



During the establishment of a session



Encapsulate the handshake data



During the encryption phase



Receive data from upper layers (handshake, alert, ChangeCipherSpec, application layers), and transmit g p p , pp y ), them after performing the following actions:

Fragment data in blocks of maximum size of 2¹⁴bytes

Data compression (optional)

…

SSL Record Protocol Operation

(8)

SSL Record Protocol



2 services:

 Confidentiality, message integrity



Layered protocol:

Fragment application data into blocks

Compress data

Apply message

authentication code (MAC)

= h(m|s) for message m and secret s

Spring 2012 EE5723/EE4723

Encrypt with client (cw) or server (sw) write key

Transmit over TCP



Specify content type for higher protocols

SSL Record Protocol Payload

Spring 2012 EE5723/EE4723

SSL Alert Protocol

 Signals alarm message when an error occurred

 Indicates the change of states like the closing of a connection

 Given the same treatment in the Record layer as those of the Application layer or the handshake protocol.

Messages of the Alert Protocol

(9)

SSL based Virtual Private Networks (VPNs)

 What is a VPN?



A virtual network is one that provides virtual circuits using the facilities of a real network



Uses a public telecommunication infrastructure, such as the Internet, to provide remote offices or individual users intranet work access

Spring 2012 EE5723/EE4723



It is secure, encrypted & scalable

VPN in detail…

 Conventional IPSec VPNs

 Users are connected to the corporate resources by a “tunnel”over the internet

 IPSec operates at network layer,

 Once the tunnelis created, it is as if the user's PC is physically on the corporate LAN, and the user can directly access corporate applications.

Spring 2012 EE5723/EE4723

SSL VPNs

 Uses SSL and proxies to provide authorized use to the company’s resources

 SSL VPN gateways are set up at the edgeof the corporate network and serve as a proxy (or go between) to LAN applications

 Web browserconnects to the VPN gatewayjust as it would to a web server

 The browser thinks it is communicating directly with the application; application thinks g y pp ; pp it is communicating directly with the browser or client software.

Pros & Cons of SSL VPN



Advantages of SSL VPNs



Easier to set up and administrate C t ff ti



Cost effective



Provide access from anywhere



Proxy provides increased security



Good Interoperability



Disadvantages of SSL based VPNs



Disadvantages of SSL-based VPNs



Grant access only to web applications



SSL provides inferior authentication as compared to

IPSec

(10)

IPSec vs. SSL

Spring 2012 EE5723/EE4723

SSL Application:

Online Credit Card Payment

 Two main security protocols to protect online y p p payment:



SSL & SET

Spring 2012 EE5723/EE4723

General Steps for Credit Card Payment Requirements of Secure Online Credit Card Payment

 Privacy



Transaction information has not been intercepted.

 Integrity



Transactions information has not been altered.

 Non-repudiation



Transaction cannot be denied, and contract is enforceable.

 Authentication



Sender is who she/he purports to be.

(11)

How does SSL secure WWW?

Spring 2012 EE5723/EE4723

 1. Parameter negotiation (handshake)

 2. Server authentication

 3. Client authentication (only on request)

 4. Key Exchange

 5. Confidential and authenticated message exchange

SSL vs. S-HTTP

 S-HTTP:a secure extension of HTTP

 By Enterprise Integration Technologies

 Both provides secure communicate w/ web server

 C fid ti lit th ti ti d d t i t it

 Confidentiality, authentication, and data integrity

 SSL encrypts the entire Internet sessionat a lower-level protocol.

 S-HTTP works on the same layer with HTTP layer.

 SSL used specialhandshakesto establish the secure connection.

 S-HTTP defines a security negotiation headerfor packets sent during the web session.

Spring 2012 EE5723/EE4723

 SSL’s secure options are preconfiguredin the browser and servers, making SSL easier to use.

 S-HTTP’s secure a vast array of options for enforcing the secure properties -> more difficult to configure

 SSL is the dominant technology for securing Web sessionin the marketplace

SSL Roundup



SSL protocol was developed by Netscape in 1994.

First version, 1.0



The most widely deployed security protocol: y p y y p



Secure browsers, e.g., Netscape, MS Explorer



Secure servers, e.g., Netscape, Microsoft



Competitors:



S-HTTP



PCT (private communication technology) = SSLv2 by MS



Defined in RFC2246,



http://www.ietf.org/rfc/rfc2246.txt



Open-source implementation at



http://www.openssl.org/

Secure Electronic Transactions

 An open encryption and security spec./standard

 Protect credit card transaction on the Internet

 Companies involved:



MasterCard, Visa, IBM, Microsoft, Netscape, , , , , p , RSA, Terisa and Verisign

 Set of security protocols and formats

(12)

SET Overview

 Privacy:



Uses 1024 bit public key cryptography which renders the intercepted message unreadable ! renders the intercepted message unreadable !

 Integrity:



Hashing & signing ensures message sent is unaltered

 Authentication:

Spring 2012 EE5723/EE4723

 Authentication:



Uses digital certificates (X.509v3) to ensure the parties are really who they claim to be.

SET Business Requirements



Provide confidentiality of payment and ordering information



Ensure the integrity of all transmitted data



Provide authentication that a cardholder is a legitimate user g of a credit card account



Provide authentication that a merchant can accept credit card transactions through its relationship with a financial institution (payment gateway)



Ensure the use of the best security practices and system design techniques to protect all legitimate parties in an

Spring 2012 EE5723/EE4723

design techniques to protect all legitimate parties in an electronic commerce transaction



Facilitate and encourage interoperability among software and network providers

SET Transactions in Picture

 Components:Cardholder; Merchant; Acquirer/payment Gateway; customer’s bank

SET Participants

(13)

Key Technologies of SET



Confidentiality of information: DES



Integrity g y of data: RSA digital signatures with SHA-1 g g hash codes



Cardholder account authentication: X.509v3 digital certificates with RSA signatures



Merchant authentication: X.509v3 digital certificates with RSA signatures

Spring 2012 EE5723/EE4723

with RSA signatures



Privacy: separation of order and payment information using dual signatures

Dual Signature

 Purpose:



extra protection of privacy, by separating…



Customer sends order information (OI) to merchant



Customer sends payment information (PI) to bank



Link is needed



Customer can prove a payment is intended for a

Spring 2012 EE5723/EE4723

specific order

Construction of Dual Signature H(OI))]

||

) ( ( [ H H PI E

DS 

KRc

Source: W. Stallings, “Cryptography and Network Security”

Payment processing H(OI))]

||

) ( ( [ H H PI E

DS 

KRc



Cardholder sends Purchase Request

(14)

Payment processing

H(OI))]

||

) ( ( [ H H PI E

DS 

KRc

Spring 2012 EE5723/EE4723

 Merchant Verifies Customer Purchase Request

Payment processing



Cardholder registration



Merchant registration



Purchase request/verification



Payment Authorization: (x.509)



Authorization Request (from merchant to payment gateway)



Authorization Response

Spring 2012 EE5723/EE4723

p



Payment Capture



Capture Request



Capture Response

How safe is SET?

