Dênio Teixeira Silva

Arquitetura de um Sistema de Segurançaem Redes ATM com Gerenciamento de

Chaves Distribuído

Dissertação apresentada ao Departamentode Ciência da Computação do Instituto deCiências Exatas da Universidade Federal deMinas Gerais, como requisito parcial paraobtenção do grau de mestre em Ciência daComputação

Belo Horizonte

19 de março de 1997

À

Leila, minha mulher,

Raphael e Bárbara, nossos filhos,

Joaquim e Elizabete, meus pais.

Resumo

A importância da segurança em redes de computadores está aumentando por causa docrescimento acelerado das redes, especialmente da rede Internet, e da demanda por serviçosbancários e comerciais através das redes. Paralelamente, existe uma demanda por diversos tiposde serviços que apresentam características de multimídia, e que exigem grandes velocidades detransmissão. A tecnologia ATM oferece velocidades altas e é uma tecnologia que pode darsuporte ao transporte de dados de qualquer tipo de serviço. Portanto, uma arquitetura desegurança para redes ATM é um trabalho que acompanha a tendência do mercado e apresentasoluções para problemas atuais e de grande necessidade.

Neste trabalho é apresentada uma arquitetura de segurança para redes ATM (AsynchronousTransfer Mode) com gerenciamento distribuído de chaves criptográficas. Essa arquitetura provêserviço de autenticação de origem e de destino e serviço de sigilo dos dados para os usuários darede. Os serviços são transparentes para as aplicações e para os comutadores ATM e, dentro daestrutura de comunicação instalada nos computadores dos usuários, apenas as camadas ATMsão utili zadas para prover a segurança. O gerenciamento de chaves criptográficas, que incluigeração, distribuição e autenticação, pode ser distribuído pela rede evitando todos os problemasque serviços de rede centralizados podem trazer em redes grandes.

Nesta dissertação é apresentada uma proposta de um novo protocolo para distribuição de chavesem grandes redes de computadores. É proposto um esquema para implementação da distribuiçãode chaves através do protocolo de sinalização, durante o estabelecimento da conexão de circuitovirtual. É apresentada uma proposta de arquitetura funcional de um sistema de segurança. Éespecificado um protocolo de segurança para a Subcamada de Convergência do ServiçoEspecífico (SSCS) da Camada de Adaptação ATM tipo 5 (AAL5). E, finalmente, é apresentadauma proposta de modelagem das entidades de gerenciamento de chaves utili zando o padrãoSNMP de gerenciamento de redes.

Abstract

The importance of computer network security is increasing because of the fast growing ofnetworks, specialy the Internet network, and because of demanding for comercial and bankingservices over the networks. On the time there is a search for several kinds of services withmultimidia characteristics, that asks for high transmission rates. The ATM technology offershigh speed and is a technology that supports the transport of data from any service. Therefore,an ATM network security architecture is a work that follows the market tendency and presentssolutions to real and necessary problems.

This work presents an ATM (Asynchronous Transfer Mode) network security architecturewithdistributed cryptographic key management. This architecture provides source and destinationauthentication and data confidenciali ty services. The services are transparent to applications andto the ATM switches. Only the ATM layers are used to provide security. The cryptographickeys management, including generation, distribution and authentication, can be distributed overthe network avoiding all the problems that centralized network services can cause in largenetworks.

This dissertation presents the proposal of a new key distribution protocol to distribute keys inlarge networks. A security system functional architecture proposal is presented. A scheme toimplement the key distribution using signalli ng protocol, during the virtual circuit stablishingphase, is proposed. A security protocol to work in the ATM Adaptation Layer (AAL5) ServiceSpecific Convergence Sublayer (SSCS) is specified. And, finally, a key management entitymodelling proposal using SNMP network management standard is presented.

Prefácio

A escolha do assunto desta dissertação foi motivada em grande parte pela oportunidade deexplorar e adquirir conhecimentos específicos em uma área cujo volume de pesquisa ainda érelativamente pequeno, se comparado a outras áreas da Ciência da Computação, e por issocontribuir de forma mais significativa através deste trabalho de dissertação.

Outra motivação importante é a contribuição que posso dar à pesquisa em segurança dascomunicações ao Centro de Pesquisa e Desenvolvimento para Segurança das Comunicações(CEPESC), do qual sou funcionário. Segurança em redes de computadores é um assunto queestá apenas começando a ser explorado pelo CEPESC e o meu trabalho certamente será demuita utilidade.

Através deste trabalho eu tive a oportunidade de estudar detalhadamente diversos assuntos daárea de redes de computadores, aprofundando e amadurecendo os conhecimentos que eu játinha. O trabalho cobre diversos assuntos de redes além daqueles relativos à segurança.

É importante salientar que minhas atividades no Laboratório de Redes de Alta Velocidade foramfundamentais para o amadurecimento e execução do trabalho.

Quero ressaltar que, para a realização desse trabalho, foi fundamental o apoio que recebi doDepartamento de Ciência da Computação da Universidade Federal de Minas Gerais, através doseu corpo de professores e de funcionários. Em especial destaco o apoio e orientação doProfessor José Marcos Silva Nogueira, meu orientador acadêmico e de dissertação, a quemagradeço pelos muitos conhecimentos que adquiri na área de redes de computadores, e pelaoportunidade de fazer parte do grupo de ATM (Laboratório de Redes de Alta Velocidade doDepartamento de Ciência da Computação).

Agradeço ao José Roberto Menezes Monteiro, colega do CEPESC e doutorando em Ciência daComputação na UNICAMP, pelos valiosos comentários que ajudaram bastante na elaboraçãodos aspectos de segurança do trabalho.

Agradeço ao CEPESC por permitir meu afastamento para este curso de pós-graduação.

Agradeço também aos amigos e amigas que fiz durante o curso com os quais tive um convívioagradável além de ter aprendido muito nos trabalhos conjuntos, nas discussões e nas trocas deidéias.

Agradeço especialmente à minha mulher Leila pelo irrestrito apoio, compreensão e carinho quedela recebi durante esses dois anos de curso.

iii

Sumário

LISTA DE TABELAS ...........................................................................................vii

LISTA DE FIGURAS ...........................................................................................viii

CAPÍTULO 1

INTRODUÇÃO ........................................................................................................1

CAPÍTULO 2

SEGURANÇA, REDES ATM, SINALIZAÇÃO E GERENCIAMENTO SNMP .. 6

2.1 SEGURANÇA.......................................................................................................6

2.1.1 Serviços e Mecanismos...............................................................................6

2.1.2 Algoritmos de Criptografia.........................................................................6

2.1.3 Hierarquia de Chaves.................................................................................9

2.1.4 Função Hash Unidirecional (Função de Espalhamento).........................11

2.1.5 Aplicações dos Algoritmos........................................................................11

2.2 REDES ATM .....................................................................................................11

2.2.1 Introdução.................................................................................................11

2.2.2 Célula ATM...............................................................................................12

2.2.3 Conexões Virtuais.....................................................................................13

2.2.4 Modelo de Referência................................................................................15

2.2.5 Taxas de Transmissão...............................................................................17

2.2.6 Camada de Adaptação ATM (AAL)..........................................................17

2.3 PROTOCOLO DE SINALIZAÇÃO Q.2931...............................................................23

2.3.1 Primitivas de Serviço.................................................................................24

2.3.2 Mensagens Q.2931....................................................................................25

2.3.3 Formato das Mensagens...........................................................................26

2.3.4 Procedimentos de Conexão.......................................................................27

2.3.5 Diagrama de Estados do Protocolo...........................................................29

2.4 GERENCIAMENTO SNMP ( SIMPLE NETWORK MANAGEMENT PROTOCOL) .........30

2.4.1 Arquitetura de Gerenciamento..................................................................30

2.4.2 O Protocolo SNMP...................................................................................31

2.4.3 Protocolo SNMPv2....................................................................................35

iv

2.4.4 Agente Procurador....................................................................................37

2.4.5 Agente Inteligente.....................................................................................38

2.4.6 Transporte de Mensagens SNMP..............................................................38

CAPÍTULO 3

ESPECIFICAÇÃO BÁSICA DO SISTEMA DE SEGURANÇA PARA REDESATM .........................................................................................................................39

3.1 SERVIÇOS DE SEGURANÇA.................................................................................39

3.2 MECANISMOS DE SEGURANÇA...........................................................................39

3.3 ALGORITMOS....................................................................................................40

3.4 GERENCIAMENTO DE SEGURANÇA.....................................................................40

3.5 VISÃO GERAL DA SEGURANÇA..........................................................................40

3.6 SERVIÇOS DE SEGURANÇA NA CAMADA AAL5 ..................................................41

3.7 VISÃO GERAL DA ARQUITETURA .......................................................................41

CAPÍTULO 4

PROTOCOLO PARA DISTRIBUIÇÃO DE CHAVES CRIPTOGRÁFICAS EMGRANDES REDES DE COMPUTADORES.........................................................44

4.1 INTRODUÇÃO....................................................................................................44

4.2 ABREVIATURAS, NOTAÇÃO E TERMINOLOGIA....................................................44

4.3 DESCRIÇÃO DO PROTOCOLO DE DISTRIBUIÇÃO DE CHAVES................................46

4.3.1 Distribuição das Chaves Públicas.............................................................47

4.3.2 Distribuição de Chave de Sessão e Autenticação (Hierarquia de DoisNíveis)................................................................................................................48

4.3.3 Análise das Características de Segurança do Protocolo............................51

4.3.4 Distribuição de Chave Mestra e Autenticação (Hierarquia de Três Níveis)53

4.4 RESSINCRONIZAÇÃO DO ALGORITMO.................................................................56

4.5 GERENCIAMENTO DE CHAVES DISTRIBUÍDO.......................................................56

4.6 CONCLUSÕES SOBRE O PROTOCOLO...................................................................61

CAPÍTULO 5

DISTRIBUIÇÃO DE CHAVES ATRAVÉS DE REDES ATM ............................62

5.1 INTRODUÇÃO....................................................................................................62

5.2 PROTOCOLO DE DISTRIBUIÇÃO DE CHAVES PARA UTILIZAÇÃO EM CIRCUITOS

VIRTUAIS................................................................................................................63

5.3 DINÂMICA DA DISTRIBUIÇÃO DAS CHAVES........................................................65

5.4 DISTRIBUIÇÃO DE CHAVE MESTRA ATRAVÉS DE MENSAGENS DE SINALIZAÇÃO ..68

v

5.5 DISTRIBUIÇÃO DE CHAVES ENTRE SERVIDORES E NÓ ORIGEM ATRAVÉS DE

MENSAGENS Q.2931...............................................................................................71

5.6 CONCLUSÃO......................................................................................................74

CAPÍTULO 6

ARQUITETURA FUNCIONAL DE UM SISTEMA DE SEGURANÇA .............76

6.1 INTRODUÇÃO....................................................................................................76

6.2 ESTRUTURA DOS NÓS........................................................................................77

6.2.1 Gerenciador de Segurança Local (LSM)..................................................78

6.2.2 Servidor de Autenticação e de Chaves (AKS)............................................79

6.2.3 API de Controle de Chamada Q.2931 (QCC)...........................................79

6.2.4 Geração de Chaves Assimétricas...............................................................81

6.3 MODELO OPERACIONAL....................................................................................81

6.4 CONCLUSÃO......................................................................................................83

CAPÍTULO 7

PROTOCOLO ESPECÍFICO DO SERVIÇO DE SEGURANÇA (SSSP)...........84

7.1 INTRODUÇÃO....................................................................................................84

7.2 TROCA DE CHAVES ATRAVÉS DE PDUS CPCS DE GERENCIAMENTO...................84

7.3 PROTOCOLO DE SEGURANÇA SSSP....................................................................86

7.3.1 Primitivas..................................................................................................87

7.3.2 Formato das PDUs e Comportamento do Protocolo SSSP.......................88

CAPÍTULO 8

DISTRIBUIÇÃO DE CHAVES UTILIZANDO SNMPV2 ...................................91

8.1 INTRODUÇÃO....................................................................................................91

8.2 MAPEAMENTO DO PROTOCOLO DE DISTRIBUIÇÃO DE CHAVES EM OPERAÇÕES

SNMP....................................................................................................................92

8.3 MIB DE SEGURANÇA ........................................................................................94

8.4 OPERAÇÕES NO PROCEDIMENTO DE GERAÇÃO DE CHAVES ................................95

8.5 OPERAÇÕES NO PROCEDIMENTO DE DISTRIBUIÇÃO DE CHAVE MESTRA..............96

8.6 OPERAÇÕES NO PROCEDIMENTO DE DISTRIBUIÇÃO DE CHAVES DE SESSÃO........98

8.7 TRANSPORTE DE MENSAGENS SNMPV2 ATRAVÉS DO PROTOCOLO Q.2931........99

CAPÍTULO 9

CONCLUSÕES.....................................................................................................100

vi

BIBLIOGRAFIA ...................................................................................................102

APÊNDICE A

GLOSSÁRIO ........................................................................................................106

APÊNDICE B

ESPECIFICAÇÃO DO PROTOCOLO SSSP ATRAVÉS DE DIAGRAMAS

SDL.........................................................................................................................108

APÊNDICE C

DEFINIÇÕES DA MIB DE SEGURANÇA EM ASN.1(SMIV2) ..................................................................................................................117

vii

Lista de Tabelas

Tabela 2.1 - Subcamadas e Funções do Modelo de Referência................................................17

Tabela 2.2 - Classes de Serviço..............................................................................................18

Tabela 2.3 - Primitivas Q.2931..............................................................................................24

Tabela 2.4 - Mensagens Q.2931.............................................................................................25

Tabela 2.5 - Elementos de Informação da Mensagem SETUP.................................................26

Tabela 2.6 - Operações SNMP..............................................................................................32

Tabela 2.7 - Operações SNMPv2...........................................................................................36

viii

Lista de Figuras

Figura 1.1 - Diagrama de Dependência dos Assuntos da Dissertação........................................5

Figura 2.1 - Modos de Cifração Simétrica................................................................................8

Figura 2.2 - Função Hash Unidirecional.................................................................................11

Figura 2.3 - Estrutura da Célula ATM...................................................................................12

Figura 2.4 - Estrutura do Cabeçalho da Célula ATM (UNI)...................................................13

Figura 2.5 - Exemplo de Rede ATM......................................................................................14

Figura 2.6 - O Meio Físico e a Relação entre VPI e VCI........................................................14

Figura 2.7 - Comutação de VP e de VC.................................................................................15

Figura 2.8 - Interfaces ATM..................................................................................................15

Figura 2.9 - Modelo de Referência para os Protocolos ATM..................................................16

Figura 2.10 - Estrutura da Camada AAL3/4 e AAL5.............................................................19

Figura 2.11 - Formato da CPCS-PDU para a AAL tipo 5.......................................................20

Figura 2.12 - PDUs AAL5.....................................................................................................21

Figura 2.13 - Fluxo de PDUs entre CPCS Origem e CPCS Destino........................................22

Figura 2.14 - Estrutura da Camada AAL de Sinalização (SAAL)...........................................23

Figura 2.15 - Protocolo Q.2931 no Modelo de Referência.......................................................24

Figura 2.16 - Estrutura da Mensagem Q.2931........................................................................27

Figura 2.17 - Estabelecimento e Encerramento de Conexão....................................................28

Figura 2.18 - Estabelecimento de Conexão não Completada...................................................28

Figura 2.19 - Diagrama de Estados do Protocolo Q.2931.......................................................29

Figura 2.20 - Elementos Básicos de Gerenciamento................................................................30

Figura 2.21 - Formas de Comunicação entre Gerente e Agente...............................................31

Figura 2.22 - PDUs SNMP....................................................................................................32

Figura 2.23 - Formato da Mensagem e das PDUs SNMP.......................................................33

Figura 2.24 - Grupos de Objetos da MIB-2............................................................................34

Figura 2.25 - Comunicação Gerente-Gerente no SNMPv2......................................................35

Figura 2.26 - PDUs SNMPv2................................................................................................36

Figura 2.27 - Formato da Mensagem e das PDUs SNMPv2....................................................37

Figura 2.28 - Agente Procurador............................................................................................38

Figura 3.1 - Rede ATM Com Servidores de Chaves...............................................................42

Figura 3.2 - Fases da Comunicação Segura............................................................................43

Figura 3.3 - Camadas ATM que Participam do Sistema de Segurança....................................43

Figura 4.1 - Distribuição de Chaves Públicas.........................................................................47

ix

Figura 4.2 - Distribuição de Chave de Sessão.........................................................................50

Figura 4.3 - Distribuição da Chave de Sessão com Autenticação Completa.............................52

Figura 4.4 - Distribuição de Chave Mestra.............................................................................54

Figura 4.5 - Distribuição de Chave de Sessão.........................................................................55

Figura 4.6 - Cifração de Mensagens e Ressincronização do Algoritmo....................................56

Figura 4.7 - Distribuição das Chaves Públicas por Domínio...................................................57

Figura 4.8 - Servidores de Chaves Distribuídos......................................................................59

Figura 4.9 - Hierarquia de Servidores de Chaves....................................................................60

Figura 5.1 - Distribuição de Chave e Autenticação.................................................................63

Figura 5.2 - Distribuição de Chave de Sessão.........................................................................64

Figura 5.3 - Seqüência de Eventos de Protocolo na Distribuição de Chaves entre Nós Origem eDestino.........................................................................................................67

Figura 5.4 - Elemento de Informação Broadband-Non-Locking Shift......................................68

Figura 5.5 - Elementos de Informação de Usuário..................................................................69

Figura 5.6 - Elemento de Informação User-User.....................................................................70

Figura 5.7 - Indicação de Criptografia no Elemento de Informação AAL Parameters.............71

Figura 5.8 - Seqüência de Eventos na Distribuição de Chaves entre Nó Origem e Servidores...72

Figura 5.9 - Elementos de Informação para Sinalização Nó Origem-Servidor..........................73

Figura 5.10 - Elemento de Informação Estado da Distribuição de Chaves...............................74

Figura 5.11 - Elementos de Informação para Sinalização Servidor-Servidor............................74

Figura 6.1 - Visão Geral do Sistema de Segurança.................................................................76

Figura 6.2 - Módulos de uma Estação Cliente........................................................................77

Figura 6.3 - Módulos de uma Estação Servidora....................................................................78

Figura 6.4 - Utilização das Funções da API............................................................................81

Figura 6.5 - Interação QCC-LSM-SSSP................................................................................82

Figura 7.1 - Formato da PDU da Subcamada CPCS...............................................................85

Figura 7.2 - Troca de Chave de Sessão e Vetor de Inicialização através de PDUs deGerenciamento..............................................................................................86

Figura 7.3 - PDUs CPCS de Gerenciamento de Chaves..........................................................86

Figura 7.4 - Estrutura da Subcamada de Segurança SSCS.....................................................87

Figura 7.5 - Formato da PDU do Protocolo de Segurança SSSP.............................................88

Figura 7.6 - Exemplo de PDUs SSSP e CPCS na Transmissão...............................................89

Figura 7.7 - Exemplo de PDUs SSSP e CPCS na Recepção...................................................89

Figura 7.8 - Instalação Inicial de Chave de Sessão e Vetor de Inicialização............................90

Figura 8.1 - Modelo de Gerenciamento...................................................................................92

Figura 8.2 - Distribuição de Chave Pública............................................................................92

Figura 8.3 - Distribuição de Chave e Autenticação.................................................................93

x

Figura 8.4 - Operações Agente-Gerente e Gerente-Gerente.....................................................93

Figura 8.5 - Operações SNMP na Distribuição das Chaves Públicas......................................96

Figura 8.6 - PDUs SNMP na Distribuição de Chaves Secretas...............................................98

Figura 8.7 - Mensagem SNMP Transportada por um Elemento de Informação de Usuário......99

1

Capítulo 1

Introdução

1.1 Segurança em Redes de Computadores

As redes de computadores estão permitindo um grande avanço nos processos de automatizaçãoda sociedade. Através das redes é possível efetuar transações financeiras, fazer compras,consultar informações em bancos de dados, controlar processos fabris, supervisionar e controlarplantas industriais, sistemas de distribuição de energia elétrica, sistemas de telecomunicações, emuitas outras atividades. Tudo isso é possível porque a evolução das tecnologias de hardware ede software tornaram possível uma comunicação que pode ser confiável, eficiente, e acessívelsob o ponto de vista da entrega dos dados. Mas existe um aspecto que não pode ser consideradocomo bem resolvido, que é o da segurança da informação contida nos dados. Uma boa parcelados dados que circulam pelas redes contém informações de valor financeiro, como informaçõestecnológicas sigilosas de empresas e governos, pedidos de compra, transferências de dinheiro,dados pessoais de usuários, informações de supervisão e controle e outros. Esses dados devemser confidenciais, mas existem pessoas, empresas e instituições ou governos, não autorizados,que têm interesse em conhecer ou alterar as informações por razões diversas. A utili zação dasredes em escala global, o espalhamento geográfico das redes e a interligação das redes à Internettornaram o acesso a esses dados mais fácil , facili tando as tentativas de captura e alteração dasinformações.

Existem diversas soluções para tentar resolver o problema de segurança em redes decomputadores, que vão desde equipamentos dedicados à segurança da intranet, até soluções emnível de aplicações, como o programa PGP e o sistema Kerberos [Stalli ngs 1995]. As soluçõeseficientes e eficazes são complexas e difíceis de operacionalizar, e as soluções mais simples nãosão suficientemente eficientes nem eficazes. Outro fator importante é a própria conscientizaçãodo usuário de rede sobre a importância da segurança. Existe uma tendência natural amenosprezar os riscos e, como os procedimentos são complexos, as medidas de segurança quedependem do usuário acabam não sendo utili zadas. Esses procedimentos devem ser, tantoquanto possível, automáticos, transparentes, e independentes do usuário.

O modelo OSI define uma arquitetura de segurança, descreve um conjunto de serviços desegurança e identifica onde, dentro do modelo OSI, estes serviços podem ser fornecidos [ISO7498, 1989]. Os serviços definidos são de diversos tipos: autenticação de origem e de destino,confidencialidade dos dados, controle de acesso, integridade dos dados, e não-rejeição [Sloman,1994]. Pelo menos um desses serviços pode ser fornecido em cada camada do modelo OSI. Emespecial, as camadas de rede e de transporte podem oferecer a maior parte dos serviços. Alémdisso, são definidos diversos mecanismos para implementação dos serviços. O principalmecanismo é a criptografia, aplicável a quase todos os serviços, e que permite um alto grau desegurança. A desvantagem do uso de criptografia é a complexidade envolvida nosprocedimentos. Os algoritmos utili zam parâmetros secretos que precisam ser gerenciados deforma eficiente e segura [Stalli ngs, 1995]. Como um mesmo mecanismo pode ser usado em cadaserviço, uma solução eficiente para a implementação de um tipo de serviço pode ser estendidapara os outros.

2

O modelo de gerenciamento OSI define também cinco áreas de gerenciamento, entre as quaisuma de gerenciamento de segurança [Brisa, 1993]. Esta área é dividida em três categorias deatividades: gerenciamento da segurança do sistema; gerenciamento dos serviços de segurança egerenciamento dos mecanismos de segurança. Para cada categoria é definido um conjunto defunções que implementam aquele tipo de atividade. Como o principal mecanismo é acriptografia, a principal atividade é a de gerenciamento de chaves que pertence à categoria degerenciamento dos mecanismos de segurança.

O uso de serviços, mecanismos e protocolos de gerenciamento para gerenciar a segurança darede pode permitir atingir os objetivos de automatização, transparência e independência deusuário, além de tornar a segurança parte de um esquema bem estruturado, organizado epadronizado de gerenciamento de rede.

Por outro lado, o crescimento das redes e a demanda por aplicações que exigem altas taxas detransmissão, motivaram o aparecimento de novas tecnologias de redes de alta velocidade. Umadas tecnologias que apareceram como solução para oferecer diversos tipos de serviço é aarquitetura ATM. O crescimento do mercado de ATM permite antever que esta será uma dastecnologias dominantes no mercado de redes de longa distância e provavelmente do mercado deredes locais e metropolitanas.

Como toda tecnologia emergente, o ATM tem que enfrentar o problema de compatibili zaçãocom as tecnologias já existentes, em especial com o TCP/IP que domina o mercado. As soluçõesjá existem e alguns padrões já estão se firmando. Os produtos que estão sendo lançados jápermitem o uso de IP sobre ATM [RFC1577, 1994] e emulação de LAN [Allens, 1995],preservando os investimentos já feitos e permitindo uma migração mais tranqüila para essa novatecnologia [RFC1577, 1994] [RFC1483, 1993]. Dessa forma, o ATM deverá se firmar comosolução para fornecer os novos serviços que o mercado está demandando e ao mesmo tempointegrar e compatibilizar os protocolos que hoje dominam o mercado.

Os principais problemas de segurança ocorrem nos tipos de tráfego onde existe um fluxo maiorde informações com valor financeiro. Este é o caso do tráfego de dados, porque astransferências de fundos, ordens de compra e venda, e outros serviços, são feitos através deaplicações que enviam e recebem dados. Na tecnologia ATM, cada tipo de tráfego é tratado poruma camada de protocolo de adaptação diferente, existindo protocolos para voz, dados e vídeo.Os serviços de transmissão de dados são tratados pela camada de adaptação AAL3/4 ou AAL5[Black, 1995].

Grande parte da pesquisa em segurança de redes de computadores se concentra em soluçõesespecíficas para as aplicações. Cada desenvolvedor de aplicativos adiciona ao seu software ostipos de serviços de segurança e mecanismos que acha importante. Por causa disso, os esquemasde segurança acabam se multiplicando dentro de um mesmo computador, com cada aplicaçãosegura utili zando um esquema diferente, com algoritmos de criptografia diferentes, e diversostipos de chaves, senhas e outros parâmetros. Para citar alguns exemplos, o NFS (Network FileSystems) utili za RPC seguro, O NIS+ (Network Information Service plus) da SunMicrosystems utili za o Kerberos, e o browser Netscape utili za o protocolo SSL (Secure SocketsLayer) [Cheswick e Bellovin, 1994] [Elgamal et al., 1996]. Se a segurança forimplementada em uma camada de rede utili zada por todos os aplicativos, um único sistema depode prover serviços de segurança a todos os programas, simpli ficando as aplicações e ogerenciamento de chaves criptográficas. Este tipo de solução é adequado para a maioria doscasos mas deve ser padronizado e não deve ser uma solução proprietária.

Outra vantagem interessante em colocar a segurança em uma camada de rede, através da qualtodos os dados tem que passar, está na possibili dade de fazer um isolamento lógico de um

3

computador. Para fazer o isolamento basta impedir qualquer transmissão ou recepção de dadossem utili zar o sistema de segurança1 implementado na(s) camada(s) de rede. Dessa forma, só épossível “entrar” no computador isolado através de outro que faça parte da rede segura2.Computadores que estão fora da rede segura não conseguem fazer seus dados nem chegar àscamadas de protocolos superiores porque não têm a chave criptográfica para cifrar os dadoscorretamente. Por isso, se o sistema de segurança for confiável, a entrada de usuários nãoautorizados no computador, através da rede, é praticamente impossível, pelo menos seminvestimentos da ordem de vários milhões de dólares em equipamentos para criptoanálise3. Oisolamento lógico permite que computadores que contém informações confidenciais possamestar interligados através de rede a outros computadores com um risco desprezível.

1.2 Objetivos

O objetivo desta dissertação é a definição de uma arquitetura para fornecer serviços desegurança para dados em redes ATM, de forma que a segurança possa ser aplicada a qualquertipo de dado que trafegue através da camada de adaptação AAL5. Qualquer aplicativo ou acamada de rede que opere sobre a pilha ATM, utili zando a camada AAL5, pode usar o sistemade segurança de forma transparente. No sistema de comunicação, apenas a pilha de protocolosATM participa do esquema de segurança. O serviço de gerenciamento de segurança,essencialmente o gerenciamento de chaves, pode também ser distribuído pela rede quandonecessário.

A tecnologia ATM foi escolhida em função de ser uma tecnologia com grande chance dedominar o mercado de rede em quase todos os segmentos em um futuro próximo. Por causadesta tendência, uma solução para segurança nesse tipo de rede poderá ter uma abrangênciagrande em termos de aplicabilidade.

1.3 Metodologia

O trabalho foi elaborado segundo as etapas relacionadas abaixo:

I. Levantamento bibliográfico

Foi feito um levantamento bibliográfico para realização do trabalho nos assuntosSegurança e Criptografia, Arquitetura e Protocolos de Redes ATM, Protocolo deSinalização e Protocolo de Gerenciamento SNMP.

II . Elaboração da especificação básica da arquitetura

Definição dos serviços, mecanismos e localização do sistema de segurança no modelode referência dos protocolos ATM.

III . Definição do protocolo de distribuição de chaves

Seleção de um protocolo de distribuição de chaves com características apropriadas paraoperação em redes de computadores e modificação desse protocolo para otimizar seuuso em redes.

IV. Adaptação do protocolo de distribuição de chaves aos protocolos de rede

1 Sistema que oferece os serviços de segurança aos usuários2 Rede pelos computadores que podem se comunicar utilizando o sistema de segurança3 Ramo da criptologia que trata da obtenção de informações decifradas a partir de dados cifrados semconhecimento da chave secreta.

4

Adaptação do protocolo de distribuição de chaves aos procedimentos e facili dades dosprotocolos de rede, de forma a permitir a distribuição eficiente das chaves criptográficassem modificação nos protocolos de rede.

V. Especificação do protocolo do serviço de segurança para a camada AAL5

Especificação de um protocolo para a subcamada SSCS da camada de adaptação ATMtipo 5 (AAL5) capaz de prover o serviço de segurança especificado.

VI. Adaptação do protocolo de distribuição de chaves ao modelo SNMPv2

Adaptação do protocolo de distribuição de chaves às operações, PDUs e estrutura deinformação gerencial do protocolo de gerenciamento SNMP.

VII . Especificação da arquitetura funcional do sistema de segurança

Especificação dos componentes que realizam os serviços de segurança dentro daestrutura de camadas ATM e sua função na arquitetura.

1.4 Organização do trabalho

Esta dissertação está dividida em nove capítulos, sendo o nono de conclusões:

Capítulo 1 - Esta introdução

Capítulo 2 - É feita uma revisão bibliográfica abordando os assuntos importantes para adissertação: criptografia, redes ATM, protocolo de sinalização e gerenciamento SNMP.

Capítulo 3 - Contém a especificação básica do sistema de segurança.

Capítulo 4 - É apresentado o protocolo que é utili zado para distribuir as chaves criptográficasde forma segura.

Capítulo 5 - É apresentada uma forma de distribuir as chaves através do protocolo desinalização.

Capítulo 6 - É apresentada a arquitetura funcional de um sistema de segurança descrevendocada um de seus componentes.

Capítulo 7 - É descrita a especificação de um protocolo de segurança para a camada AAL5 eum mecanismo para distribuir chaves através de PDUs de gerenciamento.

Capítulo 8 - É mostrado como o protocolo de gerenciamento SNMPv2 pode ser usado paramodelar o gerenciamento de chaves.

A Figura 1.1 é um diagrama que mostra as dependências entre os diversos assuntos abordadosnesta dissertação e pode orientar a leitura desse trabalho.

5

Redes ATM

Protocolo Q.2931

Criptografia

Protocolo de Distribuição de Chaves

Gerenciamento SNMP

Distribuição de Chaves em

Redes ATM

Protocolo SSSP

Distribuição de Chaves

SNMP

Especificação Básica

Arquitetura Funcional

do Sistema de Segurança

Arquitetura de um

Sistema de Segurança

Cap. 2

Cap. 2

Cap. 4

Cap. 3Cap. 2

Cap. 2

Cap. 8Cap. 7Cap. 5

Cap. 6

Figura 1.1 - Diagrama de Dependência dos Assuntos da Dissertação

6

Capítulo 2

Segurança, Redes ATM, Sinalização eGerenciamento SNMP

Este capítulo tem como objetivo fornecer os conceitos básicos para facili tar a compreensão dosassuntos tratados nos capítulos seguintes.

2.1 Segurança

2.1.1 Serviços e Mecanismos

Os serviços de segurança definidos pelo modelo de referência OSI são:

• Autenticação da origem

Serviço que garante ao receptor que a identificação da origem dos dados éverdadeira;

• Autenticação do destino

Serviço que garante ao transmissor que o receptor dos dados é realmente paraquem o transmissor deseja enviar os dados;

• Confidencialidade dos dados

Serviço que garante o segredo dos dados transmitidos contra observação nãoautorizada;

• Integridade dos dados

Serviço que garante que os dados recebidos não foram alteradosintencionalmente;

• Controle de acesso

Serviço que protege contra o uso não autorizado dos recursos;

• Não-rejeição

Serviço que impede a negação de envio ou recepção de dados através doregistro da origem e da recepção dos dados.

Diversos mecanismos podem ser utili zados para implementar os serviços descritos. No entanto,o mecanismo mais confiável, prático e utili zado na maioria das implementações de serviços desegurança é a criptografia. Todos os serviços anteriormente descritos podem utili zarcriptografia.

2.1.2 Algoritmos de Criptografia

Podemos conceituar os algoritmos criptográficos da seguinte forma:

Chamando de M uma mensagem e Kc o conjunto de chaves para utili zação com umalgoritmo E, então cada chave kc, escolhida em Kc, seleciona uma das possíveis funções

7

de transformação em E, tal que

Ekc(M) = C

onde EKc pertence a E. Deve existir um procedimento inverso para decifração, descritopor um algoritmo D e um conjunto de chaves Kd, e a chave kd seleciona uma daspossíveis funções em D, tal que

Dkd(C) = M

e Dkd pertence a D. Dependendo do tipo de algoritmo podemos ter

kc = kd = k e Ek = Dk-1 tal que Ek

-1(C) = M.

onde Dk-1 é a função inversa de Dk e a Ek

-1 é a função inversa de Ek.

Podemos ter um caso mais particular ainda onde Dk = Ek-1 = Ek.

Os algoritmos de cifração podem ser classificados em simétricos e assimétricos:

simétricos1: kc = kd = k, Ek = Dk-1 e Ek

-1(C) = M

assimétricos: kc �

kd, Ekc

� Dkc

-1, Ekd

� Dkd

-1 e Ekc = Dkd

-1

Os simétricos utili zam portanto a mesma chave tanto na cifração quanto na decifração. Osassimétricos utili zam uma chave para cifração e outra chave para decifração e são maisconhecidos como algoritmos de chave pública.

Algoritmos Simétricos

Os algoritmos simétricos podem ser de dois tipos quanto à operação: cifradores seqüenciais oude fluxo e cifradores de bloco. Nos cifradores de fluxo a chave original é modificada durante oprocesso de cifração enquanto os cifradores de bloco cifram blocos de n bits utili zando umachave que é fixa, não se altera com o processo de cifração.

Entre os algoritmos simétricos, os mais comuns são os cifradores de bloco, entre os quais o maisconhecido é o DES (Data Encryption Standard), que cifra blocos de 64 bits com chaves de 56bits. Outro algoritmo de bloco conhecido e bem mais confiável do que o DES, é o IDEA(International Data Encryption Algoritm), que cifra blocos de 64 bits com chaves de 128 bits[Schneier, 1996].

Os cifradores de bloco tem alguns modos de operação entre os quais os mais comuns são omodo Electronic Code Book2 e o modo Cypher Block Chainning3 (Figura 2.1) [Stalli ngs,1995].

1 E e D são itálicos para indicar cifração simétrica (E) e decifração simétrica (D)2 Livro de códigos eletrônico3 Encadeamento de bloco cifrado

8

No modo ECB, o cifrador funciona como um livro de códigos eletrônico e quando dois blocosiguais são cifrados, os criptogramas gerados também são iguais. Se ocorrer um erro natransmissão o bloco inteiro é decifrado errado mas o próximo bloco é decifrado corretamente senão houver outro erro. No modo CBC, o algoritmo de bloco passa a se comportar como umcifrador de fluxo. Neste caso, dois blocos iguais não geram o mesmo criptograma mas, porcausa do encadeamento, um erro causado pela perda ou acréscimo de bits na transmissão podeprovocar erros em todos os blocos seguintes. Isto ocorre devido à perda de sincronismo entrecifrador e decifrador. O vetor de inicialização IV é o bloco inicial de encadeamento e é usadopara ressincronização do algoritmo. Periodicamente, um novo e diferente vetor de inicialização éusado com o primeiro bloco de realimentação para recomeçar o encadeamento dos blocos erecuperar o sincronismo, sem permitir que blocos de mensagens iguais produzam blocos decriptogramas iguais.

Algoritmos Assimétricos ou de Chave Pública

Os algoritmos assimétricos, ou de chave pública, permitem garantir tanto o segredo dos dadosquanto a autenticidade da origem. O funcionamento genérico desses algoritmos pode ser descritoda seguinte forma [Diffie e Hellman, 1976]:

• Em um sistema de chave pública existe um procedimento de cifração E e umprocedimento de decifração D.

• Cada usuário gera um par de chaves { S, P} e a chave P é tornada pública enquantoS é mantida secreta.

• O algoritmo de cifração E e o de decifração D são ambos de conhecimento público.

• Uma mensagem M pode ser transmitida de A para B, com sigilo, através do seguinteprocedimento:

C = EPB(M) (cifração usando PB)

A � B : C (mensagem secreta)

M = DSB(C) (decifração usando SB)

BlockEncryption

BlockEncryption

BlockDecryption

BlockEncryption

BlockEncryption

BlockDecryption

BlockDecryption

BlockDecryption

Ks Ks Ks

Ks Ks Ks

C1 C2

IV

IV

M1 M2 M3

M1 M2 M3

C3

Ks

Ks

C1

M1

M1

ECB mode CBC mode

Figura 2.1 - Modos de Cifração Simétrica

9

Somente B, que é o único que tem SB, pode decifrar C.

• Uma mensagem M pode ser transmitida de A para B, com autenticação, através doseguinte procedimento:

C = ESA(M) (autenticação usando SA)

A � B : C (mensagem autenticada)

M = DPA(C) (verificação da autenticação usando PA)

Qualquer um pode decifrar C mas somente A, que é o único que tem SA, podegerar C a partir de M, logo C é a autenticação de M por A.

• Uma mensagem M pode ser transmitida para B, com sigilo e autenticação, atravésdo seguinte procedimento:

C = ESA(M) (autenticação usando SA)

C' = EPB(C) = EPB(ESA(M)) (cifração usando PB)

A � B : C’ (mensagem autenticada e secreta)

