Identity information verification method and system, storage medium, and electronic device

Abstract

Embodiments of the present disclosure provide an identity information verification method and system, a storage medium, and an electronic device. The method comprises: receiving a verification request sent by a data subject; and when the verification request instructs to verify identity information of a private data subject, verifying the identity information of the private data subject on the basis of a first sub-public key in the verification request, wherein the verification request comprises the first sub-public key of the private data subject, the first sub-public key is a public key generated by the private data subject on the basis of a first identity key allocated by a management apparatus and a preset rule, and the first sub-public key is an identity identifier of the private data subject.

Description

Identity information verification method and system, storage medium and electronic device

[0001] This disclosure claims priority to the Chinese patent application filed with the China Patent Office on June 30, 2023, with application number 202310803496.5 and invention name “Identity information verification method and system, storage medium and electronic device”, the entire content of which is incorporated by reference into this disclosure. Technical Field

[0002] The present disclosure relates to the field of communications, and in particular to a method and system for verifying identity information, a storage medium, and an electronic device. Background Art

[0003] With the booming development of the information industry, data privacy protection is receiving increasing attention and attention. Many countries and organizations have enacted strict laws and regulations to protect personal privacy. For example, the European Union (EU) has enacted the General Data Protection Regulation (GDPR), which requires companies to obtain consumers' explicit consent before collecting their personal data. The United States has adopted measures such as the California Consumer Privacy Act and the Personal Information Protection and Electronic Documents Act to protect consumer privacy. Meanwhile, countries such as China, Japan, and Australia have also enacted similar laws to protect personal privacy and data security.

[0004] However, with the continuous advancement of information technology, the amount of data generated in people's daily lives is becoming increasingly massive. Under the current management model, regulators struggle to effectively monitor all data flows. Furthermore, because private data often possesses extremely high analytical and commercial value, many companies, driven by self-interest, induce customers to agree to disclose personal privacy information to circumvent laws, or even directly ignore them to collect and exploit private data. Finally, many companies lack professional expertise and investment in security protection, resulting in frequent leaks of confidential data due to improper management or hacker attacks. Once private data is leaked, it is irreversible.

[0005] There are two main reasons for the above problems: enterprises have direct access to private data, and management agencies have no mandatory constraints on infringement of private data.

[0006] Currently, in the vast majority of cases, businesses have direct access to the private data provided by their customers. Even if regulatory requirements require businesses to anonymize and report private data, the entire data processing process is completed by the business itself, leaving the original private information visible to the business. Currently, regulatory agencies primarily constrain business behavior through regulations and generally do not directly intervene in a company's data processing processes (primarily due to management cost considerations). Therefore, if a business decides to infringe upon or exploit private data for some reason, it is difficult for regulatory agencies to detect and prevent it in a timely manner. At best, they can only impose penalties after the damage has already occurred.

[0007] Therefore, the existing technology has problems such as low security of user privacy data and easy leakage.

[0008] Summary of the Invention

[0009] The embodiments of the present disclosure provide a method and system for verifying identity information, a storage medium, and an electronic device, so as to at least solve the problems in related technologies such as low security and easy leakage of user privacy data.

[0010] According to an embodiment of the present disclosure, a method for verifying identity information is provided, comprising: receiving a verification request sent by a data subject; and when the verification request indicates verification of the identity information of a privacy data subject, verifying the identity information of the privacy data subject according to a first sub-public key in the verification request, wherein the verification request comprises: a first sub-public key of the privacy data subject, the first sub-public key being a public key generated by the privacy data subject according to a first identity key assigned by a management device and a preset rule, and the first sub-public key being an identity identifier of the privacy data subject.

[0011] According to another embodiment of the present disclosure, a system for verifying identity information is provided, including: a data subject, configured to send a verification request to a management device; a management device, configured to receive the verification request, and when the verification request indicates verification of the identity information of the privacy data subject, verifying the identity information of the privacy data subject according to the first sub-public key in the verification request, wherein the verification request includes: the first sub-public key of the privacy data subject, the first sub-public key being a public key generated by the privacy data subject according to the first identity key assigned by the management device and a preset rule, and the first sub-public key being the identity identifier of the privacy data subject.

[0012] According to another embodiment of the present disclosure, a computer-readable storage medium is provided, in which a computer program is stored. The computer program is configured to execute the steps of any one of the above method embodiments when running.

[0013] According to another embodiment of the present disclosure, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any one of the above method embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] FIG1 is a hardware structure block diagram of a computer terminal according to a method for verifying identity information according to an embodiment of the present disclosure;

[0015] FIG2 is a flow chart of a method for verifying identity information according to an embodiment of the present disclosure;

[0016] FIG3 is a flowchart of a subkey derivation process according to an embodiment of the present disclosure;

[0017] FIG4 is a flowchart of identity key legitimacy verification according to an embodiment of the present disclosure;

[0018] FIG5 is a data update flow chart according to an embodiment of the present disclosure;

[0019] FIG6 is a flowchart of data registration according to an embodiment of the present disclosure;

[0020] FIG7 is a flow chart of identity key generation according to an embodiment of the present disclosure;

[0021] FIG8 is an authentication flow chart according to an embodiment of the present disclosure;

[0022] FIG9 is a flowchart of a data query according to an embodiment of the present disclosure;

