Show page

Differences

This shows you the differences between two versions of the page.

--- iothings:proiecte:2021:gdavid [2022/01/27 01:46]
gabriel.david
+++ iothings:proiecte:2021:gdavid [2022/01/28 00:29] (current)
gabriel.david [Resources]
@@ Line 1: / Line 1: @@
-=====  Secured communications in IOT networks  =====
+======  Secured communications in IOT networks  ======
-\\
-=== Intro ===
 \\
+==== Intro ====
 Even though IoT's popularity has grown significantly in recent years, the concept of connecting small devices to a network is not quite a novelty. Starting from the '80s, many data transfer protocol have been developed for connecting embedded devices, mainly for automatic control and industrial application: Modbus[1], BACnet, Optomux and other hundreds of protocols and variations. Those protocols were used to control both home appliances (like HVAC systems or security systems for buildings) and industrial equipment (PLC, robots, drivers and controllers for various equipments). Fifty years later, some of those protocols continue to be the //de-facto// standard in that specific technological area, but most of them are obsolete and have been replaced.
@@ Line 9: / Line 8: @@
 \\
-=== MQTT protocol ===
+==== MQTT protocol ====
-\\
 MQTT[2] is a loseless, bi-directional, connection-oriented protocol. It was first developed for industry appliances, but developed over time as a general-use IoT protocol. It has appliances in many industries: consumer products for smart home, robotics, telecom, automotive, etc.
@@ Line 36: / Line 34: @@
 \\
-=== Architecture ===
+==== Architecture ====
-\\
 The set-up is depicted in Figure 2 and represents a minimal implementation for an IoT network. The ESP32 Wroom is the only client in the network, connected to the LAN over the 802.11 WiFi infrastructure. The broker runs on a machine connected to the LAN over the Ethernet. The LAN is connected to the Internet and there are no in-bound rules defined to limit MQTT connections from outside the local network.
@@ Line 49: / Line 46: @@
 \\
-\\
-=== Mosquitto MQTT Broker ===
 \\
+==== Mosquitto MQTT Broker ====
 Mosquitto[4] is an open source MQTT broker, suitable for both research and production purposes. Although the MQTT protocol is simple and straightforward, the broker may provide lots of configuration options to control the interaction with its clients.
 In order to run Mosquitto, following packages should be installed on the broker machine (apt is the package manager of choice here):
@@ Line 67: / Line 62: @@
 \\
-=== Security levels of MQTT protocol ===
+==== Security levels of MQTT protocol ====
-\\
+=== L0: No security at all ===
-== L0: No security at all ==
 In this scenario, everyone from the Internet can connect to the MQTT broker, based on the IP address of the LAN Gateway and the port number of the Mosquitto service. Port forwarding should be configured on the router to forward all packages to the broker machine, otherwise MQTT packages may be dropped.
 An attacker can connect to the broker and publish or subscribe to the running topics. As long as the attacker is connected to the broker, it doesn't matter if other nodes secure their communication to the broker, as all data flowing through the topics will be visible to the attacker. Also, in this scenario, the broker could be flooded with new connections from fake clients.
-== L1: MQTT authentication with user and password==
+=== L1: MQTT authentication with user and password ===
 MQTT brokers can be configured to allow connections only from clients providing known credentials[5]. On the client side, the username and password are stored in clear. On the server side are stored the allowed usernames and the corresponding hash values for the passwords. The broker will receive SYN requests from everyone, but will accept only the clients with allowed credentials.
 The downside of this method, as exemplified in the Figure 3, is that that both the payload (eg. values from a sensor) and even the password in the initial SYN packet are sent over the network in clear text, so an attacker can leak this information and use the credentials to connect to the broker with its clients.
@@ Line 86: / Line 80: @@
 \\
-== L2: Application level encryption with AES==
+=== L2: Application level encryption with AES ===
 AES[6] is a standard for symmetric encryption. The design principle of AES is known as a substitution and permutation network. For both encryption and decryption operations, a matrix is built with bytes of the payload and key strings, then lines of the matrix are substituted, shifted and mixed in a certain order, for more rounds.
