Contents
PRC Wallet logo

Security Architecture

Technical documentation on wallet key derivation (BIP-39/32/44), AES-256-GCM encrypted keystore, local signing (secp256k1), nonce management, and multi-chain security architecture. See /security/audits, /security/responsible-disclosure, /download, /status, and /networks for related resources.

Self-Custody Principle

PRC never has your keys. All key material is generated and kept on your device and is never sent to our servers.

Last updated: 2024-12-15•~8 min read•Contact: [email protected]•PGP on Responsible Disclosure

1. Overview

Data Flow

  1. Generate
  2. Derive
  3. Encrypt & Store
  4. Unlock
  5. Sign
  6. Broadcast

Generate: CSPRNG (WebCrypto getRandomValues) creates raw entropy → BIP-39 mnemonic (12/24 words).

Derive: BIP-32/44 HD wallet from mnemonic seed; SLIP-0044 coin types per chain.

Encrypt & Store (local): Seed (or master key) encrypted client-side and stored locally.

Unlock: User passcode/OS biometrics derives a session key to decrypt in memory.

Sign (local): Transactions built and displayed in human-readable form → user approves → signed locally (curve per chain).

Broadcast: Raw signed tx is sent to the selected RPC; no private data leaves the device.

2. Key Generation & Derivation

Standards

  • Mnemonic: BIP-39 (English wordlist), 128/256-bit entropy
  • HD tree: BIP-32 (HMAC-SHA512)
  • Paths: BIP-44 per coin type; SLIP-0044 for registered coin types
  • Cross-wallet recovery: Use same coin type and derivation path

Any wallet implementing BIP-39/32/44 with the same coin type and path can recreate PRC addresses from your seed (plus passphrase if you used one).

Passphrase (Optional)

An optional BIP-39 passphrase derives a different wallet from the same mnemonic. If you used a passphrase, you must supply it at recovery time to see the same addresses.

3. Local Encryption & Storage

At Rest (Device)

  • Encryption: AES-256-GCM via WebCrypto
  • KDF for user passcode → encryption key: PBKDF2-SHA256 with high iteration count (310k+) and 16-byte random salt
  • Nonces/IVs: 96-bit random IV per encryption operation; GCM tag stored alongside ciphertext
  • Storage: IndexedDB (preferred) or secure storage; never store raw seeds/keys unencrypted
Keystore record (JSON)
{
  "algo": "AES-256-GCM",
  "kdf": "PBKDF2-SHA256",
  "iter": 310000,
  "salt": "<base64>",
  "iv": "<base64>",
  "ct": "<base64>",
  "tag": "<base64>",
  "createdAt": "..."
}

In Memory

  • Decrypt only after explicit user unlock
  • Zeroize sensitive buffers after use; avoid logging
  • Never weaken crypto settings; prefer constant-time libs

OS / Biometric Unlock (Roadmap)

WebAuthn/Passkeys can wrap the local encryption key to permit biometric unlock without exposing raw key material (planned—document when live).

4. Signing Flow

EVM-style Chains

Build: App or dApp forms a transaction (to, value, data, gas, chainId, nonce)

Human-readable preview: Show recipient, token, amount, fees, and risk cues (domain, chain, contract)

User approval: Explicit confirm

Sign (local): secp256k1 (ECDSA) using derived account key; signature never leaves device except as part of the raw tx

Broadcast: Submit raw tx to selected RPC; receive hash

Non-EVM Chains

Use chain-specific curves/encodings (see /networks). Same rule: sign locally, broadcast raw.

Nonce Management (EVM)

  • Query getTransactionCount(address, "pending")
  • Maintain a local pending-nonce queue per account to avoid collisions
  • Speed up: re-submit same nonce with higher gas
  • Cancel: 0-value tx to self with the conflicting nonce at higher gas

dApp Connections

  • WalletConnect v2 or equivalent session protocol
  • Per-site permissions with revocation UI (Settings → Connections); domain binding to reduce phishing risk

