Gravar firmware não apaga o PIN
Gravar outro firmware atualiza o programa que será carregado e executao, mas isso não deleta um PIN já configurado, já que ele está guardado na flash, assim como credenciais residentes.
No FIDO, para apagar esses dados e definir outro PIN, precisamos executar fido2-token -R /dev/hidrawX até 10 segundos após conectar a placa e confirmar a operação tocando no botão de BOOT. Se passar dessa janela de 10 segundos, o dispositivo rejeita o reset do PIN. Esse procedimento apaga também as credenciais residentes.
No HSM, o PIN e o SO-PIN também permanecem após atualizar o firmware, para resetar podemos usar o comando abaixo:
sc-hsm-tool --initialize --pin ask:
A janela de 10 segundos é somente para o reset FIDO, para o HSM essa janela não existe.
Autenticação SSH usando FIDO2
O OpenSSH possui suporte à autenticação usando dispositivos físicos compatíveis com CTAP1/FIDO U2F e CTAP2/FIDO2, como as YubiKeys e dispositivos que usam o firmware Pico FIDO. Esse é um dos métodos mais modernos de autenticação SSH, já quele permite usar uma chave física para realizar as operações criptográficas, sem precisar armazenar a chave privada criptográfica diretamente no computador.
Esse suporte foi adicionado no OpenSSH 8.2 e trouxe com ele os tipos de chave ecdsa-sk e ed25519-sk. Esse sufixo -sk significa Security Key, ele serve para mostrar que essas chaves dependem de um autenticador físico. Nesse método de autenticação, a chave FIDO precisa estar conectado ao computador e a chave pública precisa ser configurada no arquivo ~/.ssh/authorized_keys, o processo é igual ao cadastrar uma chave SSH, mas aqui, a chave privada fica no FIDO físico e não no computador (essa é a única diferença).
Durante o login, o cliente SSH solicita ao autenticador que assine o desafio da autenticação. Dependendo de como a chave foi criada, será necessário tocar no dispositivo e informar o PIN ou realizar a verificação biométrica. O dispositivo realiza a assinatura usando a credencial criptográfica protegida pelo hardware, e o servidor SSH valida essa assinatura usando a chave pública cadastrada.
A chave privada criptográfica não é exportada do autenticador durante esse processo.
Diferença entre ecdsa-sk e ed25519-sk
O OpenSSH possui dois tipos de chaves para autenticação usando dispositivos FIDO:
ecdsa-sk: usa o algoritmo ECDSA com a curva NIST P-256.ed25519-sk: usa o algoritmo Ed25519.
A principal diferença entre elas está no algoritmo criptográfico usado e na compatibilidade com os dispositivos físicos. A ecdsa-sk possui maior compatibilidade com autenticadores antigos (que implementam o CTAP1/FIDO U2F). Já a ed25519-sk depende de suporte específico do firmware e do hardware, não sendo disponibilizada por todos os dispositivos FIDO2.
O algoritmo Ed25519 é considerado uma opção moderna por apresentar bom desempenho e usar um modelo de assinatura determinístico, reduzindo a dependência de números aleatórios durante as operações criptográficas.
No ECDSA, a geração incorreta ou reusação do valor usado em uma assinatura pode comprometer a chave privada. O Ed25519 foi projetado para evitar esse tipo de problema, tornando sua implementação menos propensa a determinadas falhas. Mas isso não significa que o ECDSA seja inseguro.
Criando uma chave SSH usando FIDO2
Para criar uma chave SSH usando o autenticador físico, podemos usar o comando ssh-keygen, informando o tipo de chave desejado. O exemplo abaixo cria uma chave ecdsa-sk:
ssh-keygen -t ecdsa-sk \
-O verify-required \
-f ~/.ssh/id_ecdsa_sk
Para criar uma chave ed25519-sk:
ssh-keygen -t ed25519-sk \
-O verify-required \
-f ~/.ssh/id_ed25519_sk
Durante a criação, o OpenSSH solicitará a interação com o dispositivo físico. Como estamos usando a opção -O verify-required, também será necessário realizar a verificação do usuário, normalmente informando o PIN do autenticador.
Após a criação, teremos dois arquivos:
~/.ssh/id_ed25519_sk
~/.ssh/id_ed25519_sk.pub
O arquivo id_ed25519_sk.pub contém a chave pública, que deverá ser cadastrada no servidor SSH. Já o arquivo id_ed25519_sk, apesar de ser identificado pelo OpenSSH como uma chave privada, não contém a chave privada convencional exportada do dispositivo. Esse arquivo é uma chave privada, mas essa chave fica ligada a chave física (autenticador).
Isso significa que, mesmo que alguém copie esse arquivo, ainda será necessário possuir o dispositivo físico correspondente para conseguir realizar a autenticação.
Opções disponíveis no ssh-keygen
O OpenSSH possui algumas opções específicas para trabalhar com chaves FIDO, como:
| Opção | O que faz |
|---|---|
-O resident | Armazena a credencial como residente no dispositivo, permitindo recuperar ela posteriormente. |
-O verify-required | Exige a verificação do usuário, normalmente através de PIN ou biometria. |
-O application=ssh:nome | Define um identificador de aplicação para separar as credenciais no autenticador. |
-O user=nome | Define um identificador de usuário associado à credencial. |
-O no-touch-required | Solicita uma chave que não exija confirmação de presença física. |
A opção -O verify-required é interessante porque adiciona uma camada de segurança, exigindo que o usuário realize uma verificação antes que o autenticador autorize a assinatura (como solicitar o PIN). Nesse caso será solicitado o passphrase mais o PIN ou biometria.
Já a opção -O no-touch-required deve ser usada com cuidado, pois permite dispensar o toque físico durante a autenticação SSH (precisa adicionar no-touch-required antes da chave pública). Para o uso comum do SSH, sempre mantenha a necessidade de interação física com o autenticador.
Credenciais residentes e não residentes
Uma diferença importante ao usar FIDO2 com SSH está na possibilidade de criar credenciais residentes ou não residentes. Por padrão, o OpenSSH cria credenciais não residentes (não usa -O resident). No entanto, podemos usar a opção -O resident para permitir que as informações necessárias para recuperar a credencial SSH sejam armazenadas no próprio dispositivo físico.
Essa diferença interfere diretamente na recuperação das chaves e também na segurança em caso de perda ou roubo do autenticador, então vou deixar bem claro, nunca crie chaves SSH usando -O resident.
Quando criamos uma chave sem usar -O resident, o OpenSSH cria uma credencial não residente, ou seja, não conseguimos listar ela no autenticador. Eu criei várias chaves no meu FIDO, vários deles são SSH, mas apenas duas chaves SSH com -O resident:
$ fido2-token -L -r /dev/hidraw10
Enter PIN for /dev/hidraw10:
00: ZfO2CpxLhho6OOuPOZT0HGrVPfsoOTxivph3XtrxA5w= www.token2.com
01: 4wYQ6KFiEVlg/h7CI+ZSnJ9LboAgDcteXDIcivHisb8= ssh:
02: 7Y7pvuO/vNaeWbj7fnKxz2+M4yygjsxHEslxBTfhiFM= ssh:ed25519-test
O problema que essa segurança a mais nos traz, caso você perca a chave pública e/ou o arquivo que armazena as informações necessárias para que o OpenSSH consiga usar a credencial protegida pelo autenticador, não será possível obter esses arquivos. Você terá que criar outra credencial, no entanto, isso fornece um modelo de segurança mais forte.
Se você criou como residente, vou deixar abaixo como obter ambos os arquivos:
## Exportar somente a chave pública do Pico FIDO.
# Exporta as credenciais residentes do Pico FIDO:
$ ssh-keygen -K
Enter PIN for authenticator:
You may need to touch your authenticator to authorize key download.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Saved ECDSA-SK key to id_ecdsa_sk_rk
Saved ED25519-SK key ssh:ed25519-test to id_ed25519_sk_rk_ed25519-test_ed25519-test
$ ls -l
total 16
-rw------- 1 bruno bruno 630 Nov 1 19:41 id_ecdsa_sk_rk
-rw-r--r-- 1 bruno bruno 213 Nov 1 19:41 id_ecdsa_sk_rk.pub
-rw------- 1 bruno bruno 533 Nov 1 19:41 id_ed25519_sk_rk_ed25519-test_ed25519-test
-rw-r--r-- 1 bruno bruno 161 Nov 1 19:41 id_ed25519_sk_rk_ed25519-test_ed25519-test.pub
Vale mencionar que esse processo permite configurar uma nova passphrase para os arquivos de chave privada SSH recuperados do autenticador FIDO2.
O grande benefício aqui é que se alguém roubar a chave física (autenticador) e consiga descobrir o PIN, essa pessoa não vai conseguir recuperar diretamente uma credencial SSH não residente se não possuir também o arquivo local correspondente, isso cria um modelo MFA para autenticação.
Gerenciando chaves
Tanto com Yubikey quanto com Pico FIDO com VID/PID da Yubikey, podemos usar o comando ykman para gerenciar tantos credenciais FIDO para WebAuth quanto para SSH.
# Listando as credenciais:
$ ykman fido credentials list
WARNING: PC/SC not available. Smart card (CCID) protocols will not function.
ERROR: Unable to list devices for connection
Enter your PIN:
Credential ID RP ID Username Display name
3c99f2caf1d002060000b6... www.token2.com token2_user_44687427
3c99f2caf1d00206000048... ssh: openssh openssh
3c99f2caf1d00206000034... ssh:ed25519-test openssh openssh
Para remover uma credencial específica:
ykman fido credentials delete <CREDENTIAL_ID>
Limpando as Credenciais Residentes e Não Residente
Lembrando que gravar outro fiemware não apaga as credenciais, tanto as Residentes quanto as Não Residente. Para maior segurança caso você queira zerar o autenticador, o procedimento correto é fazer um reset completo do autenticador FIDO2. Esse é o mesmo procedimento para resetar o PIN caso você esqueça.
Primeiro, identifique o dispositivo:
$ fido2-token -L
/dev/hidraw10: vendor=0x1050, product=0x0407 (Pol Henarejos Pico Key)
Depois, desconecte e reconecte o dispositivo e execute:
fido2-token -R /dev/hidraw10
Esse reset deve invalidar todas as credenciais FIDO2, residentes e não residentes, além de remover o PIN configurado. Para gerar um novo firmware podemos usar os comandos abaixo (para o ykman a chave Pico FIDO precisa ser compilada com VID/PID Yubikey):
# Definir PIN usando ykman:
ykman fido access change-pin
### Usando fido2-token:
# Identifique o dispositivo:
fido2-token -L
# Defina um novo PIN:
fido2-token -S /dev/hidrawX