1 Introduction

The vast amount of available smart devices brings new security and privacy concerns. These devices are connected to our daily life in multiple ways and facilitate daily activities in different sectors. In fact, Internet of Things (IoT) is one of the most promising technology to be applied in mobility, healthcare, energy, and Location Based Services (LBS) scenarios, creating a massive worldwide network of interconnected physical objects [3].

Smart homes are equipped with several smart devices with diverse functionalities and collect data from different sources, from simple cases such as environmental temperature to video surveillance. Thus, this is a critical scenario where highly sensitive data is collected, sometimes without the individual’s knowledge.

The IoT devices access and process humans’ personal data highlighting the need to ensure secure and private communications to preserve data integrity and avoid unauthorized access to personal data. However, some standard devices in that kind of architecture have limited computational resources and reduced capacity to process high computational security algorithms. Typically, these kinds of devices are called resource-constrained devices, both computationally and with power constraints. In this way, lightweight cryptographic algorithms are being considered in the scientific literature [15, 36, 41, 42] to reduce the computational impact of security algorithms. These more appropriate algorithms try to ensure humans’ security and privacy with trade-offs between cost and performance.

Privacy and security level may be estimated by considering different cases of study since the application interface to the network infrastructure is highly relevant to humans taking advantage of new technologies safely and privately. Although other previous research studies focused on exploring the delay added by the security algorithms, such as [1, 9, 35], a gap in privacy and security analysis was identified: power consumption analysis and computational efficiency to examine algorithms and protocols in usual and common boards applied in typical smart homes. In such a manner, the paper intends to understand the current impact of cryptographic algorithms to evaluate the security and privacy offered using a combination of algorithms and specific boards.

The experiment in this paper, and its main contribution, intends to explore the impact of security and privacy mechanisms on top of conventional Wireless Sensor Networks (WSN) use cases. The experiment measures three fundamental metrics (power consumption, message delay, and additional bytes) using state-of-the-art communication protocols ( Hypertext Transfer Protocol (HTTP) and Message Queuing Telemetry Transport (MQTT)) and representative embedded devices (the ESP8622, ESP32, and RPi from 1 to 4). There is a huge number of smart devices with multiple characteristics. Although Arduino devices are well-known development boards, several commercial products use ESP microcontrollers instead (IoTaWattFootnote 1, TasmotaFootnote 2, amongst others). RPi devices were selected since they are heavily used for IoT projects and prototyping while being several times more capable than simple microcontrollers in computational power. The research also considers two different cryptographic algorithms. ChaCha20 [45] is the best lightweight cryptographic algorithm to be used in IoT devices by considering memory size and energy. Advanced Encryption Standard (AES) is a popular cryptographic algorithm that offers robust and platform-independent implementation [11]. Generally, ChaCha20 is faster than AES due to the mathematical operations (multiplication, rotation, and XOR) used to encrypt and decrypt the messages compared to binary digits in AES that are used for encryption to secure the messages [43].

By considering this selection, the main contributions of the paper are:

  • Overview of what is essential in a WSN regarding security and privacy.

  • Description of the most relevant cryptographic algorithms in IoT architectures.

  • Analysis of protocols and IoT boards to improve security and privacy (computational and power consumption analyses).

  • Reference for comparison amongst the very constrained devices and the opposite.

  • A simplified model that can be used to estimate the delays measured in the experiment for the considered embedded devices.

The document is organized as follows: Section 2 describes the relevant background about the current paradigm of IoT communications; Section 3 describes the privacy and data protection in IoT communications briefly; Section 4 details security algorithms in IoT devices; the experimental setup and implementation details are outlined in Section 5; the main results are presented and discussed in Sections 6 and 7 presents the relevant State-of-the-Art (SoA); and, finally, the main conclusions are discussed in Section 8.

2 IoT Communications

The IoT concept refers to a complex network of interconnected computing components such as sensors, actuators, or any other device on the Internet. The IoT paradigm resides in having a wide variety of devices connecting and sharing data over the network, including embedded devices capable of interacting with users and other devices even without user interaction ([4, 26, 44]). Since most mobile devices are equipped with WiFi to connect to the Internet, it is relevant to analyze the impact of this technology on enabling Internet Protocol (IP) connectivity of battery-powered devices. In fact, [44] demonstrates the feasibility of low-power WiFi technology in those devices.

