Security is the primary foundation of the Crypto Inheritance Platform (CIP). Because real generational assets, estate secrets, and family legacies depend on this protocol, correctness and mathematical security strictly outrank speed.
We maintain a strict Coordinated Vulnerability Disclosure process. We deeply value the contributions of independent security researchers and cryptographers who help audit and secure this protocol.
As an open-source protocol, CIP does not offer monetary rewards. Valid, responsibly disclosed vulnerabilities receive:
- Public Hall of Fame Recognition: Permanent credit in our release notes and GitHub repository acknowledgements (unless the researcher prefers anonymity).
- CVE Attribution: Coordinated CVE assignment crediting the discoverer.
- Direct Engagement: Fast triage and direct coordination with the core engineering team.
Security researchers acting in good faith receive full safe harbor protection:
- We will not pursue civil or criminal legal action against researchers who discover and report vulnerabilities in accordance with this policy.
- Researchers must make a good-faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our services.
- Never test against production user vaults; use local or staged test vaults only.
- In-Scope:
- Cryptographic Engine:
packages/crypto-core - Offline Sovereign CLI:
packages/cli - Protocol & Data Contracts:
packages/protocol - Release-Signer Enclave:
apps/release-signer - Coordination API:
apps/api - Web Dashboard:
apps/web - Docker & Container Infrastructure:
infra/docker/,docker-compose.yml
- Cryptographic Engine:
- Out-of-Scope:
- Volumetric DDoS attacks against hosted endpoints.
- Social engineering or physical attacks against employees or users.
- Vulnerabilities requiring physical access to an unlocked, authenticated client machine.
Do NOT file public GitHub issues for security vulnerabilities.
Report security vulnerabilities via encrypted email or GitHub Security Advisory:
- Email:
security@crypto-inheritance-platform.org - PGP Fingerprint:
4E6F 9025 14D0 C66A 91E5 4D63 F236 7355 AFBA 52D9 - Response SLA:
- Initial acknowledgement: within 24 hours.
- Triage assessment and severity classification: within 72 hours.
- Remediation & release target: < 14 days (or coordinated release date).
Every code contribution must uphold the five architectural invariants established in our Architecture Decision Records:
-
Two-Tier Secret Separation (ADR-0001):
- The web client (
apps/web) and API (apps/api) must NEVER accept, process, transmit, log, or store unencrypted seed phrases, private keys, or raw threshold shares. - Any secret handling must remain strictly in
packages/crypto-coreand the offline CLI (packages/cli). - Linting rules ban imports of
libsodium-wrappers-sumo,@noble/*, and Nodecryptoinapps/webandapps/api.
- The web client (
-
No Invented Cryptography (ADR-0002):
- Vetted primitives only:
XChaCha20-Poly1305(IETF, 24-byte nonce) with authenticated associated data ($AD$ ), Argon2id ($m \ge 32\text{ MiB}, t \ge 3$ ), Verifiable Shamir over$\text{GF}(256)$ with BLAKE2b share commitments, X25519 sealed boxes, and Ed25519 signatures.
- Vetted primitives only:
-
Passkeys Only (ADR-0003):
- FIDO2 resident keys required. Email and SMS are strictly notification transports, never proof of liveness.
-
Isolated Enclave Release with Multi-Clock Verification (ADR-0004):
- Only
apps/release-signer(<1,000 LOC, zero egress) can decrypt escrow share$S$ . - Independent verification of monotonic Ed25519 Merkle event chain and Multi-Clock Roughtime attestations to prevent clock-warp attacks.
- Only
-
Fail-Closed Memory Zeroization:
- Any temporary memory holding plaintext shares or keys must be scrubbed immediately using
sodium.memzero(zeroize).
- Any temporary memory holding plaintext shares or keys must be scrubbed immediately using
- Threat Model Runbook:
docs/THREAT_MODEL_RUNBOOK.md - Independent Audit Checklist:
docs/AUDIT_CHECKLIST.md - Architecture Decision Records:
docs/adrs/