Cybersecurity for cloud-based DR solution

Cloud-based technologies have become widely used for implementation of different ICT systems due to a number of benefits such as: cost savings, quick deployment, reliability and scalability. The main issues in relation to cybersecurity for cloud-based DR solution will be explained by taking the RESPOND project as a representative use case.

Since RESPOND platform deals with highly sensitive data such as consumption patterns and home occupancy status, a way to secure such data has been considered from the initial platform design to its implementation. In particular, the aim was to undertake proper security measures in order to deal with possible communication threats that RESPOND project may encounter in relation to data acquisition, transmission and access.

In order to achieve this goal, complete end-to-end data security techniques have been defined and applied, as shown in the Figure.

RESPOND Cybersecurity

RESPOND combines encryption of communication links, internal data storages and finally it implements proper authentication and authorisation algorithms. Encryption mechanisms are based on AES-like strength techniques and are enforced on all parts of communication link (ZigBee, Ethernet, WiFi, Bluetooth and proprietary protocols).

Furthermore, RESPOND authentication and authorisation is leveraged by specification of access rights specific for each designated end user, such as building occupants, building managers or energy provider personnel.

All the data exchanged between different components of RESPOND system and external third-party services are considered to be private, and therefore they are always encrypted to ensure data privacy and confidentiality. At the application layer of the communication protocol stack (OSI 7), different protocols can be used.

In RESPOND, however, most of the components use either HTTP or MQTT protocol, depending on their needs. For both of these, protocol Transport Layer Security is mandatory. Transport Layer Security (TLS) is a cryptographic protocol aiming to provide secure communications over a computer network. Its primary purpose is to ensure privacy and data integrity between two computer application which communicate over a network.

In the sequel, we will present a brief description of the security features implemented within the components using MQTT protocol:

1. MQTT authentication by using username and password

MQTT protocol supports username and password authentication fields in the CONNECT packet, as it is shown in Table 1.


The username is encoded by using UTF-8. Previously, it was limited to 23 characters, but this limitation is removed and now it can long up to 65535 characters. On the other hand, the password is binary data with the same length limitation up to 65535 bytes. When username/password authentication mechanism is enabled, MQTT broker checks whether they are correct and returns one of the following codes:

RESPOND MQTT Return code

It must be noted that username and password are sent to the broker in plain text, which makes it vulnerable to eavesdropping, allowing attackers to easily read the credentials. In order to overcome this potential problem, transport security (TLS/SSL) must be configured and enabled, as it is the case with RESPOND platform setup.

2. MQTT broker security

Usually, Internet of Things (IoT) devices (such as those deployed in the RESPOND pilot sites), have limited computing performance and battery capacity. On the other hand, cryptographic algorithms often require more computational power than many IoT devices can actually provide. Message Queuing Telemetry Transport (MQTT) protocol security is divided into different layers of communication protocol stack:

  • Network layer: A way to ensure a secure connection to consider using physically secure network or Virtual Private Network (VPN). This approach is suitable in cases where MQTT clients and broker are connected via VPN, which may not be always suitable, as it is the case in RESPOND project.
  • Transport layer: Usually standard TLS/SSL mechanisms are used for transport encryption. By taking this approach, data cannot be overheard during transmission while identity of both sides can be verified by client-certificate authentication.

Lazar Berbakov, PhD
Research Associate
The Mihailo Pupin Institute
Volgina 15, 11060 Belgrade, Serbia
( +381 11 6775 460)
Web: www.pupin.rs

Personal energy performance assistant version 1.15 released

The version 1.15 of the personal energy performance assistant App has been released in Google Play Store and Apple Store

If you are an iOS user, you probably have missed the version 1.14. For technical reasons that are not clear to us, Apple did not approve the version 1.14 and therefore, it was only published for Android users.

The changes from the 1.13 version are:

  • Energy bonus price explanation added for Danish users
  • Normal values range added to graphics for neighbourhood electric consumption and solar thermal primary circuit temperature from Madrid pilot
  • Position changed from some neighbourhood graphics from Madrid to enhance the visualisation of more important measurements
  • Internal notification token management improved to avoid duplicated tokens
  • Several texts changed
  • Demand forecast updated with the last consumption trends derived from the COVID-19 user behaviour changes

We remind you that the app is available for Android and iOS operating systems.

RESPOND Google Play and Apple Store4

If you are an Android user, a version 6 or greater and a minimum of 45 MB free storage is required.

In order to install the RESPOND App, you find it by searching “RESPOND” in Google Play.

Or you can use this link:


RESPOND Google Play and Apple StoreIf you are an Apple user (iPhone or iPad) your operating system should be iOS 12.1 or greater and you must have at least 75 MB of storage free.

You can find the App in the Apple Store by searching “RESPOND”. Depending on the country where you are, obtained results could be different.

If you don’t find it, you can use this link:

In case you find any bug or you want to add some extra functionalities, please contact TeknikerFrancisco Diez or Gonzalo Gil.

How does RESPOND Platform work?

In this article the internal composition of the RESPOND platform is described. The next figure shows the RESPOND Architecture, where the platform components are highlighted.

Respond Platform Structure

