Skip to main content

FPSF-MPC-001 — Core Concepts

Layer: Core Concepts · Audience: developers, security architects For normative requirements, see the Formal Specification.

The Three Key Classes​

Understanding the system requires first understanding that it deliberately separates three different keys with three different roles and three different security models. Confusing them leads to incorrect implementations.

Root Key. This key never leaves the user's control and never touches the network. Its sole job is to sign Authorization Tokens that certify sub keys. Because it is offline, compromising the MPC system does not expose it. If a sub key is compromised, the user generates a new one using the root key — without the root key being at risk.

Sub Key. This key is online and is the credential the user presents to the API. It signs every request. Because it is separate from the root key, a compromised sub key is recoverable — the root key generates a new authorization token for a new sub key.

Disposable Key. This key's private scalar is never assembled. It exists only as shares across a group of MPC nodes. Its public key is returned to the user, who can use it as a verifiable identity for a single use case — typically a single bearer instrument — and then destroy it.

The three-class design means that the system has multiple independent lines of defense. Compromising the API layer does not expose the root key. Compromising a single node does not expose the disposable key's private scalar. Compromising the coordinator does not expose key material at all.

Threshold Cryptography: Why Shares Are Secure​

A threshold signature scheme with parameters (t, n) distributes a secret across n shares such that any t shares are sufficient to reconstruct or use the secret, but any t-1 shares reveal absolutely nothing about it. This is a mathematical guarantee, not a security policy.

In the context of FPSF-MPC-001, "using the secret" means signing a message. No reconstruction of the full private key is necessary — the FROST protocol allows nodes to collaboratively produce a valid signature without any party ever holding the assembled key.

The practical implication is that an attacker must compromise at least t nodes simultaneously. For a (3, 5) configuration, this means compromising 3 of 5 nodes. The system is designed to make this difficult: nodes are selected randomly via a Verifiable Random Function, they do not know each other's identities across groups, and they are distributed across independent operators.

Distributed Key Generation​

Pedersen DKG is the protocol by which the group creates the key pair. The core idea is that each node generates its own random polynomial, publishes commitments to the coefficients, and exchanges encrypted shares of its polynomial's evaluations with every other node.

At the end of the protocol, each node holds a share that is consistent with a global key pair — but no node has enough information to compute the private key. The public key, however, is fully determined and can be computed by all participants. This is the public key returned to the user.

The protocol is designed so that even a fully adversarial minority (up to t-1 malicious nodes) cannot bias the output key or learn anything about the private key shares of honest nodes.

FROST Signing​

FROST (Flexible Round-Optimized Schnorr Threshold Signatures) is the protocol used to sign messages. It runs in two rounds:

In Round 1, each participating signer generates a nonce pair and publishes commitments to those nonces. This happens before the message is known to the signers, making the protocol resistant to certain attacks that target nonce reuse.

In Round 2, the coordinator broadcasts the message and the collected commitments. Each signer computes a partial signature using their share and their nonces. The coordinator aggregates the partial signatures into a complete, standard Ed25519 Schnorr signature.

The critical property: the output signature is indistinguishable from one produced by a standard Ed25519 private key. Verifiers do not need to know FROST was involved.

Anti-Collusion: Why Nodes Cannot Coordinate​

The group formation protocol uses a Verifiable Random Function to select which nodes form each group. The VRF takes the coordinator's private key and a job-specific seed as inputs, producing a pseudorandom output with a verifiable proof. The proof is published to the audit log, so any observer can verify the selection was correct after the fact — but no one could predict it before.

During the DKG and signing protocols, nodes communicate only through the coordinator, using session-scoped opaque handles. A node assigned to a group for Key A does not know which nodes were in the group for Key B. This prevents nodes from building long-term collusion relationships by identifying repeated co-participants.

The Role of the Coordinator​

The coordinator is the central orchestration component. It is trusted to orchestrate fairly, but it is explicitly designed to be unable to compromise key security:

  • It relays inter-node messages but cannot decrypt them (share payloads are encrypted point-to-point between nodes).
  • It assembles partial signatures but does not thereby learn the private key.
  • It controls group formation but cannot predict which groups will be selected (VRF constraint).
  • It stores key metadata but not key shares.

A compromised coordinator is a denial-of-service risk and a potential group-biasing risk (detectable via audit log). It is not a key material exfiltration risk.

FPSF-MPC-001 v1.0.0 · Draft · Fabric Payment Standards Foundation · Apache-2.0