Proteger um chip já não é uma questão de verificação final ou de uma certificação anexada ao produto antes de seu lançamento, mas um processo que se estende do projeto à implantação e ao monitoramento. Essa foi a principal conclusão de um debate fechado organizado pela Semiconductor Engineering durante a conferência Design Automation Conference, com a participação de especialistas da Arteris, Cadence, Keysight EDA, Rambus, Siemens EDA, Synaptics e Synopsys. Este material baseia-se em trechos desse debate, conduzido por Ann Mutschler.
A superfície de ataque se amplia com a disseminação da inteligência artificial, dos chiplets, dos sistemas definidos por software, dos FPGAs e dos sistemas conectados. Por isso, o risco não se limita a um defeito físico no circuito ou a um ataque ao próprio chip; ele pode começar na rede, no software embarcado ou em uma camada programável, e então explorar uma vulnerabilidade para acessar ou interromper o sistema.
Da certificação ao uso real
Yathiendra Vunnam, da Cadence, observou que muitos clientes adotam uma defesa em várias camadas, utilizando mecanismos como IPsec e MACsec em diferentes camadas do modelo OSI para atender às necessidades de desempenho e computação. Ele também explicou que algumas empresas se concentram na certificação porque ela as ajuda a vender o produto, e depois reduzem o conjunto de proteções necessárias para chegar a um projeto menor, de menor custo e reutilizável.
O problema, segundo Scott Best, da Rambus, é que possuir uma tecnologia de proteção não comprova que ela foi aplicada corretamente. O cliente pode solicitar proteção contra ataques de canal lateral, ataques de injeção de falhas ou tecnologia PUF e, depois, tratar esses elementos como itens concluídos em uma lista de requisitos, sem esclarecer como serão integrados e utilizados no sistema final. O mesmo se aplica à conformidade com estruturas como CRA e ISO 26262 ou à obtenção do CSIP Level 3 da Keysight ou de uma concorrente.
Isso não significa que certificações ou padrões não tenham valor, mas que, sozinhos, não fornecem evidências suficientes de que o produto é seguro em condições reais de operação. A lacuna enfatizada pelos participantes é a diferença entre a existência de um mecanismo de segurança no papel e sua capacidade de funcionar quando integrado ao restante do hardware, do software e das redes.
A visibilidade começa pela lista de componentes
Alexander Petr, da Keysight EDA, afirmou que os sistemas modernos são construídos em níveis sobrepostos: um chip, depois um pacote, uma placa, um sistema e, por fim, um ecossistema conectado que inclui data centers e redes amplas. À medida que mais funções migram para o software embarcado, saber o que entra no produto torna-se uma condição para acompanhar os riscos.
Isso inclui criar uma lista de software para os componentes de hardware, ou o que Petr descreveu como a importância de uma Software Bill of Materials for hardware, além do rastreamento de vulnerabilidades e do monitoramento após a implantação. A dificuldade aumenta com o software de código aberto, pois ele chamou a atenção para tentativas de agentes mal-intencionados de se infiltrar em comunidades de código aberto e injetar backdoors. Além disso, descobrir uma vulnerabilidade zero-day não é suficiente; a empresa precisa primeiro saber se seu sistema utiliza o componente afetado e, depois, se é capaz de corrigi-lo ou criar uma defesa adequada.
A arquitetura de chiplets acrescenta outro desafio. A possibilidade de montar unidades de diferentes fontes pode reduzir os custos, pois nem todo bloco precisa necessariamente utilizar os nós mais avançados, mas levanta uma questão prática: como o projetista verifica a segurança de cada chiplet e garante que a unidade menos segura não coloque todo o sistema em risco?
A regulamentação aumenta a conscientização, mas não garante comportamento
Os participantes concordaram que as regulamentações, incluindo a Lei Europeia de Resiliência Cibernética CRA, elevaram o nível de conscientização e levaram algumas empresas a investir em raízes de confiança e proteção embarcada. Chris Giles, da Siemens EDA, afirmou que a existência da lei não é suficiente, pois a fiscalização será necessária para transformar os requisitos em investimento contínuo. Os participantes mencionaram que a data relacionada aos semicondutores é 11 de setembro de 2026, embora permaneçam dúvidas sobre o que deverá ser divulgado e como isso será aplicado na prática.
Mohit Arora, da Synaptics, também observou que as penalidades podem chegar a 4% da receita anual, enquanto Reed Hinkel, da Synopsys, considerou que esse tipo de pressão começou a levar empresas antes hesitantes a colocar uma grande raiz de confiança no chip ou a adotar iniciativas do Open Compute Project, como a Caliptra. O debate, porém, mostrou que o impacto das regulamentações sobre o comportamento ainda não foi definido; Giles disse que a CRA está muito presente nas conversas, mas não tinha certeza de que havia mudado as práticas, enquanto Petr observou que não haviam sido aplicadas multas até o momento do debate.
O que muda na prática?
A transformação necessária não consiste apenas em comprar ferramentas ou propriedade intelectual adicional de segurança, mas em distribuir a responsabilidade entre as equipes de projeto, software, gerenciamento de produto e operações. Quanto maior o valor do serviço oferecido pelo produto, maior o custo da falha de segurança e da responsabilidade associada a ela. Por isso, Hinkel considerou que as promessas de serviços de alto valor devem estar acompanhadas de uma capacidade real de cumprir acordos de nível de serviço e responder a vulnerabilidades.
Os incentivos comerciais e militares também aparecem no debate. Produtos que conquistam a confiança dos usuários podem justificar um investimento maior em segurança, enquanto as necessidades do Departamento de Defesa dos Estados Unidos e de seus fornecedores, entre eles Boeing e Airbus, conforme mencionado no debate, impulsionam parte dos investimentos nessa área. Isso, porém, não elimina as limitações: a segurança sempre compete com o custo e o prazo de lançamento, e a certificação pode continuar sendo mais fácil de medir do que a qualidade da implantação e do monitoramento.
Quanto à criptografia pós-quântica, Hinkel explicou que o desafio não se limita ao hardware ou ao firmware, mas se estende aos aceleradores de chave pública PKA, construídos historicamente sobre camadas acumuladas difíceis de atualizar e ampliar. Segundo o debate, os produtos precisam oferecer suporte aos novos algoritmos em três anos, enquanto a retirada dos algoritmos antigos está associada a um horizonte de cinco anos. Isso indica que a preparação para a criptografia pós-quântica exige uma reorganização arquitetônica, e não apenas a adição de um algoritmo a um projeto existente.
A principal conclusão para o leitor técnico é que a segurança comprovável deve abranger o que existe dentro do produto, como foi integrado e como será monitorado após a venda. A certificação permanece um ponto de verificação nesse processo, não um substituto para ele. Os detalhes da fiscalização regulatória, os limites da divulgação de vulnerabilidades e a capacidade das empresas de corrigir produtos já disseminados no mercado continuam sendo questões em aberto que a fonte não resolveu.