Skip to main content


Introdução​

A Yubico é uma empresa que desenvolve soluções de segurança para autenticação multifatorial, o objetivo deles é tornar a proteção digital mais acessível e eficaz. O produto principal é a YubiKey, ela é uma chave de segurança física que pode ser utilizada em diversas plataformas e dispositivos para aumentar a segurança de contas digitais, serviços online, sistemas e redes.


A YubiKey (chave) atua como um método adicional de autenticação, conhecido como MFA (Multi Factor Authentication). Ela usa diversos métodos de autenticação, como:

  • OTP (One-Time Password)
  • FIDO U2F (Universal 2nd Factor - Legado)
  • FIDO2/WebAuthn (incluindo passkeys)
  • Autenticação por certificado (PIV)
  • Suporte a OpenPGP
  • Challenge-Response
  • Static Password
  • OATH-TOTP e HOTP


Autenticação multifator​

A YubiKey funciona como segundo fator de autenticação baseado em hardware. Com ela ativada, o login pode exigir uma senha e a posse da chave física. Se alguém tiver apenas a senha, não vai conseguir o acesso à conta. No FIDO2/WebAuthn, a chave responde apenas ao site para o qual foi registrada, o que impede que um site falso reutilize a autenticação (phishing).



Forma de uso​

A chave é conectada ao dispositivo por USB ou aproximada por NFC. O usuário precisa tocar no sensor da chave ou inserir o dedo no leitor biométrico (no caso da Yubikey Bio), o toque serve para confirmar a presença física de uma pessoa (o mesmo para biometria). A autenticação é feita pela chave, sem digitar código, exceto nos modos OTP e TOTP.



Compatibilidade​

A YubiKey é compatível com Windows, macOS e Linux, e com serviços online que implementam FIDO2/U2F ou OTP. O suporte depende do serviço e do modelo da chave: nem todo serviço aceita chaves de segurança, e nem todo modelo oferece todos os protocolos.



Opções de Autenticação Suportados pela Yubico​

As opções de autenticação são diferentes modos de autenticação oferecidos pela YubiKey, que são níveis de segurança, e vai depender das necessidades do usuário ou da organização.



Passwordless Authentication (Autenticação sem Senha)​

Com o Passwordless Authentication, não precisamos de uma senha, ela é substituída por outro mecanismo de autenticação, como a YubiKey. Em vez de digitar uma senha, o usuário usa a YubiKey para comprovar sua identidade.


Dependendo da configuração, a autenticação pode exigir apenas a presença física da chave e um toque, ou também a utilização de um PIN ou biometria.



Two-Factor Authentication (2FA)​

Nesse modo, a Yubikey é usada como um segundo fator de autenticação, então teremos uma senha mais a Yubikey para poder autenticar.


O 2FA adiciona uma camada extra de segurança ao exigir dois fatores para autenticação, isso sempre inclui algo que o usuário sabe (como uma senha) e algo que o usuário possui (como um dispositivo físico, como a YubiKey).



Multi-Factor Authentication (MFA)​

O MFA é um conceito bem mais amplo e moderno, e vale deixar claro que 2FA é um tipo de MFA. Nesse modo, serão usados dois ou mais fatores para fazer a autenticação.


Um exemplo muito bom de MFA é quando usamos a YubiKey Bio para fazer autenticação no SSH via FIDO. Nesse cenário, teremos a chave física (que é algo que o usuário possui), a passphrase (que é algo que o usuário sabe), e ainda podemos configurar a YubiKey para exigir a biometria (que é algo que o usuário é) antes de liberar a autenticação.


Dessa forma, mesmo que alguém tenha acesso à chave física e à passphrase, a autenticação ainda pode depender da biometria cadastrada na YubiKey Bio.


yubikey

A YubiKey oferece suporte aos três tipos de autenticação mencionados acima.



Protocolos de Autenticação​

Vou reservar essa seção para falar um pouco dos protocolos específicos que a YubiKey suporta para realizar a autenticação.



Fast IDentity Online - FIDO​

O FIDO é um ecossistema¹ criado para adicionar uma camada a mais de segurança ao login tradicional (como usuário e senha), em alguns casos, até simplifica o processo de autenticação e ainda torna o processo mais prático e seguro.

¹ Dentro do ecossistema, temos especificações que define regras como: formato dos dados, operações, requisitos, protocolos de comunicação e etc.


Normalmente o servidor confia em uma senha que você conhece e envia, mas isso introduz um problema quando sua senha é fraca ou conhecida por pessoas com más intenções. O FIDO veio para resolver exatamente esse problema, ao invés de confiar em uma senha, o servidor passa a confiar em criptografia de chave pública.


Quando você cadastra um dispositivo em um serviço, é criado um par de chaves criptográficas para aquele serviço. A chave privada fica no dispositivo, enquanto que a chave pública fica no servidor.


A senha pode continuar existindo, tudo vai depender do modelo de implementação adotado pelo serviço.



Universal 2nd Factor - U2F​

O U2F é um protocolo de autenticação criado dentro do ecossistema FIDO, o objetivo dele é adicionar um segundo fator de autenticação ao login tradicional.


Então, quando usamos FIDO U2F, estamos basicamente adicionando um 2FA. Além de ter usuário e senha, ainda temos que ter a chave física para o login. Mesmo que o usuário e senha sejam descobertos, o atacante ainda precisaria da chave física cadastrada para concluir o acesso.


Nos dias de hoje, o U2F foi incorporado à evolução do ecossistema FIDO e passou a ser chamado de CTAP1. Dispositivos U2F antigos ainda podem funcionar em ambientes FIDO2 para uma experiência de segundo fator.



Fast IDentity Online 2 - FIDO2​

O FIDO2 é a evolução do FIDO, ele mantém o objetivo de autenticação forte com criptografia de chave pública, mas agora é voltado para ambientes modernos, com suporte a autenticação sem senha (passwordless), passkeys e múltiplos fatores (MFA).


O FIDO2 é formado por duas partes principais:

ComponenteFunção
WebAuthnDefine como os navegadores e aplicações Web vão usar as credenciais de chave pública para autenticação.
CTAP2Define como o navegador ou sistema operacional pode se comunicar com autenticadores externos, como uma YubiKey, celular ou outro dispositivo FIDO2, via USB, NFC ou BLE.

O WebAuthn é a parte usada pelos serviços, por exemplo, quando um site permite cadastrar uma chave de segurança ou uma passkey, ele usa WebAuthn para criar e validar as credenciais de chave pública.


Já o CTAP2 é o protocolo responsável pela comunicação entre o cliente (como navegador ou Sistema Operacional) e o autenticador (como uma YubiKey, celular ou outro dispositivo compatível com FIDO2). Essa comunicação pode acontecer por meios como USB, NFC ou Bluetooth (BLE).


Dependendo de como o serviço implementa o FIDO2, ele pode ser usado de três formas:

  • 2FA
    Vai usar senha mais o FIDO2.

  • passwordless
    Vai usar apenas o FIDO2, sem uso de senha.

  • MFA
    Vai usar o FIDO2 mais verificação do usuário.


Existem duas versões principais de CTAP:

VersãoRelação com FIDO
CTAP1Nome novo para o protocolo U2F
CTAP2Parte do FIDO2

Durante o cadastro, o autenticador (como uma YubiKey, celular ou outro dispositivo compatível com FIDO2) cria um par de chaves criptográficas. A chave pública é enviada ao serviço, enquanto que a chave privada permanece protegida dentro do autenticador.


Durante o login, o serviço envia um desafio, o autenticador assina esse desafio usando a chave privada armazenado nele, e o serviço valida a resposta usando a chave pública cadastrada.


Dependendo da configuração e do tipo de chave, o autenticador pode exigir apenas presença do usuário, como tocar na chave física, ou também verificação do usuário, como PIN ou biometria.



WebAuthn​

O WebAuthn (Web Authentication) foi padronizado pelo W3C em conjunto com a FIDO Alliance e faz parte do ecossistema FIDO/FIDO2. Ele é uma API de autenticação da Web, foi criado para permitir autenticação usando criptografia de chave pública diretamente em navegadores e aplicações Web.


Ele faz parte do FIDO e define como um site pode criar, registrar e utilizar credenciais de autenticação associadas a um usuário.


Quando um serviço cadastra uma chave de segurança, o navegador usa o WebAuthn para se comunicar com o Sistema Operacional e iniciar o processo de criação ou uso da credencial de acesso.


Durante o cadastro, o serviço solicita a criação de uma credencial. O autenticador cria um par de chaves criptográficas, a chave pública é enviada ao serviço e a chave privada permanece protegida no autenticador.


Durante o login, o serviço envia um desafio, o navegador recebe esse desafio através do WebAuthn e solicita ao autenticador que o assine utilizando a chave privada correspondente. Depois, o serviço valida a resposta utilizando a chave pública cadastrada.


O WebAuthn é usado pelo serviço através do navegador para solicitar operações de autenticação usando credenciais de chave pública. O navegador repassa essas solicitações para o Sistema Operacional, que pode se comunicar com um autenticador (como uma YubiKey), usando o CTAP1 ou o CTAP2.



PasswordLess - Sem senha​

O Passwordless é um modelo de autenticação, e nesse modelo, não usamos mais a senha tradicional. Dentro do ecossistema FIDO2, isso pode ser feito usando credenciais de chave pública armazenadas em um autenticador (como uma YubiKey, celular ou outro dispositivo compatível).


Isso significa que ao invés de usar a chave mais usuário e senha, vamos usar apenas o usuário mais a chave física para autenticação. Lembrando que o FIDO2 pode usar outras camadas de autenticação, como PIN ou biometria.


O objetivo do Passwordless é eliminar os principais problemas relacionados ao uso de senhas, como senhas fracas, reutilizadas, vazadas ou roubadas por ataques de phishing.



Passkeys​

A Passkey é um tipo de credencial de autenticação criada e usada dentro do ecossistema do FIDO2, e o WebAuthn é a principal forma dos sites usar essa credencial. Ela é capaz de permitir login sem informar dados de qual usuário quer autenticar, mas normalmente o serviço solicita alguma informação do usuário, como username ou e-mail, e a partir daqui inicia o fluxo de autenticação.


Todo o esquema de funcionamento do FIDO continua valendo, a chave privada fica protegida no dispositivo, enquanto que a chave pública fica armazenada no serviço.


A diferença das Passkeys para o uso comum do FIDO2 é que elas são voltadas especificamente para uma experiência de autenticação sem senha, usando credenciais FIDO2 de forma mais simples e transparente para o usuário.


Dependendo de onde ela é armazenada, uma Passkey pode ficar vinculada a um único dispositivo ou ser sincronizada entre vários dispositivos através de um provedor de credenciais.


Até o momento eu citei bastante o termo "par de chaves criptográficas", acontece que com o FIDO2, a Passkey é um tipo de credencial FIDO2 baseada em criptografia de chave pública, podemos pensar na relação deles assim:

Passkey
├── chave privada
├── chave pública
└── informações associadas à credencial

No FIDO legado (conhecido como U2F ou CTAP1), também era usado um par de chaves criptográficas. A diferença é que essas credenciais eram voltadas principalmente para 2FA e não eram chamadas de Passkeys, esse conceito (de Passkey) surgiu depois, quando foi criado o FIDO2/WebAuthn.


Relação entre FIDO2/WebAuthn e credenciais de autenticação

Toda Passkey é uma credencial FIDO2/WebAuthn (como explicado acima), mas nem toda credencial FIDO2/WebAuthn é uma Passkey.


Vamos imaginar um exemplo para facilitar, uma YubiKey usada como 2FA depois de digitar a senha é FIDO2/WebAuthn, mas não está sendo usada como Passkey.


Já o login com biometria no celular, sem digitar usuário nem senha, é FIDO2/WebAuthn e é uma Passkey.

O mesmo vale para o uso com YubiKey.


Se você precisa digitar usuário e senha e depois usar a chave física, ela está sendo usada como 2FA. Quando o serviço usa uma Passkey, essa credencial pode substituir a senha tradicional e ser usada junto com uma verificação local, como PIN ou biometria.

Ou seja, você digita apenas a informação do usuário e todo restante ocorre com uso de FIDO2/WebAuthn com Passkey.


Mesmo usando uma Passkey, o serviço ainda pode solicitar primeiro o username ou e-mail para identificar a conta que será autenticada.



Initiative for Open Authentication - OATH​

O OATH é outro ecossistema criado para adicionar uma camada a mais de segurança ao login tradicional. Ele foi criado para definir padrões abertos de autenticação, principalmente usando códigos de uso único, conhecidos como OTP (One-Time Password).


Diferente do FIDO, que trabalha principalmente com criptografia de chave pública, o OATH normalmente trabalha com um segredo compartilhado entre o serviço e o autenticador.


Durante o cadastro, o serviço gera um segredo que também é armazenado no autenticador. A partir desse segredo, os dois conseguem calcular o mesmo código de autenticação.


Um exemplo comum é quando ativamos 2FA em um site e ele apresenta um QR Code. Ao escanear esse QR Code em um aplicativo autenticador, o segredo é armazenado no dispositivo e passa a ser usado para gerar os códigos temporários.


Dentro do OATH existem dois mecanismos muito comuns:

MecanismoFuncionamento
HOTPGera códigos com base em um contador.
TOTPGera códigos com base no tempo, normalmente mudando a cada 30 segundos.

O TOTP é o mais conhecido no dia a dia, já que é o modelo usado por aplicativos como Google Authenticator, Microsoft Authenticator, FreeOTP e também pelo aplicativo OATH presente em algumas YubiKeys.


O objetivo do OATH é adicionar uma camada de autenticação além da senha. Mesmo que alguém descubra o usuário e a senha, ainda será necessário obter o código OTP válido para concluir o login.


É importante não confundir OATH com OAuth, eles são tecnologias completamente diferentes. O OATH está relacionado a autenticação/OTP, enquanto OAuth é usado principalmente para autorização entre aplicações.



Personal Identity Verification - Smart Card/PIV​

O PIV é um padrão de autenticação baseado em certificados digitais e criptografia de chave pública. Ele permite que um dispositivo, como uma YubiKey, funcione como um Smart Card.


Nesse modelo, a YubiKey armazena uma chave privada e também pode armazenar um certificado digital associado a essa chave.


A chave privada permanece protegida dentro da YubiKey e não precisa sair do dispositivo. Já o certificado pode ser armazenado em um slot PIV da própria YubiKey. Quando o sistema precisa autenticar, ele pode ler esse certificado da chave.


Mas como o certificado não é secreto, uma cópia também pode existir fora da chave.


Durante a autenticação, o sistema solicita uma operação criptográfica, a YubiKey usa a chave privada armazenada nela para assinar ou provar a posse daquela chave, e o sistema valida essa operação usando o certificado e a chave pública correspondente.


O PIV é muito usado em ambientes corporativos, onde existe uma infraestrutura de certificados, conhecida como PKI (Public Key Infrastructure). Ele pode ser usado para:

  • login em computadores;
  • autenticação em sistemas corporativos;
  • VPN;
  • assinatura digital;
  • criptografia;
  • autenticação com certificados;
  • SSH, dependendo da configuração.

A principal diferença em relação ao FIDO2 é que o PIV trabalha principalmente com certificados digitais e PKI, enquanto o FIDO2 foi criado especificamente para autenticação moderna usando credenciais criptográficas vinculadas aos serviços.


Em uma YubiKey, o PIV funciona como se a chave fosse um Smart Card físico, mas em formato USB/NFC. O sistema operacional ou aplicação acessa esse Smart Card através de interfaces como PKCS#11.



OpenPGP​

O OpenPGP é um padrão usado para criptografia, assinatura digital e verificação de identidade, principalmente em arquivos, mensagens e e-mails.


Assim como no PIV, ele funciona com criptografia de chave pública.


Quando usamos OpenPGP em uma YubiKey, a ideia é manter as chaves privadas protegidas dentro da própria YubiKey. A chave pública pode ser distribuída normalmente.


O OpenPGP normalmente trabalha com três funções principais:

FunçãoUso
AssinaturaAssinar arquivos, mensagens, commits etc.
CriptografiaDescriptografar dados enviados para você
AutenticaçãoPode ser usada para autenticação, como SSH em algumas configurações

A principal vantagem de usar OpenPGP na YubiKey é que a chave privada pode permanecer dentro do dispositivo, reduzindo o risco de ela ser copiada do computador.


Quano usamos OpenPGP com a YubiKey, temos que usar o GnuPG (gpg) para conversar com o applet OpenPGP da chave física e assim realizar as operações.



HMAC-SHA1 Challenge-Response​

O HMAC-SHA1 Challenge-Response é um mecanismo de autenticação baseado em um segredo compartilhado entre o sistema e a YubiKey.


Nesse modelo, a YubiKey armazena um segredo internamente, e quando o sistema precisar autenticar o usuário, ele envia um valor chamado challenge para a YubiKey.


A YubiKey usa esse challenge junto com o segredo armazenado para gerar uma resposta criptográfica usando HMAC-SHA1.


O segredo usado para gerar a resposta não precisa sair da YubiKey, então o sistema envia apenas o challenge e recebe a resposta calculada.


Esse mecanismo é diferente do OATH/TOTP. No OATH, normalmente é gerado um código de uso único. Já no Challenge-Response, o sistema envia um desafio específico e espera uma resposta calculada a partir dele.


Ele pode ser usado em cenários como:

  • autenticação local;
  • PAM;
  • desbloqueio de disco, como LUKS;
  • scripts e aplicações que suportem Challenge-Response.


Yubico OTP​

O Yubico OTP é um mecanismo de autenticação criado pela Yubico que gera uma senha de uso único cada vez que a YubiKey é usada.


A YubiKey possui uma identidade e um segredo criptográfico, quando o usuário toca na chave, ela gera uma sequência de caracteres única.


Diferente do TOTP, o código não é baseado no horário atual, cada uso gera um valor diferente, usando informações internas da própria YubiKey, como contadores e um segredo criptográfico.


Normalmente, a YubiKey funciona como se fosse um teclado USB, ao tocar nela, o código é digitado automaticamente no campo onde o cursor está.


O servidor recebe esse código e precisa validá-lo usando um serviço compatível com Yubico OTP. O objetivo é adicionar um fator de autenticação baseado na posse da YubiKey.


Hoje em dia, o FIDO2/WebAuthn costuma ser a preferência quando existe o suporte, principalmente pela resistência a phishing e facilita de implementação. O Yubico OTP ainda aparece bastante em ambientes legados ou integrações específicas.



YubiKey​

As YubiKeys são dispositivos físicos compactos, geralmente conectados via USB ou NFC. Ela foi projetada para aumentar a segurança durante o processo de autenticação de contas. Elas podem funcionar simulando entradas de teclado ou usando diferentes mecanismos e padrões de segurança, como Yubico OTP, OATH (HOTP e TOTP), FIDO U2F e FIDO2/WebAuthn.


Sua função pode variar desde atuar como um fator adicional de autenticação, passando pela geração de códigos de uso único, até permitir autenticação sem senha. Dependendo do método usado, a YubiKey também pode tornar o acesso mais resistente a ataques como phishing e roubo de credenciais.



Tipos de YubiKey​

Existem vários tipos de YubiKeys, cada um projetado para atender a diferentes necessidades de autenticação e compatibilidade com dispositivos, lembrando que nem todos os modelos aceitam todos os protocolos que vamos mencionar. Abaixo estão os principais modelos e suas características:

  • YubiKey 5 FIPS Series
    É a versão da YubiKey 5 voltada para organizações que precisam atender requisitos rigorosos de conformidade e segurança, como órgãos governamentais e setores regulados. A geração atual possui validação FIPS 140-3 e oferece suporte a vários mecanismos de autenticação, incluindo FIDO2/WebAuthn, FIDO U2F, Yubico OTP, OATH (HOTP/TOTP), Smart Card (PIV), OpenPGP e Challenge-Response. Ela está disponível em modelos com USB-A, USB-C e NFC.

  • YubiKey 5 Series
    É a série mais versátil da Yubico, com suporte a FIDO2/WebAuthn, FIDO U2F, Yubico OTP, OATH (HOTP/TOTP), Smart Card (PIV), OpenPGP e HMAC-SHA1 Challenge-Response. Ela é compatível com uma ampla variedade de dispositivos, sistemas operacionais e serviços. Está disponível em versões com USB-A, USB-C e modelos com NFC integrado.

  • YubiKey Bio Series
    É a série voltada para autenticação biométrica por impressão digital. A YubiKey Bio FIDO Edition suporta FIDO2/WebAuthn e FIDO U2F, enquanto a YubiKey Bio Multi-protocol Edition também adiciona suporte a Smart Card (PIV). A linha Bio não oferece suporte a Yubico OTP, OATH ou OpenPGP.

  • Security Key Series
    É uma opção mais simples e acessível da Yubico, focada exclusivamente nos padrões FIDO2/WebAuthn e FIDO U2F. Pode ser utilizada tanto como segundo fator (2FA) quanto para autenticação sem senha e Passkeys, dependendo do serviço. Não oferece suporte a OATH, Yubico OTP, PIV ou OpenPGP. Está disponível em versões USB-A, USB-C e modelos com NFC.

  • YubiKey FIPS Series
    Essa é a linha anterior à YubiKey 5 FIPS, baseada na YubiKey 4 e validada pelo FIPS 140-2. Oferece suporte a Yubico OTP, OATH (HOTP/TOTP), FIDO U2F, Smart Card (PIV), OpenPGP e HMAC-SHA1 Challenge-Response. Foi voltada principalmente para órgãos governamentais e organizações com requisitos de conformidade. Essa série foi descontinuada e substituída pela YubiKey 5 FIPS Series.

  • YubiHSM Series
    Diferente das YubiKeys tradicionais, o YubiHSM (Hardware Security Module) é um dispositivo focado em proteger infraestruturas críticas. Usado para tarefas como gerenciamento seguro de chaves criptográficas e assinatura de dados, ele é conectado a servidores via USB e oferece segurança de nível empresarial para ambientes que exigem proteção avançada.

  • YubiKey 4 Series (descontinuada)
    Esta série foi uma das principais da Yubico antes do lançamento da YubiKey 5 Series. Oferecia suporte a vários mecanismos de autenticação, incluindo Yubico OTP, OATH (HOTP/TOTP), FIDO U2F, Smart Card (PIV), OpenPGP e HMAC-SHA1 Challenge-Response.

    Era compatível com USB-A e também possuía uma versão compacta chamada YubiKey 4 Nano. Embora ainda possa ser usada em muitos cenários, foi substituída pela YubiKey 5 Series, que adicionou suporte a tecnologias mais modernas, como FIDO2/WebAuthn.


A tabela abaixo mostra as principais YubiKeys e suas diferenças:

ModeloFIDO U2FFIDO2Yubico OTPOATH HOTP/TOTPPIVOpenPGPChallenge-ResponseBiometria
YubiKey 4SimNãoSimSimSimSimSimNão
YubiKey 5 SeriesSimSimSimSimSimSimSimNão
Security Key SeriesSimSimNãoNãoNãoNãoNãoNão
YubiKey Bio FIDO EditionSimSimNãoNãoNãoNãoNãoSim
YubiKey Bio Multi-protocol EditionSimSimNãoNãoSimNãoNãoSim

Para mais detalhes sobre tamanho e versões de chaves GPG e outros protocolos suportados por cada uma das Yubikeys, veja no site oficial.



Onde usar a Yubikey?​

As YubiKeys podem ser usadas em vários cenários de autenticação, como acesso a serviços online, login local em desktops, acesso remoto via SSH e proteção de aplicações corporativas, acesse aqui para obter mais detalhes.


Em serviços online, o mais comum é usar FIDO U2F e FIDO2/WebAuthn. O FIDO U2F é usado principalmente como segundo fator, normalmente depois do usuário e senha. Já o FIDO2/WebAuthn permite cenários mais modernos, incluindo segundo fator, autenticação sem senha e uso de Passkeys.


No SSH, uma das formas mais modernas é usar o suporte a FIDO2 do OpenSSH, através de chaves como ed25519-sk ou ecdsa-sk. Nesse modelo, a YubiKey participa da operação criptográfica e a chave privada permanece protegida na Yubikey.


Também é possível usar PIV ou OpenPGP para autenticação SSH, dependendo de como o ambiente foi configurado.


Já para login local offline, podemos usar o pam_u2f, ele é baseado em criptografia de chave pública por meio do protocolo FIDO U2F. Esse método exige a presença física do dispositivo, garantindo um nível elevado de segurança mesmo sem conexão com a rede.


Como funciona Login local com pam_u2f?

Durante a configuração inicial, uma chave pública é gerada pela YubiKey e associada à conta do usuário no sistema local. No momento do login, o sistema (através do módulo PAM) envia um desafio ao dispositivo. A YubiKey utiliza sua chave privada para assinar o desafio, e o sistema verifica a assinatura utilizando a chave pública armazenada.



Slots​

As YubiKeys possuem slots configuráveis que permitem armazenar diferentes configurações e funcionalidades. Um slot é como uma área interna dedicada, onde são configurados os comportamentos desejados para a autenticação.


Existem dois slots principais disponíveis para o OTP (One-Time Password), sendo o Slot 1 associado a um pressionamento curto do contato da YubiKey e o Slot 2 a um pressionamento longo. Essa distinção permite que o dispositivo realize diferentes ações dependendo do tipo de interação.



Slots OTP​

Os slots de OTP podem ser configurados para oferecer diversas funcionalidades, como:

  • Yubico OTP: Usa um algoritmo proprietário que gera senhas descartáveis (One-Time Passwords) exclusivas para autenticação segura (ver Yubico OTP).
  • OATH HOTP (HMAC-based One-Time Password): Um padrão aberto que gera senhas descartáveis baseadas em eventos (ver OATH).
  • Senha estática: Pode ser configurado para inserir uma senha fixa como se fosse digitada por um teclado.
  • Desafio-resposta: Usa algoritmos como HMAC-SHA1 ou Yubico OTP para autenticações mais robustas, respondendo a desafios enviados pelo sistema (ver HMAC-SHA1 Challenge-Response).

