## 7 Results
### Attestation Token Size  
The size of the attestation tokens is a key factor, as larger tokens require more computational resources and take longer to process. In non-hardware-accelerated cryptographic implementations, increasing token size leads to higher power consumption and longer execution times. Additionally, for IoT devices, the time required to transmit the data over \begin{table}
\begin{tabular}{l l c c} \hline \hline  & **SW Component** & **Flash [kB]** & **SRAM [kB]** \\ \hline
**Secure Environment** & Secure Manager & 360 & 140 \\  & NS/S Area & - & 16 \\ \hline
**Non-secure Environment** & Application Components & 358.2 & 4.7 \\  & Model AE-32 & 198.27 & 7.48 \\  & Model AE-32-quantized & 57.6 & 6.46 \\  & Model AE-64 & 438.9 & 7.61 \\  & Model AE-64-quantized & 120 & 6.49 \\  & Model AE-128 & 1067.64 & 7.87 \\  & Model AE-128-quantized & 257.72 & 6.63 \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Component memory usage for secure and non-secure environments. ML model size for quantized and non-quantized models. \begin{table}
\begin{tabular}{l c c} \hline \hline
**Component** & **Image Size (kB)** & **Boot Time (ms)** \\ \hline Application + AE-32 & 556.47 & 50.82 \\ Application + AE-32-quantized & 415.8 & 51.25 \\ Application + AE-64 & 797.1 & 52.63 \\ Application + AE-64-quantized & 478.2 & 51.25 \\ Application + AE-128 & 1425.84 & 53.06 \\ Application + AE-128-quantized & 615.92 & 51.69 \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Boot times for different image sizes based on the application and model configurations. the air grows with the size of the token, as larger payloads take more time to send. This extended transmission time directly affects the device's energy consumption, particularly in battery-powered IoT devices [45]. The PSA initial attestation token, generated by the SM, has a total size of 547 bytes. It consists of a 10-byte COSE header and a 68-byte COSE signature. The token contains integer-encoded claim keys that are part of the standardized format. The size of the ML-EAT token is sum of the general claims, which are constant regardless of the model architecture, and the submodule claims that define the model architecture. The general claim keys can be integer-encoded using private-usage IANA registry keys. For this implementation, the base address for the first claim is set to \(-\)70,000, with each subsequent claim having a decremented value from this base. The total size of the general claims is 537 bytes. The subclaims regarding model architecture depend on the ML framework used to create the model and should follow a standardized format to ensure compatibility with the framework and model-saving APIs. For example, Keras provides the get_config() function, which returns a JSON-serializable dictionary representing the model architecture. Similarly, TensorFlow offers model.to_json(), and PyTorch uses torch.save() to export the model architecture in a consistent format. Table 6 shows the CBOR encoding sizes of commonly used Keras layers compatible with TFLite, for both string-encoded and integer-encoded claim keys. For integer-encoded keys, the base value used is \(-\)75,000, with subsequent keys decremented accordingly. These sizes are determined by saving each layer's configuration in a JSON format, serializing it to CBOR, and then measuring the memory footprint. The serialized sizes are compared to evaluate the impact of different encoding schemes on model memory usage. For the evaluated AE architecture, the ML-EAT token size is 9468 bytes when using string-encoded claim keys. Since each encoded layer includes a Dense layer followed by a BatchNormalization and Activation layers, the size is nearly halved to 4218 bytes when integer-encoded claim keys are used, excluding the input and output layers. This reduction in token size significantly enhances transmission efficiency in IoT applications, leading to reduced transmissions times and lower energy consumption.