Facilitando o provisionamento de IoT em escala

Esteja você procurando projetar um novo dispositivo ou adaptar um dispositivo existente para a IoT, você precisará considerar o provisionamento de IoT, que traz dispositivos IoT online para serviços em nuvem. O design de provisionamento de IoT exige que sejam tomadas decisões que afetem a experiência do usuário e a segurança tanto para o comissionamento da rede quanto para os mecanismos de provisionamento de credenciais que configuram identidades digitais, pontos de extremidade de nuvem e credenciais de rede para que os dispositivos possam se conectar com segurança à nuvem.

Para realizar o provisionamento de IoT em escala, os clientes geralmente criam e mantêm ferramentas personalizadas e aplicativos de software que podem enviar as credenciais necessárias sobre os protocolos suportados por seus dispositivos que abrangem vários domínios de problemas. Os domínios de provisionamento IoT incluem:

• Comissionamento de rede, que fornece mecanismos para os clientes definirem parâmetros específicos de contexto;
• Provisionamento de credenciais, que atribui credenciais e configuração a dispositivos físicos; e
• Provisionamento em nuvem, que define os dados de configuração do lado da nuvem que permitem autenticação, autorização e gerenciamento de dispositivos.

Todos esses três domínios de provisionamento devem funcionar em harmonia para uma experiência espetacular do usuário do cliente.

Por exemplo, uma operadora móvel fornece dados de configuração e definições de política quando um usuário de telefone móvel se conecta pela primeira vez. Este é um processo simples e bem compreendido que não leva muito tempo para o usuário do dispositivo móvel, onde o cartão SIM representa a identidade do dispositivo. A situação se torna muito diferente e desafiadora para os clientes, especialmente fabricantes de equipamentos originais (OEMs), que tentam provisionar milhões de dispositivos IoT.

Ao longo deste artigo, você será capaz de aprender como evitar ou mitigar os riscos associados à sua própria implantação de IoT, bem como compreender, por meio de breves exemplos, como um serviço de IoT fornecido por meio de plataformas de nuvem como Amazon Web Services (AWS) ajuda você a alcançar seus objetivos de provisionamento de IoT.

Abordagens para comissionamento de rede quando necessário

Eventualmente, seu dispositivo IoT se conecta e se comunica com um serviço central que é o hub de sua solução IoT. Para alcançar esse hub, seu dispositivo IoT deve se conectar a um meio de rede. O meio pode ser um fio rígido, como Ethernet, ou transmissão de rádio, como Wi-Fi. Dependendo do meio, você precisa de um humano para dizer ao dispositivo a qual meio ele deve se juntar para ter sucesso em alcançar o hub. Por exemplo, com o celular, você não precisa informar ao dispositivo a rede para se conectar, pois isso foi definido pelo cartão SIM. Por outro lado, para ingressar em uma rede Wi-Fi, você precisará saber o nome e a senha do Ponto de Acesso Wi-Fi e ser capaz de informar esses detalhes ao dispositivo. Vamos nos concentrar nos dispositivos que requerem configuração para ingressar em uma rede.

Existem vários mecanismos diferentes que os clientes têm usado para ingressar em redes IoT. Quase todo mundo tem um smartphone hoje e quase todo smartphone tem Bluetooth, então a configuração via Bluetooth se tornou difusa. No entanto, esse não é o único meio de se conectar. Alguns módulos Wi-Fi em dispositivos IoT são inteligentes o suficiente para se tornarem pontos de acesso por conta própria, onde você pode desenvolver uma página da web simples que permite aos usuários inserir a configuração da rede maior. Para dispositivos que não são de consumo, ainda é comum configurar por serial ou microSD. A configuração do Bluetooth com a ajuda de um aplicativo de smartphone tornou-se a norma. Esses aplicativos de smartphone também podem ajudar no provisionamento em nuvem do dispositivo, o que você descobrirá mais adiante neste artigo.

Abordagens para provisionamento de credencial de dispositivo em escala

