Block chain driven WAPI certificate verification method and device

Abstract

The invention provides a block chain driven WAPI certificate verification method and device, and the method comprises the steps: a device sends an authentication request containing an ID to an ASU, the ASU generates a verification result containing the ID and an SM2 signature after verifying the identity, and constructs a block chain transaction containing the result and certificate binding hash, and triggers a consensus mechanism. And after the light node captures the transaction, executing a local verification state machine, verifying SM2 signature and Hash consistency, and outputting a result to a WAPI protocol stack. According to the method, the decentralization and tampering-free characteristics of the block chain are utilized, distributed verification and trust self-management of the equipment identity are realized, the system security and reliability are enhanced, and the communication trust degree of the intelligent power grid equipment is improved.

Description

Technical Field

[0001] This application belongs to the field of blockchain certificate verification, and in particular relates to a blockchain-driven WAPI certificate verification method and apparatus. Background Technology

[0002] With the rapid integration of smart home and smart grid devices, ensuring the security and trustworthiness of communication between devices has become a critical issue. Currently, smart home technology relies on various communication protocols such as Wi-Fi, Bluetooth, and Zigbee to achieve interconnectivity between devices, bringing great convenience to home life. However, with the increase in the number of devices and the increasing complexity of communication scenarios, effectively verifying device identities and ensuring the security and immutability of communication data have become pressing technical challenges that need to be addressed.

[0003] WAPI (Wireless LAN Authentication and Privacy Infrastructure), as a security protocol for wireless LANs, provides authentication and data encryption for wireless communication devices through two parts: WAI (Wireless LAN Authentication Infrastructure) and WPI (Wireless LAN Privacy Infrastructure). WAI uses public key certificates to authenticate STAs (wireless terminals) and APs (wireless access points), ensuring that only authenticated devices can access the network. WPI uses symmetric cryptographic algorithms to encrypt transmitted service data, preventing data from being stolen or tampered with during wireless transmission.

[0004] However, traditional WAPI certificate verification relies on a centralized Certificate Authority (CA), which suffers from single points of failure and high trust costs. If the CA is attacked or malfunctions, the security of the entire system will be severely compromised. Summary of the Invention

[0005] The purpose of this application is to overcome the deficiencies in the prior art and provide a blockchain-driven WAPI certificate verification method and apparatus.

[0006] This application provides a blockchain-driven WAPI certificate verification method, including:

[0007] The authentication request device sends an authentication request to the ASU, the authentication request containing the device ID;

[0008] The ASU verifies the device identity based on the device ID and generates a verification result containing the device ID and SM2 signature;

[0009] The ASU constructs a certificate-verified blockchain transaction that includes the verification results;

[0010] The ASU generates a certificate binding hash based on the verification result;

[0011] The ASU writes the certificate binding hash into the certificate verification blockchain transaction;

[0012] The ASU triggers the blockchain consensus mechanism to reach consensus on the certificate-verified blockchain transactions.

[0013] The certificate verification light node captures the certificate-verified blockchain transactions that have passed consensus.

[0014] The certificate verification light node executes a local verification state machine, including: verifying the consistency of the SM2 signature and the certificate binding hash in the certificate verification blockchain transaction; and outputting the consistency result to the WAPI protocol stack.

[0015] Optionally, before the device sends an authentication request to the ASU, it also includes:

[0016] The device is discovered by broadcasting data packets via Bluetooth, and a pre-stored certificate is distributed to the device.

[0017] Optionally, the device is discovered via Bluetooth broadcast data packets, and a pre-stored certificate is distributed to the device.

[0018] The Bluetooth broadcast data packet contains a certificate field converted by the protocol transcoder;

[0019] The protocol transcoder converts the WAPI certificate structure into Bluetooth broadcast format.

[0020] Optionally, after the certificate verification light node captures the certificate-verified blockchain transaction that has passed consensus, it further includes:

[0021] When the blockchain's smart contract detects that the number of data requests from the device exceeds a threshold, it switches the device to the WAPI channel to transmit business data.

[0022] Optionally, verifying the consistency of the SM2 signature and the certificate binding hash in the certificate-verified blockchain transaction includes:

[0023] The access frequency of the device is monitored, and when the number of consecutive abnormal requests exceeds a preset value, the smart contract is triggered to generate a key regeneration instruction.

[0024] Optionally, after outputting the consistent result to the WAPI protocol stack, the following is also included:

[0025] The smart contract sends a key regeneration instruction to the WAPI protocol stack, and the WAPI protocol stack executes a key negotiation request based on the key regeneration instruction.

[0026] Optionally, the certificate verification light node includes:

[0027] Synchronize the local key cache with the latest session key in the blockchain consensus mechanism.

[0028] Optionally, verifying the consistency of the SM2 signature and the certificate binding hash in the certificate-verified blockchain transaction includes:

[0029] The local verification state machine calls the SM3 national cryptographic hash engine to perform hash calculation on the verification result in the certificate verification blockchain transaction, and compares the generated hash value with the certificate binding hash.

[0030] This application also provides a blockchain-driven WAPI certificate verification device, comprising:

[0031] The request module is used to send an authentication request from the verification request device to the ASU, the authentication request containing the device ID;

[0032] The verification module is used by the ASU to verify the device identity based on the device ID and generate a verification result containing the device ID and SM2 signature; the ASU constructs a certificate-verified blockchain transaction containing the verification result; the ASU generates a certificate binding hash based on the verification result; the ASU writes the certificate binding hash into the certificate-verified blockchain transaction; and the ASU triggers a blockchain consensus mechanism to reach consensus on the certificate-verified blockchain transaction.

[0033] The capture module is used by the certificate verification light node to capture the certificate-verified blockchain transactions that have passed consensus.

[0034] The local module is used by the certificate verification light node to execute the local verification state machine, including: verifying the consistency of the SM2 signature and the certificate binding hash in the certificate verification blockchain transaction; and outputting the consistency result to the WAPI protocol stack.

[0035] Optionally, before the device sends an authentication request to the ASU, the request module further includes:

[0036] The device is discovered by broadcasting data packets via Bluetooth, and a pre-stored certificate is distributed to the device.

[0037] Optionally, the device is discovered via Bluetooth broadcast data packets, and a pre-stored certificate is distributed to the device.

[0038] The Bluetooth broadcast data packet contains a certificate field converted by the protocol transcoder;

[0039] The protocol transcoder converts the WAPI certificate structure into Bluetooth broadcast format.

[0040] Optionally, after the capture module is used by the certificate verification light node to capture the certificate-verified blockchain transaction that has passed consensus, it further includes:

[0041] When the blockchain's smart contract detects that the number of data requests from the device exceeds a threshold, it switches the device to the WAPI channel to transmit business data.

[0042] Optionally, the local module is used to verify the consistency of the SM2 signature and the certificate binding hash in the certificate-verified blockchain transaction, including:

[0043] The access frequency of the device is monitored, and when the number of consecutive abnormal requests exceeds a preset value, the smart contract is triggered to generate a key regeneration instruction.

[0044] Optionally, after the local module outputs the consistency result to the WAPI protocol stack, it further includes:

[0045] The smart contract sends a key regeneration instruction to the WAPI protocol stack, and the WAPI protocol stack executes a key negotiation request based on the key regeneration instruction.

[0046] Optionally, the certificate verification light node includes:

[0047] Synchronize the local key cache with the latest session key in the blockchain consensus mechanism.

[0048] Optionally, the local module is used to verify the consistency of the SM2 signature and the certificate binding hash in the certificate-verified blockchain transaction, including:

[0049] The local verification state machine calls the SM3 national cryptographic hash engine to perform hash calculation on the verification result in the certificate verification blockchain transaction, and compares the generated hash value with the certificate binding hash.

[0050] The beneficial effects of this application are:

[0051] This application provides a blockchain-driven WAPI certificate verification method, comprising: a device sending an authentication request to an ASU, the authentication request including a device ID; the ASU verifying the device identity based on the device ID and generating a verification result including the device ID and an SM2 signature; the ASU constructing a certificate verification blockchain transaction including the verification result; the ASU generating a certificate binding hash based on the verification result; the ASU writing the certificate binding hash into the certificate verification blockchain transaction; the ASU triggering a blockchain consensus mechanism to reach consensus on the certificate verification blockchain transaction; a certificate verification light node capturing the consensus-reached certificate verification blockchain transaction; and the certificate verification light node executing a local verification state machine, including: verifying the consistency of the SM2 signature and the certificate binding hash in the certificate verification blockchain transaction; and outputting the consistency result to the WAPI protocol stack. This application integrates blockchain technology into the WAPI certificate verification process, leveraging the decentralized and immutable characteristics of blockchain to achieve distributed verification and trust self-management of device identities, reducing reliance on centralized CAs and enhancing system security and reliability. At the same time, the transparency and traceability of blockchain also ensure the security auditing of communication data, thereby improving the overall security and trustworthiness of smart grid device communication. Attached Figure Description

