New: Passkey Benchmark 2026 - 8 production KPIs to compare your passkey rolloutcompare your passkey rollout
Voltar à visão geral

Chaves de acesso vinculadas ao dispositivo vs. sincronizadas (SCA e chaves de acesso I)

Explore chaves de acesso sincronizadas e vinculadas ao dispositivo, suas diferenças e o papel dos módulos de segurança de hardware (Secure Enclave, TEE, TPM).

Vincent Delitz
Vincent Delitz

Criado: 15 de abril de 2024

Atualizado: 24 de maio de 2026

Chaves de acesso vinculadas ao dispositivo vs. sincronizadas (SCA e chaves de acesso I)

Esta página foi traduzida automaticamente. Leia a versão original em inglês aqui.

WhitepaperBanking Icon

Relatório de Passkeys para bancos. Guias práticos, padrões de implementação e KPIs para programas de passkeys.

Obter o relatório

Visão geral: Autenticação forte de clientes com chaves de acesso#

  • Análise dos requisitos da PSD2 e SCA
  • O que os requisitos de SCA significam para as chaves de acesso
  • Implicações da PSD3 / PSR para as chaves de acesso

1. Introdução: Chaves de acesso vinculadas ao dispositivo vs. sincronizadas#

No nosso post anterior sobre chaves de acesso e PSD2, discutimos como as chaves de acesso já estão sendo usadas por fintechs como Revolut e Finom e como elas melhoram a segurança digital no setor bancário.

As chaves de acesso vêm em dois formatos principais: chaves de acesso sincronizadas e chaves de acesso vinculadas ao dispositivo. Enquanto as chaves de acesso sincronizadas permitem que os usuários se autentiquem de forma contínua em vários dispositivos, as chaves de acesso vinculadas ao dispositivo estão estritamente ligadas a um dispositivo de chave de acesso, como uma chave de segurança de hardware ou um autenticador local.

Com esta série de quatro artigos, queremos analisar detalhadamente como os diferentes tipos de chaves de acesso (vinculadas ao dispositivo vs. sincronizadas) cumprem os requisitos de SCA e PSD2.

Esta primeira parte da série visa entender a diferença entre chaves de acesso vinculadas ao dispositivo e sincronizadas.

A segunda parte explica o que significa a PSD2 e a Autenticação Forte de Clientes (SCA) de forma compreensível, expondo também o seu desenvolvimento histórico.

A terceira parte da série mostra como os diferentes tipos de chaves de acesso cumprem a SCA e o que isso significa para bancos, fintechs e instituições financeiras que pensam em adotar chaves de acesso.

A quarta e última parte da série conclui o que a PSD3 / PSR significará para a SCA e as chaves de acesso no futuro.

2. Autenticação forte de clientes, PSD2 e chaves de acesso#

Após a publicação do nosso último post, recebemos muitas perguntas de acompanhamento sobre a nossa posição em relação às chaves de acesso, especificamente em relação à SCA no âmbito da estrutura da PSD2. Existe um interesse claro em entender não apenas a aplicação das chaves de acesso, mas também como elas se alinham com as Normas Técnicas Regulamentares (RTS). Além disso, as partes interessadas estão curiosas sobre as possíveis interpretações e orientações de reguladores, incluindo a Autoridade Bancária Europeia (EBA), sobre o uso de chaves de acesso.

Reconhecendo isso, pretendemos aprofundar como as chaves de acesso podem ser integradas na diretiva PSD2, nas RTS sobre a SCA, e fornecer clareza sobre nossa posição em relação ao uso dessa tecnologia. Também exploraremos as perguntas e respostas existentes da EBA para esclarecer como os reguladores e a EBA podem perceber as chaves de acesso. Esta análise não apenas abordará as distinções entre chaves de acesso sincronizadas e vinculadas ao dispositivo, mas também suas aplicações práticas na melhoria da segurança e da experiência do usuário.

Igor Gjorgjioski Testimonial

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

Ao compreender as nuances, as partes interessadas podem tomar decisões informadas que não só cumprem os rigorosos requisitos da PSD2, mas também aproveitam a mais recente tecnologia de autenticação para proteger as transações digitais. A nossa discussão visa iluminar ainda mais o caminho para a integração de chaves de acesso nos processos de autenticação, garantindo que as medidas de segurança acompanhem o cenário digital em evolução.

Obviamente, toda entidade regulamentada que se enquadra na PSD2 precisa tomar suas próprias decisões sobre como cumprir as metas regulatórias, já que cada implementação tem suas próprias complexidades. Esta abordagem individual reconhece que, embora o quadro regulamentar forneça um padrão uniforme, a aplicação prática destas normas variará significativamente entre diferentes organizações devido aos seus ambientes operacionais, capacidades tecnológicas e bases de usuários únicos.

