Padrões para manter a segurança dos dispositivos atualizada

Com dispositivos IoT tipicamente sendo construídos com baixas margens de lucro e especificações de baixa potência, a funcionalidade é tipicamente limitada ao necessário. Porém, para um dispositivo que deve durar vários anos, haverá vulnerabilidades e problemas de segurança que precisam ser corrigidos (veja a botnet da Mirai como exemplo)

Como fabricante de IoT, como posso habilitar remotamente ou atualizar remotamente algoritmos de criptografia ou protocolos de segurança ou simplesmente garantir que o dispositivo seja mantido seguro? Que padrões devo seguir?

Como os fabricantes de IoT habilitam o patch ou a atualização de algoritmos de criptografia ou protocolos de segurança remotamente ou simplesmente para garantir que o dispositivo seja mantido seguro?

Um grande número de fabricantes de IoT tem uma solução simples para isso: "não se preocupe" . Esses tendem a ser os mesmos desenvolvedores que adicionam senhas padrão (ou mesmo imutáveis) a seus dispositivos, o que levou ao Mirai em primeiro lugar.

Conforme mencionado na resposta de Rory , há custos consideráveis ​​em fornecer os mecanismos e o tempo real de desenvolvimento para projetar e implantar as correções. Eu suspeito fortemente que, sem pressão regulatória (ou demanda do consumidor, o que não parece ser o caso), não haverá incentivo para um fabricante aumentar os preços de seus produtos para aumentar a segurança. A Austrália parece estar dando esse passo considerando um sistema obrigatório de classificação de segurança para todos os dispositivos de IoT.

Penso que, para a maioria dos fabricantes, a melhor ideia é conseguir que outra pessoa cuide da segurança. Assim como a maioria dos desenvolvedores da Web usa estruturas estabelecidas como Django e Ruby on Rails para evitar cometer os mesmos erros repetidamente, os desenvolvedores de IoT devem fazer o mesmo. Existem várias opções, dependendo da complexidade do seu dispositivo:

• Os dispositivos de ponta podem usar sistemas operacionais como o Ubuntu IoT ou o Windows 10 IoT Core, em que as atualizações de segurança são feitas pelo desenvolvedor do SO e enviadas automaticamente. Muito disso não é específico da IoT, mas é muito preferível a cada dispositivo da IoT usando um sistema operacional interno personalizado que dificilmente receberá manutenção.

• Dispositivos low-end, como os módulos ESP8266, talvez sejam mais limitados, pois não são capazes de executar sistemas operacionais tão complexos e tendem a executar código desenvolvido especificamente para esse dispositivo. Ainda existem opções, como o Mongoose OS, que oferecem atualizações de firmware over-the-air

Os fabricantes de IoT geralmente devem tirar proveito das soluções existentes, quando disponíveis. Os desenvolvedores da Web geralmente não recriam uma estrutura da Web para cada novo site, então por que a IoT deve ser substancialmente diferente? A resposta de Rory oferece uma excelente lista de recursos que devem ser implementados por um bom sistema operacional para a IoT, e apenas o uso de um "IoT OS" não resolverá todos os seus problemas. Como este guia do Windows IoT explica, é necessário executar etapas para garantir que o hardware e o firmware estejam protegidos, bem como o próprio sistema operacional. As idéias na resposta de Rory são bastante abrangentes nesse sentido.

Aqui estão alguns exemplos dos sistemas operacionais que sugeri sobre quais sistemas eles usam para atualizar a segurança:

• IoT do Windows:

  • Recurso automático e atualizações de segurança quando conectado à Internet
  • Com o Azure IoT Suite, cada dispositivo tem um certificado X.509 para autenticar no hub. Isso também garante que, se um dispositivo for comprometido, outros não serão afetados

• Ubuntu Core :

  • Atualizações automáticas autônomas para segurança
  • "Atualizações transacionais sem fio - com recursos completos de reversão"

Moran publicou este rascunho da IETF intitulado Uma arquitetura de atualização de firmware para dispositivos da Internet das coisas em 30 de outubro de 2017.

Um resumo importante descrito no computador Bleeping é

• O mecanismo de atualização deve funcionar da mesma maneira, mesmo que o binário do firmware seja entregue via Bluetooth, WiFi, UART, USB ou outros meios.
• O mecanismo de atualização deve funcionar em um tipo de entrega de broadcast, permitindo que as atualizações alcancem vários usuários ao mesmo tempo.
• A segurança de ponta a ponta (criptografia de chave pública) deve ser usada para verificar e validar imagens de firmware.
• Ataques de reversão devem ser evitados.
• Todas as informações necessárias para um dispositivo tomar uma decisão sobre a instalação de uma atualização devem caber na RAM disponível de um dispositivo IoT restrito. Isso evita a exaustão da gravação em flash.
• Uma falha de energia a qualquer momento durante o processo de atualização não deve causar uma falha no dispositivo.
• O mecanismo de atualização de firmware não deve exigir alterações nos formatos de arquivo de firmware existentes.
• O novo mecanismo de atualização de firmware deve poder operar com um pequeno carregador de inicialização, específico para a maioria dos dispositivos de IoT.
• O mecanismo de atualização deve contabilizar várias permissões. Por exemplo, uma atualização de firmware para equipamentos críticos de infraestrutura deverá ser assinada pelo autor do firmware e pelo proprietário / operador do equipamento.
• A nova arquitetura de atualização de firmware da IoT deve suportar arquivos de manifesto.

Este é um rascunho, pois é uma nova área. Minha expectativa é que isso seja impulsionado mais pela regulamentação do que pela demanda do consumidor, pois os consumidores realmente não se importam com atualizações ou segurança, a menos que os afetem diretamente. Quaisquer melhorias nesta área afetarão o custo dos dispositivos.

Se o firmware do seu dispositivo puder ser menos complexo que o carregador de inicialização necessário para uma atualização remota segura, não implemente a atualização remota .

Eu sei que o consenso é ter um gerenciador de inicialização seguro e robusto, com autenticação criptográfica pública forte, mecanismos de rollover seguros, talvez uma pilha de rede básica, e depois colocar um RTOS, com uma pilha de rede IP + TLS completa, e adicionar Além disso, sua aplicação. Isso é pura insanidade para um dispositivo de baixo consumo e baixo consumo de energia. IMHO, isso leva a produtos que são atualizados a cada semana ou mais, o que tende a incomodar os usuários, porque às vezes as atualizações começam no momento errado, falham ou quebram algo. As atualizações também consomem muita energia, portanto, o usuário precisa cobrar com mais frequência. E a segurança ainda está longe de ser garantida, pois a superfície de ataque é grande.

Seu dispositivo está realizando detecção / atuação básica, talvez algum acionamento / exibição local, mas não muito? Pule tudo isso.

Escreva código bare metal, use uma pilha muito básica, faça uma auditoria completa, faça uma verificação formal, se possível. E então você pode estar relativamente confiante de que seu dispositivo não terá problemas de segurança na próxima década.

Se tudo que você tem é um martelo, tudo parece um prego. E é por isso que a maioria dos codificadores tenta escrever código para proteger o código existente não seguro. Escrever menos código nem sempre é natural.