Design e prova de corretude de um protocolo para a detecção de clones de agentes móveis usando redes de Petri coloridas Jusung Baek Kwang-Ju Institute of Science and Technology Apresentado por Nazareno Andrade

Roteiro Introdução Problema Protocolo –Modelagem –Corretude Conclusões

Introdução – agentes móveis Componente de software autônomo capaz de migrar entre nós de uma rede e continuar seu processamento em cada nó de seu itinerário; –Computação Móvel; –Recuperação de dados; –Gerência distribuída; –Comércio eletrônico;

Introdução - agências Plataforma capaz de criar, executar, transferir e finalizar a execução de agentes ; Habitat; Provê acesso aos nós do sistema; move(nó2) new Agente run() nó1 nó2 nó3 agência

Introdução - segurança Complexa em qualquer sistema distribuído; Segurança –Agente x Sistema; –Agente x Agente; –Agência x Agente; –Agência x Agência

Problema - cenário cliente Diretório de serviços Provedor de serviço1 Provedor de serviço2 efetuaAção()

Problema - cenário cliente Diretório mal- intencionado Provedor de serviço1 Provedor de serviço2 efetuaAção()

Problema - considerações Impossível diferenciar agente original do clonado: –Múltiplas transações; –Problemas na autenticação; Não há mecanismos de defesa na maioria das agências utilizadas no mercado;

Protocolo – a solução Propriedades: 1.Permite execuções válidas; 2.Identifica a agência que tentou ou fez o clone; 3.Pára o protocolo ao achá-la. Hipóteses: –Elemento confiável – Coordenador; –Rede segura e confiável; –Agências não são confiáveis.

Protocolo – linhas gerais Ações das agências só devem acontecer com permissão do coordenador; –RCT, RET, RMT, RDT; –CT, ET, MT, DT; Ações inesperadas implicam em que ou a agência que a solicitou um uma anterior no itinerário do agente é maliciosa; Token: {(CT | ET | MT | DT), aa: agentID, owner: agentServer, tar: agentServer, ut: Id}

Protocolo - casos Casos de clonagem: (pedidos de uma agência ao coordenador) 1.CT repetido; 2.MT repetido ou após DT; 3.DT repetido ou após MT; 4.ET repetido; 5.ET para clone já feito: t pede ET para um p cujo tar e owner são diferentes de t. CT ET DT MT

Protocolo - identificação –Se AS requisita um RCT | RMT | RDT inesperado AS é a agência maliciosa; –Se AS requisita um RET inesperado Antecedente no itinerário do agente é a agência maliciosa –Se o tar do agente não for AS AS é a agência maliciosa –Protocolo é parado.

Modelagem – cores principais color AgentID = with jsbaek | jypark declare lt; color AgentServer = with dsl | atom | tongki | non declare lt; color TokenType = with CT | ET | MT | DT declare lt; color Token = record tt:TokenType * aa:AgentID * owner:AgentServer * tar:AgentServer *ut:TokenID declare lt; color AgentState = record aa:AgentID * owner:AgentServer * tar:AgentServer * token:Token declare lt; color C_AgentState = product AgentID * AgentServer * Token declare lt; color ELIST = list C_AgentState; color CloneGenerator = product AgentID * AgentServer declare lt; color DLIST = list CloneGenerator; Id único Token enviado pelo coord. Estado de cada agente mantido pelo coord. Listas = Histórico Agência maliciosa detectada

Modelo - geral modelo

Protocolo - prova Definição de redes de Petri; Propriedade 1: –É possível completar o ciclo do agente, caso este não seja clonado; Propriedades 2 e 3: –Definições das funções das guardas –Verificação (sem grafos de ocorrência?) –Programação funcional

Conclusões Protocolo correto provado por verificação; Necessidade de estudos sobre viabilidade de implementações do algoritmo –Grande troca de mensagens; –Centralização;