An onion service co-residence identification method based on proof of work difficulty

Abstract

The application discloses an onion service co-residence identification method based on work quantity proof difficulty, and belongs to the technical field of network security. The first target onion service which has enabled work quantity proof defense is alternately applied with and stopped from introducing request load, so that processing occupation is generated on a shared processing resource; meanwhile, according to the onion address of the second target onion service, a service descriptor thereof is periodically acquired from an onion service directory system, and a recommended difficulty value of the work quantity proof is extracted to construct a difficulty response sequence; the rising amount of the difficulty response sequence in the load application stage relative to the load stoppage stage is calculated as a co-residence correlation degree, and compared with a preset threshold value, so that whether the two onion services share the processing resource is determined through multi-round statistical verification. The application does not need to control any relay node, can remotely observe the difficulty signal according to the reading of the public descriptor of the onion address, and is suitable for security evaluation and homologous service correlation detection of an anonymous network.

Description

Technical Field

[0001] This invention belongs to the field of network security technology, specifically relating to a method for identifying co-occurrence of onion services based on proof-of-work difficulty, applicable to security assessment and same-origin service association detection in anonymous communication systems. Background Technology

[0002] Anonymous communication systems aim to protect the confidentiality of communication content and the privacy of the identities of both parties. Tor (The Onion Router) is one of the most widely used anonymous communication systems, supporting the anonymous deployment of various TCP services, including web services and SSH services. These anonymous services are also known as hidden services or Onion services. The Tor network consists of a large number of volunteer-run nodes worldwide, protecting the security of communication content and user identities through multi-layered encryption and multi-hop routing.

[0003] The Tor service mechanism is one of the core functions of the Tor network. For example... Figure 1 As shown, when the Tor service starts, it generates a master identity public / private key pair and uses the public key to create its Tor address. The Tor service first selects several Tor nodes as introduction points (IPs) and encapsulates the introduction point information into a Tor service descriptor, which is then uploaded to several designated HSDir nodes. These HSDir nodes constitute the Tor service directory system for storing and providing Tor service descriptors. When a Tor client accesses the Tor service, it obtains the service descriptor from the HSDir nodes based on the Tor address, initiates an introduction request to the Tor service via the introduction point, and then selects a rendezvous point (RP) to establish a communication circuit. The inner encryption layer of the Tor service descriptor can be decrypted using a key derived from the Tor address; therefore, anyone who knows the Tor address can obtain and parse the Tor service descriptor from HSDir.

[0004] To mitigate flooding denial-of-service attacks targeting the Tor service, Tor introduced a Proof-of-Work (PoW) defense mechanism in its latest version. For example... Figure 2As shown, the Onion service first performs cell decryption, parsing, and proof-of-work verification on its main thread upon receiving an inbound request. Inbound requests that pass verification are then placed into a priority queue of convergence requests sorted by difficulty. The Onion service runs a difficulty control loop at a fixed update cycle. If there is a backlog in the priority queue during that update cycle (i.e., there are pending convergence requests in the queue with a difficulty not lower than the current suggested difficulty value), the publicly announced suggested difficulty value (suggested_effort) is increased additively. If there is no queue backlog during that update cycle and the current queue length is below the low-water mark threshold, the suggested difficulty value is decreased multiplicatively (by a factor of two-thirds). In other cases, the suggested difficulty value remains unchanged. When the suggested difficulty value changes significantly from the previous publication, the updated suggested difficulty value is written to a new service descriptor and published to the HSDir node, thus becoming publicly available. Before initiating an inbound request, the client needs to solve a computational puzzle of corresponding difficulty based on the suggested difficulty value. The suggested difficulty value is a state quantity that the Onion service dynamically adjusts and publicly publishes based on its real-time load.