@@ Line 113: / Line 107: @@
 \\
-== L3: TLS encryption ==
+=== L3: TLS encryption ===
 TLS(Transport Layer Security)[9] is a protocol that runs on top of TCP (OSI 4th layer security). TLS connections are secured with a symmetric key pair, named certificate. Attackers cannot decrypt the content of the messages, not even if they assist the security negotiations (MITM attacks). The connection is guaranteed to be reliable, as TCP packets can't be dropped or altered by the attacker.
@@ Line 159: / Line 153: @@
 <html></center></html>
 \\
 \\
-=== Evaluation ===
+==== Evaluation ====
 \\
-== Test scenarios ==
+=== Test scenarios ===
 In this section, the performance overhead implied by the security levels described above is measured for the different security levels described above. **L0** implementation is used as a standard value, as there is no encryption implemented, only the wireless TX is consuming time. **L1** is not tested, as the authentication procedure is run only one time per connection and this is considered negligible overhead. **L2** and **L3** use encryption method and the performance overhead is visible.
@@ Line 185: / Line 178: @@
 Notice the TOTAL_TX_SIZE is pretty big for generic WSN nodes, which usually transmit messages of a few bytes long, but the message size was over-sized in order to test the encryption model performance.
 \\
-== Results ==
+=== Results ===
-\\
 In Figure 8, Figure 9 and Figure 10 are plotted the measured values for all experiments. On the OX axis is represented the size of one message (**MESSAGE_SIZE**) in KBytes, which is relevant for the encryption algorithm performance and memory load. On the OY axis is represented the total duration of the experiment in milliseconds.
-As expected, L0 have the least overhead, as there no encryption is involved. [TODO]
+As expected, L0 implementation has the least overhead because no encryption is involved. For low **MESSAGE_SIZE** values, the overhead of L2 and L3 compared to L0 is 200%. For bigger **MESSAGE_SIZE** values, L2 has almost 300% overhead and L3 only 150% overhead compared to L0. As more messages (TOTAL_MESSAGES) are exchanged during one connection, L2 is more dependable on **MESSAGE_SIZE** than L3. This may be because the input plaintext length for each encryption process is different for L2 and L3. Maximum TCP packet size is 64KB, but data link layer protocols allow a maximum MTU of 2304B(802.11) and 1500B (Ethernet). In a real life scenario, a maximum allowed segment size for the entire TCP packet is 1448B. L2 first encrypts the message with AES CBC, then the ciphertext is sent to the TCP layer and is split in smaller chunks. For L3, the plaintext is first split in little chunks, then each chunk is encrypted individually, so the encryption algorithm (TLS also uses AES for encryption) has to digest smaller chunks. The overhead may be introduced by the AES CBC algorithm which may have an exponential growth for the encryption time as the input plaintext size is getting larger[15].
-Although L0 and L3 run experiments with **MESSAGE_SIZE** up to 160KB, the L2 implementation run out of memory for **MESSAGE_SIZE** of 80KB and over. The ESP32[15] has a DRAM of 520KB, for .text, .data, .rodata and for .heap segments. At runtime, the .heap is limited at a maximum of 320KB, if allowed by the other segments. L2 crashed when calling the encryption function because the algorithm needs 2 * **MESSAGE_SIZE** KB dynamically allocated and there was no more space in DRAM to load the entire frame stack of the encrypt function. The memory consumption of L2 at runtime is at least twice compared to L0 and L3.
 {{ :iothings:proiecte:2021:no_enc.png?600 | Measured time for no encryption implementation(L0), tested with different TOTAL_TX_SIZE values }}
@@ Line 221: / Line 210: @@
 \\
