Capítulo 31 — Segurança quântica e pós-quântica: implementação II

Capítulo 31 — Segurança quântica e pós-quântica: implementação II

Mapa da aula

Aula 31 publicada. Mapa, exemplo, EX061.

flowchart TD
  N0["31.1 Tempo constante"]
  N1["31.2 Comparação no desencapsulamento"]
  N2["31.3 Ataques por injeção de falhas"]
  N3["31.4 Aleatoriedade e sementes"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX061"]

Desenho lógico

flowchart LR
  N0["31.1 Tempo constante"]
  N1["31.2 Comparação no desencapsulamento"]
  N2["31.3 Ataques por injeção de falhas"]
  N3["31.4 Aleatoriedade e sementes"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX061"]

[31.1 Tempo constante]
    |
    v
[31.2 Comparação no desencapsulamento]
    |
    v
[31.3 Ataques por injeção de falhas]
    |
    v
[31.4 Aleatoriedade e sementes]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX061]

Objetivos de aprendizagem

Você vai (1) aplicar técnicas de tempo constante ao código baseado em reticulados; (2) entender os ataques por injeção de falhas e as suas contramedidas; (3) lidar com segurança com a aleatoriedade e as sementes; e (4) avaliar implementações embarcadas. O capítulo aprofunda o Capítulo 28 com a segurança da implementação.

31.1 Tempo constante

As implementações baseadas em reticulados precisam evitar desvios, acessos à memória e instruções de tempo variável que dependam de segredos. A divisão é uma armadilha conhecida: compiladores e processadores podem implementar a divisão por uma constante com tempo variável, e o KyberSlash mostrou vazamentos reais a partir de divisões dependentes de segredos (Bernstein et al. 2024). A correção é uma aritmética que evite a divisão (multiplicação por constantes pré-calculadas e deslocamentos) e a verificação com ferramentas de análise de tempo.

Um código-fonte que parece de tempo constante pode deixar de sê-lo após a compilação, por isso as verificações são executadas sobre o binário de cada plataforma-alvo.

31.2 Comparação no desencapsulamento

A rejeição implícita do ML-KEM compara um texto cifrado recifrado com o recebido. A comparação e a seleção entre a chave real e a chave de rejeição precisam ser de tempo constante; caso contrário, o tempo revela se um texto cifrado manipulado foi decifrado "corretamente", reabrindo os ataques de texto cifrado escolhido.

Uma comparação ingênua que para no primeiro byte diferente termina mais cedo para algumas entradas do que para outras, e um atacante que envia muitos textos cifrados forjados consegue medir a diferença. A correção compara todos os bytes e combina as diferenças com operações bit a bit, e depois seleciona a chave com uma máscara em vez de um desvio. As bibliotecas implementam isso; a revisão da BPA verifica que o código da aplicação nunca reimplemente a comparação nem acrescente uma saída antecipada em torno dela.

31.3 Ataques por injeção de falhas

Injetar falhas (picos de tensão, falhas de clock, lasers) pode pular verificações ou corromper cálculos. Nas assinaturas, uma falha durante a assinatura ML-DSA pode vazar informações sobre a chave secreta; nos esquemas determinísticos, as falhas podem ser especialmente perigosas. As contramedidas incluem o cálculo redundante, a verificação de uma assinatura antes de liberá-la e hardware reforçado. Elas importam para dispositivos aos quais um atacante tem acesso físico — scanners de portão, cartões inteligentes.

Verificar uma assinatura antes de liberá-la custa uma verificação a mais, o que no ML-DSA é rápido, e detecta falhas que corromperam a assinatura. Para o serviço central de assinatura da BPA, numa sala protegida, o risco de falhas é baixo; para dispositivos em campo, um atacante com acesso físico tem tempo para experimentar, então é ali que as contramedidas importam mais.

31.4 Aleatoriedade e sementes

A geração de chaves e o encapsulamento do ML-KEM consomem aleatoriedade nova; o ML-DSA oferece um modo "hedged" que mistura aleatoriedade nova com derivação determinística, o que ajuda contra falhas injetadas e falhas de aleatoriedade (FIPS 204). As sementes que geram chaves são tão sensíveis quanto as próprias chaves.

Num esquema hedged, um gerador de números aleatórios com defeito degrada para a assinatura determinística em vez de vazar a chave, e é por isso que a BPA ativa o ML-DSA hedged no seu serviço de assinatura. As sementes de 64 bytes do ML-KEM precisam ser protegidas como chaves privadas: quem obtém uma semente pode regenerar a chave de desencapsulamento. As regras de armazenamento e de backup se aplicam às sementes da mesma forma, inclusive a destruição quando a chave é aposentada.

31.5 Exemplo resolvido

O fornecedor dos scanners de portão da BPA fornece um verificador ML-DSA para o firmware. Como o dispositivo apenas verifica, o vazamento da chave secreta não está em jogo no dispositivo; os principais riscos são falhas que pulem o resultado da verificação. Contramedida: verificar duas vezes, por caminhos de código diferentes, e conferir um hash da imagem após o boot.

Usar dois caminhos de código diferentes significa que é improvável que uma única falha injetada pule as duas verificações da mesma forma. A conferência do hash após o boot acrescenta mais uma camada: se uma falha deixou uma imagem não assinada iniciar, a divergência é detectada e o dispositivo a relata. Essas etapas custam milissegundos no boot, o que o scanner pode pagar.

31.6 Erros comuns e limites

• Supor que os compiladores preservam a intenção de tempo constante.
• Ignorar ataques físicos contra dispositivos em campo.
• Tratar as sementes como não sensíveis.

Os compiladores otimizam para velocidade e podem introduzir desvios ou consultas a tabelas que vazam tempo, então as alegações de tempo constante precisam ser verificadas no código compilado. Dispositivos em campo, como os scanners de portão, enfrentam atacantes que podem injetar falhas neles à vontade, ao contrário dos servidores numa sala vigiada. As sementes regeneram chaves, então tratá-las como configuração inofensiva expõe todas as chaves derivadas delas. As revisões da BPA verificam esses três pontos em cada nova classe de dispositivo antes da compra.

Exercícios

• EX061 — Auditoria de divisão. Explique por que coeff // 1665 sobre um valor secreto pode vazar informação e proponha uma alternativa. Rubrica: 3 = risco da divisão de tempo variável e alternativa com multiplicação/deslocamento.
• EX062 — Ameaça de falhas. Para um bootloader que apenas verifica, identifique a ameaça de falhas e duas contramedidas. Rubrica: 3 = verificação pulada; verificação redundante e hash após o boot.

Síntese

A segurança da implementação em PQC significa aritmética e comparações de tempo constante, resistência a falhas onde os atacantes têm acesso físico e cuidado no tratamento da aleatoriedade e das sementes.

Continue estudando — capítulo 31 de 50

← Capítulo 30 · Índice de capítulos do curso · Capítulo 32 →

Siga para a próxima lição escrita.