Imagine que seu algoritmo de criptografia está matematicamente correto, sem falha nenhuma de implementação lógica, revisado, testado, publicado em paper acadêmico há vinte anos sem quebra conhecida. E mesmo assim alguém extrai a chave privada só medindo quanto tempo o chip leva pra processar cada operação, ou o consumo de energia dele durante a decriptação. Ninguém “hackeou” o algoritmo. Ninguém encontrou bug no código. O ataque explorou o hardware que executa o algoritmo, não o algoritmo em si.
Isso é side-channel attack, e é um dos motivos pelos quais “o algoritmo é seguro” e “a implementação é segura” são frases completamente diferentes.
O princípio: toda operação física deixa rastro
Um circuito não processa informação no vácuo. Ele consome energia de forma variável dependendo da operação que está fazendo, leva tempos diferentes pra caminhos de execução diferentes, emite radiação eletromagnética, e até produz variação de estado em cache de memória compartilhada. Nenhuma dessas coisas é parte do “algoritmo” — mas todas vazam informação sobre o que o algoritmo está processando.
Timing attack: o clássico contra RSA
Uma implementação ingênua de exponenciação modular (usada em RSA) usa o método “square and multiply”: pra cada bit do expoente secreto, o algoritmo sempre faz uma operação de elevar ao quadrado, e faz uma multiplicação extra somente se aquele bit for 1. Isso parece uma otimização razoável — por que multiplicar quando o bit é zero?
O problema: se o bit é 1, a operação leva mais tempo (por causa da multiplicação extra). Se é 0, leva menos tempo. Um atacante que consegue medir o tempo de execução com precisão suficiente, e que consegue repetir a operação várias vezes com entradas controladas, pode reconstruir o expoente secreto bit a bit, correlacionando os tempos observados com as hipóteses de cada bit. Não precisa nem ter acesso físico direto ao chip em muitos casos — em servidores remotos, variações de tempo de resposta de rede já foram usadas pra ataques desse tipo, embora com muito mais ruído pra filtrar.
A correção não é “torne mais rápido” — é fazer o algoritmo levar sempre o mesmo tempo, independente do valor do bit (implementações constant-time, multiplicação sempre executada e descartada quando o bit é 0, technique conhecida como “square-and-multiply-always”).
Power analysis: SPA e DPA
Se em vez de medir tempo você mede consumo de corrente do chip durante a operação, chega em power analysis. Há duas variantes:
- SPA (Simple Power Analysis): observação direta do traço de consumo de energia, geralmente suficiente pra distinguir visualmente padrões de operação diferentes (por exemplo, distinguir quadrado de multiplicação num traço de osciloscópio, porque consomem energia de forma visivelmente diferente).
- DPA (Differential Power Analysis): técnica estatística mais poderosa — captura muitos traços de consumo de energia com entradas diferentes e usa análise estatística (correlação) pra extrair a chave mesmo quando o sinal individual está soterrado em ruído. É bem mais difícil de se defender contra DPA do que contra SPA, porque não depende de um único traço “limpo”.
Cenário concreto: um smartcard ou token de autenticação processando uma operação de assinatura. Um atacante com o dispositivo em mãos (ou acesso físico temporário) conecta um resistor em série na linha de alimentação e mede a queda de tensão com osciloscópio enquanto o cartão processa múltiplas operações com o mesmo PIN. Com traços suficientes e análise estatística, é possível recuperar a chave privada sem nunca ter “quebrado” a criptografia matematicamente.
Scan chain attacks: explorando a infraestrutura de teste
Esse é menos conhecido fora do mundo de design de circuitos, mas é sério. Scan chains são cadeias de flip-flops inseridas no chip especificamente pra facilitar teste de fabricação (design for testability) — permitem forçar e ler o estado interno do circuito sem precisar de milhares de pinos de acesso.
O problema: se essa infraestrutura de teste continua acessível depois que o chip sai da fábrica, ela vira uma porta dos fundos gigantesca. Um atacante que consiga colocar o chip em modo de teste (via sinal TC, por exemplo) pode literalmente ler o estado interno do circuito através da porta de scan-out — incluindo registradores que guardam chave criptográfica no meio de uma operação. Ou pior, pode injetar valores via scan-in pra forçar estados específicos e induzir falhas exploráveis (fault injection).
Cache attacks: quando o compartilhamento de recursos vaza informação
Em sistemas com cache compartilhado (comum em qualquer CPU moderna rodando múltiplos processos), o padrão de acesso à memória durante uma operação criptográfica pode ser inferido por outro processo rodando na mesma máquina, medindo tempos de acesso a linhas de cache (se uma linha está em cache, o acesso é rápido; se não está, é lento — e essa diferença de tempo revela que endereços de memória foram tocados). Implementações de cifra que usam tabelas de lookup indexadas por bits da chave (comum em implementações de AES não otimizadas contra isso) são vulneráveis a esse tipo de vazamento.
Contramedidas que realmente funcionam
Nenhuma dessas é bala de prata isolada — na prática, produtos sérios combinam várias camadas:
- Masking: embaralhar os dados intermediários da operação com valores aleatórios, de forma que o consumo de energia ou o padrão de acesso deixe de se correlacionar diretamente com o valor secreto.
- Constant-time implementation: garantir que o tempo de execução não dependa do valor dos dados secretos, eliminando a variável que o timing attack explora.
- Injeção de ruído: adicionar variação intencional (elétrica, eletromagnética) pra reduzir a relação sinal-ruído que o atacante precisa pra extrair informação útil.
- Isolamento físico e desabilitação de scan chains em produção: garantir que a infraestrutura de teste de fábrica não fique acessível no produto final — algo tão simples quanto queimar um fusível que desabilita o modo de teste depois da fabricação já elimina boa parte do risco de scan chain attack.
O que fica de lição
Se você trabalha com criptografia em hardware — smartcards, tokens, secure elements, ou até um microcontrolador comum processando uma chave sensível — a pergunta certa não é “meu algoritmo é seguro?”. É “minha implementação vaza alguma coisa mensurável fisicamente sobre o que estou processando?”. Isso muda completamente a lista de coisas que você testa antes de assinar um projeto como pronto pra produção.
Esse tema conecta direto com hardware trojans e com FPGA security, que eu cubro em outros artigos aqui no blog — se seu produto usa FPGA ou tem componentes de terceiros na cadeia de fabricação, vale ler os dois em sequência.
