Device-to-Device MPC

Peer-to-Peer Multi-Party Computation — No Server Required

1. Protocol Overview

What is Device-to-Device MPC?

In Device-to-Device MPC, two or more smartphones connect directly to each other (peer-to-peer) to perform threshold signing. No central server is required. The phones discover each other, establish a secure session, and run the MPC protocol locally. Each phone holds one key share and uses its own cryptographic processor to sign.

Transport options: Bluetooth Low Energy (BLE), MultipeerConnectivity (iOS), peer-discovery over local WiFi, or relay servers for out-of-range pairing.

TransportRangeLatencySecurity
BLE~30m<50msEncrypted link layer
MultipeerConnectivity (iOS)WiFi/BLE/P2P<100msTLS + peer cert
WiFi Direct (Android)~100m<100msWPA2 Enterprise
QR + RelayInternet200ms+E2E encryption + MAC

2. Discovery and Pairing Flow

Phase 1: Device Discovery
Phone A broadcasts availability
Phone B scans for peers
Phone A appears in list

Both phones advertise themselves on the local network using Bonjour (mDNS) or BLE scanning. Each device shows a friendly name and status indicator.

Phase 2: Pairing Verification
Phone A (Initiator)
  • Generates random nonce N_a
  • Displays 6-digit code (HMAC-SHA256 of N_a)
Phone B (Responder)
  • Generates random nonce N_b
  • Displays 6-digit code (HMAC-SHA256 of N_b)

Both users verify that the codes match on both screens (out-of-band). This prevents man-in-the-middle attacks. Once verified, both phones establish a TLS session authenticated by the shared nonces.

Phase 3: Session Establishment
Phone A ← TLS handshake → Phone B Cipher: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 Session timeout: 30 minutes Perfect forward secrecy: Yes Peer certificate verification: HMAC(N_a, N_b)

Both phones now have a secure, encrypted, and authenticated channel. They can send messages without eavesdropping or tampering.

3. Remote Key Generation

2-Party ECDSA KeyGen
Phone A: Generate share x_0
Phone B: Generate share x_1
Exchange commitments
Agree on public key Q
Store locally on device

Round 1 (Commitment): Each phone generates a random key share and a commitment hash. The commitments are exchanged and verified against received messages.

Round 2 (Key Derivation): Both phones derive the same public key Q = (x_0 + x_1)*G and verify it matches.

Round 3 (Storage): Each phone stores its share in the Secure Enclave (iOS) or StrongBox (Android) — a hardware-backed keystore that prevents extraction.

Zero-Knowledge Proofs
During KeyGen, both phones prove knowledge of their shares using zero-knowledge proofs (Schnorr's protocol). This ensures correctness without revealing the share values.

4. Collaborative Signing

MPC Signing Protocol
User initiates sign request
Message hash is broadcast
Phone A & B run 3-round MPC
Signature completed on one phone

Round 1 (Nonce Generation): Each phone generates a random nonce k_i and broadcasts a commitment to it.

Round 2 (Partial Signatures): Each phone computes a partial signature component and sends it to the other. The partial components are combined.

Round 3 (Final Signature): One phone (designated by access policy) receives the final signature (r, s) and stores it.

Signature message flow: Phone A: commit(k_0), share(msg_1) Phone B: commit(k_1), share(msg_2) Phone A: open nonces, receive (r, s) Result: Standard ECDSA signature (67-71 bytes)
Mobile Experience

5. iOS App — Device-to-Device Flow

5.1 Discovery and Pairing

Find Peers
Nearby Devices
Alice's iPhone
Ready
Bob's iPad
Available
Carol's iPhone
Offline
Peers List
Verify Peer
🔐

Confirm this code appears on both devices:

3 8 5 7 2 1
Verify

5.2 Key Generation

KeyGen in Progress
Round 1: Generate shares
Round 2: Exchange commitments
Round 3: Verify public key
Connected to Alice's iPhone

Generating 256-bit key on secp256k1...

KeyGen
Key Generated ✓
Your Key Share
x₀ (stored in Secure Enclave)
Public Key (Shared)
02 8a7f9e2c...
Complete

5.3 Collaborative Signing

Sign Request
Message Hash
5a7f8d...
Purpose
Approve transaction
Requesting Party
Alice's iPhone
Sign
Signing...
Round 1: Generate nonce
Round 2: Compute partial sig
Round 3: Final signature
Connected to peer

Processing MPC protocol...

Progress
Signature Ready
Signature (DER)
30 45 02 20 8a7f...
Verification
Valid on secp256k1
Done

6. Device-to-Device vs. Server-Based MPC

Comparison
Aspect Device-to-Device Server-Based MPC
Infrastructure Peer-to-peer (no server) Client + Server
Latency Low (BLE/WiFi direct) Higher (network round-trip)
Availability Requires both devices online Server always available
Privacy No intermediary Server sees message hashes
Scalability Good for 2-3 parties Better for N parties
Use Case Peer cosigners, family vaults Mobile wallet with commitment server
When to Use Device-to-Device

Best for: Two family members approving transactions together, co-signer scenarios where both parties must physically be present, peer-to-peer commerce apps.

Not ideal for: Large thresholds (3+), always-available signing (if one device is offline, signing fails), enterprise deployments.