Os processos de provisionamento de credenciais de dispositivos continuam altamente fragmentados em todo o setor, sem linha de visão para convergência tão cedo. A maioria dos sistemas centralizados de IoT sugere fortemente, ou exige, uma conexão Transport Layer Security (TLS) 1.2 para transporte criptografado, que é mais recentemente, e talvez eloquentemente, conhecido como criptografia em trânsito. Hoje, a maioria das implantações de IoT usa infraestrutura de chave pública (PKI), portanto, o restante deste artigo pressupõe o uso de PKI. Em qualquer caso, é imperativo que cada dispositivo possua sua própria chave privada e certificado de identificação exclusivo.

Para criar uma sessão com uma nuvem (ou ponto de extremidade de serviço), o TLS 1.2 requer uma chave privada e um certificado x.509 (ou credencial). Observação:algumas técnicas, como Java Web Tokens ou JWT, apresentam desafios semelhantes, mas não serão discutidas aqui. A chave privada, que é como o seu DNA, deve ser conhecida apenas por um dispositivo individual, o que significa que não deve ser compartilhada com outros dispositivos. O certificado x.509, que é como uma carteira de motorista, é emitido por uma Autoridade de Certificação (CA) verificável, fornecendo uma Solicitação de Assinatura de Certificado (CSR). Entregar um CSR não é muito diferente de entregar à entidade emissora do passaporte do seu país sua certidão de nascimento com uma impressão digital e prova de outros testes aprovados como prova para receber um passaporte. Ao longo deste artigo, nos referimos ao certificado x.509 como uma credencial, supondo que o dispositivo tenha uma chave privada exclusiva.

Os detalhes do TLS 1.2 estão além do escopo deste artigo, mas forneceremos apenas informações suficientes para que você fique um pouco informado para que possa entender por que é imperativo que o dispositivo proteja a chave privada. Durante o processo de conexão TLS 1.2, uma série de trocas ocorre para provar que o dispositivo é o proprietário da Chave Privada que é sua identidade. Seu dispositivo deve provar que é o verdadeiro proprietário do certificado x.509 que está tentando usar para autenticação. Para que o serviço IoT confie em uma credencial de dispositivo quando seu dispositivo se conectar, você precisa ter essa chave privada em mãos. Agora você pode perceber que, se um mau ator obtiver essa chave, o modelo de segurança desmorona. A todo custo, proteja as chaves do seu castelo IoT!

Como a maioria dos que estão implantando a IoT, você deve tomar decisões sobre como provisionar essas credenciais em escala. Para fazer uma revisão rápida, cada dispositivo deve ter:

• Uma chave privada única e imutável que representa o dispositivo. Idealmente, para proteger contra ataques lado a lado e outros ataques avançados, a chave privada deve ser fisicamente protegida e não carregável na memória do programa principal.
• Uma credencial, relacionada ao seu aplicativo ou serviço IoT.

A logística difere entre as opções de provisionamento de chave privada e credencial, alguns que são separados do provisionamento em nuvem e outros que dependem do provisionamento em nuvem.

• Módulos de segurança de circuito integrado (que geralmente têm recursos criptográficos), autônomo ou participando de um projeto System-In-Package (SiP), System-On-Module (SoM) ou System-On-Chip (SoC), tendo um dos seguintes comportamentos:

• • Um módulo de segurança com uma chave privada provisionada manualmente ou autogerada ou raiz de confiança.
  • Além do item anterior, o módulo de segurança fornece credenciais na forma de certificados x.509 pré-provisionados.

• As tecnologias do Módulo de identidade do assinante (SIM), SIM incorporado (eSIM) e SIM integrado (iSIM) fornecem hardware que os designers usam como identidade celular para comunicação com redes celulares. O provisionamento de credenciais geralmente depende do provedor de operadora de rede móvel (MNO), provedor de rede virtual móvel (MVNO) ou de terceiros. Se você estiver usando módulos de celular para comunicação, a escolha é sua.
• Provisionamento de credencial de dispositivo automatizado e personalizado para um segmento de flash de dispositivo, que poderia ter flash seguro especial, em conjunto com um Módulo de Segurança de Hardware (HSM) durante a fabricação.
• Provisionamento manual de chaves privadas e credenciais para flash seguro seguro especial (ou flash não seguro, normalmente durante a prototipagem, mas não recomendado para provisionamento de frota).

