Como já reunimos a grande maioria do conhecimento teórico que precisávamos para começar nossa jornada na web3, a proporção de coisas novas por semana começou a diminuir. Não me entenda mal, não paramos de aprender, estamos apenas aprendendo coisas mais complexas que exigem mais tempo para digerir, e também começamos a trabalhar em um pequeno projeto de nossa escolha para praticar o máximo possível (provavelmente vou fazer um post extra no final do curso).

Além disso, também tivemos várias conversas sobre criptomoedas com convidados incríveis, onde aprendemos sobre Zero Knowledge Proof (Prova de Conhecimento Zero), Foundry ou o protocolo Graph. Sim, eu sei o que você está pensando... Tenho muitos tópicos interessantes no meu backlog e com certeza deveria produzir mais conteúdo!

Então, agora que você sabe o que temos feito, vamos nos concentrar na verificação de assinatura digital e no ecrecover.

Sumário

1 . First things First
..... . Algoritmo de Assinatura Digital de Curva Elíptica
..... . ecrecover

2 . Padrões de Assinatura Digital
..... . Como implementar o EIP
..... . Metatransações
..... . ERC20 Permit
..... . Vulnerabilidades e Práticas

3 . Recursos

First things first

Antes de descobrir o que diabos é ecrecover, precisamos dominar o básico. Você provavelmente já assinou mensagens com sua carteira, mas já parou para pensar em como isso realmente funciona?

As assinaturas digitais funcionam de maneira semelhante à criptografia assimétrica , mas de maneira oposta.

Nas assinaturas digitais, alguns dados são assinados ao fazer o hash da mensagem com a chave privada do remetente (e obviamente um algoritmo de hash também). Isso produz um resumo de hash, que só pode ser recriado usando uma das chaves do par de chaves usado pelo remetente. O destinatário usará a chave pública do remetente para fazer o hash da mensagem e afirmar que ela corresponde ao resumo de hash recebido. Se isso acontecer, o destinatário pode ter certeza de que o remetente foi quem assinou a mensagem e que a mensagem não foi alterada.

Algoritmo de Assinatura Digital de Curva Elíptica

Se você já ouviu falar sobre Algoritmo de Assinatura Digital de Curva Elíptica (ECDSA), você deve saber que é um dos algoritmos de criptografia de chave pública mais complexos e eficientes. As chaves são geradas por meio de criptografia de curva elíptica, que são menores do que as chaves habituais geradas por algoritmos de assinatura digital. No entanto, eles são capazes de oferecer o mesmo nível de segurança que qualquer outro algoritmo de assinatura digital.

ecrecover

Contratos Inteligentes na Ethereum têm acesso ao algoritmo integrado de verificação de assinatura ECDSA via ecrecover. Este método de sistema verifica a integridade de quaisquer dados arbitrários assinados e recupera o endereço correspondente ao assinante usando v, r, s e o hash de assinatura.

Exemplo de implementação do ecrecover.

Assinaturas são interessantes porque os usuários podem aprovar coisas sem precisar enviar uma transação. Esse recurso é útil porque pode melhorar a UX (experiência do usuário) e reduzir os custos de gás do usuário usando meta-transações ou o ERC20-permit (mais sobre isso posteriormente).

No entanto, como de costume, uma melhor UX e conveniência geralmente vêm à custa da segurança. Por isso, é importante seguir os padrões e as melhores práticas desenvolvidas pela comunidade ao lidar com assinaturas digitais.

Padrões de Assinatura Digital

Existem três padrões principais que podem ser usados ​​para assinar dados com uma chave Ethereum:

• Eth_sign: A maneira mais simples, poderosa e perigosa de assinar uma mensagem. Esse método é usado para assinar dados arbitrários, de modo que pode levar os usuários a assinarem dados que permitem uma transação futura sem confirmação adicional. Esse recurso é extremamente perigoso porque os usuários podem assinar esses tipos de transações "descobertas" sem saber. Por causa disso, o uso de eth_sign é desencorajado.
• Personal_sign: O EIP-191 introduziu um formato para assinar dados e garantir que não fosse uma transação válida. Para implementar esse método em geth, eles prefixaram todos os dados assinados com "\x19Ethereum Signed Message:\n" + len(message). Assim impossibilitando o uso dessas assinaturas como transações válidas.

