A data processing method and apparatus

Abstract

Embodiments of the present application provide a data processing method and device, which are used for joint proof of device information by multiple devices in an information proof scenario, and reduce the proof calculation amount of a single device without leaking device information. The method comprises: a first device obtaining a verification request, the verification request being used for requesting verification of the first device, which can be a request sent by another device or a request generated by the first device; then the first device sends first data to a second device according to the verification request, the first data being determined according to a signature of the first device, and receives second data sent by the second device, the second data being obtained by the second device through proof calculation on the first data and information of the first device, the second data being used for verifying the first device, and a specific proof algorithm can be selected according to an actual application scenario.

Description

Technical Field

[0001] This application relates to the field of computers, and more particularly to a data processing method and apparatus. Background Technology

[0002] In the field of digital identity authentication, with the increasing demand for privacy protection, anonymous credentials have gained wider attention and application due to their ability to hide user privacy information. Anonymous credentials allow users to prove they possess certain attributes or permissions while avoiding the exposure of their specific identity information, thereby achieving privacy protection and minimizing data disclosure. The application of anonymous credentials is crucial in scenarios such as personal information processing, data sharing, or user transactions.

[0003] To achieve anonymous credentials, zero-knowledge proofs (ZKPs) are crucial. ZKPs allow credential holders to prove the truth of certain statements to verifiers without revealing additional information. For example, a user can prove they are 18 years of age or older without disclosing their specific date of birth. ZKPs enable selective disclosure of credential attributes, thus satisfying verification requirements while protecting privacy. However, user credentials are typically stored on the user's terminal, and the computational demands of ZKP are very high, posing a significant overhead for user terminals with limited computing power. Summary of the Invention

[0004] This application provides a data processing method and apparatus that uses multiple devices to jointly prove device information, thereby reducing the computational load of proving a single device.

[0005] In view of this, firstly, this application provides a data processing method, comprising: a first device acquiring a verification request, the verification request being used to request verification of the first device, specifically a request received from another device or a request generated by the first device; subsequently, the first device sending first data to a second device according to the verification request, the first data being determined based on the signature of the first device, and receiving second data sent by the second device, the second data being obtained by the second device through a proof calculation of the first data and the information of the first device, the second data being used to prove the information of the first device without disclosing the information of the first device, the specific proof algorithm being selected according to the actual application scenario, the proof calculation being the calculation of proving the signature of the first device. In the embodiments of this application, for the signature proof of the first device, the second device can perform all or part of the proof calculation, thereby reducing the computational load of the first device, reducing the computational overhead of the first device, and adapting to more scenarios of the first device with low computing power.

[0006] In one possible implementation, the signature of the first device includes third data, which is stored in the first device. The first device sends the first data to the second device according to the verification request, including: the first device performs encrypted calculation on the third data to obtain the first data; and the first device sends the first data and the data in the verification request to the second device.

[0007] In this embodiment of the application, the third data in the signature of the first device is stored in the first device. In order to prevent the signature of the first device from being leaked, the first device can encrypt the third data before sending it to the second device.

[0008] In one possible implementation, the verification request includes attribute information, which indicates a first attribute of the first device to be verified. The aforementioned sending of first data and the data in the verification request from the first device to the second device includes: the first device sending the first data and the attribute information to the second device. In this embodiment, for device attribute information, such as the age, gender, and place of birth of the user using the first device, encryption and verification are typically required to prevent exposure. Therefore, the second device can verify the attribute information and output a calculation result that does not directly display the attribute, thus avoiding information leakage.

[0009] In one possible implementation, the signature of the first device further includes fourth data, which is stored in the second device. The second data is calculated by the second device based on the first and fourth data. In this embodiment, the signature is stored separately in the first and second devices, so that the signature will not be leaked even if the first device is lost.

[0010] In one possible implementation, if the third data is stored in the first device, the aforementioned method further includes: the first device calculating fifth data based on the third data and the second data, the fifth data being used to verify the first device.

[0011] In this embodiment of the application, when the first device is stored separately, the first device also uses the locally stored data to calculate a complete proof result, thereby providing a more complete proof of the signature of the first device.

[0012] In one possible implementation, the first device obtains a verification request, including: the first device receiving a verification request sent by a third device; the aforementioned method further includes: the first device sending fifth data to the third device, the fifth data being used by the third device to verify the first device.

[0013] In this embodiment, a third-party device can request signature verification from a first device. The first device can then jointly perform proof calculations with a second device without disclosing the signature, which greatly reduces the proof calculation overhead of the first device and can be adapted to more scenarios with low computing power.

[0014] Secondly, this application provides a data processing method, comprising: a second device receiving first data sent by a first device, the first data being determined based on the signature of the first device, for example, the first data being sent to the second device after the first device receives a verification request; the second device performing a proof calculation on the first data to obtain second data, the proof calculation being an algorithm for proving the information of the first device, the output second data being used to prove the information of the first device, such as proving which attributes the first device possesses; and the second device sending the second data to the first device, the second data being used to verify the signature of the first device. In this embodiment of the application, the second device can perform the signature proof calculation of the first device, thereby reducing the computational overhead of the first device and adapting to more scenarios with low computing power for the first device.

