8.4 SET-based solutions

8.4 SET-based solutions

We saw in the previous section that the TLS protocol can provide enough trust that the cardholder's Web browser and the merchant's Web server are legitimate Internet users. The TLS also allows the establishment of a confidential channel between them. Thus, TLS is suitable for the secure completion of the browsing/ordering phase of a remote transaction, protecting the consumer against outsiders' sniffing or against merchant's Web server impersonation. When it comes to securing the payment phase, however, the TLS-based solutions rely on the assumption that the cardholder and the merchant know and trust each other.

SET does not really compete with TLS, since it secures the payment phase of the transaction. It provides enough assurance that a merchant and, optionally , a cardholder have a valid relationship with a payment card brand, via their acquirer and issuer, respectively. All the parties are validated via their SET digital certificates, which are issued under the trust hierarchy established by the payment card brand. Moreover, the payment card data (credit card number, expiration date) are encrypted such that the merchant's server never sees them in clear. Within the boundaries of some limitations, cardholder authentication and non- repudiation of the transaction are also provided.

8.4.1 SET model

The SET payment model can be obtained from the model of remote payment card processing presented in Figure 8.1. In the SET model, the cardholder has a dual Internet channel device (e.g., a PC running a TLS-enabled Web browser for completing the browsing/ordering phase and the SET payment application). SET can be regarded as a helper for the Web browser, which is used for the completion of the payment phase. The cardholder's PC talks to the merchant's server. This server further communicates with the payment gateway. This gateway can be seen as a dual port computer, which on one hand acts as an e-commerce terminal for the acquirer network and on the other as an AH for the merchant server. The SET model is schematized in Figure 8.4.

Figure 8.4: SET model for remote card payments.

8.4.2 Setup of the SET payment scheme

In the framework of the SET payment system, the cardholder, the merchant, and the payment gateway, need cryptographic material to participate in a SET payment transaction.

• The cardholder has a signature key pair, which consists of a private signing key and the corresponding public verification key ( cKS, cKV ).

• The merchant has both a signature key pair ( mKS, mKV ) and a keyexchange key pair, which is composed of a private decryption key and a public encryption key ( mKD, mKE ).

• The payment gateway has also a signature key pair ( pKS, pKV ) and a key-exchange key pair ( pKD, pKE ).

8.4.2.1 Public key certificates

Each aforementioned entity uses its private signing key eKS to produce a digital signature, which anyone can verify using the corresponding public verification key eKV . The digital signature mechanism requires a CA to guarantee the authenticity of the entity's public verification key with a signature public key certificate (see Appendix D, Section D.4). The certificate itself is a digital signature with the CA's private signing key, on the entity's public verification key eKV and other data characterizing each entity (i.e., Cert_eKV = Cert ( caKS )[ eKV , entity_data]). Note that " e " abbreviates the type of entity: " c " stands for the cardholder, " m " stands for the merchant, and " p " stands for the payment gateway.

The correct verification of an entity's signature public key certificate vouches that:

• The CA guarantees that the entity_data included in the certificate is data that characterizes the entity. Any attempt at modifying these characteristics leads to an incorrect verification of the certificate.

• The public verification key of the entity is genuine and can be further involved in the verification of any digital signature produced by that entity.

Any sender can create a digital envelope with the receiver's public encryption key eKE . Only the receiver that has the corresponding private decryption key eKD can open the digital envelope. The digital envelope contains a secret session key SSK proposed by the sender to receiver, which can implement a confidential channel between them, where bulk data can be encrypted. If the receiver is the merchant, the sender uses mKE as the public encryption key; if the receiver is the payment gateway, the sender uses pKE as the public encryption key. To avoid a man-in-the-middle attack (see Appendix D, Section D.4.1), a CA must guarantee the authenticity of the receiver's public verification key with a key-exchange public key certificate (see Appendix D, Section D.4). The certificate itself is a digital signature with the CA's private signing key, on the receiver's public encryption key eKE and other data characterizing each entity (i.e., Cert_eKE = Cert ( caKS )[ eKE , entity_data]). Note that " e " abbreviates the type of entity: " m " stands for merchant, and " p " stands for the payment gateway.

The correct verification of an entity's key-exchange public key certificate vouches that:

• The CA guarantees that the entity_data included in the certificate is data that characterizes the entity.

• The public encryption key of the receiving entity is genuine and can be further involved in producing digital envelopes destined to the receiving entity.

