Uma solução segura que conecta dispositivos IoT à nuvem

　　Embora as pessoas estejam cada vez mais conscientes da necessidade de segurança, os desenvolvedores frequentemente se veem tomando atalhos para conectar dispositivos IoT à nuvem. Em muitos casos, o conflito entre a complexidade dos mecanismos de segurança apropriados, a memória limitada e os recursos de processamento disponíveis em dispositivos IoT movidos a microbaterias e a demanda por transporte de produtos parece intransponível.

　　Para resolver essas questões e simplificar a implementação de recursos de segurança em dispositivos IoT, a Microchip Technology e o Google colaboraram para criar um método que combina os recursos de hardware seguro da Microchip com uma estrutura de dados simples chamada JSON Web Token (JWT). O resultado é uma forma simples de garantir a autenticação mútua entre dispositivos IoT e os serviços centrais IoT do Google Cloud.

　　Este artigo apresentará ameaças de segurança aos dispositivos IoT e apresentará os dispositivos atualmente usados para enfrentar essas ameaças. Ele identificará vulnerabilidades de segurança e como desenvolvedores e projetistas de sistemas embarcados usam o JWT para desativá-las.

　　Vulnerabilidades de segurança em dispositivos IoT

　　Ataques a dispositivos IoT podem assumir várias formas e estão longe de se limitar a implantações em larga escala de IoT. Para hackers que buscam explorar recursos de muitos dispositivos individuais em botnets usados em ataques de negação de serviço distribuída (DDoS), até mesmo o menor IoT é um alvo atraente. Portanto, projetistas de todo tipo de dispositivo IoT inevitavelmente precisam proteger seus sistemas por meio de mecanismos robustos de segurança baseados em hardware para evitar ataques.

　　Por exemplo, usar memória do sistema ou armazenamento flash para armazenar chaves privadas para criptografia e autenticação torna dispositivos IoT vulneráveis a ataques. Pior ainda, hackers podem roubar essas chaves e usá-las para acessar redes IoT e recursos adicionais da empresa.

　　IC de Segurança

　　Dispositivos de segurança dedicados, como os CI CryptoMemory e CryptoAuthentication da Microchip Technology, possuem funções de hardware baseadas em mecanismos para proteger chaves privadas e outros dados secretos. Matrizes EEPROM são integradas a esses dispositivos, fornecendo armazenamento seguro e mecanismos de criptografia acessíveis apenas pela interface serial SPI ou I2C do dispositivo (veja a Figura 1). Portanto, esses dispositivos oferecem uma maneira simples de adicionar armazenamento seguro e outros recursos de segurança a qualquer projeto de dispositivo IoT.

　　Figura 1: Dispositivos de segurança de hardware da Microchip Technology (como AT88SC0204C CryptoMemory IC) fornecem armazenamento seguro e utilizam mecanismos integrados de criptografia para proteger o acesso a EEPROMs integradas no chip. (Imagem: Tecnologia de Microchip)

　　Membros da série Microchip CryptoAuthentication (como ATECC608A) aprimoram a base de armazenamento seguro e suportam algoritmos de criptografia comumente usados no design de segurança. Entre seus recursos de hardware, o dispositivo possui aceleração por hardware para vários algoritmos, incluindo:

　　Algoritmo de Criptografia Assimétrica:

　　Algoritmo de Assinatura Digital de Curvas Elípticas FIPS186-3 (ECDSA)

　　FIPS SP800-56A Curva Elíptica Diffie-Hellman (ECDH)

　　Criptografia de Curvas Elípticas P256 Padrão do NIST (ECC)

　　Algoritmo de criptografia simétrica:

　　Código de hash SHA-256

　　Criptografia do Código de Autenticação de Mensagens Baseado em Hash (HMAC)

　　Criptografia AES-128

　　Criptografia AES-GCM (Multiplicação de Campos de Galois)

　　Função de Derivação de Chave (KDF):

　　Função pseudoaleatória (PRF) KDF