[0023] FIG10 is a schematic diagram of a hierarchical key system according to an embodiment of the present disclosure;

[0024] FIG11 is a diagram showing a relationship between system modules according to an embodiment of the present disclosure;

[0025] FIG12 is a schematic diagram of an e-commerce application scenario according to an embodiment of the present disclosure;

[0026] FIG13 is a structural block diagram of an identity information verification system according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0027] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings and in conjunction with embodiments.

[0028] It should be noted that the terms "first", "second", etc. in the specification and claims of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0029] The method embodiments provided in the embodiments of the present disclosure can be executed in a mobile terminal, a computer terminal or a similar computing device. Taking running on a computer terminal as an example, Figure 1 is a hardware structure block diagram of a computer terminal for a method of verifying identity information in an embodiment of the present disclosure. As shown in Figure 1, the computer terminal may include one or more (only one is shown in Figure 1) processors 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor (Central Processing Unit, MCU) or a programmable logic device (Field Programmable Gate Array, FPGA)) and a memory 104 for storing data, wherein the above-mentioned computer terminal may also include a transmission device 106 and an input and output device 108 for communication functions. It can be understood by those skilled in the art that the structure shown in Figure 1 is only for illustration and does not limit the structure of the above-mentioned computer terminal. For example, the computer terminal may also include more or fewer components than those shown in Figure 1, or have a configuration different from that shown in Figure 1.

[0030] The memory 104 can be configured to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the identity information verification method in the embodiment of the present disclosure. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, implementing the above-mentioned method. The memory 104 may include a high-speed random access memory and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include a memory remotely located relative to the processor 102, and these remote memories may be connected to the computer terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0031] The transmission device 106 is configured to receive or transmit data via a network. A specific example of the aforementioned network may include a wireless network provided by a communications provider of a computer terminal. In one embodiment, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In one embodiment, the transmission device 106 may be a radio frequency (RF) module for wireless communication with the Internet.

[0032] FIG2 is a flow chart of a method for verifying identity information according to an embodiment of the present disclosure. As shown in FIG2 , the process includes the following steps:

[0033] Step S202: receiving a verification request sent by the data subject;

[0034] Step S204: When the verification request indicates verification of the identity information of the privacy data subject, the identity information of the privacy data subject is verified according to the first sub-public key in the verification request, wherein the verification request includes: the first sub-public key of the privacy data subject, the first sub-public key is a public key generated by the privacy data subject according to the first identity key assigned by the management device and the preset rules, and the first sub-public key is the identity identifier of the privacy data subject.

[0035] Through the above steps, since in the case where the verification request indicates to verify the identity information of the privacy data subject, the identity information of the privacy data subject is verified according to the first sub-public key in the verification request, wherein the verification request includes: the first sub-public key of the privacy data subject, the first sub-public key is the public key generated by the privacy data subject according to the first identity key assigned by the management device and the preset rules, and the first sub-public key is the identity identifier of the privacy data subject, that is, the privacy subject in the embodiment of the present disclosure uses the identity key to derive the sub-key, and uses the public key in the sub-key as the identity identifier, therefore, only the management device can verify the identity information of the privacy data subject according to the sub-key. Therefore, it can solve the problems of low security and easy leakage of user privacy data in related technologies, thereby achieving the effect of reducing the exposure of privacy data.

[0036] Optionally, verify the identity information of the privacy data subject through the following steps:

[0037] Step 11: Generate multiple second subkeys corresponding to multiple second identity keys according to the preset rule, wherein the multiple second identity keys are identity keys issued by the management device, and the multiple second identity keys at least include: the first identity key;

[0038] Step 12: Determine whether the first sub-public key is consistent with any second sub-public key corresponding to the plurality of second sub-subkeys;

[0039] Step 13: If the first sub-public key is consistent with any second sub-public key corresponding to the multiple second sub-public keys, determine the first identity key corresponding to the any second sub-public key, and determine the target data based on the correspondence between the first identity key and the target data;

[0040] Step 14: Obtaining interaction information carried in the verification request, wherein the interaction information is used to verify whether the privacy data subject is legal in the target scenario;

[0041] Step 15: Verify whether the privacy data subject is legal in the target scenario based on the target data;

[0042] Step 16: If the first sub-public key is consistent with any second sub-public key corresponding to the multiple second sub-keys, and the privacy data subject is determined to be legal in the target scenario, determine that the identity information of the privacy data subject is legal.

[0043] It is understandable that the privacy data subject can generate a subkey corresponding to the privacy data subject's identity key according to its own needs through preset rules, wherein the privacy data subject uses the sub-public key in the subkey as the identity identification of the privacy data subject when interacting with other data subjects.

[0044] Since the above-mentioned preset rules are jointly agreed upon by the privacy data subject and the management agency, the management agency (equivalent to the management device in the above-mentioned embodiment) can derive all subkeys that may be generated by the privacy data subject based on the identity key and the preset rules it has, and compare them with the first sub-public key. If the first sub-public key is consistent with any of the sub-public keys derived by the management agency, it means that the first sub-public key is legal, and the first sub-public key is derived from a recorded identity key. Based on the association between the recorded identity key and the target data, the target data of the data subject can be determined, and based on the target data, whether the privacy data subject is legal in the target scenario can be determined.

