Platform Architecture — private.me Platform

01 — Introduction

Architecture Overview

The private.me platform is built on three foundational primitives: DID-based identity (ML-DSA-65 post-quantum signatures), XorIDA threshold secret sharing (information-theoretic backup), and signed state checkpoints (non-authoritative freshness).

Every ACI (Autonomous Component with Identity) in the platform—from xBind M2M authentication to xPass password management—shares this common foundation. This unified architecture enables 224+ products to work together seamlessly while maintaining zero-knowledge properties.

Unlike traditional platforms that bolt on security features, private.me's architecture makes entire classes of attacks structurally impossible. No shared secrets means no MITM during key exchange. No bearer credentials means no token theft. No centralized key management means no single point of compromise.

02 — Foundation

Core Components

Four architectural primitives enable the entire platform: DID-based identity for authentication, XorIDA for key backup, signed checkpoints for freshness, and gateway coordination for optimization.

DID-Based Identity

Every entity (user, agent, device) has a Decentralized Identifier (did:key) backed by an ML-DSA-65 post-quantum keypair. Authentication is cryptographic proof of private key ownership—no lookup, no server, no oracle.

XorIDA Threshold Sharing

Key backup via information-theoretic threshold secret sharing (k=2, n=3 default). Any 2-of-3 shares reconstruct the key. Single share reveals zero information—not computationally hard, mathematically impossible.

Signed State Checkpoints

Non-authoritative freshness via gateway-signed DID state snapshots. Clients compare local cache against signed checkpoints to detect staleness. Malicious gateways can delay but not forge state.

Gateway Coordination

Optional relay for offline peers, push notifications, and bloom filter optimization. Gateway is non-authoritative—all security properties hold even with malicious gateway. Direct P2P works without gateway.

03 — Security by Architecture

Eliminated Attack Surfaces

Private.me's architecture eliminates five classes of attacks by removing the vulnerable primitives entirely. These aren't mitigations—they're structural impossibilities. What doesn't exist can't be exploited.

✗

Shared Secrets

Traditional Attack: MITM during key exchange, insider access to key database, compromised key escrow server, quantum computers breaking encrypted key exchange.

How We Eliminate: No shared secrets exist. Each agent has asymmetric keypair. Public keys distributed openly (no secrecy required). Private keys never leave device (no transmission = no MITM possible).

Proof: Grep codebase for "sharedSecret" → 0 results. All authentication uses ML-DSA-65 signatures (asymmetric). Protocol specification contains zero symmetric key operations.

✗

Bearer Credentials

Traditional Attack: Token theft (XSS, localStorage leak), session hijacking, credential stuffing, API key leakage in logs, token replay attacks.

How We Eliminate: No tokens/keys that grant access by possession. Every request requires fresh ML-DSA-65 signature with private key. Stolen message cannot be used as authentication (signature tied to original message, nonce prevents replay).

Proof: No JWT/session tokens in protocol. Every message envelope includes unique signature and nonce. Wire protocol spec shows signature verification on every request (see xBind protocol specification).

✗

Key Distribution

Traditional Attack: MITM during key exchange, compromised key server (serves attacker's key), impersonation via key substitution, DNS spoofing to redirect key fetches.

How We Eliminate: Public keys encoded in DID (did:key:z6Mk...). If you know DID, you have public key (deterministic base58 derivation). No key transmission = no MITM. TOFU on first use, checkpoints detect later changes.

Proof: DID specification (did:key method). Public key is base58-encoded in DID string. No key server in architecture. Verification: extract key from DID, no network call required.

✗

Centralized Key Management

Traditional Attack: Compromised key management server (access to all keys), insider threat (admin exports keys), supply chain attack (malicious KMS vendor), government subpoena for bulk key disclosure.

How We Eliminate: No central key server. Agents generate keys locally (deterministic from seed or random). Backup via XorIDA threshold sharing (k-of-n, information-theoretic). Compromise of k-1 shares reveals zero information.

Proof: XorIDA security proof (information-theoretic, not computational). See white paper Section 4.2. Single share indistinguishable from random noise (Shannon secrecy). No key escrow architecture in platform.

✗

Rotation Coordination

Traditional Attack: Desynchronized key rotation (clients use old key after rotation), rotation blocked by offline peers, coordinated rotation requires all-parties-online (availability attack), race conditions during rotation window.

How We Eliminate: DID succession via signed announcement. Old key signs new key (self-authenticating). Peers accept announcement independently (no coordination required). Grace period allows gradual migration. Signed checkpoints detect late arrivals.

Proof: Succession announcement format (see xBind protocol spec). No coordinator required. Offline peers catch up via signed checkpoints. Test: rotate key while peers offline → all peers verify succession signature when they reconnect.

Marketing Claims Backed by Technical Reality

Marketing Claim	Technical Implementation	Verification
Zero key management hassle	Private keys stay on device (never transmitted). Public keys derived from DID (no secure distribution needed). Backup via XorIDA (no key escrow required).	Code audit: No key transmission in protocol. XorIDA tests: 100% coverage. Protocol spec: zero key servers.
Zero shared secrets	Asymmetric cryptography (ML-DSA-65). No pre-shared keys, no symmetric secrets, no key agreement protocol.	Grep codebase: No "sharedSecret" references. All signatures use ML-DSA-65. Protocol spec audit: zero symmetric operations.
Zero bearer credentials	Every request requires fresh signature with private key. No tokens/JWTs. Replay attacks prevented via nonce + timestamp validation.	Wire protocol spec: Signature required per message. Nonce store tests: 100% pass rate. No JWT libraries in dependencies.
Zero key distribution	Public keys encoded in DID (did:key method). Deterministic derivation from DID string. No network calls for key lookup.	DID spec compliance: did:key method verified. No key server in architecture diagram. Extract key from DID: zero network operations.
Zero rotation coordination	Signed DID succession announcements. Old key signs new key. No central authority. Grace period for migration. Checkpoints detect late arrivals.	Succession tests: 100% pass. No coordinator in protocol (direct P2P works). Offline peer tests: all catch up via checkpoints.

04 — Threat Model

Security Model

The platform assumes active network attackers, compromised gateways, and malicious peers. Physical device compromise and side-channel attacks are out of scope (no protocol can protect against compromised execution environment).

In Scope

Active Network Attackers: MITM, replay attacks, message injection, traffic analysis. The protocol prevents tampering (signatures), replay (nonces), and eavesdropping (end-to-end encryption for sensitive payloads).

Compromised Gateways: Malicious coordination servers. Gateway cannot forge messages (no private keys), cannot tamper with messages (signatures detect modification), can delay/drop messages (denial of service, mitigated via direct P2P fallback).

Malicious Peers: Spoofing, impersonation attempts. DID-based identity prevents impersonation (cryptographic proof of private key ownership required). Succession announcements prevent rollback attacks (monotonic sequence numbers).

Out of Scope

Physical Device Compromise: If attacker has code execution on device, they can extract private keys from memory. Mitigation: hardware security modules (HSM), trusted execution environments (TEE), future roadmap item.

Side-Channel Attacks: Timing attacks, power analysis. We use audited libraries (mldsa-wasm) with constant-time operations. Regular dependency audits and CVE monitoring.

05 — Developer Integration

Integration Patterns

All 224 ACIs share the same integration patterns: DID creation, message signing, checkpoint verification, and XorIDA backup. Learn once, use everywhere.

Pattern 1: Agent Initialization

Create a new agent with DID-based identity. The agent generates an ML-DSA-65 keypair and derives a did:key identifier. Optionally back up the private key using XorIDA threshold sharing.

Pattern 2: Message Authentication

Every message includes sender DID, recipient DID, payload, timestamp, nonce, and ML-DSA-65 signature. Recipients verify signature with sender's public key (extracted from sender DID).

Pattern 3: Freshness Verification

Clients maintain local cache of peer DID state. Periodically fetch signed checkpoints from gateway. Compare local cache vs. checkpoint to detect staleness. Refresh if mismatch detected.

Pattern 4: Key Rotation

Agent generates new keypair, creates DID succession announcement (old key signs new key), broadcasts announcement to peers. Grace period allows both keys to be valid during migration.

Built on Identity, Not Credentials