DISSERTAÇÃO Fabio Leite Soares

FÁBIO LEITE SOARES
Sistema embarcado para comunicação intraveicular segura em Diagnostics

over IP - DoIP
Universidade Federal de Pernambuco

posgraduacao@cin.ufpe.br
www.cin.ufpe.br/~posgraduacao
Recife
2016
FÁBIO LEITE SOARES

over IP - DoIP
Dissertação de Mestrado apresentada ao

Programa de Pós-Graduação em Ciência
da Computação da Universidade Federal de
Pernambuco, como requisito parcial para a
obtenção do título de Mestre em Ciência da
Computação.
Orientador: Divanilson Rodrigo de Sousa

Campelo
Recife
2016
Catalogação na fonte
Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217
S676s Soares, Fábio Leite

Over IP - DoIP / Fábio Leite Soares. – 2016.
90 f.:il., fig., tab.
Orientador: Divanilson Rodrigo de Sousa Campelo.

Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn,
Ciência da Computação, Recife, 2016.
Inclui referências.
1. Segurança da informação. 2. Criptografia. 3. Sistemas embarcados. I.

Campelo, Divanilson Rodrigo de Sousa (orientador). II. Título.
005.8 CDD (23. ed.) UFPE- MEI 2017-232

Fabio Leite Soares
Sistema Embarcado para Comunicação Intraveicular Segura em

Diagnostics Over IP – DoIP
Dissertação de Mestrado apresentada ao

Programa de Pós-Graduação em Ciência da
Computação da Universidade Federal de
Pernambuco, como requisito parcial para a
obtenção do título de Mestre em Ciência da
Computação
Aprovado em: 09/09/2016.
BANCA EXAMINADORA
__________________________________________
Prof. Dr. Carlos André Guimarães Ferraz
Centro de Informática / UFPE
__________________________________________
Prof. Dr. Luis Henrique Maciel Kosmalski Costa
Departamento de Eletrônica e de Computação / UFRJ
__________________________________________
Prof. Dr. Divanilson Rodrigo de Sousa Campelo
Centro de Informática / UFPE
(Orientador)
A Deus, meus pais e minha família que tanto amo.
Agradecimentos
Primeiramente agradeço a Deus por sempre me guiar, ajudar e me dar forças

frente aos questionamentos e dificuldades da vida, sem Ele nada disso seria possível.
Aos meus queridos pais, Reginaldo e Ladjane, que não deixaram de acreditar em mim
em nenhum momento, mesmo quando pensei em desistir da carreira de engenheiro da
computação, mesmo quando eu achava que era incapaz, quando estava cansado, eles
estiveram sempre ao meu lado, me amando e me incentivando em todas as fases da
minha vida, à eles agradeço por ter chegado até aqui. Eles não imaginam o quanto eu
os amo.
Agradeço às minhas irmãs Flávia e Fernanda pela paciência, amor e compreensão
desde o início de tudo em 2007 quando iniciei minha graduação. À Fernanda pelo seu
carinho, cuidado e imensa paciência comigo durante o nosso convívio diário.
À minha namorada Camila, por ser tão especial com seu carinho, atenção e compreen-
são. Me fez enxergar a vida de outra forma sendo ela a maior responsável da minha
felicidade diária em suas imensas declarações e afeto. Me acompanhando lado a lado
em todos os meus passos, não poderia ser mais feliz ao seu lado.
Gostaria de expressar gratidão em especial ao Professor Divanilson Campelo, que,
através da sua forma competente de pensar e agir, mudou a minha vida pessoal e
completamente a profissional. Aprendi com ele não só como conduzir uma pesquisa
científica mas também como impactar cientificamente a sociedade com os resultados
gerados neste trabalho. Sua visão moderna e empreendedora de como devemos enxer-
gar a pesquisa acadêmica contemporânea e sua respectiva contribuição à sociedade
trouxe ao Centro de Informática da UFPE uma estreita relação profissional com o maior
departamento privado de pesquisa e desenvolvimento para Ethernet automotiva do
mundo, localizado na Alemanha. Destaco também sua paciência e compreensão às
falhas que cometi durante esta trajetória, foram exatamente nas minhas quedas que
mais aprendi com ele. Sua orientação nesta jornada foi definitivamente uma experiência
enriquecedora.
Agradeço aos meus grandes amigos do grupo de pesquisa em Redes Intraveiculares do
Centro de Informática, Edilson, Bianca, Rhudney, Paulo e Rodrigo que me incentivaram
bastante e acreditaram em mim. Em especial a Edilson e Bianca que me ajudaram
neste projeto de mestrado com imensa empatia e olhar crítico.
Por fim, expresso minha gratidão e admiração aos professores da banca avaliadora,
Professor Luís (UFRJ) e Professor Carlos (UFPE), por aceitarem o convite e dedicarem
o seu tempo à leitura e apreciação deste trabalho, contribuindo com críticas e sugestões
para a melhoria desta pesquisa.
A todos, muito obrigado.
“A good scientist is a person with original ideas.
A good engineer is a person who makes a
design that works with as few original ideas
as possible. There are no prima donnas in
engineering”. Freeman Dyson
Resumo
Nos últimos anos, a falta de medidas de segurança em protocolos de comu-

nicação intraveiculares acarretou em sérios problemas para a indústria automotiva.
Casos recentes demonstram carros modernos sendo hackeados através de suas redes
intraveiculares via interfaces digitais de acesso com ou sem fio. À medida que as Unida-
des Eletrônicas de Controle (ECU) são comprometidas, os invasores são capazes de
controlar completamente sistemas críticos como o ABS (Anti-lock breaking system), o
sistema de direção elétrica e o de aceleração, por exemplo, provocando riscos severos
para os condutores e passageiros do veículo. Redes intraveiculares de diagnóstico não
são exceções. Através da porta de acesso para as redes intraveiculares padronizadas,
OBD-II, o invasor pode explorar o CAN gateway de diversas maneiras para obter o total
controle da rede intraveicular e, consequentemente, dos sistemas críticos veiculares. O
padrão ISO 13400 Diagnostic communication over Internet Protocol (DoIP), lançado
em 2012, é um padrão fundamentalmente proposto a definir como mensagens de
diagnóstico serão transmitidas sobre uma rede de comunicação IP, desde a camada
física até a camada de transporte, seguindo o modelo OSI. O padrão ISO 14229 Unified
Diagnostic Services (UDS) e o ISO 27145-3 World-Wide Harmonized On-Board Diag-
nostics (WWH-OBD) são os principais padrões que definem a estrutura da mensagem
de diagnóstico, já que o DoIP apenas especifica os requisitos necessários para o trans-
porte das mensagens. Embora o ISO 13400 tenha sido desenvolvido para ser o próximo
padrão confiável e de longo prazo para mensagens de diagnóstico automotivas sobre IP,
mecanismos de segurança não foram definidos para tratar conhecidas vulnerabilidades
herdadas do modelo TCP/IP tais como, ARP spoofing, MAC spoofing, IP Spoofing,
TCP session hijacking, monitoramento de pacotes, modificações não autorizadas em
bytes e retransmissão de pacotes manualmente. Mesmo com a presença de uma sub-
camada de segurança no UDS através do serviço SecureDataTransmission (0x84), três
serviços desse mesmo protocolo continuam vulneráveis a possíveis ataques, sendo
eles: ResponseOnEvent (0x86), ReadDataByPeriodicIdentifier (0x2A) e TesterPresent
(0x3E). Além do mais, a sub-camada de segurança oferecida situa-se na camada
de aplicação, camada 7, permanecendo as camadas subjacentes desprotegidas e
vulneráveis a possíveis ataques. Este trabalho apresenta um modelo seguro de um
DoIP Edge Node, entidade de comunicação entre as redes intraveiculares e agentes
externos, em IPv6. O sistema de comunicação embarcado assim como a performance
de rotinas criptográficas são analisadas sob as quatro topologias centrais descritas
no padrão DoIP. Ameaças e vulnerabilidades para cada camada da pilha de comuni-
cação, os riscos e mecanismos de mitigação também são levados em consideração.
O modelo proposto cobre quatro requisitos essenciais da segurança da informação:
confidencialidade, integridade, autenticidade e temporalidade. Devido ao overhead de
processamento provenientes dos mecanismos de segurança empregados tais como o
Transport Layer Security (TLS), Generic Routing Encapsulation (GRE), Internet Pro-
tocol Security (IPSec) e o Media Access Control Security (MACsec), uma análise do
desempenho da rede é realizada e comparada ao desempenho de redes inseguras.
Por fim, são apresentados os possíveis custos de desenvolvimento, o gerenciamento
de chaves e certificados e o hardware utilizado nesta arquitetura.
Palavras-chave: Redes Intraveiculares. Segurança da Informação. Criptografia. Siste-

mas Embarcados. Ethernet Automotiva. Diagnóstico sobre IP.
Abstract
The lack of security in current in-vehicle communication protocols has brought

serious problems to the automotive industry in the past few years. Recent demon-
strations have shown modern cars being hacked through in-vehicle networks either
via wired access or wirelessly. By taking control over crucial Electronic Control Units
(ECUs), hackers were able to compromise, for instance, the anti-lock braking system,
the steering wheel and the throttle control system, leading to severe risks for drivers
and passengers. Diagnostic networks are not an exception. Through the On-board
Diagnostics (OBD-II) connector, the attacker can exploit the CAN gateway in many
different ways to obtain full access to the internal car network and conduct similar
attacks. The ISO 13400 Diagnostics over IP (DoIP), released in 2012, is a standard
fundamentally proposed to define how diagnostic messages are transmitted over an
IP communication network, from the transport layer to the physical layer, following the
OSI model. Despite the fact it was initially designed only for diagnostic systems, ISO
13400 also has the capability of providing transport protocol and network layer services
for other IP-based systems, if necessary. The ISO 14229 Unified Diagnostic Services
(UDS) and ISO 27145-3 World-Wide Harmonized On-Board Diagnostics (WWH-OBD)
are the primary standards that define the structure of diagnostic messages, since
DoIP only specifies the requirements for message transportation. Although the ISO
13400 standard has been developed to be the next reliable and long-term protocol
for automotive diagnostics over IP, no security mechanisms have been proposed so
far to manage well-known vulnerabilities inherited from the TCP/IP model, such as
ARP spoofing, MAC spoofing, eavesdropping, message tampering and message replay.
Even though the Unified Diagnostic Services provide an application security sub-layer
through the SecuredDataTransmission service (0x84), three services are still uncovered:
ResponseOnEvent (0x86), ReadDataByPeriodicIdentifier (0x2A) and TesterPresent
(0x3E). Moreover, this security sub-layer is only at the application layer, leaving lower
layers still vulnerable to attacks. This work presents an embedded implementation of a
secure IPv6 DoIP Edge Node, the external interface entity for the DoIP network. The
embedded network security and the cryptographic performance routines are analyzed
under the four central network topologies described in the DoIP standard. Potential
threats and vulnerabilities for each layer of the stack, their associated risks and the
security mechanisms to mitigate the attacks are also addressed. The implementation
covers four essential security requirements: data confidentiality, data integrity, data
authenticity and data freshness. Authorization and resiliency are also discussed. Due
to the cryptographic computing overhead caused by security mechanisms such as
Transport Layer Security (TLS), ISO 15764, IPsec and MACsec, a network performance
analysis is presented, along with a comparison with unsecured systems. Finally, the
development costs, the key management and the hardware required for the proposed
architecture are discussed.
Keywords: In-vehicle Networks. Information Security. Cryptography. Embedded Sys-

tems. Automotive Ethernet. Diagnostics over IP.
Lista de figuras
Figura 1 – Comparação do número de linhas de código entre veículos e aplica-

ções de alta complexidade. . . . . . . . . . . . . . . . . . . . . . . . 21
Figura 2 – Imagem de Charlie Miller e Chris Valasek enviada através do sistema
de telemetria do Jeep Cherokee 2014 . . . . . . . . . . . . . . . . . 22
Figura 3 – Redes intraveiculares modernas. . . . . . . . . . . . . . . . . . . . . 28
Figura 4 – Funcionalidades oferecidas em carros modernos. . . . . . . . . . . 28
Figura 5 – Conjunto de cabos utilizados em carros modernos. . . . . . . . . . . 29
Figura 6 – Modelo OSI em CAN. . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figura 7 – Subcamadas do protocolo CAN. . . . . . . . . . . . . . . . . . . . . 31
Figura 8 – Arquitetura atual da uma rede intraveicular automotiva. . . . . . . . 34
Figura 9 – Coexistência das diferentes redes intraveiculares . . . . . . . . . . . 35
Figura 10 – Transição de arquitetura centralizada para uma arquitetura hierár-
quica através do uso de gateways/switches (hexágonos) e backbone
Ethernet (retângulo superior central à direita). . . . . . . . . . . . . . 36
Figura 11 – Automotive Ethernet Roadmap. . . . . . . . . . . . . . . . . . . . . . 38
Figura 12 – Uso conjunto de câmeras, radar e sensores de proximidade. . . . . 40
Figura 13 – Diagramas de codificação do padrão Ethernet e do BroadR-Reach. 41
Figura 14 – Componentes físicos da conexão BroadR-Reach. . . . . . . . . . . 42
Figura 15 – Padrão Ethernet como backbone da arquitetura de rede intraveicular. 43
Figura 16 – Arquitetura AUTOSAR. . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figura 17 – Cronograma AUTOSAR. . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figura 18 – Porta OBD-II. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Figura 19 – Modelo OSI e o padrão DoIP comparado ao padrão de diagnósticos
sobre CAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Figura 20 – Arquitetura da rede de diagnóstico. . . . . . . . . . . . . . . . . . . . 54
Figura 21 – Conexão direta 1 - 1: (1) Cabo Ethernet, (2) equipamento de diagnós-
tico, (3) veículo e (4) conexão lógica. . . . . . . . . . . . . . . . . . . 58
Figura 22 – Conexão através da rede 1 - 1: (1) Ethernet switch e ponto de acesso
sem fio, (2) cabo Ethernet, (3) WLAN, (4, 5) equipamentos de diag-
nóstico, (6, 7) veículos e (8, 9) conexões lógicas distintas. . . . . . . 59
Figura 23 – LegConexão através da rede N - 1: (1) Rede local do centro de manu-
tenção, (2) cabo Ethernet, (3) WLAN, (4) equipamento de diagnóstico,
(5) servidor, (6, 7, 8) veículos e (9, 10) conexões lógicas distintas. . 60
Figura 24 – Conexão através da rede 1 - N: (1) Rede local do centro de ma-
nutenção, (2) cabo Ethernet, (3) WLAN, (4, 5) equipamentos de
diagnóstico, (6) servidor, (7, 8, 9) veículos e (10, 11, 12, 13) conexões
lógicas distintas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Figura 25 – Plataforma de prototipação utilizada neste trabalho . . . . . . . . . . 72
Figura 26 – Funcionamento do MACsec. . . . . . . . . . . . . . . . . . . . . . . 75
Figura 27 – Camadas de segurança aplicadas ao modelo proposto. . . . . . . . 77
Figura 28 – Modelo de encapsulamento das mensagens de diagnóstico. . . . . 78
Figura 29 – Execução da realização de rotinas de diagnóstico em um canal seguro. 79
Lista de tabelas
Tabela 1 – Lista de atributos de segurança . . . . . . . . . . . . . . . . . . . . 63

Tabela 2 – Protocolos utilizados pelo DoIP . . . . . . . . . . . . . . . . . . . . 68
Tabela 3 – Ameaças e vulnerabilidades mapeadas no padrão ISO 13400-2. . . 71
Tabela 4 – Authenticated Encryption e respectivas taxas de transmissão . . . . 80
Lista de abreviaturas e siglas
ABS Anti-lock Breaking System
ADAS Advanced Driver Assistance Systems
AES Advanced Encryption Standard
ARP Address Resolution Protocol
AUTOSAR Automotive Open System Architecture
AVB Audio/Video Bridging
CAN Controller Area Network
CAT 5 Category 5 Cable
CCU Communication Control Unit
CMC Common Mode Choke
DAS Driver Assistance Systems
DHCP Dynamic Host Configuration Protocol
DoIP Diagnostic communication over Internet Protocol
DoS Denial-of-Service
DTC Diagnostic Trouble Code
ECU Electronic Control Unit
EMC Electromagnetic Compatibility
EMI Electromagnetic Interference
ESP Encapsulating Security Payload
EVITA E-safety Vehicle Intrusion Protected Applications
GCM Galois/Counter Mode
GPS Global Positioning System
GRE Generic Routing Encapsulation
ICMP Internet Control Message Protocol

IEEE Institute of Electrical and Electronics Engineers
IKEv2 Internet Key Exchange version 2
IP Internet Protocol
IPsec Internet Protocol Security
ISO International Organization for Standardization
LAN Local Area Network
LAND Local Area Network Denial
LIN Local Interconnect Network
LVDS Low-Voltage Differential Signaling
MAC Medium Access Control
MAC Message Authentication Code
MACsec Media Access Control Security
MAN Metropolitan Area Network
MLT Multi-Level Transmit
MOST Media Oriented Systems Transport
NDP Neighbor Discovery Protocol
OABR OPEN Alliance BroadR-Reach
OBD On-board Diagnostics
ONU Organização das Nações Unidas
OPEN Alliance One Pair EtherNet Alliance
OSI Open Systems Interconnection
PHY Physical Layer
PKI Public Key Infrastructure
PSK Pre-Shared Key
QoS Quality of Service
RFI Radio-Frequency Interference

RJ45 Registered Jack 45
RST Reset
SAE Society of Automotive Engineers
SecOC Module Secure Onboard Communication
TCP Transmission Control Protocol
TDMA Time Division Multiple Access
TKIP Temporal Key Integrity Protocol
TLS Transport Layer Security
ToE Target Of Evaluation
TSN Time-Sensitive Networking
TTEthernet Time-Triggered Ethernet
UDP User Datagram Protocol
UDS Unified Diagnostic Services
UTP Unshielded Twisted Pair
VLAN Virtual Local Area Network
WEP Wired Equivalent Privacy
WLAN Wireless Local Area Network
WPA Wi-Fi Protected Access
WWH-ODB World Wide Harmonized On-Board-Diagnostic

Sumário
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.1 Contexto e Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.2 Objetivos da Investigação . . . . . . . . . . . . . . . . . . . . . . . 23
1.2.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.2.2 Objetivo Específico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.3 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.4 Estrutura da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . 25
2 REDES INTRAVEICULARES . . . . . . . . . . . . . . . . . . . . . . 26
2.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2 Controller Area Network . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3 Local Interconnect Network . . . . . . . . . . . . . . . . . . . . . . 31
2.4 FlexRay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.5 MOST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.6 LVDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.7 A Caminho da Ethernet Automotiva . . . . . . . . . . . . . . . . . . 33
2.7.1 Automotive Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.7.1.1 Primeira Geração: Diagnostic Communication over IP . . . . . . . . . 38
2.7.1.2 Segunda Geração: Driver Assistance Systems e Entretenimento . . . 39
2.7.1.3 BroadR-Reach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.7.1.4 Terceira Geração: Ethernet como Backbone . . . . . . . . . . . . . . 42
2.7.2 Autosar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.8 On-board Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.9 Acesso Remoto ao Diagnóstico Veicular . . . . . . . . . . . . . . . 47
2.10 Diagnóstico Automotivo Integrado . . . . . . . . . . . . . . . . . . 47
2.11 Diagnostics Communication over IP . . . . . . . . . . . . . . . . . 48
3 DESCRIÇÃO DO SISTEMA EM ANÁLISE . . . . . . . . . . . . . . . 51

