WebAuthn pubKeyCredParams e credentialPublicKey: CBOR e COSE

Na segurança digital, as passkeys são o novo padrão de autenticação sem senha. No centro das passkeys está a criptografia de chave pública, utilizada no protocolo WebAuthn, no qual as passkeys se baseiam. Entender como a criptografia de chave pública é usada no WebAuthn, especialmente na criação, extração, gerenciamento e armazenamento de passkeys, é crucial ao projetar ou usar a autenticação com passkeys. A chave pública é armazenada no servidor da parte confiável (relying party) (RP), que é o backend do site que deseja autenticar um usuário via passkeys, e a chave privada é armazenada com segurança em um Módulo de Segurança de Hardware, dependendo do sistema operacional: Secure Enclave (iOS), TEE (Android) ou um TPM (Windows).

Neste post, vamos abordar rapidamente os fundamentos da criptografia de chave pública usada em passkeys. As seguintes perguntas devem ser respondidas até o final do post:

• Quais algoritmos de criptografia são suportados no WebAuthn?
• Como os pubKeyCredParams funcionam ao criar um par de chaves?
• Como o credentialPublicKey funciona ao extrair as chaves públicas criadas?

Para entender como a criptografia de chave pública funciona no WebAuthn, vamos dar uma olhada rápida em como ela funciona em geral e quais são os tipos comuns de algoritmos.

A criptografia de chave pública, também conhecida como criptografia assimétrica, contrasta com a criptografia simétrica, onde a mesma chave é usada tanto para criptografar quanto para descriptografar. A criptografia assimétrica emprega duas chaves distintas – uma chave pública, que pode ser compartilhada abertamente, e uma chave privada, que é mantida em segredo pelo proprietário.

Extraído de: https://en.wikipedia.org/wiki/Public-key_cryptography

Este método não apenas permite a criptografia de dados para garantir sua confidencialidade, mas também permite assinar mensagens. A assinatura verifica a identidade do remetente e garante que a mensagem não foi adulterada, confirmando assim sua autenticidade e integridade.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Aqui está uma visão geral de alguns tipos comuns de algoritmos usados na criptografia de chave pública:

A base matemática da criptografia de curva elíptica (ECC), incluindo ECDSA e EdDSA, envolve as propriedades das curvas elípticas, que não abordaremos neste artigo. Mas fica óbvio pela tabela acima que existem vantagens que impulsionam sua adoção. Vamos analisar as mais importantes na próxima seção.

Become part of our Passkeys Community for updates & support.

Join

A criptografia de curva elíptica tem sido amplamente adotada para dispositivos móveis, pois eles se beneficiam dos tamanhos de chave menores, o que traz as seguintes vantagens:

• Requisitos de Armazenamento Reduzidos: As chaves menores da ECC exigem menos espaço de armazenamento em comparação com métodos criptográficos tradicionais como o RSA. Isso é especialmente benéfico para dispositivos com recursos de memória limitados, permitindo um uso mais eficiente do espaço. A tabela a seguir mostra uma aproximação dos níveis de segurança comparáveis e os tamanhos reais das chaves usadas. O nível de segurança é medido em bits e geralmente corresponde a uma cifra de chave simétrica desse tamanho:

O termo nível de segurança neste contexto refere-se à força do sistema criptográfico, especificamente ao nível de dificuldade para um invasor derrotar as medidas de segurança. Geralmente é medido em bits e representa a quantidade de trabalho (o número de operações) que seria necessária para quebrar a criptografia ou forjar uma assinatura. Com o aumento do nível de segurança, as vantagens de tamanho se tornam óbvias, chegando a proporções de tamanho de chave de até 1:30.

• Desempenho Aprimorado: As chaves menores permitem operações criptográficas mais rápidas, o que é crucial para dispositivos com menor poder de processamento. Isso resulta em atividades de criptografia e descriptografia mais rápidas, aumentando o desempenho geral e a capacidade de resposta dos aplicativos móveis. Dependendo do tipo de benchmarks, os ganhos de velocidade variam de 10 a 40 vezes na execução. Aqui está um exemplo de dados de benchmark que a AWS realizou ao implementar o ECDSA para o Cloudfront em 2018:

• Eficiência de Bateria Melhorada: Com um processamento mais eficiente de chaves menores, as operações ECC podem consumir menos energia. Essa conservação de energia é vital para dispositivos móveis, onde preservar a vida útil da bateria é um desafio constante.

Esses fatores tornam a ECC particularmente adequada para ambientes móveis, onde a otimização de armazenamento, velocidade de processamento e consumo de energia é essencial. Como resultado, a ECC é cada vez mais favorecida na computação móvel por sua capacidade de fornecer segurança robusta sem comprometer o desempenho do dispositivo. No entanto, até hoje, muitas versões mais antigas de protocolos difundidos como TLS (usado para HTTPS, FTPS ou SMTPS), SSH ou IPsec ainda suportam RSA, mas começaram a oferecer variantes baseadas em ECC para clientes que as suportam.

O padrão WebAuthn não é um padrão de criptografia, mas sim um protocolo de segurança que fornece autenticação forte baseada em chave pública para aplicações web, permitindo que os usuários façam login usando biometria, dispositivos móveis ou chaves de segurança de hardware (por exemplo, YubiKeys) em vez de senhas. Portanto, o WebAuthn é intencionalmente agnóstico sobre qual criptografia baseada em chave pública é realmente usada. Vamos ver como isso é alcançado.

O protocolo de segurança WebAuthn facilita a autenticação criptograficamente segura entre o Usuário e a Parte Confiável (Relying Party). Em termos técnicos, isso significa que a Parte Confiável (um site que deseja usar passkeys com seus usuários) precisa trocar chaves através do navegador com o usuário e seu autenticador, que então armazena a chave privada no módulo de segurança de hardware (HSM) específico.

Para o cadastro / registro de passkeys, existem três etapas importantes:

• (1) A Parte Confiável sinaliza os algoritmos de criptografia suportados: A parte confiável sinaliza os algoritmos de criptografia suportados via PublicKeyCredentialCreationOptions.pubKeyCredParams juntamente com as outras PublicKeyCredentialCreationOptions.
• (2) O Autenticador do usuário cria o par de chaves: O autenticador verifica a lista pubKeyCredParams em busca de algoritmos de criptografia que ele suporta e cria um par de chaves juntamente com um ID da Credencial exclusivo. Ele armazena a chave privada no HSM e, em seguida, retorna a chave pública e o algoritmo de criptografia usado para o navegador. Em seguida, o navegador envia uma solicitação POST para o backend da Parte Confiável com o attestationObject na seção “authData”. Caso não haja correspondência dos algoritmos de criptografia suportados, a cerimônia de criação falhará.
• (3) A Parte Confiável extrai a chave pública e a armazena: A parte confiável recebe o attestationObject do navegador. Ela analisa a seção authData.credentialPublicKey e extrai a chave pública. Juntamente com a chave pública, informações sobre o algoritmo de criptografia usado e o ID da Credencial também são enviadas de volta para a parte confiável.

Para logins / autenticações subsequentes com passkeys, as seguintes etapas são necessárias (detalhes simplificados):

• (1) A Parte Confiável apresenta um desafio: A parte confiável gera um desafio aleatório e o fornece ao autenticador para assinatura.
• (2) O Autenticador do usuário assina o desafio: O Autenticador assina o desafio com a chave que corresponde à solicitação de autenticação e o retorna com o ID da Credencial para a Parte Confiável.
• (3) A Parte Confiável valida a assinatura: A Parte Confiável recebe as informações e procura a chave pública associada ao ID da Credencial usado. Em seguida, valida criptograficamente a assinatura usando o algoritmo de criptografia/assinatura acordado durante o registro das passkeys.

Ao observar ambos os casos, podemos ver que apenas para o cadastro / registro de passkeys as informações da chave pública e do algoritmo de criptografia são transportadas entre os atores.

Para eventos de login / autenticação subsequentes com passkeys, apenas o desafio e a assinatura fazem parte dos dados transmitidos.

O padrão WebAuthn usa os IDs de Algoritmo COSE da IANA para identificar os algoritmos de criptografia usados. Os IDs de Algoritmo COSE são usados tanto para sinalizar os algoritmos suportados em pubKeyCredParams quanto para transmitir o tipo de par de chaves realmente criado em credentialPublicKey. Vamos focar em sua implementação nas próximas duas seções.

A lista de Algoritmos COSE da IANA inclui mais de 75 algoritmos que teoricamente poderiam ser usados com o Padrão WebAuthn. A maioria dos algoritmos com ID negativo é de chave pública assimétrica e a maioria dos positivos é simétrica, mas isso é mais uma convenção, pois existem exceções.