+{{ :iothings:proiecte:2021:gdavid-fig-13.png?600 | AES CBC Encryption time related to plaintext size. }}
+<html><center></html>
+//Figure 11: AES CBC Encryption time related to plaintext size. Hardware acceleration may reduce the exponential growth. //
+<html></center></html>
+\\
+\\
-{{ :iothings:proiecte:2021:worst-case.png?600 | L0, L2 and L3 comparison for the worst-case test }}
+Although L0 and L3 run experiments with **MESSAGE_SIZE** up to 160KB, the L2 implementation run out of memory for **MESSAGE_SIZE** of 80KB and over. The ESP32[15] has a total RAM of 520KB of 3 SRAM modules. The .text section is mapped to SRAM0(192KB). The .heap section is mapped in SRAM1(128KB) and free space from SRAM0 and SRAM2 is also reserved for .heap section. L2 implementations needs 2 * **MESSAGE_SIZE** KB of memory, as the encryption function needs one source array for the plain-text and one destination array for the cipher-text. L2 implementations crashed because the heap allocator couldn't alloc more than 160KB in the remaining .heap size. The dynamic memory consumption of L2 at runtime is at least twice compared to L0 and L3. On the other side, L3 implementation uses less .heap but the .data has to store the SSL certificate key (2KB). ESP32's memory layout is represented in Figure 12. ESP32 has quite a lot of DRAM memory, but there are IoT embedded clients with less available memory.
+{{ :iothings:proiecte:2021:gdavid-fig-9.png?300 | ESP32 memory layout }}
+{{ :iothings:proiecte:2021:gdavid-fig-10.png?300 | ESP32 memory layout }}
+{{ :iothings:proiecte:2021:gdavid-fig-11.png?300 | ESP32 memory layout }}
+{{ :iothings:proiecte:2021:gdavid-fig-12.png?300 | ESP32 memory layout }}
 <html><center></html>
-//Figure 11: L0, L2 and L3 comparison for the worst-case test. //
+//Figure 12: ESP32 memory layout[14]. //
 <html></center></html>
 \\
 \\
+For small values of **MESSAGE_SIZE** and high values of **TOTAL_MESSAGES** sent during the experiment, the overhead of L2 was slightly better than L3, because the AES-CBC encryption runs for less rounds to encrypt one message, as represented in Figure 11. This is a common scenario for IoT networks, where nodes send over network small messages (few bytes up to few kylobytes). This is only valid for a high values of **TOTAL_MESSAGES**, like a client sending more times over a second floats values read from a sensor, otherwise TLS may be a better choice performance wise. Remember that only the values read from the sensor are obfuscated and an attacker is able to hack the communication.
+{{ :iothings:proiecte:2021:worst-case.png?600 | L0, L2 and L3 comparison for the worst-case test }}
+<html><center></html>
+//Figure 13: L0, L2 and L3 comparison for the worst-case test. //
+<html></center></html>
 \\
-=== Conclusions ===
 \\
-=== Resources ===
+\\
+==== Conclusions ====
 \\
-== Useful links and references ==
+The following conclusions were drawn from the above experiments:
+  * MQTT over TCP has no security at all and may be exploited in many ways.
+  * MQTT with username/password authentication provides access control to the network but may be easily exploited.
+  * MQTT over TCP and encryption at application level is the fastest available solution performance-wise only for one scenario: really small data sent over network at a high rate until.
+  * Overhead for MQTT over TCP and encryption at application level is exponentially growing over some point.
+  * MQTT over TCP and encryption at application level still may be exploited in many ways.
+  * MQTT over TLS provides best security and is the fastest method for most real life scenarios.
+==== Resources ====
+=== Useful links and references ===
     * [1] https://www.modbus.org/
     * [2] https://mqtt.org/
@@ Line 249: / Line 263: @@
     * [12] https://www.netally.com/network-performance/802-11-retries/
     * [13] https://en.wikipedia.org/wiki/Received_signal_strength_indication
+    * [14] https://blog.espressif.com/esp32-programmers-memory-model-259444d89387
+    * [15] https://link.springer.com/article/10.1007/s13204-021-01985-3
-== Project files ==
+=== Project files ===
     * {{:iothings:proiecte:2021:tls-vs-app-level-files.tar.gz|Project files (client sketches, pcaps, plots)}}