Selecionar idioma

Rumo à Verificação Formal de Algoritmos de Geração de Senhas em Gestores de Senhas

Um artigo de pesquisa que propõe uma implementação de referência formalmente verificada para geradores de senhas aleatórias em gestores de senhas, utilizando o EasyCrypt para provas de correção funcional e segurança.
computationalcoin.com | PDF Size: 0.1 MB
Avaliação: 4.5/5
Sua avaliação
Você já avaliou este documento
Capa do documento PDF - Rumo à Verificação Formal de Algoritmos de Geração de Senhas em Gestores de Senhas

1. Introdução

Os gestores de senhas (GS) são ferramentas críticas recomendadas por especialistas em segurança para mitigar vulnerabilidades associadas à autenticação por senha, como senhas fracas e reutilização de senhas. Eles permitem o uso de senhas fortes e únicas, tratando do armazenamento e da geração. No entanto, a adoção pelos utilizadores é dificultada pela falta de confiança nestas aplicações. Este artigo identifica a funcionalidade de geração de senhas aleatórias (GSA) como um fator-chave que influencia tanto a confiança como a utilização. Para resolver isto, os autores propõem o desenvolvimento e a verificação formal de uma implementação de referência para um algoritmo de GSA, com o objetivo de fornecer uma base criptograficamente sólida e comprovadamente segura em que utilizadores e programadores possam confiar.

O problema central é que, embora os GS promovam a segurança, os seus mecanismos internos — especialmente a geração de senhas — são frequentemente caixas negras opacas. Sem garantias verificáveis, os utilizadores mantêm-se céticos. A via de solução envolve o uso de métodos formais, especificamente o enquadramento EasyCrypt, para especificar matematicamente o algoritmo e provar as suas propriedades de correção e segurança face a um modelo adversário bem definido.

2. Algoritmos Atuais de Geração de Senhas

O artigo analisa 15 gestores de senhas, focando-se em três exemplos de código aberto e amplamente utilizados: o gestor integrado do Google Chrome, o Bitwarden e o KeePass. A análise revela padrões comuns e diferenças críticas nas suas abordagens para gerar senhas aleatórias.

2.1 Políticas de Composição de Senhas

Todos os GS estudados permitem que os utilizadores definam políticas que restringem a estrutura das senhas geradas. Estas políticas incluem tipicamente:

  • Comprimento da Senha: Varia de 1-200 (Chrome) a um extremo de 1-30000 (KeePass).
  • Conjuntos de Caracteres: Os conjuntos padrão incluem letras minúsculas, maiúsculas, números e caracteres especiais. O KeePass oferece granularidade adicional com conjuntos separados para parênteses, espaço, hífen e sublinhado.
  • Mínimo/Máximo por Conjunto: O Chrome e o Bitwarden permitem definir ocorrências mínimas por conjunto de caracteres. O KeePass não o faz.
  • Exclusão de Caracteres Ambíguos: Todos os três permitem excluir caracteres visualmente semelhantes (ex.: 'l', '1', 'O', '0') para reduzir erros do utilizador.
  • Conjuntos Personalizados & Duplicados: O KeePass permite, de forma única, definir conjuntos de caracteres personalizados para incluir ou excluir, e pode remover caracteres duplicados da senha gerada.

A variação nas opções de política destaca a falta de padronização, o que complica a criação de um modelo universal e verificável.

2.2 Geração de Senhas Aleatórias

O algoritmo geral envolve a seleção aleatória de caracteres dos conjuntos permitidos, respeitando as restrições da política (comprimento, mínimos, máximos). O artigo descreve em detalhe o algoritmo do Chrome:

  1. Primeiro, gerar caracteres para cada conjunto que tenha um número mínimo de ocorrências definido.
  2. Depois, gerar os caracteres restantes selecionando aleatoriamente da união de todos os conjuntos que ainda não atingiram o seu número máximo de ocorrências permitido.
  3. Finalmente, aplicar uma permutação aleatória à cadeia de caracteres gerada.

Este processo, embora aparentemente simples, deve ser implementado com cuidado para garantir uma verdadeira aleatoriedade e uma distribuição imparcial em todo o espaço de senhas restringido pela política. Subtis enviesamentos na seleção ou permutação podem enfraquecer as senhas resultantes.

3. Implementação Formalmente Verificada Proposta

A contribuição central do artigo é a proposta de construir uma implementação de referência de GSA com provas verificadas por máquina das suas propriedades.

3.1 Especificação Formal

