A blockchain-based cross-domain collaborative filtering system and method

Abstract

The application provides a cross-domain collaborative filtering system and method based on a blockchain, comprising a filtering execution layer, a filtering control layer and a filtering resource transaction layer; the filtering execution layer is composed of filtering autonomous domains and is responsible for executing filtering tasks issued by the upper layer; the filtering control layer is composed of autonomous domain control centers, each autonomous domain deploying a filtering mechanism has a filtering controller, and the internal information of the autonomous domain is independently stored and managed by each autonomous domain, so that the network data privacy of the autonomous domain can be effectively protected; the filtering resource transaction layer is a blockchain network communication system with the autonomous domain control center as a node, responsible for recording and tracing the service process of the filtering system and conducting transactions of filtering resources. The application uses the advantages of decentralization and non-tamperability of the blockchain, enhances the robustness of the system, makes the service process of the system transparent, and assetizes the filtering service of the filtering autonomous domain, so that the collaborative filtering autonomous domain can provide services in exchange for economic benefits.

Description

Technical Field

[0001] This invention belongs to the field of network security technology, specifically relating to a general cross-domain collaborative system and method based on blockchain. Background Technology

[0002] Throughout the decades of internet development, the internet has always been vulnerable to various security threats. Among them, Distributed Denial-of-Service (DDoS) attacks, due to their immense destructive power and ease of execution, have always been favored by attackers and have become a major threat to computer networks. To address this problem, researchers have proposed defense methods based on rerouting, bandwidth limiting, rate limiting, traffic engineering, and moving target redirection. However, these measures can only mitigate the damage caused by attacks to a certain extent and cannot completely purify the network or protect it from the pollution of attack traffic. To thoroughly purify malicious flows in the network, scientists have proposed filtering-based defense mechanisms to achieve the goal of purifying attack flows in the network. Existing filtering mechanisms are divided into independent filtering mechanisms and collaborative filtering mechanisms. Independent filtering supports individual network devices, often deployed and running within an autonomous system (AS), which then decides and creates its own filtering rules. Independent filtering is often easy to deploy because it does not require cooperation, communication, or trust with other ASs. However, it is not suitable for large-scale attacks; while DDoS attacks are cross-domain attacks and are highly decentralized in design. Therefore, it is difficult to defend against them with independent filtering mechanisms alone, so collaborative filtering mechanisms are currently the main approach. Argyraki K et al., in their paper "Scalable network-layer defense against internet bandwidth-flooding attacks," proposed a collaborative filtering mechanism. While this mechanism achieves both preventative and collaborative filtering and suggests leveraging other autonomous systems (AS) for filtering, it fails to consider the inherent selfishness and economic considerations among ASs, leading to a lack of deployment motivation and hindering the effective deployment of the filtering system. Furthermore, existing collaborative filtering methods employ a hop-by-hop mechanism, but this still has room for efficiency improvement. The main reason for this is that the network structure dictates that achieving network-wide filtering inevitably involves multiple ASs, requiring cooperation between them. However, as independent economic or political entities, ASs often lack trust due to competition for resources. In this trustless environment, to promote inter-AS cooperation, advance the practical deployment of the filtering system, and expand its scale, the filtering system must become a fair, just, equitable, voluntary, consensus-based, and trustworthy collaborative platform. However, the above architecture does not fully consider the business relationships between autonomous domains and assumes friendly cooperation between them. This assumption is obviously unrealistic and is not conducive to the actual deployment of the filtering system. Summary of the Invention

[0003] To address the aforementioned issues, this invention provides a blockchain-based cross-domain collaborative filtering system. The system comprises three layers, from bottom to top: a filtering execution layer, a filtering control layer, and a filtering resource transaction layer.

[0004] The filtering execution layer consists of autonomous domains with filtering executors. Filtering executors are deployed on the boundary routers of each autonomous domain and are responsible for executing the filtering tasks issued by the upper layer.

[0005] The filtering control layer consists of an autonomous domain control center. Each autonomous domain that deploys the purification mechanism has a filtering controller. Information within the autonomous domain (such as inter-domain routing) is stored and managed independently by each autonomous domain, which can effectively protect the privacy of autonomous domain network data.

[0006] The filtering resource transaction layer is a blockchain network communication system with an autonomous domain control center as the node. It is responsible for recording and tracing the filtering system service process and conducting filtering resource transactions.

[0007] The filter executor is used to monitor the number of available filters in real time and transmit it to the filter controller. Upon receiving a filter message from the filter control layer, it immediately executes the filter task and requests the relevant host to patch the vulnerability and stop sending attack streams. At the same time, it starts monitoring illegal traffic, checks the patch results, and submits them to the filter controller within the specified filtering time Tb.

[0008] The filtering controller obtains the routing paths between autonomous systems by listening to BGP (Border Gateway Protocol) router sessions. Each filtering controller provides two interfaces: one interface for communicating with the blockchain network communication system, and the other interface for installing filtering rules on the filtering executor.

[0009] The blockchain-based cross-domain collaborative filtering system includes service requesters, service providers, and computing entities. Service requesters are nodes with filtering needs, specifically nodes that detect attacks. Service providers are nodes that assetize their filtering resources and earn revenue by collaboratively completing filtering tasks for requesters. Service requesters can obtain filtering services from service providers, while service providers can assetize their filtering resources without compromising privacy and earn revenue by providing services. Computing entities earn revenue by selecting suitable filtering rules from the quotes offered by the quoting providers. Since some privacy data, such as routing topology, may be involved in the computation process, to ensure data privacy and secure computation and processing, nodes with SGX (Intel Software Guard Extensions) trusted hardware and strong computing capabilities can be used.

[0010] The filtered resource transaction layer involves a pre-purchase transaction process and a purchase transaction process;

[0011] The pre-purchase transaction process involves three roles: service demander SC, service provider SP, and computing provider SCP. When the service demander SC needs to purchase a service, it sends a pre-purchase request in the blockchain. Other autonomous systems with idle filtering resources, i.e., service providers, respond by sending quotation information. The computing provider SCP recommends the quotation to the service demander SC, and the service demander SC pays a computing service fee to the computing provider SCP.

[0012] The purchase transaction process involves two roles: the service requester (SC) and the service provider (SP). The service requester (SC) purchases services from the relevant service provider (SP) based on the set of quotes recommended by the computing provider (SCP).