C = DSB(C') = DSB(EPB(C)) (decifração usando SB)

M = DPA(C) (verificação da autenticação usando PA)

Somente B pode decifrar C’ com SB, e em seguida pode verificar aautenticidade da origem de M porque somente A pode gerar C.

O algoritmo de chave pública mais conhecido é o RSA [Schneier, 1996]. Este algoritmo utili zacomo principio básico a dificuldade em fatorar grandes números primos:

P = {n, r} (n = p * q , p e q primos, r primo relativo a (p-1)*(q-1))

S = d (d = r-1 mod ((p-1)*(q-1)))

Cifração: C = Mr mod n

Decifração: M = Cd mod n

Os primos p e q são números de pelo menos 1024 bits (cerca de 300 dígitos) mas r pode ser umnúmero pequeno. Geralmente é usado um valor igual a 3, 17 ou 65.537. A mensagem M temque ser dividida em blocos de log 2 n bits para ser cifrada, e a decifração é feita também blocoa bloco.

2.1.3 Hierarquia de ChavesA vantagem na utili zação de algoritmos de chave pública é a complexidade quadrática paradistribuir as chaves4 e para implementar a autenticação sem necessidade de muitas interações.No entanto, a desvantagem é a grande quantidade de processamento necessário para efetuar ocálculos de cifração e decifração, que tornam esses algoritmos muito lentos. Os algoritmossimétricos são de 100 a 1000 vezes mais rápidos do que os assimétricos, mas a distribuição dechaves é mais difícil.

Um ataque a uma mensagem cifrada (criptograma) objetiva recuperar a mensagem original e/ouobter a chave usada na cifração. O ataque ao criptograma fica mais fácil se o atacante tiver

4 Para a comunicação entre cada par de nós, usando algoritmos simétricos, deve ser distribuída umachave secreta, ou seja, O(n2) operações manuais. Com chaves públicas são necessárias apenas O(n)operações para distribuir as chaves públicas e a chave secreta é distribuída de forma automática eapenas se houver comunicação.

10

conhecimento de alguma parte da mensagem original ou de algumas informações estatísticassobre esta mensagem. Se o algoritmo for seguro, ou seja resistente à criptoanálise5, e se nãohouver qualquer informação sobre a mensagem original, a única forma de decifrar ocriptograma, sem conhecer a chave, é através de um ataque por exaustão testando cada uma daschaves possíveis. Se o tamanho da chave for suficientemente grande e o algoritmo for de boaqualidade, a decifração através de ataque por exaustão é inviável. Além disso, quanto maior onúmero de mensagens cifradas com uma mesma chave, maior a quantidade de informaçõesacumulada e mais fácil se torna a tentativa de ataque. Mesmo que um ataque permita encontraruma chave usada, a sua troca periódica impede que a obtenção de uma chave permita adecifração de todas as mensagens subsequentes à troca da chave comprometida.

Estas características dos algoritmos e dos criptogramas levaram à criação dos sistemas dechaves hierárquicas. Nesses sistemas, um algoritmo de chave pública é usado apenas paradistribuir uma chave secreta aleatória Ks entre dois usuários A e B, cifrando a chave com achave pública assimétrica PB do destinatário B e autenticando com a chave secreta assimétricaSA do remetente A. Ks é utili zada apenas em uma única sessão envolvendo A e B e por isso estachave é denominada chave de sessão secreta, ou simplesmente chave de sessão. Para cada novasessão, uma nova chave secreta Ks deve ser gerada. A chave de sessão é utili zada em umalgoritmo simétrico para cifrar as mensagens:

• Distribuição de chaves com algoritmo de chave pública:

A e B geram pares {P,S} e publicam as respectivas chaves PA e PB

A gera Ks

A � B : ESA(EPB(Ks))

• Confidencialidade com algoritmo simétrico:

A � B : EKs(M1)

B � A : EKs(M2)

A chave de sessão é trocada com freqüência enquanto as chaves assimétricas são trocadasraramente. É inviável computacionalmente com a tecnologia atual a recuperação da chave Kssem conhecer SB. Como Ks é gerada aleatoriamente, o atacante não sabe como identificar umachave de sessão a não ser testando uma por uma nos criptogramas. Dessa forma, é possível usaras mesmas chaves assimétricas para distribuir chaves de sessão durante muito tempo semcomprometer a segurança.

A hierarquia de chaves pode ter mais níveis. Em uma hierarquia de três níveis, um sistema dechave pública é usado apenas para distribuir uma chave secreta aleatória Km para algoritmosimétrico. Km é usada apenas para cifrar as chaves de sessão e distribuí-las:

• Distribuição de chaves com algoritmo simétrico e algoritmo de chave pública:

A e B geram pares {P,S} e publicam as respectivas chaves PA e PB

A gera Km e Ks

A � B : ESA(EPB(Km))

A � B : EKm(Ks)

• Confidencialidade com algoritmo simétrico:

5 Ramo da criptografia dedicada à quebra dos algoritmos criptográficos para recuperar informaçõescifradas sem conhecimento da chave ou forjar mensagens para serem aceitas como autênticas.

11

A � B : EKs(M1)

B � A : EKs(M2)

A chave secreta Km é denominada chave mestra secreta, ou simplesmente chave mestra.

As mesmas considerações anteriores podem ser estendidas para este procedimento, mas deve-seacrescentar que é fundamental que Km só seja utili zado para cifrar a chave Ks. A vantagemnesse caso é tornar a distribuição de chave de sessão mais rápida porque o tempo deprocessamento para decifra-las é muito menor utilizando algoritmo simétrico.

2.1.4 Função Hash Unidirecional (Função de Espalhamento)As funções hash unidirecionais podem ser utili zadas para garantir integridade dos dados,gerando um código verificador com características criptográficas. Uma função hashunidirecional H(M) gera um valor h de tamanho fixo n, a partir de operações sobre umamensagem M de tamanho m [Schneier, 1996]:

h = H(M)

A função tem as seguintes características:

• É fácil computar h a partir do conhecimento de M

• É difícil computar M tal que H(M) = h

• É difícil achar outra mensagem M’ tal que H(M) = H(M’)

Uma função hash pode operar sobre mensagens de tamanho arbitrário, dividindo a mensagemem blocos de m bits (M i) e utili zando o valor do hash (hi-1) do bloco anterior (M i-1) paracomputar o valor (hi) do bloco atual (Mi), ou seja, hi = H(Mi, hi-1) (Figura 2.2).

O valor de hash é o que é computado com o último bloco da mensagem. Uma função hashmuito utili zada é a MD5 [RFC1321, 1992] que opera sobre blocos de 512 bits e gera um valorde 128 bits.

2.1.5 Aplicações dos AlgoritmosCada tipo de algoritmo criptográfico tem uma aplicação típica mais comum. Os algoritmossimétricos de bloco são utili zados geralmente em serviços de confidencialidade dos dados. Osalgoritmos assimétricos são utili zados para prover autenticação e realizar distribuição dechaves. As funções hash unidirecionais são utili zadas para prover serviço de integridade dosdados e autenticação.

2.2 Redes ATM

2.2.1 IntroduçãoA crescente utili zação de aplicações multimídia levou à necessidade do desenvolvimento de umatécnica de comutação rápida de pacotes (Fast Packet Switching - FPS) denominada

Mi

hi-1

hi

One-wayHash

Function

Figura 2.2 - Função Hash Unidirecional

12

Asynchronous Transfer Mode6 (ATM), especificada pelo Forum ATM7 e adotada como padrãopelo International Telecommunications Union (ITU).

O ATM é baseado em comutação de células e em multiplexação por divisão de tempoassíncrona, onde a alocação de tempo por canal é feita sob demanda e não de forma pré-determinada. Os pacotes tem tamanho fixo de 53 octetos, chamados células, e não é feitoqualquer controle de erro ou de fluxo nos enlaces. As células são transmitidas através deconexões com circuitos virtuais estabelecidos através de um protocolo de sinalização, utili zandoas informações do cabeçalho para roteamento [Black, 1995].

As redes ATM foram projetadas para suportar diversos tipos de serviços com diferentesrequisitos e operar em velocidades altas para suportar os serviços multimídia. As informaçõessão transportadas em células ATM compostas de um cabeçalho e um campo de informação.Embora a transmissão seja síncrona, as células são inseridas no canal de acordo com ademanda, de forma que não existe necessariamente um intervalo regular entre uma célula eoutra. Este intervalo vai depender do tipo de serviço e da demanda.

2.2.2 Célula ATMA Figura 2.3 mostra a estrutura de uma célula ATM. São 53 octetos, sendo os cinco primeirosoctetos de cabeçalho (header) e os restantes 48 octetos de informações (payload) [I.361, 1993].

O cabeçalho é bem simples, visando a eficiência, e carrega o mínimo de informaçõesnecessárias. Isto permite que o seu processamento nos comutadores ocorra em altas velocidades,diminuindo os atrasos nas filas dos comutadores. Sua estrutura é mostrada na Figura 2.4 para ainterface usuário-rede (UNI), e consiste de seis campos:

• GFC: utili zado para controlar de forma eficiente o fluxo de tráfego no enlaceusuário-rede;

• VCI: identifica o canal virtual através do qual a célula é transmitida;

• VPI: identifica o caminho virtual através do qual a célula é transmitida;

• PT: identifica o tipo de informação contida na célula (de usuário ou degerenciamento)

• CLP: indica se a célula é de baixa ou alta prioridade;

6 Modo de Transferência Assíncrona7 Consórcio de empresas e organizações criada para acelerar o desenvolvimento e implantação datecnologia ATM

8 12345671

56

53

Bits:

53 octet cell

Header(5 octets)

Information field(48 octets)

Figura 2.3 - Estrutura da Célula ATMFONTE - [I.361, 1993], p. 1

13

• HEC: Código corretor de erro para identificar e corrigir erros nos 4 primeirosoctetos do cabeçalho.

O HEC só identifica e corrige erros no cabeçalho. O campo de informações não tem controle deerros.

2.2.3 Conexões VirtuaisUma rede ATM é composta de equipamentos que possuem interface ATM e comutadorespúblicos e privados que interligam esses equipamentos (Figura 2.5). Um comutador ATM tem afunção de encaminhar cada célula que chega em um enlace de entrada para um enlace de saída,utili zando as informações dos campos VPI e VCI do cabeçalho da célula, de acordo com umatabela de comutação. Os valores de VPI/VCI de cada célula são modificados de acordo com atabela de comutação quando a célula é encaminhada para um enlace de saída.

O ATM é um modo de transferência orientado à conexão. Uma conexão é um caminho únicoatravés do qual as células chegam ao destino. Esse caminho é denominado circuito virtual. Umaconexão ATM é formada pela concatenação de enlaces ATM. Uma conexão pode serpermanente (Permanent Virtual Circuit8 - PVC) ou estabelecida dinamicamente (SwitchedVirtual Circuit9 - SVC). É necessária uma fase inicial de estabelecimento de conexão paraenviar dados no caso de SVC. No estabelecimento da conexão, os endereços ATM da origem edo destino devem ser fornecidos juntos com o tipo de serviço (ex.: CBR), os parâmetros detráfego (ex.: taxa máxima de transferência), e parâmetros de QoS (ex.: latência). Noestabelecimento é utili zado o protocolo de sinalização Q.2931 (seção 2.3). Os comutadoresutili zam os endereços para estabelecer uma rota e utili zam o tipo de serviço e os parâmetrospara alocar recursos e estabelecer um canal com as características solicitadas. 8 Circuito Virtual Permanente9 Circuito Virtual Comutado

8 7 6 5 4 3 2 1Bit

Octet

GFC VPI 1

VPI VCI 2

VCI 3

VCI PT CLP 4

HEC 5

CLP Cell Loss PriorityGFC Generic Flow ControlPT Payload TypeHEC Header Error ControlVPI Virtual Path Identifier

VCI Virtual Channel Identifier

Figura 2.4 - Estrutura do Cabeçalho da Célula ATM (UNI)FONTE - [I.361, 1993], p. 2

14

Cada célula carrega dois identificadores no cabeçalho que identificam a conexão. O ITUestabeleceu uma hierarquia de multiplexação e comutação entre o VPI, VCI e o meio físico[I.150, 1995]. Esta relação é mostrada na Figura 2.6.

Canais virtuais (Virtual Channels - VCs) podem ser agrupados em caminhos virtuais (VirtualPath - VPs) e os caminhos virtuais tem uma identificação única dentro de uma conexão física10.Um enlace ATM é definido pela combinação VPI/VCI e meio físico.

As conexões ATM podem ser estabelecidas por canais virtuais (Virtual Channel Connections -VCCs) ou por caminhos virtuais (Virtual Path Connections - VPCs). O conceito de VCC ésemelhante ao conceito de circuito virtual, e é um caminho único formado pela concatenação deconexões virtuais desde a origem até o destino, através do qual as células são encaminhadas. Ascélulas que chegam no comutador, em um enlace ATM, são encaminhadas ao próximo enlace docaminho determinado por um VCC. Cada VCC é associada a uma porta do comutador que faz omapeamento de cada enlace de entrada com um enlace de saída. Para isto são utili zados os

10 Cabo de cobre ou cabo de fibra ótica

Gateway

LAN, MAN or WAN

PUBLIC NETWORK

Private ATMSwitch

Public ATMSwitch

NNI

Public ATMSwitch

Figura 2.5 - Exemplo de Rede ATM

PHYSICAL MEDIUM

VPI 1

VPI 2

VCI 1VCI 2

VCI 1

Figura 2.6 - O Meio Físico e a Relação entre VPI e VCI

15

valores de VPI/VCI no cabeçalho de cada célula, de acordo com as tabelas internas deroteamento estabelecidas na fase de conexão.

Os VCCs podem ser agrupadas e roteadas pelo mesmo caminho. Este é o conceito de VPC, quepermite reduzir o processamento nos comutadores porque os VCCs são comutados em conjuntoutilizando apenas a informação do VPI das células.

Os comutadores podem fazer a comutação utili zando apenas o VPI ou a comutação utili zandoVPI e VCI. A Figura 2.7 mostra um comutador que utiliza VPI e VCI.

2.2.4 Modelo de ReferênciaA arquitetura de referência ATM define as interfaces padronizadas para interconexãousuário-comutador e comutador-comutador. São definidos dois tipos de interface: usuário-rede(UNI) e rede-rede (NNI). A UNI pode ser pública ou privada e é usada para conexãousuário-comutador e comutador privado-comutador público, enquanto a NNI é usada naconexão comutador público-comutador público (Figura 2.8).

Os protocolos de rede ATM seguem a estrutura hierarquizada do modelo de referência OSI. AFigura 2.9 mostra o modelo de referência para os protocolos ATM [I .321, 1991]. Este modeloutiliza o conceito de planos para separar as funções de usuário, controle e gerenciamento:

VP Switch

VC Switch

VCI 1 VPI 1VCI 2

VCI 3

VCI 4

VCI 1VCI 2

VCI 1 VCI 2VCI 3

VCI 4

VCI 1VCI 2VPI 4

VPI 2

VPI 3

VPI 5

Figura 2.7 - Comutação de VP e de VC

ATM User

Private ATM

Switch

ATM Switch

ATM Switch

ATM User

Public ATM NetworkPublic UNI

Private UNI NNI

Figura 2.8 - Interfaces ATM

16

Plano de Usuário11: é utili zado para o tráfego gerado pelos usuários; É dividido em camada deAdaptação, camada ATM e camada Fisica.

Plano de Controle12: é responsável pelos procedimentos e tráfego de sinalização, estabelecendo,supervisionando e liberando conexões dinamicamente; É dividido em camadas da mesma formaque o plano de usuário.

Plano de Gerenciamento13: realiza as funções de gerenciamento das camadas, gerenciamento dosplanos e tratamento dos fluxos de informações de operação, administração e manutenção.

O gerenciamento de camadas segue a estrutura de camadas dos planos de usuário e de controle.A sua função é gerenciar os recursos e parâmetros associados à cada entidade de protocolo ecuidar do fluxo de informações de operação e manutenção de cada camada.

A Tabela 2.1 apresenta um resumo das funções de cada camada no modelo ATM. Pode-seobservar que as camadas de Adaptação e Física são divididas em subcamadas.

11 User Plane12 Control Plane13 Management Plane

Figura 2.9 - Modelo de Referência para os Protocolos ATM

17

2.2.5 Taxas de TransmissãoO sistema de transmissão de redes ATM é baseado no SDH14 (Synchronous Digital Hierarchy) eno SONET15 (Synchronous Optical Network) [Black, 1995]. O SDH é derivado do SONETmas existem diferenças entre os dois sistemas [T1X1.2, 1993]. O sinal básico do SDH tem umataxa de transmissão de 51,84 Mbps e transporta a informação em quadros. Os níveis superioressão múltiplos do sinal básico. O ITU padronizou para as interfaces NNI as taxas de 155,52Mbps (3 x 51,84 Mbps) e 622,08 Mbps (12 x 51,84 Mbps), baseadas no SDH. Para a UNI, astaxas são 51,84 Mbps, 155,52 Mbps e 622,08 Mbps, baseadas no SONET.

Outros sistemas de transmissão com outras taxas também foram adotadas como o sistemabaseado em células e o sistema baseado no PDH (Plesyochronous Digital Hierarchy) [Balck,1995]. O sistema mais utilizado é o do SONET.

2.2.6 Camada de Adaptação ATM (AAL)A camada de adaptação ATM oferece ao usuário serviços com requisitos específicos de acordocom o tipo de aplicação. A camada AAL utili za os serviços da camada ATM e faz umaadaptação dos dados de acordo com a natureza dos dados transmitidos pela aplicação.Diferentes tipos de serviço podem ser oferecidos pela rede ATM e esta flexibili dade é obtidaatravés da camada de adaptação. O serviço da AAL é um serviço fim-a-fim e só existe nospontos terminais da conexão ATM, logo não está presente nos comutadores.

14 Sistema de transmissão padronizado pelo ITU15 Sistema de transmissão padronizado pelo ANSI

Controle genérico de fluxo

Geração e extração de cabeçalho

Tradução de VPI/VCI de célula

Multiplexação e demultiplexação de célula

Convergência

Segmentação e remontagem

Desacoplamento de taxa de célula

Geração/verificação de seqüência HEC

Delimitação de células

Adaptação de quadro de transmissão

Geração/recuperação de quadro de transmissão

Sincronismo de bit

Meio físico

CS

SAR

TC

PM

AAL

ATM

PHY

FunçãoSub-camada

Camada

Tabela 2.1 - Subcamadas e Funções do Modelo de Referência

18

Levando em conta as características das aplicações e procurando minimizar o número deprotocolos AAL, o ITU definiu quatro classes de serviços [I .362, 1993]. Essas classesprocuram organizar os diferentes tipos de tráfego segundo três parâmetros característicos, demodo a padronizar o tipo de protocolo adequado a cada tráfego. Os protocolos padronizadossão o AAL0, AAL1, AAL2, AAL3/4 e AAL5 [I .362, 1993]. A Tabela 2.2 mostra as classes,suas características, qual o protocolo AAL adequado e o tipo de aplicação que se enquadra noserviço. O protocolo AAL0 não é mostrado porque é um protocolo nulo, ou seja, o usuárioutiliza a camada ATM diretamente.

A camada AAL é constituída de duas subcamadas [I .363, 1993]. A subcamada de convergência(CS) que, dependendo do tipo de AAL, é responsável pela detecção de perda de células eregeneração da relação temporal da informação original. A subcamada de segmentação eremontagem (SAR) fragmenta os dados recebidos da subcamada CS na transmissão paraacomodá-los no campo de informações da célula ATM. A subcamada SAR remonta os dados apartir das células na recepção. Dependendo do tipo de AAL, a subcamada SAR pode serresponsável pela multiplexação de conexões AAL em uma conexão ATM.

Nos protocolos AAL3/4 e AAL5, a subcamada CS é subdivida em duas subcamadas:Subcamada de Convergência Específica de Serviço (SSCS), e Parte Comum da Subcamada deConvergência (CPCS). A subcamada SSCS fornece funções específicas adicionais que podemser necessárias para determinadas aplicações. A subcamada CPCS adiciona cabeçalhos aosquadros do usuário e é responsável pela detecção de erros nesses quadros. A subcamada SSCSpode ser nula e, neste caso, o usuário utili za a subcamada CPCS diretamente. A estrutura dascamadas AAL3/4 e AAL5 é mostrada na Figura 2.10.

As camadas AAL3/4 e AAL5 são adequadas para transmissão de dados. A diferença entre asduas está na capacidade da camada AAL3/4 de realizar a multiplexação de várias conexõesAAL3/4 em uma única conexão ATM, enquanto a camada AAL5 não realiza multiplexação. Acamada AAL5, pela sua maior simplicidade, é mais utilizada para transmissão de dados.

Dentro da subcamada de convergência podem coexistir diversos serviços específicos, ou seja, nasubcamada SSCS podem ser implementados diversos protocolos específicos.

As placas de rede ATM que atualmente são comercializadas implementam a camada física, acamada ATM e a subcamada SAR em hardware enquanto a subcamada de convergência éimplementada em software, no driver da placa.

Classes Classe A Classe B Classe C Classe DTempo na Fonte e noDestino

Relacionado Sem Relação

Taxa de Geração deBits

Constante( CBR )

Variável( VBR )

Modo de Conexão Orientado à Conexão Sem ConexãoCamada de Adaptação AAL 1 AAL 2 AAL 3/4 ou AAL 5Aplicações Voz e Vídeo a

TaxasConstantes(ServiçosIsócronos)

Voz e Vídeo aTaxasVariáveis

Serviços NãoIsócronosOrientados àConexão

Serviços NãoIsócronos e SemConexão

Tabela 2.2 - Classes de Serviço

19

Camada AAL tipo 5

A camada AAL5 transfere dados contidos em unidades de dados do serviço (SDU) da camadaAAL5 (AAL-SDUs) entre entidades AAL. Podem ser oferecidos dois modos de serviço: modode serviço de mensagem, no qual cada quadro recebido de usuário é enviado através da rede, emodo de serviço de fluxo, no qual um fluxo de quadros de usuário é enviado pela rede. Existemdois modos de operação: com recuperação de erro fim-a-fim e sem recuperação de erro. Osmodos de serviço e modos de operação são funções da subcamada SSCS. Se a subcamadaSSCS for nula, cada AAL-SDU é mapeada em uma unidade de dados do serviço CPCS (CPCS-SDU) e o serviço é sem recuperação de erros (apenas detecção de erros).

A camada AAL5 tem as seguintes primitivas: AAL-UNIDATA.request para envio de dados,AAL-UNITDATA.indication para recepção de dados, AAL-U-ABORT.request parainterromper o envio de uma SDU, AAL-U-ABORT.indication para indicar a interrupção doenvio de uma SDU, e AAL-P-ABORT.indication para indicar que a SDU deve ser descartadadevido algum erro em uma camada inferior.

Se a subcamada SSCS for nula, as primitivas AAL são mapeadas diretamente em primitivasCPCS. As primitivas da subcamada CPCS são as mesmas da camada AAL mas, como nãoexiste o conceito de ponto de acesso ao serviço (Service Access Point - SAP) entre assubcamadas, as primitivas são chamadas invoke e signal ao invés de request e indication.

A unidade de dados do protocolo CPCS (CPCS-PDU) é construída a partir da unidade de dadosdo protocolo (PDU) que chega da camada superior, que passa a ser uma unidade de dados deserviço CPCS (CPCS-SDU), acrescentando-se octetos de preenchimento (PAD) e um trailer. OPAD é acrescentado para deixar a CPCS-PDU com tamanho final múltiplo de 48 octetos. Dessaforma, a subcamada de segmentação e remontagem (SAR) pode dividir a PDU em pedaçosinteiros de 48 octetos e colocar cada pedaço em uma célula ATM. O trailer contém o tamanhoda SDU, um campo com CRC (Cyclic Redundancy Check) da PDU para detecção de erros, umcampo para transportar informações do usuário da subcamada CPCS, e um campo sem uso

Figura 2.10 - Estrutura da Camada AAL3/4 e AAL5FONTE - [I.363, 1993], p. 38

20

definido que serve para completar o trailer para que fique com tamanho de 64 bits. A Figura2.11 mostra o formato da CPCS-PDU.

Na transmissão, a subcamada de segmentação e remontagem (SAR) tem a função de dividir asunidades de dados do serviço SAR (SAR-SDU) de tamanho variável (múltiplo de 48 octetos),que foram recebidas como CPCS-PDUs, em unidades de dados do protocolo SAR (SAR-PDU)de tamanho fixo de 48 octetos.

As primitivas da subcamada SAR são: SAR-UNITDATA.invoke para envio de dados e SAR-UNITDATA.signal para recepção de dados. Cada SAR-PDU é entregue à camada ATM ondeo cabeçalho da célula é acrescentado. Na recepção, a subcamada SAR recebe as PDUs dacamada ATM e reagrupa as SAR-PDUs para reconstituir a SAR-SDU original. O bit menossignificativo do campo PTI do cabeçalho da célula ATM, denominado ATM-layer-user toATM-layer-user (AUU), permite indicar a última célula de uma SAR-SDU, delimitando o fimde uma SAR-SDU e o início da próxima. A Figura 2.12 mostra as PDUs definidas na camadaAAL5 e a Figura 2.13 mostra o fluxo de PDUs entre transmissor e receptor. A subcamada SARutili za as primitivas da camada ATM, ATM-DATA.request e ATM-DATA.indication, paraenviar e receber as SAR-PDUs, respectivamente.

CPCS - SDU PAD TRAILER

UU CPI Length CRC

CPCS - PDU trailer

CPCS - PDU

PAD : 0 to 47 octetsCPCS-UU : CPCS User-to-User Indication (1 octet)CPI : Common Part Indicator (1 octet)Length: Length of CPCS-SDU (2 octets)CRC: Cyclic Redundant Check (4 octets)

AAL type 5 CPCS - PDU

Figura 2.11 - Formato da CPCS-PDU para a AAL tipo 5

21

CPCS-PDUTrailer

P A DCPCS-PDU Payload

CPCS-SDU

ATM-SDU

Cell Information FieldCell

Header

SAR-PDU Payload

SAR-PDU Payload

SAR-PDU Payload

SAR-PDU Payload

ATM-PDU = Cell

SAR-PDU

SAR-PDU

SAR-PDU

SAR-PDU

CPCS-PDU

AUU

1

AUU0

AUU0

AUU

0

Figura 2.12 - PDUs AAL5FONTE - [I.363, 1993], p. 71

22

O ITU considerou que o estabelecimento de conexão deve ser feito através de um serviçoconfiável, ou seja, deve haver garantia de entrega dos dados no destino. Para isso, especificou oService Specific Conection Oriented Protocol16 (SSCOP) que oferece um serviço confiável comdetecção e recuperação de erros de transmissão [Q.2110, 1993]. Este protocolo foi especificadopara ser usado pelo protocolo de sinalização que fica localizado no nível três, ou seja, logo

16 Protocolo Orientado à Conexão Específico do Serviço

CPCS-UNITDATA signal

SAR-UNITDATAsignal

SAR-UNITDATAsignal

SAR-UNITDATAsignal

SAR-UNITDATAsignal

SAR-UNITDATA invoke

CPCS-UNITDATA invoke

Add PAD field

Add CPCS trailer

Strip PAD field

Strip CPCS trailer

AUU=1SAR-PDU

AUU=0SAR-PDU

AUU=0SAR-PDU

AUU=0SAR-PDU

AUU bit

Set

AUU bit

Interpret

CPCS

SAR

CPCS

Figura 2.13 - Fluxo de PDUs entre CPCS Origem e CPCS DestinoFONTE - [I.363, 1993], p. 72

23

acima da camada AAL. Especificou também o Service Specific Coordination Function17

(SSCF) para fazer o mapeamento dos requisitos particulares do protocolo de sinalização para osserviços SSCOP [Q.2130, 1993]. O SSCOP e o SSCF são serviços específicos e ficam nasubcamada SSCS da camada AAL5. A Figura 2.14 mostra esta estrutura da AAL5,denominada AAL de sinalização (SAAL).

2.3 Protocolo de Sinalização Q.2931

Um protocolo de sinalização define os procedimentos e mensagens utili zados paraestabelecimento, manutenção e encerramento de conexões de circuitos virtuais. O ATM Forumespecificou que a sinalização em redes ATM [UNI Signalli ng, 1994] deve seguir o protocoloQ.2931 [Q.2931, 1995] para conexões ponto-a-ponto, e o protocolo Q.2971 [Q.2971, 1995]para conexões ponto-a-multiponto. A Figura 2.15 mostra a posição do protocolo Q.2931 nomodelo de referência.

17 Função de Coordenação Específica do Serviço

Service SpecificCoordination Function

(SSCF)

SSCS

CS

Service SpecificConection OrientedProtocol (SSCOP)

CPCS

AAL5

SAR

SAAL SAP

ATM SAP

Figura 2.14 - Estrutura da Camada AAL de Sinalização (SAAL)

24

2.3.1 Primitivas de ServiçoO protocolo Q.2931 oferece um conjunto de primitivas de serviço para envio e recepção demensagens de sinalização. As primitivas mais importantes estão relacionadas na Tabela 2.3.

18 Direção usuário-Q.2931

Figura 2.15 - Protocolo Q.2931 no Modelo de Referência

Primitiva Direção Descrição

Setup.req U � Q18 transmite uma mensagem SETUP

Setup.ind Q � U19 recebe uma mensagem SETUP

Setup.resp U � Q transmite uma mensagem CONNECT

Setup.conf Q � U recebe uma mensagem CONNECT e transmite umamensagem CONNECT_ACK

Setup-complete.ind Q � U recebe uma mensagem CONNECT_ACK

Release.req U � Q transmite uma mensagem RELEASE

Release.ind Q � U recebe uma mensagem RELEASE

Release.resp U � Q transmite uma mensagem RELEASE_COMPLETE

Release.conf Q � U recebe uma mensagem RELEASE_COMPLETE

Alerting.req U � Q transmite uma mensagem ALERTING

Alerting.ind Q � U recebe uma mensagem ALERTING

Proceeding.req U � Q transmite uma mensagem CALL_PROCEEDING

Proceeding.ind Q � U recebe uma mensagem CALL_PROCEEDING

Tabela 2.3 - Primitivas Q.2931

25

2.3.2 Mensagens Q.2931As mensagens estão relacionadas por categoria na Tabela 2.4. Existe uma categoria commensagens para estabelecimento de conexões, uma categoria para encerramento conexões, umacategoria de mensagens de referência global de chamada, e uma categoria de mensagens que nãopertencem às três categorias anteriores. As mensagens podem ter significado local ou global.Mensagens com significado global têm relevância para os acessos terminais20 e para a rede.Mensagens com significado local tem relevância apenas para os acessos terminais.

As mensagens de sinalização transportam os parâmetros de conexão e outras informações emcampos de tamanho variável denominados Elementos de Informação.

Os Elementos de Informação que uma mensagem pode ter depende do tipo da mensagem. Paracada mensagem, o número e tipos de elementos é diferente. Além disso, existem elementos quesão obrigatórios e outros que são opcionais. O tamanho dos elementos depende do tipo deelemento e em alguns casos das informações que transportam. A Tabela 2.5 mostra oselementos de informação que a mensagem SETUP pode ter, indicando a direção permitida,indicando se é opcional (O) ou obrigatório (M), e indicando o tamanho em octetos. Essasmensagens tem significado global.

19 Direção Q.2931-usuário20 Conexão local usuário-rede ou rede-usuário

Mensagens Q.2931 Significado DescriçãoMensagens de conexão:ALERTING Global Avisa ao chamador que o SETUP

foi recebidoCALL PROCEEDING Local Estabelecimento de conexão

iniciadoCONNECT Global Conexão aceitaCONNECT ACKNOWLEDGE Local Aceitação da conexão confirmadaSETUP Global Inicia estabelecimento de conexãoMensagens de desconexão:RELEASE Global Inicia encerramento da conexãoRELEASE COMPLETE Local/Global Conexão encerradaOutras mensagens:NOTIFY Global Informação sobre a conexãoSTATUS Local Estado da conexãoSTATUS ENQUIRY Local Solicita estado da conexãoMensagens de reinicio:RESTART Global Reinicia todos os VCsRESTART ACKNOWLEDGE Local Confirmação do RESTART

Tabela 2.4 - Mensagens Q.2931

26

2.3.3 Formato das MensagensO formato das mensagens Q.2931 é mostrado na Figura 2.16. Cada mensagem consiste de umcabeçalho de nove octetos seguido de um ou mais elementos de informação. Estes contêm osparâmetros da conexão, informações sobre estado da conexão, controle e outros. Cada elementode informação tem um cabeçalho de quatro octetos seguido de zero ou mais octetos contendoinformações específicas do elemento de informação. Na Figura 2.16, a mensagem tem, entreseus Elementos de Informação um elemento que contém os parâmetros da camada AAL5.

21 Usuário-rede e rede-usuário22 Usuário-rede (User-Network)

Tipo da mensagem: SETUPSignificado: GlobalDireção: AmbosElemento de Informação Direção Tipo TamanhoProtocol discriminator Ambas21 M 1

Call reference Ambas M 4

Message type Ambas M 2

Message length Ambas M 2

User-User Information Ambas O 4-133

AAL parameters Ambas O 4-21

ATM traffic descriptor Ambas M 12-20

Broadband bearer capability Ambas M 6-7

Broadband high layer information Ambas O 4-13

Broadband repeat indicator Ambas O 4-5

Broadband low layer information Ambas O 4-17

Called party number Ambas O 4-*

Called party sub-address Ambas O 4-25

Calling party number Ambas O 4-*

Calling party sub-address Ambas O 4-25

Connection identifier Ambas O 4-9

End-to-end transit delay Ambas O 4-10

Notification indicator Ambas O 4-*

OAM traffic descriptor Ambas O 4-6

QOS parameter Ambas M 6

Broadband sending complete Ambas O 4-5

Transit network selection U � N22 O 4-*

Tabela 2.5 - Elementos de Informação da Mensagem SETUP

27

2.3.4 Procedimentos de ConexãoA Figura 2.17 mostra a utili zação das mensagens nos procedimentos de estabelecimento eencerramento de conexão. O estabelecimento começa com o envio da mensagem SETUP pelousuário chamador23. A mensagem contém um valor de referência de chamada (Call reference)para identificar localmente as mensagens relativas a um procedimento de conexão. A mensagemSETUP transporta os endereços origem e destino, características de tráfego e de QoS, além deoutras informações opcionais. Uma mensagem CALL PROCEEDING pode ser enviada da redeao usuário indicando que a chamada foi iniciada. Através da mensagem SETUP, a rede aloca osrecursos necessários em função dos parâmetros contidos nos elementos de informação, descobreum caminho para o endereço do destino e monta as tabelas de VC [Black, 1995]. O usuáriochamado24 recebe a mensagem de SETUP e envia uma mensagem CALL PROCEEDING,indicando que a chamada está sendo processada. Em seguida, verifica os parâmetros doselementos de informação do SETUP e, se aceitar os valores25, acata o pedido de conexão. Paraisso, envia uma mensagem CONNECT com alguns parâmetros idênticos aos do SETUP, comos parâmetros AAL aceitos e outros parâmetros criados em função dos parâmetros recebidos namensagem SETUP. Com a mensagem CONNECT, a rede conclui a criação do circuito virtual.Após a recepção do CONNECT, a rede e o usuário enviam, cada um, uma mensagemCONNECT ACKNOWLEDGE para seus parceiros respectivos indicando que o circuito virtualestá estabelecido. Um valor do par VPI/VCI identifica localmente o circuito virtual. O valor deVPI/VCI é determinado pela rede26 e fornecido ao usuário chamador na mensagem CALLPROCEEDING ou CONNECT, e ao usuário chamado na mensagem SETUP.

Uma mensagem ALERTING pode ser enviada do usuário chamado ao usuário chamador parafornecer informações sobre o procedimento de estabelecimento de conexão através de um

23 Usuário que inicia o estabelecimento de conexão24 Usuário que recebe o pedido de conexão25 Alguns valores podem ser negociados dentro de certos limites e os novos valores são enviados dentroda mensagem CONNECT26 O usuário chamador pode sugerir o valor de VPI/VCI na mensagem SETUP através de um elementode informação

Protocol discriminator

0 0 0 0 � � � � � � � � �� � � � � � � � � � � � �Flag

Call reference value

Message type

Message length

Information elements

Information element identifier

1 Codingstandard

IE instruction field

Length of informationelements

Contents of informationelements

1 0 0 0 1 1 0 0

1 0 0 0 0 0 0 1

SCSS type identifier1 0 0 0 0 1 0 0

SCSS type

0 1 0 1 1 0 0 0

Subtype identifier0 0 0 0 0 1 0 1

AAL Parameters Information Element

AAL type 5

Q.2931 message

Backward Max. CPCSSDU Size

Forward Max. CPCSSDU Size

1

1

2

2

3

3

4

4

5

6

7

8

9

Figura 2.16 - Estrutura da Mensagem Q.2931

28

elemento de informação Notification Indicator.

O encerramento de uma conexão é feito através do envio de uma mensagem RELEASE,indicando a causa da desconexão. Outras informações podem ser transportadas em um elementode informação Notification Indicator. A rede e o usuário que recebem a mensagem enviam umamensagem RELEASE_COMPLETE como resposta.

A Figura 2.18 mostra uma solicitação de conexão rejeitada pelo usuário chamado. O usuáriochamador envia a mensagem SETUP, o usuário chamado recebe a mensagem mas rejeita a

User 1 Network 1 Network 2 User 2

SETUP

SETUP

SETUP

CALL_PROCEEDING

CALL_PROCEEDING

CONNECT

CONNECT

CONNECT

CONNECT_ACK

CONNECT_ACK

ALERTING

ALERTING

ALERTING

RELEASERELEASE

RELEASE

RELEASE_COMPLETE

RELEASE_COMPLETE

= mensagem opcional

Figura 2.17 - Estabelecimento e Encerramento de Conexão

User 1 Network 1 Network 2 User 2

SETUP

SETUP

SETUP

RELEASE_COMPLETERELEASE_COMPLETE

RELEASE_COMPLETE

Figura 2.18 - Estabelecimento de Conexão não Completada

29

conexão transmitindo uma mensagem RELEASE_COMPLETE com a causa da rejeição. Nessecaso, a mensagem RELEASE_COMPLETE tem significado global.

2.3.5 Diagrama de Estados do ProtocoloA Figura 2.19 mostra os estados, os temporizadores e as principais ações definidas no protocoloQ.2931 (conexões ponto-a-ponto) para o lado do usuário na interface [Nam, 1995].

Call Initiated null Call Present

Outgoing Call Proceeding

CALL DELIVERED

Call Received

Incoming Call Proceeding

Connect Request

Active

Release Request

Restar Request

Management

U11

U11

U0U0

U11

U0

U11

Setup.reqsend SETUPset T303

2nd timeout T303Release.ind

1st Timeout T303send SETUPset T303

recv SETUPSetup.ind

Release.respsend RELEASE_COMPLETE

recv ALERTINGreset T303proceeding.ind

recv CALL_PROCEEDINGreset T303proceeding.indset T310

Timeout T310send RELEASERelease.indset T308

Timeout T301send RELEASERelease.indset T308

recv CONNECTreset T310Setup.confsend CONNECT_ACK

Alerting.reqsend ALERTING

recv CONNECTreset T303Setup.confsend CONNECT_ACK

recv CONNECTreset T301Setup.confsend CONNECT_ACK

Proceeding.reqsend CALL_PROCEEDING

Alerting.reqsend ALERTING

Setup.respsend CONNECTset T313

Setup.respsend CONNECTset T313

Setup.respsend CONNECTset T313

recv CONNECT_ACKreset T313Setup_complete.ind

Timetout T313send RELEASERelease.indset T308

release.reqsend RELEASEset T308

1st Timeout T308send RELEASEset T308

2nd Timeout T308send RESTARTset T316

1st and 2nd Timeout T316send RESTARTset T316

3rd Timeout T316

recv RELEASE_COMPLETE or RELEASEreset T308Release.conf

recv RESTART_ACK

Release.reqsend RELEASE_COMPLETE

recv RELEASE_COMPLETEreset T303Release.conf

U1

U3 U4

U9

U10

U6

U7

U8

ReleaseIndication

recv RELEASEreset all timersRelease.ind

U12

U0

Release.respsend RELEASE_COMPLETE

Figura 2.19 - Diagrama de Estados do Protocolo Q.2931

30

2.4 Gerenciamento SNMP ( Simple Network ManagementProtocol)

2.4.1 Arquitetura de Gerenciamento

Os modelos de gerenciamento de redes de computadores seguem, de uma forma geral, umaarquitetura chamada gerente-agente. Nesta arquitetura existem quatro elementos básicos[Stallings, 1993]:

• Gerente

• Agente

• Base de Informações Gerenciais

• Protocolo de Gerenciamento

A Figura 2.20 mostra como esses elementos se relacionam.

O gerente faz a interface entre a pessoa gerente (ou operador) e o sistema de gerenciamento,coletando informações dos recursos gerenciados, monitorando e controlando os recursosgerenciados através de intervenção manual ou automática.

O agente atende pedidos de informação e pedidos de atuação sobre os recursos gerenciados. Oagente pode informar ao gerente sobre eventos importantes sem solicitação do gerente.

Os recursos da rede que são gerenciados são representados como objetos. Cada objeto érepresentado por uma variável. A coleção desses objetos (representado pelas variáveis) constituia Base de Informações Gerenciais (Management Information Base - MIB). Como exemplo, umrecurso como um roteador pode ser representado na MIB por diversos objetos, representadospor variáveis, e pode ser monitorado e controlado através destas variáveis. O gerente executa amonitoração solicitando os valores das variáveis e comanda uma ação no recurso através doagente alterando valores de variáveis. O agente obtém as informações no recurso gerenciadopara colocar na variável e enviar ao gerente, ou atua no recurso gerenciado de acordo com ovalor determinado em uma variável recebida.

Um recurso pode ser um dispositivo físico, um programa, um sistema, ou qualquer coisa quepossa ser gerenciada.

Os gerentes e agentes se comunicam através de um protocolo de gerenciamento. O protocoloespecifica a sintaxe e a semântica das PDUs trocadas entre agente e gerente.

AgentManager

ManagedDevice

MIB

ManagementProtocol

Figura 2.20 - Elementos Básicos de Gerenciamento

31

O padrão SNMP (Simple Network Management Protocol) padroniza o protocolo degerenciamento [RFC1157, 1991], a Base de Informações Gerenciais [RFC1213, 1991], e aforma como a MIB é definida [RFC 1155, 1990].

2.4.2 O Protocolo SNMPO protocolo de gerenciamento SNMP define duas formas de comunicação entre gerente e agente(Figura 2.21): uma forma síncrona com pedidos e respostas (Request/Response); e uma formaassíncrona com a notificação de eventos (Notification) [RFC1215, 1991].

O gerente pode monitorar os objetos utili zando a forma síncrona, através do mecanismo devarredura, quando o gerente envia uma pedido (Request) e recebe uma resposta (Response). Oupode monitorar usando a forma assíncrona, através do mecanismo de notificação, quando oagente ao detectar um evento importante envia uma notificação (Notification) ao gerente. Se nãofor usado de maneira adequada, o esquema de varredura pode gerar alto tráfego na rede.

O SNMP define quatro operações básicas para implementar as duas formas de comunicaçãoentre gerente e agente que são SET, GET-NEXT, SET e TRAP [RFC1157, 1990]. Estasoperações estão descritas na Tabela 2.6.

Manager

Manager

Agent

Agent

MIB

MIB

Response

Notification

Request

(a) Synchronous

(b) Asynchronous

Figura 2.21 - Formas de Comunicação entre Gerente e Agente

32

A monitoração dos objetos gerenciados por varredura é feita através das operações GET eGET-NEXT. A monitoração por notificação é feita através da operação TRAP. O controle dosobjetos gerenciados é feito através da operação SET.

Para implementar estas operações, cinco tipos de PDUs são padronizadas no SNMP:GetRequest, GetNextRequest, SetRequest, GetResponse, e Trap. A Figura 2.22 mostra comocada operação SNMP utiliza estas PDUs.

As PDUs SNMP são encapsuladas em uma mensagem SNMP que contém a versão do SNMP,o nome da comunidade, e a PDU. O nome da comunidade funciona como uma senha, somente ogerente e agente que tem o mesmo nome de comunidade podem se comunicar. O formato damensagem e as PDUs SNMP são mostrados na Figura 2.23.

Operação Descrição Forma de comunicação

GET pede valor de variáveis Request/Response

GET-NEXT pede valor de variáveisem sequência

Request/Response

SET atribui valor às variáveis Request/Response

TRAP informa evento e valor dasvariáveis relacionadascom o evento

Notification

Tabela 2.6 - Operações SNMP

AgentManager

Trap

AgentManager

SetRequest

GetResponse

SET

AgentManager

GetRequest

GetResponse

GET

AgentManager

GetNextRequest

GetResponse

GET-NEXT TRAP

time

Figura 2.22 - PDUs SNMP

33

O formato das mensagens e PDUs são definidos em ASN.127 em [RFC1157, 1990] ecodificadas em uma cadeia de octetos utilizando codificação BER28 [Stallings, 1993].

A MIB é um banco de dados que pode ser alterado em função das informações obtidas dodispositivo gerenciado ou de comandos gerados pelo gerente e cada agente mantém sua instânciada MIB relacionada com os recursos que gerencia. A MIB definida em [RFC1213, 1991] édenominada MIB-II , e é uma revisão da MIB original. A MIB-II contém um conjunto básico devariáveis utili zadas no gerenciamento de redes TCP/IP. Cada objeto da MIB tem umidentificador que é único e utili zado nas operações SNMP para acesso às variáveis. Esseidentificador é um tipo OBJECT IDENTIFIER, definido em ASN.1, que designa um objetonomeado de forma autorizada. Os objetos definidos têm uma estrutura de árvore, onde a raiz é oobjeto “Norma ASN.1” [Stalli ngs, 1993]. Cada nó da árvore recebe um número inteiro quecomeça em 1 em cada nível da árvore. O valor OBJECT IDENTIFIER é uma seqüência deinteiros separados por pontos, que percorre uma árvore até um nó e identifica o nó. Logo abaixoda raiz da árvore estão os objetos que identificam as organizações de padronização: iso, ccitt ejoint-iso-ccitt. Debaixo do nó iso existe um nó para as outras organizações (org) e debaixo delaestão, entre outras, o US Department of Defense (DOD), no nó dod. Debaixo do nó dod está onó internet que contém os objetos da rede Internet. Entre os objetos da rede Internet estão osobjetos de gerenciamento no nó mgmt. Os grupos de objetos da MIB-II estão debaixo da sub-árvore do nó mgmt. A Figura 2.24 mostra um pedaço dessa árvore com os grupos de objetos daMIB-II.

27 Abstract Syntax Notation28 Basic Encoding Rules

PDU type request-id

PDU type request-id

PDU type enterprise

0 0

error-status error-index

agent-addr generic-trap specific-trap

variable-bindings

variable-bindings

variable-bindings

version community SNMP PDU

SNMP message

GetRequest, GetNextRequest, SetRequest PDU

GetResponse PDU

Trap PDU

Figura 2.23 - Formato da Mensagem e das PDUs SNMP

34

Como exemplo de identificador, o grupo de objetos do protocolo ICMP29 tem um OBJECTIDENTIFIER icmp cujo valor é 1.3.6.1.2.1.5. No grupo experimental podem ser colocadosnovos objetos ainda não definidos na MIB.

A definição formal das variáveis que representam os objetos gerenciados na MIB é feita atravésde um subconjunto da linguagem ASN.1, denominado SMI (Structure of ManagementInformation30) [RFC1155, 1990]. As variáveis definidas em ASN.1 são codificadas em umacadeia de octetos utili zando a codificação BER (Basic Encoding Rules31) [Stalli ngs, 1993]. ASMI permite a definição de variáveis atômicas ou tabelas com variáveis atômicas na MIB. Noentanto, nas tabelas o acesso é feito às variáveis atômicas que são seus componentes, não sendopossível recuperar ou alterar de uma vez uma tabela inteira ou parte dela.

As variáveis são definidas através de uma macro ASN.1 OBJECT-TYPE definida na RFC1155.No exemplo abaixo é reproduzida a definição de uma variável da MIB-II que conta o número demensagens ICMP recebidas:

icmpInMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of ICMP messages which the entity received. Note that this counter includes all those counted by icmpInErrors."::= { icmp 1 }

29 Internet Control Message Protocol30 Estrutura de gerenciamento de informação31 Regras básicas de codificação

iso (1)org (3)

dod (6)

internet (1)

directory (1)

mgmt (2)

private (4)

enterprises (1)

experimental (3)

mib-2 (1)

system (1)interfaces (2)at (3)

udp (7)

ip (4)

egp (8)

tcp (6)

snmp (11)

icmp (5)

transmission (10)

Figura 2.24 - Grupos de Objetos da MIB-2

35

O identificador do objeto icmpInMsgs tem identificador 1.3.6.1.2.1.5.1 porque está na sub-árvore icmp.

2.4.3 Protocolo SNMPv2O SNMP é um protocolo simples e fácil de implementar, mas apresenta algumas deficiênciasque limitam sua utili zação. As principais deficiências são a falta de mecanismos de segurança ea impossibilidade de distribuir o gerenciamento.

A versão dois do SNMP, denominada SNMPv2, tentou suprir essas deficiências. As melhoriasincluídas originalmente podem ser classificadas em quatro categorias:

• Estrutura de Gerenciamento de Informação (SMI)

• Operações do protocolo

• Interações gerente-gerente

• Segurança

A nova Estrutura de Gerenciamento da Informação (SMIv2) é baseada na SMI SNMP epermite uma definição mais elaborada e melhor documentada dos objetos da MIB, além deacrescentar facili dades para manipulação de tabelas [RFC1902, 1996]. Uma nova macroNOTIFICATION-TYPE foi criada para definir as notificações usadas nas PDUs Trap eInformRequest. Foi criado também o conceito de módulo de informação definido através damacro ASN.1 MODULE-IDENTITY que agrupa definições relacionadas. Novos módulos deinformação podem ser criados sob o nó experimental.

O SNMPv2 permite também a comunicação gerente-gerente na forma síncrona pedido/resposta(Request/Response), possibili tando a distribuição do gerenciamento pela rede (Figura 2.25). Ogerente nesse caso tem duplo papel. Quando envia um Request está atuando no papel de gerentee quando responde ao Request está atuando no papel de agente. Conceitualmente, o gerente nãotem informações para serem gerenciadas, logo não existem variáveis em uma MIB quecontenham informações de gerenciamento do gerente. As informações de gerenciamento dogerente estão associadas ao seu papel de agente, e a MIB gerente-gerente é a base dasinformações gerenciais do gerente quando desempenha o papel de agente.

Para fornecer os meios para coordenação entre estações de gerenciamento, foi definido ummódulo de MIB gerente-gerente (snmpM2M) [RFC1451, 1993]. Este módulo permite umaestação de gerenciamento solicitar serviços à outra estação de gerenciamento utili zando uma

Manager Manager MIBMIB

Response

Request

Figura 2.25 - Comunicação Gerente-Gerente no SNMPv2

36

operação definida no protocolo para comunicação entre gerentes. Entretanto, este módulo nãotem sido usado nas implementações do SNMPv2 [Rose, 1996].

As operações do SNMPv2 são uma extensão do SNMP. Basicamente, duas operações foramacrescentadas: GET-BULK e INFORM. A Tabela 2.7 mostra todas as operações SNMPv2[RFC1905, 1996].

A operação GET-BULK é semelhante à operação GET-NEXT mas permite a transferência degrande quantidade de informações de uma vez. A operação INFORM permite a transferência deinformações entre gerentes. Para implementar estas operações, sete tipos de PDUs sãopadronizadas no SNMPv2: GetRequest, GetNextRequest, GetBulkRequest, SetRequest,

Operação Descrição Forma de comunicação Tipo de acesso

GET pede valores de variáveis Request/Response Gerente-Agente

GET-NEXT pede valores de variáveisem sequência

Request/Response Gerente-Agente

GET-BULK pede valores de umconjunto de variáveis

Request/Response Gerente-Agente

SET atribui valor às variáveis Request/Response Gerente-Agente

INFORM pede valores de variáveis Request/Response Gerente-Gerente

TRAP informa evento e valor dasvariáveis relacionadascom o evento

Notification Agente-Gerente

Tabela 2.7 - Operações SNMPv2

Agent ManagerManager Manager

GetBulkRequest

Response

InformRequest

Response

GET-BULK INFORM

Agent AgentManager Manager

SetRequest

Response

GetRequest

Response

SET GET

Agent

Agent

Manager

Manager

GetNextRequest

Response

SNMPv2-Trap

GET-NEXT

TRAP

time

Figura 2.26 - PDUs SNMPv2

37

InformRequest, Response, e SNMPv2-Trap. A Figura 2.26 mostra como cada operaçãoSNMPv2 utiliza estas PDUs.

Como no SNMP, as PDUs SNMPv2 são encapsuladas em uma mensagem. Originalmente amensagem incluía campos para autenticação e criptografia. Entretanto, como a estratégia paraincluir segurança no SNMP não se mostrou adequada na prática, e foi abandonada [Rose,1996], o protocolo adotou o formato da mensagem do SNMP [RFC1901, 1996]. Com exceçãodo Trap, as PDUs do SNMP ficaram com o mesmo formato. A PDU do Trap foi substituídapor uma PDU com o mesmo formato das PDUs SetRequest, GetRequest, etc. Uma nova PDUfoi criada para a operação GET-BULK. O formato da mensagem e as PDUs SNMP sãomostrados na Figura 2.27.

Os mecanismos de segurança inicialmente incluídos no SNMPv2 incluíam o uso de criptografiapara proteger as PDUs e fazer autenticação do conteúdo, um módulo de MIB só para asinformações de segurança e um modelo administrativo mais complexo com visões de MIB,contextos de segurança, e política de controle de acesso. Atualmente outros mecanismos desegurança estão em estudo [RFC1910, 1996].

As implementações correntes do padrão SNMPv2 utili zam basicamente o SMIv2, e asoperações e PDUs.

2.4.4 Agente ProcuradorAlgumas vezes um agente precisa acessar informações de gerenciamento em um dispositivo quenão é local. Quando o agente recebe uma requisição sobre esta informação não local, e interagecom o dispositivo remoto para enviar ou receber informações de gerenciamento, o agente estáexecutando uma interação por procuração [Rose, 1996]. Esse tipo de agente é denominadoAgente Procurador (Figura 2.28).

PDU type request-id

PDU type request-id

request-idPDU type

0 0

error-status error-index

non-repeaters

max-repetitions

variable-bindings

variable-bindings

variable-bindings

variable-bindings

version community SNMPv2 PDU

SNMPv2 message

GetRequest, GetNextRequest, SetRequest, SNMPv2Trap, InformRequest PDU

Response PDU

GetBulkRequest PDU

name_nname_1 name_2 value_nvalue_1 value_2 . . .

Figura 2.27 - Formato da Mensagem e das PDUs SNMPv2

38

2.4.5 Agente InteligenteUm agente SNMP tradicional é uma entidade sem qualquer autonomia. A atuação desse tipo deagente se restringe a três tipos de ação: enviar ao gerente informação sobre eventos quando estessão gerados pelo dispositivo gerenciado; enviar ao gerente informações quando é requisitado; eatuar sobre o dispositivo gerenciado a partir de informações fornecidas pelo gerente através dasvariáveis da MIB.

O conceito de agente inteligente, no âmbito de gerenciamento de redes, implica em aumentar acapacidade de processamento do agente para aumentar sua autonomia e funcionalidade. Oagente inteligente pode operar sem ter necessariamente a interferência do gerente. Pode realizartarefas mais complexas que permitam fornecer informações em maior quantidade e/ou qualidadeao gerente e atuar sobre os recursos gerenciados com maior independência, controle e eficiência.

2.4.6 Transporte de Mensagens SNMPO transporte das mensagens SNMP/SNMPv2 não precisa ser feito através de um protocoloconfiável, podendo utili zar datagramas. O protocolo originalmente definido para transportar asmensagens foi o UDP32 [Stalli ngs, 1993]. Entretanto, outros protocolos de transporte estãoprevistos em [RFC1906, 1996]. O ATM Forum padronizou o uso de SNMP com o protocolo dacamada AAL5 e não existem restrições para que implementações específicas utili zem qualqueroutro tipo de protocolo de transporte.

32 User Datagram Protocol

Manager

Proxy Agent ManagedDeviceMIB

SNMP Response Response

SNMP Request Request

Figura 2.28 - Agente Procurador

39

Capítulo 3

Especificação Básica do Sistema deSegurança para Redes ATM

Este capítulo especifica os requisitos básicos do sistema de segurança para redes ATM.

3.1 Serviços de Segurança

Entre os serviços de segurança definidos pelo modelo OSI (Capítulo 1), os que podem serimplementados na camadas inferiores (enlace, rede ou transporte) são [Stallings, 1995]:

• Confidencialidade de dados

• Autenticação de origem

• Autenticação de destino

• • Integridade dos dados.

Os outros serviços, ou seja, controle de acesso e não-rejeição, não são adequados para ascamadas em questão. O serviço de não-rejeição exige o uso de uma autoridade notarialeletrônica. O serviço de controle de acesso é tipicamente um serviço de nível de aplicação. Suaaplicação ao nível de enlace ou de rede restringe o controle a toda máquina não se aplicando aosserviços e usuários específicos, como seria mais adequado.

A integridade do dados cifrados ou autenticados é garantida anexando-se aos dados um valor deuma função hash unidirecional (Capítulo 2) aplicada à informação original (não criptografada enão autenticada). Este é um procedimento simples que pode ser usado em todas as transmissões.Não foi usado nesse trabalho para permitir maior clareza nas operações descritas mas seu uso ésimples, causando apenas um acréscimo de dados e de processamento.

3.2 Mecanismos de Segurança

Diversos mecanismos podem ser utili zados. No entanto, o mecanismo mais confiável, prático eutili zado na maioria das implementações de serviços de segurança é a criptografia. Todos osserviços definidos podem ser implementados com criptografia. A segurança dos algoritmos decriptografia de boa qualidade depende do segredo da chave ou das chaves usadas na cifração.Por isso, o maior problema para a utili zação de criptografia é como distribuir as chaves deforma confiável e segura. Geralmente existem chaves específicas para proteger a comunicação,denominadas chaves de sessão, e que são trocadas a cada sessão. E existem chaves específicaspara distribuição segura de chaves de sessão (Capítulo 2). Os protocolos que definem osprocedimentos e funções utili zadas para distribuição segura de chaves são conhecidos comoprotocolos de distribuição de chaves.

Os serviços de autenticação e integridade devem ser implementados através de algoritmo dechave pública e o serviço de confidencialidade de dados deve ser implementado através de

40

algoritmo simétrico de bloco (Capítulo 2). O protocolo de distribuição de chaves provê chavesde sessão de forma segura para o algoritmo simétrico e garante a autenticação.

3.3 Algoritmos

Entre os diversos algoritmos de chave pública, o mais conhecido, utili zado e implementado é oRSA. Existem bibliotecas de programas de domínio público disponíveis com este algoritmo emuitas implementações confiáveis o utili zam. É bastante seguro se as chaves tiverem o tamanhoadequado, que atualmente é recomendado 2048 bits [Schneier, 1996]. A maioria dos protocolosde distribuição de chaves pode ser implementada com o RSA.

Entre os diversos algoritmos simétricos, o IDEA (International Data Encription Standard) é umdos mais conhecidos e é um dos algoritmos padronizados que oferece maior segurança. Cifrablocos de 64 bits e existem bibliotecas de domínio público disponíveis com este algoritmo emuitas implementações confiáveis o utilizam.

3.4 Gerenciamento de Segurança

A função mais importante do gerenciamento de segurança de sistemas baseados em criptografiaé a distribuição de chaves. Outra função importante é a notificação de eventos relativos àstentativas de quebra de segurança. A arquitetura proposta deve resolver o problema principal degerenciamento de chaves. A função de notificação não será definida mas a arquitetura deveprover meios que permitam sua inclusão sem alterações importantes.

3.5 Visão Geral da Segurança

O sistema de segurança é constituído pelos componentes de software e hardware doscomputadores que fornecem os serviços de segurança e fazem o gerenciamento da segurança. Ogerenciamento da segurança cuida da distribuição segura de chaves, ou seja, gerenciamento dechaves. Os serviços de autenticação e o gerenciamento de chaves são providos através doprotocolo de distribuição de chaves. O serviço de confidencialidade dos dados é provido poruma camada de rede.

Os serviços de segurança objetivam a proteção da transmissão de dados, mas os serviços podemser estendidos para proteção de transmissão de voz e imagem com algumas adaptações.

Em qualquer rede existem diversas possibili dades de implementação da segurança, os serviçospodem ser colocados nas estações de usuários ou nos elementos de suporte à rede comoroteadores e pontes. O posicionamento desses componentes dentro da pilha de protocolos é outraquestão importante. De acordo com modelo OSI [ISO7498, 1989] os serviços podem serimplementados em diversas camadas. No entanto, o modelo ATM não segue rigidamente omodelo OSI de sete camadas, e o conceito de encapsulamento de protocolos também dificultaesta decisão.

Dentro do ambiente de rede ATM existem várias possibili dades de colocação desses serviços desegurança nos elementos da rede. [Steveson et al., 1995] propõem um dispositivo de hardwaredenominado Crypto Unit. Este tipo de dispositivo é bastante complexo e de alto custo,envolvendo um grande esforço de desenvolvimento de hardware. É um equipamento da mesmaordem de complexidade de um comutador ATM e está fora do escopo desse trabalho.

[Chuang, 1995] faz uma análise sobre a colocação dos mecanismos de segurança em diferentesambientes de operação em redes ATM. Excluindo a possibili dade de implementação em

41

hardware, os serviços devem ser colocados na estação de trabalho do usuário. Este trabalhodefine uma forma de implementar os serviços de segurança e seu gerenciamento em software, naestação do usuário.

Como diversos protocolos podem operar sobre a pilha ATM, para que os serviços de segurançapossam ser utili zados por qualquer aplicação, esses serviços devem ser implementados nosprotocolos que constituem a pilha ATM.

3.6 Serviços de Segurança na Camada AAL5

A camada de adaptação tipo 5 é usada para o serviço de transmissão de dados (Capítulo 2).Esta camada é dividida em duas subcamadas: subcamada de convergência (CS) e subcamada desegmentação e remontagem (SAR). A subcamada de convergência é ainda subdividida em duas:parte comum da subcamada de convergência (CPCS) e subcamada de convergência específicade serviço (SSCS). Esta última tem a função de prover serviços específicos que não sãooferecidos pela camada AAL5 genérica. Um dos serviços que pode ser oferecido é o daconfidencialidade dos dados. Portanto, para a subcamada SSCS deve ser especificado umprotocolo para fornecer ao usuário da AAL5 o serviço proposto.

O serviço de confidencialidade de dados deve ser fornecido por um algoritmo simétrico de bloco,utili zando chave de sessão que deve ser trocada com freqüência, a cada nova conexão ou portempo. A escolha natural é o IDEA, cifrador de blocos de 64 bits. A chave de sessão para oIDEA tem 128 bits e deve ser obtida de forma segura através do protocolo de distribuição dechaves.

3.7 Visão Geral da Arquitetura

Na arquitetura proposta, a segurança será fim-a-fim, ou seja, o sistema de segurança de dadospara a arquitetura ATM deve prover serviço de confidencialidade dos dados e serviço deautenticação de origem e destino para estações de trabalho. O sistema deve ser transparentepara a rede e implementado nas estações dos usuários. Os serviços de segurança se destinam aproteção de dados e portanto são direcionados para serviços classe C e D, tráfego VBR e ABR[Black, 1995].

Um conjunto de componentes dessas estações deve ter a função de operacionalizar o protocolode distribuição de chaves, fornecendo chaves para operação do serviço de confidencialidade dedados e fornecendo o serviço de autenticação. O serviço de confidencialidade de dados deve serimplementado na camada AAL5.

Os protocolos de distribuição de chaves geralmente adotam o modelo cliente-servidor. Umaestação funciona como Servidor de Chaves e de Autenticação, fornecendo as chavescriptográficas necessárias à operação do sistema aos clientes, ao mesmo tempo que realiza aautenticação. Todas as estações se comunicam através de placas de rede ATM e comutadoresprivativos e/ou públicos que formam a rede ATM (Figura 3.1).

42

O sistema de segurança utili za apenas a infra-estrutura ATM e é transparente para asaplicações. Quaisquer aplicações, executando nas estações de trabalho, podem se comunicaratravés do sistema, mesmo que utili zem diferentes protocolos acima da pilha de camadas ATM.Os serviços de segurança são implementados apenas nas estações, de forma totalmenteindependente da rede ATM, utilizando apenas os protocolos da arquitetura ATM.

A arquitetura ATM tem as facili dades necessárias para a implementação da segurança semmudanças nos protocolos. Os protocolos oferecem mecanismos para o transporte das chaves e acamada de adaptação permite oferecer serviços específicos, como criptografia, na sub-camadaSSCS da camada AAL5, sem alterar a arquitetura padronizada.

As estações de trabalho operam no modo de segurança utili zando chaves criptográficasfornecidas pelas estações servidoras de chaves, operando em modo cliente-servidor. Antes deiniciar uma comunicação segura, uma estação deve solicitar, ao servidor, as chaves necessáriasà comunicação. Somente de posse das chaves a estação inicia a conexão com a outra estação,enviando as chaves necessárias ainda na fase de conexão.

O serviço do servidor de chaves pode ser distribuído pela rede em vários servidores de forma aevitar a sobrecarga de um único servidor em redes muito grandes e evitar a concentração detráfego e aumentar a confiabilidade.

O sistema é especificado para operação em redes ATM que utili zam circuitos virtuaiscomutados (SVC) e conexões ponto-a-ponto1, mas pode ser adaptado para redes que utili zamcircuitos virtuais permanentes (PVC) com algumas simplificações.

A comunicação segura tem duas fases de operação: distribuição de chaves e comunicaçãocifrada. Na primeira fase (passos 1, 2, 3 e 4 da Figura 3.2), a estação que inicia a comunicação

1 A maioria das aplicações que demandam serviços de segurança operam ponto-a-ponto.

Servidor de chaves

Estaçãode

Trabalho

Estaçãode

Trabalho

Estaçãode

Trabalho

Estaçãode

Trabalho

Estaçãode

Trabalho

Estaçãode

Trabalho

Rede ATM

Estaçãode

Trabalho

Figura 3.1 - Rede ATM Com Servidores de Chaves

43

(estação origem), a estação destino e a estação servidora devem interagir para distribuir aschaves. Na segunda fase (passos 5 e 6 da Figura 3.2), apenas a estação origem e a estaçãodestino interagem transferindo dados cifrados.

A Figura 3.3 mostra a pilha de protocolos ATM destacando as camadas que participam deforma ativa no provimento dos serviços de segurança.

Além das camadas de protocolos, dois componentes são básicos para o sistema de segurança: aaplicação que implementa o Servidor de Chaves e de Autenticação; e o processo Gerenciador deSegurança Local que faz o gerenciamento local de chaves.

Estaçãode

Trabalho

Servidor de chaves

Estaçãode

Trabalho

1

2

3

4

5

6

Figura 3.2 - Fases da Comunicação Segura

� � � � � � � � � �� � � � � � � �

! " !

! # $! $ !

% &% ' (

$ ) * + ! % ,