"0x19 [versão de 1 byte] [dados específicos da versão] [dados para assinar]".

• signTypedData_v4: Para ajudar a padronizar o uso de assinaturas na Ethereum, o EIP-712 foi introduzido e atualmente é amplamente usado e considerado um padrão que ajuda os desenvolvedores a evitar os problemas de segurança mais comuns ao lidar com assinaturas.

Como implementar o EIP-712

O principal objetivo deste EIP era garantir que os usuários entendessem o que estavam assinando. Fornecendo contexto explícito do endereço do contrato e da rede. Por fim, este EIP também teve como objetivo garantir que cada assinatura só pudesse ser utilizada pelo contrato pretendido.

Esses requisitos são alcançados combinando um Domain Separator hash _(hash separador de domínio) e uma _Typed Structed Data hash (_estrutura de hash de dados tipificada) _usando-os dentro do ecrecover.

• Hash Separador de Domínio : O separador de domínio é um hash que é calculado a partir dos dados do domínio e é usado para evitar a reutilização de uma assinatura em outro dApp.
• Estrutura de dados tipificada: Os dados que precisam ser assinados são definidos usando _structs _(estruturas) e tipos primários do Solidity.

Exemplo de implementação do padrão de assinatura EIP-712.

Metatransações

Uma metatransação é um método para separar quem paga pelo gás de uma transação de quem se beneficia com a execução da transação.

Um usuário assina a meta-transação e a envia para um operador (observe que, como não há interação com a blockchain, não é necessário nenhum gás para assinar). O operador pega essa meta-transação assinada e a envia para a blockchain, pagando ele mesmo as taxas da transação regular externa.

ERC20 Permit

O padrão ERC20 requer duas transações diferentes para transferir tokens ERC20 de uma conta de propriedade externa (External Owned Account - EOA) usando um contrato inteligente de terceiros:

• Primeiro, o EOA precisa realizar uma transação ERC20.approve() para colocar o terceiro na lista de permissões contrato inteligente.
• Em seguida, o EOA precisa chamar a função do contrato inteligente do terceiro que aciona o ERC20.transferFrom()para transferir os tokens.

Com a implementação do EIP-2612, também conhecido como ERC20-Permit, é possível simplificar o processo por meio da verificação de assinatura. Com o uso do ERC20-Permit, os usuários podem simplesmente assinar o valor da franquia com sua carteira, e o operador pode cuidar do resto.

Vulnerabilidades e Práticas

Ataque de resposta de assinatura: A menos que algumas precauções sejam tomadas, a mesma assinatura pode ser usada várias vezes para executar uma função. Para evitar esses tipos de exploits, o uso de nonces é extremamente recomendado (observe que na implementação do EIP-712 acima eu já usei um nonce para evitar essa vulnerabilidade).

Maleabilidade da Assinatura: Devido à estrutura simétrica das curvas elípticas, para cada conjunto de v, r, s existe outro conjunto diferente de v, r, s que também possui a mesma relação. Isso resulta em duas assinaturas válidas e permite que agentes mal-intencionados calculem uma assinatura válida sem a chave privada do usuário-alvo. A maneira mais fácil de resolver essa vulnerabilidade é usando a biblioteca ECDS OpenZeppelin.

Recursos

Se você não estiver familiarizado com criptografia básica, você deve definitivamente verificar os slides públicos da Artemis. Parabéns à equipe por compartilhar progressivamente o conteúdo do curso e torná-lo acessível a todos os interessados!

Se você quiser ver implementações de meta-transações e erc20-permit, você pode dar uma olhada nestes artigos por soliditydeveloper.com.

Por fim, se você deseja obter uma compreensão realmente profunda das assinaturas digitais e, especialmente, de suas possíveis vulnerabilidades, recomendo que você verifique este ótimo artigo da Immunefi, uma das principais plataformas de recompensas de bugs.

Este artigo foi escrito por 0xRusowsky e traduzido por Diogo Jorge. O artigo original pode ser encontrado aqui.