1. O dispositivo IoT gera um CSR que o serviço de provisionamento deve autorizar primeiro.

Provisionamento em tempo de execução de credenciais de segurança para dispositivos IoT

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br


Faça o download deste artigo em formato PDF.

Para impedir que dispositivos falsificados ingressem em uma rede ou limitar a oportunidade de ataques à rede, é importante autenticar dispositivos tentando ingressar em redes da Internet das Coisas (IoT) e, posteriormente, conectar apenas dispositivos autorizados. O mecanismo padrão para autenticar com segurança os clientes que se conectam a um servidor é a autenticação no lado do cliente de segurança da camada de transporte (TLS).

Para implementar essa autenticação em uma rede IoT, a autoridade de certificação apropriada (geralmente o provedor de dispositivos IoT) emite um certificado X.509 exclusivo para cada dispositivo IoT e a chave privada associada que funciona como uma credencial de segurança exclusiva para o dispositivo IoT . Depois que o certificado e a chave privada associada forem armazenados no dispositivo IoT, ele poderá ser usado durante o processo de autenticação do cliente TLS para ingressar com segurança na rede IoT.

O ato de fornecer as credenciais necessárias para um dispositivo que ingressa em uma rede é conhecido como “provisionamento”. É importante ter um processo de provisionamento transparente ao usuário para minimizar os desafios de integração ou os lapsos de segurança. Portanto, o provisionamento com zero toque, que elimina a necessidade de qualquer interação do usuário, é altamente desejado nos aplicativos de IoT.

Uma abordagem comum, porém desafiadora de aprovisionamento de certificados, é adicionar fisicamente credenciais emitidas pela CA aos dispositivos durante a fabricação. Como é essencial impedir que partes não autorizadas aprendam os valores das chaves privadas, os processos de fabricação que envolvem o gerenciamento de chaves privadas devem ser altamente seguros e totalmente confiáveis. Esse requisito exclui muitos – se não todos – fabricantes contratados de baixo custo. Mas a necessidade de manter muitas classes de dispositivos de IoT baixos exige abordagens que envolvam o uso desses tipos de fabricantes.

Um processo de provisionamento que ganhou força é pré-preencher “elementos seguros” com certificados em um local seguro e depois enviá-los a um fabricante de baixo custo, que monta o dispositivo IoT completo. Elementos seguros são chips que fornecem criptoaceleradores baseados em hardware e armazenamento seguro de chaves, às vezes aumentados com proteções adicionais contra adulteração de hardware e ataques de canal lateral. Várias empresas, como distribuidores de semicondutores, agora oferecem serviços específicos para programar elementos seguros com certificados em um ambiente confiável.

Embora o preenchimento prévio de elementos seguros com certificados permita o uso de fabricantes de baixo custo sem comprometer a segurança, essa abordagem obviamente aumenta o custo do produto e de fabricação. O elemento seguro é adicionado à lista de materiais (BOM) e, em seguida, o preenchimento prévio do certificado é uma etapa adicional de fabricação que requer um ambiente confiável (e de alto custo).

Neste artigo, discutirei uma implementação baseada em um microcontrolador SimpleLink Wi-Fi (MCU) da Texas Instruments e na Amazon Web Services (AWS) que provisiona certificados em tempo de execução e elimina a necessidade de preencher previamente os certificados durante a fabricação. Os MCUs Wi-Fi SimpleLink incluem recursos no chip que são equivalentes a um chip de elemento seguro externo, como armazenamento seguro de chaves e certificados, um UDID (Identity Unique Device Identity) pré-gravado, um par de chaves público / privado pré-gravado, e aceleração criptográfica. Como resultado, esta implementação não requer um elemento seguro. No entanto, também é fácil duplicar a abordagem descrita neste artigo usando um MCU combinado com um elemento seguro discreto.

A AWS fornece uma ampla variedade de serviços de computação genéricos e ofertas específicas de software como serviço (SaaS), como bancos de dados e análises. Discutirei o uso de alguns serviços da AWS, incluindo API Gateway, Lambda e Amazon Certificate Manager, para criar um serviço de provisionamento de toque zero para dispositivos IoT que se conectam à AWS IoT Testemunho.

Provisionamento de certificados em tempo de execução