Assim, embora os nossos insights tenham como objetivo orientar e informar, não são prescritivos. Cada entidade deve considerar as suas circunstâncias e desafios específicos ao integrar chaves de acesso nos seus protocolos de segurança e autenticação.

3. Das chaves de acesso vinculadas ao dispositivo às chaves de acesso sincronizadas#

Para entender a diferenciação entre chaves de acesso vinculadas ao dispositivo e sincronizadas, exploraremos brevemente como o ecossistema se desenvolveu.

3.1 O que são chaves de acesso vinculadas ao dispositivo (chaves de acesso de dispositivo único)?#

Começamos olhando para a história e a evolução das chaves de acesso vinculadas ao dispositivo antes de examinar mais a fundo seus detalhes técnicos.

3.1.1 História das chaves de acesso vinculadas ao dispositivo#

Historicamente, os mecanismos de autenticação do WebAuthn (o padrão subjacente às chaves de acesso) estavam fortemente acoplados a dispositivos físicos: chaves de segurança (por exemplo, YubiKeys). Antes da ampla adoção das chaves de acesso, as credenciais FIDO2 vinculadas a um único autenticador representavam o padrão-ouro em segurança. Estas credenciais estão ligadas ao dispositivo em que residem. A implicação desta vinculação foi significativa: a credencial não podia ser transferida ou utilizada fora do seu hardware original.

Esta abordagem, embora aumentasse a segurança ao localizar o processo de autenticação num único dispositivo, inevitavelmente encontrou limitações práticas que afetaram a sua ampla adoção, especialmente entre os consumidores gerais não técnicos. Os usuários eram forçados a ter o seu dispositivo de autenticação disponível para cada tentativa de login, o que não só limitava a mobilidade do usuário, como também levantava preocupações em cenários onde o dispositivo era perdido, danificado ou não estava imediatamente acessível.

Além disso, também havia relutância dos consumidores em investir em hardware adicional. Historicamente, a propriedade e a utilização de chaves de segurança dedicadas têm sido muito baixas entre os consumidores gerais. A perspectiva de comprar hardware especializado para fins de autenticação, apesar dos seus benefícios de segurança aprimorados, não teve boa aceitação pela maioria dos usuários B2C, que ao mesmo tempo são geralmente os alvos de amplas campanhas de phishing ou ataques de preenchimento de credenciais (credential stuffing).

Substack Icon

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

Assinar

3.1.2 Detalhes técnicos das chaves de acesso vinculadas ao dispositivo#

As chaves de acesso vinculadas ao dispositivo caracterizam-se pela sua categorização específica em credenciais detectáveis e não detectáveis, uma distinção que define principalmente a sua capacidade de detecção. Mas o fator chave que distingue as chaves vinculadas ao dispositivo está encapsulado nas propriedades da credencial WebAuthn, particularmente através dos sinalizadores isBackupEligible e isBackupSynchronized. Para chaves de acesso vinculadas ao dispositivo, ambos os campos são definidos como zero, indicando que as credenciais não são elegíveis para backup ou sincronização entre dispositivos. Estas características sublinham a sua ligação intrínseca ao dispositivo físico onde foram criadas, garantindo que a credencial permanece ligada a esse hardware específico e utilizável apenas nele.

Um exemplo notável de credenciais vinculadas ao dispositivo na prática é observado no ecossistema Windows. As credenciais do Windows Hello no Windows 10 e Windows 11 permanecem vinculadas ao dispositivo — o próprio Windows Hello ainda não sincroniza as chaves de acesso entre dispositivos. No entanto, a Microsoft deu um primeiro passo significativo ao introduzir a funcionalidade de salvar e sincronizar chaves de acesso no Microsoft Edge (a partir do Edge 142). Essa sincronização no nível do navegador por meio do Microsoft Password Manager permite que as chaves de acesso sejam sincronizadas entre dispositivos Windows ao usar o Edge, de forma semelhante a como o Google Password Manager permite a sincronização de chaves de acesso no navegador Chrome no Windows. Isto representa um avanço importante nos recursos de chaves de acesso do Windows, embora seja específico para o navegador Edge, em vez do autenticador de plataforma Windows Hello. As chaves de acesso do Windows Hello permanecem vinculadas ao dispositivo, mas esta integração do Edge fornece um caminho prático em direção a chaves de acesso sincronizadas no Windows, enquanto o próprio autenticador da plataforma pode evoluir para oferecer suporte à sincronização no futuro.

