Raiz de confiança para IoT e outras tendências de segurança da IoT

O tópico segurança da informação está se tornando cada vez mais relevante a cada ano. O hub de segurança da informação está em primeiro lugar na classificação e em segundo no número de assinantes. No entanto, os materiais são dedicados principalmente a várias redes, web, nuvem e outras tecnologias tradicionalmente consideradas no contexto da segurança. E quase não se aplicam a aplicativos incorporados, especialmente com recursos limitados. Enquanto o número deste último é mais do que ordens de magnitude. Neste artigo, examinaremos alguns dos recursos e tendências na segurança da Internet de coisas que têm sua origem no modelo de desenvolvimento e distribuição.


Além disso, o desenvolvimento de aplicativos incorporados sempre carregou certos recursos, de modo que a maioria dos programadores "comuns" nem pensa nisso, e o conceito de controle de qualidade e processo de teste em muitos casos é fundamentalmente diferente do que geralmente é entendido.

Um dos tópicos favoritos e discutidos periodicamente no grande canal de TI do Telegram Embedded Group é “por que ninguém entende os desenvolvedores incorporados e paga tão pouco? (no contexto de programadores "comuns") ":) Um

sistema incorporado é um sistema que funcionará sendo incorporado diretamente no dispositivo que controla. Algumas fotos para maior clareza:



A imagem da esquerda foi tirada de um artigo da Wikipedia sobre sistemas embarcados, é um exemplo de um grande sistema complexo. À direita, há uma foto da revisão da casa inteligente de Redmond, tudo aqui é muito mais simples e compacto; na verdade, todo o dispositivo é feito em um chip com o mínimo de encadernação. É importante que ambos os dispositivos funcionem como dispositivos completos (um computador de placa única ainda precisa de um gabinete e de alguns periféricos).

Como regra, uma empresa fabricante produz dispositivos acabados, que incluem principalmente hardware, e software, como regra, é fornecido em pacote e funciona apenas nesse hardware. Quase ninguém teria a idéia de comprar um smartphone “vazio” sem software e, em seguida, instalar no SO e nos aplicativos necessários, tudo deve funcionar imediatamente. Como resultado, os desenvolvedores geralmente executam todo o espectro de tarefas para o desenvolvimento de dispositivos, tanto de software quanto de hardware.

Outra característica do desenvolvimento de sistemas embarcados é que eles quase sempre têm muito menos recursos, tanto em potência e memória de computação, canal de dados quanto em consumo. A maioria das tecnologias familiares a muitos é impossível de executar em tais sistemas, mesmo o sistema operacional não está em todo lugar. É necessário ajustar-se aos recursos disponíveis e, muitas vezes, economizar significativamente. Isso também afeta a segurança - muitos padrões do Big World não são suportados ou são suportados com restrições.

C ainda é a linguagem mais usada para o desenvolvimento de sistemas embarcados. Ele possui várias falhas no trabalho com a memória que afetam diretamente a segurança. Para resolvê-los, o Rust foi desenvolvido , está ganhando popularidade (em primeiro lugar, nos seus idiomas favoritosno StackOverflow por vários anos, ultrapassando até Python e Kotlin, especialmente populares recentemente), mas ainda longe do líder em aplicabilidade no incorporado por causa dos sistemas e bibliotecas suportados. Linguagens de nível superior são raras para sistemas embarcados e provavelmente permanecerão tão cedo.

Uma característica importante do desenvolvimento de sistemas embarcados é a limitação dos recursos de hardware da plataforma e do SDK fornecidos pelo fabricante. É simplesmente impossível ou extremamente caro implementar muitas tecnologias por conta própria do zero para um único projeto. Portanto, é imperativo que o fabricante do chip ofereça suporte às tecnologias de segurança de ponta. Até recentemente, muita atenção era dada a isso. Por exemplo, se o AES de hardware apareceu há muito tempo em quase todo mundo, muitas pessoas ainda não sabem como dar suporte ao TLS / DTLS. A questão é como conseguir isso. Recentemente, escrevi sobre o novo Nordic Zephyr SDK que resolve esse problema ao integrar-se a um grande projeto suportado pela Linux Foundation. Essa é uma abordagem. Abaixo consideramos outros.

Como parte da consideração da segurança de sistemas embarcados, é necessário observar um grupo de aplicativos que se enquadram nos requisitos de padrões funcionais de segurança: medicina, automotivo, equipamentos ferroviários, automação industrial. São aplicações que afetam diretamente a vida e a saúde de uma pessoa, bem como para sistemas que não podem ser interrompidos (por exemplo, um reator nuclear). Aqui tudo é claramente regulado em todas as etapas do desenvolvimento e o potencial de falha e o efeito na operação do sistema como um todo são levados em consideração. O desenvolvimento é realizado em soluções especializadas de hardware e software, que no futuro também precisam ser certificadas. Como resultado, fica longo e caro. Portanto, aqueles que iniciam o desenvolvimento não pensam nisso se não houver padrões vinculativos.

