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 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:
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.