Instituto Superior de Engenharia do Porto. Mestrado em Engenharia Informática Área de Tecnologias do Conhecimento e Decisão

Instituto Superior de Engenharia do Porto Mestrado em Engenharia Informática Área de Tecnologias do Conhecimento e Decisão Sistemas Baseados em Agentes 1020612 Vitor Hugo Barros Maio de 2008

Índice 1Introdução...3 2...4 2.1Definição e História...4 2.2Mobilidade...5 3Vantagens da utilização de...8 4Toolkits de...12 4.1Java nos...15 4.2Aglets...17 5Segurança em...22 5.1Tipos de ameaças...22 5.2Medidas de prevenção...25 6Conclusões...29 7Bibliografia...30 2

1 Introdução No âmbito da disciplina de Sistemas Baseados em Agentes, incluída no Mestrado em Engenharia Informática vertente de Tecnologias do Conhecimento e Decisão, do Instituto Superior de Engenharia do Porto, foram lançados vários temas para pesquisa bibliográfica, entre os quais, o assunto que será o abordado neste documento. É objectivo deste documento definir o que são, bem como apresentar algumas formas típicas de implementação dos mesmos e enquadrá-los na área da computação distribuída. Serão também abordadas algumas frameworks de desenvolvimento de com um maior foco na API Aglets da IBM e, por fim, algumas considerações de segurança fundamentais nesta área uma vez que se tratam de movimentações em redes intra e internet. O documento encontra-se dividido em quatro capítulos principais. No capítulo 2 - é definido este conceito enquadrado-o com algum background histórico. No 3º capítulo Vantagens na utilização de são apresentadas as razões pelas quais devem ser utilizadas aplicações baseadas em. Na secção 4 Toolkits de são analisadas algumas bibliotecas para o desenvolvimento de, descritas as vantagens e desvantagens da utilização da linguagem Java no desenvolvimento seguindo este paradigma e é efectuada uma análise mais profunda à framework Aglets. Por último, no capítulo 5 Segurança em é abordada a problemática da segurança na movimentação de agentes bem como a apresentação de algumas contra-medidas a aplicar para evitar ameaças. 3

2 Nos últimos anos, e principalmente com o exponencial crescimento do número de pessoas e dispositivos com acesso à internet, que, por sua vez, tem vindo a disponibilizar também uma crescente panóplia de serviços e de informação, temse vindo a observar um desenvolvimento elevado nas tecnologias de computação distribuída e de rede [1]. Este desenvolvimento veio despoletar a necessidade de serem criadas aplicações com potencialidades de troca de informação entre redes heterogéneas de uma forma eficaz. Por esta razão foram criados vários paradigmas de desenvolvimento de software para computação distribuída entre os quais podemos destacar os paradigmas Cliente-Servidor, Remote Procedure Calling (RPC) e. 2.1 Definição e História são processos de software capazes de se moverem autonomamente de uma localização de rede física para outra a qualquer altura [1][2][3]. O estado de execução do processo é guardado e é movido para a nova localização juntamente com o código do Agente para que a execução possa ser retomada no novo host [3]. O Agente executa a sua acção quando e onde achar apropriado e não necessita estar previamente instalado no cliente. Desta forma, denota-se um senso de autonomia inerente na mobilidade e execução do agente [2]. 4

Os são uma forma específica dos paradigmas de mobile code e software agents. Contudo, contrariamente aos paradigmas Remote Evaluation (RE) e Code on Demand (CoD), os são activos na forma como decidem migrar entre computadores a qualquer momento da sua execução. Isto faz deles uma ferramenta poderosa para implementar aplicações distribuídas numa rede de computadores [3]. A pesquisa na área de emergiu como uma extensão do paradigma RE, proposto por Stamos e Gillford em 1990 [4]. Em 1999, Kotz e Gray [1] previram que os mais relevantes websites iriam aceitar em poucos anos, enquanto que Milojicic [5] afirmou que, apesar da tecnologia associada aos ter visto um interesse crescente nas comunidades cientificas e na indústria, a implementação esperada da tecnologia não teria emergido até então e poderia inclusive nunca chegar a emergir de todo. O declínio no número de publicações no tópico entre 1999 e 2001 suportaram, de facto, o ponto de vista de Milojicic. Contudo, desde o final de 2001, houve novamente um aumento considerável do número de publicações, largamente devido ao estabelecimento de standards abertos para as internet applications e do desenvolvimento da web semântica [6]. 2.2 Mobilidade Posto isto surge a questão: Como se move, afinal, um Agente Móvel?. Da mesma forma que um utilizador que visita uma página web não está realmente a visualizar os seus conteúdos directamente no servidor, mas antes é efectuado o download de uma cópia da mesma para ser visualizado no cliente, o 5

