Security and Privacy in Ubiquitous Sensor Networks

1. Introduction

Ubiquitous sensor networks (USNs) have become an important paradigm in sensor network systems. The International Telecommunication Union (ITU) defines a USN as a conceptual network built over existing physical networks that makes use of sensed data and provides knowledge services to anyone— anywhere and at any time—and generating that information via context awareness [1]. The increasing availability and pervasiveness of mobile devices and Internet of Things (IoT)-enabled devices (expected to reach 30 billion by 2020 [2]) are opening revolutionary opportunities toward next-generation services, systems, and applications in various areas, including environmental monitoring, transportation, entertainment, security, and healthcare.

The wide adoption of USN presents significant security and privacy challenges and risks. The limited data acquisition, storage, processing, and communication capabilities of the related sensing infrastructures, as well as their proprietary technologies, are making USN devices vulnerable to a wide range of attacks. Although intensive efforts have been undertaken to improve USNs’ security and privacy (e.g., [3-11]), additional efforts are necessary to maintain data integrity and system availability. USN devices still cannot guarantee users’ data privacy. Concerns related to re-identification and context privacy still challenge USNs’ effective implementation. Thus, in this paper, we present an overview of these issues along with potential solutions.

The rest of this paper is organized as follows. Section 2 presents architectural aspects of USNs, and compares USN with wireless sensor networks (WSNs) while highlighting USN applications. In Section 3, we discuss security and privacy issues for USNs. Section 4 presents solutions that secure and protect privacy in USNs. Section 5 considers open challenges. Section 6 offers concluding remarks.

2. Architecture and Applications of Ubiquitous Sensor Networks

USNs make use of Internet-connected devices to collect data of interest [12]. These devices are either owned by the government, private-sector companies, or common citizens. USNs differ from WSNs in multiple ways; Table 1 highlights some of the main differences. These differences are based on the architecture of both types of sensor networks, the communication and capabilities of the devices involved in data collection, and how the sensor networks are deployed. This includes the device’s power and energy management (USN devices are either connected to a reliable power source or easily recharged), communication capability between devices in USNs (depending on the infrastructure-based networks available to access the Internet), and user involvement (typically, USNs rely on user contributions to collect the data of interest). The typical hardware architecture of USNs (shown in Fig. 1) consists of the following tiers [12]: sensors, first-level integrators, data transport, and second-level integrators.

• Sensors. The major function of sensors is to collect data on objects and events of interest. To this end, they act individually or within clusters to acquire the right data, at the right time, from the right area, while optimizing the use of the available resources. Sensors connect to first-level integrator devices using wired or wireless connections via personal area networks such as Bluetooth, near-field communication (NFC), IEEE 802.15.4 (Zigbee), or some other wireless local area network (LAN) technology.

• First-level integrators. The first-level integrators tier performs initial sensor data verification, aggregation, and analysis (e.g., feature extraction). Any device (e.g., smartphones and Internetconnected devices) that supports IP-based communication can serve as a first-level integrator.

• Data transport. In USNs, data transport is provided by any IP-based communication network (e.g., Internet service providers [ISPs]) that enables the end-to-end transfer of data from firstlevel integrators to second-level integrators. Data transport mechanisms should adapt to the USN’s changing spatial distribution. They should also optimize the use of available resources.

• Second-level integrators. The second-level integrators tier collects and stores data sent by any component from the first-level integrators tier. It also provides analytics services (e.g., data analysis and machine learning that cannot be performed at first-level integrators) and feedback to the first-level integrator devices as well as to external entities who did not participate in collecting data. Second-level integrators are implemented on servers and/or as cloud-based services.

USNs are currently deployed in various application domains such as environmental monitoring, entertainment, transportation, security, and healthcare. These applications can be grouped into four major categories [12]:

• Location-based systems (LBS). Available since the late 1990s, LBS make use of location sensors to receive/collect geotagged data [13,14]. Applications of LBS include asset management, tracking systems, and geofencing.

• Community-based sensing systems (CBS). CBS (also known as crowdsensing) track variables of interest for communities (e.g., neighborhoods, cities, citizen associations, leisure/gaming associations, and government). Such variables may include pollution, noise, and street congestions [15-18]. CBS can be classified as participatory or opportunistic [19].

• Human-centric sensing systems (HCS). HCS track human-related variables such as physiological variables with the goal of improving individuals’ wellbeing. Some examples of HCS include security and safety systems (e.g., home security, human-fall detection), mobile health (m- Health), and personal health systems (e.g., fitness tracking) [20,21].

• Hybrid systems. Hybrid systems incorporate characteristics from LBS, CBS, and HCS. Common examples of hybrid systems include augmented reality games (e.g., Pokemon GO [22]) and scavenger hunt applications.

3. Security and Privacy Issues in Ubiquitous Sensor Networks

3.1 Security Issues

WSNs often operate unattended for long periods of time in extreme conditions, so frequently the devices are powered by batteries instead of a reliable power source. These constraints make the design of WSN devices limited in their communication and processing capabilities. To save battery power, WSN devices use energy-efficient routing protocols that were initially designed for infrastructureless, ad hoc network protocols to route data from sensors to base stations. In a WSN only the devices that are within the wireless communication range of the base station can broadcast data without having to route it through other devices.

Establishing secure communication channels in WSNs is a major priority, to protect the data’s integrity as it is routed through the network, while also minimizing the power used. Therefore, much WSN security-related research (from the communication perspective) focuses on developing poweraware cryptographic methods and key distribution protocols over wireless ad hoc routing protocols [23-25]. However, key distribution and power-efficient cryptography are not an issue for USNs, because first-level integrator devices are connected to the Internet and long-term power consumption is not a concern (devices easily can be recharged or connected to a reliable power source).

USN integrator devices make use of infrastructure-based networks and well-known security protocols for the TCP/IP network stack such as Transport Layer Security (TLS), Secure Sockets Layer (SSL), and Virtual Private Networks (VPNs) to communicate data between integrator devices. Consequently, given the features of USNs presented in Table 1, and assuming secure communication channels to avoid manin- the middle attacks between integrator devices by using the aforementioned protocols, the security issues in USNs are related to the integrity of data collected from non-trusted user devices, and mechanisms to avoid availability attacks (e.g., denial-of-service attacks at integrator devices). Thus, in the following, we classify the security issues for USNs into two major categories [26]: data integrity and system availability.

3.1.1 Data integrity

In contrast to traditional WSNs, in which devices are trusted because they are deployed and maintained by a single organization, the maintenance of first-level integrator devices that collect data is performed by USN’s users; this brings unique challenges. The direct access to these components by users could be utilized to launch spoofing attacks by submitting false, incorrect, or fake data [27,28]. Another type of spoofing attack could be performed by tampering and modifying the physical environment (i.e., for a temperature sensor, this type of attack intentionally increases the room temperature). In this case, although the sensor’s readings are correct, the sensed data are generated from fake or tampered environments [29].

In USNs it is difficult for systems to identify who is injecting false data and block these users, because many USNs make use of anonymization techniques to protect the privacy of users contributing sensor data (especially for CBS). This aspect brings a tradeoff between authentication and privacy that has an impact on data integrity: how to authenticate users while at the same time protecting their privacy? In addition, for HCS systems, including m-Health and fitness tracking systems, data integrity is critical. M-Health applications collect health-related data and provide feedback that could include intrusive actions on a patient’s body automatically (e.g., delivering medication). In such cases, the violation of data integrity can have serious, life-threatening consequences [26,30]. Thus, data, user, and sensor authentication are major security concerns for human-centric USNs [3,4].

3.1.2 System availability

Because data transport between integrator devices in USNs is provided by TCP/IP communication over the Internet, USNs make use of reliable networks (provided by ISPs) and secure communication protocols such as TLS, SSL and VPNs to send data securely between integrators. Therefore, we argue that there are three ways attackers can launch attacks on system availability in USNs:

