SpecCert: Specifying and Verifying Hardware-Based Security Enforcement

Abstract

Abstract. Over time, hardware designs have constantly grown in complexity and modern platforms involve multiple interconnected hardware components. During the last decade, several vulnerability disclosures have proven that trust in hardware can be misplaced. In this article, we give a formal definition of Hardware-based Security Enforcement (HSE) mechanisms, a class of security enforcement mechanisms such that a software component relies on the underlying hardware platform to enforce a security policy. We then model a subset of a x86-based hardware platform specifications and we prove the soundness of a realistic HSE mechanism within this model using Coq, a proof assistant system.

A Generic Framework to Develop and Verify Security Mechanisms at the Microarchitectural Level: Application to Control-Flow Integrity

“…the isolation mechanism provided by OS kernels or hypervisors leveraging hardware features. Such approaches require formalizing the interactions between software and hardware components [21].…”

“…Second, the security properties proved at the ISA level still rely on the correct implementation of this ISA by a microarchitectural model. Some works in formal methods for hardware verification [1], [6], [15], [21] are based on models of the actual hardware. While this makes proofs easier to come up with, this also opens a possibility for discrepancies between the model and the actual hardware, thus giving a false sense of security.…”

A Survey of Practical Formal Methods for Security

“…To demonstrate this approach, the authors have designed an implementation of TrustZone, including 10+ security bugs. Similarly the authors of [166] present a formally defined hardware security enforcement for x86 architecture. In this setting, the software relies on underlying hardware for security enforcement, for example memory paging features of an x86 CPU.…”

Modular Verification of Programs with Effects and Effect Handlers in Coq

“…FreeSpec follows our previous work named SpecCert [1], whose lack of modularity complexified scalability. Kami [13] shares many concepts with FreeSpec, but implements them in a totally different manner: components are defined as labelled transition systems and can be extracted into FPGA bitstreams.…”

“…The latter scenario may lead to a situation where every component seems to be working as expected, but their composition creates an attack path. We name this class of security vulnerabilities "architectural attacks" [1]. Over the past decade, many critical vulnerabilities affecting computing systems, in particular those relying on the x86 architecture, have raised awareness about the threat posed by architectural attacks.…”