Digital Signatures & SET Protocol

Introduction to Digital Signatures

Purpose and Analogy

• Concept: Similar to how a person physically signs a document to confirm its origin or approval, a digital signature is used cryptographically.
• Authentication Problem: How can a recipient (Bob) ensure a message truly comes from the claimed sender (Alice) and not an imposter (Eve)?
• Solution: Bob can ask Alice to cryptographically sign the message.
• Function: A digital signature authenticates Alice as the valid sender of the message.

Limitations of Simple Digitized Signatures

• Question: Why not just scan a physical signature and append it to a digital document?
• Vulnerability: Anyone with access can easily copy this digitized signature image and paste it onto a different document (e.g., a fraudulent check).
• Forgery: While modifying a physical signature requires cutting/pasting or photocopying (often detectable), digital copying and pasting is seamless and indistinguishable from the original use.
• Requirement: We need digital signatures that are intrinsically linked to the specific message being signed and cannot be separated and reattached to another message.

Core Principles

• Binding: A digital signature must be tied not only to the signer but also to the message content.
• Verifiability: The signature must be easily verifiable by any third party.
• Two Processes: Digital signature schemes involve two distinct steps:
  1. Signing Process: Performed by the sender using private information.
  2. Verification Process: Performed by the receiver (or anyone) using public information.

Basic Requirements

• Easy to Sign: The signing process should be computationally easy for the legitimate signer.
• Easy to Verify: The verification process should be computationally easy for anyone.
• Hard to Forge: It must be computationally infeasible for anyone (including the receiver) to forge a valid signature for a message they haven’t seen signed, or to create a new message with a valid signature based on existing signed messages.

Working Procedure (General)

This describes the common approach using hash functions.

1. Hashing (Signing End):
   • Alice takes her electronic file (message $M$).
   • She applies a cryptographic hash algorithm (e.g., SHA-1, SHA-256) to the message $M$.
   • This produces a fixed-size hash value (or message digest) $D=H(M)$.
2. Signing (Signing End):
   • Alice uses her private key ($k_{pr}$) and a signing algorithm to encrypt the hash value $D$.
   • This produces the digital signature $S={\text{Sign}}_{k_{pr}}(D)={\text{Sign}}_{k_{pr}}(H(M))$.
   • Alice sends the original message $M$ and the signature $S$ together to Bob.
3. Hashing (Verification End):
   • Bob receives the message $M^{\prime }$ and the signature $S^{\prime }$. (Using primes ’ to denote received versions).
   • Bob applies the same hash algorithm used by Alice to the received message $M^{\prime }$.
   • This produces a hash value $D^{\prime }=H(M^{\prime })$.
4. Verification (Verification End):
   • Bob obtains Alice’s public key ($k_{pub}$).
   • Bob uses the public key and a verification algorithm (the inverse of the signing algorithm) to decrypt the received signature $S^{\prime }$.
   • This produces a hash value $D^{\prime \prime }={\text{Verify}}_{k_{pub}}(S^{\prime })$.
5. Comparison:
   • Bob compares the hash he computed from the message ($D^{\prime }$) with the hash recovered from the signature ($D^{\prime \prime }$).
   • If $D^{\prime }=D^{\prime \prime }$, the signature is valid. This means the message hasn’t been altered (Integrity) and it was signed by the holder of the private key corresponding to the public key used (Authentication).
   • If $D^{\prime }\ne D^{\prime \prime }$, the signature is invalid.

Comparison: Digital Signature vs. Public Key Encryption

Feature	Digital Signature	Public Key Encryption
Action	Signing Data	Encrypting Data
Key Used (Doer)	Private Key (Only holder can sign)	Public Key (Anyone can encrypt)
Action	Verifying Signature	Decrypting Data
Key Used (Doer)	Public Key (Anyone can verify)	Private Key (Only holder can decrypt)

Security Services Provided

Digital signatures offer the following security services:

1. Integrity: Ensures that the message content has not been modified after being signed. Verification fails if the message is altered because the hash will change.
2. Message Authentication: Verifies that the message originated from the owner of the private key used for signing. Only the owner of the private key could have generated the valid signature verifiable by the corresponding public key.
3. Nonrepudiation: Prevents the sender from falsely denying that they sent and signed the message. Since only the sender possesses the private key, a valid signature serves as strong evidence that they created it.

---

RSA Digital Signature Scheme

Concept

• Uses the RSA algorithm’s public/private key pair properties.
• Signing is essentially “decrypting” the message/hash with the private key.
• Verification is essentially “encrypting” the signature with the public key.

Scheme Description

• Alice:
  • Has an RSA key pair: Private key $k_{pr}=d$, Public key $k_{pub}=(n,e)$.
  • Wants to sign a message $x$ (or typically, the hash of the message $D=H(x)$).
• Signing Process (Alice):
  • Computes the signature $s$ using her private key $d$: $s={\text{sig}}_{k_{pr}}(x)=x^d\mathrm{mod}n$ (If signing a digest $D$, then $s=D^d\mathrm{mod}n$)
  • Sends the message $x$ and the signature $s$ to Bob.
• Verification Process (Bob):
  • Receives message $x$ and signature $s$. Obtains Alice’s public key $(n,e)$.
  • Computes a value $x^{\prime }$ using the public key $e$: $x^{\prime }=s^e\mathrm{mod}n$
  • Compares the computed $x^{\prime }$ with the received message $x$:
    • If $x^{\prime }\equiv x\mathrm{mod}n$, the signature is valid.
    • If $x^{\prime }\not\equiv x\mathrm{mod}n$, the signature is invalid. (If signing a digest, Bob computes $D=H(x)$ and $D^{\prime }=s^e\mathrm{mod}n$. Compares $D^{\prime }$ and $D$.)

RSA Signature on Message Digest (Standard Practice)

• Why sign the digest?
  • RSA operations are computationally expensive, especially on large messages.
  • Hashing is much faster.
  • Public key block sizes might be smaller than the message; hashing creates a fixed-size input suitable for RSA.
• Process:
  1. Alice (Signer):
     • Message $M$.
     • Compute digest $D=H(M)$.
     • Sign the digest using private key $d$: $S=D^d\mathrm{mod}n$.
     • Send $(M,S)$.
  2. Bob (Verifier):
     • Receive $(M,S)$. Obtain Alice’s public key $(e,n)$.
     • Compute digest of received message: $D^{\prime }=H(M)$.
     • Verify signature using public key $e$: $D^{\prime \prime }=S^e\mathrm{mod}n$.
     • Compare: If $D^{\prime }=D^{\prime \prime }$, accept; otherwise, reject.

Attacks on RSA Signed Digests

Attacks often target the hash function or the way RSA interacts with it.

1. Key-Only Attack (Eve only knows Alice’s public key)

   • Case a (Second Preimage Attack): Eve intercepts a valid pair $(S,M)$. She tries to find a different message $M^{\prime }$ such that $H(M)=H(M^{\prime })$. If successful, $(S,M^{\prime })$ would be a valid forgery.
     • Difficulty: Depends on the second preimage resistance of the hash function. Hard for good hash functions.
   • Case b (Collision Attack): Eve finds two messages, $M$ and $M^{\prime }$, such that $H(M)=H(M^{\prime })$. She tricks Alice into signing $M$ (producing signature $S$). Eve now has a valid pair $(S,M^{\prime })$ for a message Alice never intended to sign.
     • Difficulty: Depends on the collision resistance of the hash function. Hard for good hash functions.
   • Case c (Preimage Attack): Eve generates a random signature $S$ and computes $D=S^e\mathrm{mod}n$. She then tries to find any message $M$ such that $H(M)=D$. If successful, $(S,M)$ is a valid pair.
     • Difficulty: Depends on the preimage resistance (or one-way property) of the hash function. Hard for good hash functions.