Entirely related to the concept of the IoT paradigm is the purpose of WSN. A WSN is a network of nodes, linked via wireless media, that work cooperatively to sense and control the surrounding environment. Typically, this type of architecture has three components: sensor nodes, gateway, and observer (user) [19]. Moreover, it is applied to quotidian scenarios such as smart homes, smart agriculture, security control, and medical applications. Generally, in WSN, some aspects should be considered: reliability (the ability of a sensor to maintain its network functionality without any interruption); nodes’ density (coverage area, reliability, and accuracy); network latency characteristics (latency, capacity, and robustness); and the complexity of routing data which depends on the network topology. In addition, since sensor nodes are mainly battery-powered, each node’s lifetime depends on the battery’s lifetime and the power consumption of the work performed in that device. There is a need to develop a distributed security approach for WSNs, highlighting the necessity to have WSNs where nodes are self-organized to handle the failure of nodes. [37] proposed a dynamic and autonomous scheme for a node to select another node (in case of failure) and also to ensure the individuals’ privacy considering a delegation server based on individual consent.

Different protocols and network implementations are being used in WSNs to interconnect nodes, such as Radio Frequency Identification (RFID), Zig- Bee, Wireless Personal Area Networks (WPAN), Digital subscriber line (DSL), Universal Mobile Telecommunications System (UMTS), General Packet Radio Service (GPRS), WiFi, Worldwide Interoperability for Microwave Access (WiMax), Local Area Network (LAN), or Wide Area Network (WAN).

The scenarios like smart homes, agriculture, eHealth, or mobility, are probably the most considered in the literature where IoT devices are used. This observation has a simple explanation. IoT devices are successful solutions to simplify humans’ daily activities due to their environment monitoring and actuation abilities. [21] stated that users need to allocate an extraordinary amount of time for their routine work with little distraction taking high advantage of smart devices in their smart homes. The smart home combines smaller systems linked to the home network, containing several communication technologies that can support comfort, safety, security, and convenience to enhance residents’ lifestyles [4]. In addition, [17] reviewed the WSN-based agricultural applications and concluded that the main advantage of using WSN in agriculture is to improve quality and production.

Since these devices are connected to the Internet, transmit data over communication channels, communicate with third parties, and collect and process personal data, it is highly relevant to consider this architecture’s privacy and security aspects. Moreover, energy preservation in battery-powered devices is also important to increase sensor availability.

3 Privacy in IoT Environments

Independently of the vast advantages of deploying IoT environments, human privacy is severely affected by these environments. Most users do not understand how systems access, process, and transmit their personal data; in other cases, the users do not take care of their privacy rights [32].

The lack of users’ knowledge about how recent IoT environments monitor their life affects the users’ perception of what happens with their personal data. Researchers and Data Protection Authority (DPA)s have been working in data protection frameworks in trying to address this issue. Across the world, different frameworks are continuously being updated to make it possible to follow recent technological improvements.

Some data protection frameworks have common concepts, which is the case, for example, of General Data Protection Regulation (GDPR) in the European Union (EU) and California Consumer Privacy Act (CCPA) in California. For the scope of this work, some points may be highlighted:

  • Increase the transparency about how data is accessed, processed, and communicated with third parties.

  • Users should be able to provide informed consent to personal data collection and processing.

  • Users should be notified about what happens with their personal data.

  • Systems should provide features to users to control their personal data (for example, requesting data deletion).

Since privacy is a fundamental human right, users of the recent systems are at the top of application development concerns following data protection principles. Although, discussions about how systems should behave and how interfaces should display the content and influence users are out of the scope of this work. However, discussions about how data is processed at the communication level are considered in this work.

Encrypted communications in IoT devices are essential to prevent privacy breaches and user identification at the WSN level [31]. Understanding how to improve the computational impact of the cryptographic algorithms depending on the combination of boards and algorithms helps prevent privacy issues and ensure the good work of IoT devices. Moreover, knowing the impact on power consumption is also helpful to ensure good working order and WSN survivability since this is another parameter that prevents device failure (e.g., running out of battery).

4 Security Algorithms for IoT Devices

Security is one of the most relevant challenges in IoT communications due to the limited resources available in common devices. Thus, the problem is ensuring confidentiality, data integrity, and authentication to IoT devices even though most security mechanisms require heavy computation loads and large memory requirements.

Cryptography is essential to ensure secure data communication over the network by encrypting the data using encryption algorithms that hide the information. Some of the most relevant cryptographic algorithms available are vital in information systems security, such as Rivest-Shamir-Adleman (RSA), AES, or Data Encryption Standard (DES). However, similarly to other security schemes, cryptographic algorithms consume a significant amount of computing resources which is not compatible with the low computation power of most usual IoT devices. In addition, these devices are also quite vulnerable to hardware attacks since they are typically more accessible to an attacker than other general-purpose computing devices [34].

Lightweight cryptographic algorithms are being actively developed trying to address these challenges. There are strictly defined criteria for lightweight cryptography algorithms. However, the idea is to have a minimum size required for hardware implementation suited to the low computational power of microprocessors or microcontrollers, favoring low implementation costs and a high level of security [33, 41]. The literature indicates an increasing interest in highlighting the need for these algorithms, including block ciphers, stream ciphers, and hash functions, as described by [34] and [38].

Traditionally, secure encrypted communication between two parties requires the secure exchange of cryptographic keys. Diffie-Hellman (DH) is a established method to securely exchange cryptographic keys over a public channel. This method allows two parties, without prior common knowledge, to jointly establish a shared secret key over an insecure channel. Initially, this algorithm was based on the modulo of a prime number and the security was ensured due to the difficulty associated with Discrete Logarithm Problem (DLP) [30].

Recently, Elliptic Curve Cryptography (ECC) has been widely used as a faster and more secure alternative to algorithms based on DLP. ECC has its security based on the difficulty of solving the Elliptic Curve Discrete Logarithm Problem (ECDLP), which is considered more challenging to solve than the Integer Factorization Problem (IFP) used by RSA or the DLP, which is the basis of the ElGamal encryption scheme [24]. The advantage of elliptic curves is that they ensure a level of security equivalent to that of existing public-key systems but with shorter key lengths [7, 18, 25], as shown in Table 1.

Table 1 Key length for public-key and symmetric-key cryptography
Full size table

Using ECC for the AES-256 session, a 512-bit ECC key is required. In turn, a 15360-bit RSA key would be required to achieve comparable security, which is computationally impracticable in the current systems, both for key transmission and encryption/description operations. This huge difference makes ECC dearer and a potential algorithm for the current embedded system.

[28] showed that ECC has a great performance and makes it possible to generate smaller, faster, and more reliable cryptography keys. In addition, ECC increases the memory requirements and the execution encryption and decryption time. Also, [23] used ECC to establish a secure session key between IoT devices and the remote server, to address existing limitations related to key management and multicast security in Constraint Application Protocol (CoAP), proposing the ECC-CoAP, a lightweight and secure proposed protocol.

Due to the resource constraint of most IoT devices, it is not easy to execute or implement complex mathematical operations. This difficulty is why [2] proposes an effective, secure symmetric cryptographic mechanism based on the certificate authority management and Elliptic Curve Diffie-Hellman (ECDH) to share a digital certificate among IoT devices. In this way, they can provide an adequate lightweight digital certificate management and cryptographic scheme to help detect and prevent several cyber attacks.

[27] proposed a key management module based on trust graphs for IoT. This module allows the IoT objects to have a key pair that will be used to generate their symmetric key. It allows these IoT objects to generate and store their secret keys in a distributed manner without resorting to a central authority. This way, they can minimize the number of keys because each IoT object only shares a single symmetric cryptographic key with the objects it trusts in the network. The results show that their proposed scheme offers reduced processing, storage, and communication costs, encryption and decryption time, and minimizes energy consumption.

5 Experimental Setup

In this section, we detail how the experiment was designed. The experiment was based on a typical smart home (similar in topology to the one described here [40]), as depicted in Fig. 1. Although the topology is the same, our experiment considers two significant changes. First, it considers HTTP as a communication protocol (not only MQTT). This protocol represents typical usage in legacy systems (see Sections 5.2 and 5.3). Second, we consider the existence of a key server in the network responsible for sharing the public keys used in the scenario. The experiment is based on WiFi since it is one of the most common radio technologies used in smart home deployments (next to Zigbee and Bluetooth). The experiment was based on a physical deployment instead of a software-based simulation because one crucial objective was measuring the power consumption accurately.

The gateway is responsible for the communication between the observer and the sensor. The key server is responsible for securely sharing the session’s public keys. The experiment measures key agreement, transport delay, and encryption/decryption delay. These delays will characterize the efficiency of different security configurations within typical hardware.

Fig. 1
figure 1

Experimental setup for the proposed evaluation. The measured delays are represented with brackets

Full size image

