Uma Infraestrutura de autenticação e de autorização para a ...siaibib01.univali.br/pdf/Marlon...

MARLON CORDEIRO DOMENECH

UMA INFRAESTRUTURA DE AUTENTICACAO E DEAUTORIZACAO PARA A WEB DAS COISAS

Itajaı (SC), Fevereiro de 2015

UNIVERSIDADE DO VALE DO ITAJAI

CURSO DE MESTRADO ACADEMICO EM

COMPUTACAO APLICADA


por

Marlon Cordeiro Domenech

Dissertacao apresentada como requisito parcial aobtencao do grau de Mestre em Computacao Apli-cada.Orientador: Michelle Silva Wangham, Dra.

Itajaı (SC), Fevereiro de 2015


Uma Infraestrutura de autenticação e de autorização para a Web dasCoisas

Dissertação apresentada como requisito parcial àobtenção do grau de Mestre em Computação Apli-cada.

Trabalho aprovado. Itajaí (SC), 27 de Fevereiro de 2015:

Profa. Michelle Silva Wangham, Dra.(UNIVALI)Orientadora

Prof. Cesar Albenes Zeferino, Dr.(UNIVALI)

Membro

Prof. Eros Comunello, Dr. rer. nat.(UNIVALI)

Membro

Prof. Emerson Ribeiro de Mello, Dr. (IFSC)Membro

Itajaí (SC)

Fevereiro de 2015

AGRADECIMENTOS

Agradeço aos meus pais, Inez e Gerson, por terem me apoiado durante toda a minha vida e deuma maneira ainda mais notável durante a realização deste trabalho. Tenham a certeza de que meuamor por vocês só aumentou durante este período.

Do mesmo modo, agradeço ao meu irmão, Matheus, por ter feito com que eu recordasse,diversas vezes, que a família é muito importante, muito mais do que este trabalho. Obrigado pela forçaque você teve e que transmitiu para mim nas mais diversas oportunidades.

À minha noiva e futura esposa, sempre companheira, Suelen, agradeço pela parceria, amizadee amor incondicionais durante todo esse tempo que passamos um pouco mais distantes um do outro.Sem você, os dias teriam sido sempre cinzentos e este trabalho teria sido muito mais árduo. Obrigadopelo apoio.

Aos meus sogros, Eldo e Sirlei, agradeço por tudo que fizeram por mim neste período. Tenhamcerteza de que serei eternamente grato pelo apoio que me deram nesta empreitada.

À minha orientadora e amiga Michelle, agradeço por ter ajudado a formar meu caráter comopesquisador e como ser humano. Sem sua colaboração, este resultado, e muitos outros, não teriam sidoalcançados. Tenha certeza que serei sempre grato por você ter superado as expectativas que eu tinhapara um orientador. Sempre terei você em conta.

Ao meu amigo Eros, agradeço por ter me proporcionado uma das experiências mais desafiadorasda minha vida ao apresentar a oportunidade de cursar o Mestrado. Obrigado também por ter ajudado ame formar como pesquisador e como pessoa.

Aos meus amigos de laboratório, Marcelo, Leonardo e Maykon, agradeço primeiro pela amizadee depois pelas produtivas conversas e intercâmbio de ideias. A colaboração técnico-científica de vocêsfoi essencial para que os resultados deste trabalho fossem alcançados. Minha consideração por vocês éindescritível.

Também agradeço aos meus amigos Paulo e Gabriel, pela colaboração que tiveram nestetrabalho. O trabalho de vocês colaborou muito para estes resultados.

Por fim, serei sempre grato a Carlos Bernardo González Pecotche. Seus ensinamentos foramimprescindíveis para que este trabalho viesse a ser concluído e para que a vida não se limitasse apenasa este labor.



Fevereiro / 2015

Orientadora: Michelle Silva Wangham, Dra.

Área de Concentração: Computação Aplicada

Linha de Pesquisa: Sistemas Embarcados e Distribuídos

Palavras-chave: Internet das Coisas, Autenticação, Autorização.

Número de páginas: 164

RESUMO

A Internet das Coisas consiste na presença de uma diversidade de coisas (objetos) que inte-ragem e cooperam entre si a fim de atingir um objetivo comum, por exemplo, o compartilhamentode informações. Diversas características diferenciam a Internet das Coisas dos demais ambientescomputacionais, como a grande heterogeneidade de tecnologias e as restrições de recursos computaci-onais. Uma abordagem para tratar desta heterogeneidade é utilizar a Web como plataforma, conceitoconhecido como Web das Coisas. A característica distribuída e a heterogeneidade da Web das Coisas(WoT) levam à necessidade de autenticação em ambientes colaborativos, compostos por diferentesdomínios administrativos de segurança, bem como garantir que apenas entidades autorizadas acessemos recursos protegidos. O objetivo deste trabalho é prover autenticação e autorização de usuáriose de dispositivos na Web das Coisas diante de domínios de segurança diferentes, por meio de umainfraestrutura de autenticação e de autorização, chamada AAI4WoT. A AAI4WoT é capaz de prover aautenticação única de dispositivos e de usuários por meio de diferentes mecanismos de autenticação,além de permitir o uso de diferentes modelos de controle de acesso. A AAI4WoT foi projetada e éadequada para aplicações que envolvem a comunicação M2M (Machine to Machine). O trabalho en-volveu (1) a definição e implementação de uma infraestrutura de autenticação e de autorização baseadanos padrões SAML e XACML (AAI4WoT) e (2) a avaliação dos impactos do uso da AAI4WoT emuma aplicação de Web das Coisas para controle e monitoramento remoto de máquinas industriaisinteligentes. As métricas utilizadas na avaliação foram o consumo de potência elétrica, espaço dememória RAM e flash, uso de CPU, tempo de processamento, tamanho das mensagens e vazão da rede.Os resultados obtidos mostram que (1) é possível ter a autenticação única de dispositivos e de usuáriosem uma mesma infraestrutura diante de diferentes mecanismos de autenticação; (2) é possível proverflexibilidade de modelo de controle de acesso para as aplicações de WoT; e (3) que usar a AAI4WoT

demanda o uso de mais recursos computacionais dos dispositivos.

AN AUTHENTICATION AND AUTHORIZATIONINFRASTRUCTURE FOR THE WEB OF THINGS


February / 2015

Advisor: Michelle Silva Wangham, Dra.

Area of Concentration: Applied Computer Science

Research Line: Embedded and Distributed Systems

Keywords: Internet of Things, Authentication, Authorization.

Number of pages: 164

ABSTRACT

The basic idea of the Internet of Things consists in the presence of a diversity of things (objects)that interact and cooperate to achieve a common goal, for example, sharing of information. The Internetof Things has many characteristics that differentiate it from other computational environments, such asthe great heterogeneity of technologies and restriction of computational resources. An approach to theheterogeneity of the Internet of Things is to use the Web as a platform, a concept known as Web ofThings. Distributed characteristic and heterogeneity of the Web of Things (WoT) leads to the needof authentication in collaborative environments, which are composed by differents security domains,and also to guarantee that only authorized entities can access protected resources. The objective ofthis work is to provide authentication and authorization of users and devices on the Web of Thingsfacing different security domains, through an authentication and authorization infrastructure, calledAAI4WoT. AAI4WoT enables device and user Single Sign-On (SSO) through different authenticationmechanisms, as well as the use of different access control models. AAI4WoT was designed and issuitable for applications involving Machine-to-Machine (M2M) communication. The work involved(1) definition and implementation of an authentication and authorization infrastructure based on SAMLand XACML standards (AAI4WoT), and (2) evaluation of impacts of using AAI4WoT on an Web ofThings application for remote monitoring and control of smart industrial machines. Metrics used wereelectric power consumption, RAM and flash usage, CPU usage, processing time, message size andnetwork throughput. Results show that (1) SSO for users and devices in the same infrastructure facingdifferent authentication mechanisms can be achieved; (2) flexibility of access control model can beprovided for WoT applications; and (3) using AAI4WoT requires more computational resources ofdevices.

LISTA DE ILUSTRACOES

Figura 1. Controle de Acesso ................................................................................... 45Figura 2. Modelo de Fluxo de dados do XACML ......................................................... 51Figura 3. Arquitetura do Hydra Identity Manager ......................................................... 56Figura 4. Arquitetura da IoT e passo-a-passo do protocolo de autenticação ........................ 58Figura 5. Arquitetura de autorização proposta em Seitz, Selander e Gehrmann (2013) .......... 61Figura 6. Cenário do Problema de Pesquisa ................................................................. 68Figura 7. Visão Geral da AAI4WoT - Cenário M2M ..................................................... 70Figura 8. Componentes da AAI4WoT ........................................................................ 72Figura 9. Etapa de Registro do Dispositivo SP ............................................................. 76Figura 10. AAI4WoT - Modo de Operação SP Restrito ................................................... 78Figura 11. Fluxo de mensagens de autorização no modo de operação SP Restrito.................. 80Figura 12. AAI4WoT - Modo de Operação SP Sem Restrições ......................................... 81Figura 13. Etapas e trocas de mensagens do mecanismo de autenticação de dispositivos ......... 83Figura 14. Telas de cadastro da aplicação de registro do IdP ............................................. 90Figura 15. Árvore do diretório de identidades do IdP ...................................................... 91Figura 16. Fluxo de mensagens do cenário de autenticação de dispositivos - parte 1 .............. 92Figura 17. Fluxo de mensagens do cenário de autenticação de dispositivos - parte 2 .............. 93Figura 18. Fluxo de mensagens de autenticação única do cenário de autenticação de dispositivos 97Figura 19. Aplicação de WoT para monitoramento e controle remoto de máquinas industriais . 99Figura 20. Simulador do Sistema SCADA - SIMSCADA................................................. 100Figura 21. Aplicação Cliente Desktop ......................................................................... 101Figura 22. Tela da aplicação Cliente Desktop integrada à AAI4WoT .................................. 103Figura 23. Experimento de Vazão da Rede - BeagleBone Black atua como SP...................... 128Figura 24. Experimento de Vazão da Rede - Aplicação na Nuvem atua como SP................... 130Figura 25. XSD para o contexto de autenticação utilizado nos experimentos - Parte 1 ............ 154Figura 26. XSD para o contexto de autenticação utilizado nos experimentos - Parte 2 ............ 155Figura 27. XSD para o contexto de autenticação utilizado nos experimentos - Parte 3 ............ 157Figura 28. XSD para o contexto de autenticação utilizado nos experimentos - Parte 4 ............ 158Figura 29. Diagrama de Sequência do Cliente Ativo SAML quando o cliente não possui uma

asserção SAML........................................................................................ 163Figura 30. Diagrama de Sequência da tomada de decisão de autorização ............................. 164

LISTA DE TABELAS

Tabela 1. Comparação dos Trabalhos Relacionados....................................................... 63Tabela 2. Footprint - Dados do Cliente ....................................................................... 108Tabela 3. Footprint - Dados do SP............................................................................. 109Tabela 4. Footprint - Dados de Consumo de Potência do Cliente...................................... 110Tabela 5. Footprint - Dados de Consumo de Potência do SP ........................................... 111Tabela 6. Montagem da Requisição de Autenticação SAML - Dados do Cliente com a AAI... 112Tabela 7. Tempo de processamento da Montagem da Requisição de Autenticação SAML

sem carregamento do OpenSAML - com a AAI .............................................. 113Tabela 8. Solicitação de Autenticação Sem Autenticação Única - com a AAI...................... 114Tabela 9. Solicitação de Autenticação Com Autenticação Única - com a AAI ..................... 114Tabela 10. Solicitação de Autenticação com e sem Autenticação Única - Tamanho das Mensa-

gens - com a AAI ..................................................................................... 115Tabela 11. Solicitação de Autenticação com e sem Autenticação Única - Tempo de Processa-

mento - com a AAI ................................................................................... 116Tabela 12. Participação dos subprocessos no processo de obtenção de uma asserção SAML -

com a AAI .............................................................................................. 117Tabela 13. Processo de Autenticação Completo com e sem Autenticação Única - com a AAI... 117Tabela 14. Processo de Autenticação Completo com e sem Autenticação Única - Uso de CPU

- com a AAI............................................................................................. 118Tabela 15. Processo de Autenticação Completo com e sem Autenticação Única - Consumo de

Potência - com a AAI ................................................................................ 119Tabela 16. Solicitação ao SP com e sem a AAI4WOT - Dados do Cliente - Memória RAM,

Flash/Disco e Tempo de Processamento......................................................... 120Tabela 17. Solicitação ao SP com e sem a AAI4WOT - Dados do Cliente - Tempo de Proces-

samento corrigido ..................................................................................... 121Tabela 18. Solicitação ao SP com e sem a AAI4WOT - Dados do Cliente - Tamanho das

Mensagens .............................................................................................. 121Tabela 19. Solicitação ao SP com e sem a AAI4WOT - Dados do Cliente - Consumo de Potência122Tabela 20. Solicitação ao SP com e sem a AAI4WOT - Dados do Cliente - Uso de CPU......... 123Tabela 21. Solicitação ao SP com e sem a AAI4WOT - Dados do SP ................................. 124Tabela 22. Solicitação ao SP com a AAI4WOT - Dados do SP - Tamanho das Mensagens ...... 124Tabela 23. Solicitação ao SP com e sem a AAI4WOT - Dados do SP - Uso de CPU .............. 125Tabela 24. Solicitação ao SP com e sem a AAI4WOT - Cenário Cliente Embarcado - Dados

do SP ..................................................................................................... 125Tabela 25. Solicitação ao SP com a AAI4WOT - Dados do PDP ....................................... 126Tabela 26. Processo Completo com e sem a AAI4WOT - com e sem Autenticação Única -

Dados do Cliente ...................................................................................... 127Tabela 27. Resultados da Revisão Sistemática da Literatura.............................................. 148

LISTA DE ABREVIATURAS E SIGLAS

6LoWPAN IPv6 over Low Power Wireless Personal Area Networks

ABAC Attribute Based Access Control

AC Autoridade Certificadora

ACL Access Control List

ACM Access Control Mechanism

AES Advanced Encryption Standard

API Application Programming Interface

AS Authorized Server

BPEL Business Process Execution Language

DAC Discretionary Access Control

DoS Denial of Service

DTLS Datagram Transport Layer Security

EAP Extensible Authentication Protocol

ECC Elliptic Curve Cryptography

ECCDH ECC Diffie-Hellman

ECP Enhanced Client or Proxy

EnHANTs Energy-Harvesting Active Networked Tags

GID Gestão de Identidades Digitais

HTML Hypertext Markup Language

HTTP Hypertext Transfer Protocol

IAA Infraestrutura de Autenticação e Autorização

IdM Identity Management

IdP Identity Provider

IoT Internet of Things

IP Internet Protocol

IPv4 Internet Protocol version 4

IPv6 Internet Protocol version 6

JSON JavaScript Object Notation

KDC Key Distribution Center

LDAP Lightweight Directory Access Protocol

M2M Machine to Machine

MAC Mandatory Access Control

MITM Man-In-The-Middle

NFC Near-Field Communication

PAP Policy Administration Point

PBAC Policy-Based Access Control

PDP Policy Decision Point

PEP Policy Enforcement Point

PIP Policy Information Point

RAM Random Access Memory

RBAC Role Based Access Control

REST REpresentational State Transfer

RFID Radio-Frequency IDentification

ROA Resource Oriented Architecture

ROM Read-only Memory

RSN RFID Sensor Network

RSSF Redes de Sensores Sem Fio

SGML Standard Generalized Markup Language

SAML Security Assertion Markup Language

SP Service Provider

SSO Single Sign-On

TLS Transport Layer Security

TPM Trusted Platform Module

UDDI Universal Description, Discovery and Integration

URI Uniform Resource Identifier

URL Uniform Resource Locator

WoT Web of Things

WABAC Workflow-oriented Attributed Based Access Control

WSAN Wireless Sensor and Actuator Network

WSDL Web Services Description Language

WSN Wireless Sensor Network

XML eXtensible Markup Language

XACML eXtensible Access Control Markup Language

SUMARIO

1 INTRODUÇÃO ................................................................................151.1 Problema de Pesquisa ...........................................................................171.1.1 Solução Proposta ....................................................................................... 201.1.2 Delimitação de Escopo................................................................................ 221.1.3 Justificativa .............................................................................................. 221.2 Objetivos............................................................................................... 241.2.1 Objetivo Geral .......................................................................................... 241.2.2 Objetivos Específicos .................................................................................. 241.3 Metodologia .......................................................................................... 251.3.1 Metodologia da Pesquisa ............................................................................ 251.3.2 Procedimentos Metodológicos ..................................................................... 261.4 Estrutura da Dissertação ......................................................................27

2 FUNDAMENTAÇÃO TEÓRICA ................................................292.1 Internet das Coisas ............................................................................... 292.1.1 Web das Coisas ......................................................................................... 312.2 Segurança na Internet das Coisas ........................................................ 342.2.1 Requisitos de Segurança ............................................................................. 352.2.2 Ameaças e Ataques .................................................................................... 372.2.3 Gestão de Identidades Digitais na Internet das Coisas ..................................... 392.2.4 Especificações de Segurança para XML e Serviços Web .................................. 472.3 Considerações....................................................................................... 53

3 TRABALHOS RELACIONADOS ..............................................553.1 Akram e Hoffmann (2008c) ................................................................. 553.2 Alam, Chowdhury e Noll (2011) .......................................................... 563.3 Conzon et al. (2012) ...............................................................................573.4 Liu, Xiao e Chen (2012) ....................................................................... 583.5 Gardel et al. (2013) ............................................................................... 593.6 Seitz, Selander e Gehrmann (2013) ..................................................... 603.7 Comparação dos Trabalhos Relacionados ........................................... 623.8 Considerações....................................................................................... 65

4 INFRAESTRUTURA DE AUTENTICAÇÃO E DE AU-TORIZAÇÃO PARA A WEB DAS COISAS - AAI4WOT ....66

4.1 Cenário Envolvido e Premissas .............................................................674.2 Visão Geral da AAI4WoT .................................................................... 694.3 Componentes e Funcionalidades da AAI4WoT ....................................714.4 Etapa de Registros e de Estabelecimento de Relações de Confiança .. 73

4.5 Modos de Operação da AAI4WoT ........................................................774.5.1 Modo de Operação SP Restrito .................................................................... 774.5.2 Modo de Operação SP Sem Restrições .......................................................... 804.6 Cliente Ativo SAML ............................................................................. 804.7 Uso de Mecanismos de Autenticação da IoT com o SAML ................. 824.8 Modelo de Ameaças ............................................................................. 844.9 Desenvolvimento....................................................................................874.9.1 Ferramentas Tecnológicas Utilizadas ............................................................ 874.9.2 Implementação do Protótipo da AAI4WoT.................................................... 894.9.3 Aplicação de Monitoramento e Controle de Máquinas Industriais .................... 984.9.4 Integração da Infraestrutura de Autenticação e de Autorização para a Web

das Coisas............................................................................................... 1024.10 Considerações do Capítulo .................................................................104

5 RESULTADOS E AVALIAÇÃO .................................................1065.1 Experimentos ......................................................................................1065.2 Resultados ...........................................................................................1075.2.1 Experimento de Footprint ......................................................................... 1075.2.2 Experimento de Solicitação de Autenticação .................................................1115.2.3 Experimento de Solicitação de Serviço ao SP ............................................... 1205.2.4 Experimento do Processo Completo ........................................................... 1265.2.5 Experimento de Vazão da Rede ................................................................. 1285.3 Comparação com os Trabalhos Relacionados ....................................130

6 CONCLUSÃO ................................................................................1326.1 Contribuição da Dissertação ...............................................................1346.2 Trabalhos Futuros ...............................................................................134

Referências ............................................................................................136APÊNDICE A – PROTOCOLO DE BUSCA E RESULTADOS

DA REVISÃO SISTEMÁTICA DA LITERA-TURA .......................................................................144

APÊNDICE B – POLÍTICA DE CONTROLE DE ACESSOUTILIZADA NOS EXPERIMENTOS ............149

APÊNDICE C – AUTENTICATION CONTEXT CLASS PARAO MECANISMO DE AUTENTICAÇÃO UTI-LIZADO NOS EXPERIMENTOS ...................154

APÊNDICE D – MODELAGEM DO PROTÓTIPO ...................159

15

1 INTRODUÇÃO

Em 2010, havia aproximadamente um bilhão e meio de computadores pessoais e mais de um

bilhão de celulares com acesso à Internet. Para 2020, é esperado que algo entre cinquenta e cem bilhões

de dispositivos estarão conectados à Internet (CERP-IOT, 2010). O próximo salto no crescimento da

Internet será a ampla integração dos objetos físicos do dia a dia (“coisas”), conectados em redes (ITU,

2005; COUNCIL, 2008). O paradigma da Internet das Coisas (Internet of Things – IoT) abrange uma

infraestrutura de hardware, software e serviços que conectam objetos físicos à rede de computadores

(COMMUNITIES, 2008). Babar et al. (2011) afirmam que nesse cenário estão coisas como roupas,

mobília, carros, smartcards, dispositivos médicos e máquinas industriais.

Segundo Atzori, Iera e Morabito (2010), a ideia básica da IoT consiste na presença de uma

diversidade de coisas (objetos) que interagem e cooperam entre si afim de atingir um objetivo comum

(p.e. o compartilhamento de informações), utilizando métodos de endereçamento único e protocolos

de comunicação padronizados. O paradigma de IoT integra uma grande variedade de conceitos e áreas,

tais como: eletrônica, automação, redes de comunicação, biotecnologia, mecânica e tecnologia dos

materiais (XIANG; LI, 2012).

Os avanços e a convergência das tecnologias de sistemas microeletromecânicos, comunicação

sem fio e eletrônica digital resultaram no desenvolvimento de dispositivos em miniatura capazes de

sensoriar, computar e se comunicar via rede sem fio a curtas distâncias. Deste cenário, deriva o conceito

de ambientes inteligentes (smart environments). A integração entre sensores-atuadores-Internet forma

a base tecnológica para o conceito de ambientes inteligentes, nos quais a informação gerada pode ser

compartilhada entre diversas plataformas e aplicações, permitindo o controle de determinadas coisas

(dispositivos) (GUBBI et al., 2013).

A IoT apresenta diversas características que a diferenciam dos demais ambientes computa-

cionais. Conforme Mahalle et al. (2012), Atzori, Iera e Morabito (2010) e Hummen et al. (2013),

os principais fatores que tornam desafiadora a integração dos objetos (coisas) com a Internet são as

restrições de recursos computacionais, conectividade, fontes de energia, segurança, fatores geográficos

e custo de instalação e operação.

Em função destas restrições, alguns dispositivos não suportam a conectividade direta com a

Internet, via protocolo IP. Neste caso, é possível utilizar um dispositivo intermediário entre a Internet e

16

o objeto, chamado de Smart Gateway. Esse dispositivo fornece uma interface de comunicação dos

objetos com sistemas finais na Internet e vice-versa. Isso permite que tais sistemas, que podem ser

outros objetos, se comuniquem com os objetos através desse Smart Gateway, sendo que este recebe

as mensagens vindas da Internet e repassa ao objeto por meio de sua API (Application Programming

Interface) de comunicação específica e vice-versa (TRIFA et al., 2009; MAHALLE et al., 2010).

Segundo Zeng, Guo e Cheng (2011), há uma tendência nas pesquisas atuais em tratar a IoT como

Web das Coisas (Web of Things – WoT), na qual os padrões abertos da Web são empregados para prover

o compartilhamento de informação e a interoperabilidade entre dispositivos. A interoperabilidade é

particularmente essencial para concepção de sistemas com dispositivos heterogêneos produzidos por

diferentes fabricantes. Na WoT, a integração dos dispositivos ocorre no nível de aplicação, acima da

conectividade de rede (ZENG; GUO; CHENG, 2011; GUINARD et al., 2011).

Uma possível abordagem para implementar o conceito de WoT é o estilo arquitetural REST

(REpresentational State Transfer). Esse estilo arquitetural pode ser empregado para desenvolver

sistemas que seguem uma arquitetura orientada a recursos (Resource Oriented Architecture – ROA).

O REST define um conjunto de princípios que, ao serem adotados, dão origem a sistemas RESTful

(GUINARD; TRIFA, 2009).

As questões mais desafiadoras na IoT são os aspectos de segurança, que requerem abordagens

diferenciadas em relação às abordagens adotadas nos ambientes computacionais tradicionais. Uma

forma de atender aos requisitos de segurança da IoT é por meio de uma infraestrutura de autenticação e

de autorização (Authentication and Authorization Infrastructure – AAI). Esta infraestrutura é conhecida

como o elemento central para prover a segurança e lidar com problemas de segurança em aplicações

distribuídas. Com esta infraestrutura, é possível implantar a gestão de identidades de forma a impedir

que usuários ou objetos não autorizados tenham acesso aos recursos, impedir que usuários ou objetos

legítimos acessem recursos que estes não estão autorizados e permitir que os usuários ou objetos

legítimos tenham acesso aos recursos a estes autorizados (LIU; XIAO; CHEN, 2012).

A gestão de identidades (Identity Management - IdM) pode ser entendida como o conjunto de

processos e tecnologias usados para garantir a identidade de uma entidade ou de um objeto, garantir a

qualidade das informações de uma identidade (identificadores, credenciais e atributos) e para prover

procedimentos de autenticação, autorização, contabilização e auditoria (ITU, 2009).

Uma das maneiras de prover a IdM em um ambiente com diferentes domínios de segurança é

utilizando um sistema baseado no modelo de gestão de identidades federadas (BHARGAV-SPANTZEL

17

et al., 2007). Este modelo se baseia no conceito de federação, descrito por Chadwick (2009) como

uma associação entre diversos provedores (de serviço e de identidades) que estabelecem entre si um

nível de confiança suficiente para permitir a troca de mensagens entre estes. Neste modelo, há mais de

um domínio administrativo de segurança participando da federação e o acordo de confiança existente

garante que usuários possam se autenticar em seu domínio de segurança e usar dessa autenticação

para acessar recursos protegidos, disponibilizados por entidades em outros domínios da federação

(BHARGAV-SPANTZEL et al., 2007). Se o mesmo evento de autenticação puder ser utilizado para

acesso a diversos serviços da federação, tem-se a autenticação única (Single Sign-On – SSO).

No contexto de gestão de identidades federadas, destaca-se o conjunto de especificações SAML

(Security Assertion Markup Language), que é um padrão baseado em XML (eXtensible Markup

Language) para a descrição e troca de asserções de segurança entre parceiros de negócio na Internet. O

SAML define regras para trocas de mensagens e a sintaxe destas permitindo, dentre outras coisas, a

autenticação única entre múltiplos domínios de segurança. O SAML tem suporte a diversos mecanismos

para gestão de identidades federadas, sendo uma das principais tecnologias para abordar o problema

(OASIS, 2008). Já no quesito de autorização, um padrão reconhecido é o XACML (eXtensible Access

Control Markup Language), que é uma linguagem também baseada em XML para a descrição de

políticas de autorização e para requisição/resposta de decisões de controle de acesso (OASIS, 2003).

Neste contexto, o presente trabalho visa contribuir na área de gestão de identidades para Internet

das Coisas.

1.1 PROBLEMA DE PESQUISA

Em Babar et al. (2011), algumas questões são levantadas em relação à segurança na IoT,

denotando a diferença em relação à segurança fora do ambiente de IoT:

• Segurança naturalmente consome recursos e, assim, acrescentar mecanismos de segurança

em dispositivos embarcados com restrições computacionais pode ser um desafio. Além disso,

o tempo de duração da bateria está ligado ao número de computações feitas, portanto, quanto

mais computação, menor a carga da bateria e menor a autonomia do sistema (restrições

de energia). Limitações em termos de armazenamento também podem ser obstáculos para

garantir requisitos de segurança nesses dispositivos;

• Criptografia é uma solução cara para dispositivos com restrições. Logo, em algumas si-

18

tuações, o uso de algoritmos criptográficos leves, otimizados para esse cenário, se faz

necessário;

• O acesso físico aos dispositivos é facilitado, em função do tipo de ambiente nos quais os

objetos estão inseridos. Assim, são necessárias as proteções lógica e física destes; e

• Diante da heterogeneidade dos dispositivos, desenvolver mecanismos de segurança que

possam ser executados em diferentes plataformas é um requisito importante.

A IoT é composta de dispositivos heterogêneos, que precisam provar a sua autenticidade

para as entidades com as quais se comunicam. Esses dispositivos estão localizados em domínios

administrativos de segurança que podem ser compostos de diferentes dispositivos e de diferentes

tecnologias de comunicação, bem como podem prover diferentes mecanismos para que tais dispositivos

provem a sua autenticidade. É possível que o cliente, seja ele um usuário ou um dispositivo, deseje

acessar um recurso que é disponibilizado em um domínio administrativo de segurança diferente do

seu, como descrito em Gusmeroli, Piccione e Rotondi (2013), Gardel et al. (2013), Liu, Xiao e Chen

(2012), Conzon et al. (2012) e Akram e Hoffmann (2008b). Conforme Wangham, Domenech e Mello

(2013), os dispositivos da IoT podem utilizar mecanismos de autenticação que são diferentes daqueles

utilizados por usuários humanos. Um problema neste cenário é garantir a autenticidade de dispositivos

e de usuários que se comunicam entre si e que estão em domínios administrativos de segurança

diferentes, bem como utilizam mecanismos de autenticação distintos.

Apesar da gestão de identidades federadas de usuários ser bem abordada na literatura, a gestão

de identidades federadas de dispositivos não é bem caracterizada e, segundo Miorandi et al. (2012),

é um desafio de pesquisa neste cenário. A autenticação de objetos e de usuários em uma mesma

infraestrutura que usa o modelo de gestão de identidades federadas na IoT não é tratada na literatura.

A autenticação de objetos e de usuários em uma mesma infraestrutura que usa o modelo centralizado é

abordada em Nguyen, Al-Saffar e Huh (2010) e Hanumanthappa e Singh (2012). Gusmeroli, Piccione

e Rotondi (2013) descrevem uma infraestrutura que segue o modelo tradicional.

Diante desse cenário, é preciso que diferentes mecanismos de autenticação (para usuários e

para dispositivos) possam ser utilizados na infraestrutura, de modo a garantir a capacidade destes

de provarem a sua identidade para as mais variadas entidades com as quais forem se comunicar. A

possibilidade de uso de diferentes mecanismos de autenticação na IoT foi abordada em Akram e

Hoffmann (2008b) e Conzon et al. (2012), contudo considerando apenas mecanismos para autenticar

usuários e não dispositivos.

19

A autenticação única (Single Sign On -SSO) de usuários em ambientes federados é tratada

na literatura por várias soluções, tais como o Liberty Alliance, OpenID e Windows CardSpace

(WANGHAM et al., 2010). As soluções de IdM com foco na IoT que abordam ambientes federados não

apresentam soluções para a autenticação única de dispositivos (LIU; XIAO; CHEN, 2012; AKRAM;

HOFFMANN, 2008b; GARDEL et al., 2013). Estas soluções abordam a autenticação única, contudo

apenas para usuários.

A especificação SAML permite o uso de diversos mecanismos de autenticação de usuários e

de dispositivos, gerando ao final uma asserção SAML sobre o evento de autenticação. Além disso, a

especificação provê pontos de extensão que permitem que outros mecanismos de autenticação sejam

tolerados, conforme a necessidade do ambiente (OASIS, 2005a).

A especificação SAML (OASIS, 2009d) é uma possível solução para o problema de autenti-

cação federada de dispositivos. Esta possui um perfil de utilização chamado ECP (Enhanced Client

and Proxy), o qual trata da troca de informações de segurança (p.e. asserções sobre autenticação e

autorização do cliente) envolvendo clientes ativos que não fazem uso de um navegador Web, sendo

que a autenticação única é uma das funcionalidades que a especificação oferece neste perfil. O perfil

pode ser utilizado por dispositivos para acessar um recurso protegido.

O perfil ECP exige o uso do protocolo SOAP nas trocas de mensagens entre as entidades,

além de incluir diversos cabeçalhos SOAP adicionais que o cliente deve processar (OASIS, 2009d).

Contudo, o uso do protocolo SOAP não é adequado para o cenário de IoT, pois é muito custoso

computacionalmente (ZENG; GUO; CHENG, 2011; HAMESEDER; FOWLER; PETERSON, 2011).

Alguns trabalhos já abordaram o uso do SAML no contexto da IoT. Em Seitz, Selander e

Gehrmann (2013), asserções SAML são utilizadas para expressar decisões de autorização em um

cenário de IoT, mas o trabalho aborda apenas a autorização e usa apenas as asserções e não protocolos

SAML. Em Akram e Hoffmann (2008b), o SAML é utilizado como parte de uma solução de IdM

para IoT, contudo este é empregado ao lidar com a autenticação de usuários e não ao lidar com a

autenticação de dispositivos.

Outro ponto importante na Internet das Coisas e nas infraestruturas de autenticação e autoriza-

ção, é o uso de mecanismos de autorização alinhados aos requisitos da IoT. Uma AAI que suporte

diferentes modelos e políticas de controle de acesso pode mais facilmente se adaptar às necessidades

dos processos de autorização em aplicações de IoT. A autorização é abordada em AAIs em Gusmeroli,

Piccione e Rotondi (2013) e Liu, Xiao e Chen (2012), contudo provendo suporte a apenas um modelo

20

de controle de acesso. Em Graf et al. (2011), é provido um mecanismo para construção de políticas de

controle de acesso flexíveis, contudo, não são descritos os modelos de controle de acesso suportados.

Nenhum destes trabalhos utiliza padrões de autorização amplamente aceitos. Apenas em Gusmeroli,

Piccione e Rotondi (2013), os esquemas XML utilizados são baseados nos esquemas dos padrões

SAML e XACML.

Diante desse contexto, as seguintes perguntas de pesquisa foram formuladas:

1. Como garantir a autenticação única (SSO) de usuários e de objetos físicos (dispositivos)

que utilizam diferentes mecanismos de autenticação e que estão em domínios de segurança

diferentes, tendo como base o padrão SAML e atendendo as necessidades de aplicações de

IoT?

2. Como suportar mecanismos de autorização flexíveis que reflitam as necessidades de aplica-

ções de IoT tendo como base o padrão XACML?

3. Quais os impactos na utilização de recursos computacionais dos dispositivos decorrentes

do uso de uma Infraestrutura de Autenticação e de Autorização em um ambiente industrial

inteligente que provê aplicações de monitoramento e controle de máquinas industriais?

1.1.1 Solução Proposta

A solução proposta nesse trabalho (Infraestrutura de Autenticação e de Autorização para a

Web das Coisas - Authentication and Authorization Infrastructure for Web of Things - AAI4WoT) visa

conceber uma infraestrutura de autenticação e de autorização (AAI) alinhada aos requisitos da Internet

das Coisas. Para atender as necessidades de autenticação e de autorização no cenário em que cliente

(usuário ou dispositivo) e provedor do recurso (dispositivo) estão em domínios de segurança diferentes,

a AAI4WoT está baseada no modelo de gestão de identidades federadas.

Os problemas de (i) autenticação de usuários e de dispositivos em uma única infraestrutura, (ii)

a autenticação única de dispositivos e de usuários e (iii) o uso de diferentes mecanismos de autenticação

de usuários e de dispositivos são abordados pela AAI4WoT por meio do uso do padrão SAML. A

especificação SAML é utilizada para a troca de dados de segurança (autenticação e atributos) entre

as entidades. Assim, o SAML é utilizado tanto como formato padrão para expressão de dados de

autenticação e atributos, por meio das asserções SAML, quanto para a requisição/resposta de tais

asserções, por meio dos protocolos SAML. Desse modo, provedores de identidade (Identity Providers -

21

IdPs), provedores de serviço (Service Providers - SPs) e clientes são capazes de tratar asserções SAML

e executar seus protocolos.

Para que o padrão SAML possa ser utilizado no cliente, foi proposto um "Cliente Ativo", o

qual tem como função intermediar a troca de mensagens entre o SP e o IdP. Uma das responsabilidades

do cliente ativo é solicitar e interpretar a política de qualidade de proteção do SP que o cliente deseja

acessar, para montar uma requisição de autenticação para um IdP que seja capaz de autenticar o cliente

conforme solicitado na política. Outra funcionalidade é utilizar a asserção SAML enviada pelo IdP

para o cliente, referente ao evento de autenticação realizado, para acesso ao SP desejado.

O SAML é extensível, o que permite que novos mecanismos de autenticação possam ser

utilizados. Desse modo, a solução proposta utiliza estes pontos de extensão para permitir que diferentes

mecanismos de autenticação de dispositivos sejam utilizados.

A fim de tratar dos aspectos do SAML que dificultam sua aplicação no cenário de IoT para

dispositivos, como a necessidade de utilizar o protocolo SOAP quando se utiliza o perfil SAML ECP,

a AAI4WoT teve seus componentes implementados utilizando Serviços Web RESTful. Assim, os

recursos providos pelos dispositivos são acessíveis por meio de Serviços Web RESTful, do mesmo

modo que os serviços de autorização e autenticação da AAI4WoT. Logo, não é utilizado o protocolo

SOAP nas trocas de mensagens, apenas o protocolo HTTP.

Para prover o suporte a mecanismos de autorização flexíveis, a AAI4WoT está baseada no

padrão XACML. Na AAI4WoT, o dispositivo que provê o recurso solicita decisões de autorização

à uma entidade da AAI com muitos recursos computacionais. Esta entidade centraliza, no domínio

do dispositivo, a função de tomada de decisões de autorização. Assim, cabe ao dispositivo apenas a

aplicação da decisão tomada. Para tomar essa decisão, a entidade utiliza políticas de autorização e

requisições/respostas em formatos descritos no padrão XACML. As funcionalidades das entidades de

autorização da IAA4WoT também são oferecidas como Serviços Web RESTful.

Como prova de conceito, um protótipo da AAI4WoT foi desenvolvido. Com o objetivo de

avaliar os impactos da AAI4WoT no desempenho da rede e no uso de recursos computacionais dos

dispositivos, a AAI4WoT foi integrada à uma aplicação de WoT para o monitoramento e controle de

máquinas industriais.

As seguintes hipóteses foram investigadas:

22

1. A utilização dos princípios REST e do protocolo HTTP como protocolo de aplicação e de

transporte, em uma AAI baseada no modelo de gestão de identidades federadas e no padrão

SAML, permite prover autenticação federada (e única) de usuários e de dispositivos diante

de diferentes mecanismos de autenticação em um cenário de IoT.

2. A tomada de decisões de autorização fora do dispositivo que provê o recurso, utilizando in-

tegralmente o padrão XACML e os princípios REST, torna possível o suporte a mecanismos

de autorização flexíveis que refletem as necessidades das aplicações de IoT;

3. O uso da AAI proposta em uma aplicação de IoT implica na utilização de mais recursos

computacionais dos dispositivos, porém o uso da autenticação única reduz os impactos no

consumo de recursos computacionais.

1.1.2 Delimitação de Escopo

Esse trabalho limita-se ao uso de mecanismos de segurança para prover a autenticação em

um cenário da IoT com múltiplos domínios administrativos de segurança. Não faz parte do escopo

a criação de novos mecanismos de autenticação, nem a definição de um novo modelo de gestão de

identidades para o cenário de IoT. Não foi criado um novo modelo de controle de acesso e não foi

criado um novo mecanismo para descrição de políticas de autorização. Também, não foram abordadas

questões relacionadas à auditoria e contabilização dentro do contexto da gestão de identidades na IoT.

Para a avaliação da AAI4WoT, esta foi integrada à uma aplicação de monitoramento e controle

de máquinas industriais inteligentes. A AAI4WoT foi implementada, enquanto que a aplicação de

WoT foi apenas adaptada e não faz parte das contribuições deste trabalho.

1.1.3 Justificativa

A IoT tem se mostrado um tópico de interesse e relevância para a comunidade acadêmica

e para a indústria, no qual se vê um grande impacto para as pessoas e organizações. A IoT integra

dispositivos heterogêneos, o que demanda uma preocupação em relação a interoperabilidade entre

estes (ATZORI; IERA; MORABITO, 2010; MAHALLE et al., 2012). A IoT possui características que

demandam abordagens diferenciadas em relação a segurança, sendo a segurança um dos pontos que

trazem desafios aos pesquisadores (BABAR et al., 2011; ROMAN; NAJERA; LOPEZ, 2011).

Diante do problema de pesquisa e das abordagens encontradas na literatura, como é mostrado no

23

Capítulo 3, a AAI4WoT diferencia-se ao ser uma solução que utiliza o modelo de gestão de identidades

federadas que permite, na mesma infraestrutura, a autenticação única de usuários e de dispositivos.

A AAI4WoT diferencia-se ainda ao possibilitar o uso de diferentes mecanismos de autenticação de

usuários e de dispositivos. Outro diferencial é o uso do XACML como solução de autorização em uma

infraestrutura que trata tanto de autorização como de autenticação de usuários e de dispositivos. Neste

aspecto, a AAI4WoT também diferencia-se ao oferecer as funcionalidades de autorização por meio de

Serviços Web RESTful.

Considerando o cenário de domínios administrativos de segurança heterogêneos, administrados

por organizações distintas, a escolha do modelo de gestão de identidades federadas foi a mais indicada.

Com o uso do modelo federado, cada domínio deve tratar da heterogeneidade de mecanismos de

autenticação apenas no escopo do seu domínio, uma vez que entidades externas são autenticadas em

seus respectivos domínios. Isso é possível em função das relações de confiança entre os IdPs e SPs dos

diferentes domínios de segurança de uma federação (autenticação federada).

Para resolver o problema de autenticação única de usuários e de dispositivos em uma única

infraestrutura em um ambiente federado, a AAI4WoT emprega o SAML como padrão para a troca

de informações de autenticação e de atributos dentro da federação. A escolha justifica-se por ser um

padrão amplamente utilizado em soluções de IdM fora do cenário de IoT, como em Cabarcos et al.

(2009), Garzoglio et al. (2011), Tormo, Millán e Pérez (2013) e em federações como a CAFe1 e a

GÉANT2.

O SAML provê suporte a mecanismos de autenticação de usuários e de dispositivos e à

autenticação única. Como mencionado, a especificação é extensível e permite que novos mecanismos

de autenticação sejam utilizados, de acordo com as necessidades de cada ambiente (OASIS, 2009a;

OASIS, 2005a). Logo, o uso do SAML facilita a interoperabilidade dos dispositivos da IoT com

sistemas da Internet atual.

O uso do estilo arquitetural REST na AAI4WoT vai ao encontro da necessidade de prover

mecanismos de segurança mais leves para a IoT e se mostra mais adequado quando comparado ao

SOAP (HAMESEDER; FOWLER; PETERSON, 2011). O uso de Serviços Web RESTful promove

uma maior interoperabilidade entre serviços e dispositivos, uma vez que o HTTP, um protocolo

extensamente usado na Web, é o protocolo de aplicação adotado. Guinard et al. (2009) e Guinard e

Trifa (2009) são trabalhos que corroboram com essa visão.1 http://portal.rnp.br/web/servicos/como-funciona2 http://www.geant.net/Pages/default.aspx

24

Na AAI4WoT, a flexibilidade de descrição de políticas de autorização e o suporte a diferentes

modelos de controle de acesso foi alcançado por meio do uso do XACML. Esta escolha justifica-se pelo

XACML ser um padrão consolidado na Internet para a descrição de políticas e requisição/resposta de

decisões de autorização, utilizado fora do contexto de IoT e juntamente com o SAML (GARZOGLIO

et al., 2011; TORMO; MILLáN; PéREZ, 2013; ULLTVEIT-MOE; OLESHCHUK, 2012). Ainda, o

XACML permite que decisões de autorização sejam solicitadas e entregues em diferentes formatos,

o que facilita a interoperabilidade com entidades que não utilizam o padrão XACML, sendo uma

opção para tratar a heterogeneidade da IoT. Outro aspecto em que o uso do XACML favorece a

interoperabilidade na IoT é a existência de perfis de uso bem definidos que suportam Serviços Web

RESTful (OASIS, 2013b).

Este trabalho está inserido em um projeto que estabelece uma parceria entre pesquisadores do

Mestrado em Computação Aplicada da Univali e uma indústria produtora de máquinas industriais. Este

projeto inclui o desenvolvimento de uma aplicação de WoT para controle e monitoramento remoto de

máquinas industriais inteligentes, em que as máquinas são monitoradas e controladas a partir de um

domínio de segurança diferente do domínio da máquina. Logo, a demanda pela resolução do problema

de pesquisa vem ao encontro das necessidades de um cenário real de ambientes industriais inteligentes,

sendo esta a aplicação utilizada na etapa de avaliação deste trabalho.

1.2 OBJETIVOS

1.2.1 Objetivo Geral

Prover autenticação e autorização de usuários e de dispositivos no cenário de Web das Coisas

para dispositivos e usuários em domínios de segurança diferentes, por meio de uma infraestrutura de

autenticação e de autorização.

1.2.2 Objetivos Específicos

Os objetivos específicos são:

1. Verificar como diferentes mecanismos de autenticação de dispositivos e diferentes modelos

de controle de acesso empregados nas aplicações de Internet das Coisas podem ser utilizados

em uma Infraestrutura de Autenticação e de Autorização baseada nos padrões SAML e

25

XACML;

2. Prover, em uma única infraestrutura, a autenticação única (SSO) de usuários e de disposi-

tivos que utilizam diferentes mecanismos de autenticação, diante de diferentes domínios

administrativos de segurança;

3. Prover um mecanismo de autorização flexível, com suporte a diferentes modelos de controle

de acesso e diferentes políticas de autorização, adequados aos requisitos de aplicações da

Internet das Coisas;

4. Avaliar os impactos do uso da infraestrutura de autenticação e de autorização quando utili-

zada em uma aplicação de Web das Coisas, em termos do uso de recursos computacionais

dos dispositivos.

1.3 METODOLOGIA

Esta seção apresenta a metodologia de pesquisa adotada neste trabalho.

1.3.1 Metodologia da Pesquisa

No desenvolvimento deste trabalho foi utilizado o método hipotético-dedutivo, pois pretendeu-

se confirmar ou refutar as hipóteses apresentadas por meio do desenvolvimento da AAI4WoT e do seu

uso em uma aplicação de controle e monitoramento remoto de máquinas industriais.

O método utilizado, sob o ponto de vista de sua natureza, foi o de pesquisa aplicada. Segundo

UNIVALI (2011), a pesquisa aplicada visa a utilização imediata na solução de problemas concretos.

Logo, a pesquisa teve por objetivo resolver o problema de IdM de dispositivos e de usuários em

aplicações distribuídas da IoT, diante de múltiplos domínios de segurança, por meio do uso de uma

AAI baseada nos padrões SAML e XACML, o que é de aplicação prática para os cenários relacionados.

Sobre a forma de abordagem do problema, a pesquisa foi quantitativa e qualitativa. A pesquisa

foi quantitativa, pois a execução dos experimentos permitiu, por meio do uso de métodos estatísticos,

a avaliação das hipóteses estabelecidas sobre o impacto do uso da AAI4WoT na aplicação de WoT

(hipóteses 3 e 4). A pesquisa foi qualitativa, no que se refere à investigação das hipóteses sobre (i) o

provimento de autenticação única de usuários e de dispositivos que utilizam diferentes mecanismos

de autenticação, diante de múltiplos domínios administrativos, e (ii) sobre o suporte a mecanismos

26

de autorização flexíveis (hipóteses 1 e 2). Há, nestes casos, uma subjetividade inerente ao problema,

que não pode ser traduzida em números, sendo esta dependente da interpretação dos fenômenos

observados e da atribuição correta de significado aos mesmos. Isso torna o uso de métodos estatísticos

facultativo (SILVA; MENEZES, 2005). Logo, a avaliação foi dada de forma descritiva, através da

análise e comparação de trabalhos e da análise do atendimentos de alguns requisitos.

Acerca dos objetivos do trabalho, a pesquisa caracteriza-se como exploratória. A pesquisa

exploratória deve ser constituída pela pesquisa bibliográfica disciplinada, crítica e ampla, visando tornar

o problema explícito ou construir hipóteses (MINAYO; DESLANDES, 1994; SILVA; MENEZES,

2005). Inicialmente, foi realizado um levantamento bibliográfico para o entendimento e definição do

problema de pesquisa, o que permitiu a elaboração das hipóteses e dos procedimentos metodológicos

que foram seguidos para investigar a veracidade das hipóteses, conforme descrito na Seção 1.3.2.

1.3.2 Procedimentos Metodológicos

Esta seção apresenta as etapas do trabalho que foram realizadas para o cumprimento dos

objetivos:

1. Pesquisa bibliográfica: esta etapa teve por objetivo prover o conhecimento teórico para

a definição da solução proposta. Foi realizado um levantamento bibliográfico sobre a

Internet das Coisas e a Web das Coisas. Também foram estudados os aspectos de segurança

computacional, mais especificamente aqueles relacionados a autenticação e a autorização

de usuários e de dispositivos na Internet das Coisas;

2. Análise de trabalhos relacionados: esta etapa visou analisar os trabalhos relacionados

encontrados na literatura que utilizam mecanismos de autenticação e de autorização na

IoT. Estes trabalhos foram selecionados e analisados por meio de critérios definidos em um

protocolo de busca de uma revisão sistemática. Também foi feita uma análise comparativa

das soluções abordadas em cada trabalho;

3. Definição da Infraestrutura de Autenticação e de Autorização: esta etapa visou atender

ao objetivo específico 1. Nesta, foi definido como a Infraestrutura de Autenticação e de

Autorização proposta deveria ser composta para atender aos objetivos desse trabalho. Esta

etapa incluiu o estudo das especificações SAML e XACML, o que permitiu a análise de

como estes padrões poderiam ser utilizados para tratar do problema de pesquisa. Também

27

foram definidas como deveria ser a troca de mensagens entre as entidades da Infraestrutura

de Autenticação e de Autorização;

4. Modelagem da Infraestrutura de Autenticação e de Autorização: esta etapa visou aten-

der, parcialmente, aos objetivos específicos 2 e 3, e compreendeu o levantamento de requisi-

tos e a modelagem da Infraestrutura de Autenticação e de Autorização;

5. Implementação e Integração da Infraestrutura de Autenticação e de Autorização: esta

etapa visou o atendimento parcial dos objetivos específicos 2 e 3. A etapa compreendeu a

implementação da AAI4WoT e a integração desta à aplicação de WoT utilizada na etapa de

Avaliação; e

6. Avaliação da Infraestrutura de Autenticação e de Autorização: esta etapa visou o aten-

dimento aos objetivos específicos 2, 3, e 4. A etapa compreendeu a avaliação dos impactos

decorrentes do uso da AAI4WoT na aplicação industrial de WoT, em termos de desempenho

da rede e do uso de recursos computacionais dos dispositivos, bem como em relação ao

atendimento aos objetivos de segurança.

1.4 ESTRUTURA DA DISSERTAÇÃO

O trabalho está organizado em seis capítulos correlacionados. O Capítulo 1 apresentou, por

meio de sua contextualização, o tema deste trabalho. Foram também estabelecidos o problema de

pesquisa, a solução proposta, os objetivos e a metodologia que foi seguida para atingir os objetivos.

O Capítulo 2 apresenta a fundamentação teórica sobre a Internet das Coisas, gestão de identida-

des digitais e sobre as especificações de segurança que foram utilizadas neste trabalho.

No Capítulo 3 são apresentados os trabalhos relacionados encontrados na literatura, que

abordam a gestão de identidades na Internet das Coisas e na Web das Coisas. Mais especificamente,

são descritos os trabalhos que apresentam infraestruturas que auxiliam nos processos de autenticação,

autorização e de controle de acesso de usuários e/ou de dispositivos.

O Capítulo 4 apresenta a infraestrutura de autenticação e de autorização para a Web das Coisas

(AAI4WoT). Neste capítulo são descritos os modos de operação e os componentes da AAI, assim como

o modelo de ameaças da solução proposta. Também é apresentado neste capítulo o desenvolvimento

da AAI4WoT e sua integração à uma aplicação de WoT para o controle e monitoramento remoto de

máquinas industriais, que compõe o estudo de caso realizado.

28

O Capítulo 5 apresenta os experimentos realizados e os resultados obtidos no estudo de caso,

bem como uma análise destes.

No Capítulo 6, são tecidas as considerações finais, relacionando o que foi realizado com os

objetivos e hipóteses do trabalho. Também são apresentados os trabalhos futuros.

O Apêndice A apresenta o protocolo de busca e os resultados da revisão sistemática da literatura

que foi conduzida. O Apêndice B apresenta a política de controle de acesso utilizada nos experimentos

(estudo de caso). O Apêndice C descreve como o mecanismo de autenticação de dispositivos utilizado

nos experimentos pode ser representado utilizando o padrão SAML. Por fim, o Apêndice D apresenta

a modelagem de software do protótipo desenvolvido.

29

2 FUNDAMENTAÇÃO TEÓRICA

Neste capítulo, são apresentados os conceitos de Internet das Coisas (IoT) e Web das Coisas

(WoT), assim como os requisitos de segurança para estes paradigmas e as principais ameaças e

ataques. É abordada também a gestão de identidades digitais, os principais modelos de gestão de

identidades, bem como os aspectos relacionados à autenticação e autorização. Por fim, são apresentadas

as especificações SAML, XACML e WS-Policy, as quais são utilizadas em soluções de segurança para

XML e Serviços Web.

2.1 INTERNET DAS COISAS

O próximo passo para o crescimento da Internet é a integração de objetos físicos do dia a dia

(coisas) às redes de comunicação. Esse paradigma, chamado de Internet das Coisas (IoT), abrange

uma infraestrutura de hardware, software e serviços que conectam esses objetos físicos à Internet

(ITU, 2005; COMMUNITIES, 2008). Segundo o relatório ITU Internet Reports 2005: The internet

of things (ITU, 2005), a IoT pode trazer mudanças para a sociedade, como por exemplo, na maneira

como o indivíduo se relaciona com o ambiente, ou na maneira como são realizados os processos de

negócios. Além da comunicação e informação a qualquer momento e em qualquer lugar, na IoT, é

possível também a conectividade para qualquer coisa.

A IoT possui características diferentes quando comparada com cenários computacionais tradi-

cionais. As principais características da IoT são (WANGHAM; DOMENECH; MELLO, 2013):

• A IoT pode ser caracterizada como uma rede mundial de coisas/objetos/dispositivos in-

terconectados que se comportam como entidades ativas (ROMAN; NAJERA; LOPEZ,

2011);

• As coisas (dispositivos) na IoT, muitas vezes, possuem restrições de recursos como RAM

ou ROM, poder de processamento e energia (HUMMEN et al., 2013);

• Mecanismos de comunicação de alguns dispositivos, na maioria das vezes sem fio, possuem

baixa potência de transmissão e baixa taxa de dados (MAHALLE et al., 2010);

• Há uma grande quantidade de coisas com ciclo curto de vida, o que exige uma alta capaci-

dade de gerenciamento (FONGEN, 2012);

30

• Integra coisas heterogêneas, o que demanda uma preocupação em relação a interoperabili-

dade entre estas (ATZORI; IERA; MORABITO, 2010; MAHALLE et al., 2012);

• A rede possui uma topologia dinâmica, pois muitos nós entram e saem da rede com

frequência (MAHALLE et al., 2012; HANUMANTHAPPA; SINGH, 2012);

• Pode ser caracterizada como um ambiente contendo um grande número de computadores

ou dispositivos invisíveis que colaboram com o usuário, ou seja, um ambiente pervasivo e

ubíquo (HANUMANTHAPPA; SINGH, 2012); e

• Na IoT, os usuários podem interagir com as coisas em seu ambiente físico e virtual de

diversas maneiras (MAHALLE et al., 2012).

Os dispositivos na IoT também possuem características singulares. De acordo com Roman,

Najera e Lopez (2011), as coisas na IoT possuem cinco características principais e uma opcional:

• Existência: coisas que existem no mundo real podem também existir no mundo virtual, por

meio de dispositivos de comunicação embarcada;

• Auto conhecimento (do inglês, sense of self ): todas as coisas têm, explicitamente ou impli-

citamente, uma identidade que as descreve. As coisas podem processar informação, tomar

decisões e se comportar de maneira autônoma;

• Conectividade: as coisas podem iniciar a comunicação com outras entidades. Dessa maneira,

a comunicação com entidades nas suas proximidades ou em ambientes remotos é possível;

• Interatividade: as coisas podem interoperar e colaborar com uma variedade de entidades

heterogêneas, seja humanos ou máquinas virtuais ou reais. Desse modo, estas produzem e

consomem uma grande variedade de serviços;

• Dinamicidade: as coisas podem interagir entre si a qualquer momento, lugar ou maneira.

Estas podem entrar e sair de uma rede conforme quiserem, não estando limitadas a um

único local físico, podendo usar uma grande variedade de interfaces; e

• (opcional) Ciência do ambiente: sensores permitem que as coisas percebam as característi-

cas de seu ambiente (p.e. a sobrecarga da rede ou a radiação da água). Contudo, nem todas

as coisas possuem esta capacidade, como por exemplo, um objeto com uma etiqueta RFID.

31

O conceito de IoT pode ser aplicado de diversas maneiras na vida das pessoas e organizações.

Em Atzori, Iera e Morabito (2010), é feito um agrupamento dos diferentes tipos de aplicações da IoT

em quatro domínios. São estes:

• Transporte e logística: aplicações que envolvem meios de transporte de pessoas e de merca-

dorias, assim como aplicações para rodovias;

• Cuidados com a saúde: aplicações para auxílio de cuidados com a saúde das pessoas;

• Ambientes inteligentes: aplicações que tornam escritórios, casas, plantas industriais e ambi-

entes de lazer inteligentes; e

• Pessoal e social: aplicações que habilitam o usuário a interagir com outras pessoas para

manter e criar relacionamentos.

A realização do conceito de IoT no mundo real é possível por meio do uso e integração de

várias tecnologias habilitadoras (ATZORI; IERA; MORABITO, 2010). Como exemplos, pode-se citar

RFID (Radio-Frequency IDentification)1, WSN (Wireless Sensor Network)2, WSAN (Wireless Sensor

and Actuator Network)3, EnHANTs (Energy Harvesting Active Networked Tags)4, NFC (Near Field

Communications)5 e RSN (RFID sensor networks)6, conforme apresentado em Wangham, Domenech

e Mello (2013). Como mencionado, a IoT é composta de ambientes e dispositivos heterogêneos, o que

leva muitas vezes com que esta seja tratada como Web das Coisas (Web of Things – WoT).

2.1.1 Web das Coisas

Por bastante tempo, projetos e iniciativas relacionados à IoT focaram principalmente no

tratamento das questões relacionadas à conectividade em ambientes de rede restritos. Com base na

existência desta conectividade de rede, o próximo passo é a concepção de modelos de comunicação,

tendo como foco a camada de aplicação. Desse modo, quanto mais e mais dispositivos são conectados

à Internet, o uso da Web como uma plataforma para integrar os dispositivos inteligentes da IoT com o

dia-a-dia do ser humano se mostra uma boa escolha (GUINARD et al., 2011).1 (YAN et al., 2008; JUELS, 2006)2 (XIANG; LI, 2012; AKYILDIZ et al., 2002)3 (MARTINEZ et al., 2008)4 (GORLATOVA et al., 2010)5 (AHSON SYED A; ILYAS, 2012; CAVOUKIAN, 2012)6 (BUETTNER et al., 2008)

32

Segundo Guinard et al. (2011), na WoT, os dispositivos inteligentes e seus serviços são

integrados à Web através da reutilização e adaptação de tecnologias e padrões Web que são comumente

utilizados em conteúdos Web tradicionais. Por exemplo, tais dispositivos podem ser indexados na Web,

encontrados por ferramentas de busca e utilizados em ferramentas de bookmarking dos navegadores.

Do mesmo modo, tais objetos podem ser ativos e podem realizar publicações na Web, assim como

podem interagir entre si por meio de Serviços Web disponibilizados nos dispositivos.

Segundo Zeng, Guo e Cheng (2011), existem diversos motivos que favorecem a WoT. A Web

se tornou o principal meio de comunicação na Internet. Navegadores Web estão disponíveis para

quase todas as plataformas, de computadores a smartphones e tablets, o que os tornam a interface

de usuário padrão de fato para uma gama de aplicações. Por meio da Web, é possível fazer uso da

tecnologia dos Serviços Web, a qual tem se mostrado indispensável na criação de aplicações distribuídas

interoperáveis para a Internet. Diversos pequenos servidores Web embarcados estão disponíveis, sendo

que muitos deles podem ser construídos em apenas alguns KBytes. Logo, as coisas inteligentes, com

servidores Web embarcados, podem ser abstraídas como Serviços Web e perfeitamente integradas na

Web existente, sendo que torna-se natural a reutilização de tecnologias e padrões Web existentes para

unificar o mundo cibernético ao mundo das coisas físicas.

Como as tecnologias Web existentes podem ser reutilizadas e adaptadas, é possível construir

novas aplicações e serviços com a participação das coisas inteligentes. Em suma, diferente do ponto

de vista tradicional da IoT, que associa ao dispositivo um endereço IP e os torna interconectados na

Internet, a WoT habilita os dispositivos a "conversarem"na mesma língua, de modo que estes possam se

comunicar e interagir livremente na Internet (ZENG; GUO; CHENG, 2011; GUINARD et al., 2011).

Segundo Zeng, Guo e Cheng (2011), há dois métodos para integrar coisas à Web: integração

direta e integração indireta. Na direta, é requerido que todas as coisas tenham um endereço IP ou

que tenham um IP habilitado quando conectados à Internet. Servidores Web devem ser embarcados

nas coisas/dispositivos para que estas possam se entender por meio da linguagem da Web. Já na

integração indireta, nem todos os dispositivos podem ter recursos computacionais suficientes para

embarcar um servidor Web (p.e. uma etiqueta RFID). Além disso, algumas vezes não é necessário

integrar diretamente todas as coisas inteligentes dentro da Web, quando se considera custo, energia

e segurança. Como solução para integração indireta, pode-se usar de um proxy, chamado de smart

gateway, localizado entre os dispositivos inteligentes e a Web.

Um smart gateway é um componente que permite interação Web com diferentes tipos de

dispositivos embarcados. Sua função é integrar as APIs proprietárias dos dispositivos embarcados e

33

expor as funcionalidades dos dispositivos como recursos identificados por URI, diretamente acessíveis

na Web e manipuláveis por meio do uso do HTTP. Isso permite que sistemas finais na Internet, que

podem ser outros objetos, se comuniquem com os objetos através desse smart gateway, sendo que

este recebe as mensagens vindas da Internet e as repassa ao objeto, e vice-versa (TRIFA et al., 2009;

MAHALLE et al., 2010). Um smart gateway pode ser usado também para orquestrar a composição

de diversos serviços de baixo nível em serviços de alto nível, criando "mashups"com serviços dos

dispositivos, conhecidos como "mashups físicos"(GUINARD; TRIFA, 2009).

2.1.1.1 Serviços Web na Web das Coisas

Segundo W3C (2004), um Serviço Web é um sistema de software projetado para suportar

a interação interoperável máquina à máquina (M2M) sobre uma rede. Há duas grandes classes de

Serviços Web: Serviços Web em conformidade com o REST (FIELDING; TAYLOR, 2002) e Serviços

Web arbitrários, ou WS-* (W3C, 2004). O objetivo principal dos Serviços Web em conformidade

com o REST é manipular os recursos da Web usando um conjunto uniforme de operações sem estado,

enquanto que nos Serviços Web arbitrários usa-se um conjunto arbitrário de operações (W3C, 2004).

Segundo Wangham, Domenech e Mello (2013), ambos os paradigmas podem ser adotados por smart

things ou smart gateways.

Segundo Zeng, Guo e Cheng (2011), as tecnologias chave do paradigma WS-* são o SOAP,

a WSDL (Web Services Description Language), a UDDI (Universal Description, Discovery and

Integration) e a BPEL (Business Process Execution Language). WSDL e SOAP são dois padrões

baseados em XML que são complexos e pesados, que acabam contribuindo para que os Serviços Web

arbitrários demandem mais em termos de poder de processamento, largura de banda e armazenamento

do que os Serviços Web em conformidade com o REST.

Conforme definido em Fielding e Taylor (2002), o REST é um estilo de arquitetura de software,

desenvolvido como um modelo abstrato da arquitetura Web, que pode ser aplicado no desenvolvimento

de sistemas distribuídos fracamente acoplados, denominados RESTful. O conceito básico do REST é

que qualquer coisa é modelada como recurso, ou particularmente como recursos HTTP, com uma URI.

O REST promove a reutilização de padrões Web, permitindo uma interação direta do cliente

com o serviço, sem a necessidade de interpretar uma WSDL para isso. Dispositivos que disponibilizam

seus recursos através de Serviços Web RESTful não necessitam de APIs adicionais7 ou descrições de7 APIs necessárias para a interação entre cliente e servidor, devido ao fato de que ao utilizar WS-*, cada serviço pode

disponibilizar métodos arbitrários e, ao utilizar Serviços WEB RESTful, só é possível utilizar um conjunto fixo de

34

recursos ou funções, como ocorre com Serviços Web arbitrários. Assim, em função da simplicidade,

leveza e interfaces uniformes promovidas pelo REST, o paradigma de Serviços Web RESTful é prefe-

rido para integração ad hoc na Web, viabilizando uma integração mais transparente dos dispositivos

da WoT com redes globais, como a Internet (GUINARD et al., 2009; HAMESEDER; FOWLER;

PETERSON, 2011).

Conforme Zeng, Guo e Cheng (2011), os Serviços Web RESTful são mais adequados para a

WoT do que os Serviços Web arbitrários. O aspecto leve do REST torna-o um excelente candidato

para viabilizar que dispositivos restritos disponibilizem seus recursos como serviços na Web. Algumas

das características que colaboram para essa visão são a baixa complexidade do REST e o baixo

acoplamento das interações sem estado. Os autores fazem uma comparação entre os paradigmas de

Serviços Web RESTful e de Serviços Web arbitrários, e as diferenças mais relevantes são descritas

abaixo:

• Complexidade: considerada alta no WS-* e baixa no REST;

• Manutenção de estados: WS-* trabalha com manutenção de estados enquanto REST não

prevê a manutenção de estados;

• Acoplamento: considerado alto no WS-* e baixo no REST; e

• Flexibilidade: considerada baixa no WS-* e alta no REST.

Os resultados descritos em Hameseder, Fowler e Peterson (2011) corroboram com esta visão.

Por meio da comparação de desempenho entre REST e SOAP, fica claro que o uso do REST é melhor

em termos de quantidade de dados transmitidos na rede, tempo de requisição/resposta e tempo de

serialização/desserialização (montagem e interpretação de requisição/resposta).

2.2 SEGURANÇA NA INTERNET DAS COISAS

Segundo Roman, Najera e Lopez (2011), a segurança é identificada como um dos obstáculos a

serem transpostos para o efetivo uso da IoT. Assim, essa seção visa elucidar os principais aspectos

relacionados à segurança na IoT, dentre estes os que envolvem a gestão de identidades digitais e as

especificações de segurança para XML e Serviços Web mais importantes no contexto deste trabalho.

métodos.

35

A IoT, conforme mencionado na Seção 2.1, possui características que a diferenciam dos

cenários computacionais tradicionais, as quais afetam o modo como a segurança é provida. Dentre

as principais características que afetam a segurança estão as restrições de memória, processamento

e energia. Por exemplo, uma atividade computacional mais intensa, decorrente da execução de um

algoritmo criptográfico, pode causar uma diminuição relevante do tempo de vida do dispositivo, o que

não é desejável. Neste sentido, conforme destacado em Wangham, Domenech e Mello (2013)8, alguns

trabalhos acadêmicos e atividades de padronização de tecnologias e de mecanismos de segurança estão

sendo conduzidos, visando torná-los mais adequados à IoT.

A IoT também possui ameaças e ataques diferentes daqueles dos cenários computacionais

tradicionais. Com base nisto, esta seção aborda os principais requisitos de segurança na IoT, bem como

as principais ameaças e ataques descritos na literatura para este paradigma.

2.2.1 Requisitos de Segurança

Com base nas características singulares da IoT, descritas na Seção 2.1, Alam, Chowdhury e

Noll (2011) e Roman, Najera e Lopez (2011) definem diversos requisitos de segurança para a IoT e

indicam quais propriedades de segurança devem ser garantidas. Estas propriedades são:

• Confidencialidade: dados sensíveis de usuários ou organizações podem estar contidos nas

transações na IoT e, portanto, a confidencialidade de tais dados deve ser assegurada;

• Integridade: dados armazenados e transmitidos não devem ser alterados, removidos ou

incluídos por usuários ou dispositivos não autorizados;

• Disponibilidade: manter os serviços/recursos da IoT disponíveis para acesso por usuários e

dispositivos autorizados em qualquer momento e a partir de qualquer lugar;

• Autenticidade: necessidade de autenticação mútua, pois os dados de IoT são usados para

diferentes processos de tomada de decisão e atuação; e

• Privacidade: se refere a necessidade de prover aos usuários meios para que estes controlem

a exposição e a disponibilidade dos seus próprios dados e informações e tenham maior

transparência sobre como e por quem seus dados são usados.8 Este texto possui estudos previamente publicados por Wangham, Domenech e Mello (2013), os quais foram realizados

no âmbito do mestrado e em conjunto com os respectivos pesquisadores.

36

Conforme descrito em Babar et al. (2010), alguns outros serviços de segurança precisam ser

garantidos na IoT. Dentre estes serviços estão:

• Gestão de Identidades: trata da identificação e autenticação de usuários e de dispositivos

em um sistema, bem como controla acessos aos recursos deste sistema associando direitos e

restrições de acesso, de acordo com a identidade estabelecida (autenticação e autorização);

• Comunicação segura de dados: inclui a autenticação dos pares da comunicação, assegu-

rando a confidencialidade e integridade dos dados transmitidos, impedindo o repúdio de

uma transação e protegendo a identidade das entidades;

• Acesso seguro à rede: garante a possibilidade de conexão de rede ou o acesso a um serviço

apenas para dispositivos autorizados; e

• Resistência à violação: mantém as características de segurança, mesmo quando o dispositivo

for acessado fisicamente por um atacante.

A grande escala e escopo da IoT aumentam as opções de interação dos usuários com os

sistemas, levando à necessidade de estender os modelos atuais de privacidade, segurança e gestão de

identidades para incluir a forma como os usuários interagem com os objetos. Neste sentido, também

são levantados os requisitos de que deve ser possível identificar os objetos de maneira única, além

de permitir a autenticação única (SSO) de objetos na IoT (MAHALLE; PRASAD; PRASAD, 2013;

MAHALLE et al., 2013).

Outro requisito de segurança da IoT é a tolerância a faltas, que consiste no sistema recuperar

a transmissão de dados e reparar a estrutura da rede (p.e. a topologia) de forma autônoma, mesmo

diante de faltas em nós ou nos enlaces da rede (XIAOHUI, 2012; ROMAN; NAJERA; LOPEZ, 2011;

WEBER, 2010).

Weber (2010) destaca ainda o requisito de autenticação de dados, em que o endereço e os

dados do objeto da IoT devem ser autenticados. O controle de acesso sobre os dados providos pelos

objetos também é tido como um requisito. Por fim, apenas o provedor de informações deve ser capaz

de inferir sobre um determinado usuário do sistema a partir de seus dados, o que resulta no requisito

de privacidade do cliente.

37

2.2.2 Ameaças e Ataques

A IoT possibilita que sistemas computacionais se tornem ubíquos e transparentes para os

usuários. Essa transparência, juntamente com a onipresença, ameaçam a privacidade dos usuários e

impõe dificuldades para garantir a confidencialidade e a integridade dos dados trefegados (AKRAM;

HOFFMANN, 2008a).

Do mesmo modo, o compartilhamento de dispositivos entre as pessoas é uma das principais

ameaças à privacidade dos usuários. As pessoas, de posse de um dispositivo alheio, poderiam facilmente

obter dados não autorizados, uma vez que o acesso físico ao dispositivo facilita a ação de um atacante

(JINDOU; XIAOFENG; CHENG, 2012).

Uma das grandes diferenças do cenário da IoT em relação aos cenários computacionais

tradicionais é que, na IoT, os dispositivos podem atuar também no mundo físico. Isso significa que uma

ameaça à segurança de um dispositivo pode ter impactos no mundo físico. Assim, se um dispositivo

da IoT for corrompido, há o risco de que esse corrompimento influencie o mundo físico ao ponto de

atentar contra o bem-estar e até à vida das pessoas (LIU; XIAO; CHEN, 2012). Por exemplo, um

dispositivo que possua sensor de fumaça deve avisar uma central de controle sempre que detectar

fumaça no ambiente. Caso o dispositivo seja corrompido, este poderá emitir alertas falsos ou mesmo

deixar de emitir alertas diante de uma situação de perigo com fumaça.

Babar et al. (2011) dividem os ataques na IoT em cinco categorias, relacionadas a seguir:

• Ataques físicos: violam o hardware do dispositivo e são difíceis de executar, pois o material

necessário para executar os ataques é caro. De-packaging de um chip, micro-probing e

layout reconstruction são técnicas usadas para esse tipo de ataque;

• Ataques no canal de comunicação: ataques baseados em dados recuperados dos dispositivos

responsáveis por operações criptográficas. Esses dados são obtidos através de análise de

temporização, radiação emitida, potência consumida, dentre outras fontes, que permitem

que a chave de criptografia usada seja inferida;

• Ataques de análise de criptografia: ataques com foco no texto cifrado, buscando encontrar

a chave criptográfica para obter o texto em claro (p.e. ataque man-in-the-middle);

• Ataques de software: exploram vulnerabilidades dos softwares presentes no dispositivo.

Inclui ataques de exploração de estouro do buffer (buffer overflow) e uso de programas

38

cavalos de tróia, worms e vírus para injetar código malicioso no sistema; e

• Ataques de rede: no meio sem fio a transmissão é por difusão (broadcast) e assim há

vulnerabilidades inerentes ao próprio meio. Nessa categoria entram ataques como captura e

análise de tráfego (eavesdropping), mascaramento (masquerading - no qual um nó se faz

passar por outro), negação de serviço (Denial of Service – DoS), corrupção de mensagens,

ataques de roteamento, dentre outros (BONETTO et al., 2012).

Conforme Mahalle et al. (2012), as próprias características da IoT potencializam o ataque de

DoS. Dentre tais características, pode-se citar a topologia dinâmica da rede, a menor largura de banda,

as restrições computacionais e de energia. Em alguns casos na IoT, o ataque de DoS pode ser chamado

de ataque de esgotamento de recursos.

No cenário da IoT, quando um dispositivo envia dados para outro, esteja este na mesma rede

do remetente ou não, esses dados enviados podem ser armazenados temporariamente nos dispositivos

intermediários que atuam como roteadores. Caso algum dispositivo intermediário seja malicioso, há a

ameaça de que este altere a informação em trânsito ou ainda deixe de encaminhar a informação para o

nó destinatário (CONZON et al., 2012).

Mahalle, Prasad e Prasad (2013) ainda apontam preocupações sobre o processo de ingresso dos

dispositivos em uma rede. No momento do ingresso na rede, informações sobre chaves criptográficas,

parâmetros de domínio e outras configurações podem ser capturadas por entidades maliciosas e estas

poderiam fazer uso dessas informações para interceptar e reencaminhar dados de forma a não ser

percebido, caracterizando um ataque man-in-the-middle. Neste caso, Mahalle et al. (2012) apontam

que o ataque man-in-the-middle pode levar ao ataque de mensagem antiga (replay attack), no qual o

atacante busca utilizar de mensagens antigas (interceptadas) para se comunicar com outros dispositivos,

a fim de obter respostas desses dispositivos que inicialmente não seriam para ele, mas sim para o

remetente da mensagem original.

Em arquiteturas da IoT que fazem uso do protocolo 6LoWPAN, existe a ameaça de corrom-

pimento de mensagens de identificação ou de localização de dispositivos. O corrompimento dessas

mensagens pode levar ao comprometimento da autenticidade das mensagens e dos participantes de

uma comunicação, pois um intruso pode enviar mensagens falsas de atualização de localização de um

dispositivo. Isso faz com que mensagens não sejam enviadas para o dispositivo de destino, mas (i)

para o atacante, (ii) como parte de um ataque DoS, ou simplesmente (iii) evitando que as mensagens

cheguem ao seu destinatário (JARA et al., 2011).

39

Em Nguyen, Al-Saffar e Huh (2010), são abordados dois outros tipos de ataques na IoT: o

ataque de chave compartilhada (shared-key attack) e o ataque sybil. Em Nguyen, Al-Saffar e Huh

(2010), é descrita uma técnica de autenticação que é baseada em um mecanismo de distribuição de

chaves. Basicamente, cada dispositivo do ambiente recebe material criptográfico, chamado de espaço

de chaves, para poder fazer a negociação de chaves de sessão com outros dispositivos. O mecanismo

de autenticação funciona com base na probabilidade de que dois dispositivos compartilhem o mesmo

espaço de chaves, o que significa que estes conseguirão negociar uma chave de sessão simétrica. Assim,

no ataque de chave compartilhada, o atacante conhece o mecanismo de distribuição de chaves do

ambiente e, sabendo que dois nós estão próximos, supõe que estes compartilhem um mesmo espaço de

chaves. O ataque ocorre quando a chave compartilhada pelos dispositivos também pode ser inferida

pelo atacante, comprometendo a segurança do sistema. O ataque sybil é caracterizado quando um nó

malicioso assume múltiplas identidades falsas com o objetivo de roubar ou forjar a identidade de um

nó legítimo. Em Nguyen, Al-Saffar e Huh (2010), é descrito um cenário de IoT em que esse ataque

pode ocorrer nas situações em que um dispositivo troca de domínio de segurança.

Por fim, Liu, Xiao e Chen (2012) ressaltam a existência do ataque de controle de chaves

(key control attack), no qual uma dos participantes da comunicação força os demais participantes

a escolherem chaves criptográficas dentro de um conjunto restrito de valores ou mesmo um valor

pré-determinado. Desta forma, o atacante influencia o processo de escolha de chaves criptográficas

para facilitar a obtenção do controle sobre os dados trafegados.

2.2.3 Gestão de Identidades Digitais na Internet das Coisas

Uma identidade, no mundo digital, é representada por um conjunto de atributos. Esses atributos

podem ou não ser certificados (verificados e endossados) por uma terceira parte. Um indivíduo pode ter

um conjunto de identidades, que são compostas de diferentes conjuntos de atributos. O ciclo de vida de

uma identidade consiste de seu registro, armazenamento, recuperação, provisionamento e revogação

de atributos da identidade (BHARGAV-SPANTZEL et al., 2007).

Conforme ITU (2009), a gestão de identidades (Identity Management – IdM), pode ser enten-

dida como o conjunto de processos e tecnologias usados para garantir a identidade de uma entidade ou

de um objeto, garantir a qualidade das informações de uma identidade (identificadores, credenciais e

atributos) e para prover procedimentos de autenticação, autorização, contabilização e auditoria.

As entidades envolvidas em um sistema de IdM manipulam a identidade de indivíduos ao

40

longo do ciclo de vida da identidade. Um sistema de IdM possui três entidades principais, a saber

(BHARGAV-SPANTZEL et al., 2007):

• Provedor de Identidade (Identity Provider - IdP): responsável por gerar identidades, manter

a base de dados de usuários do domínio e validar suas credenciais (autenticar usuários);

• Provedor de Serviço (Service Provider - SP): oferece recursos ou serviços aos usuários; e

• Usuário ou dispositivo: utiliza um serviço fornecido por um SP.

É possível implantar a IdM por meio do uso de uma infraestrutura de autenticação e de

autorização (Authentication and Authorization Infrastructure – AAI). Esta infraestrutura é conhecida

como o elemento central para prover a segurança e lidar com problemas de segurança em aplicações

distribuídas (LOPEZ; OPPLIGER; PERNUL, 2004). Com a implantação da IdM, é possível impedir o

acesso de usuários não autorizados aos recursos que se deseja proteger. Também é possível impedir que

usuários legítimos (autenticados) acessem recursos que estes não estão autorizados, além de permitir

que usuários legítimos acessem os recursos que estes tem autorização (LIU; XIAO; CHEN, 2012).

2.2.3.1 Modelos de Gestão de Identidades Digitais

Para Bhargav-Spantzel et al. (2007), a evolução dos sistemas de gestão de identidades passou

por quatro modelos distintos: tradicional, centralizado, federado e centrado no usuário.

No modelo tradicional, o SP provê o serviço solicitado e atua como IdP do usuário. É respon-

sabilidade do SP fazer o gerenciamento das credenciais dos usuários e do contexto em que estas são

usadas. Nesse modelo, o usuário possui um identificador e credenciais únicas para cada SP que acessa

e não há compartilhamento de identidades entre organizações (BHARGAV-SPANTZEL et al., 2007;

JØSANG; POPE, 2005).

Segundo Jøsang e Pope (2005), o uso do modelo tradicional tende a ser mais simples para o SP.

Contudo, conforme Wangham et al. (2010), o uso deste modelo tende a ser custoso para os usuários e

para os SPs. Para os usuários, o custo reside em gerenciar inúmeras identidades. Dentre os problemas,

está ter que fornecer as mesmas informações diversas vezes para diferentes SPs e ter que se preocupar

em criar (e manter) credenciais diferentes para cada SP. Para os SPs, além do custo de manutenção

de uma base de usuários, há o problema de que, em função da tarefa onerosa de sempre fornecer as

mesmas informações para criação de sua identidade, o usuário pode não ser fiel no preenchimento de

41

atributos que não são cruciais para acessar o recurso oferecido pelo SP. Um exemplo de aplicação que

utiliza este modelo é o sistema de gestão de conferências EDAS9.

O modelo centralizado tenta resolver o problema de múltiplas identidades do usuário para

diferentes SPs e da possível inconsistência de informações de identidade por meio da utilização de

apenas um IdP. Assim, existe um IdP central que cria e mantém as informações de identidade do

usuário, no qual usuários e SPs devem confiar. Existe um compartilhamento de identidades dos usuários

entre SPs e é aplicado o conceito de autenticação única (SSO). Uma vantagem desse modelo é que o

usuário pode autenticar-se apenas uma vez e usufruir dessa autenticação em todos os SPs que utilizar.

Entre as desvantagens, estão o fato de que o IdP é um ponto único de falha e, por ser o único detentor

das informações do usuário, pode fazer o que bem entender com elas (BHARGAV-SPANTZEL et al.,

2007; WANGHAM et al., 2010). Um exemplo de uso deste modelo é o portal de serviços do Banco do

Brasil10, em que múltiplos serviços bancários podem ser acessados diante de uma única autenticação.

O modelo federado distribui a tarefa de autenticação por IdPs distintos, localizados em domínios

administrativos de segurança diferentes. Para que a identidade emitida e verificada por um IdP seja

aceita em outro domínio administrativo, devem existir acordos de confiança estabelecidos entre IdPs e

SPs. A partir do estabelecimento de tais acordos, forma-se uma federação entre SPs e IdPs. Logo, o

modelo federado também permite a autenticação única, pois um identificador de um domínio (antes

aceito apenas no domínio em que foi criado) torna-se um identificador único na federação, que é

aceito pelos IdPs e SPs que a compõe (WANGHAM et al., 2010; BHARGAV-SPANTZEL et al.,

2007; JØSANG et al., 2005). Uma vantagem do modelo federado é que este resolve o problema

do ponto único de falha do IdP, já que a tarefa de autenticação é distribuída. O modelo também

consegue oferecer facilidades para os usuários, pois evita que estes tenham que lidar com diversas

identidades e permite a autenticação única. Para os SPs, o benefício é que estes poderão lidar com um

número menor de usuários temporários. Contudo, uma desvantagem é em relação à falta de controle

do usuário acerca das credenciais, já que estas são controladas pelos IdPs (WANGHAM et al., 2010;

BHARGAV-SPANTZEL et al., 2007; JØSANG et al., 2005). Um exemplo do uso deste modelo é a

Federação CAFe11.

Tanto no modelo centralizado como no modelo federado existe a falta de controle do usuário so-

bre as informações disponibilizadas aos IdPs, haja vista que o IdP fica sob controle de tais informações

e pode disponibilizá-las a terceiros. Nesse sentido, surgiu o modelo de gestão de identidades centrado9 https://edas.info/10 bb.b.br11 http://portal.rnp.br/web/servicos/cafe

42

no usuário, que tem por objetivo dar maior controle ao usuário sobre as transações envolvendo os seus

dados de identidade (BHARGAV-SPANTZEL et al., 2007; WANGHAM et al., 2010). Implementações

desse modelo são feitas tendo como base um dos modelos apresentados anteriormente, sendo o modelo

de identidades federadas o mais usado. Em implementações desse modelo, verifica-se que se objetiva

devolver o poder ao usuário em relação à posse das informações de identidade, e que a liberação destas

para um SP fica condicionada ao desejo do usuário, obedecendo assim aos seus desejos de privacidade

(WANGHAM et al., 2010). Uma aplicação que utiliza este modelo é descrita em Maçaneiro (2013).

Conforme Wangham, Domenech e Mello (2013), na IoT, os modelos de IdM mais utiliza-

dos são o centralizado e o federado, em soluções acadêmicas e comerciais. Determinados tipos de

aplicações permitem o uso de infraestruturas centralizadas. Contudo, devido às características da

IoT, na qual usuários e dispositivos podem estar em domínios administrativos diferentes, o uso do

modelo centralizado pode não ser adequado, pois neste caso é necessário que exista um provedor de

identidades amplamente aceito, o que nem sempre ocorre (LIU; XIAO; CHEN, 2012). Em função

destas características, o modelo de gestão de identidades federadas mostra-se mais adequado à IoT

(AKRAM; HOFFMANN, 2008b; LIU; XIAO; CHEN, 2012).

2.2.3.2 Autenticação na Internet das Coisas

O serviço de autenticação trata da garantia de que a entidade com a qual está-se comunicando

é aquela que ela afirma ser. Dois serviços de autenticação são definidos na recomendação X.80012: (i)

autenticação da entidade par e (ii) autenticação da origem de dados. No primeiro serviço é provida

a confirmação da identidade de uma entidade par de uma associação. O objetivo é garantir que uma

entidade não está disfarçada ou realizando uma repetição não autorizada de uma conexão anterior.

No segundo serviço, é provida a confirmação da origem de dados, ou seja, o objetivo é garantir

que a entidade que enviou os dados é aquela que é alegada como remetente (STALLINGS, 2008).

Logo, a autenticação é uma premissa para os processos de autorização, haja vista que uma decisão de

autorização depende da garantia de que aquele que está sendo autorizado realmente é quem diz ser.

No cenário da IoT, os dispositivos podem pertencer a mais de uma rede ou domínio administra-

tivo, cenário que Horrow e Sardana (2012) chamam de Internetwork of Things. Esta situação pode

afetar o funcionamento dos procedimentos de autenticação e de autorização, em função da mobilidade

destes dispositivos entre redes diferentes.12 http://www.itu.int/rec/T-REC-X.800-199103-I/en

43

Em Wangham, Domenech e Mello (2013, p. 172) é ressaltado que, na literatura, a autenticação

na IoT é tratada de forma diferente para usuários e para dispositivos. Na IoT, usuários interagem com

muitos dispositivos inteligentes ou SPs para obter algum serviço útil para eles. Para que um usuário

acesse um objeto/dispositivo na IoT, muitas vezes, é necessário que este passe por um processo de

autenticação.

Uma análise sobre os modelos de autenticação utilizados para autenticar usuários na IoT é

conduzida em Wangham, Domenech e Mello (2013). Percebe-se a existência dos seguintes modelos:

• Autenticação Centralizada baseada em uma terceira parte confiável. Uma entidade central

(IdP ou KDC - Key Distribution Center) é responsável por criar a identidade do usuário

e autenticá-lo, sendo que os SPs que o usuário acessar devem confiar nessa autenticação.

Em Li, Wang e Deng (2010) é proposto o uso do LDAP em conjunto com o mecanismo

de autenticação Kerberos, de modo a prover autenticação única para usuários na IoT. Em

Konidala et al. (2005), o usuário deve registrar-se inicialmente em um servidor central (AS),

o qual é confiável para o usuário e para o SP. Para acessar o SP, o usuário autentica-se no

AS e recebe um token assinado por este, o qual deve ser apresentado ao SP na tentativa de

acesso. O SP verifica a assinatura digital do token antes de conceder o acesso;

• Criptografia de chave pública. Uma chave privada, correspondente a uma chave pública

(normalmente presente em um certificado digital), garante a autenticidade dos usuários

diante dos dispositivos. A criptografia de chave pública pode ser utilizada para garantir a

autenticidade da entidade par e a autenticidade de origem das mensagens. Um exemplo

pode ser encontrado em (ROTONDI; SECCIA; PICCIONE, 2011); e

• Modelo de gestão de identidades federadas. Este modelo é mais adequado à IoT do que o

modelo centralizado, já que na IoT nem sempre o cliente e o SP estão no mesmo domínio

administrativo e, portanto, não confiam no mesmo IdP (AKRAM; HOFFMANN, 2008b;

LIU; XIAO; CHEN, 2012). Em Liu, Xiao e Chen (2012) é proposto um mecanismo de

autenticação de usuários que segue este modelo. Em Akram e Hoffmann (2008b) o OpenID13

é destacado como uma das soluções de IdM usadas no Hydra Middleware14.

Em Wangham, Domenech e Mello (2013) também é feita uma análise dos modelos utilizados

para autenticar dispositivos na IoT, em que é possível perceber o uso dos seguintes modelos:13 http://openid.net/14 http://www.hydramiddleware.eu/

44

• Criptografia de chave pública com auxílio de um KDC. Nesse modelo, descrito em Mahalle

et al. (2012), o KDC é considerado confiável e auxilia os dispositivos gerando e distribuindo

chaves assimétricas com base em um protocolo ECC. Quando dois dispositivos desejam se

comunicar, estes utilizam o protocolo ECCDH para estabelecimento de uma chave de sessão,

com base no par de chaves de cada dispositivo. Após isso, um protocolo de desafio-resposta

é conduzido, para que a autenticação unidirecional ou mútua seja realizada;

• Certificados Digitais. Os dispositivos se autenticam utilizando certificados digitais. Um

exemplo é descrito em Kothmayr et al. (2012), em que uma arquitetura de segurança para

IoT é construída com base no protocolo DTLS. Dois cenários são descritos, um em que

os dispositivos possuem um hardware TPM (Tamper Proof Module) e outro em que os

dispositivos não possuem. No primeiro caso, os dispositivos estabelecem um canal seguro

DTLS e se autenticam mutuamente por meio de certificados X.509, emitidos por uma AC

reconhecida por ambos. No segundo caso, um servidor de controle de acesso (terceira parte

confiável) é utilizado para intermediar o processo de autenticação entre os dispositivos.

Neste sentido, em Hummen et al. (2013) são descritas alterações que podem ser feitas

no handshake do protocolo DTLS para viabilizar seu uso em cenários da IoT em que

dispositivos com restrições computacionais são utilizados;

• Criptografia simétrica. Uma chave criptográfica simétrica, compartilhada entre o dispositivo

de origem e destino, é utilizada para a autenticação mútua. Este modelo é utilizado em

Jara et al. (2011), em que é proposto um esquema de gestão de mobilidade segura para

dispositivos que fazem uso do protocolo 6LoWPAN e que atravessam diferentes domínios

administrativos. Neste trabalho, a autenticação das mensagens trocadas entre um dispositivo

e seu gateway usa criptografia simétrica; e

• Uso de métodos tradicionais de autenticação com o auxílio de um nó intermediário. Neste

modelo, os dispositivos com restrição da IoT podem se beneficiar das mesmas funcionalida-

des de segurança que são típicos de domínios sem restrições (Internet) sem, contudo, ter

que executar operações computacionalmente intensivas para estes dispositivos. Para que

isso seja possível, utiliza-se um nó confiável sem restrições computacionais (gateway) para

assumir as tarefas intensivas de computação. Um exemplo dessa abordagem utilizando o

protocolo EAP é descrito em Bonetto et al. (2012).

45

2.2.3.3 Autorização na Internet das Coisas

A segurança requer que ações em um sistema computacional possam ser atribuídas a indivíduos.

Os processos envolvidos no estabelecimento da identidade de um indivíduo são a identificação e

autenticação. O primeiro trata do processo em que o usuário afirma quem é, e o segundo trata do

processo em que evidências são providas acerca da validade da afirmação de identidade. A partir do

estabelecimento da identidade é possível decidir se uma determinada ação sobre um determinado

objeto é permitida ou não, processo conhecido como autorização. Logo, a autenticação, que permite

garantir a identidade de um indivíduo, é um pré-requisito para que decisões de autorização possam ser

tomadas corretamente (LANDWEHR, 2001).

Uma decisão de autorização é tomada como base para o processo de controle de acesso. O

controle de acesso limita o escopo das ações que um indivíduo, ou entidades em seu nome, podem

realizar em um sistema computacional. A Figura 1 apresenta o esquema básico do controle de acesso

exercido por meio em um sistema computacional (LENTO; FRAGA; LUNG, 2006).

Figura 1. Controle de Acesso

Fonte: Lento, Fraga e Lung (2006).

O Monitor de Referência (ANDERSON, 1972) define os mecanismos utilizados na efetivação

do controle de acesso. Segundo Lento, Fraga e Lung (2006), o monitor de referência atua como

intermediário nas tentativas de acesso de qualquer sujeito à qualquer objeto protegido. O monitor

de referência faz isto por meio da consulta às políticas de segurança, que são administradas pelo

administrador do sistema.

Conforme Lento, Fraga e Lung (2006) "Os modelos de segurança correspondem a descrições

formais do comportamento de um sistema atuando segundo regras de uma política de segurança".

46

Logo, a definição de políticas de segurança é normalmente orientada por modelos de segurança. A

seguir são descritos os modelos de segurança mais relevantes para este trabalho.

O controle de acesso discricionário (Discretionary Access Control – DAC) delega aos usuários

a tarefa de proteger seus recursos no sistema. Duas abordagens tradicionais para o DAC são as listas de

controle de acesso (Access Control List – ACL) e as listas de competências (ou listas de habilidades)

(LENTO; FRAGA; LUNG, 2006).

No modelo de ACL, a cada objeto é associada uma lista que contém os sujeitos com o acesso

autorizado ao objeto. Apesar de ser simples e bastante flexível, o modelo de ACL é custoso para

manutenção, quando aumenta o número de objetos protegidos ou de usuários. Nestes casos, atividades

como revogação de direitos de acesso podem ser bastante custosas (LENTO; FRAGA; LUNG, 2006;

WANGHAM; DOMENECH; MELLO, 2013). Na IoT, o modelo de ACL é utilizado no mecanismo

proposto em Guinard, Fischer e Trifa (2010), o qual integra a WoT com redes sociais.

Na abordagem de listas de competências (Capability Based Access Control – CapBAC), cada

sujeito possui uma lista que indica quais direitos de acesso o sujeito possui para cada objeto protegido

do sistema. A competência, ou habilidade, é um token, que dá direito aquele que a possui de acessar os

objetos descritos na habilidade. Assim, o token pode ser passado de um sujeito para outro, dando ao

recebedor os respectivos direitos de acesso. Este modelo oferece facilidades às operações de verificação

e revogação de direitos de acesso e também boa escalabilidade, uma vez que não é preciso confrontar a

identidade do usuário com uma lista de controle de acesso. Neste modelo, tem-se um número menor de

informações armazenadas na entidade responsável por aplicar o controle de acesso (LENTO; FRAGA;

LUNG, 2006; WANGHAM; DOMENECH; MELLO, 2013). Aplicações do CapBAC na IoT são

realizadas em Rotondi, Seccia e Piccione (2011), Mahalle et al. (2012) e Mahalle et al. (2013).

O modelo de controle de acesso baseado em papéis (Role Based Access Control – RBAC),

regula o acesso dos usuários com base nas atividades executadas e não com base nas identidades dos

usuários. O modelo funciona com base em papéis, definidos de acordo com as atividades associadas a

um cargo ou função. Aos papéis são associadas as regras de acesso e os usuários são associados aos

papéis. O RBAC é amplamente aceito na Internet por sua simplicidade para gerenciar permissões e

usuários (LENTO; FRAGA; LUNG, 2006; WANGHAM; DOMENECH; MELLO, 2013). O RBAC é

utilizado na IoT em Liu, Xiao e Chen (2012), Jindou, Xiaofeng e Cheng (2012) e Souza et al. (2008).

No modelo de controle de acesso baseado em atributos (Attribute Based Access Control –

ABAC), a tomada de decisão de autorização é feita por meio da avaliação de atributos de sujeitos

47

e objetos, das operações que o sujeito deseja realizar sobre o objeto e das condições do ambiente.

Isso permite que se garanta o acesso de sujeitos a objetos sem a necessidade de especificar relações

individuais entre estes e sem precisar conhecer a priori os objetos e sujeitos individualmente. Sistemas

que implementam o ABAC são capazes de implementar o DAC e o MAC (HU et al., 2014). O ABAC

é utilizado no cenário da IoT em Han e Li (2012) e Zhang e Liu (2011), em que adaptações são feitas

para adequá-lo ao cenário da aplicação.

O modelo de controle de acesso baseado em políticas (Policy Based Access Control – PBAC),

pode ser entendido como uma padronização e harmonização do ABAC em um nível empresarial,

capaz de suportar objetivos de governança específicos, como por exemplo, a adequação de toda

uma organização a uma política de controle de acesso que atende a um determinado requisito legal.

Enquanto no ABAC as decisões de controle de acesso são tomadas localmente, com base nas políticas

de controle de acesso locais (p.e. de uma filial), o PBAC leva em consideração as políticas globais da

organização. O modelo ainda leva em consideração os atributos utilizados no ABAC, contudo possui

uma maior orientação a políticas (NIST, 2009).

Conforme observado em Wangham, Domenech e Mello (2013), no contexto da IoT, os meca-

nismos de autorização implantam modelos de controle de acesso já empregados na Internet clássica,

como ACL, CapBAC, RBAC e ABAC. Em alguns casos, como foi mencionado nesta seção, estes

modelos podem sofrer adaptações para atender aos requisitos de uma determinada aplicação. Contudo,

tais adaptações normalmente não alteram o modelo propriamente dito.

2.2.4 Especificações de Segurança para XML e Serviços Web

Esta seção apresenta as especificações de segurança para XML e para Serviços Web mais

relevantes para este trabalho. No contexto de segurança para XML, são apresentadas as especificações

SAML e XACML. No contexto de segurança para Serviços Web, é apresentada a especificação

WS-Policy.

2.2.4.1 SAML

O padrão SAML, desenvolvido pela OASIS15, define um framework baseado em XML para

a troca de informações de segurança entre parceiros de negócio. Essas informações de segurança

são expressas através de asserções SAML portáveis entre os sistemas participantes. Tais sistemas,15 https://www.oasis-open.org

48

localizados em domínios de segurança distintos, podem confiar nas asserções trocadas entre si, sendo

possível a troca de informações de atributos, autenticação e autorização acerca de um sujeito. Para

isso, o padrão SAML define uma sintaxe precisa e regras para requisição, criação, comunicação e uso

das asserções SAML (OASIS, 2008).

Um dos motivos para adoção do SAML é que este possui mecanismos que permitem a

implementação do conceito de identidades federadas, que é útil caso os parceiros de negócio desejem

oferecer um ambiente de aplicação colaborativo para seus usuários em comum. Neste caso, deve haver

um entendimento sobre quem é o usuário referenciado nas informações de segurança trocadas entre

esses parceiros, que comumente é estabelecido por meio de um identificador compartilhado. Caso haja

essa referência comum para um mesmo usuário em domínios distintos, é dito que sua identidade é

federada (OASIS, 2008).

Outro aspecto que favorece a adoção do SAML é que este permite que suas asserções sejam

utilizadas em ambientes que não usam os protocolos SAML. A vantagem no uso dessas asserções é

que o SAML padroniza a troca de informações de segurança, como atributos de um sujeito, os quais

não são facilmente transmitidos através de outros formatos (p.e. os tokens do padrão WS-Security).

Essa modularidade é útil no desenvolvimento de mecanismos que abordam serviços de autorização e

frameworks de IdM (OASIS, 2008).

A arquitetura do SAML possui componentes que permitem atender a diversos casos de uso

diferentes. Os conceitos básicos da arquitetura do SAML são (OASIS, 2008):

• Asserções (Assertions): carregam sentenças sobre um sujeito que uma Asserting Party

afirma que são verdadeiras, sendo que sua estrutura e conteúdo são definidos por um XML

Schema;

• Protocolos (Protocols): as mensagens de um protocolo SAML são utilizadas para requisi-

ção/resposta e sua estrutura e conteúdos são definidos por um XML Schema;

• Ligações (Bindings): define como as mensagens de um protocolo SAML são transportadas

entre os participantes por meio de um determinado protocolo de comunicação;

• Perfis (Profiles): definem restrições ao conteúdo das asserções, protocolos e bindings, com

a intenção de atender a um caso de uso específico, visando a interoperabilidade;

• Contexto de Autenticação (Authentication Context): serve para expressar informações de-

talhadas sobre o tipo e força da autenticação realizada por um sujeito em um IdP, podendo

49

ser carregado dentro de uma asserção ou referenciado por ela. Pode também ser incluído

como parte da requisição por uma asserção, quando o SP informa ao IdP o tipo e força da

autenticação que o sujeito deve realizar para que a asserção seja aceita; e

• Metadados (Metadata): define uma maneira de expressar e compartilhar as informações

de configuração entre entidades SAML. Expressa, por exemplo, os bindings suportados e

informações de identificação e material criptográfico, por meio de um XML Schema.

As asserções SAML podem carregar três tipos de sentenças, a saber (OASIS, 2009a):

• Sentenças de Autenticação: afirmando, no mínimo, os meios utilizados por uma entidade

para autenticar um sujeito e quando isso foi feito;

• Sentenças de Atributos: afirmam sobre um determinado atributo do usuário, como por

exemplo, que o usuário desempenha um papel em uma organização; e

• Sentenças de Autorização: fazem afirmações acerca de alguma ação que o sujeito está

autorizado a fazer.

O SAML define também protocolos de requisição-resposta genéricos. Dentre os protocolos,

pode-se destacar: (i) o Authentication Request Protocol, que define como um sujeito pode fazer a

requisição de asserções contendo sentenças sobre autenticação e/ou atributos; (ii) o Assertion Query

and Request Protocol, que define um conjunto de consultas pelas quais uma asserção SAML pode ser

obtida, por meio da sua ID ou do sujeito envolvido; e (iii) o Artifact Resolution Protocol, que provê um

mecanismo pelo qual as mensagens SAML podem ser passadas por referência, utilizando um campo

curto e de tamanho fixo chamado artifact (OASIS, 2009a).

Os bindings do padrão SAML definem como as mensagens de protocolo SAML podem ser

transportadas por outros protocolos. Dentre os bindings disponíveis, destacam-se (i) aqueles utilizados

para troca de mensagens SAML utilizando como protocolo de transporte o HTTP (HTTP Redirect

Binding, HTTP POST Binding e HTTP Artifact Binding), e (ii) os bindings que utilizam mensagens

SOAP para o transporte de mensagens SAML (Reverse SOAP (PAOS) Binding e SAML SOAP Binding)

(OASIS, 2009b).

Conforme mencionado, os perfis SAML são combinações de asserções, bindings e protocolos

com algumas restrições, feitas a fim de favorecer a interoperabilidade em um cenário de uso específico.

50

Os perfis SAML mais relevantes no contexto deste trabalho são aqueles que proveem a autenticação

única, a saber (OASIS, 2009d):

• Web Browser SSO Profile: define como prover a autenticação única para clientes que fazem

uso de navegadores Web padrão, usando bindings baseados no protocolo HTTP; e

• Enhanced Client and Proxy (ECP) Profile: define um perfil de autenticação única em que

clientes especializados ou proxies podem utilizar os bindings baseados no SOAP e interme-

diar a troca de mensagens entre SP e IdP.

O perfil Web Browser SSO permite que um usuário, por meio de um navegador Web padrão,

acesse um recurso em um SP, ou acesse um IdP de modo que o SP e o recurso que deseja acessar

estão implícitos. O usuário deve se autenticar no IdP, o qual gera uma asserção de autenticação que é

consumida pelo SP, permitindo que este estabeleça um contexto de segurança para o cliente. Para a

implementação desse perfil, o protocolo SAML Authentication Request é utilizado em conjunto com

o binding HTTP Redirect, HTTP POST ou HTTP Artifact. Assume-se, ainda, que o usuário é capaz

de se autenticar no IdP utilizando algum mecanismo de autenticação, o qual está fora do escopo da

especificação SAML (OASIS, 2009d).

O perfil ECP possui como premissa a presença de um ECP no cenário. Um ECP é uma entidade

do sistema que sabe como contatar o IdP apropriado para determinada operação e suporta o binding

Reverse SOAP (PAOS). O perfil ECP dá suporte ao cenário em que um cliente, por meio de um ECP,

tenta acessar um recurso em um SP, ou acessa um IdP de modo que o recurso e o SP que o cliente

deseja acessar estão implícitos. O cliente se autentica no IdP, que produz uma asserção de autenticação.

O SP consome esta asserção e estabelece seu próprio contexto de segurança para o cliente. Para a

implementação desse perfil, o protocolo SAML Authentication Request é utilizado em conjunto com o

binding Reverse SOAP (PAOS). Neste contexto, o ECP é visto como um SOAP intermediary entre o

SP e o IdP, responsável por encaminhar as mensagens entre as entidades e processar os cabeçalhos

SOAP adicionais que são necessários (OASIS, 2009d).

2.2.4.2 XACML

O XACML (eXtensible Access Control Markup Language) é uma linguagem baseada em

XML para a descrição de políticas de autorização e para requisição/resposta de decisões de controle

de acesso (OASIS, 2003). O XACML permite basear a decisão de autorização em características do

51

sujeito ou do recurso que o sujeito irá acessar, não apenas na identidade destes. Isto é possível por

meio de mecanismos de identificação única de atributos de recursos e de sujeitos. Também é possível

embasar uma decisão de autorização no conteúdo de um recurso. Além disso, o XACML provê um

conjunto de operadores lógicos e matemáticos que operam sobre tais atributos (OASIS, 2013a).

O XACML permite ainda que as políticas sejam escritas por diferentes autores, armazenadas em

locais diferentes e aplicadas (enforced) em locais diferentes. Contudo, muitas vezes o PEP (responsável

por aplicar a decisão de autorização) está em sistemas que não “falam” XACML e os atributos utilizados

para tomada de decisão (feita pelo PDP) podem estar em outros formatos, enquanto que o XACML é a

linguagem utilizada pelo PDP para troca de mensagens e descrição das políticas de autorização. Isso é

resolvido no XACML por meio de um passo intermediário de conversão do formato entendido pelo

PEP para o formato entendido pelo PDP, e vice-versa (OASIS, 2013a).

Figura 2. Modelo de Fluxo de dados do XACML

Fonte: Adaptada de OASIS (2013a).

Conforme OASIS (2013a), a especificação XACML provê um modelo de fluxo de dados, o

qual descreve como os dados referentes à tomada de decisão de autorização fluem entre as entidades

previstas no modelo. Este modelo é mostrado na Figura 2 e é descrito a seguir. (1) O PAP escreve

52

políticas e os disponibiliza ao PDP; (2) O requisitante de acesso solicita acesso ao PEP; (3) O PEP

envia a requisição de acesso ao manipulador de contexto (context handler) no formato original da

requisição; (4) O manipulador de contexto constrói uma requisição no formato XACML (contexto

XACML) e envia ao PDP; (5) O PDP requisita (se necessário) ao manipulador de contexto atributos

adicionais de sujeitos, recursos, ações e do ambiente; (6) O manipulador de contexto requisita os

atributos ao PIP; (7) O PIP obtém os atributos solicitados; (8) O PIP retorna os atributos solicitados

ao manipulador de contexto; (9 - Opcional) O manipulador de contexto inclui no contexto o próprio

recurso; (10) O manipulador de contexto envia os atributos requisitados e (opcionalmente) o próprio

recurso ao PDP. O PDP avalia a política; (11) O PDP retorna o contexto de resposta (inclui a decisão

de autorização) ao manipulador de contexto; (12) O manipulador de contexto traduz o contexto de

resposta para o formato nativo de resposta do PEP e envia a resposta a este; (13) O PEP atende às

obrigações (XACML Obligations); (14 - Não mostrado) Se o acesso for permitido, o PEP permite o

acesso ao recurso; Caso contrário, o acesso é negado.

2.2.4.3 WS-Policy

Segundo W3C (2007), o Framework Web Services Policy 1.5, também conhecido como WS-

Policy, provê um modelo de propósito geral e uma sintaxe para descrição de políticas de entidades

em um sistema baseado em Serviços Web. Essas políticas se referem a habilidades, requisitos e

características gerais das entidades citadas.

Basicamente, uma política é uma coleção de alternativas de políticas. Uma alternativa de

política é uma coleção de asserções de políticas. Uma asserção de política representa um requisito,

habilidade ou outra propriedade de um comportamento de uma entidade de um sistema baseado em

Serviços Web. Uma expressão de política é uma representação da política feita na linguagem XML

Infoset16 (W3C, 2007).

Aplicado ao cenário de sistemas baseados em Serviços Web, uma política pode ser utilizada

para transportar condições de uma interação entre entidades (p.e. aplicação requisitante, SP, etc.). Como

uma interação envolve uma ou mais trocas de mensagens entre duas entidades, é responsabilidade do

autor da asserção definir o escopo desta, o que inclui definir restrições em relação a quais sujeitos e a

quais mensagens de uma interação a asserção pode ser aplicada. Do mesmo modo, qualquer entidade

em um sistema baseado em Serviços Web pode usar uma política para expor as condições sob as

quais a entidade funciona. Por exemplo, se duas entidades, um requisitante e um provedor, expõe suas16 http://www.w3.org/TR/xml-infoset/

53

políticas conforme descrito anteriormente, o requisitante pode utilizar a política do provedor para

decidir se deve ou não utilizar o serviço oferecido (W3C, 2007).

2.3 CONSIDERAÇÕES

Ao comparar o cenário da IoT com os cenários computacionais tradicionais, tornam-se claras as

diferenças entre estes. Tais diferenças, exemplificadas principalmente pelas restrições computacionais

e de energia dos dispositivos, bem como pela heterogeneidade de dispositivos e tecnologias, levam a

diversos desafios. Dentre tais desafios destacam-se aqueles relacionados à garantia das propriedades

de segurança computacional (confidencialidade, integridade, disponibilidade, autenticidade e não-

repúdio) para dispositivos e para a comunicação destes com outros sistemas computacionais. Também

destacam-se os desafios relacionados à interoperabilidade entre os próprios dispositivos e entre estes e

os sistemas computacionais já existentes na Internet.

Diante desse cenário, a WoT mostra-se uma abordagem interessante para ambos os desafios. O

fato da WoT trazer para a IoT os recursos já utilizados na Web atual, como o uso de navegadores Web,

URIs e o protocolo HTTP, permite abordar a interoperabilidade entre os sistemas da Web e os sistemas

da IoT de uma maneira simples e direta, uma vez que as ferramentas da Web podem ser reaproveitadas

no cenário da IoT.

Em relação à segurança dos dispositivos, da comunicação entre estes e da comunicação entre

dispositivos e sistemas computacionais da Internet atual, também podem ser utilizadas abordagens

existentes na Web atual. Esse reaproveitamento favorece o desenvolvimento de soluções seguras para

a IoT, uma vez que estas são baseadas em padrões já consolidados da Web. Também é favorecida a

interoperabilidade entre soluções de segurança da Web atual com as soluções de segurança da IoT,

uma vez que as últimas são baseadas nas primeiras.

Assim, ao vislumbrar a IoT como parte da Internet atual, é bastante coerente perseguir a

interoperabilidade com a Web. Diante disso, uma opção que favorece essa integração é basear as

soluções de segurança da WoT em soluções de segurança já consolidadas na Web atual, ou seja, buscar

a interoperabilidade com padrões da Web.

Neste capítulo, foi apresentada a IoT e a WoT, bem como as questões de segurança que

permeiam esses conceitos. Foi abordada também a gestão de identidades digitais como um tópico

relevante, que deve ser considerado em soluções que procurem atender aos requisitos de segurança de

determinados cenários da IoT. Foram apresentadas algumas especificações de segurança para XML e

54

Serviços Web, que são utilizadas na Web atual. Tais tópicos formam a base conceitual deste trabalho,

bem como a base para entender como o trabalho se relaciona com os trabalhos descritos no próximo

capítulo.

55

3 TRABALHOS RELACIONADOS

Este capítulo apresenta os trabalhos correlatos encontrados na literatura que abordam a gestão

de identidades na Internet das Coisas e na Web das Coisas. Mais especificamente, são apresentados os

trabalhos que tratam dos processos de autenticação, autorização e controle de acesso de usuários e de

dispositivos, por meio de propostas de infraestruturas de autenticação e/ou autorização. Ao final do

capítulo, é feita a comparação dos trabalhos descritos com este trabalho.

A escolha dos trabalhos foi feita com base em uma revisão sistemática da literatura, a qual foi

realizada em sete bases de busca para trabalhos publicados entre 2005 e 2014. Esta revisão sistemática

da literatura foi realizada conforme o protocolo de busca descrito no Apêndice A.

3.1 AKRAM E HOFFMANN (2008C)

O framework de IdM apresentado em Akram e Hoffmann (2008b) é parte integrante do Hydra

Middleware (LinkSmart Middleware) 1. O objetivo do framework é abstrair dos desenvolvedores os

mecanismos de IdM utilizados em suas aplicações em ambientes federados. O Hydra Middleware é

baseado em WS-* e utiliza os padrões WS-Security, WS-Trust, WS-Policy e WS-Federation (AKRAM;

HOFFMANN, 2008b).

O framework possui uma arquitetura híbrida, que usa o OpenID, o SAML e o Windows

CardSpace. Na Figura 3, que ilustra o framework proposto (HIM - Hydra Identity Manager), é

mostrado que no topo do WCF2 está o UIB (Universal Identity Bus), que provê interfaces para o

HIM. Por meio dessas interfaces, o UIB alimenta o HFE (Hydra Federation Engine) com serviços

como o "cross-matching"de diferentes tipos de tokens, protocolos e information cards (p.e. Windows

CardSpace e DigitalMe) (AKRAM; HOFFMANN, 2008b).

É o HFE que os desenvolvedores utilizam se precisam dos papéis de IdP, RP (Relying Party)

ou de sujeito, conforme os padrões OpenID e SAML, ou se precisam implementar o serviço de seleção

de identidades do Windows Cardspace. O HFE serve para que o desenvolvedor consiga implementar

uma federação baseada no Hydra Middleware (AKRAM; HOFFMANN, 2008b).

O Hydra Middleware trata da autenticação única de usuários por meio dos mecanismos1 http://www.hydramiddleware.eu/2 Windows Communication Foundation, framework utilizado para construção de Serviços Web seguros

56

Figura 3. Arquitetura do Hydra Identity Manager

Fonte: Adaptada de Akram e Hoffmann (2008b).

suportados (p.e. OpenID e SAML). A autorização é tratada para usuários com base no modelo

de controle de acesso baseado em contexto (Context Based Access Control – CBAC) (HOFFMANN et

al., 2010) . Contudo, a autenticação e autorização de dispositivos não é tratada. Vale ressaltar que, além

do modelo de gestão de identidades federadas, a abordagem também é centrada no usuário. Um dos

pontos que podem trazer dificuldades no uso do middleware na IoT, é que este é baseado nos padrões

WS-*, que não são adequados para o ambiente de IoT, conforme apresentado no Capítulo 2. Por fim, o

trabalho não descreve a implementação da proposta, mas pelos títulos dos Deliverables3 do projeto

(não acessíveis ao público), pode-se inferir que protótipos foram desenvolvidos.

3.2 ALAM, CHOWDHURY E NOLL (2011)

Em Alam, Chowdhury e Noll (2011) o objetivo é prover o acesso seguro a serviços na IoT e

a interoperabilidade semântica de atributos de segurança entre diferentes domínios administrativos,

uma vez que atributos de segurança de domínios diferentes normalmente são diferentes (p.e. papéis,

responsabilidades delegadas aos papéis e níveis de segurança).3 http://www.hydramiddleware.eu/articles.php?article_id=90

57

É proposto o uso de ontologias de sensores, de eventos no ambiente e das entidades de controle

de acesso. Desse modo, é possível fazer um mapeamento dos atributos de segurança de um domínio

para os atributos de outro domínio. Para utilizar isso no contexto de autorização de acesso são utilizadas

regras semânticas, baseadas nas ontologias, para expressar restrições de autorização, que são usadas

para tomar decisões de autorização. Assim, o framework proposto permite que o controle de acesso

em uma organização seja influenciado pelos mecanismos e modelos de controle de acesso utilizados

em outras organizações (domínios de segurança distintos), evitando ambiguidades e favorecendo uma

operação integrada entre domínios (ALAM; CHOWDHURY; NOLL, 2011).

O foco principal do trabalho é a autorização em um ambiente federado de IoT, em que é

proposto um mecanismo independente do modelo de controle de acesso que permite integrar atributos

de diferentes domínios, que atuam sobre uma mesma semântica. Contudo, a autenticação de usuários e

de dispositivos não foi abordada.

3.3 CONZON ET AL. (2012)

Em Conzon et al. (2012), é apresentado o VIRTUS, um middleware que possui o objetivo de

prover comunicação segura entre entidades em um cenário de IoT. O VIRTUS é baseado no XMPP

(SAINT-ANDRE, 2004), que é um protocolo baseado em XML usado na troca de mensagens em tempo

real, troca de informações de presença e serviços de requisição/resposta. O cenário abordado pelo

middleware é de usuários acessando dispositivos da IoT, por meio de dispositivos como smartphones.

O VIRTUS provê mecanismos de autenticação e de controle de acesso nativos do XMPP.

Na arquitetura, um dispositivo deve suportar os protocolos TLS (DIERKS; ALLEN, 1999) e SASL

(MELNIKOV; ZEILENGA, 2006). O TLS é utilizado para garantir a confidencialidade e integridade

dos dados transmitidos, enquanto que o SASL faz a autenticação de entidades por perfis específicos

XMPP, permitindo diversos mecanismos de autenticação, tais como login e senha, SAML, Kerberos e

certificados X.509. No caso da comunicação entre usuários e dispositivos localizados em domínios

diferentes, os servidores que implementam o VIRTUS devem estabelecer um canal seguro usando o

TLS e o SASL e, por meio desse canal seguro, entidades de domínios diferentes podem comunicar-se

(CONZON et al., 2012).

O trabalho trata principalmente da interoperabilidade de comunicação entre dispositivos e

usuários que utilizam tecnologias de comunicação diferentes, provendo essa interoperabilidade de

maneira segura. A autenticação de usuários que utilizam o middleware e servidores que implementam

58

o middleware é tratada, mas a autenticação única de usuários e a autenticação de dispositivos não é

abordada. A autorização para acesso aos dispositivos é feita utilizando o modelo de lista de controle

de acesso (ACL). Para isso, cada módulo do middleware que intermedia o acesso a determinado

dispositivo é configurado para (i) liberar o acesso ao recurso para requisições vindas de outros

domínios de segurança ou somente para requisições do mesmo domínio; e (ii) para permitir ou não

o acesso de determinado usuário ao recurso do dispositivo. Assim, a abordagem segue o modelo de

gestão de identidades tradicional. Portanto, caso o número de dispositivos de um domínio de segurança

aumente, pode haver um aumento expressivo da carga administrativa, uma vez que alterações nas

políticas de segurança devem ser realizadas individualmente nos recursos providos.

3.4 LIU, XIAO E CHEN (2012)

Em Liu, Xiao e Chen (2012) é proposta uma arquitetura para IoT baseada no OpenID, que trata

da autenticação e do controle de acesso em um ambiente federado, em que usuários de um domínio de

segurança consomem recursos de dispositivos de outro domínio. Na inicialização do sistema, cada

dispositivo deve se registrar em uma entidade confiável (Registration Authority – RA) de seu domínio,

que auxiliará no processo de autenticacão. A Figura 4 mostra a arquitetura proposta.

HRA

ObjetoUsuário

RA

Domínio de Segurança A

2

7

1

Domínio de Segurança B

5.2

5.1

6

5

34

Figura 4. Arquitetura da IoT e passo-a-passo do protocolo de autenticação

Fonte: Adaptada de Liu, Xiao e Chen (2012).

59

A autenticação do usuário no seu domínio de segurança, feita no HRA (Home Registration

Authority), pode ser aceita no domínio do RA (LIU; XIAO; CHEN, 2012), em função das relações de

confiança entre as entidades da federação. A sequência de passos do mecanismo é mostrada na Figura

4. No Passo 1, o usuário requisita acesso ao dispositivo, o qual envia a requisição de autenticação para

a RA em que se registrou, para que esta verifique a solicitação do usuário (Passo 2). A RA requisita ao

usuário a sua ID (Passo 3) e recebe como resposta do usuário a indicação da HRA de confiança deste

(Passo 4). No Passo 5, a RA verifica a informação recebida sobre a HRA e solicita a esta a verificação

da ID do usuário. Essa verificação é feita pela HRA por meio do envio de um desafio ao usuário e

confirmação da respectiva resposta (Passos 5.1 e 5.2). O Passo 6 consiste da resposta da HRA para

a RA, indicando se a ID do usuário é válida ou não. Diante dessa confirmação, a RA responde ao

dispositivo se a ID do usuário é válida (Passo 7).

Caso o usuário seja válido, é executada uma etapa de geração de chave de sessão entre o RA

e o usuário, bem como a posterior distribuição dessa chave ao dispositivo. O protocolo de geração

e distribuição de chave de sessão proposto é proprietário. A RA gera uma chave privada para o

dispositivo e o usuário gera a próprias chaves criptográficas. Com base neste material criptográfico,

uma chave de sessão é negociada entre a RA e o usuário (usando ECC – Elliptic Curve Cryptography),

para ser usada entre o usuário e o dispositivo (LIU; XIAO; CHEN, 2012).

O foco principal do trabalho reside na técnica de autenticação do usuário com o dispositivo e

no protocolo de estabelecimento e distribuição de chave de sessão. O modelo de controle de acesso

utilizado é o RBAC. Apesar de tratar da autenticação e autorização de usuários que acessam o

dispositivo, a autenticação e autorização de dispositivos não é abordada. Do mesmo modo, um cenário

M2M também não é tratado pelos autores. Por fim, a proposta não foi implementada e nem avaliada.

3.5 GARDEL ET AL. (2013)

Em Gardel et al. (2013), é utilizado um barramento de serviços4 como infraestrutura de

publicação e descoberta para a WoT. A proposta é prover gestão de autenticação e de autorização da

WoT utilizando o protocolo OpenID Connect.

No barramento de serviços são aplicadas as políticas de controle de acesso aos dispositivos, por

meio de uma aplicação de gerenciamento de acesso que implementa o framework OpenID Connect,

utilizando o modelo de controle de acesso CapBAC. Os serviços da WoT disponibilizados pelo4 Este barramento de serviços está instalado em uma infraestrutura sem restrições computacionais.

60

barramento de serviços como Serviços Web RESTful, são classificados como públicos ou privados.

Serviços públicos podem ser acessados por qualquer aplicação ou usuário, sem necessidade de

autenticação, enquanto que serviços privados precisam da autorização do dono do recurso (GARDEL

et al., 2013).

Caso o usuário queira acessar um serviço de um dispositivo do qual é dono, a requisição é

filtrada pela aplicação de gerenciamento de acesso no barramento e o usuário é redirecionado a uma

página de autenticação em um provedor OpenID Connect, externo ao barramento, para efetuar a

autenticação. Após a autenticação, o usuário deve autorizar que a aplicação cliente tenha acesso aos

seus dispositivos. Confirmada a autorização, a aplicação recebe como resposta um token de acesso

temporário, o qual deverá ser incluído em uma nova requisição de acesso (GARDEL et al., 2013).

Caso um usuário deseje acessar um dispositivo de um terceiro, o provedor OpenID Connect

enviará uma notificação de solicitação de acesso ao proprietário do dispositivo. Este poderá fornecer,

ou não, autorização de acesso ao serviço. Caso o proprietário confirme a autorização, a aplicação do

requisitante recebe como resposta um token, o qual poderá ser utilizado temporariamente para acesso

ao serviço (GARDEL et al., 2013).

Apesar de ser um trabalho com foco na WoT, não é tratada da comunicação entre dispositivos

(M2M). Um ponto importante é que o cenário descrito é de uma federação, em que pode-se utilizar um

provedor OpenID Connect que seja confiável tanto para a aplicação de gerenciamento de acesso como

para o usuário requisitante, não estando restrito a um único provedor OpenID Connect. Por fim, um

ponto forte do trabalho é que este foi implementado.

3.6 SEITZ, SELANDER E GEHRMANN (2013)

O trabalho descrito em Seitz, Selander e Gehrmann (2013) apresenta um framework de controle

de acesso com granularidade fina e flexível aos recursos dos dispositivos com restrições computacionais

da IoT, em um cenário M2M. O framework é independente do mecanismo de autenticação e faz uso

do modelo de gestão de políticas de outsourcing, em que a decisão de autorização é tomada por um

servidor menos restrito chamado AE (Authorization Engine), conforme mostrado na Figura 5 (SEITZ;

SELANDER; GEHRMANN, 2013).

Apesar de usar o modelo de outsourcing, a decisão final de autorização ocorre no dispositivo

em que o recurso será acessado. Para isso, o framework faz uso do padrão XACML e, por meio das

XACML Obligations, expressa as condições que devem ser satisfeitas no dispositivo para que a decisão

61

Authorization Engine

Dispositivo

Usuário

Diretório de Recursos

Internet

1

2 2.1

3.13

Figura 5. Arquitetura de autorização proposta em Seitz, Selander e Gehrmann (2013)

Fonte: Adaptada de Seitz, Selander e Gehrmann (2013).

seja válida. Para transportar as decisões de autorização tomadas na AE para o dispositivo, o framework

utiliza asserções baseadas nas asserções SAML de autorização. Também é utilizado um Diretório

de Recursos, o qual mantém descrições de recursos, como informações relevantes à segurança dos

dispositivos (p.e. chave pública e capacidade de processar XACML Obligations localmente) (SEITZ;


O mecanismo proposto consiste de três etapas, as quais são mostradas na Figura 5. Na primeira

etapa (passo 1), o usuário consulta o Diretório de Recursos e recupera a URI do dispositivo e o AE que

o dispositivo confia. Na segunda etapa (passo 2), o usuário solicita à AE o acesso a um recurso. A AE

roda internamente o protocolo XACML de requisição-resposta para tomar a decisão de autorização

(Passo 2.1). Caso a autorização seja concedida, a AE gera a asserção SAML de autorização. Como

o usuário e o AE são considerados ricos em recursos computacionais, padrões comuns da Internet,

como HTTP e TLS, podem ser utilizados nessa comunicação. A última parte do processo (passo 3) é a

tentativa de acesso do usuário ao dispositivo, fazendo uso da asserção de autorização obtida. Isso é feito

por meio da inclusão da asserção SAML em uma requisição CoAP, a qual é enviada com o payload

encriptado com uma chave conhecida pelo dispositivo (simétrica ou assimétrica), obtida pelo usuário

na etapa de geração da asserção. O dispositivo valida a requisição com a asserção recebida, bem como

verifica se existem XACML Obligations que precisam ser avaliadas (Passo 3.1). Se a validação da

requisição e a avaliação das XACML Obligations for bem sucedida, o recurso é fornecido ao usuário

62

(SEITZ; SELANDER; GEHRMANN, 2013).

Para reduzir o tamanho das respostas XACML e das asserções SAML, foi definido um sub-

conjunto dos dois padrões, visando simplificar o processamento no dispositivo. Também com esse

objetivo, a representação do subconjunto escolhido foi substituída por uma notação em JSON. Essa

escolha permitiu reduzir o tamanho das asserções SAML em aproximadamente dez vezes (SEITZ;


Um dos pontos positivos do trabalho é que este foi implementado, mostrando-se viável no

dispositivo testado (Arduino Mega 2460). Contudo, a autorização de dispositivos em um cenário M2M

não é tratada. Por fim, a autenticação também não é abordada.

3.7 COMPARAÇÃO DOS TRABALHOS RELACIONADOS

A Tabela 1 mostra a comparação dos trabalhos descritos em diversos aspectos. A coluna

Autenticação/Autorização aponta qual foi o foco principal do trabalho, se foi na autenticação (Aut.) ou

na autorização (Autz.) de dispositivos ou de usuários. A coluna Interoperabilidade de Autenticação

aponta se o trabalho tratou da interoperabilidade entre usuários e dispositivos que utilizam diferentes

mecanismos de autenticação. Nos casos em que a autenticação não foi tratada, esta característica não se

aplica (N/A) ao trabalho. A coluna Modelo de IdM mostra qual foi o modelo de gestão de identidades

utilizado.

A coluna Modelo de Controle de Acesso mostra qual foi o modelo de controle de acesso

utilizado no trabalho. Há trabalhos que tratam somente de autenticação, em que não se aplica (N/A) essa

a característica. Para os trabalhos em que o modelo de controle de acesso utilizado não está explícito

nem implícito, a coluna foi preenchida com "Não define". A coluna Suporte a SSO aponta se o

trabalho abordou a autenticação única para usuários ou para dispositivos na IoT. A coluna Tecnologias

de Autenticação e Autorização aponta quais foram as tecnologias utilizadas no trabalho com foco

específico em autenticação ou autorização de usuários ou de dispositivos.

As colunas Autenticação de Usuários e Autenticação de Dispositivos mostram, respecti-

vamente, se o trabalho abordou a autenticação de usuários e de dispositivos. Nos casos em que o

trabalho não abordou, explicitamente, autenticação, essas características não se aplicam (N/A). A

coluna Implementação mostra se o trabalho foi implementado. A coluna M2M mostra se o trabalho

abordou um cenário de comunicação M2M, em que os dispositivos atuam sem a intervenção humana,

ou seja, de forma autônoma. A coluna WoT mostra se o trabalho apresentou uma abordagem para a

63

Tabela 1. Comparação dos Trabalhos RelacionadosTr

abal

hos

Aut

entic

ação

/A

utor

izaç

ão

Inte

rope

rabi

lidad

ede

Aut

entic

ação

Mod

elo

deId

M

Mod

elo

deC

ontr

ole

deA

cess

o

Supo

rte

aSS

O

Tecn

olog

iasd

eA

uten

ticaç

ãoe

Aut

oriz

ação

Aut

entic

ação

deU

suár

ios

Aut

entic

ação

deD

ispo

sitiv

osIm

plem

enta

ção

M2M

WoT

Akram eHoffmann

(2008c)

Aut. eAutz.

Usuários

Federadoe

Centradono

Usuário

CBAC Usuários

OpenID, SAML,WindowsCardspace,

WS-Security /Trust / Policy /

Federation

X - X - X

Alam,Chowdhury e

Noll (2011)Autz. N/A Federado Independ. N/A Não define N/A N/A X X X

Conzon et al.(2012)

Aut. eAutz.

Usuários Tradic. ACL - TLS e SASL X - X - -

Liu, Xiao e Chen(2012)

Aut. eAutz

- Federado RBAC - OpenID X - - - X

Gardel et al.(2013)

Aut. eAutz.

- Federado CapBAC UsuáriosOpenIDConnect

X - X - X

Seitz, Selander eGehrmann

(2013)Autz. N/A Centraliz.

Nãodefine

-SAML eXACML

N/A N/A X - X

Este Trabalho Aut. eAutz. X Federado Independ. X

SAML,XACML eWS-Policy

X X X X X

Web das Coisas.

A partir do estudo dos trabalhos relacionados, é possível perceber que a autenticação e a

autorização, e consequentemente o controle de acesso no contexto de IoT, são temas relevantes e

abordados na literatura. Também é possível perceber a necessidade de uma infraestrutura que seja

capaz de tratar tanto a autenticação quanto a autorização de usuários e de dispositivos em um ambiente

que envolva múltiplos domínios administrativos, e que possa prover a autenticação única de usuários e

de dispositivos e a interoperabilidade de diferentes mecanismos de autenticação. Também percebe-se

a necessidade de prover mecanismos de autorização flexíveis, capazes de implementar políticas de

autorização flexíveis e diferentes modelos de controle de acesso.

64

Sobre a autenticação de dispositivos da IoT, percebe-se que não há ainda um padrão adotado

pela academia ou pela indústria. A grande heterogeneidade de tecnologias de comunicação, arquiteturas

de hardware e software e mecanismos de autenticação faz com que sejam necessárias abordagens que

permitam a interoperabilidade de dispositivos que utilizam diferentes mecanismos para provar sua

autenticidade. Com isso, seria possível criar uma certa independência de mecanismos de autenticação e,

a priori, cada dispositivo poderia utilizar o mecanismo que melhor atendesse ao seu contexto, podendo

provar sua autenticidade para dispositivos que utilizam mecanismos de autenticação diferentes do seu.

Entretanto, nenhum dos trabalhos abordou a interoperabilidade de mecanismos de autenticação para

dispositivos na IoT. De maneira semelhante, pode-se perceber que a autenticação única de dispositivos

também não foi tratada, bem como não foi provida uma infraestrutura capaz de autenticar tanto usuários

como dispositivos.

Sobre o controle de acesso na IoT, é possível notar que diferentes modelos de controle de acesso

são utilizados, estando estritamente relacionado com os requisitos da aplicação de IoT. Apenas um dos

trabalhos não descreve o modelo de controle de acesso utilizado. Também, apenas um dos trabalhos é

independente de modelo de controle de acesso, contudo o trabalho não aborda a autenticação. Assim,

é reforçada a ideia de que há a necessidade de se prover um mecanismo de controle de acesso flexível,

que permita a implementação de diferentes modelos de controle de acesso.

Dentre os quatro trabalhos baseados no modelo de gestão de identidades federadas, apesar

de todos abordarem cenários de WoT, nenhum tratou da autenticação de dispositivos em um cenário

M2M. Pode-se perceber ainda que três trabalhos fizeram uso do OpenID (ou OpenIDConnect) como

mecanismo de autenticação, enquanto que o trabalho restante não tratou de autenticação.

Cinco trabalhos tiveram abordagens para a WoT e, destes, apenas um abordou um cenário

M2M. Isso pode indicar que as abordagens da literatura tem focado na WoT não para M2M, mas sim

para permitir que o usuário tenha acesso mais fácil aos dispositivos, por meio do uso da plataforma

Web, já bastante difundida e com a qual os usuários estão mais habituados. A maioria dos trabalhos (5)

teve implementação, o que mostra a aplicabilidade dos mecanismos propostos.

Por fim, a Tabela 1 apresenta de forma introdutória o posicionamento deste trabalho em relação

aos trabalhos relacionados que apresentam infraestruturas de autenticação e/ou autorização para a IoT.

65

3.8 CONSIDERAÇÕES

A autenticação e a autorização, tanto de usuários quanto de dispositivos, são aspectos impor-

tantes para garantir a segurança das operações realizadas no contexto da IoT. Garantir que dispositivos

e usuários que utilizam diferentes mecanismos de autenticação possam provar sua autenticidade uns

para os outros, mesmo diante de um cenário com múltiplos domínios administrativos, é um passo

importante para prover a interoperabilidade na IoT. A heterogeneidade de aplicações e de dispositivos

exige que as soluções de controle de acesso sejam capazes de suportar diferentes modelos de controle

de acesso.

Sendo assim, compreender o funcionamento das infraestruturas de autenticação e autorização

para a IoT é um passo importante para a abordagem do problema de pesquisa. Este capítulo apresentou

os trabalhos encontrados na literatura que abordaram infraestruturas de autenticação e autorização para

a IoT. Tais trabalhos serviram de base para a definição e desenvolvimento da infraestrutura proposta.

A AAI proposta e sua integração à uma aplicação de WoT são apresentados em detalhes no

Capítulo 4.

66

4 INFRAESTRUTURA DE AUTENTICAÇÃO E DE AUTORIZA-

ÇÃO PARA A WEB DAS COISAS - AAI4WOT

Este trabalho tem como objetivo prover autenticação e autorização de usuários e de dispositivos

por meio de uma infraestrutura de autenticação e de autorização (Authentication and Authorization

Infrastructure – AAI), chamada de AAI4WoT, alinhada aos requisitos singulares da IoT, que faz uso

dos padrões SAML e XACML.

A AAI4WoT possibilita o uso de diferentes mecanismos de autenticação e de autorização para

usuários e dispositivos. Está fora do escopo deste trabalho conceber novos mecanismos de autenticação

ou de autorização, mas sim tornar a AAI flexível para possibilitar o uso de diferentes mecanismos já

propostos na literatura.

A AAI4WoT proposta tem por objetivo prover segurança para aplicações na WoT sem prejudicar

a interoperabilidade entre os dispositivos. Para isto, a infraestrutura está baseada em padrões abertos e

amplamente aceitos na Internet, como o protocolo HTTP, Serviços Web RESTful, os padrões SAML e

XACML. A AAI4WoT provê a autenticação única de usuários e de dispositivos e permite o uso de

mecanismos de autorização flexíveis.

Este capítulo apresenta a AAI que foi desenvolvida neste trabalho (AAI4WoT). A Seção 4.1

apresenta uma visão geral da AAI4WoT e do cenário em que se apresenta o problema de pesquisa, bem

como algumas das premissas que são assumidas. As funcionalidades e os componentes da AAI4WoT

são descritos na Seção 4.3, sendo seguida pela descrição dos modos de operação da AAI4WoT na

Seção 4.5 e do cliente ativo proposto, na Seção 4.6. A descrição de como a AAI4WoT irá estender

a especificação SAML, de modo a permitir o uso de mecanismos de autenticação como descrito

nos profiles do SAML (OASIS, 2005a), é apresentada na Seção 4.7. Na Seção 4.8, é apresentado o

modelo de ameaças contra a AAI4WoT. Em seguida, a Seção 4.9 apresenta as ferramentas utilizadas

no desenvolvimento da AAI4WoT e como esta foi integrada a uma aplicação de WoT para controle e

monitoramento remoto de máquinas industriais.

67

4.1 CENÁRIO ENVOLVIDO E PREMISSAS

O cenário em que o problema de pesquisa se apresenta é caracterizado pela existência de mais

de um domínio administrativo, sendo que estes domínios pertencem a uma federação1.

Um sistema de gestão de identidades federadas define que em uma federação há uma associação

entre domínios, na qual podem existir diferentes autoridades de autenticação e de atributos (Provedores

de Identidade - Identity Providers - IdPs) e diferentes provedores de serviços (Service Providers -

SPs). Basicamente, cada domínio administrativo é constituído por uma instituição, a qual possui suas

próprias políticas de segurança. Na federação, assume-se a existência de relações de confiança entre

SPs e IdPs dos domínios administrativos.

A AAI4WoT adota o modelo de identidades federadas e o objetivo desta adoção é permitir que

usuários e dispositivos tenham seus dados de identidade (p.e. credenciais e atributos) armazenados e

gerenciados apenas no domínio administrativo ao qual pertencem, mas que estes possam ter acesso a

recursos oferecidos em diferentes domínios (identidades federadas). Neste cenário, cada dispositivo e

usuário de um domínio possui um identificador estabelecido previamente, que o identifica de maneira

única na federação.

A Figura 6 ilustra um cenário em que dois domínios administrativos fazem parte de uma

federação e estão conectados através da Internet. Em um domínio administrativo podem existir

dispositivos com restrições computacionais2 e dispositivos sem tais restrições. Em ambos os casos,

esses dispositivos podem ter um servidor Web embarcado e prover serviços (papel de SP) ou podem

consumir serviços (papel de cliente). Cada domínio administrativo possui um IdP, responsável tanto

pela autenticação de usuários quanto de dispositivos, além de dispositivos que proveem serviços

(SPs) e dispositivos clientes. Na federação, clientes podem acessar serviços disponibilizados por

dispositivos SPs que estejam dentro ou fora de seu domínio administrativo. Este acesso pode ser feito

por um usuário com o auxílio de um navegador Web ou por usuário que utiliza uma aplicação em

um dispositivo cliente. Além disso, estes acessos podem ser feitos a partir de outros dispositivos,

localizados dentro ou fora do domínio administrativo do dispositivo SP, sem que esta ação esteja ligada

a uma intervenção humana. Isso caracteriza uma interação autônoma entre o dispositivo cliente e o

dispositivo SP (comunicação M2M - Machine to Machine).

Os dispositivos e seus serviços embarcados disponibilizam o acesso aos seus recursos por1 Um conjunto composto por provedores de serviço e provedores de identidade que possuem relações de confiança

estabelecidas entre si (CHADWICK, 2009).2 Neste trabalho, sistemas embarcados caracterizam dispositivos com restrições computacionais.

68

DOMÍNIO ADMINISTRATIVO A DOMÍNIO ADMINISTRATIVO B

Modelo de Controle de Acesso: ABAC Modelo de Controle de Acesso: RBAC

IdP-B (AAI)

Wi-Fi

LR-WPAN

IdP-A (AAI)

Usuário AplicaçãoAccess Point

Ethernet

Bluetooth

Ethernet

Dispositivo SPSmart Gateway Dispositivo Cliente

Figura 6. Cenário do Problema de Pesquisa

meio de uma Arquitetura Orientada a Recursos (Resource Oriented Architecture – ROA), fazendo

uso de Serviços Web RESTful. Assim, dispositivos clientes são capazes de fazer requisições aos

dispositivos SPs e IdPs utilizando o protocolo HTTP. Outra característica do cenário assumido é

a heterogeneidade das tecnologias de comunicação que podem ser utilizadas pelos dispositivos da

IoT. Conforme ilustrado na Figura 6, é possível que um determinado domínio suporte mais do que

uma tecnologia de comunicação. Nestes casos, pode ocorrer que alguns dispositivos não suportem a

pilha TCP/IP, sendo que para viabilizar essa conectividade é utilizado um dispositivo intermediário,

chamado Smart Gateway. O Smart Gateway atua como ponte entre estes dispositivos e a Internet, pois

compreende os diferentes protocolos dos dispositivos conectados a este e fornece uma interface para tais

dispositivos se comunicarem com os sistemas finais na Internet (MAHALLE et al., 2010). Um exemplo

pode ser visto na Figura 6. No domínio administrativo A, os dispositivos estão interconectados por meio

dos protocolos de comunicação Wi-Fi, LR-WPAN e Ethernet, enquanto no domínio administrativo B

os protocolos utilizados são Ethernet e Bluetooth.

Na AAI4WoT, de acordo com a necessidade dos dispositivos e usuários de um determinado

domínio, o IdP deste domínio pode prover diversos mecanismos de autenticação que atendam tanto

usuários quanto dispositivos. Além disso, os SPs da federação podem implementar diferentes modelos

de controle de acesso aos recursos dos dispositivos (SPs). Um exemplo disso por ser visto na Figura 6,

69

em que os SPs do domínio A adotam o modelo de controle de acesso baseado em atributos (Attribute

Based Access Control – ABAC), enquanto que os SPs do domínio B utilizam o modelo de controle de

acesso baseado em papéis (Role Based Access Control – RBAC).

Diante do cenário apresentado, as seguintes premissas são assumidas neste trabalho:

• A AAI4WoT (IdPs e componentes de autorização) e os SPs não estão comprometidos;

• Os dispositivos SPs possuem um hardware resistente à violação (Trusted Platform Module -

TPM), o qual dá suporte às operações envolvendo as credenciais desses dispositivos;

• Os dispositivos clientes, quando utilizam um mecanismo de autenticação envolvendo o uso

de chaves criptográficas, possuem um hardware TPM;

• As informações de identidade de usuários e de dispositivos estão cadastradas em uma base

de dados acessível ao IdP do domínio, considerada segura e confiável.

4.2 VISÃO GERAL DA AAI4WOT

Para a troca de dados de autenticação de usuários e de dispositivos, foi utilizado o padrão SAML.

Cada domínio administrativo da federação possui a AAI4WoT que pode ser utilizada para prover a

autenticação e contribuir com o controle de acesso de serviços disponibilizados pelos dispositivos

na WoT. A AAI4WoT adota o padrão XACML para expressar políticas de controle de acesso e

como formato para descrição de requisições e respostas de decisão de autorização, visando o uso de

mecanismos de autorização flexíveis.

O SAML, como mencionado na Seção 2.2.4.1, é um padrão baseado em XML (eXtensible

Markup Language) para a descrição e troca de asserções de segurança entre parceiros de negócio na

Internet. O SAML permite, dentre outras coisas, a autenticação única (Single Sign On - SSO) entre

múltiplos domínios administrativos, provendo suporte a alguns mecanismos de autenticação, sendo

uma das principais tecnologias que possibilita a gestão de identidades federadas (OASIS, 2008).

Conforme mencionado na Seção 2.2.4.2, o XACML é uma linguagem também baseada em

XML para a descrição de políticas de autorização e para requisição/resposta de decisões de autorização.

O XACML, um padrão OASIS3), é genérico. Isso significa que o XACML é independente de modelo

de controle de acesso. O XACML também pode ser distribuído, ou seja, é possível que uma política de3 https://www.oasis-open.org/

70

autorização faça referência a outras políticas, localizadas em locais arbitrários, construindo uma única

decisão de autorização. Outro ponto importante é a fácil integração do XACML com o SAML, já que

existem diversos perfis e extensões que tratam da interoperabilidade entre os dois padrões (OASIS,

2003).

A AAI4WoT é disponibilizada por meio de Serviços Web RESTful. Conforme analisado no

Capítulo 2, o uso de Serviços Web RESTful é mais adequado para a WoT do que o uso de Serviços

Web arbitrários ou WS-*. O aspecto leve do REST possibilita que dispositivos restritos ofereçam seus

serviços na Web. As características que colaboram para esta visão são a baixa complexidade do REST,

o baixo acoplamento das interações sem estado e sua alta flexibilidade (ZENG; GUO; CHENG, 2011).

Enquanto os Serviços Web arbitrários demandam mais recursos em termos de poder de processamento,

largura de banda e armazenamento, o REST promove a reutilização de padrões Web, permitindo uma

interação direta do cliente com o serviço, sem a necessidade de interpretar uma WSDL ou utilizar

APIs adicionais para interagir com um serviço específico. Assim, em função da simplicidade, leveza e

interfaces uniformes promovidas pelo REST, o paradigma de Serviços Web RESTful é preferido na

WoT (GUINARD et al., 2009; HAMESEDER; FOWLER; PETERSON, 2011).

DOMÍNIO ADMINISTRATIVO A

Infraestrutura de Autenticação e

Autorização para WoT (AAI4WoT)

Infraestrutura de Autenticação e

Autorização para WoT (AAI4WoT)

DOMÍNIO ADMINISTRATIVO B

Dispositivo Provedor de Serviço (SP)

DispositivoClienteRequisição de Serviço + SAML

SAMLXACML

HTTP

1

2

3

Figura 7. Visão Geral da AAI4WoT - Cenário M2M

A Figura 7 apresenta uma visão geral da AAI4WoT. A infraestrutura proposta, quando neces-

sário, pode retirar grande parte da carga computacional do dispositivo SP, referente às funções de

autorização de acesso ao serviço. Em função disso, a AAI é executada em um ambiente sem restrição

71

de recursos computacionais4. Conforme a Figura 7, a AAI4WoT no domínio do SP visa auxiliar as

operações de autenticação e de autorização. No domínio do cliente, a AAI4WoT inclui um IdP no qual

usuários e dispositivos devem se autenticar.

A Figura 7 mostra ainda as trocas de mensagens, em alto nível, realizadas entre os componentes

da AAI4WoT e o cliente, que visa autenticar o dispositivo cliente e autorizar o acesso ao recurso dispo-

nibilizado pelo SP. As trocas de mensagens do dispositivo cliente com a AAI4WoT, para autenticação

do dispositivo cliente, ocorrem usando o protocolo SAML sobre o protocolo HTTP (Passo 1). Após

autenticado na infraestrutura de seu domínio, o cliente envia ao SP mensagens HTTP que contém,

além da requisição, uma asserção SAML de autenticação (Passo 2). Já as trocas de mensagens entre o

SP e a AAI4WoT para requisição/resposta de decisões de autorização, ocorrem usando mensagens em

formato XACML encapsuladas em mensagens HTTP (Passo 3). Todas as trocas de mensagens são

feitas sobre um canal de comunicação seguro, implementado por meio do TLS, com o objetivo de

garantir a autenticidade, integridade e confidencialidade dos dados trocados.

4.3 COMPONENTES E FUNCIONALIDADES DA AAI4WOT

A Figura 8 ilustra os componentes da AAI4WoT para lidar com as responsabilidades de

autenticação e de autorização. É importante ressaltar que cada domínio administrativo possui sua

própria AAI4WoT, conforme ilustrado na Figura 8. Os componentes são descritos a seguir:

• Provedor de Identidade (IdP): atua como autoridade de autenticação, sendo responsável por

autenticar usuários e dispositivos. Atua também como autoridade de atributos, sendo capaz

de gerar asserções sobre os atributos dos usuários e dos dispositivos autenticados. Também

possui a lista dos IdPs que este confia e é responsável por validar as asserções SAML

assinadas com base nas relações de confiança pré-estabelecidas na federação (autenticação

no outro domínio de segurança);

• PEP (Policy Enforcement Point): a entidade do sistema de autorização responsável por

requisitar decisões de controle de acesso ao PDP e aplicar tais decisões (OASIS, 2013a);

• PDP (Policy Decision Point): a entidade do sistema de autorização que, diante de uma

requisição de decisão de autorização, avalia as políticas aplicáveis (fornecidas pelo PAP)4 Neste trabalho, quando é mencionado um ambiente sem restrição de recursos computacionais, o autor refere-se a um

ambiente com características computacionais bem menos severas do que as dos dispositivos da Internet das Coisas. Umambiente sem restrições computacionais é caracterizado neste trabalho por um ambiente de Computação em Nuvem.Contudo, deve-se ressaltar que utilizar um ambiente de Nuvem não é uma premissa.

72

DOMÍNIO ADMINISTRATIVO

Cliente Ativo

Dispositivo Cliente

AAI4WoT


PAP PIP IdPPDP

PEP

Figura 8. Componentes da AAI4WoT

e as informações disponíveis (fornecidas pelo PIP) e toma uma decisão de autorização

(OASIS, 2013a);

• PAP (Policy Administration Point): a entidade do sistema de autorização que cria políticas

ou conjuntos de políticas (ou por meio da qual um administrador de sistemas cria as políticas)

e as disponibiliza ao PDP, quando da necessidade de tomar uma decisão de autorização

(OASIS, 2013a);

• PIP (Policy Information Point): a entidade do sistema de autorização que possui (ou sabe

como encontrar) as informações que são necessárias para a tomada de decisão de autorização,

feita pelo PDP. Tais informações são avaliadas diante das políticas de autorização e podem

ser, por exemplo, o status do recurso, estado de sessão e horário (OASIS, 2013a);

• Cliente Ativo SAML: O dispositivo cliente faz uso deste componente de software que

auxilia no uso da AAI. Caso o cliente seja um usuário que deseja acessar o dispositivo

SP por meio de um navegador Web, o Cliente Ativo SAML irá atuar como um proxy.

Caso o cliente seja um dispositivo, o Cliente Ativo SAML é um componente de software

(biblioteca), que implementa o padrão SAML e que pode ser acessado via API para facilitar o

uso da AAI4WoT para os desenvolvedores do software embarcado do dispositivo. O Cliente

73

Ativo SAML, ao invés de ser um cliente ativo conforme preconizado pela especificação

SAML, que deve necessariamente implementar o protocolo SOAP e o SOAP Reverso5, o

componente proposto usa estritamente o protocolo HTTP, conforme os princípios REST. O

Cliente Ativo SAML auxilia as trocas de mensagens entre o cliente e o IdP e entre o cliente

e o SP, visando viabilizar a troca de mensagens SAML no cenário de WoT com Serviços

Web RESTful. O Cliente Ativo SAML é o responsável por buscar a política de qualidade

de proteção do SP (que define os requisitos de segurança que o cliente deve atender para

ter acesso ao recurso oferecido pelo SP) e por montar a requisição de autenticação para o

cliente, no padrão SAML. Também é tarefa do Cliente Ativo SAML anexar a asserção SAML

recebida do IdP nos pedidos a serem enviados para o SP (no cabeçalho das mensagens

HTTP).

A AAI4WoT garante a autenticação única de dispositivos e de usuários na WoT, uma vez que

permite que usuários e dispositivos se autentiquem e recebam uma asserção SAML referente ao evento

de autenticação realizado. Esta asserção SAML pode ser usada pelo cliente dentro da federação para

acesso a serviços fornecidos pelos SPs, sem que nova autenticação seja necessária para consumo de

diferentes serviços da federação. Nos componentes PDP, PIP, PAP e PEP, as trocas de mensagens são

requisições/respostas segundo o padrão XACML.

4.4 ETAPA DE REGISTROS E DE ESTABELECIMENTO DE RELAÇÕES DE

CONFIANÇA

Para que clientes e dispositivos possam fazer uso da AAI4WoT, uma etapa de registros e de

estabelecimento de relações de confiança precisa ser realizada. Esta etapa compreende os processos de:

(i) registro dos domínios de segurança, (ii) estabelecimento das relações de confiança entre os IdPs dos

domínios de segurança e (iii) registro dos clientes (usuários e dispositivos) e dos dispositivos SPs no

IdP do domínio correspondente.

O processo de registro de um domínio de segurança deve ser executada por todos os domínios

de segurança que farão parte da federação. Este processo consiste de dois passos:

1. Registro do domínio: nesta etapa, o domínio de segurança é registrado na estrutura de DNS

da Internet e pode ser acessado por meio de uma URL (p.e. http://dominioa.com); e5 O uso do SOAP Reverso faz com que seja necessário que o SP e o IdP também suportem o protocolo SOAP

74

2. Registro da AAI: nesta etapa, os componentes da AAI4WoT são registrados na estrutura de

DNS do domínio local. Assim, os componentes da AAI podem ser acessados por meio de

uma URL de acordo com a seguinte estrutura http://componente.aai.dominioa.com).

O processo seguinte consiste no estabelecimento das relações de confiança entre os IdPs dos

domínios de segurança que fazem parte da federação. Assume-se que estes IdPs possuam certificados

digitais emitidos por CAs (Certificate Authority - Autoridades Certificadoras) confiáveis no contexto

da federação. Este processo consiste dos seguintes passos:

1. Estabelecimento de um canal seguro: é estabelecido um canal seguro TLS mutuamente

autenticado entre os dois IdPs; e

2. Troca de metadados: é realizada a troca de metadados entre os IdPs, usando o mecanismo de

publicação e resolução de metadados chamado Well-Known Location, definido em OASIS

(2009c).

Os metadados dos IdPs devem estar no formato de metadados definido na especificação SAML

2.0, conforme descrito em OASIS (2009c), o qual é baseado em XML. O mecanismo de publicação e

resolução de metadados Well-Known Location define que uma entidade deve publicar seus metadados

em um local acessível por meio de uma URL, a qual deve ser definida por meio de seu identificador

único (p.e. http://idp.dominioa.com). A resolução dos metadados, quando o mecanismo Well-Known

Location é utilizado, pode ser feita pela simples resolução da URL por meio da qual o documento de

metadados é acessível.

No documento de metadados, é possível publicar as informações de segurança necessárias para

estabelecer as relações de confiança entre os IdPs. Por exemplo, é possível incluir as informações dos

certificados digitais que podem ser usados pelos IdP ao assinarem as asserções SAML geradas. Assim,

quando o cliente apresentar ao SP uma asserção SAML gerada e assinada por um dado IdP, o IdP do

domínio do dispositivo SP pode verificar se foi realmente o IdP com o qual este tem uma relação de

confiança que assinou a asserção.

O processo seguinte consiste no registro dos clientes no IdP do domínio do qual fazem parte.

Esta etapa pode variar conforme a entidade que deseja se registrar, a qual pode ser um dispositivo SP,

um dispositivo cliente ou ainda um usuário cliente.

Para o caso do registro de um dispositivo SP na AAI4WoT de seu domínio, a sequência de

75

passos a ser executada é mostrada na Figura 9 e descrita a seguir:

1. Geração de certificado digital temporário para o SP: com apoio do administrador do IdP, o

IdP gera um certificado digital auto-assinado, o qual é inserido manualmente no SP antes

de sua instalação. Esse certificado é utilizado apenas para a etapa de registro e só pode ser

utilizado uma vez.

2. Conexão do dispositivo SP com o IdP: após instalado, o dispositivo SP estabelece um canal

seguro com o IdP, mutuamente autenticado e baseado no protocolo TLS;

3. Envio de informações do SP: o dispositivo SP envia ao IdP um documento WADL (Web

Application Description Language), o qual provê uma descrição dos Serviços Web RESTful

oferecidos pelo SP. O SP também envia ao IdP a sua política de qualidade de proteção no

formato WS-Policy;

4. Registro do SP: o IdP gera um identificador único na federação para o dispositivo e registra-

o no DNS local. O IdP envia esse identificador único ao dispositivo SP e armazena em sua

base a WS-Policy;

5. Emissão de certificado do SP: O SP gera um par de chaves (uma pública e outra privada) e

solicita para uma CA (válida no contexto da federação) a emissão de um certificado digital,

que será utilizado para estabelecer as conexões TLS (em que o SP é autenticado) com os

demais componentes durante o funcionamento da AAI. A CA emite o certificado e envia ao

SP; e

6. Criação da política de controle de acesso do Dispositivo SP: o administrador do sistema

cria políticas de controle de acesso para os recursos do dispositivo SP, por meio de uma

aplicação no PAP.

Para o caso do registro de um dispositivo cliente no IdP de seu domínio, a sequência de passos

a ser executada é descrita a seguir:

1. Conexão do dispositivo cliente com o IdP: o dispositivo cliente estabelece um canal seguro

com o IdP via protocolo TLS; e

2. Registro do Dispositivo: o dono do dispositivo cliente registra o dispositivo e, de acordo

com o mecanismo de autenticação utilizado, recebe material criptográfico gerado pelo

76



AAI4WoT

2

4

IdP

3 4

Serviço de Diretório

Administrador

PAP

6

CA

5

DNS

4

1

1

Figura 9. Etapa de Registro do Dispositivo SP

IdP (p.e. chaves criptográficas ou certificado digital). O IdP armazena as informações

necessárias para a autenticação em um serviço de diretório e envia ao dispositivo cliente um

identificador único do dispositivo.

Para o registro de um usuário como cliente no IdP de seu domínio, o processo de registro é

realizado por meio do navegador Web pelo administrador do IdP. O processo a ser executado é descrito

a seguir:

1. Registro do Usuário: o administrador do IdP registra o usuário, informando ao IdP (uma

aplicação Web de cadastro) os dados cadastrais e o certificado digital do usuário, que deve

ter sido assinado por uma AC válida no contexto da federação e ter sido enviado para o

administrador do IdP previamente, através de um canal seguro TLS. O identificador e os

atributos dos usuários são armazenados em um serviço de diretório.

77

4.5 MODOS DE OPERAÇÃO DA AAI4WOT

A AAI4WoT possui dois modos de operação, que existem em função das possíveis diferenças

em relação à capacidade computacional do SP. Os dois modos de operação são descritos a seguir:

1. Modo de Operação SP Restrito: SP com restrição computacional o que torna custosa a

tomada de decisão de autorização no próprio dispositivo; e

2. Modo de Operação SP sem Restrição: SP com recursos computacionais suficientes para

executar todos os componentes de autorização da AAI4WoT, sendo capaz de tomar a

decisão de autorização no dispositivo.

4.5.1 Modo de Operação SP Restrito

No modo de operação SP Restrito, a AAI4WoT, no domínio do SP, possui os seguintes

componentes: PDP, PIP, PAP e o IdP. O IdP tem as funções de autenticar os clientes do respectivo

domínio e validar as asserções SAML assinadas por IdPs de dispositivos clientes. Nesse modo, o SP

é responsável pelo provimento do serviço e por desempenhar as funcionalidades de PEP (aplicar a

decisão de autorização tomada pelo PDP).

Conforme ilustrado na Figura 10, a AAI4WoT é uma infraestrutura distribuída, composta de

duas partes: uma disponibilizada como Serviços Web (contemplando o PDP, PIP, PAP e um IdP) e

outra que deve ser embarcada em cada dispositivo para que estes possam fazer uso das funcionalidades

de autenticação e de autorização da AAI4WoT. A parte embarcada trata da implementação do PEP no

lado do dispositivo SP e do Cliente Ativo SAML no lado do dispositivo cliente.

Como pode ser visto na Figura 10, o modelo de controle de políticas escolhido foi o de

outsourcing (MOORE et al., 2001). Neste modelo, a solicitação de acesso recebida pelo guardião do

serviço, o PEP, é encaminhada a um PDP externo para tomada de decisão de autorização. Esta tomada

de decisão é feita com base na asserção SAML resultante do processo de autenticação do cliente e na

política de controle de acesso do dispositivo SP. O PEP é responsável por receber e aplicar a decisão

tomada pelo PDP, liberando ou bloqueando o acesso ao serviço protegido.

Vale ressaltar que todas as trocas de mensagens mostradas na Figura 10 são feitas sobre um

canal seguro implementado via protocolo TLS. As trocas ocorrem conforme descrito a seguir:

78

DOMÍNIO ADMINISTRATIVO A DOMÍNIO ADMINISTRATIVO B

Dispositivo Cliente

AAI4WoT

1

6

15

Dispotisivo Provedor de Serviço (SP)

PAP PIP

IdP PDP

Cliente AtivoPEP

9

Componentes Propostos

Tráfego HTTP sobre TLSTráfego SAML sobre

HTTP sobre TLSTráfego XACML sobre

HTTP sobre TLSCertificado

Digital

2

10 - 13

78 14

AAI4WoT

PAP PIP

IdP PDP

5 4 3

Figura 10. AAI4WoT - Modo de Operação SP Restrito

• Passo 1: O cliente, por meio do Cliente Ativo SAML, obtém a política de qualidade de

proteção (WS-Policy) do SP que encontra-se vinculada (attached) ao serviço provido;

• Passo 2: O Cliente Ativo SAML monta uma requisição de autenticação com base na política

recebida;

• Passo 3: O Cliente Ativo SAML envia a requisição de autenticação para o IdP (requisição

SAML);

• Passo 4: Ocorre as trocas de mensagens entre o IdP e o Cliente Ativo, necessárias no

processo de autenticação do cliente, de acordo com o mecanismo de autenticação suportado

no IdP;

• Passo 5: Caso a autenticação seja bem-sucedida, o IdP responde ao Cliente Ativo com uma

asserção SAML assinada de acordo com o que foi solicitado pelo Cliente Ativo. Caso a

autenticação falhe, o IdP informa a falha de autenticação ao Cliente Ativo;

79

• Passo 6: O Cliente Ativo SAML requisita ao SP o serviço desejado pelo cliente e envia

junto com a requisição a asserção SAML gerada pelo IdP;

• Passo 7: O PEP recebe a requisição do cliente e solicita ao IdP do domínio do dispositivo a

validação da asserção SAML recebida;

• Passo 8: O IdP responde ao PEP indicando se a asserção SAML é válida (confiável) ou não;

• Passo 9: Caso a asserção SAML sejá confiável, o PEP cria e envia ao PDP uma requisição

de decisão de autorização no formato XACML, tendo como base a requisição do cliente e a

asserção SAML recebida;

• Passos 10-13: Diante da requisição e das políticas de controle de acesso aplicáveis, o PDP

toma a decisão de autorização (detalhamento das trocas de mensagens é mostrado na Figura

11);

• Passo 14: O PDP responde para o PEP com a decisão de autorização tomada, usando para

isso uma mensagem no formato XACML; e

• Passo 15: O PEP aplica a decisão de autorização. Caso o acesso seja autorizado, o SP

responde ao cliente com o recurso desejado, caso contrário responde com um erro HTTP.

O XACML não define protocolos para troca de mensagens entre os componentes de autorização,

apenas a linguagem de descrição de políticas e de descrição das mensagens de pedido e resposta

de pedido de autorização. As trocas de mensagens entre os componentes da AAI4WoT (PEP, PDP,

PIP e PAP) são feitas por meio do protocolo HTTP pois, como mencionado, todos os recursos de

autorização da AAI4WoT são providos por meio de Serviços Web RESTful. A troca de mensagens

entre os componentes de autorização, omitida na Figura 10, é mostrada na Figura 11 e descrita a seguir:

• Passo 10: O PDP verifica com o PAP a existência de políticas de autorização mais novas do

que aquelas que o PDP mantém localmente;

• Passo 11: O PAP responde ao PDP com as novas políticas, caso estas existam;

• Passo 12: Caso necessário, o PDP solicita ao PIP informações adicionais para a tomada de

decisão, como informações do recurso, data e hora e condições específicas do ambiente de

rede;

• Passo 13: O PIP responde ao PDP com as informações solicitadas; e

80


AAI4WoT

PDP

Tráfego XACML sobre HTTP sobre TLS

CertificadoDigital

PIP PAP11

10

12

13

Figura 11. Fluxo de mensagens de autorização no modo de operação SP Restrito

• Passo 14: O PDP toma a decisão de autorização e a envia ao PEP (passo 14 da Figura 10).

4.5.2 Modo de Operação SP Sem Restrições

No segundo modo de operação, o SP tem recursos computacionais suficientes para tomar as

decisões de autorização por conta própria. Ou seja, o SP não precisa mais delegar à uma parte externa

a tomada de decisão de autorização referente aos acessos aos serviços que disponibiliza.

Neste caso, a visão geral da AAI4WoT da Figura 7 pode ser especificada de acordo com a

Figura 12. Neste modo de operação, os componentes responsáveis pelas funcionalidades relacionadas

à autorização (PEP, PDP, PIP e PAP) estão todos no SP. A agregação de componentes de autorização

no SP é feita pois as atividades de autorização estão estritamente ligadas com o fornecimento do

serviço aos clientes. Neste caso, utiliza-se o modelo de controle de políticas provisioning, em que os

mecanismos de decisão e aplicação da decisão de autorização (enforcement) são locais, o que elimina

o acoplamento externo e aumenta a robustez da arquitetura diante de falhas de comunicação. O único

componente que fica fora do SP é o IdP, responsável pelas operações relacionadas à autenticação

dos clientes do domínio administrativo e pela validação de assinaturas digitais das asserções SAML

recebidas.

4.6 CLIENTE ATIVO SAML

Esta seção apresenta um detalhamento das funções do Cliente Ativo SAML. Uma das funci-

onalidades deste componente é buscar a política de qualidade de proteção do serviço que o cliente

deseja acessar. Logo, quando o cliente indicar qual serviço de um provedor de serviços deseja acessar,

o Cliente Ativo SAML deve primeiramente buscar pela respectiva política de qualidade de proteção

81


Provedor de Identidade (IdP)

DOMÍNIO ADMINISTRATIVO B

Dispositivo Cliente1

6

10Dispositivo

Provedor de Serviço (SP)

PAP

PIP

PDP

Cliente Ativo

PEP

2

9

CertificadoDigital

Componentes PropostosTráfego SAML sobre

HTTP sobre TLSTráfego HTTP sobre TLS

87

AAI4WoT

PAP PIP

IdP PDP

345

Figura 12. AAI4WoT - Modo de Operação SP Sem Restrições

deste serviço. Essa política contém regras que definem, por exemplo, os mecanismos de autenticação

aceitos pelo SP e as informações que o SP precisa ter sobre o cliente para que possa tomar uma decisão

de autorização acerca da requisição de acesso ao serviço.

De posse da política de qualidade de proteção do serviço, o Cliente Ativo SAML auxilia o

cliente no fornecimento de tais informações para o SP, que normalmente incluem a prova de identidade

do cliente. Para isto, o Cliente Ativo SAML deve interpretar a política de qualidade de proteção

recebida. A maneira utilizada neste trabalho para a prova de identidade do cliente é a autenticação

em um IdP SAML que o SP confie, o qual atua como autoridade de autenticação e autoridade de

atributos. Assim, quando um IdP autentica um cliente este atesta, por meio de uma asserção SAML,

quais atributos o cliente possui.

O Cliente Ativo SAML é responsável por montar as requisições de autenticação no padrão

SAML que atenda aos requisitos indicados pelo serviço em sua WS-Policy, usando o protocolo SAML

Authentication Request Protocol.

82

Caso a autenticação seja bem sucedida, o Cliente Ativo SAML recebe do IdP uma asserção

SAML contendo uma sentença (statement) que descreve como o cliente se autenticou. Essa asserção

pode conter também sentenças relativas com os atributos do cliente que são atestados (assinados) pelo

IdP. O Cliente Ativo SAML é responsável ainda por inserir nas requisições de acesso ao serviço a

asserção SAML (no cabeçalho da mensagem HTTP).

4.7 USO DE MECANISMOS DE AUTENTICAÇÃO DA IOT COM O SAML

Conforme descrito na Seção 2.2.4.1, muitos parâmetros são utilizados na especificação SAML

para definir um contexto de autenticação, o qual é descrito por meio de uma Authentication Context

Declaration. Em função dessas variações, a especificação define diversas Authentication Context

Classes de modo a agregar contextos de autenticação similares, além de prever extensões para que

novas Authentication Context Classes possam ser definidas. Isso faz com que o SAML seja agnóstico

ao mecanismo de autenticação utilizado.

Alguns contextos de autenticação de dispositivos e de usuários para a IoT não estão definidos

na especificação SAML e, portanto, demandam do uso das extensões previstas para que possam ser

representados em asserções SAML. Este é o caso do contexto de autenticação de dispositivos utilizado

no protótipo desenvolvido como prova de conceito da infraestrutura, bem como os contextos dos

mecanismos descritos em Mahalle et al. (2012), Nguyen, Al-Saffar e Huh (2010), Hanumanthappa e

Singh (2012), Konidala et al. (2005) e Fu, Jing e Sun (2011).

Devido a isto, a especificação SAML foi estendida para representar o mecanismo de auten-

ticação de dispositivos utilizado no protótipo da AAI4WoT. O mecanismo é baseado no acordo de

chaves autenticado não-interativo Sakai-Ohgishi-Kasahara, descrito em Sakai, Ohgishi e Kasahara

(2000). Este é um criptossistema baseado em identidades, no qual a chave pública da entidade é

calculada com base em um parâmetro público de sua identidade. As etapas e trocas de mensagens que

compõe o mecanismo são mostradas na Figura 13. Na inicialização do sistema, o IdP gera uma chave

mestra (s), única, aleatória e secreta. Com base nesta chave, em uma função hash pública (H1) e em

um parâmetro público da identidade do IdP (IDidp), o IdP gera sua chave privada (sPidp). Para os

dispositivos clientes, as chaves privadas (sPcli) são geradas pelo IdP também com base na chave mestra

e em um parâmetro público da identidade do dispositivo (IDcli), mas durante a fase de registro do

dispositivo. Para a autenticação, o IdP gera uma chave de sessão (SK) com base na sua chave pública

(Pidp) e privada (sPidp) e com base na chave pública do dispositivo (Pcli). Essa chave de sessão serve

para criptografar um número aleatório r gerado pelo IdP, usando o algoritmo AES_256, compondo

83

IdP Cliente

Inicialização

Gera s

Registro

Gera sPcli

IDcli

IDcli

sPcli

PIdP = H1(IDIdP)

Gera sPIdP

Autenticação

IDcli

Pcli = H1(IDcli)

Pcli = H1(IDcli)

SK = e(sPIdP, PIdP, Pcli)

Gera r

R = SK(r)

R

SK(R) = r’

SK = e(sPcli, Pcli, PIdP)

R’ = SK(r’-1)

R’

r’’ = SK(R’)

SE r’’ == r-1 : aut. ? não aut.

Figura 13. Etapas e trocas de mensagens do mecanismo de autenticação de dispositivos

84

o challenge (R) do protocolo de challenge-response descrito em Needham e Schroeder (1978). Ao

receber o challenge, o dispositivo cliente deve calcular a mesma chave de sessão calculada pelo IdP

(SK), com base em sua chave pública (Pcli) e privada (sPcli) e na chave pública do IdP (Pidp). Essa

chave de sessão é utilizada para descriptografar o challenge (r’). Após descriptografado, o dispositivo

calcula r’-1 e criptografa o resultado com a chave de sessão, que compõe o response (R’). Ao receber o

response, o IdP o descriptografa e verifica o resultado (r”) e, se r” for igual a r-1, o dispositivo cliente

está autenticado.

A extensão à especificação SAML foi feita por meio de um XML Schema Definition (XSD)

que restringe o uso do XSD da especificação SAML. O XSD define os elementos de um documento

XML válido para a descrição de um evento de autenticação que utilizou o mecanismo de autenticação

de dispositivos. Este XSD está descrito no Apêndice C.

4.8 MODELO DE AMEAÇAS

Um modelo de ameaças descreve o quê um atacante é capaz de fazer contra um recurso ou

sistema. Este deve conter informações acerca da capacidade computacional do atacante, as informações

que este possui e o controle que detém do sistema. Um modelo de ameaças possui dois propósitos: (i)

identificar as ameaças que o sistema está suscetível e (ii) definir quais ameaças estão não são tratadas

(fora do escopo) (RESCORLA; KORVER, 2003).

Para definição do modelo de ameaças das aplicações que farão uso da infraestrutura proposta,

tomou-se como base (i) o modelo de ameaças da Internet, descrito em Rescorla e Korver (2003) e (ii)

as considerações de segurança da especificação SAML, descritas em OASIS (2005b). A seguir, são

descritas as premissas que são assumidas para a construção do modelo:

• Um atacante possui muitos recursos computacionais;

• O canal de comunicação é inseguro (pode ser atacado);

• Os protocolos de segurança utilizados foram implementados corretamente; e

• São usados protocolos de criptografia forte.

Com base nas considerações de segurança da especificação SAML (OASIS, 2005b), as quais

assumem como modelo de ameaças o modelo da Internet descrito em Rescorla e Korver (2003), a

85

maneira como o processo de autenticação é realizado é considerada fora do escopo do modelo de

ameaças da AAI4WoT. A especificação SAML permite que declarações sejam criadas sobre processos

de autenticação, mas não impõe requisitos ou especificações sobre como é realizado o processo em si.

Logo, declarações acerca deste processo serão emitidas, mas fica a cargo do receptor dessa asserção

avaliar o quanto pode confiar no processo de autenticação realizado pelo IdP.

A seguir, são descritas as ameaças que foram identificadas para a AAI4WoT, com base nas

ameaças descritas em Rescorla e Korver (2003), OASIS (2005b), Babar et al. (2010), Babar et al.

(2011) e Covington e Carskadden (2013) e as medidas que são tomadas para eliminar ou mitigar tais

ameaças:

• Comprometimento da autenticidade das partes comunicantes e comprometimento da confi-

dencialidade e integridade dos dados em trânsito;

– Esta ameaça é mitigada pelo o uso de um canal seguro estabelecido com o protocolo

TLS para troca de mensagens;

• Comprometimento da autenticidade e integridade no nível de mensagem SAML. No cenário

em questão, esta é uma ameaça à mensagem SAML que contém a asserção SAML. É uma

ameaça pois a asserção SAML não é enviada diretamente do IdP para o SP, mas sim do IdP

para o cliente e do cliente para o SP. Assim, há a ameaça de que o próprio cliente (caso este

seja malicioso) comprometa a integridade e autenticidade da asserção SAML;

– Esta ameaça é mitigada (i) pelo o uso do XML Signature (EASTLAKE et al., 2008)

pelo IdP ao gerar mensagens de protocolo e asserções SAML assinadas e (ii) pelo

timestamp, tempo de validade e indicação do SP alvo das mensagens, uma vez que as

mensagens e asserções podem ser utilizadas apenas em um SP específico e por um

curto período de tempo;

• Roubo de credenciais quando em trânsito pela rede (comunicação entre dispositivo cliente e

IdP/SP);

– Esta ameaça é mitigada pelo uso de um canal seguro criptografado entre as partes;

• IP Spoofing ou MAC Spoofing, caracterizado quando um atacante cria um pacote IP ou

quadro com endereço de origem de outro sistema final;

86

– Esta ameaça é mitigada pelo fato de que é necessário, no caso dos servidores, que

estes sejam autenticados utilizando certificados digitais (autenticação do protocolo

TLS). No caso do cliente, este precisa provar sua identidade para um IdP para então

poder receber a asserção SAML. Deste modo, o IP Spoofing ou MAC Spoofing não

são suficientes para forjar a identidade do cliente;

• Ataque de Repetição de Mensagens (Replay Attack), caracterizado quando o atacante envia

ao receptor uma sequência de mensagens que já foi enviada anteriormente;

– Esse ataque é mitigado pelo uso de um canal seguro estabelecido com o protocolo

TLS e pelo timestamp e tempo de validade das mensagens SAML;

• Ataque de Inserção de Mensagens, caracterizado quando o atacante forja uma mensagem e

a injeta na rede, normalmente forjando também o endereço de origem da mensagem;

– Este ataque é mitigado pelo uso de um canal seguro autenticado estabelecido usando

o TLS. O uso do canal seguro inviabiliza a inserção de mensagens maliciosas sem a

percepção do receptor;

• Ataque Man-in-the-Middle, em que o atacante fica entre o cliente e o servidor (IdP, SP ou

qualquer outro componente da AAI) sem ser percebido por ambos;

– Este ataque é mitigado por meio do uso de um canal seguro, usando TLS (conforme

descrito em Rescorla e Korver (2003));

• Acesso físico ao dispositivo, levando à ameaça de acesso indevido às credenciais do

dispositivo, como a chave privada do certificado digital no caso do SP e as credenciais de

autenticação no caso do cliente;

– Esta ameaça é mitigada pelo uso de hardware TPM no dispositivo SP e no dispositivo

cliente (quando este realiza operações com chaves criptográficas). Deste modo, as

operações que envolvem o uso das credenciais são feitas no hardware TPM;

• Ataque de negação de serviço no dispositivo SP;

– O fato do SP não precisar manter uma sessão HTTP aberta enquanto o cliente faz

a autenticação no IdP SAML evita que o SP tenha seus recursos esgotados em uma

operação normal com muitos clientes. Porém, este ataque ainda é possível. A solução

proposta não trata ataques de negação de serviço, uma vez que tratar esse tipo de

ataque demanda o emprego de mecanismos que estão fora do escopo deste trabalho.

87

• Ataque de negação de serviço na AAI4WoT;

– Pelo mesmo motivo que o caso anterior, o ataque de negação de serviço contra a AAI

não é tratado.

4.9 DESENVOLVIMENTO

Esta seção descreve a implementação de um protótipo da AAI4WoT e a integração da infraes-

trutura à uma aplicação de WoT para monitoramento e controle de máquinas industriais. O protótipo é

uma implementação parcial da AAI4WoT, conforme será descrito nas próximas seções. Inicialmente,

são descritas as tecnologias utilizadas na implementação e alguns aspectos do desenvolvimento do

protótipo. Em seguida, a aplicação de WoT utilizada (estudo de caso) é descrita. Por fim, é descrita a

integração da AAI4WoT à aplicação de WoT.

4.9.1 Ferramentas Tecnológicas Utilizadas

A AAI4WoT está baseada no uso de Serviços Web RESTful e das especificações SAML,

XACML e WS-Policy. Como a linguagem de programação JAVA possui várias APIs para desenvolvi-

mento de Serviços Web RESTful e implementações das referidas especificações, optou-se por esta

linguagem de programação para o desenvolvimento da AAI.

A biblioteca OpenSAML6, que implementa a especificação SAML, foi utilizado na AAI4WoT.

Esta biblioteca implementa a especificação SAML 2.0, é de código aberto e é utilizada em diversos

projetos que fazem uso do padrão SAML, como os projetos eduGAIN7, Shibboleth8 e CAS9. Esta

biblioteca foi utilizada nos pontos da AAI4WoT que necessitam do uso de SAML, exceto no IdP, o

qual foi implementado utilizando o framework SimpleSAMLphp 10. Este framework foi escolhido

por ser de código aberto, por ter ampla documentação mantida pelos desenvolvedores e pela comuni-

dade de usuários e por fornecer uma implementação pronta de IdP, facilmente parametrizável e em

conformidade com a especificação SAML 2.0.

O XACML foi utilizado no PEP e no PDP por meio da biblioteca Balana11, a qual é de6 https://wiki.shibboleth.net/confluence/display/OpenSAML/Home7 http://services.geant.net/edugain/Pages/Home.aspx8 http://shibboleth.net/9 http://www.ja-sig.org/products/cas/downloads/index.html10 https://simplesamlphp.org11 http://xacmlinfo.org/category/balana/

88

código aberto e implementa o XACML 3.0 conforme a especificação. Na implementação dos Serviços

Web RESTful em Java, foi adotada a especificação JAX-RS 2.0 e utilizado o framework Jersey12

(JSR-33913), o qual é de código aberto e é a implementação de referência para esta especificação.

O serviço de diretório no qual são armazenadas as identidades dos usuários e dos dispositivos

que autenticam-se no IdP foi implementado utilizando o OpenLDAP14, por ser de código aberto e

facilmente integrável com o SimpleSAMLphp. Os certificados digitais autoassinados utilizados para

autenticação de usuários e dos componentes da AAI4WoT foram gerados usando o Java Keytool

e a biblioteca OpenSSL15. Já para a autenticação de dispositivos, a biblioteca RELIC (ARANHA;

GOUVEA, 2009) foi utilizada para implementação do mecanismo de autenticação escolhido, descrito

na Seção 4.7 e baseado no acordo de chaves descrito em Sakai, Ohgishi e Kasahara (2000) e no

protocolo de challenge-response descrito em Needham e Schroeder (1978).

Os softwares desenvolvidos para o dispositivo cliente e o dispositivo SP utilizado no protótipo

foram embarcados em BeagleBoneBlack 16. Optou-se por esta solução de hardware pois a aplicação

de WoT a utilizada nos experimentos e por esta possuir uma plataforma de hardware aberta. Como

Container Web das aplicações Java que proveem Serviços Web RESTful, foi utilizado o Apache

Tomcat17, uma vez que este já era utilizado na aplicação de WoT, tanto na parte embarcada no

BeagleBone Black como na parte alocada na infraestrutura de Nuvem.

Como ferramentas de apoio aos testes realizados, foram utilizados o Wireshark18 e o TCP-

DUMP19 para análise dos pacotes transmitidos na rede e o Java Mission Control 20 para verificação

do consumo de memória e CPU das aplicações Java. Também foi utilizado o comando df do sistema

operacional Linux para os testes de consumo de memória flash/disco e um multímetro digital para os

testes de consumo de potência elétrica.12 https://jersey.java.net/13 https://jcp.org/en/jsr/detail?id=33914 http://www.openldap.org/15 https://www.openssl.org/16 http://beagleboard.org/BLACK17 http://tomcat.apache.org/18 https://www.wireshark.org/19 http://www.tcpdump.org/20 http://www.oracle.com/technetwork/java/javaseproducts/mission-control/java-mission-control-1998576.html

89

4.9.2 Implementação do Protótipo da AAI4WoT

Para auxiliar o uso da AAI4WoT, como prova de conceito, foi desenvolvida uma Aplicação

de Registro para usuários e para dispositivos. Esta aplicação serve para que o administrador do IdP

cadastre e gerencie as identidades dos usuários e dos dispositivos que poderão se autenticar no IdP. A

aplicação foi desenvolvida em PHP, sendo as identidades armazenadas em um serviço de diretório

LDAP. Com a aplicação, é possível gerenciar o ciclo de vida das identidades de usuários e dispositivos

(operações de inserção, consulta, exclusão e alteração de identidades).

No protótipo, foram definidos os metadados das identidades de usuários e de dispositivos. Os

metadados dos usuários são compostos dos atributos: nome, sobrenome, e-mail, organização, unidade

organizacional, função, cpf (identificador único) e certificado digital no formato X.509. Os metadados

dos dispositivos tiveram como base os atributos utilizados para descrever dispositivos em plataformas

de IoT em Nuvem 21. Os atributos dos dispositivos são: o número de série (identificador único),

nome de exibição, contato do administrador, organização, unidade organizacional, descrição, tipo de

dispositivo, referência de localização física, latitude, longitude, altitude, disposição (fixo ou móvel),

exposição (indoor ou outdoor) e status (online ou offline). A Figura 14 mostra as telas de cadastro de

usuários e de dispositivos da aplicação de registro, enquanto a Figura 15 mostra a árvore de diretório

LDAP do IdP utilizado nos experimentos.

As informações que farão parte da identidade dos usuários dependem ainda dos mecanismos

de autenticação implementados pelo IdP. No protótipo desenvolvido, o IdP permite o uso de dois

mecanismos: (i) autenticação de usuários via certificado digital no formato X.509 e (ii) autenticação

de dispositivos por meio do acordo de chaves autenticado não-interativo Sakai-Ohgishi-Kasahara,

descrito na Seção 4.7. O registro de usuários ocorre com base na inserção das informações na tela de

cadastro e na inserção de um certificado digital no formato X.509, feitos pelo administrador do IdP.

Caso a inserção não seja bem sucedida, uma tela de erro é apresentada. Para os experimentos, foram

utilizados certificados autoassinados.

Para registar um dispositivo, o administrador do domínio insere os atributos da identidade do

dispositivo na aplicação de registro. Esta executa uma aplicação escrita em linguagem C para gerar

a chave privada do dispositivo. Essa chave privada é gerada com base na chave pública (calculada

com base no número de série enviado) e na chave mestra (única, conhecida somente pelo IdP e gerada

antecipadamente - ver Figura 13) . Após a geração da chave privada, a aplicação a exibe para o21 Foram utilizadas como base as plataformas DeviceHive, Xively, Thingworx, Evrything e Axeda.

90

Figura 14. Telas de cadastro da aplicação de registro do IdP

administrador do IdP , o qual deve inserir manualmente no dispositivo que está sendo registrado.

Esta chave privada não é armazenada no IdP. Na implementação do acordo de chaves Sakai-Ohgishi-

Kasahara, foi utilizada a biblioteca RELIC (ARANHA; GOUVEA, 2009).

Optou-se pelo uso de certificados digitais para autenticação de usuários por ser um meca-

nismo mais forte do que a autenticação por usuário e senha. A opção pelo uso do acordo de chaves

Sakai-Ohgishi-Kasahara ocorreu pela necessidade de se utilizar um mecanismo mais adequado para

autenticação de dispositivos, como é o caso do mecanismo escolhido. A escolha por um mecanismo

baseado em identidades evita a necessidade do uso de certificados digitais (e o elevado custo da compra

e manutenção de um certificado para cada dispositivo) e, ao mesmo tempo, mantém a possibilidade do

uso de criptografia assimétrica para autenticação. Por fim, a escolha por mecanismos de autenticação

diferentes para usuários e dispositivos e o suporte a estes no mesmo IdP visou atingir o objetivo

específico 2 deste trabalho.

No protótipo, dois cenários foram desenvolvidos. Em ambos, o IdP e o PDP estavam aloca-

dos em uma infraestrutura de Nuvem (Modo de Operação SP com restrição). No primeiro cenário

(autenticação de dispositivos), uma aplicação Java embarcada em um dispositivo BeagleBone Black

atua como dispositivo cliente de um Serviço Web RESTful, que está embarcado em outro BeagleBone

Black (dispositivo SP). No segundo cenário (autenticação de usuários), uma aplicação Java é executada

91

dc=idp-t-marlon,dc=cloudapp,dc=net

-objectClass: top-objectClass: dcObject-objectClass: organization-dc: idp-t-marlon-o: DomainA

-dn: dc=idp-t-marlon,dc=cloudapp,dc=net

ou=person

-objectClass: top

-objectClass: organizationalUnit-ou: person

-dn: ou=person,dc=idp-t-marlon,dc=cloudapp,dc=net

ou=device

-objectClass: top-objectClass: organizationalUnit-ou: device

-dn: ou=device,dc=idp-t-marlon,dc=cloudapp,dc=net

uid=identifier

-objectClass: top-objectClass: person

-dn: uid=Identifier,ou=person,dc=idp-t-marlon,dc=cloudapp,dc=net

-objectClass: organizationalPerson-objectClass: inetOrgPerson

-cn: commonName-sn: surName-mail: [email protected]: Role-description: description of the person-uid: unique identifier with 256 characters-userCertificate: user's digital certificate

-objectClass: extensibleObject

uniqueIdentifier=identifier

-objectClass: top-objectClass: device

-dn: uniqueIdentifier=Identifier,ou=device,dc=idp-t-marlon,dc=cloudapp,dc=net

-cn: commonName-adminContact: device administrator's mail address

-deviceType: type of the device-description: description of the device

-uniqueIdentifier: unique identifier with 256 characters

-l: name of location

-objectClass: extensibleObject

-latitude: latitude of the device-longitude: longitude of the device-altitude: altitude of the device

-exposure: outdoor or indoor-disposition: mobile or fixed

-status: online or offline

Figura 15. Árvore do diretório de identidades do IdP

em um notebook e atua como cliente não Web e o Serviço Web RESTful é embarcado no BeagleBone

Black (dispositivo SP).

Os diagramas de sequência das Figura 16 e 17 mostram as trocas de mensagens para a

autenticação de dispositivos, conforme descritas a seguir:

• Passo 1: Cliente Ativo monta uma requisição de autenticação SAML22 que não é assinada

digitalmente. No campo da requisição que aponta o gerador desta, é inserido o identificador

único do SP que o cliente deseja acessar;

• Passo 2: Antes do envio da requisição de autenticação, é estabelecido um canal TLS entre o

cliente e o IdP, sendo que o IdP é autenticado por meio do seu certificado SSL. A requisição

de autenticação SAML é enviada via HTTP POST, de acordo com o Binding HTTP POST22 Diferente do que foi descrito na Seção 4.5.1, no protótipo, não foi implementada a busca da política de qualidade de

proteção do dispositivo SP conforme descrito na Seção 4.5.1. Assume-se no protótipo, que o Cliente Ativo obteve aWS-Policy e extraiu as informações necessárias para montar a requisição SAML.

92

1 - Gera SAML AuthnRequest

IdPCliente Ativo

2 - HTTPS POST - /SSOService {SAML Authn Request}

HTTPS Redirect {/selectsource + cookieSess}

/selectsource

3 - HTTPS GET - /selectsource {cookieSess}

HTTPS Redirect {/logindevice + cookieMec}

4 - HTTPS GET - /selectsource {mecanismo + cookieSess}

/logindevice

5 - HTTPS GET - /logindevice {cookieSess + cookieMec}

HTTPS Redirect {/logindevice + challenge}

6 - HTTPS POST - /logindevice {NumSerie + cookieSess + cookieMec}

CalculaChallenge

/logindevice

7 - HTTPS GET - /logindevice {cookieSess + cookieMec}

8 – Calcula Response

HTTPS Redirect {SP/resource + SAML Response + cookieAuth}

9 - HTTPS POST - /logindevice {NumSerie + response + cookieSess + cookieMec}

10 – Extrai SAML Response

Figura 16. Fluxo de mensagens do cenário de autenticação de dispositivos - parte 1

93

SPCliente Ativo

11 - HTTPS GETSP/resource {SAML Response}

17 - HTTPS 200 {recurso} / Erro HTTP

PDP

12 - Verifica Assinatura SAML Response

12 - Verifica Assinatura SAML Assertion

12 – Gera XACML Request

15 - HTTPS 200 {XACML Response}

13 - HTTPS POST - /decisionrequest {XACML Request}

14 - Toma Decisão de Autorização

16 – Verifica Decisão de Autorização

Figura 17. Fluxo de mensagens do cenário de autenticação de dispositivos - parte 2

(OASIS, 2009b), para o endpoint de autenticação do IdP (/SSOService). Em função do uso

deste Binding, para o IdP, o cliente foi redirecionado pelo respectivo SP para o endpoint

de autenticação. Como resposta, o IdP envia uma mensagem HTTP de redirecionamento,

encaminhando o Cliente Ativo para outro endpoint no mesmo IdP (/selectsource), para que

o cliente escolha qual mecanismo deseja se autenticar (certificado digital ou o acordo de

chaves Sakai-Ohgishi-Kasahara). Além do redirecionamento, a resposta HTTP contém um

cookie (cookieSess), o qual deve ser enviado pelo Cliente Ativo durante as futuras interações

com o IdP. Esse cookie serve para que o IdP possa fazer a manutenção da sessão do cliente,

sendo o único ponto da AAI4WoT que mantém estados de sessão (necessário para prover a

autenticação única). Percebe-se, assim, que para interagir com sucesso com o IdP, o Cliente

Ativo deve simular o fluxo de mensagens que seria realizado por um navegador Web;

• Passo 3: Neste passo, o Cliente Ativo solicita, via HTTP GET, o conteúdo do endereço

para onde o IdP o redirecionou no Passo 2, enviando junto o cookieSess. Como resposta, o

cliente recebe o respectivo conteúdo

• Passo 4: O Cliente Ativo seleciona o mecanismo de autenticação desejado, neste caso, o

acordo de chaves Sakai-Ohgishi-Kasahara. A opção é indicada em nova requisição HTTP

94

GET (via Query String - na URL) que o Cliente Ativo envia para o endpoint do IdP para o

qual foi redirecionado no Passo 2 (/selectsource). Como resposta, o IdP envia mensagem

HTTP redirecionando o Cliente Ativo para outro endpoint (/logindevice), responsável pelo

processo de autenticação. A mensagem de redirecionamento contém, ainda, um cookie

que deve ser mantido pelo cliente (cookieMec), indicando o mecanismo de autenticação

escolhido;

• Passo 5: Neste passo, o Cliente Ativo solicita, via HTTP GET, o conteúdo do endereço para

onde o IdP o redirecionou no Passo 4, enviando junto o cookieSess e o cookieMec. Como

resposta, o cliente recebe o respectivo conteúdo;

• Passo 6: O Cliente Ativo envia para o IdP o parâmetro público no qual sua chave pública é

baseada, por exemplo, seu número de série. Esse envio é feito via mensagem HTTP POST,

em que o conteúdo é do tipo application/x-www-form-urlencoded e o número de série é

enviado como um par do tipo chave-valor. Ao receber a requisição, o IdP irá executar uma

aplicação escrita em C que calcula challenge para o cliente, conforme descrito na Seção 4.7.

O challenge é enviado na URL para a qual o Cliente Ativo é redirecionado;

• Passo 7: Neste passo o Cliente Ativo solicita, via HTTP GET, o conteúdo do endereço para

onde o IdP o redirecionou no Passo 6, enviando junto o cookieSess e o cookieMec. Como

resposta, o cliente recebe o respectivo conteúdo

• Passo 8: O Cliente Ativo extrai o challenge da URL para a qual foi redirecionado e executa

uma aplicação em C para o cálculo do response, conforme descrito na Seção 4.7;

• Passo 9: O response é enviado para o IdP junto com o número de série do cliente via HTTP

POST23, sendo que o número de série e o response são enviados como pares do tipo chave-

valor. Junto com a requisição são enviados o cookieSess e o cookieMec. Caso o response

esteja correto, o cliente é autenticado e o IdP responde ao cliente (com uma mensagem

redirecionando para o endereço do recurso no SP desejado), enviando no corpo a mensagem

SAML Response com a asserção SAML, que indica que o cliente foi autenticado e os

atributos que este possui. Tanto a SAML Response como a Asserção SAML são assinadas

digitalmente pelo IdP. A mensagem HTTPS do IdP contém ainda um cookie que indica ao

IdP o contexto de segurança do cliente (cookieAuth). Este deve ser armazenado pelo Cliente

Ativo e utilizado em requisições futuras juntamente com os demais cookies, evitando uma

nova autenticação e permitindo a autenticação única;23 O conteúdo é do tipo application/x-www-form-urlencoded.

95

• Passo 10: Neste passo, o Cliente Ativo não segue o redirecionamento solicitado pelo IdP no

Passo 9 e extrai do corpo da resposta HTTP a mensagem SAML Response enviada pelo

IdP;

• Passo 11: O Cliente Ativo estabelece com o SP um canal seguro TLS (SP é autenticado pelo

Cliente Ativo por meio de certificado SSL). Em seguida, envia a solicitação para o recurso

do SP (SP/resource) utilizando o método HTTP GET. A mensagem SAML Response é

enviada em um cabeçalho (HTTP Header) chamado SAMLResponse;

• Passo 12: O PEP do SP extrai o cabeçalho HTTP e obtém a mensagem SAML Response.

A etapa de verificação de assinaturas digitais que seria delegada ao IdP do domínio local,

conforme descrito na Seção 4.5.1, foi executada localmente no SP. Assim, o SP verifica

se a assinatura digital da mensagem SAML Response e da Asserção SAML são de algum

dos IdPs que fazem parte do círculo de confiança do SP. Se sim, o SP gera uma requisição

de decisão de autorização no formato XACML, tendo como base o recurso que o cliente

deseja acessar, a ação que o cliente deseja realizar (método HTTP da solicitação), o dia da

solicitação e os atributos do cliente contidos na Asserção SAML;

• Passo 13: O PEP do SP envia a solicitação de decisão de autorização no formato XACML

para o PDP (/decisionrequest) em uma mensagem HTTP POST, sobre um canal TLS

mutuamente autenticado;

• Passo 14: O PDP toma a decisão de autorização com base na requisição recebida. Os

componentes PIP e PAP, descritos na Seção 4.5.1 não foram implementados. Sendo assim,

as decisões de autorização são tomadas com base nas políticas de controle de acesso que o

PDP possui localmente (a política utilizada nos experimentos está descrita em detalhes no

Apêndice B). Com base na decisão tomada, é gerada uma resposta XACML, contendo a

respectiva decisão de autorização;

• Passo 15: O PDP envia ao PEP a decisão de autorização no formato XACML (XACML

Response);

• Passo 16: O PEP verifica se a decisão de autorização permite que o recurso seja fornecido; e

• Passo 17: Caso a decisão de autorização permita, o recurso é fornecido ao cliente. Caso

contrário, um erro HTTP é enviado ao cliente.

96

Vale destacar que, no Passo 1, a requisição de autenticação SAML gerada pelo Cliente Ativo

possui, no campo que aponta o gerador da requisição, o identificador do SP que o cliente deseja acessar.

Logo, para o IdP, o cliente chegou ao endpoint de autenticação com a requisição SAML em função de

um redirecionamento feito pelo SP. Na especificação SAML, a requisição de autenticação precisa ser

gerada por um SP. Neste caso, o SP ficaria responsável pela geração da requisição de autenticação para

o cliente e precisaria manter o estado de sessão deste até que retornasse ao SP para consumir o recurso.

Uma alternativa seria o cliente realizar o fluxo de autenticação iniciado no IdP, em que o cliente não

envia uma requisição de autenticação SAML, mas indica ao IdP o SP que deseja acessar. Contudo, ao

fazer isso, o cliente pode não atender aos requisitos de segurança do SP com a autenticação realizada.

Assim, esta opção foi tomada para manter a compatibilidade com o padrão SAML nas mensagens

trocadas entre cliente e IdP.

Sobre o Passo 11, em que a mensagem SAML Response é enviada no cabeçalho (HTTP

Header), percebe-se que esta não segue um dos Bindings definidos na especificação SAML. Para

manter a conformidade com o SAML e usar apenas mensagens HTTP, há duas alternativas: (i) usar o

HTTP POST Binding ou (ii) usar o HTTP Artifact Binding. No primeiro caso, a mensagem do cliente

para o SP utiliza sempre o método HTTP POST para envio da SAML Response. Neste caso, o SP

precisará manter uma sessão do cliente e, após receber a SAML Response e avaliar a Asserção SAML

contida nesta, deverá redirecionar o cliente para o recurso desejado. Essa opção não é adequada em

função do redirecionamento adicional e da necessidade de manutenção do contexto de segurança. No

segundo caso, o cliente receberá do IdP e enviará ao SP apenas um token (artefato) que referencia a

mensagem SAML Response contida no IdP. O SP deverá solicitar ao IdP a mensagem SAML Response

por meio de um canal direto com o IdP, usando o protocolo SOAP. Essa opção também não é adequada,

em função do uso do SOAP pelo SP. Logo, para tratar deste problema, optou-se por incluir a SAML

Response no cabeçalho da requisição HTTP enviada ao SP.

Quando o cliente ativo precisar consumir novamente um recurso de algum SP da federação, este

poderá usufruir da autenticação única. Neste caso, o fluxo de mensagens com o SP não mudará e apenas

o fluxo de autenticação será alterado (Figura 16). O fluxo de autenticação única para dispositivos é

mostrado no diagrama da Figura 18 e é descrito a seguir:

• Passo 1: Cliente Ativo monta uma requisição de autenticação SAML;

• Passo 2: É estabelecido um canal TLS entre o cliente e o IdP. A requisição de autenticação

SAML é enviada via HTTP POST para o endpoint de autenticação do IdP (/SSOService).

97

1 - Gera SAML AuthnRequest

IdPCliente Ativo

2 - HTTPS POST - /SSOService {SAML Authn Request + cookieSess + cookieMec + cookieAuth}

HTTPS Redirect {SP/resource + SAML Response}

3 – Extrai SAML Response

Figura 18. Fluxo de mensagens de autenticação única do cenário de autenticação de dispositivos

Junto com a requisição, são enviados o cookieSess, o cookieMec e o cookieAuth. O IdP

verifica o contexto de autenticação do cliente e percebe que este já está autenticado. Assim,

o IdP responderá com uma mensagem redirecionando o cliente para o endereço do recurso

no SP desejado, enviando no corpo desta uma mensagem SAML Response, a qual contém a

Asserção SAML que indica que o cliente foi autenticado e os atributos que este possui; e

• Passo 3: O Cliente Ativo extrai do corpo da resposta HTTP a mensagem SAML Response

enviada pelo IdP.

A diferença nas trocas de mensagens do cenário de autenticação de usuários para o cenário de

autenticação de dispositivos está no Passo 4, no qual o cliente escolhe o mecanismo de autenticação.

Neste passo da autenticação de usuários, o Cliente Ativo seleciona a autenticação via certificado

digital. A opção também é indicada em nova requisição HTTP GET (via Query String - na URL)

que o Cliente Ativo envia para o endpoint de escolha do mecanismo de autenticação do IdP. Ao

receber a requisição, o IdP solicita o certificado digital do cliente por meio do canal TLS estabelecido

entre ambos. O cliente envia o certificado e o IdP busca no diretório LDAP um cliente que possua

o campo uid igual ao campo CN do certificado X.509. Caso o cliente seja encontrado, o certificado

enviado é comparado com o certificado armazenado na base LDAP (cadastrado na etapa de registro)

98

e, caso o certificado seja o mesmo, o cliente está autenticado. O servidor então responde com uma

mensagem de redirecionamento, enviando no corpo desta uma mensagem SAML Response, a qual

contém a Asserção SAML que indica que o cliente autenticou-se e os atributos que este possui. Tanto

a SAML Response como a Asserção SAML são assinadas digitalmente pelo IdP. Ainda, a mensagem

HTTP do IdP contém um cookie que indica ao IdP o contexto de segurança do cliente (cookieAuth) e

outro que indica o mecanismo de autenticação escolhido (cookieMec). Todos os cookies devem ser

armazenados pelo Cliente e utilizados em requisições futuras, permitindo assim a autenticação única.

Após o recebimento da SAML Response, a troca de mensagens com o SP é a mesma para dispositivos

e usuários, ou seja, o fluxo é o mesmo a partir do Passo 10. De modo similar, o fluxo de autenticação

única para usuários é igual ao fluxo para dispositivos.

4.9.3 Aplicação de Monitoramento e Controle de Máquinas Industriais

A aplicação de WoT de monitoramento e controle de máquinas industriais, descrita em Silva

(2014a), visa obter os dados de monitoramento de uma máquina industrial, ou de um conjunto de

máquinas, tratar estes dados e disponibilizá-los de duas maneiras: (i) para uma aplicação hospedada

em um ambiente de Nuvem, a qual faz a persistência dos dados recebidos e os disponibiliza para

aplicações de monitoramento construídas em uma Plataforma como Serviço (Platform as a Service

- PaaS); e (ii) para usuários e dispositivos que queiram ter acesso às informações sobre a máquina

(ou conjunto de máquinas) monitorada. Vale ressaltar que tanto a aplicação que faz a persistência dos

dados quando a PaaS são contribuições descritas em Silva (2014b).

Conforme mostrado na Figura 19, a aplicação em questão funciona em conjunto com uma

máquina industrial, a qual possui um sistema SCADA (Supervisory Control and Data Acquisition)

instalado em um notebook que acompanha a máquina. O sistema SCADA é responsável por atuar sobre

a máquina e obter informações sobre o funcionamento desta, ou seja, sobre as operações que a máquina

está realizando e sinais provenientes de sensores. Tais informações de funcionamento da máquina

são gravadas em um arquivo de log. Como o sistema SCADA intermedia a troca de informações com

a máquina, este torna-se a interface com a qual a aplicação de WoT de monitoramento e controle

de máquinas industriais deve interagir para monitorar/atuar sobre a máquina. Neste trabalho, foram

utilizadas apenas as funções de monitoramento desta aplicação, haja vista que as funções de controle

ainda estão em desenvolvimento.

Para realizar o monitoramento, a aplicação precisa identificar quando novas informações de

funcionamento da máquina são incluídas no arquivo de log pelo sistema SCADA. Para isso, foi

99

Smart Gateway

Co

nta

ine

r W

eb

Aplicação Smart Gateway

Representação

Virtual da Máquina

Serviço Web

RESTful

Cliente Web

RESTful De

vic

e D

riv

er Máquina Industrial

{ SPI/I2C }

Monitor

Cliente Web RESTful

{ JSON }

Máquina Industrial

{ LOG }

Sistema SCADA

PaaS

Serviço Web de Recebimento

de Dados

{ JSON }

Dispositivo ClienteUsuário Cliente

{ JSON/XML }{ JSON/XML }

Infraestrutura de Computação em Nuvem

Figura 19. Aplicação de WoT para monitoramento e controle remoto de máquinas industriais

Fonte: Adaptada de Silva (2014a).

desenvolvida em Silva (2014a), uma aplicação chamada Monitor. O Monitor é uma aplicação Java

instalada no notebook em que o sistema SCADA grava o log e, a cada inclusão de uma nova informação

no log, o Monitor recupera esta informação e disponibiliza à aplicação de monitoramento, conforme

mostrado na Figura 19. A aplicação de monitoramento, que também é uma aplicação Java e está

implantada em um Container Web Apache Tomcat, está embarcada em um BeagleBone Black, ou

seja, fora do notebook no qual o sistema SCADA e o Monitor estão instalados. A aplicação de

monitoramento embarcada no BeagleBone Black será chamada de Smart Gateway.

O envio das informações recuperadas pelo Monitor para o Smart Gateway é feito por meio de

Serviços Web RESTful. Assim, o Monitor é um cliente de Serviço Web RESTful, enquanto que o

Smart Gateway é o servidor. Com base nas informações recebidas sobre os estados e operações da

máquina monitorada, o Smart Gateway cria uma imagem virtual desta. Assim, ao receber uma nova

informação, o Smart Gateway faz a interpretação desta e replica a alteração na imagem virtual da

máquina monitorada. As informações da máquina presentes nesta imagem virtual são disponibilizadas

aos clientes (usuários e dispositivos) por meio de Serviços Web RESTful, podendo ser acessadas

100

diretamente no Smart Gateway. Além disso, periodicamente, o Smart Gateway envia as alterações que

ocorreram na imagem virtual da máquina para a aplicação na Nuvem, a qual faz a persistência na base

de dados da PaaS. Neste trabalho, o envio foi configurado para ocorrer a cada 30s. Assim, a aplicação

na Nuvem faz o papel de servidor do Serviço Web RESTful de Recebimento de Dados, enquanto que

o Smart Gateway faz o papel de cliente.

A Figura 19 mostra a comunicação entre as aplicações de monitoramento de máquinas indus-

triais. Como é mostrado, é possível a comunicação direta entre o Smart Gateway e uma máquina

industrial, via Device Driver e um barramento como SPI ou I2C. Contudo, este cenário não é abordado

neste trabalho.

Em função de não haver uma máquina industrial e um sistema SCADA reais para execução

dos experimentos, foi criado, em Silva (2014a), um simulador do sistema SCADA, chamado aqui

de SIMSCADA. De posse de um arquivo de log gerado por um sistema SCADA de uma máquina

industrial real, o papel do SIMSCADA é simular a gravação de registros de log que é feita pelo

sistema SCADA. Assim, o SIMSCADA copia, linha a linha, o conteúdo do arquivo de log real para o

arquivo de log que o Monitor está monitorando. Desse modo, é possível suprir a falta de uma máquina

industrial real durante os experimentos. A Figura 20 mostra a tela da aplicação SIMSCADA, em

que o campo "Arquivo de Origem"indica o caminho para o arquivo com os logs reais e o campo

"Repositório SCADA"indica o caminho para o arquivo monitorado pelo Monitor. A marcação da caixa

"Manual"indica que uma nova linha será copiada de um arquivo para outro somente quando o usuário

pressionar o botão "Play". Este foi o modo utilizado nos experimentos.

Figura 20. Simulador do Sistema SCADA - SIMSCADA

101

Como prova de conceito, também foram desenvolvidas duas aplicações clientes, que consomem

recursos do Smart Gateway. A primeira aplicação, chamada de Cliente Desktop, foi desenvolvida em

Java, podendo ser portada, com algumas adaptações (principalmente de interface com o usuário), para

um dispositivo móvel como um smartphone ou tablet. A Figura 21 mostra a tela desta aplicação. O

usuário deve preencher o campo de texto com o recurso que deseja monitorar e, ao clicar no botão

"Monitorar Recurso", a aplicação envia uma solicitação HTTP GET ao recurso e exibe o retorno

no campo "Retorno do Provedor de Serviço". Durante os experimentos, foram utilizados recursos

representados em XML.

Figura 21. Aplicação Cliente Desktop

A segunda aplicação, chamada de Cliente Embarcado, também foi desenvolvida em Java e foi

embarcada em um BeagleBone Black. A aplicação funciona de maneira similar ao Cliente Desktop,

contudo sem a interface com usuário, uma vez que o Cliente Embarcado visa simular uma aplicação

autônoma que interage com o Smart Gateway. Ao iniciar a aplicação, o Cliente Embarcado faz uma

requisição HTTP GET ao recurso que será monitorado e exibe o retorno na console, sendo esse

processo executado 50 vezes em intervalos de 5 segundos. Do mesmo modo que no Cliente Desktop,

foram utilizados recursos representados em XML durante os experimentos.

102

4.9.4 Integração da Infraestrutura de Autenticação e de Autorização para a Web

das Coisas

A integração da aplicação de monitoramento de máquinas industriais à AAI4WoT foi realizada

por meio da inclusão de código fonte da AAI4WoT no Smart Gateway, no Serviço de Recebimento

de Dados da aplicação de Nuvem, no Cliente Desktop e no Cliente Embarcado. No caso do Smart

Gateway, este foi integrado tanto para atuar com o papel de cliente quanto com o papel de servidor.

Deve-se ressaltar que a comunicação da aplicação Monitor com o Smart Gateway não foi alterada.

Além da inclusão de código fonte, houve a integração das aplicações com os demais serviços, como o

de autenticação (alocado no Provedor de Identidades - IdP) e de solicitação de decisão de autorização

(alocado no PDP).

A integração ocorreu em três cenários distintos: (i) cenário em que o Smart Gateway é o cliente

de Serviço Web RESTful e envia informações de monitoramento para o Serviço Web RESTful de

recebimento de dados na Nuvem; (ii) cenário em que o Smart Gateway atua como servidor e provê as

informações de monitoramento para um cliente Desktop; e (iii) cenário em que o Smart Gateway atua

como servidor, mas o cliente é uma aplicação embarcada em um BeagleBone Black (dispositivo SP).

No primeiro cenário, o fluxo de mensagens é similar ao mostrado nas Figuras 16 e 17. Uma

das diferenças está no início do fluxo de mensagens, que ocorre antes da autenticação. Neste caso, o

Monitor envia para o Smart Gateway informações de monitoramento da máquina industrial, gravadas

pelo sistema SCADA no arquivo de log. Em seguida, inicia-se o Passo 1, descrito na Figura 16. Outra

diferença está no método HTTP utilizado neste cenário para solicitação do recurso ao SP: ao invés

do método HTTP GET utilizado no protótipo, o Smart Gateway envia os dados para o serviço de

recebimento de dados na Nuvem utilizando o método HTTP PUT. Por fim, no protótipo, o Passo 17

(Figura 17) consiste no fornecimento do recurso ao cliente, enquanto na aplicação de WoT corresponde

à persistência na Nuvem dos dados enviados pelo Smart Gateway.

Neste cenário, o SP (serviço de recebimento de dados da Nuvem) e o PDP estavam alocados

na mesma máquina virtual, contudo em Containers Web distintos (por questões de configurações

diferentes para cada Container). Desse modo, este cenário implementa o Modo de Operação SP Sem

Restrições, descrito na Seção 4.5.2, mas ainda assim permite que um PDP seja utilizado por múltiplos

SPs. Para usufruir da autenticação única, o fluxo de mensagens mostrado na Figura 18 é executado

pelo Cliente Ativo, enquanto o fluxo de mensagens com o SP mantem-se o mesmo.

Para o cenário 2 em que o Smart Gateway atua como servidor e provê recursos para a aplicação

103

Cliente Desktop, foi necessário alterar a aplicação para que esta disponibilizasse um campo para

inserção do endpoint de autenticação do IdP escolhido pelo usuário. A tela da aplicação é mostrada

na Figura 22. Apesar desta alteração, o fluxo de mensagens deste cenário é o mesmo descrito para o

protótipo da AAI4WoT para autenticação de usuários na Seção 4.9.2.

Figura 22. Tela da aplicação Cliente Desktop integrada à AAI4WoT

Neste cenário, o SP (Smart Gateway) e o PDP estavam alocados em diferentes infraestruturas:

o SP estava embarcado em um BeagleBone Black, enquanto que o PDP estava alocado em uma

infraestrutura de computação em Nuvem. Desse modo, verifica-se a implementação do Modo de

Operação SP Restrito, descrito na Seção 4.5.1. Do mesmo modo que no cenário anterior, é possível

que o cliente usufrua da autenticação única. Para usufruir da autenticação única, o fluxo de mensagens

mostrado na Figura 18 deverá ser executado pelo Cliente Desktop e o fluxo de mensagens com o SP se

manterá o mesmo.

O último cenário consiste no Smart Gateway como servidor e na aplicação Cliente Embarcado

como cliente. A aplicação Cliente Embarcado foi integrada à AAI4WoT por meio da inclusão de

código fonte da AAI4WoT à aplicação Cliente Embarcado. Não foi necessário realizar alterações no

fluxo de mensagens do protótipo para realizar a integração da AAI4WoT com a aplicação de WoT neste

104

cenário. Assim, o fluxo de mensagens mantem-se o mesmo descrito para o protótipo da AAI4WoT para

autenticação de dispositivos na Seção 4.9.2. Do mesmo modo que no cenário anterior, o SP (Smart

Gateway) estava embarcado em um BeagleBone Black e o PDP estava alocado em uma infraestrutura

de computação em Nuvem. Para usufruir da autenticação única, o fluxo de mensagens mostrado na

Figura 18 deverá ser executado pelo Cliente Embarcado e o fluxo de mensagens com o SP mantem-se

o mesmo.

4.10 CONSIDERAÇÕES DO CAPÍTULO

A AAI4WoT está alinhada com o conceito de operações sem estado (ZENG; GUO; CHENG,

2011) do REST. Na interação do Cliente Ativo SAML com o SP, primeiro o Cliente Ativo SAML

busca a política de qualidade de proteção do serviço desejado e, só num passo posterior, o cliente tenta

acessar o serviço, já de posse de uma Asserção SAML adequada ao consumo do respectivo recurso.

Desse modo, ao tentar acessar o serviço, o cliente já dispõe das informações que o SP precisa para

tomar a decisão de autorização, a qual independe de decisões anteriormente tomadas. Assim, o SP

não precisa manter um estado (sessão) do cliente para fornecer o serviço. Esse fluxo faz com que haja

uma otimização do uso de recursos do SP, quando comparado ao cenário em que o cliente faz uma

requisição sem possuir uma asserção SAML adequada ao consumo do respectivo serviço.

Uma das alterações que poderia ter impactos positivos no desempenho da AAI4WoT e no

tamanho das mensagens transmitidas na rede é a adição do suporte à conversão da representação

de dados XML para a representação JSON, e vice-versa, para as mensagens e asserções SAML,

requisições e respostas XACML e políticas WS-Policy. Assim, por exemplo, uma asserção SAML seria

representada em JSON ao invés de XML, herdando os benefícios dessa representação, já mencionados

anteriormente. Contudo, apesar dessa conversão estar disponível para os recursos oferecidos na

aplicação de WoT, o que torna tais recursos agnósticos à maneira como são representados (p.e. XML,

JSON e texto plano), a adição desse mesmo suporte para a parte de segurança deste trabalho mostrou-se

inviável. As bibliotecas utilizadas como implementação dos padrões de segurança (SAML, XACML

e WS-Policy) não suportam a representação JSON, o que implicaria na reimplementação destas

bibliotecas para que tal suporte fosse provido e para que estas pudessem ser tratadas de maneira

transparente (sem alterações) por frameworks como o Jersey, uma implementação de referência para

Serviços Web RESTful em Java. Para o caso do IdP SAML utilizado (SimpleSAMLphp), este também

precisaria de adaptações não triviais para que pudesse suportar a conversão de XML para JSON e

vice-versa. Assim, a complexidade de reimplementação destas bibliotecas e as adaptações necessárias

105

tornam o uso do JSON inviável para a parte de segurança deste trabalho. Contudo, deve-se ressaltar

que isto não limita os SPs a proverem recursos representados apenas em XML. O recurso provido pode

ser representado de qualquer maneira, sendo dependente apenas de um acordo entre SP e cliente, uma

vez que as mensagens SAML são transmitidas do cliente para o SP em um cabeçalho HTTP arbitrário.

Uma alteração necessária nos IdPs SAML foi a inclusão do suporte ao contexto de autenticação

que represente eventos de autenticação que utilizaram o mecanismo de autenticação de dispositivos

escolhido, não previstos na especificação original SAML. Uma extensão da especificação SAML,

neste sentido, foi apresentada no Apêndice C. Contudo, a decisão de quais contextos de autenticação

devem ser suportados depende de cada implementação.

106

5 RESULTADOS E AVALIAÇÃO

Esta seção apresenta os experimentos que foram realizados para avaliação do impacto da

integração da AAI4WoT à aplicação de WoT, bem como os resultados da execução de tais experimentos.

Também é apresentada uma análise a respeito dos resultados obtidos.

5.1 EXPERIMENTOS

Durante os experimentos, dois cenários foram comparados:

1. Aplicação de WoT sem uma solução de segurança;

2. Aplicação de WoT integrada à AAI4WoT.

Para ambos os cenários, três subcenários foram comparados:

1. O dispositivo Smart Gateway assume o papel de cliente e envia os dados monitorados da

máquina industrial para a aplicação hospedada na Nuvem, a qual assume o papel de SP.

Este caso implementa o Modo de Operação SP Sem Restrições, em que o SP e o PDP

estão no mesmo ambiente computacional (neste caso, na mesma máquina virtual). Com este

cenário, buscou-se avaliar os impactos do uso da AAI4WoT para um cliente com restrições

computacionais e para um SP com muitos recursos;

2. Uma aplicação desktop (Cliente Desktop) executada em um notebook atua como cliente e

envia requisições para um recurso de monitoramento do Smart Gateway, que neste cenário

atua como SP e está embarcado em um BeagleBone Black. Este cenário implementa o

Modo de Operação SP Restrito, em que o SP está embarcado em um dispositivo com

restrições computacionais e o PDP está em outro ambiente computacional (neste caso,

uma infraestrutura de Computação em Nuvem). Neste cenário, o objetivo foi avaliar os

impactos do uso da AAI4WoT em um SP embarcado em um dispositivo com restrições

computacionais e os impactos em um cliente com muitos recursos que funciona com a

intervenção de um usuário humano; e

3. Uma aplicação embarcada em um BeagleBone Black (Cliente Embarcado) assume o papel

107

de cliente e o Smart Gateway, embarcado em outro BeagleBone Black, assume o papel de

SP. O cliente envia requisições para o mesmo recurso de monitoramento do Smart Gateway

que no cenário anterior. Este caso também implementa o Modo de Operação SP Restrito.

O objetivo deste cenário foi avaliar os impactos do uso da AAI4WoT quando o SP e o

cliente são embarcados em dispositivos com restrições computacionais. No caso do cliente,

este difere do primeiro cenário, uma vez que a aplicação embarcada é mais simples e mais

modesta no uso de recursos (p.e. não faz uso de um servidor de aplicação/container Web) e

atua sem intervenção humana.

Para avaliar a AAI diante dos cenários descritos, foram utilizadas as seguintes métricas:

• Consumo de memória RAM;

• Consumo de espaço de memória flash/disco;

• Tempo de processamento;

• Uso de CPU;

• Vazão da rede (throughput);

• Tamanho das mensagens; e

• Consumo de potência elétrica.

Foram avaliadas diferentes etapas dos processos executados nos cenários mencionados, con-

forme detalhado nas seções a seguir.

5.2 RESULTADOS

Esta seção descreve os resultados obtidos com a execução dos experimentos, os quais foram

executados 50 vezes. A partir destas amostras, foram extraídos os dados que são detalhados a seguir.

5.2.1 Experimento de Footprint

Este experimento visou verificar o custo computacional das aplicações nos diferentes cenários.

Entretanto, não é feita troca de mensagens neste experimento. Os dados obtidos para o Cliente são

108

mostrados na Tabela 21. Para cada métrica, foram calculados a média e o desvio padrão. A memória

RAM e o uso de CPU foram calculados utilizando a ferramenta JMC, considerando o uso de CPU

e memória de todo o sistema (exceto para o Cliente Desktop, em que foi considerado apenas o

consumo da JVM - Java Virtual Machine). A porcentagem de memória RAM tem como referência a

memória RAM total do sistema. O espaço utilizado em flash/disco foi obtido por meio da execução do

comando df, no console do sistema operacional (SO) Linux (exceto para o Cliente Desktop, em que

foi mensurado apenas o tamanho do arquivo executável e das bibliotecas necessárias, visando evitar

interferências do SO do computador em que a aplicação foi executada).

Tabela 2. Footprint - Dados do Cliente

AAIMemória

RAM (MiB)Flash ou

Disco (MB)Uso de

CPU (%)Cenário/Métricas Méd. D. Pad. Méd. D. Pad. Méd. D. Pad.

181 0 1.561,4 0 8,12 5,31Cliente SG -SP Cloud X 255 0 1.580,6 0 4,59 4,54

15,33a 19,25

- 0,6 - 1,35 1,32Cliente Desktop

- SP SG X14,43a 26,1

- 14 - 0,79 0,47

114 0 1.513,9 0 10,28 4,63Cliente Embarc.- SP SG X 118 0 1.589,2 0 10,30 3,01

Com base na Tabela 2, percebe-se que os dados de consumo de memória RAM e de memória

secundária (flash ou disco) possuem desvio padrão nulo, o que ocorre pelo fato de que a aplicação

estava estática, sem troca de mensagens. O mesmo não ocorre quanto ao uso de CPU, o que é atribuído

a outras atividades do próprio SO e à manutenção da aplicação ativa pela JVM. Também é possível

perceber o aumento no consumo de memória RAM, quando se compara o cenário com e sem o uso

da AAI4WoT. Percebe-se o aumento de 40,88% no caso em que o Smart Gateway é o cliente. Esse

aumento diferenciado em relação aos demais cenários ocorre pelo fato de que o Smart Gateway é uma

aplicação implantada em um Container Web, o qual precisa alocar memória RAM para carregar a

aplicação e não libera a memória alocada após o carregamento. Apesar disso, o percentual de memória

RAM consumido com a AAI4WoT foi de 51%. Isto mostra que para este cenário, apesar do impacto,

incluir a AAI4WoT é viável para este dispositivo em termos de memória RAM.

Para os casos dos Clientes Desktop e Embarcado, a Tabela 2 mostra que o impacto na memória1 Nas Tabelas desta seção, "Média"foi abreviado como "Méd."e "Desvio Padrão"foi abreviado como "D. Pad.".

109

RAM ao incluir a AAI4WoT é menor do que no caso do cliente Smart Gateway (35,88% e 3,51%

respectivamente). No caso do Cliente Desktop, os experimentos foram realizados em um notebook

com 3GB de memória RAM. Ao se comparar o máximo de memória RAM consumido com e sem a

AAI em relação ao todo, o percentual de memória consumida passa de 0.64% para 0.87%. No caso

do Cliente Embarcado, o percentual de consumo de memória passa de 22,8% sem a AAI4WoT para

23,6% com a AAI4WoT. Assim, pode-se afirmar que, com base nesta métrica, é viável a inclusão da

AAI4WoT para este cenário.

Sobre o consumo de espaço de memória flash/disco, com base na Tabela 2, percebe-se um

aumento da ordem de 1,6% para o Cliente Smart Gateway e de 4,9% para o Cliente Embarcado, que

resultam, principalmente, das bibliotecas adicionais utilizadas. Para o Cliente Desktop, percebe-se um

aumento do consumo de espaço em disco pelo mesmo motivo, da ordem de 2.233,33%.

A respeito do consumo de CPU (Tabela 2), percebe-se uma pequena diferença no caso do

Cliente Embarcado, para os casos com e sem a AAI. Para os clientes Smart Gateway e Cliente Desktop,

os dados mostram que a aplicação sem AAI consome menos CPU do que com a AAI, o que é o

inverso do que se esperava. A causa para esta diferença não foi investigada, mas pode estar relacionada

a otimizações feitas pela JVM em tempo de execução. Contudo, com base nestes dados, pode-se

perceber que não há um impacto negativo no uso de CPU quando se utiliza a AAI4WoT, o que atesta

sua viabilidade neste aspecto.

Tabela 3. Footprint - Dados do SP

AAIMemória

RAM (MiB)Flash ou

Disco (MB)Uso de

CPU (%)Cenário/Métricas Méd. D. Pad. Méd. D. Pad. Méd. D. Pad.

1.170 0 1.875,6 0 0,46 0,75Cliente SG -SP Cloud X 1.234,5 0 1.907,7 0 0,34 0,35

181 0 1.561,4 0 10,58 2,37Cliente Embarcado eDesktop - SP SG X 250 0 1.580,6 0 6,14 2,11

Os dados obtidos para o SP são mostrados na Tabela 3. Os cenários de Cliente Desktop e

Embarcado foram agregados, uma vez que o SP é o mesmo para ambos. Para o caso do cliente Smart

Gateway, houve um aumento de 5,51% no consumo de memória RAM e de 1,71% no consumo de

memória secundária (disco) quando se compara o cenário com e sem a AAI4WoT. O consumo de CPU,

entretanto, manteve-se estável, abaixo de 0,5% e com desvio padrão abaixo de 0,5. Para o caso em que

110

o SP é o Smart Gateway2, ocorre um aumento no consumo de memória RAM e o consumo de CPU

mostra-se o inverso do esperado, como já mencionado.

Quanto à avaliação de consumo de potência elétrica, foram obtidas 50 amostras, com duração

de 1 segundo cada. De cada amostra, foi obtida uma faixa de consumo (mínimo e máximo). Desse

modo, a Tabela 43 apresenta três colunas principais: (i) Menor Consumo de Potência, que apresenta a

média dos valores de consumo mínimo medidos, o desvio padrão e a faixa de valores das amostras

obtidas; (ii) Maior Consumo de Potência, que apresenta a média dos valores de consumo máximo

medidos, o desvio padrão e a faixa de valores das amostras; e (iii) Faixa de Maior Ocorrência, que

apresenta o intervalo de consumo mais frequente e a representatividade deste valor em relação às

demais amostras.

Tabela 4. Footprint - Dados de Consumo de Potência do Cliente

AAIMenor Consumode Potência (W)

Maior Consumode Potência (W)

Faixa de MaiorOcorrência (W/%)Cenário/

Métrica Méd. D. Pad. Faixa Méd. D. Pad. Faixa Faixa Ocorrênc.

1,05 0 1,05 1,1 0 1,11,05a 1,1

100Cliente SG -

SP Cloud X 1,05 0 1,05 1,1 0 1,11,05a 1,1

100

1,01 0,04941 a

1,351,11 0,0749

1,1 a1,6

1 a1,1

96Cliente Emb.

- SP SG X 1,01 0,0841 a1,6

1,11 0,0841,1 a1,7

1 a1,1

98

As medições de consumo de potência do cliente são mostradas na Tabela 4. É possível perceber

que não houve alterações no consumo de potência para o caso em que o cliente é o Smart Gateway,

ao comparar o cenário com e sem a AAI4WoT. Já para o cenário do cliente embarcado, percebe-se

um aumento nas faixas de consumo mínimo e máximo ao se comparar os cenários com e sem a AAI.

Apesar disso, a faixa de consumo mais frequente mantem-se entre 1 e 1,1 Watts.

As medições de consumo de potência do SP, nos cenários em que o SP está embarcado no

BeagleBone Black, são mostrados na Tabela 5. Percebe-se que ao utilizar a AAI4WoT, o footprint

em termos de potência elétrica é o mesmo do que no cenário em que a AAI não é utilizada. Portanto,2 Este é o mesmo caso da Tabela 2, em que o Smart Gateway é o cliente, haja vista que o Smart Gateway faz papel de

cliente em um cenário e de SP nos outros dois.3 "Cliente Embarcado"foi abreviado como "Cliente Emb.".

111

Tabela 5. Footprint - Dados de Consumo de Potência do SP

AAIMenor Consumode Potência (W)


Faixa de MaiorOcorrência(W/%)Cenário/


1,05 0 1,05 1,1 0 1,051,05a 1,1

100Cliente Desk./Emb. - SP SG X 1,05 0 1,05 1,1 0 1,1

1,05a 1,1

100

percebe-se que os impactos no consumo de potência elétrica são muito pequenos ao incluir a AAI4WoT,

tanto para os SPs como para os clientes. Assim, neste aspecto, é viável utilizar a AAI4WoT.

5.2.2 Experimento de Solicitação de Autenticação

O experimento de Solicitação de Autenticação considerou o processo de solicitação de autenti-

cação do cliente para o IdP, desde a montagem da requisição de autenticação até o recebimento da

asserção SAML pelo Cliente Ativo. O experimento foi dividido em 3 etapas, todas avaliadas apenas no

cliente e nos cenários que utilizaram a AAI4WoT: (i) Montagem da requisição autenticação SAML; (ii)

Solicitação de autenticação (com e sem a autenticação única); e (iii) Processo Completo. As métricas

de uso de CPU e de potência elétrica são consideradas apenas para o processo completo, uma vez que

a granularidade das ferramentas utilizadas nos experimentos não permite a separação das etapas com a

precisão adequada. Os resultados são descritos nas seções seguintes.

5.2.2.1 Experimento de Montagem da Requisição de Autenticação SAML

Esta etapa foi avaliada com as métricas de consumo de memória RAM, consumo de espaço

de memória flash/disco e tempo de processamento. Os dados da avaliação são mostrados na Tabela

6. Os dados de consumo de memória RAM do Cliente Desktop foram obtidos considerando apenas

o consumo da aplicação e não de todo o SO, sendo apresentada uma faixa de consumo de memória

em função da variação no consumo da memória do tipo Heap da JVM. Neste caso, o menor valor

representa a média do mínimo de memória consumido nas amostras, enquanto que o maior valor

apresenta a média do máximo de memória consumida. O mesmo ocorre com o desvio padrão para a

métrica de memória RAM. Sobre o consumo de memória de disco do Cliente Desktop, este não foi

medido, pois é estático e igual aos dados do experimento de footprint, pois é composto apenas do

112

arquivo executável e das bibliotecas utilizadas.

Tabela 6. Montagem da Requisição de Autenticação SAML - Dados do Cliente com a AAI

MemóriaRAM (MiB)

Flash ouDisco (MB)

Tempo deProcessamento (ms)Cenário/

Métrica Média Desvio Pad. Média Desvio Pad. Média Desvio Pad.Cliente SG -

SP Cloud284,76 2,7667 1.554,84 4,2299 265,98 607,5731

Cliente Desktop- SP SG

84,76 -85,63

29,2281 -30,1639

- - 366,92 625,6330

Cliente Embarcado- SP SG

153,1 2,2667 1.587,17 0,2068 378,44 2.406,0917

Ao comparar os dados apresentados na Tabela 6 com os dados do experimento de footprint do

cliente (Tabela 2), para o caso do cliente Smart Gateway com uso da AAI, percebe-se um aumento

de 11,67% no consumo de memória RAM e uma diminuição de 0,42% no consumo de espaço de

memória flash (que pode ser atribuído à fatores externos relacionados à JVM ou ao SO, e não à uma

diminuição decorrente de otimizações da aplicação). Para o cenário do Cliente Desktop, percebe-se um

aumento de, pelo menos, 228,08% no consumo de memória RAM. Já quanto ao Cliente Embarcado,

percebe-se um aumento de 29,75% no consumo de memória RAM e uma diminuição de 0,12% no

consumo de espaço de memória flash (que também não é atribuído à otimizações da aplicação, mas a

fatores externos).

O processo de montagem é composto de três etapas: (i) Carregamento da biblioteca OpenSAML;

(ii) Criação da SAML Authentication Request; e (iii) Preparação da SAML Authentication Request

para envio pela rede (conversões de objetos Java e codificação). Percebeu-se, durante os experimentos,

que o carregamento da biblioteca OpenSAML era a operação mais custosa computacionalmente e que

levava mais tempo para ser executada, tendo grande impacto no tempo de execução do processo e

no desvio padrão obtido (Tabela 6). Para o caso do Cliente Smart Gateway, a implementação teve 6

chamadas de carregamento da biblioteca durante as 50 amostras. Nestas amostras, o carregamento da

biblioteca foi responsável por 86% do tempo de processamento, em média. Para o caso do Cliente

Desktop, todas as amostras executaram o carregamento da biblioteca, que foi responsável por 62,97%

do tempo de processamento, em média. Para o Cliente Embarcado, o carregamento da biblioteca foi

feito apenas uma vez nas 50 amostras, sendo responsável por 91,16% do tempo de processamento para

esta amostra especificamente. Nos cenários em que o carregamento foi feito mais de uma vez para

o conjunto de amostras, percebeu-se que o primeiro carregamento da biblioteca durante o tempo de

113

execução da aplicação é o mais custoso e demorado.

Tabela 7. Tempo de processamento da Montagem da Requisição de Autenticação SAML semcarregamento do OpenSAML - com a AAI

Tempo de Processamento (ms)Cenário/Métrica Média Desvio Padrão

Cliente SG -SP Cloud

47,08 55,1076

Cliente Desktop -SP SG

100,16 55,6924


34,71 7,5728

Deste modo, uma otimização para a aplicação seria carregar a biblioteca apenas uma vez,

no início da execução da aplicação. A Tabela 7 mostra os dados de tempo de processamento médio

e desvio padrão, desconsiderando o carregamento da biblioteca OpenSAML e desconsiderando a

primeira execução do processo de montagem da requisição de autenticação. Isso visa simular uma

situação de execução contínua da aplicação, em que a biblioteca é carregada apenas na inicialização.

Diante da comparação com os dados da Tabela 6, é possível perceber uma diminuição de 82,29%

no tempo médio de montagem da requisição para o cenário em que o Smart Gateway é o cliente.

Uma diminuição de 72,70% e de 90,83% são observadas nos cenários do Cliente Desktop e Cliente

Embarcado, respectivamente.

5.2.2.2 Experimento de Solicitação de Autenticação

Esta etapa foi avaliada com as métricas de consumo de memória RAM, consumo de espaço de

memória flash/disco, tempo de processamento e tamanho das mensagens, para os casos com e sem o

uso da autenticação única, apenas no cliente.

Os resultado de consumo de espaço de memória RAM e memória flash/disco são mostrados

na Tabela 8, para o caso sem autenticação única. Neste caso, os dados de memória RAM do Cliente

Desktop são apresentados em uma faixa, em que o primeiro valor representa a média/desvio padrão

dos valores mínimos obtidos e o segundo valor apresenta os valores máximos de média/desvio padrão

para a métrica. O desvio padrão elevado para o consumo de memória RAM do Cliente Desktop é

atribuído às variações do consumo da memória do tipo "Heap", a qual sofre a intervenção periódica da

JVM, via Garbage Collector, para desalocação de memória RAM que não é mais utilizada. Os demais

114

Tabela 8. Solicitação de Autenticação Sem Autenticação Única - com a AAI

Memória RAM (MiB) Flash/Disco (MB)Cenário/Métrica Média Desvio Padrão Média Desvio Padrão


303,64 16,8724 1.555,6 2,8023


110,16 - 138,25 43,6948 - 46,3343 - -


155,88 3,6715 1.588,77 0,4994

clientes tiveram suas medições feitas considerando o consumo do sistema como um todo, e não apenas

da aplicação.

Tabela 9. Solicitação de Autenticação Com Autenticação Única - com a AAI

MemóriaRAM (MiB)

Flash ouDisco (MB)Cenário/

Métrica Média Desvio Padrão Média Desvio PadrãoCliente SG -

SP Cloud283,09 5,3413 1554,84 4,2299


78,33 - 81,83 26,7052 - 25,6443 - -


153,13 2,2659 1587,21 0,2429

Para o caso com autenticação única, os dados obtidos são mostrados na Tabela 9. Ao se

comparar os resultados das Tabelas 8 e 9, percebe-se que o consumo de espaço de memória flash/disco

manteve-se muito próximo nos cenários com e sem autenticação única. O mesmo ocorre para o

consumo de memória RAM no caso do Cliente Embarcado. No caso do cliente Smart Gateway e do

Cliente Desktop, observa-se que, sem autenticação única, houve maior consumo de memória RAM e

também mais variações no consumo, uma vez que o desvio padrão foi mais elevado.

Vale ressaltar que, ao observar os dados das Tabelas 8 e 9, percebe-se que o consumo de

memória RAM sempre ficou dentro das capacidades computacionais do BeagleBone Black, nunca

chegando próximo de 100% de uso deste recurso (sem autenticação única, em média 60,73% e 31,17%

para os clientes Smart Gateway e Embarcado, respectivamente; com autenticação única, em média

56,62% e 30,63% para os clientes Smart Gateway e Embarcado, respectivamente).

115

Tabela 10. Solicitação de Autenticação com e sem Autenticação Única - Tamanho das Mensagens -com a AAI

Sem Autenticação ÚnicaTamanho das Mensagens

Cliente ->IdP (Bytes)Tamanho das Mensagens

IdP ->Cliente (Bytes)Cenário/Métrica Média Desvio Padrão Média Desvio Padrão


7.806 0 69.636 0


3.298 0 2.8408 0


9.025,16 772,4 92.675,74 20.173,7469

Com Autenticação ÚnicaCliente SG -

SP Cloud1.594 0 2.951 0


1.761 0 12.751 0

Cliente Embarcado -SP SG

1.777 0 14.287 0

A Tabela 10 apresenta os dados obtidos para a métrica de tamanho das mensagens trocadas,

para os cenários com e sem autenticação única. O valor médio e desvio padrão foram calculados sobre

a soma de todas as mensagens trocadas entre cliente e IdP, para o caso de uma autenticação completa

(sem autenticação única) ou para a solicitação/resposta de uma Asserção SAML (com autenticação

única). São mostrados os tamanhos médios das mensagens enviadas do cliente para o IdP e vice-versa.

Os valores apresentados foram obtidos de um canal criptografado e são referentes a todos os segmentos

TCP (Transmission Control Protocol) trocados entre as partes em cada caso, incluindo as mensagens

necessárias à criação/manutenção do canal TLS.

Assim, os resultados da Tabela 10 mostram que, para o caso com autenticação única, a

quantidade de dados trocados entre as partes para a obtenção de uma asserção SAML é menor. Isso

ocorre em função do menor número de troca de mensagens para o respectivo caso, conforme descrito

na Seção 4.9.4. Observa-se também que, para o caso com autenticação única, o Cliente Desktop troca

menos dados com o IdP que nos demais casos, o que já era esperado em função do menor número de

troca de mensagens com o IdP, conforme descrito na Seção 4.9.4.

Em relação ao tamanho total das mensagens trocadas entre cliente e IdP durante o processo de

116

autenticação (Tabela 10), é possível perceber que o tamanho das mensagens enviadas pelo IdP para o

cliente, principalmente nos casos sem autenticação única, é bastante elevado. Para que isto possa ser

otimizado, são necessárias melhorias tanto no IdP quanto no fluxo de mensagens entre cliente e IdP.

Tabela 11. Solicitação de Autenticação com e sem Autenticação Única - Tempo de Processamento -com a AAI

Tempo deProcessamento sem

Autenticação Única (ms)

Tempo deProcessamento com

Autenticação Única (ms)Cenário/Métrica Média Desvio Padrão Média Desvio Padrão

Cliente SG - SP Cloud 5.222,08 1.012,5993 1.411,56 883,5856

Cliente Desktop - SP SG 1.400,26 276,8389 747,38 172,8207

Cliente Embarcado - SP SG 5.120,75 931,9628 832,22 124,911

A Tabela 11 apresenta os dados para o tempo total de processamento com e sem autenticação

única. Com a autenticação única, observa-se uma diminuição de 72,97% para o cliente Smart Gateway,

de 46,63% para o Cliente Desktop e de 83,75% para o Cliente Embarcado. Vale ressaltar que os dados

obtidos estão sujeitos à influências da rede de comunicação, mas foram obtidos no mesmo ambiente

de rede (de acordo com cada cenário).

É possível perceber que no processo de obtenção de uma asserção SAML, seja ele com ou sem

autenticação única, a etapa mais custosa é a troca de mensagens com o IdP. Com base nos dados das

Tabelas 7 e 11, pode-se perceber que a operação de montagem da requisição de autenticação possui

tempos de processamento aceitáveis, se (i) comparados com o processo de cálculo do response para

o challenge, que leva em média 485,38ms (desvio padrão de 67,9) para o cliente Smart Gateway e

482,42ms (desvio padrão de 69,55) para o Cliente Embarcado e (ii) ao calcular a participação deste

processo no tempo total de obtenção da SAML Response (os dados das Tabelas 7 e 11 foram somados

e a participação de cada um no todo é mostrada na Tabela 12). Percebe-se, assim, que a troca de

mensagens para autenticação precisa ser melhorada para tornar-se viável neste sentido, principalmente

para os casos em que há mais trocas de mensagens com o IdP (Clientes Smart Gateway e Embarcado).

5.2.2.3 Experimento de Processo de Autenticação Completo

Esta etapa corresponde ao processo completo que o cliente deve executar para se autenticar

(montagem da requisição de autenticação SAML e solicitação de autenticação, apresentadas nas Seções

5.2.2.1 e 5.2.2.2 respectivamente). Os experimentos foram realizados para os cenários com e sem a

117

Tabela 12. Participação dos subprocessos no processo de obtenção de uma asserção SAML - com aAAI

SSOMontagem da

Requisição de AutenticaçãoTroca de Mensagens

com o IdPCenário/Métrica Participação no Tempo Total de Processamento (%)

0,89 99,11Cliente SG -SP Cloud X 3,23 96,77

6,68 93,32Cliente Desktop- SP SG X 11,82 88,18

0,67 99,33Cliente Embarcado- SP SG X 4 96

autenticação única, apenas no cliente. As métricas utilizadas foram o tempo total de processamento, o

consumo de potência e o uso de CPU.

Tabela 13. Processo de Autenticação Completo com e sem Autenticação Única - com a AAI

Tempo deProcessamento sem

Autenticação Única (ms)

Tempo deProcessamento com

Autenticação Única (ms)Cenário/Métrica Média Desvio Padrão Média Desvio Padrão

Cliente SG - SP Cloud 7.174,66 1.804,38 1.422,22 817,9582

Cliente Desktop - SP SG 1.680,26 380,8508 1.027,38 231,1579

Cliente Embarcado - SP SG 5.175,45 941,425 866,91 125,0489

Os dados obtidos para o tempo total de processamento são mostrados na Tabela 13. É possível

perceber o elevado desvio padrão dos dados obtidos, o que justifica-se pelas interferências externas

aos experimentos, como aquelas da rede de comunicação. Percebe-se também, para o caso do cliente

Smart Gateway, uma diminuição de 80,18% do tempo de processamento, quando se compara o caso

sem e com autenticação única. Uma diminuição de 38,86% e de 83,25% é observada para os Clientes

Desktop e Embarcado, respectivamente.

A Tabela 14 mostra os dados referentes ao consumo de CPU do cliente para os cenários com e

sem autenticação única. Os processos sem autenticação única dos cenários do cliente Smart Gateway

e do Cliente Embarcado envolveram o carregamento da biblioteca OpenSAML a cada execução, o

que levou o uso de CPU a 100%. Assim, os dados da Tabela 14 são referentes aos processos que

ocorrem após o carregamento da biblioteca. É possível perceber que para o caso do cliente Smart

Gateway, apesar do uso de CPU chegar a 100% para o limiar máximo nos dois casos (com e sem

118

Tabela 14. Processo de Autenticação Completo com e sem Autenticação Única - Uso de CPU - com aAAI

Sem Autenticação ÚnicaMenor Uso de CPU (%) Maior Uso de CPU (%)Cenário/

Métrica Média D. Pad. Faixa Média D. Pad. FaixaCliente SG - SP Cloud 1,98 2,43 0 a 5,55 90,38 15,9062 50 a 100

Cliente Desktop - SP SG 0 0 0 62,16 12,5047 45 a 85

Cliente Embarcado - SP SG 0 0 0 100 0 100

Com Autenticação ÚnicaCliente SG - SP Cloud 5,27 4,6717 0 a 21,42 45,42 22,6108 8,33 a 100

Cliente Desktop - SP SG 0 0 0 64,95 13,7119 47,61 a 94

Cliente Embarcado - SP SG 0 0 0 68,35 19,1857 43,75 a 100

autenticação única), a média do valor máximo no caso com autenticação única e a faixa de valores

obtidos diminui, o que indica um menor uso de CPU ao longo do tempo. Para o Cliente Desktop, o

uso de CPU manteve-se similar para os dois casos, o que não ocorre com o Cliente Embarcado. Neste

último, a média de uso de CPU do limiar máximo fica abaixo de 100% para o caso com autenticação

única, assim como a faixa de valores máximos de uso de CPU, o que indica um menor uso do recurso

quando comparado ao caso sem autenticação única.

Ao se considerar o processo de autenticação e não apenas o footprint, observa-se que a

AAI4WoT precisa ser otimizada para tornar-se mais viável em termos do tempo de processamento, do

uso de CPU e do tamanho das mensagens. Um dos aspectos que precisa ser refatorado é o carregamento

da biblioteca OpenSAML. Observou-se que esse processo precisa ser executado apenas uma vez,

quando a aplicação é iniciada, o que não ocorre em muitos cenários da AAI4WoT. Os impactos diretos

do carregamento da biblioteca puderam ser observados nas Tabelas 6, 7) e 14.

A Tabela 15 apresenta os dados de consumo de potência elétrica para o processo de autenticação

do cliente, para os casos com e sem autenticação única do cliente Smart Gateway e Cliente Embarcado.

Observa-se que para ambos os clientes, tanto com como sem autenticação única, o consumo mínimo

de potência mantem-se estável. Entretanto, ao se comparar os cenários com e sem autenticação única

quanto ao consumo máximo de potência, há um aumento de 53,57% quando não se tem a autenticação

única, para o cliente Smart Gateway. Para o Cliente Embarcado, o aumento é de 54,05%. Tal aumento

está relacionado às trocas de mensagens que existem na autenticação completa e não existem no

cenário de autenticação única. Tais trocas foram realizadas em todas as amostras sem autenticação

única. Este aumento também está relacionado à carga da biblioteca OpenSAML para todas as amostras

119

Tabela 15. Processo de Autenticação Completo com e sem Autenticação Única - Consumo dePotência - com a AAI

Sem Autenticação ÚnicaMenor Consumode Potência (W)



Métrica Méd. D. Pad. Faixa Méd. D. Pad. Faixa Faixa Ocorrênc.Cliente SG -

SP Cloud1,05 0 1,05 1,72 0,0318

1,65 -1,75

1,05 -1,75

50


1,05 0 1,05 1,71 0,03471,65 -1,75

1,05 -1,7

50

Com Autenticação ÚnicaCliente SG -

SP Cloud1,05 0 1,05 1,12 0,0245

1,1 -1,15

1,05 -1,1

60


1,003 0,0211 -

1,151,11 0,051

1,1 -1,45

1 -1,1

86

sem autenticação única, aspecto que pode ser otimizado, como já comentado anteriormente.

Ao se comparar o consumo de potência da etapa de autenticação (Tabela 15) com o consumo de

potência do experimento de footprint (Tabela 4), percebe-se que o consumo de footprint e do cenário

com autenticação única é similar. Já quanto ao cenário sem autenticação única comparado ao footprint,

percebe-se um aumento na média de consumo máximo da ordem de 53,78% para o cliente Smart

Gateway e de 53,78% para o Cliente Embarcado.

Sobre autenticação única na AAI4WoT, observa-se ao comparar as Tabelas 8 e 9, o benefício

de seu uso em termos de consumo de memória RAM. Em função do menor número de mensagens

trocadas com o IdP, o tamanho total das mensagens trocadas também diminui e torna o processo de

autenticação mais viável neste sentido. Em relação ao tempo de processamento, observa-se também

que o uso da autenticação única permite tornar o processo mais rápido, conforme mostrado nas Tabelas

11 e 13. Benefícios do uso da autenticação única neste cenário também podem ser percebidos no uso

de CPU, conforme a Tabela 14. Em relação ao consumo de potência, observa-se na Tabela 15 uma

redução da faixa de consumo de maior ocorrência, o que é importante ao se considerar a autonomia do

sistema.

120

5.2.3 Experimento de Solicitação de Serviço ao SP

Este experimento considerada o passo a partir do qual é realizada a solicitação do recurso ao

SP. O experimento foi executado para os três clientes, sem o uso da AAI4WoT e com o uso desta.

Tabela 16. Solicitação ao SP com e sem a AAI4WOT - Dados do Cliente - Memória RAM,Flash/Disco e Tempo de Processamento

Sem a AAI4WOTMemória

RAM (MiB)Flash ou

Disco (MB)Tempo de

Processamento (ms)Cenário/Métrica Média D. Pad. Média D. Pad. Média D. Pad.

Cliente SG- SP Cloud

195,08 1,2937 1.548,23 0,9775 4.558,92 2.446,8362


18,43-22,60

0,1827-0,1446

- - 49,08 103,0042


118,11 0,4814 1.500,43 0,0012 139,06 488,0755

Com a AAI4WOTCliente SG- SP Cloud

285,07 2,0946 1.561,42 0,7954 8.978,8 3.320,8054


72,96-99,62

23,4085-27,9028

- - 3330,98 189,0984


153,21 2,282 1.585,18 13,958 3.477,96 361,9373

A Tabela 16 apresenta os resultados obtidos para as métricas de consumo de espaço em memória

RAM, consumo de espaço de memória flash/disco e tempo de processamento para o cliente. Os dados

de memória RAM do Cliente Desktop são exibidos em uma faixa, composta pela média/desvio padrão

do mínimo mensurado e pela média/desvio padrão do máximo mensurado, em função da maneira como

os dados foram obtidos, como mencionado anteriormente. Também, estes dados sofrem interferência

do Garbage Collector, o que explica o desvio padrão mais elevado que nos demais casos. Observa-se,

ao se comparar os cenários com e sem o uso da AAI4WoT, que ao utilizar a AAI, o consumo médio

de memória RAM do cliente Smart Gateway é aproximadamente 46,13% maior, o que também pode

ser observado no Cliente Desktop (aumento de 295,88% para o mínimo consumido e de 340,8%

para o máximo) e no Cliente Embarcado (aumento de 29,72%). Sobre o consumo de espaço de

memória flash/disco, observa-se um aumento de 0,85% no cliente Smart Gateway e 5,65% no Cliente

Embarcado. O Cliente Desktop não teve dados para esta métrica, uma vez que esta refere-se somente

121

ao tamanho da própria aplicação e mantem-se igual aos resultados do experimento de Footprint.

Apesar dos impactos mostrados na Tabela 16, também observa-se que o consumo esteve dentro

das capacidades computacionais do dispositivo utilizado nos experimentos. Para o cliente Smart

Gateway, o consumo médio foi de 57.01%, para o Cliente Desktop foi de 3.32% e para o Cliente

Embarcado foi de 30.64% sendo, portanto, viável a utilização da AAI4WoT neste caso.

Tabela 17. Solicitação ao SP com e sem a AAI4WOT - Dados do Cliente - Tempo de Processamentocorrigido

AAI Tempo de Processamento (ms)Cenário/Métrica

Média Desvio Padrão4.210,18 168,3453Cliente SG - SP Cloud

X 8.515,08 707,8617

27,65 10,0255Cliente Desktop - SP SGX 3.330,98 189,0984

69,39 19,1895Cliente Embarcado - SP SGX 3.477,96 361,9373

Quanto aos dados de tempo de processamento (Tabela 16), observou-se nas amostras a presença

de outliers nos casos sem AAI4WoT e no caso em que o cliente Smart Gateway utiliza a AAI4WoT.

Tais dados ocorrem em função da inicialização dos frameworks utilizados, tanto no cliente como no

SP, o que ocorre apenas uma vez durante a execução. Ao retirar estes dados das amostras, observa-se

que a média de tempo de processamento e o desvio padrão das solicitações ao SP, por parte do cliente,

diminui. Isso mostra uma tendência de comportamento ao longo do tempo mais fiel à realidade e pode

ser observado na Tabela 17.

Tabela 18. Solicitação ao SP com e sem a AAI4WOT - Dados do Cliente - Tamanho das Mensagens

AAI Tamanho das Mensagens (Bytes)Cliente ->SP SP ->ClienteCenário/Métrica

Média Desvio Padrão Média Desvio PadrãoCliente SG - SP Cloud 423,34 9,1861 91 0

Cliente SG - SP Cloud X 13.193,22 16,9674 148,08 13,5644

Cliente Desktop - SP SG 211 0 213,78 2,9684

Cliente Desktop - SP SG X 11.644,22 37,38 375,33 194,74

Cliente Embarcado - SP SG 211 0 210 0

Cliente Embarcado - SP SG X 13.134,86 6,02 473,66 179,62

122

A Tabela 18 mostra os dados de tamanho das mensagens trocadas entre cliente e SP para este

experimento. O tamanho das mensagens corresponde a todas as trocas, tendo sido obtidas métricas

de todo o segmento TCP. Isso inclui, portanto, além dos dados de aplicação, as trocas necessárias

ao estabelecimento/manutenção do canal TLS. Isto explica o elevado desvio padrão das amostras de

mensagens do SP para os cliente Desktop e Embarcado quando se utiliza a AAI4WoT, uma vez que

há apenas uma mensagem fora do padrão das demais, referente ao envio do certificado digital do SP

para o cliente (apenas o SP é autenticado via certificado digital neste fluxo). Retirando esta amostra da

população, o tamanho médio das mensagens do SP para o Cliente Desktop é de 340 Bytes e do SP para

o Cliente Embarcado é de 448 Bytes, ambos com desvio padrão nulo. Ao se considerar estes dados,

observa-se um aumento de 3.016,46% no tamanho da solicitação enviada do cliente Smart Gateway

para o SP. Do mesmo modo, observa-se um aumento de 5.418,49% para as solicitações do Cliente

Desktop e de 6.125,05% para as solicitações do Cliente Embarcado. No fluxo inverso, as respostas do

SP aumentaram 62,73%, 72,06% e 125,55% para os clientes Smart Gateway, Desktop e Embarcado,

respectivamente. O aumento do tamanho das mensagens do SP para o cliente justifica-se pelo overhead

causado pelo canal TLS. Já o aumento das mensagens do cliente para o SP justifica-se também pelo

overhead do canal TLS mas, principalmente, pela inclusão de uma mensagem SAML no cabeçalho da

requisição HTTP.

Tabela 19. Solicitação ao SP com e sem a AAI4WOT - Dados do Cliente - Consumo de Potência

Menor Consumode Potência (W)



Métrica Méd. D. Pad. Faixa Méd. D. Pad. Faixa Faixa Ocorrênc.Cliente SG -

SP Cloud - S/ AAI1,134 0,2082

1,05 -1,65

1,203 0,22241,1 -1,75

1,05- 1,1

66

Cliente SG -SP Cloud - C/ AAI

1,05 0 1,05 1,11 0,021,1 -1,15

1,05- 1,1

80

Cliente Embarcado- SP SG - S/ AAI

1,009 0,0631 -

1,451,112 0,084

1,1 -1,7

1 -1,1

98

Cliente Embarcado- SP SG - C/ AAI

1,028 0,0951 -

1,351,131 0,0953

1,1 -1,45

1 -1,1

88

A Tabela 19 mostra os dados obtidos para a métrica de consumo de potência nos clientes

Smart Gateway e Embarcado. É possível perceber uma diminuição de aproximadamente 0,1 Watt

no consumo do cliente Smart Gateway, quando este está utilizando a AAI4WoT, o que não era um

resultado esperado, haja vista que não foram feitas otimizações neste sentido. Outro valor que não

era esperado é a diminuição das faixas de consumo mínimo e máximo, quando compara-se o cenário

123

do Cliente Embarcado sem AAI4WoT com o cenário com AAI. Apesar disso, observa-se que para o

Cliente Embarcado, o consumo médio de potência é similar se a AAI4WoT for utilizada ou não.

Ao comparar os dados da Tabela 19 com os dados do experimento de Footprint (Tabela 4),

observa-se, para o cliente Smart Gateway sem AAI, um aumento de 8% no consumo mínimo e de 9,36%

para o consumo máximo. Para o cenário com AAI, o consumo mínimo foi igual ao do experimento de

Footprint, enquanto que o consumo máximo aumentou 0,91%. Para o Cliente Embarcado sem AAI, o

consumo mínimo aumento 0,1%, enquanto que o consumo máximo diminuiu 0,18%. Ao utilizar a AAI,

observa-se um aumento no consumo mínimo do Cliente Embarcado de 1,58% e do consumo máximo

de 1,71%. Contudo, pode-se dizer que não há grades impactos no consumo ao utilizar a AAI4WoT,

haja vista que a faixa de consumo mais frequente mantem-se a mesma, mesmo quando são comparados

os dados deste experimentos com os dados de Footprint (Tabela 4).

Tabela 20. Solicitação ao SP com e sem a AAI4WOT - Dados do Cliente - Uso de CPU

AAI Menor Uso de CPU (%) Maior Uso de CPU (%)Cenário/Métrica Média D. Pad. Faixa Média D. Pad. Faixa

7,36 2,69450 -

9,0954,98 25,4567

26,66- 100

Cliente SG - SP CloudX 1,3 2,0918

0 -4,76

45,15 24,495117,39- 100

0 0 0 2,18 1,34400,51

- 10,1Cliente Desktop - SP SG

X 0 0 0 44,02 16,571725 -85

0 0 0 14,55 13,38955 -100

Cliente Embarcado - SP SGX 0 0 0 63,53 18,4088

38,88- 100

Os dados de uso de CPU dos clientes são apresentados na Tabela 20. Ao comparar os cenários

com e sem a AAI4WoT para o cliente Smart Gateway, observa-se uma diminuição de 82,33% no

consumo médio mínimo de CPU e de 17,88% no consumo médio máximo de CPU. Ao contrário, nos

cenários com os Cliente Desktop e Embarcado, observa-se que o consumo médio mínimo mantem-se

igual, mas o consumo médio máximo aumenta 1.919,27% e 336,63%, respectivamente. Pelo fato de

que as bibliotecas utilizadas foram as mesmas em todos os clientes, essa diferença entre o cenário do

cliente Smart Gateway para os demais cenários pode estar relacionada com o uso do Container Web

124

pelo Smart Gateway, o qual pode realizar otimizações no carregamento/execução da aplicação que não

foram realizadas nos demais cenários, pela ausência de um Container Web nestes casos.

Tabela 21. Solicitação ao SP com e sem a AAI4WOT - Dados do SP

AAIMemória

RAM (MiB)Flash ou

Disco (MB)Tempo de

Processamento (ms)Cenário/Métrica Média D. Pad. Média D. Pad. Média D. Pad.

1.250 14,0712 1.875,96 0,0058 3.982,86 128,8023Cliente SG- SP Cloud X 1.461,06 7,1601 1.920,23 0,3415 7.836,18 1.089,9178

185,93 0,5789 1.550,52 0,0044 0,29 0,7948Cliente Embarcadoe Desktop - SP SG X 268,9 2,3169 1.565,33 0,1763 3.078,14 140,1422

Os dados de consumo de memória RAM, consumo de espaço de memória flash/disco e tempo de

processamento da solicitação para os SPs são mostrados na Tabela 21. Os cenários de Cliente Desktop

e Embarcado foram agregados, haja vista que o SP é o mesmo. Para o caso do cliente Smart Gateway,

quando se compara o cenário sem AAI4WoT com o cenário em que a AAI é utilizada, percebe-se

um aumento de 16,88% no consumo de memória RAM, 2,36% no consumo de espaço em disco e

de 96,75% no tempo de atendimento da requisição. Para o cenário do Cliente Embarcado/Desktop,

ao fazer a mesma comparação, observa-se um aumento de 44,62% no consumo de memória RAM,

de 0,96% no consumo de espaço da memória flash e de 1.061.327,59% no tempo de atendimento da

solicitação. O aumento no tempo de atendimento da solicitação para o caso da AAI4WOT deve-se,

principalmente, ao tempo adicional necessário à tomada de decisão de autorização, realizada fora do

SP.

Tabela 22. Solicitação ao SP com a AAI4WOT - Dados do SP - Tamanho das Mensagens

Tamanho das Mensagens SP ->PDP (Bytes)SP ->PDP PDP ->SPCenário/Métrica

Média Desvio Padrão Média Desvio PadrãoCliente SG - SP Cloud 5.580 0 14.393 0

Cliente Embarcado eDesktop - SP SG

3.099,1 175,7 803,56 1.928,92

Os dados de tamanho das mensagens trocadas entre SP e PDP, quando a aplicação de WoT

usa a AAI4WoT, são mostrados na Tabela 22. Os dados dos Clientes Embarcado e Desktop foram

novamente agregados. Para este último caso, observa-se um desvio padrão elevado, resultante de uma

das amostras que contém a troca de certificados digitais entre SP e PDP para estabelecimento do canal

125

TLS. Ao desconsiderar essa amostra, a média de tamanho da mensagem do SP para o PDP cai para

3074 Bytes e do PDP para o SP cai para 528 Bytes, com desvio padrão nulo para ambos.

Tabela 23. Solicitação ao SP com e sem a AAI4WOT - Dados do SP - Uso de CPU

AAIMenor Uso de

CPU (%)Maior Uso de

CPU (%)Cenário/Métrica Média D. Pad. Faixa Média D. Pad. Faixa

0,76 0,41090 -

1,569,1 17,603

0,72 -87,96

Cliente SG -SP Cloud X 62,79 23,1919

0 -87,11

90,61 11,0770,65 -

100

10,01 4,33735,15 -30,2

10,01 4,33735,15 -30,2Cliente Embarc. e Desk.

- SP SG X 0 0 0 100 0 100

A Tabela 23 mostra os dados de uso de CPU do SP para os casos com e sem o uso da AAI4WoT.

Para o caso do cliente Smart Gateway, em que o SP está na Nuvem, ocorre um aumento de 8.160,53%

no uso mínimo de CPU, enquanto que o uso máximo aumenta 895,71%. Para o caso sem o uso da

AAI dos Clientes Desktop e Embarcado, em que o SP está embarcado em um BeagleBoneBlack, o

tempo de processamento é muito curto para uma medição precisa de uma faixa de valores, conforme

mostrado na Tabela 21 e, por isso, os dados de consumo mínimo e máximo são iguais. Neste caso, ao

utilizar a AAI4WoT, percebeu-se que o uso de CPU variou em todas as amostras de 0% a 100%.

Tabela 24. Solicitação ao SP com e sem a AAI4WOT - Cenário Cliente Embarcado - Dados do SP

Menor Consumode Potência (W)




Sem a AAI4WoT 1,06 0,07751 -1,6

1,13 0,09911,1 -1,8

1,05- 1,1

74

Com a AAI4WoT 1,6 0,07471,45- 1,7

1,75 0,01581,7 -1,85

1,65 -1,75

62

A Tabela 24 apresenta os dados de consumo de potência para o caso em que o SP é embarcado

em um BeagleBone Black. É possível perceber que, quando o SP utiliza a AAI4WoT, ocorre um

aumento de 50,94% na média de consumo mínimo de potência e de 54,87% na média de consumo

máximo. Por meio dos dados da Tabela 24, pode-se inferir também que o impacto observado implica

126

em um maior consumo de potência elétrica no decorrer do tempo, uma vez que a faixa de consumo

mais frequente aumenta aproximadamente 59%.

Tabela 25. Solicitação ao SP com a AAI4WOT - Dados do PDP

MemóriaRAM (MiB)

Tempo deProcessamento (ms)Cenário/

Métrica Média Desvio Padrão Média Desvio PadrãoCliente SG - SP Cloud 1.461,06 7,1602 14,7 7,953

Cliente Embarcado/Desktop - SP SG 1.380,53 0,2671 16,72 7,4479

Os dados de consumo de memória RAM do PDP e do tempo de processamento das requisições

são apresentados na Tabela 25. No cenário em que o cliente é o Smart Gateway, o PDP está na mesma

máquina virtual do SP, alocada em uma infraestrutura de Nuvem. No cenário dos Clientes Desktop

e Embarcado, o PDP está alocado na Nuvem e o SP está embarcado em um BeagleBone Black. Ao

executar o SP e o PDP na mesma máquina virtual, é natural que exista um maior consumo de memória

RAM, como pode ser visto na Tabela 25.

Ao se observar os dados das Tabelas 17 e 21 em conjunto, percebe-se que a maior parte do

tempo de processamento da solicitação sem AAI reside no tempo para a mensagem ir do cliente ao

SP e do SP para o cliente. Para o cenário com AAI, observa-se que, além do tempo de envio das

mensagens, o tempo para envio da solicitação de decisão de autorização para o PDP compõe a maior

parte do tempo de processamento. Ao analisar estes dados junto com os dados da Tabela 25, percebe-se

que o tempo de tomada de decisão de autorização pelo PDP é pequeno. Portanto, pode-se inferir que a

maior parte do tempo de processamento da solicitação de serviço ao SP reside no envio/recebimento e

trânsito pela rede de mensagens trocadas entre os componentes. Com base nisso, pode ser inviável

utilizar a AAI4WoT em ambientes de rede em que a taxa de transferência do canal de comunicação

seja muito restrita.

5.2.4 Experimento do Processo Completo

O processo completo de obtenção do recurso desejado pelo cliente foi mensurado, para os

casos com e sem a AAI4WoT e para os casos com e sem autenticação única. Para isto, foram utilizadas

as métricas de consumo de memória RAM, consumo de espaço da memória flash/disco e tempo total

de processamento. A Tabela 26 apresenta os dados obtidos. Vale ressaltar que os dados dos cenários

sem AAI são os mesmos da Tabela 16, uma vez que sem o uso da AAI4WoT o processo de obtenção

127

do recurso é composto apenas pela solicitação do recurso ao SP e respectiva resposta.

Tabela 26. Processo Completo com e sem a AAI4WOT - com e sem Autenticação Única - Dados doCliente

AAI SSOMemória

RAM (MiB)Flash ou

Disco (MB)Tempo de

Processamento (ms)Cenário/Métrica Média D. Pad. Média D. Pad. Média D. Pad.Cli. SG -SP Cloud

195,08 1,2937 1.548,23 0,9775 4.558,92 2.446,8362

Cli. SG -SP Cloud

X 305,70 13,0084 1.556,54 3,4141 15.106,66 1.713,7693

Cli. SG -SP Cloud

X X 285,38 2,17065 1.561,05 1,7724 9.802,76 1.346,4

Cli. Desk.- SP SG

18,43-22,60

0,1827-0,1446

- - 49,08 103,0042

Cli. Desk.- SP SG

X59,22-97,65

10,37-18,78

- - 5.045,12 652,1111

Cli. Desk.- SP SG

X X66,99-109,83

21,7178-23,4493

- - 4.426,06 576,8967

Cli. Embarc.- SP SG

118,11 0,4814 1.500,43 0,0012 139,06 488,0755

Cli. Embarc.- SP SG

X 158,55 14,3691 1.586,77 14,0603 8.570,72 973,3065

Cli. Embarc.- SP SG

X X 153,22 2,276 1.587,21 0,2429 4.344,87 401,1636

Com base na Tabela 26, é possível perceber que ao utilizar a AAI4WoT no caso do cliente

Smart Gateway, há um aumento no consumo de memória RAM de, em média, 56,7% quando a

autenticação única não é utilizada, contra 46,9% quando se utiliza a autenticação única. O consumo

de espaço da memória flash do cliente aumenta 0,54%, em média, quando não se usa a autenticação

única, e 0,83% quando esta é utilizada. Quanto ao tempo para obter o recurso, ocorre um aumento de

231,36% sem autenticação única e de 115,02% com autenticação única.

Para o cenário do Cliente Desktop (Tabela 26), percebe-se que quando a AAI4WoT é utilizada

sem autenticação única, ocorre um aumento no consumo mínimo de memória RAM 221,32% e de

332,08% para o consumo máximo. Ao utilizar a autenticação única, o consumo mínimo de memória

RAM aumenta 263,48%, enquanto o consumo máximo aumenta 385,97%. Em relação ao tempo para

obter o recurso, ao utilizar a AAI4WoT sem autenticação única, o Cliente Desktop demora 10.179,38%

128

a mais para realizar todo o processo, enquanto que demora 8.918,05% a mais quando a autenticação

única é utilizada.

No cenário do Cliente Embarcado (Tabela 26), o consumo de memória RAM aumenta 34,24%

quando a AAI4WoT é utilizada sem autenticação única. Com autenticação única, há um acréscimo de

29,73% no consumo de memória RAM. O uso de espaço da memória flash também aumenta ao se

utilizar a AAI4WoT, em 5,75% sem autenticação única e 5,78% com autenticação única. Em relação

ao tempo para obter o recurso desejado, este aumenta 6.063,33% ao se utilizar a AAI4WoT sem

autenticação única e 3.024,46% quando esta é utilizada.

5.2.5 Experimento de Vazão da Rede

Figura 23. Experimento de Vazão da Rede - BeagleBone Black atua como SP

O último experimento realizado compreende a métrica de vazão da rede. Este experimento foi

realizado em dois cenários: (i) um cliente de Serviço Web RESTful implementado por meio de uma

129

aplicação Desktop Java, envia mensagens HTTPS para um Serviço Web RESTful embarcado em um

BeagleBone Black; e (ii) um cliente de Serviço Web RESTful embarcado em um BeagleBone Black

envia mensagens HTTPS para um Serviço Web RESTful hospedado em uma máquina virtual de um

ambiente de computação em Nuvem. Nos testes, são variados: (i) o tamanho do corpo das mensagens

HTTPS (os cabeçalhos HTTP não são manipulados); e (ii) um grupo contém uma mensagem SAML

Response arbitrária em um cabeçalho HTTP e outro não. Quando não é feito o uso da AAI4WoT,

o SP apenas atribui o conteúdo da mensagem à uma variável do tipo String e envia uma resposta

do tipo text/plain contendo a String "OK". Quando a AAI4WoT é utilizada, o SP também atribui o

conteúdo do cabeçalho HTTP que contém a mensagem SAML à uma variável do tipo String. Como

resultado, obteve-se o RTT (Round-Trip Time) para cada amostra. Foram obtidas 50 amostras, das quais

a primeira foi excluída por possuir sempre um RTT muito acima das demais, por ser a requisição em

que o canal TLS é estabelecido. Com este experimento, buscou-se avaliar qual o impacto do aumento

do tamanho das mensagens HTTP no desempenho do dispositivo que foi utilizado e qual o impacto da

inserção de uma mensagem SAML no cabeçalho HTTP na métrica de vazão da rede. Vale ressaltar que

as aplicações utilizadas para este experimento não são as mesmas utilizadas nos demais experimentos,

uma vez que buscou-se avaliar apenas o impacto de uma forma genérica.

O gráfico da Figura 23 mostra os resultados do teste de vazão para o cenário em que o

BeagleBone Black atua como SP. No eixo X está a variação de tamanho do vetor de bytes e no eixo Y

a média de RTT para cada variação. É possível perceber que a média de RTT para os casos com e sem

a mensagem SAML no cabeçalho HTTP (com e sem AAI) é similar.

O gráfico da Figura 24 mostra os resultados do experimento para o cenário em que o BeagleBone

Black atua como cliente. É possível perceber, pela análise do gráfico, que os tempos médios de RTT

para os casos com e sem a AAI são também similares.

Sobre o tamanho das mensagens trocadas entre cliente e SP (Tabela 18), observa-se que o uso

da AAI4WoT aumenta o tamanho das mensagens enviadas do cliente para o SP, em função da adição

de uma mensagem SAML ao cabeçalho HTTP da requisição. Contudo, ao se observar os resultados do

experimento de vazão da rede, percebe-se que, mesmo a mensagem sendo maior, o impacto no RTT é

pequeno e aceitável para o ambiente em que os experimentos foram realizados. O impacto ao utilizar a

AAI na métrica de vazão é, em média, de 16,06ms com desvio padrão de 25,18 quando o BeagleBone

é o SP e, em média, 28,83ms com desvio padrão de 22,23 quando o SP está alocado na Cloud. Se for

feita a comparação deste impacto com o tempo total do processo de solicitação/resposta de um recurso

ao SP (ver dados da Tabela 17 para o cenário com AAI4WoT), observa-se que este impacto representa

130

Figura 24. Experimento de Vazão da Rede - Aplicação na Nuvem atua como SP

0.34% do tempo de processamento do cliente Smart Gateway, enquanto representa 0.48% e 0.46% do

tempo de processamento dos Clientes Desktop e Embarcado, respectivamente. Para o fluxo contrário,

do SP para o cliente, observa-se o aumento no tamanho das mensagens em função do uso do TLS,

o qual é menor do que no caso das mensagens enviadas do cliente para o SP. Assim, este aumento

também é considerado aceitável para o ambiente dos experimentos.

5.3 COMPARAÇÃO COM OS TRABALHOS RELACIONADOS

Este trabalho apresentou uma infraestrutura de autenticação e de autorização para a Web das

Coisas (AAI4WoT). Dentre os trabalhos relacionados que apresentam infraestruturas que abordam a

autenticação e a autorização, apenas Akram e Hoffmann (2008b) e Conzon et al. (2012) abordaram

a interoperabilidade de mecanismos de autenticação, contudo apenas para usuários. Neste contexto,

apenas a AAI4WoT abordou a interoperabilidade de diferentes mecanismos de autenticação de usuários

131

e de dispositivos.

Dentre os trabalhos relacionados é possível identificar que apenas Gardel et al. (2013) e Akram

e Hoffmann (2008b) abordaram a autenticação única. Também neste caso, as duas soluções oferecem

esse serviço apenas para usuários. Neste sentido, a AAI4WoT diferencia-se ao permitir a autenticação

única tanto de usuários como de dispositivos.

Em relação às tecnologias utilizadas nas infraestruturas dos trabalhos relacionados, percebe-se

que o uso do SAML, XACML e WS-Policy não é uma inovação, uma vez que foi utilizado também

em Akram e Hoffmann (2008b) e Seitz, Selander e Gehrmann (2013). Entretanto, em Seitz, Selander

e Gehrmann (2013) são utilizadas apenas as asserções SAML e as XACML Obligations, ou seja,

apenas parte do padrão. Além disso, a autenticação não é abordada, apenas a autorização. Em Akram

e Hoffmann (2008b), estes padrões são utilizados para autenticação apenas de usuários. Assim, a

AAI4WoT diferencia-se ao utilizar estas tecnologias para permitir a autenticação de usuários e de

dispositivos.

De modo geral, dentre os trabalhos que abordaram a autenticação, nenhum abordou a auten-

ticação de usuários e de dispositivos na mesma infraestrutura. Assim, a AAI4WoT diferencia-se ao

permitir que usuários e dispositivos usem a mesma infraestrutura para se autenticar.

Quatro trabalhos relacionados abordaram a autenticação e autorização na IoT. Destes, apenas

três são soluções para a WoT (Akram e Hoffmann (2008b), Liu, Xiao e Chen (2012) e Gardel et al.

(2013)), mas nenhum abordou um cenário M2M, em que os dispositivos comunicam-se entre si de

maneira autônoma, sem intervenção humana. O diferencial da AAI4WoT neste aspecto, é abordar a

autenticação e autorização na WoT em um cenário M2M.

Por fim, apesar de todos os trabalhos relacionados abordarem a autorização, apenas em Alam,

Chowdhury e Noll (2011) é apresentada uma abordagem independente de modelo de controle de

acesso. Essa independência é importante na IoT, uma vez que permite que o modelo de controle

de acesso seja definido de acordo com requisitos da aplicação e não imposto pela infraestrutura de

segurança. Isso torna a infraestrutura mais flexível e permite que atenda mais facilmente aplicações

heterogêneas. A AAI4WoT provê essa flexibilidade por meio do uso do XACML. O diferencial, neste

caso, está em abordar, além da autorização, a autenticação de dispositivos e de usuários.

132

6 CONCLUSÃO

Um dos desafios de segurança da IoT é garantir a autenticidade de dispositivos e de usuários

em cenários com múltiplos domínios administrativos de segurança. O problema de pesquisa abordado

neste trabalho foi a autenticação e autorização de usuários e de dispositivos, em que o escopo foi

limitado à (i) garantia da autenticação única de usuários e de dispositivos que utilizam mecanismos de

autenticação heterogêneos em uma mesma infraestrutura, diante de múltiplos domínios de segurança e

(ii) a prover um mecanismo de autorização que permita a implementação de diferentes modelos de

controle de acesso e o uso de políticas de autorização flexíveis.

Para abordar o problema de pesquisa, o trabalho foi dividido em seis etapas. A primeira etapa

consistiu de uma pesquisa bibliográfica visando o conhecimento teórico dos conceitos relacionados,

que também permitiu definir com precisão as lacunas que haviam na literatura e, com isso, a definição

do escopo que seria abordado. A segunda etapa tratou da análise dos trabalhos relacionados que

foram encontrados por meio de uma revisão sistemática da literatura, realizada conforme o protocolo

de busca descrito no Apêndice A. A seleção de trabalhos permitiu identificar aqueles que proviam

infraestruturas de autenticação e/ou autorização para a IoT e não estavam limitados a uma determinada

tecnologia de comunicação ou a um mecanismo de autenticação específico.

A terceira etapa abordou a definição de como a AAI4WoT deveria ser composta para tratar

do problema de pesquisa, bem como permitiu identificar as tecnologias mais adequadas e quais eram

os modos de operação necessários. Em seguida, a quarta etapa tratou da modelagem da AAI4WoT.

A quinta etapa compreendeu a implementação de um protótipo da AAI4WoT e a integração deste à

uma aplicação industrial de WoT. A última etapa consistiu da avaliação dos impactos da inclusão da

AAI4WoT na aplicação industrial de WoT.

O objetivo deste trabalho foi prover autenticação e autorização de usuários e de dispositivos no

cenário de WoT para dispositivos e usuários em domínios de segurança diferentes, por meio de uma

AAI. Para atingir este objetivo, foram definidos quatro objetivos específicos.

O primeiro objetivo consistiu em verificar como diferentes mecanismos de autenticação de

dispositivos e diferentes modelos de controle de acesso podem ser utilizados em uma AAI baseada

nos padrões SAML e XACML. Este objetivo foi atingido por meio da definição da AAI4WoT e seus

componentes, bem como pela implementação do protótipo. Verificou-se que eventos de autenticação

133

de dispositivos que utilizam diferentes mecanismos podem ser representados pelo SAML por meio

de extensões ao padrão, já definidas na própria especificação. Também verificou-se que o SAML é

agnóstico ao mecanismo de autenticação utilizado, o que permitiu que esse objetivo fosse atingido.

Por meio do estudo da especificação XACML, definição da AAI4WoT e implementação do protótipo,

foi possível verificar que o padrão XACML é flexível o bastante para permitir a implementação de

diferentes modelos de controle de acesso.

O segundo objetivo específico tratava de prover, em uma única infraestrutura, a autenticação

única de usuários e de dispositivos diante de diferentes mecanismos de autenticação e diferentes

domínios administrativos. Este objetivo foi atingido por meio da implementação do protótipo da

AAI4WoT, em que foram utilizados dois mecanismos de autenticação no mesmo IdP: (i) via certificados

digitais no formato X.509 (para usuários) e (ii) por meio de um mecanismo desenvolvido com

base no acordo de chaves autenticado não-interativo Sakai-Ohgishi-Kasahara (SAKAI; OHGISHI;

KASAHARA, 2000), no algoritmo criptográfico AES_256 e no protocolo de challenge-response

Needham-Shroeder (NEEDHAM; SCHROEDER, 1978) (para dispositivos). Por meio do protótipo

desenvolvido e dos resultados apresentados, pode-se perceber que a autenticação única também foi

provida para usuários e dispositivos.

O terceiro objetivo específico referiu-se a prover um mecanismo de autorização flexível com

suporte a diferentes modelos de controle de acesso e diferentes políticas de autorização, adequados aos

requisitos de aplicações da IoT. O objetivo foi atingido por meio do desenvolvimento do protótipo

da AAI4WoT e uso do padrão XACML. O uso de atributos específicos de dispositivos na política de

autorização XACML (disponível no Apêndice B) permitiu implementar, como prova de conceito, o

modelo de controle de acesso ABAC, mostrando que o XACML permite representar características dos

dispositivos da IoT. Já o uso de um atributo que representa o papel de um usuário em uma instituição

permitiu a implementação do modelo de controle de acesso RBAC para autorização de usuários,

também como prova de conceito.

O último objetivo específico consistiu em avaliar os impactos do uso da AAI4WoT quando

utilizada em uma aplicação de WoT, em termos do uso de recursos computacionais dos dispositivos.

Este objetivo específico foi atingido por meio dos experimentos e resultados descritos no Capítulo 5.

Pode-se, assim, dizer que o objetivo geral deste trabalho foi alcançado.

O desenvolvimento da AAI4WoT e os resultados apresentados também permitiram confirmar

as hipóteses levantadas. Sobre a primeira hipótese, pode-se afirmar que o uso dos princípios REST e

do protocolo HTTP em uma AAI baseada no modelo de gestão de identidades federadas e no padrão

134

SAML, permite prover (i) a autenticação de usuários e de dispositivos e (ii) a autenticação única diante

de diferentes mecanismos de autenticação frente a múltiplos domínios de segurança, como foi possível

observar no protótipo desenvolvido e na etapa de avaliação.

A segunda hipótese era de que tomar as decisões de autorização fora do dispositivo SP, utili-

zando o padrão XACML e os princípios REST, torna possível o suporte a mecanismos de autorização

flexíveis que refletem as necessidades das aplicações de IoT. Diante do atendimento do objetivo

específico três, do desenvolvimento do protótipo da AAI4WoT e da integração desta a uma aplicação

real de WoT para ambientes industriais inteligentes, é possível afirmar que esta hipótese é verdadeira.

Por fim, a hipótese três consistia de que a inclusão da AAI4WoT em uma aplicação de

IoT implicaria na utilização de mais recursos computacionais dos dispositivos, mas que o uso da

autenticação única reduziria os impactos no consumo destes recursos. Esta hipótese é verdadeira,

conforme quantificado nos resultados apresentados no Capítulo 5.

6.1 CONTRIBUIÇÃO DA DISSERTAÇÃO

A principal contribuição deste trabalho está em prover uma AAI baseada no modelo de gestão

de identidades federadas capaz de prover, na mesma infraestrutura, a autenticação única de dispositivos

e de usuários diante de diferentes mecanismos de autenticação. Outra contribuição está em abordar,

para um cenário que envolve dispositivos autônomos (M2M) e WoT, tanto a autenticação como a

autorização de dispositivos e de usuários. Por fim, percebe-se também como contribuição o provimento

de uma AAI que trate tanto autenticação como autorização, mas que seja flexível quanto à escrita de

políticas de autorização e implementação do modelo de controle de acesso.

6.2 TRABALHOS FUTUROS

São propostos os seguintes trabalhos futuros:

• Concluir a implementação por meio da (i) inclusão dos componentes PIP e PAP e (ii)

implementação no Cliente Ativo da busca e interpretação da política de qualidade de

proteção do SP;

• Implementar o suporte à transformação de mensagens SAML e XACML representadas

em XML para representação JSON, por meio da refatoração das bibliotecas OpenSAML

135

e Balana. Junto com isso, avaliar os impactos do uso dos mecanismos JWT (JSON Web

Token), JWS (JSON Web Signature) e JWE (JSON Web Encryption).

• Avaliar o impacto da utilização de mecanismos que poderiam diminuir o tamanho das

mensagens enviadas, como a compressão gzip;

• Comparar a AAI4WoT com uma implementação do perfil SAML ECP, no mesmo cenário

da aplicação de WoT;

• Avaliar a viabilidade do uso do protocolo SAML Artifact Resolution Protocol em conjunto

com o HTTP Artifact Binding na AAI4WoT;

• Tornar a AAI4WoT compatível com o protocolo CoAP e avaliar a viabilidade de seu uso

com este protocolo;

• Avaliar o uso da AAI4WoT em dispositivos com mais restrições computacionais e de energia

do que o BeagleBone Black; e

• Investigar como operações criptográficas podem ser feitas com segurança em dispositivos

que não possuem um hardware seguro (TPM), uma vez que esta é uma das premissas de

funcionamento da AAI4WoT.

136

REFERÊNCIAS

AHSON SYED A; ILYAS, Mohammad. Near Field Communications Handbook. [S.l.]: CRC Press,2012.

AKRAM, Hasan; HOFFMANN, Mario. Laws of identity in ambient environments: The hydraapproach. In: THE SECOND INTERNATIONAL CONFERENCE ON MOBILE UBIQUITOUSCOMPUTING, SYSTEMS, SERVICES AND TECHNOLOGIES, 2008 – UBICOMM’08.Proceedings... [S.l.], 2008. p. 367–373.

. Supports for identity management in ambient environments-the hydra approach. In: 3RDINTERNATIONAL CONFERENCE ON SYSTEMS AND NETWORKS COMMUNICATIONS,2008. ICSNC’08. Proceedings... [S.l.], 2008. p. 371–377.

AKYILDIZ, I. F.; SU, W.; SANKARASUBRAMANIAM, Y.; CAYIRCI, E. Wireless sensor networks:a survey. Computer Networks, Elsevier North-Holland, Inc., New York, NY, USA, v. 38, n. 4, p.393–422, mar. 2002. ISSN 1389-1286.

ALAM, Sarfraz; CHOWDHURY, Mohammad MR; NOLL, Josef. Interoperability of security-enabledinternet of things. Wireless Personal Communications, Springer, v. 61, n. 3, p. 567–586, 2011.

ANDERSON, James P. Computer Security technology planning study. [S.l.], 1972. Disponível em:<http://csrc.nist.gov/publications/history/ande72.pdf>.

ARANHA, D. F.; GOUVEA, C. P. L. RELIC is an Efficient LIbrary for Cryptography. 2009.<https://github.com/relic-toolkit/relic>.

ATZORI, Luigi; IERA, Antonio; MORABITO, Giacomo. The internet of things: A survey. ComputerNetworks, Elsevier, v. 54, n. 15, p. 2787–2805, 2010.

BABAR, Sachin; MAHALLE, Parikshit; STANGO, Antonietta; PRASAD, Neeli R.; PRASAD,Ramjee. Proposed security model and threat taxonomy for the internet of things (iot). In:MEGHANATHAN, Natarajan; BOUMERDASSI, Selma; CHAKI, Nabendu; NAGAMALAI,Dhinaharan (Ed.). CNSA. [S.l.]: Springer, 2010. (Communications in Computer and InformationScience, v. 89), p. 420–429.

BABAR, Sachin; STANGO, Antonietta; PRASAD, Neeli; SEN, Jaydip; PRASAD, Ramjee. Proposedembedded security framework for internet of things (iot). In: 2ND INTERNATIONAL CONFERENCEON WIRELESS COMMUNICATION, VEHICULAR TECHNOLOGY, INFORMATION THEORYAND AEROSPACE & ELECTRONIC SYSTEMS TECHNOLOGY (WIRELESS VITAE), 2011.Proceedings... [S.l.], 2011. p. 1–5.

BHARGAV-SPANTZEL, Abhilasha; CAMENISCH, Jan; GROSS, Thomas; SOMMER, Dieter. Usercentricity: a taxonomy and open issues. Journal of Computer Security, IOS Press, v. 15, n. 5, p.493–527, 2007.

BONETTO, Riccardo; BUI, Nicola; LAKKUNDI, Vishwas; OLIVEREAU, Alexis; SERBANATI,Alexandru; ROSSI, Michele. Secure communication for smart iot objects: Protocol stacks, use casesand practical examples. In: IEEE INTERNATIONAL SYMPOSIUM ON A WORLD OF WIRELESS,MOBILE AND MULTIMEDIA NETWORKS (WOWMOM), 2012. Proceedings... [S.l.], 2012.p. 1–7.

BUETTNER, Michael; GREENSTEIN, Ben; SAMPLE, Alanson; SMITH, Joshua R.; WETHERALL,David. Revisiting smart dust with rfid sensor networks. In: 7TH ACM WORKSHOP ON HOTTOPICS IN NETWORKS (HOTNETS-VII), 2008. Proceedings. [S.l.]: ACM, 2008.

http://csrc.nist.gov/publications/history/ande72.pdf

https://github.com/relic-toolkit/relic

137

CABARCOS, Patricia Arias; MENDOZA, Florina Almenárez; MARíN-LóPEZ, Andrés;DíAZ-SáNCHEZ, Daniel. Enabling saml for dynamic identity federation management. In:WOZNIAK, Jozef; KONORSKI, Jerzy; KATULSKI, Ryszard; PACH, AndrzejR. (Ed.). Wirelessand Mobile Networking. Springer Berlin Heidelberg, 2009. v. 308, p. 173–184. Disponível em:<http://dx.doi.org/10.1007/978-3-642-03841-9_16>.

CAVOUKIAN, Ann. Mobile near field communications: Keep it secure and private. InformationSystems Security Association Journal, v. 10, n. 8, p. 12–17, 2012.

CERP-IOT. Vision and challenges for realising the Internet of Things. 2010. Disponível em:<http://www.theinternetofthings.eu/sites/default/files/Rob%20van%20Kranenburg/Clusterbook%202009_0.pdf>.

CHADWICK, David W. Federated identity management. In: ALDINI, Alessandro; BARTHE,Gilles; GORRIERI, Roberto (Ed.). Foundations of Security Analysis and Design V. SpringerBerlin Heidelberg, 2009, (Lecture Notes in Computer Science, v. 5705). p. 96–120. Disponível em:<http://dx.doi.org/10.1007/978-3-642-03829-7_3>.

COMMUNITIES, CTEC COMMISSION OF THE EUROPEAN. Future networks and the internet:Early Challenges regarding the Internet of Things. [S.l.], 2008.

CONZON, Davide; BOLOGNESI, Thomas; BRIZZI, Paolo; LOTITO, Antonio; TOMASI,Riccardo; SPIRITO, Maurizio A. The virtus middleware: An xmpp based architecture forsecure iot communications. In: 21ST INTERNATIONAL CONFERENCE ON COMPUTERCOMMUNICATIONS AND NETWORKS (ICCCN), 2012. Proceedings... [S.l.], 2012. p. 1–6.

COUNCIL, National Intelligence. Disruptive Civil Technologies: Six Technologies with PotentialImpacts on US Interests Out to 2025. [S.l.], 2008.

COVINGTON, M. J.; CARSKADDEN, R. Threat implications of the internet of things. In: 5THINTERNATIONAL CONFERENCE ON CYBER CONFLICT. Proceedings... [S.l.]: NATO CCDCOE Publications, 2013.

DIERKS, T.; ALLEN, C. The TLS Protocol. 1999. Disponível em: <https://www.ietf.org/rfc/rfc2246.txt>.

EASTLAKE, D.; REAGLE, J.; SOLO, D.; HIRSCH, F.; ROESSLER, T.; BARTEL, M.; BOYER, J.;FOX, B.; LAMACCHIA, B.; SIMON, E. XML Signature Syntax and Processing (Second Edition).2008. Disponível em: <http://www.w3.org/TR/xmldsig-core>.

FIELDING, Roy T.; TAYLOR, Richard N. Principled design of the modern web architecture. ACMTrans. Internet Technol., ACM, New York, NY, USA, v. 2, n. 2, p. 115–150, maio 2002. Disponívelem: <http://doi.acm.org/10.1145/514183.514185>.

FONGEN, Anders. Identity management and integrity protection in the internet of things. In: THIRDINTERNATIONAL CONFERENCE ON EMERGING SECURITY TECHNOLOGIES (EST), 2012.Proceedings... [S.l.], 2012. p. 111–114.

FU, Zhonglin; JING, Xiaojun; SUN, Songlin. Application-based identity management in m2m system.In: INTERNATIONAL CONFERENCE ON ADVANCED INTELLIGENCE AND AWARENESSINTERNET (AIAI 2011), 2011. Proceedings... [S.l.], 2011. p. 211–215.

GARDEL, Tito; ANDRADE, Nailton; FARIAS, Felix; PRAZERES, Cássio. Autenticação eautorização para acesso a aplicações em um barramento de serviços para a web das coisas.In: 13 SIMPóSIO BRASILEIRO EM SEGURANçA DA INFORMAçãO E DE SISTEMASCOMPUTACIONAIS (SBSEG), 2013. Anais do. [S.l.]: SBC, 2013.

http://dx.doi.org/10.1007/978-3-642-03841-9_16

http://www.theinternetofthings.eu/sites/default/files/Rob%20van%20Kranenburg/Clusterbook%202009_0.pdf

http://www.theinternetofthings.eu/sites/default/files/Rob%20van%20Kranenburg/Clusterbook%202009_0.pdf

http://dx.doi.org/10.1007/978-3-642-03829-7_3

https://www.ietf.org/rfc/rfc2246.txt

https://www.ietf.org/rfc/rfc2246.txt

http://www.w3.org/TR/xmldsig-core

http://doi.acm.org/10.1145/514183.514185

138

GARZOGLIO, G; BESTER, J; CHADWICK, K; DYKSTRA, D; GROEP, D; GU, J; HESSELROTH,T; KOEROO, O; LEVSHINA, T; MARTIN, S; SALLE, M; SHARMA, N; SIM, A; TIMM, S;VERSTEGEN, A. Adoption of a saml-xacml profile for authorization interoperability across gridmiddleware in osg and egee. Journal of Physics: Conference Series, v. 331, n. 6, 2011.

GORLATOVA, M.; SHARMA, T.; SHRESTHA, D.; XU, E.; CHEN, Jiasi; SKOLNIK, A.;PIAO, Dongzhen; KINGET, P.; KYMISSIS, J.; RUBENSTEIN, D.; ZUSSMAN, G. Prototypingenergy harvesting active networked tags (enhants) with mica2 motes. In: 7TH ANNUALIEEE COMMUNICATIONS SOCIETY CONFERENCE ON SENSOR MESH AND AD HOCCOMMUNICATIONS AND NETWORKS (SECON), 2010. Proceedings... [S.l.], 2010. p. 1–3.

GRAF, Sebastian; ZHOLUDEV, Vyacheslav; LEWANDOWSKI, Lukas; WALDVOGEL, Marcel.Hecate, managing authorization with restful xml. In: SECOND INTERNATIONAL WORKSHOP ONRESTFUL DESIGN. Proceedings of. [S.l.]: ACM, 2011. p. 51–58.

GUBBI, Jayavardhana; BUYYA, Rajkumar; MARUSIC, Slaven; PALANISWAMI, Marimuthu.Internet of things (iot): A vision, architectural elements, and future directions. Future GenerationComputer Systems, Elsevier, v. 29, n. 7, p. 1645–1660, 2013.

GUINARD, D.; FISCHER, M.; TRIFA, V. Sharing using social networks in a composable web ofthings. In: 8TH IEEE INTERNATIONAL CONFERENCE ON PERVASIVE COMPUTING ANDCOMMUNICATIONS WORKSHOPS (PERCOM WORKSHOPS), 2010. Proceedings... [S.l.], 2010.p. 702–707.

GUINARD, Dominique; TRIFA, Vlad. Towards the web of things: Web mashups for embeddeddevices. In: WORKSHOP ON MASHUPS, ENTERPRISE MASHUPS AND LIGHTWEIGHTCOMPOSITION ON THE WEB (MEM 2009). Proceedings... [S.l.], 2009.

GUINARD, Dominique; TRIFA, Vlad; MATTERN, Friedemann; WILDE, Erik. From the internet ofthings to the web of things: Resource-oriented architecture and best practices. In: UCKELMANN,Dieter; HARRISON, Mark; MICHAHELLES, Florian (Ed.). Architecting the Internet of Things.[S.l.]: Springer Berlin Heidelberg, 2011. p. 97–129.

GUINARD, Dominique; TRIFA, Vlad; PHAM, Thomas; LIECHTI, Olivier. Towards physicalmashups in the web of things. In: SIXTH INTERNATIONAL CONFERENCE ON NETWORKEDSENSING SYSTEMS (INSS), 2009. Proceedings... [S.l.], 2009. p. 1–4.

GUSMEROLI, Sergio; PICCIONE, Salvatore; ROTONDI, Domenico. A capability-basedsecurity approach to manage access control in the internet of things. Mathematicaland Computer Modelling, v. 58, n. 5–6, p. 1189 – 1205, 2013. Disponível em: <http://www.sciencedirect.com/science/article/pii/S089571771300054X>.

HAMESEDER, Katrin; FOWLER, Scott; PETERSON, Anders. Performance analysis of ubiquitousweb systems for smartphones. In: INTERNATIONAL SYMPOSIUM ON PERFORMANCEEVALUATION OF COMPUTER & TELECOMMUNICATION SYSTEMS (SPECTS), 2011.Proceedings... [S.l.], 2011. p. 84–89.

HAN, Qiyun; LI, Jing. An authorization management approach in the internet of things. Journal ofInformation & Computational Science, v. 9, n. 6, p. 1705–1713, 2012.

HANUMANTHAPPA, Pradeep; SINGH, Sanjay. Privacy preserving and ownership authenticationin ubiquitous computing devices using secure three way authentication. In: INTERNATIONALCONFERENCE ON INNOVATIONS IN INFORMATION TECHNOLOGY (IIT), 2012. Proceedings.[S.l.], 2012. p. 107–112.

HOFFMANN, Mario; BADII, Atta; ENGBERG, Stephen; NAIR, Renjith; THIEMERT, Daniel;MATTHESS, Manuel. Security, trust and privacy supported by context-aware middleware. In: 18thWireless World Research Forum Meeting: Multimedia Goes Mobile (WWRF). [S.l.: s.n.], 2010.p. 1–4.

http://www.sciencedirect.com/science/article/pii/S089571771300054X

http://www.sciencedirect.com/science/article/pii/S089571771300054X

139

HORROW, Susmita; SARDANA, Anjali. Identity management framework for cloud based internet ofthings. In: FIRST INTERNATIONAL CONFERENCE ON SECURITY OF INTERNET OF THINGS.Proceedings of. [S.l.]: ACM, 2012. p. 200–203.

HU, Vincent C.; FERRAIOLO, David; KUHN, Rick; SCHNITZER, Adam; SANDLIN,Kenneth; MILLER, Robert; SCARFONE, Karen. Guide to Attribute Based AccessControl (ABAC) Definition and Considerations. [S.l.], 2014. Disponível em: <http://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.sp.800-162.pdf>.

HUMMEN, René; ZIEGELDORF, Jan H; SHAFAGH, Hossein; RAZA, Shahid; WEHRLE, Klaus.Towards viable certificate-based authentication for the internet of things. In: 2ND ACM WORKSHOPON HOT TOPICS ON WIRELESS NETWORK SECURITY AND PRIVACY. Proceedings of. [S.l.],2013. p. 37–42.

ITU. ITU Internet Reports 2005: The internet of things. [S.l.]: International TelecommunicationUnion (ITU), 2005.

. NGN identity management framework. [S.l.]: International Telecommunication Union (ITU),2009. Recommendation Y.2720.

JARA, Antonio J; MARIN, Leandro; SKARMETA, Antonio FG; SINGH, Dhananjay; BAKUL,Gohel; KIM, Daeyeoul. Secure mobility management scheme for 6lowpan id/locator split architecture.In: FIFTH INTERNATIONAL CONFERENCE ON INNOVATIVE MOBILE AND INTERNETSERVICES IN UBIQUITOUS COMPUTING (IMIS), 2011. Proceedings... [S.l.], 2011. p. 310–315.

JINDOU, Jia; XIAOFENG, Qiu; CHENG, Cheng. Access control method for web of things basedon role and sns. In: IEEE 12TH INTERNATIONAL CONFERENCE ON COMPUTER ANDINFORMATION TECHNOLOGY (CIT), 2012. Proceedings... [S.l.], 2012. p. 316–321.

JØSANG, Audun; FABRE, John; HAY, Brian; DALZIEL, James; POPE, Simon. Trust requirements inidentity management. In: 2005 AUSTRALASIAN WORKSHOP ON GRID COMPUTING ANDE-RESEARCH. Proceedings of. [S.l.], 2005. v. 44, p. 99–108.

JØSANG, Audun; POPE, Simon. User centric identity management. In: AUSCERT ASIA PACIFICINFORMATION TECHNOLOGY SECURITY CONFERENCE 2005. Proceedings... [S.l.], 2005.

JUELS, A. Rfid security and privacy: a research survey. Selected Areas in Communications, IEEEJournal on, v. 24, n. 2, p. 381–394, 2006.

KONIDALA, Divyan M; DUC, Dang Nguyen; LEE, Dongman; KIM, Kwangjo. A capability-based privacy-preserving scheme for pervasive computing environments. In: THIRD IEEEINTERNATIONAL CONFERENCE ON PERVASIVE COMPUTING AND COMMUNICATIONSWORKSHOPS, 2005. PERCOM 2005 WORKSHOPS. Proceedings... [S.l.], 2005. p. 136–140.

KOTHMAYR, Thomas; SCHMITT, Corinna; HU, Wen; BRUNIG, Michael; CARLE, Georg. Adtls based end-to-end security architecture for the internet of things with two-way authentication.In: IEEE 37TH CONFERENCE ON LOCAL COMPUTER NETWORKS WORKSHOPS (LCNWORKSHOPS), 2012. Proceedings... [S.l.], 2012. p. 956–963.

LANDWEHR, Carl E. Computer security. International Journal of Information Security, Springer,v. 1, n. 1, p. 3–13, 2001.

LENTO, Luiz Otávio Botelho; FRAGA, Joni da Silva; LUNG, Lau Cheuk. A nova geração de modelosde controle de acesso em sistemas computacionais. In: SIMPOSIO BRASILEIRO EM SEGURANÇADA INFORMAÇAO E DE SISTEMAS COMPUTACIONAIS. Anais do. [S.l.], 2006. p. 152–201.

LI, Ning; WANG, Qing; DENG, Zhongliang. Authentication framework of iiedns based on ldap &kerberos. In: 3RD IEEE INTERNATIONAL CONFERENCE ON BROADBAND NETWORK ANDMULTIMEDIA TECHNOLOGY (IC-BNMT), 2010. Proceedings... [S.l.], 2010. p. 695–699.

http://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.sp.800-162.pdf

http://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.sp.800-162.pdf

140

LIU, Jing; XIAO, Yang; CHEN, CL Philip. Authentication and access control in the internet of things.In: 32ND INTERNATIONAL CONFERENCE ON DISTRIBUTED COMPUTING SYSTEMSWORKSHOPS (ICDCSW), 2012. Proceedings... [S.l.], 2012. p. 588–592.

LOPEZ, Javier; OPPLIGER, Rolf; PERNUL, Günther. Authentication and authorization infrastructures(aais): a comparative survey. Computers & Security, Elsevier, v. 23, n. 7, p. 578–590, 2004.

MAHALLE, Parikshit; BABAR, Sachin; PRASAD, Neeli R; PRASAD, Ramjee. Identity managementframework towards internet of things (iot): Roadmap and key challenges. In: Recent Trends inNetwork Security and Applications. [S.l.]: Springer, 2010. p. 430–439.

MAHALLE, Parikshit N; ANGGOROJATI, Bayu; PRASAD, Neeli R; PRASAD, Ramjee. Identityauthentication and capability based access control (iacac) for the internet of things. Journal of CyberSecurity and Mobility, v. 1, n. 4, p. 309–348, 2013.

MAHALLE, Parikshit N; ANGGOROJATI, Bayu; PRASAD, Neeli Rashmi; PRASAD, Ramjee.Identity establishment and capability based access control (iecac) scheme for internet of things.In: 15TH INTERNATIONAL SYMPOSIUM ON WIRELESS PERSONAL MULTIMEDIACOMMUNICATIONS (WPMC), 2012. Proceedings... [S.l.], 2012. p. 187–191.

MAHALLE, Parikshit N; PRASAD, Neeli Rashmi; PRASAD, Ramjee. Object classification basedcontext management for identity management in internet of things. International Journal ofComputer Applications, v. 63, n. 12, 2013.

MARTINEZ, D.; BLANES, F.; SIMO, J.; CRESPO, A. Wireless sensor and actuator networks:Charecterization and case study for confined spaces healthcare applications. In: INTERNATIONALMULTICONFERENCE ON COMPUTER SCIENCE AND INFORMATION TECHNOLOGY(IMCSIT 2008), 2008. Proceedings... [S.l.], 2008. p. 687–693.

MAçANEIRO, Marcondes. Um Mecanismo Agregador de Atributos Mediado pelo ClienteAlinhado ao Programa de EGOV.BR. Dissertação (Mestrado) — Universidade do Vale do Itajaí,aug 2013.

MELNIKOV, Ed. A.; ZEILENGA, Ed. K. Simple Authentication and Security Layer (SASL).2006. Disponível em: <http://tools.ietf.org/rfc/rfc4422.txt>.

MINAYO, M. C. de S.; DESLANDES, S. F. Pesquisa social: teoria, método e criatividade. [S.l.]:Vozes, 1994.

MIORANDI, Daniele; SICARI, Sabrina; PELLEGRINI, Francesco De; CHLAMTAC, Imrich. Internetof things: Vision, applications and research challenges. Ad Hoc Networks, Elsevier, v. 10, n. 7, p.1497–1516, 2012.

MOORE, B.; ELLESSON, E.; STRASSNER, J.; WESTERINEN, A. Policy Core InformationModel – Version 1 Specification. 2001. Disponível em: <http://www.ietf.org/rfc/rfc3060.txt>.

NEEDHAM, Roger M; SCHROEDER, Michael D. Using encryption for authentication in largenetworks of computers. Communications of the ACM, ACM, v. 21, n. 12, p. 993–999, 1978.

NGUYEN, Tien-Dung; AL-SAFFAR, Aymen; HUH, Eui-Nam. A dynamic id-based authenticationscheme. In: SIXTH INTERNATIONAL CONFERENCE ON NETWORKED COMPUTING ANDADVANCED INFORMATION MANAGEMENT (NCM), 2010. Proceedings... [S.l.], 2010. p.248–253.

NIST. A SURVEY OF ACCESS CONTROL MODELS (WORKING DRAFT). [S.l.],2009. Disponível em: <http://csrc.nist.gov/news_events/privilege-management-workshop/PvM-Model-Survey-Aug26-2009.pdf>.

OASIS. A Brief Introduction to XACML. 2003. Disponível em: <https://www.oasis-open.org/committees/download.php/2713/Brief_Introduction_to_XACML.html>.

http://tools.ietf.org/rfc/rfc4422.txt

http://www.ietf.org/rfc/rfc3060.txt

http://csrc.nist.gov/news_events/privilege-management-workshop/PvM-Model-Survey-Aug26-2009.pdf

http://csrc.nist.gov/news_events/privilege-management-workshop/PvM-Model-Survey-Aug26-2009.pdf

https://www.oasis-open.org/committees/download.php/2713/Brief_Introduction_to_XACML.html

https://www.oasis-open.org/committees/download.php/2713/Brief_Introduction_to_XACML.html

141

. Authentication Context for the OASIS Security Assertion Markup Language (SAML)V2.0. 2005.

. Security and Privacy Considerations for the OASIS Security Assertion MarkupLanguage (SAML) V2.0. 2005.

. Security Assertion Markup Language (SAML) V2.0 - Technical Overview. 2008. Disponí-vel em: <https://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf>.

. Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML)V2.0 - Errata Composite - Working Draft 06. 2009.

. Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0 - ErrataComposite - Working Draft 05. 2009.

. Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0 - ErrataComposite - Working Draft 04. 2009.

. Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0 - ErrataComposite - Working Draft 06. 2009.

. eXtensible Access Control Markup Language (XACML) Version 3.0. 2013. Disponível em:<http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.pdf>.

. REST Profile of XACML v3.0 Version 1.0. 2013. Disponível em: <http://docs.oasis-open.org/xacml/xacml-rest/v1.0/xacml-rest-v1.0.pdf>.

RESCORLA, E.; KORVER, B. Guidelines for Writing RFC Text on Security Considerations.2003. Disponível em: <http://www.ietf.org/rfc/rfc3552.txt>.

ROMAN, Rodrigo; NAJERA, Pablo; LOPEZ, Javier. Securing the internet of things. Computer,IEEE Computer Society, v. 44, n. 9, p. 51–58, 2011.

ROTONDI, Domenico; SECCIA, Cristoforo; PICCIONE, Salvatore. Access control & iot: Capabilitybased authorization access control system. In: 1ST IOT INTERNATIONAL FORUM. Proceedings...[S.l.], 2011.

SAINT-ANDRE, Ed. P. Extensible Messaging and Presence Protocol (XMPP): Core. 2004.Disponível em: <http://www.ietf.org/rfc/rfc3920.txt>.

SAKAI, Ryuichi; OHGISHI, Kiyoshi; KASAHARA, Masao. Cryptosystems based on pairing. In:The 2000 Symposium on Cryptography and Information Security, Okinawa, Japan. [S.l.: s.n.],2000. p. 135–148.

SEITZ, Ludwig; SELANDER, Goran; GEHRMANN, Christian. Authorization framework forthe internet-of-things. In: IEEE 14TH INTERNATIONAL SYMPOSIUM AND WORKSHOPSON A WORLD OF WIRELESS, MOBILE AND MULTIMEDIA NETWORKS (WOWMOM).Proceedings... [S.l.], 2013. p. 1–6.

SILVA, Edna Lúcia da; MENEZES, Estera Muszkat. Metodologia da Pesquisa e Elaboração deDissertação. [S.l.]: Editora da UFSC, 2005.

SILVA, Paulo Henrique da. Desenvolvimento de um Smart Gateway para o Monitoramento deMáquinas Industriais. 85 p. Monografia (Trabalho de Conclusão de Curso) — Curso de Ciência daComputação, Universidade do Vale do Itajaí, São José, 2014.

SILVA, Rodrigo Cândido da. Uma Plataforma como um Serviço (PaaS) para o Desenvolvimentode Aplicações de Monitoramento e Controle Industrial. 117 p. Monografia (Trabalho de Conclusãode Curso) — Curso de Ciência da Computação, Universidade do Vale do Itajaí, São José, 2014.

https://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf

https://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf

http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.pdf

http://docs.oasis-open.org/xacml/xacml-rest/v1.0/xacml-rest-v1.0.pdf

http://docs.oasis-open.org/xacml/xacml-rest/v1.0/xacml-rest-v1.0.pdf



142

SOUZA, Luciana Moreira Sá De; SPIESS, Patrik; GUINARD, Dominique; KÖHLER, Moritz;KARNOUSKOS, Stamatis; SAVIO, Domnic. Socrades: A web service based shop floor integrationinfrastructure. In: The internet of things. [S.l.]: Springer, 2008. p. 50–67.

STALLINGS, W. Criptografia e segurança de redes: princípios e práticas. [S.l.]: Pearson PrenticeHall, 2008.

TORMO, Ginés Dólera; MILLáN, Gabriel López; PéREZ, Gregorio Martínez. Definition of anadvanced identity management infrastructure. International Journal of Information Security,Springer-Verlag, v. 12, n. 3, p. 173–200, 2013. Disponível em: <http://dx.doi.org/10.1007/s10207-012-0189-y>.

TRIFA, Vlad; WIELAND, Samuel; GUINARD, Dominique; BOHNERT, Thomas M. Design andimplementation of a gateway for web-based interaction and management of embedded devices. In:2ND INTERNATIONAL WORKSHOP ON SENSOR NETWORK ENGINEERING (IWSNE 09).Proceedings of. [S.l.], 2009.

ULLTVEIT-MOE, Nils; OLESHCHUK, Vladimir. Mobile security with location-aware role-basedaccess control. In: PRASAD, Ramjee; FARKAS, Károly; SCHMIDT, AndreasU.; LIOY, Antonio;RUSSELLO, Giovanni; LUCCIO, FlaminiaL. (Ed.). Security and Privacy in Mobile Informationand Communication Systems. Springer Berlin Heidelberg, 2012, (Lecture Notes of the Institute forComputer Sciences, Social Informatics and Telecommunications Engineering, v. 94). p. 172–183.Disponível em: <http://dx.doi.org/10.1007/978-3-642-30244-2_15>.

UNIVALI. Produção Acadêmico-Científica: A pesquisa e o ensaio. [S.l.]: Universidade do Vale doItajaí, 2011.

W3C. Web Services Architecture. 2004. Disponível em: <http://www.w3.org/TR/ws-arch/>.

. Web Services Policy 1.5 - Framework. 2007. Disponível em: <http://www.w3.org/TR/ws-policy/>.

WANGHAM, Michelle S; DOMENECH, Marlon C; MELLO, Emerson R de. Infraestruturas deautenticação e de autorização para internet das coisas. In: Minicursos do XIII Simpósio Brasileiroem Segurança da Informação e de Sistemas Computacionais - SBSeg 2013. [S.l.: s.n.], 2013.

WANGHAM, Michelle S; MELLO, Emerson Ribeiro de; BÖGER, Davi da Silva; GUERIOS, Marlon;FRAGA, Joni da Silva. Gerenciamento de identidades federadas. In: Minicurso – SBSeg 2010. [S.l.:s.n.], 2010.

WEBER, Rolf H. Internet of things - new security and privacy challenges. Computer Law &Security Review, v. 26, n. 1, p. 23 – 30, 2010. Disponível em: <http://www.sciencedirect.com/science/article/pii/S0267364909001939>.

XIANG, Chenhui; LI, Xinran. General analysis on architecture and key technologies about internet ofthings. In: IEEE 3RD INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING ANDSERVICE SCIENCE (ICSESS), 2012. Proceedings... [S.l.], 2012. p. 325–328.

XIAOHUI, Xu. Research on safety certification and control technology in internet of things. In:FOURTH INTERNATIONAL CONFERENCE ON COMPUTATIONAL AND INFORMATIONSCIENCES (ICCIS), 2012. Proceedings... [S.l.], 2012. p. 518–521.

YAN, Lu; ZHANG, Yan; YANG, Laurence; NING, Huansheng. The Internet of Things: from rfid tothe next-generation pervasive networked systems. [S.l.]: Auerbach Publications, 2008.

ZENG, Deze; GUO, Song; CHENG, Zixue. The web of things: A survey. Journal ofCommunications, v. 6, n. 6, 2011. Disponível em: <http://ojs.academypublisher.com/index.php/jcm/article/view/jcm0606424438>.

http://dx.doi.org/10.1007/s10207-012-0189-y

http://dx.doi.org/10.1007/s10207-012-0189-y

http://dx.doi.org/10.1007/978-3-642-30244-2_15

http://www.w3.org/TR/ws-arch/

http://www.w3.org/TR/ws-policy/

http://www.w3.org/TR/ws-policy/

http://www.sciencedirect.com/science/article/pii/S0267364909001939

http://www.sciencedirect.com/science/article/pii/S0267364909001939

http://ojs.academypublisher.com/index.php/jcm/article/view/jcm0606424438

http://ojs.academypublisher.com/index.php/jcm/article/view/jcm0606424438

143

ZHANG, Guoping; LIU, Jing. A model of workflow-oriented attributed based access control.International Journal of Computer Network and Information Security (IJCNIS), v. 3, n. 1, p.47–53, 2011.

144

APÊNDICE A – PROTOCOLO DE BUSCA E RESULTADOS DA

REVISÃO SISTEMÁTICA DA LITERATURA

Este apêndice apresenta o protocolo de busca com base no qual foi conduzida a revisão

sistemática da literatura, que possibilitou uma visão do estado da arte sobre o tema dessa dissertação.

Ao final, são apresentados os resultados da revisão sistemática.

A.1 PROTOCOLO DE BUSCA

Esta seção apresenta o protocolo de busca que embasou a revisão sistemática da literatura.

A.1.1 Objeto do Estudo

Levantamento do estado da arte de gestão de identidades em Internet das Coisas (IoT).

A.1.2 Perguntas de Pesquisa

• Questão: Quais mecanismos de gestão de identidades são atualmente empregados em IoT?

• Questão de pesquisa adicional: Quais mecanismos de gestão de identidades abordam a

autenticação ou autorização em IoT?

A.1.3 População

• Mecanismos de gestão de identidades;

• Mecanismos de autenticação ou autorização.

A.1.4 Resultados

• Mecanismos de autenticação em IoT;

• Mecanismos de autorização em IoT;

145

• Mecanismos de gestão de identidades em IoT.

A.1.5 Estratégia Utilizada para Pesquisa dos Estudos Primários

• String de busca:

– Em português: (Internet das Coisas OR IoT OR Dispositivos Inteligentes OR Objetos

Inteligentes) AND (Autenticação OR Autorização OR Gestão de Identidade)

– Em inglês: (Internet of Things OR IoT OR Smart Devices OR Smart Objects OR Ma-

chine to Machine) AND (Authentication OR Authorization OR Identity Management)

• Fontes:

– IEEExplore: http://ieeexplore.ieee.org

– Springer Link: http://link.springer.com/

– Google Acadêmico: http://scholar.google.com.br

– BDBComp: http://www.lbd.dcc.ufmg.br/bdbcomp/bdbcomp.jsp

– ACM Digital Library: http://portal.acm.org

– Periódicos da CAPES: http://www.periodicos.capes.gov.br

– Science Direct: http://www.sciencedirect.com/

A.1.6 Critérios e Procedimentos para a Seleção de Estudos

Os trabalhos serão filtrados a partir dos seguintes critérios:

• Pela análise do título do trabalho;

• Pela análise do resumo e das conclusões do trabalho;

• Pela data de publicação do trabalho (entre 2005 e 2014).

Critérios para inclusão de estudo:

146

• Para a questão primária: Incluir no estudo trabalhos cujos títulos e resumos contenham

informações sobre mecanismos de gestão de identidades em IoT. A conclusão será analisada

para verificar a contribuição do trabalho;

• Para a questão secundária: Os mesmos critérios da questão primária, porém o título e re-

sumo devem conter também a informação sobre autenticação ou autorização em IoT.

Critérios para exclusão de estudo:

• Para a questão primária: Serão excluídos do estudo trabalhos cujos títulos e resumos sejam

conflitantes, ou seja, o título remete a um assunto enquanto o resumo remete a outro;

• Para a questão secundária: Os mesmos critérios da questão primária além de que o título e

resumo que não estejam informando sobre gestão de identidades, autenticação ou autoriza-

ção em IoT.

A.1.7 Lista de Verificação e Procedimentos para Avaliação da Qualidade dos

Estudos

Os estudos serão avaliados em sua qualidade abordando os seguintes aspectos:

• Objetivos: Os objetivos do trabalho devem ser no sentido de estabelecer ou aplicar meca-

nismos de gestão de identidades em Internet das Coisas, abordando mais especificamente

autenticação ou autorização nesse contexto;

• Condução: O projeto deve estar bem referenciado e possuir, preferencialmente, uma etapa

experimental, com a validação das hipóteses. Eventos negativos ocorridos durante o estudo,

como por exemplo, dificuldades quanto à população e os equipamentos, tornarão o trabalho

elegível a ter uma atribuição de menor qualidade.

A.1.8 Reunião de Dados

Os dados a serem extraídos de cada artigo são:

• Título;

147

• Fonte;

• Ano de Publicação;

• Autores;

• Conceito do periódico (Qualis);

• Resumo do Artigo;

• Palavras-chave;

• Tipo do artigo: teórico, experimental ou ambos;

• Principal problema abordado;

• Propriedades de segurança asseguradas;

• Mecanismos de gestão de identidades;

• Interoperabilidade entre tecnologias de autenticação;

• Interoperabilidade entre tecnologias de comunicação;

• Solução proposta;

• Existência de implementação;

• Metodologia ou materiais utilizados;

• Resultados obtidos;

• Métricas de avaliação; e

• Problemas em aberto.

A.2 RESULTADOS DA REVISÃO SISTEMÁTICA DA LITERATURA

A revisão sistemática da literatura conduzida neste trabalho, feita com base no protocolo

descrito na Seção A.1, permitiu a identificação dos trabalhos relacionados. Além da busca conduzida

conforme este protocolo, foi feita uma pesquisa arbitrária sobre o tema Web das Coisas (uma “sub-

área” de Internet das Coisas), a fim de verificar se algum trabalho relevante havia ficado de fora dos

resultados. Por fim, também foi feita uma pesquisa arbitrária nos artigos publicados pela equipe do

148

Hydra Middleware, no site do próprio projeto 1, uma vez que era sabido do autor que este era um

projeto que tratava de gestão de identidades na Internet das Coisas, e que não havia retornado nos

resultados da busca.

A Tabela 27 mostra os resultados dessa etapa do estudo. A coluna “Num. Artigos” mostra a

quantidade de artigos retornados em cada base, sendo que pode haver duplicação de artigos entre as

bases. Foi lido o título de todos os artigos dessa coluna. Os artigos que não foram eliminados pelo

título, tiveram o resumo lido. A coluna “Restrições da Busca” mostra as adaptações que precisaram

ser feitas ao utilizar cada base de pesquisa, para que a busca pudesse ser realizada. Essa adaptações

ocorreram em função das diferenças entre os mecanismos de pesquisa de cada base de busca. Por

exemplo, alguns mecanismos não permitiam a pesquisa de palavras no abstract do artigo, apenas no

título. A coluna “Num. Artigos Lidos” apresenta quantos artigos de uma determinada base foram lidos

por completo. Dos artigos que foram lidos por completo foi retirada a lista de trabalhos relacionados.

Tabela 27. Resultados da Revisão Sistemática da Literatura

Fonte Num. Artigos Restrições da Busca Num. Artigos LidosBDBComp 59 Título 0

IEEExplore 137 – 23

Springer Link 319 Ciência da Computação ou Engenharia 4

Google Acadêmico 89 Título, exceto patentes e citações 13

ACM Digital Library 73 Título e Abstract 3

Periódicos da CAPES 16 Título 1

Science Direct 29 Título, Abstract e Keywords 3

Web das Coisas 3 Título, Abstract e Keywords 2

Hydra Middleware 4 Título, Abstract e Keywords 3

TOTAL – – 52

1 http://www.hydramiddleware.eu/

149

APÊNDICE B – POLÍTICA DE CONTROLE DE ACESSO

UTILIZADA NOS EXPERIMENTOS

Este apêndice descreve em detalhes a política de controle de acesso escrita em linguagem

XACML (mostrada ao final do Apêndice), utilizada na etapa de experimentos. A tag <Policy inicia a

descrição da política em XACML, seguida do atributo xmlns que indica o XML Schema Definition

(XSD) que define a sintaxe do documento XML da política, neste caso o XSD da especificação

XACML. O atributo PolicyId indica o identificador único (no contexto do mesmo PDP) da política.

Uma política em XACML é composta de regras (Rules). As rules servem para avaliar uma

requisição XACML e emitir uma decisão de autorização, caso apliquem-se à requisição em questão.

Assim, o atributo RuleCombiningAlgId define o algoritmo que irá combinar resultados de diferentes

rules, caso mais de uma rule seja aplicável a mesma requisição. Neste caso, o algoritmo escolhido

(deny-overrides) define que se uma rule emitir uma decisão de autorização de negação (deny), não

importa o valor das outras rules, o resultado final de avaliação da policy será deny. Em seguida, o

atributo Version define a versão da política que está sendo descrita.

O elemento XML <Target/>, aberto e fechado na mesma tag, indica que a política é aplicável

a qualquer tipo de requisição. Isso foi adotado pois esta é a única política do sistema, logo esta precisa

ser aplicável a qualquer requisição.

Em seguida, é iniciada a descrição da primeira rule, com a tag <Rule. É descrito seu identi-

ficador com o atributo RuleId e o efeito da regra caso haja um matching desta com a requisição de

decisão de autorização que está sendo avaliada. Neste caso, o efeito é Permit, que indica que a decisão

desta Rule irá permitir o acesso solicitado. A tag Description apresenta uma descrição informal da

Rule. O elemento Target indica a quais requisições esta Rule será aplicada, as quais são indicadas pelos

elementos <Match subsequentes. Para que esta Rule seja aplicável a esta requisição de decisão de

autorização, a requisição deverá possuir os seguintes atributos:

• O atributo urn:aai:subject:subject-device-type, da categoria urn:oasis:names:tc:xacml:1.0:

subject-category:access-subject, do tipo string, com valor igual (em função do atributo Mat-

chId com valor urn:oasis:names:tc:xacml:1.0:function:string-equal) a SmartGatewayAuda-

ces;

• O atributo urn:oasis:names:tc:xacml:1.0:action:action-id, da categoria urn:oasis:names:tc:

xacml:3.0:attribute-category:action, do tipo string, com valor igual a put; e

150

• O atributo urn:oasis:names:tc:xacml:1.0:resource:resource-id, da categoria urn:oasis:names:tc:

xacml:3.0:attribute-category:resource, do tipo string, com valor igual a /product/neocut/de-

vice/machine/property;

Assim, esta Rule aplica-se às requisições do tipo HTTP PUT, em que o subject que requer o

acesso possui um atributo device-type com valor SmartGatewayAudaces e a requisição foi feita ao

recurso /product/neocut/device/machine/property. Esta Rule aplica-se, portanto, ao cenário em que o

Smart Gateway realiza o envio de informações de monitoramento para o serviço de recebimento de

dados na Nuvem.

A segunda Rule, que inicia com outra tag <Rule, também possui o efeito de Permit caso haja

um matching desta com a requisição que está sendo avaliada. Nesta Rule, há duas tags <AllOf> dentro

da tag <AnyOf>. A tag AnyOf tem o efeito de OU dentre os elementos <AllOf> presentes nesta

(qualquer um dos elementos <AllOf> deve ser verdadeiro para que a Rule seja verdadeira), enquanto

que a tag <AllOf> tem o efeito de E entre os elementos Match que a compõe. Assim, para que esta

Rule seja verdadeira, a requisição deve atender um dos dois casos, pelo menos:

1. Em que o Subject é humano, possuir:

• O atributo urn:aai:subject:subject-affiliation, da categoria urn:oasis:names:tc:xacml:1.0:

subject-category:access-subject, do tipo string, com valor igual a Manager; e


xacml:3.0:attribute-category:action, do tipo string, com valor igual a get;

2. Em que o Subject é um dispositivo, possuir:

• O atributo urn:aai:subject:subject-device-type, da categoria urn:oasis:names:tc:xacml:1.0:

subject-category:access-subject, do tipo string, com valor igual a MonitorDevice; e


xacml:3.0:attribute-category:action, do tipo string, com valor igual a get

Assim, esta Rule aplica-se às requisições do tipo HTTP GET destinadas a umSmart Gateway,

em que o cliente é ou um humano (que faz uso da aplicação Cliente Desktop) ou um dispositivo

(que faz uso da aplicação Cliente Embarcado). Se for um humano, este deve possuir um atributo que

representa seu papel (subject-affiliation) com valor Manager. Caso seja um dispositivo, deve possuir

151

um atributo que representa o tipo do dispositivo (device-type) com valor MonitorDevice. Para ambos

os casos, a operação solicitada deve ser do tipo HTTP GET.

Caso nenhuma Rule seja atendida, a política não é aplicável à requisição e o comportamento

padrão do PEP será de negar o acesso ao recurso solicitado.

1 <Policy

2 xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"

3 PolicyId="urn:aai:policy:1"

4 RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides"

5 Version="1.0">

6 <Target/>

7 <Rule RuleId="urn:aai:ruleid:1" Effect="Permit">

8 <Description> Para que uma operacao de put no servico de recebimento de dados da Cloud

da Neocut possa ser realizada, o subject deve ser do tipo (deviceType)

SmartGatewayAudaces. </Description>

9 <Target>

10 <AnyOf>

11 <AllOf>

12 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

13 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">

SmartGatewayAudaces</AttributeValue>

14 <AttributeDesignator MustBePresent="false" Category="

urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"

AttributeId="urn:aai:subject:subject-device-type" DataType="http://

www.w3.org/2001/XMLSchema#string"/>

15 </Match>


17 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">put</

AttributeValue>


urn:oasis:names:tc:xacml:3.0:attribute-category:action" AttributeId="

urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.

w3.org/2001/XMLSchema#string"/>

19 </Match>


21 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">/

product/neocut/device/machine/property</AttributeValue>


urn:oasis:names:tc:xacml:3.0:attribute-category:resource" AttributeId

="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http://

152


23 </Match>

24 </AllOf>

25 </AnyOf>

26 </Target>

27 </Rule>

28 <Rule RuleId="urn:aai:ruleid:2" Effect="Permit">

29 <Description> Para que uma operacao de get em algum recurso da Neocut possa ser

realizada, o subject deve ter papel (subject-affiliation) Manager ou ser um

dispositivo do tipo (subject-device-type) MonitorDevice. </Description>

30 <Target>

31 <AnyOf>

32 <AllOf>


34 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Manager

</AttributeValue>



AttributeId="urn:aai:subject:subject-affiliation" DataType="http://


36 </Match>


38 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">get</

AttributeValue>





40 </Match>

41 </AllOf>

42 <AllOf>


44 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">

MonitorDevice</AttributeValue>



AttributeId="urn:aai:subject:subject-device-type" DataType="http://


46 </Match>


48 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">get</

153

AttributeValue>





50 </Match>

51 </AllOf>

52 </AnyOf>

53 </Target>

54 </Rule>

55 </Policy

154

APÊNDICE C – AUTENTICATION CONTEXT CLASS PARA O

MECANISMO DE AUTENTICAÇÃO UTILIZADO NOS

EXPERIMENTOS

As Figuras 25, 26, 27 e 28 descrevem como o método de autenticação utilizado neste trabalho

foi representado usando a especificação SAML, considerando apenas o caso em que o cliente é o Smart

Gateway. Na Figura 25, as linhas 1 a 7 tratam da definição do Schema XML, definindo um namespace

XML diferente do namespace da especificação SAML. A linha 9 define qual XSD está sendo redefinido.

A linha 12 inicia a redefinição do tipo <AuthnContextDeclarationBaseType>, exigindo a presença dos

elementos <Identification>, <TechnicalProtection> e <AuthnMethod>.

Figura 25. XSD para o contexto de autenticação utilizado nos experimentos - Parte 1

O tipo <IdentificationType>, tipo do elemento <Identification>, é redefinido na linha 28 e

limita, na linha 35, que o atributo nym tenha o valor anonimity. O atributo nym serve para que seja

155

indicado se as ações do subject identificado na asserção SAML correspondente podem ou não ser

vinculadas a um usuário final humano. No caso da aplicação Smart Gateway, isso não é possível, uma

vez que esta é uma aplicação autônoma vinculada apenas à máquina industrial monitorada. Entretanto,

esta não é a semântica adequada. O ideal seria ter a possibilidade de indicar a ausência do usuário

por trás da transação, através de uma extensão do tipo <IdentificationType>, mas isso não é possível.

Desse modo, esse é um dos aspectos inadequados para a IoT, haja vista que é comum ter cenários em

que não há um usuário humano participando da transação.


Na Figura 26, na linha 44, o tipo <TechnicalProtectionBaseType> é redefinido e exige a

presença do elemento <PrivateKeyProtection>. Na sequência, o tipo <PrivateKeyProtectionType>,

156

que é o tipo do elemento <PrivateKeyProtection>, é redefinido e exige a presença dos elementos

<KeyStorage> e <KeySharing>, os quais tem seus tipos redefinidos nas linhas 69 e 83, respectivamente.

A redefinição do tipo <KeyStorageType> na linha 69 exige a presença do atributo medium, sendo o

valor memory (linha 75) o único possível. Essa restrição existe em função da premissa de que o cliente,

para realizar operações criptográficas, deve ter um hardware TPM (Tamper-Proof Module).

Na Figura 27, a redefinição do tipo <KeySharingType> define que este elemento deve ter

um atributo chamado sharing com valor fixo true. Este valor indica que a chave privada é compar-

tilhada/conhecida pela autoridade de autenticação, uma vez que é o IdP que gera a chave privada

do dispositivo. Na linha 91, o tipo <AuthnMethodBaseType> é redefinido e exige a presença dos

elementos <Authenticator> e <AuthenticatorTransportProtocol>. O tipo <AuthenticatorBaseType>,

que é o tipo do elemento <Authenticator>, é redefinido na linha 104 e exige a presença de um elemento

<ComplexAuthenticator>, que tem seu tipo redefinido na linha 117. A redefinição do tipo <Comple-

xAuthenticatorType>, por sua vez, exige a presença dos elementos <SharedSecretChallengeResponse>

e <AsymmetricKeyAgreement>, que tem seus tipos redefinidos nas linhas 128 e 137, respectivamente

(ver Figura 28).

A redefinição do tipo <SharedSecretChallengeResponseType> na linha 128 da Figura 28, exige

a presença do atributo method com valor urn:marlon:SAML:2.0:ac:challengeresponse:Needham_Schroeder,

o qual serve para indicar que foi utilizado um mecanismo de challenge-response para autenticação

e que este mecanismo foi aquele definido por Needham e Schroeder (1978). Esta semântica é espe-

cífica para esta federação, uma vez que só é conhecida pelas entidades que conhecem o namespace

urn:marlon:SAML:2.0:ac. Na linha 137, o tipo <PublicKeyType>, que é o tipo do elemento <Asymme-

tricKeyAgreement> é redefinido. Este elemento indica que o cliente possui uma chave privada e a utili-

zou em um acordo de chave compartilhada com o IdP. A redefinição do tipo <PublicKeyType> obriga

a presença do atributo keyValidation com valor fixo urn:marlon:SAML:2.0:ac:keyAgreement:sakai-

ohgishi-kasahara, o qual indica que o acordo de chave utilizado foi o acordo descrito em Sakai,

Ohgishi e Kasahara (2000). De modo similar ao tipo anterior, esta semântica é específica para esta

federação.

Por fim, a redefinição do tipo <AuthenticatorTransportProtocolType> na linha 146, que é o tipo

do elemento <AuthenticatorTransportProtocol>, exige a presença de um elemento chamado <SSL>, o

qual indica que a troca das informações utilizadas para autenticação, entre cliente e IdP, deu-se sobre

um canal seguro, estabelecido por meio do protocolo SSL. Desse modo, foi possível verificar que o

mecanismo de autenticação de dispositivos utilizado neste trabalho pode ser representado usando a

157


158

especificação SAML.


159

APÊNDICE D – MODELAGEM DO PROTÓTIPO

Para avaliar a AAI4WoT, um protótipo da AAI foi desenvolvido. Este apêndice apresenta a

modelagem da solução proposta, sendo composto por uma descrição dos requisitos funcionais e não-

funcionais dos componentes da AAI4WoT e por diagramas de sequência que mostram o funcionamento

desta. Vale ressaltar que a etapa de registro de dispositivos SP e dispositivos e usuários clientes não foi

modelada.

D.1 REQUISITOS FUNCIONAIS E NÃO-FUNCIONAIS DO CLIENTE ATIVO

SAML

A seguir são descritos os requisitos funcionais do Cliente Ativo SAML:

• RF 01: O Cliente Ativo SAML deve ser capaz de buscar a política de qualidade de proteção

do serviço que o cliente deseja acessar;

• RF 02: O Cliente Ativo SAML deve ser capaz de montar uma requisição de autenticação

conforme o protocolo SAML Authentication Request Protocol e a política de qualidade de

proteção recebida do SP, no formato WS-Policy, e enviar essa requisição ao IdP; e

• RF 03: O Cliente Ativo SAML deve ser capaz de requisitar o serviço desejado pelo cliente,

apresentando ao SP, junto com a requisição do serviço, a asserção SAML recebida do IdP.

Os requisitos não-funcionais do Cliente Ativo SAML são:

• RNF 01: O Cliente Ativo SAML só deve se comunicar com IdPs e SPs através de um canal

seguro SSL/TLS; e

• RNF 02: O Cliente Ativo SAML deve estar alinhado aos princípios REST ao solicitar

serviços de SPs e IdPs.

D.2 REQUISITOS FUNCIONAIS E NÃO-FUNCIONAIS DO PEP

A seguir, são descritos os requisitos funcionais do dispositivo SP e do PEP:

160

• RF 01: O PEP deve ser capaz de gerar uma requisição de autorização no formato XACML,

com base na requisição do cliente e na asserção SAML recebida, e enviá-la ao PDP;

• RF 02: O PEP deve ser capaz de prover o recurso solicitado pelo cliente caso a autorização

seja concedida pelo PDP;

• RF 03: O PEP deve ser capaz de apresentar ao cliente uma mensagem de erro caso a

autorização de acesso ao recurso seja negada pelo PDP; e

• RF 04: O PEP deve enviar a asserção SAML ao IdP para que esta seja validada e confirmada

a autenticação do dispositivo.

Os requisitos não-funcionais do PEP são:

• RNF 01: O PEP deve ser capaz de estabelecer um canal seguro SSL/TLS com o cliente;

• RNF 02: O PEP deve estar alinhado aos princípios REST ao solicitar serviços ao IdP e ao

PDP; e

• RNF 03: O PEP deve se comunicar com os outros elementos da AAI utilizando canais

seguros mutuamente autenticados estabelecidos por meio do protocolo SSL/TLS.

D.3 REQUISITOS FUNCIONAIS E NÃO-FUNCIONAIS DO PAP

A seguir, são descritos os requisitos funcionais do PAP:

• RF 01: O PAP deve prover uma interface para que um usuário administrador gerencie

políticas de controle de acesso no formato XACML; e

• RF 02: O PAP deve ser capaz de recuperar uma política de controle de acesso mediante

solicitação do PDP.

Os requisitos não-funcionais do PAP são:

• RNF 01: O PAP deve estar alinhado aos princípios REST ao interagir com outros compo-

nentes da AAI; e

161

• RNF 02: O PAP deve se comunicar utilizando canais seguros mutuamente autenticados

estabelecidos por meio do protocolo SSL/TLS.

D.4 REQUISITOS FUNCIONAIS E NÃO-FUNCIONAIS DO PIP

A seguir, são descritos os requisitos funcionais do PIP:

• RF 01: O PIP, mediante solicitação de informações adicionais para tomada de decisão de

autorização por parte do PDP, deve ser capaz de recuperar tais informações.

Os requisitos não-funcionais do PIP são:

• RNF 01: O PIP deve estar alinhado aos princípios REST ao interagir com outros compo-

nentes da AAI; e

• RNF 02: O PIP deve se comunicar utilizando canais seguros mutuamente autenticados


D.5 REQUISITOS FUNCIONAIS E NÃO-FUNCIONAIS DO PDP

A seguir são descritos os requisitos funcionais do PDP:

• RF 01: O PDP deve ser capaz de solicitar ao PAP uma política de controle de acesso

adequada a requisição que está sendo avaliada;

• RF 02: O PDP deve ser capaz de avaliar se precisa de informações adicionais, além daquelas

presentes na requisição de decisão de autorização enviada pelo PEP, para tomar uma decisão

de autorização;

• RF 03: O PDP deve ser capaz de solicitar ao PIP por informações adicionais necessárias

para tomar uma decisão de autorização;

• RF 04: O PDP deve ser capaz de tomar uma decisão de autorização; e

• RF 05: O PDP deve ser capaz de enviar a decisão de autorização tomada ao PEP.

Os requisitos não-funcionais do PDP são:

162

• RNF 01: O PDP deve estar alinhado aos princípios REST ao interagir com outros compo-

nentes da AAI; e

• RNF 02: O PDP deve se comunicar utilizando canais seguros mutuamente autenticados


D.6 REQUISITOS FUNCIONAIS E NÃO-FUNCIONAIS DO IDP

A seguir são descritos os requisitos funcionais do IdP:

• RF 01: O IdP deve ser capaz de autenticar clientes dispositivos ou usuários;

• RF 02: O IdP deve ser capaz de gerar asserções SAML diante de eventos de autenticação

bem-sucedidos;

• RF 03: O IdP deve ser capaz de gerar erros para o cliente diante de eventos de autenticação

mal-sucedidos; e

• RF 04: O IdP deve ser capaz de validar a assinatura digital presente em uma asserção SAML

gerada por um IdP da federação.

Os requisitos não-funcionais do IdP são:

• RNF 01: O IdP deve estar alinhado aos princípios REST ao interagir com outros componen-

tes da AAI e com os clientes;

• RNF 02: O IdP deve se comunicar com outros elementos da AAI utilizando canais seguros

mutuamente autenticados estabelecidos por meio do protocolo SSL/TLS; e

• RNF 03: O IdP deve poder se comunicar com um cliente (dispositivo ou usuário) que não

possui certificado digital, utilizando um canal seguro estabelecido por meio do protocolo

SSL/TLS.

D.7 DIAGRAMAS DE SEQUÊNCIA

O diagrama de sequência da Figura 29 mostra como é realizado o acesso de um cliente a um

recurso quando este não possui uma asserção SAML, necessária para que o cliente possa acessar o

163

recurso protegido no dispositivo SP da federação. Inicialmente, o Cliente Ativo SAML solicita ao

dispositivo SP a política de qualidade de proteção do serviço que o cliente deseja acessar, por meio de

uma requisição HTTP GET direcionada à sp111.dominioa.com/recurso/politica. A política é enviada

pelo dispositivo SP ao Cliente Ativo SAML por meio de uma mensagem HTTP 200 OK. O Cliente

Ativo SAML interpreta a política (escrita no padrão WS-Policy) e gera uma requisição de autenticação

SAML (SAMLAuthnRequest) para o IdP.

Dispositivo SP Cliente Ativo

HTTP GETsp111.dominioa.com/recurso/politica

HTTP 200 OKPolítica WS-Policy

Gera SAMLAuthn

Request

IdP do ClienteIdP do SP

HTTP POSTidp.dominiob.com/authn

SAMLAuthnRequest

Verifica Contexto de Segurança

opt

Caso não exista contexto de segurança Finaliza Autenticação

HTTP 200 OKAsserção SAML

Monta requisição

para SPHTTP GET/POST/PUT/DELETEsp111.dominioa.com/recurso

Asserção SAML

HTTP 200 OKRecurso

HTTP POSTidp.aai.dominioa.com/validaassercao

Asserção SAML

HTTP 200 OKAsserção Válida

PDP

HTTP POST - pdp.aai.dominioa.com/decisaoRequisição do Cliente

HTTP 200 OKDecisão de Autorização

Inicia Autenticação

Figura 29. Diagrama de Sequência do Cliente Ativo SAML quando o cliente não possui uma asserçãoSAML

Ao receber a requisição de autenticação, o IdP verifica se o cliente já possui um contexto de

segurança válido no IdP. Se este contexto não existir, o IdP inicia o processo de autenticação do cliente

usando um mecanismo suportado por ambos e aceito pelo SP. Após estabelecer o contexto de segurança

para o cliente, o IdP responde ao Cliente Ativo SAML com uma mensagem SAML Response contendo

uma asserção SAML. De posse da asserção, o Cliente Ativo SAML monta a requisição de serviço para

envio ao dispositivo SP contendo a asserção SAML. Essa requisição é enviada ao recurso desejado

(sp111.dominioa.com/recurso) por meio de algum método HTTP (GET, POST, PUT ou DELETE). O

SP (PEP) solicita ao IdP a validação da asserção SAML apresentada e, após a confirmação da validade

desta, solicita ao PDP uma decisão de autorização acerca da solicitação do cliente. Essa decisão é

164

tomada pelo PDP e encaminhada ao dispositivo SP. Com base nisso, o dispositivo SP responde ao

Cliente Ativo SAML com o recurso solicitado ou com um erro HTTP.

A Figura 30 mostra o diagrama de sequência que modela o processo de tomada de decisão

de autorização de acesso a um determinado recurso, o qual é feito pela AAI4WoT. O processo inicia

quando o PEP encaminha ao IdP a solicitação de validação da asserção SAML recebida e recebe

como resposta que a asserção é válida. O PEP então encaminha ao PDP uma requisição de decisão de

autorização. O PDP solicita ao PAP uma política de controle de acesso adequada para a solicitação.

Após receber a política do PAP, caso necessário, o PDP solicita ao PIP informações adicionais para

que a decisão de autorização possa ser tomada. Diante da resposta do PIP, o PDP toma a decisão de

autorização e a envia ao PEP, o qual aplica a decisão tomada.

PEP IdP

HTTP POSTidp.aai.dominioa.com/validaassercao

Asserção SAML

PDP

opt

Caso faltem informações ao PDP para tomada de decisão

PAP PIP

HTTP POST - pdp.aai.dominioa.com/decisaoRequisição do Cliente

HTTP POSTpap.aai.dominioa.com/buscapolitica

Infos. RequisiçãoBusca

Política

HTTP 200 OK - Informações Solicitadas

HTTP POST - pip.aai.dominioa.com/maisinfoInformações Necessárias

Busca Informações

Toma decisão de autorizaçãoHTTP 200 OK - Decisão de Autorização

HTTP 200 OK - Asserção Válida

HTTP 200 OKPolítica de Controle de Acesso

Figura 30. Diagrama de Sequência da tomada de decisão de autorização

Uma Infraestrutura de autenticação e de autorização para a ...siaibib01.univali.br/pdf/Marlon...

Documents

Transcript of Uma Infraestrutura de autenticação e de autorização para a ...siaibib01.univali.br/pdf/Marlon...