Efficient and Secure Pull Requests for Emergency Cases Using a Mobile Access Framework
Corinna Schmitt; Claudio Anliker; Burkhard Stiller Communication Systems Group, Department of Informatics, University of Zurich, Zurich, Switzerland
Abstract
Although the application range of Wireless Sensor Networks (WSN) is manifold, all applications have monitoring purposes in common. But WSNs usually lack (a) data collection options independent of predefined timing intervals and (b) a mobile access. Both options become important in emergency cases, since offering quick reactions (e.g., calling the ambulance) is essential and based on recognized changes of known and accepted value ranges of sensors, like for the temperature in personal health data. Therefore, this chapter introduces Secure Pull Requests (SPR), an efficient solution to request data immediately and location-independently. In support of a flexible access control, especially for emergency cases, an embedded privilege management solution is designed to maintain access to WSNs and their data. If the user's access for pulling data is granted, the request is forwarded to the node in the WSN using TinyIPFIX, which answers with a full data set including all data available data. Since some of this data might not be relevant to the requestor, it is filtered to match the user's request and to respect his privileges. This filtering process is delegated to the server side to minimize the workload of WSN-based constrained devices. The prototype developed is implemented in a modular manner and adaptable to user-specific requests.
Keywords
Internet-of-Things (IoT); Wireless Sensor Network (WSN); Access Management; Authorization; Secure Pull Requests (SPR)
Glossary
CoMaDa is a Configuration, Management, and Data handling framework. It allows the data owner to configure the sensor devices in his WSN, to manage the deployed network, and to handle the collected data (e.g., storing, preprocessing, publishing).
Constrained device is a device with limited resources for memory, power, and computational capacity. It collects data with its sensors like temperature, pressure, humidity, or brightness.
Data owner is the person who owns a WSN a wants to control the data access to the collected data.
Internet-of-Things (IoT) is a network where any kind of devices independent of their resources are connected with each other using wired and wireless communication.
TinyIPFIX is a data format to transport collected data in an efficient manner using a template-based design.
WebMaDa is a Web-based Mobile access and Data handling framework.
Wireless Sensor Network (WSN) is a network built of constrained devices with different resources and sensors.
Acknowledgements
The presented efficient and secure pull request solution in this chapter was supported partially by FLAMINGO and SmartenIT, funded by the EU FP7 Program under Contract No. FP7-2012-ICT-318488 and No. FP7-2012-ICT317846, respectively.
8.1 Introduction
Today more and more devices and systems are connected building the Internet-of-Things (IoT). The range of devices is as manifold as application areas and includes constrained devices, especially sensor nodes forming Wireless Sensor Networks (WSN) [23,2]. Those devices are constrained in memory, computational capacity and power, making it typically difficult to implement all desired functionality (e.g., periodical push-based data collection and transmission, security operations, and aggregation) at the same time. Thus, any solutions, supporting aforementioned functionalities, need a lightweight design to ensure a long system lifetime and less manual input. In addition, users desire (1) user-friendly interfaces, (2) flexible and intuitive solutions, (3) security support concerning access and data storage, and (4) mobility support. Especially, the last two requirements become essential upon the inspection of data collected within WSNs. This data can include sensitive information (e.g., GPS, medical information, address, or identifiers) allowing profiling of the data source, which is stands in contrast to user's privacy request and, thus, needs to be protected and their access to be controlled.
The developed Secure Pull Requests (SPR) solution in this chapter was motivated by an Ambient Assisted Living (AAL) scenario: A house is equipped with intelligent carpets including pressure sensors, which are connected to an emergency response system and which perform periodical measurements in predefined reporting intervals (e.g., 5 minutes). This setting allows for a behavior monitoring of inhabitants and sending out emergency calls, if required, especially in case a person falls and does not get up again within that predefined measurement interval. This monitoring ensures a secure feeling for inhabitants and especially allows elderly people to stay at home without having to live in a retirement home. The key drawback of this setting in current implementations is that unnecessary emergency calls can be generated: Assuming an external person (e.g., a family member or technician) visits the inhabitant, the system recognizes this due to periodical measurements showing unexpected changes of carpet pressure values, which do not match the inhabitant's estimated values for weight or movement patterns. Obviously, in this case an emergency call is not required. In order to avoid exactly such calls to happen, the pull functionality in the system provides an observer (e.g., doctor, fire department, police, or health care center) the chance to request measurements explicitly and independently of any predefined intervals in order to apply a short human-centric analysis of the data. Thus, it can be decided, if an ambulance has to called directly (no visitor in place) or if the inhabitant needs to be called back only to check his status. Thus, SPR was applied to a mobile access framework for evaluation purposes.
The pull functionality allows the user to request immediate and selected sensor data (e.g., “pressure of node 2”) independent of any predefined reporting intervals of a push-based solution. This solution is designed in a general manner (specification of destination node and specific sensor value) in order to make it applicable to different applications and uses a set of existing SecureWSN [36] framework components where to integrate pull support: The data format TinyIPFIX [35], the CoMaDa (Configuration, Management, and Data handling) framework [34], and the WebMaDa (Web-based Mobile access and Data handling) framework [24]. Within the frameworks of CoMaDa and WebMaDa authentication and fine-grained privilege management solutions are integrated.
The remainder of this chapter – based on [6] – is structured as followed: Section 8.2 presents selected work for AAL monitoring solutions, a solution to query sensor networks, and introduces reference frameworks and the SecureWSN framework, where the proposed SPR solution is integrated. The SPR implementation is presented in Section 8.3 including an updated architecture of SecureWSN. Finally, the SPR solution is analyzed in Section 8.4 with the focus on a functional proof and performance values in terms of latencies induced by SPRs. Section 8.5 summarizes and concludes the work.
8.2 Related Work
This section contains three parts: First, monitoring solutions are described in the area of AAL that inspired the extension of the existing framework SecureWSN [36] with pull functionality. Therefore, an efficient solution for handling queries in general is required. Second, two frameworks – Sentilo and FIWARE – are introduced. They have been chosen as reference projects. Finally, all relevant components of the existing SecureWSN infrastructure are introduced leading to the discussion of key requirements for the pull support.
8.2.1 Monitoring Solutions
The field of WSNs has a wide range. Most deployed networks have in common that sensor devices measure environmental data in predefined intervals and directly send them out to the final destination (usually the sink) [23,2]. The data is then analyzed corresponding to the research questions, stored, and visualized. To the best of the authors' knowledge, no solution exists that allows selective pull requests independent from predefined intervals and without interval updates in the installed code on the devices. This section focuses on related work that inspired our scenario selection and our solution design.
When looking into the area of AAL, all applications and solutions have common goals: (1) Allowing elderly people to stay at home as long as possible, (2) to make them feel save in their surroundings, and (3) to inform departments or people in emergency cases [7]. To achieve those goals, WSNs are a good solution, because they monitor the environment or personal medical data with less impact on the person. Several other solutions for environmental monitoring in houses work with noise sensors and video cameras [22]. A quite new approach is the intelligent carpet system [22,5,14,32,21], which is a textile-based sensor system. The carpet is equipped with piezoelectric and weight sensors, which are connected to a central station for analysis purposes. Based on the collected data and the known weight of the inhabitants, the movement of the inhabitants as well as their position in the room can be predicted. Monitoring data is usually done by Wireless Body Area Networks (WBAN) [28,4,31,38], which measure values like heartbeat, blood pressure, and temperature periodically and transmit them to a gateway forwarding the data to a doctoral office or health care center. Based on the analysis' result an emergency call can be placed.
Based on the provided brief description of the above solutions, it can be recognized that all those solutions work on a push basis, meaning the measurements are performed in predefined intervals and, therefore, in an automatic manner. The arising question is if the measurements are trustworthy at any time. Do we really need to call an ambulance, if the blood pressure rises for some minutes or if the heart rate sinks, because a person is sleeping? In order to answer this question interval-independent measurements are required.
8.2.2 Reference Projects
The two selected reference projects Sentilo [8] and FIWARE [19] have an academic nature and do not focus on concrete application scenarios. Instead, they are extensible multi-purpose frameworks to build smart applications of various kinds. This is important for the smart city context (including the assumed emergency cases in this chapter), which is defined by manifold interactions between arbitrary smart applications and sensor networks of all kinds, no matter if they are wired or wireless. Smart city is a buzzword and its definition depends on the context of usage as pointed out by Albino et al. [3]. All of these definitions can be interpreted to include WSN technology as well. Openness and interoperability are important to deploy WSNs in the smart city context.
Similar to [3] the developers of the framework Sentilo realized the importance of openness as well and promote Sentilo as “an open source sensor and actuator platform designed to fit in the Smart City architecture of any city who looks for openness and easy interoperability” [8]. It is a generic framework to integrate the management of applications based on WSNs into smart cities. Sentilo is actively used in Barcelona [10]. The company Effilogics uses Sentilo in an energy management system, a so-called smarty energy solution to measure and analyze data, e.g., temperature values, and to regulate remote devices [11]. Sentilo provides features, amongst others, a front-end for message processing, an administration console, a high performance memory database, and a non-SQL database to achieve higher flexibility and scalability [9].
Sentilo's architecture is extensible, such that core code does not need to be modified to support new, customized applications. In the context of Sentilo, smart city applications consist of three layers or tiers. The top tier is the application itself, utilizing sensor data it receives from Sentilo, which is the middle tier. The bottom tier contains applications that encapsulate sensor networks. These applications must implement Sentilo's interface to provide sensor measurements and WSN metadata to Sentilo. Its position already indicates that Sentilo is not a concrete application, but can be considered as a broker, connecting sensor networks with smart applications. The interfaces between the tiers use Representational State Transfer (REST) [12] over the Hyper Text Transfer Protocol (HTTP) [13].
FIWARE is “an open initiative aiming to create a sustainable ecosystem to grasp the opportunities that will emerge with the new wave of digitalization caused by the integration of recent Internet technologies” [19]. The FIWARE platform provides a set of public and royalty-free APIs to simplify smart application development. The FIWARE Lab provides a sandbox environment to test applications using data published by organizations and cities. FIWARE is getting increasingly important in the smart city context [17] and announced a connector for the SIGFOX IoT network [18].
FIWARE's architecture is too complex to be discussed in detail here. The most interesting part for this work is the IoT architecture, i.e., how FIWARE integrates smart applications with sensor networks, and WSNs in particular. FIWARE's IoT architecture provides two kinds of interfaces [20]. The northbound interface defines communication between a smart application of choice and the Context Broker. The Context Broker is the main-front end for developers and provides the IoT data as attributes of entities, which represent IoT devices. The IoT Agent Manager allows connecting and monitoring a set of IoT Agents. The deployed IoT Agents define the protocols (e.g., CoAP [37] and MQTT [30]) used on the southbound interface to connect to sensor networks. The mentioned protocols are dedicated to define communication with low-resource sensor networks. This makes it possible to connect WSNs directly to FIWARE, without the need for any intermediary applications.
8.2.3 Components of SecureWSN
SecureWSN is a two-parted framework existing of a WSN part and a server part as illustrated in Fig. 8.1. In the following paragraphs the TinyIPFIX for data transmission within the WSN and the GUIs CoMaDa and WebMaDa are briefly described. It is assumed that the communication within the WSN and towards the sink is done in a secure way using standard approaches of public key infrastructure (PKI) or special developed algorithms in order to achieve a two-way authentication of the communication partners by performing handshakes (e.g., TinyDTLS [25] or TinyTO [29]) resulting in new keying material and secured communication channels. This chapter will not address this security issue in detail here.
Within the WSN (shown in the left part) constrained devices are deployed with a maximum memory capacity of 48 kByte RAM [1] performing data collection in a push manner using TinyIPFIX. TinyIPFIX [35] was inspired by the Internet Protocol Flow Information Export (IPFIX) solution standardized under RFC 7011 [16]. In WSNs it is common that each message includes meta information of the sensor (e.g., temperature or brightness) and the measured value (e.g., an integer or floating point number). Due to the fact that the meta information of a sensor never changes, it produces redundancy. In additional, the maximum transmission unit (MTU) over IEEE 802.15.4 is very limited (e.g., 127 Byte for RF transceiver CC2420 [15]) [27,26], and, therefore, space for relevant data should be saved. Thus, the meta information should be deleted to save space in the message and, therefore, it makes sense to split the traditional sensor messages into two parts, which brought IPFIX to our mind.
IPFIX works with a template-based design in a push manner. A message is split into its components – meta information and measured value – resulting in a template and data record. When a device boots up, it first announces its template record to the network including a reference number (Template ID) and different template fields. The latter includes all required information (Type ID, Data Length ID, and Enterprise ID) building the meta information for each sensor in a unique manner. This template record is stored by all relevant intermediate nodes, which need to touch the data in any way, like an aggregator, and by the server. Next, the device is able to collect the sensor data and create the data record referring to the corresponding Template ID and send it out automatically according to the push characteristic of IPFIX. The second step can now be repeated periodically, which results in small messages without redundant information. All intermediate nodes and the server are able to translate the received data record when the template record is known. Fig. 8.2 illustrates the relationship between template and data record realized in TinyIPFIX [35]. The template record is re-sent periodically in order to insure this translation process, because routes might change or an unreliable transmission protocol (like UDP) is used [35,33].
In order to apply IPFIX to WSNs, TinyIPFIX was developed [35]. Therefore, templates and Enterprise IDs were specified matching sensor requirements. One drawback of IPFIX is the additional overhead of 20 Byte caused by the headers of IPFIX messages, which is overcome by replacing those headers with a new header of 3 Byte length, leaving enough space for essential data in the message. Details about the message structure can be found in [33]. In order to optimize the usage of the MTU, TinyIPFIX also supports aggregation [35]. Summarizing, TinyIPFIX is an efficient and flexible protocol as proven by [33,35] and shows a push characteristic, which is the classic manner for WSNs with periodic measurements in predefined intervals. However, TinyIPFIX does not support pull functionality yet, which becomes interesting when requesting data immediately.
The GUIs CoMaDa and WebMaDa build the server part of SecureWSN. CoMaDa [34] was developed in order to answer the users' desire to have a user-friendly and highly flexible GUI for WSNs, independent from a device's vendor and data types. This GUI should allow configuration, management, and data handling (e.g., storage and visualization) for any kind of WSN data. Thus, a unified framework was implemented allowing further extensions like WebMaDa (cf. Section 8.3.2). Fig. 8.3 illustrates the architecture of CoMaDa. The deployed WSN is located on the bottom layer. Via three components (WSN driver, Protocol Stack, and WSN connector) the received data of the WSN enters the gateway running CoMaDa. Based on the received data, a virtual representation of the data is established in real-time, including information about individual nodes (e.g., ID, sensor equipment), the topology, and the WSN itself (e.g., size or events). Linked to this virtual representation are different busses and interfaces supporting applications, like data visualization (e.g., measurement graphs and network topology), and data analysis (e.g., routing and package statistics), as well as managing and/or controlling (e.g., node programming and tunnel setup) [34]. CoMaDa requires that the WSN owner has to sit in front of the CoMaDa deployment that is directly mapped to the gateway, which means the user is in the deployment range of the WSN. It allows the WSN owner to directly interact with the WSN, like updating device settings or viewing measured data. However, this setting limits the user in mobility, because he cannot view the information without sitting in front of the computer terminal anymore. Notions of users or privileges are not defined.
In order to close the mobility gap, the WebMaDa (Web-based Mobile Access and Data Handling) framework was developed [24]. WebMaDa allows monitoring many WSNs using mobile devices (e.g., smartphones, tablets) where every single WSN is managed by exactly one CoMaDa instance. However, WebMaDa is a globally accessible web application, potentially used by many people to manage a lot of registered WSNs. Therefore, WebMaDa needs to introduce users and privileges to control which WSNs and measurements are accessible to whom. For that matter, WebMaDa provides a basic privilege system. For example, a WSN owner can grant access to all his WSNs to another person, but he cannot assign more fine-grained privileges to restrict access to a subset of the measurements (e.g., only temperature values).
8.2.4 Requirements for SPR Support
In view of the related work, Sentilo and FIWARE are both frameworks offering a middleware solution that handles incoming requests both from users and networks. This functionality is already offered by the CoMaDa component of SecureWSN. Sentilo uses HTTP for data transfer between interfaces. SecureWSN uses WebMaDa to transfer data across the Internet. In order to perform a secure data transmission between user, WebMaDa, and CoMaDa HTTPS is used instead of HTTP as done by Sentilo. To host data, a database solution is required as done by Sentilo and FIWARE. This storage issue is already addressed by CoMaDa storing data on the local CoMaDa instance. FIWARE includes an IoT Agent Manager offering the functions of connecting and monitoring of IoT devices. In SecureWSN the connecting part is relayed with CoMaDa and the monitoring is supported by CoMaDa and WebMaDa to ensure monitoring support during absence to the monitoring area when traveling. As of today, Sentilo, FIWARE, and SecureWSN do not support pull functionality. Thus, amongst others, to reduce false alarms in emergency cases as outlined above the SecureWSN special enhancements are fulfilled by extending the existing components of CoMaDa, WebMaDa, and TinyIPFIX.
Since the current setup of the SecureWSN framework does not allow measurements beyond predefined reporting intervals, immediate measurements in a pull manner require the extension of existing components with the following functionality:
1. Integration of a fine-grained privilege management
2. Extension of the Template Record of TinyIPFIX with a type field
3. Verification of pull requestor credentials and rights
4. Visualization of pull data in a user-friendly manner in CoMaDa and WebMaDa
5. Translation of pull requests into the TinyIPFIX format for processing in the WSN
6. Filtering of received answers in CoMaDa before publishing data in WebMaDa
Functionality 1 results from the general request of data owners to obtain control over data collected. Especially, the determination of who is allowed to see what information is essential, e.g., a family member can access data every time, in comparison to a doctor or an ambulance, which only can do so in emergency cases. Functionality 2 is needed to distinguish between predefined interval records (push packet) and pull answers to coordinate the packet handling in CoMaDa. Functionality 3 ensures that external persons must prove their given credentials and rights to access data at all times. This becomes essential in cases when a data owner revokes access rights, excludes persons, or updates their rights (e.g., only see pressure values, no pull right anymore). It is relevant for the existing components CoMaDa and WebMaDa to provide for a user-friendly visualization of data (functionality 4). Similarly, functionalities 5 and 6 are justified, since the reuse of existing components and software avoids the integration of resource-hungry algorithms that consume even more resources of constrained devices and, thus, reduce the lifetime of the WSN.
8.3 Design of the SPR Solution
Two major features in the course of this work have extended CoMaDa and WebMaDa: The pull mechanism was developed and integrated. Second, WebMaDa was extended by the privilege management system to provide WSN owners with a tool to control access to their WSNs and collected data.
8.3.1 Privilege Management
The fine-grained privilege management solution (privilege management in short) is a component integrated in the WebMaDa web application. It enables WSN owners to share access to their WSNs with other users. An owner can give family members the right to view all data, but can restrict the access for doctors or ambulance to relevant data in emergency cases only. This includes access to previous measurements and to the pull mechanism. To achieve that, an owner can assign two kinds of privileges:
• Push privileges allow users to see data, which has been pushed by the WSNs push mechanism in predefined intervals.
• Pull privileges enable users to pull data by themselves. This means, they can query the WSN to get up-to-date measurements independently of the nodes' configurations. Besides pulling data, pull privileges also give a user view rights on the data he is allowed to pull.
The privileges are stored in the WebMaDa database and checked at two occasions. First, whenever the WebMaDa user interface shows measurements to the user, filtering based on the user's privileges is applied to prevent unauthorized data disclosure. Second, the pull query is compared with the corresponding user's privileges to prevent unauthorized pull attempts whenever the pull mechanism is used. This is important, since pull queries are constructed on the client side and, thus, might be manipulated. The implementation of the privilege management is intuitive to use. First, the user interface allows selecting one of the owner's WSNs. In a next step, a username must be chosen in a drop down menu. Push and pull privileges can then be granted using checkboxes for the chosen user in the selected WSN.
8.3.2 SPR Triggered by WebMaDa
WebMaDa provides the pull mechanism to users over the Web. While the privilege management is part of WebMaDa, it enables owners to assign privileges and, thus, to share access to their WSNs with others. The WebMaDa database schema was improved to maintain WebMaDa user accounts, their privileges, as well as the data and metadata of registered WSNs. WebMaDa provides the following three communication interfaces as shown in Fig. 8.4.
The user interface (cf. Fig. 8.4 (1) https://webmada.csg.uzh.ch)) is used to maintain and access WSNs after successful authentication. Maintaining WSNs includes registration, reset, and deletion of WSNs. WSN registration means to create a representation of the corresponding WSN in the database schema of the WebMaDa web application. Successful WSN registration produces credentials bound to this WSN and is the prerequisite for communication between CoMaDa and WebMaDa, since the credentials must be used to authenticate at the pull and upload interfaces. A WSN reset deletes data and metadata of a WSN. However, it does neither invalidate the credentials bound to this WSN nor does it revoke any privileges assigned to other users. Thus, the WSN can be reused. In contrast, deleting a WSN leads to a complete and irreversible cleanup. This means, the credentials are invalidated, and cannot be used by CoMaDa anymore. Accessing WSNs embraces pulling data from this WSN and to view previously uploaded data. This access is regulated by the privilege management introduced in Section 8.3.1.
The upload interface (cf. Fig. 8.4 (2) https://upload.webmada.csg.uzh.ch) can be accessed using HTTP POST and uses a set of well-defined JSON messages. After a successful authentication, the communication is as follows: CoMaDa provides data and requests an upload. WebMaDa checks the requestor's authentication status (i.e., if an authenticated session has been established). If this is the case, it executes the upload procedure immediately. Finally, it confirms the operation or sends an error code. Different message types can be used to upload different types of data and meta data.
The SPR interface (cf. Fig. 8.4 (3) wss://pull.webmada.csg.uzh.ch) is used by WebMaDa to send pull queries to CoMaDa. Therefore, the server initiates communication to the client. The WebSocket protocol is suitable for this task and used to implement the SPR interface. After successful authentication, the communication on the SPR interface is completely one-directional: CoMaDa listens for pull queries transmitted by WebMaDa. On a pull query reception, CoMaDa forwards requests to WSN nodes. The above-mentioned upload interface is used to upload resulting measurements. The SPR interface was implemented as a Java servlet on Apache Tomcat. To submit pull queries, WebMaDa communicates with the servlet internally over HTTP POST. The Web server is configured to block HTTP POST access to the servlet over the Internet to prevent pull query submissions over HTTP POST from the outside, which prevents circumvention of WebMaDa's the privilege management.
8.3.3 SPR and Answer Translated by CoMaDa
Using CoMaDa alone restricts the mobility of the user, since it does neither allow mobile access nor secure sharing of WSN access at all. For this matter, CoMaDa can be used in conjunction with WebMaDa. To achieve that, the CoMaDa user must have a WebMaDa user account and register a WSN in WebMaDa as explained in Section 8.3.2. WebMaDa provides credentials to use the pull and upload interface in return. CoMaDa can be configured with these credentials and communicate with WebMaDa over the mentioned interfaces. Meta data and data of the WSN can be uploaded and pull queries can be received. One must state at this point, that CoMaDa blindly trusts WebMaDa, since the interfaces, and in particular WebMaDa's identity, are cryptographically protected by TLS (HTTPS and WSS).
CoMaDa contains a Pull Query Executor that transforms received pull query strings into requests for the respective nodes. Pull queries are stored in a queue and handled one-by-one by a worker thread. This restricts the pull traffic in the WSN and prevents the need for increased coordination in case of almost concurrent pull queries. This is beneficial, because TinyIPFIX uses UDP and does not handle message collisions at all.
8.3.4 SPR Handling using TinyIPFIX
In order to establish an efficient solution for the SPR handling the TinyIPFIX message format (cf. Section 8.2.3) is re-used. Thus, no additional resources, especially memory, are required from constrained nodes and no computational overhead occurs, because all nodes can answer the SPR in the traditional manner as needed for a predefined interval reporting. The respective message flow is illustrated in Fig. 8.5 and consists of the following steps under the assumption that node 2 is the destination node:
1. The pull requestor defines which information of a special node he wants to pull via WebMaDa (e.g., pressure from node 2).
2. Assuming that the pull requestor, a family member or a doctor, owns the correct credential, checked within WebMaDa, the request is forwarded to CoMaDa.
3. Within CoMaDa the information is translated into a TinyIPFIX message consisting of an empty payload addressed to the destination node.
4. Via the WSN's sink the TinyIPFIX message is routed through the WSN to the destination node.
5. The destination node immediately requests measurements of all available sensors and constructs a common TinyIPFIX message including all information as in the case of a predefined interval report, being send back to the sink.
6. CoMaDa now decodes the data record with the help of the referred to template record [35] and filters all values received based on the concrete SPR.
7. The filtered information is forwarded to WebMaDa and,
8. After a credential check, the result is displayed to the pull requestor.
Usually, within Step 5 the data answering the SPR is expected to be smaller than the usual report size of a predefined interval report. Thus, the node would need to create new templates with updated information each time a request is done. This computational overhead due to constructing the template, announcing it to the network, and to create the corresponding data record can be saved. Additionally, further memory required due to the saving of the new template record meanwhile can be saved, too, including the savings of energy to perform these aforementioned steps. To be as efficient as possible constrained nodes are relieved from the additional burden of operations and resource consumptions of the filtering process, which is shifted in full to CoMaDa. This leads to a very straightforward design that the requested node answers with its common TinyIPFIX message including all possible data. Consequently, in Step 6 CoMaDa decodes the data record with the help of the referred to template record [35] and filters values received based on the concrete SPR. Finally, Step 7 forwards the filtered information to WebMaDa and after a credential check the result is displayed to the pull requestor. This credential check is required, since rights granted may have been updated or revoked in the meantime.
As a consequence of this data handling process, the existing TinyIPFIX message style can be re-used by introducing one new pull message format (empty payload). Thus, no further modification on the node is required and limited memory resources can be saved. The use of TinyIPFIX allows even for future extensions, in particular, it allows the sink to separately send metadata and data by itself, providing a possibility to define new pull message formats on-the-fly.
8.4 Evaluation
The SRP solution was implemented as a prototype deployed in a home scenario, where WSN owners granted (a) full access to family members including pull rights and (b) restricted access to doctors or ambulances.
The changes to the software running TinyIPFIX on the deployed sensor nodes have been reduced to an absolute minimum, due to the memory being constrained. Nodes only listen for pull requests, indicated by an empty payload in the TinyIPFIX message, to perform the same algorithm for sensor measurement request used by the push mechanism in TinyIPFIX to measure and transmit data periodically. All other extensions to process data or to manage privileges relate to CoMaDa and WebMaDa. Since these two components do not run on restricted devices, but on a laptop and a Web server, investigating power consumption and memory management is not of that high relevance in this environment. However, latency is different, since it is affected by the restricted nodes as well.
CoMaDa allows users to setup and manage a physical WSN and to collect its data. The corresponding WSN can be registered in WebMaDa for a location-independent access over the Web. WebMaDa creates credentials as part of this registration procedure. These credentials can be used to configure CoMaDa accordingly, such that CoMaDa can authenticate itself to WebMaDa. In turn, CoMaDa is able to upload measurements and metadata over the upload interface and to receive pull queries from WebMaDa over the SPR interface. WebMaDa's privilege management gives full access control over uploaded data to the WSN owner. This improves privacy compared to the previous WebMaDa solution, in which the administrator of the system was able to assign arbitrary privileges, which provided him with access to all data. The access to the pull mechanism is also controlled by WebMaDa's privilege management.
Pulling was tested in a network consisting of 20 TelosB nodes. Fig. 8.6 shows three example screenshots of the WebMaDa user interface on a Nokia Lumia 925 running Windows Phone 8. Message panels are used to provide the user with success and error messages, as illustrated in Fig. 8.6a and Fig. 8.6b respectively. A successful pull is shown in Fig. 8.6a. The pulled values are visible in the top-most data entry. WebMaDa can only pull data from a running CoMaDa instance. If CoMaDa is terminated, the corresponding WebSocket connection with WebMaDa terminates as well. In this case, the user is informed over the user interface as shown in Fig. 8.6b, where the error message suggests contacting the WSN owner. Fig. 8.6c shows the privilege management used by the WSN owner. It lists different pull and push privileges assigned to users, like claudio in this case. Buttons can be used to add, modify, and delete user privileges.
In the current setup, latency is defined by the 3 seconds update interval of the WebMaDa user interface. In case the user interface (UI) update is timed unluckily, i.e., immediately after a pull query submission, new results might not be available yet. This increases the latency to more than 3 seconds. But the consumers of this data are humans only, this latency is acceptable. If latency is considered to be more critical in the future, the solution can be improved such that the database triggers the update of the WebMaDa user interface whenever new measurements are available. This reduces latency significantly. The implemented solution does not assume encryption inside the WSN. However, tests have been made with TinyTO [29] to encrypt the communication from the nodes to the sink. It has been shown in [29] that TinyTO needs 
seconds to sign a message, i.e., to cryptographically ensure its integrity, and 
seconds to encrypt it, i.e., to ensure confidentiality. This increases the latency on the path from the node to the sink to almost 20 seconds on average. This implies a tradeoff between latency and WSN-internal security, as the feeling of a real-time pull mechanism suffers substantially with a delay of 20 seconds. Due to the hardware constraints of the TelosB node, memory is too scarce to deploy secure channels bi-directionally using current TinyTO implementation. Thus, SPRs are still sent in clear text from the sink to collector nodes. Hypothetical encryption and authentication on this path would increase the latency, since signature verification alone takes 18.41 seconds in average using TinyTO on TelosB [29], whereas decryption has never been tested due to those mentioned resource constraints.
The developed SPR solution reached two main efficiency goals: (1) No further overhead for constrained devices is introduced and (2) a reduction of false alarms in emergency cases was reached. The overhead minimization with respect to resource consumption was reached by reusing the existing message structure within the WSN. Thus, the TinyIPFIX message structure was re-used without modifications to answer SPRs. The destination node (cf. node 2 in Fig. 8.5) is triggered by the TinyIPFIX message with an empty payload received. In this case the node performs a general sensor request, it creates TinyIPFIX messages as done for predefined interval reports, and sends the data out to the sink and CoMaDa, respectively. The only difference within this TinyIPFIX message send back to the sink is that the “type field” is set to 1, indicating the SPR?s answer. Thus, this workflow does not require any further computational overhead or resource consumption, making it fully comparable to the creation of a predefined interval report.
The reduction of false alarms was reached, since a human interaction (e.g., service assistant like police, doctor, or nurse) is required before reacting on an emergency call (e.g., sending out police or ambulance). Before sending data to the observer, for each measurement acceptable value ranges (intervals) were specified by the sensor owner, and reported to the observer (e.g., doctor, fire department, police, or health care center) for comparison purpose of upcoming measurements. Examples for those acceptable intervals are 50–100 heartbeats per minute or a room temperature above 40 centigrade. When a WSN is deployed, measurements are send to the observer in predefined intervals (e.g., 5 minutes or 1 hour), stored in a database, and compared to the given value range. If a deviation occurs, an alarm is send automatically to authorized observers instead of sending directly an emergency call out. The authorized observers can now request an immediate measurement by applying SPR. This can be repeated, if needed, several times to obtain more measurements allowing for a correct analysis of the situation, (a) resulting in an emergency call or (b) ignoring the current deviation, because values are back in acceptable interval.
8.5 Summary and Conclusion
This chapter introduced a SPR solution in an efficient manner for applications in WSNs, especially for emergency cases in AAL scenarios. The pull support is an extension of a deployed, flexible, and operational SecureWSN approach. The SPR extension required modifications to existing components of TinyIPFIX, CoMaDa, and WebMaDa to ensure efficiency and secure access. While the structure of SPR follows the existing TinyIPFIX message structure and, at the same time, allows a requestor to ask several nodes synchronously for individual sensor readings, CoMaDa handles these requests, directs them to individual nodes, and filters the answer received to provide selected information to the original requestor. WebMaDa supports by now a fine-grained privilege management in control of the WSN generation and publication mechanism as well as individual rights of end users. Privilege changes (e.g., pull and viewing rights) are processed immediately, especially important if an access is updated or even denied. Finally, based on the prototypical implementation of SPRs, the encryption in the WSN has been tested with TinyTO, showing that securing communication channels between nodes and the sink is possible in theory, but substantially increases the latency in practice.
Concluding, the designed and prototyped SPR solution is efficient, because (1) it does not introduce any overhead to the code running on constrained devices answering SPRs and (2) reduces false emergency alarms due to human interaction requested before an emergency call is really performed. The SPR solution is sensor device-independent, due to the flexible structure of TinyIPFIX data formats. Thus, SPR can be applied to very different IoT applications and sensor settings, besides the Ambient Assisted Living scenario. The fine-grained privilege management and its handling of different roles can be adapted to other application requirements than in the AAL case, giving the data owner full and detailed control of his sensor data. This enables a wide range of access solutions with a high flexibility offering data owners a trustworthy environment. Thus, the dedicated AAL scenario sees key advantages in practical operations with this new WebMaDa's feature of efficient SPRs.