An Innovative Electronic Payment Framework for Secure Peer-to-Peer Transactions

1. Introduction

The swift growth of the web has driven the transformation of online trade, creating a virtual platform that enables the transfer of digital payments and exchange-related information across networks. The success of electronic commerce can be attributed to key characteristics of the Internet, such as its openness, high-speed connectivity, anonymity, digitization, and global reach [1,2].

By the early 2000s, the Internet had connected more than 70 million computers worldwide [3]. Visionary online businesses such as Amazon.com [4] and eBay [5] recognized the immense commercial potential of this growing user base, offering global services for buying and selling goods through web-based platforms. These platforms operate on a centralized infrastructure, which ensures a certain level of security for users. The primary advantage of such a model lies in its ability to enforce rules effectively. However, from another perspective, centralized architectures present critical challenges: they create a single point of failure and introduce scalability constraints due to bandwidth and computing resource limitations, leading to high infrastructure demands [6].

Moreover, this centralized approach is often impractical for small businesses or independent merchants that lack the financial capacity to support significant infrastructure costs. This challenge has paved the way for peer-to-peer (P2P) [7,8,9] systems as an alternative solution. The P2P paradigm is gaining traction as a distributed computing framework capable of leveraging the resources of edge devices, including personal computers and mobile devices, to create a decentralized and efficient network. P2P infrastructures inherently provide scalability and fault tolerance, as demonstrated by successful systems such as Kazaa [10] and Gnutella [11]. Furthermore, P2P networks have become a foundational component of blockchain technology, where decentralized architectures facilitate secure and transparent transactions without reliance on a central governing entity [12,13].

This paper introduces a novel electronic payment protocol that harnesses the potential of peer-to-peer (P2P) networks. Unlike traditional electronic commerce models, which depend heavily on financial institutions [14], The peer-to-peer model enables individuals to switch between buyer and seller roles. This distributed digital economy is ideal for virtual marketplaces where pre-owned goods are traded. Within this framework, every user can function as both a vendor and a purchaser utilizing only their own device [15]. The proposed protocol ensures a fully anonymous, secure, and practical transaction framework, where all peers can function as both sellers and buyers. Additionally, it integrates a comprehensive security mechanism that protects both personal and order-related information from unauthorized access. The core of this protocol combines the digital envelope technique from the Secure Electronic Transaction (SET) standard [16] with the scrip-based system of Millicent [17].

The SET framework safeguards payment information by encoding it with a one-time-use symmetric cipher, subsequently securing this key through encryption with the recipient’s public encryption credential. This method, referred to as the “digital envelope,” ensures confidentiality allows the recipient to decrypt the envelope with their private key and subsequently use the symmetric key to unlock the message. the proposed P2P protocol employs the “digital envelope” concept to secure all sensitive data exchanged between transacting parties [18]. By using “session-key encryption” [18], encryption efficiency is significantly improved since only the symmetric key undergoes asymmetric encryption, which is considerably slower (approximately 1000 times) than symmetric encryption [19]. Moreover, the digital envelope mechanism ensures that public-private key pairs remain resistant to cryptographic attacks [19,20].

Millicent’s scrip mechanism provides anonymity, privacy, and authenticity [21]. Each scrip, which includes a unique serial number, prevents double-spending and unauthorized modifications. Additionally, Millicent’s “Certificate” structure prevents counterfeiting and ensures that the scrip retains its value solely for its designated merchant. Since scrips are created on demand, maintaining an extensive repository for their storage becomes unnecessary [22]. By integrating peer-to-peer features with online trade, numerous enterprises are leveraging this framework to introduce innovative offerings. Organizations like Trymedia Systems, Lightshare, PinPost, Center-Span, and First Peer assert their capability to facilitate decentralized commerce via secure methods such as email-based transactions and Secure Socket Layer (SSL) encryption [8]. SSL has become the standard for secure communication on the web, ensuring encrypted and integrity-protected data transmission. In traditional SSL setups, vendors solely hold public encryption keys, whereas buyers retain their anonymity. Although SSL secures monetary information through encryption and offers better security compared to plaintext transmission, its contribution to overall payment security remains limited [23].

By leveraging the strengths of SET’s digital envelope technique and Millicent’s scrip-based approach, the proposed P2P payment protocol offers a secure, efficient, and anonymous transaction framework. Unlike conventional SSL-based solutions, which provide limited security benefits, this model ensures robust protection of both payment details and user privacy. As the adoption of P2P commerce continues to grow, such innovative payment mechanisms will be critical in enabling secure and decentralized economic transactions.

The role of SSL in secure transactions presents several limitations.

