Secure Logging with Trusted Hardware

The other category of related work focusses on the application of trusted com-puting primitives in order to facilitate secure logging. This includes providing stronger guarantees for the security of the logging application (known also as a ‘logger’) both under execution and at rest, as well as the confidentiality and integrity of log entries. These schemes are complementary to previous schemes by taking a system security perspective rather than a wholly cryptographic one.

Indeed, it is the case that many of these systems – described below – incorporate cryptographic principles from the previously described schemes.

In 2003, Chong et al. [238] produced the first work in applying tamper-resistant hardware for providing additional security assurances with respect to cryptographic logging schemes. The authors explore the use of the iButton¹– a device containing 134kB NVRAM, a real-time clock (RTC) and a 32kHZ processor in a 17.35mm cylindrical stainless steel enclosure²– in order to protect the initial pre-shared key, RLK (or A0), of the Schneier and Kelsey scheme [232]. The iButton is used to provide tamper-resistant timestamping of log entries, as well as encryption using 64-bit DES from SHA-1 keys.

Later, Sinha et al. [225] suggested a using a TPM with a novel forward integrity scheme based on branched key chaining and the Schneier and Kelsey [232]

scheme. Here, logs are divided into epochs (blocks) with each block comprising an independent sequence of hash-chained log entries (sub-epochs). The purpose of this subdivision is to reduce the overhead of sealing each individual log entry to storage using the TPM. The root entries of each epoch are hash-chained with past epochs, thus creating a two-dimensional hash chain for protecting against re-ordering attacks. A re-ordering attack is one in which an adversary re-orders log blocks (arranged in time) in order to mislead investigators; that is, attempting to construe a series events that may be correct in their contents but not in their chronology. For each new epoch, the previous epoch’s logs are securely stored using the TPM’s seal functionality in the typical fashion, i.e. encrypts the logs with a TPM-bound key such that only that particular TPM can decrypt/‘unseal’

them.

Böck et al. [224] explored the use of AMD’s Secure Virtual Machine (SVM) – an early inception of the TEE – for launching a syslog client daemon and

1iButton: https://www.maximintegrated.com/en/products/ibutton/ibuttons/

index.cfm

2The iButton famously underpinned the Java Ring [239] in the late 1990s.

logging application from the TPM’s secure boot chain. The logger executes with access to TPM-bound key-pairs for encrypting and signing individual log entries.

Upon request, the logs are decrypted and transmitted to the verifying party over a secure channel. The TPM keys are certified for authenticating that signed logs originated from a particular AMD SVM instance; the TPM is used in convincing a remote verifier of the platform’s expected operating state via remote attestation.

Nguyen et al. [240] proposed streaming medical logs to a server application executing within an Intel SGX enclave (see Section2.4.6) that applies the tamper-resistance algorithm. In this scheme, logs are transmitted from healthcare devices to the enclave using TLS, which then computes a simple hash chain scheme in which each value is found using ai = h(ai−1, si, h(c)), where ai is the current entry, siis the i^thsequence number, and c is the contents of the log message. Each log entry is signed using an key-pair stored within the enclave and subsequently stored to file using SGX’s sealing mechanism.

Karande et al. [241] introducde SGX-Log, which protects server-side device logs received from arbitrary remote devices. SGX-Log, like [225], uses block-based hash chains and seals them to secure storage for persistent log integrity and confidentiality; the scheme, like [240], is also implemented within an SGX enclave.

The authors note that continual sealing also provides resilience to attacks in which large volumes of logs in memory are lost due to a power loss. Remote attestation is also suggested to authenticate the server enclave before transmitting the logs.

However, public-key cryptography is not used establishing public verifiability of origin, unlike [224] and [234], nor is it apparent how to protect logs from the devices from which they are sourced. The proposed scheme is evaluated using three datasets on an SGX-enabled Linux system with an eight-core Intel i7-6700 CPU (3.4GHz) and 64GB RAM, yielding a small (<7%) overhead versus a non-SGX implementation.

5.2.3 Discussion

Modern TPM- and TEE-based approaches [224], [225], [240], [241] still fall short of satisfying many desirable properties identified in past work. Public verifiability of origin, as in [224] and [234], has not been addressed in recent TEE loggers for directly authenticating system data from remote devices. Most notably, recent TEE-based schemes, i.e. [241] and [240], focus primarily on protecting logs after being received by a server-side log processing application. There has been little attention paid to protecting logs collected on source devices, which may themselves host a TEE. An adversary aboard a compromised source device may simply tamper the logs before reaching the server that applies some tamper-resistance algorithm. This is where the contribution of this work lies; the focus is on protecting logs at source on constrained devices.

