Method and equipment for detecting security of wireless network

Abstract

The invention relates to the technical field of wireless networks, in particular to a method for detecting safety of a wireless network, which comprises the following steps of: capturing wireless communication flow of a frequency band in real time through a hardware module of a radio product, and extracting four-time interaction data in a WPA3-SAE handshake process; handshake processes of all frequency bands are compared, the consistency of hardware generation logic is verified, the uniqueness and hash matching of random numbers are detected, the number of handshake failures is counted, and when the number exceeds a dynamic threshold value, it is judged that the attack is a potential attack; if it is detected that the 6GHz frequency band uses the WPA2 authentication mode, triggering an alarm and forbidding communication of the frequency band; and if any rule is violated, determining that the risk is abnormal, and outputting a corresponding risk score. And the system dynamically adjusts a defense strategy according to the score: refreshing a PMK or forbidding a frequency band when the risk is high, performing protocol compatibility negotiation when the risk is medium, and only recording a log when the risk is low. According to the invention, efficient real-time monitoring of the wireless network equipment can be realized.

Description

Technical Field

[0001] The present application relates to the technical field of wireless networks, and more particularly to a method and device for detecting wireless network security. Background Art

[0002] Current wireless network devices widely support multi-band communications (such as 2.4GHz, 5GHz, and 6GHz), but existing security detection solutions mostly rely on statistical indicators or empirical rules for risk assessment, which has obvious shortcomings: on the one hand, it is difficult to directly verify the details of the protocol implementation, resulting in limited ability to identify protocol layer attacks; on the other hand, faced with signal interference, device roaming, and compatibility issues in multi-band environments (such as incorrectly enabling WPA2 mode in the 6GHz band), existing solutions mostly use static threshold judgments, which have a high false alarm rate and cannot dynamically adapt to network changes.

[0003] In addition, some technologies rely on machine learning models for predictions, but model training requires a large amount of labeled data, and the ability to generalize to new types of attacks is insufficient, making it difficult to meet real-time requirements; at the same time, to address protocol compatibility issues, existing solutions mostly rely on post-log analysis or manual verification, and lack real-time monitoring and automatic defense mechanisms.

[0004] From the above, we can see that how to achieve efficient real-time monitoring of wireless network devices still needs to be solved. Summary of the Invention

[0005] In order to achieve efficient real-time monitoring of wireless network devices, the present application provides a method and device for detecting wireless network security.

[0006] In a first aspect, the present application provides a method for detecting wireless network security, which adopts the following technical solution: A method for detecting wireless network security, comprising: The radio product's hardware module captures wireless communication traffic in the 2.4GHz, 5GHz, and 6GHz bands in real time, performs protocol parsing on the traffic, and extracts the four-step WPA3SAE handshake data from devices in each band. This data includes the Commit message, Confirm message, PMK generation parameters, and hash checksum. Compare the SAE handshake processes for each frequency band to verify the consistency of the hardware generation logic. This includes determining whether the hardware random number is unique and whether the Confirm hash value matches. Count the number of handshake failures in each frequency band. If the number of handshake failures in any frequency band exceeds a preset dynamic threshold, it is identified as a potential attack. Detect whether abnormal frames in WPA2 authentication mode appear in the 6GHz band and trigger an alarm if detected. When an abnormal number of handshake failures is detected, the radio product's hardware module automatically sends a deauthentication frame, forcibly disconnecting the target device and triggering a re-handshake process. If an abnormal frame in WPA2 compatibility mode is detected on the 6GHz band, the wireless communication function of the 6GHz band is immediately disabled through the hardware interface configuration. Hard rules are defined based on the SAE handshake protocol specification supported by the radio product hardware. These include: the Commit message must contain a unique, hardware-generated random number that cannot be repeated; the hash value of the Confirm message must be consistent with the hardware parameters during the Commit phase; and PMK generation must be based on a hardware-level dynamic key exchange algorithm. Violations of any of these rules are considered protocol implementation flaws or attacks, and a corresponding risk score is output, with the risk score corresponding to high, medium, or low risk. Dynamically adjust defense strategies based on risk scores: If the risk is high, prioritize refreshing the PMK or disabling high-risk frequency bands through the hardware key management module; if the risk is medium, verify device protocol compatibility through firmware-level capability negotiation requests; if the risk is low, only record abnormal events and defense action logs through the hardware logger.

[0007] By implementing this technical solution, the radio product's hardware module captures multi-band (2.4GHz / 5GHz / 6GHz) wireless traffic in real time, parses WPA3-SAE handshake protocol data, verifies the hardware generation logic (such as random number uniqueness and hash value matching), and uses dynamic thresholds to detect handshake failures and abnormal frames. When the risk is high, the connection is automatically disconnected or the key is refreshed; when the risk is medium, protocol compatibility is negotiated; when the risk is low, logs are recorded, thus achieving efficient real-time monitoring and adaptive security protection.

[0008] Optionally, the cross-band protocol consistency check module further includes: By comparing the hardware protocol version fields of radio products in different frequency bands, if inconsistent protocol versions are detected for at least two frequency bands, a protocol version conflict event is marked; Generate a frequency band isolation policy based on protocol version conflict events: add the frequency band with protocol version conflicts to the hardware blacklist, prohibiting devices from initiating new handshakes on the frequency band with protocol version conflicts; send a hardware-level WPA3-SAE capability negotiation request to the target device. If the device fails to respond, a deauthentication frame is triggered and the protocol downgrade risk is recorded.

[0009] By using this technical solution, the hardware protocol version fields of radio products in different frequency bands are compared, protocol version conflicts are detected and marked, and a frequency band isolation policy is generated. The conflicting frequency bands are added to the hardware blacklist to block new handshake requests. Simultaneously, a hardware-level WPA3-SAE capability negotiation request is sent to verify device compatibility. If the response fails, a deauthentication frame is triggered and the protocol downgrade risk is recorded. This effectively prevents security vulnerabilities and potential attacks caused by protocol inconsistencies, and improves the security and stability of cross-band communications.

[0010] Optionally, the frequency band isolation strategy also includes: Write the MAC address and band identifier of the conflicting frequency band into the hardware blacklist storage unit of the radio product; When a device is detected to initiate a new SAE handshake request on a blacklisted frequency band, the hardware module automatically discards the new SAE handshake request and records the interception log; If it is subsequently detected that the device successfully completes the WPA3-SAE handshake on the blacklisted frequency band, the blacklist mark of the conflicting frequency band is automatically removed.

[0011] By implementing this technical solution, the MAC address and band ID of the conflicting frequency band are added to the hardware blacklist. This allows the radio product to automatically discard new handshake requests from the blacklisted frequency band and log them. If the device subsequently successfully completes the WPA3-SAE handshake, the blacklist ID is automatically removed, effectively preventing unsafe connections and improving system security and resource efficiency.

[0012] Optionally, the method further comprises: Based on the logs of frequency band isolation actions and protocol version conflict events captured by hardware, timestamp correlation analysis is used to identify whether attackers are carrying out coordinated attacks across multiple frequency bands. Coordinated attacks include attackers inducing device downgrade in the 6GHz band and then switching to the 2.4GHz band. Hardware isolation strategies are dynamically optimized based on the correlation analysis results. Hardware isolation strategies include strengthening monitoring of specific frequency bands or expanding the isolation range.

[0013] By employing this technical solution, hardware-captured band isolation actions and protocol version conflict events are analyzed through timestamp correlation, identifying coordinated multi-band attacks (such as induced downgrade of the 6 GHz band followed by switching to 2.4 GHz). Based on this analysis, hardware isolation strategies are dynamically optimized, such as strengthening monitoring of specific bands or expanding the isolation range, effectively preventing cross-band attacks and improving system security.

[0014] Optionally, the method further includes a defect detection step based on protocol analysis: The radio product's hardware parsing module performs field-level parsing on the SAE handshake frame sent by the target device, extracting the hardware random number in the Commit message, the hash value of the Confirm message, and the PMK generation parameters. If the Commit message is missing or contains duplicate hardware random numbers, it is considered a protocol implementation flaw. If the hash value of the Confirm message is inconsistent with the Commit phase parameters, it is considered a hardware protocol implementation flaw. According to the hardware protocol, the defects are matched with the preset risk scoring library and the corresponding risk level is output.

[0015] By implementing this technical solution, the radio product's hardware parsing module performs field-level parsing of SAE handshake frames, detecting whether the hardware random number in the Commit message is missing or duplicated, and whether the hash value of the Confirm message is consistent with the Commit phase parameters. If a flaw is found, the system outputs a risk level based on a pre-defined risk scoring library, enabling timely identification and resolution of protocol implementation flaws, thereby enhancing system security.

[0016] Optionally, the dynamic threshold adjustment further includes: Calculate baseline thresholds based on the historical handshake failure counts of the radio product hardware in each frequency band; When it is detected that the number of handshake failures of a device in a specific frequency band continuously exceeds the baseline threshold of the preset window time, the hardware logic automatically adjusts the upper limit of the dynamic threshold of the specific frequency band; If the alarm continues to be triggered after the dynamic threshold is adjusted, it will be marked as an abnormal mode and pushed to the security management platform. At the same time, a deauthentication frame will be sent to the target device through the hardware interface and the abnormal log will be recorded.

[0017] By adopting this technical solution, a baseline threshold is calculated by analyzing the historical number of handshake failures in each frequency band. When a specific frequency band continuously exceeds the baseline threshold, the hardware automatically adjusts the upper limit of the dynamic threshold. If the alarm persists, it is marked as an abnormal mode and pushed to the security management platform. Deauthentication frames are sent through the hardware interface and logs are recorded, ensuring timely detection and response to potential attacks, thereby improving system security.

[0018] Optionally, the method further comprises: The strategy is driven by the corresponding risk score: if the risk score is high, the hardware module immediately triggers a deauthentication frame and blocks the current frequency band connection, while forcing the hardware key to refresh; if the risk score is medium, a WPA3-SAE capability negotiation request is sent to the target device and observation logs are recorded; if the risk score is low, only logs are recorded and continuous monitoring is carried out; If a device is detected triggering a high-risk event in the 6GHz band, the handshake verification frequency will be increased in the 2.4GHz and 5GHz bands simultaneously.

[0019] By employing this technical solution, based on risk scores, the hardware module immediately triggers a deauthentication frame and refreshes the key when the risk is high. When the risk is medium, the module sends a WPA3-SAE capability negotiation request and logs it. When the risk is low, the module simply logs and continuously monitors the situation. If a high-risk event occurs on the 6GHz band, the handshake verification frequency on the 2.4GHz and 5GHz bands is increased simultaneously, ensuring a rapid response and preventing potential threats, thereby improving overall system security.

[0020] In a second aspect, the present application provides a device for detecting wireless network security, which adopts the following technical solution: A device for detecting wireless network security, comprising: The four-pass data extraction module uses the radio product's hardware module to capture wireless communication traffic in the 2.4GHz, 5GHz, and 6GHz bands in real time, performs protocol analysis on the wireless communication traffic, and extracts the four-pass handshake data of the devices executing the WPA3SAE handshake protocol in each frequency band. The four-pass data includes the Commit message, Confirm message, PMK generation parameters, and hash check value. The consistency verification module compares the SAE handshake processes of each frequency band to verify the consistency of the hardware generation logic. The verification process includes determining whether the hardware random number is unique and whether the confirm hash value matches. It also counts the number of handshake failures in each frequency band. If the number of handshake failures in any frequency band exceeds the preset dynamic threshold, it is determined to be a potential attack behavior. It also detects whether there are abnormal frames in the WPA2 authentication mode in the 6GHz frequency band and triggers an alarm if detected. The anomaly detection module is used to automatically send a deauthentication frame to the radio product's hardware module when an abnormal number of handshake failures is detected, forcibly disconnecting the target device and triggering a re-handshake process. If an abnormal frame in WPA2 compatibility mode is detected on the 6GHz band, the wireless communication function of the 6GHz band is immediately disabled through hardware interface configuration. The risk score output module defines hard rules based on the SAE handshake protocol specification supported by the radio product hardware. These include: the Commit message must contain a unique, hardware-generated random number that cannot be repeated; the hash value of the Confirm message must be consistent with the hardware parameters during the Commit phase; and PMK generation must be based on a hardware-level dynamic key exchange algorithm. If any of these rules are violated, it is determined to be a protocol implementation flaw or attack behavior, and the corresponding risk score is output. The risk score corresponds to high risk, medium risk, and low risk. The defense strategy adjustment module dynamically adjusts the defense strategy based on the risk score: if the risk is high, the hardware key management module is prioritized to refresh the PMK or disable high-risk frequency bands; if the risk is medium, the device protocol compatibility is verified through firmware-level capability negotiation requests; if the risk is low, only abnormal events and defense action logs are recorded through the hardware logger.

[0021] In a third aspect, the present application provides a device for detecting wireless network security, which adopts the following technical solution: A device for detecting wireless network security includes a processor, wherein the processor runs a program of any one of the above methods for detecting wireless network security.

[0022] In a fourth aspect, the present application provides a storage medium, which adopts the following technical solution: A storage medium stores a program of any one of the above methods for detecting wireless network security.

[0023] In summary, this application includes at least one of the following beneficial technical effects: The radio's hardware module captures wireless traffic in the 2.4GHz, 5GHz, and 6GHz bands in real time, analyzes the four WPA3-SAE handshake protocol interactions, and verifies the consistency of the hardware generation logic, including random number uniqueness and confirm hash value matching. Dynamic thresholds are used to detect handshake failures in each band and identify abnormal WPA2 frames in the 6GHz band, enabling rapid response to potential attacks, such as triggering deauthentication frames or disabling high-risk bands, for real-time security monitoring.

[0024] Furthermore, the system dynamically adjusts defense strategies based on risk scores, supporting differentiated handling for high, medium, and low risk scenarios, such as forced key refreshes, protocol negotiation, or logging. Furthermore, combined with mechanisms such as cross-band protocol consistency verification, blacklist isolation, and multi-band coordinated attack identification, overall defense capabilities are enhanced, ensuring efficient, real-time, and adaptive detection and protection against security threats to wireless network devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 The present invention is a flowchart of a method for detecting wireless network security according to an exemplary embodiment.

[0026] Figure 2 The figure is a structural block diagram of a device for detecting wireless network security according to an exemplary embodiment. DETAILED DESCRIPTION

[0027] Embodiments of the present application are described in detail below, examples of which are illustrated in the accompanying drawings.

[0028] Throughout this specification, reference to the terms "certain embodiments," "one embodiment," "some embodiments," "illustrative embodiments," "examples," "specific examples," or "some examples" means that a specific feature, structure, material, or characteristic described in conjunction with the embodiment or example is included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0029] The present application discloses a method for detecting wireless network security. Figure 1 ,include: S100 uses the radio product's hardware module to capture wireless communication traffic in the 2.4GHz, 5GHz, and 6GHz frequency bands in real time, performs protocol analysis on the wireless communication traffic, and extracts the four-way interaction data of the WPA3SAE handshake protocol executed by devices in each frequency band. The four interaction data include the Commit message, Confirm message, PMK generation parameters, and hash check value.

[0030] The detailed execution steps of step S100 specifically include the following sub-steps: Step 1: Enable monitoring of the 2.4 GHz, 5 GHz, and 6 GHz frequency bands simultaneously using a radio product hardware module (such as a Wi-Fi 7-compatible RF front-end or embedded detection chip). This hardware module must have hardware-level multi-band concurrency capabilities to ensure simultaneous capture of wireless communication traffic on all three bands.

[0031] In an embodiment of the present application, the hardware configuration: enables the hardware promiscuous mode in the radio product to receive all passing wireless data frames (including management frames, control frames and data frames); configures the multi-band monitoring mode to ensure compatibility with devices with different protocol versions.

[0032] In the embodiment of the present application, traffic capture: use the hardware built-in packet capture tool to capture the wireless traffic of each frequency band in real time; set filtering rules to filter data packets related to WPA3SAE handshake (such as authentication frames, data frames).

[0033] Step 2: Protocol parsing and four-way interaction data extraction: Perform protocol parsing on the captured raw traffic, focusing on extracting the four-way interaction data of the WPA3SAE handshake protocol (Commit, Confirm, PMK generation parameters, and hash check value).

