Identity mutual recognition method and device, and electronic device

Abstract

The application provides an identity mutual recognition method and device and electronic equipment, and relates to the technical field of communication. The method comprises the following steps: obtaining an interaction request and a dynamic certificate sent by a first digital twin monomer; the dynamic certificate is generated by signing a combination of a random number and an identity identifier of the first digital twin monomer with a working private key of the first digital twin monomer; performing signature verification on the dynamic certificate based on the interaction request; in response to successful signature verification, obtaining a current trust value of the first digital twin monomer stored in a block chain; sending the interaction request, the dynamic certificate and the current trust value to a second digital twin monomer to obtain a Shannon entropy value of the random number returned by the second digital twin monomer; and in response to the Shannon entropy value being a normal entropy value, the second digital twin monomer and the first digital twin monomer establish interaction.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of communication, in particular to an identity mutual recognition method and device and electronic equipment. BACKGROUND

[0002] In the construction process of a digital twin alliance, integrating heterogeneous digital twin systems is a key link to achieve efficient collaboration. However, the digital identity adopted by each system is significantly different, including Public Key Infrastructure (PKI), Decentralized ID (DID), and biometrics, and these identities are incompatible, causing the inability to dynamically verify the authenticity of the identity when interacting across systems, relying on complex intermediary conversion, high latency, and being vulnerable to replay attacks, resulting in identity mutual recognition failure. Moreover, traditional static certificates cannot perceive identity theft, cross-alliance malicious jumping, and other behaviors, and independent AI monitoring systems are disconnected from the identity system, making it difficult to associate abnormal behaviors with the source of the identity in a timely manner, resulting in an abnormal detection blind area.

[0003] In summary, the PKI mutual recognition mechanism across Certificate Authorities (CAs) has high latency, the blockchain unified identity resource consumes too much, and manual trust assessment response lags, which cannot meet the security needs of real-time collaboration at the alliance level. SUMMARY

[0004] The present application provides an identity mutual recognition method, device and electronic equipment to at least solve the above technical problems in the prior art.

[0005] In a first aspect of the present application, an identity mutual recognition method is provided, comprising:

[0006] obtaining an interaction request and a dynamic certificate sent by a first digital twin monomer; the dynamic certificate is generated by signing the combination of a random number and an identity of the first digital twin monomer with a working private key of the first digital twin monomer;

[0007] performing signature verification on the dynamic certificate based on the interaction request;

[0008] in response to successful signature verification, obtaining a current trust value of the first digital twin monomer stored in a blockchain;

[0009] sending the interaction request, dynamic certificate and current trust value to a second digital twin monomer to obtain a Shannon entropy value of the random number returned by the second digital twin monomer;

[0010] in response to the Shannon entropy value being a normal entropy value, the second digital twin monomer and the first digital twin monomer establish interaction.

[0011] In an implementable manner, further comprising:

[0012] In response to the Shannon entropy value being an abnormal entropy value, the second digital twin monomer analyzes the access behavior features of the first digital twin monomer by using a behavior analysis model;

[0013] Based on the access behavior features, a behavior deviation degree is determined;

[0014] If the behavior deviation degree is less than or equal to a first threshold value, a restricted interaction between the second digital twin monomer and the first digital twin monomer is performed; the behavior deviation degree is a deviation degree of the access behavior features of the first digital twin monomer from preset normal behavior features;

[0015] If the behavior deviation degree is greater than the first threshold value, it is determined that the identity of the first digital twin monomer is abnormal.

[0016] In an implementable manner, in response to the identity of the first digital twin monomer being abnormal, dynamic trust evaluation is performed on the first digital twin monomer to obtain a new trust value;

[0017] If the new trust value is lower than a second threshold value, the dynamic certificate is revoked and the interaction request is rejected.

[0018] In an implementable manner, the first digital twin monomer is dynamically evaluated to obtain a new trust value in the following manner,

[0019] Trust = a · (1-β)

[0020] β = 0.6x + 0.4y

[0021] Wherein, a is a basic trust value, β is an abnormal behavior weight, x is an entropy abnormality rate, and y is a behavior deviation degree.

[0022] In an implementable manner, the signature verification of the dynamic certificate based on the interaction request comprises:

[0023] Verifying a first layer signature; the first layer signature is a signature of a private key of the first digital twin monomer on the address of the first digital twin monomer;

[0024] Verifying a second layer signature; the second layer signature is a signature of a randomly generated session private key on a random number;

[0025] Verifying a third layer signature; the third layer signature is a signature of a work private key on an identity of the first digital twin monomer based on a randomly generated random number.

[0026] In an implementable manner, the signature verification of the dynamic certificate based on the interaction request further comprises:

[0027] checking the permission of the first digital twin monomer, and determining whether the permission of the first digital twin monomer is within the authorized range of the second digital twin monomer.

[0028] In an implementable manner, after the signature verification of the dynamic certificate based on the interaction request, the method further comprises:

[0029] In response to the signature verification failure, the interaction request of the first digital twin monomer is rejected.

[0030] In an implementable manner, in response to the Shannon entropy value being an abnormal entropy value, an alarm prompt is performed.

[0031] In a second aspect of the present application, an identity mutual recognition device is provided, comprising:

[0032] A first acquisition module is configured to acquire an interaction request and a dynamic certificate sent by a first digital twin monomer; the dynamic certificate is generated by signing a combination of a random number and an identity identifier of the first digital twin monomer with a working private key of the first digital twin monomer;

[0033] A signature verification module is configured to perform signature verification on the dynamic certificate based on the interaction request.

[0034] A second acquisition module is configured to acquire a trust value of the first digital twin monomer stored in a block chain in response to the signature verification success.

[0035] A third acquisition module is configured to send the interaction request, the dynamic certificate, and the trust value to a second digital twin monomer, and obtain a Shannon entropy value of the random number returned by the second digital twin monomer.

[0036] An interaction establishment module is configured to, in response to the Shannon entropy value being a normal entropy value, establish interaction between the second digital twin monomer and the first digital twin monomer.

[0037] In a third aspect of the present application, an electronic device is provided, comprising:

[0038] at least one processor;

[0039] and a memory in communication connection with the at least one processor; wherein

[0040] The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method described in the present application.

[0041] In a fourth aspect, the present application provides a non-transitory computer-readable storage medium storing computer instructions for causing a computer to execute the method described in the present application.

[0042] The identity mutual recognition method, device and electronic equipment provided by the present application can perform signature verification on the dynamic certificate generated by the first digital twin monomer, implement identity authentication between different systems, eliminate cross-system authentication delay, improve efficiency, and meet the security requirements of alliance-level real-time collaboration.

[0043] It should be understood that the content described in this part is not intended to identify key or important features of the embodiments of the present application, nor is it used to limit the scope of the present application. Other features of the present application will become apparent from the following description. BRIEF DESCRIPTION OF DRAWINGS

[0044] The above and other objects, features and advantages of the exemplary embodiments of the present application will be more apparent from the following detailed description read in conjunction with the accompanying drawings, in which:

[0045] In the drawings, the same or corresponding reference numerals denote the same or corresponding parts.

[0046] Figure 1 An implementation flowchart of the identity mutual recognition method of the embodiment of the present application is shown;

[0047] Figure 2 Another implementation flowchart of the identity mutual recognition method of the embodiment of the present application is shown;

[0048] Figure 3 A structure diagram of the identity mutual recognition device of the embodiment of the present application is shown;

[0049] Figure 4 A composition structure diagram of an electronic device of the embodiment of the present application is shown. DETAILED DESCRIPTION

[0050] In order to make the purposes, features and advantages of the present application more obvious and easy to understand, the technical solutions in the embodiments of the present application will be described clearly and completely below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0051] A kind of identity mutual recognition method, device and electronic equipment provided by the present application will be introduced below in conjunction with drawings.

[0052] AsFigure 1 As shown, this application provides a method for mutual identity recognition, including:

[0053] S101, Obtain the interaction request and dynamic certificate sent by the first digital twin entity; the dynamic certificate is generated by signing a combination of a random number and the identity identifier of the first digital twin entity using the working private key of the first digital twin entity;