• When SSL is utilized with a broker, its security remains transparent since messages are not digitally signed. Consequently, the merchant does not benefit from additional security.
• SSL does not obscure sensitive financial details, such as bank account numbers, from merchants. Therefore, it is not suitable for identity-based authorization mechanisms.
• Unlike SET or the suggested peer-to-peer (P2P) framework, SSL does not mandate a distinct certification system. Consequently, buyers cannot reliably authenticate a seller’s encryption key.
• Vendors and intermediaries need additional mechanisms apart from SSL to safely exchange financial details and validation credentials.

An alternative peer-to-peer transaction mechanism of interest is PPay [24], which operates as an autonomous, lightweight payment framework utilizing dynamic, self-regulated electronic tokens in an offline setting. While PPay reduces the broker’s involvement and operational load, it does so at the expense of security. Although this design enhances system performance significantly, it renders the protocol inadequate for medium-to-large transactions, unlike the proposed P2P payment model.

A more secure version of PPay, known as WhoPay [25], provides a structured infrastructure for secure electronic commerce transactions while maintaining anonymity between transacting parties. However, WhoPay necessitates a substantial database for storing transaction scripts and does not fully account for the inherent instability of P2P networks [9]. The scalability of both PPay and WhoPay hinges on frequent transactions related to the transfer and renewal of digital scrips. These transactions necessitate the involvement of a third party acting as a substitute for the broker. If this third party is offline, the broker must intervene, thereby increasing its workload.

Consider, for instance, an electronic marketplace where customers sporadically enter the system to make purchases. In such a scenario, the intermittent participation of peer customers renders these protocols impractical.

2. Proposed Electronic-Payment Protocol

This paper introduces a novel electronic-payment protocol involving three principal entities:

• Customer: The party initiating the payment.
• Merchant: The entity receiving the payment.
• Acquirer Gateway: An intermediary bridging electronic payments with traditional financial infrastructures. It is responsible for transaction authorization [26]. This entity will henceforth be referred to as the broker.

The broker’s role is essential for establishing trust among transacting entities. However, its presence introduces the risk of a single point of failure [27], a common issue in client/server-based payment systems. Although the broker cannot be entirely eliminated due to its financial and security significance, its participation in transactions has been minimized within the proposed protocol to mitigate associated risks [28].

The remainder of this paper is structured as follows: Section 2 introduces the involved entities, key definitions, and notation [29]. Section 3 elaborates on the user registration mechanism and public key exchange process. Section 4 outlines potential security threats, while Section 5 details the security requirements for each entity. The payment process is discussed in Section 6. In Section 7, the computational burden on the broker is analyzed. Finally, Section 8 presents concluding remarks.

2.1. Protocol Terminology

The following terms define the components utilized in the protocol [30]:

• AcctNum: Represents the customer’s bank account number.
• AcctSecret: A composite secret comprising two elements: the broker’s confidential key and the peer customer’s or peer merchant’s private key. Both the broker and the respective peer possess this shared secret [31].
• PID: A distinct identifier associated with the peer customer or merchant, used for authentication. It is computed as: Hash(AcctSecret|Hash(AcctSecret)|AcctNum) [20].
• PeerID: A unique identifier assigned to each participant (peer) in the protocol, ensuring anonymity and preventing the disclosure of personal identity information [32].
• BankToken: A form of electronic currency issued by the broker (bank) [33].
• MerchantToken: A digital currency issued by a vendor, which can only be utilized within that merchant’s system [34].
• TokenStructure: Comprises multiple fields, as illustrated in Figure ...

...

2.2. Symbols and Notations

Table 1 presents the notation used for cryptographic operations within the protocol. Additionally, Table 1 provides an overview of the fundamental message elements used in the payment framework [35].

3. Public Key Infrastructure

The proposed decentralized payment protocol is designed around public key cryptography, requiring a method for verifying public keys. To achieve this, a certification authority (CA) is introduced, possessing a private key, while all participating entities hold the corresponding public key.

For simplification, this paper assumes a single certification authority, which is designated as the broker. In the outlined peer-to-peer payment system, the broker B maintains a private key for signing and encryption purposes. Its associated public key, which facilitates signature verification and encryption, is accessible to all registered customers and merchants. Similar to conventional banking operations, the broker securely stores the customers’ and merchants’ AcctSecrets while handling their respective PIDs, ensuring trust and confidentiality among all involved entities.

3.1. Peer Enrollment

When a peer entity (customer or merchant) initiates a request to create a banking account, their confidential details (such as account number and PANSecret) are securely stored in the broker’s database. Additionally, prior to the activation of the "peer-to-peer" communication framework, a cryptographic key pair (comprising a public and private key) is generated and saved locally in the user’s file system. The broker mandates that the peer entity provides a unique user ID along with their public key to finalize the registration process. This critical information is transmitted to the broker during the "Peer Enrollment" transaction phase (Figure 1).