[0034] Commit message parsing: Extracts the Commit message exchanged between the client and access point in the first phase of the SAE handshake process; verifies whether the Commit message contains a nonces that comply with the specification and records its uniqueness (for example, by detecting duplication using a hash table); and extracts the public key and encryption parameters (such as the key exchange algorithm type) in the Commit message.

[0035] Confirm message parsing: Parse the Confirm message from the second phase and extract the hash value. Verify that the Confirm hash value is consistent with the parameters from the Commit phase (such as random numbers, public keys, and shared keys) to ensure that the key generation logic of both parties matches (e.g., recalculating the expected value through a hash function and comparing them).

[0036] PMK generation parameter extraction: Extracts key parameters used to generate the PairwiseMasterKey (PMK) from Commit and Confirm messages (such as key exchange results and hash algorithm type). Verifies whether the PMK generation complies with dynamic key exchange specifications (for example, whether it is based on the key exchange results shared by both parties).

[0037] Hash checksum extraction: Extracts the hash checksum from the Confirm message and compares it with the locally calculated expected value to determine whether the handshake process is complete and has not been tampered with.

[0038] Step 3: Multi-band data association and storage: The SAE handshake data of the same device in different frequency bands (2.4GHz, 5GHz, and 6GHz) are associated by timestamp to form a multidimensional dataset.

[0039] Device identification binding: Match the interaction data of the same device on different frequency bands through the device MAC address or service set identifier (SSID).

[0040] Timing alignment: Synchronizes the handshake process across frequency bands based on timestamps to ensure consistency in cross-band analysis (for example, detecting whether a device switches to the 2.4 GHz band immediately after initiating a handshake in the 6 GHz band).

[0041] Data storage optimization: The parsed four-step interaction data (Commit, Confirm, PMK parameters, and hash checksum) is stored in a structured format (such as a database table) to facilitate subsequent analysis.

[0042] It should be pointed out here that in the embodiment of the present application, during the capture and parsing process, the following key indicators are monitored in real time: statistics on the number of handshake failures, recording the handshake failure events in each frequency band, and counting the number of failures per unit time; if the number of handshake failures in any frequency band exceeds the preset dynamic threshold (such as the number of failures >10 times within 5 minutes), it is marked as a potential attack behavior; WPA2 authentication mode anomaly detection, screening abnormal frames in the WPA2 authentication mode in the 6GHz frequency band, and triggering an alarm if detected.

[0043] Through multiple sub-steps in S100, hardware-level real-time traffic capture and protocol parsing of radio products build a comprehensive data foundation for subsequent wireless network security testing. This includes: Traffic collection across the 2.4GHz, 5GHz, and 6GHz bands, ensuring comprehensive monitoring of attack behaviors against mainstream Wi-Fi devices (especially Wi-Fi 6 / 7); precise extraction of the four WPA3 SAE handshake interaction data (such as the Commit message, Confirm hash value, and PMK parameters) to verify handshake compliance, providing a basis for protocol version conflict detection, PMK consistency verification, and attack identification; Time-series correlation and structured storage create a closed-loop logic for cross-band protocol analysis, handshake failure statistics, and risk score calculation; and simultaneous analysis of multi-band data provides coordinated defense support for band isolation strategies, dynamic threshold adjustment, and cross-band attack pattern identification (such as induced downgrade attacks), enabling efficient detection and response to complex attack scenarios.

[0044] S200 compares the SAE handshake processes of each frequency band and verifies the consistency of the hardware generation logic. The process of verifying the consistency of the hardware generation logic includes determining whether the hardware random number is unique and whether the Confirm hash value matches; counting the number of handshake failures in each frequency band. If the number of handshake failures in any frequency band exceeds the preset dynamic threshold, it is determined to be a potential attack behavior; and detecting whether there are abnormal frames in the WPA2 authentication mode in the 6GHz band. If detected, an alarm is triggered.

[0045] The detailed execution steps of step S200 specifically include the following sub-steps: Step 1: Compare the SAE handshake processes of each frequency band to verify the consistency of the hardware generation logic: Data extraction and comparison: Compare the SAE handshake interaction data (Commit message, Confirm message, PMK parameters, hash check value) for each frequency band (2.4 GHz, 5 GHz, and 6 GHz) extracted from step S100.

[0046] Commit message verification: Checks whether the Commit messages sent by devices in each frequency band contain a unique random number (SCN) generated by the radio product hardware. If the same device sends duplicate SCNs on different frequency bands, it is flagged as abnormal behavior.

[0047] Confirm hash value match: Compare the hash value in the Confirm message with the parameters in the Commit phase (such as SCN, public key, and shared key) to ensure consistency. If they are inconsistent, it is considered a handshake process anomaly, which may lead to hardware-level PMK generation errors.

[0048] PMK generation logic verification: Verifies that PMK generation in all frequency bands is based on the same hardware-level dynamic key exchange algorithm (such as ECDH). If a frequency band's PMK generation parameters are found to be inconsistent with standard specifications (such as inconsistent algorithm types), it will be flagged as a protocol implementation defect.

[0049] Step 2: Count the number of handshake failures in each frequency band and determine potential attack behaviors: Failure count statistics: Record the number of failures (such as device failure, hash check failure, SCN conflict, etc.) from handshake events on each frequency band. The statistical period can be based on a time window (such as within 5 minutes); Dynamic threshold determination: The actual number of failures is compared with the preset dynamic threshold (calculated based on the historical baseline). If the number of failures in a certain frequency band exceeds the threshold (e.g., >10 failures within 5 minutes), it is determined to be a potential attack behavior (e.g., replay attack, forged handshake frame); Attack behavior marking: Marks the frequency bands and devices that trigger the threshold and records abnormal event logs (such as timestamp, device MAC address, and frequency band ID).

[0050] Step 3: Detect abnormal frames in WPA2 authentication mode in the 6GHz band: Protocol version field identification: Filter authentication frames in 6GHz band traffic and extract the protocol version field (such as WPA2, WPA3); Abnormal frame detection: If a WPA2 authentication mode frame (such as WPA2-PSK or WPA2-ENT) is detected in the 6GHz band, it is determined to be an abnormal protocol version and may be an attempt by an attacker to induce device downgrade. Alarm triggering: Immediately sends an alarm signal to the security management platform, records detailed information about the abnormal frame (such as time, device MAC address, and protocol version), and triggers subsequent defense strategies (such as frequency band isolation); Step S200 enables proactive detection of multi-band wireless network attacks through in-depth cross-band SAE handshake process comparison and protocol verification. Specifically, it verifies the hardware consistency of the PMK generation logic across each band (e.g., Commit random number uniqueness and Confirm hash value matching) to ensure the handshake process complies with the WPA3 SAE specification. Dynamic threshold analysis based on the number of handshake failures accurately identifies potential attacks (e.g., replay attacks and forged handshakes). It also detects abnormal WPA2 frames in the 6GHz band to prevent protocol downgrade attacks. Finally, verification results (e.g., protocol conflicts and attack flags) are passed to subsequent steps to dynamically adjust defense strategies (e.g., blocking connections and refreshing PMKs). This creates a closed-loop logic from attack identification to response, fully ensuring wireless network security in multi-band environments.

[0051] S300: When an abnormal number of handshake failures is detected, the hardware module of the radio product automatically sends a de-authentication frame, forcibly disconnecting the target device and triggering a re-handshake process; if an abnormal frame in WPA2 compatible mode is detected in the 6GHz band, the wireless communication function of the 6GHz band is immediately disabled through the hardware interface configuration.

[0052] The detailed execution steps of step S300 specifically include the following sub-steps: Step 1: Detect an abnormal number of handshake failures and trigger a deauthentication frame: When the number of handshake failures detected in a certain frequency band (such as 2.4GHz, 5GHz) exceeds the preset dynamic threshold (such as >10 failures within 5 minutes), the hardware module of the radio product will automatically trigger a defensive action.

[0053] Abnormal determination: Based on the statistical results of step S200, if the handshake failure event of a certain frequency band is marked as a potential attack behavior (such as replay attack, forged handshake frame), the response process is entered.

