Chaves, assinaturas e endereços · Aula 3 de 5
Assinaturas digitais e autorização de transações
7 min de leitura
O que uma assinatura autoriza
Uma assinatura digital é um valor criptográfico criado sobre uma mensagem especificada usando uma chave privada e um algoritmo de assinatura. Outros participantes podem testar a assinatura em relação à mensagem e à chave pública correspondente. Em uma transação de blockchain, a mensagem geralmente representa uma alteração pretendida segundo as regras da rede: transferir valor, chamar um programa ou satisfazer condições vinculadas a uma saída existente. Os bytes exatos incluídos nessa mensagem determinam o que é e o que não é autorizado. Uma assinatura não significa “concordo com tudo”; ela é verificada em relação a uma declaração definida com precisão, mesmo que o software apresente essa declaração a quem assina por meio de um resumo curto e legível.
Assinar e transmitir são eventos distintos. Um dispositivo ou aplicativo pode construir uma transação, solicitar uma assinatura e só então enviar os bytes assinados a um nó da rede. Portanto, uma assinatura pode existir antes de a transação ficar visível em um explorador de blocos. Depois de enviada, a rede ainda verifica sua validade e outras regras, e a inclusão não é automática. Os alunos devem distinguir preparação, assinatura, envio, validação e inclusão. Os mecanismos de consenso do Módulo 2 determinam como as transações aceitas passam a fazer parte de um histórico compartilhado; eles não são, por si só, o ato criptográfico de assinar.
Uma mensagem deve ser inequívoca
Serialização e campos que podem ser assinados
A serialização converte informações estruturadas em uma representação exata em bytes. Um aplicativo pode exibir um destinatário, um valor, uma taxa e o nome de uma rede, mas a verificação da assinatura se aplica a bytes definidos segundo as regras de codificação de um protocolo. A alteração de qualquer campo assinado após a criação da assinatura normalmente faz com que a verificação falhe. Alguns protocolos autorizam deliberadamente um subconjunto específico de campos, usando modos de assinatura que alteram quais partes são abrangidas. Consequentemente, um analista não deve presumir que toda assinatura vincula cada elemento de contexto exibido. A pergunta técnica relevante é: quais campos esse modo de assinatura específico realmente vinculou?
Uma transação no estilo Bitcoin consome saídas de transação não gastas anteriores e propõe novas saídas. O hash de assinatura aplicável vincula informações da transação de acordo com as regras e os sinalizadores de tipo de hash. Uma transação no estilo Ethereum geralmente contém campos como destino, valor, dados, nonce e parâmetros de taxa, e usa uma codificação de transação apropriada para a assinatura. Uma transação Solana assina uma mensagem serializada que contém instruções, informações de contas e um blockhash recente ou uma alternativa permitida. Apesar de suas estruturas diferentes, as três se baseiam no mesmo princípio: os verificadores devem validar a mesma mensagem pretendida que foi assinada.
Autorizar uma transação não é o mesmo que executá-la
Uma assinatura válida é necessária para muitos tipos de transação, mas não é suficiente para que uma alteração de estado seja bem-sucedida. Uma transação proposta pode ter um contador de sequência inválido, saldo insuficiente, um blockhash recente expirado, uma condição de gasto não satisfeita ou um erro de execução de contrato. Em sistemas baseados em contas, a assinatura pode ser válida mesmo quando a execução falha e uma taxa de processamento é cobrada. Em outros casos, a transação pode nem chegar à blockchain. Portanto, para explicar uma transferência contestada, são necessárias pelo menos duas perguntas: a mensagem foi devidamente autorizada segundo as regras da rede e o que a execução ou liquidação na rede realmente produziu?
A autorização também pode envolver mais de uma chave. Uma regra de gasto pode exigir várias assinaturas, impor condições baseadas em tempo ou usar lógica de programa. Uma conta de contrato inteligente pode validar instruções de acordo com seu código, em vez de depender de uma única conta convencional de propriedade externa. Esses sistemas não devem ser descritos como isentos de assinatura apenas porque nenhuma assinatura de conta comum aparece no mesmo campo. A lição mais ampla é que as regras de autorização pertencem ao protocolo ou programa e devem ser lidas em contexto. Governança e controles de custódia são assuntos distintos, abordados mais adiante no curso.
Repetição e vinculação ao contexto
Uma repetição ocorre quando dados assinados válidos são reutilizados em um contexto no qual não se pretendia autorizar outra ação. O projeto de transações pode reduzir o risco de repetição usando identificadores específicos da rede, contadores de sequência, dados de expiração ou outro contexto assinado. A Ethereum Improvement Proposal (EIP) 155, Proteção simples contra ataques de repetição, introduziu dados de identificação da cadeia na construção da assinatura para transações Ethereum legadas relevantes. Os formatos de transação modernos também incluem regras de contexto da cadeia, mas as implementações variam. O princípio geral é simples: os verificadores precisam saber não apenas se uma assinatura é matematicamente válida, mas também se ela é válida para esta rede, este tipo de transação e este uso.
Solicitações de assinatura e compreensão humana
Uma interface de usuário pode exibir “Aprovar” ou “Assinar”, embora as ações subjacentes tenham consequências técnicas diferentes. Em contratos de tokens Ethereum, por exemplo, uma aprovação de limite de gasto pode permitir que outra conta ou contrato movimente tokens posteriormente dentro das regras do contrato, enquanto uma transferência simples de ativo nativo é uma transação direta. Uma assinatura de mensagem fora da cadeia pode autorizar uma ação posterior se um serviço ou contrato reconhecer essa mensagem assinada. Nem a palavra “assinatura” nem a ausência de uma movimentação imediata de tokens comprovam que a solicitação é inofensiva. Em um curso básico, os revisores devem aprender a perguntar qual capacidade específica é concedida e se esse escopo tem limite de tempo ou valor, ou se pode ser revogado segundo o projeto relevante.
Algoritmos e evidências de assinatura
O NIST FIPS 186-5, Padrão de Assinatura Digital, especifica técnicas que incluem ECDSA e EdDSA. A Bitcoin Improvement Proposal 340 especifica um esquema de assinatura Schnorr sobre secp256k1 para o ambiente Taproot do Bitcoin. As implementações da rede determinam precisamente como esses algoritmos são aplicados e codificados. Não basta identificar uma assinatura como “ECDSA” sem verificar o formato real da mensagem, a curva, as regras de verificação e a versão do protocolo. Os sistemas também podem usar hashes criptográficos antes ou durante a assinatura; calcular o hash da mensagem e assiná-la são operações relacionadas, mas não são a mesma operação.
| Verificação | Pergunta principal | O que uma resposta afirmativa não comprova |
|---|---|---|
| Verificação da assinatura | Esta assinatura corresponde a esta chave e a esta mensagem? | Identidade ou mandato legal de quem assina |
| Validação do protocolo | A transação obedece às regras da rede? | Que ela tenha sido incluída em um bloco |
| Execução registrada | A blockchain registrou a ação ou seu resultado? | A interpretação jurídica correta do evento |
| Aprovação organizacional | A ação era permitida pela política interna? | Que isso seja estabelecido automaticamente pela criptografia |
Como um revisor deve documentar uma ação assinada
- Registre a rede, o tipo de transação e o identificador exato da transação ou os dados serializados, quando disponíveis.
- Identifique o que representam os campos exibidos de quem assina, destino, contrato, valor, taxa e dados.
- Confirme o escopo da assinatura e o contexto aplicável de sequência ou proteção contra repetição.
- Separe a validade da assinatura do status da transação, do resultado da execução e da autorização organizacional.
Esse método evita dois erros opostos. O primeiro é tratar uma transação bem-sucedida como prova de que uma pessoa identificada a aprovou conscientemente. O segundo é tratar uma assinatura válida como prova de que a transação necessariamente foi bem-sucedida. As evidências técnicas podem apoiar uma investigação, mas a atribuição e a intenção jurídica dependem de fatos que normalmente não são registrados em uma blockchain. Quando um analista recebe apenas capturas de tela, a conduta mais adequada é buscar de forma independente os registros correspondentes na blockchain antes de registrar uma conclusão. O próximo módulo abordará questões práticas de armazenamento de chaves e organização da custódia, não os aspectos matemáticos tratados aqui.
Foco na prova: Identifique as cinco etapas de uma transação assinada típica, explique por que os bytes exatos que podem ser assinados e a proteção contra repetição são importantes e diferencie uma assinatura válida da execução bem-sucedida, da inclusão confirmada e da aprovação organizacional. Saiba que as assinaturas podem abranger escopos diferentes conforme as regras do protocolo.