A execução do TLS 1.2 é uma atividade de computação intensiva devido aos requisitos de criptografia, que por sua vez influencia a escolha do componente de computação, especialmente se você estiver usando um microcontrolador para seu projeto. ICs especializados geralmente incluem rotinas de criptografia, que liberam o processador do host de aplicar ciclos na operação TLS 1.2, garantindo que a chave privada não seja carregada na memória principal.

A abordagem que você adota para o hardware depende do design do seu hardware. A escolha de uma solução elegante para o design de hardware certamente simplifica o provisionamento em escala, mas requer a seleção de componentes no início do ciclo de vida do design de hardware, uma vez que influencia outras escolhas de design de componentes para computação, módulos de criptografia, coprocessamento matemático e flash. Certamente, para dispositivos em escala, você não desejará provisionar manualmente, e as tendências sugerem que os dispositivos pré-provisionados produzem o mínimo de atrito nas perspectivas de fabricação, operações e experiência do cliente.

O provisionamento de dispositivos IoT requer nuvem e orquestração de dispositivos

O provisionamento de dispositivos IoT bem-sucedido requer uma orquestração de provisionamento de dispositivos e nuvem que influencia o design de hardware e software, bem como a forma como você gerenciará os dispositivos durante todo o ciclo de vida do dispositivo.

De uma perspectiva de serviço IoT, você precisará de um processo que se alinhe com sua escolha de provisionamento de credencial para criar objetos de configuração relacionados. Quando o dispositivo se conecta a um serviço IoT, o serviço IoT deve ser capaz de reconhecer o dispositivo (autenticação), habilitar ações específicas do dispositivo (autorização) e operar e gerenciar o dispositivo em um contexto específico (gerenciamento do dispositivo).

Para autenticação, o serviço IoT deve ter uma impressão digital da credencial, de forma que quando o dispositivo se conecta e envia a credencial ao serviço IoT, o serviço IoT pode relacionar a conexão física com os objetos de configuração. Para AWS IoT, você registra sua credencial, o que permite que o serviço IoT reconheça a conexão de entrada. O handshake TLS, que requer que o dispositivo tenha acesso à chave privada (o que o serviço IoT não tem), garante que a credencial foi enviada do dispositivo com a chave privada. É por isso que é tão essencial proteger a chave privada no dispositivo.

Para autorização, o serviço IoT deve aplicar regras para a conexão que concede o acesso mínimo ao serviço IoT. Acesso mínimo ao serviço IoT significa definir limites para que o dispositivo use apenas os recursos de que precisa para cumprir sua obrigação operacional. Por exemplo, os clientes da AWS criam políticas de IoT que se relacionam ao objeto de configuração da credencial.

Para gerenciamento de dispositivos, você desejará aplicar metadados aos seus objetos de configuração para especificar claramente grupos ou agregações de dispositivos ou frotas. Com a IoT, precisaremos gerenciar milhares, dezenas de milhares e milhões de dispositivos. Será impraticável gerenciar cada dispositivo individualmente. Planeje com antecedência para aplicar metadados à configuração do seu dispositivo, pois a adaptação ou refatoração pode ser dolorosa. Para AWS IoT, você cria objetos de configuração Thing Type e Thing Group que orientam as práticas de gerenciamento de dispositivos IoT.

Abordagens para provisionamento em nuvem de dispositivo em escala


Não se pode dizer que todos A implantação de IoT é diferente quando se trata de provisionamento de dispositivo, mas há diferenciação suficiente entre fornecedores de hardware, aplicativos de IoT e contextos operacionais para conduzir um conjunto robusto de mecanismos que influenciarão sua decisão sobre o mecanismo certo para você. De modo geral, existem três abordagens:registro em massa, registro sob demanda e registro lento. Todos os métodos a seguir esperam que cada dispositivo IoT tenha, ou tenha, seu próprio par de chave privada e certificado exclusivo.

Registro em massa

Com o registro em massa, o conjunto de credenciais que você deseja registrar com um serviço IoT é conhecido antes da implantação do dispositivo no campo. Assim que a lista de credenciais for obtida, você canalizará as credenciais para um processo de registro em massa. O processo de registro em massa registra a credencial e, em seguida, também coordena a credencial com objetos de gerenciamento relacionados no serviço IoT onde você usa para gerenciar sua frota IoT. O registro em massa pode exigir personalização, mas os provedores de serviços de IoT geralmente fornecem um processo de registro em massa aos clientes. Por exemplo, a AWS fornece o processo de registro em massa do AWS IoT como parte do serviço AWS IoT Core e processamento personalizado usando o SDK da AWS. Um projeto de código aberto chamado ThingPress lida com casos de uso de importação específicos.

Registro sob demanda

Com o registro do dispositivo sob demanda, o conjunto de dispositivos físicos com credenciais emparelhadas não é conhecido por você antes da implantação do dispositivo no campo. Depois que o dispositivo for implantado no campo, você ligará o dispositivo. Com sob demanda, uma sub-rotina de conectividade determina se uma referência ao emissor da credencial foi registrada no serviço IoT. Contanto que o serviço IoT tenha um mecanismo robusto para verificar se você é de fato o proprietário do emissor, o que significa que você tem em mãos a identidade do emissor (em PKI, a chave privada do emissor), você pode ter certeza de que o emissor forneceu a credencial. Em seguida, a sub-rotina registra automaticamente a credencial e cria objetos de gerenciamento relacionados. Por exemplo, a AWS tem dois mecanismos de registro de dispositivo sob demanda chamados Just-In-Time-Provisioning (JITP) que usa um modelo de provisionamento e Just-In-Time-Registration (JITR) que fornece mecanismos que podem ser totalmente personalizados.

Registro lento

Com o registro lento, nem o conjunto de dispositivos físicos nem as credenciais emparelhadas são conhecidos antes da implantação no campo. Nesse caso, os dispositivos têm uma identidade conhecida e imutável (normalmente, uma chave privada protegida) que o serviço IoT pode confirmar sem transferir a identidade privada para além do dispositivo.

Hoje, existem três mecanismos para registro preguiçoso:por reivindicação, por dispositivo móvel autorizado e por lista autorizada de identidades. No primeiro caso, o dispositivo envia a declaração ao emissor da credencial, o emissor responde com um token e o aparelho usa o token para fazer uma chamada de API de serviço web direta para emitir o certificado. No segundo caso, o dispositivo funciona em conjunto com um telefone móvel, onde o telefone móvel usa credenciais móveis, como um nome de usuário e senha, o emissor responde com um token, o telefone móvel envia o token para o dispositivo e o dispositivo usa o token para fazer uma chamada de API direta. No terceiro caso, uma lista autorizada, que pode ser uma lista de chaves públicas, e o dispositivo faz uma chamada de API direta para o serviço IoT com um CSR. A chave pública derivada do CSR é então comparada com a lista autorizada e, a seguir, fornece o certificado ao dispositivo quando existe uma correspondência. Por exemplo, o AWS Fleet provisioning fornece reivindicações e mecanismos de provisionamento baseados em smartphones, o projeto de código aberto IoT Provisioning Secret-Free fornece mecanismos de registro preguiçosos usando declarações e o parceiro AWS 1nce fornece uma experiência de provisionamento celular simplificada por meio do AWS Marketplace.

Escolha do aprovisionamento de dispositivo certo para você

Escolher o provisionamento de dispositivo certo para você significa encontrar a credencial do dispositivo e a prática de provisionamento de nuvem do dispositivo que se alinha com o design de hardware, design de software, fabricação e operações de ciclo de vida do dispositivo. O design do hardware define como você define e armazena a identidade do dispositivo individual e os arquivos de credencial. O design do software influencia a autorização do dispositivo. A fabricação influencia as condições sob as quais os segredos serão criados e armazenados, ou identificados, influencia como as impressões digitais de autorização refletem nos serviços de IoT.

A maneira como você decide fazer o provisionamento de credencial para o hardware físico, que reflete o design do hardware que geralmente é decidido com bastante antecedência ao fazer o design do produto, cria um eixo fundamental para tipos específicos de processos de provisionamento em nuvem. Além disso, se você não estiver fazendo sua própria fabricação, então usará fabricantes contratados para construir seus produtos. A fabricação por contrato tem muitos benefícios, mas muitos aspectos do processo de fabricação não estarão sob seu controle, o que inclui a criação de segredos de dispositivo, como chaves privadas e certificados na linha de fabricação. Os riscos como superprodução, clonagem e outros vetores de ataque podem estar diretamente relacionados ao fabricante contratado, o que significa que você precisa ter muita confiança para dormir bem à noite.

