Key Management Architecture

Every key in SANKET has a defined origin, location, purpose and lifetime. The organising principle is simple: keys that protect content are created and held on endpoints; keys that protect the installation are created and held inside the customer's installation; Tosh Defence holds only the keys that sign licences and releases.

Key lifecycle management follows the general model of NIST SP 800-57: generation, distribution, storage, use, rotation, revocation and destruction are defined for every key class.¹

Figure 4: Key hierarchy and lifecycle

11.1 Key Generation and Entropy

All keys are generated from operating-system cryptographically secure random number generators: libsignal draws from the platform CSPRNG; the mobile JavaScript environment installs the platform CSPRNG as its random source before any cryptographic library loads; Node.js keys use its OpenSSL-backed generator; OpenBao generates its own Transit keys. No key is derived from a password except where a password is the intended protection (vault, app passcode, backup passphrase), and in those cases a deliberately slow key derivation function is used.²

11.2 Hardware-Backed Storage

On iOS, the libsignal store and device secrets are kept in the Keychain with accessibility classes that restrict them to this device, so they are excluded from device backups and transfers, and every value is additionally encrypted with AES-256-GCM under a key derived from a Secure Enclave P-256 key (ECDH, then HKDF-SHA256 to a 256-bit key).³ On Android, the same values are encrypted with AES-256-GCM in the module's own store under a key held in StrongBox where the phone has one, and in the TEE-backed Android Keystore otherwise; Android application backup is disabled for the app.⁴ The libsignal identity key stays in libsignal's own format, because the Secure Enclave cannot hold a Curve25519 key, but it is stored only under the hardware wrapping key; the device certificate key and the account list key receive the same protection. Items copied from one phone to another do not decrypt.

Each phone records its protection level (Secure Enclave on iOS; StrongBox or TEE on Android; software only on simulators and emulators), the server holds it per device and the administrator console shows it, and policy can require a minimum level. On Android the level is backed by Key Attestation, verified offline by the installation (Chapter 14). Deleting the hardware key makes every wrapped item unreadable at once, which is the fast path of a wipe.

Attachment files and decrypted viewer copies on iOS carry the Complete data-protection class, whose file keys the operating system discards when the device locks. On desktop the same protocol runs with its secrets in the operating system's protected credential store, and an app passcode adds a second, passcode-derived wrap held only in memory; deployment guidance for desktop key storage on each operating system is given in the controlled edition.

11.3 Key Inventory

Table 19: Key inventory: origin, storage, purpose, rotation and exposure consequence

11.4 Rotation, Expiry and Revocation

• Prekeys rotate on a regular cycle; a scheduler on each client replenishes one-time prekeys before they run out. When a device's registration changes, the server discards that device's stale one-time prekeys.
• Session keys rotate continuously through the Double Ratchet; no administrator action is needed.
• Identity keys rotate account-wide through an operation that requires proof of the previous identity and a TOTP step-up. Other devices of the account clear their protocol state and sign out, and peers re-establish sessions.
• Devices are revoked by the user or an administrator. Revocation stops token refresh and request authorisation on the next check, removes the device from future fan-outs, and, when requested, triggers a remote wipe that the device executes only after confirming the revocation with the server.
• Device client certificates are short-lived and re-minted by the device before they expire; revocation, lost mode and wipe delete the certificate and its key on the device, and the edge refuses a revoked certificate through the OpenBao revocation list.
• Account list keys are long-lived. A device leaves the list through a signed removal entry; the key itself is replaced only by a vault restore that passes the restore proof or by an audited recovery procedure, which shows every peer an identity-change style warning.
• Administrator security keys are added and removed by their administrator after a fresh step-up; an owner can revoke all of another administrator's keys with the owner's own fresh security-key assertion; a sign counter that goes backwards is treated as a suspected clone and refused.
• Refresh tokens are single-use. A replay of an already-rotated token revokes the device and raises a critical security event.
• Server secrets are rotated by the operator. Token-secret rotation invalidates existing sessions, which then require sign-in.
• Licence and release keys rotate through the trust bundle, which lists active, previous and revoked keys and is itself signed by a root key.

11.5 Compromised Key Response

Table 20: Response to suspected key compromise

11.6 Disaster Recovery of Keys

End-user message keys are deliberately not recoverable by the organisation: if a user loses every device and has no vault backup, past message history on those devices is gone and new sessions are created on the replacement device. This is a direct consequence of keeping keys off the server. Organisations that need recovery of the user's identity can enable the encrypted vault, accepting the trade-off described in Chapter 2. Installation keys are recovered from the operational backup (which includes OpenBao data and configuration) together with the unseal quorum and the backup passphrase, which must be held by separate custodians.

The account list key, which signs each account's device list, follows the same principle. It is sealed into the user's encrypted vault backup on the device, and a restored copy is released on a new device only after the server has verified the device-restore proof (Chapter 13); a vault blob alone never yields a usable list key. An account without a vault backup is recovered only through an audited procedure in which every peer sees an identity-change style warning, so recovery cannot happen silently.

In the high-availability profile OpenBao runs as a three-node raft cluster with TLS between the nodes, and each node is unsealed by the key-share ceremony after a restart; a node started without the unseal quorum serves nothing. Encrypted raft snapshots are shipped to the second site, where a restore is verified before use. The reference topology is designed for a recovery point objective of 5 minutes and a recovery time objective of 1 hour with an asynchronous second site; these are design targets, and each deployment's disaster-recovery drill records its own measured figures (Chapter 32).

11.7 Hardware Security Modules

SANKET does not require an HSM. The released configuration unseals OpenBao with a Shamir key-share ceremony, on every node of the cluster in the high-availability profile. Customers whose policy requires hardware protection are recommended to hold their root CA in an HSM and to evaluate OpenBao's auto-unseal options against their HSM or key-management infrastructure (Chapter 33). Neither is part of the released configuration.

---

Footnotes

1. E. Barker, "Recommendation for Key Management: Part 1 - General", NIST SP 800-57 Part 1 Rev. 5, May 2020. ↩

2. E. Barker, J. Kelsey, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", NIST SP 800-90A Rev. 1, June 2015. ↩

3. Apple Inc., "Apple Platform Security Guide" (Secure Enclave, Keychain data protection), support.apple.com/guide/security. ↩

4. Android Open Source Project, "Android Keystore system" and "Hardware-backed Keystore", developer.android.com and source.android.com. ↩