Share via

Práticas de segurança para fabricantes de dispositivos IoT do Azure

  • Artigo

À medida que mais fabricantes lançam dispositivos IoT, é útil identificar orientações sobre práticas comuns. Este artigo resume as práticas de segurança recomendadas a serem consideradas ao fabricar dispositivos para uso com o DPS (Serviço de Provisionamento de Dispositivos IoT) do Azure.

  • Seleção de opções de autenticação de dispositivo
  • Instalando certificados em dispositivos IoT
  • Integração de um TPM (Trusted Platform Module) no processo de fabricação

Seleção de opções de autenticação de dispositivo

O objetivo final de qualquer medida de segurança de dispositivo IoT é criar uma solução de IoT segura. Mas problemas como limitações de hardware, custo e nível de conhecimento em segurança afetam as opções escolhidas. Além disso, sua abordagem à segurança afeta a forma como seus dispositivos IoT se conectam à nuvem. Embora haja vários elementos de segurança da IoT a considerar, um elemento-chave que cada cliente encontra é o tipo de autenticação a ser usado.

Três tipos de autenticação amplamente utilizados são certificados X.509, TPM (Trusted Platform Modules) e chaves simétricas. Embora existam outros tipos de autenticação, a maioria dos clientes que criam soluções no Azure IoT usa um desses três tipos. O restante deste artigo analisa os prós e contras do uso de cada tipo de autenticação.

Certificado X.509

Os certificados X.509 são um tipo de identidade digital que você pode usar para autenticação. O padrão de certificado X.509 está documentado no IETF RFC 5280. No Azure IoT, há duas maneiras de autenticar certificados:

  • Impressão digital. Um algoritmo de impressão digital é executado em um certificado para gerar uma cadeia de caracteres hexadecimal. A cadeia de caracteres gerada é um identificador exclusivo para o certificado.
  • Autenticação de autoridade de certificação baseada em uma cadeia completa. Uma cadeia de certificados é uma lista hierárquica de todos os certificados necessários para autenticar um certificado de entidade final (EE). Para autenticar um certificado EE, é necessário autenticar cada certificado na cadeia, incluindo uma autoridade de certificação raiz confiável.

Prós para X.509:

  • X.509 é o tipo de autenticação mais seguro suportado no Azure IoT.
  • X.509 permite um alto nível de controle para fins de gerenciamento de certificados.
  • Muitos fornecedores estão disponíveis para fornecer soluções de autenticação baseadas em X.509.

Contras para X.509:

  • Muitos clientes podem precisar confiar em fornecedores externos para seus certificados.
  • O gerenciamento de certificados pode ser caro e aumenta o custo total da solução.
  • A gestão do ciclo de vida dos certificados pode ser difícil se a logística não for bem pensada.

TPM (Trusted Platform Module)

O TPM, também conhecido como ISO/IEC 11889, é um padrão para gerar e armazenar chaves criptográficas com segurança. O TPM também se refere a um dispositivo de E/S virtual ou físico que interage com módulos que implementam o padrão. Um dispositivo TPM pode existir como hardware discreto, hardware integrado, um módulo baseado em firmware ou um módulo baseado em software.

Há duas diferenças principais entre TPMs e chaves simétricas:

  • Os chips TPM também podem armazenar certificados X.509.
  • O atestado TPM no DPS usa a chave de endosso TPM (EK), uma forma de autenticação assimétrica. Com a autenticação assimétrica, uma chave pública é usada para encriptação e uma chave privada separada é usada para desencriptação. Em contraste, as chaves simétricas usam autenticação simétrica, onde a chave privada é usada para criptografia e descriptografia.

Prós para TPM:

  • Os TPMs estão incluídos como hardware padrão em muitos dispositivos Windows, com suporte integrado para o sistema operacional.
  • O atestado TPM é mais fácil de proteger do que o atestado de chave simétrica baseado em token de assinatura de acesso compartilhado (SAS).
  • Você pode facilmente expirar e renovar, ou rolar, credenciais de dispositivo. O DPS rola automaticamente as credenciais do Hub IoT sempre que um dispositivo TPM deve ser reprovisionado.