Recomendamos uma série de artigos sobre segurança funcional para revisão .

Além da questão do desenvolvimento, é importante prestar atenção às condições operacionais dos sistemas.

Como regra, grandes empresas, fabricantes de serviços em nuvem se preocupam com a segurança de seus serviços por vários motivos:

• Eles estão envolvidos no desenvolvimento e suporte do funcionamento do serviço diretamente
• Eles têm um contato muito mais próximo entre desenvolvedores e engenheiros de suporte.
• O equipamento é diretamente acessível aos engenheiros, mesmo nas nuvens
• Amplos canais de transmissão de dados e alta capacidade computacional do equipamento permitem o uso de sistemas de monitoramento e detecção de atividade anormal

Os dispositivos da Internet das coisas funcionam exatamente da maneira oposta:

• Como regra, eles são de propriedade do cliente final, e os engenheiros do cliente final, competências que na maioria dos casos são inferiores por razões objetivas, estão envolvidas na configuração e no suporte.
• Os recursos de cada dispositivo são limitados, tanto em termos de desempenho quanto de transferência de dados. Como resultado, um sistema para monitorar e detectar atividades anormais é praticamente impossível neste caso.

Para maior clareza, darei uma tabela comparativa. Faça imediatamente uma reserva que:

• Existem muitas opções de entrega e suporte de software. Apenas grupos gerais são dados para fins ilustrativos.
• É difícil estimar com precisão o número de dispositivos da Internet, já que todos entendem algo diferente, e também não há boas estatísticas sobre eles.

	Servidores e soluções em nuvem (SaaS e similares)	Dispositivos do usuário (PCs, smartphones etc.)	Internet das Coisas
Quem está desenvolvendo?	provedor de soluções	-	-
/ ?
/?
		—
			,
	()		( )
	(Amazon, Google)	2019 : ~266 K, ~1.37	9

Como resultado, ocorrem periodicamente situações em que os dispositivos foram invadidos e nada se sabe sobre isso por razões objetivas. Infelizmente, essa situação não é incomum e pode durar meses e, às vezes, anos.

Os hacks mais famosos de sistemas embarcados nos últimos anos:

• Mirai botnet em 2016, trabalhando principalmente em filmadoras. Segundo várias estimativas, o número de dispositivos infectados excedeu 380 mil . Seu sucessor Satori em 2018 já capturou 700 mil dispositivos, concentrando-se principalmente em mineradores de criptomoeda.
• O KRACK atingiu o WPA2 Wi-Fi em 2017 (quase todos os dispositivos Wi-Fi nos últimos 15 anos) e seu herdeiro Kr00k , com mais de um bilhão de dispositivos em 2019.
• Em 2018, o Bleedingbit atingiu os chips Texas Instruments BLE. Oficialmente, apenas alguns modelos de pontos de acesso que usavam a família CC26xx foram afetados e o problema foi resolvido na nova versão da pilha. No entanto, nesse caso, não é levado em consideração que esses chips são usados ​​em um número muito maior de dispositivos (o segundo maior produtor de BLE do mundo, 16% dos 3,9 bilhões em 2018).

A maioria dos fabricantes de hardware lança patches para seus dispositivos. No entanto, essas correções ainda devem ser aplicadas nos próprios dispositivos, o que é difícil ou, em alguns casos, impossível para dispositivos da Internet das coisas. Como resultado, uma parte significativa dos dispositivos permanece potencialmente vulnerável. E eles podem nunca aprender sobre isso por causa da falta de controle e da devida atenção a esse problema.

Portanto, é necessário usar abordagens fundamentalmente diferentes para evitar vulnerabilidades e eliminar as consequências para a Internet das coisas. A segurança deve estar na própria plataforma desde o próprio estágio de seu design e ser realizada em todas as etapas de desenvolvimento e operação do dispositivo final, mas, ao mesmo tempo, ser simples e barata para a implementação em massa (pelo menos no que diz respeito à segurança funcional e à ETE de processadores poderosos).

A ARM, em 2017, falou sobre a segurança de sistemas embarcados baseados em CryptoCell e Cortex-M33, no entanto, amostras seriais de chips no M33 apareceram apenas no ano passado. A tecnologia apresentada é chamada Platform Security Architecture (PSA).


