Sovereign CaaS: Eliminating Custodial Counterparty Risk in Financial Institutions

1. Why Self-Host Cryptographic Services

When applications delegate key storage and signing to a third-party cloud provider, they take on risks that some institutions prefer to control directly:

• Jurisdiction: providers subject to foreign law (such as the US CLOUD Act) may be compelled to provide access to customer data.
• Vendor lock-in: each provider's KMS API differs, which complicates multi-cloud redundancy.
• Quotas and latency: cloud KMS endpoints apply request quotas and add a network round trip to every operation.

A self-hosted service keeps key material on infrastructure the institution controls while exposing a standard interface to microservices.

2. Service Topology & Isolation Boundaries

@sebastienrousseau/crypto-server is a Fastify REST service that exposes crypto-lib operations. What it provides today:

3. Performance

No throughput or latency figures are published for crypto-server yet. The table in earlier versions of this paper (104,200 ops/sec, 0.72 ms P99 signing, comparisons with cloud KMS and hardware HSMs) was not produced by committed benchmark code and has been withdrawn.

To measure primitive latency on your own hardware, run node benchmarks/crypto-bench.ts from the repository after pnpm -r run build. Load-test the REST service in your target environment before sizing a deployment.

4. Key Management Backends

@sebastienrousseau/crypto-kms defines one KmsProvider interface. There is no multi-cloud broker or automatic failover.

import { AwsKmsProvider } from "@sebastienrousseau/crypto-kms";
const kms = new AwsKmsProvider({ region: "eu-west-1" });
const key = await kms.createKey("aes-256-gcm", "encrypt");
const { plaintext, ciphertext } = await kms.generateDataKey(key.keyId);

AWS KMS and the local in-memory provider are implemented. The GCP, Azure and HashiCorp Vault providers reject every call with Not implemented.

5. Envelope Encryption (DEK/KEK)

Envelope encryption avoids encrypting large volumes of data directly under a long-lived key:

1. Data key generation: generateDataKey() returns a fresh 256-bit data encryption key (DEK) in plaintext and wrapped under the provider's key encryption key (KEK).
2. Data encryption: the application encrypts the record locally, for example with AES-256-GCM (96-bit nonce, 128-bit tag).
3. Storage: the application stores the wrapped DEK next to the ciphertext and unwraps it through the KMS when needed.
4. Memory: JavaScript cannot guarantee that a plaintext DEK is wiped from memory; drop references promptly and keep process lifetimes and core-dump policies in mind.

6. Relationship to EU DORA

The EU Digital Operational Resilience Act (Regulation 2022/2554) requires financial entities to maintain an ICT risk management framework, and its regulatory technical standards include requirements on encryption and cryptographic key management.

Crypto Service Suite can supply building blocks for that work, such as a cryptographic inventory (CBOM), algorithm choices and key management interfaces. Deploying it does not make an institution DORA compliant, and the suite has not been assessed by any regulator or auditor.

7. Production Deployment

If you deploy crypto-server, we suggest:

• Run several instances across independent availability zones behind an internal load balancer.
• Use the /live and /ready probe endpoints for health checks.
• Terminate TLS in front of the service, enable authentication, and supply secrets through Kubernetes Secrets or an equivalent secret store.