Key Derivation (KDF)

Key Derivation Model

This guide explains how IBEx links a Passkey Signer to a Safe Smart Contract Wallet, and how additional wallets (EVM EOA, Solana, Bitcoin) are deterministically derived.

Architecture Overview

Passkey Signer (device secure enclave)
    ├── WebAuthn credential (rawId, x, y)
    │   └── Safe Smart Contract Wallet (per chain)
    └── PRF / Sealed Master (32 bytes)
        ├── EVM EOA (HKDF → secp256k1)
        ├── Solana   (HKDF → Ed25519)
        └── Bitcoin  (HKDF → P2WPKH / P2TR)

Passkey → Safe Wallet

The X/Y coordinates of the P-256 public key (stored in Signer.data.safe.signer.coordinates) are used to deterministically compute the Safe address:

1. Passkey → WebAuthn signer identity — rawId + (x, y) public key coordinates
2. Signer identity → Safe owner — The SafeWebAuthnSignerFactory deterministically deploys a signer contract from (rawId, x, y)
3. Safe owner → Safe address — Computed from the factory/proxy setup + owner, even before on-chain deployment (counterfactual)

No private key on the server. The Safe is a smart contract wallet. Authorization is done via WebAuthn signatures generated inside the authenticator's secure enclave.

Deriving EOA / Solana / Bitcoin

Derived wallets use a master derivation value associated with the same Signer, not from the Safe address itself.

Master Key Acquisition

Option 1 — PRF (preferred): The WebAuthn PRF extension returns deterministic bytes from the authenticator, using a tenant-scoped salt:

salt = SHA-256("ibexfi:prf:v1:master|rpId:<effectiveRpId>")

Option 2 — Sealed fallback: If PRF is unavailable, the backend generates 32 random bytes and stores them encrypted (AES-256-GCM) in Signer.data.derivation.sealedMaster.

HKDF Derivations

All derived wallets use HKDF-SHA256 with salt "ibexfi:derivation:v1":

Security Model

Protected by Design (Passkeys)

• Passkey private keys are non-exportable from the authenticator
• The server cannot reconstruct passkey private keys from stored data

Server-Side Secrets (Sealed Master)

When PRF is unavailable, security depends on:

• DERIVATION_SECRET / DERIVATION_SALT environment variables
• These should be stored in a KMS, not in plaintext env files

Recommendations

• Enforce required env vars — fail startup if derivation secrets are missing
• Prefer PRF-only mode where feasible
• Never log PRF outputs, unsealed master, or derived private keys
• Sign client-side for Bitcoin/Solana (server only prepares/relays)