[0054] like Figure 2 As shown, the first digital twin entity can be a vendor system. When submitting an interaction request, the first digital twin entity sends its identity identifier ID_A to the consortium platform. The identity identifier ID_A can be a PKI public key. It should be noted that the first digital twin entity sends a dynamic certificate to the consortium platform simultaneously with the interaction request. This dynamic certificate is generated by the certificate management tool (Chen-Fan-Lv, CFL) within the first digital twin entity. CFL is an identity-based certificate authentication system and serves as the certificate management tool in this application. The certificate management tool generates a random number r and uses the first digital twin entity's working private key SK_A to perform a double dynamic signature on the combination of the identity identifier and the random number (ID_A||r), outputting a dynamic certificate. Then, the first digital twin entity sends an interaction request to the consortium platform, simultaneously submitting its dynamic certificate (including the random number r).

[0055] For example, when a traffic light, acting as the first digital twin, detects a decrease in traffic flow at night, it sends a "power-saving mode" request to the alliance platform and submits a dynamic certificate (including device ID, location coordinates, real-time traffic flow data, etc.).

[0056] The identity verification method provided in this application is implemented through an alliance platform. The alliance platform is the Digital Twin Alliance Platform.

[0057] S102, Perform signature verification on the dynamic certificate based on the interaction request;

[0058] After receiving the interaction request and dynamic certificate from the first digital twin entity, the alliance platform first performs signature authentication on the dynamic certificate.

[0059] S103, in response to successful signature verification, obtain the current trust value of the first digital twin stored in the blockchain;

[0060] If the consortium platform successfully authenticates the signature of the dynamic certificate, it sends a request to the blockchain to query the trust value of the first digital twin. After receiving the request, the blockchain sends the corresponding current trust value to the consortium platform.

[0061] It should be noted that the trust value in the blockchain is the basic trust value of the first digital twin monomer stored in the blockchain after the alliance platform successfully signs and authenticates the dynamic certificate. However, over time, the trust value will change, and the trust value queried by the alliance platform is the current trust value after the change.

[0062] S104, the interaction request, the dynamic certificate and the current trust value are sent to the second digital twin monomer, and the Shannon entropy value of the random number returned by the second digital twin monomer is obtained;

[0063] The alliance platform combines the interaction request, the dynamic certificate and the current trust value of the first digital twin monomer, and sends the combination to the second digital twin monomer. The second digital twin monomer obtains the random number r of the dynamic certificate and calculates the Shannon entropy value of the random number r. The Shannon entropy value of a discrete random variable r, which can take values. It takes the logarithm of the probability of each possible result and sums the weighted sum (the weighting factor is the probability itself). The Shannon entropy value essentially measures the average uncertainty of predicting the result of a random variable.

[0064] If the Shannon entropy value is a normal entropy value, it means that the random number r is random enough, and it can be considered that the dynamic certificate has not been tampered with or forged. The Shannon entropy value can be divided into high entropy value and low entropy value. According to the Shannon entropy formula H = -∑ i P(x i )log P(x i ), when the random variable is uniformly distributed, the entropy reaches the maximum value H = log n, where n is the number of possible states of the random variable. In this application, the high entropy value H ≥ 7.0 means that n ≥ 77 = 128. The random number needs to have at least 128 possible states with equal probability. High entropy value represents strong randomness and no obvious regularity of data sequence, high information content. That is, the random number r is random enough, and it can be considered that the certificate has not been tampered with or forged, and the second digital twin monomer directly authorizes the interaction with the first digital twin monomer. The low entropy value is the Shannon entropy value H < 7.0. Low entropy value represents strong regularity and high predictability of data sequence, low information content. It can also be considered as an abnormal entropy value. The random number r may have regularity (such as repeated generation, malicious control), and may be an attack behavior (such as forging identity, replay attack), at which time further verification of security is triggered. In response to the Shannon entropy value being an abnormal entropy value, the alliance platform can also perform alarm prompting.

[0065] Exemplarily, the alliance platform forwards the interaction request, the dynamic certificate and the trust value mark to a second digital twin monomer together. For example, the second digital twin monomer can be an energy network. The alliance platform forwards the request to the energy network. The energy network calculates the Shannon entropy value of the random number r. For example, city risk 1: if the r repetition is detected and the request comes from a sensitive area (such as the surrounding area of a government building), a "critical facility protection" alarm is triggered; city risk 2: if the request surges (such as 50 times in 1 minute), a "DDOS attack suspicion" mark is added.

