Síntese de Requisitos de Segurança para Internet das Coisas ...

UNIVERSIDADE FEDERAL DE GOIÁSINSTITUTO DE INFORMÁTICA

INAEL RODRIGUES DE OLIVEIRA NETO

Síntese de Requisitos de Segurança paraInternet das Coisas Baseada emModelos em Tempo de Execução

Goiânia2015

UNIVERSIDADE FEDERAL DE GOIÁS

INSTITUTO DE INFORMÁTICA

AUTORIZAÇÃO PARA PUBLICAÇÃO DE DISSERTAÇÃO

EM FORMATO ELETRÔNICO

Na qualidade de titular dos direitos de autor, AUTORIZO o Instituto deInformática da Universidade Federal de Goiás – UFG a reproduzir, inclusive em outroformato ou mídia e através de armazenamento permanente ou temporário, bem como apublicar na rede mundial de computadores (Internet) e na biblioteca virtual da UFG,entendendo-se os termos “reproduzir” e “publicar” conforme definições dos incisos VIe I, respectivamente, do artigo 5o da Lei no 9610/98 de 10/02/1998, a obra abaixoespecificada, sem que me seja devido pagamento a título de direitos autorais, desde quea reprodução e/ou publicação tenham a finalidade exclusiva de uso por quem a consulta,e a título de divulgação da produção acadêmica gerada pela Universidade, a partir destadata.

Título: Síntese de Requisitos de Segurança para Internet das Coisas Baseada em Modelosem Tempo de Execução

Autor(a): Inael Rodrigues de Oliveira Neto

Goiânia, 14 de Outubro de 2015.

Inael Rodrigues de Oliveira Neto – Autor

Fábio Moreira Costa – Orientador

Ricardo Couto Antunes da Rocha – Co-Orientador



Dissertação apresentada ao Programa de Pós–Graduação doInstituto de Informática da Universidade Federal de Goiás,como requisito parcial para obtenção do título de Mestre emCiência da Computação.

Área de concentração: Ciência da Computação.

Orientador: Prof. Fábio Moreira Costa

Co-Orientador: Prof. Ricardo Couto Antunes da Rocha

Goiânia2015

Ficha catalográfica elaborada automaticamente com os dados fornecidos pelo(a) autor(a), sob orientação do Sibi/UFG.

Rodrigues de Oliveira Neto, Inael Síntese de Requisitos de Segurança para Internet das CoisasBaseada em Modelos em Tempo de Execução [manuscrito] / InaelRodrigues de Oliveira Neto. - 2015. CXI, 111 f.

Orientador: Prof. Dr. Fábio Moreira Costa; co-orientador Dr.Ricardo Couto Antunes da Rocha.Dissertação (Mestrado) - Universidade Federal de Goiás, Instituto deInformática (INF) , Programa de Pós-Graduação em Ciência daComputação, Goiânia, 2015. Bibliografia. Inclui tabelas, lista de figuras.

1. Requisitos de Segurança. 2. Autenticação, Confidencialidade. 3.Models@runtime. 4. Reconfiguração da Segurança. 5. Internet dasCoisas. I. Moreira Costa, Fábio, orient. II. Couto Antunes da Rocha,Ricardo, co-orient. III. Título.



Dissertação defendida no Programa de Pós–Graduação do Instituto deInformática da Universidade Federal de Goiás como requisito parcialpara obtenção do título de Mestre em Ciência da Computação, aprovadaem 14 de Outubro de 2015, pela Banca Examinadora constituída pelosprofessores:

Prof. Fábio Moreira CostaInstituto de Informática – UFG

Presidente da Banca

Prof. Ricardo Couto Antunes da RochaInstituto de Informática – UFG

Prof. Dr. Sérgio Teixeira de CarvalhoInstituto de Informática – UFG

Prof. Dr. Adenauer Corrêa YaminCentro Politécnico - Computação – UCPEL

Todos os direitos reservados. É proibida a reprodução total ou parcial dotrabalho sem autorização da universidade, do autor e do orientador(a).

Inael Rodrigues de Oliveira Neto

Graduou-se em Engenharia de Software na UFG - Universidade Federal deGoiás. Durante sua graduação, foi homologador de aplicativos fiscais noCentro Tecnológico de Software (CTS) da UFG. Participou do projeto depesquisa e desenvolvimento Prontuário Eletrônico do Paciente na UFG noInstituto de Informática (INF).

Dedico essa pesquisa a minha família: esposa Jackeline Neves que esteve ao meulado me apoiando durante essa jornada; pais Mara Regina e Edvaine Domingues, e aosmeus segundos pais, a sogra Vanusa Neves e o sogro Nestor José, que sempre acreditaramem meu trabalho. Dedico também essa pesquisa aos meus tios Elsiene Domingues eZoenia Gomes, aos meus primos Guilherme Domingues e Thays Cristine que torcerampor mim para alcançar meus objetivos.

Agradecimentos

Quero agradecer, em primeiro lugar, a Deus, pela força e coragem durante todaesta longa caminhada.

Agradeço a todos que contribuíram para a conclusão deste trabalho.À minha família pelo suporte e motivação durante minha pesquisa.À minha esposa, que, de forma especial e carinhosa, me deu forças e coragem,

teve paciência e complacência e me apoiou nos momentos de dificuldade durante essajornada.

E finalmente, aos meus orientadores Fábio Costa e Ricardo Rocha, pela paciêncianas orientações e incentivos que tornaram possível a conclusão deste trabalho.

Muito obrigado.

“Meus filhos terão computadores, sim, mas antes terão livros. Sem livros,sem leitura, os nossos filhos serão incapazes de escrever - inclusive a suaprópria história.”

Bill Gates,.

Resumo

Rodrigues de Oliveira Neto, Inael. Síntese de Requisitos de Segurança paraInternet das Coisas Baseada em Modelos em Tempo de Execução. Goiânia,2015. 114p. Dissertação de Mestrado. Instituto de Informática, UniversidadeFederal de Goiás.

A Internet das Coisas (IoT) conecta na Internet todo tipo de coisas ou objetos inteli-

gentes, tais como dispositivos, sensores, atuadores, telefones celulares, eletrodomésticos,carros e até mesmo móveis. Ela caracteriza-se pela ubiquidade e dinamismo do seu ambi-ente e objetos conectados. Com isso, o ambiente da IoT é altamente volátil e heterogêneo,pois ele conta com a presença de diferentes objetos capazes de interagir e cooperar unscom os outros através da Internet.Ao passo que objetos inteligentes se tornam mais ubíquos, há uma crescente incertezasobre o ambiente, o que contribui com um maior surgimento de ameaças de segurançanão previstas na fase de projeto.Esta dissertação apresenta uma solução que objetiva garantir flexibilidade nos requisitosde segurança para serem alterados pelo usuário em tempo de execução e refletir sistemati-camente sobre essas mudanças nas configurações de segurança em objetos conectados naIoT. Para isso, este trabalho apresenta uma arquitetura de middleware e a implementaçãode um algoritmo para avaliação de requisitos e reconfiguração da segurança. Além disso,este trabalho apresenta uma linguagem de modelagem de domínio específico usando mo-

dels@runtime para especificação dos requisitos de segurança do usuário. Entre as con-tribuições deste trabalho, podemos citar a proposta de arquitetura de middleware, umalgoritmo de síntese de requisitos para reconfiguração da segurança em tempo de execu-ção, a linguagem de modelagem de requisitos de segurança, a aplicação da abordagem demodelos em tempo de execução para reconfiguração da segurança e a construção de ummetamodelo que captura de aspectos de segurança de aplicações executando em disposi-tivos na IoT.

Palavras–chave

Requisitos de Segurança, Autenticação, Confidencialidade, Models@runtime,Reconfiguração da Segurança, Internet das Coisas

Abstract

Rodrigues de Oliveira Neto, Inael. Security Requirements Synthesis for Inter-net of Things Based on Models@runtime. Goiânia, 2015. 114p. MSc. Disser-tation. Instituto de Informática, Universidade Federal de Goiás.

The Internet of Things (IoT) connects the Internet all kinds of “things” or “smart

objects” such as devices, sensors, actuators, mobile phones, home appliances, cars andeven furniture. IIoT is characterized by the ubiquity and dynamism of its environment andconnected objects. Thus, the environment of the IoT is highly volatile and heterogeneousas it counts with the presence of different objects able to interact and to cooperate witheach other over the Internet.While Smart Objects become more ubiquitous, there is growing uncertainty about theenvironment, which contributes to a greater appearance of security threats not foreseen inthe design phase.This thesis presents a solution that aims to ensure flexibility by allowing the safety re-quirements to be changed at runtime by the user, systematically reflecting these changesto the security settings for objects connected to the IoT. Therefore, this work presentsan architecture of middleware and implementation of an algorithm for assessment re-quirements and security reconfiguration as well as its evaluation. In addition, this workpresents a domain-specific modeling language using models@runtime for specifying theuser’s security requirements. About the contributions of this work, we can mention theproposed architecture of middleware, a requirements synthesis algorithm for reconfigu-ration of security at runtime, a security requirement modeling language, the applicationof models@runtime approach for reconfiguration of security and the construction of ametamodel for capturing application security aspects running on devices in the IoT.

Keywords

Security Requirements, Authentication, Confidentiality, Models@runtime, Se-curity Reconfiguration, Internet of Things

Sumário

Lista de Figuras 12

Lista de Tabelas 14

1 Introdução 151.1 Objetivos 181.2 Contribuições 191.3 Organização da Dissertação 19

2 Segurança na Internet das Coisas 212.1 Visão Geral sobre Internet das Coisas 212.2 Desafios para Implantação da Internet das Coisas 232.3 Segurança na Internet das Coisas 24

2.3.1 Requisitos de Segurança Estáticos em Ambientes Dinâmicos 252.3.2 Exemplo 26

2.4 Conclusão 28

3 Modelos em Tempo de Execução 293.1 Visão Geral 293.2 Metamodelo 313.3 Implementação de Linguagem de Modelagem Específicas de Domínio 333.4 Conclusão 37

4 Requisitos de Segurança em Tempo de Execução 394.1 Requisitos de Segurança 394.2 Requisitos de Segurança na Forma de Models@runtime 40

4.2.1 Metamodelo de Requisito de Segurança e Sessão de Comunicação 414.3 Linguagem de Modelagem de Requisitos de Segurança 45

Cláusula TRUST_IN 46Cláusula IF 47Cláusula FOR 49Cláusula MANDATORY 50

4.4 Resolução de Conflitos entre Requisitos 514.5 Conclusão 54

5 Arquitetura para Síntese de Requisitos de Segurança em Tempo de Execução 555.1 Arquitetura do Middleware 55

5.1.1 User Interface (UI) 585.1.2 Synthesis Engine (SE) 585.1.3 Control and Configuration (CC) 595.1.4 Thing Broker (TB) 60

5.2 Síntese de Requisitos de Segurança 615.2.1 Árvore de Requisitos e Sessões 615.2.2 Algoritmo de Síntese de Requisito 64

5.3 Implementação 725.3.1 Tratamento de Sinais 735.3.2 Camada Synthesis Engine (SE) 77

Algoritmo de Síntese de Requisitos 77Metamodelo 78Trust Requirement Modeling Language - TRML 78

5.3.3 Camada Control and Configuration (CC) 805.4 Conclusão 83

6 Estudo de Caso e Avaliação 846.1 Metodologia 846.2 Estudo de caso 866.3 Desempenho do Algoritmo de Síntese de Requisitos 956.4 Limitações 98

7 Trabalhos Relacionados 997.1 Reconfiguração da Segurança em Tempo de Execução 997.2 Visão do Estado da Segurança de Entidades na IoT 1017.3 Comparativo entre os Trabalhos Relacionados 102

8 Conclusão 1048.1 Trabalhos Futuros 105

Referências Bibliográficas 109

Lista de Figuras

1.1 Visão Geral da Solução 17

2.1 Dimensões de Comunicação e Compartilhamento de Informação na IoT [41] 222.2 Internet das Coisas como Resultado da Convergência de Diferentes Vi-

sões [5] 232.3 Objetos no Ambiente de IoT do Hospital HUCON 27

3.1 Arquitetura de Metamodelagem - MOF [37] 333.2 Anatomia de uma Linguagem [24] 343.3 Exemplo de Sintaxe Abstrata e Concreta de uma DSML para Domínio de

Transporte [31] 353.4 Modelagem e DSML [49] 35

4.1 Visão Geral da Reconfiguração da Segurança Mediante Especificação deRequisito de Segurança 41

4.2 Elementos do Metamodelo para Especificar Requisitos de Segurança 424.3 Exemplo de Instância do Metamodelo 444.4 (i) Arquitetura de Metamodelagem MOF [37] Proposta pela OMG [25]; (ii)

Arquitetura de Metamodelagem Proposta Neste Trabalho e (iii) Exemplode Modelo Gerado a Partir da Arquitetura (ii) 45

4.5 Diagrama de Sintaxe EBNF de um Requisito 464.6 Diagrama de Sintaxe EBNF da Cláusula TRUST_IN 464.7 Tipos e Subtipos de Objetos na IoT 474.8 Diagrama de Sintaxe EBNF da Cláusula IF 494.9 Diagrama de Sintaxe EBNF da Cláusula FOR 494.10 Diagrama de Sintaxe EBNF da Cláusula MANDATORY 504.11 Comparação de Escopos de Objetos na IoT 52

5.1 Camadas do Middleware 575.2 Diagrama de Classes da Árvore de Requisitos e Sessões 625.3 Representação da Árvore de Requisitos de Segurança e Sessões de

Comunicação do Smartphone de um Usuário 645.4 Geração do Modelo de Sessão de Comunicação 725.5 Pacotes do Projeto 735.6 Diagrama de Classe de Eventos e Gerenciador de Eventos 745.7 Diagrama de Classe com Implementações de Alguns Eventos e Gerenci-

adores de Eventos 765.8 Pacote com as Classes que Implementam o Algoritmo de Síntese de

Requisitos 77

5.9 Pacote com as Classes que Implementam o Metamodelo 785.10 Exemplo de Requisito de Segurança Especificado na TRML Java 795.11 Pacote com as Classes que Implementam a TRML 795.12 Diagrama de Classe da TRML 80

6.1 Redes Disponíveis 876.2 Exemplo de Dados Disponibilizados pelo Projeto Device Analyzer [57] 886.3 Pontos de Acesso Encontrados por Tipo de Segurança 906.4 Conexões em Pontos de Acesso por Tipo de Segurança 916.5 Segurança nas Redes Distintas Disponíveis 926.6 Segurança nas Redes Conectadas 936.7 Conexões Realizadas no Mês de Setembro 946.8 Conexões Realizadas no Mês de Setembro 946.9 Porcentagem de Pontos de Acessos Disponíveis Agrupados por Segurança 956.10 Tempo de Síntese de Requisitos para Reconfiguração da Segurança de

10 (dez), 100 (cem), 1.000 (mil) e 10.000 (dez mil) sessões 966.11 Tempo de Síntese de Requisitos para Reconfiguração da Segurança de

10 (dez), 100 (cem), e 1.000 (mil) sessões 97

8.1 Protótipo da Interface Gráfica Manter Requisitos 1068.2 Protótipo da Interface de Listagem de Dispositivos 107

Lista de Tabelas

5.1 Elementos e Atributos Usados no Algoritmo sintetizaRequisitos 665.2 Elementos e Atributos Usados no algoritmo para Gerar a Configuração de

Segurança 685.3 Sinais Tratados por cada Camada 77

7.1 Trabalhos Relacionados 103

CAPÍTULO 1Introdução

Com o avanço tecnológico, segundo Bick et al. [8], cada vez mais o proces-samento, a capacidade de energia, o armazenamento e outros componentes que fazemparte de dispositivos com capacidades computacionais reduzidas, tornam-se disponíveiscom custo relativamente baixo. Isso tem contribuído com o progresso da tecnologia epermitido o desenvolvimento de dispositivos eletrônicos extremamente pequenos e comcapacidade computacionais que podem ser incorporados no meio ambiente ou em obje-tos comuns, como dispositivos móveis (smartphones, tablets e notebooks) e dispositivosubíquos e pervasivos (televisores, relógios, sensores e atuadores).

Essa classe de dispositivos emergentes tem popularizado o acesso ubíquo à redepor meio de redes sem fio (e.g., 3G/4G e WiFi), tornando a Internet uma plataformaglobal de comunicação entre esses dispositivos. Dessa forma, aplicações e serviços estãoem nosso entorno, sempre disponíveis, abrindo o caminho para novas formas interação,novas formas de entretenimento e novos modos de vida.

Dentro desta perspectiva, o termo Internet das Coisas (Internet of Things - IoT) éamplamente utilizado para se referir a objetos, também chamados por coisas, conectadosà Internet e interagindo uns com os outros em qualquer lugar e em qualquer momentopor meio da Internet. A IoT, de acordo com Miorandi et al. [38], é um exemplo deambiente ubíquo com grande variabilidade e dinamismo. Ela conecta na Internet todotipo de objetos, como eletrodomésticos, carros e até mesmo móveis. Na IoT, devido àmobilidade e grande variedade de objetos conectados, há uma crescente incerteza no quediz respeito a quais objetos estão presentes no ambiente.

A Internet, que apenas era usada para interligar usuário final a serviços remotos(tipicamente servidores HTTP), passou a ser usada também para interligar objetos da IoT.Essa mudança, em que objetos se comunicam uns aos outros e com os seres humanos,a fim de oferecer um dado serviço, engloba a necessidade de repensar algumas dasabordagens convencionais habitualmente utilizadas na segurança do usuário.

Essa presença pervasiva da computação em nosso cotidiano implica maior mo-bilidade pelo espaço urbano e maior compartilhamento de informação. Por outro lado,também implica em uma maior exposição dos dispositivos às ameaças e agentes malicio-

16

sos. Neste contexto, de acordo com Roman et al. [43], um componente crítico que impedea ampla adoção de tecnologias e aplicações da IoT é a segurança.

Na perspectiva de um ecossistema aberto a IoT, em que os diferentes atorespodem estar envolvidos em um determinado cenário de aplicação, surge uma série dedesafios à segurança, como:

• A mudança constante da infraestrutura de rede como resultado da mobilidade podecontar com a presença de canais inseguros e pontos de acesso potencialmentemaliciosos;• Há uma grande imprevisibilidade inerente aos dispositivos participantes do ambi-

ente da IoT, dispositivos entram e saem da rede a todo instante [35, 29];• A segurança nesse cenário é complexa e seu contexto é de difícil compreensão pelo

usuário;• Aplicações e serviços tem pouca ou nenhuma opção para gerenciar a segurança na

comunicação.

Como consequência de uma variação imprevista no ambiente, o usuário pode sedeparar repentinamente com um ambiente hostil e passar a ter uma nova necessidade desegurança. No entanto, a segurança geralmente é baseada em decisões de desenvolvimentoe decisões de implantação, realizadas na infraestrutura, de modo que o usuário não podeinterferir, por exemplo, na escolha do algoritmo criptográfico que será utilizado em umaaplicação. Diante dessa limitação, o usuário pode necessitar de um meio para alterar osmecanismos de segurança nos dispositivos em tempo de execução, diante de uma situaçãoimprevisível no ambiente IoT que pode colocá-lo em risco.

Por exemplo, usuário caminhando por um aeroporto pode fazer com que seudispositivo se desconecte da rede segura fornecida pelo aeroporto e se conecte em umarede pública disponibilizada por um restaurante interno. Neste instante, o usuário podeexigir que todas as aplicações executando em seu dispositivo que não utilizam criptografiaou utilizam algoritmos criptográficos fracos (fáceis de serem decifrados) passe a utilizaralgoritmos criptográficos fortes (difíceis ou inviáveis de serem decifrados).

Para lidar com esse problema, este trabalho apresenta uma abordagem dirigidapor modelos em tempo de execução, na qual requisitos de segurança são tratados comoentidades externas a dispositivos para que possam ser alterados em tempo de execuçãoe refletir as mudanças dos requisitos na segurança da comunicação de suas aplicaçõese serviços em execução, sem interrompê-los. Dessa forma, o usuário participa do loop

(user in-the-loop [34]) de adaptação da segurança a partir da alteração e especificação deseus requisitos de segurança na aplicação.

Os requisitos de segurança, no âmbito deste trabalho, representam as necessida-des de segurança dos dispositivos de um usuário em termos de restrições (tipo de algo-ritmo criptográfica e forma de autenticação) impostas a outros dispositivos na IoT para

17

serem consideradas confiáveis em uma comunicação. Esta pesquisa concentra-se na mu-dança de requisitos de segurança, em especial, com aspectos de autenticação e confiden-cialidade, que por si só representam um importante desafio para aplicações na IoT. Osrequisitos de autenticação especificam regras para autenticar o par de participantes nacomunicação e os requisitos de confidencialidade especificam o tipo de algoritmo cripto-gráfico que será utilizado na comunicação.

O argumento fundamental deste trabalho é que as aplicações atuais não apoiam aalteração de requisitos de segurança dos dispositivos em ambientes dinâmicos. Alegamosque os usuários podem precisar examinar o estado do ambiente (dispositivos presentese redes disponíveis do ambiente) e alterar seus requisitos de segurança diante de umamudança repentina e não prevista. Isso demanda por objetos na IoT com a segurançaflexível a ponto de permitir que alterações da segurança nas aplicações em execuçãosejam realizadas pelo usuário, colocando-o no loop de adaptação dos sistemas em tempode execução.

Para resolver o problema da configuração flexível pelo usuário em dispositivosna IoT, propomos uma arquitetura de middleware que sintetiza requisitos de segurançaespecificados pelo usuário e gera comandos de segurança para serem usados na confi-guração da segurança da comunicação dos dispositivos que se interagem. A Figura 1.1ilustra de forma simplificada o processo de reconfiguração da segurança.

Figura 1.1: Visão Geral da Solução

A parte inferior da Figura 1.1 exibe a condução da reconfiguração de segurançapor meio de comandos que alteram a segurança de sessões de comunicação em consonân-cia com os requisitos de segurança estabelecidos pelo usuário.

Os comandos são gerados a partir da síntese de modelos que representam requisi-tos. Sempre que há alterações no modelo, a síntese é executada e, como resultado, sessões

têm a configuração de segurança alterada. As sessões mantêm informações que identi-ficam os processos executando em dispositivos participantes da comunicação e informa-ções a respeito da configuração de segurança usada na comunicação. A configuração de

1.1 Objetivos 18

segurança define um conjunto de diretivas de confidencialidade e autenticação usadas nacomunicação.

A sessão de comunicação é criada após a conexão e negociação de aspectosde segurança entre o par de processos executando em dispositivos na IoT. Durantea síntese, são gerados comandos para realizar a reconfiguração da segurança de cadasessão de comunicação afetada pelos requisitos, desde que possua a configuração desegurança existente diferente da nova configuração de segurança. A reconfiguração seresume à renegociação da segurança descrita na nova configuração de segurança entreos participantes da comunicação. Sempre que os modelos em tempo de execução querepresentam os requisitos são alterados, é gerada uma nova configuração de segurança aser aplicada na sessão de comunicação.

1.1 Objetivos

Diante deste cenário, este trabalho tem como objetivo permitir que dispositivosna IoT sejam flexíveis o suficiente para que o usuário final tenha condições de reconfigurara segurança em tempo de execução, a fim de atender suas necessidades específicas desegurança.

Para isso, propomos o uso da abordagem de models@runtime para tratar requi-sitos de segurança, como entidades externas às aplicações e serviços executando em dis-positivos na IoT. Dessa forma, o usuário poderá participar do loop (user-in-the-loop [34])de reconfiguração da segurança por meio de alterações de requisitos de segurança emtempo de execução, as quais refletirão dinamicamente na configuração da comunicaçãodos dispositivos.

Esse objetivo geral é concretizado pelos seguintes objetivos específicos:

• Propor uma arquitetura de middleware dirigida por modelos em tempo de execuçãoque permita alteração em requisitos de segurança em aplicações e serviços emdispositivos na IoT;• Implementar a camada responsável por manter o modelo e sintetizar requisitos em

configurações de segurança;• Projetar um metamodelo que sustente a especificação de modelos de requisitos de

segurança;• Projetar uma linguagem de domínio específico para modelar os requisitos de segu-

rança;• Projetar um algoritmo de síntese de requisitos para escolher os requisitos e

sintetizá-los em comandos de segurança para alterar a configuração de segurançada comunicação;

1.2 Contribuições 19

• Realizar uma avaliação de desempenho da solução por meio de um experimentobaseado em dados reais.

1.2 Contribuições

Este trabalho apresenta como contribuição uma solução para o problema da re-configuração flexível de segurança pelo usuário em objetos na IoT. Além disso, este tra-balho tem como contribuição a aplicação de uma abordagem de modelos em tempo deexecução no domínio da segurança para a construção da solução que permita ao usuáriofinal alterar requisitos de segurança em tempo de execução, os quais serão transformadosem comandos a fim de reconfigurar a segurança dinamicamente no contexto de comuni-cação de objetos na IoT.

Como resultado, este trabalho ainda produziu as seguintes contribuições especí-ficas:

• A construção de um metamodelo para apoiar a especificação de requisitos desegurança em tempo de execução;• A especificação de uma linguagem específica de domínio para modelagem de

requisitos de segurança do usuário em objetos da IoT, denominada TRML (Trust

Requirement Modeling Language);• O projeto de uma arquitetura de middleware baseada em camadas que permite

alterar requisitos de segurança em tempo de execução em objetos na IoT;• Implementação da camada Synthesis Engine (SE) do middleware responsável por

manter o modelo em tempo de execução e pela síntese (transformação) de requi-sitos de segurança, especificado pelo usuário, em comandos que serão usados pelacamada Control and Configuration (CC) do middleware para reconfigurar a segu-rança no contexto de comunicação de objetos na IoT;• A construção de um algoritmo de síntese de requisitos em comandos de reconfigu-

ração de segurança;• Implementação da camada Control and Configuration (CC), usando TLS/SSL como

único protocolo.

1.3 Organização da Dissertação

Esta dissertação está organizada da seguinte forma, o capítulo 2 discute a visãogeral e principais características da IoT. No mesmo capítulo é apresentada a problemáticada segurança na IoT que será ilustrada em um exemplo de cenário hospitalar, o qual possuium sistema healthcare que conecta na IoT diversos dispositivos, como leitos inteligentes.

1.3 Organização da Dissertação 20

O capítulo 3 apresenta os principais conceitos sobre modelos em tempo de execução elinguagens específicas de domínio.

O capítulo 4 discute a abordagem adotada para resolver o problema proposto,no qual é apresentado um metamodelo para modelagem de requisitos de segurançae uma linguagem de modelagem de requisitos de segurança (TRML). Além disso, édiscutida a abordagem usada para seleção de requisitos de segurança que serão usadospara reconfiguração da segurança na comunicação.

O capítulo 5 apresenta uma proposta de arquitetura de middleware usandomodelos em tempo de execução, apresenta o algoritmo de síntese de requisitos e suaestrutura de dados em árvore usada para buscar requisitos de segurança e sessões decomunicação. Ainda neste capítulo, são discutidas a implementação da linguagem demodelagem de requisitos de segurança (TRML) e a implementação da comunicação viasinais entre as camadas do middleware.

O capítulo 6 discute a avaliação de desempenho da camada de Synthesis emum cenário baseado em dados reais. O capítulo 7 resume alguns trabalhos relacionadosque apresentam soluções com propostas de arquitetura para gerenciamento da segurançana IoT, propostas que adotam modelos em tempo de execução na reconfiguração dasegurança e propostas que tratam requisitos de segurança em tempo de execução. E, porfim, o capítulo 8 apresenta conclusões obtidas e os trabalhos futuros.

CAPÍTULO 2Segurança na Internet das Coisas

Este capítulo e o capítulo seguinte apresentam os principais conceitos sobre osquais o presente trabalho foi desenvolvido, sendo que este discute sobre a segurança naInternet das Coisas e o capítulo seguinte sobre modelos em tempo de execução. Destaforma, na seção 2.1, são apresentados os principais conceitos a respeito da Internetdas Coisas e suas principais características. A seção 2.3, discute sobre o problema desegurança na Internet das Coisas e na seção 2.3.2 será apresentado um exemplo que ilustraapenas o problema que estamos interessados. O exemplo corresponde à utilização de umsistema healthcare que conecta na Internet diversos objetos como leitos, macas e pontosde acesso.

2.1 Visão Geral sobre Internet das Coisas

O avanço no crescimento da Internet está fundamentado no paradigma da Inter-net das Coisas (Internet of Things - IoT) o qual abrange uma infraestrutura de hardware,software e serviços que conectam objetos físicos, denominados como coisas à rede decomputadores. Segundo Atzori et al. [5], a ideia básica de IoT consiste na presença deuma diversidade de objetos que interagem e cooperam entre si a fim de atingir um obje-tivo comum. Para tal, compartilham informações utilizando métodos de endereçamentoúnico e protocolos de comunicação padronizados.

Na IoT, as coisas ou objetos devem se tornar participantes ativos no ambiente,onde serão capazes de interagir e comunicar entre elas mesmas, trocar informaçõescoletadas do ambiente, reagindo autonomamente aos eventos do mundo físico real, bemcomo influenciar esse contexto sem intervenção direta do ser humano [5].

A Figura 2.1 ilustra que, além da comunicação e informação a qualquer momentoe em qualquer lugar, na IoT também é possível a conectividade com qualquer coisa.As três dimensões ilustradas nesta figura, influenciam novos exemplos de mobilidade eubiquidade, os quais possuem diferentes atores conectados em diferentes infraestruturade rede, geralmente redes abertas. Com isso, a IoT é um ambiente ubíquo com grandevariabilidade e dinamismo [38].

2.1 Visão Geral sobre Internet das Coisas 22

A incerteza inerente ao ambiente volátil da IoT potencializa o surgimento de no-vas ameaças. De acordo com Viana et al. [56], a grande probabilidade de informações se-rem capturadas por agentes maliciosos durante o tráfego de informações por dispositivosmóveis e ubíquos, aponta para a necessidade de um tratamento eficaz na confidencialidadedestas informações.

Figura 2.1: Dimensões de Comunicação e Compartilhamento deInformação na IoT [41]

A Figura 2.2 apresenta a IoT como um paradigma resultante da interseção detrês visões diferentes: (a) orientada a coisas, (b) orientada à Internet e (c) orientadaà semântica.

A visão no círculo (a) da Figura 2.2 é derivada de uma perspectiva orientadaàs Coisas, compreendendo desde dispositivos elementares, como etiquetas RFID (Radio-

Frequency IDentification), até dispositivos inteligentes, como smartphones. A tecnolo-gia Near Field Communication (NFC), juntamente com RFID, atuadores sem fio e re-des de sensores, são tecnologias usualmente utilizadas por conectar o mundo real com omundo digital. Visando melhorar aspectos de rastreabilidade e comunicação, muitos es-forços estão sendo empreendidos a fim de criar protocolos e padrões globais de comunica-ção. Com este objetivo, Sakamura [44] propôs uma arquitetura baseada em identificadorexclusivo ou único dentro de um escopo específico (uID), cuja ideia principal é o desen-volvimento de soluções para prover visibilidade única e global dos objetos. Assim, a visão

2.2 Desafios para Implantação da Internet das Coisas 23

orientada às coisas pressupõe que os objetos ou coisas serão cada vez mais inteligentes,apresentando capacidades como comportamento autônomo e proativo, sensibilidade aocontexto e comunicação colaborativa [41].

Figura 2.2: Internet das Coisas como Resultado da Convergênciade Diferentes Visões [5]

Enquanto a perspectiva de coisas foca na interação de objetos, a visão de Internet

direciona para uma definição orientada a rede. Nessa visão destaca-se a iniciativa da IPSO(IP for Smart Objects) [55] para promover o Protocolo de Internet (IP) como a tecnologiade rede utilizada para a conexão de objetos ao redor do mundo. Quanto à comunicação eendereçamento, ambos são baseados em padrões da web como HTTP, REST, JSON [28],chamamos de web of things [27]. Por fim, tem-se a visão orientada a semântica, queapresenta como principais desafios interconectar e organizar a informação gerada pelaInternet das Coisas [53].

2.2 Desafios para Implantação da Internet das Coisas

De acordo com Miorandi et al. [38], para tornar efetiva a IoT é necessário aindaconsiderar aspectos como: heterogeneidade dos dispositivos ou coisas, escalabilidade,troca de dados por meio de redes sem fio, economia de energia, rastreamento e locali-zação, auto-organização (capacidade de reagir de forma autônoma a alterações do ambi-ente), interoperabilidade semântica, gerenciamento de dados, segurança e privacidade.

2.3 Segurança na Internet das Coisas 24

De acordo com Stankovic et al. [50], há grandes desafios pela frente na IoT queprecisam ser superados:

Estrutura da Rede Possui limitações na atual arquitetura da Internet, em termos demobilidade, disponibilidade, gerenciamento e escalabilidade.

Segurança, privacidade e confiança Garantir a segurança da IoT em tempo de projetoe tempo de execução; a identificação proativa e proteção de IoT de ataques arbitrários(por exemplo, ataques DoS e DDoS) e abuso; identificação proativa e proteção de IoT

de software mal-intencionado; o controle sobre informações pessoais (privacidade dedados) e controle sobre a localização e movimentação física do indivíduo (privacidade dalocalização); necessidade de tecnologias que aprimoram a privacidade e necessidade deleis de proteção; padrões, metodologias e ferramentas para gerenciamento de identidadesde usuários e objetos; e, por fim, a necessidade de troca de dados críticos e sensíveisde forma protegida, garantindo por exemplo, que objetos se comuniquem em nome dosusuários com serviços que podem confiar;

Gestão de dados Gestão de grande quantidade de informações e mineração de grandevolume de dados para fornecer serviços úteis; projetar uma arquitetura eficiente pararede de sensores e armazenamento; conceber mecanismos de descoberta de dados desensores; criação de protocolos de comunicação de dados de sensores; o desenvolvimentode mecanismos de processamento de fluxo de dados, e mineração de dados de sensor;

Gestão de heterogeneidade Finalmente, a padronização de tecnologias, o gerencia-mento de aplicações, ambientes e dispositivos heterogêneos constituem um grande desa-fio;

Dentre os desafios relacionados à Internet das Coisas, o escopo deste trabalhoenvolve a segurança na comunicação entre objetos, pois a comunicação necessária entreas coisas ou objetos, efetivamente realizadas através das interfaces de rede, abre possibi-lidades de ataques de segurança.

2.3 Segurança na Internet das Coisas

Na IoT, há vários obstáculos significativos que precisam ser superados paraaumentar a sua aceitação por parte dos usuários, sendo o principal deles a segurança. AInternet e seus usuários já estão sob ataques constantes que exploram as suas fraquezas,fato que pode ser mais proeminente na IoT, que incorpora vários dispositivos comrecursos limitados como energia, processamento e memória. Segundo Roman et al. [42],


a popularização da IoT é suscetível ao desencadeamento de novas e engenhosas ameaçasde segurança. O grande desafio é impedir o crescimento de tais ameaças ou pelo menosmitigar o seu impacto.

Os mecanismos tradicionais de proteção, como criptografia leve, protocolos desegurança e garantia da privacidade não são suficientes para IoT [58, 42], porque deacordo com Atzori e al. [5] e Babar et al. [6], ao contrário de um computador tradicional,os objetos de IoT usualmente são dotados de menor capacidade de processamento,memória e energia. Pesquisadores devem analisar os mecanismos dos protocolos desegurança atuais e decidir se tais abordagens são dignas de serem integradas na IoT ou seadaptações, ou até mesmo novos projetos, serão necessárias para atingir os objetivos desegurança.

2.3.1 Requisitos de Segurança Estáticos em Ambientes Dinâmicos

No ambiente de IoT, os objetos podem interagir com outros objetos a qualquermomento e em qualquer lugar, sem se limitar a um único local físico, de modo que elesentram e saem da rede à vontade. A natureza altamente distribuída dos objetos na Internetdas Coisas que utilizam tecnologias limitadas (como processamento, memória e bateria)em áreas públicas, podem criar vulnerabilidades que agentes maliciosos podem explorar.Diante disto, o usuário ao migrar de um ambiente confiável para um ambiente hostil,como sair da rede segura de sua casa com objetos conectados conhecidos e entrar em umarede sem fio pública de aeroporto que conecta diversos dispositivos desconhecidos, podepassar a ter novas necessidades de segurança. No entanto, devido a abordagem de tratarrequisitos de segurança de forma flexível apenas na fase de projeto e na fase de construçãoimplementá-los de forma embutida e rígida, o usuário não possui meios para alterar eimpor seus requisitos de segurança em aplicações e serviços diante de um ambiente hostil.

Cada vez mais, não é suficiente fixar requisitos de segurança do usuário estati-camente, porque eles irão mudar em tempo de execução juntamente com as mudanças noambiente. Além disso, existe uma incerteza crescente sobre o ambiente dinâmico, comoocorre na IoT, de modo que algumas ameaças podem não ser previstas. Neste ambiente, asaplicações precisam garantir que os requisitos de segurança continuarão sendo satisfeitosantes, durante e depois de uma mudança dinâmica no ambiente.

Desse modo, o usuário ao interagir com dispositivos na IoT, pode se depararcom uma situação hostil e imprevisível no ambiente que poderá levá-lo a ter necessidadesespecíficas de segurança para poder confiar em outros dispositivos, como, por exemplogarantir que seja usado na comunicação um determinado nível de criptografia paraeconomizar recursos de seu dispositivo (energia, processamento ou plano de dados), oupara poder se comunicar com o mesmo nível de segurança de outro dispositivo ou, até


mesmo, impor o uso de níveis mais sofisticados de segurança em uma comunicação, quepode implicar no uso de algoritmos criptográficos que usam maiores chaves secretas.Portanto, para que as necessidades de segurança do usuário sejam atendidas e que osusuários se mantenham seguros, os objetos na IoT devem ser flexíveis o suficientepara permitir que os requisitos de segurança sejam alterados pelo usuário em tempo deexecução para atender às suas necessidades de segurança.

Dentre os requisitos de segurança para IoT, este trabalho foca nos requisitosde segurança voltados para autenticação de dispositivos e confidencialidade dos dadostrocados na comunicação.

2.3.2 Exemplo

Para ilustrar os problemas levantados, considere um hospital chamado Hospitalde Urgências Conectado (HUCON) com um sistema healthcare que conecta na IoT

diversos objetos como portas, leitos e macas. Os leitos e as macas inteligentes fornecemdiversas funcionalidades como acesso a dados vitais coletados através de sensores,acesso ao prontuário e emissão de alertas em caso de emergência. Essas funcionalidadespodem ser acessadas por meio da Internet pelos seus familiares e profissionais de saúdeautorizados, como enfermeiras e médicos. Além disso, as informações do quadro depacientes hospitalizados e a localização de seus respectivos leitos, no HUCON, podem servistas por visitantes através de um painel inteligente na recepção do hospital e acessadaspelos profissionais de saúde por meio de seus computadores e dispositivos móveis.

Quando o sistema healthcare foi implantado no HUCON, os objetos foramconfigurados para usar a segurança mínima, por exemplo, usando criptografia com chavede 16 (dezesseis) bits e sem autenticação durante o atendimento de pacientes no dia adia. Com essa configuração de segurança, os objetos conectados poupariam bateria sem anecessidade de recargas constantes, permitindo atender maior número de pacientes.

A Figura 2.3 ilustra o ambiente do HUCON com o sistema healthcare implan-tado. A Figura 2.3 a) ilustra o hospital em um dia comum, com alguns de seus objetoscomo leitos inteligentes, macas inteligentes, portas inteligentes nas UTIs e diversos pon-tos de conexão sem fio que fazem parte do sistema healthcare.


a) dia comum b) mudança inesperada

Figura 2.3: Objetos no Ambiente de IoT do Hospital HUCON

Com a internação emergencial de uma celebridade, o hospital e suas redondezaspassam a contar com presença da imprensa, de fãs e curiosos nos arredores, algunsdeles atuando para obter informações sigilosas dos sistemas computacionais do hospital,tornando o paciente e o hospital potenciais vítimas de suas ações, conforme ilustrado pelaFigura 2.3 b). Além disso, com os novos visitantes do hospital, houve um aumento nonúmero de objetos que participam da rede do hospital ou estão no raio de ação de suasredes sem fio, como smartphones, tablets e câmeras que entram e saem do ambiente atodo instante.

Diante desse ambiente hostil, é necessário que a configuração de segurançausada pelo hospital seja alterada rapidamente para dar maior segurança ao novo paciente.Medidas deverão ser tomadas, como o uso de algoritmos de segurança mais fortes eseguros, para proteger informações de grande interesse para possíveis agentes maliciosos.

Com a alta do novo paciente, as rotinas do hospital tendem a se normalizar,levando à necessidade de alterar a configuração de segurança para segurança mínima,visando poupar recursos dos objetos conectados do hospital, como a bateria para evitara necessidade de recargas constantes, permitindo atender maior número de pacientes.No entanto, configurações de segurança dos sistemas são usualmente difíceis de seremmodificadas, sobretudo porque muitas delas são embutidas estaticamente no código fontedas aplicações e serviços.

Conforme ilustrado no exemplo, aplicações e serviços de objetos em ambien-tes IoT podem ter a necessidade de alterar a configuração de segurança rapidamente eem tempo de execução diante de mudanças imprevisíveis no ambiente. A mudança rápidana configuração da segurança pode ser uma exigência do usuário ao se deparar com umasituação repentina que o deixe vulnerável. Para isso, seria necessário, no mínimo, uma

2.4 Conclusão 28

solução que ofereça um meio para o usuário final alterar as configurações de segurançaem tempo de execução e que as alterações surtam efeito dinamicamente.

Neste trabalho, requisitos de segurança representam as necessidades de segu-rança dos objetos na IoT em termos de restrições impostas a outros objetos para seremconsiderados confiáveis para uma comunicação. Em particular, consideramos requisitosde segurança que descrevem as necessidades de autenticação dos objetos e confidencia-lidade da comunicação. Um requisito deve especificar de que maneira os objetos conec-tados na IoT confiam ou podem confiar entre si para se comunicarem. Por exemplo, orequisito “Todas as entidades autenticadas pelo hospital podem comunicar com o leito

inteligente” especifica uma restrição de autenticação.

2.4 Conclusão

Este capítulo discutiu o conceito de Internet das Coisas, as suas principais ca-racterísticas e seus principais desafios de segurança. A compreensão das característicasdinâmicas do ambiente de Internet das Coisas e o entendimento do problema de requi-sitos de segurança tratados de forma estática e embutida no código fonte, de aplicaçõese serviços em entidades na Internet das Coisas, é fundamental para a compreensão destetrabalho, que visa tratar requisitos de segurança como entidades externas ao software cor-respondente e permitir adaptação dinâmica e transparente da comunicação para satisfazera requisitos de segurança modificados pelo usuário em tempo de execução.

CAPÍTULO 3Modelos em Tempo de Execução

Neste capítulo, são apresentados alguns dos conceitos em que esse trabalho sebaseou em seu desenvolvimento. Estas definições são fundamentais neste trabalho, queas utiliza no desenvolvimento de uma abordagem dirigida por modelos para alteraçãode requisitos em tempo de execução com reflexo dessas mudanças na segurança dacomunicação entre objetos na IoT.

Na seção 3.1 são apresentados os principais conceitos e características da abor-dagem de modelos em tempo de execução. A seção 3.2 fornece uma visão geral sobremetamodelos que definem modelos em tempo de execução e como eles serão usadosneste trabalho. Por fim, a seção 3.3 discute sobre implementação de linguagem específicade domínio, usada para instanciar o metamodelo em um modelo em tempo de execução.

3.1 Visão Geral

A constante variação dos ambientes, como o ambiente de IoT, é um problemainerente ao gerenciamento de sistemas e, principalmente, em aplicações ubíquas e perva-sivas, fazendo-se necessária a adaptação do sistema às mudanças do ambiente em tempode execução.

De acordo com France et al. [19], um modelo pode oferecer representaçõesmais apropriadas dos elementos de um sistema em execução. Por esse motivo, modelostêm sido empregados para lidar com a complexidade de aplicações que precisam sermonitoradas, adaptadas, reconfiguradas e evoluídas durante a execução [46, 19].

Uma abordagem promissora para gerenciar essa complexidade é desenvolvermecanismos de adaptação por meio de modelos em tempo de execução, que fornecemrepresentações apropriadas dos elementos de um sistema em execução, proporcionandoa adaptação e evolução de um sistema sem a necessidade de interromper seu ciclo [9].Dessa forma, modelos em tempo de execução podem ser úteis para que desenvolvedo-res ou outros agentes, como o usuário, possam compreender, configurar e modificar ocomportamento e estado de aplicações em execução.

3.1 Visão Geral 30

De acordo com Blair et al. [9], uma característica importante de modelos emtempo de execução é que eles são diretamente relacionados com a reflexão computaci-onal, dado que ambos buscam definir e criar representações que refletem o sistema emexecução. Usando modelos em tempo de execução, um sistema pode ter uma abstraçãocausalmente conectada que é a representação do próprio sistema na forma de um ou maismodelos relacionados e mantidos sincronizados com o sistema em execução. Dessa forma,o modelo está causalmente conectado com o sistema, de modo que as mudanças no sis-tema são imediatamente refletidas no modelo e alterações no modelo são refletidas nosistema em tempo de execução.

Modelos em tempo de execução também podem ser utilizados para corrigir errosde projeto ou para implantar novas decisões de projeto em um sistema em execução.Da perspectiva de evolução do software durante sua execução, um modelo em tempode execução pode ser visto como modelo de desenvolvimento ao vivo, que permite aevolução dinâmica do mesmo [9].

Há uma variedade de técnicas que vêm sendo investigadas sobre modelos emtempo de execução [9], as quais são apresentadas a seguir em algumas dimensões chaves.

Estrutura x comportamento —Como na reflexão computacional, modelos tendem ase concentrar na estrutura e em aspectos comportamentais do sistema. Os modelos estru-turais tendem a enfatizar a forma como um software é construído. Já os modelos compor-tamentais partem de uma ótica de como o sistema executa, podendo ser representados emtermos de fluxos de eventos.

Procedural x Declarativa —Outra opção é o modelo procedural, que reflete a estruturae o comportamento do sistema detalhando os procedimentos/passos a serem executados,ou o modelo declarativo, por exemplo, em termos de objetivos do sistema, descrevendo atarefa a ser executada, sem se preocupar com detalhes de como o modelo será executadopelo mecanismo de execução de modelos.

Funcional x Não-funcional —A maioria dos modelos baseia-se nas funcionalidadesdo sistema, mas há também a necessidade de modelos que capturem e representemcaracterísticas não funcionais. Como exemplo, no campo de desempenho e sistemas,pesquisadores podem analisar a forma como modelos em tempo de execução podem serusados para otimizar a execução do sistema. De igual modo, há a necessidade de modelosque capturam aspectos do sistema, tais como a segurança.

Formal x Informal —Alguns modelos são inspirados na matemática computacional,enquanto outros são derivados de modelos de programação ou abstração de domínios. Os

3.2 Metamodelo 31

modelos formais possuem a vantagem de apoiar o raciocínio automatizado sobre o estadoe o comportamento do sistema, mas podem não capturar ou expressar adequadamenteos conceitos do domínio requerido de uma forma simples e acessível, por exemplo, aosusuários finais. Modelos informais são mais acessíveis aos usuários, porém são maisinconsistentes e incompletos que os modelos formais.

Modelos em tempo de execução , embora possam ser qualquer representaçãoútil do sistema, podem ser usados para apoiar no monitoramento e controle do estadodinâmico de sistemas na IoT durante a execução ou até mesmo para entender o fenômenocomportamental desses sistemas em tempo de execução. As pesquisa existentes sobremodels@runtime tendem a se concentrar em estruturas de software e representaçõesfuncionais de tais estruturas [7, 60, 40, 22, 23]. No entanto, existe uma necessidadeigual para modelos capturarem e representarem as características não funcionais. Porexemplo, no campo de segurança, modelos em tempo de execução podem ser usadospara representar os mecanismos de segurança ou, em outro nível de abstração, até mesmorepresentar requisitos de segurança implementados em aplicações na IoT para seremanalisados e alterados em tempo de execução.

Assim como no trabalho de Bencomo et al. [7] e no trabalho de Inverardi eMori [30], a visão de modelos em tempo de execução adotada por esta dissertação, elevao nível de abstração ao nível de requisitos, com o foco em requisitos de segurança dousuário. Para conseguir isso, um modelo dos requisitos de segurança do usuário deve sermantido enquanto o sistema está em execução. Além disso, este trabalho está interessadoem utilizar modelos em tempo de execução para representar objetos do ambiente em queo usuário está inserido.

Com isso, por meio de modelos em tempo de execução, requisitos de segurançaserão tratados como objetos em tempo de execução, permitindo que sejam alterados emtempo de execução pelo usuário para atender suas necessidades de segurança diantede uma mudança inesperada e repentina no ambiente. Por fim, modelos em tempo deexecução podem permitir que mudanças nos requisitos sejam refletidas dinamicamenteem alterações nos mecanismos de segurança do sistema.

3.2 Metamodelo

Models@runtime podem ser representados de forma gráfica ou textual e sãoformalizados por uma linguagem de modelagem cujas construções são definidas por ummetamodelo [46]. Um metamodelo é a especificação de um modelo para uma classede domínio de sistema. Em outras palavras, um metamodelo especifica o que pode serrepresentado pelos modelos em tempo de execução por meio de uma certa linguagem demodelagem.

3.2 Metamodelo 32

Um metamodelo define o que pode ser expresso em um modelo em termosde construções para representação dos objetos do domínio e seus relacionamentos. Eleexpressa as características de um domínio e pode ser utilizado para instanciar diferentesmodelos para um mesmo domínio. Desta forma, pode-se dizer que um modelo é umainstância de um metamodelo.

Com a popularização da abordagem dirigida por modelos, fez-se necessária a pa-dronização da construção de modelos e metamodelos, sendo que uma das iniciativas maisimportantes nesse sentido foi conduzida pelo OMG (Object Management Group) [25],por meio de uma arquitetura de metamodelagem denominada MOF (Meta-Object Faci-

lity) [37], ilustrada na Figura 3.1, onde os elementos em uma determinada camada sãodefinidos como instâncias de elementos da camada imediatamente superior. A camadamais superior, denominada M3, também integra a especificação da MOF, e representa ometa-metamodelo, que pode ser utilizado para a construção de metamodelos. O modeloda camada M3, também denominado de modelo MOF, é formalizado por meio de suaspróprias abstrações, o que elimina a necessidade de um outro nível de meta-modelagem.

A especificação da MOF apresenta uma arquitetura em quatro camadas, ondecada elemento de uma camada inferior é uma instância de algum elemento da camadasuperior. As camadas podem ser descristas da seguinte forma:

• Camada M3: contém o meta-metamodelo MOF, que pode ser utilizado para aconstrução de metamodelos. O modelo da camada M3, também denominado demodelo MOF, é formalizado por meio de suas próprias abstrações, o que elimina anecessidade de um outro nível de meta-modelagem.• Camada M2: possui um metamodelo, utilizado para modelagem de sistemas para

domínio específico. Em outras palavras, é a linguagem utilizada para a definiçãode modelos. A UML (Unified Modeling Language) é um exemplo de linguagem demodelagem definida a partir do modelo MOF. Esses metamodelos são utilizadospara construir os modelos que integram o nível M1.• Camada M1: composta por modelos que descrevem aplicações e sistemas usando

as definições presentes em M2. Esses modelos representam os objetos existentes nonível M0. Desta forma, essa camada contém, por exemplo, as classes de um sistemaorientado a objetos ou as definições de tabelas de um banco de dados relacional.• Camada M0: integrada por objetos que representam objetos do mundo real que

formam o sistema em tempo de execução, os quais são instâncias dos objetoscriadas a partir das definições presentes na camada M1.

Outra definição proveniente da especificação da MOF, é o padrão para represen-tação de modelos no formato XMI (XML Metada Interchange), utilizado para o intercâm-bio de modelos usando XML.

3.3 Implementação de Linguagem de Modelagem Específicas de Domínio 33

Figura 3.1: Arquitetura de Metamodelagem - MOF [37]

3.3 Implementação de Linguagem de Modelagem Espe-cíficas de Domínio

Uma linguagem de modelagem específica de domínio (Domain Specific Mode-

ling Language - DSML) é um conceito importante para o entendimento deste trabalho,pois modelos em tempo de execução são instanciados por meio de uma DSML que usadefinições descritas no metamodelo para um determinado domínio da aplicação [47].Com isso, DSML é especificada pelo metamodelo e é uma das formas de instanciar mo-delos em tempo de execução. Assim sendo, DSMLs representam aspectos estruturais ecomportamentais do domínio da aplicação.

Diferentemente das linguagens de propósito geral, que podem ser empregadasem um grande conjunto de tarefas em vários domínios, DSMLs são linguagem geralmenteprojetadas especificamente para executar uma tarefa em um determinado domínio. Domí-nios podem ser categorizados em domínios técnicos, como persistência, interface gráficade usuário, banco de dados, ou em domínios de negócio, como telecomunicação, bancárioe redes elétricas inteligentes. De acordo com Mernik et al. [36] e Van Deursen et al. [54],linguagens específicas de domínio oferecem um maior poder expressivo em seu domíniofocado. Por exemplo, a Microgrid Modeling Language (MGridML) é uma DSML para odomínio de microgrids [2].

Grande parte do sucesso no emprego de abordagens dirigidas por modelos estáassociada à utilização de DSMLs [18]. O uso dessa abordagem aplicada a um domínio


específico permite atingir um alto grau de automatização no processamento de modelos.Uma DSML captura os conceitos, relacionamentos, restrições e semânticas do domínioda aplicação e permite que os usuários programem de forma declarativa por meio daconstrução de modelos [11]. As DSMLs podem ser usadas em duas finalidades distintas:automatizar a geração de código-fonte com base em um modelo específico de domínioou interpretar em tempo de execução modelos específicos de domínios para identificar asnecessidades dos usuários. Este trabalho está interessado na segunda finalidade.

Semelhante a outras linguagens, de acordo com Kleppe [32], uma DSML podeser definida por meio de três componentes principais: sintaxe concreta, sintaxe abstrata esemântica. A Figura 3.2 ilustra a estrutura de uma linguagem, na qual a semântica estácontida na sintaxe abstrata e ambas estão contidas na sintaxe concreta.

Semântica

Sintaxeabstrata

Sintaxeconcreta

Figura 3.2: Anatomia de uma Linguagem [24]

A sintaxe abstrata define os elementos e conceitos disponíveis na linguagem ecomo eles estão relacionados, sendo equivalente a uma gramática de uma linguagemde programação. Além disso, a sintaxe abstrata também inclui regras que limitam osmodelos que podem ser criados com a DSML. Normalmente, são utilizadas técnicas demetamodelagem para definir a sintaxe abstrata.

A sintaxe concreta representa as notações textuais ou gráficas dos elementos dalinguagem, definidos pela sintaxe abstrata [49]. A sintaxe concreta possui a representaçãoreal dos elementos presentes na sintaxe abstrata presente no metamodelo [49], seja deforma gráfica ou textual. Um exemplo é a UML [26]: ela possui uma notação gráficaconsistindo de caixas e setas que é a sua sintaxe concreta, enquanto sua sintaxe abstratacontém construções como classe, atributo, método, e os relacionamentos entre estasconstruções. A Figura 3.3, extraída do trabalho de Izquierdo e Cabot [31], ilustra a sintaxeconcreta e a sintaxe abstrata de uma DSML.


Figura 3.3: Exemplo de Sintaxe Abstrata e Concreta de umaDSML para Domínio de Transporte [31]

A semântica também é comumente tratada separadamente como semântica está-tica e semântica dinâmica. A semântica estática, que descreve os significados e comporta-mentos dos elementos presentes no metamodelo, como restrições e regras, e a semânticadinâmica define o significado dos modelos ao serem executados.

A sintaxe abstrata e a semântica estática de uma DSML são comumente forma-lizadas por meio de um metamodelo, o que descreve um conjunto de abstrações e comoestas se relacionam. A Figura 3.4 mostra os relacionamentos entre os conceitos de mo-delo, do metamodelo e da DSML.

Domínio

Meta-metamodelo

MetamodeloSintaxeabstrata

Semânticaestática

DSMLSintaxeconcreta

ModeloSemânticaoperacional

<<instanceof>>

especificadobaseado em

respeita

pega o significado de

especificado baseado em

<<instanceof>>

subdomínio

0..*

Figura 3.4: Modelagem e DSML [49]

Segundo Clark et al. [12], existem diferentes abordagens para descrever a se-mântica dinâmica de linguagens em um metamodelo, as quais podem ser agrupadas em


categorias: semântica traducional, semântica operacional, semântica por extensão, semân-tica denotacional.

Semântica por tradução — A semântica da DSML é definida pela tradução de seusconceitos em conceitos de outra linguagem que possui uma semântica precisa. O mapea-mento é conseguido por meio de transformações do modelo.

Semântica operacional — Uma semântica operacional descreve como modelos escri-tos em uma linguagem podem ser executados diretamente. Isto envolve a construção deum interpretador. Com isso, a semântica operacional permite modelar o comportamentooperacional dos elementos descritos pela linguagem. A semântica operacional é incorpo-rada ao interpretador ou mecanismo que processa e executa os modelos.

Semântica por extensão — Permite a descrição de uma linguagem como uma extensãode outra linguagem. Além disso, ela pode estender a semântica, acrescentando novascapacidades, por exemplo. O benefício deste método é que os complexos conceitossemânticos podem ser reutilizados com o mínimo de esforço. Por exemplo, uma entidadeempresarial não precisa definir o que significa criar novas instâncias, mas pode herdar acapacidade de uma Class. A abordagem por extensão tem algo em comum com a noçãode um perfil [26]. Um perfil proporciona um conjunto de estereótipos, que podem servistos como sub-classes de UML ou elementos do modelo. No entanto, por realizar aextensão no nível de metamodelo, uma maior expressividade é fornecida para o usuário,que pode adicionar arbitrariamente ricas extensões semânticas para o novo conceito.

Semântica denotacional — É definida pelo mapeamento entre as construções dalinguagem e o domínio semântico que envolve elementos matemáticos representandoelementos primitivos da semântica. Ela associa objetos matemáticos, tais como números,tuplas, ou funções, com cada conceito da linguagem.

A linguagem de modelagem específica de domínio é um tipo especial de DSL

(Domain-specific Languages) que pode ser utilizada para modelagem de sistemas especí-ficos de domínio. Ao contrário de uma linguagem de finalidade geral, como C# ou Java,uma DSL foi projetada para expressar as instruções em um determinado problema espaçoou domínio como consulta (SQL), formatação de texto (HTML) e estruturação de dados(XML).

Neste contexto, DSLs podem ser externas e internas (embutida). Fowler [17] dizque DSL externa é uma linguagem separada da linguagem principal da aplicação com qualela trabalha. Normalmente, uma DSL externa possui uma sintaxe customizada, mas usa asintaxe de outra linguagem também comum, como XML e UML são escolhas frequentes.

3.4 Conclusão 37

Um script em uma DSL externa costuma ser analisado sintaticamente por um código naaplicação hospedeira usando técnicas de análise sintática textual. Expressões regularese SQL são exemplos de DSL externa.

Segundo Fowler [17], uma DSL interna é uma maneira específica de usar umalinguagem de propósito geral. Um script em uma DSL interna é um código válido em sualinguagem de propósito geral, mas usa apenas um subconjunto dos recursos da linguagemem um estilo determinado para tratar de um pequeno aspecto do sistema como um todo.O resultado de uma DSL interna deve ser parecido com uma linguagem customizada enão coma a linguagem hospedeira. Algumas bibliotecas Ruby tem o estilo de uma DSL

interna, como o Ruby Rails [52].Dentre os principais benefícios do uso de DSL pode-se citar que fornece uma

linguagem precisa, e ao mesmo tempo, clara para lidar com domínios, e pode ajudar amelhorar a comunicação com clientes e usuários de um sistema.

DSML é uma abordagem específica de DSL, destinada à modelagem de domíniosespecíficos, sendo que ambas utilizam técnicas parecidas, mudando apenas o nível deabstração; enquanto uma programa em domínio específico a outra modela em um domínioespecífico. Com isso, podemos usar técnicas de construção de DSL interna, como atécnica de encadeamento de métodos ou a de comando-consulta [17], para embutiruma DSML em uma linguagem de propósito geral, na qual serão embutidas construçõesde modelagem com o propósito de criar modelos em tempo de execução de alto nível queserá interpretado e convertido em sentenças de uma linguagem de programação. O fatode uma uma DSL interna ser textual não interfere na técnica de embutir uma DSML emuma linguagem de propósito geral, como Java. Apesar de DSL embutida ser limitada porter de estar em conformidade com a estrutura sintática da linguagem hospedeira, a suacurva de aprendizado pode ser favorável dado que ela usa recursos de uma linguagemprovavelmente conhecida.

3.4 Conclusão

Este capítulo discutiu conceitos sobre modelos em tempo de execução, que em-bora possa ser qualquer representação útil do sistema, este trabalho tem interesse emmodelos em tempo de execução para representar requisitos de segurança que especificamas necessidades do usuário a cerca de autenticação dos objetos do ambiente e confidenci-alidade na comunicação dentre objetos no ambiente.

Além disso, este capítulo discutiu que DSML pode ser embutida em uma lingua-gem de propósito geral por meio de técnicas de implementação de DSLs interna. Essaabordagem, se comparada com a abordagem tradicionalmente usada [47], permite im-plementar uma DSML em menor espaço de tempo, uma vez que não é necessário criar

3.4 Conclusão 38

um parser, compilador ou interpretador, pois usa os da linguagem hospedeira. Por outrolado, com essa estratégia perde-se liberdade de sintaxe, dado que a DSML tem que teruma sintaxe compatível com a linguagem hospedeira.

Esses conceitos são fundamentais para compreensão da solução proposta poreste trabalho. Com essa base teórica, junto com aquela apresentada pelo capítulo 2, nopróximo capítulo será apresentado a abordagem de requisitos de segurança em tempo deexecução para resolver o problema proposto.

CAPÍTULO 4Requisitos de Segurança em Tempo de Execução

Os requisitos de segurança em objetos na IoT, quando são implementados,geralmente estão ocultos do usuário, impedindo-o de sua ciência e de qualquer alteraçãopara atender uma possível necessidade de segurança. Diante disso, propomos tratarrequisitos de segurança como entidades externas ao dispositivo, manipuláveis em tempode execução, permitindo ao usuário alterar requisitos de segurança em objetos na IoT paraque a segurança desses objetos seja reconfigurada dinamicamente. Com isso, o usuáriopoderia controlar as configurações de segurança subjacentes indiretamente, por meio daalteração dos requisitos de segurança.

Este capítulo apresenta as abordagens adotadas no desenvolvimento de umasolução para o problema proposto por este trabalho. A seção 4.1 discute a definiçãode requisitos de segurança adotada por este trabalho. A seção 4.2 apresenta como aabordagem de modelos em tempo de execução será utilizada para resolver o problemaproposto. Por fim, a seção 4.3 apresenta a linguagem de modelagem de requisitos desegurança proposta neste trabalho para especificação de requisitos na forma de modelosem tempo de execução.

4.1 Requisitos de Segurança

Neste trabalho, um requisito de segurança representa a necessidade de segurançade um objeto na IoT em termos de restrições impostas a outros objetos remotos paraserem consideradas confiáveis para comunicação. Em particular, consideramos requisitosde segurança que descrevem as necessidades de autenticação de objetos na IoT e deconfidencialidade da comunicação. Um requisito deve especificar de que maneira osobjetos na IoT confiam ou podem confiar entre si para comunicarem umas com as outras.Por exemplo, considere o requisito de um leito inteligente “confie em smartphones para oenvio e recebimento de dados se usar criptografia baixa (chave de 16 bits)’, diz que o leitointeligente confiará, para troca de dados, apenas em smartphones que usam criptografiano mínimo baixa na comunicação.

4.2 Requisitos de Segurança na Forma de Models@runtime 40

Dessa forma, em um requisito de segurança devem constar três informações, asquais são definidas formalmente na seção 4.3:

• Escopo: define o tipo de objeto na IoT ao qual se destina o requisito, porexemplo, Smartphone e Ponto de Acesso. Os tipos de objetos na IoT são definidosna seção 4.3;• Ação: define a interação entre o dispositivo do usuário e outro dispositivo no

ambiente que será permitida caso as exigências sejam atendidas, como enviar e

receber dados e conectar a um ponto de acesso.• Condição: define as exigências de segurança que deverão ser atendidas;

– Autenticação: atributo que permite dois valores para informar se o objetoremoto a que se destina o requisito deve estar autenticado para que a Açãoseja permitida, ou se ele não precisa estar autenticado;

– Confidencialidade: informa o nível de confidencialidade desejado, comonenhum, no mínio baixo, no mínimo médio e alto;

4.2 Requisitos de Segurança na Forma de Mo-dels@runtime

Este trabalho adota models@runtime para representar requisitos de segurançado usuário bem como os elementos do ambiente da IoT, como aplicações, serviços edispositivos.

Desta maneira, a solução proposta neste trabalho usa da abordagem modelosem tempo de execução para permitir que alterações sejam realizadas nos requisitos desegurança e, com a conexão causal, tais alterações sejam refletidas na configuração desegurança de objetos na IoT e suas respectivas aplicações ou serviços.

A Figura 4.1 ilustra a alteração da configuração de segurança de objetos na IoT

mediante a especificação de modelos na forma de requisito de segurança. A parte superiorda figura ilustra os objetos do usuário que possuem sessões de comunicação com osobjetos no ambiente de IoT, ilustrados na parte inferior da figura. Nesta figura, assessões de comunicação são representadas pelos círculos nas cores verde, azul, amareloe vermelho, sendo que cada cor representa um nível de confidencialidade (nível de forçada encriptação). Na solução proposta por este trabalho, models@runtime são usados pararepresentar requisitos de segurança que podem ser alterados em tempo de execução pelousuário e refletir as mudanças nas sessões de comunicação, também representadas pormodelos. Além disso, os modelos em tempo de execução são usados para prover umavisão das entidades presentes no ambiente de IoT em que o usuário está inserido.


Figura 4.1: Visão Geral da Reconfiguração da Segurança Medi-ante Especificação de Requisito de Segurança

4.2.1 Metamodelo de Requisito de Segurança e Sessão de Comunica-ção

O metamodelo proposto por este trabalho tem como papel definir construçõessobre o que pode ser expresso por um modelo de segurança no domínio de segurançana IoT. O metamodelo proposto por este trabalho permite construir modelos que definemobjetos na IoT, como smartphones e pontos de acesso, bem como suas sessões decomunicação e seus respectivos requisitos de segurança.

A Figura 4.2 mostra o diagrama de classes do metamodelo. Um dos principaiselementos é a classe Requirement, que define um requisito de acordo com a definiçãodada na seção 4.1. Essa classe agrega os elementos Scope, Action e Condition.


Figura 4.2: Elementos do Metamodelo para Especificar Requisitosde Segurança

A classe Scope define os tipos de objetos remotos que devem cumprir asexigências de segurança especificadas no requisito para comunicar com um objeto localna IoT dono do requisito.

Por exemplo, no requisito REQ_A da Listagem 4.1, foi especificado para umleito inteligente que o escopo desse requisito é o smartphone. Com isso, sempre queum smartphone se comunicar com o leito inteligente ou vice-versa, esse requisito seráusado para configurar a segurança da sessão de comunicação.

1 Confie em smartphones para o envio e recebimento de dados

apenas se usarem encriptação forte.

Listagem 4.1: REQ_A, exemplo de requisito

A classe Condition estabelece uma condição de autenticação ou confidencia-lidade, ou ambas, no requisito que deve ser satisfeita pelos envolvidos na comunicaçãoou conexão para que uma sessão seja estabelecida. Por exemplo, no requisito REQ_A, acondição é usar encriptação forte. Dessa forma, para que a sessão seja estabelecida, osenvolvidos na comunicação (especificados pela classe Entity) deverão usar encriptaçãoforte. Encriptação forte pode, por exemplo, representar encriptação simétrica com chavede tamanho maior ou igual a 256 bits bem como encriptação média e baixa podem signi-ficar encriptação simétrica com chave de tamanho maior igual a 128 e 64 bits respectiva-mente. Conexão representa a conexão de um objeto na IoT em um meio de comunicaçãocomo ponto de acesso e Ethernet, tornando-o hábil a iniciar troca de dados por meio deportas de comunicação e sockets.


A classe Action define a ação que será permitida caso a condição do requisitoseja satisfeita pelos envolvidos na comunicação ou conexão. No requisito REQ_A, a açãoé "envio e recebimento de dados". Nesse exemplo, se as aplicações executando em umleito inteligente e um smartphone usarem encriptação forte, elas poderão trocar dados.

A classe Session representa uma sessão de comunicação associada à configu-ração de segurança e objetos na IoT, definidos pela classe Configuration e Entity

respectivamente. Uma sessão tem a responsabilidade de manter informações a respeito daconfiguração de segurança e os participantes de uma comunicação. Já uma configuraçãode segurança é usada para alterar as características de segurança da comunicação. Ela éresultado do processamento de requisitos de segurança pelo middleware (capítulo 5) noqual são extraídas regras de autenticação e confidencialidade de alto nível ( linguagemapresentada na seção 4.3) que são mapeadas em configurações de segurança de baixo ní-vel (conjunto de cifras) para serem aplicadas no canal de comunicação. Por exemplo, oleito inteligente de um hospital pode ter como requisito "Confiar no envio e recebimento

de dados de smartphones se na comunicação usar no mínimo encriptação fraca", quandoum o smartphone de um médico for enviar ou receber dados do leito inteligente esserequisito será processado e, com isso será extraída a regra de confidencialidade "no mí-

nimo encriptação fraca" que está mapeada para uma configuração de confidencialidadede acordo com as configurações do middleware, podendo resultar em um determinadoconjunto de cifras criptográficas.

A classe Entity representa um objeto na IoT, sendo que os tipos de objetos sãodefinidos na seção 4.3, como Smartphone, Thing e Application. A classe Entity é com-posta por características definidas pela classe Feature, por exemplo "sensor de luminosi-dade", display, sistema operacional android e capacidade de telefonar. A classe Featurepossui como atributo uma categoria representada pela classe FeatureCategory e umatipo representado pela classe FeatureType. As possíveis FeatureCategory de umaFeature são IO_RESOURCE, SENSOR e ACTUATOR, bem como as possíveis FeatureTypede uma Feature são HARDWARE e SOFTWARE.

A classe Attribute representa elementos que definem a estrutura das demaisclasses do metamodelo. Um Attribute representa um nome e um valor.

A Figura 4.3 ilustra um exemplo de instância do metamodelo. Essa instânciapode ser criada a partir da linguagem de modelagem de requisitos de segurança, que serádiscutida na seção 4.3.


Figura 4.3: Exemplo de Instância do Metamodelo

Diferentemente das abordagens citadas na literatura, o metamodelo proposto poreste trabalho na seção 4.2.1, não foi criado usando o metameta-modelo MOF e tambémnão foram usados os princípios e ferramentas tradicionais como Eclipse Modeling

Framework, que fornece um conjunto de ferramentas para construção e processamentode modelos, e o metamodelo denominado Ecore [51]. O metamodelo proposto poreste trabalho foi criado juntamente com a linguagem específica de domínio interna

apresentada na seção 4.3.A Figura 4.4, ilustra a comparação da (i) pilha de metamodelagem da arquite-

tura MOF com a (ii) pilha da modelagem adotada por este trabalho. O diagrama (iii)ilustrado nessa figura é um exemplo de modelo em cada camada da pilha da modelagemadotada por este trabalho.

Na camada M3, a arquitetura de metamodelagem proposta pela OMG [25], con-tém o modelo MOF padrão, que é um meta-metamodelo, ou seja, a linguagem utilizadapara a definição de metamodelos. Enquanto que na arquitetura de metamodelagem ado-tada por este trabalho, utiliza-se a linguagem Java como meta-metamodelo para criar alinguagem de modelagem de requisitos, discutida na seção 3.3.

Na camada M2, da arquitetura proposta por este trabalho, temos o metamodeloutilizado para modelar requisitos de segurança, sessões de comunicação e objetos doambiente de IoT.

4.3 Linguagem de Modelagem de Requisitos de Segurança 45

A camada M1 contém os modelos de requisitos, sessões de comunicação eobjetos do ambiente de IoT usando as definições presentes em M2.

A camada M0 possui as entidades ou objetos que formam o sistema em tempo deexecução, os quais são instâncias de sessões de comunicação e objetos na IoT definidas emM1. Os requisitos de segurança modelados em M1 são usados para configurar a segurançada sessão em M0.

Figura 4.4: (i) Arquitetura de Metamodelagem MOF [37] Pro-posta pela OMG [25]; (ii) Arquitetura de Metamo-delagem Proposta Neste Trabalho e (iii) Exemplo deModelo Gerado a Partir da Arquitetura (ii)

4.3 Linguagem de Modelagem de Requisitos de Segu-rança

A partir do metamodelo ilustrado na Figura 4.2, definimos a Linguagem deModelagem de Requisitos de Segurança, Trust Requirement Modeling Language (TRML).Como este trabalho não utiliza a especificação MOF para construir e validar os modelos,a TRML é uma linguagem específica de domínio criada para modelar os requisitosde segurança de forma textual. Neste primeiro momento, a manipulação textual foiconsiderada a forma mais fácil do usuário modelar seus requisitos de segurança.

Na TRML, um requisito é especificado com o uso das cláusulas TRUST_IN, FOR,

IF e MANDATORY. Cada cláusula é mapeada para um elemento presente no metamodeloilustrado na Figura 4.2. Por exemplo, a cláusula TRUST_IN instancia a classe Scope, acláusula FOR instancia a classe Action, a classe IF instancia a classe Condition e acláusula MANDATORY é o atributo Priority da classe Requirement.


1 Requirement ::= Scope Action Condition Priority

Listagem 4.2: Definição de Requisito de Segurança em EBNF

A Listagem 4.2 mostra a gramática de definição de um requisito na notação Ex-

tended Backus Naur Form (EBNF) [21] e a Figura 4.5 exibe o diagrama de sua sintaxe.

Figura 4.5: Diagrama de Sintaxe EBNF de um Requisito

Cláusula TRUST_IN

A cláusula TRUST_IN especifica em qual tipo de objeto na IoT o dispositivo dousuário confiará para realizar ações como troca de dados ou conexão, ação em particularpara o tipo "ponto de acesso". Em outras palavras, essa cláusula define a categoria deobjetos na IoT que deverão cumprir as exigências de segurança descritas no requisitopara trocar dados ou realizar uma conexão. A Listagem 4.3 exibe a descrição formal dacláusula TRUST_IN representado pela classe Scope na notação EBNF e a Figura 4.6 exibeo diagrama de sua sintaxe.

1 Scope ::= "TRUST_IN" ( "TRUSTED_ENTITY" | "PHYSICAL_ENTITY"

| "ACCESS_POINT" | "HOST" | "THING" | "SMARTPHONE" | "

LOGICAL_ENTITY" | "SERVICE" | "APPLICATION" )

Listagem 4.3: Especificação do escopo em notação EBNF

Figura 4.6: Diagrama de Sintaxe EBNF da Cláusula TRUST_IN


Os tipos são usados para categorizar ou classificar os objetos na IoT em grupos,os quais são: TRUSTED_ENTITY, PHYSICAL_ENTITY, HOST, THING, SMARTPHONE,

ACCESS_POINT, LOGICAL_ENTITY, SERVICE e APPLICATION. A Figura 4.7 ilustra osistema hierárquico de classificação dos tipos em que cada categoria representa um tipo.

Figura 4.7: Tipos e Subtipos de Objetos na IoT

O tipo TRUSTED_ENTITY é a categoria mais abrangente e possui duas derivações:PHYSICAL_ENTITY e LOGICAL_ENTITY. Os tipos derivados são grupos que herdam ascaracterísticas de seu tipo ancestral, com isso um tipo de objeto na IoT compartilha suascaracterísticas com os seus tipo derivados. Dessa forma, pode-se dizer, por exemplo, que otipo APPLICATION e derivado de LOGICAL_ENTITY, que é derivado de TRUSTED_ENTITY.Essa classificação hierárquica foi definida para permitir que um único requisito especi-fique exigências de segurança para mais de um tipo de objeto na IoT, por exemplo, umúnico requisito com cláusula TRUST_IN referenciando o tipo PHYSICAL_ENTITY tambémestará referenciando todos os tipos derivados como ACESS_POINT, HOST, SMARTPHONE

e THING.

Cláusula IF

A cláusula IF especifica as regras de autenticação e de confidencialidade que se-rão negociadas entre os participantes da conexão ou comunicação. Se ambos participantesda comunicação ou conexão entrarem em acordo sobre a regra de segurança definida pelacláusula IF do requisito, uma sessão de comunicação ou conexão será estabelecida.

Há um caso em especial que a regra definida na cláusula IF é tratada de formadiferente. Quando o escopo de objeto na IoT do requisito, definido na cláusula TRUST_IN,


é AcessPoint, nas regras de segurança definas na cláusula IF não existe essa negociaçãocom o ponto de acesso. Nesse caso, as regras definidas na cláusula IF são usadas paraselecionar os pontos de acesso, encontrados na varredura de redes sem fio realizadas porobjetos na IoT, que atendem as regras de segurança definidas na cláusula IF.

Apenas duas opções de regras de autenticação podem ser referenciadas pelacláusula IF: USE_AUTHENTICATION e NO_USE_AUTHENTICATION. A primeira opçãoespecifica que para autorizar a conexão ou comunicação, o objeto remoto na IoT,que interage com objeto local dono do requisito, deve estar autenticado. A opçãoNO_USE_AUTHENTICATION, que não exige autenticação para autorizar a conexão ou co-municação, é o valor padrão se nenhuma regra de autenticação seja especificada.

Das regras de confidencialidade, elas definem níveis de encriptaçãodos dados que serão trocados entre os participantes da conexão ou comunica-ção. Cada nível possui um tamanho de chave de encriptação em bits usada emum algoritmo. Os níveis, ordenados de forma ascendente por tamanho da chavede encriptação, são: USE_MIN_NO_ENCRYPTION, USE_MIN_WEAK_ENCRYPTION,

USE_MIN_MEDIUM_ENCRYPTION e USE_STRONG_ENCRYPTION.A opção USE_MIN_NO_ENCRYPTION especifica que a encriptação é opcional

entre os participantes da conexão ou comunicação. A opção USE_MIN_WEAK_ENCRYPTION

especifica que no mínimo deve-se usar encriptação fraca, ou seja, permite-se também usarencriptação média e forte. A opção USE_MIN_MEDIUM_ENCRYPTION especifica que deve-se usar encriptação média, permitindo que na negociação seja escolhido uma regra médiae alta. A opção USE_STRONG_ENCRYPTION, define que deve-se usar encriptação forte nacomunicação

A Listagem 4.4 exibe a descrição da cláusula IF na notação EBNF e a Figura 4.8ilustra a sua sintaxe.

1 Condition ::= "IF" ( "USE_AUTHENTICATION" | "

NO_USE_AUTHENTICATION" ) ( "USE_MIN_NO_ENCRYPTION" | "

USE_MIN_WEAK_ENCRYPTION" | "USE_MIN_MEDIUM\_ENCRYPTION"

| "USE_STRONG_ENCRYTPION" )?

2 | "IF" ( "USE_MIN_NO_ENCRYPTION" | "

USE_MIN_WEAK_ENCRYPTION" | "

USE_MIN_MEDIUM_ENCRYPTION" | "

USE_STRONG_ENCRYTPION" )

Listagem 4.4: Cláusula IF em anotação EBNF


Figura 4.8: Diagrama de Sintaxe EBNF da Cláusula IF

Cláusula FOR

A cláusula FOR representa uma ação que será autorizada se a condição descritana cláusula IF for satisfeita pelos objetos que participam da conexão. A Listagem 4.5exibe a descrição da cláusula FOR na notação EBNF e a Figura 4.9 mostra o diagrama desua sintaxe. As ações possíveis são SEND_AND_RECEIVE_DATA, NOTHING e CONNECT.

A ação SEND_AND_RECEIVE_DATA se refere a permissão de enviar e receberdados entre objetos na IoT. A ação NOTHING é usada para proibir interação do dispositivocom outros dispositivos, por exemplo, o requisito TRUST_IN SMARTPHONE FOR NOTHING

de um leito inteligente impede que ele se comunique com qualquer smarptphone

A ação CONNECT é uma ação especial usada apenas quando a cláusula TRUST_IN

é igual ao valor AccessPoint. Por exemplo, o usuário poderia ter como requisito "Co-

necte em um ponto de acesso apenas se ele for autenticado", com a TRML fica-ria "TRUST_IN AcessPoint FOR CONNECT IF USE_AUTHENTICATION".

Figura 4.9: Diagrama de Sintaxe EBNF da Cláusula FOR

1 Action ::= "FOR" ( "SEND_AND_RECEIVE_DATA" | "NOTHING | "

CONNECT" )

Listagem 4.5: Cláusula FOR em anotação EBNF


Cláusula MANDATORY

A cláusula MANDATORY é uma flag que marca o requisito como obrigatório,fazendo com que ele tenha prioridade sobre outros requisitos com escopo de objetosna IoT (definido pela cláusula TRUST_IN) em comum e que não especificam a cláusulaMANDATORY. Dessa forma, o requisito com a flag MANDATORY igual verdadeiro seráprocessado independentemente das regras de seleção de requisitos apresentadas na seção5.2. Por outro lado, se há mais de um requisito com escopo de objetos na IoT em comume com a cláusula MANDATORY especificada, esses requisitos serão avaliados de acordo comas regras de seleção de requisitos apresentadas na seção 4.4. Essa flag é avaliada apenasquando há no mínimo dois requisitos descrevendo regras para o mesmo escopo de objetosna IoT.

A Listagem 4.6 exibe a descrição da cláusulaMANDATORY na notação EBNF eFigura 4.10 ilustra a sua sintaxe.

1 MANDATORY ::= ’TRUE | FALSE ’?

Listagem 4.6: Cláusula MANDATORY em notação EBNF

Figura 4.10: Diagrama de Sintaxe EBNF da CláusulaMANDATORY

Para exemplificar, considere os requisitos R1 na Listagem 4.7 e o R2 na Lista-gem 4.8, modelados em um smartphone pelo usuário. Ambos definem regras de confiden-cialidade através da cláusula IF.

1 TRUST_IN PHYSICAL_ENTITY

2 FOR SEND_RECEIVE_DATA

3 IF USE_STRONG_ENCRYPTION

Listagem 4.7: Representação do R1 na linguagem de requisitos

1 TRUST_IN THING

2 FOR SEND_RECEIVE_DATA

3 IF USE_MIN_WEAK_ENCRYPTION

Listagem 4.8: Representação do R2 na linguagem de requisitos

O requisito R1 (4.7) diz que o objeto local na IoT do usuário confia em qualquerdispositivo físico conectado na Internet para trocar dados desde que o ele use encripta-ção forte na comunicação. Com isso, sempre que um dispositivo físico se conectar com

4.4 Resolução de Conflitos entre Requisitos 51

o smartphone do usuário para iniciar uma comunicação e vice-versa, o smartphone nego-ciará com o dispositivo físico remoto para usar encriptação forte durante a comunicação.A negociação é um processo para decidir o algoritmo de encriptação e a chave criptográ-fica antes da transmissão ou recepção de dados. Se a negociação for bem sucedida, istoé, se o dispositivo físico não tiver requisito que o impeça do uso desse nível de encripta-ção e tiver a capacidade de usar o nível encriptação exigida pelo smartphone, haverá umacordo e, com isso, sessões de comunicação poderão ser estabelecidas. Caso contrário, senão houver acordo com o nível de segurança exigido, o pedido de conexão do dispositivofísico será negado .

O requisito R2 (4.8) possui um escopo de abrangência de objetos mais específicoque o requisito R1 (4.7), ou seja, a cláusula TRUST_IN referencia ao tipo THING que émais específico do que referenciar PHYSICAL_ENTITY, pois um tipo derivado sempreserá mais específico. Além disso, o requisito R2, na cláusula IF, possui uma regra desegurança menos proibitiva e com menor segurança, para manter o canal de comunicaçãoconfidencial.

4.4 Resolução de Conflitos entre Requisitos

A configuração de segurança de uma comunicação pode ter uma ou duas regrasde segurança definidas no requisito que a originou, sendo uma de confidencialidadee outra de autenticação. O requisito de segurança que possui no escopo o objeto queparticipa da comunicação é selecionado para gerar a configuração de segurança dacomunicação baseada nas regras de segurança especificadas no requisito selecionado.

Dois requisitos de segurança têm escopos de objetos na IoT em comum quandoambos definem regras de segurança para o mesmo tipo de objeto na IoT. De acordo coma definição na seção 4.2, o escopo de um requisito de segurança define o tipo de objetona IoT que deve cumprir as exigências de segurança do requisito para comunicar com oobjeto dono do requisito. A Figura 4.11 exibe algumas das situações em que requisitospodem ter escopos em comum. O círculo A representa a delimitação do escopo A e ocírculo B a delimitação do escopo B.

Na Figura 4.11 a), o escopo B está contido no escopo A, logo todos os objetosno escopo B estão presentes no escopo A. Esse caso pode acontecer em dois cenários: (i)quando os escopos tem relação de herança, o tipo de objeto definido no escopo B estendeo tipo de objeto definido no escopo A. Por exemplo: se o escopo B referenciasse o tipode objeto Smartphone e escopo A referenciasse o tipo de objeto Host, o tipo do escopo B

estenderia o tipo do escopo A; (ii) o escopo B também está contido no escopo A quandoo escopo B referencia o tipo Service ou Application e o escopo A referencia o tipo deobjeto hospedeiro do tipo no escopo B, como Host, Smartphone e Thing, ambos derivados


do tipo Host. Por exemplo, se o escopo A referenciasse o tipo Smartphone e o escopo B

referenciasse o tipo Application, o tipo do escopo A hospedaria o tipo do escopo B.A Figura 4.11 b), ilustra o escopo A de objetos que contém o escopo B de objetos

e vice-versa. Logo, os escopos A e B possuem escopos iguais, por exemplo, ambosescopos referenciam o tipo de objeto Smartphone.

Na Figura 4.11 c), os escopos A e B disjuntos, ou seja, eles não tem objetosem comum. Por exemplo, se o escopo A referenciasse o tipo Smartphone e o escopo B

referenciasse o tipo AcessPoint, que não é hospedado no tipo Smartphone, pode-se dizerque os escopos A e B são distintos.

a) escopos com obje-tos em comum

b) escopos iguais c) escopos distintos

Figura 4.11: Comparação de Escopos de Objetos na IoT

Por exemplo, na Listagem 4.7 e 4.8, o requisito R1 especifica regra para HOST e orequisito R2 para SMARTPHONE e, conforme pode ser visto na Figura 4.7, SMARTPHONEé subtipo de HOST. Quando isso ocorre, os requisitos estabelecem regras que podemser conflitantes. Um requisito poderia especificar uma regra de confidencialidade comcriptografia mais forte e outro requisito poderia especificar uma regra de confidencialidadecom criptografia mais fraca, causando um conflito entre as regras.

Quando dois ou mais requisitos se aplicam à comunicação de um mesmo objetona IoT, três critérios definem quais os requisitos serão selecionados para gerar a configu-ração de segurança baseado em regras: obrigatoriedade, especificidade, e proibitividade,avaliados nesta ordem. Primeiro, avalia-se os requisitos com o critério de obrigatoriedade,se não resolver o conflito, os requisitos serão avaliados pelo critério de especificidade. Semesmo assim ainda existir conflitos entre os requisitos, os requisitos serão avaliados como critério de obrigatoriedade, especificidade, e proibitividade para selecionar o requisitoque será usado para criação da segurança.

O critério obrigatoriedade é usado para selecionar, em um conjunto de requisi-tos, os requisitos marcados como obrigatórios. Com isso, em um conjunto de requisitos, sehá um requisito com regras de confidencialidade e autenticação marcado como obrigatórioele será selecionado para gerar uma configuração de segurança com regra de autenticaçãoe confidencialidade. Por outro lado, se for selecionado um requisito obrigatório, que pos-sui apenas uma regra de autenticação ou confidencialidade, para evitar que a configuração


de segurança tenha apenas uma regra de segurança, outro requisito com a regra de segu-rança que falta para compor a configuração de segurança. Se um requisito for encontrado,a sua regra especificada será usada na geração da configuração de segurança. Se for encon-trado mais de um requisito, eles serão avaliados conforme os critérios obrigatoriedade,

especificidade, proibitividade para seleção do requisito para geração da configuração desegurança.

Se houver mais de um requisito obrigatório com o escopo em comum e comopção de segurança especificadas na mesma categoria, autenticação ou confidencialidade,esses requisitos estarão em conflito e, para resolvê-lo, será usado o próximo critério, ode especificidade.

A especificidade é usado para selecionar o requisito que possui o escopo de ob-jeto na IoT mais específico, definido na cláusula TRUST_IN do requisito. A Figura 4.7exibe a hierarquia de tipos e subtipo que classificam os objetos na IoT. Um requisito é con-siderado com escopo mais específico do que outro quando o tipo de objeto na IoT definidana TRUST_IN de um requisito é subtipo do tipo de objeto definida na cláusula TRUST_IN

de outro requisito. Em um conjunto de requisitos, se não houver requisito obrigatório, orequisito com escopo de objeto mais específico será selecionado para a geração da confi-guração de segurança.

O critério proibitividade é usado para selecionar a opção autenticação maisproibitivas e a opção de confidencialidade mais proibitiva entre os requisitos. Das op-ções de autenticação, a opção mais proibitiva é USE_AUTHENTICATION e das opçõesde confidencialidade mais proibitiva é USE_STRONG_ENCRYPTION seguida pelas op-ções ordenadas de forma decrescente em proibitividade USE_MIN_MEDIUM_ENCRYPTION,USE_MIN_WEAK_ENCRYPTION e USE_MIN_NO_ENCRYPTION.

A paridade é avaliada apenas em requisitos com regras de confidencialidade.Esse critério verifica quais são as regras de confidencialidade em comum entre osrequisitos conflitantes para serem selecionadas. Em outras palavras é realizada uma umainterseção entre as regras de confidencialidade dos requisitos conflitantes.

A Listagem 4.9 exibe quatro requisitos conflitantes com escopo em comum,sendo o REQ1 um requisito obrigatório que especifica apenas regra de confidencialidade,REQ2 um requisito que define apenas regra de confidencialidade, REQ3 um requisito quedefine regra de confidencialidade e autenticação, REQ4 um requisito que define apenasregra de autenticação.

Por exemplo, a avaliação dos quatro requisitos a partir do critério de obrigato-

riedade, o requisito selecionado será o REQ1. Com isso a regra se segurança eleita seráUSE_MIN_WEAK_ENCRYPTION. Como o requisito REQ1 não possui regra de autenticação,será buscado outro requisito para tentar eleger a regra de autenticação. Com a busca, foramencontrados dois requisitos com regra de autenticação, o REQ3 e REQ4. Seguindo ordem

4.5 Conclusão 54

de precedência dos critérios, os requisitos REQ3 e REQ4 serão avaliados pelo critério deespecificidade. Entre os dois requisitos, o que possui o escopo mais específico é o requi-sito REQ3, logo será selecionado a regra de autenticação NO_USE_AUTHENTICATION

do requisito REQ3. As regras selecionadas, USE_MIN_WEAK_ENCRYPTION do requi-sito REQ1 e NO_USE_AUTHENTICATION do requisito REQ3, serão usadas para gerara configuração de segurança.

1 REQ1: TRUST_IN HOST FOR SEND_AND_RECEIVE_DATA IF

USE_MIN_WEAK_ENCRYPTION MANDATORY

2

3 REQ2: TRUST_IN SMARTPHONE FOR SEND_AND_RECEIVE_DATA IF

USE_MIN_MEDIUM_ENCRYPTION

4

5 REQ3: TRUST_IN PHYSICAL_ENTITY FOR SEND_AND_RECEIVE_DATA IF

USE_STRONG_ENCRYPTION AND NO_USE_AUTHENTICATION

6

7 REQ4: TRUST_IN TRUSTED_ENTITY FOR SEND_AND_RECEIVE_DATA IF

USE_AUTHENTICATION

Listagem 4.9: Exemplos de requisitos conflitantes

4.5 Conclusão

Neste capítulo, foi discutida a abordagem de requisitos de segurança em tempode execução usando modelos em tempo de execução. Foi apresentado o metamodelo e alinguagem Trust Requirement Modeling Language (TRML) para especificar requisitos desegurança em modelos em tempo de execução. Por fim, foi apresentado a abordagem ado-tada para resolução de conflitos entre requisitos de segurança especificadas pela TRML.

CAPÍTULO 5Arquitetura para Síntese de Requisitos deSegurança em Tempo de Execução

Este capítulo apresenta uma proposta de arquitetura de middleware, que permiteo usuário alterar requisitos de segurança em entidades na IoT em tempo de execução paraque a sua comunicação seja reconfigurada dinamicamente. Nesta arquitetura, os requisitosde segurança são representados por meio de modelos em tempo de execução descritosem uma linguagem específica de domínio, denominada Trust Requirement Modeling

Language (TRML), introduzida na seção 4.3.Na seção 5.1, foi apresentado detalhadamente a arquitetura do middleware

baseado em camadas. A seção 5.2 discute detalhes do algoritmo de síntese e a estrutura dedados utilizadas por esse algoritmo no processo de síntese de requisitos modificados emtempo de execução para gerar comandos de reconfiguração da segurança na comunicação.A seção 5.3 apresenta a implementação dos tratadores de sinais emitidos entre as camadasdo middleware e a implementação das camadas Synthesis Engine (SE) e Control and

Configuration (CC).Na implementação da camada Synthesis Engine (SE), foi desenvolvido o algo-

ritmo de síntese de requisitos de segurança, que é executado sempre que há alteraçõesnos requisitos de segurança (adição ou remoção) e sempre que surgem novas sessõesde comunicação. Como resultado da execução do algoritmo de síntese de requisitos, sãogerados comandos enviados para a camada Control and Configuration (CC) para negoci-ação da nova configuração de segurança. Por fim, na implementação da camada Control

and Configuration (CC) foi utilizado o protocolo TLS/SSL como único protocolo.

5.1 Arquitetura do Middleware

Para gerenciar os requisitos de segurança em tempo de execução, foi projetada aarquitetura de middleware, ilustrada na Figura 5.1, inspirada na arquitetura da CVM [15].Segundo Coulouris et. al. [13], middleware, ou mediador, é uma camada de software que

5.1 Arquitetura do Middleware 56

faz a mediação entre software e demais aplicações. O objetivo típico de um middleware émascarar a heterogeneidade e abstrair complexidades.

A arquitetura de middleware proposta está organizada em quatro camadas User

Interface (UI), Synthesis Engine (SE), Control and Configuration (CC) e Thing Broker

(TB). Este trabalho concentra-se nos problemas da camada Synthesis Engine (SE), asdemais camadas foram prototipadas.

A abordagem de dividir a arquitetura em quatro camadas pode proporcionaruma separação coesa e desacoplada, dividindo as tarefas da reconfiguração da segurançaem quatro níveis de abstração, que correspondem os quatro componentes chaves daarquitetura mencionados acima: a camada UI apresenta uma abstração da configuraçãoda segurança de forma gráfica voltado para o usuário final; a camada SE apresenta umaabstração da configuração de segurança em forma de modelos em tempo de execução; acamada CC trata da configuração da segurança em um nível de protocolos de segurançae de transporte; e por fim, a camada TB apresenta a configuração de segurança em umnível de segurança de wrappers de sockets. As quatro camadas serão discutidas com maisdetalhes nas seções 5.1.1, 5.1.2, 5.1.3 e 5.1.4.

Com isso, essa abordagem separa e encapsula as principais preocupações da mo-delagem de requisitos de segurança, síntese dos requisitos, reconfiguração da segurançae a entrega efetiva da comunicação pela rede subjacente aos dispositivos. Além disso, oprincípio arquitetônico de separação de preocupações empregado no middleware, permiteque cada camada seja implementada e evoluída independentemente das outras camadas.Esta arquitetura, com baixo acoplamento entre as camadas, propiciou o desenvolvimentoe avaliação isolada da camada Synthesis Engine (SE), discutida na seção 5.3.

Nesta arquitetura, usuários podem utilizar o middleware para modelar requisi-tos de segurança através da camada User Interface (UI). Os requisitos modelados na ca-mada User Interface (UI) são enviados para a camada Synthesis Engine (SE). Em seguida,a camada Synthesis Engine (SE) sintetiza os modelos de requisitos de segurança em co-mandos de segurança que são enviados juntamente com o modelo da sessão de comunica-ção para a camada Control and Configuration (CC). A camada Control and Configuration

(CC) executa os comandos de segurança gerados pela camada Synthesis Engine (SE) paraalterar a configuração de segurança da comunicação referenciada pela sessão.

A camada Thing Broker (TB) encapsula sockets em wrappers que oferecema mesma interface de sockets tradicionais, escondendo a complexidade e reconfigura-ção subjacente ao funcionamento da arquitetura do middleware. As aplicações podemusar sockets tradicionais através da API Java ou usar os wrapper sockets através da API dacamada Thing Broker (TB). A grande diferença é que nos sockets tradicionais, a aplicaçãoserá responsável por gerenciar a sua segurança e nos wrapper sockets o gerenciamento dasegurança é realizada pelo middleware de acordo com requisitos de segurança modelados.


Figura 5.1: Camadas do Middleware

A camada Synthesis Engine (SE) mantém um modelo em tempo de execuçãoque representa requisitos de segurança, objetos no ambiente de IoT com suas respectivascaracterísticas de segurança e sessões de comunicação entre os objetos. Esse modeloem tempo de execução é atualizado de acordo com eventos provenientes das camadassubjacentes ou por meio de chamadas provenientes das camadas sobrejacentes pararepresentar o que está ocorrendo no ambiente. O modelo em tempo de execução mantidopela camada SE pode ser modificado pelo usuário através da camada UI que emitiráchamadas para camada SE modificar o modelo.

Um evento é qualquer interação que surge de um nível inferior para um nívelsuperior e chamadas são interações de um nível superior para um nível inferior. Estetrabalho utiliza o termo sinal para designar de forma generalizada um evento ou chamada.Assim, um sinal pode representar tanto uma solicitação recebida da camada superiorquanto um evento gerado por um recurso gerenciado

Conforme ilustrado na Figura 5.1, tanto um evento quanto uma chamada podemocorrer entre as camadas do middleware. Com isso, cada camada do middleware podecomunicar com a camada inferior e superior por meio de eventos e chamadas.

Quando uma camada dispara um evento, ele é capturado pela camada imediata-mente superior, e caso ela possua um manipulador relacionado ao evento capturado, esteevento será tratado. Por outro lado, caso não existam mecanismos para o tratamento do


evento, ele então é repassado para a camada imediatamente superior à camada que o cap-turou, na expectativa de que a camada superior possua mecanismos para o seu tratamento.

De forma análoga, uma camada pode disparar chamadas, que são capturadas pelacamada imediatamente inferior, e caso ela possua um manipulador relacionado ao eventocapturado, este evento será tratado. No entanto, caso não existam mecanismos para otratamento da chamada na camada que a capturou, essa chamada será encaminhada paraa camada inferior, na espera de que ela possua mecanismos para o seu tratamento.

Na camada Synthesis Engine (SE), como resultado do tratamento de um eventooriundo da camada inferior ou uma chamada realizada pela camada superior, o modeloem tempo de execução poderá ser alterado. A seção 5.3.1 discute mais detalhadamente otratamento de sinais.

Um evento pode ser repassado camada a camada em busca de mecanismospara o seu tratamento. Se o evento chegar à camada mais superior e ainda assim nãoexistir um mecanismo para o seu tratamento, o usuário é então notificado e torna-se sua responsabilidade resolvê-lo ou ignorá-lo. Por exemplo, quando houver falha nanegociação da segurança entre objetos, a camada Control and Configuration (CC) podeemitir o evento NofityFailHandshakeEvent para a camada SE tratar. No entanto, se acamada SE não tiver um manipulador apropriado, o evento NofityFailHandshakeEvent

será reemitido para a camada User Interface (UI) que, por último se não tiver umamanipulador para tratar o evento, o usuário será notificado sobre o evento.

5.1.1 User Interface (UI)

A camada User Interface (UI) permite ao usuário especificar declarativamenteseus requisitos de segurança no domínio da comunicação na IoT e mudá-los, em tempode execução, usando as interfaces apropriadas. Além disso, essa camada permite aousuário inspecionar o estado da segurança do ambiente de IoT. Após a especificaçãoou modificação de requisitos, a camada User Interface (UI) realiza chamadas paracamada Synthesis Engine (SE) para representar o requisito em modelos em tempo deexecução.

5.1.2 Synthesis Engine (SE)

A camada Synthesis Engine (SE) é responsável por manter, sintetizar e processarrequisitos de segurança em tempo de execução, gerando comandos para a camada seguinteque representam o interesse de segurança especificado pelos requisitos. A camada Synthe-

sis Engine (SE), ao receber chamadas da camada User Interface (UI), cria instâncias dometamodelo alterando os modelos em tempo de execução que representam os requisitosespecificados pela camada User Interface (UI). Quando a camada Synthesis Engine (SE)


detecta alterações no modelo em tempo de execução, ela sintetiza as configurações desegurança para serem aplicadas durante a reconfiguração dos canais de comunicação pelacamada Control and Configuration (5.1.3).

