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

Abstract

The embodiment of the invention provides an identity information verification method and system, a storage medium and an electronic device, and the method comprises the steps: receiving a verification request sent by a data main body; under the condition that the verification request indicates to verify the identity information of the private data main body, the identity information of the private data main body is verified according to a first sub-public key in the verification request, and the verification request comprises the first sub-public key of the private data main body and the second sub-public key of the private data main body; the first sub-public key is a public key generated by a private data main body according to a first identity key distributed by management equipment and a preset rule, and the first sub-public key is an identity label of the private data main body.

Description

Technical Field

[0001] The embodiments of the present application relate 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

[0002] With the booming development of the information industry, data privacy protection issues have received more and more attention and importance from the industry. 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 consumers' privacy and security. At the same time, countries such as China, Japan, and Australia have also enacted similar laws to protect personal privacy and data security.

[0003] However, with the continuous development of information technology, the amount of data generated in people's daily lives is becoming increasingly huge. Many companies lack professionalism and investment in security protection, and confidential data of companies is often leaked due to improper management and other reasons. Once private data is leaked, it is irreversible.

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

[0005] Currently, in most cases, companies have direct access to private data provided by customers. Even if companies need to anonymize and report private data according to management regulations, the entire data processing process is completed by the company, so the original private information is visible to the company. At present, management agencies mainly use regulations to constrain the behavior of companies, and generally do not directly intervene in the company's data processing process (this is mainly due to management cost considerations). Therefore, if a company decides to infringe and use private data for some reason, it is difficult for the management agency to detect and prevent it in time. At most, it can only impose ex post punishment after the loss has been incurred.

[0006] Therefore, the existing technology has the problems that the user privacy data is not secure and is easily leaked. Summary of the invention

[0007] The embodiments of the present application 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 the related art that user privacy data has low security and is easy to leak.

[0008] According to one embodiment of the present application, a method for verifying identity information is provided, comprising: receiving a verification request sent by a data subject; 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.

[0009] In an exemplary embodiment, after receiving a verification request sent by a data subject, the method further includes: when the verification request indicates verification of the identity information of a non-privacy data subject, verifying the identity information of the non-privacy data subject according to a 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 being a public key assigned to the non-privacy data subject by a management device, and the first identity public key being an identity identifier of the non-privacy data subject.

[0010] In an exemplary embodiment, verifying the identity information of the non-privacy data subject according to the first identity public key in the verification request includes: determining whether the first identity public key is consistent with any second identity public key of multiple second identity public keys, wherein the multiple second identity public keys are identity public keys issued by the management device, and the multiple second identity public keys include at least: the first identity public key; when the first identity public key is consistent with any second identity public key, determining that the identity information of the non-privacy data subject is legal.

[0011] In an exemplary embodiment, verifying the identity information of the privacy data subject according to the first sub-public key in the verification request includes: generating multiple second sub-keys corresponding to the multiple second identity keys respectively according to the preset rules, wherein the multiple second identity keys are identity keys issued by the management device, and the multiple second identity keys include at least: the first identity key; determining whether the first sub-public key is consistent with any second sub-public key corresponding to the multiple second sub-public keys; and determining that the identity information of the privacy data subject is legal when the first sub-public key is consistent with any second sub-public key corresponding to the multiple second sub-public keys.

[0012] In an exemplary embodiment, determining whether the identity information of the privacy data subject is legal includes: determining the first identity key corresponding to any second sub-public key, and determining the target data based on the correspondence between the first identity key and the target data; obtaining the interactive information carried in the verification request, wherein the interactive information is used to indicate whether the privacy data subject is legal in the target scenario; verifying whether the privacy data subject is legal in the target scenario based on the target data; and determining that the identity information of the privacy data subject is legal when the first sub-public key is consistent with any second sub-public key corresponding to the multiple second sub-public keys and the privacy data subject is determined to be legal in the target scenario.

[0013] In an exemplary embodiment, before receiving a verification request sent by a 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 based on the registration data; and upon determining that the identity information of the data subject is legitimate, sending a third identity key to the data subject, and establishing a corresponding relationship between the third identity key and the registration data.

[0014] In an exemplary embodiment, before receiving the registration request sent by the data subject, the method further includes: obtaining a root key, and generating a corresponding salt value based on the root key; and determining the third identity key corresponding to the root key and the salt value based on a key derivation algorithm.

[0015] According to another embodiment of the present application, a system for verifying identity information is provided, including: a data subject, used to send a verification request to a management device; a management device, used 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.

[0016] In an exemplary embodiment, the data subject is also used 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 used to receive the registration request sent by the data subject, and verify 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 legal, send a third identity key to the data subject, and establish a corresponding relationship between the third identity key and the registration data.

[0017] 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 of the data subject; when the data subject is a privacy data subject, the third identity key is received, and a sub-key corresponding to the third identity key is generated according to the preset rule, and the sub-public key corresponding to the sub-key is used as the identity of the data subject.

[0018] According to another embodiment of the present application, a computer-readable storage medium is provided, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above method embodiments when run.

[0019] According to another embodiment of the present application, 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 execute the steps in any one of the above method embodiments.

[0020] Through this application, 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 rule, 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 application 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, the problems of low security and easy leakage of user privacy data in the related technology can be solved, thereby achieving the effect of reducing the exposure of privacy data. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 It is a hardware structure block diagram of a computer terminal according to a method for verifying identity information in an embodiment of the present application;

[0022] Figure 2 is a flow chart of a method for verifying identity information according to an embodiment of the present application;

[0023] Figure 3 is a subkey derivation flow chart according to an embodiment of the present application;

[0024] Figure 4 is a flowchart of identity key legitimacy verification according to an embodiment of the present application;

[0025] Figure 5is a data update flow chart according to an embodiment of the present application;

[0026] Figure 6 is a data registration flow chart according to an embodiment of the present application;

[0027] Figure 7 is a flow chart of identity key generation according to an embodiment of the present application;

[0028] Figure 8 is an authentication flow chart according to an embodiment of the present application;

[0029] Fig. 9 is a data query flow chart according to an embodiment of the present application;

[0030] Fig.10 is a schematic diagram of a hierarchical key system according to an embodiment of the present application;

[0031] Fig.11 is a system module relationship diagram according to an embodiment of the present application;

[0032] Fig.12 is a schematic diagram of an e-commerce scenario application according to an embodiment of the present application;

[0033] Fig.13 It is a structural block diagram of an identity information verification system according to an embodiment of the present application. DETAILED DESCRIPTION

[0034] The embodiments of the present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

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

[0036] The method embodiments provided in the embodiments of the present application 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 1 is a hardware structure block diagram of a computer terminal of an identity information verification method according to an embodiment of the present application. Figure 1 As shown, the computer terminal may include one or more ( Figure 1Only one is shown in the figure) a processor 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 Figure 1 The structure shown is only for illustration and does not limit the structure of the above-mentioned computer terminal. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations shown.

[0037] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the verification method of identity information in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, to implement the above 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 arranged 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.

[0038] The transmission device 106 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of a computer terminal. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, referred to as NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0039] Figure 2 is a flow chart of a method for verifying identity information according to an embodiment of the present application. Figure 2 As shown, the process includes the following steps:

[0040] Step S202, receiving a verification request sent by the data subject;

[0041] Step S204, 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.

[0042] 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 rule, 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 application 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, the problems of low security and easy leakage of user privacy data in the related technology can be solved, thereby achieving the effect of reducing the exposure of privacy data.

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

[0044] 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;

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

[0046] Step 13: When 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 according to the correspondence between the first identity key and the target data;

[0047] Step 14: Obtaining 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;

[0048] Step 15: Verify whether the privacy data subject is legal in the target scenario according to the target data;

