E em resultado da execuc~ao do protocolo Skeyx, recorde{se (rever captulo 4), que as entradas da cache de chaves publicas de Die{Hellman de uma entidade27 s~ao criadas e sucessivamente actualizadas.
A criac~ao de uma entrada (ou a sua actualizac~ao) na cache de chaves publicas de Die- -Hellman pode ocorrer, basicamente, em tr^es circunst^ancias28:
1. pela execuc~ao da aplicac~ao s3lkeyxclient, fornecida na distribuic~ao do S3L (ver
secc~ao B.1 do ap^endice B) e que, grosso modo, fornece a possibilidade de, a partir da linha de comando, invocar uma func~aoSkeyx, que inicia o protocolo Skeyx sob o
ponto de vista da entidade cliente29;
2. pela invocac~ao da func~ao Skeyx, no decorrer da execuc~ao de um programa;
25[Ste90] refere
flock,ioctl,read,readv,wait,writeewritevpara a vers~ao 4.3 do BSD. 26Tal de nic~ao ocorre por intermedio da primitiva
siginterrupt. 27Ou melhor, de uma inst^ancia dessa entidade.
28Supondo, em todos os casos, que a necessaria infra{estrutura em termos do PSE e dos demonios
Reencaminhador (s3lforwarder) e Servidor (s3lkeyxserver), se encontra operacional. 29No que se segue, a designac~ao
Skeyxrefere{se a func~ao correspondente ao protocolo homonimo, que
3. por um demonio Servidor (s3lkeyxserver), em resultado de um pedido que lhe foi
reencaminhado pelo demonio Reencaminhador (s3lforwarder).
A primeira hipotese, a qual corresponde uma execuc~ao explcita do protocolo Skeyx, traduz, claramente, uma polticadeantecipac~ao, pela de nic~ao previa de um estado que se prev^e ser util num futuro proximo. Adicionalmente, e se assim o desejar, um programador de aplicac~oes pode tambem invocar, explcitamente, a func~aoSkeyxnos seus programas30, tal como prev^e a segunda hipotese.
Todavia, para o programador de aplicac~oes que recorre a API do S3L, a adopc~ao de in- vocac~oes explcitas de Skeyx (seja indirectamente pela execuc~ao de s3lkeyxclient, seja directamente no seio de um programa) raramente sera desejavel.
O protocolo Skeyx e, fundamentalmente, um pilar do S3L ponto{a{ponto e multiponto, que, para o programador de aplicac~oes, deve passar despercebido o tanto quanto possvel. E nesta ultima perspectiva que se encaixa o mecanismo de invocac~oes implcitas/auto- maticas deSkeyx e que, basicamente, concretiza uma poltica de actualizac~ao das caches por necessidade. A utilidade deste mecanismo revela{se no acto da de nic~ao de contextos S3L (viaS3Lmake S3LCtx), seja previamente a assemblagem de uma mensagem S3L, seja
apos a recepc~ao de tais mensagens:
pretendendo{se enviar uma mensagem S3L para uma entidade ausente da nossa cache, o protocolo Skeyx e executado automaticamente na de nic~ao do contexto S3L, no seio da func~ao S3Lmake S3LCtx, pelo que a invocac~ao subsequente de uma
func~ao de escrita S3L (S3Lwrite, S3Lsend, etc.) ja se processa com um contexto ctx valido, resultante da actualizac~ao da cache. Tomando como exemplo o cliente da gura B.6 (ver secc~ao B.2.8 do ap^endice B), a de nic~ao de um contexto na linha 19 pode implicar a execuc~ao do protocolo Skeyx, sem que o utilizador se aperceba de tal facto, para alem da lat^encia introduzida por essa execuc~ao;
recebendo{se uma mensagem S3L de uma entidade ausente da nossacache
31, ent~ao, para conseguir processar essa mensagem e necessario executar o protocolo Skeyx com tal entidade. Ou seja, sempre que a func~ao de desassemblagem S3Lopen message
(chamada por todas func~oes S3L de leitura | S3Lread, S3Lrecv, etc. |) invoca S3Lmake S3LCtx para de nir um contexto S3L relativo a mensagem S3L recebida, S3Lmake S3LCtxpode concluir da necessidade de executar o protocolo Skeyx32, para o que devera invocar a func~aoSkeyx.
Esta sucess~ao de acontecimentos, esquematizada na gura 5.11, pode ocorrer, por exemplo, na linha 39 do servidor da gura B.7 (ver secc~ao B.2.8 do ap^endice B ). Para invocar a func~ao Skeyx, S3Lmake S3LCtx necessita de lhe fornecer, entre ou-
tros par^ametros, a identi cac~ao X.500 da entidade remota e o endereco IP des- sa entidade, valores que, por sua vez, ter~ao de ser fornecidos a S3Lmake ctx por
30Apesar de, para todos os efeitos, a func~ao
Skeyxse considerar n~ao documentada, uma vez que executa
operac~oes consideradas de caracter privado face ao programador de aplicac~oes que utiliza a API do S3L.
31Tal situac~ao e perfeitamente possvel: se a entidade originadora conseguiu construir a mensagem S3L
e porque disp~oe, na suacache, de uma entrada relativa a entidade receptora, mas criada apos a execuc~ao
do protocolo Skeyx com uma outra replica desta.
32Como se vera ainda nesta secc~ao, essa conclus~ao deriva de dois factos possveis: aus^encia da entrada
S3Lread
S3Lopen_message
S3Lmake_ctx
Skeyx Figura 5.11: Exemplo de execuc~ao implcita do protocolo Skeyx.
S3Lopen message. Todavia, S3Lopen message conhece a sntese MD5 do nome
distinto do originador (recordar a estrutura do cabecalho de uma mensagem S3L na gura 5.3) e n~ao o nome distinto original, pelo que esse facto e indicado a
S3Lmake S3LCtx atraves do valor NSID MD5X500 para o par^ametro nsid daquela
func~ao. Recorde{se que a estrutura das mensagens do protocolo Skeyx, tal como de nidas no captulo 4, contemplam a identi cac~ao do Servidor apenas com base no seu nome distinto X.500. Contudo, veri ca{se agora, no contexto de uma execuc~ao implcita de Skeyx, a necessidade de identi ca{lo tambem pela sntese MD5 do seu nome distinto. Esta forma alternativa de identi cac~ao mantem, praticamente inal- terada, a estrutura das mensagens do Skeyx e, como a sua utilizac~ao se considera do foro interno do S3L (e n~ao propriamente destinada ao programador comum), optou{se por conserva-la no anonimato e relativamente indocumentada.
Finalmente, falta ainda esclarecer a forma atraves da qual S3Lopen messageobtem
o endereco IP da entidade originadora da mensagem. Esse endereco IP corresponde ao campoSource IP Addressde uma mensagem S3L (recordar a gura 5.3). Num
contexto invocador da func~ao S3Lopen messageem que est~ao presentes sockets de Berkeley (como e o caso das func~oes S3Lread, S3Lrecv, etc.), o endereco IP de
origem poderia ser obtido facilmente atraves da primitiva getpeername33. Porem, o uso da func~aoS3Lopen messagen~ao se restringe a desassemblagem de mensagens
recebidas da rede (recorde{se o que foi dito na secc~ao 5.3.3), o que aconselha a utilizac~ao de um mecanismo generico de especi cac~ao do endereco IP da entidade originadora de uma mensagem S3L. No caso concreto, optou{se pela utilizac~ao de um campo Source IP Address da mensagem S3L. A presenca deste campo tem
ainda outro benefcio adicional: a prevenc~ao de ataques do tipoip{spoo ng 34. Ate agora, de niu{se como causa de uma ocorr^encia implcita do protocolo Skeyx a aus^encia de uma determinada entrada nacache.dhcachedo PSE. Existem, porem, outros estados em que uma entrada se pode encontrar e cuja detecc~ao pode tambem desencadear a execuc~ao do protocolo Skeyx com a entidade correspondente.
Na secc~ao 4.5.4, o protocolo Skeyx foi caracterizado como \semi{transaccional" no que diz respeito a actualizac~ao das caches das entidades participantes. Concretamente, o Skeyx garante (tanto quanto o TCP pode garantir) que ambas as entidades atinjam um 33Ou ainda de outras formas em determinados casos espec cos: por exemplo, atraves do par^ametro
struct sockaddr *addrda primitivaacceptparasocketsconectados ou do par^ametrostruct sockaddr
*fromda primitivarecvfromparasocketsconectados e n~ao{conectados.
34Ja em [Bel89] se faz refer^encia a esta categoria de ataques, nos quais o endereco IP de
origem de um pacote e modi cado en{route. Mais recentemente, o CERT Advisory CA-96.21
(ftp://info.cert.org/pub/cert advisories/CA-96.21.tcp syn flooding) descreve outro | o TCP SYN Flooding| que frequentemente ocorre em forma combinada com oip{spoo ng.
estado em que disp~oem de toda a informac~ao necessaria a actualizac~ao das caches, mas n~ao garante o sucesso simult^aneo dessas actualizac~oes, uma vez que a conex~ao TCP e quebrada imediatamente antes de a actualizac~ao das caches se processar. Consequente- mente, e salvaguardando as situac~oes de actualizac~oes parciais35, uma entrada da
cache pode encontrar{se nos seguintes \estados totais":
inexistente: nunca houve tentativas destinadas a sua criac~ao ou, imediatamente antes da sua criac~ao, o processo no seio do qual o Skeyx executava terminou;
(existente) actual: o processo de criac~ao (ou actualizac~ao, conforme o caso), foi levado, com sucesso, ate ao m;
(existente) obsoleto: uma entrada actual foi marcada comoobsoleta.
Uma entrada actual torna{se obsoleta quando se passa a designar a chave acordada
DHagreedkey a existente por DHagreedkey.old. Obviamente, na mesma entrada n~ao
podem coexistir uma chave actual e uma chave obsoleta, correspondendo essa situac~ao, para todos os efeitos, a uma corrupc~ao da entrada.
Ascripts3lmkdhold, fornecida com a distribuic~ao do S3L (ver secc~ao B.1 do ap^endice B), marca como obsoletas todas as chaves acordadas de Die{Hellman guardadas nacache do invocador. Na pratica, isto corresponde a tornar toda a cache obsoleta, por forma a forcar, de uma forma implcita, novas execuc~oes do protocolo Skeyx que ir~ao actualizar, progressivamente, acache. A detecc~ao da obsolesc^encia de uma entrada e feita pela func~ao
S3Lmake S3LCtxdurante a de nic~ao de um contexto S3L. Como desse contexto faz parte
a chave acordada de Die{Hellman36, a aus^encia dessa chave (na pratica, a aus^encia da entrada nacache) ou a sua obsolesc^encia desencadeiam a execuc~ao implcita do protocolo Skeyx.
S~ao varias as causas que podem ditar a obsolesc^encia da totalidade dacache: modi cac~ao dos par^ametros publicos de Die{Hellman;
modi cac~ao das chaves (publica e privada) de Die{Hellman do dono dacache; para \resolver" esta situac~ao, e dispondo cada entrada nacacheda chave publica de Die- -Hellman da entidade correspondente, bastaria recombinar a chave privada do dono dacachecom aquelas chaves publicas para obter as novas chaves acordadas. Todavia, se o dono da cache enviasse agora uma mensagem S3L a uma das entidades com entrada nacache, essa entidade n~ao conseguiria abrir a mensagem, porque iria usar uma chave acordada desactualizada37. Assim, e prefervel detectar, na origem, a 35Estas situac~oes dever~ao ser, em princpio, raras, motivadas, por exemplo, por quebras de energia e
outros imponderaveis. Nessas circunst^ancias, devera ser feita uma inspecc~ao manual a cada entrada da
cache. A \corrupc~ao" de uma entrada e detectavel pela aus^encia de uma parte dos cheiros (o que signi ca
que a criac~ao foi parcial) ou pela presenca de copias suas de seguranca (o que signi ca que o processo de actualizac~ao n~ao foi levado ate ao m). O procedimento a seguir em ambos os casos deve ser a eliminac~ao da entrada, na esperanca de que uma futura criac~ao (explcita ou implcita) seja bem sucedida.
36Recorde{se a de nic~ao da estrutura
S3LCtxna secc~ao 5.3.2.
37Na realidade, a func~ao
S3Lopen message acautela, por seguranca, esta situac~ao: se a de nic~ao de um contexto S3L via S3Lmake S3LCtx e bem sucedida mas a autenticac~ao da mensagem falha, ent~ao
S3Lopen messagedespreza a mensagem recebida e termina executando Skeyx | desde que o par^ametro skeyx called n~ao venha devolvido de S3Lmake S3LCtxaS3LTRUE, sinal de que um Skeyx teria ocorrido no seu interior |, garantindo assim que, na recepc~ao das proximas mensagens, a entrada dacacheja esta
presenca de uma chave acordada obsoleta e executar, automaticamente, o protocolo Skeyx com a entidade remota, na proxima assemblagem de uma mensagem S3L a ela destinada;
modi cac~ao do PIN (induzida, eventualmente, pelo seu compromisso) do dono da cache; recorde{se que todas as chaves acordadas de Die{Hellman presentes na cacheest~ao cifradas com base numa chave DES derivada do PIN; na aus^encia de uma aplicac~ao especi camente destinada a decifrar, com o PIN antigo, todas as chaves acordadas e a cifra{las com o novo, uma forma indirecta de conseguir o mesmo efeito e marcar essas chaves como obsoletas e con ar no mecanismo de execuc~oes implcitas do protocolo Skeyx a m de assegurar a aplicac~ao do novo PIN;
modi cac~ao da identi cac~ao (nome distinto) do dono da cache; essa identi cac~ao corresponde ao sujeito dos certi cados das chaves RSA; na pratica, isto corresponde a mudanca da identidade de uma entidade e deve ser, em princpio, um evento raro; revogac~ao ou modi cac~ao das chaves (publica e privada) RSA preservadas no PSE; uma vez que estas chaves s~ao essenciais a autenticac~ao das mensagens do Skeyx, e natural que uma entidade opte por reconstruir a sua cache com base na utilizac~ao das novas vers~oes destas chaves38.
Atendendo ao que foi dito sobre os \estados totais" de uma entrada nacache, a gura 5.12 apresenta todas as combinac~oes possveis entre um par de entradas, relativas a duas entidades diferentes, A e B. cache B cache B 1 4 2 3 5 6 B: DHagreedkey.old B: DHagreedkey B: DHagreedkey A: B: B: B: cache A cache A A: DHagreedkey A: DHagreedkey.old A: DHagreedkey A: DHagreedkey.old A: DHagreedkey.old
Figura 5.12: Possveis estados de um par de entradas em duas caches distintas. A combinac~ao \estavel", para a qual todas as outras tendem e, obviamente, a com- binac~ao 4, com ambas as caches actualizadas. O mecanismo de actualizac~oes implcitas actua da seguinte forma, para as outras combinac~oes:
1 <A:,B:>: nem A, nem B possuem entrada recproca, nas suas caches; se um deles decidir enviar uma mensagem S3L ao outro, a func~ao S3Lmake S3LCtx detecta a
aus^encia da entrada e invoca Skeyxautomaticamente;
38A situac~ao de compromisso da chave privada, usada no calculo das assinaturas
Csig e Ssig |
2 <A:,B:DHagreedkey>: apenas uma das entidades (neste caso B) possui uma en- trada e actualizada; se A decide enviar uma mensagem S3L a B, ent~ao, em A,
S3Lmake S3LCtxexecutaSkeyxautomaticamente; se B decide enviar uma mensagem
S3L a A, ent~ao, em A,S3Lmake S3LCtxtambem invocaSkeyxautomaticamente; em
ambos os casos a causa da execuc~ao deSkeyxpor A e a aus^encia de entrada relativa
a B;
3 <A:,B:Dhagreedkey.old>: A n~ao possui entrada relativa a B, mas B possui entrada relativa a A, embora obsoleta; se A decide enviar uma mensagem S3L a B, ent~ao, em A,S3Lmake S3LCtxinvocaSkeyxautomaticamente porque n~ao se detectou a entrada
de B; se B decide enviar uma mensagem S3L a A, ent~ao, em B, S3Lmake S3LCtx
tambem executa Skeyx automaticamente, porque B detecta a obsolesc^encia da sua
entrada;
5 <A:DHagreedkey,B:DHagreedkey.old>: A possui entrada actualizada relativa a B e B possui uma entrada obsoleta relativa a A; se A envia uma mensagem S3L a B, ent~ao, em B, S3Lmake S3LCtx detecta a obsolesc^encia da sua entrada e executa Skeyx,
apos o que continua o processamento da mensagem S3L recebida; se B pretende enviar uma mensagem S3L a A, ent~ao, em B, S3Lmake S3LCtxdetecta, a partida, a
obsolesc^encia da entrada de A e executaSkeyx para corrigir essa situac~ao;
6 <A:DHagreedkey.old,B:DHagreedkey.old>: A e B possuem ambos entradas recprocas obsoletas; o primeiro a enviar uma mensagem S3L ao outro provoca a actualizac~ao de ambas as entradas.
Resumindo, o S3L possibilita a adopc~ao de duas polticas de actualizac~ao da cache: por antecipac~ao, com base na utilizac~ao da aplicac~ao s3lkeyxclient, e por necessidade, invocando a func~ao Skeyxsempre que tal e julgado oportuno pela func~ao de de nic~ao de
contextos S3Lmake S3LCtx, sendo este ultimo mecanismo o mais discreto e adequado ao
Comunicac~ao Segura Multiponto
via S3L
Conclui{se, neste captulo, a apresentac~ao da arquitectura do S3L, com a descric~ao das ex- tens~oes necessarias a sua operac~ao num contexto de comunicac~ao multiponto. As extens~oes multiponto em quest~ao suportam as mesmas qualidades de servico oferecidas pelo S3L ponto{a{ponto (Privacidade, Autenticac~ao1, Integridade, Sequenciac~ao { contra ataques- -de{repetic~ao { e Compress~ao) mas assumindo como protocolo base de comunicac~ao a variante multiponto do IP, vulgo IP Multicast2 [Dee89].
Basicamente, o IP Multicast assenta na utilizac~ao do protocolo User Datagram Protocol (UDP) [Pos80a] (protocolo n~ao{orientado{a{conex~ao, que segue uma poltica de entrega de melhor esforcoe n~ao garante sequenciac~ao), com o objectivo de fazer chegar um datagrama a um conjunto de sistemas de destino, constitudos num grupo identi cado atraves de um endereco IP de classe D (gama [224.0.0.0, 239.255.255.255]).
A utilizac~ao do IP Multicast como protocolo de comunicac~ao em grupo num ambiente sensvel em termos de Seguranca n~ao pode ser feita sem a introduc~ao de servicos adicionais. Por um lado, a junc~ao a um determinado grupo IP Multicast n~ao encontra obstaculos de natureza selectiva, ou seja, um sistema dispondo de interfaces de rede com capacidades multiponto pode aderir a qualquer grupo, sendo su ciente a execuc~ao de um conjunto mnimo de operac~oes sobre sockets de Berkeley (ver, por exemplo, o cliente S3L multiponto da secc~ao B.2.8 do ap^endice B). Adicionalmente, a junc~ao so e necessaria caso se pretenda receber o trafego espec co desse grupo. A gerac~ao de trafego dirigido ao grupo pode ser feita por entidades que n~ao pertencem ao grupo, o que introduz oportunidades obvias para ataques do tipo negac~ao{de{servico.
A gura 6.1 representa uma possvel soluc~ao para o problema da permeabilidade dos grupos IP Multicast: a constituic~ao de um subgrupo seguro, do grupo mais abrangente identi cado por um determinado endereco IP de classe D. O trafego do subgrupo segu- ro e sujeito a medidas especiais de protecc~ao (em termos de Privacidade, Autenticac~ao, 1Neste caso incluindo, para alem da N~ao{Repudiac~ao, o Controle de Acesso (ver \Controle de acesso
ao grupo" na secc~ao 6.2.1).
2Re ra{se que, ao longo deste captulo, o
IP Multicast n~ao sera, em si mesmo, objecto de analise
aprofundada, uma vez que se assume, sobretudo, como um instrumento de trabalho disponvel para, sobre ele, concretizar os protocolos aqui descritos. Refer^encias como [Dee89, Fen96, SM96, SRL96] constituem boas fontes de informac~ao sobre o tema, sendo [Hur97] uma sntese bastante recente do estado da arte.
grupo IP Multicast
Legenda:
tráfego seguro (SKIP/S3L) tráfego inseguro não-membro subgrupo seguro
Figura 6.1: Subgrupos seguros e inseguros sobreIP Multicast.
etc.) que o \isolam" dos elementos do subgrupo complementar, bem como de trafego eventualmente gerado por n~ao{membros.
Neste captulo, s~ao apresentados dois conjuntos de protocolos que governam a criac~ao, gest~ao e operac~ao de subgrupos seguros de grupos IP Multicast. Na linha do captulo anterior, introduzem{se, em primeiro lugar, as extens~oes multiponto do SKIP, preparan- do--se assim o terreno para a de nic~ao das extens~oes multiponto do proprio S3L. Mais uma vez, colocar{se{a ^enfase na complementaridade entre as duas abordagens.
Em jeito de antecipac~ao, podemos adiantar que o modelo de programac~ao obtido pela introduc~ao das extens~oes multiponto do S3L e muito semelhante ao da variante ponto- -a{ponto: a inicializac~ao de um \contexto multiponto", segue{se a utilizac~ao das \primi- tivas" S3Lsendtoe S3Lrecvfromque detectam, automaticamente, a variante multiponto
ou ponto{a{ponto do S3L e actuam em conformidade. 6.1 Extens~oes Multiponto ao SKIP
Tradicionalmente, a distribuic~ao de chaves num contexto de comunicac~ao multiponto ba- seia{se na exist^encia de um Centro de Distribuic~ao de Chaves (KDC3) que fornece, a cada elemento do grupo, a chave{do{grupo. Com base nessa chave, cada elemento tem acesso de leitura e escrita ao trafego do grupo.
Todavia, [AP95] identi ca dois problemas fundamentais nesta abordagem:
1. a mudanca dachave{do{grupon~ao e escalavel relativamente ao numero de elementos do grupo: para um grupo numeroso, o KDC podera ter di culdades em fornecer,