8.4.2.2 SET certification hierarchy

In the SET model, the cardholder, the merchant, and the payment gateway are situated in different security domains. The cardholder recognizes the cardholder CA (CCA), the merchant recognizes the merchant CA (MCA), while the payment gateway trusts the payment gateway CA (PCA). It is common that an issuer plays the role of the CCA for its cardholders, while an acquirer plays the role of both an MCA and a PCA for its merchants and their associated payment gateways.

• The CCA uses its private signing key ccaKS to compute the Cert_cKV for cardholders. Anyone can use the CCA's corresponding public verification key ccaKV to verify Cert_cKV and to obtain an authentic copy of cKV .

• The MCA uses its private signing key mcaKS to compute the Cert_mKV and Cert_mKE for merchants. Anyone can use the MCA's corresponding public verification key mcaKV to verify Cert_mKV and Cert_mKE ,to obtain an authentic copy of mKV and mKE , respectively.

• The PCA uses its private signing key pcaKS to compute the Cert_pKV and Cert_pKE for payment gateways. Anyone can use the PCA's corresponding public verification key pcaKV to verify Cert_pKV and Cert_pKE , to obtain an authentic copy of pKV and pKE , respectively. Note that entity_data included in the Cert_pKE may contain information about the supplementary processing facilities offered by the payment gateway, like support for on-line PIN and chip related data (see Section 8.6.2).

In order to enforce trust among entities in different security domains, a certification hierarchy is needed that allows entities in one security domain to verify certificates issued in another domain. A card brand can play the role of a brand CA, which is recognized and trusted by the cardholder CA, merchant CA, and payment gateway CA. This is a natural organization since issuers and acquirers respectively issuing and accepting cards of a certain brand are both clients of the same card association that promotes the respective card brand. Each brand CA has its own signature key pair ( bKS, bKV ), whose private signing key bKS is used to compute signature public key certificates for the public verification keys of all the subordinated organizations (i.e., Cert_ccaKV, Cert_mcaKV , and Cert_pcaKV , respectively).

The SET certification hierarchy could have at its root a SET industry CA, which can be a certification authority run by the SET consortium. This is the highest CA that is recognized and trusted by all the card brands adopting the SET payment standard. Each card brand certifies its public verification key bKV with the SET industry CA, which uses its signing private key rootKS to compute the Cert_bKV . The corresponding public verification key rootKV is widely known and is embedded in any SET application software. The SET certification hierarchy is schematized in Figure 8.5.

Figure 8.5: SET certification hierarchy.

We define the CCA certification chain as the set of certificates Cert_ccaKV and Cert_bKV , the MCA certification chain as the set of certificates Cert_ mcaKV and Cert_bKV , and the PCA certification chain as the set of certificates Cert_pcaKV and Cert_bKV .

In order to obtain an authentic copy of the public verification key of any of the entities CCA, MCA, or PCA, someone traverses the corresponding certification chain according to the following algorithm:

• Use rootKV , which is available to any SET software implementation, to check Cert_bKV . Obtain an authentic copy of the brand CA's public verification key bKV .

• Use the previously obtained bKV to check:

  • ( CCA certification chain ) Cert_ccaKV . Obtain an authentic copy of the CCA's public verification key ccaKV .

  • ( MCA certification chain ) Cert_mcaKV . Obtain an authentic copy of the MCA's public verification key mcaKV .

  • ( PCA certification chain ) Cert_pcaKV . Obtain an authentic copy of the PCA's public verification key pcaKV .

8.4.3 Registration of participants

Before being able to participate in any SET payment transaction, cardholders, merchants, and payment gateways must certify their public verification keys and public encryption keys with the appropriate CA. To this end, a certificate requesting entity and the CA run a registration protocol. Since the involvement of an EMV ¢ chip card in the SET payment transaction changes neither the cardholder registration nor the merchant registration procedures, we do not detail the corresponding protocols. We stress the security significance of the cardholder's certificate and merchant's certificates.

8.4.3.1 Cardholder registration

The cardholder's SET software generates the signature key pair ( cKS, cKV ) and transmits to the CCA the cKV item. The CCA uses ccaKS to compute Cert_cKV = Cert ( ccaKS )[ cKV _, card_data ]on cKV and on some data items that characterize the cardholder's account, referred to as card_data . This certificate, together with the CCA certification chain, is returned to the cardholder access device, which securely stores them for further use.