In $M_0$, the user’s unique identifier (which remains confidential) and the attached cryptographic signature authenticates the transaction to the broker. Moreover, the session key encryption guarantees the confidentiality of transmitted data. The broker, upon receiving this request, cross-verifies the user’s information to check for pre-existing registrations, thereby mitigating potential replay attacks. Suppose the user is unregistered and the received message ($M_0$) contains valid data. In that case, the broker securely records the user’s details in the database and subsequently dispatches $M_1$ as a confirmation of successful transaction completion. In $M_1$, the broker’s cryptographic signature serves as proof to the user that the transaction has been duly authorized.

In Figure 1, the peer user constructs the following elements:

$$\begin{array}{cc}\hfill R_0& =\mathrm{Enrollment}\mathrm{request}\hfill \\ \hfill U_{I{D}_P}& =\mathrm{Peer}\mathrm{user}\text{’}\mathrm{s}\mathrm{unique}\mathrm{identifier}\hfill \\ \hfill PAN& =\mathrm{Peer}\text{’}\mathrm{s}\mathrm{bank}\mathrm{account}\mathrm{number}\hfill \\ \hfill I{D}_C& =\mathrm{Peer}\text{’}\mathrm{s}\mathrm{identity}\mathrm{data}\hfill \\ \hfill K_{P_u}& =\mathrm{Peer}\text{’}\mathrm{s}\mathrm{public}\mathrm{key}\hfill \\ \hfill K_{P_r}& =\mathrm{Peer}\text{’}\mathrm{s}\mathrm{private}\mathrm{key}\hfill \\ \hfill K_B& =\mathrm{Broker}\text{’}\mathrm{s}\mathrm{public}\mathrm{key}\hfill \\ \hfill K_0& =\mathrm{Randomly}\mathrm{generated}\mathrm{symmetric}\mathrm{key}\hfill \\ \hfill Y_0& =PAN\hfill \end{array}$$

(1)

The peer user then composes and transmits the following message to the broker:

$$\begin{array}{cc}\hfill M_0=(& R_0,U_{I{D}_P},{\mathrm{Enc}}_{K_0}\left({\mathrm{Sign}}_{K_{P_r}}\left(Y_0\right)\right),\hfill \\ \hfill & {\mathrm{Enc}}_{K_0}\left({\mathrm{SignOnly}}_{K_{P_r}}\left(I{D}_C\right)\right),\hfill \\ \hfill & {\mathrm{Enc}}_{K_0}\left(K_{P_u}\right),{\mathrm{PKEnc}}_{K_B}\left(K_0\right))\hfill \end{array}$$

(2)

Upon receiving this message, the broker extracts the user’s details and verifies whether the user has already been registered. If the user is not pre-registered, the broker decrypts and validates the message content. If the data integrity is confirmed, the broker formulates the response:

$$R_1=\mathrm{Enrollment}\mathrm{Confirmation}$$

(3)

$$U_{I{D}_B}=\mathrm{Broker}\text{’}\mathrm{s}\mathrm{unique}\mathrm{identifier}$$

(4)

$$I=\mathrm{Information}\mathrm{message}$$

(5)

$$Y_1=\{R_1,U_{I{D}_B},I\}$$

(6)

and constructs the message: $M_1=Y_1$, which is then relayed to the peer user.

3.2. Public Key Retrieval

All communications within the "peer-to-peer" framework leverage asymmetric encryption. Consequently, in addition to the broker’s public key, a peer entity (customer or merchant) must also obtain the public key of the corresponding third party (merchant or customer) participating in the transaction. Since the broker maintains a database of registered users and their respective public keys, a peer entity must formally request access to another peer’s public key before engaging in a financial transaction (Figure 2).

In $M_0$, the user’s cryptographic signature authenticates the request to the broker. Once the signature is validated, the broker queries the database to fetch the requested public key. This public key is then securely transmitted to the requesting user in message $M_1$.

In $M_1$, the broker’s digital signature guarantees the authenticity of the transmitted public key, ensuring that it has not been tampered with. Furthermore, encryption of the message ensures the confidentiality of the shared information.

4. Adversaries and Threats

In this context, I consider three distinct adversaries:

• Eavesdropper: An entity that intercepts communications with the intention of extracting sensitive data, such as financial credentials, PAN information, and unique identifiers.
• Active Attacker: A malicious entity that injects fraudulent messages into the system to manipulate its behavior.
• Insider: A legitimate user or an entity that has gained access to a legitimate user’s confidential data. For example, a dishonest vendor attempting to receive unauthorized payments from a customer.

The Internet is an open and decentralized network, where no single entity has complete control over network resources and functionalities. Consequently, there is always a risk that communication between trusted entities could traverse systems controlled by adversaries. Additionally, existing routing mechanisms lack inherent safeguards against cyber threats. Thus, message confidentiality and authentication cannot be presumed unless appropriate cryptographic protocols are implemented.

