💻 computer science

Controller Datapath Aware Verification of Masked Hardware Generated via High Level Synthesis

Este trabalho apresenta o fluxo de ferramentas MaskedHLSVerif, que realiza verificação formal de estado em RTL gerado por Síntese de Alto Nível (HLS) para garantir a segurança contra ataques de canal lateral de potência em hardware mascarado, evitando falsos positivos causados por otimizações de síntese que compartilham recursos no datapath.

Autores originais: Nilotpola Sarma, Vaishali Ghanshyam Chaudhuri, Chandan Karfa

Publicado 2026-03-20

📖 4 min de leitura☕ Leitura rápida

CC BY 4.0

Autores originais: Nilotpola Sarma, Vaishali Ghanshyam Chaudhuri, Chandan Karfa

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você tem um segredo muito valioso, como uma senha bancária, e precisa processá-lo em um computador. O problema é que, ao fazer isso, o computador consome energia de formas diferentes dependendo dos números que está calculando. Um hacker esperto pode medir esse consumo de energia (como ouvir o som de uma fechadura sendo girada) e deduzir qual é a sua senha. Isso é chamado de Ataque de Canal Lateral.

Para evitar isso, os especialistas usam uma técnica chamada Mascaramento. É como se você não trabalhasse com a senha inteira, mas a dividisse em vários pedaços aleatórios (como rasgar um bilhete em 3 partes). Cada parte, sozinha, não diz nada sobre a senha original. Só quando você junta tudo no final é que a senha aparece.

O Problema: A Fábrica Automática (HLS)

Antigamente, criar esses circuitos "mascarados" era feito à mão por engenheiros muito experientes. Era lento e cheio de erros.
Então, surgiu uma ferramenta chamada Síntese de Alto Nível (HLS). Pense nela como uma "fábrica automática" ou um "tradutor mágico". Você escreve o código do segredo em uma linguagem simples (como C), e a ferramenta cria automaticamente o circuito de hardware complexo.

O problema é que essa fábrica automática foi feita para ser rápida e barata, não para ser segura. Para economizar espaço e tempo, ela faz truques de otimização:

Compartilhamento de Recursos: Em vez de ter 4 multiplicadores, ela usa 2 e os faz trabalhar em turnos diferentes (como um único caixa atendendo várias filas em horários diferentes).
Reorganização: Ela muda a ordem das operações para que o cálculo termine mais rápido, como um chef que muda a ordem de cortar os ingredientes para economizar tempo.

Esses truques, embora eficientes, podem quebrar o segredo. Se o "caixa" (o hardware) misturar os pedaços do bilhete rasgado no momento errado, o hacker pode ver algo que não deveria.

O Erro dos Detectores Atuais

Existem ferramentas que verificam se o circuito está seguro. Mas elas funcionam como um detetive muito desconfiado e ingênuo.
Essas ferramentas olham para o circuito e dizem: "Olha, aqui existe um caminho onde o pedaço A pode se encontrar com o pedaço B. Isso é perigoso!".

O problema é que, na fábrica automática (HLS), esse caminho nunca existe na realidade. O "caixa" (o controlador do circuito) garante que A e B nunca se encontrem ao mesmo tempo. Mas o detetive ingênuo não entende o horário de funcionamento do caixa. Ele vê a possibilidade teórica e grita: "ALERTA DE FALHA!", mesmo quando o sistema está seguro. Isso é chamado de Falso Positivo. É como um alarme de incêndio que toca porque você fez um sanduíche, e não porque há fogo.

A Solução: O Detetive Inteligente (MaskedHLSVerif)

Os autores deste paper criaram uma nova ferramenta chamada MaskedHLSVerif. Em vez de ser um detetive desconfiado, eles criaram um detetive que entende de horários e turnos.

Aqui está a analogia do funcionamento deles:

Entendendo o Turno (Estado): A ferramenta sabe exatamente em qual "turno" (estado) o circuito está operando a cada segundo.
Filtrando o Impossível: Ela olha para o circuito e diz: "Ok, neste momento, o Multiplicador 1 só está lidando com os pedaços A e B. O pedaço C está em outro lugar, descansando. Vamos verificar apenas A e B."
Verificação Passo a Passo: Ela divide o grande circuito em pequenos pedaços, um para cada turno, e verifica a segurança de cada um individualmente, garantindo que, naquele momento específico, os pedaços do segredo não estejam se misturando de forma perigosa.

O Resultado

Com essa nova abordagem, a ferramenta consegue:

Parar de gritar falsos alarmes: Ela sabe que certas combinações de dados nunca acontecem porque o "caixa" não permite.
Achar falhas reais: Se a fábrica automática (HLS) realmente fez um erro de otimização (como misturar os pedaços do bilhete na ordem errada), o novo detetive consegue ver isso e avisar o engenheiro.

Resumo em uma frase

Enquanto as ferramentas antigas olhavam para o mapa de todas as ruas possíveis (incluindo as que foram fechadas) e achavam que havia um ladrão, a nova ferramenta olha para o trânsito real, sabe quais ruas estão abertas naquele momento e só avisa se houver um ladrão realmente na rua.

Isso permite que engenheiros usem a "fábrica automática" para criar chips criptográficos rápidos e baratos, sem medo de que a otimização automática tenha deixado uma porta aberta para hackers.

Título: Verificação Consciente de Controlador-Datapath de Hardware Mascaramento Gerado via Síntese de Alto Nível (HLS)

1. Problema Identificado

O artigo aborda um desafio crítico na segurança de hardware criptográfico: a verificação de implementações mascaradas geradas automaticamente por ferramentas de Síntese de Alto Nível (HLS).

Contexto: O mascaramento (splitting de segredos em "shares" aleatórias) é uma contramedida essencial contra Ataques de Canal Lateral de Potência (PSCA). No entanto, o mascaramento manual de hardware é complexo e propenso a erros.
A Solução Atual e seus Limites: Para reduzir o tempo de design, pesquisadores usam HLS para converter especificações de software mascarado em hardware RTL (Register-Transfer Level). Contudo, as ferramentas HLS não foram desenvolvidas com segurança em mente. Elas aplicam otimizações (como balanceamento de expressões e reassociação) e compartilham recursos (datapaths com multiplexadores controlados por uma Máquina de Estados Finita - FSM) para reduzir área e latência.
O Falha na Verificação Existente: Ferramentas de verificação formal de estado da arte (como o REBECCA) assumem que todos os caminhos de dados sintaticamente possíveis podem estar ativos. Em designs HLS com compartilhamento de recursos, certas combinações de entradas em multiplexadores são inacessíveis devido ao controle da FSM.
- Consequência: As ferramentas existentes verificam combinações de dados que nunca ocorrem no hardware real, gerando falsos positivos (alertando sobre vazamentos de segurança que não existem). Isso inviabiliza a confiança na segurança de designs gerados por HLS.

2. Metodologia Proposta: MaskedHLSVerif

Os autores propõem um fluxo de verificação chamado MaskedHLSVerif, que adapta ferramentas existentes para lidar com a arquitetura específica de hardware gerada por HLS (controlador + datapath compartilhado).

Abordagem Baseada em Estados (State-wise Verification):
Em vez de verificar o design RTL completo de uma só vez (o que inclui caminhos inativos), o método decompõe o design em sub-designs menores, correspondentes a cada estado da FSM.
Passos do Fluxo:
1. Geração do RTL: O design de software mascarado é convertido para RTL via HLS.
2. Extração de Estados: O fluxo identifica os estados da FSM gerada pelo HLS.
3. Divisão do Design: O design original é dividido em sub-designs ( $D_x$ ) para cada estado. Crucialmente, cada sub-design inclui não apenas as operações daquele estado, mas também as operações dependentes de estados anteriores (para manter a cadeia de dependência dos dados mascarados).
4. Rótulagem Recursiva: As entradas de cada sub-design são rotuladas corretamente (como "Share", "Mask" ou "Público") baseando-se nas entradas originais do design, garantindo que a propagação de rótulos seja precisa.
5. Verificação Formal: Cada sub-design é verificado individualmente pela ferramenta REBECCA.
6. Análise de Resultados: Se um sub-design falhar, o fluxo identifica se a falha é devido a uma operação independente daquele estado ou a uma dependência de um estado anterior.
Vantagem Chave: Ao restringir a verificação apenas às configurações de datapath que são ativáveis em um estado específico da FSM, o método elimina os caminhos de dados inalcançáveis que causavam os falsos positivos nas ferramentas tradicionais.

3. Principais Contribuições

Identificação de Limitações: Demonstração formal de que ferramentas SOTA (State-of-the-Art) falham ao verificar designs HLS devido à sua incapacidade de considerar a lógica de controle (FSM) e o compartilhamento de recursos.
Impacto das Otimizações HLS: Análise de como otimizações do HLS (como reassociação e balanceamento de expressões) podem quebrar a segurança do mascaramento, alterando a ordem de avaliação de operações ou removendo etapas de re-mascaramento necessárias.
Novo Fluxo de Verificação: Desenvolvimento do MaskedHLSVerif, o primeiro método capaz de verificar corretamente hardware mascarado gerado por HLS, eliminando falsos positivos e detectando falhas reais induzidas por otimizações.
Validação Experimental: Prova de conceito através de benchmarks criptográficos complexos.

4. Resultados Experimentais

Os autores testaram o método em seis benchmarks, incluindo multiplicadores mascarados em cascata (DOM, COMAR, HPC1, HPC2) e a S-box do cipher PRESENT.

Experimento 1 (Validação de Falsos Positivos):
- Ao aplicar o REBECCA diretamente nos designs RTL gerados pelo HLS, a ferramenta reportou falsos positivos (indicou insegurança) para todos os seis casos, devido aos caminhos inalcançáveis.
- Ao aplicar o MaskedHLSVerif, todos os designs foram verificados como seguros, o que foi confirmado posteriormente por testes de TVLA (Test Vector Leakage Assessment) em nível de gate, provando que o hardware real não vazava informações.
Experimento 2 (Detecção de Falhas Reais):
- Os autores forçaram uma otimização de "reassociação" no HLS (ativando pragmas específicos) que alterou a ordem de operações, criando uma falha real de mascaramento de primeira ordem.
- O MaskedHLSVerif detectou corretamente essa falha no estado específico onde a reassociação ocorreu, enquanto o REBECCA padrão continuava a reportar falsos positivos genéricos.
Métricas: O fluxo demonstrou ser computacionalmente viável, com tempos de execução de verificação variando de frações de segundo a alguns segundos por estado, dependendo da complexidade do datapath.

5. Significância e Conclusão

Este trabalho é fundamental para a adoção segura de Síntese de Alto Nível em criptografia.

Confiança no Design: Permite que engenheiros utilizem a produtividade do HLS sem sacrificar a segurança contra PSCA, desde que o design seja verificado com o fluxo correto.
Precisão: Resolve o problema de "falsos positivos" que anteriormente desencorajava o uso de HLS para hardware seguro.
Detecção de Vulnerabilidades de Otimização: O método não apenas verifica a segurança, mas também atua como uma ferramenta de depuração para identificar quando otimizações automáticas do HLS comprometem a segurança do algoritmo criptográfico.

Em resumo, o MaskedHLSVerif preenche uma lacuna crítica na cadeia de ferramentas de design de hardware seguro, permitindo a verificação formal precisa de designs gerados automaticamente que utilizam arquiteturas de datapath compartilhado controladas por FSM.