WikiSensing was one of the main data management platforms and data stores that supported the Hackathon and Crackathon events at the Urban Prototyping London (UPLondon.org) festival in April 2013. For the Hackathon, WikiSensing hosted meteorological data of cities around Britain, transport data on traffic disruptions and tube departure boards and device-level electricity usage data. To ensure reliability during this 3-day event the system was stress-tested using 1000 concurrent users and deployed a back-up cloud infrastructure on Windows Azure [114]. The objective for the participants was to create cutting-edge technology solutions that result in real-world change, based on the environment, local economy or local community.
The trustworthiness of sensor data was explored during the Crackathon events by testing WikiSensing’s trustworthiness API with external users. For the
Crackathon, contestants were given air pollution data of an area in East London,
which had been selectively altered in different ways, to simulate potential attacks. The task was to assign a trustworthiness score to measurements of different sensors at different time frames, with the aid of WikiSensing’s trustworthiness API which offered history-based abnormal reading detection and neighbour-based conflict detection.
6.1.1. The Hackathon event
WikiSensing provided data management services for the UPLondon Hackathon event (sustainablesocietynetwork.net/th_event/hackathon). The participants were given access to a number of comprehensive data sources that were collected at real- time by WikiSensing. These include Meteorological Office, temperature and wind speed data (two weeks), Transport for London, tube boards and traffic disruptions data (two weeks), and household device-level electricity usage data (three years) that was monitored by a group of researchers at Intel. WikiSensing provided a set
143
of services (wikisensing.org) for querying this data as well as services for participants to create their own sensor data sources.
The provided data sources proved to be a valuable source of information for potential new applications. There was keen interest in the amount of detail stored on London transport data. The ability to manage heterogeneous record types in WikiSensing was a key factor in the flexibility of application development during this event.
6.1.2. The Crackathon event
The main goal of the sensor data trustworthiness assessment task during the
Crackathon event was to understand how users rate sensor measurement under
certain conditions. During this event the participants were given two data sets of sensor measurements where some contained alterations. The data provided were managed by WikiSensing and the users were given access to its data management services to query this data as well as trustworthiness services (Figure A.3 and Figure A.4 of Appendix) to generate trust metrics. The participants’ task was to detect the changes in the sensor data and rate the trustworthiness of a set of sensor measurements at specific time frames. Figure 6.1 illustrates a scenario where the trustworthiness of sensor data can be jeopardised. The actors are denoted using dashed boxes. The custodian is WikiSensing that manages the sensor data. The owner submits sensor data to the system and the user access these sensor data streams. Furthermore the attacker falsifies the sensor data streams stored in WikiSensing.
Two separate sets of pollution data were used for this activity. This data was obtained using GUSTO sensors that monitored the pollution levels at a busy location in East London. The two data sets were distinguished by sampling the measurement to different frequencies. Both these data sets contained four different types of pollutants (NO, NO2, SO2 and ozone). Figure 5.5 (a) illustrates the sensor deployment. Contextual information were also provided (Figure 5.5 (b)) on the
144
location of the pollution sensors, as well as historical measurements. Tools were provided to allow users to review the data sets as well as to assess trustworthiness of sensors by discovering anomalies and conflicts in the data (e.g. historical data, contextual data, and conflict with other sensors).
The attacker was simulated by introducing alterations to the sensor data streams. In each case one of the data sets would have been changed (e.g. tampered by changing a subset of measurements). Some of these changes were obvious while the others were subtle. Moreover the changes were either an abrupt or a gradual change in the data, with the change being applied to a single or multiple (possibly correlated) data streams. Importantly the participants were not aware which data was changed.
The objective for the user (participant) was to first detect when the attack occurred and to identify which sensors were attacked. The participants were also requested to report the “correct” pollution values at specific locations and justify the value they chose if the sensors in the same location report different values. The following are the strategies used for sensor measurement alterations.
Figure 6.1: The potential actors involved in sensor data management
Case 1: Inactive or faulty sensor
The sensor measurements were set to a constant value throughout the entire stream to simulate an inactive sensor (Figure 5.8.c). Moreover a constant value was added or reduced from the measurement to replicate faulty sensors (Figure 5.8.b).
Sensor Sensor Sensor
Owner Attacker User
Annotator Sensor Data Management
Digital Data
145
Case 2: Temporally-localized abrupt change in a single-sensor data stream
The data stream values were abruptly changed after a period of time and is similar to the data stream depicted in Figure 5.8.d. This change was only being applied to one sensor and the changes to the data stream were more or less apparent. Consider, for example, a sudden increase or decrease in the value range of the data stream, or the introduction of a sharp peak.
Case 3: Gradual change in a single-sensor data stream
The data stream values were gradually changed after a certain period of time. This was applied to a single sensor and the change was not easily identifiable as the previous scenario. This alteration is similar to the data stream depicted in Figure 5.8.e.
Case 4: Coordinated change in multiple (correlated) data streams
Gradual changes were applied to multiple sensors and were coordinated across these data streams. This scenario models the need to compare measurements with nearby neighbouring sensors.