The cardholder's signature public key certificate Cert_cKV is the electronic representation of the payment card. This certificate is issued such that card_data contains neither the card's account number (PAN) nor its expiration date ( CardExpiry ) in clear, but rather it contains the hash value of these two items concatenated with a secret value known only to the cardholder's software PANSecret . This secret value prevents guessing attacks on the PAN in the Cert_cKV .

Upon receipt and verification of the certificate, the merchant is assured at a minimum that the issuer, playing the role of the CCA, has validated the cardholder's account number ”but the merchant cannot derive any information about the card data. The cardholder's signature public key certificate implements the cardholder account authentication (ES4) and the confidentiality of stored card data in the merchant's Web server (CS3). If the account number, expiration date, and the secret value are known, the link to the certificate can be proven. Within SET, the cardholder provides the account information and the secret value to the payment gateway where the link is verified .

8.4.3.2 Merchant registration

The merchant's SET software generates the signature key pair ( mKS, mKV ) and the key-exchange key pair ( mKD, mKE ) and transmits to the MCA the public items mKV and mKE . The MCA uses mcaKS to compute the signature public key certificate Cert_mKV = Cert ( mcaKS )[ mKV _, merchant_data ]on mKV and on some data items that characterize the merchant's account, referred to as merchant_data . Among these data items, there is the merchant country code item. Similarly, the MCA computes the key-exchange public key certificate Cert_mKE = Cert ( mcaKS )[ mKE _, merchant_data ]on mKE and merchant_ data . Both certificates Cert_mKV and Cert_mKE together with the MCA certification chain are returned to the merchant access device, which securely stores them for further use.

The merchant's signature/key-exchange public key certificates function as the electronic substitute of the payment brand decal, which guarantees the relationship between the merchant and the acquirer concerning the acceptance of the payment card brand. These certificates implement the merchant authentication (ES3).

8.4.4 Secure SET channel over insecure networks

SET creates a secure channel over the insecure Internet, referred to as a SET channel. This channel offers the following features: data authentication (data integrity and origin authentication), entity authentication, nonrepudiation, and confidentiality.

8.4.4.1 Establishment of a SET authentic and/or confidential channel

The SET channel is established between a proving entity and a verifying entity, belonging to separate security domains, guaranteed by CA1 and CA2, respectively. Both certification authorities are hierarchically subordinated to the same brand CA and have appropriate certification chains to the SET industry CA. Both the proving and the verifying entity run the SET software, which has an authentic copy of the rootKV . The proving entity has a signature key pair ( eKS, eKV ) and a signature public key certificate signed by CA1 (i.e., Cert 1 _eKV = Cert ( ca 1 KS )[ eKV , _proving entity_data ]). The verifying entity has a key-exchange key pair ( eKD, eKE ) and the corresponding certificate from CA2 (i.e., Cert 2 _eKE = Cert ( ca 2 KS )[ eKE , _receiving entity_data ]). The proving entity sends a message M , which is part of the SET payment transaction processing, to the verifying entity. The SET makes sure that there are no messages in the SET payment transaction processing that are identical, so that replay attacks are not possible. The protocol for establishing the SET channel between the two parties is as follows :

• The verifying entity retrieves the Cert 2 _eKE and the CA2 certification chain. It sends both items to the proving entity.

• The proving entity performs the following processing to establish the SET channel, which consists of the superposition of a certificate validation channel, an authentic channel, and a confidential channel:

  1. Use the rootKV to traverse the CA2 certification chain. An authentic copy of the CA2's public verification key ( ca 2 KV ) is obtained.

  2. Use ca 2 KV to verify the key-exchange public key certificate Cert 2 _eKE . An authentic copy of the public encryption key eKE of the verifying entity is obtained.

  3. Create a digital signature on the SET transaction data M .

     • Compute the hash value of the message M through the collision-resistant hash function H [i.e., h =H( M )].

     • Retrieve the private signing key eKS and call the RSA function to compute the digital signature S = RSA( eKS )[ h ]. Since the messages in any SET transaction are different than the messages in any other transaction, the digital signature can be assimilated with a dynamic authenticator produced by a digital-based DDA mechanism (see Appendix D, Section D.7.2).

     • Retrieve the signature public key certificate Cert 1 _eKV and the CA1 certification chain.

  4. Create a confidential channel with the verifying entity.

     • Generate at random a session secret key SSK to be used in connection with the DES block cipher.

     • Use the previously generated key to compute C' = DES( SSK ) [ bulk_data ], where the bulk data is composed of the transaction data ( M ), the digital signature S on it, the signature public key certificate Cert 1 _eKV , and the CA1 certification chain. The cryptogram C' protects the confidentiality of the transaction data and guarantees that an external attacker cannot exploit any information he could obtain by verifying the digital signature S , the signature public key certificate Cert _ eKE , or any other certificates in the chain of CA1.

     • Use the authentic copy of the receiving entity's public encryption key eKE (obtained in step 2) to create an RSA digital envelope C containing the session secret key, C = RSA ( eKE )[ SSK ].

  5. Send C ' and C to the verifying entity.

• The verifying entity performs the following processing:

  6. Use the private decryption key eKD to decrypt the digital envelope C , to obtain the session secret key, SSK = RSA( eKD )[ C ].

  7. Use SSK to decrypt the cryptogram C' and to obtain the bulk data (i.e., bulk_data = DES ^{ˆ’ 1} ( SSK )[ C' ]).

  8. Parse the bulk data in the transaction data ( M ), the digital signature S on it, the signature public key certificate Cert 1 _eKV , and the CA1 certification chain.

  9. Use the rootKV to traverse the CA1 certification chain. An authentic copy of the CA1's public verification key ( ca 1 KV ) is obtained.

  10. Use ca 1 KV to verify the signature public key certificate Cert 1 _eKV . An authentic copy of the public verification key eKV of the proving entity is obtained.

  11. Use eKV to call the RSA function on the digital signature received from the proving entity and to obtain the witness hash value h of the message M, h = RSA ( eKV )[ S ].

  12. Compute the hash value h' on the transaction data M as obtained from the parsing of the bulk data. Accept the authenticity of the proving entity if h' = h .

Figure 8.6 outlines the establishment of a SET channel between two parties.

Figure 8.6: Establishment of a SET channel.

8.4.4.2 Data authentication

The data integrity and data origin authentication of the message M is provided. Indeed, the use of a collision-resistant hash function H for formatting the messages to be signed guarantees that any modification of M will lead to a different hash value computed by the verifying entity, which will not pass the verification predicate. The data origin authentication is related to the impossibility that a third party that does not know the private signing key can create a digital signature that passes the verification predicate. This service guarantees the data authentication of exchanged messages (AS1).

8.4.4.3 Entity authentication

SET authenticates the entities participating in a remote transaction:

• Cardholder to merchant (optional);

• Cardholder to payment gateway (optional);

• Merchant to cardholder;

• Mutual authentication between merchant and payment gateway.

To this end, each proving entity computes a digital signature. The successful verification of this signature proves to the verifying entity that only the holder of the private signing key could have signed the message, which includes a freshly generated challenge. However, someone could question the degree of assurance that the holder of the signing private key is one and the same as the legitimate entity to which the corresponding signature public key certificate was issued during registration (Section 8.4.3). Therefore, public key signature mechanisms are critically dependent on the security of the generation and storage of the private signing keys. Merchants' servers and payment gateway computers should employ cryptographic modules to perform cryptographic functions and to generate and store signing private keys and decryption private keys.

The degree of assurance whether SET provides the cardholder authentication service (ES5) depends on the evaluator 's belief about the possibility of mounting Trojan horse attacks (threat T11) or about the effectiveness of the Authenticode security service (see AS2). The involvement of an EMV ¢ chip card in the architecture of the cardholder access device enforces the tamper-resistance security service (TS1), which would eliminate the suspicion about both the card authentication and cardholder verification (see Section 8.5.3).

8.4.4.4 Non-repudiation

A digital signature produced by the cardholder access device on a message M including enough details about the conditions of the remote transaction could also serve to provide the cardholder non-repudiation service (NS1). Since only the cardholder could compute that value, he or she cannot later deny her participation in the transaction. Similarly to the entity authentication service, the question is whether a court would accept the possibility that someone else than the legitimate cardholder has triggered the computation of the digital signature on behalf of the cardholder, or whether a skilled attacker could have cloned the cardholder's signing private key.

8.4.5 SET dual signatures

The provision of the confidentiality of the stored card data in the merchant's server (CS3) requires some precautions in the design of the cryptographic protocols.

First, we have already stressed in Section 8.4.3 that the cardholder's signature public key certificate is issued such that it contains neither the card's account number nor its expiration date in clear.

Second, during a payment transaction with SET, the cardholder has to produce a signature with his or her private signing key on the transaction data, which serves as a simultaneous dynamic authenticator for the cardholder authentication both towards the merchant and towards the payment gateway. This data includes two items ”namely, the order instruction and the payment instruction.

• The order instruction ( OIData ) contains the details about the products or services to be purchased.

• The payment instruction ( PIData ) contains details about the cardholder's account (credit card number, expiration date) to which the public verification key was linked, through the cardholder's signature public key certificate.

To implement the confidentiality of the stored card data (CS3), the merchant should not see the payment instruction. At the same time, the privacy of the cardholder would be better protected if the payment gateway does not see the order instruction, admitting that banks would be interested about how their clients spend money. At the same time, the payment instruction and the order instruction must be linked, such that the payment is transferred to the merchant only if the cardholder accepts the offer. In order to fulfill all these goals, the SET uses the dual signature mechanism. The principle of this mechanism and details on how it is used in the SET payment transaction processing are presented in the next section.

8.4.6 SET payment method

An overview of a remote transaction, the payment phase of which is completed with the SET payment method, is presented in Figure 8.7.

Figure 8.7: Remote transaction with SET payment method.

8.4.6.1 Overview of a remote transaction with SET payment

During the browsing/ordering phase, the cardholder accesses the Web server of a merchant, browsing the offered products or services. The cardholder fills in an order form, specifying his or her choice and indicating the credit card brand chosen for payment. Although SET does not specify the information, a Web server has to send to the cardholder's SET payment software, following the completion of the browsing/ordering phase, some data items that are recommended in the SET initiation message [19]:

• Order description ( OD ): This item describes the product and/or services acknowledged by the cardholder in his or her order form.

• Purchase Amount ( PurchAmt ): This data item indicates both an amount and its currency code. The amount represents the total price to be paid for the selected products and services, to which handling and shipping costs are added.

• The acceptable payment brands for the merchant: The brand identifiers can be directly included in the SET initiation message. Supplementary, the URL in the SET-Brand header, which is included in the initiation message, references the directory on the merchant server where the cardholder system can access the file containing the acceptable brands for the merchant.

SET specifies only the protocol of the payment phase in a remote transaction. The protocol can be split into three logical stages:

1. Purchase processing is the stage in which the cardholder confirms the order and supplies the payment instruction, which is inaccessible to the merchant and is further tunneled to the payment gateway. The step is accomplished through the exchange of the Purchase Initiate Request and Purchase Initiate Response (PinitReq/PinitRes) messages, and of the purchase request and purchase response (PReq/PRes) messages.

2. Payment authorization is the stage in which the merchant accepting the order of the cardholder creates an authorization request (AuthReq) message, tunneling the cardholder's payment instruction, and forwarding it the to the payment gateway. The payment gateway creates an authorization request message (1100) and forwards it to the appropriate bankcard network, which treats it similarly to the case of face-to-face transactions. After the appropriate issuer decides upon the approval or the rejection of a guarantee of funds, it elaborates an authorization request response message (1110). This message is returned to the payment gateway, which further elaborates an authorization response (AuthRes) towards the merchant. If the issuer approves the transaction, the merchant ships the goods or performs the services indicated in the order.

3. Payment capture is the stage in which the merchant triggers the payment from the payment gateway, of a transaction that was previously authorized. The payment gateway translates a capture request message into funds transfer to the merchant's account. At the end the merchant is informed about the way the capturing stage is completed, through the capture response message.

The following sections describe the purchase processing and payment authorization stages. The level of detail is one that we believed will allow the reader to understand the extension of the SET protocol to support the transport of EMV ¢ related data. We briefly explain the payment capture phase.

8.4.6.2 Purchase processing

PinitReq The purchase processing stage of the SET payment starts with the cardholder device sending the purchase initiate request (PInitReq) message to the merchant. The PInitReq message specifies the context of a transaction, including:

• Identifier of the credit card brand to be used ( BrandID );

• Bank identification number ( BIN ) from the cardholder's account number (first six digits);

• Cardholder's preferred language;

• RRPID identifier of the PInitReq/PInitRes pair;

• Challenge r_c to guarantee the freshness of the merchant's signature.

• Information about the certificates already available in the cardholder device.

PinitRes The merchant receives the PInitReq message and elaborates the payment initiate response (PInitRes):

