Método EWA

The main focus of this chapter is the design, implementation and evaluation of our system, and a formalization of our approach is out of scope. We believe however that a formalization of both the security property and the security argument are feasible. In this section, that can safely be skipped by readers not interested in such a formalization, we outline a path towards a formal security proof.

First, the source programming language needs to be formalized. A source

module m declares a name, zero or more identifiers for input channels, and zero

or more identifiers for output channels. For each declared input channel, an event handler to process events arriving on that input channel is defined. A program

p then consists of zero or more modules, and zero or more connections, where

a connection id1→ id2 specifies that the outputs sent on output channel id1

should be delivered to input channel id2. Connections behave as buffered queues.

The input and output channels that are not connected to anything are the

primitive input and output channels of the application. These are the channels

that will be connected to I/O devices on deployment. The semantics of programs is then relatively straightforward: execution is triggered by an event ?id(n) on a primitive input channel. This leads to the execution of the corresponding handler for that event. Execution of this handler generates output events, that can be (1) internal (unobservable, silent) events like internal computation within a module or transmissions over connections between modules, or (2) primitive output events !id(n). On completion of the handler, a next event is handled – either another primitive input event, or one of the transmitted events buffered in one of the connections. Using standard techniques, the semantics of a program can be defined to be a labeled transition system where the labels are events α of the form ?id(n) and !id(n). This labeled transition system defines precisely the traces of events α that a source program p has. We will use the notation

α ↓id to project a trace α to the subtrace that only contains events on channel

id; that is, events of the form !id(n) if id is an output channel and ?id(n) if it

is an input channel.

Second, the runtime infrastructure needs to be modelled, including support for loading, isolating and attesting protected modules, and also including a model of the cryptographic primitives used in our approach. It is less straightforward to build a suitable model here. Important design choices include how to model cryptography (symbolic or computational model) and at what level of detail to model the machine code of protected modules. The semantics of the runtime infrastructure will define exactly when physical input events ?pi(n) and physical output events !po(n) occur.

Third, our approach needs to be formalized as (1) a compiler that compiles source level modules to runtime protected modules, and (2) an implementation of the deployment algorithm on the model of the runtime infrastructure. With

an appropriate model of the runtime infrastructure in place, we expect this to be straightforward.

Fourth, the security property we aim to achieve needs to be formalized. This will look roughly as follows. Let p(ini, outj) be a program with primitive input

channels ini and primitive output channels outj. Deployment connects ini to

physical input channels piiand outjto physical output channels poj. We use the

notation de to relate runtime physical events to the corresponding source-level event, i.e., d?pii(n)e = ?ini(n) and d!poj(n)e = !outj(n). Our security property

now becomes: For the time frame starting at the end of phase 2a of deployment, and ending at a point where the deployer starts a new successful attestation of the protected driver module for poj, let ρoutj be the sequence of output events

on poj. Then p has a trace α such that (1) α ↓outj= dρoutje, and (2) for each

primitive input channel ini, there has been a contiguous sequence of inputs ρini

on pii withα ↓ini= dρinie.

Fifth and finally, the theorem needs to be proven formally. This is likely to be a substantial effort, and hence is out of scope for this thesis, but remains an interesting topic for future work.

Chapter 8

Trust Assessment Modules

for the Internet of Things

In order to benefit from Sancus’ security features, one must annotate the module’s source code and compile it using our compiler (Section 4.2). Although we have tried to make this process as non-intrusive as possible, it might not be feasible to run every software system within a Sancus module. In some cases, for example, the source code might simply not be available to recompile. In other cases, the limit on the number of supported modules (NSM, Section 4.1.1)

may make it impossible to provide protection for all modules that need it. This chapter explores a way to use Sancus to provide security guarantees for software that, itself, is not able to be protected by Sancus. By deploying so-called trust assessment modules alongside unaltered and unprotected code, we are able to measure certain security relevant properties in a secure way. Of course, given our strong attacker model (Section 2.2) and the fact that we do not protect the measured code, the obtained security properties are of a heuristic nature.

8.1

Trust Assessment Modules

Our approach to trust assessment is designed to integrate seamlessly with the deployment of low-cost and low-power hardware in Wireless Sensor Networks (WSNs) and in the IoT. In particular, we make use of a Sancus-enabled CPU to run a protected trust assessment module and to facilitate secure and authenticated communication with a remote operator of this module. This operator can be, for example, a human operator with a particular interest in inspecting a specific device, or a trust management system that keeps track of the integrity and trustworthiness of a larger network of devices. Our

trust assessment module executes as a PM, in isolation from a base of largely unmodified and generally untrusted OS and application code. Yet, our approach partially relies on services provided by this untrusted code, e.g., networking, scheduling and memory management, in a way such that failure is detected by the trust assessment module or by the remote operator. Trust assessment modules are capable of inspecting and modifying the state of the untrusted OS and applications autonomously or on request, giving the operator a trustworthy means of assessing the integrity of the software on a node and to take actions accordingly.

In this section we describe the process of deploying and communicating with Sancus-protected trust assessment modules and discuss inspection targets and trust metrics. We further outline weaknesses and attack scenarios to our approach. While the examples in this section are given with respect to the Contiki OS and its internals, we believe that our approach can be easily adapted to support other OSs in the domain of the IoT, such as TinyOS [57] or FreeRTOS [11].