Secret Key

Product Introduction

1. Definition: Secret Key is an open-source, self-hosted emergency access and digital inheritance solution for password managers. It is a multi-layer security system that cryptographically splits a master password using Shamir's Secret Sharing (SSS) and distributes the shares to trusted individuals.
2. Core Value Proposition: It exists to solve the critical problem of digital asset loss upon death or incapacitation. It provides a secure, recoverable backup for your password database master key, protected during your lifetime by SMS two-factor authentication (2FA) and a 48-hour timelock with a panic button.

Main Features

1. Shamir's Secret Sharing (SSS) for Password Splitting: The core cryptographic engine. It splits the master password into n shares, requiring a minimum threshold k (e.g., 3 of 5) to reconstruct it. It uses the secrets.js library format (compatible with iancoleman.io/shamir) over GF(2⁸) with 1024-bit padding, providing information-theoretic security where individual shares reveal zero information about the secret.
2. Multi-Factor Authentication & Access Control: Every login attempt requires a unique username/password (per trustee) followed by a 6-digit SMS verification code sent via an external gateway (SMSPlanet). Failed attempts trigger server-side IP and account lockouts (3 attempts per 15 min). Successful reconstruction initiates a mandatory 48-hour waiting period before file downloads are unlocked.
3. Panic Button & Timelock System: This is the critical collusion protection layer. Upon successful password reconstruction, the system immediately emails the owner details (who, when, IP). The email contains a unique, cryptographically secure 256-bit token link to a "Panic Button" that can permanently block downloads without requiring login. This ensures the owner retains ultimate veto power.
4. Self-Hosted, Zero-SQL Architecture: The entire system runs on user-provided PHP 8+ hosting. It uses flat files (JSON/INI) for configuration and logs, requires no database (SQL), and keeps sensitive files outside the web root. The server only hosts the web panel and gated download scripts.
5. Offline Configuration & Share Carrier Generation: The setup dashboard runs locally in a browser. The owner configures trustees, splits the password using client-side JavaScript (bcrypt for hashing), and generates printable "Secret Key Cards" as PDFs. These cards contain individual login credentials, the hex/QR share, and instance URL.

Problems Solved

1. Pain Point: Digital Asset Inaccessibility After Death. Families lose access to email, cloud photos, financial accounts, cryptocurrency wallets, and 2FA-protected services because passwords die with the owner. Legal procedures often cannot recover these assets.
2. Target Audience: Security-conscious individuals, technical professionals, crypto holders, estate planners, and anyone with a substantial digital footprint who uses a password manager (KeePass, Bitwarden, 1Password) and wants a resilient inheritance plan.
3. Use Cases:
   • Estate Planning: Ensuring heirs can access critical financial, email, and administrative accounts.
   • Sole Proprietor/Founder Continuity: Securing business account access for partners in case of founder incapacitation.
   • Cryptocurrency Inheritance: Providing a recoverable method to access private keys or exchange accounts held in a password manager.
   • Personal Digital Legacy: Granting loved ones access to precious family photos and videos stored in encrypted clouds.

Unique Advantages

1. Strengths & Limitations (Pros & Cons):

   • Pros:
     • Mathematically Secure Inheritance: SSS ensures no single trustee can compromise the secret.
     • Owner-Centric Protection: SMS 2FA and the panic button provide active lifetime protection against premature access.
     • Data Sovereignty: Self-hosted, zero-SQL architecture means all data remains on infrastructure you control.
     • No Single Point of Failure: Redundancy is built-in (e.g., 3 of 5 shares).
     • Transparency & Auditability: Open-source (MIT license) allows full security review.
   • Cons:
     • Technical Setup Burden: Requires owning/managing a web server (PHP 8+, HTTPS), which excludes non-technical users.
     • Dependency on SMS Gateway: Relies on a third-party SMS service (SMSPlanet) for 2FA, introducing a cost and external dependency.
     • Trustee Onboarding Complexity: Trustees must be comfortable with a multi-step login/SMS/decryption process and need to safely store a physical card.
     • Not a Legal Tool: Does not replace a will or formal legal inheritance processes for regulated assets.

2. Key Alternatives & Differentiation:

   • Encrypted USB + Written Instructions (Manual Method):
     • Difference: Secret Key eliminates the single point of failure (one USB/note) and adds active oversight (SMS, timelock, panic button). It distributes trust and provides cryptographic guarantees instead of physical security alone.
   • Cloud-Based Inheritance (e.g., Google Inactive Account Manager, 1Password Emergency Kit):
     • Difference: Secret Key is self-hosted, protecting metadata and access patterns from any third party. It uses proactive verification (SMS) and a delay instead of a passive time-based trigger. It is also password-manager agnostic.
   • Professional Digital Inheritance Services (e.g., Dead Man's Switch, Estate Planning Firms):
     • Difference: Secret Key is a free, open-source tool focused purely on the technical problem of password recovery. It does not provide legal advice or holistic estate planning services but integrates as a technical component of a broader plan.

Frequently Asked Questions (FAQ)

1. Is Secret Key secure if someone steals one of the physical cards? A stolen card alone is insufficient for access. The attacker would still need the SMS-capable phone number associated with that card's account to complete the 2FA login, and even then, they could only contribute one share, revealing nothing about the master password without the required number of other shares.

2. Can I use Secret Key without exposing my full password database to my heirs? Yes. Secret Key does not mandate what you store. You can create a separate, dedicated "emergency" KeePass or Bitwarden database file containing only the accounts you intend your heirs to access (e.g., main email, cloud storage, a bank account). You then configure Secret Key to protect the master password for that specific file.

3. What happens if I lose my phone and can't receive the SMS alert when the panic button is triggered? The panic button email is the primary alert mechanism. It is critical to ensure the alert email address is one you can access via backup methods (e.g., a spouse's device, a backup email). The system itself does not have an alternative alert channel. This underscores the importance of configuring a reliable, recoverable email address.

4. How does Secret Key compare to simply using a multi-signature (multisig) cryptocurrency wallet? They solve related but different problems. A multisig wallet specifically secures cryptocurrency on-chain. Secret Key is a general-purpose secret-sharing system that can protect the master password to a database, which could contain cryptocurrency wallet seeds, passwords to exchanges, and countless other non-crypto assets (email, social, subscriptions). It operates at a higher level of abstraction.

5. Is the 48-hour timelock sufficient protection? The 48-hour window is a deliberate balance between providing the owner a realistic timeframe to respond to an alert (considering time zones, being offline) and not making the emergency recovery process unduly long for legitimate heirs. Its effectiveness hinges on the owner reliably monitoring the alert email. The system's design acknowledges that absolute, owner-always-prevails security would make recovery impossible if the owner is truly unavailable.