Agente concretiza o seu movimento através da duplicação de dados. Quando o Agente decide mover-se, guarda o seu próprio estado de execução, transporta este estado guardado para o próximo host e continua a sua execução aí [3]. Distinguem-se dois tipos fundamentais de mobilidade [7]: 1. Na mobilidade fraca, quando o agente decide transferir-se, apenas é guardada a componente estática do seu estado de execução (valores dos atributos dos objectos estáticos), mas não o estado dinâmico (pilha, registos da máquina, etc.). A execução do agente no destino será reiniciada num ponto pré-definido (sempre no mesmo ponto definido antes da transferência, etc.). 2. Na mobilidade forte, para além da componente estática do estado de execução do agente, também é guardada a componente dinâmica, prosseguindo a execução do agente na máquina destino, na instrução imediatamente a seguir à instrução de transferência. À primeira vista, o tipo de mobilidade mais óbvio a implementar seria a mobilidade forte uma vez que guarda a totalidade do estado do Agente Móvel antes da sua acção de deslocamento. Contudo, a mais utilizada tem sido a mobilidade fraca muito porque a eficiência dos programas que implementam este tipo de mobilidade é bastante superior e também pela razão da linguagem de programação Java TM, muito utilizada no desenvolvimento destas aplicações, não possuir mecanismos standard para a preservação da componente dinâmica do estado [7]. Embora impondo ao implementador algumas restrições adicionais, a mobilidade 6

fraca permite que se tire partido do paradigma de programação baseado em sem que, em termos práticos, constitua uma limitação muito significativa [7]. 7

3 Vantagens da utilização de Uma das máximas defendidas pelos investigadores Danny B. Lange e Mitsuru Oshima é Dispatch your Agents; shut off your machine [8]. Esta é precisamente a alusão a uma das maiores vantagens da utilização do paradigma de Agentes Móveis que, contrariamente ao exigido, por exemplo, nas arquitecturas clienteservidor, possibilitam que o computador servidor possa ser desligado durante o processamento de uma aplicação. Como tem sido referido ao longo deste documento, inversamente aos Agentes Estacionários, que iniciam e terminam a sua execução no mesmo sistema, os têm a liberdade de se moverem entre sistemas o que se traduz em enormes benefícios na criação de aplicações distribuídas, entre os quais [8]: 1. Redução da carga de rede. É normal os sistemas distribuídos apoiaremse em protocolos de comunicação que envolvem múltiplas interacções para atingirem um objectivo. Isto resulta num tráfego de rede elevado. Os permitem armazenar uma determinada conversação e enviá-la para um host destino onde as interacções continuam localmente, reduzindo o número de ligações necessário. Ajudam também a reduzir o volume de dados a transferir na rede ao efectuar o processamento de dados localmente e transferindo apenas o estado actual do agente. 8

Figura 1: Abordagem baseada em RPC vs Abordagem baseada em 2. Ocultação de latências da rede. Tipicamente em sistemas de tempo real, onde a resposta imediata é essencial para o correcto funcionamento dos mesmos, um volume de comunicações elevado resulta facilmente em notáveis latências no envio e obtenção de informação. Para sistemas críticos de tempo real, tais latências são inaceitáveis. Os oferecem uma solução para estes casos pois podem ser enviados por um controlador central para posteriormente agirem localmente nos sistemas destino executando as directivas do controlador. Assim as latências de rede são reduzidas a quase zero. 3. Encapsulamento de protocolos. Quando são trocados dados num sistema distribuído, em cada host é necessário que esteja disponível o código que implementa os protocolos necessários à interpretação dos dados recebidos e a enviar. Contudo, à medida que estes protocolos vão evoluindo para incluirem novas funcionalidades e melhorias na sua segurança, é necessária a sua actualização em todos os hosts o que representa um tarefa 9

bastante difícil para os administradores de sistemas, muitas vezes impossível de concretizar. Os, por outro lado, podem moverse para qualquer host estabelecendo canais de comunicação baseados num protocolo implementado nos mesmos. 4. Execução assíncrona e autónoma. É normal os dispositivos móveis estarem assentes em comunicações fornecidas por redes frágeis e caras. Tarefas que necessitem de uma conexão contínua entre um dispositivo móvel e uma rede fixa não são provavelmente económicas ou até tecnicamente exequíveis. Para resolver este problema, as tarefas podem ser integradas em, que podem ser distribuídos pela rede. Após a sua distribuição, os agentes tornam-se independentes do processo que os criou e podem operar assincronamente e autonomamente. O dispositivo móvel pode reconectar-se numa altura posterior para recolher o agente. Figura 2: Execução assíncrona e autónoma dos 10

5. Adaptação dinâmica. Os podem aperceber-se do ambiente no qual se encontram a ser executados e reagem autonomamente à mudanças. Múltiplos possuem também a vantagem única de se poderem distribuir por vários hosts de forma a alcançar a distribuição de rede óptima para a resolução de um determinado problema. 6. Heterogeneidade natural. A computação em rede é naturalmente heterogénea, tanto da perspectiva do software, como da perspectiva do hardware. Devido ao facto dos serem geralmente independentes no que refere a computadores e camadas de transporte (dependentes apenas dos seus ambientes de execução), eles fornecem condições óptimas para a integração de sistemas de redes distintas (em que a heterogeneidade é mais provável). 7. Robustez e tolerância a falhas. A capacidade dos reagirem dinamicamente a situações e eventos desfavoráveis torna mais fácil a criação de aplicações distribuídas robustas e tolerantes a falhas. No caso de um host se encontrar em processo de encerramento, todos os agentes são avisados e será dado tempo para estes guardarem o estado da sua execução e migrarem para novos hosts. 11

4 Toolkits de é um assunto que tem estado presente nos tópicos das mais recentes pesquisas na área da computação distribuída. Contudo, não existe a aplicação de [7], mas antes várias aplicações que beneficiam da utilização do paradigma de, entre as quais aplicações ligadas às áreas do e-commerce, assistência pessoal, obtenção de informação distribuída, serviços de telecomunicações e rede e processamento paralelo. Da investigação na área dos, surgiram uma série de toolkits cujo intuito seria o de fornecerem uma API para a implementação facilitada de software com recurso a este paradigma. Esta investigação resultou numa série de frameworks distintas, de entre as quais se destacam [9][10]: 1. Odyssey é uma biblioteca de desenvolvimento de simples mas semanticamente elegante desenvolvida pela General Magic. Esta empresa já teria desenvolvido a primeira toolkit de : a Telescript. Contudo, devido à sua natureza proprietária teve pouco sucesso e teve de ser re-implementada com recurso a linguagens e protocolos de rede abertos, dando origem à Odyssey. 2. Concordia é uma framework desenvolvida pela Mitsubishi Electric ITA conhecida por ter rica em funcionalidades. O Concordia é uma combinação de vários componentes que constituem a aplicação distribuída. Esta toolkit 12

requer apenas uma implementação padrão da máquina virtual Java e o seu ambiente é composto por um servidor e um conjunto de agentes. Providencia mecanismos de segurança e tolerância a falhas. 3. Voyager foi criada pela ObjectSpace e fornece uma poderosa biblioteca para desenvolver aplicações distribuídas. Assenta numa plataforma Object Request Broker (ORB) com suporte a agentes. Esta framework implementa os mecanismos tradicionais de troca de mensagens e movimentação de agentes, mas tem como grande desvantagem a de não oferecer mecanismos de segurança contra agentes não autorizados. 4. Aglets é uma das mais populares toolkits para o desenvolvimento de. Inicialmente desenvolvida pela IBM Tokyo Research Laboratories e mais tarde continuada pela comunidade open source, esta framework tem como principais vantagens o facto de ser extremamente bem desenhada sendo, ao mesmo tempo, simples de utilizar. Contém também um sistema de segurança robusto que impede que aglets não autorizados acedam a determinados recursos do sistema. Esta framework será abordada com mais pormenor na secção 4.2. Todos estes toolkits partilham características em comum na forma como abordam a problemática associada aos [9][10]: são implementados em linguagem Java e utilizam a sua máquina virtual como ambiente de execução; usam técnicas de serialização de objectos para o envio de informação; possuem uma arquitectura baseada num agent server. Cada uma destas frameworks possui uma classe base de onde todos os Agentes Móveis são derivados. Na Aglets são chamados aglets e nas Odyssey, Concordia e Voyager são denominados agents. O propósito desta classe base é a de fornecer uma interface comum de comunicação entre diferentes agentes. Em qualquer 13

destes toolkits, o agente não é acedido directamente, mas antes é feito um pedido a um tipo de agent proxy que se encarregará de reencaminhar as mensagens para o agente. Esta proxy é desenvolvida automaticamente pela toolkit. Por definição, os agentes deveriam circular entre diferentes hosts sem que os mesmos tivessem de preencher quaisquer pré-requisitos para a sua aceitação. Contudo, por razões de segurança, todas estas frameworks contêm um agent server que consiste basicamente em fornecer um ambiente controlado para a execução e aceitação de agentes. Um determinado agent server apenas pode receber e executar agentes criados com a mesma toolkit. Ambas as frameworks possuem também uma classe ambiente. O ambiente pode ser acedido por agentes e cada agente deve estar associado a um ambiente. A forma como é efectuada a migração de agentes nos diferentes toolkits é semelhante. Cada um deles possui um método (membro da classe base do agente) que tem como argumento o endereço do servidor destino. Também possuem um método que é invocado imediatamente antes da migração do agente e da chegada do agente. Estes métodos podem ser re-implementados para executarem de limpeza ou de inicialização de estados. A grande diferença entre estas bibliotecas de criação de aplicações distribuídas baseadas em reside essencialmente nos mecanismos de transporte de agentes e na sua interacção. A forma como abordam a segurança na troca de agentes é também distinta entre frameworks. 14

4.1 Java nos A linguagem Java tem sido aceite largamente como a linguagem para a escrita de sistemas de [9]. A razão para isto reside no facto desta tecnologia fornecer de base a maioria das características necessárias ao desenvolvimento de aplicações baseadas em. De seguida são apresentadas algumas características que fazem da linguagem Java uma óptima escolha para o desenvolvimento de sistemas de [11]: 1. Independência de plataforma. A linguagem Java foi desenhada para operar em redes heterogéneas. Toda a programação efectuada nesta linguagem é compilada para um byte code independente da arquitectura ou do sistema operativo que será lido pela máquina virtual do Java que, por sua vez, terá de se encontrar instalada no sistema. Não existem aspectos dependentes de nenhuma arquitectura na linguagem Java. Desta forma, é possível o desenvolvimento de sem a preocupação do tipo de computadores nos quais este será executado. 2. Execução segura. Um dos objectivos da criação da tecnologia Java foi a sua utilização em intranets e na internet. Assim, a exigência de segurança em todas as suas acções influenciou de sobremaneira o seu desenho. Isto faz com que o simples facto de utilizar Java torne a aceitação de agentes não reconhecidos razoavelmente segura pois, devido à sua arquitectura, não é possível que o mesmo mexa no código do host ou que aceda a informação que não deve aceder. 3. Carregamento de classes dinâmico. Este mecanismo permite que a máquina virtual carregue e defina classes em runtime. Providencia um 15

namespace que protege cada agente, permitindo que estes sejam executados segura e independentemente uns dos outros. 4. Programação com múltiplas threads. Os agentes são por definição autónomos. Isto é, um agente é executado independentemente de outros agentes que estejam a correr no mesmo local. Permitindo que cada agente seja executado no seu próprio processo, também chamado thread de execução, é uma forma de fazer com que os agentes se comportem autonomamente. Felizmente, o Java não permite apenas a programação multithread, mas também suporta um conjunto de primitivas de sincronização disponíveis de raiz na linguagem. Estas primitivas possibilitam a interacção entre agentes. 5. Serialização de objectos. Uma característica chave dos agentes móveis é o facto destes poderem ser serializados e deserializados. O Java convenientemente disponibiliza um mecanismo de serialização de raiz que permite a representação do estado de um objecto numa forma serializada suficientemente detalhada de forma a possibilitar a reconstrução do objecto numa altura posterior. A forma serializada do objecto deve ser capaz de reconhecer a classe a partir da qual o estado do objecto foi guardado, e restaurar esse estado numa nova instância. É importante a ordem deste restauro uma vez que é possível que os vários objectos sejam interdependentes. 6. Reflexão. O código Java pode descobrir informação acerca dos campos, métodos e construtores de classes e pode usar campos, métodos e construtores reflectidos para operarem a um nível mais baixo nos objectos, sempre com as restrições de segurança aplicadas. A reflexão acomoda então a necessidade dos agentes terem de ser inteligentes relativamente a eles mesmos bem como a outros agentes. 16

