Non-custodial keys
A matrix of who holds which key, per deployment model, including what is designed rather than shipped and what this design does not provide.
Custody depends on which key you are asking about and on where the software that uses it runs. That makes this page a matrix rather than a single claim. Read the row that matches your deployment before you decide whether the custody story is good enough for what you are building.
The matrix
| Deployment model | Where the account root lives | What mintBlue holds | Status |
|---|---|---|---|
| The SDK and console against the mintBlue platform | Your master key is generated on your device at sign-up and wrapped with a key encryption key derived from your password | Wrapped blobs only. Your password, your key encryption key and your plaintext master key never reach mintBlue | Shipped. This is what the SDK and the console do today |
| An operator-provisioned runtime, on your own infrastructure or in your own cloud | Your organisation keeps the account root itself, in its own key store, whether that is a KMS, an HSM or the operating system keychain | Nothing | Designed, not shipped |
| A managed runtime, hosted by mintBlue | The account key is created on your side and stays there | A machine key derived one way from the account key. Climbing back from that machine key to the account key is not possible | Designed, not shipped |
Two of the three rows describe deployment models that are designed rather than available, and they are printed here anyway. A custody page that showed only the shipped row would answer the easy question and leave the one an architect actually asks, which is what happens to custody when the runtime moves.
What the shipped row does in detail
Your device generates a keypair, the master key, when you sign up. A key encryption key is derived from your password with PBKDF2, and the master key is encrypted with it using AES-GCM before anything is sent anywhere. Your password is hashed before it leaves the browser. The encrypted master key is stored server-side, which is what makes signing in from a second device possible.
Creating an access token repeats that pattern with a different secret: a new key encryption key is generated on your side, your master key is re-encrypted with it, and the re-encrypted copy is stored server-side.
That produces the two token types the console shows you once:
- The SDK token carries the secret that decrypts your master key for local use. It is the one the SDK needs, and it is as sensitive as the key material it unlocks. Anyone holding it can decrypt what that account can decrypt.
- The API token carries a hashed secret, authenticates API calls, and cannot decrypt your master key.
When the SDK encrypts an output it uses your master key, with ECDH-ES+A128GCM, and only the encrypted result is sent. When it signs, it signs with your master key using ES256K, and the signature travels with the record.
Recovery is designed, not shipped
Two recovery mechanisms are designed and are not available today: splitting a recovery secret across several holders with Shamir's scheme, so no single holder can reconstruct it, and delegating custody of a key to a KMS or HSM provider. Neither ships, so neither should appear in a design you are committing to now.
What exists today is the recovery path implied by the shipped row: your password reconstructs your key encryption key, and your key encryption key decrypts your stored master key. Lose the password and the SDK token, and the encrypted data stays encrypted.
What this design does not provide
There is no forward secrecy, and that is a deliberate choice rather than an oversight.
Keys here are long-lived, and for content the encryption secret is derived from the payload itself. Both properties buy something real: any party that legitimately holds the content can re-derive the key and verify the record for itself, without asking the sender for anything. The cost is symmetrical. A key that opens a record today opens it in five years, and rotating a key does not retroactively close the records the old one could read.
Publishing that is more useful than leaving it out. Leaving it out would make the rest of this page harder to trust, not easier.
Specified by the SDX Protocol. mintBlue implements this concept; the SDX Protocol specifies it. Read the specification
The specified key hierarchy, its derive-not-store principle and its rotation model belong to the protocol and are not what the shipped SDK does today. Generations explains why the two descriptions differ and which one applies to the code you have installed.