As passkeys são uma abordagem segura e amigável para autenticação que também pode ser usada para criar e armazenar com segurança carteiras de criptomoedas, graças ao seu uso de criptografia de curva elíptica.
Neste post, iremos abordar como funcionam as passkeys, explorar os riscos de usar passkeys para carteiras de criptomoedas e aprofundar como a abstração de contas permite que as passkeys sejam utilizadas quando combinadas com contratos inteligentes.
Isso permite que os usuários façam login e interajam facilmente com aplicativos de maneira autorizada sem nunca armazenar credenciais sensíveis; fornecendo uma experiência perfeita e segurança adicional contra violações de dados e vetores de ataque comuns, como phishing.
Na maioria dos dispositivos, como o iPhone, as senhas de acesso são armazenadas dentro de hardware especializado chamado o Enclave Seguro; um ambiente dedicado e isolado projetado para proteger dados sensíveis, mesmo se o processador principal for comprometido.
Para assinar uma transação com a chave privada de uma senha, a transação é enviada para o hardware seguro, onde é assinada, e a assinatura resultante é então gerada. Ao longo deste processo, nem o proprietário nem o desenvolvedor do aplicativo têm acesso à chave privada; eles apenas recebem as assinaturas geradas.
Isso oferece segurança aprimorada para o usuário, pois a chave privada geralmente não é carregada na memória do aplicativo, reduzindo o risco de exposição a possíveis ataques. Por exemplo, no iPhone, o usuário nem mesmo pode acessar o valor da senha em suas configurações, pois a chave é gerada e armazenada em hardware especializado que não é acessível à interface.
No entanto, há uma diferença importante que introduz complexidade ao usar senhas para contas de blockchain; senhas usam uma curva elíptica diferente das contas de blockchain.
Enquanto a Apple, o Android e o WebAuthn usam todos a curva secp256r1 (também conhecida como curva P-256) para as chaves de acesso, as contas de blockchain usam a curva elíptica secp256k1.
Isto significa que as transações assinadas pela chave privada de uma chave de acesso não são compreendidas (e, portanto, rejeitadas) por blockchains como o Ethereum ou o Abstract. A expectativa padrão dos blockchains é que a transação seja assinada por um par de chaves gerado na curva secp256k1.
Uma vez que as carteiras regulares (EOA) são geradas na curva k1, as carteiras de contratos inteligentes são, portanto, necessárias, pois podem incluir lógica personalizada que verifica transações assinadas por chaves privadas geradas por passkeys antes de autorizar a execução da transação.
A variação k1 da curva também carece de certas características como coeficientes adicionais que tornam o secp256r1 ligeiramente mais complexo, o que significa que o secp256k1 é mais eficiente computacionalmente para geração de chave, criação de assinatura e verificação.
Embora não tenham sido encontradas vulnerabilidades diretas, também existem teorias da conspiração que afirmam que o Bitcoin escolheu usar a curva k1 em vez da curva r1 mais adotada para evitar qualquer potencial para uma porta dos fundos que poderia ter sido introduzida secretamente por agências governamentais como a NSA, dada a sua participação no desenvolvimento de padrões criptográficos endossados pelo NIST.
Bibliotecas de código aberto como Verificador P256 de código aberto da Daimoforam construídos para verificar assinaturas na curva secp256r1 dentro de contratos inteligentes escritos em Solidity.
Na Ethereum, isso significa que você pode usar contratos inteligentes construídos com a Padrão de abstração de conta ERC-4337para verificar a assinatura r1 da Operação do Utilizador dentro do validateUserOpfunção da carteira de contrato inteligente.

Em Abstract, abstração de conta nativapermite que as carteiras de contratos inteligentes enviem transações com o campo de assinatura definido como a mensagem assinada pela chave privada da chave de acesso. Se a conta que enviou a transação for um contrato inteligente que inclui lógica para verificar assinaturas r1 (em validarTransação função), a transação é aceite.

As carteiras de contratos inteligentes oferecem mais flexibilidade do que as carteiras tradicionais de EOA (Contas de Propriedade Externa) e, como podem incluir código EVM arbitrário, têm o poder de verificar assinaturas (ou seja, autorizar transações) a partir de pares de chaves criados na curva elíptica r1.
RIP-7212 (Proposta de Melhoria Rollup) propõe a adição de um contrato inteligente pré-compilado para L2s Ethereum para uma verificação de assinatura mais eficiente em relação ao consumo de gás na curva r1. Embora isso ainda não esteja incluído no Ethereum, soluções de escalabilidade compatíveis com EVM, como Abstract, já implementaram isso e oferecem uma redução de 100x no consumo de gás para verificações de assinatura r1.
Esta é uma escolha de design intencional para evitar ataques de phishing, no entanto, representa uma grande falha para os utilizadores que valorizam a auto-guarda, pois a sua carteira está diretamente ligada a uma aplicação; o que significa:





