Introduction

This introduction to the Cryptographic Lockers Extension (KLE), formerly the Atomic Cryptography Extension (ACE), is not normative and repeats material from the specification on purpose. Parts of it, such as the Threat Model, may enter the specification at ratification.

Features

KLE lets software perform fast cryptographic operations without access to the keys or other critical values, for uses such as content protection (media and local LLM decryption), link and storage encryption, secure boot, and attestation. Its main features are:

Atomic operations. Each cryptographic operation is atomic, so keys cannot be recovered from the data before and after it, even by a memory-read exploit.
Cryptographic Lockers are architectural containers that hide their secrets from software. Software provisions a locker with Content (keys and other state) and Metadata that binds the Content to algorithms and, optionally, to usage policies, hardware and software environments, and an expiration date, forming a Cryptographic Context. KLE instructions reference lockers, not key values; strict management rules keep lockers from revealing critical values; and a context can be exported to memory under authenticated encryption and later reimported.
One interface for many primitives, instead of separate instructions per primitive:
- Leaked derived keys or intermediate values break modes such as AES-GCM-SIV, XTS, and OCB, so KLE defines modes of operation (among them CTR, GCM, and CMAC) and secure key derivation, for AES-128, -192, -256 and other block ciphers such as SM4.
- Encrypt-only and decrypt-only versions reduce misuse, and versions with a preset IV or nonce keep it confidential.
- The interface also covers hash functions and public-key and post-quantum algorithms. Side-channel protected implementations, where available, are variants of the standard algorithms and replace them without code changes.
- Implementations need not support every algorithm: KLE defines subextensions, and Zkl requires a baseline set (Extensions Overview), leaving the others to the RISC-V profiles.
Scalability. One ISA and ABI serve cores from embedded to server, with support for persistence, sleep, hibernation, and VM migration.

Non-Goals

KLE intentionally does not provide:

Variable-length inputs: data is processed in fixed-size blocks.
Full key management: KLE provides building blocks, and the key-management logic resides in trusted software, such as TEE applets. External schemes provision keys only through a local trusted component that obtains keys and policies and configures the CCs.
Key revocation, because:
1. it would cost implementation effort and performance, against KLE’s goals of simplicity and speed;
2. no universal mechanism is practical: protocols are numerous, revocation data may be unbounded, and the KLE unit would need dynamic access to secure memory, whereas isolated software components can revoke keys with strong guarantees;
3. revocation applies mainly to root keys, which their trusted manager can revoke, while expiration dates and Localities limit the lifetime and scope of derived keys; and
4. applications that use root keys directly, such as link or storage encryption, usually run in protected environments with their own revocation.
Full prevention of misuse by compromised processes: a compromised process keeps access to its CCs, so KLE complements, but does not replace, vulnerability mitigations and process isolation. Modes that use one operation to encrypt and decrypt, such as counter modes, stay open to such abuse.

Threat Model

Assets are keys and any information that helps an adversary recover plaintext or forge ciphertexts or MACs, such as the masks of tweakable XEX modes and the derived keys of AES-GCM-SIV. Their confidentiality and integrity are protected. Their availability is not an architectural goal, but the availability of resources is: a caller can always configure a locker, and the KLE unit never evicts a CC on its own.

Adversaries can compromise processes through software vulnerabilities, and access memory, for example by abusing hardware interfaces or interposing between the SoC and memory. Sophisticated hardware attacks, such as tampering with a focused ion beam or scanning electron microscope (FIB/SEM), are excluded.

Direct plaintext leakage, memory-corruption attacks against the process using KLE, and Release of Unverified Plaintext (RUP) attacks are accepted: the processed data resides in the user’s execution context, where KLE cannot protect it.

Discussion Points

These items are neither known defects nor a measure of the specification’s maturity.

Group A: items requiring closure by the RISC-V Architecture Review Committee (ARC).

Opcode allocation. The encodings are provisional; the ARC allocates the final ones. The core instructions use the MISC-MEM opcode, which has several unused funct3 values; similar gaps elsewhere would serve as well. The memory instructions are harder, since their offsets take every bit that opcode, funct3 and the registers leave: kl.input uses the only unused funct3 value of LOAD, 0x7, and kl.output the value 0x5 of STORE, encoded together with kl.load and kl.store, respectively.

Moving encoding bits [29:25] of kl.size, kl.avail, kl.getmd*, kl.rstr*, and kl.clone to [24:20], with [29:25] fixed to zero, would free significant space in funct7.
Naming of instructions. Should the instructions that use vector registers take a v prefix, as vkl.mgmt for the version that takes the MDH from a vector register, and those that take 128 bits from GPRs a q suffix, as kl.mgmtq?
misa.L and mstatus[26:25] (KLS). Provisional and contested. misa.L may give way to another mechanism, such as Unified Discovery, and KLS, with the corresponding bits of sstatus and vsstatus, may move to another offset or register, or to a mechanism other than a *status context-status field. The specification depends only on a two-bit context-status field with the semantics of Encoding of the KLS field, like FS and VS.
mstatus[27] (kleemulation). The bit that makes kl.avail and kl.size of Form B or C trap on a Machine, or a combination of its MDH fields, that the KLE unit does not implement natively, so that M-mode can emulate it (KLE Emulation Control in mstatus), sits in mstatus only provisionally. The ARC must move it to a free position, in mstatus or another M-mode CSR.
KLE CSR addresses. All addresses, and the Smstateen bit of CSRs, are placeholders for the ARC to assign.
Exception cause codes. The ARC must allocate mcause values: individual causes, or a single KLE cause with a subcause register. A way to report the locker number, for instance in mtval, is also needed; it would spare handlers from decoding locker references, KLNL included.
1. specific mtval or KLE Emulation Trap. Trap-and-emulate uses the illegal-instruction exception, which, with kleemulation, must stay undelegated (KLE Emulation Control in mstatus). A dedicated exception type would be better, especially since no mode below M emulates, and would remove that constraint; a special mtval could serve instead.
KLV scope. RVV/KLV defines the vector subset KLE requires, which we consider complete. These questions do not block candidacy but need ARC feedback:
1. Should *status.VS or another mechanism gate KLV vector instructions?
2. How should KLV be discovered?
3. How should kl.exec element widths be defined? EGW/SEW cannot represent sizes that are not powers of two; one option allows any power of two that divides the size, with EGW/SEW and the vstart increment defined per iteration.
Discoverability of cipher/mode combinations. We propose that software discover Machines with kl.avail rather than by extension names, which could proliferate beyond manageability. Machine Type and Mode Encodings, corresponding Extensions still suggests names: Zkl, the primitive name ending in p, and the mode name ending in m (e.g., Zklaes192p and Zklaes192pgcmm).

Group B: open design questions owned by this task group.

Nonces for SCC export and import. An RFC 8452 nonce costs six AES-256 encryptions per export or import, whereas this design recomputes the derived keys only when the CSK changes. A competing architecture also omits nonces from key export and import, probably for the same reason. We welcome input on this choice.
Additional inputs for random key generation. Should standard KDFs be defined?
SCC_Encrypt security claim. Substantiate the claim “secure for up to 2⁶⁴ 128-bit blocks.”
Emulated Machines. TODO: define how software discovers emulated instructions and Machines, and whether an emulated Machine may override a native one with a fixed emulated version (KLE Emulation Control in mstatus).
Memory-instruction check order. Rule GR12 checks the address alignment of kl.load and kl.store independently of the locker State, so a misaligned address traps even on an inert locker. Hardware implementers should confirm that this order is practical, and that M-mode trap-and-emulate (KLE Emulation Control in mstatus) can reproduce it.
One SCC key for all protection levels, or one per level. The CSK alone determines the keys that seal every SCC, whatever its SCProtection level, and an implementation that supports several levels may export and import each locker with an AES and POLYVAL engine of the locker’s level (The Cryptographic Locker File and Authentication Information). A differential side-channel or fault-injection attack on the least-protected engine can then expose the SCCs of every level; the specification accepts this risk. Per-level keys would confine such an attack to the engine’s level, if SCC_KeyDeriv, the only step that uses the CSK, runs at the highest supported level, with a nonce that carries the SCProtection level. This choice interacts with the one on SCC nonces above. We welcome input on it.