Sumário de Comparações

3.2

Sumário de Comparações

Tendo como base as diversas soluções apresentadas na Seção 3.1, a presente seção tem como foco a realização de um comparativo entre essas soluções. O comparativo será realizado en- tre as seguintes soluções de middleware: Hermes, Prisma, Ubiware, Impala, Hydra, SOCRADES, TinyDBe GNS. Como parâmetros de classificação foram utilizados os principais componentes funcionais e não funcionais necessários a uma solução de middleware para IoT apresentados em Bandyopadhya (BANDYOPADHYAY et al.(2011)) e Mohammad (RAZZAQUE et al.(2016)).

Tabela 3.5 Comparação entre Soluções de Middleware para IoT

3.3

Considerações Finais

Este capítulo apresentou os principais trabalhos relacionados ao contexto de Middleware para IoT. Foram apresentadas as principais características que uma solução de middleware para Internet das Coisas deve possuir. Também foram abordados as possíveis arquiteturas de middleware(primitivas de comunicações) compatíveis com o paradigma de IoT.

Foi realizado um paralelo entre as soluções de middleware para Internet das Coisas, considerando os desafios a serem solucionados no contexto de IoT. Posteriormente, foram apresentadas as principais soluções de Middleware atualmente existentes para IoT e classificadas em grupos conforme suas características de funcionamento.

39 39 39

4

Middleware xPresumo

Neste capítulo será apresentado o Middleware xPresumo, que é um MOM desenvol- vido para o contexto de IoT. Serão apresentados os requisitos, a arquitetura, o projeto de desenvolvimento e suas características, além da implementação da solução.

4.1

Requisitos

Com um tamanho inferior a 500 KB (quilobyte), o middleware xPresumo é uma solu- ção que foi desenvolvida tendo como base as características essenciais à uma arquitetura de Middlewarepara Internet das Coisas, procurando associar os recursos necessários e o melhor desempenho. Os requisitos dos xPresumo foram definidos com base nos estudos apresentados por Bandyopadhya (BANDYOPADHYAY et al.(2011)), Whitmore (WHITMORE; AGARWAL; DA XU(2014)), Mohammad (RAZZAQUE et al.(2016)) e Miorandi (MIORANDI et al.(2012)).

Assim, os principais requisitos para a solução em questão são:

 Heterogeneidade: Uma das principais características em sistemas distribuídos e

necessário ao contexto de IoT. Devido à diversidade de dispositivos conectados em ambientes inteligentes, o xPresumo atua para que a comunicação ocorra de maneira simplificada, ou seja, de maneira padronizada.

 Segurança: Em ambientes onde inúmeros dispositivos compartilham todo tipo de

informações, é de fundamental importância a adoção de mecanismos de segurança que visem dificultar a manipulação de informações sem a devida autorização. O xPre- sumoprovê confidencialidade e integridade das informações por meio de criptografia simétrica. O módulo de segurança do xPresumo conta com dois mecanismos: de autenticação de dispositivos e de criptografia das mensagens trocadas entre dispositi- vos.

 Descoberta e Localização de Dispositivos: Outro requisito essencial no cenário de

IoT é na capacidade de localização e descoberta de dispositivos. O xPresumo conta com o recurso de localização e descoberta baseados em Received Signal Strength

4.2. ARQUITETURA 40 Indicator(RSSI), ou seja, estimativa de posicionamento baseada na intensidade do sinal sem fio transmitido por estações base.

 Ciência de Contexto e Adaptabilidade: Sabendo da dinamicidade encontrada em

ambientes de IoT, muitos dispositivos podem sofrer alterações necessárias para seu funcionamento adequado. Pensando nisso, o xPresumo possui a capacidade de adaptar o uso de criptografia conforme o nível de bateria dos dispositivos conectados. Conforme a bateria de determinado dispositivo atingi um nível crítico de energia, é necessário que a comunicação entre dispositivos seja modificada; mensagens que antes eram enviadas criptografadas, agora devem trafegar em seu formato original.

 Gerenciamento de Eventos: São muitos os eventos gerados em Internet das Coisas. É

necessário que o grande volume de dados produzido pelos dispositivos conectados sejam registrados para possíveis análises futuras. Sendo assim, o xPresumo possui um módulo responsável pelo armazenamento desses eventos em uma base de dados orientada a documentos (estrutura Not Only SQL (NoSQL) de coleções de atributos e valores).

Nas próximas seções serão apresentadas as demais etapas de desenvolvimento do xPre- sumo, além de maiores detalhes funcionais sobre os requisitos em relação à arquitetura.

4.2

Arquitetura

O xPresumo foi desenvolvido com base na arquitetura do Middleware Presumo (Seção 2.4), um servidor de mensagens baseado na API JMS. Optou-se pelo desenvolvimento de uma solução de middleware utilizando a API JMS considerando o mecanismo de troca de mensagens assíncronas, o mais indicado no contexto de IoT para notificações de eventos ou mesmo a troca de informações entre dispositivos. O xPresumo é uma extensão da arquitetura do Presumo, ou seja, as camadas de Distribuição e Infraestrutura foram utilizadas para estender a camada de Serviços do xPresumo. Foram necessárias algumas adaptações nas camadas de Distribuição e Infraestrutura para o correto funcionamento do xPresumo.

O Middleware xPresumo pode ser configurado de modo simples seguindo o modelo cliente-servidor, onde vários clientes se conectam a um servidor, ou mesmo adotar uma topologia mais complexa, ou seja, múltiplos servidores xPresumo conectados entre si (Figura 4.1). Nessa última topologia, os servidores ficam encarregados de encaminhar as mensagens destinadas àqueles clientes interessados em determinados tópicos.

O desenvolvimento da solução se deu utilizando o padrão de projeto Observer, também conhecido como Publish-SubscribeGAMMA et al.(1994). Em diversas situações, um ou mais dispositivos terão interesse em determinado assunto, sendo esta, a razão por adotar o modelo Publish-Subscribeao invés do modelo Point-to-point.

4.2. ARQUITETURA 41

Figura 4.1 Topologia com Vários xPresumo Conectados

O funcionamento do padrão Observer consiste basicamente em estabelecer o relaciona- mento entre objetos-chave denominados observer (observador) e subject (assunto). Os subjects produzem conteúdo e os publicam, os observers, que implementam a interface Listener, seriam os assinantes desses conteúdos, recebendo notificações a cada nova publicação.

Uma visão conceitual da arquitetura do xPresumo pode ser observada na Figura 4.2. A arquitetura do xPresumo é dividida em três camadas: infraestrutura, distribuição e serviços.

Figura 4.2 Arquitetura do Middleware xPresumo

A camada de infraestrutura é responsável pelo encapsulamento das primitivas de comuni- cação a nível de S.O. entre o transmissor e o receptor. Já a camada de distribuição tem a função de gerenciar as filas de mensagens do middleware, assegurando a troca de mensagens entre as camadas de infraestrutura e de serviços.

4.2. ARQUITETURA 42 contexto de IoT. A referida camada conta com os seguintes serviços: Localização e Descoberta, Ciência de Contexto, Gerenciamento de Eventos e Segurança.

Os serviços de Localização e Descoberta de dispositivos são características fundamentais em uma solução de Middleware para Internet das Coisas devido a mobilidade das coisas. A localização geográfica de determinado dispositivo é realizada baseando-se na intensidade do sinal (RSSI) em relação aos Access Point (AP) fixos. Optou-se pelo recurso de localização baseado em RSSI devido o sinal do Sistema de Posicionamento Global (GPS) ser de baixa qualidade na maioria dos ambientes indoor.

O serviço de Localização de dispositivos retorna a localização geográfica do próprio dispositivo solicitante. O serviço de Descoberta é responsável por informar à um determinado dispositivo a localização geográfica de um outro dispositivo dentro da mesma estrutura física.

A Ciência de Contexto é outro recurso fundamental ao paradigma de Internet das Coisas. No xPresumo, o serviço relativo à Ciência de Contexto tem como finalidade analisar o nível de energia dos dispositivos portadores de bateria e reagir conforme as necessidades de mudanças. Neste caso específico, quando a bateria do dispositivo atinge um nível crítico, as mensagens que antes eram enviadas criptografadas, passam a trafegar decriptografadas.

A Segurança implementada no xPresumo, envolve dois módulos, de Autenticação de dispositivos e Criptografia das mensagens. Na Autenticação, foi implementado o algoritmo hash Secure Hash Algorithm(SHA-2) com uma função de 256 bits. A Criptografia das mensagens é realizada por meio de Criptografia Simétrica utilizando o algoritmo Advanced Encryption Standard(AES) com uma chave de 128 bits.

Nos estudos realizados por Prasithsangaree (PRASITHSANGAREE; KRISHNAMURTHY

(2003)) e Singhal (SINGHAL; RAINA(2011)) é possível observar que existem algoritmos simé- tricos que oferecem melhor desempenho e menor consumo energético em relação ao AES, porém nota-se que tais algoritmos são suscetíveis a maioria dos ataques de força bruta (COUTURE; KENT(2004)), ou seja, oferecem menos segurança que o AES. No cenário de Internet das Coi- sas, dependendo do domínio de aplicação, é necessário priorizar a segurança devido a relevância das informação trocadas entre dispositivos; o algoritmo AES proporciona um equilíbrio entre segurança e desempenho.

O serviço de Gerenciamento de Eventos tem como propósito a captura dos eventos ocorridos durante o funcionamento de xPresumo. A troca de mensagens entre os dispositivos são armazenadas em um servidor de banco de dados. Devido à grande quantidade de eventos gerados no cenário de IoT, optou-se pelo uso do MongoDB (KANADE; GOPAL; KANADE

(2014)), um banco de dados orientados a documentos (NoSQL). Os bancos de dados NoSQL tem desempenho escalável, alta disponibilidade e resiliência.

No processo de desenvolvimento do xPresumo, houve a preocupação em solucionar os principais problemas em IoT apontados pela literatura, procurando manter um desempenho satisfatório na sua utilização.

4.3. PROJETO 43

4.3

Projeto

Esta seção tem como foco detalhar os serviços desenvolvidos no xPresumo (ver Seção 4.2). Para melhor entendimento, a representação desses serviços será realizada por diagramas de Classes e Atividades Unified Modelling Language (UML)BOOCH; RUMBAUGH; JACOBSON

(2006).

4.3.1

Localização e Descoberta

Os serviços de Localização e Descoberta de dispositivos tem a responsabilidade de retornar a localização geográfica. As funcionalidade desses serviços são implementadas pela classe Location, que, possui os métodos necessários para simular os APs fixos e calcular o RSSI.

A Figura 4.3 apresenta a modelagem dos serviços de Localização e Descoberta. Na figura é possível observar a relação entre as classes DispositivoA e a Location. A classe Location implementa a interface MessageListener, que é definida na especificação JMS e possui três atributos (idcoisa, rssi e resultabse) e cinco métodos (serviceDicovery(), serviceLocation(), LocationA(), LocationB() e LocationB()).

O atributo "rssi"tem como finalidade armazenar temporariamente a intensidade do sinal de rádio (RSSI) recebido por determinado dispositivo em relação aos APs disponíveis. Após a obtenção desses valores, o posicionamento geográfico é calculado tendo por base as distâncias entre o dispositivo em questão e os APs. Para melhor acurácia do posicionamento, é preciso usar no mínimo três APs. O atributo resultbase é utilizado para armazenar o posicionamento geográfico calculado anteriormente.

