Identity authentication and control method and device based on block chain

Abstract

The invention discloses an identity authentication and control method and device based on a block chain. According to the method, biological features are collected through edge nodes to generate feature vectors, a combined hash value is generated in combination with a device scene label and a service role label, the combined hash value is uploaded to a cloud server after encrypted signature, and the combined hash value is written into a block chain through an intelligent contract; and during user authentication, the edge node calculates a real-time risk level, dynamically selects an authentication mode, calls an intelligent contract for verification after verification of the cloud server, and adjusts the risk level according to a verification result to implement management and control. According to the method, the edge cloud collaborative architecture is adopted, and the dynamic multi-factor authentication mechanism and the block chain consensus technology are combined, so that high-security privacy protection authentication is realized, the security requirements of different service scenes can be met, data leakage and replay attacks are effectively prevented, and the authentication efficiency and reliability are improved.

Description

Technical Field

[0001] The present invention relates to the field of network security technology, and in particular to a blockchain-based identity authentication and management method and device, as well as a storage medium and electronic device. Background Art

[0002] In the field of network security, identity authentication is a core component of access control. Existing solutions primarily utilize centralized authentication solutions and blockchain-based decentralized authentication solutions. Centralized authentication solutions rely on central servers to store sensitive information such as user biometrics, account numbers, and passwords. Authentication is achieved through usernames and passwords or a single biometric. As a single trusted node, the central server faces the risk of data tampering and leakage, and its static authentication strategy also offers low security.

[0003] In addition, although blockchain-based authentication solutions solve the risks of centralized storage through distributed ledgers, the single on-chain processing model has efficiency bottlenecks. Moreover, its method of directly uploading biometric plaintext or hash values ​​to the chain fails to effectively protect private data and poses a risk of data leakage. It is also unable to dynamically adapt to the security needs of different business scenarios. Summary of the Invention

[0004] The purpose of the present invention is to overcome the shortcomings of the existing technology and provide a blockchain-based identity authentication and management method. The technical solution adopted in this application is:

[0005] In a first aspect, the present invention provides a blockchain-based identity authentication and management method, comprising: S1, collecting user information and registering on a cloud server;

[0006] In step S2, the edge node collects the user's biometrics to generate a feature vector F, obtains the device scenario label S, assigns a business role label R based on the user's selection, and generates a hash value. The hash value includes the biometric hash value and the combined hash value of the device scenario label and the business role label. The hash value is encrypted and signed and uploaded to the cloud server. After verification by the cloud server, it is written to the blockchain through a smart contract. In step S3, the user initiates authentication, the edge node obtains the business role label R and the device scenario label S, calculates the real-time risk level L, and determines the QBFT consensus mechanism and authentication method based on the real-time risk level L and the preset policy. The QBFT consensus mechanism is used to generate a dynamic verification code. The authentication methods include single-factor and two-factor authentication.

[0007] S4: If it is determined to be single-factor authentication, the edge node performs a hash calculation on the user's biometric information to obtain a hash value, encrypts and signs it, and then uploads it to the cloud server. If it is determined to be two-factor authentication, the edge node concatenates the user's biometric hash value, the combined hash value, and the dynamic verification code, encrypts and signs it, and then uploads it to the cloud server.

[0008] S5: After verification, the cloud server sends the hash value to the smart contract on the blockchain. The smart contract obtains the corresponding hash value from the blockchain for verification. If the verification is successful, the smart contract returns a successful authentication result. If the verification fails, the smart contract returns an authentication failure and prompts the user to re-authenticate.

[0009] S6: The user re-authenticates according to the prompts. If the number of consecutive failures reaches the set threshold, the user's risk level L is adjusted and the user is managed.

[0010] Optionally, in the above-mentioned method embodiments of the present invention, the dynamic verification code generation specifically includes: after receiving the verification request, selecting the number of consensus nodes according to the risk level, selecting N consensus nodes to participate in the dynamic verification code generation process, each consensus node uses a local random number generation algorithm to independently generate a random integer, which is a fragment of the dynamic verification code, and sends the fragment to the master node through a secure channel. After the master node collects at least 2N / 3+1 valid fragments, it performs aggregation calculation on these fragments to obtain the final dynamic verification code.

[0011] Optionally, in the above-mentioned method embodiments of the present invention, the edge node collects biometric features to generate a feature vector F specifically by: collecting biometric data through a fingerprint sensor or an iris recognition module, graying, binarizing, and refining the fingerprint data, and then extracting feature points to generate a 128-byte feature vector.

[0012] Optionally, in the above-mentioned method embodiments of the present invention, the edge node collects biometric features to generate the feature vector F by performing pupil positioning and normalization processing on the iris data and then using a feature encoding algorithm to generate a 256-byte feature vector.

[0013] Optionally, in the above-mentioned method embodiments of the present invention, the real-time risk level is calculated by a weighted algorithm based on the user's historical authentication records, the geographic location in the device scenario tag, the network type, and the request time.

[0014] Optionally, in the above-mentioned method embodiments of the present invention, the user management and control includes: if the risk level L ≥ 60 points, forcing subsequent authentication to adopt a two-factor mode; if L ≥ 80 points, temporarily freezing non-emergency business permissions; if L ≥ 90 points, triggering account locking and requiring manual review to unlock.

[0015] Optionally, in the above-mentioned method embodiments of the present invention, the cloud server's verification of the dynamic verification code includes: checking whether the difference between the dynamic verification code generation timestamp and the current time is within 1 minute, verifying whether the Merkle tree root value of the consensus node signature participating in the shard generation is aggregated by at least 2N / 3+1 node signatures, and confirming that the dynamic verification code format complies with preset rules.

[0016] Optionally, in the above-mentioned method embodiments of the present invention, the verification process of the smart contract is specifically as follows: extracting the feature codes of the biometric features F and F' from the registered hash value H(EI) and the current hash value respectively, performing a secondary hash calculation on the feature codes to generate feature hash fragments, and comparing whether the two are consistent. If they are consistent, the verification is passed.

[0017] In a second aspect, the present invention provides a blockchain-based identity authentication and management device, comprising:

[0018] User registration module, used to collect user information and register on the cloud server;

[0019] An information generation module is used to collect biometric features to generate a feature vector F, obtain a device scenario tag S, assign a business role tag R based on the user's selection, generate a hash value that includes the biometric hash value and a combined hash value of the device scenario tag and the business role tag, encrypt and sign the hash value, and upload it to the cloud server.