• Availability at the first-level integrators tier. In this type of attack, the adversary’s goal is to deny data collection at first-level integrators by interfering with the hardware, software, or communication infrastructure between sensors and first-level integrators. If the adversary is successful in these types of attacks, the USN will not collect data. We identify these attacks as follows: (1) attacking the communication infrastructure between sensors and the first-level integrator devices by interfering with the communication media [5-7]; (2) attacking and/or depleting the power supply with battery exhaustion attacks [8,9]; or (3) making the operating system unresponsive by exploiting security vulnerabilities of the host operating system [10,11,31].

• Availability at the second-level integrators tier. In this type of attack, the adversary’s goal is to deny data collection at second-level integrators by interfering with the services that collect and analyze the data forwarded by first-level integrators. If successful, the adversary will disable the USN’s ability to collect and analyze the data. Two major issues arise when managing availability for second-level integrator devices: elasticity and denial of service (DoS). Even though the result of not managing both issues correctly is the same (no availability), they differ in terms of lack of availability. On one hand, elasticity deals with the ability of the system or service to satisfy and adapt to workload changes [32]. On the other hand, DoS represents deliberate attacks to the system or service by malicious parties [33].

• User participation. USNs require participation and collaboration from users and custodians to collect data and enable the system to provide a certain level of quality of information (QoI) [27,34] to be useful. This is because unless users contribute to data collection with their devices, the USN will not accomplish the goals for which it was designed. With no data collected (due to users’ unwillingness to contribute or participate), the result is similar to an availability attack on the USN, because the system does not have the data available to process and provide feedback. Attacks on user participation may include availability attacks at first-level integrators and users’ resulting hesitancy to contribute and collect data (e.g., lack of motivation to participate, low opinions of the USN system, and concerns about privacy and participation).

3.2 Privacy Issues

USNs may expose users to significant privacy risks, because they make use of devices that can potentially register and forward data and metadata continually about users’ actions through the data collection cycle shown in Fig. 2 [35-37]. This collection cycle is composed of the following processes:

• Task distribution. The goal of task distribution is to release the sensing task to user participants. This is accomplished in two ways: participants either makes use of the sensing task from a server (second-level integrators), or the task is pushed to the users’ devices (first-level integrators) from second-level integrators.

• Data collection. Once tasks are configured at the participants’ devices, the tasks perform sensing and initial analysis that may include extracting features from sensor data, smoothing and filtering of outliers in the data, and data analytics that can be performed locally without the need of second-level integrators.

• Data submission. Tasks that execute at first-level integrators forward the collected data to second-level integrator devices. Depending on the USN’s goals, data submission can be performed continuously or based on events (identified in the data collection process), and data can be submitted in real time or later (e.g., at the end of the day).

• Data analysis and sharing. In this process, second-level integrator devices use the collected data from first-level integrators to perform analytics services (e.g., data analysis and machine learning) and provide feedback to first-level integrator devices. The feedback may include the release of new sensing tasks to user participants, resulting in a new data collection cycle. In addition, data may be released to external parties outside the USN system through this process.

Attacks on user privacy can be performed at any stage during the data collection cycle and they may lead to different privacy risks based on the goals of the USN. Next, we classify these risks into three major categories: re-identification; context privacy; and external data sharing. These categories enable us to study privacy issues that arise when a participant contributes data to the system.

3.2.1 Reidentification

The first concern when collecting data in a USN (from users’ point of view) is how their identities can be discovered or protected. Thus, given the data (or metadata) submitted by users in the USN, reidentification attacks attempt to discover any user’s identity who uses or participates in the system. These attacks are successful when an entity (internal or external to the system) discovers, without permission or consent, the user’s identity. Reidentification issues can be grouped into two categories:

• Reidentification from network identifiers. The attackers infer the user’s identity by associating the network addresses (e.g., IP addresses, MAC addresses, cookies) needed to send and receive data between integrator devices on the Internet [36-39].

• Reidentification from task management. The attackers infer the user’s identity from any of the processes required to manage the data collection cycle for a sensing task (Fig. 2). This issue is particularly important in CBS and HCS systems, where downloading an application or authenticating users in a system could reveal their identities [36,37].