Como apontamos antes, o algoritmo de criptografia precisa ser suportado pelo Autenticador e pelo backend da Parte Confiável para ser usado na cerimônia WebAuthn. Como a maioria das partes confiáveis usa bibliotecas WebAuthn existentes que têm acesso a uma ampla gama de algoritmos de criptografia, é mais importante observar quais algoritmos são suportados por quais autenticadores:

(*) = Pequena parte das chaves de segurança (por exemplo, Yubikeys 5+, Solokey ou Nitrokey)\nExcerto da Tabela IANA: Veja a lista completa aqui

Como você pode ver nesta tabela, para suportar todos os autenticadores importantes, RS256 e ES256 são suficientes. Há partes da comunidade que recomendam integrar também o EdDSA para melhorar ainda mais a segurança. Por outro lado, os IDs de Credencial que também precisam ser armazenados parecem ser significativamente mais longos para chaves EdDSA. Atualmente, o rascunho do Editor da W3C sobre o futuro Padrão WebAuthn de Nível 3 sugere todos os três algoritmos.

A configuração dos algoritmos de criptografia suportados para a criação de passkeys é feita através das PublicKeyCredentialCreationOptions:

const publicKeyCredentialCreationOptions = {
    challenge: "*",
    rp: {
        name: "Corbado",
        id: "corbado.com",
    },
    user: {
        id: "user-X",
        name: "user@corbado.com",
        displayName: "Corbado Name",
    },
    pubKeyCredParams: [
        {
            alg: -8,
            type: "public-key",
        },
        {
            alg: -7,
            type: "public-key",
        },
        {
            alg: -257,
            type: "public-key",
        },
    ],
    authenticatorSelection: {
        authenticatorAttachment: "platform",
        requireResidentKey: true,
    },
};
 
const credential = await navigator.credentials.create({
    publicKey: publicKeyCredentialCreationOptions,
});

O exemplo mostra como os algoritmos são especificados dentro de: pubKeyCredParams por alg para o ID e adicionando public-key como o tipo do algoritmo. Nas linhas 29/30, as PublicKeyCredentialCreationOptions são passadas para o autenticador através da API WebAuthn do navegador. Remover o suporte para ES256 ou RS256 produzirá erros e não é estritamente recomendado.

Como um exemplo funcional, vamos executar as seguintes PublicKeyCredentialCreationOptions em um Mac no Passkeys Debugger.

{
    "rp": {
        "id": "www.passkeys-debugger.io",
        "name": "Relying Party Name"
    },
    "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
    "pubKeyCredParams": [
        {
            "type": "public-key",
            "alg": -8
        },
        {
            "type": "public-key",
            "alg": -7
        },
        {
            "type": "public-key",
            "alg": -257
        }
    ],
    "excludeCredentials": [],
    "timeout": 120000,
    "authenticatorSelection": {
        "residentKey": "required",
        "requireResidentKey": true,
        "userVerification": "required",
        "authenticatorAttachment": "platform"
    },
    "hints": [],
    "attestation": "direct",
    "user": {
        "name": "User-2024-08-19",
        "displayName": "User-2024-08-19",
        "id": "LlakhOS2vobxxwdkInYP-277Atf0S5OsJax_uBCNNINk"
    }
}

A resposta produzida pelo autenticador é enviada para a parte confiável (como atestado (attestation)) e se parece com:

{
    "id": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "rawId": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "type": "public-key",
    "response": {
        "attestationObject": "o2NmbXRmcGFja2VkZ2F0dFN0bXSiY2FsZyZjc2lnWEcwRQIhAIvVNCTlYXX7WKOfeto7WyBQE6uvXpvnNy22kqrMxs_QAiAmanFqalrvD_1fe0Cb2f60ljth4nngckkKJ8JPtqZiO2hhdXRoRGF0YVikt8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADdFAAAAAK3OAAI1vMYKZIsLJfHwVQMAIGljJhOARPWc70Snfa0IXcurm65Qdwjq00RUADXusnR4pQECAyYgASFYIDP4onRKVHXlhwbmWF4V6jmfsuVuSXchGm6xoceSBGtjIlgg3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c",
        "clientDataJSON": "eyJ0eXBlIjoid2ViYXV0aG4uY3JlYXRlIiwiY2hhbGxlbmdlIjoiQUFBQmVCNzhIckllbWgxalRkSklDcl8zUUdfUk1PaHAiLCJvcmlnaW4iOiJodHRwczovL29wb3Rvbm5pZWUuZ2l0aHViLmlvIiwiY3Jvc3NPcmlnaW4iOmZhbHNlfQ",
        "transports": ["internal"],
        "publicKeyAlgorithm": -7
    },
    "authenticatorAttachment": "platform",
    "clientExtensionResults": {}
}

Na próxima seção, veremos como as chaves públicas e o algoritmo de criptografia usado podem ser extraídos da resposta.

Primeiro de tudo, precisamos examinar como o attestationObject real é construído, porque, como vemos acima, ele não é transportado em JSON para a Parte Confiável.

O attestationObject desempenha um papel importante no processo de registro do WebAuthn, servindo como um contêiner para a declaração de atestado (attestation statement) fornecida pelo autenticador. Este objeto fornece muitas informações necessárias para que a Parte Confiável (RP) verifique a origem e a integridade da credencial de chave pública recém-criada.

Em sua essência, o attestationObject é uma estrutura complexa. Ele é principalmente codificado no formato CBOR (Concise Binary Object Representation), que por sua vez é codificado com Base64URL. Ele encapsula os dados do autenticador juntamente com uma declaração de atestado (attestation) que verifica a autenticidade das informações. Como as passkeys são criadas com atestado (attestation) “none” e, portanto, não carregam uma declaração de atestado (attestation), não abordaremos isso neste artigo. Como nota lateral: escrevemos principalmente CBOR porque também existem prefixos CBOR não padrão envolvidos devido aos comprimentos variáveis necessários para as extensões opcionais. Não vamos nos aprofundar nisso; uma discussão sobre as complexidades pode ser encontrada aqui.

Extraído da especificação WebAuthn

Dentro dos dados do autenticador (authData), a chave pública recém-gerada, juntamente com o ID da credencial do usuário, são armazenados com segurança e podem ser recuperados pela parte confiável. Como os desenvolvedores devem abordar a tarefa de extrair a chave pública do attestationObject em qualquer sistema baseado em WebAuthn, entender sua arquitetura é importante.

CBOR (Concise Binary Object Representation) é um formato de dados projetado para codificar dados de maneira compacta, eficiente e extensível. É binário, o que o torna menor e mais rápido de analisar do que seu modelo baseado em texto, o JSON. O exemplo a seguir ilustra como JSON e CBOR são diferentes (Texto vs. Binário):

