AI-Powered Security for IoT: A Blockchain Enabled Device Twin Approach

Abstract

Application domains in embedded systems such as Industrial Internet of Things (IIoTs) involve smart, mobile, and interconnected devices that operate in large numbers (devices swarms). These devices process and exchange safety, privacy, and mission-critical information. Thus, message exchanges, task collaborations, and service deliveries necessitate the communicating devices to trust each other. In this regard, it is essential to have a suitable device verification technique that scales to device swarms and establishes trust among collaborating devices. However, state-of-the-art device swarm attestation schemes assume a single external verifier and do not offer resiliency. In addition, in a swarm of self-organizing IoT networks, each member device independently changes its position (i.e., continuously entering and leaving the network). Thus, it becomes very challenging for the trusted external verifier to track these mobile devices, which further exacerbates the problem of authentication, identification, and management of swarm members. We present a novel AI-powered self-healing decentralized attestation that distributes attestation among devices for systems that work in swarms. Decentralization decreases delay and overcomes the problem of a single point of failure. To ensure swarm security, interoperability, and management, we use a reusable digital identity for each physical system (IoT node), allowing authentication and authorization of access. Each device is leveraged with an ML model, where verifications are carried out on its device twin, that is, the digital representations of the attestable properties of the member device. After each attestation, our system quickly extracts information about swarm members and establishes a chained relationship (chains of trusted blocks) with one another. This chain comprises devices with benign software configurations. We evaluate performance and demonstrate if the execution overhead is negligible. We also analyze security and show that the proposed technique is very effective and robust against various attacks.

1. Introduction

Embedded devices are used in the ever-growing network of Cyber–Physical Systems (CPS) and Industrial Internet of Things (IIoTs). These networked systems are applied in the military, industries, business, medical field, retail, transportation, home automation, and other safety and security-critical applications. Devices in IoTs and CPS can operate in swarms and are connected to each other [1]. They are large clusters of devices working together to perform some task. Their key characteristics are that they are smart, mobile, and interconnected and operate in large numbers. They generate, process, and exchange a vast amount of mission-critical data as well as privacy-sensitive information and thus become targets of various attack.

Recently, a number of high-profile threats and attacks targeting IoTs have been reported in literature. Attackers pose a significant amount of threats to IoTs either by injecting malware [2, 3, 4, 5] or through observing properties (i.e., execution time, memory usage patterns, task schedule, power consumption, etc.) of the software running [6] on the underlying device. Such attacks could affect the integrity of the software running on the device as well as the underlying system’s firmware or can be used to reveal the running application’s secrets. Devices under attack could stop working, behave differently, or be leveraged to pose distributed denial-of-service (DDoS) attacks.

Thus, it is necessary to have a good code verification technique that scales to device swarms and establishes trust among collaborating devices. Such trust decisions are carried out through remote attestation.

1.1 Remote attestation in embedded devices

Remote attestation in embedded devices is a process where a target system (i.e., prover) makes a claim about its internal state by supplying reliable evidence to a verifier (trusted party). The verifier will then decide whether the target system’s attestation information is within its acceptable state.

Based on the technology they rely on, current attestation techniques can be divided into three groups: hardware-based, software-based, and hybrid. In light of protecting the prover’s report from being forged by an adversary, some techniques use secure hardware [7, 8], while others are based on trusted software [9, 10]. Secure hardware is too costly and complex for low-end embedded devices. On the other hand, trusted software relies on strong adversarial and algorithm optimality assumptions, which are very difficult to achieve in reality [11].

The hybrid (software/hardware co-design) attestation techniques use minimal hardware support as mentioned in [12, 13]. Defrawy et al. in SMART [13] present secure attestation with minimal hardware changes in memory controller unit (MCU). In SMART, each device embeds an immutable code and key realized by storing them in read-only memory (ROM). SMART additionally utilizes MCU to provide access control to memory region to only the secure code, thus guarantying privacy and security of its contents. TrustLite [12], a follow-up work on SMART, generalizes this idea to introduce Execution Aware Memory Access Control (EA- MAC). TyTAN [14] extends TrustLite’s approach with dynamic configuration of access control rules, albeit it incurs additional architectural complexity. However, all of them require additional hardware to ensure the atomicity of the execution of attestation code as well as to store attestation related keys.

1.2 State-of-the-art swarm attestation

Existing swarm attestation techniques [15, 16] assume one external entity (operator or central verifier) controls the whole attestation process. The central verifier generates attestation requests and propagates the same to swarm members. After that, it receives cumulative member devices’ attestation report. Both approaches need minimal trusted components—called trust anchors (i.e., read-only verification code, secure key storage, and atomicity of execution of verification code), as provided by SMART [13], TrustLite [12], and TyTAN [14] architectures.

On the other hand, both approaches rely on one external verifier, which is generally assumed as trusted while the provers (swarm members) are not. However, verifier impersonation, denial-of-service (DoS) and replay attacks are possible [17] under the reverse setting, where the verifier is malicious while prover is genuine. Besides, they lack resiliency as a single device/node failure that makes their cumulative attestation report to be 0 (attestation fails). In addition to that, communication between the system and central verifier is only through the initiator node, and an attack on the same could disrupt the whole attestation process (i.e., single point of failure). The other issue is that the overall attestation time is very huge in a swarm of many devices. Consequently, swarm topology must remain the same for this huge amount of time (i.e., the duration of one attestation session). Moreover, the status of member devices remains unknown until the cumulative report reaches the external verifier.