Another crucial concern is the reliability of merchants engaged in online transactions. The digital marketplace includes numerous small-scale vendors, often referred to as the cottage industry. It is relatively simple for an adversary to establish a fraudulent online storefront to harvest customers’ sensitive data ([36]). To mitigate this risk, customer identifiers must be securely transmitted to the broker without exposure to merchants. The merchant, in turn, only requires an authorization token from the broker to complete the transaction.

Furthermore, I identify three primary forms of attacks that could be initiated by customers or external adversaries: double-spending, faulty scrip generation, and scrip forgery. These attacks are described as follows:

• Double Spending: A scrip is generated using two confidential values: the MasterScripSecret and the MasterCustomerSecret, which remain exclusively known to the scrip issuer. To prevent reuse, each time a scrip is redeemed, its associated secrets are deleted from the issuer’s records, ensuring that it cannot be utilized for another transaction.
• Faulty Scrip Generation: In the payment protocol, participants can function as both customers and merchants, and they have the ability to create scrips. However, any generated scrip remains valid only for transactions with its originating entity, as it embeds the unique identifier of the producer (Figure 1).
• Scrip Forgery: A scrip consists of two components: a scrip body that holds transaction details and a cryptographic certificate that serves as its signature. Unauthorized modifications to the scrip body can be detected by verifying the integrity of the scrip’s signature.

5. Security Requirements

5.1. Issuer/Acquirer Security Measures

It is assumed that the issuer and acquirer share a baseline level of trust. Furthermore, a secure communication infrastructure is already in place between these entities, enabling them to collaborate securely. As a result, their roles and associated security requirements are unified.

• Verifiable Proof of Customer Authorization: Before the broker registers a debit transaction from a customer’s bank account, it must possess irrefutable proof that the account holder has authorized the payment. This proof should be non-replayable, preventing reuse for any other transaction. Additionally, since merchants are considered potential adversaries, they must not be able to fabricate unauthorized transactions.
• Verifiable Proof of Merchant Legitimacy: When a broker approves a payment to a specific merchant, it must retain a tamper-proof record indicating that the customer initiated the payment request and that the merchant is a verified entity.

5.2. Merchant Requirements

• Validation of Broker’s Transaction Authorization: The merchant must secure indisputable proof that the broker has sanctioned the transaction.
• Validation of Customer’s Transaction Authentication: Before obtaining approval from the broker, the merchant needs conclusive evidence that the customer has verified the transaction request. Furthermore, prior to forwarding the payment-related communication to the broker, the merchant must confirm that the respective customer genuinely initiated the request.

5.3. Customer Requirements

• Anonymity: Customers seek to remain anonymous to external observers and merchants. Merchants are only aware of the customer’s user identification number but cannot link it to personal details. Only the broker has access to such information. This property is essential in digital payment systems that aim to emulate the characteristics of cash transactions, such as the proposed peer-to-peer protocol.
• Privacy: The protocol ensures that customers’ order details and payment information remain confidential. For instance, an investor acquiring stock-related data may not wish for competitors to gain insights into their interests. Encryption mechanisms safeguard this information, preserving customer privacy. However, it should be noted that the protocol does not guarantee unlinkability between customers and merchants concerning the broker.
• Prevention of Unauthorized Charges: The system must prevent unauthorized debits from a customer’s bank account. Transactions should only be processed with valid credentials, including the bank account number, PAN-Secret, and the corresponding private key. Malicious entities, whether rogue actors on the internet or dishonest merchants, must be unable to fabricate fraudulent transactions that could gain broker approval. This security measure must hold even if the customer has participated in numerous legitimate transactions in the past. Specifically, sensitive customer identifiers should not be transmitted in plaintext and must be protected against brute-force attacks.
• Verification of Transaction Authorization by Broker: Customers may require proof that the broker has authorized a given transaction.
• Merchant Authentication: Customers should be able to verify that the merchant is a legitimate participant in the payment system.
• Purchase Receipt: Since the broker maintains a complete log of all transactions, issuing a receipt is optional.

6. Payment Processing

The subsequent sections outline the foundational steps of the proposed decentralized payment framework, illustrated through a use case involving a virtual marketplace for pre-owned items. These preliminary actions are essential for fostering trust between buyers and sellers.

In the first stage, termed “Acquire digital funds from the financial institution,” the purchaser secures virtual money by performing a singular large-scale transaction. Following this, during the “Exchange digital funds with the vendor” phase, a fraction of the obtained assets is traded for an equivalent sum in the seller’s digital currency, once again executing a high-value transfer.

A detailed flowchart depicting the payment process is illustrated in Figure 3.