[0005] In actual deployments, for operational considerations, operators often deploy multiple Tor services on the same physical host, or even run them within the same Tor process. The core processing logic of the Tor process runs on a single main thread, which is shared by multiple Tor services within the same process; similarly, multiple processes on the same host share the host's processor and other resources. The decryption, parsing, and proof-of-work verification of incoming request information, as well as the processing of aggregated requests, are all performed on the main thread. Therefore, when one Tor service experiences a high load of incoming requests and consumes shared processing resources, the request processing of other Tor services hosted on the same server will be slowed down.

[0006] However, current technologies lack effective means to remotely determine whether multiple Onion services are hosted by the same process or the same physical host. On the one hand, traditional correlation and deanonymization methods often rely on global traffic correlation or control of relay nodes, which are demanding and violate the anonymity protection principle of Onion services. On the other hand, existing network security auditing tools cannot utilize the publicly disclosed difficulty signals of the Onion service's proof-of-work mechanism. They cannot perceive the mutual influence between co-hosted services due to shared processing resources, nor can they remotely correlate and determine whether multiple Onion services co-host without controlling any relays. This technological gap restricts the improvement of the ability to detect and assess the correlation of services originating from the same source in anonymous networks. Summary of the Invention

[0007] The purpose of this invention is to provide a method for identifying co-residence of Tor services based on proof-of-work difficulty, addressing the problem of existing anonymous networks lacking effective means to remotely determine whether multiple Tor services are co-resident. This invention leverages the characteristic that co-resident Tor services share processing resources, and the observable characteristic of the Tor service's proof-of-work mechanism that "slower aggregation request release leads to a backlog in the aggregation request priority queue, thereby increasing the publicly disclosed proposal difficulty value." By applying load to one target Tor service and observing the publicly disclosed proposal difficulty value of another target Tor service, the invention remotely determines whether two Tor services are co-resident based on their correlation, without controlling any Tor relay nodes.

[0008] To achieve the above objectives, the present invention adopts the following technical solution: a method for identifying co-residence of onion services based on proof-of-work difficulty, comprising the following steps:

[0009] (1) Determination of target service pair: Select two target onion services that have both enabled proof-of-work defense mechanism, denoted as the first target onion service and the second target onion service;

[0010] (2) Applying load detection: Apply an introductory request load to the first target onion service, causing the first target onion service to occupy the shared processing resources of its process or host, and apply it alternately in the ON and OFF phases. Apply the introductory request load in the ON phase and stop applying the introductory request load in the OFF phase.

[0011] (3) Difficulty response observation: While applying the probe load, the service descriptor of the second target onion service is periodically obtained from the onion service catalog system according to the onion address of the second target onion service. The suggested difficulty value contained in the proof-of-work parameter in the descriptor is extracted, and the difficulty response sequence of the suggested difficulty value of the second target onion service changes over time is constructed.

[0012] (4) Correlation calculation: Based on the difficulty response sequence, calculate the increase in the suggested difficulty value of the second target onion service in the ON phase relative to the OFF phase, as the co-relation degree of this round; when the co-relation degree of this round is higher than the preset judgment threshold, and the suggested difficulty value of the second target onion service drops back in the OFF phase after the ON phase, the correlation result of this round is that the correlation is established; otherwise, the correlation is not established.

[0013] (5) Multiple rounds of statistical verification and judgment: For the same target service, repeat steps (2) to (4) for a total of N rounds. When the proportion of rounds in which the association result is established reaches the set proportion, it is determined that the first target onion service and the second target onion service share processing resources, that is, they co-occupy; otherwise, it is determined that they do not co-occupy.

[0014] Furthermore, step (1) specifically includes:

[0015] (11) Obtain several onion addresses that are to be determined to be carried by the same process or the same physical host, wherein the onion services corresponding to the several onion addresses have all enabled the proof-of-work defense mechanism;

[0016] (12) Select two onion addresses from the plurality of onion addresses and take their corresponding onion services as the first target onion service to be loaded and the second target onion service to be observed; and execute the method on each pair of the plurality of onion addresses to determine the co-residence relationship between the corresponding onion services.

[0017] Furthermore, step (2) specifically includes:

[0018] (21) The test client obtains the service descriptor of the first target onion service based on the onion address of the first target onion service, and obtains the referrer information of the first target onion service from it;

[0019] (22) The test client sends an introduction request to the first target onion service via the introduction point. The introduction request causes the first target onion service to perform decryption, parsing, proof-of-work verification and enqueueing processing on the information element of the introduction request on its main thread.

[0020] (23) During the ON phase, the introduction request is continuously sent, causing the shared processing resource occupancy rate of the process or host where the first target onion service is located to rise above a preset occupancy threshold; during the OFF phase, the sending is stopped; the sending rate of the introduction request is limited to a range that does not make the first target onion service unavailable to the outside world.

[0021] Furthermore, in step (2), after the test client sends the import request, it no longer continues the subsequent aggregation process and does not need to establish a complete end-to-end data circuit with the first target onion service; the import request still enables the first target onion service to complete the decryption, parsing and proof-of-work verification of the import request information on its main thread.

[0022] Furthermore, step (3) specifically includes:

[0023] (31) Based on the onion address of the second target onion service, and combined with the shared random value in the current consensus file, deduce the HSDir node responsible for storing its descriptor, and download the service descriptor of the second target onion service from the HSDir node;

[0024] (32) Decrypt the inner encryption layer of the descriptor using the key derived from the onion address of the second target onion service, and extract the proposed difficulty value contained in the proof-of-work parameter;

[0025] (33) Repeat steps (31) to (32) with the set sampling period to obtain the difficulty response sequence of the suggested difficulty value of the second target onion service as a function of time.

[0026] Furthermore, the co-resident correlation degree in step (4) is replaced by the cross-correlation between the ON / OFF state sequence of the first target onion service and the difficulty response sequence of the second target onion service. The cross-correlation reflects the correspondence between the suggested difficulty value of the second target onion service increasing in the ON phase and decreasing in the OFF phase. When the cross-correlation is higher than the preset judgment threshold, the correlation result of this round is that the correlation is established.

[0027] Furthermore, the shared processing resources mentioned in steps (2) to (4) are a single-threaded main loop shared by the first target onion service and the second target onion service; the decryption, parsing and proof-of-work verification of the introduced request information by the first target onion service, and the release of its aggregation request by the second target onion service are all performed on the single-threaded main loop.

[0028] Furthermore, based on the determination that the first target onion service and the second target onion service co-occupy, the load intensity of the inbound request applied to the first target onion service is gradually increased to determine the minimum load intensity of the inbound request required to make the co-occurrence correlation of this round higher than the preset determination threshold, and the minimum load intensity of the inbound request is used to characterize the degree of closeness of the sharing of processing resources between the first target onion service and the second target onion service.

[0029] Furthermore, while applying inbound request load to the first target onion service, the test client also sends inbound requests to the second target onion service to establish the aggregation request arrival rate of the second target onion service, causing the aggregation request priority queue of the second target onion service to back up when the shared processing resources are occupied.

[0030] The present invention also provides an onion service co-location identification system based on proof-of-work difficulty, including a memory, a processor, and computer program instructions stored in the memory and executable by the processor. When the processor executes the computer program instructions, it can implement the above-mentioned method.

[0031] Compared with the prior art, the present invention has the following beneficial effects:

[0032] 1. This invention determines whether two services co-occur by applying load to one Tor service and observing the correlation between the suggested difficulty values ​​publicly disclosed by another Tor service. It does not require controlling any Tor relay nodes or global traffic correlation, thus reducing the deployment threshold and prerequisite requirements for detecting the association between services originating from the same source.

[0033] 2. The present invention obtains the suggested difficulty value of the observed onion service by downloading public descriptors from the HSDir node based on the onion address. The download link is independent of the main processing thread of the observed onion service. While controlling the applied load intensity to cause the aggregation request queue of the observed onion service to back up and raise its suggested difficulty value, it does not cause its main thread to be starved to the point of being unable to execute periodic descriptor publishing. This allows the observed onion service to publish the increased suggested difficulty value to the outside world, and the observer can remotely read the suggested difficulty value.

