Secure Electronic Transaction (SET) is a security protocol designed to ensure the security and integrity of electronic transactions conducted using credit cards. Unlike a payment system, SET operates as a security protocol applied to those payments.
- It uses different encryption and hashing techniques to secure payments over the internet done through credit cards.
- The SET protocol was supported in development by major organizations like Visa, Mastercard, and Microsoft.
- It provide Secure Transaction Technology (STT), and Netscape which provided the technology of Secure Socket Layer (SSL).
- SET protocol restricts the revealing of credit card details to merchants thus keeping hackers and thieves at bay.
Requirements in SET
- Mutual authentication: Verifies the identity of both the customer (cardholder) and the merchant to ensure that both parties are legitimate.
- Confidentiality of PI and OI: Protects Payment Information (PI) and Order Information (OI) using encryption so that sensitive data cannot be accessed by unauthorized users.
- Message integrity: Ensures that the transmitted information cannot be modified or altered during communication.
- Interoperability and strong security: Supports compatibility between different systems and uses reliable security mechanisms to maintain safe transactions.
Participants in SET
SET involves multiple entities that work together to securely complete an online payment transaction.
- Cardholder: The customer who purchases goods or services online using a payment card.
- Issuer: The financial institution that provides the payment card to the customer.
- Merchant: The seller who offers products or services and accepts online payments.
- Acquirer: The merchant’s financial institution that processes payment transactions.
- Certificate Authority (CA): Trusted authority that issues digital certificates (such as X.509V3) to verify identities of all participants.
SET Functionalities
SET provides multiple security features to ensure safe and reliable online payment transactions. These functionalities protect the identity of users, maintain confidentiality of sensitive information, and ensure that transaction data remains unchanged during communication.
1. Provide Authentication
Ensures that both the customer and the merchant are genuine participants in the transaction.
- Merchant Authentication: Allows customers to verify that the merchant is legitimate and has a trusted relationship with financial institutions using X.509V3 digital certificates.
- Customer/Cardholder Authentication: Confirms that the credit card is being used by the authorized cardholder through digital certificates.
- Helps prevent fraud and identity theft.
- Ensures trusted communication between participants.
2. Provide Message Confidentiality
Confidentiality ensures that sensitive transaction data cannot be accessed by unauthorized users during transmission.
- Protects Payment Information (PI) and Order Information (OI).
- Uses encryption techniques to secure messages.
- Prevents unauthorized reading of transaction details.
- Traditionally uses encryption standards such as DES.
3. Provide Message Integrity
Integrity ensures that the information transmitted during the transaction is not altered or modified.
- Uses digital signatures to protect message content.
- Prevents unauthorized modification of data.
- Commonly uses RSA digital signatures with SHA-1.
- HMAC with SHA-1 may also be used for verification.
Dual Signature
This is a special security feature in SET that links Order Information (OI) and Payment Information (PI) while keeping both confidential from unauthorized parties. It ensures that the merchant can view order details but not payment details, while the bank can view payment details but not order details.
- Connects OI (Order Information) with PI (Payment Information).
- Ensures both pieces of information belong to the same transaction.
- Prevents disputes between customer, merchant, and bank.
- Enhances trust and security in online transactions.
Steps for Order Information for Merchant
Steps involved in sending Order Information to the Merchant in SET include dual signature generation, purchase request formation, and merchant-side verification for ensuring secure and authenticated transaction processing.
1. Payment Information (PI) for bank
You might think sending them separately is an easy and more secure way, but sending them in a connected form resolves any future dispute possible. Here is the generation of dual signature:
Where:
- PI: Payment Information
- OI: Order Information
- H: Hash function
- PIMD: Payment Information Message Digest
- OIMD: Order Information Message Digest
- POMD: Payment Order Message Digest
- E: Public key encryption function
- KPc: Customer’s private key
- ||: Concatenation (append) operator
Dual Signature Generation: The dual signature (DS) is computed as:
- DS = Sign(KPc, [ H( H(PI) || H(OI) ) ])
This mechanism ensures that both the payment information and order information are securely linked, while still allowing each party to access only the information relevant to them.
2. Purchase Request Generation in SET
Purchase Request Generation is the process in which the cardholder prepares a secure request to send order and payment details during an online transaction.
Inputs Required:
- Payment Information (PI): Contains sensitive payment details such as card number, expiry date, and transaction amount, which are intended only for the bank.
- Dual Signature: A security mechanism that links Order Information (OI) and Payment Information (PI) to ensure both belong to the same transaction while keeping each confidential.
- Order Information Message Digest (OIMD): A hash value of the order information that ensures the integrity of the order details.
Where:
- PI, OI, OIMD: Have the same meanings as above
- Ks: Temporary (session) symmetric key
- KUbank: Bank’s public key
- CA: Certificate Authority
- EP: Symmetric key encryption function
Digital Envelope: A digital envelope is created to securely send the symmetric key to the bank:
- Digital Envelope = E(KUbank, Ks)
This means the session key Ks is encrypted using the bank’s public key, ensuring only the bank can decrypt it using its private key.
3. Purchase Request Validation on Merchant Side
The Merchant verifies by comparing POMD generated through PIMD hashing with POMD generated through decryption of Dual Signature as follows:
Since we used Customer's private key in encryption here we use KUC which is the public key of the customer or cardholder for decryption 'D'.
Payment Authorization
This is the process in which the merchant verifies the customer’s payment information with the bank to confirm that sufficient funds are available and the transaction is valid.
- Ensures that the payment information provided by the customer is valid.
- Verifies availability of funds in the customer’s account.
- Involves communication between merchant, payment gateway, and issuing bank.
- Approval ensures the merchant will receive payment.
Payment Capture
This is the process in which the authorized payment amount is transferred from the customer’s bank to the merchant’s account through the payment gateway.
- Merchant sends capture request to the payment gateway.
- Payment gateway processes the transaction.
- Funds are transferred to the merchant’s account.
- Completes the online payment transaction securely.
Limitations of SET Protocol
- Requires customers and merchants to install special software such as digital wallets and card readers.
- Extra security steps increase the time required to complete online transactions.
- Requires Public Key Infrastructure (PKI) setup, including certificate generation and management, which Different certificate authorities and systems may follow different standards, creating compatibility problems.
- Difficult setup and usage process reduced its acceptance among users.