Por outro lado, o Google articulou uma postura clara em relação a chaves de acesso não detectáveis, indicando que as chaves de acesso não detectáveis existentes poderão permanecer não sincronizadas em implementações futuras. Essa decisão alinha-se com o princípio mais amplo de que credenciais não detectáveis desempenham um papel crucial em determinados contextos de segurança, permanecendo estritamente vinculadas ao dispositivo e, por não serem detectáveis, não podem ser usadas como chaves de acesso.

Em contraste, a abordagem adotada pela Apple com o macOS e iOS difere significativamente. Ao contrário da estratégia fixa e vinculada ao dispositivo observada com o Windows e as chaves não detectáveis do Google, o ecossistema da Apple tem uma tendência muito mais forte de permitir apenas chaves de acesso sincronizadas, especialmente no iOS, tornando assim impossível criar uma chave de acesso vinculada ao dispositivo via WebAuthn.

Esta segmentação de estratégias nas principais plataformas ilustra as diversas abordagens à gestão de credenciais WebAuthn, especialmente ao considerar o equilíbrio entre segurança, conveniência e acessibilidade do usuário. Embora as chaves de acesso vinculadas ao dispositivo ofereçam um elevado nível de segurança ao garantir que as credenciais não possam ser movidas ou mal utilizadas fora do seu dispositivo pretendido, a indústria continua a evoluir, buscando soluções que mantenham os padrões de segurança sem comprometer a experiência e a mobilidade do usuário.

3.2 O que são chaves de acesso sincronizadas (chaves de acesso de vários dispositivos)?#

Aqui também, damos uma olhada no desenvolvimento histórico das chaves de acesso sincronizadas antes de analisar os detalhes técnicos. Às vezes, as chaves de acesso sincronizadas também são chamadas de chaves de acesso sincronizáveis.

3.2.1 História das chaves de acesso sincronizadas#

Após a publicação das especificações WebAuthn Level 2 e CTAP 2.1 em meados do final de 2021, o grupo de trabalho WebAuthn lançou uma iniciativa significativa na indústria visando superar os principais obstáculos que impediam a capacidade do padrão WebAuthn de substituir senhas e aumentar a adoção. Esta iniciativa concentrou-se em duas áreas críticas: eliminar o requisito de dispositivos de segurança de hardware adicionais e mitigar o risco associado à perda do autenticador, mantendo ao mesmo tempo total compatibilidade com os padrões existentes.

3.2.1.1 Utilização de autenticadores de plataforma como módulos de hardware seguros#

O primeiro desafio — erradicar a necessidade de novo hardware — foi resolvido através da utilização de autenticadores de plataforma integrados encontrados em dispositivos de consumo modernos (por exemplo, Touch ID, Face ID, Windows Hello).

Os dispositivos modernos estão cada vez mais equipados com módulos de segurança especializados, como o Trusted Execution Environment (TEE) no Android, o Secure Enclave no iOS e macOS, e o Trusted Platform Module (TPM) nos dispositivos Windows. Estes repositórios de chaves de segurança essenciais servem como uma base sólida para as chaves de acesso, funcionando efetivamente como "chaves de segurança" integradas. Essa abordagem permite a adoção generalizada de criptografia de chave pública, um nível de segurança anteriormente alcançável apenas através de chaves de segurança de hardware externas (por exemplo, YubiKeys), e amplamente restrito a indivíduos com conhecimentos técnicos ou organizações de setores altamente regulamentados.

Ao aproveitar as capacidades do TEE, Secure Enclave ou TPM, os protocolos WebAuthn são capacitados para fornecer mecanismos de autenticação de usuários fortes e criptográficos. Agora, métodos sofisticados de autenticação tornam-se fáceis de usar e acessíveis ao público em geral, sem a necessidade de hardware especializado adicional.

Esta evolução é uma melhoria muito forte na abordagem à segurança digital, enfatizando o papel crítico que as soluções de segurança centradas no usuário desempenham na promoção de uma adoção generalizada. Organizações que combinam chaves de acesso sincronizadas com fluxos otimizados de criação e login de chaves de acesso observam as taxas de adoção mais altas. Ao usar recursos de segurança de dispositivos contemporâneos, o esforço da indústria resolveu com sucesso o obstáculo inicial de remover a necessidade de hardware externo.

Este desenvolvimento foi um passo crucial em uma nova era do ecossistema de autenticação digital, onde a ampla aplicação da criptografia de chave pública torna-se diretamente aplicável a uma ampla gama de casos de uso e, ao mesmo tempo, simplifica a autenticação para os usuários.

3.2.1.2 Sincronização de chaves de acesso na nuvem#

A fim de enfrentar o risco associado à perda do celular e, por extensão, das chaves de acesso nele armazenadas, a iniciativa do setor concentrou-se em permitir a sincronização de credenciais detectáveis na nuvem. Esta abordagem efetivamente transformou as credenciais, que deixaram de ser estritamente vinculadas ao dispositivo para se tornarem utilizáveis em vários dispositivos e, mais precisamente, vinculadas à conta do usuário no seu provedor de nuvem, como o iCloud para dispositivos Apple ou o Google para dispositivos Android.

Essa solução prática significou que mesmo que o telefone do usuário fosse perdido ou substituído, as credenciais estabelecidas anteriormente não seriam permanentemente perdidas. Em vez disso, essas credenciais poderiam ser recuperadas da conta de nuvem do usuário e sincronizadas com um novo dispositivo. Essa mudança reduziu significativamente os inconvenientes e os riscos de segurança anteriormente associados à perda de um autenticador físico.

Ao aproveitar a sincronização em nuvem, as chaves de acesso podem agora transitar de forma contínua entre os dispositivos de um usuário, mantendo a sua integridade e segurança independentemente do dispositivo específico em uso. Por exemplo, quando um usuário faz login em um site a partir de um novo dispositivo, as credenciais disponíveis em sua conta de nuvem podem ser sugeridas automaticamente para autenticação. Se necessário, essas credenciais podem ser transmitidas para o novo dispositivo, mantendo uma experiência de autenticação consistente e segura em diferentes plataformas e dispositivos.

Esta transição para credenciais vinculadas a contas e sincronizadas na nuvem representa uma abordagem pragmática da segurança digital. Ela reconhece a realidade do uso de dispositivos modernos e a ocorrência comum de trocas de dispositivos, seja por perda, dano ou atualização. Ao vincular credenciais à conta de nuvem do usuário – seja no iCloud da Apple ou nos serviços de nuvem do Google – a solução não apenas mitiga o risco associado à perda de um dispositivo, mas também melhora a capacidade do usuário de gerenciar e recuperar a sua identidade digital em vários dispositivos.

Este desenvolvimento amplia efetivamente a aplicabilidade dos mecanismos de autenticação forte e criptográfica do WebAuthn, tornando-os mais adaptáveis a cenários reais dos usuários. Também garante que uma autenticação forte seja acessível e gerenciável não apenas para aqueles com formação técnica ou para os que estão em setores altamente regulamentados, mas para o usuário comum navegando no mundo digital com vários dispositivos.

Por que as chaves de acesso são importantes?

Chaves de acesso para empresas

Senhas e phishing colocam as empresas em risco. As chaves de acesso oferecem a única solução MFA que equilibra segurança e UX. Nosso whitepaper aborda a implementação e o impacto nos negócios.

Chaves de acesso para empresas

Baixar whitepaper gratuito

3.2.2 Detalhes técnicos das chaves de acesso sincronizadas#

As chaves de acesso sincronizadas também são conhecidas como credenciais detectáveis ou chaves residentes. Estas distinguem-se das chaves vinculadas ao dispositivo por duas propriedades críticas: isBackupEligible e isBackedUp possuem valores diferentes. Para chaves de acesso sincronizadas, o sinalizador isBackupEligible é definido como 1, indicando que essas credenciais são elegíveis para backup. Após a sincronização bem-sucedida para a nuvem, o sinalizador isBackedUp também é definido como 1, confirmando que a credencial foi devidamente sincronizada. É importante observar que o status da sincronização pode mudar com o tempo, refletindo a natureza dinâmica do uso e da gestão de dispositivos.

Quando as plataformas solicitam chaves residentes, definindo o parâmetro "requireResidentKey" como required ou preferred, as plataformas que suportam serviços de nuvem criam automaticamente chaves de acesso sincronizadas. Este processo garante que os usuários possam confiar que as suas credenciais estarão acessíveis em seus vários dispositivos. No Windows, as chaves de acesso sincronizadas estão agora disponíveis por meio do Microsoft Edge/Microsoft Password Manager (sincronização no nível do navegador), enquanto as credenciais do autenticador da plataforma Windows Hello permanecem vinculadas ao dispositivo. Gerenciadores de senhas de terceiros (por exemplo, Dashlane, KeePassXC, 1Password) com recursos de gestão de chaves de acesso também fornecem sincronização em várias plataformas. Em cenários em que chaves de acesso sincronizadas são usadas, os sinalizadores isBackupEligible e isBackedUp são definidos como 1, indicando elegibilidade para backup e sincronização bem-sucedida.