[0066] S105, in response to the Shannon entropy value being a normal entropy value, the second digital twin monomer establishes interaction with the first digital twin monomer.

[0067] When the Shannon entropy value is a normal entropy value, the second digital twin monomer can directly authorize interaction with the first digital twin monomer. In this way, identity recognition of the digital twin alliance is realized.

[0068] The identity recognition method provided by the present application can verify the dynamic certificate generated by the first digital twin monomer, realize identity authentication between different systems, eliminate cross-system authentication delay, improve efficiency, and meet the security requirements of alliance-level real-time collaboration.

[0069] In some embodiments, the identity recognition method provided by the present application further comprises:

[0070] In response to the Shannon entropy value being an abnormal entropy value, the second digital twin monomer analyzes the access behavior characteristics of the first digital twin monomer using a behavior analysis model;

[0071] Based on the access behavior characteristics, a behavior deviation degree is determined;

[0072] If the behavior deviation degree is less than or equal to a first threshold value, the second digital twin monomer and the first digital twin monomer are limited to interact; the behavior deviation degree is the deviation degree of the access behavior characteristics of the first digital twin monomer from a preset normal behavior characteristic;

[0073] If the behavior deviation degree is greater than the first threshold value, it is determined that the identity of the first digital twin monomer is abnormal.

[0074] In the present application, when the Shannon entropy value is an abnormal entropy value, the second digital twin monomer further analyzes the access behavior characteristics of the first digital twin monomer using a behavior analysis model. The access behavior characteristics include access to the alliance platform, access timestamp, operation type, and data volume. The behavior analysis model in the present application is a pre-trained model, and its training method can be implemented using existing technologies. After inputting the access behavior characteristics into the behavior analysis model, the behavior analysis model outputs the deviation degree from the historical baseline. If the deviation degree is less than or equal to 95%, the second digital twin monomer performs limited authorization and only authorizes part of the permissions. If the deviation degree is greater than 95%, the second digital twin monomer sends a message about the abnormal identity to the alliance platform.

[0075] In the present application, the behavior analysis model can use a spatio-temporal sequence anomaly detection model, such as LSTM-autoencoder, Isolation Forest, etc. The behavior analysis model can be obtained by training the LSTM network. Specifically, historical normal access behavior data (such as spatio-temporal sequence features such as user operation time, access resource type, operation frequency, and data interaction volume) are collected to construct a training data set. Key spatio-temporal sequence features are extracted to construct an input vector. The model is trained with normal behavior data to minimize reconstruction error, allowing the LSTM network to learn the temporal pattern of normal behavior. The parameters are iteratively optimized until the reconstruction error converges. The behavior analysis model sets a deviation threshold (such as the quantile of the reconstruction error corresponding to 95%), calculates the reconstruction error distribution of normal samples, and sets the 95% quantile as the critical value. If it exceeds, it is determined to be abnormal.

[0076] In the present application, when the second digital twin monomer detects that the Shannon entropy value of the random number submitted by the first digital twin monomer is abnormal, a deep verification process based on the behavior analysis model is triggered. By quantifying the deviation degree of the access behavior from the normal baseline, the interaction permissions are dynamically adjusted or the identity is determined to be abnormal, realizing the security upgrade from "static certificate verification" to "dynamic behavior risk control".

[0077] In some embodiments, in response to the identity abnormality of the first digital twin monomer, a dynamic trust evaluation is performed on the first digital twin monomer to obtain a new trust value.

[0078] If the new trust value is lower than a second threshold value, the dynamic certificate is revoked and the interaction request is rejected.

[0079] The first digital twin monomer is dynamically trust evaluated in the following way to obtain a new trust value,

[0080] Trust = a · (1 - β)

[0081] β = 0.6 × x + 0.4 × y

[0082] Wherein, a is the basic trust value, β is the abnormal behavior weight, x is the entropy value abnormal rate, and y is the behavior deviation degree.

[0083] In this application, the basic trust value can be set to 0.9, that is, the identity qualification audit result at the time of registration. The dynamic adjustment rule of the trust value in this application can be that for every 10,000 times of compliance interaction (no abnormal record), a increases by 0.01 (the upper limit is 1.0), which embodies the incentive logic of “accumulating trust for long-term compliance behavior”; if there is a major abnormality in the history (such as malicious attack record), a can be triggered to be punished and adjusted downward (such as directly reduced to 0.5).

[0084] When the trust value is lower than the second threshold value 0.6, the alliance platform triggers full-link automatic disposal, realizing the closed-loop response of “abnormal identification-risk isolation-full network defense”. Specifically as follows:

[0085] Certificate revocation and blacklist broadcast: the alliance platform calls the smart contract, marks the dynamic certificate as “revoked”, and generates a blacklist containing the certificate serial number, revocation time, and reason. Through the P2P network of the alliance blockchain, the blacklist is broadcast to all nodes to ensure that the whole network is synchronized within 10 seconds (based on the Byzantine fault tolerance algorithm to ensure consistency). Then the blockchain node is unregistered: trigger the “node unregistration” function of the blockchain smart contract to delete the identity mapping record of the first digital twin monomer in the distributed ledger ({Key:,...}); Synchronously clear the historical transaction permissions of the first digital twin monomer (such as prohibiting it from initiating cross-chain interaction requests), to prevent attacks using old data residues. Then resource permission recycling: the alliance platform sends permission recycling instructions to each related system (such as the energy network, traffic control platform, etc.), revoking the first digital twin monomer's access to the following resources, sensitive data (such as device control instructions, user privacy information), core function interfaces (such as “remote parameter modification” “system mode switching”), and alliance-level shared resource pools (such as computing power, storage nodes). Finally, safety alert push: the alert content includes: the identity of the abnormal first digital twin monomer, the physical location, the abnormal behavior characteristics (such as “entropy value abnormal rate 80% + behavior deviation degree 99%”), the risk level (such as “high risk”);

[0086] In some embodiments, in response to the Shannon entropy value being an abnormal entropy value, an alarm prompt is performed.

[0087] The alarm object can be the alliance security management center (triggering the manual review process); or the node that has historical interaction with the first digital twin monomer (reminding to check whether it is affected); or all alliance nodes (informing the risk source and improving the defense level).

[0088] In some embodiments, the signature verification of the dynamic certificate based on the interaction request comprises:

[0089] verifying a first layer signature; the first layer signature is a signature of the first digital twin monomer address by a private key of the first digital twin monomer;

[0090] verifying a second layer signature; the second layer signature is a signature of a random number by a randomly generated session private key;

[0091] verifying a third layer signature; the third layer signature is a signature of an identity of the first digital twin monomer by a randomly generated random number by a work private key.

[0092] In some embodiments, after the signature verification of the dynamic certificate based on the interaction request, the method further comprises:

[0093] in response to a failure of the signature verification, rejecting the interaction request of the first digital twin monomer.

[0094] In the present application, the first layer signature verification is identity authenticity verification, a signature of the address (such as a physical device unique identifier, a blockchain account address) of the first digital twin monomer by a long-term private key of the first digital twin monomer, that is, Sign_{SK_A1}(ID_A). Through verification, it can be confirmed that the holder of the certificate is indeed the first digital twin monomer himself, rather than an attacker who forges an identity. The verification process can be that the alliance platform extracts the address (ID_A) of the first digital twin monomer and the first layer signature result from the certificate; calls the public key (PK_A1, paired with the private key SK_A1) of the first digital twin monomer, and verifies the signature using an asymmetric encryption algorithm (such as ECDSA, RSA). If the verification is passed: it is proved that the signature is indeed generated by the private key of the first digital twin monomer, and the identity subject is legal; if the verification fails: directly determine that the certificate is illegal, and reject the interaction request.

[0095] The second layer signature verification is a signature of the exclusive random number (r) of this interaction by the randomly generated session private key (SK_A2), that is, Sign_{SK_A2}(r). Through verification, it can be confirmed that the timeliness of the certificate is prevented from being reused by an attacker (replay attack). The verification process can be that the alliance platform extracts the random number (r) and the second layer signature result from the certificate; calls the session public key (PK_A2, temporarily paired with the session private key SK_A2, generated with the session) to verify the signature. If the verification is passed: it is proved that the random number r is not tampered with, and is generated by this session; if the verification fails: it is determined that the certificate may be tampered with or reused, and the request is rejected.

[0096] The third layer signature verifies the working private key (SK_A3) of the first digital twin monomer based on the combination of the random number (r) and the identity (ID_A), that is, Sign_{SK_A3}(ID_A||r) (“||” represents string splicing). By verifying the binding relationship between the identity and the random number, it is ensured that the two have not been tampered with (such as an attacker replacing ID_A or r). The verification process can extract the combined information (ID_A||r) and the third layer signature result from the certificate for the alliance platform; and call the working public key (PK_A3, paired with the private key SK_A3, regularly updated) to verify the signature. If the verification is passed: it is proved that ID_A and r are binding information generated in the same interaction process and have not been tampered with; if the verification fails: it is determined that the certificate has been tampered with, and the request is rejected.

[0097] The dynamic certificate submitted by the first digital twin monomer in the application includes three independent signatures, and the alliance platform verifies the certificate legality from the identity authenticity, session timeliness, and interaction integrity to prevent replay attacks, identity forgery, and other risks. The verification process of the three layers of signatures is closely linked and indispensable.

[0098] In some embodiments, the signature verification of the dynamic certificate based on the interaction request further includes:

[0099] The permission of the first digital twin monomer is checked to determine whether the permission of the first digital twin monomer is within the authorized range of the second digital twin monomer.

[0100] In the application, the alliance platform needs to check whether the permission of the first digital twin monomer is within the authorized range of the second digital twin monomer based on the above model before forwarding the interaction request. The identity (ID_A) and device type of the first digital twin monomer are extracted from the dynamic certificate of the first digital twin monomer; if not in the white list: directly determine that the permission is insufficient, and reject the forwarding request; if in the white list: enter the next attribute verification. The interaction request content (such as “triggering the energy saving mode”) of the first digital twin monomer can also be parsed, and the “allowed operation” list of the second digital twin monomer is matched; if the request operation is within the “allowed operation” and meets the restriction condition (such as the frequency is not exceeded): it is determined that the permission is valid; if the request operation is within the “prohibited operation” (such as “modifying the power supply parameter”): it is determined that the permission is insufficient; if the request operation exceeds the “allowed operation” range (such as the first digital twin monomer requests “turning off the emergency lighting”): it is determined that the permission is insufficient.

[0101] By checking whether the permission of the first digital twin monomer is within the authorized range of the second digital twin monomer, the application can guarantee the security of resources and compliant interaction.

[0102] The identity mutual recognition method provided in the application realizes real-time linkage protection of "identity-behavior-trust" in a digital twin alliance through dynamic identity mapping, double-factor monitoring and closed-loop trust control links.

[0103] As shown in the drawings, Figure 3 The identity mutual recognition device provided in the application comprises:

[0104] The first obtaining module 301 is configured to obtain an interaction request and a dynamic certificate sent by a first digital twin monomer; the dynamic certificate is generated by signing a combination of a random number and an identity identifier of the first digital twin monomer with a working private key of the first digital twin monomer;

[0105] The signature verification module 302 is configured to perform signature verification on the dynamic certificate based on the interaction request;

[0106] The second obtaining module 303 is configured to, in response to successful signature verification, obtain a trust value of the first digital twin monomer stored in a blockchain;

[0107] The third obtaining module 304 is configured to send the interaction request, the dynamic certificate and the trust value to a second digital twin monomer, and obtain a Shannon entropy value of the random number returned by the second digital twin monomer;

[0108] The interaction establishing module 305 is configured to, in response to the Shannon entropy value being a normal entropy value, establish interaction between the second digital twin monomer and the first digital twin monomer.

[0109] The identity mutual recognition device provided in the application obtains an interaction request and a dynamic certificate sent by a first digital twin monomer through the first obtaining module 301; the dynamic certificate is generated by signing a combination of a random number and an identity identifier of the first digital twin monomer with a working private key of the first digital twin monomer; the signature verification module 302 performs signature verification on the dynamic certificate based on the interaction request; the second obtaining module 303 obtains a trust value of the first digital twin monomer stored in a blockchain in response to successful signature verification; the third obtaining module 304 sends the interaction request, the dynamic certificate and the trust value to a second digital twin monomer, and obtains a Shannon entropy value of the random number returned by the second digital twin monomer; and the interaction establishing module 305 establishes interaction between the second digital twin monomer and the first digital twin monomer in response to the Shannon entropy value being a normal entropy value.

