O que é Atestado no WebAuthn?

Atestado (Attestation) pode se referir a três coisas (muitas vezes, na linguagem falada, são usados de forma intercambiável, embora signifiquem algo diferente se considerados com precisão):

1. Em primeiro lugar e de forma mais geral, atestado no espaço criptográfico é um termo onde uma parte "atesta" criptograficamente uma declaração para outra parte.

2. Em segundo lugar, durante a fase de registro no WebAuthn, um objeto de atestado é criado pelo autenticador e retornado para a Relying Party. É um objeto contêiner que contém as seguintes informações:

   • formato da declaração de atestado (fmt)
   • declaração de atestado (attStmt - veja abaixo)
   • dados do autenticador (authData)

3. Em terceiro lugar, no WebAuthn, uma declaração de atestado é um elemento opcional do objeto de atestado. Esta declaração, quando incluída, verifica certas características do autenticador (dispositivo) envolvido no processo de atestado. No entanto, alguns fabricantes de dispositivos (por exemplo, a Apple) não oferecem uma declaração de atestado porque este aspecto da especificação não foi projetado para a sincronização de passkeys e falha em verificar eficazmente os atributos de segurança quando as credenciais podem ser sincronizadas entre diferentes dispositivos (por exemplo, uma passkey é criada em um iPhone, mas também usada em um MacBook, pois é sincronizada através do mesmo iCloud Keychain). Características que podem ser fornecidas quando a declaração de atestado é incluída:

   • Oferecer prova de que um dispositivo genuíno e confiável foi usado durante a autenticação.
   • Fornecer detalhes sobre a origem, modelo e outras informações pertinentes do dispositivo.
   • Aprimorar as medidas de segurança, especialmente em cenários onde a confiabilidade do dispositivo é crucial (por exemplo, em certas indústrias regulamentadas como a de saúde).

O seguinte fluxograma do processo de Registro mostra o papel do atestado (objeto) no WebAuthn:

{
    "root": {
        "id": "QFPlQVypLmmx71e0tmS3IfCFky0",
        "rawId": "QFPlQVypLmmx71e0tmS3IfCFky0",
        "response": {
            "attestationObject": {
                "fmt": "none",
                "attStmt": {},
                "authData": {
                    "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc",
                    "flags": {
                        "userPresent": true,
                        "userVerified": true,
                        "backupEligible": true,
                        "backupStatus": true,
                        "attestedData": true,
                        "extensionData": false
                    },
                    "counter": 0,
                    "aaguid": "00000000-0000-0000-0000-000000000000",
                    "credentialID": "QFPlQVypLmmx71eOtmS3IfCFky0",
                    "credentialPublicKey": "pQECAyYgASFYIEa-lpSiQ4P...",
                    "parsedCredentialPublicKey": {
                        "keyType": "EC2 (2)",
                        "algorithm": "ES256 (-7)",
                        "curve": 1,
                        "x": "Rr6WlKJDg8MlbIq9mmHQzk2p2c_s7QoNKr7yMa7I8pM",
                        "y": "tAELYp7h3sYNjZZIZgHPYiaSzF×QVT18cgZ_7wm13Vw"
                    }
                }
            },
            "clientDataJSON": {
                "type": "webauthn.create",
                "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
                "origin": "https://passkeys.eu",
                "crossOrigin": false
            },
            "transports": ["hybrid", "internal"],
            "publicKeyAlgorithm": -7
        },
        "authenticatorAttachment": "cross-platform"
    }
}

Na captura de tela acima, nenhum AAGUID e nenhuma declaração de atestado são fornecidos.

Experimente fluxos de passkeys no Passkeys Debugger.

Testar grátis

Continue lendo para uma análise técnica dos atributos mais importantes.

No WebAuthn, o atestado garante que a autenticação do usuário seja segura e transparente. Com a declaração de atestado, você pode garantir que uma credencial foi criada em um autenticador / dispositivo específico.

Esses tipos de atestado referem-se à declaração de atestado (não ao objeto de atestado). Eles são considerados como uma preferência pela relying party (portanto, o autenticador pode se comportar de maneira diferente, pois é apenas uma preferência).

• Sem Atestado (none): Para casos em que a privacidade é de extrema importância ou dispositivos sincronizados estão em uso, este tipo não fornece informações sobre o dispositivo, garantindo que a privacidade do usuário permaneça intacta. Outra razão para usar este valor pode ser para economizar uma viagem de ida e volta a uma autoridade de certificação (CA). none também é o valor padrão.
• Atestado Indireto (indirect): A relying party prefere obter um atestado, mas permite que o cliente decida como obter as declarações de atestado. O cliente pode substituir as declarações de atestado geradas pelo autenticador por declarações de atestado anônimas para proteger a privacidade do usuário.
• Atestado Direto (direct): Esta é a forma mais transparente. Aqui, a relying party informa ao autenticador que deseja uma declaração de atestado, para que a relying party obtenha informações detalhadas sobre o dispositivo, incluindo sua marca, modelo e outras especificidades. Embora ofereça a maior transparência, pode levantar preocupações com a privacidade em certos cenários ou pode não ser realmente utilizável para credenciais sincronizadas.
• Atestado Empresarial (enterprise): A relying party deseja receber uma declaração de atestado que pode incluir informações de identificação únicas. Este tipo de atestado é normalmente usado em empresas ou organizações que desejam rastrear dispositivos / autenticadores específicos. Os navegadores da web (agentes de usuário) não devem fornecer este atestado detalhado, a menos que suas configurações o permitam especificamente para a parte solicitante. Se as configurações permitirem, o navegador deve informar ao dispositivo quando for necessário (no início do processo) que este tipo específico de atestado está sendo solicitado. O navegador deve então repassar o ID exclusivo do dispositivo e a prova de atestado exatamente como os recebe para a relying party.

Assine nosso Substack de passkeys para receber as últimas novidades.

Assinar

O objeto de atestado contém muitos atributos, aqui está uma explicação rápida de alguns atributos selecionados:

"attestationObject": {
        "fmt": "none",
        "attStmt": {},
        "authData": {
          "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc",
          "flags": {
            "userPresent": true,
            "userVerified": true,
            "backupEligible": true,
            "backupStatus": true,
            "attestedData": true,
            "extensionData": false
          },
          "counter": 0,
          "aaguid": "00000000-0000-0000-0000-000000000000",
          "credentialID": "QFPlQVypLmmx71eOtmS3IfCFky0",
          "credentialPublicKey": "pQECAyYgASFYIEa-lpSiQ4P...",
          "parsedCredentialPublicKey": {
            "keyType": "EC2 (2)",
            "algorithm": "ES256 (-7)",
            "curve": 1,
            "x": "Rr6WlKJDg8MlbIq9mmHQzk2p2c_s7QoNKr7yMa7I8pM",
            "y": "tAELYp7h3sYNjZZIZgHPYiaSzF×QVT18cgZ_7wm13Vw"
          }
        }

O attestationObject é um objeto codificado em CBOR, contendo informações sobre as credenciais recém-criadas, a chave pública e outros dados relevantes:

• fmt representa o formato do atestado, pois os autenticadores podem fornecer dados de atestado de diferentes maneiras. Ele informa ao servidor como o servidor deve validar os dados de atestado. Os valores permitidos são "packed", "tpm", "android-key", "android-safetynet", "fido-u2f", "apple" ou "none". Veja detalhes aqui
• attStmt é a declaração de atestado. Para passkeys, por exemplo, em dispositivos iOS ou Android, é deixado em branco, pois as passkeys em iOS ou Android podem ser sincronizadas, e preenchido para outros dispositivos, como no Windows ou chaves de segurança de hardware.
• authData é um buffer de valores contendo os seguintes dados:
  
  Os dados de credencial atestados desempenham um papel importante aqui. Eles contêm:
  • AAGUID,
  • Comprimento do ID da Credencial,
  • ID da Credencial e
  • Chave pública da credencial.

Ao contrário do objeto de atestado acima, onde attStmt foi deixado em branco por razões de legibilidade, é assim que uma declaração de atestado preenchida se pareceria.

{
    "alg": -65535,
    "sig": "MBHX7qov53SWqqPYCrxE5fcoAeDI83a0DzVJ2-N1KI6IAaCGGvINAIFzTEn44F6giANKte-8yEMDZbvbgDG1weaRj7SqsVaTty-TEQ",
    "ver": "2.0",
    "x5c": [
        "MIIFwDCCA6oIaK6tZ7M",
        "MIIG6zCCBNpG18-MCJrHyrpMT-ul7RgxE4dFxqcG59ftTXqJ1f-X_Lpo7K-d7OgKoQrUgzxgATz8YXtFAk3rE1cHXvW9W52V637eAihKn9-UKC0ijzVXrBGX4Iq1o1M0ZfR-tFoOn498xasMCTnharKiM562GBLVJtlvV3DMSLEBl5SfuGM-qYjQgTQknXccks9guCmNaN_b2fo1DisbufXfjM3DVaMqx7IJpSc3wAnxooMrAYGpPM"
    ],
    "pubArea": "AAEACwAw_c3Ousz865mUPx8O3w",
    "certInfo": "_1RDR4AXAniCekfsiDI"
}

• alg: A propriedade alg indica o identificador do algoritmo criptográfico usado pelo autenticador para assinar a declaração de atestado.
• sig: A propriedade sig contém a assinatura digital gerada pelo autenticador. Esta assinatura é usada para verificar a autenticidade da declaração de atestado.
• ver: A propriedade ver especifica a versão do formato da declaração de atestado.
• x5c: O array x5c contém um ou mais certificados X.509 que formam um caminho de certificação, o que auxilia na validação do atestado.
• pubArea: A propriedade pubArea contém informações detalhadas sobre a chave pública e as características do autenticador.
• certInfo: A propriedade certInfo normalmente inclui informações sobre a certificação do autenticador por uma parte confiável.

"clientDataJSON": {
        "type": "webauthn.create",
        "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
        "origin": "https://www.passkeys-debugger.io",
        "crossOrigin": false
      }

Leia mais sobre clientDataJSON no respectivo artigo do glossário.

"transports": [
        "hybrid",
        "internal"
      ]

A propriedade transports indica os mecanismos através dos quais um autenticador pode se comunicar com um cliente. Algumas combinações de valores de exemplo comuns são:

• "transports": ["internal","hybrid"]: As passkeys podem ser usadas a partir do autenticador de plataforma (por exemplo, Face ID, Touch ID, Windows Hello) ou via autenticação entre dispositivos (usando código QR e Bluetooth).
• "transports": ["internal"]: As passkeys podem ser usadas a partir do autenticador de plataforma (por exemplo, Face ID, Touch ID, Windows Hello)
• Nenhuma propriedade transports definida: comportamento padrão que não fornece indicações.

O atestado (a declaração de atestado) no WebAuthn é importante, pois oferece prova da autenticidade de um autenticador. Ele garante que o processo de autenticação seja realizado por um dispositivo confiável, protegendo assim contra possíveis ameaças de segurança.

Igor Gjorgjioski

Senior Product Lead, VicRoads

We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.

Veja como a VicRoads escalou as passkeys para mais de 5M de usuários, junto ao IDP existente.

Ler o estudo de caso

Sim, como as passkeys podem ser sincronizadas entre dispositivos (por exemplo, do iPhone para o MacBook via Keychain), as relying parties não conseguem mais determinar qual dispositivo atestado está realmente fazendo login em um aplicativo ou site. Portanto, a Apple e o Google decidiram que, para passkeys sincronizadas, não fornecerão mais declarações de atestado. No entanto, para melhorar a UX para as relying parties e dar-lhes a oportunidade de reconhecer e exibir passkeys dos ecossistemas da Apple e do Google (iCloud Keychain e Google Password Manager), o AAGUID ainda será fornecido (desde que o atestado seja definido como direct ou indirect nas configurações do servidor WebAuthn para as PublicKeyCredentialCreationOptions. Veja esta issue do GitHub para detalhes.

Se você deseja integrar a autenticação com passkeys em seu site e aplicativo, e quer oferecer aos seus usuários uma ótima UX de passkeys, você deve considerar o seguinte. Assumimos que você está construindo sua solução principalmente para um cenário onde a maioria dos seus usuários usa um sistema operacional Windows, iOS, macOS ou Android. Além disso, assumimos que a maioria das passkeys (além do Windows) são passkeys sincronizadas. Como nem o iOS, macOS nem o Android enviam mais uma declaração de atestado, a validação real de um autenticador não é mais usada (para o Windows isso ainda funciona, provavelmente porque o Windows ainda não oferece passkeys sincronizadas via Windows Hello). No entanto, para obter o AAGUID, por exemplo, para um melhor gerenciamento de passkeys nas configurações da conta, recomendamos definir a preferência de atestado como indirect, pois isso ainda permitiria obter o AAGUID enquanto a declaração de atestado é enviada (Windows) ou não (iOS, macOS, Android).

O serviço de metadados FIDO fornece um repositório de metadados para vários autenticadores. Durante o atestado, este serviço pode ser consultado para buscar e validar detalhes sobre o autenticador, garantindo a precisão e aumentando a confiabilidade do processo. O serviço de metadados FIDO verifica a declaração de atestado (não o objeto de atestado).

Sim, o atestado direto (na declaração de atestado), embora ofereça a maior transparência ao fornecer informações detalhadas sobre o dispositivo, pode levantar preocupações com a privacidade em certos cenários. É crucial avaliar a necessidade de transparência versus privacidade ao escolher o tipo de atestado.

O WebAuthn oferece diferentes tipos de preferências de atestado – nenhum, indireto, direto e empresarial. Para cenários onde a privacidade do usuário é importante, attestation=none pode ser empregado, o que não fornece detalhes sobre o dispositivo, garantindo que a privacidade do usuário permaneça protegida.

Sobre a Corbado

Corbado é a Passkey Intelligence Platform para times de CIAM que rodam autenticação consumer em escala. Mostramos o que logs de IDP e ferramentas genéricas de analytics não enxergam: quais dispositivos, versões de SO, navegadores e gerenciadores de credenciais suportam passkeys, por que os registros não viram logins, onde o fluxo WebAuthn falha e quando uma atualização de SO ou navegador quebra silenciosamente o login, tudo sem substituir Okta, Auth0, Ping, Cognito ou seu IDP interno. Dois produtos: Corbado Observe adiciona observabilidade para passkeys e qualquer outro método de login. Corbado Connect entrega passkeys gerenciados com analytics integrado (junto ao seu IDP). VicRoads roda passkeys para mais de 5M de usuários com Corbado (mais de 80% de taxa de ativação de passkey). Fale com um especialista em Passkeys →