A blockchain-based identity authentication and management method and device

Abstract

The application discloses a kind of identity authentication and control method and device based on block chain.The method is generated feature vector by edge node collection biological characteristics, combined with equipment scene label and business role label to generate combination hash value, after encryption signature, upload to cloud server, by smart contract write in block chain;When user authentication, edge node calculates real-time risk level, dynamically selects authentication mode, after cloud server verification, it is verified by smart contract, and according to the verification result, adjust risk level and implement control.The application adopts edge cloud collaborative architecture, by the combination of dynamic multi-factor authentication mechanism and block chain consensus technology, high security privacy protection authentication is realized, can adapt to different business scene security needs, effectively prevent data leakage and replay attack, improve authentication efficiency and reliability.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network security, in particular to an identity authentication and management method and device based on a block chain, a storage medium and an electronic device. BACKGROUND

[0002] In the field of network security, identity authentication is the core link of access control. In existing schemes, centralized authentication schemes and decentralized authentication schemes based on block chains are mainly used. The centralized authentication scheme relies on a central server to store sensitive information such as user biometric features and account passwords, and achieves authentication through a username and password or a single biometric feature. The central server serves as a single trust node, and faces the risks of data tampering and leakage. At the same time, the security of its static authentication strategy is also relatively low.

[0003] In addition, although the authentication scheme based on the block chain solves the centralized storage risk through a distributed ledger, the single on-chain processing mode has an efficiency bottleneck. Moreover, the direct on-chain mode of the biometric feature plaintext or hash value fails to effectively protect the privacy data and has the risk of data leakage. In addition, it cannot dynamically adapt to the security requirements of different business scenarios. SUMMARY

[0004] The purpose of the present application is to overcome the shortcomings of the prior art and provide an identity authentication and management method based on a block chain. The technical scheme adopted by the present application is as follows:

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

[0006] S2, an edge node collects user biometric features to generate a feature vector F, obtains a device scene label S, assigns a business role label R according to user selection, generates a hash value, the hash value includes a biometric feature hash value and a combined hash value of the device scene label and the business role label, and uploads the hash value to the cloud server after encryption and signature. After verification by the cloud server, the smart contract is written into the block chain; S3, a user initiates authentication, an edge node obtains a business role label R and a device scene label S, calculates a real-time risk level L, determines a QBFT consensus mechanism and an authentication method according to the real-time risk level L and a preset strategy, the QBFT consensus mechanism is used to generate a dynamic verification code, and the authentication method includes single-factor and double-factor authentication;

[0007] S4, when single-factor authentication is determined, the edge node performs hash calculation on the user's biometric feature information to obtain a hash value, which is uploaded to the cloud server after encryption and signature; when double-factor authentication is determined, the edge node splices the user biometric feature hash value, the combined hash value and the dynamic verification code, and uploads them to the cloud server after encryption and signature;

[0008] S5, after verification by the cloud server, the hash value is sent to the smart contract on the blockchain, the smart contract obtains the corresponding hash value from the blockchain for verification, if the verification is passed, the result of successful authentication is returned, if the verification fails, the user is prompted to re-authenticate;

[0009] S6, the user re-authenticates according to the prompt, if the number of consecutive failures reaches the set threshold, the risk level L of the user is adjusted, and the user is controlled.

[0010] Optionally, in the above-mentioned method embodiments of the application, the dynamic verification code generation specifically comprises: after receiving the verification request, the number of consensus nodes is selected according to the risk level, N consensus nodes are selected to participate in the dynamic verification code generation process, each consensus node independently generates a random integer using a local random number generation algorithm, which is a shard of the dynamic verification code, and sends the shard to the master node through a secure channel, and the master node collects at least 2N / 3+1 valid shards, and then aggregates and calculates these shards to obtain the final dynamic verification code.

[0011] Optionally, in the above-mentioned method embodiments of the application, the edge node collects biological characteristics to generate a feature vector F, which specifically comprises: collecting biological characteristic data through a fingerprint sensor or an iris recognition module, performing grayscale, binarization and thinning processing on the fingerprint data to extract feature points to generate a 128-byte feature vector.

[0012] Optionally, in the above-mentioned method embodiments of the application, the edge node collects biological characteristics to generate a feature vector F, which specifically comprises: 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 application, the calculation of the real-time risk level is based on the user's historical authentication records, the geographical location, the network type and the request time in the device scene label through a weighted algorithm.

[0014] Optionally, in the above-mentioned method embodiments of the application, the control of the user comprises: if the risk level L is greater than or equal to 60 points, the subsequent authentication is forced to adopt a two-factor mode; if L is greater than or equal to 80 points, the non-urgent business right is temporarily frozen; if L is greater than or equal to 90 points, the account is locked and requires manual review to unlock.

[0015] Optionally, in the above-mentioned method embodiments of the application, the verification of the dynamic verification code by the cloud server comprises: 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 conforms to the preset rules.

[0016] Optionally, in the above-described method embodiments of the present invention, the verification process of the smart contract specifically involves: extracting 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 a feature hash fragment, comparing whether the two are consistent, and if they are consistent, then the verification is passed.

[0017] Secondly, the present invention provides a blockchain-based identity authentication and control device, comprising:

[0018] The user registration module is used to collect user information and register them on the cloud server;

[0019] The information generation module is used to collect biometric features to generate feature vectors F, obtain device scene tags S, assign business role tags R according to user selection, and generate hash values. The hash values ​​include biometric hash values ​​and hash values ​​combining device scene tags and business role tags. After encrypting and signing the hash values, they are uploaded to the cloud server.

[0020] The verification storage module is used to decrypt and verify the uploaded data, and then write the hash value into the blockchain via a smart contract.

[0021] The authentication module is used to obtain the business role label R and the device scenario label S when a user initiates authentication. It 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 strategy. The QBFT consensus mechanism is used to generate dynamic verification codes, and the authentication method includes single-factor and two-factor authentication.

[0022] The hash processing module is used to calculate the hash value of the user's biometric information by the edge node when it is determined to be single-factor authentication, and then encrypt, sign and upload it to the cloud server; when it is determined to be two-factor authentication, the edge node concatenates the user's biometric hash value, combined hash value and dynamic verification code, encrypts and signs it and then 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, it returns a successful authentication result; if the verification fails, it returns an authentication failure result.

[0024] The risk management module is used to receive authentication failure prompts returned by the smart contract verification module, record the number of times the user fails to re-authenticate, and adjust the user's risk level L if the number of consecutive failures reaches a set threshold, and manage the user accordingly.

[0025] Thirdly, the present invention provides an electronic device comprising: a memory and a processor, the memory and the processor being coupled; the memory storing program instructions, which, when executed by the processor, cause the electronic device to perform any of the methods described in the above embodiments.

[0026] Fourthly, the present invention provides a computer-readable storage medium comprising a computer program that, when run on an electronic device, causes the electronic device to perform the method described in any of the above embodiments.

[0027] Compared with existing technologies, the present invention has the following advantages through the above technical solutions: The present invention can significantly improve the security of identity authentication and the accuracy of risk control through a dynamic multi-factor authentication system and a blockchain consensus mechanism. The dynamic verification code mechanism generated based on QBFT consensus, combined with multi-dimensional authentication of biometrics and scene tags, can reduce the risk of identity theft and achieve dynamic adjustment of authentication strength. The blockchain architecture ensures data consistency in a distributed environment, the end-to-end encryption and hash comparison mechanism can ensure data integrity, and the edge-cloud architecture can achieve a balance between security and user experience, reduce authentication latency, and improve authentication efficiency.

[0028] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

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

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

[0031] Figure 2 This is a schematic diagram of the structure of a blockchain-based identity authentication and control device provided in an exemplary embodiment of the present invention. Detailed Implementation

[0032] The present application is described below based on embodiments, but it 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 these details. To avoid obscuring the substance of the present application, well-known methods, processes, flows, elements, and circuits are not described in detail.

[0033] Furthermore, those skilled in the art should understand that the accompanying drawings provided herein are for illustrative purposes only and are not necessarily drawn to scale.

[0034] Furthermore, it should be understood that in the following description, "circuit" refers to a conductive loop consisting of at least one element or sub-circuit connected by electrical or electromagnetic connections. When an element or circuit is said to be "connected" to another element or "connected" between two nodes, it can be directly coupled or connected to another element, or there may be intermediate elements. The connection between 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 them.

[0035] Unless the context explicitly requires it, words such as "including" or "contains" throughout the application should be interpreted as including rather than exclusive or exhaustive; that is, 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 construed as indicating or implying relative importance. Furthermore, in the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0037] Hereinafter, exemplary embodiments according to the present invention will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of the present invention, and not all embodiments of the present invention. It should be understood that the present invention is not limited to the exemplary embodiments described herein.

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

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

