# FIDNT · Security Posture & Supply-Chain Provenance _Last updated: 2026-05-08_ This document records the cryptographic posture, supply-chain provenance, and disclosure protocol for FIDNT (Layer 0 sovereign identity protocol). It is the source of truth audit firms, regulators, and integrating partners should consult. --- ## 1 · Cryptographic posture ### Algorithms in use | Operation | Algorithm | Standard | Source | |---|---|---|---| | Post-quantum signature | ML-DSA-65 | NIST FIPS 204 | `@noble/post-quantum` (vendored) | | Post-quantum key encapsulation | ML-KEM-768 | NIST FIPS 203 | `@noble/post-quantum` (vendored) | | Hash · ledger / receipt anchoring | SHA3-512 | NIST FIPS 202 | `@noble/hashes` / Node `crypto` | | Hash · agent action / mandate envelopes | SHA-256 | NIST FIPS 180-4 | Web Crypto / Node `crypto` | | Symmetric encryption · session | AES-256-GCM | NIST SP 800-38D | Web Crypto API / Node `crypto` | | Key derivation · session | HKDF-SHA-256 | RFC 5869 | Web Crypto API / Node `crypto` | | Classical key agreement (hybrid) | ECDH-P256 | NIST FIPS 186-4 | Web Crypto API / Node `crypto` | | Identifier format | W3C DID v1.0 | W3C REC | original FIDNT implementation | | Consent receipt format | ISO/IEC 27560:2023 | ISO/IEC | original FIDNT implementation | ### Hybrid mode Sessions use **classical (ECDH-P256) + post-quantum (ML-KEM-768)** combined via XOR of derived keys. This belt-and-suspenders posture protects against: - Future cryptanalytic break of ML-KEM (PQ algorithm immaturity) - Cryptographically Relevant Quantum Computer (CRQC) deployment that breaks ECDH If either algorithm is broken, the other still secures the session. This matches NIST's recommended migration approach for high-security deployments (NIST IR 8413). --- ## 2 · Supply-chain provenance ### Vendored libraries (cryptographic and non-cryptographic) Every external code dependency is **vendored** — copied into FIDNT's own origin and served from `https://app.fidnt.com`. **No external CDN runtime call** for any function. | File | Library | Version | License | Anchor | |---|---|---|---|---| | `noble-pqc.js` | `@noble/post-quantum` (Paul Miller) | 0.2.1 | MIT | `instruments/manifest.json::vendored_libs[noble-pqc]` (SHA3-512) | | `lib/emailjs-browser.min.js` | `@emailjs/browser` (EmailJS) | 4.x | BSD-3-Clause | `instruments/manifest.json::vendored_libs[emailjs-browser]` (SHA3-512) | **Verification** — to verify a vendored library has not drifted, compare its on-disk SHA3-512 against the manifest entry: ```bash python -c " import hashlib with open('noble-pqc.js','rb') as f: data = f.read() print(hashlib.sha3_512(data).hexdigest()) " # compare to instruments/manifest.json :: vendored_libs[noble-pqc].sha3_512 ``` The discipline gate (`scripts/check-discipline.mjs::checkVendoredLibs()`) does this automatically on every deploy. **Drift blocks deploy.** ### What FIDNT does NOT depend on at runtime | Category | Status | |---|---| | External CDN for cryptography | ❌ none | | External API for signing / verifying | ❌ none | | External API for hashing / encryption | ❌ none | | External API for identity verification beyond user-initiated PhilSys flow | ❌ none | | External API for consent receipt issuance | ❌ none | | External API for ledger anchoring | ❌ none | | Third-party HSM service (AWS CloudHSM, Azure Dedicated HSM) | ❌ none | | Cloud KMS for FIDNT keys | ❌ none | Every cryptographic operation runs locally — in the user's browser (for client-side keys) or in our serverless functions (for server-side verification only, never holding user keys). ### What FIDNT DOES depend on at runtime | Category | Provider | Why | Risk | |---|---|---|---| | Hosting | Vercel (Hobby plan currently) | App distribution + serverless functions | Vercel could shut down account; mitigation = ability to redeploy to any host (codebase is portable) | | TLS | Vercel-provisioned (Let's Encrypt) | HTTPS for app.fidnt.com | TLS root CAs are an industry-standard dependency | | Browser Web Crypto API | User's browser | AES-256-GCM, HKDF, ECDH | Standard browser primitive — same trust as TLS itself | | QRNG entropy | Web Crypto `getRandomValues` | Key generation | Browser-supplied; no third-party QRNG service called | --- ## 3 · Authoring and signing chain ### Sovereign-root signing Ceremonial documents (Trust Deed, PPSR registrations, charter instruments) and vendored library hash anchors are signed by the **sovereign-root key** held off-platform. This key: - Is never present on FIDNT servers or in repository - Is held by the trustee/operator under a separate sovereignty-protocol custody arrangement - Signs ML-DSA-65 over SHA3-512 hashes via the offline anchor pipeline - Signature appears as `signature_status: "signed"` in `instruments/manifest.json`; `pending-signature` until offline signing completes The deploy pipeline cannot mint sovereign-root signatures. Only the offline operator can. ### User keys User identity keys (passkey + ML-DSA-65 PQC keys) are generated and stored on the user's device, in the secure enclave when available. **FIDNT never has access to user private keys.** Server-side endpoints verify signatures using the user's public key (which the user shares); they cannot sign as the user. --- ## 4 · Disclosure protocol If you discover a security vulnerability, please: 1. **Do not file a public issue.** 2. Email `security@fidnt.com` with: - Affected version (SW_VERSION from `https://app.fidnt.com/sw.js`) - Reproduction steps - Suggested severity (Low / Medium / High / Critical) - Whether you'd like attribution in the disclosure log 3. Expect acknowledgment within 72 hours. 4. Coordinated disclosure window: 90 days unless extended by mutual agreement. For supply-chain reports (e.g. you noticed a vendored library hash drifted from upstream), include the upstream hash and your computed hash for reproducibility. --- ## 5 · Discipline gate (operational guarantees) The disciplined-deployment gate (`scripts/deploy.mjs`) runs on every deploy and refuses to ship if: - Any JS bundle fails `node --check` - Any user-facing HTML contains a forbidden label (off-thesis · SEC-regulated · BSP-trigger · third-party brand) - Any deleted module has residual references in active code paths - Any vendored library's SHA3-512 has drifted from `instruments/manifest.json` - Any HTML page exceeds 500 KB These checks are not advisory. They block production deploys. --- ## 6 · Future hardening on the roadmap | Improvement | Status | |---|---| | Independent third-party audit of FIDNT integration layer (`fidnt-pqc.js`) | not yet engaged | | Signed Software Bill of Materials (SBOM) at every release | considered | | Subresource Integrity (SRI) hashes on all `