RADIS: Remote Attestation of Distributed IoT Services

07/26/2018 ∙ by Mauro Conti, et al. ∙ Università di Padova Sapienza University of Rome 0

Remote attestation is a security technique by which a potentially untrusted device called Prover can evidence its current state to an external trusted party called Verifier. The main goal of a remote attestation protocol is to guarantee the reliability of the evidence, such that the Verifier can verify remotely the trustworthiness of the Prover. In the Internet of Things (IoT) systems, which are increasingly becoming exposed to a broad range of exploitations, the existing remote attestation protocols aim to check the integrity of each individual IoT device by detecting the modified softwares and physical tampering attacks. However, in an interconnected IoT system, in which IoT devices interact autonomously among themselves, a compromised IoT service can influence the genuine operation of other invoked service, without changing the software. In this paper, we show how a compromised service in a distributed IoT service can induce malicious behavior on genuine services, and we highlight the need for distributed services attestation. We propose a protocol for Remote Attestation of Distributed IoT Services (RADIS), which provides a complete evidence about the trustworthiness of distributed IoT services. RADIS relies on a control-flow attestation technique to detect IoT services that perform an unexpected operation due to their interactions with a malicious remote service. Additionally, RADIS traces the interactions between IoT distributed services, allowing the Verifier to check whether the activities follow a legitimate interaction model. We discuss the effectiveness of our protocol in validating the integrity status of a distributed IoT service.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

Interoperability of IoT systems is estimated to create 40 percent of the potential value that can be generated by the Internet of Things in various settings

[1]. Ability of IoT devices to connect and communicate among themselves allows IoT systems to deal with a variety of complex operations that exceed the constrained resources of individual IoT devices. However, the limited capabilities of the IoT devices to adopt traditional security techniques exposes IoT systems to a huge number of potential attacks [2, 3, 4]. Thus, a security mechanism that guarantees the secure interaction between devices plays a key role in establishing trust in an IoT system.

Remote attestation has emerged as a security mechanism that provides evidence about the trustworthiness of a device. The goal of a remote attestation protocol is to provide some unforgeable evidence to a remote trusted entity, called Verifier, to testify the authenticity and integrity of the internal state on an untrusted platform, called Prover. Typically, the internal state of resource-constrained devices comprises the program binaries stored in the program memory of the device and the runtime state of the software stored in data memory. During a normal software execution, the content of the program memory remains static, whereas the data memory’s contents always change. While existing remote attestation protocols differ in the parts of the device’s memory that they consider during the verification process and hardware assumptions, most of the existing attestation protocols verify only the program memory of a prover [5, 6, 7]. These protocols provide a checksum only for the program binaries loaded on the prover’s program memory. The biggest drawback of these protocols is the lack of capability to detect prevalent runtime software attacks that target data memory of the devices [8]. These protocols do not guarantee the software integrity against an adversary that performs code reuse attack by exploiting memory corruption vulnerabilities to deviate an intended control-flow of a software by only changing the control-flow pointers at the runtime of an existing code, or non-control data attacks by manipulating some variables that make the control flow to follow a valid but non authorized direction. To mitigate the runtime attacks, some other attestation approaches have emerged in checking the correctness of the application during the execution time [9, 10, 11]. However, existing remote attestation schemes do not consider an interoperable IoT system, in which a compromised distributed service can impact the integrity of other devices of the distributed IoT services that interact with the malicious remote service.

Our Contribution: In this paper, we propose RADIS, a remote attestation protocol for distributed IoT services. The contributions of this paper are threefold:

  • We highlight the need for a distributed services attestation.

  • We define the required security properties for a distributed IoT service setting, and describe the adversary model.

  • We present a remote attestation protocol that ensures the integrity of all the services involved in the execution of a distributed IoT service.

Outline: The rest of the paper is organized as follows. In Section II, we provide an overview of the current state-of-the-art remote attestation approaches and provide a comparison with our work. We describe the problem in Section III while in Section IV we present the system model. In Section V, we describe the adversary model and define the required security properties. We introduce the preliminary concepts in Section VI and provide our protocol details in Section VII. Finally, we provide qualitative evaluation in Section VIII and the paper concludes in Section IX.

Ii Related Works