O primeiro passo é criar uma especificação matemática precisa do algoritmo de geração de senhas dentro do EasyCrypt. Esta especificação define:

  • Entradas: Parâmetros da política (comprimento $L$, conjuntos de caracteres $S_1, S_2, ..., S_n$, mínimos $min_i$, máximos $max_i$).
  • Saída: Uma cadeia de senha $p$ de comprimento $L$.
  • Pré-condições: A política deve ser consistente (ex.: $\sum min_i \leq L$).
  • Pós-condições (Correção Funcional): A saída $p$ deve satisfazer todas as restrições da política. Formalmente, $\forall i, min_i \leq count(p, S_i) \leq max_i$, onde $count$ conta os caracteres do conjunto $S_i$ em $p$.

3.2 Propriedades de Segurança e Provas

Para além da correção, a implementação deve ser comprovadamente segura. O artigo adota uma abordagem de prova criptográfica baseada em jogos. A propriedade de segurança chave é a amostragem aleatória uniforme do conjunto de todas as senhas que satisfazem a política dada.

Isto é formalizado como um jogo de segurança onde um adversário tenta distinguir entre uma senha gerada pelo algoritmo real e uma senha amostrada uniformemente do espaço de senhas válidas. A prova demonstra que nenhum adversário eficiente pode vencer este jogo com uma probabilidade significativamente melhor do que um palpite aleatório (1/2). Isto garante que o algoritmo não introduz padrões previsíveis ou enviesamentos.

A prova aproveitaria as bibliotecas do EasyCrypt para raciocinar sobre computações probabilísticas e amostragem aleatória.

4. Resultados Experimentais & Análise

Embora o PDF fornecido seja um trabalho preliminar e não contenha resultados experimentais completos, ele prepara o terreno para os mesmos. A verificação proposta produziria os seguintes resultados tangíveis:

  • Relatório de Verificação: Um certificado de prova gerado por máquina a partir do EasyCrypt, confirmando que o código do algoritmo adere à sua especificação formal e aos teoremas de segurança.
  • Análise Comparativa: O algoritmo verificado poderia ser comparado com as implementações existentes no Chrome, Bitwarden e KeePass. Os testes envolveriam gerar grandes lotes de senhas (ex.: 1 milhão) sob políticas idênticas e analisar estatisticamente a distribuição.
  • Métrica: Uma métrica chave seria a Divergência de Kullback-Leibler (KL) ou o teste do Qui-quadrado entre a distribuição empírica das senhas geradas e a distribuição uniforme teórica sobre o espaço definido pela política. Um algoritmo formalmente verificado deveria mostrar uma divergência estatisticamente indistinguível de zero, enquanto implementações não verificadas poderiam revelar enviesamentos subtis.
  • Descrição do Gráfico: Um gráfico de barras comparando a entropia (em bits) da distribuição de senhas geradas para o algoritmo de cada GS contra a entropia máxima teórica para a política dada. A barra da implementação de referência verificada deveria alinhar-se perfeitamente com a barra "Máximo Teórico".

5. Detalhes Técnicos & Enquadramento Matemático

A verificação formal baseia-se na modelação matemática precisa. Vamos definir os conceitos centrais:

Espaço de Senhas: Dada uma política com comprimento $L$ e conjuntos de caracteres permitidos $S_1, ..., S_n$, o conjunto total de senhas conformes $\mathcal{P}$ é um subconjunto do produto cartesiano $\mathcal{C}^L$, onde $\mathcal{C} = \bigcup_{i=1}^n S_i$. O tamanho de $\mathcal{P}$ é restringido pelas regras de mínimo e máximo.

Distribuição Uniforme: O objetivo de segurança é que o algoritmo $\mathcal{A}$ implemente uma função indistinguível de um verdadeiro amostrador uniforme $\mathcal{U}_{\mathcal{P}}$. Para qualquer senha $p \in \mathcal{P}$, a probabilidade deve ser: $$\Pr[\mathcal{A}(policy) = p] = \frac{1}{|\mathcal{P}|}$$ onde $|\mathcal{P}|$ é a cardinalidade do conjunto de senhas válidas.

Esboço da Prova Baseada em Jogos: A segurança é enquadrada como um jogo "Real-ou-Aleatório" (RoR).

  1. O desafiante lança uma moeda secreta $b \xleftarrow{\$} \{0,1\}$.
  2. O adversário $\mathcal{D}$ pode consultar o desafiante com políticas de senha.
  3. Se $b=0$ (Real), o desafiante executa o algoritmo real $\mathcal{A}$.
  4. Se $b=1$ (Aleatório), o desafiante amostra uniformemente de $\mathcal{P}$ usando $\mathcal{U}_{\mathcal{P}}$.
  5. $\mathcal{D}$ produz um palpite $b'$.
A vantagem do adversário é definida como: $$\mathbf{Adv}^{ror}_{\mathcal{A},\mathcal{D}}(\lambda) = \left| \Pr[b' = b] - \frac{1}{2} \right|$$ A prova demonstra que, para todos os adversários probabilísticos de tempo polinomial $\mathcal{D}$, esta vantagem é negligenciável no parâmetro de segurança $\lambda$ (relacionado com a fonte de aleatoriedade).

6. Enquadramento de Análise: Um Exemplo Sem Código

Como o PDF não inclui código real, aqui está um enquadramento de análise conceptual para avaliar um algoritmo de GSA, apresentado como uma lista de verificação:

Caso: Avaliar o gerador de senhas do "GS-X".

Passo 1 - Desconstrução da Política: Mapear as opções da interface do utilizador do GS-X (caixas de verificação, controlos deslizantes) para um tuplo de política formal: (L=12, Sets={Minúsculas, Maiúsculas, Dígitos}, min_Minúsculas=1, min_Maiúsculas=1, min_Dígitos=1, exclude={'l','O','0'}).

Passo 2 - Transparência Algorítmica: Os passos do algoritmo (como o processo de 3 passos do Chrome) podem ser claramente descritos a partir da documentação ou do código-fonte? Se não, falha no teste de transparência.

Passo 3 - Cálculo da Entropia: Calcular a entropia máxima teórica para a política: $log_2(|\mathcal{P}|)$ bits. Para a política acima, $|\mathcal{P}|$ é o número de cadeias de 12 caracteres de um alfabeto (ex.: 70 caracteres após exclusões) que satisfazem as restrições mínimas. Este é o benchmark de segurança.

Passo 4 - Desenho do Teste Estatístico: Desenhar uma experiência para gerar $N$ senhas e testar a distribuição uniforme. Usar o teste do Qui-quadrado em todo o espaço de senhas ou num subconjunto inteligentemente amostrado.

Passo 5 - Deteção de Enviesamento: Procurar enviesamentos específicos: Certas posições de caracteres são menos aleatórias? O algoritmo para cumprir os mínimos reduz a aleatoriedade para as posições restantes?

Este enquadramento fornece uma metodologia estruturada, sem código, para examinar criticamente qualquer GSA, alinhando-se com o objetivo do artigo de passar da obscuridade para uma análise verificável.

7. Aplicações Futuras & Direções de Investigação

O trabalho abre várias vias promissoras:

  • Padronização: Um GSA formalmente verificado poderia tornar-se um componente padrão (como uma biblioteca) integrado em GS em toda a indústria, semelhante à forma como o libsodium fornece primitivas criptográficas verificadas.
  • Integração no Navegador e SO: Sistemas operativos (ex.: Windows Hello, macOS Keychain) e navegadores poderiam adotar o gerador verificado para as suas funcionalidades integradas de sugestão de senhas, elevando o nível de segurança base para todos os utilizadores.
  • Geração Suportada por Hardware: O algoritmo verificado poderia ser implementado em elementos de hardware seguro (TPM, Secure Enclave) para uma geração que é tanto fisicamente como logicamente segura.
  • Considerações Pós-Quânticas: Investigação futura poderia explorar políticas de geração de senhas que produzam senhas resistentes a ataques de força bruta clássicos e quânticos, com provas formais adaptadas a novos modelos de ameaça.
  • Verificação do Compromisso Usabilidade-Segurança: Estender o modelo formal para provar propriedades sobre a memorabilidade ou facilidade de digitação das senhas geradas, colmatando o fosso entre criptografia pura e interação humano-computador.
  • Análise Automática de Políticas: Desenvolver ferramentas que usem o modelo formal para analisar automaticamente uma política definida pelo utilizador e reportar a sua entropia efetiva e quaisquer restrições não intencionais que enfraqueçam o espaço de senhas.

8. Referências

  1. Grilo, M., Ferreira, J. F., & Almeida, J. B. (2021). Towards Formal Verification of Password Generation Algorithms used in Password Managers. arXiv preprint arXiv:2106.03626.
  2. Bellare, M., & Rogaway, P. (2006). The security of triple encryption and a framework for code-based game-playing proofs. In Advances in Cryptology-EUROCRYPT 2006 (pp. 409-426). Springer.
  3. Barthe, G., Dupressoir, F., Grégoire, B., Kunz, C., Schmidt, B., & Strub, P. Y. (2016). EasyCrypt: A computer-aided cryptography toolset. Lecture Notes in Computer Science, 9573, 3-32.
  4. National Institute of Standards and Technology (NIST). (2020). Digital Identity Guidelines: Authentication and Lifecycle Management (SP 800-63B).
  5. Shannon, C. E. (1948). A mathematical theory of communication. The Bell System Technical Journal, 27(3), 379-423. (Trabalho fundamental sobre entropia e teoria da informação).
  6. Florêncio, D., Herley, C., & Van Oorschot, P. C. (2014). An administrator's guide to internet password research. In 28th Large Installation System Administration Conference (LISA14) (pp. 44-61).

9. Perspetiva do Analista: Ideia Central & Crítica

Ideia Central

Este artigo identifica corretamente uma vulnerabilidade crítica, mas frequentemente negligenciada, na cadeia de abastecimento de cibersegurança: a aleatoriedade não verificada no cerne dos gestores de senhas. A verdadeira ideia não é que a geração de senhas seja complexa — é que o modelo de confiança para uma ferramenta de segurança fundamental está quebrado. Pede-se aos utilizadores que confiem numa caixa negra com as suas chaves digitais. A proposta dos autores de aplicar verificação formal, uma técnica mais comum no desenho de hardware e software crítico de aviação (como sistemas certificados DO-178C), a uma primitiva de segurança de consumo é ambiciosa e necessária. É uma tentativa de transplantar o rigor do laboratório de investigação da SRI International ou da INRIA para o mundo frequentemente descuidado da segurança de aplicações.

Fluxo Lógico

O argumento flui logicamente de um problema bem estabelecido (desconfiança dos utilizadores nos GS) para uma causa raiz técnica e específica (geração de senhas opaca), e depois para uma via de solução concreta e de alta garantia (especificação formal e prova). O levantamento dos GS existentes não é apenas académico; demonstra efetivamente a enorme inconsistência nas implementações, fundamentando o caso para uma referência padrão e verificada. A mudança para o EasyCrypt e provas baseadas em jogos é apropriada, pois este enquadramento, desenvolvido por instituições líderes em criptografia formal, é precisamente desenhado para esta classe de problemas. O fluxo espelha a metodologia de trabalhos seminais em criptografia verificada, como a verificação do gerador HMAC-DRBG.

Pontos Fortes & Falhas

Pontos Fortes: O maior ponto forte do artigo é o seu foco num problema de alto impacto e tratável. Não tenta verificar um GS inteiro; vai ao cerne criptográfico. Usar GS de código aberto para análise fundamenta a investigação na realidade. A escolha de provas baseadas em jogos é o padrão da indústria para a análise criptográfica moderna.

Falhas Críticas & Lacunas: O artigo, tal como apresentado, é mais uma proposta convincente do que um estudo concluído. A omissão mais flagrante é o código EasyCrypt real e as provas concluídas. Sem estes, a afirmação permanece teórica. Além disso, subestima o problema da complexidade da política. A especificação formal deve lidar com todos os casos limite das políticas definidas pelo utilizador (ex.: mínimos/máximos conflituosos, conjuntos de caracteres personalizados). Isto poderia levar a uma especificação tão complexa quanto a implementação, um desafio conhecido nos métodos formais. Também contorna a fonte de entropia do mundo real — o algoritmo é tão bom quanto o CSPRNG do sistema (ex.: /dev/urandom). Um algoritmo verificado alimentado com aleatoriedade fraca continua fraco. O artigo seria mais forte ao limitar explicitamente as suas garantias com base numa suposição de fonte de entropia perfeita.

Ideias Acionáveis

1. Para Programadores de GS: Abrir imediatamente o código de geração de senhas e submetê-lo a auditoria de terceiros. Começar a modelar o seu algoritmo, mesmo informalmente, para identificar potenciais enviesamentos. Considerar integrar uma biblioteca verificada como a que esta investigação visa produzir.

2. Para Auditores de Segurança: Adicionar "Análise do Algoritmo de GSA" à sua lista de verificação padrão de auditoria de GS. Usar o enquadramento estatístico delineado na Secção 6 para testar enviesamentos distribucionais nas saídas do cliente.

3. Para Organismos de Normalização (ex.: NIST, FIDO Alliance): Iniciar um grupo de trabalho para definir uma API padrão e um conjunto de requisitos de segurança para geradores de senhas, preparando o caminho para implementações certificadas. Isto espelha a bem-sucedida padronização de algoritmos criptográficos.

4. Para Investigadores: Este trabalho é um ponto de partida perfeito. O próximo passo é completar a implementação e as provas no EasyCrypt. Uma fase subsequente e crucial é desenvolver um *harness* de testes que possa pegar no código verificado e testá-lo (*fuzzing*) contra o código do mundo real do Chrome, Bitwarden, etc., para encontrar discrepâncias e vulnerabilidades concretas, passando da teoria para o impacto prático.

Em conclusão, este artigo lança uma luz necessária sobre um canto escuro da nossa infraestrutura de segurança. Embora incompleto, a sua direção está correta. A indústria dos gestores de senhas amadureceu para além da fase "confie apenas em nós"; é tempo de confiança verificável e matemática. O sucesso desta investigação poderia estabelecer um novo precedente para a forma como construímos todo o software de segurança do lado do cliente.