Why H33 Substrate doesn't replace AWS KMS (and why that's the whole point)

I have had several conversations in the last week that start the same way: "So you are building a post-quantum alternative to AWS KMS?" The question is understandable. AWS Key Management Service is the incumbent for cryptographic infrastructure in the AWS ecosystem, it is classical-only (no post-quantum support in the current product), and a post-quantum cryptographic primitive is the kind of thing that might plausibly replace it. Several commercial vendors have pitched themselves explicitly as "post-quantum KMS replacements," and those pitches create the frame that anyone building post-quantum cryptographic infrastructure must be trying to replace KMS.

But that is not what we are doing, and I want to explain why the positioning is deliberately different and why the distinction matters for anyone evaluating the substrate against KMS (or Google Cloud KMS, or HashiCorp Vault, or any of the other key-management-first products in the commercial cryptographic infrastructure space).

The short version: AWS KMS is a key management system, and the substrate is an attestation primitive. These are different categories of infrastructure that solve different problems. A deployment that uses the substrate typically still has a KMS in the picture for the operational key management that KMS is good at. The substrate does not try to replace the KMS; it sits in a different layer of the stack and composes with the KMS for workloads that need both.

This post walks through the specific differences between key management and attestation as categories, and the reasons the substrate chose to be one rather than the other.

Key management versus attestation

Start with precise definitions. These terms get used loosely in commercial materials, and the loose usage conflates categories that are actually distinct.

A key management system is a service that generates, stores, rotates, uses, and destroys cryptographic keys on behalf of its users. The specific operations a KMS supports are: create a new key (either symmetric or asymmetric), encrypt data with a key (directly or via envelope encryption), decrypt data with a key, sign data with a key, verify a signature with a key, rotate a key to a new version while preserving the old version for decrypting historical data, and delete a key. The KMS is the authority on which keys exist, who can use them, and what they can do. The security of the system depends on the KMS protecting the keys from unauthorized access.

AWS KMS is the canonical example of this category. It provides symmetric keys (AES-GCM), asymmetric keys (RSA-2048, RSA-3072, RSA-4096, ECDSA on P-256/P-384/P-521, and ECC for ECDH), and related operations. It integrates with every AWS service that needs cryptographic keys — S3 server-side encryption, Lambda environment variable encryption, EBS volume encryption, RDS encryption at rest, Secrets Manager secret encryption, and many others. The service is fully managed, available via API, and billed per operation.

An attestation primitive is something different. An attestation primitive is a cryptographic object whose purpose is to bind the output of a specific computation to a signer's identity, in a way that can be independently verified at arbitrary future times. The specific operation an attestation primitive supports is: produce an attestation for a given input, and verify an attestation against a given signer's public key. The primitive is not about storing keys or enabling encryption; it is about creating persistent, verifiable records of "who vouched for what, when."

The substrate is an attestation primitive. It produces 74-byte persistent records binding computation outputs to three-family post-quantum signatures, with the specific goal of letting third parties verify those records years or decades later. The substrate does not encrypt data. It does not decrypt data. It does not manage keys in any meaningful operational sense — the signing keys are generated once per deployment inside a Trusted Execution Environment and used for the lifetime of the deployment, with key rotation as a relatively rare event rather than a continuous operational concern.

These are different categories. A KMS is a key management service; a substrate is an attestation primitive. A product that claims to be both is usually compromising on one or the other, because the design choices that make a good KMS are different from the design choices that make a good attestation primitive.

Where KMS is strong

AWS KMS (and its counterparts at Google, Azure, and others) is extremely good at several things, and it is worth enumerating them so that the non-replacement framing is clear.

Operational key management at scale. KMS handles millions of keys per customer account without difficulty. It rotates keys on schedules, maintains version history for historical decryption, enforces access policies via IAM, and integrates with every AWS service that needs keys. This is a lot of operational surface area, and KMS handles it with the polish of a decade-plus of commercial development.

Envelope encryption integration. KMS's most common workload is envelope encryption: the customer's data is encrypted with a data key, and the data key is wrapped by a KMS-managed master key. The wrapped data key travels with the encrypted data, and KMS is called to unwrap the data key when decryption is needed. This pattern works well at scale because the data encryption is done locally (with cheap symmetric crypto) and only the key wrapping goes through KMS. The substrate does not do envelope encryption at all — it is not in the envelope encryption business.

