STIGNING

Teknisk artikkel

Custody-arkitektur i distribuerte finansielle systemer: Terskelkryptografi, MPC og feilinneslutning

En teknisk analyse av distribuerte custody-systemer med terskelkryptografi, bysantinske adversarmodeller og signeringsprotokoller som er crash-sikre.

17. feb. 2026 · Fintech-kryptografi · 15 min

Publikasjon

Artikkel

Tilbake til bloggarkivet

Artikkelbrief

Kontekst

Programmer innen Fintech-kryptografi krever eksplisitte kontrollgrenser pa tvers av fintech, cryptography, distributed-systems under adversariell og degradert drift.

Forutsetninger

  • Arkitekturbaseline og grensekart for Fintech-kryptografi.
  • Definerte feilforutsetninger og eierskap for hendelsesrespons.
  • Observerbare kontrollpunkter for verifikasjon i deploy og runtime.

Når dette gjelder

  • Nar fintech-kryptografi direkte pavirker autorisasjon eller tjenestekontinuitet.
  • Nar kompromittering av en enkelt komponent ikke er en akseptabel feilmodus.
  • Nar arkitekturbeslutninger ma underbygges med evidens for revisjon og operasjonell assurance.

Sammendrag

In distributed financial systems, custody architecture defines the boundary of asset authority. While ledger systems preserve transactional invariants and ensure conservation of value, custody systems determine which entities are cryptographically capable of producing valid asset transfers. A failure in ledger logic may result in reconciliation complexity; a failure in custody design results in irreversible loss.

This article presents a technical and architectural analysis of custody systems built on threshold cryptography and Multi-Party Computation (MPC), focusing on formal security properties, Byzantine adversary assumptions, distributed signing protocols, crash safety, correlated failure domains, and practical implementations using FROST-based threshold signatures.

Custody is not key storage. It is adversarial distributed systems engineering.

From Centralized Keys to Distributed Authority

Let KK be a private signing key used to authorize asset transfers in an elliptic curve system such as ECDSA or Ed25519.

In a centralized model:

σ=Sign(K,m)\sigma = \operatorname{Sign}(K, m)

Where:

  • mm is the transaction message.
  • σ\sigma is a valid signature.

Security reduces entirely to the secrecy of KK.

If an attacker extracts KK, control over assets is permanently lost. Because blockchain-based transfers are irreversible, there is no rollback mechanism capable of undoing a malicious signature.

Distributed systems engineering operates under a different assumption: compromise is eventual.

Therefore, custody must satisfy:

Compromise of any single nodeCompromise of signing authority\text{Compromise of any single node} \ne \text{Compromise of signing authority}

This transforms custody from secret storage into distributed trust enforcement. In this model, the centralized baseline in Eq. (1) is intentionally replaced by the distributed authority condition in Eq. (2).

Threshold Cryptography and Secret Fragmentation

Instead of storing private key scalar xx directly, we distribute it using Shamir Secret Sharing.

Private key scalar: xZq\text{Private key scalar: } x \in \mathbb{Z}_q

Construct polynomial ff of degree (t1)(t-1) such that:

x=f(0)x = f(0)

Each participant ii receives:

xi=f(i)x_i = f(i)

No individual share reveals xx.

A threshold tt-of-nn system ensures:

  • Any subset of size tt can collaboratively produce a valid signature.
  • Any subset of size less than tt cannot reconstruct xx nor produce σ\sigma.

Security condition:

Number of compromised shares<t\text{Number of compromised shares} < t

Threshold selection encodes tradeoffs directly into system design.

Lower tt improves availability but weakens compromise resistance. Higher tt strengthens security but increases operational fragility.

This is risk modeling expressed mathematically.

Formal Adversary Model (Byzantine)

Assume a Byzantine adversary capable of:

  • Arbitrary message manipulation.
  • Adaptive node compromise.
  • Network delay and reordering.
  • Collusion among compromised nodes.

Let:

f=number of Byzantine nodesf = \text{number of Byzantine nodes}

Security condition:

f<tf < t

If ftf \ge t, signing authority is compromised.

Additionally, the signing protocol must ensure:

  • Robustness under up to (t1)(t-1) malicious nodes.
  • Unforgeability under partial compromise.
  • Bias-resistance in nonce generation.

Custody becomes a Byzantine fault-tolerant distributed protocol layered over cryptographic primitives.

The Signing Protocol as a Distributed State Machine

Distributed signing is interactive.

Each participant generates ephemeral nonce shares and contributes to a coordinated signing round.

Conceptually:

  1. Nonce-forpliktelser utvekslet.
  2. Aggregert nonce beregnet.
  3. Partielle signaturer produsert.
  4. Signaturandeler aggregert.

Final signature:

σ=(R,s)\sigma = (R, s)

The protocol must satisfy:

  • Concurrency safety.
  • Replay protection.
  • Crash atomicity.
  • Idempotency.

The signing protocol itself becomes a distributed state machine.

FROST: Efficient Threshold Schnorr Signatures

Modern custody systems frequently adopt Schnorr-based threshold schemes due to efficiency and simplicity.

FROST (Flexible Round-Optimized Schnorr Threshold Signatures) provides:

  • Two-round signing protocol.
  • Communication-efficient nonce commitment.
  • Bias-resistant nonce generation.
  • Provable security under discrete logarithm assumptions.

In Schnorr systems:

Y=xGY = xG

Verification condition:

sG=R+H(R,Y,m)YsG = R + H(R, Y, m)Y

Operational verification should remain traceable to Eq. (10) and Eq. (11) during runtime validation and incident review.

FROST produces signatures indistinguishable from centralized Schnorr signatures, ensuring blockchain compatibility.