AAL5

Aplications

Higher Layers

Figura 3.3 - Camadas ATM que Participam do Sistema de Segurança

44

Capítulo 4

Protocolo para Distr ibuição de ChavesCr iptográficas em Grandes Redes deComputadores

4.1 Introdução

A qualidade de serviços de segurança em redes de computadores, que utili zam criptografia,depende basicamente da resistência do algoritmo criptográfico à criptoanálise e do procedimentoutili zado para distribuição das chaves. Para um algoritmo resistente, a segurança depende dosegredo da chave. Em grandes redes de computadores, para viabili zar o uso de criptografia, aschaves precisam ser distribuídas para os diversos nós de forma automática e segura, e depreferência através da própria rede. Por isso, uma das funções mais importantes dogerenciamento de segurança em redes de computadores é o gerenciamento de chaves, que cuidade sua geração e distribuição pela rede.

Existem diversos protocolos para distribuição de chaves, mas nenhum pode ser consideradoadequado a todas as aplicações, e capaz de resolver todos os problemas. Cada um apresentavantagens e desvantagens e de uma forma geral os protocolos que são mais seguros são tambémmais complexos.

Um protocolo de distribuição de chaves para ser adequado ao uso em redes de computadoresdeve ter algumas características básicas. Deve ter um número reduzido de interações entre osnós e deve minimizar o número de nós envolvidos na distribuição, de forma a reduzir o tráfegona rede. Deve também permitir a distribuição do serviço pela rede para evitar a criação degargalos de comunicação. Além disso, o protocolo deve prover autenticação de origem e destino.

O protocolo proposto neste trabalho tem estas características e seu objetivo básico é permitirum serviço de distribuição segura de chaves através de redes de computadores, distribuindo esteserviço entre servidores de chaves espalhados pela rede, de forma a possibili tar a operaçãoconfiável do serviço de confidencialidade de dados e prover serviço de autenticação de origem edestino. Em relação a outros protocolos, o protocolo apresenta algumas vantagens: adistribuição de chaves públicas é automática, através da rede e só exige um procedimentomanual, o de verificação das chaves publicadas; a geração de chaves é centralizada semcomprometer a confidencialidade em relação ao gerador da chave; e o serviço de distribuição dechaves pode ser distribuído pela rede sem comprometer a segurança.

4.2 Abreviaturas, Notação e Terminologia

Relação de abreviaturas usadas neste trabalho:

AKS = “Authentication and Key Server” (Servidor de Autenticação e de Chaves) =Servidor de Chaves

Ksi = chave de sessão inicial (algoritmo simétrico)

45

Ks = chave de sessão efetiva (algoritmo simétrico)

Kmi = chave mestra inicial (algoritmo simétrico)

Km = chave mestra efetiva (algoritmo simétrico)

PX = chave pública (algoritmo assimétrico) do nó X (ex.: PK = chave pública do AKS)

SX = chave secreta (algoritmo assimétrico) do nó X (ex.: SK = chave secreta do AKS)

{Px, Sx} = par de chaves do nó X (chave pública e chave secreta)

T = marca de tempo

IDX = identificador do nó X (ex.: IDK = identificador do AKS)

IV = vetor de inicialização do algoritmo simétrico

A cifração e decifração com algoritmos de chave pública são descritas através da seguintenotação:

EPA(M) = cifração da mensagem M com a chave pública PA

DSA(C) = decifração do criptograma C com a chave secreta SA

ESK(M) = ASK(M) = cifração da mensagem M com a chave secreta SK = autenticação damensagem M com a chave secreta SK

DPB(C) = decifração do criptograma C com a chave pública PB = verificação daautenticidade (da origem) do criptograma C com a chave pública PB

A cifração e decifração com algoritmos simétricos são descritas através da seguinte notação:

EKs(M) = cifração da mensagem M com a chave de sessão Ks

DKs(C) = decifração do criptograma com chave de sessão Ks

Para ilustrar a notação utili zada, a autenticação de PB e T (concatenados) com a chave secretaSA é representada por

ASA(PB, T)

e a transmissão de ASA(PB, T) e EKs(M), de A para o AKS, é representada por

A - AKS : ASA(PB, T), EKs(M)

A aplicação de uma função hash unidirecional a uma mensagem M é representada por

H(M)

A seguinte terminologia é utilizada neste trabalho:

Servidor de Chaves ou simplesmente Servidor - simpli ficações da denominaçãoServidor de Autenticação e de Chaves (AKS).

Nó = computador conectado à rede

Nó usuár io - nó da rede que se comunica com outro nó usuário de forma segurautilizando as chaves fornecidas pelo AKS.

Nó origem - nó usuário que inicia uma comunicação segura.

Nó destino - nó com o qual o nó origem deseja se comunicar de forma segura.

Criptograma - resultado da cifração de uma mensagem.

Chave secreta - chave secreta do algoritmo de chave pública.

46

Chave pública - chave pública do algoritmo de chave pública.

Chave de sessão - chave secreta do algoritmo simétrico.

Chave mestra - uma chave secreta do algoritmo simétrico.

Confidencialidade dos dados - sigilo dos dados.

Autenticação de origem - garantia de que a origem informada dos dados é autêntica.

Autenticação de destino - garantia de que somente o nó ao qual se destinam os dadospode decifrar corretamente os dados.

Integr idade dos dados - garantia de que que os dados recebidos não foramintencionalmente alterados.

Ataque - interferência passiva ou ativa nos dados, não autorizada, entre as partes quese comunicam.

Ataque passivo - observação e análise não autorizada dos dados sem sua alteração esem alteração na disponibilidade do serviço.

Ataque ativo - modificação intencional e não autorizada dos dados ou dadisponibilidade do serviço.

Oponente - indivíduo ou organização que realiza ataque passivo ou ativo.

4.3 Descrição do Protocolo de Distribuição de Chaves

O protocolo proposto utili za algoritmo de chave pública para fazer a distribuição de chavessimétricas para comunicação e ao mesmo tempo fazer a autenticação de origem e destino. Achave simétrica distribuída é utili zada para prover confidencialidade dos dados através de umalgoritmo simétrico de bloco que opera em modo Cypher Block Chainning1 (CBC). O mesmoalgoritmo simétrico operando em modo Electronic Code Book2 (ECB) é utili zado para enviar ovetor de inicialização ou a chave de sessão no caso de hierarquia de chaves de dois níveis.

O protocolo proposto tem duas versões. A versão básica utili za hierarquia de chaves de doisníveis3 e a segunda versão utili za hierarquia de três níveis4. Para a descrição do protocolo,vamos considerar a rede como sendo constituída por dois nós usuários A e B, que devem secomunicar de forma segura, e um terceiro nó que centraliza e gerencia a distribuição de chavesde sessão para A e para B. Este terceiro nó funciona como um Servidor de Autenticação e deChaves (AKS) gerando e autenticando chaves secretas aleatórias. O procedimento paraqualquer número de nós é o mesmo que é descrito para dois nós. Os nós que podem secomunicar de forma segura devem estar relacionados no Servidor. Estes nós mais o Servidorconstituem uma rede segura..

O protocolo é dividido em duas partes: distribuição das chaves públicas, e distribuição dechaves simétricas secretas (chave mestra e/ou chave de sessão). A primeira parte é usada paradistribuir as chaves públicas que serão utili zadas para distribuir as chaves simétricas. Esteprotocolo é executado na inicialização da rede ou quando um novo usuário é adicionado, eequivale a “registrar” o nó no Servidor de Autenticação e Chaves. Deve ser usado tambémquando um dos nós tem sua chave secreta comprometida, para fazer a troca da chave pública. A

1 Encadeamento do bloco cifrado2 Livro de códigos eletrônico3 Chave pública para distribuir chaves de sessão4 Chave pública para distribuir chave mestra e chave mestra para distribuir chaves de sessão

47

segunda parte é usada para distribuição de chave mestra e/ou chave de sessão e paraautenticação de usuários e é executado sempre que for iniciada uma comunicação segura entreos usuários.

4.3.1 Distribuição das Chaves PúblicasOs protocolos apresentados na li teratura não tratam dos procedimentos preliminares dedistribuição de chaves iniciais (chaves mestras simétricas ou chaves públicas) que permitirão aposterior distribuição das chaves usadas para comunicação. Em redes pequenas estadistribuição inicial é simples mas pode se tornar complexa e trabalhosa em redes grandes.

No protocolo proposto, a maior parte deste procedimento preliminar é automática e consiste emgerar um “catálogo eletrônico” de chaves públicas em um nó Servidor de Chaves e distribuir achave pública do Servidor para os nós da rede. Apenas o procedimento de autenticação dessaschaves públicas é feito de forma manual e consiste na publicação dos valores de hash daschaves públicas e de sua verificação (Figura 4.1).

Inicialmente, o responsável pela administração da segurança do Servidor de Chaves e deAutenticação (Administrador de Segurança) coloca no AKS uma relação de todos os nós quefazem parte da rede segura. Em seguida, o AKS gera SK e PK e armazena SK de forma segura. Agera SA e PA, B gera SB e PB, e ambos armazenam suas chaves secretas de forma segura. Emseguida, A e B enviam suas chaves públicas para o Servidor junto com seus identificadores:

(1) A . AKS : IDA, PA

(1) B . AKS : IDB, PB

O AKS confere os identificadores, verifica se os nós pertencem à rede segura, armazena aschaves e então envia sua chave pública para A e para B:

(2) AKS . A : PK

(2) AKS . B : PK

O AKS e os nós A e B calculam os valores de uma função hash unidirecional, pré-definida econhecida por A, B e AKS, aplicada às chaves públicas local e remotas (H(PA) , H(PB) eH(PK)). Em seguida, o administrador de segurança publica { IDA, H(PA)} , { IDB, H(PB)} , { IDK,H(PK)} para verificação manual da autenticidade das chaves PA, PB e PK recebidas:

A B

AKS

IDa, Pa IDb, Pb

PkPk

IDk,H(Pk1),

IDa, H(Pa),

IDb, H(Pb)

(1)

(2)

(1)

(2)

(3)

Figura 4.1 - Distribuição de Chaves Públicas

48

(3) AKS publica IDA, H(PA), IDB, H(PB), IDK, H(PK)

A publicação dos valores da função hash das chaves públicas pelo AKS permite, aoadministrador local de A e ao administrador local de B, a verificação manual da autenticidadedas chaves PA e PB, recebidas pelo AKS. Permite verificar também a autenticidade da chave PK

enviada pelo AKS e recebida por A e por B. Ou seja, A e B, os usuários do serviço do AKS, aoverificarem os valores de hash publicados, estão conferindo a autenticidade das chaves contidasno AKS. O único procedimento manual é a conferência dos valores, que é feito de formaindependente pelo administrador de cada nó da rede. A publicação deve ser feita de forma ainviabili zar qualquer tentativa de fraude e é fundamental que todos os administradores locaisverifiquem, cada um, o seu identificador e valor de hash publicados. Este procedimento deve terum prazo máximo pré-determinado, a partir do qual o Servidor libera a operação dos nós. Apublicação dos valores pode ser feita de forma simples, de baixo custo e eficiente através deanúncio classificado em jornal de grande circulação.

O uso de uma função hash tem por objetivo facili tar a verificação manual já que o resultado dohash é bem menor do que a chave pública. Esta função deve ter as propriedades necessáriaspara autenticação de mensagens [Stalli ngs, 1995] que são a unidirecionalidade e oespalhamento. Somente depois de um período pré-estabelecido o Servidor libera o uso daschaves recebidas.

A verificação de autenticidade automática não é possível porque através de um ataque ativo umoponente pode interceptar toda a comunicação entre um nó usuário e o Servidor e falsificarchaves públicas de forma a enganar tanto o nó quanto o Servidor.

As ações de A e de B, descritas anteriormente, podem ser executadas em qualquer ordem e nãoprecisam ser feitas simultaneamente por todos os nós da rede. Nem a publicação dos valores dehash têm que ser feita para todas as chaves ao mesmo tempo. Cada nó pode gerar e enviar suachave para o Servidor e receber PK de forma independente dos outros nós. O AKS deve publicaro valor de hash a cada chave recebida (junto com o valor do hash de PK). Cada nó pode iniciaruma comunicação segura com um nó já registrado assim que fizer o seu registro. A geração daschaves públicas e secretas de forma aleatória pode ser feita por algum procedimento análogo aoque é usado no programa de segurança PGP [Stalli ngs, 1995] que utili za o tempo médio entreacionamento das teclas como semente para geração das chaves. Isto é possível porque esteprocedimento é executado com muito pouca freqüência.

Após este procedimento inicial, o Servidor tem em sua tabela de chaves as chaves públicas dosusuários da rede, autenticadas pelos próprios usuários através da verificação dos valores dehash publicados.

4.3.2 Distribuição de Chave de Sessão e Autenticação (Hierarquia deDois Níveis)

Entre os diversos protocolos publicados podemos destacar o protocolo de Denning e Sacco[Denning e Sacco, 1981] como um dos mais adequados para uso em redes de computadores. Oscritérios para seleção deste protocolo entre diversos protocolos publicados que apresentam ascaracterísticas desejadas para utili zação em redes, foram: segurança, pequeno número deinterações e máxima automatização da distribuição de chaves (menor quantidade deprocedimentos manuais). Tanto o protocolo de Denning e Sacco quanto o conhecido protocoloKerberos são variantes do protocolo de Needham e Schroeder [Needham e Schroeder, 1978][Schneier, 1996]. A desvantagem do Kerberos é que, devido à utili zação de algoritmossimétricos para distribuição das chaves de sessão, a distribuição inicial de chaves não pode serautomatizada com segurança. Para ser absolutamente confiável, é necessário que a distribuiçãode chaves mestras seja feita manualmente em toda a rede. O protocolo apresentado neste

49

trabalho exige apenas a verificação manual das chaves públicas, sendo todo o restante doprocesso feito através da própria rede, de forma automática.

Esta segunda parte do protocolo proposto é baseada no protocolo de Denning e Sacco com umamodificação sugerida por Schneier [Schneier, 1996] e outras modificações para torná-lo maiseficiente para uso em redes grandes de computadores.

O protocolo proposto por Denning e Sacco, descrito a seguir, é uma modificação do protocolode Needham e Schroeder [Needham e Schroeder, 1978]:

A / AKS : IDA, IDB

AKS / A : ASK(IDA, PA, T), ASK(IDB, PB, T)

A / B : EPB(ASA(Ks, T)), ASK(IDA, PA, T), ASK(IDB, PB, T)

O AKS fornece as chaves públicas de A e de B junto com uma marca de tempo T, e a chave desessão Ks é gerada por A. Um problema com este protocolo é que A pode se disfarçar de B parafalar com um terceiro nó C [Schneier, 1996]. Schneier propôs uma alteração para resolver esseproblema, enviando os identificadores IDA e IDB junto com a chave Ks:

A / AKS : IDA, IDB

AKS / A : ASK(IDA, PA, T), ASK(IDB, PB, T)

A / B : EPB(ASA(IDA, IDB, Ks, T)), ASK(IDA, PA, T), ASK(IDB, PB, T)

A geração aleatória da chave de sessão é feita por pelo nó origem (A) e isto não é adequado emmuitas situações. A geração de chaves com características aleatórias [Knuth, 1981] de formaprática e eficiente deve ser feita por algum dispositivo especial de hardware que não existe paraqualquer plataforma. Portanto, a geração deve ser centralizada no Servidor.

Entretanto, a centralização cria um problema que pode não ser aceitável em certas aplicações: achave de sessão que será usada apenas por A e B é conhecida também pelo AKS. O protocolofoi então modificado para permitir a geração da chave de sessão pelo AKS e ainda garantir osegredo dos dados transmitidos entre A e B, inclusive para o AKS, e também permitir a suadistribuição mais segura. Além de garantir a distribuição segura, se uma chave de sessão forcomprometida de alguma outra forma, o protocolo modificado impede que, através de ataqueativo, um oponente force a reutili zação da chave comprometida. Ao mesmo tempo, esteprotocolo autentica A e B.

Na descrição a seguir, A é o nó que vai iniciar a comunicação segura com o nó B. Para que umachave de sessão compartilhada por A e por B seja distribuída, são necessários três passos(Figura 4.2).

50

Inicialmente, A envia seu identificador e o identificador de B para o AKS, solicitando osparâmetros a serem usados por A e por B:

(1) A 0 AKS : IDA, IDB

O AKS gera aleatoriamente uma chave de sessão inicial Ksi. Produz uma marca de tempo Tindicando quando a chave foi gerada. Cifra Ksi e T com PA e PB garantindo que só A e B vãoobter Ksi. Em seguida, envia Ksi cifrado junto com as chaves públicas e com os identificadoresde A e de B, autenticando tudo com SK.

(2) AKS 0 A : ASK(IDA, PA, IDB, PB, EPA(Ksi, T), EPB(Ksi, T))

ASK(IDA, PA, IDB, PB, EPA(Ksi, T), EPB(Ksi, T)) é denominado ticket de autenticação (TKT) ousimplesmente Ticket.

A decifra o Ticket e obtém os diversos parâmetros:

{ID A, PA, IDB, PB, EPA(Ksi, T), EPB(Ksi, T)} =

DPK(ASK(IDA, PA, IDB, PB, EPA(Ksi, T), EPB(Ksi, T)))

{Ksi, T} = D SA(EPA(Ksi, T))

Em seguida, verifica se IDA e IDB são os mesmos valores que foram enviados para o AKS.Verifica também o valor de T para garantir que as chaves não são repetidas5. Depois A gera achave de sessão efetiva cifrando Ksi com SA:

Ks = ESA(Ksi)

Este procedimento produz uma chave aleatória desconhecida também para o AKS já quesomente A tem a chave SA.

A gera, a partir do relógio interno da máquina, um vetor de inicialização IV para a operação doalgoritmo simétrico em modo Cypher Block Chainning. Depois cifra IV com a chave Ks,usando o algoritmo simétrico em modo Electronic Code Book, e cifra Ks com PB. A enviaentão, para B, Ks e IV cifrados, e o Ticket recebido do AKS:

5 Chaves repetidas tem marca de tempo T de valor menor que a marca de tempo corrente

AKS

A B

IDa, IDb

ASk(IDa, Pa, IDb, Pb, EPa(Ksi, T), EPb(Ksi, T))

ASk(IDa, Pa, IDb, Pb, EPa(Ksi, T),EPb(Ksi, T)),

EPb(Ks), EKs(IV)

(1)

(2)

(3)

Figura 4.2 - Distribuição de Chave de Sessão

51

(3) A 1 B : ASK(IDA, PA, IDB, PB, EPA(Ksi, T), EPB(Ksi, T)), EPB(Ks), EKs(IV)

B decifra os parâmetros recebidos e obtém Ks:

{ID A, PA, IDB, PB, EPA(Ksi, T), EPB(Ksi, T)} =

DPK(ASK(IDA, PA, IDB, PB, EPA(Ksi, T), EPB(Ksi, T)))

{Ksi, T} = D SB(EPB(Ksi, T))

Ks = DSB(EPB(Ks))

B verifica se Ks foi gerada por A, a partir de Ksi, comparando Ksi com DPA(Ks) (DPA(Ks) =DPA(ESA(Ksi) = Ksi).

As novidades do protocolo apresentado em relação ao protocolo de Denning e Sacco são acentralização da geração das chaves no Servidor e o mecanismo de modificação da chave desessão inicial Ksi gerada pelo Servidor em uma chave Ks desconhecida pelo Servidor.

O Servidor de Chaves e de Autenticação facili ta o estabelecimento de políticas de segurançacomo a seleção dos nós com os quais cada nó pode se comunicar de forma segura. OAdministrador de Segurança pode colocar esta informação no Servidor. Se o nó origem nãotiver permissão para se comunicar de forma segura com o nó destino, o AKS pode rejeitar opedido de chaves impossibili tando a comunicação segura. Este tipo de controle sobre a redesegura permite também que o Administrador de Segurança bloqueie o acesso a um nó que tevesua segurança comprometida.

4.3.3 Análise das Características de Segurança do ProtocoloAs características de segurança do protocolo são relacionadas e analisadas a seguir:

a) Este protocolo é fundamentado no fato de que as chaves públicas armazenadas no AKS sãoconsideradas confiáveis, já que seus valores de hash foram publicados e verificados por cadanó que participa da rede. Além disso, cada chave secreta SA, SB ou SK só é conhecida pelo nóque a gerou, ou seja, A, B e AKS, respectivamente.

b) A marca de tempo T indica quando a chave foi gerada e pode ser usada para controlar avalidade da chave de sessão. A chave Ks só vale até o tempo (T + ∆τ), onde ∆τ é o períodode validade da chave pré-determinado para a rede. A validade é controlada pelo nó origem eapós a expiração da validade, outra deve ser solicitada ao AKS por A.

c) A marca de tempo T pode ser usada também para impedir que Ticket enviado do AKS paraA e de A para B seja gravado e repetido posteriormente por um oponente, forçando areutili zação de uma chave de sessão gerada anteriormente [Neuman e Stubblebine, 1993].Como T cresce continuamente, o seu valor para uma nova chave tem sempre que ser maiorque o valor anterior.

d) O vetor de inicialização IV é gerado através de uma função time Para impedir que um ataqueativo force sua reutilização, basta ao nó B verificar se o novo valor é maior que o anterior.

e) A chave Ksi é fornecida para o serviço de confidencialidade. Se Ksi for usada para cifração,além de A e de B, o AKS também pode decifrar as mensagens transmitidas entre A e B.Para que a chave de sessão não seja conhecida pelo AKS, Ksi é transformada por A nachave de sessão efetiva Ks, através da cifração de Ksi com a chave secreta SA. Como Ks étransmitida para B cifrada com PB, somente B pode decifrar e recuperar Ks. Os outros nósnão podem recuperar Ks por que não conhecem SB. O Servidor conhece Ksi mas não podeobter Ks porque não conhece nem SA nem SB.

52

f) A recebe do AKS a chave PB e outros parâmetros, assinados com SK, garantindo aautenticidade da origem dos parâmetros. A decifração com PK e a verificação de IDA e IDB,garantem que foi o AKS que enviou as chaves. Por causa disso, PB não pode ser fraudado eA tem a garantia de que, cifrando qualquer informação com PB, somente B poderá decifrar eisto garante a autenticidade do receptor. Cifrando a chave de sessão Ks com PB, A temcerteza que somente B poderá decifrar e usar Ks, e portanto tudo que for cifrado com Ksserá decifrado apenas por B, garantindo a A a autenticidade do destino B.

g) A autenticação do destino é parcial porque A não tem certeza que B está realmenterecebendo. A tem certeza apenas que só B pode receber corretamente. A autenticação ficacompleta se B enviar de volta para A o valor de T cifrado com SB (ASB(T)). A calculaT=DPB(ASB(T)). Como só B tem SB, se o valor de T recebido por A for igual ao valortransmitido para B, ASB(T) só pode ter sido gerado por B e a autenticação fica completa(Figura 4.3).

h) B recebe de A o identificador IDA e chave PA, além de outros parâmetros, assinados com SK,o que garante a autenticidade da origem dos parâmetros. A decifração com PK e a verificaçãode IDA e IDB, garantem que foi o AKS que enviou as chaves. Por causa disso, PA não podeser fraudado e B tem a garantia de que tudo o que for cifrado (autenticado) com SA, edecifrado com PA, só pode ter vindo de A, o que garante a autenticidade do transmissor.

i) Ks é gerada assinando Ksi com SA. A chave Ksi enviada pelo AKS é cifrada com PB eassinada com SK, garantindo sua origem e segredo. Calculando Ksi = DPA(Ks) e verificandose este valor é igual ao valor de Ksi assinado pelo AKS, é possível ter certeza que a chaveKs foi gerada por A. Portanto, tudo o que for decifrado com Ks só pode ter vindo de A, oque garante a autenticidade da origem.

j) PA, PB e Ksi são assinados pelo AKS com SK, PK não pode ser falsificado já que o seu valorde hash foi publicado na distribuição inicial de chaves, logo tudo o que for assinado com SK

só pode ter sido gerado no AKS, que é considerado seguro.

AKS

A B

IDa, IDb

ASk(IDa, Pa, IDb, Pb, EPa(Ksi, T), EPb(Ksi, T))

ASk(IDa, Pa, IDb, Pb, EPa(Ksi, T), EPb(Ksi, T)),

EPb(Ks), EKs(IV)

(1)

(2)

(3)

ASb(T)

(4)

Figura 4.3 - Distribuição da Chave de Sessão com Autenticação Completa

53

k) { ASK(IDA, PA, IDB, PB, EPA(Ksi, T), EPB(Ksi, T))} contém dados que são usados apenas porA ou apenas por B mas permite a B obter as chaves que precisa de forma confiável(autenticadas pelo AKS) sem precisar se conectar ao AKS, economizando uma conexão.

l) A chave de sessão tem que ser aleatória e deve ser gerada preferencialmente por umdispositivo de hardware que utili ze um gerador de ruído natural. Esta é a melhor forma degerar bits aleatórios de forma rápida e automática [Schneier, 1996]. No entanto, IV nãoprecisa ser aleatório desde que nunca seja repetido . Para este propósito é adequado utili zar orelógio interno da máquina através de alguma função como time que retorna o número desegundos desde uma data pré-determinada. Para maior segurança é importante cifrar IV coma chave Ks utili zando um algoritmo cifrador de bloco no modo ECB. O conhecimento de IVnão compromete o sigilo mas o seu valor pode ser alterado para modificar bits selecionadosdentro do criptograma [Stallings, 1995].

m) Se os parâmetros forem alterados intencionalmente no caminho entre o nó origem e o nódestino, a segurança lógica não fica comprometida porque não é possível prever, semconhecer as chaves, o resultado da decifração de um parâmetro cifrado e alterado. Este tipode ataque pode interromper o serviço mas as mensagens recebidas são descartadas porquenão podem ser reconhecidas pelo destino.

n) A integridade dos parâmetros distribuídos pelo AKS e dos parâmetros enviados de A para B,pode ser garantida calculando o valor de hash das informações sem autenticação:

(2) AKS 2 A : ASK(IDA, PA, IDB, PB, EPA(Ksi, T), EPB(Ksi, T)),H(IDA, PA, IDB, PB, EPA(Ksi, T), EPB(Ksi, T))

(3) A 2 B : EPB(Ks), EKs(IV), ASK(IDA, PA, IDB, PB, EPA(Ksi, T), EPB(Ksi, T)),H(IDA, PA, IDB, PB, EPA(Ksi, T), EPB(Ksi, T))

4.3.4 Distribuição de Chave Mestra e Autenticação (Hierarquia deTrês Níveis)

Os algoritmos de chave pública exigem muito processamento e são de duas a três ordens degrandeza mais lentos que os algoritmos simétricos [Schneier, 1996]. Por isso, a distribuiçãofreqüente de chaves de sessão através de algoritmo assimétrico pode criar um retardo grande nacomunicação, devido ao tempo necessário para que os usuários processem a decifração. Oservidor de chaves também pode ficar sobrecarregado se receber muitas requisições de chavessimultaneamente. Para evitar isto, pode ser utili zada uma hierarquia de chaves de três níveis.Um algoritmo assimétrico é usado para distribuir uma chave mestra para um algoritmosimétrico (o mesmo usado para cifrar mensagens com a chave de sessão), utili zando oprocedimento já descrito anteriormente para chave de sessão (Figura 4.4).

54

Inicialmente, A envia seu identificador e o identificador de B para o AKS com uma indicaçãodo tipo de chave que está solicitando, neste caso a chave mestra (Master_Key_Request) e orestante do procedimento é idêntico ao de distribuição de chave de sessão:

(1) A 3 AKS : IDA, IDB, Master_Key_Request

(2) AKS 3 A : ASK(IDA, PA, IDB, PB, EPA(Kmi, T), EPB(Kmi, T))

A chave Km é gerada da mesma forma que Ks (Km = ESA(Kmi)), depois é cifrada com PB eenviada junto com o Ticket para B:

(3) A 3 B : ASK(IDA, PA, IDB, PB, EPA(Kmi, T), EPB(Kmi, T)), EPB(Km)

B completa a autenticação:

(4) B 3 A : ASB(T)

Depois da distribuição da chave mestra, a distribuição de chaves de sessão é feita utili zando achave mestra já distribuída (Figura 4.5).

AKS

A B

IDa, IDb, Master_Key_Request

ASk(IDa, Pa, IDb, Pb, EPa(Kmi, T), EPb(Kmi, T))

ASk(IDa, Pa, IDb, Pb, EPa(Kmi, T), EPb(Kmi, T)), EPb(Km)

(1)

(2)

(3)

(4)

ASb(T)

Figura 4.4 - Distribuição de Chave Mestra

55

A envia seu identificador e o identificador de B para o AKS com uma indicação do tipo dechave que está solicitando, neste caso a chave de sessão (Session_Key_Request):

(1) A 4 AKS : IDA, IDB, Session_Key_Request

O Servidor gera a chave de sessão inicial, cifra com a chave mestra já distribuída e envia paraA:

(2) AKS 4 A : EKmi(Ksi, T)

A gera Ks a partir de Ksi e envia para B:

Ks = ESA(Ksi)

(3) A 4 B : EKm(Ks), EKs(IV)