[0054] Sending a deauthentication frame: The radio product's hardware-level RF control unit sends a deauthentication frame to the target device (such as the attack source device or the attacked device) to forcibly disconnect it from the access point (AP). The sending of the deauthentication frame must comply with the 802.11 protocol specification and contain fields such as the device MAC address and reason code (such as "Class 2 Error: Protocol Violation") to ensure legitimacy and traceability.

[0055] Triggering a re-handshake: After a forced disconnect, the target device attempts to re-initiate the handshake process. The system monitors the new handshake process through steps S100 and S200 to determine whether there are still anomalies.

[0056] Step 2: Detect WPA2 compatibility mode in the 6GHz band and block the connection: If an abnormal WPA2 authentication mode frame (such as WPA2-PSK or WPA2-ENT) is detected in the 6GHz band, the radio product's hardware interface will immediately perform band isolation operations.

[0057] Protocol version check: Based on step S200, further verify whether the authentication frame in the 6GHz band complies with the WPA3SAE specification. If a WPA2 protocol frame is detected (for example, WPA3 is not declared in the RSNIE field), it is determined to be a protocol downgrade attack.

[0058] Frequency band isolation and blocking: The hardware interface controller of the radio product will immediately shut down the wireless communication function of the 6GHz frequency band, preventing attackers from infiltrating using old protocol versions.

[0059] Configuration methods include disabling the 6 GHz band in the AP's radio interface view (for example, executing the shutdown command on the radio6 interface). Disabling the band can also be accomplished by writing to hardware registers or using radio channel control signals, rather than relying on software-based AP configuration commands.

[0060] It should be noted that traffic on this frequency band is blocked through policy rules (such as ACL or VLAN isolation). In addition, in the embodiment of the present application, a dynamic recovery mechanism is provided: a timer is set or a health check mechanism is used to re-enable the 6GHz frequency band at a preset time (such as 10 minutes) and continuously monitor protocol version compliance.

[0061] Step 3: All defense operations must be synchronously recorded in the security log system for subsequent analysis and auditing.

[0062] Log content: Event type, clearly marked as "Handshake Failure Abnormal Response" or "WPA2 Compatibility Mode Block"; timestamp, recording the specific time when the defense action was triggered (such as 2025-06-23 02:13:35); device information, including the target device's MAC address, frequency band (such as 6GHz), AP ID, etc.; defense action details, such as the number of deauthentication frames sent and the block status change record of the 6GHz band.

[0063] Log storage and alerting: Synchronize logs to a centralized log server (such as ELKStack or Splunk) and trigger notifications (such as email, SMS, or internal enterprise IM tools) through the radio product's firmware-level alert interface.

[0064] In step S300, the hardware-level active defense mechanism of the radio product is used to respond in real time to abnormal handshake behavior and protocol version conflicts detected by S200; the hardware module automatically sends deauthentication frames to forcibly disconnect the abnormal device and block the link where attackers exploit handshake vulnerabilities (such as replay attacks and forged identities); for WPA2 compatibility mode anomalies in the 6GHz band, the hardware interface directly disables communications in this band to prevent protocol downgrade attacks; hardware logging and firmware-level alarm interfaces are combined to form a closed-loop process from attack detection to defense actions, providing data support for traceability analysis and strategy optimization; through cross-band isolation and recovery strategies (such as dynamically disabling / enabling the 6GHz band), the overall anti-attack capability of the wireless network in a multi-band environment is enhanced, thereby achieving the coordinated goals of rapid response, precise blocking and dynamic protection.

[0065] S400 defines hard rules based on the SAE handshake protocol specification supported by the radio product hardware, including: the Commit message must contain a unique and non-repeatable random number generated by the hardware, the hash value of the Confirm message must be consistent with the hardware parameters of the Commit phase, and PMK generation must be based on a hardware-level dynamic key exchange algorithm. If any of the rules are violated, it is determined to be a protocol implementation defect or attack behavior, and the corresponding risk score is output, where the risk score corresponds to high risk, medium risk, and low risk.

[0066] The detailed execution steps of step S400 specifically include the following sub-steps: Step 1: Generate a structured security report based on the data collected in steps S100 to S300 (such as handshake interaction records, attack markers, and defense action logs).

[0067] In the embodiment of this application, the report content mainly includes: Attack event statistics: summarize key indicators such as the number of handshake failures, the number of deauthentication frame transmissions, and the number of WPA2 abnormal frame detections in each frequency band (2.4GHz, 5GHz, and 6GHz); time trend analysis: draw attack event density maps using hourly / daily time windows to identify high-risk periods (such as frequent replay attacks at night); device behavior profiling: for high-frequency abnormal devices (such as MAC addresses), mark their attack patterns (such as repeated sending of Commit messages and protocol downgrade attempts).

[0068] In the embodiment of the present application, the report format adopts visual forms such as tables, line charts, heat maps, etc., which makes it easy for administrators to quickly locate problems. In addition, the output format of the report format supports PDF, HTML or can be integrated into the enterprise security management system (such as the SOC platform).

[0069] Step 2: Use machine learning models (such as time series analysis or clustering algorithms) to model historical attack data and predict potential future risks.

[0070] By inputting the attack frequency, frequency band distribution, defense action response time and other characteristics recorded in steps S100 to S300, based on dimensions such as attack type (such as replay attack weight > protocol degradation attack), frequency band importance (6GHz>5GHz>2.4GHz), attack duration, and combining the compliance verification results of the radio product's own protocol, the risk scoring model dynamically calculates the risk score of the device or frequency band (such as 0-100 points). If it is a high risk, the high risk score triggers an automatic alarm (such as a score > 80 is pushed to the administrator or firmware-level alarm interface). In this embodiment of the present application, a heat map of attack probability within the next 24 hours can be generated to assist in formulating a defense strategy adjustment plan.

[0071] Step 3: Based on the changes in attack patterns and feedback on defense effectiveness, propose targeted strategy optimization suggestions.

[0072] Dynamic threshold adjustment: If the number of handshake failures in a certain frequency band is consistently below the preset threshold, it is recommended to lower the detection sensitivity to reduce false alarms. If new attack patterns (such as short, high-frequency commit messages) appear in high-frequency bands (such as 6 GHz), it is recommended to temporarily tighten the threshold.

[0073] Defense strategy adjustment: For specific attack types (such as protocol downgrade attacks), it is recommended to enable stricter protocol version verification (such as mandatory WPA3-SAE). For high-frequency abnormal devices, it is recommended to add them to the blacklist or restrict their access frequency band (such as allowing access to only 5GHz).

[0074] Automated deployment recommendations: Automatically deliver optimized policies to the configuration modules of radio products (such as RF control registers and key management units) through scripts or API interfaces.

[0075] Step 4: System adaptive adjustment and feedback loop, that is, feeding back the analysis results of S400 to steps S100 to S300 to form a closed-loop optimization.

[0076] Parameter update: Synchronizes the weight parameters (such as attack type weight) output by the risk scoring model to the dynamic threshold calculation module of the S200; automatically adds the MAC addresses of high-frequency abnormal devices to the S300's rapid blocking whitelist.

[0077] Policy deployment: Batch update the configuration policies (such as protocol version verification rules and handshake process verification items) of radio products through automated tools (such as embedded scripts or firmware update mechanisms).

[0078] In addition, new monitoring items for the optimized strategy (such as the newly deployed protocol version verification rules) are added in step S100 to ensure that the strategy is effective and the effect is continuously evaluated.

[0079] Step S400 builds a complete risk identification and response system through a compliance verification mechanism based on the radio product hardware protocol, combined with data analysis and intelligent scoring models. Its core functions are: building comprehensive security situation awareness capabilities, intuitively displaying attack distribution, frequency band risks, and device behavior characteristics; using machine learning to achieve intelligent risk prediction, dynamically calculating risk scores and identifying potential threats in advance; promoting adaptive optimization of defense strategies, adjusting detection thresholds, protocol restrictions, and access control strategies based on changes in attack patterns; and through a closed-loop system collaboration mechanism, feeding analysis results back to the detection and defense modules, forming a complete security closed loop of "collection-analysis-response-optimization", continuously improving the protocol security and anti-attack capabilities of radio products in multi-band environments.

[0080] S500 dynamically adjusts the defense strategy based on the risk score: if the risk is high, the hardware key management module is prioritized to refresh the PMK or disable high-risk frequency bands; if the risk is medium, the device protocol compatibility is verified through firmware-level capability negotiation requests; if the risk is low, only abnormal events and defense action logs are recorded through the hardware logger.

[0081] The detailed execution steps of step S500 specifically include the following sub-steps: Step 1: Build a long-term security trend database. All security event data collected in steps S100 to S400 (such as handshake interaction records, attack tags, defense action logs, and risk scores) are structured and stored to form a long-term trend database.

[0082] Data classification: Attack event density, handshake failure count, defense response frequency, and other indicators are divided by time dimension (such as hour, day, and week); abnormal device behavior patterns (such as high frequency of commit messages and protocol downgrade attempts) are recorded by device dimension (such as MAC address and frequency band).

[0083] Storage optimization: Use an embedded database supported by the radio product (such as lightweight SQLite or FlashDB) to store massive amounts of data, enabling fast queries and real-time analysis. Additionally, index key fields (such as timestamps, device MAC addresses, and risk levels) to improve retrieval efficiency.

[0084] Step 2: Multi-dimensional security trend analysis, which involves conducting an in-depth analysis of the wireless network's security status based on a long-term trend database to identify potential threat patterns.

[0085] It should be pointed out here that for attack pattern mining, clustering algorithms (such as K-means) can be used to perform cluster analysis on high-frequency attack events (such as replay attacks and forged handshakes) to extract the attacker's behavioral characteristics (such as attack time distribution and target device preferences).

[0086] Through association rule mining (such as the Apriori algorithm), the correlation between attack events and device behavior is discovered (for example, after a device frequently triggers deauthentication frames in the 6GHz band, a protocol degradation attack occurs in the 5GHz band).

[0087] Step 3: Based on the trend analysis results, automatically generate and deploy optimized security policies to achieve self-evolution of the defense system.

[0088] Policy generation: If a high-risk event is detected (such as an abnormal WPA2 frame + PMK generation anomaly), the system automatically triggers the hardware key management module to refresh the PMK or directly disable communication in the high-risk frequency band. For medium-risk events (such as a Confirm hash value deviation but no violation of the protocol specification), firmware-level capability negotiation requests are used to verify whether the device supports WPA3-SAE to prevent misjudgment. For low-risk events (such as a slight timestamp deviation or non-standard frame format), only the hardware logger records the event details without interrupting the connection.

[0089] Policy deployment: Policy changes are distributed to local modules (such as the key management unit and radio frequency control unit) through the radio product's firmware update mechanism or configuration register interface. The policy implementation status is monitored in real time (for example, checking whether the PMK is successfully refreshed or the frequency band is closed), and deployment logs are recorded.

[0090] Step 4: Present the long-term trend analysis and strategy optimization results in a visual format to provide decision support for management. In this embodiment of the application, the visualization content includes: The attack heat map displays the attack density distribution and high-risk periods for each frequency band (2.4GHz, 5GHz, and 6GHz). The policy effectiveness dashboard displays the response efficiency of the defense policy (such as PMK refresh success rate and protocol compatibility negotiation success rate) in real time.

[0091] In addition, in an embodiment of the present application, security reports are generated on a periodic basis, and the period can be adjusted. That is, periodic security reports (such as monthly / quarterly) are generated, which include attack trend analysis, defense strategy optimization suggestions and resource allocation suggestions. The reports support multi-format export (PDF, HTML) and are integrated into the security management platform (such as SOC, SIEM system) through the firmware-level log upload interface.

[0092] Through differentiated defense strategies based on risk scoring, combined with data analysis and intelligent decision-making models, radio products can accurately respond to different security situations: hardware-level PMK refresh or frequency band isolation is triggered when the risk is high; protocol compatibility is verified through firmware-level capability negotiation when the risk is medium; and only logs are recorded to ensure system stability when the risk is low. Ultimately, a closed-loop logic of "collection-analysis-response-optimization" is formed to continuously improve the product's anti-attack resilience and intelligent protection capabilities.

[0093] In an embodiment of the present application, the cross-band protocol consistency check module further includes: Step 1: Verify protocol consistency across frequency bands by comparing the hardware protocol version fields of radio products across different frequency bands. The system uses the radio product's hardware parsing module to extract the protocol version fields (such as the WPA3-SAE identifier in the RSNIE field) from SAE handshake frames sent by devices across different frequency bands (e.g., 2.4 GHz, 5 GHz, and 6 GHz) for cross-band comparison.

[0094] The conflict detection logic of this solution is as follows: if a discrepancy is detected in the protocol version field of at least two frequency bands (for example, the 2.4GHz band claims to support WPA3SAE, while the 6GHz band claims to use WPA2PSK), a protocol version conflict event is marked. It should be noted that this conflict detection logic has already been mentioned in the "Protocol Consistency Assurance" step S200 (such as PMK generation algorithm verification), but it is further refined here to a comparison mechanism based on the hardware protocol version field to ensure protocol compliance from the perspective of the radio product itself.

[0095] Step 2: Based on the protocol version conflict event, generate and execute a frequency band isolation strategy.

[0096] The system writes the frequency band with protocol version conflicts (such as 6GHz) to the radio product's hardware blacklist storage unit, prohibiting the initiation of new SAE handshake processes for that frequency band. This isolation mechanism is similar to the "blacklist mechanism" in step S300, but here it is expanded to include dedicated processing logic for protocol version conflicts. This logic is directly executed by the radio product's hardware-level RF control module, rather than relying on external configuration.

[0097] Step 3: Send a hardware-level WPA3-SAE capability negotiation request to the target device to verify whether it supports the latest protocol version.

[0098] Negotiation process: If the device fails to respond (such as not returning WPA3-SAE confirmation information), it is determined that there is a risk of protocol downgrade; Deauthentication frame trigger: The hardware-level RF control unit of the radio product sends a deauthentication frame (DeauthenticationFrame) to the target device, forcing the connection to be disconnected.

[0099] It should be noted here that protocol downgrade risk events will be recorded in the firmware-level logger of the radio product, including timestamp, device MAC address, frequency band identifier, protocol version information and defense action details for subsequent analysis and alerting.

[0100] In other words, after a device completes a handshake using WPA3-SAE on the 2.4GHz band, an attacker attempts to trick it into initiating a connection using WPA2 on the 6GHz band. The radio's hardware parsing module compares the protocol version fields of the two bands (such as the WPA3-SAE identifier in the RSNIE) and discovers that the 6GHz band claims to use WPA2-PSK, triggering a protocol version conflict. The system then blacklists the 6GHz band and disables communication on that band, while simultaneously sending a hardware-level WPA3-SAE capability negotiation request. If the device fails to respond or returns an error (if it insists on using WPA2), the radio's hardware-level RF control unit immediately triggers a deauthentication frame to forcibly disconnect the device and logs the protocol downgrade risk event in the firmware logger. This process, combined with the S300's band isolation strategy and the S200's protocol consistency check, ultimately blocks attackers from penetrating through protocol version downgrades, ensuring protocol security in multi-band environments.

[0101] In the embodiment of the present application, the frequency band isolation strategy further includes: Step 1: When a protocol version conflict event is detected, the hardware-level security control module of the radio product writes the MAC address and frequency band identifier (such as 2.4GHz, 5GHz, 6GHz) of the conflicting device into the hardware blacklist storage unit.

[0102] Blacklist storage logic: It should be pointed out here that the blacklist mechanism here is different from the "disable wireless connection in the 6GHz band" logic mentioned in the "frequency band isolation and blacklist mechanism" of step S300. It is further refined here into a device-level blacklist, which only limits the access rights of specific devices in specific frequency bands, rather than globally disabling the entire frequency band; for example: If a device triggers a protocol version conflict event in the 6GHz band, the system will record its MAC address and 6GHz band identifier to prevent it from initiating a connection in the frequency band in the future.

[0103] Step 2: When the device is detected to initiate a new SAE handshake request in the blacklisted frequency band, the hardware module automatically discards the request and records the interception log.