Para fixar as informações:

  • Slot 1 (Pressionamento curto)
    Por padrão, este slot é configurado para Yubico OTP, permitindo que a YubiKey gere senhas descartáveis rapidamente com um toque breve. É ideal para autenticação rápida em serviços compatíveis. Também pode ser reprogramado para outros protocolos, como OATH HOTP, senha estática ou Challenge-Response.

  • Slot 2 (Pressionamento longo)
    Usado para funções mais avançadas, como Challenge-Response ou senha estática, mas é totalmente configurável. Ativado por um toque prolongado (cerca de 2 segundos), esse slot possibilita o uso simultâneo das diferentes funcionalidades da YubiKey em um único dispositivo.


Vamos entender os modos de configuração suportados nos slots OTP:

  • Yubico OTP
    Gera um código OTP baseado em chaves Yubico, que pode ser configurado em qualquer slot.

  • Challenge-Response
    É um método de autenticação suportado pelas YubiKeys que envolve a troca de desafios e respostas entre o dispositivo e o sistema host. Nesse processo, o sistema envia um "desafio" (challenge) para a YubiKey, que responde (response) utilizando um algoritmo criptográfico previamente configurado. As YubiKeys suportam dois principais algoritmos para Challenge-Response:

    • HMAC-SHA1
      Esse mecanismo é muito bom e muito usado em ambientes locais ou offline, onde não existe comunicação com um servidor de validação externo. Dessa forma, não dependemos de um servidor externo de validação e podemos fazer tudo localmente.

      O sistema que solicita a autenticação gera ou fornece um desafio e o envia para a YubiKey. A YubiKey combina esse desafio com uma chave secreta interna e usa o algoritmo HMAC-SHA1 para gerar uma resposta. O sistema calcula a resposta esperada usando a mesma chave secreta e o mesmo desafio e, se ambas coincidirem, a autenticação é validada.

      O sistema calcula a resposta esperada utilizando a mesma chave secreta e o mesmo desafio e, se ambas as respostas coincidirem, a autenticação é confirmada com sucesso.

    • OTP Challenge-Response
      Nesse modo, a YubiKey recebe um desafio de 6 bytes enviado pelo sistema host e combina com 10 bytes adicionais gerados pelo dispositivo. Essa combinação é criptografada usando uma chave AES de 16 bytes, gerando uma resposta de 16 bytes.

      O sistema que realiza a validação descriptografa essa resposta e verifica se os primeiros 6 bytes correspondem ao desafio enviado.

  • Static Password
    Armazena uma senha fixa que pode ser usada em locais onde senhas OTP não são suportadas.

  • OATH HOTP
    Gera códigos OTP baseados em eventos (como contador) para autenticação multifatorial.


Podemos configurar os slots usando o YubiKey Manager (GUI ou CLI), onde é possível definir qual slot será utilizado para cada função. Isso permite personalizar a YubiKey para atender a diferentes necessidades de segurança e autenticação, escolhendo a função mais apropriada para cada slot. Também é possível usar o Yubikey Personalization Tool (legado) ou YubiKey Manager/ykman (moderno).


Esses dois slots proporcionam uma grande flexibilidade, permitindo que um único dispositivo atenda a múltiplas necessidades de segurança em diferentes serviços e cenários de uso.



Código OTP​

O código OTP é um sistema de autenticação forte que gera uma senha única e dinâmica cada vez que é usado. O sistema é projetado para impedir a reutilização de senhas e fornecer uma autenticação segura em várias situações. A YubiKey gera OTPs utilizando uma combinação de identificadores e uma chave secreta, protegida por criptografia AES.


O OTP gerado pela YubiKey tem 44 caracteres e é composto por duas partes principais:

  1. Public ID (Identificador Público)
    Os primeiros 12 caracteres do OTP representam o Public ID da YubiKey. Ele identifica exclusivamente a YubiKey e serve para identificar a chave sem revelar informações sensíveis. Ele é usado pelo servidor para localizar a Private ID e Secret Key da YubiKey no banco de dados.

  2. Encrypted OTP (Token Criptografado)
    Os últimos 32 caracteres representam um bloco criptografado de 128 bits. Dentro desse bloco estão informações como o Private ID, contador de uso, timestamp, contador de sessão, número aleatório e checksum.

    Esse bloco é criptografado usando uma Secret Key AES-128, que fica configurada tanto na YubiKey quanto no servidor de validação.


A estrutura detalhada do Yubico OTP é a seguinte:

  • Private UID (6 bytes)
    ID privada única da YubiKey.

  • Contador de Uso (2 bytes)
    Incrementa a cada uso, mesmo após reinicializações, ajudando a detectar OTPs reutilizados.

  • Timestamp (3 bytes)
    Marca temporal que incrementa aproximadamente 8 vezes por segundo, indicando quando o OTP foi gerado.

  • Contador de Sessão (1 byte)
    Incrementa a cada OTP gerado durante uma sessão de energia contínua, reiniciando após desligamento.

  • Número Aleatório (2 bytes)
    Adiciona entropia ao OTP, tornando-o mais seguro.

  • Checksum (2 bytes)
    Verifica a integridade dos dados do OTP.


A segurança da Yubico OTP depende da proteção da Secret Key AES-128. Sem essa chave, não é possível descriptografar de forma prática o bloco criptografado de 128 bits. Com a chave AES correta, o servidor consegue descriptografar o OTP e verificar informações como Private ID, contador de uso, timestamp, contador de sessão, número aleatório e checksum.


No entanto, com o Public ID, Private ID e a Secret Key, é possível recriar um OTP completo, pois esses são os elementos essenciais que formam o código. Por esse motivo, é crucial proteger essas informações, especialmente ao operar um servidor KSM (Key Storage Module), que armazena e utiliza esses dados para validar os OTPs. A segurança desses elementos é fundamental para evitar comprometimentos no sistema de autenticação.



Estrutura do OTP​

A saída OTP da YubiKey é fornecida no conjunto de caracteres Modhex. O conjunto de caracteres Modhex usa caracteres comuns na maioria dos layouts, isso permite funcionalidades independentemente do idioma usado no computador.


  • Hexadecimal (Hex)
    O Hexadecimal é um sistema numérico base 16 usado para representar dados de maneira compacta e legível. Ele usa os dígitos de 0 a 9 e as letras de A a F para representar os valores de 0 a 15. O formato hexadecimal é amplamente usado em computação e criptografia para representar valores binários de forma simplificada, pois cada caractere hex representa exatamente 4 bits (um nibble). Por exemplo, o byte binário 10101100 pode ser escrito como AC em hexadecimal.

  • Modhex (Modified Hexadecimal)
    Já o Modhex é uma variação do formato hexadecimal usada pela Yubico para garantir a compatibilidade dos códigos gerados pelas YubiKeys com diferentes layouts de teclado.

    Como a posição das teclas pode variar entre layouts, o ModHex utiliza um conjunto específico de caracteres escolhidos para reduzir esse problema.

    O mapeamento entre Hex e Modhex é o seguinte:

    Hexadecimal: 0 1 2 3 4 5 6 7 8 9 A B C D E F
    Modhex:      c b d e f g h i j k a n t r u v

    Por exemplo, a sequência hexadecimal 1A3F seria representada como bant em Modhex.



PIV certificate slots​

As YubiKeys compatíveis com PIV (Personal Identity Verification) possuem diversos slots de certificados, cada um destinado a uma função específica na autenticação e segurança. Os modelos YubiKey 4 e 5 oferecem 25 slots, enquanto a YubiKey NEO possui 4 slots.

Principais slots de certificados PIV:

  • Slot 9a: PIV Authentication
    Utilizado para autenticar o cartão e o portador, sendo comum em logins de sistemas. Requer a inserção do PIN do usuário para operações com a chave privada. Após a autenticação inicial, múltiplas operações podem ser realizadas sem solicitar o PIN novamente.

  • Slot 9c: Digital Signature
    Destinado a assinaturas digitais, como documentos ou executáveis. Exige a inserção do PIN antes de cada operação de assinatura, garantindo a participação ativa do usuário em cada assinatura gerada.

  • Slot 9d: Key Management
    Usado para criptografia visando confidencialidade, como na encriptação de e-mails ou arquivos. Requer o PIN do usuário para operações com a chave privada. Após a autenticação inicial, múltiplas operações podem ser realizadas sem solicitar o PIN novamente.

  • Slot 9e: Card Authentication
    Suporta aplicações de acesso físico, como controle de entrada em edifícios com fechaduras compatíveis com PIV. Não requer a inserção do PIN para operações com a chave privada.

  • Slots 82-95: Retired Key Management
    Disponíveis apenas nas YubiKeys 4 e 5, são destinados ao armazenamento de chaves de gerenciamento anteriores, permitindo a decriptação de documentos ou e-mails antigos. Todos os 20 slots estão disponíveis para uso.

  • Slot f9: Attestation
    Disponível em YubiKeys a partir da versão 4.3, é utilizado para atestar outras chaves geradas no dispositivo. Este slot não é limpo durante um reset, mas pode ser sobrescrito conforme necessário.


É importante notar que as políticas de PIN para esses slots podem ser ajustadas nas YubiKeys 4 e 5. No entanto, aplicativos que utilizam backends genéricos, como PKCS#11, podem não considerar essas diferenças e solicitar o PIN mesmo quando não é necessário.



Ferramentas online​

A Yubico oferece diversas ferramentas online para facilitar a configuração e o uso de suas chaves de segurança YubiKey. A seguir, vou comentar uma visão geral de alguns serviços online que são interessantes ter conhecimento:

  • Yubico OTP Verification
    Esta ferramenta permite que você teste e verifique se sua YubiKey está funcionando corretamente ao gerar e validar um One-Time Password (Yubico OTP). O sistema validará o código para confirmar o funcionamento adequado do dispositivo. Para que possa ser confirmado, você deve ter submetido os dados para o servidor do YubiCloud ou ter a configuração de fábrica (quando a chave é nova). Para acessar esse serviço, utilize o link Yubico OTP Verification.

  • Yubico API Key Signup
    É usado quando queremos criar ou personalizar uma credencial Yubico OTP. Nesses casos, informações como Serial Number, Public ID, Private ID e Secret Key precisam ser enviadas ao YubiCloud para que o serviço consiga validar os OTPs gerados por essa configuração. Para que possa ser obtidos os dados, você deve ter submetido os dados para o servidor do YubiCloud ou ter a configuração de fábrica (quando a chave é nova). Para acessar esse serviço, utilize o link Yubico API Key Signup.

  • Yubico OTP Key Upload
    Se você personalizou sua YubiKey com uma chave Yubico OTP específica, este serviço permite que você carregue essa chave para os servidores de validação da Yubico, garantindo que terceiros possam autenticar seu dispositivo corretamente. Esse serviço sincroniza sua YubiKey personalizada com os servidores de validação da Yubico. Para acessar esse serviço, utilize o link Yubico OTP Key Upload.



Ferramentas de Linha de Comando​

As ferramentas de linha de comando (CLI) da Yubico oferecem várias opções para gerenciar e configurar YubiKeys diretamente do terminal, o que é ideal para administradores de sistemas e usuários avançados. Abaixo estão as principais ferramentas de CLI da Yubico e suas funcionalidades:

  • YubiKey Manager CLI (ykman)
    Ferramenta principal para configurar e gerenciar YubiKeys, não possui mais um equivalente para ser usado na Interface Gráfica (antigamente tinha). Disponibiliza as seguintes funcionalidades:

    • Visualizar informações detalhadas da YubiKey, como modelo e número de série.

    • Configurar os diferentes modos de autenticação, como OTP, FIDO2, PIV (cartão inteligente) e OpenPGP.

    • Habilitar ou desabilitar aplicações e interfaces da YubiKey, além de configurar os slots OTP.

    • Gerenciar certificados, chaves e senhas armazenadas na YubiKey.

    • Exemplo de Uso:

      # Exibir informações gerais da YubiKey
      ykman info

      # Configurar o slot 1 para OTP
      ykman otp yubiotp 1

  • Yubico PAM Modules
    São Módulos PAM que permitem usar YubiKeys para autenticação de usuários em sistemas Unix/Linux. Eles possuem as seguintes funcionalidades:
    • pam_yubico.so: Usado para autenticação com Yubico OTP, requer um servidor de validação (local ou YubiCloud).
    • pam_u2f.so: Usado para autenticação com FIDO U2F/FIDO2, funcionando de maneira offline.

  • YubiOTP Personalization Tool
    É uma ferramenta usada para personalizar as configurações OTP da YubiKey, possui um equivalente para ser usado na Interface Gráfica.

    • Exemplo de Uso:
      # Configurar o Slot 2 para Challenge-Response HMAC-SHA1
      ykpersonalize -2 -ochal-resp -ochal-hmac -ohmac-lt64 -oserial-api-visible

  • yubico-piv-tool
    Ferramenta CLI para gerenciar e configurar o modo PIV (Personal Identity Verification) da YubiKey, usado para autenticação baseada em certificados digitais.

  • yubikey-agent
    É uma ferramenta de terceiros, ela permite usar uma YubiKey como agente SSH utilizando o modo PIV. A chave privada é gerada e mantida na YubiKey, enquanto que o agente fornece a chave pública ao SSH. Não é uma ferramenta oficial da Yubico.


Yubico Authenticator​

O Yubico Authenticator é um aplicativo desenvolvido pela Yubico para interagir e gerenciar diferentes funções da YubiKey. Ele pode gerar códigos de autenticação em duas etapas através de OATH (TOTP/HOTP) e também permite gerenciar recursos como Passkeys FIDO2, certificados PIV, credenciais OATH e configurações do Yubico OTP, dependendo do modelo da YubiKey.


Diferente de Authenticators tradicionais (como Google Authenticator), as credenciais OATH ficam armazenadas diretamente na YubiKey, e não no computador ou celular. O aplicativo funciona como uma interface para acessar essas credenciais e solicitar à YubiKey a geração dos códigos.


Se a YubiKey for perdida ou roubada, as credenciais OATH armazenadas nela também serão perdidas, caso não exista uma segunda chave ou outro método de recuperação configurado. Isso acontece porque os segredos permanecem armazenados no próprio dispositivo.


O aplicativo é compatível com Windows, macOS, Linux, Android, iOS e iPadOS, e pode funcionar através de USB, Lightning e NFC, dependendo do dispositivo e do modelo da YubiKey.


O Authenticator exibe e permite gerenciar bastante coisa, mas depende muito do modelo da YubiKey:

  • visualizar e excluir Passkeys FIDO2;
  • configurar ou alterar o PIN FIDO2;
  • gerenciar impressões digitais nas YubiKey Bio;
  • carregar e gerenciar certificados PIV;
  • configurar contas OATH;
  • gerenciar recursos relacionados ao Yubico OTP.


YubiHSM​

O YubiHSM é um HSM (Hardware Security Module) desenvolvido pela Yubico. Ele é um dispositivo criado para proteger chaves criptográficas importantes e realizar operações com essas chaves sem precisar expor elas diretamente ao Sistema Operacional ou às aplicações.


Por exemplo, se uma aplicação precisa assinar um arquivo, ela não precisa receber ou acessar diretamente a chave privada. A aplicação envia os dados para o YubiHSM, o dispositivo realiza a assinatura usando a chave armazenada internamente e devolve apenas o resultado da operação.


Ele pode ser utilizado para:

  • gerar chaves criptográficas;
  • armazenar chaves;
  • realizar assinaturas digitais;
  • criptografar e descriptografar dados;
  • realizar operações de autenticação;
  • proteger chaves utilizadas por aplicações e servidores.

O YubiHSM possui um formato muito menor que muitos HSMs tradicionais. Ele é conectado ao servidor através de USB, sendo uma opção interessante para pequenas e médias infraestruturas, laboratórios e organizações que precisam proteger suas chaves sem utilizar equipamentos maiores de data center.



SSH com Yubikey​

A YubiKey oferece várias maneiras de fortalecer a autenticação SSH, permitindo diferentes métodos de autenticação com segurança adicional. Aqui estão todos os métodos principais que podem ser usados para autenticação SSH com uma YubiKey:



Autenticação SSH com Yubico OTP via PAM - Descontinuado​

Este método usa o módulo pam_yubico.so para validar um Yubico OTP através do YubiCloud ou de um servidor próprio de validação. Apesar de ainda poder existir em ambientes antigos, o yubico-pam chegou ao fim da vida e não é mais mantido. Para novas implementações, a Yubico recomenda métodos baseados em chaves assimétricas, como FIDO2, PIV ou OpenPGP.


Esse método é útil quando a organização quer centralizar a validação dos OTPs ou usar o servidor do Yubicloud para isso. O ponto negativo é a necessidade do servidor que está sendo acessado ter conectividade com o servidor de validação das chaves físicas.



Autenticação SSH com chave CTAP1/FIDO2 pelo OpenSSH​

Devo dizer que esse é o método mais moderno e simples de usar uma YubiKey no SSH. Para que ele funcione, é preciso usar chaves do tipo ecdsa-sk ou ed25519-sk, onde o sufixo -sk significa security key. Nesse tipo de autenticação, a YubiKey fica conectada no computador do usuário, ou seja, no cliente SSH, e o servidor recebe apenas a chave pública no ~/.ssh/authorized_keys.


