Compartilhar via

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

  • Artigo

À medida que mais fabricantes lançam dispositivos IoT, convém identificar diretrizes relacionadas a práticas comuns. Este artigo resume as práticas de segurança recomendadas a serem consideradas quando você fabrica dispositivos para uso com o DPS (Serviço de Provisionamento de Dispositivos) de IoT do Azure.

  • Selecionar opções de autenticação de dispositivo
  • Instalar certificados em dispositivos IoT
  • Integrar um Trusted Platform Module (TPM) ao processo de fabricação

Selecionar 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 questões como limitações de hardware, custo e nível de experiência em segurança afetam as opções que você escolhe. Além disso, sua abordagem de segurança afeta 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 usados 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 na IoT do Azure usa um desses três tipos. O restante deste artigo pesquisa 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. Na IoT do Azure, 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 CA com base em uma cadeia completa. Uma cadeia de certificados é uma lista hierárquica de todos os certificados necessários para autenticar um certificado EE (entidade final). Para autenticar um certificado EE, é necessário autenticar cada certificado na cadeia, incluindo uma CA raiz confiável.

Prós do X.509:

  • O X.509 é o tipo de autenticação mais seguro com suporte no IoT do Azure.
  • O 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 no X.509.

Contras do X.509:

  • Muitos clientes podem precisar contar com fornecedores externos para seus certificados.
  • O gerenciamento de certificados pode ser dispendioso e agregado ao custo total da solução.
  • O gerenciamento do ciclo de vida do certificado pode ser difícil se a logística não for bem considerada.

Trusted Platform Module (TPM)

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 físico ou virtual 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 do TPM também podem armazenar certificados do X.509.
  • O atestado de TPM no DPS usa a chave de endosso (EK) do TPM, uma forma de autenticação assimétrica. Com a autenticação assimétrica, uma chave pública é usada para criptografia e uma chave privada separada é usada para descriptografia. Por outro lado, as chaves simétricas usam a autenticação simétrica, em que a chave privada é usada para criptografia e descriptografia.

Prós do TPM:

  • Os TPMs são incluídos como hardware padrão em muitos dispositivos Windows, com suporte integrado para o sistema operacional.
  • O atestado do TPM é mais fácil de proteger do que o atestado de chave simétrica baseado em token de SAS (Assinatura de Acesso Compartilhado).
  • Você pode facilmente expirar e renovar, ou reverter, as credenciais do dispositivo. O DPS reverte automaticamente as credenciais do Hub IoT sempre que um dispositivo TPM está prestes a ser provisionado novamente.

Contras do 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.
  • Você pode ter que recriar o painel do seu dispositivo para incluir um TPM no hardware.
  • Se você reverter a EK em um TPM, ela destruirá a identidade do TPM e criará uma nova. Embora o chip físico permaneça o mesmo, ele tem uma nova identidade na sua solução de IoT.

Chave simétrica

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

Prós da chave simétrica:

  • O uso de chaves simétricas é a maneira mais simples e econômica de começar a usar a autenticação.
  • O uso de chaves simétricas simplifica seu processo porque não há nada extra para gerar.

Contras da chave simétrica:

  • As chaves simétricas assumem 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 locais. Por outro lado, 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 acompanhamento de práticas de segurança inadequadas. Uma tendência comum com chaves simétricas é codificar permanentemente as chaves não criptografadas nos dispositivos. Embora essa prática seja conveniente, ela deixa as chaves vulneráveis. Você pode mitigar alguns riscos armazenando com segurança a chave simétrica no dispositivo. No entanto, se a sua prioridade for a segurança em vez da conveniência, use certificados X.509 ou TPM para autenticação.

Chave simétrica compartilhada

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

Prós da chave simétrica compartilhada:

  • Simples de implementar e barata de produzir em grande escala.

Contras da chave simétrica compartilhada:

  • Altamente vulnerável a ataques. O benefício da implementação fácil é amplamente superado pelo risco.
  • Qualquer pessoa pode representar seus dispositivos se eles obtiverem a chave compartilhada.
  • Se você depende de uma chave simétrica compartilhada que foi comprometida, provavelmente perderá o controle dos dispositivos.

Fazer a escolha certa para seus dispositivos

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

Instalar certificados em dispositivos IoT

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

Se você está acostumado a usar senhas, pode se perguntar por que não consegue usar o mesmo certificado em todos os seus dispositivos, da mesma forma que conseguiria usar a mesma senha em todos os seus dispositivos. Primeiramente, usar a mesma senha em qualquer lugar é perigoso. A prática expôs as empresas a grandes ataques de DDoS, incluindo aquele que derrubou o DNS na Costa Leste dos Estados Unidos há alguns anos. Nunca use a mesma senha em qualquer lugar, mesmo com contas pessoais. Em segundo lugar, um certificado não é uma senha, é uma identidade exclusiva. Uma senha é como um código secreto que qualquer pessoa pode usar para abrir a porta de um prédio seguro. Você sabe qual é a senha e pode fornecê-la a qualquer pessoa para ter acesso. 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. Ele está vinculado a quem você é. Desde que o guarda compare com precisão as pessoas com suas respectivas carteiras de motorista, somente você pode usar sua carteira (identidade) para obter acesso.

Variáveis envolvidas em decisões de certificado

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

De onde provém a raiz do certificado de confiança

Pode ser dispendioso e complexo gerenciar uma infraestrutura de chave pública (PKI). Especialmente se a sua empresa não tiver nenhuma experiência em gerenciar uma PKI. As opções são:

  • Usar uma PKI terceirizada. Você pode comprar certificados de assinatura intermediários de um fornecedor de certificado terceirizado. Ou pode usar uma Autoridade de Certificação (CA) privada.
  • Usar uma PKI autogerenciada. Você pode manter seu próprio sistema de PKI e gerar seus próprios certificados.
  • Usar o serviço de segurança Azure Sphere. Essa opção se aplica somente a dispositivos Azure Sphere.

Onde os certificados são armazenados

Há 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 por 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 o painel de controle do seu dispositivo já tem um HSM instalado. Se você sabe que não tem um HSM, fale com o fabricante do seu 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 repositório de certificados. Por exemplo, o repositório 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 é ideal. Ela 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 localmente e offline.
  • Sem conectividade. Nesse caso, você pode obter certificados que foram gerados antes do tempo. Ou pode usar uma PKI offline para gerar certificados localmente.

Requisito de auditoria

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

  • Não é um setor confidencial. Nenhuma auditoria é necessária.
  • Setor confidencial. Os certificados devem ser instalados em um ambiente seguro de acordo com os requisitos de certificação de conformidade. Se você precisa de um ambiente seguro para instalar certificados, provavelmente já sabe como os certificados são instalados nos seus dispositivos. E você provavelmente já tem um sistema de auditoria em vigor.

Duração da validade do certificado

Como uma carteira de motorista, os certificados têm uma data de validade que é definida quando são criados. Veja, a seguir, as opções de duração da validade do certificado:

  • Renovação não necessária. Essa abordagem usa um período de renovação longo, portanto, você nunca precisará renovar o certificado durante o tempo de vida do dispositivo. Embora seja conveniente, essa abordagem também é arriscada. Você pode reduzir os riscos usando um armazenamento seguro, como um HSM, nos 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 o tempo de vida 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á obtendo certificados e que tipo de funcionalidade over-the-air seus dispositivos devem 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 fornecem ao fornecedor de HSM acesso a um certificado de autenticação. Em seguida, o fornecedor de HSM instala certificados assinados por esse certificado de autenticação em cada HSM que o cliente adquire. Tudo o que o cliente precisa fazer é instalar o HSM no dispositivo. Embora esse serviço acrescente custos, ele ajuda a agilizar seu processo de fabricação. E resolve a questão de quando instalar certificados.
  • Certificados gerados pelo dispositivo. Se os seus dispositivos geram certificados internamente, você deve extrair o certificado X.509 público do dispositivo para inscrevê-lo no DPS.
  • Fábrica conectada. Se a sua fábrica possui conectividade, você pode gerar certificados de dispositivo sempre que precisar deles.
  • Fábrica offline com sua própria PKI. Se a 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 terceirizada. Se a sua fábrica não tiver conectividade e você estiver usando uma PKI terceirizada, você deverá gerar os certificados antecipadamente. 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. Essa abordagem é a mais conveniente para o seu processo de fabricação.

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

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

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