3.1 Método de Análise . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.2 Agentes de Comunicação da Rede . . . . . . . . . . . . . . . . . . 53
3.3 Arquitetura da Rede DoIP . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4 Características da Camada Física e Camada de Enlace . . . . . . 55
3.5 Características da Camada de Rede e Camada de Transporte . . 55
3.6 Características da Camada de Aplicação . . . . . . . . . . . . . . 57
3.7 Topologias e Casos de Uso . . . . . . . . . . . . . . . . . . . . . . 57
3.7.1 Conexão física direta entre um veículo e um equipamento de diagnóstico 57
3.7.2 Conexão através da rede entre um veículo e um equipamento de
diagnóstico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.7.3 Conexão através da rede entre múltiplos veículos e um equipamento
de diagnóstico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.7.4 Conexão através da rede entre um veículo e múltiplos equipamentos
de diagnóstico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.8 Recursos a Serem Protegidos . . . . . . . . . . . . . . . . . . . . . 61
3.9 Requisitos de segurança . . . . . . . . . . . . . . . . . . . . . . . . 62
3.9.1 Autenticidade da Origem dos Dados . . . . . . . . . . . . . . . . . . 63
3.9.2 Integridade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.9.3 Autorização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.9.4 Data Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.9.5 Não-Rejeição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.9.6 Privacidade e Anonimidade . . . . . . . . . . . . . . . . . . . . . . . 66
3.9.7 Confidencialidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.9.8 Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.10 Análise de Ameaças e Vulnerabilidades . . . . . . . . . . . . . . . 67
3.10.1 DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.10.2 ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.10.3 NDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.10.4 ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.10.5 IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.10.6 TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.10.7 UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.10.8 Ameaças e Vulnerabilidades no protocolo DoIP . . . . . . . . . . . . 70
4 DESCRIÇÃO DO MODELO PROPOSTO . . . . . . . . . . . . . . . . 72

4.1 Plataforma utilizada . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.1.1 Sistema operacional . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.1.2 Mecanismos de Segurança Aplicados no Modelo . . . . . . . . . . . 73
4.1.2.1 MACsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.1.2.2 VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.1.2.3 Generic Routing Encapsulation . . . . . . . . . . . . . . . . . . . . . 76
4.1.2.4 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.1.2.5 TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.1.3 Pilha de TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.1.4 Modelo de encapsulamento na camada de rede . . . . . . . . . . . . 78
4.2 Análise de Desempenho . . . . . . . . . . . . . . . . . . . . . . . . 79
5 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
20
1 INTRODUÇÃO
1.1 Contexto e Motivação
Os veículos modernos, hoje equipados com diversos dispositivos eletrônicos de

alta tecnologia e complexidade, oferecem ao usuário uma infinidade de funcionalidades
e configurações, proporcionando uma experiência inovadora e sofisticada ao condutor
e aos passageiros. Um exemplo desta sofisticação se dá pela possibilidade de sin-
cronização do smartphone ao sistema de segurança e alerta do veículo. Utilizando a
conectividade à Internet oferecida por este dispositivo, o veículo é capaz de informar ao
condutor sobre alertas em tempo real, acidentes, trânsito e rotas alternativas. Carros
conectados também são muito úteis para os fabricantes, pois possibilitam um maior
controle de riscos e danos, atuando proativamente em atualizações de software re-
motas, monitoramento do desempenho do sistema e componentes em tempo real,
evitando assim maiores problemas técnicos e que comprometam a vida dos usuários e
a imagem da empresa. No entanto, juntamente com os avanços tecnológicos vêm os
riscos associados ao sistema e às falhas de segurança da informação, assim como às
questões de privacidade. Para mitigar tais ameaças, a indústria automotiva considera a
segurança1 como prioridade contra ataques digitais (INTEL SECURITY, 2015).
Por várias décadas, veículos eram apenas máquinas metálicas, contendo um
motor à combustão com o único propósito de transportar passageiros e cargas de um
lugar a outro, sem qualquer tipo de comunicação digital interna ou externa ao veículo.
Nos últimos 50 anos, a indústria automotiva tem adotado a eletrônica e a tecnologia
da informação e comunicação para cumprirem regulamentações, legislações, padrões,
controles de emissão de CO2 e eficiência no consumo de combustível; assim como a
melhoria nos sistemas de diagnóstico, no conforto oferecido ao usuário, conveniência,
comunicação e entretenimento.
Com o advento de uma sociedade permanentemente conectada, espera-se
que a mesma experiência digital e de conectividade, oferecidas por smartphones por
exemplo, estejam presentes nos veículos modernos. Funcionalidades como escutar
músicas de playlists personalizadas, fazer e receber ligações através de comandos
de voz com informações sendo exibidas na tela principal do veículo, ligar o veíclo à
distância e carros que busquem por vagas de estacionamento automaticamente são
1
Em inglês, safety e security possuem significados diferentes no contexto automotivo. Security está
associado à segurança da informação em sistemas de comunicação intraveiculares, sendo portanto, o
principal foco deste trabalho. Safety por outro lado, possui uma conotação mais abrangente, incluindo
componentes mecânicos, acústicos, elétricos e eletrônicos no veículo. É importante destacar que
security é um subconjunto de safety, logo ao contribuírmos para um sistema seguro digitalmente,
contribui-se automaticamente para um sistema veicular seguro - safety.
Capítulo 1. INTRODUÇÃO 21
exemplos de ações esperadas no futuro pelos usuários.

Portanto, espera-se que o veículo seja um nó em uma rede de dispositivos e
usuários conectados. É com esta motivação que fabricantes automotivos modernizam
seus veículos, acompanhando as necessidades e interesses dos seus usuários, e
analogamente, a modernização de componentes de segurança e conforto, garantindo
a integridade dos passageiros.
Analogamente à adição de novas funcionalidades e sistemas eletrônicos embar-
cados nos veículos, o volume de software responsável pelo correto funcionamento das
unidades eletrônicas de controle (ECU) também aumentou drasticamente. A Figura 1.1
mostra a quantidade de linhas de código presentes em um carro moderno no ano de
2010, sendo a quantidade de linhas de código em veículos duas vezes maior que o
Grande Colisor de Hádrons.
Figura 1 – Comparação do número de linhas de código entre veículos e aplicações de alta
complexidade.
IBM, 2014.
Porém, esta modernização traz riscos e consequências potencialmente fatais.

Pesquisadores de segurança da informação demonstraram que carros computado-
rizados podem ser invadidos e controlados com apenas um computador portátil e
programas de código aberto facilmente encontrados na Internet. Obtiveram sucesso
em demonstrar falsas informações enviadas ao sistema de telemetria do veículo sendo
estas exibidas no painel principal do carro como visualizado na Figura 1.2 (MILLER;
VALASEK, 2015; KOSCHER et al., 2010; CHECKOWAY et al., 2011).
Miller e Valasek demonstraram como controlar remotamente a direção do veículo
em movimento, controlar os freios e até mesmo desligar o motor completamente em
uma rodovia americana de alta velocidade. Outro exemplo de grande repercussão
partiu da empresa britânica E2V após o desenvolvimento de um dispositivo capaz de

parar os veículos através do envio de ondas eletromagnéticas (E2V, 2013).
Ataques utilizando Ramsonwares2 em sistemas de transporte, exigindo atos
políticos sob a ameaça de ataques a frotas veiculares ou transferências de dinheiro, já
foram realizados e podem aumentar proporcinalmente com o aumento da conectividade
veicular (THE GUARDIAN, 2016). O Anonymous é um conhecido exemplo de um grupo
mundial anônimo de hackers que agem principalmente por motivações políticas. Um
exemplo recente foi a declaração de “guerra total” ao atual candidato às eleições
presidenciais dos Estados Unidos da América, Donald John Trump (ANONYMOUS,
2004; THE CONVERSATION, 2016).
Figura 2 – Imagem de Charlie Miller e Chris Valasek enviada através do sistema de telemetria do
Jeep Cherokee 2014 .
Remote Exploitation of an Unaltered Passenger Vehicle, 2015.
Assim como invadir sistemas comercias evoluiu de simples brincadeiras por

adolescentes sem qualquer motivação política e financeira para empresas de ciber-
crime altamente rentáveis (DEIBERT, 2016), o mesmo pode ser esperado no âmbito
automotivo. Não apenas a segurança física dos usuários será afetada, mas a privaci-
dade também está em risco diante das vulnerabilidades presentes hoje nos veículos
modernos. Informações pessoais em smartphones, tais como e-mails, mensagens de
2
Ramsonware é um software malicioso que se aloja sem o consentimento do usuário para a execução
de um ataque criptográfico impedindo, através de criptografia, o correto funcionamento de uma ou
mais funcionalidades do sistema em troca de pagamento para a remoção do mesmo.
texto, contatos, registro de ligações, posicionamento através do GPS e outros dados

podem ser copiados ou alterados por invasores caso não existam barreiras de proteção.
Atualmente, a principal e única porta de acesso para o sistema de comunicação
intraveicular se dá através da porta de diagnóstico, On-board Diagnostics II (ODB-
II). É através dessa porta que os fabricantes automotivos realizam atualizações de
software, assim como a verificação do comportamento dos sensores e de possíveis
falhas registradas no sistema. No entanto, é através da porta de diagnóstico que vários
ataques são realizados pela facilidade do acesso físico à porta OBD-II e má construção
de mecanismos de segurança programados em software. Anteriormente ao caso
Jeep, Miller e Valasek utilizaram do fácil acesso às redes de comunicação intraveicular,
através da porta OBD-II, para a exploração de vulnerabilidades em interfaces de acesso
remoto oferecidos pelo modelo do Jeep.
É a partir dessa porta insegura hoje presente nos automóveis que este presente
trabalho analisa as ameaças, vulnerabilidades e riscos associados aos protocolos de
diagnósticos utilizados pela indústria automotiva.
O desafio para a indústria automotiva na segurança da informação é definitiva-
mente multidisciplinar: componentes eletrônicos fornecidos por empresas terceirizadas
devem ser minuciosamente analisados evitando-se casos como o backdoor3 encontrado
em dispositivos Android manufaturados pela empresa chinesa Allwinner em 2016 (THE
REGISTER, 2016), auditoria e testes de penetração durante a fabricação de firmwares
e softwares automotivos, testes de segurança, integridade e stress em ECUs, etc.
As tecnologias são complexas, a integração entre diferentes domínios é com-
plexa, a vida útil do produto e de sua manutenção é longa, a cadeia de fornecedores
de componentes automotivos nem sempre é confiável e o ambiente ao qual o veículo
está inserido é vasto em termos de ameaças.
Na verdade, a segurança da informação deve ser inserida em cada estágio do
processo de fabricação, desde o projeto do componente até a produção, chegando à
cadeia de fornecedores, montadoras e manutenção. A segurança deve fazer parte do
ecossistema automotivo desde a concepção do produto até o seu fim.
1.2 Objetivos da Investigação
1.2.1 Objetivo Geral
O objetivo geral deste trabalho é apresentar uma análise da segurança da

informação na realização de atualizações de firmware e rotinas de diagnóstico através
3
Backdoor é um recurso utilizado por diversos malwares para garantir acesso remoto ao sistema ou à
rede infectada, explorando falhas críticas não documentadas existentes em programas instalados,
softwares desatualizados e do firewall para abrir portas do dispositivo.
do uso do protocolo ISO 13400 - Diagnostics communication over the Internet Protocol.
Em seguida, um modelo de segurança é proposto a fim de mitigar os problemas de
segurança deste cenário.
1.2.2 Objetivo Específico
Este trabalho apresenta um modelo seguro de um DoIP Edge Node, entidade

de comunicação entre as redes intraveiculares e agentes externos, em IPv6. O sistema
de comunicação embarcado assim como o desempenho de rotinas criptográficas são
analisados sob as quatro topologias centrais descritas no padrão DoIP. Ameaças e
vulnerabilidades para cada camada da pilha de comunicação, os riscos e mecanismos
de mitigação também são levados em consideração. O modelo proposto cobre quatro
requisitos essenciais da segurança da informação: confidencialidade, integridade, au-
tenticidade e temporalidade. Devido à sobrecarga de processamento provenientes dos
mecanismos de segurança empregados tais como o Transport Layer Security (TLS),
Generic Routing Encapsulation (GRE), Internet Protocol Security (IPSec) e o Media
Access Control Security (MACsec), uma análise do desempenho da rede é realizada e
comparada à de redes inseguras. Por fim, o modelo proposto é validado através do uso
de uma plataforma embarcada de baixo custo. Esta plataforma utilizará bibliotecas de
código aberto, algoritmos e patches de kernel necessários para a garantia de um canal
de comunicação seguro entre as entidades.
1.3 Contribuições
As principais contribuições realizadas neste trabalho dividem-se em duas partes:
• A primeira é a análise teórica das ameaças e vulnerabilidades presentes no DoIP,

que foi proposto como o protocolo de diagnóstico de próxima geração. Nesta
análise, verifica-se que a adoção deste protocolo como a próxima tecnologia
de uso de longo prazo acarreta questões de segurança sérias e que trazem
riscos aos usuários, aos pedestres e aos fabricantes dos automóveis. Pontua-se
onde estão as falhas e quais as consequências de cada uma presentes na
comunicação entre os veículos e os equipamentos de diagnóstico.
• A segunda contribuição se dá pela proposta de um modelo de um canal de

comunicação seguro para a troca de mensagens utilizando o DoIP. Para a
validação do modelo proposto, é utilizada uma plataforma embarcada de baixo
custo capaz de executar o sistema operacional Raspbian, distribuição baseada
no sistema operacional Linux.
1.4 Estrutura da Dissertação
O restante do trabalho se organiza da seguinte forma: No Capítulo 2, as redes

intraveiculares são apresentadas. A origem e necessidade do uso destas redes são
discutidas para a compreensão das tecnologias atuais e necessidade de largura de
banda. Uma breve introdução das principais redes hoje utilizadas facilita a compreen-
são dos aspectos técnicos na transmissão de informações entre sistemas eletrônicos.
Ao fim do Capítulo 2, a Ethernet automotiva é explicada detalhadamente até o nível
elétrico da solução existente hoje no mercado. No Capítulo 3, apresenta-se o conceito
de diagnóstico automotivo e sua necessidade. Ao final, apresenta-se o protocolo ISO
13400 como protocolo do futuro nos diagnósticos automotivos.
O Capítulo 4 traz uma análise detalhada quanto às ameaças e vulnerabilidades mapea-
das no ISO 13400. As consequências de cada vulnerabilidade são apresentadas ao
fim deste capítulo. O capítulo 5 apresenta uma proposta de um modelo seguro para a
comunicação remota entre dispositivos de teste e automóveis. Por fim, os resultados e
conclusão deste trabalho aparecem nos Capítulos 6 e 7 respectivamente.
26
2 REDES INTRAVEICULARES
Neste capítulo uma breve introdução sobre as redes intraveiculares modernas

é apresentada. (NAVET; SIMONOT-LION, 2013) e (TUOHY et al., 2015) realizaram
um trabalho minucioso sobre a evolução de tecnologias, protocolos e necessidades
quanto à transmissão de informações entre ECUs. O autor deste presente trabalho
destaca a importância destas duas referências como ponto de partida para a completa
compreensão das redes intraveiculares modernas.
2.1 Introdução
Recentes avanços no desenvolvimento de hardware de sistemas embarcados e

do poder computacional desses possibilitaram grandes inovações na indústria automo-
tiva. Sistemas eletrônicos intraveiculares avançam rapidamente em complexidade e
diversidade. Inúmeros sensores e processadores são utilizados em diferentes partes de
um automóvel moderno atualmente. Sistemas como o Antilock Braking System (ABS)
e sistemas de controle de estabilidade são exemplos de sistemas que monitoram e
controlam o desempenho e dinâmica em um automóvel; já câmeras, radares e senso-
res ultrassônicos são considerados como a visão do carro no ambiente ao qual está
inserido, trazendo novas informações ao condutor e ao próprio sistema de atuação do
veículo, consequentemente aumentando o controle e a segurança sobre a dirigibilidade
do automóvel.
A natural substituição de partes mecânicas por componentes eletrônicos de
maior confiabilidade, durabilidade e eficiência, assim como legislações governamentais
para maior segurança e diminuição de índices de poluição, são alguns dos principais
fatores que incentivam a indústria automotiva no desenvolvimento de tecnologias de
redes intraveiculares. Maior eficiência de combustão, conforto, diminuição de custos,
menor peso do automóvel e menor tempo na linha de produção são algumas das
inúmeras vantagens da aplicabilidade e desenvolvimento de redes intraveiculares.
Nos primeiros estágios do desenvolvimento da indústria automotiva, o rádio era
o único componente considerado eletrônico dentre todos os outros sistemas em um
veículo. Hoje, o sistema de freio, navegação e tantas outras unidades de controle para
as portas, janelas, controle de temperatura, injeção de combustível, entre outros, são
todos eletrônicos. Considera-se uma unidade de controle eletrônica (ECU), a unidade
que utiliza sinais de entrada digitais ou analógicos de um ou mais sensores presentes no
veículo, interpreta os sinais recebidos e realiza ações através dos atuadores. Portanto,
ECUs são basicamente microcontroladores ou microprocessadores.
Capítulo 2. REDES INTRAVEICULARES 27
O processo de receber um ou mais sinais e atuar conforme as diferentes entra-

das ocorrem também entre as ECUs, e não apenas sinais advindos de sensores. Por
exemplo, em um carro automático o motor deve informar ao sistema de transmissão a
velocidade e a rotação atual do eixo principal, o sistema de transmissão irá verificar se
a marcha atual corresponde ao intervalo de marchas permitidas para a determinada
rotação e velocidade. O sistema de transmissão então trocará de marcha sempre que
a rotação do motor estiver fora da faixa preestabelecida. Todo este processo necessari-
amente deve ser realizado em tempo real, ou seja, dentro de um intervalo de tempo
que garanta a segurança do condutor, a segurança do ambiente no qual o carro se
encontra e que atenda aos requisitos de desempenho desejados.
Com o aumento do número de ECUs em um veículo e a necessidade de estarem
interconectados, o número de cabos também aumentou consideravelmente, tornando
toda a arquitetura complexa e não escalável para futuras expansões. O aumento da
complexidade não se deu apenas pelo grande número de cabos, a adição ou remoção
de uma ECU exigia uma mudança em toda a arquitetura o que tornava todo o processo
bastante difícil. Para resolver essa complexidade, os fabricantes decidiram utilizar um
barramento central ao qual as principais unidades eletrônicas de controle estariam
conectadas. Isto permitiu que diferentes unidades pudessem ser facilmente conectadas
ou desconectadas da rede, trazendo flexibilidade, escalabilidade e rapidez no processo
de fabricação.
O barramento é uma rede de comunicação específica para conectar as princi-
pais unidades eletrônicas de controle. Cada unidade é um nó responsável por controlar
determinada funcionalidade intraveicular. A comunicação e a troca de dados entre as
unidades de controle e seus componentes auxiliares acontecem sob o regimento de um
protocolo padronizado de comunicação. A razão para a introdução de novos padrões
e protocolos é uma característica do desenvolvimento tecnológico em comunicações
intraveiculares para atender demandas como imunidade eletromagnética, confiabili-
dade e disponibilidade em ambientes críticos, robustez, assim como a aplicação de
uma tecnologia rentável, quando utilizada em larga escala. A Figura 2.1 e a Figura
2.2 abaixo exibem as principais redes intraveiculares usadas em veículos modernos e
suas principais funcionalidades, respectivamente.
Figura 3 – Redes intraveiculares modernas.
Fonte: Renesas Electronics Corporation
Figura 4 – Funcionalidades oferecidas em carros modernos.
Fonte: ZF Friedrichshafen AG, 2015
Nas próximas seções, serão apresentados de forma sucinta, diferentes protoco-

los e padrões propostos na indústria automotiva. Destacam-se os diversos protocolos
de comunicação nesta indústria mapeando-os nas camadas do modelo OSI.
2.2 Controller Area Network
Controller Area Network, ou CAN, é um barramento automotivo de comunicação

