arXiv subjects

Christian Werling

Publications and source records attributed to Christian Werling.

4 recordsLinked to original sources

arXiv2026

Not Discrete Enough: On the Inherent Insecurity of dTPMs for Measured Boot

Measured Boot, a mechanism enabled through Trusted Platform Modules (TPMs), is commonly used for passwordless protection of data-at-rest, aiming to protect data when the device is lost or stolen. Microsoft's standpoint is neutral on which way a TPM should be implemented: Firmware-based TPMs (fTPMs) are viewed as more economical but less secure. Despite the inherent susceptibility to bus sniffing attacks, discrete TPMs (dTPMs) are still seen as the gold standard, as many deliver better on-paper tamper resistance. It is often argued that attacks against the bus can be mitigated by bus encryption and, ideally, mutual authentication between the CPU and TPM. This position paper aims to emphasize another inherent, difficult-to-mitigate attack against dTPMs that was originally shown against a TPM 1.1 over 20 years ago: We demonstrate that even brief physical access to a TPM 2.0 and the ability to boot from an attacker-controlled system enable an attacker to reset and replay arbitrary measurements, thereby allowing an attacker to unseal, for example, a disk encryption key solely protected by the TPM. While there have been attacks against fTPMs, too, we argue that their practical attack surface is fundamentally smaller. Bus protection techniques can be used to protect dTPMs, but only guard against passive attacks. After all, we argue that, from a security standpoint, firmware TPMs, or any TPM internal to the SoC, are superior to discrete (external) ones. Lastly, in order for dTPM-based setups to provide meaningful protection of sealed secrets, configurations must require a user-provided PIN or password along with the Measured Boot configuration.

cs.CR↗

arXiv2023

faulTPM: Exposing AMD fTPMs' Deepest Secrets

Trusted Platform Modules constitute an integral building block of modern security features. Moreover, as Windows 11 made a TPM 2.0 mandatory, they are subject to an ever-increasing academic challenge. While discrete TPMs - as found in higher-end systems - have been susceptible to attacks on their exposed communication interface, more common firmware TPMs (fTPMs) are immune to this attack vector as they do not communicate with the CPU via an exposed bus. In this paper, we analyze a new class of attacks against fTPMs: Attacking their Trusted Execution Environment can lead to a full TPM state compromise. We experimentally verify this attack by compromising the AMD Secure Processor, which constitutes the TEE for AMD's fTPMs. In contrast to previous dTPM sniffing attacks, this vulnerability exposes the complete internal TPM state of the fTPM. It allows us to extract any cryptographic material stored or sealed by the fTPM regardless of authentication mechanisms such as Platform Configuration Register validation or passphrases with anti-hammering protection. First, we demonstrate the impact of our findings by - to the best of our knowledge - enabling the first attack against Full Disk Encryption solutions backed by an fTPM. Furthermore, we lay out how any application relying solely on the security properties of the TPM - like Bitlocker's TPM- only protector - can be defeated by an attacker with 2-3 hours of physical access to the target device. Lastly, we analyze the impact of our attack on FDE solutions protected by a TPM and PIN strategy. While a naive implementation also leaves the disk completely unprotected, we find that BitLocker's FDE implementation withholds some protection depending on the complexity of the used PIN. Our results show that when an fTPM's internal state is compromised, a TPM and PIN strategy for FDE is less secure than TPM-less protection with a reasonable passphrase.

cs.CR↗

arXiv2022

EM-Fault It Yourself: Building a Replicable EMFI Setup for Desktop and Server Hardware

EMFI has become a popular fault injection (FI) technique due to its ability to inject faults precisely considering timing and location. Recently, ARM, RISC-V, and even x86 processing units in different packages were shown to be vulnerable to electromagnetic fault injection (EMFI) attacks. However, past publications lack a detailed description of the entire attack setup, hindering researchers and companies from easily replicating the presented attacks on their devices. In this work, we first show how to build an automated EMFI setup with high scanning resolution and good repeatability that is large enough to attack modern desktop and server CPUs. We structurally lay out all details on mechanics, hardware, and software along with this paper. Second, we use our setup to attack a deeply embedded security co-processor in modern AMD systems on a chip (SoCs), the AMD Secure Processor (AMD-SP). Using a previously published code execution exploit, we run two custom payloads on the AMD-SP that utilize the SoC to different degrees. We then visualize these fault locations on SoC photographs allowing us to reason about the SoC's components under attack. Finally, we show that the signature verification process of one of the first executed firmware parts is susceptible to EMFI attacks, undermining the security architecture of the entire SoC. To the best of our knowledge, this is the first reported EMFI attack against an AMD desktop CPU.

cs.CR↗

arXiv2019

Insecure Until Proven Updated: Analyzing AMD SEV's Remote Attestation

Customers of cloud services have to trust the cloud providers, as they control the building blocks that form the cloud. This includes the hypervisor enabling the sharing of a single hardware platform among multiple tenants. AMD Secure Encrypted Virtualization (SEV) claims a new level of protection in cloud scenarios. AMD SEV encrypts the main memory of virtual machines with VM-specific keys, thereby denying the higher-privileged hypervisor access to a guest's memory. To enable the cloud customer to verify the correct deployment of his virtual machine, SEV additionally introduces a remote attestation protocol.This paper analyzes the firmware components that implement the SEV remote attestation protocol on the current AMD Epyc Naples CPU series. We demonstrate that it is possible to extract critical CPU-specific keys that are fundamental for the security of the remote attestation protocol.Building on the extracted keys, we propose attacks that allow a malicious cloud provider a complete circumvention of the SEV protection mechanisms. Although the underlying firmware issues were already fixed by AMD, we show that the current series of AMD Epyc CPUs, i.e., the Naples series, does not prevent the installation of previous firmware versions. We show that the severity of our proposed attacks is very high as no purely software-based mitigations are possible. This effectively renders the SEV technology on current AMD Epyc CPUs useless when confronted with an untrusted cloud provider. To overcome these issues, we also propose robust changes to the SEV design that allow future generations of the SEV technology to mitigate the proposed attacks.

cs.CR↗