• Create the response data PInitResData, including the same RRPID as for the request, a transaction identifier ( TransID ) specifying the current date (PReqDate), the cardholder's challenge r_c , and a fresh challenge of the merchant r_m for the subsequent signature produced by the cardholder.

• Compute S 1 = RSA( mKS )[H(PInitResData)], which establishes a SET channel providing only authenticity without confidentiality (Step 3, first two bullets, in Section 8.4.4.1).

• Search in PInitReq the information about the certificates the cardholder already stored in his or her device. It could be that the certificates of the merchant and/or payment gateway are already available in the cardholder device. If this is not the case, retrieve the merchant's signature public key certificate Cert_mKV = Cert ( mcaKS )[ mKV _, merchant_data ] with the MCA certification chain and/or the payment gateway's key-exchange public key certificate Cert_pKE = Cert ( pcaKS )[ pKE, payment_gateway_data ] with the PCA certification chain.

• Compose PInitRes from PInitResData, and S 1. Depending on the certificates already existing with the cardholder, add the appropriate items among the following Cert_mKV , MCA certification chain, Cert_pKE , PCA certification chain.

• Send PInitRes to the cardholder.

PReq After receiving the PInitRes, the cardholder first verifies this response and elaborates a purchase request (PReq) message, as follows.

• Verify the authenticity of the merchant and the integrity of the information received.

  • Check the authenticity of the merchant's electronic brand decal. Traverse the MCA certification chain from the rootKV to obtain an authentic copy of mcaKV . Use this key to validate Cert_mKV and obtain an authentic copy of the merchant's public verification key mKV .

  • Use mKV to dynamically authenticate the merchant and to check the integrity of his response. Compute h = RSA( mKV )[ S 1] and compare it with the hash value h' = H(PInitResData) computed locally by the cardholder. If they are equal, the cardholder is assured about the authenticity of the merchant and the integrity of PInitRes.

• Traverse the PCA certification chain from the rootKV to obtain an authentic copy of pcaKV . Use this key to validate Cert_pKE and obtain an authentic copy of the payment gateway's public encryption key pKE .

• Generate the order instruction part of the PReq message, OIData , using the information obtained in the SET initiation message. It includes the transaction identifier ( TransID ), the identifier of the card's brand (BrandID), the BIN of the issuer of the card, the hash value HOD of a byte string HODInput , and the merchant's challenge r_m , which guarantees the uniqueness of the SET transaction data. The HODInput includes the OD and the purchase amount ( PurchAmt ). Thus, the OIData does not contain the OD or PurchAmt in clear, since OIData is not transmitted on a confidential channel to the merchant.

• Generate the payment instruction part of the PReq message, PIData .It consists of the PIHead and PANData items. The PIHead includes:

  • TransID: This allows the payment gateway to link the OIData and PIData , coming from two different sources (the merchant and the cardholder, respectively) in a unique purchase request message.

  • HOD, PurchAmt , merchant's identifier.

  • A keyed MAC (HMAC) of the identifier of the transaction record in the merchant's database XID with the secret generated by the cardholder software during the registration protocol with the CCA, PANSecret .

    The PANData encompasses the credit card number (PAN), the expiration date ( CardExpiry ), PANSecret , and EXNonce , which is a fresh random.

• Produce a dual signature DS . To this end, compute H( OIData ) and H( PIData ), concatenate them, and compute another hash value on the result [i.e., H(H( OIData )H( PIData ))]. Compute DS = RSA ( cKS ) (H(H( OIData )H( PIData ))).

• Create a SET authentic channel M with the merchant, composed of H( PIData ), OIData, DS, Cert_cKV , and the CCA certification chain.

• Create a SET authentic and confidential channel P with the payment gateway.

  • Compute the payment_message from the payment instruction PIData , DS , and H( OIData ).

  • Generate SSK to compute the encrypted payment message C' = DES (SSK) ( PIData DS H( OIData )).

  • Using the authentic copy of the payment gateway's public encryption key pKE , create a digital envelope including the SSK and the PAN of the cardholder (i.e., C = RSA ( pKE )[ SSK PAN ]).

  • P consists of C' and C .

• Compute PReq as a superposition of M and P , where only M is intended for the merchant, while P is just tunneled by the merchant to the payment gateway. Send PReq to the merchant.

