# Enhancing Resilience in Digital Twins: ASCON-Based Security Solutions for Industry 4.0
## 3 Proposed Solution
### Ditto Java Base Payload Mapping
\begin{table}
\begin{tabular}{c c c c} \hline  & **No-Encryption** & **ASCON** & **AES-GCM** \\ \hline Cycle Count & 2009 & 36,811 & 49,956 \\ Byte Processed & 32 & 32 & 32 \\ CPU Freq MHz & 240 & 240 & 240 \\ Cycle per byte & 64.28 & 1094.68 & 31,517.90 \\ Time Elapsed μs & 8.57 & 145.95 & 202.38 \\ Throughput B/ μs & 3.73 & 0.219 & 0.158 \\ \hline \end{tabular}
\end{table} 
Table 2: Cycle count for 3 cases: No-Encryption, ASCON, AES-GCM. Figure 7: Throughput and cycle per byte ratio of each algorithm. ### Static and Dynamic Memory Footprint

Examining and evaluating the memory utilization of embedded programs is crucial, particularly in devices with limited memory capacity. In this section, we delve into the analysis of both static and dynamic memory usage within our proposed solution. During our assessment, we explored three different implementation scenarios as mentioned in Section 4.1. The memory map in embedded programming is divided into sections. The flash memory part includes the _.roddata_, which contains the data variables, and the _.text_section, which contains the code resulting from compiling and building the source program [24]. This section contains static codes and requires a fixed memory size. In contrast, the RAM section of the memory is responsible for containing a few sections for statically generated codes, and the majority of it is used for dynamic memory management, such as stack and heap allocation as illustrated in Figure 8.

In our analysis of the dynamic memory usage, we focused only on the RAM section. However, when assessing the static memory usage (code size), we examined both the RAM and Flash sections. This approach was necessary as both sections contribute to the overall code size. #### 4.3.1 Static Memory Usage--Code Size

The static code size measurement was conducted to compare the code size requirements of three different implementation scenarios: No-Encryption, ASCON, and AES-GCM. The goal was to assess the impact of these implementations on resource-constrained devices in terms of memory usage. Table 3 provides a summary of the code size measurements for each scenario. In the No-Encryption scenario, no additional code was required beyond the base program, resulting in minimal memory usage. Our implementation based on ASCON introduced a slight increase in code size. Approximately 1 KB of additional memory was needed in both RAM and Flash compared with the No-Encryption scenario. On the other hand, AES-GCM demonstrated slightly higher code size requirements. The implementation demanded approximately 8 KB more RAM and 5.6 KB more Flash memory compared with the No-Encryption case. The results are illustrated in Figure 9.

Figure 8: Memory map of embedded programming [25]. The static code size measurement was conducted to compare the code size requirements of three different implementation scenarios. The objective was to assess the impact of these implementations on resource-constrained devices in terms of memory usage. Table 4 provides a summary of the code size measurements for each scenario. In the No-Encrypption scenario, no additional code was required beyond the base program, resulting in minimal memory usage. Our implementation based on ASCON introduced a slight increase in code size. Approximately 1 KB of additional memory was needed in both RAM and Flash compared with the No-Encrypption scenario. On the other hand, AES-GCM demonstrated slightly higher code size requirements. The implementation demanded approximately 8 KB more RAM and 5.6 KB more Flash memory compared with the No-Encrypption case

#### 4.3.2 Dynamic RAM Usage

Measuring the dynamic RAM usage of each algorithm is challenging compared with measuring static memory usage. This challenge arises from the need to monitor the dynamic memory allocations and deallocations on both the heap and stack, occurring throughout function calls and returns. While an effective technique suggested by NIST involves overwriting memory with known values before program execution and subsequently tracking the memory cells