Segurana em Redes Multicast

Nilton C. N. da C. Braga
Grupo de Teleinformtica e Automao GTA/COPPE/EE
Programa de Engenharia Eltrica Universidade Federal do Rio de Janeiro
Caixa Postal 68504 21945-970 Rio de Janeiro RJ Brasil
ncb@gta.ufrj.br

Abstract. This tutorial presents the main concepts related to security in

multicast networks. The problems here described are: authentication,
confidentiality, group keys, routing and multicast transport protocols. Possible
solutions to some of them are also presented. As an example of scalability and
security in multicast networks, the Iolus framework is briefly studied. The
objectives of this work are supplying the reader with both a start point to the
subject and a tutorial with its main topics.
Resumo. Este tutorial apresenta os principais conceitos sobre segurana em
redes multicast. Os problemas descritos abordam questes como autenticao,
confidencialidade, chaves de grupo, roteamento e protocolos de transporte
multicast. Em alguns casos, so apresentadas possveis solues e idias para
a resoluo dos mesmos. apresentada tambm a arquitetura Iolus, como
exemplo de escalabilidade e segurana no tipo de rede em questo. Os
objetivos do trabalho so fornecer ao leitor tanto um ponto de partida para
anlises mais aprofundadas quanto um material que aborde os principais
tpicos relacionados ao assunto.

1. Introduo
O rpido desenvolvimento da Internet tem proporcionado motivao para o
desenvolvimento de novas aplicaes que combinem voz, vdeo, imagem e texto sobre
IP. Com o nmero cada vez maior de pessoas acessando a Internet, um problema que
surge a necessidade de se otimizar as chamadas comunicaes de grupo, em que um
interage com muitos, ou muitos com muitos. Como alguns exemplos dessas aplicaes
podemos citar jogos, videoconferncia, distribuio de vdeo, de dados e ensino a
distncia.
O tipo de comunicao predominante na Internet o unicast, em que a
comunicao ponto-a-ponto. Dessa forma, se o n A quiser enviar os mesmos dados
para outros trs ns, ele dever enviar trs cpias dessa mesma informao pela rede. A
alternativa que existe tanto para esse exemplo simples quanto para casos mais
complexos o multicast, em que apenas uma cpia dos dados enviada por A. A idia
: ao invs de enviar trs cpias da mesma informao (gastando trs vezes mais
recursos), enviar apenas uma cpia, direcionada ao grupo dos ns que desejam recebla.
O multicast j utilizado em vrios backbones e redes menores, contudo, ainda
no se pode afirmar que seu uso seja em larga escala.

Um dos principais problemas em relao a aplicaes multicast na Internet a

segurana. O projeto do multicast no teve, propositalmente em sua implementao, a
preocupao com esse fator. Um exemplo disso a associao e desassociao dos ns
ao grupo, feitas de forma completamente annima.
O objetivo deste trabalho apresentar e discutir alguns conceitos sobre
segurana em multicast. Esses conceitos foram divididos em seis tpicos bsicos,
abrangendo tanto questes gerais quanto questes relacionadas infra-estrutura
[Hardjono e Tsudik 2000].
O tutorial est organizado da seguinte maneira: no item a seguir apresentada
uma breve introduo de IP multicast. Aps isso, so apresentados ento aspectos gerais
envolvendo tanto multicast quanto segurana de dados. No item seguinte discute-se
questes referentes autenticao e confidencialidade, gerenciamento de chaves e
polticas de segurana. Em seguida so abordados aspectos relativos a infra-estrutura
(roteamento e protocolos de transporte). O trabalho continua com uma apresentao
breve da arquitetura Iolus. Por fim, apresentada a concluso.

2. IP Multicast
De uma forma resumida e simples, o IP multicast uma maneira mais eficiente de
transportar os mesmos dados de um (fonte) para vrios usurios (participantes). O
multicast cria o conceito de um conjunto de usurios associados a um endereo de grupo
(classe D do endereamento IP). Com base nisso, a idia do protocolo otimizar as
comunicaes desse grupo [Dias, Medeiros e Alves 2002].
Na Internet, quando uma mesma informao deve ser enviada para diversos
hosts, so enviadas pela rede tantas cpias dessa informao quanto forem os hosts. Isso
acarreta em desperdcio de recursos, principalmente se cpias da mesma informao
trafegarem pelos mesmos links, causando um congestionamento desnecessrio. O
cenrio acima citado baseado em unicast, cuja comunicao ponto-a-ponto.
A alternativa , ento, uma comunicao ponto-multiponto: enviar uma nica
cpia da informao pela rede, destinada ao grupo de hosts como um todo. Assim, os
pacotes que compem essa informao s sero duplicados quando for realmente
necessrio. Observe as figuras abaixo:

Figura 1. Trfego unicast.

Figura 2. Trfego multicast.

No exemplo com unicast, os pacotes so duplicados j entre o primeiro e o

segundo roteador, gerando um consumo de recursos desnecessrio nesse link. No
exemplo com multicast, os pacotes so duplicados somente quando no h mais
alternativa: nos links entre o segundo e os ltimos roteadores.
Para que haja a correta duplicao dos pacotes nos pontos corretos, necessria
a utilizao de protocolos de roteamento multicast, que criam rvores para a distribuio
dos dados. As rvores podem ser de raiz compartilhada (shared tree) ou com raiz na
fonte do trfego multicast (source tree).
Nas primeiras, existe uma entidade chamada de Rendezvous Point (RP),
responsvel por receber todo o trfego multicast das fontes e reencaminh-lo para os
receptores. criada ento, uma rvore nica para cada grupo. Aqui, cada roteador
guarda apenas informaes sobre o grupo, no importando qual a fonte. (*,G).
Nas rvores com raiz na fonte, existe uma rvore diferente para cada fonte
multicast, independente de o trfego ser destinado para o mesmo endereo ou no. Aqui,
cada roteador armazena informaes sobre fonte e grupo (S,G).
Como exemplos de protocolos de roteamento, podemos citar o DVMRP, PIM
Protocol Independent Multicast (SM e DM), REUNITE e HBH [Costa e Duarte 2003].
Em essncia, a rvore de distribuio composta de roteadores que mantm uma
informao bsica: por qual interface um pacote multicast entrou e por qual ele deve
sair.
No modelo multicast, um host se associa e deixa um grupo usando o protocolo
IGMP (Internet Group Management Protocol). O host avisa ao roteador multicast de
sua sub-rede a inteno de participar de determinado grupo (join). O roteador passa
ento a encaminhar os pacotes recebidos e endereados quele grupo para a sub-rede da
qual o host faz parte. Quando o host decide deixar o grupo, ele avisa ao roteador (leave),
que simplesmente no repassa mais o trfego para a sub-rede correspondente.
No IGMP, o roteador no est interessado em quantos ou quais hosts participam
do grupo: a nica informao relevante a presena ou ausncia de pelo menos um
participante do grupo na sub-rede. Assim, o roteador no mantm nenhuma informao
sobre os hosts participantes do grupo. Do ponto de vista de segurana, o IGMP permite
o total anonimato de cada um deles.
O IGMP se encontra na sua verso trs, e uma de suas principais caractersticas
possibilitar ao host especificar de quais fontes do grupo ele deseja receber trfego. Cabe

aqui ressaltar uma caracterstica geral do IP multicast: uma fonte no precisa,

necessariamente, fazer parte do grupo para o qual ela envia dados.
A idia desse tipo de comunicao de grupo acaba sendo atrativa por ser
escalvel para um grande nmero de membros, dependendo basicamente da banda e do
protocolo de roteamento multicast disponveis entre a fonte e os destinos. Essa
escalabilidade se deve, principalmente, ao fato de que nenhuma identificao dos hosts
mantida pelos roteadores. Um host se associa e deixa o grupo sem que informaes suas
sejam repassadas para roteador algum.
Mesmo que sob a perspectiva de segurana esse anonimato possa ser enxergado
como uma falha, importante lembrar que o modelo do multicast nunca teve a inteno
de oferecer comunicao segura. Ao invs disso, ele permite que mecanismos adicionais
e outros servios sejam construdos em cima de sua estrutura. Dessa forma,
arquiteturas de segurana podem ser implementadas sem afetar a rvore de distribuio,
responsvel pelo trfego fim-a-fim dos dados.

3. Segurana e Multicast
Existem diversos fatores, intrnsecos ao IP multicast, que influenciam os modelos de
segurana utilizados. Abaixo, so relacionados os mais importantes.
3.1. Tipo de Aplicao Multicast
Em geral, o multicast utilizado em aplicaes de um-para-muitos ou de muitos-paramuitos. Somando-se a esse fato os diferentes tipos de dados passveis de transmisso,
fcil obter uma extensa gama de aplicaes possveis.
Um primeiro exemplo seria a transmisso de informaes do mercado de aes.
Esse um tpico exemplo de um-para-muitos, onde a autenticao da fonte mais
importante do que a confidencialidade dos dados.
No servio Pay-per-view a estrutura de transmisso semelhante, contudo, a
autenticao da fonte no de vital importncia. A confidencialidade o aspecto
principal do servio, no pelo fato de o que est sendo transmitido ser secreto, mas para
a estao de TV poder se assegurar de que somente os assinantes tero acesso ao
programa exibido.
A videoconferncia um exemplo onde tanto a autenticao quanto a
confidencialidade so importantes. Em geral, esse tipo de aplicao envolve a interao
de muitos com muitos, sendo importante assegurar tanto a identidade do transmissor
quanto a privacidade dos dados.
3.2. Tamanho do Grupo e Dinmica do Mesmo
Esses dois fatores podem afetar a maneira como se aplica segurana a um grupo de
usurios. Os diferentes tamanhos afetam diretamente o mecanismo de segurana
aplicado, assim como a escalabilidade do mesmo. No que diz respeito dinmica, um
grupo pode variar de alguns poucos participantes a milhares deles em questo de
segundos, seja por associaes e desassociaes explcitas, ou por falhas em roteadores
intermedirios.

Intuitivamente, grupos pequenos so mais fceis de gerenciar, e possuem

necessidades diferentes das de grupos grandes. Da mesma forma, a exibio de um
programa de TV tem uma dinmica completamente diferente da de um vdeo
disponibilizado na Internet. natural que o grupo de telespectadores do programa
apresente muitas associaes imediatamente antes do incio do mesmo, bem como
muitas desassociaes aps seu trmino. A distribuio de pessoas assistindo ao vdeo
tende a no apresentar um comportamento to previsvel quanto o do programa de TV.
3.3. Escalabilidade
Este um dos principais fatores que limitam a implementao de aplicaes multicast.
De uma forma geral, quanto mais escalvel for o grupo (e, conseqentemente, a
aplicao), mais escalvel deve ser o mecanismo de segurana utilizado.
A escalabilidade do mecanismo de segurana em multicast se refere
possibilidade de aplicao do mesmo a um grupo grande de participantes, sem
deteriorao do servio oferecido [Hardjono e Tsudik 2000]. De uma forma
3.4. Modelo de Confiana
Ao utilizar esquemas de criptografia, a questo de quem distribui, gera e gerencia as
chaves deve ser discutida.
Com certeza, os fatores citados acima no esgotam a lista de aspectos
relacionados a segurana em multicast, mas servem como um guia para anlises mais
aprofundadas.
A seguir, so abordados os principais problemas encontrados quando se deseja
dar segurana a transmisses multicast.

