SecureWSN: A Framework to Monitor Environments with Constrained Devices

Today a growing number of applications within the Internet of Things (IoT) depends on data collected by wireless sensor networks. The individual nodes of these networks have severe resource limitations, concerning storage, processing, and transmission capabilities, but also concerning energy available for communication functions. Supporting the required protocol functionality in combination with the goal of energy-saving operation typically results in the development of proprietary, highly specialized communication protocols for wireless sensor networks (WSN).

However, with Internet technology as the dominating communication paradigm for a wide range of application areas, it became an attractive goal to be able to use Internet protocols (IP) within WSNs. The idea itself is interesting but at the same time challenging, because the commonly used devices in WSNs are very constraint in memory, computational capacity, and power. The most challenging constraints are the first two if more than only data collection and sending should be performed by the devices. RFC 7228 groups the devices into classes depending on their RAM and ROM resources and points out that only devices with more than 10 KB RAM and 100 KB ROM are able to support Internet connectivity and security functions. The latter becomes essential due to the linkage of WSNs to the Internet and the raising concerns of privacy and security by the users, because any kind of collected data includes sensitive information (e.g., ID, address). Thus, WSN solutions must support security solutions beyond efficient data transmission.

The project SecureWSN faces those challenges and develops different solutions for secure and efficient data transmission for WSNs consisting of devices between 10-50 KB RAM and 100-250 KB ROM.

Contact me per mail or visit me in my office (here).



History of SecureWSN

SecureWSN started in 2008 with the development of an efficient data transmission protocol. Messages within a WSN have in common that they include meta information and measured values at the same time, and are send automatically in a predefined interval. Due to the fact that the message size is very limited (around 102 bytes on MAC layer using IEEE 802.15.4 radio) and costs energy it needs to be efficient. Thus, the PUSH-based Internet Protocol Flow Information Export (IPFIX) protocol from IP networks standardized in RFC 5101 becomes interesting due to its template-based design. In general IPFIX splits messages into Template and Data Records. Template Records include meta information and Data Records the corresponding values. A drawback of IPFIX is the introduction of additional IPFIX headers with around 20 byte size. IPFIX can be used for WSNs in a light-weighted solution together with header compression. TinyIPFIX is the resulting protocol for WSNs including header compression to compress the additional headers down to 3 bytes and reducing redundancy by the re-sending of meta information in each message. The principle is the following: (1) Device boots. (2) Device announces its meta information to the network by sending out a Template Record with unique ID. The Template Record is stored by nodes in the networks (e.g., gateway, aggregator) that need to perform decoding of data (e.g., for aggregation). (3) Now device sends only out Data Records with a reference to the Template Record for decoding purposes. Due to the usage of UDP and especially quick changing topology in the beginning of the WSN establishment the Template Record is re-send periodically. To make proper use of the limited message size TinyIPFIX was extended with aggregation functionality. It can support message aggregation and data aggregation at the same time. The latter is useful in scenarios where pre-processing of data is needed (e.g., control of HVAC system). In order to modify the aggregation type and degree during run-time a SHELL was developed allowing the user to access an aggregator and change the functionality (e.g., MIN, MAX, AVG, degree of aggregation).

In a next step of development SecureWSN faced the security request by the users. Therefore, different security solution where designed and implemented keeping the device resources in mind as well as the idea to re-use standards from IP networks. At the moment SecureWSN supports three security option that have authentication, session key agreement, and being standard-based in common. The TinySAM protocol is a solution developed for devices with 10 KB RAM and max. 100 KB ROM. It offers one-way authentication and works with pre-shared keys. A more secure solution is the developed TinyTO protocol performing the Bellare-Canetti-Krawczyk (BCK) handshake with pre-shared keys resulting in two-way authentication. It uses Elliptic Curve Cryptography (ECC) for key generation, key signatures, and encryption. Where the used 192-bit ECC keys are assumed to be as secure as 1024-2048 bit RSA keys. For devices with more resources the TinyDTLS protocol was designed performing a common DTLS handshake using X.509 certificates and supporting two-way authentication.

