SDATA: Symmetrical Device Identifier Composition Engine Complied Aggregate Trust Attestation

: 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.

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.(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.

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 (di l ) for each layer using a one-way function (OWF).This process is based on the unique device secret (uds) and the configuration measurement (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 k using the di l (l = h) with a key derivation function (KDF).The process is as follows: layer 0: di 0 = OWF(ci 0 , uds), layer l:

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 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 Ṫ is an aggregate MAC): AggMAC({(id 1 , m 1 , t 1 ), . . ., (id n , m n , t n )}) → Ṫ: take bitwise XOR of MAC tags Ṫ = i∈(1,...,n) t i AggVerify({(id 1 , m 1 , k 1 ), . . ., (id n , m n , k n )}, Ṫ) → result: for each (id i , m i , k i ), recompute ẗi = MAC(k i , m i ) and then recalculate T = i∈(1,...,n) ẗi , if Ṫ = T holds, result = ACCEPT, otherwise, result = REJECT

SDATA 3.1. System Model
We consider a network, denoted as DN , which consists of interconnected, resourceconstrained devices.This network is composed of numerous embedded devices, represented as D i , equipped with DICE.The devices in DN undergo verification by a remote verifier (RV), with the device supplier (DS) providing reference values to facilitate this process.During an attestation, it is assumed that only a seed device, denoted as D 1 , exists within DN .The primary responsibilities of this seed device include receiving an attestation request from the remote verifier RV, forwarding this request to other devices within the network, generating an aggregate report of DN , and subsequently transmitting this report to RV.This process is depicted in Figure 1a.The devices within DN are capable of identifying and interacting with their immediate neighbors and communicating with RV, and possess the computational ability to compute the MAC.
The objectives of SDATA are as follows: (1) Completeness: Assuming that all devices in DN are benign, RV should consistently produce a positive attestation outcome.(2) Scalability: The system should facilitate the remote verification of the integrity of a large 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.

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 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 RV verifies DN by reconstructing the attestation keys, which are based on the shared identities of devices at layer 0 and the device reference values from DS, and subsequently verifies the aggregate MAC.
Identify.If the verification is unsuccessful, the devices in DN will attempt to send their stored aggregate reports to RV for individual verification.If some of these aggregate reports also fail the verification, the aforementioned procedure is repeated to identify compromised devices.

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 DN .(2) It is assumed that the hash function, MAC algorithm, OWF, and KDF employed in SDATA are secure.(3) It is assumed that 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 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.

SDATA Design
This section explores the design of SDATA.For the purpose of clarity in the subsequent content, each device in the network DN will be denoted as D i , with the last layer of D i referred to as layer h.

Prepare
During the secure booting process, the DICE layer of D i serves as its TCB.It measures the layer 0 component and combines it with a uds to generate a unique identifier, di 0 i , for layer 0. A potential TCB implementation within D i could include a processor boot Read-Only Memory (ROM) that houses both the uds i and the DICE layer code.Additionally, a simple Memory Protection Unit (MPU) could be employed to restrict access to uds i exclusively to the DICE layer.
The preparation process for device D i is illustrated in Figure 2 and involves two scenarios: (1) Pre-Deployment: Prior to deployment, D i shares the TCB-generated di 0 i with RV. (2) Post-Deployment: Upon deployment, D i generates an identifier, di l i (l = h), in a chain-like manner, derived from di 0 i .Ultimately, the last layer, layer h, contains id i (computed based on di 0 i by layer 0), di l i (l = h), and cd i .The cd i includes the component information of layers 1, . . ., h.Subsequently, D i generates an attestation key, k i , based on di l i (l = h).
RV DICE Layer 0 Layer 1 Layer h Figure 2. Device preparation process.

Reports
The attestation request, which includes a random number denoted as vn, is initiated by 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.

Generate Individual Report
When an attestation request is received by the device D i , it generates its own random number, dn i .D i then constructs m i by concatenating vn and dn i .Following this, D i employs k i to calculate the MAC tags, denoted as t i = MAC(k i , m i ).
In conclusion, the individual report of D i is (id i , dn i , t i , cd i ).

Aggregate Reports
In the case where 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 D i has gathered u individual reports from its leaf children, each denoted as (id j , dn j , t j , cd j ), where 1 ≤ j ≤ u.D i then recalculates m j = vn∥dn j for j = 1, . . ., u, i.Following this, D i aggregates (id j , m j , t j , cd j ) (j = 1, . . ., u, i) according to T ′ i ← AggMAC({(id 1 , m 1 , t 1 ), . . ., (id u , m u , t u ), (id i , m i , t i )}) as described in Section 2.2.Subsequently, D i merges Suppose that D i has gathered v aggregate reports from its non-leaf children, each denoted as (T j , î d j , dn j , ĉd j ), where 1 ≤ j ≤ v. D i aggregates each (T j , î d j , dn j , ĉd j ) with Subsequently, D i forwards the aggregate report (T i , î d i , dn i , ĉd i ) to its parent.
It is important to emphasize that 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 ) produced by 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 DN , represented as (T, î d, dn, ĉd), and forwards this report to RV.

Verify
Upon receiving the aggregate report (T, î d, dn, ĉd), which consolidates n individual reports, RV undertakes the following steps: (1) For ( î d, dn, ĉd), RV filters out duplicate layer component information from ĉd, resulting in a set of distinct layer component information {lc 1 , . . ., lc x }.RV then retrieves the component reference values from DS based on {lc 1 , . . ., lc x }.For each (id i , dn i , cd i ) where 1 ≤ i ≤ n, RV maps the obtained values ci 1 , . . ., ci x to each layer's integrity reference value ci i l (l = 1, . . ., h).
(2) Subsequently, RV reconstructs the attestation key k ′ i of D i based on the shared identifier di 0 i using the following formulas: Following this, RV recalculates m i = vn∥dn i .