[0049] Step 16: When 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.

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

[0051] Since the above 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 embodiment) can derive all subkeys that may be generated by the privacy data subject based on the identity key and preset rules it has, and compare them with the first sub-public key. In the case where 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. According to the association between the recorded identity key and the target data, the target data of the data subject can be determined, and whether the privacy data subject is legal in the target scenario can be determined based on the target data.

[0052] Furthermore, the privacy data subject can generate multiple subkeys according to its own needs, and choose to use different subkeys in different interaction processes to avoid the outside world from tracking its own behavior and identity, thereby greatly reducing the probability of privacy data exposure and reducing the risk of data exposure. The privacy data subject can also inform a specific subject of the association relationship of some subkeys for some reasons (for example, in order to obtain better services), so that the specific subject can know that the same subject is behind these subkeys (so as to better serve the privacy subject). However, no matter what choice is made, except for the above-mentioned management agencies and the privacy data subject itself, no one can directly obtain the data of the privacy data subject, and it is difficult to associate and threaten the true identity of the privacy data subject by mining and analyzing multiple subkeys. The control of the generation, use and exposure of the association relationship of subkeys is in the hands of the privacy data subject. Even if some subkey association information has been exposed to malicious subjects, the privacy subject can easily implement defense and control the scope of damage (for example, generate and use new subkeys and no longer use the exposed subkeys).

[0053] The embodiment of the present invention provides a method for a privacy data subject to generate a subkey. The subkey derivation process of the privacy data subject is as follows: Figure 3 As shown, the specific steps are as follows:

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

[0055] Specifically, the privacy data subject first needs to determine a generated value according to a preset rule. This preset rule can be formulated by the management agency. For example, it is stipulated that the generated value must be randomly selected from the integer range of [1-2048]; or, the generated value = identity public key + generation number (where the initial value of the generation number is 0, each time a subkey is generated + 1, the maximum value is 2048, and it is used in a cycle). Since the generated value rules are formulated 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.

[0056] Step S302, generating a new subkey (equivalent to the first subkey in the above embodiment) according to the identity key (equivalent to the above first identity key) and the generated value;

[0057] 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 KDF algorithm.

[0058] Step S303: save the subkey and additional information.

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

[0060] 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?)

[0061] Through the above embodiments, the verifier can only determine whether the data subject is legal in the current scenario, but cannot obtain the data subject's privacy 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.

[0062] The private data and the real identity behind it are represented by a sub-public key. When the participants in the interaction need to verify whether a sub-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 an identity legitimacy verification process with the management agency, such as Figure 4 As shown, the specific steps are as follows:

[0063] Step S401: the management machine authenticates the requester;

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

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

[0066] Step S404: if the authentication fails, feedback that the authentication failed;

[0067] 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;

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

[0069] 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);

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

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

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

[0073] Step S411: when the data subject is illegal in the interaction context, feedback is given that the target subject is illegal in the interaction context;

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

[0075] Optionally, when 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 the management device, and the first identity public key is the identity identifier of the non-privacy data subject.

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

[0077] Step 21: 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 at least include: the first identity public key;

[0078] 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.

[0079] Since the non-privacy data subject (such as an enterprise) can only use its own identity key to disclose information (public key) 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 the multiple identity keys to see if 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.

[0080] Optionally, the data subject can update the data stored in the security device in the following manner: Figure 5 As shown, including:

[0081] Step S501: The data subject sends an update request to the management agency so that the management agency can verify the legitimacy of the identity of the data subject, wherein the update request includes: the identity public key or sub-public key of the data subject;

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

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

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

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

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

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

[0088] 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: 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.

[0089] It is understood that the registration process for data subjects is as follows Figure 6 As shown, the registration data of the data subject includes: data that can prove its identity or legitimacy, where for the privacy data subject (for example: natural person), the registration data is private data; for the non-privacy data subject (for example: enterprise), the registration data is public data. The specific steps are as follows:

[0090] Step S601: accepting a registration request sent by a data subject;

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

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

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

[0094] It should be noted that the generated value must be a value related to the root key and can be derived from the root key and a small amount of public information. For example: generated value = root public key + generated number. Later, only the root public key and the maximum generated number are needed to restore all generated values ​​and then all identity keys, which is very beneficial for backup and recovery.

[0095] Step S605: using a KDF (Key Derivation Function) algorithm, taking the root key and the generated value as input, deriving an identity key, and sending the identity key to the data subject;

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

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

[0098] Optionally, in an embodiment of the present invention, multiple identity keys may be generated in advance, specifically: a root key is obtained, and a corresponding salt value is generated based on the root key; and the identity key corresponding to the root key and the salt value is determined based on a key derivation algorithm.

[0099] It is understandable that the process of obtaining the root key is as follows Figure 7 As shown, including:

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

[0101] 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.

[0102] Step S702, generate a root key;

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

[0104] Step S703, save the root key.

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

[0106] Optionally, before receiving the verification request sent by the data subject, it also 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.

[0107] It is understandable that before receiving the verification request sent by the device body, such as Figure 8 The method also includes:

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

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

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

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

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

[0113] Step S805: verify the signature according to the public key of the identity key and the random number obtained previously;

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

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

[0116] Optionally, an embodiment of the present application also 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: a public type, a 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.

[0117] It can be understood that the types of data include one of the following: public type and private type. For the public type, all devices have the right to access. Public data mainly includes public identity public key and public information; for the private type, only the private data subject can access his own private data, and no device has the right to access the private type data that does not belong to it.

[0118] In the case that the data type is of 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.

[0119] Specifically, the data query method in the embodiment of the present invention is as follows: Fig. 9 As shown, the specific steps are as follows:

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

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

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

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

[0124] Step S905: When the requester has no right to access the target data, or when the authentication fails, the data query fails.

[0125] 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 an optional embodiment, but it is not used to limit the technical solution of the embodiment of the present application.

[0126] Fig.10 is a schematic diagram of a hierarchical key system according to an embodiment of the present application, such as Fig.10 As shown:

[0127] 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;

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

[0129] 3) Since the management agency controls the identity keys and corresponding privacy data of all privacy 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 in combination with the privacy data;

[0130] 4) Some entities are not private data subjects (such as enterprises), so they must directly use the identity key (public key) during the interaction process and cannot derive and use subkeys. At the same time, the public key and identity information of their identity key are made public by the management agency, and any entity can verify its identity at any time.

[0131] In summary, this solution eliminates the risk of privacy data leakage during data interaction by isolating private data from other entities and using a specially designed hierarchical key system. The top-level management agency is able to audit and track the information of all parties involved in the interaction without directly monitoring or interfering with the interaction process.

[0132] Fig.11 is a system module relationship diagram according to an embodiment of the present application, such as Fig.11 As shown:

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

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

[0135] In the system described in the embodiment of the present application, the privacy data subject includes: a key application module E and a privacy data module F;

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

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

[0138] When a managed entity registers with the management agency, module A needs to generate an identity key for any managed entity based on the root key and a generated value, 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 saved). It can also further save all generated identity keys to improve the efficiency of subsequent processes;

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

[0140] Whenever a private data subject (e.g. a natural person) registers with a management agency, he or she needs to provide his or her own private data. The private data is not allowed to be made public and is only accessible to the management agency and the data subject. Module B is responsible for receiving and properly keeping this data, and also records the relationship between the identity key generated by module A and the private data for use in subsequent processes;

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

[0142] Whenever a public data subject (e.g., a company) registers with a management agency, the management agency and the subject need to jointly determine its public data information (e.g., business license and business address, etc.), which can be accessed by anyone. Module C is responsible for receiving and saving this data, and also records the relationship between the identity key generated by module A and the public data for use in subsequent processes;

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