Integrar um TPM ao processo de fabricação

Se você usa um TPM para autenticar seus dispositivos IoT, esta seção oferece diretrizes. As diretrizes englobam os dispositivos TPM 2.0 amplamente usados ​​que têm suporte de chave de Hash-based Message Authentication Code (HMAC). A especificação TPM para chips TPM é um padrão ISO mantido pelo Trusted Computing Group. Para obter mais informações sobre o TPM, consulte as especificações para o TPM 2.0 e o ISO/IEC 11889.

Assumir a propriedade do TPM

Uma etapa crítica na fabricação de um dispositivo com um chip TPM é assumir a propriedade do TPM. Essa etapa é necessária para que você possa fornecer uma chave ao proprietário do dispositivo. A primeira etapa é extrair a chave de endosso (EK) do dispositivo. A próxima etapa consiste em reivindicar a propriedade. Como fazer isso depende de qual TPM e sistema operacional você usa. Se necessário, entre em contato com o fabricante do TPM ou com o desenvolvedor do sistema operacional do dispositivo para determinar como reivindicar a propriedade.

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

Importante

As diretrizes a seguir pressupõem que você use um TPM discreto, de firmware ou integrado. Em locais onde ele é aplicável, as diretrizes adicionam observações sobre o uso de um TPM não discreto ou de software. Se você usa um TPM de software, poderá haver etapas adicionais que essas diretrizes não incluem. 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 TPM de software na linha do tempo de fabricação geral a seguir. No entanto, embora um TPM emulado de software seja adequado para protótipos e testes, ele não consegue fornecer o mesmo nível de segurança que um TPM discreto, de firmware ou integrado. Como uma prática geral, evite usar um TPM de software em produção.

Linha do tempo de fabricação geral

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 é exclusivo, e essa linha do tempo mostra os padrões mais comuns. A linha do tempo oferece diretrizes sobre quando executar determinadas ações com as chaves.

Etapa 1: O TPM é fabricado

  • Se você adquirir TPMs de um fabricante para uso nos seus dispositivos, confira se eles extrairão as chaves de endosso públicas (EK_pubs) para você. Será útil se o fabricante fornecer a lista de EK_pubs com os dispositivos enviados.

    Observação

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

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

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

Etapa 2: O TPM é instalado em um dispositivo

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

  • Se você não extraiu a 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 se apropriar do TPM.

Etapa 3: O dispositivo tem firmware e software instalados

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

  • Agora é a última chance de extrair a EK_pub. Se um terceiro for instalar o software no seu dispositivo, é recomendável extrair a EK_pub primeiro.
  • Esse ponto no processo de fabricação é ideal para se apropriar do TPM.

    Observação

    Se você estiver usando um TPM de software, poderá instalá-lo agora. Extraia a EK_pub ao mesmo tempo.

Etapa 4: O dispositivo é empacotado e enviado ao depósito

Às vezes, um dispositivo pode ficar em um depósito por até um ano antes de ser implantado e provisionado com o DPS. Se um dispositivo ficar em um depósito por um longo tempo antes da implantação, os clientes que implantam o dispositivo poderão precisar 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 do TPM.

Recursos

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