6.1. Acquiring BrokerScrip from the Bank

A customer intending to make purchases in the electronic marketplace must first obtain BrokerScrip, which is later exchanged for VendorScrip to complete the transaction. This process begins when the customer connects with the broker and purchases the required amount of BrokerScrip using real currency (Figure 4). Once the transaction is validated, the broker provides the customer with a unique BrokerScrip. Notably, a user can possess only a single active BrokerScrip, which must be fully utilized before requesting another. This BrokerScrip functions as an instrument for acquiring digital currency from a seller.

In transaction message $M_0$, the combination of the customer’s digital signature and unique identification provides strong verification for the broker, ensuring that the transaction request is legitimate. Additionally, a nonce is included to prevent replay attacks, while encryption safeguards the customer’s identity and ensures message integrity.

Once the transaction request is validated, the broker generates the corresponding BrokerScrip and logs the transaction details for future reference, especially in the event of a dispute. The broker then sends the issued BrokerScrip in a new transaction message, $M_1$. This message includes the broker’s digital signature, confirming the authenticity of the issued BrokerScrip. Moreover, the inclusion of a nonce ensures that the message is not a replayed transaction. Encryption mechanisms provide an added layer of confidentiality.

As depicted in Figure 4, the process illustrates...

Upon receiving $M_1$, the customer decrypts the message, verifies the broker’s signature, and ensures that the value of the received BrokerScrip aligns with the requested amount. If all validations succeed, the customer securely stores the following encrypted values:

$$PKEn{c}_{K_C}\left(B_0\right)$$

(7)

$$PKEn{c}_{K_C}\left(CS{B}_0\right)$$

(8)

6.2. Converting BrokerScrip into VendorScrip

Each merchant exclusively accepts VendorScrip issued by them. Therefore, a customer who possesses BrokerScrip but lacks VendorScrip must initiate a conversion process before making a purchase. If the BrokerScrip’s value meets or exceeds the desired VendorScrip amount, the exchange transaction proceeds as illustrated in Figure 5.

In transaction message $M_0$, the customer provides their digital signature, identification details, and the associated CustomerSecret of the BrokerScrip. This information enables the broker to verify the customer’s authorization of the transaction. If valid, the broker logs the details for record-keeping.

Subsequently, the customer sends another message, $M_1$, to the merchant. This message, containing the customer’s digital signature, identification, and BrokerScrip details, serves as proof of authorization. The broker ensures that the message is not a replayed attempt by verifying the uniqueness of the BrokerScrip. Encryption ensures the confidentiality of transaction details, and only the broker can decrypt the customer’s ID. The merchant processes only their portion of the message:

$$(C_1,U_{I{D}_C},{\mathrm{Enc}}_{K_2}\left({\mathrm{Sign}}_{K_C}\left(X_2\right)\right),{\mathrm{PKEnc}}_{K_M}\left(K_2\right)).$$

(9)

Upon receiving the message, the merchant decrypts the content and validates the customer’s signature. The signature provides proof that the customer has authorized the transaction. If the received data is verified successfully, the merchant constructs $M_2$ and sends it to the broker. This message contains the merchant’s digital signature and identification details, verifying that the merchant approves the transaction. Additionally, encryption ensures the confidentiality of transaction details, particularly the merchant’s identification, and guarantees that only the broker can access the relevant information.

When the broker receives $M_2$, they decrypt the message, authenticate the signatures, and validate the associated transaction details, including the BrokerScrip and the parties involved. They also confirm that the transaction values match.

A transaction is considered legitimate if the worth of the BrokerScrip meets the required VendorScrip amount. Upon successful validation, the broker formulates two distinct messages: one directed to the customer ($M_3$) and another intended for the merchant ($M_4$). Additionally, the broker’s records are modified to reflect the transaction details.

In $M_3$, the broker’s digital signature serves as proof to the customer that the message originates from an authorized source. Encryption mechanisms ensure that the transmitted details remain confidential.

Likewise, in $M_4$, the broker’s digital endorsement confirms to the merchant that the exchange is authentic. Upon obtaining this communication, the merchant validates the broker’s authentication. If the verification succeeds, the merchant formulates $M_5$ and transmits it to the customer; otherwise, the process is halted.

For security purposes, $M_5$ incorporates the merchant’s digital signature, which provides strong proof to the customer that the transaction was authorized by the merchant. Additionally, session key encryption guarantees the confidentiality of the transmitted details.

The customer receives two messages: $M_3$ from the broker and $M_5$ from the merchant. The customer then decrypts and verifies the signatures of both messages, ensuring that the recorded values are accurate. If everything is valid, the customer securely stores the following encrypted values:

$${\mathrm{PKEnc}}_{K_C}\left(V_0\right)$$

