Distributed network identity authentication method and system based on block chain

Abstract

The invention provides a distributed network identity authentication method and system based on a block chain, and relates to the technical field of data processing, and the method comprises the steps: 1, a user terminal generates a decentralized identity identifier and a corresponding asymmetric cryptography key pair, identity registration information containing the decentralized identity identifier and the public key is uploaded to a block chain identity chain to complete registration; and 2, in the identity authentication process, acquiring authentication request data sent by a user terminal, extracting a plurality of authentication feature quantities from the authentication request data, and dividing the authentication strategy framework into a plurality of strategy execution areas by using a grid division algorithm based on spatial distribution features of the authentication feature quantities. According to the invention, through combination of decentralized identity registration, regionalized strategy adjustment and block chain smart contract verification, the security, reliability and dynamic adaptability of distributed network identity authentication are improved, and the credibility of the authentication process and the non-tampering of the result are guaranteed.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a distributed network identity authentication method and system based on blockchain. Background Technology

[0002] In smart manufacturing workshops, automated guided vehicles (AGVs), mobile robots, and other equipment need to move between different work areas and dynamically access the network. To establish a trusted identity system, existing solutions use decentralized identity technology based on blockchain to create a decentralized identity identifier for each device and register the identity information on the blockchain to achieve immutability and verifiability of identity data. However, when dealing with mobile device access, the authentication logic of existing authentication methods may seem too simplistic. Current solutions mainly rely on verifying the correctness of the device's digital signature and the registration status of the identity identifier on the chain. This static verification mechanism is mostly unable to effectively identify abnormal patterns in the device's movement behavior.

[0003] For example, an automated guided vehicle that has completed blockchain identity registration may initiate a network access request from an unauthorized work area if its firmware is maliciously tampered with. In this case, the existing authentication mechanism may grant access based solely on a valid digital signature and legitimate identity status, without being able to identify potential unauthorized access risks based on contextual information such as the device's real-time location. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to provide a blockchain-based distributed network identity authentication method and system, which improves the security of identity authentication in distributed networks.

[0005] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows:

[0006] Firstly, a blockchain-based distributed network identity authentication method, the method comprising:

[0007] Step 1: The user terminal generates a decentralized identity identifier and a corresponding asymmetric cryptographic key pair, and uploads the identity registration information containing the decentralized identity identifier and public key to the blockchain identity chain to complete the registration;

[0008] Step 2: During the identity authentication process, collect authentication request data sent by the user terminal, extract multiple authentication feature quantities from the authentication request data, and use a grid partitioning algorithm to divide the authentication strategy framework into multiple strategy execution regions based on the spatial distribution characteristics of the authentication feature quantities.

[0009] Step 3: Set up an authentication evaluation unit in each policy execution area. Based on the numerical characteristics and spatial location of the authentication features, assign each authentication feature to the corresponding policy execution area to form an authentication feature set for each policy execution area.

[0010] Step 4: For each policy execution region, calculate the policy adjustment coefficient based on the certification evaluation unit, and generate comprehensive verification parameters by weighted fusion calculation based on the policy adjustment coefficients of each policy execution region.

[0011] Step 5: Input the comprehensive verification parameters into the identity management smart contract deployed on the blockchain, verify the digital signature of the user terminal, query the registration status of the decentralized identity identifier in the blockchain identity chain, and generate the identity verification result;

[0012] Step 6: When the identity verification result is successful, the identity management smart contract generates an access permission decision based on the comprehensive verification parameters and uploads the identity verification result and access permission decision to the blockchain for storage. Secondly, a blockchain-based distributed network identity authentication system includes:

[0013] The registration module is used by user terminals to generate decentralized identity identifiers and corresponding asymmetric cryptographic key pairs, and upload identity registration information containing decentralized identity identifiers and public keys to the blockchain identity chain to complete the registration.

[0014] The partitioning module is used to collect authentication request data sent by user terminals during the identity authentication process, extract multiple authentication feature quantities from the authentication request data, and divide the authentication strategy framework into multiple strategy execution regions based on the spatial distribution characteristics of the authentication feature quantities using a grid partitioning algorithm.

[0015] The evaluation module is used to set up an authentication evaluation unit in each policy execution area. Based on the numerical characteristics and spatial location of the authentication features, it assigns each authentication feature to the corresponding policy execution area, forming an authentication feature set for each policy execution area.

[0016] The adjustment module is used to calculate the policy adjustment coefficient based on the certification evaluation unit for each policy execution region, and generate comprehensive verification parameters through weighted fusion calculation based on the policy adjustment coefficient of each policy execution region.

[0017] The verification module is used to input comprehensive verification parameters into the identity management smart contract deployed on the blockchain, verify the digital signature of the user terminal, query the registration status of the decentralized identity identifier in the blockchain identity chain, and generate the identity verification result.

[0018] The storage module is used to generate access permission decisions based on comprehensive verification parameters when the identity verification result is successful, and then upload the identity verification result and access permission decisions to the blockchain for storage.

[0019] Thirdly, a computing device, comprising:

[0020] One or more processors;

[0021] A storage device for storing one or more programs that, when executed by one or more processors, cause the one or more processors to implement the method.

[0022] Fourthly, a computer-readable storage medium storing a program that, when executed by a processor, implements the method.

[0023] The above-described solution of the present invention has at least the following beneficial effects:

[0024] By extracting multi-dimensional authentication features such as timestamp sequences, device hardware characteristics, and network communication characteristics, and combining this with dynamic policy adjustments (e.g., generating policy adjustment coefficients based on risk assessment values), abnormal patterns during device movement can be effectively captured, avoiding the risk of unauthorized access caused by legitimate identities but abnormal behavior. By registering decentralized identity identifiers and public keys on the blockchain, and storing identity verification results and access permission decisions on the blockchain, the immutability and distributed storage characteristics of blockchain are fully utilized to ensure that identity baseline data and authentication process records are not tampered with. Through grid partitioning, feature allocation by region, and regional risk assessment, domain-specific control of authentication features is achieved, avoiding the coarseness of a single assessment logic. This refined processing can more accurately reflect the real-time status of the device. By parsing comprehensive verification parameters through blockchain smart contracts, dynamically determining the verification strictness level, and generating permission decisions that include resource access scope and effective time limits, the rigidity of fixed permissions is avoided, and the automatic execution characteristics of smart contracts ensure that the permission allocation logic is transparent and trustworthy. Attached Figure Description

[0025] Figure 1 This is a flowchart illustrating a blockchain-based distributed network identity authentication method provided in an embodiment of the present invention.

[0026] Figure 2 This is a schematic diagram of a blockchain-based distributed network identity authentication system provided in an embodiment of the present invention. Detailed Implementation

[0027] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0028] like Figure 1 As shown, embodiments of the present invention propose a blockchain-based distributed network identity authentication method, the method comprising the following steps:

[0029] Step 1: The user terminal generates a decentralized identity identifier and a corresponding asymmetric cryptographic key pair, and uploads the identity registration information containing the decentralized identity identifier and public key to the blockchain identity chain to complete the registration;

[0030] Step 2: During the identity authentication process, collect authentication request data sent by the user terminal, extract multiple authentication feature quantities from the authentication request data, and use a grid partitioning algorithm to divide the authentication strategy framework into multiple strategy execution regions based on the spatial distribution characteristics of the authentication feature quantities.

[0031] Step 3: Set up an authentication evaluation unit in each policy execution area. Based on the numerical characteristics and spatial location of the authentication features, assign each authentication feature to the corresponding policy execution area to form an authentication feature set for each policy execution area.