[0034] 3. This invention proposes to use "the increase in the difficulty value of the observed onion service in the ON phase relative to the OFF phase" as a co-residence determination index, providing a quantifiable measurement basis for the co-residence and homo-origin relationship of onion services; and can further characterize the degree of closeness of the sharing of processing resources between two onion services so that the increase exceeds the determination threshold.

[0035] 4. This invention addresses Tor's newly introduced proof-of-work defense mechanism by utilizing its publicly disclosed suggested difficulty value as an observable signal of shared resource competition. This overcomes the shortcomings of existing auditing tools that cannot use this to determine the co-location of Tor services. When an inbound request load is applied to the first target Tor service, causing competition for shared processing resources, the aggregation request priority queue of the second target Tor service accumulates. Based on this, the publicly disclosed suggested difficulty value is raised through its proof-of-work difficulty control loop. After the load application stops, the value drops accordingly, thus creating an observable correlation between the two. It should be noted that the suggested difficulty value is not a continuously readable real-time load, but rather a discrete state quantity that is updated by the difficulty control loop at a fixed update cycle and is only rewritten to the descriptor and published externally when there is a significant change relative to the previous release. Therefore, to convert it into a co-resident signal that can be read remotely, it is necessary to deliberately control the pressure on the first target onion service so that the backlog of the aggregation request priority queue of the second target onion service continues to span multiple update cycles, causing its suggested difficulty value to change significantly enough to trigger the re-release of the descriptor, while controlling the pressure intensity so as not to starve the main thread of the second target onion service to the point that it cannot complete the periodic descriptor release. This invention, through alternating ON / OFF pressure and multiple rounds of statistical verification, stably transforms the above-mentioned discrete, lagging difficulty signal constrained by the release threshold into a co-resident association determination criterion, which cannot be directly obtained from the common phenomenon of shared resource competition. Attached Figure Description

[0036] Figure 1 This is a schematic diagram of the Tor network's onion service mechanism in existing technologies.

[0037] Figure 2 This is a schematic diagram of the existing Onion Service proof-of-work defense and suggestion difficulty value publishing mechanism.

[0038] Figure 3 This is a schematic diagram illustrating the implementation process of the Onion Service Co-location Identification Method based on Proof-of-Work Difficulty provided in this embodiment of the invention.

[0039] Figure 4 This is a schematic diagram illustrating the correlation between the length of the priority queue for the aggregation request of the second target onion service and the suggested difficulty value over time when the first target onion service is alternately loaded with load in an embodiment of the present invention. Detailed Implementation

[0040] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0041] It should be noted that the following detailed descriptions are exemplary and intended to provide further explanation of this application. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains.

[0042] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments according to this application. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0043] This embodiment provides a method for identifying co-hosting onion services based on proof-of-work difficulty, used to remotely determine whether two onion services are hosted on the same physical host or by the same process. The method consists of five steps: identifying the target service pair, applying probe load, observing the difficulty response, calculating the correlation, and performing multi-round statistical verification and determination. The complete process of this method is as follows: Figure 3 As shown, it specifically includes:

[0044] 1. Determining the target service pair

[0045] The security auditor obtains several onion addresses that are to be determined to be of the same origin. From these, one onion address is identified as the first target onion service to be subjected to load balancing (denoted as service A), and the other onion address is identified as the second target onion service to be observed (denoted as service B). Both service A and service B have enabled proof-of-work defense mechanisms.

[0046] 2. Apply detection load

