by Pascal Gremaud, Arnaud Durand and Jacques Pasquier (University of Fribourg, Switzerland)

Cloud-based Internet of Things commercial solutions offer an ever-growing set of possibilities. However, these come at the cost of entrusting data to the platforms running these systems. We explain how Trusted Execution Environments can be used to enforce device and user data confidentiality for an entire ecosystem.

The Internet of Things (IoT) is an ever-growing field, with multiple applications aimed at different types of users. Cloud-based solutions allow users to connect their devices, enabling them to easily set up a rich ecosystem. However, these systems may not only suffer from external attacks, but they are also susceptible to being compromised by internal parties. Indeed, cloud platforms as well as providers of the services running on these platforms have access to all data contained in them. In order to function, these systems rely on their users entrusting data to these companies, simply because so far there is no alternative to this security model.

Our project is centred around a simple idea: at no point in time should data be accessible by any party other than its owners, unless specified by the owners themselves. Based on this principle, we are aiming to create a complete IoT ecosystem designed for smart home applications and connected appliances in general. Such a security requirement can easily be met by services such as messaging or data storage, since data is not processed by non-trusted parties. However, the strength of a typical IoT ecosystem is precisely the ability to enable complex interactions between multiple devices and users, which requires data processing. Because we target non-expert users, an easily deployable, cloud-based solution is a must for achieving our goal.

Our ecosystem, shown in Figure 1, relies on Intel’s Software Guard Extensions (SGX) to protect data on a cloud platform. This set of instructions allows the creation of a memory-protected region, called an enclave. In our project, this enclave is responsible for client registration and authentication, as well as data processing. In order to ensure privacy in this cloud environment, all data passing to and from the enclave are encrypted. A web server is responsible for passing client messages to the enclave, and for sending responses. We use application-layer encryption to guarantee that transiting data cannot be accessed either by an external attacker, or by the cloud platform provider (including when being treated by the web server). We designed a simple protocol on top of HTTP in order to easily communicate with web clients. Our system is also capable of using the Object Security for Constrained RESTful Environments (OSCORE) protocol, the use of which we evaluated in the context of secure IoT [1]. Both these protocols use a RESTful API exposed by the middleware platform to interact with it.

Figure 1: The architecture of the ecosystem. Components in shades of blue are considered trusted.
Figure 1: The architecture of the ecosystem. Components in shades of blue are considered trusted.

We store data in two different ways, depending on the type of data. An in-memory database running inside the enclave is used to store data related to the middleware model, such as clients, event types, rules, etc. An encrypted backup of this database is saved outside the enclave in case of a system reboot. A second database running outside the enclave is responsible for archiving encrypted past messages and can be used to get the history of the system’s events. Our system uses a simple Event-Condition-Action (ECA) engine adapted from the iFLUX middleware model [2] as its rules engine. An ECMAScript engine running inside the enclave allows middleware rules to be defined as scripts, enabling rich interactions between devices and complex scenarios. For instance, a user can set smart radiator valves to stop heating their home when it is assumed that the house is vacant. A combination of the user’s phone not being connected to their home WiFi network and deductions based on their online planner can be used as a condition for this scenario.

Client registration and authentication is performed using a simple Public Key Infrastructure (PKI). The owner of the system (one of its users) creates a self-signed certificate that is distributed to each client, including the enclave. This special user acts as the root of trust for the entire system. The enclave acts as a Certification Authority (CA), and is able to issue new certificates to clients and verify them when authenticating. The creation and modification of middleware logic resources (clients, rules, event types, etc.) are performed via web or mobile clients. Complex IoT scenarios can be proposed by third parties in the form of predefined configuration files, and then instantiated using a dedicated web client. Because all the interaction with the enclave are done using this client, there is no need to grant any data access to these third parties.

One key point of the system is the ability to attest that the enclave code corresponds to the users’ expectations. Intel proposes a remote attestation mechanism to comply with this requirement. Before the verification, the public certificate of the system owner is placed in the enclave, which ensures that this particular enclave instance is linked with that specific user.

Using the architecture we described, our ecosystem is able to achieve both a high level of data security and an ease of use and deployment for non-experienced users. We plan on extending the system features and creating real-life scenarios by deploying devices using a dedicated firmware to interact with our system. We believe that such systems will become a suitable response to security concerns that arise with the vast amount of data used in the IoT. We hope to see a growing interest in similar projects in the near future. Updates on the project can be found at [L1].

Links:
[L1] https://www.unifr.ch/inf/softeng/en/research/topics/iot-privacy.html

References:
[1] A. Durand et al.: “Trusted lightweight communication for IoT systems using hardware security”, in: Proc. of the 9th Int.Conference on the Internet of Things, 2019.
[2] O. Liechti et al.: “Enabling reactive cities with the iFLUX middleware”, in: Proc. of the 6th Int. Workshop on the Web of Things,2015.

Please contact:
Pascal Gremaud
University of Fribourg, Switzerland
+41 79 454 41 20
This email address is being protected from spambots. You need JavaScript enabled to view it.

Next issue: January 2022
Special theme:
"Quantum Computing"
Call for the next issue
Image ERCIM News 126
This issue in pdf

 

Image ERCIM News 126 epub
This issue in ePub format

Get the latest issue to your desktop
RSS Feed