Bunker reference architectures/SaaS

Wallet backup ingestion pipeline

Fireblocks, Fordefi, and Utila push encrypted workspace backups to dedicated integrations endpoints. Bunker verifies, enrolls, and splits the backup key across 3 security domains.

Integrations APIKMS signed JWTNitro EnclaveAES GCM 256Shamir 3 of 3Multi region S3
Fireblocks
Fordefi
Utila
Bearer token · IP allow list
Provider push
Bunker3 domain key split
KMS signed key JWTVERIFIED
Nitro Enclave TEEATTESTED
3 way key splitSHAMIR
Ciphertext managerDURABLE
Customer shareHSM shareCloud share · KMSEncrypted backupThree security domains
Distinct prod and testnet endpointsSHA 256 fingerprintsMulti zone · multi region

Dataflow

01

The wallet provider calls its dedicated /keys endpoint from an allow listed IP with a bearer token. Bunker returns a public encryption key as a KMS signed JWT the provider verifies before use.

02

The provider encrypts the workspace backup and posts it to the secure backup endpoint with customer and workspace metadata and the key id.

03

An ephemeral EC2 instance launches the signed TEE as a Nitro Enclave when the enrollment job is queued. The TEE has no durable storage and no general purpose network access.

04

The TEE generates a backup encryption key (AES GCM 256) from the enclave security module and splits it 3 of 3 with Shamir secret sharing: customer, HSM, and cloud shares.

05

The customer share is super encrypted to every registered customer device key. The HSM share is encrypted to a single tenant CloudHSM in a distinct AWS account. The cloud share is encrypted under KMS.

06

All ciphertexts land in the ciphertext management system with SHA 256 fingerprints stored in a separate system. Testnet backups flow through distinct endpoints so test and production assets never mix.

Components

Integrations API

Distinct per provider endpoints with bearer tokens and IP allow lists. Separate credentials for production and testnet.

Nitro Enclave TEE

Generates and splits the backup encryption key. Launched ephemerally per enrollment job; destroyed on completion.

Ciphertext management service

Multi zone, multi region storage of every ciphertext, with SHA 256 fingerprints held in a separate storage system.

Single tenant CloudHSM

Holds the HSM share encryption key in a distinct AWS account from the TEE and the policy engine.

Customer FIDO2 devices

YubiKeys registered per member. The customer share is encrypted to every device on the recovery policy.

Security considerations

Station70 never holds sufficient key material. All 3 domains (customer, HSM, cloud) must participate to recover a backup.

The provider verifies the KMS signed JWT before trusting any encryption key, closing the key substitution channel.

Quarterly scans verify every ciphertext against its fingerprint and alert engineering on any mismatch before a recovery is ever needed.

Each security domain uses separate keys under unique administration. A lost or compromised device is nullified through ciphertext erasure.

Deploy this architecture

Walk through the trust model, policy design, and rollout with our security and solutions team.

Learn moreAll architectures