Commitment Server Topology — Client + Server 2-Party MPC
In a Server-based MPC topology, a mobile client (Party 0) and a commitment server (Party 1) jointly generate and sign keys. The client holds its share in the Secure Enclave; the server holds its share in a HSM (Hardware Security Module) or KMS. All cryptographic operations happen collaboratively over an encrypted WebSocket connection.
Key advantage: The server is always available. If the client is offline, the signature request waits. When the client comes back online, it can immediately sign without re-running key generation.
| Component | Location | Storage | Role |
|---|---|---|---|
| Client | Mobile device | Secure Enclave | Party 0 — initiates signing |
| Server | Cloud (AWS, GCP, etc.) | HSM or KMS | Party 1 — co-signs requests |
| Channel | Internet | TLS 1.3 | Encrypted transport |
Session Management: Each KeyGen starts a new WebSocket session with a unique session ID. Sessions timeout after 5 minutes of inactivity and require re-authentication via JWT.
Storage: After KeyGen completes, the client stores x_0 in Secure Enclave (non-exportable). The server stores x_1 in its HSM.
Round 1 (Setup): Client sends message hash and nonce commitment. Server generates its nonce and commits.
Round 2 (Compute): Both parties compute partial signature components in parallel. Client and server exchange partial signatures.
Round 3 (Final): Client combines the partial signatures into the final ECDSA signature (r, s).
| Endpoint | Method | Purpose | Auth |
|---|---|---|---|
/keygen |
POST | Initiate 2PC key generation | JWT token |
/sign |
POST | Initiate collaborative signing | JWT token |
/refresh |
POST | Rotate key shares (forward security) | JWT token |
/status |
GET | Server health & version | None |
/pubkey |
GET | Retrieve public key (after keygen) | JWT token |
WebSocket: All MPC protocols (KeyGen, Sign, Refresh) use WebSocket for bidirectional real-time communication. Upgrade from HTTP with: GET /ws?session_id=sess_xyz789
Generating key with commitment server...
Running 3-round MPC...
| Aspect | Server (2PC) | Device-to-Device | Single Device |
|---|---|---|---|
| Availability | Server always available | Both devices must be online | Single point of failure |
| Latency | 100-500ms (network) | 50-100ms (BLE) | <10ms (local) |
| Security Model | Threshold: compromise server or client (either alone) | Threshold: compromise both devices | Full key in one place |
| Scalability | Excellent (many clients per server) | Poor (limited to 2-3 peers) | N/A (single party) |
| Backup & Recovery | Supported via PVE | Manual coordination | User is responsible |
| Use Case | Mobile wallet, institutional | Peer cosigners | Custodial |
Server Compromise: If the server's HSM is compromised, attackers can sign arbitrary transactions. Mitigate with: rate limiting, transaction validation, and signing policies.
Client Compromise: If the Secure Enclave is broken, attackers can extract the key share. Mitigate with: key refresh (rotate shares), TLS pinning, and device attestation.
Combined Attack: If both are compromised simultaneously, the full key is exposed. This is the threshold property: threshold = 1 share leakage tolerance.