[0013] This invention also provides a blockchain-based cross-domain collaborative filtering method, comprising the following steps:

[0014] (1) Registration: When a new node joins the blockchain, it needs to register and publish a series of declarations after successful registration, including address declaration and public key declaration. The address is the account name of the blockchain node. The filtering autonomous system can achieve anonymous transactions and communication through the account name. The account name is generated by the public key of the blockchain node and a blockchain node can have multiple account names. The public key is generated by the private key (not disclosed to the public). Both can be used for encryption and signing of transactions, and a node can hold multiple public keys.

[0015] (2) Pre-purchase filtering service: If the service requester detects an attack flow, a pre-purchase request is sent at the filtering transaction layer. In order to achieve transaction traceability, all requests and responses need to be recorded on the blockchain. In order to prevent malicious nodes from using address clustering to analyze the real identity information of the service requester and service provider and the real content of the transaction, we propose privacy protection schemes for them respectively.

[0016] (3) Purchasing services: Once the transaction negotiation is completed, the service requester (or transaction initiator) sends a purchase request to the corresponding autonomous system control center. The purchase request includes the set of malicious flows that need to be filtered and the filtering rules that need to be deployed on the autonomous system s. In order to prevent malicious nodes from eavesdropping on the transaction process, a corresponding privacy protection scheme is proposed.

[0017] (4) Filtering: For the filtering rules contained in the purchase request content, the autonomous system control center locates the filtering executor Rs on the corresponding ingress router, and then sends a filtering request to the filtering executor Rs to block the malicious flow. The blocking time is one period Tb.

[0018] (5) Stop: The filter executor Rs sends a stop request to the attack source Hs. Upon receiving this request, the qualified host will patch its security vulnerability and further stop sending data packets.

[0019] The pre-purchased filtering service includes the following steps:

[0020] Step 2.1: When the victim-as-a-service requester (SC) discovers that it has been attacked, it will publish a pre-purchase request containing a malicious stream set on the blockchain operation platform.

[0021] Step 2.2: After receiving the request, the remaining nodes that are willing to provide filtering services respond and generate their own pricing SP. i SP i This indicates that the quote was produced by the i-th service provider (or transaction recipient), and the quote includes the price, a set of filtered malicious flows, and collateral damages.

[0022] Step 2.3: Service requester SC selects service provider SP1, ..., SP1 based on the filtering requirements. i , ..., SP n And the calculation method SCP k Send a computation request request([SP1,SP2,…,SP) i ,…,SP n ],SCP k ) to the calculation side;

[0023] Step 2.4, Calculate SCP k Receive computation requests and initiate a request to the service provider to share data in order to obtain specific information about the quote;

[0024] Step 2.5, Service Providers SP1, ..., SP i , ..., SP n The quote will utilize the SCP calculation method. k The data, Data, encrypted with the SGX public key, is sent to the SCP (computing party) according to formula (1). k Perform secure calculations;

[0025]

[0026] Among them SGX pk It is SCP k SGX public key, SK_SP i It is SP i The private key, offer represents SP i The original quote data;

[0027] Step 2.6, Calculate SCP kAfter completing the secure calculation, the encrypted result EResult is sent to the service requester SC, as shown in formula (2);

[0028] EResult = PK_SC(Result) (2)

[0029] Where PK_SC represents the public key of SC, and Result represents the computation result in SGX.

[0030] Step 2.7: The service requester SC receives the calculation result Eresult. After confirming the result, the filtering strategy recommendation contract automatically completes the transfer. After the transfer is completed, the filtering recommendation calculation ends.

[0031] Step 2.8: The service requester (SC) sends the calculation results to the corresponding service provider (SP). i Initiate a request to purchase filtering resources;

[0032] Step 2.9, Service Provider SP i Upon receiving a purchase request, the system replies with a message indicating whether it is willing to provide the filtering service. If the confirmation message is N, indicating a refusal to provide the filtering service, the communication ends. If the confirmation message is Y, the service requester SC initiates an order transaction with the service provider, creates a filtering service contract, and transfers the required service fee into the contract wallet.

[0033] The purchase of services includes the following steps:

[0034] Step 3.1: The service requester (SC) sends the calculation results to the corresponding service provider (SP). i Initiate a request to purchase filtering resources;

[0035] Step 3.2, Service Provider SP i The system responds by sending the provided service content to the service requester (SC). The service requester (SC) checks whether the content meets the requirements. If it does not meet the requirements, it sends a response to reject the service and the transaction is terminated. If it meets the requirements, it sends a response to confirm the service and the service begins.

[0036] Step 3.3, Service Provider (SP) i Each service At that time, the service requester (SC) needs to send confirmation information to the service provider (SP). i For further use, otherwise the service provider SP i Services will be suspended for the service requester SC, where Tb represents the service provider's service time and n represents the number of time periods.

[0037] Step 3.4: After receiving the new confirmation, the service provider SP... iTo achieve the best results, the operation should be performed if the service requester (SC) uses the service for more than [time period]. Service Provider SP i The service will be discontinued to the service requester SC; if the service requester SC's usage time has not exceeded [the specified period]. Service Provider SP i The current status will be maintained to maximize profits; if the service provider SP... i If it is malicious and the service requester SC stops providing services, then the service requester SC will not provide services to the service provider SP. i Send any confirmation, and the service provider SP i They will not receive more service fees from the service requester, SC.

[0038] Step 3.5: Increment i by 1, i = 1, 2, 3...n. Repeat steps 3.3 and 3.4 until one side can no longer continue or there is no remaining time.

[0039] Step 3.6, SP at the end of the transaction i Calculate the fee based on the number of confirmed payments from the service requester (SC) and complete the transfer.

[0040] Privacy protection for service requesters (SCs) in pre-purchased filtering services includes the following steps:

[0041] Step A1: The service requester SC needs to possess multiple other people's public keys listp = {P0, P1, P2, ..., P...} m}, its own public and private key pair, and its own address H;

[0042] Step A2: The service requester SC uses elliptic cryptography to generate a corresponding value R for each public key, combining them into a public key set listr = {R0, R1, R2, ..., R}. n};

[0043] Step A3: The service requester SC uses another person's public key to transfer R... i The encryption produces the corresponding Y, denoted as Y = {Y0, Y1, Y2, ..., Y}. m}, as shown in formula (3), where Hp is the encryption function;