Brasser et al. [18] proposed ARM TrustZone-based approach in which the operations of smart personal guest devices are analyzed (through attestation) and regulated as per usage policies set by a host device. This work aims at prohibiting ARM-based personal computing devices such as phones, tablets, and smart glasses from being used to exfiltrate unauthorized secure information from sensitive environments. ARM TrustZone partitions processing environments into two as normal and secure worlds These two environments have their own address spaces and different privileges. The secure world can access the code and data in the normal world while its processing is immune from anything in the normal world. Attestations in this architecture are carried out by taking integrity measurements in the secure world while normal applications are executing in the normal world.

Ambrosin et al. in their recent work, called PADS: Practical Attestation for Highly Dynamic Swarm Topologies [19], have designed a collective attestation scheme for IoT swarms that work under dynamic topologies. To efficiently collect attestation proofs, devices in PADS attest themselves and share reports among each other through a minimum consensus algorithm [20]. This cumulative value describes the state of the whole network. The consensus in PADS, nevertheless, poses a high communication overhead (i.e., O(N), where N is the number of devices in the swarm). In addition to that, the network dynamics also creates security issues as nodes may enter or leave the swarm while attestation is going on.

SeED [21], on the other hand, came up with a noninteractive attestation approach, where the prover device (through its hardware features) carries out software measurements and provides a timely response. This technique is resilient to DoS attacks as the prover device has no incoming traffic for the attestation protocol. Moreover, SeED is implemented on slightly modified versions of SMART [13] and TrustLite [12] security architectures. However, SeED’s network relies on a central verifier, which introduces a single point of failure. Besides, it assumes a static swarm topology.

Recently, researchers have proposed a decentralized approach toward IoT swarm attestation [22, 23, 24, 25]. Such an approach distributes the central verifier’s responsibility to swarm members so that attestations are carried out in a more efficient manner. In DADS [22], for example, attestation starts from a given device in the swarm (i.e., attestation initiator device), and the attestation operation propagates in such a way that each device in the swarm is attested and then appointed to securely verify its neighbors. This means that previously verified nodes can run the attestation protocol in parallel. This approach is very efficient and robust against a single point of failure in IoT swarms where smart, mobile, and interconnected devices operate in large numbers. However, DADS’s nodes do not hold topology information of the swarm. Hence, graph restructuring, as well as system resilience, could disrupt if multiple neighboring nodes fail at the same time. Note that at any given point in time, swarm members in DADS only know the topology up to two hops. DADS is also based on state-of-the-art security architectures for embedded systems [12, 13].

1.3 Contributions

In order to address issues related to efficiency, security, and swarm resiliency, we design and evaluate a blockchain-enabled decentralized and re-configurable swarm attestation scheme in which verification is carried out by swarm members. This AI-powered approach assures complete system resilience to node compromise/failure. Besides, it decentralizes the central verifier’s duty to swarm members where each device in the swarm is attested and then appointed to securely verify others.

Our approach also takes into account additional practical features of IoT and CPS swarm devices, namely, device mobility, dynamic topology, and very large numbers. To summarize, the proposed scheme is:

• self-reliant:

  • External entity’s involvement is limited to initiating the first attestation session.

After that, swarm attestation is maintained by member devices.

• resilient upon node compromise/failure

• verifies both static and runtime attacks

• captures topology information in highly dynamic networks

Table 1 compares and summarizes basic features offered by various attestation schemes. Having a central verifier makes the system (i.e., the swarm) rely on this entity and creates a single point of failure. DADS [22], property-based attestation [23], and our new approach are immune from such a security issue. Decentralization also eases the swarm verification burden, reduces bandwidth requirement, and increases efficiency by distributing attestation responsibility to swarm members. When we consider swarm management, all schemes except DADS, property-based attestation and the proposed approach rely on the central verifier, which is essentially external to the swarm. Swarm members in DADS and property-based attestation inform the central verifier when there is a node compromise/failure. The new approach, in this regard, is self-reliant, where each member node holds a snapshot of the swarm.

	Device Mobility	Verifier Scheme	Attestation		Swarm Management	Topology Information at each Node	System Resilence (Robustness against node compromis e/failure)	Supported Topology
			Attestation Approach	Security against Single point of failure
SEDA [15]	No	Centralized	Static	No	Central Verifier	No	No	Static
LISA [16]	Partial	Centralized	Static	No	Central Verifier	No	No	Partial (Semi-dynamic)
SANA [26]	No	Centralized	Static	No	Central Verifier	No	No	Static
ARM TrustZone based [18] Attestation	No	Centralized	Static	No	Central Verifier	No	No	Static
PADS [19]	Yes	Distributed	Static	No	Central Verifier	No	No	Dynamic
SeED [21]	No	Centralized	Static	No	Central Verifier	No	No	Static
DADS [22]	Yes	Decentralized	Static	Yes	Partial	Partial	Partial	Dynamic
Property based [23] Attestation	Yes	Decentralized	Static and Runtime (Both)	Yes	Partial	Partial	Partial	Dynamic
This work	Yes	Decentralized	Static and Runtime (Both)	Yes	Self-reliant	Yes	Yes	Dynamic

Table 1.

Overview of features provided by various schemes (Swarm Attestation Perspective).

LISA supports partial mobility in which its nodes send their own reports as soon as they receive requests from parent nodes. After that, they serve their descendants only as a channel to propagate results toward the central verifier. DADS, property-based attestation and the new scheme, however, allow topology changes where member devices may connect or leave the swarm frequently. This is a practical feature of IoT swarm devices [27, 28, 29]. The remaining techniques, on the other hand, do not support mobility.

All approaches, except the property-based scheme [23], verify the static properties of the underlying program. In [23] meanwhile, attestation is carried out on the execution time properties.

Outline: The rest of the chapter is organized as follows. In Section 2, we detail the problem and describe the assumptions of our approach. Section 3 describes the proposed approach, while Section 4 details the underlying protocols. In Section 5, we present implementation and performance evaluation. We present security assessment in Section 6 and conclude the chapter in Section 7.

2. Problem definition, attack model, and assumptions

Attestation schemes for embedded systems can be either single prover [30] or swarm attestation [15, 16, 18, 19, 21, 22, 26]. In a single prover approach, the verifier attests each target device one at a time. Such an approach lacks the flexibility needed to deal with the mobility of swarm members and does not scale to systems that work in a group.

Existing swarm attestation techniques require additional hardware to ensure the atomicity of the execution of attestation code as well as to store attestation-related keys. On the other hand, trusted software relies on strong adversarial and algorithm optimality assumptions [11], which are very difficult to achieve in reality as well as orthogonal to real-time demands of IoTs. Recent studies [31, 32] have uncovered that embedded software is vulnerable to various exploits during runtime.

The goal of the proposed scheme is to design an efficient and self-reliant attestation technique that scales to device swarms and guarantees service/collaboration to be only in a link between two trusted devices; that is device A trusts device B and vice-versa where the link is an edge between A and B. Such a trust is established through remote attestation between devices A and B. It also deals with frequent topology changes caused by mobility of the swarm members (i.e., it holds snapshot of swarm topology). Furthermore, the digital twin of the underlying device is verified for its execution time properties by analyzing the real-time attestation data captured from its current state.

2.1 Attack model and assumptions

We focus on attacks that are executed solely through software, whether by remote or local adversaries. This means that the attacker, A, is unable to physically manipulate the devices in the swarm. A remote adversary’s goal is to infect the prover device from a distance by injecting malware. On the other hand, a local adversary positions itself close enough to the prover to eavesdrop and manipulate its communication channels [33]. This implies that aside from attempting to compromise a device in the swarm, an adversary can also carry out active and passive attacks on the messages being communicated.

The different attack vectors that an adversary could try are:

• compromising software configuration of a prover to disturb the normal operation of the underlying device,

• forge messages (attestation request and report) to/from a device,

• DoS on application, network, and lower layers of the communication channel alter the runtime behavior of the running code without changing its binary.

• infected devices (Botnets) could collude to create a DDoS attack.

A potential enemy (i.e., Adversary A) could send numerous requests that could overwhelm the device being targeted and deplete its resources.

It is assumed that each device within the swarm has the required hardware to store attestation-related code and take untampered measurements. Additionally, it is also assumed that the attestation code and subsequent protocol elements are securely stored in read-only memory (ROM) and or on dedicated flash memory.

Each device, D_i, holds:

• System parameters, p and q; that is, for shared key calculation, all devices in the swarm can have similar p and q values.

• Pair of signing keys (sK_i, pK_i)

• device identities idD₁, idD₂, idD₃, …, idD_n, where n implies the number of elements in the swarm

• Software configuration C_i: hash digest of software of D_i

These (device specific) values can be given to all swarm devices at manufacture or deployment time by the operator/owner of the network (O).

Each member of the swarm has an online presence that can be identified through its digital identity, also known as idD. This identifier is unique to each member and is shared among collaborating devices when joining the swarm.

It is assumed that the devices in the swarm are equipped with the required hardware as provided by ARM TrustZone [34], SMART [13], or TrustLite [12].

Along with the deployment time values, member devices also perform self-attestation periodically and record the traced runtime properties in a rewritable nonvolatile memory known as RAM. We follow the same strategy as DADS [22] to store such values that need occasional updating, such as session identifiers. These runtime properties make up the Device Twin, which represents the current status of the designated IoT device in real time. We will provide more details on this in Section 3.2.1.

3. The proposed approach

The concept of chain-of-trust is commonly used to validate software and hardware components. It involves one component trusting the next one toward the root, ensuring that only trustworthy components are used in the system. This approach is employed in the proposed scheme to create the Blockchain for swarm attestation.

The idea is that the main component, which is trusted by everyone, boots up and hands over control to the next unit after checking its integrity. The currently running component (which was verified by the root component in the previous step) confirms the next component’s validity before launching it. For instance, as depicted in Figure 1, the root of trust (component A) performs self-tests and code validation for itself. If these tests pass, it can proceed to validate component B, which then checks component C upon successful verification. This method ensures that every object (component) is verified by the preceding component, and the next one is measured in a way that establishes a trust relationship from the root to the end. Only a trusted component is authorized to execute and transfer the same to the next one.

Figure 1.

Chain of trust.

Our method involves creating a linked chain between members of a swarm based on their attestation results. This chain is composed of devices with secure software setups, as indicated in their attestation reports. Using this approach, we generate a trusted graph that enables nodes to recognize reliable swarm members and identify who will initiate the next attestation session. Devices utilize the trusted graph to determine which parties they can communicate with during their regular operations. The graph updates whenever a neighboring device submits a new attestation value containing information about a newly verified device.

In order to preserve the aforementioned feature and utilize the swarm nature of IoTs (where the devices often function as a group, are numerous in quantity, and are mobile in nature), our approach consists of the following stages (as depicted in Figure 2).

Figure 2.

Overview of the proposed approach.

First, devices should join the swarm and be part of the group. Here, the first device (the one that joins the group first) measures its integrity and makes the report available for submission. The report is then broadcasted to swarm members. This device is verified by O at system startup. This particular node is special in the sense that it starts swarm attestation from itself by executing self-verification. It is also called initiator (the root of trust). From this point forward, devices attest to each other and form a trusted chain. Devices in the chain will then generate a trusted graph comprising node IDs extracted from submitted reports. This graph restructures whenever nodes leave the group or new attestation reports arrive. New attestation session starts by a genuine device elected through leader election. We later see (in Section 4) how member devices select a session initiator. Whenever a new attestation session starts, devices remove information related to an old session by clearing obsolete data. In short, the phases can be summarized as follows: First phase is attestation, which is followed by trusted-chain formation. After that, we generate a trusted graph that essentially comprises trusted swarm members. For example, in Figure 2, trusted graph on D₅ is shown as a list = {D₅, D₄, D₃, D₂, D₁} comprising genuine nodes in a depth-first manner, where D₆ and D₇ are being attested by D₄ and D₂, respectively, while D₈ is joining the swarm. The list in the graph shrinks and expands based on attestation reports from member devices. Finally, a leader election is carried out to select an initiator for the next attestation session.

3.1 Blockchain-based verification

In a blockchain-based implementation, the initiator device begins the attestation process by verifying its own integrity. If the verification is successful, the initiator creates the very first block in the chain, which is called the genesis block (i.e., the root of trust in Figure 1). The block that is created after successful verification includes the attester’s identifier, the attestee’s identifier, the attestation digest that resulted from previous executions, a timestamp, and the verifier’s (attester’s) signature. Since there is no predecessor, the genesis block only points to itself. The initiator then proceeds to attest the second device in the group (swarm). If the verification is successful, it creates a new block and broadcasts it. This new block consists of the initiator’s ID as the attester, the newly verified device’s ID as the attestee, the cryptographic hash of the genesis block, the current time, and a signature on the entire data. In this way, each block references the previous one, forming a chain that points back to the genesis block. The generated trusted graph (TG) essentially consists of genuine devices with verified runtime properties. The TG is global data that is shared among devices in the swarm. With each new attestation instance, chained blocks from previous attestations are removed to reduce the burden on the devices.

3.2 Attestation

Remote attestation involves communication between a prover and verifier. The prover is responsible for providing a status report upon request from a trusted party (verifier) to ensure that it is operating according to the set standards. The verifier then assesses the attestation information provided to determine whether the target system is in an acceptable state. Once a successful attestation is achieved, control is handed over to the prover through a report that outlines a hierarchy of trust. This report includes the prover’s identifier, the verifier’s identifier, and a hash digest of previous attestations.

Table 2 shows the basic elements involved in a successful attestation.

Sender’s ID	identification of the Verifier/Attester
Recipient’s ID	identification of the newly verified device.
Prev. Att. Digest	hash of previous attestations
Ver. Signature	Attestation initiator’s signature (signature of root device, σ)
MACAB	message Authentication Code using common key KAB from device DA to device DB

Table 2.

Notation.

If device A, D_A is a verifier and device B, D_B is a prover (Figure 3), upon successful attestation on D_B, D_A creates a report (3) by making a hash on the following attestation fingerprint:

• Recipient’s ID (ID of D_B),

• Sender’s ID (ID of D_A), and

• Prev. Att. digest (MAC on previous attestation).

Figure 3.

Attestation through chain of trust.

D_A sends the resulted MAC_AB to D_B. If D_A is the initiator, it also computes signature on its own report and broadcasts to swarm members so that every member can easily trace who the initiator was. The digital signature (σ) computation is done once per attestation session. In this way, each report references the previous one, forming a chain of trust pointing to the first entity in the chain (root of trust) that is created by the session (attestation) initiator.

Note that as in [15, 18, 19, 21, 22], we use MAC as a Hash-based Message Authentication Code (HMAC) with Secure Hash Algorithm-1 (SHA-1) [35] and the signature scheme with Elliptic Curve Digital Signature Algorithm (ECDSA) [36]. In addition to that, we use the Diffie–Hellman key exchange algorithm [37] to create and exchange attestation key K_AB between devices D_A and D_B as part of the join process.

That is, D_A computes a signature on a certain message covering the public value. D_B proceeds in a similar way. Now, D_A and D_B exchange their values and perform similar computation on it. Computed value K will be the same and forms common attestation key, K_AB (Table 3).

DA	DB
mA ← q^skA mod p	mB ← q^skB mod p
σA ← sign(sKA; mA)	σB ← sign(sKB; mB)
↘	↙
KAB ← (mB)^skA mod p	KAB ← (mA)^skB mod p

Table 3.

Key exchange and common attestation key establishment.

3.2.1 The digital twin

ML-based runtime device property traces and state prediction. The proposed scheme carries out attestation as follows: Similar to [23], the prover runs the target program, identifies runtime properties, sends the resulting traces to the Machine Learning (ML) classifier, and creates an attestation report.

To train our ML classifier, we begin by gathering data through the execution of sample IoT applications [38, 39]. This involves generating and capturing the profile of the typical execution of these applications. The two real IoT applications are syringe pump [38] and soldering iron temperature controller applications [39]. A syringe pump system is designed to provide controlled access to fluids, especially in hospitals to dispense medicines. On the other hand, the soldering iron temperature controller is used to set soldering iron to the desired temperature and keep the same for a given duration. These two systems could also be integrated in such a way that it controls water flows based on feedback from temperature controllers and other sensors. Such a system can be used in other domains of IoT, such as in smart farming. These categories vary significantly in behavior and size.

ML-Classifier: Similar to [23], we use the k-nearest neighbors (a nonparametric supervised) algorithm, also referred to as KNN or k-NN, to make predictions to classify the data. This approach makes use of proximity to classify/predict how an individual data point is grouped.

This particular model has been proven to detect attacks with a minimal false-positive rate [40]. Additionally, it provides quick and accurate responses (predictions) [41], making it an ideal option for device attestation in IoT swarms. It is worth noting that we use a K value of 5, as this helps us accurately predict outcomes. Note that the number of optimal neighbors K = √N, where N is the total number of points in the training data set.

We employ the same approach as [23], where in the first phase, the prover utilizes input i to run application program P. During this stage, the prover traces every instruction of the target program to generate valid inputs for the measurement entity. To collect execution time properties (also known as behaviors), we adopt the instrumentation approach of C-FLAT [42]. We keep track of properties by adding every instruction to our Runtime Reference Table (RT) data structure.

This entails counting:

• instructions – the number of instructions executed;

• cycles – the number of CPU cycles;

• branchInstructions – the number of branch instructions retired;

• branchMisses – the number of branch instructions retired;

• cacheMisses – the number of branch instructions retired;

• cacheReferences – the number of hits in the last-level CPU cache (both loads and stores).

Note that these execution time properties, combined with the (device-specific) parameters assigned by O, make up the Device Twin. The details about device parameters are discussed in Section 2.1.

3.3 Decentralized swarm attestation

Figure 4 shows a sample swarm formed of five devices where node B is an initiator. B is now a golden node that we can control and initiate attestation from itself. As shown in the figure, node B starts attestation by verifying its attestable memory; it then submits the report and sends attestation request to its neighbors (i.e., to nodes A, C, and E). The request essentially has a nonce, N, to prevent replay attack between communicating devices, and session identifier sn, for identifying successive attestation instances. After checking their report, B computes a hash that forms a chain rooted from itself and sends the same to the honest nodes (suppose all of them are honest). At this point, all three child nodes are secure (trusted) and eligible to run attest. As depicted in the graph, C and E are neighbors of node D, which means they can send attestation requests to D.

Figure 4.

Decentralized chain of trust-based attestation and resulting trusted graph.

Suppose node C sends the request first. Then, it checks D’s integrity through the submitted report, computes a hash over the previous result, and sends the whole information to D. Upon arrival of a new report, member devices extract ID of the honest nodes and form a trusted graph. For example, after receiving a report from B, node A forms a list of trusted nodes L_A = {A, B} taking itself as root. B also sends information about C and E to verified nodes in its vicinity (remember that both C and E are checked by the same parent node, node B). Now, A gets informed about C and E through B. This means that A updates its trusted graph list in DFS as follows: L_A = {A, B, C, E}. A’s list becomes L_A = {A, B, C, D, E} when C finishes node D’s attestation and reveals its finding. Other members also update and restructure their list whenever they receive a new attestation report, or they know that some nodes are missing from the resulting topology.

Generally, in a swarm of many devices, every device in the swarm is eventually attested and then (if its software is in a genuine benign state) appointed to verify others. A trusted node (the verified one) checks each of its neighbors that is yet to be attested. This means that previously verified child nodes can run the attestation protocol in parallel, which is followed by trusted graph generation.

On the other hand, swarm attestations are carried out once in a while or at regularly occurring intervals. A new attestation session is initiated by a node selected through leader election among devices in the trusted graph. If the next leader is attacked and corrupted, the same is revealed in its report, and other trusted graph members would then choose another initiator in a similar fashion. Subsequent attestation sessions will have unique session ID, sn. When a new attestation session starts, obsolete attestation-related information as well as the corresponding graph generated from older reports are discarded. Besides, O can contact member devices at any point in time to know the status of the swarm.

If a node in the trusted graph is missing, neighboring devices broadcast an error message so that other nodes are aware of its absence. This can be done using a heartbeat-based absence detection technique as proposed by [43]. The devices will then remove that node from their list and restructure their graph (connectivity graph) again for resiliency. If a compromised node is found, then the verifier (node appointed for that particular attestation) removes that malicious node from its neighbor list. Hence, the compromised node is not included in the trusted graph, and the system continues working. In this way, swarm attestation is decentralized and maintained by swarm members. This assures system resiliency.

4. Protocol description

Table 4 provides an overview of the variables and parameters used in the protocol specification.

Entities
D1	Swarm attestation initiator (for a specific instance)
Di	Device i
Swarm parameters
s	Total number of devices in the swarm/sub-network
gi	Number of neighbors of Di
pi ≤ gi – 1	Number of children of Di in the attestation treea
Desi	Number of descendants of Di
Device parameters
(ski, pki)	Secret and public key pair of Di
cert (pki)	Identity certificate of Di (issued by $\mathcal{O}$)
cert (Ci)	Code certificate of Di (issued by $\mathcal{O}$)
Ki j	Shared attestation key between neighbor devices Di and Dj
ci	Hash digest of the binary code of Di
id Di	ID of Di
Pid Di	ID of parent device of Di
Protocol parameters
$c_i^{\prime }$	Hash digest of the latest platform configuration of Di
sn	Session identifier
N	Random nonce
$\mathcal{T}$	A boolean variable indicating attestation success/fail on Di
tGList[ ]	List of genuine devices forming a trusted graph in the network
σ	Digital signature
$H{c}_i^{\prime }$	MAO digest of Di
P Digesti	Hash digest from the parent of Di
CumDigesti	Cumulative attestation digest up to Di

Table 4.

Variables and parameters of the proposed protocol.

^a

Attestat ion tree is a spanning tree consists of devices that are yet to be attested.

4.1 Attestation

• Integrity verification

Device I, D_i waits for attestation-related message arrival. If an incoming message is attestation request (AttReq), D_i checks authenticity through VERMAC and computes a hash on the underlying task through H(Mem). Then, it prepares and sends out attestation report (AttRep) to the verifier (i.e., attestation request sender). If D_i receives a cumulative report (CumRep), it means that D_i is genuine and certified by the verifier. Now, D_i eligible to attest other swarm members by sending attestation requests. For each AttRep received from neighbor nodes, D_i checks if there is a software modification in them and hands over control through CumRep. In addition to that, D_i adds the attested devices’ IDs and updates its TG and informs other genuine members (attested swarm members) using Update message. On the other hand, if the message is Update, D_i checks the authenticity of the packet and regenerates its trusted graph by adding the ID of the newly attested device. Upon a new attestation session, swarm members elect one device to start the next session. This device is called an initiator, D_i. When D_i receives attestation initiate request (InitReq), it checks its software configuration and compares the resulting digest with the preinstalled hash value (c_i). If the two values are equal, D_i sets T ← 1, increments session sn, and computes σ over (T, sn, idD_i), where T indicates attestation success or failure and idD_i is initiator’s ID. D_i then broadcasts this value to inform swarm members that it is an attestation initiator. D_i also removes obsolete data upon new attestation instances (Section 4.1).

4.2 Clear

• removes obsolete attestation related information from device.

Clear is called on new attestation instances (through CumRep and InitReq messages) to remove older attestation results in the chain formation process. It also removes IDs from the old graph.

Algorithm 1: Clear

Input: Current Session (Cursn), Cumulative Report (CumRep), Swarm Attestation Initiate Request (InitReq).

Output: clears obsolete attestation reports.

1 if message is (CumRep or InitReq) and sn > Cursn, then

2   Remove old reports except signature of previous session initiator;

3   Remove old trusted graph tGList[];

4   Update tGList[] with the new device through TGraph_Gen;

5 else

6   break;

7 end

4.3 Trusted graph generation

• generating a graph of genuine nodes that can trust each other on a service

Extraction of node IDs from arrived reports (i.e., AttRep and Update messages) is carried out through Algorithm 2. After decomposing reports, it constructs a trusted graph by updating its list in DFS fashion.

Algorithm 2: TGraph_Gen

Input: trusted graph list (tGList), stack (S), Successful Attestation Report (AttRep), Update message (Update), Current Session (Cursn).

Output: creates restructured trusted graph TG.

1. 1 for each message AttRep or Update, arrived from neighbor device D_i,do

2  /* Decompose message and extract idD_j of newly attested device D_j */;

3  /* where message sender is D_i with ID idD_i */;

4  extract idD_j from message;

5  /*D_i and D_j have parent–child relationships, where D_i is the parent of D_j, and let S be a stack*/;

6  /*i.e., idD_i ==PidD_j */;

7  while tGList[] is not empty, do

8     pop identifier idD in DFS from the list into S; /*where idD is the ID of device D in the list*/;

9     if idD == idD_i, then

10         /* where idD_i is the ID of parent device D_i */;

11         push idD_j to tGList[];

12         push idD_i to tGList[];

13         break;

14     else

15          continue;

16     end

17  end

18  tGList[]←S, /* Push IDs from S to tGList[]*/;

19 end

4.4 Leader election

• selects next session initiator

Leader election helps to choose new attestation initiators. This algorithm executes periodically at certain attest interval time t. Member devices elect and agree on a node that is going to start the next session. This activity is carried out between devices in the trusted graph. Each device in the trusted graph (i.e., D_i ∈ TG) randomly chooses one device as the next attestation session initiator and shares that value with member devices. Other swarm members also carry out the same process, poll for a majority vote (i.e., identifying a device elected by the majority of devices), and identify the selected device. Hence, everybody reaches the same decision as to which device starts the next attestation session. Consequently, the elected device starts attestation by verifying itself, broadcasts its report, and sends a new attestation request to its neighbors through Attest.

Global data is shared between the member devices while attestations are carried out in parallel. Moreover, subsequent attestation instances can be created through devices selected using any consensus algorithms. For example, using a byzantine algorithm [44], we can apply a majority vote to reach consensus on who should start the next session as follows:

Suppose we have five nodes, that is, node A, B, C, D, and E, in a cluster.

/* each device chooses one device in the cluster */;

A sends v to B, C, D, E;

/* where v is A’s vote on who should start */ B sends x to A, C, D, E; /* here, v is B’s vote */

-

/* each node run majority to determine who gets majority vote*/ A ← majority (v,v,x,y,z) == v;

-

If the majority returns more than one value, then a vote will be made between them; the final decision is the majority vote from A, B, C, D, E, and as a result, consensus is achieved.

5. Implementation and performance evaluation

In this section, we discuss implementation details of our approach.

5.1 Implementation

We implement our protocol on any embedded architecture with minimal security as provided by TrustLite [12] and ARM TrustZone [34]. TrustLite enables execution of our attestation-related code isolated from the rest of the system. This isolated code chunks are called trustlets. TrustLite’s MPU (also called execution-aware memory protection unit: EA-MPU) ensures that data can be accessed only by code of trustlets that owns that data. TrustLite’s data access permissions depend on the currently executing code.

TrustZone is a hardware security extension that is present in devices with Cortex-based processor systems [45]. It partitions the processing environments into two distinct worlds—Normal and Secure. These two environments have their own address spaces and different privileges. While the Secure World can access the code and data present in the Normal World, its processing remains immune from anything that happens in the Normal World.

5.2 Performance evaluation

In this section, we evaluate our approach and discuss experimental results.

We began by testing the classifier’s accuracy for device attestation through the use of six features (see Section 3.2.1): the total number of instructions, cycles, branch instructions, branch misses, cache misses, and cache references for representative applications (i.e., the syringe pump and soldering iron temperature controller applications).

To fit the machine learning model, we typically use the commonly used train-test ratio of 80:20 to split our data set into training and testing sets [46]. This means that we use 80% of the observations for training and reserve the remaining 20% for testing. To test an embedded application, we considered the class label of a real device (where its device twin depicts the same) to be 1, and 0 for all others. In this regard, the classifier’s high verification rate, that is, 99.8% for the syringe pump and 99.7% for the soldering iron temperature controller, demonstrates its robustness and ability to avoid false positives.

5.2.1 Runtime performance

We implement our protocol on OP-TEE [41, 42], which is an ARM TrustZone-based open-source implementation of TEE (Trusted Execution Environment)

Single device experiments are carried out on OP-TEE [45, 47], which is an ARM TrustZone-based open-source implementation of TEE (Trusted Execution Environment). Further, communication has been secured with HMAC using SHA-1 [35] and signed with ECDSA [36] (see Section 3.2 above).

Figure 5 illustrates the runtime performance of our approach on a single device. The attestation overheads appear to be linear with their respective runtime (execution time) events due to the context switch.

Figure 5.

Single device attestation overhead.

Swarm Attestation: We use the swarm attestation approach from DADS [22] by having an initiator node (i.e., the root node) start swarm attestation, with member devices attesting to each other in a decentralized manner.

We use the OMNeT++ [48] simulation environment to evaluate the runtime cost of our approach on device swarms (connected devices) with chain, star, binary, 4-ary, 8-ary, and 12-ary tree topologies.

As observed in Figure 6a, the runtime cost on the syringe pump for star and chain topologies grows linearly. Star allows parallel attestation resulting in better performance but implies a general case with one common ancestor.

Figure 6.

Runtime performance of our approach on syringe pump IoT application for various topologies (a) Star and Chain topologies (b) Tree topologies.

In a swarm of many devices, a tree topology results in more realistic runtimes. Figure 6b depicts the logarithmic runtime for various tree topologies. Our approach performs better with more child nodes.

5.2.2 Computation cost

The dominant parts of the computation cost of our approach (on swarm members) are due to cryptographic operations, that is, creating/verifying digital signatures (σ) and creating/verifying the benign software configurations (MACs/VERMACs). Swarm attestation initiator device D₁, which is a root-of-trust device for the underlying attestation session, computes 1 digital signature that is to be broadcasted to swarm members and at most 2g₁ MACs, where g₁ is the number of D₁’s neighbors. D₁ also verifies at most g₁MACs (i.e., g₁ VERMCS). Every other device D_i verifies 1 digital signature, computes 1+ 2p_i, and verifies 2 + p_i MACs, where p_i ≤ g_i – 1 and g_i is the number of neighbors of D_i.

5.2.3 Communication cost

We implemented MAC as a Hash-based Message Authentication Code (HMAC) with Secure Hash Algorithm-1 (SHA-1) [35] and the signature scheme with Elliptic Curve Digital Signature Algorithm (ECDSA) [36], where l_mac = 20 and l_sign = 40 bytes. The lengths in bytes needed for other components of the new scheme are:

l_N = 20, l_sn = 8, c = c’ = H(Mem) = 20, signing and verification keys sk = pk = K = 20, device identifiers idD = PidD = 4, digital signatures (σ) = 40, MACs = 20, certificates cert (pk) and cert (c) = 20 + 40 = 60.

Broadcasted information from initiator node, D₁, comprises σ, cert(pk), cert(c), and sn, which is about 40 + 60 + 60 + 8 = 168 bytes. On the other hand, attestation requests are 48 bytes, while attestation reports are 20 bytes. Communication cost depends on the amount of data transferred between nodes, which basically relies on the number of neighbor nodes as well as their descendants (Des) with which they communicate. Consequently, maximum communication overhead for D₁ is sending 168 + 48 g₁ + 20 g₁ (i.e., 168 + 68 g₁) and receiving 20g₁ + ${\sum }_{i=1}^{g1}\left(20+4{\mathrm{z}}_{\mathrm{i}}\right)$ where g₁ is the number of neighbors of D₁ and z_i is number of descendants of D₁’s neighbor node_i (i.e., Des_i - 1). For every other D_i, communication cost is at most sending 48p_i + 20p_i + 20p_i + 4w_i (i.e., 88p_i + 4w_i) and receiving 168 + 20p_i + ${\sum }_{i=1}^{\mathit{pi}}\left(20+4{\mathrm{z}}_{\mathrm{i}}\right)$ bytes, where g_i is the number of neighbors of D_i in the network, z_i is Des_i - 1, w_i is Des_i, and p_i ≤ g_i – 1.

5.2.4 Memory requirements

Each D_i in the new scheme stores S device identifiers (idD₁, … idD_s), signing key pair (sK_i, pK_i), identity certificate cert(pK_i), code certificate cert(c_i), set of attestation keys K shared with its neighbors in the network, and one sn for the duration of each swarm attestation protocol instance. Hence, the storage overhead for every D_i is estimated as 4 s + 20g_i + 168 bytes of write-protected memory, which is O(s), where g_i is the number of D_i’s neighbors and s is the number of devices in the swarm (for smaller networks) or sub-network. Our approach consumes an insignificant amount of this memory, assuming that the maximum neighbor nodes of devices is approximately 12 while the total number of nodes in the swarm is 10,000. Furthermore, most industrial applications such as smart factories and IIoT networks usually have fewer number of neighbors [15].

5.2.5 Energy cost

Energy is essentially required to send/receive a message, to generate a random number, and to compute MAC/VERMAC and digital signatures (σ); let the energy required to send one byte be E_send, receive one byte E_recv, generate sn (i.e., 20 random bytes) E_prng, compute MAC/VERMAC E_mac, and sign E_sign.

Then, the estimated energy consumption of initiator, D₁, is:

$$\begin{array}{l}E{\left(D_1\right)}_{⪯}\left(168+69g_1\right)E_{\mathit{\text{send}}}+\left(20g_1+\sum _{i=1}^{g1}\left(20+4{\mathrm{z}}_{\mathrm{i}}\right)\right)E_{\mathit{\text{recv}}}+\left(3{\mathrm{g}}_1\right)E_{\mathit{mac}}\\ +\left({\mathrm{g}}_1\right)E_{\mathit{\text{prng}}}+E_{\mathit{sign}}\end{array}$$E1

