Download PDF
ads:
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
II
Dados Internacionais de Catalogação-na-Publicação (CIP)
Divisão Biblioteca Central do ITA/CTA
Netto, João Evangelista
Segurança em Redes de Telecomunicações Aeronáuticas e seu desempenho em canal VDL modo 2 /
João Evangelista Netto.
São José dos Campos, 2005.
Número de folhas no formato 91f.
Tese de mestrado – Engenharia eletrônica e Computação – Telecomunicações
Instituto Tecnológico de Aeronáutica, 2005. Orientador: Dr. Alessandro Anzaloni.
1. Segurança de redes. 2. ATN. 3. VDL. I. Centro Técnico Aeroespacial. Instituto Tecnológico de
Aeronáutica. Engenharia Eletrônica e Computação. II.Título
REFERÊNCIA BIBLIOGRÁFICA –
NETTO, João Evangelista. Segurança em Redes de Telecomunicações Aeronáuticas e seu
desempenho em canal VDL modo 2. 2005. 91 folhas. Tese de mestrado – Instituto
Tecnológico de Aeronáutica, São José dos Campos.
CESSÃO DE DIREITOS –
NOME DO AUTOR: João Evangelista Netto
TÍTULO DO TRABALHO: Segurança em Redes de Telecomunicações Aeronáuticas e seu
desempenho em canal VDL modo 2
TIPO DO TRABALHO/ANO: Tese / 2005
É concedida ao Instituto Tecnológico de Aeronáutica permissão para reproduzir cópias desta
tese e para emprestar ou vender cópias somente para propósitos acadêmicos e científicos. O
autor reserva outros direitos de publicação e nenhuma parte desta tese pode ser reproduzida
sem a autorização do autor.
___________________________
João Evangelista Netto
ads:
III
Segurança em Redes de Telecomunicações Aeronáuticas e seu
desempenho em canal VDL modo 2
João Evangelista Netto
Composição da Banca Examinadora:
Prof Dr. David Fernandes ............Presidente - ITA
Prof. Dr. Alessandro Anzaloni ....Orientador - ITA
Prof Dr. Waldecir João Perrella ..ITA
Prof Dr. Edgar Toshiro Yano ......ITA
Prof Dr. Ricardo Varela Correa ..INPE
ITA
IV
Dedicatória
À minha família.
V
Agradecimentos
A Deus, todo poderoso.
Ao meu orientador Dr. Alessandro Anzaloni.
A minha família.
Aos amigos feitos nessa jornada.
Especialmente ao meu amigo Edésio, pela ajuda com o software Opnet Modeler.
VI
Epígrafe
A imaginação é mais importante que o conhecimento.
Albert Einstein
VII
Resumo
Este trabalho tem por objetivo analisar o desempenho da solução de segurança
definida pela ICAO (International Civil Aviation Organization) para a ATN (Aeronautical
Telecommunication Network) que é uma rede global para prover serviço de comunicação de
dados para aviação civil. Depois de uma apresentação de arquitetura e serviços ATN e uma
revisão sobre questões de criptografia e segurança de rede, é proposto um cenário
desenvolvido no software de simulação de redes Opnet Modeler para caracterizar o
desempenho obtido com e sem segurança. Neste cenário, aeronaves executam
simultaneamente a função Logon da aplicação CM (Context Management), responsável pelo
início, autenticação e manutenção de sessões (conexões data link) entre aeronave e estação
terrestre. Atendendo a restrição de atraso fim a fim, imposta ao padrão ATN, a sub-rede do
cenário proposto mostrou suportar até 50 aeronaves simultaneamente executando CM-Logon
em um canal VDL modo 2 com a solução de segurança proposta pela ICAO para a ATN.
VIII
Abstract
This work has for objective to analyze the performance of defined security's solution
by ICAO (International Civil Aviation Organization) for ATN (Aeronautical
Telecommunication Network) that is a global network to provide data communication
services for civil aviation. After an architecture presentation and ATN services and a revision
on cryptography subjects and network security, a proposed scenery is developed in the
software of simulation of networks Opnet Modeler to characterize the performance obtained
with and without security. In this scenery, aircrafts execute the Logon function
simultaneously of the application CM (Context Management), responsible for the beginning,
authentication and maintenance of sessions (connections date link) between aircraft and
ground station. Assisting the requirement of end to end delay, imposed to the ATN standard,
the sub-net of the proposed scenery showed to support up to 50 aircrafts simultaneously
executing CM-Logon in a channel VDL mode 2 with security's solution proposed by ICAO
for ATN.
IX
Sumário
DEDICATÓRIA..................................................................................................................................................IV
AGRADECIMENTOS.........................................................................................................................................V
EPÍGRAFE..........................................................................................................................................................VI
RESUMO ...........................................................................................................................................................VII
ABSTRACT......................................................................................................................................................VIII
SUMÁRIO............................................................................................................................................................IX
LISTA DE FIGURAS .........................................................................................................................................XI
LISTA DE TABELAS.......................................................................................................................................XII
LISTA DE ABREVIATURAS E SIGLAS .....................................................................................................XIII
1. INTRODUÇÃO ...............................................................................................................................................15
2. PADRÃO ATN ................................................................................................................................................17
2.1. HISTÓRICO.................................................................................................................................................. 17
2.2. CNS/ATM.................................................................................................................................................. 19
2.3. VISÃO GERAL DA ATN ............................................................................................................................... 20
2.4. ARQUITETURA ATN ...................................................................................................................................22
2.4.1. A camada de transporte.....................................................................................................................24
2.4.2. A camada de rede...............................................................................................................................25
2.4.3. A camada de enlace...........................................................................................................................26
2.5. SERVIÇOS ATN ..........................................................................................................................................26
3. CRIPTOGRAFIA E SEGURANÇA DE REDE ...........................................................................................28
3.1. MECANISMOS DE SEGURANÇA ....................................................................................................................30
3.1.1. Criptografia simétrica .......................................................................................................................30
3.1.2. Criptografia assimétrica....................................................................................................................31
3.1.3. Funções hash .....................................................................................................................................33
3.2. ESQUEMAS CRIPTOGRÁFICOS...................................................................................................................... 33
3.2.1. Assinatura digital...............................................................................................................................34
3.2.2. Estabelecimento de chaves.................................................................................................................35
3.2.3. Keyed Message Authentication Code.................................................................................................36
3.3. SISTEMAS CRIPTOGRÁFICOS ATUAIS ........................................................................................................... 37
3.3.1. Problema de fatoração de inteiros – RSA..........................................................................................38
3.3.2. Problema de logaritmos discretos – DH e DSA.................................................................................40
3.3.3. Problema de logaritmos discretos em curvas elípticas – ECC (Elliptic Curve Cryptography).........42
3.4. COMPARAÇÃO ENTRE SISTEMAS CRIPTOGRÁFICOS ..................................................................................... 44
3.4.1. Segurança ..........................................................................................................................................44
3.4.2. Desempenho dos algoritmos..............................................................................................................46
4. SEGURANÇA NA ICAO PARA ATN..........................................................................................................48
4.1. VULNERABILIDADES E REQUISITOS DE SEGURANÇA NA ATN ..................................................................... 48
4.2. INFRA-ESTRUTURA DE CHAVE PÚBLICA ...................................................................................................... 50
4.2.1. Arquitetura.........................................................................................................................................51
4.2.2. Formato do certificado ......................................................................................................................52
4.3. SOLUÇÃO DE SEGURANÇA ATN..................................................................................................................54
4.3.1. Fase inicial ........................................................................................................................................56
4.3.2. Estabelecimento da sessão CM..........................................................................................................57
4.3.3. Comunicações ar-solo subseqüentes..................................................................................................61
4.4. DETALHAMENTO DA APLICAÇÃO CONTEXT MANAGEMENT – CM.............................................................. 62
4.4.1. CM Logon Request e CM Logon Response........................................................................................65
5. SIMULAÇÃO E RESULTADOS...................................................................................................................69
5.1. O SOFTWARE DE SIMULAÇÃO OPNET MODELER ......................................................................................... 70
X
5.2. CENÁRIO CRIADO........................................................................................................................................ 72
5.2.1. Modelo ATN desenvolvido no Opnet Modeler...................................................................................74
5.2.1.1. Camada data link – VDL modo 2....................................................................................................75
5.2.1.2. Camada de rede..............................................................................................................................78
5.2.1.3. Camada de transporte.....................................................................................................................80
6. RESULTADOS................................................................................................................................................82
6.1. ANTES DOS SERVIÇOS DE SEGURANÇA ........................................................................................................ 84
7. CONCLUSÃO .................................................................................................................................................88
8. REFERÊNCIAS BIBLIOGRÁFICAS...........................................................................................................90
XI
Lista de figuras
FIGURA 1 – SISTEMA DE NAVEGAÇÃO AÉREA CONCEBIDO PELO COMITÊ FANS........................... 20
FIGURA 2 – AMBIENTE ANTERIOR À ATN ..................................................................................................21
FIGURA 3 – AMBIENTE ATN ...........................................................................................................................22
FIGURA 4 – COMPONENTES ATN................................................................................................................... 23
FIGURA 5 – ARQUITETURA DE PROTOCOLOS EM CAMADAS................................................................24
FIGURA 6 – ESTRUTURA DE ENDEREÇAMENTO ATN.............................................................................. 25
FIGURA 7 – CRIPTOGRAFIA SIMÉTRICA......................................................................................................31
FIGURA 8 – CRIPTOGRAFIA ASSIMÉTRICA................................................................................................. 32
FIGURA 9 – ASSINATURA DIGITAL...............................................................................................................34
FIGURA 10 – ESTABELECIMENTO DE CHAVES.......................................................................................... 35
FIGURA 11 – CÓDIGOS MAC ........................................................................................................................... 37
FIGURA 12 – COMPARAÇÃO QUANTO AOS NÍVEIS DE SEGURANÇA................................................... 45
FIGURA 13 – INTEGRANTES DA PKI ATN ....................................................................................................51
FIGURA 14 – CERTIFICADO X.509 .................................................................................................................. 53
FIGURA 15 – COMPONENTES DO CENÁRIO SIMULADO ..........................................................................69
FIGURA 16 – PILHA DE PROTOCOLOS UTILIZADA NA SIMULAÇÃO .................................................... 70
FIGURA 17 – EDITORES DO OPNET MODELER ........................................................................................... 70
FIGURA 18 – CENÁRIO DA SIMULAÇÃO CM-LOGON................................................................................ 73
FIGURA 19 – ENCERRAMENTO DE ATIVIDADE NO CENÁRIO................................................................ 74
FIGURA 20 – COMPRIMENTO EM BITS DAS MENSAGENS CM-LOGON REQUEST E CM-LOGON
RESPONSE .................................................................................................................................................75
FIGURA 21 – MODELO DA CAMADA DATA LINK VDL MODO 2...............................................................76
FIGURA 22 – MAQUINA DE ESTADOS DA SUBCAMADA DE ACESSO AO MEIO (MAC)..................... 76
FIGURA 23 – ATRASO FIM-A-FIM AO LONGO DE UMA HORA DE SIMULAÇÃO .................................82
FIGURA 24 – TEMPO DE RESPOSTA DA APLICAÇÃO AO LONGO DE UMA HORA DE SIMULAÇÃO83
FIGURA 25 – VAZÃO AO LONGO DE UMA HORA DE SIMULAÇÃO........................................................ 84
FIGURA 26 – ATRASO FIM-A-FIM AO LONGO DE UMA HORA DE SIMULAÇÃO .................................85
FIGURA 27 – TEMPO DE RESPOSTA DA APLICAÇÃO AO LONGO DE UMA HORA DE SIMULAÇÃO86
FIGURA 28 – VAZÃO AO LONGO DE UMA HORA DE SIMULAÇÃO........................................................ 87
XII
Lista de tabelas
TABELA 1 – COMPARAÇÃO QUANTO AOS NÍVEIS DE SEGURANÇA – IEEE P1363 ............................ 46
TABELA 2 – TEMPOS PARA ASSINATURA DIGITAL (MILISEGUNDOS EM UM PENTIUM PRO
200MHZ) [13]..............................................................................................................................................46
TABELA 3 – TEMPOS DE OPERAÇÕES COM CURVAS ELÍPTICAS SOBRE COM 163 BITS EM
MILISEGUNDOS NUM PENTIUM III – 450 MHZ.................................................................................. 47
m
F
2
TABELA 4 – RESUMO DOS ESQUEMAS DA SOLUÇÃO DE SEGURANÇA ATN ..................................... 55
TABELA 5 – DETALHAMENTO DA MENSAGEM CM-LOGON REQUEST................................................ 66
TABELA 6 – DETALHAMENTO DA MENSAGEM CM-LOGON RESPONSE.............................................. 68
TABELA 7 – COMPARAÇÃO ENTRE AS FUNÇÕES DOS PROTOCOLOS CLNP E IP .............................. 79
TABELA 8 – COMPARAÇÃO DAS FUNÇÕES DOS PROTOCOLOS TCP E TP4......................................... 81
XIII
Lista de abreviaturas e siglas
AAC - Aeronautical Administrative Communications
AAIM - Aircraft Autonomous Integrity Monitoring
ACARS - Aircraft Communications Addressing and Reporting System
ACC - Area Control Centre
ADS - Automatic Dependent Surveillance
ADS-B - Automatic Dependent Surveillance - Broadcast
ADSP - Automatic Dependent Surveillance Panel
ADSS - ATN Digital Signature Scheme
AEEC - Airlines Electronic Engineering Committee
AFTN - Aeronautical Fixed Telecommunications Network
AINSC - Aeronautical Industry Service Communication
AMACS - ATN Keyed Message Authentication Code Scheme
ANC - Air Navigation Commission
ANS Air Navigation Services
AOC - Aeronautical Operational Control
ATC - Air Traffic Control
ATM - Air Traffic Management
ATN - Aeronautical Telecommunication Network
ATNP - ATN Panel
ATS - Air Traffic Services
ATSC - Air Traffic Services Communications
CA - Certification Authority
CLNP - Connectionless Network Protocol
CM - Context Management
CNS/ATM - Communications Navigation Surveillance/Air Traffic Management
CPDLC - Controller-Pilot Data Link Communications
CSMA - Carrier Sense Multiple Access
D8PSK - Differentially encoded 8-Phase Shift Keying
DES - Data Encryption Standard
DFIS - Data Link Flight Information Service
DLS - Data Link Service
ECDSA - Elliptic Curve Digital Signature Algorithm
ES - End System
FAA - Federal Aviation Administration
FANS - Future Air Navigation System
FIS - Flight Information Services
GNSS - Global Navigation Satellite System
GPS - Global Positioning System
HDLC - High Level Data Link Control
HF - High Frequency (3-30MHz)
HMAC - Hashed Message Authentication Code
ICAO - International Civil Aviation Organisation
IDEA - International Data Encryption Algorithm
IEC - International Electrotechnical Committee
IEEE - Institute of Electrical and Electronics Engineers
IPv4 - Internet Protocol Version 4
ISO - International Standards Organisation
LME - Link Management Entity
XIV
MAC - Media Access Control
MAC - Message Authentication Code
OSI - Open Systems Interconnection
PKI - Public Key Infrastructure
QoS - Quality of Service
SARPs - Standards and Recommended Practices
SHA-1 - Secure Hash Algorithm
TCP - Transmission Control Protocol
UDP - User Datagram Protocol
VDL - VHF Digital Link
VHF - Very High Frequency (30 - 300 MHz)
VME - VDL Management Entity
15
1. Introdução
Anteriormente à rede ATN, para estarem na área de cobertura de comunicação,
aeronaves eram obrigadas a percorrer rotas ineficientes aumentando o gasto com tempo e
combustível, estimados em bilhões de dólares anuais. A definição de um padrão internacional
permitirá conectividade entre sistemas heterogêneos podendo ser utilizadas as infra-estruturas
já implantadas. Automatização de mensagens rotineiras antes baseadas apenas em voz é
apenas um dos possíveis serviços.
Estas vantagens têm levado a Europa e USA a implementar a rede ATN; contudo
atualmente somente partes do sistema foram realmente implementadas. No Brasil a rede ATN
ainda está em fase de projeto.
Mas, com a mudança dos ATCs (Sistemas de Controle de Tráfego Aéreo) de um
ambiente somente de voz para um no qual dados são emitidos via enlace digital, existe risco
que uma entidade não autorizada tente se passar por um piloto ou controlador [1]. Para se
proteger deste e outros ataques relacionados, comunicações ar-terra devem ser seguras. O
desafio é adicionar segurança a um ambiente no qual largura da banda é limitada.
É objetivo deste trabalho estudar o impacto da solução de segurança no desempenho
da rede, obtendo via simulação a vazão do sistema e o atraso fim-a-fim dos pacotes; bem
como o número máximo de usuários suportados para que determinados requisitos de
desempenho não sejam desobedecidos.
É importante observar que não existem muitos trabalhos voltados para a problemática
de análise de desempenho de soluções de segurança e escalabilidade do sistema na rede ATN.
Este trabalho tem como ponto de partida dois trabalhos anteriores [2] e [3], onde o primeiro
endereçou somente o desempenho do VDL modo 2 na presença de ruído e múltiplo acesso e o
segundo apenas as vulnerabilidades e soluções de segurança na ATN. Basicamente este
16
trabalho simulou a arquitetura de comunicação inteira considerando as camadas de aplicação
(aplicativos de segurança), transporte, rede, enlace e física.
No capítulo 2 é apresentado um histórico sobre o esforço realizado para a
padronização da comunicação na aviação civil posicionando o leitor sobre características e
serviços previstos.
O capítulo 3 é uma introdução básica aos conceitos relevantes de segurança como
ameaças de segurança, serviços de segurança e mecanismos de segurança. Mecanismos de
segurança são examinados mais adiante apresentando fundamentos de criptografia simétrica,
criptografia assimétrica, funções hash e descrevendo então como as técnicas fundamentais
podem ser combinadas para formar esquemas criptográficos.
A seguir, o capítulo 4 descreve vulnerabilidades e requisitos de segurança na Rede de
Telecomunicações Aeronáutica (ATN), os esquemas criptográficos definidos e a sua
aplicação específica na segurança de comunicação em enlaces digitais.
No capítulo 5 é feita a analise de desempenho utilizando simulação a fim de se definir
a capacidade de um servidor CM em atender pedidos de aeronaves para início de sessão em
um canal VDL modo 2 usando as solução de segurança da rede ATN.
Finalmente nos capítulos 6 e 7 são apresentados resultados da simulação e discussão
dos resultados obtidos.
17
2. Padrão ATN
O padrão ATN será apresentado a seguir fornecendo inicialmente um histórico, seu
papel no sistema CNS/ATM, sua arquitetura de comunicações e finalmente os serviços que
oferece.
2.1. Histórico
Com a crescente limitação nos sistemas de navegação aérea no início dos anos 80,
decorrente do aumento na demanda e necessidade de novas aplicações, a ICAO (International
Civil Aviation Organization), reconhecendo a necessidade de melhorias, estabeleceu em 1983,
o comitê especial FANS (Future Air Navigation Systems), com a tarefa de estudar, identificar
e avaliar novas tecnologias e fazer recomendações, coordenando assim, o desenvolvimento da
navegação aérea para os próximos vinte e cinco anos [4].
FANS enfatizou a necessidade de comunicação digital sobre diferentes enlaces de
dados aeronáuticos (HF, VHF ou satélite), recomendando também a adoção dos princípios da
arquitetura ISO (International Standards Organization) OSI (Open Systems Interconnection)
para prover interoperabilidade no desenvolvimento de enlaces de dados aeronáuticos. O
comitê completou sua tarefa em 1988 com o conceito do sistema de comunicação, navegação
e vigilância (CNS – Communication, Navigation, and Surveillance), baseado largamente em
satélites que possibilitaria a evolução do gerenciamento de tráfego aéreo (ATM – Air Traffic
Management) e que permitiria a aviação civil mundial superar as limitações do sistema atual e
tirar proveito de tecnologias modernas a fim de sustentar o crescimento da aviação no século
XXI.
Como a realização deste conceito envolveria um alto grau de cooperação internacional
de esforços entre administradores de aviação civil, organizações internacionais, provedores de
serviços e usuários, a ICAO estabeleceu um novo comitê especial cuja tarefa era desenvolver
18
um plano coordenado global. O FANS II realizou seu primeiro encontro em junho de 1990 e
concluiu o plano em 1993, o qual continha diretrizes de transição para o sistema CNS/ATM,
incluindo recomendações de implementação progressiva e ordenada com custo-benefício
oportuno. O conselho da ICAO aprovou o plano em 1994.
Em janeiro de 1989 a ANC (Air Navigation Commission) expandiu os assuntos
referentes ao SICASP (Secondary Surveillance Radar Improvements and Collision Avoidance
Systems Panel) para incluir o material desenvolvido pela ICAO como necessário para permitir
a máxima interoperabilidade praticável entre enlaces ATS (Air Traffic Services), incluindo
enlaces de satélite. O trabalho feito pelo SICASP resultou no conceito da ATN (Aeronautical
Telecommunication Network) que pretendia suportar a comunicação computador a
computador operada por autoridades de aviação civil e agencias operacionais aeronáuticas.
No seu quarto encontro, em maio de 1989 o SICASP desenvolveu uma descrição da
ATN e recomendou sua publicação como um manual ICAO. A primeira edição do manual foi
publicada em 1991 e a segunda edição foi recomendada para publicação no quinto encontro
do painel em março de 1997. SARPs (Standards and Recommended Practices) e material de
orientação foram aprovados em março de 1997 e incluso no anexo 10.
Seguido da conclusão, pelo SICASP, da segunda edição do manual ATN, a ANC (Air
Navigation Commission) transferiu o trabalho do desenvolvimento de SARPs e material de
orientação ATN para o ATNP (ATN Panel). No primeiro encontro, ATNP/1 em junho de
1994, foi acordado que o ATNP desenvolveria draft SARPs e material de orientação que
incluiria recomendações técnicas para a rede, as camadas superiores e um conjunto limitado
de aplicações ar/terra e terra/terra para definir a implementação operacional inicial da ATN.
19
2.2. CNS/ATM
Os quatro principais componentes do sistema CNS/ATM [1], como mostrado na
Figura 1, são descritos a seguir:
• Comunicação (Communication): Nos sistemas CNS/ATM, inicialmente, a
transmissão de voz continuará acontecendo sobre canais VHF (Very High Frequency);
porém, com um aumento cada vez maior do uso destes canais para transmitir dados
digitais. Dados de satélite e comunicações de voz, capaz de cobertura global, também
estão sendo introduzidos junto com transmissão de dados em canais HF (high
frequency). O SSR (Secondary Surveillance Radar Mode S) que está sendo cada vez
mais usado para vigilância em espaço aéreo de alta densidade tem a capacidade de
transmitir dados digitais entre ar e terra. ATN proverá o intercâmbio de dados digitais
entre usuários finais sobre sub-redes ar-terra e terra-terra diferentes. Novas
possibilidades no gerenciamento do trafego aéreo surgirão uma vez que será permitido
acoplamento mais direto e eficiente entre sistemas automatizados ar-terra auxiliando a
comunicação de piloto/controlador.
• Navegação (Navigation): A introdução progressiva da RNAV (area navigation) com
o sistema GNSS (global navigation satellite system) proverá cobertura navegacional
mundial e aproximações sem precisão. Com o aprimoramento apropriado e
procedimentos relacionados, é esperado que estes sistemas também apóiem
aproximações de precisão.
• Vigilância (Surveillance): Tradicionais radares SSR (secondary surveillance radar)
continuarão sendo usados, enquanto é introduzido gradualmente o Modo S em áreas
terminais e espaço aéreo continental de alta densidade. Porém, a inovação principal é a
implementação da ADS (automatic dependent surveillance). ADS permite a aeronave
20
transmitir automaticamente informações de seu FMS (flight management system)
como sua posição, proa, velocidade e outras, por satélite ou outro canal disponível.
• Gerenciamento de Trafego Aéreo (Air Traffic Management): Considerando a
implementação de todas as melhorias esperadas do sistema CNS, provavelmente o
maior beneficiário seja o gerenciamento de trafego aéreo. Muito mais que controle de
tráfego aéreo o sistema permitirá a administração de fluxo de tráfego e espaço aéreo.
Um sistema ATM integrado globalmente permitiria operadoras administrar seus vôos
conforme suas trajetórias preferidas, dinamicamente, de maneira a otimizar a relação
custo-eficiência.
Figura 1 – Sistema de navegação aérea concebido pelo comitê FANS
2.3. Visão geral da ATN
O ambiente anterior à ATN (Figura 2) é baseado no uso de transmissões de voz em
VHF e HF sujeitas a todos os problemas de idioma, taxa de transferência de informação lenta,
alta carga de trabalho, possibilidade de erros, etc.
21
Figura 2 – Ambiente anterior à ATN
Devido às suas características de propagação o uso de VHF é limitado à comunicação
de linha de visada e a cobertura global, obviamente, não é possível.
Comunicações de HF móveis, atualmente, são as únicas disponíveis para propagação
além do horizonte e têm limitações de confiabilidade como resultado da variabilidade de
características de propagação.
A ATN (Figura 3) integrará vários meios de comunicações, inclusive o AMSS
(Aeronautical Mobile Satellite Service), VHF data link, SSR (Secondary Surveillance Radar
mode S), HF data link e redes terra-terra privadas/públicas. Baseada no modelo de referência
ISO OSI, a ATN fornecerá serviços de comunicações de dados a Serviço de Tráfego Aéreo
(ATS), a organizações provedoras e agências operadoras de aeronave para os seguintes tipos
de tráfego de comunicações [4]:
• Comunicação de Serviço de Tráfego Aéreo (ATSC - Air Traffic Services
Communications)
• Controle Operacional Aeronáutico (AOC - Aeronautical Operational Control)
• Comunicação Administrativa Aeronáutica (AAC - Aeronautical Administrative
Communications)
22
• Comunicação de Passageiro Aeronáutica (APC - Aeronautical Passenger
Communications)
Figura 3 – Ambiente ATN
A ATN oferece os serviços de comunicações anteriormente citados de acordo com
prioridades estabelecidas e exigências de segurança.
2.4. Arquitetura ATN
Os componentes de infra-estrutura principais do ATN [5], conforme apresentado na
Figura 4 são a subrede, roteadores ATN (IS) e os sistemas finais (ES). A subrede faz parte da
rede de comunicação, mas não faz parte do ATN, sendo definida como uma rede de
comunicação independente baseada em uma tecnologia de comunicação particular que é
usada como meio físico para transferir informação entre sistemas ATN.
23
Subrede Subrede Subrede
Sistema
Intermediário (IS)
Sistema
Intermediário (IS)
Sistema
Final (ES)
Aplicação
Camadas
superiores
Camadas
inferiores
Sistema
Final (ES)
Aplicação
Camadas
superiores
Camadas
inferiores
Figura 4 – Componentes ATN
Uma variedade de subredes terra-terra e ar-terra provêem a possibilidade de múltiplos
caminhos de dados entre sistemas finais. Roteadores ATN são responsáveis para conectar
vários tipos de subredes. Eles roteam pacotes de dados por estas subredes, baseados na classe
de serviço pedida e na disponibilidade atual da infra-estrutura de rede (por exemplo, rotas
satisfatórias para o sistema de destino) e implementam políticas de roteamento. Os sistemas
finais ATN hospedam aplicação e as camadas da pilha de protocolo se comunicam em pares.
A ATN é baseada no modelo de referencia ISO OSI e utiliza seus protocolos de
comunicação padrões. As sete camadas do modelo (Figura 5) indicam um dos princípios
fundamentais do modelo OSI modela que é a "comunicação ponto a ponto”, isto é, cada
camada em cada sistema se comunica com a sua correspondente no sistema remoto e não está
preocupada com os mecanismos subjacentes usados para prover o diálogo.
O modelo de referência é construído em uma arquitetura de camadas introduzida com
o padrão X.25 na qual são identificados dois tipos de sistemas:
• End Systems (sistemas finais): que são computadores host que possuem todas as sete
camadas de protocolo que junto provêem um serviço de comunicações às aplicações
do usuário.
24
• Intermediate systems (sistemas intermediário): que são tipicamente chamados de
roteadores e possuem somente as três camadas inferiores, responsáveis por rotear e
retransmitir pacotes, além de interconectar tipos diferentes de subredes.
Figura 5 – Arquitetura de protocolos em camadas
Considerando que este trabalho está mais interessado em aspectos da rede de
comunicações, a seguir são dados maiores detalhes da camada de transporte, rede e enlace da
ATN
2.4.1. A camada de transporte
A camada de transporte ATN provê transferência de dados transparente entre usuários
do serviço de transporte. Todos os protocolos definidos na camada de transporte têm um
significado “fim-a-fim” onde os “fins” são definidos como entidades de transporte co-
operacionais nos dois computadores hosts ATN. O protocolo de transporte só opera entre
sistemas finais. Entidades da camada de transporte se comunicam usando serviços da camada
de rede ATN.
Há dois modos do serviço de transporte – CLTS (Connectionless mode Transport
Service) e COTS (Connection-mode Transport Service). O CLTS permite que dois usuários
de transporte troquem datagramas individuais, sem controle de fluxo ou a necessidade de
25
estabelecer uma conexão previamente, mas sem garantia de entrega. O COTS permite que
dois usuários do serviço de transporte negociem um canal de comunicações com um conjunto
de características comuns, incluindo entrega segura de unidades de dados e garantindo (com
probabilidade muito alta) ordem de entrega.
Os dois protocolos OSI que provêem os dois modos do serviço de transporte têm
especificações separadas, e opera independentemente. O protocolo CLTS é especificado na
norma ISO/IEC 8602, e o protocolo COTS é especificado na norma ISO/IEC 8073 Classe 4.
2.4.2. A camada de rede
A camada de rede OSI, assim como a camada de transporte OSI é especificada para
prover um modo orientado a conexão e um modo não orientado a conexão. Porém, na ATN o
serviço da camada de rede é restringido só ao modo não orientado a conexão. Isto porque,
diferente da camada de transporte, os mesmos protocolos de rede devem ser implementados
ao longo de todo sistema da subrede.
Um endereço OSI NSAP (Network Acces Point) único é necessário para cada sistema
ATN. Este endereçamento de 20 octetos é baseado na norma ISO/IEC 8348 (Figura 6).
AFI
Authority
Format
Identifier
IDI
Initial Domain
Identifier
VER
Version
ADM
Administration
RDF
Routing
Domain
Format
ARS
Administrative
Regional
Selector
LOC
Location
SYS
System
Identifier
SEL
NSAP
Selector
Initial Domain Part (IDP) Domain Specific Part (DSP)
20 Octetos / 160 bits
Figura 6 – Estrutura de endereçamento ATN
A estrutura de um endereço ATN segue uma hierarquia de responsabilidades os três
primeiros campos são designados pela OSI para a ICAO e garantem que os endereços ATN
sejam únicos mundialmente. Os dois campos seguintes são designados pela ICAO e garantem
26
um mesmo prefixo para cada administração ou organização participante da ATN que por sua
vez designam endereços para seus sistemas usando o restante dos campos. Resumidamente:
• RDP – Routing Domain Part: identifica a organização responsável pelo domínio de
roteamento da aplicação. É formado pelos campos VER, ADM, e RDF.
• ARS – Administrative Region Selector: usado para distinguir domínios de roteamento
operados pelo mesmo Estado (na aeronave, é seu endereço de 24 bits);
• LOC – Location: usado para distingüir áreas de roteamento dentro de um domínio;
• SYS – System Identifier: identifica um ES (End System) dentro de uma área de
roteamento;
• SEL – Network Service Access Point Selector: identifica a entidade de rede de um ES;
2.4.3. A camada de enlace
Uma das principais exigências ATN é suportar rede de dados móveis (tipicamente
aeronave). As três subredes cujo uso é esperado na ATN são Mode S data link, Aeronautical
Mobile Satellite Service (AMSS) e VHF Data Link (VDL).
2.5. Serviços ATN
As aplicações CNS/ATM-1 especificadas para a primeira fase do desenvolvimento da
ATN têm os propósitos seguintes:
• Context Management (CM): provê meios para descobrir serviços de comunicações
dentro de uma determinada região de vôo e também de, um sistema terrestre ou
controlador, direcionar a aplicação CM de uma aeronave a contatar uma região de vôo
diferente - talvez como um preliminar handover entre domínios CM distintos, ou seja,
áreas cujo gerenciamento é feito por autoridades diferentes.
27
• Automatic Dependent Surveillance (ADS): é projetado para dar relatórios
automáticos de uma aeronave para um sistema terrestre. Esta informação é provida:
por demanda – quando disparada por um evento – periodicamente e em uma
emergência. Posição e trajetória da aeronave e dados meteorológicos são usos típicos
deste serviço.
• Controller-Pilot Data Link Communications (CPDLC): provê comunicação
bidirecional incluindo um conjunto de mensagens clearance/information/request
(autorização de partida, informação e requisição), que correspondem ao diálogo de voz
atual empregado em procedimentos de ATC.
• Flight Information Services (FIS): pode suportar vários serviços de informação,
provendo informação terrestre para uma aeronave, incluindo informação sobre um
aeroporto, como pistas em uso e condições de tempo.
• ATS Interfacility Data Communication (AIDC): provê a troca de informação ATC,
como notificações de região limite de vôo para vôos que chegam.
• Aeronautical Message Handling System (AHMS): provê a troca e distribuição de
mensagem entre unidades de tráfego aéreo. Pode ser usado adicionalmente para prover
novos serviços de mensagens incluindo correio eletrônico e troca de dado eletrônico.
Está baseado na recomendação ITU X.400.
Todas as aplicações anteriores usam serviço de comunicação orientado a conexão.
28
3. Criptografia e segurança de rede
As ameaças a um sistema de segurança computacional podem ser classificadas como
ativas ou passivas [1]. Ameaças passivas não alteram o estado de um sistema. Inclui-se nesta
categoria a escuta (eavesdropping), que envolve a escuta de mensagens trocadas. Uma
contramedida para isso é a encriptação.
Ameaças ativas causam uma mudança não-autorizada do estado de um sistema, e
ameaças nesta categoria incluem:
• Mascaramento: personificação de um usuário autorizado de um sistema de modo a
fazer uso não-autorizado do mesmo.
• Modificação: modificação não-autorizada de informação detida por um sistema ou
trocada entre sistemas.
• Replay: a exata repetição de uma transação prévia, para uso não-autorizado.
• Repúdio: um usuário autorizado negando envolvimento em uma transação prévia
atribuída a este usuário.
• Negação de serviço: indisponibilidade de um serviço a um usuário autorizado.
Tais ameaças podem se manifestar na forma de ataques, fazendo-se necessária a
utilização de mecanismos de segurança que forneçam ao sistema um ou mais serviços de
segurança. Tais conceitos são apresentados a seguir:
• Ataque – qualquer ação que compromete a segurança da informação detida por uma
organização.
• Mecanismo de segurança – mecanismo criado para detectar, prevenir ou remediar
um ataque.
29
• Serviço de segurança – serviço que provê a segurança no processamento dos dados e
na transferência de informações em uma organização. Os serviços devem combater
ataques, e fazem uso de um ou mais mecanismos de segurança.
A seguir são definidos alguns serviços de segurança importantes para o
desenvolvimento deste trabalho:
• Confidencialidade (privacidade ou sigilo): assegura que a informação armazenada ou
transmitida está acessível apenas a partes autorizadas.
• Autenticidade: assegura que a origem de uma mensagem ou documento está
corretamente identificada, sendo a identidade verdadeira.
• Integridade: assegura que qualquer modificação na informação pode ser feita apenas
pelas partes autorizadas.
• Não-repúdio: previne que nem o remetente nem o destinatário da mensagem possam
negar uma transmissão efetivamente realizada.
• Controle de acesso: requer que o acesso aos recursos de informação seja controlado
pelo ou para o sistema.
• Disponibilidade: Requer que os recursos estejam disponíveis às partes autorizadas
quando necessário.
Segurança física provavelmente é o mecanismo de segurança em uso mais comum
hoje. Compreendido por mecanismos de segurança que controlam acesso físico a sistemas
reais. Por exemplo, fechaduras em portas, ou acesso restrito somente ao pessoal autorizado
em salas de computadores. Porém, enquanto segurança física é um mecanismo essencial para
a proteção de ativos físicos, tem aplicação limitada nas comunicações. Dutos de cabo lacrados
podem estender segurança física para fora do ambiente da sala dos computadores, mas assim
30
que haja uma necessidade de comunicação fora do perímetro protegido pela segurança física,
outros mecanismos são necessários.
Funcionalidade de confiança é essencial em tais situações. Aqui são referidas as
funções embutidas que restringe acesso à operação de um sistema a usuários autorizados, para
tarefas autorizadas, e que são provados (através de avaliação) a executar esta tarefa.
Funcionalidade de confiança é o mecanismo que impede atacantes de ganhar acesso e
fazer uso de um sistema por enlaces de comunicação que são desprotegidos por medidas de
segurança física. Isto requer mecanismos para identificar e autenticar usuários autorizados e
proteger a integridade e confidencialidade de dados enquanto transitam sobre tais enlaces de
comunicação.
Senhas podem prover meio de autenticar usuários autorizados. Porém, são facilmente
registradas e reenviadas oferecendo assim só um impedimento limitado. Geralmente
mecanismos de criptografia são aplicados. Estes podem prover confidencialidade, integridade,
autenticação e são os únicos mecanismos que podem proteger dados em trânsito em enlaces
de comunicação desprotegidos.
Dois tipos de mecanismos de criptografia são possíveis. Criptografia simétrica
baseado em uma única chave secreta, e criptografia assimétrico que usa um par de chaves:
uma pública, a outra privada.
3.1. Mecanismos de segurança
3.1.1. Criptografia simétrica
Criptografia é a técnica de se escrever em cifra, e tem sido usada bem antes de sua
aplicação computacional, inclusive durante o Império Romano, para cifrar mensagens por
31
Júlio César. Na criptografia de hoje, a mensagem é cifrada e decifrada com o uso de
seqüências de bits chamadas chaves.
A criptografia simétrica (ou criptografia de chave única ou secreta) tem como
princípio a existência de uma única chave secreta compartilhada para cifrar e posteriormente
decifrar as mensagens. O processo é resumido na Figura 7. Esta chave deve ser conhecida
apenas pelo remetente e pelo destinatário das mensagens, o que implica na existência de um
canal seguro para que a chave seja trocada sem que um atacante possa descobri-la [6], [7].
Figura 7 – Criptografia simétrica
A vantagem deste método é sua simplicidade, o que se traduz em tempo de execução
menor dos algoritmos. Além disso, o tamanho da chave necessária para obter um bom nível
de segurança é da ordem de meia centena de bits. Por estas razões ela é adequada para
encriptação em massa, de longas mensagens.
3.1.2. Criptografia assimétrica
A principal característica da criptografia assimétrica é o fato de existirem duas chaves
diferentes, uma é usada pelo remetente para cifrar a mensagem, e outra pelo receptor para
decifrá-la. O par de chaves exibe uma relação matemática, mas deve ser computacionalmente
inviável determinar uma a partir da outra. Uma chave é a chamada chave pública, e pode ficar
disponível publicamente em diretórios, por exemplo. A outra, a chave privada, deve ser
mantida em segredo pelo seu proprietário.
32
O processo é resumido na Figura 8. Neste método, quando uma usuário A deseja
enviar uma mensagem criptografada para um outro usuário B, ela encripta a mensagem
usando a chave pública de B, que fica disponível a qualquer pessoa. Ao receber a mensagem
cifrada, B usa sua chave privada para obter a mensagem original. Nota-se então que somente
B pode ler a mensagem a ele destinada, pois só ele conhece sua chave privada. Esta também
não pode ser determinada a partir da chave pública [6], [7].
Figura 8 – Criptografia assimétrica
No modelo clássico de criptografia (criptografia simétrica), A e B tinham que escolher
secretamente uma chave
K
, que dava origem uma regra para cifrar e uma regra para
decifrar . Nos sistemas criptográficos que seguem este modelo, é igual a , ou então
é facilmente obtido a partir de .
K
e
K
d
K
d
K
e
K
e
Um grande inconveniente da criptografia simétrica é a necessidade de haver a prévia
troca da chave
K
entre A e B, através de um canal seguro. Isto pode representar um sério
impedimento em diversas situações onde não é possível estabelecer um canal seguro.
A idéia que dá origem à criptografia de chave pública (criptografia assimétrica) é a
possibilidade de haver um sistema em que não é computacionalmente factível obter dado
. Neste sistema, seria a chave pública, que poderia ser publica em um diretório, por
exemplo. A vantagem é que qualquer pessoa pode enviar uma mensagem para B usando a
chave pública, sem a necessidade de trocar uma chave através de um canal seguro. B será a
única pessoa que poderá ler a mensagem, pois somente ele possui a chave privada .
K
d
K
e
K
e
K
d
33
Em 1976, Diffie e Hellman propuseram a idéia de um sistema criptográfico de chave
pública. No ano seguinte, Rivest, Shamir e Adleman inventaram o conhecido sistema RSA,
que deve seu nome a seus criadores. Posteriormente, outros sistemas foram propostos, alguns
dos quais serão descritos mais adiante neste texto.
Sistemas de chave pública podem ser construídos usando um certo tipo de função
chamado trapdoor one-way function. Estas funções são chamadas one-way por serem fácies
de calcular, mas difíceis de inverter. Ou seja, sendo
)
xf uma função one-way, é fácil
calcular , porém, dado , é difícil encontrar o
()
xfy =
y
x
correspondente. Se houver uma
informação que permita a inversão de
)
xf
então a função é dita trapdoor one-way function.
Então esta informação (a trapdoor) torna fácil a inversão da função.
A criptografia assimétrica tem grande utilidade para implementação de assinaturas
digitais, como será visto adiante.
3.1.3. Funções hash
Uma função hash é aquela que, dado um valor arbitrariamente longo
M
, faz o
mapeamento de
M
em um valor
)
MH cujo comprimento é curto e fixo. As funções hash
têm grande utilidade nos esquemas criptográficos descritos a seguir, como assinaturas digitais.
Existem diversos algoritmos de funções hash, e na solução de segurança adotada para
a rede ATN o algoritmo utilizado é o SHA-1, que cria resumos de comprimento de 20 octetos.
3.2. Esquemas criptográficos
A seguir são apresentados esquemas que, utilizando mecanismos de criptografia,
oferecem os serviços de segurança vistos anteriormente e são utilizados na ATN.
34
3.2.1. Assinatura digital
As assinaturas digitais garantem autenticidade, ou seja, funcionam como uma prova da
origem de uma mensagem, da mesma forma que as assinaturas reais.
A assinatura digital é enviada junto com a mensagem, e é um hash da mesma, cifrado
com a chave privada do remetente. Ao recebê-la, o receptor computa o hash da mensagem,
decifra o hash anexado à mensagem usando a chave pública do suposto remetente e compara
os dois. Se forem iguais, a autenticidade está garantida. A Figura 9 mostra este processo.
Figura 9 – Assinatura digital
As assinaturas digitais geradas através de algoritmos de criptografia assimétrica são
não-repudiáveis, uma característica muito importante. Isso acontece porque uma pessoa que
deseja enviar uma mensagem gera a assinatura digital usando a sua chave secreta e a
autenticação é feita na recepção usando a chave pública. Como apenas a pessoa que enviou a
mensagem conhece sua chave privada, somente ela poderia ter gerado a mensagem. Em
compensação qualquer um pode autenticar a mensagem, pois a chave pública é conhecida de
todos.
No entanto, existe um problema ligado à distribuição das chaves públicas. Como são
amplamente distribuídas, é difícil garantir que uma chave pública é genuína. Um atacante
pode substituir a chave de uma pessoa por uma falsa, e assim, personificá-la.
Uma solução encontrada para este problema é emissão de certificados emitidos por
Autoridades de Certificação (CA). Este certificado garante que uma chave pública pertence de
fato à pessoa para a qual ele é emitido. O processo é o seguinte:
35
Um certificado contém a chave pública de uma pessoa, sua identidade, e a assinatura
da CA. Esta assinatura é formada da maneira explicada acima. Quem quiser ter a garantia da
chave pública desta pessoa deve obter a chave pública da CA, verificar a assinatura da CA no
certificado e obter a chave desejada.
3.2.2. Estabelecimento de chaves
Trata-se de um esquema que permite que duas pessoas (A e B) estabeleçam uma chave
secreta compartilhada através de um canal inseguro. A partir daí podem ser usados outros
esquemas eficientes baseados em chave simétrica, como criptografia simétrica e códigos
MAC. O princípio está mostrado na Figura 10.
Figura 10 – Estabelecimento de chaves
O Diffie-Hellman Key Exchange é um esquema deste tipo. Ele funciona da seguinte
forma:
• A e B devem combinar dois números primos grandes, n e , sendo que algumas
condições se aplicam a estes números e eles podem ser públicos.
g
• Em seguida A pega um número grande
x
e B pega um número grande
y
. Eles devem
guardar estes números para si, em segredo.
• A, então, envia para B uma mensagem contendo: ngxmod
36
• B responde com o valor: ngymod
• A pega este número que B enviou e computa:
)
xngymod
• B executa uma operação semelhante para obter
)
yngxmod . Ambos os cálculos, de A
e
B, dão o mesmo resultado: ngxymod
• Agora eles compartilham uma chave secreta, que é o número acima.
Mesmo que as mensagens trocadas sejam gravadas por um atacante, não será possível
achar os números
x
e
y
, pois dado não é computacionalmente viável encontrar ngxmod
x
.
O esquema ATN Key Agreement Scheme (AKAS) adotado para a ATN usa uma
variante do método Diffie-Hellman Key Exchange baseada em curvas elípticas
[8].
3.2.3. Keyed Message Authentication Code
O Keyed Message Authentication Code é um apêndice transmitido junto com conteúdo
de uma mensagem que pode ser usado para verificar a integridade e a autenticidade da
mensagem. É essencialmente um resumo (às vezes chamado de selo) da mensagem, gerado
usando uma chave secreta através de uma função hash, por exemplo. O processo está
mostrado na
Figura 11: A gera um hash de sua mensagem e o cifra usando uma chave secreta
(muitas vezes chamada chave de sessão) previamente acordada com
B (por exemplo, através
de um esquema de estabelecimento de chaves). O hash cifrado é o código MAC (Message
Authentication Code). Ela envia para
B a mensagem e o código MAC, e este calcula um novo
MAC com a mensagem enviada e sua chave secreta. Se o MAC calculado por
B e o MAC
enviado por
A forem iguais, então B sabe que A é de fato a remetente da mensagem, pois só
ela conhece a chave secreta.
B tem também a certeza de que a mensagem não foi alterada
durante a transmissão, ou seja, sua integridade é garantida.
37
Figura 11 – Códigos MAC
Um código bastante popular é o Hashed Message Authentication Code (HMAC).
HMAC pode ser usado com qualquer função hash, como, por exemplo, SHA-1 ou MD5.
HMAC é a base para o Keyed Message Authentication Code Scheme da ATN (AMACS), e a
função hash usada é SHA-1
[8].
3.3. Sistemas criptográficos atuais
Existem três problemas ditos matematicamente complexos, nos quais se baseiam
diversos dos sistemas de criptografia de chave pública em uso hoje
[8]:
• Problema de fatoração de inteiros (Integer Factorization Problem – IFP), em que se
baseia, por exemplo, o RSA;
• Problema de logaritmos discretos (Discrete Logarithm Problem – DLP), tendo como
exemplo DSA;
• Problema de logaritmos discretos em curvas elípticas (Elliptic-Curve Discrete
Logarithm Problem – ECDLP), no qual é baseado o ECC (Elliptic Curve
Cryptography);
Um problema é dito matematicamente difícil se o algoritmo mais rápido para resolvê-
lo leva um tempo longo relativamente ao tamanho de suas entradas. Algoritmos de tempo
polinomial rodam em um tempo curto em relação a suas entradas, e um exemplo é o algoritmo
de soma: assim como é trivial adicionar números pequenos, existe um algoritmo que soma
números enormes em um tempo curto. O mesmo não acontece com algoritmos de tempo
38
exponencial, como algoritmos de fatoração. Apesar de ser simples fatorar números pequenos,
o mesmo não acontece para números grandes. Assim, fatoração é um problema
matematicamente complexo, ao passo que soma é um problema simples.
Ao projetar um sistema criptográfico, procuram-se problemas cujos algoritmos
possuem tempo de execução exponencial. Em termos gerais, quanto mais tempo leva o
algoritmo de resolução de um problema, mais seguro será o sistema criptográfico baseado
neste problema.
Os três tipos sistemas de criptografia de chave pública citados acima são considerados
hoje seguros e eficientes. A seguir cada um deles será descrito brevemente.
3.3.1. Problema de fatoração de inteiros – RSA
A segurança do algoritmo RSA baseia-se na dificuldade de fatorar inteiros de grande
dimensão, e para entender seu funcionamento é preciso recorrer a princípios de aritmética
modular, propriedades de números primos, e outros conceitos matemáticos relativamente
simples. A seguir o algoritmo é brevemente descrito
[9].
Inicialmente descreveremos o mecanismo de geração de chaves na seqüência abaixo:
• Escolhe-se dois números primos p e q grandes
• Calcula-se: q
p
n ×=
• Em seguida calcula-se:
)
)
)
11
−
×
−
=
Φ qpn , que é o fator de Euler de , ou seja, é
o número de inteiros positivos menores que n e primos relativamente a .
n
n
• Escolhe-se um inteiro tal que: e
)
)
1,gcd
=
Φ
en ;
)
ne
Φ
<
<
1 , ou seja, e é primo
relativamente a . (Onde
()
nΦ
)
gcd é greatest common divisor – máximo divisor
comum)
39
• Calcular tal que: d
)
ned Φ=
−
mod
1
d =e−1modΦ(n), de modo que seja o menor
primo relativamente a .
d
Φ
Após esta seqüência, tem-se que a chave pública é dada por
{
}
ne, e pode ser enviada
através de um canal inseguro, ao passo que a chave privada é dada por
{}
. nd,
Digamos agora que um remetente queira cifrar um texto e enviá-lo a um destinatário,
dado o par de chaves do destinatário como definido acima. Os passos abaixo mostram como o
texto é cifrado e em seguida decifrado pelo destinatário segundo o RSA.
• Para que a função de cifrar seja usada, a mensagem deve ser quebrada em blocos cujo
tamanho é menor que .
n
• Em seguida, a função de cifrar é usada. Sendo
M
a mensagem a ser cifrada e C o
bloco codificado, tem-se que:
)
nMC
e
mod= , sendo
{
}
ne, a chave do destinatário,
previamente enviada para o remetente.
• Ao receber
C
, o destinatário usa a função de decifrar: , sendo
(
nMC
d
mod=
)
{
}
nd, a
sua chave privada, e assim obtém a mensagem original.
Para que o algoritmo seja seguro, é certamente necessário que q
p
n ×= tenha
dimensão suficientemente grande para que a operação de fatoração não seja
computacionalmente factível. Geralmente recomenda-se que
p
e tenham dimensão de 512
bits, de modo que tenha dimensão de 1024 bits.
q
n
Anteriormente foi dito que uma trapdoor one-way function permite a criação de
sistemas de chave pública. No RSA, a função:
)
)
nxxf
e
mod= , é uma função deste tipo. A
40
função inversa tem uma forma similar, mas para calculá-la precisa-se do valor , que é
obtido através dos fatores de . Portando a trapdoor é a fatoração de .
d
n n
Na última metade do século 20, houve um brutal progresso com relação à operação de
fatoração. Isto se deve ao desenvolvimento de algoritmos mais eficientes aliado ao aumento
do poder de cálculo dos computadores disponíveis.
3.3.2. Problema de logaritmos discretos – DH e DSA
O problema dos logaritmos discretos (DLP) é a base de diversos dos sistemas
criptográficos em uso, entre eles Diffie-Hellman Key Exchange (DH) e o Digital Signature
Algorithm (DSA). Para todos os esquemas baseados no DLP existem análogos para curvas
elípticas, assunto do próximo item.
Pode-se definir o DLP da seguinte forma
[9]:
Dado , com n
x
mod
αβ
=
)
10
−
≤
≤
nx é relativamente fácil calcular
β
dados
α
,
x
e , mas é relativamente difícil calcular
n
x
dados
β
,
α
e .
n
O NIST (National Institute of Standards and Technology) propôs o Digital Signature
Algorithm (DSA) em 1991 e adotou-o como padrão em 1994.
Neste como em outros esquemas de assinaturas digitais, o que é assinado é um
“resumo” da mensagem (hash) que aqui possui 160 bits. A geração das chaves no DSA
acontece da forma explicada a seguir. O algoritmo de hash não é mostrado, portanto supõe-se
que se deseja assinar um bloco de 160 bits.
Para gerar suas chaves,
A inicialmente escolhe:
• Um número primo de 160 bits e outro número primo
q
p
tal que
(
é múltiplo
de
)
1−p
q
• Um número
g
• Uma chave privada tal que
A
K 11
−
<
<
qK
A
41
• A em seguida calcula uma chave pública: pgP
A
K
A
mod=
• Por fim A publica
p
, , q
g
e
A
P
O procedimento para
A assinar sua mensagem
)
m é o seguinte:
• A seleciona randomicamente tal que k
11
−
<
<
qk
• A calcula:
o
(
)
qpgr
K
modmod=
o
()
mhashe =
o
()
rKeks
A
+=
−1
• A envia
(
junto com a mensagem
)
sr,
)
m .
B ao receber a mensagem
'
m e a assinatura anexada executa a seqüência de cálculos
abaixo para verificar a procedência da mensagem:
• qsh mod
1−
=
•
''
mhashe =
• qheh mod
'
1
=
• qrhh mod
2
=
•
21
h
A
h
Pgv =
Se
r
v =
, a assinatura é válida.
O esquema de troca de chaves proposto por Diffie e Hellman (Diffie-Hellman Key
Exchange) foi descrito no item
3.2.2.
42
3.3.3. Problema de logaritmos discretos em curvas elípticas – ECC (Elliptic Curve
Cryptography)
Curvas elípticas têm sido estudadas intensamente por matemáticos há mais de um
século, e no que tange a criptografia, têm tido uso em diversas aplicações tais como
algoritmos de fatoração e testes de primalidade (verificação de ser um número primo ou não).
Em 1985 Neal Koblitz e Victor Miller propuseram de forma independente o uso de
pontos em curvas elípticas nos sistemas de criptografia baseados no problema de logaritmos
discretos. Como ocorre com todos os sistemas criptográficos (e especialmente aqueles de
chave pública) levam-se muitos anos de estudo e avaliações até que seja atingido um nível
adequado de confiança em um novo sistema. Atualmente sistemas criptográficos baseados em
curvas elípticas são usados em diversas aplicações, como segurança de e-mails, web, smart
cards, e outras. A seguir será dada uma breve descrição deste tipo de sistema
[10].
Uma curva elíptica é o conjunto de soluções de uma equação da forma:
64
2
2
3
31
2
axaxaxyaxyay +++=+=
Curvas elípticas podem ser definidas sobre corpos finitos com características diversas,
sendo os mais comuns os corpos primos ( ) e os corpos binários ( ). Um corpo finito
é um conjunto finito de elementos com operações binárias (adição e multiplicação). O número
de elementos que pertencem ao corpo é chamado de ordem do mesmo. Existem várias
escolhas possíveis, sendo duas as mais comuns: corpos primos ( ) e corpos binários ( ).
Um corpo primo possui
P
F
m
F
2
F
P
F
m
F
2
p
elementos inteiros menores que um primo
p
, e as operações
implementadas usam aritmética modular ( ). Um corpo binário contém elementos,
sendo um inteiro (grau do corpo). Os elementos são cadeias de bits de tamanho e as
operações implementadas são operações sobre bits
pmod
m
2
m m
[9].
Uma curva elíptica sobre os números reais tem uma forma simplificada:
43
baxxy ++=
232
Já foi dito neste texto que para cada esquema criptográfico baseado no problema dos
logaritmos discretos existe uma variação baseada em curvas elípticas. Portanto é necessário
definir (ainda que informalmente) o problema dos logaritmos discretos para curvas elípticas
(ECDLP –
Elliptic-Curve Discrete Logarithm Problem). O ECDLP é baseado na dificuldade
de inverter a multiplicação de dois pontos em uma curva. Tem-se a equação: , onde
e
kPQ = Q
P
são pontos na curva elíptica e é um número grande. Dados e k k
P
é fácil calcular ,
mas dados
Q e
Q
P
é difícil determinar . k
Como exemplo, será mostrado abaixo o procedimento para o método Diffie-Hellman
para curvas elípticas.
•
A e B escolhem publicamente um corpo finito , uma curva elíptica
q
F
E
e um ponto
fixo na curva
S
E
;
•
A gera randomicamente um número para ser sua chave privada;
A
k
•
B faz o mesmo com um número ;
B
k
•
A calcula e publica sua chave publica: SkP
AA
=
;
•
B calcula e publica sua chave publica: SkP
BB
=
;
•
A calcula: ; SkkPkP
BABA
==
•
B calcula: ; SkkPkP
ABAB
==
Agora, os dois usuários compartilham um valor secreto, o ponto
P
. Qualquer
informação derivada deste ponto pode ser usada como chave de sessão.
44
3.4. Comparação entre sistemas criptográficos
A comparação entre os três sistemas citados anteriormente levará em conta dois
aspectos: segurança e tempos de execução dos algoritmos (desempenho).
3.4.1. Segurança
Como foi dito anteriormente, a complexidade do melhor algoritmo de resolução de um
problema dá uma medida da segurança do sistema criptográfico baseado neste problema.
Os algoritmos de resolução podem ser divididos em algoritmos específicos (
special-
purpose algorithms
) e algoritmos genéricos (general-purpose algorithms): Algoritmos
específicos resolvem um problema somente em determinados casos, nos quais os parâmetros
do problema seguem alguma condição específica (“pontos fracos” do problema). No caso do
problema de curvas elípticas, por exemplo, existem duas classes de curvas para as quais o
problema pode ser facilmente resolvido por um algoritmo específico. Ao contrário, algoritmos
genéricos resolvem o problema qualquer que seja o caso em questão, não importando os
parâmetros.
Para cada um dos três problemas citados, existem algoritmos específicos que resolvem
rapidamente o problema para alguns casos. Como tais casos são conhecidos, deve-se sempre
checar se estes não estão sendo usados de modo a garantir a segurança do sistema.
Existem também algoritmos genéricos para os três problemas. Estes levam muito
tempo em sua execução, mas resolvem sempre o problema, quaisquer que sejam os
parâmetros. Para comparar os três sistemas quanto à segurança que apresentam, é preciso
avaliar o tempo de execução de cada um dos respectivos algoritmos genéricos. A ordem de
grandeza deste tempo será um indicativo da segurança do sistema em questão.
O problema de fatoração de inteiros (IFP) e o problema de logaritmos discretos (DLP)
admitem algoritmos genéricos de resolução que rodam em tempo sub-exponencial
[11]. Isso
45
significa em termos gerais que estes dois problemas devem ser considerados menos
complexos que aqueles que admitem apenas solução de tempo exponencial. Este é o caso do
problema de curvas elípticas (ECDLP): o melhor algoritmo de solução para este problema é
integralmente exponencial. Assim pode-se dizer que atualmente o ECDLP é considerado mais
complexo que o IFP e o DLP. Em termos práticos, é por este motivo que criptosistemas
baseados em curvas elípticas requerem chaves menores que os outros sistemas, para um
mesmo nível de segurança, como será visto a seguir.
A
Figura 12 mostra uma comparação feita entre os tempos para quebrar sistemas
representantes dos três problemas (RSA para o IFP, DSA para o DLP e ECC para o ECDLP).
Os valores estão em MIPS-ano. Um MIPS-ano representa a quantidade de computação de um
ano em uma máquina capaz de executar um milhão de instruções por segundo. Aceita-se
geralmente que MIPS-ano representa um nível de segurança razoável
12
10
[11].
Figura 12 – Comparação quanto aos níveis de segurança
46
Pelo gráfico apresentado, pode-se ver que para atingir o nível de segurança
especificado, RSA e DSA devem usar 1024 bits, enquanto que 160 bits são suficientes para
ECC. Além disso, a diferença entre os sistemas cresce quando o tamanho da chave aumenta.
Dados semelhantes são mostrados na
Tabela 1, proveniente da norma IEEE P1363 [12], onde
é feita a mesma comparação.
Tabela 1 – Comparação quanto aos níveis de segurança – IEEE P1363
IFP e DLP
Bits
ECDLP bits
Processamento
MIPS-ano
512 128
5
4.10
1024 172
12
103.
2048 234
21
3.10
4096 314
33
10.2
3.4.2. Desempenho dos algoritmos
Existem diversas fontes de informação sobre tempos de execução dos principais
algoritmos criptográficos, sobretudo na Internet. A
Tabela 2 abaixo mostra uma comparação
entre tempos de computação para assinaturas digitais. O tamanho dos corpos é de
aproximadamente 191 bits.
Tabela 2 – Tempos para assinatura digital (milisegundos em um Pentium Pro 200MHz) [13]
RSA – 1024
( ) 3e =
DSA – 1024
ECDSA sobre
1912F
m
≅
ECDSA sobre
()
191pF ≅
Assinar
43.3 7 11.3 6.3
Verificar
0.65 28.3 60 26
Geração de chave
1000 7 11.7 5.5
Os dados apresentados mostram que a verificação de assinatura usando RSA é bem
mais rápida que quando se utiliza DSA/ECDSA. No entanto, alguns estudos alegam que
expoentes baixos comprometem a segurança do sistema. Vê-se também a grande diferença
47
entre os tempos de geração de chaves para RSA e para ECDSA/DSA. Na operação de
assinatura ECDSA/DSA também levam vantagem.
A
Tabela 3 mostra tempos de execução para curvas elípticas sobre o corpo finito ,
onde . Este é o corpo finito usado para as aplicações ATN
m
F
2
163=m [14].
Tabela 3 – Tempos de operações com curvas elípticas sobre com 163 bits em milisegundos num
Pentium III – 450 MHz
m
F
2
EC Diffie-Hellman EC Digital Signature Algorithm
Sem pré-
computação
Com pré-
computação
Assinatura (sem
pré-computação)
Assinatura (com
pré-computação)
Verificação
12.2 6.75 12.2 6.75 16.32
Os tempos apresentados são de operações de assinatura (usando ECDSA) e de
estabelecimento de chaves (usando ECDH) para curvas elípticas sobre , com 163 bits.
Tais tempos foram obtidos de
m
F
2
[15].
48
4. Segurança na ICAO para ATN
No capítulo anterior foram estudados os sistemas criptográficos que podem ser
utilizados para prover segurança nas comunicações de redes computacionais. A ATN é uma
rede sujeita a ameaças que poderiam implicar em sérios danos à comunidade aeronáutica,
sendo, portanto, necessário estudar uma solução criptográfica que satisfaça os requisitos de
segurança. A Edição 3 das SARP na rede ATN
[14] define uma solução de segurança para as
comunicações ar-solo e ar-ar que envolve criptografia de chave pública. Neste trabalho será
estudada a solução para as comunicações ar-solo, ou seja, entre uma aeronave que deseja
utilizar aplicações da ATN e as próprias entidades das aplicações no solo. A aplicação CM
(especificamente sua função CM-Logon) desempenha um papel fundamental nesta solução. O
CM-Logon tem como objetivo estabelecer uma sessão entre a aeronave e o solo, para que
outras aplicações ATN possam ser utilizadas. Na solução de segurança, é durante o CM-
Logon que acontece a autenticação das partes e o estabelecimento de chaves de sessão para a
comunicação posterior.
O item
4.1 identifica as vulnerabilidades e requisitos de segurança da rede ATN,
definidos pelo ATN Panel. O item
4.2 apresenta a infra-estrutura de chave pública (PKI)
adotada e o item
4.3 descreve passo a passo a solução de segurança adotada para a rede ATN
para o cenário estudado neste trabalho.
4.1. Vulnerabilidades e requisitos de segurança na ATN
Requisitos de segurança são conseqüência da existência de ameaças ao funcionamento
adequado de um sistema ou organização. Entretanto, a existência de uma ameaça não implica
necessariamente em uma vulnerabilidade do sistema no que diz respeito a esta ameaça. Uma
determinada ameaça pode existir sem afetar o sistema e, se isso acontece, ele não está
vulnerável à mesma.
49
Assim, uma organização deve identificar as possíveis ameaças existentes, selecionar
quais são as que se traduzem como uma vulnerabilidade, e onde justificável, tomar
contramedidas para eliminar ou limitar tais vulnerabilidades.
O ATN Panel estudou as possíveis ameaças às comunicações na rede ATN e
identificou as seguintes vulnerabilidades
[1]:
•
Um atacante pode personificar um controlador de tráfego aéreo ou um piloto de modo
a passar falsas instruções;
•
As mensagens podem ser modificadas em trânsito;
•
Vários ataques do tipo indisponibilidade de serviço podem ocorrer incluindo jamming
nas transmissões, injeção de falsas rotas na rede e sobrecarga da rede com dados;
•
As informações de roteamento podem ser modificadas causando indisponibilidade de
serviço.
É importante notar que “
eavesdropping” (escuta) não é visto como vulnerabilidade
uma vez que as comunicações relativas ao controle de tráfego aéreo não são consideradas
confidenciais. No entanto, as comunicações das operadoras de aeronaves e dos passageiros
podem ser confidenciais e freqüentemente o são, cabendo às operadoras definirem seus
requisitos neste sentido.
A possibilidade de incluir o serviço de confidencialidade na solução de segurança da
ATN está sendo discutida no ATN Panel. A idéia é incluir tal serviço como opcional, de
modo que fosse utilizado apenas para comunicações para as quais o sigilo é importante. Ver
[8] para uma discussão a este respeito.
As contramedidas para os ataques do tipo indisponibilidade de serviço incluem
[1]:
•
Segurança física de modo a proteger instalações físicas no solo de destruição ou
interferência;
•
Detectores de sinal de modo a identificar transmissões não-autorizadas;
50
•
Múltiplos caminhos alternativos nas redes de modo a prevenir interrupções de rota; Os
demais tipos de ameaças requerem o uso de técnicas criptográficas. Na ATN, é
adotado um sistema criptográfico baseado em curvas elípticas.
Os requisitos de segurança para os sistemas finais foram definidos com base nas
ameaças acima. A solução de segurança da comunicação na rede ATN deve garantir:
•
Autenticidade da identidade dos sistemas;
•
Autenticidade da origem das mensagens das aplicações;
•
Integridade das mensagens das aplicações.
4.2. Infra-estrutura de chave pública
A fim de atender os requisitos apresentados no item anterior, a solução de segurança
empregada na ATN utiliza criptografia de chave pública. A PKI (Infra-estrutura de chave
pública) que será descrita a seguir tem como objetivo prover suporte para a distribuição das
chaves públicas para as entidades ATN, e assim possibilitar a operação da solução de
segurança.
Algumas definições são importantes para entender o significado de uma PKI. De
modo geral, chaves públicas estão sujeitas a modificações, pois estão disponíveis em
diretórios públicos. Uma Autoridade de Certificação (
Certification Authority - CA) é o meio
encontrado para evitar esta possível ameaça. Uma CA é uma entidade que possui
credibilidade de todas as partes envolvidas, e que emite certificados. Um certificado é um
item composto pelos seguintes dados:
•
O nome do proprietário da chave pública
•
A chave pública
•
O nome da CA
•
A data de validade da chave
51
•
Uma assinatura digital, formada pelo hash dos campos acima, cifrado com a chave
privada da CA.
A chave pública da CA é geralmente distribuída fisicamente para todas as partes
envolvidas, e estas então podem checar a validade de qualquer certificado emitido pela CA.
Na prática, são os certificados que são publicados, e não as chaves públicas. Assim,
mesmo que estejam disponíveis em diretórios públicos, ou que sejam transmitidos por canais
inseguros, pode-se verificar a integridade e a origem de uma chave pública, através da
verificação de seu certificado.
A PKI da rede ATN baseia-se na estrutura X.509, e o formato dos certificados
utilizados está de acordo com o perfil PKIX do padrão X.509.
4.2.1. Arquitetura
A Figura 13 mostra as entidades componentes da PKI [16].
Figura 13 – Integrantes da PKI ATN
A seguir cada uma dessas entidades será descrita. A ICAO é a detentora do controle da
PKI. Ela especifica o modo pelo qual a PKI opera, e efetua revisões periódicas. A ICAO
governa os estados (states) que por sua vez governam as entidades dentro do seu domínio
(área designada para o estado). Um estado designa uma entidade para agir como CA dentro de
seu domínio (
State CA), e recomenda-se que estados compartilhem CAs sempre que possível.
Uma CA de estado emite certificados para as entidades ATN dentro do domínio do estado,
52
tais como aplicações no solo e CAs de AOE (
Aircraft Operating Entity). É possível também
emitir certificados para outra CA de estado, de modo que entidades dentro do estado possam
obter chaves de entidades no outro estado, e também para uma CA de AOE de outro estado.
Deve ser também implementado por um estado um serviço de entrega de certificados
(
Certificate Delivery Service) cuja função é disponibilizar para as entidades ATN dentro do
domínio do estado os certificados que sejam necessários. Este serviço pode ser implementado
de várias maneiras, como diretórios, servidores, e outras. Uma AOE governa as aeronaves
dentro do seu domínio e designa uma CA de AOE para emitir certificados para suas
aeronaves.
4.2.2. Formato do certificado
O formato do certificado utilizado na infra-estrutura de chave pública da ATN baseia-
se no perfil PKIX do padrão X.509. Este formato está mostrado na
Figura 14. Várias
restrições são feitas para o uso deste formato na ATN, de forma a possibilitar a operação
efetiva da rede. Existem restrições aplicáveis para cada utilização de um certificado na ATN,
por exemplo, para certificados emitidos de uma CA de estado para outra, de uma CA de
estado para uma entidade de aplicação no solo, etc.
53
Figura 14 – Certificado X.509
No cenário estudado, é importante conhecer o formato específico do certificado de
chave pública emitido da CA de estado para a entidade CM no solo, uma vez que este
certificado será enviado para a aeronave como prova da autenticidade da chave. Será suposto
neste cenário que a aeronave e a entidade CM no solo compartilham a mesma CA de estado,
de modo que será necessário que a entidade CM no solo envie apenas um certificado para a
aeronave: o certificado da chave pública de estabelecimento de chave emitida pela CA de
estado. Caso esta suposição não fosse verdade, a entidade CM no solo deveria enviar também
o certificado que a CA de estado da aeronave emite para a CA de estado da entidade CM no
solo.
Ao invés de enviar o certificado completo, a entidade CM no solo envia uma forma
comprimida do mesmo, eliminando campos que, originalmente, traziam informações que a
aeronave pode deduzir. Por exemplo, o número da versão do certificado é sempre o mesmo na
54
ATN (versão 3), não sendo necessário enviar tal informação. Isso pode significar uma valiosa
economia uma vez que certificados geralmente são longos.
4.3. Solução de segurança ATN
A solução de segurança proposta para a ATN utiliza-se da aplicação Context
Management
para estabelecer uma comunicação segura entre a aeronave e o solo.
A ATN compreende algumas outras aplicações ar-solo, citadas anteriormente. No ar,
uma aeronave pode rodar cada uma das aplicações. No solo, o CM serve a uma região,
denominada domínio CM, enquanto outras aplicações, como CPDLC, podem rodar em um ou
mais lugares dentro de um domínio CM.
O principal propósito da solução de segurança é assegurar a autenticidade nas
comunicações ar-solo. A mesma solução também provê segurança nas comunicações solo-
solo, porém este aspecto não será discutido aqui, por fugir do cenário proposto na introdução.
Quando a aeronave entra em um domínio CM, segue-se um protocolo de estabelecimento de
sessão com a aplicação CM no solo, que envolve a confirmação da identidade das partes e o
estabelecimento de chaves que serão usadas para autenticar mensagens CM. Além disso, gera-
se um “valor público compartilhado” (
shared public value) cujo objetivo é ajudar na
segurança dos diálogos com outras aplicações, enquanto a aeronave estiver no domínio CM.
Assim, após o estabelecimento da sessão CM, quando outra aplicação, por exemplo CPDLC,
for usada, as unidades no solo e no ar deverão estabelecer chaves de sessão. Tais chaves são
calculadas usando, entre outros parâmetros, o valor público compartilhado.
O protocolo de estabelecimento de sessão pode ser iniciado pela aeronave ou pela
entidade CM no solo. O protocolo iniciado pela aeronave é utilizado quando a aeronave entra
no primeiro domínio CM, enquanto que o protocolo iniciado no solo é geralmente utilizado
nas comunicações com o segundo domínio CM e com os seguintes. O foco deste estudo está
55
no protocolo iniciado pela aeronave, ou seja, a aeronave entrando no domínio CM e
estabelecendo uma sessão com a estação CM no solo através do CM-Logon.
Tabela 4 – Resumo dos esquemas da solução de segurança ATN
Esquema Primitiva/Função Objetivo Entradas Saídas
ASP – ATN
Signature
Generation
Primitive
Assinar dados
utilizando o método
ECDSA
Dados a serem
assinados, chave
privada de
assinatura e
parâmetros
Usig
d
,
stan
T
Assinatura
digital dos
dados
ADSS – ATN
Digital
Signature
Scheme
AVP – ATN
Signature
Verification
Primitive
Verificar
assinaturas
utilizando o método
ECDSA
Dados, assinatura
a ser testada,
chave pública de
assinatura
Usig
Q
,
Válido ou
inválido
AKAS – ATN
Key Agreement
Scheme
ASVDP – ATN
Secret Value
Derivation Primitive
Calcular um valor
privado
compartilhado que
será utilizado para
estabelecimento de
chaves de sessão.
O método utilizado
é o ECDH
Chave privada
e chave
pública
Us
d
,
Vs
Q
,
Valor privado
compartilhad
o Z, base
para a função
AKDF que
forma a
chave de
sessão
AMACP – ATN
Message
Authentication
Code Generation
Primitive
Calcular um código
MAC de um
conjunto de dados,
usando o método
HMAC e a função
hash AHASH
Dados sobre os
quais o código
será calculado,
chave de sessão
de 20 octetos
Código MAC
de 32 bits dos
dados de
entrada
AMACS – ATN
Message
Authentication
Code Scheme
AMACVP – ATN
Message
Authentication
Code Verification
Primitive
Verificar a validade
de um código MAC
usando o método
HMAC e a função
hash AHASH
Dados, código
MAC a ser testado,
chave de sessão
de 20 octetos
Válido ou
inválido
AKDF – ATN Key
Derivation Function
Calcular uma
chave de sessão
Valor privado
comparilhado Z,
dados públicos
compartilhados
Chave de
sessão de 20
octetos
Funções
auxiliares
AHASH – ATN
Hash Function
Calcular valores
hash segundo a
função SHA-1
Dados sobre os
quais o hash será
calculado
Valor hash de
20 octetos
Para melhor entendimento dos procedimentos envolvidos, estes serão divididos e
apresentados a seguir nas seguintes fases: fase inicial (
setup na aeronave e no solo), fase de
operação durante o CM-Logon e fase de operação nas comunicações subseqüentes (quando
são utilizadas outras aplicações ar-solo).
56
Os principais esquemas e primitivas utilizados nas fases de citadas anteriormente
envolvidos na solução de segurança da rede ATN
[8] estão resumidos na Tabela 4.
4.3.1. Fase inicial
São três os procedimentos que a aeronave deve executar:
•
Seleção dos pares de chaves: a entidade U deve selecionar dois pares de chaves
baseados em curvas elípticas: um par de chaves estático para estabelecimento de
chaves (
static key agreement key pair) que consiste de uma chave privada e da
correspondente chave pública
Q
Us
d
,
stan,,
Gd
UsUs
=
para uso de todas as aplicações
embarcadas, para o esquema Diffie-Hellman para curvas elípticas; e um par de chaves
de assinatura (signing key pair) que consiste de uma chave privada e da
correspondente chave pública
Usig
d
,
stan,,
GdQ
UsigUsig
=
para uso da aplicação CM
embarcada, para assinaturas segundo o esquema ECDSA.
• Certificação das chaves públicas: a entidade U deve ter suas chaves públicas
certificadas pela CA (Autoridade de Certificação) correspondente a sua AOE (Aircraft
Operating Entity). Serão emitidos certificados separados para as chaves públicas:
Us
QUCert
,
, para a chave e
Us
Q
,
Usig
QU
,
,Cert para a chave . Os certificados
da aeronave devem ser amarzenados no solo e devem estar disponíveis em um serviço
de entrega de certificados (Certificate Delivery Service).
Usig
Q
,
•
Instalação da chave pública da CA de estado: a entidade U deve obter a chave pública
de assinatura de sua CA de estado. A aeronave utilizará esta chave para ajudá-la a
obter cópias autênticas das entidades CM no solo durante o CM-logon.
57
De modo semelhante ao que acontece na aeronave, são três os procedimentos que a
entidade CM no solo deve executar:
•
Seleção dos pares de chaves: a entidade V deve selecionar um par de chaves baseado
em curvas elípticas: trata-se de um par de chaves estático para estabelecimento de
chaves (static key agreement key pair) que consiste de uma chave privada e da
correspondente chave pública
Vs
d
,
stan,
G
Vs,
dQ
Vs
=
para uso no esquema Diffie-Hellman
para curvas elípticas.
•
Certificação da chave pública: a entidade V deve ter sua chave pública certificada por
sua CA (Autoridade de Certificação) de estado. Será emitido um certificado para a
chave pública
(
)
Vs
QVCert
,
, para a chave . Este deve ser amarzenado no solo e
deve estar disponível em um serviço de entrega de certificados (
Certificate Delivery
Service
).
Vs
Q
,
• Instalação da chave pública da CA de estado: a entidade V deve obter a chave pública
de assinatura de sua CA de estado. Esta chave será utilizada para ajudar a entidade a
obter cópias autênticas das chaves públicas de entidades CM embarcadas bem como
de entidades de outras aplicações no solo.
Qualquer outra entidade de aplicação no solo (aqui denominada
W ) deve seguir o
mesmo procedimento acima, ou seja, selecionar um pare de chaves, ter sua chave pública
certificada e instalar a chave pública da CA de estado.
4.3.2. Estabelecimento da sessão CM
A entidade CM embarcada inicia a comunicação segura com a entidade CM no solo da
seguinte maneira:
58
1.
A entidade CM embarcada forma uma mensagem CM-Logon Request que inclui sua
identidade (
U ), a identidade da entidade CM no solo (V ) e um campo de tempo,
entre outras informações (o item
4.4.1 descreve detalhadamente o conteúdo da
mensagem CM-Logon Request). Em seguida a entidade assina esta mensagem usando
o esquema ADSS (primitiva ASP) e sua chave privada , resultando uma
assinatura .
Usig
d
,
U
s
2.
A aeronave envia o CM-Logon Request acrescido da assinatura para a entidade CM no
solo. A entidade CM embarcada guarda a assinatura para uso posterior. A inclusão
da assinatura tem como objetivo confirmar a identidade da entidade CM embarcada
para a entidade CM no solo. A assinatura é usada ao invés de um MAC, pois neste
momento da comunicação ainda não foi possível estabelecer uma chave de sessão.
U
s
3.
A entidade CM no solo recebe a requisição enviada e recupera da mensagem as
identidades
U e V , e o campo de tempo. A entidade recupera os dois certificados das
chaves públicas (
Us
QUCert
,
,
e
Usig
QUCert
,
,
) da entidade CM embarcada e os
certificados intermediários que sejam necessários. Verifica os certificados
intermediários (se existirem) usando a chave pública de sua CA de estado e os
certificados da entidade CM embarcada. Uma vez checados os certificados, a entidade
CM no solo recupera a chave pública de assinatura a partir de seu certificado.
Ela pode então verificar a assinatura na mensagem recebida usando o esquema
ADSS (primitiva AVP) e a chave pública , e caso esta esteja correta, a
requisição de
login da entidade CM embarcada é aceita.
Usig
Q
,
U
s
Usig
Q
,
59
4.
A entidade CM no solo calcula um “valor público compartilhado” (shared public
value
) que será enviado a outras aplicações dentro do domínio CM. Antes, a
entidade recupera a chave pública a partir de seu certificado e em seguida calcula
o “valor privado compartilhado” (
shared private value) usando o esquema
AKAS (primitiva ASVDP) e usando como parâmetros e . Em seguida é
selecionado um valor randômico de 32 bits , e o valor de 160 bits é
calculado como segue:
VU
X
,
Us
Q
,
VU
Z
,
Vs
d
, Us
Q
,
V
Rand
VU
X
,
)
VUVU
RandsHASHX ||
,
=
, onde representa a função
de
hash SHA-1 e o sinal || significa a operação de concatenação. A entidade CM no
solo calcula então a chave de sessão CM usando a função AKDF com os
seguintes parâmetros: , , uma constante, e as identidades
U e V .
HASH
VU
MacKey
,
VU
Z
, VU
X
,
5.
A entidade CM no solo em seguida forma uma mensagem CM-Logon Response
contendo entre outros o parâmetro . Este é incluído para que a entidade CM
embarcada possa também computar o valor . Para garantir a autenticidade da
mensagem, é formado um código MAC da mensagem usando o esquema AMACS
(primitiva AMACP) e a chave de sessão CM .
V
Rand
VU
X
,
VU
MacKey
,
6.
Para que a aeronave possa se comunicar com outras aplicações no solo, a entidade CM
no solo deve enviar os identificadores das aplicações no solo e suas chaves públicas
para estabelecimento de chaves. No entanto, antes, é preciso que a entidade verifique
os certificados das chaves, obtidos junto ao
Certificate Delivery Service. Para detalhes
sobre o conteúdo da mensagem CM-Logon Response, ver o item
4.4.1.
60
7.
A entidade CM no solo envia a resposta para a aeronave, contendo o certificado de sua
chave pública (e os demais certificados intermediários se necessário), a mensagem
CM-Logon Request e o código MAC. O código MAC é enviado ao invés de uma
assinatura digital devido a restrições de banda passante.
8.
A entidade CM embarcada recebe o CM-Logon Response, verifica o certificado de
chave pública da entidade CM no solo, usando para isso a chave pública de sua CA de
estado, e recupera do certificado a chave pública . A aeronave então recupera o
valor e calcula o valor público compartilhado como segue:
, onde representa a função de
hash SHA-1 e o
sinal || significa a operação de concatenação. Calcula também o valor privado
compartilhado usando o esquema AKAS (primitiva ASVDP) usando como parâmetros
e . As propriedades matemáticas de curvas elípticas garantem que o valor
privado compartilhado calculado pela entidade CM embarcada é o mesmo que o
calculado pela entidade CM no solo.
Vs
Q
,
V
Rand
()
VUVU
RandsHASHX ||
,
= HASH
Us
d
, Vs
Q
,
9.
A entidade CM embarcada em seguida calcula a chave de sessão CM
usando a função AKDF com os seguintes parâmetros: , , uma constante, e as
identidades e
V . Novamente o valor calculado pela entidade CM
embarcada é o mesmo que o calculado pela entidade CM no solo.
VU
MacKey
,
VU
Z
, VU
X
,
U
VU
MacKey
,
10.
Finalmente, a entidade CM embarcada checa o código MAC recebido usando para isso
o esquema AMACS (primitiva AMACVP) e a chave de sessão CM . Caso
VU
MacKey
,
61
tenha sucesso na verificação, a entidade CM embarcada aceita a resposta e conclui que
uma sessão CM foi estabelecida.
4.3.3. Comunicações ar-solo subseqüentes
Após o estabelecimento da sessão CM, outras aplicações podem ser usadas, por
exemplo, CPDLC ou ADS. Para que estas outras aplicações possam se comunicar de modo
seguro, adota-se um procedimento baseado em códigos MAC. Sendo
Y
uma entidade de uma
aplicação embarcada e
W uma entidade da mesma aplicação no solo, tem-se abaixo um
resumo dos procedimentos de segurança adotados:
1.
A entidade de aplicação embarcada recupera através da entidade CM embarcada: a
chave privada da entidade CM embarcada , a chave pública da aplicação
(que a entidade CM embarcada obteve na mensagem CM-Logon Response) e o valor
público compartilhado .
Us
d
, Ws
Q
,
VU
X
,
2.
A entidade de aplicação embarcada calcula o valor privado compartilhado , de
forma semelhante ao que foi feito no estabelecimento de sessão CM. Em seguida
calcula a chave de sessão também como feito no estabelecimento de
sessão CM, usando como parâmetros
WU
Z
,
WY
MacKey
,
Y
, W , e .
WU
Z
, VU
X
,
3.
A entidade de aplicação no solo recupera via Certificate Delivery Service o certificado
da chave pública da entidade CM embarcada e os certificados intermediários que
sejam necessários. Verifica os certificados intermediários (se existirem) usando a
62
chave pública de sua CA de estado e o certificado da entidade CM embarcada. Uma
vez checados os certificados, a entidade no solo recupera a chave pública .
Us
Q
,
4.
A entidade de aplicação no solo recupera através da entidade CM no solo o valor
público compartilhado .
VU
X
,
5.
A entidade de aplicação embarcada calcula o valor privado compartilhado . Em
seguida calcula a chave de sessão usando como parâmetros
WU
Z
,
WY
MacKey
,
Y
, W ,
e . As propriedades matemáticas das curvas elípticas garantem que o valor
calculado pela entidade de aplicação embarcada é o mesmo que o
calculado pela entidade de aplicação no solo.
WU
Z
,
VU
X
,
WY
MacKey
,
6.
Agora as entidades possuem uma chave de sessão que podem usar para autenticar as
mensagens que queiram trocar. Para isso, utilizam um código MAC de modo
semelhante ao que foi feito no estabelecimento de sessão CM.
4.4. Detalhamento da aplicação Context Management – CM
O Context Management - CM, responsável por estabelecer uma sessão entre a estação
de solo e a aeronave, de modo que estas possam trocar informações sobre aplicações. A
aplicação CM é iniciada sempre pela aeronave, e é composta das seguintes funcionalidades:
• Logon: permite que aeronaves e sistemas no solo troquem informações sobre as
aplicações ATN;
63
• Update: permite que um sistema no solo modifique (atualize) as informações detidas
por uma aeronave;
• Contact: permite que um sistema no solo direcione uma aeronave para efetuar contato
com outro sistema no solo;
• Forward: permite que um sistema no solo direcione as informações uma aeronave
para outro sistema no solo;
• Registration: permite que sistemas no solo e aeronaves tornem disponíveis
informações sobre aplicações para outras aplicações e sistemas de comunicação
embarcados e no solo.
A partir da terceira edição da SARP, o CM desempenha um importante papel na
segurança da comunicação na ATN. De fato, durante o CM-Logon, a entidade CM embarcada
e a entidade CM no solo negociam as bases dos serviços de segurança que serão utilizados,
tanto para os diálogos da própria aplicação CM quanto para aqueles das aplicações que serão
posteriormente utilizadas.
O CM faz a função de um serviço de diretório, através do qual obtém-se endereços de
aplicações a partir dos nomes das mesmas. Aqui é necessário distinguir os dois termos: no
modelo de referência OSI, um nome é usado para identificar um objeto (sistema, entidade,
aplicação, etc.), enquanto que um endereço é usado para encontrar um objeto. Nomes
geralmente são mnemônicos com algum significado, enquanto que endereços são em formato
numérico. O nome é permanente, enquanto que o endereço pode mudar freqüentemente. Por
este motivo, faz-se necessário um serviço que armazene nomes e endereços e permita que,
dado um nome, seja possível obter o endereço correspondente.
A aplicação CM faz este papel: a entidade CM embarcada fornece ao solo os
endereços das aplicações embarcadas e vice-versa. Também a entidade CM embarcada
64
fornece para as aplicações embarcadas os endereços que estas precisam, fazendo a entidade
CM no solo o mesmo. Na ATN, os endereços de aplicações são os próprios endereços da
camada de transporte (TSAP -
Transport Service Access Point) pois as camadas de sessão e
apresentação não estão presentes. Já os nomes de aplicações nos termos OSI são chamados
ATN
application entity title (AE-Title) e identificam de forma única uma aplicação no
contexto da ATN. Um AE-Title é composto de um
application process title (AP-title) e de um
application entity qualifier (AE-qualifier). O AP-title é o nome do processo que contém a
aplicação e o AE-qualifier identifica de forma única a aplicação ATN. O AP-title de uma
aplicação hospedada numa estação terrestre é um parâmetro chamado
Facility Designator
através do qual a ICAO identifica unidades de controle de tráfego aéreo, enquanto que o AP-
title de uma aplicação embarcada é o endereço de 24 bits da aeronave, fornecido pela ICAO.
O AE-Qualifier é um número que identifica a aplicação.
O endereço fornecido pela aplicação CM é o TSAP, e este pode assumir duas formas,
uma curta (
short TSAP) e uma longa (long TSAP). No short TSAP os seguintes campos estão
presentes:
• ARS – Administrative Region Selector: usado para distinguir domínios de roteamento
operados pelo mesmo Estado (na aeronave, é seu endereço de 24 bits);
• LOC – Location: usado para distingüir áreas de roteamento dentro de um domínio;
• SYS – System Identifier: identifica um ES (End System) dentro de uma área de
roteamento;
• NSEL – Network Service Access Point Selector: identifica a entidade de rede de um
ES;
• TSEL - TSAP Selector: identifica a entidade de transporte de um ES;
65
Já o
long TSAP é formado por:
• RDP – Routing Domain Part: identifica a organização responsável pelo domínio de
roteamento da aplicação. É formado pelos campos VER, ADM, e RDF.
• Short TSAP – descrito acima.
Através da mensagem CM-Logon Request, o endereço da entidade CM embarcada é
enviado à entidade CM no solo, no formato long TSAP. São enviados também os endereços
de outras entidades de aplicações embarcadas, e caso o RDP destas entidades seja o mesmo da
entidade CM, então a aeronave pode enviar os endereços destas entidades no formato short
TSAP.
4.4.1. CM Logon Request e CM Logon Response
As mensagens que interessam a este estudo são CMLogonRequest e
CMLogonResponse. Segue um estudo do conteúdo destas mensagens com o objetivo de
definir seus comprimentos, essenciais à análise de desempenho que se pretende.
A mensagem CM Logon Request é enviada da entidade CM na aeronave para a
entidade CM no solo, como uma requisição de estabelecimento de sessão. Ela é composta
basicamente dos seguintes parâmetros:
• Facility Designator: código da ICAO de até 8 caracteres que identificam uma ATSU
(Air Traffic System Unit – Unidade de controle de tráfego aéreo);
• Aircraft Address: endereço de 24 bits fornecido pela ICAO para aeronaves;
• Logon Request: contém dados sobre o vôo e sobre as entidades embarcadas das
aplicações que a aeronave deseja utilizar;
66
• Security Required: Indicação de que a entidade CM embarcada quer ou não utilizar
serviços de segurança, e caso queira, quais serviços ela deseja utilizar (por exemplo,
ela pode solicitar autenticidade das mensagens, e talvez futuramente, encriptação das
mesmas – O ATN Panel estuda a possibilidade de incluir o serviço de encriptação das
mensagens na rede ATN);
• Time field: Campo temporal que indica o momento de transmissão da mensagem.
Usado pela entidade CM no solo;
• Assinatura: Assinatura digital da mensagem, usada para autenticar a origem da
mesma.
Tabela 5 – Detalhamento da mensagem CM-Logon Request
Parâmetro Tamanho (octetos) Descrição
CM – Logon Request 112
Mensagem enviada da aeronave para
o solo
Facility Designation 8 Identificação do sistema em solo
Aircraft Address 3 Identificação da aeronave
Logon Request 50
Parâmetro contendo informações
sobre o vôo e sobre aplicações
Aircraft Flight Id 8 Identificação do vôo
CM Long Tsap 16 Endereço da aplicação CM
Long Tsap 16 Endereço
RDP 5
routing domain part: corresponde aos
campos ver, adm e rdf do endereço
ATN
Short Tsap 11
parte do endereço correspondente aos
campos loc, sys, nsel e tsel
Applications 26
Informações sobre as aplicações que
a aeronave pode suportar
AEQualifier 1 Identificador da aplicação
VersionNumber 1 número de versão
APAddress 11 Endereço da aplicação
Short Tsap 11
parte do endereço correspondente aos
campos loc, sys, nsel e tsel
AEQualifier 1 Identificador da aplicação
VersionNumber 1 número de versão
APAddress 11 Endereço da aplicação
Short Tsap 11
parte do endereço correspondente aos
campos loc, sys, nsel e tsel
Security Required 1
Parâmetro indicando se a aeronave
deseja utilizar os serviços de
segurança
Time
10 Campo de tempo
Assinatura
40 Assinatura digital: inteiros r e s
67
No cenário aqui estudado, a aeronave envia informações referentes a duas aplicações,
por exemplo, CPDLC e ADS. Ela envia os endereços das entidades, no formato short TSAP, e
o endereço da entidade CM no formato long TSAP.
A
Tabela 5 mostra com mais detalhes os parâmetros que formam a mensagem CM-
Logon Request, e seus comprimentos em octetos. Em itálico são marcados os parâmetros
ligados à solução de segurança. Conforme mostrado, o comprimento total da mensagem é de
112 octetos, para um cenário como o deste trabalho.
A mensagem CM-Logon Response é enviada pela entidade CM no solo para a
entidade CM embarcada, como resposta à solicitação da aeronave. Esta mensagem contém os
seguintes parâmetros:
• Facility Designator: código da ICAO de até 8 caracteres que identificam uma ATSU
(Air Traffic System Unit – Unidade de controle de tráfego aéreo);
• Aircraft Address: endereço de 24 bits fornecido pela ICAO para aeronaves;
• Logon Response: contém dados sobre as aplicações que a aeronave deseja utilizar e
que estão disponíveis no solo. Estes dados incluem as chaves públicas das aplicações;
• Security Required: Indicação de que a entidade CM no solo aceita utilizar serviços de
segurança solicitados pela entidade CM embarcada;
• Random Challenge: Número randômico de 32 bits gerado pela entidade CM no solo
e usado pela entidade CM embarcada para calcular a chave de sessão CM;
• Public Key Certificate: Certificado de chave pública da entidade CM no solo (forma
comprimida);
• MAC: Código MAC de 32 bits da mensagem usado para autenticar a origem da
mesma.
68
A
Tabela 6 mostra com mais detalhes os parâmetros que formam a mensagem CM-
Logon Response, e seus comprimentos em octetos. Em itálico são marcados os parâmetros
ligados à solução de segurança. Conforme mostrado, o comprimento total da mensagem é de
195 octetos, para um cenário como o deste trabalho.
Tabela 6 – Detalhamento da mensagem CM-Logon Response
Parâmetro Tamanho (octetos) Descrição
CM – Logon Response 195
Mensagem enviada do solo para a
aeronave
Facility Designation 8 Identificação do sistema em solo
Aircraft Address 3 Identificação da aeronave
Logon Response 68
Parâmetro contendo informações sobre
as aplicações que a aeronave deseja
utilizar e que estão disponíveis no solo
Application 13
Informações sobre cada aplicação que o
solo pode suportar
AEQualifier 1 Identificador da aplicação
VersionNumber 1 número de versão
APAddress 11 Endereço da aplicação
Short Tsap 11
parte do endereço correspondente aos
campos loc, sys, nsel e tsel
Public Key
20 Chave pública da aplicação
Domain Flag
1
Indicação de se a chave pública é
compartilhada por todas as entidades de
um mesmo tipo (ex. CPDLC) ou não
Security Required
1
Parâmetro indicando que a entidade no
solo aceita utilizar os serviços de
segurança
Random Challenge
4
Número randômico gerado pela entidade
CM no solo
Public Key Certificate
107
Certificado de chave pública da entidade
CM no solo
Certificate
67 Certificado na forma comprimida
Serial Number
10 Número de série do certificado
Validity
20
Período de validade do certificado: datas
de inicio e fim
Subject Public Key
20
Chave pública que está sendo
certificada
Subject Alt Name
8
Identificação (AP-Title) da entidade para
a qual está sendo emitido o certificado
Issuer Alt Name
8
Identificação (AP-Title) da CA emissora
do certificado
Key Usage
1
Indicação do uso da chave pública ("key
agreement")
Signature
40 Assinatura da CA
MAC
4
69
5. Simulação e resultados
Conhecida a solução de segurança para a rede ATN, foi desenvolvido um cenário de
simulação no software Opnet Modeler que a aproximasse com o objetivo de avaliar seu
desempenho. Utilizando como meio de comunicação entre aeronaves e servidor CM o padrão
VDL2 e considerando o comprimento das mensagens
CM-Logon Request e CM-Logon
Response
, foi feita a avaliação através dos parâmetros atraso fim-a-fim, tempo de resposta e
vazão em função do número de aeronaves tentando estabelecer uma sessão.
É importante observar que os resultados obtidos na simulação consideram:
a. Uma SNR de 16 dB fixa, pois é um valor no qual a maioria dos sistemas ATN
opera.
b. Nenhum atraso devido ao processamento dos algoritmos de cifragem e decifragem.
Conforme mostrado na
Figura 15, pretende-se avaliar o desempenho do
estabelecimento de sessão não considerando os processamentos envolvidos, mas somente as
limitações impostas pelo canal de transmissão. A Figura 16 mostrada a pilha de protocolos
que será utilizada na simulação.
AERONAVE SERVIDOR CM PKI – ATN
Fase Inicial
Processamento
CM – Logon Response
CM – Logon Request
Estabelecimento
de
sessão
Comunicações
subseqüentes
Requisição à
Autoridade certificadora
Resposta da
Autoridade certificadora
Processamento
Figura 15 – Componentes do cenário simulado
70
Aplicação (CM)
TCP
IPv4
VDL modo 2
Físico
AERONAVE
Aplicação (CM)
TCP
IPv4
VDL modo 2
Físico
SERVIDOR CM
Figura 16 – Pilha de protocolos utilizada na simulação
5.1. O software de simulação Opnet Modeler
Desenvolvido pela empresa MIL3 Inc, o Opnet, pode ser descrito como um conjunto
de ferramentas de suporte para decisões, fornecendo um ambiente de desenvolvimento com
recursos de fácil compreensão para o usuário na especificação, análise da simulação e
desempenho das redes de comunicações, sistemas de computadores, aplicações e sistemas
distribuídos. O OPNET foi projetado para sustentar a modelagem e a simulação de uma
variedade imensa de sistemas de comunicações desde uma única LAN até uma rede global via
satélite. A
Figura 17 mostra alguns ambientes dos editores do OPNET.
Figura 17 – Editores do Opnet Modeler
71
O simulador de redes OPNET apresenta várias características importantes, entre elas
pode-se citar as seguintes:
• Orientação a Objetos: é orientado a objeto, onde cada objeto tem um conjunto
definido de atributos que podem ser configurados;
• Modelagem Hierárquica: Cada nível da modelagem descreve diferentes aspectos do
modelo completo que será simulado, podendo ser herdados por modelos no nível
superior, modelos genérico podem ser desenvolvidos e usados em muitos cenários
diferentes;
• Especializado em Redes de Comunicação: Uma biblioteca de modelos detalhados
fornece suporte para vários protocolos existentes e permite que os pesquisadores e
desenvolvedores os modifiquem ou desenvolvam outros novos modelos a partir
desses;
• Geração Automática de Simulação: Os modelos podem ser compilados gerando
código executável de uma simulação de eventos discretos, resultando em dados de
saída;
• Ferramentas de Depuração: A ferramenta de depuração interativa disponível permite
aos desenvolvedores localizar diversas características do modelo. Por exemplo, o
conteúdo ou tamanho de um determinado pacote é facilmente verificado.
OPNET pode ser usado como plataforma para desenvolver modelos de uma grande
diversidade de sistemas como pesquisa e desenvolvimento em arquiteturas de comunicações e
protocolos, dimensionamento de recursos, etc. Podem-se citar entre algumas finalidades as
seguintes:
72
• Explorar características das novas tecnologias e analisar o impacto obtido ao
introduzi-las em configurações existentes.
• Auxiliar no entendimento da natureza dinâmica das redes;
• Analisar as características de desempenho de sistemas;
• Desenvolver novos protocolos de comunicações ou aperfeiçoar os já existentes.
5.2. Cenário criado
O cenário, que representa um domínio de terminal aéreo, como pode ser visto na
Figura 18, é composto basicamente por 120 aeronaves executando simultaneamente e
sucessivamente a função de
logon da aplicação Context Management (CM) em uma estação
terrestre ao centro, utilizando um canal de comunicação VDL modo 2
[17].
A aplicação de rede, ou seja, o esquema de troca de mensagens apresentado no item
4.3.2 é definido nos módulos Task, Application e Profile.
73
Figura 18 – Cenário da simulação CM-Logon
A cada cinco minutos de atividade a comunicação de 10 aeronaves é encerrada até que
não haja mais trafego na rede, o que acontece após uma hora de simulação, como mostra a
Figura 19.
O agendamento do término de atividade nas aeronaves é definido no módulo
Failure
Recovery
.
74
Após 1 hora de simulação
Figura 19 – encerramento de atividade no cenário
5.2.1. Modelo ATN desenvolvido no Opnet Modeler
Para cada nó participante da rede (aeronaves e estação terrestre) é necessário que
sejam atribuídos os protocolos da pilha OSI definida para a rede ATN. Por não serem
implementados no simulador Opnet, os protocolos da camada de rede CLNP e transporte TP4
foram substituídos (com o devido ajuste no tamanho dos cabeçalhos) sem prejuízo pelos
protocolos IP e TCP respectivamente.
Os protocolos de transporte ISO TP4 e o TCP não só são funcionalmente equivalentes,
mas operacionalmente também. Um estudo de 1985, executado em conjunto pela
U.S.
Defense Communications Agency
e a National Academy of Science, concluiu que TP4 e TCP
são funcionalmente equivalentes e essencialmente provêem serviços semelhantes
[17].
Na camada de rede o ISO suporta
Connectionless Network Protocol (CLNP) e a
arquitetura de protocolos TCP/IP suporta o
Internet Protocol (IP). O CLNP e IP são
funcionalmente idênticos e ambos têm protocolos de serviço de entrega
best effort (melhor
esforço). A diferença principal entre os dois é que CLNP acomoda comprimento variável de
endereço, enquanto IPv4 suporta endereços de 32 bits
[17].
75
Os comprimentos totais em bits gerados pelas mensagens CM-Logon Request e CM-
Logon Response bem como os cabeçalhos provenientes das normas ISO 8072 (TP4 –
transporte) e ISO 8473 (CLNP – rede) são apresentados na
Figura 20. Cada camada é um
pouco mais detalhada nos itens
5.2.1.1, 5.2.1.3 e 5.2.1.2.
896
Aplicação
896
Transporte
52
948
Rede
424
CM-Logon Request
1560
Aplicação
1560
Transporte
52
1612
Rede
424
CM-Logon Response
Figura 20 – Comprimento em bits das mensagens CM-Logon Request e CM-Logon Response
5.2.1.1. Camada data link – VDL modo 2
Como a camada de data link (enlace) VDL modo 2 definida para a rede ATN não faz
parte, por padrão, dos modelos fornecidos com o software Opnet Modeler, houve-se a
necessidade de implementá-la. A implementação, desenvolvida para esse trabalho, foi baseada
no modelo criado em uma versão antiga do simulador e gentilmente cedido pelo
Mitre
Corporation
na pessoa do Dr. Paul T. R. Wang. Basicamente foram aproveitadas a estrutura
de subcamadas e suas máquinas de estados. Já o código-fonte, em linguagem C, para cada
estado das máquinas de estado teve que ser reescrito, visto que as funções de kernel (que
controlam envio/recebimento de pacotes e outras manipulações internas) mudaram nas
versões recentes do simulador. Na etapa de codificação um tempo substancial foi gasto, dado
que foram escritos/alterados cerca de 8.000 linhas de código.
A estrutura da camada de enlace e seus componentes são mostrados na
Figura 21.
76
Figura 21 – Modelo da camada data link VDL modo 2
A subcamada DLS (
data link service) manipula time out e agendamento de
retransmissão.
A subcamada MAC (controle de acesso ao meio) implementa CSMA (
Carrier Sense
Multiple Access
) p-persistente com backoff. A máquina de estados responsável pelos
procedimentos da subcamada é mostrada na
Figura 22, na qual podem ser identificados (em
cada circulo) os estados de espera por chagada de novos pacotes, escuta do meio para
transmissão e
backoff, entre outros.
Figura 22 – Maquina de estados da subcamada de acesso ao meio (MAC)
77
Colisão e sinal de interferência são controlados pelo Opnet. A largura de banda do
canal é fixa com taxa de 31.5 kbps em modo simplex operando em modulação D8PSK
(
differentially encoded 8-phase shift keying). O transceiver tem potência de 20 watts nas
aeronaves e 25 watts na estação terrestre.
A subcamada DLS recebe pacotes da camada de sub-rede e envia um novo
frame, a
cada pacote recebido, para a subcamada MAC. Para cada
frame que requer um
acknowledgement (reconhecimento), a subcamada DLS dispara um timer de retransmissão T1
(valor entre 2.2 segundos e um número muito grande). Se o
timer expirar, a subcamada DLS
retransmite o mesmo
frame por até N2 vezes (N2 = 6). Para cada frame recebido que requer
um reconhecimento de envio, a subcamada DLS envia um frame de
acknowledgement.
A subcamada MAC recebe
frames da subcamada DLS. Cada nó da rede, aeronave ou
estação terrestre, checa o estado do canal antes de proceder a transmissão. Se o canal estiver
ocupado, a entidade transmissora aguarda (
backoff) por um intervalo de tempo fixo TM1
(TM1= 4.5 milisegundos), antes de rechecar o estado do canal. Se o canal não estiver
ocupado, a entidade transmissora tenta transmitir com uma probabilidade
p e entra em backoff
com uma probabilidade de
1-p. O número máximo de tentativas de acesso ao meio é M1
(M1=135).
Os atrasos fim-a-fim de
downlink e uplink são registrados para cada frame. A camada
de sub-rede calcula estatísticas incluindo carga oferecida (
G) e vazão (S).
CSMA p-persistente: O protocolo CSMA e suas variações incluindo o p-persistente
foram analisados em
[19]. Este protocolo reduz a freqüência de colisões nas mensagens sobre
um canal de rádio fazendo com que as estações prontas sintam a portadora das outras estações
antes de tentar transmitir uma mensagem. O protocolo p-persistente trabalha como segue.
Estações prontas sentem o canal antes da transmissão. Se o canal é sentido inativo, então
78
transmite com probabilidade
p, ou adia a transmissão com probabilidade 1-p por
τ
segundos.
Ao término de cada adiamento, a estação repete o mesmo processo se o canal ainda estiver
inativo. Caso contrário, se o canal está ocupado, a estação programa a retransmissão do pacote
de acordo com um atraso de retransmissão aleatório de média
X
. O atraso médio
X
é grande
comparado a
T
(duração do comprimento do pacote). Se um terminal pronto sente um canal
ocupado, continua esperando até que o canal esteja inativo e então opera como descrito
anteriormente.
Vazão (S), e atraso (D), normalmente são as duas características de desempenho de
interesse em um sistema de comunicações. Vazão é definida como a taxa de trafego recebida
com sucesso, normalizada em relação à taxa no canal. Ela mede a utilização da largura de
banda do canal, que é sempre menor ou igual a 1. Vazão é uma função de muitos parâmetros
inclusive a carga oferecida (G) que é definida como o total de tráfico transmitido pela sub-
camada MAC. Isto inclui trafego de novas chegadas como também retransmissões. A carga
oferecida é normalizada em relação a taxa do canal e pode ser maior que 1.
5.2.1.2. Camada de rede
Na camada de rede, ISO suporta o Connectionless Network Protocol (CLNP) e a
arquitetura de protocolos TCP/IP suporta IP. O CLNP e IP são funcionalmente idênticos e
ambos são protocolos de rede
best effort (melhor esforço). A diferença principal entre os dois
é que CLNP acomoda comprimento variável de endereço, enquanto IPv4 suporta endereços
de 32 bits e IPv6 suporta 128 bits.
O
Internet Control Message Protocol (ICMP) provê mecanismos elaborados para
informar erros em datagramas IP processados em
hosts e gateways. Funções equivalentes são
providas pelo CLNP usando uma razão para opção de descarte carregada no relatório de erro
79
CLNP. CLNP e IP têm múltiplas opções. O conjunto de opções definido para os dois
protocolos é virtualmente idêntico, mas o processo é ligeiramente diferente.
ICMP define mensagens diferentes de relatório de erro. A fonte extingue mensagens
servindo como um mecanismo de notificação de congestão grosseiro, proporcionando rotas
como um meio de dizer para os
hosts que reduzam a taxa na qual eles estão enviando pacotes
IP. A mesma função é realizada no OSI usando um relatório de erro CLNP com a razão para
descartar no campo definido pelo valor médio de congestão experimentada. A
Tabela 7
compara as funções do CLNP e IP.
Tabela 7 – Comparação entre as funções dos protocolos CLNP e IP
Função CLNP IP
Version identification 1 octet 4 bits
Header length 1 octet, represented in octets 4 bits, represented in 32 bit words
Quality of service QoS maintenance option Type of Service / Class
Segment/fragment length
16 bits, in octets 16 bits, in octets
Total length 16 bits, in octets 16 bits, in octets
Data unit identification 16 bits 16 bits
Flags
Don’t segment, more segments,
suppress error report
Don’t fragment, more fragments
Segment/fragment offset
16 bits, represented in octets (value
always multiple of 8)
13 bits, represented in units of 8
octets
Lifetime, time to live
1 octet, represented in 500 millisecond
units
1 octet, represented in 1-second units
Higher layer protocol Not present Protocol identifier
Lifetime control 500 millisecond units 1-second units
Addressing Variable length 32-bit fixed
Options • Security • Priority • Complete source
routing • Partial source routing •
Record route • Padding • Not present •
Reason for discard (Error PDU only)
• Security • Precedence bits in TOS •
Strict source route • Loose source
route • Record route • Padding •
Timestamp • Uses ICMP messages
80
5.2.1.3. Camada de transporte
A camada de transporte é o bloco básico de comunicação fim-a-fim entre os sistema
finais. Tudo acima da camada de transporte é associado com a aplicação distribuída e tudo
abaixo da camada de transporte é rede de transmissão orientada. Na ATN, TP4 provê um
caminho de dados seguro para as camadas superiores como parte de um serviço não orientado
a conexão. O
Connection Less Transport Protocol (CLTP) provê entrega de datagramas
simples como parte de um serviço não orientado a conexão. No conjunto de protocolos
TCP/IP, o serviço orientado a conexão confiável é provido pelo TCP e o serviço de datagrama
simples pelo
User Datagram Protocol (UDP).
Em uma operação orientada a conexão, o fluxo de dados submetido à camada de
transporte pelo usuário fonte de transporte deve ser entregue ao usuário de transporte de
destino sem perda. Não podendo haver duplicação de quaisquer dos octetos no fluxo de
dados, e os octetos devem ser entregues na mesma ordem nas quais eles foram submetidos. A
camada de transporte também tem que prover detecção e correção fim-a-fim para identificar e
corrigir erros introduzidos pela rede no fluxo de dados.
Em ambos os modos, orientado a conexão e não orientado a conexão, a camada de
transporte tem que fazer o que pode para aperfeiçoar o uso dos recursos da rede para uma
determinada qualidade de serviço especificada pelos usuários de transporte.
Os serviços de transporte providos por TP4 e TCP são funcionalmente equivalentes.
Adicionalmente, examinando o processo de estabelecimento da conexão de transporte,
provendo transferência de dados seguras por meio de retransmissões com mecanismos de
time
out
e termino de cada conexão mostra que eles são operacionalmente semelhantes. A
comparação mostrada na
Tabela 8, baseada no estudo executado pela U.S. Defense
Communication Agency
(DCA, agora DISA) e a National Academy of Sciences, conclui que
TCP e TP4 são funcionalmente equivalentes e provêem serviços essencialmente semelhantes.
81
Tabela 8 – Comparação das funções dos protocolos TCP e TP4
Função Protocolo TCP Protocolo TP4
Data transfer Streams Blocks
Flow control Octets Segments
Error detection Checksum Checksum
Error correction Retransmission Retransmission
Addressing 16 bit ports Variable TSAP address
Interrupt service Urgent data Expedited data
Security Supported Variable in TP
Precedence Supported 16 bits in TP
Connection termination Graceful Non graceful
82
6. Resultados
As estatísticas coletadas da simulação foram end-to-end delay (atraso fim-a-fim),
application response time (tempo de resposta da aplicação) e throughput (vazão).
O controle de trafego aéreo é dividido em quatro domínios:
airport (aeroporto),
terminal (terminal aéreo), em route (em rota) e oceanic (oceânico). No ambiente da rede de
Serviço de Trafego Aéreo (ATS), que inclui a sub-rede VDL modo 2 e o ATN certas
exigências de atraso das mensagens são impostas em cada porção da rede. Para a porção VDL
modo 2 da rede é exigido que 95% do atraso fim-a-fim esteja em até 3 segundos no domínio
de área de terminal.
Cumprindo a exigência imposta fica claro pelo gráfico da
Figura 23, que o número
máximo suportado pelo canal executando CM-Logon simultaneamente fica em torno de 50
aeronaves, que ocorre no intervalo de tempo entre 35 e 40 minutos da simulação.
Figura 23 – Atraso fim-a-fim ao longo de uma hora de simulação
No gráfico da
Figura 24 cada ponto representa o tempo médio levado pelos nós da
rede em 100 execuções completas de uma aplicação CM-Logon, ou seja, o tempo do envio de
83
um CM-Logon request da aeronave para o servidor CM no solo até o recebimento de um CM-
Logon response do servidor CM pela aeronave.
Para o intervalo de tempo, no qual a exigência de atraso fim-a-fim foi satisfeita (obtido
do gráfico de atraso fim-a-fim), entre 35 e 40 minutos de simulação, a aplicação CM-Logon
executada leva por volta de 6 segundos para ser concluída.
Figura 24 – Tempo de resposta da aplicação ao longo de uma hora de simulação
O gráfico da
Figura 25 mostra a vazão do canal praticamente constante, excetuando-se
os momentos imediatamente seguintes ao encerramento de comunicação de cada grupo de 10
aeronaves, que ocorre a cada 5 minutos. A utilização total do canal é bem razoável, em torno
de 25.000 bits/segundo.
84
Figura 25 – Vazão ao longo de uma hora de simulação
6.1. Antes dos serviços de segurança
Até a versão 2 das SARPs os itens em negrito e itálico da Tabela 5 e da Tabela 6,
relativos a solução de segurança na rede ATN, não eram implementados.
A seguir uma comparação do desempenho da aplicação CM-Logon com serviços de
segurança e sem serviços de segurança.
O gráfico da
Figura 26 mostra que cumprindo a exigência de até 3 segundos no atraso
fim-a-fim da porção VDL modo 2 da rede em domínio de terminal, a quantidade máxima
suportada pelo canal, executando CM-Logon simultaneamente, sem serviços de segurança,
está em torno de 100 aeronaves, o dobro da quantidade suportada pela estação, que ocorre
entre 10 e 15 minutos de simulação.
85
Figura 26 – Atraso fim-a-fim ao longo de uma hora de simulação
No gráfico da
Figura 27 cada ponto representa o tempo médio levado pelos nós da
rede em 100 execuções completas de uma aplicação CM-Logon, ou seja, o tempo do envio de
um CM-Logon request da aeronave para o servidor CM no solo até o recebimento de um CM-
Logon response do servidor CM pela aeronave.
Para o intervalo de tempo, no qual a exigência de atraso fim-a-fim foi satisfeita (obtido
do gráfico de atraso fim-a-fim), entre 10 e 15 minutos de simulação, a aplicação CM-Logon
executada leva, também, por volta de 6 segundos para ser concluída.
86
Figura 27 – Tempo de resposta da aplicação ao longo de uma hora de simulação
O gráfico da
Figura 28 mostra a vazão do canal (em bits por segundos) também
praticamente constante, excetuando-se os momentos imediatamente seguintes ao
encerramento de comunicação de cada grupo de 10 aeronaves, que ocorre a cada 5 minutos.
A utilização total do canal, sem os serviços de segurança, agora fica em torno de
20.500 bits/segundo. Tal diminuição ocorre porque, como o estabelecimento das sessões CM
foi configurado para se repetir sucessivamente e tantas vezes quantas fossem possíveis, e o
tamanho das mensagens sem serviço de segurança é menor, então são criadas mais sessões
CM se comparada quando realizadas com serviços de segurança. Portanto há aumento de
colisões por causa dos nós disputarem o acesso ao meio mais vezes.
87
Figura 28 – Vazão ao longo de uma hora de simulação
88
7. Conclusão
A maior contribuição deste trabalho na área de estudo da rede ATN foi a simulação de
toda a arquitetura de comunicação da rede.
Esta contribuição vem a complementar trabalhos anteriores onde somente partes da
arquitetura foram consideradas
[2] e [3].
Por meio de simulação foi avaliado o desempenho de um servidor CM com e sem
serviços de segurança, mantendo-se fixa a relação sinal ruído de forma a ter uma
probabilidade de erro por bit na ordem de . Para a avaliação do desempenho foi utilizado
o parâmetro de atraso fim-a-fim da rede. A partir dos resultados obtidos de atraso fim-a-fim
foi possível avaliar o tempo de resposta da aplicação e a vazão do canal. Em seguida foi
possível concluir que o número máximo de aeronaves que podem ser atendidas pelo servidor
CM é de 50 aeronaves de forma a satisfazer o requisito de que o atraso médio fim-a-fim do
pacote seja menor ou igual a 3 segundos.
6
10
−
Também por meio dos resultados desse estudo pode ser avaliado o impacto do serviço
de segurança no estabelecimento de sessão de comunicações. De fato em um sistema sem
serviços de segurança um servidor CM pode atender 100 aeronaves atendendo o requisito de
no máximo 3 segundos de atraso médio fim-a-fim dos pacotes, o dobro.
Sugere-se para futuros trabalhos endereçar os seguintes tópicos:
a.
No modelo de simulação aqui apresentado incluir também os atrasos de cifragem e
decifragem.
b.
No modelo de simulação desenvolvido substituir o canal de transmissão
representado apenas por ruído branco aditivo, por um canal mais realista que
considere interferências tais como desvanecimento e reflexões do sinal
transmitido.
89
c.
Estender o estudo de desempenho realizado nesse trabalho para sistemas que
utilizem versões mais avançadas do VDL, como:
• VDL modo 3: Usa os mesmos esquemas de modulação do modo 2 e introduz o
gerenciamento de canais TDMA. Isto habilita o uso de voz digitalizada e de
dados. É esperado que, no futuro, o modo 3 substitua os modos de
comunicação analógicas de voz.
• VDL modo 4: Além da comunicação de dados, suporta vigilância automática
subordinada multi-usuário (aplicação ar-ar) e aplicações de prevenção de
colisões. É o VDL que irá suportar aplicações críticas. O esquema de
modulação pode ser o D8PSK com vazão de 31,5 kbps (similar aos modos 2 e
3) ou o GFSK com taxa de dados de 19,200 kbps. O esquema de modulação
GFSK apresenta uma confiabilidade um pouco melhor que a do D8PSK.
90
8. Referências bibliográficas
[1]
HELIOS Information Services Atn2002. Conference Tutorial. IEE London, 2002.
[2]
MONTEIRO, Alexandre Moreira. Simulação das camadas 1 e 2 de um enlace de
dados em VHF modo 2
. 2001. Dissertação (Mestrado) - Instituto Tecnológico de
Aeronáutica, São José dos Campos, São Paulo, 2001.
[3]
SOUZA, Marília da Costa Souza. Estudo da solução de segurança na ATN (Rede de
Telecomunicações Aeronáuticas) e seu desempenho em canal via satélite
. 2004.
Dissertação (Mestrado Profissionalizante) - Instituto Tecnológico de Aeronáutica, São
José dos Campos, São Paulo, 2004.
[4]
FANS Information Services. Comprehensive ATN Manual (CAMAL) Part I. 1999.
Disponível em: http://www.helios-is.com/downloads/Guidance%20Material/parti.pdf
[5]
ICAO. Manual of Technical Provisions for the Aeronautical Telecommunication
Network (ATN).
First Edition. [S.l.]: International Civil Aviation Organization, 1998.
(Doc 9705-AN/956).
[6]
PFLEEGER, Charles P. ; PFLEEGER, Shari Lawrence. Security in Computing. 3 ed.
New Jersey: Prentice Hall, 2000.
[7]
TRAPPE, W.; WASHINGTON, L. Introduction to Cryptography with Coding Theory.
New Jersey: Prentice Hall, 2002.
[8]
AERONAUTICAL TELECOMMUNICATION NETWORK PANEL. Application
Security Solution for the Aeronautical Telecommunication Network
. [S.l.: S.n.], 1998.
[9]
STINSON, D. Cryptography Theory and Practice. [S.l.]: CRC Press, 1995.
[10]
MENEZES, Alfred. Elliptic curve cryptosystems. CryptoBytes, v. 1, n.2, Summer
1995. Disponível em:
http://www.rsasecurity.com/rsalabs/cryptobytes/
[11]
CERTICOM. Current Public-Key Cryptographic Systems. [S.l.]: Certicom
Whitepapers, 2000.
91
[12]
IEEE Working Group P1363. Working Draft: Standard for RSA, Diffie-Hellman and
related public-key cryptography. Editorial contribution, March 1997.
[13]
WIENER, M. Performance Comparison of Public-Key Cryptosystems. CryptoBytes,
vol. 4, no. 1, 1998.
[14]
ICAO. ATN Standards and Recommendations Practices. [S.l: S.n.], 1999. ed.3 v.l8.
[15]
SHAMUS SOFTWARE LTD. Multiprecision Integer and Rational Arithmetic C/C++
Library
. Disponível em: http://indigo.ie/~mscott/
[16]
AERONAUTICAL TELECOMMUNICATION NETWORK PANEL. Public Key
Infrastructure for the Aeronautical Telecommunication Network
. [S.l: S.n.], 1999.
(Working Group B, Subgroup 3).
[17]
ICAO ATN. Digital Data Communication Systems. [S.l]: ICAO, 1999. (Annex 10
Aeronautical Telecommunications, Volume III Part I, 1999).
[18]
NASA - GLENN RESEARCH CENTER. Aeronautical Related Applications Using
ATN and TCP/IP.
[S.l]: NASA, 2000. (Research Report, NASA/CR—2000-209922,
April 2000).
[19]
KLEINROCK, L.; TOBAGI, F.A. Packet Switching in Radio Channels: Part I-Carrier
Sense Multiple-Access Modes and Their Throughput-Delay Characteristics.
IEEE
Transactions on Communications,
vol. COM-23, December 1975.
FOLHA DE REGISTRO DO DOCUMENTO
1.
CLASSIFICAÇÃO/TIPO
TM
2.
DATA
deixe em branco
3.
DOCUMENTO N°
deixe em branco
4.
N° DE PÁGINAS
91
5.
TÍTULO E SUBTÍTULO:
Segurança em Redes de Telecomunicações Aeronáuticas e seu desempenho em canal VDL modo 2
6.
AUTOR(ES):
João Evangelista Netto
7. INSTITUIÇÃO(ÕES)/ÓRGÃO(S) INTERNO(S)/DIVISÃO(ÕES):
Instituto Tecnológico de Aeronáutica. Divisão de Engenharia Eletrônica - ITA/IEE
8.
PALAVRAS-CHAVE SUGERIDAS PELO AUTOR:
Segurança de redes, ATN, VDL
9.PALAVRAS-CHAVE RESULTANTES DE INDEXAÇÃO:
deixe em branco
10.
APRESENTAÇÃO: X Nacional Internacional
ITA, São José dos Campos, 2005, 91 páginas
11.
RESUMO:
Este trabalho tem por objetivo analisar o desempenho da solução de segurança definida pela ICAO
(International Civil Aviation Organization) para a ATN (Aeronautical Telecommunication Network) que
é uma rede global para prover serviço de comunicação de dados para aviação civil. Depois de uma
apresentação de arquitetura e serviços ATN e uma revisão sobre questões de criptografia e segurança de
rede, é proposto um cenário desenvolvido no software de simulação de redes Opnet Modeler para
caracterizar o desempenho obtido com e sem segurança. Neste cenário, aeronaves executa
m
simultaneamente a função Logon da aplicação CM (Context Management), responsável pelo início,
autenticação e manutenção de sessões (conexões data link) entre aeronave e estação terrestre. Atendendo
a restrição de atraso fim a fim, imposta ao padrão ATN, a sub-rede do cenário proposto mostrou suportar
até 50 aeronaves simultaneamente executando CM-Logon em um canal VDL modo 2 com a solução de
segurança proposta pela ICAO para a ATN.
12.
GRAU DE SIGILO:
(X ) OSTENSIVO ( ) RESERVADO ( ) CONFIDENCIAL ( ) SECRETO
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo