Trust & Threat Model

The DeRec protocol provides security guarantees under explicitly defined trust and threat assumptions. This page clarifies what the system protects against, what assumptions must hold, and what falls outside the protocol’s guarantees.

Security Objective

The primary security objective of DeRec is to ensure that the Secret can only be reconstructed from the Helper set when a defined threshold t of independent Helpers participate in the recovery process. The protocol prevents unilateral recovery by any single Helper and prevents recovery when fewer than the threshold number of Helpers cooperate.

The protocol does not attempt to eliminate trust entirely. Instead, it minimizes and isolates trust boundaries.

Trust Assumptions

DeRec relies on the following assumptions.

Trusted Owner Identity

The Owner environment is assumed to be trusted during:

• Secret creation

• Share generation

• Recovery and reconstruction

When the Owner identity spans multiple devices via the replica feature, every Replica device is part of the same trust boundary as the Owner. The protocol does not separate them cryptographically — a Replica device holds the full Secret and can act on behalf of the Owner identity in full. Compromise of any device under the Owner identity is treated as compromise of the Owner.

If any device under the Owner identity is compromised at the time of recovery, the confidentiality of the Secret cannot be guaranteed. The protocol does not protect against a malicious or fully compromised Owner or Replica.

Helper Independence

Security depends on Helper independence. Helpers are assumed to operate independently and not collude beyond the configured threshold.

If fewer than the threshold number of Helpers collude, the Secret remains protected. If at least the threshold number collude and combine their shares, reconstruction becomes possible.

Correct Cryptographic Implementation

The security guarantees assume that:

• Secret-sharing algorithms are correctly implemented

• Secure communication channels are correctly established

• Protocol validation rules are enforced. Implementation flaws can invalidate protocol guarantees.

Adversarial Model

The protocol protects against the following adversarial scenarios.

• Single Helper Compromise — If one Helper is compromised, the attacker gains access to only a single share. A single share is insufficient to reconstruct the Secret.

• Partial Helper Compromise — If fewer than the threshold number of Helpers are compromised, reconstruction remains impossible.

• Network Interception — Every protocol message is encrypted under per-channel Shared Keys. Interception of protocol communication does not reveal the Secret or any share material; only message metadata is exposed on insecure transport. See the network trust boundary note at the bottom of this page.

• Helper Unavailability — If some Helpers are offline but at least the threshold number remain available, recovery remains possible.

• Malicious Helper Behavior — A Helper may attempt to return invalid or manipulated shares. The protocol mitigates this through share commitments and verification mechanisms that allow the requester (the Owner, or any Replica acting on its behalf) to detect incorrect shares during recovery.

Out-of-Scope Threats

The following scenarios fall outside the protocol’s security guarantees.

• Threshold-Level Collusion — If the threshold number (or more) of Helpers collude and combine shares, the Secret can be reconstructed.

• Compromised Owner or Replica at Recovery — If any device under the Owner identity is compromised during recovery, the Secret may be exposed after reconstruction.

• Compromised Owner Before Protection — If the Secret is compromised before share distribution begins, the protocol cannot provide protection.

• Replica Compromise — A compromised Replica device holds the full Secret and the per-Helper Shared Keys. It can impersonate the Owner toward every Helper and read every user secret. See Recovery transitivity for the full discussion.

• Improper Threshold Configuration — If the threshold is set too low relative to Helper trust assumptions, security is weakened by configuration, not protocol failure.

• Cryptographic Breakthroughs — The protocol assumes the continued security of underlying cryptographic primitives.

Trust Boundary Summary

Component	Trusted For	Not Protected Against
Owner	Secret lifecycle and reconstruction	Owner compromise during recovery
Replica	Same as Owner — full Secret, full authority on its behalf	Compromise of any device under the Owner identity
Helper	Storage and return of one share	Collusion at or above threshold
Network	Delivery of protocol messages	Out-of-band ContactMessage exposure; metadata leakage (*)

The DeRec protocol minimizes trust by distributing recovery authority across multiple independent Helpers, but it does not eliminate trust entirely. Security is derived from threshold-based reconstruction combined with explicit trust assumptions.

(*) Network Trust Boundary

Outside of the initial ContactMessage transmission in the Pairing flow, the protocol is designed to not need a secure communication channel. Every message is encrypted under a pre-established Shared Key and wrapped in a DeRecEnvelope. When transmitted over an insecure channel, only message metadata is exposed.