Contras para TPM:

  • Os TPMs são complexos e podem ser difíceis de usar.
  • O desenvolvimento de aplicativos com TPMs é difícil, a menos que você tenha um TPM físico ou um emulador de qualidade.
  • Talvez seja necessário redesenhar a placa do seu dispositivo para incluir um TPM no hardware.
  • Se você rolar o EK em um TPM, ele destrói a identidade do TPM e cria um novo. Embora o chip físico permaneça o mesmo, ele tem uma nova identidade em sua solução de IoT.

Chave simétrica

Com chaves simétricas, a mesma chave é usada para encriptar e desencriptar mensagens. Como resultado, a mesma chave é conhecida pelo dispositivo e pelo serviço que a autentica. O Azure IoT dá suporte a conexões de chave simétrica baseadas em token SAS. A autenticação de chave simétrica requer uma responsabilidade significativa do proprietário para proteger as chaves e alcançar um nível igual de segurança com a autenticação X.509. Se você usar chaves simétricas, a prática recomendada é proteger as chaves usando um módulo de segurança de hardware (HSM).

Prós para chave simétrica:

  • Usar chaves simétricas é a maneira mais simples e de menor custo de começar a usar a autenticação.
  • O uso de chaves simétricas agiliza seu processo porque não há nada a mais para gerar.

Contras para chave simétrica:

  • As chaves simétricas exigem um grau significativo de esforço para proteger as chaves. A mesma chave é compartilhada entre o dispositivo e a nuvem, o que significa que a chave deve ser protegida em dois lugares. Em contraste, o desafio com os certificados TPM e X.509 é provar a posse da chave pública sem revelar a chave privada.
  • As chaves simétricas facilitam o cumprimento de práticas de segurança deficientes. Uma tendência comum com chaves simétricas é codificar as chaves não criptografadas nos dispositivos. Embora esta prática seja conveniente, deixa as chaves vulneráveis. Você pode reduzir alguns riscos armazenando com segurança a chave simétrica no dispositivo. No entanto, se a sua prioridade for a segurança e não a conveniência, use certificados X.509 ou TPM para autenticação.

Chave simétrica partilhada

Há uma variação de autenticação de chave simétrica conhecida como chave simétrica compartilhada. Esta abordagem envolve o uso da mesma chave simétrica em todos os dispositivos. A recomendação é evitar o uso de chaves simétricas compartilhadas em seus dispositivos.

Pro para chave simétrica compartilhada:

  • Simples de implementar e barato de produzir em escala.

Contras para chave simétrica compartilhada:

  • Altamente vulnerável a ataques. O benefício de uma implementação fácil é largamente superado pelo risco.
  • Qualquer pessoa pode fazer-se passar pelos seus dispositivos se obtiver a chave partilhada.
  • Se depender de uma chave simétrica partilhada que fica comprometida, provavelmente perderá o controlo dos dispositivos.

Fazer a escolha certa para os seus dispositivos

Para escolher um método de autenticação, considere os benefícios e custos de cada abordagem para seu processo de fabricação exclusivo. Para autenticação de dispositivos, geralmente há uma relação inversa entre o quão segura é uma determinada abordagem e o quão conveniente ela é.

Instalando certificados em dispositivos IoT

Se você usa certificados X.509 para autenticar seus dispositivos IoT, esta seção oferece orientação sobre como integrar certificados em seu processo de fabricação. Você precisará tomar várias decisões. Isso inclui decisões sobre variáveis de certificado comuns, quando gerar certificados e quando instalá-los.

Se você está acostumado a usar senhas, pode perguntar por que não pode usar o mesmo certificado em todos os seus dispositivos, da mesma forma que você seria capaz de usar a mesma senha em todos os seus dispositivos. Primeiro, usar a mesma senha em todos os lugares é perigoso. A prática expôs as empresas a grandes ataques DDoS, incluindo o que derrubou o DNS na costa leste dos EUA há vários anos. Nunca use a mesma senha em todos os lugares, mesmo com contas pessoais. Em segundo lugar, um certificado não é uma senha, é uma identidade única. Uma palavra-passe é como um código secreto que qualquer pessoa pode usar para abrir uma porta num edifício seguro. É algo que você sabe, e você pode dar a senha para qualquer pessoa para ganhar entrada. Um certificado é como uma carteira de motorista com sua foto e outros detalhes, que você pode mostrar a um guarda para entrar em um prédio seguro. Está ligado a quem você é. Desde que o guarda combine com precisão as pessoas com carteiras de motorista, apenas você pode usar sua carteira (identidade) para obter entrada.

Variáveis envolvidas nas decisões de certificação

Considere as seguintes variáveis e como cada uma delas afeta o processo geral de fabricação.

De onde vem a raiz de confiança do certificado

Pode ser dispendioso e complexo gerir uma infraestrutura de chave pública (PKI). Especialmente se a sua empresa não tem qualquer experiência na gestão de uma PKI. As suas opções:

  • Use uma PKI de terceiros. Você pode comprar certificados de assinatura intermediários de um fornecedor de certificados de terceiros. Ou você pode usar uma autoridade de certificação (CA) privada.
  • Use uma PKI autogerenciada. Você pode manter seu próprio sistema PKI e gerar seus próprios certificados.
  • Use o serviço de segurança do Azure Sphere . Esta opção aplica-se apenas a dispositivos Azure Sphere.

Onde os certificados são armazenados

Existem alguns fatores que afetam a decisão sobre onde os certificados são armazenados. Esses fatores incluem o tipo de dispositivo, as margens de lucro esperadas (se você pode pagar pelo armazenamento seguro), os recursos do dispositivo e a tecnologia de segurança existente no dispositivo que você pode usar. Considere as seguintes opções:

  • Em um módulo de segurança de hardware (HSM). O uso de um HSM é altamente recomendado. Verifique se a placa de controle do seu dispositivo já tem um HSM instalado. Se você sabe que não tem um HSM, trabalhe com o fabricante do hardware para identificar um HSM que atenda às suas necessidades.
  • Em um local seguro no disco, como um ambiente de execução confiável (TEE).
  • No sistema de arquivos local ou em um armazenamento de certificados. Por exemplo, o armazenamento de certificados do Windows.

Conectividade na fábrica

A conectividade na fábrica determina como e quando você obterá os certificados para instalar nos dispositivos. As opções de conectividade são as seguintes:

  • Conectividade. Ter conectividade é ótimo, agiliza o processo de geração de certificados localmente.
  • Sem conectividade. Nesse caso, você usa um certificado assinado de uma autoridade de certificação para gerar certificados de dispositivo local e offline.
  • Sem conectividade. Nesse caso, você pode obter certificados que foram gerados com antecedência. Ou você pode usar uma PKI offline para gerar certificados localmente.

Requisito de auditoria

Dependendo do tipo de dispositivos que você produz, você pode ter um requisito regulatório para criar uma trilha de auditoria de como as identidades de dispositivo são instaladas em seus dispositivos. A auditoria acrescenta um custo de produção significativo. Por isso, na maioria dos casos, só o faça se necessário. Se não tiver a certeza se é necessária uma auditoria, consulte o departamento jurídico da sua empresa. As opções de auditoria são:

  • Não é uma indústria sensível. Nenhuma auditoria é necessária.
  • Indústria sensível. Os certificados devem ser instalados em uma sala segura de acordo com os requisitos de certificação de conformidade. Se você precisa de uma sala segura para instalar certificados, provavelmente já está ciente de como os certificados são instalados em seus dispositivos. E você provavelmente já tem um sistema de auditoria em vigor.

Duração da validade do certificado

Tal como uma carta de condução, os certificados têm uma data de validade que é definida quando são criados. Aqui estão as opções de duração da validade do certificado:

  • Não é necessária renovação. Essa abordagem usa um longo período de renovação, portanto, você nunca precisará renovar o certificado durante a vida útil do dispositivo. Embora essa abordagem seja conveniente, também é arriscada. Você pode reduzir o risco usando armazenamento seguro como um HSM em seus dispositivos. No entanto, a prática recomendada é evitar o uso de certificados de longa duração.
  • Renovação necessária. Você precisará renovar o certificado durante a vida útil do dispositivo. A duração da validade do certificado depende do contexto, e você precisará de uma estratégia para renovação. A estratégia deve incluir onde você está recebendo certificados e que tipo de funcionalidade over-the-air seus dispositivos têm que usar no processo de renovação.