4. Confidencialidade e Autenticao
Da mesma forma que o trfego unicast, pacotes multicast devem atravessar pores
pblicas da Internet; por isso, necessrio controlar o acesso aos dados enviados. Um
mtodo comum utilizado a encriptao [Hardjono e Tsudik 2000].
A idia se baseia na encriptao da informao na fonte, e sua posterior
decriptao nos receptores. Para tal, esses ltimos devem possuir chaves que
possibilitem a leitura correta dos dados recebidos. Com esse mecanismo, dados
interceptados ao longo do caminho so inteis para quem no conhea a chave de
decriptao.
Um dos maiores obstculos no uso desse tipo de controle de acesso surge
quando ele deve ser aplicado a dados transmitidos em alta velocidade. No caso de um
vdeo por exemplo, a encriptao / decriptao de todos os pacotes pode gerar
mensurveis atrasos no envio e exibio do mesmo.
No contexto de IP multicast, til separar autenticao de confidencialidade.
Como j mencionado anteriormente, aplicaes diferentes possuem diferentes
necessidades de segurana (mercado de aes e Pay-per-view).
A autenticao pode ser dividida em autenticao pela fonte e pelo grupo. A
primeira tipicamente usa chaves pblicas (criptografia assimtrica), enquanto que a

segunda usa chaves privadas (criptografia simtrica). O uso de uma ou de outra est
diretamente associado ao desempenho de cada uma delas: algoritmos assimtricos em
geral so mais lentos e seguros que os simtricos. Em contrapartida, a distribuio das
chaves privadas em algoritmos simtricos um problema, uma vez que devem ser
criadas formas seguras de transmitir a chave usada na decriptao dos dados.
Associado ao uso de chaves privadas, existe o fato de que qualquer host que
participe do grupo pode se fazer passar pela fonte de multicast, uma vez que ele possui a
chave utilizada pela mesma. Assim, natural que se procure por esquemas baseados em
chaves assimtricas, como a assinatura digital. Essa soluo, contudo, apresenta um
grande overhead, tanto para assinar e verificar quanto em utilizao de banda.
Uma soluo conhecida fazer uma assinatura ser vlida para um conjunto de
pacotes, ao invs de assinar um por um. Ambos os esquemas, contudo, no so
completamente satisfatrios. O primeiro, pelo fato de pacotes poderem ser perdidos e
pela no existncia de reconhecimento (ack). Um caso tpico seria a perda do pacote
contendo a assinatura [Perrig e Canetti 2001]. A assinatura de todos os pacotes, por sua
vez, requer poder computacional.
Um ataque do tipo DOS (Denial of Service) possvel no caso proposto acima.
O ataque se d quando um hacker inunda um receptor com pacotes que supostamente
possuem a assinatura. Como a verificao da mesma exige poder computacional da
CPU, o receptor se perde e no consegue mais sair do processo de verificao, tendo que
analisar todos os pacotes maus [Perrig e Canetti 2001].
O algoritmo conhecido como TESLA prope um esquema de autenticao
assimtrica. A idia que haja sincronizao de timers entre a fonte e os demais
participantes. O funcionamento como a seguir: a fonte anexa um cdigo a cada pacote,
calculado usando uma chave k, conhecida apenas por si prpria. O pacote enviado e
armazenado num buffer pelo receptor. Alguns momentos depois, a fonte revela a chave
k, e o receptor capaz de decriptar o cdigo e ler o pacote.
Esse esquema, contudo, pode apresentar problemas de armazenamento de
pacotes e gerar vulnerabilidade a ataques DOS.
Em [Perrig, Canetti, Song e Tygar 2001] so propostas alteraes no TESLA,
entre elas:
o autenticao de pacotes assim que so recebidos;
o diferentes timers para diferentes hosts em redes com diferentes atrasos (essa
funcionalidade j existia no TESLA, mas a melhora aqui diz respeito ao menor
overhead obtido);
o no TESLA, a fonte se autentica individualmente com cada receptor. Isso pode
ser muito custoso caso muitos hosts desejem se autenticar simultaneamente. A
proposta utilizar uma nica chave pblica por unidade de tempo, independente
do nmero de sincronizaes durante essa unidade.
No TESLA, assume-se que todos se autenticaram antes de qualquer transmisso
ter sido iniciada. Na verdade, receptores podem desejar receber os dados e s depois se
autenticarem. Eles ainda podem querer se autenticar durante o processo de recepo. A
modificao proposta torna possveis ambas as opes.

5. Gerenciamento da Chave de Grupo Multicast