When a key exchange uses Ephemeral DH, a temporary DH key is generated for every connection; thus, the same key is unlikely to be used twice. On the other hand, in a static DH, the shared key is generated once and may then be reused across sessions. The synchronous request-response nature of HTTP makes it ideal for the ephemeral experimentation of DH, while the asynchronous nature of MQTT makes it better suited for static DH experimentation. Therefore, our experimental setup is designed to evaluate ephemeral DH on top of HTTP, while the static DH will be deployed on top of MQTT. It is important to mention that even in a static DH implementation, the keys should be updated regularly (every n message). However, that is not explored within this work.

Due to the constrained resources on the embedded devices, the key server was introduced as the method to share the keys between entities and share the data when the HTTP was used. While running an HTTP server on the embedded device or the client is possible, the additional server’s overheads could have impact on the security performance evaluation.

All the connections between the embedded device (sensor) and the servers (either the HTTP key exchange server or the MQTT server) were unencrypted. The Arduino vanilla libraries for MQTT communication did not support Transport Layer Security (TLS), it is possible to use it with ESP-specific code, but that could also impact the security performance measurement.

In our experiment, the MQTT protocol uses static DH, meaning that the session key is computed only once. For this reason, we did not vary the ECDH since it has minimal impact on the experiment.

In the following section (Section 5.1), the hardware used for the experiment is detailed and discussed. Sections 5.2 and 5.3 described the typical message flow between the entities when the HTTP and MQTT gateways were used, respectively.

5.1 Hardware

Six different embedded solutions were selected for this work: ESP8266, ESP32, and Raspberry Pi versions from 1 to 4. It is important to mention that all boards, except for Raspberry Pi 1 and 2, have native wireless support. These two boards used the official Wireless USB dongleFootnote 3 to have wireless capabilities. The main characteristics of these devices can be found in Table 2.

Table 2 Specifications for the devices used in the experiment
Full size table

All embedded devices were connected using WiFi 802.11n on a dedicated Access Point (AP), a tp-link TL-WR802NFootnote 4. On this AP were only connected embedded devices and the remaining entities.

The remaining entities (key server, gateway, and observer) were regular computers (conventional laptops running Linux) connected to the same network. The sensors shared three environmental phenomenons: temperature, relative humidity, and atmospheric pressure. These values were measured in real-time using a BME280Footnote 5 sensing device. The BME280 was selected because it is highly used in smart home devices (for example, Xiaomi Aqara). This device is an environmental sensor with temperature, barometric pressure, and humidity.

Whenever possible, the code was written in Python. The primary reasons for this choice were the dependencies isolation through virtual environments, vast library collection (through the pip package manager), and code portability. Nevertheless, the code for the ESP boards was written in C using the Arduino IDE environmentFootnote 6. Arduino is an open-source platform and a valid option for anyone working on interactive hardware and software projects. The studies mention an increasing usage of the Arduino platform [20].

For this work, measuring the power consumption of the devices is necessary. We have used a USB meter for that task, the AVHzY CT-3Footnote 7.

5.2 HTTP

HTTP is predominantly a web messaging protocol. HTTP supports request/response RESTful Web architecture. Analogous to CoAP, HTTP uses Universal Resource Identifier (URI) instead of topics. The server sends data through the URI, and the client receives data through a particular URI. HTTP is a text-based protocol that does not define the size of header and message payloads; rather, it may depend on the web server or the programming technology. HTTP uses Transmission Control Protocol (TCP) as a default transport protocol and TLS/SSL for security. Thus, communication between the client and server is connection-oriented. It does not explicitly define Quality of Service (QoS) and requires additional support for it. HTTP, a globally accepted web messaging standard, offers several features, such as persistent connections, request pipelining, and chunked transfer encoding.

There is a single HTTP server. The same server has methods to store/retrieve the public keys (ECDH key exchange) and store/retrieve data (JavaScript Object Notation (JSON document) (as seen in Fig. 2).

Fig. 2
figure 2

WSN architecture for HTTP

Full size image

The typical sequence of messages is depicted in Fig. 3. Consider that the observer and the sensor do not operate at the same speed. Some retries should exist in a regular execution (the message retries are not depicted within the diagram).

Fig. 3
figure 3

HTTP messages exchanged between the entities

Full size image

5.3 MQTT

MQTT is a standardized publish/subscribe Machine to machine (M2M) communication protocol [39]. This protocol has low network overhead and can be implemented on low-power devices such as microcontrollers that might be used in IoT scenarios as a communication protocol for sensors [22]. It is lightweight M2M communication for constrained networks.

MQTT client publishes messages to an MQTT broker, which are subscribed by other clients or may be retained for future subscriptions. Every message is published to an address known as a topic [29]. Clients can subscribe to multiple topics and receive every message published on each topic. It uses TCP as a transport protocol and TLS for security. Thus, communication between the client and broker is connection-oriented. Another great feature of MQTT is its three levels of QoS for the reliable delivery of messages [5]. It is a very basic messaging protocol offering only a few control options.

There are two servers: the key server (the same HTTP from the previous execution) and the MQTT server. The key exchange is performed at the beginning of the session. After that, the observer subscribes to the topic sensor/bme280, and the sensor publishes to that topic (as seen in Fig. 4).

Fig. 4
figure 4

WSN architecture for MQTT

Full size image

The typical sequence of messages is depicted in Fig. 5. Considering that the observer and the sensor do not operate at the same speed, some retries should exist during the key exchange operation.

Fig. 5
figure 5

MQTT messages exchanged between the entities

Full size image

6 Results and Discussion

As previously stated, we want to evaluate the impact of security mechanisms in WSN. It is unfeasible to select all possible combinations, but we tried to select a representative approach. It is essential to mention that the selection of secure algorithms was guided by the recommendations present within the official Arduino Cryptography LibraryFootnote 8. ECDH [14] was selected as the method to exchange the secret key for that session securely, as suggested by the guidelines of the previously mentioned library. The library offers two different ECDHs: curve25519 and P-521. ESP devices support some hardware accelerator cryptographic operations, but there are more limited than the cryptographic library offered by Arduino. This library is also available on a more extensive set of embedded devices, not only Arduino and ESP.

Each embedded device will be explored considering the HTTP and MQTT protocols, the ECDH with curve25519 and P-521, and the AES[128, 192, 256] and Chacha20 as cipher algorithms.

Fig. 6
figure 6

ECDH delay for the different embedded devices. The time axis is in the logarithm scale

Full size image

ChaCha [6] is a stream cipher, while the AES [10] is a block cipher. The main difference between a Block cipher and a Stream cipher is that a block cipher converts the plain text into cipher text by taking plain text one well-defined data chunk at a time. In contrast, a stream cipher converts the plain text into cipher text by taking 1 byte of plain text at a time.

Each configuration runs for about one hour, totaling 72 hours for the entire experiment (48 hours for HTTP and 24 for MQTT). For each configuration, we measured three different latency (delay) values (as described in Section 5): the key agreement (in both parties), the transport latency, and the encryption/decryption latency (encryption on the sensor and decryption on the client). The timestamp differences measured the transport latency by taking advantage of Network Time Protocol (NTP) and the synchronization clocks between the devices.

After running the experiments described in Section 5, we gathered the power consumption and the delay added by the different security mechanisms. The results can be found in Tables 5 and 4.

The following subsections discuss the results from three perspectives: the delay added by the security mechanisms, the measured overhead in bytes added, and the recorded power consumption.

Without considering the transport delay between the HTTP and MQTT protocols, there are no major differences between their key agreement and encryption delays. For this reason, we will focus on the HTTP protocol delays. Furthermore, we are only focusing on the delays of the sensor device and not the client since the client in this experiment was executed in a conventional computer.

6.1 Delay Analysis

Before discussing the delay of the security mechanisms, it is important to mention that the transport delay in the HTTP mechanism is not as reliable as with the MQTT protocols. Due to the Request/Reply nature of the HTTP protocol, both the sensor and the observer must perform polling on the GET operations. The server is coded to return 400 BAD REQUEST when the data is unavailable, and the sensor/observer retries the request after some time. These polling operations lead to inconsistencies in the transport delay. The measured delay is the sum of the actual delay and the synchronization made by the entities during the polling operations.

These retries do not occur with the Publish/Subscribe nature of the MQTT protocol. After the initial key agreement algorithm, the observer subscribes to the correct topic and awaits the messages forwarded by the broker.

In Fig. 6, we can find the delays of the key agreement protocols for each board (the time axis is in the logarithm scale). As expected, the usage of different cipher algorithms does not impact on the delay of the key agreement protocol. The fastest boards (RPi) can compute the shared key with a smaller delay. Finally, the delay of P-521 is several times higher than that of Curve-25519.

Fig. 7
figure 7

Cipher delay for the different embedded devices

Full size image

In Fig. 7, we can find the delays from the cipher algorithm for each board. As expected, the stream cipher ChaCha20 is the fastest overall. The block cipher AES has a delay proportional to its key size. Contrary to the results with ECDH, the fastest boards (RPis) have the worst times for the encryption operation. There are some possible explanations for this. First, the code for the ESP devices is a highly optimized library developed especially for small boards. In contrast, the Python library on Raspberry Pi devices uses OpenSSL as the backend for cryptographic computations. To the best of our knowledge, the OpenSSL shipped with the Operative System (OS) is not optimized for embedded devices. Second, while the ESP devices only run a single program (do not have an OS), the Raspberry Pi has a full-fledged OS running with other processes.

6.2 Size Analysis

Another way to measure the impact of security methods is to compute the ratio of extra bytes shared between the entities. Let us assume that the normal message, without any cipher applied, is N bytes. All the cipher algorithm evaluated requires an initialization vector (IV) to be sent to the other entity. Lets us define the size of IV as I. For the ephemeral DH, changing the public key between the two entities is also necessary. Let us define the size of the public keys as P.

The ratio for ephemeral DH is given by equation 1, where N is the size of the original message (plain text), P is the size of the public key, and I is the size of the IV.

$$\begin{aligned} \frac{N+2P+I}{N} \end{aligned}$$
(1)

Both P and I are constants during the session. We can simplify the ratio by replacing the \(2P+I\) with k (a constant for the session). This simplification generalizes the equation, making it usable for the static DH scenario. In this scenario, the value k would be only the size of the IV: \(k=I\). The public keys are shared only once at the beginning of the session.

Fig. 8
figure 8

Relation between computational capabilities (\(\frac{1}{c}\)) and the encryption duration (t ms). The boards with less computational power achieved faster encryption times

Full size image

The ratio equation simplifies to equation 2 where N is the size of the original message (plain text), and k is the constant value that depends on the type of ECDH (static or ephemeral).

$$\begin{aligned} \frac{N+k}{N} \end{aligned}$$
(2)

One crucial property of equation 2 is that the limit of the ratio when the size of the data increases (\(N\rightarrow \infty \)) the ratio tends to 1 (as seen in equation 3).

$$\begin{aligned} \lim _{N\rightarrow \infty } \frac{N+k}{N} = 1 \end{aligned}$$
(3)

The main of this property is that, since the security bytes are finite in size, as the data part of the message increases, the extra bytes added by the security methods are negligible. Table 3 lists the ratios for the experiment done in this work. The size of the raw message is 128 bytes, and the IV is 16 bytes. The size of the public keys is 32 and 132 bytes for Curve25519 and P-521, respectively. As stated previously, for the static ECDH, we do not consider the size of the public keys. The impact of security measures is significant when considering ephemeral DH and is minimized with the static DH.

Table 3 Ratios for the experiment
Full size table

6.3 Modeling Security Algorithms

The authors of [13] present a simple linear model to estimate the time a security operation lasts based on the text size and the CPU frequency, and bus size (see equation 4).

$$\begin{aligned} t = \frac{a + b \lceil \frac{text\_length}{block\_size}\rceil }{cpu\_frequency \times bus\_witdh} \end{aligned}$$
(4)

We adopted this model as it appeared to work well on the boards evaluated in the paper. The ESP boards are quite similar to the Arduinos used by the authors. The RPi devices are more complex and may not be correctly modeled with a simple linear equation. In this subsection, we explore if a simple linear equation is sufficient to model the typical cryptographic algorithms used in WSN.

The variable \(text\_length/block\_size\) is constant within our simulation, all messages have a fixed length (128 bytes), and the block size for all cipher algorithms evaluated is 16 bytes. With a simple reorganization, it can be written as seen in equation 5, where p is \(text\_length/block\_size\) and c is \(cpu\_frequency \times bus\_witdh\).

$$\begin{aligned} t = a \times \frac{1}{c}+b\times \frac{p}{c} \end{aligned}$$
(5)

We now have a linear equation where t is the dependent variable, c and p are the independent variables, and a and b are the weights of the linear system. Since it is a linear equation, we can use the least square optimization to find the ideal values of a and b. We generated a dataset using an Excel spreadsheet and a Matlab script to perform the linear regression (the script uses the regress command).

Fig. 9
figure 9

Relation between \(\frac{1}{c}\) and the cipher duration (t)

Full size image
Fig. 10
figure 10

Relation between the ECDH duration with the \(\frac{1}{c}\) and the ECDH duration with the public key size

Full size image

Using the values from our simulation (for the cipher algorithms), we obtained the following values: \(a=1.2869E09\) and \(b=-3.2171E08\). However, the coefficient of determination (\(R^2\)) was close to zero, meaning that our data could not be fitted with a linear function. This result is expected. To illustrate this point, in Fig. 8, we plotted the relationship between \(\frac{1}{c}\) and the encryption duration (t). As we can see, the boards with less computational capabilities (represented by the red line) achieved faster encryption time (represented by the blue bars).

There are two possible explanations for this. First, the code for the ESP devices is a highly optimized library developed especially for small boards. In contrast, the Python library on Raspberry Pi devices uses OpenSSL as the backend for cryptographic computations. To the best of our knowledge, the OpenSSL shipped with the OS is not optimized for the devices. Second, while the ESP devices only run a single program (do not have an OS), the Raspberry Pi has a full-fledged OS running with other processes.

The next logical step is to divide the dataset into two, one for ESP-based devices and another for RPi-based devices. Given the significant differences between these types of boards, it is difficult to assume that a linear model could capture the underlying model. We again plotted the relationship between the variables in Fig. 9. The relation for the RPi devices appears to follow a linear approach. On the other hand, ESP devices are not as well defined. The key size appears to have greater importance for the ESP devices (the AES algorithm uses three key sizes [128, 192, 256] and the ChaCha also uses 256). And the type of cipher algorithms: block (AES) or stream (ChaCha) cipher.

We applied the previous linear model to both datasets (ESP and RPi). The RPi dataset, the model reached a 0.98 of \(R^2\) with the following values: \(a=7.6329E09\) and \(b=-1.9082E09\).

For the ESP dataset, the model reached a 0.633 of \(R^2\) with the following values: \(a=9.1344E8\) and \(b=-2.2836E8\). The linear model is a good fit for the RPi devices. Although the performance of the ESP devices increased, the value of 0.633 is not close enough to be a relevant model.

Fig. 11
figure 11

Power consumption on the booth protocols

Full size image

We expanded the linear model to have two other variables, as seen in equation 6, where p is \(text\_length/block\_size\), c is \(cpu\_frequency \times bus\_witdh\), k represents the key size [128, 192, 256], t represents the type of cipher (0 for block and 1 for stream) and [a, b, d, e]: are the weights of the previous mentioned independent variables.

$$\begin{aligned} t = a \times \frac{1}{c}+b\times \frac{p}{c}+d\times k+e \times t \end{aligned}$$
(6)

After adding these two values to the dataset, the performance increased to 0.844 \(R^2\) with the following values: \(a=9.7978E8\), \(b=-2.4495E8\), \(d=1.3425E-3\) and \(e=-6.5253e-1\). The last mentioned models could capture the linear pattern from the underlying model and can be useful for the modulation and estimation of security overhead on embedded devices.

Finally, we adapted the linear equation from [13] to ECDH time estimation. Similarly to the previous analysis, we plotted the relationship between the ECDH duration with the \(\frac{1}{c}\) and the ECDH duration with the public key size (see Fig. 10).

Although the \(\frac{1}{c}\) does have a perfect linear relation with the duration of the ECDH algorithm. The linear model becomes a better fit by adding the public key size (second plot). The adapted linear equation is given by equation 7, where c, is \(cpu\_frequency \times bus\_witdh\), k is the size of the public key used by the algorithm and [a, b]: are the weights of the previous mentioned independent variables.

$$\begin{aligned} t=a\times \frac{1}{c} + b\times \frac{k}{c} \end{aligned}$$
(7)

By replacing the values and using the previously mentioned least square optimization, we get a value of 0.751 \(R^2\) with the following values: \(a=-3.7727E6\) and \(b=1.5566E5\). Although it is the lowest value obtained (from valid models), this model combines ESP and RPi devices, making this model generic. It also points to another interesting result, the internal implementation of ECDH is not/could not be appropriately accelerated by hardware.

6.4 Power Consumption Analysis

We observed in Fig. 11 (as in Tables 5 and 4) that the power consumption within embedded devices does not change significantly with each security configuration. It considerably varies when taking into account the communication protocol, with HTTP consuming slightly more (as it implements the Ephemeral DH). A possible reason for this behavior is that the sensor only publishes a message per second, causing the CPU to be idle most of the time.

Although power consumption does not vary greatly in the same embedded device, the most potent devices consume less power during the experiment, except for the RPi 4. This statement appears counter-intuitive but is explained by the previous observation. Most of the time, the CPU is idle. The fastest CPU spends more time idle, while the slower CPU spends more time in load, as seen in Fig. 12.

Fig. 12
figure 12

CPU processing time for a single message

Full size image

Accounting for this imbalance means that, for this scenario, the ESP32 consumes less power than the ESP8266. Similarly, RPi 3 consumes less power than RPi 1 and 2. The direct comparison between ESP and Raspberry Pi is not interesting. The ESP-embedded device is rather simple and can only run a single program. While the Raspberry Pi is a small computer that runs a full-fledged OS and can execute multiple processes.

RPi 4 is an exception to this observation. Although the CPU speed only increased 300Mhz from the previous iteration, several other changes were made to the boards, such as adding a novel power delivery system based on USB-C, the addition of Wireless AX and gigabit Ethernet, and finally, the addition of a USB3 chip and ports. All of these changes may explain the high power consumption of this board.

7 Related Work

The impact of cryptographic algorithms in WSN has been studied in the literature. It is not a recent problem, but different lightweight algorithms and devices are considered in various studies. In addition, different applicability scenarios are contemplated.

Dhanda et al. [8] provided a comprehensive survey where 21 lightweight block ciphers, 19 lightweight stream ciphers, 9 lightweight hash functions, and 5 variants of ECC were compared in terms of chip area, energy, power, hardware and software efficiency, throughput, latency, and Figure of Merit (FoM). The conclusion resulted from comparing the remaining practical studies in the literature where the performed simulations outputted results to compare the performance of different algorithms. The results showed that AES remains the preferred choice for security, and it is the most competitive cipher among block ciphers; ECC also remains the option that provides authentication and non-repudiation in addition to confidentiality. However, this study does not contemplate a selection of devices and respective analyses of the algorithms.

Haque et al. [16] focused on performance analysis of cryptographic algorithms (AES, RC4, Blowfish, CAST, 3DES, Twofish as symmetric key encryption and Digital Signature Algorithm (DSA) and ElGamal as asymmetric encryption algorithms) in resource-constrained devices and examined the key size, data blocks, data types, and encryption/decryption speed. However, this study did not examine the impact on different devices and provided no comparison between devices, only between algorithms. We considered it relevant to experiment with how different devices and algorithms impact these parameters to provide a reference for future researchers or developers simply identify the best combination of device and algorithm according to theequirements.

Fotovvat et al. [12] proposed a more practical analysis considering devices and algorithms, similar to the idea of the current paper, and compared the performance of 32 lightweight algorithms from different categories permutation, block cipher, stream cipher, and tweakable block cipher). These algorithms were tested in well-known devices (RPi 3, RPi Zero W, and iMX233, in terms of power consumption, random access memory usage, and execution time. One of the outcomes of this study is to assist researchers in weighing the pros and cons of different design topologies. The idea of this study is very aligned with the current paper, and both consider the test on RPi 3. However, both papers consider other different devices and other lightweight algorithms. [12] focused on recent algorithms that could be used in future applications, while the current paper focused on existing and severely used algorithms.

Table 4 Results from the experiment MQTT
Full size table

8 Conclusion

In this paper, we considered the security impact on systems performance as a scientific contribution in terms that researchers or service providers can directly understand how systems may be affected by cryptographic algorithms. In this case, we focused on WSN since these environments traditionally handle constrained devices with less computational power to run security algorithms. We considered this analysis important due to the high applicability of these network architectures in Smart Homes. The lack of systems mechanisms to prevent abusing the users’ privacy affects the users’ safety severely. Security mechanisms are important to prevent users’ privacy abuse and to avoid malicious entities accessing unauthorized data. In this way, this paper focuses on a specific case where boards used on smart devices, typically applied in smart homes, were analyzed to help users, developers, or service providers choose the most appropriate cryptographic algorithm for the corresponding board in order to optimize the computational power and energy-efficient performance of the system, to ensure the existence of security.

This paper intends to address important identified gaps: security mechanisms’ overheads within small sensing devices are still not completely explored; previous studies focused on measuring the delay added by the security layer but were still missing studies considering the power consumption. For those reasons, the described study considers the power consumption analysis within representative WSN use-cases, using SoA communications protocols (HTTP and MQTT) and representative embedded devices (used in usual and common smart home scenarios): ESP8622, ESP32, RPi1, RPi2, RPi3, and RPi4.

We found that the security algorithms on WSN considerably impact the size of the messages and times of execution. Although the power consumption within the same embedded device does not vary with the multiple security configurations, the boards with a faster CPU tend to use less power. The literature review in Section 7 did not clearly indicate that the power consumption would follow the pattern identified in this work. As the size of the raw message increases, the extra bytes added by the security algorithms becomes less relevant.

A possible limitation is the number of brands of boards selected for the study. In fact, it was impractical to choose and implement all the existing boards. For this reason, we selected the most significant ones.