Quando gerar certificados

Os recursos de conectividade com a Internet em sua fábrica afetarão seu processo de geração de certificados. Você tem várias opções para quando gerar certificados:

  • Certificados pré-carregados. Alguns fornecedores de HSM oferecem um serviço premium no qual o fornecedor de HSM instala certificados para o cliente. Primeiro, os clientes dão ao fornecedor do HSM acesso a um certificado de assinatura. Em seguida, o fornecedor do HSM instala certificados assinados por esse certificado de assinatura em cada HSM comprado pelo cliente. Tudo o que o cliente precisa fazer é instalar o HSM no dispositivo. Embora este serviço acrescente custos, ajuda a agilizar o seu processo de fabrico. E resolve a questão de quando instalar certificados.
  • Certificados gerados por dispositivos. Se seus dispositivos geram certificados internamente, você deve extrair o certificado X.509 público do dispositivo para registrá-lo no DPS.
  • Fábrica conectada. Se sua fábrica tiver conectividade, você poderá gerar certificados de dispositivo sempre que precisar deles.
  • Fábrica offline com sua própria PKI. Se sua fábrica não tiver conectividade e você estiver usando sua própria PKI com suporte offline, poderá gerar os certificados quando precisar deles.
  • Fábrica offline com PKI de terceiros. Se sua fábrica não tiver conectividade e você estiver usando uma PKI de terceiros, deverá gerar os certificados com antecedência. E será necessário gerar os certificados a partir de um local que tenha conectividade.

Quando instalar certificados

Depois de gerar certificados para seus dispositivos IoT, você pode instalá-los nos dispositivos.

Se você usar certificados pré-carregados com um HSM, o processo será simplificado. Depois que o HSM é instalado no dispositivo, o código do dispositivo pode acessá-lo. Em seguida, você chamará as APIs do HSM para acessar o certificado armazenado no HSM. Esta abordagem é a mais conveniente para o seu processo de fabricação.

Se você não usar um certificado pré-carregado, deverá instalá-lo como parte do processo de produção. A abordagem mais simples é instalar o certificado no HSM ao mesmo tempo em que você pisca a imagem inicial do firmware. Seu processo deve adicionar uma etapa para instalar a imagem em cada dispositivo. Após esta etapa, você pode executar verificações de qualidade finais e quaisquer outras etapas, antes de empacotar e enviar o dispositivo.

Existem ferramentas de software disponíveis que permitem executar o processo de instalação e verificação de qualidade final em uma única etapa. Você pode modificar essas ferramentas para gerar um certificado ou para extrair um certificado de um armazenamento de certificados pré-gerado. Em seguida, o software pode instalar o certificado onde você precisa instalá-lo. Ferramentas de software desse tipo permitem que você execute a produção de qualidade de fabricação em escala.

Depois de ter certificados instalados em seus dispositivos, a próxima etapa é aprender como registrar os dispositivos com DPS.

Integração de um TPM no processo de fabrico

Se você usar um TPM para autenticar seus dispositivos IoT, esta seção oferece orientação. A documentação de orientação abrange os dispositivos TPM 2.0 amplamente utilizados com suporte de chaves HMAC (Hash-based Message Authentication Code). A especificação TPM para chips TPM é um padrão ISO mantido pelo Trusted Computing Group. Para obter mais informações sobre TPM, consulte as especificações para TPM 2.0 e ISO/IEC 11889.

Apropriação do TPM

Um passo crítico na fabricação de um dispositivo com um chip TPM é assumir a propriedade do TPM. Esta etapa é necessária para que você possa fornecer uma chave ao proprietário do dispositivo. O primeiro passo é extrair a chave de endosso (EK) do dispositivo. O próximo passo é realmente reivindicar a propriedade. Como você faz isso depende de qual TPM e sistema operacional você usa. Se necessário, entre em contato com o fabricante do TPM ou o desenvolvedor do sistema operacional do dispositivo para determinar como reivindicar a propriedade.

Em seu processo de fabricação, você pode extrair o EK e reivindicar a propriedade em momentos diferentes, o que adiciona flexibilidade. Muitos fabricantes aproveitam essa flexibilidade adicionando um módulo de segurança de hardware (HSM) para aumentar a segurança de seus dispositivos. Esta seção fornece orientação sobre quando extrair o EK, quando reivindicar a propriedade do TPM e considerações para integrar essas etapas em um cronograma de fabricação.