To complicate matters, source devices are unlikely to transmit logs in real-time in order to minimise network and computational overhead, and so secure storage should be used to preserve unsent logs. Moreover, TEEs typically contain other security-critical applications, such as biometric authentication and payment tokenisation. As a result, a TEE-based logging mechanism should operate with reasonable resource consumption, particularly run-time memory, to preserve performance and limit the rise of Denial of Service (DoS) conditions.

5.3 Security Goals

To scope this work, we identify a series of security and functional goals for constructing a TEE-based system for protecting logs on constrained devices, which are drawn from the issues identified in related work in Section5.2:

R1. Isolated execution: the system shall process logs in an environment isolated from a regular ‘rich’ OS, e.g. Android, to provide strong integrity assurances of the application and data under execution.

R2. Forward integrity: the integrity of a given block of logs shall not be affected by a key comprise of a previous block.

R3. Log confidentiality: on-device log confidentiality should be preserved to prevent the disclosure of potentially sensitive entries.

R4. Remote attestation: the proposal shall allow third-parties to verify the logging application’s integrity post-deployment to provide assurances that logs were sourced from an integral and authentic platform.

R5. Secure log retrieval: remote, authorised third-parties shall be able to securely retrieve device logs with mutual trust assurances.

R6. Public verifiability: the system shall allow third-parties to authenticate the origin of log entries without access to private key information.

R7. Truncation attack-resistant: the system shall be resistant to attacks that aim to delete a contiguous subset of tail-end log entries.

R8. Re-ordering attack-resistant: the proposal shall resist attempts to change the order of entries in the log sequence.

R9. Power-loss resilience: the loss of tamper-resistant logs shall be minimised in the event of a device power-loss.

R10. Suitable root of trust: a root of trust for constrained device architectures shall be used, ideally without requiring additional security hardware.

5.4 Threat Model

Two types of adversary are addressed for when, firstly, the logs are collected and processed on the device and, secondly, when they are retrieved by a verifier over a network. These are described as follows:

• On-device adversary: a software-based attacker that compromises the system at time t and attempts to arbitrarily alter, forge or observe logs produced before t. This adversary can operate at any protection level in the untrusted world, i.e. Rings 0–3, including arbitrarily altering execution flow and accessing non-TEE kernel space services. For example, the attacker may aim to modify the contents of individual log entries to conceal any evidence of wrongdoing, or, like [241] and [225], perform re-ordering attacks in which blocks of log entries are re-ordered to construe a misleading sequence of events chronologically. As stated in Section5.3, we also tackle the issue of truncation-resistance, identified in [235], where an attacker aims at deleting at sub-set of tail-end log entries. Additionally, like [241], we consider power-loss attacks in which an attacker disables power to the device with the aim of erasing significant numbers of logs kept in volatile RAM.

• Network adversary: an adversary that attempts to arbitrarily alter, forge, replay or observe logs between the source device and the verifier over a network channel, e.g. Bluetooth or WiFi/802.11. The attacker may also attempt to masquerade as a legitimate party to either end-point to collect logs illicitly. Here, we consider the principle goal of the attacker to modify or observe log entries as they are transmitted over-the-air to the log verifying authority.

The first case considers an on-device adversary similar to related work, namely Böck et al. [224], Karande et al. [241], Sinha et al. [225], and the secure untrusted system logging schemes identified in Section5.2.1. In other words, we do not attempt to secure untrusted world logs after a compromise by the above adversary after time t, as a kernel-mode adversary may simply write directly to the kernel message buffer used to queue log entries (see Section5.5.1). Related to this, we do not consider denial-of-service (DoS) attacks from an adversary after time t who attempts to flood the logging scheme with log entries at a rate faster than they are processed in the TEE. As per related work, the assurances are valid only before time t at which the device is compromised by the on-device adversary stated above. Principally, the aim is to protect system logs collected before time t against kernel-level adversaries. In the second case, for the network adversary, we do not cover DoS attacks in which the attacker impedes all network traffic

between device and the verifier, thus preventing log retrieval; physical retrieval would be one remedy in this situation.

We assume the presence of a GlobalPlatform-compliant TEE that satisfies the GlobalPlatform TEE Protection Profile, the scope of which was discussed in detail in Section2.4.7of Chapter2. As such, threats that fall outside the protection remit of the GlobalPlatform TEE are beyond the scope of this work, such as developer-induced TA and TEE programming errors, supply chain attacks, and advanced hardware attacks requiring substantial time, capital, equipment and expertise, e.g. laser fault injections. Consequently, caution is urged in situations where such threats are considered. We refer the reader back to Sections2.5.1,2.5.2and2.6for a discussion of the threats considered within the security remit of TEEs and other secure and trusted execution technologies generally. For clarity, we consider the issue of log entry analysis – the act of assessing system activity and detecting anomalous and malicious events, usually achieved using anomaly detection algorithms (see Xu et al. [242] and Fu et al. [243]) – to also be out-of-scope in this work.