Apesar do Java estar muito bem adaptado para o desenvolvimento de sistemas de, existem algumas limitações que devemos ter em conta [11]: 1. Suporte inadequado para o controlo de recursos. O Java não possui nenhuma forma do implementador poder controlar os recursos que um objecto Java consome. Isto expõe o sistema a ataques do tipo Denial of Service (DoS), no qual um agente pode consumir memória ilimitadamente, por exemplo, através da execução de um ciclo infinito roubando desta forma todos os recursos disponíveis e necessários ao normal funcionamento do sistema. 2. Não existe protecção de referências. Os métodos públicos de um objecto Java estão disponíveis a qualquer outro objecto que faça referência a si. Isto é importante para os agentes uma vez que estes não têm noção de quantos nem de quais agentes se encontram a aceder aos seus objectos. A solução encontrada para este problema foi a utilização de agent proxies responsáveis pelo filtro de acessos aos objectos do agente. 3. Não existe suporte para guardar e carregar um estado de execução. Actualmente é impossível em Java obter o estado de execução completo de um objecto. Informação como o estado do contador do programa e da frame stack são permanentemente território proibido para programas em Java. É então impossível para um Agente Móvel retomar a sua exacta computação num novo host (mobilidade forte). O agente deve basear-se em atributos internos e no registo de eventos externos que informem o novo host do ponto de execução a partir do qual deve retomar (mobilidade fraca). 4.2 Aglets 17

Aglets é uma biblioteca de desenvolvimento de aplicações com recurso a Agentes Móveis [12]. Originalmente desenvolvida por Mitsuro Oshima e Danny Lange no IBM Tokio Research Laboratory em 1995 [12][13], foi entretanto disponibilizada à comunidade open source que se encarregou de lançar as versões 2.x desta toolkit [12]. O nome Aglets surge da junção das palavras agent + applets devido ao facto de ter sido criado como uma reflexão do modelo aplicado às applets [13]. Os aglets diferem das applets na medida em que são programas Java que se movem entre hosts, guardando o seu estado ao longo do caminho e podendo inclusivé voltar ao host inicial. Enquanto que as applets são sempre executadas num browser, os aglets correm num aglet server. O SDK Aglets inclui a Aglets API, documentação, aglets exemplo e o aglet server denominado Tahiti. Tahiti é uma aplicação executada como um agent server. Possui um GUI muito fácil de utilizar que permite ao utilizador criar, enviar e eliminar agentes assim como definir os acessos dos agentes aos agent servers. 18

Figura 3: GUI do aglet server Tahiti O modelo definido pela Aglets API compreende uma série de abstracções que tem como objectivo tomar partido das vantagens que a linguagem Java oferece no que refere a agentes, assim como ultrapassar as desvantagens identificadas anteriormente. Assim, são apresentados de seguida os elementos base da framework [11]: 1. Aglet. Um aglet é um objecto Java móvel que visita hosts que executam aglet servers. É autónomo, pois inicia a sua execução numa thread independente assim que chega a um novo host, e reactivo, devido à sua capacidade de responder a mensagens recebidas. 2. Proxy. Um proxy representa um aglet. Funciona com um escudo protector que controla o acesso exterior aos métodos públicos do agente. O proxy 19

pode também servir para esconder a localização real do aglet. 3. Context. Um contexto (context) constitui a área de trabalho do aglet. É um objecto estacionário que fornece os meios para manter e gerir aglets num ambiente uniforme onde o host se encontra seguro contra agentes maliciosos. Cada aglet server pode conter vários contexts. 4. Message. Uma mensagem (message) é um objecto trocado entre aglets. Permite a troca síncrona e assíncrona de mensagens entre aglets para colaboração e troca de informação sem necessidade de uma ligação contínua entre os mesmos. 5. Future reply. Uma resposta futura (future reply) é usada no envio assíncrono de mensagens como um handler para receber um resultado numa altura futura assincronamente. 6. Identifier. A cada aglet está associado um identificador (identifier). Este identificador é globalmente único e imutável ao longo do clclo de vido do aglet. De seguida são sumarizadas as operações fundamentais dos aglets, nomeadamente criação, clonagem, envio, retracção, eliminação e envio de mensagens, bem como a sua contextualização no ciclo de vida do aglet [11]: 1. Creation. A criação (creation) de um aglet ocorre num contexto. É atribuído um identificador ao aglet, este é inserido no contexto e é inicializado. O aglet começa a sua execução assim que seja inicializado. 2. Cloning. A clonagem (cloning) de um aglet produz uma cópia quase perfeita do aglet original dentro do mesmo contexto. As únicas diferenças residem no identificador atribuído e no facto do novo aglet reiniciar a sua execução. De notar que as threads de execução não são clonadas. 20

3. Dispatching. O envio (dispatching) de um contexto para outro irá despoletar a remoção do aglet do seu contexto para o inserir no contexto destino, onde reiniciará a sua execução. 4. Retraction. A retracção (retraccion) de um aglet é a acção contrária ao envio, isto é, consiste na acção de remover um aglet do seu actual contexto para o inserir no contexto onde a retracção foi requerida. 5. Disposal. A eliminação (disposal) de um aglet irá parar a sua execução e removê-lo do contexto no qual está incluído. 6. Messaging. O envio de mensagens (messaging) entre aglets envolve o envio, recepção e manuseamento de mensagens síncrona e assincronamente. Figura 4: Ciclo de vida de um aglet e respectivas operações 21

5 Segurança em Devido à sua natureza móvel e à sua utilização em redes de grande dimensão, o uso de implica o surgimento de uma série preocupações de segurança. Os agentes necessitam de protecção de outros agentes e dos hosts nos quais são executados. Da mesma forma, os hosts precisam de ser protegidos dos agentes e de outros aplicativos que possam comunicar com a plataforma [14]. 5.1 Tipos de ameaças É possível classificar as ameaças de segurança em quatro grandes categorias [15]: 1. Agente para Plataforma. Este grupo representa o conjunto de ameaças nos quais os agentes exploram falhas de segurança ou lançam ataques a uma plataforma. Este conjunto de ameaças inclui técnicas de masquerading, DoS e acesso não autorizado. 2. Agente para Agente. Esta categoria representa o conjunto de ameaças nos quais os agentes exploram falhas de segurança ou lançam ataques a outros agentes. Este conjunto de ameaças inclui masquerading, acesso não autorizado, DoS e repudiação. 3. Plataforma para Agente. Este grupo representa o conjunto de ameaças nos quais as plataformas comprometem a segurança dos agentes. Este conjunto de ameaças inclui masquerading, DoS, eavesdropping e 22

alteração. 4. Outros para Plataforma de Agentes. Esta categoria representa o conjunto de ameaças nos quais entidades externas, incluindo agentes e plataformas de agentes, ameaçam a segurança duma plataforma de agentes. Este conjunto de ameaças inclui masquerading, DoS, acesso não autorizado, e cópia e replicação. Os problemas associados com a protecção dos hosts no que refere à execução de código malicioso é já bem conhecida [14] e, como tal, não serão abordados em detalhe neste documento (embora muitos deles sejam descritos no ponto de vista do host). Já o problema posto pelos hosts maliciosos que pretendem atacar os seus agentes é de resolução bem mais complexa. Isto porque, uma vez que um agente se encontra sob o controlo de um host que o executa, o host pode em princípio fazer o que quiser ao agente e ao seu código [14]. Os ataques que um host malicioso pode provocar podem ser sumarizados da seguinte forma [14][15]: 1. Masquerade. Uma plataforma pode-se mascarar de outra plataforma de forma a conseguir que o agente pense que está a ser executado num host confiável. Desta forma, o masquerade host pode danificar tanto o host ao qual tomou a identidade, como aos agentes que o interpretam como sendo confiável e que, por essa razão, se movimentam para ele. 2. Denial of Service. Quando um agente chega a determinada plataforma, esta espera que o agente execute os seus pedidos honestamente, 23

efectuando uma alocação de recursos justa, de acordo com os acordos relacionados com a qualidade de serviço. Contudo, uma plataforma maliciosa pode ignorar os requisitos do agente e introduzir atrasos inaceitáveis para tarefas críticas ou até terminar a sua execução sem notificação. 3. Eavesdropping. A ameaça clássica eavesdropping envolve a intercepção e monitorização de comunicações secretas. Esta ameaça ganha, contudo, contornos exacerbados nos sistemas de pois a plataforma pode observar tanto as comunicações do agente, como as suas instruções de execução. 4. Alteração. Uma vez que o agente pode visitar várias plataformas sob vários domínios de segurança, expondo o seu código, dados e estado a estas plataformas, devem ser implementados mecanismos capazes de garantir a integridade do agente. Caso esta situação não se verifique, uma plataforma maliciosa pode alterar o código, dados ou estado do agente e infectar as plataformas para as quais este migrará. Além destes ataques, relacionados directamente com os hosts, são também frequentes os apresentados de seguida [15]: 1. Acesso não autorizado. Utilizadores remotos, processos e agentes podem requerer recursos para os quais não são autorizados. Este tipo de ameaça pode ser despoletada a partir de scripts que exploram falhas de segurança nos sistemas operativos para ganhar acesso a recursos para os quais não possuem autorização. 2. Repudiação. A repudiação ocorre quando um agente, que se encontre a participar numa transacção ou comunicação, afirme que essa comunicação nunca existiu. Independentemente da repudiação se deliberada ou 24

acidental, esta pode levar a sérias disputas que podem não ser facilmente resolvidas. 3. Cópia e Replicação. De cada vez que um agente se move de um host para outro aumenta a sua exposição a ameaças de segurança. Uma entidade que consiga interceptar o agente em movimento pode copiá-lo e retransmiti-lo quantas vezes pretender simulando varios envio do agente quando só deveria ter ocorrido um. 5.2 Medidas de prevenção Os problemas de segurança que surgem com os são bastante conhecidos e compreendidos pela comunidade de pesquisa da área de segurança e, como tal, é dado grande ênfase a este assunto [14]. Têm havido várias tentativas de resolução dos problemas postos pelos Agentes Móveis, a maior parte das quais endereçando uma parte específica do problema. Como foi referido anterirmente, uma vez chegado a um host, o agente puco ou nada pode fazer para evitar que o host o trate como desejar. Este problema é normalmente conhecido como o problema do host malicioso [14]. Não existe uma solução universal para este problema, mas algumas soluções parciais foram já propostas, conforme resumido nos pontos seguintes [14]: 1. Acordos contratuais. A solução mais simples (pelo menos do ponto de vista técnico) é a de usar meios contratuais para resolver o problema dos hosts maliciosos. Os operadores das plataformas de agentes garantem, via 25

contratos, que irão operar as suas plataformas de forma segura, não violando a privacidade ou a integridade do agente. Contudo, provar que um contrato foi quebrado pode não ser uma tarefa trivial. 2. Hardware confiável. Se não é possível confiar nos ambientes de execução disponíveis uma solução óbvia é a de confiar o fornecimento de hardware a uma entidade certificada, na forma de dispositivos (ex. Smartcards) instalados nos hosts destino, cuja função será a de bloquear alterações que o host possa fazer aos agentes. De notar que esta medida pode ser ultrapassada, mas requer um esforço muito maior por parte do atacante. 3. Nós confiáveis. Ao introduzir nós confiáveis na infraestrutura onde os podem migrar quando requerido, é possível prevenir que seja enviada informação sensível para hosts não confiáveis, assim como se torna possível auditar possíveis comportamentos suspeitos de hosts maliciosos. 4. Agentes confiáveis. Ao utilizar agentes cooperantes, é obtido um resultado semelhante ao dos nós confiáveis. A informação e a funcionalidade pode ser dividida por vários agentes de forma a que se a segurança um agente for comprometida não seja comprometida toda a tarefa. 5. Auditoria de execuções. A auditoria de execuções foi proposta para detectar modificações não autorizadas aos agentes através dos registos de execução em cada plataforma de agentes. Cada plataforma terá de registar um log de operações desempenhadas pelos agentes que por si passam. A desvantagem desta abordagem é o espaço gasto e o esforço necessário para gerir esses logs. 6. Encriptação. A criptografia assimétrica está bem adaptada para Agentes Móveis que necessitem de enviar resultados para o seu owner ou que vá recolhendo informação ao longo do seu percurso antes de enviar o conteúdo 26