Para otimizar as requisições ao AKS, a primeira chave de sessão pode ser gerada e distribuídajunto com a chave mestra:

(1) A 4 AKS : IDA, IDB, Master_Key_Req

(2) AKS 4 A : ASK(IDA, PA, IDB, PB, EPA(Kmi, T), EPB(Kmi, T)), EKmi(Ksi, T)

(3) A 4 B : ASK(IDA, PA, IDB, PB, EPA(Kmi, T), EPB(Kmi, T)), EPB(Km), EKm(Ks),EKs(IV)

A validade de Km pode ser várias ordens de grandeza maior que a validade de Ks. Em redes quetrabalham com circuitos comutados, a distribuição da chave mestra pode ser feita na primeirasolicitação da conexão e mantida em uma tabela local de chaves. Em outras conexões, para omesmo destino, não é necessário requisitar nova chave mestra se a chave atual ainda estiverválida, bastando solicitar a chave de sessão. Cada conexão deve ter uma chave de sessão quepode ser trocada várias vezes, porque, utili zando a chave mestra, o tempo envolvido na troca épequeno e não deve afetar de modo significativo a transmissão de dados.

As características de segurança do protocolo com chave mestra não mudam em relação ao quejá foi analisado. A distribuição da chave mestra é igual ao procedimento de distribuição dechave de sessão analisado anteriormente. Quanto à distribuição da chave de sessão, como A tem

EKmi(Ksi, T)

AKS

A B

IDa, IDb, Session_Key_Request

EKm(Ks), EKs(IV)

(1)

(2)

(3)

Figura 4.5 - Distribuição de Chave de Sessão

56

certeza que Kmi foi gerado pelo AKS, decifrando { Ksi, T} com Kmi e verificando T, A temcerteza que Ksi foi gerado pelo AKS (autenticação da origem) e que não é repetido. Além disso,como somente A e B tem Km, quando A envia Ks para B, cifrado com Km, A tem certeza queapenas B pode decifrar a chave (autenticação do destino) e B tem certeza que apenas A podefazer a cifração (autenticação da origem). IV é gerado através de uma função time e, paraimpedir que um ataque ativo force sua reutili zação, basta ao nó B verificar se o novo valor émaior que o anterior. Como IV é cifrado com Ks, indiretamente este procedimento impedetambém um ataque para forçar a reutilização de Ks.

4.4 Ressincronização do Algoritmo

Após a distribuição de Ks, A e B tem a mesma chave de sessão para usar na transferência dedados, e usam o vetor de inicialização IV como primeiro bloco de encadeamento do cifrador debloco operando no modo CBC. No exemplo da Figura 4.6 as mensagens M1 e M2 podem sertrocadas entre A e B com sigilo (confidencialidade dos dados).

A 5 B : EKs(M1)

B 5 A : EKs(M2)

B decifra e obtém M1:

M1 = DKs(EKs(M1))

A decifra e obtém M2:

M2 = DKs(EKs(M2))

Erros na transmissão podem provocar a perda de sincronismo entre o cifrador na transmissão edecifrador na recepção. Um novo valor de IV deve ser transmitido periodicamente de A para Bpara ressincronizar o algoritmo. Como na distribuição de chave de sessão, o IV deve ser cifradopelo algoritmo de bloco no modo ECB, usando a chave Ks:

A 5 B : EKs(IV)

IV = DKs(EKs(IV))

4.5 Gerenciamento de Chaves Distribuído

O modelo com um Servidor centralizando todo o gerenciamento de chaves é adequado pararedes de pequeno porte. Mas em redes grandes esta configuração pode criar problemas decongestionamento nos canais de comunicação que chegam ao Servidor, além de dificultar apublicação e verificação das chaves públicas devido ao grande número de chaves envolvidas.

A B

EKs(M1)

EKs(M2)

EKs(IV)

Figura 4.6 - Cifração de Mensagens e Ressincronização do Algoritmo

57

Outro problema é o da confiabili dade já que, se o Servidor parar de funcionar, a rede seguratambém pára.

Para contornar este problema, o gerenciamento de chaves pode ser distribuído pela rede. Osprotocolos publicados não apresentam uma proposta satisfatória para permitir a distribuiçãodeste serviço. Needham e Schroeder prevêem esta possibili dade no seu protocolo mas cada nódeve ter a chave pública de todos os Servidores ou acessar um Servidor Central que tem aschaves de todos os outros Servidores. O protocolo proposto apresenta uma solução paradistribuição das chaves entre Servidores de domínios que permite otimizar os acessos entre nós eServidores e entre os Servidores para obtenção da chave pública desconhecida. Os nós sóprecisam conhecer a chave pública do Servidor de seu domínio o que simpli fica muito adistribuição e verificação inicial das chaves públicas.

O protocolo descrito anteriormente pode ser adaptado para permitir este tipo de operação emanter as mesmas características de segurança já mencionadas. Diversos Servidores locaisgerenciam, cada um, uma parte da rede, que constitui um domínio de um Servidor. Cada AKSdistribui as chaves públicas dos nós pertencentes ao seu domínio. Isto inclui os nós usuários e osnós que são servidores de chaves de outros domínios. Se um usuário solicita a chave pública deoutro usuário que está localizado em um domínio diferente, o AKS local se comunica com outroAKS para tentar obter a chave. Se este por sua vez também não tem a chave, tenta obtê-la comoutro AKS e assim por diante. Uma organização para os Servidores localizarem qual tem achave será apresentada mais adiante.

No exemplo a seguir os nós A e B pertencem ao domínio do AKS1, os nós C e D pertencem aodomínio do AKS2, e os nós E, AKS1 e AKS2 pertencem ao domínio do AKS3. AKS1 distribuias chaves dos nós A e B, AKS2 distribui as chaves dos nós C e D, e AKS3 distribui as chavesdos nós E, AKS1 e AKS2. O procedimento inicial garante a distribuição segura da chavepública de cada usuário, e também de cada AKS (Figura 4.7).

A BD

AKS1AKS2

AKS3

IDa, Pa

IDk1, Pk1

IDk2, Pk2

IDb, Pb

IDc, Pc

Pk3

Pk3

Pk2

Pk1

Pk1

IDe, H(Pe),IDk1, H(Pk1),IDk2, H(Pk2),IDk3, H(Pk3)

IDk1, H(Pk1), IDa, H(Pa),IDb, H(Pb)

IDk2, H(Pk2), IDc, H(Pc),IDd, H(Pd)

domain 2domain 1

domain 3

C

IDe, Pe

IDd, Pd

E

Pk3

Pk2(1)

(2)

(1)

(1)

(1)

(1)

(2)

(2)

(2)

(2)

(1)

(1)

(2)

(2)

(3)

(3)

(3)

Figura 4.7 - Distribuição das Chaves Públicas por Domínio

58

Inicialmente, cada administrador de segurança coloca no seu Servidor uma relação dos nós doseu domínio. Em seguida, cada Servidor gera suas chaves assimétricas e a armazena a chavesecreta de forma segura. Cada nó também gera suas chaves assimétricas e armazena a chavesecreta de forma segura. Depois cada nó envia sua chave pública para o Servidor de seudomínio, junto com seu identificador:

(1) A 6 AKS1 : IDA, PA

(1) B 6 AKS1 : IDB, PB

(1) C 6 AKS2 : IDC, PC

(1) D 6 AKS2 : IDD, PD

(1) E 6 AKS3 : IDE, PE

(1) AKS1 6 AKS3 : IDPK1, PK1

(1) AKS2 6 AKS3 : IDPK2, PK2

Cada AKS confere os identificadores e então envia, para cada nó do seu domínio, a sua chavepública:

(2) AKS1 6 A : PK1

(2) AKS1 6 B : PK1

(2) AKS2 6 C : PK2

(2) AKS2 6 D : PK2

(2) AKS3 6 E : PK3

(2) AKS3 6 AKS1 : PK3

(2) AKS3 6 AKS2 : PK3

Cada AKS publica o identificador e respectivo valor de hash da sua chave pública e da chavepública de cada nó de seu domínio, para que seja feita a verificação manual pelosadministradores de segurança do domínio:

(3) AKS1 publica IDA, H(PA), IDB, H(PB), IDK1, H(PK1)

(3) AKS2 publica IDC, H(PC), IDd, H(PD), IDK2, H(PK2)

(3) AKS3 publica IDK1, H(PK1), IDK2, H(PK2), IDK3, H(PK3), IDE, H(PE)

O procedimento para distribuição de chaves de sessão e autenticação é mais complexo nestecaso. No protocolo a seguir, A é o nó que vai iniciar a comunicação segura com o nó C. Os doisnós estão localizados em domínios diferentes, logo, para que uma chave de sessãocompartilhada por A e por C seja distribuída, são gastos mais passos do que seria necessário seambos estivessem no mesmo domínio. O AKS1 está no domínio do AKS3, e as chaves que nãosão conhecidas por AKS1 são solicitadas ao AKS3. Este por sua vez passa a solicitação aoAKS2. Esse procedimento é ilustrado na Figura 4.8.

59

Para A se comunicar de forma segura com C em outro domínio, A envia seu identificador e oidentificador de C para o AKS1, solicitando os parâmetros a serem usados por A e por C:

(1) A 7 AKS : IDA, IDC, Master_Key_Req

Como o AKS1 não tem a chave PC, este Servidor transmite IDK1 e IDC ao AKS3, seidentificando e solicitando a chave PC. AKS3 também não tem a chave, portanto é transmitidoIDK3, IDC e ASK3(PK1) ao AKS2 que finalmente localiza a chave PC em sua tabela de chaves.

(2) AKS1 7 AKS3 : IDK1, IDC

(3) AKS3 7 AKS2 : IDK3, IDC, ASK3(PK1)

(4) AKS2 7 AKS3 : ASK2(IDC, PC), ASK2(PK1)

(5) AKS3 7 AKS1 : ASK3(IDC, PC), ASK2(PK1)

O resto do protocolo é igual ao que foi descrito na seção 4.3.4:

(6) AKS1 7 A : ASK1(IDA, PA, IDC, PC, EPA(Kmi, T), EPC(Kmi, T)), ASK2(PK1)

(7) A 7 C : EPC(Km), ASK1(IDA, PA, IDC, PC, EPA(Kmi, T), EPC(Kmi, T)), ASK2(PK1)

(8) C 7 A : ASC(T)

Os parâmetros de segurança são fornecidos pelo AKS1 ao nó A e deste ao nó C, autenticadoscom SK1. PK1 só é conhecida pelos nós usuários localizados no domínio gerenciado por AKS1,portanto C não tem a chave PK1 e tem que recebe-la autenticada pelo AKS2 para poder decifraro Ticket (TKT) com certeza de sua origem. Por isso, PK1 tem que ser transmitida ao AKS2autenticada com a chave secreta de AKS3 para garantir sua autenticidade, e retornarautenticada pelo AKS2. O AKS2 tem a chave PC e autentica PK1 e { IDC, PC} com sua chavesecreta (SK2) e transmite tudo de volta. PK1 retorna até o AKS1, autenticada com SK2. { IDC, PC}são verificados pelo AKS3 quanto a sua autenticidade e novamente autenticados com a chave

A

AKS1

AKS3

AKS2

C

IDa, IDc,

Master_Key_Request

IDk1, IDc

ASk2(IDc, Pc),

ASk2(Pk1)

ASk3(IDc, Pc),

ASk2(Pk1)

TKT, ASk2(Pk1), EKmi(Ksi, T)

TKT, EPc(Km), EKm(Ks), EKs(IV), ESk2(Pk1)

TKT = ASk1(IDa, Pa, IDc, Pc, EPa(Kmi, T), EPc(Kmi, T))

domain 1

domain 2

(1)

(2)

(3)

(4)

(5)

(6)

(7)

IDk3, IDc,

ASk3(Pk1)

ASc(T)

(8)

Figura 4.8 - Servidores de Chaves Distribuídos

60

SK3 para o envio ao AKS1. Dessa forma, cada nó Servidor tem certeza que está recebendo umidentificador e chave autênticos.

Depois de receber ASK3(IDC, PC) e ASK2(PK1) do AKS3, o AKS1 transmite para A os parâmetrosde segurança junto com ASK2(PK1). A os retransmite para C permitindo que C verifique aautenticidade6.

Do ponto de vista do usuário A ou C, o Servidor de Chaves é centralizado. A comunicaçãoentre os AKS’s é transparente para A ou C. Tudo funciona como um AKS virtual que éconstituído pelos diversos Servidores de Chaves espalhados pela rede.

O gerenciamento das chaves pode ser organizado de forma hierárquica. Os nós Servidores e osnós usuários podem ser organizados em forma de árvore, onde os usuários são folhas e osgerentes são nós de grau maior que zero (Figura 4.9). Os nós da árvore correspondem aos nósda rede que participam do gerenciamento de segurança. Os usuários que são nós irmãos (níveln) formam um domínio e são gerenciados pelo nó pai que é um AKS (nível n-1). Os AKS’s quesão irmãos (nível n-1) também formam um domínio de AKS’s e são gerenciados pelo AKS queé o nó pai (nível n-2) e assim por diante.

Na Figura 4.9, quando o nó A solicita ao AKS1 a chave de sessão para comunicação seguracom o nó G, como o AKS1 não tem a chave pública de G, tem que solicita-la ao seu nó pai,AKS5. Este também não tem essa chave e tem que solicita-la ao AKS7. Do AKS7 a requisiçãoda chave passa para o AKS6 e depois para o AKS4. AKS4 tem a chave pública de G e a enviade volta autenticada, junto com a chave pública de AKS1 autenticada. As chaves seguem ocaminho inverso na resposta: AKS4-AKS7-AKS7-AKS5-AKS1.

Para que um AKS possa identificar se o nó destino está em uma das suas sub-árvores, bastaque os identificadores dos nós da rede tenham uma estrutura hierárquica como os nomes demáquinas e domínios na Internet. Isto pode ser feito identificando o nó através dos nomes dosServidores que estão no caminho do nó até a raiz da árvore. Dessa forma, o caminho dasolicitação de chave fica implícito no identificador. Como exemplo, A.AKS1.AKS5.AKS7 6 o AKS local de C é o AKS2 e PK1 está autenticada com SK2, logo C pode verificar a autenticidade dePK1 e conseqüentemente dos parâmetros recebidos

A FDCBG

AKS1 AKS2AKS4

AKS5AKS6

AKS7

E

AKS3

H

I

Figura 4.9 - Hierarquia de Servidores de Chaves

61

identifica o nó A e G.AKS4.AKS6.AKS7 identifica o nó G. Se A solicitar comunicação com onó destino G, o AKS1 examina o endereço do destino e verifica que G não está em uma das suafolhas. Em seguida, transmite a solicitação para o AKS5 que é o seu nó pai. Pelo endereço,AKS5 sabe que G não está em nenhuma das folhas das suas sub-árvores porque nem AKS4nem AKS6 estão em qualquer das suas sub-árvores. Portanto, AKS5 envia o pedido paraAKS7 que é o seu nó pai e raiz da árvore toda. AKS7 verifica o identificador e envia o pedidopara AKS6, que também verifica o identificador e envia para AKS4. AKS4 tem a chave eresponde ao pedido enviando a chave para AKS6. O caminho de volta é fácil porque em cadaAKS pelo qual o pedido passou existe uma requisição de chaves pendente e o servidor sabe paraquem deve responder.

O caminho do Servidor de um nó origem até o Servidor de um nó destino, para solicitação dachave pública do nó destino, é determinado pelo primeiro Servidor comum aos dois nós. Comoexemplo, o caminho para obtenção da chave pública do nó E (E.AKS2.AKS5.AKS7) parapermitir a comunicação segura com o nó B (endereço B.AKS1.AKS5.AKS7), deve ser AKS1-AKS5-AKS2 porque o primeiro Servidor comum ao nó B e ao nó E é o Servidor AKS5.

Este é o mesmo modo de funcionamento de Servidores de Nomes como o DNS (Domain NameService) da Internet, que utili zam o conceito de domínio e organização hierárquica de nomes[Halsall , 1996]. Em redes TCP/IP, o identificador ID pode ser o próprio nome da máquinausado no DNS. Além disso, se o domínio do AKS for igual ao do servidor de nomes, o AKSpode ser acoplado ou integrado ao DNS. Dessa forma, as tabelas poderiam conter as chavespúblicas junto com os endereços IPs e nomes de máquinas. As solicitações e respostas do DNSpoderiam levar os endereços junto com as informações dos Servidores de Chaves, fornecendoum serviço conjunto de resolução de nomes e de distribuição de chaves.

A estrutura em árvore simpli fica a localização dos nós mas a distribuição do gerenciamento dechaves tem que ser tolerante a falhas para ser confiável. Sem tolerância à falha, se um Servidorfalhar a rede não pára completamente como no caso do gerenciamento centralizado mas umaparte da rede pode ficar inoperante ou ficar isolada do restante. É necessário que algumesquema de redundância seja implementado para que um Servidor que venha a falhar possa sersubstituído por outro, de forma a aumentar a confiabilidade da rede segura.

4.6 Conclusões sobre o Protocolo

O protocolo proposto garante confidencialidade da chave de sessão contra ataques passivos eativos. Garante também autenticação de origem e destino que devem ser característicasobrigatórias de qualquer protocolo confiável para distribuição de chaves. Além disso, apresentaalgumas características importantes que o tornam adequado ao uso em redes grandes. Precisa deum pequeno número de interações para distribuição da chave de sessão dentro do mesmodomínio: são necessários apenas três passos para o estabelecimento de chave confiável paracomunicação. Apenas o nó origem precisa se comunicar com um Servidor de Autenticação e deChaves, o que reduz o tráfego de dados de controle e diminui a latência para obtenção da chave.Permite centralizar a geração das chaves de sessão e ainda assim manter o segredo, mesmo parao AKS. Permite também o controle de validade da chave por tempo ou por conexão.

Além dessas características, o protocolo permite que o centro de distribuição de chaves sejadistribuído pela rede de forma a otimizar o gerenciamento de chaves em redes grandes.

62

Capítulo 5

Distr ibuição de Chaves através de RedesATM

5.1 Introdução

Para que um par de nós possa se comunicar com sigilo, ambos têm que estar de posse de umachave criptográfica secreta (chave de sessão), que é utili zada como parâmetro de um algoritmosimétrico de bloco para cifrar os dados na transmissão e decifrar na recepção. Além disso, umachave de sessão deve ser usada apenas em uma conexão e esta chave deve ser trocadaperiodicamente para garantir a segurança da comunicação. Os protocolos de distribuição dechaves mais utili zados concentram a geração dessas chaves em máquinas que funcionam comoservidores de chaves. Esses servidores funcionam também como servidores de autenticaçãoefetuando a autenticação dos nós no processo de distribuição de chaves [Stallings, 1995].

Quando um nó quer se comunicar com outro, uma chave tem que ser solicitada ao Servidor edistribuída para cada nó. O transporte da chave desde o Servidor até os dois nós deve serotimizado de forma a reduzir o número de conexões necessárias e a latência devido aoscomplexos cálculos de algoritmos de chave pública utili zados para garantir a segurança nadistribuição.

Quando uma chave é instalada em um circuito virtual já estabelecido, é necessário que ainstalação da chave na origem e no destino sejam sincronizadas, caso contrário uma parte dosdados transmitidos antes e depois da instalação da chave pode se perder. Como as chaves desessão usadas para prover o sigilo dos dados devem ser trocadas com freqüência, essesproblemas de otimização e sincronização são fundamentais para evitar a degradação dodesempenho devido à segurança. A instalação da chave inicial deve ser feita antes doestabelecimento do circuito, evitando o problema de sincronização. Se for feita com o circuito jáestabelecido, é necessário algum mecanismo para sincronizar a instalação.

Em uma rede de computadores suportada nos níveis mais baixos por tecnologia ATM, aimplementação de serviços de segurança de dados tem a vantagem de tornar a segurançadisponível para qualquer aplicação operando sobre qualquer protocolo em cima da pilha ATM[RFC1483, 1993]. Mas alguns problemas precisam ser levados em conta para que os serviçossejam implementados de forma eficiente.

Grandes redes ATM utili zam circuitos virtuais e, cada vez que uma comunicação segura foriniciada, é necessário estabelecer conexões entre cada nó e o Servidor de Chaves paradistribuição da chave de sessão. Como o estabelecimento dos circuitos virtuais é umprocedimento demorado, é necessário otimizar a quantidade de conexões necessárias paradistribuição de chaves.

Neste capítulo é especificado um esquema para transporte das chaves e sincronização da trocadas chaves em redes ATM, operando com circuitos virtuais, otimizando a quantidade de

63

conexões e os tempos de latência e simpli ficando a sincronização. O esquema consiste emutili zar um mecanismo do protocolo de sinalização para transporte de chaves em tempo deconexão.

5.2 Protocolo de Distribuição de Chaves para Utilização emCircuitos Virtuais

A otimização da distribuição na rede de transporte começa pela escolha do algoritmo dedistribuição de chaves. É necessário que o protocolo utili zado tenha características adequadas àoperação em redes que utili zam circuitos virtuais, além das características de segurançanecessárias. O protocolo descrito no Capítulo 4 tem estas características.

Para reduzir a quantidade de conexões necessárias, uma pequena modificação pode seracrescentada para que o Servidor de Chaves envie mais de uma chave de sessão de cada vez. Aschaves extras recebidas são armazenadas em um cache de chaves de sessão. Dessa forma,quando for iniciada uma conexão, ou quando a chave de sessão tiver que ser trocada, seexistirem chaves para o nó destino no cache, não é necessário estabelecer um circuito com oServidor de Chaves para obter novas chaves. A Figura 5.1 ilustra a descrição do protocolomodificado. O nó A vai se comunicar com o nó C que está em outro domínio e com o nó B queestá no mesmo domínio.

A solicita a chave mestra ao Servidor AKS1:

(1) A 8 AKS1 : IDA, IDA, Master_Key_Request

(2) AKS1 8 AKS3 : IDK1, IDC

(3) AKS3 8 AKS2 : IDK3, IDC, ASK3(PK1)

A

AKS1

AKS3

AKS2

C

domain 1domain 2

(1)

(2)(3)

(4)

(5)

(6)

(7)

(8)B

(9)

(10)

IDa, IDb,

Master_Key_Request

IDa, IDc,

Master_Key_Request

TKTb = ASk1(IDa, Pa, IDb, Pb, EPa(Kmi, T), EPb(Kmi, T))

TKTc = ASk1(IDa, Pa, IDc, Pc, EPa(Kmi, T), EPc(Kmi, T))

TKTb, SKSb

TKTc, ASk2(Pk1), SKSc

SKSb = EKmib(Ksi1b,Tb), EKbmib(EKsi2b,Tb), ...

SKSc = EKmic(Ksi1c,Tc), EKbmic(EKsi2c,Tc), ...

TKTc, EPc(Kmc), EKmc(Ksc), EKsc(IVc), ASk2(Pk1)EPb(Kmb), TKTb, EKmb(Ksb), EKsb(IVb)

IDk1, IDc IDk3, IDc, ASk3(Pk1)

ASk2(IDc, Pc),

ASk2(Pk1)

ASk3(IDc, Pc),

ASk2(Pk1)

ESc(T)ESb(T)

Figura 5.1 - Distribuição de Chave e Autenticação

64

(4) AKS2 9 AKS3 : ASK2(IDC, PC), ASK2(PK1)

(5) AKS3 9 AKS1 : ASK3(IDC, PC), ASK2(PK1)

O AKS1 gera aleatoriamente uma chave mestra inicial Kmi e um conjunto de chaves de sessãoKsi.

(6) AKS1 9 A : ASK1(IDA, PA, IDC, PC, EPA(Kmi, T), EPC(Kmi, T)), ASK2(PK1)

EKmi(Ksi1, T), EKmi(Ksi2, T), ...

A verifica T e armazena cada Ksi no cache de chaves de sessão. A gera a chave mestra efetivacifrando Kmi com SA, e gera a chave de sessão efetiva cifrando uma das chaves Ksi com SA:

Km = ESA(Kmi)Ks = ESA(Ksi1)

(7) A 9 C : EPC(Km), EKm(Ks), EKs(IV),ASK1(IDA, PA, IDC, PC, EPA(Kmi, T), EPC(Kmi, T)), ASK2(PK1)

(8) C 9 A : ASC(T)

Como A e B estão no mesmo domínio, AKS1 tem a chave PB e não é necessário comunicaçãocom outros servidores.

(1) A 9 AKS1 : IDA, IDB, Master_Key_Req

(6) AKS1 9 A : ASK1(IDA, PA, IDB, PB, EPA(Kmi, T), EPB(Kmi, T)),EKmi(Ksi1, T), EKmi(Ksi2, T), ...

(7) A 9 B : EPB(Km), EKm(Ks), EKs(IV),ASK1(IDA, PA, IDB, PB, EPA(Kmi, T), EPB(Kmi, T)), ASK2(PK1)

(8) B 9 A : ASB(T)

Posteriormente, a distribuição de chaves de sessão pode ser feita utili zando a chave mestra jádistribuída (Figura 5.2). Este procedimento é utili zado para a primeira chave de sessão de umaconexão ou para troca periódica de chave de sessão. Este procedimento é utili zado quando o nódestino está no mesmo domínio (B) e também quando o nó destino está em outro domínio (C).

Os passos 1 e 2 são necessários apenas se não houver chaves de sessão para o nó destino nocache de chaves. Cada chave de sessão do cache que é utilizada deve ser apagada.

EKmi(Ksi1, T), EKmi(Ksi2, T), ..., EKmi(Ksin, T)

AKS1

A B

IDa, IDb, Session_Key_Request

EKm(Ks), EKs(IV)

(1)

(2)

(3)

Figura 5.2 - Distribuição de Chave de Sessão

65

(1) A : AKS : IDA, IDB, Session_Key_Req

O AKS gera aleatoriamente um conjunto de chaves de sessão. Gera uma marca de tempo Tindicando quando as chaves foram geradas.

(2) AKS : A : EKmi(Ksi1, T), EKmi(Ksi2, T), ..., EKmi(Ksin, T)

A recebe as chaves, decifra, verifica T e armazena cada Ksi no cache de chaves. A gera a chavede sessão efetiva cifrando uma das chaves Ksi com SA:

Ks = ASA(Ksi1)

A gera, a partir do relógio interno da máquina, um vetor de inicialização IV para a operação doalgoritmo em modo cypher block chainning.

(3) A : B : EKm(Ks), EKs(IV)

Um novo valor de IV deve ser transmitido periodicamente de A para B para ressincronizar oalgoritmo. IV deve ser cifrado pelo algoritmo de bloco usando a chave Ks em modo electroniccode book:

A : B : EKm(IV)

IV = DKs(EKs(IV))

Todo o controle da distribuição de chaves é feito pelo nó origem, que é o nó A na descriçãoacima. O nó origem controla a validade e requisita novas chaves ao Servidor quando a chavemestra perde a validade, ou quando acabam as chaves de sessão do cache.

5.3 Dinâmica da Distribuição das Chaves

No sistema de segurança, se a chave de transmissão for diferente da recepção, ou se oencadeamento de blocos (Figura 2.1) da transmissão estiver defasado em relação à recepção, osdados decifrados não correspondem aos dados originais. Neste caso, as camadas superiores vãodescartar os dados se houver verificação de erro.

Outro problema associado ao da sincronização na troca das chaves é o da contenção dos dados.Se o sistema de segurança for transparente para as aplicações e a instalação da chave de sessãofor feita após o estabelecimento do circuito virtual, a aplicação pode iniciar a transmissão dosseus dados sem que as chaves tenham sido instaladas. Se a chave não foi instalada durante aconexão, os dados não podem ser transmitidos. Se forem, não serão cifrados no início datransmissão e depois poderão ser descartados no destino até que o cifrador e o decifradorestejam sincronizados. É necessário então que os dados sejam contidos e armazenados em umbuffer na memória principal até que a chave seja instalada para evitar a retransmissão pelaaplicação, o que implicaria em uma perda de desempenho maior. Em redes alta velocidade comouma rede ATM, o volume de dados a serem armazenados pode ser muito grande. A taxa efetivade transmissão de dados por uma aplicação pode chegar a 100 Mbps em uma conexão a 155Mpbs. Se o tempo para instalação de chaves for de um décimo de segundo é necessárioarmazenar 1,25 MB por conexão, o que pode causar problemas de latência e de espaço emmemória principal, quando várias conexões forem estabelecidas em uma mesma máquina. Umdécimo de segundo para uma troca de chaves não é um tempo grande quando é utili zadoalgoritmo de chave pública para distribuir a chave de sessão. Por isso, os protocolos detransporte das chaves através da rede devem ser escolhidos com cuidado levando em conta essesproblemas.

66

Na primeira parte do protocolo de distribuição de chave descrito na seção anterior (Figura 5.1),nos passos de 1 até 6, o transporte das chaves pode ser feito através de PDUs normais de algumprotocolo de gerenciamento. Não existe problema de sincronização nem de latência natransmissão do dados porque não existe ainda um circuito virtual entre nó origem e nó destino.O problema é o atraso no início do estabelecimento desse circuito.

No passo 7 (Figura 5.1), pode ser feita uma otimização. Ao invés de utili zar uma conexãoadicional entre nó origem e nó destino apenas para enviar chaves, é possível utili zar o próprioprocedimento de estabelecimento do circuito virtual para o transporte das chaves. As chavespodem ser transportadas na mensagem SETUP do protocolo de sinalização Q.2931 e instaladasantes que o circuito esteja completamente estabelecido, evitando problemas de sincronização ede armazenamento de dados. No passo 8, a conclusão da autenticação pode ser feitatransportando ESA(T) na mensagem CONNECT do protocolo Q.2931.

Na segunda parte do protocolo de distribuição de chave (Figura 5.2), nos passos 1 e 2 otransporte das chaves pode também ser feito através de PDUs normais de algum protocolo degerenciamento. No passo 3, se for a primeira chave de uma conexão, a chave e o vetor podemser transportados na mensagem de SETUP e instalados antes que o circuito estejacompletamente estabelecido, evitando problemas de sincronização. Se for uma troca periódica, achave e o vetor podem ser enviados através de uma PDU de gerenciamento da camada AAL5que pode ser identificada no destino e tratada de forma especial [Chuang, 1995]. Esteprocedimento é detalhado no capítulo seguinte. A ressincronização periódica do algoritmo, coma troca do vetor de inicialização IV, pode ser feita da mesma forma.

Para operacionalizar esse procedimento de forma que fique transparente e independente daaplicação, a conexão iniciada pela aplicação tem que ser interrompida antes do envio damensagem de solicitação de conexão (mensagem SETUP), para que uma conexão com oServidor de Chaves seja estabelecida e a chave seja gerada e recebida. Caso já exista chave desessão para o nó destino no cache de chaves, esta conexão com o Servidor não é necessária.Depois que a chave é recebida, a conexão com o Servidor é encerrada. Em seguida, a conexãocom o destino é reiniciada e entre os parâmetros de conexão deve ser enviada a chave de sessãoe outras informações necessárias. O retardamento da conexão inicial não afeta os timeouts doprotocolo de sinalização já que a mensagem com o pedido de conexão para o nó destino não éenviada para a rede.

Nesses procedimentos, a segurança é garantida pelo uso da cifração e decifração através dealgoritmo de chave pública. Este tipo de algoritmo é muito lento e consome um tempoconsiderável de CPU [Schneier, 1996]. Antes que a conexão seja estabelecida, todos os cálculose transferências de chaves são concluídos e, como o tempo gasto na comunicação é bem maiordo que o de processamento, o tempo gasto com cifração e decifração é uma porcentagempequena do tempo total. Concluída a distribuição da chave mestra, a troca da chave Ks e de IVpode ser feita de forma muito rápida porque utili za algoritmo simétrico. A seqüência de eventosdescrita anteriormente é ilustrada na Figura 5.3.

O controle da validade da chave mestra, da chave de sessão, e do vetor de inicialização é feitopelo nó origem porque é este nó que inicia e controla a distribuição das chaves. O tempo devalidade de uma chave depende do nível de segurança desejado. Em princípio, quanto maior afreqüência da troca, maior a segurança. No entanto, a troca tem um custo que cresce com ahierarquia das chaves. A troca de uma chave de sessão tem o menor custo já que o procedimentoé automático, utili za algoritmo mais rápido (simétrico) e gasta apenas uma célula em cadasentido para trocar a chave. A troca da chave mestra tem um custo maior porque utili zaalgoritmo mais lento (assimétrico) e o número de células necessárias para transmitir todos osparâmetros é bem maior, mas o procedimento também é totalmente automático. A troca das

67

chaves públicas tem o maior custo porque, apesar de ser feita de forma automática, depende deverificação manual, além de utili zar algoritmo mais lento, e gastar um número de células bemmaior do que no caso da troca de chave de sessão.

A validade das chaves públicas depende do tamanho da chave e do estado da arte da análisecriptográfica de algoritmos de chaves públicas. Se o tamanho da chave for suficientementegrande, a chave pode ter uma validade equivalente ao tempo de obsolescência tecnológica daprópria máquina, ou seja alguns anos, e nunca é trocada. A validade da chave mestra é menormas a troca não será feita em períodos menores do que algumas horas, podendo chegar até avários dias. A chave de sessão tem que ser trocada com grande freqüência, e sua validade deveser determinada pela quantidade máxima de células de gerenciamento que é recomendada para arede. Em redes ATM é recomendado que o número máximo de células de gerenciamento sejamenor do que 1% do total de células [UNI ILMI, 1996]. Portanto, a validade deve ser calculadalevando em conta esses parâmetros, de forma que, somando as células de gerenciamento dechave com outras células de gerenciamento, o total não ultrapasse 1% do total de células.

