BR112020006080A2 - método e servidor de comunicações para identificação e autenticação segura de um dispositivo para uma plataforma de internet - Google Patents

Abstract

Método e servidor de comunicações para identificação e autenticação segura de um dispositivo para uma plataforma de internet, em que o método compreende realizar, por um servidor de comunicações (200), as etapas de: receber, de um dispositivo (100), uma solicitação para estabelecer uma conexão com pelo menos uma plataforma de internet (300), em que o dito dispositivo (100) coleta informações de um objeto físico; obter um endereço de IP do dispositivo (100) e validá-lo, retornando um identificador do dispositivo (100); extrair informações de rede do dispositivo (100); extrair algumas credenciais do cliente na plataforma de internet (300); e enviar ditas credenciais ao dispositivo (100) para que este último envie as ditas informações coletadas do objeto físico para a plataforma de internet (300) ou enviar, utilizando as ditas credenciais e o identificador do dispositivo (100), as informações coletadas do objeto físico acompanhadas das informações de rede obtidas para a plataforma de internet (300).

Description

MÉTODO E SERVIDOR DE COMUNICAÇÕES PARA IDENTIFICAÇÃO E AUTENTICAÇÃO SEGURA DE UM DISPOSITIVO PARA UMA PLATAFORMA DE INTERNET CAMPO DA TÉCNICA

[0001] A presente invenção se refere, de modo geral, à identificação e autenticação segura de dispositivos. Em particular, a presente invenção fornece um método e um servidor de comunicações para identificação e autenticação segura de um dispositivo para uma plataforma de internet, empregando capacidades de rede de um operador de comunicações móveis. A invenção também fornece capacidades de encaminhamento de um dado para diferentes plataformas de internet sem a necessidade de realizar alterações no firmware dos dispositivos. Além disso, é também oferecido um ponto de depuração intermediária que permite garantir onde há um problema de integração ou operação e a capacidade de enriquecimento dos dados enviados pelo dispositivo com informações conhecidas pela rede.

ANTECEDENTES DA INVENÇÃO

[0002] A presente invenção tem como base o conceito de “Computación de Frontera [Computação de Fronteira]” (descrita no artigo publicado por IEEE sob o número de acesso INSPEC: 14916986) mediante o processamento de dados adquiridos por dispositivos, em particular dispositivos loT, em uma etapa intermediária em termos de rede em relação a uma plataforma de internet, ou plataforma loT.

[0003] loT impõe um modelo de comunicação fortemente apoiado na computação em nuvem (descrita no artigo publicado por IEEE sob o número de acesso INSPEC: 14986379)

em alguns casos devido à capacidade relativamente baixa de processamento e armazenamento dos dispositivos finais, e em outros com o objetivo de simplificar a configuração, aumentar a usabilidade e aproveitar ao máximo a onipresença dos usuários em um foco tecnológico que tende a se massificar.

[0004] A Fig. 1 mostra um esquema básico de uma arquitetura baseada na computação em nuvem.

[0005] Alguns desafios são apresentados à medida que essa tendência domina as redes de comunicações com dispositivos loT de uma maneira muito acelerada. Será apresentada a seguir o estado da técnica relacionada a alguns dos desafios mais importantes.

Capacidade

[0006] O esgotamento do espaço de endereços no esquema IPV4 é um exemplo de que todo limite pode ser ultrapassado. Embora com o IPv6 tenham sido tomadas precauções para que fosse muito mais difícil ultrapassar o limite, a solução do problema, pelo menos aquela mais utilizada, foi a conversão de endereços privados em públicos e vice-versa (NAT, por suas siglas em inglês). Nesse esquema, um nó intermediário da rede é responsável por processar previamente os cabeçalhos de tráfego de IP para reduzir a pressão na demanda e a consequente alocação do universo cada vez mais escasso de endereços disponíveis.

Disponibilidade

[0007] A internet funciona sob a aplicação em camadas de vários serviços no modo de “melhor esforço”, ou seja, sem garantias quanto ao nível de serviço, e por isso não é 100 % estável ou confiável em termos de transporte. Isso significa que, inevitavelmente, os dispositivos loT encontrarão situações nas quais perderão conectividade com a plataforma de internet. Uma arquitetura baseada em Fog Computing permite que cada dispositivo loT possa lidar com essa situação. Ter um tratamento dos dados na fronteira permite ter maior resiliência à solução.

Confidencialidade

[0008] Historicamente, essa necessidade significa uma barreira à entrada dos serviços baseados na nuvem.

Integridade

[0009] A implementação de qualquer sistema de intermediação exige verificar se a integridade dos dados é mantida no caso de perda ou de possível modificação indesejada dos dados. Nesse caso, a confiança seria depositada na operadora móvel e pode ser verificada utilizando-se mecanismos de verificação ponta a ponta ou mecanismos baseados em Blockchain.

Interoperabilidade

[0010] A flexibilidade no momento de selecionar diferentes implantações de sistemas, rede, componentes plataformas de internet etc. é crítica para a sustentabilidade de qualquer solução loT, por isso é importante que as implementações sejam baseadas em arquiteturas e padrões abertos. Para tanto, criou-se oO Consórcio OpenFog com a missão de desenvolver e evoluir uma arquitetura de referência que permita aproveitar ao máximo as possibilidades oferecidas por esse paradigma computacional.

[0011] A invenção soluciona, entre outros, os seguintes problemas: - Problemas atuais nos mecanismos de fornecimento de identidade e autenticação de dispositivos:

[0012] As melhores práticas de segurança loT aplicadas a dispositivos indicam a necessidade de se dispor de credenciais individuais por dispositivo, de maneira que, se em algum momento uma determinada credencial for comprometida, essa não colocará em risco a integridade dos demais dispositivos implantados em campo.

[0013] os principais métodos utilizados atualmente estão alinhados aos métodos utilizados na internet, principalmente a criptografia simétrica (mediante chaves ou sigilos compartilhados) ou assimétrica (mediante a utilização de certificados X.509), todos estes sob uma camada de transporte seguro como TLS.

[0014] O fornecimento dessas identidades (chave compartilhada ou certificado digital) nos diferentes dispositivos é um processo complicado que muitas vezes é realizado mediante uma particularização do firmware de cada dispositivo ou um fornecimento manual. No final, esse processo se traduz em um aumento nos custos, tanto do dispositivo (pois exige um HW mais potente capaz de armazenar as credenciais de forma segura e implementar os algoritmos TLS) quanto na fabricação (etapa de personalização individual por dispositivo para fornecer a credencial individual).

[0015] Por outro lado, a gestão de identidade é realizada, em muitos casos, na plataforma loT, por exemplo, revogando credenciais do dispositivo. Isso garante que o dispositivo não tem acesso à plataforma, porém em nenhum caso impede a possibilidade de se realizar conexões com a rede móvel e que continue transmitindo sem controle.

[0016] - Problemas relacionados ao consumo de dados, energia e computação relacionados aos mecanismos de autenticação de dispositivos:

[0017] Como foi visto na seção anterior, os principais métodos utilizados atualmente estão alinhados aos métodos utilizados na internet, como por exemplo, camada de transporte TLS com certificados X.509 para autenticação.

[0018] A implementação desses mecanismos de segurança tem um forte impacto no projeto e desenvolvimento do dispositivo: . Impacto na capacidade computacional. A implementação de algoritmos de segurança tipo SSL ou TLS, incluindo a gestão de chaves, requer que o dispositivo seja mais complexo e potente, pois é necessário realizar esses processos que são geralmente bastante intensos quanto ao uso de CPU e memória.

. Impacto na transmissão de dados. Antes de iniciar uma transmissão de dados “úteis”, é necessário realizar uma série de diálogos (handshakes) encarregados de garantir a comunicação mediante autenticação mútua. Em um caso típico de TLS v.1.2 com certificados X.509, a modalidade desse tipo de handshake pode exigir a transmissão de 7 Kbytes de dados, independentemente da carga (payload) útil que se deseje transmitir posteriormente. Por exemplo, se for desejado enviar posteriormente apenas o dado de uma temperatura em formato json (“(temp: 35)”), estaríamos falando de uma razão de 10/(7*1024)=0,001 de mensagem útil em relação ao tamanho total da mensagem.

. Impacto no consumo de energia. Tanto a execução de algoritmos de certa complexidade (por exemplo, TLS) quanto a transmissão sem fio de dados, têm um forte impacto sobre o consumo de energia do dispositivo.

[0019] - Problemas atuais na Integração de Plataformas de Internet:

[0020] De modo geral, uma arquitetura típica para desenvolver uma solução loT consiste em conectar os dispositivos a uma plataforma de internet que facilite a integração dos dispositivos, provendo serviços de gestão de dispositivos e dados.

[0021] Como atualmente não há uma padronização de protocolos (incluindo payload [carga úÚútil]), este tipo de integração pode apresentar uma série de desvantagens: . Em muitos casos, as plataformas de internet não são capazes de informar se os dispositivos estão enviando dados a um endpoint [ponto final] incorreto ou se têm erros no estabelecimento da conexão. Isso dificulta o processo de integração de dispositivos às mesmas.

. A possível necessidade de migração entre uma plataforma de internet de um provedor para outra é um processo complexo que implica no fornecimento de novas credenciais por dispositivo e na implementação de uma nova integração com os protocolos disponíveis nessa plataforma.

[0022] - Problemas relacionados à complexidade, tamanho e custo dos dispositivos loT:

[0023] As soluções loT tipicamente atendem às necessidades em um mercado de massas, portanto, o custo total da solução e, portanto, o grau de penetração no mercado, dependem em grande medida do custo dos dispositivos loT. Da mesma maneira, os objetos que são conectados normalmente dispõe de um espaço limitado para os componentes que adicionarão a conectividade e o processamento local, o que impõe limitações aos componentes a serem selecionados, uma vez que, de modo geral, cada funcionalidade independente (módulo de Geolocalização, Relógio etc.) ocupa espaço e acrescenta um custo adicional à solução.

[0024] - Problemas relacionados à gestão e manutenção dos dispositivos loT:

[0025] A cardinalidade e simplicidade (no projeto) dos dispositivos loT em uma solução representa normalmente um desafio importante com relação à gestão e manutenção destes. É normal encontrar soluções nas quais o firmware é imutável ou muito difícil de atualizar e, portanto, é complicado e até impossível corrigir erros no mesmo ou acrescentar novas funcionalidades devido à dificuldade de se fazer atualizações remotas. Normalmente, é inviável (muito caro e impraticável) enviar um técnico para realizar o trabalho de cada dispositivo ou solicitar que o operador da solução o leve ou o envie a um centro de suporte ou realize a atualização sem supervisão.

REVELAÇÃO DA INVENÇÃO

[0026] Os aspectos da presente invenção fornecem um método para identificação e autenticação segura de um dispositivo, por exemplo, um dispositivo loT, para uma plataforma de internet, preferivelmente alojada na nuvem. O método compreende: a) receber, por um servidor de comunicações do dito dispositivo, uma solicitação para estabelecer uma conexão com a dita plataforma de internet, em que o dispositivo, que inclui um módulo de comunicações móveis, está associado a um cliente do servidor de comunicações mediante um identificador único de um cartão SIM, e coleta informações de um objeto físico adquiridas por um ou mais sensores, e em que o servidor de comunicações está operacionalmente conectado à plataforma de internet; b) obter, pelo servidor de comunicações, um endereço de IP do dito dispositivo e validar se o dito endereço de IP está atribuído ao cliente no servidor de comunicações, retornando, caso a validação esteja correta, um identificador do dispositivo; c) extrair, pelo servidor de comunicações, informações de rede do dispositivo a partir do endereço de IP; d) extrair, pelo servidor de comunicações, algumas credenciais do cliente na plataforma de internet; e el) enviar, pelo servidor de comunicações, as credenciais ao dispositivo para que este último envie as ditas informações coletadas do objeto físico para a plataforma de internet, em que as credenciais são utilizadas para autenticação do dispositivo antes da plataforma de internet; ou e2) enviar, pelo servidor de comunicações, utilizando as ditas credenciais e o identificador do dispositivo, as informações coletadas do objeto físico acompanhadas das informações de rede obtidas na etapa c), para a plataforma de internet.

