Atomic Cryptography Extension (ACE)

The Atomic Cryptography Extension (ACE) is being developed by the RISC-V High Assurance Cryptography (HAC) Task Group.

ACE is an Instruction Set Architecture (ISA) extension that provides atomic (i.e., full-round) cryptographic operations using Cryptographic Contexts (CCs).

Cryptographic Contexts

A Cryptographic Context is an indivisible data structure consisting of metadata and a content section that holds secrets such as keys. The metadata binds secrets to a specific cryptographic algorithm and defines usage and access policies.

These policies prevent the secret from being used with other algorithms and can optionally restrict access by unauthorized processes, security states, or other entities.

Forms of Cryptographic Contexts

Cryptographic Contexts take one of two forms:

Cryptographic Registers (CRs): Protected architectural containers that conceal secrets once they are written into the registers together with their metadata. The architecture provides no mechanism to export the secrets stored in a CR as plaintext.
Sealed Cryptographic Contexts (SCCs): Cryptographic Contexts stored in untrusted memory and encrypted using a mode of operation of Authenticated Encryption with Associated Data (AEAD). An SCC can subsequently be reimported into a CR.

        Key security principle:
        ACE instructions can use keys only while those keys reside inside
        a Cryptographic Register (CR).
    

Cryptographic Registers

ACE instructions can use keys only while they reside in a CR. When a Cryptographic Context is stored in memory as an SCC, the binding between the key and its metadata relies on the cryptographic strength of the AEAD encryption.

SCCs may be produced by trusted software or hardware and supplied to applications.

Any piece of software can create its own Cryptographic Context by writing a key and metadata into a Cryptographic Register. The original key can then be erased from system memory to reduce its exposure while ACE continues to operate using the key secured within the register.

Algorithm Selection Through Metadata

The metadata may specify anything from a basic cipher, such as AES-128 or AES-256, to a mode of operation such as SM4-GCM-SIV.

A key advantage of ACE is that a small set of algorithm-agnostic instructions can support many different algorithms because the metadata selects the algorithm to execute.

        Example:
        The same compiled binary can target any 128-bit cipher in a given
        mode, such as AES-GCM-SIV, SM4-GCM-SIV, Калина-GCM-SIV, or
        Кузнечик-GCM-SIV. Only the Cryptographic Context changes;
        the instruction sequence remains the same.
    

Symmetric and Asymmetric Cryptography

The current ACE interface supports only symmetric cryptographic primitives.

However, the ISA can also support asymmetric cryptography if public key operations are specified as algorithms that can be selected through the metadata.

Key Advantages of ACE

Protects cryptographic keys inside architectural registers.
Prevents plaintext export of keys from Cryptographic Registers.
Supports sealed cryptographic contexts in untrusted memory.
Uses AEAD to protect SCCs and their metadata binding.
Allows algorithm selection through metadata.
Reduces the need for algorithm-specific ISA instructions.
Allows the same compiled binary to support multiple cryptographic algorithms.
Provides a foundation that can potentially support asymmetric cryptography.

Key Technical Takeaways & Design Verification Flow

Atomic Operations: ACE executes full-round cryptographic operations in single, indivisible instructions rather than exposing individual cipher steps or sub-operations.
Algorithm Agnosticism: Small, unified instruction sets operate independently of the underlying cipher, relying on metadata to select the targeted cryptographic algorithm.
Instruction Reuse: A single compiled binary can execute across multiple 128-bit symmetric ciphers (e.g., AES, SM4, Kalyna, Kuznyechik) without modifying the instruction sequence.
Extensibility Potential: Though currently specified for symmetric primitives, the ISA interface can support public-key (asymmetric) cryptography by introducing corresponding metadata definitions.
Context Structure: A Cryptographic Context is an atomic data structure binding algorithm metadata, usage policies, and access control rights directly to secret keys.
Algorithm Binding: Metadata strictly locks secret keys to specified algorithms, preventing misuse or unauthorized execution using alternative primitives.
Access Control Policies: Metadata enforces restrictions based on software security states, process privilege levels, or specific entity authorizations.
Key Exposure Reduction: Once software loads a key into a Cryptographic Register, the source key in system memory can be securely zeroized to minimize physical attack surfaces.
Cryptographic Registers (CRs): Protected hardware containers that store active CCs and prohibit plaintext key extraction via software commands.
Sealed Cryptographic Contexts (SCCs): Encrypted versions of CCs generated for safe external storage in untrusted system memory.
AEAD Binding Integrity: SCC security relies on Authenticated Encryption with Associated Data (AEAD) to cryptographically bind the key and its metadata during memory storage.
Reimport Mechanism: Sealed contexts (SCCs) stored in memory can be securely decrypted and restored back into hardware Cryptographic Registers for execution.
Specifications & Policy Mapping: Verification begins by translating ISA functional specs, microarchitecture models, and access control matrices into clear test plans.
Formal Property Checking: Formal tools mathematically prove critical security invariants, such as ensuring plaintext keys in CRs can never be read directly.
Random & Directed Simulation: Stimulus generators (RITG) and targeted tests inject corner cases, key misuse attempts, and context corruption scenarios into the RTL model.
Golden Reference Modeling: Simulation results are continuously checked against C++/SystemC golden reference models to verify algorithmic correctness across all supported ciphers.
Side-Channel & Fault Verification: Dedicated security verification tests hardware for side-channel leakage (SPA/DPA) and fault-injection resilience.
Subsystem & SoC Integration: Tests verify inter-process context switching, privilege level enforcement, and correct memory protection unit (MPU) interaction.
Hardware Emulation: Accelerated FPGA/emulation platforms validate real-world software stacks and complex multi-context operational workloads before tape-out.
Post-Silicon Certification: Physical silicon undergoes bring-up validation and compliance testing for standards like FIPS 140-3 and Common Criteria.
ACE DV to silicon validation flow: This entire above flow can be depicted in below diagram.