Skip to main content
Studio uses envelope encryption to add a cryptographic boundary around supported sensitive fields. A copied ciphertext is not useful without the matching data key, KMS authorization, and authenticated context. This protection does not cover every record field, local recording, exported file, or plaintext value at its point of use, so it complements rather than replaces application and endpoint controls. This page describes the design end to end: the keys, the algorithm, the envelope format, the rotation behavior, the cross-organization sharing flow, the keychain caching, and the organization-deletion path that ends in cryptographic shredding.

​
The shape

Three layers of indirection — CMK wraps DEK wraps record — sound complex. They give us four properties we want:
  • The CMK never leaves the HSM.
  • The DEK can be rotated frequently without rewriting every ciphertext immediately (envelopes carry a dekRef and the corresponding wrap is fetched at decrypt time).
  • A single record can be re-wrapped for additional organizations (sharing) without re-encrypting.
  • Organization key destruction can make remaining encrypted envelopes unrecoverable after the KMS deletion window. It does not erase unencrypted metadata, exports, or endpoint copies.

​
The algorithm

Envelope payloads are versioned so the format can evolve without breaking historical decrypts; every envelope carries a version tag and a reference to the DEK that wrapped it.

​
Additional authenticated data

Every envelope’s AAD binds it to its location. An adversary who copies a ciphertext from one record to another (transplantation attack) cannot decrypt it: the AAD they would have to forge includes the destination record’s identity, and the GCM tag fails verification. This means:
  • A field copied from one record to another in the same table fails to decrypt.
  • A field copied from one organization to another fails to decrypt.
  • A field copied between two semantically different fields on the same record fails to decrypt.
The exact AAD construction is a hardening detail we don’t publish, but the property it enforces is the one above.

​
DEK lifecycle

A new organization receives a freshly minted DEK:
1

Create the org's CMK

On organization creation, a backend handler creates a dedicated KMS customer master key, applies the org-scoped key policy, and records the binding so subsequent calls route to the right key.
2

Mint the first DEK

The same handler asks KMS to generate a fresh data key under the new CMK. The plaintext form is used once and discarded; the wrapped form is persisted as the org’s active DEK.
3

Use the active DEK for new envelopes

Encryption calls fetch the active DEK, unwrap it via KMS into protected memory, perform the AES-256-GCM operation with the appropriate AAD, and embed a reference to the DEK in the envelope so it can be located again at decrypt time.
4

Rotate on a recurring schedule

A scheduled rotation mints a new DEK version and marks the previous one retired. New envelopes use the new DEK; old envelopes still decrypt because retired DEKs are kept (encrypted) for the lifetime of the organization.
5

Admin-triggered rotation

An organization admin can also trigger rotation manually — for example, after a personnel change. The same handler runs; the same retirement semantics apply.
Rotation is idempotent and concurrent-safe: the active-version pointer is updated with a conditional write so two simultaneous rotations cannot produce two different “active” versions. Retired DEKs are never deleted while the organization exists. Old envelopes must keep decrypting. The cost of keeping them is negligible, and the benefit is that historical data does not become inaccessible after a routine rotation.

​
Plaintext DEK caching

Decrypting a record requires the plaintext DEK. Calling KMS for every decrypt is too slow for a workspace that opens hundreds of records per session, so plaintext DEKs are cached in the operating system keychain on the desktop with a short lifetime. Electron safeStorage uses the platform credential service to protect cached values at rest. This is an OS-account boundary, not a defense against a privileged process on an unlocked workstation. The bounded TTL is a deliberate safety margin: a stolen workstation that is signed in for a day still has limited useful key material once the cache expires, and an explicit sign-out purges every cached vault entry immediately.

​
Cross-organization shares

When a user shares a resource with a member of another organization, the resource’s encrypted contents must become readable to the other org without exposing the originating org’s DEK. Studio uses a per-resource DEK wrap for this:
1

Originating org unwraps the record

The originating user’s session unwraps the record’s envelope using the active org DEK and re-encrypts it under a fresh per-record DEK.
2

Per-record DEK is wrapped for each participating org

The per-record DEK is wrapped once under each participating organization’s CMK via KMS. Each wrap is persisted as its own row, scoped by (resource, organization).
3

Recipient org reads the share

A recipient’s session looks up the wrap for its own org, calls KMS with its own CMK to unwrap the per-record DEK, then decrypts the record. At no point does the recipient’s session see the originating org’s DEK or CMK.
4

Revoking a share removes the wrap

Removing a share deletes the recipient org’s wrap. The recipient’s session can no longer unwrap the per-record DEK; the underlying record is unchanged for the originating org.
This pattern lets Studio revoke future unwrap access without replacing the originating organization’s envelope. Revocation cannot erase plaintext, exports, screenshots, or keys a recipient legitimately obtained and retained outside the supported cache while the share was active.

​
Encrypted fields

The following fields are encrypted under the org DEK at rest: Hostnames, display names, organization membership, ownership, and folder structure are intentionally not encrypted. They have to be queryable for the workspace to be usable, and they are not the secrets — they are operational metadata. This boundary is documented honestly under known limits.

​
KMS access policy

Each organization’s CMK has a key policy that only permits decryption when the caller is bound to that organization. The binding is established at sign-in: the user’s identity claim is propagated as an AWS principal tag on every signed call, and KMS will only unwrap a DEK when the tag and the key’s policy align with the encryption context the application supplies. A user signed into organization A should not be able to unwrap organization B’s data key because the identity tag, key policy, and encryption context do not match. This protects encrypted fields; it does not replace resolver checks on unencrypted metadata.

​
Organization deletion and cryptographic shredding

When an organization is deleted, an organization-lifecycle handler:
1

Schedule the CMK for deletion

KMS marks the org’s CMK pending deletion with the AWS-mandated 30-day window. Shorter windows aren’t permitted.
2

Stop minting new envelopes

The org-key state is updated so the application no longer encrypts new records against the soon-to-be-destroyed CMK.
3

Wait the AWS-mandated window

During the 30 days, an admin can cancel the deletion if it was a mistake.
4

CMK is destroyed

After the window, AWS destroys the CMK irreversibly. Every wrapped DEK for the organization is now unrecoverable; every envelope encrypted with those DEKs is now ciphertext that can never be decrypted.
This is cryptographic shredding for the protected envelopes: ciphertext may remain in database rows, object storage, or backups but becomes unrecoverable after the key is destroyed. Unencrypted metadata and copies made outside the envelope path require separate deletion and retention controls.

​
How to verify any of this

Studio runs as a managed SaaS in Altostrat’s AWS account. The current vault, KMS, CloudTrail, and AppSync control plane is not deployed into your AWS account. The verification options reflect that:
  • FIPS endpoint and HSM: AWS’s published documentation establishes that the FIPS KMS endpoint in us-east-1 runs on FIPS 140-2 validated hardware. Our internal integration suite asserts on every release that we route to the FIPS endpoint; the assertion details are part of the security pack we share under NDA.
  • DEK rotation cadence and key isolation: producible from our CloudTrail on request as part of a security or compliance review.
  • Per-organization isolation: observable in any record export — each organization’s encrypted blobs reference a different KMS key, and sharing produces additional per-organization wraps.
  • Envelope versioning: observable in any record export — the version tag is unambiguous and lets us evolve the format without breaking historical records.
If you need formal evidence — for a SOC review, a PCI assessment, a customer security questionnaire — contact us. We share controls documentation and CloudTrail evidence under standard NDA.

Identity and access

How the principal tag that gates KMS access gets attached to your AWS calls.

Known limits

What the vault does not yet do — including audit logging of every decrypt and AI-context scrubbing.