Além disso, embora atualmente ainda seja possível identificar o autenticador específico onde a chave de acesso foi armazenada, a ausência de atestado para a maioria destas credenciais significa que a sua origem não pode ser verificada criptograficamente. Este aspecto destaca uma possível limitação na garantia da linhagem de segurança de chaves de acesso sincronizadas unicamente por meio dos mecanismos padrão do WebAuthn.

Este desenvolvimento em chaves de acesso sincronizadas amplia essencialmente o escopo de credenciais detectáveis ao integrá-las num framework de sincronização baseada em nuvem. Ao tornar essas chaves elegíveis para backup e garantir a sua sincronização entre os dispositivos de um usuário, o WebAuthn aborda dois dos principais desafios na autenticação digital: o risco de perda de acesso devido à perda de dispositivos e o inconveniente de gerenciar múltiplas credenciais vinculadas ao dispositivo.

3.3 Vínculo a dispositivo único de credenciais WebAuthn sacrificado em prol de um bem maior#

A transição de chaves de acesso vinculadas ao dispositivo para sincronizadas iniciou um diálogo crítico no grupo de trabalho WebAuthn, centrado na necessidade de medidas de segurança avançadas, nas questões legais envolvidas e em um compromisso que fosse fácil para o consumidor e seguro.

A adoção de chaves de acesso sincronizadas foi celebrada pela sua promessa de melhorar a conveniência e a segurança do usuário através de recursos como sincronização na nuvem e funcionalidade contínua em vários dispositivos. No entanto, introduziu algum desconforto entre algumas partes dependentes (RPs - Relying Parties), especialmente em relação às implicações para a segurança e conformidade em ambientes com requisitos elevados. A essência do debate foi a exigência de um mecanismo que garantisse que mesmo as chaves de acesso sincronizadas mantivessem uma conexão com dispositivos específicos, um conceito crucial para as partes dependentes que lidam com transações sensíveis ou operam sob padrões regulatórios rigorosos.

Para os RPs incapazes ou não dispostos a adotar chaves de acesso, a ausência de um método confiável para vincular estas credenciais a dispositivos específicos em aplicações críticas representava um desafio significativo. Um mecanismo assim foi considerado muito importante por alguns RPs. A falta dessa capacidade de vinculação ao dispositivo, uma expectativa que talvez não tenha sido declarada explicitamente, mas que certamente era esperada, representou uma surpresa séria e uma quebra de confiança da sua perspectiva.

A discussão concluiu que deveria haver uma harmonização de interesses, mas primeiramente o bem maior de disseminar as chaves de acesso deveria prevalecer. Na discussão, a extensão devicePubKey foi vista como uma forma de resolver essas preocupações, mas depois foi substituída por supplementalPubKeys que adotam uma abordagem muito mais ampla no rascunho atual do WebAuthn Level 3. Infelizmente, esta abordagem também foi descontinuada em agosto de 2024.

3.4 O melhor de dois mundos: Chaves de acesso e extensão supplementalPubKeys [descontinuada a partir de agosto de 2024]#

Vamos analisar como foi formado o compromisso com a extensão supplementalPubKeys e o que isso significa tecnicamente.

3.4.1 Da extensão devicePubKey para a extensão supplementalPubKeys#

A discussão em torno da transição da extensão devicePubKey para a extensão supplementalPubKeys destaca a natureza dinâmica da especificação WebAuthn. Inicialmente, a devicePubKey serviu para aprimorar a segurança através de chaves públicas vinculadas ao dispositivo, mas mais tarde foi substituída pela sugestão da supplementalPubKeys no rascunho de trabalho do editor do WebAuthn Level 3. Esta extensão mais recente oferece uma solução mais abrangente, permitindo múltiplas chaves para aprimorar os processos de autenticação.

O cerne do debate centrou-se em equilibrar as medidas de segurança aprimoradas com a adoção mais ampla e a utilidade prática das chaves de acesso em diferentes dispositivos e plataformas. A extensão supplementalPubKeys representa uma combinação destas prioridades, permitindo uma autenticação mais rigorosa. Por exemplo, acomoda regulamentações que exigem determinados padrões de autenticação, permitindo "sub-chaves" adicionais com declarações de atestado. Estas chaves podem sinalizar a conformidade com os requisitos de autenticação, potencialmente reduzindo a necessidade de desafios de login adicionais sob certas condições (mesmo com chaves de acesso).

Um exemplo diretamente do rascunho do WebAuthn:

Digamos que um pedido de login aparece num site com algum sinal de geolocalização que não foi visto antes para a conta deste usuário, e está fora das horas normais de utilização observadas para a conta. O risco pode ser considerado elevado o suficiente para não permitir o pedido, mesmo com uma afirmação por uma credencial multi-dispositivo por si só. Mas se uma assinatura de uma chave suplementar que é vinculada ao dispositivo, e que está bem estabelecida para este usuário também pode ser apresentada, então isso pode inclinar a balança.”

Durante a discussão, foi sublinhado que estas destinavam-se apenas a RPs com requisitos de segurança extremamente altos (por exemplo, no contexto do setor público).

Ao incorporar feedback e resolver casos de uso específicos — incluindo também transações financeiras regulamentadas e a necessidade de sinais vinculados ao dispositivo num ambiente de credenciais para vários dispositivos — a comunidade WebAuthn visava resolver preocupações tanto de segurança como de interoperabilidade. A extensão supplementalPubKeys é, portanto, uma abordagem que procura fornecer recursos robustos de segurança ao mesmo tempo em que oferece suporte a uma experiência de usuário perfeita e ampla compatibilidade essencial para a adoção generalizada das chaves de acesso. Trata-se de uma extensão completamente opcional que não interfere na implementação das chaves de acesso observada nos últimos 2 anos.

Esta evolução em direção a uma estrutura mais inclusiva e flexível sublinha o compromisso da comunidade WebAuthn em melhorar os métodos de autenticação na web mesmo em casos de uso mais rigorosos.

3.4.2 Detalhes técnicos da supplementalPubKeys#

A extensão supplementalPubKeys introduzida no WebAuthn permite a utilização de pares de chaves adicionais ao lado da credencial primária.

Tirado do issue original do GitHub

A imagem mostra o conceito de supplementalPubKey tirado do issue original do GitHub (pk = passkey, pspk=provider supplemental key, dspk = device supplemental key).

Aqui está um resumo de como funciona e do seu uso pretendido:

Propósito e funcionalidade da supplementalPubKey

  • Uma credencial central de chave de acesso permanece: É importante ter em mente que apenas uma chave de acesso central continua sendo o método primário de autenticação de usuário, e as chaves adicionais fornecem camadas extras de segurança e garantia. Esta estrutura mantém a simplicidade e a eficiência de utilizar uma única chave de acesso principal para autenticação em vários dispositivos, garantindo uma experiência contínua ao usuário. As chaves suplementares, por sua vez, servem para aprimorar o contexto da autenticação, oferecendo à Parte Dependente (RP) sinais adicionais sobre o ambiente de segurança ou conformidade com padrões específicos de autenticação. Estas chaves suplementares não são métodos de autenticação autônomos, mas sim aumentam a chave de acesso principal, reforçando a sua fiabilidade com evidências da integridade do dispositivo.
  • Chaves vinculadas ao dispositivo: Estas estão ligadas especificamente a um dispositivo. Elas podem fornecer garantias de que um pedido de autenticação é proveniente de um dispositivo confiável que foi autenticado anteriormente. Elas não serão sincronizadas em nenhuma circunstância.
  • Chaves vinculadas ao provedor: Estas chaves têm um escopo de "provedor", o que significa que podem oferecer garantias adicionais com base nas políticas do provedor de autenticação ou no atestado específico do provedor. Por exemplo, um provedor pode emitir tal chave apenas depois de um usuário ter concluído um nível mais alto de autenticação (como 2FA).
  • Várias chaves públicas: Ao contrário do seu predecessor, a extensão devicePubKey, que permitia apenas uma chave pública vinculada ao dispositivo, as supplementalPubKeys permitem a inclusão de um ou dois tipos de chaves suplementares. Estas chaves podem servir a diferentes propósitos e escopos – nomeadamente, escopos vinculados ao dispositivo e vinculados ao provedor.

Casos de uso e exemplos de supplementalPubKey

  1. Segurança aprimorada: Em situações em que um site (parte dependente) deve aderir a determinados padrões aprimorados de segurança para autenticação, as chaves suplementares podem ser usadas para atender a esses requisitos. Se essa chave suplementar foi vista e verificada pelo site antes, ela pode permitir que o usuário ignore desafios de login adicionais, uma vez que a continuidade do dispositivo pode ser confirmada por sinais anteriores.
  2. Gestão de riscos: Para pedidos de login que parecem arriscados (por exemplo, provenientes de uma nova geolocalização ou em horários incomuns), a presença de uma chave suplementar vinculada ao dispositivo que tenha um histórico de uso com a conta do usuário pode reduzir o risco percebido e permitir que o pedido continue onde, de outra forma, poderia ter sido bloqueado.

