Key Management and Sensitive Material Flow
Understand how SecuriTLS separates platform secrets, per-customer storage encryption, and Satellite-local custody for signing and deployment workflows.
What this page explains
SecuriTLS separates platform credential encryption, customer storage encryption, and Satellite-local key custody. That separation matters because each layer protects a different category of sensitive material and has a different blast radius.
Local Master Key scope: platform-wide wrapping of the Platform DEK.
Storage Master Key scope: per-customer wrapping of the Customer Storage DEK.
Satellite symmetric keys encrypt private key material locally.
The Platform DEK protects operational secrets stored in the database. The Customer Storage DEK protects encrypted key material in the selected storage provider. Satellites maintain their own local encryption and RSA exchange model for deployment and signing workflows.
Master keys and DEKs
SecuriTLS uses master keys to unwrap data encryption keys, or DEKs. The DEKs are what actually encrypt sensitive payloads. This keeps long-lived wrapping keys separate from the keys used for data encryption.
Local Master Key
Scope: platform-wide.
Purpose: unwraps the Platform DEK stored in the database.
Protects: device credentials and storage provider secrets after they are encrypted by the Platform DEK.
Storage Master Key
Scope: per customer or workspace.
Purpose: unwraps the Customer Storage DEK stored with the configured storage provider.
Protects: key material encrypted at rest in Sia, AWS, or a configured self-managed storage provider.
Database-stored sensitive material
The database stores the wrapped Platform DEK and encrypted operational secrets. SecuriTLS unwraps the Platform DEK only when a workflow needs to use the protected material.
| Category | Examples | Protection model |
|---|---|---|
| Device credentials | User passwords, RSA private keys used to connect to devices | Encrypted by the Platform DEK, which is wrapped by the Local Master Key. |
| Storage secrets | AWS Secret Access Key, AWS Session Token, AWS External ID, Sia password | Encrypted by the Platform DEK so storage access secrets are not stored in plaintext. |
| Wrapped Platform DEK | The wrapped data encryption key for database secrets | Unwrapped by the Local Master Key when required by platform workflows. |
Storage provider encryption
Storage providers hold encrypted certificate private key material and related encrypted payloads. The Customer Storage DEK performs encryption at rest for that storage layer. The Storage Master Key unwraps the Customer Storage DEK.
Important distinction: the storage encryption layer is per customer. It is separate from the platform-wide database secret layer. That means storage provider key material can have customer-specific wrapping and rotation behavior.
Satellite-local key custody
Satellites add a third boundary. A Satellite runs inside the customer environment and can generate local symmetric keys for private key material. Satellite-local private key encryption uses AES-256-GCM.
Each Satellite also has an RSA key pair for secure exchange. When SecuriTLS needs a Satellite to perform a deployment, it decrypts the required device credential, then re-encrypts it to the target Satellite RSA public key before sending the job.
1. Platform prepares job
SecuriTLS determines the device, certificate attachment, credential, and target Satellite.
2. Credential is re-encrypted
The platform decrypts the required credential and re-encrypts it using the target Satellite RSA public key.
3. Satellite executes locally
The Satellite decrypts the job material locally and performs signing, validation, or deployment from inside the customer network.
Cross-Satellite sensitive material exchange
Some workflows involve more than one Satellite. For example, one Satellite may control a leaf certificate key while another controls a signing CA key. SecuriTLS can coordinate the exchange without requiring every Satellite to expose plaintext material to every other component.
Typical examples include CSR signing workflows, certificate deployment workflows, and environments where signing and deployment are intentionally separated.
Security boundaries
| Boundary | Who controls it | What it protects | Best for |
|---|---|---|---|
| Platform database encryption | SecuriTLS platform | Device credentials and storage provider secrets | Operational automation and secure credential storage. |
| Customer storage encryption | Per-customer SecuriTLS storage key, or BYOK where configured | Private key material encrypted at rest in storage providers | Customer-specific storage isolation and storage provider migration. |
| Satellite custody | Customer environment | Private key generation, local encrypted key material, deployment secrets, and signing operations | Private networks, self-custody, and workflows where private keys should remain local. |