Sentinel Protocol (哨兵协议) Technical Whitepaper

1. Abstract

Sentinel Protocol proposes a digital asset protection framework based on "sovereignty origin + recursive fragmentation." By reducing adoption barriers through AI privacy proxy, locking sovereignty execution root through TEE hardware, and combining multi-level SSS algorithms to enable perpetual asset succession. The core innovation lies in the dual-track guarantee of smart contract dead man switch and statutory trust storage mechanism, ensuring that after a commercial entity ceases service, the open-source community can take over access rights, and encrypted data remains physically preserved and decryptable over long historical periods.

2. Core Architecture: Four-Layer Defense System

2.1 AI Accessibility Layer

Functional Assistant: Encapsulates advanced prompts into preset plugins, providing natural language interaction entry points.
Privacy Proxy:
- Local Interception: Executes sensitive keyword filtering on the client side, ensuring private key fragments or personally identifiable information never leave the local environment.
- De-identified Forwarding: Relay proxy removes metadata such as IP addresses and device IDs, allowing third-party AI vendors to receive only anonymized pure instructions.
Local Semantic Summary: Client-side AI locally summarizes assets, only prompting users to enter hardening process when valuable targets are discovered.

2.2 Hardware Sovereignty Layer

Master Key (K): Derived from mnemonic phrases, locked within the phone's TEE (Trusted Execution Environment). We don't trust software systems, only mathematics locked in chip architectures.
Inner Hardening: Data completes the first-layer hardware-level inner encryption using K before leaving the device.

2.3 Sentinel Vault Layer

Outer Hardening: Server clusters perform secondary public key encryption on ciphertext to defend against transmission risks.
Perpetual Storage: Double-encrypted ciphertext is custodied on decentralized permanent networks such as Arweave.

2.4 Third-Party API Integration Layer

Mode A: Standalone Sovereignty: Third-party applications work with independent mnemonics. Sentinel Protocol serves solely as storage medium and algorithm suite, with completely isolated logic.
Mode B: Collaborative SDK: Third-party applications integrate Sentinel encryption SDK. After user biometric authorization, collaborative sharing of master authorization data breaks down data silos.

3. Role Definitions and Key Derivation System

The system follows strict derivation logic from "mathematical meta-seed" to "physical shards":

Mnemonic: System's root seed, the sole mathematical origin of all keys.
Master Key (K): Locked within TEE chip, serving as the daily sovereignty execution root.
S0 (Redundancy): Redundancy backup shard. Saved offline by users (physical printout/USB drive) as final recourse.
S1 (Cloud): Distributed recursive shard, custodied by cloud nodes.
S2 (Heir): Heir shard. Distributed by user to designated estate handlers.

4. S1 Distributed Recursive Fragmentation (Multi-Server Fragmentation)

To completely eliminate centralized node data breach and collusion risks, S_1 adopts a "divide and conquer" strategy:

4.1 Secondary Fragmentation Logic

After the mobile device generates S_1, instead of uploading it directly, it is fragmented again through the SSS algorithm into n sub-shards (n \ge 2): \{S_{1a}, S_{1b} \dots S_{1n}\}.

4.2 Node Encryption and Storage

Independent Encryption: Each sub-shard is encrypted using the independent public key of its corresponding storage node.
Distributed Storage: Sub-shards are distributed to multiple geographically isolated and logically independent sentinel server nodes.
Security Characteristics: No single server possesses complete S_1. Hackers breaching a single database only obtain "fragments of fragments."

5. Business Logic Workflow

5.1 Data Ingestion Flow

Identification and Confirmation: Local AI discovers information, obtaining user biometric authorization.
Double Encryption: TEE invokes K to complete inner hardening \rightarrow Server executes outer hardening.
Recursive Distribution: S_1 is fragmented into multiple sub-shards, then encrypted and sent to different geographic nodes.

5.2 Succession and Recovery Flow

Status Determination: Smart contract detects incapacity signal.
Shard Aggregation: Multiple nodes verify contract instructions, decrypt and release their respective sub-shards.
Multi-level Reconstruction:
- First-level Reconstruction: Sub-shards reconstruct the original cloud shard S_1.
- Second-level Reconstruction: S_1 combined with heir-held S_2 (or redundancy shard S_0) synthesizes Master Key (K).
Asset Decryption: Using K to peel off inner encryption and retrieve original assets.

6. Survival Guarantee and Security Summary

6.1 Survival Guarantee (The Great Survival Protocol)

Statutory Trust and Renewal: Dedicated trust fund independent from commercial entities, ensuring physical validity of storage fees over long historical periods.
Dead Man Switch: Once the commercial entity becomes incapacitated, smart contracts automatically release ciphertext indexes and node private keys, with open-source community taking over access.
Open-Source Self-Rescue: Users can leverage open-source tools, combined with mnemonic phrases or S_2/S_0, to locally restore K; even if official services disappear, data can be recovered.

6.2 Security Highlights

Anti-Database Breach (Anti-DB Leak): Cloud-side S_1 exists in fragmented state; single-point compromise is meaningless.
Privacy Sovereignty: Privacy Proxy physically isolates AI-side profiling risks.
Uniqueness and Robustness: K locked in TEE, and system can reconstruct data even when some nodes go offline.

6.1 KiB Raw Permalink Blame History