[0020] The verification storage module is used to decrypt and verify the uploaded data and write the hash value into the blockchain through the smart contract;

[0021] The authentication module is used to obtain the business role label R and the device scenario label S at the edge node when the user initiates authentication, calculate the real-time risk level L, and determine the QBFT consensus mechanism and authentication method based on the real-time risk level L and the preset policy. The QBFT consensus mechanism is used to generate a dynamic verification code. The authentication method includes single-factor and two-factor authentication.

[0022] The hash processing module is used to calculate the user's biometric information to obtain a hash value when it is determined to be single-factor authentication. The edge node encrypts and signs the hash value before uploading it to the cloud server. When it is determined to be two-factor authentication, the edge node concatenates the user's biometric hash value, the combined hash value, and the dynamic verification code, encrypts and signs the hash value, and uploads it to the cloud server.

[0023] The verification module includes a cloud server verification submodule and a blockchain smart contract submodule. The cloud server verification submodule is used to verify the received data and send the hash value to the smart contract submodule on the blockchain. The blockchain smart contract submodule is used to obtain the corresponding hash value from the blockchain for verification. If the verification passes, the result of authentication success is returned; if the verification fails, the result of authentication failure is returned.

[0024] The risk management module is used to receive the authentication failure prompt returned by the smart contract verification module, record the number of failed re-authentication operations by the user, and adjust the user's risk level L if the number of consecutive failures reaches the set threshold, and control the user.

[0025] In a third aspect, the present invention provides an electronic device, comprising: a memory and a processor, wherein the memory and the processor are coupled; the memory stores program instructions, and when the program instructions are executed by the processor, the electronic device executes any of the methods described in the above embodiments.

[0026] In a fourth aspect, the present invention provides a computer-readable storage medium, comprising a computer program. When the computer program is run on an electronic device, the electronic device executes any of the methods described in the above embodiments.

[0027] Through the above technical solution, compared with the existing technology, the present invention has the following beneficial effects: the present invention can significantly improve the security of identity authentication and the accuracy of risk control through the dynamic multi-factor authentication system and blockchain consensus mechanism. The dynamic verification code mechanism generated based on QBFT consensus, combined with multi-dimensional authentication of biometrics and scene labels, can reduce the risk of identity impersonation and realize dynamic adjustment of authentication strength. The blockchain architecture ensures data consistency in a distributed environment. The full-process encryption and hash comparison mechanism can ensure data integrity. The edge cloud architecture can achieve a balance between security and user experience, reduce authentication delay, and improve authentication efficiency.

[0028] The technical solution of the present invention is further described in detail below through the accompanying drawings and embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The above and other objects, features and advantages of the present invention will become more apparent through the following description of the embodiments of the present invention with reference to the accompanying drawings, in which:

[0030] Figure 1 This is a flowchart of a blockchain-based identity authentication and management method provided by an exemplary embodiment of the present invention.

[0031] Figure 2 It is a structural diagram of a blockchain-based identity authentication and control device provided by an exemplary embodiment of the present invention. DETAILED DESCRIPTION

[0032] The present application is described below based on the following embodiments, but the present application is not limited to these embodiments. In the detailed description of the present application below, certain specific details are described in detail. Those skilled in the art can fully understand the present application without the description of these details. To avoid obscuring the essence of the present application, well-known methods, processes, procedures, components, and circuits are not described in detail.

[0033] Furthermore, persons of ordinary skill in the art will appreciate that the figures provided herein are for illustration purposes only and are not necessarily drawn to scale.

[0034] At the same time, it should be understood that in the following description, "circuit" refers to a conductive loop composed of at least one element or subcircuit connected electrically or electromagnetically. When an element or circuit is said to be "connected to" another element or an element / circuit is said to be "connected" between two nodes, it can be directly coupled or connected to the other element or there can be intermediate elements. The connection between the elements can be physical, logical, or a combination thereof. Conversely, when an element is said to be "directly coupled to" or "directly connected to" another element, it means that there are no intermediate elements between the two.

[0035] Unless the context clearly requires otherwise, words like “include”, “comprising” and the like throughout this application should be interpreted as including rather than exclusive or exhaustive; that is, as meaning “including but not limited to”.

[0036] In the description of this application, it should be understood that the terms "first", "second", etc. are used for descriptive purposes only and should not be understood to indicate or imply relative importance. In addition, in the description of this application, unless otherwise specified, "plurality" means two or more.

[0037] Below, the exemplary embodiments according to the present invention will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all the embodiments of the present invention, and it should be understood that the present invention is not limited to the exemplary embodiments described herein.

[0038] It should be noted that the relative arrangement of components and steps, the numerical expressions and numerical values ​​set forth in these embodiments do not limit the scope of the present invention unless specifically stated otherwise.

[0039] Those skilled in the art will understand that the terms "first" and "second" in the embodiments of the present invention are only used to distinguish different steps, devices or modules, and neither represent any specific technical meaning nor indicate the necessary logical order between them.

[0040] It should also be understood that, in the embodiments of the present invention, “a plurality of” may refer to two or more than two, and “at least one” may refer to one, two or more than two.

[0041] It should also be understood that any component, data or structure mentioned in the embodiments of the present invention can generally be understood as one or more, unless explicitly limited or otherwise indicated in the context.

[0042] This invention achieves highly secure and privacy-preserving authentication through edge-cloud collaboration, dynamically adapting to the security requirements of different business scenarios, effectively preventing data leakage and replay attacks, and improving authentication efficiency and reliability. The system architecture of this invention consists of four parts: edge nodes, blockchain network, cloud server, and user terminal.

[0043] Edge nodes are deployed at the edge of the network near user terminals. They are equipped with biometric data collection interfaces, support communication protocols such as USB and Bluetooth, and can connect to devices such as fingerprint readers and iris scanners. The software comes pre-installed with OpenSSL 3.0 for encryption, a Python 3.9 runtime environment, and a FIDO2-compliant biometric SDK.

