EmLog: Tamper-Resistant System Logging for Constrained Devices with TEEs

Abstract

Remote mobile and embedded devices are used to deliver increasingly impactful services, such as medical rehabilitation and assistive technologies. Secure system logging is beneficial in these scenarios to aid audit and forensic investigations particularly if devices bring harm to end-users. Logs should be tamper-resistant in storage, during execution, and when retrieved by a trusted remote verifier. In recent years, Trusted Execution Environments (TEEs) have emerged as the go-to root of trust on constrained devices for isolated execution of sensitive applications. Existing TEE-based logging systems, however, focus largely on protecting server-side logs and offer little protection to constrained source devices. In this paper, we introduce EmLog -a tamper-resistant logging system for constrained devices using the GlobalPlatform TEE. EmLog provides protection against complex software adversaries and offers several additional security properties over past schemes. The system is evaluated across three log datasets using an off-the-shelf ARM development board running an open-source, GlobalPlatform-compliant TEE. On average, EmLog runs with low run-time memory overhead (1MB heap and stack), 430-625 logs/second throughput, and five-times persistent storage overhead versus unprotected logs.

Systematic Literature Review on the Use of Trusted Execution Environments to Protect Cloud/Fog-Based Internet of Things Applications

“…Protection for flow tracking application [59] Trusted framework to develop IoT applications [36] Protection for health data [73] Secure architecture for P2P scenarios [24] Protection for edge computing [63] Comparison between TEE and secure multi-party computation application [62] Protection for video application [46], [69] Secure logger [13], [76] Protection for system analyser [49] Societal model for IoT security [68] Protection for location-based services [60] Trusted auditor [47] Protection for data dissemination [61] Data encryption mechanism [56] Protection for data management [14] Data protection (app) [71] Protection for data aggregation (app) [75] Checker for Industrial gateway communications [52] Lightweithg anonymous authentication [25] Remote attestation mechanism [38] Device snapshot authentication system [32] Control-flow attestation [37] Authentication scheme [58] Remote attestation and channel protection [44] Secure authentication and key distribution [67] Boot attestation [53] Protection for data through authentication [50] Protection and attestation for remote terminal [65] Device private keys protection architecture [28] Remote attestation [64] Keys derivation from device characteristics [31] Authenticity detection service [40] Keys protection against cold boot attacks [55] Cache rootkit exploiting TrustZone [35] vendors, e.g., ARM and Intel, already present many of the general advantages, such as hardware isolation (normal world and the secure world) and mem...…”

“…Shepherd et al [76] proposed group logging schemes for multiple devices and comparing the TEE performance for the secure logger solution. Pinto et al [43] proposed implementing the protection for real-time OS in edge devices and integrating it with other hardware anchors.…”

Audit Logs Management and Security - A Survey

“…Tamper Proof Storage of Logs using Trusted Platform Module 2.0 is explained in (Sinha et al,2014). EmLog as a Tamper-Resistant System Logging introduced for Constrained Devices with Trusted Execution Environments (TEEs) (Shepherd et al, 2017). Secure Audit Logging with iButton based tamper resistant hardware solution was proposed in (Chong et al, 2003) which further use encryption and ROM storage.…”

Custos: Practical Tamper-Evident Auditing of Operating Systems Using Trusted Execution

“…While the aid of trusted hardware (as in [57], [89], [111]) can help overcome these issues (e.g., by protecting the secrecy of the current key after full system compromise), it is not a panacea. Interacting with a TEE still requires addressing attack vectors such as rollback attacks and protocol termination attacks, and accounting for these issues often leads to large overheads [46], [78], [80].…”