Source author record

Stefan Hristozov

Stefan Hristozov appears in the imported research catalog. Authorship, coauthor and topic links are available while profile ownership is still unclaimed.

ResearcherUnclaimed source record

Catalog footprint

What is connected

2works
1topics
4close collaborators

Actions

Connect this record

Log in to claim

Research graph

See the researcher in context

Open full explorer

Inspect adjacent papers, topics, institutions and collaborators without losing the researcher page.

Building this map preview

BZPEER is loading the nearby papers, people, topics and institutions for this page.

Published work

2 published item(s)

preprint2022arXiv

A TOCTOU Attack on DICE Attestation

A major security challenge for modern Internet of Things (IoT) deployments is to ensure that the devices run legitimate firmware free from malware. This challenge can be addressed through a security primitive called attestation which allows a remote backend to verify the firmware integrity of the devices it manages. In order to accelerate broad attestation adoption in the IoT domain the Trusted Computing Group (TCG) has introduced the Device Identifier Composition Engine (DICE) series of specifications. DICE is a hardware-software architecture for constrained, e.g., microcontroller-based IoT devices where the firmware is divided into successively executed layers. In this paper, we demonstrate a remote Time-Of-Check Time-Of-Use (TOCTOU) attack on DICE-based attestation. We demonstrate that it is possible to install persistent malware in the flash memory of a constrained microcontroller that cannot be detected through DICE-based attestation. The main idea of our attack is to install malware during runtime of application logic in the top firmware layer. The malware reads the valid attestation key and stores it on the device's flash memory. After reboot, the malware uses the previously stored key for all subsequent attestations to the backend. We conduct the installation of malware and copying of the key through Return-Oriented Programming (ROP). As a platform for our demonstration, we use the Cortex-M-based nRF52840 microcontroller. We provide a discussion of several possible countermeasures which can mitigate the shortcomings of the DICE specifications.

preprint2020arXiv

The Lazarus Effect: Healing Compromised Devices in the Internet of Small Things

We live in a time when billions of IoT devices are being deployed and increasingly relied upon. This makes ensuring their availability and recoverability in case of a compromise a paramount goal. The large and rapidly growing number of deployed IoT devices make manual recovery impractical, especially if the devices are dispersed over a large area. Thus, there is a need for a reliable and scalable remote recovery mechanism that works even after attackers have taken full control over devices, possibly misusing them or trying to render them useless. To tackle this problem, we present Lazarus, a system that enables the remote recovery of compromised IoT devices. With Lazarus, an IoT administrator can remotely control the code running on IoT devices unconditionally and within a guaranteed time bound. This makes recovery possible even in case of severe corruption of the devices' software stack. We impose only minimal hardware requirements, making Lazarus applicable even for low-end constrained off-the-shelf IoT devices. We isolate Lazarus's minimal recovery trusted computing base from untrusted software both in time and by using a trusted execution environment. The temporal isolation prevents secrets from being leaked through side-channels to untrusted software. Inside the trusted execution environment, we place minimal functionality that constrains untrusted software at runtime. We implement Lazarus on an ARM Cortex-M33-based microcontroller in a full setup with an IoT hub, device provisioning and secure update functionality. Our prototype can recover compromised embedded OSs and bare-metal applications and prevents attackers from bricking devices, for example, through flash wear out. We show this at the example of FreeRTOS, which requires no modifications but only a single additional task. Our evaluation shows negligible runtime performance impact and moderate memory requirements.