[0027] Em um exemplo de modalidade, a solicitação recebida pelo servidor de comunicações serve para estabelecer uma conexão com uma pluralidade de plataformas de internet, em que o método compreende, na etapa e), extrair as credenciais do cliente utilizadas em cada uma da dita pluralidade de plataformas de internet; e realizar a etapa e2) simultaneamente para cada uma da pluralidade de plataformas de internet.

[0028] Em um exemplo de modalidade, o método compreende ainda receber do dispositivo, pelo servidor de comunicações, uma solicitação para estabelecer uma conexão com outra plataforma de internet; e realizar a etapa e2) para a outra plataforma de internet.

[0029] Em um exemplo de modalidade, a etapa c) compreende ainda adicionar as informações de rede extraídas às informações coletadas do objeto físico.

[0030] Em ainda outro exemplo de modalidade, o servidor de comunicações, antes da etapa a), recebe uma mensagem de texto que inclui uma chave de uso único (ou token) com uma numeração privada atribuída ao servidor de comunicações e um identificador do dito cliente, e valida a origem e o cliente da mensagem de texto. Se a origem corresponder ao cliente, o servidor de comunicações obtém as credenciais da plataforma de internet e as armazena temporariamente associadas à chave de uso único e ao identificador do cliente, de maneira que a solicitação da etapa a) nesse caso inclui ainda a chave de uso único e o identificador do cliente. O servidor de comunicações retorna as credenciais armazenadas se a chave de uso único e oO identificador do cliente recebidos na solicitação coincidirem com a chave de uso único e com o identificador do cliente associados às credenciais armazenadas ou, alternativamente, envia uma mensagem de erro ao dispositivo caso não coincidam.

[0031] A dita mensagem de erro pode compreender uma indicação que a autenticação do dispositivo é válida, mas que as credenciais ainda não estão disponíveis ou uma indicação que a autenticação do dispositivo não é válida.

[0032] De acordo com a presente invenção, as informações de rede extraídas na etapa c) podem incluir: o identificador único do cartão SIM do dispositivo, um número de identidade internacional do cliente (IMSI), um número de identidade internacional do dispositivo, por exemplo, O número IMEI ou o número MSISDN, a marca e/ou modelo do dispositivo, uma localização do dispositivo baseada em rede etc.

[0033] Aspectos da presente invenção fornecem também um servidor de comunicações para identificação e autenticação segura de um dispositivo para uma plataforma de internet. O servidor de comunicações proposto compreende: um módulo de autenticação configurado para obter, uma vez recebida de um dispositivo, preferivelmente um dispositivo loT, uma solicitação para estabelecer uma conexão com pelo menos uma plataforma de internet, um endereço de IP do dito dispositivo e validar se o endereço de IP está atribuído a um cliente do servidor de comunicações, em que o dispositivo coleta informações de um objeto físico adquiridas por um ou mais sensores; um módulo de gestão de conectividade configurado para verificar, utilizando o endereço de IP, se o dispositivo é um dispositivo legítimo e retornar um identificador do dispositivo caso esse seja um dispositivo legítimo; um módulo de enriquecimento de dados configurado para extrair informações de rede do dispositivo a partir do endereço de IP; um repositório de credenciais configurado para armazenar algumas credenciais do cliente na plataforma de internet; e um módulo adaptador de protocolos configurado para extrair as ditas credenciais do cliente e enviá-las ao dispositivo para que este último envie as ditas informações coletadas do objeto físico para a plataforma de internet ou para que envie, utilizando as credenciais e o identificador do dispositivo, as informações coletadas do objeto físico acompanhadas das informações de rede obtidas para a plataforma de internet.

[0034] Em um exemplo de modalidade, o dito módulo adaptador de protocolos é modular e está configurado para permitir uma conexão do dispositivo com uma pluralidade de plataformas de internet.

[0035] A presente invenção permite obter um menor custo no desenvolvimento da solução end2end. Graças à simplificação dos processos de fornecimento, eliminando a necessidade de distribuir credenciais individuais a cada dispositivo, a invenção permite que todos os dispositivos compartilhem o mesmo firmware e que não seja necessário particularizá-los.

[0036] Além disso, a invenção permite um menor consumo de dados, uma vez que não é necessário estabelecer uma camada adicional de transporte seguro entre os dispositivos e o servidor, pois se utiliza aquela fornecida pela rede móvel, evitando assim a necessidade de implementar o handshake SSL/TLS, e um menor consumo de energia, O que significa uma maior duração da bateria do dispositivo, pois não é necessário executar algoritmos de criptografia (SSL/TLS) e se reduz a quantidade de dados enviados por meio sem fio.

[0037] Por fim, a invenção permite reduzir também a quantidade de erros de segurança. Ao permitir que o provedor da solução loT não realize muitos dos processos críticos para a segurança da solução (por exemplo, bootstrapping da identidade, escolha do token de autenticação ou rodízio de credenciais), é menos provável que ocorra uma má configuração que comprometa a solução.

BREVE DESCRIÇÃO DOS DESENHOS

[0038] Essas e outras características e vantagens são mais plenamente compreendidas a partir da seguinte descrição detalhada de alguns exemplos de modalidade, sendo meramente ilustrativa e não limitativa, com referência aos desenhos anexos, nos quais:

[0039] A Fig. 1 mostra esquematicamente uma arquitetura baseada em computação em nuvem.

[0040] A Fig. 2 mostra esquematicamente os elementos do servidor de comunicações para identificação e autenticação segura de um dispositivo para uma plataforma de internet, de acordo com um primeiro exemplo de modalidade da presente invenção.

[0041] A Fig. 3 mostra esquematicamente a arquitetura utilizada pelo método e servidor de comunicações propostos de acordo com um segundo exemplo de modalidade da presente invenção.