[0045] Furthermore, the data subject can generate multiple subkeys based on their needs and choose to use different subkeys in different interaction processes to prevent external tracking of their behavior and identity, thereby significantly reducing the probability of private data exposure and lowering the risk of data exposure. The data subject can also, for certain reasons (e.g., to obtain better service), disclose the associations of some subkeys to specific entities, allowing them to know that these subkeys correspond to the same entity (thus providing better service to the data subject). However, regardless of the choice, no one other than the aforementioned management agencies and the data subject themselves can directly access the data subject's data, nor can they easily link and threaten the data subject's true identity by mining and analyzing multiple subkeys. The data subject controls the generation, use, and exposure of subkey associations. Even if some subkey associations are exposed to malicious actors, the data subject can easily implement defenses and limit the scope of damage (e.g., by generating and using new subkeys and resuming use of the exposed subkeys).

[0046] The present disclosure provides a method for a private data subject to generate a subkey. The subkey derivation process of the private data subject is shown in FIG3 . The specific steps are as follows:

[0047] Step S301, determining a generated value according to a preset rule;

[0048] Specifically, the privacy data subject first needs to determine a generated value based on a preset rule. This preset rule can be established by a management agency. For example, it can be stipulated that the generated value must be randomly selected from an integer range of [1-2048]; or, the generated value = identity public key + generation number (where the generation number is initially 0, and is increased by 1 each time a subkey is generated, with a maximum value of 2048, which is used in a cycle). Since the generated value rules are established by the management agency, the management agency can independently derive all generated values ​​that the privacy data subject may use, and derive all subkeys that the privacy data subject may generate based on the generated values.

[0049] Step S302: Generate a new subkey (equivalent to the first subkey in the above embodiment) based on the identity key (equivalent to the above first identity key) and the generated value;

[0050] Specifically, the privacy data subject uses his or her own identity key plus the generated value to derive a new subkey, where the derivation algorithm includes but is not limited to the Key Derivation Function (KDF) algorithm.

[0051] Step S303: Save the subkey and additional information.

[0052] Specifically, the privacy data subject locally saves and records the generated subkey and additional information (e.g., the corresponding generated value) for subsequent use.

[0053] The above interactive information can be used to verify whether the natural person is legitimate (does this person exist? Is this person's age legal in the context of the current order? Is this person's fund balance sufficient to complete the current order?)

[0054] Through the above embodiment, the verifier can only determine whether the data subject is legal in the current scenario, and cannot obtain the data subject's private data. Therefore, it solves the problems of low security and easy leakage of user privacy data in related technologies, greatly reduces the probability of exposure of privacy data, and reduces risks.

[0055] Private data and the real identity behind it are represented by a child public key. When the participants in the interaction need to verify whether a child public key is legal (whether it has been registered with the management agency) and whether the corresponding privacy subject is legal in the context of this interaction (for example, a natural person with a record of dishonesty is not allowed to participate in a specific business activity), they need to initiate the identity legitimacy verification process with the management agency, as shown in Figure 4. The specific steps are as follows:

[0056] Step S401: The management machine authenticates the requester;

[0057] Step S402: Determine whether the authentication is successful;

[0058] Step S403: If the authentication is successful, extract the sub-public key to be verified from the verification request; wherein the verification request includes: information of the sub-public key to be verified (equivalent to the first sub-public key) and interaction context information (equivalent to the interaction information);

[0059] Step S404: If the authentication fails, a message indicating that the authentication failed is fed back;

[0060] Step S405: The management agency searches for the identity key set of the data subject distributed by it, and determines the identity key that can derive the sub-public key to be verified;

[0061] Step S406: Determine whether there is an identity key that can derive the sub-public key to be verified;

[0062] Step S407: If there is an identity key that can derive the sub-public key to be verified, read the interaction context information contained in the verification request (for example, this verification request is for completing a specific business behavior);

[0063] Step S408: If there is no identity key that can derive the sub-public key to be verified, the feedback identity key is illegal;

[0064] Step S409: combining the data subject's identity and privacy information to determine whether the subject is legitimate in the interaction context;

[0065] Step S410: If the data subject is legal in the interaction context, feedback is given that the target identity verification is legal;

[0066] Step S411: If the data subject is not legal in the interaction context, feedback is given that the target subject is not legal in the interaction context;

[0067] Step S412: Record and archive the current process data.

[0068] Optionally, when the verification request indicates verification of the identity information of the non-private data subject, the identity information of the non-private data subject is verified according to the first identity public key in the verification request, wherein the verification request includes: the first identity public key of the non-private data subject, the first identity public key is the public key assigned to the non-private data subject by the management device, and the first identity public key is the identity identifier of the non-private data subject.

[0069] Furthermore, the identity information of the non-private data subject is verified through the following steps:

[0070] Step 21: Determine whether the first identity public key is consistent with any second identity public key among a plurality of second identity public keys, wherein the plurality of second identity public keys are identity public keys issued by the management device, and the plurality of second identity public keys include at least: the first identity public key;

[0071] Step 22: When the first identity public key is consistent with any of the second identity public keys, determine that the identity information of the non-privacy data subject is legal.

[0072] Since non-privacy data subjects (such as enterprises) can only use their own identity keys to disclose information (public keys) during the interaction process, when verifying the identity information of the non-privacy data subject, only the first public key is compared with the third public key among multiple identity keys to see whether they are consistent. When the first public key is consistent with the third public key among the multiple identity keys, the first data of the first data subject can be determined based on the recorded association relationship between the identity key and the first data.

