# Rapidly Deployable IoT Architecture with Data Security: Implementation and Experimental Evaluation
## 4 Application Implementation
### Testbed Setup  
The proposed testbed consists of two microcontrollers (8-bit and 32-bit) and their respective software and programming tools to implement the aforementioned block ciphers. The 8-bit PIC microcontroller is chosen for evaluating XTEA and software AES in low resource embedded platforms. It had 128 Kbytes [58] of program memory, sufficient to implement the software AES algorithm. This combined with eXtreme Low-Power (XLP) technology makes it energy efficient and ideal for IoT applications. As many microcontrollers for IoT edge devices such as PIC18F24K42 do not have large program memory space, software AES cannot be implemented in them [59]. The 32-bit MSP432 microcontroller has an AES hardware accelerator, enables the microcontroller to perform complex computation without consuming precious program memory, and is efficient in terms of time and power. AES can be implemented in software across different architectures (8-bit, 16-bit, and 32-bit), but is not as efficient as hardware accelerated AES. A software implementation of XTEA was done on all platforms including the 8-bit microcontroller, which does not have a hardware accelerator. Figure 4: One cycle of XTEA. From the proposed testbed, the cycles, power, code size, and RAM space required to encrypt and decrypt sample data were measured. The execution time was measured in terms of clock cycles using the oscilloscope in Figure 5 and the experimental setup in Figure 6. The internal timers inside the microcontrollers were used to record the number of cycles while encrypting and decrypting sample data. To further verify the results, the execution time was also measured with an oscilloscope. Hardware efficiency can be measured in terms of latency, clock cycles, and power consumption. Software efficiency can be quantified by considering the number of cycles it takes to encode and decode data sets. As most sensor nodes in IoT applications have limited resources and often feed sensor data to the cloud in real time, the encryption process should not add much overhead. As most sensor nodes are either battery powered or have stringent restrictions on power, it must be ensured that data encryption does not increase the power consumption. To measure the time required to encrypt data, one of the output pins of the microcontroller was driven high at the start of the encryption process and driven low at the end providing a pulse equal to the encryption time, which was measured with an oscilloscope. Keysight's InfiniVision MSO-X 3054T Oscilloscope was used to conduct all the measurements. The same process was taken to measure the timing of the decryption process. The power was measured with the help of a current measurement tool called a Real-time current monitor [60]. This tool has a precise current sensing resistor and amplification stages to measure in line low dynamic currents. The amplification stages are fast enough to capture instantaneous data which is essential as the encryption and decryption time is in the order of tens of milliseconds. The measured values were exported to the computer with the help of the USB connectivity of the current measurement tool. The instantaneous current values during encryption and decryption were multiplied with the reference power supply unit Tektronix PWS 2323 to get the power  
Figure 5: Block diagram of the testbed. Figure 6: Experimental setup for measuring execution time. The voltage of the power supply was measured at the device under the test end with Tektronix DMM 4020 precision benchtop multi-meter to compensate for the wire losses. The respective timing data was used to obtain the energy used for the encryption and decryption process. The code size was acquired from the hex file generated by the compiler. The RAM space was obtained from the compiler. The optimization feature in the compilers was disabled to cancel out any interferences caused by the compiler optimization. All the microcontrollers were run at the same speed to negate the effects of the CPU clock speed on the encryption/decryption timing.