[0104] Interception logic: This operation is different from the "sending a deauthentication frame" in step S300. The interception here occurs at an earlier stage of the handshake process (such as before the Commit message is sent), directly discarding the request rather than passively disconnecting. For example, if a device has been marked as 6GHz blacklisted, the Commit message it sends will be directly discarded by the hardware-level RF control unit of the radio product, without entering the Confirm stage or triggering a deauthentication frame.

[0105] In step 3, if it is subsequently detected that the device successfully completes the WPA3-SAE handshake in the blacklisted frequency band, its blacklist identification in the frequency band is automatically removed.

[0106] Dynamic removal logic: If a device has been blacklisted in the 6GHz band due to a protocol version conflict, but subsequently passes the compliant WPA3-SAE handshake verification, the firmware-level security management module of the radio product will automatically remove it from the blacklist and allow it to access normally.

[0107] A device was previously added to the system's hardware blacklist due to a protocol version conflict (declaring it used WPA2 instead of WPA3 SAE) in the 6GHz band. When the device attempted to initiate an SAE handshake request in the 6GHz band again, the radio's hardware-level RF control unit simply discarded its Commit message and logged the interception (rather than waiting for the complete handshake process), effectively preventing attackers from exploiting vulnerabilities in the older protocol. If the device subsequently passes a compliant WPA3-SAE handshake in the 6GHz band (for example, successfully sending a Confirm message), the radio's firmware-level security management module automatically removes it from the blacklist, allowing it to connect normally. This process combines the S300's band isolation strategy (global band blocking) with the S200's protocol consistency check (protocol version field comparison) to achieve a closed-loop "precise interception and dynamic removal" protection, preventing accidental damage to legitimate devices while ensuring protocol security in multi-band environments.

[0108] In an embodiment of the present application, the method further includes: In step 1, based on the hardware-captured logs of frequency band isolation actions and protocol version conflict events, timestamp correlation analysis is used to identify whether the attacker is carrying out a coordinated attack across multiple frequency bands (for example, inducing device downgrade on the 6 GHz band and then switching to the 2.4 GHz band).

[0109] The hardware-level logger of radio products collects timestamp data of frequency band isolation actions (such as sending deauthentication frames and writing to blacklists) and protocol version conflict events. The system analyzes attack behavior patterns through time series comparison. For example: if a device triggers a protocol version conflict event (timestamp T1) in the 6GHz band and then initiates an abnormal handshake request (timestamp T2) in the 2.4GHz band, and T2-T1 is within the preset threshold (such as 30 seconds), it is judged as a coordinated attack behavior (such as "induced degradation + cross-band penetration").

[0110] Step 2: Dynamically optimize the hardware isolation strategy based on the correlation analysis results.

[0111] Policy adjustment logic: If an attacker is detected inducing degradation through the 6GHz band and then switching to the 2.4GHz band, the hardware-level RF control module of the radio product dynamically adjusts the isolation policy: the 2.4GHz band is added to the temporary isolation list, and its handshake failure threshold is lowered (such as the dynamic threshold adjustment logic of the S200); if the device has multiple abnormal cross-band behaviors, its MAC address is marked as high-risk and expanded to full-band isolation.

[0112] Step 3: Optimize the blacklist update rules based on the characteristics of the coordinated attack behavior.

[0113] Rule optimization logic: If a device is marked multiple times for coordinated attack behavior, the radio product's firmware-level security management unit will automatically adjust the blacklist aging policy: shorten its blacklist aging time from the default 30 minutes to 5 minutes, increasing the blocking frequency; increase the penalty weight for cross-band behavior, and improve the interception priority of subsequent connection requests; record the coordinated attack characteristics for subsequent machine learning model training and risk scoring model optimization (such as the linkage of S400 and S500 steps).

[0114] An attacker tricked a device into downgrading from WPA3SAE to WPA2 on the 6GHz band (timestamp T1). The attacker then initiated an anomalous handshake request on the 2.4GHz band (timestamp T2), with the interval between T2 and T1 being only 15 seconds. The radio product's hardware-level logger, through timestamp correlation analysis, identified the coordinated attack on both bands and determined it to be a "protocol downgrade induction plus cross-band penetration" attack. The hardware-level RF control module then dynamically adjusted its policy: strengthening the handshake failure threshold for the 2.4GHz band (S200 dynamic threshold adjustment) and adding the device's MAC address and the 6GHz band to the hardware blacklist (S300 blacklist mechanism). If the device subsequently attempts to connect on the 2.4GHz band, the system automatically shortens its blacklist aging time to 5 minutes due to the cross-band behavior flag (S500 dynamic trust restoration), and the firmware-level security management unit records the high-risk behavior. This closed-loop process, encompassing "timestamp correlation - policy response - rule evolution," precisely blocks the attack path and optimizes the defense system's resilience against complex coordinated attacks.

[0115] In an embodiment of the present application, the method further includes a defect detection step based on protocol analysis: In step 1, the system utilizes the radio's hardware-level protocol parsing unit to perform in-depth field-level parsing of key frames, such as the Commit and Confirm messages, sent by the target device during the SAE handshake. The system extracts the following parameters: the hardware random number (Scalar / Element value) in the Commit message; the hash value (ConfirmHash) in the Confirm message; and key parameters relied upon for PMK generation (such as the Scalar / Element combination in the Commit phase). These fields are extracted and verified in real time by the radio's hardware-level protocol parsing engine, ensuring that data collection is independent of external systems or software processing.

[0116] Step 2: Based on the extracted parameters, detect the following hardware protocol implementation defects: If the Commit message lacks a hardware random number (for example, a missing Scalar or Element), or the random number conflicts with a historical record (for example, it is reused), it is considered a protocol implementation flaw. For example, an attacker might forge a Commit message and reuse an old random number, resulting in PMK calculation errors or cross-band consistency conflicts.

[0117] If the hash value of the Confirm message does not match the calculation result of the Commit phase parameters (such as the Scalar / Element combination), it is considered a hardware protocol implementation flaw. For example, an attacker can tamper with the hash value of the Confirm message to bypass the verification process, affecting the security of WPA3-SAE.

[0118] Step 3: According to the detected protocol implementation defects, match the preset risk scoring library and output the corresponding risk level (such as low risk, medium risk, high risk).

[0119] Risk scoring logic: For example, if repeated hardware random numbers are detected, it is judged as "medium risk", and if the confirm hash value is inconsistent, it is judged as "high risk". The risk scoring result will trigger the corresponding defense response action, such as adding to the blacklist, sending a deauthentication frame, or dynamically adjusting the isolation policy.

[0120] Based on the above steps, a device sent a Commit message during the Commit phase of the SAE handshake, in which the hardware random number (Scalar value) duplicated the historical record. The radio product's hardware-level protocol parsing engine detected this anomaly through field-level analysis, determined it to be a protocol implementation flaw, and matched it with the risk scoring library, marking it as "medium risk." The system then triggered the S300 blacklist mechanism, adding the device to a temporary quarantine list and recording the risk event. If it subsequently detected that the device's hash value during the Confirm phase was inconsistent with the Commit parameters (e.g., tampering with the Confirm message), the system upgraded the risk level to "high risk" and triggered a deauthentication frame through the hardware-level RF control unit to forcibly disconnect. This process, combined with the S200 protocol consistency check (protocol version field) and the S500 dynamic trust recovery mechanism, creates a complete closed loop from flaw detection to risk response.

[0121] In the embodiment of the present application, dynamic threshold adjustment further includes: Step 1: Calculate the baseline threshold based on the historical handshake failure counts of the radio product hardware in each frequency band, which serves as the basis for dynamic threshold adjustment.

[0122] The system uses the radio product's hardware-level statistics module to collect historical handshake failure records for devices in various frequency bands (such as 2.4GHz, 5GHz, and 6GHz) and performs statistical analysis using a sliding window mechanism (e.g., data collected over a seven-day period). The calculation logic determines a baseline threshold based on the mean and standard deviation of handshake failures. For example, if a device has an average handshake failure rate of 2% and a standard deviation of 0.5% in the 6GHz band, the baseline threshold could be set as 2% + 2 × 0.5% = 3%. This baseline serves as the basis for subsequent dynamic threshold adjustments, distinguishing normal fluctuations from potential attacks.