Apenas uma chave mestra é necessária para cada par de nós origem-destino, podendo esta chaveser usada para distribuição de chaves de sessão para várias conexões. Como um nó pode sertanto origem quanto destino, para cada par de nós deve haver duas chave mestras, uma para serusada quando o nó é destino e a outra para ser usada quando o nó é origem. A chave mestradeve ser sempre distribuída durante o estabelecimento de conexão para evitar problemas desincronização da troca de chave de sessão com troca de chave mestra. As chaves de sessão evetores de inicialização devem ser únicos para cada conexão. Além disso, cada vez que umaconexão é encerrada a chave de sessão correspondente deve ser descartada e, conseqüentemente,uma nova chave Ks e um novo vetor IV devem ser usados a cada nova conexão. A troca dovetor de inicialização deve ser feita em função da taxa de erros média do canal e deve entrar nacontagem de células de gerenciamento.

source nodedestination node Key Server

{...Ks...IV...}

{...Ks...IV...}

{...IV...}

{...IV...}

{...IV...}

{...IV...}

SETUP{...Km...Ks...IV...}

{...Kmi...Ksi...}

{...Ksi...}

{IDa, IDb}

{IDa, IDb}

CONNECT

Master Keyand/or

Session Keydistribution

Session Keydistribution

resynchronization

resynchronization

Ks change

Q.2931 Message

Management AAL5 PDU

Regular AAL5 PDU

delayedconnection

time

Figura 5.3 - Seqüência de Eventos de Protocolo na Distribuição de Chaves entre NósOrigem e Destino

68

Outro fator importante na otimização é o número de chaves de sessão que devem ser geradaspelo Servidor a cada solicitação. Este número deve levar em conta a capacidade dearmazenamento local, a freqüência da troca de chaves e a freqüência máxima de conexões como Servidor que pode ser considerada aceitável para a rede, sem degradação de desempenho. Paraa mesma freqüência de trocas, quanto maior o tamanho do cache de chaves, menor a freqüênciade conexões com o Servidor de Chaves.

5.4 Distribuição de Chaves através de Mensagens deSinalização

O estabelecimento de um caminho virtual em uma rede ATM é feito através de mensagens desinalização que seguem o protocolo Q.2931 [Q.2931, 1995], de acordo com a versão 4 daespecificação de sinalização do ATM Forum [UNI signalli ng, 1994]. Um nó origem solicitauma conexão com um nó destino enviando, para a rede, uma mensagem SETUP com osparâmetros da conexão. A mensagem passa pelos diversos comutadores até o destino e, se arede puder atender os valores indicados nos parâmetros e o destino aceitar a conexão, umamensagem CONNECT é enviada de volta aceitando a conexão. Caso contrário, uma mensagemREALEASE_COMPLETE é enviada.

Os parâmetros de segurança dos passos 7 e 8 do protocolo da seção 5.2 (Figura 5.1) podem sertransportados dentro das mensagens de sinalização SETUP e CONNECT, através de ummecanismo de escape definido no protocolo Q.2931. O mecanismo consiste em utili zar umElemento de Informação (IE) especial, denominado Broadband-Non-Locking Shift (BNLS),para inserir na mensagem um Elemento de Informação definido pelo usuário (Figura 5.4). UmElemento de Informação BNLS pode ser usado em qualquer mensagem Q.2931 [Q.2931, 1995].

Cada Elemento de Informação é identificado pelo primeiro octeto do cabeçalho (Figura 5.4).

Cada Elemento de Informação tem um campo Codeset Standard de três bits localizado nosegundo octeto do cabeçalho. Neste campo é indicado a qual conjunto de códigos o identificadordo elemento pertence. Os códigos definidos para uma determinada organização ou finalidade

Protocol discriminator

0 0 0 0 Length of callreference value

Flag

Call reference value

Message type

Message length

Information elements

Information element identifier

1 Codingstandard

IE instruction field

Length of informationelements

0 1 1 0 0 0 0 1 Broadband-Non-Locking Shift

1 0 0 0 0New codeset Id

1 1 1

Information element identifier

1 Codingstandard IE instruction field

Length of informationelements

Parameters

Q2931 message

User SpecificInformation Element

Size of Parameters Field

User Code Set

Figura 5.4 - Elemento de Informação Broadband-Non-Locking Shift

69

pertencem a um conjunto de códigos. Podem existir até sete conjuntos de códigos. O número docódigo de um Elemento de Informação de um conjunto pode ser igual ao número de código deoutro Elemento de Informação de um conjunto diferente. Os Elementos de Informaçãopadronizados pelo ITU pertencem ao conjunto de códigos número zero, que é o conjuntodefault. O conjunto de códigos número sete é reservado para uso específico de usuário.

O Elemento de Informação Broadband-Non-Locking Shift, dentro de uma mensagem Q.2931,indica que o próximo Elemento de Informação deve ser interpretado de acordo com o número decódigo indicado no campo New Codeset Id (três últimos bits do octeto 5) do cabeçalho. Se ocódigo for sete, o Elemento de Informação é específico de usuário. Depois que o Elemento deInformação seguinte ao BNLS é interpretado, o próximo elemento deve ser interpretado deacordo como conjunto de códigos ativos, geralmente o zero.

Novos Elementos de Informação para transportar as chaves e outros parâmetros dentro demensagens de SETUP e CONNECT podem ser definidos. Cada um desses elementos pode serinserido na mensagem depois de um Elemento de Informação Broadband-Non-Locking Shiftcom o campo Codeset Standard igual a sete. Três novos Elementos de Informação são definidosnesta proposta. Um para transporte dos parâmetros de segurança do nó origem até o nó destino,outro para transporte da informação de autenticação de destino do nó destino até o nó origem(Figura 5.5), e outro para transporte de chave de sessão e vetor de inicialização.

Através da utili zação do mecanismo de escape, o tempo gasto na distribuição da chave mestra éotimizado. Isto ocorre porque o procedimento de conexão é demorado e o tempo gasto noscálculos e transferências representam uma porcentagem pequena do tempo total de conexão, seo processador for suficientemente rápido. Outra vantagem importante é que as mensagens deconexão utili zam um serviço confiável fornecido pelo protocolo SSCOP na subcamada deconvergência (seção 2.2.6, Capítulo 2), garantindo a entrega das chaves.

Nas situações em que o processador estiver muito sobrecarregado e o tempo de cálculo doalgoritmo de chave pública retardar demasiadamente o envio da mensagem CONNECT, o timer

Information element identifier Information element identifier Information element identifier

1 1 1Codingstandard

Codingstandard

CodingstandardIE instruction field IE instruction field IE instruction field

Length of informationelements

Length of informationelements

Length of informationelements

EPb(Km)

ESa(T)EKm(Ks)

EKs(IV)

ESk2(Pk1)

EKm(Ks)

EKs(IV)

ESk1( IDa, Pa,IDb, Pb,EPa(Kmi, T),EPb(Kmi, T) )

Master Key DistributionInformation Element

Destination AuthenticationInformation Element

Session Key andInitialization Vector

Information Element

Figura 5.5 - Elementos de Informação de Usuário

70

T3031 pode provocar timeout no nó origem e reenvio do SETUP (seção 2.3.5, Capítulo 2). Istopode ser evitado através de uma mensagem ALERTING, enviada do nó destino ao nó origem,que interrompe o timer T303 e inicia o timer T3012 aumentando bastante o tempo permitidopara conclusão da conexão [Q.2931, 1995].

De acordo com [Q.2931, 1995], o primeiro comutador público entre origem e destino devetratar os elementos de informação com o campo Codeset Standard igual a sete como elementonão reconhecido. No entanto, a mesma norma prevê que esse procedimento pode ser alteradoatravés de acordo bilateral entre usuário e a concessionária de serviço de comunicação,permitindo que os Elementos de Informação de Usuário atravessem a rede pública semtratamento de erro.

Uma forma alternativa de transportar chaves durante o procedimento de estabelecimento deconexão é utili zar um Elemento de Informação User-User (Figura 5.6). Este elemento permiteenviar 129 octetos de informação de usuário a usuário, sem interferência dos comutadores. Umcampo de dados de 129 octetos não é suficiente para transportar chaves RSA mas pode seradequado para outros algoritmos, como os algoritmos de chave pública baseados em curvaselípticas que utili zam chaves pequenas, da ordem de 200 bits [Certicom, 1996]. O Elemento deInformação User-User pode ser adequado também para uso com um protocolo que utili zeapenas algoritmo simétrico como o Kerberos, que utili za chaves simétricas com cerca de 128bits.

A mensagem SETUP leva uma série de parâmetros de conexão entre os quais o tipo de serviçoespecífico da subcamada SSCS da camada AAL5. Esta informação é enviada através do últimoocteto do Elemento de Informação AAL Parameters (Figura 5.7). Atualmente o protocoloQ.2931 define quatro tipos de subcamada SSCS: nula, SSCOP confiável, SSCOP não confiávele Frame Relay. Um quinto tipo pode ser definido para indicar, durante a conexão, o uso decriptografia. Dessa forma, durante o estabelecimento da conexão, o nó destino, ao receber amensagem SETUP e examinar os campos do Elemento de Informação AAL Parameters, verificaque está sendo solicitada uma conexão com criptografia e que existem Elementos de Informaçãoadicionais contendo parâmetros de segurança. A mensagem CONNECT deve indicar noElemento de Informação AAL Parameters se a conexão foi aceita com criptografia ou não.

1 Timer de espera de confirmação de recebimento da mensagem SETUP2 Timer de espera de estabelecimento de conexão

Information element identifier0 1 1 1 1 1 1 0

1 Codingstandard

IE instruction field

Length of informationelements

0 - 129 user octets

User-UserInformation Element

Figura 5.6 - Elemento de Informação User-User

71

5.5 Distribuição de Chaves entre Servidores e Nó Origematravés de Mensagens Q.2931

O mesmo mecanismo utili zado para transportar as chaves entre o nó origem e o nó destino podeser usado para transportar as chaves entre servidores e entre Servidor e nó origem. Neste caso, oestabelecimento da conexão tem a finalidade de transferir as chaves do Servidor ao nó origem.Se as mensagens de estabelecimento de conexão são utili zadas para transportar as chaves,nenhuma PDU de dados é transferida no circuito virtual. Ou seja, o circuito virtual não éutili zado. Este tipo de conexão pode ser considerado uma “pseudo-conexão” porque suafinalidade não é estabelecer uma conexão para transferência de dados. Além disso, se os nósorigem e destino estiverem no mesmo domínio, a conexão não precisa ser estabelecida.

A seqüência de eventos descrita nos parágrafos seguintes é ilustrada na Figura 5.8.

Protocol discriminator

0 0 0 0 ; < = > ? @ A B C D E EF < B < F < = C < G D E H <Flag

Call reference value

Message type

Message length

Information elements

Information element identifier

1 Codingstandard

IE instruction field

Length of informationelements

Contents of informationelements

1 0 0 0 1 1 0 0

1 0 0 0 0 0 0 1

SCSS type identifier1 0 0 0 0 1 0 0

SCSS type

0 1 0 1 1 0 0 0

Subtype identifier0 0 0 0 0 1 0 1

AAL Parameters Information Element

AAL type 5

SSCS type:0x00 = null0x01 = SSCOP confiável0x02 = SSCOP não confiável0x04 = frame relay0x08 = criptography

Q.2931 message

Backward Max. CPCSSDU Size

Forward Max. CPCSSDU Size

Figura 5.7 - Indicação de Criptografia no Elemento de Informação AAL Parameters

72

A distribuição de chaves entre nó origem e Servidor, quando o nó destino está no mesmodomínio, é feita através das mensagens SETUP e RELEASE_COMPLETE. O nó origem enviaum SETUP contendo, entre seus parâmetros, um Elemento de Informação para solicitação dachave (passo 1 do protocolo da Figura 5.1), e recebe uma mensagem RELEASE_COMPLETE(passo 6 do protocolo da Figura 5.1) rejeitando a conexão e transportando as chaves em umElemento de Informação. O mesmo procedimento é utili zado para os passos 1 e 2 do protocoloda Figura 5.2. Neste caso, a conexão nem chega a ser estabelecida, já que as chaves sãotransportadas em uma mensagem RELEASE_COMPLETE que rejeita o estabelecimento daconexão (“pseudo-conexão”). Neste procedimento, é utili zada uma mensagem a menos do queem um procedimento normal de estabelecimento e encerramento de conexão: SETUP,CONNECT, RELEASE. O mesmo procedimento é usado também para distribuição de chavesde sessão (Figura 5.2): SETUP e RELEASE_COMPLETE. Os novos Elementos de Informaçãodefinidos para estes procedimentos são mostrados na Figura 5.9.

source nodeAuthentication and

Key Server 1Authentication and

Key Server 3Authentication and

Key Server 2

SETUP {IDa,IDb}

SETUP {IDa,IDc}

SETUP {IDk1,IDc}

SETUP {IDk1,IDc}

RELEASE_COMPLETE{...Kmi...Ksi...}

RELEASE {...Kmi...Ksi...}

RELEASE{ESk3(IDc,Pc),ESk2(Pk1)}

CONNECT {searching key}

CONNECT {searching key}

RELEASE_COMPLETE{ESk2(IDc,Pc),ESk2(Pk1)}

intradomainkey distribution

interdomainkey distribution

time

Figura 5.8 - Seqüência de Eventos na Distribuição de Chaves entre Nó Origem eServidores

73

A distribuição de chaves entre nó origem e Servidor, quando o nó destino está em outrodomínio, é feita através das mensagens SETUP, CONNECT e RELEASE, transportando assolicitações de chave, indicações de tipo de solicitação e parâmetros de segurança. Os novosElementos de Informação definidos para estes procedimentos são mostrados na Figura 5.10 e naFigura 5.11. O nó origem envia uma mensagem SETUP contendo um Elemento de InformaçãoMaster Key Request com a solicitação de chaves (passo 1 do protocolo da Figura 5.1). OServidor 1 envia ao nó origem uma mensagem CONNECT contendo um Elemento deInformação Key Distribution Status com uma indicação de busca de chave em andamento(status = Searching_Key na Figura 5.10). O Servidor 1 envia uma mensagem de SETUP aoServidor 3 contendo um Elemento de Informação Public Key Request solicitando a chavepública do destino (passo 2 do protocolo da Figura 5.1). O Servidor 3 envia ao Servidor 1 umamensagem CONNECT contendo um Elemento de Informação Key Distribution Status com umaindicação de busca de chave em andamento (status = Searching_Key na Figura 5.10).

Information element identifierInformation element identifier

11 Codingstandard

Codingstandard

IE instruction fieldIE instruction field

Length of informationelements

Length of informationelements

IDa

IDb

EKmi1(Ksi1,T),EKmi2(Ksi2,T),. . .

Authenticated TicketInformation Element

MasterKey RequestInformation Element

ESk1( IDa, Pa,IDb, Pb,EPa(Kmi, T),EPb(Kmi, T) )

ESk2(Pk1)

Figura 5.9 - Elementos de Informação para Sinalização Nó Origem-Servidor

74

O Servidor 3 envia uma mensagem de SETUP ao Servidor 2 contendo um Elemento deInformação Public Key Request solicitando a chave pública do destino (passo 3 do protocolo daFigura 5.1). Finalmente, o Servidor 2 tem a chave solicitada e envia uma mensagemRELEASE_COMPLETE contendo um Elemento de Informação Authenticated Public Key coma chave pública do destino (passo 4 do protocolo da Figura 5.1). O Servidor 3 envia ummensagem RELEASE contendo um Elemento de Informação Authenticated Public Key com achave pública do destino (passo 5 do protocolo da Figura 5.1) ao Servidor 1. O Servidor 1 enviaao nó origem uma mensagem RELEASE contendo um Elemento de Informação AuthenticatedTicket com os parâmetros de segurança e as chaves solicitadas (passo 6 do protocolo da Figura5.1).

No caso de nenhum Servidor possuir a chave pública do nó destino, o último Servidor envia namensagem REALEASE um Elemento de Informação Key Distribution Status indicando que achave pública do nó destino não existe (status = Key_Unavailable na Figura 5.10). Esteprocedimento é repetido por cada Servidor até chegar ao que iniciou a solicitação da chavepública.

5.6 Conclusão

A utili zação dos procedimentos de conexão e as mensagens de estabelecimento de circuitovirtual para distribuir as chaves traz algumas vantagens importantes:

Information element identifier

1 Codingstandard

IE instruction field

Length of informationelements

Status

Key Distribution StatusInformation Element

Figura 5.10 - Elemento de Informação Estado da Distribuição de Chaves

Information element identifier Information element identifier

1 1Codingstandard

CodingstandardIE instruction field IE instruction field

Length of informationelements

Length of informationelements

Public Key RequestInformation Element

Authenticated Public KeysInformation Element

IDK1

IDc

ESk2(Pk1)

ESk2(IDc,Pc)

ESk3(Pk1)

Figura 5.11 - Elementos de Informação para Sinalização Servidor-Servidor

75

• Uso do protocolo confiável SSCOP para transportar as mensagens Q.2931garantindo a entrega das chaves;

• Menor latência na obtenção das chaves, já que são necessárias menos mensagens desinalização;

• Economia de circuitos virtuais que não chegam a ser estabelecidos, principalmentese a maior parte das conexões ocorrer entre nós pertencentes ao mesmo domínio;

• Eliminação do problema de sincronização na troca das chaves, evitando o uso degrandes áreas de armazenamento em memória principal dos dados transmitidos.

76

Capítulo 6

Arquitetura Funcional de um Sistema deSegurança

6.1 Introdução

Este Capítulo descreve a arquitetura funcional do sistema de segurança detalhando os módulosdos nós usuários e dos nós servidores e descrevendo a função de cada um. É feita uma descriçãode como esses módulos interagem para fazer o sistema de segurança funcionar conforme osprocedimentos de distribuição de chaves descritos no Capítulo anterior e como os módulospermitem a operação do protocolo de segurança proposto no Capítulo 7.

A Figura 6.1 oferece uma visão geral do sistema de segurança mostrando as interações entre osnós. Está representada a distribuição de chaves através de mensagens de sinalização e a troca dechave de sessão através de PDUs CPCS de gerenciamento que é apresentada no Capítulo 7.

Figura 6.1 - Visão Geral do Sistema de Segurança

77

6.2 Estrutura dos Nós

O sistema de segurança segue o modelo cliente-servidor, onde os nós origem e destino são osclientes dos Servidores de Autenticação e de Chaves.

O sistema de segurança é composto de um conjunto de módulos integrados em uma estação detrabalho. Os módulos modificados ou acrescentados para prover segurança em uma estaçãocliente estão destacados na Figura 6.2.

São três os módulos que implementam a segurança no cliente: entidade do protocolo SSSP,Q.2931 Call Control API1 (QCC) e Local Security Manager2 (LSM). O módulo SSSPimplementa o protocolo de segurança da subcamada SSCS que é apresentado no Capítulo 7. Omódulo QCC fornece uma API de sinalização para as camadas superiores e interage com omódulo LSM que controla a distribuição das chaves.

Os módulos modificados ou acrescentados para prover segurança em uma estação servidoraestão destacados na Figura 6.3.

1 API de Controle de Chamada Q.29312 Gerenciador de Segurança Local

Figura 6.2 - Módulos de uma Estação Cliente

78

O módulo Authentication and Key Server3 (AKS) faz a função do Servidor de Chaves e deautenticação. Este módulo acessa a API de Controle de Chamada diretamente, sem utili zar apilha de protocolos que opera sobre o ATM. O Servidor pode ser modelado como um gerenteSNMPv2 (Capítulo 8).

6.2.1 Gerenciador de Segurança Local (LSM)O Gerenciador de Segurança Local (Figura 6.2) é um processo que controla todo oprocedimento de distribuição de chaves. A partir de notificações do módulo API de Controle deChamada, o LSM gerencia a distribuição de chaves requisitando, recebendo e armazenando,verificando a validade e autenticidade das chaves, e as enviando ao nó destino. Tambémgerencia a segurança instalando as chaves locais na subcamada SSCS, controlando a validadedas chaves e bloqueando a transmissão e recepção em caso de falha de autenticação. Estemódulo acessa a camada AAL5 direto sem utili zar a pilha de protocolos que opera sobre oATM, de forma a otimizar o desempenho. O módulo LSM pode ser implementado como umagente SNMPv2 inteligente (Capítulo 8).

O módulo LSM tem dois papéis, dependendo de estar atuando em um nó origem ou em um nódestino. O relacionamento origem-destino é do tipo mestre-escravo. No nó origem, o móduloLSM funciona no papel de mestre controlando a distribuição de chaves (requisição, geração,

3 Servidor de Autenticação e de Chaves

Upper Layers

GeneratorDriver

PublicKey

Table

RandomSequenceGenerator(Hardware)

Authenticationand KeyServer

Q.2931

QCC API

SSSP

CPCS

SAR

ATM

SSCF/SSCOPAAL5

APLICATIONSAssimetric

KeyGenerator

Figura 6.3 - Módulos de uma Estação Servidora

79

armazenagem, recepção, envio e instalação) e a validade das mesmas. No nó destino, o móduloLSM funciona no papel de escravo. Recebe os parâmetros, decifra, verifica a autenticação evalidade das chaves e as instala sob controle do módulo LSM origem. Responde também aomódulo LSM origem com a autenticação de destino.

6.2.2 Servidor de Autenticação e de Chaves (AKS)O Servidor de Autenticação e de Chaves (Figura 6.3) recebe, processa e responde às requisiçõesde chaves feitas pelo LSM no nó origem. As suas principais funções são: geração de chavesimétrica aleatória, armazenamento das chaves públicas em uma tabela de chaves, eautenticação das chaves simétricas e dos nós.

As chaves simétricas são geradas de forma aleatória, a partir de um dispositivo de hardwarecapaz de gerar seqüências de bits com características estatisticamente aleatórias [Knuth, 1981].

As chaves públicas são armazenadas em uma tabela de chaves com proteção criptográficacontra escrita não autorizada, funcionando como um catálogo eletrônico de chaves públicas. Aschaves são recuperadas através do endereço do nó. Este catálogo pode ser distribuído pela rede(Capítulo 2) e o Servidor se conecta a outros Servidores para obter uma chave pública nãodisponível localmente.

A autenticação é feita com o uso da chave secreta local e das chaves públicas armazenadas natabela de chaves.

6.2.3 API de Controle de Chamada Q.2931 (QCC)A função do módulo Q.2931 é controlar as instâncias dos estados do procedimento deestabelecimento de cada circuito virtual, conforme definido no protocolo Q.2931. As mensagensde sinalização são parâmetros das primitivas do protocolo Q.2931. A montagem e desmontagemdessas mensagens é feita pelo módulo da API de Controle de Chamada Q.2931 (Figura 6.2). Omódulo do protocolo Q.2931 não precisa de qualquer modificação em relação ao que estápadronizado na norma Q.2931 [Q.2931, 1995].

O módulo QCC oferece uma interface padronizada para os programas de aplicação ou camadassuperiores de protocolos utili zarem o protocolo Q.2931. A utili zação é feita através de funçõespara transmissão e para recepção de mensagens. As funções de transmissão permitem montarmensagens de sinalização no formato definido pelo protocolo a partir dos seus parâmetros. Asfunções de recepção permitem extrair dos elementos de informação transportados pelasmensagens, as informações necessárias às aplicações, passando através dos parâmetros dasfunções o conteúdo desses Elementos de Informação às aplicações.

O módulo tem também uma interface com o plano de gerenciamento através da qual interagecom o Gerenciador de Segurança Local, fornecendo ou recebendo informações relativas aoprocedimento de gerenciamento de chaves. O módulo QCC pode incluir Elementos deInformação nas mensagens utili zando parâmetros fornecidos pelo gerenciamento de segurançalocal, ou fornecer ao gerenciamento os parâmetros extraídos de Elementos de Informaçãorecebidos nas mensagens. O módulo QCC controla os pedidos de conexão segura e suspende amontagem e envio da mensagem SETUP até que o módulo Gerenciador de Segurança Localreceba as chaves do Servidor.

Entre as funções de controle de conexão que a API oferece, o módulo QCC deve incluir umafunção para pedido de conexão com segurança. Nas outras funções deve incluir, quandonecessário, um parâmetro para passar uma estrutura com o conteúdo do Elemento deInformação de Usuário que transporta os parâmetros de segurança. Como exemplo, no caso daAPI da Sun Microsystems [SunATM, 1995], as seguintes funções estão disponíveis paraestabelecimento e encerramento de conexão:

80

qcc_bld_setup(...)

Constrói uma mensagem SETUP a partir do parâmetros

qcc_bld_connect(...)

Monta uma mensagem CONNECT a partir do parâmetros

qcc_bld_release(...)

Monta uma mensagem RELEASE a partir do parâmetros

qcc_bld_release_complete(...)

Monta uma mensagem RELEASE_COMPLETE a partir do parâmetros

qcc_parse_setup(...)

Analisa e extrai os parâmetros da mensagem SETUP

qcc_parse_connect(...)

Analisa e extrai os parâmetros da mensagem CONNECT

qcc_parse_release(...)

Analisa e extrai os parâmetros da mensagem RELEASE

qcc_parse_release_complete(...)

Analisa e extrai os parâmetros da mensagem RELEASE_COMPLETE

Em cada uma destas mensagens deve ser acrescentado um parâmetro de função (SecParam)para transportar o conteúdo do Elemento de Informação de Usuário que contém parâmetros desegurança. Deve ser criada também uma função adicional para solicitar conexão comsegurança.

Exemplos:

qcc_bld_setup(..., mkr_struct *SecParam)

SecParam pode apontar para uma estrutura contendo {IDA, IDC};

qcc_parse_release_complete(..., atk_struct *SecParam)

SecParam pode apontar para uma estrutura contendo { ESK1(IDA, PA, IDC, PC,EPA(Kmi, T), EPC(Kmi, T)), ESK2(PK1), EKmi(Ksi1, T), EKmi(Ksi2, T), ...};

qcc_bld_sec_setup(....)

Esta função solicita uma conexão com segurança.

A Figura 6.4 ilustra a utilização das funções da API.

81

6.2.4 Geração de Chaves AssimétricasA geração de chaves assimétricas depende do tipo de algoritmo de chave pública empregado. Nocaso do algoritmo RSA, a geração é feita a partir de uma semente aleatória utili zando umalgoritmo que gera um número grande com potencial para ser primo4. Depois testa o númeropara verificar se é realmente um número primo.

Como a geração das chaves assimétricas é um processo que é realizado com pouca freqüência, asemente pode ser gerada por meios manuais. Uma forma simples e eficiente é a que é utili zadapara gerar as chaves no programa PGP [Stalli ngs, 1995]. A geração é feita através do teclado,medindo o tempo entre acionamentos de teclas em uma seqüência de acionamentos feitos peloadministrador de segurança do Servidor.

6.3 Modelo Operacional

A Figura 6.5 ilustra o modelo operacional que define como os módulos QCC, LSM e a entidadedo protocolo SSSP interagem para distribuir as chaves. As funções utili zadas como exemplosão as da API da Sun Microsystems.

4 Impar, algarismo menos significativo diferente de cinco e não divisível por três

CallerStation

API

CallerStationQ.2931

CalledStationQ.2931

Network CalledStation

API

qcc_bld_setup

qcc_parse_setup

qcc_bld_connect

qcc_parse_connectqcc_bld_release

qcc_parse_release

SETUP

CONNECT

RELEASE

setup.req

setup.conf

setup.ind

setup.resp

release.req

release.ind

time

Figura 6.4 - Utilização das Funções da API

82

Quando a função qcc_bld_sec_setup é invocada por uma camada superior ou uma aplicação(passo 1 da Figura 6.5), o módulo QCC informa ao módulo LSM, através da interface com oplano de gerenciamento utili zando as primitivas de gerenciamento de camada5, que foi solicitadauma conexão segura para o destino especificado na função (passo 2 da Figura 6.5). O pedido deconexão é suspenso em um estado de espera, aguardando o módulo LSM fornecer uma resposta.Supondo que a chave mestra tenha perdido a validade, o módulo LSM solicita uma conexãocom o Servidor (passo 3 da Figura 6.5) utili zando a função qcc_bld_setup(..., mkr_struct*SecParam). SegParam é um ponteiro para um tipo de estrutura que contém o tipo de chavesolicitada e {IDa, IDb}:

struct mkr_struct {

key_type request // Master_Key_Request ou Session_Key_Request

atm_addr_t *src_addrp // IDa

atm_addr_t *dst_addrp // IDb

}

O módulo QCC coloca estes parâmetros em um Elemento de Informação Master Key Request(Capítulo 5) e envia a mensagem CONNECT (passo 4 da Figura 6.5). Se o nó destino estiver nomesmo domínio, a resposta chega em uma mensagem RELEASE_COMPLETE (passo 5 daFigura 6.5) contendo um Elemento de Informação Authenticated Ticket (figura 3.10). O móduloLSM recebe os parâmetros (passo 6 da Figura 6.5) através da funçãoqcc_parse_release_complete(..., atk_struct *SecParam). SecParam é um ponteiro para um tipode estrutura que contém { ESK1(IDA, PA, IDC, PC, EPA(Kmi, T), EPC(Kmi, T)), ESK2(PK1),EKmi(Ksi1, T), EKmi(Ksi2, T), ...}:

5 AALM-UNITDATA.req e AALM-UNITDATA.ind

Figura 6.5 - Interação QCC-LSM-SSSP

83

struct atk_struct {

TicketBlock tkt // ESK1(IDA, PA, IDC, PC, EPA(Kmi, T), EPC(Kmi, T))

AssimCyphBlock auth_pub_key // ESK2(PK1)

DoubleSimCyphBlock priv_aks_session_key[n] // EKmi(Ksi1, T), EKmi(Ksi2, T), ...

}

Quando o nó origem está no mesmo domínio,

auth_pub_key := null.

Depois que o módulo LSM processa as informações recebidas, as chaves Km e Ks e o vetor IVsão fornecidas à entidade do protocolo SSSP (passo 7a da Figura 6.5), e os parâmetros desegurança são entregues ao módulo QCC (passo 7b da Figura 6.5). O módulo QCC coloca estesparâmetros em um Elemento de Informação Master Key Distribution (figura 3..5) e reinicia aconexão suspensa montando a mensagem SETUP para o nó destino (passo 8 da Figura 6.5). Amensagem SETUP é enviada ao módulo Q.2931.

Quando a mensagem SETUP chega ao módulo Q.2931 no destino, o módulo QCC recebe amensagem (passo 9 da Figura 6.5), analisa e verifica que está sendo solicitada uma conexãocom segurança. Os parâmetros de segurança são entregues ao módulo LSM através da interfacecom o plano de gerenciamento (passo 10a da Figura 6.5), utili zando as primitivas degerenciamento de camada. Simultaneamente, através da função qcc_parse_setup(..., int*SecParam), a camada superior ou aplicação de usuário recebe os parâmetros de conexão(passo 10b da Figura 6.5). Na variável apontada por SecParam está a indicação de subcamadaSSCS com criptografia. O módulo LSM do nó destino decifra parâmetros de segurança, passaas chaves Km e Ks e o vetor IV à entidade do protocolo SSSP (passo 11a da Figura 6.5).Simultaneamente calcula e entrega ao módulo QCC o autenticador de destino ESB(T) (passo 11bda Figura 6.5). A camada superior (ou aplicação) aceita a chamada através da funçãoqcc_bld_connect(...) (passo 12 da Figura 6.5). O módulo QCC só monta a mensagemCONNECT se tiver recebido ESB(T) do módulo LSM. A mensagem CONNECT é montada comum Elemento de Informação Destination Authentication. (Capítulo 5) e enviada (passo 13 daFigura 6.5). No nó origem é recebida pelo módulo QCC (passo 14 da Figura 6.5) que analisa eextrai os parâmetros. O autenticador é entregue ao módulo LSM através da interface com oplano de gerenciamento (passo 15a da Figura 6.5). Simultaneamente, os outros parâmetros sãoentregues ao usuário do módulo QCC que iniciou a conexão (passo 15b da Figura 6.5), atravésda função qcc_parse_connect(...).

Posteriormente, o módulo LSM pode trocar a chave Ks e o vetor IV através de uma PDU degerenciamento utili zando a interface da subcamada SSCS com o plano de gerenciamento. Comoé descrito no Capítulo 7, a PDU de gerenciamento é enviada do módulo LSM origem até o LSMdestino (passos 16, 17, 18 e 19 da Figura 6.5), e depois do módulo LSM destino até o móduloLSM origem (passos 20, 21 e 22 da Figura 6.5). São utili zadas as primitivas AALM-UNITDATA.req e AALM-UNITDATA.ind (Capítulo 7).

6.4 Conclusão

Este Capítulo descreve a arquitetura de segurança proposta, mostrando como os procedimentose mecanismos propostos no Capítulo 5 pode ser implementado utili zando a estrutura emcamadas de rede ATM, com uma quantidade mínima de modificações e módulos de segurançaadicionais. Este Capítulo antecipa também como o protocolo de segurança SSSP proposto noCapítulo 7 pode ser implementado com os módulos apresentados.

84

Capítulo 7

Protocolo Específico do Serviço deSegurança (SSSP)

7.1 Introdução

No Capítulo 5 foi apresentada uma proposta para distribuição de chaves através de mensagensde conexão. O esquema proposto permite a distribuição de chave mestra e/ou chave de sessãoantes de estabelecido o circuito virtual. É necessário definir também um esquema para a trocade chave de sessão e ressincronização do algoritmo. Esse esquema é fortemente acoplado aoserviço de segurança confidencialidade dos dados que deve ser fornecido pela subcamada SSCSda camada AAL5.

Neste capítulo é apresentada uma proposta para um protocolo de segurança que fornece oserviço de confidencialidade dos dados através de criptografia, utili zando algoritmo simétrico debloco na subcamada SSCS da camada de Adaptação ATM Tipo 5 (AAL5). Esse protocolo,denominado Service Specifi c Security Protocol1 (SSSP), permite também a troca da chave desessão através do circuito virtual estabelecido para transferência de dados, utili zando PDUsespeciais de gerenciamento.

7.2 Troca de Chaves através de PDUs CPCS deGerenciamento

Na arquitetura ATM, serviços específicos como o de criptografia devem ser colocados nasubcamada SSCS da Subcamada de Convergência (CS) da camada de adaptação AAL5 [I .363,1993]. O serviço específico de criptografia na subcamada SSCS é realizado pelo Protocolo deSegurança do Serviço Específico (SSSP). Este protocolo define como a subcamada SSCS devecifrar e decifrar os dados. Define o formato das PDUs de gerenciamento de chaves através dasquais a chave de sessão Ks e o vetor de inicialização IV podem ser enviados da origem aodestino e em sentido contrário. E define também como as PDUs de gerenciamento devem sertratadas.

As PDUs da subcamada CPCS tem um campo chamado CPCS-UU que é usado para passarinformação sobre o conteúdo da SDU entre os usuários da subcamada CPCS, que neste caso é aentidade do protocolo SSSP [I .363, 1993]. Na interface entre a subcamada SSCS e asubcamada CPCS, a primitiva de envio de dados CPCS-UNITDATA.invoke tem comoparâmetros a PDU do protocolo SSSP e o conteúdo do campo CPCS-UU, além de outros. Aprimitiva de recepção de dados CPCS-UNITDATA.signal fornece, nos parâmetros, o valor docampo CPCS-UU e a PDU do protocolo SSSP, além de outros. A subcamada SSCStransmissora pode usar o campo CPCS-UU para passar informações de gerenciamento econtrole, na sua SDU, para a subcamada SSCS receptora (Figura 7.1). O valor zero indica umaSDU normal, com criptografia e não segmentada, o valor um indica SDU com o primeiro

1 Protocolo de Segurança do Serviço Específico

85

segmento dos dados criptografados, e o valor dois indica SDU com o segundo segmento dosdados criptografados. A questão de segmentação será explicada na próxima seção. Os valoresquatro e oito indicam SDUs de gerenciamento. Existem dois tipos de PDUs especiais degerenciamento de chaves em função do conteúdo da SDU, que pode conter a chave Ks e o vetorIV cifrados para troca de chaves (UU = 4), ou o vetor IV cifrado para ressincronização (UU =8).

Após o estabelecimento da conexão, as chaves Km e Ks são instaladas no cifrador e decifradorno nó origem e no nó destino. O controle de validade de chave é feito no nó origem. Quandouma chave de sessão perde a validade, o nó origem obtém uma nova no cache de chaves desessão ou no Servidor de Chaves, e gera um novo vetor de inicialização. A nova chave Ks e onovo vetor IV são trocados no nó origem apenas no cifrador. O decifrador permanece com achave antiga porque o nó destino ainda não trocou a chave de sessão. Se não fosse dessa forma,os dados cifrados com a chave antiga que ainda estivessem em trânsito pela rede seriamdecifrados incorretamente. Uma PDU CPCS de gerenciamento é transmitida pelo nó origemcontendo a nova chave Ks, cifrada com a chave mestra Km, e o novo vetor IV, cifrado com anova chave Ks. A PDU chega no nó destino e a subcamada SSCS recebe a SDU com as chavese o valor do campo CPCS-UU indicando que é uma SDU de gerenciamento. O protocolo SSSPdecifra a chave Ks com Km, decifra IV com a nova Ks e instala os dois parâmetros nadecifração. Depois disso, entrega a chave Ks e o vetor IV para o processo Gerenciador deSegurança Local. O Gerenciador Local instala a chave Ks e vetor IV recebidos na cifração. Emseguida, transmite de volta uma SDU de gerenciamento idêntica à que foi recebida. O nó origemrecebe a PDU de gerenciamento, decifra Ks com Km, decifra IV com o novo Ks, e instala osdois parâmetros na decifração, concluindo a troca. Este procedimento de troca em um sentido edepois no outro, permite uma sincronização perfeita na troca de chaves de forma a não ocorrerperda de dados devido ao uso de chaves diferentes na origem e no destino. A Figura 7.2 ilustra oprocedimento descrito.

CPCS - SDU PAD TRAILER

UU CPI Length CRC

CPCS - PDU trailer

CPCS - PDU

PAD : 0 to 47 octetsCPCS-UU : CPCS User-to-User Indication (1 octet)CPI : Common Part Indicator (1 octet)Length: Length of CPCS-SDU (2 octets)CRC: Cyclic Redundant Check (4 octets)

AAL type 5 CPCS - PDU

UU = SDU payload type

0 : Encrypted User Data (no segmentation)1 : Encrypted User Data (first segment)2 : Encrypted User Data (second segment)4 : EKm(Ks), EKs(VI)8 : EKs(VI)

Figura 7.1 - Formato da PDU da Subcamada CPCS

86

A ressincronização com a troca do vetor de inicialização é controlada também pelo nó origem.O procedimento é idêntico ao da troca de Ks e IV. É feito através de uma PDU degerenciamento com o campo CPCS-UU indicando PDU de ressincronização, e trocandoprimeiro em um sentido e depois no outro.

O formato destas PDUs CPCS de gerenciamento é mostrado na Figura 7.3 para um algoritmoque cifra blocos de 8 octetos (64 bits) com chaves de 16 octetos (128 bits), como o algoritmoIDEA.

7.3 Protocolo de Segurança SSSP

A Subcamada de Convergência Específica do Serviço (SSCS) faz a cifração das PDUs quechegam na camada AAL5 oriundas das camadas superiores, e decifra as PDUs que chegam nasubcamada SSCS oriundas da Parte Comum da Subcamada de Convergência (CPCS). Alémdisso, identifica e processa PDUs especiais de gerenciamento de chaves. O protocolo SSSP édefinido de forma a prover as funções necessárias para realizar estes serviços.

Cada circuito virtual deve ser completamente independente, com sua própria chave Ks e seupróprio vetor IV, para facili tar a sincronização, aumentar a segurança e simpli ficar a troca dechaves. Ou seja, o fluxo de dados em cada ponto de acesso ao serviço (SAP) da camada AAL5é cifrado ou decifrado de forma totalmente independente de outros SAPs, utili zando uma chavede sessão e um vetor de inicialização que não são utili zados em qualquer outro SAP. O ponto deacesso ao serviço é identificado pelo número do circuito virtual definido no estabelecimento daconexão.

LocalSecurity

ManagementEntity

LocalSecurity

ManagementEntity

SSCS CPCS SSCSCPCS

Ks, IV Ks, IV

Ks, IV

Management CPCS-PDU

Management CPCS-PDU

Source Node Destination Node

Figura 7.2 - Troca de Chave de Sessão e Vetor de Inicialização através de PDUs deGerenciamento

EKm(Ks) TRAILER

TRAILER

EKs(VI)

EKs(VI)

PAD

PAD

8 octets

8 octets16 octets

8 octets

16 octets 8 octets

32 octets

UU = 2

UU = 4

(a) session key change PDU

(b) Resynchronization PDU

Figura 7.3 - PDUs CPCS de Gerenciamento de Chaves

87

A Figura 7.4 ilustra a estrutura da subcamada SSCS com a entidade do protocolo SSSP com asfunções necessárias ao serviço de segurança confidencialidade dos dados.

O SSSP tem uma interface com a camada superior ou com uma aplicação que se comunicadireto com a camada AAL5, tem uma interface com a subcamada CPCS. A entidade doprotocolo SSSP tem também uma interface com o gerenciamento de camada da subcamadaSSCS. Através dela interage a entidade de gerenciamento de segurança local no plano degerenciamento. Esta interface permite receber ou enviar parâmetros de segurança locais epermite a troca de dados de gerenciamento entre entidades pares de gerenciamento.

7.3.1 PrimitivasO protocolo SSSP tem duas primitivas de serviço na interface com o usuário e duas primitivasde serviço na interface com o gerenciamento de camada:

AAL-UNITDATA.request(UserData) - Usada para transmitir dados do usuário local para ousuário remoto com cifração;

AAL-UNITDATA.indication(UserData) - Usada para receber os dados do usuário remotodecifrados;

AALM-UNITDATA.request(ManagementData) - Usada para transmitir dados degerenciamento da entidade de gerenciamento local para a entidade de gerenciamento remota.

AALM-UNITDATA.indication(ManagementData) - Usada para receber dados degerenciamento da entidade de gerenciamento remota.

Figura 7.4 - Estrutura da Subcamada de Segurança SSCS

88

O parâmetro UserData contém os dados do usuário até o tamanho máximo igual ao tamanhomáximo da SDU da subcamada CPCS. O parâmetro ManagementData contém os dados degerenciamento até o tamanho máximo igual ao tamanho máximo da SDU da subcamada CPCS.

7.3.2 Formato das PDUs e Comportamento do Protocolo SSSPPara simpli ficar a especificação do protocolo SSSP, o algoritmo simétrico de bloco tem asmesmas características do IDEA2. Uma PDU que chega na camada AAL5, oriunda dascamadas superiores, é tratada pelo serviço de segurança SSSP na subcamada SSCS. A PDU,que passa a ser uma SSSP-SDU, deve ser acrescida de um campo de octetos de preenchimento(Padding octets - PAD) para que o comprimento da SDU se torne sempre múltiplo de 8 octetos.Desse modo, a SDU pode ser dividida em um número inteiro de blocos de 8 octetos para ocifrador de blocos. O último octeto de preenchimento é usado para indicar o tamanho do campode PAD, nos três últimos bits (Figura 7.5). O campo de PAD é sempre acrescentado, mesmoque a SSSP-SDU já tenha tamanho múltiplo de 8 octetos, e neste caso o campo fica comtamanho de 8 octetos. Para melhorar a segurança, evitando o ataque por “claros conhecidos”[Stalli ngs, 1995], os octetos de preenchimento devem ser desconhecidos e podem ser gerados apartir de alguma função de geração de números aleatórios por software (função random).

O cifrador de bloco cifra a SDU em blocos de 8 octetos em modo Cypher Block Chaining.Cada bloco cifrado é concatenado com o bloco anterior para gerar a SSSP-PDU (Figura 7.6).Esta PDU passa a ser uma CPCS-SDU na subcamada CPCS. Se, por causa do campo de PAD,a PDU ficar com tamanho maior que o permitido para a CPCS-SDU, a PDU tem que serdividida em dois segmentos. O primeiro segmento fica com o tamanho máximo permitido e osegundo segmento fica com os octetos excedentes. Para controlar a segmentação e remontagemda SSSP-PDU, o protocolo SSSP utili za o campo CPCS-UU da PDU da subcamada CPCS(Figura 7.1) para indicar se houve ou não segmentação e o número do segmento:

CPCS-UU = 0 : PDU não segmentadaCPCS-UU = 1 : 1o segmento da PDUCPCS-UU = 2 : 2o segmento da PDU

2 Cifra blocos de 64 bits com chaves de 128 bits

SSSP - SDU PAD

octet indicates length of PAD

SSSP - PDU (n x 8 octets)

PAD: 0 to 7 octetsN: number of PAD octets (3 bits)

0 0 0 N0 0

Length

Figura 7.5 - Formato da PDU do Protocolo de Segurança SSSP

89

A SSSP-PDU passa para a subcamada CPCS através de um parâmetro da primitiva CPCS-UNITDATA.invoke. Outro parâmetro indica o valor para o campo CPCS-UU, definindo se aPDU é de gerenciamento de chaves ou de dados e, se for de dados, se houve ou nãosegmentação.

No destino, a SSSP-SDU chega na subcamada SSCS através de um parâmetro da primitivaCPCS-UNITDATA.signal. O valor do campo CPCS-UU, indicando o tipo de PDU, tambémpassa para a entidade do protocolo SSSP em um parâmetro daquela primitiva. Se não houvesegmentação, o protocolo SSSP decifra a SDU. Se houve segmentação, o protocolo SSSParmazena o primeiro segmento, e quando receber o segundo segmento faz a remontagem edepois a decifração. Depois da decifração, o protocolo SSSP retira o campo de PAD e gera umaSSSP-SDU que é passada para a camada superior (Figura 7.7).

SSSP-SDU

PAD

SSSP-PDU (16 octets)

CPCS-PDUCPCS-SDU PAD TRAILER

AddSSSP PAD

BlockEncryption

BlockEncryption

AddCPCS PAD and Trailer

PL

8 octets 8 octets

PAD Length

Figura 7.6 - Exemplo de PDUs SSSP e CPCS na Transmissão

SSSP-SDU

PAD

SSSP-PDU (16 octets)

CPCS-PDUCPCS-SDU PAD TRAILER

RemoveSSSP PAD

BlockDecryption

BlockDecryption

RemoveCPCS PAD and Trailer

PL

8 octets 8 octets

Figura 7.7 - Exemplo de PDUs SSSP e CPCS na Recepção

90

Uma SDU para gerenciamento de chaves, contendo chave de sessão e vetor de inicialização,pode ser gerada pelo Gerenciador de Segurança Local, que é uma entidade do plano degerenciamento, e enviada através da primitiva de gerenciamento de camada AALM-UNITDATA.request. Esta SDU é transmitida ao destino como uma PDU CPCS degerenciamento de chaves. Este tipo de SDU é cifrada na origem e decifrada no destino peloSSSP utili zando um procedimento diferente do que é usado com os dados. A primitiva degerenciamento AALM-UNITDATA.indication entrega a SDU à entidade de gerenciamento desegurança local no destino. Na SDU de gerenciamento não são acrescentados octetos depreenchimento (PAD) e o modo de cifração e decifração é o Electronic Code Book. Além disso,é usada a chave mestra Km para cifrar a chave de sessão Ks e a nova chave Ks para cifrar ovetor de inicialização IV. A SDU de gerenciamento é interpretada localmente (na subcamadaSSCS) na transmissão e na recepção pelo protocolo SSSP, para instalar a chave Ks e o vetor IVno cifrador do nó origem e no decifrador do nó destino. PDUs de gerenciamento são sempretransmitidas de uma entidade de gerenciamento na origem para outra entidade de gerenciamentono destino. Dessa forma, a entidade de gerenciamento no destino recebe Ks e IV e poderetransmiti-los no sentido da origem, para completar a troca destes parâmetros no cifrador do nódestino e no decifrador do nó origem. Procedimento semelhante é usado também pararessincronização com a troca de IV.

A entidade do protocolo SSSP permite que a chave se sessão e o vetor de inicialização sejaminstalados diretamente pela entidade de gerenciamento de segurança local na subcamada SSCS(Figura 7.8), durante o procedimento de estabelecimento de conexão (instalação inicial). Aentidade do protocolo SSSP recebe estes parâmetros e instala no cifrador e no decifrador.

O comportamento do protocolo SSSP é especificado através de diagramas SDL [Z.100, 1993]no apêndice B.

Figura 7.8 - Instalação Inicial de Chave de Sessão e Vetor de Inicialização

91

Capítulo 8

Distr ibuição de Chaves Utili zando SNMPv2

8.1 Introdução

Neste Capítulo é apresentada uma proposta de utili zação do padrão SNMPv2 para modelar oServidor de Autenticação e de Chaves (AKS) e o Gerenciador de Segurança Local e deutilização das mensagens de sinalização para transportar as mensagens SNMPv2.

No Capítulo 4 é descrito como as informações de segurança podem ser transportados atravésdas mensagens de sinalização dentro de Elementos de Informação. As mensagens de conexãorealizam apenas a tarefa de entregar as informações no destino. No campo de parâmetros decada Elemento de Informação, as informações de segurança devem ter uma estrutura, ordem ecodificação definidas, além de outras informações sobre o conteúdo para que as entidades degerenciamento de chaves possam reconhecer e tratar as informações adequadamente.Basicamente é necessário um protocolo gerenciamento de chaves. Este protocolo pode ser umprotocolo de gerenciamento de redes. Enquanto o protocolo de distribuição de chaves define osprocedimentos de mais alto nível do gerenciamento de chaves, o protocolo de gerenciamento derede define os procedimentos de troca de dados entre as entidades de gerenciamento de chaves.

O protocolo mais utili zado para gerenciamento de redes é o SNMP, que é adequado para estaaplicação. A vantagem na utili zação do SNMP está na sua estrutura básica simples e eficiente.As operações definidas neste protocolo permitem implementar a distribuição das chaves entre osnós através de mensagens SNMP. Através das operações, PDUs e variáveis da MIB, definidosno SNMP, as entidades de gerenciamento de chaves podem reconhecer os dados que chegam nasmensagens de sinalização e determinar qual operação executar segundo o protocolo dedistribuição de chaves.

Os Servidores de chaves podem ser modelados como gerentes SNMP. Em cada nó origem, oprocesso que controla a distribuição de chaves (Gerenciador de Segurança Local) pode sermodelado como um agente SNMP inteligente. Neste modelo, o agente tem dois papéis. É agentedo sistema de segurança local e é agente procurador do sistema de segurança do nó destino(Figura 8.1). Em cada nó destino, o mesmo processo agente funciona como um dispositivo nãoSNMP controlado pelo agente SNMP no nó origem. O gerente recebe notificação de cadaagente indicando que foi gerada uma nova chave pública, ou que não existe chave mestra ou desessão disponível, e executa o procedimento de geração de chaves e de autenticação. Emseguida, envia os parâmetros em valores das variáveis para serem alterados na MIB do agente.O agente além de armazenar os valores na MIB local realiza um processamento sobre os valorese atua como agente procurador enviando os parâmetros de segurança para o nó destino.

92

8.2 Mapeamento do Protocolo de Distribuição de Chaves emOperações SNMP

Como é necessário troca de informações entre os gerentes, é utili zado o protocolo SNMP versão2. O protocolo de distribuição de chaves pode ser mapeado para o SNMPv2 utili zando as PDUsSNMPv2-Trap, SetRequest, InformRequest e Response, e variáveis definidas em uma MIB desegurança, específica para esta aplicação (Capítulo 2).

A Figura 8.2 ilustra a troca de chaves públicas entre um nó qualquer e o Servidor de Chaves,após a geração das chaves do algoritmo de chave pública.

A Figura 8.3 ilustra a distribuição de chaves e autenticação. O nó A é o nó origem e o nó B é nódestino.

Agent/Proxy Agent

(source node)

Devicemanaged

byProxy Agent(Destination

Node)

Manager(AKS)

Figura 8.1 - Modelo de Gerenciamento

NÓn

AKSIDn, Pn

IDk,Pk

IDk, H(Pk)

IDn, H(Pn)

(1) (2)

Figura 8.2 - Distribuição de Chave Pública

93

Na descrição das operações SNMP a Figura 8.2 e a Figura 8.3 são utili zadas como referência.As interações entre agente e gerente são feitas através de PDUs Trap, SetRequest e Response.As PDUs são encapsuladas em mensagens SNMP que são enviadas utili zando algum protocolode transporte que pode ser as mensagens do protocolo Q.2931. As interações entre gerentes sãofeitas através de PDUs InformRequest e Response. As PDUs são encapsuladas em mensagensSNMP que são enviadas utili zando um protocolo de transporte. A Figura 8.4 ilustra estemodelo.

Na descrição das mensagens a seguinte notação é utilizada:

SetRequest{variável1, variável2, ..., variáveln}

InformRequest{[snmpTrapOID.0 = tipo_evento], variável1, variável2, ..., variáveln}

SNMPv2-Trap{[snmpTrapOID.0 = tipo_evento], variável1, variável2, ..., variáveln}

Response{error-status = tipo_erro, variável1, variável2, ..., variáveln}

A(agent)

AKS1(manager)

AKS3(manager)

AKS2(manager)

B

IDa, IDb, Master_Key_Req

IDk1, IDb

ASk2(IDb, Pb),

ASk2(Pk1)

ASk3(IDb, Pb),

ASk2(Pk1)

TKT, ASk2(Pk1), SKS

TKT, EPb(Km), EKm(Ks), EKs(IV), ASk2(Pk1)

TKT = ASk1(IDa, Pa, IDb, Pb, EPa(Kmi, T), EPb(Kmi, T))

SKS = EKmi(Ksi1,T),EKmi(Ksi2,T),..,EKmi(EKsin,T)

domain 1

domain 2

(1)

(2)(3)

(4)(5)

(6)

(7)

IDk3, IDb, ASk3(Pk1)

(8)

ASb(T)

Figura 8.3 - Distribuição de Chave e Autenticação

SNMPv2-Trap

SetRequest

Response

InformRequest

Response

Agent(source node)

Manager(AKS)

Manager(AKS)

Figura 8.4 - Operações Agente-Gerente e Gerente-Gerente

94

onde var iáveli é uma variável definida na MIB, [snmpTrapOID.0 = tipo_evento] indica quesnmpTrapOID.0 contém o object identifier de tipo_evento conforme definido na MIB, eerror-status = tipo_erro significa que a variável error-status é igual a tipo_erro. tipo_eventopode ser igual a newPubKey, noMasterKey, noSessionKey e noPubKey. tipo_erro pode ser umdos erros definidos para error-status no formato da PDU SNMPv2.

8.3 MIB de Segurança

As variáveis definidas na MIB de segurança correspondem a cada um dos parâmetros desegurança necessários à distribuição de chaves, que são os objetos gerenciados. A MIB desegurança tem dois módulos. Um módulo que corresponde aos objetos de segurança gerenciadospelo agente (securityMIB) e um módulo que corresponde aos objetos necessários aogerenciamento distribuído, para as interações gerente-gerente (securityM2M). São definidostambém na MIB os eventos de segurança usados na operações SNMPv2-Trap e InformRequest.Os dois módulos e os eventos são definidos em ASN.1 [Stalli ngs, 1993] usando a SMIv2[RFC1902, 1996] no Apêndice C. Para estas definições as chaves públicas são de 2048 bits(256 octetos) e as chaves simétricas são de 128 bits (16 octetos) e o algoritmo simétrico cifrablocos de 64 bits (8 octetos).

É relacionada abaixo cada uma das variáveis, em cada módulo, e o parâmetro correspondenteno protocolo de distribuição de chaves, além do eventos usados nas PDUs SNMPv2-Trap eInformRequest:

MÓDULO securityMIB

localId -- ID

localPubKey -- P

aksPubKey -- PK

securityTable -- Tabela de segurança do agente com as seguintes colunas:

sourceId -- IDA

destinId -- IDB

authTicket -- TKT

authPubKey -- ESK2(PK1)

sessionKeyTable -- Tabela de chaves de sessão com as seguintes colunas:

nodeId -- IDA

privAksSessionKey -- EKmi1(Ksi1,T), EKmi2(Ksi2,T), ...

MÓDULO securityM2M

authPubKeyTable -- Tabela de segurança do gerente com as seguintes colunas:

remoteId -- IDB

aksId -- IDKx

authLocalPk -- ESKx(PK1)

remAuthLocalPk -- ESK2(PK1)

authNodePubKey -- ESK2(IDB,PB)

EVENTOS de segurança

95

securityNotification -- eventos de segurança

newPubKey -- criação de uma nova chave pública

noMasterKey -- chave mestra ficou inválida

noSessionKey -- todas as chaves de sessão já foram usadas e estão fora devalidade

noPubKey -- gerente não tem a chave pública solicitada

A MIB só armazena os valores que trafegam pela rede e nenhum parâmetro secreto éarmazenado sem cifração. Toda informação secreta contida nas variáveis está cifrada. Por isto,a área de armazenamento da MIB não precisa de mecanismos especiais de proteção contraleitura, já que, quando as chaves mestra e de sessão são decifradas, em seguida são transferidaspara as tabelas seguras com proteção contra acesso não autorizado.

A segurança da MIB não impede que através de um ataque ativo os valores sejam modificadosde forma a interromper o serviço. Para evitar este tipo de ataque, que não compromete asegurança mas compromete a confiabili dade, devem ser utili zados outros mecanismos desegurança como os que estão sendo definidos para o SNMPv2 em substituição aos mecanismosde segurança originais deste protocolo.

8.4 Operações no Procedimento de Geração de Chaves

Após a geração da chave pública e da chave secreta no nó n (Figura 8.2), o agente deste nóenvia para o Servidor AKS o identificador do nó (IDn) e sua chave pública (Pn). Isto é feitoatravés do envio de um SNMPv2-Trap do agente ao gerente com as variáveis localId elocalPubKey. A variável snmpTrapOID.0 do SNMPv2-Trap contém o object identifier doevento newPubKey.

agente → gerente: SNMPv2-Trap{[snmpTrapOID.0=newPubKey],localId,

localPubKey}

O gerente armazena o identificador e a chave recebidos em sua tabela de chaves públicas, eenvia ao agente sua chave pública (PK) na variável aksPubKey através de uma PDU SetRequest.Se não houve qualquer erro, o agente responde indicando noError na variável error-status deuma PDU Response:

gerente → agente: SetRequest{aksPubKey}

agente → gerente: Response{error-status=noError, aksPubKey }

A Figura 8.5 ilustra esta interação entre as entidades SNMP.

96

8.5 Operações no Procedimento de Distribuição de ChaveMestra

Se não existir uma chave mestra válida para iniciar uma comunicação segura, o agente do nóorigem A envia ao gerente no Servidor AKS1 os identificadores IDA e IDB. Isto é feito atravésdo envio de uma PDU SNMPv2-Trap com as variáveis sourceId e destinId. A variávelsnmpTrapOID.0 do SNMPv2-Trap contém o object identifier do evento noMasterKey.

agente → gerente AKS1: SNMPv2-Trap{[snmpTrapOID.0=noMasterKey],sourceId,

destinId}

Se o nó destino B pertencer ao domínio do Servidor de Chaves, o gerente utili za o valor desourceId e destinId para recuperar as chaves públicas do nó origem e do nó destino. Em seguidagera as chaves, prepara o Ticket (TKT) e as chaves de sessão. Depois envia ao agente asvariáveis destinId, authTicket, e privAksSessionKey contendo respectivamente IDB, TKT, e{ EKmi1(Ksi1,T), EKmi2(Ksi2,T), ...} , através de uma PDU SetRequest. Se não houver qualquererro, o agente responde indicando noError na variável error-status de uma PDU Response:

gerente AKS1 → agente: SetRequest{destinId, authTicket, privAksSessionKey}

agente → gerente AKS1: Response{error-status=noError, destinId, authTicket,

privAksessionKey }

Se o nó B não pertencer ao domínio do gerente AKS1, este envia ao gerente AKS3 seuidentificador (IDK1) e o identificador do destino (IDB), solicitando a chave pública do destino(PC) e a autenticação da chave pública local (ESK2(PK1)). Isto é feito através do envio de umaPDU InformRequest com as variáveis aksId, remoteId, authLocalPk, remAuthLocalPk eauthNodePubKey. A variável snmpTrapOID.0 do InformRequest contém o object identifier doevento noPubKey.

gerente AKS1 → gerente AKS3: InformRequest{[snmpTrapOID.0=noPubKey] aksId,

remoteId, authLocalPk, remAuthLocalPk,

authNodePubKey}

Se o Servidor AKS3 não tiver a chave solicitada, o procedimento é repetido para o gerenteAKS2. Este procedimento poderia se repetir até que a solicitação chegasse ao Servidor que tema chave pública do nó destino em sua tabela de chaves públicas.

Source Node(Agent)

Server(Manager)

SNMPv2-Trap

SetRequest

Response

time

Figura 8.5 - Operações SNMP na Distribuição das Chaves Públicas

97

gerente AKS3 → gerente AKS2: InformRequest{[snmpTrapOID.0=noPubKey], aksId,

remoteId, authLocalPk, remAuthLocalPk,

authNodePubKey}

O gerente AKS2 recebe a PDU InformRequest e utili za o valor de remoteId para recuperar achave pública do nó B em sua tabela de chaves públicas. Utili za o valor de aksId para recuperara chave pública do Servidor AKS3 que enviou o InformRequest (Pk3) e obter a chave pública doServidor AKS1 (PK1). Em seguida, autentica o identificador e a chave do nó B (ESK2(IDB,PB)) ea chave pública do Servidor AKS1 (ESK2(PK1)). Depois envia ao gerente AKS3, uma PDUResponse com as mesmas variáveis recebidas, aksId, remoteId, authLocalPk, remAuthLocalPke authNodePubKey, atualizando os valores de remAuthLocalPk e de authNodePubKey comESK2(PK1) e ESK2(IDB,PB), em relação aos valores recebidos no InformRequest.

gerente AKS2 → gerente AKS3: Response{aksId, remoteId, authLocalPk,

remAuthLocalPk, authNodePubKey }

O gerente AKS3 recebe a PDU Response, decifra e obtém IDB e PB, e calcula ESK3(IDB,PB).Depois envia ao gerente AKS1, uma PDU Response com as mesmas variáveis recebidas, aksId,remoteId, authLocalPk, remAuthLocalPk e authNodePubKey, atualizando os valores deremAuthLocalPk e de authNodePubKey com ESK2(PK1) e ESK3(IDB,PB) em relação aos valoresrecebidos no InformRequest.

gerente AKS3 → gerente AKS1: Response{aksId, remoteId, authLocalPk,

remAuthLocalPk, authNodePubKey }

O gerente AKS1 ao receber a PDU Response, decifra e obtém a chave pública do nó destino(PB), gera as chaves, e prepara o Ticket, e as chaves de sessão. Depois envia ao agente no nó Aas variáveis destinId, authTicket, e privAksSessionKey contendo IDB, TKT, ESK2(PK1) e{ EKmi1(Ksi1,T), EKmi2(Ksi2,T), ...} , através de uma PDU SetRequest. Se não houver qualquererro, o agente responde indicando noError na variável error-status de uma PDU Response

gerente AKS1 → agente: SetRequest{destinId, authTicket, authPubKey,

privAksSessionKey}

agente → gerente AKS1 : Response{error-status=noError, destinId, authTicket,

authPubKey, privAksSessionKey }

No caso de nenhum gerente possuir a chave pública do nó destino, o último gerente envia umaPDU Response indicando resourceUnavailable na variável error-status:

gerente AKS2 → gerente AKS3: Response{error-status= resourceUnavailable, aksId,

remoteId, authLocalPk, remAuthLocalPk,

authNodePubKey }

O mesmo procedimento é repetido por cada gerente. O gerente inicial envia um SetRequest ,com valor zero na variáveis destinId, authTicket, privAksSessionKey:

gerente AKS1 → agente: SetRequest{destinId=0, authTicket=0,

privAksSessionKey=0}

98

agente → gerente AKS1: Response{error-status=noError, destinId=0, authTicket=0,

privAksSessionKey=0}

Um mesmo gerente pode fazer várias solicitações de chaves para destinos diferentes ouservidores diferentes, enviando várias PDUs InformRequest. As respostas podem chegar emqualquer ordem e o Servidor pode controlar a correspondência entre as PDUs InformRequest eas PDUs Response através do request-id de cada mensagem.

A Figura 8.6 ilustra estas interações entre as entidades SNMP.

8.6 Operações no Procedimento de Distribuição de Chavesde Sessão

Se não existir uma chave de sessão válida para iniciar uma comunicação segura, o agente do nóA envia IDA e IDB ao gerente AKS1. Isto é feito através do envio de uma PDU SNMPv2-Trapcom as variáveis sourceId e destinId. A variável snmpTrapOID.0 do SNMPv2-Trap contêm oobject identifier do evento noSessionKey. O gerente gera as chaves, cifra e envia ao agente asvariáveis nodeId, e privAksSessionKey contendo respectivamente IDB, e {EKmi1(Ksi1,T),EKmi2(Ksi2,T), ...} , através de uma PDU SetRequest. Se não houve qualquer erro, o agenteresponde indicando noError na variável error-status de uma PDU Response:

agente → gerente:SNMPv2-Trap{[snmpTrapOID.0=noSessionKey],sourceId,destinId}

gerente → agente: SetRequest{nodeId, privAksSessionKey}

agente → gerente: Response{error-status=noError, privAksSessionKey}

A Figura 8.6 ilustra estas interações.

Source Node(Agent)

AKS1(Manager)

AKS3(Manager)

AKS2(Manager)

SNMPv2-Trap

SNMPv2-Trap

InformRequest

InformRequest

Response

Response

Response

Response

SetRequest

SetRequest

Master KeyDistribution

Session KeyDistribution

time

Figura 8.6 - PDUs SNMP na Distribuição de Chaves Secretas

99

8.7 Transporte de Mensagens SNMPv2 através do ProtocoloQ.2931

Em redes TCP/IP as mensagens SNMP são transportadas utili zando o protocolo de transporteUDP. No entanto, outros protocolos pode ser utili zados e alguns estão padronizados em[RFC1906, 1996]: DDP (Datagram Delivery Protocol), IPX (Internet Packet eXchange), e OSICLTS (Connectionless-mode Transport Service). Para o caso de redes ATM, o ATM Forumpadronizou o uso de SNMP como o protocolo da camada AAL5 [UNI ILMI, 1996].

No caso da distribuição de chaves utili zando “pseudo-conexões”, conforme definido na seção5.5, as mensagens SNMP podem ser transportadas dentro dos Elementos de Informação deUsuário. Em cada Elemento de Informação definido no Capítulo 5, no campo Parameters, aoinvés de se colocar diretamente os parâmetros de segurança, pode ser inserida uma mensagemSNMP com as variáveis que contêm o valor desses parâmetros.

A Figura 8.7(a) mostra o formato de um Elemento de Informação de Usuário com umamensagem SNMP genérica. A Figura 8.7(b) mostra o Elemento de Informação Session KeyResponse com uma mensagem SNMP no campo de parâmetros, encapsulando uma PDUSetRequest.

Information element identifier Information element identifier

1 1Coding

standardCoding

standardIE instruction field IE instruction field

Length of informationelements

Length of informationelements

User SpecificInformation Element(SNMP Message)

Session Key ResponseInformation Element

(SetRequest SNMP Message)

privAksSessionKey

versionversion

communitycommunity

PDU type = SetRequestPDU type

request-idrequest-id

error-status

0error-index

0

name_1

value_1

name_2

value_2

name_n

value_n

IDb

. . .

nodeId

EKmi1(Ksi1,T),EKmi2(Ksi2,T),. . .

(a) (b)

Figura 8.7 - Mensagem SNMP Transportada por um Elemento deInformação de Usuário

100

Capítulo 9

Conclusões

A arquitetura proposta permite flexibili dade na utili zação do sistema de segurança. É possívelmesclar computadores que não utili zam o sistema de segurança, com computadores que podemou não utili zá-lo, ou com computadores que sempre o utili zam. Dessa forma, o sistema não crialimitações ao seu emprego e possibili ta a escalabili dade, permitindo expandir a segurança deacordo com as necessidades. Além disso, a qualidade da segurança do sistema só depende daqualidade dos algoritmos criptográficos utili zados. Se forem utili zados algoritmos seguros, osistema também será seguro. Por causa destas características este trabalho pode ser a base paraimplementação de um sistema completo de segurança em redes ATM.

As minhas contribuições neste trabalho são:

• Proposta de um novo protocolo de distribuição de chaves distribuído;

• Proposta de um mecanismo de distribuição de chaves através de mensagens desinalização;

• Proposta de um protocolo de segurança para a subcamada SSCS da camada deadaptação ATM;

• Definição de um esquema de gerenciamento de chaves utili zando o padrão SNMPv2para modelar as entidades de gerenciamento.

• Proposta de uma arquitetura funcional para segurança nas estações de trabalhooperando em rede ATM

Os serviços de segurança foram propostos para garantir a segurança da transmissão de dados nacamada de adaptação AAL5 mas é possível estender a segurança para outras camadas deadaptação de forma a fornecer os serviços de segurança para imagens, vídeo e voz.

O sistema de gerenciamento de segurança foi especificado para realizar a função principal dogerenciamento de segurança que é a distribuição de chaves de forma segura, mas pode serfacilmente estendido para incluir funções de envio de notificações de segurança ao Servidor deChaves, como falha na autenticação, chave repetida e outros. A infra-estrutura básica que foiespecificada já tem funcionalidades para bloquear a comunicação no caso de quebra dasegurança (protocolo SSSP).

O sistema de segurança foi especificado apenas para conexões ponto-a-ponto. O trabalho podeser estendido para incluir conexões ponto-a-multiponto no sistema de segurança.

A dissertação abre a possibili dade de elaboração de outros trabalhos de graduação ou mestradoestendendo ou complementando o trabalho realizado:

• Especificação detalhada dos componentes da arquitetura como o Servidor deAutenticação e de Chaves, o Gerenciador de Segurança Local, a API de Controle deChamada, e o Gerador de Chaves Assimétricas utili zando uma ferramenta como oSDL [Z.100, 1993];

101

• Implementação do protocolo SSSP e do módulo Gerenciador de Segurança Localpara uma plataforma específica com distribuição de chaves manual;

• Aprimoramento do trabalho sobre gerenciamento distribuído de chaves comtratamento de falhas e análise de performance.

Reunindo os trabalhos propostos acima e fazendo a implementação de cada um doscomponentes do sistema para uma plataforma específica, obtém-se um sistema de segurançaoperacional e confiável para redes ATM. É um trabalho de grande porte, de muita utili dade se ofuturo confirmar a consolidação da tecnologia ATM como principal tecnologia de rede.

Pude observar, durante a fase de levantamento bibliográfico, que na área de segurança de redesde computadores o número de publicações é relativamente menor do que outras áreas depesquisa da Ciência da Computação. Mas o interesse nessa área (e conseqüentemente aquantidade de trabalho) vem crescendo nos últimos anos devido às ações nocivas provocadaspor especialistas em invasão de computadores e por causa do crescente comércio eletrônico.Ainda assim, a maior parte dos resultados acaba sendo utili zada para solucionar o problema desegurança em aplicativos. Por esses motivos, e devido à importância que as redes decomputadores estão adquirindo em escala global, e também por causa da importância que asegurança tem para as redes, considero que esta dissertação traz uma contribuição valiosa.

Outro aspecto importante é a divulgação do trabalho. Como a dissertação aborda diversosassuntos que tem um certo grau de estanqueidade, surgirão como subprodutos trabalhos emsegurança de redes, protocolos e gerenciamento de redes para divulgação em congressos.

Esta dissertação permitiu avaliar na prática as dificuldades para incorporar um sistema desegurança confiável em um sistema de comunicação que não tem previsão específica paraserviços deste tipo. O sistema só é possível de ser realizado, com um certo grau de dificuldade,porque os protocolos do ATM e de sinalização tem facili dades para acréscimo de funções.Considerando que o problema da segurança em redes não é um problema novo, e que atecnologia ATM é recente, os serviços de segurança poderiam ter sido previstos no modelo.Teria havido um ganho enorme de funcionalidade e aceitação de mercado se, no projeto dosprotocolos ATM, tivessem sido previstas facili dades específicas para implementação desegurança. Hoje o Forum ATM tem um grupo que começou a trabalhar neste assuntorecentemente [Chen et al., 1996], ou seja, a questão da segurança continua sendo tratada comouma questão não prioritária pelos organismos de padronização.

102

Bibliografia

[Alles, 1995] Anthony Alles. ATM Internetworking. Cisco Systems Inc., May 1995.

[Black, 1995] Uyless Black. ATM: Foundations for Broadband Networks. Prentice Hall , 1a

Edição, 1995.

[Brisa, 1993] BRISA - Sociedade Brasileira de Sistemas Abertos. Gerenciamento Redes - UmaAbordagem de Sistemas Abertos. Makron, 1993.

[Certicom, 1996] Certicom Corp. Concepts in Information Security. 1996.

[Chen et al., 1996] Thomas M. Chen, Steve S. Liu, David Wang, Vijay K. Samalan, Michael J.Procanik, Dinyar Kavouspour. Monitoring and Control of ATM Networks Using Special Cells.IEEE Network, vol. 10 no. 5, pp. 28-38. September/October 1996.

[Cheswick e Bellovin, 1994] Willi am R. Cheswick, Steven M. Bellovin. Firewalls naInternet Security - Repelling the wily Hacker. Addison Wesley, 1994.

[Chuang, 1995] Shaw-Cheng Chuang. Securing ATM Networks. 18th October 1995.

[Denning e Sacco, 1981] D. E. Denning, G. M. Sacco. Timestamps in Key DistributionProtocols. Communications of the ACM, v.24, n. 8, pp.533-536. August 1981.

[Diff ie e Hellman, 1976] W. Diff ie, H. E. Hellman. New Directions in Cryptography. IEEETransactions on Information Theory, no. IT22-(6), pp. 644-654, 1976.

[Elgamal et al., 1996] Taher Elgamal, Jeff treuhaft, Frank Chen. Securing Communications onthe Internet and over the Internet. Netscape communications Corp., July 1996.

[Halsall , 1996] Fred Halsall . Data Communications, Computer Networks and Open Systems.Addison Wesley, 4a Edição, 1996.

[I .150, 1995] ITU-T Recommendation I.150. B-ISDN Asynchronous TransferModeFunctional Characteristics. 1995.

[I .321, 1991] ITU-T Recommendation I.321. B-ISDN Protocol Reference Model And ItsApplication. 1991.

[I.361, 1993] ITU-T Recommendation I.361. B-ISDN ATM Layer Specification. 1993.

[I .362, 1993] ITU-T Recommendation I.362. B-ISDN ATM Adaptation Layer (AAL) FuncionalDescription. 1993.

[I .363, 1993] ITU-T Recommendation I.363. B-ISDN Adaptation Layer (AAL) Specifi cation.1993.

[ISO7498, 1989] Ref. No. ISO 7498/2. Information Processing Systems - Open SystemsInterconnection - Basic Reference Model - Adendum 2: Security Architecture. 1989.

[Knuth, 1981] Donald E. Knuth. The Art of Computer Programming Vol. II - SeminumericalAlgorithms. Addison-Wesley, 2a Edição, 1981.

[Nam, 1995] KookJim Nam. An Implementation of ATM Signalling Protocol. September 1995.

[Needham e Schroeder, 1978] Roger M. Needham, Michael D. Schroeder. Using Encryption forAuthentication in Large Netwoks of Computers. Communications of the ACM, v.21, n.12, pp993-999. December 1978.

103

[Neuman e Stubblebine, 1993] B. Cli fford Neuman, Stuart G. Stubblebine. A Note on the Useof Timestamps as Nonces. Operating Systems Review, 27(2), pp. 10-14, April 1993.

[Q.2100, 1993] ITU-T Recommendation Q.2100. B-ISDN Signalli ng ATM Adaptation LayerOverview Description. 1993.

[Q.2110, 1993] ITU-T Recommendation Q.2110. B-ISDN Adaptation Layer - Service Specifi cConnection Oriented Protocol (SSCOP). 1993.

[Q.2130, 1993] ITU-T Recommendation Q.2130. . B-ISDN Adaptation Layer - Service Specifi cCoordination Function for Support of Signalli ng at the User-to-Network Interface (SSCF ATUNI). 1993.

[Q.2931, 1995] ITU-T Recommendation Q.2931. Broadband Integrated Services DigitalNetwork (B-Isdn) – Digital Subscriber Signalli ng System No. 2 (Dss 2) – User-NetworkInterface (Uni) Layer 3 Specification For Basic Call/Connection Control. 1995.

[Q.2957cl1, 1995] ITU-T Recommendation Q.2957. Stage 3 Description for AdditionalInformation Transfer Supplementary Services using B-ISDN Digital SubscriberSignalli ng System No. 2 (Dss 2) – Basic Call Clause 1 – User-to-user signalli ng (UUS).1995.

[Q.2971, 1995] ITU-T Recommendation Q.2971. Broadband Integrated Services DigitalNetwork (B-Isdn) – Digital Subscriber Signalli ng System No. 2 (Dss 2) – User-NetworkInterface Layer 3 Specification For Point-To-Multipoint Call/Connection Control. 1995.

[RFC1155, 1990] Network Working Group, Request for Comments: 1155. Structure andIdentification of Management Information for TCP/IP-based Internets. May 1990.

[RFC1157, 1990] Network Working Group, Request for Comments: 1157. A Simple NetworkManagement Protocol (SNMP). May 1990.

[RFC1213, 1991] Network Working Group, Request for Comments: 1156. ManagementInformation Base for Network Management of TCP/IP-based internets: MIB-II. May 1990.

[RFC1215, 1991] Network Working Group, Request for Comments: 1215. A Convention forDefining Traps for Using with the SNMP. March 1991.

[RFC1270, 1991] Network Working Group, Request for Comments: 1270. SNMPCommunications Services. October 1991.

[RFC1321, 1992] Network Working Group, Request for Comments: 1321. The MD5 Message-Digest Algorithm. April 1992.

[RFC1351, 1992] Network Working Group, Request for Comments: 1351. SNMPAdministrative Model. July 1992.

[RFC1451, 1993] Network Working Group, Request for Comments: 1451. Manager-to-Manager MIB. April 1993.

[RFC1483, 1993] Network Working Group, Request for Comments: 1483. MultiprotocolEncapsulation over ATM Adaptation Layer 5. July 1993.

[RFC1577, 1994] Network Working Group, Request for Comments: 1577. Classical IP andARP over ATM. January 1994.

[RFC1901, 1996] Network Working Group, Request for Comments: 1901. Introduction toCommunity-based SNMPv2. January 1996,

104

[RFC1902, 1996] Network Working Group, Request for Comments: 1902. Structure ofManagement Information for Version 2 of the Simple Network Management Protocol(SNMPv2). January 1996.

[RFC1905, 1996] Network Working Group, Request for Comments: 1905. ProtocolOperations for Version 2 of the Simple Network Management Protocol (SNMPv2). January1996.

[RFC1906, 1996] Network Working Group, Request for Comments: 1906. TransportMappings for Version 2 of the Simple Network Management Protocol (SNMPv2). January,1996.

[RFC1907, 1996] Network Working Group, Request for Comments: 1907. ManagementInformation Base for Version 2 of the Simple Network Management Protocol (SNMPv2).January 1996.

[RFC1909, 1996] Network Working Group, Request for Comments: 1909. An AdministrativeInfrastructure for SNMPv2. February 1996.

[RFC1910, 1996] Network Working Group, Request for Comments: 1910. User-based SecurityModel for SNMPv2. February 1996.

[Rose, 1996] Marshall T. Rose. The Simple Book. Prentice Hall, 2a edição Revisada, 1996.

[Schneier, 1996] Bruce Schneier. Applied Cryptography - Protocols, Algorithms, and SourceCode in C. John Willey & Sons. 2a Edição, 1996.

[Sloman 1995] Morris Sloman. Network and Distributed Systems Mangement. Addison-Wesley, 1a edição, 1995.

[Soares et al., 1995] Luiz F. G. Soares, Guido Lemos, Sérgio Colcher. Redes de Computadores- das LANs, MANs e WANs às Redes ATM. Campus, 1996.

[Stalli ngs, 1993] Willi am Stalli ngs. SNMP. SNMPv2, and CMIP - The Practical Guide toNetwork-Management Standards. Addison-Wesley, 1993.

[Stalli ngs, 1995] Willi am Stalli ngs. Network and Internetwork Security: Principles andPractice. Prentice Hall, 1995.

[Stevenson et al., 1995] Daniel Stevenson, Nathan Hill ery, Greg Bird. Secure Communicationsin ATM Networks. Communications of the ACM, v.38, n. 2, pp.45-52. February 1995.

[SunATM, 1995] Sun Microsystems Computer Company. SunATM-155 Sbus Cards Manual.Revision A, May 1995.

[T1X1.2, 1993] ANSI Technical Report T1X1.2/93-024R2. A Comparison of SONET andSDH. 1993.

[Tanenbaum, 1996] Andrew S. Tanenbaum. Computer Networks. Prentice-Hall , 3a Edição,1996.

[UNI ILMI, 1996] ATM Forum Technical Committee. Integrated Local Management Interface(ILMI) Specification Version 4.0. September, 1996.

[UNI Signalli ng, 1994] ATM Forum Technical Committee. ATM User-Network Interface(UNI) Signalling Specification Version 4.0. July 1996.

[Z.100, 1993] ITU-T Recommendation Z.100. CCITT Specification and DescriptionLanguage (SDL). 1993.

105

Apêndice A

Glossário

AAL = ATM Adaptation Layer

AAL5 = ATM Adaptation Layer Type 5

ABR = Available Bit Rate

AKS = Authentication and Key Server (Servidor de Autenticação e de Chaves)

ANSI = American National Standard Institute

API = Application Program Interface

ASN.1 = Abstract Syntax Notation.One

ATM = Asynchronous Transfer Mode

AUU = ATM-layer-user to ATM-layer-user

BER = Basic Encoding Rules

B-ISDN = Broadband Aspects of Integrated Services Digital Network

B-ISDN PRM = Protocol Reference Model of The Broadband Aspects of ISDN

BNLS = Broadband-Non-Lockink Shift

B-NT2 = Broadband Network Termination 2 for B-ISDN

CBC = Cipher Block Chainning

CBR = Constant Bit Rate

CLP = Cell Loss Priority

CLTS = Connectionless-mode Transport Service

CPCS = Common Part Convergence Sublayer

CPU = Central Processing Unit

CRC = Cyclic Redundancy Check

CS = Convergence Sublayer

DDP = Datagram Delivery Protocol

DES = Data Encryption Standard

DNS = Domain Name System

ECB = Electronic Code Book

FPS = Fast Packet Switching

GFC = Generic Flow Control

HEC = Header Error Control

106

ICMP = Internet Control Message Protocol

IDEA = International Data Encryption Algoritm

IDx = identificador do nó X

IE = Information Element

IP = Internet Protocol

IPX = Internet Packet eXchange

ITU = International Telecommunications Union

IV = Initialization Vector (vetor de inicialização)

Km = chave mestra efetiva (algoritmo simétrico)

Kmi = chave mestra inicial (algoritmo simétrico)

Ks = chave de sessão efetiva (algoritmo simétrico)

Ksi = chave de sessão inicial (algoritmo simétrico)

LAN = Local Area Network

LM = Layer Mangement

LSM = Local Security Manager

MIB = Management Information Base

NFS = Network File System

NIS = Network Information Service

OAM = Operation And Maintenance

OSI = Open Systems Interconnection

PAD = Padding Octets

PDU = Protocol Data Unit

PM = Physical Medium

PRM = Protocol Reference Model

PT = Payload Type

PVC = Permanente Virtual Circuit

Px = chave pública (algoritmo assimétrico) do nó X

QCC = Q.2931 Call Control API

QoS = Quality of Service

RFC = Request For Comment

RPC = Remote Procedure Call

SAAL = Signalling ATM Adaptation Layer

SAP = Service Access Point

SAR = Segmentation and Reassembly Sublayer

SDH = Synchronous Digital Hierarchy

107

SDL = Systems Description Language

SDU = Service Data Unit

SMI = Structure of Management Information

SNMP = Simple Network Management Service Specific

SONET = Synchronous Digital Hierarchy

SONET = Synchronous Optical Networ

SSCF = Service Specific Coordination Function

SSCOP = Service Specific Connection Oriented Protocol

SSCS = Service Specific Convergence Sublayer

SSL = Security Sockets Layer

SSSP = Service Specific Security Protocol

SVC = Switched Virtual Circuit

Sx = chave secreta (algoritmo assimétrico) do nó X

T = marca de tempo

TC = Transmission Convergence

TCP = Transmission Control Protocol

TKT = Ticket de Autenticação

UDP = User Datagram Protocol

UNI = User Network Interface

VBR = Variable Bit Rate

VC = Virtual Channel

VCC = Virtual Channel Connection

VCI = Virtual Channel Identifier

VP = Virtual Path

VPC = Virtual Path Connection

VPI = Virtual Path Identifier

108

Apêndice B

Especificação do Protocolo SSSP através deDiagramas SDL

[AAL-UNITDATA.req(MU)] [AAL-UNITDATA.ind(MU)]

[CPCS-UNITDATA.signal(ID,LP,CI,UU)][CPCS-UNITDATA.invoke(ID,LP,CI,UU)]

ToCPCS FromCPCS

FromLM ToLM

FromUser ToUser

SYSTEM SSSP (1 of 1)

S S S P

Acronyms

SSSP-Service Specific Security ProtocolLM-Layer ManagementCPCS-Common Part Convergence SublayerMU-Message UnitUU-User-to-User IndicationID-Interface DataLP-Loss PriorityCI-Congestion IndicationMD-Management Data

SSSP SDLsSystem DiagramsVersion 1.0

AALM-UNITDATA.req(MD,Type),InitKeys,ChangeKey,Stop

signalInitKeys(MasterKey,SessionKey,InitVector),ChangeKey(SessionKey,InitVector),Stop, AAL-UNITDATA.req(MU),AAL-UNITDATA.ind(MU), AALM-UNITDATA.req(MD,Type),AALM-UNITDATA.ind(MD,type),CPCS-UNITDATA.invoke(ID,LP,CI,UU),CPCS-UNITDATA.signal(ID,LP,CI,UU),SegError

AALM-UNITDATA.ind(MD,Type),SegError

109

SSSP_TX

[AAL-UNITDATA.req(MU)]

[AAL-UNITDATA.ind(MU)]

[AALM-UNITDATA.ind(MD,Type),SegError]

[CPCS-UNITDATA.signal(ID,LP,CI,UU)]

[CPCS-UNITDATA.invoke(ID,LP,CI,UU)]ToCPCS

FromCPCS

FromLM

ToLM

FromUser

ToUser

BLOCK SSSP (1 of 1)

UU=0 : normalUU=1 : SDU cifradaUU=2 : E Km(Ks),EKs(IV)

UU=4 : E Ks(IV)

Signals to/from User(parameters listed between parentheses)

AAL-UNITDATA.req(MU)AAL-UNITDATA.ind(MU)

Signals to/from CPCS(parameters listed between parentheses)

CPCS-UNITDATA.invoke(ID,LP,CI,UU)CPCS-UNITDATA.signal(ID,LP,CI,UU)

Signals to/from Layer Management(parameters listed between parentheses)

AALM-UNITDATA.req(MD,Type)AALM-UNITDATA.ind(MD,Type)

Type=2: Ks,IVType=4: IV

FromLM

[AALM-UNITDATA.req(MD,Type)]

SSSP_RX

Key_Control

Processes

SSSP_TX - transmittion protocolSSSP_RX - reception protocolCoord_SSSP - coordination of protocolprocesses

ToTx

ToRx

[InitKeys, ChangeKey, Stop]

[InitKeys,ChangeKey, Stop]

[InitKeys,ChangeKey,Stop]

110

PROCESS Key_Contro l (1 OF 1)

idle

InitKeys(MasterKey,SessionKey,InitVector)via ToTx

InitKeys(MasterKey,SessionKey,InitVector)via ToRx

-

StopInitKeys(MasterKey,SessionKey,InitVector)

Stopvia ToPx

Stopvia ToTx

ChangeKey(SessionKey,InitVector)via ToTx

ChangeKey(SessionKey,InitVector)via ToRx

ChangeKey(SessionKey,InitVector)

111

idle

PROCESS SSSP_TX

DATA

KEY

(1 of 4)

Km:=MasterKeyKs:=SessionKeyLastOBlock:=InitVector

Ks:=SessionKeyLastOBlock:=InitVector

-

Acronyms

Km- Master KeyKs- Session KeyIV- Initialization Vector

Procedure EncryptEncrypt(Key,LastOBlock,InputBlock,OutputBlock)

Description:8 octets block encryption mode CBC, one block input, one block output, if LastOBlock=0, encryption is done in ECB mode

Parameters:Key - Cryptographic Key (16 octets)LastOBlock - Last Output Block (8 octets)InputBlock - Input Block to Encrypt (8 octets)OutputBlock - Output Encrypted Block (8 octets)

Global Encryption Parameters(stored per destination)Km = master key (16 octets)

Local Encryption Parameters(stored per VC)Ks = session key (16 octets)LastIBlock =last CBC encrypted block (8 octets)

InitKeys(MasterKey,SessionKey,InitVector)

AAL-UNITDATA.req(MU)

AALM-UNITDATA.req(MD,Type)

ChangeKey(SessionKey,InitVector)

Resync(InitVector)

LastOBlock:=InitVector

Stop

Stopped

InitKeys(MasterKey,SessionKey,InitVector)

Km:=MasterKeyKs:=SessionKeyLastOBlock:=InitVector

112

Add PAD

Encrypt (Key,LastOBlock,InputBlock,OutputBlock)

LastOBlock:=OutputB lockBlockNo:=BlockNo+8ID:=ID/ /OutputBlock

Last OutputB lock

false

D A T A

P R O C E S S S S S P _ T X

ID:=nullB lockNo:=1

(2 of 4)

InputBlock:=SubStr ing(MU,BlockNo,8)Key :=Ks

S E G

true

113

Ks:=SubString(MD,1,16)IV:=SubString(MD,17,8)LastOBlock:=IVKey:=KmInputBlock:=SubString(MD,1,8)

Encrypt(Key,0,InputBlock,OutputBlock)

Encrypt(Key,0,InputBlock,OutputBlock)

CPCS-UNITDATA.invoke(ID,LP,CI,UU)via ToCPCS

ID:=OutputBlockInputBlock:=SubString(MD,9,8)

ID:=ID//EncryptedBlock

-

IV:=MDLastOBlock:=IVID:=null

Type

PROCESS SSSP_TX

KEY

8 4

(3 of 4)

UU:=Type

Encrypt(Key,0,Inputblock,OutputBlock)

ID:=ID//OutputBlock

InputBlock:=IV

114

true

-

UU:=2

SEG

size_of_ID>

max_size

SID:=SubString(ID,1,max_size)

CPCS-UNITDATA.invoke(SID,LP,CI,UU)via ToCPCS

SID:=SubString(ID,max_size+1,size_of_S-max_size)

false

CPCS-UNITDATA.invoke(SID,LP,CI,UU)via ToCPCS

CPCS-UNITDATA.invoke(ID,LP,CI,UU)via ToCPCS

UU:=1

PROCESS SSSP_TX (4 of 4)

115

idle

UU

Decrypt(Key,LastIBlock,InputBlock,OutputBlock)

Last OutputBlock

LastIBlock:=InputBlockMU:=MU//OutputBlockBlockNo:=BlockNo+8

RemovePAD(MU)

AAL-UNITDATA.ind(MU)via ToUser

true

false

Decrypt(Key,0,InputBlock,Outputblock)

DecryptECB(Key,0,InputBlock,OutputBlock)

MD:=MD//OutputBlockInputBlock:=SubString(ID,17,8)

LastIBlock:=OutputBlockMD:=MD//OutputBlock

-

AALM-UNITDATA.ind(MD,Type)via ToLM

PROCESS SSSP_RX

MU:=nullBockNo:=1Seg:=0

4 8

(1 of 2)

InputBlock:=SubString(ID,BlockNo,8)Key:=Ks

Inputblock:=SubString(ID,1,8)Key:=KmSeg:=0

InputBlock:=SubString(ID,1,8)MD:=nullSeg:=0

Km:=MasterKeySave Km

Stopped

-

Type:=UU

MD:=OutputBlockInputBlock:=SubString(ID,9,8)

Decrypt(Key,0,InputBlock,Outputblock)

MasterKeyCPCS-UNITDATA-signal(ID,LP,CI,UU)

Stop

S_0

S_2

0

S_1

1 2

InitKeys(MasterKey,SessionKey,InitVector)

Km:=MasterKeyKs:=SessionKeyLastIBlock:=InitVector

idle

116

Acronyms

Km- Master KeyKs- Sess ion KeyIV- Init ial ization Vector

Procedure DecryptDecrypt(Key,Last IBlock, InputBlock,OutputBlock)

Description:8 octets block decrypt ion mode CBC, one block input, one block output, i f Last IBlock=0, encrypt ion is done in ECB mode

Parameters:Key - Cryptographic Key (16 octets)LastIBlock - Last Input Block (8 octets)InputBlock - Input Block to Decrypt (8 octets)OutputBlock - Output Decrypted Block (8 octets)

(2 of 2)P R O C E S S S S S P _ R X

Global Decryption Parameters(stored per dest inat ion)Km = master key (16 octets)

Local Decryption Parameters(s tored per VC)Ks = session key (16 octets)Last IBlock =last CBC encrypted block (8 octets)

S_1

Clear_BufferBuf fer :=IDSeg:=1

-

S_2

Seg =1

ID:=Buffer / / IDClear_BufferSeg:=0

SegErrorvia ToLM

Clear_BufferSeg:=0

idle

S_0

false

true

117

Apêndice C

Definições da MIB de Segurança em ASN.1(SMIv2)

-------------------- MÓDULO de segurança dos agentes (securityMIB)----------

securityMIB MODULE-IDENTITYLAST-UPDATED “9702101614Z”ORGANIZATION “DCC-UFMG ATM LAB”CONTACT-INFO

“Denio Teixeira Silva DCC/UFMG E-mail: denio@dcc.ufmg.br”

DESCRIPTION“Modulo MIB para segurança em redes ATM”

::= {experimental 77}

localId OBJECT-TYPESYNTAX IdentifierMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

“identificação local (ID)”::= { securityMIB 1 }

localPubKey OBJECT-TYPESYNTAX AssimKeyMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

“Chave assimétrica pública local (P)”::= { securityMIB 2 }

aksPubKey OBJECT-TYPESYNTAX AssimCyphBlockMAX-ACCESS read-writeSTATUS currentDESCRIPTION

“chave pública do AKS local PK”::= { securityMIB 3 }

---------- tabela do agente para distribuição de chave mestra

118

securityTable OBJECT-TYPESYNTAX SEQUENCE OF SecurityEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

“Tabela com chaves cifradas e outros parâmetros de segurança”::= { securityMIB 4 }

securityEntry OBJECT-TYPESYNTAX SecurityEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

“uma entrada na tabela de chaves e parâmetros”INDEX

{ nodeId }::= {securityTable 1}

SecurityEntry ::= SEQUENCE { sourceId IdentifierdestinId IdentifierauthTicket TicketBlockauthPubKey AssimCyphBlock }

sourceId OBJECT-TYPESYNTAX IdentifierMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

“identificador do nó origem (IDA)”::= { securityEntry 1 }

destinId OBJECT-TYPESYNTAX IdentifierMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

“identificador do nó destino (IDB)”::= { securityEntry 2 }

authTicket OBJECT-TYPESYNTAX TicketBlockMAX-ACCESS read-writeSTATUS currentDESCRIPTION

“ticket contendo os parâmetros de segurança e autenticado pelo AKS (TKT)”::= { securityEntry 3 }

119

authPubKey OBJECT-TYPESYNTAX AssimCyphBlockMAX-ACCESS read-writeSTATUS currentDESCRIPTION

“chave pública do AKS local autenticada pelo AKS remoto (ESK2(PK1))”::= { securityEntry 4 }

---------- fim da tabela

---------- tabela para distribuição de chave de sessão

sessionKeyTable OBJECT-TYPESYNTAX SEQUENCE OF SessionKeyEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

“tabela de chaves de sessão por destino”::= { securityMIB 5 }

sessionKeyEntry OBJECT-TYPESYNTAX SessionKeyEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

“uma entrada na tabela de chaves de sessão”::= { sessionKeyTable 1 }

SessionKeyEntry ::= SEQUENCE {nodeId IdentifierprivAKSSessionKey SEQUENCE OF

DoubleSimCyphBlock }

nodeId OBJECT-TYPESYNTAX IdentifierMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

“identificador do nó destino (IDB)”::= { sessionKeyEntry 1 }

privAksSessionKey OBJECT-TYPESYNTAX SEQUENCE OF DoubleSimCyphBlockMAX-ACCESS read-writeSTATUS currentDESCRIPTION

“chaves de sessão geradas pelo AKS cifradas com chave mestra pelo AKS(EKmi1(Ksi1,T)), (EKmi2(Ksi2,T)), ...”

::= { sessionKeyEntry 2 }

---------- fim da tabela

120

-------------------- MÓDULO securityM2M MIB de segurança dos gerentes----------

securityM2M MODULE-IDENTITYLAST-UPDATED “9702271803Z”ORGANIZATION “DCC-UFMG ATM LAB”CONTACT-INFO

“Denio Teixeira Silva DCC/UFMG E-mail: denio@dcc.ufmg.br”

DESCRIPTION“Modulo MIB para troca de informações de segurança entre gerentes”

::= {experimental 78}

---------- tabela com as chaves publicas autenticadas para comunicação gerente-gerente

authPubKeyTable OBJECT-TYPESYNTAX SEQUENCE OF AuthPubKeyEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

“Tabela com chaves públicas, chaves autenticadas e chaves criptografadas”::= { securityM2M 1 }

authPubKeyEntry OBJECT-TYPESYNTAX AuthPubKeyEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

“entrada na tabela de chaves públicas autenticadas”INDEX { keyId }::= {authPubKeyTable 1}

AuthPubKeyEntry ::= SEQUENCE {remoteId IdentifieraksId IdentifierauthLocalPk AssimCyphBLockremAuthLocalPk AssimCyphBlockauthNodePubKeyDoubleAssimCyphBlock }

remoteId OBJECT-TYPESYNTAX IdentifierMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

“identificador do nó destino (IDD)”::= { authPubKeyEntry 1 }

121

aksId OBJECT-TYPESYNTAX IdentifierMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

“identificador do AKS (IDK)”::= { authPubKeyEntry 2 }

authLocalPk OBJECT-TYPESYNTAX AssimCyphBlockMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

“chave pública do AKS local autenticada pelo AKS transmissor (ESKx(PK1))”::= { AuthKeyEntry 3 }

remAuthLocalPk OBJECT-TYPESYNTAX AssimCyphBlockMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

“chave pública do AKS local autenticada pelo AKS remoto (ESK2(PK1))”::= { AuthKeyEntry 4 }

authNodePubKey OBJECT-TYPESYNTAX DoubleAssimCyphBlockMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

“identificador e chave pública autenticados pelo AKS seguinte (ESK2(IDB,PB))”::= { authPubKeyEntry 5 }

---------- fim da tabela

-------------------- EVENTOS gerados pelo agente via SNMPv2-Trap ou pelo gerente via Inform----------

securityNotification OBJECT IDENTIFIER ::= { securityMIB 5 }

newPubKey NOTIFICATION-TYPEOBJECTS { localID, localPubKey }STATUS currentDESCRIPTION

“notifica que foi criada uma nova chave pública”::= { securityNotification 1 }

122

noMasterKey NOTIFICATION-TYPEOBJECTS { sourceId, destinationId }STATUS currentDESCRIPTION

“indica que não existe chave mestra válida para conexão ao no destino”::= { securityNotification 2 }

noSessionKey NOTIFICATION-TYPEOBJECTS { localID, nodeId }STATUS currentDESCRIPTION

“indica que não existe chave de sessão para o nó destino”::= { securityNotification 3 }

noPubKey NOTIFICATION-TYPEOBJECTS { remoteId, aksId, authLocalPk, authRemotePk, authNodePubKey }STATUS currentDESCRIPTION

“solicitação de chave pública do no ident a um AKS remoto”::= { securityNotification 4 }

---------- fim dos eventos

---------- Tipos definidos

Identifier ::= OCTET STRING (SIZE(20)) -- endereço ATM

AssimCyphBlock ::= OCTET STRING (SIZE(256)) -- bloco cifrado ou assinado de 256octetos

DoubleAssimCyphBlock ::= OCTET STRING (SIZE(512)) -- bloco cifrado de 512 octetos

SimCyphBlock ::= OCTET STRING (SIZE(8)) -- bloco cifrado de 16 octetos

DoubleSimCyphBlock ::= OCTET STRING (SIZE(16)) -- bloco cifrado de 16 octetos

AssimKey ::= OCTET STRING (SIZE(256)) -- chave assimétrica de 256 octetos

SimKey ::= OCTET STRING (SIZE(8)) -- chave simétrica de 64 bits

TicketBlock ::= OCTET STRING (SIZE(1280)) -- bloco cifrado e autenticado de 1280 octetos