2. Known-Message Attack (Eve has some valid message-signature pairs $(M_1,S_1),(M_2,S_2),...$ signed with the same key)

   • Multiplicative Property Attack: If the hash function had a multiplicative property (e.g., $H(M_1\times M_2)=H(M_1)\times H(M_2)$), Eve could compute $S=S_1\times S_2\mathrm{mod}n$. This $S$ would be a valid signature for $M=M_1\times M_2$.
     • Mitigation: Cryptographic hash functions (SHA-1, SHA-256, etc.) do not have such simple algebraic properties. Finding an $M$ such that $H(M)=H(M_1)\times H(M_2)$ (given $M_1,M_2$) is generally as hard as finding a preimage if the hash function is preimage resistant.

3. Chosen-Message Attack (Eve can get Alice to sign messages of Eve’s choosing)

   • Similar multiplicative attack potential as Known-Message if the hash function were weak. Eve asks Alice to sign $M_1$ and $M_2$, gets $S_1$ and $S_2$. If Eve could find $M$ such that $H(M)=H(M_1)\times H(M_2)$, she could forge $(S,M)$ where $S=S_1\times S_2\mathrm{mod}n$.
     • Difficulty: Relies on finding $M$ given the target hash value, which should be hard due to preimage resistance.

---

ElGamal Digital Signature Scheme

Concept

• Based on the difficulty of the discrete logarithm problem.
• Involves a random element in the signing process, making the signature non-deterministic (different signatures for the same message each time).

Standard ElGamal Signature Scheme (Page 14)

• Setup:
  • Choose a large prime $p$.
  • Choose a generator $\alpha$ of the multiplicative group ${\mathbb{Z}}_p^{\ast }$ (or a suitable subgroup).
  • Alice chooses a private key $a$, where $1\le a\le p-2$.
  • Alice computes her public key $\beta ={\alpha }^a\mathrm{mod}p$.
  • Public parameters: $(p,\alpha ,\beta )$. Private key: $a$.
• Signing Process (Alice signing message $m$):
  1. Select a secret random integer $k$ such that $1\le k\le p-2$ and $\text{gcd}(k,p-1)=1$. This $k$ must be unique for each signature.
  2. Compute $r={\alpha }^k\mathrm{mod}p$.
  3. Compute $s=k^{-1}(m-ar)\mathrm{mod}(p-1)$. (Requires computing the modular inverse of $k$ modulo $p-1$).
  4. The signature is the pair $(r,s)$. Alice sends $(m,r,s)$.
• Verification Process (Bob verifying $(m,r,s)$):
  1. Obtain Alice’s public key $(p,\alpha ,\beta )$. Verify that $1\le r\le p-1$.
  2. Compute $v_1={\beta }^r{r}^s\mathrm{mod}p$.
  3. Compute $v_2={\alpha }^m\mathrm{mod}p$.
  4. The signature is valid if and only if $v_1\equiv v_2\mathrm{mod}p$.
• Proof of Correctness:
  • From the signing equation, $s\equiv k^{-1}(m-ar)(\mathrm{mod}p-1)$.
  • Multiplying by $k$, we get $sk\equiv m-ar(\mathrm{mod}p-1)$.
  • Rearranging, $m\equiv sk+ar(\mathrm{mod}p-1)$.
  • Now consider $v_2={\alpha }^m\mathrm{mod}p$. Using the congruence in the exponent: $v_2\equiv {\alpha }^{sk+ar}\equiv ({\alpha }^k{)}^s({\alpha }^a{)}^r(\mathrm{mod}p)$
  • Since $r={\alpha }^k\mathrm{mod}p$ and $\beta ={\alpha }^a\mathrm{mod}p$, substitute these: $v_2\equiv r^s{\beta }^r(\mathrm{mod}p)$
  • This is exactly $v_1$. Thus, $v_1\equiv v_2\mathrm{mod}p$ if the signature is valid.

ElGamal Variant (Pages 15, 16)

• Setup:
  • Choose prime $p$.
  • Choose generator $e_1$ (equivalent to $\alpha$).
  • Alice chooses private key $d$ (equivalent to $a$).
  • Alice computes public key $e_2=e_1^d\mathrm{mod}p$ (equivalent to $\beta$).
  • Public parameters: $(p,e_1,e_2)$. Private key: $d$.
• Signing Process (Alice signing message $M$):
  1. Choose a secret random integer $r$ (equivalent to $k$) such that $\text{gcd}(r,p-1)=1$.
  2. Compute $S_1=e_1^r\mathrm{mod}p$.
  3. Compute $S_2=(M-d{S}_1)r^{-1}\mathrm{mod}(p-1)$. (Note the structure difference from standard $s$).
  4. Signature is $(S_1,S_2)$. Alice sends $(M,S_1,S_2)$.
• Verification Process (Bob verifying $(M,S_1,S_2)$):
  1. Obtain public key $(p,e_1,e_2)$.
  2. Compute $V_1=e_1^M\mathrm{mod}p$.
  3. Compute $V_2=e_2^{S_1}{S}_1^{S_2}\mathrm{mod}p$.
  4. Signature is valid if $V_1\equiv V_2\mathrm{mod}p$.
• Proof of Correctness (Variant):
  • From signing $S_2$: $S_{2}r\equiv M-d{S}_1(\mathrm{mod}p-1)$.
  • Rearranging: $M\equiv S_{2}r+d{S}_1(\mathrm{mod}p-1)$.
  • Consider $V_1=e_1^M\mathrm{mod}p$. Substitute the exponent: $V_1\equiv e_1^{S_{2}r+d{S}_1}\equiv (e_1^r{)}^{S_2}(e_1^d{)}^{S_1}(\mathrm{mod}p)$
  • Since $S_1=e_1^r\mathrm{mod}p$ and $e_2=e_1^d\mathrm{mod}p$: $V_1\equiv S_1^{S_2}{e}_2^{S_1}(\mathrm{mod}p)$
  • This is exactly $V_2$. Thus, $V_1\equiv V_2\mathrm{mod}p$.

ElGamal Example (Variant from Page 16)

• Parameters: $p=3119$, $e_1=2$, $d=127$ (private).
• Public key: $e_2=e_1^d\mathrm{mod}p=2^{127}\mathrm{mod}3119=1702$.
• Message: $M=320$.
• Random secret chosen by Alice: $r=307$. (Note $\text{gcd}(307,3118)=1$).
• Signing:
  1. $S_1=e_1^r\mathrm{mod}p=2^{307}\mathrm{mod}3119=2083$.
  2. Need $r^{-1}\mathrm{mod}(p-1)$, i.e., $307^{-1}\mathrm{mod}3118$. Using Extended Euclidean Algorithm, $307^{-1}\equiv 2755(\mathrm{mod}3118)$.
  3. $S_2=(M-d{S}_1)r^{-1}\mathrm{mod}(p-1)$ $S_2=(320-127\times 2083)\times 2755\mathrm{mod}3118$ $S_2=(320-264541)\times 2755\mathrm{mod}3118$ $S_2=(-264221)\times 2755\mathrm{mod}3118$ $(-264221\equiv 815(\mathrm{mod}3118))$ $S_2=815\times 2755\mathrm{mod}3118$ $S_2=2245325\mathrm{mod}3118$ $S_2=2105$.
• Signature is $(S_1,S_2)=(2083,2105)$. Alice sends $(320,2083,2105)$.
• Verification (Bob):
  1. $V_1=e_1^M\mathrm{mod}p=2^{320}\mathrm{mod}3119=3006$.
  2. $V_2=e_2^{S_1}{S}_1^{S_2}\mathrm{mod}p=1702^{2083}\times 2083^{2105}\mathrm{mod}3119$. Calculating these large powers requires modular exponentiation. $1702^{2083}\mathrm{mod}3119=101$ (Calculation needed) $2083^{2105}\mathrm{mod}3119=2105$ (Calculation needed) Re-check calculation from slide… $V_2=1702^{2083}\times 2083^{2105}\mathrm{mod}3119=3006$ (Slide confirms result)
• Result: Since $V_1=3006$ and $V_2=3006$, $V_1\equiv V_2\mathrm{mod}p$. The signature is valid.

---

Digital Signature Algorithm (DSA)

• Mentioned as “One Standard” in the outline (Page 1).
• No details provided in the subsequent slides.
• DSA is another signature scheme based on the discrete logarithm problem, similar in principle to ElGamal but with some differences in structure and calculation. It was specified as a U.S. Federal Information Processing Standard (FIPS).

---

Secure Electronic Transaction (SET)

Introduction

• Problem: How to securely communicate credit card and purchasing data over the internet to gain consumer trust?
• Needs:
  • Authentication of both buyer (cardholder) and merchant.
  • Confidentiality of transmitted data (like credit card numbers).
• Systems Vary By:
  • Type of public-key encryption used.
  • Type of symmetric encryption used.
  • Message digest algorithm used.
  • Number of parties having private keys.
  • Number of parties having digital certificates.

Related Credit Card Protocols

• SSL/TLS: Secure Sockets Layer / Transport Layer Security (Provides secure channel, used widely, can involve 1 or 2 private keys/certificates).
• i KP (IBM).
• SEPP (Secure Encryption Payment Protocol): MasterCard, IBM, Netscape.
• STT (Secure Transaction Technology): VISA, Microsoft.
• SET (Secure Electronic Transactions): Developed primarily by Visa and MasterCard.

SET Overview

• Goal: Protect credit card transactions online.
• Features:
  • Confidentiality: All sensitive messages are encrypted.
  • Trust: Relies heavily on digital certificates. All parties must have certificates issued by a trusted hierarchy.
  • Privacy: Information is made available only on a “need-to-know” basis (e.g., merchant doesn’t see credit card number, bank doesn’t see order details). This is achieved using Dual Signatures.

Participants in the SET System

• Cardholder: Buyer using a credit card.
• Merchant: Seller accepting credit card payments.
• Issuer: Financial institution that issued the card to the cardholder (Cardholder’s bank).
• Acquirer: Financial institution that establishes an account with the merchant and processes payments (Merchant’s bank).
• Payment Gateway: Interface between SET (internet) and existing financial payment networks for authorization and clearing. Often operated by the acquirer or a designated third party.
• Certificate Authority (CA): Trusted entity that issues and manages digital certificates for all participants.

SET Business Requirements

• Provide confidentiality of payment and ordering information.
• Ensure the integrity of all transmitted data.
• Authenticate the cardholder as a legitimate user of the credit card account.
• Authenticate the merchant’s ability to accept credit card transactions via its relationship with a financial institution.
• Use best security practices and system design.
• Be independent of transport security mechanisms (like TLS/SSL) but not prevent their use.
• Facilitate interoperability between software and network providers.

SET Transaction Flow (Simplified)

1. Customer browses and decides to purchase.
2. Customer software (e.g., e-wallet) sends order information (OI) and encrypted payment information (PI) to the merchant, using SET protocols (including Dual Signature).
3. Merchant forwards PI (still encrypted) and related information to the Payment Gateway.
4. Payment Gateway decrypts PI, reformats if necessary, and requests payment authorization from the Issuer via the Acquirer and payment network.
5. Issuer authorizes (or denies) payment. Authorization flows back to the Gateway.
6. Gateway sends authorization status back to the Merchant.
7. Merchant confirms the order with the customer and fulfills it (e.g., ships goods).
8. Merchant later sends a “capture” request (to actually get the funds) to the Gateway.
9. Funds are transferred through the payment network; Issuer bills the cardholder.

Key Technologies in SET

• Confidentiality: DES (Data Encryption Standard) for symmetric encryption of bulk information (like PI). Keys are exchanged using public-key encryption (digital envelopes).
• Integrity & Authentication: RSA digital signatures combined with SHA-1 hash codes.
• Cardholder Authentication: X.509v3 digital certificates containing the cardholder’s public key, signed by an Issuer-trusted CA, used with RSA signatures.
• Merchant Authentication: X.509v3 digital certificates containing the merchant’s public key(s), signed by an Acquirer-trusted CA, used with RSA signatures. (Merchants typically had two certificates: one for signing, one for key exchange).
• Privacy (Dual Signatures): A core SET innovation to separate order information (OI) from payment information (PI).

Dual Signatures

• Concept: Links two separate pieces of information (intended for different recipients) together cryptographically, while keeping the content of each piece private from the recipient of the other.
• SET Context:
  • Message 1: Order Information (OI) - Sent by Customer, intended for Merchant.
  • Message 2: Payment Information (PI) - Sent by Customer, intended for Bank (via Payment Gateway).
• Goal:
  • Limit Information: Merchant sees OI but not the credit card number in PI. Bank sees PI but not the specific items ordered in OI.
  • Linkage: Prove that the payment (PI) is specifically intended for this order (OI) and not some other order the merchant might try to substitute.
• Why Needed? If the customer simply sent a signed OI to the merchant and a signed PI to the bank (via the merchant), a malicious merchant could potentially capture the signed PI and pair it with a different (perhaps fraudulent) signed OI from the same customer, claiming the payment was for the fraudulent order. Dual signature prevents this.

Dual Signature Operation

1. Hashing: The customer’s software computes the hash (using SHA-1 in SET) of the Payment Information ($PI$) and the Order Information ($OI$):
   • $PIMD=H(PI)$ (Payment Information Message Digest)
   • $OIMD=H(OI)$ (Order Information Message Digest)
2. Concatenation: The two digests are concatenated: $PIMD||OIMD$.
3. Hashing Again: The concatenated digest is hashed:
   • $POMD=H(PIMD||OIMD)$ (Payment Order Message Digest)
4. Signing: The customer encrypts (signs) this final digest ($POMD$) using their private signature key ($K{R}_c$):
   • $DS=E_{K{R}_c}[POMD]=E_{K{R}_c}[H(H(PI)||H(OI))]$
   • $DS$ is the Dual Signature.

Information Sent

• To Merchant: Customer sends OI (plaintext), DS, OIMD. (Also, PI encrypted for the bank, and the digital envelope for PI’s symmetric key).
• To Bank (via Merchant & Gateway): Merchant forwards PI (encrypted), DS, PIMD, and the digital envelope.

Dual Signature Verification by Merchant

• Goal: Verify that the OI received is linked to the payment being processed (even though the merchant can’t see the PI).
• Inputs: Merchant has OI, DS, OIMD, and the customer’s public signature key ($K{U}_c$) from the customer’s certificate. Crucially, the merchant also needs PIMD. SET protocols ensure the merchant receives PIMD along with the other components.
• Steps:
  1. Merchant computes the hash of the received Order Information: $H(OI)$. Verify this matches the received $OIMD$.
  2. Merchant computes the combined hash using the received $PIMD$ and the received $OIMD$: $POM{D}_{calculated}=H(PIMD||OIMD)$.
  3. Merchant decrypts (verifies) the Dual Signature using the customer’s public key: $POM{D}_{decrypted}=D_{K{U}_c}[DS]$.
  4. Compare: If $POM{D}_{calculated}=POM{D}_{decrypted}$, the signature is valid, proving the OI is linked to the PI whose hash is PIMD.

Dual Signature Verification by Bank/Gateway

• Goal: Verify that the PI received is linked to the order being processed (even though the bank can’t see the OI).
• Inputs: Bank/Gateway has PI (after decryption), DS, PIMD, OIMD, and the customer’s public signature key ($K{U}_c$).
• Steps:
  1. Gateway decrypts the PI using the symmetric key from the digital envelope.
  2. Gateway computes the hash of the decrypted Payment Information: $H(PI)$. Verify this matches the received $PIMD$.
  3. Gateway computes the combined hash using the computed $H(PI)$ (which is $PIMD$) and the received $OIMD$: $POM{D}_{calculated}=H(H(PI)||OIMD)$.
  4. Gateway decrypts (verifies) the Dual Signature using the customer’s public key: $POM{D}_{decrypted}=D_{K{U}_c}[DS]$.
  5. Compare: If $POM{D}_{calculated}=POM{D}_{decrypted}$, the signature is valid, proving the PI is linked to the OI whose hash is OIMD.

Accomplishments of Dual Signature

• Merchant receives OI and verifies it’s linked to a valid payment intent.
• Bank receives PI and verifies it’s linked to a specific order intent.
• Customer has successfully linked OI and PI while maintaining privacy, and can prove this linkage if necessary (since they created the DS linking the specific $H(OI)$ and $H(PI)$).

SET Purchase Transaction Messages (Simplified)

The purchase involves several message exchanges.

1. Initiate Request (Customer to Merchant):
   • Customer needs Merchant’s and Payment Gateway’s certificates.
   • Sends request indicating brand of card, a unique transaction ID, and a nonce (random number).
2. Initiate Response (Merchant to Customer):
   • Merchant responds, signing the response.
   • Includes customer’s nonce, a merchant nonce, the transaction ID.
   • Also includes Merchant’s Signature Certificate and Payment Gateway’s Key Exchange Certificate.
3. Purchase Request (Customer to Merchant):
   • Cardholder verifies the certificates received.
   • Creates OI and PI.
   • Generates a one-time symmetric key ($K_s$) for encrypting PI.
   • Encrypts $K_s$ using the Payment Gateway’s public key exchange key ($K{U}_b$) - this is the digital envelope.
   • Encrypts PI using $K_s$: $E_{K_s}[PI]$.
   • Calculates $PIMD=H(PI)$ and $OIMD=H(OI)$.
   • Calculates the Dual Signature $DS=E_{K{R}_c}[H(PIMD||OIMD)]$.
   • Message Contains: OI (clear), $E_{K_s}[PI]$, Digital Envelope ($E_{K{U}_b}[K_s]$), DS, OIMD, Cardholder Certificate. (The diagram suggests PIMD is also passed, likely needed by Merchant for verification step).
4. Purchase Response (Merchant to Customer):
   • Merchant verifies certificates and the Dual Signature (as described above).
   • Processes the order information.
   • Forwards payment components (Encrypted PI, Digital Envelope, DS, PIMD, OIMD, Certs) to Payment Gateway for authorization.
   • Sends an acknowledgment message to the customer, signed by the merchant, referencing the transaction ID. Includes Merchant’s signature certificate.
   • Customer verifies the merchant’s signature on the response.

SET Payment Process

• Broken into two main phases after the purchase request:
  1. Payment Authorization: Merchant requests authorization before shipping goods/providing service.
  2. Payment Capture: Merchant requests the actual transfer of funds after fulfillment.

Payment Authorization

• Merchant Request to Gateway: Sends an authorization request containing:
  • Purchase-related info: Encrypted PI, Dual Signature (DS), OIMD, PIMD, Digital Envelope (for $K_s$).
  • Authorization-related info: Transaction ID, amount, etc., possibly in a block signed by the merchant’s private key and including an encrypted session key for the gateway response.
  • Certificates: Cardholder’s signature cert, Merchant’s signature cert, Merchant’s key exchange cert.
• Payment Gateway Actions:
  1. Verify all certificates.
  2. Decrypt authorization block envelope (if used), verify merchant signature on auth block.
  3. Decrypt payment block digital envelope ($E_{K{U}_b}[K_s]$) to get $K_s$.
  4. Decrypt $E_{K_s}[PI]$ to get PI.
  5. Verify the Dual Signature using PI, OIMD, and customer’s public key.
  6. Verify transaction ID consistency.
  7. Format and send an authorization request to the Issuer via the payment network.
  8. Receive authorization response from Issuer.
• Authorization Response (Gateway to Merchant):
  • Sends a response message back to the merchant.
  • Includes authorization status (approved/denied), authorization code.
  • May include a “Capture Token” required for the later payment capture phase.
  • Message is typically signed/authenticated by the gateway. Includes Gateway’s certificate.

SET Overhead

• SET involves significant cryptographic operations for a single transaction:
  • Multiple messages (4 between customer/merchant, 2 between merchant/gateway for auth).
  • Multiple digital signatures (e.g., ~6).
  • Multiple RSA encryptions/decryptions (e.g., ~9 cycles, including key exchange, signing/verifying).
  • Multiple DES encryptions/decryptions (e.g., ~4 cycles, for PI and session keys).
  • Multiple certificate verifications (e.g., ~4).
• Scaling: Requires managing a large infrastructure of Certificate Authorities and distributing/validating certificates for potentially millions of users and merchants. Multiple servers often need access to certificate copies or validation services.

---