IoTAthena: Unveiling IoT Device Activities from Network Traffic

The user can also manually operate the device in the traditional way, such as locking the smart lock manually. This action causes the device to update its status to the cloud server immediately following the action. In addition, the user can communicate directly with the device locally through a non-WiFi communication channel, such as Bluetooth or ultrawideband (UWB) when the user is in the vicinity of the device. This action also causes device initiated status updates. Furthermore, automatic device operations such as the smart lock’s autolocking function also introduce status update traffic. These types of device initiated communications are illustrated by the dashed red line. There also exists traffic introduced by device background operations such as device firmware update checks. We use the dotted red line between the smart lock and the cloud server to illustrate these data flows.

IoTAthena collects the network traffic at the programmable home router, which enables the capture of incoming and outgoing packets of all above mentioned device-related operations. The smart home router is a desirable centralized location for data collection, considering its switching and routing function, sufficient computational and processing capacities, and the design transparency to IoT devices and apps. In our experiments, we used Linksys WRT1900AC WiFi home routers which run the open-source Linux-based OpenWrt operating system for network traffic collection. The data processing and analysis were performed offline in this study. One of our future work is designing and implementing a prototype system on commodity home routers to evaluate the real-time feasibility of IoTAthena for unveiling IoT device activities on the fly.

We carefully studied the network traffic within each individual traffic cluster of an IoT device. We can clearly observe the network traffic one would anticipate for normal IoT device activities, e.g., users issuing locking or unlocking commands for August Lock via the smartphone app. Surprisingly, we also discovered a significant amount of network traffic when there is no human-triggered or environment-triggered activity. We use the term background traffic to denote such network traffic, i.e., network traffic not triggered by human or environment. In order to gain a thorough understanding of IoT background traffic, we left the devices in our controlled smart home environment without any human interactions for one week and consider the network traffic cluster of each IoT device during this “silent” period as background traffic. By separating IP data packets based on the destination (and source) ports of the outgoing (and incoming) traffic, we observed that these IoT devices typically exchange messages with the remote cloud servers on the well-known application ports such as 22/TCP (SSH), 53/UDP (DNS), 80/TCP (HTTP), 123/UDP (NTP), 5353/UDP (mDNS). This observation leads us to classify IoT background traffic into three categories: management and service, signal and update, and random noise.

The management and service traffic is mainly used to manage and maintain the devices, e.g., periodical time synchronizations with NTP servers. The signal and update traffic corresponds to keep-alive signals and regular firewall update checks between IoT devices and cloud servers. The random noise traffic is mostly generated by other IoT or non-IoT devices in the local home network for a variety of reasons, e.g., ARP requests, SSDP broadcasts, and multicast DNS (mDNS) traffic from Apple Bonjour protocol for automatic device and service discovery.

The background traffic analysis not only removes unnecessary noise for characterizing and generating signatures of IoT device activities, but also sheds light on the potential vulnerabilities of the protocol stacks of mission-critical IoT devices in millions of smart homes. For example, our analysis discovered the usage of non-encrypted and insecure Telnet and HTTP sessions between some camera devices and cloud servers, for logins and firmware update checks. Discovering and mitigating security weaknesses of IoT devices is beyond the scope of this paper.

Fig. 4 illustrates the time interval between the first and second packets (left plot), and the time interval between the second and third packets (right plot), of $1,200$ repeated on activities of TP-Link Plug over a $24$-hour span. We observe that the inter-packet time intervals exhibit stable and consistent patterns, with small variances. However, the time interval between one pair of consecutive packets may significantly differ from that between another pair of consecutive packets. Specifically, the interval between the first and second packets has a mean ($\mu$) of $76.73ms$ and a standard deviation ($\sigma$) of $0.003995ms$, while the interval between the second and third packets has a mean ($\mu$) of $0.02ms$ and a standard deviation ($\sigma$) of $0.000003ms$ for TP-Link Plug’s on activity. The unstable wireless channel between the IoT devices and the home router could result in packet loss and retransmission which contribute to the fluctuation in the LAN inter-packet time intervals. The uncertain number of retransmissions in the MAC layer affects the inter-packet time intervals in our collected traffic log. However, compared with the short wireless transmission delay, the local processing time at the IoT device still dominates the LAN inter-packet time intervals, as we observe from the right plot in Fig. 4. These key observations inspire us to include inter-packet time intervals as an important component in characterizing the signatures of IoT device activities.