[0052] Figure 1 This is a schematic diagram of the blockchain-driven WAPI certificate verification process in this application;

[0053] Figure 2 This is a schematic diagram of the overall WAPI framework in this application;

[0054] Figure 3 This is a schematic diagram of the WAPI certificate in this application;

[0055] Figure 4 This is a schematic diagram of WAI secure access in this application;

[0056] Figure 5 This is a schematic diagram illustrating the WAI certificate authentication process in this application;

[0057] Figure 6 This is a schematic diagram of WAI session key negotiation in this application;

[0058] Figure 7 This is a schematic diagram of the WPI packaging structure in this application;

[0059] Figure 8 This is a schematic diagram of the decentralized trust network in this application. Detailed Implementation

[0060] 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 is to be understood that various forms of implementation of the present disclosure are intended and should not be limited to the embodiments set forth herein. Rather, the 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.

[0061] Please refer to Figure 2 As shown, WAI session key negotiation, including the key negotiation phase, uses the base key BK calculated during the identity authentication process to achieve the negotiation. The specific negotiation process is as follows:

[0062] 1. Key negotiation request.

[0063] The AP sends a data packet to the STA, AP→STA: (BKID, N1).

[0064] After the AP completes the authentication of the STA certificate and both ends generate their respective base keys BK, the AP first needs to generate a random number NAP consisting of 32 octets. Then, the AP sends the BK identifier BKID negotiated during the certificate negotiation phase as a key negotiation request packet to the STA.

[0065] The BKID is calculated as follows:

[0066] BKID=KD-HMAC-SHA256(BK,MAC STA MAC AP )

[0067] Among them, MAC STA and MAC AP These represent the physical addresses of the STA and AP, respectively.

[0068] 2. Key negotiation response.

[0069] The STA transmits this data packet to the AP, STA→AP: (BKID, N1, N2, HMAC-SHA256(MAK, BKID|N1|N2)).

[0070] After the data transmitted from the AP is sent to the STA, the STA needs to process it according to the following steps:

[0071] (a) Verify whether BKID is consistent with the locally calculated value. If they are consistent, proceed to step (b).

[0072] (b) STA generates a random number N2;

[0073] (c) via KD-HMAC-SHA256(BK, N1|N2|MAC) STA MACAP The key expansion process derives a 48-octet session key. The first 16 octets are the encryption key, the next 16 octets are the integrity verification key, and the remaining 16 octets are the message authentication key (MAK) used by WAI.

[0074] Afterwards, the STA sends the base key BK, random number N1, random number N2, and message authentication code calculated using HMAC-SHA256 with the previously generated MAK as the content of this packet to the AP. At this point, the ASU does not need to wait for the AP's response, and the ASU's function has been completed.

[0075] 3. Key negotiation confirmation.

[0076] AP sends this data packet to STA, AP→STA: (BKID, N2, HMAC-SHA256(MAK, BKID|N2)).

[0077] After the data sent by the STA is transmitted to the AP, the AP must process it according to the following steps:

[0078] (a) Verify that BKID is the same as the value you calculated. If they are the same, proceed to step (b).

[0079] (b) Verify whether the values ​​of N1, N2, and the locally stored random number are the same. If they are the same, proceed to step (c).

[0080] (c) via KD-HMAC-SHA256(BK, N1|N2|MAC) STA MAC AP Perform key expansion calculations. Derive a 48-octet session key. The first 16 octets are the encryption key, the next 16 octets are the integrity verification key, and the last 16 octets are the Message Authentication Key (MAK) used by WAI.

[0081] (d) Using the previously generated MAK, calculate the message authentication code using HMAC-SHA256, compare the generated result with the MAK in the data sent by the STA, and if they match, proceed to (e).

[0082] (e) The AP uses HMAC-SHA256 to calculate the message authentication code using the base key BK, the random number N2, and the previously generated MAK, and sends the above data as the content of this packet to the STA.

[0083] After the STA receives the data packet information from the AP, it needs to perform the following processing steps:

[0084] (a) Verify whether the received BKID is consistent with the value you calculated. If they are consistent, proceed to step (b).

[0085] (b) Verify whether N2 is consistent with the value of the random number generated during the identity authentication stage. If they are consistent, proceed to step (c).

[0086] (c) Compare the received message authentication code with the value calculated using the HMAC-SHA256 algorithm with MAK. If they match, the key negotiation process between STA and AP ends, and STA and AP obtain the same encryption key and integrity verification key.

[0087] Please refer to Figures 1 to 8 As shown, this application provides a blockchain-driven WAPI certificate verification method and apparatus, implemented under the WAPI protocol framework, involving a device (as an authentication requester entity ASUE, such as a smart home device), an authentication service unit ASU (power company or a trusted third-party institution), and a blockchain system.

[0088] The device sends an authentication request to ASU via the WAPI protocol;

[0089] After ASU verifies the device's identity, it generates a verification result and constructs a blockchain transaction.

[0090] After the certificate verification light node captures the transaction, it performs local verification and outputs the result to the WAPI protocol stack.

[0091] Blockchain is used to enhance data integrity and decentralized trust, while smart contracts are used to automate policy execution (such as key updates).

[0092] This application discloses a blockchain-driven WAPI certificate verification method and apparatus, comprising:

[0093] S101: The authentication request device sends an authentication request to the ASU, the authentication request containing the device ID;

[0094] The device (such as a smart home device, acting as an ASUE) sends an authentication request to the ASU.

[0095] The device ID is a unique identifier for the device, such as a MAC address or IMEI number. This identifier is defined based on the WAPI certificate format (X.509v3).

[0096] In the WAPI certificate authentication process, the device indirectly sends a request to the ASU through the access point (AP): the device first generates a temporary public-private key pair and a random number, and sends the device ID (embedded in the certificate) as the request content to the AP;

[0097] AP then forwards it to ASU.

[0098] The authentication request format is: the device sends a data packet containing a random number N. STA Temporary public key x·G, device certificate Cert STA and Sign STA (N STA |x·G|Cert STA The device ID is implicit in Cert. STA middle.

[0099] S102: The ASU verifies the device identity based on the device ID and generates a verification result containing the device ID and SM2 signature;

[0100] After receiving the authentication request, ASU verifies the device identity based on the device ID (extracted from the device certificate). The verification process includes checking the certificate's validity (such as version number, serial number, and validity period).

[0101] Upon successful verification, ASU generates a verification result, which includes the device ID and ASU's SM2 signature. The signature uses the SM2 algorithm (Elliptic Curve Digital Signature) to ensure immutability.

[0102] The verification result format is as follows:

[0103] Cert STA |Authentication-Result STA |Cert AP |Authentication-Result AP |N AP |Sign ASU

[0104] Sign ASU Sign the SM2.

[0105] S103: The ASU constructs a certificate-verified blockchain transaction that includes the verification result;

[0106] ASU constructs the generated verification results as "certificate-verified blockchain transactions".

[0107] Blockchain transactions are implemented based on the Hyperledger Fabric framework. Transaction content includes verification results (device ID, verification status, SM2 signature, etc.), which serve as the transaction data payload.

[0108] The construction process is initiated by ASU, which creates a transaction request through the blockchain SDK and submits it to the endorsing node (En dorser) for initial processing. The transaction type is "certificate verification," specifically used to record device authentication events.

[0109] S104: The ASU generates a certificate binding hash based on the verification result;

[0110] ASU generates a "certificate binding hash" based on the verification results, using the SM3 national cryptographic hash algorithm.

[0111] SM3 converts the verification results (including device ID and verification status) into a fixed-length (256-bit) hash value for data integrity verification. The generation process is as follows: ASU calls the SM3 engine to perform hash calculation on the verification results and generate a unique hash value.

[0112] S105: The ASU writes the certificate binding hash into the certificate verification blockchain transaction.

[0113] ASU binds the generated certificate to a hash and writes it into the constructed blockchain transaction. The hash value, as part of the transaction metadata, is written into the transaction payload to ensure the transaction content is immutable. The write operation is completed on the ASU side, implemented through the blockchain SDK.

[0114] S106: The ASU triggers the blockchain consensus mechanism to reach a consensus on the certificate-verified blockchain transaction.

[0115] ASU triggers the blockchain consensus mechanism to process the transaction. The process includes: (a) the transaction is submitted to the ordering node for sorting; (b) after sorting the transactions, the ordering node shares the block information with other nodes; (c) other nodes verify the legality of the transaction (e.g., by checking the hash and signature), and upon successful verification, synchronize it to their local blockchain. The consensus mechanism ensures the consistency and immutability of transactions across the entire network. The triggering method is that ASU calls the consensus interface via its SDK.

[0116] S107: Certificate-verified light nodes capture consensus-verified blockchain transactions.

[0117] Certificate-verified light nodes (such as lightweight blockchain nodes integrated into smart meters or WAPI access points) capture consensus-reached blockchain transactions. Light nodes subscribe to the blockchain network and listen for new blocks in real time; once consensus is reached on a block containing a certificate-verified transaction, the light node retrieves that transaction from the blockchain.

[0118] S108: The certificate verification light node executes a local verification state machine, including: verifying the consistency of the SM2 signature and the certificate binding hash in the certificate verification blockchain transaction; and outputting the consistency result to the WAPI protocol stack.

[0119] The light node executes the local verification state machine, and the process includes:

[0120] (a) Verify the consistency of SM2 signature and certificate binding hash: Use the SM2 algorithm to verify the validity of the ASU signature in the transaction. At the same time, verify the consistency of the certificate binding hash: Call the SM3 national cryptographic hash engine to recalculate the hash value of the verification result in the transaction, and compare the generated hash value with the certificate binding hash written in the transaction.

[0121] (b) Output consistency result: If the signature and hash are consistent, output "Verification passed"; otherwise, output "Verification failed". The result is output to the WAPI protocol stack.

[0122] WPI encapsulation and decapsulation, including:

[0123] (1) The block size occupied by the session key index is 1.

[0124] (2) The group size occupied by the reserved field is 3, which is usually recorded as 0.

[0125] (3) The group size occupied by the group number is 16.

[0126] (4) The PDU field is the information obtained by encrypting the MPDU. During encryption, the block number is used as the IV (initialization vector) to calculate the ciphertext data.

[0127] (5) The MIC field occupies a block size of 16, and its value is calculated using the integrity check ciphertext generated during the WAI phase. The block number is used as the IV.

[0128] When sending data, WPI's encapsulation process is as follows:

[0129] (1) First, use the encryption key and block sequence number negotiated by WAI to encrypt the MPDU data, and calculate the encrypted MPDU data.

[0130] (2) Use the integrity verification key and packet sequence number generated in the WAI phase to encrypt other data in the packet, generate MIC, and send the above data as a packet.

[0131] When receiving information, WPI's decapsulation steps are as follows:

[0132] (1) First, it is necessary to verify whether the group number of the information is correct. If it is incorrect, the group needs to be discarded.

[0133] (2) Use the integrity verification key and group sequence number generated in the WAI phase to generate MIC. Compare the calculated MIC with the received information. If they do not match, the data needs to be discarded. If they match, then execute (3).

[0134] (3) Use the encryption key generated in WAI to decrypt the received data and calculate the original data.

[0135] Blockchain technology builds decentralized trust networks:

[0136] Treating data transmission between smart meters and smart homes as a transaction allows blockchain technology to be applied to data transmission. The following section explains in detail how blockchain technology can be used to achieve decentralized and tamper-proof data transmission from smart meters.

[0137] (1) Transaction request initiation:

[0138] Smart home devices, acting as user terminals, can initiate data transfer transaction requests using the API of the Fabric SDK, written in Go. The client then submits this request to the corresponding endorser node. For example, when a smart appliance needs to obtain electricity usage data from a smart meter, it submits a request in this way.

[0139] (2) Endorsement node processing:

[0140] In the Fabric network, endorsing nodes process transaction requests from smart home devices. First, the endorsing node verifies the legitimacy of the transaction request, such as checking if the device is authorized and if the request conforms to preset rules. Then, it simulates the execution of the transaction, which involves simulating access to smart meter data. If the transaction is valid, the endorsing node will include the transaction result and a verified signature authenticated by the endorsing node in its response; if the transaction is invalid, it will return an error message.

[0141] (3) Transactions are recorded on the blockchain:

[0142] Transaction requests verified by endorsing nodes are submitted to the block, executed, and recorded on the blockchain. In smart meter and smart home data transmission scenarios, these records ensure the immutability and traceability of data transmission-related transactions.

[0143] (4) Ranking and consensus:

[0144] The updated block record and digest are submitted to the sorting nodes. The sorting nodes sort the blocks and then share the sorted block information with other nodes. This process ensures the consistency and accuracy of the data transmission transaction order.

[0145] (5) Verification and synchronization:

[0146] After receiving the block information from the sorting node, other nodes first verify it to confirm its correctness and legitimacy. Taking other relevant nodes in the network where smart meters and smart home devices reside as an example, after successful verification, the block is submitted to the local blockchain, and other nodes are notified to synchronize the block and its transaction information. If the verification fails, the block will be rejected from being added to the blockchain.

[0147] (6) Transaction Confirmation:

[0148] Once a transaction request is authenticated and recorded by the blockchain, it is recognized as a valid transaction request. In smart meter and smart home data transmission solutions, this means that the data transmission transaction has been successfully completed, and the transmission and access of related data are effectively protected by the blockchain.

[0149] Application of smart contract technology in this application:

[0150] In this application, by leveraging smart contracts on a blockchain platform, it is effectively ensured that smart home devices can only read electricity consumption data from smart meters, while the power company has the authority to analyze and process this data. The detailed deployment steps and principles are as follows:

[0151] Define roles and permissions:

[0152] As the applicant entity within the authentication requester, the smart home device is only granted permission to read smart meter electricity consumption data. During network access and data acquisition, it must strictly adhere to the rules set by the smart contract. Within the system, the power company can be analogous to an entity with higher privileges, possessing the authority to analyze and process smart meter electricity consumption data. The power company can then leverage this data for in-depth business operations, such as developing reasonable electricity pricing strategies and forecasting electricity demand.

[0153] Smart contract writing:

[0154] Data read restrictions: The smart contract will explicitly stipulate that only authorized smart home devices can read electricity data from the storage address corresponding to the smart meter. In practice, the contract code will set conditional checks, such as allowing the read operation only if the address of the device requesting the data is within a pre-defined whitelist.

[0155] Power company access permissions: The smart contract grants the power company specific permissions to call contract functions, enabling it to analyze and process the electricity consumption data it receives. For example, the power company can call data analysis functions within the contract to perform statistical analysis and forecasting on the collected electricity consumption data. These functions will conduct in-depth data mining based on preset algorithms and rules, providing support for the power company's decision-making.

[0156] Deploying smart contracts:

[0157] The written smart contracts are deployed to a suitable blockchain platform. Blockchain's decentralized and immutable nature ensures the execution of smart contracts and the security of data. Once deployed, the smart contracts will run automatically, monitoring and managing the operations of smart home devices and power companies.

[0158] Equipment and system integration:

[0159] When a smart home device connects to a network (WLAN), it authenticates itself by interacting with an authenticator system (such as a smart meter acting as the authenticator). The authentication process follows the rules of the WAPI framework to ensure the legitimacy of the device's identity. After successful authentication, the smart home device reads the smart meter's electricity usage data through the corresponding interface, according to the smart contract rules. During data reading, the device sends a request to a blockchain node, which determines whether to allow the device to read the data based on the smart contract's judgment.

[0160] The power company's system interacts with authentication service units to obtain legitimate authorization before invoking permitted analysis and processing functions in the smart contract to manipulate electricity consumption data. During data analysis and processing, the power company's operation records are stored on the blockchain to ensure traceability and transparency.

[0161] Security and Auditing:

[0162] To prevent data leaks, encryption technology is used to encrypt data during transmission and data stored on the blockchain. Simultaneously, smart contracts undergo regular security audits to check for vulnerabilities or risks of tampering. Professional security auditing tools and techniques can be used to comprehensively examine the code of smart contracts, promptly identifying and fixing potential security vulnerabilities.

[0163] Establish audit logs to record information such as smart contract calls and data access records. These audit logs will be stored on the blockchain for traceability and troubleshooting when needed. By analyzing the audit logs, abnormal operations and potential security threats can be detected in a timely manner, ensuring the stable operation of the system.

[0164] This application also provides a blockchain-driven WAPI certificate verification device, comprising:

[0165] The request module is used to send an authentication request from the verification request device to the ASU, the authentication request containing the device ID;

[0166] The verification module is used by the ASU to verify the device identity based on the device ID and generate a verification result containing the device ID and SM2 signature; the ASU constructs a certificate-verified blockchain transaction containing the verification result; the ASU generates a certificate binding hash based on the verification result; the ASU writes the certificate binding hash into the certificate-verified blockchain transaction; and the ASU triggers a blockchain consensus mechanism to reach consensus on the certificate-verified blockchain transaction.

[0167] The capture module is used by the certificate verification light node to capture the certificate-verified blockchain transactions that have passed consensus.

[0168] The local module is used by the certificate verification light node to execute the local verification state machine, including: verifying the consistency of the SM2 signature and the certificate binding hash in the certificate verification blockchain transaction; and outputting the consistency result to the WAPI protocol stack.

[0169] Optionally, before the device sends an authentication request to the ASU, the request module further includes:

[0170] The device is discovered by broadcasting data packets via Bluetooth, and a pre-stored certificate is distributed to the device.

[0171] Optionally, the device is discovered via Bluetooth broadcast data packets, and a pre-stored certificate is distributed to the device.

[0172] The Bluetooth broadcast data packet contains a certificate field converted by the protocol transcoder;

[0173] The protocol transcoder converts the WAPI certificate structure into Bluetooth broadcast format.

[0174] Optionally, after the capture module is used by the certificate verification light node to capture the certificate-verified blockchain transaction that has passed consensus, it further includes:

[0175] When the blockchain's smart contract detects that the number of data requests from the device exceeds a threshold, it switches the device to the WAPI channel to transmit business data.

[0176] Optionally, the local module is used to verify the consistency of the SM2 signature and the certificate binding hash in the certificate-verified blockchain transaction, including:

[0177] The access frequency of the device is monitored, and when the number of consecutive abnormal requests exceeds a preset value, the smart contract is triggered to generate a key regeneration instruction.

[0178] Optionally, after the local module outputs the consistency result to the WAPI protocol stack, it further includes:

[0179] The smart contract sends a key regeneration instruction to the WAPI protocol stack, and the WAPI protocol stack executes a key negotiation request based on the key regeneration instruction.

[0180] Optionally, the certificate verification light node includes:

[0181] Synchronize the local key cache with the latest session key in the blockchain consensus mechanism.

[0182] Optionally, the local module is used to verify the consistency of the SM2 signature and the certificate binding hash in the certificate-verified blockchain transaction, including:

[0183] The local verification state machine calls the SM3 national cryptographic hash engine to perform hash calculation on the verification result in the certificate verification blockchain transaction, and compares the generated hash value with the certificate binding hash.

[0184] The above description of the embodiments is provided to enable those skilled in the art to understand and apply this application. Those skilled in the art will readily make various modifications to the above embodiments and apply the general principles described herein to other embodiments without inventive effort. Therefore, this application is not limited to the above embodiments, and any improvements and modifications made to this application based on the disclosure thereof should be within the scope of protection of this application.

Claims

1. A blockchain-driven WAPI certificate verification method, characterized in that, include: The authentication request device sends an authentication request to the ASU, the authentication request containing the device ID; The ASU verifies the device identity based on the device ID and generates a verification result containing the device ID and SM2 signature; The ASU constructs a certificate-verified blockchain transaction that includes the verification results; The ASU generates a certificate binding hash based on the verification result; The ASU writes the certificate binding hash into the certificate verification blockchain transaction; The ASU triggers the blockchain consensus mechanism to reach consensus on the certificate-verified blockchain transactions. The certificate verification light node captures the certificate-verified blockchain transactions that have passed consensus. The certificate verification light node executes a local verification state machine, including: verifying the consistency of the SM2 signature and the certificate binding hash in the certificate verification blockchain transaction; Output consistent results to the WAPI protocol stack.

2. The blockchain-driven WAPI certificate verification method according to claim 1, characterized in that, Before the authentication request device sends the authentication request to the ASU, it also includes: The device is discovered by broadcasting data packets via Bluetooth, and a pre-stored certificate is distributed to the device.

3. The blockchain-driven WAPI certificate verification method according to claim 2, characterized in that, The device is discovered via Bluetooth broadcast data packets, and a pre-stored certificate is distributed to the device. The Bluetooth broadcast data packet contains a certificate field converted by the protocol transcoder; The protocol transcoder converts the WAPI certificate structure into Bluetooth broadcast format.

4. The blockchain-driven WAPI certificate verification method according to claim 1, characterized in that, After the certificate verification light node captures the certificate-verified blockchain transaction that has passed consensus, it also includes: When the blockchain's smart contract detects that the number of data requests from the device exceeds a threshold, it switches the device to the WAPI channel to transmit business data.

5. The blockchain-driven WAPI certificate verification method according to claim 1, characterized in that, Verifying the consistency of the SM2 signature and the certificate binding hash in the certificate-verified blockchain transaction includes: The access frequency of the device is monitored, and when the number of consecutive abnormal requests exceeds a preset value, the smart contract is triggered to generate a key regeneration instruction.

6. The blockchain-driven WAPI certificate verification method according to claim 5, characterized in that, After outputting the consistent results to the WAPI protocol stack, the following is also included: The smart contract sends a key regeneration instruction to the WAPI protocol stack, and the WAPI protocol stack executes a key negotiation request based on the key regeneration instruction.

7. The blockchain-driven WAPI certificate verification method according to claim 1, characterized in that, The certificate verification light node includes: Synchronize the local key cache with the latest session key in the blockchain consensus mechanism.

8. The blockchain-driven WAPI certificate verification method according to claim 1, characterized in that, Verifying the consistency of the SM2 signature and the certificate binding hash in the certificate-verified blockchain transaction includes: The local verification state machine calls the SM3 national cryptographic hash engine to perform hash calculation on the verification result in the certificate verification blockchain transaction, and compares the generated hash value with the certificate binding hash.

9. A blockchain-driven WAPI certificate verification device, characterized in that, include: The request module is used to send an authentication request from the verification request device to the ASU, the authentication request containing the device ID; The verification module is used by the ASU to verify the device identity based on the device ID and generate a verification result containing the device ID and SM2 signature; The ASU constructs a certificate-verified blockchain transaction containing the verification result; the ASU generates a certificate binding hash based on the verification result; the ASU writes the certificate binding hash into the certificate-verified blockchain transaction; the ASU triggers the blockchain consensus mechanism to reach consensus on the certificate-verified blockchain transaction. The capture module is used by the certificate verification light node to capture the certificate-verified blockchain transactions that have passed consensus. The local module is used by the certificate verification light node to execute the local verification state machine, including: verifying the consistency of the SM2 signature and the certificate binding hash in the certificate verification blockchain transaction; Output consistent results to the WAPI protocol stack.

10. A blockchain-driven WAPI certificate verification device according to claim 9, characterized in that, The request module, used before the device sends an authentication request to the ASU, also includes: The device is discovered by broadcasting data packets via Bluetooth, and a pre-stored certificate is distributed to the device.

11. A blockchain-driven WAPI certificate verification device according to claim 10, characterized in that, The device is discovered via Bluetooth broadcast data packets, and a pre-stored certificate is distributed to the device, wherein: The Bluetooth broadcast data packet contains a certificate field converted by the protocol transcoder; The protocol transcoder converts the WAPI certificate structure into Bluetooth broadcast format.

12. A blockchain-driven WAPI certificate verification device according to claim 9, characterized in that, The capture module, used by the certificate verification light node to capture the certificate-verified blockchain transaction after consensus, also includes: When the blockchain's smart contract detects that the number of data requests from the device exceeds a threshold, it switches the device to the WAPI channel to transmit business data.

13. A blockchain-driven WAPI certificate verification device according to claim 9, characterized in that, The local module is used to verify the consistency of the SM2 signature and the certificate binding hash in the certificate-verified blockchain transaction, including: The access frequency of the device is monitored, and when the number of consecutive abnormal requests exceeds a preset value, the smart contract is triggered to generate a key regeneration instruction.

14. A blockchain-driven WAPI certificate verification device according to claim 13, characterized in that, After the local module outputs the consistent result to the WAPI protocol stack, it also includes: The smart contract sends a key regeneration instruction to the WAPI protocol stack, and the WAPI protocol stack executes a key negotiation request based on the key regeneration instruction.

15. A blockchain-driven WAPI certificate verification device according to claim 9, characterized in that, The certificate verification light node includes: Synchronize the local key cache with the latest session key in the blockchain consensus mechanism.

16. A blockchain-driven WAPI certificate verification device according to claim 9, characterized in that, The local module is used to verify the consistency of the SM2 signature and the certificate binding hash in the certificate-verified blockchain transaction, including: The local verification state machine calls the SM3 national cryptographic hash engine to perform hash calculation on the verification result in the certificate verification blockchain transaction, and compares the generated hash value with the certificate binding hash.

Images