KeeChallenge para YubiKey, e por que você deveria evitá-lo
O KeeChallenge é um plugin que adiciona suporte a YubiKey no KeePass 2. No entanto, ele apresenta vários problemas. Este artigo discute esses problemas e soluções alternativas.
Como o KeeChallenge funciona
O KeeChallenge criptografa o banco de dados com a chave secreta HMAC (S). Essa chave é armazenada na YubiKey e é usada para gerar respostas. Além disso, o KeeChallenge criptografa a S com o par desafio-resposta pré-calculado e armazena o segredo criptografado e o desafio em um arquivo XML auxiliar.
Quando você desbloqueia o banco de dados:
- O KeeChallenge carrega o desafio C do arquivo XML e o envia à YubiKey
- A YubiKey transforma o desafio (usando o segredo S armazenado na chave) e retorna uma resposta R
- A resposta R é usada para descriptografar o segredo Senc armazenado no arquivo XML.
- O segredo descriptografado S é usado para descriptografar o banco de dados. É importante notar que este é o mesmo segredo armazenado na YubiKey.
- O KeeChallenge regenera o arquivo XML (gera um novo desafio aleatório C, calcula a nova resposta R, criptografa S usando R' e armazena os valores atualizados de C e Senc no arquivo XML)
Para mais detalhes, confira o diagrama completo do fluxo de trabalho.
Problemas com o KeeChallenge
Há vários problemas de segurança na abordagem do KeeChallenge:
- A chave secreta nunca muda, ela apenas é recriptografada. Do ponto de vista do KeePass, o KeeChallenge não é diferente de um arquivo de chave estático que fornece os mesmos bytes toda vez.
- Como consequência disso, o KeeChallenge fica totalmente vulnerável a ataques de repetição (replay attack). Qualquer um dos arquivos XML anteriores pode ser usado para descriptografar o banco de dados. Ou seja, não há sentido em randomizar o desafio e recriptografar o segredo — é puro teatro de segurança.
- O segredo nunca deveria sair da YubiKey — esse é justamente o propósito de uma chave física somente de gravação. O KeeChallenge viola esse princípio ao trazer o segredo para o computador. Teoricamente, um invasor pode copiar o S da memória do processo, clonar a YubiKey do proprietário sem que ele saiba e descriptografar qualquer versão futura do banco de dados (já que o segredo é estático).
Além disso, há alguns problemas relacionados:
- Um desenvolvedor da Yubico levantou uma preocupação de segurança em 2016. Até 2024, o problema continua em aberto.
- O KeeChallenge parece abandonado; não houve atualizações significativas desde 2016.
- O mantenedor não responde aos problemas relatados.
Uma alternativa melhor
Uma abordagem alternativa foi introduzida no KeePassXC e é suportada por todos os apps compatíveis:
No KeePassXC, não exigimos nenhum conhecimento do segredo HMAC. Usamos a semente mestra do banco de dados (uma sequência aleatória de bytes que faz parte dele) como desafio e então usamos a resposta para criptografá-lo. Dessa forma, não precisamos de um arquivo extra e ainda ganhamos a vantagem de que a resposta necessária muda toda vez que o banco de dados é salvo, o que se assemelha mais a uma autenticação de dois fatores de verdade.
Essa abordagem tem várias vantagens importantes em relação ao KeeChallenge:
- A chave derivada da YubiKey é dinâmica: ela muda toda vez que o banco de dados é salvo. (No KeeChallenge, a chave de criptografia permanece a mesma, simulando na prática um arquivo de chave estático.)
- O segredo HMAC nunca sai da chave física, então a YubiKey não pode ser clonada às escondidas.
- Não há arquivo XML auxiliar, apenas o próprio banco de dados.
- Há várias equipes de desenvolvimento ativas que suportam essa abordagem.
Pelas razões descritas acima, o KeePassium implementa a abordagem do KeePassXC. Não há planos de suportar bancos de dados criptografados com o KeeChallenge.
Se você tem um banco de dados protegido pelo KeeChallenge — considere migrar para o KeePassXC e o KeePassium. Essa combinação oferece uma solução mais segura, compatível e com manutenção ativa.