MPC Threshold Signature Protocol

Secubit implements threshold ECDSA signatures using the DKLs23 protocol. Unlike multi-signature wallets where multiple signatures are combined at the blockchain level, threshold schemes produce a single ECDSA signature that is indistinguishable from a standard one. This makes the wallet compatible with any blockchain or application that already supports ECDSA.

In Secubit’s architecture, there are exactly two key shares:

  • HSM key share: generated and stored inside the HSM. This share never leaves the secure boundary in plaintext. It is encrypted and processed exclusively within the HSM.
  • Customer key share: generated on the user machine and immediately encrypted under the user’s PassKey. The encrypted form of this share is stored by the Secubit server. Since the server never has access to the PassKey, it cannot decrypt or misuse this share — only the user, with biometric authentication on their device, can unlock and use it.

To support multiple approvers, the customer share is replicated. Each approver has their own encrypted copy of the customer key share, bound to their personal PassKey. This ensures that authorization remains self-sovereign and distributed, even though Secubit helps coordinate the signing protocol.

Protocol Flow

The sequence diagram below illustrates how a transaction is signed under the DKLs23 protocol:

  1. A transaction request is initiated by the customer system and sent to the Secubit server.
  2. The Secubit server prepares the transaction data and sends the HSM-generated digest along with the HSM’s ephemeral nonce to the customer system.
  3. The customer system passes the digest, nonce, and the user’s encrypted share to the user machine.
  4. The user machine, protected by PassKey, decrypts the customer share, generates its own nonce, and computes the customer signature share.
  5. The customer signature share and nonce are sent back to the server, which forwards them to the HSM along with the original transaction data.
  6. Inside the HSM, the vault verifies the digest, uses its key share, decrypts its encrypted share, and generates the HSM signature share.
  7. The HSM combines its signature share with the customer’s share to produce a complete ECDSA signature.
  8. The final signed transaction is returned to the server, which submits it to the blockchain.
sequenceDiagram
    participant H as 🔑 Secubit HSM
    participant S as Secubit Server
    participant C as Customer System
    participant U as 🔑 User Machine

    activate U
    U->>C: tx_request
    activate C
    C->>S: tx_request
    
    activate S
    S->>S: create tx_data from tx_request
    S->>H: tx_data

    activate H
    H->>H: prepare tx and <br/> create digest
    H->>H: generate nonce_hsm
    H-->>S: digest + <br/> nonce_hsm
    deactivate H

    S->>S: store tx_data in DB
    S->>S: fetch enc_customer_share from DB
    S-->>C: digest + <br/> nonce_hsm + <br/> enc_customer_share
    deactivate S

    C-->>U: digest + <br/> nonce_hsm + <br/> enc_customer_share
    U->>U: nonce_hsm + <br/> nonce_customer
    U->>U: decrypt <br/> enc_customer_share <br/> by PassKey
    U->>U: generate sig_customer
    U->>C: nonce_customer + <br/> sig_customer

    C->>S: nonce_customer + <br/> sig_customer
    activate S
    S->>S: fetch tx_data from DB
    S->>S: fetch enc_hsm_share from DB
    S->>H: tx_data + <br/> nonce_customer + <br/> sig_customer + <br/> enc_hsm_share

    activate H
    H->>H: prepare tx and <br/> create digest
    H->>H: nonce_hsm + <br/> nonce_customer
    H->>H: decrypt <br/> enc_hsm_share
    H->>H: generate sig_hsm
    H->>H: sig_hsm + <br/> sig_customer
    H-->>S: signed_tx
    deactivate H

    S->>S: send signed_tx to network
    S-->>C: ok
    deactivate S

    C-->>U: ok
    deactivate C

    deactivate U

Key Generation and Rotation

Secubit uses a Distributed Key Generation (DKG) process to establish threshold ECDSA keys. In this scheme, the HSM independently generates its own key share within the secure boundary, while the customer share is generated directly on the user machine. At no point does Secubit — or even the HSM — ever see the plaintext customer share. Once generated, the customer share is encrypted under the PassKey public keys of the authorized users, ensuring that each approver can only unlock their own copy with biometric authentication on their device. Thanks to the flexibility of the DKLs23 protocol, Secubit also supports secure key rotation, allowing users to be added or removed by re-distributing customer shares while preserving the same wallet public key. This provides long-term agility without compromising security or requiring funds to be migrated.

Recovery Kit

During the key generation phase, the Secubit HSM receives the user’s PassKey public key and encrypts its own share under that key. The user machine then decrypts the HSM share using PassKey, combines it with the customer share, and reconstructs the full private key of the wallet. This single private key is immediately encrypted with a complex, long password chosen by the customer and stored offline as a recovery kit in an air-gapped environment. After this step, the temporary shares on the user machine are securely erased using zeroization to prevent residual data leakage. The recovery kit is not used in daily operations—customers continue to rely only on their distributed key shares. However, in a disaster recovery scenario, the customer can use the recovery kit to regain complete control over the wallet and funds without depending on Secubit. This mechanism provides a final safeguard and guarantees resistance against censorship or permanent loss of access.

Combined Security Model

Secubit strengthens its threshold signature protocol by combining MPC signing, approver-based authorization, and Merkle tree validation into a unified workflow. Before the HSM decrypts its own key share and produces a partial signature, it first enforces approval verification against the wallet’s Merkle tree. This ensures that each approver or user is not only co-signing the transaction through their customer share, but also simultaneously authorizing the HSM to release its share for signing. In effect, the HSM share remains under customer control, serving primarily to split the private key and mitigate the risk of compromise of the customer share alone. By layering MPC with policy enforcement and Merkle-root–anchored approvals, Secubit delivers a secure self-sovereign non-custodial wallet that resists both insider and external threats while maintaining user ownership of keys.

Security Guarantees

  • Key material never leaves secure boundaries: the HSM independently generates and protects its own share, while the customer share is created on the user machine and encrypted under PassKey. Even the HSM never learns the plaintext customer share.
  • Server compromise is harmless: even if the Secubit server is fully compromised, attackers cannot decrypt user shares or forge signatures, since every share is bound to PassKey authentication and HSM-enforced policies.
  • Multiple approvers supported: each approver holds an independently encrypted copy of the customer share, allowing secure multi-user wallets. Thanks to DKLs23’s support for share rotation, users can be added or removed while preserving the same wallet public key.
  • Policy enforcement with Merkle tree verification: before the HSM decrypts its share or generates a partial signature, it validates approver authorizations against the wallet’s Merkle tree. This means each approver simultaneously approves the HSM’s participation and co-signs the transaction, keeping the HSM share effectively under customer control.
  • Recovery without dependency: through the recovery kit, customers can reconstruct their full private key in an air-gapped environment using their password, ensuring that in extreme scenarios they retain ultimate control over funds without relying on Secubit.