In this section, we provide an overview of previous work related to remote attestation protocols. We focus particularly on attestation of distributed services in traditional systems and state-of-the-art remote attestation protocols in IoT systems.

The work in [12] proposes BIND as a fine-grained attestation scheme for traditional distributed systems. BIND assumes that the most critical parts of the service software are predefined by programmers. Thus, in the attestation time, instead of attesting the code for the entire sequence of the distributed services, BIND attests only the selected piece of code for each service. BIND measures a critical code immediately before entering in the code execution and uses a sand-boxing mechanism to serve as a protection for ensuring the untampered code execution. However, BIND does not address attacks that happen in the intermediary code that is not annotated for attestation. In our protocol, the runtime attestation takes into consideration all the software of the service without limiting the attestation only to predefined section of code. The authors in [13] present a integrity attestation that aims to check whether a subroutine of a program is executed correctly. The proposed scheme leverages Trusted Computing Group (TCG) attestation to build a trust chain rooted at Trusted Platform Module (TPM) for function execution. The attestation schemes presented in [12] and [13] are not designed for resource-constrained devices.

In IoT systems, collective attestation schemes aim to verify the internal state of a large group of devices in a more efficient way than attesting each of devices individually. The attestation approach proposed in SEDA [14] constructs the interconnected network as a spanning-tree. In this scheme, each device statically attests its children and reports back to its parent the number of children that successfully passed the attestation protocol. In the end, an aggregated report with the total number of the devices successfully attested will be transmitted to the Verifier. The weakest point of this protocol is that a compromised node can impact the integrity of the attestation result of all its children nodes in the aggregation tree. This problem is tackled by SANA [15], which relies on the use of a multi-signature scheme to propose a scalable attestation protocol with untrusted aggregators. Here, devices sign the attestation responses and an aggregation of the signatures is used to validate the network in a constant time. The basic assumption followed by both SEDA and SANA is that the network is fully interconnected. The work in [16] rules out this assumption and proposes an efficient protocol for highly dynamic networks. In this proposal, each device performs the local attestation at the same point in time and shares the individual result with other devices in the network. Then, devices use the consensus algorithm to gain knowledge about the state of the other devices in the network. At the attestation time, the verifier can perform the attestation over a random device, which will report the consensus state of the entire network. However, the collective attestation schemes do not consider the flow of the interactions between devices and the data flow that goes from one device to another. Therefore, these schemes detect devices that are running a modified software, but they do not check whether the devices with legitimate software are executing a task on malicious data. We argue that, in a distributed system, a service victim of a run-time attack can propagate malicious behavior to all the devices that requested that service, even though the software running on those devices is legitimate. Additionally, the existing collective attestation schemes verify only the integrity of the static program memory without providing a validation mechanism for the data memory. Thus, runtime attacks remain undetected.

Dynamic attestation approaches aim to verify the run-time state of the Prover during the normal software execution. The work in [9] proposes ReDAS as an attestation protocol that verifies the properties of the run-time behavior of the Prover. When any of the properties is violated, ReDAS stores the relevant evidence in a Trusted Platform Module (TPM). ReDAS checks the system integrity only at system calls, and it traces only the order of the launched modules in a system. Therefore, it does not detect the malware presence between system calls, and it does not check the runtime flow of the instructions of a specific module. C-FLAT [10] proposes a complete attestation of the run-time state of the Prover. During the execution, each software instruction is reported into a so-called “trusted anchor” and from there, a hash engine mechanism accumulates the sequence of the instructions into a single hash value that represents the entire control flow of the Prover’s state. A Verifier, who has initially computed and stored a set of all the possible valid hashes of the Prover, can detect control-flow attacks, since a Prover targeted with a control-flow run-time attack will report an unexpected hash value to the Verifier. A practical version of C-FLAT is introduced in LO-FAT [17]. Instead of the software instrumentation used in C-FLAT, LO-FAT explores the features of the microcontroller to intercept the instructions, providing in this way an implementation of C-FLAT with low overhead. ATRIUM [11] proposes a hardware based runtime attestation protocol that is resilient against Time of Check Time of Use attacks. ATRIUM attests both executed instructions and the control flow.

However, the existing dynamic attestation protocols follow the one-device-attestation approach and do not provide a complete evidence about the integrity of the services that compose a distributed IoT system.

Iii Problem Setting

