LiteAtt: Secure and Seamless IoT Services Using TinyML-based Self-Attestation as a Primitive

TL;DR

LiteAtt is a lightweight, verifier-less IoT firmware attestation framework leveraging TinyML in TrustZone, providing high accuracy and low latency for secure, decentralized IoT device trust without firmware copies.

Contribution

This work introduces LiteAtt, a novel TinyML-based self-attestation framework that operates within TrustZone, eliminating the need for firmware copies and enhancing privacy and security in IoT networks.

Findings

Achieves 98.7% accuracy in SRAM attestation

Operates with 1.29ms latency and 42.79μJ energy consumption

Uses up to 32KB runtime memory overhead

Abstract

As the Internet of Things (IoT) becomes an integral part of critical infrastructure, smart cities, and consumer networks, there has been an increase in the number of software attacks on the microcontrollers (MCUs) that constitute such networks. Runtime firmware attestation, i.e., the verification of a firmware's integrity, has become instrumental, and prior work focuses on lightweight IoT MCUs, offloading the verification task to capable remote verifiers. However, modern IoT devices feature large flash and volatile memory, on-device TinyML inference, and Trusted Execution Environments (TEE). Leveraging these capabilities, this paper presents a verifier-less, hybrid Self-Attestation (SA) framework called LiteAtt, which is based on TinyML execution in the Arm TrustZone of an IoT MCU for quick, on-device evaluation of the IoT firmware's SRAM footprint. LiteAtt takes a step towards ubiquitous intelligence and decentralized trust in IoT networks. It eliminates the need for firmware copies for attestation, and protects the privacy of user SRAM data by leveraging twin devices to train the TinyML models. The proposed framework achieves an average accuracy of 98.7%, F1 score of 99.33%, TPR of 98.72%, and TNR of 97.45% on SRAM attestation datasets collected from real devices. LiteAtt operates with a latency of 1.29ms, an energy consumption of 42.79uJ, and a runtime memory overhead of up to 32KB, which is suitable for battery-operated Arm Cortex-M devices. A security analysis is provided for the protocol regarding mutual authentication, confidentiality, integrity, SRAM privacy, and defense against replay and impersonation attacks. Practical deployment scenarios and future works are also discussed.