[0044] Y i =H p (R i (3)

[0045] Step A4: The service demander SC uses formula (4) to calculate m loop parameters in sequence, where the i-th loop parameter is represented as V. i, where V0 is a random number. If V0 is equal to the last looping parameter, a loop will be formed. If they are not equal, use formula (4) to calculate Y to close the loop.

[0046]

[0047] Step A5: Place the private key of the service requester SC at the end of listp and R at the end of listr. Perform a circular shift on listp and listr, and then select the corresponding V to obtain the signature S(listp, listr, V).

[0048] Privacy protection for service providers (SPs) in pre-purchase filtering services includes the following steps:

[0049] Step B1: Service requester SC selects two public keys A and B, random r and SP, and calculates a one-time public key L = Hs(rA)G + B, where A = aG, B = bG, a and b are the private keys corresponding to public keys A and B, G is a public variable, which is a base point on the elliptic curve, and Hs is a cryptographic hash function.

[0050] Step B2: The service requester SC uses the public key L to construct a new output address Add. b =H(L), transfer funds to this address and package the key RR = rG into the transaction, where H is a hash function; the service provider SP uses private keys a and b to check each transaction, and if the output address of a certain transaction satisfies the formula Add b =H(Hs(aRR)G+B), then the service provider SP can determine that the recipient of the transaction is itself;

[0051] Step B3: The service provider SP recovers the public key L = Hs(aRR)G+B and the private key s = Hs(aRR)+b corresponding to the address. At this time, the account Adda is the SP's personal anonymous account. Moreover, in order for the account to be used normally, the SP needs to publish the public key L of the account.

[0052] Privacy protection for transaction content in pre-purchase filtering services includes the following steps:

[0053] Step C1: The service requester SC encodes the transaction content onto a point M on the elliptic curve, and then encrypts M using SP's public key and its own generated random number r, resulting in C = {rP, M + rK}.

[0054] Step C2: Encrypt M using the public key of the service provider SP and the random number r generated by itself, resulting in C = {rP, M + rK}.

[0055] Step C3: After receiving the transaction, the service provider SP decrypts C using the private key S to obtain M = M + rK - S * rP;

[0056] Step C4: The service provider SP can obtain the specific transaction details by decoding M using elliptic curves.

[0057] Privacy protection during the transaction process of purchasing services includes the following steps:

[0058] Step D1, Escrow Assets: Both the service requester (SC) and the service provider (SP) contribute a portion of their assets and escrow them into a jointly signed account. Expenditures from this account require the joint signature of both parties. Subsequently, during the payment phase, the transaction status of each user in the payment channel cannot exceed the escrowed assets.

[0059] Step D2: Constructing the channel: User SC constructs a commitment transaction Cla and a revocable payment transaction RD1a, and submits them to user SP for signature; the Cla transaction is used to ensure that SP can obtain its escrowed assets in the event that user SC unilaterally terminates the channel, and RD1a is used to ensure that user SC can unilaterally retrieve its escrowed assets.

[0060] Step D3, Payment: When user SC pays 0.1 unit of asset to user SP, the states represented by C1a and RD1a must first be invalidated. User SC constructs and signs the default remedy transaction and sends it to user SP. Therefore, after user SC publishes C1a, user SP can publish BR1a. Then, both parties reconstruct the commitment transactions C2a and C2b and the revocable payment transactions RD2a and RD2b according to the balance distribution after payment, following the steps in the channel construction phase, thus completing the state change.

[0061] Step D4, Termination: When either user wishes to terminate the contract, they first announce the committed transaction. If the other user does not announce a default remedy transaction within the delay period, it indicates that the committed transaction is in its final state. The user then announces a revocable payment transaction to retrieve assets after the delay period.

[0062] The beneficial effects of this invention are as follows: This invention leverages the advantages of blockchain, such as decentralization and immutability, to enhance system robustness while making the system service process transparent, eliminating distrust between autonomous systems (AS / RS). This transforms the filtering system into a trusted filtering cooperation platform and assetizes the filtering services of AS / RS, allowing them to provide services in exchange for economic benefits. By protecting the commercial interests of AS / RS, the actual deployment of the traceability system is promoted. Attached Figure Description

[0063] Figure 1 A schematic diagram of a filtering architecture for a blockchain-based cross-domain collaborative filtering system provided by the present invention;

[0064] Figure 2 A pre-purchase workflow diagram of a blockchain-based cross-domain collaborative filtering method provided by this invention;

[0065] Figure 3 A purchase workflow diagram for a blockchain-based cross-domain collaborative filtering method provided by this invention;

[0066] Figure 4 This is a schematic diagram illustrating the use of off-chain channels to isolate transactions, as provided by the present invention. Detailed Implementation

[0067] The invention will be further explained below with reference to the accompanying drawings and specific implementation examples.

[0068] This invention provides a blockchain-based cross-domain collaborative filtering system, which consists of three layers, from bottom to top: a filtering execution layer, a filtering control layer, and a filtering resource transaction layer.

[0069] The filtering execution layer consists of autonomous systems (AS) with filtering executors. Filters are deployed on the border routers of each AS. The primary responsibility is to monitor the number of available filters in real time and transmit this information to the filtering controller. Upon receiving a filtering message from the filtering control layer, the layer immediately executes the filtering task and requests the relevant hosts to patch vulnerabilities and stop sending attack flows. Simultaneously, it begins monitoring illegitimate traffic, checks patch results, and submits the patching information to the filtering controller before the specified filtering time (Tb) expires. If the vulnerability is not patched within the specified time, the victim will impose further penalties on the relevant hosts to protect their interests; for example, the relevant hosts may lose access to the victim as punishment.

[0070] The filtering control layer consists of Autonomous System Control Centers (ASNCs), with each ASNC deploying a filtering mechanism independently equipped with a control center. The controller obtains the routing paths between ASNCs by listening to BGP router sessions. ASPATH is an important attribute in BGP routing update messages; it provides an ordered list of ASNCs that need to be traversed before reaching the destination. Each filtering controller provides one interface for communicating with the filtering coordinator and another interface for installing filters on the filtering executors. It is responsible for: ① issuing a registration request in the blockchain system, including the ASNC number, network prefix, number of available filters, routing paths between ASNCs, and the purchase price of each filter; ② immediately distributing the agreed-upon filtering tasks to the corresponding filtering executors after accepting the filtering transaction with the victim. The control center is essentially a device with data storage and processing capabilities, such as a cloud server. Uploading relevant data within an autonomous system (AS) such as inter-domain routing paths, filtering resources, and service fees to the control center for independent storage and management by each AS can effectively protect the privacy of AS network data. On the other hand, it frees the filtering system from the constraints of limited routing device resources. Furthermore, by leveraging the computing power of the control center, it not only reduces the computing power consumption of routing devices and ensures the stability of network transmission performance, but also enables faster processing of filtering requests, ensuring the high efficiency of the filtering service.

[0071] The filtering resource transaction layer is a blockchain network communication system with an Autonomous Domain (ADA) control center as the node, responsible for the coordination between filtering Autonomous Domains. Filtering Autonomous Domains need to register on the blockchain network to become blockchain nodes. During registration, relevant information such as address and public key must be publicly disclosed. The blockchain network communication system records all filtering requests, filtering responses, and related filtering service fee transfer information in a ledger format. Leveraging its decentralized and tamper-proof advantages, it makes the system service process transparent, thereby eliminating distrust between Autonomous Domains. Once this data is on the blockchain, it enables the supervision of the filtering system, preventing deceptive and repudiation behaviors, such as denying filtering response content or refusing to provide services after collecting service fees, and allowing for post-event accountability. The blockchain network communication system safeguards the legitimate interests of all filtering Autonomous Domains, greatly improving the credibility of the system architecture. Furthermore, the filtering resource transaction layer eliminates the coupling between Autonomous Domains, ensuring an independent and peer-to-peer relationship between Autonomous Domains under the filtering architecture, fully respecting the deployment wishes of Autonomous Domains, allowing Autonomous Domains to freely join / leave, reducing system complexity, and greatly enhancing the system's scalability and incremental deployment capabilities.

[0072] In a blockchain communication system, although all nodes act as autonomous system control centers, their roles in completing filtering tasks differ due to varying needs. Service Consumers (SCs) are nodes with filtering requirements, i.e., nodes detecting attacks. Service Providers (SPs) are nodes that assetize their filtering resources and earn revenue by collaboratively completing filtering tasks for the consumer. Consumers can obtain filtering services from SPs, while SPs can assetize their filtering resources without compromising privacy and earn revenue by providing services. Computers select and recommend suitable filtering rules from the quotes offered by the quoting provider and earn revenue. Since computation may involve some private data, such as routing topology, secure computation and processing with SGX trusted hardware and strong computing capabilities are crucial for protecting data privacy during computation.

[0073] like Figure 1 This system has five types of requests:

[0074] (1) Registration: When a new node joins the blockchain, it needs to register and publish a series of declarations after successful registration, including address declaration and public key declaration. The address is the account name of the blockchain node. The filtering autonomous system can achieve anonymous transactions and communication through the account name. The account name is generated by the public key of the blockchain node and a blockchain node can have multiple account names. The public key is generated by the private key (not disclosed to the public). Both can be used for encryption and signing of transactions, and a node can hold multiple public keys.

[0075] (2) Pre-purchase filtering service: If the service requester (SC) detects an attack flow, a pre-purchase request is sent at the filtering transaction layer.

[0076] (3) Purchase of services: Once the transaction negotiation is completed, the service requester (SC) sends a purchase request to the corresponding autonomous system control center. The purchase request includes the set of malicious flows that need to be filtered and the filtering rules that need to be deployed on the ASS. s indicates that the filtering will be completed on the ASS.

[0077] (4) Filtering: For the filtering rules contained in the purchase request content, the autonomous system control center locates the filter executor on the corresponding ingress router Rs, and then sends a filtering request to Rs to block the malicious flow. The blocking time is one period Tb.

[0078] (5) Stop: The filter executor Rs sends a stop request to the attack source Hs. Upon receiving this request, the qualified host will patch its security vulnerability and further stop sending data packets.

[0079] The filtered resource transaction layer involves pre-purchase transaction processes and purchase transaction processes.

[0080] The pre-purchase transaction process involves three roles: Service Requester (SC), Service Provider (SP), and Computation Controller (SCP). Blockchain technology ensures data security, trustworthiness, and traceability. When the Service Requester (SC) needs to purchase a service, it sends a pre-purchase request on the blockchain. Other Autonomous Systems (AS) with available filtering resources, i.e., Service Providers, respond by sending quotes. However, a distributed attack from hundreds of domains can involve hundreds of routers, meaning millions of filters are available to help block unwanted traffic. If coordination is inadequate—that is, filters are not correctly selected and allocated—the Service Requester (SC) may have to pay expensive service fees to achieve the filtering objective, or even pay for services that cannot be effectively filtered. Therefore, the Computation Controller (SCP) recommends suitable quotes from these offers to the Service Requester (SC), and the Service Requester (SC) also pays a computation service fee to the Computation Controller (SCP).

[0081] The purchase transaction process involves two roles: the service requester (SC) and the service provider (SP). The service requester (SC) purchases services from the relevant service provider (SP) based on a set of quotes recommended by the computing provider (SCP). In traditional transactions, a trusted third-party adjudicator would handle disputes between the two parties. However, because different autonomous domains in this system come from different network service providers, it is difficult to find an adjudicator to resolve service-related disputes. Therefore, we need a different purchasing methodology to protect the rights and interests of both parties.

[0082] like Figure 2 The pre-purchased filtering service includes the following steps:

[0083] Step 2.1: When the victim-as-a-service requester (SC) discovers that it has been attacked, it will publish a pre-purchase request containing a malicious stream set on the blockchain operation platform.

[0084] Step 2.2: After receiving the request, the remaining nodes that are willing to provide filtering services respond and generate their own pricing SP. i SP i This indicates that the quote was produced by the i-th service provider (or transaction recipient), and the quote includes the price, a set of filtered malicious flows, and collateral damages.

[0085] Step 2.3: Service requester SC selects service provider SP1, ..., SP1 based on the filtering requirements. i , ..., SP n And the calculation method SCP k Send a computation request request([SP1,SP2,…,SP) i ,…,SPn ],SCP k ) to the calculation side;

[0086] Step 2.4, Calculate SCP k Receive computation requests and initiate a request to the service provider to share data in order to obtain specific information about the quote;

[0087] Step 2.5, Service Providers SP1, ..., SP i , ..., SP n The quote will utilize the SCP calculation method. k The data, Data, encrypted with the SGX public key, is sent to the SCP (computing party) according to formula (1). k Perform secure calculations;

[0088]

[0089] Among them SGX pk It is SCP k SGX public key, SK_SP i It is SP i The private key, offer represents SP i The original quote data;

[0090] Step 2.6, Calculate SCP k After completing the secure calculation, the encrypted result EResult is sent to the service requester SC, as shown in formula (2);

[0091] EResult = PK_SC(Result) (2)

[0092] Where PK_SC represents the public key of SC, and Result represents the computation result in SGX.

[0093] Step 2.7: The service requester SC receives the calculation result Eresult. After confirming the result, the filtering strategy recommendation contract automatically completes the transfer. After the transfer is completed, the filtering recommendation calculation ends.

[0094] Step 2.8: The service requester (SC) sends the calculation results to the corresponding service provider (SP). i Initiate a request to purchase filtering resources;

[0095] Step 2.9, Service Provider SP i Upon receiving a purchase request, the system replies with a message indicating whether it is willing to provide the filtering service. If the confirmation message is N, indicating a refusal to provide the filtering service, the communication ends. If the confirmation message is Y, the service requester SC initiates an order transaction with the service provider, creates a filtering service contract, and transfers the required service fee into the contract wallet.

[0096] Existing service-oriented collaborative filtering mechanisms implicitly assume that both service providers and service requesters are trustworthy. However, in practice, untrustworthy service providers or requesters may exist. In such cases, service providers might receive payment from the requester but fail to provide the service, while dishonest requesters might use the filtering service without paying, thus undermining transaction fairness. The above analysis demonstrates the urgent need for a mechanism to ensure transaction fairness and protect the interests of honest participants. To this end, we designed a segmented payment purchase process, reducing economic losses by dividing service time, so that participants only suffer partial losses. This ensures that service requesters have no opportunity to use the filtering service without paying unless they accept financial penalties. Furthermore, transaction fairness also guarantees that service providers cannot receive payment without providing the service.

[0097] Figure 3 To illustrate the detailed workflow for purchasing services, since the filtering service requires a duration of Tb, we divide the time into n equal segments. Therefore, the length of each segment is... Where Tb represents the service provider's service time. The specific steps are as follows:

[0098] Step 3.1: The service requester (SC) sends the calculation results to the corresponding service provider (SP). i Initiate a request to purchase filtering resources;

[0099] Step 3.2, Service Provider SP i The system responds by sending the provided service content to the service requester (SC). The service requester (SC) checks whether the content meets the requirements. If it does not meet the requirements, it sends a response to reject the service and the transaction is terminated. If it meets the requirements, it sends a response to confirm the service and the service begins.

[0100] Step 3.3, Service Provider (SP) i Each service At that time, the service requester (SC) needs to send confirmation information to the service provider (SP). i For further use, otherwise the service provider SP i Services will be suspended for the service requester SC, where Tb represents the service provider's service time and n represents the number of time periods.

[0101] Step 3.4: After receiving the new confirmation, the service provider SP... i Perform the operation to obtain the best benefit. If the service requester (SC) runs out of usage time, the service provider (SP) will... i The service provider (SP) will cease providing services to the service requester (SC). If the service requester (SC) still has usage time remaining, the service provider (SP) will...i The current status quo will be maintained to maximize profits. Furthermore, if the service provider SP... i If it is malicious and the service requester SC stops providing services, then the service requester SC will not provide services to the service provider SP. i Send any confirmation, and the service provider SP i They will not receive more service fees from the service requester, SC.

[0102] Step 3.5: Increment i by 1, i = 1, 2, 3...n. Repeat steps 3.3 and 3.4 until one side can no longer continue or there is no remaining time.

[0103] Step 3.6, SP at the end of the transaction i Calculate the fee based on the number of confirmed payments from the service requester (SC) and complete the transfer.

[0104] Due to the transparency and decentralization of blockchain, the system achieves traceability and non-repudiation. However, these same characteristics also make it difficult to effectively protect on-chain privacy data, leading to privacy leaks. In the aforementioned pre-purchase process, the transaction is a one-time payment. To ensure that this information is not tampered with and is permanently stored, and to facilitate effective and reliable traceability of the transaction process for users, the filtering requests and responses during the pre-purchase stage, as well as the transaction records of both parties, need to be stored directly on the blockchain in ledger form. For example, a node with filtering needs will publish a purchase request in the blockchain system. To effectively prove that this request is genuine, it needs to be recorded in the blockchain system. To prevent other nodes from making invalid responses and wasting resources, we need to record the response information. However, since the data is stored on the blockchain in plaintext, and all participating nodes have equal access to the entire ledger, attackers can obtain sensitive information in the network by attacking nodes with weaker security, thereby spying on user privacy. For example, although the blockchain has a pseudonym mechanism—using hash addresses as the account names of blockchain nodes—malicious nodes can still analyze transaction records through address clustering and other methods to associate nodes with users' real identities. They can roughly deduce the routing path by analyzing request and response records in the ledger. For the purchasing process, a time-segmented approach is used to ensure transaction fairness in the absence of an adjudicator. The service requester will only continue providing service after the service provider sends a confirmation message to the service requester. This requires multiple communications between the two parties; however, attackers can identify the true sender and receiver by analyzing the traffic between nodes in the current network. Based on this, a privacy protection scheme will be proposed for the above two workflows.

[0105] Analysis of the pre-purchase workflow of the cross-domain collaborative filtering system reveals that the privacy data involved can be divided into two categories: identity privacy and transaction privacy. Identity privacy refers to the association between a user's real identity information and their blockchain address; transaction privacy refers to the transaction records and underlying information stored in the blockchain.

[0106] Regarding identity privacy, it is necessary to protect the privacy of both the transaction initiator and the transaction recipient. Since autonomous systems are managed separately by their respective ISPs (Internet Service Providers), they possess a certain degree of organization. Therefore, ring signature technology can be used for signing, ensuring the privacy and security of the transaction initiator: for each transaction input, all possible initiators are equally likely.

[0107] 1) The signer needs to possess: multiple other people's public keys listp = {P0, P1, P2, ..., P...} n} and its own public and private key pair.

