Skip to content

Threat model

Component: tss4j (cryptographic protocols used by TKeeper)

This document describes the security goals, assets, threat assumptions, attack surfaces, mitigations, and residual risks for the tss4j protocol library used by TKeeper.

Scope

In scope:

  • GG20 ECDSA (secp256k1), including:
  • Paillier MtA (multiplicative-to-additive) protocol
  • ZK proofs, validators, MtAProtocol, ZKSetup
  • FROST Schnorr, including:
  • Preprocessor (commitment generation / PoP)
  • Partial signer and aggregator
  • Transcript hashing and domain separation
  • Encoding / RNG
  • TLV encoding (Bytes.encode)
  • ZKRandom (strong secure random source)

Out of scope:

  • Compromise of ≥ t parties (collusion or takeover) as a confidentiality / unforgeability break (this is the threshold model limit).
  • Physical side channels beyond timing (EM/power analysis, invasive attacks).
  • Host hardening, OS/container isolation, and operational controls outside the library boundary.

System overview

tss4j implements threshold signing based on:

  • GG20: multi-round threshold ECDSA for secp256k1 using Paillier encryption and MtA, protected by ZK proofs.
  • FROST: threshold Schnorr signing for Ed25519 and secp256k1 with preprocessing commitments, transcript hashing, and proof-of-possession (PoP) protections.

All protocol messages, commitments, and contexts are bound into transcripts using deterministic hashing with domain separation. All hashed inputs are TLV-encoded to avoid ad-hoc concatenation and ambiguity.

Security objectives

The library aims to provide the following properties when the threshold assumptions hold:

  • Key secrecy: an attacker controlling fewer than t parties cannot reconstruct the private key or usable signing capability.
  • Unforgeability: an attacker controlling fewer than t parties cannot produce valid signatures without participation of honest parties.
  • Protocol robustness: malformed inputs and malicious participants should be detected and rejected.
  • Replay resistance / context binding: messages and proofs must be bound to the correct session and operation context.
  • Implementation hardening: operations on secret material should avoid data-dependent timing where possible; one-time secrets must not be reused.

Assets

Primary assets protected by the library:

GG20 / Paillier assets

  • Paillier private key (λ, μ, p, q)
  • Paillier public modulus N
  • Paillier randomness r (per-encryption)

Threshold key material

  • Secret shares sk_i
  • One-time nonces d_i, e_i, and per-session randomness (including PoP nonce r)
  • Session transcripts (commitments, contexts, AAD)

Public parameters

  • Group public keys
  • Paillier modulus N

Threat actors and capabilities

Assume an adversary can:

  • Control the network: intercept, replay, reorder, and modify protocol messages.
  • Act as a malicious participant: send malformed or adversarially chosen protocol values.
  • Exploit implementation issues: parsing ambiguities, nonce reuse, weak randomness, or unsafe arithmetic.
  • Compromise a subset of parties < t and extract their in-memory state and local storage (depending on deployment).

Trust boundaries

  • Between parties: all inter-party messages are untrusted until validated.
  • Between sessions: data must not be accepted across sessions unless explicitly designed (replay protections).
  • Between protocols: GG20 and FROST must not allow cross-protocol transcript confusion or reuse of secrets.

Cryptographic invariants

The following invariants must hold; violations are treated as security bugs or misconfiguration.

Paillier modulus constraints

  • Paillier N ≥ 3072 bits and N ≥ q^8

ZK setup constraints

  • In ZKSetup, ĤN is a Blum integer (p ≡ q ≡ 3 (mod 4))
  • h1, h2 ∈ QR(ĤN) and gcd(h_i, ĤN) = 1

FROST transcript constraints

  • All parties must use identical additionalContext (AAD) per operation.
  • All parties must use the same sorted commitment list per operation.

Encoding and hashing

  • All hashed data is TLV-encoded (Bytes.encode).
  • No ad-hoc concatenation is used for transcript inputs.

Nonce and randomness handling

  • One-time values (d, e, r, Paillier r) are never reused.
  • One-time secrets are destroyed/zeroed after use.

Implementation and cryptographic backends

The project avoids Java BigInteger primitives for security-critical arithmetic. Its foundation uses native cryptographic/math backends:

  • libsecp256k1 (secp256k1 group operations)
  • libsodium (Ed25519 and related primitives)
  • libgmp (large integer arithmetic where required)

Operations over private shares are implemented using constant-time routines where applicable and supported by the underlying backend.

Attack surfaces and mitigations

This section groups threats by class and lists the primary mitigations in tss4j.

1) Malformed or weak Paillier modulus (key extraction)

Risk: - A malicious party provides a weak or non-biprime modulus to enable factorization or secret extraction.

