## 7 Results
### Attestation Time  
The inference time of a ML model refers to the time it takes to process input data and generate predictions, and it must be maintained within application-specific limits to ensure timely decision-making. However, if the ML model attestation process is resource-intensive, it may compete with the inference time, potentially leading to delays in decision-making. We evaluate the attestation time of the dual attestation method, specifically the time elapsed from when the prover receives the challenge until the device generates the two linked attestation tokens for the verifier. This evaluation focuses solely on the time it takes for the device to generate the tokens and does not include the reply protection checks, as illustrated in Figure 3.  
One of the claims in the ML-EAT token is the model hash (see Table 2), which represents the hash of the TFLite flatbuffer array, flavored with a nonce. This hash is computed on the device to ensure that the model has not been modified or tampered with during runtime. This is critical in an attestation system, where the verifier needs to confirm that a specific model is being executed on the device. In a federated learning scenario, the device-computed hash ensures that the updated weights sent to the server are identical to those at the time of attestation. Nevertheless, if model weights are not updated at runtime, the hash value of the TFLite flatbuffer array can be stored in the ITS area during the provisioning stage. The hash of the model is computed at runtime over the entire TFLite flatbuffer array, which includes weights, layer configurations, and metadata. Extracting just the weights requires parsing the entire flatbuffer, which not only causes a performance bottleneck on resource-constrained devices but also requires integrating a parser, increasing the memory footprint. Figure 8 illustrates the attestation time for each model, with the hash computation time included as part of the overall token generation time. This is shown to highlight the additional overhead introduced by the hash process in relation to the token generation. The attestation time includes the creation of the PSA attestation token, the hashing of the ML model, and the generation of the ML-EAT token. The creation of the PSA token, which is independent of the specific model being executed, takes approximately 15.2 ms. The hash chain, which links the two tokens, requires around 1.8 ms.  
Figure 7: ML-EAT token size based on the number of encoder layers for the evaluated AE architecture. The variation in token generation time based on the encoding type of the claim keys is primarily attributed to the AES-CBC-128 encryption time. When the ML-EAT token uses integer-encoded claim keys for the model architecture, the average difference in time generation is approximately 8 ms, resulting in an average improvement of 9.4%. Quantized models consistently demonstrate faster hash times across all sizes and also reduce token generation times. On average, quantized models show a 31.17% improvement in hash times compared to non-quantized models. Additionally, the average improvement in token generation times for quantized models is approximately 14.66%. In addition to the hash time of the model, the token generation time is influenced by the model architecture. The ML-EAT token includes the encoded model architecture, stored as subclaims, which is produced by the model framework and encoded in CBOR. An increase in the number of layers expands the model subclaim section, resulting in longer ML-EAT hash times and additional time for encrypting the model subclaims. The attestation time for different numbers of encoder layers in the AE model is shown in Figure 9. The plot excludes the model hash overhead and focuses solely on the impact of encryption on the model size, depending on the encoding type of the claim keys. We evaluated how the attestation time differs between the ML-EAT token containing model subclaims as plain data versus encrypted data.