[0032] Step 4: For each policy execution region, calculate the policy adjustment coefficient based on the certification evaluation unit, and generate comprehensive verification parameters by weighted fusion calculation based on the policy adjustment coefficients of each policy execution region.

[0033] Step 5: Input the comprehensive verification parameters into the identity management smart contract deployed on the blockchain, verify the digital signature of the user terminal, query the registration status of the decentralized identity identifier in the blockchain identity chain, and generate the identity verification result;

[0034] Step 6: When the identity verification result is successful, the identity management smart contract generates an access permission decision based on the comprehensive verification parameters, and uploads the identity verification result and access permission decision to the blockchain for storage.

[0035] In this embodiment of the invention, by extracting multi-dimensional authentication features such as timestamp sequences, device hardware characteristics, and network communication characteristics, and combining them with dynamic policy adjustments, such as generating policy adjustment coefficients based on risk assessment values, abnormal patterns during device movement can be effectively captured, avoiding the risk of unauthorized access caused by legitimate identities but abnormal behavior. By registering decentralized identity identifiers and public keys on the blockchain, and storing identity verification results and access permission decisions on the blockchain, the immutability and distributed storage characteristics of the blockchain are fully utilized to ensure that identity baseline data and authentication process records are not tampered with. Through grid partitioning, feature quantity partitioning and regional risk assessment, domain-specific control of authentication features is achieved, avoiding the coarseness of a single assessment logic. This refined processing can more accurately reflect the real-time status of the device. By parsing comprehensive verification parameters through blockchain smart contracts, dynamically determining the verification strictness level, and generating permission decisions that include resource access scope and effective time limits, the rigidity of fixed permissions is avoided, and the automatic execution characteristics of smart contracts ensure that the permission allocation logic is transparent and trustworthy.

[0036] In a preferred embodiment of the present invention, step 1 involves the user terminal generating a decentralized identity identifier and a corresponding asymmetric cryptographic key pair, and uploading the identity registration information containing the decentralized identity identifier and public key to the blockchain identity chain to complete the registration, including:

[0037] In this embodiment of the invention, the first step is to prepare the equipment capabilities. These mobile devices need to dynamically access the network in different work areas, so they need to have two basic capabilities in advance. The first is secure computing capability, which must have a built-in hardware security module or trusted execution environment. Such components can provide hardware-level secure storage and computing functions, specifically designed to ensure the randomness of subsequent key generation and the anti-theft security during storage. The second is blockchain access capability, which requires the installation of client tools that can connect to the blockchain identity chain, such as client components that support the common data transmission protocols of workshop-specific consortium blockchains, to ensure that the equipment can communicate stably with each node of the identity chain.

[0038] Next, asymmetric cryptographic key pairs are generated. Considering the limited processor and storage resources of mobile devices, computationally efficient elliptic curve cryptography algorithms are prioritized, such as the 256-bit elliptic curve algorithm commonly used for device authentication. During the generation process, the device generates a private key using a cryptographically secure random number generator. After generation, the private key is immediately stored in the hardware-level encrypted storage area of ​​the hardware security module or trusted execution environment, without being transmitted over the network; only the device's own security chip can access it. Subsequently, when the device derives the public key, it first calls the pre-built elliptic curve preset parameters within the security module. These parameters conform to the industry standard for 256-bit elliptic curve device authentication and are fixed baseline data. Specifically, these include the curve equation coefficients, which adopt the common standard values ​​for this type of algorithm: coefficient a is 0, coefficient b is 7, and the corresponding elliptic curve equation is... First, it ensures computational security and compatibility. Second, it defines the base point, where x represents the x-coordinate of the point on the elliptic curve plane, and y represents the y-coordinate, both of which are standard fixed 256-bit values. Third, it defines the finite field order, a standard prime number order specific to elliptic curves, which is the core parameter ensuring encryption strength. The private key is used as a 256-bit scalar value and is multiplied by the base point in the isolated environment of the security module. Essentially, this involves repeatedly performing elliptic curve addition on the base point according to the private key value a specified number of times. The entire calculation process does not expose intermediate data, and the final result is the public key. The public key is stored in an uncompressed format, and the x and y values ​​it contains also represent the x and y coordinates of the corresponding point on the elliptic curve plane, respectively.

[0039] Next, a decentralized identity identifier is generated. This process is completed autonomously by the device without the intervention of any centralized server. The format consists of three parts. The first part is the method name, which is determined according to the type of blockchain identity chain. If the identity chain is a dedicated consortium chain for a smart manufacturing workshop, the method name will be set as workshop consortium chain identifier + smart manufacturing scenario identifier, such as workshop chain-smart factory. The scenario identifier is used to distinguish the industrial scenario to which the device belongs. The second part is the specific identifier. After performing a 256-bit hash operation on the public key generated above, the first 160 bits of the result are converted into a 40-digit hexadecimal string to ensure that the identifier of each device is unique and can be traced back to the corresponding public key through the string. The final decentralized identity identifier format is, for example, a decentralized identity identifier prefix plus workshop chain-smart factory plus a 40-digit hexadecimal string. Specifically, it is similar to the decentralized identifier plus... The Workshop Chain - Smart Factory plus 7a3f9b4c2d8e1a5f... identifier uniquely identifies mobile devices and can verify identity association through public key traceability. Subsequently, identity registration information is constructed. In addition to the decentralized identity identifier and public key, basic device attribute information is added. Specifically, the device model is labeled with its type, such as Automated Guided Vehicle - A1 or Mobile Robot - B3. These models are directly associated with the device's hardware configuration and functional permissions. The initial work area clearly defines the area where the device is first deployed, such as work area 1 in Workshop A or three logistics channels in Workshop B. Sensitive information such as device firmware version and internal IP address is removed to prevent leakage and malicious attacks. The public key information is also additionally labeled with an algorithm identifier, such as Elliptic Curve Algorithm - 256 bits, to facilitate rapid matching of the corresponding verification algorithm by blockchain nodes.

[0040] Finally, the blockchain registration process is completed. The first step is to construct a registration transaction. The device uses its private key to digitally sign the complete registration information, ensuring that it can be identified if the information is tampered with during transmission, and proving that the initiator is the device. Then, according to the transaction format specifications of the identity chain, the identifier, public key, device attributes, and digital signature are combined into transaction data including field verification bits. The second step is transaction broadcasting. The device sends the transaction data to the consensus nodes of the blockchain identity chain through the client tool it is equipped with. These nodes are operated by trusted entities such as the workshop management system, equipment manufacturers, and park operation and maintenance platforms, and are responsible for transaction verification and block generation. The third step is node verification and consensus. The consensus nodes first use the device... The process begins with verifying the transaction signature using a public key. After confirming that the signature matches the public key, the system queries existing data on the chain to check if the identifier has already been registered, preventing duplicate identities. Once verification is successful, nodes reach a consensus on the transaction using a Raft-like consensus algorithm, ensuring that all nodes approve the transaction. The fourth step is on-chain storage. Consensus transactions are packaged into newly generated blocks, which contain information such as the block number and the hash value of the previous block. After generation, the blocks are synchronized to all nodes on the identity chain and ultimately stored in the blockchain ledger as key-value pairs. The key is the decentralized identity identifier, and the value is a complete decentralized identity document containing the public key, device attributes, registration timestamp, and document version number. At this point, device identity registration is complete.

[0041] In a preferred embodiment of the present invention, step 2 includes:

[0042] Step 200 involves extracting multiple authentication features from the authentication request data. These features include timestamp sequences, device hardware characteristics, and network communication characteristics. Specifically, this includes: first, extracting the three core authentication features one by one from the authentication request data sent by the user terminal; when extracting the timestamp sequence, collecting each time point of the authentication request, including the request start time and the time points of each stage of data transmission, and then organizing these time points into an ordered sequence in chronological order. This sequence reflects the timing pattern of the device initiating authentication, such as determining whether the device initiates the request during normal working hours; when extracting device hardware characteristics, reading the device hardware information interface data carried in the authentication request data to extract the device's inherent hardware identification information, such as the device's hardware model, unique core chip identifier, and hardware configuration parameters. This information is used to confirm the consistency of the device's physical identity and prevent non-target devices from forging identities; when extracting network communication characteristics, parsing the network data packets corresponding to the authentication request and extracting network access-related feature information from the data packets, such as the network access address when the device initiated the request, the type of communication protocol used, and the data transmission rate. This information reflects the environmental characteristics of the device accessing the network and provides a basis for determining whether the access environment is normal.

[0043] Step 201: Based on the spatial distribution characteristics of the authentication features, construct an authentication strategy framework and use a grid partitioning algorithm to divide the authentication strategy framework into four strategy execution regions. Step 201a involves projecting multiple authentication features onto a two-dimensional authentication feature plane to form a set of authentication feature points. Specifically, this includes selecting two representative feature dimensions from the extracted three types of authentication features as the horizontal and vertical axes of the two-dimensional authentication feature plane. Device hardware feature similarity is selected as the horizontal axis, and network communication feature matching degree is selected as the vertical axis. The calculation process for device hardware feature similarity involves comparing the currently extracted device hardware features, such as hardware model, core chip identifier, and configuration parameters, with the hardware information stored when the device is registered on the blockchain identity chain. The hardware features are compared item by item, and the number of feature items that completely match is counted. This number is then divided by the total number of hardware features. The resulting ratio is the device hardware feature similarity, with the result ranging from 0 to 1. A higher value indicates a higher degree of matching. The network communication feature matching degree is calculated as follows: network communication features from the device's historical normal network access times, such as historical access addresses, common communication protocols, and typical transmission rates, are retrieved to form a baseline feature set. The currently extracted network communication features are compared item by item with the baseline feature set, and the number of items in the current feature set that completely overlap with the baseline features is counted. This number is then divided by the total number of network communication features. The resulting ratio is the network communication feature matching degree, with the result also ranging from 0 to 1.

[0044] For each authentication feature, the horizontal coordinate value is determined based on the similarity of its corresponding device hardware features, and the vertical coordinate value is determined based on the matching degree of its corresponding network communication features. Thus, the specific coordinate position of the feature is determined on the two-dimensional authentication feature plane. Each authentication feature corresponds to a unique coordinate point. After summing all the coordinate points, an authentication feature point set is formed.

[0045] Step 201b: Based on the spatial distribution of the authentication feature point set, calculate the minimum bounding rectangle of the authentication feature point set, and use this minimum bounding rectangle as the spatial range of the authentication strategy framework. Specifically, this includes: first, traversing all coordinate points in the authentication feature point set, recording the x-coordinate and y-coordinate of each point; on the x-axis, comparing the x-coordinates of all points, selecting the largest value as the maximum value and the smallest value as the minimum value; similarly, on the y-axis, comparing the y-coordinates of all points, selecting the largest value as the maximum value and the smallest value as the minimum value, and then using the minimum value as the minimum value. The left boundary of the rectangle is defined by the minimum x-coordinate of the left edge of the rectangle; the right boundary is defined by the maximum x-coordinate of the right edge of the rectangle; the bottom boundary is defined by the minimum y-coordinate of the bottom edge of the rectangle; and the top boundary is defined by the maximum y-coordinate of the top edge of the rectangle. The rectangle constructed using these four boundaries completely contains all the coordinate points in the authentication feature point set. This rectangle is called the minimum bounding rectangle of the authentication feature point set, and its spatial range is the spatial range of the authentication strategy framework used for authentication evaluation.

[0046] Step 201c: Using a grid partitioning algorithm, the spatial range of the authentication policy framework is divided into four equal rectangular policy execution regions along both the horizontal and vertical directions. Specifically, this includes: first, calculating the horizontal and vertical lengths of the authentication policy framework, i.e., the minimum bounding rectangle; where the horizontal length is the result of subtracting the minimum value from the maximum value on the horizontal axis, representing the total width of the rectangle in the horizontal direction; and the vertical length is the result of subtracting the minimum value from the maximum value on the vertical axis, representing the total height of the rectangle in the vertical direction; then, the horizontal direction is divided into equal parts, and the midpoint position in the horizontal direction is calculated. The x-coordinate is the sum of the maximum and minimum x-axis values, divided by 2. Draw a line parallel to the y-axis through this midpoint. This line divides the rectangle horizontally into two equal parts (left and right, each half the total horizontal length). Simultaneously, divide the rectangle vertically into two equal parts and calculate the midpoint. The y-coordinate of the midpoint is the sum of the maximum and minimum y-axis values, divided by 2. Draw a line parallel to the x-axis through this midpoint. This line divides the rectangle vertically into two equal parts (upper and lower, each half the total vertical length).

[0047] After the two dividing lines intersect, the original minimum bounding rectangle is divided into four smaller rectangles of equal size, each of which is an independent policy execution area.

[0048] This embodiment, by extracting three types of features—time, hardware, and network—breaks through the limitations of authentication relying solely on a single identity identifier. It can characterize the device authentication status from multiple dimensions, including time sequence, physical identity, and access environment. By projecting abstract authentication features onto a two-dimensional plane to form a point set, it transforms the originally scattered feature information into a visualized spatial distribution, making the correlations and differences between features more intuitive. Determining the authentication strategy framework range using the minimum bounding rectangle ensures that the framework precisely covers all feature points, avoiding both excessively large ranges that lead to scattered feature analysis and excessively small ranges that miss key features, thus guaranteeing the framework's adaptability to the current authentication scenario. Dividing the framework into four equal regions avoids the coarseness of a one-size-fits-all approach in overall evaluation, enabling more accurate location of abnormal risks in features within different regions and improving the granularity of authentication decisions.

[0049] In a preferred embodiment of the present invention, step 3 includes:

[0050] Step 300: Based on the spatial density distribution of the authentication feature quantities, determine the boundary coordinate range of each policy execution region. Specifically, this includes: first, counting the number of coordinate points in the authentication feature point set distributed within the four initially divided regions (the four small rectangles obtained in step 201c), thus determining the spatial density of each region, i.e., the proportion of feature points contained within each region to the total number of feature points. A higher proportion indicates a denser distribution of feature points in that region. Combining the spatial density distribution, further clarify the boundary coordinate range of each policy execution region. For the horizontal direction, using the horizontal midpoint (midpoint of the horizontal axis) calculated in step 201c as the boundary, the left boundary of the left region is the minimum horizontal value of the original smallest bounding rectangle. The right boundary is the horizontal midpoint; the left boundary of the right region is the horizontal midpoint, and the right boundary is the maximum horizontal value of the original minimum bounding rectangle; for the vertical direction, the vertical midpoint (vertical midpoint) calculated in step 201c is used as the boundary, the lower boundary of the upper region is the vertical midpoint, and the upper boundary is the maximum vertical value of the original minimum bounding rectangle; the lower boundary of the lower region is the minimum vertical value of the original minimum bounding rectangle, and the upper boundary is the vertical midpoint; if some points in a region are close to the boundary due to excessive feature point density, the boundary coordinates will be finely adjusted, such as extending the boundary of the dense region by 1% to 2% in the direction of point density, to ensure that the densely distributed feature points are completely contained in the corresponding region, and finally forming the precise boundary coordinate range of each strategy execution region.

[0051] Step 301: Based on the boundary coordinate range of the four policy execution regions, an authentication evaluation unit is set up at the center of each policy execution region. Specifically, this includes: calculating the coordinates of the center position of each policy execution region. For the horizontal direction, the sum of the horizontal coordinates of the left and right boundaries of the region is taken and then divided by 2 to obtain the horizontal center coordinates. For the vertical direction, the sum of the vertical coordinates of the lower and upper boundaries of the region is taken and then divided by 2 to obtain the vertical center coordinates. The combination of the horizontal and vertical center coordinates is the center position coordinate of the policy execution region. An authentication evaluation unit is deployed at the center of each region. This unit has data receiving, feature analysis, and local calculation functions and can directly obtain the authentication feature data within its region.

[0052] An authentication evaluation unit is deployed at a physical node corresponding to the geometric center of each policy execution area. These physical nodes are industrial equipment installation points with optimal signal coverage and convenient cabling within the area, such as near control boxes or network access points in a workshop. This ensures efficient reception of feature data across the entire area. This unit is an edge computing module, and its hardware structure consists of a hardware interface, an embedded processing chip, and a local storage unit. The hardware interface includes an Ethernet port and a wireless communication module (such as industrial Wi-Fi) for receiving authentication feature data transmitted from devices within the area. The embedded processing chip (such as an ARM architecture microprocessor) is responsible for real-time processing of the received data, supporting structured parsing (converting raw feature data into a standard format). The edge computing module performs correlation analysis (identifying temporal or logical relationships between different feature quantities) and local operations (such as feature aggregation and preliminary screening of outliers). The local storage unit is used to temporarily cache data during processing to ensure that data is not lost. In actual deployment, the edge computing module connects to the industrial Ethernet switch in the area via Ethernet port or connects to the workshop-level wireless AP via Wi-Fi module to establish a stable communication link with all devices in the area. When a device initiates an authentication request, it sends the extracted authentication feature quantity to the module through a preset port. The module, relying on the real-time receiving capability of the hardware interface and the computing performance of the processing chip, completes the reception and preliminary processing of a single feature quantity, which is fully matched with the authentication frequency and data volume of devices in the area and meets the real-time processing requirements.

[0053] Step 302: Establish feature allocation rules. The feature allocation rules include determining spatial allocation conditions based on the positional relationship between the spatial coordinates of the certified feature and the coordinate range of the policy execution area, and determining numerical allocation conditions based on the matching relationship between the numerical range of the certified feature and a preset threshold interval. Specifically, the feature allocation rules are used to clarify the policy execution area to which each certified feature should belong. They include two parts: spatial allocation conditions and numerical allocation conditions, both of which must be met simultaneously to complete the allocation. The spatial allocation conditions are formulated based on the matching relationship between the spatial coordinates of the certified feature and the coordinate range of the policy execution area. For any certified feature, its abscissa and ordinate on the two-dimensional certified feature plane are first extracted, and then compared with the boundary coordinate range of a certain policy execution area. If the abscissa of the feature is greater than the left boundary abscissa of the area and less than the right boundary abscissa, and the ordinate is greater than the lower boundary ordinate of the area and less than the upper boundary ordinate, then the spatial position of the feature is determined to be within the area, satisfying the spatial allocation conditions.

[0054] The numerical allocation conditions are determined based on the fit between the numerical range of the authentication feature values ​​and the corresponding preset threshold intervals for each region. These preset threshold intervals are determined by analyzing the distribution of feature data during historical normal authentication of the device. Due to different feature patterns, the four policy execution regions have distinctly different threshold intervals. Specifically, the first region focuses on high-matching features, with a threshold interval of 0.9 to 1.0 for device hardware feature similarity and 0.85 to 1.0 for network communication feature similarity. The second region focuses on relatively high-matching features, with a threshold interval of 0.7 to 0 for device hardware feature similarity. 0.9, the network communication feature matching degree threshold range is 0.7 to 0.85; the third region focuses on regular matching degree features, the device hardware feature similarity threshold range is 0.5 to 0.7, and the network communication feature matching degree threshold range is 0.5 to 0.7; the fourth region focuses on low matching degree features, the device hardware feature similarity threshold range is 0 to 0.5, and the network communication feature matching degree threshold range is 0 to 0.5. When the value of a certain authentication feature, such as device hardware feature similarity or network communication feature matching degree, falls within the above threshold range corresponding to a certain region, it is determined that the value allocation condition of that region is met.

[0055] Step 303: According to the feature allocation rules, each authentication feature is assigned to the corresponding policy execution region. The authentication evaluation unit aggregates the authentication features assigned to the corresponding policy execution regions to form an authentication feature set for each policy execution region. Specifically, this includes: First, processing each authentication feature individually. The allocation process for each feature is as follows: Step 1: Extracting the spatial coordinates (horizontal and vertical coordinates) of the feature and comparing them with the boundary coordinate ranges of the four policy execution regions to check whether the spatial allocation conditions of a certain region are met, i.e., whether the coordinates fall between the left and right boundaries and the lower and upper boundaries of the region; Step 2: Extracting the feature... The core values ​​of the quantity, such as the similarity value of device hardware features and the matching degree value of network communication features, are compared with the preset threshold range corresponding to the region that meets the spatial allocation conditions in the first step. For example, if the spatial coordinates of a certain feature quantity meet the range of the first region, it is checked whether its hardware similarity is between 0.9 and 1.0 and its communication matching degree is between 0.85 and 1.0, so as to determine whether it meets the numerical allocation conditions of the region. In the third step, if a certain feature quantity meets both the spatial and numerical allocation conditions of a region, it is marked as the feature quantity to be allocated in that region and sent to the authentication evaluation unit of that region through a data transmission protocol, such as the MQTT industrial protocol.

[0056] After receiving all the assigned features, the authentication evaluation unit of each policy execution area initiates an aggregation process. First, it categorizes and summarizes the raw data of the features, organizing them into subsets according to feature type (timestamp sequence, device hardware features, network communication features). Then, it adds a unique identifier to each feature, recording its generation timestamp and the corresponding device terminal source to ensure traceability. Subsequently, it filters out duplicate data, such as records of the same feature under the same timestamp and invalid data, such as outliers with hardware similarity below 0 and significantly deviating from a reasonable range. Finally, it forms a structured set containing all valid features and their associated information in the area, which is the authentication feature set of the policy execution area.

[0057] This embodiment determines boundaries by combining the spatial density distribution of feature quantities, avoiding ambiguity in feature point attribution due to coarse initial division, and ensuring that the coverage of each region matches the actual feature distribution. An evaluation unit is set up at the center of the region to reduce data transmission distance and improve the efficiency of feature quantity reception and processing. Through dual-condition screening of spatial location and numerical range, it ensures that feature quantities are accurately assigned to the corresponding evaluation region, avoiding allocation errors caused by single-condition judgment. The feature quantities within the region are aggregated to form a structured feature set, improving the relevance and accuracy of certification evaluation.

[0058] In a preferred embodiment of the present invention, step 4 includes:

[0059] Step 400 involves analyzing the distribution characteristics of the corresponding authentication feature set through the authentication evaluation unit of each policy execution area, and calculating the consistency index and dispersion of the authentication feature quantity. Specifically, the authentication evaluation unit of each policy execution area conducts a distribution characteristic analysis of the authentication feature set of that area. First, it extracts the core values ​​of all authentication feature quantities in the set, including the similarity of device hardware features and the matching degree of network communication features. It counts each core value and counts the specific number of times each value appears in the set. Then, it arranges all core values ​​in ascending order and accumulates the occurrence count of the corresponding value starting from the minimum value. When the accumulated count reaches 70% of the total number of features, it records the value range at this time, that is, from the initial minimum value to the current value at the end of the accumulation. This continuous range is the concentrated distribution interval of the feature quantity. At the same time, it calculates the proportion of the occurrence count of each value to the total number of features and selects the values ​​with a proportion of more than 20%. These values ​​are the high-frequency value points. Through the two indicators of concentrated distribution interval and high-frequency value points, the overall distribution trend of the feature set is clarified.

[0060] The process of calculating the consistency index based on the above distribution characteristics is as follows: The historical normal authentication feature distribution benchmark for this region is determined as follows: collect all feature data generated by normal authentication in the past 3 months, extract the core values ​​and sort them from smallest to largest. Take the value at the 2.5% position after sorting as the lower limit and the value at the 97.5% position as the upper limit to form a 95% confidence interval, that is, 95% of the normal feature values ​​fall within this interval. At the same time, count the proportion of the occurrence of each value to the total normal features during this period, and select the range of values ​​with a proportion exceeding 20% ​​as the historical high-frequency value interval. When calculating the current consistency index, first compare the concentrated distribution interval of the current feature set with the 95% confidence interval of the historical benchmark, and count the specific number of values ​​in the current feature quantity that fall within the 95% confidence interval. Then compare the current high-frequency value points with the historical high-frequency value interval, and count the specific number of values ​​in the current feature quantity that fall within the historical high-frequency value interval. Add the two types of statistical counts to obtain the total number of matches. The consistency index is obtained by dividing the total number of matches by the total number of features in the current feature set. The higher the ratio, the stronger the consistency between the current feature and the historical normal features. The dispersion is calculated as follows: First, select the largest and smallest values ​​from the core values ​​of the current feature set. Subtract the smallest value from the largest value to get the value range. Then, determine the midpoint of the concentrated distribution interval by taking the left and right endpoint values ​​of the concentrated distribution interval, adding the two values ​​and dividing by 2. The result is the midpoint of the concentrated distribution interval. Next, calculate the absolute deviation between the core value of each feature and the midpoint. That is, take the absolute value of the difference between each value and the midpoint, add all the absolute deviations to get the total deviation, and then divide the total deviation by the total number of features in the current feature set to get the average deviation value. Finally, combine the value range and the average deviation value to determine the dispersion. That is, the smaller the value range and the lower the average deviation value, the more concentrated the distribution of the feature and the lower the dispersion.

[0061] Step 401: Based on the consistency index and dispersion, and combined with the time series change trend of the certification feature quantity, calculate the risk assessment value for each strategy execution area. Specifically, when calculating the base risk value, the consistency index and dispersion need to be numerically transformed first, and then the result is obtained through weighted combination. The specific process is as follows: The consistency index reflects the degree of matching between the current feature and the historical normal feature. In order to associate it with risk, it needs to be converted into an inverse value. When the consistency index is 100%, that is, a perfect match, the corresponding value is 0 (lowest risk); when the consistency index is 0% (complete mismatch), the corresponding value is 100 (highest risk). In cases of high dispersion, the value increases linearly with the decrease of the consistency index. For example, when the consistency index is 50%, the corresponding value is 50. Meanwhile, the dispersion reflects the concentration or dispersion of the feature distribution and needs to be converted into a positive value. When the dispersion is the lowest, that is, the feature is highly concentrated and the value range and average deviation are both the smallest, the corresponding value is 0 (lower risk). When the dispersion is the highest, that is, the feature is extremely dispersed and the value range and average deviation are both the largest, the corresponding value is 100 (higher risk). In other cases, the value increases linearly with the increase of the dispersion. For example, when the dispersion is at a medium level, the corresponding value is 50.

