The Secure Electronic Transaction (SET) is a protocol designed for protecting creditcard transactions over the Internet. It is an industry-backed standard that was formed byMasterCard and Visa (acting as the governing body) in February 1996. To promote the SETstandard throughout the payments community, advice and assistance for its developmenthave been provided by IBM, GTE, Microsoft, Netscape, RSA, SAIC, Terisa and Verisign.SET relies on cryptography and X.509 v3 digital certificates to ensure message confi\u0002dentiality and security. SET is the only Internet transaction protocol to provide securitythrough authentication. It combats the risk of transaction information being altered in transitby keeping information securely encrypted at all times and by using digital certificates toverify the identity of those accessing payment details. The specifications of and ways tofacilitate secure payment card transactions on the Internet are fully explored in this article.
The cardholder holds the CA certificate to use later during the registration process. The cardholder sends the initiate request to the CA
id: 0147c06e51cfb3cc0c4a7ecc9e57b68a - page: 6
Once the initiate request is received from the cardholder, the CA generates the response and digitally signs it by generating a message digest of the response and encrypting it with the CAs private key. The CA sends the initiate response along with the CA certificate to the cardholder. The cardholder receives the initiate response and verifies the CA certificate by traversing the trust chain to the root key. SET FOR E-COMMERCE TRANSACTIONS 369 The cardholder verifies the CA certificate by decrypting it with the CAs public key and comparing the result with a newly generated message digest of the initiate response. It is worth depicting this registration process as shown. Registration form process: The cardholder generates the registration form request.
id: 276b0de04fd5e0a5d98ef84bc42981b0 - page: 6
The cardholder encrypts the SET message with a random symmetric key (No. 1). The DES key, along with the cardholders account number, is then encrypted with the CAs public key. The cardholder transmits the encrypted registration form request to the CA. The CA decrypts the symmetric DES key (No. 1) and cardholders account number with the CAs private key. The CA then decrypts the registration form request using the symmetric DES key (No. 1). The CA determines the appropriate registration form and digitally signs it by generating a message digest of the registration form and encrypting it with the CAs private key. The CA sends the registration form and the CA certificate to the cardholder. The cardholder receives the registration form and verifies the CA certificate by traversing the trust chain to the root key. The cardholder verifies the CAs signature by decrypting it with the CAs public key and comparing the result with a newly generated message digest of the registration form. Th
id: 53ce12b4735f8fb3055bd8fe548949e9 - page: 6
The registration form process is depicted as shown Figure 11.8. 3. Certificate request/response processes: The cardholder generates the certificate request, including the information entered into the registration form. The cardholder creates a message with request, the cardholders public key and a newly generated symmetric key (No. 2), and digitally signs it by generating a message digest of the cardholders private key. The cardholder encrypts the message with a randomly generated symmetric key (No. 3). This symmetric key, along with the cardholders account information, is then encrypted with the CAs public key. The cardholder transmits the encrypted certificated request messages to the CA. The CA decrypts the No. 3 symmetric key and cardholders account information with the CAs private key, and then decrypts the certificate request using this symmetric key. The CA verifies the cardholders signature by decrypting it with the cardh
id: 1e5394c6e112cc256865e6d8b1e7d5eb - page: 6