We use $p.t$ to denote the timestamp of packet $p$, and use $\widehat{p}$ to denote the $7$-tuple obtained by deleting the first field (timestamp) in $p$. We call $\widehat{p}$ the base packet of packet $p$.

Instead of using $(\widehat{q_{1}},\widehat{q_{2}},\ldots,\widehat{q_{n}})$ and $(\tau_{1},\tau_{2},\ldots,\tau_{n-1})$ to represent a signature, we can equivalently represent the same signature using a sequence of $n$ packets $(\rho_{1},\rho_{2},\ldots,\rho_{n})$, where $\widehat{\rho_{j}}=\widehat{q_{j}}$ for $j=1,2,\ldots,n$ and $\rho_{j+1}.t-\rho_{j}.t=\tau_{j}$ for $j=1,2,\ldots,n-1$. In this representation, the time interval between the $j$th packet and the $j+1$th packet can be uniquely computed by $\tau_{j}=\rho_{j+1}.t-\rho_{j}.t$.

The signature of an IoT device activity is a constant, as defined in Definition 1. The above alternative representation of the signature, however, does not look like a constant in format. For example, for any given real number $c$, $(p_{1},p_{2},\ldots,p_{n})$ and $(\rho_{1},\rho_{2},\ldots,\rho_{n})$ denote exactly the same signature, provided that $\widehat{p_{j}}=\widehat{\rho_{j}}$, $p_{j}.t=\rho_{j}.t+c$, for $j=1,2,\ldots,n$. Since $(p_{1},p_{2},\ldots,p_{n})$ and $(\rho_{1},\rho_{2},\ldots,\rho_{n})$ define exactly the same sequence of $n$ base packets $(\widehat{p_{1}},\widehat{p_{2}},\ldots,\widehat{p_{n}})$ $=$ $(\widehat{\rho_{1}},\widehat{\rho_{2}},\ldots,\widehat{\rho_{n}})$ and exactly the same sequence of $n-1$ inter-packet time intervals $(p_{2}.t-p_{1}.t,p_{3}.t-p_{2}.t,\ldots,p_{n}.t-p_{n-1}.t)$ $=$ $(\rho_{2}.t-\rho_{1}.t,\rho_{3}.t-\rho_{2}.t,\ldots,\rho_{n}.t-\rho_{n-1}.t)$, we can use this alternative representation without losing any accuracy.

Given the above discussions, we will denote a signature of an IoT device activity using an ordered sequence of packets $(q_{1},q_{2},\ldots,q_{n})$, where the timestamp fields are only used to compute the inter-packet time intervals $\tau_{j}=q_{j+1}.t-q_{j}.t$. For this reason, we also call the timestamp fields in a signature relative timestamps. We set $q_{1}.t$ to $0$ for simplicity.

Filtering the background traffic described in Section 4-B, which happens in parallel with the device activity, leads to an ordered sequence of timestamped IP packets exchanged between IoT devices and the cloud servers. Each packet in the sequence carries a variety of traffic features such as the timestamp of each packet, local IP address and port number of the IoT device, remote IP address and port number of the cloud server, protocol, packet length, and the actual application payload of IoT applications which are mostly encrypted for security and privacy reasons. For each packet, we continue to remove features with random and dynamic values due to the protocol designs, e.g., the random local port number at IoT devices in TCP connections with cloud servers and TCP sequence and acknowledge numbers. In addition, we transform certain traffic features to retain the stable values, e.g., converting dynamic IP addresses of load-balanced cloud servers to the canonical remote cloud server names.

The inter-packet time interval $\tau_{j}$ between the $j$th packet and the $j+1$th packet in the signature is set to the mean (over the $100$ tries) of the inter-packet time intervals. To simplify notations, we set $q_{1}.t$ to $0$, and set $q_{j+1}.t=q_{j}.t+\tau_{j}$, $j=1,2,\ldots,n$.

TABLE 1 illustrates the signatures for various activities of the August Lock⁴⁴4In our experiments we noticed firmware updates of IoT devices might cause slight changes on the activity signatures.. Note that we have used the alternative representation of signatures. The signature shown in Fig. 3(a) corresponds to the lower-right box in TABLE 1. The signature shown in Fig. 3(b) corresponds to the lower-left box in TABLE 1. While the sequence of base packets in the signature for Bluetooth (un)locking (illustrated in Fig. 3(b)) is a subset of the sequence of base packets in the signature for WiFi (un)locking (illustrated in Fig. 3(a)), the additional information embedded in the inter-packet time intervals makes it possible to distinguish these two activities. With the aid of additional information on inter-packet time intervals, we can distinguish these two activities from network traffic logs, which are difficult to distinguish using the base packets only.

In light of the end-to-end network latency variations on the Internet [9, 16, 29], we allow an inter-packet time interval tolerance $\epsilon_{j}>0$ as the “safety margin” for the measurement of $q_{j+1}.t-q_{j}.t$ when trying to find a match of a signature in the network log.

Let $j$ satisfy $1<j\leq n$ and $\delta>0$ be a given tolerance. Let $i^{\prime}$ and $i^{\prime\prime}$ satisfy $1\leq i^{\prime}<i^{\prime\prime}\leq m$. We say that $(p_{i^{\prime}},p_{i^{\prime\prime}})$ is a $\delta$-valid match of $(q_{j-1},q_{j})$, if

1. 1.

   $\widehat{p_{i^{\prime}}}=\widehat{q_{j-1}}$, $\widehat{p_{i^{\prime\prime}}}=\widehat{q_{j}}$;

2. 2.

   $|({p_{i^{\prime\prime}}}.t-{p_{i^{\prime}}}.t)-({q_{j}}.t-{q_{j-1}}.t)|\leq\delta$.

Let $\mathbb{S}=(q_{1},q_{2},\ldots,q_{n})$ be a signature. Let $\epsilon=(\epsilon_{1},\epsilon_{2},\ldots,$ $\epsilon_{n-1})$ be the matching tolerance vector, where $\epsilon_{j}$ is the tolerance for the matching of $(q_{j},q_{j+1})$. Let $(l[1],l[2],\ldots,l[n])$ be an increasing sequence of integers indicating the index of the location of a packet in the network log. We say that $(p_{l[1]},p_{l[2]},\ldots,p_{l[n]})$ is an $\epsilon$-valid match of signature $\mathbb{S}$ in log $\mathbb{L}$, if $(p_{l[j]},p_{l[j+1]})$ is an $\epsilon_{j}$-valid match of $(q_{j},q_{j+1})$, for $j=1,2,\ldots,n-1$.

We study the following two related problems:

IoT activity signature matching: Given network traffic log $\mathbb{L}$, signature $\mathbb{S}$, and tolerance vector $\epsilon$ for $\mathbb{S}$, identify all $\epsilon$-valid matches of signature $\mathbb{S}$ in log $\mathbb{L}$.

IoT device activity extraction: Given network traffic log $\mathbb{L}$ and signature set $\mathbb{SS}$, find a sequence of IoT activities $\mathbb{A}_{1},\mathbb{A}_{2},\ldots$, whose execution leads to the network traffic log $\mathbb{L}$.

For a given network traffic log $\mathbb{L}=(p_{1},p_{2},\ldots,p_{m})$ and signature $\mathbb{S}=(q_{1},q_{2},\ldots,q_{n})$, together with a inter-packet time interval tolerance vector $\epsilon$, we compute a DAG $G_{\mathbb{LS}}=(V_{\mathbb{LS}},E_{\mathbb{LS}})$ that captures all $\epsilon$-valid matches of signature $\mathbb{S}$ in log $\mathbb{L}$. The vertex set $V_{\mathbb{LS}}$ contains vertices in the form of $v_{i,j}$, where $p_{i}$ is a potential match of $q_{j}$. The edge set $E_{\mathbb{LS}}$ contains directed edges in the form of $(v_{i,j},v_{k,j-1})$, where $(p_{k},p_{i})$ is an $\epsilon_{j-1}$-valid match of $(q_{j-1},q_{j})$ for $1\leq k\leq i-1$, and there is a directed path from vertex $v_{i,j}$ to a vertex $v_{i^{\prime},1}\in V_{\mathbb{LS}}$ (for some $i^{\prime}\leq i-j+1$).

If $\widehat{p_{i}}\neq\widehat{q_{j}}$, vertex $v_{i,j}$ does not exist. If $\widehat{p_{i}}=\widehat{q_{j}}$, vertex $v_{i,j}$ may exist. Each edge has the form $(v_{i,j},v_{k,j-1})$ for some $k<i$. Hence we have $|V_{\mathbb{LS}}|\leq mn$ and $|E_{\mathbb{LS}}|\leq\frac{m(m-1)(n-1)}{2}$.

In Line 1 of Algorithm 1, both $V_{\mathbb{LS}}$ and $E_{\mathbb{LS}}$ are initialized to $\emptyset$. The algorithm then populates the vertex set and the edge set while looping over the packets $p_{1},p_{2},\ldots,p_{m}$. For each $i$, the algorithm loops over the packets $q_{1},q_{2},\ldots,q_{n}$. When $\widehat{p_{i}}=\widehat{q_{1}}$, $v_{i,1}$ is a vertex in the DAG. For $j=2,3,\ldots,n$, $v_{i,j}$ is a vertex if and only if $\widehat{p_{i}}=\widehat{q_{j}}$ and $(p_{k},p_{i})$ is an $\epsilon_{j-1}$-valid match of $(q_{j-1},q_{j})$ for some $k<i$. In this case, $(v_{i,j},v_{k,j-1})$ is an edge in the DAG.

We use Fig. 5 to illustrate a running example of sigMatch. The goal is to identify all $\epsilon$-valid matches of signature $\mathbb{S}=(q_{1},q_{2},q_{3})$ in log $\mathbb{L}=(p_{1},p_{2},p_{3},p_{4},p_{5},p_{6},p_{7},p_{8})$ with tolerance vector $\epsilon=(1,1)$. In this example, we have $\widehat{p_{1}}=\widehat{p_{3}}=\widehat{p_{4}}=\widehat{q_{1}}$, denoted by the hexagon shape; we also have $\widehat{p_{2}}=\widehat{p_{5}}=\widehat{p_{6}}=\widehat{p_{7}}=\widehat{p_{8}}=\widehat{q_{2}}=\widehat{p_{3}}$, denoted by the square shape. The timestamps (for traffic log) and relative timestamps (for signature) are inside the corresponding shape.

We start from $p_{1}$. Since $\widehat{p_{1}}=\widehat{q_{1}}$, vertex $v_{1,1}$ is added to $V_{\mathbb{LS}}$; Then we move to $p_{2}$. Since $\widehat{p_{2}}=\widehat{q_{2}}$, $v_{1,1}\in V_{LS}$, and $|({p_{2}}.t-{p_{1}}.t)-({q_{2}}.t-{q_{1}}.t)|=|(38-35)-(4-0)|\leq 1$, vertex $v_{2,2}$ is added to $V_{\mathbb{LS}}$ and directed edge $(v_{2,2},v_{1,1})$ is added to $E_{\mathbb{LS}}$. Similarly, vertices $v_{3,1}$ and $v_{4,1}$ are added to $V_{\mathbb{LS}}$. Next, we pay attention to the row corresponding to $p_{5}$. We found $\widehat{p_{5}}=\widehat{q_{2}}$. For $k=1$, we found $v_{1,1}\in V_{\mathbb{LS}}$, but the time interval does not match. For $k=3$, we found $v_{3,1}\in V_{\mathbb{LS}}$, and the time interval matches. Hence vertex $v_{5,2}$ is added to $V_{\mathbb{LS}}$, and edge $(v_{5,2},v_{3,1})$ is added to $E_{\mathbb{LS}}$. For $k=4$, we found $v_{4,1}\in V_{\mathbb{LS}}$, and the time interval matches. At this moment, vertex $v_{5,2}$ is already in $V_{\mathbb{LS}}$, and edge $(v_{5,2},v_{4,1})$ is added to $E_{\mathbb{LS}}$. We obtain the DAG as shown in Fig. 5 by continuing the above process.