PRes After receiving the PReq, the merchant first verifies the authenticity of the cardholder. Then, the merchant elaborates an authorization request (AuthReq) for the payment gateway, which allows the matching of an order instruction coming from the merchant with a payment instruction coming from the cardholder. The merchant computes a purchase response (PRes), without necessarily waiting for the authorization response (AuthRes) of the payment gateway.

• Verify the authenticity of the cardholder and the integrity of the information received in the part M of the PReq.

  • Check the authenticity of the electronic representation of the payment card. Traverse the CCA certification chain from the rootKV to obtain an authentic copy of ccaKV . Use this key to validate Cert_cKV and obtain an authentic copy of the cardholder's public verification key cKV .

  • Use cKV to dynamically authenticate the cardholder and the integrity of her purchase request. Compute the H( OIData ), concatenate it with H( PIData ), and apply once again H. Compare the result H(H(OIData) H (PIData)) computed locally with the witness value computed by the verification of the dual signature DS (i.e., RSA( cKV )[ DS ]). If they are equal, the merchant is assured about the authenticity of the cardholder and the integrity of the part M in PReq, and consequently of the OD .

• The merchant processes the OD .

• The merchant includes the part P of the PReq, consisting of the encrypted payment message C' and the digital envelope C , together with the cardholder's signature public key certificate Cert_cKV and the CCA certification chain, in the AuthReq addressed to the payment gateway.

• The merchant is not compelled to wait for the AuthRes to his AuthReq before computing the PRes message and sending back to the cardholder.

  To this end the PResData is formatted, including enough identification information ( TransID , RRPID), the current session challenge r_c of the cardholder, and the PResPayLoad item. This last item indicates the conditions of completion of the current purchase processing. Thus, when the payment gateway has not yet answered , then a completion code cc = orderReceived is included in the PResPayLoad. If the payment gateway rejects the transaction then cc = orderRejected , and the PResPayLoad could also include the AcqCardMsg (eventually received in AuthRes), explaining a reason for the rejection in AuthCode . When the payment gateway has authorized the payment, then the completion code is cc = authPerformed and the AcqCardMsg could indicate the authorization date (AuthDate), a ratio of how much of the purchase amount was actually authorized (whether the whole amount is authorized or a smaller amount).

  The merchant's software signs the PResData, computing S 2 = RSA ( mKS ) [H (PResData)]. Both the PResData and S 2 are sent to the cardholder, for verification, together with the merchant's signature public key certificate Cert_mKV and the MCA certification chain.

• The cardholder's software verifies the authenticity and integrity of the payment response PRes received from the merchant.

  • Retrieve the authentic copy of the merchant's public verification key mKV . If this copy cannot be retrieved, traverse the MCA certification chain from the rootKV to obtain an authentic copy of mcaKV . Use this key to validate Cert_mKV and obtain an authentic copy of the mKV .

  • Use mKV to compute h = RSA( mKV )[ S 2] and compare it with the hash value h' = H(PResData) computed locally by the cardholder. If they are equal, the cardholder is assured about the authenticity of the merchant's response PRes.

  • If the payment gateway did not send the status of the transaction, an order inquiry can be subsequently sent to the merchant to find out the final result of the SET payment.

8.4.6.3 Payment authorization

AuthReq The payment authorization stage of the SET payment starts with the merchant sending the AuthReq message to the payment gateway. It consists of two parts : the payment instruction related message P , which was originally sent by the cardholder inside PReq and destined to the payment gateway, and an authorization message in relation to the order instruction created and signed by the merchant. When the payment gateway receives AuthReq, it checks the consistency between the two parts of the request, independently elaborated by the cardholder and merchant, but which are linked together, using the dual signature and the transaction identifier ( TransID ).

• The merchant creates an authentic and confidential channel (Section 8.4.4.1) with the payment gateway.

  • Create AuthReqData specifying the conditions of the transaction to be authorized, including the purchase amount ( PurchAmt ), the TransID from the order instruction, a locally generated hash value of the OIData , and other information related to the current transaction.

  • Sign it with the mKS and compute S 3 = RSA ( mKS )[H (AuthReq Data)].

  • Generate at random the symmetric key SSK 1 and compute C '1 = DES( SSK 1)[AuthReqData S 3].

  • Use an authentic copy of the payment gateway's public encryption key pKE to produce a digital envelope C 1 containing SSK 1 (i.e., C 1 = RSA( pKE )[ SSK 1]).