Importante

As diretrizes a seguir pressupõem que você use um TPM discreto, firmware ou integrado. Em locais onde é aplicável, as orientações acrescentam notas sobre o uso de um TPM não discreto ou de software. Se você usar um TPM de software, pode haver etapas adicionais que esta orientação não inclui. Os TPMs de software têm uma variedade de implementações que estão além do escopo deste artigo. Em geral, é possível integrar um software TPM no seguinte cronograma geral de fabricação. No entanto, embora um TPM emulado de software seja adequado para prototipagem e teste, ele não pode fornecer o mesmo nível de segurança que um TPM discreto, firmware ou integrado. Como prática geral, evite usar um software TPM na produção.

Cronograma geral de fabricação

A linha do tempo a seguir mostra como um TPM passa por um processo de produção e termina em um dispositivo. Cada processo de fabricação é único, e esta linha do tempo mostra os padrões mais comuns. A linha do tempo oferece orientação sobre quando tomar certas ações com as chaves.

Passo 1: TPM é fabricado

  • Se você comprar TPMs de um fabricante para uso em seus dispositivos, veja se eles extrairão chaves de endosso públicas (EK_pubs) para você. É útil se o fabricante fornecer a lista de EK_pubs com os dispositivos enviados.

    Nota

    Você pode conceder ao fabricante do TPM acesso de gravação à sua lista de inscrição usando políticas de acesso compartilhado em seu serviço de provisionamento. Essa abordagem permite que eles adicionem os TPMs à sua lista de inscrição para você. Mas isso é no início do processo de fabricação, e requer confiança no fabricante de TPM. Faça-o por sua conta e risco.

  • Se você fabrica TPMs para vender a fabricantes de dispositivos, considere fornecer aos seus clientes uma lista de EK_pubs juntamente com seus TPMs físicos. Fornecer aos clientes EK_pubs economiza uma etapa em seu processo.

  • Se você fabrica TPMs para usar com seus próprios dispositivos, identifique qual ponto do seu processo é o mais conveniente para extrair o EK_pub. Você pode extrair o EK_pub em qualquer um dos pontos restantes da linha do tempo.

Etapa 2: O TPM é instalado em um dispositivo

Neste ponto do processo de produção, você deve saber com qual instância do DPS o dispositivo será usado. Como resultado, você pode adicionar dispositivos à lista de inscrição para provisionamento automatizado. Para obter mais informações sobre o provisionamento automático de dispositivos, consulte a documentação do DPS.

  • Se você ainda não extraiu o EK_pub, agora é um bom momento para fazê-lo.
  • Dependendo do processo de instalação do TPM, esta etapa também é um bom momento para assumir a propriedade do TPM.

Passo 3: O dispositivo tem firmware e software instalados

Neste ponto do processo, instale o cliente DPS juntamente com o escopo da ID e a URL global para provisionamento.

  • Agora é a última chance de extrair o EK_pub. Se um terceiro instalar o software no seu dispositivo, é uma boa ideia extrair o EK_pub primeiro.
  • Este ponto do processo de fabricação é ideal para se apropriar do TPM.

    Nota

    Se estiver a utilizar um software TPM, pode instalá-lo agora. Extraia o EK_pub ao mesmo tempo.

Passo 4: O dispositivo é embalado e enviado para o armazém

Às vezes, um dispositivo pode ficar em um depósito por até um ano antes de ser implantado e provisionado com DPS. Se um dispositivo permanecer em um depósito por muito tempo antes da implantação, os clientes que implantarem o dispositivo talvez precisem atualizar o firmware, o software ou as credenciais expiradas.

Etapa 5: O dispositivo é instalado no local

Depois que o dispositivo chega ao seu local final, ele passa pelo provisionamento automatizado com DPS.

Para obter mais informações, consulte provisionamento e atestado TPM.

Recursos

Além das práticas de segurança recomendadas neste artigo, o Azure IoT fornece recursos para ajudar na seleção de hardware seguro e na criação de implantações de IoT seguras: