diff --git a/content/docs/concepts/compare/aws-kms.mdx b/content/docs/concepts/compare/aws-kms.mdx new file mode 100644 index 0000000..bd2a380 --- /dev/null +++ b/content/docs/concepts/compare/aws-kms.mdx @@ -0,0 +1,103 @@ +--- +title: CipherStash vs AWS KMS +navTitle: AWS KMS +description: "Compare AWS KMS envelope encryption with CipherStash ZeroKMS: trust boundaries, per-value keys, batching, audit, searchable encryption, and where each fits." +type: concept +components: [encryption, platform] +audience: [developer, cto, ciso] +reviewBy: "2027-01-31" +--- + +AWS Key Management Service and CipherStash overlap at key management, but they operate at different layers. + +AWS KMS is a general-purpose cloud key service. It protects root keys in AWS-managed hardware security modules and performs cryptographic operations under IAM control. CipherStash is an application-data protection system: the Stack SDK or CipherStash Proxy encrypts individual values, while ZeroKMS supplies one half of a split key-derivation process. + +They are often complementary. AWS KMS is a strong fit for infrastructure encryption and conventional envelope encryption. CipherStash is designed for field-level application data that needs per-value isolation, searchable ciphertext, and a key service that cannot decrypt the data by itself. + +## The architectural difference + +The conventional AWS KMS pattern is envelope encryption: + +1. The application asks KMS to generate or unwrap a data encryption key. +2. KMS returns the plaintext data key to the authorized application. +3. The application encrypts data locally. +4. It stores the wrapped copy of the data key beside the ciphertext. +5. Decryption sends the wrapped key back to KMS to recover the plaintext data key. + +ZeroKMS does not return a data key: + +1. ZeroKMS produces a key seed from its authority key and the value's key ID. +2. The application processes that seed with a client key that never leaves its environment. +3. A unique data key comes into existence locally for one value. +4. The data key is discarded after the operation; it is never stored or transmitted. + +The full mechanism is described in [Cryptography](/security/cryptography#how-a-data-key-is-produced). + +| Property | AWS KMS envelope encryption | CipherStash ZeroKMS | +| --- | --- | --- | +| Root of trust | KMS key protected by AWS-managed HSMs | ZeroKMS authority key plus a client key held by the application | +| Material returned to the client | Plaintext and wrapped data key when using `GenerateDataKey`, or a plaintext key from `Decrypt` | A key seed that is unusable without the client key | +| Data-key persistence | Wrapped data key is normally stored with the ciphertext | Data key is never stored; the payload carries a reproducible key ID | +| Key granularity | Chosen by the application; keys are commonly reused or cached | Unique data key for every encrypted value | +| Server acting alone | KMS can perform an authorized decrypt operation | ZeroKMS cannot derive a usable data key without the client side of the split | + +## Trust and compromise + +AWS KMS keeps key material inside its managed boundary and gives customers detailed IAM policies, grants, encryption context, rotation, and CloudTrail integration. The application still needs credentials that authorize KMS operations, and an authorized KMS response contains the plaintext data key or plaintext data. + +ZeroKMS separates the capability across two systems. Stealing only the application's client key does not permit offline decryption of historical ciphertext, because the attacker still needs an authorized ZeroKMS interaction. Compromising only ZeroKMS is also insufficient because it never receives the client key. + +A live attacker controlling an authorized application can still request operations available to that application until access is revoked. The difference is that the capability remains scoped by keyset and authorization, is observed outside the application, and cannot be copied once as a reusable master key. See the [ZeroKMS trust model](/security/cryptography#trust-model). + +## Per-value keys without data-key caching + +AWS KMS cryptographic APIs operate on individual requests and share regional request quotas. AWS recommends data-key caching when applications need to reduce `GenerateDataKey` traffic. Caching improves throughput by allowing one plaintext data key to protect multiple values, but it also increases the amount of data that key can decrypt. + +ZeroKMS batches the server-side work, then derives each value's distinct key locally. A bulk operation therefore avoids one network round trip per value without turning the batch into one cryptographic failure domain. + +This distinction matters for reads as well as writes. With envelope encryption, independently keyed values require their wrapped keys to be unwrapped. Reusing cached data keys reduces those calls only by placing more values under each reusable key. ZeroKMS retains per-value granularity across scattered query results. + +## Audit granularity + +CloudTrail can record the KMS API operation, principal, KMS key, and request context. If one unwrapped or cached data key decrypts many application values locally, KMS cannot infer which of those values the application read. + +CipherStash key derivation is tied to the value's key ID and keyset. ZeroKMS participates before plaintext recovery, so the independent audit event follows the same per-value boundary as the encryption design. When federated identity is used, that event can also be associated with the authenticated user and lock context. + +## Searching encrypted data + +AWS KMS encrypts and decrypts bytes; it does not make ciphertext queryable. Building searchable fields on top of envelope encryption requires a separate indexing design, query transformation, and leakage analysis. + +CipherStash includes that layer. The client emits ciphertext plus only the searchable terms declared for the column, and [EQL](/reference/eql) gives PostgreSQL typed equality, ordering, range, and fuzzy-match operations. The trade-offs of those terms are covered in [Searchable encryption](/concepts/searchable-encryption). + +## Performance and cost model + +AWS KMS charges for customer-managed keys and API use; cryptographic operations also consume regional request quotas. The exact price and quota depend on key type and region, so production estimates should use the current [AWS KMS pricing](https://aws.amazon.com/kms/pricing/) and [request quota](https://docs.aws.amazon.com/kms/latest/developerguide/requests-per-second.html) documentation. + +CipherStash moves repeated work into local derivation and supports bulk operations. That makes its network cost track the batch rather than the number of values in the batch. Database query performance is a separate concern: published EQL measurements are in [Benchmarks](/reference/benchmarks). + +## Which should you use? + +### AWS KMS is usually the better fit when + +- you are encrypting AWS infrastructure such as S3 objects, EBS volumes, or service-managed resources; +- AWS IAM, CloudTrail, and regional KMS controls are already the operational standard; or +- the application does not need to query encrypted fields. + +### CipherStash is usually the better fit when + +- performance is a primary requirement: ZeroKMS batches the server-side work and derives per-value keys locally, avoiding one KMS network operation per value; +- individual application values need independent keys; +- the key service must not be capable of decrypting data by itself; +- encrypted PostgreSQL fields still need equality, range, ordering, or fuzzy-match queries; +- application identity needs to participate in cryptographic authorization; or +- batching must not require reusing data keys. + +### Use both when + +AWS KMS protects infrastructure and root key material while CipherStash protects sensitive fields inside the application. CipherStash does not replace disk, volume, object, or backup encryption; those layers protect different failure modes. + +## Related + +- [Cryptography and key derivation](/security/cryptography) +- [Searchable encryption](/concepts/searchable-encryption) +- [AWS KMS concepts](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html) diff --git a/content/docs/concepts/compare/fhe.mdx b/content/docs/concepts/compare/fhe.mdx new file mode 100644 index 0000000..0371dfc --- /dev/null +++ b/content/docs/concepts/compare/fhe.mdx @@ -0,0 +1,130 @@ +--- +title: CipherStash vs homomorphic encryption +navTitle: Homomorphic encryption +description: "Compare CipherStash searchable encryption with fully homomorphic encryption: supported computations, performance, leakage, PostgreSQL integration, and where each fits." +type: concept +components: [encryption, eql] +audience: [developer, cto, ciso] +reviewBy: "2027-01-31" +--- + +CipherStash is sometimes described as homomorphic encryption for databases. It is not. CipherStash uses several specialized searchable-encryption mechanisms, each built for a database operation such as equality, ordering, range, or fuzzy text matching. + +Fully homomorphic encryption (FHE) pursues a more general goal: evaluate arbitrary computations over ciphertext and decrypt the result without revealing the inputs to the computing party. + +That difference in ambition drives the practical trade-off. FHE can express computations that CipherStash cannot. CipherStash supports a deliberately narrower query surface that runs inside ordinary PostgreSQL with conventional indexes. + +## At a glance + +| | Fully homomorphic encryption | CipherStash searchable encryption | +| --- | --- | --- | +| Goal | General computation over ciphertext | Practical encrypted database queries | +| Computation model | Arithmetic or Boolean circuits supported by the FHE scheme | Purpose-built equality, ordering, range, fuzzy-match, and JSON terms | +| Database integration | Usually custom application and execution layers | PostgreSQL domains, operators, functions, B-tree and GIN indexes through EQL | +| Information revealed to the data store | Depends on the scheme and surrounding protocol; ciphertext aims to hide inputs and intermediate values | Explicitly reveals equality, order, or probabilistic token overlap for enabled query capabilities | +| Unsupported today in CipherStash | Arbitrary functions, encrypted `SUM` and `AVG`, general ML inference | Not applicable | +| Best fit | Computation where hiding inputs from the computing party justifies substantial complexity | OLTP and application search over protected PostgreSQL fields | + +## Why specialization is faster + +An FHE comparison or equality operation is evaluated as a cryptographic circuit. CipherStash does not evaluate that circuit. It stores a purpose-built term that PostgreSQL can compare or index directly. + +For example: + +- an equality-enabled column carries an HMAC term; +- an orderable column carries an OPE or block-ORE term; and +- a fuzzy-match text column carries an encrypted Bloom-filter term. + +The database learns the structure required for that operation, but gains a query path that resembles a normal indexed PostgreSQL query. [Searchable encryption](/concepts/searchable-encryption) explains exactly what each term reveals. + +## Primitive benchmark: TFHE and ORE + +CipherStash maintains a small open-source benchmark that compares similar primitive operations in the `tfhe` and `ore-rs` libraries. On the recorded Apple M2 run: + +| Operation | TFHE | ORE | Approximate difference | +| --- | ---: | ---: | ---: | +| Encrypt one value | 11.3 ms | 374 µs | 30x | +| Equality | 151 ms | 756 ns | 200,000x | +| Greater than | 162 ms | 750 ns | 215,000x | +| Less than | 166 ms | 755 ns | 220,000x | + +These are **primitive microbenchmarks**, not a claim that every FHE system or every CipherStash query has those timings. They compare one TFHE implementation with one ORE implementation on one machine. The harness and full results are published at [cipherstash/tfhe-ore-bench](https://github.com/cipherstash/tfhe-ore-bench). + +The comparison illustrates why a specialized predicate can be dramatically cheaper than evaluating a general encrypted circuit. End-to-end database performance also includes planning, index traversal, row retrieval, network time, and client decryption. + +## Database performance + +EQL's database benchmarks compare encrypted columns with plaintext PostgreSQL using equivalent indexes. At one million rows on the reference machine: + +| Query | Encrypted median | Relative to plaintext | +| --- | ---: | ---: | +| Exact equality | 0.12 ms | 1.3x | +| OPE range and ordering | 0.12 ms | 1.2x | +| Block-ORE range and ordering | 0.52 ms | 5.2x | +| JSON containment | 0.40 ms | 1.4x | + +Those results measure EQL v3 on PostgreSQL 17, not the SDK-to-database round trip. Methodology, scaling results, ingest performance, and reproduction commands are in [Benchmarks](/reference/benchmarks). + +## What CipherStash supports + +EQL v3 column domains declare the searchable capability stored with each value: + +| Capability | Typical operations | Stored structure | +| --- | --- | --- | +| Equality | `=`, `<>`, `IN`, equijoins, `GROUP BY`, `DISTINCT` | HMAC equality term, or an equality-lossless ordering term for some scalar types | +| Ordering and range | `<`, `<=`, `>`, `>=`, `BETWEEN`, `ORDER BY`, `MIN`, `MAX` | CLLW OPE or block-ORE term | +| Fuzzy text match | `@@` | Encrypted Bloom-filter term | +| JSON search | Path equality, range, and containment | Per-path searchable terms | + +The full type and operator surface is in [EQL core concepts](/reference/eql/core-concepts). + +CipherStash does not currently support arithmetic over encrypted values. `SUM`, `AVG`, multiplication, and arbitrary user-defined computations require decryption at the application boundary or a different cryptographic system. That boundary is intentional rather than hidden behind an inefficient fallback. + +## Leakage is the central trade-off + +FHE is designed so the computing party can evaluate a supported circuit without learning the plaintext inputs or intermediate values. Its practical security still depends on the complete protocol, including who holds keys, which outputs are revealed, and whether access patterns are visible. + +CipherStash makes a different bargain. A column stores only the terms required by its declared query capabilities: + +- equality terms reveal which encrypted values repeat; +- ordering terms reveal relative order; and +- fuzzy-match terms reveal probabilistic token overlap. + +This structure is what lets PostgreSQL use ordinary index machinery. Teams should enable only the capabilities the application actually needs, especially for low-cardinality or highly predictable data. + +## Operational differences + +CipherStash keeps the database model familiar: + +- encrypted values are JSON-backed EQL domains; +- ordinary SQL operators express supported queries; +- B-tree and GIN indexes accelerate the corresponding terms; +- the Stack SDK, ORM integrations, or Proxy encrypt query operands; and +- PostgreSQL never receives the data key or plaintext operand. + +FHE applications generally need a computation expressed for a particular scheme or compiler, ciphertext parameter management, evaluation-key distribution, and an execution environment sized for the circuit. That can be the correct engineering choice when the computation itself must remain hidden, but it is a different system from adding encrypted predicates to an existing relational application. + +## Which should you use? + +### FHE is the better fit when + +- an untrusted compute service must evaluate a genuinely general function over private inputs; +- the required computation cannot be reduced to CipherStash's supported query capabilities; +- encrypted inference, private analytics, or multiparty computation is central to the product; and +- the latency, ciphertext size, and operational complexity fit the workload. + +### CipherStash is the better fit when + +- the application needs equality, range, ordering, fuzzy matching, or JSON search over protected fields; +- queries must run in standard PostgreSQL and work with existing SQL tooling; +- low-latency OLTP behavior matters; and +- the team accepts the explicit leakage profile of the selected capabilities. + +The choice is not “strong cryptography versus weak cryptography.” It is general encrypted computation versus specialized encrypted queries with different performance and disclosure properties. + +## Related + +- [Searchable encryption](/concepts/searchable-encryption) +- [EQL reference](/reference/eql) +- [EQL benchmarks](/reference/benchmarks) +- [TFHE/ORE benchmark source](https://github.com/cipherstash/tfhe-ore-bench) diff --git a/content/docs/concepts/compare/hashicorp-vault.mdx b/content/docs/concepts/compare/hashicorp-vault.mdx new file mode 100644 index 0000000..241f5e3 --- /dev/null +++ b/content/docs/concepts/compare/hashicorp-vault.mdx @@ -0,0 +1,123 @@ +--- +title: CipherStash vs HashiCorp Vault +navTitle: HashiCorp Vault +description: "Why ZeroKMS is a faster and stronger security model than HashiCorp Vault Transit for high-volume application data encryption." +type: concept +components: [encryption, platform] +audience: [developer, cto, ciso] +reviewBy: "2027-01-31" +--- + +HashiCorp Vault is a broad secrets-management and cryptographic platform. The closest comparison with CipherStash is its **Transit secrets engine**, which offers encryption operations without storing the application data. + +For high-volume application data encryption, ZeroKMS has two decisive advantages: + +1. **Performance:** ZeroKMS was designed to derive a unique key for every value in bulk. A batch requires one service interaction, while final key derivation and encryption happen locally and scale with the application. +2. **Security:** Vault either receives the plaintext or holds everything required to unwrap its data keys. ZeroKMS never receives plaintext and cannot derive a usable data key without the client key held in your environment. + +Vault remains a strong general-purpose platform for secrets, PKI, signing, and centralized cryptographic services. ZeroKMS is the stronger fit when the workload is protecting large volumes of application values. + +## Performance is the first difference + +Vault Transit supports batching, but the work still follows one of two centralized models. + +### Direct Transit centralizes every cryptographic operation + +In direct mode, the application sends every plaintext value to Vault. Vault encrypts every value and returns the ciphertext. `batch_input` reduces the number of HTTP round trips, but it does not move the cryptographic work out of the Vault cluster. + +Throughput therefore depends on the capacity of the Vault deployment. Scaling application workers does not scale encryption unless the Vault cluster scales with them. Every byte of plaintext also crosses the service boundary in both directions over its lifetime: into Vault for encryption and out of Vault after decryption. + +### Transit envelope mode still produces complete data keys + +Envelope mode moves the final encryption into the application. Vault generates a plaintext data key plus a wrapped copy, the application encrypts locally, and the wrapped data key is stored with the ciphertext. Decryption sends that wrapped key back to Vault to recover the plaintext data key. + +Current Vault versions document a plural `datakeys` endpoint that can return multiple key pairs in one request. That removes the old one-request-per-key limitation, but Vault must still generate and wrap a complete data key for every independently keyed value. The application must persist every wrapped data key and send it back for unwrapping on reads. + +### ZeroKMS was designed for per-value bulk encryption + +ZeroKMS returns key seeds rather than complete data keys. One bulk service interaction supplies the material for a batch, then the application combines each seed with its client key and derives each value's unique data key locally. + +The final derivation and AES operations scale horizontally with the application rather than being concentrated in the key-service cluster. No plaintext data key is transmitted, no wrapped data key is persisted, and performance does not depend on reusing or caching a data key across values. + +| Performance property | Vault direct | Vault envelope | ZeroKMS | +| --- | --- | --- | --- | +| Network interactions for a batch | One with `batch_input` | One where plural `datakeys` is available | One bulk interaction | +| Who performs value encryption? | Vault cluster | Application | Application | +| Server-side work per value | Encrypt or decrypt the value | Generate, wrap, or unwrap a complete data key | Produce seed material; final derivation remains local | +| Material stored per value | Vault ciphertext | Ciphertext plus wrapped data key | Ciphertext plus non-secret key ID | +| How encryption throughput scales | Scale the Vault cluster | Scale Vault key generation and application workers | Scale application workers | +| Does performance require data-key reuse? | A named Transit key is normally shared | Reuse is optional but expands key blast radius | No; every value always receives a unique key | + +The exact latency of Vault depends on cluster size, storage, seal configuration, network placement, and mode. The architectural distinction is stable: ZeroKMS keeps the network interaction at batch granularity while distributing the final cryptographic work across the application fleet. + +## The security model is the second difference + +### Vault direct mode sees plaintext + +Direct Transit is encryption as a remote service. The application sends plaintext to Vault and Vault returns it during decryption. Anyone who controls the authorized Vault boundary has a path to both keys and data during the operation. + +Policies, audit devices, HSM-backed seals, and operational controls can harden that boundary. They do not remove it from the plaintext trust model. + +### Vault envelope mode can unwrap every data key + +Envelope encryption keeps application plaintext out of Vault, but Vault still holds the Transit key that unwraps every stored data key. An authorized Vault operation can return a complete plaintext data key without needing cryptographic material held separately by the application. + +Envelope mode also introduces durable wrapped-key material that must be stored and mapped to the correct ciphertext. If a plaintext data key is copied from application memory, it remains usable offline for every value protected by that key. + +### ZeroKMS splits the decryption capability + +ZeroKMS holds an authority key. The application holds a client key that never leaves its environment. Neither side can derive a data key alone, and the two long-lived components are never brought together. + +The encrypted payload contains a key ID, not a wrapped data key. Stealing the client key alone does not permit offline decryption of historical ciphertext; ZeroKMS must still authorize and participate in future derivations. Compromising ZeroKMS alone is also insufficient because it never receives the client key. + +A live attacker controlling an authorized application can use the operations granted to it until access is revoked. The important difference is that the capability remains **scoped, observable, and revocable** rather than becoming a complete key that can be copied and used offline. + +| Security property | Vault direct | Vault envelope | ZeroKMS | +| --- | --- | --- | --- | +| Plaintext reaches the key service | Yes | No | No | +| Key service can enable decryption alone | Yes | Yes, by unwrapping the data key | No | +| Client-held cryptographic half required | No | No | Yes | +| Complete data key crosses the network | Not exposed to the application in direct mode | Yes | No | +| Per-value key material stored | Ciphertext carries the Transit key version | Wrapped data key | Non-secret key ID | +| Unique key per value | Must be designed through context or separate keys | Must be designed through separate data keys | Always | +| Offline value of a copied application secret | A Vault token still needs the Vault service | A copied plaintext data key can decrypt every value that reused it | The client key alone cannot derive any historical data key | + +The full ZeroKMS mechanism and compromise model are in [Cryptography](/security/cryptography#trust-model). + +## Audit granularity + +Vault audit devices record requests to the service. In direct mode, a batch records a Transit operation over the batch. In envelope mode, Vault observes data-key generation and unwrapping; how those keys map to application records is left to the application's storage and metadata design. + +ZeroKMS makes the value's key ID and keyset part of derivation. Every decryption needs server participation before plaintext recovery, so independent audit follows the same per-value boundary as the key model. Federated identity and lock contexts can also bind that operation to an authenticated end user. See [Provable access control](/solutions/provable-access). + +## Searching encrypted data + +Vault's convergent encryption can make the same plaintext and context produce the same ciphertext, enabling limited deterministic lookup. It exposes equality directly in the ciphertext and does not provide range, ordering, fuzzy matching, JSON search, or PostgreSQL operator integration by itself. + +CipherStash separates randomized ciphertext from purpose-built search terms. The EQL domain selected for a column declares exactly which operations it supports and which structure the database learns. See [Searchable encryption](/concepts/searchable-encryption) for the leakage model and [EQL core concepts](/reference/eql/core-concepts) for the type system. + +## Which should you use? + +### CipherStash ZeroKMS is usually the better fit when + +- **performance is a primary requirement for high-volume field encryption;** +- the key service must never receive plaintext or possess enough material to decrypt alone; +- unique per-value keys must not require key caching or reuse; +- PostgreSQL must query protected fields while they remain encrypted; or +- key derivation, database types, SDKs, ORM wrappers, audit, and identity binding should work as one system. + +### Vault Transit is usually the better fit when + +- Vault is already the organization's standard security platform; +- the workload needs Vault's broader secrets, PKI, signing, HMAC, or tokenization capabilities; +- centralized encryption inside the Vault boundary is acceptable; or +- the organization wants to own and operate the complete cryptographic service. + +The products can coexist: Vault can manage infrastructure secrets and other cryptographic workloads while CipherStash protects high-volume, queryable application data. + +## Related + +- [Vault Transit documentation](https://developer.hashicorp.com/vault/docs/secrets/transit) +- [Vault Transit API](https://developer.hashicorp.com/vault/api-docs/secret/transit) +- [Cryptography and key derivation](/security/cryptography) +- [Searchable encryption](/concepts/searchable-encryption) diff --git a/content/docs/concepts/compare/index.mdx b/content/docs/concepts/compare/index.mdx index 0615aa1..c5e64de 100644 --- a/content/docs/concepts/compare/index.mdx +++ b/content/docs/concepts/compare/index.mdx @@ -1,10 +1,22 @@ --- title: Comparisons -navTitle: Overview -description: "How CipherStash compares to other approaches to protecting data." +description: "How CipherStash compares with cloud key management, HashiCorp Vault, hardware security modules, and fully homomorphic encryption." type: concept --- -This section is being built as part of the docs V2 overhaul ([CIP-3307](https://linear.app/cipherstash/issue/CIP-3307)). Track progress in [IA.md](https://github.com/cipherstash/docs/blob/v2/IA.md). +CipherStash combines application-level encryption, zero-trust key management, and purpose-built searchable encryption. These pages compare that combination with tools that overlap with one part of the system. -Until it lands, current documentation lives in the [existing docs](/stack). + + + Centralized cloud key management compared with ZeroKMS split control and per-value key derivation. + + + Vault Transit direct and envelope modes compared with ZeroKMS and searchable encryption. + + + Where HSMs fit, what operating one entails, and how the two approaches can complement each other. + + + Specialized encrypted database queries compared with general computation over ciphertext. + + diff --git a/content/docs/concepts/compare/meta.json b/content/docs/concepts/compare/meta.json index 3e374e5..2357b87 100644 --- a/content/docs/concepts/compare/meta.json +++ b/content/docs/concepts/compare/meta.json @@ -1,5 +1,5 @@ { "title": "Comparisons", "icon": "Scale", - "pages": ["index", "..."] + "pages": ["!index", "aws-kms", "hashicorp-vault", "zerokms-vs-hsm", "fhe"] } diff --git a/content/docs/concepts/compare/zerokms-vs-hsm.mdx b/content/docs/concepts/compare/zerokms-vs-hsm.mdx new file mode 100644 index 0000000..5ad1539 --- /dev/null +++ b/content/docs/concepts/compare/zerokms-vs-hsm.mdx @@ -0,0 +1,91 @@ +--- +title: ZeroKMS vs hardware security modules +navTitle: ZeroKMS vs HSMs +description: "Compare ZeroKMS with dedicated hardware security modules: custody, trust boundaries, integration, availability, per-value keys, and complementary deployment patterns." +type: concept +components: [platform] +audience: [cto, ciso] +reviewBy: "2027-01-31" +--- + +A hardware security module (HSM) is a tamper-resistant hardware boundary for generating, storing, and using cryptographic keys. ZeroKMS is a key-management protocol and service for deriving application data keys without either the service or application holding enough long-lived material to derive them alone. + +They are not exact substitutes. An HSM answers **where and under whose physical control a key is protected**. ZeroKMS answers **how authority is divided and how a unique key is made practical for every application value**. + +## Where HSMs fit + +HSMs are commonly used to protect certificate-authority keys, payment keys, code-signing keys, database master keys, and the root keys behind managed KMS products. They provide a well-defined cryptographic boundary, strong resistance to key extraction, and certifications required by some regulatory or procurement regimes. + +An HSM does not by itself provide an application encryption model. Teams still need to decide: + +- which keys exist and how much data each protects; +- how applications authenticate and are authorized; +- whether applications send plaintext to the HSM boundary or receive data keys; +- how keys are rotated, backed up, replicated, and destroyed; and +- how database queries work over encrypted fields. + +ZeroKMS is focused on those application-level decisions. Its authority keys are protected server-side, while each workload holds a separate client key. The two sides produce unique data keys locally through the process described in [Cryptography](/security/cryptography#how-a-data-key-is-produced). + +## Comparison + +| Property | Dedicated HSM deployment | CipherStash ZeroKMS | +| --- | --- | --- | +| Primary security boundary | Tamper-resistant hardware and its operator controls | Split authority key and client key in separate environments | +| Long-lived key custody | Customer or cloud operator controls the HSM partition | CipherStash protects the authority side; customer protects the client side | +| Application data-key model | Designed by the customer or KMS layer built above it | Unique derived key for every encrypted value | +| Can one boundary decrypt alone? | Usually yes, when the HSM and authorization policy permit the operation | No; neither authority nor client key is sufficient alone | +| Application integration | PKCS #11, JCE, CNG, or a KMS/service layer | Stack SDK, ORM integrations, or CipherStash Proxy | +| Scaling | Appliance, partition, cluster, or provider capacity planning | Batched server interaction and local per-value derivation | +| High availability and recovery | Customer or provider must design clustering, backup, quorum, and ceremonies | Operated as part of the ZeroKMS service; encrypted application data remains in the customer's database | +| Searchable database fields | Not supplied by the HSM | Built into CipherStash through EQL | + +## Custody and split control + +Owning an HSM gives an organization direct control over the hardware boundary and its administrative procedures. That can be essential when a policy requires customer-held hardware, witnessed key ceremonies, a particular FIPS validation level, or an offline signing environment. + +Hardware custody does not automatically create split cryptographic control. An authorized application or operator may still ask the HSM to use the protected key. The security boundary is strong, but it is centralized. + +ZeroKMS distributes that capability. The authority side can produce only a key seed; it cannot turn that seed into a data key. The client side cannot reproduce seeds by itself. Compromise must cross both boundaries, and client access can be revoked at ZeroKMS without relying on the application to honor the decision. + +## Integration and operations + +Direct HSM integration normally uses low-level standards such as PKCS #11, or a higher-level key-management service built on top. Production operation also needs capacity planning, redundant devices or partitions, secure backup, credential quorum, monitoring, firmware management, and tested disaster recovery. + +Those costs can be worthwhile when the HSM boundary is itself the requirement. They are often unnecessary complexity when the real requirement is protecting application fields with fine-grained, revocable keys. + +CipherStash provides that higher layer. The SDK and Proxy handle encryption payloads, key IDs, bulk derivation, searchable terms, and identity binding. The database stores ciphertext while ZeroKMS handles only the server side of key derivation. + +## Performance and key granularity + +An HSM performs bounded cryptographic operations. Giving every database value a unique HSM-backed key can turn a bulk query into many service or device operations, so systems commonly introduce envelope keys, caching, or reuse. + +ZeroKMS batches the server-side work and derives the final keys locally. Every value can retain a distinct key without sending every encryption operation through a hardware boundary and without keeping a cache of plaintext data keys. + +## When to choose an HSM + +A dedicated HSM is usually appropriate when: + +- a regulation, customer contract, or internal policy explicitly requires a validated hardware boundary; +- the organization must retain physical or administrative custody of root keys; +- keys must operate in an offline or air-gapped environment; +- the workload is certificate issuance, payment processing, signing, or another HSM-native use case; or +- the organization already has the people and procedures to operate the hardware safely. + +## When to choose ZeroKMS + +ZeroKMS is usually appropriate when: + +- the workload is field-level application encryption; +- one service or operator must not hold unilateral decryption capability; +- each value needs an independent key and audit boundary; +- high-volume batches must not require data-key reuse; or +- encrypted PostgreSQL data still needs to be queried. + +## Use them together + +The strongest design may use both. An HSM or HSM-backed cloud KMS can protect root key material, while ZeroKMS supplies split control and per-value derivation above it. The HSM remains the hardened foundation; ZeroKMS defines the application-facing trust model. + +## Related + +- [Cryptography and key derivation](/security/cryptography) +- [ZeroKMS vs AWS KMS](/concepts/compare/aws-kms) diff --git a/public/images/hsm.png b/public/images/hsm.png new file mode 100644 index 0000000..ccb6eda Binary files /dev/null and b/public/images/hsm.png differ