[0073] Optionally, the data subject can update the data stored in the security device. The method for updating data is shown in FIG5 and includes:

[0074] Step S501: The data subject sends an update request to the management agency to enable the management agency to verify the legitimacy of the data subject's identity, wherein the update request includes: the data subject's identity public key or sub-public key;

[0075] Step S502: Determine whether the identity of the data subject is legal;

[0076] Step S503: If the identity of the data subject is legitimate, the data subject sends the updated data to the management agency;

[0077] Step S504: The management agency reviews the received new data to ensure the reliability and integrity of the data;

[0078] Step S505: Determine whether the data authentication is passed;

[0079] Step S506: If the data authentication is passed, save the data;

[0080] Step S507: If the identity of the data subject is illegal or the data authentication fails, the data update fails.

[0081] Optionally, before receiving the verification request sent by the data subject, the method further includes: receiving a registration request sent by the data subject, wherein the registration request includes: the registration data of the data subject; verifying the identity information of the data subject based on the registration data; and when determining that the identity information of the data subject is legal, sending a third identity key to the data subject, and establishing a corresponding relationship between the third identity key and the registration data.

[0082] It is understood that the registration process of the data subject is shown in Figure 6, where the registration data of the data subject includes: data that can prove its identity or legitimacy. For private data subjects (such as natural persons), the registration data is private data; for non-private data subjects (such as enterprises), the registration data is public data. The specific steps are as follows:

[0083] Step S601: accepting the registration request sent by the data subject;

[0084] Step S602: receiving registration data sent by the data subject;

[0085] Step S603: Determine whether the registration data has passed the review;

[0086] Step S604: if the registration data passes the review, determine the generated value;

[0087] It's important to note that the generated value must be related to the root key and can be derived from the root key and a small amount of public information. For example, the generated value = root public key + generation number. Subsequently, knowing only the root public key and the maximum generation number allows all generated values ​​and, consequently, all identity keys to be recovered, greatly facilitating backup and recovery.

[0088] Step S605: Using the KDF algorithm, taking the root key and the generated value as input, deriving the identity key, and sending the identity key to the data subject;

[0089] Step S606: associate the identity key with the registration data and save them.

[0090] Step S607: If the registration data fails to pass the review, a registration failure message is fed back to the data subject.

[0091] Optionally, in an embodiment of the present disclosure, multiple identity keys may be generated in advance, specifically: obtaining a root key, and generating a corresponding salt value based on the root key; and determining the identity key corresponding to the root key and the salt value based on a key derivation algorithm.

[0092] It is understood that the process of obtaining the root key is shown in Figure 7 and includes:

[0093] Step S701, selecting a reliable random source;

[0094] Due to the extreme importance of the root key, the management agency must select a reliable random source to obtain high-quality random numbers. The random source can be generated using a dedicated hardware random source, such as a thermal noise generator.

[0095] Step S702, generate a root key;

[0096] The root key may be determined based on a key derivation algorithm (for example, using a mainstream asymmetric encryption algorithm: ED25519, combined with a random number).

[0097] Step S703: Save the root key.

[0098] Among them, the generated root key is properly preserved, and the input values ​​and intermediate values ​​(such as random numbers, etc.) used in the process of generating the root key are completely destroyed.

[0099] Optionally, before receiving the verification request sent by the data subject, the method further includes: receiving a first verification request sent by the data subject, wherein the first verification request is used to request verification of the identity of the data subject, and the first verification request includes: the public key of the third identity key of the data subject; sending a random number to the data subject so that the data subject signs the random number according to the private key of the third identity key; receiving the signed random number sent by the data subject, and determining the identity verification result of the data subject based on the signed random number.

[0100] It is understandable that, before receiving the verification request sent by the device body, the method as shown in FIG8 further includes:

[0101] Step S801: The management agency receives an authentication request from a requester (equivalent to the above-mentioned data subject), wherein the authentication request includes the public key data of the requester's identity key;

[0102] Step S802: The management agency extracts the public key of the requester's identity key from the authentication request;

[0103] Step S803: The management agency obtains a random number from a reliable random source and sends it to the requester;

[0104] The requester signs the random number using the private key of the identity key and feeds the signature back to the management agency;

[0105] Step S804: The management agency receives the signature;

[0106] Step S805: Verify the signature based on the public key and random number of the identity key obtained previously;

[0107] Step S806: If the verification fails, the authentication failure and the reason are fed back, and the process ends;

[0108] Step S807: If the verification is successful, the authentication is successful.

[0109] Optionally, the disclosed embodiment further includes: receiving an access request sent by the data subject, wherein the access request is used to request access to the data of other data subjects; determining the type of the data of the other data subjects, wherein the type includes one of the following: public type, privacy type; and determining whether the data subject is allowed to access the data of the other data subjects based on the type of the data.

[0110] It is understood that data types can be either public or private. Public data is accessible to all devices. Public data primarily includes public identity keys and public information. Private data is accessible only to the data subject, and no device has access to private data that does not belong to it.

[0111] In the case that the data type is a privacy type, it is determined that the data subject is prohibited from accessing the data. If the data subject is prohibited from accessing the data, the permission review fails and a failure is directly fed back.

[0112] Specifically, the data query method in the embodiment of the present disclosure is shown in FIG9 , and the specific steps are as follows:

[0113] Step S901: Authenticate the requester of the data query (equivalent to the data subject in the above embodiment);

[0114] Step S902: Determine whether the authentication is successful;

[0115] Step S903: If the authentication is successful, determine whether the requester has the right to access the target data;

[0116] Step S904: If the requester has the right to access the target data, query and feedback the relevant data;

[0117] Step S905: If the requester does not have the right to access the target data, or if the authentication fails, the data query fails.

[0118] In order to better understand the process of the above-mentioned identity information verification method, the implementation process of the above-mentioned identity information verification method is described below in combination with optional embodiments, but it is not used to limit the technical solution of the embodiment of the present disclosure.

[0119] FIG10 is a schematic diagram of a hierarchical key system according to an embodiment of the present disclosure, as shown in FIG10 :

[0120] 1) Both the root key and the identity key are generated by the management agency. The identity key is generated from the root key and a generated value (also known as a salt value). The management agency records all generated identity keys, distributes them to various entities, and keeps the root key and identity key secret.

[0121] 2) The privacy data subject (such as a natural person) can derive a subkey based on their own identity key and a generated value (salt value), and use the subkey's public key as a substitute value for private information when interacting with the outside world. This derivation process does not require the involvement of the management agency. The privacy data subject needs to keep their own identity key (both public and private keys cannot be disclosed) and the subkey's private key secret, so that other entities cannot track and locate a specific data subject by observing public data;

[0122] 3) Since the management agency controls the identity keys and corresponding private data of all private data subjects, it can calculate which identity key it is derived from based on the public sub-public key and generated value information, and then locate the specific data subject by combining the private data;

[0123] 4) Some entities are not private data subjects (e.g., businesses). Therefore, they must use their identity keys (public keys) directly during interactions and cannot derive or use subkeys. At the same time, their public keys and identity information are publicly available to the management authority, allowing any entity to verify their identity at any time.

[0124] In summary, this solution eliminates the risk of private data leakage during data interaction by isolating private data from other entities and using a specially designed hierarchical key system. Top-level management agencies can audit and track the information of all parties involved in the interaction without directly monitoring or interfering with the interaction process.

[0125] FIG11 is a diagram showing the relationship between system modules according to an embodiment of the present disclosure, as shown in FIG11 :

[0126] The system described in the embodiment of the present disclosure includes: a management agency, a private data subject, and a public data subject;

[0127] In the system described in the embodiment of the present disclosure, the management mechanism includes: a key management module A, a private data management module B, a public data management module C, and an identity verification module D;

[0128] In the system described in the embodiment of the present disclosure, the private data subject includes: a key application module E, a private data module F;

[0129] In the system described in the embodiment of the present disclosure, the public data body includes: a key application module G and a public data module H.

[0130] 1) Module A is responsible for generating the root key of the entire system;

[0131] When a managed entity registers with the management agency, Module A needs to generate an identity key for any managed entity using a generated value based on the root key and send the key to the corresponding entity (Module E or Module G). Module A must persist the root key and the used generated value (if the generated value is designed to be derived from the root key, then only the root key can be stored). It can also further store all generated identity keys to improve the efficiency of subsequent processes;

[0132] 2) Module B is responsible for the management and storage of private data;

[0133] Whenever a private data subject (e.g., a natural person) registers with a regulatory agency, they are required to provide their private data. This private data is not publicly accessible and is only accessible to the regulatory agency and the data subject. Module B is responsible for receiving and properly storing this data, while also recording the association between the identity key generated by Module A and the private data for subsequent use.

[0134] 3) Module C is responsible for the management and preservation of public data;

[0135] Whenever a public data subject (e.g., a company) registers with a regulatory agency, the agency and the subject must jointly determine their public data information (e.g., business license and address), which can be accessed by anyone. Module C is responsible for receiving and storing this data, while also recording the association between the identity key generated by Module A and the public data for subsequent use.

[0136] 4) Module D is responsible for verifying the legitimacy of specific identity keys and associated data;

[0137] The identity keys issued by the management agency to each data subject will be used in the data exchange process. Any party involved in the interaction can query the management agency for the legitimacy of a specific identity key (mainly to query whether the key has been registered. For public data subjects, it can also be further queried whether the key and public information match);

[0138] 5) Module E is the key application module on the privacy data subject side;

[0139] The main responsibility of module E is to properly preserve the identity key (private key) obtained from the management agency, and to dynamically generate a subkey based on the identity key and a generated value when the subject needs it. In daily data interaction activities, the private data subject should use the public key of the subkey as a representative of their own identity, so that other interacting parties will have difficulty tracking their specific private identity. The management agency is able to calculate the corresponding private data subject identity based solely on the subkey public key + generated value;

[0140] 6) Module F is responsible for the privacy data management of the privacy data subject;

[0141] Module F is primarily responsible for properly preserving the data subject's own private data and interacting with the management agency or updating the content when necessary (for example, when some private data content needs to be updated);

[0142] 7) Module G is the key application module on the public data subject side;

[0143] Module G's primary responsibility is to properly preserve the identity key (private key) obtained from the management agency and directly use the public key of the identity key as the interactive identity in daily data interaction activities. The public data subject is not allowed to use alternative identities (such as subkeys). Any party involved in the interaction can confirm the legitimacy of the specific identity public key information based on the data disclosed by the management agency;

[0144] 8) Module H is responsible for data management on the public data subject side;

[0145] Module H is mainly responsible for managing and storing the public data of the data subject itself, and interacting with the management agency or updating the content when necessary (for example, when some public data content needs to be updated).

[0146] Compared to the aforementioned system modules, in traditional systems, the private data of private data subjects is visible to all interacting parties, making it extremely vulnerable to leakage or illegal exploitation. Even in some improved systems, random values ​​are used to replace specific private information in the interaction process, but this anonymization scheme is often designed and implemented by a single party involved in the interaction (for example, between a natural person and a data company). If the implementer of the anonymization scheme is unreliable, the security of private data cannot be guaranteed. Finally, in traditional systems, top-level management agencies have no binding force against illegal infringements of private data. They can generally only formulate relevant laws and regulations to punish relevant parties after the damage has occurred, but they cannot prevent or prevent the infringement from occurring.

[0147] In the system of the embodiment of the present disclosure, only the data subject itself and the management agency can access the private data, and other entities can no longer access the private data, eliminating the risk of intentional or unintentional privacy leakage; when interacting with other entities, the private subject can switch to a different anonymous identity at any time to replace its own private information, eliminating the possibility of other entities tracking and identifying the identity of the private subject based on historical interaction records; the management agency does not directly participate in or interfere with the interaction process between entities, nor does it participate in or interfere with the process of private subjects generating and switching anonymous identities, thus reducing management costs; the management agency has the ability to verify and track all identity keys issued by it, and can also verify and track all anonymous identities (subkeys) generated by the private data subject itself; it does not rely on any special hardware devices (such as trusted computing chips, etc.) or special network architectures (such as blockchain, etc.), and the current mainstream software and hardware system architecture can be applied to this method.

[0148] FIG12 is a schematic diagram of an e-commerce scenario application according to an embodiment of the present disclosure. As shown in FIG12 , in this embodiment:

[0149] 1) The management agency plays the role of the management agency, the natural person plays the role of the private data subject, and companies A and B play the role of the public data subject;

[0150] 2) The management agency first generates a root key. The key algorithm can use an asymmetric encryption algorithm such as ED25519. For the root key, only the private key of the root key is used, so the public key does not need to be stored. The root private key must be properly stored and cannot be leaked. The root key can be stored separately from other data in different data tables or in different databases.

[0151] 3) The management agency selects a KDF (Key Derivation Function) algorithm to generate a new identity key from the root key. KDF algorithms include but are not limited to PBKDF2, HKDF, Scrypt, and Argon2. Subsequent individuals must also use the same KDF algorithm when deriving subkeys.

[0152] 4) When using the KDF algorithm to derive identity keys, a root private key and a salt value (equivalent to a generated value) are required. For the convenience of backup and recovery, the generated value can use a value related to the source key but unknown to the outside as the initial value, and then increment by 1 each time a key is generated. In this way, all derived keys can be restored by backing up only one source key and the maximum generated sequence number, saving a lot of storage space. In this embodiment, when the management agency derives identity keys for natural persons or enterprises, it uses the public key of the root key as the initial value of the generated value, and increments the generated value by 1 each time a new identity key is generated. Since the public key and private key of the root key are not exposed to the outside, using the root public key as the salt value of the KDF algorithm will not reduce the strength of the generated key. At this time, the generated value is basically equivalent to the generated sequence number, and the management agency can restore all identity keys that have been generated based only on the root key and the maximum sequence number;

[0153] 5) Individuals must use some terminal software and hardware (e.g., a mobile app developed by the management agency) to implement interaction and data storage functions. They must use this terminal to register with the management agency. Upon approval, the management agency will generate and distribute a personal private key and save the serial number, private key, and private data in a corresponding data table. The terminal must also properly store the personal private key and private data (this data must not be disclosed to others) for subsequent use.

[0154] 6) When a natural person terminal uses the KDF algorithm to generate a subkey, it needs to input a personal private key and a generated value. The selection rules of the generated value are specified by the management agency. For example, in this embodiment, the management agency stipulates that the generated value of the subkey can only be selected from the integer range [1, 2048] (this means that any natural person can use a maximum of 2048 anonymous identities to participate in external interactions);

[0155] 7) Each enterprise also needs to provide information to the management agency and register. After passing the review, the management agency will generate and distribute the enterprise private key for it, and save the serial number, private key and enterprise data in the corresponding data table. The enterprise itself also needs to properly keep the enterprise private key (not to be disclosed to the outside);

[0156] 8) Whenever a new enterprise registers with the management agency, the management agency will extract the enterprise's public information (enterprise public key and enterprise information that must be disclosed) and save it in the corresponding data table. All registered natural persons or enterprises can obtain this public data through the data query process;

[0157] 9) When a natural person interacts with an enterprise through e-commerce:

[0158] The natural person terminal uses its own personal private key plus a generated value to derive a subkey (private key + public key) through the KDF algorithm and saves the newly generated subkey in the terminal;

[0159] If a natural person has generated some subkeys before, he or she can also directly choose to use these subkey data;

[0160] Individuals no longer expose their private data when interacting with businesses, and only use their sub-public key as a representation of their identity in order information. Enterprises, on the other hand, use their own corporate public key as a representation of their identity.

