8.3 Remote payment method based on TLS

The SSL protocol [17] was specified by Netscape Communications, and is actually at version 3.0. The current TLS protocol [18], version 1.0, is elaborated by the IETF, and is based on the SSL version 3.0. Like SSL, TLS is composed of two layers : the handshake protocol and the record protocol. In the remainder of the section we refer only to the TLS protocol and its use for remote payments.

TLS-based solutions are suitable for implementation on unique Internet channel devices, where both the browsing/ordering phase and the payment phase are completed during the same session on the same channel. These solutions are suitable for small transaction amounts, considering the security limitations of the TLS protocol, as described in Section 8.3.3.

8.3.1 TLS handshake protocol

The TLS handshake protocol allows the server and ( optionally ) the client to authenticate each other. It also allows the negotiation of a symmetric encryption algorithm, with the corresponding cryptographic keys. The negotiated keys are made available to the record protocol operation for any connection established during a secure session between the browser and the server. The handshake protocol is described below, and is schematized in Figure 8.3. We use the notations and terminology explained in Appendix D, Sections D.1 and D.3.

Figure 8.3: Overview of the TLS handshake protocol.

The client forwards a set of CipherSuite proposals and a random number R_c to the server. Each CipherSuite includes the types of cryptographic algorithms together with the length of their parameters. These algorithms refer to key establishment, symmetric encryption, and the type of MDC used for deriving a keyed MAC (see Appendix D, Section D.2.2). In the remainder of the protocol we assume that RSA is used for key establishment. Note that Diffie-Hellman is a possible alternative algorithm for key establishment, which is accepted by the TLS.

The server answers with its own set of preferred cipher suites, and a random number generated by itself, denoted R_s . The server also includes an RSA certificate Cert_Server = Cert _CA ( KE ) on its public encryption key, denoted KE . A certification authority accepted as a TTP by both the client and the server signs this certificate.

Using the public verification key KV _CA of the CA, the client verifies Cert_Server and retrieves the server's authentic KE . It is assumed that KV _CA is installed in both the client and the server.

If the server requires the authentication of the client, which is optional, the client has to retrieve the public key certificate Cert_Client = Cert _CA ( KV ), issued by the same CA, on the client's public verification key KV . The client uses the corresponding private signing key KS to generate a signature of the client, Sign_Client = RSA ( KS )[ Msg ] on a message Msg that includes the random numbers created by both the server ( R_s ) and the client ( R_c ).

The client generates the so-called premaster secret, denoted pms , and creates an RSA digital envelope that wraps it, C = RSA ( KE )[ pms ]. The premaster secret is used together with R_s and R_c to compute the master secret key K = SHA ( pms, R_c, R_s ).

The client forwards Cert_Client, Sign_Client , and C to the server.

The server verifies the Cert_Client , using the public verification key KV _CA of the CA, and retrieves the client's authentic KV . The server uses it to verify the signature produced by the client Sign_Client , and if the verification is correct it accepts the authenticity of the client.

Using its private decryption key KD , the server unwraps the RSA digital envelope containing the premaster secret, i.e., pms = RSA( KD )[ C ]. The premaster secret is used in the same way as explained for the client to compute the master secret key K . The key K together with R_s and R_c are provided to the TLS record protocol of the server for the duration of a session.

The server also computes a key confirmation value V as the result of a one-way function (e.g., SHA), on the recovered master secret key and the message Msg [i.e., V = SHA( K, Msg )]. The server forwards this value to the client.

The client verifies the key confirmation value, and if this verification passes , it accepts the authenticity of the server, since only it would have been able to compute the premaster key from the RSA digital envelope. The key K together with R_s and R_c are provided to the TLS record protocol of the client for the duration of a session.

8.3.2 TLS record protocol

The TLS record protocol takes a message of arbitrary size to be transmitted, fragments it into appropriate blocks, optionally compresses the data, computes a MAC, enciphers, and transmits the result. A sequence number is also inserted for countering attempts to replay blocks or alter the order of the transmitted blocks. From the master secret key K , together with R_s and R_c , which are provided by the TLS handshake protocol, the TLS record protocol generates keys, initialization vectors for the CBC mode of the block cipher, and secrets for the keyed MAC computation. These cryptographic parameters are subsequently used for symmetric encryption, implementing the secure messaging for confidentiality service (CS2), and MAC computation, implementing the data authentication of exchanged messages (AS1). When the data authentication service is implemented with a MAC, the service is often referred to as secure messaging for integrity and authentication.

The messages that are effectively secured at the level of the TLS record protocol are the content request of the cardholder's browser, specifying the URL of the concerned merchant's Web page, and the commercial offer of the merchant returned in the content response of his Web server. The commercial offer can include the order form. After decryption by the cardholder's browser, the cardholder fills in the order form and the appropriate payment information, which is again encrypted and sent to the merchant's Web server.

8.3.3 Security limitations of the TLS protocol

In terms of security services, as introduced in Section 8.2.2, the TLS handshake protocol provides server authentication (ES1), and optionally, client authentication (ES2).

The client authentication is based on a digital signature “based DDA mechanism (as explained in Appendix D, Section D.7.2). The client computes the digital signature Sign_Client = RSA ( KS )[ Msg ] on a view of the messages exchanged with the server, using the client's private signing key KS . A CA accepted on the Internet issues the certificate Cert_Client = Cert _CA ( KV ) of the corresponding public verification key KV of the client.
The server authentication is based on a MAC-based DDA mechanism (as explained in Appendix D, Section D7.1) with the master secret key K , derived from a premaster secret key proposed by the client. The premaster secret key is forwarded to the server in a digital envelope created with the server's public encryption key, KE , which is certified by the same CA on the Internet.
This key establishment mechanism for the master secret key K is essential for the implementation by the TLS record protocol of the confidentiality of the ordering phase, of the secure messaging for confidentiality (CS2), and of the secure messaging for integrity and authentication (AS1). These services successfully counteract threats generated by external attackers , but they are powerless against attacks mounted by the entities involved in the remote transaction.

The fact that a CA on the Internet authenticates a merchant's server does not provide any security against attempts of impersonating the electronic decal of a payment card brand (T6). Similarly, the client's certificate provides no protection against attempts to use invalid payment cards (T7) or against fraudulent transactions (T8). This is mainly because the CA that issues the server and client certificates has no connection with the financial institutions either issuing payment cards or acquiring transactions performed with them. The certificates refer only to the fact that the Web server and/or the Web client can legitimately be connected on the Web, but it does not legitimate the two entities to participate in a certain application, whether it is payment or not.

The TLS provides neither the non- repudiation service (NS1) nor the confidentiality of the financial data of the cards after it is stored on the merchant's computer (CS3). This makes this solution rather sensitive to fraud both by the cardholder, who may deny having performed a transaction (T9), and by the merchant who can abuse the financial information of cards stored on his Web server (T12).