# Enhancing Resilience in Digital Twins: ASCON-Based Security Solutions for Industry 4.0
## 3 Proposed Solution
### Ditto Java Base Payload Mapping
### Measurement Case Scenarios

To assess the performance of our proposed solution, we designed three case scenarios. For each scenario, we conducted analyses at both the algorithmic (function call) level and examined the broader application overhead. _Case 1: AES-GCM_: In this case, we assessed the performance of the AES-GCM encryption algorithm in terms of power consumption, memory usage, and processing speed. We analyze both its standalone performance as a function and its implementation within the application

Figure 5: Ditto and web app for simulating Digital Twin. Case 2: ASCON: In this case, we measured the performance of the ASCON encryption algorithm both at the functional level and its impact on the implementation of the proposed solution

Case 3: No encryption: This case scenario served as a baseline reference for the other two cases. In this case, we called a function that had a similar signature to the encryption function calls used for ASCON and AES-GCM. However, the underlying function did not perform any operations other than copying values from one memory location to another ([[https://libsodium.gitbook.io/doc/](https://libsodium.gitbook.io/doc/)]([https://libsodium.gitbook.io/doc/](https://libsodium.gitbook.io/doc/)) (accessed on 27 May 2023)) illustrated in Listing 3:

The implementation code for this case can be seen in the following code list. ```
intcrypto_aead_encrypt( unsignedchar*c,unsignedlonglong*clen, constunsignedchar*m,unsignedlonglongmlen, constunsignedchar*ad,unsignedlonglongadlen, constunsignedchar*nsec, constunsignedchar*npub, constunsignedchar*k { *len=mlen+CRYTO_ABYTES; memcpy(c,m,mlen); memset(c+mlen,0,CRYTO_ABYTES); return0; }
```

```
intcrypto_aead_decrypt( unsignedchar*m,unsignedlonglong*mlen, unsignedchar*nsec, constunsignedchar*c,unsignedlonglongclen, constunsignedchar*ad,unsignedlonglongadlen, constunsignedchar*npub, constunsignedchar*k } { unsignedlonglonglonglen=*mlen=clen-CRYTO_ABYTES; memcpy(m,c,len); return0; }
```

### Performance Measurement--Speed, Memory, and Power

The performance of a particular category of encryption algorithms is influenced by the algorithm's complexity, defined by factors such as the number of processing rounds and required CPU instructions. It is essential to recognize that there exists a trade-off between security and performance. More intricate algorithms generally offer higher security levels but demand greater computational resources and execution time. Therefore, designers and practitioners must meticulously assess the acceptable performance and the minimum required security level for a specific application before selecting encryption algorithms. This section aims to provide insights into the performance of our proposed solution, which relies on two algorithms, AES and ASCON, both utilizing a 128-bit key size. Our primary focus centers on measuring their processing speed, memory consumption, and power utilization. Additionally, we introduce a nonencrypted implementation to serve as a benchmark for comparative analysis. #### 4.2.1 Speed--Running Time

To measure the execution time of the algorithms, we used the built-in function esp_timer_get_time() from the ESP-IDF framework. By capturing the start time before executing the function and the end time after the function completes, we can calculate the execution time by subtracting the start time from the end time. Our experimental setup involves three distinct case scenarios. Firstly, we measure the execution time when the application runs without any encryption algorithm. Then, we measure the execution time when the messages are encrypted using ASCON and AES algorithms. Note that we measure the performance of the proposed solution from two perspectives: (1) from the time required to run the encryption algorithm within the application program and (2) from the perspective of measuring the total time required to process the message and send it to the Digital Twin (Cloud). Both case scenarios are shown in figure 5(a),b.