Security overview
Policy, encryption, and provenance that assume compromise
Every Torvus control is designed so no single actor—including us—can leak your most sensitive disclosures.
Digital Legacy release paths inherit the same controls: envelope keys reside in segregated KMS clusters today with hardware-backed customer key management on the roadmap, and every estate event produces provenance receipts that executors and beneficiaries can independently verify.
Architecture overview
Zero-trust segmentation
Vault, orchestration, and audit planes run on isolated workloads with mutually-authenticated service mesh boundaries. Each request carries signed policy context to minimise implicit trust.
Policy-governed access
Policies live in attested storage. Release workflows must supply policy hashes and approvals before keys are re-wrapped. Operators can’t bypass policy even with elevated credentials.
Attested runtime
Critical services boot with measured start-up, HSM-backed environment sealing, and monitored integrity. Drift triggers alerts and can auto-revoke release privileges until re-attested.
Encryption & key management
Torvus treats keys as policy-bound artefacts. Client devices derive data keys, seal them to policy, then store ciphertext. Release orchestration requires quorum validation and leaves an independently verifiable provenance trail.
- 1. Client-side encryption
- 2. Policy sealing
- 3. Oracles
- 4. HSM/TEE key shares
- 5. Release orchestrator
- 6. Recipient portal
Client-side encryption
Torvus SDKs encrypt files and secrets in the browser or client before ingestion (XChaCha20-Poly1305 or AES-GCM). Plaintext never touches Torvus infrastructure.
Key derivation & sealing
Per-item data keys are wrapped with envelope keys. Policy metadata (conditions, recipients, approvals) is sealed and integrity-protected to prevent tampering. Digital Legacy estates add staged KMS hardening with a customer-managed key roadmap.
Split custody
Envelope keys are split across HSM clusters and attested TEEs. Release orchestration requires quorum-based reassembly, tied to current policy state and approvals.
Audit-grade logging
Each unwrap logs the policy hash, approvals, duress state, and derived key material fingerprint. Customers can mirror logs in real time to their own SIEM or evidence store.
Identity & access assurance
Authentication is phishing-resistant by default, with policy-tuned fallback paths only where necessary. Sessions are monitored for anomalies, and emergency access requires multi-party proof.
Passkeys first
WebAuthn/passkeys are required for administrators and recipients. FIDO2 security keys supported. Policies decide where TOTP fallback is allowed.
Adaptive session controls
Session binding uses device attestation, IP reputation, and optional geo-fencing. Abnormal patterns can require re-authentication or trigger duress pause automatically.
Least-privilege platform roles
Granular roles separate vault admins, policy authors, and operational approvers. Emergency paths are logged, time-bound, and require multi-party approvals.
Duress & liveness controls
Operators can act under pressure without leaking intent. Pauses, decoys, and liveness checks provide breathing room while preserving evidence.
Silent pause
Operators trigger a pause from the UI, hardware key, or API. Releases freeze instantly, assets stay sealed, and stakeholders receive discreet status without endangering the operator.
Decoy responses
Policies can serve redacted or pre-approved decoy content under duress to avoid tipping off adversaries while buying time for response teams.
Liveness checks
Scheduled liveness prompts plus optional biometrics ensure an operator is present and safe. Missed checks escalate via secondary channels before triggering release logic.
Transparency, audit & provenance
Releases produce evidence automatically. You choose where to mirror logs and who can verify them, ensuring partners and regulators see exactly what happened.
End-to-end provenance
Every file, note, or secret is tagged with data lineage. Provenance certificates explain who ingested, who approved, and why releases were triggered.
Immutable export
Audit exports include cryptographic receipts so third parties can verify timelines independently. Customers can anchor receipts into their own transparency ledgers.
Recipient accountability
Recipients sign for retrieval with passkeys or attested devices. Optional selfie/KYC capture can attach to provenance to satisfy legal or estate requirements.
Compliance stance
Torvus is designed to augment your compliance programme rather than replace it. Ask for our latest control mappings and vendor due diligence package.
Australian Privacy Principles
Data residency controls, structured consent, and breach notification workflows map to APP requirements. Regional segregation is available for sensitive programmes.
GDPR alignment
Data minimisation and purpose binding are built-in. Tamper-evident logs support Article 30 documentation and DSAR fulfilment with zero-knowledge export options.
Risk & assurance
Independent pen-tests, threat modelling, and secure SDLC practices are table stakes. Customers receive current summaries in the security portal, including SLA targets.
FAQs
Who can decrypt Torvus vault contents?
Only policy-compliant recipients with valid approvals. Operators and Torvus staff never receive plaintext—keys remain sealed inside customer-controlled policies, HSM shares, and attested TEEs until release conditions are satisfied.
How does Torvus verify duress triggers?
Duress triggers can come from dedicated hardware buttons, passphrase entry, or detection heuristics. Each trigger is authenticated with the operator’s keys and recorded in an immutable log so responders can prove when a pause occurred.
What happens if a policy misfires?
Policy dry-runs show which predicates pass or fail before activation. Runtime guardrails permit emergency pause, while audit trails expose the exact signals that influenced a release so teams can adjust policies quickly.
Can Torvus integrate with our compliance tooling?
Yes. Audit logs and provenance receipts are available via streaming APIs and scheduled exports. Governance teams can feed Torvus evidence into GRC, SIEM, or digital forensics pipelines.