5. Multi-Chain Architecture

  • Per-chain providers: independent RPC endpoints and chain IDs; no cross-leakage of nonces or caches
  • SLIP-0044 coin type: derivation aligns with each chain's registered coin type
  • Address formats & checksums: follow chain norms (e.g., EIP-55 checksum for Ethereum-style addresses)
  • Explorers: link to official or reputable explorers per chain; never embed untrusted iframes

6. Network, Runtime & Isolation Controls

  • Runtime: signing happens in a privileged context with no third-party scripts
  • CSP: strict Content Security Policy; Subresource Integrity (SRI) for static assets; forbid unsafe-inline
  • Storage partitioning: no cross-origin access to keystore
  • Telemetry: off by default or opt-in; never includes seeds, keys, addresses, balances, or full tx data
  • Supply chain: dependency pinning with lockfile verification; SRI for third-party assets; provenance when available

7. Threat Model

What We Protect Against

  • Compromised RPC responses (display mismatch warnings)
  • Phishing / malicious approvals (domain binding, clear prompts, easy revoke)
  • Storage compromise (AES-256-GCM at rest; KDF-strengthened key)
  • Accidental user error (human-readable previews, network badges, test-send tips)

Out of Scope

  • A fully compromised device (malware/keylogger)
  • Social engineering that convinces users to reveal seeds/passphrases
  • Side-channel attacks outside the browser's threat model

8. Verification & Reproducibility

  • Checksums & signatures: publish SHA-256 hashes and PGP signatures for downloads (and build commit for web). See /download.
  • Reproducible builds: status: beta. Users can verify hashes, PGP signatures, and the source commit today.
  • Status / incidents: transparent uptime and incident notes on /status.

9. Audits & Reviews

Independent assessments: We commission third-party security reviews and publish reports (firm, scope, date, version) on /security/audits.

Responsible disclosure: [email protected] with PGP; acknowledge within 48h; safe-harbor policy on the disclosure page.

10. Hardware Wallets

Integration Status

Hardware wallet integration planned for a future release.

Key custody: private keys stay on the device; PRC derives addresses via the HW derivation path

Flow: PRC constructs tx → sends to device → on-device confirmation → device returns signature → PRC broadcasts

Limitations: message formats vary; ensure the device supports the target chain & method (EIP-1559, typed data, etc.)

Security benefit: keys never exist in browser memory

11. Privacy & Data

  • No tracking of balances or addresses
  • Minimal opt-in analytics (aggregated only)
  • GDPR-aligned: data retention and rights documented in /legal/privacy

12. Implementation Notes

Standards: BIP-39, BIP-32, BIP-44, SLIP-0044 (coin types), EIP-55 checksums (EVM)

Crypto primitives: HMAC-SHA512 (BIP-32), PBKDF2-SHA256 (local KDF), AES-256-GCM (at rest), secp256k1 ECDSA (EVM)

Storage: IndexedDB; never plaintext keys at rest

Keystore policy: auto-lock after 5 minutes idle (foreground) / 15 minutes (background). Keys are zeroized from memory on lock.

Never: send mnemonics/keys to servers, embed third-party scripts in signing context, or auto-approve dApp permissions

dApp revocation: revoke approvals in-app via Settings → Connections.

13. FAQ

Do you ever see my seed or private key?

No. Keys are generated, encrypted, and used only on your device.

Can you recover my wallet if I forget my seed or passphrase?

No. That's the nature of self-custody. Back up securely and test a recovery.

Why do I see a different address after import?

Derivation path or passphrase mismatch. Ensure the same coin type/path and the exact passphrase you used originally.

How do you handle nonces when I have pending txs?

We track pending nonces per account and expose speed-up/cancel actions.

Do you support passkeys/biometric unlock?

Planned via WebAuthn-wrapped local keys. We'll document when live.

14. Contact & Disclosure

Security Contact

Email: [email protected]

Report vulnerability: see disclosure page

Audits: published at /security/audits

Chain-Specific Details

See /networks for: coin type/path, address format, fee model, signature scheme, explorers, and known quirks per chain.