YubiKey: compilado (com criptografia, Linux e o que mudou de lá para cá)

Escrevi uma série de artigos sobre YubiKey ao longo dos últimos anos. A ideia original era simples: sair do “2FA por obrigação” e chegar no “2FA/MFA por arquitetura”. No caminho, a chave deixou de ser um penduricalho caro e virou um componente útil de um setup coerente: Linux mais duro, SSH menos dependente de arquivos sensíveis, GPG menos exposto e autenticação mais resistente a phishing.

Este post é um resumo unificado dos artigos anteriores, com links diretos para referência, e com atualizações técnicas que fazem sentido em 2026 — especialmente no eixo FIDO2/WebAuthn, passkeys e políticas de PIN/gestão que evoluíram bastante. Também conecto com outros textos meus sobre criptografia, porque YubiKey é uma consequência prática: você para de falar “cripto” como conceito abstrato e passa a operacionalizar chaves, assinatura, identidade e risco.

Antes de tudo: YubiKey não é “um 2FA melhorado”

A tentação é tratar YubiKey como “o mesmo 2FA, só que em USB”. Isso é reduzir o assunto ao pior caso de uso: OTP digitável, dependente do usuário, exposto a phishing e a UXs tortas. O valor real aparece quando você entende que ela suporta múltiplos protocolos e que cada um deles muda o tipo de ataque que você precisa derrotar.

Quando você sai de códigos e entra em FIDO2/WebAuthn, por exemplo, você não está “melhorando 2FA”, você está mudando a categoria: a autenticação fica vinculada ao origin (o site), e isso reduz drasticamente a classe de ataque baseada em páginas falsas e coleta de segredo reutilizável. Quando você leva a chave para SSH, você reduz o impacto do roubo/exfiltração do seu $HOME. Quando leva para OpenPGP, você diminui a exposição do material de chave e melhora sua disciplina de subkeys e finalidades.

Parte 1 — A série original

YubiKey #1 — Introdução ao 2FA

No primeiro artigo estabeleço o motivo da série existir: senhas vazam, usuários reutilizam, e qualquer mecanismo “extra” que ainda dependa do usuário digitar um segredo é melhor do que nada, mas continua com falhas previsíveis.

A chave física entra como fator de posse para elevar a barra e reduzir o efeito dominó de credenciais comprometidas. O ponto importante ali é o enquadramento: YubiKey não é só um gerador de código. É um autenticador multi-protocolo. Isso muda a conversa de “qual app de token eu uso” para “qual protocolo eu escolho para o meu risco”. Link: https://esli.blog.br/yubikey-introducao

YubiKey #2 — Linux instalação: plug-and-play, pcscd e ferramentas

No segundo artigo trago o contexto do Linux: muitas funções básicas funcionam sem instalar nada porque parte do comportamento pode aparecer como dispositivo HID (teclado) para OTP. Só que a vida real (OATH no Authenticator, PIV, OpenPGP) passa pelo stack de smartcard e ferramentas como o Yubico Authenticator e o YubiKey Manager.

O artigo também faz um inventário do que uma YubiKey 5 NFC suporta e por que isso importa: FIDO U2F/FIDO2, OTP, OATH, PIV, OpenPGP. A consequência prática é clara: antes de “configurar”, você precisa decidir o que vai usar e o que vai desabilitar, porque deixar tudo ligado por padrão costuma ser o jeito mais eficiente de colecionar surpresas. Link: https://esli.blog.br/yubikey-linux-instalacao

YubiKey #3 — Console, sudo e SSH

O terceiro artigo é onde a YubiKey deixa de ser “2FA de site” e vira controle local de privilégio.

Eu mostro dois caminhos no PAM: um baseado em Yubico OTP (libpam-yubico com API ID/secret e mapeamento de usuários/keys) e outro baseado em U2F (libpam-u2f com pam_u2f e pamu2fcfg).

O resultado prático é endurecer login em console e, principalmente, exigir presença do token para sudo. Isso ataca um cenário comum: a senha do usuário foi obtida (ou a sessão foi “emprestada”), e agora virar root é só uma questão de hábito. Com a chave no fluxo, o atacante precisa também do hardware e do momento. Eu também deixo registrado o detalhe que muita gente ignora: “colocar PAM no SSH” não cria automaticamente um 2FA remoto robusto. Sem desenho de fluxo e parâmetros corretos, você quebra acesso ou cria uma falsa sensação de segurança. Link: https://esli.blog.br/yubikey-console-sudo-ssh

YubiKey #4 — OpenSSH + YubiKey (ed25519 e afins)

No quarto artigo entro no uso para SSH, e isso é uma das melhores aplicações para infraestrutura: reduzir o impacto de exfiltração de chaves privadas e aumentar o custo de ataque local.

A ideia é simples, mas tem implicação profunda: em vez de o host guardar um segredo que te representa, ele guarda um identificador e delega a operação de assinatura para o hardware no momento do login. Na prática, você reduz a “portabilidade acidental” de credenciais. Backups ficam menos perigosos, dotfiles vazados ficam menos catastróficos, e o atacante que conseguir ler seu disco não ganha automaticamente sua identidade SSH. Isso não resolve endpoint comprometido, mas muda o tipo de incidente e o esforço necessário para persistência. Link: https://esli.blog.br/yubikey-ssh-ed25519-ecdsa

YubiKey #5 — Chaves GPG: subkeys, finalidades e o prazer de parar de improvisar criptografia

O quinto artigo amarra criptografia aplicada com a chave: geração de chaves RSA e ECC no GnuPG, criação de subkeys, e o uso correto por finalidade. Eu bato em um ponto que vale repetir: uma chave não deveria ser “faz tudo”. Subkeys existem para separar assinatura, criptografia e autenticação; isso melhora segurança e também melhora sua capacidade de operar com disciplina (revogar, rotacionar, isolar).

Além do básico de gpg --gen-key e do fluxo de export/backup, o artigo entra em keytocard para mover material para a YubiKey e operar no modelo de smartcard. O ganho não é “criptografar mais”: é expor menos o material que realmente importa. Link: https://esli.blog.br/yubikey-chaves-gpg

Parte 2 — Onde a criptografia entra (e os meus outros artigos que se conectam com isso)

YubiKey não substitui criptografia. Ela é uma forma de forçar criptografia a sair do plano do “conceito correto” e entrar no plano do “uso correto”.

Em outras palavras: ela te obriga a pensar em identidade, chaves, finalidades, recuperação e falhas.

Isso conversa diretamente com outros textos meus: Em “Criptografia para iniciantes”, eu explico a base: simétrica vs assimétrica, hash, salt e por que confundir integridade com confidencialidade dá ruim. Esse é o pano de fundo que ajuda a entender por que “um código de 6 dígitos” (TOTP) não é do mesmo universo de uma autenticação vinculada ao origin (FIDO2). Link: https://esli.blog.br/criptografia-para-iniciantes

Em “Ferramentas para Criptografia” e “Como escolher Ferramentas de Criptografia”, eu puxo o assunto para o lado pragmático: escolher ferramenta por caso de uso, reduzir fricção, evitar complexidade desnecessária e, principalmente, não usar OpenPGP como martelo universal quando a sua dor é outra. YubiKey entra aqui como “hardening do material de chave”, não como “mais uma ferramenta de cripto”. Links: https://esli.blog.br/ferramentas-para-criptografia e https://esli.blog.br/como-escolher-ferramentas-de-criptografia

E em “O que é o WireGuard?”, eu mostro um exemplo de criptografia moderna bem aplicada: algoritmos sólidos, design direto, pouca área para erro humano e operação simples. É a mesma filosofia que justifica trocar 2FA frágil por autenticação resistente a phishing quando o ecossistema permite. Link: https://esli.blog.br/o-que-e-o-wireguard

Parte 3 — Atualizações que importam (FIDO2, passkeys e firmware recente)

O ecossistema avançou. A palavra da moda virou “passkeys”, mas a parte importante é: FIDO2/WebAuthn é a rota mais curta hoje para reduzir phishing como classe de ataque, e não só “adicionar um segundo passo”.

A Yubico publicou evoluções relevantes na linha YubiKey 5 com firmware 5.7, com aumento de capacidade de armazenamento para credenciais, melhorias de gerenciamento de PIN e recursos voltados a ambientes enterprise, incluindo opções como enterprise attestation e mudanças ligadas a CTAP 2.1. Referência oficial: https://www.yubico.com/blog/now-available-for-purchase-yubikey-5-series-and-security-key-series-with-new-5-7-firmware/

Para quem quer detalhe técnico (em vez de marketing), o manual técnico da Yubico documenta matriz de capacidades por versão de firmware e explica recursos e limitações com mais precisão, inclusive deixando explícito um ponto que muita gente insiste em ignorar: firmware não é atualizável pelo usuário; se você quer firmware novo, você compra chave nova. Referência: https://docs.yubico.com/hardware/yubikey/yk-tech-manual/yk5-firmware-overview.html e detalhes 5.7/5.6 aqui: https://docs.yubico.com/hardware/yubikey/yk-tech-manual/5.7-firmware-specifics.html

Parte 4 — O que eu considero “uso bom” de YubiKey em 2026

O uso bom é aquele que reduz classes de ataque e melhora sua operação. Não é o que te dá mais sensação de segurança.

Para contas web: priorize FIDO2/WebAuthn quando existir. O salto de segurança é estrutural, porque você deixa de depender de segredo digitável e depende de autenticação vinculada ao serviço certo.

Para Linux local: se você faz coisas que importam, exigir token no sudo é uma das melhores relações custo/benefício. Não porque “ninguém vai virar root”, mas porque você corta o caminho mais comum do ataque oportunista.

Para SSH: hardware-backed auth muda o impacto de exfiltração de credenciais. Não cura endpoint comprometido, mas reduz o estrago de vazamento passivo e deixa a identidade mais difícil de clonar.

Para criptografia pessoal/profissional: OpenPGP com subkeys por finalidade e operação via smartcard é o tipo de disciplina que evita gambiarra virar hábito. Aqui a YubiKey é menos “segurança extra” e mais “governança mínima para não se auto-sabotar”.

E a regra que eu trataria como não-negociável: se você usa uma chave, tenha duas. A primeira é a que você carrega. A segunda é a que te impede de transformar “perdi um objeto” em “perdi minha identidade digital”.

Backup codes offline continuam existindo por um motivo.

Conclusão

A série começou como 2FA e acabou como identidade e controle de risco. Se você usa YubiKey só para cuspir OTP, você está usando o modo mais frágil do ecossistema — útil, mas longe do melhor. O valor aparece quando você move autenticação para FIDO2/WebAuthn onde der, usa o hardware para reduzir exfiltração em SSH e trata criptografia (GPG) como algo que merece separação de funções e operação com menos exposição.

Este post é um índice comentado da série, mas também um lembrete: segurança que depende de disciplina perfeita do usuário é cara e falha. Segurança que melhora o desenho do sistema é mais barata no longo prazo e falha de forma menos humilhante.