diff --git a/content/stack/reference/comparisons/aws-kms.mdx b/content/stack/reference/comparisons/aws-kms.mdx index 24a2e35..a9cf5b7 100644 --- a/content/stack/reference/comparisons/aws-kms.mdx +++ b/content/stack/reference/comparisons/aws-kms.mdx @@ -1,326 +1,177 @@ --- title: CipherStash vs AWS KMS -description: Compare CipherStash Encryption and AWS KMS for application-level encryption, covering searchable encryption, bulk operations, and developer experience. +description: How CipherStash compares to AWS KMS for application-level encryption — the distributed-trust ZeroKMS key-management architecture, plus a developer-experience comparison covering searchable encryption, identity-aware keys, bulk operations, and type safety. --- -Encrypting data should not require managing binary buffers, base64 encoding, key ARNs, or building custom search solutions. CipherStash Encryption eliminates these complexities with a developer-friendly API. +CipherStash and AWS KMS solve overlapping problems differently. AWS KMS is a centralized key-management service: keys live in AWS-controlled HSMs, and it returns binary ciphertext that you encode and store yourself. CipherStash encrypts application data through a developer SDK backed by **ZeroKMS**, a key-management service that issues a unique key per record and never holds the keys needed to decrypt your data. -## The simple truth: Encrypting a value +This page compares them on two axes: the **architecture and trust model**, and the **developer experience** of encrypting application data. -Start with the most basic operation: encrypting a single value. +## What's being compared -### AWS KMS: Manual work required +| Term | What it is | +|---|---| +| **AWS KMS** | AWS's managed key-management service. Keys live in AWS-controlled HSMs; you call `Encrypt`/`Decrypt` and manage ciphertext storage yourself. | +| **ZeroKMS** | CipherStash's key-management service. Derives a unique key per record on demand from client- and server-side components; no party — including CipherStash — holds a complete data key. | +| **CipherStash Encryption SDK** (`@cipherstash/stack`) | The TypeScript library that encrypts/decrypts application data and runs searchable queries, backed by ZeroKMS. | +| **CipherStash Proxy** | A drop-in SQL proxy that applies the same primitives server-side with no application code changes. | -```typescript -import { KMSClient, EncryptCommand } from '@aws-sdk/client-kms'; - -const client = new KMSClient({ region: 'us-west-2' }); -const keyId = 'arn:aws:kms:us-west-2:123456789012:key/abcd1234-efgh-5678-ijkl-9012mnopqrst'; - -async function encryptWithKMS(plaintext: string): Promise { - try { - const command = new EncryptCommand({ - KeyId: keyId, - Plaintext: Buffer.from(plaintext), - }); - - const response = await client.send(command); - const ciphertext = response.CiphertextBlob; - const base64Ciphertext = Buffer.from(ciphertext).toString('base64'); - - return base64Ciphertext; - } catch (error) { - console.error('Error encrypting data:', error); - throw error; - } -} - -const encrypted = await encryptWithKMS('secret@squirrel.example'); -``` +The SDK and Proxy are two deployment shapes of the same primitives; the examples below use the SDK. -**What you're managing:** Key ARNs, binary buffer conversions, base64 encoding/decoding, manual error handling, region configuration, AWS credential setup. +## Architecture & trust model -### CipherStash Encryption: One simple call - -```typescript -import { Encryption } from '@cipherstash/stack'; -import { encryptedTable, encryptedColumn } from '@cipherstash/stack/schema'; +AWS KMS provides managed key management with high availability and deep AWS integration, but key custody and the underlying hardware remain with AWS. Two properties matter for a security evaluation: -const users = encryptedTable('users', { - email: encryptedColumn('email'), -}); +- **Shared keys, larger blast radius.** A KMS key (or a derived data key) typically protects many records, so a single key compromise exposes everything it covers. +- **Provider custody.** AWS controls the HSMs and the IAM boundary around them, so your trust model includes AWS. -const client = await Encryption({ - schemas: [users], -}); +ZeroKMS takes a different approach: -const encryptResult = await client.encrypt( - 'secret@squirrel.example', - { column: users.email, table: users } -); +- **Unique key per record.** Every value gets its own key, so a compromised key exposes a single record rather than a dataset. +- **Distributed trust.** Keys are derived on demand by combining client- and server-side components and are never stored. No single party — including CipherStash — can decrypt data unilaterally (CipherStash calls this *zero-knowledge* key management). +- **Identity-bound access.** Decryption is gated by OIDC identity, with per-record access control, instant revocation, and a real-time audit log of every access. +- **Performance.** Sub-5ms overhead for most operations ([latency benchmarks](https://app.artillery.io/share/sh_75edb9d22a060633bfdce04777ffd60d1bcfc88989393dc38d3a4924b83fc6cd)), and up to 14× the throughput of AWS KMS at scale. +{/* TODO: cite a public throughput benchmark for the "14×" figure, as the FHE page does for its ORE numbers. Until sourced, this claim is unverifiable to an external reader. */} +- **Deployment.** Managed service across regions, or self-hosted as a container for jurisdictional control. -if (encryptResult.failure) { - throw new Error(encryptResult.failure.message); -} +The same architecture comparison applies to Google Cloud KMS and Azure Key Vault, which share the provider-custody, shared-key model. -const ciphertext = encryptResult.data; -``` +## Developer experience -**What you get:** No key management (handled by ZeroKMS), no binary conversions, no base64 encoding, type-safe error handling, JSON payload ready for storage, zero-knowledge encryption by default. +Beyond the trust model, the SDK removes the boilerplate AWS KMS requires. Examples are TypeScript. -## Decryption +### Encrypting and decrypting a value -### AWS KMS +AWS KMS returns binary ciphertext you must encode, store, and decode yourself: ```typescript -async function decryptWithKMS(base64Ciphertext: string): Promise { - try { - const ciphertextBlob = Buffer.from(base64Ciphertext, 'base64'); - const command = new DecryptCommand({ CiphertextBlob: ciphertextBlob }); - const response = await client.send(command); - return Buffer.from(response.Plaintext).toString('utf-8'); - } catch (error) { - console.error('Error decrypting data:', error); - throw error; - } -} -``` - -### CipherStash Encryption - -```typescript -const decryptResult = await client.decrypt(ciphertext); - -if (decryptResult.failure) { - throw new Error(decryptResult.failure.message); -} - -const plaintext = decryptResult.data; -``` +import { KMSClient, EncryptCommand, DecryptCommand } from "@aws-sdk/client-kms"; -## Features that AWS KMS can't do without major custom work +const client = new KMSClient({ region: "us-west-2" }); +const keyId = "arn:aws:kms:us-west-2:123456789012:key/abcd1234-..."; -### 1. Searchable encryption: Built-in vs impossible - -**AWS KMS** requires decrypting everything and searching in memory, storing plaintext indexes, or building a custom searchable encryption solution. - -**CipherStash Encryption** has searchable encryption built-in: - -```typescript -const users = encryptedTable('users', { - email: encryptedColumn('email') - .freeTextSearch() - .equality() - .orderAndRange(), -}); +const enc = await client.send( + new EncryptCommand({ KeyId: keyId, Plaintext: Buffer.from("secret@squirrel.example") }), +); +const ciphertext = Buffer.from(enc.CiphertextBlob).toString("base64"); // you store this -const searchTerms = await client.encryptQuery('secret', { - column: users.email, - table: users, -}); +const dec = await client.send( + new DecryptCommand({ CiphertextBlob: Buffer.from(ciphertext, "base64") }), +); +const plaintext = Buffer.from(dec.Plaintext).toString("utf-8"); ``` -### 2. Identity-aware encryption: Built-in vs custom implementation +You manage: key ARNs, buffer/base64 conversions, error handling, AWS credentials, and regions. -**AWS KMS** has no built-in support. You must implement custom logic with encryption context as a workaround. - -**CipherStash Encryption** has built-in identity-aware encryption: +The CipherStash SDK returns a JSON payload ready for `JSONB` storage, with key management handled by ZeroKMS and a type-safe `Result` rather than thrown errors: ```typescript -import { LockContext } from '@cipherstash/stack/identity'; +import { Encryption } from "@cipherstash/stack"; +import { encryptedTable, encryptedColumn } from "@cipherstash/stack/schema"; -const lc = new LockContext(); -const lockContext = await lc.identify(userJwt); +const users = encryptedTable("users", { email: encryptedColumn("email") }); +const client = await Encryption({ schemas: [users] }); -const encryptResult = await client.encrypt( - 'secret@squirrel.example', - { column: users.email, table: users } -).withLockContext(lockContext); +const result = await client.encrypt("secret@squirrel.example", { column: users.email, table: users }); +if (result.failure) throw new Error(result.failure.message); -const decryptResult = await client.decrypt(ciphertext) - .withLockContext(lockContext); +const plaintext = (await client.decrypt(result.data)).data; // type: string ``` -### 3. Bulk operations: Native API vs manual batching +### Capabilities AWS KMS doesn't provide without custom work -**AWS KMS** has no bulk API. You must manually batch operations and handle rate limits. - -**CipherStash Encryption** has native bulk encryption: +**Searchable encryption** — query encrypted data directly in PostgreSQL. AWS KMS requires decrypting in memory or building a custom searchable index. ```typescript -const bulkPlaintexts = [ - { id: '1', plaintext: 'Alice' }, - { id: '2', plaintext: 'Bob' }, - { id: '3', plaintext: 'Charlie' }, -]; - -const bulkResult = await client.bulkEncrypt(bulkPlaintexts, { - column: users.name, - table: users, +const users = encryptedTable("users", { + email: encryptedColumn("email").freeTextSearch().equality().orderAndRange(), }); -const encryptedMap = bulkResult.data; +const terms = await client.encryptQuery("secret", { column: users.email, table: users }); ``` -## Feature comparison - -| Feature | AWS KMS | CipherStash Encryption | -|---------|---------|------------------------| -| **Basic Encryption** | Requires manual buffer/base64 handling | One-line API, JSON payload | -| **Key Management** | You manage key ARNs | Zero-knowledge, automatic | -| **Searchable Encryption** | Not possible | Built-in for PostgreSQL | -| **Identity-Aware Encryption** | Custom implementation | Built-in `LockContext` | -| **Bulk Operations** | Manual batching | Native bulk API | -| **Error Handling** | Try/catch, manual types | Type-safe Result pattern | -| **Type Safety** | Manual typing | Full TypeScript inference | -| **Storage Format** | Binary (needs encoding) | JSON (database-ready) | -| **ORM Integration** | Manual integration | Built-in Drizzle support | -| **Zero-Knowledge** | AWS has key access | True zero-knowledge | -| **Setup Complexity** | Medium (AWS credentials, regions) | Low (just environment variables) | - -## Developer experience comparison - -### Error handling - -**AWS KMS:** Try/catch with manual error type checking: - -```typescript -try { - const response = await client.send(command) -} catch (error) { - if (error.name === "AccessDeniedException") { - // Handle access denied - } else if (error.name === "InvalidKeyUsageException") { - // Handle invalid key usage - } -} -``` - -**CipherStash Encryption:** Type-safe Result pattern: +**Identity-aware encryption** — bind encryption to an OIDC identity via `LockContext`. AWS KMS has no built-in equivalent; encryption context is a manual workaround. ```typescript -const result = await client.encrypt(plaintext, options) - -if (result.failure) { - switch (result.failure.type) { - case "EncryptionError": - // TypeScript knows this is an EncryptionError - break - case "ClientInitError": - // TypeScript knows this is a ClientInitError - break - } -} -``` +import { LockContext } from "@cipherstash/stack/identity"; -### Type safety +const lockContext = await new LockContext().identify(userJwt); -**AWS KMS:** Manual typing with binary data handling: - -```typescript -const plaintext: string = Buffer.from(response.Plaintext).toString("utf-8") +await client + .encrypt("secret@squirrel.example", { column: users.email, table: users }) + .withLockContext(lockContext); ``` -**CipherStash Encryption:** Full TypeScript inference: +**Bulk operations** — native batch API. AWS KMS has no bulk endpoint; you batch and handle rate limits manually. ```typescript -const plaintext = decryptResult.data // Type: string -``` - -### Storage format - -**AWS KMS:** Binary data that needs encoding: - -```typescript -// Returns Uint8Array, must encode for storage -const base64 = Buffer.from(ciphertext).toString("base64") +const result = await client.bulkEncrypt( + [{ id: "1", plaintext: "Alice" }, { id: "2", plaintext: "Bob" }], + { column: users.name, table: users }, +); ``` -**CipherStash Encryption:** JSON payload ready for database: +## Comparison -```typescript -// Returns JSON payload ready for JSONB storage -const ciphertext = encryptResult.data -``` +### Architecture -## Complete workflow comparison +| Property | AWS KMS | CipherStash (ZeroKMS) | +|---------|---------|------------------------| +| Key storage | Centralized in provider HSMs | Distributed, derived on demand, never stored | +| Control model | Provider-managed custody | Distributed trust, no single point of decryption | +| Key granularity | Shared keys | Per-record keys | +| Breach impact | All records under the key | Single record | +| Access control | IAM-based | Identity-based (OIDC), per-record | +| Audit | CloudTrail (API calls) | Real-time log of every decryption | +| Performance | Network-dependent, rate-limited | Sub-5ms overhead; up to 14× throughput | +| Deployment | AWS regions | Managed service or self-hosted container | -### AWS KMS: Full implementation +### Developer experience -```typescript -import { KMSClient, EncryptCommand, DecryptCommand } from "@aws-sdk/client-kms" - -const client = new KMSClient({ region: "us-west-2" }) -const keyId = "arn:aws:kms:us-west-2:123456789012:key/abcd1234-efgh-5678-ijkl-9012mnopqrst" - -async function encrypt(plaintext: string): Promise { - const command = new EncryptCommand({ - KeyId: keyId, - Plaintext: Buffer.from(plaintext), - }) - const response = await client.send(command) - return Buffer.from(response.CiphertextBlob).toString("base64") -} - -async function decrypt(base64Ciphertext: string): Promise { - const command = new DecryptCommand({ - CiphertextBlob: Buffer.from(base64Ciphertext, "base64"), - }) - const response = await client.send(command) - return Buffer.from(response.Plaintext).toString("utf-8") -} - -const encrypted = await encrypt("secret@squirrel.example") -const decrypted = await decrypt(encrypted) -``` +| Feature | AWS KMS | CipherStash Encryption | +|---------|---------|------------------------| +| Basic encryption | Manual buffer/base64 handling | One call, JSON payload | +| Key management | You manage key ARNs | Automatic, via ZeroKMS | +| Searchable encryption | Not supported | Built-in for PostgreSQL | +| Identity-aware encryption | Manual workaround | Built-in `LockContext` | +| Bulk operations | Manual batching | Native bulk API | +| Error handling | Try/catch, manual types | Type-safe `Result` | +| Storage format | Binary (needs encoding) | JSON (`JSONB`-ready) | +| ORM integration | Manual | Built-in Drizzle support | -~25 lines for basic encrypt/decrypt. You manage: key ARNs, binary conversions, base64 encoding, error handling, AWS credentials, regions. +## When to use each -### CipherStash Encryption: Full implementation +**AWS KMS fits when:** -```typescript -import { Encryption } from "@cipherstash/stack" -import { encryptedTable, encryptedColumn } from "@cipherstash/stack/schema" +- You're encrypting AWS infrastructure resources (S3, EBS, RDS storage) rather than application records +- You need envelope encryption at rest with simple key management and no querying over ciphertext +- A shared-key model and AWS key custody are acceptable for your threat model -const users = encryptedTable("users", { - email: encryptedColumn("email"), -}) +**CipherStash fits when:** -const client = await Encryption({ schemas: [users] }) +- You're encrypting application data in PostgreSQL and need to query it while it stays encrypted +- You want per-record keys, distributed trust, and instant, identity-based (OIDC) revocation +- You need real-time audit trails for compliance (SOC 2, HIPAA, GDPR) +- You're on multi-cloud or hybrid infrastructure and want to avoid provider key custody -const encryptResult = await client.encrypt("secret@squirrel.example", { - column: users.email, - table: users, -}) +**Limits to know:** searchable encryption targets PostgreSQL; identity-aware encryption requires an OIDC provider; and CipherStash encrypts at the application layer, so it complements — rather than replaces — disk- or infrastructure-level encryption (where AWS KMS fits). -if (encryptResult.failure) { - throw new Error(encryptResult.failure.message) -} +## Migration path -const decryptResult = await client.decrypt(encryptResult.data) -``` +Migration from AWS KMS (or any cloud KMS) can be incremental: -~20 lines including setup. `@cipherstash/stack` handles everything. +1. **Assess** — identify high-value data that benefits from per-record encryption and searchable queries +2. **Pilot** — start with a new application or a non-critical workload +3. **Integrate** — connect your existing OIDC identity provider +4. **Migrate** — move sensitive workloads to ZeroKMS in stages +5. **Coexist** — keep AWS KMS for infrastructure-level encryption -## When to use each +## Learn more -### Use AWS KMS when: -- You need encryption for AWS services (S3, EBS, etc.) -- You're encrypting infrastructure-level resources -- You don't need to search encrypted data -- You're comfortable with manual buffer/base64 handling - -### Use CipherStash Encryption when: -- You're building applications with databases -- You need to search encrypted data -- You want a developer-friendly API -- You need identity-aware encryption -- You want zero-knowledge key management -- You value type safety and developer experience - -## References - -- [AWS KMS Documentation](https://docs.aws.amazon.com/kms/) -- [CipherStash Encryption Getting Started](/stack/quickstart) -- [CipherStash Schema Reference](/stack/cipherstash/encryption/schema) -- [Searchable Encryption Concepts](/stack/cipherstash/encryption/searchable-encryption) +- [CipherStash Encryption getting started](/stack/quickstart) +- [ZeroKMS](/stack/cipherstash/kms) +- [Schema reference](/stack/cipherstash/encryption/schema) +- [Searchable encryption concepts](/stack/cipherstash/encryption/searchable-encryption) +- [Security architecture](/stack/reference/security-architecture) — leakage profiles and primitives +- [ZeroKMS vs Hardware Security Modules](/stack/reference/comparisons/zerokms-vs-hsm) +- [AWS KMS documentation](https://docs.aws.amazon.com/kms/) diff --git a/content/stack/reference/comparisons/index.mdx b/content/stack/reference/comparisons/index.mdx index 8af067f..c72ee04 100644 --- a/content/stack/reference/comparisons/index.mdx +++ b/content/stack/reference/comparisons/index.mdx @@ -8,7 +8,8 @@ Side-by-side breakdowns of CipherStash against the approaches teams most commonl - + + ## Related diff --git a/content/stack/reference/comparisons/meta.json b/content/stack/reference/comparisons/meta.json index f899b8d..ad0883a 100644 --- a/content/stack/reference/comparisons/meta.json +++ b/content/stack/reference/comparisons/meta.json @@ -1,5 +1,5 @@ { "title": "Comparisons", "description": "How CipherStash compares to alternative approaches", - "pages": ["index", "fhe", "aws-kms"] + "pages": ["index", "fhe", "aws-kms", "zerokms-vs-hsm"] } diff --git a/content/stack/reference/comparisons/zerokms-vs-hsm.mdx b/content/stack/reference/comparisons/zerokms-vs-hsm.mdx new file mode 100644 index 0000000..3ef332e --- /dev/null +++ b/content/stack/reference/comparisons/zerokms-vs-hsm.mdx @@ -0,0 +1,225 @@ +--- +title: ZeroKMS vs Hardware Security Modules (HSM) +description: Compare CipherStash ZeroKMS's zero-trust key management with traditional hardware security modules +--- + +Hardware Security Modules (HSMs) provide cryptographic key management through tamper-evident hardware. They're often chosen when organizations need complete control over key custody, regulatory compliance with specific hardware standards, and jurisdictional certainty. + +Cloud based Key Management Services like ZeroKMS and AWS KMS use HSM internally. However, managing your own HSM can be a complex and costly undertaking. Careful consideration must be given to physical access management, key governance and disaster recovery plans. + + +**ZeroKMS simplifies or eliminates self-managed HSM:** + +* as a viable alternative to HSM for many use-cases +* by reducing operational complexity and improving performance when customer managed HSM is mandated + + +## Benefits of HSM + +TODO + +## HSM Challenges + +Virtually all key management solutions will use an HSM as part of a key heirarchy. + + +The question isn't whether an HSM is required but rather if self-managed HSM is necessary to meet compliance and security goals. + + +Below are some of the challenges associated with self-managed HSM that should be considered before deciding on a key management strategy. + +### Physical access + +HSMs require secure physical installation — often in locked racks or safes within a data center with strict access controls, surveillance, and environmental protections. + +![A generated image of an HSM in a server-rack](/images/hsm.png) + +Standards like FIPS and PCI require dual control and split-knowledge policies, meaning no single person can access keys alone. This can complicate physical security which not only introduces risk but adds significant cost. + + +ZeroKMS replaces physical custody with cryptographic custody — the root key still lives in hardware, but access, rotation, and audit are handled programmatically and verifiably, eliminating the physical-access bottlenecks that plague traditional HSM operations. + +TODO: this could be worded better +The ZeroKMS distributed trust model means that even HSM controlled root keys are unable to perform cryptographic operations on their own. + + +Learn more (link): +TODO: Cryptographic custody and distributed trust (maybe this is an article called Trust Model) + +### Integration effort + +Integrating software applications with an HSM requires the use of low-level interfaces like PKCS#11, JCE or CNG. Additionally, integration with network-based HSMs such as AWS CloudHSM or Thales Luna require secure channel setup, VPNs, or private VPC endpoints. + +Using PKCS#11, JCE, or CNG directly is notoriously difficult for developers — even seasoned security engineers — because these APIs were designed primarily for hardware abstraction and compliance, not for developer ergonomics. + + +ZeroKMS integrates via Protect SDK or CipherStash Proxy which eliminate the complexity of PKCS#11-, JCE-, and CNG-style APIs. + +These provide simple, developer-friendly interfaces that integrate directly into application code and databases without requiring HSM drivers, provider configuration, or handle management. + + +### Operational complexity + +Traditional HSMs are difficult to scale because every device manages its own key state — meaning key generation, rotation, and backup must be coordinated manually across identical hardware. Achieving high availability or disaster recovery requires securely replicating keys between HSMs, which is slow, error-prone, and often breaks FIPS compliance if not done through vendor-specific procedures. + +When an HSM loses power, it wipes all active secrets and reboots into a locked, verified state. +Recovery requires re-authenticating operators and reloading encrypted key partitions — a safe but slow process that depends on physical credentials, making automated or cloud-scale recovery difficult. + +TODO: key ceremonies, replication, uptime (eg. power), reliability etc + +### Compliance + +TODO: Talk about PCI/DSS etc + +### Expertise + +Managing an HSM demands cryptographic fluency, vendor-specific training, and precise procedural control — a combination that is hard to hire for. Failing to recruit sufficiently qualified personel can leave organizations vulnerable. + + +ZeroKMS was designed to be simple to use without the need for specialized skills or expertise. Each system component is built on a high-assurance framework, is misuse resistant and forgiving even for engineers with limited cryptographic knowledge. + + +### Cost model + +HSMs deliver strong assurance but come with high upfront and ongoing costs. Hardware units typically cost tens to hundreds of thousands of dollars each, plus annual support, licensing, and maintenance contracts. Scaling requires buying more physical devices, not just compute, and disaster recovery often means duplicating hardware across regions. Operating them also demands specialist staff, secure facilities, and compliance audits — making total cost of ownership (TCO) high and predictable only at small scale. + + +ZeroKMS can be purchased via a monthly or annual subscription. There are no upfront or hidden costs. + + +## Hybrid solutions + +{/* TODO: add a diagram here. The original Markdoc source used a D2 diagram (this repo has no D2 renderer yet). Original source: +direction: down + +Client: { + label: 'Client Application' + App: { + label: 'App Logic' + } + SDK: { + label: 'Crypto SDK / PKCS#11' + } + App -> SDK: 'Crypto requests' +} + +HSM: { + label: 'HSM' + Key: {label: 'Secret Key'} +} + +Client.SDK -> HSM: 'Generate Data Key' +*/} + +## Why Organizations Choose HSMs + +### Full Control and Ownership + +HSMs offer complete end-to-end ownership over cryptographic keys, including their generation, rotation, archival, and destruction. No external party has access to keys under any circumstances. + +### Physical Security and Isolation + +Keys are protected by tamper-evident hardware in a physically isolated environment. Sensitive material never leaves the secure boundary of the device. + +### Compliance with Regulations + +Many organizations require FIPS 140-2 Level 3 or Level 4, PCI DSS, or region-specific data residency laws. HSMs provide auditable hardware-based security with proof of key custody. + +### Assured Key Destruction + +Organizations can trigger and verify cryptographic erase or physically destroy HSM modules locally, meeting policy requirements for witnessed destruction and compliance audits. + +### Jurisdictional Certainty + +On-premises HSMs ensure all key management and backups remain under the organization's legal jurisdiction, preventing cross-border replication and reducing sovereignty risks. + +### Performance and Latency + +Local HSMs provide predictable, ultra-low-latency cryptographic operations for real-time applications and highly sensitive transactional workloads. + +### Customization and Legacy Integration + +HSMs integrate with legacy infrastructure, support custom backup and cluster topologies, and enable cryptographic ceremonies without being restricted by provider APIs or cloud-specific tooling. + +## How ZeroKMS Addresses HSM Requirements + +### Per-Record and Zero-Knowledge Key Management + +ZeroKMS derives a unique key per record on demand; keys are never stored, and no single party — including CipherStash — can decrypt data unilaterally (CipherStash calls this *zero-knowledge* key management). A compromised key exposes a single record rather than a dataset, addressing the shared-key blast radius of centralized KMS while keeping key custody distributed rather than tied to physical hardware. + +### No Shared Secrets and No Single Point of Decryption + +Keys are derived on-demand by combining client- and server-side components. No centralized key store exists, and no party (client, server, or CipherStash) holds all components needed to decrypt data unilaterally. + +### Instant Key Revocation and Fine-Grained Access + +Organizations maintain fine-grained, identity-based access control via OIDC integration. Only authorized identities can decrypt specific records. Instant revocation and real-time audit logs provide continuous, provable compliance that often exceeds traditional HSM audit capabilities. + +### Performance Without Bottlenecks + +ZeroKMS adds [sub-5ms overhead](https://app.artillery.io/share/sh_75edb9d22a060633bfdce04777ffd60d1bcfc88989393dc38d3a4924b83fc6cd) for most operations, removing the latency and throughput bottlenecks associated with hardware HSMs. + +### Continuous Audit and Compliance + +Instead of point-in-time compliance checks, ZeroKMS logs every access in real time with cryptographically verifiable audit trails. This exceeds standard attestation methods used with HSMs. + +### Flexible Deployment and Jurisdiction Control + +ZeroKMS runs as a managed cloud service across multiple regions. It's also available as a Docker container for deployment under your own jurisdiction when needed. + +## Comparison Table + +| Feature | HSMs | ZeroKMS | +|---------|------|----------| +| Key Storage | Centralized in hardware | Distributed, generated locally | +| Deployment | Physical/Virtual appliance | Managed service or container | +| Control Model | Full hardware custody | Zero-knowledge, client-side | +| Compliance | FIPS 140-2 L3/L4 | Continuous audit, cryptographic proofs | +| Performance | Hardware-limited | Sub-5ms overhead at scale | +| Scaling | Hardware-dependent | Software-defined, unlimited | +| Cost Model | CapEx + maintenance | Usage-based | +| Jurisdictional Control | Full on-prem control | Flexible deployment | +| Key Granularity | Shared keys | Per-record keys | + +## Benefits for Regulated Environments + +ZeroKMS enables organizations to maintain HSM-like control, auditability, and compliance while delivering lower operational overhead and greater scalability for modern applications: + +- Prove continuous control for compliance-sensitive workloads in financial services, healthcare, and regulated markets +- Support real-time use cases without sacrificing speed or security +- Eliminate vendor lock-in by never holding centralized secrets or requiring shared credentials +- Reduce breach impact through per-record encryption and instant access revocation + +## Use Cases + +### When HSMs Make Sense + +- Regulatory requirements explicitly mandate FIPS 140-2 Level 3+ hardware certification +- Legacy systems require direct HSM integration +- On-premises-only deployments with no cloud connectivity +- Root key protection for certificate authorities + +### When ZeroKMS Makes Sense + +- Cloud-native or hybrid architectures +- High-throughput encryption requirements with modern applications +- Fine-grained, per-record encryption and access control +- Zero-trust security requirements without delegating trust to providers +- Global, multi-region deployments +- Rapid development and deployment cycles +- Continuous compliance and real-time auditability + +## Complementary Deployment + +Organizations can use HSMs and ZeroKMS in complementary roles: + +- **HSMs**: Protect root keys and certificate authorities +- **ZeroKMS**: Handle application-layer data encryption and key management + +This layered approach provides defense in depth while maintaining performance and flexibility for application development. + +## Learn More + +- [Read about ZeroKMS](/stack/cipherstash/kms) +- [View all comparisons](/stack/reference/comparisons) +- [Book a discovery session](/stack/reference/discovery-session) 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