SDATA: Symmetrical Device Identifier Composition Engine Complied Aggregate Trust Attestation

Abstract

Efficient safeguarding of the security of interconnected devices, which are often resource-constrained, can be achieved through collective remote attestation schemes. However, in existing schemes, the attestation keys are independent of the device configuration, leading to increased requirements for the trusted computing base. This paper introduces a symmetrical aggregate trust attestation that is compatible with devices adhering to the device identifier composition engine framework. The proposed scheme simplifies the trusted computing base requirements by generating an attestation key that is derived from the device configuration. Moreover, the scheme employs distributed aggregate message authentication codes to reduce both the communication volume within the device network and the size of the attestation report, thereby enhancing the aggregation efficiency. In addition, the scheme incorporates interactive authentication to accurately identify compromised devices.

1. Introduction

The Internet of Things (IoT) has a broad range of applications, extending across sectors such as intelligent logistics and smart medical technology. Recently, there has been a significant surge in security incidents, primarily due to cybercriminals compromising the embedded devices within the IoT infrastructure [1,2,3,4]. Given the critical importance of securing these IoT embedded devices, various attestation techniques rooted in trusted computing have been proposed [5,6,7,8,9,10,11,12]. These techniques aim to verify the integrity of these devices. Considering that IoT embedded devices often operate within networks, researchers have developed Collective Remote Attestation (CRA) schemes [13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28]. These schemes are proficient at performing remote attestation for networks of IoT devices.

In each existing CRA, the attestation key is independent of the device configuration. However, to prevent impersonation of the attester and to ensure that the report is consistent with the device configuration, both the measurement code and the attestation code need to be stored in the Trusted Computing Base (TCB). This requirement imposes a higher demand on the TCB in these schemes. During the attestation process, the measurement code is responsible for assessing the device configuration and obtaining metric values, and the attestation code employs the attestation key to either sign the report or generate a Message Authentication Code (MAC).

According to the types of attestation keys, CRAs can be categorized into two types: symmetric [13,14,15,16,17,18,19] and asymmetric [20,21,22,23,24]. Certain schemes, including SEDA [25], DARPA [26], ERASMUS [27], and SALAD [28], offer support for both symmetric and asymmetric cryptography. However, asymmetric schemes such as SANA [20], US-AID [21], ESDRA [22], and SARA [23] demand substantial resources, making them unsuitable for scenarios with resource constraints. As a result, our study will primarily concentrate on symmetric schemes.

Furthermore, existing symmetric CRAs can be broadly divided into two categories: centralized and distributed verification. Centralized verification, exemplified by SAP [13] and ERASMUS [27], involves a remote verifier solely performing the integrity checks of all devices. In contrast, distributed verification involves either self-verification of device integrity (as in LISA [14], slimIoT [15], PADS [16], SCAPI [17], SALAD [28]) or verification by another device (as in SEDA [25], DARPA [26], SeED [18], HEALED [19]). This process necessitates a device to either store reference values or receive them from an attestation request, leading to increased Trusted Computing Base (TCB) requirements as these values must be securely stored in a write-protected area of the memory. Storing the reference values on the device can pose an inconvenience for updating the device. Conversely, if the device receives reference values from an attestation request, it can result in an increased volume of network communication.

We introduce SDATA, a Symmetrical Device Identifier Composition Engine (DICE) complied Aggregate Trust Attestation, with the following features: (1) Adaptability to DICE-Equipped Devices: SDATA is adaptable to DICE-equipped devices with minimal TCB requirements. The TCB of SDATA only needs to ensure a measurement of the device’s initial configuration and generate a unique device identifier from this measurement. There is no need to store the attestation code and reference values in the TCB. A comparison of the TCB requirements of SDATA and other schemes [13,14,15,16,17,18,19,25,26,27,28] is presented in

Table 1. Comparison of TCB requirements.

	SEDA, DARPA, LISA, SeED, PADS, slimIoT, HEALED	SCAPI, SALAD	ERASMUS, SAP	SDATA
measurement	✓	✓	✓	only measure layer 0
attestation code	✓	✓	✓	✗
reference value	store	receive	✗	✗

. (2) Efficient Use of Symmetric Aggregate Message Authentication Codes: SDATA uses symmetric aggregate message authentication codes for efficiency, reducing both the communication volume within the device network and the size of the attestation report. Additionally, it employs distributed aggregation to decrease aggregation time. (3) Support Identification: SDATA incorporates interactive authentication to identify compromised devices.

Outline: Section 2 provides some preliminaries, Section 3 outlines SDATA, and Section 4 describes the workflow of SDATA in detail. Section 5 discusses the security analysis of SDATA, and Section 6 elaborates on the performance evaluation of SDATA. Section 7 explores the extension of SDATA.

2. Preliminaries

2.1. DICE

DICE, an architecture proposed by the Trusted Computing Group (TCG) [29], offers robust security foundations for systems with minimal silicon requirements and without a TPM. It operates in a chain-like manner to generate a device identifier (${\mathsf{di}}^l$) for each layer using a one-way function ($\mathtt{OWF}$). This process is based on the unique device secret ($\mathsf{uds}$) and the configuration measurement (${\mathsf{ci}}^l$) of each layer, which are safeguarded by hardware during secure booting. Assuming that the last layer is layer h, layer h can derive a symmetric attestation key $\mathsf{k}$ using the ${\mathsf{di}}^l(l=h)$ with a key derivation function ($\mathtt{KDF}$). The process is as follows:

$$\mathrm{layer} 0:{\mathsf{di}}^0=\mathtt{OWF}({\mathsf{ci}}^0,\mathsf{uds}), \mathrm{layer} 1:{\mathsf{di}}^l=\mathtt{OWF}({\mathsf{ci}}^l,{\mathsf{di}}^{l-1})(l=1,\dots ,h); \mathsf{k}=\mathtt{KDF}\left({\mathsf{di}}^l\right)(l=h)$$

2.2. Aggregate Message Authentication Code

The aggregate Message Authentication Code (MAC) [30] is a technique that facilitates the consolidation of multiple message authentication codes, generated by a variety of senders, into a more compact authentication code using XOR or hash operations. This condensed code can be verified by a recipient who holds the secret keys of the senders. The XOR aggregation and verification processes are outlined as follows (where ${\mathsf{id}}_i$ represents an identity, $m_i$ is a message, $t_i$ is an MAC tag, $k_i$ is a secret key, n is the number of aggregations, and $\dot{T}$ is an aggregate MAC):

$\mathtt{AggMAC}\left(\{({\mathsf{id}}_1,m_1,t_1),\dots ,({\mathsf{id}}_n,m_n,t_n)\}\right)\to \dot{T}$: take bitwise XOR of MAC tags $\dot{T}={⨁}_{i\in (1,\dots ,n)}{t}_i$

$\mathtt{AggVerify}(\{({\mathsf{id}}_1,m_1,k_1),\dots ,({\mathsf{id}}_n,m_n,k_n)\},\dot{T})\to \mathsf{result}$: for each $({\mathsf{id}}_i,m_i,k_i)$, recompute $\ddot{t_i}=\mathtt{MAC}(k_i,m_i)$ and then recalculate $\ddot{T}={⨁}_{i\in (1,\dots ,n)}\ddot{t_i}$, if $\dot{T}=\ddot{T}$ holds, $\mathsf{result}=\mathsf{ACCEPT}$, otherwise, $\mathsf{result}=\mathsf{REJECT}$

3. SDATA

3.1. System Model

We consider a network, denoted as $\mathcal{DN}$, which consists of interconnected, resource-constrained devices. This network is composed of numerous embedded devices, represented as ${\mathcal{D}}_i$, equipped with DICE. The devices in $\mathcal{DN}$ undergo verification by a remote verifier ($\mathcal{RV}$), with the device supplier ($\mathcal{DS}$) providing reference values to facilitate this process. During an attestation, it is assumed that only a seed device, denoted as ${\mathcal{D}}_1$, exists within $\mathcal{DN}$. The primary responsibilities of this seed device include receiving an attestation request from the remote verifier $\mathcal{RV}$, forwarding this request to other devices within the network, generating an aggregate report of $\mathcal{DN}$, and subsequently transmitting this report to $\mathcal{RV}$. This process is depicted in Figure 1a. The devices within $\mathcal{DN}$ are capable of identifying and interacting with their immediate neighbors and communicating with $\mathcal{RV}$, and possess the computational ability to compute the MAC.

The objectives of SDATA are as follows: (1) Completeness: Assuming that all devices in $\mathcal{DN}$ are benign, $\mathcal{RV}$ should consistently produce a positive attestation outcome. (2) Scalability: The system should facilitate the remote verification of the integrity of a large $\mathcal{DN}$ as a whole. (3) Unforgeability: The system must be capable of detecting and declaring the network as untrustworthy if some devices are remotely compromised, or if some attestation reports are intentionally falsified. (4) Efficiency: The system should provide superior efficiency compared to individual attestations. (5) Identifiability: The system should possess the capability to identify compromised devices.

