# Building Trust in Data for IoT Systems ††thanks: This work has been
developed within the MASTERMINE project (European Mining in the Green and
Digital Era, https://www.mastermine-project.eu/), funded by the European Union
under the Horizon Europe framework programme [GA 101091895].

Davide Margaria, Alberto Carelli, Andrea Vesco LINKS Foundation -
Cybersecurity Research Group - Torino 10138, Italy

###### Abstract

Nowadays, Internet of Things platforms are being deployed in a wide range of
application domains. Some of these include use cases with security
requirements, where the data generated by an IoT node is the basis for making
safety-critical or liability-critical decisions at system level. The challenge
is to develop a solution for data exchange while proving and verifying the
authenticity of the data from end-to-end. In line with this objective, this
paper proposes a novel solution with the proper protocols to provide Trust in
Data, making use of two Roots of Trust that are the IOTA Distributed Ledger
Technology and the Trusted Platform Module. The paper presents the design of
the proposed solution and discusses the key design aspects and relevant trade-
offs. The paper concludes with a Proof-of-Concept implementation and an
experimental evaluation to confirm its feasibility and to assess the
achievable performance.

###### Index Terms:

Internet of Things, Distributed Ledger Technology, IOTA Tangle, Trusted
Computing, Remote Attestation.

##  I Introduction

Internet of Things (IoT) nodes are now being deployed in a plethora of
different connected systems and are moving towards an ecosystem phase. Attacks
based on malicious data ingestion, data manipulation, eavesdropping on
contextual information indicative or derived from IoT data represent a serious
problem especially in specific scenarios like autonomous cars in cooperative
intelligent transport systems [1] and critical infrastructures [2],
potentially resulting in catastrophic incidents. In these scenarios, safety-
critical or liability-critical decisions are made on the basis of data
generated or collected by IoT nodes, hence the need for Trust in Data [3, 4,
5]. In this context, there are already some examples of solutions that take
advantage of Distributed Ledger Technology (DLT) [6] to preserve the integrity
of the data stored in the distributed ledger against potential malicious
manipulation [7, 8, 9, 10, 11, 12]. In addition, the communication between the
IoT nodes and the DLT gateway node is often protected by the Transport Layer
Security (TLS) protocol [13]. It must be noted that the security properties
provided by the DLT (i.e. immutability, hence integrity of the data stored)
and secure communications (i.e. authentication, data integrity and
confidentiality in transit) are not enough to take critical decisions on data
generated by IoT nodes. The combination of the two solutions basically
provides cryptographic protection of the data transmission from the source to
the final destination, but they do not consider the software (SW) integrity of
the originating IoT node [14, 2]. If the SW stack of the IoT node is
compromised, the data can be manipulated at the origin before being
transmitted over the secure channel and therefore cannot be fully trusted.

Aiming to solve the problem highlighted above, this paper proposes a novel
solution to ensure the trust in data, effectively providing end-to-end
protection of the entire chain from data generation to final data consumption
for decision-making. The proposed solution, called Trusted Data over the
Tangle (TDT), is based on two Root of Trust (RoT):

  1. 1.

the IOTA Tangle as the RoT for data [15],

  2. 2.

the Trusted Platform Module (TPM) as the RoT for SW integrity measures and
reporting [16, 17].

Excluding constraint IoT, today IoT nodes in connected systems can easily be
equipped with a TPM, e.g. Infineon OPTIGA™ TPM SLI 9670 board for Raspberry
Pi® 4 [18]. Hence, this paper assumes that each critical IoT node in the
system is equipped with a hardware TPM enabling the verification of SW
integrity of the data source, while the IOTA Tangle ensures data immutability
for near real-time and non-real-time data consumption.

The contribution of this paper is threefold: (_i_) proposes the TDT concept
and design for IoT connected systems that need to produce, exchange and
consume trusted data to enable critical decision-making, (_ii_) defines the
protocols ruling the interactions between the involved agents and highlights
the relevant trade-offs, and (_iii_) presents a Proof-of-Concept (PoC)
implementation and reports promising experimental results that confirm the
feasibility of the TDT solution.

##  II Related Works

###  II-A Existing Approaches to Provide Trust in IoT Data

Several scientific papers have proposed solutions to evaluate and enhance the
trustworthiness of IoT data, based on different assumptions and theoretical
foundations [3, 4, 5, 6, 7, 8, 9, 10, 11, 12].

Guo et al. [3] introduce the Lightweight Verifiable Trust based Data
Collection (LVT-DC), an approach for sensor to cloud systems. The work
considers a scenario with many IoT nodes in a smart city and a set of mobile
vehicles that collect data from those nodes and report data to the cloud to
enable different applications. The LVT-DC solution evaluates the
trustworthiness of the mobile vehicles, based on direct trust computation and
trust inference computation. The LVT-DC solution considers the IoT node
trustworthy by design and focuses on estimating the reliability of unknown
data collectors. Instead, no IoT node is considered a priori trusted in our
work, where the TDT solution takes advantage of a TPM to verify the integrity
of the entire SW stack of each IoT node and its configuration, according to
Trusted Computing (TC) principles [17].

Ren et al. [4] propose the Privacy-protected Intelligent Crowdsourcing scheme
based on Reinforcement Learning (PICRL). This solution assesses the
trustworthiness of unknown data sources and aims to optimise the utility of
crowdsourcing applications by simultaneously considering the data amount, data
quality, and cost. Notably, the trustworthiness calculation of IoT nodes is
probabilistic due to the inherent characteristics of the system. Instead, our
work performs a deterministic evaluation of the trustworthiness of the IoT
nodes by assessing their SW integrity with TC techniques.

Mo et al. [5] present the Active and Verifiable Trust Evaluation (AVTE), an
approach to enhance the reliability of edge computing applications, whose
decisions are based on data forwarded by sensing devices that are self-
organised in IoT networks. The AVTE solution evaluates the credibility of IoT
nodes as trustworthy forwarding nodes, to ensure reliable and low cost data
collection for edge computing. Again, this approach does not assess the SW
integrity of IoT nodes, nor does it cover attacks aimed at compromising the
data sources. Moreover, the solutions in [3, 4, 5] do not use a TPM and/or
DLTs, which are the key building blocks of our work.

Concerning the DLT-based solutions [6], the recent scientific literature
includes relevant examples of DLT adoption in different categories of IoT
systems [7, 8, 9, 10, 11, 12].

Among the others, it is worth to mention the works of Alam et al. [7], Alajlan
et al. [8], and Bikos et al. [9], that present comprehensive literature
surveys of DLT-based solutions suitable for IoT systems, with detailed
analyses of current trends, cybersecurity requirements, vulnerabilities,
future challenges and possible areas for improvement.

Bikos et al. [9] highlight the IOTA Tangle as a promising distributed ledger
capable of addressing both the security and performance challenges of
traditional IoT applications.

Montanaro et al. [10] analyse the benefits and the performance of the
simultaneous use of an off-chain database, to store actual IoT data, and a
DLT, to guarantee the immutability of such data and other relevant properties.

Khelifi et al. [11] present a reputation-based blockchain mechanism tailored
to a vehicular network scenario and suitable to a Named Data Networking (NDN)
architecture. This solution secures the in-network caching and enforces the
trust between cache stores and consumer vehicles by assigning each cache store
a reputation value, that is increased/decreased based on the served content.

Wang et al. [12] propose a mutual authentication and a key agreement protocol
that takes advantage of a DLT to verify the IoT data sources and ensure data
integrity in a smart grid with edge computing scenario.

All the works in [7, 8, 9, 10, 11, 12] take advantage of DLTs to ensure the
integrity of IoT data stored. However, they do not consider the SW integrity
of the IoT nodes that actually generate the data. This is the main shortcoming
of the existing solutions.

With this work, we are exploring the feasibility and benefits of combining the
use of DLT and hardware TPM to build trust in data, thereby enhancing the
security and reliability of IoT-connected systems.

###  II-B Enabling Building Blocks for the Proposed Solution

The proposed TDT solution takes advantage of the following building blocks:

  * •

IOTA Tangle [15], a DLT designed primarily for use in IoT environments and
suitable for anchoring data while taking advantage of its data immutability
feature;

  * •

Wrapped Authenticated Messages (WAM) [19], a novel open-source cryptographic
protocol for structuring data on the IOTA Tangle and facilitating their
consumption in near real-time and non-real-time;

  * •

_Trusted Platform Module_ [16], a tamper-resistant cryptographic hardware at
the core of TC principles [17] on top of which TDT builds its own SW integrity
architecture;

  * •

_Remote Attestation_ (RA) protocol [20, 21] to challenge and verify the SW
integrity of IoT nodes at run-time.

The IOTA Tangle [15] is a permissionless public DLT available for anchoring
data in a feeless manner. WAM is an open-source application level protocol
[19] to structure a stream of data on the IOTA Tangle. To the best of our
knowledge, WAM is the only open-source implementation in C language available
for IoT nodes. It organises data into concatenated messages that form a
unidirectional logical channel on the IOTA Tangle. Optionally, WAM provides
the function to encrypt/decrypt data. The logical channel allows any node in
the system to subscribe to a WAM channel of another node and retrieve the data
in near real-time or rapidly retrieve the full chain of data (or a portion of
it) in non-real-time, while verifying the authenticity of the retrieved data.
The WAM protocol signs each message and provides the functionality to verify
the authenticity of each message at the subscriber end, removing this
complexity from the applications. Moreover, the WAM protocol ensures the
channel ownership property. Only the owner of a WAM channel can publish data
on it, while any malicious attempt by an adversary to take control of the
channel or to insert false data can be easily detected by any node subscribed
to it during the verification of the data retrieved [19].

At this point of the paper, it should be agreed that the TLS protocol protects
the data in transit from the IoT node to the IOTA Tangle, the WAM protocol
ensures the authenticity of the data published by the IoT node in its WAM
channel stored in the IOTA Tangle, and the IOTA Tangle ensures the integrity
of the data thanks to its immutability feature (i.e. authenticity, integrity
and _optionally_ confidentiality are provided from end-to-end). The remaining
security gap is the possibility for an adversary to tamper with the SW stack
of the IoT node and modify the data at source. For this reason, TDT adds SW
integrity verification using a hardware TPM and a Remote Attestation protocol.

The SW integrity architecture is depicted in Fig. 1. The IoT node implementing
the TC principles on top of a hardware TPM [16] is called Attester. The
identification of the SW components running on the Attester and the
verification of their integrity is performed by means of a hierarchy of trust
rooted into a trust anchor (i.e. typically a small portion of code into the
processor executed at the very beginning of the boot process). The
architecture implies different trust decisions to decide whether the Attester
can be considered trusted or not. Such decisions can be taken by the Attester
itself during the bootstrap (e.g. before running the bootloader and before
running the OS Kernel) to build the so-called secure bootstrap. Moreover, the
decision can also be taken by a Verifier running the RA protocol [20, 21]. The
RA is a challenge/response protocol in which the Verifier is able to determine
the trustworthiness level of the Attester against a list of golden values
(i.e. the hash values of the software components running on the Attester). The
adoption of a RA protocol enables periodical verification of the Attester
integrity at run-time, so it adds security to the sole verification at boot
time. With reference to Fig. 1, the first two trust decisions are typically
made by the processor based on the signature of the bootloader and of the OS
Kernel. Upon full loading of the OS, the third periodical decisions are made
by the Verifier through remote attestation. These decisions are made based on
(_i_) the values of the Platform Configuration Registers (PCRs) inside the
hardware TPM that accumulate the digest of the SW components running on the
Attester, and (_ii_) on the values of the Integrity Measurement Architecture
(IMA) Measurement Log (ML) [22]. For more details on these aspects, interested
readers can also refer to [17, 16].

Figure 1: Software integrity architecture.

The RA protocol is addressed in standards and specifications, for instance the
Trusted Attestation Protocol (TAP) Information Model defined by the Trusted
Computing Group (TCG) [20] and the Remote ATtestation procedureS (RATS)
architecture by the Internet Engineering Task Force (IETF) [21]. Moreover,
several RA solutions have already been proposed and implemented in different
application domains and use cases, for instance critical infrastructures [2],
Industry 4.0 [14], or time distribution networks [23].

##  III Trusted Data over the Tangle (TDT)

###  III-A General Principles and Agents

The proposed TDT solution, depicted in Fig. 2, involves the following agents:

Figure 2: Agent involved and their roles.

Verifier ($V$)

– a specialised agent in charge of enforcing the trustworthiness level of IoT
nodes (i.e. Attester) in the system. It verifies the digital identity and the
SW integrity of the nodes by means of a RA protocol. The Verifier generates,
signs, and sends back an Attestation Report (AR) to the IoT nodes.

Attester ($A$)

– any IoT node in the system that generates data that other IoT nodes in the
system consume. It is equipped with a hardware TPM and it initiates the RA
protocol by contacting the Verifier asking for an AR. Upon receiving a valid
AR, the Attester starts writing the data into its WAM channel, inserting with
a configurable periodicity a fresh AR in the stream. To preserve the
confidentiality of the data, the Attester can optionally encrypt them. For
instance, the Attester can take advantage of Authenticated Encryption with
Associated Data (AEAD) through a specific security layer of WAM protocol [19].

Relying Party ($RP$)

– any IoT node in the system that consumes the data of an Attester through the
Tangle. After subscription to the selected WAM channel, the Relying Party
performs the appropriate verification (i.e. on the identity and SW integrity
of the Attester) before trusting and consuming the data. Note that the Relying
Party carries out an _a posteriori_ check on the AR and data.

Tangle

– is the RoT for the data generated by the Attesters in the IoT system.

For the sake of simplicity but without losing generality, Fig. 2 shows a
single agent for each role. In principle, it is possible to generalise this
basic scheme to more complex use cases, based on multiple Verifiers,
Attesters, and/or Relying Parties. Moreover, an IoT node can play both the
role of Attester and Relying Party.

It must be noted that the proposed system is compliant with the RATS
architecture defined in the RFC 9334 [21]. In detail, the Verifier, Attester,
and Relying Party agents in Fig. 2 correspond to the roles formally defined in
[21]. Moreover, the data flows are consistent with the topological pattern
named as Passport Model in [21], due to its resemblance to how a national
authority issues a passport to a citizen and how an immigration desk checks
that passport. In this analogy, the Attester corresponds to a citizen that
conveys a passport application and identifying information (i.e. an evidence)
to a passport-issuing agency, that is the Verifier. The Verifier compares the
evidence against its appraisal policy and, if the evidence passes the
appraisal policy, the Verifier gives back a passport (i.e. AR). The Attester
treats the passport as opaque data and appropriately stores it. The Attester
can now present (i.e. write on its WAM channel on the Tangle) the passport
(i.e. AR) and possibly additional claims (i.e. data) to an airport immigration
desk (i.e. Relying Party). The immigration desk then compares this information
against its own appraisal policy to make an authorisation decision (i.e. to
consume or discard the AR and data).

###  III-B Assumptions and Notation

The TDT description assumes the use of any public-key signature scheme
supported by the TPM (e.g. RSA, ECDSA, ECDAA) [24].

A proper provisioning phase is assumed for all the IoT nodes in the system.
This phase is carried out before deployment of IoT nodes on the field and it
consists of the typical initial configuration procedure in a secure
environment. It includes the generation of a database of golden values, that
consists in the computation of the digests for all the relevant SW components
on the IoT node that will be verified during the RA protocol, and the
execution of a proper key generation procedure. In detail, the Verifier,
Attester, and Relying Party execute a key generation algorithm to initialise
the asymmetric key pairs associated to their identities, according to the
selected signature scheme.

Aiming to unambiguously identify the owner of each public key ($p_{k}$) and
private key ($s_{k}$), the next sections adopt the following notation:

  * •

the Verifier key pair $(p^{V}_{k},s^{V}_{k})$;

  * •

the Attester key pair $(p^{A}_{k},s^{A}_{k})$;

  * •

the Relying Party key pair $(p^{RP}_{k},s^{RP}_{k})$.

It is worth highlighting that the TPM in the Attester node generates the key
pair $(p^{A}_{k},s^{A}_{k})$ according to an appropriate key hierarchy. Such
asymmetric key pair is conventionally denoted as the _Attestation Key_ (AK)
[17, 16]. It is a non-migratable key pair, since its private part $s^{A}_{k}$
will never leave the TPM, while $p^{A}_{k}$ is publicly available. In
principle, the AK is used to sign and verify the TPM Quote during the RA
protocol and the WAM messages generated by the Attester, ensuring a hardware-
rooted authenticity. The TPM Quote consists in the signed list of PCR values
stored in the TPM. The AK is protected by means of the so-called _Endorsement
Key_ (EK), that corresponds to another non-migratable asymmetric key pair,
derived from a seed statistically unique for the TPM. The EK is certified by
the TPM manufacturer and represents the root of the chain of trust for any AK.
The provisioning phase terminates with the distribution and the secure
installation of all the public key certificates in all agents of the TDT
system.

###  III-C The Protocols

The TDT solution comprises two protocols that take place between different
agents at different times: (i) the RA protocol, between $A$ and $V$, and (ii)
the Data Exchange protocol, between $A$ and a $RP$ through the Tangle, as
shown in Fig. 3 and Fig. 4, respectively.

Figure 3: The Remote Attestation protocol.

Figure 4: The Data Exchange protocol.

The RA protocol is tailored to the agents involved and conforms to the
specification in the TCG Trusted Attestation Protocol (TAP) information model
[20]. The first interactions (Steps 0–4) include the provisioning phase
discussed in Section III-B, the attestation request from $A$ to $V$, the
generation of the nonce (i.e. a random challenge to counteract replay attacks)
by $V$, and the generation of the TPM Quote and ML to be sent to $V$. Then,
$V$ checks the integrity of $A$ (Step 5) using the received Quote and the ML.
Specifically, $V$ checks the signature on the TPM Quote with $p^{A}_{k}$, then
reconstructs the PCR10 using the measures in the ML and compares it to the
actual PCR10 value in the Quote. Finally, $V$ checks the measures in the ML
against the golden values in a whitelist. If any of these checks fail, $V$
terminates the communication with $A$ without generating the Attestation
Report (AR). Otherwise, $V$ generates and signs the AR using its private key
$s^{V}_{k}$ (Step 6). Finally, $V$ sends the AR to $A$ (Step 7) and $A$ checks
the authenticity of the AR using $p^{V}_{k}$ (Step 8).

The AR includes at least the current Timestamp $T_{i}$ and the public key
$p^{A}_{k}$, to ensure a binding between the AR and the identity of $A$.
However, different options can be considered for the content of the AR and for
the periodicity of the RA protocol, as discussed in Section III-D.

Once $A$ has received an AR, the Data Exchange protocol takes place as in Fig.
4. In detail, $A$ writes the AR into the WAM channel (Step 9) and, then,
starts generating (Step 10) and writing data with a valid timestamp $T_{j}$
into the WAM channel (Step 11). By periodically repeating these last three
steps and the RA protocol, $A$ can actually write a continuous data stream
into a WAM channel over the Tangle, consisting of a periodic succession of AR
and data with proper timestamps as depicted in Fig. 5. The $RP$ can request
access to the data from $A$ (Step 12) at any time. $A$ provides an entry point
within the WAM channel to $RP$ (Step 13), and $RP$ uses it to directly
retrieve the messages from the WAM channel of $A$ (Step 14). At this point,
before trusting and consuming the data, $RP$ checks (Step 15) the authenticity
of the AR, the consistency of $p_{k}^{A}$ and the timestamps in ARs. In
detail, $RP$ checks the signature on the AR using $p^{V}_{k}$ and that the
public key into the AR is the expected $p_{k}^{A}$, the same public key passed
to the WAM protocol to check ownership and authenticity of the messages.
Moreover, $RP$ verifies the consistency of the timestamps in data and ARs with
the issuing time of the corresponding data transaction on the Tangle.

Figure 5: Realisation of the writing process on a WAM channel.

###  III-D Discussion on Key Design Aspects

The agents can periodically repeat the protocols in Fig. 3 and Fig. 4. $A$ can
periodically request a new AR from $V$ and write it into the WAM channel by
executing a new iteration of the RA protocol. $A$ can generate and write fresh
data into the WAM channel. These two processes are independent and $A$ can
asynchronously execute them as shown in Fig. 5. At any time, $RP$ can request
and obtain access to the resulting stream of data interspersed with ARs.

Different design choices result in a trade-off between security and
performance of the system. In this sense, the paper identifies and briefly
discusses here the main design aspects and some potential options to be
considered.

AR verbosity – The AR can contain:

  * •

a synthetic report on the SW integrity of $A$, the public key $p^{A}_{k}$, the
Timestamp $T_{i}$, and the signature computed by $V$ with $s^{V}_{k}$;

  * •

a verbose report that, in addition to the contents of the synthetic report,
includes the full ML sent by $A$ to $V$ during the remote attestation.

The first option is preferable in near real-time use cases. The second option
may be appropriate when $RP$ needs to verify the type and version of the
software running at $A$. An incremental ML that contains only the new measures
can be used for performance reasons. The latter requires storing the golden
values at the $RP$ during the provisioning phase.

Periodicity for checkpoints – The RA protocol shown in Fig. 3 and the
subsequent writing of a new AR to the WAM channel can be repeated with a
constant or variable time interval. Depending on the use case, a constant time
interval can be appropriate if there is a known periodicity and a predefined
size for the data, while a variable interval is suitable when $A$
asynchronously generates data, possibly with a variable size that is not known
a priori (e.g. 1 AR every 10 data messages or every 100 kB of data).

Relying Party logic for trust – Assuming that a $RP$ considers as trusted only
the data between two valid ARs generated within a predefined threshold $TH$,
the logic for the retrieval and consumption of the data can differ for non-
real-time and near real-time use cases, depending on their requirements.

In a non-real-time case, $RP$ is interested in obtaining access to the full or
at least a portion of the data stream, without strict latency constraints.
Starting from an entry point on the WAM channel, which should correspond to a
past AR, the $RP$ can check that the elapsed time to the next AR at is less
than $TH$. Then, the $RP$ consumes all the data between these two ARs. The
same process is repeated for the subsequent ARs and data.

In a near-real-time case, the entry point on the WAM channel can be at an
arbitrary time instant that probably does not coincide with an AR. $RP$ can
discard the retrieved data until the first valid AR becomes available; after
that, $RP$ has two options for the logic of trust:

  * •

$RP$ stores the following data in a buffer until the second AR becomes
available. If and only if the two ARs are valid and the time elapsed between
them does not exceed $TH$, $RP$ consumes the buffered data;

  * •

$RP$ retrieves and directly consumes the data without buffering. If a new AR
does not become available by the expiration of $TH$, the $RP$ must reconsider
the trustworthiness of the consumed data.

The first option can be considered more secure than the second logic that, on
the other hand, seems more efficient. In fact, the second one may reduce the
latency between the writing of data by $A$ and its consumption by $RP$.
Depending on the preferred option, $RP$ continues to process the subsequent
stream of data interspersed with ARs.

##  IV Experimental Results

###  IV-A Proof-of-Concept Implementation and Configuration

The hardware infrastructure for the PoC includes:

  * •

Raspberry Pi® 4 (RPi4) Model B [25] (1.5 GHz CPU, 4 GB RAM, Raspberry Pi OS,
Linux 5.15.79-v7l+ kernel);

  * •

Infineon OPTIGA™ TPM SLI 9670 [18], a board with TPM2.0 chip connected as
expansion hat on RPi4 and configured to use the ECC NIST P256 curve [24, 18];

  * •

mid-range server (1.8 GHz CPU, 24 GB RAM, 1 TB SSD, Ubuntu 22.04 LTS, Linux
5.19.0-50 kernel);

  * •

IOTA node [26] synchronised with the IOTA distributed ledger deployed and
operated in our lab.

The analyses consider the RPi4 with the TPM as the main device under test for
both Attester and Relying Party roles. Furthermore, the server is used as the
Verifier of the IoT system, and the IOTA node is leveraged as the gateway
toward the IOTA network to write and read data. The PoC takes advantage of the
RA protocol and WAM protocol implementations, both developed in C language by
our research group.

###  IV-B Remote Attestation Protocol

An initial experimental analysis is carried out to investigate the expected
performance of the RA protocol depicted in Fig. 3, focusing on the operations
with the largest computational complexity.

For these initial tests, the server is configured as the Verifier and two
RPi4s are deployed, one as the Attester and one as the Relying Party. The
initial provisioning phase (Step 0) mainly consists in the generation of a
full database of golden values for all the relevant files on the devices under
test in a protected environment. This phase is executed on the RPi4s and it is
typically done only once for each device, thus its complexity will be excluded
from the performance assessment.

The size of the ML (i.e. IMA log) can be considered as a key parameter, since
it is expected to have a remarkable impact on the execution time of the main
operations for the RA procedure (Steps 1–5). The following analyses consider a
ML size of $132$ kB, that corresponds to approximately 900 entries on the IMA
log. This value has been measured on the PoC just after a reboot and it is
representative of the typical length of an IMA log on a RPi4. The experimental
test consists in the execution of multiple independent repetitions (i.e. 500
trials) of the main RA operations (Steps 1–5) to assess the achievable
performance. The Verifier measures the execution time for each trial by means
of three intermediate timers:

Timer1

– measuring the elapsed time from the reception of an attestation request from
the Attester (Step 1) up to the complete reception of the Quote and ML (Step
4);

Timer2

– estimating the execution time for the verification of the Quote received
from Attester (first part of Step 5);

Timer3

– assessing the time to verify the ML against golden values and whitelist
databases, plus the time to reconstruct and verify the PCR10 (second part of
Step 5).

It is possible to compute the total RA latency as the sum of these three
timers. The Steps 6–8 mainly consist in a signature generation for the AR and
its verification and, thus, they are excluded due to the limited impact on the
overall performance.

TABLE I: Statistical analysis of the execution time for RA operations. Statistics |  Timer1 (s) |  Timer2 (s) |  Timer3 (s) |  Total (s)
---|---|---|---|---
max | 0.459 | 0.023 | 0.075 | 0.494
avg | 0.404 | 0.009 | 0.035 | 0.447
min | 0.358 | 0.005 | 0.021 | 0.392
std | 0.015 | 0.003 | 0.010 | 0.018
Figure 6: Empirical CDF of the execution time for RA operations.

Table I presents a statistical analysis on the experimental results, including
the maximum (max), average (avg), minimum (min), and standard deviation (std)
values estimated for the three timers and for the total RA time. The same
results are also depicted in Fig. 6, that presents the empirical Cumulative
Distribution Function (CDF) computed on the three intermediate timers and on
the total RA time. The results in Table I and Fig. 6 demonstrate that the
Timer1, with an average of 0.404 s, represents the largest contribution to the
total RA time (i.e. approx. 90% of its average, that is 0.447 s). In fact, the
Timer1 mainly assesses specific operations (i.e. Quote generation, at Step 3,
and transmission of the Quote and ML to the Verifier, at Step 4) that are
executed on the RPi4 equipped with TPM. On the other hand, Timer2 and Timer3
correspond to computations done by the Verifier (Step 5). An additional
investigation on the specific operations measured by Timer1 allows noticing
that the Quote generation on the TPM is the operation with the largest
contribution to Timer1, showing an average execution time of 0.361 s. It
corresponds to approx. 89% of the average value of Timer1 and to approx. 81%
of the total RA time. This value is justified by the fact that the Quote
generation is securely executed by the TPM.

These results confirm the feasibility of the proposed RA protocol in Fig. 3.
In fact, the measured total RA time is always below 0.5 s (i.e. average equal
to 0.447 s and maximum value of 0.494 s).

It is also worth to point out that the selected PoC configuration corresponds
to an approximate ML size of $132$ kB. In principle, better performance (i.e.
lower total RA time) can be achieved by adopting a hybrid solution, where the
RPi4 periodically sends a differential ML instead of transmitting the full ML.

As an additional remark, the Timer2 is expected to have an execution time that
is almost constant varying the ML size, since the assessed operation (i.e.
Quote verification) does not depend on the ML size, while both the Timer1 and
Timer3 are significantly affected by the ML size.

Figure 7: Empirical CDF of the writing time (top) and estimated average
writing time and goodput (bottom) over the Tangle.

Figure 8: Empirical CDF of the reading time (top) and estimated average
reading time and goodput (bottom) over the Tangle.

###  IV-C Data Exchange Protocol

Another experimental analysis is carried out to investigate the performance of
the protocol in Fig. 4, especially focusing on time-consuming operations on
the Tangle through the WAM protocol. In detail, it is possible to identify the
following operations as the ones with the highest expected execution time: the
Steps 9 and 11, that concern the writing of specific data (i.e. AR and data,
respectively) into the WAM channel on the Tangle, and the Step 14, that
consists in retrieving such data from the WAM channel. In fact, the remaining
operations in Fig. 4 mainly consist in data generation, timestamping, and
signature verification, with a negligible impact on the overall complexity of
the workflow and, thus, they are excluded from the following discussion.

In these tests, one RPi4 is connected to the IOTA gateway node and it emulates
the periodic writing of AR and data into a WAM channel on the Tangle; it
generates random data with a size from 1 byte up to 4 kilobytes. Another RPi4
retrieves the data from the WAM channel. Such write and read operations are
repeated for each selected data size and for 500 trials. The RPi4 nodes
measure the execution time of the operations and these values are analysed to
estimate the empirical CDF and the average execution times. Moreover, the
analysis also includes an estimation of the Goodput $G$, that represents the
number of useful information bits delivered by the network to a certain
destination per unit of time. It corresponds to the data throughput neglecting
any packet overhead and can be computed as $G=D/T$, where $D$ is the
considered payload data size and $T$ is the average execution time of the
write or read operations.

Fig. 7 and Fig. 8 present the results for writing and reading data through the
WAM channel on the Tangle, respectively. In detail, Fig. 7 (top) shows the
empirical CDF of the writing time for the considered data sizes. It can be
appreciated that the CDFs are clustered in three groups, with different but
consistent statistics in each group. This behaviour is also noticeable in Fig.
7 (bottom), that shows the estimated average writing time and the goodput
versus the data size. Each group shows an almost constant average writing
time, with the first group corresponding to the data sizes from 1 B to 200 B
(and writing times from 8.3 s to 9.6 s), the second group from 300 B to 1 kB
(and writing times from 24.3 s to 27.4 s), and the third group from 1.5 kB to
4 kB (and writing times from 76.4 s to 79.4 s). This behaviour is well
explained considering that the complexity of the Proof-of-Work that the IOTA
gateway node must perform for each data transaction depends on the data size
[26].

The staircase pattern of the average writing time in Fig. 7 (bottom) directly
translates into a saw-tooth pattern for the goodput. In fact, if the data size
increases inside one of the groups, the almost constant average writing time
implies a growing goodput. It can be noticed that specific use cases,
requiring to maximise the goodput, can be interested in finding a locally
optimal value for the data size according to this pattern (e.g. a WAM message
payload of 1 kB results in $G=39.4$ B/s, while 1.5 kB would imply $G=19.6$
B/s).

A similar analysis is also done for the reading time and the results are
reported in Fig. 8. In this case, the measured values result in a similar
empirical CDF for all data sizes considered, as shown in Fig. 8 (top). Thus,
Fig. 8 (bottom) presents an almost constant average reading time, with small
magnitudes (from 3.8 ms to 9.4 ms). These values result in an increasing trend
for the goodput, achieving the remarkable value of $G=798.67$ kB/s for a data
size of 4 kB.

These results confirm the feasibility of the proposed protocol in Fig. 4. As
expected, the achievable performance is limited for writing data to the
Tangle, with average goodput values in the range of few tens of bytes per
second, while several hundreds of kilobytes per second are achievable for
reading data from the Tangle, depending on the size of each data packet. In
this sense, it seems inadvisable to periodically write a verbose AR (including
the full ML) to the Tangle, unless strictly necessary, whereas it may be
appropriate to use a synthetic AR.

Moreover, if the use case requires a low latency for the delivery of data from
the Attester to the Relying Party, a small packet size (e.g. less than 200 B)
is preferable to minimise the writing time (e.g. less than 10 s). On the other
hand, if the goodput must be maximised, large packet sizes (e.g. from 1 kB to
4 kB) may the preferred option (e.g. to achieve up to $G=51.2$ B/s for writing
and up to $G=798.67$ kB/s for reading data).

##  V Conclusions and Future Work

This paper has proposed TDT as a novel solution for providing the Trust in
Data for IoT connected systems with stringent security requirements. The PoC
implementation and the experimental results have confirmed the feasibility of
the proposed solution and have showed promising performance for its main
building blocks. Future work will focus on prototyping the TDT solution,
tailoring its design parameters to real use case requirements, and extending
the performance analysis to microcontroller-based devices.

## References

  * [1] M. A. Amanullah, S. W. Loke, M. Baruwal Chhetri, and R. Doss, “A taxonomy and analysis of misbehaviour detection in cooperative intelligent transport systems: A systematic review,” _ACM Computing Surveys_ , vol. 56, no. 1, August 2023.
  * [2] S. Sisinni, D. Margaria, I. Pedone, A. Lioy, and A. Vesco, “Integrity verification of distributed nodes in critical infrastructures,” _Sensors_ , vol. 22, no. 18, 2022.
  * [3] J. Guo, H. Wang, W. Liu, G. Huang, J. Gui, and S. Zhang, “A lightweight verifiable trust based data collection approach for sensor–cloud systems,” _Journal of Systems Architecture_ , vol. 119, p. 102219, 2021.
  * [4] Y. Ren, W. Liu, A. Liu, T. Wang, and A. Li, “A privacy-protected intelligent crowdsourcing application of IoT based on the reinforcement learning,” _Future Generation Computer Systems_ , vol. 127, pp. 56–69, 2022.
  * [5] W. Mo, T. Wang, S. Zhang, and J. Zhang, “An active and verifiable trust evaluation approach for edge computing,” _Journal of Cloud Computing_ , vol. 9, no. 1, p. 51, Sep 2020.
  * [6] N. Kannengießer, S. Lins, T. Dehling, and A. Sunyaev, “Trade-offs between distributed ledger technology characteristics,” _ACM Computing Surveys_ , vol. 53, no. 2, pp. 1–37, May 2020.
  * [7] T. Alam, “Blockchain-based internet of things: Review, current trends, applications, and future challenges,” _Computers_ , vol. 12, no. 1, 2023\.
  * [8] R. Alajlan, N. Alhumam, and M. Frikha, “Cybersecurity for blockchain-based IoT systems: A review,” _Applied Sciences_ , vol. 13, no. 13, 2023.
  * [9] A. N. Bikos and S. A. P. Kumar, “Securing digital ledger technologies-enabled IoT devices: Taxonomy, challenges, and solutions,” _IEEE Access_ , vol. 10, pp. 46 238–46 254, 2022.
  * [10] T. Montanaro, I. Sergi, A. Quarta, E. Manrique, N. Bedoya, D. L. de Ipiña, G. de Artaza, and L. Patrono, “The combined use of IoT and blockchain in logistics: a comparative experiment,” in _International Conference on Smart and Sustainable Technologies_ , 2023, pp. 1–6.
  * [11] H. Khelifi, S. Luo, B. Nour, H. Moungla, and S. Hassan Ahmed, “Reputation-based blockchain for secure NDN caching in vehicular networks,” in _IEEE Conference on Standards for Communications and Networking_ , 2018, pp. 1–6.
  * [12] J. Wang, L. Wu, K.-K. R. Choo, and D. He, “Blockchain-based anonymous authentication with key management for smart grid edge computing infrastructure,” _IEEE Transactions on Industrial Informatics_ , vol. 16, no. 3, pp. 1984–1992, 2020.
  * [13] E. Rescorla, “The transport layer security (TLS) protocol,” Version 1.3, RFC 8446, August 2018. [Online]. Available: https://www.rfc-editor.org/info/rfc8446
  * [14] D. Margaria and A. Vesco, “Trusted GNSS-based time synchronization for industry 4.0 applications,” _Applied Sciences_ , vol. 11, no. 18, 2021.
  * [15] S. Popov, “The Tangle,” Version 1.4.3, April 2018. [Online]. Available: https://assets.ctfassets.net/r1dr6vzfxhev/2t4uxvsIqk0EUau6g2sw0g/45eae33637ca92f85dd9f4a3a218e1ec/iota1_4_3.pdf
  * [16] TCG, “Trusted platform module library specification,” November 2019. [Online]. Available: https://trustedcomputinggroup.org/resource/tpm-library-specification/
  * [17] W. Arthur, D. Challener, and K. Goldman, _A Practical Guide to TPM 2.0 – Using the Trusted Platform Module in the New Age of Security_. Apress Berkeley, CA, 2015.
  * [18] Infineon Technologies AG, “OPTIGA™ TPM Application Note. Integration of an OPTIGA™ TPM SLx 9670 TPM2.0 with SPI Interface in a Raspberry Pi® 4 Linux environment,” July 2019. [Online]. Available: https://www.infineon.com/
  * [19] LINKS Foundation, “Wrapped Authenticated Messages – Library to interface with IOTA Tangle based on the Chrysalis protocol,” 2023. [Online]. Available: https://github.com/Cybersecurity-LINKS/WAM
  * [20] TCG, “TCG trusted attestation protocol (TAP) information model for TPM families 1.2 and 2.0 and DICE family 1.0,” September 2019. [Online]. Available: https://trustedcomputinggroup.org/wp-content/uploads/TNC_TAP_Information_Model_v1.00_r0.36-FINAL.pdf
  * [21] H. Birkholz, D. Thaler, M. Richardson, N. Smith, and W. Pan, “Remote ATtestation procedureS (RATS) Architecture,” RFC 9334, January 2023. [Online]. Available: https://www.rfc-editor.org/info/rfc9334
  * [22] R. Sailer, X. Zhang, T. Jaeger, and L. van Doorn, “Design and Implementation of a TCG-based Integrity Measurement Architecture,” in _USENIX Security Symposium_ , San Diego, CA, August 2004.
  * [23] D. G. Berbecaru, S. Sisinni, A. Lioy, B. Rat, D. Margaria, and A. Vesco, “Mitigating software integrity attacks with trusted computing in a time distribution network,” _IEEE Access_ , vol. 11, pp. 50 510–50 527, 2023\.
  * [24] TCG, “TCG algorithm registry,” Family 2.0, Level 00, Revision 01.33, March 2023. [Online]. Available: https://trustedcomputinggroup.org/wp-content/uploads/TCG-Algorithm-Registry_R1.33_Pub.pdf
  * [25] Raspberry Pi® Trading Ltd, “Raspberry Pi® 4 Computer Model B, Product brief,” January 2021. [Online]. Available: https://datasheets.raspberrypi.org/rpi4/raspberry-pi-4-product-brief.pdf
  * [26] IOTA Foundation, “HORNET: IOTA fullnode software,” 2023. [Online]. Available: https://github.com/iotaledger/hornet