Fig. 1: Service Flow of IoT devices

In a heterogeneous IoT system, some of the devices can operate both as clients and servers, and these devices interact among themselves through their available services in the network. A conceptual view of these interactions is illustrated in Figure 1. Here, each of the devices shown in Level 1, , , and provide a set of services, as represented in Level 2. In this setting, the execution of a complex operation, which is beyond the capacities or functionalities of a single device, requires the invocation of a remote service provided by other devices. Likewise, the called service might still be too complex for the resources of a device, and therefore it invokes other service calls to complete its task. The sequence of all the services involved in fulfilling an operation is called Service Flow, and the notation for the Service Flow depicted in Figure 1 is . Also, the set of services communicating with each other to support the operation form a distributed service. Note that a given distributed service can follow a different service flow based on different invocations, depending, for example, on the input parameters.

In the following, we consider the interoperation between services in a Smart Home IoT system enabled by the communication of three IoT devices: an Outdoor Camera, a central Security Monitor, and a Smart Door. A motion sensing Outdoor Camera observes outside the main door of the home, and when any movement of objects or people is detected, the camera captures an image and reports it to a Security Monitor. Once the Security Monitor gets the captured image, it analyzes the image, and if it identifies a family member, it sends an unlock command to open the Smart Door, as shown in Figure 2. The service flow in this scenario is: .

Devil’s Ivy attack [18] shows how an attacker exploits a vulnerability in a widely used library to take control over a security camera. Here, the attacker uses Return-Oriented Programming (ROP) technique [19] to change at runtime the execution flow of genuine pieces of code loaded on the device’s memory and, consequently, produce a malicious code. As these attacks can become pervasive in IoT systems, a prominent requirement for the attestation schemes is the detection of run-time attacks, which target the data memory and do not modify the program memory of a device. The attestation of data memory of individual devices requires the execution of a single-device attestation protocol that detects subverted control flows. One possible example of such attestation protocol is C-FLAT [10]. In the case the device is not compromised, a control-flow attestation protocol, running on a single device, will report the benign state of the device. For instance, when a single-device control-flow attestation protocol attests a genuine Smart Door, it will ensure its correctness.

Fig. 2: Device interaction in Smart Home IoT System

Now, consider an attack scenario where an adversary subverts the control-flow of another device of the distributed service, e.g., the Security Monitor device. After this attack, a single-device control-flow attestation procedure executed on the Smart Door will report again the correctness of the Smart Door. This is because the adversary has not changed the software of Smart Door and has not deviated its control-flow. However, even though the adversary is located only in the Security Monitor and the Smart Door passes all the checks of the control-flow attestation procedure, we show that the Smart Door can be forced into an incorrect state.

By changing the control-flow of the Security Monitor device, the adversary is able to generate malicious software executions on the Security Monitor that can produce malicious data, and can influence the current behavior of the other interconnected devices. As a consequence, the state of the Smart Door may be corrupted by the commands invoked maliciously from the Security Monitor to the Smart Door. For example, an command initiated as result of a control-flow attack can open the door even if the camera has not captured the image of a family member. We thus argue that the Smart Door may have a genuine software, but its behavior is not legitimate if it is performing an unexpected operation due to the command or input that it received from a malicious code executed in the Security Monitor device.

One could think to detect this attack by running a single-device control-flow attestation protocol on every device of the IoT system. Indeed, the evaluation of the results of control-flow attestation protocols, running on each individual IoT device, will report the malicious devices in the network. For example, the results of control-flow attestation protocols, running on each on the three devices of our scenario, would report the Security Monitor as a compromised device and the Smart Door in a legitimate state. However, control-flow attestation protocols, running on every device, cannot detect the devices that have been influenced by the attacker and forced into an incorrect state.

Device : Outdoor Camera Device : Security Monitor Device : Smart door
1:  captureImage() { 2:   3:  if  then 4:      5:      6:  end if 7:  } 1:  checkImage(img) { 2:   3:   4:  if  is false then 5:      6:      7:  else 8:      9:      10:  end if 11:  } 12:  service: 13:  service: 1:  unlockDoor(cmd) { 2:  if  is true then 3:      4:  else 5:      6:  end if 7:  } 8:  service: 9:  service:
: captureImage() : checkImage() : unlockDoor()
Fig. 3: Pseudo-code of the service flow in Fig.2