[0161] Both natural persons and enterprises can verify the legitimacy of each other's identities. Natural persons can directly verify the legitimacy of an enterprise through the enterprise public key included in the order and the public data provided by the management agency (wherein the public data includes but is not limited to: whether the enterprise exists, whether the business scope of the enterprise matches the order context, etc.); while the enterprise can query the management agency whether the natural person is legitimate through the sub-public key information included in the order (querying the legitimacy of a natural person with the management agency includes but is not limited to: querying whether the person exists, whether the person's age is legal in the current order context, whether the person's fund balance is sufficient to complete the current order, etc.);

[0162] 10) Individuals can pre-download all public data (and subscribe to public data change notifications from the management agency), which can avoid initiating a query process with the management agency every time they interact with the enterprise.

[0163] 11) If a natural person trusts the target enterprise, or believes that there is no high need for privacy protection in interactions with the enterprise, then the natural person can use the same sub-public key in multiple interactions with the enterprise. For example, each sub-public key can be verified once, which avoids the need for the enterprise to initiate an identity verification process with the management agency for each interaction. However, in return, the enterprise will be able to mine some information about the natural person from related orders (these orders are all related to the same customer, what are his / her preferences, what is the usual shopping time, etc.). However, the enterprise still cannot directly obtain the natural person's private data (such as name, gender, age, mobile phone number, ID number, etc.), and the amount of information that can be mined depends mainly on how long the natural person will use the same sub-key;

[0164] 12) All functional modules within all roles can be implemented using any programming language, any programming framework, and any interface interaction protocol based on actual needs, as long as they can meet the above functional characteristics and business processes.

[0165] The core point of the above embodiment is to use the KDF algorithm to implement a hierarchical anonymous identity key system, so that the top-level management organization can efficiently and completely manage the privacy data and anonymous identities of the entire system, maximize the security of privacy data, and provide higher application flexibility.

[0166] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present disclosure, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as a read-only memory / random access memory (ROM / RAM), a magnetic disk, or an optical disk), and includes a number of instructions for enabling a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in the various embodiments of the present disclosure.

[0167] This embodiment also provides an identity information verification system, which is configured to implement the above-mentioned embodiments and preferred embodiments. Details already described will not be repeated here. As used below, the term "module" may refer to a combination of software and / or hardware that implements a predetermined function. Although the systems described in the following embodiments are preferably implemented in software, implementation using hardware, or a combination of software and hardware, is also possible and contemplated.

[0168] FIG13 is a structural block diagram of an identity information verification system according to an embodiment of the present disclosure. As shown in FIG13 , the device includes:

[0169] Data subject 1302 is configured to send a verification request to the management device;

[0170] The management device 1304 is configured to receive the verification request, and when the verification request indicates verification of the identity information of the privacy data subject, verify the identity information of the privacy data subject according to the first sub-public key in the verification request, wherein the verification request includes: the first sub-public key of the privacy data subject, the first sub-public key is a public key generated by the privacy data subject according to the first identity key assigned by the management device and a preset rule, and the first sub-public key is the identity identifier of the privacy data subject.

[0171] Through the above system, since when the verification request indicates to verify the identity information of the privacy data subject, the identity information of the privacy data subject is verified according to the first sub-public key in the verification request, wherein the verification request includes: the first sub-public key of the privacy data subject, the first sub-public key is the public key generated by the privacy data subject according to the first identity key assigned by the management device and the preset rules, and the first sub-public key is the identity identifier of the privacy data subject, that is, the privacy subject in the embodiment of the present disclosure uses the identity key to derive the sub-key, and uses the public key in the sub-key as the identity identifier, therefore, only the management device can verify the identity information of the privacy data subject according to the sub-key. Therefore, it can solve the problems in the related technology that the user privacy data is not secure and easy to leak, thereby achieving the effect of reducing the exposure of privacy data.

[0172] In an exemplary embodiment, the data subject is further configured to send a registration request to the management device, wherein the registration request includes: the registration data of the data subject; the management device is configured to receive the registration request sent by the data subject, verify the identity information of the data subject based on the registration data; and upon determining that the identity information of the data subject is legal, send a third identity key to the data subject, and establish a correspondence between the third identity key and the registration data.

[0173] In an exemplary embodiment, when the data subject is a non-privacy data subject, the third identity key is received, and the identity public key in the third identity key is used as the identity identifier of the data subject; when the data subject is a privacy data subject, the third identity key is received, and a subkey corresponding to the third identity key is generated according to the preset rule, and the sub-public key corresponding to the subkey is used as the identity identifier of the data subject.

[0174] It should be noted that the above modules can be implemented through software or hardware. For the latter, it can be implemented in the following ways, but not limited to: the above modules are all located in the same processor; or the above modules are located in different processors in any combination.

[0175] To facilitate understanding of the technical solutions provided by the present disclosure, embodiments of the present disclosure will be described in detail below with reference to specific scenarios.

[0176] An embodiment of the present disclosure further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any one of the above method embodiments when run.

[0177] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0178] An embodiment of the present disclosure further provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0179] In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0180] For specific examples in this embodiment, reference may be made to the examples described in the above embodiments and exemplary implementation modes, and this embodiment will not be described in detail here.