　　Extração baseada em HMAC – e expansão do KDF (HKDF)

　　Para especialistas em criptografia, esse conjunto de recursos de criptografia representa uma lista abrangente de mecanismos necessários para suportar protocolos de segurança de nível mais alto. Autenticação e troca segura de dados. Por exemplo, o recurso KDF fornece os mecanismos básicos necessários para protocolos de Segurança da Camada de Transporte (TLS) verificarem participantes em sessões de troca de dados antes das trocas ou mesmo começarem.

　　Neste protocolo, sessões TLS enviam requisições dos clientes para o servidor para iniciar uma sessão segura. O servidor responde usando seu certificado digital, que o cliente usa para confirmar a identidade do servidor. Após o cliente verificar o servidor dessa forma, as configurações de sessão continuam a gerar chaves de sessão usando a chave pública do servidor para criptografar alguns valores aleatórios criados usando PRF KDF ou o mais poderoso HDKF.

　　O protocolo de autenticação TLS é a base da segurança na Internet. Toda a indústria de provedores de certificados, conhecida como Autoridade Certificadora (CA), evoluiu para um componente chave de suporte às comunicações seguras. A empresa obtém um certificado confiável da CA para instalar em seus próprios servidores, suportando o mencionado protocolo padrão de autenticação TLS.

　　Para aplicações de IoT, as redes são amplamente e profundamente conectadas às empresas, e essa autenticação unidirecional é insuficiente para garantir proteção. Por exemplo, hackers com certificados fraudulentos podem se apresentar como servidores legítimos para dispositivos IoT como parte de um ataque mais amplo.

　　Apesar dos riscos, desenvolvedores de IoT frequentemente têm dificuldade para implementar protocolos de autenticação mútua TLS porque certificados, chaves e softwares necessários para autenticação de clientes usando TLS podem exceder as capacidades de muitos dispositivos IoT. Por meio da colaboração, a Microchip Technology e o Google criaram uma abordagem alternativa que combina ATECC608A funcionalidade com uma estrutura de dados simples chamada JSON Web Token (JWT). O resultado é uma forma simples de garantir a autenticação mútua entre dispositivos IoT e os serviços centrais IoT do Google Cloud.

　　Autenticação baseada no JWT

　　O RFC 7519 especifica que o JWT é um contêiner padrão da indústria para informações sobre a entidade que prepara e transmite o JWT, conhecido como reivindicação. A estrutura do JWT em si consiste em três partes:

　　Títulos, incluindo o nome JSON: o nome do algoritmo criptográfico ("alg") (por exemplo, o "EC256" da ECDSA usa a curva P-256 do NIST) para assinar tokens e tipos de token ("typ") (o "JWT" desses tokens)

　　Payload, incluindo o nome JSON: par de valores para cada reivindicação

　　Assinatura: Ele usa o algoritmo especificado no cabeçalho para codificar a chave, o cabeçalho e o conjunto de declarações, cada um convertido individualmente na codificação da URL base64 antes da criptografia

　　A RFC 7519 oferece grande flexibilidade para especificar reivindicações em cargas úteis ou outras peças. O padrão permite até mesmo JWTs inseguros criados sem assinatura ou criptografia, caso em que o cabeçalho incluirá o nome do algoritmo: par de valores {{alg":"none"}. Para JWTs usados com os serviços centrais IoT do Google Cloud, o Google precisa de uma seção de assinatura e um payload contendo três declarações obrigatórias, incluindo:

　　"iat" - O "tempo de emissão" ao criar o token no formato de carimbo de tempo ISO 8601 UTC, o número de segundos desde 1970-01-01T00:00:00Z (por exemplo, 1561896000 12:00 GMT em 30 de junho de 2019)

　　"exp" - O carimbo de tempo UTC especificando o tempo de expiração do token, até 24 horas acima do valor "IAT" mais um período de carência de 10 minutos, para abordar diferentes vieses de clock do sistema entre cliente e servidor (por exemplo, 1º de julho de 2019 1561982400, GMT 00:00 00:00)

　　"aud" - uma string contendo o ID do projeto Google Cloud do desenvolvedor

　　< p> a solução de autenticação de dispositivos IoT do Google combina autenticação convencional baseada em TLS com JWT, criada com essas declarações relativamente simples para autenticação de dispositivos IoT. Para iniciar uma nova sessão, o dispositivo IoT abre um socket seguro para o servidor e autentica o servidor usando o mesmo protocolo TLS descrito anteriormente.

　　O próximo passo desse processo depende do protocolo leve de transmissão de telemetria em fila de mensagens (MQTT) do Google IoT Cloud para transações em redes IoT. Usando um socket seguro para um servidor autenticado, o dispositivo IoT usa seu JWT único como senha de login para "fazer login" no serviço host MQTT nesse servidor (Inventário 1).

　　Embora dispositivos IoT enviem nomes de usuário como parte dessa sequência de login, os nomes de usuário não são usados para autenticação. Portanto, um nome de usuário virtual (Listagem 2) foi transferido. Em vez disso, a autenticação de dispositivos IoT é baseada no JWT enviado como senha de login. Como as assinaturas JWT são uma combinação de cabeçalhos, cargas úteis e chaves privadas de dispositivos, os serviços centrais IoT do Google Cloud podem verificar se o JWT realmente vem de dispositivos autorizados. Para essa verificação, os Serviços IoT do Google Cloud utilizam chaves públicas de dispositivos previamente armazenadas no Google Cloud por desenvolvedores de dispositivos IoT usando o processo de gerenciamento de chaves descrito abaixo. Comparado ao uso exclusivo do TLS, essa abordagem oferece autenticação mútua por meio de uma abordagem híbrida, acelerando processos e reduzindo a necessidade de recursos para dispositivos IoT.

　　Principais facilitadores

　　ATECC608A e a funcionalidade de sua cadeia de suprimentos são os principais impulsionadores dessa abordagem. Embora qualquer MCU possa eventualmente gerar assinaturas de criptografia criptografadas a partir de cabeçalhos e cargas úteis do JWT, qualquer método apenas de software ainda é vulnerável a ataques sem armazenamento de chaves de segurança baseado em hardware. Além disso, para muitos dispositivos ou aplicações IoT com recursos limitados e requisitos rigorosos de tempo de resposta, a carga do processador e a latência de execução exigidas para implementação "apenas por software" podem ser proibidas. Por fim, sem algoritmos de segurança extensos e experiência mais avançada em protocolos, é difícil para os desenvolvedores implementarem as funções de software necessárias. O Microchip resolve essas questões por meio de sua biblioteca CryptoAuthLib (Figura 2).

　　Figura 2: Como o CryptoAuthLib usa a camada de abstração de hardware (HAL) para separar funções da API e primitivas centrais do hardware subjacente, os desenvolvedores podem posicionar seu software para vários dispositivos de suporte. (Imagem: Tecnologia de Microchip)

　　O Microchip CryptoAuthLib simplifica a implementação de recursos seguros de IoT, como o protocolo de autenticação do Google JWT, reduzindo operações de segurança complexas a um conjunto de chamadas de função fornecidas pela interface de programação de aplicações (API) CryptoAuthLib. Para desenvolvedores de IoT, talvez o mais importante seja o recurso central Microchip CryptoAuthLib, que aproveita totalmente os CIs de criptografia Microchip como o ATECC608A para acelerar a execução dos recursos de segurança no design. Por exemplo, na Listagem 1, uma chamada para atca_jwt_finalize() usa dispositivos de criptografia disponíveis (como ATECC608A) para criar um JWT para a senha da Listagem 2. Neste caso, ATECC608A acelerar a criptografia das assinaturas JWT, leia o projeto de sua chave integrada de armazenamento seguro para completar o processo de criação de assinaturas descrito anteriormente.

　　No entanto, mesmo com softwares complexos e dispositivos de segurança, dispositivos IoT continuam vulneráveis a ataques devido aos métodos tradicionais de gerenciamento de chaves e certificados. No passado, chaves privadas precisavam ser geradas externamente e carregadas em dispositivos de armazenamento seguros durante a fabricação, distribuição ou até mesmo implantação. Mesmo ao usar módulos de segurança de hardware e recursos de segurança, segredos brevemente existentes além do único dispositivo "necessário saber" representam vulnerabilidades de segurança que podem ser expostas acidentalmente ou intencionalmente. Ao aproveitar as capacidades ATECC608A, Microchip e Google eliminaram em grande parte vulnerabilidades tradicionais de segurança.

　　Nessa nova abordagem, a Microchip utiliza a capacidade do ATECC608A de gerar pares de chaves sem deixar o dispositivo com uma chave privada (Figura 3). O Microchip então utiliza um certificado intermediário para assinar a chave pública gerada pelo dispositivo, que é fornecida pelo cliente e armazenada em um servidor seguro dentro das instalações de segurança da Microchip. Por fim, a Microchip transmite a chave pública de forma segura para a conta do cliente no Google Cloud IoT Device Manager, que pode armazenar até três chaves públicas por dispositivo para suportar políticas de rotação de chaves. Após a implantação, dispositivos IoT podem usar ATECC608A recursos de segurança para criar JWTs usados no processo de autenticação mútua descrito anteriormente.

　　Figura 3: A combinação da Microchip Technology e dos serviços IoT do Google Cloud simplifica a configuração de chaves e certificados, fornecendo um mecanismo protegido voltado para fortalecer a segurança das aplicações IoT. (Imagem: Google)

　　Essa colaboração entre Microchip e Google permite que os desenvolvedores se desfaçam completamente desse processo crítico de gerenciamento de chaves. Para requisitos personalizados, os desenvolvedores podem usar a função da API CryptoAuthLib atcab_genkey() para implementar seu próprio processo de gerenciamento de chaves, o que leva a ATECC608A gerar pares de chaves, armazenar chaves privadas em seu armazenamento seguro e devolver a chave pública associada. /p>

　　Para explorar geração de chaves e outros recursos de segurança ATECC608A, os desenvolvedores podem rapidamente construir um ambiente de desenvolvimento abrangente baseado no kit de avaliação Microchip SAM D21 Xplained Pro. Baseado no Microchip ATSAMD21J18A Arm ® Cortex-M0 ® + MCU de 32 bits, o kit SAM D21 Xplained Pro oferece um driver completo de plataforma de hardware e módulo de código, suportado pelo Advanced Software Framework (ASF) da Microchip.

　　Para avaliar dispositivos de CryptoAuthentication, incluindo ATECC608A, os desenvolvedores podem simplesmente inserir a placa adicional XPRO-B CryptoAuth em uma das duas cabeças de extensão da placa Xplained Pro. A Microchip fornece software de exemplo para avaliar os recursos de segurança do CryptoAuthLib e ATECC608A. Além disso, os desenvolvedores podem inserir a placa adicional Wi-Fi Microchip ATWINC1500-XPRO em outro cabeçalho para rodar software de amostra Microchip, que demonstra o processo de autenticação mútua descrito neste artigo, incluindo autenticação de servidor TLS e de dispositivos JWT.

　　Conclusão

　　Embora a segurança de aplicações IoT envolva múltiplos requisitos, o principal desafio frequentemente está na implementação de autenticação mútua para dispositivos IoT e recursos em nuvem. Em sistemas IoT com recursos limitados, protocolos tradicionais podem exceder a memória e os recursos de processamento disponíveis. Utilizando a biblioteca CryptoAuthLib da Microchip Technology e ATECC608A IC CryptoAuthenticing, os desenvolvedores podem implementar uma abordagem mais eficiente baseada em JSON Web Tokens para conectar dispositivos IoT de forma segura aos serviços IoT do Google Cloud.