3.2.2 Context privacy

Given the data (or metadata) submitted to the system by participants, attacks on context privacy attempt to discover and associate aspects considered private by users/participants with their identities. Some examples in this category include inferring users’ locations, activities, behaviors, and/or health state based on the collected data [36-37]. We classify attacks on context privacy into two groups:

• Location privacy. Location data by itself can reveal a lot of contextual information about a user (e.g., user’s interests, social/business activities, and profile). Location privacy issues can be categorized further into two groups: privacy in location-based queries (including location data submission) [40-49], and path privacy [50-55]. In location-based queries, the goal is to avoid the release of location data that may be used to infer users’ sensitive contexts. For example, collecting location data at a particular type of hospital may reveal that the user has some type of terminal illness, and the user may not want to reveal that he/she is suffering from that illness. In path privacy, the goal is to protect user participants explicitly from releasing a set of locations (a path) that may compromise the user’s privacy or disclose what the user is doing.

• Sensor data and metadata privacy. Sensor data and metadata privacy corresponds to the issues that arise when an attacker infers information about the user’s context or actions (e.g., if a user is sick) from the sensor data or metadata submitted to the system (e.g., the hardware or software used, or the time when a particular application was used). An example of how metadata can be used to infer context is when an attacker knows the amount of time that a user spends on a device, and from that the attacker discerns the type of activity that the user is performing, even without collecting sensor data.

3.2.3 External data sharing

In USNs, data are usually forwarded to a service in the cloud that aggregates, analyzes, and provides feedback to users. The collected data may include several objects and/or events of interest, such as environmental data (in case of LBS or CBS) or health-related data. Sharing this data with external entities outside the USN occurs either by creating infographics on which the data is summarized and visualized (i.e., through maps and visualizations) or by sharing the raw data with organizations external to the USN system [36]. This sharing represents one of the biggest threats to privacy, especially when data are not protected or curated before their release. In this case, an attacker could infer information about contributors and perform malicious actions accordingly [56].

External data sharing in USNs depends on the type of USN. For example, in the US, unless the USN is part of a comprehensive (medical) healthcare system (i.e., m-Health), the organization that develops and deploys the USN system does not have to follow the guidelines in the law when sharing data externally. Some of these guidelines providing a legal framework in the US to share data to external organizations are specified in the Health Insurance Portability and Accountability Act (HIPAA) and Health Information Technology for Economic and Clinical Health Act (HITECH) [57]. Similar laws exist in other countries [57,58]. As such, the protection of users’ data depends on the stipulation of privacy policies.

4. Solutions to Security and Privacy Issues for Ubiquitous Sensor Networks

In this section, we discuss some of the security and privacy issues for USNs.

4.1 Securing Ubiquitous Sensor Networks

Next, we discuss security solutions that mitigate the attacks discussed in Section 3.1.

4.1.1 Data integrity

We can prevent eavesdropping and data integrity attacks by protecting communication channels through encryption from sensors to first-level integrators, as well as from first-level integrators to second-level integrators. However, faulty sensor readings and users’ actions such as tampering with sensors (or the environment) are examples where encryption alone fails to maintain data integrity in USNs. In this section, we present solutions that can protect data integrity.

• Estimation and filtering. For certain types of USNs, including community-based systems, the management of errors in the data (e.g., wrong measurements, outliers, or faulty sensor readings) assumes that there are enough participants to handle errors in the data at a macro level [59-61]. By this, we mean that there is enough redundancy (of first-level integrators) along with statistical models to keep the system’s estimation capabilities from being impaired. Some examples of techniques for estimation and filtering of data used in USNs include interpolation techniques (such as kriging), Markov random fields, Principal Component Analysis [59], clustering, Gaussian mixture models [60], and anomaly detection algorithms (such as unsupervised/ supervised machine learning methods—including support vector machines, neural networks, Bayesian networks—and parametric/non-parametric methods adapted for anomaly detection [61]).