[0181] Obviously, those skilled in the art should understand that the modules or steps of the present disclosure described above can be implemented using a general-purpose computing device, they can be concentrated on a single computing device, or distributed across a network composed of multiple computing devices, they can be implemented using program code executable by the computing device, and thus, they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be performed in a different order than herein, or they can be fabricated into separate integrated circuit modules, or multiple modules or steps can be fabricated into a single integrated circuit module for implementation. Thus, the present disclosure is not limited to any particular combination of hardware and software.

[0182] The foregoing description is merely a preferred embodiment of the present disclosure and is not intended to limit the present disclosure. Those skilled in the art will readily appreciate that various modifications and variations of the present disclosure are possible. Any modifications, equivalent substitutions, or improvements made within the principles of the present disclosure shall be included within the scope of protection of the present disclosure.

Claims

1. A method for verifying identity information, comprising: Receive verification requests sent by data subjects; In the case where the verification request indicates verification of the identity information of the privacy data subject, the identity information of the privacy data subject is verified according to the first sub-public key in the verification request, wherein the verification request includes: the first sub-public key of the privacy data subject, the first sub-public key is a public key generated by the privacy data subject according to the first identity key assigned by the management device and a preset rule, and the first sub-public key is the identity identifier of the privacy data subject, and the first identity key is the identity key of the privacy data subject.

2. The method according to claim 1, wherein: Verifying the identity information of the privacy data subject according to the first sub-public key in the verification request includes: Determine whether the first sub-public key is consistent with any second sub-public key corresponding to a plurality of identity keys stored in a management device, wherein the plurality of identity keys stored in the management device at least include: a first identity key of the privacy data subject and a third identity key of the data subject; When the first sub-public key is consistent with any second sub-public key corresponding to a plurality of identity keys stored in the management device, it is determined that the identity information of the privacy data subject is legal.

3. The method according to claim 2, wherein: Determine that the identity information of the subject of the privacy data is legal, including: Determine a first identity key corresponding to any second sub-public key, and determine the target data according to a correspondence between the first identity key and the target data; Acquire the interaction information carried in the verification request, wherein the interaction information is used to indicate whether the privacy data subject is legal in the target scenario; Verifying whether the subject of the privacy data is legal in the target scenario according to the target data; When the first sub-public key is consistent with any of the second sub-public keys and the privacy data subject is determined to be legal in the target scenario, the identity information of the privacy data subject is determined to be legal.

4. The method according to claim 1, wherein: After receiving the verification request sent by the data subject, the method further includes: In a case where the verification request indicates verification of the identity information of the non-privacy data subject, the identity information of the non-privacy data subject is verified according to the first identity public key in the verification request, wherein the verification request includes: the first identity public key of the non-privacy data subject, the first identity public key is the public key assigned to the non-privacy data subject by a management device, and the first identity public key is the identity identifier of the non-privacy data subject.

5. The method according to claim 4, wherein: Verifying the identity information of the non-privacy data subject according to the first identity public key in the verification request includes: Determine whether the first identity public key is consistent with any second identity public key of a plurality of second identity public keys, wherein the plurality of second identity public keys are identity public keys issued by the management device, and the plurality of second identity public keys include at least: the first identity public key; In the case where the first identity public key is consistent with any of the second identity public keys, it is determined that the identity information of the non-privacy data subject is legal.

6. The method according to claim 1, wherein: Before receiving the verification request sent by the data subject, the method further includes: receiving a registration request sent by the data subject, wherein the registration request includes: registration data of the data subject; Verifying the identity information of the data subject according to the registration data; When it is determined that the identity information of the data subject is legitimate, a third identity key is sent to the data subject, and a corresponding relationship between the third identity key and the registration data is established, wherein the third identity key is the identity key of the data subject.

7. The method according to claim 6, wherein: Before receiving the registration request sent by the data subject, the method further includes: Obtaining a root key, and generating a corresponding salt value according to the root key; The third identity key corresponding to the root key and the salt value is determined based on a key derivation algorithm.

8. A system for verifying identity information, comprising: The data subject is configured to send a verification request to the management device; A management device is configured to receive the verification request, and when the verification request indicates verification of the identity information of the privacy data subject, verify the identity information of the privacy data subject according to the first sub-public key in the verification request, wherein the verification request includes: the first sub-public key of the privacy data subject, the first sub-public key is a public key generated by the privacy data subject according to the first identity key assigned by the management device and a preset rule, and the first sub-public key is the identity identifier of the privacy data subject, and the first identity key is the identity key of the privacy data subject.

9. The system according to claim 8, wherein: include: The data subject is further configured to send a registration request to the management device, wherein the registration request includes: registration data of the data subject; The management device is configured to receive a registration request sent by the data subject, verify the identity information of the data subject based on the registration data; when determining that the identity information of the data subject is legal, send a third identity key to the data subject, and establish a corresponding relationship between the third identity key and the registration data, wherein the third identity key is the identity key of the data subject.

10. The system according to claim 9, wherein: include: In the case where the data subject is a non-privacy data subject, receiving the third identity key, and using the identity public key in the third identity key as the identity identifier of the data subject; In the case where the data subject is a private data subject, receiving the third identity key, and A subkey corresponding to the third identity key is generated, and a sub-public key corresponding to the subkey is used as the identity identifier of the data subject.

11. A computer-readable storage medium having a computer program stored therein, wherein: When the computer program is executed by a processor, the steps of the method described in any one of claims 1 to 7 are implemented.

12. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the method described in any one of claims 1 to 7 when executing the computer program.

Images