[0144] The identity key distributed by the management agency to each data subject will be used in the data interaction 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);

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

[0146] 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 privacy data subject should use the public key of the subkey as a representative of its own identity, so that other interacting parties will find it difficult to track its specific privacy identity. The management agency has the ability to calculate the corresponding privacy data subject identity based only on the subpublic key + generated value;

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

[0148] Module F is mainly responsible for properly preserving the privacy data of the data subject and interacting with the management agency or updating the content when necessary (for example, when some privacy data content needs to be updated);

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

[0150] The main responsibility of module G 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 representative of the interactive identity in daily data interaction activities. The public data subject is not allowed to use alternative identities (such as subkeys), and 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;

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

[0152] 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, the content of some public data needs to be updated).

[0153] Compared with the above system modules, in traditional systems, the privacy data of the privacy data subject is visible to all interacting parties, which is very easy to leak or illegally used. Even if some improved systems use random values ​​to replace the specific privacy information in the interaction process, this anonymous scheme is often designed and implemented by one of the parties involved in the interaction (for example: the interaction between a natural person and a data enterprise). If the implementer of the anonymous scheme is unreliable, the security of the privacy data cannot be ensured. Finally, in traditional systems, the top-level management agency has no mandatory binding force on the illegal infringement of privacy data. Generally, it can only formulate relevant laws and regulations and punish the relevant subjects after the damage has occurred, but it cannot eliminate and prevent the occurrence of infringement.

[0154] In the system of the embodiment of the present application, 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 privacy subject can switch to different anonymous identities at any time to replace its own privacy information, eliminating the possibility of other entities tracking and identifying the identity of the privacy 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 privacy subjects generating and switching anonymous identities, so the management cost is low; 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 privacy data subject itself; it does not rely on any special hardware devices (for example: trusted computing chips, etc.), does not rely on special network architectures (for example: blockchain, etc.), and the current mainstream software and hardware system architectures can apply this method.

[0155] like Fig.12 is a schematic diagram of an e-commerce scenario application according to an embodiment of the present application, such as Fig.12 As shown, in this embodiment:

[0156] 1) The management agency plays the role of the management agency, the natural person plays the role of the privacy data subject, and enterprises A and B play the role of the public data subject;

[0157] 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 will be used, so the public key does not need to be saved. The root private key must be properly stored and must not be leaked. The root key can be stored separately from other data in different data tables or in different databases;

[0158] 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. The same KDF algorithm must also be used when natural persons derive subkeys in the future;

[0159] 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 increases the generated value by 1 each time a new identity key is generated. Since neither the public key nor the private key of the root key is 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;

[0160] 5) Natural persons need to use some terminal software and hardware (for example, a mobile phone app developed by the management agency) to realize the interaction and data storage functions. Natural persons need to use the terminal to register with the management agency. After the management agency reviews and approves it, it will generate and distribute a personal private key for them, and save the serial number, private key and privacy data in the corresponding data table. The natural person terminal also needs to properly save personal private keys and privacy data (these data cannot be leaked to the outside) for subsequent use.

[0161] 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 rule of the generated value is 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 of [1, 2048] (this means that any natural person can use up to 2048 anonymous identities to participate in external interactions);

[0162] 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 leaked to the outside);

[0163] 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;

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

[0165] 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 to the terminal;

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

[0167] Natural persons no longer expose their private data during the interaction with enterprises, and only use the sub-public key as a representative of their identity in the order information. Enterprises, on the other hand, use their own corporate public key as a representative of their identity;

[0168] Both natural persons and enterprises can verify the legitimacy of each other's identities. Natural persons can directly verify the legitimacy of enterprises through the enterprise public key contained 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.); and enterprises can query the management agency whether the natural person is legal through the sub-public key information contained in the order (querying the management agency whether the natural person is legal 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.);

[0169] 10) Natural persons can download all public data in advance (and subscribe to public data change notifications from the management agency), so as to avoid initiating a query process with the management agency every time they interact with the enterprise

