“Esse componente é certificado, é seguro” é a frase que mais deveria te deixar desconfiado, não tranquilo — porque “seguro” sem especificar contra quê, por quanto tempo, e com que orçamento de ataque, não significa nada mensurável. Já cobri em outros dois artigos a taxonomia dos ataques físicos e as contramedidas de design que resistem a eles. Este aqui é sobre o problema anterior a esses dois: como você mede, de forma que dê pra comparar fornecedores e decidir com base em critério, o nível de segurança física de um sistema.
Tamper resistance é uma equação de tempo, custo e expertise — não um selo
Tamper resistance mede o quão difícil é pra um atacante violar um sistema, considerando três fatores concretos:
- Tempo: quanto tempo é necessário pra executar o ataque com sucesso.
- Custo: quantos recursos financeiros o atacante precisa investir (equipamento, mão de obra especializada).
- Expertise: qual nível de especialização e acesso a equipamento específico é exigido.
Em outras palavras: quanto mais tempo, dinheiro e conhecimento especializado forem necessários pra comprometer um sistema, maior a resistência dele a ataque físico. Isso importa porque muda a pergunta de “é seguro?” (resposta binária inútil) pra “seguro contra um atacante com que orçamento e que nível de acesso a equipamento?” — que é uma pergunta que você consegue de fato responder e usar pra decisão de projeto.
Os níveis, na prática
Dá pra classificar dispositivos numa escala prática, do mais fraco ao mais robusto:
Nível zero — sem proteção. Nenhum mecanismo de segurança implementado, todos os componentes acessíveis e expostos. Um atacante compromete o dispositivo em minutos ou poucas horas, sem equipamento sofisticado. Exemplo típico: microcontroladores e chips FPGA com memória externa, sem nenhuma proteção adicional.
Nível baixo — proteção básica. Implementa alguma feature de segurança básica, mas de forma rudimentar — geralmente microcontroladores com memória interna e algoritmo de programação proprietário (mas não robusto). Um atacante precisa de ferramentas simples e algum conhecimento técnico, e o tempo de quebra vai de horas a dias. Vale um dado histórico interessante aqui: no início dos anos 1990, o equipamento necessário custava algo em torno de US$ 1.000; hoje esse custo caiu significativamente, pra faixa de US$ 500 ou menos. Isso ilustra bem por que classificação de segurança física é dinâmica, não estática — o que era “nível baixo, mas ainda assim uma barreira relevante” há trinta anos hoje é irrelevante como barreira.
Nível moderadamente baixo — proteção contra ataques de baixo custo. O sistema incorpora medidas específicas pra neutralizar métodos de ataque baratos. Exige equipamento um pouco mais avançado, e o tempo de comprometimento pode se estender a vários meses.
Níveis avançados — proteção para aplicações críticas. Dispositivos como chips militares, sistemas bancários e ASICs ou FPGAs complexos precisam resistir a todos os tipos de ataque conhecidos. Nesse nível, é praticamente inviável pra um atacante individual comprometer o sistema sem desenvolver métodos ou ferramentas novas.
O ponto importante, que vale repetir porque é fácil esquecer numa reunião de especificação de produto: essa classificação é relativa e dinâmica. Conforme equipamento fica mais barato e acessível ao longo do tempo, sistemas antes considerados seguros podem se tornar vulneráveis sem que uma única linha de código ou design tenha mudado — só o custo de ataque caiu.
FIPS 140: quando “certificado” tem um número por trás
Além da classificação prática acima, módulos criptográficos seguem padrões formais publicados pelo Departamento de Comércio dos EUA, com níveis bem definidos:
- Nível 1: define os requisitos básicos de segurança.
- Nível 2: adiciona mecanismos físicos como revestimentos, selos ou travas.
- Nível 3: exige proteção física avançada pra impedir acesso a parâmetros críticos.
- Nível 4: o padrão mais alto, projetado pra resistir a qualquer tipo de ataque físico conhecido.
Isso importa na prática de compra e especificação: quando um fornecedor diz “nosso módulo é certificado”, a primeira pergunta é “certificado em qual nível, por qual laboratório, com qual escopo de teste”. Nível 1 e nível 4 são mundos completamente diferentes de garantia, e ambos podem legitimamente carregar o rótulo “certificado FIPS 140”.
Falhas reais — porque teoria sem histórico de falha é meio caminho
Vale registrar casos reais que aconteceram, porque eles mostram que falha de segurança física não é hipotética — é recorrente, mesmo em produtos de fabricantes sérios:
- Fusível de proteção de microcontrolador que podia ser resetado sem apagar dados ou código. Alguns microcontroladores tinham um fusível de segurança que, em vez de forçar apagamento de memória ao ser resetado (como deveria), simplesmente voltava ao estado destravado — comprometendo toda a proteção presumida do chip.
- Vazamento de informação em smartcards. Num caso envolvendo produtos Hitachi, um datasheet completo do chip acabou incluído acidentalmente num CD de distribuição — mostrando que falha de segurança física às vezes não é sofisticação de ataque nenhuma, é negligência de processo.
- Bugs em chips FPGA e CPLD. Falhas de software em dispositivos de fabricantes como Actel e Xilinx reforçaram a necessidade de atualização contínua mesmo em componentes considerados “hardware”, não só firmware.
- Falha de inicialização de memória segura. Em dispositivos como a memória segura Dallas SHA-1, um erro de inicialização de fábrica resultou em ativação inadequada dos mecanismos de proteção — levando a recalls e revisões de segurança depois do produto já estar no mercado.
Esses casos têm uma coisa em comum: nenhum deles foi “o algoritmo criptográfico quebrou”. Todos foram falha de processo, de fabricação ou de decisão de design — o tipo de coisa que só aparece quando alguém audita de verdade, não quando alguém confia na especificação do datasheet.
Como isso se traduz em processo de projeto
Construir (ou escolher) um sistema fisicamente seguro não é sobre comprar o componente com o selo mais impressionante. É sobre:
- Modelar a ameaça primeiro: quem é o atacante provável, o que motiva ele, e que equipamento ele realisticamente teria acesso — o que conecta direto com o artigo sobre motivações de ataque físico que escrevi aqui no blog.
- Garantir que o custo de ataque supere o benefício do atacante: às vezes vale investir em componente mais caro precisamente porque a alternativa barata custa mais caro em prejuízo depois.
- Testar fornecedor, não confiar na marca dele: “certificado” e “seguro” são reivindicações de marketing até serem verificadas por teste independente. Sempre que possível, submeta o componente a teste próprio antes de integrar num produto que depende dele.
- Tratar segurança física como processo contínuo, não milestone: os casos de falha acima aconteceram em produtos que, no momento do lançamento, provavelmente passaram em toda checklist interna. A pergunta certa não é “isso está seguro hoje”, é “o que muda daqui a três anos quando o equipamento de ataque ficar mais barato”.
Junto com os artigos sobre taxonomia de ataque físico e sobre contramedidas concretas de design (bus scrambling, glue logic, sensor mesh), esse é o terceiro pé da mesa: entender o que pode acontecer, como se defender no nível de chip, e como medir se essa defesa de fato aguenta o que promete.