Negrito é Nome. Itálico é Corbado. (mais informações podem ser encontradas em https://cbor.io/)

No contexto do WebAuthn, o CBOR é usado por várias razões:

• Ligação com FIDO2 / CTAP: Como o CBOR é usado nos padrões subjacentes, a análise e o processamento de dados são simplificados, pois tanto o WebAuthn quanto o CTAP utilizam o mesmo esquema de codificação compacto.
• Compacidade: A codificação eficiente do CBOR o torna uma excelente escolha para o tráfego da web, onde minimizar o tamanho dos dados pode impactar significativamente o desempenho, especialmente em redes móveis ou em ambientes onde a largura de banda é uma restrição.
• Flexibilidade: O CBOR suporta uma variedade de tipos e estruturas de dados, incluindo arrays, mapas, strings de texto, strings de bytes e tags para extensibilidade. Isso o torna versátil o suficiente para lidar com os diferentes tipos de dados e estruturas complexas necessárias para as operações do WebAuthn.
• Extensibilidade: O formato é projetado para ser extensível, o que significa que novos recursos podem ser adicionados ao WebAuthn sem quebrar a compatibilidade com as implementações existentes.

O uso do CBOR é especialmente adequado para codificar as chaves públicas e o attestationObject porque ele precisa lidar com os diferentes formatos e comprimentos que discutimos acima. Por exemplo, uma chave RSA teria atributos e tamanhos diferentes em comparação com uma chave ECDSA. Dentro do attestationObject, as chaves públicas são armazenadas no formato COSE Key, que é baseado em CBOR.

Uma estrutura COSE Key é construída sobre um objeto de mapa CBOR. Ela define uma maneira estruturada para a representação de chaves, abrangendo vários tipos de chaves e seus parâmetros correspondentes, como o módulo e o expoente RSA, ou as coordenadas da chave pública de curva elíptica. Este formato padronizado permite que as chaves sejam serializadas e desserializadas de maneira consistente, independentemente de seu algoritmo criptográfico subjacente, além do ID do algoritmo de criptografia que discutimos acima.

Ao aproveitar o CBOR e o formato COSE Key, o WebAuthn pode facilitar uma ampla gama de operações criptográficas, garantindo que a carga útil permaneça o menor possível e permaneça adaptável para futuras atualizações na tecnologia criptográfica. Essa escolha está alinhada com os objetivos do WebAuthn de fornecer um protocolo seguro, eficiente e compatível com o futuro para autenticação na web.

Quando se trata de decodificar o attestationObject no WebAuthn, os desenvolvedores se deparam com uma decisão importante: desenvolver uma solução personalizada ou aproveitar uma biblioteca estabelecida. A complexidade e a natureza crítica deste processo não podem ser subestimadas. A implementação manual da decodificação Base64URL e CBOR, embora tecnicamente viável, introduz o risco de erros sutis que podem comprometer a integridade do processo de autenticação.

Para garantir a verificação criptográfica da assinatura, bem como a precisão de todas as outras etapas de validação, é fortemente aconselhável utilizar uma biblioteca WebAuthn bem testada e amplamente adotada. Tais bibliotecas são construídas com expertise em criptografia para lidar com os detalhes da decodificação e validação do attestationObject, incluindo:

• Análise correta do formato CBOR para extrair a declaração de atestado (attestation) e os dados do autenticador.
• Interpretação do formato COSE Key para recuperar a chave pública.
• Realização de verificações criptográficas para validar a assinatura de acordo com o padrão WebAuthn.

Ao confiar em uma biblioteca respeitável, os desenvolvedores não apenas economizam tempo e recursos, mas também ganham tranquilidade. A chave pública, uma vez extraída e verificada por meio dessas ferramentas confiáveis, pode ser armazenada com segurança no banco de dados, pronta para ser usada em sessões de autenticação seguras. Essa abordagem garante a adesão às especificações do protocolo e mantém a postura de segurança esperada nas implementações do WebAuthn. Para simplificar, usaremos o SimpleWebauthn Debugger que retorna uma versão completamente decodificada com os campos CBOR convertidos em JSON expandido:

{
    "id": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "rawId": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "type": "public-key",
    "response": {
        "attestationObject": {
            "fmt": "packed",
            "attStmt": {
                "alg": "ES256 (-7)",
                "sig": "MEUCIQCL1TQk5WF1-1ijn3raO1sgUBOrr16b5zcttpKqzMbP0AIgJmpxampa7w_9X3tAm9n-tJY7YeJ54HJJCifCT7amYjs"
            },
            "authData": {
                "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc",
                "flags": {
                    "userPresent": true,
                    "userVerified": true,
                    "backupEligible": false,
                    "backupStatus": false,
                    "attestedData": true,
                    "extensionData": false
                },
                "counter": 0,
                "aaguid": "adce0002-35bc-c60a-648b-0b25f1f05503",
                "credentialID": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
                "credentialPublicKey": "pQECAyYgASFYIDP4onRKVHXlhwbmWF4V6jmfsuVuSXchGm6xoceSBGtjIlgg3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c",
                "parsedCredentialPublicKey": {
                    "keyType": "EC2 (2)",
                    "algorithm": "ES256 (-7)",
                    "curve": 1,
                    "x": "M_iidEpUdeWHBuZYXhXqOZ-y5W5JdyEabrGhx5IEa2M",
                    "y": "3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c"
                }
            }
        },
        "clientDataJSON": {
            "type": "webauthn.create",
            "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
            "origin": "https://opotonniee.github.io",
            "crossOrigin": false
        },
        "transports": ["internal"],
        "publicKeyAlgorithm": -7
    },
    "authenticatorAttachment": "platform",
    "clientExtensionResults": {}
}

A biblioteca SimpleWebAuthn é usada para decodificar o attestationObject completo. Como podemos ver, todas as informações agora são legíveis. Todas as informações criptográficas fazem parte do credentialPublicKey, que faz parte da seção authData, que a biblioteca expandiu para a declaração parsedCredentialPublicKey. Na especificação, existem vários exemplos de como o formato COSE Key se parece.

{
    "parsedCredentialPublicKey": {
        "keyType": "EC2 (2)",
        "algorithm": "ES256 (-7)",
        "curve": 1,
        "x": "M_iidEpUdeWHBuZYXhXqOZ-y5W5JdyEabrGhx5IEa2M",
        "y": "3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c"
    }
}

Esta saída mostra todos os elementos criptográficos do credentialPublicKey devidamente analisados em formato legível por humanos. Esta instância em particular revela uma chave EC2 para o algoritmo ES256, conforme indicado pelo parâmetro do algoritmo e pela presença das coordenadas x e y.

Em contraste, a saída de um sistema Windows 10 se parece com o seguinte:

{
    "parsedCredentialPublicKey": {
        "keyType": "RSA (3)",
        "algorithm": "RS256 (-257)",
        "modulus": "mzRVwAL6jbccWT4NQ3rQWEYLkTKkEBeHPPUn0CXT8VwvvGE_IaXDeP9ZzcA7WoX3z6E0l_L-XZmRuKc9cO7BkiYyz3jOg_pNFTz5Ap9a1f_9H0m4mpL-30WHQZi1skB5f6zt8sO8q7rBYH0mRmH8LdCrhJRhVjB_UxbcAbYlpV98M5g-5OBs_boNXtMhMoyp-IOeGChp07wwSLVOH3hKMoxlU27hZ3QvK2LRWosNKhXSHcU9IOC0XOyhlZ5rtPX2ae3KsSE1H2rEJVcMaVMRAg8yx2SRM98pDvf829smrnJPdMBojKftne2j8o84i_xyDJ_jARlyVj0kxR37u0AVQQ",
        "exponent": 65537
    }
}

Aqui, o ID do algoritmo é -257, correspondendo ao RS256, e podemos discernir que os atributos que caracterizam esta chave pública divergem significativamente daqueles de uma chave ECDSA. O formato COSE Key permite especificar atributos únicos por tipo:

Além disso, o módulo RSA é substancialmente mais longo do que as coordenadas da curva elíptica usadas na chave ES256, ressaltando nossa discussão anterior sobre as diferenças nos tamanhos das chaves e os requisitos inerentes de diferentes algoritmos criptográficos.

Depois de passar pelos fundamentos da criptografia de chave pública e entender como ela é incorporada ao padrão WebAuthn / FIDO2, temos duas recomendações principais para as partes confiáveis:

• Selecione os algoritmos de criptografia corretos: Na implementação do WebAuthn, é importante usar os algoritmos corretos para máxima compatibilidade. Com base nas recomendações atuais, uma combinação de RS256, ES256 e EdDSA é aconselhável. RS256 e ES256 se destacam devido ao seu amplo suporte, e a inclusão do EdDSA pode aumentar a segurança sempre que possível.
• Use bibliotecas WebAuthn bem testadas para extrair a chave pública: Depois de decidir sobre os algoritmos, o próximo passo é integrar uma biblioteca WebAuthn bem testada. Tal biblioteca pode lidar competentemente com as complexidades da análise do attestationObject. Depois que a biblioteca extrair as chaves públicas e seus dados associados, eles podem ser armazenados com segurança no banco de dados. O formato usado pela biblioteca normalmente garante que a chave seja armazenada de uma forma que possa ser lida e utilizada com precisão para fins de autenticação futuros.

É crucial não reinventar a roda: aproveite o conhecimento coletivo incorporado em bibliotecas estabelecidas. A implementação personalizada arrisca introduzir erros e falhas de segurança que poderiam minar a eficácia da autenticação e a segurança geral do sistema.

Neste post, investigamos os fundamentos da criptografia de chave pública para responder às três perguntas centrais iniciais:

1. Algoritmos de Criptografia Suportados no WebAuthn: O WebAuthn é projetado para ser flexível e suporta uma ampla gama de algoritmos de criptografia, incluindo proeminentemente RSA (RS256), ECDSA (ES256) e EdDSA. Essa adaptabilidade permite que ele se integre perfeitamente a vários autenticadores e plataformas, garantindo ampla compatibilidade.
2. Funcionalidade do pubKeyCredParams na Criação de Pares de Chaves: O pubKeyCredParams desempenha um papel importante na fase de registro do processo WebAuthn, especificando quais algoritmos criptográficos a parte confiável suporta. Isso garante que os pares de chaves criados sejam compatíveis tanto com o autenticador do usuário quanto com os requisitos da parte confiável.
3. Funcionalidade do credentialPublicKey e Extração de Chaves Públicas: O credentialPublicKey é usado para extrair chaves públicas do attestationObject fornecido pelos autenticadores.

Além disso, destacamos a independência do protocolo WebAuthn de algoritmos de criptografia específicos, o que aumenta significativamente sua flexibilidade e preparação para o futuro contra métodos criptográficos emergentes. Esperamos que este artigo também ajude outros desenvolvedores na depuração e compreensão de conceitos / problemas relacionados à criptografia de chave pública no WebAuthn.