[0170] 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 every time it interacts. However, in contrast, 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 privacy data of the natural person (such as name, gender, age, mobile phone number, ID number, etc.), and the amount of information that can be mined mainly depends on how long the natural person will use the same sub-key;

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

[0172] 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.

[0173] 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 a 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 such an understanding, the technical solution of the present application, 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 disk, or an optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0174] In the present embodiment, a verification system for identity information is also provided, which is used to implement the above-mentioned embodiments and preferred implementation modes, and the descriptions that have been made will not be repeated. As used below, the term "module" can implement a combination of software and / or hardware of a predetermined function. Although the system described in the following embodiments is preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0175] Fig.13 is a structural block diagram of an identity information verification system according to an embodiment of the present application, such as Fig.13 As shown, the device comprises:

[0176] Data subject 1302, used to send a verification request to the management device;

[0177] The management device 1304 is used 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.

[0178] Through the above system, 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 rule, 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 application 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, the problems of low security and easy leakage of user privacy data in the related technology can be solved, thereby achieving the effect of reducing the exposure of privacy data.

[0179] In an exemplary embodiment, the data subject is also used 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 used to receive the registration request sent by the data subject, and verify 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 legal, send a third identity key to the data subject, and establish a corresponding relationship between the third identity key and the registration data.

[0180] 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 of the data subject; when the data subject is a privacy data subject, the third identity key is received, and a sub-key corresponding to the third identity key is generated according to the preset rule, and the sub-public key corresponding to the sub-key is used as the identity of the data subject.

[0181] It should be noted that the above modules can be implemented by 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.

[0182] To facilitate the understanding of the technical solution provided by the present application, a detailed explanation will be given below in combination with embodiments of specific scenarios.

[0183] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above method embodiments when running.

[0184] 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.

[0185] An embodiment of the present application further provides an electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0186] 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.

[0187] 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 herein.

[0188] Obviously, those skilled in the art should understand that the above modules or steps of the present application can be implemented by a general computing device, they can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, they can be implemented by a program code executable by a computing device, so that 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 executed in a different order from that herein, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. Thus, the present application is not limited to any specific combination of hardware and software.

[0189] The above description is only the preferred embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the principles of the present application shall be included in the protection scope of the present application.

Claims

1. A method for verifying identity information, characterized in that: include: 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.

2. The method according to claim 1, characterized in that Verifying the identity information of the privacy data subject according to the first sub-public key in the verification request includes: Generate multiple second subkeys corresponding to multiple second identity keys respectively 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; Determining whether the first sub-public key is consistent with any second sub-public key corresponding to the plurality of second sub-public keys; When the first sub-public key is consistent with any second sub-public key corresponding to the plurality of second sub-public keys, it is determined that the identity information of the privacy data subject is legal.

3. The method according to claim 2, characterized in that 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 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, the identity information of the privacy data subject is determined to be legal.

4. The method according to claim 1, characterized in that: 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, characterized in that 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 at least include: 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, characterized in that 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.

7. The method according to claim 6, characterized in that 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 verification system for identity information, characterized in that: include: Data subject, used to send a verification request to the management device; A management device is used 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.

9. The system according to claim 8, characterized in that include: The data subject is further used to send a registration request to the management device, wherein the registration request includes: registration data of the data subject; The management device is used to receive a registration request sent by the data subject, verify 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 legal, send a third identity key to the data subject, and establish a corresponding relationship between the third identity key and the registration data.

10. The system according to claim 9, characterized in that 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, the third identity key is received, and a subkey corresponding to the third identity key is generated according to the preset rule, and a sub-public key corresponding to the subkey is used as the identity of the data subject.

11. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, wherein the computer program implements the steps of the method described in any one of claims 1 to 7 when executed by a processor.

12. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the method described in any one of claims 1 to 7 are implemented.

Images