2.2 V ERDISETTING OG PRIORITERING 22
2.2.5 Område med lite data eller usikker status
O fornecimento de seguranca ao nvel da Camada de Rede tem sido, ultimamente, objecto de intensa actividade de investigac~ao e desenvolvimento. Nesse sentido, t^em sido sugeridas extens~oes ao IP actual (e.g., [Atk95a, Atk95b, Atk95c]), enquanto a migrac~ao para a vers~ao 6 [Dee95] (que contempla de base opc~oes de seguranca66) n~ao se processa.
As abordagens que iremos apresentar de seguida constituem exemplos nessa linha recorrendo a mecanismos de encapsulamento capazes de oferecer seguranca e transpar^encia em simult^aneo. Em particular, o SKIP sera alvo de uma analise mais detalhada, uma vez que serviu de ponto de partida a concepc~ao do S3L.
3.4.1 swIPe
O swIPe [IB93] pretende ser uma resposta as di culdades sentidas pela aplicac~oes, num Sistema Distribudo, relativamente ao estabelecimento de comunicac~oes seguras com base
62Do ingl^esPersonal Security Environment. 63Do ingl^esPersonal Identi cation Number.
64Chave essa conhecida por Public Root Key e que e a unica chave publica de uma autoridade de
certi cac~ao (CA) que n~ao foi certi cada, uma vez que diz respeito a CA que encabeca a hierarquia de certi cac~ao.
65Do ingl^esForward Certi cation Path.
numa infra{estrutura TCP/IP, e opta pelo fornecimento de seguranca a um nvel su cien- temente baixo para que esse processo seja, na pratica, transparente as aplicac~oes.
Concretamente, o swIPe e um protocolo de encapsulamento de datagramas IP, capaz de assegurar Autenticac~ao, Integridade e Con dencialidade ao nvel da Camada de Rede67. O encapsulamento dos datagramas IP (possivelmente cifrados) e feito no interior de outros datagramas IP68de um novo tipo (
IPPROTO SWIPE), conjuntamente com a possvel adic~ao de informac~ao de controlo de Autenticac~ao e Integridade. Esta abordagem tem, segundo [IB93], algumas vantagens evidentes:
uma vez que os datagramas IP s~ao encapsulados dentro de outros datagramas IP, eles podem transitar por trocos da rede que desconhecem o swIPe;
dado que o encapsulamento e desencapsulamento pode ocorrer em qualquer ponto onde se processem datagramas IP69 (
i.e., nos routers ou nos sistemas nais) ent~ao, com o swIPe, e possvel seguranca Fim{a{Fim (encapsulamento no sistema de origem e desencapsulamento no sistema de destino) ou Ligac~ao{a{Ligac~ao (encapsulamento e desencapsulamento tambem nos nos intermedios);
e possvel implementar uma variedade razoavel de polticas de seguranca pela de- cis~ao de encapsular (ou n~ao) datagramas ou de aceitar (ou n~ao) datagramas (que podem estar ou n~ao encapsulados), com base no seu endereco de destino e origem, respectivamente.
Sob Unix, o swIPe e implementado com base numa interface de rede virtual70, swn (com n igual a 0, 1, etc.), e em direcc~ao a qual s~ao estabelecidas rotas por omiss~ao. O processamento de pacotes IP e feito no nucleo71 do sistema operativo, devidamente modi cado para o efeito, enquanto o tratamento de excepc~oes, a gest~ao de chaves e a poltica de seguranca individual com cada maquina cam a cargo de demonios do nvel utilizador.
Apesar dos grandes benefcios que a sua abordagem transparente pressup~oe, n~ao po- demos deixar de referir alguns aspectos menos positivos do swIPe:
a gest~ao de chaves implica, frequentemente, a comunicac~ao entre demonios em ma- quinas diferentes. Essa comunicac~ao n~ao usa (declaradamente) as qualidades de servico oferecidas pelo swIPe. Logo, caso n~ao se aplique um outro mecanismo capaz de assegurar Autenticac~ao, Integridade e Con dencialidade do trafego das mensagens de gest~ao de chaves, toda a estrutura de seguranca do swIPe podera car em risco; no swIPe, as polticas de seguranca s~ao estabelecidas tendo como sujeito a maquina/sis-
tema, ou seja, todo o trafego de e para esse sistema e afectado pelas exig^encias da poltica individual adoptada em relac~ao a esse sistema. Logo, para aplicac~oes que 67Ou seja, o swIPe n~ao contempla outra protecc~ao que n~ao a de datagramas IP. Ficheiros e outros objectos
de um Sistema Distribudo t^em quer ser protegidos com recurso a outros mecanismos complementares.
68De uma forma analoga ao mecanismo posteriormente \normalizado" pelo protocolo
IP{inside{IP
(IPIP) [Sim95, Per95].
69Desde que haja suporte instalado para o swIPe, obviamente. 70Do ingl^es
virtual network interface, em termos conceptuais semelhante ao mecanismo sugerido por
[Bel90].
71Do ingl^es kernel.
n~ao necessitem de seguranca (ou necessitam apenas de um subconjunto das quali- dades de servico automaticamente asseguradas), existira sempre uma penalizac~ao indesejada.
3.4.2 Simple Key Management for Internet Protocols
O Simple Key Management for Internet Protocols (SKIP) [AP95, AMP95c] e, prima- riamente, um esquema de distribuic~ao de chaves, com base nas quais se torna possvel assegurar Autenticac~ao, Integridade e Con dencialidade na troca de pacotes IP. Particu- larmente bem adaptado a protocolos n~ao{orientados{a{conex~ao (como o IP), em ambas as suas modalidades de comunicac~ao ponto{a{ponto e multiponto, o SKIP fornece, neste ultimo caso, uma boa escalabilidade na distribuic~ao de chaves.
Ao contrario de outras abordagens a seguranca na Camada de Rede (e.g., swIPe), o SKIP n~ao necessita de uma comunicac~ao previa entre as partes interessadas, a m de estabelecer e actualizar chaves de sess~ao. O SKIP usa chaves individuais para cada pacote, que viajam integradas no proprio pacote.
Este esquema de operac~ao e possvel porque o SKIP recorre a Troca de Chaves de Die- -Hellman, a qual, recorde{se (ver secc~ao 2.7.4.), permite o estabelecimento de uma chave secreta, entre duas partes, desde que cada uma delas conheca a chave publica de Die- -Hellman da outra72. Adicionalmente, o SKIP pressup~oe a disponibilidade de certi cados X.509 dessas chaves publicas. Uma vez estabelecida a chave secreta de longa durac~ao (cha- ve essa que permanece valida enquanto forem validas as chaves publica e privada de Die- -Hellman de cada uma das partes), dela faz{se derivar uma chave mestra K
ij, a qual sera usada como chave{de{encriptac~ao{de{outras{chaves.
Cada pacote IP e protegido com uma chave K
p, gerada aleatoriamente e por sua vez cifrada com K
ij. Uma vez que as chaves K
ij podem ser mantidas em cache, ent~ao a protecc~ao individual de cada pacote torna{se viavel, dado que n~ao e necessario efectuar operac~oes de chave publica (lentas, por natureza) a m de gerarK
ij, cada vez que K
ij e necessaria para cifrarK
p.
Tudo o que o receptor do pacote tem a fazer e: identi car o emissor73, adquirir a sua chave publica de Die{Hellman devidamente certi cada74, combina{la com a chave privada de Die{Hellman propria, gerar a chave secreta comum, dela derivar K
ij, usar K
ij para decifrar K
p (que viaja no pacote) e nalmente usar K
p para decifrar o resto do pacote e comprovar a sua Autenticidade e Integridade.
Note{se que, apesar de K
p poder ser gerada individual e aleatoriamente para cada pacote, tal n~ao e estritamente necessario. Pode optar{se por uma poltica que conceda uma determinada vida util (em termos de tempo ou de quantidade de trafego protegido) a K
p, so ao m da qual sera gerada uma nova chave K
p.
Por sua vez, e tambem conveniente mudar a propria chave mestra K
ij. Tal n~ao so di culta a analise criptogra ca dos pacotes como tambem previne a reutilizac~ao de chaves 72Note{se que o SKIP n~ao depende exclusivamente, em termos conceptuais, da Troca de Chaves de Die-
-Hellman. Qualquer algoritmo de chaves publicas que permita a gerac~ao de uma chave secreta comum pela combinac~ao da chave privada de uma parte com a chave publica de outra, e igualmente candidato a ser usado numa implementac~ao do SKIP.
73O que, nas implementac~oes actuais do SKIP, corresponde a identi car o endereco IP de origem. 74Junto de uma autoridade de certi cac~ao ou atraves da execuc~ao de um protocolo espec co com o
K
p eventualmente comprometidas . A mudanca da chave K
ij pode ser induzida pela actualizac~ao das chaves publica e privada de Die{Hellman de qualquer uma das partes. Em relac~ao a chave publica isso signi ca tambem a emiss~ao de um novo certi cado e a revogac~ao do anterior. Se se desejar uma actualizac~ao rapida de K
ij, este processo pode introduzir demoras inaceitaveis, pelo que o SKIP opta por associar um contador n a K
ij e que serve, fundamentalmente, para de nir a sua vers~ao, quando gerada por um determinado processo que devera ser comum a ambas as partes. Se o n viajar em cada pacote, ent~ao o destinatario ca a saber qual a vers~ao de K
ij usada e gera, localmente, K
ijn. Note{se que, para alem de evitar a reutilizac~ao de chaves K
ijn (caso tenham sido comprometidas), o incremento de n fornece tambem uma protecc~ao contra ataques{de{ repetic~ao.
O SKIP apresenta tambem uma soluc~ao propria ([AMP95e]) para a distribuic~ao de chaves num grupo onde a comunicac~ao se faz com a variante multiponto do IP (IP Mul- ticast). Tradicionalmente, sup~oe{se a exist^encia de umCentro de Distribuic~ao de Chaves (KDC)76 que fornece a chave de sess~ao aos elementos do grupo. O trafego multiponto e ent~ao cifrado com essa chave. Segundo [AP95], esta abordagem tem pelo menos dois inconvenientes:
1. a (re)distribuic~ao de chaves pode consumir demasiado tempo em grupos de dimens~oes consideraveis. Mesmo em grupos pequenos, se a poltica de gest~ao de chaves ditar actualizac~oes frequentes por parte do KDC, ent~ao a actividade do grupo pode ser penalizada, uma vez que a troca de mensagens podera car temporariamente sus- pensa ate que a nova chave seja disseminada por todo o grupo (a n~ao ser que se opte pela utilizac~ao da chave antiga enquanto n~ao se receber a nova);
2. a utilizac~ao da mesma chave por todos os elementos do grupo pode impedir a adopc~ao de determinadas cifras de uxo77, conhecidas que s~ao as vulnerabilidades desta classe de cifras no que diz respeito a analise criptogra ca do seu produto cifrado, quando se efectua a reutilizac~ao de chaves78.
O SKIP resolve estes problemas atraves de mecanismos semelhantes aos usados na comunicac~ao ponto{a{ponto. Uma entidade designada por \dono do grupo" (no fundo, um KDC adaptado a gest~ao das chaves que circulam num grupo) detem uma Chave de Interc^ambio do Grupo (GIK)79, que mais n~ao e que uma
chave{de{encriptac~ao{de{ chaves, semelhante a chaveK
ij. Por forma a enviar mensagens cifradas para o grupo, um membro deve solicitar ao dono do grupo (cuja identidade devera ser, antecipadamente, bem conhecida) a chave GIK, o que devera ser feito recorrendo a comunicac~ao ponto{a{ ponto protegida pelo proprio SKIP. Com base na consulta a uma Lista de Controle de Acesso (ACL), o dono do grupo decide (ou n~ao) fornecer a GIK. Uma vez na posse da GIK, um membro pode gerar aleatoriamente chavesK
p, espec cas para cada pacote e que o acompanham, devidamente cifradas com a GIK (a qual, recorde{se, e compartilhada por todos os elementos do grupo). Assim sendo, cada membro usa uma chave K
p diferente, 75Uma vez que estas, recorde{se, s~ao cifradas com
Kij. 76Do ingl^esKey Distribution Center.
77Do ingl^esstream ciphers. 78Ver [Sch96], pags. 197{199. 79Do ingl^esGroup Interchange Key.
cujo tempo de vida ca ao seu criterio. Quanto a GIK, ela podera tambem ter um tempo de vida limitado, ao m do qual todos os membros devem solicitar ao dono do grupo uma nova GIK. Naturalmente, espera{se que esse tempo de vida seja su cientemente lato para que o processo de requisic~ao de uma nova GIK n~ao ocorra t~ao frequentemente de modo a diluir as vantagens que a sua utilizac~ao pressup~oe.
Sob UNIX80, a implementac~ao do SKIP comporta tr^es modulos [AP95]:
1. demonio de gest~ao de chaves (skip keymgrd), no nvel do utilizador. Mantem uma
base de dados com os certi cados das chaves publicas de Die{Hellman, gera as chaves K
ij (e conserva{as em cache) e tambem as chaves K
p;
2. modulo generico de encriptac~ao/desencriptac~ao, no nucleo do sistema operativo, que opera com base nas chaves fornecidas pelo skip keymgrd ou pelo modulo de
streams81 (ver a seguir);
3. modulo de streams, tambem no nucleo do sistema operativo, inserido entre o IP e a interface de rede. Com base no endereco IP de destino (durante a emiss~ao) ou de origem (durante a recepc~ao) dos pacotes, e na poltica ditada pelas ACLs, este modulo solicita a encriptac~ao ou desencriptac~ao, respectivamente, dos pacotes IP. Esta abordagem, claramente integrada na Camada de Rede, e completamente transpa- rente as aplicac~oes, que bene ciam assim de seguranca nas suas comunicac~oes sem neces- sidade de serem modi cadas. A semelhanca do swIPe, o SKIP tambem e uma abordagem que pode fornecer n~ao so seguranca Ligac~ao{a{Ligac~ao (bastando que se con gurem todos os nos intermedios a m de executarem o SKIP) como tambem Fim{a{Fim (em que o SKIP actua apenas na origem primaria e no destino nal dos pacotes), dado que, funda- mentalmente, ambas as abordagens optam por mecanismos de intercepc~ao do trafego IP conceptualmente semelhantes. Essa semelhanca estende{se tambem a utilizac~ao do ende- reco IP82 como determinante da (des)encriptac~ao (ou n~ao) dos pacotes, o que pode ser indesejavel para certas aplicac~oes que n~ao querem tirar partido da encriptac~ao automatica. Porem, o SKIP vai mais longe ao sugerir a extens~ao do seu mecanismo de seguranca de base a comunicac~ao multiponto o que, em conjunc~ao com a poltica de gest~ao de cha- ves, perfeitamente adaptada a aplicac~oes n~ao{orientadas{a{conex~ao83, in uenciou decisi- vamente a concepc~ao e o desenvolvimento do S3L84. Recorde{se que um dos objectivos perseguidos pela presente dissertac~ao e precisamente a seguranca da comunicac~ao em gru- po, tomando o IP Multicast | que e n~ao{orientado{a{conex~ao | como protocolo base de comunicac~ao.
80Concretamente, em Solaris.
81A traduc~ao \modulo de uxo" perderia signi cado, pelo que se optou por conservar o termostreams. 82De origem ou de destino, conforme as circunst^ancias.
83A este proposito, recorde{se o exemplo contrario fornecido pelo SSL, que necessita de trocar chaves
secretas e outros par^ametros criptogra cos (ou seja, necessita de criar estado) sempre que pretende esta- belecer uma sess~ao | embora se reconheca que todas as conex~oes dentro dessa sess~ao ir~ao bene ciar dessa troca previa.