3.2. Work Flow

SDATA consists of four system processes: prepare, reports, verify, and identify. The interactions between entities in these processes are depicted in Figure 1b.

Prepare. Before the deployment of any device, the identity of layer 0 for each device must be shared with $\mathcal{RV}$. Subsequently, during the booting process, each device generates a symmetric attestation key derived from the chained identity of its last layer.

Reports. Upon receiving an attestation request, each device employs its attestation key to produce an MAC for reporting its integrity. A device may also collect reports from its child devices, aggregate these accumulated MACs with its own, and then relay the consolidated outcome to its parent.

Verify. The $\mathcal{RV}$ verifies $\mathcal{DN}$ by reconstructing the attestation keys, which are based on the shared identities of devices at layer 0 and the device reference values from $\mathcal{DS}$, and subsequently verifies the aggregate MAC.

Identify. If the verification is unsuccessful, the devices in $\mathcal{DN}$ will attempt to send their stored aggregate reports to $\mathcal{RV}$ for individual verification. If some of these aggregate reports also fail the verification, the aforementioned procedure is repeated to identify compromised devices.

3.3. Security Assumptions and Threats

This section outlines the security assumptions and adversary model.

Security Assumptions. (1) TCB assumption: The TCB of SDATA is limited to the DICE layers in the devices of $\mathcal{DN}$. (2) It is assumed that the hash function, MAC algorithm, $\mathtt{OWF}$, and $\mathtt{KDF}$ employed in SDATA are secure. (3) It is assumed that $\mathcal{RV}$ is honest and secure.

Adversary Model. (1) It is assumed that an adversary can access a device’s data and code, with the exception of the DICE layer. And, the cold boot attack is not considered. (2) It is assumed that an adversary can eavesdrop, intercept, tamper with, and replay all messages exchanged between devices and between devices and $\mathcal{RV}$. (3) DoS attacks are not considered.

Given these security assumptions, SDATA is designed to thwart these potential attacks and achieve the objectives outlined in Section 3.1.

4. SDATA Design

This section explores the design of SDATA. For the purpose of clarity in the subsequent content, each device in the network $\mathcal{DN}$ will be denoted as ${\mathcal{D}}_i$, with the last layer of ${\mathcal{D}}_i$ referred to as layer h.

4.1. Prepare

During the secure booting process, the DICE layer of ${\mathcal{D}}_i$ serves as its TCB. It measures the layer 0 component and combines it with a $\mathsf{uds}$ to generate a unique identifier, ${\mathsf{di}}_i^0$, for layer 0. A potential TCB implementation within ${\mathcal{D}}_i$ could include a processor boot Read-Only Memory (ROM) that houses both the ${\mathsf{uds}}_i$ and the DICE layer code. Additionally, a simple Memory Protection Unit (MPU) could be employed to restrict access to ${\mathsf{uds}}_i$ exclusively to the DICE layer.

The preparation process for device ${\mathcal{D}}_i$ is illustrated in Figure 2 and involves two scenarios: (1) Pre-Deployment: Prior to deployment, ${\mathcal{D}}_i$ shares the TCB-generated ${\mathsf{di}}_i^0$ with $\mathcal{RV}$. (2) Post-Deployment: Upon deployment, ${\mathcal{D}}_i$ generates an identifier, ${\mathsf{di}}_i^l(l=h)$, in a chain-like manner, derived from ${\mathsf{di}}_i^0$. Ultimately, the last layer, layer h, contains ${\mathsf{id}}_i$ (computed based on ${\mathsf{di}}_i^0$ by layer 0), ${\mathsf{di}}_i^l(l=h)$, and ${\mathsf{cd}}_i$. The ${\mathsf{cd}}_i$ includes the component information of layers $1,\dots ,h$. Subsequently, ${\mathcal{D}}_i$ generates an attestation key, $k_i$, based on ${\mathsf{di}}_i^l(l=h)$.

4.2. Reports

The attestation request, which includes a random number denoted as $\mathsf{vn}$, is initiated by $\mathcal{RV}$. The seed device receives this request and broadcasts it throughout the network. Each device designates the first device that transmits the request as its parent and further disseminates the request. This dissemination culminates in a logical tree structure where each device represents a node.

4.2.1. Generate Individual Report

When an attestation request is received by the device ${\mathcal{D}}_i$, it generates its own random number, ${\mathsf{dn}}_i$. ${\mathcal{D}}_i$ then constructs $m_i$ by concatenating $\mathsf{vn}$ and ${\mathsf{dn}}_i$. Following this, ${\mathcal{D}}_i$ employs $k_i$ to calculate the MAC tags, denoted as $t_i=\mathtt{MAC}(k_i,m_i)$.