[0042] A Fig. 4 mostra esquematicamente a arquitetura utilizada pelo método e servidor de comunicações propostos de acordo com um terceiro exemplo de modalidade da presente invenção.

DESCRIÇÃO DETALHADA DA INVENÇÃO E DE ALGUNS EXEMPLOS DE MODALIDADE

[0043] A presente invenção fornece identificação e autenticação segura de dispositivos loT 100 para conexão a plataformas de internet, ou plataformas loT 300, geralmente localizadas na nuvem, empregando capacidades de rede de um operador de comunicações móveis.

[0044] Dentro da arquitetura típica de 1loT, utilizando como modelo de referência aquele proposto na Recomendação ITU-T Y.2060, figura 4, a presente invenção está localizada na camada de rede (“Network Layer”), dentro de capacidades de rede (“Network Capabilities”), servindo como ligação com a camada de suporte a serviços e aplicações (“Service support and Application support layer”).

[0045] A invenção oferece três funcionalidades principais: . Roteamento das informações para diferentes plataformas de internet 300: a invenção fornece um ponto de roteamento, por meio de um servidor de comunicações 200, para diferentes plataformas de internet 300. Dessa forma, permite- se que o usuário realize uma única integração simples, pois os dispositivos 100 são autenticados mediante as informações disponíveis na rede, não sendo necessário o fornecimento de credenciais.

. Gestão de credenciais de autenticação de plataformas de internet 300: a invenção permite gerir, fora do dispositivo 100, as credenciais de autenticação com a plataforma de internet 300, de forma que todos os dispositivos 100 possam compartilhar o mesmo firmware de fábrica, não sendo necessários processos manuais de fornecimento de identidade.

. Enriquecimento das informações com informações de rede: a invenção permite enriquecer as informações que oO dispositivo 100 fornece na plataforma de internet 300 com informações de rede, como ICCID, MSISDN ou IMEI do dispositivo 100.

[0046] - Roteamento das informações para diferentes plataformas de internet:

[0047] Atualmente, desde a fase de projeto, o software do dispositivo 100 escolhe a plataforma de internet 300 para a qual envia os dados e tem definidos tanto o servidor de destino quanto as credenciais que devem ser empregadas com este. Essa situação limita a possibilidade de migração entre provedores de plataformas de internet 300, já que, apesar de empregar protocolos comuns (MQOTT, HTTP), são utilizados diferentes métodos de autenticação que impossibilitam ao provedor de uma solução loT migrar entre plataformas sem precisar modificar significativamente o firmware de todos os seus dispositivos. Somente as soluções loT baseadas em conectividade LPWA no IP, como SIGFOX ou LORA, por não terem no dispositivo 100 a possibilidade de integração com a maioria das plataformas de internet 300, oferecem na infraestrutura do operador de comunicações à possibilidade de rotear os dados para uma ou outra plataforma. No entanto, para as soluções loT que empregam conectividade celular 2G, 3G, 41G e que dispõem de conectividade IP, não há na infraestrutura do operador de comunicações nenhum mecanismo para selecionar a plataforma loT de destino.

[0048] Em vez disso, a invenção permite ao provedor de uma solução loT integrar seus dispositivos 100 unicamente ao servidor de comunicações 200. A partir desse momento, o provedor da solução loT pode utilizar uma interface de administração do servidor de comunicações 200 para poder encaminhar as informações de seus dispositivos 100 para a plataforma de internet 300 que desejar. Para tanto, é necessário que os dispositivos 100 utilizem um protocolo padrão (MQOTT, HTTP), mas sem tenham que usar credenciais específicas da plataforma de internet 300 de destino. Dessa forma, o provedor da solução loT poderá selecionar uma ou várias plataformas de internet de destino 300 que deseje, sem a necessidade de realizar nenhuma alteração no software de seus dispositivos 100. Além disso, a incorporação de novas plataformas de internet 300 ou as alterações nas atuais também serão realizadas de forma centralizada, sem a necessidade de alterações nos dispositivos.

[0049] - Gestão de credenciais de autenticação de plataformas de internet:

[0050] Atualmente, a gestão de credenciais dos dispositivos 100 deve ser realizada pelo provedor da solução loT interagindo diretamente sobre os dispositivos 100. Essa gestão da identidade implica diversas decisões de projeto e operações de gestão que o provedor da solução deve realizar, entre elas: . Geração de um token de identidade: em muitas ocasiões as plataformas de internet 300 deixam sob a responsabilidade do provedor da solução loT a geração do token de identidade que permite autenticar um dispositivo

100. Esse token pode ser um sigilo compartilhado, um token temporal derivado de um sigilo compartilhado ou um certificado —“X.509. Nem todas as organizações têm o conhecimento e os processos para gerar e gerir de forma segura esses tokens de identidade. Isso pode fazer com que os esses tokens sejam previsíveis, que não sejam geridos de forma segura e que possam vazar ou até serem comuns para toda a base de dispositivos.

. Fornecimento do token de identidade: a distribuição desses tokens de identidade é outro processo delicado fora do alcance das plataformas de internet 300 e que envolve uma decisão crítica de projeto para o provedor da solução loT. Isso muitas vezes faz com que o token de identidade seja fornecido manualmente no dispositivo 100, seja nele armazenado de forma insegura ou ainda mantido em um armazenamento permanente que não permite seu rodízio em caso de suspeita ou confirmação de que o token de identidade foi comprometido.

[0051] Além disso, é possível que, devido às limitações de recursos técnicos no dispositivo 100, não seja possível realizar um procedimento seguro de geração e fornecimento desses tokens de identidade no dispositivo 100, impossibilitando uma gestão segura dessa identidade, embora a organização tenha os recursos e o conhecimento para fazê-lo.

[0052] Por isso, a invenção permite que oO provedor de uma solução loT não tenha que realizar os processos de geração e fornecimento do token de identidade. Isso não apenas reduz o esforço dedicado a essas operações de interação com o dispositivo 100, mas também evita os riscos de segurança associados à sua execução insegura. O provedor da solução não precisa gerar um token de identidade pelo dispositivo 100 que seja dependente da plataforma de internet 300 de destino, pois se utiliza a identidade na rede celular do dispositivo 100.

[0053] Quando um dispositivo 100 se conecta à rede celular e estabelece um contexto de dados para ter conectividade IP, o GGSN da rede celular atribui a ele um endereço de IP. O provedor de comunicações sabe a todo momento a identidade na rede celular (MSISDN, IMSI), a identidade do dispositivo utilizado (IMEI) e a identidade do cartão SIM utilizado (ICCD) para esse contexto de dados. Dessa forma, a partir do endereço de IP de origem do dispositivo 100, o provedor de comunicações pode conhecer a identidade em rede do dispositivo 100 e, dessa forma, convertê-la na identidade adequada na plataforma de internet 300 de destino selecionada pelo provedor da solução loT. Para realizar essa conversão, é necessário que o servidor de comunicações 200 tenha acesso às informações de sinalização da rede, bem como às credenciais de conexão com a plataforma de internet 300 de destino que permite a gestão de identidades de dispositivos 100.

[0054] É importante ressaltar que a invenção não é vulnerável às técnicas de IP spoofing [mMascaramento de IP], já que em uma rede celular GGSN, ainda que um dispositivo 100 modifique seu endereço de IP e envie os pacotes com um endereço diferente daquele atribuído, os pacotes nunca serão enviados de volta ao dispositivo 100 malicioso. Sempre se considera o uso de protocolos que necessitam de conexão (HTTP, MOTT), por meio do qual a fase de handshake não poderá ser concluída em caso de mascaramento de IP.

[0055] - Enriquecimento das informações com informações de rede:

[0056] Às vezes, é necessário conhecer as informações de rede, por exemplo, ICCID do cartão SIM, IMSI,

IMEI do dispositivo 100, marca e modelo do dispositivo 100 ou localização deste baseada em rede. Essas informações podem ser úteis para identificar o dispositivo físico que está conectado e, por exemplo, realizar verificações de segurança que impeçam que um cartão SIM seja introduzido em um dispositivo 100 não autorizado. Atualmente, os dispositivos 100 devem incorporar, caso seja necessário para a aplicação, informações sobre a rede celular e sobre os parâmetros de rede do dispositivo 100. Isso implica na comunicação entre o software de dispositivo e o módulo de comunicações, o que nem sempre é simples de se obter.

[0057] A invenção permite que o provedor de uma solução loT não precise realizar o desenvolvimento no software do dispositivo 100 necessário para obter essas informações do módulo de comunicações. Adicionalmente, oO envio dessas informações a partir do dispositivo 100 implica em um consumo adicional de dados e, portanto, de bateria, oO que não é necessário graças à invenção. Essa melhora é particularmente interessante no caso em que é necessário utilizar as informações de rede para obter as informações finais, por exemplo, no caso de resolver a localização, é necessário empregar o LAC e o CellID que conhecem o módulo de comunicações, e consultar um serviço adicional de um terceiro para resolvê-lo. O mesmo é necessário quando se deseja resolver o nome do fabricante do módulo e o modelo a partir do IMEI.

[0058] Com referência agora à Fig. 2, a mesma mostra um esquema dos diferentes módulos do servidor de comunicações 200 para permitir a identificação e autenticação segura de um dispositivo 100 para uma plataforma de internet

300. O servidor de comunicações 200 consiste principalmente em: . Um módulo adaptador de protocolos 204: Esse elemento é responsável por realizar a conexão com a plataforma de internet 300 e enviar os dados recebidos do dispositivo 100. Vale destacar que esse elemento absorve a complexidade e evolução das APIS de plataforma 300 de destino, liberando o dispositivo 100 de realizar atualizações de software para se adaptar a elas. A principal tarefa assumida é gerenciar a autenticação com a plataforma de internet 300 de destino, dessa forma, caso exija uma criptografia complexa ou autenticação mútua baseada em certificados digitais X.509, o dispositivo 100 não precisa se preocupar com essa tarefa. Isso leva a uma redução significativa na capacidade dos recursos de hardware necessários no dispositivo 100 e no consumo de dados que o dispositivo deve enviar para realizar, por exemplo, um handshake TLS.

[0059] O adaptador de protocolos 204 é capaz de trocar a plataforma de internet 300 de destino de forma transparente para o dispositivo 100, bem como enviar os dados a várias plataformas 300 simultaneamente com um único envio de informações pelo dispositivo 100.

[0060] O projeto desse módulo 204 é preferivelmente modular, e dessa forma permite a conexão com diferentes provedores de plataforma de internet 300 com diferentes protocolos relevantes, por exemplo, HTTP, MQTT e COAP.

[0061] As credenciais empregadas na conexão com a plataforma de internet 300 serão obtidas de um repositório de credenciais 205 do servidor de comunicações 200.

. Um módulo de enriquecimento de dados 203: Esse elemento é responsável por ampliar as informações enviadas pelo dispositivo 100 com dados disponíveis na rede, por exemplo: ICCID do cartão SIM, IMSI, IMEI do dispositivo 100, marca e modelo do dispositivo 100 ou localização deste baseada em rede etc. Essas informações estão disponíveis em um módulo de gestão de conectividade 202 e podem ser consultadas a partir do IP recebido do dispositivo 100.

. Um módulo de autenticação 201 (de rede): Esse elemento é responsável por verificar a identidade do dispositivo 100 e permitir sua conexão para o envio de dados para a plataforma de internet 300. Esse elemento emprega o IP recebido na solicitação enviada pelo dispositivo 100 e consultará o módulo de gestão de conectividade 202. A autenticação será satisfatória sempre que o módulo de gestão de conectividade 202 reconhecer o IP do dispositivo 100 como válida para o cliente.

. Repositório de Credenciais 205: Esse elemento é responsável por manter a relação entre a identidade de rede do dispositivo 100 que conhece o módulo de gestão de conectividade 202 e a identidade atribuída pelo cliente na plataforma de internet 300.

. Módulo de gestão de conectividade 202: Esse elemento é responsável por gerir o ciclo de vida da conectividade do dispositivo 100 e conhece todas as informações de rede relativas a ele, por exemplo: IP atribuído, ICCID do cartão SIM, IMSI, IMEI do dispositivo 100, marca e modelo do dispositivo ou localização deste baseada em rede com base na rede. Deve-se permitir uma consulta dessas informações de rede a partir do endereço de IP atribuído ao dispositivo 100.

[0062] Por outro lado, o dispositivo 100 é um dispositivo do cliente do servidor de comunicações 200 que é responsável por coletar informações de um objeto ao qual está conectado (por exemplo, um veículo, uma lavadora ou um localizador, entre outros) a partir de sensores e certa capacidade de processamento para enviá-los para a plataforma de internet 300. Além disso, o dispositivo 100 pode dispor de capacidades de atuação que o permitem realizar determinadas ações sobre o objeto conectado, recebendo comandos da plataforma de internet 300. O dispositivo 100 dispõe de um módulo de comunicações móveis que emprega um cartão ICC como mecanismo de autenticação do cliente com a rede e que é conhecido pelo módulo de gestão de conectividade 202 no processo de conexão à mesma.

[0063] Com referência à plataforma de internet 300, esse elemento é o responsável por armazenar os dados coletados pelo dispositivo 100 e oferecê-los a uma aplicação

301. Esse elemento mantém uma identidade do dispositivo 100 para o qual oferece algumas credenciais individuais que são armazenadas no repositório de credenciais 205. A aplicação 301 é responsável por apresentar ao cliente as informações coletadas pelo dispositivo 100 na plataforma de internet 300 e por gerar os comandos de ação sobre o mesmo.

[0064] Em um exemplo de modalidade, o fluxo de envio de dados desde o dispositivo 100 até a plataforma de internet 300 é o seguinte. O dispositivo 100 envia uma solicitação ao módulo de autenticação 201 sem nenhum tipo de credencial de autenticação por meio de uma rede móvel ou celular. O módulo de autenticação 201 obtém o endereço de IP da solicitação recebida e consulta o módulo de gestão de conectividade 202 para validar se esse endereço de IP foi atribuído pela rede celular a um dispositivo 100 do cliente. O módulo de gestão de conectividade 202, a partir do endereço de IP consultado, confirma se a solicitação é proveniente de um dispositivo 100 legítimo e retorna um identificador do dispositivo 100 (por exemplo, o IMSI do ICC do dispositivo 100). Caso contrário, retornará um erro e a solicitação não prosseguirá. Então, o módulo de autenticação 201 encaminha a solicitação do dispositivo 100 para módulo de enriquecimento de dados 203 e esse solicita ao módulo de gestão de conectividade 202 as informações de rede disponíveis a partir desse dispositivo 100, por exemplo: ICCID do cartão SIM, IMSI, IMEI do dispositivo, marca e modelo do dispositivo ou localização deste baseada em rede. O enriquecedor de dados 203 encaminha a solicitação do dispositivo 100 enriquecida com as informações de rede obtidas ao módulo adaptador de protocolos 204, o qual adapta a solicitação ao protocolo de destino da plataforma de internet 300. O módulo adaptador de protocolos 204 consulta o repositório de credenciais 205 para obter as credenciais adequadas ao protocolo de destino acompanhadas da identidade do dispositivo 100 na plataforma

300. Na ausência dessas informações localmente, o módulo adaptador 204 deve ser capaz de interagir com a plataforma de internet 300 para registrar o dispositivo 100 ou recuperá-las caso já estejam registradas. O módulo adaptador de protocolos 204 envia os dados do dispositivo 100 acompanhados das informações de rede do módulo de enriquecimento de dados 203 e das credenciais adequadas para a plataforma de internet

300. Por fim, a aplicação 301 recupera os dados da plataforma de internet 300 e os apresenta de forma adequada ao usuário final.

[0065] Com referência agora à Fig. 3, a mesma mostra um segundo exemplo de modalidade da invenção. Nesse caso, oO servidor de comunicações é utilizado como broker [corretor] de credenciais. Nesse exemplo de modalidade, o dispositivo 100 mantém a conexão direta com a plataforma de internet 300 utilizando um serviço exposto pelo servidor de comunicações 200 para obter as credenciais na dita plataforma de internet 300 utilizando para tanto a identificação e autenticação fornecidas pela rede.

[0066] O módulo de autenticação 201, depois de obter e validar a identidade e a autenticação por meio do módulo de conectividade 202 de forma análoga ao exemplo anterior de modalidade, obtém as credenciais para o dito dispositivo 100 na plataforma de internet 300 através do módulo adaptador de protocolos 204 e as fornece ao dispositivo 100 para seu uso posterior. O dispositivo 100, em caso de erro de autenticação em sua comunicação com a plataforma 300, iniciará uma nova solicitação ao módulo de autenticação 201 para renovar suas credenciais. Mediante esse mecanismo, atinge-se igualmente o objetivo principal da presente invenção, a saber, implantar um único firmware de fábrica em todos os dispositivos 100 e evitar a posterior instalação manual dos certificados necessários para a comunicação segura com a plataforma de internet 300 escolhida.

[0067] Essa alternativa permite manter uma conexão direta, sem pontos intermediários, entre o dispositivo 100 e a plataforma de internet 300, o que reduz a complexidade da operação. Além disso, a criptografia da comunicação é implementada ponta a ponta desde o dispositivo 100 até a plataforma 300.

[0068] Ao contrário, como principais inconvenientes, a conexão do dispositivo 100 com a plataforma de internet 300 exige algumas capacidades mínimas de computação para a criptografia da comunicação no lado do dispositivo 100, o que exclui muitos dispositivos 100 de baixo custo utilizados em uma ampla variedade de casos de uso, por exemplo, medidores inteligentes. Além disso, o uso de criptografia ponta a ponta desde o dispositivo 100 exige um maior consumo de largura de banda móvel, bem como uma menor duração da bateria. Se o usuário desejar trocar de plataforma de internet 300, é necessário reprogramar O dispositivo 100 com a interface da nova plataforma de internet 300 caso não sejam utilizados APIS padrão nas mesmas. Essa alternativa não permite enriquecer automaticamente as informações enviadas para a plataforma de internet 300 com informações de rede.