[0123] In step 2, when it is detected that the number of handshake failures of the device in a specific frequency band continuously exceeds the baseline threshold of the preset window time, the hardware logic automatically adjusts the upper limit of the dynamic threshold of the specific frequency band (for example, from 3% to 4%).

[0124] If a device's handshake failure rate in the 6 GHz band exceeds the baseline threshold for three consecutive hours (for example, from 3% to 4%), the radio product's firmware-level policy control unit will automatically increase the dynamic upper threshold limit for that band (for example, from 3% to 4% or 5%) to accommodate short-term abnormal fluctuations. For example, if a device's handshake failure rate rises to 4% due to 6 GHz band signal interference, the system will dynamically increase the upper threshold limit for that band to 5% and observe subsequent behavior.

[0125] Step 3: If the alarm continues to be triggered after the dynamic threshold is adjusted, it is marked as an abnormal mode and pushed to the security management platform.

[0126] It should be noted here that if the handshake failure rate of the device in the 6GHz frequency band remains higher than 5% after the dynamic threshold is adjusted, and is accompanied by other abnormal behaviors (such as protocol version conflict and Confirm hash verification failure), the hardware-level security decision module of the radio product will determine it as an abnormal mode and generate a structured event log.

[0127] The event is pushed to a security management platform (such as a SIEM system) for manual review. At the same time, the hardware-level RF control unit sends a deauthentication frame to the target device, forcibly disconnecting the device and recording the exception log in the firmware-level logger.

[0128] The handshake failure rate of a certain device in the 6GHz band suddenly increased from a normal value of 2% to 4%. The hardware-level statistics module of the radio product calculated a baseline threshold of 3% based on historical data, triggering the firmware-level policy control unit to increase the dynamic threshold upper limit for this band to 5%. If the handshake failure rate of the device continues to exceed 5% due to a protocol downgrade attack after the adjustment, the hardware-level security decision module will mark it as an abnormal pattern and push it to the security management platform. After review, security personnel discovered that the device was indeed induced to downgrade by an attacker exploiting a vulnerability in the old protocol. The device's MAC address and the 6GHz band were permanently banned through the S300 blacklist mechanism, and the S200 protocol consistency check was used to strengthen the handshake verification policy for the 6GHz band. This process achieves accurate identification and rapid response to complex attacks through the closed-loop logic of "baseline modeling - dynamic adjustment - pattern marking - active blocking."

[0129] In an embodiment of the present application, the method further includes: Based on the device's behavioral characteristics and protocol consistency test results during the SAE handshake process, the system assigns a risk score (high / medium / low). The hardware-level security decision module of the radio product triggers the corresponding defense strategy: If the risk score is high (e.g., Confirm hash value inconsistency, protocol downgrade attack induction), the hardware module immediately triggers a deauthentication frame and blocks the current band connection. Simultaneously, the hardware-level key management unit initiates a forced refresh of the PMK (Pairwise Master Key) to prevent misuse of the old key. For example, if a device is identified as high risk in the 6GHz band due to a Confirm hash value inconsistency, the radio automatically sends a deauthentication frame to forcibly disconnect it, refresh the PMK, and write its MAC address to the hardware blacklist storage unit (S300).

[0130] If the risk score is medium (e.g., repeated Commit random numbers or an abnormal protocol version field), the system sends a WPA3-SAE capability negotiation request (CapabilityNegotiationRequest) to the target device through the firmware-level capability negotiation module. This verifies the device's support for the latest protocol specifications and records observation logs for subsequent analysis. For example, if a device sends a Commit message with repeated random numbers in the 2.4 GHz band, the system determines the risk as medium and sends a WPA3-SAE capability negotiation request to verify compliance, logging the negotiation process.

[0131] If the risk score is low (e.g., slight deviation in protocol fields, handshake failure rate below baseline), only the firmware-level logger will record the event details without interrupting the connection or actively initiating interaction. The device's subsequent behavior will be continuously monitored to determine whether to escalate the risk level.

[0132] Step 2: If a device is detected triggering a high-risk event in the 6GHz band, the handshake verification frequency is increased in both the 2.4GHz and 5GHz bands. When a device triggers a high-risk event in the 6GHz band (such as a protocol downgrade attack), the radio product's hardware-level RF control unit will coordinate with other frequency bands (2.4GHz and 5GHz) to strengthen the handshake verification. This includes increasing the handshake verification frequency (for example, adjusting the handshake failure threshold from the default of 5 to 3) and shortening the verification interval (for example, checking handshake activity every 10 seconds), thereby enhancing the ability to identify coordinated cross-band attacks.

[0133] Example: A device is identified as high risk due to a protocol downgrade attack in the 6GHz band. The system automatically increases the handshake verification frequency in the 2.4GHz and 5GHz bands, requiring the device to pass a stricter protocol consistency check (S200) when connecting. If the device attempts to connect again in the 2.4GHz band, the system detects a duplicate commit random number (medium risk) and sends a WPA3-SAE capability negotiation request, logging it. If the negotiation fails, the risk is upgraded to high risk and a deauthentication frame is triggered.

[0134] In an SAE handshake frame sent by a device in the 6GHz band, the Confirm hash value and the Commit parameter are inconsistent (high risk). The radio product's hardware-level security decision module immediately triggers a deauthentication frame and blocks the connection. Simultaneously, the hardware-level key management unit refreshes the PMK to prevent key leakage. Simultaneously, the hardware-level RF control unit increases the handshake verification frequency in the 2.4GHz and 5GHz bands, requiring devices to pass stricter protocol consistency checks (S200) upon connection. If the device attempts to connect again in the 2.4GHz band, the system detects a duplicate Commit random number (medium risk) and sends a WPA3-SAE capability negotiation request, logging it. If the negotiation fails, the risk is upgraded to high and a deauthentication frame is triggered. This process, through a logical chain of "risk scoring, policy selection, and cross-band linkage," precisely blocks attack paths while minimizing accidental damage to legitimate devices.

[0135] The present application discloses a device for detecting wireless network security. Figure 2 ,include: The four-interaction data extraction module 001 captures the wireless communication traffic in the 2.4GHz, 5GHz and 6GHz frequency bands in real time through the hardware module of the radio product, performs protocol analysis on the wireless communication traffic, and is used to extract the four-interaction data of the devices in each frequency band executing the WPA3SAE handshake protocol, where the four-interaction data includes Commit message, Confirm message, PMK generation parameters and hash check value.

[0136] The consistency verification module 002 compares the SAE handshake processes of each frequency band to verify the consistency of the hardware generation logic. The process of verifying the consistency of the hardware generation logic includes determining whether the hardware random number is unique and whether the Confirm hash value matches; counting the number of handshake failures in each frequency band. If the number of handshake failures in any frequency band exceeds the preset dynamic threshold, it is determined to be a potential attack behavior; and detecting whether abnormal frames in the WPA2 authentication mode appear in the 6GHz frequency band. If detected, an alarm is triggered.

[0137] Abnormal detection module 003 is used to automatically send a de-authentication frame to the hardware module of the radio product when an abnormal number of handshake failures is detected, forcibly disconnecting the target device and triggering a re-handshake process; if an abnormal frame in WPA2 compatible mode is detected in the 6GHz band, the wireless communication function of the 6GHz band is immediately disabled through the hardware interface configuration.

[0138] The risk score output module 004 defines hard rules based on the SAE handshake protocol specification supported by the radio product hardware, including: the Commit message must contain a unique random number generated by the hardware and cannot be repeated, the hash value of the Confirm message must be consistent with the hardware parameters of the Commit phase, and PMK generation must be based on the hardware-level dynamic key exchange algorithm; if any rule is violated, it is determined to be a protocol implementation defect or attack behavior, and is used to output the corresponding risk score, where the risk score corresponds to high risk, medium risk, and low risk.

[0139] Defense strategy adjustment module 005 dynamically adjusts the defense strategy based on the risk score: if the risk is high, the PMK is refreshed or the high-risk frequency band is disabled through the hardware key management module first; if the risk is medium, the device protocol compatibility is verified through the firmware-level capability negotiation request; if the risk is low, only abnormal events and defense action logs are recorded through the hardware logger.