Beyond the secure and efficient data transmission protocols a graphical user interface (GUI) was design in SecureWSN. Today the users prefer to configure and manage networks in handsome ways usually using buttons. Therefore, the CoMaDa framework was designed, allowing the user to configure, manage, and handling data using an intuitive GUI. CoMaDa works with a virtualization of the deployed WSN and has connection to the deployment via the gateway. The user can program new devices and update running ones, can view the network status, can define how collected data is handled (e.g., stored or forwarded to analysis tools), and receives a visualization of data in raw format and in curve design. The newest feature is to provide filtering options for network owners addressing the transparency request of users to stay in controll of their data and to know who accessed when the data, as well as which priviledges were granted including to whom and when. The only requirement for CoMaDa is that the user sits directly before his PC, which is connected to the gateway of the WSN. This is a contradiction to the mobility requirement of the user. Thus, WebMaDa was developed and included into CoMaDa. WebMaDa is a Web-based mobile access and data handling framework allowing authorized users to publish their own WSN data online, and grant authorized users (e.g., security firm, fire department) access to the data. Additionally, WebMaDa supports pull requests allowing authorized users to reuqest sensor data independent on the pre-set intervalls used for push process. The pull requests become essential when thinking of emergency requests. Due to limited resources on the sensor node itself, the sensor node answers with a complete data set to the pull request that is filtered based on the set rights of the authorized pull requestor on the CoMaDa part before displaying the measurements on WebMaDa. In order to address the transparency request for network owners filtering options where here includes as well similar to the CoMaDa instance. The newest feature is the support of automated handling of requests (e.g., privilege granting, passwort reset) to overcome the existing delay occuring when an administrator is required to forward communication between network owners and requestors.

More details about features supported by the components can be found further below.



Topics of Future Research Interest

Contact me and talk about your interests! I am sure there are other topics that fit into the scope of SecureWSN than the ones listed here:

  • Optimization of existing components on all instances of SecureWSN
  • Extension of visualization mechanisms
  • Indoor localization and their security vulnerabilities / optimization of routing
  • Enhancing security support in general from a prevention perspective and/or on constrained devices
  • Enhancing security and performance of the database
  • ... and more! Check out here!


Overview of Deployed Network and Supported Functionalities





The figure above illustrates the cooperation between all components in the established wireless sensor network (status 04/2020):

  • CoMaDa represents the server side of the network. If needed the DTLS server part for the security implementation runs on it as well including a self-managed Certificate Authority for creating X.509 certificates. Here the figure shows the data flow within the interface and the offered functionalities including hardware configuration, management of the network components, network status and data visualization, and information storage. Additionally, CoMaDa includes an Export/Import Client for Matlab and a secured connection to Xively (a third party to visualize data) and WebMaDa. Since 2016 the visualization of the collected data can be performed without active involvement of a third party, like Xively, using now Google Charts. This change results in the fact that no data leaves the control area of the data owner. The newest feature addresses the transparency request of network owner to see who accessed what kind of data in active manner supported by detailed filtering options. Due to some situations (e.g., relocation of a node or opening a window for fresh air) received measurements might be identified as outliers and, thus, might be considered to be not trustworthy anymore. In order to automate this outlier check CoMaDa has now a trust-check operation integrated categorizing incoming measurements and informing the network owner if necessary to verify the outliers.
  • WebMaDa is a mobile interface offering visualization of data and network topology for authorized users access their WSN information via the Internet. Additionally, WebMaDa now allows authorized users to send pull-request in order to receive sensor measurements immediately. On the upper left side of the figure WebMaDa's frontend functionality is visualized. Perspectives differ depending if the logged in person is a network owner or just a user, requesting privileges to view networks. In order to ensure that only authorized persons can use WebMaDa a database server is required that hosts the access management solution. Within the last months two new features were integrated: (1) Automated request handling to reduce delays to the system due to interaction with the system's administrator and (2) filtering support for network owner addressing their transparency requests.
  • On the bottom left part a room scenario as a zoom-in example for the WSN is illustrated. The deployed sensor nodes use TinyIPFIX for data transmission purpose throughout the network up to the gateway under operating systems TinyOS and Contiki. Within the WSN some sensor nodes, usually with more resources, support special functionalities, such as data/message aggregation. The cluster head (grey ball) is a special node - called OPAL - including a trusted platform module and allows a strong two-way authentication handshake in order to establish a DTLS secured communication channel to the gateway under TinyOS. It works as a TinyDTLS client and requires X.509 certificate for authentication purposes to build an end-to-end secured tunnel with the gateway. OPAL node also supports aggregation functionality in order to transmit more data over a secured connection to the gateway. Sensor nodes not bind to a OPAL node transmitting their data over UDP to the gateway. In order to bring security to TinyOS-operating lower devices than OPAL TinySAM and TinyTO are used. Where the latter is an end-to-end solution using Elliptic Curve Cryptography. Under the operating system Contiki two security implementation - sTiki and DTLS - are available. Since end of 2020 also RIOT OS is supported in the WSN. Currently several security protocols are under deployment, where ID-based signing with group IKEv2 is already integrated allowing secure group communication.
  • Since beginning of 2021 the total system is linked to a Home Automation Solution, called HAIFA, allowing the network owner to define thresholds triggering actuators (e.g., switches or light bulbs) following the MAPE-K cycle concept. The system supports ZigBee and MQTT strategies supporting intuitive integration of new home automation hardware. To set up HAIFA the network owner requires physical access to CoMaDa, but afterwards updates for HAIFA can be done also remote via WebMaDa.


Theses or actors involved within the research area - It is/was a pleasure working with you!

Active - Research Institute CODE, University of Federal Armed Forces Munich (Germany)

Theses marked with * are supervised at the Ludwig-Maximilian University.



Running Theses/Trainings

  • Single Common Information Service Provider for Constrained Networks (MA) (*)
  • HAIFA 2.0 - Home Automation in RUST (BA)
  • MARTEN 2.0 - Dynamic Trust Check (BA)
  • Secure Data Transmission in Constrained Networks - Topic 1 (BA) (*)
  • Visualization of Collector Status with Interaction Triggering in a Dynamic Floor Map (BA) (*)
  • Waiting for you!




Alumni - Research Institute CODE, University of Federal Armed Forces Munich and Ludwig-Maximilian University (Germany)

  • Control Plane Security of LDACS (MA)
  • Design and Implemetation of a Code-Staging Solution for WebMaDa (MA)
  • ID-based Signing with Group IKEv2 in Constrained Networks (MA) (*)
  • Role/Attribute-based Privilege Management for WebMaDa (MA) (*)
  • Quantum Secure Public-Key Encryption in IoT Networks (MA) (*)
  • Schwachstellenanalyse Mercedes "Hermes" Head Unit (HU) und Telematic Control Unit (TCU) (MA)
  • Code-Documentation of WebMaDa in SecureWSN (BA) (*)
  • Controller-based Routing in Mobile Ad-hoc Networks (BA) (*)
  • Creation of a home automation system linked to SecureWSN (BA) (*)
  • Design & Implementation of a Raspberry Pi Gateway for SecureWSN (BA) (*)
  • Design and Implementation of a Geospatial IoTNaming System: Database and Web Application (BA)
  • Design and Implementation of a Geospatial IoTNaming System: Geographic Polygons (BA)
  • DTLS-based Security Solution for Constrained Devices using Contiki (BA) (*)
  • Indoor Localization under RIOT OS (*) (BA)
  • Network Ownership Transfer of WSNs Inside a Closed Network (BA)
  • Optimization of Processing and Validation of Incoming Sensor Data in an Improved Development Environment (BA) (*)
  • Raspberry Pi CoMaDa Instance Supporting Different Operating Systems and Features in Parallel (BA) (*)
  • TinyIPFIX-based Data Collection in Constrained Networks under RIOT OS (BA) (*)
  • Trustworthiness Check for Environmental Measurements in CoMaDa (BA) (*)
  • Aggregation Support in Constrained Networks following TinyIPFIX under RIOT OS (BA) (*)
  • Benchmarking für Basisfunktionalitäten in WebMaDa (BA) (*)
  • Certificateless DTLS in Wireless Sensor Networks (MA) (*)
  • Standard-based Threat Analysis of WebMaDa (BA)
  • Indoor Localization without GPS under RIOT OS (BA) (*)
  • Bidirectional communication in constrained devices (competence trainings)
  • Qualitätssicherung der Weboberfläche des mobilen Frameworks von SecureWSN (competence trainings)
  • Upgrading SecureWSN's Virtual Machine (competence trainings)
  • SecureWSN's Virtual Machine Migration (competence trainings)
  • Data Filtering Options Extension I (competence training)
  • Data Filtering Options Extension II (competence training)
  • Dockerimagebildung unter RIOT-OS auf Raspberry Pi (competence training)