Fine-grained access control via IAM. KMS integrates deeply with AWS IAM, so access to keys can be controlled by IAM policies attached to users, roles, or resources. This is a mature access control model that enterprise customers are used to reasoning about, and it is integrated with every other AWS service's access control. The substrate has no equivalent — it is a signing runtime, not a service with its own access control layer. A customer running the substrate has to wrap it in their own access control infrastructure, which is typically based on their existing IAM or equivalent.

Compliance certifications. KMS is certified against FIPS 140-2 Level 3 (via AWS CloudHSM Classic or dedicated KMS endpoints), SOC 1/2/3, PCI-DSS, HIPAA BAA, FedRAMP Moderate and High, ISO 27001, and many other standards. The compliance portfolio is the result of years of commercial investment and audit work, and it is what makes KMS acceptable for regulated workloads today. The substrate's compliance portfolio is a work in progress, and for customers whose compliance framework requires certifications today, KMS (or another mature commercial key management product) is the right choice.

Low per-operation cost at scale. KMS charges approximately $0.03 per 10,000 operations (for most operation types), which works out to an extremely low marginal cost for individual operations. At the scale of a typical enterprise workload, the KMS costs are a rounding error in the cloud bill. The substrate's cost structure is different and is not directly comparable because the substrate charges per-mint for attestations, while KMS charges per-operation for key management — these are different units of work.

Strong vendor relationship for AWS customers. If you are already deeply integrated with AWS, you already have a vendor relationship with Amazon that covers KMS. Adding another commercial cryptographic product adds another vendor relationship, which adds procurement overhead, legal review, and ongoing vendor management. For customers who want to minimize the number of commercial vendors in their stack, "use what you already have" is the default choice.

Each of these strengths is real. KMS is a good product, and the fact that we are not trying to compete with it is not because we think KMS is bad. It is because KMS solves a different problem.

Where KMS is not the right tool

KMS's strengths come with corresponding gaps in areas where the substrate is designed to operate. The gaps are not flaws in KMS — they are design consequences of KMS being a key management service rather than an attestation primitive.

KMS does not produce persistent verifiable records of signed computations. KMS can sign arbitrary data, but the signatures are not tied to a specific wire format, are not committed to a compact receipt, and are not designed to be verified by third parties far in the future. A signature from KMS is a blob of bytes that the customer can store and show to verifiers, but the verification procedure for a KMS signature requires the verifier to trust AWS's public key infrastructure and the AWS CA chain. Over a long time horizon, this becomes a dependency that is hard to maintain — the verifier has to track AWS's key rotations, has to maintain a trusted copy of AWS's root CA, and has to handle the case where AWS at some future time deprecates the signing algorithm and reissues keys under a new format. For a cryptographic attestation that is meant to remain verifiable for decades, the KMS signature model is not the right abstraction.

KMS does not support post-quantum algorithms. As of this writing, KMS supports RSA (2048, 3072, 4096), ECDSA (P-256, P-384, P-521), and symmetric AES. All of these are classical, meaning they are vulnerable to attack by a sufficiently large fault-tolerant quantum computer. AWS has announced post-quantum hybrid modes for TLS termination (in KMS-adjacent services like CloudFront) but has not, at the time of this writing, released a post-quantum signing option in KMS itself. A customer who wants post-quantum signatures for their attestation workload cannot get them from KMS, and has to use a different tool for the signing operation.

KMS signatures are single-family. When KMS signs with RSA-2048, the signature's security depends on the hardness of integer factorization. When KMS signs with ECDSA-P256, the security depends on the hardness of the elliptic curve discrete logarithm problem. In both cases, a single cryptographic hardness assumption underlies the signature's security. A cryptanalytic breakthrough against that single assumption breaks every historical signature produced under it, because the adversary can now forge signatures retroactively. The substrate's three-family bundle is designed specifically to resist this failure mode, at the cost of producing larger signatures. KMS does not offer a three-family option.

KMS signatures do not have a fixed small persistent footprint. An RSA-2048 signature is 256 bytes, an ECDSA-P256 signature is typically 64-72 bytes after DER encoding, and an ECDSA-P384 signature is a bit larger. None of these is the 74-byte persistent footprint that the substrate's compact receipt provides. For workloads that anchor signatures to blockchains or storage-expensive environments, the byte savings of the substrate's compact receipt are meaningful, and they are not achievable by simply using KMS with the current supported algorithms.

KMS does not do Merkle aggregation. If you want to sign a million independent events, KMS expects you to call the sign API a million times. There is no batched-signing API that produces a single root signature over a Merkle tree of events. The per-signature cost is low enough that a million calls is feasible, but the structural cost is linear in the number of events, and the amortization benefits of Merkle aggregation are not available. The substrate's batched Merkle aggregation (covered in a separate post in this series) is a specific structural advantage that KMS does not replicate.

KMS signatures cannot be independently verified without trusting AWS. To verify a KMS signature, you need the KMS-signed certificate chain, which ultimately roots in AWS's CA. If AWS is unavailable (hypothetically — for the sake of argument), or if the verifier does not have a trusted copy of AWS's root CA, verification cannot be completed. The substrate's verifier, by contrast, is source-available and has no runtime dependency on our infrastructure at verification time. A verifier with the substrate, the compact receipt, the signature bundle, and the signer's published public keys can verify independently with no runtime dependency on us, because the verifier code is source-available under a proprietary license (auditable, independently compilable) and the public keys are distributed as a static artifact.

KMS audit logs are internal to AWS CloudTrail. If you want to prove "AWS KMS signed this data at this time," your evidence is the CloudTrail log entry, which lives inside your AWS account. A third party who wants to verify the claim has to either trust you to produce the log entry correctly, or has to have access to your AWS account. The substrate's analogous mechanism — the Bitcoin chain metering — uses a public blockchain that any third party can read, and the on-chain record of a substrate's signing message is observable to anyone with a Bitcoin node. The transparency is structurally different.

Each of these gaps is the same kind of thing: KMS is a key management service and its cryptographic operations are designed to fit into the key management context. When you need a different context — persistent attestations, post-quantum signatures, third-party-verifiable records, batched aggregation, compact footprints — KMS is not the right tool, and the substrate is.

The composition pattern

The right way to think about the substrate and KMS in a deployment is as complementary tools that compose, not as alternatives that one replaces the other.

A typical composition looks like this:

KMS for operational key management. The customer's application data is encrypted with KMS-managed keys using envelope encryption. When a piece of data needs to be decrypted, the application calls KMS to unwrap the data key. This is the standard KMS workflow and it is unchanged by adding the substrate.

Substrate for attestation of the computation. When the application performs a computation whose result needs to be attested (say, a fraud score, a credit decision, a biometric match, a regulatory submission), the application calls the locally-running substrate runtime to produce a substrate attesting the result. The substrate's content hash binds to the canonical encoding of the result, and the substrate's three-family signature bundle is produced inside the TEE.

KMS for long-term encryption key protection. The encryption keys themselves are rotated, audit-logged, and access-controlled via KMS's standard mechanisms. The substrate does not touch these keys.

Substrate for long-term attestation key protection. The three-family signing keys used by the substrate runtime are generated inside the TEE at first launch and never leave it. The substrate does not expose these keys to KMS or to any external key management system; they are local to the enclave.

Both for compliance coverage. KMS's compliance certifications (FIPS 140-3, SOC 2, HIPAA BAA) cover the key management layer, and the substrate's compliance certifications (on the roadmap) cover the attestation layer. A regulated deployment needs both layers covered, and the composition gives you both without duplication.

The key observation is that KMS and the substrate operate on different data. KMS operates on encryption keys and the operational metadata around them. The substrate operates on computation outputs and the attestation records for them. These are different data with different lifecycles and different access patterns, and they are best managed by different tools optimized for their respective data types. Trying to use a single tool for both ends up being a worse fit for both, because the tools that are good for keys are not optimized for persistent attestations and vice versa.

This composition pattern is not unique to the substrate. It is how most complex cryptographic deployments are structured — a key management system for operational keys, a specialized signing or attestation system for the records that need long-term verification, and whatever glue code is needed to keep the two systems synchronized. The substrate is the specialized piece in this composition, and KMS (or Google Cloud KMS, or HashiCorp Vault, or Fortanix DSM) is the operational key management piece.

Why we don't try to replace KMS

Given that there is a gap between KMS and attestation, a natural question is: why did we not build a post-quantum KMS and try to compete with AWS directly? The answer is that building a competitive KMS is a massive undertaking that would have made us worse at the substrate, and the substrate is the thing we are actually good at.

A competitive KMS is, at minimum, a managed service with: a multi-tenant database of keys, an IAM integration, a region-scoped deployment, a certificate authority, a multi-cloud or multi-region HA story, FIPS 140-3 validated HSMs or enclaves, a compliance portfolio covering FIPS, SOC 1/2/3, HIPAA, PCI-DSS, FedRAMP, and others, a 99.99% uptime SLA, 24/7 support, a billing integration with enterprise procurement systems, a documentation site, a partner ecosystem, and probably a few hundred additional things I have not listed. All of this is table stakes for a KMS that enterprise customers would consider alongside AWS KMS.

The amount of work required to build all of this to the level where customers would consider it equivalent to AWS KMS is substantial. The amount of work required to convince customers to trust a new entrant in the space, against an incumbent with a decade of AWS infrastructure behind it, is even more substantial. We would be spending years catching up on features that KMS already has, and the time we spent catching up would be time not spent on the substrate primitive itself.

Instead, we chose to build the substrate as a primitive that composes with whatever KMS the customer is already using. The customer does not have to switch key management systems to use the substrate. They do not have to establish a new vendor relationship for key management. They do not have to re-audit their encryption pipeline. They add the substrate for the specific workload that needs attestation, and the rest of their cryptographic infrastructure stays the same.

This is a much lower-friction adoption path than "switch your KMS to a post-quantum alternative," and it lets the substrate serve customers who would never have switched KMS but who do need post-quantum attestation for a specific workload. The positioning is deliberate and it is what makes the substrate adoptable in practice.

What the substrate adds that KMS can't

To close this post with a concrete framing: when a customer comes to us asking about post-quantum cryptographic infrastructure, we have a clear answer about where the substrate fits in their existing stack.

If the customer asks: "Can you replace my KMS?" — the answer is no, and the customer should keep using their KMS (or an equivalent) for operational key management.

If the customer asks: "Can you give me post-quantum signatures for my attestation workload?" — the answer is yes, and the substrate is the right tool.

If the customer asks: "Can you give me persistent, verifiable records of my computations that remain valid for decades?" — the answer is yes, and the substrate's persistent compact receipt is the specific mechanism that provides this.

If the customer asks: "Can I prove to a regulator that a specific computation happened at a specific time under a specific signing authority?" — the answer is yes, because the substrate's anchoring to Bitcoin provides an immutable timestamp that the customer and the regulator can independently verify.

If the customer asks: "Can I reduce my per-event signing cost by several orders of magnitude through batching?" — the answer is yes, because the substrate's Merkle aggregation allows a single root substrate to commit to a large batch of per-event attestations.

If the customer asks: "Can I have three independent post-quantum signatures on every attestation, so that a cryptanalytic breakthrough against one family does not invalidate my historical records?" — the answer is yes, and this is one of the substrate's defining security properties.

If the customer asks: "Can I manage my KMS keys, my IAM policies, my envelope encryption, my secrets manager, and my SSL certificates through a single interface?" — the answer is no, and they should use KMS for that. The substrate is not trying to be KMS.

These are the questions that clarify the positioning. KMS and the substrate are tools for different problems, and they compose cleanly when a customer has both problems. Neither one is trying to be the other, and neither one would be improved by trying.

Closing

The positioning of the substrate as "not a KMS replacement" is deliberate, and it is the positioning that lets the substrate be adopted by customers who already have a KMS in their stack and do not want to replace it. A customer using AWS KMS, Google Cloud KMS, HashiCorp Vault, or Fortanix DSM for their operational key management can add the substrate for their attestation workload without disrupting the rest of their cryptographic infrastructure. The two tools coexist because they solve different problems.

For a reader who came to this series expecting a post-quantum KMS alternative, I hope this post clarifies why the substrate is a different category of product. For a reader evaluating the substrate against their existing KMS, I hope this post makes the composition pattern clear: keep your KMS, add the substrate for the specific workloads that need attestation, and let the two layers do what each is good at.

The next post in this series is more playful — a calculation of how many attestations fit into a single Bitcoin block under the substrate's batched Merkle aggregation, and why the answer is surprising. See you there.