CV G. Web Security Web now widely used by business, government, individuals but Internet & Web are vulnerable have a variety of threats integrity.

CV CV G G

Web SecurityWeb Security

Web now widely used by business, Web now widely used by business, government, individualsgovernment, individuals

but Internet & Web are vulnerablebut Internet & Web are vulnerable have a variety of threatshave a variety of threats

integrityintegrity confidentialityconfidentiality denial of servicedenial of service authenticationauthentication

need added security mechanismsneed added security mechanisms

SSL (Secure Socket Layer)SSL (Secure Socket Layer)

transport layer security servicetransport layer security service originally developed by Netscapeoriginally developed by Netscape version 3 designed with public inputversion 3 designed with public input subsequently became Internet standard subsequently became Internet standard

known as TLS (Transport Layer Security)known as TLS (Transport Layer Security) uses TCP to provide a reliable end-to-end uses TCP to provide a reliable end-to-end

serviceservice SSL has two layers of protocolsSSL has two layers of protocols

SSL ArchitectureSSL Architecture

SSL ArchitectureSSL Architecture

SSL connectionSSL connection a transient, peer-to-peer, communications linka transient, peer-to-peer, communications link associated with 1 SSL sessionassociated with 1 SSL session

SSL sessionSSL session an association between client & serveran association between client & server created by the Handshake Protocolcreated by the Handshake Protocol define a set of cryptographic parametersdefine a set of cryptographic parameters may be shared by multiple SSL connectionsmay be shared by multiple SSL connections

Session state is defined by Session state is defined by Session identifier:Session identifier: An arbitrary byte sequence chosen by An arbitrary byte sequence chosen by

the server to identify an active or resumable session state.the server to identify an active or resumable session state. Peer certificate: Peer certificate: An X509.v3 certificate of the peer. This An X509.v3 certificate of the peer. This

element of the state may be null.element of the state may be null. Compression method: Compression method: The algorithm used to compress The algorithm used to compress

data prior to encryption.data prior to encryption. Cipher spec: Cipher spec: Specifies the bulk data encryption algorithm Specifies the bulk data encryption algorithm

(such as null, AES, etc.) and a hash algorithm (such as (such as null, AES, etc.) and a hash algorithm (such as MD5 or SHA-1) used for MAC calculation. It also defines MD5 or SHA-1) used for MAC calculation. It also defines cryptographic attributes such as the hash_size.cryptographic attributes such as the hash_size.

Session StateSession State

Master secret:Master secret: 48-byte secret shared 48-byte secret shared between the client and server.between the client and server.

Is resumable: A flag indicating whether Is resumable: A flag indicating whether the session can be used to initiate new the session can be used to initiate new connections.connections.

Connection StateConnection State

Server and client random: Byte sequences that are Server and client random: Byte sequences that are chosen by the server and client for each connection.chosen by the server and client for each connection.

Server write MAC secret: The secret key used in MAC Server write MAC secret: The secret key used in MAC operations on data sent by the server.operations on data sent by the server.

Client write MAC secret: The secret key used in MAC Client write MAC secret: The secret key used in MAC operations on data sent by the client.operations on data sent by the client.

Server write key: The conventional encryption key for Server write key: The conventional encryption key for data encrypted by the server and decrypted by the data encrypted by the server and decrypted by the client.client.

Client write key: The conventional encryption key for Client write key: The conventional encryption key for data encrypted by the client and decrypted by the data encrypted by the client and decrypted by the server.server.

SSL Record Protocol SSL Record Protocol ServicesServices

message integritymessage integrity using a MAC with shared secret keyusing a MAC with shared secret key similar to HMAC but with different paddingsimilar to HMAC but with different padding

confidentialityconfidentiality using symmetric encryption with a shared using symmetric encryption with a shared

secret key defined by Handshake Protocolsecret key defined by Handshake Protocol AES, IDEA, RC2-40, DES-40, DES, 3DES, AES, IDEA, RC2-40, DES-40, DES, 3DES,

Fortezza, RC4-40, RC4-128Fortezza, RC4-40, RC4-128 message is compressed before encryptionmessage is compressed before encryption

SSL Record Protocol SSL Record Protocol OperationOperation

SSL Record ProtocolSSL Record Protocol

Record Protocol takes an application Record Protocol takes an application message to be transmitted, fragments message to be transmitted, fragments the data into blocks, compresses the data, the data into blocks, compresses the data, applies MAC, encrypts, adds a header and applies MAC, encrypts, adds a header and transmits resulting unit in a TCP segmenttransmits resulting unit in a TCP segment

Received data are decrypted, verified, Received data are decrypted, verified, decompressed and reassembled and decompressed and reassembled and delivered to higher level usersdelivered to higher level users


Fragmented into blocks of 2 Fragmented into blocks of 2 1414 bytes or bytes or lessless

Compression must be lossless and may Compression must be lossless and may not increase the content length by more not increase the content length by more than 1024 bytesthan 1024 bytes

In SSLv3 no compression alg is specified In SSLv3 no compression alg is specified so default compression alg is null so default compression alg is null MAC MAC

MAC ComputationMAC Computation

hash(MAC_write_secret || pad_2 ||hash(MAC_write_secret || pad_2 || hash(MAC_write_secret || pad_1 || hash(MAC_write_secret || pad_1 ||

seq_num ||seq_num || SSLCompressed.type ||SSLCompressed.type || SSLCompressed.length || SSLCompressed.length ||

SSLCompressed.fragment))SSLCompressed.fragment))

SSL Record ProtocolSSL Record Protocol For stream encryption, the compressed message For stream encryption, the compressed message

plus the MAC are encrypted.plus the MAC are encrypted. For block encryption, padding may be added after For block encryption, padding may be added after

the MAC prior to encryption.the MAC prior to encryption. An example is a plaintext (orAn example is a plaintext (or compressed text if compression is used) of 58 bytes, compressed text if compression is used) of 58 bytes,

with a MAC of 20 bytes (using SHA-1), that is with a MAC of 20 bytes (using SHA-1), that is encrypted using a block length of 8 bytes (e.g., encrypted using a block length of 8 bytes (e.g., DES). With the padding.length byte, this yields a DES). With the padding.length byte, this yields a total of 79 bytes. To make the total an integer total of 79 bytes. To make the total an integer multiple of 8, one byte of padding is added.multiple of 8, one byte of padding is added.



the compressed message plus the MAC the compressed message plus the MAC are are encrypted using symmetric encrypted using symmetric encryption.encryption.


The final step of SSL Record Protocol The final step of SSL Record Protocol processing is to prepend a header, processing is to prepend a header, consisting of the following fields:consisting of the following fields:

Content Type (8 bits): The higher layer Content Type (8 bits): The higher layer protocol used to process the enclosed protocol used to process the enclosed fragment.fragment.

Major Version (8 bits): Indicates major Major Version (8 bits): Indicates major version of SSL in use. For SSLv3, the version of SSL in use. For SSLv3, the value is 3.value is 3.


