IoT access control system having active security capability
Patent Information
- Application Number
- PCT/CN2025/089729
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2025-04-18
- Publication Date
- 2026-10-22
Smart Images
Figure CN2025089729_22102026_PF_FP_ABST
Abstract
Description
An IoT access control system with proactive security capabilities Technical Field
[0001] This application relates to the field of Internet of Things (IoT) security technology, specifically to an IoT access control system with proactive security capabilities. Background Technology
[0002] The large-scale deployment and heterogeneous nature of current Internet of Things (IoT) devices pose significant challenges to traditional network security solutions. Existing technologies largely focus on network-layer device access control, relying on static authentication rules (such as MAC whitelists) or strong authentication protocols (such as 802.1X certificate authentication) for identity verification. While 802.1X authentication can theoretically defend against MAC spoofing and protocol replay attacks, its complex certificate management and terminal computing resource requirements make it difficult for most IoT devices (such as low-power sensors and smart home terminals) to support it, forcing the widespread adoption of lightweight mechanisms such as MAC whitelists in actual deployments. Attackers can exploit this contradiction to launch MAC address spoofing attacks against devices that have not deployed 802.1X, or to bypass single-layer authentication mechanisms by simulating legitimate device interaction processes through protocol reverse engineering.
[0003] Furthermore, due to a lack of deep understanding of the device's business logic, traditional traffic monitoring technologies struggle to effectively identify abnormal behavior under encrypted protocols (such as low-rate DDoS attacks disguised as legitimate business operations) and cannot perform cross-layer verification by associating with the business system status, thus creating blind spots in security defense.
[0004] At the attack handling level, existing solutions mostly adopt a single blocking strategy (such as IP blacklists), which lacks the ability to accurately locate physical access points, making it difficult to quickly isolate the attack source and repair the corrupted network protocol state (such as ARP entry errors), resulting in significant delays in service recovery.
[0005] Meanwhile, rigid security strategies are difficult to adapt to the dynamic changes in device behavior patterns in differentiated scenarios such as smart homes and industrial IoT, resulting in problems such as increased false blocking rates or missed detection of new attacks.
[0006] The aforementioned technical deficiencies prevent existing solutions from meeting the high-level security requirements of the Internet of Things (IoT) environment for real-time performance, accuracy, and business continuity. Summary of the Invention
[0007] To address the shortcomings of existing technologies, this application provides an IoT access control system with proactive security capabilities, which solves the technical problem that existing IoT security solutions cannot simultaneously ensure device identity trustworthiness, business behavior compliance, and real-time blocking and repair of attacks.
[0008] To achieve the above objectives, this application provides an IoT access control system with proactive security capabilities, including an IoT security gateway deployed at the boundary of a Layer 2 access network and communicating with at least one access switch, a WLAN controller, and an external IoT service system. The IoT security gateway includes:
[0009] The port authentication module is used to perform Layer 2 or Layer 3 access authentication on IoT devices connected to the access switch or WLAN AP according to a preset access authentication policy.
[0010] The IoT traffic monitoring module is used to dynamically match the behavior of IoT devices based on the traffic feature sequence corresponding to the service type after the IoT devices have passed access authentication, and to determine the legitimacy of the IoT devices within a preset time period.
[0011] The IoT device verification interface module is used to interact with external IoT business systems to verify the registration and operational status of IoT devices at the business layer; and
[0012] The proactive defense execution module is used to trigger access blocking operations against unauthorized devices based on traffic monitoring and service verification results, and to restore the status of affected network devices.
[0013] Preferably, the access authentication strategy of the port authentication module includes at least one of the following methods:
[0014] Layer 2 authentication of IoT devices' MAC addresses is performed using a RADIUS server; and
[0015] Verify the validity of the MAC address of the IoT device and its associated network layer parameters, including IP address allocation method or VLAN configuration, and block devices that fail the verification from accessing the external network.
[0016] Preferably, the method for generating the flow characteristic sequence includes:
[0017] Define a multi-stage protocol interaction sequence based on the service type of the IoT device, including broadcast messages, time synchronization requests, domain name resolution behavior, and encrypted session establishment procedures during the IoT device startup phase; and
[0018] The IoT traffic monitoring module determines the legality of IoT device behavior by detecting whether IoT devices trigger protocol interaction processes in sequence within a preset time period.
[0019] Preferably, the IoT device verification interface module performs the following operations:
[0020] Submit the MAC address, IP address, and VLAN information of the IoT devices to the corresponding IoT business system; and
[0021] Receive the verification results of IoT devices returned by the IoT business system, including at least one of the IoT device's registration status and the validity of the current session.
[0022] Preferably, the blocking operations of the proactive defense execution module include:
[0023] For wired devices connected via physical ports, send a port shutdown command to the corresponding access switch;
[0024] For wireless access devices, send a blacklist addition command to the WLAN controller to block the connection of the wireless access devices;
[0025] Issue a Layer 3 ACL filtering rule within the VLAN to which the device belongs to restrict the device's network access permissions.
[0026] Preferably, the restoration of network device status includes:
[0027] When an ARP spoofing attack is detected, a legitimate ARP advertisement message is broadcast to all devices within the attacked VLAN, overwriting the ARP entries forged by the illegal device.
[0028] Preferably, the IoT security gateway also includes a network element management module, used for:
[0029] Maintain the topology information and port connection relationships of access switches and WLAN APs;
[0030] Based on the MAC address of the illegal device, combined with port authentication records and network element topology information, a blocking command is generated for a specific access port or wireless access point.
[0031] Preferably, the IoT access control system achieves device access traceability in the following ways:
[0032] For wired devices, query the access switch and port information in the port authentication record based on their MAC address;
[0033] For wireless devices, the access location or blocking execution point is determined based on the access point association information provided by the WLAN controller.
[0034] Preferably, dynamic behavior matching of traffic feature sequences includes:
[0035] For encrypted session traffic, a traffic baseline model corresponding to the service type is established based on at least one of its packet length, transmission frequency, and session duration.
[0036] When the device traffic deviates from the traffic baseline model by more than a preset threshold, a secondary verification or blocking operation is triggered.
[0037] This application also provides an IoT access control method with active security capabilities, comprising the following steps:
[0038] Perform access authentication on IoT devices requesting network access, including at least one of MAC address authentication or IP-MAC binding verification;
[0039] For IoT devices that have passed access authentication, dynamic behavior matching of IoT devices is performed based on the traffic feature sequence corresponding to their business type, and the traffic behavior of IoT devices is judged within a preset time period to determine whether the traffic behavior of IoT devices meets expectations.
[0040] When the traffic behavior of an IoT device is successfully matched, the identification information of the IoT device is submitted to the corresponding IoT business system for secondary verification to obtain the registration and operation status of the IoT device at the business layer.
[0041] The legitimacy of IoT devices is determined based on the results of the secondary verification. If the secondary verification fails, proactive blocking operations are triggered, including closing the device's access port or adding network layer filtering rules; and
[0042] Perform repair operations on network anomalies caused by unauthorized device access, including broadcasting legitimate network protocol messages to cover up information forged by the unauthorized device. Attached Figure Description
[0043] Figure 1 is a schematic diagram of the structure of the IoT access control system with active security capabilities according to this application;
[0044] Figure 2 is a schematic diagram of the IoT traffic monitoring process of this application;
[0045] Figure 3 is a schematic diagram of the active defense process of this application;
[0046] Figure 4 is a schematic diagram of an example of the IoT active security gateway of this application;
[0047] Figure 5 is a schematic diagram of the method flow of this application. Detailed Implementation
[0048] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.
[0049] Please refer to Figures 1-4. The IoT access control system with proactive security capabilities provided in this application achieves full-process control of IoT devices from access authentication to dynamic behavior monitoring through a layered and collaborative architecture design.
[0050] As shown in Figure 1, the core of this application's system lies in the IoT security gateway, which is deployed in the network infrastructure layer, bypassed by the core switch, or integrated into the network controller. It interacts with the access switch, WLAN controller, and external IoT service systems through protocol interfaces. The following sections, in conjunction with the accompanying figures, detail the functional implementation and interaction logic of each module.
[0051] This IoT security gateway includes a port authentication module, an IoT traffic monitoring module, an IoT device verification interface module, and a proactive defense execution module. The following sections, with reference to the accompanying diagrams, detail the functional implementation and interaction logic of each module.
[0052] In this application, the port authentication module of the IoT security gateway serves as the primary link in device access control, undertaking the functions of identity verification and access control for wired and wireless IoT devices. As shown in Figure 1, this port authentication module is located in the core logic layer of the gateway, interacts with the authentication server through the RADIUS protocol, and works in conjunction with the access switch and WLAN controller to implement dynamic policy distribution.
[0053] The device access authentication process begins with link activation at the physical port or wireless AP. When an IoT device connects to the network for the first time, the access switch or WLAN AP will report the IoT device's MAC address and access location information (such as the switch port number or the AP's BSSID) to the port authentication module.
[0054] In a hotel IPTV network scenario, when an IPTV set-top box connects to port 6 of a switch, the switch sends the set-top box's MAC address (e.g., 00:1A:2B:3C:4D:5E) and the switch's port information to the gateway via an SNMP Trap message. The port authentication module then initiates an authentication request to the pre-configured RADIUS server, carrying parameters such as the device's MAC address and access port / VLAN. The RADIUS server returns the authentication result based on a pre-configured whitelist policy (e.g., only allowing devices with MAC addresses registered in the hotel's asset database). If authentication is successful, the port authentication module writes the device information into the port authentication record table. Each record in the table contains fields such as "MAC address, access network element type (switch / AP), physical port or AP identifier, associated VLAN, and first authentication timestamp," forming a complete digital profile of the device access.
[0055] The dynamic network layer parameter validity verification mechanism continues to run after the device passes Layer 2 authentication, covering the compliance verification of IP address allocation methods and VLAN configurations. The port authentication module maintains the association between the device's MAC address and network layer parameters by monitoring ARP packets, DHCP interactions, and VLAN identification information in the device's communication traffic. For example, in strong-binding mode, for IPTV devices configured with static IPs or DHCP reserved IPs (MAC address 00:1A:2B:3C:4D:5E), the port authentication module verifies whether its actual IP address (192.168.10.5) matches the pre-registered address. In weak-binding mode, for smart thermostats that have passed MAC authentication (MAC address 00:0A:95:9D:68:16), it verifies whether the dynamically obtained IP address comes from the pre-authorized DHCP address pool (e.g., 192.168.10.0 / 24) and checks whether the VLAN to which its communication traffic belongs matches the service type (e.g., environmental sensors are only allowed to access VLAN 200).
[0056] This process is achieved by parsing the VLAN configuration table of the access switch port and the VLAN information in the device traffic. For example, when an IPTV set-top box (MAC address 00:1A:2B:3C:4D:5E) sends a data packet, the module extracts the VLAN ID (e.g., 900) from its traffic and compares it with the predefined service rules (IPTV devices should belong to VLAN 900). If an unauthorized VLAN ID is detected (e.g., device traffic carrying a VLAN 950 tag), the module will trigger an alarm and restrict its access permissions.
[0057] The authentication failure handling strategy is implemented in stages based on the type of anomaly. For devices that fail RADIUS authentication (e.g., unregistered MAC address), the port authentication module directly sends a port close / unassociation command to the access switch or WLAN controller, preventing them from further accessing the network. For devices that fail network layer parameter verification (e.g., unauthorized IP address or VLAN privilege exceeding), the port authentication module adopts a progressive control approach: upon the first anomaly, only a log is recorded and the IoT traffic monitoring module is notified to strengthen monitoring; if the same device triggers an anomaly again within a preset time period (e.g., within 5 minutes), it is upgraded to Layer 3 ACL filtering, restricting its access to core business systems. Such devices will be marked as having a "suspicious state," and their subsequent traffic will be redirected to an isolation zone for deep packet inspection.
[0058] The dual authentication mechanism, employing both MAC whitelist authentication and dynamic IP-MAC binding verification, effectively defends against spoofed device access (such as MAC address cloning attacks). Even if attackers bypass Layer 2 authentication, the system can still trigger alarms through Layer 3 IP change detection, significantly improving the accuracy of identity management compared to traditional single authentication methods and reducing the risk of unauthorized devices entering the network from the source.
[0059] Data table structure design and state synchronization are fundamental to the efficient operation of the port authentication module. The port authentication record table adopts a hash index structure, using the MAC address as the primary key to achieve fast lookup with O(1) complexity, supporting real-time location of device access during attack events. Each record in the table contains the following fields:
[0060] Access network element type (switch / AP);
[0061] Physical port or AP identifier (such as switch port number, AP BSSID);
[0062] Associated VLAN;
[0063] Extended information for wireless devices (when the access network element is an AP, it records signal strength, associated timestamps, etc., and the data comes from the user Station table of the WLAN controller);
[0064] This table is linked to the gateway's IoT device table via a foreign key. When a device's status is updated in the IoT traffic monitoring module (e.g., changing from "authenticated" to "abnormal"), the port authentication module synchronously updates its handling policy (e.g., closing the port or adding ACL rules). This two-way data synchronization mechanism ensures consistency in the understanding of device status among all modules, avoiding policy conflicts caused by information lag.
[0065] Through the above implementation methods, the port authentication module not only achieves strict verification of device identity, but also constructs a multi-layered defense system through dynamic binding verification and hierarchical handling strategies. In scenarios where attackers attempt to access switch ports or wireless APs by forging MAC addresses, the module can accurately execute blocking operations based on real-time authentication data and network status awareness, laying the foundation for collaborative defense by subsequent modules.
[0066] The IoT traffic monitoring module in this application serves as the core decision-making unit for dynamic security defense. Through multi-dimensional behavioral modeling and real-time traffic analysis, it accurately determines the legitimacy of services provided by connected devices. As shown in Figure 2, this IoT traffic monitoring module continuously monitors devices within critical time windows after they connect to the network, based on preset traffic characteristic sequences and dynamic baseline models, and forms a closed-loop linkage with the port authentication module and the IoT device verification interface module.
[0067] The mechanism for constructing and loading the traffic feature template library is fundamental to the module's dynamic behavior matching. For IoT devices of different service types (such as IPTV terminals, smart speakers, and environmental sensors), the IoT traffic monitoring module predefines differentiated protocol interaction sequence templates. Taking hotel IPTV equipment as an example, its standard traffic feature template includes a four-stage protocol chain:
[0068] 1. SSDP Broadcast Phase: When the device starts up, it sends an SSDP discovery message to 239.255.255.250. The message contains the device model identifier (e.g., NT:urn:schemas-upnp-org:device:IPTVDeviceV1).
[0069] 2. NTP Time Synchronization Phase: Initiate a time request to the preset NTP server (e.g., 192.168.10.100) to ensure that the device clock is synchronized with the business system;
[0070] 3. DNS resolution phase: Resolve the business system domain name (e.g., api.iptv-hotel.com) to obtain the server IP address;
[0071] 4. HTTPS Business Login Phase: Establish a TLS connection with the business system and send an HTTPS POST request containing the device serial number and authentication token.
[0072] Once a device is authenticated via the port, the IoT traffic monitoring module loads the corresponding template based on its VLAN (e.g., VLAN 950) and device type (obtained from the port authentication record table). The template is stored as a Finite State Machine (FSM), with each state corresponding to the expected behavior of a protocol phase. For example, the initial FSM state of an IPTV device is "Waiting for SSDP broadcast." Upon detecting a matching SSDP packet, the state transitions to "Waiting for NTP request," and a countdown clock is started.
[0073] The sliding detection algorithm under time window constraints is used to verify whether device behavior conforms to the temporal logic of the feature sequence. The IoT traffic monitoring module maintains an independent detection timeline for each device.
[0074] 1. When the device enters the traffic monitoring phase, the IoT traffic monitoring module initializes the sliding time window (default length T = 30 seconds), and the window starts at the capture time of the first protocol event (such as SSDP broadcast);
[0075] 2. During the window period, the IoT traffic monitoring module listens for all messages sent by the device and attempts to match the protocol phases in the template in sequence. For example, after detecting an SSDP broadcast, the module expects to capture an NTP request message within a subsequent Δt time (e.g., 5 seconds).
[0076] 3. If the device triggers all protocol stages in sequence (such as SSDP→NTP→DNS→HTTPS) within the window period, its behavior is deemed legal and its status is marked as "authenticated".
[0077] 4. If the window times out or an abnormal protocol order is detected (such as skipping NTP and directly initiating an HTTPS request), an exception event is triggered, and the secondary verification process is started.
[0078] Based on the pre-defined multi-protocol interaction sequence (such as SSDP→NTP→HTTPS) for business types, combined with time-series window constraints and traffic baseline modeling, hidden threats such as replay attacks and protocol tampering can be identified. For example, even if an attacker impersonates a legitimate device to complete the initial authentication, the dynamic behavior model will still determine it as abnormal because it cannot reproduce the complete business behavior chain (such as skipping NTP synchronization and directly initiating an HTTPS request).
[0079] To improve detection efficiency, the IoT traffic monitoring module adopts a multi-threaded parallel processing mechanism: traffic analysis for each device runs in an independent thread, and the threads exchange key events (such as protocol phase completion notifications) through shared memory, avoiding performance bottlenecks caused by global locks.
[0080] The construction of a dynamic baseline model for encrypted traffic solves the problem of traditional solutions being invisible to encrypted protocols such as HTTPS. When a device enters the HTTPS phase, the IoT traffic monitoring module establishes a traffic baseline using the following non-intrusive method:
[0081] 1. Metadata Analysis: Analyze the data packet length distribution during the TLS handshake phase. For example, the Client Hello message length of a legitimate IPTV device is typically 512±64 bytes, while a forged short message by an attacker might only occupy 200 bytes;
[0082] 2. Transmission Behavior Modeling: Record the duration of HTTPS sessions, the ratio of uplink to downlink packets, and the transmission interval. For example:
[0083] Login phase: The device completes authentication through a short connection. The connection is closed immediately after a single HTTPS request (such as POST / auth), and the uplink data packets account for more than 90% (including encrypted credentials and device fingerprints).
[0084] Business interaction phase: Differentiated modeling based on service type:
[0085] Command-type devices (such as smart switches): use short connections, transmit a payload of less than 512B in a single HTTPS request (such as PUT / state), and the connection duration is less than 2 seconds;
[0086] Streaming devices (such as surveillance cameras): After logging in, a long connection is established, and data frames are continuously sent through chunked encoding. The ratio of uplink to downlink traffic is close to 1:20 (downlink traffic is mostly control commands).
[0087] 3. Anomaly Threshold Calculation: The judgment threshold is dynamically adjusted based on historical data. For example, if the average data volume of a device over N consecutive sessions (N=5) is Q, then the anomaly threshold is set to 0.7Q. When the real-time traffic is lower than this value, a low traffic alarm is triggered.
[0088] When encrypted traffic deviates from the baseline model, the IoT traffic monitoring module will not attempt to decrypt the content (to avoid privacy compliance risks), but will instead mark the device as "suspicious" and initiate secondary verification in the business system.
[0089] The coordination mechanism with the proactive defense execution module ensures that detection results can be translated into defensive actions in real time. When the module determines that the device behavior is abnormal (such as failure to complete a protocol sequence or deviation from the traffic baseline), the following linked operations are executed:
[0090] 1. Event Log Generation: Records exception timestamps, protocol phase deviation details, and original message digests (such as SSDP message header hash values), and stores them in the security event database;
[0091] 2. Verification request trigger: Submit device identification information to the external business system through the IoT device verification interface module to request secondary verification (such as confirming whether the IPTV device has been bound to a user).
[0092] 3. Preloaded defense instructions: If the business system responds with a timeout (e.g., network interruption), the module pre-generates blocking instructions (e.g., three-layer ACL rules) based on the local policy library. After the business system recovers, the verification request is resent to avoid defense delay.
[0093] Taking the IPTV attack scenario in Figure 4 as an example, when an attacker forges a legitimate MAC address to access the network and sends an ARP Flood, the IoT traffic monitoring module detects the following anomaly:
[0094] No SSDP broadcast or NTP request was triggered (deviation from IPTV feature template);
[0095] HTTPS traffic length is significantly lower than the baseline value (e.g., sending only 100 bytes of invalid requests).
[0096] The module immediately generates an abnormal event and, in conjunction with the proactive defense execution module, closes the attacker's access port (port 6) and simultaneously broadcasts an ARP repair message to restore the network to normal operation.
[0097] By integrating standardized APIs with IoT business systems (such as room control platforms and video management systems), the system verifies the registration status and operational permissions of devices at the business layer. For example, when an attacker steals the MAC address of a legitimate device to pass network layer authentication, the system calls the business interface to verify whether the device has actually completed user binding, thus solving the problem of missing business layer verification caused by the unresolvable encrypted traffic in traditional solutions.
[0098] Through the aforementioned technologies, the IoT traffic monitoring module can not only identify traditional network layer attacks (such as protocol tampering and replay attacks), but also effectively deal with advanced threats such as encrypted traffic spoofing and low-rate slow attacks.
[0099] The IoT device verification interface module in this application serves as the core hub for cross-system trusted verification. It collaborates with external business systems through standardized APIs to verify the business-layer legitimacy of devices, thus resolving the security blind spots caused by the separation of network layer and business layer information in traditional solutions. As shown in Figure 1, this IoT device verification interface module is deeply integrated with the port authentication module and the proactive defense execution module, forming a closed-loop verification chain of "network layer access → business layer authentication".
[0100] When the IoT traffic monitoring module detects abnormal device behavior or triggers secondary verification conditions (such as a deviation from the encrypted traffic baseline), the verification interface module immediately initiates the business system interaction process. As shown in Figure 4, in a hotel IPTV network scenario, if a device passes MAC authentication and completes SSDP broadcast, but its subsequent HTTPS traffic length is significantly lower than the historical baseline, the verification interface module will construct a verification request containing the device's MAC address, VLAN, and IP address. The request body is encapsulated in JSON-RPC 2.0 format and sent to the IPTV business system via the HTTPS channel to ensure the integrity and confidentiality of the transmission process.
[0101] Upon receiving a request, the business system queries its device registration database to verify whether the device has completed user binding (e.g., associated with a specific room number) or holds a valid session token. If the device is legitimate, the system returns a response containing a business status identifier, and the verification interface module immediately updates the status in the IoT device table to "Business authentication passed." If the device is not registered or the session has expired, the verification interface module immediately triggers a blocking operation in conjunction with the proactive defense execution module.
[0102] Timeout and fault tolerance strategies ensure the robustness of the verification process. The verification interface module sets a dynamic timeout threshold (usually 3-5 seconds) for each verification request. If the business system does not respond within the time limit, the following tiered processing is performed:
[0103] 1. First timeout: Enable local cache query to check the device's historical authentication records. If a recent successful authentication record exists (e.g., within 30 minutes), temporarily mark it as "pending review" and allow limited network access (e.g., only communication to the business system is allowed);
[0104] 2. Continuous timeout: If the same device triggers timeout multiple times (e.g., 3 times), it will be determined as "business system unreachable" and the preset security policy will be executed (e.g., blocking the device and alerting the administrator).
[0105] 3. Business system failure recovery: When the recovery of business system services is detected (such as successful continuous heartbeat detection), the verification interface module automatically resends the backlog of pending verification requests to ensure state synchronization.
[0106] As shown in Figure 4, when the IPTV system is temporarily unavailable due to maintenance, the verification interface module allows authenticated devices to maintain basic business functions (such as TV channel playback) according to the caching policy, but prohibits them from accessing high-risk interfaces (such as the payment module) until the business system is restored and full verification is completed.
[0107] Real-time synchronization of verification results with network policies ensures consistency in cross-layer security decisions. The module pushes verification results to relevant modules via shared memory and message queues.
[0108] 1. Port authentication module: If service authentication fails, notify it to update the port authentication record table, add the device's MAC address to the temporary blacklist, and prevent it from reconnecting;
[0109] 2. Proactive defense execution module: Triggers precise blocking commands (such as closing a specified switch port) and synchronizes device information to the WLAN controller blacklist;
[0110] 3. IoT Traffic Monitoring Module: Adjust the detection strategy of this device (such as shortening the traffic analysis window) to improve the detection sensitivity of replay attacks.
[0111] The proactive defense execution module directly controls network devices through protocol interfaces (SNMP / NETCONF) to achieve simultaneous execution of physical isolation of unauthorized devices (such as port closure) and network status restoration (ARP entry reset).
[0112] Taking the attack scenario in Figure 4 as an example, when the attacker forges the MAC address of the IPTV device and passes port authentication, the verification interface module queries the business system and finds that the MAC address is not bound to any room. It immediately sends a blocking command to the proactive defense execution module and marks the MAC address as "permanently disabled" in the port authentication record table, completely eliminating the possibility of it accessing the network again.
[0113] Through the aforementioned technologies, the IoT device verification interface module breaks down the data barriers between the network layer and the business layer, enabling security decisions to be based not only on device identity and network behavior, but also on its actual operating status in the business system.
[0114] The proactive defense execution module in this application serves as the final execution unit for security response. Through a collaborative mechanism of precise blocking and intelligent repair, it ensures that unauthorized devices are isolated immediately and the network status is quickly restored. As shown in Figure 3, this module receives abnormal event notifications from the IoT traffic monitoring module and the IoT device verification interface module. It generates differentiated defense commands based on the device access type (wired / wireless) and attack characteristics, and coordinates with underlying network devices to execute operations through standardized protocol interfaces. When a malicious device is detected, the proactive defense execution module calls the access location information (such as AP identifier and switch port) in the port authentication record table, and issues blocking commands or generates location reports according to policy requirements, achieving end-to-end access tracing capabilities.
[0115] When the IoT traffic monitoring module detects that an IPTV device (MAC:00:1A:2B:3C:4D:5E) has not completed the protocol interaction sequence (such as missing NTP request) within the preset window period, or when the IoT device verification interface module returns that the device is not registered, the proactive defense execution module initiates a multi-stage response process.
[0116] First, the IoT device verification interface module queries the port authentication record table to locate the physical access point of the device—for example, confirming that it accesses VLAN 950 through port 6 of the access switch.
[0117] Subsequently, the IoT device verification interface module selects a blocking strategy based on the device type:
[0118] For wired routing devices, directly disable their access switch ports (such as port 6) via the SNMP protocol;
[0119] For wireless devices, a disconnect command is sent to the WLAN controller, specifying the target AP to perform blocking (e.g., AP-07). Simultaneously, based on security policy requirements, the blocking execution point or physical location information is selectively recorded.
[0120] Basic blocking mode: Only the associated AP identifier (BSSID) and blocking time are recorded;
[0121] Location Enhancement Mode: Parses the signal strength and signal-to-noise ratio data in the user's Station table, and combines it with the AP deployment topology map (e.g., AP-07 is located in the east corridor on the 2nd floor) to generate approximate location coordinates of the device for security event visualization.
[0122] The network status restoration mechanism is activated immediately after the blocking operation is completed to eliminate the residual effects of the attack. For example, when an ARP spoofing attack is detected, causing some devices in VLAN 950 to be unable to access IPTV services, the module sends a legitimate ARP advertisement packet (source IP: 192.168.10.100, source MAC: 00:0A:95:9D:68:16) to all access devices in that VLAN, overwriting the attacker's spoofed ARP entries. As shown in Figure 4, this packet is sent in broadcast form, and each switch forwards it on its local port, ensuring that the ARP cache of the compromised devices is forcibly updated. The triggering conditions for the restoration operation include: detecting an abnormal ARP request / response ratio or a surge in ICMP unreachable packets in a specific VLAN. The module dynamically adjusts the restoration frequency by analyzing the status logs of network devices (such as the port error count of switches) to avoid network congestion caused by excessive broadcasting.
[0123] The logic for generating and optimizing defense commands ensures the accuracy and timeliness of response actions. The module maintains a defense policy library; each policy includes attack characteristics (e.g., "ARP spoofing"), device type (e.g., "wired"), and action sequence (e.g., "close port → ARP repair"). When an abnormal event is received, the module selects the optimal policy using a feature matching engine.
[0124] 1. Exact Match: If the event characteristics match the policy library exactly (e.g., "MAC spoofing + ARP spoofing"), the preset action is invoked directly;
[0125] 2. Fuzzy matching: For new types of attacks (such as "Unidentified Protocol DoS"), enable default actions (such as isolating to a honeynet) based on the device risk level (calculated by the traffic monitoring module);
[0126] 3. Learning Mode: When an administrator manually handles an unidentified attack, the module records the operation sequence and generates a new strategy for automatic invocation in subsequent similar events.
[0127] Taking the IPTV attack scenario in Figure 4 as an example, after the module identifies the attack characteristics as "MAC spoofing + ARP Flood", it accurately matches the "close port + broadcast ARP repair" instructions in the policy library and marks the effectiveness of the handling in the log (if no similar alarm is detected within the next 5 minutes, it is considered successful).
[0128] In collaboration with the network element management module, intelligent blocking based on network topology awareness is achieved. As shown in Figure 1, the network element management module provides a network-wide device topology map (such as switch interconnection relationships and AP deployment locations). The proactive defense execution module uses this information to optimize command delivery paths. For example, when a wireless attack device is detected associating with an AP group (such as AP1-AP3 in a hotel lobby), the proactive defense execution module not only adds the device's MAC address to the blacklist but also issues temporary power reduction commands to adjacent APs, limiting the attacker's physical access range. For attacks spreading across switches (such as worm viruses), the proactive defense execution module locates the core aggregation node based on the topology map and prioritizes blocking upstream ports to minimize the impact.
[0129] To improve fault tolerance and rollback mechanisms and ensure the reliability of defense operations, the network element management module sets up execution status tracking for each defense command:
[0130] Command confirmation: Wait for the network device to return a successful operation response (such as SNMP SET-ACK). If no confirmation is received after a timeout, try a backup protocol (such as NETCONF) to resend the command.
[0131] Abnormal rollback: If the blocking operation causes network partitioning (such as accidentally shutting down a core switch port), the module will automatically roll back the command based on topology dependency analysis and initiate an administrator alarm;
[0132] Log traceability: All defense actions are recorded in the security audit database, including the original message digest, the handling timestamp, and the operator identifier (automatic / manual), supporting post-attack chain reconstruction.
[0133] When the network element management module detects that a port shutdown operation has caused a critical link within the service VLAN to be interrupted, it immediately triggers a rollback: the port is reopened and switched to ACL filtering mode (restricting the destination IP to the service system address), restoring critical service connectivity while maintaining security.
[0134] Through the aforementioned technologies, the proactive defense execution module achieves second-level attack containment.
[0135] The network element management module of this application serves as the intelligent control hub for network infrastructure. Through real-time topology discovery and protocol adaptation technologies, it enables unified management and status synchronization of physical nodes such as switching devices and wireless controllers across the entire network.
[0136] The core function of the network element management module is to dynamically build and maintain a global network topology view. When the gateway starts up or detects a network change event (such as a change in switch port status), the module automatically discovers active devices in the current network using standard protocols (such as LLDP and CDP). For example, by listening to LLDP packets sent by access switches, the module identifies its neighboring devices (such as core switches and WLAN controllers) and interconnection ports, generating a tree-like topology diagram. This view is stored in a graph database, with node attributes containing metadata such as device model, management IP, and firmware version, and edge attributes recording connection ports, VLANs, and link bandwidth information. The real-time nature of the topology data is ensured through a dual mechanism of periodic polling (every 5 minutes) and event-triggered updates (such as port failure alarms).
[0137] Through the aforementioned technologies, the network element management module transforms discrete network devices into programmable intelligent entities, enabling IoT security gateways to implement collaborative defense from a global perspective.
[0138] As shown in Figure 5, this application also provides an IoT access control method with active security capabilities, which achieves active security protection through a five-layer progressive verification mechanism.
[0139] During the initial access phase (S1), the system performs MAC address whitelist authentication and IP-MAC binding verification on the devices. For example, when a device connects to the access switch, the gateway verifies whether its MAC address is registered through the RADIUS server and monitors whether its IP address matches the binding table. Once authenticated, the device enters the dynamic behavior monitoring phase (S2). The gateway loads a preset traffic characteristic sequence template based on the device's service type (e.g., smart lighting, video surveillance) and verifies within a 30-second window whether it triggers protocol interactions in sequence (e.g., a smart speaker needs to complete DHCP requests, NTP synchronization, and HTTPS encrypted connections sequentially).
[0140] When traffic behavior is compliant (S3), the system submits the device identifier to an external IoT business system (such as a hotel room status management platform) to verify its business layer status (such as whether it is bound to a valid room number or holds an unexpired session token). If the business system returns verification failure (S4), the gateway immediately coordinates with network devices to perform blocking (such as closing the access port or adding it to the blacklist), and triggers a repair mechanism for network pollution caused by attacks (such as ARP table tampering) (S5), restoring the network to normal status by broadcasting legitimate protocol messages, forming a complete closed loop of "authentication-monitoring-verification-blocking-repair". This method, through multi-level verification and real-time response, balances the trustworthiness of device identity with the compliance of business behavior.
[0141] This application optimizes the system through protocol adaptation plugins, dynamic template loading mechanisms, and topology awareness strategies, enabling it to flexibly adapt to different IoT business scenarios (such as smart buildings and industrial IoT). For example, when adding a new device type, only the traffic feature template library and business system interface configuration need to be updated, without modifying the underlying architecture, significantly reducing deployment and maintenance complexity.
[0142] Although embodiments of this application have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of this application, the scope of which is defined by the appended claims and their equivalents.
Claims
1. An IoT access control system with proactive security capabilities, comprising an IoT security gateway deployed at the boundary of a Layer 2 access network and communicatively connected to at least one access switch, a WLAN controller, and an external IoT service system, wherein the IoT security gateway comprises: The port authentication module is used to perform Layer 2 or Layer 3 access authentication on IoT devices connected to the access switch or WLAN AP according to a preset access authentication policy. The IoT traffic monitoring module is used to dynamically match the behavior of the IoT device based on the traffic feature sequence corresponding to the service type after the IoT device passes access authentication, and to determine the legality of the IoT device within a preset time period. The IoT device verification interface module is used to interact with the external IoT business system to verify the registration and operating status of the IoT device at the business layer. as well as The proactive defense execution module is used to trigger access blocking operations against unauthorized devices based on traffic monitoring and service verification results, and to restore the status of affected network devices.
2. The IoT access control system with active security capabilities according to claim 1, characterized in that, The access authentication strategy of the port authentication module includes at least one of the following methods: The MAC address of the IoT device is authenticated using a RADIUS server; and Verify the validity of the MAC address of the IoT device and its associated network layer parameters, including IP address allocation method or VLAN configuration, and block devices that fail the verification from accessing the external network.
3. The IoT access control system with active security capabilities according to claim 1, characterized in that, The method for generating the flow feature sequence includes: The protocol interaction sequence is defined according to the service type of the IoT device, including broadcast messages, time synchronization requests, domain name resolution behavior, and encrypted session establishment process during the IoT device startup phase; and The IoT traffic monitoring module determines the legality of the IoT device's behavior by detecting whether the IoT device triggers the protocol interaction process in sequence within the preset time period.
4. The IoT access control system with active security capabilities according to claim 1, characterized in that, The IoT device verification interface module performs the following operations: Submit the MAC address, IP address, and VLAN information of the IoT device to the corresponding IoT business system; and The system receives the verification result of the IoT device returned by the IoT business system, including at least one of the registration status of the IoT device and the validity of the current session.
5. The IoT access control system with active security capabilities according to claim 1, characterized in that, The blocking operations of the active defense execution module include: For wired devices connected via physical ports, send a port shutdown command to the corresponding access switch; For wireless access devices, a blacklist addition command is sent to the WLAN controller to block the connection of the wireless access device; Issue a three-layer ACL filtering rule within the VLAN to which the device belongs to restrict the device's network access permissions.
6. The IoT access control system with active security capabilities according to claim 1, characterized in that, The restoration of the network device's status includes: When an ARP spoofing attack is detected, a legitimate ARP advertisement message is broadcast to all devices within the attacked VLAN, overwriting the ARP entries forged by the illegal device.
7. The IoT access control system with active security capabilities according to claim 1, characterized in that, The IoT security gateway also includes a network element management module, used for: Maintain the topology information and port connection relationships of access switches and WLAN APs; Based on the MAC address of the illegal device, combined with port authentication records and network element topology information, a blocking command is generated for a specific access port or wireless access point.
8. The IoT access control system with active security capabilities according to claim 1, characterized in that, The system achieves device access traceability in the following ways: For wired devices, query the access switch and port information in the port authentication record based on the MAC address of the wired device; For wireless devices, the access location or blocking execution point of the wireless device is determined based on the access point association information provided by the WLAN controller.
9. The IoT access control system with active security capabilities according to claim 1, characterized in that, The dynamic behavior matching of the traffic feature sequence includes: For encrypted session traffic, a traffic baseline model corresponding to the service type is established based on at least one of its packet length, transmission frequency, and session duration. When the device traffic deviates from the traffic baseline model by more than a preset threshold, a secondary verification or blocking operation is triggered.
10. An IoT access control method with active security capabilities, based on the IoT access control system with active security capabilities as described in any one of claims 1-9, characterized in that, Includes the following steps: Perform access authentication on IoT devices requesting network access, the access authentication including at least one of MAC address authentication or IP-MAC binding verification; For IoT devices that have passed access authentication, dynamic behavior matching of the IoT devices is performed based on the traffic feature sequence corresponding to their service type, and it is determined whether the traffic behavior of the IoT devices meets expectations within a preset time period. When the traffic behavior of the IoT device is successfully matched, the identification information of the IoT device is submitted to the corresponding IoT business system for secondary verification to obtain the registration and operation status of the IoT device at the business layer. The legality of the IoT device is determined based on the result of the secondary verification. If the secondary verification fails, an active blocking operation is triggered, including closing the device access port or adding network layer filtering rules. Perform repair operations on network anomalies caused by unauthorized device access, including broadcasting legitimate network protocol messages to cover up information forged by the unauthorized device.