Como mencionado no item acima, importante controlar o acesso aos dados
transmitidos via multicast, sendo esse controle normalmente implementado com
criptografia.
O uso desse mecanismo implica em duas questes bsicas: distribuio das
chaves e gerenciamento das mesmas. Assim, um protocolo que cuide desses aspectos
deve no somente decidir qual chave o grupo vai utilizar, mas tambm lidar com
atualizaes das chaves existentes.
5.1. Chave de Grupo Multicast
Os principais fatores com os quais um protocolo de gerenciamento de chaves deve se
preocupar so [Hardjono e Tsudik 2000]:
o escalabilidade envolve questes como variao da densidade e comportamento
do grupo, bem como sua distribuio geogrfica. Operaes de gerenciamento de
chaves devem ser eficientes na utilizao de recursos e acessveis por todos do
grupo. Devem tambm reduzir atrasos envolvidos em transaes de informao /
atualizao das chaves.
o Independncia o gerenciamento das chaves de grupo deve ser independente do
roteamento unicast e multicast.
o Confiabilidade a entrega da chave deve ser um evento certo, sem margens para
dvidas quanto a sua recepo por parte do participante. Da mesma forma, cada
membro confia que a chave atualizada ser entregue no momento oportuno.
o Segurana o gerenciamento das chaves deve utilizar canais seguros. A
transmisso das mesmas deve garantir que elas no sero interceptadas no meio
do caminho. Podem ser usadas at mesmo chaves (km-keys) para o
gerenciamento das prprias chaves de decriptao (daqui para frente, sempre que
esse esquema for mencionado, a chave do grupo multicast ser chamada de
chave 2, e a chave usada para encript-la, de chave 1).
5.2. Atualizao das Chaves
A modificao das chaves efetuada quando algum evento altera o quadro de membros,
como a entrada e sada de hosts. Qualquer evento dessa natureza passar a ser
denominado de alterao no grupo.
Essas atualizaes so influenciadas por parmetros como durao do perodo de
refresh, distribuio da populao, dinmica do grupo, custo de processamento nas
mquinas e freqncia de alteraes no grupo [Hardjono e Tsudik 2000].
Existem duas regras bsicas associadas alterao das chaves. A primeira
denominada forward-secrecy, e especifica que nenhum ex-membro deve poder ter
acesso a dados transmitidos aps sua sada do grupo. A segunda, backward-secrecy,
especifica o contrrio: nenhum membro deve poder ter acesso aos dados transmitidos
antes de sua associao.

5.3. Escalabilidade, Domnios e km-keys

O conceito de domnio (ou regio) muitas vezes aplicado como um esforo para
minimizar o problema de escalabilidade. Existem dois tipos de domnios:
o encriptao de dados o limite entre um domnio e outro estabelecido pelas
chaves de encriptao utilizadas em cada um. Torna-se necessria, ento, uma
traduo dos dados, sempre que eles saem de uma regio para outra. Esse
processo compreende a decriptao na sada do domnio A e nova encriptao na
entrada do B. Nesta abordagem as regies so independentes entre si, com cada
membro possuindo somente a chave correspondente regio da qual faz parte.
o Gerenciamento de chaves aqui cada domnio possui suas prprias km-keys.
Embora as chaves 1 variem de regio para regio, juntas, elas formam um canal
seguro para a transmisso da chave 2.
5.4. Arquiteturas para Gerenciamento de Chaves de Grupo
So descritos a seguir modelos para o gerenciamento das chaves. Todos os trs se
baseiam na existncia de uma entidade de gerenciamento de chave raiz (KME). Essa
entidade pode servir membros direta ou indiretamente, por intermdio de outras KMEs
(figura 3). Apesar de mais complexo, esse modelo distribudo se mostra mais escalvel
que o centralizado.

Figura 3. Arquiteturas de gerenciamento de chaves de grupo.

5.4.1. Esquema de Compartilhamento

Aqui, a KME raiz compartilha uma chave 1 com membros autorizados a entrar no
grupo. Com base nessa chave estabelecido um meio de comunicao seguro entre a
KME e os hosts do grupo, por onde transmitida a chave 2.
Alm de haver um ponto nico de confiana na rede (KME), esse esquema
tambm peca por haver um ponto nico de falha. Alm disso, no escalvel para
muitos hosts. Uma alternativa selecionar hosts confiveis pela rede (outras KMEs),
delegando poderes aos mesmos, de forma que sejam responsveis pela disseminao da
chave 1.
5.4.2. Chaves Complementares
Nesse esquema, alm da chave de grupo os participantes possuem tambm uma chave
complementar. A KME associa cada host a uma chave diferente. Contudo, o dono de
uma chave nunca sabe o seu prprio valor: ao invs disso, sabe o valor combinado das
chaves dos outros participantes.
O funcionamento : quando um host deixa o grupo, a KME instrui o resto dos
integrantes a recalcularem a chave, excluindo o valor associado ao host que deixou o
grupo.
Um problema que deve sempre ser considerado a robustez do mecanismo
criptogrfico utilizado, uma vez que no membros e ex-membros do grupo devem ser
incapazes de calcular a chave em uso. O algoritmo deve criar chaves difceis de supor,
principalmente por ex-membros.
O mecanismo de chaves complementares se baseia na idia da existncia de um
segredo S compartilhado entre algumas pessoas (secret sharing). Para ilustrar esse
esquema, seguem trs exemplos.
Exemplo 1:
Onze cientistas desenvolveram uma frmula secreta. Com medo de que casse
em mos erradas, trancaram-na em um ba. Decidiram ento que o ba s seria aberto
se seis ou mais deles estivessem presentes. Fazendo os clculos, chega-se a concluso de
que o ba deveria ter 462 fechaduras diferentes, e cada cientista deveria portar 252
chaves, cobrindo assim todas as possveis combinaes.
Exemplo 2:
Numa empresa, para autorizar compras existem trs opes:
o permitir que qualquer executivo assine o cheque. Essa abordagem a que d
menos trabalho, mas tambm a menos segura;
o somente permitir a compra se todos os executivos autorizarem. Em relao
primeira alternativa, mais segura. Contudo, d mais trabalho, uma vez que
requer a presena de todos;
o a terceira alternativa (e mais plausvel delas), requerer um mnimo de trs
autorizaes para que a assinatura seja impressa no cheque.

Em ambos os exemplos, a ao (abertura do ba ou compra) s efetuada se o

nmero mnimo de pessoas (k) estiver presente. como se o segredo S fosse dividido
(S1, S2,..., Sn), e a cada um fosse entregue uma parcela dele. No primeiro caso, o
segredo o conjunto de chaves que um cientista possui. No segundo, a assinatura.
Alm disso, mesmo que haja k-1 pessoas, no possvel tomar a ao.
Exemplo 3:
Imagine uma senha S (o nmero 77), que seja dividida entre trs cartes. Cada
carto contm um pedao da senha. A ao (abertura de uma porta), s pode ser
tomada com, no mnimo, dois cartes.
Tem-se ento um esquema (k,n) de (2,3), onde k o nmero de cartes
necessrios e n o nmero cartes com os quais a senha foi compartilhada.
Seleciona-se um polinmio q de grau k-1, por exemplo: q(x) = S+a1.x = 77+2.x.
A constante a1 desconhecida pelos trs cartes.
Pedaos da senha, por carto:
o Carto 1: S1 = 79 = 77 + 2.1
o Carto 2: S2 = 81 = 77 + 2.2
o Carto 3: S3 = 83 = 77 + 2.3
Recuperao de S:
Os cartes so passados, e o sistema da porta possui agora S1 e S2. Ento:
o S + a1.1 = 79 = S1
o S + a1.2 = 81 = S2
Subtraindo uma equao da outra, a1 se iguala a 2. Com base nesse valor,
conclui-se ento que S igual a 77.
Esses exemplos so meramente ilustrativos, e uma anlise mais complexa e
aprofundada pode ser encontrada em [Shamir 2003].
5.4.3. rvore hierrquica
Um protocolo de gerenciamento de chaves de grupo deve ser capaz de restringir os
efeitos decorrentes de alteraes no grupo. Isso significa que a mudana de chave para
um ou mais hosts no deve afetar a participao dos demais.
Nesses casos, um mtodo comum dividir os membros em sub-grupos,
organizados como uma rvore lgica (figura 4). O objetivo cada um desses
subconjuntos possuir uma chave de sub-grupo diferente, do tipo chave 1. Com essa
chave, ento possvel transmitir a chave 2 de forma segura.

Figura 4. rvore hierrquica.

Nessa abordagem, possvel que a KME raiz (possuidora de todas as chaves de

sub-grupo) envie mensagens direcionadas para determinados subconjuntos (via unicast
ou multicast). Uma vantagem dessa arquitetura que as chaves de pequenos
subconjuntos podem ser alteradas independentemente da(s) chave(s) do restante do
grupo. Assim, possvel alterar mais freqentemente as chaves de grupos suspeitos,
sem prejuzo para os demais integrantes.
Em comparao com as outras duas estruturas, a rvore hierrquica com KME
centralizada a mais escalvel. Isso decorre do fato de que sub-grupos podem ser
criados sob medida, de acordo com sua dinmica e densidade. Entretanto, em casos de
populaes geograficamente dispersas, a soluo com diversas KMEs secundrias tornase mais atrativa.

6. Polticas de Segurana Multicast

De uma forma geral, as mesmas polticas adotadas para trfego unicast devem ser
adotadas para o trfego multicast. Contudo, existem questes diretamente ligadas a
operao deste ltimo. So elas: polticas de disseminao e alterao de chaves,
controle de acesso e quais aes devem ser tomadas quando uma chave comprometida.
No que diz respeito ao IP multicast, existem duas categorias mais abrangentes
em relao a polticas de segurana:
o polticas relacionadas aos integrantes do grupo envolvem questes como quem
pode ou no se unir ao grupo (e sob quais condies) e como os usurios so

autenticados e removidos. Aspectos como recursos computacionais mnimos

tambm so tratados aqui.
o polticas de garantia da segurana tratam da disseminao inicial das chaves,
alteraes das mesmas e de aes tomadas quando da ocorrncia de erros.
Em resumo: importante que as polticas sejam coerentes entre si, livres de
loops e que cubram todos os possveis cenrios encontrados pelo sistema [Hardjono e
Tsudik 2000].

7. Roteamento
De uma forma geral, muitos dos problemas de infra-estrutura podem ser resolvidos com
base nas solues apresentadas nos tpicos de autenticao, confidencialidade e
gerenciamento de chaves. Proteger a infra-estrutura multicast consiste, na verdade, na
proteo tanto da rvore de distribuio dos dados quanto na proteo do protocolo de
transporte utilizado.
A rvore de distribuio est diretamente associada ao roteamento. Ela
responsvel pela entrega dos dados fim-a-fim, e a construo da mesma est associada a
escalabilidade do grupo.
Vale lembrar que problemas no roteamento multicast afetam tanto aplicaes
que tm como fim a distribuio de dados (Pay-per-view, jogos) quanto aplicaes em
que o multicast apenas uma ferramenta. Como exemplos dessas ltimas, possvel
citar softwares de gerenciamento e at mesmo protocolos de roteamento unicast (OSPF,
por exemplo).
Existem dois tipos bsicos de ameaa ao roteamento: ataques internos e ataques
vindos da borda da rede.
Ataques vindos da borda: so originados de hosts conectados a roteadores-folha.
Podem ser:
o ataques vindos do emissor a rvore de distribuio atacada por hosts
enviando dados esprios para o grupo. Conseqentemente, esses pacotes so
entregues a todos os outros participantes, consumindo muita largura de banda.
importante lembrar que para enviar dados a um grupo multicast no necessrio
fazer parte do mesmo. Outra forma de ataque seria a fonte enviar pacotes numa
taxa maior do que a permitida, tentando inundar os integrantes do grupo
[Whetten 1998].
o Ataques vindos do receptor aqui, a inteno inchar a rvore de distribuio e
simplesmente consumir recursos dos roteadores (banda nos links entre eles e
informaes de controle so dois exemplos). O ataque se d com muitos hosts
no-membros se associando ao grupo. O trfego, mesmo encriptado, recebido
por eles e descartado. Esse ataque requer colaborao de muitos hosts, e pode ser
classificado como um tipo de DDOS (Distributed Denial of Service).
Ataques internos: provenientes de dentro da rvore, tm origem em roteadores
invadidos ou em invasores do grupo.

o Ataques com dados semelhante aos ataques vindos do emissor, aqui tambm
podem ser enviados dados esprios para todos os outros participantes. A
principal diferena que o hacker agora um membro do grupo. Tambm
possvel restringir o nmero de hosts afetados ao subconjunto deles abaixo do
ponto de ataque.
o Ataques a dados de controle nessa modalidade, so injetados dados de controle
falsos, com o objetivo de confundir ou desmontar a rvore de distribuio. O
hacker pode remontar a rvore de acordo com seus objetivos: pode forar a
incluso de um roteador prximo, com o intuito de injetar trfego. Outro ataque
pode ser a transformao de um roteador num buraco negro [Huitema 2000].
Esse ataque tambm pode partir da borda.
De uma forma resumida, ataques ao roteamento so funes de: i) protocolos de
roteamento unicast e multicast utilizados; ii) utilizao ou no da tabela de roteamento
unicast, por parte do protocolo de roteamento multicast (PIM, por exemplo); iii)
topologia da rede; iv) tipo de aplicao multicast [Satmeeting 2003] e v) sentido do
trfego (uni ou bidirecional).
Algumas propostas de proteo ao roteamento existem para o CBT (Core Based
Tree) e para o PIM. No caso desse ltimo, tratado especificamente o modo esparso,
com autenticao usando IPSec. A idia que todos os roteadores PIM de um mesmo
domnio utilizem a mesma chave simtrica. Algumas entidades, como o RP e o roteador
Bootstrap (BSR) utilizam criptografia assimtrica. O BSR pode, por exemplo, assinar
digitalmente a lista de possveis candidatos a RP.

8. Protocolos Multicast confiveis

Em relao a esse tipo de protocolo, difcil propor uma soluo nica para todos, uma
vez que cada um implementa a confiabilidade de uma forma diferente (ack, nack,
retransmisso, etc). Mesmo assim, so relacionadas no final da seo algumas
caractersticas mnimas que esses protocolos devem possuir.
Com o objetivo de apresentar alguns aspectos de segurana, sero dados dois
exemplos, ambos baseados no protocolo RMTP (Reliable Multicast Transport Protocol)
[Shiroshita, Sano e Takahashi 1997].
O protocolo de transporte confivel multicast desenvolvido para ser utilizado em
plataformas satelitais (SAT-RMTP) prev os seguintes mecanismos de segurana
[Koyabe e Fairhurst 2001]:
o autenticao dos clientes usando chave pblica;
o controle de acesso a um dado objeto ou arquivo;
o troca de chaves usando criptografia assimtrica;
o confidencialidade baseada na encriptao do objeto ou arquivo com chaves
secretas;
o integridade do arquivo baixado por meio de HMACs (Hash Message
Authentication Codes);
o deteco de ataques de repetio usando nmeros aleatrios.

Especificamente em relao ao RMTP, existem tcnicas baseadas em

scramblers, em que a ordem dos pacotes embaralhados constantemente alterada com
base na troca de chaves [Shiroshita, Takahashi e Yamashita 1996].
Existem algumas vulnerabilidades no protocolo RMTP II que possibilitam
ataques do tipo DOS. Como a maioria delas j foi explicada ao longo do trabalho (por
serem inerentes ao multicast), no sero aqui repetidas. Em contrapartida, so
apresentadas algumas defesas, propostas em [Whetten 1998]:
o senha nica para todos os receptores designados (DR) e para os Top Nodes (TN);
o uma chave por fonte;
o uma chave para os receptores comuns.
Conforme mencionado no incio da seo, apesar de cada protocolo ser diferente
em relao implementao da confiabilidade, existem caractersticas de autenticidade
que todos eles devem possuir. So elas:
o mensagens de controle todas as mensagens de controle trocadas devem passar
por algum processo de autenticao. Isso evitaria modificaes que causassem
problemas de roteamento e comportamento errneo do protocolo.
o Retransmisses o protocolo de transporte deve especificar se, ao retransmitir
pacotes, eles devem ser autenticados com um mecanismo prprio, ou se devem
receber o mesmo tipo de autenticao inicial (da fonte).
8.1. Camada da Autenticao
Geralmente, a autenticao aplicada na camada de rede. Entretanto, existem outras
camadas onde se pode fazer o mesmo.
Uma opo utilizar a camada de aplicao. Quando feito dessa forma, o
processo passa a ser realmente fim-a-fim, comeando na fonte e terminando nos
receptores.
A vantagem desse mtodo que entidades retransmissoras podem pura e
simplesmente retransmitir os dados sem aplicar nenhuma autenticao sua. Isso significa
que, para quem retransmite, no h distino entre dados originais e informao de
autenticao proveniente da fonte. A desvantagem reside no fato de que os cabealhos
das camadas de rede e transporte no so protegidos. Uma outra caracterstica : o
receptor incapaz de distinguir entre um dado original e um retransmitido.
A segunda opo, e mais utilizada, autenticar na camada de rede. A vantagem
est em proteger os cabealhos das camadas 3 e 4. No momento da retransmisso,
existem duas alternativas: desencapsular os dados perdidos e envi-los como um novo
pacote autenticado, ou encapsular o pacote inteiro (dados e informao de autenticao)
num novo pacote autenticado.
A figura abaixo ilustra os dois mtodos apresentados.

Figura 5. Camada do processo autenticao / encriptao.

Finalizando, outra questo relacionada a protocolos confiveis multicast que

eles, teoricamente, so a melhor alternativa para enviar as chaves de grupo. Assim,
mesmo que no sejam utilizados para a transferncia macia de dados, podem ser
usados para garantir a entrega das chaves. Um bom exemplo seria a entrega do vdeo via
UDP e a entrega das chaves via RMTP.

9. O Modelo Iolus
Neste modelo, o objetivo desenvolver uma arquitetura que garanta multicast seguro e
escalvel. Essa garantia dada com base numa rvore de distribuio segura.
O Iolus tem uma estrutura bastante semelhante apresentada no item rvore
Hierrquica, com sub-grupos independentes entre si. Alm disso, tambm utiliza a
idia de vrias chaves criptogrficas diferentes.
Um dos problemas que afetam a escalabilidade de um grupo so as mudanas de
chave. Muitas vezes, a atualizao chega tarde ao destino (quando no mais til) ou,
no pior dos casos, nem chega.
No Iolus, a rvore composta de um nmero de sub-grupos organizados
hierarquicamente, criando um grupo virtual nico para multicast seguro. Por
simplicidade, sub-grupos sero denotados simplesmente por grupos. Cada grupo possui
o seu prprio endereo multicast e tambm suas prprias chaves, no havendo uma
chave global para o grupo virtual todo. O sistema tambm independente do protocolo
de roteamento utilizado. Assim, o problema de escalabilidade reduzido, com cada host
se associando ao seu grupo correspondente.
O segundo objetivo assegurar a existncia do grupo virtual nico. Isso
garantido com a existncia de entidades que gerenciam e interconectam os grupos,
chamadas de GSAs (Group Security Agents). Os GSAs compreendem o GSC (Group

Security Controller), que o gerente do grupo virtual; e os vrios GSIs (Group Security
Intermediaries), responsveis pelos grupos menores. Observe a figura abaixo:

Figura 6. Exemplo de rvore no Iolus.

Devido a essa estrutura, poucas mudanas so necessrias para a fonte e

receptores. A principal diferena est no fato de eles fazerem parte de grupos diferentes.
Em relao s entidades, o GSC responsvel geral pela segurana do grupo
virtual. Os GSIs atuam tanto como proxies do trfego multicast quanto como
controladores do grupo do qual so pais. Todo GSI faz parte de dois grupos. Num deles
ele atua como filho (recebendo o trfego multicast); no outro atua como pai, fazendo sua
distribuio.
Mais duas vantagens do Iolus so o gerenciamento distribudo do grupo (sem a
existncia de um ponto nico de falha) e a garantia de ausncia de loops.
Como principais concluses sobre o Iolus podemos citar:
o segurana pela inexistncia de uma chave global para o grupo virtual, qualquer
ataque fica restrito ao grupo do qual o hacker faz parte, reduzindo assim o
universo de possveis hosts comprometidos. Outra vantagem que a chave, se
descoberta, no pode ser arbitrariamente compartilhada com qualquer um, isso
porque ela s vlida naquele grupo especfico.
o Gerenciamento flexvel o agrupamento hierrquico proposto no Iolus permite
delegao de poderes. Imagine uma universidade promovendo uma palestra, e
distribuindo esse contedo via multicast. A universidade controla o GSC. Uma
empresa interessada no contedo cria um GSI para si e, atravs dele, acessa o
GSC. Os funcionrios da empresa, por sua vez, acessam o contedo via o GSI da
mesma. O GSC no precisa saber quais funcionrios esto vendo a palestra, e

sim que o GSI da empresa est ativo. A idia uma extenso do conceito do
IGMP: o roteador (GSC) no precisa saber a identidade de quem est no grupo, e
sim que existe pelo menos um membro nele (GSI).
o Tarifao flexvel relacionada ao gerenciamento, a tarifao tambm fica mais
fcil. A universidade pode cobrar por GSI, ao invs de cobrar por cada membro.
A empresa, por sua vez, repassa seus custos aos funcionrios (ou clientes)
interessados.
Informaes detalhadas do modelo Iolus e de propostas semelhantes podem ser
encontradas em [Mittra 1997] e [Judge e Ammar 2002], respectivamente.

10. Concluso
O tutorial apresentou uma viso geral sobre os principais aspectos envolvidos na
segurana de redes multicast. Foram abordadas questes como confidencialidade,
autenticao e gerenciamento de chaves de grupo. Em relao a problemas de infraestrutura, foram apresentados aspectos envolvendo roteamento e protocolos de
transporte.
Uma concluso geral a que se chega que a segurana em multicast difere da
segurana em unicast por motivos inerentes a natureza de cada um. No primeiro, a
segurana envolve apenas um par de estaes. J no segundo podem haver,
virtualmente, centenas de milhares delas. Essas diferenas afetam principalmente os
protocolos de roteamento utilizados e o gerenciamento das chaves de criptografia.
Da mesma forma que em redes unicast, o nvel de segurana para redes multicast
deve levar em conta fatores como:
o tipo de aplicao algumas aplicaes requerem menos segurana que outras.
Mais ainda: devem ser levadas em conta as diferenas entre autenticao e
confidencialidade;
o Tamanho do grupo e sua dinmica grupos que sofrem muitas alteraes so
inerentemente mais difceis de gerenciar. Da mesma forma, mais fcil aplicar
segurana a grupos pequenos e restritos a uma certa rea geogrfica.
o Escalabilidade por trabalhar com grupos, esse fator deve ser prioridade no
desenvolvimento de qualquer projeto que envolva multicast.
Um fator que tambm deve merecer ateno a poltica de segurana. Aqui,
pode-se incluir questes como quais hosts tm acesso a qu na rede; como a fonte e / ou
grupo so autenticados e qual o algoritmo de criptografia utilizado (chaves pblicas ou
privadas).
De forma a garantir tanto a autenticao quanto a confidencialidade, devem ser
estabelecidas polticas para o gerenciamento das chaves utilizadas para criptografar os
dados. Como mencionado no trabalho, uma boa soluo utilizar a km-keys, apesar de
isso poder acarretar em overhead e complexidade. necessrio tambm especificar em
que camada(s) a autenticao deve ser aplicada
As chaves de grupo devem ser constantemente atualizadas para fazer valer as
regras de forward e backward-secrecy. Essas chaves tambm devem ser entregues nos

momentos devidos, para permitir que os membros do grupo estejam sempre atualizados.
Ainda, interessante que a entrega das mesmas possua algum tipo de confirmao.
Em relao ao roteamento, o objetivo primordial deve ser garantir a integridade
da rvore de distribuio. Como j mencionado, muitos dos problemas que afetam o
roteamento podem ser resolvidos com base nas solues apresentadas nos tpicos de
autenticao, confidencialidade e gerenciamento de chaves. de especial interesse
tambm, desenvolver protocolos de transporte seguros, uma vez que eles podem ser
usados para o transporte das chaves 1 e 2.
Por fim, as melhores alternativas para segurana parecem apontar em duas
direes distintas. A primeira, para esquemas semelhantes ao Iolus, com diviso em
sub-grupos independentes em relao ao roteamento e ao gerenciamento das chaves. A
segunda, para a incorporao de segurana nos protocolos de transporte.

11. Bibliografia
Costa, L. H. M. K., e Duarte, O. C. M. B. (2003) Roteamento Multicast na Internet,
Mini-Curso do XXI Simpsio Brasileiro de Redes de Computadores SBRC' 2003,
Natal, RN, Brasil, Maio, 2003.
Dias, B., Medeiros, J., Alves, N. (2002) Implementao e Aplicao de IP Multicast
em Backbone Metropolitano (Rede Rio) Projeto MCAST, Projeto de final de
curso de graduao, Universidade do Estado do Rio de Janeiro.
Hardjono, T. e Tsudik, G. (2000) IP Multicast Security: Issues and Directions,
Annales de Telecom, Julho-Agosto 2000, pp 324-340.
Huitema, C. (2000) Routing in the Internet, 2nd Edition, Publicado por Prentice Hall
PTR, Upper Sadle River, New Jersey, E.U.A..
Judge, P., Ammar, M. (2002) Gothic: A Group Access Control Architecture for Secure
Multicast and Anycast, IEEE INFOCOM' 2002, New York, E.U.A., Junho, 2002.
Koyabe, M., Fairhurst, G. (2001) Satellite Reliable Multicast Transport Protocol
(SAT-RMTP A Network Tool for Multimedia File Distribution),
http://www.geocast-satellite.com/index2.phtml, Setembro, 2003.
Mittra, S. (1997) Iolus: A Framework for Scalable Secure Multicasting, ACM
SIGCOMM' 97, Cannes, Riviera Francesa, Frana, Setembro, 1997.
Perrig, A., Canetti, R., Song, D., e Tygar, J.D. (2001) Efficient and Secure Source
Authentication for Multicast, Network and Distributed System Security Symposium
NDSS' 2001, San Diego, California, E.U.A., Fevereiro, 2001.
Satmeeting. (2003) Satmeeting, http://www.satmeeting.com.br.
Shamir, A. (1979) Nick Szabo's Papers and Concise Tutorials How to Share a
Secret, http://szabo.best.vwh.net/secret.html, Setembro, 2003.
Shiroshita, T., Sano, T., Takahashi, O. (1997) Reliable Multicast Transport Protocol
(RMTP), Tokyo Research Laboratory IBM Japan, Fevereiro, 1997.

Shiroshita, T., Takahashi, O., Yamashita, M. (1996) Integrating Layered Security into
Reliable Multicast, NTT Information and Communication Systems Laboratories,
Outubro, 1996.
Whetten, B. (1998) RMTP-II Security Considerations, The Secure Multicast Research
Meeting (SmuG), Orlando, Florida, E.U.A., Dezembro. 1998.