To explain the details how the run-time attack occurs, Figure 3 illustrates the pseudo-code of the three services involved in the aforementioned service flow: . Based on the instructions of this pseudo-code, for each service a Control Flow Graph is constructed, where each instruction is presented as a node of the graph, as shown in Figure 4. During the normal operation, each service follows the intended control-flow and then invokes a service call to the next device.

The adversary located in Security Monitor ( ) performs a control-flow attack by changing the pointer between two nodes of the Control Flow Graph ( goes into instead of going into ), as shown in Figure 4. Note that when the execution flow reached at Node , the variable was assigned as “”. The malicious alteration prevents the execution of in Node and maliciously redirects the execution to Node , which assigns the variable with the value “”, and then proceeds to Node to call the service . This control-flow attack has two potential effects. First, the compromised argument , produced by the subverted control-flow in Security Monitor, is used in node of Smart Door ( ) as a decision-making variable that defines the further operations of Smart Door. This means that Smart Door, even though is running a genuine software, can maliciously run command in Node because of the compromised argument received. Second, the malicious subversion of the control-flow to Node changes also the control-flow of the interaction between services since the instruction in Node is not executed. Specifically, instead of calling the device that provides the service , which may report an alert on the smartphone of the owner, the Security Monitor will call the command in the Smart Door. This run-time attack shows that a compromised device ( ) induces a malicious behavior into a subset of IoT devices, even though the software running on the subset of the devices is not altered in any way by the attacker. Therefore, to produce a correct attestation response of a distributed service, the attestation scheme is required not only to report the device running the malicious code, but also to verify all other devices which interact with the infected device and are performing a non-intended operation due to their interactions with the infected device.

Fig. 4: Control flow of the distributed service in Fig.2

Iv System model

We consider a distributed IoT system, where each heterogeneous IoT device provides a number of services, each uniquely identified as where . In a typical distributed IoT service, each service invokes an explicit service request to another service according to a predefined interaction model. At runtime, a distributed IoT service may follow various service flows, thus, the aim of the attestation mechanism is to check the integrity of a distributed service by verifying that a given service flow is legitimate. In modeling the attestation scheme of a distributed IoT service, we consider the presence of the following entities:

  • Device : a number of interconnected devices that compose a distributed IoT system. Each device hosts different services, which can be identified in the distributed system by a unique name , for .

  • System operator : responsible for the trusted deployment of the distributed IoT system.

  • Verifier : a trusted external party who checks the integrity of a service flow of the distributed IoT system. may be different from . has access to the binaries of all the services deployed on the distributed IoT system. The attestation runs periodically at an arbitrary time determined by .

Fig. 5: System model of remote attestation of a distributed IoT service, which consists of two services and .

Initially, an IoT system operator validates the identities of the devices, authorizes their access, and verifies the correct version of the software and services available on them. Then, a Verifier , responsible for the integrity check of the distributed services, performs an offline procedure to measure all genuine services that compose the distributed IoT system. During the service measurement procedure, considers the legitimate service flows and all possible legitimate control-flows of the genuine services that compose a service flow. Next, generates the measurement for each service flow, and at the end of this procedure, stores in a database a single hash value for each legitimate service flow. A conceptual overview of our system model is depicted in Figure 5.

At the attestation time, sends an attestation request 1⃝ to the device hosting the first service of a given service flow. Upon receiving the attestation request, the device initiates attestation process for the intended service 2⃝. Every service call invocation includes the attestation result of the calling service. This process binds all the services attestation reports generated through the entire service flow 2⃝ - 6⃝. After completion, the first service of the service flow sends to the final attestation report of the entire service flow 7⃝. In the end, validates the received result with the known measurements stored previously in the database 8⃝. If the final attestation result matches with one of the pre-calculated values, ensures that the service flow is in the legitimate state. Otherwise, the service flow is compromised.

V Adversary model and Security Requirements

V-a Adversary model

The main goal of an adversary is to compromise the execution of a distributed IoT service to influence its results maliciously. Thus, the aim of remote attestation is to detect the distributed services which are compromised or maliciously influenced by . We consider the following possible actions of an against distributed IoT services:

Software adversary

