1 Introdução

O rápido desenvolvimento da Internet tem proporcionado motivação para o desenvolvimento de novas aplicações que combinem voz, vídeo, imagem e texto sobre IP. Com o número cada vez maior de pessoas com acesso à Internet, um problema que surge é a necessidade de optimizar as chamadas comunicações de grupo, em que um interage com muitos, ou muitos com muitos. Como alguns exemplos dessas aplicações podemos citar jogos, videoconferência, distribuição de vídeo, de dados e ensino à distância.

O tipo de comunicação predominante na Internet é o unicast, em que o tráfego é ponto-a-ponto. Dessa forma, se o ponto A quiser enviar os mesmos dados para outros três nós, ele deverá enviar três cópias dessa mesma informação pela rede. A alternativa que existe, tanto para esse exemplo simples quanto para casos mais complexos, é o multicast, em que apenas uma cópia dos dados é enviada para A. A ideia é: em vez de enviar três cópias da mesma informação (gastando três vezes mais recursos), enviar apenas uma cópia, direccionada ao  grupo que deseja recebê-la.

O multicast já é utilizado em vários backbones e redes menores, contudo, ainda não se pode afirmar que seja usado em larga escala. Um dos principais problemas em relação a aplicações multicast na Internet é a segurança. O projecto do multicast não teve, na sua implementação, a preocupação com esse factor. Um exemplo disso é a associação e desassociação dos nós ao grupo, feitas de forma completamente anónima. A seguir, apresentam-se conceitos sobre segurança em multicast. Estes conceitos foram divididos em alguns tópicos básicos, abrangendo tanto questões gerais como questões relacionadas com a infra-estrutura..

2 IP Multicast

De uma forma resumida e simples, o IP multicast é uma maneira mais eficiente de transportar os mesmos dados de uma fonte para vários utilizadores (participantes). O multicast cria o conceito de um conjunto de utilizadores associados a um endereço de grupo.

Com base nisso, a ideia do protocolo é optimizar as comunicações desse grupo. Na Internet, quando uma mesma informação deve ser enviada para diversos hosts, são enviadas pela rede tantas cópias dessa informação quanto forem os hosts. Isso traduz-se em desperdício de recursos, principalmente se cópias da mesma informação viajarem pelas mesmos rotas, causando um congestionamento desnecessário. O cenário acima citado é baseado em unicast, cuja comunicação é ponto-a-ponto.

A alternativa é, então, uma comunicação ponto-multiponto: enviar uma única cópia da informação pela rede, destinada ao grupo de hosts como um todo. Assim, os pacotes que compõem essa informação só serão duplicados quando for realmente necessário.

Para que haja uma correcta duplicação dos pacotes nos pontos certos, é necessária a utilização de protocolos de routing multicast, que criam árvores para a distribuição dos dados.

As árvores podem ser de raiz partilhada (shared tree) ou com raiz na fonte do tráfego multicast (source tree). Nas primeiras, existe uma entidade chamada de Rendezvous Point (RP), responsável por receber todo o tráfego multicast das fontes e reencaminhá-lo para os receptores. É criada então, uma árvore única para cada grupo. Aqui, cada router guarda apenas informações sobre o grupo, não importando qual é a fonte. Nas árvores com raiz na fonte, existe uma árvore diferente para cada fonte multicast, independentemente de o tráfego ser destinado para o mesmo endereço ou não. Aqui, cada router armazena informações sobre fonte e grupo. Como exemplos de protocolos de routing, podemos citar o DVMRP, PIM – Protocol Independent Multicast, REUNITE e HBH.

Em essência, a árvore de distribuição é composta de routers que mantêm uma informação básica: por qual interface um pacote multicast entrou e por qual ele deve sair.