[0047] like Figure 3As shown, the auditer's test client obtains the descriptor of service A based on its onion address and retrieves the inbound point information from it. It then sends an inbound request to service A via the inbound point. Upon receiving the inbound request, service A performs decryption, parsing, and proof-of-work verification on its main thread, placing inbound requests that pass verification into a priority queue of convergence requests sorted by difficulty. The auditer applies load alternately in ON and OFF phases: in the ON phase, it continuously sends inbound requests at a rate that raises the shared processing resource utilization of the process or host where service A resides above a preset threshold; in the OFF phase, it stops sending. To avoid making service A unavailable externally, the inbound request rate is limited to a range that does not render service A unavailable. In one implementation, to ensure that the effective inbound request rate is truly transmitted to the main thread of service A, the test client uses multiple inbound circuits to send concurrently, thus circumventing the rate limitation on a single circuit. In another implementation, the import request is an import request that does not complete the subsequent aggregation process. That is, after the test client sends the import request to the import point, it does not establish a complete end-to-end data circuit. This allows service A to complete the decryption, parsing, and proof-of-work verification of the import request information on the main thread, thereby generating processing overhead on the main thread of service A at a lower client cost.

[0048] 3. Difficulty Response Observation

[0049] While applying load to service A, the auditor, based on the onion address of service B and the shared random value in the current consensus file, derives the HSDir node responsible for storing service B's descriptor. At a set sampling period, the auditor downloads the service B descriptor from the HSDir node, decrypts its inner encryption layer using the key derived from the service B onion address, and extracts the proposed difficulty value contained in the proof-of-work parameters, thereby constructing the difficulty response sequence for service B. It should be noted that the auditor's download of the service B descriptor is performed via the HSDir node, and this download link is independent of service B's own main processing thread. Simultaneously, the action of service B writing the increased proposed difficulty value into a new descriptor and uploading it to HSDir is still executed on service B's main thread. Therefore, in step (2), the auditor controls the load intensity applied to service A to be sufficient to cause a backlog in service B's aggregation request queue and increase the proposed difficulty value, but not to cause service B's main thread to become starved and unable to complete the periodic descriptor publication, thus ensuring that service B can publish the increased proposed difficulty value to HSDir for remote reading by the auditor.

[0050] 4. Relevance Calculation and Co-residence Determination

[0051] When services A and B co-host, they share the same processing resources. Under the same process hosting, services A and B share a single-threaded main loop: service A performs decryption, parsing, and proof-of-work verification of incoming request data on the main thread, while the main thread allows a limited number of aggregation requests from service B in each main loop event (implemented as one request per loop, configurable to a maximum of several). Assume that the aggregation request release rate of service B is proportional to the trigger frequency of its main loop events. ,in This indicates the frequency at which the aggregation request release callback for service B is triggered; the arrival rate of aggregation requests for service B is denoted as... When the load of incoming requests applied to service A consumes the main thread, As the rate of service B decreases, the release rate of its aggregation requests also slows down; when the release rate of service B is lower than its arrival rate... At that time, the aggregation request priority queue of service B continued to accumulate. During the update cycle of the difficulty control loop, due to the accumulation of aggregation request priority queues during this cycle, the difficulty control loop additively increases the suggested difficulty value published by service B. After the OFF phase stops applying load to service A, Restore service B's queue to empty; it is recommended to lower the difficulty value.

[0052] The auditor calculates the increase in the suggested difficulty value of service B during the ON phase relative to the OFF phase as the co-relation degree for this round (in another implementation, the co-relation degree can also be the cross-correlation between the ON / OFF state sequence of applying load to service A and the difficulty response sequence of service B), and compares it with a preset judgment threshold. When the suggested difficulty value of service B increases significantly during the ON phase relative to the OFF phase and the co-relation degree is higher than the threshold, the correlation result for this round is that the co-relation between the two is established; when the suggested difficulty value of service B is unrelated to the pressure applied to service A and the co-relation degree is lower than the threshold, the correlation result for this round is that it is not established.

[0053] Specifically, set at the The state of applying load to service A at each sampling time is: (1 for ON phase, 0 for OFF phase), the suggested difficulty value released by service B at this moment is... The sampling set of the ON phase is denoted as The sampling set of the OFF phase is denoted as The co-resident correlation degree in this round is calculated using one of the following formulas:

[0054] Increase: ;

[0055] Cross-correlation: ,in For sequence and covariance, , They are respectively and The standard deviation.

