Protocolo Distribuído para Dispositivos de Internet Das Coisas em Instalações Offline

MINISTÉRIO DA DEFESA
EXÉRCITO BRASILEIRO
DEPARTAMENTO DE CIÊNCIA E TECNOLOGIA
INSTITUTO MILITAR DE ENGENHARIA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA DE TRANSPORTES
RICARDO DE AZEVEDO BRANDÃO
PROTOCOLO DISTRIBUÍDO PARA DISPOSITIVOS DE INTERNET DAS

COISAS EM INSTALAÇÕES OFFLINE
RIO DE JANEIRO
2021
PROTOCOLO DISTRIBUÍDO PARA DISPOSITIVOS DE INTERNET DAS

COISAS EM INSTALAÇÕES OFFLINE
Tese apresentada ao Programa de Pós-graduação em Enge-

nharia de Transportes do Instituto Militar de Engenharia,
como requisito parcial para a obtenção do título de Doutor
em Ciências em Engenharia de Transportes.
Orientador: Ricardo Choren, D.Sc.
Rio de Janeiro
2021
©2021
INSTITUTO MILITAR DE ENGENHARIA
Praça General Tibúrcio, 80 – Praia Vermelha
Rio de Janeiro – RJ CEP: 22290-270
Este exemplar é de propriedade do Instituto Militar de Engenharia, que poderá incluí-lo em base
de dados, armazenar em computador, microfilmar ou adotar qualquer forma de arquivamento.
É permitida a menção, reprodução parcial ou integral e a transmissão entre bibliotecas deste
trabalho, sem modificação de seu texto, em qualquer meio que esteja ou venha a ser fixado,
para pesquisa acadêmica, comentários e citações, desde que sem finalidade comercial e que
seja feita a referência bibliográfica completa.
Os conceitos expressos neste trabalho são de responsabilidade do autor e do orientador.
Brandão, Ricardo de Azevedo.

Protocolo distribuído para dispositivos de Internet das Coisas em instalações
offline / Ricardo de Azevedo Brandão. – Rio de Janeiro, 2021.
95 f.
Orientador: Ricardo Choren.
Tese (doutorado) – Instituto Militar de Engenharia, Engenharia de Transportes,

2021.
1. Comunicação entre dispositivos. 2. Segurança e Privacidade. 3. Internet

das Coisas. 4. Dispositivos com restrições. i. Choren, Ricardo (orient.) ii. Título
Protocolo distribuído para dispositivos de Internet das

Coisas em instalações offline
Tese apresentada ao Programa de Pós-graduação em Engenharia de Transportes do

Instituto Militar de Engenharia, como requisito parcial para a obtenção do título de
Doutor em Ciências em Engenharia de Transportes.
Orientador: Ricardo Choren.
Aprovada em 13 de dezembro de 2021, pela seguinte banca examinadora:
Prof. Ricardo Choren - D.Sc. do IME - Presidente
Prof. Paulo César Salgado Vidal - D.Sc. do IME
Prof. Ronaldo Moreira Salles - Ph.D do IME
Prof. Célio Vinicius Neves de Albuquerque - Ph.D da UFF
Prof. David Fernandes Cruz Moura - D.Sc. do CETEx
Rio de Janeiro
2021
Este trabalho é dedicado à minha esposa e aos meus filhos.
AGRADECIMENTOS
A minha esposa e filhos, pelo incentivo e apoio durante toda essa jornada.
Ao meu Orientador Ricardo Choren, por seu apoio, disponibilidade e atenção.
Ao Instituto Militar de Engenharia, na figura de seus professores, funcionários e
alunos.
E a todas as pessoas que direta ou indiretamente apoiaram esse projeto.
“Qualquer idéia poderosa é absolutamente
fascinante e absolutamente inútil
até decidirmos usá-la.”
Richard Bach
RESUMO
Os sistemas de controle industriais ou ICSs (Industrial Control Systems) se popularizaram

com o advento dos primeiros controles automatizados no final dos anos 1960. Seu uso e sua
complexidade aumentaram com a evolução da eletrônica e o surgimento de equipamentos
de automação informatizados. Naturalmente surgiu a necessidade de controlar e monitorar
esses sistemas, inclusive aqueles que se encontram em diferentes localizações geográficas.
Para atender essa demanda foram criados os sistemas SCADA (Supervisory Control and
Data Acquisition), considerado o maior subgrupo dos ICSs. No entanto, nem todos os
dispositivos de um ICS têm acesso a serviços de comunicação ou, em alguns casos, têm
apenas acesso intermitente à rede ICS. Assim, a comunicação entre dispositivos offline com
a rede, mantendo a autenticidade e a integridade das mensagens é um problema pouco
abordado pela literatura. A partir desse contexto, este trabalho propõe um protocolo
de comunicação distribuído e descentralizado para redes ICSs que possibilita a troca
de mensagens entre a rede e dispositivos offline, provendo serviços de autenticação e
integridade das mesmas. O protocolo tem como suas principais características: ter os
seus serviços de propagação das mensagens, autenticação e integridade descentralizados
com a utilização de rotinas criptográficas leves; e utilizar um banco de dados distribuído.
A conexão entre os dispositivos é estabelecida por autenticação mútua, que independe
de um serviço centralizado, e a propagação das mensagens é realizada por conexão
P2P, possibilitando assim uma comunicação assíncrona entre os dispositivos offline e o
restante da rede. Um protótipo foi desenvolvido para validar as hipóteses apresentadas.
Foram realizados experimentos com o objetivo de testar as funcionalidades do protocolo
considerando uma rede com dispositivos offline e uma simulação na qual um dispositivo
recupera totalmente seus dados já propagados, apagados por um suposto problema no
sistema de armazenamento. Foram simulados ataques do tipo MitM (man-in-the-midle)
com o objetivo de testar os serviços de autenticação e integridade do protocolo. A partir
dos resultados positivos dos testes e simulações, podemos concluir que a solução proposta
atingiu seu objetivo: propor um protocolo de comunicação distribuído e descentralizado
para redes ICSs IIoT (Industrial Internet of Things) que permitam a troca de mensagens
entre a rede e dispositivos offline provendo serviços de autenticação e integridade das
mesmas.
Palavras-chave: Comunicação entre dispositivos. Segurança e Privacidade. Internet das

Coisas. Dispositivos com restrições.
ABSTRACT
Industrial Control Systems (ICSs) became popular with the advent of the first automated
controls in the late 1960s. Its use and complexity increased with the evolution of electronics
and the emergence of computerized automated equipment. The need to control and
monitor these systems have emerged, even for those in different geographic locations.
SCADA (Supervisory Control and Data Acquisition) systems were created to meet this
need, considered to be the highest subgroup of ICSs. However, not all ICS devices have
access to communication services or, in some cases, only have intermittent access to the
ICS network. Thus, communication between offline devices and the network, maintaining
authenticity and integrity of messages is a problem addressed poorly by the literature.
Within this context, the work presented here proposes a distributed and decentralized
communication protocol for ICS networks that enable the message exchange between the
network and offline devices; providing them with authentication and integrity services. The
main features of the protocol are: decentralized message propagation, authentication, and
integrity services using lightweight cryptographic algorithms; and a distributed database.
The connection between devices uses mutual authentication, independent of a centralized
service. The message propagation is performed by P2P connection, enabling asynchronous
communication between the offline devices and the remainder of the network. A prototype
was developed to validate the hypotheses presented. Experiments were made to test the
protocol functionalities considering a network with offline devices and a simulation in
which a device fully recovers its already propagated data, deleted by a supposed problem
in the storage system. MitM (man-in-the-middle) attacks were simulated to test the
authentication and integrity services of the protocol. The positive results of the tests
and simulations, shows the proposed solution has reached its goal: propose a distributed
and decentralized communication protocol for ICSs IIoT ((Industrial Internet of Things))
networks that allow the exchange of messages between the network and offline devices,
providing authentication and integrity services.
Keywords: Device-to-Device Communication. Machine-to-Machine Communications.

Secure Communications. Security and Privacy. Internet of Things. Constrained Devices.
LISTA DE ILUSTRAÇÕES
Figura 1 – Arquitetura de um ICS (1) . . . . . . . . . . . . . . . . . . . . . . . . . 16

Figura 2 – Tela de controle de uma ICS (2) . . . . . . . . . . . . . . . . . . . . . . 17
Figura 3 – Fluxo de Dados em uma operação normal de um ICS (1) . . . . . . . . 18
Figura 4 – Exemplo de rede com dispositivos offline . . . . . . . . . . . . . . . . . 19
Figura 5 – Cenários de Ataque e seus caminhos . . . . . . . . . . . . . . . . . . . 20
Figura 6 – Replay Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figura 7 – Espelhamento de Sinal . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figura 8 – Exemplo de uma Arquitetura DTN simples (3) . . . . . . . . . . . . . 24
Figura 9 – Arquitetura Mesh Híbrida (4) . . . . . . . . . . . . . . . . . . . . . . . 26
Figura 10 – Exemplo de Rede Mesh sem fio . . . . . . . . . . . . . . . . . . . . . . 26
Figura 11 – Exemplo de Arquitetura Fog Computing . . . . . . . . . . . . . . . . . 27
Figura 12 – Arquitetura do protocolo MQTT-SN (5) . . . . . . . . . . . . . . . . . 29
Figura 13 – Modelo de Interação do protocolo CoAP (6) . . . . . . . . . . . . . . . 29
Figura 14 – Visão simplificada do blockchain . . . . . . . . . . . . . . . . . . . . . . 35
Figura 15 – Arquitetura proposta por Vishwakarma e Das(7) . . . . . . . . . . . . 37
Figura 16 – Arquitetura de Referência de Fog Computing (8) . . . . . . . . . . . . 39
Figura 17 – Modelo do Systema IIoT (9) . . . . . . . . . . . . . . . . . . . . . . . . 42
Figura 18 – Esquema da Solução Proposta por Novo(10) . . . . . . . . . . . . . . . 43
Figura 19 – Visão Geral do cenário ilustrativo . . . . . . . . . . . . . . . . . . . . . 47
Figura 20 – Visão detalhada dos feeds dos dispositivos afiliados ao Pub 3 . . . . . . 48
Figura 21 – Criação e Validação do Ticket . . . . . . . . . . . . . . . . . . . . . . . 48
Figura 22 – Criação do Pub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Figura 23 – Criação de Convites . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figura 24 – Criação de Dispositivo Comum . . . . . . . . . . . . . . . . . . . . . . 50
Figura 25 – Instalação dos Convites . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Figura 26 – Comunicação com o Pub . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Figura 27 – Cifragem e Decifragem do Convite . . . . . . . . . . . . . . . . . . . . 53
Figura 28 – Geração do Ticket e envio ao dispositivo . . . . . . . . . . . . . . . . . 54
Figura 29 – Criação de mensagem e armazenamento no feed . . . . . . . . . . . . . 55
Figura 30 – Estrutura do feed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figura 31 – Mensagens Privadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figura 32 – Criação do Bloco de Mensagem . . . . . . . . . . . . . . . . . . . . . . 56
Figura 33 – Propagação da mensagem entre os dispositivos . . . . . . . . . . . . . . 57
Figura 34 – Sincronização - Handshake . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figura 35 – Sincronização - Autenticação Mútua (D02) . . . . . . . . . . . . . . . . 59
Figura 36 – Sincronização - Autenticação Mútua (D01) . . . . . . . . . . . . . . . . 60
Figura 37 – Sincronização de Mensagens – Detalhes do feed . . . . . . . . . . . . . 61
Figura 38 – Sincronização de Mensagens – Envio de Mensagens . . . . . . . . . . . 62
Figura 39 – Sincronização de Mensagens – Recepção de Mensagens . . . . . . . . . 63
Figura 40 – Dispositivos do Experimento . . . . . . . . . . . . . . . . . . . . . . . . 64
Figura 41 – Diagrama de Componentes - Visão Geral . . . . . . . . . . . . . . . . . 65
Figura 42 – Diagrama de Componentes - Criptografia . . . . . . . . . . . . . . . . . 66
Figura 43 – Comunicação por sockets . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Figura 44 – Cenário de Teste 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Figura 45 – Sincronização entre Dispositivos 1 e 2 . . . . . . . . . . . . . . . . . . . 69
Figura 46 – Sincronização entre dispositivos 2, 3 e 4 . . . . . . . . . . . . . . . . . 70
Figura 47 – Sincronização entre dispositivos . . . . . . . . . . . . . . . . . . . . . . 71
Figura 48 – Perda dos dados – Dispositivo 2 . . . . . . . . . . . . . . . . . . . . . . 72
Figura 49 – Recuperação dos tickets – Dispositivo 2 . . . . . . . . . . . . . . . . . . 72
Figura 50 – Recuperação de dados – Dispositivo 2 . . . . . . . . . . . . . . . . . . 73
Figura 51 – Cenário de Testes com dispositivos IoT . . . . . . . . . . . . . . . . . . 73
Figura 52 – Geração das Mensagens . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Figura 53 – Sincronização com os Pubs . . . . . . . . . . . . . . . . . . . . . . . . . 74
Figura 54 – Sincronização Offline . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Figura 55 – Sincronização Offline – Terceira Etapa . . . . . . . . . . . . . . . . . . 76
Figura 56 – Ataque por Dispositivo Falso – Criação do Pub e do Dispositivo . . . . 77
Figura 57 – Ataque por Falso Pub – Tentativa de Sincronização . . . . . . . . . . . 77
Figura 58 – Ataque eavesdropping – Coleta do ticket . . . . . . . . . . . . . . . . . 78
Figura 59 – Ataque eavestropping – Tentativa de Sincronização . . . . . . . . . . . 79
Figura 60 – Ataque de Modificação – Acesso indevido ao dispositivo . . . . . . . . . 80
Figura 61 – Ataque de Modificação – Tentativa de Propagação dos feeds comprometidos 81
Figura 62 – Situação Inicial dos feeds . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Figura 63 – Fork criado pelo participante desonesto no feed P01-R . . . . . . . . . 82
Figura 64 – Alteração do feed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Figura 65 – Tentativa de Propagação das novas mensagens . . . . . . . . . . . . . . 83
LISTA DE TABELAS
Tabela 1 – Vulnerabilidades à ameaças (10) . . . . . . . . . . . . . . . . . . . . . . 43

Tabela 2 – Trabalhos Relacionados – Tabela Comparativa . . . . . . . . . . . . . 44
Tabela 3 – Tabela de Afiliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Tabela 4 – Códigos dos Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Tabela 5 – Trabalhos Relacionados – Comparativo com a Solução Proposta . . . 84
LISTA DE ABREVIATURAS E SIGLAS
CoAP Constrained Application Protocol
DCS Distributed Control System
DTLS Datagram Transport Layer Security
DTN Delay-Tolerant Network
ENISA European Union Agency For Network And Information Security
EWS Engineering Workstation
HTTP Hypertext Transfer Protocol
ICS Industrial Control Systems
IEC International Electrotechnical Commission
IED Intelligent Electronic Device
IHM Interface Homem Máquina
IoT Internet of Things
IIoT Industrial Internet of Things
ISA International Society of Automation
MAC Message Authentication Code
MitM Man in the middle
MQTT Message Queuing Telemetry Transport
P2P Peer to Peer
PLC Programmable Logic Controller
QoS Quality of Service
RTU Remote Terminal Unit
SCADA Supervisory Control and Data Acquisition
SHA Secure Hash Algorithm
UDP User Datagram Protocol
XMPP Extensible Messaging and Presence Protocol

SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2 DEFINIÇÃO DO PROBLEMA . . . .
. . . . . . . . . . . . . . . . . 23
2.1 HISTÓRICO . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 23
2.1.1 ARQUITETURA . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 23
2.1.2 PROTOCOLOS . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 27
2.2 O PROBLEMA . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 31
2.3 OBJETIVO GERAL . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 32
2.3.1 OBJETIVOS ESPECÍFICOS . . . . . . . .
. . . . . . . . . . . . . . . . . . 33
2.3.2 REQUISITOS DO MECANISMO PROPOSTO . . . . . . . . . . . . . . . . . 33
3 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . 34
3.1 SEGURANÇA EM ICSS IIOT . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.1 BLOCKCHAIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2 VISHWAKARMA E DAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3 ALI ET AL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4 FERRETTI, MARCHETTI E COLAJANNI . . . . . . . . . . . . . . . . . . 38
3.5 KIM ET AL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.6 AMANLOU E BAKAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.7 RAHMAN ET AL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.8 BRUNO E BOLETTIERI . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.9 YANG ET AL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.10 OSCAR NOVO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.11 CONSIDERAÇÕES SOBRE OS TRABALHOS RELACIONADOS . . . . . . 44
4 PROPOSTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1 FUNDAMENTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2 UM CENÁRIO ILUSTRATIVO . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3 O PROTOCOLO PROPOSTO . . . . . . . . . . . . . . . . . . . . . . . . 47
5 AVALIAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.1 CENÁRIO DOS EXPERIMENTOS . . . . . . . . . . . . . . . . . . . . . . 64
5.2 TESTES DE FUNCIONAMENTO . . . . . . . . . . . . . . . . . . . . . . 67
5.2.1 TESTE DE PROPAGAÇÃO DE MENSAGENS . . . . . . . . . . . . . . . . . 67
5.2.2 TESTE DE RECUPERAÇÃO DO BANCO DE DADOS . . . . . . . . . . . . . 69
5.2.3 TESTE COM DISPOSITIVOS IOT . . . . . . . . . . . . . . . . . . . . . . . 70
5.3 SIMULAÇÃO DE ATAQUES . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.3.1 ATAQUE DE FABRICAÇÃO – SPOOFING . . . . . . . . . . . . . . . . . . . 75
5.3.2 ATAQUE EAVESDROPPING . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.3.3 ATAQUE DE MODIFICAÇÃO – ALTERAÇÃO E EXCLUSÃO . . . . . . . . . . 78
5.3.4 ATAQUE DE MODIFICAÇÃO – EXCLUSÃO DE MENSAGENS PÓS SINCRONI-
ZAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.4 DISCUSSÕES SOBRE A SOLUÇÃO PROPOSTA . . . . . . . . . . . . . . 83
6 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.1 CONTRIBUIÇÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.2 TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . . . 86
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
15
1 INTRODUÇÃO
O desenvolvimento de controles automáticos está intimamente ligado aos problemas

práticos que precisavam ser resolvidos durante qualquer fase da história humana. A principal
motivação para esses desenvolvimentos na antiguidade foi iniciada com a necessidade da
determinação precisa do tempo (11). Um novo impulso no desenvolvimento dos sistemas
de controle aconteceu a partir de 1700 com a Primeira Revolução Industrial (12). Do final
de 1800 ao início de 1900, a maioria das invenções de sistemas de controle se concentravam
em atuar nos processos básicos, como controle de temperatura, pressão, níveis de líquidos e
velocidade de rotação de máquinas. Porém, no decorrer do século XX o avanço da indústria
demandou um desenvolvimento de controles para sistemas hidráulicos, pneumáticos e a
vapor (12, 11).
No início da década de 30, novas teorias de controle foram desenvolvidas e incorpo-
radas aos sistemas de controles industriais. Esse período foi seguido por um grande avanço
nos sistemas de comunicação, preparando o terreno para aplicações de sistemas de controle
modernos. Na sequência, a álgebra booleana foi aplicada nos circuitos elétricos com a
utilização de relés. O objetivo era controlar, automatizar e proteger os processos (13). No
final da década de 1960, os primeiros controles computadorizados entraram em cena e a
partir da década de 1970 evoluíram com o desenvolvimento de microprocessadores. Isso
abriu caminho para o desenvolvimento do PLC (Programmable Logic Controller) que se
tornou bastante popular na indústria, usado para automatizar processos eletromecânicos
industriais (14).
Com o desenvolvimento de novos equipamentos, sensores e atuadores, a complexi-
dade dos sistemas de controle foi aumentando e com isso houve a necessidade de utilizar
sistemas para gerenciar os diversos equipamentos utilizados para o controle dos processos.
Convencionou-se chamar esses sistemas de Sistemas de Controle Industriais, os ICSs. São
definidos pela ISA-99/IEC 62443 como “uma coleção de pessoal, hardware e software
que pode afetar ou influenciar a operação segura, protegida e confiável de um processo
industrial” (12).
Os modernos ICSs usam diversas tecnologias para controlar e automatizar a opera-
ção de processos industriais, cuidando do monitoramento, do controle e da interconexão
entre dispositivos em uma variedade de indústrias, como geração, transmissão e distribuição
de energia elétrica, produção química, óleo e gás e dessalinização da água (14). A ENISA
(European Union Agency For Network And Information Security), uma agência da União
Europeia com foco na Segurança da Informação e Redes, cita que uma parte importante
das infraestruturas críticas da Europa é gerenciada e controlada por ICSs (15). No Brasil, a
Capítulo 1. Introdução 16
Estratégia Nacional de Defesa, elaborada pelo Ministério da Defesa, ressalta a importância

de aprimorar a Segurança da Informação e das Comunicações e a Segurança Cibernética,
em todas as instâncias do Estado, com ênfase na proteção das Estruturas Críticas (16).
O monitoramento e o controle dos ICSs surgiram como uma necessidade dos
responsáveis pelas plantas industriais. Para atender a essa demanda, foram criados os
sistemas SCADA (Supervisory Control and Data Acquisition). Choi, Yun e Kim(1) definem
um ICS como um sistema composto por módulos de medições, monitoramento e controle
instalados no campo conectados a equipamentos e softwares de gerenciamento através de
sistemas de telecomunicações. Atualmente considerado o maior subgrupo dos ICSs (15),
um sistema SCADA típico é composto por um controlador central e vários dispositivos de
campo como PLCs, sensores e atuadores. Geralmente, sua arquitetura possuí três níveis,
como ilustrado na Figura 1: o nível 0, no qual estão instalados os diversos dispositivos
de campo como sensores, atuadores e medidores; o nível 1, responsável pelo controle do
processo do ICS, formado por DCSs (Distributed Control System), PLCs, RTUs (Remote
Terminal Unit) ou IEDs (Intelligent Electronic Device) e finalmente o nível 2, que gerencia
o processo como um todo e no qual realiza o interfaceamento com os operadores através
das EWSs (Engineering Workstation), IHMs (Interface Homem Máquina), análise de dados
históricos e informações dos dispositivos de campo.
Figura 1 – Arquitetura de um ICS (1)
A figura apresenta também o fluxo de dados em um ICS: entre os níveis 0 e 1

