{'fraction_non_alphanumeric': 0.03258728737690242, 'fraction_numerical': 0.004046553267681289, 'mean_word_length': 4.5729395330273395, 'pattern_counts': {'":': 0, '<': 8, '<?xml version=': 0, '>': 4, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 2, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 1, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
A Privacy Scheme for Monitoring Devices in the Internet of Things

Sufficiently strong security and privacy mechanisms are prerequisite to amass the promising benefits of the IoT technology and to incorporate this technology into our daily lives. This paper introduces a novel approach to privacy in networks, an approach which is especially well matched with the IoT characteristics. Our general approach is based on continually changing the identifying attributes of IoT nodes. In particular, the scheme proposed in this work is based on changing the IoT nodes' IP addresses, and because the changing patterns of the IP addresses appear random to a non-intended observer, an adversary is unable to identify the source or destination of a particular transmission. Thus, packets that carry information generated by a particular node cannot be linked together. The scheme offers additional security benefits, including DoS mitigation, is relatively easy to implement, and requires no changes to the existing networking infrastructure. We discuss the details of the implementation of the scheme and evaluate its performance.


Introduction and Motivation
To amass the promising benefits of the Internet of Things (IoT) technology, a number of technical challenges have to be overcome, with security being a major such a challenge. Without sufficient degree of security and privacy of information, users will not adopt this new trend that promises to intimately integrate into their lives. It is generally believed that security of Internet of Things is a significantly more challenging problem than the security of today's Internet. First, the number of devices in the IoT increases exponentially and many of these devices will operate unattended, thus more time might pass without a successful attack being detected. Moreover, all the malware that already exists today in the Internet, become viable threats to the small-print IoT devices, incapable of running complex security protection software. Furthermore, a successful attack on IoT devices, such as medical devices, baby-monitoring equipment, smart stove, and house alarm systems, creates potential for severe and immediate danger to their users (e.g., resulting in injury or death), a different type of danger than we are used to with typical Internet malware, such as theft of information.
There have been a number of solutions proposed in the literature that preserve privacy for IoT networks (e.g., [1] − [3]). However, as Internet transmissions require explicit disclosure of source/destination IP addresses, these schemes cannot hide the identity of the IoT nodes, thus allowing the adversaries to learn about the IoT nodes simply by observing the IP addresses in the packets' headers. In contrast, our proposed scheme, aims to actively obfuscate the IP address of a node by allowing the IP address of the node to change frequently (i.e., "IP address hopping"), thus creating uncertainty for adversaries of who is the source/destination of a transmission, while still allowing the packets to be correctly routed to the destination within the Internet.
As an example, consider a hospital facility in which numerous patients are hooked up to medical sensing IoT devices (e.g., EKG, SPO2, GSR, BP, temperature, etc), together creating an IoT network. The sensors' readings are continuously acquired, packetized, and transmitted to the medical information collection station for processing, archival, and possibly alerting medical personnel of emergency care needed. Such transmissions, being IP-routed, contain the IP addresses of the source device − the IoT sensor of the patient. Typically, such information would also include the identity of the patient. As all the packets originating from the same IoT device would carry the same IP address, an adversary can assemble the medical record of a patient by collecting subsequent packets. In other words, the IP addresses create an index that links all the transmissions together.
Another example could be collection of electricity reading from electric meters. The importance of privacy of such information is well acknowledged, as it could be used by thieves to determine that the house occupants are away and, thus, the house may be subject to a burglary. Of course, a series of readings put together would tell whether the electricity reading decreased in a particular time period, indicative of the occupants being away. Our scheme can preserve the privacy of such information by severing the link between the electricity readings, as well as the readings' link to any ID of a residence.
Using the proposed-here scheme, the IP addresses of subsequent transmissions of each IoT device would be changed in some unpredictable (yet deterministic) pattern, so that the adversary would not be able to use the IP addresses as a linking index of the transmissions. In other words, the adversary will see a massive collection of readings, but will not be able to attribute any reading to a single source (e.g., patient or house, in the previous examples). Of course, the receiver would need to generate a corresponding sequence of the IP addresses, so that the receiver can properly collect together the received information. We further note that, as the pattern of IP addresses is unique to a particular device, there is no need to include the encrypted patient's ID in the packets, as the IP address pattern already identifies a particular IoT device to the receiver (but not to the adversary). In other words, the IP address pattern serves as an ID of the IoT device. Furthermore, an attempt to associate a patient with an IP address of his IoT devices would also be fruitless.

The Basics of the Scheme
The proposed scheme is useful for information privacy protection in a scenario where a large number of IoT devices transmit similar monitoring (e.g., telemetry) data. More particularly, each transmitted data packet, standing by itself and without association with a particular user, would be useless to an attacker, while either (1) collection of large amount of data coming from a particular user, or (2) association of the data with a particular user, would constitute breach of information privacy. The example of a hospital with large number of the same type of medical sensors would correspond to such a scenario. Similarly, the example of electric meter information from numerous houses in a neighborhood would also present such a scenario.
The basic setup of our scheme includes three nodes, the IoT node whose information privacy we intent to protect, the device that communicates with the IoT node, which we refer to as the corresponding node (CN), and a trusted node that controls the operation of the scheme, which we refer to as the central node. In a general scenario multiple IoT nodes communicate with multiple corresponding nodes.
The IP address hopping is achieved by a pseudorandom number generator that is embedded in a function referred to here as the Tracking Function (TF). The parameters of the TF are shared by the IoT node and the authorized CNs. (Note that the TF itself does not need to be secret) The TF continually generates, what appear to an arbitrary observer, random addresses. We emphasize that although the output of the TF seems random, the operation of the function is deterministic; i.e., anyone who observes the output of the TF, even for a long time, cannot predict its future values; but whoever holds the parameters (including the input) of the TF can replicate the output deterministically.
An IoT node uses the random addresses as its actual addresses as they are generated by the TF. When an authorized CN desires to communicate with the IoT node, (authorized CN is in possession of the TF parameters), it uses the valid (i.e., the current) address generated by the TF as the destination address of its transmission. Similarly, transmission from the IoT node uses as the source address the currently generated output based on the TF. The IoT node and the CNs generate the IoT node's current IP address every seconds. Of course, for the scheme to operate properly, some degree of synchronization of the TF at the IoT node and the CNs is required -we discuss this in more details later.
The role of the central node is mainly to perform the coordination functions: authenticate the CNs, distribute the TF parameters, and aid in clock synchronization. The central node, the IoT nodes, and the CNs do not have to reside on the same network or even be close to each other. We assume here that the IoT node is static and does not migrate to a new subnet while the scheme is operating, although the scheme could be easily extended to support mobile operation as well.
Our scheme does not introduce additional header information for its operation and it can be incrementally deployed in networks; furthermore, the scheme is compatible with IPv6 addressing. There is no change required for the operation of routing and switching. The required changes to the IP protocol are mostly in the end nodes (the IoT and the CN nodes). If the changes in IP address are sufficiently fast, the scheme could also be used for DoS mitigation at the IoT node.
An alternative scheme would be to implement end-to-end encryption on each of the IoT devices' information flows. Although this would protect the information privacy, we suggest here that the IP address hopping provides significant advantages over encryption. In what follows, we explain why.
If end-to-end encryption were to be implemented, it is clear that multiple keys (probably one key per an IoT device) would need to be maintained. Therefore, some node ID would have to be transmitted in the clear to allow the receiver to choose the proper decryption key. (In fact, the IP address could be such a node ID used to choose the proper key.) As such, the attacker would be able to associate packets with a particular ID, risking loss of privacy. On the other hand, in the proposed scheme, no node ID needs to be transmitted; indeed, even the IP address of the node cannot be interpreted as a node ID, as it is continually changes (even if an attacker is able to associate an IP address with a particular device, such an association would be very shorttime living with very limiting privacy consequences). Thus, we maintain that, for the assumed communication scenario, our scheme provides advantageous information privacy scheme, compared with plain encryption.
Furthermore, the proposed scheme avoids the need to maintain the encryption keys and the necessity to periodically rekey the nodes. Finally, the overhead associated with encryption/decryption is eliminated too, which is of particular benefit for resource-constrained devices.

Threat Model
We assume that an adversary can mount passive attacks, such as network scanning and eavesdropping to collect information carried by the packets (including the header information), to assemble information from packets, so as to obtain protected information sent by the IoT nodes (i.e., violating privacy). An attacker can eavesdrop on all connections. In particular, a passive attacker can obtain the current IP address of the IoT node and launch attacks on the IoT node (i.e., becoming an active attacker). We assume that network infrastructure is reliable and not malicious; but may impose delay and packet loss. We further assume that CNs are not malicious and that the central node is a trusted node.

The Tracking Function
In order to generate the IP addresses at the IoT node, we use the timestamp (a sequence that is linearly increasing) as the input to a pseudo-random number generator (PRNG). The timestamp of the IoT node is one of the parameters that is kept secret in our scheme and is in the possession of the secret-sharing nodes. The PRNG, on the other hand, is publicly known; however, without knowing the timestamp and the other parameters the output is unpredictable. In general, any hash function that satisfies the following characteristics, can be used as the scheme's PRNG: • The function must be one-way secure, meaning that by watching the past values, one cannot guess the parameters of the function. • The function must be unpredictable; meaning that by watching past values, one cannot predict any future values of the function. • The function outputs should be randomly distributed on any time scale (at least on a sufficiently long time scale).
The IP address of IoT node is generated by feeding the timestamp to the Tracking Function, which is based on PRNG as follows: where TF denotes the Tracking Function, represents the base address of the IoT node's subnet (e.g. '129.110.242.0' without '/24'), and 2 denotes using least significant bit of the output of the PRNG. is the minimum number of bits that is required for representing all the available addresses in the IoT node's subnet ( and can be calculated from the IoT node's subnet address).
We propose to use a chaotic function as the PRNG. In general, chaotic functions are highly sensitive to initial conditions and control parameters, and they appear to behave randomly, alas they are completely deterministic once the set of control parameters is known. A slight change in the input will result in a big change in the output. This property fits well with the goals of the PRNG. More specifically, we use the Hash Function Based on Chaotic Tent Maps as the PRNG of the scheme ( [4]), since it has the aforementioned characteristic. By using the hash function based on a chaotic function, a third-party can neither predict the future values by watching the function, nor generate the function without having the control parameters.
The following is a simple example that demonstrates the operation of the Tracking Function. We further assume that we are using IPv4 addressing scheme and that the network address of IoT is 129.110.242.0/24. We need at least 8 bits to represent the host ID portion of the IP address ( = 8). Table 1 shows the corresponding generated IP addresses. Basically, the hash function based on the chaotic tent maps takes in an arbitrary length input and produces a 2 -bit hash output, where is the blocks' size into which the message is broken. is the number of rounds in the function. If < , the block is padded so that the size of the message is a multiple of . In our scheme, the hash function takes in the timestamp as the input M and a pair of initial binary fractions ( ; , ; ), producing a hash output that is a 2 -bit binary number. Yet we only use the required number of bits ( ) that is needed to represent all the available IP addresses in a subnet. The initial parameters ; , ; could be chosen in different ways, but for a good perturbation we use here ( ; , ; ) = (0.1010…10, 0.0101…01). In [4], the author showed that the hash function is resistant to target attack, free-start target attack, collision attack, semi-free-start collision attack, and free-start collision attack, as the computational complexity of these attacks are 2 ? , 2 ? , 2 ?/A , 2 ?/A , 2 ?/A respectively.
After successful authentication with the central node, authorized CNs get the parameters of the Tracking Function from the central node. The parameters are: timestamp, , , and subnet address of the IoT node.

Clock Synchronization
As discussed below, some degree of clock synchronization is required in the scheme to guarantee that timestamps of the central node, the CNs, and the IoT nodes are synchronized. Clock synchronization algorithms sync two or more clocks that have a non-zero drift rate. Typically, drift rate is a very small number; but due to the high frequency of clocks, this can lead to a large difference in clocks even after a short while. The timestamp that we use in our solution, however, is different from the local clock of the operating system. The timestamp that we use is a number that increases by one every seconds. The central node, after authenticating the CN, performs coarse clock synchronization with the CN, before sending the Tracking Function control parameters to the CN. Note that all the nodes (central node, IoT node, and CN), perform clock synchronization periodically.
Let us assume that is the number of times that an IP address changes in each clock synchronization period ; i.e., = × , where is a parameter that reflects the accuracy of the clocks in use and is calculated based on the maximum drift rate as follows. Assume that the maximum drift rate in the system is defined by [sec/sec]. Usually is a small number (e.g., 10 HI ). The maximum skew between the clocks in the system after 1 second would be 2× [sec]. We know that timestamp increases by one every seconds. The maximum skew between two timestamps should be always kept less than one within the interval of clock synchronization (every seconds). This way the timestamps will always be equal, since they are integer numbers. Let denote the skew between the timestamps within seconds; thus we require that < 1: There are many clock synchronization solutions in the literature that can be used for our scheme (e.g., [5], [6]). For instance, Network Time Protocol (NTP) is a low-cost solution whose accuracy ranges from hundreds of microseconds to several milliseconds ( [7]). The reference [8] presents a precise relative clock synchronization protocol for distributed applications. It achieves clock precision on the order of 10 microseconds in small-scale LANs and sub-millisecond over LANs. For our experiment (Section 4), we implemented an NTP-like clock synchronization program, where the central node is an NTP server and the other nodes in the system synchronize their clock with it.

3
Performance Issues

Address Collision
If many IoT nodes in a subnet use the IP hopping scheme, there is a probability that, at some point in time, two (or more) nodes will be assigned the same IP address. This, of course, is an undesirable situation that should be avoided. In this section, we estimate the probability of such an address collision. Suppose that, in a particular subnet, there are + ℎ nodes, of which are IoT nodes and ℎ are other non-IoT nodes (e.g., assigned permanent IP addresses). Further, assume that is the total number of available IP addresses in the subnet. Then, the probability that two or more IoT nodes will be randomly assigned the same IP address (i.e., the probability of address collision) is: We assumed that each IP address can be assigned by the Tracking Function with equal probability of 1/ , because the Tracking Function is technically based on a pseudo-random number generator, thus the probability of all possible outputs is equal ( [4]). The author in [4] maintains that for any 0 ≤ < 1, the distribution of K = Y ( ; ), which is the core of the Hash Function based on Chaotic Tent Maps, for randomly chosen 0 < ; < 1 is the standard uniform distribution, (0,1).  , for different values of and ℎ (ℎ + < < 256). As shown in the figure, when there are only IoT nodes in the subnet (i.e., ℎ = 0), the address collision probability for network sizes of > 40 is negligibly small. When there are 5 normal nodes (ℎ = 5) in addition to the active IoT nodes, the address collision probability is not negligible anymore. This provides guidance to the design process of such IoT subnets.

Packets in Transit
As discussed before, due to clock mis-synchronization and intrinsic network delays, packets arriving after a change in IP address has occurred at the IoT node, may still carry the old IP address of the IoT node and, thus, may be discarded at the destination. A mechanism is needed that will prevent or at least minimize the loss of packets in transit during the changes of network addresses. In the approach that we propose here, the IoT node continues to maintain the old IP address (together with the new one) for a short while, so that packets arriving with the old IP address after the IP address has already changed will still be accepted. Of course, the duration of time when both IP addresses are in use should be short to achieve higher privacy in IoT node, as well as to reduce the probability of address collision. The timing diagram explaining the scheme's operation is presented in Fig. 2. In the upper portion of the diagram presented are the assignments of the IP addresses to the IoT node as a function of time. As we can observe, initially, the IP address of K is assigned to the IoT node and is maintained for the period of ζ, after which time the new A is assigned. However, K is kept active for an additional time λ (the thicker line), during which time the IoT node is assigned both K and A addresses.
We now assume that the network introduces delay of to the packet sent from the CN. The lower portion of Fig. 2 displays the IP addresses of packets arriving at the IoT node. In this example, we assume that the only cause of mis-synchronization of the IP addresses is the network delay (i.e., that the clocks are perfectly synchronized). We see that the IP addresses of packets arriving at the IoT node follow exactly the IP addresses assigned at the IoT node (upper portion of Fig. 2), but they are delayed by . In this example, < , so some packets arrive at the IoT node after the old IP address, K , has already been dropped (after the extra time λ); such packets are lost (the loss is marked in darker vertical spaces in the lower portion of Fig. 2). It is easy to observe that if > , then no packet loss would occur. Next, we present a simple analysis of the packet loss.
Let us consider a long time interval and, for simplicity, assume that is a multiple of ; i.e., = • , for some integer . We further assume that the generation rate of packets by the CN is Poisson with rate . Since we assume that the only source of packet loss is the mismatch in IP addresses (i.e., no network losses), the total arrival of packets to the IoT node is also Poisson with rate . Then the average packet loss is: where we labeled − ≡ . Thus, the measure of probability of loss is . To minimize the probability of loss, either ≅ or ≫ − . The first case requires the knowledge of the value of , which typically has a non-stationary distribution. Similarly, in the second case, when is large, it requires either large or large , leading to limiting degree of achievable privacy. In either case, there is a need for a mechanism to estimate the value of , which can be measured by a one-way delay measurement scheme.

Privacy Protection
The privacy of the scheme primarily relies on the fact that the sequence of the generated IP addresses cannot be predicted neither by anyone who does not possess the parameters of the Tracking Function, nor by observing the past sequence of the IP addresses. To test the temporal randomness of a function the standard method is to compute the correlation of the function at various times, i.e., the function's autocorrelation. We conducted experimentation with the hash function we used in our scheme, collecting the samples over sufficiently long time to calculate the autocorrelation. The experiment showed white-noise like autocorrelation (an impulse ( ) response), demonstrating the lack of correlation in the hash function based on chaotic tent maps.

Experimentation Results
In this section, we provide some results of the experimental implementation of the scheme. We used three machines as the main components of the scheme. One machine served as the IoT node, one as the central node, and one as the CN that communicated with the IoT node. In order to evaluate the behavior of the basic scheme, we experimented with the scheme over a local-area (UTD, in Richardson, TX) network, as well as over a wide-area network, where the CN resided at Cornell University, in Ithaca, NY. The goal was to understand the performance as a function of different settings of the scheme, with drastically different distributions of the network delays.
As we can see in Table 2, in local-area networks, for > 2s, the packet loss is smaller than 1%. To achieve similar packet loss, in the wide-area network, it is required that > 4s (Table 3). In the experiment in local-area network, most of the losses occur due to delays of running the code, and in particular, due to the delay required for changing the IP addresses in a Linux machine. Wide-area Network over a WAN (where the CN was at Cornell University). The same parameters for the Tracking Function were used as before. The figure demonstrates that there is a "threshold" value of , below which the packet loss rapidly increase, while above the threshold the packet loss remains relatively negligible. Thus, as long as is above the threshold, the packet loss is not much sensitive to the actual value of . In Fig. 3, this threshold is = 0.7s for the experiment over the local-area network and = 1s for experiment over the wide-area network.

Related Work
There are some related works that use address hopping technique, although either in a different manner or for a different reason. Some of these works are primarily related to the well-known concept of frequency hopping in wireless networks. The works of Shi et al. ([9], [10]) discusses port and address hopping for active cyber defense (generally DoS). In their work, privacy is not always preserved, as hopping is not done continuously. In their more recent work ( [11]), they presented a scheme that requires Hopping Agent that is responsible for the hopping operation while the security-critical server is hidden behind it. Our approach does not require agent and is more suitable for IoT scenarios where devices are connected in different settings. Another interesting work based on address hopping is Mirage ( [12]), which is mainly designed for defending against DDoS for web applications. However, the scheme cannot be used for privacy preserving in the IoT, since, the scheme is only activated when under active attack (and only then, it hops every 5 minutes). Furthermore, it does not match the resource-constrained devices in IoT, as it requires solving puzzles, filtering by routers, and sending large size ACL files (few hundred thousand entries for small attacks) to routers, on each address change.
Similarly, a more recent related work based on address hopping by Krylov et al. ( [13]) addressed DDoS attack mitigation. Their system is not scalable to the IoT networks, since several routers are required (and should support the scheme) to protect a single node. Comparably, the work [14] discusses the general idea of network address hopping, but it is not suited for IoT networks, as much information needs to be sent between two peers each time a communication needs to be established between two nodes. Also their scheme is not scalable to IoT, as the hopping is on per-packet basis (only one-to-one communications is supported). In contrast, in our scheme, only the scheme's parameters (i.e., a few numbers) are transmitted when a new CN joins, and it supports one-to-many communication, namly suitable for IoT.

Conclusion
We introduced and discussed a scheme for data privacy in IoT based on IP address hopping. The scheme is in particular useful for information privacy protection in a scenario where a large number of IoT devices transmit similar monitoring (e.g., telemetry) data. To implement the scheme, we used a hash function based on chaotic tent maps as the scheme's PRNG. We discussed and evaluated some performance aspects of the scheme, such as the IP address collisions and the degree of privacy protection. In its basic configuration, the scheme requires no changes to the existing networking infrastructure. Finally, we provided the results of our experiments with the scheme and we showed that there is a fundamental trade-off between achievable degree of privacy and the average packet loss. As noted, the scheme could be also used for location-privacy and for protection against DoS attacks. We intend to evaluate these directions in our future work.