Proof. The loop over $i$ runs $m$ times. The loop over $j$ runs $n$ times. The loop over $k$ runs $i-1$ times, for each $i$. This leads to the worst-case time complexity of $O(m^{2}n)$.

From the condition in Line 7 of the algorithm, we notice that there is an edge in the form $(v_{i,j},v_{k,j-1})$ if and only if there is an $\epsilon_{[j]}$-valid match of $(q_{1},q_{2},\ldots,q_{j})$ in $\mathbb{L}$ that matches $(q_{j-1},q_{j})$ to $(p_{k},p_{i})$, where $\epsilon_{[j]}=(\epsilon_{1},\epsilon_{2},\ldots,\epsilon_{j-1})$. This leads to claims (a) and (b). $\Box$

We point out that the total number of $\epsilon$-valid matches of signature $\mathbb{S}$ in $\mathbb{L}$ may be exponential. However, all of them are captured by a polynomial sized DAG $G_{\mathbb{LS}}$, which can be computed in polynomial time.

For each $k=1,2,\ldots,K$, there may be zero or more $\epsilon^{k}$-valid matches of signature $\mathbb{S}^{k}$. Making use of $G_{\mathbb{LS}^{k}}$, we can either confirm that there is no $\epsilon^{k}$-valid match (when there is no vertex $v_{i,n_{k}}$ in $V_{\mathbb{LS}^{k}}$) or compute the earliest $\epsilon^{k}$-valid match $(p_{l[1]},p_{l[2]},\ldots,p_{l[n_{k}]})$, in the sense that $(p_{l[1]},p_{l[2]},\ldots,p_{l[n_{k}]})$ is lexicographically smallest, in $O(m+n_{k})$ worst-case time.

Given the network traffic $\mathbb{L}$, and the valid matches of signatures in $\mathbb{SS}$, how do we decide which IoT activity happened first? Through extensive experiments, we found that in normal situations, each network packet corresponding to an earlier IoT activity proceeds every network packet corresponding to a later IoT activity. Therefore the signature that has the earliest match happens first. Once this decision is made, we can delete each packet with a timestamp no later than that of the last packet in the match of the found signature from the network traffic. Repeating the above process, we can unveil the sequence of IoT activities from the given network traffic. We formally describe this process called actExtract in Algorithm 2.

Proof. Initially, the $K$ DAGs can be computed in $O(Km^{2}n_{\max})$ time. The earliest match of $\mathbb{S}^{k}$ can be computed in $O(m+n_{k})$ time, $\forall k$. Selecting the signature with the earliest match requires $O(Kn_{\max})$ time. This process is repeated for no more than $m$ times, hence the time complexity.

Next, we prove the correctness of the algorithm. Assuming that the sequence of IoT device activities that generated the network traffic $\mathbb{L}$ is $\mathbb{A}_{1},\mathbb{A}_{2},\ldots,\mathbb{A}_{x}$. By our normal assumption, each network packet of $\mathbb{A}_{1}$ must happen earlier than every network packet of $\mathbb{A}_{\lambda}$, for any $\lambda>1$. Since actExtract uses the earliest match, it will output $\mathbb{A}_{1}$ as the first activity, and all of the packets in the computed match for $\mathbb{A}_{1}$ have timestamps earlier than the timestamp of any packet in other IoT activity $\mathbb{A}_{\lambda}$, with $\lambda>1$. Hence, when we delete the packets matched for $\mathbb{A}_{1}$, we delete all of the packets generated for $\mathbb{A}_{1}$, but none of the packets generated by $\mathbb{A}_{\lambda}$ with $\lambda>1$. Therefore actExtract will next output $\mathbb{A}_{2}$, then $\mathbb{A}_{3}$, and so on. This proves the correctness of the algorithm. $\Box$

When we execute the computed sequence of IoT device activities, the network traffic observed may be different from $\mathbb{L}$, but only in the timestamp field. The sequence of packets will have increasing timestamps. Ignoring the timestamp field, two sequences of packets will be identical with $\mathbb{L}$. Note that we can divide the network traffic log into multiple sublogs where each sublog corresponds to a unique IoT device. We can apply actExtract to each sublog in parallel to unveil the IoT activities for all IoT devices.

In addition to network traffic and activity logs collected from our own smart home testbed, we also evaluated IoTAthena’s performance using a large public IoT network traffic dataset [30], known as the MON(IOT)R dataset. The MON(IOT)R dataset includes raw IP data traffic and the labeled activity logs of $25$ IoT devices⁵⁵5We evaluated IoTAthena on the IoT device activities with at least $30$ samples in the MON(IOT)R dataset in order to have statistically meaningful results.. Among these devices, $6$ of them are also included in our smart home testbed, while the other $19$ devices are unique to the dataset. The IoT network traffic and labeled activities in the dataset allow us to evaluate the performance of IoTAthena.

The accuracy of IoTAthena depends on the matching tolerance parameter. Intuitively, when the matching tolerance is very small, IoTAthena tends to unveil fewer activities due to the strict checking of inter-packet time intervals, leading to low accuracy. On the other hand, when the matching tolerance is very large, IoTAthena tends to have more false negatives due to the loose checking of inter-packet time intervals, also leading to low accuracy. In order to have a deeper understanding of this dependency, we carried out sensitivity analysis. For each device activity, we repeatedly triggered it $120$ times with random delays between two consecutive experiments. We then ran $6$-fold cross validation using the data collected. In each of the $6$ rounds, we observe the accuracy of IoTAthena on $20$ of the experiments, while using the remaining $100$ to generate the signature. Fig. 6 illustrates some representative results.

Figs. 6(a)-(d) show the accuracy changes for unveiling the on and off activities of TP-Link Bulb and TP-Link Plug as $r$ increases from $1$ to $30$, while Figs. 6(e)-(h) show the accuracy dynamics of unveiling August Lock’s app opening, Wifi (un)locking, autolocking, and Bluetooth (un)locking activities. In Figs. 6(a)-(d), we observe that the accuracy of IoTAthena exhibits a non-decreasing trend for the on and off activities of both TP-Link Bulb and TP-Link Plug, when $r$ increases from $1$ to $30$. These observations are not surprising since the increasing value of $r$ leads to a higher tolerance value to allow larger inter-packet time intervals.

However, Figs. 6(e)-(g) contradict such conjectures as increasing $r$ to a particular value leads to decreasing accuracy in matching August Lock’s app opening, WiFi (un)locking, and autolocking activities. Our in-depth investigation discovered that the accuracy decrease for the larger $r$ values is due to the interference of August Lock’s background traffic noise. The background traffic happens to shares overlapping packets with the signatures of app opening, WiFi (un)locking, and autolocking activities when we allow bigger tolerance of inter-packet intervals. Unlike Figs. 6(e)-(g), the accuracy of unveiling August Lock’s Bluetooth (un)locking activities changes in a non-decreasing fashion in Fig. 6(h) as $r$ increases from $1$ to $30$. The underlying reason of this distinct observation is the unique traffic patterns of the network traffic collected when triggering August Lock’s Bluetooth (un)locking activities, where no background noise that cannot be filtered out has been observed.

In summary, our sensitivity analysis on the tolerance parameter confirmed the importance and impact of choosing appropriate tolerance values during the IoT device activity extraction process. More importantly, the observations in Fig. 6 highlight the rationale and necessity of our full packet sequences with inter-packet time intervals as the IoT device activity signature and our time-sensitive subsequence matching algorithm for unveiling IoT device activities.

For each IoT device activity, we repeated it $120$ times and collected the network traffic on the router in our smart home testbed. We again ran the $6$-fold cross validation. TABLE 2 shows the accuracy ($\mathcal{A}$), precision ($\mathcal{P}$), and recall ($\mathcal{R}$) measures of IoTAthena for various activities of the $16$ devices in our smart home testbed, with $r$ set to $3$, $11$, and $23$, respectively.