As configurações de segurança são sintetizadas sempre que há disponibilidadede pontos de acesso ou quando a camada Synthesis Engine (SE) (i) detecta alterações nosmodelos em tempo de execução que representam os requisitos de segurança e (ii) quandoé sinalizada sobre pedidos de conexão por objetos. Neste último caso (ii), são criadosmodelos em tempo de execução que representam as novas sessões de comunicação,estabelecida com o aceite da conexão. O modelo em tempo de execução representa sessõesde comunicação, configurações de segurança das sessões de comunicação e informaçõesdos envolvidos na conexão, como a identificação e tipo de objeto inteligente. A síntese derequisitos é realizada pelo algoritmo descrito na seção 5.2.2.

A camada Synthesis Engine (SE) tem como uma de suas responsabilidadesmanter o modelo em tempo de execução atualizado e consistente com os requisitos desegurança e o ambiente de IoT. A atualização do modelo em tempo de execução ocorrequando a camada SE recebe chamadas oriundas da camada superior e eventos originadosna camada inferior. As chamadas da User Interface (UI), são disparados para notificaralterações nos requisitos e, a partir disso, a camada Synthesis Engine (SE) atualiza omodelo em tempo de execução. Os eventos da camada Control and Configuration (CC)

são criados para notificar a camada Synthesis Engine (SE) de mudanças em sessões decomunicação e alterações no ambiente de IoT, como surgimento ou saída de um novoobjeto inteligente e ponto de acesso do ambiente de IoT. Com isso, a camada Synthesis

Engine (SE), ao receber eventos de alterações da camada Control and Configuration (CC),atualiza o modelo tempo de execução para deixá-lo consistente com o estado do ambientede IoT e manter a relação causal entre modelo e sistema no objeto inteligente.

5.1.3 Control and Configuration (CC)

A camada Control and Configuration (CC) implementa protocolos de segurança(e.g. transporte seguro e autenticação) responsáveis por negociar configurações de segu-rança entre os objetos. Essa negociação é realizada para estabelecer uma conexão segurae garantir que a comunicação de um processo local com um remoto independentementeda forma como foram construídos.

Neste trabalho, a camada CC foi implementada apenas com o proto-colo TLS [16], o qual, durante o handshaking, negocia cifras criptográficas duranteuma conexão entre dois processos. As cifras criptográficas definem opções que dizemrespeito aos algoritmos de criptografia, autenticação dos participantes da comunicação efunções hash a serem utilizados durante toda a comunicação segura.


A partir do handshaking, as duas instâncias do protocolo decidem quais algorit-mos e chaves criptográficas deverão utilizar durante a comunicação entre dois processos.Além das chaves criptográficas, pode ser usada uma chave simétrica ou uma chave assi-métrica no processo de autenticação dos participantes. Uma vez que as ambas instânciasdo protocolo TLS concordem quanto à autenticidade um do outro e também quanto aosparâmetros de segurança (chave e algoritmo), a transmissão segura pode então começar.

Como a camada Synthesis Engine (SE) foi implementada usando o proto-colo TLS, ao sintetizar um requisito de segurança, ela envia comandos para a camada Con-

trol and Configuration (CC) que resultarão em uma lista de cifras criptográficas.Por exemplo, com a síntese do requisito TRUST_IN THING FOR

SEND_AND_RECEIVE_DATA IF USE_MIN_WEAK_ENCRYPTION, a camada SE envia para acamada CC um comando indicando o uso de no mínimo criptografia baixa na comunica-ção. Dado que a camada CC usa o protocolo TLS para negociar a segurança, o comandorecebido pela camada SE resultaria em três cifras criptográficas, sendo que a primeiracifra se refere à criptografia baixa (menor chave), a segunda à criptografia média (chaveintermediária) e a terceira à criptografia alta (maior chave). Essas cifras criptográficas,são negociadas no handshaking do protocolo TLS, o qual dará preferência para a cifracriptográfica mais forte (a mais difícil de decifrar).

Por outro lado, se houver algum erro durante o handshaking, a camada Control

and Configuration (CC) pode tratar o erro ou pode emitir um evento para a camada Synthe-

sis Engine (SE), que emitirá um evento para a camada User Interface (UI) notificar aousuário que houve uma falha.

Na solução proposta por esse trabalho, o tamanho da chave de encriptação as-sociada a cada opção (USE_MIN_WEAK_ENCRYPTION, USE_MIN_MEDIUM_ENCRYPTION,

USE_STRONG_ENCRYPTION) é parametrizável. Com isso, dois objetos na IoT podemter suas opções de encriptação parametrizados com tamanho mínimo de chaves di-ferentes. Por exemplo, considere dois objetos na IoT, o A e o B, sendo que a op-ção USE_MIN_WEAK_ENCRYPTION de A está parametrizada com tamanho de chave mínimoigual a 128 bits e B com chave mínima de 256 bits. Dessa forma, como o objeto A aceitachaves acima de 128, durante a negociação das regras entre A e B pode ser acordado o usode uma chave de 256 bits. Nesse acordo, as regras das duas partes serão atendidas mesmocom as opções de encriptação estando parametrizadas com tamanho de chaves diferentesem cada objeto.

5.1.4 Thing Broker (TB)

A camada Thing Broker (TB) pode gerenciar sockets e a comunicação com a ca-mada de transporte. Os sockets são encapsulados em wrappers de sockets cliente e wrap-

5.2 Síntese de Requisitos de Segurança 61

per de sockets servidores, que escondem das aplicações e serviços a complexidade dereconfiguração da segurança mediante alterações em requisitos. Quando um canal de co-municação (wrapper socket ) disponibilizado é usado para estabelecer uma sessão de co-municação, um evento é emitido para a camada Control and Configuration (CC) que, pornão possuir um manipulador para este evento, emitirá um evento para a camada Synthesis

Engine (SE) sinalizando o estabelecimento de uma sessão de comunicação para atuali-zar o modelo em tempo de execução e executar o algoritmo de síntese de requisitos paraconfigurar a segurança da sessão.

Além disso, a camada Thing Broker (TB) tem a função de descobrir elementosdo ambiente de IoT, como aplicações, serviços e objetos como smartphones, pontosde acesso e coisas. Na medida que novos objetos são descobertos, eventos podem seremitidos para as camadas superiores, notificando a descoberta dos objetos para que omodelo em tempo de execução seja atualizado na camada Synthesis Engine (SE).

5.2 Síntese de Requisitos de Segurança

A síntese de requisitos transforma requisitos modelados com a TRML em coman-dos que servem como diretivas para a camada CC gerenciar a segurança na comunicação.Esse processo é realizado pelo algoritmo de síntese de requisitos que é executado sempreque requisitos de segurança são modificados ou quando é criada uma sessão de comuni-cação. A seção 5.2.2 apresenta o algoritmo de síntese de requisitos.

A camada Synthesis Engine mantém os modelos em tempo de execução querepresentam sessões e requisitos em uma estrutura de dados em árvore. A seção 5.2.1apresenta os detalhes dessa estrutura de dados. Esta estrutura de dados em árvore arma-zena sessões de comunicação e requisitos de segurança em forma de modelos em tempode execução para,que durante a execução do algoritmo de síntese de requisitos, a árvoreseja percorrida em busca de sessões que precisam ter a segurança configurada. Durante abusca de sessões, requisitos de segurança são selecionados de acordo com as regras de-finidas na seção 4.4, para serem sintetizados em comandos com diretivas de segurançapara serem aplicadas, pela camada Control and Configuration, em sessões de comunica-ção (sockets). Essa abordagem, de usar uma estrutura de dados em árvore para mantero modelo em tempo de execução foi usada para implementar o algoritmo de síntese derequisitos, apresentado em detalhes na seção 5.2.2.

5.2.1 Árvore de Requisitos e Sessões

O algoritmo de síntese da camada Synthesis Engine (SE) utiliza uma estruturade dados em árvore binária para armazenar e pesquisar requisitos de segurança e sessões


de comunicação em forma de modelos em tempo de execução. A Figura 5.2 ilustra umdiagrama de classe da estrutura de dados em árvore.

A árvore de sessões e requisitos é representada pela classe Tree. A camada SE

possui uma instância dessa estrutura de dados em árvore composta por um nó raiz (Trus-

tedEntity) e de oito nós filhos (Logical, Physical, Application, Service, AccessPoint, Host,

Smartphone e Thing), ambos representados pela classe Node. O Node possui como atri-butos identifier, parent, children, adoptedChildren e requirement. O atri-buto identifier, do tipo Class<Entity> que referencia um categoria de objeto, é usadopara identificar o nó. O parent referencia o nó pai e se ele é nulo, então o nó desse atri-buto é dito nó raiz da árvore. O atributo children, do tipo Set<Node>, referencia osnós filhos e se ele é nulo, logo o nó é folha. O adoptedChildren é um atributo quepode referenciar os nós do tipo LogicalEntity, Service e Application. A implementaçãodo atributo adoptedChildren é a forma utilizada para permitir que os nós LogicalEntity,

Service e Application herdem os requisitos adicionados nos nós Smarpthone e Host.

Figura 5.2: Diagrama de Classes da Árvore de Requisitos e Ses-sões

Os nós da árvore, embora estejam dispostos de forma hierárquica, não estão or-denados. Cada elemento, ou nó, possui um identificador que é usado para posicionar umasessão de comunicação ou um requisito de segurança de forma hierárquica na árvore. Oidentificador é um dos tipos de objetos ilustrados na Figura 4.7, como TRUSTED_ENTITY,

PHYSICAL_ENTITY e LOGICAL_ENTITY. O nó raiz possui o identificador TRUSTE_ENTITY


e tem os nós PHYSICAL_ENTITY e LOGICAL_ENTITY como nós filhos. Os nós com identi-ficador SMARTPHONE, ACCESS_POINT, THING, SERVICE e APPLICATION são nós folha.

Para adicionar um requisito de segurança na árvore, é realizada uma busca emprofundidade para encontrar o nó em que ele será adicionado. A cada nó é verificado se oidentificador do nó é igual ao escopo de entidade do requisito. Por exemplo, a Figura 5.3exibe de forma gráfica a árvore com dois requisitos de segurança adicionados, REQ1

e REQ2, e duas sessões de comunicação adicionadas, sessão A e sessão B. Par inserir orequisito REQ1 com escopo de entidade igual a Thing, foi necessário realizar uma buscapara encontrar o nó com o identificador igual a Thing.

Para adicionar uma sessão de comunicação na árvore, também é realizada umabusca em profundidade na árvore para encontrar o nó em que ela será adicionada.

A Figura 5.3 ilustra uma representação da árvore de requisitos e sessões nacamada Synthesis Engine do middleware de um smartphone. O nó raiz é identificadopor TrustedEntity e os nós folhas são identificados por Application, Service,

Smartphone, Thing e AcessPoint.Uma sessão de comunicação á adicionada no nó que possui o identificador

igual ao escopo de entidade remota da sessão. Por exemplo, na Figura 5.3 a sessãode comunicação A possui escopo de entidade remota igual à Thing. Para Adicioná-la àárvore será buscado o nó que tiver identificador igual à Thing. Desse modo, as sessões decomunicação estão dispostos de forma hierárquica nos nós.

Dado que os requisitos de segurança REQ2 e REQ1 na Figura 5.3 possuem comoescopo de entidade o tipo Smartphone e o tipo Host, eles estão associados aos nós comidentificador Smartphone e com identificador Host respectivamente.

Todo nó que não possui requisitos de segurança associado herdará os requisitosdo nó pai. Por exemplo, o nó Thing da árvore ilustrada na Figura 5.3, não possui requisitoassociado e herda os requisitos do nó pai Host. Se o requisito REQ1 estivesse associado aonó Physical, o nó Host herdaria o requisito REQ1, consequentemente, o nó Thing herdariao requisito REQ1 do seu nó pai.


Figura 5.3: Representação da Árvore de Requisitos de Segurança eSessões de Comunicação do Smartphone de um Usuá-rio

A herança de requisito estende aos nós Application e Service quando requi-sitos são adicionados nos nós Host, Smartphone e Thing. Por exemplo, a Figura 5.3exibe a sessão A especifica características da comunicação entre a entidade local dotipo Smartphone com endereço IP 192.168.0.1:9091 e a entidade remota do tipo Thing

com endereço IP:PORTA 192.168.0.8:8380, teve a segurança configurada de acordo como requisito de segurança REQ1 herdado de nó Host. A sessão B, que especifica ca-racterísticas da comunicação entre a entidade local do tipo SMARTPHONE com en-dereço IP:PORTA 192.168.0.1:9092 e a entidade remota do tipo SMARTPHONE comendereço IP:PORTA 192.168.0.7:8390 também é configurada por um requisito herdadodo Host, que neste caso é o requisito REQ2.

5.2.2 Algoritmo de Síntese de Requisito

O algoritmo de síntese de requisitos tem como objetivo transformar modelosem tempo de execução que representam requisitos de segurança em comandos parareconfiguração de sessões de comunicação que estão dentro do escopo do requisitode segurança. Este algoritmo realiza um percurso em pré-ordem também chamado detravessia da árvore, para encontrar sessões de comunicação que precisam ter a segurançaconfigurada a partir de síntese de requisitos de segurança. Durante a busca dos requisitosque serão usados na síntese, é dada preferência na seleção dos requisitos associados aomesmo nó da árvore em que está associada a sessão que terá a segurança configurada. Osrequisitos utilizados na síntese são chamados de requisitos selecionados.


O Algoritmo 1 (sintetizaRequisitos) realiza síntese de requisitos que estãoinseridos na árvore. Ele tem como entrada o nó que iniciará a busca e um conjunto derequisitos de seu nó pai, sendo que a camada Synthesis Engine (SE) sempre inicia aexecução do algoritmo no nó raiz da árvore e com o conjunto de requisitos vazio.

Sempre que é estabelecida uma nova sessão de comunicação ou há alteraçõesnos requisitos, o algoritmo sintetizaRequisitos realiza uma busca por profundi-dade recursivamente para encontrar sessões de comunicação que precisam ter a segu-rança reconfigurada. Durante a busca, o algoritmo sintetizaRequisitos seleciona osrequisitos pertinentes que serão sintetizados em configuração de segurança pela fun-ção geraReconfiguracaoSeguranca.

A tabela 5.1 lista e descreve todos os elementos e atributos de elementosutilizados no algoritmo sintetizaRequisitos.


Elemento Descrição AtributosnoCorrente nó da árvore com sessões e

requisitos, passado como en-trada para o algoritmo

reqs, sessoes, filhos

filhos conjunto de nós filhos da ár-vore de sessões e requisitos

—

reqs conjunto de requisitos de se-gurança

—

sessoes conjunto de sessões de comu-nicação

—

reqsNoPai conjunto de requisitosde segurança do nó paido noCorrente

—

reqsSelecionados conjunto de requisitos seleci-onados para serem sintetiza-dos em configuração de se-gurança (comandos de segu-rança)

—

configSeg, novaConfigSeg configuração de segurançagerada a partir da síntese derequisitos selecionados

escopo

escopo escopo de entidades que de-vem atender as exigências daconfiguração de segurança

—

sessao sessão de comunicação entreentidades

configSeg

camadaControleConfiguracao referência para a camadaControl and Configuration

(CC)

—

filho nó filho de outro nó que re-ferencia conjuntos de sessões,conjuntos de requisitos e con-junto de filhos se não for nófolha

—

Tabela 5.1: Elementos e Atributos Usados no Algo-ritmo sintetizaRequisitos

No algoritmo sintetizaRequisitos, na linha 9 (nove), o operador / é utilizado


para verificar se escopo de entidades do requisito de segurança é mais especifico do que oescopo de outro requisito. Um requisito ser mais específico que outro significa que o es-copo de entidades (TrustedEntity, PhysicalEntity, LogicalEntity, Service,

Application, Host, AccessPoint, Smartphone, Thing) do requisito mais especí-fico é um subtipo (tipo filho) do tipo definido no escopo outro requisito. Por exemplo, acomparação dos escopos Smart phone /Host é verdadeira. Na linha 10 (dez) do algo-ritmo sintetizaRequisitos é enviado um comando para a camada Control and Con-

figuration (CC) contendo uma sessão e a configuração de segurança retornada pela fun-ção geraReconfiguracaoSeguranca.

Algoritmo 1 sintetizaRequisitosInput: noCorrente, reqsNoPai = {r′1,r′2, . . . ,r′k}

1 if noCorrente.reqs 6= /0 then2 reqsSelecionados← noCorrente.reqs

3 else4 reqsSelecionados← reqsNoPai

5 if reqsSelecionados 6= /0 and noCorrente.sessoes 6= /0 then6 novaCon f igSeg← geraCon f iguracaoSeguranca(reqsSelecionados)

7 foreach sessao in noCorrente.sessoes do8 if novaCon f igSeg 6= sessao.con f igSeg then9 if novaCon f igSeg.escopo/ sessao.con f igSeg.escopo then

10 camadaControleCon f iguracao.recon f igSessao(sessao,novaCon f igSeg)

11 else12 foreach f ilho in noCorrente. f ilhos do13 sintetizaRequisitos( f ilho,reqsSelecionados)

A Tabela 5.2 lista e descreve todos os elementos e atributos de elementosutilizados na função geraConfiguracaoSeguranca.


Variável DescriçãoreqsSelecionados parâmetro de entrada que representa um conjunto de requi-

sitos selecionados pelo algoritmo de síntese para serem sin-tetizados em um configuração de segurança

opcaoAut parâmetro de retorno que representa a opção de autentica-ção selecionada pelo algoritmo

opcaoConf parâmetro de retorno que representa a opção de confidenci-alidade selecionada pelo algoritmo

opcaoAutObrig opção de autenticação obrigatória que será atribuído se exis-tir regra de autenticação especificada em um dos requisitosmarcado como obrigatória do conjunto reqsSelecionados

opcoesConfObrig opção de confidencialidade obrigatória que será atribuído seexistir regra de confidencialidade especificada em um dosrequisitos marcado como obrigatório do conjunto reqsSele-cionados

opcaoAutNaoObrig opção de autenticação que será atribuído se existir regra deautenticação especificada em um dos requisitos do conjuntoreqsSelecionados

opcoesConfNaoObrig opção de confidencialidade que será atribuído se existir re-gra de confidencialidade especificada em um dos requisitosdo conjunto reqsSelecionados

req requisito de segurança do conjunto de requisitos de segu-rança selecionados reqsSelecionados, tendo como atributoopcoesConf e opcaoAut

opcaoAut opção de autenticação extraída do requisito de segurança

opcoesConf opção de confidencialidade extraída de um requisito de umrequisito de segurança

Tabela 5.2: Elementos e Atributos Usados no algoritmo para Ge-rar a Configuração de Segurança

A função geraReconfiguracaoSeguranca tem como entrada um con-junto de requisitos e como saída uma configuração de segurança composta poruma opção de autenticação e uma opção de confidencialidade. A opção de auten-ticação diz respeito à uma das regras de autenticação USE_AUT HENT ICAT ION

e NO_USE_AUT HENT ICAT ION, e a opção de confidencialidade diz res-peito à uma das regras de confidencialidade USE_MIN_NO_ENCRY PT ION,USE_MIN_WEAK_ENCRY PT ION, USE_MIN_MEDIUM_ENCRY PT ION eUSE_ST RONG_ENCRY PT ION.


Nas linhas 21 e 28 da função geraReconfiguracaoSeguranca, o operador�é usado para verificar se uma regra de autenticação é mais proibitiva do que outra. Porexemplo, a expressão USE_AUT HENT ICAT ION�NO_USE_AUT HENT ICAT ION é

verdadeira. Esse operador é usado apenas para comparar regras de autenticação, sendoque a regra USE_AUT HENT ICAT ION sempre será mais proibitiva do que a regraNO_USE_AUT HENT ICAT ION.


Algoritmo 2 geraConfiguracaoSegurancaInput: reqsSelecionados = {r′1,r′2, . . . ,r′k}Output: opcaoAut,opcaoCon f

14

15 var opcaoAutObrig

16 var opcoesCon f Obrig

17 var opcaoAutNaoObrig

18 var opcoesCon f NaoObrig

19 foreach req in reqsSelecionados do20 if req é obrigatorio then21 if req.opcaoAut� opcaoAutObrig then22 opcaoAutObrig← req.opcaoAut

23 if opcoesCon f Obrig = /0 then24 opcoesCon f Obrig← req.opcoesCon f

25 else26 opcoesCon f Obrig← (opcoesCon f Obrig∩ req.opcoesCon f )

27 else28 if req.opcaoAut� opcaoAutNaoObrig then29 opcaoAutNaoObrig← req.opcoesAut

30 if opcoesCon f NaoObrig = /0 then31 opcoesCon f NaoObrig← req.opcoesCon f

32 else33 opcoesCon f NaoObrig← (opcoesCon f NaoObrig∩ req.opcoesCon f )

34 if opcaoAutObrig 6= /0 then35 if opcoesCon f Obrig 6= /0 then36 return opcaoAutObrig,opcoesCon f Obrig

37 else38 return opcaoAutObrig,opcoesCon f NaoObrig

39 else if opcoesCon f Obrig 6= /0 then40 if opcaoAutObrig 6= /0 then41 return opcaoAutObrig,opcoesCon f Obrig

42 else43 return opcaoAutNaoObrig,opcoesCon f Obrig

44 else45 return opcaoAutNaoObrig,opcoesCon f NaoObrig

Quando um processo em execução em uma entidade local na IoT se conectaem um processo remoto, executando em outra entidade na IoT, a camada Thing Broker


da entidade local cria uma sessão de comunicação que referencia o wrapper socket doprocesso que realizou a conexão. A camada Thing Broker da entidade remota tambémcria uma sessão, referenciando o wrapper socket que aceitou o pedido de conexão.

Em seguida, a camada Thing Broker notifica a camada Control and Configuration

sobre a sessão de comunicação estabelecida. Diante dessa notificação, a camada Control

and Configuration notifica a camada Synthesis Engine sobre a nova sessão de comunica-ção. Quando a camada Synthesis Engine é notificada do surgimento de uma nova sessãode comunicação, ela instancia um modelo em tempo de execução para representar a novasessão e o adiciona na estrutura de dados em árvore 5.2.1, bem como executa o algoritmode síntese de requisitos, em cuja execução comandos de configuração da segurança sãocriados e enviados juntamente com a identificação da nova sessão de comunicação para acamada Control and Configuration.

A camada Control and Configuration (CC), ao receber os comandos de configu-ração da segurança originados da camada Synthesis Engine (SE) a camada CC configura asegurança da sessão de comunicação através da negociação de segurança com a entidadeque solicitou a conexão. O sucesso da negociação está indiretamente relacionado comos requisitos de segurança que cada entidade da comunicação possui, porque através dasíntese dos requisitos, são geradas configurações de segurança que definirão quais os al-goritmos criptográficos e de autenticação que cada entidade exige durante a comunicação.Dessa forma, se uma entidade remota e uma entidade local não possuírem requisitos desegurança com regras de segurança comuns, a síntese não gerará algoritmos criptográficose de autenticação que satisfaçam as duas partes da comunicação.

Quando a negociação não é bem sucedida, o usuário será notificado da falha denegociação e será envolvido no loop de reconfiguração, quanto então ele pode aceitara falha na negociação e o encerramento da sessão de comunicação ou alterar seusrequisitos para que uma nova tentativa de negociação seja realizada. Com o sucessoda negociação entre processos de duas entidades na IoT, os modelos de requisitos dasduas entidades serão combinados para gerar um novo modelo em tempo de execução querepresentará a sessão de comunicação. O modelo em tempo de execução identifica osprocessos em comunicação e a configuração de segurança da comunicação gerada a partirdos algoritmos criptográficos e de autenticação negociados entre os dois processos emcomunicação.

A Figura 5.4 ilustra o processo de geração do modelo em tempo de execuçãoda sessão de comunicação quando uma entidade local inicia a comunicação com umaentidade remota. Esse processo é resumido em cinco fases, nas quais as fases 1, 2, 3 e 5

são executadas na camada Synthesis Engine (SE) e a fase 4 é executada na camada Control

and Configuration (CC). Todas essas fases são realizadas tanto pelo middleware daentidade local, quanto pelo middleware da entidade remota. Elas iniciam imediatamente

5.3 Implementação 72

após a conexão, momento em que a camada Thing Broker (TB) cria um wrapper socket

utilizado na conexão.

Figura 5.4: Geração do Modelo de Sessão de Comunicação

Tomando como referência a entidade local, na fase 1 da Figura 5.4, são selecio-nados o requisitos de segurança que serão utilizados para configurar a segurança da sessãode comunicação entre uma entidade local e uma remota. Os requisitos de segurança se-lecionados pelo middleware da entidade local devem possuir um escopo de entidade queenvolva o tipo de entidade do middleware remoto, e vice-versa. Na fase 2, os requisitosselecionados são sintetizados (transformados) em comandos de segurança, os quais sãoenviados para a camada CC. A camada CC, mapeia os comandos de segurança recebidosem Cipher Suites que será negociado pelo protocolo TLS com a entidade remota. O Cipher

Suite escolhido na negociação será utilizado para configurar a segurança do socket encap-sulado no wrapper e, na fase 5, a camada SE gera um modelo em tempo de execuçãoque representa a sessão de comunicação entre a entidade local e a entidade remota. Omodelo da sessão de comunicação identifica o par de entidades que se comunicam e aconfiguração de segurança adotada.

5.3 Implementação

Nesta seção, serão apresentados alguns detalhes de implementação da ca-mada Synthesis Engine (SE), da camada Control and Configuration (CC). Sobre a ca-mada SE, a seção 5.3.1 discute sobre sobre a comunicação entre as camadas middleware

por meio do manipulador de sinais. Além disso, a seção 5.3.2 discute a implementação dalinguagem de modelagem de requisitos (TRML) e, na seção 5.3.3, será discutido imple-mentação da camada (CC) será usando o TLS como o único protocolo de segurança

A Figura 5.5 ilustra a organização do projeto do middleware, no qual a ca-mada SE foi implementada no pacote br.ufg.inf.middleware.layer.synthesis ea camada CC no pacote br.ufg.inf.middleware.layer.configurationcontrol.As interfaces do manipulador de sinais, encontra-se implementado no pa-cote br.ufg.inf.middleware.signal.


Figura 5.5: Pacotes do Projeto

5.3.1 Tratamento de Sinais

Como mencionado na seção 5.1, o comportamento da camada Synthesis Engine,e das demais camadas, é definido pela forma como a camada reage às chamadas recebidasda camada superior e aos eventos sinalizados pela camada inferior. Neste trabalho, assolicitações recebidas da camada superior são denominadas chamadas e o termo sinal éutilizado para designar de forma generalizada um evento ou chamada. Assim, um sinalpode representar tanto uma solicitação recebida da camada superior quanto um eventogerado por uma camada inferior.

A Figura 5.6, ilustra o diagrama de classes que participam do tratamento de si-nais. Um dos principais elementos desse diagrama é a classe abstrata SignalManager,que possui quatro implementações concretas, sendo elas a TB_SignalManager utili-zado pela camada Thing Broker, a CC_SignalManager utilizado pela camada Control

and Configuration e a SE_SignalManager utilizado pela camada Sythesis Engine. Aclasse SignalManager tem como atributo o topLayer que referencia a camada imedi-atamente superior à camada do gerenciador de sinal, o bottomLayer que referencia a


camada inferior, o registrySignalAction que é um mapa de registro dos sinais que se-rão tratados pela camada do SignalManager e associa a ações que serão realizadas coma ocorrência do sinal associado.

Figura 5.6: Diagrama de Classe de Eventos e Gerenciador deEventos

A classe SignalManager é responsável por gerenciar o envio e recebimento desinais, por tratar sinais e por registrar a ação que atenderá um sinal recebido.

Quando uma camada deseja enviar um sinal para outra camada, ela terá queusar o método sendSignal(Signal signal) de seu SignalManager, passando comoparâmetro uma implementação concreta da classe abstrata Call ou Event, sendo que am-bas são extensões da classe abstrata Signal. O método sendSignal(Signal signal)

irá decidir se enviará o sinal para a camada superior ou inferior através do tipo de si-nal passado como parâmetro. Se o sinal é uma chamada, o SignalManager chamaráo método notify da camada superior referenciada pelo atributo topLayer, passandoo sinal como parâmetro. Por outro lado, se o sinal é um evento, o SignalManager

chama o método call(Signal signal) da camada inferior, referenciada pelo atri-buto bottomLayer, passando o sinal como parâmetro. Com isso, uma determinada ca-mada receberá da camada superior o sinal por meio do método call(Signal signal) ereceberá da camada inferior por meio do método notify(Signal signal), os quaistratarão o sinal recebido invocando o método handlerSignal(Signal signal) deseu SignalManager.

O método handlerSignal(Signal signal), ao receber um sinal,verificará se a sua camada consegue tratar o sinal através do método pri-vado thisLayerCanHandler(Signal signal) do SignalManager. Essa verificaçãoé realizada sobre o registrySignalAction, se houver registro do sinal recebido, o


sinal será tratado por uma ação, associada ao sinal. Se não houver registro do sinalrecebido no registrySignalAction, o sinal será encaminhado, por meio do mé-todo sendSignal(Signal signal), para a próxima camada, que será a superior seo sinal se tratar de um evento ou a inferior se o sinal se tratar de uma chamada. Comisso, cada camada do middleware é responsável por tratar apenas os sinais de suaresponsabilidade.

Uma ação é a implementação da classe abstrata SignalAction, que estende ainterface Runnable, e possui os atributos layer e signal. O atributo layer refere-se àcamada responsável por tratar o sinal associado a ação, ela fornece interfaces para que aação trate o sinal. O atributo signal é o sinal que a ação tratará, ele possui atributos queserão utilizados pela ação durante a execução.

Toda ação deverá ser associada a um sinal no mapa de registro de si-nais (registryAction), por meio do método registrySignalAction(SignalAction

action, Signal signal). As ações, que implementam a interface Runnable, são exe-cutadas por um executor de threads SignalManager, identificado por executorSignaldo tipo ThreadPoopExecutor.

A Figura 5.7, exibe o diagrama de classe com implementações de sinais, queestendem as classes abstratas Call e Event, implementações de SignalManager eimplementações de SignalAction


Figura 5.7: Diagrama de Classe com Implementações de AlgunsEventos e Gerenciadores de Eventos

O SignalManager é inicializado juntamente com a sua camada. No cons-trutor da classe SignalManager, através do método registrySignalAction(Signal

signal, SignalAction action) é registrado os sinais que a sua camada atenderá e asações que serão executadas com o recebimento de sinais de outras camadas associados àação.

A Tabela 5.3, lista as ações e sinais que cada camada trata, por exemplo,a camada Synthesis Engine trata a chamada RemoveRequirementCall enviada pelacamada User Interface (UI) através da ação RemoveRequirementModelAction.


Layerresponsável por

tratar o sinal

Implementaçãodo Gerenciador

de Sinal

Layerque emitiuo sinal

Tipode

SinalImplementação de Sinal Ação tratadora do Sinal

RemoveRequirementCall RemoveRequirementModelActionUser Interface Call

AddNewRequirement AddNewRequirementModelActionNofityRemoveSessionEvent RemoveSessionModelAction

Synthesis Engine SE_SignalManagerControl andConfiguration

EventNofityNewSessionEvent AddNewSessionModelAction

Control andConfiguration

CC_SignalManagerSynthesisEngine

Call ReconfigureSescurityCall ReconfigureSecurityAction

Thing Broker TB_SignalManagerControl andConfiguration

Call StartSSLHandshakeCall StartSSLHandShakeAction

Tabela 5.3: Sinais Tratados por cada Camada

5.3.2 Camada Synthesis Engine (SE)

A camada Camada Synthesis Engine (SE) é responsável por manter o modeloem tempo de execução e sintetizar requisitos de segurança em comandos enviados para acamada Camada Control and Configuration (CC).

Algoritmo de Síntese de Requisitos

O algoritmo de síntese de requisitos apresentado na seção 5.2.2 foi im-plementado na camada SE. A Figura 5.8 ilustra as classes implementadas no pa-cote “br.ufg.inf.middleware.layer.synthesis.algorithm”. As classes deste pa-cote são:

• RequirementsSynthesisAlgorithm: classe que implementa o algoritmo de sín-tese de requisitos;• TraversalStrategy: classe que representa as estratégias de travessia em árvore

(profundidade e largura);• BreadthFirstTreeIterator: classe que implementa a estratégia de travessia em

profundidade da árvore de requisitos e sessões;• DepthFirstTreeIterator: classe que implementa a estratégia de travessia em

largura da árvore de requisitos e sessões;• Tree: classe que representa a estrutura de dados em árvore;• Node: classe que representa o nó da árvore.

Figura 5.8: Pacote com as Classes que Implementam o Algoritmode Síntese de Requisitos


Metamodelo

O metamodelo apresentado na seção 4.2.1 foi implementado na camada SE. AFigura 5.9 ilustra o pacote com as classes que implementam o metamodelo que permitemconstruir modelos que podem ser usados pelo usuário para compreender, configurar emodificar a segurança em tempo de execução.

Figura 5.9: Pacote com as Classes que Implementam o Metamo-delo

Trust Requirement Modeling Language - TRML

Neste trabalho, foi desenvolvido uma linguagem de especifica de domínio in-

terna (DSL), denominada Trust Requirement Modeling Language (TRML), para modela-gem de requisitos de segurança. Um dos motivos que influenciou implementar a TRML

em DSL interna é que, diferentemente das DSL externas, não é necessário aprender so-bre gramáticas e análise sintática de linguagens, e, diferentemente das bancadas de lin-guagens, não precisa de qualquer ferramenta especial [17]. Além disso, acredita-se queseria investido menos tempo no desenvolvimento da TRML em uma DSL interna do queusando o metameta-modelo MOF, as ferramentas tradicionais como Eclipse Modeling

Framework e o metamodelo denominado Ecore.Como a TRML foi implementada em uma linguagem hospedeira optou-se por

projetá-la para ser usada com encadeamento de métodos. O encadeamento de métodos usauma sequência de chamadas a métodos na qual cada chamada age sobre o resultado daschamada anteriores. Os métodos são compostos a partir da chamada de um sobre o outro.A Figura 5.10 mostra o encadeamento do métodos na especificação de dois exemplos derequisitos em TRML usando Java.


Figura 5.10: Exemplo de Requisito de Segurança Especificado naTRML Java

A abordagem de encadeamento de métodos permite compor múltiplas chamadasde métodos sem depender de muitas variáveis, o que causa ao código uma sensação defluxo e fluidez, parecendo-se mais com uma linguagem. Além disso, segundo Fowler [17],a curva de aprendizado parece ser favorável ao uso de uma DSL externa.

A Figura 5.11 ilustra os pacotes das classes que implementam a TRML ea Figura 5.12 ilustra o diagrama de classes que implementam a TRML. No pa-cote br.ufg.inf.middleware.layer.synthesis.dsl.model.builder foram imple-mentadas 7 classes, que totalizaram 396 linhas. A especificação de um requisitocomeça pelo método TRUST_IN(entrustedEntityType: Class<TrustedEntity>)

da classe TrustInBuider, passando como parâmetro entrustedEntityType dotipo Class<TrustedEntity> que informa o tipo de entidade que deverá atender as exi-gências de segurança do requisito para interagir com a entidade dona do requisito. Essaclasse criará instância do elemento Scope do metamodelo ilustrado na Figura 4.3..

Figura 5.11: Pacote com as Classes que Implementam a TRML

O método TRUST_IN retorna à classe ForBuilder, que fornece o mé-todo FOR(action: ActionEnum). O método FOR(action: ActionEnum) re-cebe como parâmetro um ActionEnum para informar qual o tipo de ação seráautorizada se as exigências de segurança forem satisfeitas. Os tipos de açõessão SEND_DATA_AND_RECEIVE_DATA, NOTHING e CONNECT, ambos geram instânciasdo elemento Action do metamodelo ilustrado na Figura 4.3.


O método FOR(action: ActionEnum) retorna à classe IfBuilder que, atravésdo método IF, especifica a condição de segurança que deve ser satisfeita pela entidadeque for interagir com a entidade proprietária do requisito. O método IF instancia oelemento Condition do metamodelo ilustrado na Figura 4.3 e possui três assinaturascom número e tipo de parâmetros diferentes. Essas assinaturas forçam a especificação deuma condição que contenha pelos menos um nível de segurança, de confidencialidadeou autenticação.O retorno do método IF é a classe Requirement, o que encerra oencadeamento de métodos da linguagem.

Figura 5.12: Diagrama de Classe da TRML

5.3.3 Camada Control and Configuration (CC)

A camada Control and Configuration (CC) é responsável por implementarprotocolos de segurança da camada de transporte. Dessa forma, é essa camada querealiza configuração e reconfiguração da segurança na comunicação. No entanto, comoo foco deste trabalho foi sobre a camada Synthesis Engine (SE), a camada Control

and Configuration (CC) foi implementada apenas com o protocolo TLS/SSL [16, 20],sendo que seus principais objetivos são garantir confidencialidade dos dados em umacomunicação entre duas aplicações e autenticação dos participantes da comunicação.

A configuração da segurança é realizada a partir do momento em que a ca-mada Synthesis Engine (SE) realiza a chamada ReconfigureSecurityCall para a ca-mada Control and Configuration (CC) por meio da implementação do método call dainterface Layer. A chamada ReconfigureSecurityCall é realizada com dois atribu-tos sessão de comunicação e configuração de segurança.


Com isso, o gerenciador de sinais CC_SignalManager da ca-mada Control and Configuration (CC) recupera do mapa de registro de ações

(registryAction) a ação ReconfigureSecurityAction que atenderá o si-

nal ReconfigureSecurityCall. Em seguida, o gerenciador de sinais adiciona na ação

o sinal recebido e solicita para o executor de threads executar a ação.A ação ReconfigureSecurityAction, em sua execução, chama o

método negotiateSecurity(Session session, SecurityConfiguration

secConfig) passando como parâmetro a sessão de comunicação e a configuraçãode segurança recuperados do signal.

Na execução do método negotiateSecurity(Session session,

SecurityConfiguration secConfig) é obtido o SSLSocketWrapper da sessão decomunicação. O SSLSocketWrapper oferece a mesma interface de sockets tradicionaisda API Java, escondendo a complexidade e reconfiguração subjacente ao funcionamentoda arquitetura do middleware.

O atributo SecurityConfiguration, passado por parâmetro aométodo negotiateSecurity(Session session, SecurityConfiguration

secConfig), é composto chaves que identificam o nível de segurança (autenticaçãoe confidencialidade) especificado pelo requisito.

As chaves são mapeadas para um conjunto de codificações que combinam algo-ritmos criptográficos do protocolo TLS/SSL. Esse mapeamento, entre a configuração desegurança e o conjunto de codificações criptográficas, é realizado por meio dos arqui-vos de propriedades authentication.properties e confidentiality.properties

salvos no middleware, sendo ambos arquivos parametrizáveis. A Listagem 5.1 exibe oconteúdo do arquivo authentication.properties e a Listagem 5.2 exibe o conteúdodo arquivo confidentiality.properties. Ambos arquivos descrevem níveis de segu-rança da TRML e os respectivos algoritmos criptográficos do protocolo TLS/SSL para serusado configuração da segurança da comunicação.

1 USE_AUTHENTICATION=RSA_

2 NO_USE_AUTHENTICATION=DH_anon_

3 NOT_USE_AUTHENTICATION_WITH_CONF_NULL=

ECDH_anon_

Listagem 5.1: Arquivo com mapeamento de algoritmos de

autenticação


1 #256

2 STRONG_KEY=WITH_AES_256_CBC_SHA

3 #128

4 MEDIUM_KEY=WITH_AES_128_CBC_SHA

5 #56

6 WEAK_KEY=WITH_DES_CBC_SHA

7 #0

8 ABSENT=WITH_NULL_SHA256

9 #0

10 ABSENT_WHEN_AUTH_IS_EXEMPT=WITH_NULL_SHA

Listagem 5.2: Arquivo com mapeamento de algoritmos de

confidencialidade

Por exemplo, na Listagem 5.3 exibe o requisito de um leito inteli-gente em linguagem em TRML, sintetizado na camada Synthesis Engine emum SecurityConfiguration (comando) enviado para a camada Control and Confi-

guration (CC). A camada Control and Configuration (CC), recupera a chave do nívelde segurança no SecurityConfiguration e verifica nos arquivos de propriedades,da Listagem 5.2 e 5.1, qual o algoritmo associado à chave. Para o requisito na Lista-gem 5.3, a chave do nível de segurança é MEDIUM_KEY e está associado ao conjunto dealgoritmos DH_anon_WITH_AES_128_CBC_SHA.

1 TRUST_IN SMARTPHONE FOR SEND_AND_RECEIVE_DATA

IF USE_MIN_MEDIUM_ENCRYPTION

Listagem 5.3: Exemplo de Requisito de Segurança em TRML

Através do método setEnabledCipherSuites(String[] suites), protegidopara ser acessado apenas por classes do mesmo pacote do SSLSocketWrapper, o con-junto de codificações é adicionado no socket encapsulado pelo SSLSocketWrapper paradisponibilizá-los ao uso em conexões (comunicação). O parâmetro String[] suites serefere ao conjunto de de codificações, ou Cipher Suite, que combina algoritmos criptográ-ficos para serem utilizados em uma conexão SSL e TLS. Os arquivos na Listagem 5.2 e 5.1exibem os algoritmos usados pela camada Control and Configuration (CC) para comporum Cipher Suite.

Inicialmente, um CipherSuite padrão será ativado em um novo SSLSocketWrapperque representa o conjunto de codificação mínima, que ele não estabelece algoritmos deautenticação e de criptografia.

O CipherSuite padrão permanece no SSLSocketWrapper enquanto não houverrequisitos de segurança para alterar o conjunto de codificação. Durante uma conexão,se ambos os lados aceitarem explicitamente comunicação não autenticado e não-privado

5.4 Conclusão 83

(sem criptografia) será selecionado o CipherSuite padrão na comunicação.Finalmente, após a execução do método setEnabledCipherSuites(String[]

suites), é chamado o método startHandshake() do SSLSocketWrapper que inicia anegociação de segurança durante o handshaking.

Durante esse processo de negociação, os dois pontos finais da conexão de-vem concordar sobre um Cipher Suite, que deverá estar disponível em ambos os am-bientes. Se não existir esse suite em comum, nenhuma conexão SSL/TLS será estabe-lecida e os dados não poderão ser trocados. A qualquer momento da conexão, o mé-todo startHandshake() pode ser invocado para renegociar a segurança da comunicaçãoatravés da troca do Cipher Suite.

5.4 Conclusão

Neste capítulo, foi discutido a arquitetura de middleware para síntese de requisi-tos de segurança e geração de comandos de reconfiguração da segurança da comunicaçãoentre entidades na IoT. Apesar desse trabalho ter como foco na camada Synthesis En-

gine, as demais camadas foram discutidas, apresentando suas principais responsabilidadesno middleware.

Neste capítulo foi discutido em detalhes como é realizada a síntese de requisitosde segurança na camada Synthesis Engine (SE) e como são gerados os comandos de con-figuração da segurança enviados e processados pela camada Control and Configuration

(CC). Além disso, foi discutido como o modelo em tempo de execução é mantido pela ca-mada Synthesis Engine, como as camadas do middleware se comunicam, como é iniciadaa síntese de requisitos.

Por fim, este trabalho apresentou a implementação da linguagem Trust Require-

ment Modeling Language, a implementação dos sinais emitidos durante a comunicaçãoentre as camadas do middleware e implementação da camada CC usando TLS como únicoprotocolo para reconfigurar a segurança da comunicação.

CAPÍTULO 6Estudo de Caso e Avaliação

Com o intuito de avaliar e demonstrar a viabilidade da abordagem proposta parareconfiguração da segurança de entidades em ambientes de IoT, será apresentado nessecapítulo um cenário baseado em dados reais e a avaliação de impacto da reconfiguraçãoda segurança pelo middleware no desempenho do dispositivo do usuário. O objetivo daavaliação foi verificar o tempo gasto na síntese de requisitos especificados em modelosem tempo de execução.

A seção 6.1, discute a metodologia empregada na realização da avaliação. Naseção 6.2 apresenta um estudo de caso projetado com base em dados reais. Por fim, aseção 6.3 apresenta a avaliação realizada para medir o desempenho da camada Synthesis

Engine (SE) do middleware.

6.1 Metodologia

Para realizar essa avaliação, foi realizado um conjunto de experimentos querepresentam as etapas mais críticas na síntese de requisitos de segurança e geraçãode comandos para reconfiguração da segurança em sessões de comunicação, ambosocorridos na camada Synthesis Engine (SE).

Os experimentos foram realizados com base nos dados disponibilizadas peloprojeto Device Analyzer [1] sobre as rotinas de uso de smartphones para identificarcenários hostis no mundo real em que o usuário encontra-se vulnerável.

O ambiente para realização dos experimentos sobre a camada Synthesis Engine

consiste em um computador com processador 1,3 GHz Intel Core i5, memória 4 GB 1600

MHz DDR3, Sistema Operacional Mac OS X Yosemite 64 bits rodando uma JVM 8.O objetivo da avaliação é verificar a escalabilidade da camada Synthesis En-

gine mostrando quantos requisitos de segurança podem ser sintetizados para configurar asegurança de sessões de comunicação ou conexão sem impactar grandemente o funciona-mento do objeto inteligente do usuário. Esse cenário 6.2 foi escolhido como tentativa detornar a avaliação mais próxima da realidade, pois número de sessões que serão reconfi-guradas pela síntese de requisitos será baseado no número de conexões que o smartphone

6.1 Metodologia 85

do usuário realizou em pontos de acessos disponíveis. Dessa forma, o middleware serásubmetido ao processamento de um volume de entradas criadas baseadas em um cenárioreal.

Com isso, a camada Synthesis Engine foi testada com um número de sessõespróximo ao número de pontos de acesso conectados pelo usuário durante a semana. Alémdisso, para analisar a escalabilidade, a camada Synthesis Engine foi testada com umnúmero de sessões superior ao do cenário simulado para verificar quantas sessões podemser reconfiguradas e quantos requisitos de segurança podem ser analisados pelo algoritmosem impactar grandemente o funcionamento do dispositivo do usuário.

A camada Synthesis Engine foi submetida a testes que tinham como entradauma lista de requisitos de segurança e uma lista de sessões de comunicação. A cada teste,o tamanho da lista de requisitos e sessões foi variado, sendo que o tamanho da lista desessões se baseia no número de conexões entre o smartphone do usuário e pontos deacessos no cenário discutido na seção 6.2.

Durante o teste, o middleware analisou as entradas para verificar se algumasessão deverá ser reconfigurada a partir da síntese de requisitos. Se houver alguma sessãoque precise ser reconfigurada, ou seja, se existir algum requisito de segurança que poderáser aplicado em alguma sessão, espera-se que os requisitos de segurança sejam avaliadose sintetizados em configurações de segurança e essas sessões sejam reconfiguradas comconfigurações de segurança geradas pela síntese de requisitos.

Na avaliação, um teste com a mesma configuração de entrada, lista de requisitosde mesmo tamanho e lista de sessões de mesmo tamanho foi executado 100 (cem) vezes.A cada execução do teste, foi criada uma nova lista com mesmo número de sessõesde comunicação entre entidades (Smartphone, Thing, Host, PhysicalEntity, AccessPoint,

LogicalEntity, Service, Application e TrustedEntity) escolhidas de forma aleatória etambém foi gerada uma nova lista com o mesmo número de requisitos de segurança apartir de escolhas aleatórias das cláusulas (TRUST_IN, FOR e IF) dos requisitos. Porexemplo, para o teste realizado com a entrada de uma lista com 10 (dez) sessões e umalista com 1 (um) requisito, a execução do algoritmo foi repetida por 100 (cem) vezes,sendo que a cada repetição foi gerado uma nova lista com 10 (dez) sessões criadasaleatoriamente e uma nova lista com 1 (um) requisito criado aleatoriamente.

As 100 (cem) repetições de execução de um teste com a mesma configuraçãode entrada, com a lista de requisitos e sessões criadas de forma aleatória, foi necessáriopara, através da média do tempo dessas execuções, minimizar o impacto no tempo quea composição do requisito de segurança pode causar. A composição de um requisito dizrespeito ao conjunto de valores associados às cláusulas do requisito que podem influenciarna variação do tempo de síntese pela camada Synthesis Engine.

Dessa forma, sendo T(r,s) o tempo médio de 100 (cem) execuções de um teste

6.2 Estudo de caso 86

com a mesma configuração (r,s), sendo r o número de requisitos e s o número de sessões,e ti o tempo individual de cada uma das 100 (cem) execuções, para calcular o tempo deexecução de um teste com a mesma configuração tem-se a equação 6-1.

T(r,s) =100

∑i=1

ti ∗100−1 (6-1)

No entanto, mesmo com execuções para o cálculo do tempo médio, algumasmedições do tempo de execução, chamadas de outliers, tinham um tempo nitidamentedistante das demais medições de tempo execução. Para evitar que o tempo médio fossedistorcido pelos outliers, foi descartado 10% (dez porcento) das maiores medidas detempo e 10% (dez porcento) das menores medidas de tempo. Desse modo, com os temposindividuais ordenados das execuções, para calcular o tempo de execução de um teste coma mesma configuração descartando os outliers tem-se a equação 6-2.

T(r,s) =90

∑i=10

ti ∗80−1 (6-2)

A média do tempo (sem os outliers) de 100 (cem) execuções da camada Synthe-

sis Engine com entradas de 10 (dez), 100 (cem), 1.000 (mil) e 10.000 (dez mil) sessões eo número de requisitos variando de 0 (zero) a 100 (sem) é ilustrado no gráfico da Figura6.10.

O tempo efetivo usado no cálculo da média ilustrado no gráfico, é apenas o tempoque a camada Synthesis Engine demora para sintetizar requisitos de segurança, buscar porsessões que precisam ter a segurança configurada, selecionar requisitos que devem sersintetizados e gerar comandos de configuração da segurança para as sessões encontradas.

O tempo para adicionar sessões e requisitos de segurança na estrutura de dadosem árvore 5.2.1 não é contabilizado. Além disso, o tempo gasto pela demais camadastambém não é contabilizado, como por exemplo o tempo gasto pela camada Control and

Configuration para processar os comandos de segurança (recebidos da camada Synthesis

Engine) e configurar a segurança das sessões.

6.2 Estudo de caso

A Figura 6.1 ilustra uma cidade com inúmeras redes sem fio disponíveis, sendoque cada uma pode apresentar perfis e características de segurança distintas. Nessa cidadehá um usuário que ao circular por ela, conecta seu smartphone em diferentes redes semfio situadas em diferentes ambientes como a sua casa, a rua, o restaurante e o trabalho.


Figura 6.1: Redes Disponíveis

Nesse cenário, será analisada a segurança das redes conectadas, a variação doperfil de segurança das redes efetivamente conectadas e as características dos pontos deacesso conectados. Pensando em apresentar um cenário próximo a realidade, os dadosanalisados nesse cenário, como o nível de segurança das redes disponíveis, a quanti-dade de redes disponíveis e as características de segurança dos pontos de acesso encon-trados foram extraídos de um dataset fornecido por um grupo de pesquisa da Univer-

sity of Cambridge [1]. Esse grupo desenvolveu uma aplicação chamada Device Analyzer

para smartphones com Android, que foi instalada em aproximadamente 12.500 dispositi-vos espalhados por 167 países, ao longo de dois anos. Com isso, foram coletados mais de53 bilhões de registros sobre o uso real dos smartphones. Dentre esse conjunto, apenas321 smartphones participaram do projeto pelo menos por um ano.

A aplicação Device Analyzer captura um log em série temporal mais de 200 even-tos diferentes. Os eventos registrados incluem alterações nas configurações do dispositivo,aplicativos instalados, as características do sistema operacional, dispositivos bluetooth, re-des sem fio, armazenamento em disco, as características do carregamento, telefonia, o usode dados, informações de CPU e memória para cada aplicação e muitos mais. Uma listacompleta dos dados coletados está disponível no website do projeto Device Analyzer [1].

Nesse trabalho, foi selecionado o dispositivo que forneceu dados com maiorriqueza sobre redes sem fio conectadas e encontradas na varredura. Por exemplo, odispositivo escolhido forneceu dados não apenas de quando um smartphone conecta emum ponto de acesso sem fio, mas também todos os detalhes capturados sempre que umavarredura de redes sem fio ocorre, incluindo o endereço MAC, o SSID, a frequência, aforça do sinal e as capacidades de segurança. Os critérios de seleção do smartphone paraanálise dos dados foram:


• o smartphone que registrou o maior número de dados sobre redes sem fiocomo SSID, Capacidades de Segurança, Endereço MAC de redes conectadas e en-contradas pelo dispositivo.• dar preferência para o smartphone que registrou os dados de interesse por mais

tempo;

Os dados foram filtrados para selecionar apenas dados gerados a partir deconexões em pontos de acesso e varreduras de rede sem fio pelo smartphone. Com isso,dados como SSID, Capacidades de Segurança e Endereço MAC foram persistidos emum banco de dados para permitir consultá-los e analisá-los de forma mais eficiente.

A Figura 6.2 exibe uma tabela de banco de dados criada para armazenar dados deinteresse deste trabalho extraídos do arquivo de texto disponibilizado pelo projeto Device

Analyzer.

Figura 6.2: Exemplo de Dados Disponibilizados pelo Projeto De-vice Analyzer [57]

Essa tabela exibe um trecho dos dados disponibilizados durante uma varredurade redes sem fio, contendo na primeira coluna o número da linha do arquivo de texto queencontra-se o registro, na segunda coluna o tempo em milissegundos desde a última coletade dados do smartphone, na terceira coluna o dia que o dado foi coletado do smartphone,na quarta coluna a chave de identificação do dado, na quinta coluna o valor associadoa chave da quarta coluna. Como os dados de nosso interesse são os dados sobre redessem fio, na tabela ilustrada pela Figura 6.2, todas as chaves que identificam os dados sãocompostas pela concatenação do marcador wifi com outros marcadores, sendo eles:

• connected: Informações sobre a rede sem fio que o dispositivo está conectado nomomento

– [BSSID]: O hash do endereço MAC do ponto de acesso.

∗ ssid: O hash do nome da rede que é exibida para o usuário. Múltiplospontos de acesso podem pertencer a uma mesma rede.∗ RSSI: A intensidade do sinal.∗ LinkSpeed: A velocidade de conexão atual do dispositivo.

• scancomplete : Marcador que indica que a varredura de rede sem fio terminou. Ovalor contém o número de pontos de acesso visíveis.• scan: resultados de uma varredura para redes sem fio no alcance


– [BSSID]: O hash do endereço MAC do ponto de acesso.

∗ ssid: O hash do nome da rede que é exibida para o usuário, sendo quemúltiplos pontos de acesso podem pertencer a uma mesma rede.∗ level: A força do sinal. Note-se que este não é o mesmo que o RSSI.∗ frequency: A frequência que este ponto de acesso está operando, isto

corresponde aos canais de rede sem fio.∗ capabilities: A saída do ScanResult.capabilities para este ponto de

acesso.

• state: O estado do subsistema dede rede sem fio alterado. Há uma série de possíveisvalores para esta chave:

– disabled: Um valor que indica que o subsistema de de rede sem fio estádesativado

– disabling: Um valor que indica que o subsistema de de rede sem fio está sendodesligado.

– enabled: Um valor indicando que a subsistema de rede sem fio está ativo– enabling: Um valor indicando que a subsistema de rede sem fio está sendo

ativado.– unknown: Um valor que indica que o estado da subsistema de rede sem fio é

desconhecido.

Os dados persistidos foram analisados com o objetivo de verificar com quefrequência o usuário encontrou e usou redes sem fio desprotegidas ou com mecanismosde segurança que apresentam vulnerabilidades fáceis de serem exploradas por agentesmaliciosos.

Com essa análise, foi gerado o gráfico na Figura 6.3 que exibe os pontos deacesso encontrados pelo smartphone do usuário entre os dias 01/04/2012 e 01/01/2014.Analisando esse gráfico, no mês de junho, o smartphone encontrou cerca de 2.000vezes pontos de acesso sem segurança. Esse número é alto porque os pontos de acessoencontrados não foram distinguidos. Dessa forma, certamente um mesmo ponto deacesso foi contabilizado mais de uma vez. Além disso, a aplicação do projeto Device

Analyzer [57] instalada no dispositivo do usuário para coleta de informações, repetia avarredura em pequenos intervalos de tempo na busca de redes sem fio.


Figura 6.3: Pontos de Acesso Encontrados por Tipo de Segurança

A Figura 6.4 exibe a quantidade de conexões em redes (não distintas) realizadaspelo smartphone do usuário no mesmo período de análise do gráfico ilustrado pelaFigura 6.3. No gráfico da Figura 6.4, observa-se o predomínio de conexões em pontosde acesso sem segurança, representadas em vermelho.


Figura 6.4: Conexões em Pontos de Acesso por Tipo de Segurança

Relacionando a informações exibidas nas Figuras 6.3 e 6.4, observa-se que,durante o ano, apesar do smartphone do usuário ter encontrado na maioria pontos deacesso usando WAP2 (nível de segurança alto), a maioria das conexões foram realizadasem pontos de acesso sem segurança.

Para o mesmo usuário, também foi analisado o seu comportamento no períodode uma semana, de domingo dia 2 de junho de 2013 ao sábado dia 08 de junho de 2013.Esse período foi escolhido por se tratar de um intervalo em que o usuário encontrou econectou em diversas redes sem segurança no decorrer do dia. Com isso, foram geradosos gráficos ilustrados nas Figuras 6.5, 6.6 e 6.8,

A Figura 6.5, exibe dados reais da segurança em redes encontradaspelo smartphone do usuário durante a semana. Na quarta-feira, quinta-feira e sexta-feira foram os dias em que o smartphone encontrou maior número de redes, uma médiade 445 pontos de acesso ao dia. Observa-se que durante o período avaliado, o usuário sedeparou com pontos de acesso sem segurança e com segurança WEP e WPA, que segundoLashkari et al. [33] há vulnerabilidades fáceis de serem exploradas. A configuração desegurança desses pontos de acesso tem o perfil típico de locais públicos e comerciais queofertam acesso a Internet, como restaurantes, aeroportos e praças públicas. Isso indicaque, possivelmente, o usuário circulou por esses locais.


Figura 6.5: Segurança nas Redes Distintas Disponíveis

Além disso, nota-se que foram encontrados pontos de acesso com WPA2, queatualmente há poucas vulnerabilidades conhecidas. Talvez, mais vulnerabilidades aindanão foram descobertas porque os dispositivos que suportam o WPA2 ainda não sãolargamente utilizados. Mas mesmo assim, segundo Linhares et al. [14], os pontos deacesso com WPA2 também não protegem a rede de forma integral, embora esse tipode configuração de pontos de acesso é um dos mais seguros disponíveis. Os pontos deacesso que ofertam conexão com WPA2, é mais comum de ser encontrado em ambientesde trabalho, ambientes corporativos e, quiçá, ambientes residenciais.

Esse cenário real, ilustrado pela Figura 6.5, possui um baixo nível de segurançadas redes disponíveis. Em um ambiente de IoT, essas redes possuem vulnerabilidades queimpactariam na segurança dos objetos. Com isso, o nível de segurança geral desse cenárionão é suficiente para manter os objetos seguros de ameaças.

No gráfico da Figura 6.6, é ilustrado a quantidade de conexões realizadas empontos de acesso pelo smartphone do usuário selecionado por dia na semana. No eixo x

desse gráfico, estão dispostos a identificação dos pontos de acesso composta por SSID| MAC | Nível de Segurança, sendo o SSID o nome da rede, o MAC a representação(abstraída em até 4 caracteres) do endereço físico associado à interface do ponto de acessoe o Nível de Segurança diz respeito ao protocolo de segurança do ponto de acesso.

Para efeito de geração do gráfico, foi considerado quatro níveis de segurança:S0, que corresponde a pontos de acesso sem segurança; S1, que corresponde a pontosde acesso com segurança baixa (WEP); S2, que corresponde a pontos de acesso comsegurança média (WPA); S3, que corresponde a pontos de acesso com segurança alta


(WPA2). A identificação dos pontos de acesso está marcada em vermelho, laranja, azule verde que sinaliza respectivamente os níveis de segurança sem Segurança, segurança

baixa, segurança média, e segurança alta. Nesse gráfico pode ser visto pontos de acessosque possuem na identificação o mesmo SSID e MAC diferentes. Isso acontece em pontosde acesso que funcionam como repetidores de sinal. Dessa forma, esses pontos de acessocom o mesmo dão acesso a mesma rede.

O eixo y do gráfico ilustrado na Figura 6.6 exibe a quantidade de conexõesem pontos de acesso. Comparando os gráficos das Figuras 6.5 e 6.6, nota-se que emdeterminados dias da semana o número de pontos de acesso encontrados foi menor doque o número de conexões, isso aconteceu porque sempre que o smartphone saía domodo stand-by e usava a rede era foi contabilizado uma conexão. Nesse gráfico, observa-se que o usuário conectou em quase 100% das vezes em pontos de acesso sem segurança.Possivelmente esses pontos de acesso são de locais públicos como praças, universidadese restaurantes que ofertam acesso livre à Internet.

Figura 6.6: Segurança nas Redes Conectadas

Conforme é ilustrado na Figura 6.5, apesar de haver disponibilidade de pontosde acesso com segurança alta praticamente todos os dias da semana, de acordo coma Figura 6.6, o uso efetivo se deu nos pontos de acesso que ofertaram configuraçõesde segurança inferiores. Dessa forma, o perfil de segurança das redes efetivamenteconectadas pelo usuário é inseguro.

A Figura 6.7 exibe as conexões realizadas pelo smartphone do usuário no períodoentre sábado de 07/09/13 e sexta-feira de 13/09/13. O eixo x identifica os pontos de acessoque foram conectados por meio do SSID, mostra o nível de segurança dos pontos deacesso e a data que o smartphone do usuário conectou no ponto de acesso. As barrasno eixo x estão coloridas com as cores, vermelho, laranja, azul e verde que identificam o


nível de segurança do ponto de acesso. A cor vermelha se refere a pontos de acesso comsem segurança - S0 (sem segurança), a cor laranja referencia pontos de acesso com nívelde segurança baixa - S1 (WEP), a cor azul referencia pontos de acesso com segurançamédia - S2 (WPA) e a cor verde referencia pontos de acesso com a segurança alta - S3

(WPA2). Por exemplo, no sábado, dia 07/09/13, o usuário conectou em dois pontos deacesso, o AP01 com segurança nível S3 (WPA2) e o AP02 com nível de segurança S0

(sem segurança). O eixo y exibe a quantidade de conexões nos pontos de acesso.

Figura 6.7: Conexões Realizadas no Mês de Setembro

Diante de um ambiente que disponibiliza pontos de acesso inseguros e vulnerá-veis, o usuário poderia ser motivado a especificar um requisito de segurança que permitaa seu smartphone conectar apenas em pontos de acesso com no mínimo com segurançamédia como, por exemplo, usando WPA. Para tal, o usuário poderia especificar como re-quisito que os pontos de acesso disponíveis seriam filtrados e apenas os pontos de acessodestacados no gráfico da Figura 6.8 seriam conectados pelo smartphone do usuário.

Figura 6.8: Conexões Realizadas no Mês de Setembro

6.3 Desempenho do Algoritmo de Síntese de Requisitos 95

De acordo com análise dos dados e do gráfico na Figura 6.6, durante o anohouve predominância de conexões em pontos de acesso inseguros embora tenha existidopredominância na disponibilidade de pontos de acesso seguros conforme é ilustrado nográfico da Figura 6.5. A Figura 6.9 resume o gráfico da Figura 6.5 exibindo a porcentagemde pontos de acesso disponíveis por nível de segurança durante a semana analisada. Ocomportamento do usuário verificado durante o ano se repetiu durante a semana analisada:de acordo com o gráfico da Figura 6.6 mesmo com a predominância de 64% de pontos deacesso disponíveis com segurança alta, segundo a gráfico da Figura 6.7 o usuário conectouem pontos de acesso sem segurança na maioria das vezes.

Figura 6.9: Porcentagem de Pontos de Acessos Disponíveis Agru-pados por Segurança

De modo geral, pode-se concluir que o smartphone do usuário encontrou ummaior número de pontos de acesso que apresentam segurança do que pontos de acessosem segurança e conectou em um maior número de pontos de acesso sem segurança doque em pontos de acesso com segurança. Com isso, o usuário esteve a maior parte dotempo conectado em ponto de acessos que apresentam vulnerabilidades fáceis de seremexploradas por agentes maliciosos.

6.3 Desempenho do Algoritmo de Síntese de Requisitos

O eixo x do gráfico na Figura 6.10 exibe o número de requisitos que vão de zeroaté 100 (cem). No mundo real, certamente o usuário teria poucos requisitos de segurança,um número bem inferior a 100 (cem) requisitos, conforme é explorado no gráfico. Noentanto, foi realizado o teste de síntese de até 100 (cem) requisitos com objetivo deverificar a progressão de tempo, o qual segue uma tendência praticamente linear para10 (dez), 100 (cem), 1.000 (mil) e 10.000 (dez mil) sessões.


Figura 6.10: Tempo de Síntese de Requisitos para Reconfiguraçãoda Segurança de 10 (dez), 100 (cem), 1.000 (mil) e10.000 (dez mil) sessões

A Figura 6.11 exibe o mesmo gráfico da Figura 6.10, no entanto sem o tempo desíntese de requisitos para 10.000 (dez mil) sessões. Nesse gráfico, nota-se que o tempo desíntese de requisitos para 10 (dez), 100 (cem) e 1.000 (mil) sessões são próximos. Observeque o tempo gasto na síntese de aproximadamente 65 (sessenta e cinco) requisitos com 10(dez) sessões foi superior do que o tempo para sintetizar o mesmo número de requisitoscom 1.000 (mil sessões) sessões. Esse fenômeno ocorre por causa da aleatoriedade dasvariáveis envolvidas, como sessões e requisitos de segurança.


Figura 6.11: Tempo de Síntese de Requisitos para Reconfiguraçãoda Segurança de 10 (dez), 100 (cem), e 1.000 (mil)sessões

No cenário real ilustrado pelo gráfico da Figura 6.5, a quinta-feira foi o dia emque o smartphone do usuário encontrou maior número de pontos de acesso, cerca de 619(seiscentos e dezenove) pontos de acesso. Nesse cenário, com a existência de um ou maisrequisitos como TRUST IN ACESS_POINT FOR CONNECT IF USE_STRONG_ENCRYPTION

que especificam exigências de segurança que devem ser atendidas por pontos de acesso, acamada Synthesis Engine teria que analisar se 619 (seiscentos e dezenove) pontos deacesso estão com a segurança configurada de acordo com os requisitos de segurançaespecificados para impedir que o smartphone se conecte em pontos de acesso que nãoatendem as exigências de segurança dos requisitos. Nesse caso, em um cenário real, naquarta-feira, a camada Synthesis Engine teria que analisar 619 (seiscentos e dezenove)análises de pontos de acesso ao longo do dia.

O gráfico da Figura 6.10 mostra que a camada Synthesis Engine demorouaproximadamente 250 (duzentos e cinquenta) microssegundos para analisar se 1.000 (mil)sessões de comunicação estão com a segurança configurada de acordo com os requisitosde segurança especificados. Nesse teste, o número de análises das sessões de comunicaçãofoi quase duas vezes maior do que o número de análises que seriam necessárias paraavaliar os pontos de acesso encontrados durante o dia na quarta-feira do cenário real. Alémdisso, no cenário real, os 619 (seiscentos e dezenove) pontos de acesso foram encontradosno decorrer do dia. Com isso, as análises dos pontos de acesso não seriam realizadas deuma vez, diferentemente do teste que analisou 1.000 (mil) sessões de uma vez. Mesmo

6.4 Limitações 98

assim, com o teste sendo realizado com entradas maiores do que as praticadas no cenárioreal, o tempo gasto na execução da camada Synthesis Engine continuou pequeno.

Comparando o tempo de 500 (quinhentos) microssegundos para execução dacamada Synthesis Engine com tempo de um segundo para negociação da segurançado protocolo TLS registrados pelo trabalho de Argyroudis et al. [4], o overhead dacamada Synthesis Engine é pequeno em relação ao protocolo Handshake do TLS. Como oprotocolo TLS é largamente utilizado de forma transparente por aplicações sem impactaro funcionamento de seu host, pode-se dizer que a camada Synthesis Engine tambémpoderá ser usada de forma transparente por aplicações sem impactar o funcionamento deseu host. Apesar da camada Synthesis Engine e o protocolo TLS se tratarem de elementoscom objetivos diferentes, essa relação foi realizada com intuito de comparar os tempos deexecução das duas soluções e demonstrar que o tempo da camada Synthesis Engine podeser dito aceitável se tomado como referência o tempo de execução do protocolo TLS queé suficientemente rápido para ser largamente utilizado na indústria de software.

Apesar do tempo registrado nos testes ter sido praticamente imperceptível, ele serefere apenas ao tempo de execução da camada de síntese, ou seja, esse é tempo de umadas partes do processo. Pois em uma solução completa, com as quatro camadas do mid-

dleware implementadas, o tempo total de reconfiguração da segurança a partir da modela-gem de requisitos seria o resultado da soma do tempo de execução da camada Synthesis

Engine, Control and Configuration e Thing Broker. Dessa forma, apesar da implementa-ção da camada Synthesis Engine apresentar ser eficiente na síntese de requisitos, o tempototal da solução pode impactar no funcionamento do dispositivo inteligente do usuário seas camadas subjacentes não forem eficientes.

6.4 Limitações

A avaliação do middleware possui algumas limitações, pois ela avaliou apenassobre a perspectiva do tempo gasto na processamento dos requisitos de segurança paratransformá-los em reconfigurações de segurança. Dessa forma, foi avaliado apenas otempo de execução a camada de Synthesis. Por fim, apesar do resultado dessa avaliação tersido promissora, para uma melhor avaliação da aplicabilidade do middleware é necessárioavaliar outras dimensões além do tempo como consumo de energia, processamento ememória. Além disso, para uma avaliação mais precisa, a avaliação do middleware podeser realizada em um dispositivo móvel com recursos de memória, processamento e energialimitados.

CAPÍTULO 7Trabalhos Relacionados

Este capítulo apresenta e discute trabalhos representativos na literatura que pro-põe abordagens de solução para o problema da inflexibilidade de requisitos de segurançaem aplicações que precisam ser alteradas pelo usuário em tempo de execução. Estes tra-balhos são apresentados em duas categorias: aqueles que apresentam abordagens de re-configuração da segurança em tempo de execução e aqueles que apresentam soluções quefornecem uma visão do estado da segurança de entidades na IoT. Este capítulo discuteas abordagens e técnicas utilizadas entre os trabalhos relacionados apontado quais resol-vem o problema proposto. Além disso, este capítulo compara os pontos positivos de cadatrabalho na solução do problema.

Na seção 7.1 discute os trabalhos que lidam com o problema proposto por estetrabalho através de reconfiguração da segurança em tempo de execução. Na seção 7.2apresenta os trabalhos que fornecem uma visão do estado da segurança de entidadesna IoT para ajudar o usuário detectar possíveis ameaças. Por fim, a seção 7.3 discutedetalhadamente o comparativo dos trabalhos relacionados com a solução proposta porteste trabalho, destacando suas características em comum, vantagens e desvantagens.

7.1 Reconfiguração da Segurança em Tempo de Execu-ção

Várias pesquisas tentam entregar soluções com mecanismos recursos de segu-rança adaptáveis. A solução proposta por Yskout et al. [60], concentra-se em refletirmudanças nos requisitos de segurança na arquitetura do sistema em execução e auto-maticamente reconfigurar o sistema de acordo com mudanças na arquitetura em tempode execução. Este trabalho apresenta padrões de mudança arquitetural para refletir mu-danças em requisitos de segurança no modelo arquitetural. O trabalho de Yskout et al.adota models@runtime para representar a arquitetura do sistema em execução, enquantoeste trabalho propõe o uso de modelos em tempo execução para representar requisitos desegurança e sessões de comunicação entre entidades na IoT. Embora a proposta de Yskout

7.1 Reconfiguração da Segurança em Tempo de Execução 100

et al. [60] resolva o problema da inflexibilidade em alterar a segurança de aplicações emtempo de execução, ela não envolve o usuário no loop da reconfiguração da segurança.Por outro lado, a proposta de Yskout et al. [60], tem como alvo requisitos de segurançaem controle de acesso, enquanto a proposta desta dissertação foca em requisitos de segu-rança em autenticação e confidencialidade. Outro diferencial é que a solução proposta porYskout et. al foca em alterações arquiteturais para satisfazer alterações em requisitos desegurança e o nosso trabalho foca em alterações de segurança na comunicação para sa-tisfazer as alterações nos requisitos de segurança. Uma das principais contribuições destetrabalho é o fornecimento de estratégias, princípios e padrões para mudança arquiteturalem resposta a alterações nos requisitos de segurança, os quais podem ser reaproveitadose aplicados em trabalhos futuros.

Almorsyn et. al [3] apresentam uma abordagem de engenharia dirigida por mode-los (MDE) que permite a engenheiros de segurança especificarem e impor dinamicamenterequisitos de segurança do cliente no sistema através de programação orientada a aspectosque permite combinar interceptadores e arquivos de configurações no código que especi-ficam os pontos de segurança no sistema. Para isso, o fornecedor do sistema, em tempo deprojeto ou de implantação, desenvolve um modelo de descrição do sistema a partir de umnovo perfil UML criado por Almorsyn et al. Um perfil é uma UML com um conjunto deestereótipos predefinidos, valores atribuídos, restrições e classes base que permite definiruma nova versão especializada da UML para um determinado domínio [10]. Esse modelocaptura funcionalidades do sistema, classes, componentes, comportamentos e detalhes deimplantação. Um engenheiro de segurança do sistema desenvolve, em tempo de execução,um modelo de especificação de segurança que captura objetivos de segurança, requisitos,arquitetura e controles usados no sistema. A partir da fusão desses dois modelos é geradoum terceiro modelo com a segurança detalhada do sistema para automaticamente injetarno sistema alvo extensões de segurança.

A abordagem adotada por Almorsy et al. [3] também resolve o problema dainflexibilidade dos mecanismos de segurança de aplicações. No entanto, ela necessita daparticipação de especialistas no domínio da aplicação e de engenheiros de segurança paraalterarem a configuração de segurança do sistema.

O trabalho MDSE@R [3] propõe uma nova abordagem orientada a modelos paracoordenar a segurança de forma dinâmica e em tempo de execução em aplicações de soft-ware. MDSE@R se baseia na utilização de um conjunto de modelos de descrição do sis-tema criados durante a fase de projeto pelos desenvolvedores, e um conjunto de modelosde especificação da segurança, modelados por clientes do sistema para capturar detalhesde segurança usando um linguagem visual específica de domínio (DSVLs [48]). MDSE@R

utiliza injeção dinâmica de código e interceptadores de segurança no sistema alvo parafazer cumprir a segurança especificada. Apesar de ser voltada para engenheiros de segu-

7.2 Visão do Estado da Segurança de Entidades na IoT 101

rança e engenheiros de sistema, MDSE@R destaca-se por propor uma linguagem visualque permite modelar atributos e capacidades de segurança que precisam ser cumpridosno sistema e/ou no ambiente operacional. No entanto, este trabalho não envolve o usuáriofinal na alteração da segurança em tempo de execução e não fornece uma visão do es-tado da segurança do sistema em tempo de execução, o que poderia ser usada auxiliar namodelagem de requisitos de segurança.

Morin et al. [39] propõem uma abordagem baseada em modelos e orientada asegurança que permite a adaptação de aplicações para refletir políticas de controle deacesso sensíveis ao contexto. Engenheiros definem políticas de segurança que levamem consideração informações de contexto. Sempre que o contexto do sistema muda,a abordagem proposta atualiza a arquitetura do sistema para aplicar as políticas desegurança. Esta metodologia usa modelos em tempo de execução para manter o modelode arquitetura sincronizado com o sistema funcionando. Quando a política é atualizada, omodelo de arquitetura é atualizado, que por sua vez reconfigura o sistema funcionando.

A proposta de Morin et al. [39], diferentemente da abordagem desta dissertação,altera a configuração de segurança através da alteração de políticas por especialistas emsegurança, o que não envolve o usuário no loop da alteração da segurança. Ela tambémfoca apenas no controle de acesso e não em autenticação e confidencialidade.

As propostas de Almorsy et al. [3], Yskout et al. [60] e Morin et al. [39] resolvemo problema da inflexibilidade da segurança em tempo de execução. No entanto, elas nãoresolvem o problema no cenário que este trabalha trata, no qual o usuário ao entrarem um ambiente dinâmico e imprevisível, faz parte do loop de alteração da segurançaem tempo de execução para lidar com a mudança repentina do ambiente que o deixouvulnerável. Por exemplo, com a entrada de um dispositivo desconhecido (não autenticado)na rede, o usuário pode passar ter como requisito que para se comunicar com o seu relógiointeligente todo dispositivo deverá estar autenticado.

7.2 Visão do Estado da Segurança de Entidades na IoT

A proposta de Schulz et al. [45] se apoia na percepção de confiança por parte dousuário a respeito da IoT, garantindo a transparência das propriedades e conceitos de segu-rança e confiabilidade subjacentes a sistemas interconectados. Os autores desenvolveramo Trust FeedBack Toolkit (TFT) que pode apresentar informações para o usuário sobre aquais dados são coletados (como lista de contatos e localização) e estão sendo transmiti-dos para outros dispositivos na IoT, a segurança utilizada nas conexões realizadas em seudispositivo (se usa criptografia e se o dispositivo na IoT está autenticado).

Com isso, o TFT apresentará para o usuário conceitos de segurança das apli-cações em seu dispositivo de forma compreensível, permitindo-lhes fazer julgamentos

7.3 Comparativo entre os Trabalhos Relacionados 102

válidos sobre confiabilidade dessas aplicações.O TFT é composto por um framework para integrar em aplicações e capturar

eventos de segurança, e uma interface de usuário que apresenta informações ao usuário,com a qual ele pode decidir se irá confiar na ação ou não. Por exemplo, TFT forneceinformações como o tipo de segurança da rede em que o usuário está conectado, se a redeusa criptografia nos dados e o tipo de informação que uma aplicação deseja armazenar(como contatos da agenda, localização e fotografias).

No entanto, como esse trabalho se limitou em apenas fornecer um feedback dasegurança de aplicações na IoT para usuários decidirem se usarão ou não determinadaaplicação, essa solução não resolve o problema apresentado por essa dissertação nocapítulo 2. Com isso, essa solução não permite que as configurações de segurança sejamalteradas pelo usuário em tempo de execução; ela apenas expõe as características desegurança implementadas em aplicações para o usuário final.

7.3 Comparativo entre os Trabalhos Relacionados

Alguns trabalhos têm focado no problema da incapacidade do usuário de alterara segurança em tempo de execução em objetos [3, 60, 39]. No entanto, diferentemente dasolução apresentada por essa dissertação, as soluções apresentadas não foram pensadaspara envolver o usuário final no loop da alteração da segurança e não são voltadaspara dispositivos, com hardware limitado como pouca capacidade de processamento epouca eficiência energética como objetos na IoT. Além disso, os trabalhos relacionados,com exceção do trabalho de Schulz et al. [45], não permitem que o usuário tenha umavisão das características de segurança dos objetos (coisas) em seu ambiente para que ousuário avalie uma possível hostilidade. A solução apresentada nessa dissertação, usou aabordagem de modelos em tempo de execução para representar os objetos do ambientecom o intuito de prover uma visão geral das coisas que estão localizadas no ambientede IoT onde o usuário está inserido.

A Tabela 7.1 relaciona as principais características entre os trabalhos, sendo elas:

1. O trabalho propõe estratégias, padrões e princípios que podem ser reaproveitadosem trabalhos futuros;

2. O trabalho desenvolveu uma interface gráfica de usuário ou uma linguagem demodelagem para permitir alteração da segurança no sistema em tempo de execução;

3. O trabalho que foca na alteração de requisitos em tempo de execução para alterar asegurança do software correspondente;

4. O trabalho tem como foco envolver o usuário no loop de alteração da segurança emtempo de execução;

7.3 Comparativo entre os Trabalhos Relacionados 103

5. O trabalho implementou ou projetou um meio para prover uma visão geral dosobjetos no ambiente e suas características de segurança;

6. O trabalho foca na alteração do mecanismo de autenticação no sistema em tempode execução;

7. O trabalho foca na alteração do mecanismo de confidencialidade (encriptação) nosistema em tempo de execução;

8. O trabalho foca na alteração do mecanismo de controle de acesso no sistema emtempo de execução;

9. O trabalho adota modelos em tempo de execução como abordagem para permitiralterações da segurança em tempo de execução;

10. O trabalho adota programação orientada a aspectos (AOP) como abordagem parapermitir alterações da segurança em tempo de execução.

CaracterísticasTrabalhos

1 2 3 4 5 6 7 8 9 10

Yskout et al. [60] X X X X

Almorsy et al. [3] X X X X X X XMorin et al. [39] X X X

TFT [45] XNossa proposta X X X X X X

Tabela 7.1: Trabalhos Relacionados

De todos os trabalhos, apenas o TFT [45] tem como objetivo prover mecanismospara o usuário visualizar as características de segurança de elementos no ambiente, noentanto, esse trabalho limita-se apenas a isso. Nenhum dos trabalhos apresentou todas ascaracterísticas listadas encontradas que são encontradas no trabalho desta dissertação.

CAPÍTULO 8Conclusão

Diante de um ambiente dinâmico, ubíquo onde há comunicação entre diferentesdispositivos, como ocorre na IoT, o usuário pode passar a ter necessidades de segurançaque não são contempladas pelas aplicações em execução nos seus dispositivos. Os re-quisitos de segurança embutidos de forma estática nas aplicações não possuem garantiasde satisfação das necessidades do usuário, pois no ambiente dinâmico, como na IoT, ne-cessidades de segurança do usuário podem surgir em tempo de execução. A abordagemde models@runtime se mostra eficaz para flexibilizar os mecanismos de segurança emautenticação e confidencialidade de aplicações a ponto de permitir que eles sejam alte-rados em tempo de execução pelo usuário para atender suas necessidades que podemsurgir diante de um cenário imprevisível. O uso da abordagem de modelos em tempo deexecução permitiu descrever requisitos de segurança do usuário, em autenticação e confi-dencialidade, causalmente conectado com os mecanismos de segurança das aplicações emexecução nos dispositivos do usuário, ou seja, mudanças nos modelos que representam asnecessidades do usuário sobre as aplicações em seus dispositivos refletem em alteraçõesnos mecanismos de segurança dessas aplicações.

Diferentemente de middleware de propósito geral, que executam aplicações nodispositivo host, o middleware apresentado nesse trabalho é específico de domínio eexecuta modelos em tempo de execução para gerar configurações de segurança queserão utilizadas pelas aplicações. A solução é considerada como middleware porqueela executa requisitos em forma de modelos para apoiar a reconfiguração da segurançanas aplicações em execução no dispositivo. O middleware proposto separa os aspectos desegurança das aplicações em execução no dispositivo do usuário através de modelos emtempo de execução e cada aspecto de segurança passa a ser tratado como um programapelo middleware. Com isso, o middleware permite alterar os mecanismos de segurançadas aplicações em tempo de execução.

No desenvolvimento do middleware, implementamos os modelos em tempo deexecução no domínio da segurança através da utilização de DSL interna. Foi apresentadauma DSML textual, intitulada TRML, para modelagem das necessidades de segurançano usuário no domínio de segurança de dispositivos na IoT. A TRML, diferentemente

8.1 Trabalhos Futuros 105

das abordagens tradicionais que utilizam MOF, foi desenvolvida sobre a linguagem depropósito geral Java utilizando técnicas implementação de DSL interna. Este trabalhoadotou essa estratégia, de embutir uma DSML em uma linguagem de propósito geral nolugar de utilizar a especificação MOF com intuito de simplificar e minimizar o tempo paradesenvolver a TRML

Apesar dessa abordagem ter oferecido vantagem no desenvolvimento e menortempo da TRML, ela limitou o poder de expressividade que a TRML poderia ter. Aoembutir uma DSML em uma linguagem de propósito geral, a expressividade fica limitadaà estrutura sintática da linguagem hospedeira. Além disso, essa abordagem deixou aimplementação da TRML com alto acoplamento, o que inflexibiliza a evolução. Devido aessa decisão, muitos aspectos do código da implementação do middleware não poderãoser reaproveitados em uma manutenção evolutiva.

Para execução dos modelos descritos pela TRML, este trabalho propôs uma ar-quitetura de middleware com 4 (quatro) camadas, na qual o foco foi sobre a camada iden-tificada por Synthesis Engine (SE), responsável por sintetizar os requisitos (modelos) dousuário, através de um proposta de algoritmo, em comandos de segurança e enviá-los paraoutra camada (Control and Configuration–CC) realizar as alterações das configurações desegurança de aplicações em execução no dispositivo do usuário.

A camada de SE foi implementada como prova de conceito, a qual foi realizadauma avaliação para verificar se síntese de requisitos de segurança ocorreria em um tempode resposta que não inviabilizasse o uso da solução por parte do usuário, sendo queo tempo resposta se refere ao tempo gasto na síntese de requisitos de segurança emcomandos de segurança.

A avaliação de desempenho da camada SE apresentou resultados, dentro docenário avaliado, em que o tempo de resposta da camada SE não impactaria negativamenteno uso da solução por parte do usuário se comparado com o tempo de execução doprotocolo SSL/TLS que estabelece canais de comunicação seguros entre aplicações. Comisso, dado que o tempo de execução do protocolo SSL/TLS não impacta o funcionamentode sistemas a ponto de inviabilizar o seu uso por usuários, e dado que o tempo gastona execução da camada SE apresentou ser menor do que o tempo gasto na execução doprotocolo SSL/TLS, conclui-se que a camada SE realizou o seu propósito em um tempoque não impactaria o uso da solução por parte do usuário.

8.1 Trabalhos Futuros

As camadas User Interface (UI) e Thing Broker (TB) podem ser implementasem trabalhos futuros. A camada UI, pode ser projetada com dois componentes: o Mo-

deling Environment - ME que fornece uma interface amigável aos usuários para facilitar


a criação de modelos específicos de domínio e o Schema Transformation Environment

(STE) responsável pela validação e transformação dos modelos criados pelo usuário (naME e UI) em modelos textuais baseados em XML [59] para serem processados pela ca-mada Synthesis Engine (SE). As figuras 8.1 e 8.2 ilustram uma proposta de interfacegráfica. Na figura 8.1, a esquerda, são listados os dispositivos conectados na rede em queo dispositivo do usuário está conectado e a direita são listadas as aplicações do dispositivoe o nível de segurança exigido para se comunicar com o dispositivo do usuário.

Figura 8.1: Protótipo da Interface Gráfica Manter Requisitos

Na figura 8.2, a direita, é ilustrado a listagem requisitos modelados para umaselecionada na tela ilustrada na figura anterior.


Figura 8.2: Protótipo da Interface de Listagem de Dispositivos

Na camada TB, pode ser desenvolvida uma API para descoberta de dispositi-vos juntamente com suas informações a respeito de características de segurança comotipos de algoritmos de encriptação implementados para informar a camada Control and

Configuration (CC) a descoberta de dispositivos e prover uma visão geral de dispositivosque estão localizados no ambiente de IoT que permitirá ao usuário localizá-los e obterinformações sobre as características de segurança que esses dispositivos possuem.

Embora o middleware tenha sido projetado para colocar o usuário no loop dareconfiguração da segurança, há algumas situações em seriam mais convenientes se areconfiguração de segurança ocorresse sem a participação do usuário de forma automáticaatravés da identificação do contexto. Com isso, a implementação do middleware podeser estendida para permitir que reconfigurações de segurança sejam realizadas de formaautomática de acordo com o contexto em que o usuário se encontre, desde que nãosobrescreva ou entre em conflito com os requisitos de segurança do usuário caso existam.

Além disso, o metamodelo pode ser estendido para permitir a modelagem deoutros requisitos de segurança além de autenticação e confidencialidade, como requisitosde controle de acesso. Esta tarefa, por sua vez, requer a identificação dos aspectos queserão modelados como, por exemplo, requisitos de controle de acesso e a elaboração deabstrações apropriadas para descrever os novos aspectos na forma de modelos.

A camada Control and Configuration (CC) utilizou apenas o protocolo TLS

para atender os requisitos de segurança modelados. Desse modo, a camada CC pode serestendida para implementar outros protocolos de segurança que permitem reconfigurarmais características de segurança dos dispositivos como, por exemplo, controle de acesso.


A respeito da TRML, ela pode ser expandida para permitir especificar requisitosde segurança com mais detalhes, como por exemplo especificar no escopo do requisito aidentificação ou uma característica particular de um dispositivo. Além do mais, estamosinteressados em implementar uma versão gráfica da TRML utilizando MOF para oferecermelhor experiência ao usuário durante a modelagem de requisitos de segurança.

Referências Bibliográficas

[1] Device analyzer. http://deviceanalyzer.cl.cam.ac.uk/keyValuePairs.

htm. Accessed: 2015-08-18.

[2] ALLISON, M.; MORRIS, K.; YANG, Z.; CLARKE, P. J.; COSTA, F. M.; OTHERS.

Towards reliable smart microgrid behavior using runtime model synthesis.

In: High-Assurance Systems Engineering (HASE), 2012 IEEE 14th International

Symposium on, p. 185–192. IEEE, 2012.

[3] ALMORSY, M.; GRUNDY, J.; IBRAHIM, A. S. Mdse@r: Model-driven security

engineering at runtime. In: Proceedings of the 4th International Conference on

Cyberspace Safety and Security, CSS’12, p. 279–295, Berlin, Heidelberg, 2012.

Springer-Verlag.

[4] ARGYROUDIS, P. G.; VERMA, R.; TEWARI, H.; MAHONY, D. O. Performance analy-

sis of cryptographic protocols on handheld devices. In: Network Computing and

Applications, 2004.(NCA 2004). Proceedings. Third IEEE International Symposium

on, p. 169–174. IEEE, 2004.

[5] ATZORI, L.; IERA, A.; MORABITO, G. The internet of things: A survey. Computer

networks, 54(15):2787–2805, 2010.

[6] BABAR, S.; MAHALLE, P.; STANGO, A.; PRASAD, N.; PRASAD, R. Proposed security

model and threat taxonomy for the internet of things (iot). In: Recent Trends in

Network Security and Applications, p. 420–429. Springer, 2010.

[7] BENCOMO, N.; WHITTLE, J.; SAWYER, P.; FINKELSTEIN, A.; LETIER, E. Require-

ments reflection: requirements as runtime entities. In: Proceedings of the 32nd

ACM/IEEE International Conference on Software Engineering-Volume 2, p. 199–202.

ACM, 2010.

[8] BICK, M.; KUMMER, T.-F. Ambient intelligence and ubiquitous computing.

In: Handbook on Information Technologies for Education and Training, p. 79–100.

Springer, 2008.

http://deviceanalyzer.cl.cam.ac.uk/keyValuePairs.htm

http://deviceanalyzer.cl.cam.ac.uk/keyValuePairs.htm


[9] BLAIR, G.; BENCOMO, N.; FRANCE, R. B. [email protected]. Computer, 42(10):22–

27, 2009.

[10] BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. Elsevier Brasil,

2006.

[11] CHEN, K.; SZTIPANOVITS, J.; NEEMA, S. Toward a semantic anchoring infras-

tructure for domain-specific modeling languages. In: Proceedings of the 5th ACM

international conference on Embedded software, p. 35–43. ACM, 2005.

[12] CLARK, T.; SAMMUT, P.; WILLANS, J. Applied metamodelling: a foundation for

language driven development. arXiv preprint arXiv:1505.00149, 2015.

[13] COULOURIS, G. F.; DOLLIMORE, J.; KINDBERG, T. Distributed systems: concepts

and design. Pearson Education, 2005.

[14] DA, A. G. L. P. A.; GONÇALVES, S. Uma análise dos mecanismos de segu-

rança de redes IEEE 802.11: WEP, WPA, WPA2 e IEEE 802.11.

[15] DENG, Y.; MASOUD SADJADI, S.; CLARKE, P. J.; HRISTIDIS, V.; RANGASWAMI,

R.; WANG, Y. Cvm–a communication virtual machine. Journal of Systems and

Software, 81(10):1640–1662, 2008.

[16] DIERKS, T. The transport layer security (TLS) protocol version 1.2. 2008.

[17] FOWLER, M. Domain-specific languages. Pearson Education, 2010.

[18] FRANCE, R.; RUMPE, B. Domain specific modeling. Software and Systems

Modeling, 4(1):1–3, 2005.

[19] FRANCE, R.; RUMPE, B. Model-driven development of complex software: A

research roadmap. In: 2007 Future of Software Engineering, p. 37–54. IEEE

Computer Society, 2007.

[20] FREIER, A. The SSL protocol version 3.0. http://wp. netscape.

com/eng/ssl3/draft302. txt, 1996.

[21] GARSHOL, L. M. Bnf and EBNF: What are they and how do they work. acedida

pela última vez em, 16, 2003.

[22] GEORGAS, J. C.; VAN DER HOEK, A.; TAYLOR, R. N. Using architectural models

to manage and visualize runtime adaptation. Computer, (10):52–60, 2009.

[23] GJERLUFSEN, T.; INGSTRUP, M.; OLSEN, J. W. Mirrors of meaning: Supporting

inspectable runtime models. Computer, 42(10):61–68, 2009.


[24] GREENFIELD, J.; SHORT, K.; COOK, S.; KENT, S.; CRUPI, J. Software factories:

assembling applications with patterns, models, frameworks, and tools. Wiley

Pub., 2004.

[25] GROUP, O. M. Object management group [web site]. Disponível por WWW em:

http://www. omg.org/), Acessado em setembro de 2015.

[26] GROUP, O. M. Unified Modeling Language (UML), Acessado em Setembro de

2015.

[27] GUINARD, D.; TRIFA, V. Towards the web of things: Web mashups for embedded

devices. In: Workshop on Mashups, Enterprise Mashups and Lightweight Compo-

sition on the Web (MEM 2009), in proceedings of WWW (International World Wide

Web Conferences), Madrid, Spain, p. 15, 2009.

[28] GUINARD, D.; TRIFA, V.; MATTERN, F.; WILDE, E. From the internet of things

to the web of things: Resource-oriented architecture and best practices. In:

Architecting the Internet of Things, p. 97–129. Springer, 2011.

[29] HANUMANTHAPPA, P.; SINGH, S. Privacy preserving and ownership authentica-

tion in ubiquitous computing devices using secure three way authentication.

In: Innovations in Information Technology (IIT), 2012 International Conference on, p.

107–112. IEEE, 2012.

[30] INVERARDI, P.; MORI, M. Requirements models at run-time to support consistent

system evolutions. In: Requirements@ Run. Time (RE@ RunTime), 2011 2nd

International Workshop on, p. 1–8. IEEE, 2011.

[31] IZQUIERDO, J. L. C.; CABOT, J. Enabling the collaborative definition of DSMLs.

In: Advanced Information Systems Engineering, p. 272–287. Springer, 2013.

[32] KLEPPE, A. Software language engineering: creating domain-specific langua-

ges using metamodels. Pearson Education, 2008.

[33] LASHKARI, A. H.; DANESH, M. M. S.; SAMADI, B. A survey on wireless security

protocols (wep, wpa and wpa2/802.11 i). In: Computer Science and Information

Technology, 2009. ICCSIT 2009. 2nd IEEE International Conference on, p. 48–52.

IEEE, 2009.

[34] LIN, J.; MADNANI, N.; DORR, B. J. Putting the user in the loop: Interactive maxi-

mal marginal relevance for query-focused summarization. In: Human Language

Technologies: The 2010 Annual Conference of the North American Chapter of the As-

sociation for Computational Linguistics, HLT ’10, p. 305–308, Stroudsburg, PA, USA,

2010. Association for Computational Linguistics.


[35] MAHALLE, P. N.; ANGGOROJATI, B.; PRASAD, N. R.; PRASAD, R. Identity establish-

ment and capability based access control (iecac) scheme for internet of things.

In: Wireless Personal Multimedia Communications (WPMC), 2012 15th International

Symposium on, p. 187–191. IEEE, 2012.

[36] MERNIK, M.; HEERING, J.; SLOANE, A. M. When and how to develop domain-

specific languages. ACM computing surveys (CSUR), 37(4):316–344, 2005.

[37] Meta object facility (MOF) core specification, 2011. Version 2.4.1.

[38] MIORANDI, D.; SICARI, S.; DE PELLEGRINI, F.; CHLAMTAC, I. Internet of things:

Vision, applications and research challenges. Ad Hoc Networks, 10(7):1497–

1516, 2012.

[39] MORIN, B.; MOUELHI, T.; FLEUREY, F.; LE TRAON, Y.; BARAIS, O.; JÉZÉQUEL, J.-

M. Security-driven model-based dynamic adaptation. In: Proceedings of the

IEEE/ACM international conference on Automated software engineering, p. 205–214.

ACM, 2010.

[40] MOSINCAT, A.; BINDER, W.; JAZAYERI, M. Runtime adaptability through auto-

mated model evolution. In: Enterprise Distributed Object Computing Conference

(EDOC), 2010 14th IEEE International, p. 217–226. IEEE, 2010.

[41] PEÑA-LÓPEZ, I.; OTHERS. ITU internet report 2005: The internet of things. 2005.

[42] ROMAN, R.; NAJERA, P.; LOPEZ, J. Securing the internet of things. Computer,

44(9):51–58, Sept 2011.

[43] ROMAN, R.; NAJERA, P.; LOPEZ, J. Securing the internet of things. Computer,

44(9):51–58, 2011.

[44] SAKAMURA, K. Challenges in the age of ubiquitous computing: a case study of

t-engine, an open development platform for embedded systems. In: Proceedings

of the 28th international conference on Software engineering, p. 713–720. ACM,

2006.

[45] SCHULZ, T.; TJØSTHEIM, I. Increasing trust perceptions in the internet of things.

In: Human Aspects of Information Security, Privacy, and Trust, p. 167–175. Springer,

2013.

[46] SEIDEWITZ, E. What models mean. IEEE software, 20(5):26–32, 2003.

[47] SOUSA, G.; COSTA, F. M.; CLARKE, P. J.; ALLEN, A. A. Model-driven development

of DSML execution engines. In: Proceedings of the 7th Workshop on Models@ run.

time, p. 10–15. ACM, 2012.


[48] SPRINKLE, J.; KARSAI, G. A domain-specific visual language for domain model

evolution. Journal of Visual Languages & Computing, 15(3):291–307, 2004.

[49] STAHL, T.; VOELTER, M.; CZARNECKI, K. Model-driven software development:

technology, engineering, management. John Wiley & Sons, 2006.

[50] STANKOVIC, J.; OTHERS. Research directions for the internet of things. Internet

of Things Journal, IEEE, 1(1):3–9, 2014.

[51] STEINBERG, D.; BUDINSKY, F.; MERKS, E.; PATERNOSTRO, M. EMF: eclipse

modeling framework. Pearson Education, 2008.

[52] TATE, B. A.; HIBBS, C. Ruby on Rails: Up and Running: Up and Running. "O’Reilly

Media, Inc.", 2006.

[53] TOMA, I.; SIMPERL, E.; HENCH, G. A joint roadmap for semantic technolo-

gies and the internet of things. In: Proceedings of the Third STI Roadmapping

Workshop, Crete, Greece, volume 1, 2009.

[54] VAN DEURSEN, A.; KLINT, P.; VISSER, J. Domain-specific languages: An annota-

ted bibliography. Sigplan Notices, 35(6):26–36, 2000.

[55] VASSEUR, J. IP for smart objects alliance. Internet Protocol for Smart Objects

(IPSO) Alliance White paper, (2), 2008.

[56] VIANA, W.; BRAGA, R.; ANDRADE, R.; OTHERS. Framesec: a framework for the

application development with end-to-end security provision in the mobile com-

puting environment. In: Telecommunications, 2005. advanced industrial confe-

rence on telecommunications/service assurance with partial and intermittent resour-

ces conference/e-learning on telecommunications workshop. aict/sapir/elete 2005.

proceedings, p. 72–77. IEEE, 2005.

[57] WAGNER, D. T.; RICE, A.; BERESFORD, A. R. Device analyzer: Large-scale mobile

data collection. ACM SIGMETRICS Performance Evaluation Review, 41(4):53–56,

2014.

[58] WANGHAM, M.; DOMENECH, M.; DE MELLO, E. Infraestrutura de autenticaçao e

de autorizaçao para internet das coisas. p. 156–205, 2013.

[59] WU, Y.; ALLEN, A. A.; HERNANDEZ, F.; FRANCE, R.; CLARKE, P. J. A domain-

specific modeling approach to realizing user-centric communication. Software:

Practice and Experience, 42(3):357–390, 2012.


[60] YSKOUT, K.; BEN DAVID, O.-N.; SCANDARIATO, R.; BAUDRY, B. Requirements-

driven runtime reconfiguration for security. In: Moschitti, A.; Scandariato, R.,

editors, Eternal Systems, volume 255 de Communications in Computer and In-

formation Science, p. 25–33. Springer Berlin Heidelberg, 2012.

Síntese de Requisitos de Segurança para Internet das Coisas ...

Documents

Transcript of Síntese de Requisitos de Segurança para Internet das Coisas ...