## 6 Evaluation and Analysis
### Experimental Evaluation  
In this section, we evaluate the performance of our concept through extensive experiments and verify its superiority in comparison to the standard traditional SOTA process. We built the test target ECU using an Infineon AURIX(\({}^{TM}\)) starter kit triboard [27] with a TC49x 32-bit microcontroller operating at a 400 MHz CPU clock and connected to a laptop acting as the repository through the UART/USB interface. We initially started our implementation with a TC39x 32-bit microcontroller [28]. However, given that the TC49x offers more support for different hash algorithms implemented in hardware, it is efficient to compare results with the same experimental conditions where hashes are calculated by hardware engines in the TC49x instead of being calculated by software for the cases where the TC39x does not support the required hash algorithms (e.g., the case of SHA3-512). The hardware security is typically a small cost adder (less than 10%) and nowadays it has become a necessity in ECUs. Thus, our experiments used security hardware engines to perform the hash calculations and signature verification operations. The full sequence of secure MT-SOTA implementation in the ECU is shown in Figure 11. To simplify the system, a new image is flashed to the triboard using programming tools. In addition, cryptographic key setup is out of the scope, and keys are loaded to the device using programming tools. The application software is stored in the physical non-volatile memory (NvM). Given the memory layout of the microcontroller we are using, we have six program flash (Pflash) banks used for application cores and one Pflash bank used for the security core. We designed and located the main scheduler and MT-SOTA scheme handler in Pflash0. The application software clusters are located in any of the Pflash1 through Pflash5 NvM banks. The security software, located in Pflashcs, is responsible for executing on-demand cryptographic functions (e.g., hash computations) initiated by the  
Figure 11: Secure MT-SOTA workflow sequence within the ECU. Once image is received, the signature verification is performed before installing the image. handler. As the smallest erasable Pf flash size is 16 Kbyte, we assume that the smallest size of any software cluster or block is 16 Kbyte and its size should always be a multiple of 16. We assume that we have N software images in addition to the security image and the main MT-SOTA handler image. Thus, we have N + 2 image binaries to flash on the device. We present the non-volatile memory map layout as shown in Figure 12.  
Software clusters (SWC) are usually separated based on various criteria such as safety level, functionality, virtual platforms, etc. We analyze different generic-use-cases to reflect different flash memory sizes, different numbers of software clusters, and different hash algorithms. We experimented with the performance of these use cases built with a combination of parameters, as shown in Table 3. Because the encryption and decryption of the Merkle tree root are the same for all use cases, we do not include it in the results to emphasize the performance results of the MT-SOTA scheme itself. The computation of hashes is performed using cryptographic services (algorithms that map arbitrarily sized data to a fixed size output). These cryptographic routines can be implemented in software or hardware, and mixed setups can be supported. It should be possible for different applications to have different underlying cryptographic primitives or schemes. This flexibility is one of the advantages of this approach. For example, one software cluster might use SHA-2 as the hash algorithm, while another software cluster uses a SHA-3 hash algorithm. Excluding some exceptions, more hash output bits aim to achieve stronger security and higher collision resistance. As a general rule, 512-bit hash  
Figure 12: Software memory mapping for the ECU test case.