Ambos os métodos e atributos são comuns aos serviços de Localização e Descoberta de dispositivos. Entretanto, o método serviceLocation() é usado especificamente pelo serviço de Localização, já o método serviceDiscovery() é de exclusividade do serviço de Descoberta.

Figura 4.3 Diagrama de Classe do Serviço de Localização

O diagrama de sequência do serviço de Localização pode ser observado na Figura 4.4. Um dispositivo qualquer solicita sua localização fazendo uma chamada ao método serviceLocation()

4.3. PROJETO 44 da classe Location e no retorno é realizada uma chamada aos métodos subscriberLocation() e onMessage().

Figura 4.4 Diagrama de Sequência do Serviço de Localização

Juntamente com o método subscriberLocation(), um parâmetro do tipo "inteiro"é enca- minhado. Esse parâmetro corresponde ao "id"do próprio dispositivo, ou seja, sua identificação. Ao invocar o método publisherLocation(), o dispositivo em questão recebe a sua localização geográfica por meio de um objeto do tipo Message no método onMessage.

Figura 4.5 Diagrama de Sequência do Serviço de Descoberta

A Figura 4.5 apresenta o diagrama de sequência do serviço de Descoberta. O método responsável por retornar a localização geográfica de outros dispositivos é o serviceDiscovery(), que também recebe um parâmetro do tipo "inteiro", correspondente à identificação (id) do dispositivo que se deseja obter a localização.

4.3.2

Ciência de Contexto

O serviço de Ciência de Contexto viabiliza a adaptação do funcionamento do xPresumo em relação ao envio de mensagens. Por padrão, as mensagem trocadas entre os dispositivos são todas criptografadas e esse recurso de segurança tem impacto negativo no consumo de energia de dispositivos dependentes de bateria. Por essa razão, optou-se em incluir o módulo em questão de modo a obter um melhor gerenciamento dos recursos energéticos dos dispositivos.

4.3. PROJETO 45 O diagrama de classe do serviço de Ciência de Contexto pode ser visto na Figura 4.6. Assim como a classe Location, a classe MessageControl também implementa a interface Messa- geListener. A MessageControl possibilita a alternância entre mensagens criptografadas e não criptografas através do envio de mensagens de controle (message), informando quando determi- nado dispositivo equipado com bateria atingir um nível crítico (nivelcritico) de energia. O valor do nível crítico é um parâmetro definido pelo usuário do sistema conforme as necessidades do ambiente monitorado e do tipo de dispositivos que portam bateria.

Figura 4.6 Diagrama de Classe do Serviço de Ciência de Contexto

A adaptação ocorre mediante o recebimento de alguma mensagem de controle, ou seja, todos os dispositivos que se subscrevem a um determinado tópico (temperatura, localização, status, entre outras), estão condicionados às mensagens de controle. Antes que as mensagens enviadas aos tópicos cheguem ao destino final, é verificado se existem dispositivos portando bateria e se o nível energético destes dispositivos possibilita o recebimento de mensagens sem comprometer seu funcionamento. O diagrama de sequência da Figura 4.7 ilustra esse fluxo de eventos.

Figura 4.7 Diagrama de Sequência do Serviço de Ciência de Contexto

Os dispositivos que solicitam alguma informação pertinente ao cenário monitorado (temperatura, localização, status, entre outras), realizam inicialmente uma chamada ao método subscriberMSGControl(). O subscriberMSGControl() é responsável por receber as mensagens de controle relacionadas ao nível energético dos dispositivos dependentes de bateria.

4.3. PROJETO 46 O publisherMSGControl() é o método encarregado pelo envio das mensagens de controle. Os dispositivos portadores de bateria devem constantemente realizar chamadas a este método, informando se o nível crítico de energia foi atingido. O método onMessage presente em ambas as classes é invocado a cada nova mensagem. Nos dispositivos que detém bateria, o método setMensagemé executado dentro do onMessage e atualiza o status energético sempre que há alterações no nível de energia da bateria.

4.3.3

Segurança

O serviço de Segurança é outro módulo de extrema importância ao cenário de IoT. As informações que trafegam entre as coisas inteligentes devem ter um mínimo de segurança para que problemas como intercepção de dados sejam evitados. A Segurança no xPresumo tem duas finalidades: prover um mecanismos de autenticação das coisas inteligentes e a criptografia nas mensagens trocadas entre esses dispositivos.

O diagrama de classe da Figura 4.8 ilustra a classe Authentication, responsável por autori- zar que dispositivos conhecidos possam enviar e/ou receber informações. A classe Authentication possui três métodos: includeDevice(), verificationDevice() e selecthashDevice(). O primeiro método (includeDevice) foi implementado para possibilitar a prévia inclusão dos dispositivos par- ticipantes no cenário a ser monitorado. Dentre as informações que são utilizadas para o cadastro do dispositivo, uma identificação única é solicitada, além de uma senha para autenticação.

Figura 4.8 Diagrama de Classe do Serviço de Segurança - Autenticação

Para aumentar a segurança no mecanismo de autenticação, a senha fornecida no cadastro é submetida à uma função criptográfica unidirecional SHA-2, gerando um hash (sequência de bits) que será convertida em formato hexadecimal antes de ser armazenadoa no banco de dados.

O método verificationDevice() tem a finalidade de verificar se a identificação única do dispositivo (idcoisa) que está publicando alguma mensagem corresponde ao dispositivo em questão. A validação das informações relacionadas à autenticação dos dispositivos é realizada pelo método selecthashDevice. As informações fornecidas para autenticação são verificadas em uma base dados e caso a autenticação seja bem sucedida, o dispositivo terá permissão para

4.3. PROJETO 47 interagir com os demais. O diagrama de sequência da Figura 4.9 demonstra o processo de autenticação realizado pelos dispositivos.

Figura 4.9 Diagrama de Sequência do Serviço de Segurança - Autenticação

Antes de qualquer publicação de mensagens relacionada ao cenário monitorado, os dis- positivos devem realizar a autenticação para que possam interagir com o xPresumo. Inicialmente é realizada uma chamada ao método selecthashDevice passando como parâmetro a identificação única do dispositivo (id), juntamente com o hash gerado para aquele dispositivo específico. É realizada uma consulta à base de dados do xPresumo afim de verificar se os dados são válidos e correspondem a algum dispositivo previamente cadastrado. Em caso de sucesso na verificação, o dispositivo terá permissão para interagir com o sistema, publicando e recebendo mensagens. Essa verificação é realizada toda vez que um dispositivo deseja enviar e receber mensagens.

O mecanismo de autenticação resolve uma das preocupações presentes nos cenários de IoT; acesso não autorizado as mensagens trocadas entre dispositivos. Entretanto, só essa medida de segurança não é suficiente. Existe também a preocupação em relação à inteligibilidade das mensagens em casos de intercepção não autorizada. Sendo assim, em complemento ao mecanismo de autenticação, o xPresumo por meio de criptografia simétrica, permite a encriptação das mensagens enviadas entre dispositivos.

Todas as mensagens publicadas via xPresumo são submetidas ao processo de cifragem utilizando um algoritmo criptográfico AES com uma chave de 128 bits. A classe Security (Figura 4.10) fica responsável por realizar esse processo de encriptografar e decriptografar as mensagens trocadas entre os dispositivos.

Figura 4.10 Diagrama de Classe do Serviço de Segurança - Criptografia

A classe Security possui um atributo key do tipo array de bytes, além dos seguintes métodos: keyGenerator, encrypt e decrypt(). O atributo key tem a responsabilidade de armazenar

4.3. PROJETO 48 o valor da chave criptográfica gerada por meio do método keyGenerator. O encrypt tem a finali- dade de encriptar as mensagens enviadas. Na outra extremidade de comunicação, o decrypt() realiza a decriptação das mensagens recebidas. Uma melhor visualização do fluxo criptográfico realizado na troca de mensagens pode ser observada na Figura 4.11.

Figura 4.11 Diagrama de Sequência do Serviço de Segurança - Criptografia

Quando determinado dispositivo deseja publicar uma mensagem, este invoca o método encryptda classe Security, passando como parâmetro a mensagem a ser criptografada (msg). O resultado desse processo é um array (vetor) de bytes. A chave de 128 bits utilizada para realizar a criptografia e decriptografia é gerada por meio de uma chamada ao método (keyGenerator). O decrypt() fica responsável pela conversão das mensagens criptografadas para o seu estado original (texto puro). Por se tratar de uma algoritmo simétrico, a chave utilizada para criptografar as mensagens enviadas também é aplicada no processo de decriptografia da mensagens recebidas. A implementação desses dois mecanismos de segurança (autenticação e criptografia) são suficientes para impedir que dispositivos não autorizados ou mesmo invasores tenham acesso as funcionalidades do xPresumo.

4.3.4

Gerenciamento de Eventos

No cenário de Internet das Coisas, a grande quantidade de coisas inteligentes gerando eventos em tempo contínuo acaba por resultar em um alto volume de informações. Devido à relevância dessas informações, é essencial que estas sejam armazenadas para posterior análises.

Todos os eventos gerados durante o monitoramento de determinado ambiente são persis- tidos (armazenados) em um banco de dados Orientado a Documentos. Optou-se por um SGBD NoSQL devido as inúmeras vantagens (flexibilidade, escalabilidade, desempenho, entre outros) em relação aos SGBD convencionais, principalmente em arquiteturas distribuídas.

O banco de dados escolhido para interagir com a arquitetura do xPresumo foi o MongoDB. O MongoDB é um SGBD NoSQL Orientado a Documentos que se adapta muito bem à com arquiteturas distribuídas. No contexto de IoT onde o volume de informações produzidas é extremamente elevado, a adoção do MongoDB foi muito importante. A MongoConnection

4.3. PROJETO 49 (Figura 4.12) é a classe responsável por realizar a conexão com o MongoDB e fazer a persistência dos dados.

Figura 4.12 Diagrama de Classe do Serviço de Gerenciamento de Eventos

Além de realizar a conexão com o banco de dados MongoDB, a classe MongoConnection também possui métodos que permitem a persistência dos eventos gerados pelos dispositivos. Os atributos server e port são utilizados no processo de comunicação com o servidor MongoDB via conexão Transmission Control Protocol (TCP). Os demais atributo (mongo, db, dbname, collection), são usados na conexão com banco de dados e nos métodos de acesso. O fluxo de operação dos métodos da MongoConnection pode ser observado no diagrama de sequência (Figura 4.13).

Figura 4.13 Diagrama de Sequência do Serviço de Gerenciamento de Eventos

Na situação onde os dispositivos já se encontram cadastrados na base de dados que será utilizada pelo xPresumo, é realizada uma chamada ao método verifyHash para liberar o acesso (autenticação) do dispositivo ao middleware. Após a etapa de autenticação, o processo de persistência dos dados inicia-se com a verificação do status da conexão realizada com o Servidor de Banco de Dados. Essa verificação é realizada através do verifyConnection(), retornando um valor true caso o Servidor esteja online e o valor false em caso contrário.

Posteriormente à verificação de comunicação com o Servidor, é criado um objeto do tipo MongoClient. A partir do objeto MongoClient, é realizada a conexão com o banco de dados por

4.4. IMPLEMENTAÇÃO 50 meio do método getDB(), passando como parâmetro o nome da base de dados (dbname) a ser utilizada. O atributo db do tipo DB possui o método getCollection() para acessar as coleções do banco de dados. Se estas etapas tiverem sucesso, o método insertDataDB é invocado para realizar a persistência dos eventos gerados pelos dispositivos.

4.4

Implementação

O xPresumo foi integralmente implementado na linguagem de programação Java e é distribuído como biblioteca. Para o desenvolvimento da solução algumas ferramentas foram