Mitigations:

  • BiPrime proof

    • Generator: org.exploit.tss.proof.paillier.BiPrimeProofGenerator
    • Validator: org.exploit.tss.proof.paillier.BiPrimeProofValidator

  • NoSmallFactor proof

    • Generator: NoSmallFactorProofGenerator
    • Validator: NoSmallFactorProofValidator

  • MtAProtocol.validatePaillierN enforces N ≥ q^8 and minimum security size.

2) Range abuse in MtA (out-of-range plaintexts)

Risk: - A malicious participant uses values outside the expected range to bias results or leak information.

Mitigations:

  • PaillierRangeProof

    • Generator: PaillierRangeProofGenerator
    • Validator: PaillierRangeProofValidator

  • Witness binding:

    • PaillierRangeEncryptionWitness(m, r, c, pk, zk, q)

  • Context binding:

    • PaillierRangeProofContext(c, q, zk, ctx)

  • Enforces m ∈ [0, q) and binds the proof to ciphertext c.

3) Malformed MtA response (arbitrary c_j)

Risk:

  • A malicious respondent returns an unrelated ciphertext to break correctness or leak information.

Mitigations:

  • PaillierRespondentProof
    • Generator: PaillierRespondentProofGenerator
    • Validator: PaillierRespondentProofValidator
  • Context binding:
    • PaillierRespondentProofContext(c_i, c_j, q, zk, ctx)
  • Validator checks bounds (s1 ∈ Z_{q^3}, t1 ∈ Z_{q^7}), rejects non-units, and binds c_j to the expected construction.
  • MtAProtocol.computeCjWithY constructs c_j as Enc(y; r_j) and requires a valid proof.

4) Transcript mixups / cross-session reuse

Risk:

  • Messages or proofs from one session are replayed into another, causing acceptance under a different context.

Mitigations:

  • TLV encoding is used everywhere needed: org.exploit.tss.bytes.Bytes.encode
  • GG20 proofs include explicit session context bytes.
  • FROST hashes (H1, H2, PoP) bind to AAD and operation-specific transcript inputs.

5) Rogue-key and aggregator vectors (FROST)

Risk:

  • A malicious participant or aggregator attempts rogue-key attacks, commitment manipulation, or mismatched participant sets.

Mitigations:

  • Proof-of-possession (PoP):
    • FrostPreProcessor.generateCommitment produces sigma = r + c·sk_i
    • Challenge: c = H(POP_DOMAIN || AAD || Y_i || R)
    • Verification: SignaturePartAggregator.verifyPoP uses identical challenge inputs
  • Binding factors and transcript hashing:
    • FrostHash.H1(idx, msg, AAD, B, q)
    • FrostHash.H2(R, Y, msg, AAD, q)
  • Aggregator-side enforcement:
    • Requires identical AAD and identical participant list for the operation
    • Requires identical sorted commitment list

Per-share correctness check:

  • R = Σ(D_j + ρ_j E_j)
  • g·z_i = D_i + ρ_i E_i + λ_i·c·Y_i

6) Replay / cross-protocol reuse

Risk:

  • Reusing the same transcript inputs across different domains (e.g., PoP vs signing) could enable replay or substitution.

Mitigations:

  • Domain tags are used in all FROST hashes (H1/H2/PoP).
  • TLV encoding ensures unambiguous hashing inputs.
  • GG20 proofs bind to exact ciphertexts and session context.

7) RNG misuse / nonce reuse

Risk:

  • Nonce reuse breaks security for Schnorr and can catastrophically leak key material.

Mitigations:

  • ZKRandom is backed by a strong CSPRNG (SecureRandom strong instance).
  • Fresh randomness is generated for all one-time secrets: (d, e, r, r_j, Paillier r) per session.
  • Operational requirement: destroy/zero one-time values after use and never reuse across retries.

8) Performance hardening / shared-state risks

Risk:

  • Shared mutable state or cross-thread reuse of sensitive values can introduce correctness or leakage issues.

Mitigations:

  • Proof generation and verification are parallelized across independent rounds without shared mutable state.
  • Independent sessions must not share RNG state or nonce pools.

Residual risks

Even with the mitigations above, the following risks remain:

  • Threshold limit: compromise/collusion of ≥ t parties breaks secrecy and unforgeability by definition of the threshold model.
  • Side channels beyond timing: EM/power/cache/invasive side channels are out of scope; deployments should assume hardened hosts for high-value custody.
  • Supply chain risk: compromise of native crypto backends or build pipeline can undermine security. Although TKeeper includes all natives in build, it tries to load required dependencies from system, if natives for target OS are not found (e.g linux-aarch64)
  • Denial of service: an attacker can still attempt to exhaust CPU by triggering expensive proof verification; operational rate limiting and request gating are required at the service layer.

References

  • tss4j repository: https://github.com/exploit-org/tss4j