Esse método não usa PAM, nem OTP e não depende do YubiCloud ou algum outro servidor de validação, toda a comunicação ocorre entre o cliente SSH e o servidor SSH.


Durante o login, o cliente SSH solicita a passphrase (se tiver configurada) e logo em seguida solicita a YubiKey, o usuário toca na chave ou faz a verificação exigida, e a chave assina o desafio da autenticação. O servidor valida a assinatura usando a chave pública cadastrada e permite a conexão.



Autenticação Local com Challenge-Response HMAC-SHA1 via PAM​

Este método usa o modo Challenge-Response da YubiKey com HMAC-SHA1. Em vez de validar um OTP em um servidor externo, o sistema envia um desafio para a YubiKey, e a YubiKey gera uma resposta criptográfica baseada em um segredo gravado nela.


Esse método também usa o módulo pam_yubico.so, mas em modo offline. Ele não depende do YubiCloud nem de um servidor OTP externo.


É importante entender a limitação desse modelo. Como o PAM roda no sistema que está fazendo a autenticação, a YubiKey precisa estar acessível para esse sistema. Por isso, esse método é mais comum para login local, sudo, TTY ou estações de trabalho. Para SSH remoto comum, ele não é tão prático, porque a YubiKey precisar estar conectada no computador do usuário, mas o PAM estaria rodando no servidor remoto, isso invalida o login via SSH.



Autenticação local com FIDO U2F/FIDO2 via PAM​

Este método usa o módulo pam_u2f.so para integrar YubiKeys e outros autenticadores compatíveis com FIDO U2F ou FIDO2 ao PAM do Linux.


Ele é indicado para proteger login local, tela gráfica, TTY, sudo, su e outros serviços que usam PAM. O sistema mantém um arquivo de mapeamento com o usuário e a credencial FIDO cadastrada.


No pam_u2f, a autenticação é feita pelo PAM do sistema onde o login está acontecendo. Para SSH remoto comum, isso exigiria que a YubiKey estivesse acessível pelo servidor, e não apenas pelo computador do usuário, isso invalida o login via SSH.



Autenticação SSH com PIV / Smart Card​

A YubiKey também pode ser usada como smart card por meio da aplicação PIV. Nesse modelo, uma chave privada e um certificado ficam armazenados na YubiKey, e o SSH usa essa chave por meio de PKCS#11.


Esse método não usa OTP e não depende do YubiCloud. A chave privada permanece protegida na YubiKey, enquanto o servidor SSH valida a autenticação usando a chave pública correspondente.


É uma opção comum em ambientes corporativos ou em cenários onde já existe uso de certificados digitais.



Autenticação SSH com OpenPGP / GPG Agent​

Outra possibilidade é armazenar uma chave OpenPGP na YubiKey e usar o gpg-agent como agente SSH. Nesse modelo, a YubiKey guarda a chave privada OpenPGP, e o gpg-agent expõe essa chave para o cliente SSH.


Esse método também é local, não usa YubiCloud e não depende de servidor de validação OTP. Ele é útil para quem já usa GPG para assinatura, criptografia ou assinatura de commits, e quer aproveitar a mesma chave ou o mesmo fluxo para SSH.



Autenticação SSH com Yubico OTP via PAM​

Nesta seção, configuraremos o SSH para autenticação com YubiKey usando o módulo PAM e validação de OTP via YubiCloud. O YubiCloud, que opera os servidores YK-VAL (Servidor de Validação) e YK-KSM (Servidor de Armazenamento de Chave), será responsável por validar os OTPs gerados pelas YubiKeys. Após a configuração, apenas usuários com uma YubiKey registrada poderão realizar login, usuários sem uma Yubikey não poderão logar, mas isso depende do método de configuração usado.


A Yubico oferece duas opções para associar Chaves YubiKeys a usuários do sistema, (link oficial):

  • Nível Global
    É necessário criar um arquivo único de mapeamento para todos os usuários do sistema, associando cada nome de usuário aos IDs das YubiKeys correspondentes. Cada linha deve seguir o formato: username:ID_YubiKey1:ID_YubiKey2:.....

  • Nível do Usuário
    Como alternativa, cada usuário pode ter um arquivo de mapa pessoal, que deve ficar em $HOME/.yubico/authorized_yubikeys com o mesmo formato acima. Isso permite que usuários mantenham suas próprias YubiKeys autorizadas.



Configuração no Nível Global​

Neste exemplo, vamos usar o nível global para associar YubiKeys aos usuários. Primeiramente, instale a biblioteca necessária para autenticação via PAM:

# Install dependencies
$ sudo apt install -y libpam-yubico

O Token ID é necessário para o mapeamento. Gere-o executando o seguinte comando, substituindo pelo código OTP gerado pela sua YubiKey:

# Obtenha o YubiKey token ID:
echo 'seu_otp_yubikey_aqui' | cut -c1-12

Em seguida, crie ou edite o arquivo de mapeamento, onde você associará cada usuário aos IDs das YubiKeys correspondentes.

# Crie o arquivo contendo o mapeamento entre usuário e IDs das chaves:
$ sudo vim /etc/yubikeyid

# A linha abaixo é apenas um exemplo:
vagrant:ccccccccccci

O Token ID é composto pelos primeiros 12 caracteres do OTP gerado pela YubiKey e deve ser associado ao nome do usuário no arquivo de mapeamento. Acesse o link upgrade.yubico.com/getapikey para obter o Client ID e uma API Key da YubiKey. Esses dados serão necessários na configuração do módulo PAM.


Você não consegue obter o Public ID e Secret Key em upgrade.yubico.com/getapikey

Se você alterou a configuração da Yubikey e não submeteu os dados novos no servidor da YubiCloud, recomendo que reconfigure a chave e submeta os dados para que a autenticação seja possível usando o servidores deles.


Adicione a configuração da YubiKey ao final do arquivo PAM para SSH.

# Edite o pam do ssh:
$ sudo vim /etc/pam.d/sshd

# Adicione a linha abaixo:
auth required pam_yubico.so mode=client id=16 key=20s3a0f debug debug_file=/var/log/yubikey.log authfile=/etc/yubikeyid

Para ativar o debug dos registros de login
$ sudo touch /var/log/yubikey.log
$ sudo chmod go+w /var/log/yubikey.log

$ sudo journalctl -f -l
$ tail -f /var/log/yubikey.log

Não se esqueça de trocar id=16 pelo seu ID e key=20s3a0f pela sua API Key. Este é o Client ID que você obteve no passo anterior. O parâmetro authfile=/etc/yubikeyid especifica o caminho do arquivo de mapeamento onde os IDs das YubiKeys são associados aos usuários.


Caso você tenha ou vá ter seu próprio servidor de validação (conjunto de servidores YK-VAL e YK-KSM), use o exemplo abaixo para autenticar no seu servidor.

auth required pam_yubico.so mode=client urllist=http://192.168.121.66/wsapi/2.0/verify id=1 key=+nzbRHG3/zZUEHuLBSPahBL0XS8= authfile=/etc/yubikeyid

Para que o PAM reutilize a senha informada no primeiro módulo de autenticação, evitando que o usuário precise digitá-la novamente, modifique o arquivo de autenticação comum.

# Edite o pam da autenticação normal:
$ sudo vim /etc/pam.d/common-auth

# Encontre a linha abaixo:
auth   [success=1 default=ignore]      pam_unix.so nullok

# Substitua por esta linha para reutilizar a senha já fornecida:
auth   [success=1 default=ignore]      pam_unix.so nullok try_first_pass

Para finalizar a configuração, ative o suporte à autenticação via PAM no SSH seguindo os passos abaixo:

# Edite o arquivo de configuração do servidor SSH:
$ sudo vim /etc/ssh/sshd_config

# Adicione as linhas abaixo caso ainda não estejam configuradas:
KbdInteractiveAuthentication yes
UsePAM yes

# Reinicie o serviço SSH para aplicar as alterações:
$ sudo systemctl restart sshd ssh

O ChallengeResponseAuthentication virou apenas um alias para KbdInteractiveAuthentication.


A partir de agora será possível logar no SSH usando sua chave Yubikey.


considerações importantes

Ao adicionar auth required pam_yubico.so... no final do arquivo pam.d/sshd, a autenticação via YubiKey ocorre após a senha do usuário ser validada. Isso garante que apenas usuários com credenciais corretas avancem para a etapa de validação da YubiKey.


Se colocarmos a linha no início do arquivo, o sistema tentará validar a YubiKey antes de verificar a senha. Embora isso funcione, introduz um risco de segurança: atacantes poderiam usar o comportamento do sistema para inferir a existência de usuários válidos no sistema. Isso ocorre porque o processo de validação da YubiKey só é executado se o nome do usuário existir e a YubiKey estiver registrada para ele. Essa diferença de comportamento pode ser explorada para mapear nomes de usuários válidos.