• User and sensor authentication. Solutions to handle authentication in USNs include biometrics [62,63], smart card authentication [64,65], two-factor authentication [66,67], and secured brokering hardware [68,69]. Using mobile phone-based biometric authentication methods (e.g., fingerprint sensors or face recognition) combined with other wearable and/or implantable sensors may provide novel approaches to achieve user authentication [70]. The use of hardwarebased, trusted execution environments (TEEs) [71] can provide solutions for device authentication, especially because TEEs are currently used in mobile phones as a standard feature for network device authentication (e.g., International Mobile Equipment Identity) [72].

4.1.2 System availability

We discuss below availability issues related to integrators and user participation.

• Availability at first-level integrators. Mitigating DoS attacks on communication channels between sensors and first-level integrator devices can be achieved by using several mechanisms, including frequency hopping, repositioning of sensors, modification of protocols, and physical layer jamming avoidance techniques (e.g., directional antennas, spread spectrum, channel diversity) [5]. In the case of battery exhaustion attacks, potential methods include developing power-aware operating systems and frameworks [73,74]. They may also include techniques for assessing an app’s power consumption or employing a sensing task before downloading and installing it at a first-level integrator device [75-77], as well as approaches that detect an abnormal increase in power consumption at runtime [78-80]. In the case of detecting operating system vulnerabilities, the following techniques could be used: static analysis (i.e., analysis of source/compiled code before execution by using tools such as Metal [81]; dynamic analysis (i.e., analysis of programs during their execution to detect and document program errors and vulnerabilities [82]; and formal methods (i.e., the use of mathematical logic and specifications to prove program correctness [83,84]). The detection of vulnerabilities is always a race against the clock, as they must be corrected before they are exploited by attackers. It is possible for a vulnerability or bug to go undetected and be exploited for long periods of time (even years) [31] before it is fixed.

• Availability at second-level integrators. To deal with the availability at second-level integrators, USN systems should focus on addressing the problems of elasticity and DoS (see Section 3). Given the possibility of billions of Internet-connected devices performing data collection for USNs, not being able to manage or cope with different types of workloads will render the system useless. To deal with elasticity in USNs, various approaches have been considered, such as hybrid architectures of client-server and peer-to-peer architecture designs [12] and cloud-based solutions [85,86]. In the case of DoS, the issue is similar to any other service being provided on the Internet. Therefore, countermeasures for traditional network infrastructure and cloud-based environments can be used [87].

• User participation. Salim and Haque [88] identified that the successful, large-scale user participation in USNs consists of five steps. First, identify the needs and dilemmas (dilemmas in this context represent the users’ decision to participate in the USN given the possible associated risks and costs such as privacy risks, monetary costs, user reputation, or physical security). Second, identify stakeholders. Third, identify incentives. Fourth, gather evidence and experience. And fifth, provide tools and affordance (affordance in this context means the provisions, tools, and interfaces for the user to interact with the USN in a usable manner—not only to collect data, but also to understand the information from the collected data). User participation relates to security in USNs, because if users do not participate in collecting data, the USN will have an availability issue (no data will be available for processing). Thus, USN systems must be mindful of an individual or community and assure that any data collection preserves their wellbeing, to assure adequate participation and even increase it. The following are means of monetary or nonmonetary incentives [89] to help:

― Micropayments. These are monetary incentives that pay small fractions of a dollar to users who contribute data to the USN. Micropayments were developed in the 1990s during the Web’s explosion, as an incentive to sell online content [90] for user-generated content. In the context of USNs, micropayments were first evaluated by Lee and Hoh [91], using dedicated algorithms based on game theory;

― Altruistic incentives. Users participate because of the benefits to the community that a USN can provide. Common examples include P-Sense [15], the Personal Environmental Impact Report (PEIR) [16], and NoiseSPY [17];

― Social incentives. In this category, the incentives are social or human-centric rewards, such as a better reputation, improved health, or interacting with other users to achieve mutual goals. Common examples in this group include e-bird [18], fitness applications (such as Runtastic [21]), and games (such as Pokemon GO [22]).

Table 2 presents a summary of the issues, along with their solutions discussed in Section 4.

4.2 Solutions to Privacy Issues in Ubiquitous Sensor Networks

In this section, we present privacy solutions to address the privacy issues discussed in Section 3.2.

4.2.1 Reidentification

Encryption alone is not enough to protect users’ privacy from third parties eavesdropping on communication channels. Indeed, users’ identities could be revealed from network identifiers as well as from the incorrect management of processes related to the sensing tasks in USNs. Next, we explore available solutions to avoid reidentification at first- and second-level integrators.

• Reidentification from network identifiers. Solutions that avoid reidentification from network identifiers aim to hide users’ network addresses (such as IP addresses). They include the use of peer-to-peer (P2P) anonymization networks [36-38], disposable network identifiers [39], and double encryption via brokers [92,93].

• Reidentification from task management. Solutions that prevent reidentification from task management seek to hide the users’ identity at different stages during the data collection stage for sensing tasks. As such, different solutions for user authentication, task distribution, and data submission have been proposed to decrease the risk of reidentification. In the case of authentication for USNs, solutions include using pre-shared keys in the sensing software [37], group authentication [92], and pseudonyms [94-97]. For task distribution solutions, options include using beacons that distribute tasks through broadcast signals from the beacons or access points (such as Wi-Fi access points) [92]. Downloading tasks at crowded spaces to diminish the risk of reidentification [92], and using anonymization networks that hide a user’s identity [37,38] are also options used to protect privacy in task distribution.

During data submission, several methods have been proposed to protect data privacy. These methods include using anonymization networks and double encryption, using anonymization methods in databases (e.g., k-anonymity, l-diversity, and obfuscation) [92], group-based signatures, microaggregation (calculating averages on sensed data values from k users in a particular area [98]), data aggregation (calculating statistics based on groups of users) [99,100], and using representative samples from data collected in a region [101,102].

Vergara-Laurens [103] discussed the tradeoffs between information loss, computational complexity, communication overhead, and power consumption for different privacy-protection schemes for data submission. Vergara-Laurens suggested using different anonymization schemes based on geographical cells with various sizes. For smaller cell sizes where users can be identified more easily, the scheme uses encryption to protect users’ privacy and increase the quality of information. For bigger cells where it is more important to protect users’ privacy, the scheme makes use of anonymization and data obfuscation techniques at of the cost of decreasing the quality of information (the submitted data are perturbed in this latter technique) [103].

4.2.2 Context privacy

The goal of solutions for context privacy is to diminish or eliminate the risks of discovering and associating aspects or contexts considered private by users and contributors from the data (or metadata) submitted to the system. Here, we explore solutions that can protect context privacy.

For location data privacy protection, methods can be classified into those that aim to protect privacy in location-based queries (including the location of data submission) [40-49], and others that aim to protect path privacy [50-55]. For location-based queries, methods to protect privacy include adaptations of k-anonymity [40-44,95,96] and location obfuscation methods [45-50]. In the case of solutions that use k-anonymity, the idea is that the original location data from a particular user cannot be distinguished from k - 1 other locations within a particular area, and within a particular timeframe. In the second group (obfuscation methods), the goal is to modify/perturb the submitted location by selecting or calculating a new location for the submitted location data. Some examples of the last approach add random noise [47-49], make use of known landmarks [50,51], or select a point from a redefined area where the user’s true location is identified [46]. Methods for path privacy protection include the use of location query protection algorithms, schemes based on geographical contexts (such as virtual fences [53]), and obfuscation schemes (that mix true and fake locations along a path [54] and use cloaking regions to blur paths [55]).

Mechanisms for sensor data privacy protection include allowing or denying data collection in specific contexts. The ultimate goal is to create rules for the device to collect data only when the user wishes to do so. Good examples of allowing data collection only in particular contexts include bubble sensing [97]. In this case, contexts are identified based on sensor data readings—as well as on the concept of privacy bubbles [98] on which users define contexts—to manage content for submission to second-level integrators in mobile environments. Mechanisms to deny data collection in specific locations are explored in Kapadia et al. [99]. The authors proposed the virtual walls approach, where users explicitly restrict the contexts of where data collection should not happen.

4.2.3 External data sharing

Technical solutions for external data sharing for USNs focus on anonymization techniques in databases [100]. These solutions fall into two major categories: anonymization for the release of microdata (un-aggregated data) [104-106]; and anonymization for the release of aggregated data [100,107]. In the first category, the goal is to guarantee that if a record is released (in the microdata), an attacker cannot associate confidential attributes of a record in the microdata with an identifier from the record (e.g., a name, Social Security number, or face). Some examples of methods for anonymizing microdata include k-anonymity (where each record in a microdata release is indistinguishable from at least k − 1 other records with respect to certain identifying attributes) [104], l-diversity (the microdata table contains at least l well-represented values with respect to a sensitive or confidential attribute) [105], and t-closeness (the distance between the distribution of a sensitive attribute in an anonymized group should not be different from the global distribution by more than a threshold value t) [106]. In the second category (aggregated data), the goal is to guarantee whether the release of a statistical value (e.g., an average) from the database can reveal information about a particular record in that database or reveal an identifier that was used to create the statistical value. Differential privacy has been proposed as an approach to handle privacy in the release of aggregated data [107]. Table 3 presents a summary of these privacy issues and solutions.

5. Future Security and Privacy Challenges for Ubiquitous Sensor Networks

In this section, we discuss some of the security and privacy issues for USNs.

5.1. Security Challenges for Ubiquitous Sensor Networks

As USNs make strong use of consumer devices to collect data of interest, these devices still will be exposed to human intervention in the future. In addition, trust in devices (as they are developed for the consumers with less emphasis on built-in security), trust in the sensing tasks (as they can be maliciously engineered and implemented to cause harm), and trust in the organizations that delegate the sensing tasks (as they could have goals that may affect users’ privacy and security) are key aspects in the successful deployment of future USNs. In this context, we identify current challenges that should be addressed to build more robust and secure USNs. These challenges include trustworthy tasking and data integrity for human-centric USNs.

5.1.1 Trustworthy tasking

USNs have been developed under the principle that the sensing task and the organizations that collect data are trusted. As such, most of the research in securing USNs assumes that threats are coming from custodians of first-level integrator devices (e.g., by submitting fake data) or from an external organization or third party with the goal of disrupting the USN (e.g., by executing a DoS attack on the USN). However, more research is needed on assessing the trust that we may have in the organizations that perform data collection, the sensing task, and the security of the device collecting data—especially given the usage of COTS devices as integrators and sensors. As an example of this issue, consider a recent incident about a U.S. federal court case involving the Federal Trade Commission and Vizio about “deceptive and unfair” data collection practices. Vizio tracked what people saw on their TV sets without actually getting user consent (the approach used by Vizio to provide notice to users was deceptive). Similar incidents involving IoT companies [108] underscore the need for research about organizations’ and companies’ trustworthiness, along with their practices on collecting and managing data from users.

Moreover, USN devices could be reprogrammed through a sensing task to steal data or create physical harm to the user (e.g., theft, kidnapping, or accidents) [109], because many USN devices not only collect data but also perform some type of physical action (e.g., opening doors, increasing building temperatures, driving cars without human intervention, or delivering medication automatically to user’s body). Finally, USN devices could be used as zombies by botnets to attack external parties, as demonstrated by the DDoS at Domain Name Servers (DNS) attack that disrupted the Web in 2016, which involved consumer Internet connected cameras as zombies [110].

5.1.2 Data integrity for human-centric USNs

In a human-centric USN, a user usually has one type of sensor of each kind. For instance, a user has one heart rate sensor, one ECG sensor, and one breath depth sensor if using a wearable such as the Zephyr BioHarness [111]. There may also be multiple sensors of one type (e.g., a heart rate sensor on a chest strap, and another on a smartwatch) [112]. Estimation and filtering of variables of interest in addition to redundancy of sensors or multiple first-level integrators, as proposed for community-based USNs, cannot be used. This is because data in human-centric systems from a particular user is usually isolated from others due to privacy concerns. New techniques are needed to authenticate data in these scenarios. In addition, because feedback in human-centric systems could involve intrusive actions automatically (e.g., deliver medication without user intervention), novel methods are needed to continuously authenticate the user to ensure these actions’ effectiveness (i.e., some of these actions can generate life-threatening consequences). These authentication methods must have the following characteristics:

Non-repudiation. These methods must guarantee user identity with high assurance.

Unobtrusiveness. These methods must authenticate users without explicit user intervention. Continuous authentication methods that request users to authenticate regularly are unrealistic (i.e., not usable from the human-computer interaction perspective).

Power-aware. Many first-level integrators in human-centric USNs are battery-powered, thus continuous authentication methods that generate high power overhead for a first-level integrator device are not useful.

5.2. Privacy Challenges for Ubiquitous Sensor Networks

The ubiquity and use of mobile and Internet-connected devices as first-level integrators present a tradeoff: on one hand, we need to collect data as accurately as possible, but on the other hand, it is imperative that we collect or share data in a way that would preserve the privacy of users [101]. Next, we identify some of the current challenges that should be addressed to build privacy-preserving USNs. These challenges include access control and privacy of bystanders.

Access control. Using privacy policies to protect users’ privacy in USNs may not inform how and when the data collected is shared by second-level integrator devices. A report by the US Federal Trade Commission [102] stated that due to the length of policies, the lack of uniformity in the language, and the difficulty in understanding these policies, privacy policies are not successful in informing users about data practices. In addition, research has shown that 50% of adults in the United States cannot understand literature written at an eight grade level [113], so they will not understand privacy policies which are typically written at a level above eighth grade [114]. Mechanisms for fine-grained access control (i.e., electronic consents for data-sensor data readings) are needed for users to better handle their privacy. Fine-grained access control for sensor data using privacy-preserving contracts based on blockchains [103] may present an alternative for users to manage the sharing of sensor data with third-parties more efficiently.

Privacy of bystanders. Privacy on USNs has focused on the protection of the privacy of users. However, USNs may collect identifiable data about third parties (bystanders) who may have not given consent to be part of the collection. Even though some solutions to protect the privacy of bystanders’ privacy have been proposed [115], these solutions exist only as research prototypes that have not been widely adopted or implemented in consumer products. Bystanders’ privacy is becoming increasingly important because the growth and availability of IoT devices are making computation transparent, in the sense that consumers are generally not aware of these devices’ availability and what they do in their surroundings: with the current technological trends, computing devices are being manufactured as small as needed. The fact that an IoT company in the U.S. recently collected location data about users at brick-and-mortar shopping stores without customers’ knowledge and without providing options for the consumers demonstrates the seriousness of this issue [108]. More research urgently is needed to implement and fiercely protect bystanders’ privacy in USNs.

6. Conclusion and Future Work

After reviewing threats and solutions in security and privacy for ubiquitous sensor networks, we classified security issues into two major categories: data integrity and system availability. We also classified privacy issues into three major categories: reidentification, context privacy, and external data sharing privacy. Although we discussed potential solutions for improving security and protecting privacy in USNs, additional research is needed to handle several security issues (for example, ensuring trustworthy tasking and data integrity for human-centric USNs), as well as privacy issues (such as access control and bystanders’ privacy). Given the current rate of adoption of mobile and IoT devices and their utilization in USNs, security and privacy will continue to play a significant role in the future.

Acknowledgement

This is an extended version of the paper “Investigating Security for Ubiquitous Sensor Networks” previously published in the Proceedings of the 8th International Conference on Ambient Systems, Networks and Technologies (ANT-2017). We thank the anonymous reviewers for their valuable comments, which helped improve the paper’s content, quality, and organization. Alfredo J. Perez was supported by the US National Science Foundation and the US Department of Defense’s ASSURE program under award 1560214. Sherali Zeadally was partially supported by a University Research Professorship Award from the University of Kentucky.