Aspectos técnicos da supplementalPubKey

  • Sem ID de credencial próprio: Chaves suplementares não são credenciais de usuário e não possuem os seus próprios IDs de credencial.
  • Declarações de atestado: As chaves suplementares podem, opcionalmente, ter um atestado. Estes são cruciais para compreender o escopo e o nível de segurança das chaves suplementares. Um atestado pode indicar o nível de proteção de que desfruta uma chave vinculada ao hardware ou as políticas para outros tipos de chaves suplementares.
  • Implementação para partes dependentes: As partes dependentes podem solicitar estas chaves suplementares como parte do processo de autenticação. Contudo, a complexidade de lidar com várias chaves e declarações de atestado significa que esta extensão é mais adequada para entidades com necessidades específicas de segurança, como bancos ou serviços operando sob rigorosos requisitos regulatórios.

É crucial notar que, até abril de 2024, a extensão supplementalPubKeys não havia sido adotada por nenhum navegador importante, e a especificação do WebAuthn Level 3 ainda estava em desenvolvimento e sujeita a alterações. Se este recurso seria incluído na versão final da especificação, e a sua possível implementação e adoção futura, permaneciam incertos, visto que na época encontrava-se apenas no rascunho do editor (Editor’s Draft).

3.4.3 Descontinuação da supplementalPubKeys em agosto de 2024#

Em agosto de 2024, a extensão supplementalPubKeys foi oficialmente descontinuada. O grupo de trabalho WebAuthn decidiu remover esta funcionalidade devido a suporte insuficiente. A descontinuação desta extensão também destaca uma nova direção. Atualmente, a FIDO Alliance está trabalhando no desenvolvimento de uma abordagem diferente para apoiar Partes Dependentes com altos requisitos de segurança. Espera-se que esta solução futura aborde as lacunas deixadas pela descontinuação de supplementalPubKeys e ofereça novos métodos para fortalecer os processos de autenticação em cenários onde normas rigorosas de segurança são essenciais.

Para mais detalhes sobre a descontinuação, veja a publicação oficial WebAuthn GitHub pull request.

4. Como a Corbado lida com as diferenças de chaves de acesso vinculadas ao dispositivo vs. sincronizadas na prática#

Compreender as diferenças entre as chaves de acesso vinculadas ao dispositivo e sincronizadas é essencial, mas os bancos também precisam de ferramentas para operacionalizar essas diferenças em escala. A plataforma da Corbado fornece inteligência de confiança do dispositivo que classifica automaticamente os tipos de chaves de acesso e aplica o tratamento de SCA adequado a cada um.

Visibilidade da confiança do dispositivo em todos os tipos de chaves de acesso#

O painel de controle (dashboard) de Device Trust da Corbado mostra como as chaves de acesso vinculadas ao dispositivo e as sincronizadas têm desempenhos diferentes na produção. As chaves vinculadas ao dispositivo alcançam taxas de sucesso mais elevadas (99,1%) com zero requisitos de etapa adicional (step-up), enquanto as chaves de acesso sincronizadas com sinais de confiança do dispositivo alcançam 98,4% com uma pequena taxa de verificação adicional para novos dispositivos.

O painel de controle também rastreia a classificação do dispositivo — identificando quais dispositivos são exclusivos a um único usuário (92% em implementações típicas do setor bancário), quais são compartilhados entre dois usuários (7%) e quais são dispositivos compartilhados/quiosque (0,8%). Essa classificação alimenta diretamente as decisões de conformidade de SCA.

Controle baseado em políticas para diferentes cenários de chaves de acesso#

Em vez de tratar todas as chaves de acesso da mesma forma, as políticas de confiança da Corbado permitem que os bancos apliquem diferentes regras baseadas no tipo de chave de acesso, status do dispositivo e nível de confiança. Chaves de acesso vinculadas a dispositivos conhecidos obtêm autenticação sem atrito, enquanto chaves de acesso sincronizadas em novos dispositivos acionam verificação adicional — exatamente o tipo de abordagem com nuances que a estrutura de SCA da PSD2 exige.

Isto significa que os bancos podem implementar com confiança chaves de acesso sincronizadas para uma melhor experiência do usuário, mantendo ao mesmo tempo o controle rígido de dispositivos que as chaves de acesso vinculadas ao dispositivo proporcionam para cenários de alta segurança — tudo gerido através da configuração de políticas, em vez de fluxos de autenticação separados.

