Secure Electronic Transaction (SET) Protocol 


(Or How to Transact Safely on the Internet)


The growth of the Internet over the past few years has been explosive. It is also changing its character from merely being a purveyor of information to being a complete transaction enabler. Thus, today a surfer can purchase a variety of goods on the Internet, as opposed to merely accessing information. However, what is impeding rapid growth of this business is the consumer perception of poor security on the Net. Most payment methods revolve around the credit card, and consumers remain hesitant to reveal their card information on the Internet. Also, not surprisingly, credit card frauds on the Internet have registered a dramatic increase.

To address these growing security concerns and pave the way for uninhibited growth of electronic commerce on the net, the two leading credit card brands, Visa and MasterCard, teamed up some years ago to develop a common standard to process card transactions on the Internet, called the Secure Electronic Transaction (SET) standard. As the name implies, SET is a standard which will ensure that credit card and associated payment order information travels safely and securely between the various involved parties on the Internet. The purpose of this article is to describe the principles of SET and how they are implemented.

A Sample SET Session

Before getting into details of SET, we shall take a simple example to describe how SET works from the consumer's perspective.

  1. The consumer accesses the merchant's web site, goes through the various goods on display and selects what he or she wants. Perhaps there is a virtual shopping cart where he or she drops all the items to be purchased. At the end, the customer proceeds to the virtual checkout counter. A screen pops up giving details, including the cost of all the items the shopper is purchasing, plus taxes and shipping costs.
  2. Then the screen asks for the payment method and the consumer chooses to pay through a credit card using SET.
  3. Immediately, a special software on the consumer's PC called Digital Wallet is invoked, and it asks the customer to choose one credit card from the many he or she possesses.
  4. The consumer chooses a card, and the electronic transaction using SET is underway. A few seconds later, there is a confirmation that this order has been processed.

Objectives of SET

SET addresses seven major business requirements:1

  1. Provide confidentiality of payment information and enable confidentiality of order information that is transmitted along with the payment information.
  2. Ensure the integrity of all transmitted data.
  3. Provide authentication that a cardholder is a legitimate user of a branded payment card account.
  4. Provide authentication that a merchant can accept branded payment card transactions through its relationship with an acquiring financial institution.
  5. Ensure the use of the best security practices and system design techniques to protect all legitimate parties in an electronic commerce transaction.
  6. Create a protocol that neither depends on transport security mechanisms nor prevents their use.
  7. Facilitate and encourage interoperability among software and network providers.

Point 1 ensures that card information cannot be viewed by unauthorized parties. Point 2 ensures that the information cannot be changed or tampered. Points 3 and 4 ensure that the cardholder and merchant are really who they claim they are. Hence, in essence, this framework, if implemented effectively, will allow both buyers and sellers to transact in total confidence in an open network.


SET principally uses cryptography to meet its objectives. Hence, we shall digress briefly to discuss some basics about cryptography. Cryptography is the science of encrypting messages, that is, converting clear text to cipher text using an algorithm, and then converting it back from cipher text to clear text using the same or another algorithm. There are two common encryption methods: secret key cryptography and public key cryptography (PKC).

Secret key cryptography (also called symmetric key cryptography) has been around for a long time and hence its use is widespread. The most popular implementation is DES, which is used by all financial institutions to encrypt debit and credit card transactions. The sender uses a single 56-bit key (also called a symmetric key) to encrypt information, and the receiver will use the same key to decrypt. We have well-developed hardware and software implementations which encrypt and decrypt using DES at very high speeds.

A much more secure and sophisticated encryption method is public key cryptography (PKC), also known as asymmetric key cryptography, which uses two keys. Any one key (it does not matter which) can be used to encrypt and the other can be used to decrypt. This fundamental property lies at the core of SET. However, encryption and decryption are relatively slow using PKC.

Secure Transmission Using PKC1

When two users want to exchange messages securely, each of them transmits one component of their key pair, designated the public key, to the other and keeps secret the other component, designated the private key. Because messages encrypted with the public key can only be decrypted using the private key, these messages can be transmitted over an insecure network without fear that an eavesdropper could use the key to read encrypted transmissions.

For example, Bob can transmit a confidential message to Alice by encrypting the message using Alice's public key. As long as Alice ensures that no one else has access to her private key, both she and Bob will know that only Alice can read the message.

Mechanics of SET

What happens in an actual SET transaction is a bit more involved. The method has been developed keeping in mind the basic objectives of SET: confidentiality, integrity and authentication of both sender and receiver.

To ensure integrity, we use a one-way hashing algorithm on the message to generate a message digest. This algorithm uses statistical methods to compute a checksum (or message digest) from the characters in the message. If the content or position of even a single character is changed, the message digest will not match. To secure the message digest itself from tampering, the digest is encrypted using the sender's private key. The encrypted form of the message digest is called the digital signature of the sender. The receiver can decrypt the digest using the sender's public key, regenerate the digest and compare. This also ensures that the message has really come from the sender (nobody else knows the sender's private key) and hence accomplishes the objective of authenticating the sender.

To ensure confidentiality, the entire message is encrypted. Since the message could be large, we use the more efficient symmetric encryption. A random symmetric key is generated and used to encrypt the message. To secure the symmetric key itself, it is encrypted using the public key of the receiver.

Finally, the symmetrically encrypted message and the random symmetric key encrypted using the receiver's public key are sent to the receiver. Only the receiver can decrypt the symmetric key, since only he possesses the private key of the receiver. Thus we have achieved authentication of the receiver.

The receiver uses his private key to decrypt the random symmetric key. Then he uses the random symmetric key to decrypt the main message. He locates the sender's digital signature and using the public sender's key, he decrypts it and retrieves the message digest. He regenerates the message digest using the known hashing function and compares it to the retrieved digest. If they match, he is assured that the message has not been tampered with and has indeed originated from the sender.

One last thing needs to be covered: the concepts of digital certificates and certifying authorities. Before two parties start communicating, each wants to be sure about the authenticity of each other's public keys. For instance how is the receiver sure that the public key of the sender is what is mentioned in the message and not something else? To resolve this, we use trusted third parties, also called certifying authorities (CAs). A certifying authority could be a financial institution, a government body, an international body or a card brand (such as Visa or MasterCard). A certifying authority would create a digital document containing the entity's details and public key and then sign it digitally (this involves creating a message digest and encrypting it under the CA's private key). This digital document is called a digital certificate. A good analogy for this is when we take a birth certificate (public key) to the consulate (certifying authority) to get it attested (digital signature) to yield an attested birth certificate (digital certificate). Since people trust the consulate (CA), they will, in turn, trust the attested birth certificate (digital certificate).

What if the sender or receiver does not know of the existence of (does not trust) the certifying authority itself? This can very often happen if the two parties are in different countries. To overcome this, SET mandates the establishment of a hierarchy of trust. This means that the CA itself will be trusted by a parent CA, which in turn will be trusted by another CA until it goes to a root CA which is trusted by everybody. For example, a financial institution in UAE can be trusted by the regional office of the Visa or MasterCard, which in turn is trusted by the Visa or MasterCard international office, which in turn can be trusted by a UN body. The UN body can function as the root CA who everybody trusts. Thus each party vouchsafes for the level below, by issuing digital certificates. The receiver will authenticate the sender by traversing this hierarchy of trust all the way to the root CA. In an actual implementation, this entire process should only take a few seconds, because it is completely automated.

An SET Implementation

Before we apply this to an actual implementation of SET, let us first examine how a credit card transaction is processed in the physical non-SET world.

  • The cardholder presents the card to the merchant, who in turn swipes the card on a POS terminal.
  • An electronic message containing the card number and amount is then sent to the acquiring bank, with whom the merchant is associated.
  • The acquiring bank, in turn, forwards the message to the card brand's (Visa or MasterCard) central computer.
  • The card brand forwards the message to the issuing bank, which initially issued the card to the cardholder.
  • The issuing bank checks the available credit limit on the card and sends back an authorization.
  • This authorization travels all the way back, until it reaches the merchant's POS terminal.

We described, in the beginning of the article, how the transaction will progress in an SET environment. But, in the light of the mechanics of SET, let us describe this in more detail (in the interest of clarity, some details have been omitted/simplified):

  • The cardholder goes to a merchant's web site and selects the items he or she wants to purchase. The cardholder then clicks on the virtual checkout button or its equivalent.
  • This triggers wallet software to be invoked on the cardholder's PC. The software presents several credit cards which the cardholder possesses, and one is chosen. The wallet software also receives the digital certificates of two entities: the merchant and the acquiring bank (also called a payment gateway). These two certificates are validated by traversing the hierarchy of trust, through messages sent on the Internet to all the entities on the trust chain.
  • The wallet software then generates a message containing two parts: the order information and the payment information. The order information contains information confirming the order, whereas the payment information contains the card number and the amount. The payment information is encrypted using a random symmetric key, which, in turn, is encrypted with the payment gateway's public key, so that only the payment gateway can decrypt it. In other words, the merchant will never know the details of the card number of its customer. This data is sent automatically to the merchant's web site.
  • The merchant's computer will first validate the cardholder's digital certificate. Then it will send the payment information to the payment gateway (which is the acquiring bank's computer).
  • The payment gateway will verify the digital certificates of both the merchant and the card holder and decrypt the message to access the card number and the amount.
  • Then the payment gateway will interface with the legacy systems of the acquiring bank to send the transaction to the card brand, which will then send it to the issuing bank for authorization.
  • This authorization response is then encrypted in the usual fashion and sent to the merchant, who, in turn, will validate the message and store the response. Then the merchant will arrange to ship the goods.

All of these transactions happen on the Internet and are quite transparent to the cardholder.

Practical Requirements for SET

SET has been introduced and is working successfully in several European countries. The prerequisites for SET are:

  • The issuing bank will need to request that its cardholders acquire digital certificates. Typically, it will supply a wallet software, which will set up a digital certificate for the cardholder automatically.
  • There has to be a reasonable number of merchant web sites which support SET. For this to happen, the merchants' acquiring banks have to implement payment gateways. Payment gateway software is now available from several certified leading software vendors. Currently the number of SET-enabled web sites is small; however, this is expected to grow substantially in the near future. A list of SET-enabled sites is available from the web sites of MasterCard ( and Visa (


SET is a protocol which enables highly secure Internet shopping using credit cards. It has been developed by Visa and MasterCard in response to the security concerns of transacting on the Internet. The explosive growth of transactions on the Internet will only be further fuelled by SET. The SET protocol itself is still evolving, and is presently being extended to cover debit card transactions as well.

For ease of understanding, the author has presented a simplified version of SET. The actual protocol is far more elaborate and rigorous.


1 SET Secure Electronic Transaction Specification: Book 1: Business Description

Please refer to the February 1999 issue of the ISACA UAE newsletter for more detailed coverage of cryptography by the same author.

Ganesh Ramakrishnan
works with the Global Consumer Bank, Citibank NA, Dubai, UAE, and heads operations and systems coordination. He has more than 10 years of experience with Citibank in various areas including systems development, project management, systems migration, business need analyses and retail banking operations. He is an engineer and a post-graduate in management. He is keenly interested in matters related to online transactions and the fulfillment cycle and the part played by electronic security in this.