Fuzzing para validar a segurança do SoC. Inovação na Verificação

Fuzzing é para verificação de software o que a randomização é verificação de hardware. Uma abordagem de difusão pode melhorar os testes de segurança de hardware? Paul Cunningham (GM, Verificação na Cadence), Raúl Camposano (Catalisador de Silício, empresário, ex-CTO da Synopsys) e eu continuamos nossa série de ideias de pesquisa. Como sempre, o feedback é bem-vindo.

A Inovação

A escolha deste mês é HyperFuzzing para validação de segurança SoC. Os autores apresentaram este artigo no ICCAD 2020. Eles são do IIT Kanpur.

Esta é uma abordagem intrigante para fuzzing, adaptada especificamente ao design SoC moderno. Baseia-se em hiper-propriedade verificar em simulações dinâmicas. Essas hiperpropriedades raciocinam sobre os comportamentos ao longo conjuntos de traços, uma abordagem adequada para verificação de segurança. Os autores oferecem como exemplos verificações de fluxo de informações (dados privilegiados não podem vazar de A para B, digamos) e verificações de não interferência (ações adversárias não devem interferir no fluxo de cálculos). A segurança é então verificada comparando pacotes de traços de simulação com e sem adulteração.

A adulteração dessa abordagem pode modelar diferentes tipos de vulnerabilidades para fontes não confiáveis. Ao randomizar as instruções de firmware, escreva as instruções de um componente para o NoC ou bit flips em uma memória. Os autores também propõem várias novas métricas de cobertura. Eles são projetados para orientar as iterações de adulteração em casos mais influenciados por execuções de adulteração anteriores.

Seu caso de teste é um SoC pequeno, embora representativo (detalhes em GitHub) executando testes de firmware em blocos criptográficos, verificando a não interferência e outras vulnerabilidades. Eles também executam uma inicialização segura com verificações de bloco de dados. Eles encontraram várias violações de segurança nos blocos de criptografia, exceto onde o bloco inclui proteção ECC.

Visão de Paul

A verificação de segurança é um tópico muito importante e há muito trabalho em andamento aqui, tanto na academia quanto na indústria. Este artigo reúne agradavelmente cobertura baseada em mutação aleatória com “hiperpropriedades” sobre conjuntos de traços de simulação para criar uma solução inovadora que é escalonável e eficaz na demonstração de falhas de segurança.

Algumas propriedades de segurança podem ser definidas formalmente apenas em um conjunto de rastreamentos de simulação. Por exemplo, “não interferência” significa que um invasor não pode interferir em certos cálculos protegidos em um design. Para demonstrar a interferência, você precisa comparar dois traços, idênticos no estímulo de entrada, exceto pela presença de algumas ações do invasor em um traço. Se quaisquer cálculos protegidos no traço atacado diferirem daqueles no traço dourado, então houve interferência.

Os autores criam seu próprio sabor especial de linguagem para afirmações sobre vários rastros e usam-no para formular propriedades de segurança para não interferência e confidencialidade. Eles criam um fluxo personalizado para adulterar aleatoriamente as simulações e verificar suas propriedades de segurança entre simulações adulteradas e não adulteradas. Seu algoritmo de adulteração aleatória também tem uma heurística de aprendizagem baseada em cobertura elegante para guiá-lo para encontrar falhas de segurança com mais eficiência.

A ideia de asserções em várias simulações é muito poderosa. Eu me pergunto se seria possível estender SystemVerilog de forma limpa para oferecer suporte a esses tipos de asserções. Isso poderia abrir a porta para algumas extensões nativas atraentes para simulação comercial e ferramentas formais. Outra possibilidade pode ser estender o novo Portable Stimulus Standard (PSS) para incluir afirmações que abrangem vários testes gerados.

Este artigo é uma leitura fácil e agradável, embora eu deseje mais alguns detalhes sobre os resultados. Os autores afirmam que sua solução encontra brechas de segurança em seu caso de teste de SoC de código aberto, mas não há detalhes sobre o que são essas brechas ou como sua abordagem se compara a outras abordagens na literatura que poderiam ser aplicadas para encontrar as mesmas brechas.

Visão de Raúl

Vou olhar para isso primeiro do ângulo da maturidade da tecnologia. Eu gosto da ideia em geral, uma abordagem muito interessante para avaliar a segurança em um design. Dito isso, cada projeto exige que os designers forneçam testes de sementes, adulteradores e especificações de segurança em uma nova linguagem de asserção. Para mim, isso limita a abordagem firmemente ao domínio acadêmico por enquanto. Ótimo para dissertações e artigos, ainda não está perto de algo que poderia fazer o salto para a aplicação comercial.

Vou colocar meu chapéu de investidor para o segundo desafio. Segurança é um tópico importante, sem dúvida. Mas fora de alguns domínios que já conhecemos - aeroespacial, defesa, sistemas de pagamento e processadores / servidores, por exemplo. Ainda não é um problema existencial para a maioria dos OEMs e fabricantes de componentes. Eles estão dispostos a marcar uma caixa, se geralmente esperados. Mas apenas se o impacto no custo ou no tempo de comercialização for pequeno. Porque seus clientes geralmente não pagam mais pela segurança. O que deixa a segurança para a maioria dos mercados ainda dependente de IP pronto para uso, como raízes de confiança de hardware e aplicativos fáceis de usar. As soluções empacotadas de uma dessas maneiras podem ser investidas, caso contrário, não tanto.

Minha visão

Paul e Raúl cobriram a maior parte do que eu poderia ter sugerido. Gosto da ideia de Paul de estender o SVA, pelo menos para encorajar a experimentação com hiperpropriedades. Isso deve abrir uma nova classe de testes interessantes, levando eventualmente a novos métodos de verificação agrupados.

Compartilhe esta postagem via: Fonte: https://semiwiki.com/eda/299391-fuzzing-to-validate-soc-security-innovation-in-verification/