[0140] An embodiment of the present application further discloses a device for detecting wireless network security, including a processor, wherein a program of any one of the above-described methods for detecting wireless network security is running on the processor.

[0141] An embodiment of the present application further discloses a storage medium storing a program of any one of the above-mentioned methods for detecting wireless network security.

[0142] Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limitations on the present application. Ordinary technicians in this field can change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A method for detecting wireless network security, characterized in that: include: The radio product's hardware module captures wireless communication traffic in the 2.4GHz, 5GHz, and 6GHz bands in real time, performs protocol parsing on the traffic, and extracts the four-step WPA3SAE handshake data from devices in each band. This data includes the Commit message, Confirm message, PMK generation parameters, and hash checksum. Compare the SAE handshake processes for each frequency band to verify the consistency of the hardware generation logic. This includes determining whether the hardware random number is unique and whether the Confirm hash value matches. Count the number of handshake failures in each frequency band. If the number of handshake failures in any frequency band exceeds a preset dynamic threshold, it is identified as a potential attack. Detect whether abnormal frames in WPA2 authentication mode appear in the 6GHz band and trigger an alarm if detected. When an abnormal number of handshake failures is detected, the radio product's hardware module automatically sends a deauthentication frame, forcibly disconnecting the target device and triggering a re-handshake process. If an abnormal frame in WPA2 compatibility mode is detected on the 6GHz band, the wireless communication function of the 6GHz band is immediately disabled through the hardware interface configuration. Hard rules are defined based on the SAE handshake protocol specification supported by the radio product hardware. These include: the Commit message must contain a unique, hardware-generated random number that cannot be repeated; the hash value of the Confirm message must be consistent with the hardware parameters during the Commit phase; and PMK generation must be based on a hardware-level dynamic key exchange algorithm. Violations of any of these rules are considered protocol implementation flaws or attacks, and a corresponding risk score is output, with the risk score corresponding to high, medium, or low risk. Dynamically adjust defense strategies based on risk scores: If the risk is high, prioritize refreshing the PMK or disabling high-risk frequency bands through the hardware key management module; if the risk is medium, verify device protocol compatibility through firmware-level capability negotiation requests; if the risk is low, only record abnormal events and defense action logs through the hardware logger.

2. The method for detecting wireless network security according to claim 1, wherein: The cross-band protocol consistency check module also includes: By comparing the hardware protocol version fields of radio products in different frequency bands, if inconsistent protocol versions are detected for at least two frequency bands, a protocol version conflict event is marked; Generate a frequency band isolation policy based on protocol version conflict events: add the frequency band with protocol version conflicts to the hardware blacklist, prohibiting devices from initiating new handshakes on the frequency band with protocol version conflicts; send a hardware-level WPA3-SAE capability negotiation request to the target device. If the device fails to respond, a deauthentication frame is triggered and the protocol downgrade risk is recorded.

3. The method for detecting wireless network security according to claim 1, wherein: The frequency band isolation strategy also includes: Write the MAC address and band identifier of the conflicting frequency band into the hardware blacklist storage unit of the radio product; When a device is detected to initiate a new SAE handshake request on a blacklisted frequency band, the hardware module automatically discards the new SAE handshake request and records the interception log; If it is subsequently detected that the device successfully completes the WPA3-SAE handshake on the blacklisted frequency band, the blacklist mark of the conflicting frequency band is automatically removed.

4. The method for detecting wireless network security according to claim 1, wherein: The method also includes: Based on the logs of frequency band isolation actions and protocol version conflict events captured by hardware, timestamp correlation analysis is used to identify whether attackers are carrying out coordinated attacks across multiple frequency bands. Coordinated attacks include attackers inducing device downgrade in the 6GHz band and then switching to the 2.4GHz band. Hardware isolation strategies are dynamically optimized based on the correlation analysis results. Hardware isolation strategies include strengthening monitoring of specific frequency bands or expanding the isolation range.

5. The method for detecting wireless network security according to claim 1, wherein: The method also includes a defect detection step based on protocol analysis: The radio product's hardware parsing module performs field-level parsing on the SAE handshake frame sent by the target device, extracting the hardware random number in the Commit message, the hash value of the Confirm message, and the PMK generation parameters. If the Commit message is missing or contains duplicate hardware random numbers, it is considered a protocol implementation flaw. If the hash value of the Confirm message is inconsistent with the Commit phase parameters, it is considered a hardware protocol implementation flaw. According to the hardware protocol, the defects are matched with the preset risk scoring library and the corresponding risk level is output.

6. The method for detecting wireless network security according to claim 1, wherein: The dynamic threshold adjustment further includes: Calculate baseline thresholds based on the historical handshake failure counts of the radio product hardware in each frequency band; When it is detected that the number of handshake failures of a device in a specific frequency band continuously exceeds the baseline threshold of the preset window time, the hardware logic automatically adjusts the upper limit of the dynamic threshold of the specific frequency band; If the alarm continues to be triggered after the dynamic threshold is adjusted, it will be marked as an abnormal mode and pushed to the security management platform. At the same time, a deauthentication frame will be sent to the target device through the hardware interface and the abnormal log will be recorded.

7. The method for detecting wireless network security according to claim 1, wherein: The method also includes: The strategy is driven by the corresponding risk score: if the risk score is high, the hardware module immediately triggers a deauthentication frame and blocks the current frequency band connection, while forcing the hardware key to refresh; if the risk score is medium, a WPA3-SAE capability negotiation request is sent to the target device and observation logs are recorded; if the risk score is low, only logs are recorded and continuous monitoring is carried out; If a device is detected triggering a high-risk event in the 6GHz band, the handshake verification frequency will be increased in the 2.4GHz and 5GHz bands simultaneously.

8. A device for detecting wireless network security, characterized in that: include: The four-pass data extraction module uses the radio product's hardware module to capture wireless communication traffic in the 2.4GHz, 5GHz, and 6GHz bands in real time, performs protocol analysis on the wireless communication traffic, and extracts the four-pass handshake data of the devices executing the WPA3SAE handshake protocol in each frequency band. The four-pass data includes the Commit message, Confirm message, PMK generation parameters, and hash check value. The consistency verification module compares the SAE handshake processes of each frequency band to verify the consistency of the hardware generation logic. The verification process includes determining whether the hardware random number is unique and whether the confirm hash value matches. It also counts the number of handshake failures in each frequency band. If the number of handshake failures in any frequency band exceeds the preset dynamic threshold, it is determined to be a potential attack behavior. It also detects whether there are abnormal frames in the WPA2 authentication mode in the 6GHz frequency band and triggers an alarm if detected. The anomaly detection module is used to automatically send a deauthentication frame to the radio product's hardware module when an abnormal number of handshake failures is detected, forcibly disconnecting the target device and triggering a re-handshake process. If an abnormal frame in WPA2 compatibility mode is detected on the 6GHz band, the wireless communication function of the 6GHz band is immediately disabled through hardware interface configuration. The risk score output module defines hard rules based on the SAE handshake protocol specification supported by the radio product hardware. These include: the Commit message must contain a unique, hardware-generated random number that cannot be repeated; the hash value of the Confirm message must be consistent with the hardware parameters during the Commit phase; and PMK generation must be based on a hardware-level dynamic key exchange algorithm. If any of these rules are violated, it is determined to be a protocol implementation flaw or attack behavior, and the corresponding risk score is output. The risk score corresponds to high risk, medium risk, and low risk. The defense strategy adjustment module dynamically adjusts the defense strategy based on the risk score: if the risk is high, the hardware key management module is prioritized to refresh the PMK or disable high-risk frequency bands; if the risk is medium, the device protocol compatibility is verified through firmware-level capability negotiation requests; if the risk is low, only abnormal events and defense action logs are recorded through the hardware logger.

9. A device for detecting wireless network security, characterized in that: The method comprises a processor, wherein a program of the method for detecting wireless network security according to any one of claims 1 to 7 is run in the processor.

10. A storage medium, characterized in that: A program is stored that implements the method for detecting wireless network security according to any one of claims 1 to 7.

Images