[0062] Due to the consistency difference (i.e., the converted reverse value and the distribution dispersion (i.e., the converted positive value) having equally important impacts on risk, they need to be combined with a 50% weighting. Specifically, the reverse value of the consistency indicator is multiplied by 0.5 to obtain its contribution to risk, and the positive value of the dispersion is multiplied by 0.5 to obtain its contribution to risk. The sum of these two values ​​is the base risk value, ranging from 0 to 100. Next, the base risk value is adjusted based on the trend of the characteristic quantity over time. If the mean of the characteristic quantity is stable within the historical normal range and the fluctuation is small (i.e., a stable trend), the base risk value remains unchanged. If the mean gradually deviates from the historical range and the deviation continues to widen (i.e., a deviation trend), the base risk value is calculated by multiplying it by 1.2. If the mean fluctuates drastically in a short period and deviates from the historical range (i.e., a sudden change trend), the base risk value is calculated by multiplying it by 1.5.

[0063] Step 402: Based on the risk assessment value and the distribution density of the authentication features, a weighted average algorithm is used to calculate the strategy adjustment coefficient for each strategy execution region. Specifically, this includes: first, determining the distribution density of the authentication feature set, i.e., calculating the area of ​​the strategy execution region (horizontal length × vertical length), counting the total number of authentication features within the region, and dividing the total number by the area to obtain the number of features per unit space, i.e., the distribution density. The higher the number of features, the higher the distribution density, indicating a greater impact of the feature data in that region on the overall authentication result; and then, based on the risk assessment value and the distribution density, calculating the strategy adjustment coefficient using a weighted average algorithm. First, weighting rules are set: when the distribution density is lower than the average density of the four regions... The risk assessment value has a weight of 0.6, and the distribution density has a weight of 0.4. When the distribution density is higher than or equal to the average density, the risk assessment value has a weight of 0.4, and the distribution density has a weight of 0.6 (the sum of the two weights is always 1). The risk assessment value, ranging from 0 to 100, is converted to a standardized value of 0 to 1, i.e., risk assessment value ÷ 100, multiplied by its corresponding weight, to obtain the risk contribution value. The distribution density is converted to a standardized value of 0 to 1, i.e., the density of the region ÷ the maximum density of the four regions, multiplied by its corresponding weight, to obtain the density contribution value. The strategy adjustment coefficient is the sum of the risk contribution value and the density contribution value (ranging from 0 to 1). The higher the coefficient, the more stringent the certification strategy adjustment is required for the region.

[0064] Step 403: Perform a weighted fusion calculation on the policy adjustment coefficients of the four policy execution regions to generate a comprehensive verification parameter based on the preset weight configuration. Specifically, this includes: a preset weight configuration for the four policy execution regions, which is determined based on the functional importance of the region and the reliability of historical certification. Regions containing core production equipment, such as the main control equipment region, have a weight of 0.3; regions containing key auxiliary equipment, such as the data transmission node region, have a weight of 0.25; regions containing conventional terminal equipment, such as the ordinary sensor region, have a weight of 0.25; and regions containing edge access equipment, such as the temporary access terminal region, have a weight of 0.2. The sum of the weights of the four regions is 1. Multiply the policy adjustment coefficient (ranging from 0 to 1) of each policy execution region by the corresponding preset weight to obtain the weighted adjustment value of each region. Then, add the weighted adjustment values ​​of the four regions together to obtain the comprehensive verification parameter, which ranges from 0 to 1. This parameter integrates the characteristic risks and adjustment requirements of all regions.

[0065] This embodiment, by analyzing distribution characteristics and calculating consistency indices and dispersion, can grasp the distribution patterns of feature quantities at both the overall and individual levels, providing an objective basis for risk assessment. Combined with time series trends, it enables risk assessment to not only reflect the current state but also capture the evolutionary patterns of feature quantities, improving the ability to predict potential anomalies. Weighted calculation based on risk and distribution density allows the strategy adjustment coefficients to adapt to the differences in feature distribution across different regions, avoiding a one-size-fits-all approach. By weightedly integrating the adjustment needs of each region, the generated comprehensive verification parameters can balance the impact of different regions, providing a unified decision-making basis for optimizing the overall certification strategy.

[0066] In a preferred embodiment of the present invention, step 5 includes:

[0067] Step 500: The comprehensive verification parameters are transmitted to the identity management smart contract deployed on the blockchain. The identity management smart contract parses the comprehensive verification parameters and determines the verification strictness level of the identity verification process. Specifically, this includes: firstly, preprocessing the comprehensive verification parameters generated in step 403 by performing a hash operation on the parameters using the SHA-256 algorithm to generate a 256-bit hash value; combining the hash value and the parameter body according to the hash value and parameter format to form a transmission data packet, which is then sent to the access node of the blockchain network through an encrypted communication link based on the TLS 1.3 protocol. When establishing a connection, the encrypted link uses the ECDHE key exchange algorithm to generate a temporary session key and performs end-to-end encryption on the transmitted data packet (the encryption algorithm is AES-GCM-256) to ensure that even if the data is intercepted during transmission, it cannot be decrypted or eavesdropped.

[0068] The blockchain network provides a trusted environment for identity verification, notarization, and smart contract execution. It employs a consortium blockchain architecture and comprises three types of nodes: access nodes (deployed by service providers and distributed across server clusters in the core data center) responsible for receiving external data; consensus nodes (jointly operated by equipment manufacturers and regulatory agencies, deployed in secure data centers across different regions); and storage nodes (based on a distributed file system, redundantly storing all on-chain data to ensure its integrity). The network uses the Practical Byzantine Fault-Tolerant (PBFT) consensus algorithm, with a block generation interval of 5 seconds, and supports smart contracts executed in seconds. Written and deployed in the Solidity language, it meets the security, consistency, and real-time requirements of authentication scenarios. After receiving the data packet, the blockchain access node (belonging to the server cluster deployed by the service provider) immediately initiates the parameter integrity verification process, which involves separating the hash value and parameter body from the data packet, re-performing the SHA-256 hash operation on the parameter body, and comparing the newly generated hash value with the received hash value bit by bit. If the two are completely consistent, it means that the parameter has not been tampered with during transmission. The access node then forwards the parameter to the consensus node responsible for executing the identity management smart contract through the blockchain's internal P2P communication protocol (implemented using the gRPC framework).

[0069] After receiving the parameters, the consensus node triggers the identity management smart contract pre-deployed on the chain. This contract is deployed after being reviewed and approved by all alliance members. The address is written into the parsing logic of the node configuration file during network initialization. The smart contract first extracts the specific value from the parameters and then matches it with the preset strictness level threshold range within the contract. The preset threshold range is divided according to the risk level of the business scenario. Specifically, when the value of the comprehensive verification parameter is less than 0.3, it corresponds to a low-risk scenario (such as ordinary information query) and matches the basic verification level; when the value is greater than or equal to 0.3 and less than 0.7, it corresponds to a medium-risk scenario (such as data browsing) and matches the standard verification level; when the value is greater than or equal to 0.7, it corresponds to a high-risk scenario (such as permission change) and matches the enhanced verification level. The smart contract automatically determines the strictness level of this identity verification by judging which range the parameter value falls into and writes the level information into the contract's temporary storage area in key-value pair format (the key is the unique identifier ID of this verification request, generated by the access node and passed in with the parameters; the value is the character identifier corresponding to the level, such as basic, standard, enhanced).

[0070] Step 501: Verify the user terminal's digital signature based on the verification strictness level, and query the registration status of the decentralized identity identifier in the identity chain to obtain the digital signature verification result and registration status query result. Specifically, the smart contract reads the verification strictness level determined in step 500 from the temporary storage area and initiates a layered verification process for the digital signature submitted by the user terminal. If it is the basic verification level, the verification process is as follows: First, perform format verification to check whether the digital signature conforms to the standard format of the elliptic curve digital signature algorithm. Specifically, verify whether the total byte length of the signature data is consistent with the preset value of 64 bytes. This length is specified by the algorithm standard to ensure that the signature structure is complete and there are no data truncation, splicing errors, etc. The problem is as follows: Next, public key binding verification is performed. The device identifier registry on the blockchain is called to query the public key list corresponding to the user terminal device identifier, such as the mobile device identification code. This list is uploaded by the device manufacturer when the device enters the network and stored on the blockchain. The public key used for this signature is checked to see if it is in the list. If it is, the binding relationship between the public key and the device is confirmed to be valid. Finally, time validity verification is performed. The generation timestamp contained in the signature is extracted (synchronously written when the user terminal generates the signature) and compared with the current system time of the blockchain node (taken from the node's trusted time source). The time difference is calculated. If the time difference is within ±5 minutes (the fault tolerance range is used to deal with the time synchronization error between the terminal and the node), the signature generation time is determined to be valid.

[0071] For the standard verification level, two additional checks are added to the basic verification. The first is hash algorithm compliance check, which parses the hash algorithm identifier recorded in the signature and compares it with the list of security algorithms preset in the smart contract, such as SHA-256 and SHA-384. If the identifier is in the list, the algorithm is deemed compliant. The second is original data integrity check, which extracts the original data corresponding to the signature, such as user ID and operation type, and checks whether it contains all required fields. For example, the user ID cannot be empty and the operation type must be a preset enumerated value to ensure that the data has not been truncated or tampered with.

[0072] To enhance the verification level, two additional checks are added to the standard verification. The first is a replay attack check, which extracts the unique random number embedded in the signature, queries the smart contract's random number history table, and if the random number has not been recorded before, it is considered successful (to prevent the signature from being reused). The second is a public key validity period check, which calls the certificate authority's on-chain notarization contract to obtain the digital certificate corresponding to the public key, compares the certificate's validity start time and validity end time with the current system time, and if the current time is within the validity period, the public key is considered valid.

[0073] After completing digital signature verification, the smart contract initiates a decentralized identity identifier (DID) registration status query. This involves sending a query transaction containing the user terminal's DID to the identity chain via the cross-chain query interface. Upon receiving the transaction, the identity chain node retrieves the registration record corresponding to the DID, extracts fields such as registration time, associated public key list, revocation flag (Boolean value), and last update time, packages the results into a query result, and returns it to the smart contract. The smart contract then determines the registration status based on the result. If the revocation flag is not present, the current signature public key is in the associated public key list, and the registration time is earlier than the current time and has not exceeded the maximum validity period (e.g., 3 years), the registration is considered valid; otherwise, the registration is considered invalid.

[0074] Step 502: Combining the digital signature verification result and the registration status query result, generate the final identity verification result. Specifically, the smart contract first summarizes the two results from Step 501: the digital signature verification result (pass or fail and the specific reason) and the DID registration status query result (registration valid or invalid and the specific reason). Based on the summarized results, a preliminary judgment is made. If the digital signature verification result is passable and the DID registration status is valid, the verification is preliminarily determined to be successful. If the digital signature verification result is failable, such as format verification failure or public key not bound, regardless of the registration status, the verification is determined to be unsuccessful, and the specific reason for failure is written into the result details. If the digital signature verification result is passable but the DID registration status is invalid, such as being revoked or the public key not being in the associated list, the verification is also determined to be unsuccessful, and the reason is noted, such as the DID being revoked and the revocation date being 2023-10-01. For enhanced verification level scenarios... Based on the initial judgment, cross-validation is added. This involves extracting user information from the original digital signature data, such as device model and registration organization code, and comparing it with the corresponding fields in the DID registration record of the identity chain. If all fields are completely consistent, or the differences are within the preset tolerance range (e.g., different device models or minor version numbers), the initial judgment is maintained. If there are key field differences, such as inconsistent registration organization codes that exceed the tolerance range, the initial verification is changed from passing to failing, and the reasons are supplemented, such as the signing device model not matching the DID registration model. Finally, the smart contract packages the judgment result (verification passing or failing), verification strictness level, details of all verification steps (including passing and failing items), and verification timestamps into the final identity verification result, and pushes it to the user terminal through the blockchain event mechanism (the terminal listens for contract events to obtain the result). At the same time, the result is written to the blockchain's evidence storage module (using a Merkle tree structure for storage to ensure immutability).