[0056] Let the threshold for determining the increase be... The cross-correlation threshold is ;when And when the suggested difficulty value of service B drops accordingly in the OFF phase following the ON phase, or when If the condition is met, the association result for this round is considered valid; otherwise, the association is considered invalid.

[0057] like Figure 4 As shown, in the OFF phase, the length of the aggregation request priority queue for service B is zero and the suggested difficulty value is zero; in the ON phase, as the load of incoming requests applied to service A occupies the shared main thread, the length of the aggregation request priority queue for service B increases significantly from zero, and its publicly disclosed suggested difficulty value increases accordingly; after the load application stops, the queue of service B is emptied and the suggested difficulty value drops, showing a correlation with the state of pressure applied to service A.

[0058] As mentioned earlier, the rate at which service B's aggregation requests are allowed is proportional to the frequency of its main loop callback. Suppose that applying load to service A causes the shared main thread's occupancy rate to be [percentage missing]. ,but Follow Increase and decrease, when occupancy rate Increase it so that the release rate of service B is lower than the arrival rate of its aggregation requests. At that time, the queue for service B began to back up, and the suggested difficulty value increased. Therefore, in terms of statistical expectation, the co-resident correlation in this round increased with the shared main thread occupancy rate. The increase of exhibits a threshold-type non-decreasing trend: when When the correlation falls below the threshold that causes service B's queue to start accumulating, the correlation remains zero; when After exceeding this threshold, the correlation decreases. Increase and rise.

[0059] Based on the determination of co-location, the auditor further gradually increases the load intensity of the incoming request applied to service A, recording the minimum load intensity required to elicit the aforementioned associated response from service B. The lower the minimum load intensity, the more closely service A and service B share processing resources. It should be noted that the conversion relationship between the load intensity applied by the auditor and the actual shared resources occupied by the services varies depending on the processing capacity of the target host and the background load. Therefore, the minimum load intensity is used to characterize the degree of closeness of resource sharing between the two, and not to make an absolute classification of their load-bearing structures.

[0060] 5. Multiple rounds of statistical verification and judgment

[0061] Because the suggested difficulty value is updated at a fixed interval and the descriptor is only republished when there are significant changes, and because it is affected by network jitter, single-round measurements may have biases. To ensure the statistical reliability of the identification results, the auditors repeatedly executed steps (2) to (4) on the same target service. The process involves multiple rounds of updates, with each ON phase spanning several update cycles, causing a significant change in the suggested difficulty value of Service B sufficient to trigger a re-release of the descriptor. In each round, when the proportion of rounds in which the association result is successful reaches a set proportion, it is determined that service A and service B co-host; the above determination is performed on each pair of the several onion addresses to be determined, and finally, onion service groups hosted by the same host or the same process are clustered out.

[0062] The present invention will be further described below through a specific embodiment.

[0063] Implementation Environment: A private Tor network is deployed in a containerized manner on the host machine. The private network consists of a directory authority node and several relay nodes. The Tor instance in the private network uses version 0.4.8.x, which introduces a proof-of-work mechanism, and proof-of-work defense is enabled for the Tor service. Two Tor services, denoted as Service A and Service B, are deployed on the same Tor instance (i.e., the same process), sharing the single-threaded main loop of the process. The test client sends an introduction request to Service A through the introduction point of the private network to apply probe load and reads the publicly disclosed suggested difficulty value of Service B and its aggregation request priority queue length. The baseline suggested difficulty value of Service B in the private network is zero.

[0064] Implementation Process: During both the OFF and ON phases, the test client continuously sends inbound requests to service B at a constant rate, serving as the baseline aggregation request arrival traffic for service B (service B maintains its own independent aggregation request priority queue, independent of service A's queue). In the OFF phase, no load is applied to service A, the shared main thread is idle, and service B's baseline arrival traffic is promptly allowed, its aggregation request priority queue is nearly empty, and the suggested difficulty value is zero. In the ON phase, while maintaining the baseline traffic to service B, the test client continuously sends inbound requests to service A concurrently, occupying the shared main thread. At this time, service B's aggregation request release slows down, and the aggregation request priority queue accumulates. Following the aforementioned mechanism of "slower aggregation request release leading to queue accumulation, which in turn raises the suggested difficulty value through the difficulty control loop," when the queue accumulation persists for one or more difficulty update cycles, the suggested difficulty value published by service B increases accordingly. After stopping the load application to service A, service B's queue is emptied, and the suggested difficulty value drops back down. Based on the changes in the queue and difficulty of Service B during the OFF, ON, and OFF phases, as well as the aforementioned co-occurrence correlation indicators, the auditors determined whether Service A and Service B co-occur. Specifically, whether Service B's main thread is occupied due to Service A's load and whether its aggregation request queue accumulates accordingly reflects whether Service A and Service B share processing resources. It should be noted that when Service B's baseline suggested difficulty value is zero, an increase in suggested difficulty value from zero to non-zero is a qualitative state change, which will inevitably be written into the proof-of-work parameters and trigger a descriptor redeployment; therefore, the difficulty response is easily observable remotely. In environments where the observed Onion service has a non-zero baseline suggested difficulty value, the suggested difficulty value must undergo a significant change sufficient to trigger a redeployment for it to be observable remotely.

[0065] By gradually increasing the load intensity applied to service A, it was found that the aforementioned associated response of service B only appeared significantly after the shared processing resources were occupied to a considerable extent, and it increased with the increase of load intensity. Based on this, the minimum load intensity required for service B to show an associated response can be recorded to characterize the degree of closeness between service A and service B in sharing processing resources.

[0066] This embodiment also provides an Onion service co-location identification system based on proof-of-work difficulty, including a memory, a processor, and computer program instructions stored in the memory and executable by the processor. When the processor executes the computer program instructions, it can implement the above-described method.

[0067] This embodiment also provides a computer-readable storage medium storing computer program instructions that, when executed by a processor, implement the above-described method.

[0068] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0069] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0070] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0071] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0072] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A method for identifying co-occurrence of onion services based on proof-of-work difficulty, characterized in that, Includes the following steps: (1) Determination of target service pair: Select two target onion services that have both enabled proof-of-work defense mechanism, denoted as the first target onion service and the second target onion service; (2) Applying load detection: Apply an introductory request load to the first target onion service, causing the first target onion service to occupy the shared processing resources of its process or host, and apply it alternately in the ON and OFF phases. Apply the introductory request load in the ON phase and stop applying the introductory request load in the OFF phase. (3) Difficulty response observation: While applying the probe load, the service descriptor of the second target onion service is periodically obtained from the onion service catalog system according to the onion address of the second target onion service. The suggested difficulty value contained in the proof-of-work parameter in the descriptor is extracted, and the difficulty response sequence of the suggested difficulty value of the second target onion service changes over time is constructed. (4) Correlation calculation: Based on the difficulty response sequence, calculate the increase in the suggested difficulty value of the second target onion service in the ON phase relative to the OFF phase, as the co-relation degree of this round; when the co-relation degree of this round is higher than the preset judgment threshold and the suggested difficulty value of the second target onion service drops back in the OFF phase after the ON phase, the correlation result of this round is that the correlation is established; otherwise, the correlation is not established. (5) Multiple rounds of statistical verification and judgment: For the same target service, repeat steps (2) to (4) for a total of N rounds. When the proportion of rounds in which the association result is established reaches the set proportion, it is determined that the first target onion service and the second target onion service share processing resources, that is, they co-occupy; otherwise, it is determined that they do not co-occupy.

2. The method for identifying co-occurrence of onion services based on proof-of-work difficulty as described in claim 1, characterized in that, Step (1) specifically includes: (11) Obtain several onion addresses that are to be determined to be carried by the same process or the same physical host, wherein the onion services corresponding to the several onion addresses have all enabled the proof-of-work defense mechanism; (12) Select two onion addresses from the plurality of onion addresses and take their corresponding onion services as the first target onion service to be loaded and the second target onion service to be observed; and execute the method on each pair of the plurality of onion addresses to determine the co-residence relationship between the corresponding onion services.