can compromise the binaries of the services, can inject malicious code in the free space of the program memory of a device, or can exploit a service vulnerability to manipulate the data memory of a device at runtime. Additionally, can forge the attestation result by managing to produce a valid result despite the software modifications present on the device.

Man-in-the-middle (MITM) attack

can eavesdrop on and alter the communication data between services. will be particularly interested to alter the communication data in such way that it will change the intended control-flow of the invoked service.

Replay attack

precomputes the operations of the attestation procedure, and reports to a previous valid response which hides the attack.

Assumptions

Like in other attestation schemes, we rule out physical attack, and we assume that a software adversary cannot compromise hardware-protected memory. While we do not consider Denial of Service (DoS) attacks, we limit these attacks by using symmetric key for the service invocations, thus, a device does not perform intensive computations to refuse a fake service request. We also assume that software attacks and Man in the middle (MITM) attacks impact the control-flow of a service software. Furthermore, we assume that services will respond during the attestation procedure. However, since RADIS includes the attestation result in the service invocations, typically a non responding service will generate a timeout message. Consequently, the final attestation result will not comprise the information about the non responsive service.

V-B Security requirements

In order to be resilient to the above attacks, the remote attestation scheme of distributed services should satisfy the following security properties:

  • Authenticity and integrity of services: The attestation scheme should perform software integrity verification of a distributed service to guarantee that the distributed service has not been modified by any software adversary. In particular, the protocol should provide authentic and reliable evidence to prove that at runtime a distributed service has followed a legitimate control-flow. The attestation scheme should guarantee the integrity and authenticity for each of the services that compose a distributed service.

  • Integrity of communication data: The attestation scheme should detect the compromised state of distributed services when a MITM attack, which alters the communication data between two distributed services, causes the invoked service to execute a non-intended control-flow.

    Each distributed service should be able to verify the trustworthy origin of the its inputs, and it should reject any service calls invoked by an unauthorized device.

  • Freshness: To be resilient to replay attack, any service should not be able to reply to the attestation request of with a precomputed value that could hide an ongoing attack on the service. Likewise, an invoked service should prove to the calling service the freshness of the response it provides to the caller.

Vi Preliminaries

In order to achieve all security properties described above, our attestation scheme requires the following components.

  • Signature scheme: A signature scheme is a pair of algorithms: a signature algorithm and a verification algorithm . The signature algorithm takes as input a message and a secret signing key and outputs a signature . The verification algorithm verifies whether is valid or invalid on input of a message , a signature , and a public verification key .

  • Message authentication code: A Message Authentication code (MAC) is a pair of polynomial time algorithms and such that outputs a MAC tag on input of and , and verifies on input of and .

  • Graph hashing: A Control Flow Graph represents the legitimate execution flows of a given software. For instance, Figure 6 depicts two valid execution flows: and , where each graph node .. denotes a software instruction. We borrow the hash engine from C-FLAT, which associates each valid execution flow of a single device with a unique hash value, computing = . For example, Figure 6 shows = , and the final hash value represents the hash value for each of the two legitimate execution flows.

    Fig. 6: Hashing Control Flow Graph in C-FLAT
  • Device requirements: Each device deployed in a distributed service is equipped with a trusted anchor . A trust anchor is a lightweight hardware component which provides an isolated measurement engine. This trusted component cannot be disabled or modified by non-physical means.

Vii RADIS: Our proposal for remote attestation of distributed IoT services

We now describe RADIS, our remote attestation protocol for distributed IoT services.

RADIS has two main operation modes: setup mode and attestation mode. Setup mode is an initial procedure, executed only once, which allows trustworthy execution of the remote attestation protocol. Attestation mode is a periodical procedure initiated by at an arbitrary time. In Table 1, we summarize the terms used in RADIS.

Term Description
System Operator
Verifier of a distributed IoT system
Secret key of
Public key of
Device
Prover
Trusted anchor of
Secret key of
Public key of
Symmetric key shared between and
Unique name of a service running on
Service Flow Graph
Local Hash Value of the software execution
flow for the current service running on
Global Hash Value stored in for
the control-flow execution of a service flow
Procedure Description
generates MAC tag on
verifies MAC tag on using
encrypts message using a secret key
verifies on using public key
performs attestation for a given service
sends attestation request between two services
reports attestation result from invoked service
to calling service
retrieves the attestation response from invoked
service to calling service
TABLE I: Notation Summary

Vii-1 Setup mode

Setup mode includes two operations: key setup and service measurement, executed respectively by and .

Key setup

To establish a secure communication between and , each deployed device knows ’s public key and owns an asymmetric key-pair . In addition, two devices and that will interact during the normal operations in the network establish a shared symmetric attestation Message Authentication Code (MAC) key . The secret signing key and the shared attestation key are both protected within the trust anchor , preventing untrusted parties from using these keys. Alternatively, as a lightweight key exchanging scheme between devices can be used a random key predistribution scheme [20], [21], [22] which rely on probabilistic key sharing among devices. The basic idea is that each device is initialized with keys, selected from a large pool of keys, such that two random subsets of size in

will share at least one key with some probability

. Next, devices will perform shared-key-discovery to find out with which of other device they share a key. Afterwards, a challenge-response can be used to two devices that share a common key. Note that the key setup process between devices is managed by , and this paper assumes that two device and share a symmetric key without providing details about the key management scheme.

Service measurement

Service measurement is one-time-only procedure that performs offline to measure the legitimate service flows of a distributed service. Service measurement procedure follows the assumption that has access to the binaries of all the services and knows in advance the legitimate interactions between IoT devices. First, builds a graph, in which the nodes represent services and the edges determine the execution order of the services in a distributed service. Next, builds the Control Flow Graph of every service and builds a Service Flow Graph (SFG) to represent all the possible valid transitions that a distributed service may follow at runtime. Then, starting from each valid transition, executes a measurement function to associate each legitimate service flow with a single hash value as shown in Figure 7. Finally, stores all the generated hash values in a database. Although the measurement of the Control Flow Graph can introduce high complexity, typically an IoT service is expected to be less complex than traditional applications, and has sufficient processing resources. Moreover, since performs offline the software measuremens, the complexity of software measurement does not impact the performance of the remote attestation procedure.

Fig. 7: Hashing procedure for a legitimate Service Flow

Vii-2 Attestation mode

Fig. 8: The attestation protocol

To check the integrity of all the services that compose a distributed service, RADIS uses two components: Local Hash Value () to record the local execution flow of a given service and Global Hash Value () to record the entire transition of a service flow. and are both protected in .

The attestation procedure starts with who sends an attestation request , where is the name of the service to be attested, is the initial input for the given service , is a randomized nonce to ensure the freshness of the communication, and is ’s signature over , and (as shown in Step 1⃝ in Figure 8). Upon receiving the attestation request , the device , which serves as a prover , verifies the signature by using the ’s public key . If the signature is valid, RADIS protocol, which is running on , invokes the procedure (Step 2⃝) to attest with the provided input . Since is the first service of the service flow, will be initialized with 0. The invocation of triggers to trace the execution flow of , to compute a hash value for each instruction, and to store the accumulated hash value in . The single hash value accumulated in represents the complete runtime state of . After all the instructions are measured, updates the value of with the computed hash .

When invokes another service , the code of that handles the service invocation will be attested by the method (Step 3⃝). Among the arguments of the service call, the service invocation will also include the attestation result of and a nonce to initiate the attestation for . Specifically, to initiate the request, computes a MAC signature over the message = , , , , where is the name of the invoked service, is the output which serves as input data in the service call, is the attestation result of registered in , and is a randomized nonce. On receiving the service request, uses to verify the MAC signature and prove the authenticity and integrity of the request.

In case the service call is valid, RADIS protocol running on starts the attestations for by calling (Step 4⃝) on the received input data. The code of which handles the response will be attested by (Step 5⃝). In details, returns a MAC signature over = , , , where is the randomized nonce, is the output data produced by the execution of , and is the hash value of the attestation protocol. Next, handles the response of by calling (Step 6⃝) and updates with the hash value produced by . After processing the response, in the case continues the execution of some more lines of code, RADIS will trigger to attest the code or will call again and if invokes other service calls.

Upon the completion of service execution for each of the service that compose a service flow, retrieves stored locally, and it sends back to the signed attestation result = (Step 7⃝). verifies the signature of the response and then proceeds with hash validation. Since has initially stored the valid hash for each service, to validate the attestation response, checks in the database whether is among the legitimate hash values saved in the database. If it matches with the hash value of reported by , then serves as as an evidence that proves that each service that composes the service flow is legitimate.