trafegam os dados coletados no campo e os sinais enviados pelos sistemas de controle aos
sensores e atuadores. Entre os níveis 1 e 2 trafegam as informações de alto nível e sinais
de controle dos protocolos de comunicação. Horizontalmente, ou seja, na comunicação
entre dispositivos posicionados no mesmo nível, são coletados e armazenados os logs de
operação dos diversos equipamentos. Com relação à abrangência, os dados podem trafegar
no caminho completo, ou apenas por parte dele.

A Figura 2 apresenta, de forma estruturada, um exemplo de sistema SCADA
responsável pelo monitoramento e controle de uma coluna de destilação. Nela é possível
identificar os diversos elementos da arquitetura citada na Figura 1: os dispositivos de
campo (válvulas, bombas e sensores); que são comandados por sistemas de controle (que
interagem com os dispositivos de campo), e o sistema de gerenciamento.
Figura 2 – Tela de controle de uma ICS (2)
Inicialmente, os ICSs eram projetados para utilizar redes de comunicação privadas.

Nesse contexto, e em operações normais, o fluxo de dados em um ICS decorrente da interco-
nexão entre dispositivos, pode ser classificado conforme a Figura 3 [1]: (i) controle remoto,
no qual os comandos partem de uma localização remota, chegando até os dispositivos de
campo e depois retornando à origem; (ii) o controle local, no qual as decisões são tomadas
por equipamentos de controle automático como PLCs e o retorno das operações é enviado
ao nível gerencial do sistema; (iii) o controle stand-alone, que assemelha-se ao controle
local, porém o retorno não é enviado ao nível gerencial; (iv) instrumentação, medições de
campo enviadas ao sistema de gerenciamento e (v) evento/estado, no qual os sistemas de
controle enviam diretamente ao sistema gerencial dados sobre a operação. Além disso, a
troca de dados entre o controlador e os dispositivos de campo é realizada através protocolos
de comunicação, que foram desenvolvidos especificamente para aplicações industriais (17).
Com o decorrer dos anos, as organizações têm anexado mais dispositivos e pro-
Figura 3 – Fluxo de Dados em uma operação normal de um ICS (1)
cessos aos ICSs, criando redes cada vez mais complexas. Adicionalmente, a evolução dos
dispositivos tem permitido uma maior comunicação entre eles, aumentando a comunicação
horizontal (18). Nesses casos podemos considerar que algumas funções executadas pelos
níveis 1 e 2 da Figura 3 estão descentralizadas, sendo executadas pelos dispositivos de
campo, como ocorre por exemplo nas implementações que utilizam Arquitetura de Névoa
ou de Borda (Fog Computing ou Edge Computing). Dada a complexidade desse novo
cenário, com o objetivo de reduzir despesas operacionais, facilitar a acessibilidade e contar
com maior automação e supervisão, os ICSs passaram a utilizar infraestruturas de redes
públicas, como a Internet (15, 17).
Nesse sentido, os ICSs entraram em uma nova era, chamada de Internet das Coisas
(IoT), na qual a Internet é a tecnologia que permite o acesso de dispositivos a uma rede (19).
O uso de IoT no ambiente industrial – também conhecido como IIoT – está promovendo a
evolução dos ICSs, desempenhando um papel importante em suas conexões ao ciberespaço,
melhorando a eficiência operacional e aumentando o rendimento da produção (20). A
diferença entre um ICS tradicional e esse novo ICS IIoT está na conectividade com
outros sistemas e usuários, fomentando o emprego de sensores e atuadores em ambientes
industriais, além de aumentar sua diversidade e escala (21).
Embora um ICS IIoT use a Internet, nem sempre é possível supor que os diversos
dispositivos estejam, a todo momento, conectados à rede (22). Existem diversos motivos
pelos quais um dispositivo em um ICS IIoT fica offline, como (23): economia de energia,
circunstâncias externas (ex. problemas de conexão de redes wireless) e mobilidade. Apesar
de atualmente a cobertura por internet alcançar a marca de 90 por cento da população
mundial (24), áreas rurais ainda possuem deficiências não só na cobertura de telecomu-
nicações, como também deficiências no suprimento de energia elétrica (25, 24). Dessa
forma, sistemas de controle em localizações remotas sem cobertura de redes móveis, ou
de sistemas de telefonia são exemplos nos quais os dispositivos ficam permanentemente

sem conexão direta com os demais componentes de sua rede. Alguns exemplos nos quais a
conexão com a rede é intermitente incluem: dispositivos agrícolas, sistemas embarcados
em veículos ou embarcações.
A Figura 4 mostra um esquema de um ICS IIoT no qual dispositivos ou sistemas
podem estar offline. No exemplo todos os dispositivos e ICSs fazem parte de uma única rede
de monitoramento representada pelo sistema SCADA. Os dispositivos remotos retratados
na parte superior esquerda da figura, o ICS remoto à direita e a plataforma de petróleo
estão permanentemente desconectados da rede. Os dispositivos móveis e os dispositivos
embarcados instalados no helicóptero possuem conexões eventuais.
Figura 4 – Exemplo de rede com dispositivos offline
Nesse contexto, os dispositivos móveis são responsáveis por estabelecer a troca de

informações entre a rede e os dispositivos e ICSs remotos. O helicóptero exemplifica a
situação na qual as informações geradas durante o período em que estão sem conexão com
rede precisam ser enviadas aos seus destinatários assim que a conexão for restabelecida. Da
mesma forma, precisam receber as informações direcionadas aos dispositivos embarcados
durante o período em que estava desconectado.
De fato, se a popularização da IoT possibilitou o aumento do nível de automatização
e integração dos processos através da Internet, também deixaram os ICSs expostos a
ataques cibernéticos (26), por conta de fatores como (27): utilização de protocolos já
conhecidos pelos atacantes, o que facilita o acesso aos dispositivos que controlam os
processos industriais; a heterogeneidade de tecnologias empregadas, exigindo a inserção de
gateways ou softwares de integração; e baixa disponibilidade de recursos computacionais
dos dispositivos (dificultando a instalação de componentes de segurança).
Um relatório da ENISA (15) faz uma análise sobre as ameaças e vulnerabilidades
dos sistemas ICSs IIoT, citando que o aumento desse tipo de eventos tem imposto um
grande desafio aos profissionais responsáveis pela segurança desses sistemas para adaptá-los
à nova realidade a que foram expostos. A maioria desses ataques atua comprometendo
os processos de tomada de decisão, sejam essas decisões executadas por operadores ou
sistemas automáticos (28). Como exemplo, pode-se citar o trabalho de Lin, Wu e Lee(29)
que lista mais de 200 ataques em sistemas de infraestrutura crítica a cada ano, destacando
um caso na Alemanha no qual um forno utilizado em uma usina de aço foi destruído por
um ataque cibernético.
Com relação às ICSs, a Figura 5 apresenta os diversos cenários de ataque a uma
ICS IIoT. As linhas pretas sólidas indicam o fluxo normal de dados, sem ataque. As linhas
vermelhas sólidas indicam o caminho do ataque. As linhas vermelhas tracejadas indicam
que o ataque pode comprometer as informações posteriores.
Figura 5 – Cenários de Ataque e seus caminhos

(1)
O ataque de Interrupção ocorre quando o atacante consegue fazer com que o sistema
ou parte dele fique indisponível, seja por exaustão dos recursos, como no ataque DoS
- (Denial of Service), ou por destruição física. Assim, um ativo é destruído ou torna-se
indisponível, sendo um ataque contra disponibilidade. O ataque de Interceptação ocorre
quando o atacante consegue a informação desviando o fluxo da informação. Logo, um
ativo é acessado por uma parte não autorizada (pessoa, programa, etc), sendo um ataque
contra a confidencialidade.
O ataque de Fabricação ocorre quando o atacante consegue reproduzir mensagens
enviadas entre dois endereços de uma rede (30), em outras palavras, o atacante gera um
dado falso e o injeta no sistema, sem que emissor tenha realizado nenhuma ação. Este
é um ataque contra a autenticidade. Por fim, o ataque de Modificação ocorre quando a
informação é interceptada e modificada pelo atacante durante o trânsito entre o emissor e
o receptor (31), sendo um ataque contra a integridade.
O escopo deste trabalho está voltado para o tratamento de integridade e autentici-
dade em ICSs IIoT. Desta maneira, ele está focado nos ataques de Fabricação e Modificação.
Um dos mais elementares ataques de Fabricação é o spoofing ou masquerade (32). Neste
ataque, o objetivo é conseguir controle total sobre o dispositivo alvo (31). Uma vez que
tenha conseguido obter o controle, faz uma análise do ambiente e começa a se comportar
como um dispositivo autorizado. Usando, por exemplo, um IP válido para a rede, uma
técnica conhecida como IP spoofing (33). Já um dos principais ataques de Modificação é o
replay attack (ataque por repetição) (34), no qual o atacante busca violar a integridade do
sistema ao reproduzir mensagens enviadas entre dois endereços de uma rede (30, 32). O
atacante monitora a comunicação entre o Endereço 1 e Endereço 2, coletando as mensagens
enviadas e passado um tempo determinado as mensagens coletadas são enviadas novamente
para o Endereço 2 conforme exemplificado na Figura 6. O principal objetivo deste ataque
é atrapalhar o fluxo de comunicação entre emissor e receptor levando aos sistemas de
controle tomarem decisões errôneas baseados nas informações duplicadas enviadas pelo
atacante.
Figura 6 – Replay Attack

(30)
Uma variação do ataque de repetição utiliza a técnica de espelhamento do sinal,

na qual o sinal é gerado no sentido inverso durante o período do ataque (35), conforme
apresentado na Figura 7.
(a) Sinal Original (b) Sinal Mascarado por Espelhamento
Figura 7 – Espelhamento de Sinal
Lin, Wu e Lee(29) apresentam um grupo de ataques normalmente executados em

conjunto com o objetivo de invadir e comprometer um ou mais dispositivos de uma rede
industrial. Os ataques são: Reconnaissance Attack, é um tipo de ataque eavesdropping, que

ao conseguir acesso, normalmente não autorizado, a um dos dispositivos da rede, mapeia
sua arquitetura, identifica as características dos dispositivos, como fabricante, modelo e
protocolos utilizados; os ataques Response Injection Attack Command Injection Attack
têm como objetivo fazer com que os atuadores executem comandos errados, ou fora de hora.
No primeiro ataque são enviados ao sistema de controle informações incorretas do sensor,
enquanto que no segundo, são enviados comandos errados aos atuadores, sem a ciência do
sistema de controle (36). A maneira de proceder o ataque é a seguinte: o atacante registra
um determinado número de leituras geradas pelo sensor (Reconnaissance). Executa o
ataque na forma de uma sequência de sinais de controle para os atuadores (Command
Injection) enquanto envia para o sistema de controle a sequência de leituras previamente
registradas (Response Injection), mascarando a real situação do processo controlado.
Para buscar garantir a segurança de sistemas de informação automatizados, Stallings
apresenta cinco categorias de serviços (37): (i) autenticação, serviço que assegura que a
entidade é aquela que afirma ser e que a origem dos dados recebidos é conforme a alegada;
(ii) integridade dos dados, assegura que os dados recebidos são exatamente conforme
enviados por uma entidade autorizada; (iii) irretratabilidade, serviço que oferece proteção
contra a negação, por parte de uma das entidades envolvidas na comunicação de ter
participado de toda ou parte dela; (iv) controle de acesso, serviço que previne o uso não
autorizado de um recurso, controlando quem pode e em quais condições o recurso pode
ser acessado; e (v) confidencialidade dos dados, serviço responsável por proteger contra a
divulgação não autorizada dos dados.
23
2 DEFINIÇÃO DO PROBLEMA
Este capítulo apresenta o problema da necessidade de se manter a autenticidade e a

integridade na comunicação (fluxo de dados) em um ICS IIoT, no qual os dispositivos
instalados em diferentes localizações geográficas não têm acesso à serviços de comunicação
ou, em alguns casos, têm apenas acesso intermitente à rede.
A maioria dos dispositivos existentes nos ICSs tradicionais foram projetados sem
levar em consideração questões de segurança e privacidade (38). Nesses ICSs a segurança
era implementada através de um isolamento físico e, nos casos em que era necessário o
monitoramento e controle de sistemas remotos, esse isolamento era conseguido através da
utilização de redes de comunicação privadas.
2.1 Histórico
Em um cenário de ICS IIoT com dispositivos offline, uma solução ingênua para
estabelecer a comunicação com esses dispositivos é usar outros dispositivos móveis para
transportar as mensagens até que consigam conectar-se à rede e propagá-las até o destino
final, conforme ilustrado na Figura 4. Para tanto, existem algumas tecnologias (arquiteturas
e protocolos) que visam fazer esse transporte.
2.1.1 Arquitetura
As arquiteturas que se destacam como as adequadas para a comunicação de
dispositivos offline são a DTN (Delay-Tolerant Network), Mesh e Fog Computing. Embora
as estruturas de arquitetura apresentadas a seguir não definam, por si só, os serviços de
autenticidade e integridade, suas características baseadas na descentralização permitem
implementar esses serviços para dispositivos offline. Assim, o projeto de uma arquitetura
descentralizada é uma etapa importante no desenvolvimento da troca de mensagens neste
contexto.
A arquitetura que utiliza a comunicação ponto a ponto (P2P - Peer-to-Peer )
intuitivamente permite a participação de dispositivos offline. De acordo com (39):
“Uma arquitetura de rede distribuída pode ser chamada de rede ponto a

ponto, se os participantes compartilham uma parte de seus próprios recursos
de hardware. Esses recursos compartilhados são necessários para fornecer o
serviço e o conteúdo oferecido pela rede. Eles são acessíveis por outros pares
diretamente, sem passar por entidades intermediárias. Os participantes de tal
Capítulo 2. Definição do Problema 24
rede são, portanto, provedores de recursos, bem como solicitantes de recursos

(Definição 1)”.
O autor completa sua definição, classificando a rede P2P em Pura e Híbrida:
Pura: “se for primeiramente uma rede ponto a ponto de acordo com a Definição
1 e, em segundo lugar, se houver um único terminal escolhido arbitrariamente,
a entidade pode ser removida da rede sem que a rede sofra qualquer perda de
serviço de rede”
Híbrida: “se for em primeiro lugar uma rede ponto a ponto de acordo com a
Definição 1 e em segundo lugar uma entidade central é necessária para fornecer
parte dos serviços de rede oferecidos”.
A partir do contexto do uso de protocolos de comunicação executados em infra-

estruturas com ambientes sujeitos a atrasos e falhas de comunicação, Fall(40) propôs
uma arquitetura de rede estruturada por encaminhamento de mensagens assíncronas, com
expectativas limitadas de conectividade de ponta a ponta, nomeando-a Arquitetura DTN.
O trabalho do autor ressalta um problema anterior ao surgimento da Internet das Coisas.
Seu trabalho chamou a atenção dos profissionais que atuavam no setor espacial, uma vez
que a comunicação entre um computador na Terra e outro embarcado em um satélite ou
até mesmo em espaçonaves envolvidas em missões no espaço profundo, as interrupções são
mais frequentes e de maior duração. Protocolos como TCP/IP que funcionam para redes
terrestres podem ter problemas nas redes espaciais quando a conectividade não é contínua
ou há um longo atraso nas comunicações (3).
Cada nó pode se comunicar com qualquer outro nó desde que haja um meio de
comunicação disponível. Quando o nó destinatário de uma mensagem não está ao alcance
do nó remetente, outros nós podem ser utilizados para propagar a mensagem. Nesse caso
esses nós que propagam as mensagens fazem o papel de um gateway.
Cada nó tem o conhecimento de outros nós com os quais pode comunicar diretamente
e quando esses links de comunicação estão disponíveis. Para nós onde a comunicação direta
não é possível, os gateways DTN podem ser usados. Qualquer nó DTN que envie dados
para outro nó DTN é considerado um gateway. No exemplo simplificado apresentado na
Figura 8 se o nó 1 deseja enviar uma mensagem para o nó 4, os nós 2 e 3 funcionam como
gateways.
Figura 8 – Exemplo de uma Arquitetura DTN simples (3)

O DTN pode acomodar diferentes protocolos de entrega. Como cada um desses

protocolos fornecem diferentes semânticas, são necessários adaptadores para para transpor-
tar unidades de dados do protocolo DTN (chamados bundles) em cada um dos protocolos
correspondentes (41).
Para implementar os serviços de integridade das mensagens durante a propagação,
existe o conceito de transferência de custódia, que é realizada por uma solicitação feita a
partir do nó que envia os dados para o nó que os recepciona. Caso o nó receptor aceitar
a custódia dos dados, o nó solicitante pode excluir sua cópia dos dados. Ao aceitar a
custódia dos dados, o nó receptor aceita a responsabilidade de garantir que os dados sejam
transferidos para o destino final ou até que ele possa passar a custódia para outro nó (3).
Os serviços de integridade são implementados pela utilização de diversos mecanis-
mos criptográficos. Cada mensagem inclui um "postage stamp" imutável contendo uma
identidade verificável do remetente, uma aprovação, da classe de serviço solicitada (COS)
associada com a mensagem, e outro material criptográfico convencional para verificar a
precisão do conteúdo da mensagem. A arquitetura proposta também implementa serviços
de confidencialidade (41).
Apesar de ser uma arquitetura projetada para situações de comunicação inter-
mitente, mantendo a integridade e autenticidade, há alguns pontos de atenção na sua
utilização. Os mecanismos de roteamento da arquitetura DTN costumam consumir muitos
recursos computacionais, fazendo que projetistas optem por outras soluções no caso de
dispositivos restritos. Como exemplo, o trabalho apresentado por Madni, Iranmanesh e
Raad(42) aborda a utilização de protocolos Não-DTN em satélites CubeSat, que têm como
característica pequenas dimensões e recursos muito restritos.
Outro desafio apontado no trabalho de Mao et al.(43) tem relação com a transfe-
rência de custódia. Pois uma vez que as mensagens são apagadas após terem sido acetias
pelo nó destinatário, sua integridade depende exclusivamente do nó responsável pela sua
guarda. Um ataque a esse nó pode causar uma alteração nas mensagens ou até mesmo a
sua perda.
Um tipo de Rede Mesh é particularmente adequado para lidar com dispositivos
offline: a Wireless Mesh Network, que utiliza “saltos” entre os dispositivos que estão no
alcance de seus sinais de rádio para estabelecer o tráfego da rede (44). Dessa forma, os
dispositivos móveis podem alcançar dispositivos offline, permitindo um acesso temporário
à rede WMN através de uma infraestrutura de roteadores sem cabeamento entre os nós.
Cada dispositivo na rede atua como um nó de encaminhamento para transferir os dados.
Uma vez que a rede é descentralizada, o encaminhamento de dados só é possível para
algum dos dispositivos vizinhos e que estejam ao alcance do sinal de rádio (4).
Eu seu trabalho, Parvin(4) classifica as redes Mesh em três, baseadas nas suas
funcionalidades: (i) Arquitetura Mesh de Infraestrutura, na qual roteadores sem fio atuam
como uma espinha dorsal (back bone) para a estrutura de comunicação. Neste caso, os
clientes conectam-se a esses roteadores passivamente através de interfaces Ethernet. A
próxima claasificação é a (ii) Arquitetura Mesh baseada em Clientes, na qual os próprios
clientes atuam também como roteadores e a (iii) Arquitetura Mesh híbrida, na qual a
estrutura de back bone é composta tanto por roteadores como pelos clientes. A Figura 9
apresenta um exemplo de uma arquitetura Mesh híbrida.
Figura 9 – Arquitetura Mesh Híbrida (4)
No entanto, se o dispositivo estiver em uma área remota, o alcance do dispositivo

sem fio pode não ser suficiente para atingir o objetivo desejado, como exemplificado na
Figura 10. Nesse caso, seria necessário ter vários dispositivos sem fio dispostos em locais
específicos para que fosse possível criar uma rota para a rede principal.
Figura 10 – Exemplo de Rede Mesh sem fio

Para atender os requisitos dos projetos de Internet das Coisas, como escalabilidade,
privacidade, largura de banda, consumo de energia, eficiência no roteamento de rede e
comunicação sensível a atrasos, que já não estavam sendo atendidos convenientemente pela
arquitetura em nuvem, surgiram os conceitos de computação em névoa (Fog Computing) e
em Borda (Edge Computing). Tecnologias baseadas na descentralização e distribuição de
serviços que eram providos de forma centralizada pela computação em núvem (45). Nessas
arquiteturas um grande número de dispositivos heterogêneos, ubíquos e descentralizados
se comunicam e realizam tarefas sem a intervenção de terceiros (46). Um exemplo de
arquitetura Fog Computing está representada na Figura 11.
Figura 11 – Exemplo de Arquitetura Fog Computing
A figura apresenta a camada Fog na qual fica evidente a descentralização e dis-

tribuição dos serviços que na arquitetura tradicional eram providos pelos servidores na
nuvem, que na figura ficam posicionados na camada superior.
A descentralização dos serviços, levando-os para a borda da rede pode se ade-
quar como solução viável à questão dos dispositivos offline, porém há algumas questões
importantes a serem levadas em conta. A descentralização, neste caso, introduz novos
problemas relativos à implantação dos serviços antes disponíveis na nuvem: a transferência
de rotinas críticas insere mais pontos de vulnerabilidade aumentando a probabilidade
de ataques, além disso, torna-se mais complicado executar diferentes serviços em toda
a rede sem a implementação de um gerenciamento eficaz desses serviços (47). Outro
ponto que aumenta a complexidade desse gerenciamento é o aumento na infraestrutura de
comunicação, explicitada na figura pelas conexões f2f (Fog to Fog) e c2f (Cloud to Fog) e
heterogeneidade dos equipamentos utilizados.
2.1.2 Protocolos
Dois protocolos têm posição de destaque no ambiente de comunicação entre dispo-
sitivos IoT: o MQTT (Message Queuing Telemetry Transport) e o CoAP (Constrained
Application Protocol), que reforçam a afirmação de Thota e Kim(48), na qual mencionam

que após pesquisas sobre o desenvolvimento da IoT hoje, MQTT e CoAP figuram como os
principais protocolos que se enquadram no ambiente de IoT. De acordo com suas especi-
ficações (49, 50), ambos os protocolos foram desenvolvidos para comunicação Máquina
a Máquina (M2M) em ambientes com restrição de recursos, como ocorre no contexto da
Internet das Coisas.
O MQTT usa o sistema publicação/subscrição sobre o protocolo TCP/IP ou sobre
outros protocolos de rede que forneçam conexões bidirecionais ordenadas, sem perdas
(50). Em sua arquitetura, há a figura do Broker, que desempenha a função de servidor
e que realiza a troca de mensagens de forma assíncrona. Um Broker pode ser instalado
em qualquer dispositivo da rede. A arquitetura do protocolo permite que um Broker
seja espelhado, distribuindo e descentralizando o serviço. O MQTT tem três níveis de
Qualidade de Serviço (QoS - Quality of Service): (i) nível 0 onde pode ocorrer perda de
mensagem; (ii) nível 1 onde há a garantia de que as mensagens chegam ao destino, mas
podem ocorrer em duplicidade; e (iii) nível 2, no qual as mensagens chegam exatamente
uma vez. Assim, a utilização de Brokers distribuídos que podem acessar dispositivos offline,
aliada à utilização do nível de QoS maior ou igual a um, permite sua aplicação em redes
com dispositivos offline com garantia de entrega das mensagens aos seus destinatários.
A Oasis Open Foundation, responsável pela manutenção das especificações do
protocolo MQTT criou uma versão que considera as peculiaridades de uma WSN (Wirelless
Sensor Network), o MQTT-SN (MQTT For Sensors Networks) como é possível verificar
na sua documentação (5):
“MQTT-SN é projetado para ser o mais próximo possível do MQTT, mas é

adaptado às peculiaridades de um ambiente de comunicação sem fio, como
largura de banda baixa, falhas de link constantes, comprimento de mensagem
curto, etc. Ele também é otimizado para implementação em dispositivos de
baixo custo, operados por bateria e com recursos limitados de processamento e
armazenamento.”
Na prática o MQTT-SN possui mecanismos para reduzir o tamanho das mensagens

bem como a simplificação de alguns procedimentos visando um menor custo computacional.
Prevê também a inclusão de dois novos componentes o MQTT-Gateway que é o responsável
para fazer a integração com o MQTT Broker tradicional e o MQTT-Forwarder para os
casos nos quais o Gateway não esteja diretamente conectado a rede dos dispositivos,
conforme é apresentado na Figura 12. O Forwarder simplesmente encapsula os pacotes
MQTT-SN que recebe dos sensores e os encaminha inalterados para o Gateway; na direção
oposta, ele desencapsula os pacotes que recebe do Gateway e os envia aos sensores, também
inalterados (5).
Figura 12 – Arquitetura do protocolo MQTT-SN (5)
Porém, seja na implementação do MQTT ou do MQTT-SN a utilização de brokers

distribuídos implica na inserção de novos equipamentos e/ou serviços instalados próxi-
mos aos dispositivos offline. Nesses casos, a depender da aplicação há um aumento na
complexidade da gestão da rede, bem como a inserção de novos pontos de vulnerabilidade.
CoAP é um protocolo de camada de aplicação, cliente-servidor, do tipo requisi-
ção/resposta, projetado para uso com redes e nós restritos e executado sobre o protocolo
UDP (User Datagram Protocol) (49), a Figura 13 apresenta um modelo de interação do
protocolo. A troca de mensagens é baseada em REpresentation State Transfer (REST),
que é uma forma simples de criar uma interface sobre o HTTP, no qual o CoAP atua
como uma ponte entre o HTTP e mensagens REST (51). A especificação não menciona a
possibilidade de espelhamento do servidor, dificultando a descentralização do serviço, o
que pode ser feito por meio de mensagens REST.
Figura 13 – Modelo de Interação do protocolo CoAP (6)
O CoAP adequa-se bem em situações nas quais muitos clientes precisam acessar o
mesmo recurso simultaneamente, criando problemas de escalabilidade e eficiência, como
perdas de mensagens devido a congestionamento de rede, memória restrita ou atrasos
ne processamento devido a capacidades de computação limitadas dos dispositos. Nesses

casos, CoAP implementa duas capacidades opcionais: proxying e cache. Os proxies são
intermediários que encaminham solicitações e retransmitem respostas de volta em nome do
servidor que hospeda o recurso de destino. O cache permite reutilizar uma mensagem de
resposta prévia para satisfazer um novo pedido. Ambos os mecanismos permitem reduzir
o uso de largura de banda de rede e melhorar os tempos de resposta (52).
Comparado ao MQTT, o protocolo CoAP é mais leve que o MQTT considerando os
requisitos operacionais: não é necessário um broker e há uma menor demanda de memória
e recursos de rede, uma vez que o UDP não requer uma conexão constantemente aberta e
as mensagens possuem tamanho menores. Porém, os requisitos de QoS (Quality of Service)
são menores no CoAP, diminuindo o grau de integridade das mensagens trocadas (6).
Para permitir a troca de mensagens com dispositivos que ficam eventualmente
offline, o CoAP possui Tokens que são usados para criar uma correspondência entre a
solicitação e a resposta. Assim, o uso de CoAP com dispositivos offline só é possível se esses
dispositivos possam eventualmente conectar-se ao servidor por si próprios, inviabilizando
seu uso para dispositivos remotos sem nenhum aceso ao restante da rede.
Apesar da popularidade dos protocolos MQTT e CoAP, o relatório apresentado por
Magg e Vosseler(6) aponta para vários problemas de segurança, bem como implementações
vulneráveis. O fato de não terem sido projetados levando em consideração questões de
segurança, exige que os projetistas que utilizam o protocolo, especialmente com dispositivos
offline, criem uma rígida camada de segurança em seus projetos.
Em 1999, com o objetivo de criar um protocolo aberto de mensagens instantâneas,
como opção aos então protocolos fechados como ICQ ou MSN Messenger, foi criado o
protocolo XMPP (Extensible Messaging and Presence Protocol)1 . Tem como uma de suas
principais características uma arquitetura distribuída, o que permite uma interoperabili-
dade, permitindo ser usado como gateways integrando outros protocolos de comunicação.
Graças a essas características teve seu uso adotado logo após o surgimento e popularização
da Internet das Coisas (53).
Porém com o surgimento de outros protocolos como o CoAP e MQTT, sua utilização
em projetos para IoT começou a reduzir. Principalmente por possuir um mecanismo de
QoS (Quality of Service) menos abrangente que o MQTT (54). A complexidade em lidar
com formato XML em suas mensagens também incentivou os projetistas a deixarem de
utilizar o XMPP em seus projetos de IoT.
1
https://www.hjp.at/doc/rfc/rfc6120.html
2.2 O Problema
O problema principal estudado nesta tese é o da manutenção da autenticidade
e da integridade durante a propagação do fluxo de dados (mensagem entre dispositivos
e a rede) envolvendo dispositivos offline em ICSs IIoT. Conforme se expõe a seguir,
vários autores consideram a autenticidade e a integridade como problemas importantes
na área de segurança de ICSs IIoT (sistemas com dispositivos distribuídos em geral),
mas não abordam a questão de dispositivos offline, sendo este um problema ainda não
adequadamente resolvido na área.
Reinfurt et al.(55) apresentam cinco padrões de IoT para resolver problemas
semelhantes encontrados em diferentes setores que usam a tecnologia de IoT. Os autores
identificaram os padrões coletando e revisando informações de produtos e tecnologias,
usando várias fontes como: páginas de produtos, manuais do usuário, documentação técnica,
documentos padrão, com jornais e artigos de pesquisa. O padrão de sombra do dispositivo
explica como interagir com dispositivos offline. O contexto deste padrão é definido por
dispositivos que, devido ao seu modo de operação ou circunstâncias externas, devem
estar frequentemente offline. O padrão de bloqueio e apagamento remoto é outro padrão
relacionado ao uso de dispositivos offline. Esse padrão deve ser considerado no contexto
de dispositivos que podem ser perdidos ou roubados por estarem em locais públicos ou
remotos. Assim, sempre que um dispositivo que permaneceu offline se conectar à rede,
seja por meio de outro dispositivo ou diretamente a um servidor, o dispositivo deve estar
sujeito a serviços de autenticação e integridade para verificar se, durante o período em
que esteve offline, não houve roubo ou violação de dados de dados. Porém o trabalho
não aborda de forma detalhada a forma com que os padrões lidam com as questões de
segurança.
Em sua pesquisa, Al-Fuqaha et al.(56) apresenta uma visão geral da Internet das
Coisas com ênfase em tecnologias habilitadoras, protocolos e problemas de aplicativos.
embora os autores não abordem diretamente os protocolos usados para dispositivos offline,
apresentam uma visão geral das arquiteturas, protocolos e padrões atuais da indústria
de IoT, abordando diferentes aspectos da implementação dos serviços de autenticação e
integridade usados nos protocolos e arquiteturas apresentadas.
Uma análise aprofundada do uso de protocolos nos vários ambientes de IoT,
destacando os desafios, pontos fortes e fracos desses protocolos de troca de mensagens,
é o foco do trabalho apresentado por Al-Masri et al.(51). No entanto, em relação à
comunicação offline, os autores mencionam apenas uma vulnerabilidade no protocolo
MQTT2 , relacionada com a desabilitação da codificação Unicode, e a possibilidade de
clientes buscarem dados offline no protocolo AMQP3 . Em sua comparação, eles analisam
2
Message Queuing Telemetry Transport
3
Advanced Message Queuing Protocol
os protocolos HTTP, CoAP, MQTT, AMQP, DDS e XMPP em vários aspectos, incluindo
recursos de segurança, mapeando possíveis fontes de vulnerabilidades para práticas de
segurança comuns, incluindo a Tríade CIA (confidentiality, integrity and availability) (37).
Porém, não apresentam soluções de contorno para as vulnerabilidades apontadas.
Nguyen, Laurent e Oualha(57) apresentam uma discussão sobre a aplicabilidade
e limitações dos protocolos de segurança usados em redes de sensores sem fio, que são
potencialmente adequados no contexto da IoT. A análise é baseada no mecanismo de
distribuição de chaves. Embora o trabalho não aborde a comunicação com dispositivos
offline, a análise dos vários métodos de distribuição de chaves permite uma compreensão
das questões de segurança, incluindo autenticidade e integridade, que podem ser aplicadas
em comunicações com dispositivos offline.
Os trabalhos apresentados por Kavianpour et al.(58) e Marino, Moiso e Petracca(59)
discutem profundamente a questão da autenticação mútua, que tem um papel destacado
na questão da segurança nas trocas de informações entre dispositivos IoT, protegendo
o perímetro da rede. Marino, Moiso e Petracca(59) abordam o monitoramento offline e
problemas de comunicação, analisando a evolução das arquiteturas IoT, que deixaram
aplicações estáticas, fechadas e com integração vertical entre os dispositivos. No contexto
do monitoramento de transações que ocorrem nessa integração, os autores abordam a
questão dos dispositivos offline. Apontam a necessidade de que todas as interações que
ocorram durante o monitoramento offline sejam seguramente registradas e armazenadas
para exames futuros, preservando sua autenticidade e integridade, porém não apresentam
propostas de implementação que atendam a essa necessidade.
2.3 Objetivo Geral

O objetivo principal deste trabalho é propor um protocolo de comunicação distri-
buído e descentralizado para redes ICSs IIoT que permitam a troca de mensagens entre a
rede e dispositivos offline provendo serviços de autenticação e integridade das mesmas.
Considerando o contexto da troca de mensagens em uma rede na qual alguns
dispositivos estão sem conectividade, pode-se enxergar dois cenários distintos: um no qual
os dispositivos que estão trocando mensagens estão conectados entre si, porém sem acesso
à internet ou ao restante da rede, e outra situação na qual o dispositivo que no cenário
anterior coletou as mensagens do dispositivo offline posicionou-se em um local onde é
possível conectar-se com o restante da rede.
Para o primeiro cenário, os dispositivos devem ser capazes de: (i) identificar que
o dispositivo ao qual está conectado faz parte da mesma rede, (ii) assinar mensagens
digitalmente de forma autônoma, e (iii) verificar a integridade das mensagens recebidas. Já
para o segundo cenário, os dispositivos devem ser capazes de: (i) propagar as mensagens
coletadas dos dispositivos offline para os outros participantes da mesma rede, (ii) e (iii)
verificar a autenticidade e integridade das mensagens propagadas.
2.3.1 Objetivos Específicos
• Definir e propor uma estrutura de mensagens encadeadas que implemente serviços

de autenticação e integridade.
• Definir e propor um mecanismo de sincronização de mensagens de forma a distribuir

as mensagens para os demais participantes da rede, mesmo aqueles que estejam sem
conectividade.
• Desenvolver um protótipo com o objetivo de validar as funcionalidades da solução

proposta.
• Demonstrar através de simulações de ataques que o mecanismo proposto atende aos

requisitos apresentados.
2.3.2 Requisitos do Mecanismo Proposto

O protocolo proposto deve ser capaz de:
• Rodar em dispositivos com poucos recursos computacionais
• Permitir portabilidade, ou seja, instalação em dispositivos com diferentes arquiteturas
• Ser capaz de comunicar-se com outro dispositivo sem a necessidade de uma entidade
central.
34
3 TRABALHOS RELACIONADOS
Este capítulo tem por objetivo apresentar uma revisão da literatura sobre trabalhos ligados
a troca de mensagens entre a rede e dispositivos offline em uma ICS. Como já citado
no levantamento do problema no Capítulo 2 poucos trabalhos abordam diretamente o
problema da garantia da autenticidade e integridade das mensagens propagadas entre a
rede e dispositivos que estejam permanente ou momentaneamente sem conexão.
3.1 Segurança em ICSs IIoT

Quando dois dispositivos se comunicam e não têm acesso a terceiros para garantir a
autenticidade um do outro, a autenticação mútua é necessária para proteger a rede contra
a adição de dispositivos inválidos ou maliciosos.
Marino, Moiso e Petracca(59) classificam as soluções para autenticação mútua
em duas: criptografia simétrica e assimétrica. Na criptografia simétrica, os pontos finais
compartilham uma chave secreta usada para criptografar o texto simples de uma mensagem
em um texto cifrado. Eles usam a mesma chave para descriptografar o texto cifrado em um
texto simples novamente. Por outro lado, na criptografia assimétrica, cada ponto final usa
um par de chaves: uma pública e uma secreta usada para criptografar e descriptografar
mensagens (37).
A segurança dessas técnicas depende da chave secreta. Assim, a distribuição de
chaves torna-se um desafio. Tarefa ainda mais difícil no contexto de IoT com dispositivos
offline.
Marino, Moiso e Petracca(59) e Kavianpour et al.(58) discutem muitos aspectos da
autenticação para dispositivos IoT. Eles analisam vários esquemas de autenticação, como
IoT baseado em nuvem, baseado em blockchain e autenticação de usuário remoto baseada
em biometria (multifator). Eles levantaram suas vantagens e limitações, mostrando que
mais pesquisas são necessárias para obter um esquema de autenticação robusto.
Na conclusão do seu trabalho, Harit, Ezzati e Elharti(60) apontaram que o ge-
renciamento de chaves é o principal método de proteção para implantar autenticação,
integridade e confiabilidade para as informações em uma rede IoT. Outros autores citam
várias técnicas para garantir a integridade das mensagens trocadas entre dispositivos
IoT: algoritmos criptográficos (61, 62), MACs (Message Authentication Code), assinaturas
digitais e funções hash (63, 64), abordagem por níveis de privilégios (62) e protocolo DTLS
(Datagram Transport Layer Security) (65). Mas a aplicabilidade dessas técnicas continua
sendo um desafio, dado o recurso computacional restrito dos dispositivos IoT.
Capítulo 3. Trabalhos Relacionados 35
3.1.1 Blockchain
Algumas linhas de pesquisa na literatura têm apontado a tecnologia Blockchain
como uma solução viável para tratar as questões de segurança listadas acima. Devido
principalmente às suas características da descentralização, segurança e auditibilidade da
tecnologia (66). Blockchain é um banco de dados distribuído, descentralizado, comparti-
lhado, imutável e auditável (67), que suporta uma plataforma para execução de transações
anônimas e seguras, utilizando uma rede descentralizada de computadores e dispositivos
(68).
Como o próprio nome sugere, blockchain é uma cadeia de blocos, no qual cada um
dos blocos é identificado pelo seu hash 1 e faz referência ao hash do bloco anterior, criando
assim uma sequência encadeada de blocos (70). Uma visão simplificada do blockchain está
apresentada na Figura 14.
Figura 14 – Visão simplificada do blockchain
O encadeamento dos blocos através do código hash é um dos fatores que contribuem
para a imutabilidade do blockchain, pois caso algumas das transações de blocos anteriores
seja alterada, o hash do bloco também será alterado, que por sua vez fará com que todos
os blocos subsequentes tenham seus códigos hash alterados.
A tecnologia blockchain possibilita redes onde as transações P2P podem ser realiza-
das sem a necessidade de uma entidade intermediária e centralizadora para estabelecer a
confiança (67), que no caso é garantida pelo uso de técnicas de criptografia, sua principal
característica.
A cadeia de blocos é distribuída para todos os participantes da rede, e para garantir
que todas as cópias sejam idênticas, é necessário um mecanismo automático no qual os nós
concordem com as transações e a ordem em que são registrados na cadeia. Caso contrário,
as cópias individuais do blockchain vão divergir afetando a integridade da rede. A esse
mecanismo é dado o nome de consenso (67).
Desde o lançamento da tecnologia blockchain em 2008, pesquisadores têm proposto
seu uso em redes IoT devido às suas características: ambiente verdadeiramente descentra-
lizado, confiável e seguro. A tecnologia blockchain utiliza os mecanismos dos protocolos
1
Resultado de uma função hash, que tem como objetivo extrair uma cadeia de caracteres de tamanho
fixo de uma mensagem com tamanho variável. Utilizado como um código único da mensagem (69).
gossip, que foram projetados para redes P2P em sistemas distribuídos e imitam a propaga-
ção de doenças epidêmicas (71). Embora os protocolos gossip tenham sido estudados por
mais de quarenta anos (72), eles ganharam popularidade com seu uso na tecnologia de
blockchain, devido à sua resiliência.
No entanto, o uso da tecnologia blockchain em dispositivos restritos enfrenta alguns
obstáculos: o banco de dados distribuído requer recursos extensos dos nós e também requer
um tempo substancial para validar e sincronizar as transações (73), o aumento do uso da
rede blockchain implica no aumento dificuldade das funções de criptografia, o que resulta
em tempos de transação elevados e consumo de energia elétrica muito alto (68). A troca
de dados em aplicativos de blockchain tradicionais é realizada através de transações de
token (criptomoedas) e a maioria dos sistemas de blockchain têm taxas de transação que
são usadas para gerar recompensas de bloco como incentivos, para manter a rede viva, de
acordo com Florea(68) esta é a principal desvantagem de uso de blockchain em redes IoT.
Como forma de contornar os problemas na adoção das implementações de blockchain
existentes por redes de IoT, mas mantendo seus principais conceitos, em 2018 foi criada a
IOTA (74), um novo tipo de DLT (Distributed Ledger Technology) com foco em redes de
IoT (75). Ao contrário de outras implementações como Bitcoin e Ethereum que utiliza os
conceitos tradicionais do blockchain, IOTA usa uma tecnologia baseada em grafos chamada
“Tangle” para anexar e propagar suas transações (76). Ao invés de encadear as transações
de forma linear, na rede IOTA uma transação apenas se referencia a outras duas transações
já existentes, validando-as. Dessa forma, cada nó não necessita validar todas as transações
do banco de dados, como acontece no blockchain tradicional.
Mesmo sendo uma tecnologia desenvolvida com foco em dispositivos IoT, Zorzo
et al.(77), Wang et al.(78) e Florea(68) destacam que a IOTA não deve ser usado em
dispositivos com restrições de recursos devido ao seu pesado algoritmo de validação das
transações.
3.2 Vishwakarma e Das

Tendo como base o problema de segurança na comunicação entre dispositivos IoT,
os autores (7) citam que as soluções apresentadas em geral são centralizadas. Então propõe
a utilização da tecnologia blockchain devido a sua escalabilidade, arquitetura distribuída,
banco de dados uniforme e a prova de adulteração e com o potencial de lidar com a
segurança da informação nas redes IoT.
Na arquitetura proposta, existem três tipos de dispositivos: Servidor Blockchain
– Blockchain Server (BS), Cluster Principal – Head Cluster (CH) Membro do Cluster –
Cluster Member (CM). O BS tem como principal objetivo gerenciar registro de dados de
autenticação dos participantes da rede, que é compartilhado com membros do cluster.
Todos os CHs têm uma cópia idêntica do blockchain. Os CHs devem ser dispositivos
com alto poder de processamento, uma vez que será o controlador da comunicação dos
participantes do cluster, os CMs. Os CMs são dispositivos inteligentes, como lâmpadas
inteligentes, alto-falantes, equipamentos médicos especializados, ar-condicionado e muitos
outros. A Figura 15 apresenta um esquema da arquitetura proposta
Figura 15 – Arquitetura proposta por Vishwakarma e Das(7)
O processo é iniciado com a criação dos CHs, que por sua vez são responsáveis
por autenticar os dispositivos (CMs) através da geração de uma identificação e um par
de chaves. Ao se associar a um cluster, cada dispositivo recebe um Batch ID, que será
utilizado na comunicação. A identificação dos dispositivos é registrada no blockchain da
Ethereum, através de um Smart Contract. A cada comunicação entre os CMs, cada CM
faz uma solicitação ao CH vinculado que atesta sua autenticidade na rede blockchain
entregando uma chave secreta síncrona de uso único para que seja realizada a comunicação.
A solução apresentada mostrou-se adequada nas questões de autenticação e inte-
gridade, porém para utilização com dispositivos offline é necessário que haja dispositivos
do tipo CHs móveis que possibilitem a comunicação eventual do dispositivo offline com o
restante da rede.
3.3 Ali et al.

Nos trabalhos apresentados (79, 80) os autores levantam os problemas decorrente do
aumento exponencial dos dispositivos IoT. A partir desse contexto, os protocolos existentes
começaram a ter problemas em lidar com o grande número de dispositivos e principalmente
com a quantidade de dados gerados. Os autores focaram em duas consequências desse
aumento: (i) a grande dependência de soluções em nuvem que implica em um alto custo de
transferência desses dados e o desperdício de bandas de comunicação, somado ao fato de
que nem todas as aplicações suportadas por dispositivos IoT podem tolerar a latência que
é introduzida na troca de dados com os servidores centralizados da nuvem, e (ii) a falta
de padronização dos dispositivos IoT, resultando em uma grande variedade de protocolos,
o que dificulta a conectividade entre os dispositivos.
Propuseram então, a utilização de comunicação sem fio e um framework computa-
cional que suporta escalabilidade com o aumento do número de dispositivos. A solução é
composta por uma WMN (Wireless Mesh Network) na qual os Access Points e Roteadores
são utilizados como Gateways que facilitam a integração de dispositivos com diferentes
protocolos.
Para a propagação de dados, os autores utilizaram um protocolo assíncrono baseado
no sistema de publicação/subscrição. Porém para não utilizar protocolos centralizados, como
o MQTT e AMQP, usaram o DHT (Distributed Hash Table) (81) um modelo descentralizado
que mescla a comunicação P2P (Peer-to-peer) com o sistema publicação/subscrição.
O fato da solução apresentada ser descentralizada e permitir uma comunicação
assíncrona poderia pressupor que permite a inclusão de dispositivos offline na sua rede.
Porém, os autores não fazem uma menção direta a esse contexto. Além disso, as questões de
autenticação, integridade e confidencialidade na troca de mensagens não foram abordadas
no trabalho.
3.4 Ferretti, Marchetti e Colajanni

Os autores (8) atuam no desafio de projetar redes IoT seguras, escalonáveis e
resilientes devido aos dispositivos com recursos limitados e nenhuma garantia de que a
conectividade da rede seja confiável.
Os projetos baseados em serviços providos por plataformas em nuvem tem como
principal desvantagem a dependência da conectividade. Em muitos cenários, essa desvan-
tagem não é aceitável. Então, o paradigma da Fog Computing visa resolver problemas
relacionados a arquiteturas assistidas por nuvem, movendo alguns recursos operacionais
da nuvem para a borda da rede (Edge Computing).
Na Figura 16 os autores apresentam uma arquitetura de referência de Fog Compu-
ting, na qual as coisas representam dispositivos IoT com recursos limitados, serviços na
nuvem são serviços acessíveis pela Internet disponíveis a usuários e coisas previamente
autorizadas e Fog Nodes são componentes que podem ser acessados pelas coisas sem
necessidade de acesso à Internet. Os NFNs (Near edge Fog Nodes) são Fog Nodes que
provêm serviços com o objetivo de aumentar a comunicação entre os dispositivos utilizando
o sistema publicação/subscrição (50).
A solução proposta pelos autores combina a flexibilidade e a segurança das implan-
Figura 16 – Arquitetura de Referência de Fog Computing (8)
tações de IoT baseadas em nuvem com a escalabilidade e resiliência da Fog Computing.

No protocolo proposto, as coisas aproveitam os recursos computacionais de nós de névoa
semi-honestos para trocar mensagens criptografadas.
Enquanto os nós de névoa garantem escalabilidade e resiliência do sistema, o
protocolo garante a confidencialidade de ponta a ponta das informações trocadas entre os
dispositivos IoT. O protocolo é baseado em um esquema de recriptografia simétrica de
proxy original que é adequado para a capacidade computacional limitada de muitas coisas
conectadas de baixo consumo de energia.
Apesar de apresentar soluções para dispositivos que não possuam uma comunicação
constante com serviços de nuvem, o trabalho proposto implica na utilização de serviços
centralizados (os nós NFNs), que além de serem potenciais alvos de ataques, inserem uma
maior complexidade na borda da rede.
3.5 Kim et al.

A partir do contexto no qual diversos serviços utilizados por redes IoT são disponi-
bilizados na nuvem e de forma centralizada, os autores levantam o problema decorrente
da indisponibilidade desses serviços, principalmente quando se trata de serviços críticos
como a autenticação dos dispositivos IoT na rede.
Os autores propõem uma abordagem que utiliza uma técnica chamada migração
segura, que permite que os dispositivos IoT migrem para outras entidades de autorização
locais servidas em computadores de borda confiáveis quando sua entidade de autorização
ficar indisponível. A proposta é baseada em uma técnica desenvolvida pelos autores
chamada SST (Secure Swarm Toolkit) (82).
Em sua proposta, a migração segura tem como objetivo restaurar a disponibilidade
de dispositivos IoT durante falhas em alguns serviços de autenticação, explorando as
características arquitetônicas do SST. O objetivo é alcançado fazendo com que os serviços
de autenticação, ou autenticadores, espalhados na borda assumam as tarefas de autorização
de outros autenticadores quando o último grupo ficar indisponível devido a um ataque.

Antes que ocorra qualquer falha em algum dos serviços, são realizadas cópias de segurança
das informações e credenciais necessárias para os demais autenticadores confiáveis.
A proposta apresenta solução para autenticação no caso de perda de conexão com
serviços críticos descentralizando os serviços em dispositivos na borda da rede. Apesar de ter
apresentado sucesso nos seus experimentos, o trabalho apresentado não trata diretamente
da propagação das mensagens entre dispositivos offline e o restante da rede. E da mesma
forma que as demais soluções baseadas em Edge Computing, é necessário um aumento da
complexidade e da distribuição de nós responsáveis por serviços críticos, que podem se
tornar alvos dos ataques.
3.6 Amanlou e Bakar

Usando como foco a questão das vulnerabilidades do protocolo MQTT, os autores
apresentaram uma proposta de um mecanismo de segurança a ser implementado no
protocolo MQTT (83). Trata-se a implementação da autenticação TLS (Transport Layer
Security), um mecanismo que permite uma comunicação segura ponto-a-ponto que utiliza
algoritmos criptográficos para a autenticação e proteção dos dados. É subdividido em dois
protocolos, o TLS Handshake Protocol no qual os dispositivos executam a autenticação
mútua e o TLS Record Protocol que garante a segurança na troca das informações realizadas
após a autenticação.
Apesar da proposta apresentada oferecer uma solução viável para a questão da
autenticação e confidencialidade na troca de informações. Não há referências à utilização
no contexto de dispositivos offline, consequentemente não é tratada a integridade das
mensagens durante a propagação entre os dispositivos offline e a rede.
3.7 Rahman et al.

Usando como ponto de partida o mesmo problema citado no trabalho anterior, Rah-
man et al.(84) também apresentam uma proposta com o objetivo de implementar serviços
de segurança no protocolo MQTT. O mecanismo utiliza uma abordagem multicamada que
deve proteger a comunicação entre o dispositivo e os serviços hospedados em uma nuvem.
Porém, o trabalho tem como principal foco reduzir a vulnerabilidades de segurança,
utilizando algoritmos leves de criptografia, mais adequados à dispositivos com poucos
recursos computacionais. Dessa forma, também não aborda a questão da integridade
durante a propagação de mensagens entre a rede e dispostivos offline.
3.8 Bruno e Bolettieri

Em seu trabalho, Bruno e Bolettieri(52) utilizam o CoAP como base de uma
proposta de solução para comunicação entre dispositivos IoT. Abordam que apesar da
popularidade do protocolo CoAP, algumas de suas desvantagens podem inviabilizar sua
utilização em algumas implementações dependendo de seus requisitos. No CoAP a distinção
entre cliente e servidor é muito vaga, uma vez que os seus dispositivos possuem papeis duplos.
Dessa forma, em situações nas quais seja necessário um acesso massivo a um determinado
recurso, o dispositivo não suporte a carga, ocasionando perda de informação, demora na
resposta ou até mesmo inoperabilidade do recurso. Para minimizar esses problemas, o
CoAP implementa dois recursos adicionais: proxies, que atuam como intermediários que
controlam o tráfego; e Cache que utiliza a resposta anterior para atender a uma nova
requisição.
Porém, esses recursos adicionais nem sempre podem atender os requisitos nos quais
há uma grande demanda por dados dos sensores e seus valores são alterados frequentemente.
A partir desse contexto, os autores apresentam uma proposta de um proxy mais sofisticado
que também pode atuar como um broker para aplicações heterogêneas, regulando o acesso
aos recursos de IoT para evitar o uso injusto da largura de banda da rede.
Uma característica chave de proposta é medir a confiabilidade da transmissão de
mensagens de atualização de estado que são recebidas pelos servidores que hospedam
os recursos observados. Se essa confiabilidade for menor do que o desejado, o Broker do
aplicativo ajustará a frequência de solicitação de atualizações a fim de atingir uma melhor
utilização de banda.
O CoAP permite uma troca de mensagens assíncrona, que em uma primeira análise
permitiria a utilização com dispositivos offline. Porém algumas características de sua
arquitetura podem comprometer sua escolha nesse contexto como já abordado no seção
2.1.2. Outro ponto de atenção é o fato do CoAP utilizar UDP (User Datagram Protocol)
no qual as mensagens podem ser perdidas ou chegar fora de ordem. A implementação do
CoAP contorna essa questão utilizando um mecanismo simples para garantir a entrega da
mensagem. Porém, não garante a ordem, impactando assim, a integridade na troca das
informações.
Outro ponto não abordado no trabalho são as vulnerabilidades de segurança do
protocolo CoAP, que exige a implementação de uma camada extra de segurança no sentido
de implementar os serviços de autenticação, integridade e confidencialidade.
3.9 Yang et al.

Yang et al.(9) apresentaram no seu trabalho uma proposta de um mecanismo de
autenticação mútua para dispositivos de IIot, que leve em conta a restrição de recursos
desses dispositivos. O projeto consiste-se em definir um protocolo AKA (Authenticated Key
Agreement) nos sistemas IIoT. Consideram um modelo de sistema para IIoT mostrado na
Figura 17 no qual são considerados três tipos de participantes gerais: usuários, dispositivos
IIoT e um gateway. Um usuário pode acessar o sistema através de dispositivos móveis,
ou sistemas SCADA por meio de senha ou biometria. Aqui, o gateway é responsável pela
autenticação entre um usuário e um dispositivo IIoT. Para conseguir isso, é necessário
um gerenciamento de chaves de forma que os usuários e os dispositivos IIoT tenham
chaves de autenticação pré-compartilhadas com o gateway. Portanto, o protocolo AKA
pode ser executado de forma eficiente entre essas partes para gerar uma chave de sessão
compartilhada.
Figura 17 – Modelo do Systema IIoT (9)
Apesar dos autores não citarem explicitamente o seu uso em dispositivos offline,
devido ao gerenciamento de chaves pré-compartilhadas a autenticação mútua é atingida
independente dos dispositivos estarem com conexão estabelecida com o restante da rede.
Porém, os autores não citam se o trabalho permite a propagação de forma segura das
mensagens geradas por dispositivos offline.
3.10 Oscar Novo

O autor aborda a incapacidade dos dispositivos de IoT armazenarem as informações
necessárias para atuarem como um nó de uma rede blockchain como uma das motivações
do seu trabalho. Uma vez ser necessário que cada nó possua uma cópia completa das
transações realizadas na rede.
Assim, o autor propõe uma solução que integre os dispositivos em um blockchain, e
consequentemente aproveitar das suas características intrínsecas de decentralização e a
implementação dos serviços de autenticação e integridade. Para tal, a proposta inclui um
nó chamado management hub que interage com o blockchain em nome dos dispositivos
IoT. As regras de acesso ao sistema, bem como todas as operações e comunicações entre
os dispositivos são controladas por um Smart Contract. Administradores do sistema,
chamados de managers podem interagir com o Smart Contract a fim de definir políticas
do sistema. A Figura 18 apresenta um esquema simplificado da solução proposta.
Figura 18 – Esquema da Solução Proposta por Novo(10)
Com relação às questões de segurança, o autor utilizou o modelo STRIDE (85)

para identificar vulnerabilidades da sua proposta. O modelo STRIDE classifica as ameaças
em seis categorias, que formam seu acrônimo em inglês: Spoofing (falsificação), Tampering
(adulteração), Repudiation (repúdio), Information disclosure (divulgação de informações),
Denial of service (negação de serviço) e Elevation of privileges (elevação de privilégios), a
Tabela 1 apresenta a vulnerabilidade de cada elemento da solução proposta.
Tabela 1 – Vulnerabilidades à ameaças (10)
S T R I D E
Management Hub X X X X X
Administrador X
Dispositivo IoT X
Ao analisar os resultados apresentados na Tabela 1, destaca-se que devido ao

fato dos dispositivos de IoT não fazerem parte da rede blockchain, devem confiar nos
management hubs. Que por sua vez estão vulneráveis a diversos tipos de ataque: falsificação,
ao se passar por um equipamento autêntico; adulteração, modificando as informações
trocadas entre o dispositivo e a rede; repúdio, alegação de não ter executado determinada
ação; DoS, interrompendo o serviço; e divulgando informações dos dispositivos a pessoas
ou dispositivos não autorizados. Da mesma forma, o management hub não tem como
verificar a identidade dos dispositivos ou do administrador.
Para contornar essa situação, o autor propõe a utilização de certificados assinados
por uma entidade certificadora, porém com o aumento do número de dispositivos, bem
como a necessidade de substituição e realocação e revogação dos acessos, a gestão e
distribuição desses certificados torna-se complexo.
3.11 Considerações sobre os Trabalhos Relacionados

A Tabela 2 apresenta um resumo das principais características dos Trabalhos
Relacionados de acordo com sua aderência aos assuntos destacados no cabeçalho.
Tabela 2 – Trabalhos Relacionados – Tabela Comparativa
Arquitetura Segurança Offline
Trabalho
Fog /
Mesh P2P Outra Autenticação Integridade Parcial Total
Edge
Vishwakarma e Das(7)
Ali et al.(79, 80)
Ferretti et al.(8)
Kim et al.(82)
Amanlou e Bakar(83)
Rahman et al.(84)
Bruno e Bolettieri(52)
Yang et al.(9)
Novo(10)
No grupo arquitetura, a tabela apenas indica qual tipo de arquitetura os respectivos

autores utilizaram em seus trabalhos. No grupo segurança, o símbolo indica que o trabalho
não trata, ou não aborda a questão identificada pela respectiva coluna (Autenticação e
Integridade); o símbolo indica que o trabalho trata da questão, porém com ressalvas
e o símbolo indica que a questão foi devidamente endereçada pelo trabalho. No grupo
Offline, o símbolo indica que não é possível a utilização de dispositivos offline na solução
proposta; o símbolo indica que é possível a utilização dos dispositivos, porém com
restrições e o símbolo indica a possibilidade de utilizar dispositivos offline. Convém
ressaltar que apesar dos autores não citarem explicitamente a questão da propagação de
mensagens geradas por dispositivos offline, foi considerada a utilização das tecnologias
para inferir se a solução é ou não adequada para esses tipos de dispositivos.
45
4 PROPOSTA
Este capítulo apresenta o protocolo de comunicação descentralizado com banco de dados

distribuído proposto para redes IIoT, que permite a troca de mensagens entre rede e
dispositivos offline com serviços de autenticidade e integridade.
4.1 Fundamentos
A fim de tratar o problema da troca de dados entre a rede e dispositivos offline, o
protocolo proposto está baseado nos seguintes princípios:
• A rede é formada por dispositivos IoT, IIoT ou participantes de uma ICS.
• Toda a troca de mensagens do protocolo é realizada entre equipamentos (M2M -

Machine to Machine).
• O acesso de alguns dispositivos à rede é inexistente ou intermitente. Apesar disso,

dois ou mais equipamentos offline podem comunicar-se entre si, por conexão direta
ou por participarem de uma mesma rede.
O trabalho considera os seguintes pressupostos:
• As chaves criptográficas e convites de afiliação dos dispositivos serão gerados e

instalados localmente por administradores honestos.
• Os serviços de autenticação e integridade providos pelo protocolo serão testados

apenas contra ataques conhecidos como man-in-the-middle. Durante o ataque man-in-
the-middle, a comunicação é interceptada pelo atacante e retransmitida de uma forma
discricionária. Desta forma, pretende-se emular ataques de Fabricação e Modificação.
• Durante os testes contra ataques será considerado que o atacante não possui acesso
às chaves secretas dos dispositivos. A exceção será para os casos nos quais o atacante
é um participante desonesto da rede, porém, nesse caso será considerado que somente
terá acesso às chaves secretas do seu dispositivo.
O protocolo proposto tem como base o protocolo SSB (Secure Scuttlebutt), um

protocolo desenvolvido para ser utilizado em aplicações decentralizadas, que pode funcionar
offline e não precisa de um administrador. É um protocolo flexível capaz de suportar
diversos tipos de aplicação (86). É um protocolo P2P (Peer to Peer) no qual cada nó possuí
um registro imutável no qual só é possível a inserção e consulta de dados (87, 88). Foi
Capítulo 4. Proposta 46
desenhado originalmente para ser um protocolo de mensagens de rede social que funcione
mesmo com alguns usuários estando offline.
O SSB apresenta o conceito de Pub, que é um participante do SSB acessível ao
público. Um Pub tem um objetivo social e outro técnico: serve como um ponto de encontro
para novos usuários encontrarem outras pessoas e para usuários já existentes darem as boas
vindas aos usuários recém-chegados; possui um endereço IP estável e permite conexões
TCP, facilitando assim o acesso. Um Pub também emite os convites que possibilitam
que os novos usuários se conectem à rede. Um convite contém o endereço do Pub, a
porta e a chave pública. Também contém uma chave privada que o usuário pode usar
para fazer com que o Pub os siga de volta. Somente após a resposta do Pub, o novo
usuário será considerado afiliado ao Pub e terá acesso às mensagens postadas por outros
membros do Pub e conseguirá enviar suas próprias mensagens. As mensagens emitidas
por qualquer um dos participantes da rede são armazenadas em um Feed, uma lista de
mensagens encadeadas pelo hash de cada mensagem, um mecanismo semelhante ao usado
no blockchain.
Embora em um primeiro momento, o mecanismo proposto pelo SSB parece se
adequar perfeitamente ao contexto de redes IoT com dispositivos offline, o modelo aberto
sofre de algumas limitações impostas pelo contexto de uma rede IoT, como entre outras:
ele implementa a replicação total, ou seja, após o armazenamento de novas mensagens em
um nó, todos os outros nós devem conter os mesmos logs (e as mesmas mensagens). Além
disso, fornece persistência total, ou seja, uma vez que uma mensagem é gerada por um
dispositivo, ela é mantida para sempre em todos os nós da rede (88).
Outro ponto importante que pode ser considerado uma desvantagem na utilização
do protocolo SSB em um ICS é seu acesso aberto. Por ter sido desenvolvido visando um
aplicativo de mensagens, qualquer um que possua o endereço IP do Pub pode solicitar a
afiliação ao protocolo. Mesmo no caso em que o projetista altere os parâmetros padronizados
do protocolo como chave de acesso e porta, criando assim uma rede apartada, uma vez
que um atacante descubra o IP de algum Pub, é possível participar da rede.
4.2 Um cenário ilustrativo

Para auxiliar a descrição do trabalho proposto, foi pensado um cenário ilustrativo.
Sempre que for necessário apresentar algum exemplo durante a explicação do protocolo
proposto, este cenário será referido. Como será detalhado a seguir, o protocolo proposto,
semelhante ao protocolo SSB, utiliza os conceitos de Pubs, feeds e convites com algumas
alterações para adequar ao contexto de recursos escassos dos dispositivos IIoT. O cenário
está apresentado na Figura 19 no qual, uma rede ICS possui três Pubs e quatro dispositivos.
A Tabela 3 relaciona cada dispositivo aos Pubs aos quais são afiliados. Dessa
Figura 19 – Visão Geral do cenário ilustrativo
forma, cada Pub possui tantos feeds (entidade que armazena as mensagens emitidas)
quanto dispositivos afiliados. E devido ao fato do protocolo implementar um banco de
dados distribuído, cada afiliado a um Pub terá uma cópia dos feeds correspondentes. Essa
configuração está representada na Figura 19, na qual os feeds possuem a mesma cor dos
Pubs.
Tabela 3 – Tabela de Afiliação
Dispositivos Pub 1 Pub 2 Pub 3

Pub 1
Pub 2
Pub 3
Dispositivo 1
Dispositivo 2
Dispositivo 3
Dispositivo 4
Total de Feeds por Pub 5 6 3
Um detalhe dos feeds de mensagens emitidas por Pubs e dispositivos afiliados ao

Pub 3 é apresentado na Figura 20. No exemplo, cada Pub ou dispositivo afiliado ao Pub 3
possuí três feeds, cada um armazena as mensagens emitidas por cada um de seus afiliados.
Apenas para facilitar o entendimento ao longo do texto, os feeds serão referenciados pela
codificação <Pub>-<Emissor>.
4.3 O Protocolo Proposto

No protocolo proposto existem dois tipos de dispositivos: o Pub e o dispositivo
comum. Ambos possuem um par de chaves (chave pública e chave secreta) e podem gerar
mensagens e comunicar-se entre si, porém o Pub tem uma característica adicional: de
Figura 20 – Visão detalhada dos feeds dos dispositivos afiliados ao Pub 3
forma semelhante ao protocolo SSB, atua como um gerenciador de identidades para outros
dispositivos. Para participar da rede todos os dispositivos devem ser afiliados a pelo menos
um Pub.
O processo de afiliação é iniciado pela geração de um convite pelo Pub e instalado
localmente no dispositivo pelo administrador. De posse do convite, o dispositivo acessa
o Pub e através um processo onde o convite é validado, o Pub gera um ticket e o envia
para o dispositivo, que é o instrumento de associação. O ticket consiste-se na assinatura,
pelo Pub, da chave pública do dispositivo afiliado. Uma vez de posse do ticket, qualquer
dispositivo da rede poderá validá-lo. Para isso basta verificar se o ticket apresentado pelo
dispositivo corresponde à assinatura da sua chave pública realizada pelo Pub. As figuras
21a e 21b apresentam, respectivamente, os processos de criação e validação do ticket. A
proposta da utilização do ticket tem como objetivo evitar a complexidade dos processos
tradicionais do gerenciamento de criação e distribuição de chaves (21).
(a) Criação
(b) Validação
Figura 21 – Criação e Validação do Ticket
Na sequência, serão descritos os processos de criação do Pub e dispositivo comum.

O diagrama de sequência apresentado na Figura 22 apresenta a criação de um Pub. Os
processos de criação são executados localmente pelo administrador da rede.
Todo dispositivo necessita de um par de chaves. A chave pública será sua identidade
dentro da rede e a chave secreta será utilizada para assinaturas e cifragem de mensagens
privadas. Dessa forma a primeira etapa na criação de qualquer dispositivo é a geração

das chaves pública e secreta. Como todos os dispositivos precisam estar afiliados a um
Pub, o próximo passo é afiliar o Pub recém-criado a ele próprio, através da criação de
um ticket. No caso do exemplo, foi gerado o ticket P01-P01, representando o Pub (P01)
e o dispositivo afiliado (P01). O ticket então é armazenado no banco de dados (tabela
Pubs Afiliados) com o status ADMITIDO. Por se tratar de uma auto-afiliação, não foi
necessário a utilização de convite. O feed que armazenará as mensagens geradas pelo Pub
P01 para destinatários vinculados ao próprio Pub P01 também é criado neste momento,
como está demonstrado na Figura.
Figura 22 – Criação do Pub
Para que outros dispositivos sejam afiliados ao Pub recém-criado, é necessário criar
convites a serem enviados para os futuros afiliados. O convite consiste-se em um código
gerado randomicamente e a chave pública do Pub. O diagrama de sequência desta operação
está descrita na Figura 23. Tanto o processo de criação como de coleta dos convites são
realizados localmente pelo administrador da rede.
Para cada convite criado pelo Pub, é gerado um arquivo para ser enviado posterior-
mente para o dispositivo. Todos os códigos de convites criados são armazenados no banco
de dados do Pub com o status CRIADO. Nesta tabela também há um campo para registro
do dispositivo que terá sua afiliação autorizada após o envio do convite, dessa forma o
Pub poderá gerenciar o processo de distribuição e utilização de convites, garantindo que
sejam utilizados uma única vez.
A criação de um dispositivo comum é semelhante à criação do Pub, já vista
Figura 23 – Criação de Convites
anteriormente: o par de chaves é gerado, as tabelas de Pubs Afiliados e feeds são criadas,
porém sem registros uma vez que o dispositivo não está afiliado a nenhum Pub no momento
de sua criação. O diagrama de sequência dessa etapa está apresentado na Figura 24.
Figura 24 – Criação de Dispositivo Comum
O próximo passo é executar a afiliação do dispositivo recém-criado a um Pub. O

processo é iniciado com a instalação no dispositivo de um dos convites gerados previamente
pelo Pub. Na Figura 25 há um exemplo de instalação de um convite no dispositivo D01.
No exemplo, o administrador instala no dispositivo o convite P01 - Convite 3, apenas para
evidenciar de que é possível utilizar qualquer convite criado pelo Pub, independente da
ordem em que foi gerado.
Figura 25 – Instalação dos Convites
Ao ser instalado, o dispositivo armazena os dados do convite recebido na tabela de

Pubs Afiliados com o status RECEBIDO.
Uma vez o convite instalado no dispositivo, o próximo passo é realizar uma conexão
com o Pub que emitiu o convite e solicitar a emissão do ticket. Esse processo deve ocorrer
através da rede permitindo assim que o dispositivo receba o seu ticket de forma remota.
O Pub executa uma série de verificações antes de gerar e entregar o ticket ao dispositivo
solicitante. Nos casos em que os dispositivos fiquem permanentemente sem acesso ao
restante da rede, é possível criar um Pub “móvel” para que possa ser levado ao dispositivo
remoto para que se conectem localmente e seja possível enviar o ticket. Esse procedimento
pode ser realizado a qualquer tempo, mesmo durante o funcionamento pleno da rede. Dessa
forma, novos dispositivos, mesmo que estejam sem conexão com o restante da rede, podem
seus tickets de afiliação através da conexão com Pubs “móveis”.
O processo está descrito por diagramas de sequência apresentadas nas Figuras 26 e
28 que serão detalhadas a seguir.
O processo é iniciado no lado do dispositivo com a preparação do comando
GET_TICKET. O convite enviado na mensagem deve ser cifrado usando a chave se-
creta do dispositivo e a chave pública do Pub para garantir que o código de convite não
seja divulgado na rede. A cifragem é realizada sobre o convite concatenado com um campo
nonce 1 . Caso um atacante intercepte e interrompa essa mensagem, pode solicitar com
sucesso, um ticket ao Pub, caso o conteúdo do convite esteja exposto. A cifragem realizada
pelo dispositivo e a decifragem realizada pelo Pub estão apresentados respectivamente nas
Figuras 27a e 27b.
Antes de enviar a mensagem ao Pub, o dispositivo ainda precisa assinar a mensagem
para que o Pub possa verificar a autenticidade da mesma, ou seja, que o dispositivo que
1
Do inglês (number used once), um valor gerado de forma aleatória usado para garantir que a cada vez
que uma mesma mensagem seja transmitida durante uma comunicação, ela será cifrada ou assinada de
uma forma completamente diferente (37). Tem como uma das funções minimizar o risco de ataques de
repetição.
Figura 26 – Comunicação com o Pub
está solicitando o ticket seja realmente quem diz ser. A assinatura da mensagem e a
cifragem do convite são instrumentos utilizados para mitigar o risco de que dispositivos
não autorizados recebam um ticket válido por um Pub da rede.
Assim que o Pub recebe a mensagem enviada pelo dispositivo, são verificadas
a assinatura e a cifragem. Caso haja algum problema nesses quesitos, é retornada uma
mensagem para o dispositivo informando a causa da recusa. O processo a partir da recepção
da mensagem pelo Pub está apresentado no diagrama de sequência, Figura 28.
Caso o dispositivo tenha enviado o convite de forma pública, é retornada uma
mensagem de recusa ao dispositivo e o convite recebido é descartado. O descarte é
materializado com uma alteração no status do convite no banco de dados evitando assim
que seja utilizado novamente.
Uma vez verificado o comando, o próximo passo é verificar a existência do convite
e o status do convite no banco de dados do Pub. Para que possa ser gerado um ticket a
partir do convite recebido, o convite deve estar registrado com o status CRIADO. Em
caso afirmativo, o ticket é gerado e um comando POST_TICKET é preparado para ser
enviado ao dispositivo. Ao receber o comando, o dispositivo valida o ticket gerado. Tendo
(a) Cifragem (b) Decifragem
Figura 27 – Cifragem e Decifragem do Convite
sido validado pelo dispositivo, é enviado um comando ao Pub confirmando o recebimento

e a validação. Neste momento os bancos de dados do dispositivo e do Pub são atualizados.
Caso o convite recebido não tenha sido encontrado no banco de dados do Pub ou
não esteja com o status CRIADO, é enviado uma mensagem ao dispositivo com o código
de erro correspondente. O processo, neste caso, termina com a atualização do banco de
dados do dispositivo.
Uma vez que os Pubs e dispositivos estão criados, todas as afiliações realizadas,
os Pubs e dispositivos podem gerar suas mensagens que serão armazenadas nos feeds,
independente do dispositivo estar conectado com a rede ou com outro dispositivo. Cada
mensagem deve ter um único destinatário. É necessário que o emissor saiba previamente a
chave pública do destinatário e a qual(is) Pub(s) é afiliado.
Para exemplificar, consideremos o exemplo descrito na Figura 19. Supondo que
seja necessário enviar uma mensagem do dispositivo 2 para o dispositivo 4. Neste caso,
como o único Pub em comum é o Pub 2, a mensagem deve ser armazenada no feed relativo
ao Pub 2, feed P02-D02 (Figura 29).
A Figura 30 apresenta a estrutura detalhada de um feed, que é identificado por
um cabeçalho que possuí: (i) A chave pública do dispositivo emissor, (ii) a chave pública
do Pub e (iii) o ticket que valida a associação do dispositivo ao Pub. Dessa forma, cada
dispositivo possuirá um feed para cada Pub associado no qual poderá registrar suas
mensagens.
O objetivo de utilizar um feed para cada par emissor x Pub é minimizar o problema
da persistência total, como no protocolo SSB, uma vez que somente serão compartilhados
feeds relativos a Pubs em comum.
No feed as mensagens geradas pelo dispositivo emissor são armazenadas no de forma
Figura 28 – Geração do Ticket e envio ao dispositivo
encadeada por funções hash, utilizando um mecanismo similar ao usado na tecnologia

blockchain. Cada mensagem é encapsulada em um bloco com a seguinte estrutura: (i) o
hash do bloco de mensagens anterior (que é nulo na primeira mensagem do feed); (ii)
o cabeçalho da mensagem, com o número sequencial da mensagem, a chave pública do
destinatário, o nonce e um campo que informa se a mensagem é privada ou não; (iii) o
Figura 29 – Criação de mensagem e armazenamento no feed
Figura 30 – Estrutura do feed
conteúdo da mensagem e; (iv) a assinatura realizada com a chave secreta do emissor. O

bloco é finalizado com o código hash do seu conteúdo.
Tanto no blockchain como no protocolo SSB, a utilização de timestamp é uma
garantia adicional da integridade das mensagens, bem como seu sequenciamento, porém
no protocolo proposto esse recurso não será utilizado devido a dois fatores: (i) dispositivos
que não estejam conectados à Internet podem ter seus relógios fora de sincronia e (ii) nem
todos os dispositivos possuem relógios nas suas configurações. Nas situações em que for
necessário o registro do tempo, isso deve ser feito no corpo da mensagem.
Para enviar uma mensagem privada, o emissor utiliza criptografia assimétrica
para cifrar a mensagem e garantir que apenas o destinatário possa decifrá-la. O corpo
da mensagem é cifrado utilizando a chave pública do destinatário, a mensagem cifrada
é colocada no campo message e o campo Private é definido como true. Ao receber a
mensagem, basta o destinatário usar sua chave secreta para decifrar a mensagem. O
processo está exemplificado na Figura 31.
A criação do bloco de mensagem que será adicionado ao feed está representado no
na Figura 32. Inicialmente o emissor assina com sua chave secreta a sequência dos campos
apresentados na Figura 32a. A seguir, é gerado o código hash do Bloco de mensagens
(Figura 32b).
Para que a mensagem chegue ao seu destino ela deve ser propagada através de
um mecanismo chamado sincronização, que ocorre quando dois dispositivos se conec-
(a) Criação (b) Validação
Figura 31 – Mensagens Privadas
(b) Geração do código Hash
(a) Assinatura da Mensagem
Figura 32 – Criação do Bloco de Mensagem
tam. Ao final desse processo, ambos os dispositivos possuirão os feeds pertencentes ao

Pubs em comum atualizados. Dessa forma, a cada sincronização entre dispositivos, as
mensagens vão sendo propagadas até que todos os dispositivos estejam com seus feeds
sincronizados. Considerando o exemplo da Figura 29, o armazenamento da mensagem
no feed é representado por uma cor verde escura, ao final da sincronização entre todos
os dispositivos, a configuração da rede ficará como demonstrado na Figura 33. Na figura,
também está representado com setas as sincronizações realizadas. É importante observar
que o dispositivo 2 somente realizou a sincronização com o dispositivo 3, e independente
deste fato, sua mensagem chegou a todos os dispositivos afiliados ao Pub 2.
A seguir será detalhado o processo de sincronização, no qual são verificadas e
validados a autenticidade e integridade das mensagens trocadas. O processo é inciado com
um mecanismo de Handshake logo que a conexão é estabelecida. Os objetivos dessa fase do
processo são: (i) realizar uma autenticação mútua, garantindo que o dispositivo do outro
lado da conexão é afiliado pelo(s) Pub(s) comum(ns) e que é quem diz ser e (ii) verificar
quais são os Pubs comuns entre os dois dispositivos. A Figura 34 apresenta o diagrama de
Figura 33 – Propagação da mensagem entre os dispositivos
sequência da primeira etapa do Handshake.
Figura 34 – Sincronização - Handshake
O dispositivo D01 envia um comando GET_FEED_HEADER com dois campos: a

chave pública de D01 e um campo nonce com valor randômico gerado em tempo de execução.
Ao receber o comando, o dispositivo D02 busca o primeiro feed disponível no banco de
dados. Se não houver feeds a ser enviado é retornado o comando POST_FEED_HEADER

com o campo Pub vazio (nulo). Como todos os feeds armazenados são de Pubs ao
qual D02 é afiliado, é feita uma consulta no banco de dados para retornar o ticket
correspondente à afiliação de D02. Para ser autenticado por D01, D02 assina o nonce
recebido e anexa o ticket de sua afiliação ao Pub. A partir desse momento, é montado
o comando POST_FEED_HEADER e enviado ao dispositivo D01, com as seguintes
informações: (i) identificação do feed (Chave pública do Pub, Chave pública do Emissor e
Ticket), (ii) chave pública do dispositivo (no exemplo D02), (iii) Ticket de afiliação ao
Pub correspondente ao feed enviado, (iv) assinatura do nonce recebido e (v) nonce para
ser assinado pelo outro dispositivo.
A Figura 35 apresenta a continuidade do processo a partir do recebimento por
D01 do comando POST_FEED_HEADER. Assim que D01 recebe a resposta de D02 é
verificado se D01 é afiliado ao Pub relativo ao feed recebido. Caso não seja, o processo se
repete enviando um novo comando GET_FEED_HEADER para solicitar o próximo feed
do dispositivo D02.
Se D01 é afiliado ao Pub, é feita a primeira etapa da autenticação mútua, na
qual o dispositivo D01 verifica a autenticidade do dispositivo D02, através da verificação
da assinatura realizada por D02 sobre o nonce enviado e a autenticidade do ticket de
afiliação de D02. Caso a assinatura ou o ticket sejam inválidos, é retornado o comando RE-
TURN_MESSAGE, informando o erro e a conexão é encerrada, uma vez que a autenticação
mútua falhou.
Caso a assinatura e o ticket sejam legítimos, é dada a sequência no processo
verificando a integridade do feed recebido através a verificação do ticket. Tendo validado o
feed é verificado se o feed recebido já existe no banco de dados, sendo inserido caso ainda
não exista.
A segunda parte da autenticação mútua, na qual D01 é autenticado por D02, é
realizada através do envio, por D01, de um comando de retorno, com o código OK, o
ticket de afiliação de D01 ao Pub referente ao feed recém-recebido e a assinatura do nonce
enviado por D02. Ao receber o comando, o dispositivo D02 verifica a autenticidade de D01
verificando a assinatura do nonce e a autenticidade do ticket de afiliação. Da mesma forma
que feito por D01, é devolvido um comando de retorno à D01 informando o resultado da
verificação. No caso de não ter sido verificada, D02 encerra a conexão. O diagrama de
sequência dessa operação está apresentado na Figura 36
Uma vez realizada a autenticação mútua, o processo de sincronização propriamente
dito é iniciado. É a partir desse momento que também são realizadas as verificações de
integridade das mensagens. Uma vez que o dispositivo D01 já possui em seu banco de
dados todos os feeds em comum com o dispositivo D02, será feita uma varredura solicitando
ao dispositivo D02 os detalhes de cada feed através do comando GET_FEED_DETAIL.
Figura 35 – Sincronização - Autenticação Mútua (D02)
A Figura 37 apresenta o diagrama de sequência da etapa inicial da sincronização das

mensagens.
O objetivo desta etapa é verificar a última mensagem do feed em questão armazenada
no dispositivo ao qual se está conectado. Ao receber o Comando, o dispositivo D02 faz
uma consulta em seu banco de dados e estrutura o comando de retorno, informando o
sequencial e o código hash da última mensagem armazenada no feed.
Ao receber a resposta, o dispositivo D01 verifica o ticket retornando uma mensagem
de erro pelo comando RETURN_MESSAGE, caso haja algum problema na validação. Caso
Figura 36 – Sincronização - Autenticação Mútua (D01)
o ticket seja válido, as informações recebidas serão comparadas com o feed correspondente e
definido se será necessário enviar ou receber mensagens do dispositivo D02. Neste momento
existe a possibilidade do dispositivo D02 não possuir ainda o feed questionado por D01,
neste caso o dispositivo envia o sequencial zero e o último hash nulo.
A Figura 38 apresenta o diagrama de sequência para o caso em que é necessário
enviar mensagens para o dispositivo D02. Neste momento é feita a primeira verificação
da integridade do feed, o hash da última mensagem enviada é comparado com o hash da
mensagem armazenada no dispositivo D01 com o mesmo sequencial. Se os códigos hash
são diferentes, significa que há uma divergência nos feeds. É enviado uma mensagem de
retorno com um código de erro e o processo para esse feed é interrompido. Caso os códigos
hash sejam iguais, considera-se que as mensagens anteriores estejam íntegras e iguais nos
dois dispositivos.
Então o processo inicia o envio das mensagens a partir da mensagem subsequente à
última armazenada no dispositivo D02. Para isso é utilizado o comando POST_MESSAGE,
conforme representado na Figura. Ao receber o bloco da mensagem o dispositivo D02 faz
uma série de validações antes de armazená-lo no seu feed: (i) o número sequencial da men-
sagem, (ii) a assinatura da mensagem e (iii) o código hash. Caso alguma dessas validações
falhe, é enviado o código de erro correspondente ao dispositivo D01 que interrompe o
Figura 37 – Sincronização de Mensagens – Detalhes do feed
processo, passando para o próximo feed. No caso da validação ocorrer com sucesso, o bloco
de mensagem é armazenado no seu feed, incrementando o número de validações do bloco.
Na sequência, é enviado um comando de retorno informando que a validação ocorreu com
sucesso. No recebimento, o número de validações também é incrementado no seu feed.
A Figura 39 apresenta o diagrama de sequência para os casos em que é necessário
receber mensagens do dispositivo D02. O número sequencial da última mensagem arma-
zenada no feed em questão é incrementada e é enviado um comando GET_MESSAGE,
informando o feed e o sequencial. Ao receber o comando, é feita uma verificação no seu
formato. Caso haja algum problema, é retornado o comando RETURN_MESSAGE com
o código de erro. Se o comando estiver correto, é verificado se existe o bloco de mensagem
correspondente ao sequencial solicitado. Caso não haja a mensagem, é retornado o comando
POST_MESSAGE com o valor nulo no campo Pub, encerrando a sincronização para esse
Figura 38 – Sincronização de Mensagens – Envio de Mensagens
feed. Caso exista o bloco de mensagem, é preparado um comando POST_MESSAGE. O

tratamento dado ao comando é o mesmo já descrito no caso anterior.
Ao terminar a varredura em todos os feeds o processo de sincronização está finalizado.
As validações do número sequencial, da assinatura e do código hash do bloco de mensagem
estabelecem um mecanismo de integridade das mensagens propagadas entre os diversos
dispositivos participantes da rede.
Figura 39 – Sincronização de Mensagens – Recepção de Mensagens

64
5 AVALIAÇÃO
Este capítulo descreve os experimentos realizados a fim de avaliar o protocolo proposto.

Na Seção 5.1, descreve-se a metodologia adotada para a produção dos experimentos de
ordem prática e via simulação. Em seguida, na Seção 5.2, são apresentados experimentos
práticos com o objetivo de testar as funcionalidades do protocolo. Finalmente, na Seção
5.3, resultados produzidos em ambiente de simulação são apresentados e discutidos.
5.1 Cenário dos Experimentos

O hardware utilizado para o desenvolvimento e testes do protocolo e hospedagem
dos Pubs nos experimentos foi utilizado um PC MacMini Late 2014, com 16GB de memória.
Foram usados dois dispositivos IoT: um computador embarcado Toradex, módulo Colibri
iMX7D 1GB eMMC com a placa base Aster (Figura 40a) e um Raspberry Pi 3 – Model
B (Figura 40b). Foram escolhidos computadores embarcados devido sua capacidade de
reunir os diversos componentes de computação em uma única placa: CPU, memória,
armazenamento, gerenciamento de energia, comunicação Ethernet, Wi-Fi e Bluetooth. Por
conta desta característica esse tipo de dispositivo tem sido usado em ICSs e redes de IIoT.
(a) Computador Embarcado Toradex – Módulo (b) Raspberry Pi 3 – Model B

Colibri iMX7D e placa base Aster
Figura 40 – Dispositivos do Experimento
O módulo Colibri iMX7D é um computador embarcado baseado nos processadores

NXP i.MX 7Dual, ARM Cortex A7 1GHz, com 1GB de memória RAM e armazenamento
de 4GB eMMC, possui conectividade via Ethernet, portas USB e VGA. O Raspberry Pi 3
– Model B também é um computador embarcado com processador Broadcom BCM2837,
Quad Core 64-bit ARMv8 Cortex-A53 1.2GHz, com 1GB RAM de memória RAM, arma-
zenamento através de SD Card, conectividade via Ethernet e WiFi, portas USB e conector
Capítulo 5. Avaliação 65
HDMI. Ambos computadores possuem sistema operacional Linux baseados em Debian,