[0108] 2) The signer uses elliptic cryptography to generate a corresponding R for each public key, and generates listr = {R0, R1, R2, ..., R}. n}

[0109] 3) The signer uses another person's public key to transfer R i The encryption generates the corresponding Y, denoted as {Y0, Y1, Y2, Y3, ..., Y}. n The specific formula is shown below, where Hp is the encryption function.

[0110] Y i =H p (Ri)

[0111] 4) The signer calculates V1 = V0^Y0 + H in sequence until V... (n+1) V0 is a random number. At this point, all public keys have been used. If V0 is equal to the last V, a loop will be formed. If they are not equal, the Y that closes the loop is calculated using the following formula.

[0112] V0 = V (n+1) ^Y^H

[0113] 5) The signer’s private key is placed at the end of listp, and R is placed at the end of listr. A circular shift is performed on listp and listr, and then the corresponding V is selected to obtain the signature S(listp, listr, V).

[0114] Privacy protection for service requesters (SCs) in pre-purchased filtering services includes the following steps:

[0115] Step A1: The service requester SC (or signer) needs to possess multiple other people's public keys listp = {P0, P1, P2, ..., P...} m}, its own public and private key pair, and its own address H;

[0116] Step A2: The service requester SC uses elliptic cryptography to generate a corresponding value R for each public key, combining them into a public key set listr = {R0, R1, R2, ..., R}. n};

[0117] Step A3: The service requester SC uses another person's public key to transfer R... i The encryption produces the corresponding Y, denoted as Y = {Y0, Y1, Y2, ..., Y}. m}, as shown in formula (3), where Hp is the encryption function;