Viii Qualitative evaluation

Regardless of the number of services that compose a service flow, the attestation result that will be invoked in the service call is always a single hash value. Therefore, the overhead of invoking the attestation result in a service call is constant in the number of services that compose a given service flow. In addition, the complexity of attestation for each service that composes a given service flow is linear to the number of control-flow instructions that the service has to execute.

In practice, RADIS requires code instrumentation to allow the instructions to be intercepted by a trampoline and then processed by a trusted hash engine, following the design of [10]. In addition, RADIS requires an enhancement of the instrumentation mechanism in order to intercept the service call and initialize the measurement engine with the attestation result of the calling service. Therefore, RADIS introduces an additional overhead due to context switch on intercepting the instructions and the service calls. However, the overhead of intercepting the software instructions with code instrumentation can be reduced by using a trusted hardware component to intercept the control-flow as shown in [17]. In the verification process of a given service flow, ensures the trustworthy state of all the services that compose that service flow by comparing one single hash value with the known measurements previously stored in database.

Ix Conclusions

While IoT systems become interoperable, an important challenge for the remote attestation schemes is to guarantee the trustworthy state of the IoT services that compose a distributed service. Secure interaction between devices is a key issue in IoT systems, and in this paper, we emphasize the need of a distributed services attestation in IoT systems. We presented a protocol that provides a comprehensive and reliable integrity check of a distributed service. Our solution gives evidence about the trustworthiness of the services that compose a distributed services and the interaction flow between services.

