Sentinel Protocol Demo Data Flow Overview

1. Key Sharding Flow: Fragmentation of Identity (Initialization)

This is the starting point of the system. Through the SSS (3,2) threshold algorithm, the user's absolute control is transformed into distributed trust.

Input: System randomly generates 12 BIP-39 standard mnemonic words.
Action: Split the Entropy corresponding to the mnemonic words into 3 independent mathematical shares:
- Share A (Device): Presumed to be stored in the user's mobile phone security chip.
- Share B (Cloud): Presumed to be stored on the Sentinel server.
- Share C (Physical): Presumed to be printed on a physical inheritance card and given to the heir.
Verification Point: Demonstrate that the original 12 mnemonic words can be reconstructed through any of the three combinations (A+B), (B+C), (A+C).

2. User Inner Encryption Flow: Establishing a Private Vault (Vault Layer)

This is client-side encryption, ensuring "Zero-Knowledge" storage, meaning the system cannot perceive the data content without the shares.

Input: User private data (plaintext) + Mnemonic words recovered in Step 1.
Action:
- Derive a symmetric encryption key (AES-256-GCM) from the mnemonic words.
- Use this key to encrypt the data, generating Ciphertext 1.
Feature: This step simulates completion on the user's local device; Ciphertext 1 is the primary protection form of user assets.

3. System Outer Wrapping Flow: Double Encapsulation (Gateway Layer)

This is the company/platform layer encryption, used to implement "Passive Verification" and "Permission Locking".

Input: Ciphertext 1 + Company generated independent RSA Public Key.
Action:
- The system generates a set of RSA public/private key pairs (Company Keys) unrelated to the user.
- Use the RSA Public Key to re-encrypt Ciphertext 1, generating Ciphertext 2.
Logical Value: The generated Ciphertext 2 now has double security—even if the mnemonic is leaked, it cannot be opened without the company private key; even if the company private key is leaked, it cannot be opened without the mnemonic shares.

4. Decision Trigger Flow: Stripping the System Shell (Trigger/Unlock Layer)

This is the turning point of the Demo, simulating the system releasing the first layer of lock when "subscription fails" or during "normal access while alive".

Input: Ciphertext 2 + Company RSA Private Key.
Action: Use the private key to decrypt Ciphertext 2, restoring it to Ciphertext 1.
Business Mapping:
- Alive Mode: User is active, system private key cooperates in real-time, allowing data to flow to the user.
- Inheritance Mode: After death is confirmed, the system permanently releases this private key permission to the data packet.

5. Multi-Scenario Restoration Flow: Final Extraction (Restoration Scenarios)

This is the end of the Demo, showing how data eventually returns to human hands in different social scenarios.

Input: Ciphertext 1 restored in Step 4 + Different combinations of shares.
Scenario Simulation:
- Scenario 1: Normal access while alive
  - Combination: Share A (Phone) + Share B (Cloud) --> Recover Mnemonic --> Decrypt Ciphertext 1.
  - Significance: Proves that the user can view data without the inheritance card while alive.
- Scenario 2: Standard inheritance after death
  - Combination: Share B (Cloud) + Share C (Physical Card) ---> Recover Mnemonic ---> Decrypt Ciphertext 1.
  - Significance: Simulates the user passing away, and the heir completing the handover relying on the card and the share released by the server.
- Scenario 3: Pure testing verification, since the user holds all 12 mnemonic words
  - Combination: Share A (Phone) + Share C (Physical Card) --> Recover Mnemonic --> Decrypt Ciphertext 1.
  - Significance: Testing purposes.

3.7 KiB Raw Blame History