Minor Version (8 bits): Indicates minor Minor Version (8 bits): Indicates minor version in use. For SSLv3, the value is version in use. For SSLv3, the value is 0.0.

Compressed Length (16 bits): The Compressed Length (16 bits): The length in bytes of the plaintext length in bytes of the plaintext fragment (or compressed fragment if fragment (or compressed fragment if compression is used).compression is used).

The maximum value is 2The maximum value is 21414 + 2048. + 2048.

SSL Record FormatSSL Record Format

SSL Change Cipher Spec SSL Change Cipher Spec ProtocolProtocol

one of the 3 SSL specific protocols which one of the 3 SSL specific protocols which use the SSL Record protocoluse the SSL Record protocol

a single messagea single message causes pending state to become currentcauses pending state to become current hence updating the cipher suite in usehence updating the cipher suite in use

SSL Alert ProtocolSSL Alert Protocol conveys SSL-related alerts to peer entityconveys SSL-related alerts to peer entity severityseverity

• warning or fatalwarning or fatal

specific alertspecific alert• fatal: unexpected message, bad record mac, fatal: unexpected message, bad record mac,

decompression failure, handshake failure, illegal decompression failure, handshake failure, illegal parameterparameter

• warning: close notify, no certificate, bad certificate, warning: close notify, no certificate, bad certificate, unsupported certificate, certificate revoked, unsupported certificate, certificate revoked, certificate expired, certificate unknowncertificate expired, certificate unknown

compressed & encrypted like all SSL datacompressed & encrypted like all SSL data

SSL Alert ProtocolSSL Alert Protocol

unexpected_message: An inappropriate message was unexpected_message: An inappropriate message was received.received.

bad_record_mac: An incorrect MAC was received.bad_record_mac: An incorrect MAC was received. decompression_failure: The decompression function decompression_failure: The decompression function

received improper input (e.g., unable to decompress or received improper input (e.g., unable to decompress or decompress to decompress to greater than maximum allowable length).greater than maximum allowable length).

handshake_failure: Sender was unable to negotiate an handshake_failure: Sender was unable to negotiate an acceptable set of security parameters given the options acceptable set of security parameters given the options available.available.

illegal_parameter: A field in a handshake message was illegal_parameter: A field in a handshake message was out of range or inconsistent with other fields.out of range or inconsistent with other fields.

The remainder of the alerts are the following:The remainder of the alerts are the following:


close_notify: Notifies the recipient that the sender close_notify: Notifies the recipient that the sender will not send any more messages on this will not send any more messages on this connection. Each party is requiredconnection. Each party is required

to send a close_notify alert before closing the write to send a close_notify alert before closing the write side of a connection.side of a connection.

no_certificate: May be sent in response to a no_certificate: May be sent in response to a certificate request if no appropriate certificate is certificate request if no appropriate certificate is available.available.

bad_certificate: A received certificate was corrupt bad_certificate: A received certificate was corrupt (e.g., contained a signature that did not verify).(e.g., contained a signature that did not verify).


unsupported_certificate: The type of the unsupported_certificate: The type of the received certificate is not supported.received certificate is not supported.

certificate_revoked: A certificate has certificate_revoked: A certificate has been revoked by its signer.been revoked by its signer.

certificate_expired: A certificate has certificate_expired: A certificate has expired.expired.

certificate_unknown: Some other certificate_unknown: Some other unspecified issue arose in processing the unspecified issue arose in processing the certificate, rendering it unacceptable.certificate, rendering it unacceptable.


SSL Handshake ProtocolSSL Handshake Protocol allows server & client to:allows server & client to:

authenticate each otherauthenticate each other to negotiate encryption & MAC algorithmsto negotiate encryption & MAC algorithms to negotiate cryptographic keys to be usedto negotiate cryptographic keys to be used

comprises a series of messages in phasescomprises a series of messages in phases1.1. Establish Security CapabilitiesEstablish Security Capabilities

2.2. Server Authentication and Key ExchangeServer Authentication and Key Exchange

3.3. Client Authentication and Key ExchangeClient Authentication and Key Exchange

4.4. FinishFinish

SSL Handshake ProtocolSSL Handshake Protocol

The Handshake Protocol consists of a series of The Handshake Protocol consists of a series of messages exchanged by client and servermessages exchanged by client and server

Each message has three fields:Each message has three fields: Type (1 byte): Indicates one of 10 messages. Type (1 byte): Indicates one of 10 messages.

Table 17.2 lists the defined message types.Table 17.2 lists the defined message types. Length (3 bytes): The length of the message Length (3 bytes): The length of the message

in bytes.in bytes. Content ( 0 bytes): The parameters Content ( 0 bytes): The parameters

associated with this message2associated with this message2



Phase 1 Establish Security Phase 1 Establish Security CapabilitiesCapabilities

Version: The highest SSL version understood by the client.Version: The highest SSL version understood by the client. Random: A client-generated random structure, consisting of a 32-bit Random: A client-generated random structure, consisting of a 32-bit

timestamp and 28 bytes generated by a secure random number timestamp and 28 bytes generated by a secure random number generator. These values serve as nonces and are used during key generator. These values serve as nonces and are used during key exchange to prevent replay attacks.exchange to prevent replay attacks.

Session ID: A variable-length session identifier. A nonzero value Session ID: A variable-length session identifier. A nonzero value indicates that the client wishes to update the parameters of an existing indicates that the client wishes to update the parameters of an existing connection or create a new connection on this session. A zero value connection or create a new connection on this session. A zero value indicates that the client wishes to establish a new connection on a new indicates that the client wishes to establish a new connection on a new session.session.

CipherSuite: This is a list that contains the combinations of CipherSuite: This is a list that contains the combinations of cryptographic algorithms supported by the client, in decreasing order cryptographic algorithms supported by the client, in decreasing order of preference. Each element of the list (each cipher suite) defines both of preference. Each element of the list (each cipher suite) defines both a key exchange algorithm and a CipherSpec;a key exchange algorithm and a CipherSpec;

Compression Method: This is a list of the compression methods the Compression Method: This is a list of the compression methods the client supports.client supports.


RSARSA: The secret key is encrypted with the receiver's RSA public key. A public-key : The secret key is encrypted with the receiver's RSA public key. A public-key certificate for the receiver's key must be made available.certificate for the receiver's key must be made available.

Fixed Diffie-Hellman: Fixed Diffie-Hellman: This is a Diffie-Hellman key exchange in which the server's This is a Diffie-Hellman key exchange in which the server's certificate contains the Diffie-Hellman public parameters signed by the certificate certificate contains the Diffie-Hellman public parameters signed by the certificate authority (CA). That is, the public-key certificate contains the Diffie-Hellman public-authority (CA). That is, the public-key certificate contains the Diffie-Hellman public-key parameters. The client provides its Diffie-Hellman public key parameters either key parameters. The client provides its Diffie-Hellman public key parameters either in a certificate, if client authentication is required, or in a key exchange message. in a certificate, if client authentication is required, or in a key exchange message. This method results in a fixed secret key between two peers, based on the Diffie-This method results in a fixed secret key between two peers, based on the Diffie-Hellman calculation using the fixed public keys.Hellman calculation using the fixed public keys.

Ephemeral Diffie-Hellman:Ephemeral Diffie-Hellman: This technique is used to create ephemeral This technique is used to create ephemeral (temporary, one-time) secret keys. In this case, the Diffie-Hellman public keys are (temporary, one-time) secret keys. In this case, the Diffie-Hellman public keys are exchanged, signed using the sender's private RSA or DSS key. The receiver can exchanged, signed using the sender's private RSA or DSS key. The receiver can use the corresponding public key to verify the signature. Certificates are used to use the corresponding public key to verify the signature. Certificates are used to authenticate the public keys. This would appear to be the most secure of the three authenticate the public keys. This would appear to be the most secure of the three Diffie-Hellman options because it results in a temporary, authenticated key.Diffie-Hellman options because it results in a temporary, authenticated key.

Anonymous Diffie-Hellman: Anonymous Diffie-Hellman: The base public Diffie-Hellman parameters to the The base public Diffie-Hellman parameters to the other, with no authentication. This approach is vulnerable to man-in-the-middle other, with no authentication. This approach is vulnerable to man-in-the-middle attacks, in which the attacker conducts anonymous Diffie- Hellman with both attacks, in which the attacker conducts anonymous Diffie- Hellman with both parties.parties.

Fortezza: The technique defined for the Fortezza scheme.Fortezza: The technique defined for the Fortezza scheme.


CipherAlgorithm: Any of the algorithms CipherAlgorithm: Any of the algorithms mentioned earlier: RC4, RC2, DES, 3DES, DES40, mentioned earlier: RC4, RC2, DES, 3DES, DES40, IDEA, FortezzaIDEA, Fortezza

MACAlgorithm: MD5 or SHA-1MACAlgorithm: MD5 or SHA-1 CipherType: Stream or BlockCipherType: Stream or Block IsExportable: True or FalseIsExportable: True or False HashSize: 0, 16 (for MD5), or 20 (for SHA-1) bytesHashSize: 0, 16 (for MD5), or 20 (for SHA-1) bytes Key Material: A sequence of bytes that contain Key Material: A sequence of bytes that contain

data used in generating the write keysdata used in generating the write keys IV Size: The size of the Initialization Value for IV Size: The size of the Initialization Value for

Cipher Block Chaining (CBC) encryptionCipher Block Chaining (CBC) encryption

Phase 2. Server Phase 2. Server Authentication and Key Authentication and Key

ExchangeExchange The certificate message is required for any The certificate message is required for any

agreed-on key exchange method except agreed-on key exchange method except anonymous Diffie-Hellman.anonymous Diffie-Hellman.

Next, a server_key_exchange message Next, a server_key_exchange message may be sent if it is required. It is not may be sent if it is required. It is not required in two instances: (1) The server required in two instances: (1) The server has sent a certificate with fixed Diffie-has sent a certificate with fixed Diffie-Hellman parameters, or (2) RSA key Hellman parameters, or (2) RSA key exchange is to be usedexchange is to be used


ExchangeExchange The server_key_exchange message is needed for The server_key_exchange message is needed for

the following:the following: Anonymous Diffie-Hellman: The message content Anonymous Diffie-Hellman: The message content

consists of the two global Diffie-Hellman values (a consists of the two global Diffie-Hellman values (a prime number and a primitive root of that number) prime number and a primitive root of that number) plus the server's public Diffie-Hellman keyplus the server's public Diffie-Hellman key

Ephemeral Diffie-Hellman: The message content Ephemeral Diffie-Hellman: The message content includes the three Diffie-Hellman parameters includes the three Diffie-Hellman parameters provided for anonymousprovided for anonymous

Diffie-Hellman, plus a signature of those Diffie-Hellman, plus a signature of those parameters.parameters.


ExchangeExchange RSA key exchange, in which the server RSA key exchange, in which the server

is using RSA but has a signature-only is using RSA but has a signature-only RSA key( Public Key plus signature)RSA key( Public Key plus signature)

FortezzaFortezza signature is created by taking the hash of signature is created by taking the hash of

a message and encrypting it with the a message and encrypting it with the sender's private key. In this case the hash sender's private key. In this case the hash is defined asis defined as


ExchangeExchange The The certificate_request message includes two parameters: certificate_request message includes two parameters:

certificate_type and certificate_authoritiescertificate_type and certificate_authorities The certificate type indicates theThe certificate type indicates the public-key algorithm and its use:public-key algorithm and its use: RSA, signature onlyRSA, signature only DSS, signature onlyDSS, signature only RSA for fixed Diffie-Hellman; in this case the signature is used only RSA for fixed Diffie-Hellman; in this case the signature is used only

for authentication, by sending a certificate signed with RSAfor authentication, by sending a certificate signed with RSA DSS for fixed Diffie-Hellman; again, used only for authenticationDSS for fixed Diffie-Hellman; again, used only for authentication RSA for ephemeral Diffie-HellmanRSA for ephemeral Diffie-Hellman DSS for ephemeral Diffie-HellmanDSS for ephemeral Diffie-Hellman FortezzaFortezza

The final message in Phase 2, and one The final message in Phase 2, and one that is always required, is thethat is always required, is theserver_done server_done message, which is sent by the server to message, which is sent by the server to indicate the indicate the end of the server hello and end of the server hello and associated messagesassociated messages

Phase 3. Client Authentication Phase 3. Client Authentication and Key Exchangeand Key Exchange

the client should verify that the server the client should verify that the server provided a valid certificate if required and provided a valid certificate if required and check that the server_hello parameters check that the server_hello parameters are acceptable. If all is satisfactory, the are acceptable. If all is satisfactory, the client sends one or more messages back client sends one or more messages back to the server.to the server.

Phase 3. Client Authentication Phase 3. Client Authentication and Key Exchangeand Key Exchange

client_key_exchange message, which must be sent in this phaseclient_key_exchange message, which must be sent in this phase The content of the message depends on the type of key exchange, as The content of the message depends on the type of key exchange, as

follows:follows: RSA: The client generates a 48-byte RSA: The client generates a 48-byte pre-master secret and pre-master secret and

encrypts with the public key from the server's certificate or encrypts with the public key from the server's certificate or temporary RSA key from a server_key_exchange message. Its use to temporary RSA key from a server_key_exchange message. Its use to compute a compute a master secret is explained later.master secret is explained later.

Ephemeral or Anonymous Diffie-Hellman: The client's public Ephemeral or Anonymous Diffie-Hellman: The client's public Diffie-Hellman parameters are sent.Diffie-Hellman parameters are sent.

Fixed Diffie-Hellman: The client's public Diffie-Hellman Fixed Diffie-Hellman: The client's public Diffie-Hellman parameters were sent in a certificate message, so the content of parameters were sent in a certificate message, so the content of this this message is null.message is null.

