A Practical Evaluation of a High-Security Energy-Efficient Gateway for IoT Fog Computing Applications

Abstract

Fog computing extends cloud computing to the edge of a network enabling new Internet of Things (IoT) applications and services, which may involve critical data that require privacy and security. In an IoT fog computing system, three elements can be distinguished: IoT nodes that collect data, the cloud, and interconnected IoT gateways that exchange messages with the IoT nodes and with the cloud. This article focuses on securing IoT gateways, which are assumed to be constrained in terms of computational resources, but that are able to offload some processing from the cloud and to reduce the latency in the responses to the IoT nodes. However, it is usually taken for granted that IoT gateways have direct access to the electrical grid, which is not always the case: in mission-critical applications like natural disaster relief or environmental monitoring, it is common to deploy IoT nodes and gateways in large areas where electricity comes from solar or wind energy that charge the batteries that power every device. In this article, how to secure IoT gateway communications while minimizing power consumption is analyzed. The throughput and power consumption of Rivest-Shamir-Adleman (RSA) and Elliptic Curve Cryptography (ECC) are considered, since they are really popular, but have not been thoroughly analyzed when applied to IoT scenarios. Moreover, the most widespread Transport Layer Security (TLS) cipher suites use RSA as the main public key-exchange algorithm, but the key sizes needed are not practical for most IoT devices and cannot be scaled to high security levels. In contrast, ECC represents a much lighter and scalable alternative. Thus, RSA and ECC are compared for equivalent security levels, and power consumption and data throughput are measured using a testbed of IoT gateways. The measurements obtained indicate that, in the specific fog computing scenario proposed, ECC is clearly a much better alternative than RSA, obtaining energy consumption reductions of up to 50% and a data throughput that doubles RSA in most scenarios. These conclusions are then corroborated by a frame temporal analysis of Ethernet packets. In addition, current data compression algorithms are evaluated, concluding that, when dealing with the small payloads related to IoT applications, they do not pay off in terms of real data throughput and power consumption.

Keywords: ECC; ECDHE; ECDSA; IoT; IoT gateway; IoT security; RSA; TLS; cryptographic security; energy efficiency; fog computing; performance; power consumption.

Figure 1

Generic Internet of Things (IoT) fog computing architecture.

Figure 2

Transport Layer Security (TLS) Handshake procedure for ECDHE-RSA-AES128-GCM-SHA256 and similar cipher suites.

Figure 3

Key size needed for different security levels using symmetric, Rivest–Shamir–Adleman (RSA) and Elliptic Curve Cryptography (ECC) ciphers.

Figure 4

Orange Pi PC Printed Circuit Board (PCB). Top view (A) and bottom view (B).

Figure 5

Testbed. (A) Orange Pi PC Single Board Computers (SBCs); (B) INA219; (C) switch; (D) power supply; (E) cooling fan.

Figure 6

Detailed testbed architecture.

Figure 7

Power consumption during 10 min for idle state and 16 concurrent clients accessing a 512 byte payload served by Nginx using HTTPS and HTTP.

Figure 8

Server-side page size versus energy consumption for Apache2 and Nginx with 16 concurrent clients, with and without GNU ZIP (GZIP) compression.

Figure 9

Client-side page size versus energy consumption for Apache2 and Nginx with 16 concurrent clients, with and without GNU ZIP (GZIP) compression.

Figure 10

Server-side page size versus energy consumption for Apache2 and Nginx with two concurrent clients.

Figure 11

Server-side page size versus energy consumption for Apache2 and Nginx with 16 concurrent clients.

Figure 12

Server-side page size versus energy consumption for Apache2 and Nginx with 128 concurrent clients.

Figure 13

Server-side concurrent clients versus throughput for Apache2 and Nginx with 512 bytes of payload for Elliptic Curve Digital Signature Algorithm (ECDSA), Rivest–Shamir–Adleman (RSA), and HTTP.

Figure 14

Server-side concurrent clients versus throughput for Apache2 and Nginx with 512 bytes of payload for Elliptic Curve Digital Signature Algorithm (ECDSA) and Rivest–Shamir–Adleman (RSA).

Figure 15

Server-side concurrent clients versus requests/mWh for Apache2 and Nginx with 512 bytes of payload for Elliptic Curve Digital Signature Algorithm (ECDSA) and Rivest–Shamir–Adleman (RSA).

Figure 16

Client-side page size versus energy consumption for Apache2 and Nginx with two concurrent clients.

Figure 17

Client-side page size versus energy consumption for Apache2 and Nginx with 16 concurrent clients.

Figure 18

Client-side page size versus energy consumption for Apache2 and Nginx with 128 concurrent clients.

Figure 19

Client-side concurrent clients versus requests/mWh Apache2 and Nginx with 512 bytes of payload for Elliptic Curve Digital Signature Algorithm (ECDSA) and Rivest–Shamir–Adleman (RSA).

Figure 20

Total energy consumption for a 512-byte payload for 32 concurrent clients. Client and server-side consumption stacked for Apache and Nginx using Elliptic Curve Digital Signature Algorithm (ECDSA), Rivest–Shamir–Adleman (RSA), and plain HTTP.

Figure 21

Handshake and payload communication times for 512-byte and a 128-kilobyte payloads using Elliptic Curve Digital Signature Algorithm (ECDSA), Rivest–Shamir–Adleman (RSA), and HTTP, with and without GNU ZIP (GZIP) compression using Apache2. * HTTP handshake for HTTP, Transport Layer Security (TLS) and HTTP handshakes for ECDSA and RSA.

Figure 22

Handshake and payload communication times for 512-byte and a 128-kilobyte payloads using Elliptic Curve Digital Signature Algorithm (ECDSA), Rivest–Shamir–Adleman (RSA), and HTTP, with and without GNU ZIP (GZIP) compression using Nginx. * HTTP handshake for HTTP, Transport Layer Security (TLS) and HTTP handshakes for ECDSA and RSA.

Figure 23

Time elapsed until each main step of the Transport Layer Security (TLS) handshake, start and end of the data transmission. * The frame contains several messages besides the Server Hello/Client Key Exchange/Handshake Messages.