From KMS to SpaceKMS: Building a Verifiable Cryptographic Control Plane

From confidential computing on Earth to independent trust domains in space

Modern computing systems depend on cryptographic keys to determine who may sign, decrypt, authenticate, release secrets, provision infrastructure, or authorize high-value actions. A Key Management Service (KMS) is the control plane that governs those keys: where they may exist, who or what may use them, under which policies, and inside which execution environment. As cloud services, financial systems, autonomous software, and AI agents become increasingly action-oriented, KMS becomes critical infrastructure for deciding when digital intent is allowed to become cryptographic authority.

1. Cryptographic authority starts on Earth

For SpaceComputer, KMS is a natural first application because it is authority-dense: it requires comparatively modest computation and has a relatively small communication footprint, yet it governs the cryptographic authority behind high-consequence actions, including signatures, encryptions, decryptions, key derivations, and authorization of crucial downstream systems. That asymmetry and concentration of authority make KMS especially well suited to physically isolated trust domains such as space, while the same stack can deliver immediate value on Earth as a terrestrial confidential KMS. SpaceKMS is the longer-term architectural horizon. 

1.1 Compute where it is economical. Place authority where it is trusted.

For the near to medium term, most computation will remain more economical on Earth than it is in orbit. The question is which components of the computing stack gain value when part of their trust model can be physically segregated from the rest of the hosted infrastructure.

We can build and operate the stack on Earth now as a general-purpose confidential KMS service, while designing it from the ground up for both terrestrial and space-based trust domains. The same product serves use cases across managed, self managed, on-premise, regulated, multi-domain and orbital deployment models. The goal is to build a KMS whose API, policy model, attestation model, and cryptographic boundaries remain coherent as authority is situated where each deployment needs it.

1.2. Why build a different kind of KMS?

As AI systems become increasingly autonomous, with the ability to call APIs, move assets, modify infrastructure, and access sensitive data, cryptographic authority becomes a natural enforcement point: the model may determine its intended action, but the KMS determines whether that intent is permitted to become a real-world operation.

There are already strong KMS solutions on Earth. Our goal is not to replace them for the sake of building another key vault, but to extend the KMS model with capabilities we see becoming increasingly strategically significant: programmable guardrails, richer policy enforcement, verifiable execution, attestation-aware authorization, post-quantum cryptography and cryptographic agility, while making those capabilities portable toward a space-native deployment model.

For SpaceComputer, the terrestrial KMS is the empirical proving ground for this stack. It allows us to understand and control where key material may exist, how policy is bound to a key and enforced, how workloads are attested, how cryptographic capabilities are provisioned, how nodes authenticate and communicate, and how the cryptographic layer can evolve across post-quantum cryptography primitives and different execution environments.

1.3 Design for space. Validate on Earth.

Intel TDX provides us with a pragmatic substrate for validating these abstractions today. It allows us to run real workloads, exercise AI guardrails, harden the policy and attestation adjudication paths, introduce new cryptographic primitives, observe operational failure modes, and stabilize the interfaces users will depend on. If those boundaries remain portable, a future migration toward constrained space hardware becomes an infrastructure evolution instead of an application reimplementation.

1.4 AI and autonomous software: separate intent from authority

Giving an agent direct access to a long-lived private key collapses reasoning, authorization, and execution authority into the same boundary. A policy-driven, attested KMS separates those concerns. The AI system may determine what it intends to do; the KMS determines whether that intent may be transmuted into a signed, decrypted or otherwise authenticated external action. An agent may be permitted to sign only for an approved service, only below a defined risk or value threshold, or only when its execution environment presents an approved Confidential Virtual Machine (CVM) measurement.

Attestation does not prove that an AI decision is correct, and a signature does not prove that an inference is true. The value is narrower, but more enforceable: the KMS defines the boundary between software intent and cryptographic authority.

1.5 The trajectory: stronger trust first, space later

The architecture is deliberately useful before it becomes distributed. The priority is to make a single terrestrial KMS domain strongly isolated, attestable, policy-controlled, cryptographically-agile and auditable. After that foundation is established do stronger separation models become appropriate: deployments with heightened assurance requirements can introduce  independent trust domains without changing the client programming model.

The more immediate objective is to make each KMS node trustworthy in a way that is externally verifiable: protect key use with CVM, allow callers to verify the service through attestation and aTLS, optionally verify attested callers when a key policy requires it, express authorization in Cedar (an authorization policy language designed for expressing fine-grained access rules), make cryptography replaceable through profiles, and define certification boundaries with precision.

The next section describes the terrestrial implementation in deep technical detail. Readers primarily interested in the higher-level trust architecture can continue at Section 3: From one trust domain to many.

2. Near-term target architecture

The architecture below describes the near-term terrestrial target. Today, the service tier and the KMS run in a single TD, isolated as containers. The near-term target is to separate them into distinct, independently attested CVMs. The architecture below describes that target unless otherwise stated.

2.1 Architecture at a glance

The terrestrial KMS decomposes the system into distinct responsibilities: client-facing API; evidence verification; confidential execution; persistent hardware roots; and secure transport. The software-defined key and its OpenBao-backed state reside together within the KMS confidential-VM boundary, initially an Intel TDX CVM. A KeyId resolves to a tenant- and user-scoped security object whose Cedar policy, cryptographic profile, attestation prerequisites, and protected key lifecycle are interpreted, evaluated and enforced inside that measured environment, with policies stored where their integrity is protected (in the measured image or inside OpenBao's encrypted storage).

2.2 A signing request, end to end

A signing request illustrates the separation of responsibilities in operational terms. The exact implementation details may evolve over time, but the underlying security choreography should remain legible.

1. Verify the service CVM and establish aTLS. This applies to callers using an attestation-aware client. The Gateway presents attestation evidence bound to its service identity; the caller verifies the approved service-CVM measurement and trusted-computing-base state before establishing attested TLS. Separately, the operator or unseal controller verifies the KMS CVM before releasing unseal secrets or persistent roots.
2. Authenticate, route and resolve the software-defined key. The client sends the requested operation and KeyId to the Gateway. The request flows through Orbitport or the Direct KMS API and converges on the Gateway's KMS plugin inside the service CVM. The plugin validates the KMS parameters, resolves the authenticated tenant/user, assembles request context, and routes the KeyId to the separate KMS CVM, where its Cedar policy, cryptographic profile, attestation requirements and OpenBao lifecycle state are loaded.
3. Verify the caller only when the selected key requires it. If the selected Cedar policy imposes caller-attestation requirements, the caller TEE submits a TDX quote bound to the specific request and to a recipient public key. The attestation service verifies the quote and returns normalized caller claims. If the key does not require caller-attestation, this evidentiary step is omitted.
4. Authorize inside the KMS CVM. The service CVM authenticates the caller, assembles identity and request context, and forwards that context to the KMS CVM. Before relying on it, the KMS CVM verifies the service CVM’s attested identity and approved measurement. Cedar then evaluates the selected key’s policy inside the KMS CVM over the authenticated principal, requested action, assembled request context, and, when required, verified caller-attestation claims. In this design, the guarantee depends on the OpenBao credential remaining confined to the approved KMS CVM, with no privileged operator access to OpenBao. Longer term, the stronger design is to enforce Cedar at the point of key use.
5. Execute and protect the result. On ALLOW, OpenBao (Transit or a crypto plugin) performs the cryptographic operation inside the KMS CVM. Signatures may return through the ordinary response path. When the key requires caller attestation, the KMS encrypts any secret-bearing result (Decrypt, GenerateDataKey, Decapsulate, key-store Get) to the request-bound public key.
6. Return and audit. The result returns from the KMS CVM to the Gateway's KMS plugin, then through the selected Orbitport or Direct KMS API path and Gateway. The system records the relevant key version, Cedar decision, service-CVM and KMS-CVM attestation state, and any caller-attestation claims used during authorization.

2.3 Service plane: authentication, routing, and request context

Gateway first: Orbitport and Direct KMS API as service paths

The Gateway is the primary application-facing service boundary. Applications, command-line tools and AI agents enter through its JSON-RPC interface, where authentication, authorization, routing and tenant context are established before a request is dispatched along one of two paths: Orbitport for SpaceComputer-native applications, or the Direct KMS API for self-managed and on-premise deployments. Both paths converge on KMS-specific logic implemented as a Gateway plugin.

The Gateway, Orbitport or the Direct KMS API, and the KMS plugin together constitute the service architecture inside a confidential virtual machine (CVM). Orbitport remains the default path for communications, telemetry, routing and other space-native workflows, while the Direct KMS API provides a more customizable path for sensitive, self-managed and on-premise deployments. The Gateway and Orbitport handle ingress, orchestration and caller authentication, but managed key material never leaves OpenBao inside the TEE. Separating the service and KMS CVMs limits what a compromised service tier can do: it cannot extract keys, although it could request operations on behalf of any tenant, because the KMS trusts the tenant context the service tier asserts. This is why the service CVM is attested and kept minimal, and why, longer term, the KMS verifies the caller's token itself.

The API intentionally adopts AWS KMS-style operation names and request semantics, including operations such as Sign, Encrypt, Decrypt and GenerateDataKey. The external protocol, however, is JSON-RPC rather than the AWS wire protocol. Because the system does not implement AWS SigV4 authentication, AWS SDKs are not drop-in compatible. The objective is conceptual familiarity, stable operation naming, and a low-friction developer model, not wire-level AWS API compatibility.

Orbitport authenticates clients with Personal Access Tokens (PATs). A PAT is a signed token scoped to one account. The Gateway verifies it on every request, and the account service checks revocation and resolves the tenant, so applications and AI agents can call the KMS without handling any provider credentials.

KMS plugin: KMS-specific logic in the Gateway service

The implementation does not introduce a separate proxy service. Instead, KMS-specific request handling resides in the Gateway's KMS plugin. Requests routed through Orbitport or the Direct KMS API converge on this plugin, which validates KMS parameters, resolves the authenticated tenant/user and KeyId, assembles request context such as caller-attestation claims when required, and invokes the separate KMS CVM. Encapsulating KMS behavior behind a plugin boundary preserves API stability while allowing new operations, cryptographic profiles and execution backends to be introduced without allowing any single backend's native API to become the product interface.

2.4 Authority plane: policy-bound keys and cryptographic execution

Software-defined keys: policy travels with the key

For SpaceComputer, policy is not merely a global authorization gate in front of the KMS. Cedar, an authorization policy language designed for expressing fine-grained access rules, is bound to both the tenant/user and the key. Each KeyId resolves inside the KMS CVM to a software-defined key: protected cryptographic material, the policy governing its use, its cryptographic profile, attestation requirements, and lifecycle metadata. OpenBao provides the protected key lifecycle and cryptographic substrate within the same confidential boundary.

This means two keys owned by the same tenant can enforce different rules, and the same principal can hold different authority across different keys. Cedar expresses and evaluates the key-specific authorization rules, while policy storage, versioning, and distribution remain KMS control-plane responsibilities, deliberately separate from the Cedar language itself.

Structured signing: policy over what gets signed

Traditional KMS permissions remain necessary, but they are insufficient as a complete policy model. This becomes especially important for signing workflows.

In semantically opaque signing, the KMS signs a digest it cannot semantically inspect, so policy is enforced over identity, software measurement, execution context, attestation claims, and request metadata. In semantically structured signing, the KMS or an approved signing plugin receives the full transaction rather than a digest. It extracts the policy-relevant fields, such as value, destination, asset or purpose, from that transaction and evaluates policy over them before signing. Because policy is checked against exactly what gets signed, the caller cannot pair harmless-looking fields with a different payload. This enables an AI agent to sign only transactions below a defined limit or only for an approved destination. Keys governed by such semantic constraints must allow only structured signing, never raw, digest or free-form EIP-191 messages, because each of these can authorize an action the policy never inspects.

OpenBao: protected key lifecycle and execution

OpenBao provides the mature cryptographic substrate inside the KMS CVM. Its Transit engine and crypto plugins perform cryptographic operations without returning private key material through the API, while OpenBao also maintains key lifecycle state, versioning, metadata, authentication primitives, and audit hooks. The software-defined key abstraction binds this substrate to the tenant/user, KeyId, Cedar policy, cryptographic profile and execution requirements.

In the initial design, the KMS runtime may use a single OpenBao credential with access to all tenants' keys, so OpenBao does not itself enforce the per-key Cedar decision. The guarantee therefore depends on that credential remaining confined to the approved attested KMS CVM,  with no privileged operator access (such as pod exec or port-forward) to OpenBao, and being exercised only by the measured KMS runtime after Cedar returns ALLOW. Longer term, per-tenant scoped OpenBao tokens would improve compartmentalization, but the stronger design is to enforce Cedar at the point of key use: either inside the KMS CVM component that alone holds the OpenBao credential, or  inside an OpenBao plugin itself. That is what makes the policy decision not bypassable by design rather than merely protected by credential confinement.

We start with OpenBao as a single Raft node; for deployments that require high availability, Integrated Storage can extend to a Raft quorum across peer CVMs. This quorum provides availability, state replication, and consensus over service state; it is distinct from threshold cryptography and does not, by itself, distribute signing authority across multiple nodes.

2.5 Trust plane: attestation, confidential execution, transport, and hardware roots

Attestation service: evidence before authority

The architecture uses attestation bidirectionally, but asymmetrically. First, every caller using an attestation-aware client can verify the service CVM before placing trust in the system: the Gateway presents TDX/CVM evidence bound to its service identity, that evidence is verified, and the caller establishes attested TLS (aTLS) only with an approved service-CVM measurement. The same principle applies to unseal secrets and persistent roots: release occurs only after verifying that the intended KMS CVM is running an approved measurement. This still leaves the operator in the shared trust model. Attestation proves that approved code is running, not that the approved code is safe, and an unrestricted unseal secret could potentially be used outside the intended TEE. Reproducible builds, public logs of approved measurements, and unseal keys cryptographically bound to verified TEE state can reduce that residual trust.

Second, the KMS verifies the caller only when the selected KeyId's Cedar policy requires caller-side evidence. In that case, the caller provides a TDX quote bound to the specific request, for example through a hash of the request and a fresh nonce or timestamp, and to a recipient public key whose private key remains confined inside the caller TEE. The attestation service verifies the caller quote and returns signed, normalized claims that the KMS CVM verifies before use; Cedar then adjudicates and evaluates those claims alongside the principal, action, and request context. When a key's policy requires caller attestation, any secret-bearing output (Decrypt, GenerateDataKey, Decapsulate, key-store Get) is encrypted to the request-bound caller key, so neither the caller's host nor the service tier can read the plaintext.

Confidential execution: isolate the point of key use

The near-term target separates the service CVM from the KMS CVM, with Intel TDX serving as the initial confidential-computing substrate for both. The service CVM contains the Gateway, the Orbitport or Direct KMS API path, and the Gateway's KMS plugin. The distinct KMS CVM contains the software-defined key runtime, Cedar policy evaluation, and OpenBao key-use path, ensuring that cryptographic authority is sequestered from the application-facing service tier.

This separation is most consequential at the moment a key is exercised. Encrypting key material at rest is insufficient if plaintext secret material later appears in an ordinary host-controlled process. The architectural objective is to keep policy evaluation, protected key material, and sensitive cryptographic operations co-resident within a single attested confidential-computing boundary. For rollback protection, every unseal carries a monotonic epoch from the operator's store, checked against the value recorded inside OpenBao's encrypted storage, so a stale datastore never serves. Checking freshness at runtime as well, and anchoring the counter in independent hardware, are next steps.

Transport: encrypted and deployment-specific

WireGuard provides the default encrypted transport for Orbitport-managed paths, terminated inside each CVM and bound to attestation (WireGuard keys released only after attestation). Self-managed and on-premise deployments may instead use customer-controlled private connectivity. In either model, privileged network configuration remains deliberately decoupled from cryptographic application logic, ensuring that the component authorized to configure or manipulate the network does not thereby inherit cryptographic authority.

Hardware roots: persistent anchors for programmable trust

CVMs and HSMs address distinct dimensions of the trust architecture. A CVM is programmable and well suited to richer protected computation, whereas an HSM or secure element is optimized for safeguarding small, persistent roots of trust, such as wrapping, sealing, or bootstrap keys. In terrestrial deployments, validated HSMs can be incorporated where regulatory, assurance, or separation-of-duties requirements demand non-exportable hardware roots. In future space-oriented profiles, secure elements are similarly important because they can preserve persistent identity and key anchors across reboots while the surrounding TEE or CVM executes richer, more expressive logic.

The design therefore treats HSMs, secure elements, and CVMs as complementary rather than interchangeable substitutes. The appropriate root of trust is deployment-specific: cloud-native, self-managed, regulated and future space deployments may select different hardware anchors while preserving the same software-defined key and policy model.

2.6 Cryptographic agility: profiles, PQC, and programmable functions

The KMS should not be circumscribed by a single algorithm. Different layers of the system carry different performance, interoperability, and assurance requirements, and the existing architecture already composes multiple primitives: symmetric encryption, signatures, WireGuard and attested-TLS transport, and hardware-backed roots of trust. Transport is part of the PQC migration: recorded traffic can be decrypted once quantum computers exist, so WireGuard's pre-shared key option (with the PSK itself released over a post-quantum channel) and hybrid TLS key exchange protect it against harvest-now, decrypt-later.

The appropriate abstraction is therefore a cryptographic profile rather than a hard-coded primitive. The KMS API can remain stable while the implementation selects algorithms according to the operation, deployment profile, and policy. Post-quantum cryptography (PQC) belongs in this model as a disciplined migration path rather than a one-time substitution. Long-lived systems benefit from PQC-ready and hybrid interfaces before every deployment is compelled to converge on the same primitive.

The same separation creates a natural plugin boundary for cryptographic workflows. New signing schemes, domain-specific primitives, or optional multi-party mechanisms can be introduced behind the stable KMS interface and selected by a key's cryptographic profile. This is where future multisignature or threshold-cryptography plugins can fit without making threshold operation a prerequisite of the base KMS.

Longer term, the same boundary could support Lambda-like programmable KMS functions: small customer-defined or SpaceComputer-provided functions that execute inside an approved confidential-computing boundary close to protected key material. Rather than exporting a key to application logic, a user could bring constrained logic for operations such as transaction validation, custom signing flows, policy-aware transformations, or domain-specific authorization, with Cedar and attestation determining when that function may execute and which cryptographic capabilities it may invoke.

These functions would not receive unrestricted access to private keys; they would execute against a narrow KMS capability interface, preserving the separation between programmable logic and underlying cryptographic authority.

2.7 Shared security model and assurance boundaries

Industry-standard components and a shared security model

The architecture deliberately composes familiar interfaces and security primitives rather than introducing an insular closed stack: a KMS-style API, OpenBao, Cedar policy, confidential VMs such as Intel TDX, standard attestation evidence, HSM/PKCS#11-style hardware roots where appropriate, and conventional secure transport. This makes the system easier to reason about, integrate, audit, and certify, while still allowing SpaceComputer-specific capabilities to be layered on top.

This also makes the shared security model explicit. SpaceComputer can provide measured KMS software, policy and attestation integration, secure defaults, and upgrade paths; the deployment owner retains control over identities, tenant and key policies, approved measurements, application logic, network exposure, and operational recovery. In managed Orbitport deployments, more of that control plane can be provided as a service, while self-managed and on-premise deployments can keep those responsibilities within the customer boundary.

This compositional approach also makes certification easier to define around concrete deployment boundaries.

Certification should follow the deployment boundary

The stack is intended for environments in which architectural claims alone may be insufficient. Financial infrastructure, sovereign deployments, critical systems, and certain AI use cases may require formal assurance. Certification should therefore be designed and organized around tangible, attestable boundaries: the cryptographic module, the TDX environment, the hardware root, the attestation verifier, the policy configuration, operational controls, and the deployed profile.

This approach preserves product practicality. A cloud KMS profile can select validated components and approved algorithms where required, while future remote profiles may emphasize secure boot, attestation, update integrity, and physical separation. Certification is a property of a defined boundary and use case, not a universal label conferred on the entire system.

3. From one trust domain to many

Once a single KMS domain is strongly isolated, attestable, policy-controlled and externally verifiable, the next step is not simply to replicate it, but to determine when sensitive authority should be distributed across independently controlled domains.

Infrastructure diversity and separation of authority are not the same thing.

3.1 Separation of authority, not just infrastructure

High-assurance systems commonly distribute critical infrastructure across multiple failure domains to improve resilience. A second terrestrial region can reduce exposure to localized outages or infrastructure failures; a second cloud provider can reduce dependence on a single operator and technology stack. These are valuable properties, but they primarily improve availability and infrastructure diversity, they do not, by themselves, prevent one domain from exercising cryptographic authority.

An orbital domain adds physical and possibly jurisdictional diversity, but those properties become meaningful separation of authority only when policy or cryptography prevents either domain from acting unilaterally.

3.2 Threshold and multi-signature when the use case warrants it

One possible future step for SpaceComputer’s KMS is to partition particularly sensitive authority across independently operated KMS domains, so that no single machine or organization can unilaterally complete a high-value operation. Multisignature or threshold mechanisms can be introduced through the cryptographic plugin boundary when a use case warrants them, while the default KMS remains simpler, single-domain, and operationally tractable.

Threshold signatures, multisignature schemes, and explicit co-signing are different mechanisms, but they instantiate the same security principle: a protected operation requires concurrence across independently controlled domains. For threshold schemes, this separation holds only when the key is generated through distributed key generation (DKG) and no complete private key ever exists in a single domain.

3.3 SpaceKMS: an additional trust domain

The long-term SpaceComputer opportunity does not depend on space-based computation becoming less expensive than terrestrial computation. Nor does placing a single KMS instance on a satellite, by itself, create meaningful separation of authority; it merely relocates the same singular point of trust. Space becomes strategically significant when it operates as an additional, independently controlled trust domain within an authorization scheme that requires concurrence across more than one domain.

This does not make satellites inherently secure. Orbital systems introduce their own supply-chain, communication, update, operational, and hardware risks. Attestation and secure boot help make each domain verifiable; joint authorization is what converts multiple domains into genuine separation of authority. Space is therefore most valuable as an additional participant in a multi-domain trust model, not a relocated single root of trust.

KMS is the starting product. SpaceKMS is the architectural horizon.

4. What we are really building: SpaceKMS

The KMS trajectory is not fundamentally about the physical location of a private key. It is about the conditions under which cryptographic authority may be instantiated, constrained, and exercised.

In the near term, those conditions are terrestrial and concrete: an authenticated caller, an attested service path, a software-defined key with key-bound policy, a verified confidential-computing boundary, a protected OpenBao-backed key lifecycle, secure transport, auditability, cryptographic agility, and deployment-specific assurance.

These capabilities are valuable to users today, particularly high-assurance services and AI systems that need stronger boundaries between application logic and irreversible actions. If we establish these abstractions correctly on Earth, the future space step becomes far more tractable: we do not need to move the application or the data center; we selectively extend the trust boundary when space provides sufficient additional assurance to justify the cost.

Further reading

• Space Fabric: The Trust Layer in Orbit. Future satellite-native trust architecture and deployment model.
• Space Security: An End-to-End Threat Model for Space Systems. Threat boundaries, evidence, enforcement, and residual risk across Earth-to-orbit systems.
• SpaceComputer Docs: Product concepts and integration guides.
• Orbitport: Gateway to Orbital Services. Orbitport architecture, plugin model, and roadmap.
• Raft: In Search of an Understandable Consensus Algorithm (extended version). the consensus protocol behind OpenBao Integrated Storage.