[0015] In one possible implementation, the signature of the first device includes third data and fourth data. The third data is stored in the first device, and the fourth data is stored in the second device. The first data is calculated by the first device based on the third data. The aforementioned second device verifies and calculates the second data based on the first data, which includes: the second device verifies and calculates the second data based on the fourth data and the first data. In this embodiment, the signature of the first device can be stored in both the first device and the second device. Therefore, even if the first device is lost or its data is lost, the complete signature of the first device can be avoided, thus improving the information security of the first device.

[0016] In one possible implementation, the aforementioned method further includes: a second device receiving attribute information sent by a first device, the attribute information being used to indicate a first attribute for verification of the first device; the second device performing a proof calculation on the fourth data and the first data to obtain second data includes: the second device performing a proof calculation on the attribute information, the fourth data, and the first data to obtain the second data. In this embodiment, when performing the proof calculation, the second device can selectively prove the attributes that need to be verified, thereby outputting a calculation result that can be used to prove the attribute information.

[0017] Thirdly, this application provides a first device, comprising:

[0018] The acquisition module is used to acquire verification requests, which are used to request verification of the first device.

[0019] The transceiver module is used to send first data to the second device according to the verification request. The first data is determined based on the signature of the first device.

[0020] The transceiver module is also used to receive second data sent by the second device. The second data is obtained by the second device through verification calculation of the first data and the information of the first device. The second data is used to verify the first device.

[0021] The effects achieved by the third aspect and any optional implementation of the third aspect can be referred to the description of the first aspect or any optional implementation of the first aspect, and will not be repeated below.

[0022] In one possible implementation, the signature of the first device includes third data, the third data is stored in the first device, and the first device further includes a processing module;

[0023] The processing module is used to perform encrypted calculations on the third data to obtain the first data;

[0024] The transceiver module is also used to send the first data and the data in the verification request to the second device.

[0025] In one possible implementation, the verification request includes attribute information that indicates a first attribute of the first device to be verified.

[0026] The transceiver module is also used to send the first data and attribute information to the second device.

[0027] In one possible implementation, the signature of the first device further includes fourth data, which is stored in the second device. The second data is calculated by the second device based on the first data and the fourth data.

[0028] In one possible implementation, if the third data is stored in the first device, the device further includes:

[0029] The processing module is used to calculate the fifth data based on the third data and the second data, and the fifth data is used to verify the first device.

[0030] In one possible implementation, the transceiver module is further configured to receive a verification request sent by a third device and send fifth data to the third device, the fifth data being used by the third device to verify the first device.

[0031] Fourthly, this application provides a second device, comprising:

[0032] The transceiver module is used to receive first data sent by the first device, wherein the first data is determined based on the signature of the first device;

[0033] The processing module is used to perform verification calculations on the first data to obtain the second data;

[0034] The transceiver module is also used to send second data to the first device, which is used to prove the signature of the first device.

[0035] The effects achieved by the fourth aspect and any optional implementation of the fourth aspect can be referred to the description of the second aspect or any optional implementation of the second aspect, and will not be repeated below.

[0036] In one possible implementation, the signature of the first device includes third data and fourth data, the third data is stored in the first device, the fourth data is stored in the second device, and the first data is calculated by the first device based on the third data;

[0037] The processing module is specifically used to perform verification calculations on the fourth data and the first data to obtain the second data.

[0038] In one possible implementation, the transceiver module is further configured to receive attribute information sent by the first device, the attribute information being used to indicate a first attribute proving the first device;

[0039] The processing module is specifically used to perform verification calculations on the attribute information, the fourth data, and the first data to obtain the second data.

[0040] Fifthly, embodiments of this application provide a system that may include a first device and a second device. The first device may be used to perform processing-related functions in the method shown in any of the first aspects above, and the second device may be used to perform processing-related functions in the method shown in any of the second aspects above.

[0041] In a sixth aspect, embodiments of this application provide a first device, the first device including a processor and a memory, wherein the processor and the memory are interconnected via a circuit, and the processor calls program code in the memory to perform processing-related functions in the method shown in any of the first aspects above.

[0042] In a seventh aspect, embodiments of this application provide a second device including a processor and a memory, wherein the processor and the memory are interconnected via a circuit, and the processor calls program code in the memory to perform processing-related functions in the method shown in any of the second aspects above.

[0043] Eighthly, embodiments of this application provide a digital processing chip or chip, the chip including a processing unit and a communication interface, the processing unit obtains program instructions through the communication interface, the program instructions are executed by the processing unit, and the processing unit is used to perform processing-related functions as described in any optional embodiment of the first or second aspect above.

[0044] In a ninth aspect, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a computer, cause the computer to perform the method in any of the optional embodiments of the first or second aspect described above.

[0045] In a tenth aspect, embodiments of this application provide a computer program product comprising a computer program / instructions, which, when executed by a processor, causes the processor to perform the method in any of the optional embodiments of the first or second aspect described above. Attached Figure Description

[0046] Figure 1 A schematic diagram of the system architecture provided in this application embodiment;

[0047] Figure 2 A flowchart illustrating a data processing method provided in an embodiment of this application;

[0048] Figure 3 A flowchart illustrating another data processing method provided in an embodiment of this application;

[0049] Figure 4 This is a schematic diagram of the structure of a first device provided in an embodiment of this application;

[0050] Figure 5 This is a schematic diagram of the structure of a second device provided in an embodiment of this application;

[0051] Figure 6 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application. Detailed Implementation

[0052] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0053] The method provided in this application can be used in scenarios such as device authentication or user authentication. It can be used to verify the signature of a device through collaborative computation of multiple devices, which can reduce the computational load of a device compared to performing proof computation on a single device.

[0054] First, for ease of understanding, some of the categories or concepts involved in the embodiments of this application will be introduced.

[0055] Knowledge signature (SoK): A verifiable signature that uses knowledge without revealing the knowledge itself, and uses the signature to prove the knowledge to the outside world.

[0056] Zero-knowledge proof (ZKP): Allows credential holders to prove the truth of certain statements to verifiers without revealing additional information.

[0057] Anonymous credentials are a privacy-preserving digital identity authentication scheme that allows users to hide sensitive attributes when verifying the validity of their identity, achieving a balance between "minimized disclosure" and "verifiable claims".

[0058] BBS group signature (Boneh-Boyen-Shacham signature): A secure multi-message digital signature protocol that allows for the proof of knowledge of the signature while selectively disclosing a subset of signed messages.

[0059] BBS+ digital signature (Boneh-Boyen-Shacham+ digital signature): It is an improved version of the original BBS group signature (Boneh-Boyen-Shacham signature). This signature is based on bilinear pairing and can verify the validity of the signature while protecting privacy. It is usually suitable for distributed systems that need to hide the identity of the signer.

[0060] In the field of digital identity authentication, with the increasing demand for privacy protection, anonymous credentials have gained wider attention and application due to their ability to hide user privacy information. Anonymous credentials allow users to prove they possess certain attributes or permissions while avoiding the exposure of their specific identity information, thereby achieving privacy protection and minimizing data disclosure. The application of anonymous credentials is crucial in scenarios such as personal information processing, data sharing, or user transactions.

[0061] To enable anonymous credentials, zero-knowledge proof (ZKP) technology becomes the core support. ZKP allows credential holders to prove the truth of certain statements to verifiers without revealing additional information. For example, a user can prove they are 18 years of age or older without disclosing their specific date of birth. ZKP allows for selective disclosure of credential attributes, thus satisfying verification requirements while protecting privacy.

[0062] For example, the BBS+ digital signature scheme has attracted much attention due to its efficiency and flexibility. BBS+ signature is a digital signature scheme based on bilinear mapping, supporting efficient zero-knowledge proofs and attribute disclosure functions. BBS+ digital signature is widely used in anonymous credential systems, becoming an important support for e-government, privacy-preserving data sharing, and commodity transactions. That is, the method provided in this application embodiment can be applied to scenarios such as e-government, privacy-preserving data sharing, and commodity transactions, enabling the proof of user information without disclosing user information.

[0063] However, existing signature schemes, especially those with higher security, require greater computational resources. Performance on resource-constrained devices (such as mobile devices) remains a significant challenge. For example, while BBS+ signatures support both zero-knowledge and knowledge proofs, offering advantages in privacy protection and minimizing data disclosure, they still have limitations in resource-constrained environments. Specifically, BBS+ signatures have high computational complexity in proofs, placing demands on device processing power and storage resources. In resource-limited scenarios (such as embedded devices or low-power devices), signature generation and verification may lead to performance degradation, making it difficult to meet the needs of lightweight applications. Furthermore, this signature requires a complete signature for verification, necessitating storage on the user device. If the user device is lost or its data is lost, identity theft may occur.

[0064] Therefore, this application provides a data processing solution that reduces the computational workload of a single device by enabling multiple devices to jointly perform proof calculations. It also avoids the leakage of user information due to device loss.

[0065] The method provided in this application can be applied to an architecture where multiple devices jointly perform proof computation. This architecture may include multiple devices, such as a first device and a second device. When verification of the first device is required, the first device and the second device can jointly perform the proof computation, thereby reducing the computational load on the first device.

[0066] Specifically, the first device may be a client, a user terminal, or other electronic devices, and the second device may be a client, a user terminal, or a server, or other electronic devices.

[0067] Exemplary, a system architecture provided in this application embodiment can be as follows: Figure 1 As shown. Figure 1 As shown, the system architecture may include a data center 11, a cloud platform 12, and a client 13.

[0068] The cloud platform 12 may specifically include a server cluster or a cloud platform, or the computing device may be other devices with computing capabilities. Optionally, the cloud platform 12 can work with other computing devices, such as data storage, routers, load balancers, etc. The cloud platform 12 can use data in the data storage cluster or call program code in the data storage cluster to implement the method steps executed by the second device provided in the embodiments of this application.

[0069] Data center 11 can be used to store data for cloud platform 12 to query or write data, etc.

[0070] The cloud platform 12 can provide services to users in the form of a client. Users can operate on the client 13 to achieve data interaction with the cloud platform 12 or request services from the cloud platform 12. Specifically, this client can be deployed on personal computers, computer workstations, smartphones, tablets, laptops, and smart cars, etc. This client can be used to execute the method steps provided in the embodiments of this application, which are performed by the first device.

[0071] In this embodiment, the user can authorize the cloud platform 12 in advance, that is, allow the cloud platform 12 to store part of the user's signature information. When verification of the client 13 is required, the client 13 and the cloud platform 12 can jointly execute the verification algorithm and output the verification result. This is equivalent to transferring the computation originally performed by the client 13 to the cloud platform 12, thereby reducing the computational load on the client 13.

[0072] See Figure 2 The present application provides a schematic flowchart of a data processing method.

[0073] 201. The first device receives a verification request.

[0074] This verification request is used to request verification of the first device, specifically including verifying the signature of the first device or verifying whether the first device meets preset conditions.

[0075] Optionally, the verification request may carry attribute information, which can be used to indicate the attribute type of the first device requesting verification. For example, in some scenarios, the verification request may include a name or location, indicating that the name or location of the first device should be verified.

[0076] The verification request can be generated by the first device or received from a third device, depending on the specific application scenario.

[0077] For example, in one possible scenario, when the first device needs to start a process, the start of the process may require verification of the first device's signature, identity, or attributes. The process in the first device can then generate a verification request to request verification of the first device's identity or attributes.

[0078] For example, in another possible scenario, if a third device is present and needs to verify the first device, such as verifying the first device's identity or attributes, the third device can send a verification request to the first device to request verification of the first device's signature, identity, or attributes.

[0079] Furthermore, in specific application scenarios, the information of the first device may include information about the first device itself, or information about the user using the first device. For example, the information of the first device may include, but is not limited to, the serial number of the first device, or information such as the gender, permissions, or age of the user using the first device. The information of the first device may be represented as a signature or sequence, etc. The specific data format can be determined according to the actual application scenario. This application embodiment exemplifies the use of proving the signature of the first device as an example for illustrative purposes. The signature of the first device mentioned below can also be replaced with other types of information of the first device, which will not be elaborated further below.

[0080] 202. The first device sends the first data to the second device.

[0081] The first data is determined based on the signature of the first device, instructing the second device to perform a proof calculation based on the first data.

[0082] The first data may be a part of the signature of the first device, or it may be calculated from a part of the signature stored by the first device.

[0083] For example, in one possible implementation, to improve the information security of the first device, the first device can calculate the data in its signature to obtain the first data. For instance, the signature of the first device may include third data, and the first device can encrypt the third data before outputting the first data.

[0084] 203. The second device performs verification calculations on the first data to obtain the second data.

[0085] After receiving the first data, the second device can perform a proof calculation on the first data and output the second data. This proof calculation is also known as the algorithm for proving the input data. The specific proof algorithm can be determined according to the actual application scenario. For example, a proof algorithm based on the BBS + signature scheme can be used, or other algorithms can be used. The specific algorithm can be determined according to the actual application scenario, and this application does not limit it.

[0086] Optionally, in one possible implementation, the signature of the first device can be divided into the aforementioned third data and fourth data. To improve the information security of the first device, the third data can be stored in the first device, and the fourth data can be stored in the second device, such as in the aforementioned cloud data center. Accordingly, when the second device performs proof calculation on the first data, it can use the stored fourth data to perform proof calculation on the first data and output the second data. Therefore, in this embodiment of the application, the signature of the first device is stored in both the first device and the second device, so that even if the first device is lost or its data is lost, the information of the first device can be prevented from being leaked, thereby improving the information security of the first device.

[0087] Optionally, in one possible implementation, if the aforementioned verification request also includes attribute information, the first device may also send the attribute information to the second device. When performing the proof calculation, the second device may also combine the attribute information to perform the calculation to prove the attributes of the first device.

[0088] 204. The first device receives the second data sent by the second device.

[0089] The second data can be used to verify the first device, which is the verification result corresponding to the aforementioned verification request.

[0090] The specific proof algorithm for joint proof by the first and second devices is detailed below.

[0091] Therefore, in this embodiment, the proof is performed jointly by the first device and the second device, thereby distributing the steps originally performed by the first device to the second device, thus reducing the computational overhead of the first device. Furthermore, some of the signature information of the first device can be stored in the authorized second device, thus preventing information leakage of the first device and improving its information security even if the first device is lost or its data is lost.

[0092] Optionally, in one possible implementation, if the signature of the first device is divided into third data and fourth data, and the first device stores the third data while the second device stores the fourth data, since the second device does not have the complete signature of the first device, the first device can further calculate the second data output by the second device using the third data to output the fifth data, that is, the complete proof data.

[0093] In one possible implementation, if the aforementioned verification request is sent from a third device to a first device, the first device, after receiving the second data, can feed the second data back to the third device; or, in the case of calculating the fifth data, the first device feeds the fifth data back to the third device. This allows the third device to verify the first device based on the verification result.

[0094] The foregoing has described the method flow provided by the embodiments of this application. The following section will provide a more detailed description of the method flow provided by the embodiments of this application in conjunction with specific algorithms and application scenarios.

[0095] The following example illustrates the situation using the first device as the client, the second device as the server, and the third device as the verifier.

[0096] Typically, in existing schemes, the client needs to independently complete the generation process of the knowledge signature (SoK) proof. This means the client needs to perform all complex computations, including addition of group elements, scalar multiplication, and bilinear pairing operations. However, the method provided in this application, based on a client-server architecture and a selective disclosure mechanism for two-party joint anonymous credentials, can construct a two-party joint knowledge signature (SoK) compatible with BBS+signatures. This architecture allows resource-constrained clients to collaborate with computationally powerful servers to generate proofs, significantly reducing the client's computational burden. Furthermore, storing information separately on the client and server improves user information security. Moreover, it is compatible with the BBS+signature scheme, so no changes are needed for the verifier, achieving a seamless process for the verifier.

[0097] This application provides a two-party joint proof generation mechanism based on a client-server architecture for constructing proofs of knowledge signatures (SoK). For clients with limited computing resources (e.g., mobile devices), it allows them to collaborate with servers with greater computing power to generate proofs, thereby significantly improving proof efficiency. Specifically, to avoid the client performing all computationally intensive operations, this application distributes the computational burden between the client and the server. The specific initialization and verification phases are described below as an example.

[0098] First, for ease of understanding, as shown in Table 1, the parameters involved in some algorithms in the following embodiments are introduced.

[0099]

[0100] Table 1

[0101] First, the client and server need to be initialized before verification.

[0102] For example, during the initialization phase, signatures are typically issued by other platforms, such as the signature of the first device or the user's signature. For instance, for a user's identity signature, a designated platform usually calculates the signature based on the user's specific information and then sends it to the client and server.

[0103] For example, during the initialization phase, the platform can calculate a signature using information from the first device or the user. Taking the BBS+ signature scheme as an example, a bilinear group can be used to calculate the signature of a vector of length l representing user information. Generate a signature.

[0104] such as bilinear group Contains a set of cyclic groups It is also equipped with a highly efficient bilinear mapping (pairing) operation. Satisfy: For all x, All of them are: in, and They are groups and The generator.

[0105] First generate and They are groups and The generators are q, and q is the order of the three groups.

[0106] Random selection And randomly select Calculate X = x·G2.

[0107] Set the private key sk = (H, x) and the public key pk = (H, X), and output (sk, pk).

[0108] calculate

[0109] Announce PK and

[0110] Signature Algorithm This algorithm uses sk as a message vector of length l. Generate signature σ.

[0111] Specifically, the algorithm may include:

[0112] Parse sk as (H, x).

[0113] Randomly select e, And calculate A=(G1+s·H1+∑ i∈,l- m i ·H i+1 ) / (x+e).

[0114] Output σ = (A, e, s).

[0115] For the information in the signature, different information can be deployed on the client and the server. For example, s can be sent to the client, and A and e can be sent to the server; or A and e can be sent to the client, and s can be sent to the server; or (A, e, s) can be sent to the client, and the client can choose which information to authorize the server; or (A, e, s) can be sent to both the client and the server, etc. The specific method can be determined according to the actual application scenario.

[0116] The following example illustrates how s is sent to the client and A and e are sent to the server.

[0117] See Figure 3 The present application provides a schematic flowchart of another data processing method.

[0118] 301. The verifier sends a verification request to the client.

[0119] The verifier can be the device connecting to the client, such as a server or terminal. The verifier may differ depending on the specific application scenario.

[0120] Typically, the signature stored on the client is issued by a reliable institution or platform, and verifiers can verify the user's specific information by verifying the signature. For example, a verifier might want to verify that the client possesses certain attributes (i.e., To verify a valid signature, the verifier sends a verification request to the client, carrying the fresh value n and... For example, a verifier might request verification of information such as the age, gender, or location of the user using the client. This verification could be achieved by sending a verification request to the client, carrying a randomly generated fresh value 'n' and the specific type of the client attribute being verified.

[0121] 302. The client requests joint proof from the server.

[0122] After receiving the verification request, the client can encrypt the signature stored on the client and send it to the server to request the server to jointly verify the client's signature.

[0123] For example, T can be calculated. ′ =s·H1, where H1 is randomly selected, and n is sent to the server. T′.

[0124] For example, in some scenarios, when a user opens a website, the website needs to verify whether the user is an adult. The website server can send a verification request to the user's client, which includes the user's age attribute. After receiving the verification request, the client, in order to avoid the leakage of user information, can cooperate with the server to perform a proof calculation to obtain proof that the user is an adult, without revealing the user's specific information.

[0125] 303. The server sends the calculation results back to the client.

[0126] After receiving the information sent by the client, the server can use the stored client signature to perform a proof calculation and then send the calculation result back to the client.

[0127] Specifically, taking the proof algorithm of the BBS+ signature scheme as an example, the server can perform the following proof calculations:

[0128] Random selection

[0129] Calculate the public value A ′ =r1·A, calculate Calculate D = r1·B - r2·H1;

[0130] Random selection and

[0131] Calculate the commitment value and commitment value

[0132] Calculate the challenge value

[0133] Calculate the return value z e =ρ e +c·e, r = r2·r3;

[0134] Set partial proof values

[0135] Set the calculation results

[0136] The server will then calculate the results. Send to the client.

[0137] 304. The client sends proof to the verifier.

[0138] Since both the client and the server store a portion of the signature, the client uses the locally stored signature to perform supplementary calculations based on the calculation results returned by the server, thereby providing a complete proof of the client's signature.

[0139] For example, the client can perform the following proof calculation:

[0140] Analysis of π′ is

[0141] Calculate z s′ =ρ s′ +c·(sr);

[0142] Set partial proof values

[0143] Set proof value

[0144] The client then sends proof to the verifier.

[0145] The verifier can verify the client based on the received proof value.

[0146] Specific verification algorithms may include:

[0147] verify and Check if the condition is true or false; if not, output 0.

[0148] Analysis of π is

[0149] Calculate the commitment value

[0150] verify If true, output 1; otherwise, output 0.

[0151] This can be understood as follows: in the implementation of this application, the verifier wishes to confirm that the client possesses certain attributes (i.e., To verify a valid signature, the verifier will send a fresh value n to the client. Subsequently, the client and server jointly generate a knowledge proof for the BBS+ signature, namely: in, A set of indices representing hidden messages. This indicates the index of the message that needs to be made public, that is, the index corresponding to the message that the verifier needs to verify.

[0152] During the initialization phase, the entity holding the signature (A,e,s) sends (A,e) and a pre-calculated commitment value T to the server. At this point, the client holds s, while the server holds (A,e). Through collaborative interaction, both parties jointly generate a BBS+signature SoK. Specifically, the server uses (A,e) and the commitment value T to generate an incomplete proof π′, and then sends it to the client. The client only needs to... qA SoK proof can be completed by performing a simple multiplication, addition, and subtraction operation. Therefore, most of the computational burden is shifted to the server side, significantly reducing the computational load on the client side. Furthermore, storing the client's signature separately on both the client and server prevents information leakage even if the client's device or data is lost, thus improving the security of the client's signature. Moreover, it ensures integrity, reliability, and zero-knowledge compliance even under conditions of semi-honest servers, malicious clients, and verifiers.

[0153] For example, in digital identity authentication systems, such as digital identity wallet apps, enterprise authentication systems, and e-government service platforms, there are client applications (such as mobile apps) and server-side modules that support federated proof generation. The client stores the user's digital identity signature and collaborates with the server to generate a knowledge signature (SoK); the server handles complex computational tasks to assist in completing the federated proof. Users typically need to prove to the verifier that certain attributes they possess (such as age, education, membership status, etc.) meet the requirements without revealing all their identity information. Through the method provided in this application's embodiments, users only expose necessary identity attributes while hiding other sensitive information, thereby protecting user privacy.

[0154] For example, in the decentralized identity (DID) scenario, key issues such as user privacy protection and resource-constrained device authentication can be solved through efficient collaborative computation and selective disclosure. User devices store distributed identity credentials (such as BBS + signatures). When a verifier requests verification of certain attributes (such as age or membership status), the user device (client) collaborates with nodes (servers) in the distributed identity network to generate a joint proof.

[0155] For example, in potential privacy-preserving payment scenarios, users may need to prove they are part of a specific group (such as a VIP member or a service subscriber) to enjoy discounts or offers without revealing the payment amount or their identity information. The solution provided in this application can be combined with privacy-preserving payment protocols (such as the ZKP payment protocol), allowing users to quickly prove their eligibility through a joint proof generation mechanism while protecting transaction privacy.

[0156] The method flow provided in the application embodiments has been described above. The structure of the apparatus for executing the above method flow is described below.

[0157] See Figure 4 The present application provides a schematic diagram of the structure of a first device, which includes:

[0158] The acquisition module 401 is used to acquire a verification request, which is used to request verification of the first device;

[0159] The transceiver module 402 is used to send first data to the second device according to the verification request, wherein the first data is determined according to the signature of the first device;

[0160] The transceiver module 402 is also used to receive second data sent by the second device. The second data is obtained by the second device through verification calculation of the first data and the information of the first device. The second data is used to verify the first device.

[0161] In one possible implementation, the signature of the first device includes third data, the third device is stored in the first device, and the first device further includes a processing module 403;

[0162] Processing module 403 is used to perform encrypted calculations on the third data to obtain the first data;

[0163] The transceiver module 402 is also used to send the first data and the data in the verification request to the second device.

[0164] In one possible implementation, the verification request includes attribute information that indicates a first attribute of the first device to be verified.

[0165] The transceiver module 402 is also used to send the first data and attribute information to the second device.

[0166] In one possible implementation, the signature of the first device further includes fourth data, which is stored in the second device. The second data is calculated by the second device based on the first data and the fourth data.

[0167] In one possible implementation, if the third data is stored in the first device, the processing module 403 is used to calculate the fifth data based on the third data and the second data, and the fifth data is used to verify the first device.

[0168] In one possible implementation, the transceiver module 402 is further configured to receive a verification request sent by a third device and send fifth data to the third device, the fifth data being used by the third device to verify the first device.

[0169] See Figure 5 The present application provides a schematic diagram of the structure of a second device, including:

[0170] The transceiver module 501 is used to receive first data sent by the first device, wherein the first data is determined based on the signature of the first device;

[0171] Processing module 502 is used to perform proof calculations on the first data to obtain the second data;

[0172] The transceiver module 501 is also used to send second data to the first device, the second data being used to prove the signature of the first device.

[0173] In one possible implementation, the signature of the first device includes third data and fourth data, the third data is stored in the first device, the fourth data is stored in the second device, and the first data is calculated by the first device based on the third data;

[0174] The processing module 502 is specifically used to perform a verification calculation on the fourth data and the first data to obtain the second data.

[0175] In one possible implementation, the transceiver module 501 is further configured to receive attribute information sent by the first device, the attribute information being used to indicate a first attribute proving the first device.

[0176] The processing module 502 is specifically used to perform verification calculations on the attribute information, the fourth data, and the first data to obtain the second data.

[0177] like Figure 6 The diagram shown is a hardware structure schematic of a computing device 60 provided in an embodiment of this application. This computing device 60 can be used to implement the aforementioned... Figures 2 to 3 The steps of the method may specifically include the aforementioned first device or second device.

[0178] Figure 6 The computing device 60 shown may include a processor 601, a memory 602, a communication interface 603, and a bus 604. The processor 601, the memory 602, and the communication interface 603 can be connected via the bus 604.

[0179] The processor 601 is the control center of the computing device 60. It can be a general-purpose central processing unit (CPU) or other general-purpose processors. The general-purpose processor can be a microprocessor or any conventional processor, such as a GPU or NPU, and can be adapted to the actual application scenario.

[0180] As an example, processor 601 may include one or more CPUs, and may also include other processors, such as... Figure 6 The CPU, NPU, or GPU shown are examples of such devices.

[0181] The memory 602 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.

[0182] In one possible implementation, the memory 602 can exist independently of the processor 601. The memory 602 can be connected to the processor 601 via a bus 604 and is used to store data, instructions, or program code. When the processor 601 calls and executes the instructions or program code stored in the memory 602, it can implement the methods provided in the embodiments of this application, for example, Figures 2 to 3 The method shown.

[0183] In another possible implementation, the memory 602 can also be integrated with the processor 601.

[0184] The communication interface 603 is used for connecting the computing device 60 to other devices via a communication network, which may be Ethernet, radio access network (RAN), wireless local area network (WLAN), etc. The communication interface 603 may include a receiving unit for receiving data and a transmitting unit for sending data.

[0185] Bus 604 can be an industry standard architecture (ISA) bus, a peripheral component interconnect (PCI) bus, or an extended industry standard architecture (EISA) bus. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 6 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0186] It should be pointed out that, Figure 6 The structure shown does not constitute a limitation on the computing device 60, except... Figure 6 In addition to the components shown, computing device 60 may include more or fewer components than illustrated, or combine certain components, or have different component arrangements.

[0187] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk, etc., including several instructions to cause a data quantization device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0188] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0189] This application also provides a computer-readable storage medium storing a program for training a model or performing inference tasks, which, when run on a computer, causes the computer to perform the aforementioned... Figures 2 to 3 All or part of the steps in the method described in the embodiments shown.

[0190] This application also provides a digital processing chip. This digital processing chip integrates circuitry for implementing the aforementioned processor or processor functions, and one or more interfaces. When the digital processing chip integrates a memory, it can perform the method steps of any one or more of the foregoing embodiments. When the digital processing chip does not integrate a memory, it can be connected to an external memory via a communication interface. The digital processing chip implements the method steps of any one or more of the foregoing embodiments based on the program code stored in the external memory.

[0191] This application also provides a computer program product comprising one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., a solid-state disk (SSD)).

[0192] The device provided in this application embodiment can be a chip, which includes a processing unit and a communication unit. The processing unit can be, for example, a processor, and the communication unit can be, for example, an input / output interface, pins, or circuits. The processing unit can execute computer execution instructions stored in a storage unit to cause the chip to perform the above-mentioned operations. Figures 2 to 3 The method described in the illustrated embodiment. Optionally, the storage unit is a storage unit within the chip, such as a register, cache, etc. The storage unit can also be a storage unit located outside the chip within an electronic device, such as read-only memory (ROM) or other types of static storage devices that can store static information and instructions, random access memory (RAM), etc.

[0193] Specifically, the aforementioned processing unit or processor can be a central processing unit (CPU), a neural-network processing unit (NPU), a graphics processing unit (GPU), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0194] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0195] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0196] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0197] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0198] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. The term "and / or" in this application is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Additionally, the character " / " generally indicates that the preceding and following related objects are in an "or" relationship. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or modules is not necessarily limited to those steps or modules explicitly listed, but may include other steps or modules not explicitly listed or inherent to such processes, methods, products, or devices. The naming or numbering of steps in this application does not imply that the steps in the method flow must be executed in the time / logical order indicated by the naming or numbering. The execution order of the named or numbered process steps can be changed according to the technical purpose to be achieved, as long as the same or similar technical effect can be achieved. The division of modules in this application is a logical division. In actual applications, there may be other division methods. For example, multiple modules may be combined into or integrated into another system, or some features may be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the modules shown or discussed may be through some ports, and the indirect coupling or communication connection between modules may be electrical or other similar forms, which are not limited in this application. Furthermore, the modules or sub-modules described as separate components may or may not be physically separated, may or may not be physical modules, or may be distributed in multiple circuit modules. Some or all of the modules can be selected to achieve the purpose of the solution in this application according to actual needs.

Claims