References

  • [1] M. . Company, “The internet of things: Mapping the value beyond the hype,” http://www.mckinsey.com/, June 2015, [Online; accessed 15-December-2017].
  • [2] KrebsonSecurity, “Mirai Botnete,” http://krebsonsecurity.com/tag/mirai-botnet, October 2016, [Online; accessed 15-December-2017].
  • [3] E. Fernandes, J. Jung, and A. Prakash, “Security analysis of emerging smart home applications,” in 2016 IEEE Symposium on Security and Privacy (SP).   IEEE, may 2016. [Online]. Available: https://doi.org/10.1109/sp.2016.44
  • [4] E. Ronen, A. Shamir, A.-O. Weingarten, and C. OFlynn, “IoT goes nuclear: Creating a ZigBee chain reaction,” in 2017 IEEE Symposium on Security and Privacy (SP).   IEEE, may 2017. [Online]. Available: https://doi.org/10.1109/sp.2017.14
  • [5] S. Kiyomoto and Y. Miyake, “Lightweight attestation scheme for wireless sensor network,” vol. 8, pp. 25–40, 03 2014.
  • [6] X. Yang, X. He, W. Yu, J. Lin, R. Li, Q. Yang, and H. Song, “Towards a low-cost remote memory attestation for the smart grid,” vol. 15, pp. 20 799–20 824, 08 2015.
  • [7] A. Ibrahim, A.-R. Sadeghi, G. Tsudik, and S. Zeitouni, “Darpa: Device attestation resilient to physical attacks,” in Proceedings of the 9th ACM Conference on Security & Privacy in Wireless and Mobile Networks, ser. WiSec ’16.   ACM, 2016, pp. 171–182. [Online]. Available: http://doi.acm.org/10.1145/2939918.2939938
  • [8] C. Castelluccia, A. Francillon, D. Perito, and C. Soriente, “On the difficulty of software-based attestation of embedded devices,” in Proceedings of the 16th ACM Conference on Computer and Communications Security, ser. CCS ’09.   ACM, 2009, pp. 400–409. [Online]. Available: http://doi.acm.org/10.1145/1653662.1653711
  • [9] C. Kil, E. C. Sezer, A. M. Azab, P. Ning, and X. Zhang, “Remote attestation to dynamic system properties: Towards providing complete system integrity evidence,” in 2009 IEEE/IFIP International Conference on Dependable Systems & Networks.   IEEE, jun 2009. [Online]. Available: https://doi.org/10.1109/dsn.2009.5270348
  • [10] T. Abera, N. Asokan, L. Davi, J.-E. Ekberg, T. Nyman, A. Paverd, A.-R. Sadeghi, and G. Tsudik, “C-FLAT: Control-Flow Attestation for Embedded Systems Software,” in Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security - CCS ’16.   ACM Press, 2016. [Online]. Available: https://doi.org/10.1145/2976749.2978358
  • [11] S. Zeitouni, G. Dessouky, O. Arias, D. Sullivan, A. Ibrahim, Y. Jin, and A. R. Sadeghi, “Atrium: Runtime attestation resilient under memory attacks,” in 2017 IEEE/ACM International Conference on Computer-Aided Design (ICCAD), 2017, pp. 384–391.
  • [12] E. Shi, A. Perrig, and L. V. Doorn, “BIND: A Fine-Grained Attestation Service for Secure Distributed Systems,” in 2005 IEEE Symposium on Security and Privacy (SP).   IEEE, may 2005. [Online]. Available: https://doi.org/10.1109/sp.2005.4
  • [13] L. Gu, Y. Cheng, X. Ding, R. H. Deng, Y. Guo, and W. Shao, “Remote Attestation on Function Execution (Work-in-progress),” in Proceedings of the First International Conference on Trusted Systems on - INTRUST ’09.   Springer-Verlag, 2010.
  • [14] N. Asokan, F. Brasser, A. Ibrahim, A.-R. Sadeghi, M. Schunter, G. Tsudik, and C. Wachsmann, “SEDA: Scalable Embedded Device Attestation,” in Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security - CCS ’15.   ACM Press, 2015. [Online]. Available: https://doi.org/10.1145/2810103.2813670
  • [15] M. Ambrosin, M. Conti, A. Ibrahim, G. Neven, A.-R. Sadeghi, and M. Schunter, “SANA: Secure and Scalable Aggregate Network Attestation,” in Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security - CCS ’16.   ACM Press, 2016. [Online]. Available: https://doi.org/10.1145/2976749.2978335
  • [16] M. Ambrosin, M. Conti, R. Lazzeretti, M. M. Rabbani, and S. Ranise, “Toward secure and efficient attestation for highly dynamic swarms,” in Proceedings of the 10th ACM Conference on Security and Privacy in Wireless and Mobile Networks - WiSec ’17.   ACM Press, 2017. [Online]. Available: https://doi.org/10.1145/3098243.3106026
  • [17] G. Dessouky, S. Zeitouni, T. Nyman, A. Paverd, L. Davi, P. Koeberl, N. Asokan, and A.-R. Sadeghi, “LO-FAT: Low-Overhead Control Flow ATtestation in Hardware,” in Proceedings of the 54th Annual Design Automation Conference 2017 on - DAC ’17.   ACM Press, 2017. [Online]. Available: https://doi.org/10.1145/3061639.3062276
  • [18] Senrio, “Devil’s Ivy,” http://blog.senr.io/blog/devils-ivy-flaw-in-widely-used-third-party-code-impacts-millions, July 2017, [Online; accessed 15-December-2017].
  • [19] H. Shacham, “The geometry of innocent flesh on the bone,” in Proceedings of the 14th ACM conference on Computer and communications security - CCS ’07.   ACM Press, 2007. [Online]. Available: https://doi.org/10.1145/1315245.1315313
  • [20] L. Eschenauer and V. D. Gligor, “A key-management scheme for distributed sensor networks,” in Proceedings of the 9th ACM Conference on Computer and Communications Security, ser. CCS ’02.   New York, NY, USA: ACM, 2002, pp. 41–47. [Online]. Available: http://doi.acm.org/10.1145/586110.586117
  • [21] J. M. Kahn, R. H. Katz, and K. S. J. Pister, “Next century challenges: Mobile networking for “smart dust”,” in Proceedings of the 5th Annual ACM/IEEE International Conference on Mobile Computing and Networking, ser. MobiCom ’99.   New York, NY, USA: ACM, 1999, pp. 271–278. [Online]. Available: http://doi.acm.org/10.1145/313451.313558
  • [22] H. Chan, A. Perrig, and D. Song, “Random key predistribution schemes for sensor networks,” in Proceedings of the 2003 IEEE Symposium on Security and Privacy, ser. SP ’03.   Washington, DC, USA: IEEE Computer Society, 2003, pp. 197–. [Online]. Available: http://dl.acm.org/citation.cfm?id=829515.830566