Security for Connected Objects
Descriptive Part
The goal of the security course was get a good understanding of the principles and challenges of security in various domains, the course was articulated around different aspects of security each focusing on unique challenges and methods to protect systems.
In the cryptography course, we explored how to secure information through mathematical encoding techniques to ensure data integrity, confidentiality, and authentication (RSA, AES, TLS…). We covered theorical concepts and real-world cryptographic algorithms.
In the course on side-channel attacks, we focused on how attackers can exploit unintentional information leaks (like power consumption or timing differences) to break cryptographic systems. This covered practical examples like “Flush and Reload” or “Prime and Probe” to know the risks and defenses in hardware systems.
In communication protocol security, we learned the basics on how to design and verify secure protocols for data exchange. We got introduced to threats like replay and impersonation attacks. In addition, we got a small introduciton on formal methods (ProVerif…) to prove that protocols are mathematically secure.
The web application security module introduced us to vulnerabilities like SQL injection and cross-site scripting (the most common threats faced by websites).
Finally, reverse engineering microarchitectures taught us how to analyze hardware systems to understand their design and identify potential weaknesses. All theses courses where complemented by practical labs to better understand the concepts.
But that’s not all, we also had a course and practical lab on quantum security that covered quantum security mechanisms like BB84.
Technical Part
Security Features of the Interdisciplinary Project
Security is a crucial aspect of all projects involving some sort of communication, especially in a Wireless Sensor Network where data integrity and confidentiality are essential.
Context and Challenges
To add a bit of context on the matter, our interdisciplinary project aim to detect water leaks using a distributed network of sensors (WSN), each equipped with an ESP32 and a LoRa module for communication. These sensors transmit a payload consisting of metrics (frequency and harmonic data, timestamps, etc…) and edge computing analysis preliminary results (output of small machine learning models). Our LoRa module (SX1278) operate on frequencies ranging from 410MHz to 525MHz and is designed for low power consumption and limited bandwidth. Without any security features each sensor node is vulerable to every attack imaginable (replay attacks, data tempering, eavesdropping…). Consequently it is necessary for the project to implement a security solution that protects data integrity and confidentiality without introducing too much overhead.
Proposed Solution
We propose a lighweight security mechanism based on pre-shared symmetric keys that use AES-128 encryption: each sensor encrypts its data using AES in Cipher Block Chaining (CBC) mode with a unique and randomly generated Initialization Vector (IV) for every message. The IV is then transmitted with the actual message.
The issue with this method is that we have to transmitt the Initialization Vector with each message. Depending on the IV size (16 bytes usually) this can add significant overhead, and with LoRa (maximum packet size 256 byte) we can’t afford it. This led me to think a new solution.
Instead of sending the whole Initialization Vector we can store a static decimated 14 byte version on each nodes and only send two (65,536 (2^16) possible combinations) randomly generated bytes as a “salt” to complete the IV. This solution alter AES security but this tradeoff is acceptable for the application. Moreover the Initialization Vector goal is to introduce some randomness in the cryptographic process in order to prevent replay attacks, but fortunately our application transmitt FFT data in its payload, but Fast Fourier Transformations induce significant chaos and randomness which results in the extremely low probability of message duplicata thus naturally tampering potential replay attacks.
AES encrypt that in blocks of 16 bytes, if the clear message size is not a multiple of 16 it is necessary to add padding to the end of the message. In our implemetation we use PKCS#7 padding, the value of each padded added byte is the number of bytes that are added. For example, if 5 bytes are needed, each of the 5 bytes will have the value 5.
In optimal conditions as LoRa 256 Bytes is a multiple of 16, total overhead added by the cryptographic process is 2 Bytes.
Implementation
In order to implement AES on the microcontroller we first thought about implementing AES in bare-metal without library as its not a particularly complex algorithm but we found TinyAES (https://github.com/kokke/tiny-AES-c), a lightweigh cross platform library.
Source code of the implementation: light-encrypt
[Test Task] Original Message: Hello World
[Test Task] Encrypted Data:
04 b4 d0 b0 1a f1 c4 a6 94 95 b3 f2 6c 4a ee fd 82 2c
[Test Task] Decrypted Message: Hello World
[Test Task] Original Message: Hello World
[Test Task] Encrypted Data:
78 d8 f3 74 04 7b fb 13 49 d2 f7 a8 65 36 a3 01 39 cc
[Test Task] Decrypted Message: Hello WorldCode: Testing the implementation on the ESP32-C3 in C
In the demonstration above we can clearly see the entropy implemented by the IV, while the clear message is identical, the encrypted output is absolutely different. This mechanism effectively prevents replay attacks.
SQL Injections
SQL injection is a type of attack (maybe the most used on the web) where malicious SQL code is injected into a website input fields, exploiting vulnerabilities to manipulate the database, the attacker can for example log as admin or retreive confidencial data.
The expression ' OR '1'='1 is probably the blink led program of SQL injections attacks. It works by exploiting vulnerable user input fields. The logic of the query always return TRUE.
For example, consider the following SQL query for user authentication:
SELECT * FROM users WHERE username = 'admin' AND password = 'password';If an attacker inputs admin' OR '1'='1 as the username, the query becomes:
SELECT * FROM users WHERE username = 'admin' OR '1'='1' AND password = 'password';The '1'='1' part is always true, causing the query to return all rows from the users table, bypassing authentication.
You can try the simulator below to test it by yourself. (Hint: Try admin' OR '1'='1 in the username input field)