[0075] This embodiment executes verification logic based on blockchain smart contracts, ensuring that the rules for determining the verification strictness level and the signature verification standards are public, transparent, and tamper-proof, thereby enhancing the credibility of identity verification. By dynamically adjusting the strictness level through comprehensive verification parameters, it simplifies the verification process and improves efficiency in basic scenarios, while strengthening verification dimensions to ensure security in high-risk scenarios, achieving a balance between efficiency and security. By combining the technical effectiveness of digital signatures with the identity legitimacy of DID registration status, it avoids the limitations of single-dimensional verification and significantly reduces the risk of identity forgery or signature theft to pass verification. The verification process and results are stored on the blockchain, supporting subsequent traceability of the details of each verification, such as the strictness level and the reason for failure.

[0076] In a preferred embodiment of the present invention, step 6 includes:

[0077] Step 600: When the identity verification result is successful, the identity management smart contract extracts permission assessment information based on the comprehensive verification parameters. This permission assessment information includes the authentication trust level and device security status. Specifically, when the identity verification result in step 502 is successful, the identity management smart contract triggers permission assessment logic, extracting permission assessment information based on the comprehensive verification parameters (range 0-1) generated in step 403. This information includes the authentication trust level and device security status. The authentication trust level is determined by comparing the parameters with a preset range; that is, the lower the parameter value (the lower the overall risk), the higher the level. A value of 0 to 0.3 (low range) corresponds to high trust. The credibility level is determined by a score of 0.3 to 0.7 (medium range) for medium credibility and 0.7 to 1 (high range) for basic credibility, reflecting the credibility of the authentication process. The device security status is categorized based on the characteristic risk trend reflected by the parameters. When the parameter is below 0.3 (low range threshold), the device characteristics are stable and consistent with historical normal status, and it is considered safe. When it is between 0.3 and 0.7 (medium range), there are slight characteristic fluctuations but they do not reach the abnormal threshold, and it is considered to require attention. When it is between 0.7 and 1 (high range), the characteristic risk is high but it still passes verification, and it is considered to require further investigation. The smart contract packages these two pieces of information into permission assessment information and stores it in the contract's temporary data area.

[0078] Step 601: Generate access permission decisions based on permission assessment information, and determine the scope of resources allowed access and the effective time limit. Specifically, the smart contract generates access permission decisions based on the permission assessment information from step 600, specifying the scope of resources allowed access and the effective time limit. The scope of resources allowed access is matched to a preset resource list according to the authentication trust level. High trust level (parameter 0 to 0.3) corresponds to core resources (such as sensitive data storage areas) and ordinary resources (such as public information interfaces); medium trust level (parameter 0.3 to 0.7) corresponds only to ordinary resources; basic trust level (parameter 0.7 to 1) corresponds to some restricted ordinary resources (such as non-real-time data reading). When a device's security status is "Pending Verification" (parameter 0.7 to 1), highly interactive resources, such as data modification interfaces, will be further restricted within the matching range. The effective time limit is determined by combining the authentication trust level and the device's security status. That is, the time limit is longest for high trust and security (parameter 0 to 0.3); the time limit is shorter for medium trust or "Need Attention" (parameter 0.3 to 0.7) status; and the time limit is shortest for basic trust or "Pending Verification" (parameter 0.7 to 1) status, requiring re-authentication upon expiration. After the decision is generated, the smart contract records the resource scope (specific interface or data identifier) ​​and the effective time (the start time is the current verification pass time, and the end time is calculated according to the rules), forming a structured access permission decision.

[0079] Step 602 involves combining the identity verification result and access permission decision to construct an authentication transaction record, and adding a timestamp and digital signature to the authentication transaction record to form a complete blockchain transaction. Specifically, the smart contract first combines the identity verification result from step 502 (including the verification pass identifier, strictness level, and verification details) with the access permission decision from step 601 (including the resource scope and validity period) as the main content of the authentication transaction record. Then, a timestamp (taken from a trusted time source of the blockchain node, accurate to the second) is added to the record to ensure time uniqueness. Next, the smart contract's private key is used to digitally sign the entire transaction record, including the main content and timestamp. That is, a hash value of the record is generated through a hash algorithm, and the hash value is encrypted with the private key to obtain the signature data, which is appended to the end of the record. After the above processing, the complete data structure containing the main content, timestamp, and digital signature is the blockchain transaction.

[0080] Step 603 involves broadcasting the blockchain transaction to the blockchain network for distributed storage. Specifically, the smart contract broadcasts the blockchain transaction generated in step 602 to all nodes via the blockchain network's P2P communication protocol. After receiving the transaction, each node first verifies its integrity and legality, i.e., checks whether the digital signature matches the smart contract's public key (ensuring it has not been tampered with) and whether the timestamp is within a reasonable range (to prevent replay attacks). After successful verification, the transaction is temporarily stored in its local transaction pool. Subsequently, the network initiates a consensus process, where each node collectively verifies the transactions in the transaction pool using a preset consensus algorithm (such as a Byzantine fault-tolerant algorithm) to jointly confirm the validity of the transactions, including format compliance and signature legality. Finally, a consensus is reached on whether the transaction can be written to the blockchain. After reaching a consensus, the transaction is packaged into a new block and written into the block body along with other verified transactions. After the block is generated, each node synchronously updates its local blockchain ledger and adds the new block to the end of the chain, completing distributed storage. Because each node stores a complete ledger, transaction data is backed up in multiple copies, ensuring it cannot be lost or unilaterally tampered with.

[0081] This embodiment dynamically extracts permission evaluation information based on comprehensive verification parameters, matching access permissions with authentication credibility and device security status to avoid over-authorization or insufficient permissions, balancing security and availability. Through digital signatures and blockchain distributed storage, it ensures the integrity and authenticity of authentication transaction records, preventing any node from unilaterally modifying stored verification results and permission decisions. Complete transaction records include timestamps, verification details, permission scope, and other information, stored on the blockchain, supporting full-process traceability of the background, results, and authorized content of each authentication, meeting compliance requirements. The blockchain's distributed storage mechanism enables multi-node backup of transaction data; even if some nodes fail, data can still be recovered through other nodes, ensuring the long-term availability of identity authentication records.

[0082] like Figure 2 As shown, embodiments of the present invention also provide a blockchain-based distributed network identity authentication system, including:

[0083] The registration module is used by user terminals to generate decentralized identity identifiers and corresponding asymmetric cryptographic key pairs, and upload identity registration information containing decentralized identity identifiers and public keys to the blockchain identity chain to complete the registration.

[0084] The partitioning module is used to collect authentication request data sent by user terminals during the identity authentication process, extract multiple authentication feature quantities from the authentication request data, and divide the authentication strategy framework into multiple strategy execution regions based on the spatial distribution characteristics of the authentication feature quantities using a grid partitioning algorithm.

[0085] The evaluation module is used to set up an authentication evaluation unit in each policy execution area. Based on the numerical characteristics and spatial location of the authentication features, it assigns each authentication feature to the corresponding policy execution area, forming an authentication feature set for each policy execution area.

