Operational Deployment Scenarios (or "Use Cases")
Security Architecture: Standard vs. Advanced
The Cryptosign ecosystem is designed with absolute modularity. While all our hardware utilizes the robust Shamir’s Secret Sharing (SSS) protocol via your air-gapped zk-terminal, the physical security model depends on your specific threat landscape.
The "Citadel" Protocol (Forward Model)
Core Principle: SSS Shares + Required Master Key (Medallion) Threat Profile: Physical Coercion, Unwarranted Search and Seizure, Hostile Third Parties.
In Forward Deployment, your cryptographic seed is split into encrypted SSS shares. To reconstruct the wallet, you require M-of-N steel plates and the physical Citadel Medallion (the Master Key). The payload and the decryption key are air-gapped.
Use Case 1: High-Net-Worth Individuals (The Trustee Network) You hold 3 encrypted SSS shares yourself. You purchase multiple Citadel Medallions. You distribute these Master Key Medallions to trusted "Trustees" (a family office, your lawyer, a secure bank vault).
- The Scenario: If an attacker finds your steel plates, they cannot decrypt the payload. If you are physically coerced, you can safely disclose the location of the plates, because the funds are secure as long as the Trustees do not release the Medallion. Recovery requires the M-of-N plates AND cooperation from at least one (or M-of-N, depending on your setup) of your Trustees to authorize the decryption.
Use Case 2: Geo-Redundant Vaulting You keep the required M-of-N encrypted plates in your primary residence and office. You store duplicate Master Key Medallions in geographically separate secure vaults (e.g., Singapore and Zurich).
- The Scenario: In the event of a catastrophic regional disaster or the complete destruction of your primary location, your funds are recoverable by traveling to the secure secondary location and utilizing the backup Medallion.
The "Succession" Protocol (Reverse Keyless Model)
Core Principle: Pure SSS Shares (No Master Key Needed) Threat Profile: Death of the Custodian, Lack of Technical Heir, Complex Estate Logistics.
In Reverse Deployment, the cryptographic payload is stored directly on the SSS plates without the additional Master Key layer. This minimizes the complexity of the recovery process while maintaining the M-of-N security threshold.
Use Case 1: The Inheritance Plan (Non-Technical Heirs) You want your heirs to inherit your crypto assets, but they have zero technical knowledge and do not own a hardware wallet. You split your seed using the zk-terminal into 5 plates (3-of-5 threshold). You give two plates to your spouse, one to your notary, and keep two in separate vaults.
- The Scenario: In the event of your passing, your spouse and notary can easily combine their three plates to reconstruct the exact seed phrase. There are no additional keys or medallions to manage, making it the most straightforward and secure path for non-technical heirs.
Use Case 2: Legal Escrow & Multi-Jurisdictional Wills You designate the recovery process to a legal firm or notary. You distribute plates across multiple jurisdictions (e.g., Swiss law firm and London law firm).
- The Scenario: The notary or executor can assemble the M-of-N plates from the various legal entities and immediately recover the funds for distribution to the estate, with no dependence on the availability of a physical Medallion that might be lost in the estate chaos.
The "Enterprise" Protocol (B2B & Admin Root Accounts)
Core Principle: Large-Scale Multi-Signature & Root Authority Key Splits Threat Profile: Disgruntled Employees, Single Point of Failure, Admin Root Account Hijacks.
Cryptosign provides critical infrastructure for B2B enterprises managing large digital asset vaults, running admin root accounts, or utilizing security APIs.
Use Case 1: Hardware API and Vault Access Controls You are a security firm building hardware security modules (HSMs) or managing complex vaulting logic that requires an external, physical "physical kill-switch."
-
Use Case 2: Admin Root Account Protection Your DevOps team manages your company's AWS Root Account or primary code repository. A single compromised admin credentials would be catastrophic.
- The Scenario: You do not give the Root password to any human. You split the AWS Root password (or primary recovery seed) into a 5-of-8 SSS scheme using Cryptosign plates. These 8 plates are distributed to the company C-Suite and lead engineers. Any sensitive root operation requires at least 5 executives to physically cooperate and enter their keys into the air-gapped terminal. No single individual has the "keys to the kingdom."