Practical Example: frost-ed25519 (Rust)

Below is a simplified illustration using a FROST-compatible Rust library.

use frost_ed25519 as frost;
use rand::thread_rng;

fn threshold_sign(message: &[u8]) -> Result<frost::Signature, frost::Error> {
    let mut rng = thread_rng();

    let key_package = load_key_package();
    let pubkey_package = load_public_package();

    let (nonces, commitments) =
        frost::round1::commit(key_package.signing_share(), &mut rng);

    broadcast_commitments(commitments);

    let signing_package =
        frost::SigningPackage::new(commitments, message);

    let signature_share =
        frost::round2::sign(&signing_package, &nonces, &key_package)?;

    collect_signature_share(signature_share);

    let signature =
        frost::aggregate(&signing_package, collected_signature_shares, &pubkey_package)?;

    Ok(signature)
}

No full private key reconstruction occurs. Each node holds only its share. Final signature remains standard Ed25519-compatible.

Crash Safety and Atomic Signing

Consider node crash during signing round.

System must guarantee:

Incomplete signing roundNo valid signature produced\text{Incomplete signing round} \Rightarrow \text{No valid signature produced}

Intermediate nonce values must be ephemeral. Partial signatures must not be durable in reconstructible form. Retry must not reduce threshold requirement.

Custody must be crash-consistent by design.

Concurrency and Replay Safety

Custody must coordinate with ledger state.

Example validation:

fn validate_before_sign(tx: &Transaction, ledger: &Ledger) -> Result<(), Error> {
    if ledger.nonce_used(tx.account, tx.nonce) {
        return Err(Error::ReplayDetected);
    }

    if !ledger.balance_sufficient(tx.account, tx.amount) {
        return Err(Error::InsufficientFunds);
    }

    Ok(())
}

Ledger preserves value invariants:

entries(T)=0\sum \text{entries}(T) = 0

In practice, custody pipelines should validate this ledger invariant against Eq. (13) before issuing final signature broadcast.

Custody preserves authorization boundaries. Security is compositional.

Correlated Failure Domains

Threshold cryptography assumes independent shares. Operational correlation invalidates this assumption.

If shares reside in:

  • Same cloud account.
  • Same IAM boundary.
  • Same CI/CD pipeline.
  • Same secrets manager.

Compromise may become correlated.

Security principle:

Operational independenceCryptographic independence\text{Operational independence} \ge \text{Cryptographic independence}

Infrastructure separation, access isolation, and deployment segregation are mandatory.

Conceptual Signing Architecture

The custody signing flow can be visualized as:

                    +----------------------+
                    |  Transaction Proposal |
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    |   Ledger Validation  |
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    |      Risk Engine      |
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    |  Custody Coordinator  |
                    +----+--------+--------+
                         |        |        |
                         v        v        v
                    +--------+ +--------+ +--------+
                    | Node 1 | | Node 2 | | Node 3 |
                    | Share  | | Share  | | Share  |
                    +----+---+ +----+---+ +----+---+
                         \        |        /
                          \       |       /
                           \      |      /
                            v     v     v
                      +----------------------+
                      | Signature Aggregation |
                      +----------+-----------+
                                 |
                                 v
                      +----------------------+
                      | Broadcast Transaction |
                      +----------------------+

Ledger validation precedes custody signing. Risk policy constrains signing eligibility. Custody nodes collaboratively produce final signature.

Konklusjon

Threshold cryptography transforms custody from centralized secret storage into distributed authority enforcement. FROST-based schemes provide efficient, bias-resistant threshold Schnorr signatures suitable for modern blockchain ecosystems. However, cryptographic guarantees alone are insufficient.

Custody must be analyzed under Byzantine adversary assumptions, implemented with crash-consistent protocols, and deployed across operationally independent failure domains. Ledger correctness preserves value invariants. Custody architecture preserves authority boundaries.

In distributed financial systems, control and correctness are inseparable. Without distributed custody, any system is ultimately controlled by whoever controls a single key.

Custody is where mathematics meets adversarial distributed systems engineering.

Referanser

Del artikkel

LinkedInXE-post

Artikkelnavigasjon

Relaterte artikler

Fintech-kryptografi

Custody-myndighet i distribuerte finansielle systemer: Hendelsesrekonstituering under delvis feil

En formell engineeringanalyse av fintech-kryptografi med vekt på hendelsesrekonstituering under delvis feil og adversarielle operative begrensninger.

Les relatert artikkel

Fintech-kryptografi

Custody-myndighet i distribuerte finansielle systemer: Revisjonsspor og verifiserbare operasjoner

En formell engineeringanalyse av fintech-kryptografi med vekt på revisjonsspor og verifiserbare operasjoner og adversarielle operative begrensninger.

Les relatert artikkel

Fintech-kryptografi

Custody-myndighet i distribuerte finansielle systemer: Migreringssekvensering for systemer med høy assurance

En formell engineeringanalyse av fintech-kryptografi med vekt på migreringssekvensering for systemer med høy assurance og adversarielle operative begrensninger.

Les relatert artikkel

Fintech-kryptografi

Custody-myndighet i distribuerte finansielle systemer: Forutsetninger for bysantinsk kompromittering og gjenopprettingsbaner

En formell engineeringanalyse av fintech-kryptografi med vekt på forutsetninger for bysantinsk kompromittering og gjenopprettingsbaner og adversarielle operative begrensninger.

Les relatert artikkel

Tilbakemelding

Var denne artikkelen nyttig?

Teknisk Intake

Bruk dette mønsteret i ditt miljø med arkitekturgjennomgang, implementeringsbegrensninger og assurance-kriterier tilpasset din systemklasse.

Bruk dette mønsteret -> Teknisk Intake