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

Abstract

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.

Profiling with Trust: System Monitoring from Trusted Execution Environments

“…Hardware Watchdog: Hardware watchdogs are widespread on IoT devices and are an established mechanism to react to a critical event [63][64][65][66]. We ensure that the TM TA is scheduled regularly by employing a hardware watchdog in the secure world.…”

A TOCTOU Attack on DICE Attestation

“…However, if the device runs malware the malware may ensure that the device never resets. In order to overcome this problem, an additional mechanism is required allowing the backend to enforce a device reset as proposed in [33,67]. In these papers, the authors propose the usage of an Authenticated Watchdog Timer (AWDT) which causes the device to reset if the backend stops issuing authenticated tokens.…”

“…In these papers, the authors propose the usage of an Authenticated Watchdog Timer (AWDT) which causes the device to reset if the backend stops issuing authenticated tokens. However, this approach has higher hardware requirements -either an additional coprocessor [67] or a Trusted Execution Environment (TEE), e.g., TrustZone-M [33]. Additionally, a reset may be disturbing in real applications.…”