[0069] Com referência agora à Fig. 4, a mesma mostra um terceiro exemplo de modalidade da invenção. Nesse caso, o servidor de comunicações é utilizado como broker de credenciais com autenticação por uma mensagem de texto. O dispositivo 100 continua mantendo a conexão direta com a plataforma de internet 300, incluindo, nesse caso, o servidor de comunicações 200 para um módulo de serviço por SMS 206 a fim de identificar e autenticar ao dispositivo 100 antes da obtenção das credenciais na plataforma de internet 300.

[0070] Nesse caso, o dispositivo 100 envia uma mensagem de texto, preferivelmente uma mensagem SMS, através do módulo de serviço por SMS 206 incluindo, como conteúdo, um token temporal de uso único (ou chave de uso único), bem como um identificador do cliente no módulo de gestão de conectividade 202 e uma numeração privada (shortcode [código curto]) atribuída ao servidor de comunicações 200. É importante o uso de numeração privada, e não pública, para evitar ataques por mascaramento de SMS, nos quais poderiam chegar ao módulo de serviço por SMS 206 mensagens de redes externas, não confiáveis, com a origem da mensagem modificada. Em quaisquer dos casos, podem ser colocados em funcionamento todos os mecanismos disponíveis na operadora para evitar a chegada de SMS com origem não confiável ao módulo de serviço por SMS 206. Por outro lado, o token contido na mensagem SMS preferivelmente possui um número mínimo de caracteres para evitar colisões entre solicitações de diferentes dispositivos 100, é temporário, tendo uma duração de poucos minutos, e é de uso único.

[0071] O módulo de serviço por SMS 206 encaminha a mensagem recebida (incluindo o conteúdo e a origem da mesma) para o módulo de autenticação 201, validando então a origem e o cliente no módulo de gestão de conectividade 202 de forma análoga aos casos anteriormente descritos. Se a origem pertencer ao inventario do cliente, as credenciais são obtidas na plataforma de internet 300 e são temporariamente armazenadas associadas ao token gerado pelo dispositivo 100 e ao identificador do cliente contidos na mensagem SMS. Decorrido um tempo de espera estabelecido, o dispositivo 100 realiza uma solicitação HTTPS para descarregar as credenciais na plataforma de internet 300, inclusive na dita solicitação do token e do identificador de cliente. Se houver credenciais para a dita dupla, essas são devolvidas na solicitação HTTPS. Caso contrário, podem ser retornados os seguintes códigos de erro: o Processo de autenticação válido, porém credenciais ainda não disponíveis: 404 Not Found o Processo de autenticação inválido: 403 Forbidden

[0072] De forma análoga ao que foi descrito no segundo exemplo de modalidade, o dispositivo 100, em caso de erro de autenticação em sua comunicação com a plataforma de internet 300, iniciará um novo processo para a renovação de suas credenciais seguindo os passos citados anteriormente.

[0073] Esse terceiro exemplo de modalidade é baseado em funcionalidades padrão da rede móvel, uma vez que é baseado na autenticação do módulo de serviço por SMS 206 em vez de nos procedimentos proprietários de autenticação em rede de cada operadora: identificação através do IP privado do dispositivo 100 na rede celular ou adição de cabeçalhos HTTP por redes proxy transparentes. Além disso, são eliminados os problemas com os NATs que, em alguns casos de uso, podem ocultar o IP privado do dispositivo 100, impedindo sua identificação no módulo de autenticação 201.

[0074] Por outro lado, esse exemplo de modalidade apresenta algumas limitações ou inconvenientes. A validação mediante o módulo de serviço por SMS 206 introduz uma comunicação assíncrona, necessitando de um tempo de espera variável prévio para a recuperação das credenciais por parte do dispositivo 100. Isso obriga a configurar, no dispositivo 100, um tempo de espera superior ao estimado e a programar procedimentos de recuperação caso as credenciais não estejam disponíveis no dito tempo.

[0075] Do mesmo modo, não há uma confirmação para o dispositivo 100 do processo de autenticação iniciado com a mensagem SMS. O dispositivo 100 somente pode comprovar o estado da autenticação mediante a consulta HTTPS ao módulo de autenticação 201 que o retornará as credenciais quando finalizado. A confirmação do processo de autenticação poderia ser habilitada com uma mensagem SMS de retorno originada no módulo de autenticação 201 com destino ao dispositivo 100, incluindo, como conteúdo, o token, o identificador de cliente e o resultado da autenticação.

[0076] Um versado na técnica poderia introduzir alterações e modificações nos exemplos de modalidade descritos sem sair do escopo da invenção conforme definido nas reivindicações anexas.

Claims (12)

REIVINDICAÇÕES

1. MÉTODO PARA IDENTIFICAÇÃO E AUTENTICAÇÃO SEGURA DE UM DISPOSITIVO PARA UMA PLATAFORMA DE INTERNET, caracterizado por compreender: a) receber, por um servidor de comunicações (200), de um dispositivo (100), uma solicitação para estabelecer uma conexão com pelo menos uma plataforma de internet (300), em que o dito dispositivo (100), que inclui um módulo de comunicações móveis, está associado a um cliente do servidor de comunicações (200) mediante um identificador único de um cartão SIM inserido no dito dispositivo (100), e coleta informações de um objeto físico adquiridas por um ou mais sensores, e em que o servidor de comunicações (200) está operacionalmente conectado à plataforma de internet (300), que é pelo menos uma; b) obter, pelo servidor de comunicações (200), um endereço de IP do dito dispositivo (100) e validar se o dito endereço de IP está atribuído ao cliente no dito servidor de comunicações (200), retornando, caso a validação esteja correta, um identificador do dispositivo (100); c) extrair, pelo servidor de comunicações (200), informações de rede do dispositivo (100) a partir do endereço de IP; d) extrair, pelo servidor de comunicações (200), algumas credenciais do cliente na plataforma de internet (300); e el) enviar, pelo servidor de comunicações (200), as ditas credenciais ao dispositivo (100) para que este último envie as ditas informações coletadas do objeto físico para a plataforma de internet (300), em que as credenciais são utilizadas para autenticação do dispositivo (100) antes da plataforma de internet (300); ou e2) enviar, pelo servidor de comunicações (200), utilizando as ditas credenciais e o identificador do dispositivo (100), as informações coletadas do objeto físico, acompanhadas das informações de rede obtidas na etapa c), para a plataforma de internet (300).