[0110] It should be noted that the identity mutual recognition device of the embodiments of the application has similar principles to the identity mutual recognition method described above in solving problems, and therefore the implementation process and implementation principles, and the beneficial effects of the identity mutual recognition device can be referred to the descriptions of the implementation process and implementation principles, and the beneficial effects of the method described above, and the repeated parts will not be described herein.

[0111] An electronic device is provided, comprising:

[0112] at least one processor;

[0113] and a memory connected with the at least one processor in communication; wherein

[0114] The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method of any of the above embodiments.

[0115] A non-transitory computer readable storage medium storing computer instructions is provided, wherein the computer instructions are used to enable a computer to perform the method of any of the above embodiments.

[0116] According to the embodiments of the present application, the present application further provides an electronic device and a readable storage medium.

[0117] Figure 4 A schematic block diagram of an example electronic device that can be used to implement embodiments of the present application is shown. The electronic device is intended to represent various forms of digital computers, such as laptops, desktops, tablets, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular telephones, smartphones, wearable devices, and other similar computing devices. The components shown in the figure, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit implementations of the present application described and / or claimed in this document.

[0118] As Figure 4 shown, the device 800 includes a computing unit 801 that can perform various suitable actions and processes in accordance with computer programs stored in a read-only memory (ROM) 802 or loaded into a random access memory (RAM) 803 from a storage unit 808. Various programs and data required by the device 800 for operation can also be stored in the RAM 803. The computing unit 801, the ROM 802, and the RAM 803 are connected to each other via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0119] A plurality of components in the device 800 are connected to the I / O interface 805, including: an input unit 806, such as a keyboard, a mouse, etc.; an output unit 807, such as various types of displays, speakers, etc.; a storage unit 808, such as a magnetic disk, an optical disk, etc.; and a communication unit 809, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 809 allows the device 800 to exchange information / data with other devices through a computer network, such as the Internet, and / or various telecommunication networks.

[0120] The computing unit 801 can be various general and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The computing unit 801 performs various methods and processes described above, such as the identity cross-certificate method. For example, in some embodiments, the identity cross-certificate method can be implemented as a computer software program, which is tangibly embodied in a machine-readable medium, such as the storage unit 808. In some embodiments, part or all of the computer program can be loaded and / or installed onto the device 800 via the ROM 802 and / or the communication unit 809. When the computer program is loaded onto the RAM 803 and executed by the computing unit 801, one or more steps of the identity cross-certificate method described above can be performed. Alternatively, in other embodiments, the computing unit 801 can be configured to perform the identity cross-certificate method by any other appropriate means, such as by means of firmware.

[0121] Various implementations of the systems and techniques described above herein can be realized in digital electronic circuitry, integrated circuitry, a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a system on a chip (SOC), a complex programmable logic device (CPLD), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and / or interpretable on a programmable system including at least one programmable processor, which can be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

[0122] Program code for carrying out methods of the present application can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the program code, when executed by the processor or controller, produces a means for implementing the functions / acts specified in the flowcharts and / or block diagrams. The program code can be retrieved from a machine-readable medium or device and executed by a processor to produce a machine for implementing the functions / acts specified in the flowcharts and / or block diagrams. The program code can be executed as a stand-alone program, or in combination with other program codes, on the machine to produce a machine that implements the functions / acts specified in the flowcharts and / or block diagrams.

[0123] In the context of the present application, a machine-readable medium can be a tangible medium that can contain or store program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable storage media can include, without limitation, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media can include, but are not limited to, an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0124] To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input.

[0125] The systems and techniques described herein can be implemented in a computing system that includes a back end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front end component (e.g., a user computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described herein), or any combination of such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), and the Internet.

[0126] The computer system can include clients and servers. The clients and the servers are generally remote from each other and typically interact through a communication network. The relationship of client and server can arise by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The servers can be cloud servers, servers of a distributed system, or servers combined with a blockchain.

[0127] It should be understood that the steps shown in the above-mentioned various forms of flowcharts can be reordered, added, or deleted. For example, each step described in the present disclosure can be executed in parallel, sequentially, or in a different order, as long as the desired results of the technical solutions of the present application can be achieved, and the present disclosure is not limited herein.

[0128] In addition, the terms "first", "second" are only for descriptive purposes, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features. Therefore, the features defined with "first", "second" can explicitly or implicitly include at least one of the features. In the description of the present application, the meaning of "a plurality of" is two or more, unless otherwise specifically limited.

[0129] The above description is merely a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A method for mutual identity recognition, characterized in that, include: Obtain the interaction request and dynamic certificate sent by the first digital twin entity; The dynamic certificate is generated by signing a combination of a random number and the identity identifier of the first digital twin using the working private key of the first digital twin entity. The dynamic certificate is signed and verified based on the interaction request. In response to successful signature verification, obtain the current trust value of the first digital twin stored in the blockchain; The interaction request, dynamic certificate, and current trust value are sent to the second digital twin entity to obtain the Shannon entropy value of the random number returned by the second digital twin entity. In response to the Shannon entropy value being a normal entropy value, the second digital twin entity establishes an interaction with the first digital twin entity.

2. The method according to claim 1, characterized in that, Also includes: In response to the Shannon entropy value being an abnormal entropy value, the second digital twin instance uses a behavioral analysis model to analyze the access behavior characteristics of the first digital twin instance; Based on the access behavior characteristics, the degree of behavior deviation is determined; If the deviation of the behavior is less than or equal to the first threshold, then the interaction between the second digital twin and the first digital twin is restricted. The behavioral deviation is the degree of deviation between the access behavior characteristics of the first digital twin and the preset normal behavioral characteristics; If the deviation of the behavior is greater than the first threshold, then the identity of the first digital twin is determined to be abnormal.

3. The method according to claim 2, characterized in that, In response to the anomaly in the identity of the first digital twin, a dynamic trust assessment is performed on the first digital twin to obtain a new trust value; If the new trust value is lower than the second threshold, the dynamic certificate is revoked and the interaction request is rejected.

4. The method according to claim 3, characterized in that, The first digital twin is dynamically trusted using the following method to obtain a new trust value. Trust = α·(1-β) β = 0.6 × x + 0.4 × y Where α is the base trust value, β is the abnormal behavior weight, x is the entropy abnormality rate, and y is the behavior deviation degree.

5. The method according to claim 1, characterized in that, The signature verification of the dynamic certificate based on the interaction request includes: Verify the first-level signature; the first-level signature is the signature of the private key of the first digital twin instance on the address of the first digital twin instance; Verify the second-level signature; the second-level signature is a signature of a random number on a randomly generated session private key; Verify the third-layer signature; the third-layer signature is the signature of the identity identifier of the first digital twin based on a randomly generated random number by the working private key.

6. The method according to claim 5, characterized in that, The signature verification of the dynamic certificate based on the interaction request also includes: Verify the permissions of the first digital twin entity to determine whether the permissions of the first digital twin entity are within the authorization scope of the second digital twin entity.

7. The method according to claim 5, characterized in that, After performing signature verification on the dynamic certificate based on the interaction request, the process further includes: In response to signature verification failure, the interaction request of the first digital twin is rejected.

8. The method according to claim 2, characterized in that, An alarm is triggered in response to the Shannon entropy value being an abnormal entropy value.

9. An identity verification device, characterized in that, include: The first acquisition module is used to acquire the interaction request and dynamic certificate sent by the first digital twin entity; The dynamic certificate is generated by signing a combination of a random number and the identity identifier of the first digital twin using the working private key of the first digital twin entity. A signature verification module is used to perform signature verification on the dynamic certificate based on the interaction request; The second acquisition module is used to acquire the trust value of the first digital twin stored in the blockchain in response to successful signature verification. The third acquisition module is used to send the interaction request, dynamic certificate and trust value to the second digital twin entity to obtain the Shannon entropy value of the random number returned by the second digital twin entity. An interaction establishment module is used to establish an interaction between the second digital twin and the first digital twin in response to the Shannon entropy value being a normal entropy value.

10. An electronic device, characterized in that, include: At least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-8.

Images