Architecture des jonctions

Finalmente, efectuou{se a avaliac~ao do desempenho das primitivas de comunicac~ao multi- ponto. Concretamente, as combinac~oes sendto+recvfrom por parte de Berkeley e S3Lsendto+S3Lrecvfrompor parte do S3L foram confrontadas, tendo mais uma vez como

pano de fundo a variac~ao da dimens~ao do bloco de dados e a introduc~ao de Compress~ao e Encriptac~ao. Analogamente a outros testes realizados, a dimens~ao das amostras foi 100. O protocolo de comunicac~ao usado foi o UDP8, pelo que a dimens~ao maxima do bloco de dados foi limitada a 63K.

Para a realizac~ao deste teste, executou{se um dono de grupo S3L numa das duas maquinas disponveis. Nessa maquina, instalou{se tambem um processo re ector de trafego IP Multicast. Na outra maquina, executou{se o cliente produtor do trafego origi- nal. Ambos os processos inibiram a recepc~ao de trafegoIP Multicastpor eles gerado a m de garantir a recepc~ao de datagramas originados apenas no outro processo.

Os tempos medidos apresentam{se na tabela 7.6 e o graco correspondente e dado pela gura 7.6. Os resultados obtidos s~ao id^enticos aos produzidos sobre UDP para trafego ponto{a{ponto (ver a tabela 7.4 e a gura 7.4), dado que o grupo constitudo representa uma situac~ao simplicada (elementos na mesma LAN) e que, em termos de tempos de propagac~ao e processamento protocolar, n~ao apresenta variac~oes de registo.

7Correspondente a execuc~ao da func~ao

S3LMjoin group. 8Para o domnio

AFINETapenassocketsdo tipoSOCK DGRAMeSOCK RAWsuportamIPMulticast, sendo

dimens~ao sendto S3Lsendto S3Lsendto + S3Lsendto +

dos + + S3Lrecvfrom S3Lrecvfrom c/

dados recvfrom S3Lrecvfrom c/ Compress~ao Comp. e Encriptac~ao

1K 4280 s 39853 s 55885 s 62191 s 2K 6721 s 42490 s 60058 s 67144 s 4K 10373s 49337 s 70036 s 79802 s 8K 18500s 61752 s 91238 s 109176 s 16K 32551s 88389 s 113891 s 137746 s 32K 67629s 137215s 137564 s 163986 s 63K 127389s 234435s 198559 s 218086 s

Tabela 7.6: Lat^encia das primitivas(S3L)sendtoe (S3L)recvfrommultiponto.

0 50000 100000 150000 200000 250000 300000 350000 1k 2k 4k 8k 16k 32k 63k

dimensão dos dados

tempos de ida e volta (us)

Berkeley IP Multicast S3L multiponto S3L multiponto com compressão S3L multiponto com compressão e encriptação

Figura 7.6: Desempenho das primitivas(S3L)sendtoe (S3L)recvfrommultiponto.

As conclus~oes s~ao, portanto, analogas as produzidas anteriormente num contexto de comunicac~ao ponto{a{ponto: a carga adicional introduzida pelas qualidades de servico do S3L multiponto torna{se menos signicativa, relativamente a utilizac~ao das funcionalida- des de Berkeley normais, na medida em que a Compress~ao dos dados cumprir ecazmente o seu papel de reduzir (em termos de tempos de propagac~ao) o tempo adicional consumido nos processos de Autenticac~ao e Encriptac~ao.

Conclus~oes

O desenvolvimento do S3L considera{se oportuno num contexto onde, apesar de ja se- rem conhecidas abordagens a comunicac~ao segura ponto{a{ponto semelhantes1(como por exemplo o Secure Sockets Layer (SSL) [FKK96]), s~ao poucas as que, em simult^aneo, ofe- recem operac~ao segura de grupos IP Multicast.

Precisamente, uma dessas abordagens e o Simple Key Management for Internet Pro- tocols(SKIP) [AP95, AMP95c] da Sun, que oferece uma soluc~ao transparente para o pro- blema da comunicac~ao segura ponto{a{ponto e multiponto no ^ambito da pilha TCP/IP. Conceptualmente, o S3L assimilou alguns elementos fundamentais da operac~ao do SKIP, nomeadamente a utilizac~ao do acordo de Die{Hellman como ponto de partida para a obtenc~ao de um modelo stateless de operac~ao. Todavia, enquanto o SKIP se situa a um nvel arquitectural relativamente baixo (na Camada de Rede e integrado no nucleo do Sistema Operativo), o S3L localiza{se acima da interface de programac~ao dos sockets de Berkeley. Consequentemente, os mecanismos de operac~ao do S3L acabam por divergir do SKIP, n~ao so em resultado do diferente posicionamento arquitectural de ambos, como tambem pelo facto de que o S3L assenta em servicos criptogracos de base oferecidos pelo Secure Development Environment (SecuDE) [Sch95a].

A face visvel do S3L e uma API atraves da qual os protocolos de comunicac~ao segura ponto{a{ponto e multiponto do S3L s~ao acessveis. Essa API permite uma migrac~ao relati- vamente expedita de aplicac~oes codicadas segundo o modelo tradicional Cliente{Servidor dos sockets de Berkeley para um modelo muito semelhante (na realidade assente sobre o primeiro) capaz de fornecer novas qualidades de servico no ^ambito de uma comunicac~ao segura: Privacidade, Autenticac~ao (incluindo N~ao{Repudiac~ao), Integridade, Compress~ao, Sequenciac~ao (contra ataques{de{repetic~ao) e Controlo de Acesso (na variante multipon- to).

O esquema de operac~ao do S3L apresenta{se, em geral, stateless, a menos da ne- cessaria execuc~ao, pelo menos uma vez, do Skeyx, um protocolo auxiliar de troca de chaves publicas de Die{Hellman n~ao certicadas. Este protocolo dispensa a certicac~ao das cha- ves publicas de Die{Hellman, embora dependa da certicac~ao das chaves publicas RSA dos intervenientes de forma a garantir a seguranca da troca das chaves publicas de Die- -Hellman. Essa depend^encia e, contudo, minimizada: uma entidade comunicante precisa 1Relativamente ao posicionamento em termos da Arquitectura do Sistema Operativo e do Modelo de

Comunicac~oes e n~ao tanto no que diz respeito aos protocolos e mecanismos proprios de operac~ao.

apenas do certicado da sua chave publica RSA, n~ao havendo necessidade de recuperar previamente, de algum repositorio (e.g., a Directoria X.500), o certicado da entidade com quem vai executar o protocolo Skeyx. Evitou{se, assim, um confronto directo com o problema da distribuic~ao de chaves certicadas, mas exige{se que essas chaves sejam certicadas dentro da mesma hierarquia X.509.

Outro aspecto do Skeyx e a necessidade da manutenc~ao de servidores individuais por cada entidade, o que constitui uma abordagem reconhecidamente pouco escalavel. Contu- do, tal opc~ao deveu{se, fundamentalmente, a disposic~ao da cache sob o Personal Security Environment (PSE) do SecuDE, auferindo assim das restric~oes de acesso que exigem a utilizac~ao de um Personal Identication Number (PIN) de conhecimento restrito a cada entidade e que, portanto, n~ao pode ser usado por um unico servidor de chaves publicas de Die{Hellman para todas as entidades de uma maquina.

Como aspectos mais positivos do Skeyx poderemos apontar, entre outros:

 o mecanismo de actualizac~oes \semi{transaccional" destinado a minimizar a hipotese de actualizac~oes com diferentes graus de sucesso nas caches de duas entidades co- municantes; esse mecanismo e ainda complementado pelas actualizac~oes implcitas;  a designac~ao \anonima" das entradas da cache, baseada em snteses MD5 dos nomes

distintos X.500 das entidades correspondentes;

 o mecanismo de acesso concorrente (com trincos do tipo advisory) a cache, partilhado por todos os processos que, no contexto do S3L, necessitam de lhe aceder; este mecanismo, combinado com o algorimto de actualizac~ao das caches, possibilita a manutenc~ao de um estado coerente das mesmas;

 suporte a replicac~ao das caches, i.e., na eventualidade da replicac~ao de uma entidade, o mecanismo de actualizac~oes implcitas efectua a converg^encia das replicas desde que o seu padr~ao de contactos seja semelhante.

Porventura, a maior diculdade na implementac~ao da vers~ao ponto{a{ponto do S3L foi a resoluc~ao do problema da Sequenciac~ao de mensagens sem recurso a preservac~ao, para cada origem possvel, da ultima marca temporal/numero de sequ^encia valido. Tal era indispensavel no sentido de assegurar o caracter stateless do S3L. Adicionalmente, perseguia{se uma soluc~ao independente da sincronizac~ao de relogios dos intervenientes, a qual teria, necessariamente, que assentar num protocolo ja de si seguro. Apesar de a soluc~ao obtida ser, de longe, mais efectiva que a preconizada pelo SKIP no combate a ataques{de{repetic~ao (mais n~ao seja pela reduzida granularidade oferecida pelo S3L), reconhece{se que, na pratica, o problema n~ao cou completamente resolvido porque os criterios de rejeic~ao de mensagens repetidas servem{se de elementos (nomeadamente, tem- pos de propagac~ao) cuja medic~ao rigorosa e difcil. O recurso a estimativas e, portanto, inevitavel, abrindo{se, eventualmente, janelas de ataque.

Na implementac~ao do S3L ponto{a{ponto importa tambem registar algumas opc~oes cujos efeitos se consideram positivos. Por exemplo, o S3L simplica o esquema de iden- ticac~ao do SKIP, utilizando apenas snteses MD5 de nomes distintos para identicar as entidades comunicantes. Para alem da sua simplicidade, o anonimato das entidades e a independ^encia da sua localizac~ao s~ao algumas das vantagens deste esquema. Adicional- mente, no contexto do S3L e possvel gerar mensagens destinadas a armazenamento ou a

outra forma de entrega que n~ao a rede. Essas mensagens s~ao rigorosamente iguais, em ter- mos de aplicac~ao de qualidades de servico (Privacidade, Autenticac~ao, etc.), as mensagens entregues a rede. Resultante de um pormenor de implementac~ao, a presenca do endereco IP de origem numa mensagem S3L ponto{a{ponto (o que n~ao acontece no SKIP) oferece protecc~ao contra ataques do tipo ip{spoong.

Os problemas com a temporalidade e o caracter imprevisvel dos atrasos de propa- gac~ao voltaram a ser sentidos no desenvolvimento do S3L multiponto onde, de novo, o preco a pagar pela manutenc~ao de uma operac~ao essencialmente stateless (a menos da (re)junc~ao ao grupo) e pela n~ao necessidade de sincronizac~ao de relogios entre membros (potencialmente muito dispersos) de um grupo foi a admiss~ao da operac~ao do grupo com chaves que n~ao constituem, necessariamente, a ultima chave{do{grupo gerada pelo seu dono. A opc~ao assumida (que, basicamente, consiste na manutenc~ao de umarraycircular, de dimens~ao parametrizavel, com um conjunto de chaves obsoletas admissveis, para alem da chave mais recente) revela{se mais resistente a estrangulamentos na actualizac~ao da chave{do{grupo junto do dono, evitando a paragem da operac~ao do grupo durante o pro- cesso de actualizac~ao dessa chave. Melhor ainda, livra{se do problema que a utilizac~ao de chaves marginalmente obsoletas (i.e., chaves cuja validade expirou quando a transmiss~ao de mensagens que protegiam estava em curso) constitui.

Recordam{se ainda outros aspectos que orientaram a concepc~ao do S3L multiponto:  o processo de (re)junc~ao e automatico, ocorrendo transparentemente, durante a e-

xecuc~ao de uma \primitiva S3L multiponto" de escrita ou leitura;

 ao contrario do que acontece no SKIP, as Listas de Controle de Acesso operam sobre entidades e n~ao sobre enderecos IP;

 e possvel, nalguns casos, prevenir a criac~ao de um grupo com base num endereco IP Multicast transiente previamente \reservado".

Apesar de submetida a numerosos testes durante o seu desenvolvimento, a implemen- tac~ao actual do S3L carece ainda de uma utilizac~ao sucientemente alargada para que se possam produzir aqui conclus~oes imparciais sobre a sua seguranca, robustez e facilidade de utilizac~ao. Todavia, em termos de desempenho, os testes realizados permitem armar com alguma propriedade que os benefcios obtidos com as qualidades de servico extra (Privacidade, Autenticac~ao, etc.) ultrapassam a inevitavel sobrecarga introduzida pela depend^encia do S3L de criptograa por software (fornecida pelo SecuDE).

Em termos de trabalho futuro, cam abertas algumas vias cuja concretizac~ao permitira, por um lado, simplicar o modelo de operac~ao do S3L e, por outro, actualizar a sua implementac~ao. Fundamentalmente, perspectiva{se:

1. adopc~ao de um esquema de certicac~ao de chaves publicas de Die{Hellman (efec- tuando, se necessario, extens~oes ao SecuDE com esse objectivo) com o m de simpli- car o protocolo Skeyx, ja que o esquema de desao{resposta usado pretende com- pensar a aus^encia dessa certicac~ao; note{se que, a menos da negociac~ao de algorit- mos, o Skeyx poderia ser dispensado caso a certicac~ao de chaves publicas de Die- -Hellman se baseasse numa infra{estrutura distribuda, onde a aquisic~ao (segura) da chave publica de Die{Hellman do destinatario teria lugar antes da transmiss~ao

de qualquer pacote S3L; este cenario corresponderia a um mecanismo verdadeira- mente stateless, sob o ponto de vista das entidades comunicantes, ja que n~ao seria difcil conseguir garantias de suporte comum de um conjunto mnimo de algoritmos standard (e.g. DES, 3DES, IDEA, RC4, MD5, etc.);

2. alternativamente a opc~ao anterior, a evoluc~ao do Skeyx para um modelo de operac~ao que, dispensando certicac~ao RSA, permita ainda a troca segura de chaves publicas de Die{Hellman; em tal modelo, poderia tambem ser contemplada a hipotese de concentrar num unico servidor por maquina a responsabilidade das trocas Skeyx em nome de todas as entidades dessa maquina (a atribuic~ao de privilegios especiais a este servidor teria, no entanto, que ser bem ponderada, ja que se constitui como single{point{of{failure);

3. utilizac~ao de vers~oes mais recente do SecuDE. Estas vers~oes suportam um leque mais alargado de algoritmos, oferecem certicac~ao X.509v3 e viabilizam a utilizac~ao de threads;

4. migrac~ao da implementac~ao actual do S3L para outra plataformas. A restric~ao actual ao sistema operativo Linux resulta, fundamentalmente, de ter sido esse o ambiente de desenvolvimento original do S3L. A extens~ao a outros sistemas operativos da famlia Unix devera ser relativamente expedita. Ja a migrac~ao para a plataforma Windows 95/NT se agura mais problematica, dado que determinados pormenores de implementac~ao tiram partido de caractersticas especcas do UNIX2.

Para terminar, podemos ainda concluir que a construc~ao de protocolos do tipo dos preconizados pelo S3L e um verdadeiro jogo de compromissos, onde cada opc~ao de desenho e implementac~ao deve ser ponderada, na mira do equilbrio sempre difcil entre o objectivo prioritario da Seguranca e as limitac~oes a sua implementac~ao que inevitavelmente surgem, como bem exemplicam os problemas levantados pelo tratamento, sempre complicado, da Temporalidade.

2Neste contexto, e animadora a recente proposta OpenNT da Softway

(http://www.softway.comp/OpenNT/) que, basicamente, oferece um subsistema Unix sobre o kernel

Instalac~ao e congurac~ao do S3L

A.1 Instalac~ao

A distribuic~ao actual do S3L (vers~ao beta 1.0) contem quatro pacotes desoftware: 1. s3l-b01.tgz{ ambiente de desenvolvimento S3L;

2. secude-4.4b0.tgz1 { ambiente de desenvolvimento SecuDE; 3. zlib-1.0.3.tgz{ biblioteca de compress~ao;

4. mrouted-3.8.tgz{ demoniomroutede outros utilitarios de suporte2, para

IPMul- ticast.

O pacotesecude-4.4b0.tgzcontem uma vers~ao do ambiente de desenvolvimento Se-

cuDE, especialmente modicada3a m de ser possvel a distribuic~ao manual dos par^ametros de Die{Hellman. Concretamente, essa modicac~ao operou{se sobre o utilitario

secude-4.4.b0/src/util/psemaint.c, e e visvel na gura A.1. A informac~ao fornecida

neste manual n~ao dispensa a consulta da documentac~ao que acompanha a distribuic~ao do SecuDE 4.4b0, nomeadamente do volume 2 [Sch95d].

A compilac~ao e a instalac~ao dos pacotes contidos na distribuic~ao do S3L devem ser feitas pelo super{utilizador. Assumindo a directoria/tmpcomo directoria de trabalho, os

passos a seguir s~ao:

/tmp# tar zxvf s3l-b01-dist.tgz /tmp# cd s3l-b01-dist

/tmp/s3l-b01-dist# ./make

/tmp/s3l-b01-dist# ./make install

A desinstalac~ao e a eliminac~ao do produto da compilac~ao faz{se tambem atraves da

Makefileprincipal:

1A vers~ao 5.0, introduzida muito recentemente, apresenta algumas modicac~oes que a tornam incom-

patvel com a vers~ao 4.4b0, nomeadamente em termos de APIs, utilitarios e estrutura de directorias. Essas modicac~oes s~ao, nalguns casos, bastante importantes (e.g., a \eliminac~ao" das variaveis globais, o que permitira escrever codigo multithreaded), pelo que se prev^e a migrac~ao futura do S3L para o ambiente SecuDE 5.0.

2Ambos pre{compilados para o sistema operativo Linux. 3O original pode ser encontrado em

ftp://ftp.darmstadt.gmd.de/pub/secude.

.../secude-4.4.b0/src/util# diff psemaint.c.original psemaint.c.patched 4010a4011,4017

> /* begin DH PATCH */

> else if ((dh_parm = d_AlgId(ostr))) { > oid = af_get_objoid(DHparam_name); > aux_free_AlgId(&dh_parm);

> }

> /* end DH PATCH */

Figura A.1: Modicac~ao ao psemaint.c original. /tmp/s3l-b01-dist# ./make uninstall

/tmp/s3l-b01-dist# ./make clean

Qualquer pacote podera ser individualmente compilado, instalado, removido ou de- purado do produto da sua compilac~ao, atraves de Makefiles especcas localizadas nas

directorias de topo de cada um.

A instalac~ao processa{se, por omiss~ao, na subarvore/usr/local. Este comportamento

pode ser modicado atraves da congurac~ao dos cheiros Makefile da distribuic~ao. O

processo de instalac~ao actualiza as seguintes directorias com os cheiros discriminados: 1. /usr/local/lib: libs3l.a,libsecude.ae libz.a;

2. /usr/local/include: zconf.he zlib.h;

3. /usr/local/include/s3l: common.h,keyx.h,skeyx.h es3lsocket.h;

4. /usr/local/include/secude: copia desecude-4.4.b0/src/include;

5. /usr/local/bin: algumas aplicac~oes do SecuDE (cacreate, getpkroot, certify, psecreate, instpkroot, getkey, instcert, pem e psemaint);

aplicac~oes do S3L (s3lforwarder, s3lkeyxserver, s3lkeyxclient, s3ltest, s3lmkdhold, s3lmgowner, s3lmgaclsmaint, s3lmgliste s3lmtest);

6. /usr/local/sbin: demoniomrouted e utilitariosmap-mbone, mrinfo e mtrace;

7. /usr/local/man/man8: manuais de suporte aos utilitariosIP Multicast.

Determinadas aplicac~oes podem ser apenas executadas pelo super{utilizador, como e o caso decacreate, getpkroot, certifye s3lforwarder, pelo que as suas permiss~oes

s~ao devidamente modicadas. Por omiss~ao, o comando s3lmgownere gerado com setuid root a m de que ainda seja possvel a detecc~ao de grupos IP Multicast \pre{activos" quando o invocador desse comando n~ao e o super{utilizador. Este comportamento pode ser alterado editando o cheiro.../s3l-b01-dist/s3l-b01/src/Makefilee comentando