1. A data processing method, characterized in that, include: The first device obtains a verification request, the verification request being used to request verification of the first device; The first device sends first data to the second device according to the verification request, wherein the first data is determined based on the signature of the first device; The first device receives second data sent by the second device. The second data is obtained by the second device through a verification calculation based on the first data and the information of the first device. The second data is used to verify the first device.

2. The method according to claim 1, characterized in that, The signature of the first device includes third data, which is stored in the first device. The first device sends first data to the second device according to the verification request, including: The first device performs encrypted calculations on the third data to obtain the first data; The first device sends the first data and the data in the verification request to the second device.

3. The method according to claim 2, characterized in that, The verification request includes attribute information, which is used to indicate the verification of a first attribute of the first device. The first device sends the first data and the data in the verification request to the second device, including: The first device sends the first data and the attribute information to the second device.

4. The method according to any one of claims 1-3, characterized in that, The signature of the first device also includes fourth data, which is stored in the second device. The second data is calculated by the second device based on the first data and the fourth data.

5. The method according to claim 4, characterized in that, When storing third data in the first device, the method further includes: The first device calculates fifth data based on the third data and the second data, and the fifth data is used to verify the first device.

6. The method according to claim 5, characterized in that, The first device receives a verification request, including: The first device receives the verification request sent by the third device; The method further includes: The first device sends the fifth data to the third device, and the fifth data is used by the third device to verify the first device.

7. A data processing method, characterized in that, include: The second device receives first data sent by the first device, wherein the first data is determined based on the signature of the first device. The second device performs verification calculations on the first data to obtain the second data; The second device sends the second data to the first device, and the second data is used to verify the signature of the first device.

8. The method according to claim 7, characterized in that, The signature of the first device includes third data and fourth data. The third data is stored in the first device, the fourth data is stored in the second device, and the first data is calculated by the first device based on the third data. The second device performs verification calculations on the first data to obtain the second data, including: The second device performs a verification calculation on the fourth data and the first data to obtain the second data.

9. The method according to claim 8, characterized in that, The method further includes: The second device receives attribute information sent by the first device, the attribute information being used to indicate the verification of a first attribute of the first device; The second device performs a verification calculation on the fourth data and the first data to obtain the second data, including: The second device performs a verification calculation on the attribute information, the fourth data, and the first data to obtain the second data.

10. A first device, characterized in that, include: The acquisition module is used to acquire a verification request, which is used to request verification of the first device; The transceiver module is used to send first data to the second device according to the verification request, wherein the first data is determined based on the signature of the first device; The transceiver module is further configured to receive second data sent by the second device. The second data is obtained by the second device through a verification calculation of the first data and the information of the first device. The second data is used to verify the first device.

11. The device according to claim 10, characterized in that, The signature of the first device includes third data, which is stored in the first device. The first device also includes a processing module. The processing module is used to perform encrypted calculations on the third data to obtain the first data; The transceiver module is also used to send the first data and the data in the verification request to the second device.

12. The device according to claim 11, characterized in that, The verification request includes attribute information, which is used to indicate the verification of a first attribute of the first device. The transceiver module is also used to send the first data and the attribute information to the second device.

13. The device according to any one of claims 10-12, characterized in that, The signature of the first device also includes fourth data, which is stored in the second device. The second data is calculated by the second device based on the first data and the fourth data.

14. The device according to claim 13, characterized in that, In the case where the third data is stored in the first device, the first device further includes a processing module for calculating fifth data based on the third data and the second data, the fifth data being used to verify the first device.

15. The device according to claim 14, characterized in that, The transceiver module is also used to receive the verification request sent by the third device; The transceiver module is further configured to send the fifth data to the third device, the fifth data being used by the third device to verify the first device.

16. A second device, characterized in that, include: The transceiver module is used to receive first data sent by the first device, wherein the first data is determined based on the signature of the first device; The processing module is used to perform proof calculations on the first data to obtain the second data; The transceiver module is further configured to send the second data to the first device, the second data being used to prove the signature of the first device.

17. The device according to claim 16, characterized in that, The signature of the first device includes third data and fourth data. The third data is stored in the first device, the fourth data is stored in the second device, and the first data is calculated by the first device based on the third data. The processing module is specifically used to perform a verification calculation on the fourth data and the first data to obtain the second data.

18. The device according to claim 17, characterized in that, The transceiver module is further configured to receive attribute information sent by the first device, the attribute information being used to indicate and prove the first attribute of the first device; The processing module is specifically used to perform a verification calculation on the attribute information, the fourth data, and the first data to obtain the second data.

19. A first device, characterized in that, The device includes a memory and a processor; the memory stores code, and the processor is configured to execute the code, wherein when the code is executed, the first device performs the method as described in any one of claims 1-6.

20. A second device, characterized in that, The device includes a memory and a processor; the memory stores code, and the processor is configured to execute the code, wherein when the code is executed, the second device performs the method as described in any one of claims 7-9.

21. A system, characterized in that, It includes a first device and a second device, wherein the first device performs the method as described in any one of claims 1-6, and the second device performs the method as described in any one of claims 7-9.

22. A computer storage medium, characterized in that, The computer storage medium stores instructions that, when executed by the computer, cause the computer to perform the method of any one of claims 1 to 6 or any one of claims 7 to 9.

23. A computer program product, characterized in that, The computer program product stores instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 6 or any one of claims 7 to 9.

Images