How MPC‑Based Key Management Eliminates Key Leakage Risks

Key management is a core issue in cryptographic applications; any encryption or signing system ultimately faces the question: where do you store your keys?

The article outlines two conventional approaches: (a) local encryption where keys are stored on client‑side media and exposed in memory, and (b) server‑side encryption where keys reside entirely on a server, exposing them to server compromises.

Both methods have inherent risks: client‑side keys can be leaked through memory attacks, and server‑side keys are vulnerable to server breaches or malicious administrators.

To address these risks, a Secure Multi‑Party Computation (MPC) based Key Management System (MPC KMS) is proposed. MPC KMS splits a user's private key into M fragments and stores each fragment on a different server (e.g., different cloud providers). No single server can reconstruct the key, and a threshold of n out of M servers is required to perform cryptographic operations.

Because the key never appears in clear form on any participant, both client‑side and server‑side leakage are mitigated; an attacker would need to compromise at least n independent servers simultaneously.

The decentralized nature of MPC KMS aligns well with blockchain consensus mechanisms, enabling use cases such as threshold‑based cryptocurrency custody or multi‑party software release signing.

Secure Multi‑Party Computation (MPC) Overview

MPC, introduced by Yao in the 1980s, allows multiple parties to jointly compute a function over their private inputs while revealing only the result. It guarantees that no additional information about the inputs is leaked.

Typical applications include privacy‑preserving data analysis, joint risk control, and collaborative recommendation systems.

MPC KMS Architecture and Workflow

The implemented system follows a two‑party ECDSA signing protocol. Two servers, A and B, independently generate random shares a and b; their sum a+b serves as the private key for signing.

When a user requests a signature, the client retrieves share a from server A, sends the message and encrypted data to server B, and the two servers run the secure signing protocol. The private key a+b is never reconstructed in any party’s memory.

Exposed APIs are getPK() for retrieving the public key and sign() for obtaining a signature, both provided via Alibaba’s High‑speed Service Framework (HSF).

Operational steps:

User creates a new key on the KMS; the two servers generate their key shares.

User calls getPK() to obtain the corresponding public key.

User registers a SHA256WithECDSA public key in the system.

User invokes sign() to obtain a signature, which can be verified with the public key.

Even administrators must cooperate across both servers to learn the private key, greatly enhancing security.

The solution has been deployed within Alibaba Group’s internal key management system.

References

Lindell Y. Fast secure two‑party ECDSA signing. CRYPTO 2017.

Doerner J. et al. Secure Two‑party Threshold ECDSA from ECDSA Assumptions. IEEE S&P 2018.

Lindell Y., Nof A. Fast secure multiparty ECDSA with practical distributed key generation. CCS 2018.