[0044] Blockchain network: This can be a private consortium blockchain built on Ethereum 2.0 or other blockchain network architectures. The blockchain network comprises master nodes, validation nodes, and consensus nodes. Consensus nodes refer to all nodes participating in the blockchain consensus process. In this invention, the number of consensus nodes, N, is dynamically adjusted based on risk level (e.g., N = 5 for low risk, N = 9 for high risk). These nodes jointly participate in the generation of dynamic verification code shards and consensus verification, and are core participants in the blockchain consensus mechanism. Validation nodes are a specific implementation of consensus nodes, referring to the N pre-deployed nodes in the blockchain network, responsible for generating blocks and verifying transactions. Validation nodes are a subset of consensus nodes, and all validation nodes are considered consensus nodes. Master nodes are dynamically selected consensus nodes from the validation node pool and coordinate, responsible for aggregating dynamic verification code shards and controlling the consensus process. Master nodes are both validation nodes and part of the consensus nodes, temporarily coordinating the consensus process.

[0045] Cloud Server: A core component that can run a Java-based registration service program for a redundant server group and support key management and signature verification for multiple encryption algorithms.

[0046] User terminal: such as smartphones not limited to Hongmeng, Android or iOS systems, with biometric data collection functions such as fingerprint recognition and iris recognition, support for network communication functions, and support for communication modules of encryption protocols.

[0047] Furthermore, user terminals (such as mobile phones and smart terminals) establish connections with edge nodes via USB, Bluetooth, or local API interfaces to transmit raw biometric data such as fingerprints and iris images. Data is transmitted over an encrypted channel between the edge node and the terminal to ensure the privacy of the biometric data during local processing. The edge node uploads the processed hash value and dynamic verification code to the cloud server. The transmission protocol uses AES-256-GCM encryption and the ECDHE algorithm for key negotiation. At the same time, the cloud server sends parameters such as the authentication policy and the number of consensus nodes N to the edge node to control the local authentication process.

[0048] The cloud server calls the authentication contract deployed on the blockchain through the blockchain node API, passing in parameters such as the decrypted hash value and user identity, triggering the on-chain verification logic. At the same time, it synchronizes data such as the hash value of the user during registration from the blockchain node for local pre-verification.

[0049] In the blockchain network, the master node is responsible for the aggregation and consensus coordination of dynamic verification code shards. It dynamically selects nodes from the verification node pool based on the risk level L. The verification nodes are distributed in the network and generate dynamic verification code shards based on random seeds and block heights. The master node and the verification node transmit shard data through a P2P encrypted channel, using ECDSA signatures to ensure the legitimacy of the message source. When a 2N / 3+1 node message is received, it confirms that a consensus has been reached.

[0050] The user terminal obtains the encrypted dynamic verification code through the cloud server, decrypts it with the private key and participates in the authentication process. The dynamic verification code verification result of the cloud server is uploaded to the smart contract through the chain. The smart contract returns the authentication result (true / false) to the cloud server, and then the cloud server pushes it to the terminal to ensure the integrity and traceability of the authentication process.

[0051] Example 1, as Figure 1 As shown, this embodiment provides a blockchain-based identity authentication and management method, including: S1 collecting user information and registering on a cloud server;

[0052] The user accesses the registration interface through a terminal device and fills in basic identity information on the registration interface, including but not limited to username, password, email address, and mobile phone number. The system sends a text message verification code to the mobile phone number entered by the user. The user fills in the received text message verification code on the registration interface for verification to confirm the authenticity of the mobile phone number. After completing the basic information verification, the edge node guides the user to prepare for biometric collection, prompting the user to place their finger on the fingerprint recognition module or adjust the position of their face to align with the camera for iris image capture. At the same time, information such as the terminal device type and operating system is obtained to generate the initial information of the device scenario label S. The business role label R is then assigned based on the business type selected by the user, such as ordinary user, cross-border trader, etc.

[0053] The S2 edge node collects the user's biometrics to generate a feature vector F, obtains the device scenario tag S, assigns a business role tag R based on the user's selection, and generates a hash value. The hash value includes the biometric hash value and the combined hash value of the device scenario tag and the business role tag. The hash value is encrypted and signed and uploaded to the cloud server. After verification by the cloud server, it is written to the blockchain through a smart contract.

[0054] Furthermore, the edge node collects fingerprint data through a fingerprint sensor or iris recognition module to collect iris biometric data, or collects facial data, voiceprint and other data through tools. The processing of fingerprints and irises is used as an example below.

[0055] Among them, the fingerprint data is preprocessed, the fingerprint color image is converted into a grayscale image, the grayscale image is converted into a black and white binary image, the fingerprint lines are thinned to a single pixel width, and then the feature points are extracted to finally generate a 128-byte feature vector F.

[0056] The iris data is preprocessed to locate the pupil position first, then normalized, and finally a 256-byte feature vector F is generated using a feature encoding algorithm.

[0057] The eigenvector is F=[f,f2,...,f n ], n = 128 or 256, each element is an 8-bit unsigned integer.

[0058] Furthermore, the device scene tag is generated as follows:

[0059] Hardware information includes but is not limited to: device model (such as iPhone14Pro), operating system version (iOS16.4), and CPU model (A16).

[0060] Network information includes but is not limited to: IP address geographic location, network type (5G / WiFi), and network service provider (China Mobile).

[0061] Environmental information includes but is not limited to: current timestamp, GPS coordinates, light intensity obtained by the ambient light sensor, etc.

[0062] The above information is combined into a device scenario tag S according to a preset format such as JSON format.

[0063] Label format: S = {hardware:[h1,h2],network:[n1,n2],environment:[e1,e2]}.

[0064] Furthermore, the steps for generating the business role label R are as follows:

[0065] Based on the business type selected by the user during registration, such as "Ordinary User", "Cross-border Trader", and "Administrator", the corresponding permission set is assigned from the predefined role library.

[0066] The role permission mapping table is as follows:

[0067] Character R Permission Sets Ordinary users Product browsing, ordering, and payment Cross-border traders Cross-border payment, international logistics tracking, foreign exchange inquiry administrator User management, system configuration, transaction audit

[0068] Furthermore, the hash value includes a biometric hash value H(F) and a combined hash value H(S, R). The biometric hash value H(F) is generated as follows using a 128-dimensional example:

[0069] Step 1.1: Feature Vector Standardization Perform standardization on the 128-dimensional biometric feature vector F: convert the floating-point data into 32-bit binary format according to the IEEE 754 standard, arrange them in big-endian byte order to ensure cross-platform consistency, and output a 512-byte raw data block;

[0070] Step 1.2: Segment hash calculation, divide the 512 sections into the front and back segments, each 256 bytes.

[0071] For the front-end processing: extract the first 256 bytes of data and apply the SHA-256 algorithm to generate the intermediate hash value H1, with a fixed output length of 32 bytes;