Leia Também  Selecione a memória flash correta para o seu alto-falante AI alimentado por bateria com controle de voz

Qualquer dispositivo (ou servidor) conectado à Internet pode usar uma solicitação de assinatura de certificado (CSR) como uma solicitação a uma autoridade de certificação (CA) para um certificado X.509. O dispositivo pode apresentar esse certificado quando a autenticação do cliente for necessária. O CSR fornece um mecanismo para um dispositivo IoT obter um certificado em tempo de execução, normalmente durante a instalação nas instalações do usuário, o que elimina a necessidade de preencher previamente os certificados durante a fabricação. Como o dispositivo IoT seria programado para emitir o CSR na primeira conexão, essa abordagem pode fornecer provisionamento sem toque e, portanto, fica invisível para os usuários finais.

Para gerar um CSR, o dispositivo IoT preenche os campos apropriados para criar um certificado X.509, como o nome da empresa ou organização e sua localização. O CSR deve conter uma chave pública e uma assinatura digital criada criptografando um hash do CSR com a chave privada associada.

Embora os pares de chaves usados ​​na maioria dos CSRs sejam normalmente gerados para uso em uma implementação de provisionamento seguro para dispositivos de IoT, é mais preferível que o fabricante original do equipamento (OEM) incorpore o par de chaves no dispositivo antes de enviar para um cliente, usando um MCU com chaves pré-queimadas ou adicionando um elemento seguro. Como não é necessário pré-programar o elemento seguro com o certificado, o processo de fabricação não exige mais esta etapa.

O motivo pelo qual o dispositivo IoT não pode gerar o par de chaves é impedir que dispositivos não autorizados obtenham um certificado que permita que eles ingressem na rede IoT. Isoladamente, uma CA atenderá a qualquer solicitação de CSR que use um par de chaves pública / privada válido. Para evitar isso, um processo de provisionamento deve rastrear todas as solicitações de CSR para garantir que elas venham de um dispositivo autorizado a ingressar na rede. Por exemplo, o processo de provisionamento pode implicar a verificação da chave pública no CSR em relação a uma lista de chaves públicas contidas nos dispositivos IoT enviados pelo OEM, o que efetivamente implementa um mecanismo de lista de permissões.

Uma abordagem semelhante pode usar um UDID para autorizar a conclusão do CSR. O UDID pode ser pré-gravado no dispositivo ou inserido usando um aplicativo móvel que digitaliza uma barra ou código QR. O uso de uma combinação de UDID e chave pública aprimora a segurança, pois um invasor precisaria obter dois valores em vez de um valor para comprometer o sistema.

Implementando um mecanismo de provisionamento baseado em CSR para dispositivos IoT

O AWS IoT Core é um serviço de IoT baseado em nuvem que usa a comunicação MQTT (Message Queue Telemetry Transport) em um soquete TLS seguro para fornecer serviços como gerenciamento de dispositivos, telemetria e atualizações remotas. Para executar a autenticação do cliente, o TLS exige que o dispositivo IoT possua um certificado. Como um dispositivo Wi-Fi SimpleLink inclui um par de chaves pré-gravado e um UDID pré-gravado, além da capacidade de gerar um CSR, a TI e a AWS usaram esses recursos para implementar uma solução de provisionamento em tempo de execução. Essa solução permite que um dispositivo IoT baseado em Wi-Fi do SimpleLink obtenha um certificado antes de conectar-se ao AWS IoT Core principal.

Vamos revisar essa implementação com mais detalhes, começando pelo lado incorporado. Um dispositivo Wi-Fi SimpleLink inclui um processador de rede separado com código de memória somente leitura (ROM) que implementa redes sem fio, armazenamento seguro e operações criptográficas. As funções de rede sem fio da ROM incluem geração de CSR.

figura 1 ilustra as etapas no dispositivo IoT. Na primeira vez em que o dispositivo é inicializado, ele verifica se possui ou não o certificado do cliente. Caso contrário, iniciará o processo de provisionamento. O primeiro passo é gerar o CSR. Além de preencher as informações de localização, nome da organização e algoritmo de assinatura, o dispositivo IoT inclui a chave pública pré-queimada no CSR, insere o UDID no campo de nome do certificado e, em seguida, cria um hash do certificado e criptografa-o usando sua chave privada para criar a assinatura digital para assinar o CSR.

1. O dispositivo IoT gera um CSR que o serviço de provisionamento deve autorizar primeiro. 1. O dispositivo IoT gera um CSR que o serviço de provisionamento deve autorizar primeiro.

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br

Em seguida, o dispositivo IoT se conectará ao serviço de provisionamento por meio de uma conexão TLS, que exigirá apenas autenticação do servidor. O fabricante do dispositivo precisará incluir o URL do servidor de provisionamento, juntamente com a raiz confiável necessária para validar a cadeia de certificados do servidor, na imagem padrão programada em cada dispositivo IoT. Depois de conectado ao serviço de provisionamento, o dispositivo IoT envia a solicitação de CSR. Se o serviço de aprovisionamento autorizar a associação do dispositivo IoT, ele enviará o certificado de cliente para o dispositivo. O dispositivo IoT deve então armazenar o certificado com segurança para impedir o acesso não autorizado.

Um dispositivo Wi-Fi SimpleLink possui um sistema de arquivos seguro que permite o armazenamento de código e dados em flash criptografado. As MCUs sem uma capacidade semelhante podem usar um elemento seguro discreto. Nesse momento, o dispositivo IoT pode se conectar ao AWS IoT Core e apresentar o certificado durante a etapa de autenticação do cliente.

No lado da nuvem, os principais serviços da AWS usados (Figura 2) são Amazon API Gateway, AWS Lambda e CA privada do Amazon Certificate Manager (ACM). A implementação de provisionamento também deve registrar certificados emitidos para um dispositivo IoT no AWS IoT Core. O administrador da infra-estrutura de chave pública (PKI) responsável pela CA que emite os certificados do dispositivo também deve registrar o certificado da CA – geralmente um certificado raiz imediato – no AWS IoT Core. Para aprimorar a segurança, o AWS IoT Core conecta apenas dispositivos com certificados emitidos por uma CA registrada.

2. O serviço de provisionamento primeiro autoriza o CSR antes de cumpri-lo e registra o certificado e o item no AWS IoT Core.2. O serviço de provisionamento primeiro autoriza o CSR antes de cumpri-lo e registra o certificado e o item no AWS IoT Core.

O Amazon API Gateway fornece uma interface REST (Representational State Transfer) (como o Hypertext Transfer Protocol) para que o dispositivo IoT se conecte inicialmente e inicie o processo de provisionamento. O AWS Lambda executa as duas funções principais do serviço de provisionamento: autorização e emissão de certificados. A implementação usa o AWS Lambda porque as funções são executadas apenas em resposta a um dispositivo de IoT que entra em contato com o serviço de provisionamento. Como resultado, manter um servidor permanente seria caro. O AWS Lambda fornece um modelo de execução orientado a eventos, sem servidor, que atende melhor aos requisitos de aplicativos e minimiza os custos de computação em nuvem.

A primeira função que é executada após o dispositivo IoT entrar em contato com o Amazon API Gateway é a função de autorização. A função de autorização extrai o UDID e a chave pública do certificado e compara ambos os valores em um banco de dados pré-preenchido – mostrado como a tabela de chave pública em Figura 2.

Embora seja possível implementar a tabela de chave pública em vários formatos, a implementação de exemplo usa o serviço AWS DynamoDB, que é um banco de dados relacional. O AWS DynamoDB usa o UDID como um índice para recuperar uma chave pública do banco de dados e compara essa chave com a do certificado. Se corresponderem, a função autoriza a operação CSR a continuar

Uma segunda função do AWS Lambda cumpre o CSR e emite o certificado obtido da CA privada ACM, que fornece um link para importar certificados da CA do provedor de dispositivos IoT e encaminha o certificado para o próprio dispositivo por meio da interface do Amazon API Gateway. A função do emissor também registra o certificado no AWS IoT Core e cria a coisa para representar o dispositivo, juntamente com a política apropriada.

Esse fluxo aborda a entrega do certificado para dispositivos IoT quando eles estão prontos para o cliente. Um fluxo alternativo usa o AWS IoT Core para emitir os certificados. Esse fluxo é destinado principalmente ao desenvolvimento, pois elimina a necessidade de integrar imediatamente a CA privada do ACM à CA do provedor de dispositivos IoT. Os certificados emitidos pelo AWS IoT Core são válidos apenas para a região específica da AWS que os emite e, portanto, não são adequados se a intenção for implantar um produto em todo o mundo.

Criando a tabela de chave pública

Leia Também  Arduino Blog »Juntos, vamos fazer a história do COVID-19 - ANÚNCIO DA CONFERÊNCIA

Uma etapa fora de banda adicional necessária para implementar o fluxo de provisionamento está preenchendo o banco de dados usado para autorizar solicitações de CSR. Esta etapa requer a obtenção dos valores UDID e de chave pública do MCU ou do elemento seguro usado em cada dispositivo IoT. Em alguns casos, esses valores estarão disponíveis nas listas de permissões fornecidas pelo fornecedor de semicondutores.

No entanto, essas listas de permissões geralmente estão vinculadas a compras de quantidade mínima (geralmente em torno de 2.000 unidades) relacionadas ao tamanho dos cilindros no processo de fabricação de semicondutores. Como resultado, durante o desenvolvimento e o teste inicial de um dispositivo de IoT, é necessário extrair essas informações de forma programática, pois qualquer compra por volume de MCUs ou elementos seguros geralmente ocorre posteriormente durante as rampas de produção.

Para o MCU SimpleLink Wi-FI, a Texas Instruments projetou o fluxo mostrado em Figura 3 para que os desenvolvedores possam extrair o UDID e a chave pública para upload subsequente na nuvem. Um desenvolvedor conecta o dispositivo IoT à ferramenta Uniflash da TI por meio de uma conexão UART (Universal Asynchronous Receiver Transmitter Transmitter). Nesse modo, um dispositivo baseado em Wi-Fi SimpleLink é inicializado e fornece um gancho no processo de inicialização para o Uniflash fazer o download de uma função. O desenvolvedor faz o download de uma função pré-fornecida que lê o UDID e a chave pública.

3. O TI Uniflash pode baixar uma função temporária no momento da inicialização para extrair o UDID e a chave pública para preencher a tabela de chaves públicas.3. O TI Uniflash pode baixar uma função temporária no momento da inicialização para extrair o UDID e a chave pública para preencher a tabela de chaves públicas.

Esse método permite que o provedor de dispositivos IoT preencha o banco de dados a qualquer momento do processo de desenvolvimento e produção, independentemente das compras de volume de semicondutores. Um aspecto importante dessa abordagem é o download temporário da função de extração, que elimina a necessidade de incorporar a função na imagem principal do MCU e adicionar a lógica associada para ativá-la apenas em circunstâncias específicas.

Conclusão

Leia Também  Resgatando a Feira de Ciências da COVID-19

A autenticação do lado do cliente é importante para os provedores de dispositivos IoT para impedir que os clones de dispositivos IoT ingressem na rede e para fortalecer a segurança. A adição de credenciais de segurança durante a fabricação aumenta os custos, pois requer um ambiente de fabricação seguro ou a compra de elementos seguros com credenciais pré-preenchidas. Uma abordagem alternativa é fazer o download da credencial quando o dispositivo se conectar à rede.

Este artigo apresentou uma visão geral técnica de uma implementação de provisionamento em tempo de execução com base no TI SimpleLink Wi-Fi e no AWS IoT Core que usa o CSR para obter as credenciais de segurança, combinado com um serviço de autorização adicional que verifica uma combinação de UDID / chave pública para bloquear os CSRs de dispositivos não autorizados.

Para obter mais detalhes dessa implementação de provisionamento em tempo de execução, consulte https://github.com/aws-samples/iot-provisioning-secretfree para o código e a documentação do lado da nuvem da AWS (incluindo o código para criar a tabela de chave pública no AWS DynamoDB) e dev.ti.com/CC32XX_AWS_PKT_provisioning para o código e a documentação do lado incorporado do SimpleLink SDK.

Reconhecimentos

Gostaria de agradecer a Richard Elberger, engenheiro de aplicativos sênior da AWS, e Kobi Leibovitch, engenheiro de aplicativos SimpleLink da Texas Instruments, por compartilharem seus conhecimentos sobre a implementação de software de provisionamento.

Nick Lethaby é gerente de ecossistemas de IoT da Texas Instruments.

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br