[0118] Y i =H p (R i (3)

[0119] Step A4: The service demander SC uses formula (4) to calculate m loop parameters in sequence, where the i-th loop parameter is represented as V. i , where V0 is a random number. If V0 is equal to the last looping parameter, a loop will be formed. The inequality formula (4) is used to calculate Y that makes the loop close.

[0120]

[0121] Step A5: Place the private key of the service requester SC at the end of listp and R at the end of listr. Perform a circular shift on listp and listr, and then select the corresponding V to obtain the signature S(listp, listr, V).

[0122] For the transaction recipient, a one-time public-private key pair is used. The initiator can generate a new one-time public key based on the recipient's long-term public key. Only the recipient can calculate the corresponding private key from the new public key, and it cannot be associated with the recipient's long-term public key by other users. In this way, while ensuring that the same recipient has a different receiving address for each transaction, the sender can construct transactions independently without the recipient needing to provide the new public key.

[0123] Privacy protection for service providers (SPs) in pre-purchase filtering services includes the following steps:

[0124] Step B1: Service requester SC selects two public keys A and B, random r and SP, and calculates a one-time public key L = Hs(rA)G + B, where A = aG, B = bG, a and b are the private keys corresponding to public keys A and B, G is a public variable, which is a base point on the elliptic curve, and Hs is a cryptographic hash function.

[0125] Step B2: The service requester SC uses the public key L to construct a new output address Add. b =H(L), transfer funds to this address and package the key RR = rG into the transaction, where H is a hash function; the service provider SP uses private keys a and b to check each transaction, and if the output address of a certain transaction satisfies the formula Add b =H(Hs(aRR)G+B), then the service provider SP can determine that the recipient of the transaction is itself;

[0126] Step B3: The service provider SP recovers the public key L = Hs(aRR)G+B and the private key s = Hs(aRR)+b corresponding to the address. At this time, the account Adda is the SP's personal anonymous account. Moreover, in order for the account to be used normally, the SP needs to publish the public key L of the account.

[0127] Regarding transaction privacy, the main reason we need to protect against privacy leaks is that data in the blockchain exists in plaintext. To solve this problem, we use Elliptic Curve Cryptography (ECC) to encrypt the content in the blockchain. We need to select an elliptic curve within the Fq domain to obtain the relevant parameters, as shown in Table 1. Additionally, we need the keys of both communicating parties, including a public key K and a private key S. The public key is publicly disclosed, while the private key is kept private. The public and private keys satisfy the following relationship: K = S * P. Suppose SC wants to conduct an encrypted transaction with SP. SC encodes the transaction content onto a point M on the elliptic curve, and then encrypts M using SP's public key and its own generated random number r, resulting in C = {rP, M + rK}. After receiving the transaction, SP decrypts C using its private key S to obtain M = M + rK - S * rP. Then, decoding M using the elliptic curve yields the specific transaction content. The relevant parameters of the elliptic curve are explained in Table 1.

[0128] Privacy protection for transaction content in pre-purchase filtering services includes the following steps:

[0129] Step C1: The service requester SC encodes the transaction content onto a point M on the elliptic curve, and then encrypts M using SP's public key and its own generated random number r, resulting in C = {rP, M + rK}.

[0130] Step C2: Encrypt M using the public key of the service provider SP and the random number r generated by itself, resulting in C = {rP, M + rK}.

[0131] Step C3: After receiving the transaction, the service provider SP decrypts C using the private key S to obtain M = M + rK - S * rP;

[0132] Step C4: The service provider SP can obtain the specific transaction details by decoding M using elliptic curves.

[0133] Table 1. Explanation of relevant parameters for elliptic curves

[0134]

[0135] Analysis of the purchase workflow of the cross-domain collaborative filtering system reveals that, because we ensure fairness in transactions by using time-segmented payment methods during the transaction phase, we don't need to record the entire transaction process on the blockchain. Only the final result needs to be recorded, thus addressing the limited capacity of the blockchain ledger. Based on this, we can employ off-chain channel isolation technology. Users can create channels by recording the initial state on the blockchain, and then conduct transactions off-chain. Specific data is secured through contracts but not publicly recorded on the blockchain. When a transaction needs to be terminated, the latest ending state is published and recorded on the blockchain, terminating the channel and destroying historical transaction records. Specifically... Figure 4 As shown.

[0136] Privacy protection during the transaction process of purchasing services includes the following steps:

[0137] Step D1, Escrow Assets: Both the service requester (SC) and the service provider (SP) contribute a portion of their assets and escrow them into a jointly signed account. Expenditures from this account require the joint signature of both parties. Subsequently, during the payment phase, the transaction status of each user in the payment channel cannot exceed the escrowed assets.

[0138] Step D2: Constructing the channel: User SC constructs a commitment transaction Cla and a revocable payment transaction RD1a, and submits them to user SP for signature; the Cla transaction is used to ensure that SP can obtain its escrowed assets in the event that user SC unilaterally terminates the channel, and RD1a is used to ensure that user SC can unilaterally retrieve its escrowed assets.

[0139] Step D3, Payment: When user SC pays 0.1 unit of asset to user SP, the states represented by C1a and RD1a must first be invalidated. User SC constructs and signs the default remedy transaction and sends it to user SP. Therefore, after user SC publishes C1a, user SP can publish BR1a. Then, both parties reconstruct the commitment transactions C2a and C2b and the revocable payment transactions RD2a and RD2b according to the balance distribution after payment, following the steps in the channel construction phase, thus completing the state change.

[0140] Step D4, Termination: When either user wishes to terminate the contract, they first announce the committed transaction. If the other user does not announce a default remedy transaction within the delay period, it indicates that the committed transaction is in its final state. The user then announces a revocable payment transaction to retrieve assets after the delay period.

Claims

1. A blockchain-based cross-domain collaborative filtering method, characterized in that, Includes the following steps: (1) Registration: When a new node joins the blockchain, it needs to register and publish a series of declarations after successful registration, including address declaration and public key declaration. The address is the account name of the blockchain node. The filtering autonomous system can realize anonymous transactions and communication through the account name; the account name is generated by the public key of the blockchain node and a blockchain node can have multiple account names; the public key is generated by the private key. Both can be used for the encryption and signing of transactions, and a node can hold multiple public keys. (2) Pre-purchase filtering service: If the service requester detects an attack flow, a pre-purchase request is sent at the filtering transaction layer, and all requests and responses are recorded on the blockchain; and privacy protection is designed to prevent malicious nodes from using address clustering to analyze the real identity information of the service requester and the service provider and the real content of the transaction. (3) Purchasing services: Once the transaction negotiation is completed, the service requesting party sends a purchase request to the corresponding autonomous system control center. The purchase request includes the set of malicious flows that need to be filtered and the filtering rules that need to be deployed on the autonomous system s. Privacy protection is designed to prevent malicious nodes from eavesdropping on the transaction process. (4) Filtering: For the filtering rules contained in the purchase request content, the autonomous system control center locates the filtering executor Rs on the corresponding ingress router, and then sends a filtering request to the filtering executor Rs to block the malicious flow. The blocking time is one period Tb. (5) Stop: The filter executor Rs sends a stop request to the attack source Hs. After receiving this request, it patches the security vulnerability through the host and further stops sending data packets; The pre-purchased filtering service includes the following steps: Step 2.1: When the victim-as-a-service requester (SC) discovers that it has been attacked, it will publish a pre-purchase request containing a malicious stream set on the blockchain operation platform. Step 2.2: After receiving the request, the remaining nodes that are willing to provide filtering services respond and generate their own pricing SP. i SP i This indicates that the quote was produced by the i-th service provider, and the quote includes the price, a set of filtered malicious flows, and collateral damage. Step 2.3: Service requester (SC) selects service provider based on filtering requirements. and calculation method Send a calculation request To the calculation side; Step 2.4, Calculation Method Receive computation requests and initiate a request to the service provider to share data in order to obtain specific information about the quote; Step 2.5, Service Provider Use calculation method to quote The data, Data, encrypted with the SGX public key, is sent to the computing party according to formula (1). Perform secure calculations; （1） in yes SGX public key, yes The private key, offer means The original quote data; Step 2.6, Calculation Method After completing the secure calculation, the encrypted result EResult is sent to the service requester SC, as shown in formula (2); （2） in, This represents the public key of SC, and Result represents the computation result in SGX; Step 2.7: The service requester SC receives the calculation result Eresult. After confirming the result, the filtering strategy recommendation contract automatically completes the transfer. After the transfer is completed, the filtering recommendation calculation ends. Step 2.8: The service requester (SC) sends the calculation results to the corresponding service provider. Initiate a request to purchase filtering resources; Step 2.9, Service Provider Upon receiving a purchase request, the system replies with a message indicating whether it is willing to provide the filtering service. If the confirmation message is N, indicating a refusal to provide the filtering service, the communication ends. If the confirmation message is Y, the service requester SC initiates an order transaction with the service provider, creates a filtering service contract, and transfers the required service fee into the contract wallet.

2. The blockchain-based cross-domain collaborative filtering method according to claim 1, characterized in that, The purchase of services includes the following steps: Step 3.1: The service requester (SC) sends the calculation results to the corresponding service provider. Initiate a request to purchase filtering resources; Step 3.2, Service Provider The system responds by sending the provided service content to the service requester (SC). The service requester (SC) checks whether the content meets the requirements. If it does not meet the requirements, it sends a response to reject the service and the transaction is terminated. If it meets the requirements, it sends a response to confirm the service and the service begins. Step 3.3, Service Provider Each service At that time, the service requester (SC) needs to send confirmation information to the service provider. For further use, otherwise the service provider Service to the service requester SC will be suspended, where Tb represents the service provider's service time. Indicates the number of time periods divided; Step 3.4: After receiving the new confirmation, the service provider... Perform operations to generate revenue if the service requester SC's usage time exceeds [a certain period]. Service Provider The service will be discontinued to the service requester SC; if the service requester SC's usage time has not exceeded [the specified period]. Service Provider We will maintain the current status in order to gain more profit; If the service provider If it is malicious and the provider stops providing services to the service requester SC, then the service requester SC will not provide services to the service provider. Send any confirmation, and the service provider They will not receive more service fees from the service requester, SC. Step 3.5, let Add 1, Repeat steps 3.3 and 3.4 until one side can no longer continue or there is no remaining usage time; Step 3.6, Service Provider at the end of the transaction Calculate the fee based on the number of confirmed payments from the service requester (SC) and complete the transfer.

3. The blockchain-based cross-domain collaborative filtering method according to claim 1, characterized in that, Privacy protection for service requesters (SCs) in pre-purchased filtering services includes the following steps: Step A1: The service requester (SC) needs to possess multiple other people's public keys. Its own public and private key pair and its own address H; Step A2: The service requester SC uses elliptic cryptography to generate a corresponding value R for each public key, which are then combined to form a public key set. ; Step A3: The service requester SC uses another person's public key to... Encryption produces the corresponding Y, denoted as As shown in formula (3), where Hp is the encryption function; Y i = H p (R k ) (3) Step A4: The service demander SC uses formula (4) to calculate m loop parameters in sequence, where the i-th loop parameter is represented as... ,in If it is a random number, If the last looping parameter is equal to the last looping parameter, a loop will be formed. If they are not equal, use formula (4) to calculate Y to close the loop. （4） Step A5: Place the private key of the service requester SC at the end of listp and R at the end of listr. Perform a circular shift on listp and listr, and then select the corresponding V to obtain the signature. ; Privacy protection for service providers (SPs) in pre-purchase filtering services includes the following steps: Step B1: The service requester SC selects two public keys A and B, a random value r and SP, to compute a one-time public key. ,in, , a and b are the private keys corresponding to public keys A and B, respectively, and G is a public variable, which is a base point on the elliptic curve. It is a cryptographic hash function; Step B2: The service requester SC uses the public key L to construct a new output address. Transfer funds to that address and send the key. Packaged into the transaction, where H is a hash function; the service provider SP uses private keys a and b to check each passed transaction, and if the output address of a certain transaction satisfies the formula... Then the service provider (SP) can determine that the recipient of the transaction is itself; Step B3: The service provider (SP) restores the public key corresponding to the address. and private key At this point, account Adda is SP's personal anonymous account, and in order for the account to be used normally, SP needs to publish the account's public key L.

4. The blockchain-based cross-domain collaborative filtering method according to claim 1, characterized in that, Privacy protection for transaction content in pre-purchase filtering services includes the following steps: Step C1: The service requester SC encodes the transaction content onto a point M on the elliptic curve, and then encrypts M using SP's public key and its own generated random number r. The result is... ; Step C2: Encrypt M using the public key of the service provider SP and its own generated random number r, resulting in... ; Step C3: After receiving the transaction, the service provider SP decrypts C using its private key S to obtain... ; Step C4: The service provider SP decodes M using elliptic curves to obtain the specific transaction details.

5. The blockchain-based cross-domain collaborative filtering method according to claim 1, characterized in that, Privacy protection during the transaction process of purchasing services includes the following steps: Step D1, Escrow Assets: Both the service requester (SC) and the service provider (SP) contribute a portion of their assets and escrow them into a jointly signed account. Expenditures from this account require the joint signature of both parties. Subsequently, during the payment phase, the transaction status of each user in the payment channel cannot exceed the escrowed assets. Step D2: Constructing the Channel: User SC constructs a commitment transaction Cla and a revocable payment transaction RD1a, and submits them to user SP for signature; the Cla transaction is used to ensure that SP can obtain its escrowed assets in the event that user SC unilaterally terminates the channel, and RD1a is used to ensure that user SC can unilaterally retrieve its escrowed assets. Step D3, Payment: When user SC pays 0.1 units of asset to user SP, the states represented by C1a and RD1a must first be invalidated. User SC constructs and signs the default remedy transaction and sends it to user SP. Therefore, after user SC publishes C1a, user SP can publish BR1a. Then, both parties reconstruct the commitment transactions C2a and C2b and the revocable payment transactions RD2a and RD2b according to the balance distribution after payment, following the steps in the channel construction phase, thus completing the state change. Step D4, Termination: When either user wishes to terminate the contract, they shall first announce the committed transaction. If the other user does not announce a default remedy transaction within the delay period, it indicates that the committed transaction is in its final state. The user shall then announce a revocable payment transaction to retrieve assets after the delay period.

6. A blockchain-based cross-domain collaborative filtering system, said system being used to implement the blockchain-based cross-domain collaborative filtering method of claim 1, characterized in that, The system is divided into three layers, from bottom to top: the filter execution layer, the filter control layer, and the filter resource transaction layer. The filtering execution layer consists of autonomous domains with filtering executors. Filtering executors are deployed on the boundary routers of each autonomous domain and are responsible for executing the filtering tasks issued by the upper layer. The filtering control layer consists of an autonomous domain control center. Each autonomous domain that deploys the purification mechanism has a filtering controller. Information within the autonomous domain is stored and managed independently by each autonomous domain, which can effectively protect the privacy of autonomous domain network data. The filtering resource transaction layer is a blockchain network communication system with an autonomous domain control center as the node. It is responsible for recording and tracing the filtering system service process and conducting filtering resource transactions.

7. A blockchain-based cross-domain collaborative filtering system according to claim 6, characterized in that, The filter executor is used to monitor the number of available filters in real time and transmit it to the filter controller. Upon receiving a filter message from the filter control layer, it immediately executes the filter task and requests the relevant host to patch the vulnerability and stop sending attack streams. At the same time, it starts monitoring illegal traffic, checks the patch results, and submits them to the filter controller within the specified filtering time Tb. The filter controller obtains the routing paths between autonomous systems by listening to BGP router sessions. Each filter controller provides two interfaces: one for communicating with the blockchain network communication system and the other for installing filter rules on the filter executor.

8. A blockchain-based cross-domain collaborative filtering system according to claim 6 or 7, characterized in that, The blockchain-based cross-domain collaborative filtering system includes service requesters, service providers, and computing entities. Service requesters are nodes with filtering needs, i.e., nodes that detect attacks. Service providers are nodes that assetize their filtering resources and earn revenue by collaboratively completing filtering tasks for requesters. Service requesters obtain filtering services from service providers, who, without disclosing privacy information, assetize their filtering resources and earn revenue by providing services. Computing entities earn revenue by selecting recommended filtering rules from quotes offered by quoting providers.

9. A blockchain-based cross-domain collaborative filtering system according to claim 8, characterized in that, The filtered resource transaction layer involves a pre-purchase transaction process and a purchase transaction process; The pre-purchase transaction process involves three roles: service demander SC, service provider SP, and computing provider SCP. When the service demander SC needs to purchase a service, it sends a pre-purchase request in the blockchain. Other autonomous systems with idle filtering resources, i.e., service providers, respond by sending quotation information. The computing provider SCP recommends the quotation to the service demander SC, and the service demander SC pays a computing service fee to the computing provider SCP. The purchase transaction process involves two roles: the service requester (SC) and the service provider (SP). The service requester (SC) purchases services from the relevant service provider (SP) based on the set of quotes recommended by the computing provider (SCP).

Images