Ataques em Cerimônias de Assinatura Limiar: Como um Participante Malicioso Pode Viesar a Geração de Chaves no FROST

Hook & Contexto

Carteiras MPC se tornaram a camada de infraestrutura da custódia cripto institucional. A promessa é atraente: nenhuma chave única, nenhum ponto único de falha. Mas essa promessa repousa em uma cerimônia que a maioria dos engenheiros trata como uma caixa-preta — o protocolo de Distributed Key Generation (DKG). Quando você implementa FROST em um quórum de assinatura t-of-n, a segurança de cada assinatura subsequente depende inteiramente da integridade dessa cerimônia de inicialização. Se o DKG for comprometido, a carteira é comprometida — silenciosamente, permanentemente e retroativamente.

FROST (Flexible Round-Optimized Schnorr Threshold Signatures) é cada vez mais a escolha padrão para sistemas de limiar em produção. É rápido, produz assinaturas compactas compatíveis com Schnorr e tem sólido respaldo acadêmico. Mas o DKG do FROST herda uma classe de vulnerabilidades que não são únicas do FROST — elas decorrem do desafio fundamental de combinar aleatoriedade gerada independentemente por partes que não confiam mutuamente. Um único participante malicioso que se desvia precisamente durante a fase de broadcast do polinômio pode viesar o segredo compartilhado do grupo para um valor que ele conhece, efetivamente reconstruindo a chave privada do grupo sozinho, enquanto cada participante honesto acredita que a cerimônia foi concluída corretamente.

Este artigo disseca esse ataque completamente. Cobrimos a estrutura de commitment-reveal do DKG, os desvios exatos que um participante fraudulento faz, como o ataque se parece do ponto de vista dos participantes honestos (spoiler: nada), e os controles criptográficos — commitments de compartilhamento secreto verificável, abort-on-equivocation — que implementadores devem aplicar antes de chamar uma cerimônia DKG de pronta para produção.

TL;DR

Fundamentos & Teoria

Assinaturas Schnorr como Camada Base

FROST produz assinaturas Schnorr de limiar. Em um esquema Schnorr padrão, um assinante mantém chave privada x, publica X = x·G, e produz assinaturas (R, s) tal que s·G = R + H(R, X, m)·X. A segurança da chave do grupo em FROST significa que o escalar correspondente x é dividido entre participantes usando Shamir's Secret Sharing, e nenhum t-1 participantes podem reconstruir. A chave pública do grupo X é conhecida publicamente; o escalar x nunca deve existir em um único local.

Shamir Secret Sharing Revisitado

Em (t, n) Shamir's Secret Sharing, um distribuidor gera um polinômio f(z) = a_0 + a_1·z + ... + a_{t-1}·z^{t-1} onde a_0 é o segredo. Cada um dos n participantes recebe a avaliação f(i) para seu índice i. Qualquer t compartilhamentos permite reconstrução via interpolação de Lagrange; menos de t compartilhamentos não revelam nada sobre a_0. A propriedade crítica: o segredo é o termo constante do polinômio.

No DKG do FROST, não há distribuidor. Todo participante é simultaneamente um compartilhador e um receptor de compartilhamentos. Cada participante i gera seu próprio polinômio f_i(z) com um termo constante secreto a_{i,0}. O segredo do grupo é a soma x = Σ a_{i,0} entre todos os participantes. A chave pública do grupo é X = x·G = Σ a_{i,0}·G.

Onde Se Encaixa no Fluxo de Trabalho

A janela de ataque está inteiramente dentro dos Rounds 1 e 2. Uma vez que a cerimônia é concluída sem abort, o dano está feito. É por isso que controles de detecção devem ser aplicados dentro da cerimônia, não como auditoria posterior.

Conceitos-Chave em Profundidade

1. A Fase Commitment-Reveal (Round 1)

No DKG do FROST, Round 1 requer que cada participante i:

1. Amostra um polinômio aleatório f_i(z) = a_{i,0} + a_{i,1}·z + ... + a_{i,t-1}·z^{t-1}
2. Computa commitments Feldman VSS: C_{i,k} = a_{i,k}·G para cada coeficiente k
3. Computa uma Proof of Knowledge (PoK) de a_{i,0} — uma prova Schnorr de que conhecem o discrete log de C_{i,0}
4. Transmite {C_{i,0}, C_{i,1}, ..., C_{i,t-1}, PoK_i} para todos os participantes

Os commitments vinculam o participante a um polinômio específico antes dos compartilhamentos serem trocados. O PoK previne o ataque de chave rogue garantindo que o participante conhece seu próprio coeficiente secreto — eles não podem reivindicar uma contribuição de chave pública que não possam assinar.

A garantia de segurança aqui é inteiramente condicional ao broadcast ser consistente. Todo participante deve receber o mesmo vetor de commitment do participante i. Se o participante i enviar vetores de commitment diferentes para receptores diferentes, estão equivocando — e essa é a principal superfície de ataque.

2. O Desvio do Participante Fraudulento

Aqui está o ataque preciso. Suponha que o participante m seja malicioso em um grupo (2, 3) com participantes {1, 2, 3} onde m = 3.

Comportamento legítimo (o que Round 2 requer):

• Participante 3 envia compartilhamento f_3(1) para participante 1 e f_3(2) para participante 2
• Ambos os compartilhamentos devem ser consistentes com o polinômio comprometido: f_3(j)·G = Σ_k C_{3,k}·j^k

Comportamento fraudulento — o ataque de viés:

Sem detecção de equivocação, participante m pode fazer o seguinte:

1. Observa os commitments do Round 1 de todos os outros participantes C_{1,0} e C_{2,0}
2. Computa qual seria a chave pública do grupo se contribuísse honestamente: X_target = C_{1,0} + C_{2,0} + C_{m,0}
3. Escolhe a_{m,0} depois de ver os commitments dos outros, mirando em um valor onde a_{m,0} torna o segredo do grupo um valor x_target que o participante m pré-computou e armazenou

Este é o ataque de chave rogue em sua forma mais simples. O requisito PoK (passo 3 do Round 1) é especificamente projetado para fechar isso: porque participante m deve comprometer C_{m,0} = a_{m,0}·G e provar conhecimento de a_{m,0} antes de ver os coeficientes dos outros — ou pelo menos, simultaneamente em um broadcast atômico — eles não podem retroativamente escolher a_{m,0} para cancelar as contribuições honestas.

O vetor de ataque residual — quando o PoK existe mas a equivocação não — é mais sutil:

Participante m transmite diferentes valores C_{m,0} para diferentes subconjuntos de participantes. Para o participante 1 envia C'_{m,0}, e para o participante 2 envia C''_{m,0}. Cada participante honesto verifica os compartilhamentos que recebem contra o commitment que recebeu, então ambos passam na verificação local. Mas o grupo agora está operando em uma visão inconsistente da chave pública, e participante m engenheirou um cenário onde a chave agregada real é uma que ele controla.

3. Commitments de Verifiable Secret Sharing como Defesa

Os commitments Feldman VSS transformam o esquema Shamir em um onde a validade do compartilhamento é verificável publicamente. Quando participante i envia compartilhamento s_{i,j} = f_i(j) para participante j, o receptor j verifica:

s_{i,j} · G == Σ_{k=0}^{t-1} C_{i,k} · j^k

Se essa verificação falhar, participante j sabe que participante i enviou um compartilhamento inconsistente e pode fazer uma acusação. Isso fecha o ataque de compartilhamento inconsistente mas não o ataque de broadcast de commitment inconsistente. Um participante fraudulento que envia vetores de commitment consistentes (mas diferentes) para diferentes participantes ainda pode passar nas verificações VSS por receptor.

Este diagrama ilustra por que a verificação por receptor sozinha é insuficiente.

4. Abort-on-Equivocation: A Camada de Aplicação Faltante

A defesa completa requer um primitivo de broadcast consistente — efetivamente garantindo que todo participante receba a mesma mensagem do Round 1 do participante m. Na prática, isso é implementado por:

• Commitment em um quadro de avisos público: Todas as mensagens do Round 1 são postadas em um canal append-only, publicamente legível (um smart contract, um blockchain público, ou um serviço de broadcast autenticado). Todo participante lê todos os commitments dos outros da mesma fonte antes de prosseguir para o Round 2.
• Comparação de commitment entre participantes: Depois de receber mensagens do Round 1, os participantes comparam hashes dos vetores de commitment dos outros fora de banda ou via uma segunda rodada de reconhecimentos.
• Provas de equivocação: Se o participante j e o participante k puderem ambos provar que receberam diferentes commitments do participante m — apresentando mensagens assinadas/autenticadas — o protocolo deve abortar e excluir m.

A especificação FROST (conforme descrita no draft IETF draft-irtf-cfrg-frost) explicitamente requer que listas de commitment usadas durante assinatura sejam consistentes e autenticadas. Porém, a fase DKG é underspecified em muitas implementações, deixando a garantia de broadcast consistente para o ambiente de implementação. Esta é a brecha que implementações do mundo real rotineiramente perdem.

5. O Ângulo de Verificação SageMath

Para auditores e implementadores, SageMath fornece um ambiente ideal para verificar transcrições de cerimônia. Dado um conjunto completo de vetores de commitment publicados {C_{i,k}} e a chave pública do grupo reivindicada X, um verificador pode checar:

# Em SageMath
# Verify group key derivation consistency
X_derived = sum(C[i][0] for i in participants)
assert X_derived == X_claimed, "Group key inconsistency detected"

# Verify each share against its commitment
for j in participants:
    for i in participants:
        lhs = shares[i][j] * G
        rhs = sum(C[i][k] * pow(j, k) for k in range(t))
        assert lhs == rhs, f"Invalid share from {i} to {j}"

Este tipo de verificação de transcrição deveria ser um passo de auditoria pós-cerimônia padrão antes de qualquer fundo ser comprometido em endereços derivados da chave do grupo.

Alternativas & Comparação

GG20 (usado por muitas implementações MPC institucionais antigas) inclui provas zero-knowledge mais elaboradas durante a geração de chaves mas tem suas próprias vulnerabilidades bem documentadas — notavelmente a divulgação de 2021 de um ataque de geração de chaves malicioso pela Verichains. DKLs19 tem provas de segurança mais fortes e é cada vez mais preferido para novas implementações, mas é mais complexo de implementar corretamente. O problema de broadcast consistente está presente em todos os DKGs multi-party em vários graus; o que difere é como explicitamente cada protocolo especifica a mitigação.

Conclusões & Leitura Adicional

Leitura Adicional & Referências

• FROST: Flexible Round-Optimized Schnorr Threshold Signatures — IETF Draft (draft-irtf-cfrg-frost)
• ZKDocs — Threshold Signature Schemes Reference
• FROST Reference Implementation — ZcashFoundation/frost (GitHub)
• Verichains — Critical Vulnerabilities in GG18 and GG20 MPC Implementations (2022)
• Pedersen, T. — Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing (CRYPTO 1991)
• Komlo & Goldberg — FROST: Flexible Round-Optimized Schnorr Threshold Signatures (SAC 2020)
• Feldman — A Practical Scheme for Non-interactive Verifiable Secret Sharing (FOCS 1987)
• Trail of Bits — Cryptographic Vulnerabilities in MPC Wallets (2023 Research)