Architectural Support for Containment-based Security

Abstract

Software security techniques rely on correct execution by the hardware. Securing hardware components has been challenging due to their complexity and the proportionate attack surface they present during their design, manufacture, deployment, and operation. Recognizing that external communication represents one of the greatest threats to a system's security, this paper introduces the TrustGuard containment architecture. TrustGuard contains malicious and erroneous behavior using a relatively simple and pluggable gatekeeping hardware component called the Sentry. The Sentry bridges a physical gap between the untrusted system and its external interfaces. TrustGuard allows only communication that results from the correct execution of trusted software, thereby preventing the ill effects of actions by malicious hardware or software from leaving the system. The simplicity and pluggability of the Sentry, which is implemented in less than half the lines of code of a simple in-order processor, enables additional measures to secure this root of trust, including formal verification, supervised manufacture, and supply chain diversification with less than a 15% impact on performance. CCS Concepts • Security and privacy → Hardware security implementation.

Hardware Security For and Beyond CMOS Technology

“…The implementation of memristor devices remains under research and development, considering various materials and arrangements like titanium dioxide [111], spintronics [112], or carbon nanotubes [113], with most approaches remaining compatible with CMOS fabrication. Memristive systems in the broader sense, like resistive random-access memories (ReRAMs) or even phase-change memories (PCMs), 3 are progressing towards commercial application [118,119]. Aside from memory, memristors are also interesting for in-memory computing, neuromorphic computing, and reconfigurable logic [115,120,121].…”

“…Within the realm of cybersecurity in general, hardware security in particular is concerned about achieving security and trust directly within the underlying electronics. Therefore, hardware security seeks to build up, e.g., so-called root of trust (RoT) schemes for isolation and attestation of computation [2][3][4], or other hardware primitives and protection schemes.…”

“…Such "breadand-butter" attacks are conducted mainly at the software level. Cryptography represents the most commonly applied protection scheme, while many hardware security features have been proposed and implemented as well, e.g., RoT architectures [2][3][4] or hardware crypto modules [6] and true random number generators (TRNGs) to support the latter. However, if not designed and implemented carefully, such security features become prone to hardware-centric attacks, e.g., see [7][8][9][10][11]; such attacks are discussed below.…”

Towards Designing a Secure RISC-V System-on-Chip: ITUS

“…Even the safe enclaves offered by TEE frameworks can be vulnerable to sidechannel leaks such as due to speculative execution [32]. Measures to ensure fault resiliency is another important aspect in this context: e.g., DIVA [33], Sentry [34].…”

“…While Keystone strives to be less dependent on hardware modifications (improving from Sanctum), approaches like TIMBER-V use tagged memory ideas to implement flexible isolation and involve significant hardware changes 4 . Different in approach and scope from the above containment strategies, TrustGuard [34] presents a hardware based containment strategy to 'quarantine' any faulty or malicious behavior of untrusted components using a gatekeeping hardware module they call a 'Sentry'. Also receiving attention, and something with a significant impact on the threat surface of a system, are CPU micro-architectural countermeasures: e.g., InvisiSpec [58] (making speculation associated leakage unobservable), [32] (securing enclaves executing on a speculative CPU, same as the one used in Section 5.4).…”