facilitando assim a portabilidade dos programas desenvolvidos.
A linguagem de programação escolhida para o desenvolvimento do protótipo a
ser utilizado nos experimentos foi C. Considerando que o protocolo deve ser executado
em diversos dispositivos, com diferentes processadores e arquiteturas e em configurações
com poucos recursos computacionais, a linguagem de programação deve possuir algumas
características para atender a esses requisitos: possuir portabilidade para os diversos
processadores e arquiteturas disponíveis e gerar códigos binários eficientes. Também deve
possibilitar acesso de baixo nível a fim de acessar recursos do hardware e/ou do sistema
operacional com poucas interfaces, permitir a criação de bibliotecas possibilitando seu
reuso e ser popular entre a comunidade de desenvolvedores (89).
O C é a linguagem de programação embarcada mais amplamente usada, com
compiladores disponíveis para quase todos os microprocessadores, microcontroladores e
núcleos de processador (90). Além disso, devido ao seu tempo no mercado, podem ser
encontradas bibliotecas para os principais algoritmos, protocolos, drivers para sensores e
atuadores, o que facilita e reduz o tempo de desenvolvimento.
A Figura 41 apresenta o Diagrama de Componentes de software do protocolo
proposto. Cada dispositivo possui cinco componentes: (i) criptografia, (ii) persistência,
(iii) JSON, (iv)socket, e (v) controle.
Figura 41 – Diagrama de Componentes - Visão Geral
O componente de Criptografia utiliza a biblioteca Sodium1 . A biblioteca foi desen-

volvida pelo criador da Curva 25519, uma função de curva elíptica Diffie-Hellman (91). Por
ser um algoritmo rápido e seguro com cálculos uniformes e sem pontos fracos conhecidos
1
https://doc.libsodium.org/ - O nome Sodium é derivado do acrônimo da biblioteca: NaCl (Networking
and Cryptography library), que também é a fórmula molecular do Cloreto de Sódio
até hoje, a Curva 25519 tem sido adotada em diversas aplicações, como por exemplo nas
bibliotecas SSL/TLS (92).
Figura 42 – Diagrama de Componentes - Criptografia
Além dos algoritmos de geração de chaves, utilizando a Curva 25519 e o esquema

ED25519, a biblioteca sodium também disponibiliza funções de assinatura e validação de
assinatura; funções de cifragem e decifragem, para implementação de confidencialidade,
rotinas de codificação e decodificação para Base64, e rotinas de cálculo de código hash.
A codificação em Base64 é usada para representar dados binários arbitrários como texto,
permitindo assim a utilização de formatos puramente textuais, como XML ou JSON, na
troca de informações (93). No protótipo, as mensagens do protocolo utilizam a codificação
Base64. Para o cálculo dos códigos hash, a biblioteca disponibiliza diversos algoritmos.
Para o trabalho foi escolhido o SHA256 (Secure Hash Algorithm) que produz um hash de
256 bits (32 bytes).
O componente de persistência utiliza a biblioteca sqlite2 . O SQLite é popular por
sua utilização em celulares e dispositivos móveis, por seu baixo consumo de recursos e
também por permitir a utilização de comandos SQL (Structured Query Language) o que
facilita o gerenciamento de armazenamento e consulta dos dados nos dispositivos.
Este trabalho utiliza o JSON3 como formato de organização de dados. Isto se
deve ao fato de que seu formato é independente da linguagem, e tem sido utilizado nos
protocolos de comunicação como padrão de formatação das mensagens. Assim, para o
desenvolvimento do componente JSON foi utilizada a biblioteca jansson4 , pela simplicidade
de uso, pequeno tamanho e com funções abrangentes, o que permite criar e manipular as
mensagens trocadas de forma simples e rápida.
2
sqlitehttps://www.sqlite.org/capi3ref.html
3
https://www.json.org/
4
https://digip.org/jansson/
O componente sockets implementa a parte do trabalho que abstrai os pontos

de conexão de um dispositivo. São acessados pelos programas como como um arquivo
comum. São projetados para que permitam a comunicação entre processos distintos na
mesma máquina ou em máquinas distintas em uma mesma rede. No modelo OSI ficam
posicionados entre a camada de aplicação e a de transporte, como apresentado na Figura
43. Sua implementação no protocolo é realizada por bibliotecas nativas da linguagem C.
Figura 43 – Comunicação por sockets
5.2 Testes de Funcionamento

Para validar as rotinas de sincronização, foram desenvolvidos três testes. O primeiro
teste visou verificar o funcionamento do protocolo no que tange à propagação correta
das mensagens geradas por cada dispositivo a cada sincronização realizada. O objetivo
do segundo teste foi realizar um teste de recuperação do banco de dados, no qual um
dispositivo com seus feeds já sincronizados tiveram o banco de dados apagado, simulando
algum problema ocorrido no sistema de armazenamento. Os dois testes utilizaram o cenário
descrito na Figura 44 com três Pubs e quatro dispositivos, na qual as setas representam as
afiliações dos dispositivos aos Pubs. Após esses dois testes, o terceiro teve por finalidade
verificar a execução do protocolo proposto utilizando dispositivos IoT.
Para a execução automática dos testes foram desenvolvidos scripts em Python.
5.2.1 Teste de propagação de mensagens

O objetivo dessa seção é verificar o funcionamento do protocolo no que tange à
propagação correta das mensagens geradas por cada dispositivo a cada sincronização
realizada. A seguir serão apresentados diagramas de sequência representando os quatro
dispositivos descritos no cenário da Figura 44. Os retângulos em amarelo representam os
banco de dados de cada dispositivo. Nos diagramas são representadas também a geração
das mensagens pelos dispositivos.
As mensagens emitidas pelos dispositivos são armazenadas em um feed, que é
identificado pelo par Pub x Emissor. Assim, o banco de dados de um dispositivo pode
conter diversos feeds, sejam eles emitidos pelo próprio dispositivo ou recebidos no momento
Figura 44 – Cenário de Teste 1
da sincronização. Porém, somente são armazenados os feeds que sejam de Pubs aos quais o
dispositivo seja afiliado. Nos diagramas de sequência a seguir, os feeds serão identificados
pela codificação Pxx-Dyy, onde xx é o número do Pub e yy o número do dispositivo. A
afiliação de cada dispositivo é apresentada na sua descrição.
O início do experimento está descrito no diagrama de sequência apresentado na
Figura 45. Os dispositivos 1 e 2 geram mensagens que são armazenadas em seus bancos de
dados representados nos retângulos amarelos. A geração de mensagens pelos dispositivos
são representadas pelos retângulos cor de rosa. Após a sincronização entre os dispositivos
1 e 2 os respectivos bancos de dados são atualizados.
O experimento é iniciado com a emissão de mensagens pelos dispositivos 1 e 2. O
dispositivo 1 emite uma mensagem no feed P01-D01 e o dispositivo 2 emite duas mensagens:
uma no feed P01-D02 e outra no feed P02-D02, como representado na Figura 45.
Como o único Pub comum aos dois dispositivos é o Pub 1, apenas as mensagens
geradas em feeds do Pub 1 são sincronizadas. Ou seja, o dispositivo 1 não recebe as
mensagens emitidas pelo dispositivo 2 no feed P02-D02. Na sequência, a Figura 46
apresenta o diagrama de sequência das sincronizações entre os dispositivos 2, 3 e 4, com
geração de mensagens dos dispositivos 2 e 4 nos feeds P01-D02 e P03-D04 respectivamente.
Na sincronização entre os dispositivos 2 e 3, apenas o feed P02-D02 é sincronizado, uma vez
que o dispositivo 3 não é associado ao Pub 1. Antes da última sincronização desse diagrama
(Figura 46), o dispositivo 4 gera uma mensagem no feed P03-D04. Na sincronização com o
dispositivo 2, os feeds referentes ao Pub 1 são trazidos para o seu banco de dados. Devido
ao fato do Pub 3 só possuir o dispositivo 4 como associado, a mensagem gerada no feed
P03-D04 não será propagado entre os demais dispositivos desse experimento.
A última fase do teste de propagação de dados está descrita através do diagrama de
Figura 45 – Sincronização entre Dispositivos 1 e 2
sequência apresentado na Figura 47. Nesse momento, o dispositivo 3 emite uma mensagem
no feed P02-D03 antes da sincronização com o dispositivo 1. Após a sincronização entre os
dispositivos 1 e 3 são realizadas as sincronizações entre os dispositivos 1 e 4 e entre os
dispositivos 2 e 3.
Após a sincronização entre os dispositivos 1 e 3, os bancos de dados de ambos
os dispositivos permanecem inalterados. Isso é devido ao fato de que os dispositivos não
são afiliados a nenhum Pub comum. Porém, após a sincronização entre os dispositivos
1 e 4, o banco de dados do dispositivo 1 foi atualizado, com a mensagem emitida pelo
dispositivo 2. Importante observar a propagação dessa mensagem que não chegou ao
dispositivo 1 pela sincronização com o emissor, mas através de um terceiro dispositivo,
no caso o dispositivo 4 que é associado a um Pub comum aos dois outros dispositivos.
Finalmente, a sincronização entre os dispositivos 2 e 3 para a propagação da última
mensagem emitida pelo dispositivo 3. E ao final desse procedimento os dispositivos estão
com todas as mensagens sincronizadas.
5.2.2 Teste de recuperação do banco de dados

No próximo experimento um dispositivo terá seus feeds já sincronizados comple-
tamente apagados, simulando algum problema ocorrido no sistema de armazenamento
do dispositivo. A Figura 48 apresenta o cenário de teste no qual o banco de dados do
dispositivo 2 foi danificado. Importante ressaltar que o par de chaves do dispositivo não
tenha sido afetado ou que de alguma forma, possa ter sido recuperado.
A primeira ação para recuperar os dados no dispositivo 1, é solicitar novos convites
Figura 46 – Sincronização entre dispositivos 2, 3 e 4
aos Pubs aos quais o dispositivo era afiliado. No caso específico os Pubs 1 e 2. Uma vez
de posse dos convites, deve-se instalá-los no dispositivo. No próximo passo, o dispositivo
envia uma solicitação de ticket aos Pubs 1 e 2. Esse processo está descrito no diagrama de
sequência apresentado na Figura 49.
Uma vez os tickets restaurados, para restaurar os feeds, basta realizar sincronizações
com dispositivos que sejam afiliados aos mesmos Pubs. No caso, foram realizadas as
sincronizações com os dispositivos 1 e 3, conforme descrito no diagrama de sequência
apresentado na Figura 50. Ao final do processo, os feeds do dispositivo 2 foram totalmente
restaurados.
5.2.3 Teste com dispositivos IoT

Nesse cenário de testes, descrito na Figura 51, foram usados os dois dispositivos IoT
disponíveis: um computador embarcado Toradex e um computador embarcado Raspberry
Pi. O dispositivo Toradex não tem conexão com a internet ou com os Pubs a que é afiliado.
O Raspberry Pi fará o papel de um dispositivo móvel que será responsável por propagar
as mensagens entre o Toradex e o restante da rede.
Figura 47 – Sincronização entre dispositivos
Ambos dispositivos são afiliados aos Pubs 1 e 2. O experimento é iniciado com

a geração de mensagens por todos os dispositivos, que são armazenados nos respectivos
bancos de dados. Cada dispositivo e Pub geram 100 mensagens em cada feed, conforme
apresentado no diagrama de sequência da Figura 52.
Para facilitar a visualização e conferência dos resultados, as mensagens geradas tem
o seguinte formato: Msg<Código do dispositivo>-<Sequência>. Os feeds são representados
no diagrama por <Código do Pub>-<Código do Dispositivo emissor>. A Tabela 4
apresenta os códigos utilizados. As mensagens geradas nos feeds do Pub1 são numeradas
de 1 a 100, as mensagens geradas nos feeds do Pub2 são numeradas de 201 a 300.
Tabela 4 – Códigos dos Dispositivos
Dispositivo Código
Toradex T
Raspberry Pi R
Pub 1 P01
Pub 2 P02
Figura 48 – Perda dos dados – Dispositivo 2
Figura 49 – Recuperação dos tickets – Dispositivo 2
Como os Pubs e o Raspberry estão conectados, são realizados três procedimentos

de sincronismo: o Raspberry com cada Pub e os Pubs entre si. Ao sincronizar com os Pubs,
o Raspberry recebe as mensagens geradas pelos Pubs em seus respectivos feeds e cada Pub
recebe as mensagens geradas pelo Raspberry nos feeds correspondentes. A sincronização
entre os dois Pubs não ocasiona nenhuma alteração nos bancos de dados, uma vez que os
Pubs não possui afiliações em comum. O diagrama de sequência da Figura 53 apresenta o
sincronismo do Raspberry com os Pubs.
Ao final das sincronizações, o Raspberry possui no seu banco de dados uma cópia
Figura 50 – Recuperação de dados – Dispositivo 2
Figura 51 – Cenário de Testes com dispositivos IoT
de todas as mensagens emitidas pelos dispositivos online do experimento.

Na próxima etapa do experimento, o Raspberry conecta-se com o dispositivo
Offline e realiza a sincronização. Como ambos são afiliados dos dois Pubs, o Toradex recebe
todas as mensagens produzidas pelos demais dispositivos (o Raspberry e os Pubs). E o
Raspberry recebe as mensagens geradas pelo Toradex. O procedimento realizado Offline
está apresentado no diagrama de sequência da Figura 54.
Na etapa final do experimento, apresentada no diagrama de sequência da Figura 55,
o Raspberry volta a conectar-se com os demais dispositivos da rede e realiza a sincronização
com os dois Pubs. Ao final, os Pubs estão com as mensagens geradas pelo dispositivo
Figura 52 – Geração das Mensagens
Figura 53 – Sincronização com os Pubs
Offline em seus bancos de dados.
5.3 Simulação de ataques

Inicialmente foi avaliada a possibilidade de utilização de datasets de ataques à ICSs
disponíveis na literatura, sendo um dos mais populares os produzidos por Morris(94). Esses
datasets foram desenvolvidos para simulações de ataques em dois tipos de ICSs: sistemas
elétricos e gasodutos. Em ambos os casos, simulam ataques de modificação ou fabricação
em protocolo Modbus, com diversos objetivos: acionar relés indevidamente, alterar valores
monitorados e alterar de configurações de equipamentos. Porém, as premissas utilizadas
nesses datasets é de que ou o atacante tenha acesso irrestrito à rede Modbus, ou de que o
Figura 54 – Sincronização Offline
atacante seja um participante desonesto. Situações que não se enquadram no escopo deste
trabalho.
Desta forma, as simulações de ataque foram desenvolvidas de forma a se enquadra-
rem nas premissas do trabalho. Foram realizadas diversas simulações de ataques do tipo
MitM, com foco na propagação das mensagens geradas pelos dispositivo offline. Assim
como nos testes de funcionamento, foram desenvolvidos scripts em Python para a execução
automática das simulações que serão descritas a seguir.
5.3.1 Ataque de Fabricação – spoofing

Nessa simulação de ataque, são criados dois dispositivos, um Pub e um dispositivo
comum, que tentarão se passar como dispositivos validados pela rede com o objetivo de
coletar os dados gerados pelo dispositivo offline. A primeira fase do ataque está descrita
no diagrama de sequência apresentado na Figura 56. O atacante cria um Pub com par
de chaves pública / secreta válidas, habilitado para gerar convites, validá-los para gerar
tickets, porém não habilitado para participar da rede a ser atacada.
Com o Pub criado, o atacante cria um dispositivo, semelhante como feito com o
Pub. Na sequência, instala o convite gerado pelo Pub Falso, que em seguida conecta-se
ao Pub para conseguir um ticket válido. Nesse ponto, o atacante possui um dispositivo
íntegro, com um ticket validado por um Pub, porém ambos não autenticados pela rede.
O próximo passo é conectar-se ao dispositivo offline com o objetivo de que após
a sincronização o atacante consiga uma cópia do banco de dados do dispositivo offline,
como apresentado no diagrama de sequência da Figura 57.
Figura 55 – Sincronização Offline – Terceira Etapa
Porém, apesar do dispositivo atacante conseguir se conectar ao dispositivo offline, o

fato de não serem afiliados a Pubs em comum, ao final da sincronização não há transferência
de informações do dispositivo offline para o dispositivo atacante.
5.3.2 Ataque eavesdropping

Eavesdropping é uma técnica de hacking que se baseia na violação da confiden-
cialidade, onde um atacante, aproveitando de vulnerabilidades nas comunicações de um
sistema, faz um monitoramento sem autorização nesta comunicação, podendo roubar dados
e informações que poderão ser usadas posteriormente (34). Normalmente, o ataque de
eavesdropping tem o intuito de coletar informações para em um segundo momento usá-las
para um ataque mais efetivo, como por exemplo, o spoofing.
Na simulação, o atacante conseguirá através da interceptação coletar o ticket de um
outro dispositivo. Lembrando que esse atacante pode ser alguém fora da rede, como também
um participante desonesto. Em qualquer um dos casos, a tentativa será conseguir passar
da fase do handshake no processo de sincronização. Será utilizado para essa simulação o
mesmo dispositivo criado no ataque spoofing, descrito na seção 5.3.1.
A primeira fase do ataque é a interceptação de uma comunicação com o objetivo
de conseguir o ticket de um dispositivo. No caso, consideremos que o atacante tenha
tido sucesso na sua ação, e conseguido o ticket de autenticação do Raspberry no Pub 1,
Figura 56 – Ataque por Dispositivo Falso – Criação do Pub e do Dispositivo
Figura 57 – Ataque por Falso Pub – Tentativa de Sincronização
conforme apresentado na Figura 58.

Uma vez de posse do ticket, o atacante apaga o feed referente ao Pub falso e instala
um feed que pertença ao Pub do ticket coletado. No caso, o atacante espera que caso
consiga se passar por um dispositivo autenticado pelo Pub 1, consiga coletar todas os
demais feeds possíveis do Pub. Além disso, caso tenha sucesso, poderá coletar tickets de
outros Pubs e acessar feeds que sejam o objetivo final do atacante.
O processo é iniciado por um handshake, como descrito na Figura 34, com a
recepção do comando GET_FEED_HEADER pelo dispositivo offline. O atacante então
pode tentar duas abordagens diferentes ao montar o comando de retorno: ou se passa pelo
Figura 58 – Ataque eavesdropping – Coleta do ticket
dispositivo autenticado pela rede, no comando apresentado à esquerda, ou se passa pelo

próprio dispositivo apresentando um ticket de afiliação forjado. Na figura, as informações
fraudadas estão destacadas em vermelho.
Em ambos os casos, o dispositivo autêntico irá recusar a conexão. No primeiro caso,
a assinatura do nonce será inválido, pois a expectativa é que seja assinado pelo dispositivo
R, mas a assinatura foi realizada pelo dispositivo A. A segunda opção será recusada ao ser
analisado o ticket de afiliação do dispositivo A pelo Pub 1. Como o dispositivo A não é
afiliado ao Pub 1, a verificação da assinatura não obterá sucesso.
5.3.3 Ataque de Modificação – Alteração e Exclusão

Nesta simulação de ataque, o atacante buscará se comportar como um dispositivo
autorizado a fim de tentar alterar o conteúdo de mensagens válidas ou de excluir mensagens.
Nessa simulação de ataque, consideramos que o atacante tenha acesso ao dispositivo
íntegro e validado pela rede, com capacidade de alterar o banco de dados, podendo ser um
participante desonesto.
O diagrama de sequência apresentado na Figura 60 detalha a primeira fase do
ataque. No experimento o atacante aguarda a sincronização do dispositivo móvel com o
dispositivo online a fim de acessar o banco de dados com os feeds emitidos.
Após os feeds terem sido acessados, o atacante faz dois tipos de alterações nos
feeds: no feed P01-T o conteúdo da mensagem número 51 é alterada de “MsgT-51” para
“MsgTM-51”, ou seja, foi inserido um caracter “M” no meio da mensagem; no feed P02-T a
mensagem número 251 foi excluída. Na Figura 60 as alterações nos feeds estão representadas
por linhas em vermelho.
Devido ao fato do atacante não ter acesso às chaves secretas do dispositivo emissor
das mensagens (no caso, o dispositivo T), não é possível gerar uma assinatura válida
Figura 59 – Ataque eavestropping – Tentativa de Sincronização
da mensagem alterada. Mesmo considerando a hipótese do atacante gerar novos códigos

hashs sequenciais no restante do feed, as assinaturas de todas as mensagens subsequentes
à mensagem alterada teriam que ser regeradas, o que não é possível sem a posse da chave
secreta do emitente.
O mesmo acontece no caso em que o atacante remove uma mensagem do feed.
Como a assinatura da mensagem considera os códigos hash e o número sequencial da
mensagem, mesmo que o atacante refaça a sequência das mensagens, as assinaturas das
demais mensagens teriam que ser regeradas.
Após o atacante ter alterado e excluído as mensagens, a segunda etapa do ataque
será a tentativa de propagar os feeds comprometidos para o restante da rede. O diagrama
de sequência desta etapa está apresentado na Figura 61.
Inicialmente o atacante inicia a sincronização com o Pub 1. O envio das mensagens
inicia sem problemas, uma vez que a comunicação é realizada por um dispositivo autenticado
pela rede. Porém ao chegar na mensagem alterada, o algoritmo executado pelo Pub 1 não
Figura 60 – Ataque de Modificação – Acesso indevido ao dispositivo
valida a assinatura da mensagem alterada, abortando o restante do processo. Na Figura

61 há um destaque indicando que o Pub 1 somente recebeu as mensagens íntegras. A
mensagem alterada pelo atacante, bem como todas as mensagens subsequentes não foram
recepcionadas pelo Pub 1.
Em seguida, o dispositivo conecta-se com o Pub 2. Da mesma forma que aconteceu
na sincronização anterior, as mensagens são recepcionadas sem problemas até a mensagem
250. Como o atacante apagou a mensagem 251, há uma falha no sequenciamento das
mensagens fazendo com que o algoritmo rejeite a próxima mensagem, de número 252,
abortando o processo. Da mesma forma, há um destaque no diagrama indicando que só
foram recepcionadas as mensagens íntegras.
5.3.4 Ataque de Modificação – Exclusão de mensagens pós sincronização

Nessa simulação, o atacante é um participante desonesto da rede. Seu intuito é
apagar um conjunto de mensagens já propagadas pela rede e gerar um novo grupo de
mensagens sequenciadas. A simulação será realizada no dispositivo Raspberry e a situação
incial dos feeds dos dispositivos está representada na Figura 62. É possível verificar que as
Figura 61 – Ataque de Modificação – Tentativa de Propagação dos feeds comprometidos
mensagens emitidas pelo dispositivo já foram propagadas para os Pubs 1 e 2.
Figura 62 – Situação Inicial dos feeds
Ao apagar uma sequência de mensagens a partir de um determinado ponto do

encadeamento e gerar uma nova sequência de mensagens encadeadas é criada a situação
conhecida na tecnologia blockchain como fork. Uma situação no qual os dispositivos da rede
possuem cópias diferentes de um encadeamento de mensagens geradas de forma íntegra
(67). A figura 63 detalha a operação feita no ataque.
No caso em tela, o atacante apagou as mensagens de sequencial 51 até a última
mensagem do feed, no caso a de sequencial 100. Em seguida, o atacante gerou cem novas
mensagens a partir do sequencial 51 até o sequencial 150. Como as mensagens foram
criadas por um dispositivo íntegro e autenticado na rede, há uma suposta integridade
no feed, já que todos os blocos de mensagens estarão corretamente assinadas, bom como
(a) Feed Ori-

ginal (b) Feed com fork
Figura 63 – Fork criado pelo participante desonesto no feed P01-R
o encadeamento por códigos hash estarão válidos. O diagrama de sequência do ataque

realizado pelo participante desonesto é apresentado na Figura 64.
O problema decorre do fato de que o feed original, também gerados de forma autên-
tica já foram propagados na rede. Assim, deve haver um mecanismo que não permita que
haja duas versões diferentes de feeds gerados de forma correta, como é o caso apresentado
nessa simulação.
Figura 64 – Alteração do feed

Uma vez que o atacante realizou o fork na sua versão do feed P01-R, o próximo passo
é tentar propagar as novas mensagens geradas ao restante da rede através de sincronizações.
Essa operação está detalhada no diagrama de sequência da Figura 65.
Figura 65 – Tentativa de Propagação das novas mensagens
O processo de sincronização ocorre normalmente até o momento da análise dos

feeds dos dois dispositivo em que é determinado qual dispositivo deve enviar as mensagens
de forma que ambos os feeds possuam as mesmas mensagens. Como no caso em questão, a
última mensagem armazenada no Pub 1 par ao feed P01-R é a mensagem com sequencial
100 e a última mensagem do dispositivo R é a de sequencial 150, o dispositivo R prepara
um comando POST_MESSAGE da mensagem com o sequencial 101. Porém ao realizar
o processo de validação do bloco de mensagem, o Pub 1 identifica que o código hash do
bloco de mensagem com sequencial 100 não confere com o código hash armazenado no seu
banco de dados, recusando assim a recepção das novas mensagens.
5.4 Discussões sobre a solução proposta

O protocolo apresentado neste trabalho tem como objetivo permitir a troca de
informações entre dispositivos em redes ICSs IIoT nas quais existam um ou mais dispositivos
offline, ou seja, que estejam permanente ou momentaneamente sem conexão com a rede. A
troca de mensagens deve acontecer de forma a preservar a autenticidade e integridade das
mesmas.
Devido ao fato de haver dispositivos offline, foi decidido utilizar comunicação
P2P em detrimento de uma estrutura cliente-servidor, uma vez que utilizaria serviços
centralizados que não seriam acessados pelos dispositivos offline. Nesse caso seria necessária
uma solução de distribuição desses serviços nas bordas da rede para que fossem “alcançáveis”
pelos dispositivos (Edge ou Fog Computing), ou através de uma rede Mesh que faria a
conexão por saltos até alcançar o dispositivo offline.
A autenticação dos dispositivos na conexão P2P em situações nas quais não há
acesso à rede foi resolvida através de um mecanismo de autenticação mútua por tickets
gerados e assinados por Pubs, dispositivos com capacidade de gerenciar a identidade e
autenticação dos demais dispositivos de maneira simples e sem a necessidade de acesso a
serviços centralizados.
A integridade e autenticidade das mensagens geradas, seja por dispositivos offline
ou conectados foram conseguidas através de algoritmos criptográficos e por encadeamento
de mensagens, similar à da tecnologia blockchain.
A propagação das mensagens é conseguida por um mecanismo de sincronização
realizada em pares, aliada a um banco de dados distribuído, no qual todos os dispositivos
associados a um mesmo Pub possui uma cópia das mensagens geradas pelos demais
associados. Ao sincronizar somente os feeds de Pubs em comum, a solução proposta visa
minimizar os problemas decorrentes do processo utilizado no SSB, no qual são sincronizadas
todas as mensagens dos participantes da rede, podendo facilmente exaurir os recursos de
armazenamento dos dispositivos.
Foi desenvolvido um protótipo do protocolo e seu funcionamento foi testada a sua
resistência à ataques do tipo MitM, bem como a uma tentativa de propagação de um fork
indevido por um participante desonesto. A partir dos experimentos realizados, podemos
depreender que a solução proposta atingiu seus objetivos ao evidenciar que dispositivos
offline tiveram suas mensagens propagadas corretamente, preservando sua integridade e
autenticidade.
Finalmente, a Tabela 5 faz um comparativo da solução proposta com os trabalhos
relacionados apresentados no capítulo 3
Tabela 5 – Trabalhos Relacionados – Comparativo com a Solução Proposta

Arquitetura Segurança Offline
Trabalho
Fog /
Mesh P2P Outra Autenticação Integridade Parcial Total
Edge
Vishwakarma e Das(7)
Ali et al.(79, 80)
Ferretti et al.(8)
Kim et al.(82)
Amanlou e Bakar(83)
Rahman et al.(84)
Bruno e Bolettieri(52)
Yang et al.(9)
Novo(10)
Solução Proposta
85
6 CONCLUSÃO
Este trabalho apresentou um protocolo de comunicação descentralizado que tem como

principal objetivo permitir a troca de mensagens entre a rede e dispositivos offline provendo
serviços de autenticação e integridade das mesmas. Ele é projetado de forma a ser executado
em dispositivos com poucos recursos computacionais; permitir portabilidade, ou seja, ser
instalado em dispositivos com diferentes arquiteturas e ser capaz de comunicar-se com
outro dispositivo de forma segura sem a necessidade de uma entidade central.
O protocolo propõe dois tipos de dispositivos: o Pub e o dispositivo comum. Ambos
são identificados por uma chave pública e podem trocar mensagens entre si. O Pub atua
como um gerenciador de identidades aos quais os demais dispositivos devem se afiliar. A
afiliação a um Pub é confirmada por ticket, que será o principal instrumento de autenticação
dos dispositivos na rede. As mensagens emitidas pelos dispositivos são armazenadas em
feeds. Cada feed é identificado pelo par Pub x Emissor da mensagem. A integridade
das mensagens é estabelecida por um esquema de encadeamento por códigos hash e a
autenticidade por algoritmos criptográficos de assinatura digital.
Foi desenvolvido um protótipo do protocolo, tendo sido aplicado aos testes de
funcionalidade com dispositivos IoT, dentre eles um sem conexão com o restante da
rede. Resultados práticos e provenientes de experimentos simples, porém amplamente
avaliados, demonstram a viabilidade do mecanismo proposto. Resultados de simulação de
ataques revelam que o mecanismo proposto resistiu aos principais ataques do tipo MitM:
eavesdropping combinado com spoofing e ataques de modificação, com inclusão e exclusão
de mensagens.
6.1 Contribuições
Como contribuições desta tese, destacam-se:
• A proposta de um protocolo de comunicação descentralizado proposto para redes

IIoT, que permite a troca de mensagens entre rede e dispositivos offline com serviços
de autenticação e integridade.
A comunicação P2P com autenticação mútua, aliada aos mecanismos que provêm
autenticidade e integridade de forma descentralizada, têm como principal benefício
implementar esses serviços através de uma arquitetura simplificada, sem a necessi-
dade de equipamentos instalados nas bordas da rede (Edge Computing) distribuindo
serviços de segurança, originalmente providos por servidores centralizados. Ou a uti-
lização de uma rede Mesh, que a depender da distribuição geográfica dos dispositivos
Capítulo 6. Conclusão 86
offline exigiria a instalação de um grande número de dispositivos para prover uma

cobertura adequada de conectividade.
• Um mecanismo de recuperação de mensagens já propagadas, no caso de problemas

no sistema de armazenamento do dispositivo.
O banco de dados distribuído do protocolo proposto atua como um sistema de backup
descentralizado uma vez que cada dispositivo afiliado a um mesmo Pub possuirá uma
cópia dos feeds dos demais afiliados. Essa característica permite que um dispositivo
possa restaurar seus feeds em caso de problemas, como apresentado na seção 5.2.2.
• Especificação e implementação de um protótipo, disponível para download 1 do

protocolo proposto nesta dissertação.
O protótipo foi desenvolvido em linguagem C, facilitando sua portabilidade para
dispositivos com diferentes arquiteturas. Seus componentes de software foram desen-
volvidos com bibliotecas populares entre os desenvolvedores de sistemas embarcados,
devido tanto à portabilidade quanto à adequação do uso por dispositivos com poucos
recursos computacionais. O protótipo está extensamente documentado, facilitando a
reprodução dos experimentos apresentados neste trabalho.
• Um conjunto de experimentos, incluindo testes de funcionamento e simulações de

ataque.
Os testes e simulações realizados neste trabalho estão documentados detalhadamente
e podem servir de base para o desenvolvimento de novos experimentos em trabalhos
futuros.
6.2 Trabalhos Futuros

A solução proposta demonstrou-se viável ao atingir os objetivos colocados por este
trabalho, apresentando um protocolo que trata o problema da propagação de mensagens
entre dispositivos offline e a rede da qual faz parte. O trabalho traz o foco em um problema
no qual a literatura aborda de forma marginal, sem apresentar soluções direcionadas para
as questões da comunicação segura com dispositivos offline. Porém, há diversos pontos em
que a pesquisa pode avançar visando o aprimoramento da solução proposta.
Aprimoramento do mecanismo de consenso. O protocolo proposto mostrou-se resis-
tente, não propagando as mensagens da ramificação recriada pelo participante desonesto.
Porém há uma oportunidade de melhoria nesse mecanismo, no caso em que a ramificação
recriada seja propagada a dispositivos que ainda não tenham recebido a ramificação origi-
nal. Neste caso poderia haver um grande número de dispositivos com feeds conflitantes,
necessitando a implementação de um mecanismo de consenso mais robusto.
1
https://gitlab.com/programonauta/secureprotocol/
Capítulo 6. Conclusão 87
Desenvolvimento de um mecanismo de descarte de mensagens antigas (pruning) sem

comprometer a integridade do protocolo. O banco de dados distribuído, implementado no
protocolo proposto tem como um dos objetivos atuar na integridade das mensagens, porém
com o tempo os recursos de armazenamento dos dispositivos podem não ser suficientes para
armazenar todas as mensagens geradas pelos dispositivo e pelos seus pares. A utilização
de Pubs, minimiza o problema, segregando o armazenamento de forma que os dispositivos
não necessitem armazenar todas as mensagens geradas na rede. Porém, não é uma solução
definitiva. Dessa forma, é necessário o desenvolvimento de um mecanismo de pruning que
possibilite a exclusão de registros de um feed liberando espaço no dispositivo, preservando
a integridade e autenticidade dos feeds armazenados.
Realização de testes de carga e escalabilidade do protocolo. O protótipo apresentado
neste trabalho foi desenvolvido com premissas de utilização de bibliotecas leves de forma
que a execução do protocolo não afete o funcionamento dos dispositivos, porém não foram
realizados testes considerando um cenário próximo a situações reais, com uma maior
quantidade de dispositivos gerando mensagens de forma constante.
88
REFERÊNCIAS
1 CHOI, S.; YUN, J.-H.; KIM, S.-K. A comparison of ics datasets for security research
based on attack paths. In: LUIIJF, E.; ŽUTAUTAITĖ, I.; HÄMMERLI, B. M. (Ed.).
Critical Information Infrastructures Security. Cham: Springer International Publishing,
2019. p. 154–166. ISBN 978-3-030-05849-4.
2 BOFF, S. G.; PAGANO, D. J.; PLUCÊNIO, A.; ALVES, R. Aplicação de um scada a
uma unidade experimental de coluna de destilação. In: Congresso Brasileiro de P&D em
Petróleo e Gás, Salvador (BA). [S.l.: s.n.], 2005.
3 NASA. TREK Delay Tolerant Networking (DTN) Tutorial. [S.l.], 2020. Disponível em:
<https://trek.msfc.nasa.gov/Documents/trek_5_3_1/trek_dtn_tutorial.pdf>.
4 PARVIN, J. R. An overview of wireless mesh networks. Wireless Mesh Networks-Security,
Architectures and Protocols, IntechOpen, 2019.
5 Stanford-Clark, A.; Truong, H. L. MQTT For Sensor Networks (MQTT-SN) – Proto-
col Specification. [S.l.], 2013. Disponível em: <https://www.oasis-open.org/committees/
download.php/66091/MQTT-SN_spec_v1.2.pdf>.
6 MAGG, F.; VOSSELER, R. The Fragility of Industrial IoT’s Data Backbone.
[S.l.], 2018. Disponível em: <https://documents.trendmicro.com/assets/white\_papers/
wp-the-fragility-of-industrial-IoTs-data-backbone.pdf>.
7 VISHWAKARMA, L.; DAS, D. Scab - iota: Secure communication and authentication
for iot applications using blockchain. Journal of Parallel and Distributed Computing, v. 154,
p. 94–105, 2021. ISSN 0743-7315. Disponível em: <https://www.sciencedirect.com/science/
article/pii/S0743731521000800>.
8 FERRETTI, L.; MARCHETTI, M.; COLAJANNI, M. Fog-based secure communications
for low-power iot devices. ACM Trans. Internet Technol., Association for Computing
Machinery, New York, NY, USA, v. 19, n. 2, mar. 2019. ISSN 1533-5399. Disponível em:
<https://doi.org/10.1145/3284554>.
9 Yang, Z.; He, J.; Tian, Y.; Zhou, J. Faster authenticated key agreement with per-
fect forward secrecy for industrial internet-of-things. IEEE Transactions on Industrial
Informatics, v. 16, n. 10, p. 6584–6596, 2020.
10 Novo, O. Blockchain meets iot: An architecture for scalable access management in iot.
IEEE Internet of Things Journal, v. 5, n. 2, p. 1184–1195, 2018.
11 LEWIS, F. Applied Optimal Control and Estimation. Prentice-Hall„ 1992. ISBN
978-0130403612. Disponível em: <https://lewisgroup.uta.edu/history.htm>.
12 HAYDEN, E.; ASSANTE, M.; CONWAY, M. An Abbreviated History of Automation
and Industrial Controls Systems and Cybersecurity. [S.l.], 2014. Disponível em: <https://ics.
sans.org/media/An-Abbreviated-History-of-Automation-and-ICS-Cybersecurity.pdf>.
13 BARADI, D.; XAVIER, J. Relay logic programming explained. In: 2018 71st Annual
Conference for Protective Relay Engineers (CPRE). [S.l.: s.n.], 2018. p. 1–11.
Referências 89
14 MCLAUGHLIN, S.; KONSTANTINOU, C.; WANG, X.; DAVI, L.; SADEGHI, A.-R.;
MANIATAKOS, M.; KARRI, R. The cybersecurity landscape in industrial control systems.
Proceedings of the IEEE, IEEE, v. 104, n. 5, p. 1039–1057, 2016. ISSN 0018-9219.
15 ENISA. Communication network dependencies for ICS/SCADA Systems. [S.l.], 2016.
Disponível em: <https://www.enisa.europa.eu/publications/ics-scada-dependencies>.
16 BRASIL. Política Nacional de Defesa. [S.l.], 2020. Disponível em: <https://www.gov.
br/defesa/pt-br/assuntos/copy_of_estado-e-defesa/pnd_end_congresso_.pdf>.
17 PLIATSIOS, D.; SARIGIANNIDIS, P.; LAGKAS, T.; SARIGIANNIDIS, A. G. A
survey on scada systems: Secure protocols, incidents, threats and tactics. IEEE Communi-
cations Surveys Tutorials, v. 22, n. 3, p. 1942–1976, 2020.
18 KIM, J.; LEE, J.; KIM, J.; YUN, J. M2m service platforms: Survey, issues, and
enabling technologies. IEEE Communications Surveys Tutorials, v. 16, n. 1, p. 61–76,
2014.
19 KENG, D.; KOO, S. G. Spatial standards for internet of things. In: 2014 IEEE
International Conference on Internet of Things (iThings), and IEEE Green Computing
and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing
(CPSCom). [S.l.: s.n.], 2014. p. 284–287.
20 Dai, H.; Zheng, Z.; Zhang, Y. Blockchain for internet of things: A survey. IEEE
Internet of Things Journal, v. 6, n. 5, p. 8076–8094, 2019.
21 SCHRECKER, S.; SOROUSH, H.; MOLINA, J.; LEBLANC, J.; HIRSCH, F.;
BUCHHEIT, M.; GINTER, A.; MARTIN, R.; BANAVARA, H.; ESWARAHALLY,
S.; RAMAN, K.; KING, A.; ZHANG, Q.; MACKAY, P.; WITTEN, B. Indus-
trial Internet of ThingsVolume G4: Security Framework. [S.l.], 2016. Disponível
em: <https://www.iiconsortium.orghttps://www.iiconsortium.org/pdf/IIC\_PUB\_G4\
_V1.00\_PB.pdf>.
22 Sahadevan, A.; Mathew, D.; Mookathana, J.; Jose, B. A. An offline online strategy for
iot using mqtt. In: 2017 IEEE 4th International Conference on Cyber Security and Cloud
Computing (CSCloud). 445 Hoes Lane, Piscataway, NJ 08854: IEEE, 2017. p. 369–373.
23 Meiklejohn, C. S.; Van Roy, P. Loquat: A framework for large-scale actor communica-
tion on edge networks. In: 2017 IEEE International Conference on Pervasive Computing
and Communications Workshops (PerCom Workshops). 445 Hoes Lane, Piscataway, NJ
08854: IEEE, 2017. p. 563–568.
24 GALáN-JIMéNEZ, J.; MOGUEL, E.; GARCíA-ALONSO, J.; BERROCAL, J. Energy-
efficient and solar powered mission planning of uav swarms to reduce the coverage gap in
rural areas: The 3d case. Ad Hoc Networks, v. 118, p. 102517, 2021. ISSN 1570-8705. Dis-
ponível em: <https://www.sciencedirect.com/science/article/pii/S157087052100072X>.
25 NUGROHO, A. P.; OKAYASU, T.; HOSHI, T.; INOUE, E.; HIRAI, Y.; MITSUOKA,
M.; SUTIARSO, L. Development of a remote environmental monitoring and control
framework for tropical horticulture and verification of its validity under unstable network
connection in rural area. Computers and Electronics in Agriculture, v. 124, p. 325–339,
2016. ISSN 0168-1699. Disponível em: <https://www.sciencedirect.com/science/article/
pii/S0168169916301569>.
Referências 90
26 AGHASHAHI, M.; SUNDARARAJAN, R.; POURAHMADI, M.; BANKS, M. K.

Water distribution systems analysis symposium–battle of the attack detection algorithms
(batadal). In: World Environmental and Water Resources Congress 2017. Sacramento,
California: ASCE Library, 2017. Disponível em: <https://ascelibrary.org/doi/abs/10.1061/
9780784480595.010>.
27 Zhu, B.; Joseph, A.; Sastry, S. A taxonomy of cyber attacks on scada systems. In:
2011 International Conference on Internet of Things and 4th International Conference on
Cyber, Physical and Social Computing. 445 Hoes Lane, Piscataway, NJ 08854: IEEE, 2011.
p. 380–388.
28 ALVES, T.; DAS, R.; MORRIS, T. Virtualization of industrial control system testbeds
for cybersecurity. In: Proceedings of the 2Nd Annual Industrial Control System Security
Workshop. New York, NY, USA: ACM, 2016. (ICSS ’16, 1), p. 10–14. ISBN 978-1-4503-
4788-4. Disponível em: <http://doi.acm.org/10.1145/3018981.3018988>.
29 LIN, C. T.; WU, S. L.; LEE, M. L. Cyber attack and defense on industry control
systems. In: 2017 IEEE Conference on Dependable and Secure Computing. [S.l.: s.n.], 2017.
p. 524–526.
30 WIBOWO, M. H. A.; GUO, H.; GOH, W. L. Detecting anomalies in metro systems.
In: 2018 IEEE 4th World Forum on Internet of Things (WF-IoT). [S.l.: s.n.], 2018. p.
302–307.
31 LIN, J.; YU, W.; ZHANG, N.; YANG, X.; ZHANG, H.; ZHAO, W. A survey on internet
of things: Architecture, enabling technologies, security and privacy, and applications. IEEE
Internet of Things Journal, v. 4, n. 5, p. 1125–1142, Oct 2017.
32 AYALA, L. Cybersecurity lexicon. [S.l.]: Springer, 2016. v. 158.
33 MUKADDAM, A.; ELHAJJ, I.; KAYSSI, A.; CHEHAB, A. Ip spoofing detection
using modified hop count. In: 2014 IEEE 28th International Conference on Advanced
Information Networking and Applications (AINA). [s.n.], 2014. v. 00, p. 512–516. ISSN
1550-445X. Disponível em: <doi.ieeecomputersociety.org/10.1109/AINA.2014.62>.
34 Syverson, P. A taxonomy of replay attacks [cryptographic protocols]. In: Proceedings
The Computer Security Foundations Workshop VII. [S.l.: s.n.], 1994. p. 187–191.
35 JIANG, J.; ZHAO, X.; WALLACE, S.; COTILLA-SANCHEZ, E.; BASS, R. Mining
pmu data streams to improve electric power system resilience. In: Proceedings of the
Fourth IEEE/ACM International Conference on Big Data Computing, Applications and
Technologies. New York, NY, USA: ACM, 2017. (BDCAT ’17, 12), p. 95–102. ISBN 978-1-
4503-5549-0. Maio/2019. Disponível em: <http://doi.acm.org/10.1145/3148055.3148082>.
36 GAO, W.; MORRIS, T. H. On cyber attacks and signature based intrusion detection
for modbus based industrial control systems. Journal of Digital Forensics, Security and
Law, v. 9, n. 1, p. 37–55, 2014. Disponível em: <https://doi.org/10.15394/jdfsl.2014.1162>.
37 STALLINGS, W. Cryptography And Network Security – Principles and Practice. [S.l.]:
Pearson Education, 2017.
38 Hossain, M. M.; Fotouhi, M.; Hasan, R. Towards an analysis of security issues,
challenges, and open problems in the internet of things. In: 2015 IEEE World Congress
on Services. [S.l.: s.n.], 2015. p. 21–28. ISSN 2378-3818.
Referências 91
39 Schollmeier, R. A definition of peer-to-peer networking for the classification of peer-

to-peer architectures and applications. In: Proceedings First International Conference on
Peer-to-Peer Computing. 1730 Massachusetts Ave., NW Washington, DCUnited States:
IEEE Computer Society, 2001. p. 101–102.
40 FALL, K. A delay-tolerant network architecture for challenged internets. In: Proceedings

of the 2003 Conference on Applications, Technologies, Architectures, and Protocols for
Computer Communications. New York, NY, USA: Association for Computing Machinery,
2003. (SIGCOMM ’03), p. 27–34. ISBN 1581137354. Disponível em: <https://doi.org/10.
1145/863955.863960>.
41 FALL, K.; FARRELL, S. Dtn: an architectural retrospective. IEEE Journal on Selected

Areas in Communications, v. 26, n. 5, p. 828–836, 2008.
42 MADNI, M. A. A.; IRANMANESH, S.; RAAD, R. Dtn and non-dtn routing protocols
for inter-cubesat communications: A comprehensive survey. Electronics, v. 9, n. 3, 2020.
ISSN 2079-9292. Disponível em: <https://www.mdpi.com/2079-9292/9/3/482>.
43 MAO, Y.; ZHOU, C.; LING, Y.; LLORET, J. An optimized probabilistic delay tolerant
network (dtn) routing protocol based on scheduling mechanism for internet of things (iot).
Sensors, v. 19, n. 2, 2019. ISSN 1424-8220. Disponível em: <https://www.mdpi.com/
1424-8220/19/2/243>.
44 Bruno, R.; Conti, M.; Gregori, E. Mesh networks: commodity multihop ad hoc networks.
IEEE Communications Magazine, IEEE Communications Society, 3 Park Avenue 17th
Floor New York, NY 10016, v. 43, n. 3, p. 123–131, 2005.
45 NAEEM, R. Z.; BASHIR, S.; AMJAD, M. F.; ABBAS, H.; AFZAL, H. Fog computing
in internet of things: Practical applications and future directions. Peer-to-Peer Networking
and Applications, Springer, v. 12, n. 5, p. 1236–1262, 2019.
46 VAQUERO, L. M.; RODERO-MERINO, L. Finding your way in the fog: Towards a

comprehensive definition of fog computing. SIGCOMM Comput. Commun. Rev., Asso-
ciation for Computing Machinery, New York, NY, USA, v. 44, n. 5, p. 27–32, out. 2014.
ISSN 0146-4833. Disponível em: <https://doi.org/10.1145/2677046.2677052>.
47 VAKILI, M. G.; DEMARTINI, C.; GUERRERA, M.; MONTRUCCHIO, B. Open

source fog architecture for industrial iot automation based on industrial protocols. In:
2019 IEEE 43rd Annual Computer Software and Applications Conference (COMPSAC).
[S.l.: s.n.], 2019. v. 1, p. 570–578.
48 Thota, P.; Kim, Y. Implementation and comparison of m2m protocols for internet of
things. In: 2016 4th Intl Conf on Applied Computing and Information Technology/3rd Intl
Conf on Computational Science/Intelligence and Applied Informatics/1st Intl Conf on Big
Data, Cloud Computing, Data Science Engineering (ACIT-CSII-BCD). 445 Hoes Lane,
Piscataway, NJ 08854: IEEE, 2016. p. 43–48.
49 CoRE Working Group, T. I. C. R. E. RFC7252 - The Constrained Application Protocol

(CoAP). [S.l.], 2014. Disponível em: <https://tools.ietf.org/html/rfc7252>.
50 Oasis Open Foundation. MQTT Version 5.0 – OASIS Standard Specification. [S.l.],
2019. Disponível em: <https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html>.
Referências 92
51 Al-Masri, E.; Kalyanam, K. R.; Batts, J.; Kim, J.; Singh, S.; Vo, T.; Yan, C. Investiga-
ting messaging protocols for the internet of things (iot). IEEE Access, v. 8, p. 94880–94911,
2020.
52 Bruno, R.; Bolettieri, S. Design and implementation of a coap-based broker for

heterogeneous m2m applications. In: 2018 IEEE International Congress on Internet of
Things (ICIOT). [S.l.: s.n.], 2018. p. 1–8.
53 BENDEL, S.; SPRINGER, T.; SCHUSTER, D.; SCHILL, A.; ACKERMANN, R.;
AMELING, M. A service infrastructure for the internet of things based on xmpp. In: 2013
IEEE International Conference on Pervasive Computing and Communications Workshops
(PERCOM Workshops). [S.l.: s.n.], 2013. p. 385–388.
54 AL-FUQAHA, A.; KHREISHAH, A.; GUIZANI, M.; RAYES, A.; MOHAMMADI, M.

Toward better horizontal integration among iot services. IEEE Communications Magazine,
v. 53, n. 9, p. 72–79, 2015.
55 REINFURT, L.; BREITENBüCHER, U.; FALKENTHAL, M.; LEYMANN, F.;

RIEGG, A. Internet of things patterns. In: Proceedings of the 21st European Confe-
rence on Pattern Languages of Programs. New York, NY, USA: Association for Compu-
ting Machinery, 2016. (EuroPlop 16), p. 1 – 21. ISBN 9781450340748. Disponível em:
<https://doi.org/10.1145/3011784.3011789>.
56 Al-Fuqaha, A.; Guizani, M.; Mohammadi, M.; Aledhari, M.; Ayyash, M. Internet of
things: A survey on enabling technologies, protocols, and applications. IEEE Communica-
tions Surveys Tutorials, v. 17, n. 4, p. 2347–2376, 2015.
57 NGUYEN, K. T.; LAURENT, M.; OUALHA, N. Survey on secure communication

protocols for the internet of things. Ad Hoc Networks, v. 32, p. 17 – 31, 2015. ISSN
1570-8705. Internet of Things security and privacy: design methods and optimization.
Disponível em: <http://www.sciencedirect.com/science/article/pii/S1570870515000141>.
58 KAVIANPOUR, S.; SHANMUGAM, B.; AZAM, S.; ZAMANI, M.; SAMY, G. N.;
BOER, F. D. A systematic literature review of authentication in internet of things for
heterogeneous devices. Journal of Computer Networks and Communications, v. 2019, 2019.
ISSN 2090-7141. Disponível em: <https://doi.org/10.1155/2019/5747136>.
59 MARINO, F.; MOISO, C.; PETRACCA, M. Automatic contract negotiation, service

discovery and mutual authentication solutions: A survey on the enabling technologies of the
forthcoming iot ecosystems. Computer Networks, v. 148, p. 176 – 195, 2019. ISSN 1389-1286.
Disponível em: <http://www.sciencedirect.com/science/article/pii/S1389128618312167>.
60 HARIT, A.; EZZATI, A.; ELHARTI, R. Internet of things security: Challenges and
perspectives. In: Proceedings of the Second International Conference on Internet of Things,
Data and Cloud Computing. New York, NY, USA: Association for Computing Machinery,
2017. (ICC ’17), p. Article No 167 Pages 1–8. ISBN 9781450347747. Disponível em:
<https://doi.org/10.1145/3018896.3056784>.
61 Kim, H.; Wasicek, A.; Mehne, B.; Lee, E. A. A secure network architecture for the
internet of things based on local authorization entities. In: 2016 IEEE 4th International
Conference on Future Internet of Things and Cloud (FiCloud). 445 Hoes Lane, Piscataway,
NJ 08854: IEEE, 2016. p. 114–122.
Referências 93
62 Hamad, S. A.; Sheng, Q. Z.; Zhang, W. E.; Nepal, S. Realizing an internet of secure
things: A survey on issues and enabling technologies. IEEE Communications Surveys
Tutorials, v. 22, n. 2, p. 1372–1391, 2020.
63 NETO, A. L. M.; SOUZA, A. L. F.; CUNHA, I.; NOGUEIRA, M.; NUNES, I. O.;
COTTA, L.; GENTILLE, N.; LOUREIRO, A. A. F.; ARANHA, D. F.; PATIL, H. K.;
OLIVEIRA, L. B. Aot: Authentication and access control for the entire iot device life-cycle.
In: Proceedings of the 14th ACM Conference on Embedded Network Sensor Systems CD-
ROM. New York, NY, USA: Association for Computing Machinery, 2016. (SenSys ’16), p.
1–15. ISBN 9781450342636. Disponível em: <https://doi.org/10.1145/2994551.2994555>.
64 Macedo, E. L. C.; de Oliveira, E. A. R.; Silva, F. H.; Mello, R. R.; França, F. M. G.;
Delicato, F. C.; de Rezende, J. F.; de Moraes, L. F. M. On the security aspects of internet
of things: A systematic literature review. Journal of Communications and Networks, v. 21,
n. 5, p. 444–457, 2019.
65 SICARI, S.; RIZZARDI, A.; GRIECO, L.; COEN-PORISINI, A. Security, privacy
and trust in internet of things: The road ahead. Computer Networks, v. 76, p. 146 – 164,
2015. ISSN 1389-1286. Disponível em: <http://www.sciencedirect.com/science/article/pii/
S1389128614003971>.
66 KHAN, M. A.; SALAH, K. Iot security: Review, blockchain solutions, and open
challenges. Future Generation Computer Systems, v. 82, p. 395 – 411, 2018. ISSN 0167-739X.
Disponível em: <http://www.sciencedirect.com/science/article/pii/S0167739X17315765>.
67 Christidis, K.; Devetsikiotis, M. Blockchains and smart contracts for the internet of
things. IEEE Access, v. 4, p. 2292–2303, 2016. ISSN 2169-3536.
68 Florea, B. C. Blockchain and internet of things data provider for smart applications.
In: 2018 7th Mediterranean Conference on Embedded Computing (MECO). 445 Hoes Lane,
Piscataway, NJ 08854: IEEE, 2018. p. 1–4.
69 Fridrich, J.; Goljan, M. Robust hash functions for digital watermarking. In: Procee-
dings International Conference on Information Technology: Coding and Computing (Cat.
No.PR00540). [S.l.: s.n.], 2000. p. 178–183.
70 ANTONOPOULOS, A. M. Mastering Bitcoin: unlocking digital cryptocurrencies.
Sebastopol, CA: " O’Reilly Media, Inc.", 2014.
71 LAO, L.; LI, Z.; HOU, S.; XIAO, B.; GUO, S.; YANG, Y. A survey of iot applications
in blockchain systems: Architecture, consensus, and traffic modeling. ACM Comput. Surv.,
Association for Computing Machinery, New York, NY, USA, v. 53, n. 1, fev. 2020. ISSN
0360-0300. Disponível em: <https://doi.org/10.1145/3372136>.
72 APT, K. R.; KOPCZYNSKI, E.; WOJTCZAK, D. On the computational complexity
of gossip protocols. In: IJCAI. Melbourne, Australia: International Joint Conferences on
Artificial Intelligence, 2017. p. 765–771.
73 aO, R. B. A blockchain-based protocol for message exchange in a ics network: Stu-
dent research abstract. In: Proceedings of the 35th Annual ACM Symposium on Applied
Computing. New York, NY, USA: Association for Computing Machinery, 2020. (SAC
’20), p. 357–360. ISBN 9781450368667. Disponível em: <https://doi.org/10.1145/3341105.
3374231>.
Referências 94
74 POPOV, S. The Tangle. [S.l.], 2018. Disponível em: <https://iota.org/IOTA_

Whitepaper.pdf>.
75 BARTOLOMEU, P. C.; VIEIRA, E.; FERREIRA, J. Iota feasibility and perspectives

for enabling vehicular applications. In: IEEE. 2018 IEEE Globecom Workshops (GC
Wkshps). [S.l.], 2018. p. 1–7.
76 LINDVALL, M. How is authenthicity and confidentiality maintained for mam channels

on the iota tangle? Varden Development, Varden Development, 2019.
77 Zorzo, A. F.; Nunes, H. C.; Lunardi, R. C.; Michelin, R. A.; Kanhere, S. S. Dependable
iot using blockchain-based technology. In: 2018 Eighth Latin-American Symposium on
Dependable Computing (LADC). [S.l.: s.n.], 2018. p. 1–9.
78 Wang, J.; Li, M.; He, Y.; Li, H.; Xiao, K.; Wang, C. A blockchain based privacy-
preserving incentive mechanism in crowdsensing applications. IEEE Access, v. 6, p. 17545–
17556, 2018.
79 ALI, S.; BANERJEA, S.; PANDEY, M.; TYAGI, N. Wireless fog-mesh: A communi-
cation and computation infrastructure for iot based smart environments. In: RENAULT,
É.; BOUMERDASSI, S.; BOUZEFRANE, S. (Ed.). Mobile, Secure, and Programmable
Networking. Gewerbestrasse 11, 6330 Cham, Switzerland: Springer International Publishing,
2019. p. 322–338. ISBN 978-3-030-03101-5.
80 ALI, S.; PANDEY, M.; TYAGI, N. Wireless-fog mesh: A framework for in-network
computing of microservices in semipermanent smart environments. International Journal
of Network Management, v. 30, n. 6, p. e2125, 2020. E2125 nem.2125. Disponível em:
<https://onlinelibrary.wiley.com/doi/abs/10.1002/nem.2125>.
81 YANG, X.; HU, Y. A dht-based infrastructure for content-based publish/subscribe

services. In: Seventh IEEE International Conference on Peer-to-Peer Computing (P2P
2007). [S.l.: s.n.], 2007. p. 185–192.
82 KIM, H.; KANG, E.; LEE, E. A.; BROMAN, D. A toolkit for construction of autho-
rization service infrastructure for the internet of things. In: Proceedings of the Second
International Conference on Internet-of-Things Design and Implementation. New York,
NY, USA: Association for Computing Machinery, 2017. (IoTDI ’17), p. 147–158. ISBN
9781450349666. Disponível em: <https://doi.org/10.1145/3054977.3054980>.
83 AMANLOU, S.; BAKAR, K. A. A. Lightweight security mechanism over mqtt protocol

for iot devices. International Journal of Advanced Computer Science and Applications,
The Science and Information Organization, v. 11, n. 7, 2020. Disponível em: <http:
//dx.doi.org/10.14569/IJACSA.2020.0110726>.
84 Rahman, A.; Roy, S.; Kaiser, M. S.; Islam, M. S. A lightweight multi-tier s-mqtt
framework to secure communication between low-end iot nodes. In: 2018 5th International
Conference on Networking, Systems and Security (NSysS). [S.l.: s.n.], 2018. p. 1–6.
85 HERNAN, S.; LAMBERT, S.; OSTWALD, T.; SHOSTACK, A. Threat modeling-

uncover security design flaws using the stride approach. MSDN Magazine-Louisville, San
Francisco, CA: CMP Media Inc., c2000-, p. 68–75, 2006.
Referências 95
86 SCUTTLEBUTT. Scuttlebutt Protocol Guide. 2019. <https://ssbc.github.io/

scuttlebutt-protocol-guide/index.html>. [Online; accessed 27-Sept-2019].
87 TSCHUDIN, C. End-to-end encrypted scalable abstract data types over icn. In:
Proceedings of the 5th ACM Conference on Information-Centric Networking. New York,
NY, USA: ACM, 2018. (ICN ’18, .), p. 88–94. ISBN 978-1-4503-5959-7. Maio/2019.
Disponível em: <http://doi.acm.org/10.1145/3267955.3267962>.
88 KERMARREC, A.-M.; LAVOIE, E.; TSCHUDIN, C. Gossiping with append-only

logs in secure-scuttlebutt. In: Proceedings of the 1st International Workshop on Distributed
Infrastructure for Common Good. New York, NY, USA: Association for Computing
Machinery, 2020. (DICG’20), p. 19–24. ISBN 9781450381970. Disponível em: <https:
//doi.org/10.1145/3428662.3428794>.
89 PONT, M. J. Embedded C. [S.l.]: Addison-Wesley Longman Publishing Co., Inc., 2002.
90 GARRIDO, J. M. Improving software development for embedded systems. In: Pro-

ceedings of the SouthEast Conference. New York, NY, USA: Association for Compu-
ting Machinery, 2017. (ACM SE ’17), p. 231–234. ISBN 9781450350242. Disponível em:
<https://doi.org/10.1145/3077286.3077318>.
91 MEHIBEL, N.; HAMADOUCHE, M. A new approach of elliptic curve diffie-hellman

key exchange. In: 2017 5th International Conference on Electrical Engineering - Boumerdes
(ICEE-B). [S.l.: s.n.], 2017. p. 1–6.
92 NIASAR, M. B.; KHATIB, R. E.; AZARDERAKHSH, R.; MOZAFFARI-KERMANI,

M. Fast, small, and area-time efficient architectures for key-exchange on curve25519. In:
2020 IEEE 27th Symposium on Computer Arithmetic (ARITH). [S.l.: s.n.], 2020. p. 72–79.
93 MUŁA, W.; LEMIRE, D. Faster base64 encoding and decoding using avx2 instructions.
ACM Trans. Web, Association for Computing Machinery, New York, NY, USA, v. 12, n. 3,
jul. 2018. ISSN 1559-1131. Disponível em: <https://doi.org/10.1145/3132709>.
94 Morris, T. Industrial Control System (ICS) Cyber Attack Datasets. [S.l.], 2014. Dispo-
nível em: <https://sites.google.com/a/uah.edu/tommy-morris-uah/ics-data-sets>.

Protocolo Distribuído para Dispositivos de Internet Das Coisas em Instalações Offline

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Protocolo Distribuído para Dispositivos de Internet Das Coisas em Instalações Offline

Enviado por

Direitos autorais:

Formatos disponíveis

MINISTÉRIO DA DEFESA

RICARDO DE AZEVEDO BRANDÃO

PROTOCOLO DISTRIBUÍDO PARA DISPOSITIVOS DE INTERNET DAS

PROTOCOLO DISTRIBUÍDO PARA DISPOSITIVOS DE INTERNET DAS

Tese apresentada ao Programa de Pós-graduação em Enge-

Brandão, Ricardo de Azevedo.

Orientador: Ricardo Choren.

Tese (doutorado) – Instituto Militar de Engenharia, Engenharia de Transportes,

1. Comunicação entre dispositivos. 2. Segurança e Privacidade. 3. Internet

Protocolo distribuído para dispositivos de Internet das

Tese apresentada ao Programa de Pós-graduação em Engenharia de Transportes do

Aprovada em 13 de dezembro de 2021, pela seguinte banca examinadora:

Prof. Ricardo Choren - D.Sc. do IME - Presidente

Prof. Paulo César Salgado Vidal - D.Sc. do IME

Prof. Ronaldo Moreira Salles - Ph.D do IME

Prof. Célio Vinicius Neves de Albuquerque - Ph.D da UFF

Prof. David Fernandes Cruz Moura - D.Sc. do CETEx

Os sistemas de controle industriais ou ICSs (Industrial Control Systems) se popularizaram

Palavras-chave: Comunicação entre dispositivos. Segurança e Privacidade. Internet das

Keywords: Device-to-Device Communication. Machine-to-Machine Communications.

Figura 1 – Arquitetura de um ICS (1) . . . . . . . . . . . . . . . . . . . . . . . . . 16

Tabela 1 – Vulnerabilidades à ameaças (10) . . . . . . . . . . . . . . . . . . . . . . 43

CoAP Constrained Application Protocol

DCS Distributed Control System

DTLS Datagram Transport Layer Security

DTN Delay-Tolerant Network

ENISA European Union Agency For Network And Information Security

EWS Engineering Workstation

HTTP Hypertext Transfer Protocol

ICS Industrial Control Systems

IEC International Electrotechnical Commission

IED Intelligent Electronic Device

IHM Interface Homem Máquina

IoT Internet of Things

IIoT Industrial Internet of Things

ISA International Society of Automation

MAC Message Authentication Code

MitM Man in the middle

MQTT Message Queuing Telemetry Transport

P2P Peer to Peer

PLC Programmable Logic Controller

QoS Quality of Service

RTU Remote Terminal Unit

SCADA Supervisory Control and Data Acquisition

SHA Secure Hash Algorithm

UDP User Datagram Protocol

XMPP Extensible Messaging and Presence Protocol

O desenvolvimento de controles automáticos está intimamente ligado aos problemas

Estratégia Nacional de Defesa, elaborada pelo Ministério da Defesa, ressalta a importância

Figura 1 – Arquitetura de um ICS (1)

A figura apresenta também o fluxo de dados em um ICS: entre os níveis 0 e 1

no caminho completo, ou apenas por parte dele.

Figura 2 – Tela de controle de uma ICS (2)

Inicialmente, os ICSs eram projetados para utilizar redes de comunicação privadas.

Figura 3 – Fluxo de Dados em uma operação normal de um ICS (1)

de sistemas de telefonia são exemplos nos quais os dispositivos ficam permanentemente

Figura 4 – Exemplo de rede com dispositivos offline

Nesse contexto, os dispositivos móveis são responsáveis por estabelecer a troca de

Figura 5 – Cenários de Ataque e seus caminhos

Figura 6 – Replay Attack

Uma variação do ataque de repetição utiliza a técnica de espelhamento do sinal,

(a) Sinal Original (b) Sinal Mascarado por Espelhamento

Figura 7 – Espelhamento de Sinal