A essência da idéia era separar partes críticas do sistema (chaves, direitos, firmware) de componentes potencialmente hackáveis, tanto de hardware quanto de software, para sistemas em que a implementação completa do TEE é impossível ou difícil. A tecnologia é focada principalmente no Cortex-M, mas é compatível com todas as famílias Cortex-A / -R / -M.



Considere basicamente 4 etapas de proteção de dispositivos da Internet das coisas. Considere-os em sequência à medida que surgem durante a operação do dispositivo.

Modo de segurança

• Verifica-se que o firmware é genuíno, não foi alterado e não pode ser rebaixado.

Atualização segura de firmware através do ar (Secure FOTA)

• Somente atualizações autenticadas e verificadas podem ser baixadas.
• ( )

API

• , .
• «» API.
• —

• (MITM)

Para proteger o dispositivo, propõe-se identificar / verificar os dados que chegam a cada estágio. O conceito é baseado na idéia da raiz da confiança (Root-of-Trust, RoT). A conclusão é que um determinado identificador (chave) é costurado no dispositivo e um procedimento de hardware continua para verificar se a chave é exclusiva da plataforma atual e do código executável. No futuro, todas as bibliotecas importantes usam o RoT para seu próprio trabalho.


Normalmente, isso ocorre em três estágios principais:

1. Fornecendo Confiança: inclusão da Raiz de Confiança no estágio de produção na estrutura do
   chip.O identificador imutável de chips e a raiz de confiança do hardware fornecem segurança básica e identificação exclusiva do dispositivo.
2. :
   ,
3. :
   , 2 .

A solução mais comum no mercado é o TrustZone da ARM. Muito foi escrito sobre sua implementação no Habré, desde que a própria tecnologia foi introduzida por um longo tempo. O mais claramente na minha opinião foi resumido em uma das últimas publicações .

No contexto deste artigo, vale ressaltar que o TrustZone anterior era o privilégio de processadores de alto desempenho da família Cortex-A. E, no ano passado, quase todos os fabricantes de sistemas sem fio baseados em cristal lançaram soluções baseadas no Cortex-M ; o mais popular é o Cortex-M33 .

Falando em segurança da informação, vale lembrar o sistema de critérios gerais(Critérios Comuns), adotados internacionalmente e como padrão nacional. Ele permite determinar o nível de confiança EAL (Nível de Garantia de Avaliação) de 1 a 7 (EAL1 - EAL7); uma figura mais alta indica um nível mais alto de segurança. Para entender, a maioria dos sistemas operacionais Windows tem um nível EAL4 ou EAL4 + , o LInux / Unix, o EAL5 basicamente possui cartões inteligentes (bancos, transporte, inclusive sem contato), o EAL6 permite usar a solução em situações de alto risco, o EAL7 em situações de risco extremo, por exemplo, para redes unidirecionais (diodos de dados).

Em abril deste ano, o Cortex-M33 e o M35P foram certificados para EAL6 +. Este é um nível muito alto que permite aplicar soluções em situações de alto risco.

O ARM TrustZone Cryptocell no novo Cortex-M33 / M23 fornece armazenamento de chaves seguro (incluindo um com um identificador de hardware exclusivo), verificação de firmware, durante o download e atualização aérea, aceleração de criptografia de hardware AES, SHA, ChaCha, ECC, em inclusive com DMA (como resultado, todos os dados no Flash e na RAM podem ser criptografados), geradores de números aleatórios (TRNG, PRNG).


É interessante observar que o CryptoCell permite que você tenha várias raízes de confiança para várias tarefas (por exemplo, incorpore um RoT adicional para um cliente que deseja integrar uma solução em massa do mercado em seu sistema de TI fechado, por exemplo, um banco sem estar vinculado ao RoT principal do fabricante), bem como depuração segura (Secure Debug) com direitos de autorização.

A série 300 do CryptoCell é direcionada especificamente para dispositivos Internet of Things de baixa potência. O consumo do novo M33 é cerca de 20-40% menor que o M4, dada a perda no consumo de energia do trabalho da TrustZone de 20%, temos o mesmo ou menor nível de consumo do que agora. Como resultado, podemos dizer que a segurança do hardware chegou ao segmento de orçamento mais massivo com o Cortex-M33 / M23 e, em um futuro próximo, o número de produtos com base neles só aumentará.

As alternativas do TrustZone incluem o OpenTitan patrocinado pelo Google. No entanto, ainda não está difundido e focado em outros aplicativos além dos dispositivos finais da Internet.

Vale ressaltar que a implementação de hardware da raiz da confiança não é uma panacéia e também pode ser invadida. Um exemplo é a história recente da Intel . É importante mencionar que, neste caso, foi encontrado um erro na ROM e uma chave foi usada para todas as gerações de chipsets, portanto, pode ser reproduzida. E mesmo essa implementação complica muito o hack.

Considere os 5 estágios da evolução da implementação da Raiz de Confiança nos módulos de comunicação celular uBlox , desenvolvidos em colaboração com o Grupo Kudelski. Isso é interessante do ponto de vista da tarefa, pois suas soluções diferem significativamente das abordagens de outras empresas. Os módulos celulares Cat-M Nb-IoT / LTE pertencem às classes de transição entre a quarta e a quinta gerações de LTE e são direcionados para redes LPWAN de baixa potência. Na maioria dos casos, os dispositivos devem funcionar por anos sem intervenção humana. As soluções modernas permitem que você trabalhe de 7 a 10 anos com uma bateria (bateria). A vida média do dispositivo geralmente chega a 15 anos. Durante esse período, os requisitos de segurança podem mudar significativamente, novas ameaças aparecerão. Os dispositivos devem funcionar de forma estável sem intervenção humana por toda a vida útil. Por conseguinte, é necessário proteger esses dispositivos, levando em consideração a duração e a natureza do seu trabalho.


Como você pode ver na estrutura, a cada próxima geração, a raiz da confiança muda de posição. Este é um ponto-chave que afeta a segurança da solução como um todo.

As opções 1 e 3 são consideradas não confiáveis, de acordo com o uBlox / Kudelski, devido à implementação de software do RoT e ao hack mais provável. Inclusive no caso de criar a raiz da confiança no eSIM externo (eUICC), que fornece proteção suficiente para aplicativos bancários do EAL4 de nível de entrada (as chaves no eUICC não podem ser lidas ou alteradas para que não sejam perceptíveis do lado de fora). No entanto, essa abordagem traz falhas e possíveis vulnerabilidades decorrentes do fato de a comunicação com um componente externo poder ser interceptada e potencialmente distorcida, a complexidade da interação nos estágios iniciais da inicialização do sistema (verificação do gerenciador de inicialização), bem comomecanismo de programação complicado devido aos recursos limitados de chips no UICC. Além disso, o módulo externo pode ser substituído ou removido do sistema (simplesmente alterando o cartão SIM), deixando todo o sistema sem uma raiz de confiança.

Portanto, o caminho de desenvolvimento adicional é integrar a raiz da confiança na área protegida do chip. Essa abordagem é consistente com a composição do ARM TrustZone CryptoCell.

A versão com a implementação da Raiz de Confiança em um sistema operacional seguro é a mais comum no mercado e fornece um nível de segurança suficiente para a maioria das tarefas. A solução mais comum no mercado é o ARM TrustZone (sobre isso acima), mas sem o CryptoCell, que armazena chaves em uma área protegida.

A solução com proteção integrada dentro do chipset, à qual praticamente não há acesso externo, possui a maior proteção. A solução atual usa o elemento de segurança interno (Elemento Seguro), certificado de acordo com o nível EAL5 + . Isso permite a certificação de critérios comuns para todo o dispositivo como um todo e também permite que você coloque funções do cartão SIM e perfis de operadora de rede móvel (MNO) no dispositivo. Isso corresponde ao nível atual de segurança.

A próxima geração do chipset uBlox está em desenvolvimento, onde o Secure Element será integrado ao silício do próprio chipset do modem. Isso reduz ainda mais a superfície de ataque e melhora a segurança ao nível mais alto. Será implementado através do iUICC(Placa de circuito integrado universal integrado) - a próxima geração de UICC, na qual todo o código e o identificador SIM estarão localizados dentro do sistema em um chip, o padrão ainda não foi concluído.

Constatações:

• Cada vez mais fabricantes de componentes eletrônicos desenvolvem e produzem dispositivos com segurança em mente, a partir dos estágios iniciais de desenvolvimento.
• As empresas de terminais obtêm ferramentas de gerenciamento de segurança prontas para uso. Atrair especialistas no estágio de desenvolvimento de ferramentas permite evitar erros e reduzir significativamente o custo da solução como um todo.
• O preço das novas soluções costuma estar próximo das soluções atuais, mas oferece um nível de proteção fundamentalmente diferente, o que também simplifica bastante a transição
• O crescente número de dispositivos que fornecem um novo nível de segurança é apenas uma questão de tempo.
• Em novas soluções de elementos seguros, o UICC é transferido para dentro do chip para aumentar a segurança e impedir ataques
• As soluções modernas fornecem níveis de segurança até EAL6 + suficientes para uso em situações de alto risco.
• As soluções do nível EAL7 estão em desenvolvimento; no entanto, elas usam tecnologias sem um padrão finalmente aprovado; portanto, o prazo para sua disponibilidade no mercado não é definido.