2. MÉTODO, de acordo com a reivindicação 1, caracterizado pela solicitação recebida pelo servidor de comunicações (200) servir para estabelecer uma conexão com uma pluralidade de plataformas de internet (300), em que o método compreende: na dita etapa d), extrair as credenciais do cliente utilizadas em cada uma da dita pluralidade de plataformas de internet (300); e realizar a dita etapa e2) simultaneamente para cada uma da pluralidade de plataformas de internet (300).

3. MÉTODO, de acordo com a reivindicação 1, caracterizado por compreender ainda: receber do dispositivo (100), pelo servidor de comunicações (200), uma solicitação para estabelecer uma conexão com outra plataforma de internet (300); e realizar a dita etapa e2) para a outra plataforma de internet (300).

4. MÉTODO, de acordo com a reivindicação 1, caracterizado pela etapa c) compreender ainda adicionar as informações de rede extraídas às informações coletadas do objeto físico.

5. MÉTODO, de acordo com a reivindicação 1,

caracterizado por compreender ainda: receber, antes da dita etapa a), pelo servidor de comunicações (200), uma mensagem de texto que inclui uma chave de uso único com uma numeração privada atribuída ao servidor de comunicações (200) e um identificador do dito cliente; e validar, pelo servidor de comunicações (200), a origem e o cliente da dita mensagem de texto, em que, se a origem corresponder ao dito cliente, o servidor de comunicações (200) obtém as credenciais da plataforma de internet (300) e as armazena temporariamente associadas à chave de uso único e ao identificador do cliente, de maneira que a solicitação da etapa a) inclui ainda a chave de uso único e o identificador do cliente, e o servidor de comunicações (200) retorna as credenciais armazenadas se a chave de uso único e o identificador do cliente recebidos na solicitação coincidirem com a chave de uso único e com o identificador do cliente associados às credenciais armazenadas ou envia uma mensagem de erro ao dispositivo (100) caso não coincidam.

6. MÉTODO, de acordo com a reivindicação 5, caracterizado pela mensagem de erro compreender: uma indicação que a autenticação do dispositivo (100) é válida, mas que as credenciais ainda não estão disponíveis; ou uma indicação que a autenticação do dispositivo (100) não é válida.

7. MÉTODO, de acordo com qualquer uma das reivindicações 1 a 6, caracterizado pelas informações de rede extraídas na etapa c) incluírem pelo menos um entre: o identificador único do cartão SIM do dispositivo (100), um número de identidade internacional do cliente, ou número IMSI ou MSISDN, um número de identidade internacional do dispositivo (100), ou número IMEI, a marca e/ou modelo do dispositivo (100), ou uma localização do dispositivo (100) baseada em rede.

8. MÉTODO, de acordo com a reivindicação 1, caracterizado pelo dispositivo (100) ser um dispositivo loT e a plataforma de internet (300) está alojada na nuvem.

9. SERVIDOR DE COMUNICAÇÕES PARA IDENTIFICAÇÃO E

AUTENTICAÇÃO SEGURA DE UM DISPOSITIVO PARA UMA PLATAFORMA DE INTERNET, caracterizado por compreender: um módulo de autenticação (201) configurado para obter, uma vez recebida de um dispositivo (100), uma solicitação para estabelecer uma conexão com pelo menos uma plataforma de internet (300), um endereço de IP do dito dispositivo (100) e validar se o dito endereço de IP está atribuído a um cliente do servidor de comunicações (200), em que o dito dispositivo (100), que inclui um módulo de comunicações móveis, está associado ao dito cliente mediante um identificador único de um cartão SIM inserido no dispositivo (100), e coleta informações de um objeto físico adquiridas por um ou mais sensores; um módulo de gestão de conectividade (202) configurado para verificar, utilizando o endereço de IP, se o dispositivo (100) é um dispositivo legítimo e retornar um identificador do dispositivo (100) caso esse seja um dispositivo legítimo; um módulo de enriquecimento de dados (203) configurado para extrair informações de rede do dispositivo

(100) a partir do endereço de IP; um repositório de credenciais (205) configurado para armazenar algumas credenciais do cliente na plataforma de internet (300); e um módulo adaptador de protocolos (204) configurado para extrair as ditas credenciais do cliente e enviá-las ao dispositivo (100) para que este último envie as ditas informações coletadas do objeto físico para a plataforma de internet (300) ou para que envie, utilizando as ditas credenciais e o identificador do dispositivo (100), as informações coletadas do objeto físico acompanhadas das informações de rede obtidas para a plataforma de internet (300).

10. SERVIDOR DE COMUNICAÇÕES, de acordo com a reivindicação 9, caracterizado pelo dito módulo adaptador de protocolos (204) ser modular e está configurado para permitir uma conexão do dispositivo (100) com uma pluralidade de plataformas de internet (300).

11. SERVIDOR DE COMUNICAÇÕES, de acordo com a reivindicação 9, caracterizado pelas informações de rede extraídas incluírem pelo menos um entre: o identificador único do cartão SIM do dispositivo (100), um número de identidade internacional do cliente, ou número IMSI ou MSISDN, um número de identidade internacional do dispositivo (100), ou número IMEI, a marca e/ou modelo do dispositivo (100), ou uma localização do dispositivo (100) baseada em rede.

12. SERVIDOR DE COMUNICAÇÕES, de acordo com qualquer uma das reivindicações 9 a 11, caracterizado por compreender ainda um módulo de serviço por SMS (206)

configurado para receber uma mensagem de texto que inclui uma chave de uso único com uma numeração privada atribuída ao servidor de comunicações (200) e um identificador do dito cliente.