Posição da Corbado sobre a PSD2/SCA e Chaves de acesso: As chaves de acesso (tanto vinculadas ao dispositivo como sincronizadas) podem ser compatíveis com a SCA. Cada instituição deve ser a dona da sua avaliação de risco de SCA, mas a evidência é clara: as chaves de acesso fornecem inerentemente dois fatores de SCA - posse (chave privada em módulo de segurança de hardware ou chaveiro na nuvem) + inerência (biométrica) ou conhecimento (PIN). O debate sobre a "posse" tem nuances, mas é solúvel - a indústria está caminhando para três abordagens: (1) Chaves de acesso como são (por exemplo, Revolut, Finom) - inerência + posse por meio do dispositivo com a chave privada, (2) Chaves de acesso + vinculação de cookies/sessão (por exemplo, PayPal, Comdirect) - sinal de posse extra para interpretação conservadora, (3) Vinculação criptográfica (DBSC/DPoP) - prova de posse vinculada a hardware, garantia mais forte. Ainda não existe uma única interpretação "correta". Uma abordagem baseada nos resultados em relação à SCA é necessária - concentrando-se na resistência ao phishing demonstrável em vez de na categorização rígida de fatores. A vinculação dinâmica (Dynamic linking) permanece um requisito separado para pagamentos mesmo com chaves de acesso.

Corbado

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

Perguntas Frequentes#

Como as chaves de acesso vinculadas ao dispositivo aumentam a segurança?#

As chaves de acesso vinculadas ao dispositivo são credenciais WebAuthn estritamente ligadas ao dispositivo onde foram criadas. Ao contrário das chaves de acesso sincronizadas, elas permanecem em um único dispositivo, tornando-as inerentemente mais seguras para determinados casos de uso:

  • Sem roubo de credenciais: A chave privada nunca sai do dispositivo, então os invasores não podem interceptar as credenciais.
  • Prevenção de acesso não autorizado: A autenticação só ocorre a partir do dispositivo específico onde a chave de acesso foi criada.
  • Sem dependência da nuvem: Elimina os riscos associados a violações de dados na nuvem ou apropriação de contas.
  • Alta conformidade de segurança: Atende a requisitos rigorosos de autenticação vinculada ao dispositivo para setores regulamentados, como serviços financeiros (AAL3).

A principal desvantagem é a portabilidade limitada. Se o dispositivo for perdido, a chave de acesso não pode ser recuperada a menos que o usuário registre uma nova em outro dispositivo.

Por que as chaves de acesso sincronizadas foram introduzidas e quais são seus benefícios?#

As chaves de acesso sincronizadas (chaves de acesso de vários dispositivos) foram introduzidas para resolver os desafios de usabilidade das chaves de acesso vinculadas ao dispositivo, particularmente a falta de portabilidade e o possível bloqueio da conta em caso de perda do dispositivo. Os principais benefícios incluem:

  • Autenticação em vários dispositivos: Acesse contas em vários dispositivos sem registrar manualmente uma nova chave de acesso para cada um.
  • Nenhum risco de perda de acesso: As credenciais têm backup na nuvem (por exemplo, iCloud Keychain, Google Password Manager), garantindo a recuperação em caso de perda de um dispositivo.
  • Melhoria na UX: Elimina o atrito ao remover a necessidade de transferir ou recriar credenciais manualmente.
  • Sem hardware adicional necessário: Ao contrário das chaves de segurança de hardware, as chaves de acesso sincronizadas usam módulos de segurança integrados ao dispositivo.
  • Segurança forte com a conveniência da nuvem: A criptografia de ponta a ponta garante que a chave privada nunca saia do dispositivo em formato não criptografado.

5. Conclusão#

Na primeira parte da nossa série de 4 partes, analisamos quais são as diferenças históricas e técnicas das chaves de acesso vinculadas ao dispositivo e sincronizadas. Compreender essas diferenças nos ajudará a aplicar os requisitos de PSD2 e SCA de acordo. Além disso, analisamos o que o futuro pode nos trazer ao dar uma olhada nas mudanças mais recentes do padrão WebAuthn Level 3 que ainda está em evolução.

Aqui estão os links para as outras partes da nossa série:

  • Parte 2 “Análise dos requisitos da PSD2 e SCA (SCA e chaves de acesso II)”
  • Parte 3 "O que os requisitos de SCA significam para as chaves de acesso (SCA e chaves de acesso III)"
  • Parte 4 "Implicações da PSD3 / PSR para as chaves de acesso (SCA e chaves de acesso IV)"

Próximo passo: pronto para implementar passkeys no seu banco? Nosso relatório de +90 páginas sobre passkeys para bancos está disponível.

Obter o relatório

Compartilhar este artigo


LinkedInTwitterFacebook