🏗️ Security architecture
Inheriti® Business layers policy and cryptography so that no single party, including SafeTech, can reach your data alone. This page describes how the pieces fit.
The key chain
- Organisation Key
- Plan key
- HSM key pair
- SSDP+ key
Created at organisation setup, derived in the browser from the owner's Organisation Recovery Key with Argon2id. Sealed to members' devices via SafeKey Mobile, and never held by SafeTech.
Protects: every plan key.
Created at plan creation, unique per plan. It exists in storage only as ciphertext: wrapped by the Organisation Key, sealed by the HSM.
Protects: every share of that plan.
Generated per organisation inside the managed HSM. The private key never leaves the hardware, and what the HSM returns is still encrypted under the Organisation Key.
Protects: the wrapped plan key.
Created per plan at the protocol layer; it encrypts the data itself (AES-256) and is split into shares, never stored whole.
Protects: the plan's data.
The chain works like this: the SSDP+ key encrypts your data (AES-256) and is split along with it. The plan key encrypts every share. The plan key is wrapped by the Organisation Key (AES-GCM), sealed by the HSM, and only then stored, as ciphertext that neither SafeTech nor any single member can open.
Why SafeTech cannot decrypt your data
The Organisation Key is derived from an Organisation Recovery Key only the owner holds, using the Argon2id key derivation function with a random salt, and never reaches our servers; we store only the salt and a non-reversible verificator.
At reveal time the HSM peels off only its own layer and returns material that is still encrypted under the Organisation Key it never held.
Full access to our database, storage and HSM together is still not a decryption path.
What this architecture defends against
| Threat | What answers it |
|---|---|
| A stolen or leaked database | Plan keys exist there only as ciphertext, double-locked by a key we never hold |
| A breached storage layer or cloud account | Any single layer yields shares that are useless on their own |
| Phishing and faked approvals | Every approval is confirmed on a phone or in an inbox only the member holds; a convincing email approves nothing |
| A compromised insider at SafeTech | The Organisation Key never reaches our servers, and the HSM's private key never leaves the hardware; no party holds both |
| A departed employee's devices | Access is evaluated live at reveal time; stale shares on old devices are inert |
| Purely remote attacks | The custodian key share is released by hand from SafeKey Mobile or SafeKey Pro |
| Tampered records | The validator share trail lives on InheritiChain, and audit exports carry a SHA-256 hash |
Anatomy of a reveal
A reveal is not the encryption chain run backwards with a password. It is a sequence in which governance comes first and cryptography follows:
- A member requests access to a plan.
- The Organisation Key is released from SafeKey Mobile into the requester's browser session.
- Dead Man Switch: on continuity plans, the creator's countdown runs and can stop the request.
- Authentication: the requester confirms the request with SafeKey Mobile or an email link, where required.
- Moderation: the plan's moderators approve, where configured, with the set threshold.
- The validator shares are collected from your smart contract on InheritiChain.
- The data shares are collected from the Inheriti® Vault.
- The custodian pair completes: its data share from the custodian depot, its key share released by hand from SafeKey Mobile or SafeKey Pro.
- The sealed plan key is unsealed inside the HSM, then unwrapped with the Organisation Key in the browser. Only now can the shares be decrypted.
- Shamir's Secret Sharing recombines the shares, and the SSDP+ layer performs the final decryption. The data appears only on the requester's own computer: in their browser, or in the Inheriti® tools they use, and never in the hands of an AI assistant.
Steps run in order, and every gate must pass before the collections even begin.
Leaving, revoking and reconfiguring
Access checks happen at reveal time, against your live organisation:
- Removing a member or team invalidates their share access records immediately. A stale share left on a departed member's device is inert: it can no longer be authorised or served.
- Reconfiguring a plan, for example when its protected data changes, creates new shares from the new information and deletes the old shares from every storage layer. Earlier custodian share claims become stale.
- Every collection is gated on the member being active, authorised through teams and roles, and holding a valid access record, evaluated at that moment.
Personnel changes therefore take effect without re-encrypting anything, and without a race against whatever might still sit on old devices.
Access decisions are made against your organisation's current teams, roles and members, not a list frozen when the plan was created.