No modelo multicast, um host associa-se e deixa um grupo usando o protocolo IGMP (Internet Group Management Protocol). O host avisa o router multicast da sua subrede da intenção de participar de determinado grupo (join). O router passa então a encaminhar os pacotes recebidos e endereçados àquele grupo para a sub-rede da qual o host faz parte. Quando o host decide deixar o grupo, ele avisa o router (leave), que simplesmente não encaminha mais o tráfego para a sub-rede correspondente. No IGMP, o router não está interessado em quantos ou quais hosts participam do grupo: a única informação relevante é a presença ou ausência de pelo menos um participante do grupo na sub-rede. Assim, o router não mantém nenhuma informação sobre os hosts participantes do grupo. Do ponto de vista de segurança, o IGMP permite o total anonimato de cada um deles.

Uma das características do IGMP é possibilitar ao host especificar de quais fontes do grupo ele deseja receber tráfego. Cabe aqui realçar uma característica geral do IP multicast: uma fonte não precisa, necessariamente, de fazer parte do grupo para o qual envia dados.

A ideia desse tipo de comunicação de grupo torna-se atraente por ser escalável para um grande número de membros, dependendo basicamente da largura de banda e do protocolo de routing multicast disponíveis entre a fonte e os destinos. Essa escalabilidade deve-se, principalmente, ao fato de que nenhuma identificação dos hosts é mantida pelos routers. Um host associa-se e deixa o grupo sem que informações suas sej   encaminhados qualquer router.

Mesmo que, sob a perspectiva da segurança, esse anonimato possa ser visto como uma falha, é importante lembrar que o modelo do multicast nunca teve a intenção de oferecer comunicação segura. Ao invés disso, ele permite que mecanismos adicionais e outros serviços sejam construídos “em cima” de sua estrutura. Dessa forma, arquitecturas de segurança podem ser implementadas sem afectar a árvore de distribuição, responsável pelo tráfego fim-a-fim dos dados.

3 Segurança e Multicast

Existem diversos fatores, intrínsecos ao IP multicast, que influenciam os modelos de segurança utilizados. Abaixo, são referidos os mais importantes.

3.1. Tipo de Aplicação Multicast

Em geral, o multicast é utilizado em aplicações de um-para-muitos ou de muitos-para muitos.

Somando-se a esse facto os diferentes tipos de dados passíveis de transmissão, é fácil obter uma extensa gama de aplicações possíveis.

Um primeiro exemplo seria a transmissão de informações do mercado de acções. Este é um típico exemplo de um-para-muitos, onde a autenticação da fonte é mais importante do que a confidencialidade dos dados.

No serviço Pay-per-view a estrutura de transmissão é semelhante, contudo, a autenticação da fonte não é de vital importância. A confidencialidade é o aspecto principal do serviço, não pelo fato de o que está sendo transmitido ser secreto, mas para a estação emissora se poder certificar de que apenas os assinantes terão acesso ao programa exibido.

A videoconferência é um exemplo onde tanto a autenticação como a confidencialidade são importantes. Em geral, esse tipo de aplicação envolve a interacção de muitos com muitos, sendo importante assegurar tanto a identidade do transmissor como a  privacidade dos dados.

3.2 Tamanho do Grupo e sua Dinâmica

Estes dois factores podem afectar a maneira como se aplica segurança a um grupo de utilizadores. Os diferentes tamanhos afectam directamente o mecanismo de segurança aplicado, assim como a escalabilidade do mesmo. No que diz respeito à dinâmica, um grupo pode variar de alguns poucos participantes a milhares deles em questão de segundos, seja por associações e desassociações explícitas, ou por falhas em routers intermediários.

Intuitivamente, grupos pequenos são mais fáceis de gerir, e possuem necessidades diferentes das de grupos grandes. Da mesma forma, a exibição de um programa de TV tem uma dinâmica completamente diferente da de um vídeo disponibilizado na Internet. É natural que o grupo de telespectadores do programa apresente muitas associações imediatamente antes do início do mesmo, bem como muitas desassociações após seu término. A distribuição de pessoas vendo o vídeo tende a não apresentar um comportamento tão previsível como o do programa de TV.

3.3 Escalabilidade

Este é um dos principais factores que limitam a implementação de aplicações multicast. De uma forma geral, quanto mais escalável for o grupo (e, consequentemente, a aplicação), mais escalável deve ser o mecanismo de segurança utilizado. A escalabilidade do mecanismo de segurança em multicast refere-se à possibilidade de aplicação do mesmo a um grupo grande de participantes, sem deterioração do serviço oferecido.

3.4 Hierarquia de Confiança

Ao utilizar esquemas de criptografia, a questão de quem distribui, gera e gere as chaves deve ser discutida.

A seguir, são abordados os principais problemas encontrados quando se deseja conferir segurança a transmissões multicast.

4 Confidencialidade e Autenticação

Da mesma forma que o tráfego unicast, pacotes multicast devem atravessar partes públicas da Internet; por isso, é necessário controlar o acesso aos dados enviados. Um método comum utilizado é a cifra.

A ideia baseia-se na cifra da informação na fonte, e sua posterior decifração nos receptores. Para tal, estes últimos devem possuir chaves que possibilitem a leitura correcta dos dados recebidos. Com esse mecanismo, dados interceptados ao longo do caminho são inúteis para quem não conheça a chave de decifração.

Um dos maiores obstáculos no uso deste tipo de controle de acesso surge quando ele deve ser aplicado a dados transmitidos a alta velocidade. No caso de um vídeo por exemplo, a cifra / decifração de todos os pacotes pode gerar consideráveis atrasos no envio e exibição do mesmo.

No contexto do IP multicast, é útil separar autenticação de confidencialidade. Como já mencionado anteriormente, aplicações diferentes possuem diferentes necessidades de segurança (mercado de acções e Pay-per-view).

A autenticação p  e ser dividida em autenticação pela fonte e pelo grupo. A primeira, tipicamente, usa chaves públicas (criptografia assimétrica), enquanto que a segunda usa chaves privadas (criptografia simétrica). A utilização de uma ou de outra está directamente associado ao desempenho de cada uma delas: algoritmos assimétricos em geral são mais lentos e seguros que os simétricos. Em contrapartida, a distribuição das chaves privadas em algoritmos simétricos é um problema, uma vez que devem ser criadas formas seguras de transmitir a chave usada na decifração dos dados.

Associado ao uso de chaves privadas, existe o facto de que qualquer host que participe do grupo se pode fazer passar pela fonte de multicast, uma vez que ele possui a chave utilizada pela mesma. Assim, é natural que se procure esquemas baseados em chaves assimétricas, como a assinatura digital. Essa solução, contudo, apresenta um grande overhead, tanto para assinar e verificar quanto em utilização de largura de banda.

Uma solução conhecida é fazer uma assinat  a válida para um conjunto de pacotes, em vez de assinar um por um. Nenhum dos esquemas é, contudo, completamente satisfatório. O primeiro, pelo fato de pacotes poderem ser perdidos e pela não existência de reconhecimento (ack). Um caso típico seria a perda do pacote contendo a assinatura. A assinatura de todos os pacotes, por sua vez, requer poder computacional.

Um ataque do tipo DoS (Denial of Service) é possível no caso proposto acima. O ataque dá-se quando um hacker inunda um receptor com pacotes que supostamente possuem a assinatura. Como a verificação da mesma exige poder computacional do CPU, o receptor perde-se e não consegue mais sair do processo de verificação, tendo que analisar todos os pacotes “maus”.

O algoritmo conhecido como TESLA propõe um esquema de autenticação assimétrica. A ideia é que haja sincronização de timers entre a fonte e os demais participantes. O funcionamento é o seguinte: a fonte anexa um código a cada pacote, calculado usando uma chave k, conhecida apenas por si própria. O pa  te é enviado e armazenado num buffer pelo receptor. Alguns momentos depois, a fonte revela a chave k, e o receptor é capaz de decifrar o código e ler o pacote.

Este esquema, contudo, pode apresentar problemas de armazenamento de pacotes e gerar vulnerabilidade a ataques DoS. Existem propostas de alterações no TESLA, entre elas:

• autenticação de pacotes assim que são recebidos;
• diferentes timers para diferentes hosts em redes com diferentes delays (essa funcionalidade já existia no TESLA, mas a melhora aqui diz respeito ao menor overhead obtido);
• no TESLA, a fonte autentica-se individualmente com cada receptor. Isso pode ser muito dispendioso caso muitos hosts desejem autenticar-se simultaneamente. A proposta é utilizar uma única chave pública por unidade de tempo, independentemente do número de sincronizações durante essa unidade.

No TESLA, presume-se que todos se autenticaram antes de qualquer transmissão ter sido iniciada. Na verdade, receptores podem desejar receber os dados e só depois se autenticarem. Podem, ainda, querer autenticar-se durante o processo de recepção. A modificação proposta torna possíveis ambas as opções.

5 Gestão da Chave de Grupo Multicast

Como mencionado no ponto acima, é importante controlar o acesso aos dados transmitidos via multicast, sendo esse controle normalmente implementado com criptografia.

A utilização deste mecanismo implica duas questões básicas: distribuição das chaves e gestão das mesmas. Assim, um protocolo que trate desses aspectos deve, não só decidir que chave o grupo vai utilizar, mas também lidar com actualizações das chaves existentes.

5.1 Chave de Grupo Multicast

Os principais factores com os quais um protocolo de gestão de chaves se deve preocupar são:

• Escalabilidade – envolve questões como variação da densidade e comportamento do grupo, bem como a sua distribuição geográfica. Operações de gestão de chaves devem ser eficientes na utilização de recursos e acessíveis por todos do grupo. Devem também reduzir atrasos envolvidos em transacções de informação / actualização das chaves.
• Independência – a gestão das chaves de grupo deve ser independente do routing unicast e multicast.
• Fiabilidade – a entrega da chave deve ser um evento certo, sem margens para dúvidas quanto à sua recepção por parte do participante. Da mesma forma, cada membro confia que a chave actualizada será entregue no momento oportuno.
• Segurança – a gestão das chaves deve utilizar canais seguros. A transmissão das mesmas deve garantir que elas não serão interceptadas no meio do caminho. Podem ser usadas até mesmo chaves para a gestão das próprias chaves de decifração (de agora em diante, sempre que este esquema for mencionado, a chave do grupo multicast será chamada “chave 2”, e a chave usada para cifrá-la, “chave 1”).

5.2 Actualização das Chaves

A modificação das chaves é efectuada quando algum evento altera o quadro de membros, como a entrada e saída de hosts. Qualquer evento dessa natureza passará a ser denominado de alteração no grupo.

Estas actualizações são influenciadas por parâmetros como a duração do período de refresh, distribuição da população, dinâmica do grupo, custo de processamento nas máquinas e frequência de alterações no grupo.

Existem duas regras básicas associadas à alteração das chaves. A primeira é denominada forward-secrecy, e especifica que nenhum ex-membro deve poder ter acesso a dados transmitidos após a sua saída do grupo. A segunda, backwardsecrecy, especifica o contrário: nenhum membro deve poder ter acesso aos dados transmitidos antes de sua associação.

5.3 Escalabilidade, Domínios e km-keys

O conceito de domínio (ou região) é muitas vezes aplicado como um esforço para minimizar o problema de escalabilidade. Existem dois tipos de domínios:

• Cifra de dados – o limite entre um domínio e outro é estabelecido pelas chaves de cifra utilizadas em cada um. Torna-se necessária, então, uma tradução dos dados, sempre que eles saem de uma região para outra. Esse processo compreende a decifração na saída do domínio A e nova cifra na entrada do B. Nesta abordagem, as regiões são independentes entre si, com cada membro possuindo apenas a chave correspondente à região da qual faz parte.
• Gestão de chaves – aqui cada domínio possui as suas próprias km-keys. Embora as chaves 1 variem de região para região, juntas, elas formam um canal seguro para a transmissão da chave 2.

5.4. Arquiteturas para Gestão de Chaves de Grupo

Existem diversos modelos para a gestão das chaves baseados na existência de uma entidade de gestão de chave raiz (KME). Essa entidade pode servir membros directa ou indirectamente, por intermédio de outras KMEs. Apesar de mais complexo, este modelo distribuído mostra-se mais escalável que o centralizado.

6 Políticas de Segurança Multicast

De uma forma geral, as mesmas políticas adoptadas para tráfego unicast devem ser adoptadas para o tráfego multicast. Contudo, existem questões directamente ligadas à operação deste último. São elas: políticas de disseminação e alteração de chaves, controle de acesso e quais acções devem ser tomadas quando uma chave é comprometida.

No que diz respeito ao IP multicast, existem duas categorias mais abrangentes em relação a políticas de segurança:

• políticas relacionadas com os integrantes do grupo – envolvem questões como quem pode ou não juntar-se ao grupo (e em que condições) e como os utilizadores são autenticados e removidos. Aspectos como recursos computacionais mínimos também são tratados aqui.
• políticas de garantia da segurança – tratam da disseminação inicial das chaves, alterações das mesmas e de acções tomadas aquando da ocorrência de erros.

Em suma: é importante que as políticas sejam coerentes entre si, livres de loops e que cubram todos os cenários possíveis encontrados pelo sistema.

7 Routing

De uma forma geral, muitos dos problemas de infra-estrutura podem ser resolvidos com base nas soluções apresentadas nos tópicos de autenticação, confidencialidade e gestão de chaves. Proteger a infra-estrutura multicast consiste, na verdade, na protecção tanto da árvore de distribuição dos dados como na protecção do protocolo de transporte utilizado.

A árvore de distribuição está directamente associada ao routing. Ela é responsável pela entrega dos dados fim-a-fim, e a construção da mesma está associada à escalabilidade do grupo.

Vale a pena lembrar que problemas no routing multicast afectam tanto aplicações que têm como fim a distribuição de dados (Pay-per-view, jogos) como aplicações em que o multicast é apenas uma ferramenta. Como exemplos destas últimas, é possível citar softwares de gestão e até mesmo protocolos de routing unicast (OSPF, por exemplo).

Existem dois tipos básicos de ameaça ao routing: ataques internos e ataques vindos de border routers. Estes últimos podem ser:

• Ataques vindos do emissor – a árvore de distribuição é atacada por hosts enviando dados maliciosos para o grupo. Consequentemente, esses pacotes são entregues a todos os outros participantes, consumindo muita largura de banda. É importante lembrar que para enviar dados a um grupo multicast não é necessário fazer parte do mesmo. Outra forma de ataque seria a fonte enviar pacotes a um ritmo maior do que o permitido, tentando inundar os integrantes do grupo.
• Ataques vindos do receptor – aqui, a intenção é inchar a árvore de distribuição e simplesmente consumir recursos dos routers. O ataque dá-se com muitos hosts não-membros associando-se ao grupo. O tráfego, mesmo cifrado, é recebido por eles e descartado. Este ataque requer colaboração de muitos hosts, e pode ser classificado como um tipo de DDoS (Distributed Denial of Service).

Ataques internos, provenientes de dentro da árvore, têm origem em routers invadidos ou em invasores do grupo.

• Ataques com dados – semelhante aos ataques vindos do emissor, aqui também podem ser enviados dados maliciosos para todos os outros participantes. A principal diferença é que o hacker agora é um membro do grupo. Também é possível restringir o número de hosts afectados ao subconjunto deles abaixo do ponto de ataque.
• Ataques a dados de controle – nesta modalidade, são injectados dados de controle falsos, com o objectivo de confundir ou desmontar a árvore de distribuição. O hacker pode remontar a árvore de acordo com os seus objectivos: pode forçar a inclusão de um router próximo, com o intuito de injectar tráfego. Outro ataque pode ser a transformação de um router num buraco negro. Este ataque também pode partir da borda.

De uma forma resumida, ataques ao routing são funções de:

1. protocolos de routing unicast e multicast utilizados;
2. utilização ou não da tabela de roteamento unicast, por parte do protocolo de routing multicast (PIM, por exemplo);
3. topologia da rede;
4. tipo de aplicação multicast e
5. sentido do tráfego (uni ou bidireccional).

8. Conclusão

Apresentou-se uma visão geral sobre os principais aspectos envolvidos na segurança de redes multicast. Foram abordadas questões como confidencialidade, autenticação e gestão de chaves de grupo. Em relação a problemas de infraestrutura, foram apresentados aspectos envolvendo routing e protocolos de transporte.

Uma conclusão geral a que se chega é que a segurança em multicast difere da segurança em unicast por motivos inerentes a natureza de cada um. No primeiro, a segurança envolve apenas um par de pontos. Já no segundo podem haver, virtualmente, centenas de milhares deles. Essas diferenças afectam principalmente os protocolos de routing utilizados e a gestão das chaves criptográficas. Da mesma forma que em redes unicast, o nível de segurança para redes multicast deve levar em conta fatores como:

• Tipo de aplicação – algumas aplicações requerem menos segurança que outras. Mais ainda: devem ser levadas em conta as diferenças entre autenticação confidencialidade;
• Tamanho do grupo e sua dinâmica – grupos que sofrem muitas alterações são inerentemente mais difíceis de gerir. Da mesma forma, é mais fácil aplicar segurança a grupos pequenos e restritos a uma certa área geográfica.
• Escalabilidade – ao lidar com grupos, este factor deve ser prioridade no desenvolvimento de qualquer projeto que envolva multicast.

Um factor que também deve merecer atenção é a política de segurança. Aqui, podem incluir-se questões como quais hosts têm acesso a quê na rede; como a fonte e / ou grupo são autenticados e qual o algoritmo de criptografia utilizado (chaves públicas ou privadas).

De forma a garantir tanto a autenticação como a confidencialidade, devem ser estabelecidas políticas para a gestão das chaves utilizadas para criptografar os dados. É necessário também especificar a que camada(s) a autenticação deve ser aplicada.

As chaves de grupo devem ser constantemente actualizadas para fazer valer as regras de forward e backward-secrecy. Essas chaves também devem ser entregues nos momentos devidos, para permitir que os membros do grupo estejam sempre actualizados.

Além disso, pode interessar que a entrega das mesmas esteja sujeita a algum tipo de confirmação.

Em relação ao routing, o objetivo primordial deve ser garantir a integridade da árvore de distribuição. Como já mencionado, muitos dos problemas que afectam o routing podem  ser resolvidos com base nas soluções apresentadas nos tópicos de autenticação, confidencialidade e gestão de chaves. É de especial interesse também, desenvolver protocolos de transporte seguros, uma vez que eles podem ser usados para o transporte das chaves 1 e 2.

Finalmente, as melhores alternativas para segurança parecem apontar em duas direcções distintas. A primeira, para esquemas com divisão em sub-grupos independentes em relação ao routing e à gestão das chaves. A segunda, para a incorporação de segurança nos protocolos de transporte.

 

A modificação das chaves é efectuada quando algum evento altera o quadro de
membros, como a entrada e saída de hosts. Qualquer evento dessa natureza passará
a ser denominado de alteração no grupo.
Estas actualizações são influenciadas por parâmetros como a duração do período de
refresh, distribuição da população, dinâmica do grupo, custo de processamento nas
máquinas e frequência de alterações no grupo.