📬 Toda semana, um resumo de segurança, Clean Code e IA no seu e-mail Inscreva-se →

O que são Physically Unclonable Functions (PUFs) e para que servem

Um problema clássico de quem projeta hardware com propriedade intelectual valiosa: você grava uma chave de criptografia na flash do dispositivo pra proteger o firmware ou autenticar o produto original. Só que essa chave está lá, em algum endereço de memória, esperando alguém com um programador de flash e paciência pra extrair. Uma vez extraída, ela pode ser copiada pra mil placas clonadas idênticas. A chave “secreta” vira um segredo público em massa.

PUF (Physically Unclonable Function) ataca esse problema por um ângulo diferente: em vez de guardar um segredo em algum lugar pra depois proteger esse lugar, você gera o segredo a partir de algo que fisicamente não dá pra copiar — as variações microscópicas de fabricação de cada chip individual.

A ideia central

Dois chips saídos da mesma máscara, do mesmo wafer, do mesmo lote de produção, não são idênticos no nível físico. Espessura de trilha, dopagem do silício, atraso de propagação em portas lógicas — tudo isso varia de forma minúscula e imprevisível entre unidades, mesmo com processo de fabricação idêntico. Essa variação normalmente é ruído que os engenheiros tentam minimizar. PUF vira esse ruído de cabeça pra baixo e usa exatamente essa imprevisibilidade como fonte de identidade única.

Um exemplo concreto de circuito PUF (do tipo arbiter/delay-based): você monta dois caminhos de sinal supostamente idênticos, cada um passando por uma sequência de portas lógicas (inversores, por exemplo), e os dois caminhos chegam a um flip-flop que funciona como árbitro. No papel, os dois caminhos deveriam levar exatamente o mesmo tempo. Na prática, um deles sempre chega um pouquinho antes — por causa de variações de fabricação que não dá pra prever nem replicar de propósito. O flip-flop registra qual caminho venceu, e essa resposta (0 ou 1) é única daquele chip específico, repetível toda vez que você aplica o mesmo estímulo (challenge), mas impossível de prever a partir do design ou de replicar em outro chip, mesmo que seja fabricado com a mesma máscara.

Aplique várias combinações diferentes de challenge e você tem um conjunto de pares challenge-response (CRPs) que funciona como impressão digital daquele chip.

Ring Oscillator PUF e outras variantes

A variante mais estudada academicamente é o Ring Oscillator PUF: em vez de um par de caminhos competindo uma única vez, você monta vários osciladores em anel (loops de portas lógicas invertendo sinal continuamente) e compara a frequência de oscilação entre pares deles. Pequenas variações de fabricação fazem cada oscilador rodar numa frequência ligeiramente diferente, e comparar pares dá o mesmo tipo de resposta determinística-mas-única.

Existem também PUFs baseados em SRAM, que exploram o estado inicial (0 ou 1) de células de memória no momento em que a energia é ligada — antes de qualquer escrita, cada célula “nasce” com uma tendência física pra um dos dois estados, e essa tendência é consistente ao longo de milhares de power-ups do mesmo chip, mas varia de chip pra chip. É particularmente atraente porque SRAM já existe em praticamente todo microcontrolador — você ganha PUF de graça, sem circuito adicional.

Pra que serve isso na prática

  • Geração de chave criptográfica sem armazenamento. Em vez de gravar a chave na flash (onde pode ser extraída), você deriva a chave a partir da resposta do PUF sempre que precisa dela. Ela nunca fica persistida em lugar nenhum — se o chip está desligado, a chave “não existe”.
  • Autenticação de dispositivo/anticlonagem. Um fabricante registra os pares challenge-response de cada chip legítimo antes de sair da fábrica. No campo, ele manda um challenge e verifica se a resposta bate com o que foi registrado. Uma placa clonada, mesmo com o design idêntico, vai gerar respostas diferentes porque a física dela é diferente.
  • Licenciamento de software atrelado a hardware específico, sem depender de um número de série gravável (e portanto alterável).

Onde isso quebra na prática

Aqui é onde eu preciso ser honesto, porque PUF é frequentemente vendido como solução mágica e não é. O maior problema real de PUF é confiabilidade, não segurança teórica.

Temperatura, tensão de alimentação e envelhecimento do chip afetam justamente as variações físicas que o PUF está medindo. Um Ring Oscillator PUF calibrado a 25°C pode dar uma resposta ligeiramente diferente a 70°C — e “ligeiramente diferente” é péssimo quando você precisa da mesma chave bit a bit toda vez. Isso força o uso de mecanismos de correção de erro (fuzzy extractors, códigos corretores) por cima do PUF puro, o que adiciona complexidade e, pior, pode vazar informação sobre a resposta original se implementado de forma descuidada.

Cenário real: um PUF que funciona perfeitamente em bancada de testes no laboratório, com fonte de alimentação estável e temperatura controlada, pode apresentar taxa de erro de bit inaceitável quando o dispositivo vai pro campo — variação de temperatura ambiente, ruído de fonte compartilhada com outros circuitos no mesmo PCB, ou simplesmente o chip envelhecendo alguns milhares de horas de uso. Se o seu produto depende de PUF pra derivar chave de criptografia e você não testou sob essas condições de variação, é bem provável que ele funcione no protótipo e falhe de forma intermitente em produção.

O que eu recomendo antes de adotar

PUF não é “instale e esqueça”. Antes de colocar num projeto real, valide:

  1. Taxa de erro de bit sob variação de temperatura e tensão da faixa operacional real do produto, não só condições de bancada
  2. Estabilidade ao longo do tempo de vida esperado do dispositivo (envelhecimento do silício)
  3. Se você realmente precisa de PUF ou se um elemento seguro dedicado (secure element com chave provisionada de fábrica) resolve o mesmo problema com menos complexidade de engenharia

PUF é uma ferramenta poderosa pra um problema específico — identidade de hardware sem chave armazenada — não um substituto genérico pra tudo relacionado a chave criptográfica. Se você está avaliando isso pra um projeto de autenticação de hardware ou anticlonagem, vale a pena entender também como funciona secure boot e onde PUF se encaixa (ou não) nessa cadeia — é assunto pra outro artigo aqui no blog.

Leandro Rosendo Candido

Leandro Rosendo Candido

Engenheiro de Computação, mestre pela USP, 10+ anos com Embedded Linux. Escreve e grava sobre segurança, Clean Code e IA aplicada à programação.

Rolar para cima