Capítulo 8 — Arquitetura de computadores
Mapa da aula
Aula 08 publicada. Mapa, exemplo, EX015.
flowchart TD
N0["8.1 Recursos de desempenho"]
N1["8.2 Canais laterais"]
N2["8.3 Memória e tamanho de código"]
N3["8.4 HSMs e elementos seguros"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX015"]
Desenho lógico
flowchart LR
N0["8.1 Recursos de desempenho"]
N1["8.2 Canais laterais"]
N2["8.3 Memória e tamanho de código"]
N3["8.4 HSMs e elementos seguros"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX015"]
[8.1 Recursos de desempenho]
|
v
[8.2 Canais laterais]
|
v
[8.3 Memória e tamanho de código]
|
v
[8.4 HSMs e elementos seguros]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX015]
Objetivos de aprendizagem
Você vai (1) relacionar o desempenho dos algoritmos a recursos do processador, como unidades vetoriais e caches; (2) explicar os canais laterais de tempo e de consumo de energia; (3) avaliar memória e tamanho de código em dispositivos restritos; e (4) entender os módulos de segurança de hardware (HSMs) e as suas restrições de migração. O capítulo prepara a implementação (Capítulos 28 e 31) e o desempenho (Capítulo 36).
8.1 Recursos de desempenho
Os esquemas de reticulados passam a maior parte do tempo na multiplicação de polinômios pela transformada de teoria dos números e no cálculo de hashes com SHAKE. As instruções vetoriais (AVX2 em x86, NEON em ARM) paralelizam as operações sobre coeficientes, tornando o ML-KEM muito rápido em servidores. Microcontroladores restritos sem unidades vetoriais são mais lentos, mas muitas vezes ainda aceitáveis; ali, o limite costuma ser a memória, não a velocidade.
Para a BPA, isso significa que os servidores TLS gastarão mais tempo enviando bytes do que calculando; resultados de benchmark que mostram a geração de chaves do ML-KEM mais rápida que a do X25519 num servidor não se transferem para um controlador de guindaste.
8.2 Canais laterais
O tempo de execução, os padrões de acesso à cache e o consumo de energia podem revelar segredos se dependerem de valores secretos. As descobertas do "KyberSlash" mostraram que uma divisão por uma constante cujo dividendo dependia de dados secretos vazava tempo em várias implementações do Kyber (Bernstein et al. 2024). Código em tempo constante — sem desvios, índices de memória ou instruções de tempo variável que dependam de segredos — é um requisito, não uma otimização.
A correção, nesse caso, foi substituir a divisão por uma multiplicação e um deslocamento que levam o mesmo tempo para qualquer entrada. As revisões procuram o mesmo padrão em outros lugares: qualquer desvio, consulta a tabela ou divisão cuja entrada dependa de uma chave ou de um valor decifrado. Ferramentas que executam o código com entradas marcadas como secretas e apontam essas dependências ajudam, mas precisam rodar sobre o binário compilado, porque os compiladores podem reintroduzir desvios que o código-fonte não tinha.
8.3 Memória e tamanho de código
A assinatura com ML-DSA precisa de vários kilobytes de memória de trabalho; as assinaturas SLH-DSA são grandes, mas as chaves são minúsculas; os esquemas baseados em hash com estado precisam de um estado não volátil que nunca pode retroceder. Num scanner de portão com 64 KB de RAM, a escolha do algoritmo de verificação de assinaturas é uma decisão de arquitetura.
Um verificador ML-DSA-44 precisa da chave pública de 1.312 bytes, da assinatura de 2.420 bytes e de uma área de trabalho para a expansão da matriz, que algumas implementações mantêm pequena gerando as linhas sob demanda. Um verificador que cabe porque recalcula dados troca velocidade por memória, o que um scanner que verifica uma atualização por mês pode facilmente pagar. A revisão de arquitetura registra qual compromisso foi escolhido e por quê.
8.4 HSMs e elementos seguros
As chaves privadas da autoridade certificadora da BPA ficam num HSM. A migração precisa de um firmware de HSM que suporte o ML-DSA e, possivelmente, o LMS/XMSS com proteção de estado, validado no programa de certificação pertinente. Os ciclos de atualização de HSMs costumam durar anos — uma restrição clássica dos cronogramas de migração.
O plano da BPA faz, portanto, três perguntas ao fornecedor do HSM desde já: quais algoritmos pós-quânticos o firmware atual suporta, quando haverá firmware certificado e se o hardware existente pode ser atualizado ou precisa ser substituído. As respostas fixam a data mais cedo possível para emitir certificados ML-DSA, o que, por sua vez, restringe cada etapa posterior da migração da autenticação.
8.5 Exemplo resolvido
Os controladores de guindaste da BPA verificam assinaturas de firmware num bootloader com 32 KB de flash disponíveis. O código de verificação do ML-DSA-44 e uma chave pública de 1.312 bytes podem caber; um verificador LMS é menor e precisa apenas de hashing, e, como só a verificação acontece no dispositivo, o problema de estado do LMS fica no servidor de assinatura. A revisão de arquitetura registra as duas opções e os seus orçamentos de memória.
A decisão também depende da frequência com que o firmware é assinado. As chaves LMS só podem assinar um número fixo de mensagens, por exemplo 2^10 ou 2^15, e perder o estado do assinante pode causar reutilização de chave. Com algumas versões por ano, uma chave de 2^15 assinaturas dura indefinidamente, então o risco está no procedimento de backup do servidor de assinatura, não na capacidade.
8.6 Erros comuns e limites
- Fazer benchmarks só em servidores.
- Supor que uma implementação correta roda em tempo constante.
- Esquecer os prazos de compra de HSMs.
Os benchmarks em servidores escondem os limites de memória que decidem o que cabe num scanner de portão ou num controlador de guindaste, então cada classe de dispositivo precisa da sua própria medição. Uma implementação correta ainda pode vazar tempo, como mostrou o caso KyberSlash, e é por isso que o comportamento em tempo constante é testado separadamente das respostas conhecidas. As atualizações de HSM podem levar anos, então o pedido sai antes de o trabalho de software começar, como a BPA fez com a sua autoridade certificadora.
Exercícios
- EX015 — Revisão de canal lateral. Identifique o risco de tempo em
if secret_coeff > q//2: x = slow_path()e proponha uma correção. Rubrica: 3 = identifica o desvio e dá uma alternativa sem desvio. - EX016 — Adequação ao dispositivo. Compare a verificação ML-DSA-44 e LMS para um bootloader de 32 KB. Rubrica: 3 = memória, localização do estado e normas (FIPS 204, SP 800-208) considerados.
Síntese
A arquitetura determina velocidade, adequação à memória e vazamento: os esquemas de reticulados são rápidos com unidades vetoriais, o código em tempo constante é obrigatório, os dispositivos restritos moldam a escolha do algoritmo e os ciclos dos HSMs moldam os cronogramas.
Continue estudando — capítulo 08 de 50
← Capítulo 07 · Índice de capítulos do curso · Capítulo 09 →
Siga para a próxima lição escrita.