Show page

Differences

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

--- iothings:proiecte:2021:gdavid [2022/01/27 16:58]
gabriel.david [Resources]
+++ iothings:proiecte:2021:gdavid [2022/01/28 00:29] (current)
gabriel.david [Resources]
@@ Line 184: / Line 184: @@
 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].
 {{ :iothings:proiecte:2021:no_enc.png?600 | Measured time for no encryption implementation(L0), tested with different TOTAL_TX_SIZE values }}
@@ Line 210: / Line 210: @@
 \\
-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.
+{{ :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>
+\\
+\\
+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 }}
@@ Line 217: / Line 224: @@
 {{ :iothings:proiecte:2021:gdavid-fig-12.png?300 | ESP32 memory layout }}
 <html><center></html>
-//Figure 11: ESP32 memory layout. //
+//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 12: L0, L2 and L3 comparison for the worst-case test. //
+//Figure 13: L0, L2 and L3 comparison for the worst-case test. //
 <html></center></html>
 \\
@@ Line 233: / Line 241: @@
 ==== Conclusions ====
 \\
+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/
@@ Line 250: / Line 264: @@
     * [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 ===