[0072] For post-processing: extract the remaining 256 bytes of data, apply the SHA3-512 algorithm to generate a 64-byte hash, and intercept the first 32 bytes as the intermediate hash value H2;

[0073] Step 1.3: Final hash synthesis: concatenate H1 and H2 in sequence, apply the SHA-256 algorithm to the concatenation result again, and output the final 32-byte biometric hash value H(F).

[0074] The example for generating the combined hash value H(S,R) is as follows:

[0075] Step 2.1: Serialize the scene tag. Convert the device scene tag S into a normalized JSON string. Arrange the fields in lexicographical order by key name, remove all whitespace characters, and use UTF-8 encoding.

[0076] Step 2.2: Role label encoding: Map the business role label R to a 2-byte unsigned integer: for example, ordinary user: 0x0001, administrator: 0x0100, super user: 0xFF00, and store in big-endian byte order;

[0077] Step 2.3: Salted hash operation to construct the input message: concatenate the serialized scene string with the character encoding bytes;

[0078] Example: utf8_encode(S_json)||R_bytes

[0079] Perform hash calculation: Set the output length to 32 bytes and use a preset threshold, such as "Scene-Role-Binding-Salt-0xFAST", to perform keyed hashing to generate a 32-byte scene-role combination hash value H(S,R).

[0080] After the hash value is generated, the AES-256 encryption algorithm is used to encrypt the hash value using the encryption key K_F and a randomly generated 16-byte initialization vector (IV). Before encryption, the hash value is padded to make its length an integer multiple of 16 bytes.

[0081] After encryption, the ciphertext ciphertext and initialization vector IV are generated, which are combined into the encryption result EI = (ciphertext, IV), where ciphertext is the encrypted I and iv is the initialization vector. Then, the user uses the private key generated based on the elliptic curve digital signature algorithm (ECDSA) to sign the encryption result EI to generate a digital signature signature.

[0082] The edge node packages the encrypted result EI, the digital signature, the user's ECDSA public key (public_key) used to verify the signature, and the generated timestamp into an upload data packet. The upload data structure is (EI, signature, public_key, timestamp), where EI is the encrypted value; signature is the user's private key's signature on EI; public_key is the user's ECDSA public key (used to verify the signature); and timestamp is the generated timestamp to prevent replay attacks. The uploaded data packet is sent to the cloud server via a secure communication channel.

[0083] Furthermore, the cloud server verification process is as follows:

[0084] The cloud server uses the user's ECDSA public key to verify the digital signature to confirm whether it is generated by the corresponding private key pair EI.

[0085] Check the difference between the timestamp in the uploaded data packet and the current server time to ensure that it is within the preset time window to prevent replay attacks.

[0086] The cloud server decrypts the encrypted result and obtains the hash value.

[0087] Furthermore, the blockchain evidence is as follows:

[0088] The cloud server calls the smart contract deployed on the blockchain and passes the user's Ethereum address, hash value, business role label R, and device scenario label S as parameters to the smart contract. The hash value includes the biometric hash value and the combined hash value of the device scenario label and the business role label.

[0089] After the smart contract verifies the validity of the timestamp, it stores this information on the blockchain and establishes a mapping between the user address and identity information.

[0090] Furthermore, the cloud server optionally calls a smart contract deployed on the blockchain and passes the user's Ethereum address (ethAddress), hash value, business role tag R, device scenario tag S, and timestamp (timestamp) as parameters to the smart contract. The smart contract creates and maintains the userIdentity table on the blockchain. The table structure is as follows:

[0091] structUserIdentity{

[0092] addressethAddress; / / User Ethereum address

[0093] bytes32hashF; / / biometric information hash value

[0094] bytes32hash(S,R); / / combined information hash value

[0095] stringroleTag; / / Business role tag R

[0096] stringsceneTag; / / device scene tag S

[0097] uint256registerTime; / / registration timestamp} mapping(address=>UserIdentity)userIdentityTable;

[0098] The smart contract completes data writing through userIdentityTable[ethAddress]=UserIdentity(ethAddress,has h,roleTag,sceneTag,timestamp), and establishes a unique index through the Ethereum address to ensure that the registration hash value can be quickly queried through userIdentityTable[userId] later.

[0099] The S3 user initiates authentication. The edge node obtains the business role label R and the device scenario label S, calculates the real-time risk level L, and determines the QBFT consensus mechanism and authentication method based on the real-time risk level L and the preset policy. The QBFT consensus mechanism is used to generate a dynamic verification code. The authentication methods include single-factor and two-factor authentication.

[0100] Among them, QBFT stands for Quick Byzantine Fault Tolerance, which is a fast Byzantine fault-tolerant consensus mechanism. It is a consensus mechanism unique to the Hyperledger Besu blockchain client and was developed by the Hyperledger Besu team to improve the efficiency and performance of the Byzantine fault-tolerant algorithm. There are multiple node roles in QBFT, including proposers, validators, and observers. Proposers are responsible for generating new blocks and broadcasting them to validators; validators verify and vote on blocks; observers do not participate in the consensus process but can receive the finalized blocks.

[0101] The QBFT consensus process consists of three main phases: pre-prepare, prepare, and commit. After a proposer generates a new block, they send a pre-prepare message to the validator. Upon receiving the message, the validator verifies and broadcasts the prepare message. Once the validator has received enough prepare messages, the commit phase begins, broadcasting the commit message and finalizing the block. Unlike PBFT, QBFT introduces a coordinator role to collect and aggregate validator votes, reducing the number of message transmissions. Based on this, the present invention adopts the QBFT consensus mechanism.

[0102] Furthermore, the edge node receives an authentication request initiated by the user through the terminal device. The request contains user identification such as user name, Ethereum address, and authentication context information such as request time, request IP, request service type, etc.

[0103] The edge node queries the user's corresponding on-chain identity record through the blockchain interface and obtains: business role label R: such as "ordinary user", "cross-border trader", etc.; device scenario label S: including hardware information, network information, environmental information, etc.; historical authentication records: such as the most recent authentication time, authentication results, historical changes in risk level, etc.

[0104] Furthermore, the real-time risk level L calculation involves first collecting multi-dimensional risk factors: Behavioral risk: Counting the number of authentication failures in the past hour, abnormal request frequency, etc. Environmental risk: Checking the difference between the requesting IP location and historical location, changes in network type, changes in device fingerprints, etc.

[0105] Time risk: Determine whether the current time is in a high-risk period (such as 0:00-6:00 in the morning).

[0106] Risk value calculation model: PL = w1×F1+w2×F2+...+w n ×F n +B

[0107] Among them: F1-F n Quantify the value of each risk factor;

[0108] w1-w n The weight of each factor, for example, behavioral risk weight is 0.4, environmental risk weight is 0.35, and time risk weight is 0.25;

[0109] B is the base risk value, with a default value of 30 for the first certification. Ultimately, the dynamic risk level L is calculated by weighted accumulation of various factors and superimposing them on the base value, providing data support for subsequent certification strategy matching.

[0110] Then the risk level mapping is carried out, where the risk levels are divided into low risk, medium risk and high risk:

[0111] Risk value range Risk Level L 0-30 Low risk 31-60 Medium risk 61-100 High risk

[0112] Furthermore, a preset strategy is matched. According to the values ​​of the current business role label R, device scenario label S, and real-time risk level L, the corresponding consensus node number N and authentication method are matched from the preset strategy table. Specifically, the cloud server calls the blockchain smart contract interface based on the real-time risk level L uploaded by the edge node to trigger the QBFT consensus mechanism. N nodes are dynamically selected from the blockchain verification node pool to form a consensus group. For example, when the risk is low, single-factor authentication is used and no consensus verification is required. When the risk is medium, two-factor authentication is used and 5 verification nodes are selected. When the risk is high, two-factor authentication is used and 9 verification nodes with the highest reputation values ​​are selected. At the same time, consensus parameters are configured to enhance the randomness of subsequent dynamic verification code generation.

[0113] Furthermore, the number of QBFT consensus nodes is dynamically adjusted based on the real-time risk level L: when L30, 5-node consensus (1-node fault tolerance) is enabled, and when L≥60, 9-node consensus (2-node fault tolerance) is adopted. Nodes are selected from the pre-deployed pool of 9 verification nodes, and the master node is determined by the current block height modulo N. The consensus node transmits shard data through an encrypted channel, and the message contains the shard value, node identifier, block height, and ECDSA signature. The master node broadcasts a request to generate the block height, and each node performs a hash operation based on the seed, block height, and its own identifier, and converts the result into a 32-byte shard value; after the master node collects no less than 2N / 3+1 valid shards, it calculates the final dynamic verification code by summing modulo 2^1024, and then encrypts the dynamic verification code with the user's public key and sends it to the user terminal through a secure channel;

[0114] During authentication, the edge node retrieves a dynamic verification code from the cloud server, generated by invoking a smart contract based on risk level L. After receiving the encrypted dynamic verification code, the user terminal decrypts it using its local private key to obtain the plaintext dynamic verification code string for validation. After verification is complete, the user terminal feeds the verification result back to the edge node for further processing. After receiving verification confirmation, the edge node recollects the biometrics to generate F', reconstructs the hash value based on the real-time device scenario label S' and the on-chain role label R, and concatenates the reconstructed hash value with the UTF-8 encoded byte stream of the dynamic verification code to form the data block D to be verified.

[0115] Specifically, when the dynamic verification code is generated, the cloud server calls the smart contract interface to select a consensus node based on the risk level L to generate a dynamic verification code. After the cloud server receives the spliced ​​data uploaded by the edge node, when verifying the dynamic verification code, the cloud server verifies the validity of the timestamp and the Merkle tree signature aggregation result. The cloud server aggregates at least 2N / 3+1 node signatures through the Merkle tree and verifies the validity of the ECDSA signature. The dynamic verification code is accompanied by a timestamp with a validity period of 1 minute.

[0116] Furthermore, the authentication method decision rule is that when the risk level L≤30 and the device scenario S is a trusted environment, only the biometric F is verified; when the risk level L>30 or the device scenario S is an untrusted environment, both the biometric F and the dynamic verification code are verified.

[0117] Authentication policy table:

[0118] Business Role R Device Scenario S Risk Level L Number of consensus nodes N Authentication method Ordinary users Home WiFi Low risk 0 nodes Single factor Ordinary users Public WiFi Medium risk 5 nodes Two-factor Cross-border traders Any network High risk 9 nodes Two-factor administrator Untrusted devices High risk 9 nodes Multifactor

[0119] S4 When it is determined to be single-factor authentication, the edge node performs hash calculation on the user's biometric information to obtain a hash value, encrypts and signs it, and then uploads it to the cloud server; when it is determined to be two-factor authentication, the edge node concatenates the user's biometric hash value, the combined hash value, and the dynamic verification code, encrypts and signs it, and then uploads it to the cloud server;

[0120] Furthermore, the edge node receives the authentication method determined in step S3, single-factor or dual-factor, and related parameters. If it is single-factor authentication, it only needs to prepare biometric data: a) collect raw feature data in real time through the biosensor; b) perform the same preprocessing process as the registration stage; c) generate a standardized feature vector F';

[0121] If it is two-factor authentication, you need to prepare both biometric F and dynamic verification code.

[0122] After receiving the authentication mode, the edge node then reconstructs the hash value information and re-collects the user's biometric data through the biometric sensor; at the same time, it re-acquires the current device hardware information, network information, and environmental information, and combines them into a new device scenario label S' in the JSON format defined by S2, and extracts the business role label R from the on-chain information obtained from S3, regenerates the biometric hash and the combined hash from F', R, and S', where the role label R at the time of user registration is obtained from the blockchain smart contract query.

[0123] Furthermore, for two-factor authentication, the user terminal uses the private key to decrypt the encrypted dynamic verification code obtained from the server and verify its validity, checking whether the format of the dynamic verification code complies with the preset rules and whether the difference between the generated timestamp and the current time is within the validity period.

[0124] After completing the above processing, the edge node performs hash calculation and generates a hash value for the biometric information in single-factor authentication; for two-factor authentication, the hash value is concatenated with the UTF-8 encoded byte stream of the dynamic verification code string, encrypted, and signed to ensure the security and verifiability of the authentication data.

[0125] After the S5 cloud server verifies the uploaded data, it sends the hash value in the uploaded data to the smart contract on the blockchain. The smart contract obtains the corresponding hash value from the blockchain for verification. If the verification is successful, it returns a successful authentication result; if the verification fails, it returns an authentication failure and prompts the user to re-authenticate.

[0126] Among them, the user terminal first obtains the RSA public key of the cloud server, and uses the encryption algorithm to encrypt the hash value or splicing value calculated in step S4 to obtain the encrypted hash value. The specific encryption process is not limited and can be consistent with the previous text, or other commonly used encryption methods in the encryption field can be used.

[0127] Optionally, the edge node can also perform ECDSA signature operation on the encrypted hash value to generate a signature value. Finally, the encrypted hash value, digital signature, user identity such as Ethereum address and timestamp are encapsulated in JSON format and sent to the cloud server through the TLS1.3 encrypted channel.

[0128] After receiving the data packet, the cloud server first verifies the validity of the TLS certificate and uses the user's ECDSA public key to decrypt the encrypted hash value to obtain the original hash value or concatenation value. Using the user's identity, the corresponding ECDSA public key is obtained from the local database. The encrypted hash value and / or concatenation value are decrypted and the signature is verified to confirm that the data has not been tampered with. The difference between the data packet timestamp and the current server time is checked to ensure that it is within the validity period. Finally, the original hash value and / or concatenation value are restored, which includes the encoded hash value serialized byte stream and the dynamic verification code string.

[0129] Furthermore, when two-factor authentication is used, the verification process for the dynamic verification code in the concatenated value is as follows:

[0130] 1. First check the generation timestamp carried by the dynamic verification code to confirm that the difference between it and the current time is no more than 1 minute to avoid expiration.

[0131] 2. When the master node sends a dynamic verification code to the cloud server, it will be accompanied by the Merkle tree root value signed by the consensus node participating in the shard generation. When the cloud server verifies the dynamic verification code transmitted by the edge node, it obtains the consensus node public key through the blockchain and verifies whether the Merkle tree root value is aggregated by at least 2N / 3+1 node signatures. By using the Merkle tree to compress the verification complexity, it ensures that the dynamic verification code generation meets the fault tolerance requirements of the QBFT consensus.

[0132] 3. Check whether the dynamic verification code conforms to the preset format, then splice the dynamic verification code with the current hash value and compare it with the spliced ​​value sent by the user terminal. If they are consistent, it proves that the dynamic verification code has not been tampered with and is bound to the user identity, completing the verification. The above three methods ensure the legitimacy and accuracy of the dynamic verification code.

[0133] Furthermore, specifically, after the cloud server verifies the validity of the signature, it passes the decrypted hash value, user identity, and current timestamp to the blockchain smart contract. The smart contract extracts the hash value of the user registration from the blockchain storage and verifies it with the current hash value passed in.

[0134] Furthermore, the smart contract verification mechanism of the present invention adopts a two-level gradient verification architecture, achieving a balance between security and usability through precise matching of biometric hashes and dynamic tolerance determination of scenario-role combination hashes. The specific verification process is performed as follows:

[0135] Step 1: Biometric Hash Comparison: First, the smart contract initiates strict consistency verification of the biometric hash. Specifically, the contract retrieves the userIdentity structure stored on the blockchain using the user's identity (e.g., Ethereum address) and extracts the biometric hash value H(F) written during the registration phase. Note that this hash value is a fixed-length 128-byte data value generated by the edge node after normalizing the raw biometric vector.

[0136] At the same time, the smart contract parses the current login request data packet transmitted by the cloud server, extracting the biometric hash value H(F') collected in real time. To ensure data integrity, the system verifies the validity of the digital signatures of the two hash values ​​before comparing them. Specifically, the ECDSA algorithm is used to verify that the signature matches the user's public key, eliminating the risk of tampering during transmission.

[0137] After completing the above preparations, the system performs a byte-by-byte comparison. If any discrepancies are found between H(F) and H(F'), the subsequent verification process is immediately terminated and an error code 401 is returned to the cloud server. For example, if the biometrics do not match, the system will simultaneously record a failure log, including key information such as the discrepant byte position and timestamp, to provide data support for security audits.

[0138] Step 2: Dynamic Verification of the Scenario-Role Combination Hash: Once biometric verification is successful, the system enters the dynamic verification phase for scenario adaptability. The core of this phase is to assess the degree of change in the user's device environment. In practice, the smart contract reads the registered scenario-role combination hash value H(S, R) from on-chain storage. This 256-byte data is generated from multiple factors, including the device's hardware fingerprint and network environment.

[0139] Furthermore, to quantify the degree of environmental change, the system uses the Hamming distance algorithm to calculate the difference between the current combined hash value H(S',R) and the registered value. The specific calculation formula is as follows:

[0140] Δ=HammingDistance(H(S,R),H(S',R)) / 256

[0141] The denominator 256 corresponds to the total bit length of the hash value, so that the calculation result Δ is normalized to a scalar value between 0 and 1.

[0142] After obtaining the difference Δ, the system dynamically adjusts the judgment threshold θ based on the real-time risk level L. For example, when L ≤ 30 (low risk), θ = 0.3, allowing for greater environmental variation; when L ≥ 61 (high risk), θ = 0.1, significantly increasing verification stringency. This flexible threshold mechanism ensures smooth switching of normal devices while promptly blocking access in abnormal environments.

[0143] Furthermore, based on the comparison result of the dynamic difference with the threshold, if the dynamic difference is greater than the threshold, the verification is rejected.

[0144] For example, the smart contract executes the following judgment logic: compare Δ and θ. If Δ ≤ θ, the current environmental change is considered to be within a reasonable range and the authentication is passed.

[0145] Example: User switches from home Wi-Fi to mobile data (Δ=0.15, θ=0.3), login is allowed.

[0146] If Δ>θ: It is determined to be an abnormal environment change (such as device cloning, network hijacking), and authentication is rejected.

[0147] Example: A sudden change in the user device fingerprint (Δ=0.35, θ=0.2) triggers risk control.

[0148] In particular, if three consecutive verification failures occur, the system will force the use of two-factor authentication, regardless of whether the biometrics match. This defensive design effectively counters advanced attacks involving biometric cloning.

[0149] Based on the verification result, the smart contract returns a Boolean value. If the verification is successful, the cloud server generates an authentication success flag. If it fails, it returns a response with an error code and error information and sends it to the user terminal. The user terminal parses it and displays the authentication result, prompting the user to re-authenticate.

[0150] S6 users re-authenticate according to the prompts. If the number of consecutive failures reaches the set threshold, the user's risk level L is adjusted and the user is controlled.

[0151] Furthermore, the cloud server records the number of user authentication failures in real time, and automatically increments the count after each failure. When the number of consecutive failures reaches a preset threshold, such as 5 times, the risk level adjustment process is triggered: the cloud server calls the blockchain smart contract and increases the user's current risk level L according to the preset rules (such as L+20 points). The smart contract updates the L value on the chain and generates an adjustment log. At the same time, the corresponding management and control strategy is automatically triggered according to the new risk level. If L≥60 points, subsequent authentication is forced to use the two-factor mode. If L≥80 points, non-emergency business permissions are temporarily frozen. If L≥90 points, the account is locked and manual review and unlocking are required. In addition, the cloud server will push failure notifications and control reasons to the user terminal, and store the adjustment records on the chain, including the number of failures, adjusted L value, management measures and timestamps.

[0152] The present invention uses edge nodes to collect biometric features to generate feature vectors, combines device scenario tags and business role tags to generate a combined hash value, uploads it to the cloud server after encryption and signing, and writes it to the blockchain by the smart contract; during user authentication, the edge node calculates the real-time risk level, dynamically determines the QBFT consensus mechanism and single and double factor authentication methods, and uploads the hash value or the dynamic verification code after encryption and signing to the cloud server. After verification, the cloud server calls the smart contract for verification; if continuous authentication failures reach the threshold, the risk level is adjusted and management and control are implemented. The present invention achieves high-security privacy protection authentication through edge-cloud collaboration, can dynamically adapt to the security requirements of different business scenarios, effectively prevent data leakage and replay attacks, and improve authentication efficiency and reliability.

[0153] Secondly, as attached Figure 2 As shown, an embodiment of the present invention further provides an identity authentication and control device based on blockchain, comprising:

[0154] User registration module 201, used to collect user information and register on the cloud server;

[0155] An information generation module is used to collect biometric features to generate a feature vector F, obtain a device scenario tag S, assign a business role tag R based on the user's selection, generate a hash value that includes the biometric hash value and a combined hash value of the device scenario tag and the business role tag, encrypt and sign the hash value, and upload it to the cloud server.

[0156] The verification storage module is used to decrypt and verify the uploaded data and write the hash value into the blockchain through the smart contract;

[0157] Authentication module 203, configured to: when a user initiates authentication, the edge node obtains the business role tag R and the device scenario tag S, calculates the real-time risk level L, and determines the QBFT consensus mechanism and authentication method based on the real-time risk level L and a preset policy. The QBFT consensus mechanism is used to generate a dynamic verification code, and the authentication methods include single-factor and two-factor authentication;

[0158] Hash processing module 204, for when single-factor authentication is determined, the edge node performs hash calculation on the user's biometric information to obtain a hash value, encrypts and signs it, and then uploads it to the cloud server; when two-factor authentication is determined, the edge node concatenates the user's biometric hash value, the combined hash value, and the dynamic verification code, encrypts and signs it, and then uploads it to the cloud server;

[0159] Verification module 205 includes a cloud server verification submodule and a blockchain smart contract submodule. The cloud server verification submodule is used to verify the received data and send the hash value to the smart contract submodule on the blockchain. The blockchain smart contract submodule is used to obtain the corresponding hash value from the blockchain for verification. If the verification is successful, the result of authentication success is returned; if the verification fails, the result of authentication failure is returned.

[0160] The risk management module 206 is used to receive the authentication failure prompt returned by the smart contract verification module, record the number of failed authentication operations by the user, and adjust the user's risk level L if the number of consecutive failures reaches a set threshold, and control the user.

[0161] In a third aspect, an embodiment of the present invention further provides an electronic device, comprising a processor and a memory, wherein the memory stores computer-executable instructions that can be executed by the processor, and the processor executes the computer-executable instructions to implement any one of the methods provided in the first aspect.

[0162] The core of the invention The present invention provides a data processing system based on a knowledge graph, which includes a memory, a processor, and a computer program stored on the memory and runnable on the processor, wherein the processor executes the computer program and implements the data processing method based on the knowledge graph as described above.

[0163] A second aspect of the present invention provides a system comprising a memory, a processor, and a computer program stored on the memory and runnable on the processor, wherein the processor executes the computer program and implements the knowledge graph-based data processing method as described in the aforementioned embodiment.

[0164] In addition to the above-mentioned methods and devices, the embodiments herein are also computer program products, which include computer program instructions, which, when executed by a processor, cause the processor to perform the steps of the target detection method according to various embodiments herein described in the above-mentioned "Exemplary Method" section of this specification.

[0165] The basic principles of the present disclosure have been described above in conjunction with specific embodiments. However, it should be noted that the advantages, strengths, and effects mentioned in this disclosure are merely illustrative and not restrictive, and should not be construed as necessarily possessed by each embodiment of the present disclosure. Furthermore, the specific details disclosed above are provided for illustrative purposes and to facilitate understanding, rather than as limitations. These details do not limit the present disclosure to necessarily being implemented using these specific details.

[0166] Each embodiment in this specification is described in a progressive manner, with each embodiment focusing on its differences from the other embodiments. References to the same or similar parts between the various embodiments are sufficient. For system embodiments, since they largely correspond to method embodiments, their description is relatively simple. For relevant parts, references to the description of the method embodiments are sufficient.

[0167] The block diagrams of the devices, devices, equipment, and systems involved in this disclosure are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As will be appreciated by those skilled in the art, these devices, devices, equipment, and systems can be connected, arranged, or configured in any manner. Words such as "include," "comprise," "have," and the like are open-ended words, meaning "including but not limited to," and can be used interchangeably therewith. The words "or" and "and" used herein refer to the words "and / or" and can be used interchangeably therewith, unless the context clearly indicates otherwise. The word "such as" used herein refers to the phrase "such as but not limited to," and can be used interchangeably therewith.

[0168] The methods and apparatus of the present disclosure may be implemented in many ways. For example, the methods and apparatus of the present disclosure may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above order of steps for the method is for illustration only, and the steps of the method of the present disclosure are not limited to the order specifically described above unless otherwise specified. In addition, in some embodiments, the present disclosure may also be implemented as programs recorded in a recording medium, which include machine-readable instructions for implementing the methods according to the present disclosure. Thus, the present disclosure also covers recording media that store programs for executing the methods according to the present disclosure.

[0169] It should also be noted that, in the apparatus, equipment and method of the present disclosure, each component or each step can be decomposed and / or recombined. These decompositions and / or recombinations should be regarded as equivalent schemes of the present disclosure. The above description of the disclosed aspects is provided to enable any technician in this field to make or use the present disclosure. Various modifications to these aspects will be very obvious to those skilled in the art, and the general principles defined herein can be applied to other aspects without departing from the scope of the present disclosure. Therefore, the present disclosure is not intended to be limited to the aspects shown here, but to the widest range consistent with the principles and novel features disclosed herein.

[0170] The above description has been provided for the purpose of illustration and description. In addition, this description is not intended to limit the embodiments of the present disclosure to the forms disclosed herein. Although a number of example aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.

Claims

1. A blockchain-based identity authentication and management method, characterized in that: include: S1, collect user information and register on the cloud server; S2: The edge node collects the user's biometrics to generate a feature vector F, obtains the device scenario tag S, assigns a business role tag R based on the user's selection, and generates a hash value. The hash value includes the biometric hash value and the combined hash value of the device scenario tag and the business role tag. The hash value is encrypted and signed and uploaded to the cloud server. After verification by the cloud server, it is written to the blockchain through a smart contract. S3: The user initiates authentication. The edge node obtains the business role label R and the device scenario label S, calculates the real-time risk level L, and determines the QBFT consensus mechanism and authentication method based on the real-time risk level L and the preset policy. The QBFT consensus mechanism is used to generate a dynamic verification code. The authentication methods include single-factor and two-factor authentication. S4: If it is determined to be single-factor authentication, the edge node performs a hash calculation on the user's biometric information to obtain a hash value, encrypts and signs it, and then uploads it to the cloud server. If it is determined to be two-factor authentication, the edge node concatenates the user's biometric hash value, the combined hash value, and the dynamic verification code, encrypts and signs it, and then uploads it to the cloud server. S5: After verification, the cloud server sends the hash value to the smart contract on the blockchain. The smart contract obtains the corresponding hash value from the blockchain for verification. If the verification is successful, the result of successful authentication is returned. If the verification fails, the authentication failure result is returned and the user is prompted to re-authenticate; S6: The user re-authenticates according to the prompts. If the number of consecutive failures reaches the set threshold, the user's risk level is adjusted and the user is managed.

2. The blockchain-based identity authentication and management method according to claim 1, characterized in that: The dynamic verification code generation specifically includes: after receiving the verification request, selecting the number of consensus nodes according to the risk level, selecting N consensus nodes to participate in the dynamic verification code generation process, each consensus node uses a local random number generation algorithm to independently generate a random integer, which is a fragment of the dynamic verification code, and sends the fragment to the master node through a secure channel. After the master node collects at least 2N / 3+1 valid fragments, it aggregates these fragments to obtain the final dynamic verification code.

3. The blockchain-based identity authentication and management method according to claim 1, characterized in that: The edge node collects biometric features to generate a feature vector F specifically by: collecting biometric data through a fingerprint sensor or an iris recognition module, graying, binarizing, and refining the fingerprint data, and then extracting feature points to generate a 128-byte feature vector.

4. The blockchain-based identity authentication and management method according to claim 1, characterized in that: The edge node collects biometric features to generate a feature vector F specifically by performing pupil location and normalization processing on the iris data and then using a feature coding algorithm to generate a 256-byte feature vector.

5. The blockchain-based identity authentication and management method according to claim 1, characterized in that: The real-time risk level is calculated by a weighted algorithm based on the user's historical authentication records, the geographic location in the device scenario tag, the network type, and the request time.

6. The blockchain-based identity authentication and management method according to claim 1, characterized in that: The user management and control includes: if the risk level L is ≥ 60 points, the subsequent authentication is forced to use the two-factor mode; if L is ≥ 80 points, non-emergency business permissions are temporarily frozen; if L is ≥ 90 points, the account is locked and manual review and unlocking are required.

7. The blockchain-based identity authentication and management method according to claim 1, characterized in that: The cloud server verifies the dynamic verification code by checking the timestamp of the dynamic verification code generation, verifying the Merkle tree root value signed by the consensus node participating in the shard generation, and confirming that the format of the dynamic verification code complies with the preset rules.

8. The blockchain-based identity authentication and management method according to claim 1, characterized in that: The verification process of the smart contract is specifically as follows: a) Biometric verification: comparing the biometric hash value H(F) stored on the chain with the current H(F'). If they are inconsistent, the authentication is directly rejected; b) Combined hash value verification: If the biometric feature passes, calculate the dynamic difference Δ = HammingDistance(H(S,R),H(S',R)) / 256, where HammingDistance is the Hamming distance, H(S,R) is the combined hash value stored on the chain, and H(S',R) is the currently generated combined hash value. Compare the dynamic difference with the preset threshold. If it is greater than the preset threshold, the verification is rejected.

9. A blockchain-based identity authentication and control device, characterized in that: include: User registration module, used to collect user information and register on the cloud server; An information generation module is used to collect biometric features to generate a feature vector F, obtain a device scenario tag S, assign a business role tag R based on the user's selection, generate a hash value that includes the biometric hash value and a combined hash value of the device scenario tag and the business role tag, encrypt and sign the hash value, and upload it to the cloud server. The verification storage module is used to decrypt and verify the uploaded data and write the hash value into the blockchain through the smart contract; The authentication module is used to obtain the business role label R and the device scenario label S at the edge node when the user initiates authentication, calculate the real-time risk level L, and determine the QBFT consensus mechanism and authentication method based on the real-time risk level L and the preset policy. The QBFT consensus mechanism is used to generate a dynamic verification code. The authentication method includes single-factor and two-factor authentication. The hash processing module is used to calculate the user's biometric information to obtain a hash value when it is determined to be single-factor authentication. The edge node encrypts and signs the hash value before uploading it to the cloud server. When it is determined to be two-factor authentication, the edge node concatenates the user's biometric hash value, the combined hash value, and the dynamic verification code, encrypts and signs the hash value, and uploads it to the cloud server. The verification module includes a cloud server verification submodule and a blockchain smart contract submodule. The cloud server verification submodule is used to verify the received data and send the hash value to the smart contract submodule on the blockchain; The blockchain smart contract submodule is used to obtain the corresponding hash value from the blockchain for verification. If the verification is successful, the result of successful authentication is returned. If the verification fails, it returns authentication failure; The risk management module is used to receive the authentication failure prompt returned by the smart contract verification module, record the number of failed re-authentication operations by the user, and adjust the user's risk level L if the number of consecutive failures reaches the set threshold, and control the user.

10. An electronic device, characterized in that: The electronic device includes: a memory and a processor, wherein the memory and the processor are coupled; the memory stores program instructions, and when the program instructions are executed by the processor, the electronic device executes the method according to any one of claims 1 to 8.

Images