This figure shows a conceptual vision, but the technological vision is more complex due to the use of different frameworks and the micro services approach. The result is a complete platform covering all the aspects needed to implement an IoT system: starting from the data acquisition, to their storage, integration,  processing , analysis and finally the visualisation to offer comprehensive information to the home occupants and the facility manager.

Thanks to the use of standard protocols such as MQTT, SPARQL, SQL, LDAP, HTTPS and REST, the implementation of a micro service approach is feasible, thus allowing to add, change or remove certain functionalities easily and without interfering with the rest of the system. This high degree of interoperability between systems also allows to use different frameworks to implement and integrate the micro services.

The next figure shows all the technological modules used or developed that comprise the RESPOND platform.

Respond Platform

Third party components

The MQTT broker is the component that receives data generated by the field devices. This messaging protocol is optimised for high-latency or unreliable networks and using the publish/subscribe paradigm, the broker distributes the data to the modules that need the data in real time. The technological solution that implements the MQTT protocol in the RESPOND platform is the open source  Eclipse Mosquitto (https://mosquitto.org/).

The RESPOND platform relies on the TICK Stack bundle (https://www.influxdata.com/time-series-platform/), which is composed of Telegraf, InfluxDB, Chronograf and Kapacitor. Telegraf is the component that allows to save the data received by the MQTT broker in the time series database InfluxDB. This type of database is optimised to manage IoT data acquired in real time. Chronograf is another module of this bundle that allows to visualize the data and Kapacitor is an event processor engine that allows to transform or aggregate data and send notifications when some conditions are true.

Another key component of the architecture is Nginx (https://www.nginx.com/), a web server that is also used as a proxy server for micro services and load balancing. This component allows to expose the Open REST API to interact with the services.

The OpenLDAP (https://www.openldap.org/) is an open source implementation of the Lightweight Directory Access Protocol (LDAP). The user authentication and authorisation is controlled by this component. The administration frontend for this component is the PHP LDAP Admin (http://phpldapadmin.sourceforge.net). It is also open source and is used for defining the user credentials, permissions, and groups.

Regarding the information related with the topology of the pilot sites, including the appliances and devices connected in each home, it is defined with the semantic model in the semantic repository. This semantic repository has been implemented using the open source edition of Openlink Virtuoso (http://vos.openlinksw.com/owiki/wiki/VOS)

For data not managed by the previous repositories, the general purpose relational database MySQL (https://www.mysql.com/) is used. For example, this repository contains data related with  the analytical micro services.

The R Server (https://cran.r-project.org/ ) allows the remote execution of scripts written in the R programming language. This language is the leading language to implement artificial intelligence applications and services.

Micro services Developed by RESPOND partners

All the previous components are third party frameworks and artefacts used to provide the basic functionalities needed in an IoT platform. On top of these components, the RESPOND consortium has developed a set of micro services to provide the added value capabilities to exploit the Demand Response. These micro services are described in the next paragraphs. As it is shown in the architecture, the adapters are the components in charge of gather the exogenous data to be used by the RESPOND services and the final user. In this regard, two main adapters have been developed. On the one hand, the Weather Forecast Adapter which is responsible for gathering the weather forecast data of the day ahead, and on the other, the Energy Prices Adapter which acquires the prices of electricity for the upcoming hours.

Likewise, a set of services based on the predictive analytics have been developed. The Demand Forecast service forecasts the day ahead demand at the pilot sites. The Production Forecast service forecasts the day ahead production of the RES (Renewable Energy Sources) at the pilot sites. Predictions generated by these two services are used by the Optimisation service to generate an optimised profile for every pilot site. Afterwards, his optimised profile is used by the Heuristic Optimisation service in order to generate the energy-saving recommended actions which are sent in the form of notifications to the home occupants. The daily interaction between these modules is orchestrated by the Task Scheduler service.

Last but not least, a set of have been developed with views to ensuring an adequate interaction with users. The main tool used for the interaction is the Smart Energy Assistant App, a multilingual and cross-platform mobile app which available for download both in Google Play and Apple Store Markets (http://project-respond.eu/personal-energy-performance-assistant-version-1-13-released/). The additional  services that implement the interaction with users are the following:

  • The Smart Energy Assistant Proxy is in charge of answering the requests coming from the Smart Energy Assistant App used by the occupants of the pilot homes.
  • The User Adapter is the module that manages the preferences of the home occupants in order to adapt the prescriptions generated by the backend services.
  • The Notification module sends push messages to the smartphones of the users who use the Smart Energy Assistant App.
  • The Thermal DR is the service to generate and schedule the set points used in the use case related to the thermal demand response.

Francisco Javier Díez
C/ Iñaki Goenaga, 5
20600 Eibar, Gipuzkoa (Spain)
Tel.: +34 943 20 67 44

RESPOND Events: Meet us at our Workshop in LDAC2020

LDAC2020 - Tekniker and RESPOND

Our Partner Tekniker, represented by Iker Esnaola-Gonzalez and Gonzalo Gil, will participate in the LDAC2020 – 8th Linked Data in Architecture and Construction Workshop on the 17th – 19th June 2020.

Read our full paper about “Towards Defining Data Usage Restrictions in the Built Environment” here 👉: Read Full Article.

Register to the LDAC2020 event for free and attend our online workshop: LDAC2020 Website

Stay tuned and check our latest News!