# IoTBystander: A Non-Intrusive Dual-Channel-Based Smart Home Security Monitoring Framework
## 5 Event Recognition
### Traffic-Based Event Recognition (TER)  
The network traffic patterns of event notification messages are generally fixed, which makes the _offline signature extraction and online signature matching_ mechanism widely used for identifying IoT device events from payload-encrypted traffic [52; 53; 54; 55; 56; 57]. However, approaches that rely on protocol-specific features to construct traffic signatures often lack generalizability across diverse IoT environments as IoT devices employ a wide range of communication protocols. In this context, packet-level signatures, represented as Directional Frame Length (DFL) sequences--i.e., sequences consisting of the packet direction and length--have proven to be effective [58]. In this work, we adapt this signature construction method for fingerprinting IoT device events. Figure 4: Pipeline of audio-based physical event recognition. **Signature Extraction. ** Event signatures are learned in an offline manner. Each event is manually triggered by operating the device, while a traffic sniffer component captures the traffic traces associated with the device's communication of the triggered event to the platform. By integrating the traffic sniffer atop the home router, we can capture wireless traffic from IoT devices after decrypting the 802.11 traffic, thus gaining access to packet-level details such as MAC addresses, IP addresses, timestamps, and packet lengths. In our implementation, we use TShark [59] to capture traffic packets and store the 5-tuple information (as defined in Equation (1)) in.tsv-formatted files for subsequent analysis. To extract event-specific traffic signatures, only packets within the communication session between the device and the platform are considered. To this end, MAC and IP addresses are employed to filter out noisy packets. \[\textit{feature\_vec}=[\textit{Packet\_length},\textit{MAC\_src},\textit{MAC \_dst},\textit{IP\_src},\textit{IP\_dst}] \tag{1}\]  
In our setup, IoT devices are connected to a Raspberry Pi, which functions as the home router, as illustrated in Figure 5. To ensure the accuracy and generalizability of the extracted signatures, each event is manually triggered 50 times. When an event is triggered, up to 30 related packets are recorded, capturing their 5-tuple information. To exclude irrelevant packets, we use the MAC and IP addresses, and we label the direction of each packet as \(C\) (from the device to the platform) or \(S\) (from the platform to the device). The DFL sequences, which are essential for identifying an event, are then extracted as the event's signature. The extracted signatures are provided in Table 5.  
We observe that the signature (denoted as \(S_{1}\)) extracted using the approach from [58], which only incorporates packets sent immediately when an event is triggered, has limitations in certain scenarios. For instance, the events _switch-on_ and _switch-off_ of a _xiaomi smart plug_ generate identical patterns \"S-223 C-207 S-54\" in \(S_{1}\), making it impossible to distinguish between them. To overcome this limitation, we enhance the signature construction by including additional packets that typically appear a few seconds after the immediate packets. These additional packets form a lagging DFL sequence, denoted as \(S_{2}\). Consequently, when \(S_{2}\) is required, the original signature \(S_{1}\) is expanded to \(S_{1}\cdots S_{2}\). For example, additional sequences such as \"C-223 S-143 C-54\" and \"C-111 S-111 C-54\" are included in the extracted signature to differentiate between the _switch-on_ and _switch-off_ events of the _xiaomi smart plug_ (see Table 5).