In conclusion, the individual report of ${\mathcal{D}}_i$ is $({\mathsf{id}}_i,{\mathsf{dn}}_i,t_i,{\mathsf{cd}}_i)$.

4.2.2. Aggregate Reports

In the case where ${\mathcal{D}}_i$ is a non-leaf device, it first produces its own attestation report and then waits for a certain duration to gather reports from its child devices.

Suppose that ${\mathcal{D}}_i$ has gathered u individual reports from its leaf children, each denoted as $({\mathsf{id}}_j,{\mathsf{dn}}_j,t_j,{\mathsf{cd}}_j)$, where $1\le j\le u$. ${\mathcal{D}}_i$ then recalculates $m_j=\mathsf{vn}\parallel {\mathsf{dn}}_j$ for $j=1,\dots ,u,i$. Following this, ${\mathcal{D}}_i$ aggregates $({\mathsf{id}}_j,{\mathsf{m}}_j,t_j,{\mathsf{cd}}_j)$$(j=1,\dots ,u,i)$ according to $T_i^{\prime }\leftarrow \mathtt{AggMAC}\left(\right\{({\mathsf{id}}_1,$ $m_1,t_1),\dots ,({\mathsf{id}}_u,m_u,t_u),({\mathsf{id}}_i,m_i,t_i)\left\}\right)$ as described in Section 2.2. Subsequently, ${\mathcal{D}}_i$ merges $({\mathsf{id}}_j,{\mathsf{dn}}_j,{\mathsf{cd}}_j)$$(j=1,\dots ,u,i)$ into $({\widehat{\mathsf{id}}}_i^{\prime },{\widehat{\mathsf{dn}}}_i^{\prime },{\widehat{\mathsf{cd}}}_i^{\prime })$, resulting in an aggregate report $(T_i^{\prime },{\widehat{\mathsf{id}}}_i^{\prime },{\widehat{\mathsf{dn}}}_i^{\prime },{\widehat{\mathsf{cd}}}_i^{\prime })$. If $u=0$, indicating that ${\mathcal{D}}_i$ has no leaf children, then $T_i^{\prime }=t_i, {\widehat{\mathsf{id}}}_i^{\prime }=\left\{{\mathsf{id}}_i\right\}, {\widehat{\mathsf{dn}}}_i^{\prime }=\left\{{\mathsf{dn}}_i\right\}, {\widehat{\mathsf{cd}}}_i^{\prime }=\left\{{\mathsf{cd}}_i\right\}$.

Suppose that ${\mathcal{D}}_i$ has gathered v aggregate reports from its non-leaf children, each denoted as $(T_j,{\widehat{\mathsf{id}}}_j,{\widehat{\mathsf{dn}}}_j,{\widehat{\mathsf{cd}}}_j)$, where $1\le j\le v$. $D_i$ aggregates each $(T_j,{\widehat{\mathsf{id}}}_j,{\widehat{\mathsf{dn}}}_j,{\widehat{\mathsf{cd}}}_j)$ with $(T_i^{\prime },{\widehat{\mathsf{id}}}_i^{\prime },{\widehat{\mathsf{dn}}}_i^{\prime },{\widehat{\mathsf{cd}}}_i^{\prime })$:

$$T_i=T_i^{\prime }⨁T_j,{\widehat{\mathsf{id}}}_i={\widehat{\mathsf{id}}}_i^{\prime }\cup {\widehat{\mathsf{id}}}_j,{\widehat{\mathsf{dn}}}_i={\widehat{\mathsf{dn}}}_i^{\prime }\cup {\widehat{\mathsf{dn}}}_j,{\widehat{\mathsf{cd}}}_i={\widehat{\mathsf{cd}}}_i^{\prime }\cup {\widehat{\mathsf{cd}}}_j$$

(1)

Subsequently, ${\mathcal{D}}_i$ forwards the aggregate report $(T_i,{\widehat{\mathsf{id}}}_i,{\widehat{\mathsf{dn}}}_i,{\widehat{\mathsf{cd}}}_i)$ to its parent.

It is important to emphasize that ${\mathcal{D}}_i$ is required to temporarily hold u collected individual reports, its own individual report, and v collected aggregate reports, as well as the aggregate report $(T_i^{\prime },{\widehat{\mathsf{id}}}_i^{\prime },{\widehat{\mathsf{dn}}}_i^{\prime },{\widehat{\mathsf{cd}}}_i^{\prime })$ produced by ${\mathcal{D}}_i$, for a certain period. This storage facilitates the subsequent identification of potentially compromised devices.

Finally, the seed device generates an aggregate report for $\mathcal{DN}$, represented as $(T,\widehat{\mathsf{id}},\widehat{\mathsf{dn}},\widehat{\mathsf{cd}})$, and forwards this report to $\mathcal{RV}$.

4.3. Verify

Upon receiving the aggregate report $(T,\widehat{\mathsf{id}},\widehat{\mathsf{dn}},\widehat{\mathsf{cd}})$, which consolidates n individual reports, $\mathcal{RV}$ undertakes the following steps:

(1) For $(\widehat{\mathsf{id}},\widehat{\mathsf{dn}},\widehat{\mathsf{cd}})$, $\mathcal{RV}$ filters out duplicate layer component information from $\widehat{\mathsf{cd}}$, resulting in a set of distinct layer component information $\{{\mathsf{lc}}_1,\dots ,{\mathsf{lc}}_x\}$. $\mathcal{RV}$ then retrieves the component reference values from $\mathcal{DS}$ based on $\{{\mathsf{lc}}_1,\dots ,{\mathsf{lc}}_x\}$. For each $({\mathsf{id}}_i,{\mathsf{dn}}_i,{\mathsf{cd}}_i)$ where $1\le i\le n$, $\mathcal{RV}$ maps the obtained values ${\mathsf{ci}}_1,\dots ,{\mathsf{ci}}_x$ to each layer’s integrity reference value ${\widetilde{{\mathsf{ci}}_i}}^l$$(l=1,\dots ,h)$.

(2) Subsequently, $\mathcal{RV}$ reconstructs the attestation key ${\mathsf{k}}_i^{\prime }$ of ${\mathcal{D}}_i$ based on the shared identifier ${\mathsf{di}}_i^0$ using the following formulas:

$${\mathsf{k}}_i^{\prime }=\mathtt{KDF}\left({\widetilde{{\mathsf{di}}_i}}^l\right)(l=h),{\widetilde{{\mathsf{di}}_i}}^l=\mathtt{OWF}({\widetilde{\mathsf{di}}}_i^{l-1},{\widetilde{{\mathsf{ci}}_i}}^l)(l=2,\dots ,h),{\widetilde{\mathsf{di}}}_i^1=\mathtt{OWF}({\mathsf{di}}_i^0,{\widetilde{{\mathsf{ci}}_i}}^1)$$

(2)

Following this, $\mathcal{RV}$ recalculates $m_i=\mathsf{vn}\parallel {\mathsf{dn}}_i$.

(3) $\mathcal{RV}$ then verifies the aggregate MAC T according to $\mathsf{result}\leftarrow \mathtt{AggVerify}\left(\right\{({\mathsf{id}}_1,m_1,k_1^{\prime }),$ $\dots ,({\mathsf{id}}_n,m_n,k_n^{\prime })\},T)$, as described in Section 2.2. If the value of $\mathsf{result}$ is $\mathsf{ACCEPT}$, this signifies that $\mathcal{DN}$ is deemed trustworthy. Conversely, $\mathcal{DN}$ is untrustworthy.

4.4. Identify

In the event that the outcome in Section 4.3 is $\mathsf{REJECT}$, a subsequent procedure can be employed to identify compromised devices. Let $\mathbb{I}$ represent the set of devices that have not been verified, and $\mathbb{J}$ denote the set of compromised devices. Both sets are initially assigned the value $\widehat{\mathsf{id}}$.

(1) Upon receiving an identification request from $\mathcal{RV}$ or the parent, a device ${\mathcal{D}}_i$ ($i\in \{1,\dots ,n\}$, where the initial value of i is 1) selects an aggregate report from its temporary storage, denoted as $(T_{\mathbb{S}},\widehat{{\mathsf{id}}_{\mathbb{S}}},\widehat{{\mathsf{dn}}_{\mathbb{S}}},\widehat{{\mathsf{cd}}_{\mathbb{S}}})$, and sends it to $\mathcal{RV}$.

(2) If the verification result from $\mathcal{RV}$ is $\mathsf{ACCEPT}$, $\mathbb{J}\leftarrow \mathbb{J}\backslash \widehat{{\mathsf{id}}_{\mathbb{S}}},\mathbb{I}\leftarrow \mathbb{I}\backslash \widehat{{\mathsf{id}}_{\mathbb{S}}}$. If $\mathbb{I}\ne \varnothing$, the device goes to step (1) with another aggregate report.

(3) If the verification result is $\mathsf{REJECT}$, there are two potential scenarios:

• If $(T_{\mathbb{S}},\widehat{{\mathsf{id}}_{\mathbb{S}}},\widehat{{\mathsf{dn}}_{\mathbb{S}}},\widehat{{\mathsf{cd}}_{\mathbb{S}}})$ represents the aggregate report from itself and its leaf child nodes, it sends $u+1$ stored individual reports to $\mathcal{RV}$. Then, set $\mathbb{I}\leftarrow \mathbb{I}\backslash \widehat{{\mathsf{id}}_{\mathbb{S}}}$, and the device IDs that were successfully verified are removed from $\mathbb{J}$. If $\mathbb{I}\ne \varnothing$, the device goes to step (1) with another aggregate report.
• If $(T_{\mathbb{S}},\widehat{{\mathsf{id}}_{\mathbb{S}}},\widehat{{\mathsf{dn}}_{\mathbb{S}}},\widehat{{\mathsf{cd}}_{\mathbb{S}}})$ is one of the other aggregate reports, the device notifies the corresponding non-leaf child node. This non-leaf child node then goes to step (1).

The final output is a set $\mathbb{J}$ consisting of the IDs of the compromised devices. Based on the identification results, the administrator of $\mathcal{DN}$ has the ability to repair these compromised devices.

In conclusion, Figure 3 illustrates the comprehensive attestation process of SDATA.

5. Security Analysis

This section will provide a proof of completeness and an elaboration on unforgeability.

5.1. Completeness

As described in Figure 2 in Section 4.1, the attestation key of ${\mathcal{D}}_i$ is given by ${\mathsf{k}}_i=\mathtt{KDF}\left({\mathsf{di}}_i^l\right)$$(l=h)$, where ${\mathsf{di}}_i^l=\mathtt{OWF}({\mathsf{di}}_i^{l-1},{\mathsf{ci}}_i^l)(l=1,\dots ,h),{\mathsf{di}}_i^0=\mathtt{OWF}({\mathsf{uds}}_i,{\mathsf{ci}}_i^0)$. Assuming that $\mathcal{RV}$ is honest, ${\mathcal{D}}_i$ is benign, and ${\mathsf{cd}}_i$ in the aggregate report remains constant, the ${\widetilde{\mathsf{ci}}}_i^l$$(l=1,\dots ,h)$ retrieved by $\mathcal{RV}$ from $\mathcal{DS}$ and the corresponding ${\mathsf{ci}}_i^l$ will be identical. This ensures that the reconstructed key ${\mathsf{k}}_i^{\prime }$ by $\mathcal{RV}$ will match ${\mathsf{k}}_i$. If each reassembled key is consistent with the attestation key of its respective device, and ${\mathsf{dn}}_i$ and the individual random number of each device ${\mathcal{D}}_i$, which is part of the message $m_i$$(i=1,\dots ,n)$, along with the tag T and $\mathsf{id}$ contained in the aggregate report, remain constant, then $\mathcal{RV}$ will execute the $\mathtt{AggVerify}$ algorithm and invariably receive an $\mathsf{ACCEPT}$ outcome. As a result, $\mathcal{RV}$ will consistently yield a positive attestation outcome for $\mathcal{DN}$.

5.2. Unforgeability

In SDATA, the attestation code is not part of the TCB, yet it can still prevent report forgery attacks. Consider a scenario where a device ${\mathcal{D}}_i$ is compromised and at least one layer l$(l\in \{0,\dots ,h\left\}\right)$ has been breached. In this case, ${\mathcal{D}}_i$ can exhibit three main types of report forgery abnormalities:

(1) ${\mathcal{D}}_i$ attempts to generate a valid report: If an adversary tries to alter a layer l while causing ${\mathcal{D}}_i$ to generate a valid report, the measurements ${\mathsf{ci}}_i^l$ computed by layer $l-1$ should match the corresponding ${\widetilde{\mathsf{ci}}}_i^l$$(l=0,\dots ,h)$ provided by $\mathcal{DS}$. However, this is not the expected behavior of layer $l-1$. Consequently, this would necessitate modifying the code in layer $l-1$. Following the same reasoning, it would also require altering the DICE layer. But, this contravenes the TCB assumption outlined in Section 3.3.

(2) ${\mathcal{D}}_i$ attempts to obtain the correct attestation key $k_j$ to impersonate ${\mathcal{D}}_j$:

${\mathcal{D}}_i$ tries to generate a $k_j$ on its own. ${\mathsf{k}}_j=\mathtt{KDF}\left({\mathsf{di}}_j^l\right)(l=h)$, where ${\mathsf{di}}_j^l=\mathtt{OWF}({\mathsf{di}}_j^{l-1},$${\mathsf{ci}}_j^l)(l=1,\dots ,h),{\mathsf{di}}_j^0=\mathtt{OWF}({\mathsf{uds}}_j,{\mathsf{ci}}_j^0)$. Since ${\mathsf{uds}}_j$ cannot be accessed outside of the DICE layer of ${\mathcal{D}}_j$, ${\mathsf{di}}_j^0$ cannot be leaked by $\mathcal{RV}$, and ${\mathsf{di}}_j^l$$(l=0,\dots ,h)$ cannot be leaked by ${\mathcal{D}}_j$’s layer l (as explained in the following sub-case). Therefore, ${\mathcal{D}}_i$ cannot generate a $k_j$.

${\mathcal{D}}_i$ tries to obtain secrets from ${\mathcal{D}}_j$. If the compromised layer l$(l=0,\dots ,h-1)$ of ${\mathcal{D}}_j$ attempts to transmit ${\mathsf{di}}_j^l$ or ${\mathsf{di}}_j^{l+1}$, or the compromised layer h attempts to transmit $k_j$ to ${\mathcal{D}}_i$, as described in (1), ${\mathsf{di}}_j^l$, …, ${\mathsf{di}}_j^h$, or $k_j$ will be incorrect.

This implies that, under any circumstances, ${\mathcal{D}}_i$ cannot obtain the correct attestation key of ${\mathcal{D}}_j$. Therefore, ${\mathcal{D}}_i$ cannot successfully impersonate ${\mathcal{D}}_j$.

(3) ${\mathcal{D}}_i$ attempts to perform replay attacks: Each attestation request includes a random number $\mathsf{vn}$ and each individual report contains a device random number ${\mathsf{dn}}_{\mathsf{i}}$. If ${\mathcal{D}}_i$ attempts to replay the report, $\mathcal{RV}$ will detect it during the computation of $m_i$.

6. Performance Evaluation

In our experiment, each device node is simulated by a process, and devices within $\mathcal{DN}$ utilize the gossip protocol [31] for communication. The hash and HMAC functions are facilitated by the libsecp256k1 library [32].

The evaluation experiments are carried out on Ubuntu 20.04 in a VMware (VM) environment. The VM is hosted on a physical machine outfitted with a 13th Gen Intel(R) Core(TM) i7-13700H @ 2.40 GHz processor and 32 GB of RAM.

All existing symmetric CRAs utilize Trusted Execution Environment (TEE) architectures, such as SMART [33], TrustLite [34], and TyTan [35]. These architectures are distinct from SDATA; hence, a comparison with them has not been conducted. A series of experiments were conducted, involving varying numbers of devices within $\mathcal{DN}$, to assess both its communication volume and aggregation times.

6.1. Report Size and Communication Volume

Firstly, the primary communication data between the seed device and $\mathcal{RV}$ are the aggregate report. In our experiment, the sizes of the attestation key, random number, and MAC tag are all 32B. According to the specification [36], it is assumed that the size of the detailed information for each layer’s component is 200B, although this may not be necessary in practical applications. It is also assumed that the number of device layers is 3, and the number of devices in $\mathcal{DN}$ is n. An individual attestation report of a device ${\mathcal{D}}_i$ is represented as $({\mathsf{id}}_i,{\mathsf{dn}}_i,t_i,{\mathsf{cd}}_i)$, as described in Section 4.2, and its size is 496B. Without aggregation, the total reports of $\mathcal{DN}$ are represented as $(\widehat{t},\widehat{\mathsf{id}},\widehat{\mathsf{dn}},\widehat{\mathsf{cd}})$, and their size is 496nB. However, with aggregation, the aggregate report of $\mathcal{DN}$ is represented as $(T,\widehat{\mathsf{id}},\widehat{\mathsf{dn}},\widehat{\mathsf{cd}})$, requiring only $(464n+32)$B. In practical applications, the network between the seed device and $\mathcal{RV}$ is typically a high-load network, and the size of the report is not a significant concern.

