Biblio

Hardware security architectures and primitives are becoming increasingly important in practice providing trust anchors and trusted execution environment to protect modern software systems. Over the past two decades we have witnessed various hardware security solutions and trends from Trusted Platform Modules (TPM), performance counters for security, ARM's TrustZone, and Physically Unclonable Functions (PUFs), to very recent advances such as Intel's Software Guard Extension (SGX). Unfortunately, these solutions are rarely used by third party developers, make strong trust assumptions (including in manufacturers), are too expensive for small constrained devices, do not easily scale, or suffer from information leakage. Academic research has proposed a variety of solutions, in hardware security architectures, these advancements are rarely deployed in practice.

Security of embedded devices is a timely and important issue, due to the proliferation of these devices into numerous and diverse settings, as well as their growing popularity as attack targets, especially, via remote malware infestations. One important defense mechanism is remote attestation, whereby a trusted, and possibly remote, party (verifier) checks the internal state of an untrusted, and potentially compromised, device (prover). Despite much prior work, remote attestation remains a vibrant research topic. However, most attestation schemes naturally focus on the scenario where the verifier is trusted and the prover is not. The opposite setting–-where the prover is benign, and the verifier is malicious–-has been side-stepped. To this end, this paper considers the issue of prover security, including: verifier impersonation, denial-of-service (DoS) and replay attacks, all of which result in unauthorized invocation of attestation functionality on the prover. We argue that protection of the prover from these attacks must be treated as an important component of any remote attestation method. We formulate a new roaming adversary model for this scenario and present the trade-offs involved in countering this threat. We also identify new features and methods needed to protect the prover with minimal additional requirements.