pertencente à família Fieldbus desenvolvido pela empresa alemã Robert Bosch GmbH
em 1965 para a troca de informações em sistemas embarcados interconectados (Robert
Bosch GmbH, 1991).
Fieldbus é um modelo industrial de rede para sistemas distribuídos de tempo
real. É basicamente um barramento para a conexão de diferentes instrumentos em
uma planta industrial. Fieldbus opera em uma estrutura de rede que permite diversas
topologias tais como daisy-chain, estrela, anel, barramento e árvore. Anteriormente,
computadores ou sistemas embarcados eram conectados através do protocolo serial
RS-232 o qual permite apenas dois dispositivos para o estabelecimento de uma comu-
nicação. Diferentemente do RS-232, tecnologias Fieldbus são equivalentes às atuais
Local Area Networks – LANs, pois permitem centenas de dispositivos se interconecta-
rem em nível lógico através de endereçamento ou broadcast. Isto reduz drasticamente
o número de cabos necessários e o comprimento total utilizado (THOMESSE, 2005).
Para termos uma dimensão do problema de cabeamentos na indústria automo-
tiva, em um veículo moderno, este é considerado o terceiro componente de maior custo
na produção do veículo, sendo o chassis em segundo lugar e o motor em primeiro. O
trabalho de conexão e instalação dos cabos compreende 50% do custo de produção de
todo o carro como também é o terceiro componente mais pesado, portanto, qualquer
tecnologia que reduza o número de cabos, consequentemente o peso, contribuirá dire-
tamente no consumo de combustível. A Figura 2.3 exibe a quantidade de cabos totais
utilizados pelos componentes eletrônicos nos diversos barramentos de comunicação
intraveicular.
Figura 5 – Conjunto de cabos utilizados em carros modernos.
Fonte: Delphi Automotive

O barramento CAN é capaz de transmitir dados em até 1Mbps, teoricamente.

Foi um grande avanço para solucionar o problema de cabeamento na indústria au-
tomotiva pois é capaz de funcionar plenamente em ambientes de alta interferência
eletromagnética, cenário encontrado no interior dos veículos, além de ser um protocolo
tolerante a falhas. Um sistema tolerante a falhas é a propriedade a qual permite que o
sistema continue em pleno e correto funcionamento após um evento de falha em um
ou mais componentes lógicos do sistema (Robert Bosch GmbH, 1991; CORRIGAN,
2008).
Estas características tornaram o CAN bastante popular no setor automotivo,
militar, médico, industrial e aeroespacial. O protocolo CAN é um protocolo de trocas de
mensagens no qual os nós competem para utilizar o barramento através da arbitração.
A prioridade do uso do barramento é determinada pelo código de arbitração contido no
cabeçalho de cada mensagem. Um mesmo nó pode transmitir diferentes mensagens
com diferentes prioridades – código de arbitração. Os nós com mensagens prioritárias
possuem a dominância sobre o barramento ao transmitir suas mensagens, impedindo
todos os outros nós de utilizarem o barramento no mesmo instante de tempo (Robert
Bosch GmbH, 1991; CORRIGAN, 2008). Este modelo de prioridades permite que um
nó sempre vença ao disputar o barramento, impedindo outros nós de transmitirem
dados por um longo período de tempo, forçando os demais nós a não cumprirem com
seus respectivos deadlines.
O CAN é um barramento serial multi-master que transmite suas mensagens num
meio compartilhado por todos os nós conectados, ou seja, toda mensagem enviada por
qualquer nó será recebida igualmente nos demais nós da rede. O padrão CAN definido
pelo (ISO 11898-1, 2015) define o protocolo nas camadas física e de enlace do modelo
OSI. A Figura 2.4 e a Figura 2.5 mostram de forma bastante simplificada as camadas
e subcamadas do modelo OSI para as redes CAN. O detalhamento dos protocolos
utilizados nas diferentes camadas da pilha de comunicação CAN está fora do escopo
deste trabalho, dado a complexidade dos protocolos e a proposta deste trabalho quanto
à segurança da informação.
Figura 6 – Modelo OSI em CAN.
Fonte: Robert Bosch GmbH
Figura 7 – Subcamadas do protocolo CAN.
Fonte: Robert Bosch GmbH
2.3 Local Interconnect Network
Para aplicações intraveiculares simples que requerem apenas uma comunicação

sensor-atuador em um sistema de comunicação de um fio, a rede Local Interconnect
Network (LIN) é uma das mais indicadas tecnologias. Disponível desde 2001, foi
desenvolvida por um consórcio formado de 5 fabricantes automotivos BMW, Volkswagen
Group, Audi Group, Volvo Cars, Mercedes-Benz sendo a Volcano Automotive Group e
a Motorola os parceiros tecnológicos do consórcio. Diferente da tecnologia CAN, onde
todos os nós da rede possuem o mesmo grau de independência quanto ao uso do

barramento, o padrão LIN possui uma arquitetura mestre-escravo com transmissão
de dados serial. Com uma taxa de 19.200 bauds e apenas um fio compartilhado, a
proposta dessa rede se encaixa no domínio body electronics (espelhos, acessórios,
janelas, etc) uma vez que é mais barata e seus requisitos de largura de banda são
baixos (MATHEUS; KÖNIGSEDER, 2014). Para aplicações onde a largura de banda
e latência não são fatores críticos como aplicações que dependem de redes CAN,
a industria automotiva comumente utiliza redes LIN, reduzindo o custo da linha de
produção.
2.4 FlexRay
A rede FlexRay que está disponível desde 2005, é um barramento serial com-
partilhado que pode chegar a uma taxa de 10Mbps. A mesma foi desenvolvida pelo
consórcio FlexRay, um grupo de fornecedores de semicondutores, de automóveis e de
infraestrutura de rede. O padrão FlexRay possui largura de banda maior que a da rede
CAN, sendo esta uma vantagem em relação a tal tecnologia. Entretanto, a FlexRay
é mais cara e mais complexa das redes intraveiculares, elevando o custo de projetos
exigindo um maior tempo no desenvolvimento e time altamente qualificado. O padrão
FlexRay é usado em domínios automotivos de alta criticalidade como powertrain 1 e
safety (drive-by-wire, adptive cruise control) uma vez que este padrão é considerado o
mais confiável da atualidade (MATHEUS; KÖNIGSEDER, 2014).
2.5 MOST
A tecnologia Media Oriented Systems Transport (MOST) foi disponibilizada em

2001, atualmente é composta por uma arquitetura de rede do tipo anel e pode chegar
a uma taxa de 50Mbps usando fibra ótica ou cabos de cobre. A tecnologia MOST
define a comunicação entre as 7 camadas do modelo ISO/OSI de camadas. De maior
complexidade em sua pilha de protocolos, comparado ao CAN e LIN, é a primeira
tecnologia a possuir funções e serviços que podem ser requisitados durante a operação
do veículo. Esse padrão tem uma largura de banda relativamente alta (no mercado
automotivo), porém tem um custo muito alto. Desta forma, a tecnologia é usada apenas
para câmeras e transmissões multimídia (MATHEUS; KÖNIGSEDER, 2014).
1
Em veículos motorizados, o termo powertrain descreve os principais componentes geradores de
potência e que transmitem esta potência para as rodas proporcinando o deslocamento dos veículos.
Estes incluem o motor, transmissão, eixos de transmissão, diferenciais e rodas. Em modelos híbridos
a bateria, o motor elétrico e o algoritmo de controle da transmissão de potência também são
considerados elementos do Powertrain.
2.6 LVDS
O padrão Low Voltage Differential Signaling (LVDS), definido em 1994, vem

ganhando espaço no mercado automotivo como uma alternativa ao MOST. Diferente-
mente das tecnologias MOST/LIN/FlexRay, o LVDS é um barramento ponto-a-ponto
(não compartilhado). Esse padrão tem um custo muito menor que MOST e muitos
fabricantes estão começando a usá-lo para câmera e dados de vídeo. Por outro lado, a
desvantagem dessa tecnologia é que cada barramento LVDS pode ser usando para
suportar apenas uma saída de câmera ou saída de vídeo (MATHEUS; KÖNIGSEDER,
2014).
2.7 A Caminho da Ethernet Automotiva
Para a próxima geração de arquiteturas de redes intraveiculares, a indústria

automotiva identificou o padrão Ethernet2 como tecnologia bastante promissora para a
comunicação entre ECUs. Ethernet é um padrão IEEE de transmissão de dados bas-
tante utilizado tanto em casas, escritórios, universidades quanto por grandes empresas
de telecomunicações devido ao alto grau de reuso de componentes, abstração, trans-
parência, maturidade, custo e domínio tecnológico. Além disso, o padrão Ethernet
oferece uma largura de banda necessária para as novas tecnologias como Sistemas
Avançados de Assistência ao Condutor (Advanced Driver Assistance System - ADAS),
sistemas de entretenimento e telemetria. No entanto, para o uso real deste padrão em
veículos, a indústria automotiva necessita de grandes esforços técnicos para adaptar
a aplicabilidade desta tecnologia num ambiente hostil quanto às interferências ele-
tromagnéticas, variações de temperatura e constantes impactos mecânicos. Fatores
não menos importantes como escalabilidade, flexibilidade, baixo consumo de potência,
robustez e segurança também estão sendo discutidos na padronização do protocolo
no setor automotivo (MATHEUS; KÖNIGSEDER, 2014).
A necessidade de conectividade, troca de mensagens e largura de banda au-
mentam com a oferta de diferentes e complexas funcionalidades em um veículo, por
exemplo, sistemas de estabilidade e controle, entretenimento e telemetria. Os usuários
desejam encontrar no veículo o mesmo nível de experiência, entretenimento e conecti-
vidade que possuem em suas casas. Tecnologias existentes de redes intraveiculares
como os padrões LIN, CAN e FlexRay não foram projetadas para suprir a crescente
demanda em termos de largura de banda e escalabilidade que são necessárias nos
sistemas ADAS. Tecnologias de rede futuras devem reutilizar padrões e protocolos
2
Ao longo deste trabalho toda e qualquer referência ao termo padrão Ethernet deve ser compreendida
como o padrão IEEE 802.3 definido pelo Instituto de Engenheiros Eletricistas e Eletrônicos (IEEE).
Independentemente da especificação da camada física em questão, o padrão IEEE 802.3 oferece
suporte transparente aos demais serviços definidos em camadas superiores, por exemplo, os serviços
definidos no padrão IEEE 802.1 de redes locais e metropolitanas.
já existentes e utilizados por usuários fora do domínio automotivo, aumentando a

transparência da experiência do usuário na troca de ambientes. Redes intraveiculares
como MOST também oferecem uma alta taxa de transmissão de dados, porém, o
custo de uma solução proprietária para uso em larga escala aumenta drasticamente
(METCALFE et al., 2014).
Diante das inúmeras aplicações e funcionalidades adicionadas aos veículos
ao longo dos anos, diferentes redes intraveiculares foram desenvolvidas, permitindo
a coexistência de diferentes tecnologias e características quanto à transmissão de
dados. Outro importante fator da coexistência dessas redes se da pelo custo total do
veículo produzido, como exemplo, o uso da rede LIN reduz significantemente o custo
de produção, antendendo à aplicações de baixa criticalidade.
Portanto, a arquitetura das redes intraveiculares se apresenta como um sistema
heterogêneo como observado nas Figuras 2.6 e 2.7, característica histórica no projeto
de novas tecnologias para suprir as necessidades temporais dos últimos anos.
Figura 8 – Arquitetura atual da uma rede intraveicular automotiva.

Figura 9 – Coexistência das diferentes redes intraveiculares
Fonte: NXP Semiconductors
Se a arquitetura das redes intraveiculares fosse construída totalmente do zero,

desconsiderando a retrocompatibilidade de tecnologias, a arquitetura se assemelharia
à arquitura do lado direito da Figura 2.8. Nela, as ECUs estão estruturadas de forma
hierárquica, em que os módulos centrais de cada domínio estariam conectados dire-
tamente em um barramento de alta velocidade. O padrão Ethernet oferece suporte a
todos os pré-requisitos para esta construção. A Ethernet seria utilizada como back-
bone3 para conectar as diversas aplicações de diferentes domínios, assim como as
sub-redes que demandam maior largura de banda (MATHEUS; KÖNIGSEDER, 2014).
Atualmente, as redes Ethernet utilizam comunicação ponto a ponto, e são mais eficien-
tes no uso e no gerenciamento da largura de banda disponível na rede, se comparadas
às redes CAN e FlexRay (MATHEUS; KÖNIGSEDER, 2014). O conceito de comutação
de dados pode ser aplicado eficientemente nas interfaces de redes intraveiculares
distintas em um veículo, não sendo necessários encapsulamentos e ordenamento de
pacotes entre estas redes, impactando diretamente na latência das mensagens.
3
Um backbone Ethernet pode ser definido como a principal rota na troca de dados entre imensas redes
de computadores estrategicamente distribuídas para o envio e recebimento de grande massa de
dados. O termo backbone utilizado no contexto de redes intraveiculares diz respeito a um barramento
único de alta capacidade e confiabilidade capaz de interconectar todas as sub-redes de diferentes
tecnologias através de gateways.
Figura 10 – Transição de arquitetura centralizada para uma arquitetura hierárquica através do

uso de gateways/switches (hexágonos) e backbone Ethernet (retângulo superior
central à direita).
O uso do padrão Ethernet em veículos significa uma mudança de paradigma

no projeto das redes intraveiculares do futuro, conectando sub-redes de diferentes
domínios, transportando diferentes tipos de dados com prioridades distintas além
dos desafios em cumprir eficientemente restrições temporais, eletromagnéticas, de
temperatura e mecânicas.
2.7.1 Automotive Ethernet
O padrão Ethernet é um padrão IEEE pertencente à família de padrões IEEE

802 que estuda redes locais e redes metropolitanas, LANs e MANs respectivamente
(IEEE 802.3, 2012). O padrão IEEE 802.3 define as características e comportamento
da camada física e da sub-camada MAC para redes Ethernet com fio. Nas últimas
décadas, o comitê de padronização IEEE 802 definiu diversos modelos de camadas
física iniciando em 10Mbps até 10Gbps.
O padrão 100Base-TX é amplamente utilizado tanto por usuários domésticos
quanto na indústria e foi selecionado como padrão para a nova geração de diagnós-
tico automotivo baseado em IP, definido pelo ISO 13400, que será discutido em detalhes
nas próximas seções (ISO 13400-3, 2011). Como mostra a Figura 2.9, diferentes pro-
tocolos acima da camada de rede também foram definidos para serem utilizados na
indústria automotiva. O grupo-tarefa para Time-Sensitive Networking (TSN), anterior-
mente denominado Audio/Video Bridging (AVB), definiu um conjunto de padrões de alto
nível pertencentes à família IEEE 802. Nos próximos cinco anos, diferentes camadas
físicas compatíveis com o padrão IEEE 802.3 coexistirão, por exemplo BroadR-Reach
e PHYs Gigabit Ethernet. Analogamente, protocolos serão adicionados ou atualizados
para versões mais eficientes.
De forma simplificada, os padrões definidos no grupo-tarefa TSN definem ca-
racterísticas como: temporização e sincronização de mensagens em aplicações com

requisitos temporais, largura fixa de banda reservada para streaming, encaminhamento
e enfileiramento cíclicos, preepção de frame, etc (IEEE 802.1AS, 2011; IEEE 802.1Q,
2011; IEEE 802.1QAV, 2009; IEEE 802.1BA, 2011). Um exemplo prático de redes
TSN são sistemas que utilizam câmeras para transmissão de imagens em tempo real,
auxiliando o condutor a visualizar os pontos cegos do veículo.
A fim de dar continuidade e apoio ao desenvolvimento de tecnologia da Ether-
net Automotiva, um grupo especial de interesse foi formado por empresas de vários
segmentos, unindo esforços em comum chamado One Pair EtherNet Alliance (OPEN
Alliance) para o desenvolvimento de uma nova camada física que atendesse aos re-
quisitos e restrições do hostil ambiente automotivo. Além do esforço comum para o
desenvolvimento da camada física o OPEN Alliance atualmente trabalha na padroni-
zação de componentes e testes utilizando a camada física para Ethernet a 100Mbps
desenvolvida pela Broadcom, conhecida como BroadR-Reach (Broadcom Corporation,
2014). Outro importante interesse do OPEN Alliance é a definição dos requisitos para
futuras tecnologias como o Reduced Pair Gigabit, onde esforços estão sendo tomados
para a aplicabilidade do barramento Ethernet a 1Gbps em redes intraveiculares (BRO-
ADCOM CORPORATION, 2013).
De acordo com as estimativas da consultoria fornecida pela Frost & Sullivan,
aproximadamente 400 milhões de portas Ethernet automotivas serão utilizadas até
2020. Em 2022, é esperado que o número total de portas Ethernet automotivas seja
maior que todas as outras portas Ethernet existentes somadas. Ethernet automotiva
não se destina apenas para o mercado de luxo, tendências indicam que a significante
maioria dos fabricantes de automóveis planejam utilizar o barramento Ethernet em
todas as suas classes e linhas de veículos. A BMW é a pioneira quanto à adoção
da tecnologia (BMW, 2015), influenciando outras montadoras à seguirem o mesmo
caminho nesta “corrida tecnológica” automotiva já que é possível observar exemplos
como a Hyundai ao utilizar a Ethernet automotiva nos sistemas de entretenimento em
seus próximos lançamentos e a Volkswagen nos Sistemas Avançados de Assistência
ao Condutor (Advanced Driver Assistance System - ADAS).
Figura 11 – Automotive Ethernet Roadmap.
Como o padrão Ethernet não foi desenvolvido para redes TDMA, uma impor-
tante questão que necessita ser discutida para sistemas automotivos é uma solução
adequada para se alcançar um desepenho de tempo real e qualidade do serviço (QoS).
Redes Time-Sensitive Networking (TSN) como o AVB já possuem mecanismos para a
garantia temporal da entrega em canais de transmissão de dados sobre Ethernet. Para
o grupo-tarefa TSN, a melhoria da latência é um dos maiores desafios de execução. As
primeiras aplicações Time-Sensitive para Ethernet foram realizadas em sistemas digi-
tais aeronáuticos com requisitos temporais de altíssima criticidade e severos requisitos
de segurança (TILL STREICHERT; DAIMLER AG, 2012).
Definido no (SAE AS6802, 2011), diferentemente do AVB, Time-Triggered Ether-
net (TTEthernet) foi desenvolvido sobre um algoritmo distribuído para a sincronização
dos clocks da rede, resultando em um algoritmo preciso de comportamento determinís-
tico. Embora a integração entre TTEthernet e AVB seja possível, pesquisas ainda são
necessárias para permitir esta integração no sistema crítico automotivo, já que dados
de entretenimento, controles de tempo real assim como informações de diagnóstico
seriam transmitidos utilizando a mesma rede (STEINBACH et al., 2012).
2.7.1.1 Primeira Geração: Diagnostic Communication over IP
As primeiras aplicações Ethernet na indústria automotiva são execuções de

rotinas de diagnóstico e atualizações de firmware de ECUs através deste barramento. A
largura de banda para a transmissão de grandes volumes de dados através das redes
intraveiculares existentes é um fator limitante, não sendo suficiente para os requisitos

de produção exigidos pela indústria. Em (ELEKTROBIT GMBH, 2008), engenheiros
analisaram o tempo de transmissão e atualização da quarta e quinta geração do BMW
Series 7. A quarta geração utiliza CAN como barramento principal para a transmissão
de diagnósticos e atualizações de ECUs, já a quinta geração utiliza o padrão Ethernet
para ambas as funcionalidades. Foi observado que para o BMW Series 7 de quarta
geração foram necessárias dez (10) horas para a transmissão e instalação de oitenta
e um (81) megabytes de dados, enquanto o BMW Series 7 de quinta geração utilizou
apenas vinte (20) minutos para a transmissão e instalação de um (1) gigabyte de dados.
O padrão Ethernet 100Base-TX juntamente com o padrão de cabo CAT 5 e conector
RJ45 foram eleitos para definirem a interface entre o veículo e o equipamento de
diagnóstico externo. A grande largura de banda disponível da tecnologia Ethernet reduz
custos tanto na produção quanto na manutenção (MATHEUS; KÖNIGSEDER, 2014).
Os padrões (ISO 13400-1, 2011) e (ISO 14229-1, 2013) usam padrões da indústria para
construir um modelo a longo prazo, moderno, estável e escalável para diagnósticos
veiculares. Hoje os carros da BMW já oferecem suporte à interface de diagnósticos
através do padrão Ethernet 100Base-TX.
2.7.1.2 Segunda Geração: Driver Assistance Systems e Entretenimento
A segunda geração da Ethernet Automotiva oferecerá soluções robustas para os

sistemas de entretenimento e câmeras acopladas ao carro para sistemas ADAS. Atual-
mente, câmeras traseiras normalmente utilizam a tecnologia LVDS para a transmissão
do vídeo, sendo o LVDS uma tecnologia adequada para o uso de apenas uma câmera
(DILLON, 2003). Nos sistemas futuros, mais câmeras serão utilizadas em conjunto com
os sensores de proximidade, como mostrado na Figura 2.10, proporcionando maior
segurança e comodidade ao condutor. A tecnologia LVDS se torna bastante ineficiente
quanto ao uso de cabos de transmissão, conectores e multiplexadores de sinal, favore-
cendo o uso do padrão Ethernet para a transmissão, sincronização e processamento
das imagens. Tal ineficiência ocorre pela característica técnica do padrão ao utilizar um
barramento não compartilhado, sendo necessário o uso de cabos individuais de alto
custo para cada câmera. O uso de uma rede que ofereça maior largura de banda e me-
nor latência garantirá a detecção de objetos através do processamento de imagens de
múltiplas câmeras acopladas ao carro requer uma transmissão não compactada, sem
perdas, evitando assim que informações importantes sejam perdidas ou mascaradas
devido à compressão.
Grande parte das soluções de entretenimento utilizam protocolos e barramentos
proprietários e de alto custo; o uso da Ethernet automotiva, portanto, contribui signifi-
cativamente para a redução de custos, utilizando o protocolos TSN para transmissão,
sincronização e baixas latências já demonstradas em componentes de primeira geração
do AVB.
Figura 12 – Uso conjunto de câmeras, radar e sensores de proximidade.
2.7.1.3 BroadR-Reach
Embora o padrão 100Base-TX e o modelo IP tenham sido criados desde meados

dos anos 90, mais de vinte anos foram necessários para atrair a atenção da indústria
automotiva para o uso da Ethernet como padrão de comunicação das redes intravei-
culares do futuro, principalmente pela falta de uma camada física capaz de atender
aos requisitos do ambiente automotivo. A Figura 2.11 ilustra as diferenças técnicas,
evidenciando o uso da Fast Ethernet e da Gigabit Ethernet não foram aplicados ao
domínio automotivo. Fast Ethernet utiliza o esquema de codificação de sinal MLT-3,
diferenciando 3 níveis de sinais: positivo, nulo e negativo (MAZZOLA; CAFIERO; DE-
NICOLO, 1994). Utiliza dois pares trançados para comunicação, cada par transmite
dados em apenas uma direção. Gigabit Ethernet alcança uma taxa de transmissão
de dados dez vezes maior que o Fast Ethernet, utilizando quatro pares trançados e
codificação de sinal PAM-5 (SCHREIBER, 2004).
Modulação por amplitude de pulso (PAM) é uma técnica de modulação de sinal
onde a informação é codificada na amplitude de pulsos de sinais elétricos. Os sinais são
transmitidos de forma analógica em séries de pulsos elétricos temporais de diferentes
amplitudes. A demodulação ocorre periodicamente pra cada pulso recebido de acordo
com a amplitude do sinal. Por exemplo, PAM-3 e PAM-5 utilizam respectivamente três e
cinco diferentes níveis de amplitudes elétricas ao transmitirem informações.
O valor da taxa de transmissão a 125MBaud para ambas Fast e Gigabit Ethernet
contribui significantemente para a emissão de ruídos eletromagnéticos na faixa crítica
de rádio FM eliminando a possibilidade do uso de pares trançados não blindados de
baixo custo no ambiente automotivo. A tecnologia BroadR-Reach foi capaz de reduzir

a taxa para 66.6 Mbaud possibilitando o uso de um par trançado não blindado para a
transmissão confiável de dados. A princípio, o BroadR-Reach pode ser considerado
uma versão reduzida do Gigabit, utilizando uma codificação bidirecional em apenas
um par trançado. Graças ao uso da codificação de sinal PAM-3, uma taxa de erros de
transmissão de bits menor que 10−10 pode ser alcançada.
Figura 13 – Diagramas de codificação do padrão Ethernet e do BroadR-Reach.
Aplicações automotivas impõem requisitos consideravelmente mais rígidos em

sistemas eletrônicos e seus componentes, quando comparadas às aplicações domésti-
cas, principalmente em termos de EMC (Compatibilidade Eletromagnética) e condições
ambientais (ISO 11452-1, 2015). Investigações iniciais indicam que BroadR-Reach é
compatível para o uso no ambiente automotivo. Entretanto, para alcançar a robustez
necessária para os padrões de redes intraveiculares da próxima geração, novos compo-
nentes otimizados precisam ser desenvolvidos por exemplo, camada física automotiva
para Gigabit Ethernet.
O diagrama elétrico na Figura 2.12 revela os principais componentes de um
enlace de conexão do BroadR-Reach. Comparado com o padrão Fast Ethernet, o preço
total dos componentes pode ser significativamente reduzido. Aplicando um acoplamento
capacitivo no lugar de um transformador convencional, a estrutura de hardware utilizada
na camada física – que consiste do controlador TJA1100 (PHY), common mode choke
(CMC)4 , capacitores de acoplamento, conector e o par trançado não blindado (UTP) –
é muito similar à do FlexRay ou CAN.
4
Em eletrônica, um choke é um indutor (bobina) utilizado no bloqueio de correntes alternadas de
alta frequência em circuitos elétricos, permitindo a passagem apenas de correntes alternadas de
Figura 14 – Componentes físicos da conexão BroadR-Reach.
O controlador TJA1100(PHY), sendo a interface entre o meio de transmissão

analógico e o controlador MAC digital, é determinante na robustez contra ruídos
eletromagnéticos. Enquanto um controlador PHY é otimizado para ser compatível
com comprimentos de cabeamento de mais de 100 m, controladores PHY automotivos
tipicamente utilizam um comprimento de enlace de menos de 10 metros.
Com a tecnologia BroadR-Reach permitindo o uso de cabos de pares trançado
não blindados, a Ethernet torna-se competitiva financeiramente para aplicações au-
tomotivas. O cabo utilizado pelo FlexRay suporta as condições severas do ambiente
automotivo e é também a primeira escolha para a Ethernet Automotiva. Em contraste
com as aplicações não automotivas, um estudo cuidadoso do impacto das condições do
ambiente (principalmente temperatura) sobre a integridade do sinal Ethernet é preciso.
2.7.1.4 Terceira Geração: Ethernet como Backbone
Enquanto na primeira e segunda geração a Ethernet é utilizada em sub-redes

para o uso em aplicações específicas de ADAS e entretenimento, na terceira geração o
padrão Ethernet será utilizado como backbone da rede intraveicular. Um exemplo do
uso da Ethernet como backbone é mostrado na Figura 2.13. O uso de um backbone
Ethernet em redes intraveiculares representa uma mudança de paradigma na forma da
arquitetura de comunicação entre ECUs. A rede de comunicação será organizada de
forma hierarquizada onde os principais módulos de cada domínio estão conectados
diretamente ao backbone. Sub-redes localizadas abaixo dos controladores de cada
domínio também podem ser Ethernet onde switches serão responsáveis pela troca de
dados entre a sub-rede e o backbone. Esta estrutura oferece uma solução escalável já
que cada porta do switch geralmente pode ser implementada para taxas de transmissão
variando entre 10Mbps, 100Mbps e 1Gbps sem mudanças nos protocolos das camadas
acima.
A mudança de paradigma também se torna evidente na forma como as mensa-
gens entre diferentes tecnologias serão transmitidas, por exemplo, enquanto nas redes
atuais complexos gateways de aplicação específica realizam esta função, switches e
baixa frequência ou correntes contínuas. Common-mode chokes são quando dois chokes (bobi-
nas) separados são envoltos no mesmo núcleo ferroso. São bastante úteis na proteção dos circuitos
contra interferências eletromagnéticas (EMI) e interferências de radiofrequência (RFI) advindas de
fontes de tensão.
roteadores já conhecidos e estabelecidos são propostos na interface com o backbone e

sub-redes. O uso do roteamento IP é totalmente independente das camadas inferiores
da rede, permitindo assim um conceito de endereçamento homogêneo em toda a
rede intraveicular. Além disso, o modelo baseado em IP permite o estabelecimento
transparente de rotas entre a rede intraveicular e a Internet (METCALFE et al., 2014),
facilitando o acesso a serviços remotos como por exemplo a execução de diagnósticos
remotamente.
Figura 15 – Padrão Ethernet como backbone da arquitetura de rede intraveicular.
Fonte: NXP Semiconductors.
2.7.2 Autosar
AUTOSAR ou Automotive Open System Architecture é uma iniciativa de padro-

nização liderada por fabricantes e fornecedores automotivos. Fundada em 2003, o
intuito desta iniciativa é o desenvolvimento de uma arquitetura de software referência
para ECUs, reduzindo a complexidade no desenvolvimento de novas funcionalidades
adicionadas nos firmwares das ECUs.
O AUTOSAR define um conjunto de especificações descrevendo os módulos
básicos de software, as interfaces das aplicações e propondo uma metodologia comum
no desenvolvimento baseado na padronização de software favorecendo o reuso. Esses
módulos são disponibilizados pela arquitetura de software em camadas da AUTOSAR,
como mostra a Figura 2.14, e podem ser usados em veículos de diferentes fabricantes
e também em componentes eletrônicos de diversos fornecedores, assim reduzindo
os custos de pesquisa e desenvolvimento, além de controlar o crescente aumento da
complexidade da eletrônica automotiva e das arquiteturas de software (SCHMERLER
et al., 2012; HEINECKE et al., 2006; FENNEL et al., 2006).
Figura 16 – Arquitetura AUTOSAR.
Fonte: AUTOSAR, 2015.
Com base nesses princípios, o AUTOSAR foi desenvolvido com o objetivo de

incentivar sistemas eletrônicos inovadores que aumentem o desempenho, segurança
e contribuam na redução de emissões, além de facilitar a troca e atualização de
software e hardware durante toda a vida útil do veículo. Assim, o AUTOSAR abstrai as
funcionalidades do hardware das ECUs, estando assim preparado para as próximas
tecnologias e para a melhoria do custo-benefício. Desde sua fundação, essa parceria
publicou diversas versões como resultado das atividades de desenvolvimento conjuntas.
Com a versão 2.1 no fim da Fase I em 2006, o AUTOSAR finalizou o primeiro conjunto
das principais especificações. Já na fase II, as versões 3.0 e 3.1 introduziram adições
e ajudaram a amadurecer estes documentos. A versão 4.0 foi apresentada com um
grande número de novos recursos em 2009, sendo a versão 4.2.2 a mais recente,
lançada em 2015 com a introdução de novos conceitos como o módulo de segurança de
comunicação onboard - SecOC. As fases e versões de desenvolvimento do AUTOSAR
são exibidos no cronograma da Figura 2.15.
Figura 17 – Cronograma AUTOSAR.
2.8 On-board Diagnostics
Com a introdução de uma legislação específica para o controle e monitora-

mento de emissões de CO2 em veículos à combustível fóssil, protocolos digitais de
comunicação para diagnósticos intraveiculares foram desenvolvidos para atender às
demandas governamentais favorecendo o bem-estar e a proteção ao meio ambiente.
Tais protocolos evoluíram ao longo dos anos com a adição de novas funcionalidades
desde o diagnóstico do monitoramento de emissões até funcionalidades específicas de
cada fabricante automotivo como calibração ou atualizações de software da ECU.
Devido à constante adição de novas tecnologias nas redes intraveiculares, a
interface física entre as unidades de controle eletrônicas internas ao veículo e equipa-
mentos de testes externos sofreu diversas modificações para atender as características
específicas de cada barramento intraveicular, exigindo otimizações e refinamentos cons-
tantes na camada física e de enlace como também na camada de transporte. Essas
modificações e atualizações trazem à indústria automotiva maior controle no gerencia-
mento das informações digitais transmitidas através das mensagens de diagnóstico,
consequentemente, maior eficiência em sua produtividade.
Como apresentado no Capítulo 2 deste trabalho, o aumento das funcionalidades
presentes nas ECUs e a necessidade de diversas atualizações de software para suprir a
demanda destas funcionalidades, trouxe uma significativa complexidade na arquitetura

e organização das redes intraveiculares. A necessidade destas redes se comunicarem,
entre diferentes tecnologias, através de gateways e a introdução de aplicações x-by-
wire5 e de entretenimento acarretaram num alto uso da largura de banda do barramento
ao qual estão associados e em tempo real, como por exemplo FlexRay e MOST.
As informações de diagnóstico das ECUs nos veículos são de grande impor-
tância para indústria automotiva, tanto para o estudo do ciclo de vida de diversos
componentes, análise de comportamento em diferentes situações até para o próprio
desenvolvimento de novos módulos face aos resultados obtidos anteriormente. Através
dos serviços de diagnóstico, o estado dos componentes e sistemas podem ser moni-
torados a fim de detectar e prevenir falhas ocasionais, aumentando a disponibilidade
operacional do sistema e reduzindo o custo do suporte ao cliente.
Em veículos em fase de pré-lançamento, os serviços de diagnóstico são cruciais
para a fase de testes e validação do funcionamento do veículo assim como para a de-
tecção de problemas o mais cedo possível em sua fase de desenvolvimento, prevenindo
que falhas graves não passem despercebidas na etapa de produção. No pós-vendas, os
serviços de diagnóstico pertencem ao importante processo de manutenção, sendo os
Códigos de Falhas de Diagnóstico ou Diagnostic Trouble Code (DTC) frequentemente
lidos dos veículos dos clientes durante uma visita ao centro de manutenção para a
revisão do carro, por exemplo, verificando assim possíveis falhas registradas após a
compra do veículo.
Para aumentar a satisfação do cliente e a confiabilidade da marca, os fabri-
cantes automotivos dependem dos sistemas de diagnóstico, pois tornam o serviço de
manutenção menos complexo para os mecânicos e facilitam o descobrimento rápido e
automatizado de falhas nos sistemas eletrônicos de alta complexidade. Dessa forma,
o software de verificação de falhas envia todo o registro de cada veículo através da
Internet, mapeando em todo o mundo as estatísticas das falhas, DTCs, auxiliando em
uma rápida ação para a descoberta da origem da falha e de possíveis correlações das
falhas com o projeto automotivo de cada modelo e correlações entre diferentes falhas.
Porém, o modelo de envio ainda utilizado no Brasil basea-se na transmissão de dados
apenas via OBD-II sempre que o veículo é levado à concessionária, logo não sendo
possível a transmissão através de redes sem fio.
5
X-by-wire é uma generalização que referencia sistemas que anteriormente eram puramente mecâni-
cos, por exemplo, aceleração e transmissão, e atualmente são controlados em sua totalidade por
sistemas eletrônicos.
2.9 Acesso Remoto ao Diagnóstico Veicular
A grande proliferação de redes de comunicação sem fio, dispositivos móveis,

sistemas de telemetria e serviços possibilitaram o uso da infraestrutura já existente
capaz de ser integrada ao sistema remoto de diagnóstico veicular, não sendo neces-
sário o acesso físico ao veículo. Atualmente, serviços de telemetria para diagnósticos
intraveiculares são principalmente utilizados durante a fase de testes e validação de
carros em fase de desenvolvimento, porém o diagnóstico remoto também pode ser
encontrado no pós-vendas de carros premium, para melhor suporte e manutenção
(HIRAOKA, 2009). A próxima geração de veículos trará dispositivos a bordo de alta
sofisticação para conectividade, oferecendo conexões 4G, 5G e Wi-Fi podendo ser utili-
zados para entretenimento, navegação e demais serviços. Tal funcionalidade permitirá
a realização em larga escala de serviços de diagnóstico, coletando dados diretamente
das ECUs, algo nunca executado pela indústria automotiva. Além do mais, esta tec-
nologia permitirá diferentes serviços no pós-vendas criando oportunidades e novas
demandas como, por exemplo, o uso de mensagens de diagnóstico por seguradoras
para a avaliação do perfil do condutor.
2.10 Diagnóstico Automotivo Integrado
Dada a importância dos sistemas de diagnóstico automotivo tanto para as fabri-

cantes quanto para os consumidores e por diversas fases como no desenvolvimento e
no pós-vendas, um framework para captura, análise e gerenciamento de mensagens
de diagnóstico é claramente desejado.(CAMPOS; MILLS; GRAVES, 2002) argumenta
que gerações anteriores de sistemas de diagnóstico não possuíam a devida integração
entre serviços, resultando em esforço duplicado e trabalhos desnecessários no desen-
volvimento de diferentes aplicações para diagnóstico intraveicular, onde cada aplicação
possuía sua própria estrutura, componentes e software sem a devida padronização.
Isso leva à ineficiência do uso de recursos e alto custo no desenvolvimento e manuten-
ção de aplicações. Por essa razão, a construção de sistemas de diagnóstico deve ser
basear em padrões industriais para a comunicação e interfaces de integração, sendo
o software de diagnóstico apenas um componente modular da arquitetura definida,
possibilitando o correto reuso de componentes de software e a interoperabilidade entre
diferentes componentes da arquitetura do sistema.
O diagnóstico automotivo possui uma longa história de esforços quanto à padro-
nização, incentivados pela indústria e governo através das legislações. O On-Board
Diagnostics – OBD-II é talvez o esforço mais conhecido e mais importante até hoje, foi
criado nos anos 80 pela agência americana California Air Resource Board – CARB, e
em 1996 o OBD-II se torna obrigatório em todo carro produzido para ser vendido nos
Estados Unidos. No Brasil, o padrão se tornou obrigatório apenas em 2010, no entanto
é possível encontrar facilmente vários modelos anteriores a 2010 com a presença da

interface de diagnósticos OBD-II, como visualizado na Figura 2.16.
Em uma iniciativa técnica para maior controle de emissões, a Organização
das Nações Unidas - ONU uniu esforços para a padronização de um novo framework
chamado World Wide Harmonized On-Board Diagnostics – WWH-OBD em 2005, com
o objetivo de eliminar regras para controle de emissão regionais sendo substituídas por
um padrão de controle mundial comum. Este novo padrão representa um grande salto
no controle e diagnóstico automotivo por utilizar tecnologias e protocolos que definem
uma nova interface de comunicação, permitindo diferentes aplicações e serviços se
comunicarem com os sistemas de emissão e diagnósticos intraveiculares. Seu uso se
tornou obrigatório na União Europeia desde 2013 para o registro novos veículos de
passeio e 2014 para o registro de novos veículos pesados à diesel.
Figura 18 – Porta OBD-II.
2.11 Diagnostics Communication over IP
Um dos resultados da iniciativa WWH-OBD da ONU foi a escolha do uso do pro-

tocolo IP para troca de informações entre agentes externos e sistemas de diagnóstico
intraveiculares. Para este propósito o protocolo ISO 13400 – Diagnostic Communication
over IP foi padronizado pela Organização Internacional de Padronização – ISO.
De acordo com (ISO 13400-1, 2011), a fim de tornar o acesso unificado e
transparente às informações através de um agente externo, o ISO 13400 – Diagnostic
Communication over IP destina-se a descrever e definir uma interface padronizada de

comunicação que:
• Isole transparentemente todas as tecnologias de redes intraveiculares das

