SlideShare una empresa de Scribd logo
ARQUITECTURA MULTI-AGENTE SEGURA
BASADA EN UN SISTEMA DE IMPLEMENTACIÓN
AUTOMÁTICA DE PROTOCOLOS DE SEGURIDAD

1

Luis Mengual1, Nicolás Barcia1, Jesús Bobadilla2, Ernesto Jiménez2,
Julio Setién1, Javier Yágüez1
Universidad Politécnica de Madrid, 28031 Madrid
nicolas, jsetien, jyaguez}@fi.upm.es
2{jbobi, ernes}@eui.upm.es

1{lmengual,

Abstract. En este artículo presentamos una Arquitectura Multi-agente segura
basada en un nuevo concepto de implementación de servicios de seguridad. La
idea se basa en incorporar a nuestros agentes una capa de seguridad
denominada S.I.A.P.S (Sistema de Implementación Automática de Protocolos
de Seguridad). Esta capa adicional en el software del agente proporciona un
código único, versátil y flexible capaz de implementar, en entornos TCP/IP,
cualquier protocolo de seguridad a partir de su Especificación Formal. La
incorporación de nuestro sistema de seguridad en el código de un agente abre
un nuevo campo en la filosofía de construcción de agentes y su implantación en
servicios emergentes como el comercio electrónico en Internet [1]. Nuestra
propuesta se aleja de las soluciones estándar y rígidas ofrecidas por las
plataformas y entornos distribuidos convencionales (CORBA, JavaBeans y
COM). En nuestro sistema, los agentes pueden diseñar e implementar de forma
automática y dinámica protocolos de seguridad adaptados al contexto en el se
desarrollan los servicios y aplicaciones de usuario.

1

Introducción

La tecnología de agentes es un campo emergente en el desarrollo de aplicaciones
distribuidas [2], [3]. Los agentes son entidades software programadas que llevan a
cabo una serie de operaciones en nombre de un usuario o de otro programa, con algún
grado de independencia o autonomía, empleando algún conocimiento o
representación de los objetivos o deseos del usuario. Cuando hablamos de agentes
hay tres dimensiones o coordenadas las cuales usamos como medida de sus
capacidades: representación o mediación, inteligencia y movilidad.
La representación tiene que ver con el grado de autonomía que el agente software
tiene en representar el usuario a otros agentes, aplicaciones y sistemas de
computadoras. La inteligencia se refiere a la capacidad del agente para capturar y
1

Este trabajo esta realizado en el marco del Proyecto CICYT de Investigación Sistema
Abierto de Presentación Digital Multimedia en Tiempo Real (TIC2000-1734-C03-02
aplicar el conocimiento y el procesamiento para solucionar problemas. Por lo tanto,
los agentes pueden ser relativamente simples usando simple lógica o pueden ser
relativamente sofisticados usando complejos métodos basados en Inteligencia
Artificial como inferencias y aprendizaje.
Los agentes pueden ser estáticos o móviles. Un agente estático es aquel que sólo
puede ejecutarse en la máquina donde fue iniciado. Un agente móvil es aquel que no
está limitado al sistema donde se inició su ejecución, siendo capaz de transportarse de
una máquina a otra de la red. Esta posibilidad le permite interactuar con el objeto
deseado de forma directa sobre el sistema de agentes donde se halla dicho objeto.
Los agentes proporcionan una serie de ventajas respecto de otras técnicas
informáticas distribuidas [4]:
• Los usuarios que utilizan sistemas informáticos con baja capacidad de proceso, los
que tienen un bajo ancho de banda en la red o los que disponen de poco espacio de
almacenamiento pueden utilizar agentes para solucionar sus necesidades,
desconectando su sistema informático de la red o pidiendo que otro sistema realice
los cálculos y recogiendo posteriormente los resultados.
• Aplicaciones como el comercio electrónico, mejoran sus prestaciones, ya que el
usuario puede dar instrucciones a un agente para que realice la compra cuando se
cumplan las condiciones óptimas. El proceso es más rápido y económico porque
evita tener que hacer comunicaciones periódicas para comprobar el estado del
producto.
Por el contrario, tienen una serie de riesgos relativos a la seguridad ([5], [6], [7]).
En primer lugar un agente es representante de un usuario, por consiguiente, se debe
garantizar y probar en todo momento la identidad del usuario a quien representa
evitando suplantaciones fraudulentas. Además, los agentes no actúan en solitario, sino
que se localizan en entornos o plataformas con varios agentes, donde cada uno tiene
sus propios objetivos, toma sus decisiones y puede tener la capacidad de comunicarse
con otros agentes, lo que crea nuevos riesgos en las comunicaciones. Dichos entornos
se conocen como sistemas multi-agente.
Los sistemas multi-agente dan un mayor nivel de abstracción con respecto a la
informática distribuida tradicional, estando más cercanos a las expectativas del
usuario y permitiendo al programador una mayor flexibilidad para expresar el
comportamiento de los agentes. Sin embargo, este tipo de diseños suele plantear una
serie de problemas, como la elección de la forma de comunicación entre los agentes,
del tipo de plataforma de desarrollo, o la seguridad del sistema.
Históricamente, la comunicación entre agentes de un sistema se realizaba mediante
lenguajes propios de cada vendedor, impidiendo la comprensión entre los agentes de
sistemas heterogéneos, con una semántica informal y con poca autonomía. A
principios de los años 80, el DARPA estadounidense desarrolló el “Knowledge Query
Management Language” (KQML) ([8], [9]) que pretendía convertirse en una norma
para la comunicación entre agentes. El lenguaje KQML está enfocado a los formatos
de los mensajes y al protocolo de manejo de los mismos. Uno de los criterios del
diseño de KQML es producir un lenguaje que pudiese soportar una gran variedad de
arquitecturas de agentes. Este fue uno de los motivos de introducir un agente especial
“intermediario”. Este agente se encargaría de encaminar los mensajes en función del
contenido y realizar las funciones de mediación entre los agentes proveedores y
clientes [10].
El control de la seguridad en sistemas multi-agente es esencial en aquellos
servicios que implican la distribución en red de información sensible. Así la
implementación con sistemas multi-agente de servicios ampliamente utilizados o en
fase emergente en Internet como el comercio electrónico, transferencias bancarias,
declaraciones fiscales o gestión de red no sería posible sino estuviera garantizada la
autenticación de los usuarios, la integridad de los datos y confidencialidad de la
información [11], [12].
Las propuestas actuales de seguridad en comunicaciones entre agentes se basan en
soluciones rígidas. Así las distintas plataformas y entornos distribuidos
convencionales (CORBA [13], JavaBeans [14] y COM [15]) ofrecen soluciones
estándar poco flexibles. Adicionalmente, en algunos casos, se han desarrollado
soluciones particulares orientadas al servicio ofrecido por un sistema multi-agente [1].
Nosotros proponemos una solución dinámica, flexible e independiente de los servicios
o aplicaciones que implica la incorporación en cada agente del sistema de una capa
adicional de seguridad S.I.A.P.S (Sistema de Implementación Automática de
Protocolos de Seguridad) [16]. Esta capa adicional será capaz de interpretar e
implementar cualquier protocolo de seguridad a partir de su especificación formal. En
dicha especificación estarán definidos los intercambios que comprenden un protocolo
de seguridad, así como las funciones de seguridad necesarias para garantizar los
requisitos de la política de seguridad (generación de números aleatorios como
identificadores de uso único, sellos de tiempo, generación de claves asimétricas y
simétricas, funciones de cifrado, etc.).
Las Técnicas de Descripción Formal son la base del soporte automatizado en
diferentes actividades de desarrollo. La especificación formal es una herramienta
esencial en la ingeniería de protocolos de comunicaciones. Empleando las Técnicas
de Descripción Formal se pueden obtener mejoras significativas en la calidad del
producto, tiempo de disponibilidad en el mercado y coste del ciclo de vida. Los
modelos formales de seguridad han evolucionado en paralelo con el desarrollo de los
sistemas informáticos (software, hardware, sistemas operativos), así como con la
tecnología y extensión de las redes de datos. Inicialmente los modelos formales han
tratado el problema de control de acceso en sistemas individuales. Los criterios de
seguridad TCSEC (Trusted Computer System Evaluation Criteria) del DoD
(Departament of Defense) del gobierno de EEUU [17] o el ITSEC europeo
(Information Technology Security Evaluation Criteria) [18] son un ejemplo de la
formalización en el campo de los sistemas informáticos seguros. Otros ejemplos son
los modelos desarrollados en [19], [20], [21].
Posteriormente, el notable impulso de las Redes de Área Local, y su interconexión
con redes de remotas, ha dado lugar a nuevas y más sofisticadas amenazas asociadas a
la distribución de la información (grabaciones, retransmisiones, suplantaciones, etc)
[22]. Todo ello ha conducido al desarrollo de nuevos mecanismos y funciones de
seguridad para proteger la información en tránsito en los sistemas abiertos ([23],
[24]), y no solo contemplar los problemas de control de acceso a recursos en los
sistemas individuales. En este caso, las Técnicas de Descripción Formal (TDF) se han
utilizado para especificar protocolos de seguridad y evaluar la vulnerabilidad de
dichos protocolos frente a distintos ataques. Ejemplos de este tipo de análisis formal
se tienen en [25] y [26].
La especificación formal permite verificar y validar protocolos de comunicaciones
de manera eficiente como un paso previo al desarrollo del producto software, sin
embargo la utilización de Técnicas de Descripción Formal en la especificación de
protocolos de seguridad implica una serie de consideraciones adicionales no
contempladas en las especificaciones convencionales de protocolos de
comunicaciones [27]. La aplicación de técnicas de descripción formal al campo de la
seguridad debería contemplar la necesidad de especificar adecuadamente los
intercambios que corresponden a los protocolos de seguridad, así como las funciones
y mecanismos implicados con el objeto de ser interpretadas en fase de
implementación.
Sin embargo, esta tarea no es fácil, un protocolo de seguridad es un conjunto de
intercambios que implican funciones de cifrado simétrico y asimétrico, generación de
números aleatorios, sellos de tiempo, etc. Especificar formalmente estos intercambios
e implementarlos de forma automática no es tarea fácil. Si además pretendemos que
sea un agente la entidad software que realice está misión la tarea se complica todavía
más [28], [29]. No obstante los beneficios son indudables a la hora de implantar
aplicaciones distribuidas y servicios de telecomunicaciones en entornos abiertos.

2

Innovación del Sistema de Implementación Automática de
Protocolos de Seguridad (S.I.A.P.S)

El Sistema de Implementación Automática de Protocolos de Seguridad es capaz de
incorporar dinámicamente distintos protocolos de seguridad a una comunicación
entre aplicaciones TCP/IP. Para ello, las entidades pares en un entorno distribuido
tienen la capacidad de interpretar especificaciones de protocolos de seguridad y, por
tanto, disponen de un sólo código independiente del protocolo de seguridad
específico.
Para comprender la innovación que supone la interpretación automática de una
especificación formal vamos a comparar esta idea con la concepción habitual de
implementación de protocolos. Tradicionalmente, la implementación de un protocolo
se ha realizado generando un código independiente en cada una de las entidades
participantes ([30], [31], [32]). De esta forma se cumplen las funcionalidades, en
general distintas, asociadas a cada entidad para ese protocolo. Por consiguiente, con
este esquema, si se tuviera que implementar otro protocolo distinto se necesitaría un
nuevo código, que además debería ser distinto para cada entidad (ver Fig. 1).
ESPECIFICACIÓN
...
MESSAGES
1:A->C: peticion
2:C->A: Ka(Ks), Kb( Ks)
3:A->B:Kb( Ks)
...

...
componer(m1)
enviar( dir(C), m1)
recibir( dir(C), m2)
analizar(m2)
componer(m3)
enviar( dir(B), m3)
...

CÓDIGO DE
CLIENTE

...
recibir( dir(A), m1)
analizar(m1)
componer(m2)
enviar( dir(A), m2)
...

AUTORIDAD DE
AUTENTICACIÓN

• Cada protocolo, distinta
implementación
• Dado el protocolo, distinta
implementación para cada
entidad

...
recibir( dir(A), m3)
analizar(m3)
...

CÓDIGO DE
SERVIDOR

Fig. 1. Proceso tradicional de implementación de protocolos de seguridad

La infraestructura software desarrollada en el S.I.A.P.S permite implementar
cualquier protocolo de seguridad con un mismo código de interpretación de
protocolos localizado en cada entidad participante. Cada una de las entidades deberá
saber cuál es su comportamiento en función de la especificación formal del protocolo.
En la Fig.2 se describe esta idea.
ESPECIFICACIÓN
...
MESSAGES
1:A->C: peticion
2:C->A: Ka (Ks ), Kb( Ks )
3:A->B:Kb( Ks )
...

...
Para cada mensaje M
Si YoSoy (emisor(M))
componer(M)
enviar(receptor(M), M)
Si YoSoy (recptor (M))
recibir(emisor(M), M)
analizar(M)
...

CÓDIGO DE
CLIENTE

AUTORIDAD DE
AUTENTICACIÓN

• Una única
implementación, válida
para todos los protocolos y
todas las entidades

CÓDIGO DE INTERPRETACIÓN DE
ESPECIFICACIONES FORMALES DE
PROTOCOLOS DE SEGURIDAD

CÓDIGO DE
SERVIDOR

Fig. 2. Interpretación automática de protocolos de seguridad

Los beneficios de esta nueva filosofía de implementación de protocolos de
seguridad se reflejan en la Fig. 3.
1

A1

2

B1

C1

A2

B2

1

C2

A1

B1

C1

2

A2

B2

C2

Fig. 3. Cambio de filosofía en la implementación de protocolos
En un esquema de implementación tradicional, si aplicaciones distintas necesitan
distintos servicios de seguridad materializados con dos protocolos de seguridad
diferentes (1 y 2) harían falta 6 códigos distintos (2 por cada entidad participante). En
nuestro modelo, con un único código de interpretación de protocolos las entidades son
capaces de implementar cualquier protocolo de seguridad. Los beneficios de este
esquema son indudables a la hora de ofrecer dinámicamente servicios de seguridad a
las aplicaciones y usuarios. En la Fig. 4 se muestra el nuevo nivel de seguridad
desarrollado por el S.I.A.P.S sobre la arquitectura TCP/IP. Este nivel de seguridad
será el encargado de ofrecer al nivel superior (nivel de aplicación) un conjunto de
funciones (primitivas) para el establecimiento de comunicaciones seguras entre
aplicaciones en la arquitectura TCP/IP.
Aplicaciones de usuario,
bases de datos, …

NIVEL DE
USUARIO
datos de usuario
NIVEL DE
SEGURIDAD

S. I. A. P. S.

datos de usuario
Interfaz sockets
UDP

TCP

NIVEL TCP
cab. TCP datos de usuario

IP

NIVEL IP
cab. IP cab. TCP datos de usuario

S. I. A. P. S.: Sistema de Implementación Automática de Protocolos de Seguridad

Fig. 4. Arquitectura de Seguridad desarrollada en el Elemento Lógico de Implementación

3

Interpretación de Protocolos a partir de su especificación
formal en el S.I.A.P.S.

El S.I.A.P.S. dispone de dos módulos diferenciados: el Analizador Sintáctico y el
Código de Implementación de Protocolos. La función del Analizador Sintáctico es
verificar la sintaxis de la especificación formal. El Código de Implementación de
Protocolos es capaz de crear la infraestructura necesaria para posibilitar el
establecimiento de comunicaciones seguras entre aplicaciones que soportan la
arquitectura TCP/IP utilizando la interfaz sockets y automatizar completamente el
proceso de implementación de protocolos de seguridad a partir de una especificación
formal.
La sintaxis y semántica contemplada en la definición de las especificación
formales de protocolos de seguridad aparece recogida en [16]. El diseño de esta
especificación, realizado de acuerdo a los requisitos expuestos en [16] contiene los
siguientes módulos:
1. Identificador de inicio de la especificación. Este módulo determina el comienzo de
la especificación formal de un protocolo de seguridad.
2. Declaración de Constantes. Este módulo contiene las cadenas de caracteres que
denominaremos identificadores constantes que se utilizarán en la definición del
protocolo de seguridad. Se han definido cinco tipos de identificadores:
Identificadores de dirección, de clave, numéricos, temporales y de datos.
3. Mensajes implicados en el protocolo de seguridad. Este módulo contiene los
mensajes implicados en el protocolo de seguridad identificados por un número
entero. Cada mensaje contiene identificadores constantes o variables y/o patrones
de cifrado. Un patrón de cifrado representa un conjunto de identificadores de
dirección, de clave, numéricos o temporales cifrados por un identificador de tipo
clave.
4. Declaración de Relaciones asociadas a mensajes. Este módulo contiene un
conjunto de procedimientos o condiciones que una entidad par debe aplicar a la
hora de generar un mensaje. Es decir, se trataría de especificar las funciones y
mecanismos de seguridad implicados en los protocolos criptográficos. Por
ejemplo, cifrado simétrico y asimétrico, generación de identificadores de uso
único, sellos de tiempo etc. A cada una de estas funciones le corresponde un
identificador formal: “sesion_key()”, public_key()”, “secret_key()”, “random()”,
“function_x()”
Un ejemplo de una especificación formal, está representado en la Especificación 1:
PROTOCOL SPECIFICATION
CONSTANTS
a,b:address.
MESSAGES
1:a->b:KPA;
2:b->a:encrypt(KPA,KS).
RELATIONS
1:public_key(A,KPA:A);
2:sesion_key(KS:B).
Especificación 1. Especificación formal de prueba nº1
En este ejemplo sencillo tenemos un protocolo formado por dos intercambios. En
el primero de ellos la entidad A envía a la entidad B una variable “KPA”. Esta
variable tiene asociada en el módulo RELATIONS la función
“public_key(A,KPA:A)”. Esto significa que la variable “KPA” es la clave pública de
A que deberá ser generada por la propia entidad. En realidad la entidad A generará un
par clave pública-clave privada que almacenará en una Tabla de Variables por si
fuera necesario utilizarlas más adelante en la construcción de algún mensaje del
protocolo. Una vez obtenidas y almacenadas las claves de acuerdo a la especificación
del protocolo la entidad A enviará a la entidad B su clave pública “KPA”. La entidad
B recibirá a través de su interfaz sockets el mensaje 1 en el que identificará a “KPA”
como la clave pública de la entidad A y la almacenará en su Tabla de Variables.
En el mensaje 2 la entidad B construirá el mensaje 2. Este mensaje contiene un
patrón de cifrado. Recorriendo el patrón de cifrado la entidad B determina que tiene
que cifrar con la clave pública de A “KPA” una variable “KS”. Ahora bien, la variable
“KS” tiene asociada una relación “sesion_key(KS:B)”. Esto significa que “KS” es una
clave de sesión que tiene que generar aleatoriamente la entidad B. Por consiguiente,
en este caso el proceso de interpretación consiste en primer lugar en la generación de
la clave de sesión “KS” y posteriormente en el cifrado de esta clave con la clave
pública de A “KPA”. Finalmente, la entidad A recibirá un mensaje por su interfaz
sockets en el que podrá identificar un patrón de cifrado, el cual será incorporado
automáticamente a su Tabla de Variables. La entidad A identificará que este patrón se
ha cifrado con su clave pública y, por consiguiente, tendrá que descifrarlo con su
clave privada dual. Una vez descifrado sabrá identificar a “KS” como la clave de
sesión que almacenará en su Tabla de Variables.
Las Tablas de Variables utilizadas por las entidades permiten agilizar el proceso de
interpretación y composición de los mensajes. En nuestro ejemplo las tablas
generadas en las entidades A y B serían las de las Tablas de Variables 1 y 2.
A_public.key
A_secret.key
_KPA_KS
Sesion.key

<<valor de la clave pública de A>>
<<valor de la clave privada de A>>
<<valor patrón de cifrado>>
<<valor de la clave sesión>>

Tabla de Variables 1. Tabla de Variables de la entidad A

A_public.key
Sesion.key

<<valor de la clave pública de A>>
<<valor de la clave sesión>>

Tabla de Variables 2. Tabla de Variables de la entidad B
4

Arquitectura Multi-Agente incorporando el Sistema
Implementación Automática de Protocolos de seguridad

de

Nuestra propuesta se centra en el desarrollo de una plataforma de seguridad de
agentes estáticos ofreciendo una Interfaz de desarrollo de Aplicaciones para la
implementación de agentes específicos. Es decir, proporcionamos una serie de
métodos que garantizan las comunicaciones seguras entre agentes. Esta nueva
filosofía de implementación simplifica la tarea del desarrollador de agentes de forma
que el código propio del agente es transparente a la problemática de seguridad.
La Arquitectura de Sistema Multi-agente que proponemos en este artículo (Fig. 5)
permite proporcionar a cualquier agente del sistema de la funcionalidad necesaria
para implementar cualquier protocolo de seguridad y, por consiguiente, garantizar las
comunicaciones entre agentes y ofrecer seguridad al usuario del servicio. En
definitiva, nuestro sistema multi-agente:
• Permite ofrecer a cualquier aplicación distribuida (comercio electrónico, asistentes
personales, servicios de distribución de información, transferencias de datos,
servicios de telecomunicaciones, aplicaciones de grupo, gestión de red,
declaraciones fiscales, aplicaciones de procesamiento paralelo, etc.) servicios
dinámicos y flexibles de seguridad.
• Incorpora un nuevo concepto de implementación de protocolos de seguridad
basado en la interpretación formal de especificaciones formales de protocolos de
seguridad. [16]. La idea básica es que nuestros agentes sean capaces de
implementar de forma automática cualquier protocolo de seguridad a partir de su
especificación formal. Los usuarios finales o bien los agentes intermediarios
podrán elegir el protocolo de seguridad a utilizar en cada aplicación, para
garantizar la autenticación de los interlocutores, la integridad de los datos o la
confidencialidad de la información.
• Proporciona la infraestructura necesaria para la incorporación de las
funcionalidades propias de agentes específicos (comercio electrónico, gestión de
red, etc.)..
AGENTE
INTERMEDIARIO

S.I.A.P.S.

AGENTE
CLIENTE

AGENTE
SERVIDOR

S.I.A.P.S.

S.I.A.P.S.

S. I. A. P. S.: Sistema de Implementación Automática de Protocolos de Seguridad

Fig. 5. Arquitectura Multi-agente segura

Nuestra arquitectura ofrece a los implementadores de agentes la Clase Base
“Agente_Seguro” (ver Fig. 6) que permite construir agentes en el contexto de
cualquier aplicación. En Clase Base “Agente_Seguro” está implementado el S.I.A.P.S
(“Sistema de Implementación de Protocolos de Seguridad”) a través del método
“Implementar_Protocolo_Seguridad” que permitirá la interpretación de cualquier
protocolo de seguridad a partir de una especificación formal. Este código será común
a cualquier agente de modo que agentes específicos heredarán este método de clase.
ESPECIFICACIÓN FORMAL
PROTOCOL SPECIFICATION
CONSTANTS
----------MESSAGES
-----------RELATIONS
-------------------------------

class Agente_Seguro
{
private:
.............................................
public:
Inicializar _Agente() { }
Implementar_Protocolo_ Seguridad ()
{
// Implementación intercambio de mensajes a partir de la espec. formal
// Implementación funciones de seguridad a partir de la espec.. formal
// Implementación de mecanismos de seguridad
}
................................................................
Agente_Comercio_Electrónico{ };
Agente_Comercio_
Electronico };
{
Agente_
Gestión
Gestion{ };
Agente_Transferencias_Bancarias { };
......................................................
}

Fig. 6. Clase base “Agente_Seguro

Un ejemplo de un sistema multi-agente con la infraestructura de seguridad de
acuerdo a nuestro planteamiento es la representada en la Fig. 7, en la cual se muestran
tres agentes específicos de una aplicación de comercio electrónico que derivan de la
clase base Agente_Seguro y que, por consiguiente, heredan sus métodos. Nótese que
en cada agente específico se deberá ahora implementar los métodos
“Inicializar_agente” o “Agente_Comercio_Electronico” que no aparecen
implementados en la clase base “Agente_Seguro. Estos métodos se codificarán de
acuerdo a los requisitos específicos del servicio ofrecido al usuario y de la política de
seguridad la organización. Nuestra Arquitectura de sistema multi-agente proporciona
la funcionalidad necesaria para facilitar la tarea del programador de agentes forma
que éste solo tenga que invocar a métodos que implementan servicios y protocolos de
seguridad en la comunicación entre agentes.
ESPECIFICACIÓN FORMAL
PROTOCOL SPECIFICATION
CONSTANTS
----------MESSAGES
-----------RELATIONS
-------------------------------

Agente_Intermediario_Comercio_ Electrónico : Agente_Seguro
{
private :
................................................
public
:
Inicializar _Agente()
{
// Inicialización parámetros agente intermediario
// Inicialización Infraestructura de comunicaciones
// Distribución especificación formal de protocolo de seguridad
}
Agente_Comercio_ Electrónico
{
// Invocación método Implementar_Protocolo_Seguridad de clase base
// Implemetación Agente intermediario comercio electrónico seguro
};
}

ESPECIFICACIÓN FORMAL

ESPECIFICACIÓN FORMAL

PROTOCOL SPECIFICATION
CONSTANTS
----------MESSAGES
-----------RELATIONS
-----------

PROTOCOL SPECIFICATION
CONSTANTS
----------MESSAGES
-----------RELATIONS
-----------

-----------

-----------

-----------

-----------

Agente_Cliente_Comercio_ Electrónico : Agente_Seguro
{
private :
................................................
public
:
Inicializar _Agente()
{
// Inicialización parámetros agente cliente
// Inicialización Infraestructura de comunicaciones
// Distribución especificación formal de proto. seguridad
}

Agente_Servidor_Comercio_ Electrónico : Agente_Seguro
{
private :
................................................
public
:
Inicializar _Agente()
{
// Inicialización parámetros agente servidor
// Inicialización Infraestructura de comunicaciones
// Distribución especificación formal de proto. seguridad
}

Agente_Comercio_ Electrónico
{
// Invocación método Implementar_Protocolo_Seguridad
de clase base

Agente_Comercio_ Electrónico
{
// Invocación método Implementar_Protocolo_Seguridad
de clase base

};
}

// Implementación Agente cliente comercio electrónico
seguro

};
}

// Implementación Agente servidor comercio electrónico
seguro

Fig. 7. Arquitectura Multi-agente segura

5

Resultados

Los resultados presentados este apartado se refieren, a modo de ejemplo, a los
tiempos de ejecución de tres protocolos de seguridad en distintas redes de
comunicaciones. Estos protocolos que se han especificado e implementado utilizando
el S.I.A.P.S. son un ejemplo de tres propuestas de seguridad a incorporar a nuestros
agentes. Como ya se ha comentado, la versatilidad de nuestra solución consiste en
que, únicamente, con la especificación del protocolo de seguridad solicitado nuestros
agentes implementan de forma automática el servicio de seguridad asociado adecuado
al contexto de actuación de los agentes.
Cada una de las especificaciones propuestas incorpora progresivamente más
funciones y mecanismos de seguridad que hacen más compleja la tarea de
implementación automática. Cada una de las pruebas consiste en realizar medidas de
tiempo de ejecución del protocolo en la entidad Cliente utilizando sistema operativo
Windows NT. Para la implementación de mecanismos de cifrado simétrico se ha
utilizado el código Blowfish disponible en [33] y para el cifrado asimétrico el código
RSA de la librería Crypto++ [34]. Las pruebas se realizaron sobre tres
especificaciones formales diferentes. Las especificaciones formales utilizadas fueron
en primer lugar la Especificación formal P1, ya analizada anteriormente, y las
Especificación Formales P2 y P3:
Especificación formal P2: Esta especificación formal es una aproximación del
protocolo SSL (Security Socket Layer), en el que la entidad A genera una clave de
sesión y se la envía a la entidad B cifrada con la clave pública de la entidad B. Una
tercera entidad, la entidad C realiza funciones de autenticación y firma de las claves
públicas distribuidas. La especificación formal es la siguiente:
PROTOCOL SPECIFICATION
CONSTANTS
a,b,c:address;
req:data.
MESSAGES
1:c->a:KPC;
2:a->b:req;
3:b->c:KPB;
4:c->b:encrypt(KSC,[KPB,T1]),KPC;
5:b->a:encrypt(KSC,[KPB,T1]);
6:a->b:encrypt(KPB,KS).
RELATIONS
1:public_key(C,KPC:C);
3:public_key(B,KPB:B);
4:secret_key(C,KSC:C),time(T1:C);
6:sesion_key(KS:A).
Especificación 2: Especificación formal de prueba nº2

Especificación formal P3: En esta especificación formal la entidad C genera la
clave de sesión y se la envía a las entidades A y B cifrada con la clave pública de cada
una de estas entidades respectivamente. Esta especificación contiene ejemplos de
números aleatorios, funciones, etc.:
PROTOCOL SPECIFICATION
CONSTANTS
a,b,c:address;
dat:data.
MESSAGES
1:a->c:req,B,N1,KPA;
2:c->a:encrypt(KPA,[req,KS,N2]);
3:c->b:req,N3;
4:b->c:req,N4,KPB;
5:c->b:encrypt(KPB,[req,KS,N2]).
RELATIONS
1:random(N1:A),public_key(A,KPA:A);
2:sesion_key(KS:C),function_1(N1,N2:C);
3:random(N3:C);
4:public_key(B,KPB:B),function_1(N3,N4:B).
Especificación 3: Especificación formal de prueba nº3

Nótese que en la Especificación Formal 1 intervienen dos entidades A y B,
mientras que en las Especificación Formales 2 y 3 intervienen tres entidades A, B y C.
Las pruebas se han realizado sobre los tipos de redes más comúnmente usadas. En
primer lugar, las pruebas se hicieron en una Red de Área Local CSMA/CD (10baseT)
a 10 MBps. En segundo lugar, se han realizado las pruebas en Redes de Área
Extendida, concretamente, utilizando los protocolos Frame Relay y X.25. Para ello, se
han utilizado encaminadores con las diferentes configuraciones, en particular, con las
siguientes velocidades en la línea:
 Para Frame Relay, 2 Mbps y 64 Kbps.
 Para X.25, 2 Mbps , 64 Kbps y 9600 bps.
La topología de la red utilizada tiene el siguiente aspecto de la Fig. 8:
RED 3
MÁSCARA: 255.255.255.0
RED: 142.100.1.0
142.100.1.1

AUX
ROUTER
DTE

RAL

138.100.8.125

142.100.1.2

FR / X.25

AUX
ROUTER
DCE
139.100.10.1

RAL
HUB

.....
CLIENTE_ELI
138.100.10.248

S_AUTEN_ELI
139.100.10.248

RED 1
MÁSCARA : 255.255.248.0
RED : 138.100.8.0

SERVIDOR_ELI
139.100.10.247

RED 2
MÁSCARA : 255.255.248.0
RED : 139.100.8.0

*ELI: Elemento Lógico de
Implementación

Fig. 8. Topología de la red de área extensa FR/X25

Por último, también se han realizado las pruebas sobre la Red Digital de Servicios
Integrados. Para ello, se configuraron dos encaminadores con la pila de protocolos
RDSI en la línea, utilizándose una centralita RDSI interconectando ambos
encaminadores. Las pruebas se han realizado con configuraciones de un único canal
B (a 64 Kbps) y de dos canales B (a 128 Kbps). La topología es utilizada es la
mostrada en la Fig. 9).
NET 3
MASK: 255.255.255.0
NETWORK: 142.100.1.0

142.100.1.1

AUX

ISDN

142.100.1.2

RAL

138.100.8.125

AUX
ROUTER
DCE

ROUTER
DTE

139.100.10.1

RAL
HUB

.....
CLIENTE_ELI

S_AUTEN_ELI

138.100.10.248

139.100.10.248

RED 1
MÁSCARA : 255.255.248.0
RED : 138.100.8.0

SERVIDOR_ELI
139.100.10.247

RED 2
MÁSCARA : 255.255.248.0
RED : 139.100.8.0

*ELI: Elemento Lógico de Implementación

Fig. 9. Topología de la red de área extensa RDSI

Señalemos, por último, las características de los equipos en los que se ejecutó cada
una de las entidades:
 Entidad A: Pentium II a 450 Mhz, 128 Mbytes de RAM.
 Entidad B: Dual Pentium II a 400 MHz, 384 Mbytes de RAM.
 Entidad C: Pentium II a 400 Mhz, 128 Mbytes de RAM.
A continuación se muestran los resultados de las pruebas. Cada tabla contiene las
medidas de las tres especificaciones formales descritas anteriormente (P1, P2 y P3).
Las unidades de tiempo son todas en segundos y representan el tiempo total de
ejecución de los protocolos de seguridad y el envío de una cadena de prueba cifrada
con la clave de sesión distribuida en cada caso.
• PRUEBAS EN RAL (10-BASE-T)
Longitud Claves RSA
P1
P2
P3

512 bits
0.120
0.250
0.281

1024 bits
0.160
0.371
0.401

Tabla Resultados 1: Resultados obtenidos en RAL

2048 bits
0.641
1.472
0.852
• PRUEBAS EN FRAME RELAY
1.

FR 2 Mbps

Longitud Claves RSA

P1
P2
P3

512 bits
0.140
0.260
0.291

1024 bits
0.180
0.411
0.421

2048 bits
0.651
1.472
0.842

Tabla Resultados 2: Resultados obtenidos en FR 2Mbps

2.

FR 64 Kbps

Longitud Claves RSA
P1
P2
P3

512 bits
0.280
0.451
0.381

1024 bits
0.330
0.631
0.521

2048 bits
0.851
1.803
0.972

Tabla Resultados 3: Resultados obtenidos en FR 64Kbps

•

PRUEBAS EN X.25
1.

X.25 2 Mbps

Longitud Claves RSA
P1
P2
P3

512 bits
0.230
0.371
0.411

1024 bits
0.270
0.521
0.491

2048 bits
0.772
1.602
0.921

Tabla Resultados 4: Resultados obtenidos en X25 2Mbps

2.

X.25 64 Kbps

Longitud Claves RSA
P1
P2
P3

512 bits
0.351
0.541
0.441

1024 bits
0.410
0.721
0.591

2048 bits
0.942
1.923
1.031

Tabla Resultados 5: Resultados obtenidos en X25 64 Kbps
•

PRUEBAS EN RDSI
1.

RDSI 64 Kbps

Longitud Claves RSA
P1
P2
P3

512 bits
0.291
0.491
0.370

1024 bits
0.331
0.621
0.501

2048 bits
0.871
1.822
0.971

Tabla Resultados 6: Resultados obtenidos en RDSI 64 Kbps

2.

RDSI 128 Kbps

Longitud Claves RSA
P1
P2
P3

512 bits
0.290
0.471
0.381

1024 bits
0.320
0.621
0.500

2048 bits
0.861
1.852
0.971

Tabla Resultados 7: Resultados obtenidos en RDSI 128 Kbps

Los resultados obtenidos demuestran que nuestro Sistema de Implementación
Automática de Protocolos de Seguridad (S.I.A.P.S) obtiene resultados aceptables a la
hora de implementar servicios de seguridad para incorporar en agentes específicos. A
modo de ejemplo, un sistema multi-agente formado por tres agentes (cliente, servidor
e intermediario) que utilizase conexiones RDSI o Frame-Relay a 64Kbps y sistema
operativo Windows NT necesitaría un tiempo estimado entre 0,5 y 0,6seg. en distribuir
de forma segura una clave de sesión entre los agentes. Para ello, estaríamos
considerando la implementación de un protocolo de seguridad de 5 intercambios con
mecanismos de cifrado simetrico/asimetrico, mecanismos de sellos de tiempo y
funciones aleatorias (especificaciones 2 y 3) en el que se distribuyen las claves de
sesión utilizando cifrado de clave pública RSA con claves de una longitud de 1024
bits.

6

Conclusiones

En este artículo realizamos una propuesta de Arquitectura Multi-agente segura basada
en un nuevo concepto de interpretación automática de especificaciones formales de
protocolos de seguridad. Nuestra arquitectura proporciona un sistema dinámico y
abierto que permite ofrecer servicios de seguridad a cualquier aplicación distribuida.
El comercio electrónico en Internet, aplicación emergente en la actualidad con la
potencialidad de generar millones de transacciones en la red, será una de muchas
aplicaciones beneficiaria de nuestro sistema. Una de sus recientes variantes el
denominado comercio electrónico móvil (m-commerce), desarrollado desde redes de
Telecomunicaciones Móviles basa, precisamente, uno de los aspectos críticos del éxito
del servicio en el nivel de seguridad ofrecido al usuario. La combinación de la
tecnología orientada a objetos, la interpretación automática de especificaciones de
protocolos y la incorporación dinámica de mecanismos de cifrado simétrico y
asimétrico son los pilares de la infraestructura de nuestro sistema.

7. Referencias
1. Merwe, J., Solms, S.H. “Electronic commerce with secure intelligent trade
Agents”. Computers and security. Vol.17, Nº5, pp435-446, 1998.
2. Bradshaw, J. M. (Ed.) (1997), Software Agents, Boston: MIT Press.
3. Genesereth, M.R. & Ketchpel, S.P. Software agents. Communications of the ACM
37(7) (1994) 48–53.
4. Gomez,
R.
“Agentes
Móviles
y
CORBA”.
http://www.fie.us.es/
~ramon/tesis/CORBA/Seminario-MASIF/.
5. Li, J.L. “Mobile Agents and Security” Computer Communications, Volume 22,
Issues 15-16, 25 September 1999, Pages 1526-1527.
6. Greenberg, M.S., Byington, J. C., Harper, D.G. “Mobile agents and security”,
IEEE Communications Magazine, Volume 36, Issue 7, July 1998, Pages 76-85.
7. Jansen, W. A.
“Countermeasures for mobile agent security”, Computer
Communications, volume 23, Issue. 17, 1 November 2000, Pages 1667-1676.
8. Knowledge Query Management Language (KQML) (AgentWeb, Universidad de
Maryland en Baltimore): http://www.cs.umbc.edu/kqml/
9. Finin, T. & Labrou, Y. (1997), “KQML as an Agent Communication Language”,
In Software Agents. Bradshaw, J.M. (ed.), MIT Press, Cambridge, MA, pp. 291316, 1997.
10. Foner, L. & Crabtree, I. B. (1997), “Multi-Agent Matchmaking”, in Nwana, H. S.
& Azarmi, N. (Eds.),Software Agents and Soft Computing: Concepts and
Applications, Heidelberg: Springer-Verlag, 100-115.
11. Romao, A., Da Silva, M., Silva, A. “Secure electronic payments based on mobile
agents”, Distributed and Parallel Databases, Volume 8, Issue 4, October 2000,
Pages 447-470
12. Papastavrou, S., Samaras, G., Pitoura, E. “Mobile agents for World Wide Web
distributed database access” IEEE Transactions on Knowledge and Data
Engineering, Volume 12, Issue 5, September 2000, Pages 802-823.
13. A Quick Tour Of the CORBA Security Service. http://www.itsecurity.com/corba/
corbasec.htm.
14. JavaBeans (security). http://www.utcluj.ro/doc/PJB/html/ch15.htm
15. COM (security). http://www.microsoft.com/security/default.asp
16. Mengual Galán, L. “Un modelo formal para la especificación, analisis,
verificación e implementación de protocolos de seguridad.” Tesis Doctoral.
Facultad de Informática. Universidad Politécnica de Madrid. Julio 1998
17. Departament of Defense, Trusted Computer System Evaluation Criteria, DOD
5200.28-STD, December 1985.
18. Information Technology Security Evaluation Criteria. Harmonized Criteria 1991.
19. Trcek D. “Security policy conceptual modeling and formalization for networked
information systems.” Computers Comunications, Vol. 23, Nº 17, 2000.
20. Cohen, F. “Simulating Cyber Attacks, references and Consequences.” Computers
& Security, Vol. 18, Nº 6, 1999.
21. Soh, B.C,, and Dillon, T.S. “System Intrusion Process: a simulated model.”
Computers & Security, Vol. 16, Nº 1, 1997.
22. Khoussainov, R. and Patel, A. “LAN security: problems and solutions for Ethernet
networks.” Computers Standars & Interfaces, Vol. 22, Nº 3, August 2000.
23. Mengual, L., Barcia, N., Fernández, C., Morant, F., Yagüez, J. “A Model To
Specify Security Protocols On The Isdn” Journal Of Applied Computer Science.
Technical University Press Vol. 7, Nº2, 1999.
24. Yagüez, J., Morant, F., Mengual, L., Barcia, N., López, G. “An Innovative
Distributed Identity Delegation”. Journal Of Applied Computer Science.
Technical University Press 17-3-2000.
25. Lampard, R. “Formal Description Techniques in Data Security: An Evaluation
and Comparison.” National Physical Lab., Teddington, England Div. of
Information Technology and Computing, 1991, 59pp, PB91-229484/WCC.
26. Leduc, G., Germeau, F. “Verification of security protocols using LOTOS-method
aplication.” Computer Communication, Vol. 23, Nº 12, July 2000.
27. “Formal Description Techniques and Security Standard Conformance Testing.”
National Physical Lab., Teddington, England Div. of Information Technology and
Computing, 1991, 34pp, PB91-229542/WCC.
28. Gervais, M.P., Diagne, A. “Enhancing telecommunications service engineering
with mobile agent technology and formal methods” IEEE Communications
Magazine, Volume 36, Issue 7, July 1998, Pages 38-43.
29. Puliafito, A. and Tomarchio, O. “Using mobile agents to implement flexible
network management strategies” Computer Communications, Volume 23, Issue
8, 1 April 2000, Pages 708-719.
30. Ashley P., Vandenwauver M., Siebenlist F. “Applying authorization to intranets:
architectures, issues and APIs”. Computers Comunications, Vol. 23, Nº 17,
November 2000.
31. Zhou J. “Further analysis of the Internet key exchange protocol”. Computer
Communication, Vol. 23, Nº 17, November 2000.
32. Pieprzyk, J., Li, C.-H. “Multiparty key agreement protocols” IEE Proceedings:
Computers and Digital Techniques, Volume 147, Issue 4, July 2000, Pages 229236.
33. ftp://ftp.ox.ac.uk/pub/crypto/misc/
34. http://www.eskimo.com/~weidai/cryptlib.html

Más contenido relacionado

Similar a Arquitectura multi agente.doc

Exposicion isummit
Exposicion isummitExposicion isummit
Exposicion isummit
Freddy Berru
 
Exposicion isummit
Exposicion isummitExposicion isummit
Exposicion isummit
Freddy Berru
 
Exposicion isummit
Exposicion isummitExposicion isummit
Exposicion isummit
Freddy Berru
 
Exposicion isummit
Exposicion isummitExposicion isummit
Exposicion isummit
Freddy Berru
 
Extensibilidad y Seguridad
Extensibilidad y SeguridadExtensibilidad y Seguridad
Extensibilidad y Seguridad
Jose Paricagua Siñani
 
Glosario
GlosarioGlosario
Unidad 7 desempeño y seguridad
Unidad 7 desempeño y seguridadUnidad 7 desempeño y seguridad
Unidad 7 desempeño y seguridad
Carlos Martinez
 
ingenieria de software
 ingenieria de software ingenieria de software
ingenieria de software
EmanuelAmador
 
Seguridad y protección en los s.o
Seguridad y protección en los s.oSeguridad y protección en los s.o
Seguridad y protección en los s.o
JESÚS GUERRA
 
mapa mental - previo 2.pptx
mapa mental - previo 2.pptxmapa mental - previo 2.pptx
mapa mental - previo 2.pptx
MauricioArceBolados1
 
Mecanismos de Seguridad - Seguridad en Redes
Mecanismos de Seguridad - Seguridad en RedesMecanismos de Seguridad - Seguridad en Redes
Mecanismos de Seguridad - Seguridad en Redes
Leyda Cordoba Araujo
 
Diseño de sistemas de informacion
Diseño de sistemas de informacionDiseño de sistemas de informacion
Diseño de sistemas de informacion
Jhonderson
 
Protección y seguridad en s.o
Protección y seguridad en s.oProtección y seguridad en s.o
Protección y seguridad en s.o
Miguel J Rivero
 
SSEGURIDAD DE LA INFORMACION
SSEGURIDAD DE LA INFORMACIONSSEGURIDAD DE LA INFORMACION
SSEGURIDAD DE LA INFORMACION
Jessicakatherine
 
Clase rii 10 11 u3 sistemas cliente servidor
Clase rii 10 11 u3 sistemas cliente servidorClase rii 10 11 u3 sistemas cliente servidor
Clase rii 10 11 u3 sistemas cliente servidor
Gregorio Tkachuk
 
Presentación electiva v
Presentación electiva vPresentación electiva v
Presentación electiva v
Fran Deivis Rojas Marcano
 
Introduccion a los proyectos informaticos[1]
Introduccion a los proyectos informaticos[1]Introduccion a los proyectos informaticos[1]
Introduccion a los proyectos informaticos[1]
mnolguin
 
Investigación de tecnologías de sistemas distribuidos
Investigación de tecnologías de sistemas distribuidosInvestigación de tecnologías de sistemas distribuidos
Investigación de tecnologías de sistemas distribuidos
Yolanda Mora
 
2º Webinar - 3ª Ed. EXIN en Castellano: Luces y Sombras del Cloud Computing
2º Webinar - 3ª Ed. EXIN en Castellano: Luces y Sombras del Cloud Computing2º Webinar - 3ª Ed. EXIN en Castellano: Luces y Sombras del Cloud Computing
2º Webinar - 3ª Ed. EXIN en Castellano: Luces y Sombras del Cloud Computing
EXIN
 
Una Arquitectura Multiagente Inteligente para la Detección de Intrusos
Una Arquitectura Multiagente Inteligente para la Detección de IntrusosUna Arquitectura Multiagente Inteligente para la Detección de Intrusos
Una Arquitectura Multiagente Inteligente para la Detección de Intrusos
Juan A. Suárez Romero
 

Similar a Arquitectura multi agente.doc (20)

Exposicion isummit
Exposicion isummitExposicion isummit
Exposicion isummit
 
Exposicion isummit
Exposicion isummitExposicion isummit
Exposicion isummit
 
Exposicion isummit
Exposicion isummitExposicion isummit
Exposicion isummit
 
Exposicion isummit
Exposicion isummitExposicion isummit
Exposicion isummit
 
Extensibilidad y Seguridad
Extensibilidad y SeguridadExtensibilidad y Seguridad
Extensibilidad y Seguridad
 
Glosario
GlosarioGlosario
Glosario
 
Unidad 7 desempeño y seguridad
Unidad 7 desempeño y seguridadUnidad 7 desempeño y seguridad
Unidad 7 desempeño y seguridad
 
ingenieria de software
 ingenieria de software ingenieria de software
ingenieria de software
 
Seguridad y protección en los s.o
Seguridad y protección en los s.oSeguridad y protección en los s.o
Seguridad y protección en los s.o
 
mapa mental - previo 2.pptx
mapa mental - previo 2.pptxmapa mental - previo 2.pptx
mapa mental - previo 2.pptx
 
Mecanismos de Seguridad - Seguridad en Redes
Mecanismos de Seguridad - Seguridad en RedesMecanismos de Seguridad - Seguridad en Redes
Mecanismos de Seguridad - Seguridad en Redes
 
Diseño de sistemas de informacion
Diseño de sistemas de informacionDiseño de sistemas de informacion
Diseño de sistemas de informacion
 
Protección y seguridad en s.o
Protección y seguridad en s.oProtección y seguridad en s.o
Protección y seguridad en s.o
 
SSEGURIDAD DE LA INFORMACION
SSEGURIDAD DE LA INFORMACIONSSEGURIDAD DE LA INFORMACION
SSEGURIDAD DE LA INFORMACION
 
Clase rii 10 11 u3 sistemas cliente servidor
Clase rii 10 11 u3 sistemas cliente servidorClase rii 10 11 u3 sistemas cliente servidor
Clase rii 10 11 u3 sistemas cliente servidor
 
Presentación electiva v
Presentación electiva vPresentación electiva v
Presentación electiva v
 
Introduccion a los proyectos informaticos[1]
Introduccion a los proyectos informaticos[1]Introduccion a los proyectos informaticos[1]
Introduccion a los proyectos informaticos[1]
 
Investigación de tecnologías de sistemas distribuidos
Investigación de tecnologías de sistemas distribuidosInvestigación de tecnologías de sistemas distribuidos
Investigación de tecnologías de sistemas distribuidos
 
2º Webinar - 3ª Ed. EXIN en Castellano: Luces y Sombras del Cloud Computing
2º Webinar - 3ª Ed. EXIN en Castellano: Luces y Sombras del Cloud Computing2º Webinar - 3ª Ed. EXIN en Castellano: Luces y Sombras del Cloud Computing
2º Webinar - 3ª Ed. EXIN en Castellano: Luces y Sombras del Cloud Computing
 
Una Arquitectura Multiagente Inteligente para la Detección de Intrusos
Una Arquitectura Multiagente Inteligente para la Detección de IntrusosUna Arquitectura Multiagente Inteligente para la Detección de Intrusos
Una Arquitectura Multiagente Inteligente para la Detección de Intrusos
 

Más de jcfarit

Conceptos basicos de telefonia
Conceptos basicos de telefoniaConceptos basicos de telefonia
Conceptos basicos de telefonia
jcfarit
 
Manual de usuario Ruani
Manual de usuario RuaniManual de usuario Ruani
Manual de usuario Ruani
jcfarit
 
Unidad 3 gestion de procesos en linux
Unidad 3 gestion de procesos en linuxUnidad 3 gestion de procesos en linux
Unidad 3 gestion de procesos en linux
jcfarit
 
Arquitectura General del Sistema Operativo Linux
Arquitectura General del Sistema Operativo LinuxArquitectura General del Sistema Operativo Linux
Arquitectura General del Sistema Operativo Linux
jcfarit
 
Linq to sql 9
Linq to sql 9Linq to sql 9
Linq to sql 9
jcfarit
 
Linq to sql 8
Linq to sql 8Linq to sql 8
Linq to sql 8
jcfarit
 
Linq to sql 7
Linq to sql 7Linq to sql 7
Linq to sql 7
jcfarit
 
Linq to sql 6
Linq to sql 6Linq to sql 6
Linq to sql 6
jcfarit
 
Linq to sql 5
Linq to sql 5Linq to sql 5
Linq to sql 5
jcfarit
 
Linq to sql 4
Linq to sql 4Linq to sql 4
Linq to sql 4
jcfarit
 
Linq to sql 3
Linq to sql 3Linq to sql 3
Linq to sql 3
jcfarit
 
Linq to sql 2
Linq to sql 2Linq to sql 2
Linq to sql 2
jcfarit
 
Ejemplo Linq To SQL
Ejemplo Linq To SQLEjemplo Linq To SQL
Ejemplo Linq To SQL
jcfarit
 
ISO 27001 -6
ISO 27001 -6ISO 27001 -6
ISO 27001 -6
jcfarit
 
ISO 27001 - 5
ISO 27001 - 5ISO 27001 - 5
ISO 27001 - 5
jcfarit
 
ISO 27001 4
ISO 27001 4ISO 27001 4
ISO 27001 4
jcfarit
 
ISO 27001 -3
ISO 27001 -3 ISO 27001 -3
ISO 27001 -3
jcfarit
 
ISO 27001
ISO 27001ISO 27001
ISO 27001
jcfarit
 
ISO 27001
ISO 27001ISO 27001
ISO 27001
jcfarit
 
Curso ubuntuimprimible
Curso ubuntuimprimibleCurso ubuntuimprimible
Curso ubuntuimprimible
jcfarit
 

Más de jcfarit (20)

Conceptos basicos de telefonia
Conceptos basicos de telefoniaConceptos basicos de telefonia
Conceptos basicos de telefonia
 
Manual de usuario Ruani
Manual de usuario RuaniManual de usuario Ruani
Manual de usuario Ruani
 
Unidad 3 gestion de procesos en linux
Unidad 3 gestion de procesos en linuxUnidad 3 gestion de procesos en linux
Unidad 3 gestion de procesos en linux
 
Arquitectura General del Sistema Operativo Linux
Arquitectura General del Sistema Operativo LinuxArquitectura General del Sistema Operativo Linux
Arquitectura General del Sistema Operativo Linux
 
Linq to sql 9
Linq to sql 9Linq to sql 9
Linq to sql 9
 
Linq to sql 8
Linq to sql 8Linq to sql 8
Linq to sql 8
 
Linq to sql 7
Linq to sql 7Linq to sql 7
Linq to sql 7
 
Linq to sql 6
Linq to sql 6Linq to sql 6
Linq to sql 6
 
Linq to sql 5
Linq to sql 5Linq to sql 5
Linq to sql 5
 
Linq to sql 4
Linq to sql 4Linq to sql 4
Linq to sql 4
 
Linq to sql 3
Linq to sql 3Linq to sql 3
Linq to sql 3
 
Linq to sql 2
Linq to sql 2Linq to sql 2
Linq to sql 2
 
Ejemplo Linq To SQL
Ejemplo Linq To SQLEjemplo Linq To SQL
Ejemplo Linq To SQL
 
ISO 27001 -6
ISO 27001 -6ISO 27001 -6
ISO 27001 -6
 
ISO 27001 - 5
ISO 27001 - 5ISO 27001 - 5
ISO 27001 - 5
 
ISO 27001 4
ISO 27001 4ISO 27001 4
ISO 27001 4
 
ISO 27001 -3
ISO 27001 -3 ISO 27001 -3
ISO 27001 -3
 
ISO 27001
ISO 27001ISO 27001
ISO 27001
 
ISO 27001
ISO 27001ISO 27001
ISO 27001
 
Curso ubuntuimprimible
Curso ubuntuimprimibleCurso ubuntuimprimible
Curso ubuntuimprimible
 

Último

edublogs info.docx asdasfasfsawqrdqwfqwfqwfq
edublogs info.docx asdasfasfsawqrdqwfqwfqwfqedublogs info.docx asdasfasfsawqrdqwfqwfqwfq
edublogs info.docx asdasfasfsawqrdqwfqwfqwfq
larapalaciosmonzon28
 
Catalogo general tarifas 2024 Vaillant. Amado Salvador Distribuidor Oficial e...
Catalogo general tarifas 2024 Vaillant. Amado Salvador Distribuidor Oficial e...Catalogo general tarifas 2024 Vaillant. Amado Salvador Distribuidor Oficial e...
Catalogo general tarifas 2024 Vaillant. Amado Salvador Distribuidor Oficial e...
AMADO SALVADOR
 
Inteligencia Artificial
Inteligencia ArtificialInteligencia Artificial
Inteligencia Artificial
YashiraPaye
 
Modo test refrigeradores y codigos de errores 2018 V2.pdf
Modo test refrigeradores y codigos de errores 2018 V2.pdfModo test refrigeradores y codigos de errores 2018 V2.pdf
Modo test refrigeradores y codigos de errores 2018 V2.pdf
ranierglez
 
INFORMATICA Y TECNOLOGIA
INFORMATICA Y TECNOLOGIAINFORMATICA Y TECNOLOGIA
INFORMATICA Y TECNOLOGIA
renzocruz180310
 
Manual de Soporte y mantenimiento de equipo de cómputos
Manual de Soporte y mantenimiento de equipo de cómputosManual de Soporte y mantenimiento de equipo de cómputos
Manual de Soporte y mantenimiento de equipo de cómputos
cbtechchihuahua
 
625204013-64-Camino-a-----La-Lectura.pdf
625204013-64-Camino-a-----La-Lectura.pdf625204013-64-Camino-a-----La-Lectura.pdf
625204013-64-Camino-a-----La-Lectura.pdf
yuberpalma
 
MONOGRAFIA memoria RAM.docx trabajo DE TECNOLOGIA
MONOGRAFIA memoria RAM.docx trabajo DE TECNOLOGIAMONOGRAFIA memoria RAM.docx trabajo DE TECNOLOGIA
MONOGRAFIA memoria RAM.docx trabajo DE TECNOLOGIA
leia ereni
 
Nuevos tiempos, nuevos espacios.docxdsdsad
Nuevos tiempos, nuevos espacios.docxdsdsadNuevos tiempos, nuevos espacios.docxdsdsad
Nuevos tiempos, nuevos espacios.docxdsdsad
larapalaciosmonzon28
 
Todo sobre la tarjeta de video (Bienvenidos a mi blog personal)
Todo sobre la tarjeta de video (Bienvenidos a mi blog personal)Todo sobre la tarjeta de video (Bienvenidos a mi blog personal)
Todo sobre la tarjeta de video (Bienvenidos a mi blog personal)
AbrahamCastillo42
 
El uso de las TIC por Cecilia Pozos S..pptx
El uso de las TIC  por Cecilia Pozos S..pptxEl uso de las TIC  por Cecilia Pozos S..pptx
El uso de las TIC por Cecilia Pozos S..pptx
cecypozos703
 
Manual Web soporte y mantenimiento de equipo de computo
Manual Web soporte y mantenimiento de equipo de computoManual Web soporte y mantenimiento de equipo de computo
Manual Web soporte y mantenimiento de equipo de computo
mantenimientocarbra6
 
Mantenimiento de sistemas eléctricos y electrónicosarticles-241712_recurso_6....
Mantenimiento de sistemas eléctricos y electrónicosarticles-241712_recurso_6....Mantenimiento de sistemas eléctricos y electrónicosarticles-241712_recurso_6....
Mantenimiento de sistemas eléctricos y electrónicosarticles-241712_recurso_6....
MiguelAtencio10
 
PLAN DE MANTENMIENTO preventivo de un equipo de computo.pdf
PLAN DE MANTENMIENTO preventivo de un equipo de computo.pdfPLAN DE MANTENMIENTO preventivo de un equipo de computo.pdf
PLAN DE MANTENMIENTO preventivo de un equipo de computo.pdf
70244530
 
Programming & Artificial Intelligence ebook.pdf
Programming & Artificial Intelligence ebook.pdfProgramming & Artificial Intelligence ebook.pdf
Programming & Artificial Intelligence ebook.pdf
Manuel Diaz
 
mantenimiento de chasis y carroceria1.pptx
mantenimiento de chasis y carroceria1.pptxmantenimiento de chasis y carroceria1.pptx
mantenimiento de chasis y carroceria1.pptx
MiguelAtencio10
 
Presentación Seguridad Digital Profesional Azul Oscuro (1).pdf
Presentación Seguridad Digital Profesional Azul Oscuro (1).pdfPresentación Seguridad Digital Profesional Azul Oscuro (1).pdf
Presentación Seguridad Digital Profesional Azul Oscuro (1).pdf
giampierdiaz5
 
La Inteligencia Artificial en la actualidad.docx
La Inteligencia Artificial en la actualidad.docxLa Inteligencia Artificial en la actualidad.docx
La Inteligencia Artificial en la actualidad.docx
luiscohailatenazoa0
 
Second Life, informe de actividad del maestro Tapia
Second Life, informe de actividad del maestro TapiaSecond Life, informe de actividad del maestro Tapia
Second Life, informe de actividad del maestro Tapia
al050121024
 
TIC en educacion.rtf.docxlolololololololo
TIC en educacion.rtf.docxlolololololololoTIC en educacion.rtf.docxlolololololololo
TIC en educacion.rtf.docxlolololololololo
KukiiSanchez
 

Último (20)

edublogs info.docx asdasfasfsawqrdqwfqwfqwfq
edublogs info.docx asdasfasfsawqrdqwfqwfqwfqedublogs info.docx asdasfasfsawqrdqwfqwfqwfq
edublogs info.docx asdasfasfsawqrdqwfqwfqwfq
 
Catalogo general tarifas 2024 Vaillant. Amado Salvador Distribuidor Oficial e...
Catalogo general tarifas 2024 Vaillant. Amado Salvador Distribuidor Oficial e...Catalogo general tarifas 2024 Vaillant. Amado Salvador Distribuidor Oficial e...
Catalogo general tarifas 2024 Vaillant. Amado Salvador Distribuidor Oficial e...
 
Inteligencia Artificial
Inteligencia ArtificialInteligencia Artificial
Inteligencia Artificial
 
Modo test refrigeradores y codigos de errores 2018 V2.pdf
Modo test refrigeradores y codigos de errores 2018 V2.pdfModo test refrigeradores y codigos de errores 2018 V2.pdf
Modo test refrigeradores y codigos de errores 2018 V2.pdf
 
INFORMATICA Y TECNOLOGIA
INFORMATICA Y TECNOLOGIAINFORMATICA Y TECNOLOGIA
INFORMATICA Y TECNOLOGIA
 
Manual de Soporte y mantenimiento de equipo de cómputos
Manual de Soporte y mantenimiento de equipo de cómputosManual de Soporte y mantenimiento de equipo de cómputos
Manual de Soporte y mantenimiento de equipo de cómputos
 
625204013-64-Camino-a-----La-Lectura.pdf
625204013-64-Camino-a-----La-Lectura.pdf625204013-64-Camino-a-----La-Lectura.pdf
625204013-64-Camino-a-----La-Lectura.pdf
 
MONOGRAFIA memoria RAM.docx trabajo DE TECNOLOGIA
MONOGRAFIA memoria RAM.docx trabajo DE TECNOLOGIAMONOGRAFIA memoria RAM.docx trabajo DE TECNOLOGIA
MONOGRAFIA memoria RAM.docx trabajo DE TECNOLOGIA
 
Nuevos tiempos, nuevos espacios.docxdsdsad
Nuevos tiempos, nuevos espacios.docxdsdsadNuevos tiempos, nuevos espacios.docxdsdsad
Nuevos tiempos, nuevos espacios.docxdsdsad
 
Todo sobre la tarjeta de video (Bienvenidos a mi blog personal)
Todo sobre la tarjeta de video (Bienvenidos a mi blog personal)Todo sobre la tarjeta de video (Bienvenidos a mi blog personal)
Todo sobre la tarjeta de video (Bienvenidos a mi blog personal)
 
El uso de las TIC por Cecilia Pozos S..pptx
El uso de las TIC  por Cecilia Pozos S..pptxEl uso de las TIC  por Cecilia Pozos S..pptx
El uso de las TIC por Cecilia Pozos S..pptx
 
Manual Web soporte y mantenimiento de equipo de computo
Manual Web soporte y mantenimiento de equipo de computoManual Web soporte y mantenimiento de equipo de computo
Manual Web soporte y mantenimiento de equipo de computo
 
Mantenimiento de sistemas eléctricos y electrónicosarticles-241712_recurso_6....
Mantenimiento de sistemas eléctricos y electrónicosarticles-241712_recurso_6....Mantenimiento de sistemas eléctricos y electrónicosarticles-241712_recurso_6....
Mantenimiento de sistemas eléctricos y electrónicosarticles-241712_recurso_6....
 
PLAN DE MANTENMIENTO preventivo de un equipo de computo.pdf
PLAN DE MANTENMIENTO preventivo de un equipo de computo.pdfPLAN DE MANTENMIENTO preventivo de un equipo de computo.pdf
PLAN DE MANTENMIENTO preventivo de un equipo de computo.pdf
 
Programming & Artificial Intelligence ebook.pdf
Programming & Artificial Intelligence ebook.pdfProgramming & Artificial Intelligence ebook.pdf
Programming & Artificial Intelligence ebook.pdf
 
mantenimiento de chasis y carroceria1.pptx
mantenimiento de chasis y carroceria1.pptxmantenimiento de chasis y carroceria1.pptx
mantenimiento de chasis y carroceria1.pptx
 
Presentación Seguridad Digital Profesional Azul Oscuro (1).pdf
Presentación Seguridad Digital Profesional Azul Oscuro (1).pdfPresentación Seguridad Digital Profesional Azul Oscuro (1).pdf
Presentación Seguridad Digital Profesional Azul Oscuro (1).pdf
 
La Inteligencia Artificial en la actualidad.docx
La Inteligencia Artificial en la actualidad.docxLa Inteligencia Artificial en la actualidad.docx
La Inteligencia Artificial en la actualidad.docx
 
Second Life, informe de actividad del maestro Tapia
Second Life, informe de actividad del maestro TapiaSecond Life, informe de actividad del maestro Tapia
Second Life, informe de actividad del maestro Tapia
 
TIC en educacion.rtf.docxlolololololololo
TIC en educacion.rtf.docxlolololololololoTIC en educacion.rtf.docxlolololololololo
TIC en educacion.rtf.docxlolololololololo
 

Arquitectura multi agente.doc

  • 1. ARQUITECTURA MULTI-AGENTE SEGURA BASADA EN UN SISTEMA DE IMPLEMENTACIÓN AUTOMÁTICA DE PROTOCOLOS DE SEGURIDAD 1 Luis Mengual1, Nicolás Barcia1, Jesús Bobadilla2, Ernesto Jiménez2, Julio Setién1, Javier Yágüez1 Universidad Politécnica de Madrid, 28031 Madrid nicolas, jsetien, jyaguez}@fi.upm.es 2{jbobi, ernes}@eui.upm.es 1{lmengual, Abstract. En este artículo presentamos una Arquitectura Multi-agente segura basada en un nuevo concepto de implementación de servicios de seguridad. La idea se basa en incorporar a nuestros agentes una capa de seguridad denominada S.I.A.P.S (Sistema de Implementación Automática de Protocolos de Seguridad). Esta capa adicional en el software del agente proporciona un código único, versátil y flexible capaz de implementar, en entornos TCP/IP, cualquier protocolo de seguridad a partir de su Especificación Formal. La incorporación de nuestro sistema de seguridad en el código de un agente abre un nuevo campo en la filosofía de construcción de agentes y su implantación en servicios emergentes como el comercio electrónico en Internet [1]. Nuestra propuesta se aleja de las soluciones estándar y rígidas ofrecidas por las plataformas y entornos distribuidos convencionales (CORBA, JavaBeans y COM). En nuestro sistema, los agentes pueden diseñar e implementar de forma automática y dinámica protocolos de seguridad adaptados al contexto en el se desarrollan los servicios y aplicaciones de usuario. 1 Introducción La tecnología de agentes es un campo emergente en el desarrollo de aplicaciones distribuidas [2], [3]. Los agentes son entidades software programadas que llevan a cabo una serie de operaciones en nombre de un usuario o de otro programa, con algún grado de independencia o autonomía, empleando algún conocimiento o representación de los objetivos o deseos del usuario. Cuando hablamos de agentes hay tres dimensiones o coordenadas las cuales usamos como medida de sus capacidades: representación o mediación, inteligencia y movilidad. La representación tiene que ver con el grado de autonomía que el agente software tiene en representar el usuario a otros agentes, aplicaciones y sistemas de computadoras. La inteligencia se refiere a la capacidad del agente para capturar y 1 Este trabajo esta realizado en el marco del Proyecto CICYT de Investigación Sistema Abierto de Presentación Digital Multimedia en Tiempo Real (TIC2000-1734-C03-02
  • 2. aplicar el conocimiento y el procesamiento para solucionar problemas. Por lo tanto, los agentes pueden ser relativamente simples usando simple lógica o pueden ser relativamente sofisticados usando complejos métodos basados en Inteligencia Artificial como inferencias y aprendizaje. Los agentes pueden ser estáticos o móviles. Un agente estático es aquel que sólo puede ejecutarse en la máquina donde fue iniciado. Un agente móvil es aquel que no está limitado al sistema donde se inició su ejecución, siendo capaz de transportarse de una máquina a otra de la red. Esta posibilidad le permite interactuar con el objeto deseado de forma directa sobre el sistema de agentes donde se halla dicho objeto. Los agentes proporcionan una serie de ventajas respecto de otras técnicas informáticas distribuidas [4]: • Los usuarios que utilizan sistemas informáticos con baja capacidad de proceso, los que tienen un bajo ancho de banda en la red o los que disponen de poco espacio de almacenamiento pueden utilizar agentes para solucionar sus necesidades, desconectando su sistema informático de la red o pidiendo que otro sistema realice los cálculos y recogiendo posteriormente los resultados. • Aplicaciones como el comercio electrónico, mejoran sus prestaciones, ya que el usuario puede dar instrucciones a un agente para que realice la compra cuando se cumplan las condiciones óptimas. El proceso es más rápido y económico porque evita tener que hacer comunicaciones periódicas para comprobar el estado del producto. Por el contrario, tienen una serie de riesgos relativos a la seguridad ([5], [6], [7]). En primer lugar un agente es representante de un usuario, por consiguiente, se debe garantizar y probar en todo momento la identidad del usuario a quien representa evitando suplantaciones fraudulentas. Además, los agentes no actúan en solitario, sino que se localizan en entornos o plataformas con varios agentes, donde cada uno tiene sus propios objetivos, toma sus decisiones y puede tener la capacidad de comunicarse con otros agentes, lo que crea nuevos riesgos en las comunicaciones. Dichos entornos se conocen como sistemas multi-agente. Los sistemas multi-agente dan un mayor nivel de abstracción con respecto a la informática distribuida tradicional, estando más cercanos a las expectativas del usuario y permitiendo al programador una mayor flexibilidad para expresar el comportamiento de los agentes. Sin embargo, este tipo de diseños suele plantear una serie de problemas, como la elección de la forma de comunicación entre los agentes, del tipo de plataforma de desarrollo, o la seguridad del sistema. Históricamente, la comunicación entre agentes de un sistema se realizaba mediante lenguajes propios de cada vendedor, impidiendo la comprensión entre los agentes de sistemas heterogéneos, con una semántica informal y con poca autonomía. A principios de los años 80, el DARPA estadounidense desarrolló el “Knowledge Query Management Language” (KQML) ([8], [9]) que pretendía convertirse en una norma para la comunicación entre agentes. El lenguaje KQML está enfocado a los formatos de los mensajes y al protocolo de manejo de los mismos. Uno de los criterios del diseño de KQML es producir un lenguaje que pudiese soportar una gran variedad de arquitecturas de agentes. Este fue uno de los motivos de introducir un agente especial “intermediario”. Este agente se encargaría de encaminar los mensajes en función del contenido y realizar las funciones de mediación entre los agentes proveedores y clientes [10].
  • 3. El control de la seguridad en sistemas multi-agente es esencial en aquellos servicios que implican la distribución en red de información sensible. Así la implementación con sistemas multi-agente de servicios ampliamente utilizados o en fase emergente en Internet como el comercio electrónico, transferencias bancarias, declaraciones fiscales o gestión de red no sería posible sino estuviera garantizada la autenticación de los usuarios, la integridad de los datos y confidencialidad de la información [11], [12]. Las propuestas actuales de seguridad en comunicaciones entre agentes se basan en soluciones rígidas. Así las distintas plataformas y entornos distribuidos convencionales (CORBA [13], JavaBeans [14] y COM [15]) ofrecen soluciones estándar poco flexibles. Adicionalmente, en algunos casos, se han desarrollado soluciones particulares orientadas al servicio ofrecido por un sistema multi-agente [1]. Nosotros proponemos una solución dinámica, flexible e independiente de los servicios o aplicaciones que implica la incorporación en cada agente del sistema de una capa adicional de seguridad S.I.A.P.S (Sistema de Implementación Automática de Protocolos de Seguridad) [16]. Esta capa adicional será capaz de interpretar e implementar cualquier protocolo de seguridad a partir de su especificación formal. En dicha especificación estarán definidos los intercambios que comprenden un protocolo de seguridad, así como las funciones de seguridad necesarias para garantizar los requisitos de la política de seguridad (generación de números aleatorios como identificadores de uso único, sellos de tiempo, generación de claves asimétricas y simétricas, funciones de cifrado, etc.). Las Técnicas de Descripción Formal son la base del soporte automatizado en diferentes actividades de desarrollo. La especificación formal es una herramienta esencial en la ingeniería de protocolos de comunicaciones. Empleando las Técnicas de Descripción Formal se pueden obtener mejoras significativas en la calidad del producto, tiempo de disponibilidad en el mercado y coste del ciclo de vida. Los modelos formales de seguridad han evolucionado en paralelo con el desarrollo de los sistemas informáticos (software, hardware, sistemas operativos), así como con la tecnología y extensión de las redes de datos. Inicialmente los modelos formales han tratado el problema de control de acceso en sistemas individuales. Los criterios de seguridad TCSEC (Trusted Computer System Evaluation Criteria) del DoD (Departament of Defense) del gobierno de EEUU [17] o el ITSEC europeo (Information Technology Security Evaluation Criteria) [18] son un ejemplo de la formalización en el campo de los sistemas informáticos seguros. Otros ejemplos son los modelos desarrollados en [19], [20], [21]. Posteriormente, el notable impulso de las Redes de Área Local, y su interconexión con redes de remotas, ha dado lugar a nuevas y más sofisticadas amenazas asociadas a la distribución de la información (grabaciones, retransmisiones, suplantaciones, etc) [22]. Todo ello ha conducido al desarrollo de nuevos mecanismos y funciones de seguridad para proteger la información en tránsito en los sistemas abiertos ([23], [24]), y no solo contemplar los problemas de control de acceso a recursos en los sistemas individuales. En este caso, las Técnicas de Descripción Formal (TDF) se han utilizado para especificar protocolos de seguridad y evaluar la vulnerabilidad de dichos protocolos frente a distintos ataques. Ejemplos de este tipo de análisis formal se tienen en [25] y [26].
  • 4. La especificación formal permite verificar y validar protocolos de comunicaciones de manera eficiente como un paso previo al desarrollo del producto software, sin embargo la utilización de Técnicas de Descripción Formal en la especificación de protocolos de seguridad implica una serie de consideraciones adicionales no contempladas en las especificaciones convencionales de protocolos de comunicaciones [27]. La aplicación de técnicas de descripción formal al campo de la seguridad debería contemplar la necesidad de especificar adecuadamente los intercambios que corresponden a los protocolos de seguridad, así como las funciones y mecanismos implicados con el objeto de ser interpretadas en fase de implementación. Sin embargo, esta tarea no es fácil, un protocolo de seguridad es un conjunto de intercambios que implican funciones de cifrado simétrico y asimétrico, generación de números aleatorios, sellos de tiempo, etc. Especificar formalmente estos intercambios e implementarlos de forma automática no es tarea fácil. Si además pretendemos que sea un agente la entidad software que realice está misión la tarea se complica todavía más [28], [29]. No obstante los beneficios son indudables a la hora de implantar aplicaciones distribuidas y servicios de telecomunicaciones en entornos abiertos. 2 Innovación del Sistema de Implementación Automática de Protocolos de Seguridad (S.I.A.P.S) El Sistema de Implementación Automática de Protocolos de Seguridad es capaz de incorporar dinámicamente distintos protocolos de seguridad a una comunicación entre aplicaciones TCP/IP. Para ello, las entidades pares en un entorno distribuido tienen la capacidad de interpretar especificaciones de protocolos de seguridad y, por tanto, disponen de un sólo código independiente del protocolo de seguridad específico. Para comprender la innovación que supone la interpretación automática de una especificación formal vamos a comparar esta idea con la concepción habitual de implementación de protocolos. Tradicionalmente, la implementación de un protocolo se ha realizado generando un código independiente en cada una de las entidades participantes ([30], [31], [32]). De esta forma se cumplen las funcionalidades, en general distintas, asociadas a cada entidad para ese protocolo. Por consiguiente, con este esquema, si se tuviera que implementar otro protocolo distinto se necesitaría un nuevo código, que además debería ser distinto para cada entidad (ver Fig. 1).
  • 5. ESPECIFICACIÓN ... MESSAGES 1:A->C: peticion 2:C->A: Ka(Ks), Kb( Ks) 3:A->B:Kb( Ks) ... ... componer(m1) enviar( dir(C), m1) recibir( dir(C), m2) analizar(m2) componer(m3) enviar( dir(B), m3) ... CÓDIGO DE CLIENTE ... recibir( dir(A), m1) analizar(m1) componer(m2) enviar( dir(A), m2) ... AUTORIDAD DE AUTENTICACIÓN • Cada protocolo, distinta implementación • Dado el protocolo, distinta implementación para cada entidad ... recibir( dir(A), m3) analizar(m3) ... CÓDIGO DE SERVIDOR Fig. 1. Proceso tradicional de implementación de protocolos de seguridad La infraestructura software desarrollada en el S.I.A.P.S permite implementar cualquier protocolo de seguridad con un mismo código de interpretación de protocolos localizado en cada entidad participante. Cada una de las entidades deberá saber cuál es su comportamiento en función de la especificación formal del protocolo. En la Fig.2 se describe esta idea. ESPECIFICACIÓN ... MESSAGES 1:A->C: peticion 2:C->A: Ka (Ks ), Kb( Ks ) 3:A->B:Kb( Ks ) ... ... Para cada mensaje M Si YoSoy (emisor(M)) componer(M) enviar(receptor(M), M) Si YoSoy (recptor (M)) recibir(emisor(M), M) analizar(M) ... CÓDIGO DE CLIENTE AUTORIDAD DE AUTENTICACIÓN • Una única implementación, válida para todos los protocolos y todas las entidades CÓDIGO DE INTERPRETACIÓN DE ESPECIFICACIONES FORMALES DE PROTOCOLOS DE SEGURIDAD CÓDIGO DE SERVIDOR Fig. 2. Interpretación automática de protocolos de seguridad Los beneficios de esta nueva filosofía de implementación de protocolos de seguridad se reflejan en la Fig. 3.
  • 6. 1 A1 2 B1 C1 A2 B2 1 C2 A1 B1 C1 2 A2 B2 C2 Fig. 3. Cambio de filosofía en la implementación de protocolos En un esquema de implementación tradicional, si aplicaciones distintas necesitan distintos servicios de seguridad materializados con dos protocolos de seguridad diferentes (1 y 2) harían falta 6 códigos distintos (2 por cada entidad participante). En nuestro modelo, con un único código de interpretación de protocolos las entidades son capaces de implementar cualquier protocolo de seguridad. Los beneficios de este esquema son indudables a la hora de ofrecer dinámicamente servicios de seguridad a las aplicaciones y usuarios. En la Fig. 4 se muestra el nuevo nivel de seguridad desarrollado por el S.I.A.P.S sobre la arquitectura TCP/IP. Este nivel de seguridad será el encargado de ofrecer al nivel superior (nivel de aplicación) un conjunto de funciones (primitivas) para el establecimiento de comunicaciones seguras entre aplicaciones en la arquitectura TCP/IP. Aplicaciones de usuario, bases de datos, … NIVEL DE USUARIO datos de usuario NIVEL DE SEGURIDAD S. I. A. P. S. datos de usuario Interfaz sockets UDP TCP NIVEL TCP cab. TCP datos de usuario IP NIVEL IP cab. IP cab. TCP datos de usuario S. I. A. P. S.: Sistema de Implementación Automática de Protocolos de Seguridad Fig. 4. Arquitectura de Seguridad desarrollada en el Elemento Lógico de Implementación 3 Interpretación de Protocolos a partir de su especificación formal en el S.I.A.P.S. El S.I.A.P.S. dispone de dos módulos diferenciados: el Analizador Sintáctico y el Código de Implementación de Protocolos. La función del Analizador Sintáctico es
  • 7. verificar la sintaxis de la especificación formal. El Código de Implementación de Protocolos es capaz de crear la infraestructura necesaria para posibilitar el establecimiento de comunicaciones seguras entre aplicaciones que soportan la arquitectura TCP/IP utilizando la interfaz sockets y automatizar completamente el proceso de implementación de protocolos de seguridad a partir de una especificación formal. La sintaxis y semántica contemplada en la definición de las especificación formales de protocolos de seguridad aparece recogida en [16]. El diseño de esta especificación, realizado de acuerdo a los requisitos expuestos en [16] contiene los siguientes módulos: 1. Identificador de inicio de la especificación. Este módulo determina el comienzo de la especificación formal de un protocolo de seguridad. 2. Declaración de Constantes. Este módulo contiene las cadenas de caracteres que denominaremos identificadores constantes que se utilizarán en la definición del protocolo de seguridad. Se han definido cinco tipos de identificadores: Identificadores de dirección, de clave, numéricos, temporales y de datos. 3. Mensajes implicados en el protocolo de seguridad. Este módulo contiene los mensajes implicados en el protocolo de seguridad identificados por un número entero. Cada mensaje contiene identificadores constantes o variables y/o patrones de cifrado. Un patrón de cifrado representa un conjunto de identificadores de dirección, de clave, numéricos o temporales cifrados por un identificador de tipo clave. 4. Declaración de Relaciones asociadas a mensajes. Este módulo contiene un conjunto de procedimientos o condiciones que una entidad par debe aplicar a la hora de generar un mensaje. Es decir, se trataría de especificar las funciones y mecanismos de seguridad implicados en los protocolos criptográficos. Por ejemplo, cifrado simétrico y asimétrico, generación de identificadores de uso único, sellos de tiempo etc. A cada una de estas funciones le corresponde un identificador formal: “sesion_key()”, public_key()”, “secret_key()”, “random()”, “function_x()” Un ejemplo de una especificación formal, está representado en la Especificación 1: PROTOCOL SPECIFICATION CONSTANTS a,b:address. MESSAGES 1:a->b:KPA; 2:b->a:encrypt(KPA,KS). RELATIONS 1:public_key(A,KPA:A); 2:sesion_key(KS:B). Especificación 1. Especificación formal de prueba nº1
  • 8. En este ejemplo sencillo tenemos un protocolo formado por dos intercambios. En el primero de ellos la entidad A envía a la entidad B una variable “KPA”. Esta variable tiene asociada en el módulo RELATIONS la función “public_key(A,KPA:A)”. Esto significa que la variable “KPA” es la clave pública de A que deberá ser generada por la propia entidad. En realidad la entidad A generará un par clave pública-clave privada que almacenará en una Tabla de Variables por si fuera necesario utilizarlas más adelante en la construcción de algún mensaje del protocolo. Una vez obtenidas y almacenadas las claves de acuerdo a la especificación del protocolo la entidad A enviará a la entidad B su clave pública “KPA”. La entidad B recibirá a través de su interfaz sockets el mensaje 1 en el que identificará a “KPA” como la clave pública de la entidad A y la almacenará en su Tabla de Variables. En el mensaje 2 la entidad B construirá el mensaje 2. Este mensaje contiene un patrón de cifrado. Recorriendo el patrón de cifrado la entidad B determina que tiene que cifrar con la clave pública de A “KPA” una variable “KS”. Ahora bien, la variable “KS” tiene asociada una relación “sesion_key(KS:B)”. Esto significa que “KS” es una clave de sesión que tiene que generar aleatoriamente la entidad B. Por consiguiente, en este caso el proceso de interpretación consiste en primer lugar en la generación de la clave de sesión “KS” y posteriormente en el cifrado de esta clave con la clave pública de A “KPA”. Finalmente, la entidad A recibirá un mensaje por su interfaz sockets en el que podrá identificar un patrón de cifrado, el cual será incorporado automáticamente a su Tabla de Variables. La entidad A identificará que este patrón se ha cifrado con su clave pública y, por consiguiente, tendrá que descifrarlo con su clave privada dual. Una vez descifrado sabrá identificar a “KS” como la clave de sesión que almacenará en su Tabla de Variables. Las Tablas de Variables utilizadas por las entidades permiten agilizar el proceso de interpretación y composición de los mensajes. En nuestro ejemplo las tablas generadas en las entidades A y B serían las de las Tablas de Variables 1 y 2. A_public.key A_secret.key _KPA_KS Sesion.key <<valor de la clave pública de A>> <<valor de la clave privada de A>> <<valor patrón de cifrado>> <<valor de la clave sesión>> Tabla de Variables 1. Tabla de Variables de la entidad A A_public.key Sesion.key <<valor de la clave pública de A>> <<valor de la clave sesión>> Tabla de Variables 2. Tabla de Variables de la entidad B
  • 9. 4 Arquitectura Multi-Agente incorporando el Sistema Implementación Automática de Protocolos de seguridad de Nuestra propuesta se centra en el desarrollo de una plataforma de seguridad de agentes estáticos ofreciendo una Interfaz de desarrollo de Aplicaciones para la implementación de agentes específicos. Es decir, proporcionamos una serie de métodos que garantizan las comunicaciones seguras entre agentes. Esta nueva filosofía de implementación simplifica la tarea del desarrollador de agentes de forma que el código propio del agente es transparente a la problemática de seguridad. La Arquitectura de Sistema Multi-agente que proponemos en este artículo (Fig. 5) permite proporcionar a cualquier agente del sistema de la funcionalidad necesaria para implementar cualquier protocolo de seguridad y, por consiguiente, garantizar las comunicaciones entre agentes y ofrecer seguridad al usuario del servicio. En definitiva, nuestro sistema multi-agente: • Permite ofrecer a cualquier aplicación distribuida (comercio electrónico, asistentes personales, servicios de distribución de información, transferencias de datos, servicios de telecomunicaciones, aplicaciones de grupo, gestión de red, declaraciones fiscales, aplicaciones de procesamiento paralelo, etc.) servicios dinámicos y flexibles de seguridad. • Incorpora un nuevo concepto de implementación de protocolos de seguridad basado en la interpretación formal de especificaciones formales de protocolos de seguridad. [16]. La idea básica es que nuestros agentes sean capaces de implementar de forma automática cualquier protocolo de seguridad a partir de su especificación formal. Los usuarios finales o bien los agentes intermediarios podrán elegir el protocolo de seguridad a utilizar en cada aplicación, para garantizar la autenticación de los interlocutores, la integridad de los datos o la confidencialidad de la información. • Proporciona la infraestructura necesaria para la incorporación de las funcionalidades propias de agentes específicos (comercio electrónico, gestión de red, etc.)..
  • 10. AGENTE INTERMEDIARIO S.I.A.P.S. AGENTE CLIENTE AGENTE SERVIDOR S.I.A.P.S. S.I.A.P.S. S. I. A. P. S.: Sistema de Implementación Automática de Protocolos de Seguridad Fig. 5. Arquitectura Multi-agente segura Nuestra arquitectura ofrece a los implementadores de agentes la Clase Base “Agente_Seguro” (ver Fig. 6) que permite construir agentes en el contexto de cualquier aplicación. En Clase Base “Agente_Seguro” está implementado el S.I.A.P.S (“Sistema de Implementación de Protocolos de Seguridad”) a través del método “Implementar_Protocolo_Seguridad” que permitirá la interpretación de cualquier protocolo de seguridad a partir de una especificación formal. Este código será común a cualquier agente de modo que agentes específicos heredarán este método de clase.
  • 11. ESPECIFICACIÓN FORMAL PROTOCOL SPECIFICATION CONSTANTS ----------MESSAGES -----------RELATIONS ------------------------------- class Agente_Seguro { private: ............................................. public: Inicializar _Agente() { } Implementar_Protocolo_ Seguridad () { // Implementación intercambio de mensajes a partir de la espec. formal // Implementación funciones de seguridad a partir de la espec.. formal // Implementación de mecanismos de seguridad } ................................................................ Agente_Comercio_Electrónico{ }; Agente_Comercio_ Electronico }; { Agente_ Gestión Gestion{ }; Agente_Transferencias_Bancarias { }; ...................................................... } Fig. 6. Clase base “Agente_Seguro Un ejemplo de un sistema multi-agente con la infraestructura de seguridad de acuerdo a nuestro planteamiento es la representada en la Fig. 7, en la cual se muestran tres agentes específicos de una aplicación de comercio electrónico que derivan de la clase base Agente_Seguro y que, por consiguiente, heredan sus métodos. Nótese que en cada agente específico se deberá ahora implementar los métodos “Inicializar_agente” o “Agente_Comercio_Electronico” que no aparecen implementados en la clase base “Agente_Seguro. Estos métodos se codificarán de acuerdo a los requisitos específicos del servicio ofrecido al usuario y de la política de seguridad la organización. Nuestra Arquitectura de sistema multi-agente proporciona la funcionalidad necesaria para facilitar la tarea del programador de agentes forma que éste solo tenga que invocar a métodos que implementan servicios y protocolos de seguridad en la comunicación entre agentes.
  • 12. ESPECIFICACIÓN FORMAL PROTOCOL SPECIFICATION CONSTANTS ----------MESSAGES -----------RELATIONS ------------------------------- Agente_Intermediario_Comercio_ Electrónico : Agente_Seguro { private : ................................................ public : Inicializar _Agente() { // Inicialización parámetros agente intermediario // Inicialización Infraestructura de comunicaciones // Distribución especificación formal de protocolo de seguridad } Agente_Comercio_ Electrónico { // Invocación método Implementar_Protocolo_Seguridad de clase base // Implemetación Agente intermediario comercio electrónico seguro }; } ESPECIFICACIÓN FORMAL ESPECIFICACIÓN FORMAL PROTOCOL SPECIFICATION CONSTANTS ----------MESSAGES -----------RELATIONS ----------- PROTOCOL SPECIFICATION CONSTANTS ----------MESSAGES -----------RELATIONS ----------- ----------- ----------- ----------- ----------- Agente_Cliente_Comercio_ Electrónico : Agente_Seguro { private : ................................................ public : Inicializar _Agente() { // Inicialización parámetros agente cliente // Inicialización Infraestructura de comunicaciones // Distribución especificación formal de proto. seguridad } Agente_Servidor_Comercio_ Electrónico : Agente_Seguro { private : ................................................ public : Inicializar _Agente() { // Inicialización parámetros agente servidor // Inicialización Infraestructura de comunicaciones // Distribución especificación formal de proto. seguridad } Agente_Comercio_ Electrónico { // Invocación método Implementar_Protocolo_Seguridad de clase base Agente_Comercio_ Electrónico { // Invocación método Implementar_Protocolo_Seguridad de clase base }; } // Implementación Agente cliente comercio electrónico seguro }; } // Implementación Agente servidor comercio electrónico seguro Fig. 7. Arquitectura Multi-agente segura 5 Resultados Los resultados presentados este apartado se refieren, a modo de ejemplo, a los tiempos de ejecución de tres protocolos de seguridad en distintas redes de comunicaciones. Estos protocolos que se han especificado e implementado utilizando el S.I.A.P.S. son un ejemplo de tres propuestas de seguridad a incorporar a nuestros agentes. Como ya se ha comentado, la versatilidad de nuestra solución consiste en que, únicamente, con la especificación del protocolo de seguridad solicitado nuestros agentes implementan de forma automática el servicio de seguridad asociado adecuado al contexto de actuación de los agentes. Cada una de las especificaciones propuestas incorpora progresivamente más funciones y mecanismos de seguridad que hacen más compleja la tarea de implementación automática. Cada una de las pruebas consiste en realizar medidas de tiempo de ejecución del protocolo en la entidad Cliente utilizando sistema operativo Windows NT. Para la implementación de mecanismos de cifrado simétrico se ha utilizado el código Blowfish disponible en [33] y para el cifrado asimétrico el código RSA de la librería Crypto++ [34]. Las pruebas se realizaron sobre tres especificaciones formales diferentes. Las especificaciones formales utilizadas fueron
  • 13. en primer lugar la Especificación formal P1, ya analizada anteriormente, y las Especificación Formales P2 y P3: Especificación formal P2: Esta especificación formal es una aproximación del protocolo SSL (Security Socket Layer), en el que la entidad A genera una clave de sesión y se la envía a la entidad B cifrada con la clave pública de la entidad B. Una tercera entidad, la entidad C realiza funciones de autenticación y firma de las claves públicas distribuidas. La especificación formal es la siguiente: PROTOCOL SPECIFICATION CONSTANTS a,b,c:address; req:data. MESSAGES 1:c->a:KPC; 2:a->b:req; 3:b->c:KPB; 4:c->b:encrypt(KSC,[KPB,T1]),KPC; 5:b->a:encrypt(KSC,[KPB,T1]); 6:a->b:encrypt(KPB,KS). RELATIONS 1:public_key(C,KPC:C); 3:public_key(B,KPB:B); 4:secret_key(C,KSC:C),time(T1:C); 6:sesion_key(KS:A). Especificación 2: Especificación formal de prueba nº2 Especificación formal P3: En esta especificación formal la entidad C genera la clave de sesión y se la envía a las entidades A y B cifrada con la clave pública de cada una de estas entidades respectivamente. Esta especificación contiene ejemplos de números aleatorios, funciones, etc.: PROTOCOL SPECIFICATION CONSTANTS a,b,c:address; dat:data. MESSAGES 1:a->c:req,B,N1,KPA; 2:c->a:encrypt(KPA,[req,KS,N2]); 3:c->b:req,N3; 4:b->c:req,N4,KPB; 5:c->b:encrypt(KPB,[req,KS,N2]). RELATIONS 1:random(N1:A),public_key(A,KPA:A); 2:sesion_key(KS:C),function_1(N1,N2:C); 3:random(N3:C); 4:public_key(B,KPB:B),function_1(N3,N4:B).
  • 14. Especificación 3: Especificación formal de prueba nº3 Nótese que en la Especificación Formal 1 intervienen dos entidades A y B, mientras que en las Especificación Formales 2 y 3 intervienen tres entidades A, B y C. Las pruebas se han realizado sobre los tipos de redes más comúnmente usadas. En primer lugar, las pruebas se hicieron en una Red de Área Local CSMA/CD (10baseT) a 10 MBps. En segundo lugar, se han realizado las pruebas en Redes de Área Extendida, concretamente, utilizando los protocolos Frame Relay y X.25. Para ello, se han utilizado encaminadores con las diferentes configuraciones, en particular, con las siguientes velocidades en la línea:  Para Frame Relay, 2 Mbps y 64 Kbps.  Para X.25, 2 Mbps , 64 Kbps y 9600 bps. La topología de la red utilizada tiene el siguiente aspecto de la Fig. 8: RED 3 MÁSCARA: 255.255.255.0 RED: 142.100.1.0 142.100.1.1 AUX ROUTER DTE RAL 138.100.8.125 142.100.1.2 FR / X.25 AUX ROUTER DCE 139.100.10.1 RAL HUB ..... CLIENTE_ELI 138.100.10.248 S_AUTEN_ELI 139.100.10.248 RED 1 MÁSCARA : 255.255.248.0 RED : 138.100.8.0 SERVIDOR_ELI 139.100.10.247 RED 2 MÁSCARA : 255.255.248.0 RED : 139.100.8.0 *ELI: Elemento Lógico de Implementación Fig. 8. Topología de la red de área extensa FR/X25 Por último, también se han realizado las pruebas sobre la Red Digital de Servicios Integrados. Para ello, se configuraron dos encaminadores con la pila de protocolos RDSI en la línea, utilizándose una centralita RDSI interconectando ambos encaminadores. Las pruebas se han realizado con configuraciones de un único canal B (a 64 Kbps) y de dos canales B (a 128 Kbps). La topología es utilizada es la mostrada en la Fig. 9).
  • 15. NET 3 MASK: 255.255.255.0 NETWORK: 142.100.1.0 142.100.1.1 AUX ISDN 142.100.1.2 RAL 138.100.8.125 AUX ROUTER DCE ROUTER DTE 139.100.10.1 RAL HUB ..... CLIENTE_ELI S_AUTEN_ELI 138.100.10.248 139.100.10.248 RED 1 MÁSCARA : 255.255.248.0 RED : 138.100.8.0 SERVIDOR_ELI 139.100.10.247 RED 2 MÁSCARA : 255.255.248.0 RED : 139.100.8.0 *ELI: Elemento Lógico de Implementación Fig. 9. Topología de la red de área extensa RDSI Señalemos, por último, las características de los equipos en los que se ejecutó cada una de las entidades:  Entidad A: Pentium II a 450 Mhz, 128 Mbytes de RAM.  Entidad B: Dual Pentium II a 400 MHz, 384 Mbytes de RAM.  Entidad C: Pentium II a 400 Mhz, 128 Mbytes de RAM. A continuación se muestran los resultados de las pruebas. Cada tabla contiene las medidas de las tres especificaciones formales descritas anteriormente (P1, P2 y P3). Las unidades de tiempo son todas en segundos y representan el tiempo total de ejecución de los protocolos de seguridad y el envío de una cadena de prueba cifrada con la clave de sesión distribuida en cada caso. • PRUEBAS EN RAL (10-BASE-T) Longitud Claves RSA P1 P2 P3 512 bits 0.120 0.250 0.281 1024 bits 0.160 0.371 0.401 Tabla Resultados 1: Resultados obtenidos en RAL 2048 bits 0.641 1.472 0.852
  • 16. • PRUEBAS EN FRAME RELAY 1. FR 2 Mbps Longitud Claves RSA P1 P2 P3 512 bits 0.140 0.260 0.291 1024 bits 0.180 0.411 0.421 2048 bits 0.651 1.472 0.842 Tabla Resultados 2: Resultados obtenidos en FR 2Mbps 2. FR 64 Kbps Longitud Claves RSA P1 P2 P3 512 bits 0.280 0.451 0.381 1024 bits 0.330 0.631 0.521 2048 bits 0.851 1.803 0.972 Tabla Resultados 3: Resultados obtenidos en FR 64Kbps • PRUEBAS EN X.25 1. X.25 2 Mbps Longitud Claves RSA P1 P2 P3 512 bits 0.230 0.371 0.411 1024 bits 0.270 0.521 0.491 2048 bits 0.772 1.602 0.921 Tabla Resultados 4: Resultados obtenidos en X25 2Mbps 2. X.25 64 Kbps Longitud Claves RSA P1 P2 P3 512 bits 0.351 0.541 0.441 1024 bits 0.410 0.721 0.591 2048 bits 0.942 1.923 1.031 Tabla Resultados 5: Resultados obtenidos en X25 64 Kbps
  • 17. • PRUEBAS EN RDSI 1. RDSI 64 Kbps Longitud Claves RSA P1 P2 P3 512 bits 0.291 0.491 0.370 1024 bits 0.331 0.621 0.501 2048 bits 0.871 1.822 0.971 Tabla Resultados 6: Resultados obtenidos en RDSI 64 Kbps 2. RDSI 128 Kbps Longitud Claves RSA P1 P2 P3 512 bits 0.290 0.471 0.381 1024 bits 0.320 0.621 0.500 2048 bits 0.861 1.852 0.971 Tabla Resultados 7: Resultados obtenidos en RDSI 128 Kbps Los resultados obtenidos demuestran que nuestro Sistema de Implementación Automática de Protocolos de Seguridad (S.I.A.P.S) obtiene resultados aceptables a la hora de implementar servicios de seguridad para incorporar en agentes específicos. A modo de ejemplo, un sistema multi-agente formado por tres agentes (cliente, servidor e intermediario) que utilizase conexiones RDSI o Frame-Relay a 64Kbps y sistema operativo Windows NT necesitaría un tiempo estimado entre 0,5 y 0,6seg. en distribuir de forma segura una clave de sesión entre los agentes. Para ello, estaríamos considerando la implementación de un protocolo de seguridad de 5 intercambios con mecanismos de cifrado simetrico/asimetrico, mecanismos de sellos de tiempo y funciones aleatorias (especificaciones 2 y 3) en el que se distribuyen las claves de sesión utilizando cifrado de clave pública RSA con claves de una longitud de 1024 bits. 6 Conclusiones En este artículo realizamos una propuesta de Arquitectura Multi-agente segura basada en un nuevo concepto de interpretación automática de especificaciones formales de protocolos de seguridad. Nuestra arquitectura proporciona un sistema dinámico y abierto que permite ofrecer servicios de seguridad a cualquier aplicación distribuida. El comercio electrónico en Internet, aplicación emergente en la actualidad con la potencialidad de generar millones de transacciones en la red, será una de muchas aplicaciones beneficiaria de nuestro sistema. Una de sus recientes variantes el denominado comercio electrónico móvil (m-commerce), desarrollado desde redes de Telecomunicaciones Móviles basa, precisamente, uno de los aspectos críticos del éxito
  • 18. del servicio en el nivel de seguridad ofrecido al usuario. La combinación de la tecnología orientada a objetos, la interpretación automática de especificaciones de protocolos y la incorporación dinámica de mecanismos de cifrado simétrico y asimétrico son los pilares de la infraestructura de nuestro sistema. 7. Referencias 1. Merwe, J., Solms, S.H. “Electronic commerce with secure intelligent trade Agents”. Computers and security. Vol.17, Nº5, pp435-446, 1998. 2. Bradshaw, J. M. (Ed.) (1997), Software Agents, Boston: MIT Press. 3. Genesereth, M.R. & Ketchpel, S.P. Software agents. Communications of the ACM 37(7) (1994) 48–53. 4. Gomez, R. “Agentes Móviles y CORBA”. http://www.fie.us.es/ ~ramon/tesis/CORBA/Seminario-MASIF/. 5. Li, J.L. “Mobile Agents and Security” Computer Communications, Volume 22, Issues 15-16, 25 September 1999, Pages 1526-1527. 6. Greenberg, M.S., Byington, J. C., Harper, D.G. “Mobile agents and security”, IEEE Communications Magazine, Volume 36, Issue 7, July 1998, Pages 76-85. 7. Jansen, W. A. “Countermeasures for mobile agent security”, Computer Communications, volume 23, Issue. 17, 1 November 2000, Pages 1667-1676. 8. Knowledge Query Management Language (KQML) (AgentWeb, Universidad de Maryland en Baltimore): http://www.cs.umbc.edu/kqml/ 9. Finin, T. & Labrou, Y. (1997), “KQML as an Agent Communication Language”, In Software Agents. Bradshaw, J.M. (ed.), MIT Press, Cambridge, MA, pp. 291316, 1997. 10. Foner, L. & Crabtree, I. B. (1997), “Multi-Agent Matchmaking”, in Nwana, H. S. & Azarmi, N. (Eds.),Software Agents and Soft Computing: Concepts and Applications, Heidelberg: Springer-Verlag, 100-115. 11. Romao, A., Da Silva, M., Silva, A. “Secure electronic payments based on mobile agents”, Distributed and Parallel Databases, Volume 8, Issue 4, October 2000, Pages 447-470 12. Papastavrou, S., Samaras, G., Pitoura, E. “Mobile agents for World Wide Web distributed database access” IEEE Transactions on Knowledge and Data Engineering, Volume 12, Issue 5, September 2000, Pages 802-823. 13. A Quick Tour Of the CORBA Security Service. http://www.itsecurity.com/corba/ corbasec.htm. 14. JavaBeans (security). http://www.utcluj.ro/doc/PJB/html/ch15.htm 15. COM (security). http://www.microsoft.com/security/default.asp 16. Mengual Galán, L. “Un modelo formal para la especificación, analisis, verificación e implementación de protocolos de seguridad.” Tesis Doctoral. Facultad de Informática. Universidad Politécnica de Madrid. Julio 1998 17. Departament of Defense, Trusted Computer System Evaluation Criteria, DOD 5200.28-STD, December 1985. 18. Information Technology Security Evaluation Criteria. Harmonized Criteria 1991.
  • 19. 19. Trcek D. “Security policy conceptual modeling and formalization for networked information systems.” Computers Comunications, Vol. 23, Nº 17, 2000. 20. Cohen, F. “Simulating Cyber Attacks, references and Consequences.” Computers & Security, Vol. 18, Nº 6, 1999. 21. Soh, B.C,, and Dillon, T.S. “System Intrusion Process: a simulated model.” Computers & Security, Vol. 16, Nº 1, 1997. 22. Khoussainov, R. and Patel, A. “LAN security: problems and solutions for Ethernet networks.” Computers Standars & Interfaces, Vol. 22, Nº 3, August 2000. 23. Mengual, L., Barcia, N., Fernández, C., Morant, F., Yagüez, J. “A Model To Specify Security Protocols On The Isdn” Journal Of Applied Computer Science. Technical University Press Vol. 7, Nº2, 1999. 24. Yagüez, J., Morant, F., Mengual, L., Barcia, N., López, G. “An Innovative Distributed Identity Delegation”. Journal Of Applied Computer Science. Technical University Press 17-3-2000. 25. Lampard, R. “Formal Description Techniques in Data Security: An Evaluation and Comparison.” National Physical Lab., Teddington, England Div. of Information Technology and Computing, 1991, 59pp, PB91-229484/WCC. 26. Leduc, G., Germeau, F. “Verification of security protocols using LOTOS-method aplication.” Computer Communication, Vol. 23, Nº 12, July 2000. 27. “Formal Description Techniques and Security Standard Conformance Testing.” National Physical Lab., Teddington, England Div. of Information Technology and Computing, 1991, 34pp, PB91-229542/WCC. 28. Gervais, M.P., Diagne, A. “Enhancing telecommunications service engineering with mobile agent technology and formal methods” IEEE Communications Magazine, Volume 36, Issue 7, July 1998, Pages 38-43. 29. Puliafito, A. and Tomarchio, O. “Using mobile agents to implement flexible network management strategies” Computer Communications, Volume 23, Issue 8, 1 April 2000, Pages 708-719. 30. Ashley P., Vandenwauver M., Siebenlist F. “Applying authorization to intranets: architectures, issues and APIs”. Computers Comunications, Vol. 23, Nº 17, November 2000. 31. Zhou J. “Further analysis of the Internet key exchange protocol”. Computer Communication, Vol. 23, Nº 17, November 2000. 32. Pieprzyk, J., Li, C.-H. “Multiparty key agreement protocols” IEE Proceedings: Computers and Digital Techniques, Volume 147, Issue 4, July 2000, Pages 229236. 33. ftp://ftp.ox.ac.uk/pub/crypto/misc/ 34. http://www.eskimo.com/~weidai/cryptlib.html