Identify
In the event that the outcome in Section 4.3 is REJECT, a subsequent procedure can be employed to identify compromised devices.Let I represent the set of devices that have not been verified, and J denote the set of compromised devices.Both sets are initially assigned the value î d.
(1) Upon receiving an identification request from RV or the parent, a device D i (i ∈ {1, . . ., n}, where the initial value of i is 1) selects an aggregate report from its temporary storage, denoted as (T S , îd S , d n S , ĉd S ), and sends it to RV. (2) If the verification result from RV is ACCEPT, J ← J\ îd S , I ← I\ îd S .If I ̸ = ∅, the device goes to step (1) with another aggregate report.
(3) If the verification result is REJECT, there are two potential scenarios: If (T S , îd S , d n S , ĉd S ) represents the aggregate report from itself and its leaf child nodes, it sends u + 1 stored individual reports to RV.Then, set I ← I\ îd S , and the device IDs that were successfully verified are removed from J. If I ̸ = ∅, the device goes to step (1) with another aggregate report.If (T S , îd S , d n S , ĉd 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 J consisting of the IDs of the compromised devices.Based on the identification results, the administrator of DN has the ability to repair these compromised devices.
In conclusion, Figure 3 illustrates the comprehensive attestation process of SDATA.

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

Completeness
As described in Figure 2 in Section 4.1, the attestation key of D i is given by Assuming that RV is honest, D i is benign, and cd i in the aggregate report remains constant, the ci l i (l = 1, . . ., h) retrieved by RV from DS and the corresponding ci l i will be identical.This ensures that the reconstructed key k ′ i by RV will match k i .If each reassembled key is consistent with the attestation key of its respective device, and dn i and the individual random number of each device D i , which is part of the message m i (i = 1, . . ., n), along with the tag T and id contained in the aggregate report, remain constant, then RV will execute the AggVerify algorithm and invariably receive an ACCEPT outcome.As a result, RV will consistently yield a positive attestation outcome for DN .

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 D i is compromised and at least one layer l (l ∈ {0, . . ., h}) has been breached.In this case, D i can exhibit three main types of report forgery abnormalities: (1) D i attempts to generate a valid report: If an adversary tries to alter a layer l while causing D i to generate a valid report, the measurements ci l i computed by layer l − 1 should match the corresponding ci l i (l = 0, . . ., h) provided by 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) D i attempts to obtain the correct attestation key k j to impersonate D j : D i tries to generate a k j on its own.k j = KDF(di l j )(l = h), where di l j = OWF(di l−1 j , ci l j )(l = 1, . . ., h), di 0 j = OWF(uds j , ci 0 j ).Since uds j cannot be accessed outside of the DICE layer of D j , di 0 j cannot be leaked by RV, and di l j (l = 0, . . ., h) cannot be leaked by D j 's layer l (as explained in the following sub-case).Therefore, D i cannot generate a k j .
D i tries to obtain secrets from D j .If the compromised layer l (l = 0, . . ., h − 1) of D j attempts to transmit di l j or di l+1 j , or the compromised layer h attempts to transmit k j to D i , as described in (1), di l j , . .., di h j , or k j will be incorrect.This implies that, under any circumstances, D i cannot obtain the correct attestation key of D j .Therefore, D i cannot successfully impersonate D j .
(3) D i attempts to perform replay attacks: Each attestation request includes a random number vn and each individual report contains a device random number dn i .If D i attempts to replay the report, RV will detect it during the computation of m i .

Performance Evaluation
In our experiment, each device node is simulated by a process, and devices within 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 DN , to assess both its communication volume and aggregation times.

Report Size and Communication Volume
Firstly, the primary communication data between the seed device and 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 200 B, 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 DN is n.An individual attestation report of a device D i is represented as (id i , dn i , t i , cd i ), as described in Section 4.2, and its size is 496B.Without aggregation, the total reports of DN are represented as ( t, î d, dn, ĉd), and their size is 496nB.However, with aggregation, the aggregate report of DN is represented as (T, î d, dn, ĉd), requiring only (464n + 32)B.In practical applications, the network between the seed device and RV is typically a high-load network, and the size of the report is not a significant concern.
Secondly, DN is a resource-constrained network.The hop-byte metric is employed to evaluate the communication volume within 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, D i , a non-leaf node in a spanning tree generated during a complete attestation, with x descendants.Without aggregation, 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 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 DN .Figure 4a illustrates the communication volume within DN under both aggregation and non-aggregation scenarios, across varying numbers of devices.The height of an entire bar represents the communication volume within 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, . . ., 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.

Distributed Aggregation
In the SDATA system, which is inherently distributed, aggregation is performed concurrently across multiple non-leaf devices.The series y (y = 0, . . ., 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 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.

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 RV, necessitating RV to store identifiers of all devices.For a closed scenario, an alternative strategy could be to share only the di 0 1 of the seed device with RV, while other devices use di 0 1 as their unique device secrets.Then, RV can still reconstruct the attestation keys of the devices using di 0 1 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 need for secret sharing.

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.
4) Identify select an aggregate report (T S , îd S , d n S , ĉd S )

Figure 4 .
Figure 4. Evaluation of communication volume and aggregation times.(a) Communication volume.(b) Aggregation times.

Table 1 .
Comparison of TCB requirements.