Passkeys são uma abordagem segura e amigável ao autenticação que também pode ser usado para criar e armazenar com segurança carteiras de criptomoedas, graças ao seu uso de criptografia de curva elíptica.
Nesta postagem, vamos abordar como as chaves de acesso funcionam, explorar os riscos do uso de chaves de acesso para carteiras de criptomoedas e mergulhar em como a abstração de conta permite que as chaves de acesso sejam usadas 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; proporcionando 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 são armazenadas dentro de hardware especializado chamado o Enclave Seguro; um ambiente dedicado e isolado projetado para proteger dados sensíveis mesmo que o processador principal seja comprometido.
Para assinar uma transação com a chave privada de uma senha, a transação é enviada ao hardware seguro, onde é assinada e a assinatura resultante é então gerada. Durante todo esse processo, nem o proprietário nem o desenvolvedor do aplicativo têm acesso à chave privada; eles só recebem as assinaturas geradas.
Isso proporciona 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; as senhas usam uma curva elíptica diferente das contas de blockchain.
Embora a Apple, o Android e o WebAuthn usem todos a curva secp256r1 (também conhecida como P-256) para senhas, as contas de blockchain usam a curva elíptica secp256k1.
Isso significa que transações assinadas pela chave privada de uma senha não são compreendidas (e, portanto, rejeitadas) por blockchains como Ethereum ou 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, são necessárias carteiras de contrato inteligente, 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 chaves, criação de assinaturas e verificação.
Embora não tenham sido encontradas vulnerabilidades diretas, também existem teorias conspiratórias de que o Bitcoin escolheu usar a curva k1 em vez da curva r1 mais bem adotada para evitar qualquer potencial de uma porta dos fundos que possa ter sido introduzida secretamente por agências governamentais como a NSA, dada a sua participação no desenvolvimento de padrões criptográficos endossados pela NIST.
Bibliotecas de código aberto como Verificador de código aberto P256 de Daimoforam criados para verificar assinaturas na curva secp256r1 dentro de contratos inteligentes escritos em Solidity.
No Ethereum, isso significa que você pode usar contratos inteligentes construídos com o Padrão de abstração de conta ERC-4337para verificar a assinatura r1 da Operação do Usuário dentro do GatevalidarOperaçãoUsuáriofunção da carteira de contrato inteligente.

No Abstract, abstração de conta nativapermite que 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 é aceita.

As carteiras de contrato inteligente oferecem mais flexibilidade do que as carteiras tradicionais de EOA (Contas de Propriedade Externa) e, uma vez que 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.
A RIP-7212 (Proposta de Melhoria Rollup) propõe a adição de um contrato inteligente pré-compilado para Ethereum L2s para uma verificação de assinatura mais eficiente em termos de gás na curva r1. Embora isso ainda não esteja incluído no Ethereum, soluções de escalonamento compatíveis com EVM, como Abstract, já implementaram isso e oferecem uma redução de gás de 100 vezes 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 usuários que valorizam a auto-guarda, pois sua carteira está diretamente ligada a um aplicativo; o que significa:





