conception des blocs du multiplicateur sous cadence

As abordagens apresentadas constituem uma pequena amostra das propostas actualmente disponveis em termos de Seguranca em Sistemas Distribudos. Um facto e indiscutvel: n~ao existe uma soluc~ao ou modelo ideal para o problema da Seguranca em Sistemas Dis- tribudos. Abordagens de alto e de baixo nvel t^em os seus meritos e fraquezas proprias. Resumindo [CLA+96]:

 vantagens da seguranca integrada nas aplicac~oes:

{ as aplicac~oes podem decidir quais os dados que dever~ao estar sujeitos a medidas especiais de seguranca;

{ assumindo que as aplicac~oes se encarregam de todas as operac~oes de seguranca, ent~ao n~ao ha necessidade de depositar conanca em entidades de mais baixo nvel;

{ n~ao e necessario transferir chaves para camadas mais baixas e, portanto, a visibilidade desta informac~ao (crtica) ca limitada;

 desvantagens da seguranca integrada nas aplicac~oes:

{ ao ligar intimamente a infra{estrutura de seguranca com as aplicac~oes (na propria aplicac~ao ou numa biblioteca), o comportamento dessa infra{estrutura e susceptvel de ser in uenciado por outra aplicac~ao;

{ num contexto em que diferentes arquitecturas e algoritmos de seguranca emer- gem rapidamente, a interoperabilidade entre aplicac~oes e n~ao so um requisito cada vez mais solicitado como tambem exige um esforco crescente por parte dos programadores de aplicac~oes;

{ a escalabilidade das aplicac~oes pode car comprometida se tomarem a seu cargo tarefas como a gest~ao de chaves (gerac~ao, armazenamento, troca, etc.);

 vantagens da seguranca ligada a Camada de Rede:

{ mecanismos e interfaces s~ao iguais para todas as aplicac~oes que residem na mesma maquina. Uma vez provada a correcc~ao e seguranca desses mecanismos, todas as aplicac~oes podem tirar deles proveito de igual forma;

{ o acesso a bases de dados (possivelmente distribudas) de chaves e transparente, sob o ponto de vista das aplicac~oes. Tal facilita a gest~ao de chaves, a qual pode ser feita com base em mecanismos mais uniformes;

{ sistemas intermediarios (e.g., routers) podem aplicar operac~oes de seguranca nos pacotes, facilitando a implementac~ao de redes privadas virtuais erewalls;  desvantagens da seguranca ligada a Camada de Rede:

{ as aplicac~oes t^em que conar incondicionalmente na Seguranca supostamente fornecida pelos nveis hierarquicos mais baixos;

{ a Seguranca e levada a cabo sempre da \mesma" forma, sem levar em conta o signicado (que so as aplicac~oes conhecem) dos dados, o que representa uma perda de exibilidade em relac~ao a aplicac~ao de Seguranca directamente pelas aplicac~oes;

{ a utilizac~ao de chaves especcas para cada aplicac~ao/utilizador e mais difcil de concretizar. Na realidade, isso representaria uma violac~ao da divis~ao que os modelos de comunicac~ao por camadas estabelecem, uma vez que a Camada de Rede teria que levar em conta necessidades especcas de entidades da Camada de Aplicac~ao.

Adicionalmente, e previsvel que a clivagem entre abordagens de alto nvel (maiorita- riamente ao nvel da Camada de Aplicac~ao) e baixo nvel (tipicamente ao nvel da Camada de Rede, em contactontimo com o nucleo dos sistemas operativos) se va progressivamente esbatendo. A tend^encia sera, portanto, para modelos que integrem os diversos aspectos da Seguranca de um Sistema Distribudo nas camadas apropriadas, mas de uma forma com- plementar. Assim, por exemplo [CLA+96], as operac~oes de encriptac~ao e desencriptac~ao seriam realizadas ao nvel da Camada de Rede, usualmente integrada no nucleo do sistema operativo, o que lhes permitiria atingir nveis de desempenho adequados ao tratamento de grandes volumes de dados. Ja o controlo de dispositivos de hardware, eventualmente dedicados a essas tarefas85, seria feito, apropriadamente, pelo sistema operativo. Polticas globais de Seguranca (tipo de algoritmos, chaves, combinac~oes diversas de Autenticac~ao, Integridade e Condencialidade) podem tambem ser impostas a um nvel sucientemen- te baixo de forma a que as aplicac~oes/utilizadores n~ao as possam contornar, se assim se desejar. Todavia, ao nvel das aplicac~oes, devera ser feita a disponibilizac~ao de APIs, bibliotecas e utilitarios que permitam um nvel satisfatorio de programac~ao/congurac~ao das necessidades especcas de Seguranca de cada aplicac~ao.

Por enquanto, e na aus^encia de uma abordagem que proporcione este nvel de inte- grac~ao, ha que optar. Nesse sentido, as tabelas 3.5 e 3.6 poder~ao ser uteis, na medida em que resumem algumas das caractersticas das abordagens tradicionais apresentadas neste captulo.

Em relac~ao a tabela 3.5, o signicado dos termos \implcito" e \explcito" com que se classica o Modelo de Comunicac~ao de cada abordagem e o seguinte [WBSL94]:

 implcito: diz{se do modelo de comunicac~ao para o qual as aplicac~oes/utilizado- res n~ao necessitam de gerir os pormenores da troca de mensagens, lidando com abstracc~oes de alto nvel. A programac~ao segundo o modelo de RPCs e um exemplo tpico de uma abordagem implcita a comunicac~ao;

 explcito: diz{se do modelo de comunicac~ao para o qual as aplicac~oes/utilizadores s~ao responsaveis pela invocac~ao dos servicos de transfer^encia de dados, incluindo a possvel iniciac~ao e terminac~ao de conex~oes. A programac~ao com sockets constitui um exemplo paradigmatico deste modelo.

3. Ab ordagens aCom unica c~ao Segura em Sistemas Distribu dos 52

Abordagem Nvel OSI Modelo de Comunicac~ao Nveis de Seguranca Esforco de Migrac~ao GSS{API 7 (e.g., sobre Independente do Autenticac~ao, Integridade. (Re)Programac~ao com chamadas

RPC, Kerberos) modelo de comunicac~ao. e Condencialidade. a GSS{API.

SNP 7 Explcito. Autenticac~ao, Integ. e Conf. (Re)Programac~ao com chamadas (sobre GSS{API) (interface tiposockets) (derivadas da GSS{API) a API do SNP. KDC necessario.

SSL >4 (7) Explcito. Autenticac~ao, Integridade (Re)Programac~ao com chamadas

(sobresocketsTCP) e Condencialidade. a API do SSL.

Secure RPC 6 Implcito. Autenticac~ao. Nova variante (Re)Programac~ao segundo o AUTHKERBfornece Integridade modelo RPC. Adic~ao explcita

e Condencialidade. de opc~oes de Autenticac~ao. DCE RPC 6 Implcito. Autent., Integ., Autorizac~ao, (Re)Programac~ao segundo o

(sobre Kerberos) e Controle de Acesso. modelo DCE RPC.

Condencialidade opcional. KDC (Kerberos) necessario. Kerberos >4 (7) Explcito Autenticac~ao, Integridade (Re)Programac~ao com chamadas

(sobresockets) e Condencialidade. a API do Kerberos (kerberizac~ao).

KDC (Kerberos) necessario. swIPe 3 Implcito. Autenticac~ao, Integridade Modicac~ao dokernel.

e Condencialidade. Necessita de alguns demonios. SKIP 3 Implcito. Autenticac~ao, Integridade Modicac~ao dokernel.

e Condencialidade. Necessita de alguns demonios. SecuDE >4 (7) Explcito. Autenticac~ao, Integridade (Re)Programac~ao com chamadas

e Condencialidade. as APIs do SecuDE.

3. Ab ordagens aCom unica c~ao Segura em Sistemas Distribu dos 53

Abordagem Algoritmos de Suporte Disponibilidade/Exportabilidade Portabilidade/Plataformas GSS{API Independente. Especicac~ao publica. Exportabilidade de Potencialmente boa.

algumas implementac~oes condicionada.

SNP \Independente"viaGSS{API Exportabilidade condicionada pela imple- Potencialmente boa.

(actualmente DES, RSA e MD5) mentac~ao da GSS{API sobre RSAREF. (via GSS{API)

SSL DES, 3DES, RC2, RC4, IDEA, Especicac~ao publica. SSLRef publico SunOS, Solaris, HP{UX, IRIX RSA, Die{Hellman, Fortezza, mas n~ao exportavel. SSLeay publico e DGUX, OSF, AIX, Win16/32. MD5, SHA. exportavel (origem australiana).

Secure RPC DES e Die{Hellman. Propriedade da Sun. Licenciamento Solaris e SunOS.

necessario. NIS/NIS+ necessario.

DCE RPC \Independente" (DES e MD5 Vers~ao de domnio publico sem Seguranca. Maioria das variantes UNIX. nas implementac~oes actuais) Vers~oes comerciais sujeitas as restric~oes de OpenVMS, Win95, WinNT,

exportac~ao do DES. MacOS, OS/2, AS/400, etc. Kerberos DES. Uso de algoritmos Vers~ao publica do MIT. Varias vers~oes Boa (e.g., vers~ao do OSF DCE;

assimetricos (e.g., RSA) na comerciais. Todas sujeitas as restric~oes de portabilidade da vers~ao do MIT

fase de autenticac~ao previsto exportac~ao do DES, excepto a \vers~ao comparavel a da OSF DCE). em proximas vers~oes. internacional" eBones (Bones+DES).

swIPe Arquitectura \independente". Especicac~ao e implementac~ao publicas. SunOS, Mach, BSDI. (DES, RSA e Die{Hellman Restric~oes de exportac~ao em func~ao

na implementac~ao actual) dos algoritmos criptogracos empregues.

SKIP DES, 3DES, SAFER 128SK, Especicac~ao e implementac~ao publicas. SunOS, Solaris, FreeBSD, IRIX, RC2, RC4, Die{Hellman, Restric~oes de exportac~ao em func~ao Windows 3.11/95/NT, JavaOS. MD2, MD4, SHA, DSA. dos algoritmos criptogracos empregues.

SecuDE DES, 3DES, IDEA, RC2/4, RSA, Codigo de domnio publico e de utilizac~ao SunOS, Solaris, HP{UX, AIX, DSA, DSS, Die{Hellman, gratuita para ns n~ao comerciais. IRIX, OSF1, Linux, AS/400, MD2/4/5, SHA, RIPEMD160. Exportavel (origem alem~a). OS/2, Win95/NT, MSDOS 6.

3.5.1 Outras Abordagens

Existem muitas outras abordagens a Seguranca em Sistemas Distribudos (a maior parte das quais acabam por se enquadrar nas mesmas categorias das que analisamos), mas que, por limitac~oes de espaco e de tempo, n~ao foi possvel analisar em pormenor. A ttulo meramente ilustrativo, cam aqui refer^encias a algumas delas:

 autenticac~ao e distribuic~ao de chaves: SPX [TA91], KryptoKnight [MTHZ92], au- tenticac~ao no sistema operativo Taos [WABL93], SESAME [KPP94];

 seguranca na Camada de Rede: SKEME [Kra95], Photuris[KS], IPSP [Atk95a, Atk95b, Atk95c], NLSP [ISO92b];

 seguranca na Camada de Transporte: TLSP [ISO92a], TLS [DA97];  bibliotecas de func~oes/toolkits: Cryptolib [LMS93], Crypto++

86, Python87, RSAEURO88, RSAREF89, CryptoAPI90, BSAFE91;

 aplicac~oes: secure shell (ssh)

92, Pretty Good Privacy (PGP) [Zim95] 93, Privacy Enhanced Mail (PEM) [Lin93a, Ken93, Bal93, Kal93].