[0040] It should also be understood that in the embodiments of the present invention, "multiple" can refer to two or more, and "at least one" can refer to one, two or more.

[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 defined or given contrary instructions in the context.

[0042] This invention achieves highly secure and privacy-preserving authentication through edge-cloud collaboration, dynamically adapting to the security needs 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, a blockchain network, a cloud server, and a user terminal.

[0043] Edge nodes: Deployed at the network edge close to user terminals, equipped with biometric data acquisition interfaces, supporting 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] The blockchain network can be a private consortium blockchain built on Ethereum 2.0, or other blockchain network architectures. This network includes master nodes, validator 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 according to the risk level (e.g., N=5 for low risk, N=9 for high risk). These nodes jointly participate in dynamic CAPTCHA shard generation and consensus verification, and are the core participants in the blockchain consensus mechanism. Validator nodes are the specific implementation of consensus nodes, referring to N pre-deployed nodes in the blockchain network, responsible for generating blocks and verifying transactions. Validator nodes are a subset of consensus nodes; all validator nodes are considered consensus nodes. The master node is a consensus node dynamically selected from the validator node pool to coordinate and is responsible for the aggregation of dynamic CAPTCHA shards and consensus process control. The master node is a validator node and also part of the consensus nodes; its role is to temporarily undertake coordination tasks during the consensus process.

[0045] Cloud server: The core component, which can be a redundant server group, running a registration service program developed based on Java, and supporting key management and signature verification of multiple encryption algorithms.

[0046] User terminal: Such as a smartphone, not limited to HarmonyOS, Android or iOS systems, with biometric data collection functions such as fingerprint recognition and iris recognition, supporting network communication functions, and a communication module that supports 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. An encrypted channel is used between the edge nodes and the terminals to ensure the privacy of biometric data during local processing. The edge nodes upload 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. Simultaneously, the cloud server sends authentication policies and parameters such as the number of consensus nodes (N) to the edge nodes 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 identifier to trigger the on-chain verification logic. At the same time, it synchronizes data such as the hash value when the user registered from the blockchain node for local pre-verification.

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

[0050] User terminals obtain encrypted dynamic verification codes from cloud servers, decrypt them using their private keys, and participate in the authentication process. The verification result of the dynamic verification code from the cloud server is uploaded to the smart contract on the blockchain. The smart contract returns the authentication result (true / false) to the cloud server, which then 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 control method, including: S1 collecting user information and registering with a cloud server;

[0052] The system involves users accessing the registration interface via their terminal devices and filling in basic identity information, including but not limited to username, password, email address, and mobile phone number. The system sends an SMS verification code to the user's entered mobile phone number. The user then enters this verification code into the registration interface to verify the authenticity of the mobile phone number. After completing the basic information verification, the edge node guides the user through biometric data collection preparation, prompting them to place their finger on the fingerprint recognition module or adjust their facial position to align with the camera for iris image capture. Simultaneously, it acquires information such as the terminal device type and operating system to generate initial information for the device scenario label S. Then, based on the user's selected business type (e.g., ordinary user, cross-border trader), a business role label R is assigned.

[0053] The S2 edge node collects user biometrics to generate a feature vector F, obtains device scene tags S, assigns business role tags R according to user selection, and generates a hash value. The hash value includes a biometric hash value and a combined hash value of device scene tags and business role tags. After encrypting and signing the hash value, it is uploaded to the cloud server. After verification by the cloud server, it is written into the blockchain through a smart contract.

[0054] Furthermore, edge nodes collect fingerprint data through fingerprint sensors or iris biometric data through iris recognition modules, or collect facial data, voiceprint, and other data through tools. The following example uses fingerprint and iris processing.

[0055] The process involves preprocessing the fingerprint data, converting the color fingerprint image into a grayscale image, converting the grayscale image into a black and white binary image, thinning the fingerprint ridges to a single pixel width, extracting feature points, and finally generating a 128-byte feature vector F.

[0056] The process involves preprocessing the iris data, first locating the pupil position, then normalizing it, and finally using a feature encoding algorithm to generate a 256-byte feature vector F.

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

[0058] Furthermore, the device scene tags are generated as follows:

[0059] Hardware information includes, but is not limited to: device model (e.g., iPhone 14 Pro), operating system version (iOS 16.4), and CPU model (A16).

[0060] Network information includes, but is not limited to: IP address and 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, and light intensity obtained through an ambient light sensor.

[0062] Combine the above information into a device scenario tag S according to a preset format such as JSON.

[0063] Tag 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 "regular user", "cross-border trader" or "administrator", the corresponding permission set is assigned from the predefined role library.

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

[0067] Role R Permission Set Ordinary User Commodity browsing, ordering, payment Cross-border trader Cross-border payment, international logistics tracking, foreign exchange query Administrator User management, system configuration, transaction audit

[0068] Furthermore, the hash value includes H(F) biometric hash value and H(S,R) combined hash value, wherein the biometric hash value H(F) is generated as shown in the following 128-dimensional example:

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

[0070] Step 1.2: Segmented hash calculation, dividing the 512 segments into a front segment and a back segment, each segment being 256 bytes.

[0071] For front-end processing: extract the first 256 bytes of data, apply the SHA-256 algorithm to generate the intermediate hash value H1, and fix the output length to 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 truncate the first 32 bytes as the intermediate hash value H2;

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

[0074] The following is an example of generating a combined hash value H(S,R):

[0075] Step 2.1: Scene tag serialization, converting the device scene tag S into a standardized JSON string: the key name field is arranged in lexicographical order, all whitespace characters are removed, and UTF-8 encoding is used uniformly;

[0076] Step 2.2: Role tag encoding, mapping the business role tag R to a 2-byte unsigned integer: for example: ordinary user: 0x0001, administrator: 0x0100, super user: 0xFF00, using big-endian byte order for storage;

[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, use a preset threshold, such as "Scene-Role-Binding-Salt-0xFAST" to perform keyed hashing mode, and generate a 32-byte scene-role combination hash value H(S,R).

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

[0081] After encryption, ciphertext and initialization vector IV are generated and combined to form 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 and generate a digital signature signature.

[0082] The edge node packages the encrypted result EI, the digital signature "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 signing EI; "public_key" is the user's ECDSA public key (used for signature verification); and "timestamp" is the generated timestamp to prevent replay attacks. The upload data packet is then sent to the cloud server through 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 and confirm whether it was generated by the corresponding private key to the EI.

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

[0086] The cloud server decrypts the encrypted result to obtain the hash value.

[0087] Furthermore, the blockchain evidence storage 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 tag R, and device scenario tag S as parameters to the smart contract. The hash value includes biometric hash value and hash value combining device scenario tag and business role tag.

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

[0090] Furthermore, optionally, the cloud server invokes a smart contract deployed on the blockchain, passing the user's Ethereum address (ethAddress), hash value, business role label R, device scenario label S, and timestamp as parameters. The smart contract creates and maintains a userIdentity table on the blockchain, with the following structure:

[0091] structUserIdentity{

[0092] addressethAddress; / / User's Ethereum address

[0093] bytes32hashF; / / Hash value of biometric information

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

[0095] stringroleTag; / / Business role tag R

[0096] stringsceneTag; / / Device scene tag

[0097] uint256 registerTime; / / Registration timestamp} mapping(address => UserIdentity) userIdentityTable;

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

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

[0100] QBFT stands for Quick Byzantine Fault Tolerance, a consensus mechanism unique to the Hyperledger Besu blockchain client. Developed by the Hyperledger Besu team, it aims to improve the efficiency and performance of Byzantine fault-tolerant algorithms. QBFT involves multiple node roles, including proposers, validators, and observers. Proposers are responsible for generating new blocks and broadcasting them to validators. Validators verify and vote on the blocks. Observers do not participate in the consensus process but can receive the finalized blocks.

[0101] The QBFT consensus process mainly includes three phases: pre-preparation, preparation, and commit. After generating a new block, the proposer sends a pre-preparation message to the validators; upon receiving the message, the validators verify the block and broadcast a preparation message; once the validators have received enough preparation messages, they enter the commit phase, broadcasting a commit message and finally determining the block. Unlike PBFT, QBFT introduces a coordinator role to collect and aggregate validators' votes, reducing the number of message passes. Based on this, this invention adopts the QBFT consensus mechanism.

[0102] Furthermore, the edge node receives authentication requests initiated by users through their terminal devices. The requests include user identifiers such as username and Ethereum address, and authentication context information such as request time, request IP, and request service type.

[0103] Edge nodes query the on-chain identity records corresponding to users through the blockchain interface to obtain: business role tags R: such as "ordinary user" or "cross-border trader"; device scenario tags S: including hardware information, network information, environmental information, etc.; historical authentication records: such as the most recent authentication time, authentication result, and historical changes in risk level, etc.

[0104] Furthermore, the real-time risk level L calculation includes first collecting multi-dimensional risk factors: Behavioral risk: statistically analyzing the number of authentication failures and request frequency anomalies in the past hour. Environmental risk: checking for differences between the geographical location of the requesting IP and its historical location, changes in network type, and changes in device fingerprints.

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

[0106] Risk Value Calculation Model: PL = w1 × F1 + w2 × F2 + ... + w n ×F n +B

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

[0108] w1-w n The weights for each factor are as follows: behavioral risk weight 0.4, environmental risk weight 0.35, and time risk weight 0.25.

[0109] B is the base risk value, with a default score of 30 for initial certification. The final dynamic risk level L is obtained by weighting and summing all factors and then overlaying it with the base value, providing data support for subsequent certification strategy matching.

[0110] Then, a risk level mapping is performed, 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 matching is performed. Based on the current business role label R, device scenario label S, and real-time risk level L, the corresponding number of consensus nodes N and authentication method are matched from the preset strategy table. Specifically, the cloud server calls the blockchain smart contract interface to trigger the QBFT consensus mechanism based on the real-time risk level L uploaded by the edge node. N nodes are dynamically selected from the blockchain verification node pool to form a consensus group. For example, single-factor authentication is used when the risk is low and no consensus verification is required. Double-factor authentication is used when the risk is medium and 5 verification nodes are selected. Double-factor authentication is used when the risk is high and 9 verification nodes with the highest reputation value 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 L is 30, a 5-node consensus (1 fault-tolerant node) is used; when L ≥ 60, a 9-node consensus (2 fault-tolerant nodes) is used. Nodes are selected from a pre-deployed pool of 9 validator nodes, and the master node is determined by taking the current block height modulo N. Consensus nodes transmit shard data through an encrypted channel. The message includes the shard value, node identifier, block height, and ECDSA signature. The master node broadcasts a request to generate the block height. Each node performs a hash operation based on the seed, block height, and its own identifier, converting the result into a 32-byte shard value. After collecting no less than 2N / 3+1 valid shards, the master node calculates the final dynamic verification code by summing and taking the modulo 2^1024, then encrypts the dynamic verification code using the user's public key and sends it to the user terminal through a secure channel.

[0114] During authentication, edge nodes retrieve a dynamic verification code generated by a smart contract based on risk level L from the cloud server. 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, verifies its validity, and then sends the verification result back to the edge node for further processing. Upon receiving the successful verification feedback, the edge node re-collects biometric features to generate F', reconstructs the hash value by combining it with the real-time device scenario tag S' and the on-chain role tag 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 generating dynamic verification codes, the cloud server calls the smart contract interface to elect consensus nodes to generate dynamic verification codes based on the risk level L. After receiving the spliced ​​data uploaded by the edge nodes, the cloud server verifies the validity of the timestamp and the Merkle tree signature aggregation result when performing dynamic verification code verification. 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 1-minute validity period.

[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 feature F is verified; when the risk level L>30 or the device scenario S is an untrusted environment, both the biometric feature F and the dynamic verification code are verified.

[0117] Authentication Policy Table:

[0118] Business Role R Device Scenario S Risk Level L Consensus Node Number N Authentication Method Ordinary User Home WiFi Low Risk 0 Nodes Single Factor Ordinary User Public WiFi Medium Risk 5 Nodes Double Factor Cross-border trader Any network High risk 9 nodes Double factor Administrator Untrusted device High risk 9 nodes Multi-factor

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

[0120] Furthermore, the edge node receives the authentication method determined in step S3, either single-factor or two-factor, and related parameters. If it is single-factor authentication, only biometric data needs to be prepared: a) raw feature data is collected in real time through biosensors; b) the same preprocessing process as in the registration stage is executed; c) a standardized feature vector F' is generated.

[0121] If it is a two-factor authentication, both biometric signature F and dynamic verification code are required.

[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, combines them into a new device scenario label S' according to the JSON format defined in S2, and extracts the business role label R from the on-chain information obtained from S3. It then regenerates the biometric hash and the combined hash using F', R, and S', where the user's role label R is obtained from the blockchain smart contract.

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

[0124] After the above processing is completed, the edge nodes perform hash calculations. For single-factor authentication, the biometric information is used to generate a hash value. For two-factor authentication, the hash value is concatenated with the UTF-8 encoded byte stream of the dynamic verification code string for encryption and signature processing to ensure the security and verifiability of the authentication data.

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

[0126] In this process, the user terminal first obtains the RSA public key of the cloud server, and then uses an encryption algorithm to encrypt the hash value or concatenation 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 one, or other commonly used encryption methods in the field of encryption can be used.

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

[0128] After receiving the data packet, the cloud server first verifies the validity of the TLS certificate, decrypts the encrypted hash value using the user's ECDSA public key, and obtains the original hash value or the concatenated value. It then retrieves the corresponding ECDSA public key from the local database using the user's identity identifier, decrypts the encrypted hash value and / or the concatenated value, and verifies the signature to confirm that the data has not been tampered with. Simultaneously, it checks the difference between the data packet's timestamp and the current server time to ensure it is within the validity period. Finally, it reconstructs the original hash value and / or the concatenated value, which includes the encoded hash value serialized byte stream and the dynamic verification code string.

[0129] Furthermore, when using two-factor authentication, 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 ensure that the time difference between it and the current time is no more than 1 minute, so as to avoid using it after it expires.

[0131] 2. When the master node sends a dynamic verification code to the cloud server, it will also include the Merkle root value of the consensus node signatures generated by the sharding. When the cloud server verifies the dynamic verification code transmitted by the edge node, it obtains the consensus node's public key through the blockchain and verifies whether the Merkle root value is aggregated from 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 QBFT consensus.

[0132] 3. Check if the dynamic verification code conforms to the preset format, then concatenate the dynamic verification code with the current hash value and compare it with the concatenated value sent by the user terminal. If they match, it proves that the dynamic verification code has not been tampered with and is bound to the user's identity, thus completing the verification. The above three methods ensure the legality and accuracy of the dynamic verification code.

[0133] Furthermore, specifically, after the cloud server verifies the validity of the signature, the cloud server sends the decrypted hash value, user identity identifier, and current timestamp to the blockchain smart contract. The smart contract retrieves the hash value at the time of user registration from the blockchain storage and verifies it with the incoming current hash value.

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

[0135] Step 1: Biometric Hash Value Comparison; First, the smart contract initiates a strict consistency verification of the biometric hash. Specifically, the contract retrieves the userIdentity structure stored on the blockchain using the user's identity identifier (such as an Ethereum address) and extracts the biometric hash value H(F) written during the registration phase. It should be noted that this hash value is a fixed-length data of 128 bytes, generated by the edge nodes after standardizing the original biometric vector.

[0136] Meanwhile, the smart contract parses the current login request data packet from the cloud server and extracts the real-time collected biometric hash value H(F'). To ensure data integrity, the system verifies the validity of the digital signatures of the two hash values ​​before comparison. Specifically, the ECDSA algorithm is used to verify the match between the signature and the user's public key, thereby eliminating the risk of tampering during transmission.

[0137] After completing the above preparations, the system performs a byte-by-byte comparison. If any difference is 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, indicating a biometric mismatch. The system will synchronously record a failure log, including the location of the differing bytes, timestamps, and other key information, to provide data support for security auditing.

[0138] Step 2: Dynamic Verification of Scenario-Role Combination Hash; After biometric verification is successful, the system enters the dynamic verification phase of scenario adaptability. The core of this phase is to assess the degree of change in the user's device environment. In specific implementation, the smart contract reads the scenario-role combination hash value H(S,R) at the time of registration from on-chain storage, which includes 256 bytes of data generated from diverse information such as device 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, which normalizes the calculation result Δ 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, it is set as follows: when L≤30 (low risk), θ=0.3, allowing for larger environmental changes; when L≥61 (high risk), θ=0.1, significantly improving the verification rigor. This flexible threshold mechanism ensures both the smoothness of normal device switching and timely blocking of access in abnormal environments.

[0143] Furthermore, based on the comparison results of dynamic difference degree and threshold, if it is greater than the threshold, the verification is rejected.

[0144] For example, a smart contract executes the following judgment logic: compare Δ with θ, and if Δ≤θ: consider the current environmental changes to be within a reasonable range, and the authentication is successful.

[0145] Example: A user switches from home Wi-Fi to mobile data (Δ = 0.15, θ = 0.3) and is allowed to log in.

[0146] If Δ > θ: This is considered an abnormal environment change (such as device cloning or network hijacking), and authentication is rejected.

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

[0148] Specifically, if three consecutive verification attempts fail, the system will force the use of two-factor authentication regardless of whether the biometrics match. This defensive design effectively counters advanced attacks that replicate biometrics.

[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 identifier; if it fails, it returns a response with an error code and error message, which is sent to the user terminal. The user terminal parses the response and displays the authentication result, prompting the user to re-authenticate.

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

[0151] Furthermore, the cloud server records the number of user authentication failures in real time, automatically incrementing 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 to increase the user's current risk level L according to preset rules (e.g., L+20 points). The smart contract updates the on-chain L value and generates an adjustment log. At the same time, the corresponding control strategy is automatically triggered according to the new risk level. If L≥60 points, subsequent authentication will be forced to adopt the two-factor mode. If L≥80 points, non-urgent business permissions will be temporarily frozen. If L≥90 points, the account will be locked and manual review will be required to unlock it. In addition, the cloud server will also push failure notifications and control reasons to the user's terminal and store the adjustment records on the blockchain, including the number of failures, the adjusted L value, control measures, and timestamps.

[0152] This invention collects biometric features at edge nodes to generate feature vectors, combines these vectors with device scenario tags and business role tags to generate combined hash values, and uploads them to a cloud server after encryption and signing. A smart contract then writes these hash values ​​to the blockchain. During user authentication, edge nodes calculate the real-time risk level, dynamically determine the QBFT consensus mechanism and single / double factor authentication method, and upload the hash value, or a combination of hash and dynamic verification code, to the cloud server after encryption and signing. The cloud server verifies the hash value and invokes the smart contract for verification. If consecutive authentication failures reach a threshold, the risk level is adjusted and control measures are implemented. This invention achieves highly secure and privacy-preserving authentication through edge-cloud collaboration, dynamically adapting to the security needs of different business scenarios, effectively preventing data leakage and replay attacks, and improving authentication efficiency and reliability.

[0153] Secondly, as attached Figure 2 As shown, this embodiment of the invention also provides a blockchain-based identity authentication and control device, including:

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

[0155] The information generation module is used to collect biometric features to generate feature vectors F, obtain device scene tags S, assign business role tags R according to user selection, and generate hash values. The hash values ​​include biometric hash values ​​and hash values ​​combining device scene tags and business role tags. After encrypting and signing the hash values, they are uploaded to the cloud server.

[0156] The verification storage module is used to decrypt and verify the uploaded data, and then write the hash value into the blockchain via a smart contract.

[0157] The authentication module 203 is used to obtain the business role label R and the device scenario label S when a 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 strategy. The QBFT consensus mechanism is used to generate dynamic verification codes, and the authentication method includes single-factor and two-factor authentication.

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

[0159] The 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, it returns a successful authentication result; if the verification fails, it returns an authentication failure result.

[0160] The risk management module 206 is used to receive authentication failure prompts returned by the smart contract verification module, record the number of times the user fails to re-authenticate, and adjust the user's risk level L if the number of consecutive failures reaches a set threshold, and manage the user.

[0161] Thirdly, embodiments of the present invention also provide an electronic device, including a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement the method described in any of the first aspects.

[0162] The core of this invention is to provide a knowledge graph-based data processing system, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program and implements the knowledge graph-based data processing method as described above.

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

[0164] In addition to the methods and apparatus described above, the embodiments herein are also computer program products that include computer program instructions that, when executed by a processor, cause the processor to perform the steps of the target detection methods according to the various embodiments herein as described in the "Exemplary Methods" section above.

[0165] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0166] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For system embodiments, since they largely correspond to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0167] The block diagrams of devices, apparatuses, devices, and systems disclosed herein 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 those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0168] The methods and apparatus of this disclosure may be implemented in many ways. For example, they may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order of steps for the methods is for illustrative purposes only, and the steps of the methods of this disclosure are not limited to the order specifically described above unless otherwise specifically stated. Furthermore, in some embodiments, this disclosure may also be implemented as a program recorded on a recording medium, the program including machine-readable instructions for implementing the methods according to this disclosure. Thus, this disclosure also covers recording media storing programs for performing the methods according to this disclosure.

[0169] It should also be noted that in the apparatus, devices, and methods of this disclosure, the components or steps are decomposable and / or recombinable. Such decomposition and / or recombination should be considered equivalent to the present disclosure. The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0170] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.

Claims

1. A blockchain-based identity authentication and control method, characterized in that, include: S1, collect user information and register with the cloud server; S2, the edge node collects user biometrics to generate feature vector F, obtains device scene label S, assigns business role label R according to user selection, and generates hash value. The hash value includes biometric hash value and combined hash value of device scene label and business role label. After encrypting and signing the hash value, it is uploaded to the cloud server. After verification by the cloud server, it is written to the blockchain through 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 strategy. The QBFT consensus mechanism is used to generate dynamic verification codes, and the authentication method includes single-factor and two-factor authentication. 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 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, combined hash value and dynamic verification code, encrypts and signs it before uploading it to the cloud server. After verification by the S5 cloud server, the hash value is sent to the smart contract on the blockchain. The smart contract retrieves the corresponding hash value from the blockchain when the user registered and verifies it. If the verification is successful, it returns a successful authentication result. If verification fails, an authentication failure result will be returned, prompting the user 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 subject to control.

2. The blockchain-based identity authentication and control method according to claim 1, characterized in that, The generation of dynamic verification codes specifically includes: after receiving a 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 independently generating a random integer using a local random number generation algorithm, which is a fragment of the dynamic verification code, and sending 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 calculations on these fragments to obtain the final dynamic verification code.

3. The blockchain-based identity authentication and control method according to claim 1, characterized in that, The process of collecting biometric features and generating feature vector F at the edge node involves: collecting biometric data through a fingerprint sensor, performing grayscale, binarization, and thinning processing on the fingerprint data, and then extracting feature points to generate a 128-byte feature vector.

4. The blockchain-based identity authentication and control method according to claim 1, characterized in that, The process of collecting biometric features at the edge nodes to generate the feature vector F involves: performing pupil localization and normalization on the iris data, and then using a feature encoding algorithm to generate a 256-byte feature vector.

5. The blockchain-based identity authentication and control method according to claim 1, characterized in that, The user control measures include: if the risk level L ≥ 60 points, mandatory use of the two-factor authentication mode for subsequent authentication; if L ≥ 80 points, temporary freezing of non-urgent business permissions; if L ≥ 90 points, triggering account lockout and requiring manual review for unlocking.

6. The blockchain-based identity authentication and control method according to claim 1, characterized in that, The cloud server's verification of the dynamic verification code includes: checking the timestamp of the dynamic verification code generation, verifying the Merkle root value of the consensus node signatures participating in the shard generation, and confirming that the dynamic verification code format conforms to preset rules.

7. The blockchain-based identity authentication and control method according to claim 1, characterized in that, The smart contract verification process is as follows: a) Biometric verification: compare the biometric hash value H(F) stored on the chain with the current H(F'). If they do not match, the authentication is rejected directly. b) Verification of combined hash value: If the biometrics pass, 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 a preset threshold. If it is greater than the preset threshold, the verification is rejected.

8. A blockchain-based identity authentication and control device, characterized in that, include: The user registration module is used to collect user information and register them on the cloud server; The information generation module is used to collect biometric features to generate feature vectors F, obtain device scene tags S, assign business role tags R according to user selection, and generate hash values. The hash values ​​include biometric hash values ​​and hash values ​​combining device scene tags and business role tags. After encrypting and signing the hash values, they are uploaded to the cloud server. The verification storage module is used to decrypt and verify the uploaded data, and then write the hash value into the blockchain via a smart contract. The authentication module is used to obtain the business role label R and the device scenario label S when a user initiates authentication. It 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 strategy. The QBFT consensus mechanism is used to generate dynamic verification codes, and the authentication method includes single-factor and two-factor authentication. The hash processing module is used to calculate the hash value of the user's biometric information by the edge node when it is determined to be single-factor authentication, encrypt and sign it and then upload it to the cloud server; when it is determined to be two-factor authentication, the edge node concatenates the user's biometric hash value, combined hash value and dynamic verification code, encrypts and signs it and then 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 retrieve the corresponding hash value from the blockchain when the user registered, and to verify it. If the verification is successful, it returns a result indicating successful authentication. If verification fails, an authentication failure will be returned. The risk management module is used to receive authentication failure prompts returned by the smart contract verification module, record the number of times the user fails to re-authenticate, and adjust the user's risk level L if the number of consecutive failures reaches a set threshold, and manage the user accordingly.

9. An electronic device, characterized in that, The electronic device includes: a memory and a processor, the memory and the processor being coupled; the memory stores program instructions that, when executed by the processor, cause the electronic device to perform the method as described in any one of claims 1 to 7.

Images