Alumni - Communication Systems Group, Department of Informatics, University of Zurich (Switzerland)

  • Classification and Analysis of Security Protocols and Algorithms for Constrained Networks (FA)
  • CoMaDa Extension Addressing Transparency Request for Data Owners (VA)
  • Database Solution for Sensor Data with Authorized Data Access Solution (VA)
  • Data Gathering in Wireless Sensor Networks using IPFIX under Contiki (BA)
  • Design and Development of a Mobile App to Monitor Active Wireless Sensor Networks under Authorized Access Rules (MA)
  • Design and Implementation of a Module Framework for Sensor Data Management (BA)
  • Design, Implementation, and Evaluation of an Object Tracking Motion Detection System (MA)
  • ECC-based Security Solution for Contiki-based Sensor Networks (BA)
  • Efficient and User-friendly Handling of Access Requests in WebMaDa(BA)
  • Guideline for Mapping Security Solutions of Wireless Sensor Networks to Security Fundamentals (VA)
  • Integration of Contiki Support in CoMaDa-GUI (VA)
  • Offline Method for Graphical Visualization of Sensor Data (VA)
  • Optimization of TinyIPFIX Implementation in Contiki and Realtime Visualization of Data (SP)
  • Optimization of Two-way Authentication Protocol in Internet of Things (MA)
  • Secure Data Transmission in Contiki-based Constrained Networks Offering Mutual Authentication (BA)
  • Secure Position Data Transmission for Object Tracking using LoRaWAN (MA)
  • Secure Pull Request Development for TinyIPFIX in Wireless Sensor Network (MA)
  • Security, Privacy, and Transparency Improvements of CoMaDa (BA)
  • TinyIPFIX Aggregation in Contiki (CSI)
  • WebMaDa Extension Addressing Transparency Request for Data Owners (VA)



Alumni - Chair for Network Architecture and Services, Computer Science, Technische Universität München (Germany)

  • Data Aggregation using TinyIPFIX (BA)
  • Framework Development for WSNs facing Configuration and Information Exchange/Export Tasks (CoMaDa) (BA, Hiwi-activity)
  • TinyIPFIX support (Hiwi-activity)
  • Data collection in WSNs for Autonomic Home Networks (BA)
  • Adaption of DTLS for a Cluster-based Security Protocol in Wireless Sensor Networks (MA)
  • Security analysis for very constrainted objects (ZA, BA)
  • Key Management and Secure Data Aggregation in Wireless Sensor Networks (MA)
  • Secure Communication in WSN (BA)
  • Driver development for AutHoNe interface (Hiwi-activity)
  • Communication Standards in WSNs (BA)
  • Performance Evaluation of Routing Protocols in Wireless Sensor Networks (BA)
  • Bidirectional Data Querying with TinyIPFIX (BA)
  • Impact of asymmetric links on the performance of routing in Wireless Sensor Networks (MA)



Demonstrator: TinyIPFIX as Data Transmission Protocol with Extensions for Aggregation and Security Support

The demonstrators run currently with the following software under Ubuntu:

  • TinyOS version 2.x
  • Contiki version 2.6/2.7/3.0
  • RIOT OS









OPAL from Commonwealth Scientific and Industrial Research Organisation























Open Source Parts

Parts of SecureWSN are open source available under different licences. If you recognize any problems do not hesitate to contact me.

  • CoMaDa the Graphical User Interface under MIT-Licence - Acknowledgement to Andre Freitag
  • TinyIPFIX and Extensions under GPLv3 and eCos Licence - Ackowledgements to Thomas Kothmayr and Benjamin Ertl
  • TinyPKC is a port of the CyaSSL implentation of RSA and ECC to TinyOS 2.x that is released under the GPLv2. - Acknowledgement to Thomas Kothmayr