KeyVisor -- A Lightweight ISA Extension for Protected Key Handles with CPU-enforced Usage Policies

TL;DR

KeyVisor is presented, a lightweight Instruction Set Architecture (ISA) extension that securely offloads the handling of symmetric crypto keys to the CPU that provides CPU instructions that enable applications to request protected key handles and perform AEAD cipher operations on them.

Abstract

The confidentiality of cryptographic keys is essential for the security of protection schemes used for communication, file encryption, and outsourced computation. Beyond cryptanalytic attacks, adversaries can steal keys from memory via software exploits or side channels, enabling them to, e.g., tamper with secrets or impersonate key owners. Therefore, existing defenses protect keys in dedicated devices or isolated memory, or store them only in encrypted form. However, these designs often provide unfavorable tradeoffs, sacrificing performance, fine-grained access control, or deployability. In this paper, we present KeyVisor, a lightweight ISA extension that securely offloads the handling of cryptographic keys to the CPU. KeyVisor provides CPU instructions that enable applications to request protected key handles and perform AEAD cipher operations on them. The underlying keys are accessible only by KeyVisor, and thus never leak to memory. KeyVisor's direct CPU integration enables fast crypto operations and hardware-enforced key usage restrictions, e.g., keys usable only for de-/encryption, with a limited lifetime, or with a process binding. Furthermore, privileged software, e.g., the monitor firmware of TEEs, can revoke keys or bind them to a specific process/TEE. We implement KeyVisor for RISC-V based on Rocket Chip, evaluate its performance, and demonstrate real-world use cases, including key-value databases, automotive feature licensing, and a read-only network middlebox.

Figures (5)

• Figure 1: KeyVisor allows CPUs to replace in-memory keys with protected key handles usable only via new CPU instructions in a policy-defined way, e.g., by the owner process.
• Figure 2: The Key handle format contains the encrypted user key, the AES-GCM IV and tag, and the handle usage policy (bits 0 to 128). The policy is signed as GCM AAD.
• Figure 3: Simplified block diagram of KeyVisor's hardware implementation.
• Figure 4: Performance of KeyVisor encryption and decryption for varying sizes of data (x-axis) and AAD (y-axis).
• Figure 5: Overview of KeyVisor's Handle State Cache and its IV-based indexing, assuming 96 bit handle IVs (IV handle).