• The merchant tunnels the authentic and confidential channel established between the cardholder and the payment gateway during the payment processing stage. To this end, the AuthReq includes the payment message P = ( C, C' ) received from the cardholder within PReq, the cardholder's signature public key certificate Cert_cKV , and the CCA certification chain.

• The merchant includes in the AuthReq his own cryptogram, C' 1, of the authorization data and the corresponding digital envelope, C1. If the payment gateway has no authentic copies of the merchant's public verification key ( mKV ) and public encryption key ( mKE ), the AuthReq includes also the Cert_mKV and Cert_mKE , together with the MCA certification chain.

• The merchant sends AuthReq to the payment gateway.

AuthRes The payment gateway receives AuthReq from the merchant and checks it. If the verification passes, the payment gateway formats an authorization request (1100) message according to the requirements of the bankcard association network that connects to the IH and forwards the 1100 message. After processing this authorization request, the IH elaborates an authorization request response (1110) message, which is sent back to the payment gateway. This message consists of two parts: the issuer's response, concerning the approval or rejection of the current transaction, and a capture token. The merchant software uses this token to complete the payment capture stage, which is the last stage of the SET payment.

• The payment gateway parses the AuthReq received from the merchant and checks the consistency between the order instruction and payment instruction, coming on independent channels, from the merchant and cardholder, respectively.

  • Traverse the MCA certification chain from the rootKV to obtain an authentic copy of mcaKV . Use this key to validate Cert_mKV and Cert_mKE , and obtain an authentic copy of the merchant's public verification key mKV and public encryption key mKE .

  • Use the payment gateway's private decryption key pKD to open the digital envelope C 1 and to obtain the symmetric key SSK 1 (i.e., SSK 1 = RSA( pKD )[ C 1]).

  • Use SSK 1 to decrypt C' 1 and obtain the authorization data of the transaction AuthReqData together with the signature S 3 of the merchant on this data.

  • Use the authentic copy of the merchant's public verification key mKV to check the signature S 3. To this end, compute h = RSA ( mKV )[ S 3] and compare it with h ' = H(AuthReqData), computed locally. If the verification passes, accept the authenticity and integrity of the authorization data, including the order instruction as presented by the merchant h 2 = H( OIData ) and the transaction identifier TransID .

  • Traverse the CCA certification chain from the rootKV to obtain an authentic copy of ccaKV . Use this key to validate Cert_cKV and obtain an authentic copy of the cardholder's public verification key cKV .

  • Use the payment gateway's private decryption key pKD to open the digital envelope C originated by the cardholder and tunneled by the merchant. Obtain the symmetric key SSK and the cardholder's account information (i.e., SSK PAN = RSA ( pKD )[ C ]).

  • Use SSK to decrypt C' and to obtain the payment message, PIData DS H( OIData ) = DES ^-1 (SSK) [ C' ].

  • Compute the hash value h 1 = H( PIData ) of the payment instruction PIData recovered from the cardholder's cryptogram and concatenate it with the order instruction as presented by the merchant h 2 = H( OIData ). Compute locally the hash value h ' = H(h1 h2).

  • Verify the dual signature DS . To achieve this, compute h = RSA ( cKV )[ DS ] and compare it with h' obtained above. If the verification passes, the payment gateway has the guarantee that the order instruction presented by the merchant is the order instruction on which the cardholder agrees. The payment gateway also checks that the TransID from the order instruction is one and the same value with that present in the payment instruction.

• The payment gateway has all the elements to compute the message 1100 and to send it to the issuer. After receiving the corresponding 1110 response from the IH, the payment gateway elaborates the authorization response AuthRes to the merchant. This message contains the following:

• Information about the approval or rejection of the transaction (AuthResPayload), from which the merchant server can further compose the PResPayLoad included in the PRes. The AuthCode gives the error code in case of rejection;

• The AcqCardMsg, providing supplementary information from the IH for the cardholder software, which is also included in the PRes;

• The capture token, which is subsequently used in the payment capture stage.

  The message is sent to the merchant using an authentic and confidential channel.

8.4.6.4 Payments capture

The merchant initiates this stage in order to get paid for a transaction that was already authorized and for which the delivery of purchases or services was already completed. The merchant composes and sends to the payment gateway a capture request message (CapReq), including the amount involved in the previously authorized transaction and the capture token. The payment gateway receives the request and sends to the issuer for clearing, using the same bankcard network as for authorization stage. The payment gateway sends a capture response (CapRes) to the merchant, who will store it for reconciliation with the payment received from the acquirer. This closes the SET payment.