Quando configurado ao final, o processo exige que a senha seja avaliada como correta antes de prosseguir para a etapa da YubiKey, reduzindo a exposição a essa vulnerabilidade de enumeração de usuários.



Logando apenas com a yubikey​

Para logar apenas com a Yubikey, sem precisar de uma senha (em todo o sistema), você pode fazer:


/etc/pam.d/common-auth
# Comente a linha abaixo:
#auth   [success=1 default=ignore]      pam_unix.so nullok try_first_pass

# Adicione a linha abaixo:
auth [success=2 default=ignore] pam_yubico.so mode=client urllist=https://192.168.121.66/wsapi/2.0/verify id=1 key=+nzbRHG3/zZUEHuLBSPahBL0XS8= authfile=/etc/yubikeyid

O campo [success=2 default=ignore] é importante porque define as ações com base no resultado da autenticação realizada pelo módulo pam_yubico.so. O success=2 faz com que, se a autenticação for bem-sucedida, o fluxo de autenticação avance duas etapas, pulando as próximas duas regras de auth, como se a autenticação já tivesse sido concluída com sucesso. Já o default=ignore determina que, para qualquer outro resultado (como falha na autenticação), esta regra será ignorada, e o PAM continuará avaliando a próxima regra na configuração.



Aplicar a autenticação no common-auth​

Até aqui, a configuração foi feita no arquivo /etc/pam.d/sshd, afetando apenas o login via SSH. Também é possível configurar o pam_yubico.so no arquivo /etc/pam.d/common-auth. Essa abordagem faz com que a autenticação com YubiKey passe a valer para todos os serviços que incluem o common-auth, como SSH, sudo, su, login em TTY e, dependendo do ambiente, login gráfico.


Antes de alterar o arquivo, mantenha uma sessão root aberta e faça um backup:

sudo cp /etc/pam.d/common-auth /etc/pam.d/common-auth.bkp

O arquivo final deve ficar assim:

/etc/pam.d/common-auth
# here are the per-package modules (the "Primary" block)
auth    [success=1 default=ignore]      pam_unix.so nullok try_first_pass

# here's the fallback if no module succeeds
auth    requisite                       pam_deny.so

auth    [success=1 default=ignore]      pam_yubico.so mode=client urllist=http://192.168.121.66/wsapi/2.0/verify id=1 key=+nzbRHG3/zZUEHuLBSPahBL0XS8= authfile=/etc/yubikeyid

# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth    required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth    optional                        pam_cap.so
# end of pam-auth-update config

Observações

Esse modelo implementa 2FA, já que exige a senha validada pelo pam_unix e, em seguida, a YubiKey validada pelo pam_yubico. A ordem das regras PAM é importante para garantir que os dois fatores sejam realmente exigidos.


Como o Yubico OTP precisa ser validado por um servidor externo ou próprio, a indisponibilidade desse servidor pode impedir a autenticação.


A regra auth requisite pam_deny.so garante que, se nenhuma das regras anteriores for bem-sucedida, o acesso será negado imediatamente. Ao adicionar o módulo pam_yubico.so depois dessa linha, ele será avaliado como parte do fluxo de autenticação sem interferir nas configurações padrão do sistema.


CUIDADO

Vale destacar que este modelo configura a autenticação com YubiKey de forma abrangente para todos os métodos de autenticação do sistema. Isso inclui autenticações realizadas via SSH, login local em terminais (TTY), troca de usuário com su, autenticação em interfaces gráficas e também durante o uso de comandos protegidos pelo sudo.


A aplicação global ocorre porque as configurações do arquivo common-auth são utilizadas como base para todos os processos de autenticação gerenciados pelo Pluggable Authentication Modules (PAM) no sistema.



Autenticação SSH com chave FIDO2 pelo OpenSSH​

O FIDO2 pode ser usado para login sem senha, 2FA ou múltiplo fator. Já o FIDO U2F/CTAP1, é voltado para ser usado apenas como 2FA. Em autenticações baseadas em senha ou OTP, o serviço recebe um segredo ou código informado pelo usuário. Já em autenticações com chave pública, como SSH e CTAP1/FIDO2, o segredo não precisa ser enviado ao servidor.


Mesmo que a senha esteja protegida no servidor por hash, ela continua sendo um segredo reutilizável. Se alguém descobrir a senha, pode usar ela novamente em outro login.


Já com o FIDO, a lógica muda. O serviço não precisa receber a chave privada, nem um segredo que possa ser reutilizado depois. Ele recebe uma resposta criptográfica assinada para um desafio específico daquele login. Durante o cadastro, o autenticador cria um par de chaves, como uma chave privada/pública do SSH.


Durante o login, o servidor SSH envia um desafio, que é um valor único gerado para aquela tentativa de autenticação. A YubiKey assina esse desafio usando a chave privada. O servidor recebe essa assinatura e valida usando a chave pública cadastrada.


Com isso, o serviço não precisa conhecer a chave privada. Ele só precisa confirmar que a resposta recebida foi assinada por quem possui a chave privada correspondente à chave pública registrada.


A YubiKey assina o desafio usando a chave privada da credencial FIDO.

Dependendo de como a chave foi criada e do modelo da YubiKey, essa assinatura pode exigir apenas a presença física do YubiKey, ou também uma verificação local do usuário.


No caso mais simples, o usuário precisa apenas conectar a YubiKey, digitar a passphrase da chave do SSH (se configurada) e tocar na YubiKey. Esse toque confirma a presença do usuário.


Em uma configuração com verificação obrigatória, como ao usar -O verify-required, a YubiKey também exige uma verificação local antes de permitir a assinatura. Essa verificação pode ser feita por PIN ou por biometria (para modelos compatíveis como a YubiKey Bio).


Podemos usar os seguintes comandos para identificar o modelo da YubiKey pelo terminal (instale o pacote yubikey-manager para ter os comandos):

# Listando as YubiKey conectadas e exibindo o modelo:
$ ykman list
YubiKey 4 (4.3.7) [OTP+FIDO] Serial: xxxxxxx

# Obtendo mais informações das YubiKey conectadas:
$ ykman info
Device type: YubiKey 4
Serial number: xxxxxxx
Firmware version: 4.3.7
Enabled USB interfaces: OTP, FIDO

Applications
OTP             Enabled
FIDO U2F        Enabled
FIDO2           Not available
OATH            Disabled
PIV             Disabled
OpenPGP         Disabled
YubiHSM Auth    Not available

Se sua chave possui suporte para FIDO2, use o comando abaixo para ver o status geral do FIDO2. Como eu não tenho suporte, vai dar erro:

$ ykman fido info
PIN is not supported.

# Caso você tenha FIDO2:
$ ykman fido info
PIN is set, with 8 attempt(s) remaining.

O OpenSSH 8.2 adicionou suporte a autenticadores FIDO U2F/FIDO2 com os tipos de chave ecdsa-sk e ed25519-sk. No OpenSSH, o tipo ecdsa-sk possui maior compatibilidade com autenticadores FIDO/U2F mais antigos, enquanto que o tipo ed25519-sk depende de suporte específico do hardware e normalmente está disponível apenas em chaves mais novas, como modelos com FIDO2.


As YubiKeys Series 4 por não possuir suporte a FIDO2 só podem usar chaves ecdsa-sk, enquanto que as YubiKeys Series 5, Security Key Series e YubiKey Bio series possuem suporte a ed25519-sk.


Diferença das chaves ecdsa-sk e ed25519-sk

No OpenSSH, as chaves ecdsa-sk e ed25519-sk são tipos de chave SSH que depende de uma chave física FIDO. A chave privada necessária para assinar fica associada a chave física, e o arquivo SSH local pode ainda ser protegido por passphrase.


O sufixo -sk significa security key, indicando que a chave depende de um autenticador físico, como uma YubiKey. A diferença principal está no algoritmo usado e no suporte do hardware. A ecdsa-sk é uma chave ECDSA com curva P-256, já a ed25519-sk é uma chave Ed25519.


A ed25519 é mais usada hoje em dia porque é a opção mais moderna, rápida e menos propensa a erros de implementação do que ecdsa. O OpenSSH adicionou suporte a ed25519 na versão 6.5 e descreveu esse tipo de chave como uma assinatura de curva elíptica com melhor segurança que ECDSA e DSA, além de bom desempenho.


A principal diferença técnica está no desenho do algoritmo. A ecdsa depende fortemente da geração correta de um valor aleatório único para cada assinatura. Se esse valor for reutilizado ou gerado de forma fraca, a chave privada pode ser comprometida.


