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.

Experiment with passkey flows in the Passkeys Debugger.

Try for Free

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.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

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

Head of Digital Channels & Platform Enablement, VicRoads

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

See how VicRoads scaled passkeys to 5M+ users — alongside their existing IDP.

Read the case study

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 (+80% de ativação de passkey). Fale com um especialista em Passkeys →