Fortezza: The client's Fortezza parameters are sent.Fortezza: The client's Fortezza parameters are sent.

Phase 4Phase 4

Finally, in this phase, the client may send Finally, in this phase, the client may send a certificate_verify message to provide a certificate_verify message to provide explicit verification of a client certificate.explicit verification of a client certificate.

Phase 4Phase 4

This phase completes the setting up of a secure This phase completes the setting up of a secure connection. The client sends a connection. The client sends a change_cipher_spec change_cipher_spec message and copies the pendingmessage and copies the pending

CipherSpec into the current CipherSpecCipherSpec into the current CipherSpec The client then immediately sends the The client then immediately sends the finished finished

message under the new algorithms, keys, and message under the new algorithms, keys, and secrets.secrets.

The finished message verifies that the key exchange and The finished message verifies that the key exchange and authentication processes were successful. The content authentication processes were successful. The content of the finished message is the concatenation of two hash of the finished message is the concatenation of two hash values:values:

FinishFinish

Master SecretMaster Secret The shared master secret is a one-time 48-byte value (384 The shared master secret is a one-time 48-byte value (384 bits) generated for this session by means of secure key bits) generated for this session by means of secure key exchange.exchange.

The creation is in two stages. First, a pre_master_secret is The creation is in two stages. First, a pre_master_secret is exchanged. Second, the master_secret is calculated by exchanged. Second, the master_secret is calculated by both parties. For pre_master_secret exchange, there are both parties. For pre_master_secret exchange, there are two possibilities:two possibilities:

RSA: A 48-byte pre_master_secret is generated by the RSA: A 48-byte pre_master_secret is generated by the client, encrypted with the server's public RSA key, and client, encrypted with the server's public RSA key, and sent to the sent to the server. The server decrypts the ciphertext using server. The server decrypts the ciphertext using its private key to recover the pre_master_secret.its private key to recover the pre_master_secret.

Diffie-Hellman: Both client and server generate a Diffie-Diffie-Hellman: Both client and server generate a Diffie-Hellman public key. After these are exchanged, each Hellman public key. After these are exchanged, each side performs the side performs the Diffie-Hellman calculation to create the Diffie-Hellman calculation to create the shared pre_master_secret.shared pre_master_secret.

CipherSpecs require a client write MAC secret, a CipherSpecs require a client write MAC secret, a server write MAC secret, a client write key, a server write MAC secret, a client write key, a server write key, a client write IV, and aserver write key, a client write IV, and a

server write IV, which are generated from the server write IV, which are generated from the master sercret in that ordermaster sercret in that order

The generation of the key material from the The generation of the key material from the master secret uses the same format for master secret uses the same format for generation of the master secret from the pre-generation of the master secret from the pre-master secret:master secret:

TLS (Transport Layer TLS (Transport Layer Security)Security)

IETF standard RFC 2246 similar to SSLv3IETF standard RFC 2246 similar to SSLv3 with minor differenceswith minor differences

in record format version numberin record format version number uses HMAC for MACuses HMAC for MAC a pseudo-random function expands secretsa pseudo-random function expands secrets has additional alert codeshas additional alert codes some changes in supported cipherssome changes in supported ciphers changes in certificate types & negotiationschanges in certificate types & negotiations changes in crypto computations & paddingchanges in crypto computations & padding

There are two differences between the SSLv3 and TLS MAC schemes: the There are two differences between the SSLv3 and TLS MAC schemes: the actual algorithm and the scope of the MAC calculationactual algorithm and the scope of the MAC calculation

TLS makes use of the HMAC algorithm, HMAC is defined as TLS makes use of the HMAC algorithm, HMAC is defined as HMACHMACK(M) = H[(K+ opad)||H[(K+ ipad)||M]] K(M) = H[(K+ opad)||H[(K+ ipad)||M]] wherewhere H = embedded hash function (for TLS, either MD5 or SHA-1)H = embedded hash function (for TLS, either MD5 or SHA-1) M = message input to HMACM = message input to HMAC K+ = secret key padded with zeros on the left so that the result is equal to 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 the block length of the hash code(for MD5 and SHA-1, block length = 512 SHA-1, block length = 512 bits)bits)

ipad = 00110110 (36 in hexadecimal) repeated 64 times (512 bits)ipad = 00110110 (36 in hexadecimal) repeated 64 times (512 bits) opad = 01011100 (5C 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 SSLv3 uses the same algorithm, except that the padding bytes are

concatenated with the secret key rather than being XORed with the secret concatenated with the secret key rather than being XORed with the secret key padded to the block length. The level of security should be about the key padded to the block length. The level of security should be about the same in both cases.same in both cases.

TLS makes use of a pseudorandom function referred to TLS makes use of a pseudorandom function referred to as PRF to expand secrets into blocks of data for as PRF to expand secrets into blocks of data for purposes of key generation or validation. purposes of key generation or validation.

The objective is to make use of a relatively small shared The objective is to make use of a relatively small shared secret value but to generate longer blocks of data in a secret value but to generate longer blocks of data in a way that is secure from the kinds of attacks made on way that is secure from the kinds of attacks made on hash functions and MACs. hash functions and MACs.

The PRF is based on the following data expansion The PRF is based on the following data expansion functionfunction

where A() is defined aswhere A() is defined as A(0) = seedA(0) = seed A(A(i) = HMAC_hash (secret, A(i - 1))i) = HMAC_hash (secret, A(i - 1)) The data expansion function makes use of the HMAC algorithm, The data expansion function makes use of the HMAC algorithm,

with either MD5 or SHA-1 as the underlying hash function. with either MD5 or SHA-1 as the underlying hash function. As can be seen, P_hash can be iterated as many times as As can be seen, P_hash can be iterated as many times as

necessary to produce the required quantity of data. For example, if necessary to produce the required quantity of data. For example, if P_SHA-1 was used to generate 64 bytes of data, it would have to P_SHA-1 was used to generate 64 bytes of data, it would have to be iterated four times, producing 80 bytes of data, of which the last be iterated four times, producing 80 bytes of data, of which the last 16 would be discarded. 16 would be discarded.

In this case, P_MD5 would also have to be iterated four times, In this case, P_MD5 would also have to be iterated four times, producing exactly 64 bytes of data. Note that each iteration involves producing exactly 64 bytes of data. Note that each iteration involves two executions of HMAC, each of which in turn involves two two executions of HMAC, each of which in turn involves two executions of the underlying hash algorithmexecutions of the underlying hash algorithm

To make PRF as secure as possible, it To make PRF as secure as possible, it uses two hash algorithms in a way that uses two hash algorithms in a way that should guarantee its security if either should guarantee its security if either algorithm remainsalgorithm remains

secure. PRF is defined assecure. PRF is defined as

PRF takes as input a secret value, an identifying label, PRF takes as input a secret value, an identifying label, and a seed value and produces an output of arbitrary and a seed value and produces an output of arbitrary length. length.

The output is created by splitting the secret value into The output is created by splitting the secret value into two halves (S1 and S2) and performing P_hash on each two halves (S1 and S2) and performing P_hash on each half, using MD5 on one half and SHA-1 on the other half. half, using MD5 on one half and SHA-1 on the other half.

The two results are exclusive-ORed to produce the The two results are exclusive-ORed to produce the output; for this purpose, P_MD5 will generally have to be output; for this purpose, P_MD5 will generally have to be iterated more times than P_SHA-1 to produce an equal iterated more times than P_SHA-1 to produce an equal amount of data for input to the exclusive-OR function.amount of data for input to the exclusive-OR function.

Alert CodesAlert Codes TLS supports all of the alert codes defined in SSLv3 with the exception of TLS supports all of the alert codes defined in SSLv3 with the exception of

no_certificate. A number of additional codes are defined in TLS;no_certificate. A number of additional codes are defined in TLS; of these, the following are always fatal:of these, the following are always fatal: decryption_failed: A ciphertext decrypted in an invalid way; either it was decryption_failed: A ciphertext decrypted in an invalid way; either it was

not an even multiple of the block length or its paddingnot an even multiple of the block length or its padding values, when checked, were incorrect.values, when checked, were incorrect. record_overflow: A TLS record was received with a payload (ciphertext) record_overflow: A TLS record was received with a payload (ciphertext)

whose length exceeds 214 + 2048 bytes, or thewhose length exceeds 214 + 2048 bytes, or the ciphertext decrypted to a length of greater than 214 + 1024 bytes.ciphertext decrypted to a length of greater than 214 + 1024 bytes. unknown_ca: A valid certificate chain or partial chain was received, but unknown_ca: A valid certificate chain or partial chain was received, but

the certificate was not accepted because the CAthe certificate was not accepted because the CA certificate could not be located or could not be matched with a known, trusted certificate could not be located or could not be matched with a known, trusted

CA.CA. access_denied: A valid certificate was received, but when access control access_denied: A valid certificate was received, but when access control

was applied, the sender decided not to proceed withwas applied, the sender decided not to proceed with the negotiation.the negotiation.

decode_error: A message could not be decoded because a field was out of its decode_error: A message could not be decoded because a field was out of its specified range or the length of the messagespecified range or the length of the message

was incorrect.was incorrect. export_restriction: A negotiation not in compliance with export restrictions export_restriction: A negotiation not in compliance with export restrictions

on key length was detected.on key length was detected. protocol_version: The protocol version the client attempted to negotiate is protocol_version: The protocol version the client attempted to negotiate is

recognized but not supported.recognized but not supported. insufficient_security: Returned instead of handshake_failure when a insufficient_security: Returned instead of handshake_failure when a

negotiation has failed specifically because the servernegotiation has failed specifically because the server requires ciphers more secure than those supported by the client.requires ciphers more secure than those supported by the client. internal_error: An internal error unrelated to the peer or the correctness of internal_error: An internal error unrelated to the peer or the correctness of

the protocol makes it impossible to continue.the protocol makes it impossible to continue. The remainder of the new alerts include the following:The remainder of the new alerts include the following: decrypt_error: A handshake cryptographic operation failed, including being decrypt_error: A handshake cryptographic operation failed, including being

unable to verify a signature, decrypt a keyunable to verify a signature, decrypt a key exchange, or validate a finished message.exchange, or validate a finished message.

user_canceled: This handshake is being user_canceled: This handshake is being canceled for some reason unrelated to a canceled for some reason unrelated to a protocol failure.protocol failure.

no_renegotiation: Sent by a client in response no_renegotiation: Sent by a client in response to a hello request or by the server in response to a hello request or by the server in response to a client hello after initialto a client hello after initial

handshaking. Either of these messages would handshaking. Either of these messages would normally result in renegotiation, but this alert normally result in renegotiation, but this alert indicates that the sender is not ableindicates that the sender is not able

to renegotiate. This message is always a warning.to renegotiate. This message is always a warning.

Cipher SuitesCipher Suites There are several small differences between the There are several small differences between the

cipher suites available under SSLv3 and under TLS:cipher suites available under SSLv3 and under TLS: Key Exchange: TLS supports all of the key Key Exchange: TLS supports all of the key

exchange techniques of SSLv3 with the exchange techniques of SSLv3 with the exception of Fortezza.exception of Fortezza.

Symmetric Encryption Algorithms: TLS includes Symmetric Encryption Algorithms: TLS includes all of the symmetric encryption algorithms all of the symmetric encryption algorithms found in SSLv3, with thefound in SSLv3, with the

exception of Fortezza.exception of Fortezza.

Client Certificate TypesClient Certificate Types TLS defines the following certificate types to be requested in a TLS defines the following certificate types to be requested in a

certificate_request message: rsa_sign, dss_sign, rsa_fixed_dh, certificate_request message: rsa_sign, dss_sign, rsa_fixed_dh, andand

dss_fixed_dh. These are all defined in SSLv3. In addition, SSLv3 dss_fixed_dh. These are all defined in SSLv3. In addition, SSLv3 includes rsa_ephemeral_dh, dss_ephemeral_dh, and includes rsa_ephemeral_dh, dss_ephemeral_dh, and fortezza_kea.fortezza_kea.

Ephemeral Diffie-Hellman involves signing the Diffie-Hellman Ephemeral Diffie-Hellman involves signing the Diffie-Hellman parameters with either RSA or DSS; for TLS, the rsa_sign and parameters with either RSA or DSS; for TLS, the rsa_sign and dss_signdss_sign

types are used for that function; a separate signing type is not types are used for that function; a separate signing type is not needed to sign Diffie-Hellman parameters. TLS does not include needed to sign Diffie-Hellman parameters. TLS does not include thethe

Fortezza scheme.Fortezza scheme.

In the TLS certificate_verify message, the MD5 and In the TLS certificate_verify message, the MD5 and SHA-1 hashes are calculated only over SHA-1 hashes are calculated only over handshake_messages. Recall that for SSLv3, the hash handshake_messages. Recall that for SSLv3, the hash calculation also included the master secret and pads. calculation also included the master secret and pads. These extra fields were felt to add no additional security.These extra fields were felt to add no additional security.

As with the finished message in SSLv3, the finished As with the finished message in SSLv3, the finished message in TLS is a hash based on the shared message in TLS is a hash based on the shared master_secret, the previous handshake messages, and master_secret, the previous handshake messages, and a label that identifies client or server. The calculation is a label that identifies client or server. The calculation is somewhat different. For TLS, we havesomewhat different. For TLS, we have

Cryptographic ComputationsCryptographic Computations

The pre_master_secret for TLS is calculated in The pre_master_secret for TLS is calculated in the same way as in SSLv3. As in SSLv3, the the same way as in SSLv3. As in SSLv3, the master_secret in TLS is calculated as a hash master_secret in TLS is calculated as a hash function of the pre_master_secret and the two function of the pre_master_secret and the two hello random numbers. hello random numbers.

The form of the TLS calculation is different from The form of the TLS calculation is different from that of SSLv3 and is defined as follows:that of SSLv3 and is defined as follows:

The algorithm is performed until 48 bytes The algorithm is performed until 48 bytes of pseudorandom output are produced. of pseudorandom output are produced. The calculation of the key block material The calculation of the key block material (MAC secret keys, session encryption (MAC secret keys, session encryption keys, and IVs) is defined as followskeys, and IVs) is defined as follows

PaddingPadding In SSL, the padding added prior to encryption of user data is the In SSL, the padding added prior to encryption of user data is the

minimum amount required so that the total size of the data to beminimum amount required so that the total size of the data to be encrypted is a multiple of the cipher's block length. In TLS, the encrypted is a multiple of the cipher's block length. In TLS, the

padding can be any amount that results in a total that is a multiple of padding can be any amount that results in a total that is a multiple of thethe

cipher's block length, up to a maximum of 255 bytes. For example, if cipher's block length, up to a maximum of 255 bytes. For example, if the plaintext (or compressed text if compression is used) plus MACthe plaintext (or compressed text if compression is used) plus MAC

plus padding.length byte is 79 bytes long, then the padding length, in plus padding.length byte is 79 bytes long, then the padding length, in bytes, can be 1, 9, 17, and so on, up to 249. A variable paddingbytes, can be 1, 9, 17, and so on, up to 249. A variable padding

length may be used to frustrate attacks based on an analysis of the length may be used to frustrate attacks based on an analysis of the lengths of exchanged messages.lengths of exchanged messages.

Secure Electronic Secure Electronic TransactionTransaction

(SET)(SET)

Secure Electronic Transaction Secure Electronic Transaction (SET)(SET)

Developed by Visa and MasterCardDeveloped by Visa and MasterCard Designed to protect credit card Designed to protect credit card

transactionstransactions Confidentiality: all messages encryptedConfidentiality: all messages encrypted Trust: all parties must have digital Trust: all parties must have digital

certificatescertificates Privacy: information made available only Privacy: information made available only

when and where necessarywhen and where necessary

Participants in the SET System

SET Business RequirementsSET Business Requirements

Provide confidentiality of payment and Provide confidentiality of payment and ordering informationordering information

Ensure the integrity of all transmitted dataEnsure the integrity of all transmitted data Provide authentication that a cardholder is Provide authentication that a cardholder is

a legitimate user of a credit card accounta legitimate user of a credit card account Provide authentication that a merchant Provide authentication that a merchant

can accept credit card transactions can accept credit card transactions through its relationship with a financial through its relationship with a financial institutioninstitution

SMUSMU CSE 5349/7349CSE 5349/7349

SET Business Requirements (contSET Business Requirements (cont’’d)d)

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

Create a protocol that neither depends Create a protocol that neither depends on transport security mechanisms nor on transport security mechanisms nor prevents their useprevents their use

Facilitate and encourage interoperability Facilitate and encourage interoperability among software and network providersamong software and network providers

SMUSMU CSE 5349/7349CSE 5349/7349

SET Transactions

SMUSMU CSE 5349/7349CSE 5349/7349

SET TransactionsSET Transactions

The customer opens an account with a card issuer.The customer opens an account with a card issuer. MasterCard, Visa, etc.MasterCard, Visa, etc.

The customer receives a X.509 V3 certificate signed by a bank.The customer receives a X.509 V3 certificate signed by a bank. X.509 V3X.509 V3

A merchant who accepts a certain brand of card must possess two X.509 V3 A merchant who accepts a certain brand of card must possess two X.509 V3 certificates.certificates.

One for signing & one for key exchangeOne for signing & one for key exchange

The customer places an order for a product or service with a merchant.The customer places an order for a product or service with a merchant.

The merchant sends a copy of its certificate for verification.The merchant sends a copy of its certificate for verification.

SMUSMU CSE 5349/7349CSE 5349/7349

SET TransactionsSET Transactions

The customer sends order and payment The customer sends order and payment information to the merchant.information to the merchant.

The merchant requests payment authorization The merchant requests payment authorization from the payment gateway prior to shipment.from the payment gateway prior to shipment.

The merchant confirms order to the customer.The merchant confirms order to the customer. The merchant provides the goods or service to The merchant provides the goods or service to

the customer.the customer. The merchant requests payment from the The merchant requests payment from the

payment gateway.payment gateway.

SMUSMU CSE 5349/7349CSE 5349/7349

Key Technologies of SETKey Technologies of SET

Confidentiality of information: DESConfidentiality of information: DES Integrity of data: RSA digital signatures Integrity of data: RSA digital signatures

with SHA-1 hash codeswith SHA-1 hash codes Cardholder account authentication: Cardholder account authentication:

X.509v3 digital certificates with RSA X.509v3 digital certificates with RSA signatures signatures

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

Privacy: separation of order and payment Privacy: separation of order and payment information using dual signaturesinformation using dual signatures

SMUSMU CSE 5349/7349CSE 5349/7349

Dual SignaturesDual Signatures Links two messages securely but allows only one party to read Links two messages securely but allows only one party to read

each. each.

MESSAGE 1

DIGEST 1

NEW DIGEST

HASH 1 & 2WITH SHA

MESSAGE 2

DIGEST 2

CONCATENATE DIGESTSTOGETHER

HASH WITH SHA TOCREATE NEW DIGEST

DUAL SIGNATURE

PRIVATE KEYENCRYPT NEW DIGESTWITH SIGNER’S PRIVATE KEY

SMUSMU CSE 5349/7349CSE 5349/7349

Dual Signature for SETDual Signature for SET

Concept:Concept: Link Two Messages Intended for Two Different Link Two Messages Intended for Two Different Receivers:Receivers: Order Information (OI): Customer to MerchantOrder Information (OI): Customer to Merchant Payment Information (PI): Customer to BankPayment Information (PI): Customer to Bank

Goal:Goal: Limit Information to A “Need-to-Know” Basis: Limit Information to A “Need-to-Know” Basis: Merchant does not need credit card number.Merchant does not need credit card number. Bank does not need details of customer order.Bank does not need details of customer order. Afford the customer extra protection in terms of privacy by Afford the customer extra protection in terms of privacy by

keeping these items separate.keeping these items separate. This link is needed to prove that payment is intended for this This link is needed to prove that payment is intended for this

order and not some other one.order and not some other one.

SMUSMU CSE 5349/7349CSE 5349/7349

Why Dual Signature?Why Dual Signature?

Suppose that customers send the merchant two messages:Suppose that customers send the merchant two messages:

• The signed order information (OI).The signed order information (OI).

• The signed payment information (PI).The signed payment information (PI).

• In addition, the merchant passes the payment In addition, the merchant passes the payment information (PI) to the bank.information (PI) to the bank.

If the merchant can capture another order information (OI) If the merchant can capture another order information (OI) from this customer, the merchant could claim this order goes from this customer, the merchant could claim this order goes with the payment information (PI) rather than the original.with the payment information (PI) rather than the original.

SMUSMU CSE 5349/7349CSE 5349/7349

Dual Signature OperationDual Signature Operation

The operation for dual signature is as follows:The operation for dual signature is as follows: Take the hash (SHA-1) of the payment and order information.Take the hash (SHA-1) of the payment and order information. These two hash values are concatenated [H(PI) || H(OI)] and then These two hash values are concatenated [H(PI) || H(OI)] and then

the result is hashed.the result is hashed. CCuustomer encrypts the final hash with a private key creating the stomer encrypts the final hash with a private key creating the

dual signaturedual signature..

DS = EDS = EKRCKRC [ H(H(PI) || H(OI)) ] [ H(H(PI) || H(OI)) ]

SMUSMU CSE 5349/7349CSE 5349/7349

DS Verification by MerchantDS Verification by Merchant

The merchant has the public key of the customer obtained The merchant has the public key of the customer obtained from the customer’s certificate.from the customer’s certificate.

Now, the merchant can compute two values:Now, the merchant can compute two values:

H(PIMD || H(OI))H(PIMD || H(OI))

DDKUCKUC[DS][DS]

Should be equal!Should be equal!

SMUSMU CSE 5349/7349CSE 5349/7349

DS Verification by BankDS Verification by Bank

The bank is in possession of DS, PI, the message digest for OI The bank is in possession of DS, PI, the message digest for OI (OIMD), and the customer’s public key, then the bank can (OIMD), and the customer’s public key, then the bank can compute the following:compute the following:

H(H(PI) || OIMD)H(H(PI) || OIMD)

DDKUCKUC [ DS ] [ DS ]

SMUSMU CSE 5349/7349CSE 5349/7349

What did we accomplish?What did we accomplish?

The merchant has received OI and verified the signature.The merchant has received OI and verified the signature. The bank has received PI and verified the signature.The bank has received PI and verified the signature. The customer has linked the OI and PI and can prove the The customer has linked the OI and PI and can prove the

linkage.linkage.

SMUSMU CSE 5349/7349CSE 5349/7349

SET Supported TransactionsSET Supported Transactions

card holder registration card holder registration merchant registration merchant registration purchase request purchase request payment authorization payment authorization payment capture payment capture certificate query certificate query purchase inquiry purchase inquiry

purchase notification

sale transaction

authorization reversal

capture reversal

credit reversal

SMUSMU CSE 5349/7349CSE 5349/7349

Purchase RequestPurchase Request

Browsing, Selecting, and Ordering is DoneBrowsing, Selecting, and Ordering is Done Purchasing Involves 4 Messages:Purchasing Involves 4 Messages:

Initiate RequestInitiate Request Initiate ResponseInitiate Response Purchase RequestPurchase Request Purchase ResponsePurchase Response

SMUSMU CSE 5349/7349CSE 5349/7349

Purchase Request: Initiate RequestPurchase Request: Initiate Request

Basic Requirements:Basic Requirements: Cardholder Must Have Copy of Certificates for Cardholder Must Have Copy of Certificates for

Merchant and Payment GatewayMerchant and Payment Gateway Customer Requests the Certificates in the Initiate Customer Requests the Certificates in the Initiate

Request Message to MerchantRequest Message to Merchant Brand of Credit CardBrand of Credit Card ID Assigned to this Request/response pair by ID Assigned to this Request/response pair by

customercustomer NonceNonce

SMUSMU CSE 5349/7349CSE 5349/7349

Purchase Request: Initiate ResponsePurchase Request: Initiate Response

Merchant Generates a ResponseMerchant Generates a Response Signs with Private Signature KeySigns with Private Signature Key Include Customer NonceInclude Customer Nonce Include Merchant Nonce (Returned in Next Include Merchant Nonce (Returned in Next

Message)Message) Transaction ID for Purchase TransactionTransaction ID for Purchase Transaction

In Addition …In Addition … Merchant’s Signature CertificateMerchant’s Signature Certificate Payment Gateway’s Key Exchange CertificatePayment Gateway’s Key Exchange Certificate

SMUSMU CSE 5349/7349CSE 5349/7349

Purchase Request: Purchase RequestPurchase Request: Purchase Request

Cardholder Verifies Two Certificates Using Their CAs and Creates Cardholder Verifies Two Certificates Using Their CAs and Creates the OI and PI.the OI and PI.

Message Includes:Message Includes: Purchase-related InformationPurchase-related Information Order-related InformationOrder-related Information Cardholder CertificateCardholder Certificate

SMUSMU CSE 5349/7349CSE 5349/7349

Purchase RequestPurchase Request

The cardholder generates a one-time symmetric The cardholder generates a one-time symmetric encryption key, KS, encryption key, KS,

SMUSMU CSE 5349/7349CSE 5349/7349

Merchant Verifies Purchase RequestMerchant Verifies Purchase Request

When the merchant receives When the merchant receives the the Purchase Request Purchase Request messagemessage, it performs the , it performs the following actions:following actions:

Verify the cardholder Verify the cardholder certificates by means of certificates by means of its CA signatures.its CA signatures.

Verifies the dual Verifies the dual signature using the signature using the customer’s public key customer’s public key signature.signature.

SMUSMU CSE 5349/7349CSE 5349/7349

Merchant Verification (cont’d)Merchant Verification (cont’d)

Processes the order Processes the order and forwards the and forwards the payment information to payment information to the payment gateway the payment gateway for authorization.for authorization.

Sends a purchase Sends a purchase response to the response to the cardholder.cardholder.

SMUSMU CSE 5349/7349CSE 5349/7349

Purchase Response MessagePurchase Response Message

Message that Acknowledges the Order and References Message that Acknowledges the Order and References Corresponding Transaction NumberCorresponding Transaction Number

Block isBlock is Signed by Merchant Using its Private KeySigned by Merchant Using its Private Key Block and Signature Are Sent to Customer Along with Block and Signature Are Sent to Customer Along with

Merchant’s Signature CertificateMerchant’s Signature Certificate Upon ReceptionUpon Reception

Verifies Merchant CertificateVerifies Merchant Certificate Verifies Signature on Response BlockVerifies Signature on Response Block Takes the Appropriate ActionTakes the Appropriate Action

SMUSMU CSE 5349/7349CSE 5349/7349

Payment ProcessPayment Process

The payment process is broken down into two steps:The payment process is broken down into two steps: Payment authorizationPayment authorization Payment capturePayment capture

SMUSMU CSE 5349/7349CSE 5349/7349

Payment AuthorizationPayment Authorization

The merchant sends an The merchant sends an authorization request messageauthorization request message to the to the payment gateway consisting of the following:payment gateway consisting of the following:

Purchase-related informationPurchase-related information

• PIPI• Dual signature calculated over the PI & OI and Dual signature calculated over the PI & OI and

signed with customer’s private key.signed with customer’s private key.• The OI message digest (OIMD)The OI message digest (OIMD)• The digital envelopThe digital envelop

Authorization-related informationAuthorization-related information CertificatesCertificates

SMUSMU CSE 5349/7349CSE 5349/7349

Payment Authorization (cont’d)Payment Authorization (cont’d)

Authorization-related informationAuthorization-related information• An authorization block including:An authorization block including:

A transaction IDA transaction ID Signed with merchant’s private keySigned with merchant’s private key Encrypted one-time session keyEncrypted one-time session key

CertificatesCertificates• Cardholder’s signature key certificateCardholder’s signature key certificate• Merchant’s signature key certificateMerchant’s signature key certificate• Merchant’s key exchange certificateMerchant’s key exchange certificate

SMUSMU CSE 5349/7349CSE 5349/7349

Payment: Payment GatewayPayment: Payment Gateway

Verify All CertificatesVerify All Certificates Decrypt Authorization Block Digital Envelope to Obtain Symmetric Decrypt Authorization Block Digital Envelope to Obtain Symmetric

Key and Decrypt BlockKey and Decrypt Block Verify Merchant Signature on Authorization BlockVerify Merchant Signature on Authorization Block Decrypt Payment Block Digital Envelope to Obtain Symmetric Key Decrypt Payment Block Digital Envelope to Obtain Symmetric Key

and Decrypt Blockand Decrypt Block Verify Dual Signature on Payment BlockVerify Dual Signature on Payment Block Verify Received Transaction ID Received from Merchant Matches PI Verify Received Transaction ID Received from Merchant Matches PI

Received from CustomerReceived from Customer Request and Receive Issuer AuthorizationRequest and Receive Issuer Authorization

SMUSMU CSE 5349/7349CSE 5349/7349

Authorization ResponseAuthorization Response

Authorization Response MessageAuthorization Response Message Authorization-related InformationAuthorization-related Information Capture Token InformationCapture Token Information CertificateCertificate

SMUSMU CSE 5349/7349CSE 5349/7349

SET OverheadSET Overhead

Simple purchase transaction:Simple purchase transaction: Four messages between merchant and customerFour messages between merchant and customer Two messages between merchant and payment Two messages between merchant and payment

gatewaygateway 6 digital signatures6 digital signatures 9 RSA encryption/decryption cycles9 RSA encryption/decryption cycles 4 DES encryption/decryption cycles4 DES encryption/decryption cycles 4 certificate verifications4 certificate verifications

Scaling:Scaling: Multiple servers need copies of all certificatesMultiple servers need copies of all certificates

Secure Electronic Transactions Secure Electronic Transactions (SET)(SET)

open encryption & security specificationopen encryption & security specification to protect Internet credit card transactionsto protect Internet credit card transactions developed in 1996 by Mastercard, Visa etcdeveloped in 1996 by Mastercard, Visa etc not a payment systemnot a payment system rather rather a set of security protocols & formatsa set of security protocols & formats

secure communications amongst partiessecure communications amongst parties trust from use of X.509v3 certificatestrust from use of X.509v3 certificates privacy by restricted info to those who need itprivacy by restricted info to those who need it

SET ComponentsSET Components

SET TransactionSET Transaction

1.1. customer opens accountcustomer opens account2.2. customer receives a certificatecustomer receives a certificate3.3. merchants have their own certificatesmerchants have their own certificates4.4. customer places an ordercustomer places an order5.5. merchant is verifiedmerchant is verified6.6. order and payment are sentorder and payment are sent7.7. merchant requests payment authorizationmerchant requests payment authorization8.8. merchant confirms ordermerchant confirms order9.9. merchant provides goods or servicemerchant provides goods or service10.10. merchant requests paymentmerchant requests payment

Dual SignatureDual Signature

customer creates dual messagescustomer creates dual messages order information (OI) for merchantorder information (OI) for merchant payment information (PI) for bankpayment information (PI) for bank

neither party needs details of otherneither party needs details of other but but mustmust know they are linked know they are linked use a dual signature for thisuse a dual signature for this

signed concatenated hashes of OI & PIsigned concatenated hashes of OI & PIDS=E(PRDS=E(PRcc, [H(H(PI)||H(OI))]), [H(H(PI)||H(OI))])

SET Purchase RequestSET Purchase Request

SET purchase request exchange SET purchase request exchange consists of four messagesconsists of four messages

1.1. Initiate Request - get certificatesInitiate Request - get certificates

2.2. Initiate Response - signed responseInitiate Response - signed response

3.3. Purchase Request - of OI & PIPurchase Request - of OI & PI

4.4. Purchase Response - ack orderPurchase Response - ack order

Purchase Request – Purchase Request – CustomerCustomer

Purchase Request – MerchantPurchase Request – Merchant

1.1. verifies cardholder certificates using CA sigsverifies cardholder certificates using CA sigs2.2. verifies dual signature using customer's public verifies dual signature using customer's public

signature key to ensure order has not been signature key to ensure order has not been tampered with in transit & that it was signed tampered with in transit & that it was signed using cardholder's private signature keyusing cardholder's private signature key

3.3. processes order and forwards the payment processes order and forwards the payment information to the payment gateway for information to the payment gateway for authorization (described later)authorization (described later)

4.4. sends a purchase response to cardholdersends a purchase response to cardholder

Purchase Request – MerchantPurchase Request – Merchant

Payment Gateway Payment Gateway AuthorizationAuthorization

1.1. verifies all certificatesverifies all certificates2.2. decrypts digital envelope of authorization block to obtain decrypts digital envelope of authorization block to obtain

symmetric key & then decrypts authorization blocksymmetric key & then decrypts authorization block3.3. verifies merchant's signature on authorization blockverifies merchant's signature on authorization block4.4. decrypts digital envelope of payment block to obtain decrypts digital envelope of payment block to obtain

symmetric key & then decrypts payment blocksymmetric key & then decrypts payment block5.5. verifies dual signature on payment blockverifies dual signature on payment block6.6. verifies that transaction ID received from merchant verifies that transaction ID received from merchant

matches that in PI received (indirectly) from customermatches that in PI received (indirectly) from customer7.7. requests & receives an authorization from issuerrequests & receives an authorization from issuer8.8. sends authorization response back to merchantsends authorization response back to merchant

Payment CapturePayment Capture

merchant sends payment gateway a merchant sends payment gateway a payment capture requestpayment capture request

gateway checks requestgateway checks request then causes funds to be transferred to then causes funds to be transferred to

merchants accountmerchants account notifies merchant using capture responsenotifies merchant using capture response

SummarySummary

have considered:have considered: need for web securityneed for web security SSL/TLS transport layer security protocolsSSL/TLS transport layer security protocols SET secure credit card payment protocolsSET secure credit card payment protocols

CV G. Web Security Web now widely used by business, government, individuals but Internet & Web are vulnerable have a variety of threats integrity.

Documents