interfaces de comunicação de equipamentos externos destinados a acessar
as informações do veículo, permitindo o uso contínuo e estável a longo prazo
diminuindo a interdependência técnica entre os domínios interno e externo;
• Utilize padrões industriais de protocolos comunicação e conectores, garantindo

o uso estável, comum e de longo prazo através de tecnologias em seu estado
da arte para a troca de mensagens de diagnóstico como também mensagens
proprietárias específicas a cada fabricante;
• Seja transparente e facilmente adaptável à diferentes camadas físicas e de en-

lace, incluindo comunicações com e sem fio através de adaptadores e gateways
preexistentes.
Apesar de inicialmente o padrão ter sido proposto apenas para sistemas de di-
agnóstico intraveiculares, o ISO 13400 possui também a capacidade de atuar como um
protocolo genérico da camada de transporte e de rede, camadas 4 e 3 respectivamente,
em sistemas de redes IP. O padrão (ISO 14229-1, 2013; ISO 14229-2, 2013) Unified
Diagnostic Services (UDS) e o (ISO 27145-2, 2012; ISO 27145-3, 2012) World-Wide
Harmonized On-Board Diagnostics (WWH-OBD) são os principais padrões que definem
a estrutura da mensagem de diagnóstico, já que o DoIP apenas especifica os requisitos
necessários para o transporte das mensagens.
Em outras palavras, o padrão Diagnostics Communication over IP pode ser -
DoIP pode ser caracterizado da seguinte forma:
• DoIP é um encapsulamento de mensagens de diagnóstico definidas na camada

de aplicação, por exemplo (ISO 14229-1, 2013) e (ISO 14229-5, 2013), para
serem transmitidas através do padrão Ethernet entre o veículo e o equipamento
de diagnóstico. DoIP não define mensagens de diagnóstico, apenas containers
para o transporte dessas.
• O padrão da troca de mensagens através do protocolo DoIP é definido nas

camadas de rede e transporte do modelo OSI. Portanto, o DoIP não depende
de protocolos da camada de aplicação para o seu funcionamento.
• Por utilizar o barramento Ethernet, 100Base-TX, alcança taxas de transmissão

até duzentas (200) vezes mais rápidas que o padrão CAN - 500kbps.
• A interface do protocolo DoIP no veículo continuará sendo através da porta

OBD-II, onde numa ponta do cabo usa-se o conector RJ45 e na outra ponta o
conector macho OBD-II.
• O gateway de diagnóstico presente dentro do veículo implementa a troca de

mensagens de diagnóstico tanto utilizando o DoIP - UDSonIP (ISO 14229-5,
2013) como protocolo de transporte baseado em Ethernet, quanto mensagens
de diagnóstico sobre o protocolo CAN - UDSonCAN (ISO 14229-3, 2012).
51
3 DESCRIÇÃO DO SISTEMA EM ANÁLISE
Neste capítulo, uma análise minuciosa das ameaças e vulnerabilidades em

sistemas de comunicação de diagnósticos é realizada. Ameaças e vulnerabilidades her-
dadas da pilha TCP/IP que afetam diretamente ou indiretamente o DoIP são discutidas.
Por fim, as vulnerabilidades e ataques do próprio protocolo ISO 13400 são analisadas,
assim como as consequências destas.
Na Figura 3.1 abaixo, os protocolos utilizados para o diagnóstico automotivo
especificamente sobre IP são organizados de acordo com a camada de atuação de
acordo com o Modelo OSI. A documentação do padrão ISO 13400 se divide em
4 partes:
• (ISO 13400-1, 2011) contém informações gerais do protocolo e define os casos

de uso que são aplicáveis ao diagnóstico automotivo.
• (ISO 13400-2, 2012) descreve os serviços necessários das camadas de trans-

porte e de rede, definindo o encapsulamento de mensagens da camada de
aplicação, identificadores de mensagens, etapas e características no estabeleci-
mento da conexão, protocolos da suite TCP/IP, etc.
• (ISO 13400-3, 2011) e (ISO 13400-4, 2016) especificam os requisitos da camada

física e da camada de enlace, baseados no padrão (IEEE 802.3, 2012) e no
conector (ISO 15031-3, 2016).
Capítulo 3. DESCRIÇÃO DO SISTEMA EM ANÁLISE 52
Figura 19 – Modelo OSI e o padrão DoIP comparado ao padrão de diagnósticos sobre CAN.
3.1 Método de Análise
A metodologia de análise aplicada neste trabalho é um subconjunto do método

da análise de ameaças, vulnerabilidades e riscos definido pelo Instituto Europeu (ETSI,
2010; ETSI, 2011; MBIYDZENYUY; PERSSON; DAVIDSSON, 2012). Inicialmente o
método de análise completo será apresentado e em seguida as etapas não realizadas
neste trabalho. Este método pode ser brevemente resumido da seguinte forma: o alvo
de análise ou Target of Evaluation (ToE) é identificado com os componentes a serem
protegidos juntamente com os objetivos da análise. Os objetivos de segurança são
então identificados e classificados levando em consideração cinco atributos de segu-
rança: confidencialidade, integridade, disponibilidade, autenticidade e resposabilização.
Esses objetivos de segurança são então utilizados para a definição dos requisitos de
segurança funcionais, em seguida um registro de componentes a serem protegidos é
feito.
Possíveis vulnerabilidades são então identificadas e classificadas seguidas
das correspondentes ameaças e dos resultados não desejados. Tais ameaças são
classificadas baseadas nas seguintes quatro categorias: interceptação, manipulação,
negação de serviço e rejeição. Por fim, um conjunto de mecanismos de segurança é
gerado e uma análise é realizada a fim de selecionar os mecanismos mais adequados

para a redução dos riscos correspondentes às ameaças identificadas. O resultado final,
portanto, é utilizado para o desenvolvimento de serviços de segurança.
Quatro etapas foram omitidas neste trabalho, sendo elas: requisitos funcio-
nais de segurança, a probabilidade de ameaças ocorrerem, os riscos e a análise do
custo-benefício. Os requisitos funcionais são de certo modo uma especificação mais
detalhada os objetivos de segurança, descrevendo como um certo objetivo de segu-
rança deve ser executado, por exemplo, o controle de acesso deve ser implementado
utilizando um nome de usuário e senha para validação. O intuito deste trabalho é uma
análise mais abrangente, portanto, eliminam-se os quatro itens acima descritos, não
sendo de interesse do autor deste trabalho calcular quaisquer probabilidades e riscos
para as diferentes ameaças e vulnerabilidades.
3.2 Agentes de Comunicação da Rede
Os agentes de comunicação presentes nos centros de manutenção automotiva

serão chamados neste trabalho de equipamento externo de testes, equipamento de
diagnóstico ou tester. Esta é a unidade eletrônica utilizada para enviar requisições
e mensagens de diagnóstico aos veículos sob casos de testes específicos. Isto é,
o equipamento de diagnóstico envia ao veículo um pedido de diagnóstico e espera
por uma resposta com os dados requisitados pela mensagem enviada pelo tester. O
equipamento externo de diagnóstico, tester, é um dispositivo com capacidade de
processamento suficiente capaz de interpretar e enviar quaisquer mensagens do
protocolo DoIP, obedecendo todos os requisitos técnicos e temporais definidos no (ISO
13400-2, 2012).
O segundo agente de comunicação da rede é o veículo que está submetido ao
procedimento de diagnóstico. O módulo do veículo que diretamente recebe e processa
as mensagens de diagnóstico enviadas pelo tester é chamado de DoIP edge node. O
DoIP edge node é apenas uma definição lógica da Unidade de Controle de Comunica-
ção (CCU), dispositivo que atua como gateway entre todas as comunicações entre as
redes intraveiculares e dispositivos externos através da porta OBD-II.
3.3 Arquitetura da Rede DoIP
Na Figura 3.2, um exemplo da descrição lógica da rede DoIP é mostrado. Nos

dois quadros mais externos, as redes intraveiculares e a rede do equipamento de
diagnóstico são representadas. Na rede intraveicular, diversos nós estão conectados
à rede diretamente e indiretamente, alguns compatíveis com o protocolo DoIP outros
não. Cada sub-rede intraveicular possui um gateway responsável pela conversão de
mensagens entre protocolos, permitindo que diferentes tecnologias se comuniquem.

Um backbone Ethernet é utilizando para conectar todos os gateways presentes na rede,
sendo compatíveis ou não com o protocolo ISO 13400-1 (2011).
O principal e único dispositivo que interage com as redes internas e redes
externas ao veículo é denominado DoIP edge node, gerenciando o estabelecimento de
conexões entre equipamentos de diagnóstico, envio e transmissão de dados entre as
duas grandes redes. A linha de ativação definida no ISO 13400-2 (2012) é uma funcio-
nalidade da interface Ethernet específica para o gerenciamento de energia do gateway
DoIP e diminuição de emissões eletromagnéticas. Os outros nós conectados à rede
fisicamente não estão aptos a utilizar o protocolo DoIP para a troca de mensagens de
diagnóstico, apenas mensagens do protocolo TCP/IP usualmente conhecidas. Podem
ser, por exemplo, computadores e servidores da rede local da central de manutenção.
O DoIP Edge Node é também capaz de se conectar diretamente à sub-redes
intraveiculares, pois este atua como gateway na conversão e encapsulamento de
pacotes de diferentes tecnologias.
É importante destacar que as redes baseadas em IP mostradas na Figura 3.2
podem ser quaisquer tipos de rede IP, sendo estas cabeadas ou sem fio.
Figura 20 – Arquitetura da rede de diagnóstico.
ISO 13400-1.
3.4 Características da Camada Física e Camada de Enlace
O padrão DoIP não impõe muitas restrições quanto à camada de enlace e

camada física. Logo, as tecnologias aqui abordadas são padrões utilizados pela in-
dústria previamente estabelecidos e que atendem aos requisitos dos casos de uso
na Seção 4.7. A seguir as características de segurança serão analisadas quanto aos
padrões utilizados. É importante notar que, em uma das possíveis topologias descritas
no (ISO 13400-1, 2011), consiste no uso de apenas um cabo Ethernet, enquanto as
outras topologias consistem de múltiplas conexões físicas, podendo essas utilizarem
tecnologias de transmissão sem fio.
Para conexões com e sem fio, as características de segurança são significante-
mente diferentes entre as duas tecnologias de conexão(HOUSLEY; ARBAUGH, 2003).
O cabo Ethernet é em essência um meio privado na transmissão dos dados, há exem-
plos de monitoramento de dados através da medição da radiação eletromagnética
emitida pelo cabo, quando não blindado, mas que é um caso extremo não considerado
neste trabalho (PFLEEGER; PFLEEGER, 2002). Considera-se que toda a infraestru-
tura física está sob supervisão, eliminando a possibilidade de inserção de dispositivos
externos ou alterações físicas na estrutura.
Diferentemente da transmissão através do cabo Ethernet, a Wireless LAN
(WLAN) é essencialmente uma transmissão aberta, desconsiderando mecanismos
lógicos de proteção como criptografia. Portanto, mensagens podem ser monitoradas e
alteradas através de dispositivos dentro do raio de alcance da transmissão. Existem três
formas básicas para a proteção às redes Wi-Fi, sendo estas: Wired Equivalent Privacy
(WEP), Wi-Fi Protected Access (WPA) e Wi-Fi Protected Access II (WPA2). Destas,
o WEP é considerada insegura e o WPA vulnerável a ataques de dicionários. Imple-
mentações do WPA e do WPA2 utilizando o Protocolo de Integridade de Chave (TKIP)
para criptografia da conexão também possui vulnerabilidades conhecidas (BITTAU;
HANDLEY; LACKEY, 2006; LASHKARI; DANESH; SAMADI, 2009).
O uso do Padrão Avançado de Criptografia (AES) com o WPA2 é a forma mais
segura e recomendada para o controle de acesso à redes Wi-Fi (LASHKARI; DANESH;
SAMADI, 2009). No entanto, mecanismos de segurança em camadas superiores devem
ser empregados para mitigar outros tipos de possíveis ataques às redes de diagnóstico.
3.5 Características da Camada de Rede e Camada de Transporte
Esta seção descreve quais protocolos são usados na camada de rede e na

camada de transporte, apresentando brevemente as características de transmissão
nestas camadas. Uma descrição detalhada pode ser encontrada na segunda parte da
documentação do padrão DoIP, (ISO 13400-2, 2012).
O protocolo da camada de rede utilizado para transmissões de mensagens de

diagnóstico é o Internet Protocol (IP). DoIP possui suporte para ambas as versões,
IPv4 (IETF, 1981a) e IPv6 (IETF, 1998), sendo a última recomendada como padrão do
protocolo. No entanto, IPv4 é mantido por razões de compatibilidade e fácil integração
em redes já existentes. Algumas características do IP, independentemente de sua
versão, que impactam em questões de segurança são:
• Troca de dados pública: qualquer um pode acessar, monitorar e utilizar a rede,

assim como dados podem ser facilmente injetados e manipulados em conexões
não seguras.
• Pacotes podem ser descartados ou perdidos. Em qualquer ponto da rede,

pacotes podem ser perdidos ou simplesmente descartados.
• Pacotes podem ser entregues fora da ordem em que foram enviados.
• Pacotes podem ser entregues intencionalmente modificados já que a validação

do checksum atua apenas em casos onde bits foram alterados aleatoriamente
devido a ruídos na transmissão.
• Não existem deadlines, limites de atraso ou de jitter. Os atrasos podem ser

infinitamente longos, variar indefinidamente diversas vezes.
DoIP utiliza os dois principais protocolos atualmente utilizados para a camada de

transporte em redes Ethernet, o Transmission Control Protocol (TCP) (IETF, 1981b) e
o User Datagram Protocol (UDP) (IETF, 1980), para diferentes serviços do padrão. O
TCP oferece entrega ordenada e confiável de pacotes, dentre outras características.
Diferentemente do TCP, o UDP não oferece garantia de entrega em transmissões de
dados. Como sua complexidade é bem menor que a do TCP é também mais agressivo,
rápido e, portanto, comumente utilizando quando o tempo de entrega é mais importante
que a entrega em si.
Na comunicação DoIP, o protocolo UDP é basicamente utilizado apenas para
mensagens de identificação enquanto o TCP é utilizado para o transporte de mensa-
gens de rota e diagnóstico. Os tipos de mensagens utilizados no DoIP serão descritos
a seguir nas Seções 4.8 e 4.9.
Por fim, é importante notar que os dados enviados utilizando o protocolo DoIP
estão sujeitos às mesmas falhas de segurança encontradas nos protocolos da pilha
TCP/IP, onde o monitoramento e a manipulação de dados são possíveis quando
mecanismos de segurança não são aplicados (FALL; STEVENS, 2011).
3.6 Características da Camada de Aplicação
Não há considerações quanto ao protocolo DoIP na camada de aplicação, já

que o escopo deste protocolo se estende apenas da camada física até a camada
de transporte. Diversos protocolos da camada de aplicação utilizam o DoIP como
protocolo de transporte nas mensagens de diagnóstico, como mostrados na Tabela
4.1. Um exemplo importante considerado neste trabalho é o ISO 14229-1, ou Unified
Diagnostics Services (UDS) como definido em (ISO 14229-1, 2013).
O padrão DoIP especifica o uso do Protocolo de Configuração Dinâmica de
Host (DHCP) para a configuração dos nós antes do estabelecimento de conexões.
Problemas de segurança relacionados a este protocolo serão discutidos nas próximas
seções.
3.7 Topologias e Casos de Uso
Esta seção descreve as quatro básicas topologias, definidas no (ISO 13400-1,

2011), em uma rede de diagnóstico baseada em IP. Todas as outras possibilidades
podem ser mapeadas como rearranjos destas quatro topologias aqui apresentadas.
Cada nó e conexões serão mais a frente investigados. Pode-se assumir que nas quatro
topologias descritas, todas possuem acesso à Internet.
3.7.1 Conexão física direta entre um veículo e um equipamento de diagnóstico
No caso mais simples como mostra a Figura 3.3, um único equipamento de

diagnóstico é conectado diretamente à um único veículo, isto implica que nenhum outro
equipamento de diagnóstico ou veículo terá acesso ao meio físico desta conexão. Neste
cenário, a conexão física consiste no uso do cabo Ethernet para a ligação direta entre
as duas entidades. O uso de uma conexão com fio é exigido pelo padrão e sempre
será necessária já que o DoIP edge node não possui interfaces sem fio (ISO 13400-1,
2011; ISO 13400-2, 2012; ISO 13400-3, 2011; ISO 13400-4, 2016).
Figura 21 – Conexão direta 1 - 1: (1) Cabo Ethernet, (2) equipamento de diagnóstico, (3) veículo
e (4) conexão lógica.
ISO 13400-1.
3.7.2 Conexão através da rede entre um veículo e um equipamento de diagnóstico
No cenário da Figura 3.4, visualiza-se que mais de um veículo e mais de um

equipamento de diagnóstico estão conectados à mesma rede. Isto implica que o
equipamento de diagnóstico possui a capacidade de identificar os veículos conectados
à rede, sendo capaz de selecionar o veículo correto para o estabelecimento da conexão.
Do ponto de vista do veículo, isto implica que o mesmo deve implementar mecanismos
de identificação assim como ser capaz de gerenciar ou negar múltiplas tentativas de
conexões, já que outros equipamentos de diagnóstico poderiam interferir na conexão
já estabelecida caso este gerenciamento não existisse. Ambas as entidades devem
suportar funcionalidades de integração automáticas à rede IP já existente, através
de rotinas de negociação presente na camada de rede. Nota-se que as conexões
são individuais e únicas para cada entidade. A topologia da rede intermediária não
é definida pelo padrão podendo assim variar desde um roteador na rede local até
a realização de diagnóstico remoto através da Internet. No exemplo abaixo, apenas
um switch é utilizado, no entanto, não há nenhuma restrição para o tamanho da rede
intermediária.
7
Figura 22 – Conexão através da rede 1 - 1: (1) Ethernet switch e ponto de acesso sem fio, (2)
cabo Ethernet, (3) WLAN, (4, 5) equipamentos de diagnóstico, (6, 7) veículos e (8, 9)
conexões lógicas distintas.
ISO 13400-1.
3.7.3 Conexão através da rede entre múltiplos veículos e um equipamento de diag-

nóstico
O cenário da Figura 3.5 é idêntico ao cenário da Figura 3.4 sob a perspectiva do

veículo. Neste caso, o equipamento de diagnóstico deve ser capaz de suportar múltiplas
conexões através de sockets TCP. Este cenário é comum, por exemplo, durante a linha
de produção, onde o fabricante necessita programar as ECUs de muitos veículos,
todos ao mesmo tempo. Dessa forma, o tempo e o custo da fabricação e manutenção
são significantemente reduzidos através destas redes.
5
Figura 23 – LegConexão através da rede N - 1: (1) Rede local do centro de manutenção, (2) cabo
Ethernet, (3) WLAN, (4) equipamento de diagnóstico, (5) servidor, (6, 7, 8) veículos e
(9, 10) conexões lógicas distintas.
3.7.4 Conexão através da rede entre um veículo e múltiplos equipamentos de diag-

nóstico
A Figura 3.6 demonstra um cenário similar ao da Figura 3.5, exceto pelo fato
do veículo suportar múltiplas conexões à equipamentos de diagnóstico. Neste caso,
o veículo deve ser capaz de corretamente distinguir as mensagens de diagnóstico
para cada equipamento ao qual está conectado. Da mesma forma, cada equipamento
de diagnóstico deve ser capaz de identificar que o veículo está conectado à outros
equipamentos de diagnóstico e que serviços específicos, não concorrentes, do veículo
podem estar em uso por outros equipamentos.
Este cenário normalmente ocorre quando um veículo está conectado à uma rede
IP local através de roteadores ou pontos de acesso sem fio, onde vários equipamentos
de diagnóstico executam diferentes aplicações e funcionalidades destinados ao mesmo
veículo. Por exemplo, um equipamento de diagnóstico está reprogramando as ECUs
enquanto o outro verifica os registros de falhas do mesmo veículo simultaneamente.
6
Figura 24 – Conexão através da rede 1 - N: (1) Rede local do centro de manutenção, (2) cabo
Ethernet, (3) WLAN, (4, 5) equipamentos de diagnóstico, (6) servidor, (7, 8, 9)
veículos e (10, 11, 12, 13) conexões lógicas distintas.
ISO 13400-1.
3.8 Recursos a Serem Protegidos
Os recursos identificados como aqueles que são importantes para serem prote-
gidos com respeito à comunicação DoIP são terminais das redes previamente descritas
na seção de configurações. Em outras palavras, o veículo e o equipamento externo de
teste são recursos que precisam ser protegidos. Como esta dissertação se concentra
em questões de segurança relacionados ao DoIP, o verdadeiro recurso do veículo é
a rede interna de comunicação. Como explicado anteriormente, a rede veicular está
conectada com o mundo externo através do DoIP edge node localizado na Unidade
Central de Comunicação (CCU). Comunicações consideradas legítimas pelo gateway
são então encaminhadas para a rede interna. Estudos mostraram que as ações que
podem ser executadas ao se receber tal privilégio de acesso podem potencialmente
resultar em consequências severas (CHECKOWAY et al., 2011; KOSCHER et al., 2010;
NILSSON; LARSON, 2008).
O próprio equipamento de diagnóstico precisa ser protegido, já que um invasor
em posse de um dispositivo de teste legítimo teoricamente teria acesso direto às redes

internas do veículo. Os bancos de dados que o testador potencialmente pode ter acesso
são também incluídos neste conjunto, por exemplo, registros de informações privadas
dos usuários.
Como descrito, os recursos do sistema que precisam ser protegidos são o
veículo e o equipamento de teste externo. Portanto, a comunicação é o recurso que
precisa ser protegido. Se as mensagens transmitidas são protegidas de acordo com
os requisitos especificados na seção seguinte, os terminais irão como consequência
também serem protegidos com respeito às questões de segurança relacionadas ao
DoIP.
3.9 Requisitos de segurança
A taxonomia usada para especificar os atributos de segurança neste documento

é a mesma usada pelo projeto financiado pela Comissão Europeia chamado Apli-
cações Veiculares Protegidas de Invasão (EVITA). As propriedades são retiradas
especificamente do documento (RUDDLE et al., 2009) produzido pelo projeto. Em sua
essência, a taxonomia tem o modelo comum CIA(Confidencialidade Integridade Dispo-
nibilidade) (ALTUNBASAK et al., 2004) o qual é estendido com várias propriedades
extras, sendo esta escolhida pela grande relevância para a indústria automotiva .
Os termos básicos definidos pelo projeto EVITA são usados ao longo deste
trabalho, embora adaptados para se adequar com as características deste tipo de
sistema específico onde comunicações externas ao veículo são o foco. Deve-se levar
em consideração que alguns destes termos se sobrepõem bastante, mas todos são
inclusos para manter a consistência.
Tabela 1 – Lista de atributos de segurança
Atributo
Autenticidade da origem dos

Dados
Integridade
Acesso controlado
(autorização)
Freshness
Não-rejeição
Privacidade e Anonimidade
Confidencialidade
Disponibilidade
A Tabela 3.1 mostra uma lista de atributos de segurança na ordem em que eles
são descritos nesta seção.
3.9.1 Autenticidade da Origem dos Dados
Esta propriedade assegura que a fonte de uma mensagem é verificável. O

receptor de uma mensagem DoIP deve em outras palavras ser capaz de autenticar que
a suposta fonte é realmente de onde a comunicação veio.
Aplicabilidade do DoIP no sistema especificado:
Quando cumprida, esta autenticidade da origem do dado vai assegurar que o
veículo pode verificar que as requisições de diagnóstico vêm de um equipamento de
teste externo confiável, e que o testador pode, por sua vez, receber confirmação que
realmente recebe as respostas do veículo com o qual procura se comunicar. Isto é, as
respostas não são falsificadas ou reproduzidas por outra entidade em nome do veículo.
Possíveis implicações se o atributo de segurança não for completamente cum-

prido:
Se não cumprido, um usuário com intenção maliciosa poderia personificar uma
entidade autorizada com o objetivo de ter comandos potencialmente perigosos aceitos
por uma entidade receptora. Dependendo dos serviços de diagnóstico fornecidos pelo
protocolo executando sobre o DoIP, os resultados podem diferir. Por exemplo, se o
UDS está sendo utilizado, então os dados poderão ser escritos através de mensagens
de atualização de firmware e o software malicioso carregado. Como provado em
(CHECKOWAY et al., 2011) isto poderia, por exemplo, permitir ao adversário desabilitar
os freios de um veículo em locomoção.
3.9.2 Integridade
Quando satisfeita, a propriedade da integridade garante que uma mensagem

não foi alterada, maliciosamente ou aleatoriamente (falhas ou efeitos físicos) em trânsito.
Ou seja, os dados recebidos são idênticos aos dados enviados.
O atributo da integridade assegura que uma entidade não autorizada não pode
modificar quaisquer informações contidas nas mensagens DoIP.
prido:
Modificações poderiam, por exemplo, implicar na mudança de comandos realiza-
das por um invasor que intercepta as mensagens do protocolo. Isto também permite que
o invasor altere software sendo transmitido e que o cenário descrito em autenticidade
da origem do dado possa então também ocorrer se a integridade não for garantida.
3.9.3 Autorização
Esta propriedade descreve como diferentes entidades são permitidas a acessar

recursos, por exemplo em outros nós. É cumprida se as entidades com permissão para
executar certas ações também são as únicas capazes de executá-las.
Autorização pode ser usado para garantir que apenas equipamentos de teste
externos legítimos têm acesso para executar diagnósticos em um veículo.
prido:
Há um claro perigo em permitir agentes arbitrários a habilidade de executar
comandos de diagnóstico em um veículo. Não restringir o acesso significa que o
exemplo o qual está sendo executado é válido em caso de violação desta propriedade,
já que não impor a autorização significaria que qualquer carregamento de software
seria aceito.
3.9.4 Data Freshness
A propriedade de freshness é satisfeita se uma informação recebida é sempre

recente. Isto é, uma mensagem recebida é garantida de não ser uma cópia de uma
mensagem válida transmitida anteriormente.
Na configuração de sistema especificada, esta propriedade acarreta que uma
requisição de diagnóstico legítima mandada anteriormente não pode ser retransmitida
da mesma maneira.
prido:
Um comando que não é perigoso em um certo cenário, pode ser potencialmente
letal em outro. Supondo que um mecânico de uma oficina envia um comando de
diagnóstico para começar uma rotina que libera os freios de um carro para testar a sua
funcionalidade. Este procedimento, obrigatoriamente, seria executado em condições
controladas dentro de uma oficina mecânica, mas imagine que um adversário monitora
a rede da oficina e registra a mensagem enviada. Se o atributo freshness não é
assegurado, esta mensagem legítima poderia ser retransmitida mais tarde com intenção
maliciosa quando o veículo testado anteriormente estiver em velocidade. Deve-se
também levar em conta que este ataque pode ser executado mesmo que as mensagens
sejam protegidas por mecanismos de encriptação já que o adversário não precisa
alterar a transmissão em maneira alguma, mas pode enviar a mensagem inalterada
para reproduzir o resultado esperado.
3.9.5 Não-Rejeição
Não-rejeição é um atributo que garante que uma entidade a qual realizou uma
ação, não possa reivindicar que não a fez. Em outras palavras, ações podem ser
rastreadas e provadas de terem sido executadas por certas entidades.
Se algum dano é causado ao veículo, mensagens de diagnóstico podem ser
utilizadas a fim de identificar a origem da instrução causadora do dano. Isto é por
exemplo útil para garantir responsabilidade legal.
prido:
Enquanto a não-rejeição não impede que acidentes ocorram, este atributo facilita
o trabalho forense conduzido posteriormente para identificar a origem de um ataque.
Um problema que poderia surgir da não garantia da propriedade da não-rejeição seria
provar responsabilidade legal do autor do acidente.
3.9.6 Privacidade e Anonimidade
Privacidade é uma propriedade a qual assegura que a informação sobre o

veículo e seu proprietário não está disponível para entidades não autorizadas.
Anonimidade é um caso especial da privacidade no que se refere à confidencia-
lidade da identificação de uma entidade.
Em um sistema de diagnóstico esta propriedade garante que informações sobre
a identificação do veículo e seu proprietário não esteja disponível para entidades não
autorizadas.
prido:
As possíveis implicações dependem completamente de quais informações estão
armazenadas no veículo e quais podem ser acessadas. Em caso de dados pessoais
do proprietário, tais como número do cartão de crédito, as consequências podem ser
severas.
3.9.7 Confidencialidade
A propriedade de confidencialidade é um conceito mais amplo de sigilo quando

comparado à privacidade. Este requisito refere-se ao sigilo de toda a informação
transmitida, independentemente da entidade, origem ou destino da informação.
Um nó pertencente à rede local de diagnósticos com intenções maliciosas pode
monitorar e observar o conteúdo das mensagens que trafegam na rede e utilizar estas
informações para a descoberta de vulnerabilidades e execução de ataques.
prido:
Se os atributos autorização, data freshness e integridade são cumpridos e exe-
cutados, apenas informações que possivelmente violem a privacidade e anonimidade
poderão ser monitoradas. Logo, a informação capturada não irá contribuir para a execu-
ção de um ataque com consequências letais para os usuários do veículo ou ameaça

ao ambiente externo.
3.9.8 Disponibilidade
Disponibilidade é a propriedade que é satisfeita enquanto o serviço ao qual esta

propriedade se aplica está funcionando.
O requisito de disponibilidade é satisfeito em um sistema de diagnóstico sempre
que as mensagens enviadas são entregues corretamente aos respectivos destinatários,
obedecendo aos requisitos temporais do protocolo.
prido:
Impedir a disponibilidade do sistema irá levar a perturbações não desejadas
acarretando em um aumento de custos para as centrais de manutenção, devido ao
baixo escoamento. Porém, não traz riscos letais aos usuários ou ao ambiente quando
não satisfeito. Pode, no entanto, causar um grave dano à imagem da empresa associada
ao serviço.
3.10 Análise de Ameaças e Vulnerabilidades
Os Protocolos TCP e IP são amplamente utilizados na transmissão de dados

em backbones Ethernet. Devido a essa fundamental importância e necessidade do uso
de tais protocolos de comunicação nas redes digitais, os protocolos TCP/IP são sempre
alvos primários em ciberataques para a exploração de vulnerabilidades sendo também
o utilizado como o vetor de ataque da ação. Nesta seção, são discutidas algumas das
principais vulnerabilidades e ameaças conhecidas em serviços herdados do TCP/IP
que são utilizados pelo DoIP. Devido à imensa gama de possíveis vulnerabilidades
do TCP/IP, apenas as vulnerabilidades que são consideradas críticas e que impactam
diretamente no padrão DoIP. É importante notar que alguns dos protocolos abaixo
são utilizados apenas no pré-estabelecimento da conexão ou entre conexões de
diagnóstico.
Tabela 2 – Protocolos utilizados pelo DoIP
Protocolo
DHCP
ARP
NDP
ICMP
IP
TCP
UDP
A Tabela 3.2 contém a lista de protocolos utilizados pelo DoIP para auxiliar no es-
tabelecimento de conexões e comunicação do DoIP. Abaixo, algumas vulnerabilidades
são apresentadas.
3.10.1 DHCP
Inúmeros ataques podem ser executados contra o DHCP em rotinas de garantia

de acesso à rede local do servidor DHCP. Neste trabalho (ALTUNBASAK et al., 2004),
os autores mencionam alguns exemplos destes ataques em maiores detalhes. Talvez
o ataque mais conhecido e realizado neste protocolo seja o DHCP starvation, onde o
invasor extingue de maneira intencional os recursos disponíveis para o estabelecimento
de conexões na rede. O resultado deste ataque é a negação de serviço para requisições
não maliciosas, por exemplo a extinção de endereços IP reservados para rotinas de
diagnóstico. O DHCP também pode ser atacado para desviar a rota do tráfego de
dados, enviando dados falsificados para enganar o servidor DHCP. Por exemplo, o host
malicioso pode responder solicitações DHCP de terminais legítimos da rede, falsificando
o endereço do gateway padrão para o seu próprio endereço, reencaminhando todo
o tráfego para o host malicioso. O host malicioso terá domínio sobre as informações
enviadas a ele podendo reter estas informações ou reencaminhá-las ao destino correto,

atuando como man-in-the-middle (CALLEGATI; CERRONI; RAMILLI, 2009).
3.10.2 ARP
ARP spoofing ou ARP cache poisoning, é um tipo de ataque onde um host

malicioso da rede local força outros hosts a aceitarem informações errôneas em suas
respectivas tabelas ARP (ABAD; BONILLA, 2007). Ou seja, o host pode responder,
maliciosamente, requisições ARP em nome de outros nós, dessa forma direcionando a
tradução entre endereços de IP e endereços MAC para o host malicioso. A execução
deste ataque entre dois nós que estão prestes a estabelecer um canal de comunicação,
permite ao host malicioso se colocar entre os dois nós de forma transparente, agindo
como man-in-the-middle. Assim como os ataques ao DHCP, o ARP cache poisoning
também exige que o host malicioso esteja conectado à rede local.
3.10.3 NDP
Ataques similares ao ARP cache poisoning podem ser executados em uma rede
IPv6 através do Neighbor Discovery Protocol (NDP) para a resolução de endereços
(ALSA’DEH; MEINEL, 2012). Ao invés do envio de mensagens ARP falsas, solicitações
NDP e de advertisements são injetadas maliciosamente para produzirem o mesmo
efeito, redirecionando o tráfego para um endereço incorreto. Análogo aos ataques
DHCP e ARP, negociações do NDP também ocorrem com nós participantes da LAN,
necessitando a conexão do host malicioso nesta LAN.
3.10.4 ICMP
A forma mais comum de incorporar o Internet Control Message Protocol (ICMP)

em ataques é utilizá-lo para varrer, testar e mapear sistemas, a fim de encontrar
quaisquer tipo de vulnerabilidades antes mesmo do ataque ocorrer (KOHNO; BROIDO;
CLAFFY, 2005). O ICMP redirect quando injetado maliciosamente, podem redirecionar
o tráfego e, portanto, o monitoramento do mesmo. Outros ataques como o envio
de pacotes ICMP malformados e ataques fuzzy podem desencadear problemas não
esperados travando ou corrompendo o sistema (GONT, 2010a).
3.10.5 IP
Pela razão do protocolo IP ser um dos mais estudados e pesquisados pela

comunidade acadêmica, muitas vulnerabilidades têm sido descobertas desde a publica-
ção de sua primeira versão. Um estudo bastante detalhado sobre o protocolo IP quanto
à sua arquitetura, funcionamento e segurança pode ser encontrado em (IETF, 2011).
O objetivo de certos ataques ao protocolo IP é a mudança de campos de dados com
valores aleatórios a fim de provocar um comportamento não esperado pelos desenvol-

vedores, provocando travamentos e panes no sistema. Um exemplo de tal ataque é
conhecido como Local Area Network Denial (LAND), onde o host malicioso envia um
pacote contendo em ambos os campos de origem e destino o mesmo endereço do alvo.
Este é um ataque antigo e conhecido mas, que ainda é efetivo em alguns sistemas
operacionais desatualizados.
3.10.6 TCP
Assim como para o IP, uma análise minuciosa da arquitetura, funcionamento e

segurança do protocolo TCP foi realizada em (GONT, 2010b). Devido à grande com-
plexidade do TCP frente ao UDP, maior a probabilidade de potenciais ataques ao TCP.
Quanto maior o número de funcionalidades e complexidade, maior a vulnerabilidade do
protocolo. Uma classe de ataques contra o TCP é conhecida como session hijacking,
ou sequestro de sessão, onde um host malicioso forçadamente toma para si o controle
do socket de um dos hosts da conexão (HARRIS; HUNT, 1999). Existem algumas
variantes onde o invasor insere segmentos RST, derrubando a conexão entre os nós.
Este último ataque pode resultar em um possível estado de negação de serviço (DoS),
enquanto o TCP session hijacking pode levar a consequências mais graves.
3.10.7 UDP
Por não possuir número de sequência no envio de datagramas ou definição

de sessão, o UDP se torna um alvo fácil para um invasor injetar pacotes modificados
em um canal de comunicação (IETF, 1980). Outro tipo de ataque é conhecido por
UDP bomb onde um host malicioso envia datagramas com valores ilegais, forçando
o direcionamento do protocolo à estados não previstos pelo desenvolvedor, ou seja,
travamentos e panes (MIRKOVIC; PRIER; REIHER, 2002).
3.10.8 Ameaças e Vulnerabilidades no protocolo DoIP
Nesta seção, os problemas de segurança específicos ao protocolo DoIP são

apresentados, excluindo-se todas as vulnerabilidades e ameaças herdadas da pilha
TCP/IP. A análise contém referências diretas aos requisitos definidos no (ISO 13400-2,
2012), sendo expressamente recomendada a leitura deste documento e dos requisitos
descritos para a completa compreensão.
As vulnerabilidades aqui listadas são resultantes da metodologia de análise de
ameaças, vulnerabilidades e riscos aplicadas ao protocolo DoIP. Como mencionando
anteriormente, a especificação do protocolo DoIP é construída na definição de requisi-
tos, máquinas de estado, tipos de mensagens e aplicações. Juntas, definem o protocolo
e seu comportamento.
A seguir, a Tabela 3.3 apresenta as vulnerabilidades do protocolo e as con-

sequências de forma sucinta para fácil entendimento.
Tabela 3 – Ameaças e vulnerabilidades mapeadas no padrão ISO 13400-2.
Ataques e
Referência ISO 13400-2 Vulnerabilidade
Consequências
Fraca Verificação de
-Manipulação de dados
DoIP-041 Cabeçalho Integridade do Cabeçalho
-Negação de serviços
DoIP
Identificação do Número Ausência de Autenticação e -Negação de serviços
do Veículo - VIN Integridade -Falsificação de
Identidade
Mensagens de
Ausência de Integridade -Negação de serviços
Roteamento
-Desvio de tráfego
DoIP-148 - Alocação de
Ausência de Autenticação -Negação de serviços
Recursos Estática
-Falsificação de
identidade
Mensagens de Diagnóstico Ausência de Autenticação
-Permissão de acesso
indevida
DoIP-071 Resposta -Descoberta de

Vazamento de Informação
Negativa - Endereço endereços da rede
Confidencial
inválido intraveicular
Diagnostic Power Mode Ausência de Integridade
-Ameaça letal
Verifica-se que a ausência de atributos de segurança tais como confidenciali-

dade, integridade e autenticação acarretam em consequências de imagem, financeira
e até letais.
72
4 DESCRIÇÃO DO MODELO PROPOSTO
Neste capítulo, serão apresentados os mecanismos de segurança aplicados

no sistema embarcado para mitigar as vulnerabilidades encontradas em sistemas de
diagnóstico citadas anteriormente. Sendo esta a segunda contribuição descrita no
primeiro capítulo deste trabalho. Primeiramente a arquitetura de software embarcada
é discutida, levando em consideração o sistema operacional utilizado, bibliotecas,
módulos do kernel e os mecanismos criptográficos e de autenticação utilizados em
cada camada do modelo OSI. Em seguida, técnicas de encapsulamento e segregação
do tráfego são apresentadas e justificadas. Políticas de firewall, gerenciamento de
portas, acesso remoto e gerenciamento de chaves e certificados, finalizam a descrição
do modelo proposto neste trabalho. Os mecanismos aqui apresentados e o modelo
proposto definem a segunda contribuição deste trabalho, mitigando as vulnerabilidades
descritas na seção 3.10.8 deste trabalho.
4.1 Plataforma utilizada
A Raspberry Pi, Figura 4.1, é um computador de plataforma unitária com ta-

manho próximo ao de um cartão de crédito. Foi desenvolvido no Reino Unido para
promover o ensinamento de ciência da computação em escolas de todo o mundo.
Todos os modelos possuem um System on a Chip (SoC) fabricado pela Broadcom que
inclui uma unidade de processamento central (CPU) ARM e chips de processamento
gráfico. A velocidade da CPU varia de 700 MHz a 1.2GHz para a Raspberry Pi 3,
modelo utilizado neste trabalho.
Figura 25 – Plataforma de prototipação utilizada neste trabalho
4.1.1 Sistema operacional
O sistema operacional utilizado foi o Debian Project, compatível com a Raspberry

Pi. No entanto, o autor deste trabalho utilizou o código fonte do kernel linux 4.7 para
fazer modificações específicas nos módulos de criptografia da camada de enlace e
Capítulo 4. DESCRIÇÃO DO MODELO PROPOSTO 73
rede, sendo assim necessário a recompilação do kernel em binários modificados pare

este projeto especificamente. A razão desta modificação é prover o maior nível de
segurança possível em toda a pilha TCP/IP à qual o protocolo DoIP depende para o
correto funcionamento.
4.1.2 Mecanismos de Segurança Aplicados no Modelo
Após a análise das vulnerabilidades descritas no capítulo anterior, possíveis

mecanismos de segurança são apresentados e agrupados baseados no tipo de vulne-
rabilidade e ameaças que cada mecanismo trata.
• Criptografia: utilizada para proteção de dados confidencias contra a leitura

indesejada do tráfego da rede. Pode ser utilizada também para o armazenamento
de dados, além da transmissão.
• Forte Autenticação é necessária: chaves públicas e privadas, certificados

digitais e autenticações através do protocolo Kerberos podem ser utilizadas
(NEUMAN; TS’O, 1994). No entanto, deve existir um gerenciamento de riscos
em caso de cópias de chaves criptográficas. As chaves devem possuir ou uma
curta validade com procedimentos frequentes de atualização ou chaves de
longas validades com procedimentos de eliminação dessas. A aplicação de uma
nova versão do protocolo Kerberos para dispositivos embarcados e Internet das
coisas é sugerida como trabalho futuro.
• Segregação do tráfego da rede: segregação do tráfego da rede pode ser

realizado de duas formas, separação por criptografia, separação lógica na trans-
missão ou ambas. A separação lógica é feita através de encapsulamentos de
frames Ethernet em pacotes IP, por exemplo. Virtual LANs (VLANs) é a tecno-
logia mais conhecida para a separação de trafego em redes IP (YUASA et al.,
2000). Para a separação utilizando criptografia, grupos de dispositivos são de-
finidos para o compartilhamento da mesma chave de sessão para a conexão.
Filtros, firewalls e configurações em switches e roteadores são outras formas de
segregar o tráfego.
• Assinaturas digitais e códigos de autenticação (MACs): são utilizados para

a verificação da origem e da integridade dos dados da comunicação. Logo,
falsificação, dados corrompidos e personificação podem ser detectados (ALTUN-
BASAK et al., 2005).
• Timestamps: etiquetas de tempo são anexadas a cada pacote transmitido na

rede, garantindo que inserção de pacotes válidos do passado sejam processados
na rede (MO; SINOPOLI, 2009).
• Firewalls: utilizados em gateways, restringem, controlam e monitoram todo

o acesso entre a rede LAN e a Internet através de políticas de acesso pré-
configuradas.
As seções seguintes descrevem quais os softwares de criptografia e segu-

rança utilizados neste projeto. Cada item possui uma responsabilidade específica e
necessária, evitando-se redundância na aplicação destes.
Após detalhadas análises do comportamento do protocolo ISO 13400, sua
complexidade e imensa lista de requisitos, ficou claro que as medidas de segurança a
serem aplicadas não seriam feitas diretamente no DoIP. Modificações no protocolo em
si tornariam este projeto muito mais complexo havendo um grande risco de não ser
realizado a tempo ou a confirmação que o esforço demandado seria economicamente
inviável. Outro fator crítico no momento da decisão dos mecanismos de mitigação
aqui propostos está relacionado com a versatilidade tecnológica do padrão: IPv4, IPv6,
ARP, ICMP, ICMP6, DHCP, TCP, UDP, NDP são alguns dos protocolos que podem ser
utilizados durante a comunicação.
Portanto, a proposta realizada neste trabalho se dá pela aplicação de mecanis-
mos de segurança para cada camada do modelo OSI, buscando a máxima segurança
do frame DoIP em todos os estágios de sua transmissão. Os mecanismos de segurança
aplicados em cada camada do modelo OSI são independentes entre si e devem ser
gerenciados separadamente. A interação aqui construída entre mensagens de diag-
nóstico do protocolo ISO 13400 e com os mecanismos de segurança, garantem que
todo e qualquer tipo de informação transmitida pelo veículo ou pelo equipamento de
diagnóstico permaneça intacta, porém encapsulada em containers definidos no nosso
modelo de segurança.
Abaixo, uma breve introdução técnica de cada mecanismo aplicado nas diferen-
tes camadas é apresentada.
4.1.2.1 MACsec
MACsec, (IEEE 802.1AE, 2006), oferece uma comunicação segura entre LANs
com fio. Quando MACsec é aplicado para proteger a comunicação entre os terminais
em uma rede local, cada frame da rede é criptografado utilizando criptografia de
chave simétrica, prevenindo que os dados sejam alterados ou monitorados através
de dispositivos maliciosos conectados à rede. Esta criptografa ocorre na camada de
enlace, camada 2 do modelo OSI. O MACsec foi projetado principalmente para ser
utilizado em conjunto com o (IEEE 802.1X, 2010), pois oferece o controle de acesso
baseado em portas usando autenticação. Uma porta (IEEE 802.1X, 2010) pode ser
ativada ou desativada com base na identidade do usuário ou dispositivo que se conecta
a ele de forma dinâmica. Antes de autenticação, a identidade do host é desconhecida e

todo o tráfego é bloqueado. Após a autenticação, a identidade do host é conhecida e
todo o tráfego a
partir desse ponto final é permitida. O switch executa filtragem de endereços
MAC e monitoramento do estado de portas para garantir que apenas o host autenticado
envie dados através desta porta.
O (IEEE 802.1X, 2010) define a forma que o MACsec é utilizado em conjunto
com a autenticação para fornecer controle de acesso baseado em porta segura usando
a autenticação. (IEEE 802.1X, 2010) autentica o host e transmite a chave criptográ-
fica necessária para ambos os lados. Usando as chaves derivadas da autenticação
(IEEE 802.1X, 2010), o MACsec pode estabelecer uma conexão criptografada na LAN,
garantindo a segurança da sessão autenticada, com visualizado na Figura 4.2.
Figura 26 – Funcionamento do MACsec.
Neste trabalho, considera-se o MACsec como o mecanismo de segurança mais

importante do modelo aqui proposto. É o MACsec que recebe diretamente o frame DoIP,
é o MACsec que realiza o primeiro encapsulamento das informações de diagnóstico, ou
seja, o MACsec gera um frame (camada de enlace) após o encapsulamento do frame
DoIP (IEEE 802.1AE, 2006).
4.1.2.2 VLAN
Virtual LAN (VLAN), (IEEE 802.1Q, 2011), é uma abstração virtual da LAN. Por
padrão, os hosts associados à uma determinada VLAN não possuem acesso aos
sistemas em outras VLANs, mesmo que façam parte da mesma rede física. VLANs
permitem o isolamento virtual da rede, possibilitando a divisão do tráfego em grupos
e atendendo aos requisitos funcionais e de segurança. IEEE 802.1Q é o padrão que
define as VLANs; o identificador VLAN possui 12 bits no frame Ethernet, criando um
limite inerente de 4096 VLANs em uma LAN. Portas em switchs podem ser atribuídas a
uma ou mais VLANs, permitindo que os sistemas sejam divididos em grupos lógicos
- por exemplo, baseado em qual departamento estão associados - e as regras a ser
estabelecido sobre como os sistemas nos grupos separados podem se comunicar uns
com os outros.
4.1.2.3 Generic Routing Encapsulation
Generic Routing Encapsulation (GRE) é um protocolo de tunelamento desen-

volvido pela Cisco Systems que encapsula uma grande variedade de protocolos da
camada de rede em pacotes de protocolos da camada IP.
Neste modelo de segurança, o uso de GRE proporciona dupla funcionalidade
neste projeto. A primeira funcionalidade é o encapsulamento de frames Ethernet (ca-
mada de enlace) em pacotes IP (camada de rede). Esta funcionalidade é desejável
e necessária pois o encapsulamento realizado pelo MACsec resulta em um frame
(camada de enlace) sendo o encapsulamento GRE necessário para transmitir a men-
sagem de diagnóstico em infraestruturas genéricas que não implementam o MACsec,
por exemplo. A segunda funcionalidade deriva do uso do IPsec, descrito a seguir. O
IPsec é um protocolo da camada de rede, sendo assim, não suporta a transmissão e
ou encapsulamento de frames Ethernet.
4.1.2.4 IPsec
O Internet Protocol Security (IPSec) é um conjunto de protocolos para comunica-

ções seguras IP (Internet Protocol) que funciona através da autenticação e criptografia
de cada pacote IP de uma sessão de comunicação. O IPsec inclui protocolos para
estabelecer a autenticação mútua entre os hosts no início da sessão de negociação e
protocolos para a troca de chaves criptográficas a serem utilizados durante a sessão.
IPsec pode ser usado para proteger a transferência de dados entre um par de hosts
(host-to-host), entre um par de gateways de segurança (Rede-a-rede), ou entre um
gateway de segurança e uma série (network-to-host). O IPsec utiliza serviços de cripto-
grafia para proteger as comunicações através das redes IP. IPsec suporta autenticação
de nível de rede ponto a ponto, os dados origem autenticação, integridade de dados,
confidencialidade de dados (criptografia) e proteção contra replay attacks.

IPsec é um esquema de segurança fim a fim, operando na camada de rede de acordo
com o modelo OSI. Assim, apenas o oferece mecanismos de segurança e criptografia
à nível IP (DORASWAMY; HARKINS, 2003).
4.1.2.5 TLS
O protocolo TLS foi projetado para fornecer três serviços essenciais à nível de
aplicação que utilizem a pilha TCP/IP, são estes: criptografia, autenticação e integridade
dos dados (IETF, 2008). A segurança à nível da camada de aplicação é opcional e está
relacionado diretamente ao uso do protocolo UDS.
4.1.3 Pilha de TCP/IP
A Figura 4.3 demonstra visualmente os mecanismos aplicados à pilha TCP/IP

do linux embarcado na Raspberry Pi.
Figura 27 – Camadas de segurança aplicadas ao modelo proposto.

4.1.4 Modelo de encapsulamento na camada de rede
Como explicado anteriormente, o modelo de encapsulamento de tráfego é

exibido na Figura 4.4.
Para uma maior compreensão dos níveis de encapsulamento, as justificativas
são sumarizadas da seguinte forma:
• O tráfego gerado pelo protocolo DoIP é vasto e de diferentes características.

O encapsulamento realizado pelo MACsec garante a segurança contra hosts
autorizados e conectados na rede local da central de manutenção.
• Cada veículo possui suas chaves criptográficas e certificados de acordo com o

modelo de Infraestrutura de Chave Pública (PKI).
• O encapsulamento MACsec também garante a confidencialidade, integridade e

autenticidade entre veículos. Se por alguma razão um veículo estiver compro-
metido e este assumir o papel de host malicioso, o MACsec possui mecanismos
que mitigam estas ameaças.
• A fim de transmitir os frames MACsec através dos roteadores e redes IP, o

encapsulamento GRE se faz necessário, contribuindo para o isolamento do
tráfego em grupos pré-definidos.
• O IPsec por fim, realiza o último encapsulamento, possibilitando de maneira

segura a realização de diagnóstico remoto. Isso reduz drasticamente os custos
das centrais de manutenção e consequentemente das fabricantes. O diagnóstico
poderá ser realizado diretamente de centrais inteligentes localizados dentro das
montadoras.
Figura 28 – Modelo de encapsulamento das mensagens de diagnóstico.
A Figura 4.5 exemplifica visualmente como se dá a realização de sessões de

diagnóstico seguras através da Internet.
Figura 29 – Execução da realização de rotinas de diagnóstico em um canal seguro.
4.2 Análise de Desempenho
Todas as combinações possíveis dos algoritmos de criptografia que cada me-

canismo oferece em suas funcionalidades foram testadas e avaliadas quanto suas
respectivas taxas de transmissão.
Os testes foram realizados utilizando a biblioteca StrongSwan versão 5.5.1 para
execução das rotinas IPsec no linux. Para o uso das funcionalidades de encapsulamento
GRE e do MACsec, foram necessários módulos de kernel manualmente modificados,
compilados e instalados no kernel linux. Em cada camada de proteção, ou seja, módulos
de kernel e bibliotecas em espaço de usuário, arquivos de configuração, especificando
cifras criptográficas, foram submetidos para a correta análise do desempenho como
visualizados na Tabela 4.1. Os arquivos de configuração podem ser obtidos mediante o
contato direto com o autor do presente trabalho.
Para o cálculo das taxas de transmissão encontradas, o simulador de tráfego de
rede Iperf foi utilizado tanto para geração quanto para a medida de taxa máxima de
transmissão.
O algoritmo para troca de chaves no estabelecimento da conexão considerado
neste projeto é o Internet Key Exchange v2 (IKEv2). O tempo de estabelecimento da
conexão máximo alcançado dos vários casos de testes simulados foi de 300 ms. Não
impactando nos requisitos temporais definidos pelo ISO 13400.
Na Tabela 4.1, verifica-se a lista de combinações que foram implementadas e
suas respectivas velocidades de transmissão.
Tabela 4 – Authenticated Encryption e respectivas taxas de transmissão
Cipher Suite Mb/s
Sem criptografia, texto puro 89.76
Biblioteca AES não otimizada ———
esp-aes128-sha1 42.45
esp-aes128-sha256 37.39
esp-aes256-sha256 33.25
esp-aes128ccm128 35.17
esp-aes256ccm128 28.70
esp-aes128gcm128 30.62
esp-aes256gcm128 27.84
esp-aes128-sha512 22.91
esp-aes256-sha512 21.28
Biblioteca AES otimizada para

———
ARM
esp-aes128-sha256 42.69
Após a execução dos testes descritos acima, constata-se que o impacto temporal
no estabelecimento da conexão criptografada é insignificante para o cenário proposto
neste trabalho. Conjuntos de rotinas criptográficas otimizadas para o processador ARM
são os mais recomendados, no entanto, as bibliotecas com rotinas otimizadas não
oferem suporte a todos os conjuntos criptográficos.
Se o conjunto de algoritmos esp-aes128gcm128 for selecionado para a trans-
missão segura de mensagens de diagnóstico, a taxa de transmissão média será
de 33.33Mbps. Aproximadamente sessenta e seis vezes (66) mais rápido que sistemas
não criptografados utilizando o barramento CAN.
82
5 CONCLUSÃO
Carros conectados devem necessariamente ser projetados e construídos apli-

cando a segurança como um requisito fundamental. Os veículos já não são ilhas de
engenharia eletromecânica; ao contrário, eles são componentes de um sistema maior
de sistemas, que integra o veículo, estradas, fabricante e consumidor, oferecendo uma
experiência de transporte seguro.
Num futuro próximo, ou até mesmo hoje, carros conectados serão dispositivos
completamente conectados à Internet ou conectados à redes IP. Isto traz flexibilidade
dos serviços que podem ser oferecidos e um novo nicho de mercado. A cibersegurança
veicular será uma das maiores ameaças que a sociedade já enfrentou em sistemas
de transporte de toda a história. E mesmo assim, é um tópico ainda desconhecido,
até mesmo pela indústria automotiva de ponta. A ameaça de ataques e invasões em
sistemas automotivos só irá aumentar à medida que carros autônomos são introduzidos,
dada a revolução na tecnologia de transporte individual que neste exato momento
acontece.
Sistemas de diagnósticos intraveiculares, de fato, pertencem ao grupo de funci-
onalidades que agregam conectividade aos veículos atuais e que certamente serão
alvos comuns de ataques e exploração. Por essa razão, este trabalho sugeriu um
possível modelo de proteção que certamente dificultará muito a ação de invasores, pois
consideramos, na segurança da informação, que não existe nenhum sistema totalmente
seguro, nenhum.
Concluímos que a aplicação de técnicas de criptografia e segurança em múltiplas
camadas da pilha TCP/IP é sim atrativo quando analisa-se o impacto de um ataque
cibernético, imagem da empresa e reparação de danos versus a redução da largura de
banda devido ao processamento das rotinas de criptografia embarcada. A plataforma
de hardware embarcada sugerida neste projeto está longe de ser uma plataforma de
alto desempenho e foi exatamente com esta intenção que demonstramos a factibilidade
do projeto.
Metodologias de ataques e poder de processamento dos nós maliciosos sempre
aumentam ao longo dos anos, consequentemente as técnicas de proteção devem estar
necessariamente mais evoluídas, estáveis e maduras que técnicas de ataque.
Os próximos passos deste projeto, que ainda está em andamento, é investigar
como sistemas de segurança entre ECUs se comportam utilizando o barramento
Ethernet, já que a proposta do presente trabalho considerou apenas comunicações
entre dispositivos externos e o veículo através do protocolo DoIP. Qual o impacto de
Capítulo 5. CONCLUSÃO 83
eficiência na transmissão das informações intraveiculares e quais as consequências

no comprometimento da autenticidade das ECUs, são perguntas que pretendemos
respondê-las em um futuro breve.
84
Referências
ABAD, C. L.; BONILLA, R. I. An analysis on the schemes for detecting and preventing
ARP cache poisoning attacks. In: IEEE, 2007. Distributed Computing Systems
Workshops, 2007. ICDCSW’07. 27th International Conference on. [S.l.], 2007. p. 60 –
60. Citado na página 69.
ALSA’DEH, A.; MEINEL, C. Secure neighbor discovery: Review, challenges,

perspectives, and recommendations. IEEE Security & Privacy, IEEE, v. 10, n. 4, p. 26 –
34, 2012. Citado na página 69.
ALTUNBASAK, H. et al. Addressing the Weak Link Between Layer 2 and Layer 3 in the
Internet Architecture. In: LCN. [S.l.: s.n.], 2004. v. 4, p. 417 – 418. Citado 2 vezes nas
páginas 62 e 68.
ALTUNBASAK, H. et al. Securing layer 2 in local area networks. In: SPRINGER, 2005.
International Conference on Networking. [S.l.], 2005. p. 699 – 706. Citado na página
73.
ANONYMOUS. Anonymous. 2004. Disponível em: <http://anonofficial.com/>. Citado

na página 22.
BITTAU, A.; HANDLEY, M.; LACKEY, J. The final nail in WEP’s coffin. In: IEEE, 2006.
2006 IEEE Symposium on Security and Privacy (S&P’06). [S.l.], 2006. p. 15 – pp.
Citado na página 55.
BMW. Introducing Automotive Ethernet. 2015. Disponível em: <https://standards.

ieee.org/events/automotive/2015/00_Keynote_BMW_Introducing_Ethernet_v1.0.pdf>.
BROADCOM CORPORATION. From OPEN Alliance BroadR-Reach® PHYs to IEEE

802.3bp RTPGE. 2013. Disponível em: <https://standards.ieee.org/events/automotive/
03_Tazabay_Broadcom_RTPGE.pdf>. Citado na página 37.
Broadcom Corporation. BroadR-Reach® Physical Layer Transceiver Specification For

Automotive Applications V3.0. [S.l.], 2014. Disponível em: <http://www.ieee802.org/3/
1TPCESG/public/BroadR_Reach_Automotive_Spec_V3.0.pdf>. Citado na página 37.
CALLEGATI, F.; CERRONI, W.; RAMILLI, M. Man-in-the-Middle Attack to the HTTPS

Protocol. IEEE Security and Privacy, IEEE Educational Activities Department, v. 7, n. 1,
p. 78 – 81, 2009. Citado na página 69.
CAMPOS, F. T.; MILLS, W. N.; GRAVES, M. L. A reference architecture for remote

diagnostics and prognostics applications. In: IEEE, 2002. AUTOTESTCON Proceedings,
2002. IEEE. [S.l.], 2002. p. 842 – 853. Citado na página 47.
CHECKOWAY, S. et al. Comprehensive Experimental Analyses of Automotive Attack

Surfaces. In: SAN FRANCISCO, 2011. USENIX Security Symposium. [S.l.], 2011.
Citado 3 vezes nas páginas 21, 61 e 64.
Referências 85
CORRIGAN, S. Introduction to the controller area network (CAN). Texas Instrument,

Application Report, 2008. Disponível em: <http://www.ti.com/lit/an/sloa101a/sloa101a.
pdf>. Citado na página 30.
DEIBERT, R. Disarming a Cyber Mercenary, Patching Apple Zero Days. 2016.

Disponível em: <https://deibert.citizenlab.org/2016/08/disarming-a-cyber-mercenary-
patching-apple-zero-days/>. Citado na página 22.
DILLON, C. D. Low voltage differential signaling (LVDS) drivers and systems. [S.l.]:
Google Patents, 2003. US Patent 6,590,422. Citado na página 39.
DORASWAMY, N.; HARKINS, D. IPSec: the new security standard for the Internet,
intranets, and virtual private networks. [S.l.]: Prentice Hall Professional, 2003. Citado
na página 77.
E2V. RF Safe-Stop shuts down car engines with radio pulse. 2013. Disponível em:
<http://www.bbc.com/news/technology-25197786>. Citado na página 22.
ELEKTROBIT GMBH. Ethernet for AUTOSAR. 2008. Disponível em: <https:

//www.autosar.org/fileadmin/files/events/2008-10-23-1st-autosar-open/07_Elektrobit_
Ethernet_for_Autosar.pdf>. Citado na página 39.
ETSI. Threat, Vulnerability and Risk Analysis (TVRA). [S.l.], 2010. 2010 – 03 p.
Disponível em: <http://www.etsi.org/deliver/etsi_tr/102800_102899/102893/01.01.01_
60/tr_102893v010101p.pdf>. Citado na página 52.
ETSI. Telecommunications and Internet converged Services and Protocols for

Advanced Networking (TISPAN). [S.l.], 2011. Disponível em: <http://www.etsi.org/
deliver/etsi_ts/102100_102199/10216501/04.02.03_60/ts_10216501v040203p.pdf>.
FALL, K. R.; STEVENS, W. R. TCP/IP illustrated, volume 1: The protocols. [S.l.]:

addison-Wesley, 2011. Citado na página 56.
FENNEL, H. et al. Achievements and exploitation of the AUTOSAR development

partnership. Convergence, v. 2006, 2006. Citado na página 43.
GONT, F. ICMP attacks against TCP. 2010. Citado na página 69.
GONT, F. Security Assessment of the Transmission Control Protocol (TCP). Work in

Progress, 2010. Citado na página 70.
HARRIS, B.; HUNT, R. TCP/IP security threats and attack methods. Computer
Communications, Elsevier, v. 22, n. 10, p. 885 – 897, 1999. Citado na página 70.
HEINECKE, H. et al. AUTOSAR–Current results and preparations for exploitation. In:

7th EUROFORUM conferenceâ Software in the vehicle. [S.l.: s.n.], 2006. Citado na
página 43.
HIRAOKA, C. Technology Acceptance of Connected Services in the Automotive

Industry. Wiesbaden: Gabler, 2009. ISBN 978-3-8349-8309-1. Disponível em:
<http://www.springer.com/us/book/9783834918703>. Citado na página 47.
Referências 86
HOUSLEY, R.; ARBAUGH, W. Security problems in 802.11-based networks.

Communications of the ACM, ACM, v. 46, n. 5, p. 31 – 34, 2003. Citado na página 55.
IEEE 802.1AE. Standard for Local and Metropolitan Area Networks: Media Access
Control (MAC) Security. [S.l.], 2006. Disponível em: <https://standards.ieee.org/findstds/
standard/802.1AE-2006.html>. Citado 2 vezes nas páginas 74 e 75.
IEEE 802.1AS. Standard for Local and Metropolitan Area Networks - Timing and
Synchronization for Time-Sensitive Applications in Bridged Local Area Networks. [S.l.],
IEEE 802.1BA. Standard for Local and metropolitan area networks–Audio Video
Bridging (AVB) Systems. [S.l.], 2011. Disponível em: <https://standards.ieee.org/
findstds/standard/802.1BA-2011.html>. Citado na página 37.
IEEE 802.1Q. Standard for Local and metropolitan area networks–Media Access
Control (MAC) Bridges and Virtual Bridged Local Area Networks. [S.l.], 2011. Disponível
em: <https://standards.ieee.org/findstds/standard/802.1Q-2011.html>. Citado 2 vezes
nas páginas 37 e 76.
IEEE 802.1QAV. Standard for Local and metropolitan area networks– Virtual
Bridged Local Area Networks Amendment 12: Forwarding and Queuing
Enhancements for Time-Sensitive Streams. [S.l.], 2009. Disponível em: <https:
//standards.ieee.org/findstds/standard/802.1Qav-2009.html>. Citado na página 37.
IEEE 802.1X. Standard for Local and metropolitan area networks–Port-Based Network
Access Control. [S.l.], 2010. Disponível em: <https://standards.ieee.org/findstds/
standard/802.1X-2010.html>. Citado 2 vezes nas páginas 74 e 75.
IEEE 802.3. Standard for Ethernet. [S.l.], 2012. Disponível em: <https://standards.ieee.
org/about/get/802/802.3.html>. Citado 2 vezes nas páginas 36 e 51.
IETF. RFC 768. [S.l.], 1980. User Datagram Protocol. Disponível em: <https:
//tools.ietf.org/html/rfc768>. Citado 2 vezes nas páginas 56 e 70.
IETF. RFC 791. [S.l.], 1981. Internet Protocol Version 4 (IPv4). Disponível em:
<https://tools.ietf.org/html/rfc791>. Citado na página 56.
IETF. RFC 793. [S.l.], 1981. Transmission Control Protocol. Disponível em:
IETF. RFC 2460. [S.l.], 1998. Internet Protocol Version 6 (IPv6). Disponível em:
IETF. RFC 5246. [S.l.], 2008. The Transport Layer Security (TLS) Protocol Version 1.2.
Disponível em: <https://tools.ietf.org/html/rfc5246>. Citado na página 77.
IETF. RFC 6274. [S.l.], 2011. Security Assessment of the Internet Protocol Version 4.
Disponível em: <https://tools.ietf.org/html/rfc6274>. Citado na página 69.
INTEL SECURITY. Automotive Security Best Practices. 2015. Disponível em:

<http://www.mcafee.com/de/resources/white-papers/wp-automotive-security.pdf>.
Referências 87
ISO 11452-1. Road vehicles – Component test methods for electrical disturbances
from narrowband radiated electromagnetic energy – Part 1: General principles and
terminology. [S.l.], 2015. Disponível em: <http://www.iso.org/iso/catalogue_detail.htm?
csnumber=59609>. Citado na página 41.
ISO 11898-1. Road vehicles – Controller area network (CAN) – Part 1:

Data link layer and physical signalling. [S.l.], 2015. CAN bus. Disponível em:
<http://www.iso.org/iso/catalogue_detail.htm?csnumber=63648>. Citado na página 30.
ISO 13400-1. Road vehicles – Diagnostic communication over Internet Protocol (DoIP)
– Part 1: General information and use case definition. [S.l.], 2011. Disponível em:
<http://www.iso.org/iso/catalogue_detail.htm?csnumber=53765>. Citado 6 vezes nas
páginas 39, 48, 51, 54, 55 e 57.
ISO 13400-2. Road vehicles - Diagnostic communication over Internet Protocol (DoIP)
– Part 2: Transport protocol and network layer services. [S.l.], 2012. Disponível em:
páginas 51, 53, 54, 55, 57 e 70.
– Part 3: Wired vehicle interface based on IEEE 802.3. [S.l.], 2011. Disponível em:
páginas 36, 51 e 57.
– Part 4: Ethernet-based high-speed data link connector. [S.l.], 2016. Disponível em:
páginas 51 e 57.
ISO 14229-1. Road vehicles – Unified diagnostic services (UDS) – Part 1: Specification
and requirements. [S.l.], 2013. Disponível em: <http://www.iso.org/iso/catalogue_detail.
htm?csnumber=55283>. Citado 3 vezes nas páginas 39, 49 e 57.
ISO 14229-2. Road vehicles – Unified diagnostic services (UDS) – Part 2: Session
layer services. [S.l.], 2013. Disponível em: <http://www.iso.org/iso/catalogue_detail.
htm?csnumber=45763>. Citado na página 49.
ISO 14229-3. Road vehicles – Unified diagnostic services (UDS) – Part 3: Unified
diagnostic services on CAN implementation (UDSonCAN). [S.l.], 2012. UDSonCAN.
Disponível em: <http://www.iso.org/iso/catalogue_detail.htm?csnumber=55284>.
ISO 14229-5. Road vehicles – Unified diagnostic services (UDS) – Part 5: Unified
diagnostic services on Internet Protocol implementation (UDSonIP). [S.l.], 2013.
UDSonIP. Disponível em: <http://www.iso.org/iso/catalogue_detail.htm?csnumber=
55287>. Citado 2 vezes nas páginas 49 e 50.
ISO 15031-3. Road vehicles – Communication between vehicle and external

equipment for emissions-related diagnostics – Part 3: Diagnostic connector
and related electrical circuits: Specification and use. [S.l.], 2016. Disponível em:
<http://www.iso.org/iso/catalogue_detail.htm?csnumber=64636>. Citado na página 51.
Referências 88
ISO 27145-2. Road vehicles – Implementation of World-Wide Harmonized On-Board

Diagnostics (WWH-OBD) communication requirements – Part 2: Common data
dictionary. [S.l.], 2012. Disponível em: <http://www.iso.org/iso/catalogue_detail.htm?
csnumber=46276>. Citado na página 49.
ISO 27145-3. Road vehicles – Implementation of World-Wide Harmonized On-Board

Diagnostics (WWH-OBD) communication requirements – Part 3: Common message
dictionary. [S.l.], 2012. Citado na página 49.
KOHNO, T.; BROIDO, A.; CLAFFY, K. C. Remote physical device fingerprinting. IEEE
Transactions on Dependable and Secure Computing, IEEE, v. 2, n. 2, p. 93 – 108, 2005.
KOSCHER, K. et al. Experimental Security Analysis of a Modern Automobile. In:

2010 IEEE Symposium on Security and Privacy. [S.l.: s.n.], 2010. p. 447 – 462. ISSN
1081-6011. Citado 2 vezes nas páginas 21 e 61.
LASHKARI, A. H.; DANESH, M. M. S.; SAMADI, B. A survey on wireless security

protocols (WEP, WPA and WPA2/802.11 i). In: IEEE, 2009. Computer Science and
Information Technology, 2009. ICCSIT 2009. 2nd IEEE International Conference on.
[S.l.], 2009. p. 48 – 52. Citado na página 55.
MATHEUS, K.; KÖNIGSEDER, T. Automotive ethernet. [S.l.]: Cambridge University

Press, 2014. Citado 4 vezes nas páginas 32, 33, 35 e 39.
MAZZOLA, M.; CAFIERO, L.; DENICOLO, M. Method and apparatus for multilevel
encoding for a local area network. [S.l.]: Google Patents, 1994. US Patent 5,280,500.
MBIYDZENYUY, G.; PERSSON, J. A.; DAVIDSSON, P. Threat, Vulnerability, and

Risk Analysis for Intelligent Truck Parking, a Pre-study. [S.l.], 2012. Disponível em:
<http://www.bth.se/com/intelligent_truck_parking.nsf/attachments/Del_6_Security_
pdf/$file/Del_6_Security.pdf>. Citado na página 52.
METCALFE, B. et al. Automotive Ethernet - The Definitive Guide. Intrepid Control

Systems, 2014. ISBN 9780990538820. Disponível em: <https://books.google.com.br/
books?id=g1zToQEACAAJ>. Citado 2 vezes nas páginas 34 e 43.
MILLER, C.; VALASEK, C. Remote Exploitation of an Unaltered Passenger Vehicle.

2015. Disponível em: <http://www.ioactive.com/pdfs/IOActive_Remote_Car_Hacking.
pdf>. Citado na página 21.
MIRKOVIC, J.; PRIER, G.; REIHER, P. Attacking DDoS at the source. In: IEEE, 2002.
Network Protocols, 2002. Proceedings. 10th IEEE International Conference on. [S.l.],
2002. p. 312 – 321. Citado na página 70.
MO, Y.; SINOPOLI, B. Secure control against replay attacks. In: IEEE, 2009.
Communication, Control, and Computing, 2009. Allerton 2009. 47th Annual Allerton
Conference on. [S.l.], 2009. p. 911 – 918. Citado na página 73.
NAVET, N.; SIMONOT-LION, F. In-vehicle communication networks-a historical

perspective and review. [S.l.], 2013. Citado na página 26.
Referências 89
NEUMAN, B. C.; TS’O, T. Kerberos: An authentication service for computer networks.

IEEE Communications magazine, IEEE, v. 32, n. 9, p. 33 – 38, 1994. Citado na página
73.
NILSSON, D. K.; LARSON, U. E. Simulated attacks on CAN buses: vehicle virus. In:
IASTED International conference on communication systems and networks (AsiaCSN).
[S.l.: s.n.], 2008. p. 66 – 72. Citado na página 61.
PFLEEGER, C. P.; PFLEEGER, S. L. Security in computing. [S.l.]: Prentice Hall

Professional Technical Reference, 2002. Citado na página 55.
Robert Bosch GmbH. CAN Specification 2.0. Suttgart, Germany, 1991. Disponível em:
<http://www.bosch-semiconductors.de/media/ubk_semiconductors/pdf_1/canliteratur/
can2spec.pdf>. Citado 2 vezes nas páginas 29 e 30.
RUDDLE, A. et al. Security requirements for automotive on-board networks based on

dark-side scenarios. EVITA Deliverable D, v. 2, 2009. Citado na página 62.
SAE AS6802. Time-Triggered Ethernet. [S.l.], 2011. Disponível em: <http:

//standards.sae.org/as6802/>. Citado na página 38.
SCHMERLER, S. et al. AUTOSAR–Shaping the Future of a Global Standard. In: 5th

VDI Congress Baden-Baden Spezial. [S.l.: s.n.], 2012. Citado na página 43.
SCHREIBER, U. Pulse-amplitude-modulation (PAM) fluorometry and saturation pulse

method: an overview. In: Chlorophyll a Fluorescence. [S.l.]: Springer, 2004. p. 279 –
STEINBACH, T. et al. Tomorrow’s in-car interconnect? A competitive evaluation of

IEEE 802.1 AVB and Time-Triggered Ethernet (AS6802). In: IEEE, 2012. Vehicular
Technology Conference (VTC Fall), 2012 IEEE. [S.l.], 2012. p. 1 – 5. Citado na página
38.
THE CONVERSATION. How Anonymous hacked Donald Trump. 2016. Disponível em:
<http://theconversation.com/how-anonymous-hacked-donald-trump-56794>. Citado na
página 22.
THE GUARDIAN. Ransomware attack on San Francisco public transit gives everyone a
free rideA. 2016. Disponível em: <https://www.theguardian.com/technology/2016/nov/
28/passengers-free-ride-san-francisco-muni-ransomeware>. Acesso em: 03/12/2016.
THE REGISTER. This is what a root debug backdoor in a Linux kernel looks like. 2016.
Disponível em: <http://www.theregister.co.uk/2016/05/09/allwinners_allloser_custom_
kernel_has_a_nasty_root_backdoor/>. Citado na página 23.
THOMESSE, J. Fieldbus technology in industrial automation. Proceedings of the IEEE,

IEEE, v. 93, n. 6, p. 1073 – 1101, 2005. Citado na página 29.
TILL STREICHERT; DAIMLER AG. SEIS - Sicherheit in Eingebetteten IP-

basierten Systemen. 2012. Disponível em: <http://www.strategiekreis-automobile-
zukunft.de/public/projekte/seis>. Citado na página 38.
Referências 90
TUOHY, S. et al. Intra-vehicle networks: A review. IEEE Transactions on Intelligent

Transportation Systems, IEEE, v. 16, n. 2, p. 534 – 545, 2015. Citado na página 26.
YUASA, H. et al. Virtual LAN system. [S.l.]: Google Patents, 2000. US Patent 6,085,238.

DISSERTAÇÃO Fabio Leite Soares

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

DISSERTAÇÃO Fabio Leite Soares

Enviado por

Direitos autorais:

Formatos disponíveis

FÁBIO LEITE SOARES

Sistema embarcado para comunicação intraveicular segura em Diagnostics

Universidade Federal de Pernambuco

Sistema embarcado para comunicação intraveicular segura em Diagnostics

Dissertação de Mestrado apresentada ao

Orientador: Divanilson Rodrigo de Sousa

S676s Soares, Fábio Leite

Orientador: Divanilson Rodrigo de Sousa Campelo.

1. Segurança da informação. 2. Criptografia. 3. Sistemas embarcados. I.

005.8 CDD (23. ed.) UFPE- MEI 2017-232

Sistema Embarcado para Comunicação Intraveicular Segura em

Dissertação de Mestrado apresentada ao

Aprovado em: 09/09/2016.

Primeiramente agradeço a Deus por sempre me guiar, ajudar e me dar forças

Nos últimos anos, a falta de medidas de segurança em protocolos de comu-

Palavras-chave: Redes Intraveiculares. Segurança da Informação. Criptografia. Siste-

The lack of security in current in-vehicle communication protocols has brought

Keywords: In-vehicle Networks. Information Security. Cryptography. Embedded Sys-

Figura 1 – Comparação do número de linhas de código entre veículos e aplica-

Tabela 1 – Lista de atributos de segurança . . . . . . . . . . . . . . . . . . . . 63

ABS Anti-lock Breaking System

ADAS Advanced Driver Assistance Systems

AES Advanced Encryption Standard

ARP Address Resolution Protocol

AUTOSAR Automotive Open System Architecture

AVB Audio/Video Bridging

CAN Controller Area Network

CAT 5 Category 5 Cable

CCU Communication Control Unit

CMC Common Mode Choke

DAS Driver Assistance Systems

DHCP Dynamic Host Configuration Protocol

DoIP Diagnostic communication over Internet Protocol

DTC Diagnostic Trouble Code

ECU Electronic Control Unit

EMC Electromagnetic Compatibility

EMI Electromagnetic Interference

ESP Encapsulating Security Payload

EVITA E-safety Vehicle Intrusion Protected Applications

GCM Galois/Counter Mode

GPS Global Positioning System

GRE Generic Routing Encapsulation

ICMP Internet Control Message Protocol

IKEv2 Internet Key Exchange version 2

IPsec Internet Protocol Security

ISO International Organization for Standardization

LAN Local Area Network

LAND Local Area Network Denial

LIN Local Interconnect Network

LVDS Low-Voltage Differential Signaling

MAC Medium Access Control

MAC Message Authentication Code

MACsec Media Access Control Security

MAN Metropolitan Area Network

MLT Multi-Level Transmit

MOST Media Oriented Systems Transport

NDP Neighbor Discovery Protocol

OABR OPEN Alliance BroadR-Reach

OBD On-board Diagnostics

ONU Organização das Nações Unidas

OPEN Alliance One Pair EtherNet Alliance

OSI Open Systems Interconnection

PHY Physical Layer