Testemunho de Weeve – Uma etapa confiável para proteger a economia da máquina

(Gaurav Tiwari) (6 de maio de 2020)

Os dados foram comparados a commodities como petróleo ou ouro. Neste mundo conectado, mais e mais dados de qualidade irão capacitar o processo de tomada de decisão inteligente de máquinas implantadas em uma fábrica ou de vários dispositivos implantados em nossas casas. Mas há um grande desafio pela frente – como dados de qualidade e confiáveis ​​podem ser entregues com segurança de forma escalonável e automatizada? Os líderes da indústria de dispositivos embarcados de baixo custo estão trabalhando duro para trazer as melhores práticas de segurança de hardware e software amplamente disponíveis em dispositivos de ponta para esses dispositivos microcontrolados. Recursos limitados em microcontroladores, e com tantos sistemas operacionais e pilhas de soluções, levam a um cenário complexo e desafiador para a segurança incorporada.

Podemos categorizar os cenários de proteção de dados da seguinte maneira;

  • Dados em repouso
  • Dados em trânsito
  • Dados em uso

Na Weeve, estamos desenvolvendo soluções personalizadas para segurança de dados para dispositivos IoT baseados em microcontroladores.

  • Nós protegemos dados em repouso está usando uma solução de armazenamento confiável. Esses dados contêm ativos criptográficos, como chaves ou alguns ativos digitais, como moedas virtuais, etc.
  • Com dados em trânsito, desenvolvemos Weeve MQTTS, uma publicação-assinatura leve e segura construída no protocolo MQTT adaptado para dispositivos low-end. Esta é uma alternativa ao MQTT sobre TLS, que consome mais recursos de energia no limite.
  • Para dados em uso abordamos a integridade do processo em execução em um dispositivo IoT. Este processo pode ser a coleta de dados úteis usando sensores ou a execução de uma etapa de processamento de dados ou mesmo a execução de uma lógica de negócios no caso de um dispositivo atuador. Detectar e prevenir as vulnerabilidades de software do processo é a chave aqui. Estamos desenvolvendo o Weeve Testimony , um aplicativo de atestado de controle em tempo real, que é o tópico desta série de blog.

Antes de apresentarmos o Weeve Testimony, aqui está um pouco do histórico técnico dos problemas que estamos resolvendo e das tecnologias usadas em nossa solução.

Problemas de vulnerabilidade do programa C

Quase todos os softwares e firmware embarcados de baixo nível são desenvolvidos na linguagem de programação C. A falta de verificações adequadas dos limites de C para a memória alocada pretendida é uma fonte de grandes ameaças à segurança. Além do estouro de buffer, o programa C sofre de estouro de inteiros, vulnerabilidade de formato de string, sobrescrita de endereço de retorno, etc. Há também uma nova classe de ameaças de segurança para um programa C, como return-to-libc , e mais geral programação orientada a retorno (ROP) que são muito eficazes contra técnicas de mitigação comuns, como Prevenção de execução de dados e assinatura de código. A revisão de código adequada com ferramentas de segurança de aplicativo estáticas e dinâmicas pode reduzir a gravidade de tais vulnerabilidades. Existem outras técnicas na cadeia de ferramentas, como proteção contra empilhamento, no próprio hardware, como conjunto de bits NX para segmentos de dados, durante o tempo de execução, como randomizações de layout de espaço de endereço (ASLR). Mas o programa ainda está longe de ser uma garantia livre de vulnerabilidade justa. No contexto de dispositivos low-end baseados em microcontroladores, a técnica de mitigação mais eficaz de ASLR não é implementada devido à praticidade para evitar ter um carregador de tempo de execução.

Nossa abordagem para atenuar vulnerabilidades do programa C

Para resolver os problemas de vulnerabilidade do programa C, presumimos que sempre haverá falhas de segurança no programa, e por isso nos aventuramos a detectá-los em tempo de execução. Nós prevemos a existência de um processo de guarda isolado mais privilegiado que inspeciona e testifica o comportamento de um programa C em execução (o firmware MCU). O processo de guarda precisa ser isolado e mais privilegiado do que o firmware normal porque se fizer parte do mesmo processo ou nível de privilégio semelhante ao firmware normal, o hacker será capaz de hackear o processo de guarda, bem como explorar a mesma vulnerabilidade no firmware normal . Também prevemos a necessidade de uma entidade de atestação remota que saiba com antecedência (usando nossa ferramenta de criação de perfil) todos os instantâneos de execução válidos da execução normal do firmware e testemunhe esses instantâneos periodicamente.

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *