Manufaturação industrial
Internet das coisas industrial | Materiais industriais | Manutenção e reparo de equipamentos | Programação industrial |
home  MfgRobots >> Manufaturação industrial >  >> Industrial Internet of Things >> Computação em Nuvem

Como aproveitar os recursos de segurança do Arm TrustZone do LPC5500

Saiba como a extensão Arm TrustZone para a série LPC5500 funciona e como começar a utilizar as medidas de segurança em aplicativos personalizados seguros e não seguros.


Com dispositivos cada vez mais conectados e a sofisticação cada vez maior de hackers, muitas empresas - como a NXP Semiconductors - reconheceram a necessidade de contramedidas. A NXP desenvolveu a série LPC5500 MCU, que vem com recursos de segurança aprimorados que podem ser usados ​​para proteger projetos incorporados.

A NXP adotou um gerador de número aleatório compatível com FIPS, selecionou o algoritmo de descriptografia “Prince” (permitindo que o núcleo execute código criptografado simétrico) e implementou uma chave no chip efêmera de 4096 bits com tecnologia PUF. Quando combinados com o acelerador de hardware criptográfico on-chip ‘CASPER’, os MCUs LPC5500 são adequados para aplicativos IoT de ponta da rede que requerem contramedidas de segurança cibernética robustas e provisionamento de chave de ciclo de vida completo.

Além disso, o chip alavanca a tecnologia Arm TrustZone para dispositivos baseados em Cortex-M. Neste artigo, aprenda como a extensão TrustZone da série LPC5500 funciona e como começar a utilizar as medidas de segurança em aplicativos personalizados.


O que é a tecnologia Arm TrustZone para Cortex-M?


O princípio básico do TrustZone é melhor explicado por meio de um exemplo. O fabricante do MCU geralmente fornece código proprietário personalizado, como bibliotecas de segurança, um bootloader ou algoritmos DSP rápidos na ROM do microcontrolador. No entanto, os autores desses aplicativos geralmente têm bons motivos para proteger sua propriedade intelectual - eles podem não querer que os usuários ou concorrentes descompilem os binários para fazer a engenharia reversa dos algoritmos.

Por um lado, os programadores desejam utilizar essas bibliotecas de software predefinidas. Por outro lado, no entanto, o fabricante não deseja que o código seja exposto a uma parte possivelmente mal-intencionada.




Figura 1. O código de usuário não seguro e o conteúdo de ROM seguro residem no mesmo MCU físico.



O fornecedor deseja ocultar os detalhes da implementação, ao mesmo tempo que garante que os desenvolvedores possam acessar as funções. O código do usuário é capaz de chamar os métodos expostos do software oculto, mas não tem acesso direto à memória de propriedade da ROM segura. O resultado é uma estrutura que consiste em dois subsistemas isolados. As transições entre esses dois mundos são governadas pela extensão de segurança TrustZone.

Isso significa que um microcontrolador que utiliza TrustZone será arquitetado como dois projetos separados. O primeiro projeto começa no estado Seguro. Em seguida, ele configura as atribuições de segurança para recursos no chip e pode publicar funções seguras em uma tabela acessível a partir do estado não seguro. O segundo contém o código não seguro e tem acesso limitado às funções expostas do mundo seguro.


Diferenças das arquiteturas anteriores


Os núcleos Cortex-M3 e -M4 conhecem dois modos de processador:modo thread e modo manipulador. O software aplicativo é executado no modo thread e o modo manipulador lida com exceções. O código pode operar em um nível privilegiado ou não privilegiado, que controla o acesso a certos recursos da CPU.

Com a extensão TrustZone em núcleos Cortex-M33, dois novos estados foram introduzidos, conforme discutido acima. Essa mudança resultou em quatro modos de processador diferentes:gerenciador não seguro, modo de gerenciador seguro, thread não seguro e thread seguro.



Figura 2. A extensão TrustZone no núcleo M33 cria quatro modos de processador.



Além de outras atualizações, novos temporizadores SysTick também foram introduzidos com os novos estados. Portanto, agora existem temporizadores separados para o estado seguro e o estado não seguro.


Partição de Memória


Como mencionado anteriormente, a memória do MCU é particionada em áreas seguras e não seguras. O núcleo da CPU do MCU só pode acessar regiões seguras de memória se operar em um dos modos seguros. Ele não pode acessar nenhuma instrução que resida em outras partições de memória. No entanto, ele pode ler e gravar segmentos seguros e não seguros da RAM de dados. Se o núcleo da CPU estiver em um estado não seguro, ele poderá acessar apenas a instrução não segura e os blocos de memória de dados.

TrustZone decora intervalos de endereço no mapa de memória com atribuições de segurança. Existem três atribuições de segurança:seguro (S), não seguro (NS) e não seguro com chamada (NSC). O acesso a cada área de memória é permitido ou negado, dependendo do estado de segurança atual do núcleo.




Figura 3. A CPU pode acessar diferentes áreas no modo seguro e não seguro.



No dispositivo LPC55S69, a memória foi dividida em segmentos seguros e não seguros com base no endereço. Se o bit 28 do endereço de memória for BAIXO, a memória não é segura. Caso contrário, é seguro. A única exceção é a memória do programa, que pode ser configurada por meio da Unidade de Atribuição de Segurança.


Os blocos de construção de um aplicativo seguro


O código não seguro não pode fazer chamadas diretas para a parte segura do aplicativo. Em vez disso, a parte protegida expõe uma lista de funções que um usuário pode acessar. Essa lista é chamada de mesa de verniz porque é uma camada muito fina que é visível do lado de fora, mas esconde os detalhes internos. A tabela de verniz está localizada em uma região de memória com o atributo TrustZone NonSecure Callable.

Normalmente, a origem da parte protegida não é visível. Em vez disso, ele é compilado, fornecendo uma biblioteca de objetos e a tabela de verniz como um arquivo de cabeçalho. Observe que nenhum desses arquivos contém qualquer uma das instruções reais, mas juntos contêm as informações necessárias para chamar funções seguras. A tabela de verniz contém apenas um gateway e uma instrução de ramificação para o local de memória seguro onde residem as instruções reais.


Transição entre funções seguras e não seguras


CPUs com a extensão TrustZone suportam duas novas funções para a transição entre seguro e não seguro:a instrução SG e BXNS.

Quando o código do usuário deseja uma função segura, ele faz uma chamada por meio da tabela de verniz, que está localizada na parte NSC da memória. A instrução SG é então utilizada para mudar a CPU para um modo seguro. Quando a execução é concluída, o controle é retornado ao código do usuário com a instrução BXNS:




Figura 4. O código do usuário deve chamar uma função segura por meio do gatekeeper TrustZone.



Se o usuário tentar uma operação ilegal relacionada à segurança, como acessar diretamente uma área protegida, uma exceção Secure Fault é gerada.


Um exemplo de Hello World seguro


O SDK para o LPCXpresso55S69 vem com alguns exemplos TrustZone que podem ser carregados no MCUXpresso. Conforme mencionado anteriormente, esses exemplos consistem em dois projetos separados:a parte segura e o código de usuário não seguro.

A parte segura se parece quase exatamente com qualquer outro projeto MCUXpresso. No entanto, há uma diferença, que é a seguinte chamada de função:







Esta função deve ser chamada o mais cedo possível. Depois disso, é responsabilidade do projeto seguro configurar a memória e o projeto não seguro:







Como o projeto seguro lida com todas as chamadas de configuração, o projeto não seguro não precisa, portanto, sua função principal é curta:







No entanto, este aplicativo apenas chama funções seguras que foram definidas no outro projeto. A seguinte definição para a função PRINTF_NSE é a seguinte:







Se essa definição for seguida, ela aponta para a tabela de verniz, definida no projeto garantido. É importante lembrar que o projeto não seguro conhece apenas o arquivo de cabeçalho que descreve a tabela de verniz. No entanto, neste caso, podemos dar uma olhada na função correspondente no código-fonte:







A decoração “__attribute __ ((cmse_nonsecure_entry))” força a função a ser exportada para o arquivo objeto.


Particionando a memória


Os atributos de segurança definem quais partes da memória são protegidas, NSC ou não protegidas. Eles são verificados a cada acesso. Para isso, o MCU foi estendido com hardware que lida com essas verificações e consiste em três blocos lógicos:
  1. Unidade de atribuição de segurança (SAU)
  2. Unidade de atribuição definida de implementação (IDAU)
  3. Lógica de atribuição de segurança

O SAU é programado pelo projeto seguro dentro da função BOARD_InitTrustZone (). Isso permite que a memória seja particionada em oito regiões com diferentes configurações de segurança. Observe que qualquer região não definida explicitamente permanece segura por padrão.

O IDAU permite que o fabricante do MCU - NXP neste caso - defina mais regiões personalizadas. Aqui, as regiões dependem do 28º bit do endereço. No MCU LPC55S69, a parte inferior do mapa de memória (0x0000_0000 a 0x2FFF_FFFF) é padronizada como não segura, portanto, é livre para configurar com a SAU.

O árbitro garante que as configurações IDAU e SAU coincidam. Para que uma região de memória seja marcada como não segura, ambos os blocos lógicos devem ser definidos como não segura. Caso contrário, a memória voltará ao estado de segurança padrão. O mesmo se aplica às regiões de memória NSC. Para que uma seção seja NSC, o SAU deve ser marcado como NSC e o IDAU deve ser definido como não seguro.

Existe uma ferramenta dentro do MCUXpresso que permite ao usuário definir regiões de memória de forma rápida e fácil. Para acessar a ferramenta, use a barra de menu principal do IDE e abra a perspectiva TEE:




Figura 5. Esta ferramenta MCUXpresso permite ao usuário visualizar e editar o mapa de memória do MCU.



A tabela do lado esquerdo da ferramenta pode alterar o nível de segurança das regiões de memória. O mapa de memória do lado direito ilustra como a memória é particionada.


TrustZone oferece um componente de segurança necessário


Na série LPC5500 MCU com tecnologia TrustZone, a memória é dividida em um mundo seguro e não seguro - é possível permitir que os usuários acessem partes da memória não segura, e um aplicativo seguro também pode ser escrito para ser utilizado por outras. O TrustZone atua como um porteiro entre os dois mundos e gerencia como o núcleo faz a transição entre eles.

Duas novas instruções foram introduzidas para esse fim. O aplicativo seguro fornece uma tabela de verniz que expõe as funções que podem ser chamadas a partir do contexto não seguro. O hardware no MCU garante que nenhuma operação ilegal de acesso à memória seja realizada. Este hardware também pode ser utilizado para configurar as regiões no mapa de memória. Para isso, o MCUXpresso oferece a perspectiva TEE. Uma compreensão mais profunda da segurança fornecida para a série LPC5500 de MCUs permite uma melhor experiência de design. Mais informações sobre TrustZone podem ser encontradas assistindo TrustZone:Calling the Secure World.

Artigos do setor são uma forma de conteúdo que permite aos parceiros do setor compartilhar notícias, mensagens e tecnologia úteis com os leitores do All About Circuits de uma forma que o conteúdo editorial não é adequado. Todos os artigos da indústria estão sujeitos a diretrizes editoriais rígidas com a intenção de oferecer aos leitores notícias úteis, conhecimentos técnicos ou histórias. Os pontos de vista e opiniões expressos nos Artigos da Indústria são do parceiro e não necessariamente da All About Circuits ou de seus redatores.

Computação em Nuvem

  1. Nuvem e como ela está mudando o mundo da TI
  2. A segurança na nuvem é o futuro da cibersegurança
  3. Como se tornar um engenheiro de segurança em nuvem
  4. Por que o futuro da segurança de dados na nuvem é programável
  5. Como proteger a tecnologia em nuvem?
  6. Como gerenciar riscos de segurança na nuvem
  7. Como os hackers invadem a nuvem; Adicione mais segurança à sua nuvem com AWS
  8. Como passar no exame de engenheiro do Google Cloud?
  9. Como implantar DevOps na nuvem
  10. Como migrar ERP para a nuvem