Se você não está gerenciando uma CA privada para sua frota de IoT, então as credenciais pré-provisionadas podem ser a escolha certa para você. As credenciais pré-provisionadas podem custar um pouco mais no início, mas vimos que elas reduzem significativamente os custos operacionais. Se você precisar gerenciar sua própria CA privada, algumas empresas de hardware fornecem credenciais pré-provisionadas onde a configuração é feita na saída da fita, o que significa que o fabricante do contrato não terá nenhum conhecimento dos segredos do dispositivo. Caso contrário, você pode preferir o provisionamento de estilo preguiçoso, onde o dispositivo tem a chave privada imutável ou chave privada autogerada reproduzível no dispositivo e pode participar com um serviço IoT para ter credenciais implantadas após algum nível de atestado. Se você ficar na infeliz situação de não ter uma chave privada imutável no dispositivo, ainda poderá fornecer uma chave privada e credencial diretamente para o flash, mas isso não é muito recomendado.

Em contraste com o design de hardware, o design de software é mais flexível e pode mudar ao longo do desenvolvimento do dispositivo e até mesmo do ciclo de vida (pense em atualizações de firmware por via aérea). Sempre que você enviar um novo lote de dispositivos para os clientes, precisará confiar no processo de provisionamento de dispositivos em nuvem. Assim como o design de software, o design de provisionamento pode exigir flexibilidade com base em seus requisitos de software em evolução. A configuração necessária e a amplitude de personalização impulsionam o processo de provisionamento de dispositivos em nuvem que você usará ao implantar frotas de dispositivos novos ou adicionais.

Os requisitos de operações do ciclo de vida do dispositivo impulsionarão o nível de flexibilidade que será necessário para o provisionamento da nuvem do dispositivo. Mais especificamente, embora a maioria dos processos de provisionamento em nuvem de dispositivo AWS IoT permita a criação automática de objetos de gerenciamento, como Thing Types e Thing Groups, se o seu processo também requer qualquer interoperabilidade personalizada durante o tempo de registro, você pode querer considerar Just-In-Time- Provisionamento que permite uma personalização mais profunda.

Por fim, ao examinar o ciclo de vida do dispositivo, considere a oportunidade de o dispositivo mudar de proprietário em toda a sua utilidade. Embora a identidade do dispositivo em termos de chave privada possa não mudar, existe a oportunidade de descontinuar o certificado do proprietário anterior para mover o dispositivo para o "estado de fábrica". Quando o novo proprietário humano comissiona o dispositivo para uma nova rede e provisiona usando talvez um aplicativo móvel, um novo Certificado pode precisar ser provisionado naquele momento. A mecânica do ciclo de vida então precisaria acompanhar esses requisitos.

Conclusão

Ao longo deste artigo, discutimos as situações de provisionamento de IoT que você provavelmente está testemunhando hoje. Da mesma forma, você testemunhou que existem muitas opções, dependendo do que você está tentando alcançar e dos resultados que deseja que seus clientes desfrutem. Como tudo, a segurança sustenta o provisionamento, que começa com cada dispositivo tendo seu par de chave privada e certificado único e identificável. A abordagem de provisionamento de credencial que você escolhe cria esse ponto dinâmico para as opções de provisionamento de nuvem de seu dispositivo. Se você estiver fazendo um novo design, vai querer dar uma olhada em soluções de segurança de hardware reforçadas, como elementos e enclaves seguros, que por sua vez simplificam o provisionamento de dispositivos em nuvem. Se você estiver evoluindo ou retrabalhando um projeto existente, suas escolhas podem parecer muito mais limitadas, mas ainda há opções para conectar seu dispositivo com capacidade de IoT. Finalmente, ao longo dos exemplos e anedotas, você pôde testemunhar que a AWS IoT forneceu soluções de provisionamento em nuvem de dispositivo que combinam bem com nossas soluções de parceiros de silício. Agora é hora de construir dispositivos IoT comissionados e provisionados com segurança!