(10)

$${\mathrm{PKEnc}}_{K_C}\left({\mathrm{CSV}}_0\right)$$

(11)

$${\mathrm{PKEnc}}_{K_C}\left(B_1\right)$$

(12)

$${\mathrm{PKEnc}}_{K_C}\left({\mathrm{CSB}}_1\right)$$

(13)

6.3. Purchase Transaction

When a customer possesses the appropriate MerchantScrip necessary for acquiring an item from a vendor, they initiate the transaction by transferring it to the merchant (Figure ). Upon receiving the scrip, the merchant validates its authenticity, deducts the required amount, and generates a new scrip reflecting the remaining balance, which is sent back to the customer. This process signifies the successful completion of the payment.

In $M_0$, the inclusion of a digital signature serves as proof to the broker that the customer has indeed authorized the transaction and that the transmitted data remains unaltered. When the broker receives this message, it verifies the signature and logs the transaction details into a secure record.

In $M_1$, the presence of CustomerKey, alongside the customer’s digital signature, assures the merchant of the transaction’s legitimacy. Additionally, encryption mechanisms safeguard the confidentiality of the exchanged information, allowing the merchant to detect any unauthorized modifications. Upon receiving the encrypted message, the merchant decrypts the contents, validates the signature, and verifies the provided MerchantScrip. Once confirmed, the merchant issues the remaining balance as a new MerchantScrip in a subsequent message ($M_2$). Finally, an informational message is dispatched to the broker ($M_3$).

In $M_2$, the merchant’s digital signature guarantees to the customer that the transaction has been properly authorized. Encryption further ensures confidentiality during transmission. When the customer receives this message, they decrypt its contents, verify the signature, and validate the amount of the newly issued MerchantScrip. The securely stored values, represented as ${\mathrm{PKEnc}}_{K_U}\left(V^{*}\right)$ and ${\mathrm{PKEnc}}_{K_U}\left({\mathrm{CSV}}^{*}\right)$, are retained locally for future reference.

For $M_3$, the broker is assured of the message’s integrity and the merchant’s authorization through digital signature verification. Upon successful validation, the broker retrieves the corresponding log entry and updates the transaction record accordingly.

6.4. Acquiring Sufficient Electronic Cash from the Bank

The customer always possesses a single instance of BrokerScrip, which serves as a medium for multiple transactions involving the acquisition of VendorScrips. Whenever the value of the desired VendorScrip exceeds the available BrokerScrip, a transaction is initiated (Figure 10).

In message $M_0$, the customer provides their identification, the scrip’s CustomerSecret, and a digital signature, ensuring that the broker can verify the legitimacy of the request. Encryption mechanisms are employed to maintain the confidentiality of the transmitted data. Furthermore, as the scrip is designed to be non-reusable, the broker is protected against replay attacks. Upon successful validation of the transmitted data, the broker constructs a new message, denoted as $M_1$, transmits it back to the customer, and logs the transaction details for record-keeping.

Within message $M_1$, the broker’s digital signature acts as a robust proof that the transaction has been authorized. Additionally, encryption guarantees that the contents of the communication remain confidential.

Upon receiving $M_1$, the customer decrypts its elements, verifies the broker’s signature, and confirms that the allocated amount of BrokerScrip corresponds to the requested value. Subsequently, the customer securely stores the encrypted components ${\mathit{PKEnc}}_{{\mathit{K}}_{\mathit{C}}}\left({\mathit{B}}_{\mathit{1}}\right)$ and ${\mathit{PKEnc}}_{{\mathit{K}}_{\mathit{C}}}\left({\mathit{CSB}}_{\mathit{1}}\right)$ locally for future use.

Figure 6. Buy Item

Figure 6. Buy Item

Figure 7. Obtain “enough” electronic cash from the bank

Figure 7. Obtain “enough” electronic cash from the bank

6.5. Acquiring Sufficient Electronic Cash from the Merchant

In a scenario where a customer has already engaged in transactions with a merchant and possesses VendorScrip issued by this specific merchant but requires additional funds because the item’s value surpasses the available VendorScrip balance, a supplementary transaction is initiated (Figure 11).

The customer generates message $N_0$ and transmits it to the broker. The corresponding CustomerSecret associated with the scrip (BrokerScrip/VendorScrip), along with the digital signature, serves as authentication proof, confirming that the customer has authorized the transaction. Furthermore, encryption mechanisms ensure both confidentiality and data integrity.

Upon receipt of the message, the broker processes the designated portion. The broker decrypts the relevant components, verifies the digital signature, and authenticates the provided BrokerScrip. Additionally, the broker evaluates whether the received BrokerScrip holds a value sufficient to cover the required difference $(X_1-X_2)$ in VendorScrip. If all conditions are met, the broker constructs message $N_1$, forwards it to the merchant, and locally records the received BrokerScrip, including any remaining balance. The transaction details are subsequently stored in a log file.

In message $N_1$, the broker’s digital signature functions as evidence to assure the merchant that the broker has authorized the transaction. Encryption techniques maintain the confidentiality of the transmitted information.

Upon receiving $N_1$, the merchant processes the concatenated message, which consists of two segments: the broker’s newly generated message and the original message forwarded from the customer. The merchant first handles the broker’s portion by decrypting its elements and verifying the signature. If the message elements are valid, the merchant then processes the customer’s portion by decrypting its contents, verifying the digital signature, and authenticating the VendorScrip. If all elements are validated, the merchant ensures that $X_1$ and $X_3$ are equal.

If these values align, the merchant generates two response messages: $N_3$ for the customer and $N_2$ for the broker.

In message $N_3$, the merchant’s digital signature serves as confirmation for the customer that the transaction has been approved. Additionally, encryption is applied to maintain data confidentiality.

Message $N_2$ contains the merchant’s digital signature, ensuring the broker that the merchant has officially approved the transaction. The broker verifies the signature and, upon successful validation, deletes the temporarily stored BrokerScrip. If any residual balance exists in BrokerScrip, the broker constructs message $N_4$, transmits it to the customer, and subsequently removes the temporary record of the change. Finally, the broker updates the transaction log file accordingly.

Message $N_4$ reassures the customer that the broker has validated and approved the transaction, as demonstrated by the broker’s digital signature. Encryption mechanisms continue to safeguard data integrity and confidentiality.

Upon successful processing, the customer receives the merchant’s confirmation message ($N_3$).

Figure 8. Obtain “enough” electronic cash from the merchant

Figure 8. Obtain “enough” electronic cash from the merchant

The customer decrypts the received elements and validates the accompanying digital signature. Subsequently, they verify whether the value of the received VendorToken matches the requested one. Once confirmed, the customer securely stores $PKEn{c}_{K_C}\left(V_2^{\prime }\right)$ and $PKEn{c}_{K_C}\left(CS{V}_2^{\prime }\right)$ for future reference.

Additionally, the customer receives the broker’s message ($M_4^{\prime }$), decrypts its components, and verifies its digital signature. Further, they ensure that the received BrokerToken corresponds to the expected value. Upon successful validation, the customer securely stores $PKEn{c}_{K_C}\left(B_2^{\prime }\right)$ and $PKEn{c}_{K_C}\left(CS{B}_2^{\prime }\right)$ in their local system.

6.6. BrokerToken Withdrawal

When the customer no longer wishes to make purchases in the electronic marketplace, they have the option to withdraw their BrokerToken and transfer its value back to their associated bank account (Figure 12).

In message $M_0^{\prime }$, the TokenSecret alongside the customer’s unique identifier and digital signature serves as proof of authorization for the transaction. Encryption mechanisms ensure both data confidentiality and integrity. Moreover, since the scrip is non-reusable, any replay attacks can be effectively identified and mitigated.

Upon receiving this message, the broker decrypts its contents and validates the digital signature. The broker then cross-checks the customer’s identity and verifies the BrokerToken. If all details are authenticated, the transaction is recorded, and the associated MasterTokenSecret and MasterCustomerSecret are securely erased. The broker then sends an acknowledgment message ($M_1^{\prime }$) to the customer, where the digital signature assures the customer that the transaction has been successfully authorized.

Finally, upon receiving this confirmation message, the customer verifies the signature’s authenticity. Once verified, they permanently delete the withdrawn BrokerToken and its corresponding TokenSecret from their local storage.

Figure 9. BrokerScrip withdraw

Figure 9. BrokerScrip withdraw

6.7. VendorScrip Withdrawal

Customers also have the option to withdraw their VendorScrip and transfer its equivalent value back into their bank accounts (Figure 10).

In transaction message $T_0$, the presence of the buyer’s distinct identifier and cryptographic signature provides assurance to the broker that the payment request is valid. Moreover, embedding the scrip’s CustomerSecret along with the purchaser’s digital endorsement allows the merchant to confirm the legitimacy of the transaction.

As VendorScrip is non-reusable, the merchant can effectively detect any replay attacks. Furthermore, the application of encryption guarantees both confidentiality and data integrity throughout the process.

Upon receiving $T_0$, the merchant decrypts the designated portion of the message, verifies the digital signature, and validates the received VendorScrip. If the provided details are accurate, the merchant constructs message $T_1$, transmits it to the broker, and temporarily stores the VendorScrip.

Figure 10. VendorScrip withdrawal process

Figure 10. VendorScrip withdrawal process