[0086] The adjustment module is used to calculate the policy adjustment coefficient based on the certification evaluation unit for each policy execution region, and generate comprehensive verification parameters through weighted fusion calculation based on the policy adjustment coefficient of each policy execution region.

[0087] The verification module is used to input comprehensive verification parameters into the identity management smart contract deployed on the blockchain, verify the digital signature of the user terminal, query the registration status of the decentralized identity identifier in the blockchain identity chain, and generate the identity verification result.

[0088] The storage module is used to generate access permission decisions based on comprehensive verification parameters when the identity verification result is successful, and then upload the identity verification result and access permission decisions to the blockchain for storage.

[0089] It should be noted that this system is a system corresponding to the above method. All implementation methods in the above method embodiments are applicable to this embodiment and can achieve the same technical effect.

[0090] Embodiments of the present invention also provide a computing device, including: a processor and a memory storing a computer program, wherein the computer program, when executed by the processor, performs the method described above. All implementations in the above method embodiments are applicable to this embodiment and can achieve the same technical effects.

[0091] Embodiments of the present invention also provide a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the method described above. All implementations in the above method embodiments are applicable to this embodiment and can achieve the same technical effects.

[0092] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A distributed network identity authentication method based on blockchain, characterized in that, The method includes: Step 1: The user terminal generates a decentralized identity identifier and a corresponding asymmetric cryptographic key pair, and uploads the identity registration information containing the decentralized identity identifier and public key to the blockchain identity chain to complete the registration; Step 2: During the identity authentication process, collect authentication request data sent by the user terminal, extract multiple authentication feature quantities from the authentication request data, and use a grid partitioning algorithm to divide the authentication strategy framework into multiple strategy execution regions based on the spatial distribution characteristics of the authentication feature quantities. Step 3: Set up an authentication evaluation unit in each policy execution area. Based on the numerical characteristics and spatial location of the authentication features, assign each authentication feature to the corresponding policy execution area to form an authentication feature set for each policy execution area. Step 4: For each policy execution region, calculate the policy adjustment coefficient based on the certification evaluation unit, and generate comprehensive verification parameters by weighted fusion calculation based on the policy adjustment coefficients of each policy execution region. Step 5: Input the comprehensive verification parameters into the identity management smart contract deployed on the blockchain, verify the digital signature of the user terminal, query the registration status of the decentralized identity identifier in the blockchain identity chain, and generate the identity verification result; Step 6: When the identity verification result is successful, the identity management smart contract generates an access permission decision based on the comprehensive verification parameters, and uploads the identity verification result and access permission decision to the blockchain for storage.

2. The blockchain-based distributed network identity authentication method according to claim 1, characterized in that, Step 2 includes: Multiple authentication features are extracted from the authentication request data, including timestamp sequences, device hardware features, and network communication features. Based on the spatial distribution characteristics of authentication features, an authentication strategy framework is constructed, and a grid partitioning algorithm is used to divide the authentication strategy framework into four strategy execution regions.

3. The blockchain-based distributed network identity authentication method according to claim 2, characterized in that, Based on the spatial distribution characteristics of authentication features, an authentication policy framework is constructed, and a grid partitioning algorithm is used to divide the authentication policy framework into four policy execution regions, including: Multiple authentication features are projected onto a two-dimensional authentication feature plane to form a set of authentication feature points. Based on the spatial distribution of the authentication feature point set, the minimum bounding rectangle of the authentication feature point set is calculated, and this minimum bounding rectangle is used as the spatial range of the authentication strategy framework. Using a grid partitioning algorithm, the spatial extent of the authentication policy framework is divided into four equal rectangular policy execution regions along the horizontal and vertical directions.

4. The blockchain-based distributed network identity authentication method according to claim 3, characterized in that, Step 3 includes: Based on the spatial density distribution of authentication features, determine the boundary coordinate range of each policy execution region; Based on the boundary coordinate range of the four policy execution regions, an authentication evaluation unit is set at the center of each policy execution region. Establish feature allocation rules, which include determining spatial allocation conditions based on the positional relationship between the spatial coordinates of the authentication feature and the coordinate range of the policy execution area, and determining numerical allocation conditions based on the matching relationship between the numerical range of the authentication feature and a preset threshold interval. According to the feature allocation rules, each authentication feature is assigned to the corresponding policy execution area. The authentication evaluation unit then aggregates the authentication features assigned to the corresponding policy execution area to form an authentication feature set for each policy execution area.

5. The blockchain-based distributed network identity authentication method according to claim 4, characterized in that, Step 4 includes: The distribution characteristics of the corresponding authentication feature set are analyzed by the authentication evaluation unit of each policy execution area, and the consistency index and dispersion of the authentication feature quantity are calculated. Based on consistency indicators and dispersion, and combined with the time series change trend of certification features, the risk assessment value of each strategy execution area is calculated. Based on the distribution density of risk assessment values ​​and certification feature quantities, a weighted average algorithm is used to calculate the policy adjustment coefficient for each policy execution region; The policy adjustment coefficients of the four policy execution regions are weighted and fused to generate comprehensive verification parameters based on the preset weight configuration.

6. The blockchain-based distributed network identity authentication method according to claim 5, characterized in that, Step 5 includes: The comprehensive verification parameters are transmitted to the identity management smart contract deployed on the blockchain. The identity management smart contract parses the comprehensive verification parameters and determines the verification strictness level of the identity verification process. The digital signature of the user terminal is verified based on the verification strictness level, and the registration status of the decentralized identity identifier in the identity chain is queried to obtain the digital signature verification result and the registration status query result. The final identity verification result is generated by combining the digital signature verification result and the registration status query result.

7. The blockchain-based distributed network identity authentication method according to claim 6, characterized in that, Step 6 includes: When the identity verification result is successful, the identity management smart contract extracts permission assessment information based on comprehensive verification parameters. The permission assessment information includes the authentication trust level and the device security status. Based on the permission assessment information, an access permission decision is generated, and the scope of resources allowed to be accessed and the effective time period are determined. The authentication result and access control decision are combined to construct an authentication transaction record, and a timestamp and digital signature are added to the authentication transaction record to form a complete blockchain transaction; Broadcast blockchain transactions to the blockchain network for distributed storage.

8. A blockchain-based distributed network identity authentication system, which implements the method as described in any one of claims 1 to 7, characterized in that, include: The registration module is used by user terminals to generate decentralized identity identifiers and corresponding asymmetric cryptographic key pairs, and upload identity registration information containing decentralized identity identifiers and public keys to the blockchain identity chain to complete the registration. The partitioning module is used to collect authentication request data sent by user terminals during the identity authentication process, extract multiple authentication feature quantities from the authentication request data, and divide the authentication strategy framework into multiple strategy execution regions based on the spatial distribution characteristics of the authentication feature quantities using a grid partitioning algorithm. The evaluation module is used to set up an authentication evaluation unit in each policy execution area. Based on the numerical characteristics and spatial location of the authentication features, it assigns each authentication feature to the corresponding policy execution area, forming an authentication feature set for each policy execution area. The adjustment module is used to calculate the policy adjustment coefficient based on the certification evaluation unit for each policy execution region, and generate comprehensive verification parameters through weighted fusion calculation based on the policy adjustment coefficient of each policy execution region. The verification module is used to input comprehensive verification parameters into the identity management smart contract deployed on the blockchain, verify the digital signature of the user terminal, query the registration status of the decentralized identity identifier in the blockchain identity chain, and generate the identity verification result. The storage module is used to generate access permission decisions based on comprehensive verification parameters when the identity verification result is successful, and then upload the identity verification result and access permission decisions to the blockchain for storage.

9. A computing device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the method as described in any one of claims 1 to 7.

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

Images