## 6 Methodology
### Evaluation Metrics  
The evaluation of the proposed solution focuses on key metrics that reflect its efficiency and applicability. Initially, two key aspects are evaluated: the memory footprint,  
\begin{table}
\begin{tabular}{l l l} \hline \hline
**Claim Name** & **Details** & **Possible Values** \\ \hline \multirow{3}{*}{measurement\_description} & Describes the type of hash & \multirow{3}{*}{“SHA256”, “SHA512”, etc.} \\  & algorithm used for the & \\  & measurement & \\ \hline \multirow{3}{*}{measurement\_value} & Computed hash value of the & \multirow{3}{*}{Any valid byte array} \\  & software component & \\ \hline \multirow{3}{*}{signer\_id} & Hash of the public key used to & \multirow{3}{*}{Any valid byte array} \\  & verify the software component. & \\ \hline \multirow{3}{*}{sw\_component\_type} & Specifies the type of the & \multirow{3}{*}{“NSPE” (ML application)} \\  & software component being & \\ \cline{1-1}  & described & \\ \hline \multirow{3}{*}{sw\_component\_version} & Version of the software & Any valid version string (e.g., \\ \cline{1-1}  & component & \multicolumn{1}{c}{“1.0.”, “1.1.0”)} \\ \hline \hline \end{tabular}
\end{table}
Table 3: Software component details for PSA token.  
representing the resource demands of the implementation, and the secure boot time, critical for ensuring secure system initialization. These foundational metrics provide a basis for evaluating the feasibility and suitability of the solution on the experimental platform.  
Further, other metrics can be derived from the following use cases:  
1. A cloud-based service, acting as a relying party, wants to verify the device's trustworthiness and obtain high-level details about the ML model, such as vendor, version, accuracy, and the latest update. It is not interested in the detailed specifics of the model itself.
2. A federated learning system queries a device that has just joined the collaborative network for the weights it has trained. In this scenario, the system needs to verify both the trustworthiness of the device and the model architecture. Depending on the security requirements of the model, the token claims can either be encrypted or unencrypted. Additionally, the system may either recognize standardized ML claims (integer-encoded) related to the model architecture or rely on string-encoded claims that align with the structure of the ML framework.  
The inference time of an ML model depends on its complexity, as demonstrated by the MLPerf Benchmark [42]. For instance, a basic image classification task might require around 700 ms for inference. In contrast, anomaly detection tasks using the same AE architecture employed in this study, running on an STM NUCLEO-L4R5 ZI, take only a few milliseconds, typically ranging from 15 to 20 ms.  
Attestation time is crucial in systems that perform inference at the edge, as it should be minimal to ensure quick decision-making and maintain real-time performance. Any significant delay in attestation could negatively impact the system's responsiveness and overall efficiency.  
We evaluate how the model architecture impacts the ML-EAT token size and the attestation time. We define the attestation time as the time it takes for the device to generate the attestation tokens, without including the timing impact of the nonce encryption as described in Figure 3. Further, we compare how important is to have standardized ML claim labels for the model architecture and how this impacts the token generation time.