Pega um smartcard, um resistor de baixo valor em série na linha de alimentação, e um osciloscópio. Manda o cartão processar uma assinatura com o PIN de sempre, várias vezes. Isso é literalmente o kit de um dos ataques mais antigos e mais efetivos contra criptografia embarcada — e ele nunca precisa quebrar matematicamente RSA ou AES. Ele só precisa que o chip consuma energia de forma diferente dependendo do que está processando. E consome, sempre.
Já toquei nesse assunto de forma mais ampla no artigo geral sobre side-channel attacks. Aqui eu quero entrar na mecânica real de SPA e DPA — porque são duas técnicas com níveis de sofisticação bem diferentes, e entender a diferença é o que separa “sei que existe power analysis” de “sei quando minha implementação está exposta a ela”.
SPA: o ataque que você resolve olhando o gráfico
Simple Power Analysis funciona por observação visual direta do traço de consumo de energia durante a execução. O exemplo clássico é a exponenciação modular usada em RSA com o método “square and multiply”: pra cada bit do expoente secreto, o algoritmo sempre faz uma operação de “square”, e só faz a operação de “multiply” quando aquele bit é 1.
Essas duas operações consomem energia de forma visivelmente diferente num traço de osciloscópio — square tem uma assinatura, multiply tem outra. Se o traço mostra uma sequência alternando picos maiores e menores, dá pra ler direto ali, olho no gráfico, quais bits do expoente são 1 e quais são 0. Nenhuma estatística sofisticada é necessária. É basicamente leitura visual de padrão.
Isso é o motivo pelo qual toda implementação séria de RSA hoje usa “square-and-multiply-always” (sempre faz a multiplicação e descarta o resultado quando o bit é 0) — não porque isso deixe o algoritmo “mais seguro” no sentido matemático, mas porque elimina a diferença visual que SPA explora.
DPA: quando o sinal individual não basta, mas a estatística resolve
Differential Power Analysis é bem mais poderoso, e resolve exatamente o problema que apareceria se você tentasse aplicar SPA contra uma implementação que já esconde os padrões óbvios num único traço. DPA não depende de um traço “limpo” — ele extrai sinal de centenas ou milhares de traços ruidosos, usando estatística.
O processo, passo a passo:
- Coleta de dados. O atacante roda o algoritmo criptográfico repetidamente, capturando o traço de consumo de energia pra entradas diferentes (plaintexts variados, por exemplo).
- Construção de modelo. Com o algoritmo conhecido (por exemplo, um S-box com operação XOR), o atacante calcula, para cada hipótese de valor de chave, qual seria o valor intermediário processado.
- Particionamento dos traços. Os traços são divididos em dois grupos de acordo com um bit específico desse valor intermediário hipotético — um grupo onde o bit seria 0, outro onde seria 1.
- Análise estatística. Calcula-se a média dos traços de cada grupo, e a diferença entre essas médias. Se a hipótese de chave estiver correta, essa diferença mostra um pico visível num ponto específico do traço temporal — a “assinatura DPA”. Se a hipótese estiver errada, a diferença tende a zero (ruído).
A vantagem central do DPA é que ele não exige alta precisão em nenhuma medição individual. Com traços suficientes, até discrepâncias minúsculas se amplificam estatisticamente. Isso faz de DPA uma técnica capaz de superar várias contramedidas físicas isoladas — desde que o atacante tenha acesso físico ao dispositivo por tempo suficiente pra coletar traços.
Exemplo concreto: quebrando uma chave AES de 128 bits
Pra deixar isso menos abstrato: numa chave AES de 128 bits, dividida em 16 bytes, cada byte tem 256 valores possíveis. Isso dá 4.096 combinações (256 × 16) de hipóteses a testar — não 2^128. O atacante calcula o valor DPA pra cada uma dessas 4.096 hipóteses, e a hipótese que produzir o pico mais alto na diferença de traços é o candidato mais provável pra aquele byte da chave.
Repare no que isso significa na prática: recuperar uma chave de 128 bits, que seria inviável por força bruta, vira um problema de rodar 4.096 hipóteses e comparar picos estatísticos — porque o AES processa a chave byte a byte, e cada byte pode ser atacado independentemente. É essa decomposição que torna DPA prático mesmo contra chaves “grandes” no sentido criptográfico.
O que funciona contra isso (e o que não é bala de prata)
- Operações a tempo e energia constantes, garantindo que a execução consuma a mesma quantidade de energia e leve o mesmo tempo, independente do dado processado. Reduz a correlação entre padrão de consumo e valor secreto, mas raramente elimina 100% na prática de silício real.
- Masking (mascaramento) e randomização, introduzindo ruído ou dados aleatórios durante a execução do algoritmo, dificultando a correlação entre os traços coletados e o valor processado. É a defesa mais usada contra DPA porque ataca diretamente a premissa estatística do ataque — mas exige reprojetar a implementação, não é um patch cosmético.
- Blinding, aplicando transformações matemáticas que embaralham o dado antes do processamento (por exemplo, RSA blinding, onde a mensagem é multiplicada por um fator aleatório antes da exponenciação e o resultado é corrigido depois). Reduz a possibilidade de inferência a partir do consumo, sem alterar o resultado da operação.
Nenhuma dessas é definitiva sozinha. Masking bem implementado ainda pode vazar em “ordem superior” (combinando múltiplos pontos do traço), e blinding não protege contra SPA se a implementação subjacente ainda tiver branches óbvios. Produtos que levam isso a sério combinam várias camadas e testam com equipamento real — osciloscópio, milhares de traços, análise estatística — antes de assinar que a implementação está pronta.
Se você já leu meu artigo sobre cache attacks, repare que o princípio é o mesmo em espírito: a cifra está matematicamente correta, mas a implementação física vaza informação sobre o que está processando. A diferença é o canal — aqui é energia, lá é tempo de acesso à cache. E ainda tem um terceiro canal que cubro em outro artigo: a infraestrutura de teste do próprio chip, explorada via scan chain.