Within $T_1$, the merchant’s digital signature serves as authentication, proving to the broker that the transaction was authorized. Additionally, encryption ensures that the transmitted data maintains integrity and confidentiality. Once the broker receives this message, they process its components by decrypting the elements and verifying their respective signatures. The broker additionally authenticates the buyer’s credentials. Upon successful validation, they check whether $X_1$ corresponds to $X_2$. If the values align, two distinct response signals are produced: one designated for the vendor ($T_2$) and another for the purchaser ($T_3$). These are subsequently transmitted to their respective destinations, while a transaction entry is documented in a log file.

In $T_3$, the broker’s signature serves as verification for the customer, confirming that the transaction was officially authorized. Encryption ensures that the data remains confidential and intact during transmission. The customer receives the message, decrypts its contents, and verifies the digital signature. Once verified, they remove the VendorScrip and the associated CustomerSecret from their local repository.

Similarly, $T_2$ maintains confidentiality and integrity through encryption. Additionally, the merchant gains definitive proof of authorization via the broker’s digital signature. Upon receiving the message, the merchant verifies its authenticity and, if validated, retrieves and deletes the previously stored VendorScrip along with the associated MasterScripSecret and MasterCustomerSecret.

6.8. Expired Scrip

The scrip (BrokerScrip/VendorScrip) is associated with an expiration date, beyond which it becomes invalid. Upon expiration, a renewal process is triggered (Figure 14), where the expired scrip is sent back to its issuer for reauthorization. During this renewal, the PrimaryScripKey and PrimaryUserKey, which are linked to the scrip and stored within the issuer’s lookup repository, are refreshed. Simultaneously, the respective UserKey, residing in the user’s local storage, undergoes renewal.

In $M_0$, the digital signature, along with the corresponding UserKey of the scrip, serves as cryptographic proof that the user has authenticated the transaction. Additionally, encryption mechanisms safeguard the integrity and confidentiality of transmitted data. Moreover, the inherent non-reusable nature of the scrip guarantees that the transaction is not susceptible to replay attacks.

Upon receiving this request, the issuer decrypts the included elements and verifies the digital signature. Subsequently, the issuer validates the scrip and issues a replacement. The newly generated scrip contains:

• An updated expiration date,
• A fresh ScripID and UserID,
• A new certificate along with a newly assigned UserKey.

The only retained element between the old and the new scrip is their intrinsic value. The issuer then composes message $M_1$, transmits it to the user, and securely deletes the previous PrimaryScripKey and PrimaryUserKey associated with the expired scrip.

The digital signature appended to $M_1$ by the issuer serves as proof to the user that the transaction was properly authorized. Furthermore, encryption mechanisms ensure both the confidentiality and integrity of transmitted information.

Upon receiving $M_1$, the user decrypts its contents, verifies the authenticity of the signature, and confirms that the updated scrip holds the same value as the expired one. If all conditions are met, the user securely stores $PKEn{c}_{KU}\left(E_1\right)$ and $PKEn{c}_{KU}\left(US{E}_1\right)$ within their local repository.

Figure 11. Expired Scrip

Figure 11. Expired Scrip

7. Computational Overhead of the Broker

The proposed protocol is designed to minimize the broker’s involvement, thereby reducing their operational and computational burden. As previously discussed, the broker represents financial institutions and plays a crucial role in facilitating transactions. Within the payment protocol, the broker functions as both the entity responsible for payment authorization and as a recorder of transaction details.

Considering the three fundamental transaction phases in the protocol—1. “Issuing electronic cash from the bank,” 2. “Receiving electronic cash from the merchant,” and 3. “Executing a purchase transaction” (with other steps being supplementary to these)—the broker has a dual role in the first two steps: verifying transactions and maintaining transaction records. This results in significant computational overhead due to the requirement for multiple cryptographic operations. However, in the third phase, their role is limited to passive observation and logging, requiring only two signature verifications and updates to the transaction ledger.

Optimizing the protocol involves ensuring that the first two transaction phases, which establish trust between peers, occur less frequently than the third phase. This design ensures that in a peer-to-peer transaction model, the broker’s computational burden is effectively reduced.

8. Conclusion

This paper introduces a novel payment protocol that is adaptable to various network architectures, with a primary focus on P2P networks. The initial transaction phases—“Issuing electronic cash from the bank” and “Receiving electronic cash from the merchant”—are essential for establishing trust between the customer and the merchant. However, in the final transaction phase, where the actual purchase occurs, the broker’s role is significantly minimized and restricted to observing and logging transaction data. At the same time, the exchange is conducted directly between the customer and the merchant.

Furthermore, the proposed protocol meets all security and confidentiality requirements of the participating entities. It ensures robust privacy protection for customers and enables secure transactions, aligning with the fundamental principles of anonymity and data integrity in digital payment systems.