On the other hand, the energy consumption of every other device D_i is:

$$\begin{array}{l}E{\left(D_i\right)}_{⪯}\left(88p_i+4w_i\right)E_{\mathit{\text{send}}}+\left(168+20p_i+\sum _{i=1}^{\mathit{pi}}\left(20+4{\mathrm{z}}_{\mathrm{i}}\right)\right)E_{\mathit{\text{recv}}}+\left(2+3p_i\right)E_{\mathit{mac}}\\ +\left(p_i\right)E_{\mathit{\text{prng}}}+E_{\mathit{sign}}\end{array}$$E2

where D_i is the initiator, g_i is the number of neighbors of D_i, z_i is Des_i − 1, w_i is Des_i, and p_i ≤ g_i − 1.

6. Security analysis

Recall that the proposed approach aims to allow secure detection through remote attestation and ensures a trusted graph (TG) is formed among genuine devices in a network, where their execution time properties reveal the same. This means that services/collaborations are to be only in a link between devices D_i and D_j, where D_i, D_j ∈ TG. Recall also that our adversarial model only considers remote and local adversaries (see Section 2.1), while physical attacks are out of scope.

We start with the case where adversary A modifies the software configuration of the target device P (also called prover). Code performing attestation measurement is in ROM and accessed through EA-MPU (see Section 5.1), and thus A cannot tamper with measurement code. This means that any modification on the running code is revealed on the measured value. What A could do to make any kind of change on the result and trick verifier V is to forge the hashed attestation result (i.e., AttRep_p). As A cannot tamper with code measurement entity in P, it must forge the hashed attestation result if it is going to deceive V. Given the preimage and collision resistance nature of MAC, we use MAC as HMAC; the probability that A forges AttRep_p (i.e., MAC(K_VP; N_p || sn || c’_p)) is negligible in l_mac. On the other hand, symmetric attestation key K_VP is stored in ROM and read only by attestation code (attestation measurement entity), which A cannot tamper with. Thus, it leaks no information regarding the key.

Other possible attacks include the case where A fakes attestation request AttReq and masquerades V to cause DoS on P. AttReq comprises two basic components, sn and N. A single session identifier sn is used by every member of the swarm for the duration of one attestation session. Obtaining one sn means A can repeatedly send requests by attaching it with possible nonce N value. However, this unique N value is provided by V to detect any possible replayed requests. In addition to that, both sn and N are authenticated via MAC (K_VP; N_p || sn). As the case in attestation report forgery, A should know the pair-wise attestation key K_VP or forge the hashed AttReq to cause any kind of modification. But neither case is feasible in light of key storage and MAC features discussed above.

The other possibility is that an A could deploy rootkit (or bootkit) attacks to gain constant administrator-level access to a device and/or network. A installs malware through exploiting the system’s vulnerabilities without the victim device’s consent and could modify the attestation code. It provides A with complete control over the device, subverts its security, and causes malicious functions to be executed. Such an attack could alter the way the attestation measurements are taken as well as modify the outcome. They make wrong decisions on attestation results and add devices to a network of bots (creates botnet). However, the execution of the attestation code Attest is isolated from the rest of the system (see Section 4.1), and data access permissions depend on the currently executing code (via its EA-MPU). Any change in the operating system does not reflect on the measurement entity’s functionality.

In the case of initiator’s broadcasted message, A must forge σ = sign (sk₁; sn || c’₁) to trick swarm members into accepting the report. However, given the selective forgery resistance of the signature scheme used (recall that we use ECDSA, Section 5.2.1), the probability that A forges σ is negligible in l_sign. Hence, the probability of A bypassing the attestation protocol as well as modifying contents of the TG is negligible in l_sign, l_mac, l_N, l_sn.

7. Conclusion

In this chapter, we present a novel self-healing decentralized attestation scheme that distributes attestation among devices for systems that work in swarms. Each device carries out periodical ML-based self-attestation on its execution time properties called Device Twin. After that, our design allows swarm attestation to start from any node in the group, verifies its neighbors, and establishes a chain of trust from root to end based on attestation outcomes from one another. The new approach also generates a trusted graph where nodes hold link information to facilitate message exchanges, task collaborations, and service deliveries. We demonstrated the implementation on ARM TrustZone security extensions for embedded devices and showed its security against various software attacks. Evaluation results on real-world IoT applications showed that the new approach incurs negligible system overhead. Basic features of the new scheme include: (1) self-reliant; (2) resilient upon node compromise/failure; (3) captures topology information; (4) attestation starts from a single but trusted entity; (5) chains are immutable for a given attestation session. It also supports:

• Device Mobility,

• Dynamic Topology, and

• Graph Restructuring.

Acronyms

AAPCS	ARM Architecture Procedure Call Standard
AI	Artificial Intelligence
ARM	Advanced RISC Machines
BC	Blockchain
CPS	Cyber-Physical Systems
DoS	Denial-of-Service
DDoS	Distributed Denial-of-Service
EA-MAC	Execution Aware Memory Access Control
ECDSA	Elliptic Curve Digital Signature Algorithm
IIoT	Industrial Internet of Things…
IoT	Internet of Things…
KNN	k-nearest neighbors
MAC	Message Authentication Code
MCU	Memory Controller Unit
ML	Machine Learning
OP-TEE	Open-Source Trusted Execution Environment
PC	Program Counter
RA	Remote Attestation
ROM	Read-Only Memory
RT	Reference Table
SHA	Secure Hash Algorithm
SPOF	Single Point of Failure
TEE	Trusted Execution Environment
TG	Trusted Graph
VERMAC	Verify Message Authentication Code