Secondly, $\mathcal{DN}$ is a resource-constrained network. The hop-byte metric is employed to evaluate the communication volume within $\mathcal{DN}$, referring to a byte transmitted between a child node and its parent node. It is important to note that the communication volume that we subsequently consider only includes MAC tags in reports during the attestation response process, excluding identification. Consider a device, ${\mathcal{D}}_i$, a non-leaf node in a spanning tree generated during a complete attestation, with x descendants. Without aggregation, ${\mathcal{D}}_i$ would directly merge $x+1$ MAC tags, including its own report and the individual reports of all its descendants, and transmit a total of $32(x+1)$ hop-bytes to its parent. In contrast, with aggregation, as described in Section 4.2.2, the aggregate report of ${\mathcal{D}}_i$ would only transmit an aggregate MAC of 32 hop-bytes to its parent. This aggregation leads to a reduction in the communication volume within $\mathcal{DN}$.

Figure 4a illustrates the communication volume within $\mathcal{DN}$ under both aggregation and non-aggregation scenarios, across varying numbers of devices. The height of an entire bar represents the communication volume within $\mathcal{DN}$ for a specific number of devices. In the case of aggregation, the total communication volume remains consistent for a given number of devices, eliminating the need for stacked bars. On the other hand, in the non-aggregation stacked bar, the series y$(y=1,\dots ,7)$ represents the average hop-bytes transmitted from level y to level $y-1$ over 20 runs. Within a spanning tree, the root node is at level 0, its child nodes are at level 1, and so on. As depicted in the figure, the communication volume with aggregation is only equal to the hop-bytes of level 1 without aggregation. As the number of devices increases, the communication volume with aggregation decreases significantly.

6.2. Distributed Aggregation

In the SDATA system, which is inherently distributed, aggregation is performed concurrently across multiple non-leaf devices. The series y$(y=0,\dots ,6)$ in the stacked bar of Figure 4b represents the maximum aggregation times of level y nodes in a spanning tree, averaged over 20 runs. The total height of a bar signifies the time taken to generate the complete report of $\mathcal{DN}$. In the case of centralized aggregation, the seed device sequentially consolidates all individual reports from its descendants, and the aggregation times remain consistent for a given number of devices. As depicted in Figure 4b, distributed aggregation is more efficient than centralized aggregation. Notably, as the number of devices increases, the efficiency of aggregation significantly improves.

7. Discussion

The related work [13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28] is illustrated in the introduction. Existing attestation methods are classified into symmetric and asymmetric categories. Within the symmetric category, further division is made into centralized and distributed verification. A common characteristic across these attestation schemes is that the attestation key is independent of the device configuration. This aspect distinguishes them from SDATA. Further details will not be elaborated on in this section.

The extension of the SDATA system is being explored, with the identification process being the initial focus for refinement. The proposed identification process of SDATA in this paper is interactive. Devices select the next group for testing after receiving the verification result from the previous group, a feature that is characteristic of adaptive group testing. An adaptive group testing protocol [37] could be employed to strike a balance between the number of interactions and the volume of communication. This could involve the use of binary search, the rake-and-winnow algorithm, Li’s multi-stage algorithm, and the digging algorithm. Alternatively, the identification process could be transformed into a non-interactive method using non-adaptive group testing [38]. This method would use a disjunct matrix to divide the attestation device into multiple test sets, and then send the attestation results of multiple test sets to the verifier at once, thereby reducing the number of interactions.

This section also includes a discussion on the attestation-key-sharing aspect of SDATA. In SDATA, each device is required to share its layer 0 identifier with $\mathcal{RV}$, necessitating $\mathcal{RV}$ to store identifiers of all devices. For a closed scenario, an alternative strategy could be to share only the ${\mathsf{di}}_1^0$ of the seed device with $\mathcal{RV}$, while other devices use ${\mathsf{di}}_1^0$ as their unique device secrets. Then, $\mathcal{RV}$ can still reconstruct the attestation keys of the devices using ${\mathsf{di}}_1^0$ and the reported components’ detailed information.

However, symmetric attestation secret sharing is not suitable for open scenarios, such as the remote attestation of confidential container clusters or other systems in cloud computing [39,40,41,42,43]. Instead, aggregate remote attestation based on asymmetric cryptography could be considered for confidential container clusters, as it eliminates the need for secret sharing.

8. Conclusions

We present SDATA, an efficient symmetric aggregate trust attestation that is compliant with DICE and is designed for a network of interconnected low-end devices. The TCB of SDATA only needs to accurately generate an identifier for device layer 0. Subsequently, the device derives an attestation key associated with its configuration, eliminating the need to store the attestation code and reference values. This feature simplifies the TCB requirements compared to other schemes while still offering protection against forgery attacks. Moreover, the use of an aggregate MAC significantly reduces both the communication volume within the device network and the size of the attestation report. The distributed aggregation further enhances the aggregation efficiency. SDATA employs interactive authentication to identify compromised devices.