Já a ed25519, usa EdDSA sobre a curva Ed25519. Esse modelo foi projetado para ser determinístico, rápido e mais simples de implementar corretamente. Isso reduz o risco de falhas causadas por aleatoriedade ruim durante a assinatura.


Agora vamos criar a chave usando ecdsa-sk. Durante a criação, será necessário encostar na chave:

ssh-keygen -t ecdsa-sk -C "teste@yubikey4"

Agora vamos criar a chave usando ed25519-sk. Durante a criação, podemos definir uma opção para a chave em questão. As principais opções para trabalhar com a Yubikey que suporta FIDO2 são:

OpçãoO que fazQuando usar
-O residentGuarda a credencial como residente no autenticadorQuando quer recuperar a chave em outro computador com ssh-keygen -K
-O verify-requiredExige verificação local do usuárioQuando quer exigir PIN ou biometria
-O application=ssh:nomeDefine o identificador da aplicação/RP ID usado pela credencial FIDOQuando quer separar várias credenciais na mesma chave
-O user=nomeDefine o usuário associado à credencialÚtil com resident keys
-O no-touch-requiredTenta dispensar o toque físicoEvite em SSH comum, só use se souber bem o impacto
ssh-keygen -t ed25519-sk -C "teste@yubikey4"

Para uma chave mais moderna, quando suportada.

ssh-keygen -t ed25519-sk -O resident -O application=ssh:lab-teste -O user=vagrant-test -O verify-required -C "teste@yubikey5"

Após a criação da chave, adicione ela no ~/.ssh/authorized_keys. Para chaves ed25519-sk, pode ser necessário usar algumas opções no SSH como -o IdentityAgent=none.

É bom deixar claro que o uso de -o IdentityAgent=none não é uma exigência da ed25519-sk. Só é necessário fazer isso em alguns ambientes quando um ssh-agent atrapalha a seleção da chave.


Com isso você já pode fazer SSH usando Yubikey com FIDO.

deletar a chave ssh da Yubikey

Se você criou a chave ssh com -O resident, vai existir um backup da chave SSH entro da YubiKey. Você pode baixar essa chave usando o comando abaixo:

ssh-keygen -K

Para apagar a chave da Yubikey faça:


# Liste as credenciais residentes:
$ ykman fido credentials list
Enter your PIN: 
Credential ID  RP ID                Username                 Display name
aaaaaaaa...    yyyyyyyyyyyyyyyyyyy  xxxxxxxxxxxxxxxxx              
bbbbbbbb...    zzzzzzzzzzzzzzzzzzz  ppppppppppppppppp                               
cccccccc...    ssh:lab-teste        openssh                  openssh     

# Delete a chave com o comando abaiixo:
ykman fido credentials delete <CREDENTIAL_ID>


Autenticação Local com Challenge-Response HMAC-SHA1 via PAM​

Neste exemplo, não vamos demonstrar o passo a passo da configuração. Esse método permite usar a YubiKey para autenticação local de forma totalmente offline, sem depender do YubiCloud ou de outro servidor externo de validação.


Para que esse método funcione, é necessário configurar um dos slots OTP da YubiKey no modo Challenge-Response HMAC-SHA1. O sistema envia um desafio para a YubiKey, que calcula uma resposta usando o segredo armazenado no dispositivo. O PAM compara essa resposta com o valor esperado e, se estiver correta, permite a autenticação.


Esse método é mais indicado para cenários como login local, TTY, sudo, su e estações de trabalho. Em SSH remoto comum, ele não é o método mais prático, porque o PAM é executado no servidor enquanto a YubiKey normalmente está conectada no computador do usuário.


Para mais detalhes sobre a configuração, consulte a documentação oficial da Yubico sobre autenticação Challenge-Response com PAM.



Autenticação local usando FIDO U2F/FIDO2 com pam_u2f​

Nesta seção, implementaremos a autenticação de dois fatores (2FA) no Linux, exigindo que o usuário esteja com a YubiKey conectada no momento do login local. Esse método utiliza o módulo PAM para autenticação, mas, ao contrário do método que usa um servidor de validação, não requer validação online, pois todo o processo ocorre offline.


A partir do momento em que o pam_u2f for configurado como fator obrigatório no serviço PAM, o usuário precisará possuir uma YubiKey ou outro autenticador FIDO previamente cadastrado para concluir a autenticação.


Essa configuração pode ser feita em dois níveis: Global e Usuário. Aqui, descreveremos o processo no Nível Global, onde o mapeamento de usuários e YubiKeys é centralizado em um único arquivo. O formato para configurar o arquivo de mapeamento de usuários e YubiKeys é o seguinte:

<username>:<KeyHandle1>,<UserKey1>,<CoseType1>,<Options1>:<KeyHandle2>,<UserKey2>,<CoseType2>,<Options2>:…

Abaixo está uma explicação para cada campo no formato de mapeamento de usuários e chaves para autenticação local com FIDO U2F:

  • username: O nome do usuário no sistema Linux que está autorizado a usar a YubiKey para autenticação. Esse campo permite que o sistema associe a YubiKey ao usuário específico durante o login.

  • KeyHandle1: Um identificador único gerado para a chave pública U2F associada ao usuário. Esse KeyHandle é utilizado para identificar a chave correta armazenada na YubiKey durante o processo de autenticação.

  • UserKey1: A chave pública do usuário registrada para autenticação. Essa chave pública é associada ao KeyHandle e utilizada pelo servidor para verificar a autenticidade do desafio (challenge) recebido durante o login.

  • CoseType1: Indica o tipo de chave de criptografia usada (também conhecida como algoritmo COSE). Em geral, FIDO U2F utiliza ES256 (que representa o algoritmo ECDSA com curva P-256) como padrão, mas outras opções podem existir dependendo da configuração e do dispositivo.

  • Options1: Este campo é utilizado para definir opções adicionais de configuração para o dispositivo. Alguns exemplos de opções comuns incluem up=true para indicar que a autenticação requer uma ação do usuário, como tocar na YubiKey, ou uv=false para especificar que a verificação do usuário não é necessária.


Primeiramente, instale a biblioteca necessária para autenticação via PAM:

# Install dependencies
$ sudo apt install -y libpam-u2f pamu2fcfg

Agora vamos gerar os dados necessários para efetuar a autenticação da Yubikey do usuário:

# Quando a yubikey piscar, toque nela!
pamu2fcfg -u fulano >> /etc/u2f_mappings

Para configurar a YubiKey no gerenciador de login do Ubuntu 22.04 (GDM), adicione a seguinte configuração ao final do arquivo /etc/pam.d/gdm-password:

# Edite o arquivo:
$ sudo vim /etc/pam.d/gdm-password

# Encontre a linha abaixo:
@include common-auth

# Após a linha acima, coloque a configuração abaixo em baixo da linha acima:
auth required pam_u2f.so authfile=/etc/u2f_mappings debug_file=/var/log/yubikey_gdm_u2f.log

# Reinicie o GDM:
$ sudo systemctl restart gdm

Para ativar o debug dos registros de login
$ sudo touch /var/log/yubikey_gdm_u2f.log
$ sudo chmod go+w /var/log/yubikey_gdm_u2f.log

Podemos configurar a YubiKey para autenticação em diversos módulos PAM, alguns deles são:

  • gdm-password e lightdm
    Utilizados pelos gerenciadores de login gráfico, como o GDM e o LightDM, esses módulos permitem implementar autenticação em dois fatores (2FA) com FIDO U2F no login via interface gráfica (não funciona na troca de usuário via terminal).


  • sudo
    Configurado no módulo PAM do comando sudo, este método adiciona 2FA ao sudo, oferecendo uma camada extra de segurança além do controle de permissões padrão.


  • login
    Utilizado para logins em terminais TTY (usado ao trocar de usuário via CLI), permitindo que sessões de terminal tenham autenticação protegida com YubiKey e FIDO U2F.



Configurando o UDEV - Opcional​

Podemos configurar o udev para bloquear as sessões do sistema quando a YubiKey for removida do computador.

# Crie o arquivo com a regra:
sudo tee /etc/udev/rules.d/80-yubilock.rules > /dev/null <<'EOF'
ACTION=="remove", SUBSYSTEM=="usb", ATTRS{idVendor}=="1050", RUN+="/usr/bin/loginctl lock-sessions"
EOF

# Corrija as permissões do arquivo:
sudo chmod 644 /etc/udev/rules.d/80-yubilock.rules

# Recarregue as regras do udev:
sudo udevadm control --reload

# (Opcional) força o udev a reavaliar os dispositivos, caso esteja conectado:
sudo udevadm trigger

como obter o idvendor?

Para obter o idVendor da Yubikey ou de qualquer outro dispositivo USB, basta executar o comando abaixo:

$ lsusb -v -d $(lsusb | grep -i yubikey | awk '{ print $6 }') | grep -i 'idVendor'
  idVendor           0x1050 Yubico.com