3. The method for identifying co-occurrence of onion services based on proof-of-work difficulty as described in claim 1, characterized in that, Step (2) specifically includes: (21) The test client obtains the service descriptor of the first target onion service based on the onion address of the first target onion service, and obtains the referrer information of the first target onion service from it; (22) The test client sends an introductory request to the first target onion service via the introductory point. The introductory request causes the first target onion service to perform decryption, parsing, proof-of-work verification and enqueueing processing on the information element of the introductory request on its main thread. (23) During the ON phase, the introduction request is continuously sent, causing the shared processing resource occupancy rate of the process or host where the first target onion service is located to rise above a preset occupancy threshold; during the OFF phase, the sending is stopped; the sending rate of the introduction request is limited to a range that does not make the first target onion service unavailable to the outside world.

4. The method for identifying co-occurrence of onion services based on proof-of-work difficulty as described in claim 3, characterized in that, In step (2), after the test client sends the import request, it no longer continues the subsequent aggregation process and does not need to establish a complete end-to-end data circuit with the first target Onion service; the import request still enables the first target Onion service to complete the decryption, parsing and proof-of-work verification of the import request information on its main thread.

5. The method for identifying co-occurrence of onion services based on proof-of-work difficulty as described in claim 1, characterized in that, Step (3) specifically includes: (31) Based on the onion address of the second target onion service, and combined with the shared random value in the current consensus file, deduce the HSDir node responsible for storing its descriptor, and download the service descriptor of the second target onion service from the HSDir node; (32) Use the key derived from the onion address of the second target onion service to decrypt the inner encryption layer of the descriptor and extract the suggested difficulty value contained in the proof-of-work parameter; (33) Repeat steps (31) to (32) with the set sampling period to obtain the difficulty response sequence of the suggested difficulty value of the second target onion service as a function of time.

6. The method for identifying co-occurrence of onion services based on proof-of-work difficulty as described in claim 1, characterized in that, In step (4), the co-resident correlation degree is replaced by the cross-correlation between the ON / OFF state sequence of the first target onion service and the difficulty response sequence of the second target onion service. The cross-correlation reflects the correspondence between the suggested difficulty value of the second target onion service increasing in the ON phase and decreasing in the OFF phase. When the cross-correlation is higher than the preset judgment threshold, the correlation result of this round is that the correlation is established.

7. The method for identifying co-occurrence of onion services based on proof-of-work difficulty according to claim 1, characterized in that, In steps (2) to (4), the shared processing resource is a single-threaded main loop shared by the first target onion service and the second target onion service; the first target onion service's decryption, parsing and proof-of-work verification of the introduced request information element, and the second target onion service's release of its aggregation request are all performed on the single-threaded main loop.

8. The method for identifying co-occurrence of onion services based on proof-of-work difficulty according to claim 1, characterized in that, Based on the determination that the first target onion service and the second target onion service co-occupy, the load intensity of the inbound request applied to the first target onion service is gradually increased. The minimum load intensity of the inbound request required to make the co-occurrence correlation of this round higher than the preset determination threshold is determined, and the minimum load intensity of the inbound request is used to characterize the degree of closeness of the sharing of processing resources between the first target onion service and the second target onion service.

9. The method for identifying co-occurrence of onion services based on proof-of-work difficulty according to claim 3, characterized in that, While applying inbound request load to the first target onion service, the test client also sends inbound requests to the second target onion service to establish the aggregation request arrival rate of the second target onion service, causing the aggregation request priority queue of the second target onion service to back up when the shared processing resources are occupied.

10. A system for identifying co-occurrence of onion services based on proof-of-work difficulty, characterized in that, It includes a memory, a processor, and computer program instructions stored in the memory and executable by the processor, wherein when the processor executes the computer program instructions, it can implement the method as described in any one of claims 1-9.

Images