Já expliquei em outro artigo o mecanismo básico de timing attack contra RSA (o “square and multiply” vazando tempo por bit) e o conceito de scan chain attack. Aqui eu quero ir num ângulo que aquele artigo não cobre: por que timing attack continua funcionando mesmo quando o atacante não tem acesso físico nenhum — só uma conexão de rede — e por que scan chain não é só “uma porta de teste esquecida aberta”, é uma tensão de design que toda equipe de hardware enfrenta entre testabilidade e segurança.
Timing attack não precisa de laboratório — precisa de estatística e paciência
Kocher publicou o ataque original em 1996 contra implementações de Diffie-Hellman, RSA e DSS, mostrando que a correlação entre tempo de execução e valor do expoente secreto podia ser explorada com medições cuidadosas. O ponto que costuma passar despercebido é que esse ataque não depende de acesso físico ao dispositivo: se você consegue mandar requisições repetidas pra um servidor que processa a mesma operação criptográfica com a mesma chave, e consegue medir o tempo de resposta com granularidade suficiente, o ataque é aplicável remotamente.
Brumley e Boneh demonstraram isso de forma concreta contra implementações de SSL/TLS: um atacante na mesma rede local (ou até através da internet, com mais medições pra compensar o ruído) conseguiu extrair a chave privada RSA de um servidor só cronometrando o tempo de resposta de handshakes TLS repetidos. O ruído de rede (variação de latência, jitter, carga do servidor) reduz a precisão de cada medição individual — mas não elimina o sinal, só exige mais amostras e mais filtragem estatística pra separar sinal de ruído. Isso é uma diferença importante em relação a como o timing attack costuma ser ensinado: não é “preciso de um osciloscópio ligado no chip”, é “preciso de paciência estatística e de uma operação que eu consiga repetir com a mesma chave”.
Isso muda a lista de sistemas que você precisa considerar vulneráveis. Não é só smartcard em bancada de laboratório — é qualquer serviço de rede que processa operação criptográfica com tempo variável e permite repetição controlada pelo atacante.
Blinding: a defesa específica pra esse cenário
A defesa canônica contra timing attack em RSA não é só “faça constant-time” (que já é a base) — é RSA blinding: antes de processar a operação com a chave privada, o servidor multiplica a entrada por um fator aleatório, processa esse valor cegado, e desfaz a transformação no resultado final. Como o fator aleatório muda a cada operação, o atacante não consegue correlacionar o tempo medido com o valor real processado, mesmo que a implementação subjacente ainda tenha alguma variação de tempo residual. É uma defesa elegante porque ataca a premissa do attacker (repetir a mesma operação com a mesma entrada controlada) sem exigir reescrever toda a aritmética modular como constant-time perfeito.
Scan chain: a ferramenta de teste que ninguém pensa em “desligar”
Scan chain é uma técnica de design-for-testability: uma cadeia de flip-flops conectados em série, especificamente pra permitir que o fabricante force e leia o estado interno do circuito durante teste de produção, sem precisar de milhares de pinos de acesso físico a cada registrador. Sem scan chain, testar cobertura de falhas num chip complexo seria inviável economicamente — é uma ferramenta legítima e necessária de manufatura.
O problema é o que acontece depois que o chip sai da fábrica. Se a infraestrutura de scan continua acessível no produto final, ela vira um caminho de acesso ao estado interno do circuito que não passa por nenhuma das proteções lógicas normais do chip — porque scan chain foi projetado pra ignorar exatamente essas proteções, esse é o ponto dele.
Dois modos de exploração distintos:
- Captura de estado interno. O atacante força o chip a entrar em modo de teste (via o sinal de controle TC, tipicamente), e lê o estado interno através da porta de scan-out — incluindo registradores que guardam uma chave criptográfica no meio de uma operação. Isso não exige decapsular o chip nem microprobing; muitas vezes basta acesso aos pinos de teste padrão (JTAG é a interface mais comum usada pra isso na prática, embora scan chain e JTAG sejam camadas distintas — JTAG é o protocolo de acesso, scan chain é a infraestrutura interna que ele frequentemente expõe).
- Injeção de falhas via scan-in. Além de ler, o atacante pode escrever valores arbitrários nos flip-flops via a porta de scan-in, forçando estados específicos do circuito. Isso permite tanto extrair informação (forçando o circuito pra um estado que revela mais do que deveria) quanto induzir erros controlados que abrem caminho pra outros ataques, como fault injection combinado com análise de diferença de resultado.
Como scan chain seguro realmente se parece na prática
A solução ingênua — “desabilita o modo de teste depois da fábrica” — já ajuda bastante e é mais barata do que parece: um fusível queimado após teste de produção que desabilita permanentemente o acesso à porta de scan já elimina boa parte do risco pra produtos de consumo. Mas isso também elimina a possibilidade de diagnóstico de campo, o que nem sempre é aceitável.
Para produtos que precisam manter alguma capacidade de teste/debug pós-fabricação (automotivo, telecom, alguns cenários industriais), o design mais maduro usa:
- Scan chain locking/encryption: os dados que trafegam pela cadeia de scan são cifrados ou exigem uma chave de desbloqueio pra ativar o modo de teste, de forma que só quem tem a chave de fábrica (ou um processo de autenticação) consiga usar a infraestrutura de teste.
- Scan segregation: registradores que guardam segredo criptográfico são explicitamente excluídos da cadeia de scan, ou isolados numa cadeia separada com controle de acesso próprio, em vez de compartilhar a mesma cadeia usada pra depurar o resto do chip.
- IEEE 1500 / arquiteturas de scan seguro: padrões de wrapper de teste que permitem granularidade de acesso — testar um bloco sem expor o estado de outro.
O ponto central pra quem projeta hardware: testabilidade e segurança não são inimigas por natureza, mas são objetivos em tensão que exigem decisão explícita de design. Se ninguém decidiu conscientemente o que acontece com o scan chain depois que o chip sai da fábrica, a resposta padrão tende a ser “continua tudo acessível” — que é exatamente o cenário que um atacante quer encontrar.
Esse tema fecha bem com os outros dois artigos que escrevi sobre canais específicos de vazamento — cache attacks e power analysis. Juntos, os três mostram que “implementação segura” é uma lista bem mais longa do que só “usei uma cifra forte”.
