Tesis Doctoral, Un Enfoque en La Protección de Sistemas De, Dr. Antonio Muñoz Gallego
Tesis Doctoral, Un Enfoque en La Protección de Sistemas De, Dr. Antonio Muñoz Gallego
Presentada por
Antonio Muñoz Gallego
Para optar al grado de
Doctor Ingeniero en Informatica
Dirigida por
Dr. Antonio Maña Gómez
Profesor Titular de Universidad
En primer lugar agradezco a mi director de tesis y amigo Antonio todo su apoyo y guía
que considero que, sin duda, han sido fundamentales para todos estos años de trabajo.
Agradezco a Marioli ese apoyo tan cómplice e incondicional para todo lo que ha impli-
cado la evolución de todas y cada una de las etapas de esta tesis. A Domy porque siempre
ha representado mi mano derecha y evidentemente durante todos estos años no me ha
defraudado en ningún momento. A Nacho que me ha servido de brújula para no perder
el norte. A Marian que siempre ha sabido llevarnos a todos al plano terrenal y en mi caso
especialmente. Por su puesto a mi padre que gracias a él me enorgullezco de ser quien
soy y quien, sin ser del todo consciente de ello, me hizo firmar el contrato de compromiso
esta tesis. Agradezco a mis abuelas Ascensión y Eulogia, ya que sin su ayuda no habría
podido tener la oportunidad de estar escribiendo estas líneas.
Agradezco también al resto de mis familiares que con paciencia han comprendido todo
este tiempo empleado. Quiero dar las gracias a mis amigos Salva, Javi, Monte, Onieva,
Sergio, Iván, Esther, Nati, Espe, Belén, Arantxa, Dani, Fran, Seba, Carlos, José María,
Gustavo y a los que me dejo en el tintero. Asimismo a mis compañeros de laboratorio,
en especial a Pablo, Jose, Andrés y Hristo por ese aliento continuo en el camino y los
apretones de última hora.
Para finalizar quiero hacer mención a todos los que han contribuido en el desarrollo
de este trabajo que de cualquier forma han contribuido a que por fin vea la luz.
Resumen
Los agentes móviles son entidades software que tienen la habilidad de migrar entre no-
dos dentro de una red, actuando de forma autónoma y en cooperación con otros agentes
con el objetivo de realizar una serie de tareas. Actualmente existen diferentes aplicaciones
basadas en agentes en numerosos entornos de computación tales como redes peer-to-peer,
web crawlers, etc. Los sistemas multiagentes, MAS (Multi-Agent Systems) representan
una propuesta arquitectural muy prometedora para la construcción de aplicaciones basa-
das en Internet y distribuidas.
A pesar de la atención prestada, por parte de la comunidad investigadora, a este
campo no ha habido una aceptación evidente, de hecho, únicamente se ha aplicado en
un número reducido de escenarios del mundo real. En este trabajo hemos llegado a la
conclusión de que los aspectos de seguridad juegan un papel vital para el desarrollo de
este paradigma. Un hecho que lo evidencia es que el principal problema a resolver antes
de que la tecnología basada en agentes esté lista para ser usada de forma habitual fuera
de la comunidad investigadora es la falta de mecanismos de seguridad apropiados. Para
conseguir un nivel de seguridad apropiado, en el contexto de los sistemas multiagentes, no
es suficiente que la plataforma de agentes ofrezca un conjunto de mecanismos de seguridad
estándares tales como son los sandboxing, o mecanismos de cifrado y firma digital, sino que
es necesario, diseñar la infraestructura considerando los aspectos de la seguridad desde las
primeras etapas del diseño hasta la últimas de la implementación. Además, la seguridad
de una plataforma de agentes necesita ser adaptada a las características específicas de
estos sistemas.
En esta tesis doctoral partimos de una base de estudio de las tecnologías actuales
que pueden usarse para construir sistemas de agentes seguros. Pero debemos advertir que
este estudio nos ha servido para concluir que ninguno es suficientemente completo, puesto
que los mecanismos existentes hasta el momento se centran o bien en la protección de la
agencia o bien en la protección del agente. Esto se debe en gran medida a que la mayoría
de las soluciones que se usan para la protección de los agentes no está diseñada para
este modelo computacional, sino que suelen ser adaptaciones de otros mecanismos usados
para la protección general del software. También queremos resaltar el hecho de que la
aplicación de las técnicas actuales para la protección de los sistemas basados en agentes
implica ciertos conocimientos en materia de seguridad que no resultan triviales. De hecho
hemos comprobado que una de las causas de que no se apliquen técnicas de seguridad en
este ámbito es la dificultad que presentan en su aplicación este tipo de prácticas.
En esta tesis presentamos dos soluciones para la protección de sistemas basados en
agentes claramente diferenciadas. Aunque, como describimos en el capítulo de conclu-
siones, también son complementarias. La primera de las técnicas se basa en el uso de
hardware criptográfico para la protección de los agentes. Hemos diseñado un protocolo
de migración segura específico para un hardware determinado Trusted Platform Module
(TPM). No obstante, esta técnica se puede aplicar a cualquier otro tipo de hardware con
características similares, como es el caso de las tarjetas inteligentes. La segunda de las
técnicas diseñadas hace uso del paradigma conocido como “computación protegida”. Este
se basa en la partición del código de los agentes y en realizar una repartición entre las
partes de código obtenidas. Como vemos en transcurso de esta tesis hemos desarrollado
herramientas de ayuda para la aplicación de esta técnica a sistemas de agentes reales, de
forma sencilla y automática. Hemos incluido un capítulo para las conclusiones y los traba-
jos futuros, ya que consideramos de gran interés continuar con esta línea de investigación,
que creemos que tiene un futuro muy prometedor. Hemos añadido un apéndice en el que
se incluye una traducción, en inglés, de la introducción de la tesis junto con un resumen,
en inglés, del contenido global de la tesis. Y por último hemos añadido un apéndice con
la metodología seguida para el desarrollo de esta tesis.
Índice general
1 Introducción 11
1.1 Acerca de la tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2 Motivación y objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3 Publicaciones que avalan esta tesis . . . . . . . . . . . . . . . . . . . . . . 12
1.3.1 Publicaciones relacionadas con la solución basada en el uso de TPM 13
1.3.2 Publicaciones relacionadas con la solución basada en la computación
protegida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3.3 Publicaciones relacionadas con trabajos futuros . . . . . . . . . . . 16
7
3.2.2 El atacante dispone de una agencia pero esta no es confiable. . . . . 82
3.2.3 El atacante conoce un destino adecuado . . . . . . . . . . . . . . . 82
3.2.4 El atacante dispone de una agencia confiable y con su TPM funcio-
nando correctamente, además de disponer de otra agencia manipulada. 82
3.3 Evaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.3.1 Validación de los protocolos con AVISPA . . . . . . . . . . . . . . . 86
3.4 Aplicación en sistemas reales . . . . . . . . . . . . . . . . . . . . . . . . . . 93
3.5 Conclusiones y futuras mejoras . . . . . . . . . . . . . . . . . . . . . . . . 95
Bibliografía 191
Capítulo 1
Introducción
11
Introducción
A pesar del interés prestado a este campo, por parte de la comunidad investigadora,
su aceptación no ha tenido un impacto tan relevante como parecía esperar. Únicamente
se ha aplicado en un número bastante reducido de escenarios del mundo real. Pensamos
que este hecho se debe a que los aspectos de seguridad juegan un papel crucial en el
desarrollo de sistemas multi-agentes y se considerada uno de los principales problemas a
resolver antes de que esta tecnología esté totalmente preparada para ser usada de una
forma habitual, en especial en entornos empresariales.
No obstante, para conseguir los mecanismos de seguridad apropiados para los sistemas
basados en agentes, no basta únicamente con que la plataforma de agentes proporcione
un conjunto de mecanismos y técnicas de seguridad estándares como los sandboxing o
ciertos mecanismos de cifrado y de firma digital. En nuestro trabajo partimos de la base
de que es necesario que durante todas las fases de la vida del software se tengan en
consideración los aspectos de seguridad. En efecto, como muchos autores han mostrado
la idea de considerar la seguridad como un elemento añadido ha quedado obsoleta. Otro
aspecto a resaltar es el hecho de que la seguridad de un sistema basado en agentes necesita
ser diseñada conforme a las características específicas de estos sistemas y de las tecnologías
que se usan para construirlas. Especialmente relevante es el caso de la movilidad.
Los principales objetivos de este trabajo de tesis son:
El estudio de los puntos débiles de la seguridad de los sistemas basados en agentes,
tanto a nivel de agente como de la plataforma en la que este se ejecuta.
Un análisis de los diferentes mecanismos que existen hasta el momento para pro-
porcionar seguridad a los sistemas basados en agentes. La evaluación de los mismos
tendrá en cuenta tanto aspectos de seguridad como de usabilidad, los cuales resultan
vitales para la aceptación práctica de las soluciones.
El tercer objetivo consiste en el diseño de una solución que proporcione a los desa-
rrolladores de sistemas de agentes los medios necesarios para la construcción de
sistemas seguros, así como su implementación, junto con las herramientas necesa-
rias para facilitar, en la medida de lo posible, la tarea al usuario final.
El último de los objetivos es la validación de nuestra solución. Esto se llevará a cabo
mediante el análisis de la utilización de nuestra solución y las herramientas de ayuda
asociadas aplicados en sistemas reales basados en agentes.
Hemos de resaltar el hecho de que inicialmente nuestro tercer objetivo era el diseño
de una única solución, sin embargo durante el diseño de la misma se nos planteaba el
dilema de decantarnos por una solución basada únicamente en elementos software o por
el contrario hacer uso de algún tipo de dispositivo de seguridad. Por todo esto decidimos
no elegir entre una y otra opción sino que continuamos el estudio de ambas soluciones en
paralelo.
tions”. ISSN 0972-9038. Así como el trabajo titulado, “TPM-based Protection for Mobile
Agents”, que tiene como autores a Antonio Muñoz y a Antonio Maña Gomez. Aceptado
para publicarse en el “Security and Communication Networks”. Estas publicaciones des-
criben los conceptos básicos de la protección de los sistemas de agentes que hacen uso de
elementos hardware específicos para ello. Estas publicaiones están orientadas en mostrar
un mecanismo para reforzar el proceso de migración obteniendo una migración segura.
En la primera parte del capítulo 3 se describen los resultados obtenidos en este trabajo.
En cambio, el segundo trabajo es una evolución del anteriormente comentado, aunque
en este caso se centra en las posibles mejoras aplicables a este método de migración a
distintos niveles. En primer lugar se estudian las diferentes alternativas a otros protocolos
existentes, como es el caso del protocolo de atestación anónima directa que consideramos
de especial interés para ciertos casos. Además se realiza un proceso de validación y se
diseña un nuevo protocolo basado en el uso de una clave ligada al estado del sistema, que
es la mayor aportación práctica de esta solución basada en hardware. En el capítulo 3
mostramos los resultados obtenidos en esta publicación.
Asimismo hemos introducido en esta sección dos capítulos de libros de bastante impor-
tancia. El primero de ellos se titula “Model Cheking Ambient Intelligence with AVISPA”,
dentro del libro “Ambient Intelligent Perspectives”, los autores de este han sido Antonio
Muñoz, Antonio Maña y Daniel Serrano. Ha sido publicado en el IO Press y editado por
Peter Mikuleck, Tereza Liskov, Pavel Cech y Vladimir Bures en el 2009. ISSN 1875-4163.
ISBN 978-1-58603-946-2. En este se describen una serie de mecanismos para modelar so-
luciones de seguridad específicos para ambientes inteligentes, para su posterior validación
mediante unas herramientas de model-checking. Lo particularmente interesante de esta
aportación es que proporciona ciertas herramientas para el modelado de soluciones de
seguridad particulares de ambientes inteligentes. Al igual que el capítulo titulado “Verifi-
cation of S&D solutions for workflows, network communications and devices”, con Carsten
Rudolph, Luca Compagna, Antonio Muñoz, y Jurgen Repp como autores. Este capítulo
forma parte del libro “Security and Dependability for Ambient Intelligence”, editado por
Dr. Georgios Spanoudakis, Antonio Maña y Christos Kokolakis, publicado en Junio de
2009 por el Information Security Series, Springer, ISBN-978-0-387-88775-3. Son aporta-
ciones de especial interés puesto que nos han proporcionado los medios necesarios para
poder elaborar una validación formal del protocolo que usamos como base de nuestra
solución a lo largo de la investigación. Permitiéndonos la identificación de las debilidades
presentes en el mismo.
el trabajo de esta tesis, y en particular del capítulo 4. En este artículo se plantea el uso del
Protected Computing como una alternativa al uso del Trusted Computing. En la presente
tesis doctoral planteamos un paralelismo de dos soluciones para la protección de agen-
tes, precisamente una basada en la primera de las propuestas planteadas en este artículo
(Protected Computing) y la otra basada en la segunda (Trusted Computing). En ella se
plantean las ventajas e inconvenientes de cada una de las tecnologías propuestas.
Al igual que la publicación previa esta ha sido esencial para el desarrollo de la investi-
gación de toda la tesis y en ella se plantea la organización de la misma en los dos grandes
bloques, la solución basada en hardware y la solución basada en software. A continuación
y en el mismo año el trabajo con nombre “Mutual Protection for Multiagent Systems”,
realizado por Antonio Maña y Antonio Muñoz. Proceedings of the Third International
Workshop on Safety and Security in Multiagent Systems (SASEMAS ’06), como parte del
AAMAS. En este artículo presentamos la primera propuesta, a alto nivel, de la aplicación
de la computación protegida para la protección de agentes. Las aportaciones que obtuvi-
mos en este congreso nos fueron de gran utilidad, ya que el AAMAS representa el congreso
internacional más importante dentro del ámbito de los agentes. Además de disponer de
una sesión específica para los aspectos de seguridad, sin lugar a dudas, representó un
avance cualitativo para el desarrollo de este trabajo. Por último en este año se publicó “A
Secure and Auto-configurable Environment for Mobile Agents in Ubiquitous Computing
Scenarios”, los autores fueron Javier Lopez, Antonio Maña y Antonio Muñoz, en el Third
International Conference Ubiquitous Intelligence and Computing, en las páginas 977-987,
LNCS 4159, Springer, Wuhan, China, Septiembre de 2006.
En el año siguiente se publicó el trabajo “Towards Secure Agent Computing for Ubiqui-
tous Computing and Ambient Intelligence”, realizado por Antonio Maña, Antonio Muñoz
y Daniel Serrano. En la cuarta conferencia internacional de Ubiquitous Intelligence and
Computing. Los datos específicos de esta publicación son ISSN 0302-9743. ISBN 978-3-
540-73548-9. LNCS, Springer Verlag. Este congreso tuvo lugar en Hong Kong (China) en
el 2007. En este artículo planteamos a un nivel bastante abstracto una solución basada
en el uso de smartprot, en este trabajo hacíamos la primera distinción entre una versión
académica diseñada para un número fijo de agentes dentro de un sistema y otra dinámica,
con un mayor grado de complicación.
En el mismo año y en esta misma línea, pero desde otra perspectiva distinta hicimos
el trabajo “Trusted Code Execution in JavaCard”, Antonio Maña y Antonio Muñoz. Este
trabajo se publicó en los proceedings Springer-Verlag, LNCS. Dentro de la conferencia
Trustbus en el 2007, que tuvo lugar en Regensburg (Alemania). Hemos de resaltar la
relevancia de este congreso, que representa uno de los más importantes internacionalmente
dentro del ámbito de la seguridad. En este artículo se propone una mejora a la ejecución
del código en Javacard. Esta tecnología está descrita en el capítulo , así como su aplicación
como alternativa a los resultados de la aplicación de las técnicas de trusted computing se
discuten en el capítulo 3.
Tras una etapa de maduración, en el 2009 se publicaron dos trabajos de gran impacto.
El primero de ellos titulado “SecMiLiA: An Approach in the Agent Protection”, realizado
por Antonio Muñoz, Antonio Maña y Daniel Serrano. Trabajo que fue publicado en el
proceedings de la cuarta conferencia internacional de Availability, Reliability and Security
ARES 2009, esta conferencia tuvo lugar entre los días 16-19 de marzo en Fukuoka en el
A lo largo de este capítulo vamos a hacer un repaso sobre los antecedentes y los trabajos
previos más influyentes para el desarrollo de la presente tesis. El objetivo principal de este
capítulo no es otro que el de situar al lector en el problema que nos planteamos al comienzo
de esta tesis. Para ello vamos a describir en profundidad lo que entendemos por agente
móvil, puesto que es el elemento sobre el que hemos centrado todo nuestro trabajo, para
ello vamos a describir sus características más importantes, los diferentes tipos existentes,
la definición de sistemas multiagentes, etc. A continuación mostramos las tecnologías para
trabajar con agentes que actualmente tienen un mayor impacto en la comunidad, como es
el estándar FIPA y el framework JADE. También vamos a dar un repaso por los trabajos
que hasta el momento se han hecho para la protección de los sistemas de agentes. Hemos
organizado este tipo de mecanismos de protección en dos grupos bien definidos, el primero
de ellos es el que engloba a las soluciones que protegen a los agentes frente a la agencia y
el segundo contiene a las soluciones que tratan de proteger a las agencias de los posibles
ataques por parte de los agentes. Y por último vamos a hacer una descripción de las
tecnologías de base para el desarrollo del trabajo de esta tesis.
Antes de comenzar una descripción detallada de los antecedentes y los trabajos pre-
vios en la protección de los agentes móviles y las plataformas de los mismos, debemos
puntualizar el hecho de que existen dos concepciones distintas de agentes móviles. Por un
lado nos encontramos con la asumida en el área de la Inteligencia Artificial que se centra
en la capacidad de decisión y de razonamiento, en la autonomía y ciertos aspectos de los
agentes, y por otra parte nos encontramos la que está más relacionada con la Ingeniería
del Software, que muestra a los agentes como un modelo para construir sistemas software.
Es en torno a esta última concepción en la que centramos todo nuestro trabajo.
17
Antecedentes y Trabajos Previos
vista de la transmisión de datos, el concepto del agente siempre resulta conveniente en los
casos en los que se procesan datos remotos, el programa es mucho menor que los mismos,
o las características del almacenamiento de esos datos hacen inconveniente su transmisión
(por razones de tamaño, seguridad, etc). Evidentemente en aplicaciones tales como las
de comercio electrónico en las que se gestiona dinero, la confianza de los usuarios es un
prerrequisito para su uso. Este caso nos revela la importancia real de la seguridad en los
agentes móviles y el porqué se han invertido tantos esfuerzos para conseguir soluciones
de seguridad apropiadas. El gran número de trabajos que se encuentran en la literatura
científica relacionada con la seguridad de los agentes móviles evidencia la importancia del
tema.
Una de las características más valoradas de los agentes móviles es precisamente su
movilidad, que les permite viajar de manera autónoma a través de la red. Sin embargo, esta
es precisamente la propiedad que les hace más vulnerables a diferentes tipos de ataques.
A continuación vamos a presentar estos ataques, junto con los que puedan realizar los
agentes para atacar a las plataformas.
Accesos no autorizados. Los agentes móviles pueden intentar acceder a servicios
y/o recursos de una plataforma sin los permisos adecuados. Para contrarrestar este
tipo de ataque, una plataforma de agente móvil ha de disponer de una política de
seguridad para especificar las reglas de acceso para varios agentes, así como de un
mecanismo para hacer cumplir las políticas.
Suplantación de identidad. En este tipo de ataques un agente con carácter malicioso
asume la identidad de otro agente con idea de obtener acceso a los recursos y servicios
de la plataforma, o simplemente para causar algún tipo de daño. Asimismo, una
plataforma puede suplantar la identidad de otra plataforma para obtener acceso a
los datos del agente móvil. En ambos casos, el objetivo del ataque es que el agente o
la plataforma cuya identidad fue mal usada asuma la responsabilidad de los daños
[20].
Denegación de servicio. Una plataforma con carácter malicioso puede causar daño
a un agente visitante simplemente ignorando las peticiones de servicios y recursos
del mismo, aunque estén disponibles en la plataforma. También puede causar daños
forzando la terminación de la ejecución del agente sin notificación alguna, e incluso
asignándole tareas de forma continua de manera que este nunca llegue a conseguir
su objetivo. Asimismo, un agente malicioso puede causar daños consumiendo más
recursos de los necesarios de la plataforma, como pueden ser el espacio de disco o el
consumo de CPU. También podría alterar o eliminar información, pudiendo causar
daños serios a la plataforma y perpetrando un ataque de denegación de servicio
contra otros agentes visitantes [20].
Escucha no autorizada. En este caso una plataforma con carácter malicioso puede
monitorizar el comportamiento o las comunicaciones de un agente móvil con idea
de extraer información sensible del mismo. Esto se usa normalmente con el código
y los datos del agente cifrados. La monitorización puede revelar la identidad de las
entidades con que se comunica el agente móvil, y los tipos de servicios requeridos
por el agente móvil [20].
agente surgió en el campo de la robótica en el que los agentes físicos son entidades inde-
pendientes que perciben el mundo que les rodea a través de sus sensores y que interactúan
con él mediante el uso de actuadores.
El término “agente” describe una abstracción de un elemento software, y comparte
algunas similitudes con los objetos en la programación orientada a objetos, la principal
diferencia se encuentra en los aspectos de autonomía y movilidad. El concepto de agente
nos proporciona una forma conveniente y poderosa de describir una entidad de software
compleja capaz de actuar con cierto grado de autonomía para cumplir tareas en represen-
tación de personas u otras entidades.
Un agente no es un programa tradicional, ya que es capaz de reaccionar al entorno
y tiene autonomía y persistencia. En la programación tradicional se han desarrollado
programas con una rutina preestablecida, sin capacidad de decisión puesto que se basaban
en ciertos elementos esenciales, como eran los bucles y los saltos para desarrollar el flujo
del programa. Sin embargo, con la tecnología de agentes se abren las puertas a un nuevo
modelo capaz de reaccionar frente a cambios en el entorno y con el grado suficiente de
autonomía para tomar decisiones conforme al comportamiento propio y a estos cambios.
No debemos concebir a un agente como un objeto, de hecho, en la concepción del
mundo como objetos existe el concepto de encapsulación. En cambio, el concepto de agente
representa una entidad que es más autónoma, que como mencionábamos anteriormente
tiene capacidad de decisión. Obviamente esta capacidad de decisión junto con la capacidad
de reaccionar al entorno hace de los agentes una tecnología mucho más flexible que los
objetos, hecho que se evidencia con la capacidad de reactividad propia de los agentes
sumada a su capacidad de actuar socialmente con otros agentes.
Por último hemos de afirmar el hecho de que un agente no es un sistema experto,
porque los sistemas expertos no se adaptan a su entorno, es decir, los sistemas expertos
adquieren una gran cantidad de conocimiento experto mediante una adquisición de la
información similar a un método de aprendizaje, en cambio, no están diseñados para
tener comportamientos reactivos ni proactivos, así como tampoco tienen habilidad social,
que es lo que realmente los diferencia de los agentes.
2.2.1. Características
El paradigma de la programación orientada a agentes móviles aporta una serie de
ventajas e inconvenientes debido a la naturaleza del mismo. Esta naturaleza viene dada
por una serie de características. A saber:
Autonomía, esta característica permite a los agentes actuar sin ningún tipo de in-
tervención humana directa y tener control sobre sus propios actos.
Sociabilidad, los agentes tienen capacidad para interaccionar con otros agentes hu-
manos o no, a través de algún tipo de lenguaje de comunicación.
Iniciativa, un agente inteligente debe tener la capacidad para ejecutar tareas para
conseguir su objetivo, separada de la propia del usuario. Los problemas que motiva-
ron la aparición del concepto de agente son aquellos en los que el agente puede llegar
a saber más que el usuario sobre una materia y/o sobre las estrategias a utilizar para
resolver el problema.
Racionalidad, un agente siempre actúa de forma racional con miras a cumplir sus
objetivos.
Agentes móviles, que se desplazan de una ubicación a otra durante su ciclo vital.
Por otro lado, podemos realizar una clasificación de los agentes atendiendo a sus carac-
terísticas que describíamos previamente. Usando estas características podemos clasificar
los agentes en cuatro clases:
Agentes cooperativos con capacidad de aprendizaje. Son agentes que colaboran entre
sí pero con cierta autonomía dada por su capacidad de aprendizaje.
De esta última clasificación cabe destacar que las categorías no son excluyentes, es
decir, un agente puede pertenecer en mayor o menor medida a una o varias categorías.
Esta clasificación es conocida con el nombre Nwana. Por ser la más precisa y extendida
hemos dedicado especial atención a la descripción de la misma.
La clasificación de Nwana
En la figura 2.1 podemos ver una clasificación de los agentes propuesta por Hyacinth
S. Nwana [21], según la cual existen siete tipos de agentes; agentes cooperativos, agentes
de interfaz, agentes móviles, agentes informativos (conocidos como de Interenet), agentes
reactivos, agentes híbridos y agentes inteligentes.
Estos agentes pueden coexistir en sistemas de agentes homogéneos, formados por agen-
tes de características similares o heterogéneos en los que hay agentes de diversos tipos.
También es necesario destacar que los agentes pueden competir entre ellos, ya que sus
intereses pueden no coincidir. Este último aspecto es muy importante y es necesario te-
nerlo en cuenta a la hora de diseñar un sistema multiagente, ya que es posible que agentes
antagónicos puedan actuar de forma maliciosa entre sí. A continuación vamos a analizar
más detalladamente cada uno de los tipos de agentes propuestos por la clasificación de
Nwana.
Agentes cooperativos
El aspecto más importante de este tipo de agentes es, sin duda, la cooperación con
otros agentes. Por ello, los agentes cooperativos se usan para enfrentar diversos problemas
que resultan demasiado extensos para ser resueltos por un agente centralizado, ya sea
por la escasez de recursos o por el riesgo que ello pueda conllevar. También resultan
de gran utilidad para la resolución de otros problemas que hacen uso de fuentes de datos
distribuidas, para sistemas que hacen uso de sistemas expertos distribuidos, para sistemas
que requieren modularidad son bastante adecuados sobre todo mejorando parámetros
de velocidad (haciendo uso del paralelismo), confiabilidad (gracias a la redundancia),
flexibilidad y reusabilidad del conocimiento (mediante la compartición de recursos). Sin
embargo, el diseño de sistemas basados en agentes cooperativos implica una serie de
dificultades: la coordinación entre agentes es esencial en este tipo de sistemas, ya que
permite la resolución de un gran número de problemas.
Un diseño erróneo de la coordinación puede derivar en problemas de anarquía e in-
terbloqueos. Por otro lado, es necesario establecer si los agentes negocian entre ellos de
manera confiable o si pueden engañarse. Además, la coordinación es necesaria desde el
punto de vista de las restricciones de recursos y tiempo. También pueden surgir proble-
mas de estabilidad, escalabilidad y rendimiento, además de los problemas de validación
de los sistemas de agentes. Es necesario desarrollar una técnica de verificación y evalua-
ción de sistemas de agentes para determinar si cumplen sus especificaciones y administran
Agentes de interfaz
Las características esenciales de los agentes de interfaz son la autonomía y el aprendi-
zaje. Estos agentes colaboran con el usuario. Por lo que no requiere el uso de un lenguaje
específico, como en el caso de colaboración entre agentes. Los agentes de interfaz se usan
normalmente para ayudar al usuario en el aprendizaje, ya sea en el uso de un sistema
operativo, hoja de cálculo u otra aplicación. Este aprendizaje lo lleva a cabo el agente de
cuatro maneras posibles. Observando e imitando al usuario, a través de la respuesta del
usuario, a través de instrucciones específicas del usuario y preguntando a otros agentes.
El objetivo del uso de sistemas de agentes de interfaz es pasar de una comunicación uni-
direccional, en la que el usuario ordena a la máquina que lleve a cabo una serie de tareas,
a una comunicación bidireccional, en la que hombre y máquina colaboran, lo cual permite
que el sistema pueda llevar a cabo las tareas tediosas permitiendo ahorrar horas de tra-
bajo al usuario. El diseño de sistemas basados en agentes de interfaz conlleva una serie de
problemas, entre los que destacamos el hecho de demostrar que el conocimiento adquirido
por los agentes pueden realmente ayudar a reducir la carga de trabajo del usuario y el
determinar qué técnicas de aprendizaje son más adecuadas para qué dominios y por qué.
Agentes móviles
Los agentes móviles son procesos software capaces de desplazarse dentro de redes
de área amplia (Wide Area Networks, WAN), como Internet, interactuando con hosts
remotos, recogiendo información para el usuario y retornando al lugar de origen habiendo
llevado a cabo las tareas solicitadas por el usuario. Todas estas características pueden
habilitar la reducción de los costes de comunicación, el uso de recursos locales bastante
escasos, la coordinación sencilla, etc. El agente lleva a cabo varias tareas, aunque debido a
la computación asíncrona, sólo será necesario coordinar al propio agente, no a las múltiples
tareas que realiza de manera independiente . Sin embargo, el diseño de sistemas basados en
agentes móviles conlleva una serie de problemas, entre los que destacamos el del transporte,
ya que es necesario determinar cómo realiza el agente la transferencia de un host a otro,
cómo empaqueta su información para poder trasladarla consigo, etc. También hemos de
considerar el problema de la seguridad, ya que es necesario evitar que los agentes puedan
infectar los sistemas con virus o incluso actuar ellos mismos de manera maliciosa. La
seguridad engloba tanto a la autenticación del agente para establecer mecanismos que
permitan, determinar su identidad, a quién representan y si está libre de virus, como
a la privacidad, basado en asegurar que los agentes no vulneren las leyes de privacidad
establecidas.
Agentes reactivos
Los agentes reactivos representan una categoría especial de agentes que no poseen un
modelado simbólico de su entorno. En su lugar, actúan respondiendo a estímulos que reci-
ben del entorno en el que se encuentran. El punto clave de los agentes reactivos es que no
poseen una especificación, a priori, de su comportamiento. Pueden verse como una colec-
ción de módulos independientes que actúan de manera autónoma y son responsables de
tareas determinadas. La comunicación entre estos módulos es mínima y de bajo nivel, por
lo que no existe un modelo global del sistema. Por otra parte, los agentes reactivos tienden
a operar como si se tratasen de sensores, usando una representación de los datos similar a
la de éstos en contra de lo que hacen otros tipos de agentes, que usan una representación
simbólica de alto nivel. La hipótesis clave sobre la cual gira la idea de los agentes reactivos
es que puede desarrollarse un sistema inteligente mediante agentes simples que no tengan
modelos simbólicos internos y cuya inteligencia se base en el comportamiento derivado
de la interacción entre los módulos que lo forman. Un beneficio derivado del desarrollo
de sistemas de agentes reactivos es que deberían ser más robustos y tolerantes a fallos
que otros sistemas de agentes. Por otro lado los sistemas obtenidos son más flexibles y
adaptables. El diseño de sistemas de agentes reactivos conlleva una serie de problemas: el
reducido rango de aplicaciones basadas en agentes reactivos, la metodología de desarrollo
para este tipo de sistemas no está claramente definida y la existencia de una serie de
problemas no funcionales que deben ser resueltos, como la escalabilidad y el rendimiento.
Agentes híbridos
Un agente híbrido es aquel que reúne características de varios de los diferentes tipos de
agentes. El desarrollo de sistemas basados en este tipo de agentes suele implicar un diseño
específico para una aplicación concreta sin una base determinada, con los problemas que
ello conlleva.
Esta clasificación tan detallada de todos los tipos de agentes software abre las puertas a
un gran número de posibles aplicaciones de esta tecnología en diversos tipos de escenarios,
y más aún si consideramos el caso de los sistemas de agentes híbridos, en los que contamos
con un elevado número de posibles combinaciones.
2.3.1. Definición
2.3.2. Clasificación
Los sistemas multiagente pueden ser homogéneos o heterogéneos. Los primeros están
compuestos por agentes de un solo tipo, y como cabe esperar los segundos se componen
de diferentes tipos de agentes. Mientras que los sistemas homogéneos están pensados para
desarrollar aplicaciones específicas determinadas por el tipo de agentes que componen el
sistema, los sistemas heterogéneos tienen un propósito más amplio proporcionando una
serie de beneficios con respecto a los homogéneos. Permiten desarrollar aplicaciones que
proporcionen servicios de valor añadido basadas en los diferentes sistemas que cooperan,
y sirven para solucionar problemas que surgen al usar sistemas antiguos y al interoperar
con estos mediante el uso de agentes específicos que se encargan de traducir los mensajes
de otros agentes al sistema de comunicación propio del sistema antiguo y viceversa.
Existen dos posibles arquitecturas para el sistema multiagente, una en la que cada
agente gestiona su propia coordinación con los demás y otra en la que existen agentes
especiales encargados de coordinar a los diferentes agentes. La primera aproximación
tiene la desventaja de que la escalabilidad no está asegurada, por lo que la segunda
suele ser la más aceptada. En esta última, los agentes encargados de la coordinación
suelen realizar funciones como encontrar agentes que proporcionen servicios determinados,
establecer la comunicación entre diferentes entornos y asegurar que la comunicación entre
agentes sea correcta. Los sistemas multiagente proporcionan una serie de ventajas con
respecto a otras aproximaciones de diseño. Esto permite resolver problemas demasiado
grandes para un agente centralizado, evitan que exista un único punto de error, permiten
resolver problemas inherentemente distribuidos y ayudan a resolver problemas donde el
“conocimiento experto” es distribuido.
Estructura Horizontal: Este tipo de configuración existe cuando todos los agentes
que integran un sistema están al mismo nivel, es decir, no hay ningún agente que
haga las veces de maestro o supervisor, ni tampoco agentes esclavos.
Estructura Jerárquica: Esta configuración existe cuando los agentes trabajan dife-
rentes niveles de abstracción de un problema, es decir, la configuración es de niveles.
En un mismo nivel se establece una configuración horizontal, si hay más de un agen-
te. Para resolver un problema cada agente divide el problema en subproblemas que
él puede solucionar con la cooperación de los agentes que están al mismo nivel y
subproblemas que sabe que los agentes de niveles inferiores de la jerarquía pueden
hacerlos por sí mismos.
Estructura “ad hoc”: Esta configuración puede ser una mezcla de las tres anteriores,
se caracteriza porque la dinamicidad de la estructura está regida por el ajuste mutuo
entre los pequeños grupos de agentes en el sistema.
Escoger una u otra estructura de organización depende de las funciones que deben cumplir
los agentes del sistema, de sus características y de la complejidad que requiera el sistema.
Cooperación
En un sistema multiagente existen dos tipos de tareas a realizar: las tareas locales y las
tareas globales. Las tareas locales son las tareas relacionadas con los intereses individuales
de cada agente y las tareas globales son las tareas relacionadas con los intereses globales
del sistema. Estas tareas globales son descompuestas y cada subtarea es realizada por
un agente, de acuerdo a sus habilidades y bajo el supuesto de que la integración de la
solución de las subtareas llevará a la solución global. La descomposición de la tarea global
no necesariamente garantiza la independencia de cada una de las subtareas, por ello se
necesitan mecanismos de cooperación que permitan compartir resultados intermedios que
lleven al progreso en la resolución de las tareas de otros agentes y al progreso de la solución
global que debe alcanzar el sistema.
Para que los agentes puedan cooperar de manera eficiente, cada uno de ellos debe
tener ciertas características:
Es necesario tener un modelo bien definido del mundo, que le permita localizar a
los demás agentes, saber cómo comunicarse con ellos, qué tareas pueden realizarse,
etc.
Así como la posibilidad de integrar información de otros agentes con la suya, para
formar conceptos globales o conocimiento conformado por varios agentes.
Y el poder interrumpir un plan que se esté llevando a cabo para ayudar o atender
a otros agentes para que puedan cooperar entre sí cuando los agentes lo necesiten.
Coordinación
La coordinación entre un grupo de agentes les permite considerar todas las tareas a
realizar y coordinarlas para no ejecutar acciones no deseables, por ejemplo:
Hay varios modelos de coordinación de acciones entre agentes, entre los que destaca-
mos:
Coordinación orientada por los problemas: En este tipo de coordinación, los agentes
deben coordinar los planes de realización de acciones para prevenir interbloqueos,
repetición de acciones y creación de inconsistencias.
Negociación
Para que los mecanismos de cooperación y coordinación sean exitosos en un sistema
de agentes que actúan independientemente, debe existir un mecanismo adicional, por
medio del cual los integrantes de un sistema se puedan poner de acuerdo cuando cada
agente defiende sus propios intereses, llevándolos a una situación que los beneficie a todos
teniendo en cuenta el punto de vista de cada uno. Este mecanismo es llamado negociación.
Los procesos de negociación tienen como resultado la modificación o confirmación de
las creencias de cada agente involucrado, en lo relacionado con los demás agentes y con
el mundo en el que se desenvuelve.
La negociación se puede mirar bajo una perspectiva racional, la cual describe la nego-
ciación como un proceso de seis pasos que consisten en definir el problema, en identificar
los aspectos que lo representan, en ponderar los diferentes criterios, generar alternativas,
evaluar estas alternativas, y por último formular la solución.
En los sistemas multiagentes la mayoría de las veces el problema está bien definido, es
decir, el primer paso no es relevante. Los demás pasos se pueden o no seguir, dependiendo
del problema para el cual un grupo de agentes busca una solución.
Los mecanismos de negociación utilizan diferentes reglas en lo relacionado con la dis-
tribución de recursos del sistema:
Regla igualitaria: establece una distribución de recursos a partes iguales para todos
los miembros.
Hay otro tipo de reglas usadas en negociación, relacionadas con la toma de decisiones:
Control
El control es el mecanismo básico que proporciona apoyo para la implementación de
mecanismos de coordinación en un sistema multiagente. El control se relaciona directa-
mente con la determinación de las subtareas más importantes a realizar en un momento
dado. Así como la determinación del contexto en que deben ser usados dentro de la so-
lución de cada subtarea. También es importante estimar el tiempo de generación de la
solución por cada subtarea. Así como evaluar si se ha generado la solución de un problema.
El control puede ser considerado desde dos puntos de vista, por un lado el control global
y por otro el control local. El control global se relaciona con tomar decisiones basándose en
datos obtenidos y consolidados a partir de la información de todos los agentes del sistema,
mientras que el control local se relaciona con tomar decisiones basándose solo en datos
locales. Estos dos controles deben ser balanceados por varias razones: En primer lugar,
el aumento del poder de control local nos lleva a que los agentes actúen eficientemente
desde el punto de vista “rapidez en la toma de decisiones y en la ejecución de tales
decisiones”. Pero se puede llegar a la pérdida de mecanismos de cooperación efectivos y
como consecuencia a la realización de tareas no deseables. A su vez, el aumento del poder
del control global nos puede llevar a aumentar los costos de computación del sistema,
porque como consecuencia cambia dinámicamente la información de los agentes. Para
mantener la coherencia en la información global se deben revisar e incorporar de forma
constante los cambios en cada uno de los agentes.
Para mantener el balance entre el control global y el control local, los componentes
del control local de cada agente deben proveer al control cooperativo una descripción
de su estado actual y de actividades esperadas. A la vez que han de interactuar con el
control cooperativo para modificar las actividades locales y estar más “on-line” con las
necesidades de los otros agentes. Y por su puesto, ser suficientemente sofisticado en la toma
de decisiones de manera que pueda tolerar cierto nivel de error en el control cooperativo.
Existen diferentes mecanismos y estrategias para la implementación del control en un
sistema multiagente. El mecanismo básico propuesto es la creación y manejo de estructuras
a las que puedan acceder todos los agentes y en las que se representen, organicen e integren,
a alto nivel, las metas globales y locales del sistema. Cada una de estas metas se relaciona
con la intención de realización de alguna tarea. La estructura global de metas no necesita
ser totalmente desarrollada para la resolución distribuida de problemas, la estructura
puede ser construida a medida que la solución del problema progresa.
Para poder manejar estas estructuras de objetivos, los agentes que integran el sistema
multiagente deben tener la habilidad de transmitir sus estructuras locales de metas. La
transmisión de las metas puede indicar a los otros agentes qué tipo de información es más
necesaria para el desarrollo de una solución. Por otro lado, la generación de submetas
a partir de las metas facilita la generación de resultados intermedios que lleven a la
consecución de la meta inicial. De esta forma, la incertidumbre en el control cooperativo
disminuye porque se genera más información y hay una mayor comunicación. Sin embargo,
la comunicación de estructuras de metas genera costos adicionales de comunicación en el
sistema.
A partir de la información de la estructura de metas se debe decidir cuáles son las
metas de mayor importancia para su realización. Para ello es importante distinguir entre
la creencia local en un resultado parcial (creencias) y la importancia de incorporar tal
resultado en una solución (evaluación global de la importancia de un resultado). La eva-
luación local de la importancia de metas externas, determina el balance entre responder
a las necesidades de otros agentes y a las propias. La decisión del balance preciso depen-
de de cómo los agentes, desde su perspectiva local, juzguen sus resultados parciales y la
importancia de sus metas desde una perspectiva cooperativa. Entre las estrategias para
la implementación de los mecanismos de control se mencionan:
Metacontrol estático asociado con la estructura organizacional de un sistema : Para
Esta información guía a un agente, para reorganizar sus metas locales, buscando resultados
tales como: explotar los resultados parciales disponibles de otros agentes, proporcionar
resultados parciales que puedan restringir el campo de búsqueda de la solución a las metas
de otros agentes, evitar soluciones redundantes a metas, excepto cuando sea deseable, y
por supuesto reevaluar la importancia de alcanzar una meta.
El estándar FIPA
FIPA es un consorcio internacional creado en 1995 y que está formado por distintas
universidades y empresas. El objetivo del consorcio es crear un estándar público, para
lo que proporciona una serie de especificaciones normativas (referencias tecnológicas) e
informativas (referencias de aplicaciones). Las referencias tecnológicas especifican una
plataforma que permite el desarrollo de sistemas multiagente abiertos, mientras que las
referencias a aplicaciones son aplicaciones reales que motivan el uso de estos sistemas. Las
referencias tecnológicas establecen normas de comportamiento e interfaces externas que
aseguran la interoperabilidad con otros sistemas similares sin imponer una implementación
específica.
Sender: Denota la identidad del emisor del mensaje. Es decir, el nombre del agente
que envía el mensaje.
Reply-to: Indica el agente al que deben dirigirse los siguientes mensajes en lugar de
al emisor.
Reply-with: Expresión que será usada por el agente que responde para identificar el
mensaje.
In-reply-to: Denota una expresión relativa a una acción anterior a la que responde
el mensaje.
Reply-by: Denota una fecha u hora que indica el límite temporal en el que el emisor
espera recibir una respuesta.
JADE posee una ontología de gestión de agentes (SL), además de soportar ontolo-
gías y lenguajes de contenido definidos por el usuario que pueden ser implementados y
registrados con los agentes además de usados automáticamente por el framework. JADE
también está integrado con JESS, lo que permite añadir capacidad de razonamiento a los
agentes.
En la actualidad JADE ha sido adoptado por una serie de compañías, de las cuales
algunas son miembros del consorcio FIPA. Entre las compañías que usan JADE se encuen-
tran BT, CNET, NHK, Imperial Collage, IRST, KPN, Universidad de Helsinki, INRIA,
ATOS y muchas otras.
El framework de JADE incluye tanto las librerías necesarias para el desarrollo de
aplicaciones de agentes como el entorno de ejecución que proporciona los servicios básicos
que deben activarse para que los agentes puedan funcionar. Cada instancia del entorno
de ejecución de JADE se conoce como contenedor. El conjunto de todos los contenedores
forma una plataforma y proporciona una capa homogénea que oculta a los agentes la
complejidad de las capas subyacentes.
JADE es compatible con J2ME CLDC/MIDP1.0 pudiendo funcionar sobre redes
GPRS, así como sobre otros tipos de red. Debido a los escasos recursos requeridos por
JADE, puede desplegarse en sistemas con restricciones, aunque también puede integrarse
en arquitecturas más complejas como .NET o J2EE.
A pesar de los beneficios que nos proporciona el uso de los agentes móviles, su uso
extendido está restringido por razones de seguridad y, en concreto, por la carencia de
mecanismos de seguridad apropiados. Entendemos por seguridad toda aquella acción que
tiende a garantizar el cumplimiento de alguna de seis propiedades básicas: autentica-
ción, autorización, confidencialidad, integridad, disponibilidad y no-repudio. Mostremos
un ejemplo de ello: “Cuando el agente del proceso A se envía a la máquina donde reside
el proceso B, hay un potencial obvio para que el agente provoque problemas”. Podría
potencialmente hacerlo de diferentes maneras. La cuestión de seguridad predomina en las
discusiones de agentes móviles. Java es un lenguaje que soluciona algunos agujeros de
seguridad. Por ejemplo, Java no tiene punteros, así que es intrínsecamente complicado
que una aplicación en Java pueda acceder a un proceso que se encuentra en memoria.
Además, las máquinas virtuales de Java poseen una clase llamada SecurityManager que
permite establecer una política de seguridad (accesos a recursos,...). Sin embargo, es muy
difícil asegurarse que un proceso no use más de un cierto número de ciclos del procesador.
El tener un control de la seguridad es un grave problema, ya que los agentes son
programas que viajan de una máquina a otra, de forma similar a como lo realiza un virus.
Se deben controlar los siguientes aspectos: protección de la máquina frente a agentes y
protección de los agentes contra la máquina. Vamos a describir detalladamente cada una
de ellas y las peculiaridades de sus soluciones.
Ataques
Como ya mencionábamos en la introducción de esta sección, existen multitud de razo-
nes por las cuales un host podría iniciar un ataque contra el agente, e incluso estos ataques
podrían ser de índoles muy diversas, bien por obtener beneficios en la ejecución del agente,
o simplemente por pura diversión. A continuación vamos a definir los diferentes tipos de
ataques que se pueden realizar sobre un agente móvil [24]:
información para obtener cierto beneficio en la ejecución del agente. Este problema
plantea serias dificultades, puesto que es muy difícil evitar y/o detectar las escu-
chas de cualquier dato no cifrado que transporte el agente. Asimismo es una tarea
difícilmente evitable el hecho de que el host guarde una copia de los datos cifrados
para realizar un posterior análisis criptográfico.
Otro tipo de ataques que hay que considerar es el basado en las confabulaciones entre
hosts. Este consiste en que ciertos hosts tienen en común la pertenencia al itinerario
de un agente y establecen un acuerdo para sacar provecho de la ejecución del agente.
Este tipo de ataques es de difícil detección y prevención. Un hecho que demuesta esta
afirmación, radica en que todas las propuestas actuales para proporcionar seguridad
a los agentes móviles son vulnerables a las confabulaciones. Por otro lado existen
técnicas para la protección del itinerario [27] que se podrían emplear en la limitación
de los posibles efectos de las confabulaciones. A lo largo de este trabajo de tesis se
ha hecho especial hincapié en abordar este problema. Una prueba que lo evidencia
la encontramos en los dos mecanismos desarrollados en los siguientes capítulos.
Medidas
Atendiendo a la clasificación de Bierman y Cloete [28] vamos a clasificar las distintas
propuestas atendiendo a si están enfocadas a proporcionar la detección de los posibles
ataques o a la prevención de los mismos.
La medida conocida como “Replicación y Voto” introducida por Minsky et al. [29]
consiste en la agrupación de los hosts en distintas etapas por las que los agentes van
circulando. Esto se ha de realizar con la restricción de que los hosts pertenecientes a
una misma etapa han de ser mutuamente independientes y proporcionar los mismos
severamente dañado, puesto que dónde antes se enviaba un agente ahora se envían
varios. Otra de las desventajas de esta propuesta radica en el hecho de que todos los
agentes cooperantes han de permanecer en la red hasta que el último finalice. Otro
aspecto a considerar consiste en que el sistema ha de garantizar que la comunicación
entre los agentes cooperantes se mantenga, puesto que sino esto podría provocar
retrasos, e incluso la obstrucción a la consecución de las tareas principales. Y por
supuesto, qué ocurre si alguno de los agentes cooperantes abandona su ejecución
por cualquier motivo ajeno, como podría darse el caso de que la máquina en la
que esté corriendo la agencia sea apagada por cualquier motivo. Y por último, no
debemos olvidar que esta estrategia asume que no hay confabulación, sin embargo
no podemos obviar este hecho. A pesar de las desventajas que puede presentar
esta solución, es cierto que aporta ideas muy ventajosas para el desarrollo de nuevos
mecanismos. En concreto una de las propuestas desarrolladas en este trabajo de tesis
tiene como semilla la propuesta de los agentes cooperantes, sin embargo llevada a
otros niveles, solventando la mayoría de las limitaciones de esta propuesta, para más
detalle consultar capítulo 4.
Firma de código
La técnica de firma de código asegura la integridad del código descargado desde Inter-
net. Permite a la plataforma verificar que el código no ha sido modificado desde que fue
firmado por su creador. La firma de código no puede revelar lo que el código puede hacer
o garantizar que es seguro en su ejecución.
La firma de código hace uso de una firma digital y una función hash. Una imple-
mentación conocida de ésta técnica es el “Microsoft Authenticode”, el cual es típicamente
usado para firmar código como controladores ActiveX y applets de Java. La firma de có-
digo permite verificar la identidad del creador del código, pero esto no garantiza que sea
seguro.
con datos de manera que un posible atacante no pueda tener acceso a ningún tipo de
información sobre dichos datos. Un concepto básico del hardware confiable es que es
resistente a intentos de modificación del propio dispositivo, lo que se conoce como tamper
proof (a prueba de falsificación).
Existen diferentes maneras de protegerse ante los ataques físicos:
Tamper evidence, que consiste en que el dispositivo posee mecanismos que provocan
que cualquier ataque físico deje huella y por lo tanto pueda ser detectado.
Y por último el tamper response, en este el dispositivo posee mecanismos que des-
truyen la información cuando se produce un ataque, lo que evita el acceso a la
misma.
Hay que destacar que la seguridad que proporciona el hardware confiable tiene un
límite físico determinado por sus características, sin embargo, la comunicación entre los
dispositivos seguros y los no seguros siempre es susceptible de ser atacada.
Existe una gran diversidad de ataques físicos diferentes que podría sufrir el hardware
confiable. En primer lugar, el acceso directo a componentes internos del dispositivo. En
segundo lugar, lo que se conoce como “micro probing”, que consiste en observar o mani-
pular el dispositivo. O las técnicas conocidas como “ingeniería inversa”, que analizan el
dispositivo para identificar sus componentes y cómo se relacionan. También nos encontra-
mos con las técnicas de lectura de memoria (mediante congelado por nitrógeno líquido,
que aumenta el tiempo que la RAM retiene datos y lectura posterior de los datos). Y con
otro tipo de técnicas no invasivas (acceso con rayos UV, rayos x, etc.).
Además de ataques directos sobre el dispositivo, el hardware confiable suele ser resis-
tente a otros tipos de ataques no invasivos. Los conocidos como “tempest attacks”, que
consisten en reconstruir datos a partir de las radiaciones electromagnéticas del disposi-
tivo, los conocidos como “side channel attacks” que pueden llevarse a cabo de diferentes
maneras:
Mediante un análisis temporal, que consiste en medir el tiempo que consumen las
operaciones criptográficas respecto a los datos de entrada y el algoritmo implemen-
tado.
Por otro lado, también es posible atacar los dispositivos de hardware confiable reali-
zando ataques software de las API criptográficas. La realización de este tipo de ataques
es posible gracias a ciertos problemas existentes en dichas API. En primer lugar la in-
tegridad de las claves es insuficiente. Ya que se pueden producir problemas derivados de
la retrocompatibilidad, que implican hacer uso de algoritmos más vulnerables, e incluso
otros tipos de ataques a la integridad de las claves. En segundo lugar, se puede realizar
un chequeo insuficiente de los parámetros de la función (ataques sobre el sistema de re-
cuperación de códigos PIN, etc.). O se puede dar el caso de que ocurra un cumplimiento
insuficientemente estricto de las políticas de seguridad.
Hay que destacar que el hardware confiable no es completamente seguro, y que siempre
es posible realizar algún tipo de ataque. Sin embargo, el objetivo de este hardware es
dificultar los ataques, de manera que se produzcan en menor medida. Por otro lado,
también es importante resaltar que gran parte de los ataques que se producen tienen
como objetivo el software que a su vez hace uso del hardware confiable. Por lo que es
importante realizar el diseño del software con la mayor cautela posible, ya que de nada
sirve disponer del hardware de seguridad más avanzado del mercado si no se hace un buen
uso específico del mismo. Una vez descrita nuestra concepción de hardware confiable,
vamos a ver el hardware que usamos en esta tesis, el Trusted Platform Module (TPM). El
TPM es un microcontrolador desarrollado por el Trusted Computing Group (TCG) que
almacena claves criptográficas, claves de acceso y certificados digitales protegiéndolos de
ataques externos, tanto físico como lógicos (software).
Antes de analizar con más detalle el TPM, vamos a conocer un poco más qué es el
TCG y cual es su objetivo. El TCG es una organización sin ánimo de lucro formada en
2003 por diversas empresas (AMD, HP, Microsoft, Sony, Sun Microsystems, etc.) con el
objetivo de desarrollar, definir y promover estándares abiertos para computación segura
basada en hardware y otros desarrollos tecnológicos relacionados con la seguridad. Las
especificaciones del TCG tienen como objetivo obtener entornos de desarrollo más seguros
sin que ello comprometa la integridad funcional, privacidad o derechos individuales. éstas
especificaciones adoptan las creadas por el TCPA (Trusted Computing Platform Alliance)
promoviendo de manera conjunta la mejora de dichas especificaciones y su extensión hacia
diversas plataformas como servidores, PDA, teléfonos digitales, etc.
La estructura del TCG está diseñada para favorecer una amplia participación, una
gestión eficiente y una amplia adopción de las especificaciones. Para ello se siguen una
serie de principios. El primero es que la pertenencia al TCG está abierta a un amplio
rango de organizaciones, además de empresas que apoyan los objetivos del TCG. Existen
diferentes niveles de pertenencia al TCG y los beneficios están claramente definidos. El
segundo principio se basa en la política de licencia de patentes entre miembros que se
realiza de forma razonable y no discriminatoria. El tercer principio radica en la estructura
de los comités, grupos de trabajo, etc. se deciden por mayoría absoluta. Y por último está
el plan de mercado definido.
Actualmente, el TCG cuenta con más de 170 miembros entre los que figuran empresas
como Microsoft, Sun Microsystems, AMD, HP, IBM, Infineon, Intel, Lenovo, etc. El TCG
cuenta además con un consejo asesor, designado por la junta directiva, cuyo objetivo es
aconsejar sobre un amplio espectro de temas relacionados con la computación confiable.
Este consejo está compuesto por expertos de una diversa variedad de campos como la
privacidad, seguridad, arquitectura de computadores, servicios financieros, comercio elec-
trónico, etc. El TCG se compone de varios grupos de trabajo encargados de desarrollar
Estas son una serie de comandos que tienen permiso exclusivo para acceder a ubicaciones
protegidas. Con ubicaciones protegidas nos referimos a aquellas zonas (memoria, regis-
tros) dónde pueden realizarse operaciones sobre datos sensibles de manera segura. El TPM
implementa estas funciones protegidas que permiten realizar informes de mediciones de
integridad de la configuración, además de proporcionar ubicaciones seguras para proteger
dichas mediciones. Por otro lado, el TPM almacena claves criptográficas que permiten au-
tenticar la información. También disponemos de la atestación, consistente en un proceso
que permite a una entidad obtener datos precisos de otra. La atestación puede verse desde
varios puntos de vista. La atestación realizada por el TPM es una operación que propor-
ciona veracidad a datos contenidos en el TPM. Se realiza firmando digitalmente datos
internos del TPM usando una AIK. La veracidad, tanto de los datos firmados como de la
AIK la determina la entidad que los solicita. La AIK se obtiene mediante protocolos que
hacen uso de una Autoridad de Certificación (Certification Authority, CA) o protocolos
de atestación segura. La atestación de la confiabilidad de una plataforma es una operación
que asegura que puede confiarse en una plataforma para que esta proporcione medidas de
la integridad. Se realiza usando un conjunto (o subconjunto) de las credenciales asociadas
con la plataforma, que permiten crear las credenciales de la AIK. La atestación de la con-
figuración de una plataforma es una operación que proporciona veracidad a un conjunto
de datos sobre la integridad de la misma. Se realiza firmando digitalmente mediante una
AIK un conjunto de registros PCR. La autenticación de la plataforma, es una operación
que asegura la autenticidad de la identidad de una plataforma, la cual puede o no estar
ligada a un usuario o a las acciones llevadas a cabo por este. Esta operación se realiza
firmando con una clave “no migrable” del TPM. Debe tenerse en cuenta que el número
de claves de este tipo en un TPM es ilimitado, siendo por tanto ilimitado el número de
identidades. También tenemos soporte para llevar a cabo la medida, registro e informe
de integridad. La medida de la integridad es el proceso que obtiene características del
sistema que puedan afectar a la integridad (confiabilidad) del mismo. El punto de partida
de esta medida se conoce como Raíz de confianza (Root of Trust, ROT), que proporciona
desde la raíz de confianza, incorporando sucesivamente diferentes bloques que pasan a ser
confiables.
Además el TPM proporciona un sistema de medición de la integridad que genera
informes del estado operativo de la plataforma, almacenando dos tipos de medidas. En
primer lugar los parámetros medidos se refieren a lo que se mide en realidad. Y los valores
hash, que no son más que un valor obtenido tras aplicar una función hash a la medición de
cierto parámetro. Los valores hash son almacenados en el TPM usando la funcionalidad de
RTR y RTS, mientras que los parámetros medidos pueden ser almacenados en cualquier
lugar que el sistema de medición determine. De hecho pueden incluso no almacenarse,
siendo computados cuando sean necesarios.
Los datos medidos describen propiedades y características del componente medido.
Es responsabilidad del implementador de núcleo de medición entender la sintaxis y la
semántica de los campos medidos con el suficiente detalle como para poder producir
resultados que sean usados por los consumidores de los eventos de medida.
El registro de medidas almacenadas (Stored Measurement Log, SML) contiene se-
cuencias de medidas relacionadas. Dichas secuencias comparten un mismo valor hash, ya
que cada nueva medida se enlaza a las anteriores y se recalcula de nuevo el valor hash.
Esta técnica permite relacionar valores y preservar la secuencia de las operaciones. La
representación algebraica de la extensión de los valores se calcula como sigue:
PCR[n]<-SHA-1(PCR[n]+datos de medición)
EL SML no se almacena dentro del TPM ya que puede ser demasiado grande y no
necesita la protección proporcionada por el TPM ya que los ataques contra el SML podrían
detectarse. Aun así, el SML puede sufrir ataques de denegación del servicio, por lo que
los implementadores deberían poder replicar o regenerar el registro.
El RTR tiene dos funciones: proporcionar ubicaciones seguras para el almacenamiento
de informes de integridad y atestar la autenticidad de los valores almacenados según la
identidad de las plataformas seguras. Los PCRs pueden implementarse en memoria volátil
o no volátil y deben estar protegidos frente a ataques software. También deben tenerse
en cuenta medidas para protegerlos frente a ataques físicos. Los informes de integridad se
firman digitalmente usando una AIK para autenticar los valores de los PCRs. La firma
incluye un nonce para evitar ataques de repetición.
El TPM posee una clave interna llamada Endorsement Key (EK). Esta clave se usa
para establecer el propietario del TPM y para emitir las credenciales de las AIK. El pro-
pietario del TPM puede crear una clave raíz de almacenamiento (Storage Root Key, SRK),
que sirve para envolver otras claves del TPM pudiendo almacenarlas de manera segura
fuera del TPM. El reporte de la seguridad puede usarse para determinar la configuración
de una plataforma en un momento dado.
El protocolo consta de varias etapas:
2. Un agente de la plataforma con acceso al TPM obtiene las entradas del SML.
6. La entidad solicitante verifica los datos obtenidos. Los valores recibidos son compa-
rados con los valores que posee el solicitante. Además se evalúan las credenciales y
se comprueba la firma.
participación de una CA que emita las credenciales de la AIK que atestiguan la confia-
bilidad de la plataforma. Estas credenciales sustituirían a la parte pública de la EK, que
no es apropiada para su distribución pública. El TPM debe probar a la CA que la AIK
es de uso exclusivo suyo. Para ello, la CA emite las credenciales cifrándolas con la EK, de
manera que sólo el TPM que generó dicha TPM pueda descifrarla. Por su parte, la CA
no debe revelar información privada relacionada con el TPM.
• Credenciales del TCG: El TCG define cinco tipos de credenciales, cada tipo está
pensado para proporcionar la información necesaria para llevar a cabo una opera-
ción específica: credenciales de aprobación (Endorsement Credentials), credenciales
de conformidad (Conformance Credentials), credenciales de plataforma (Platform
Credentials), credenciales de validación (Validation Credentials) y por último cre-
denciales de identidad (Attestation Identity Credentials).
• Credenciales de aprobación: Son emitidas por la entidad que generó la EK, que
normalmente es el fabricante del TPM. Las credenciales contienen el nombre del
fabricante del TPM, el número de modelo del TPM, la version del TPM, la clave
pública de la EK y por último la firma del fabricante del TPM. La clave pública
de la EK, aun siendo pública, debe ser de acceso restringido como señalamos an-
teriormente, debido a que identifica de manera única el TPM y por extensión a la
plataforma.
y por lo tanto el mensaje sólo será accesible desde dicho TPM. Por otro lado, si
la clave fuera migrable esta característica desaparecería. Este mecanismo es clave
para una de las aportaciones fundamentales de esta tesis como se verá en capítulos
sucesivos.
Sellado-Ligado (Sealed-Binding): Los mensajes a los que se les aplica esta operación
quedan ligados a un estado de la plataforma, de esta manera el mensaje sólo puede
ser descifrado si la plataforma del receptor se encuentra en un estado concreto. Esta
operación asocia un mensaje con una serie de valores de los PCRs y con una clave
asimétrica “no migrable”. De esta manera el receptor sólo puede descifrar el mensaje
si el TPM posee la clave de cifrado correspondiente y los valores de sus PCR son
los determinados por el emisor.
Sellado-Firmado (Sealed-Signing): Esta operación enlaza una firma con unos valores
determinados de los PCRs, añadiendo por lo tanto la prueba de que la plataforma
que firmó el mensaje se encontraba en un estado determinado. En este caso, el
receptor de la firma indica al emisor que la firma debe incluir una serie de valores
de los PCRs. El emisor, obtiene los valores de los PCRs y los incluye en el mensaje
a firmar. El verificador analiza posteriormente los valores de los PCRs incluidos
en la firma, de manera que puede determinar el estado de la configuración de la
plataforma emisora en el momento en el que se realizó la firma.
El RTS protege claves y datos confiados al TPM. Para ello el RTS gestiona una pequeña
porción de memoria volátil en la cual se cargan las claves para realizar operaciones de
firma y cifrado. Las claves no usadas pueden ser cifradas y almacenadas fuera del TPM
para obtener espacio para otras claves que se vayan a usar. La gestión del espacio de caché
para claves es gestionado de forma externa por el Gestor de Caché de Claves (Key Cache
Manager, KCM), que actúa de interfaz entre el dispositivo de almacenamiento donde se
almacenan las claves inactivas de manera indefinida.
El RTS está optimizado para almacenar objetos pequeños, aunque puede almacenar
diferentes tipos de objetos como claves simétricas, claves asimétricas, claves de acceso,
cookies, resultados de autenticación y datos en general.
Existen dos tipos de claves integradas en el TPM, la EK y la SRK, que no pueden ser
eliminadas, aunque es posible crear una nueva clave SRK para un nuevo propietario de la
plataforma. Esto último provoca que los datos controlados por la SRK anterior no queden
“en-claro”. La clave SRK generada por el TPM y su clave de acceso se cifran usando la
EK cuando se establece el propietario del TPM. La clave SRK se usa para proteger otras
claves de manera que puedan ser almacenadas en el exterior del TPM.
Atributos de las claves. Todas la claves gestionadas por el RTS pueden ser “migrables”
o “no-migrables”, según se pudieran transferir de un TPM a otro. Este atributo se establece
Claves de firma (Signing keys): Son claves asimétricas de propósito general que se
usan para firmar datos de una aplicación y mensajes. Pueden ser “migrables” o “no
migrables”, pudiendo en cada caso ser exportadas a otros TPM o no. El TPM puede
firmar datos de la aplicación con una clave e imponer restricciones para la migración
de dichos datos.
Claves de identidad (Identity keys, AIK): Son claves de firma “no migrables” cuyo
propósito exclusivo es firmar datos generados por el TPM (valores PCR, etc.).
Claves de conformidad (Endorsement keys, EK): Son claves de cifrado “no migrables”
pertenecientes a una plataforma. Se usan para descifrar datos del propietario en el
momento en el que se establece el mismo en la plataforma. También se usan para
descifrar mensajes asociados con la creación de una AIK. No deben usarse para
cifrar o firmar.
Claves de ligado (Bind keys): Son claves que pueden ser usadas para cifrar datos
pequeños (por ejemplo, claves simétricas) en una plataforma y descifrarlos en otra.
Claves externas (Legacy keys): Son claves creadas fuera del TPM. Se importan al
TPM para firmar o cifrar. Por definición son claves “migrables”.
Atestation Identity Keys (AIK). Las AIK deben ser persistentes, sin embargo se
recomienda que sean almacenadas cifradas de forma externa al TPM. Cuanto más
espacio disponible haya en el TPM para mantener las AIK cargadas mayor será la
velocidad de ejecución de los programas que hagan uso de ellas.
Motor Sha-1. Es un motor que calcula valores hash Sha-1 y que se usa para generar
firmas, empaquetar claves cifradas y para otros usos generales.
Generador de claves RSA. El TCG establece el algoritmo RSA como estándar para
el uso en TPM. El motor de generación de claves RSA se usa para crear claves de
firma y de almacenamiento. Los TPM deben soportar claves RSA de más de 2048
bits, y algunas claves (SRK, AIK) deben ser de al menos 2048 bits.
Motor RSA. El motor RSA se usa para firmar con claves de firma, cifar/descifrar
con claves de almacenamiento y descifrar con la EK.
Opt-In. Estos componentes implementan la política del TCG que obliga que los
TPM sean entregados a los clientes en el estado que ellos deseen. El estado inicial
puede ser deshabilitado, desactivado o habilitado, preparado para que el usuario
establezca el propietario del TPM. Los mecanismos Opt-In proporcionan la lógica
y los interfaces para determinar el estado de la presencia física y asegurar que se
deshabiliten las operaciones de otros componentes del TPM cuando sea necesario.
6. Verificar la prueba no es una tarea fácil si lo que se quiere es una prueba concisa y
que el chequeador sea pequeño, rápido e independiente de la política de seguridad.
La frecuencia del procesador suele estar relacionada con el lector. Puesto que las tarjetas
no disponen de generador de reloj interno y por tanto reciben la señal de reloj del lector.
Esto hace que, aunque existan tarjetas capaces de funcionar a frecuencias muy altas de
reloj (33Mhz), en la práctica se ven limitadas a la velocidad que es capaz de proporcionar
cada lector y que suele rondar los 5Mhz. Evidentemente, los avances en la tecnología de
control de reloj hacen que algunas tarjetas puedan funcionar internamente a estas eleva-
das velocidades de reloj, independientemente de la velocidad proporcionada por el lector.
Otro aspecto a considerar es el referente al software contenido en la tarjeta, tanto a nivel
de sistema operativo como de aplicaciones, así como la posibilidad de instalar aplicacio-
nes de forma dinámica, que determinan en gran medida la utilidad de las mismas. Y por
último la inclusión de coprocesadores que aceleren las operaciones criptográficas puede
ser una característica importante, debido a que la utilidad de estos dispositivos está muy
ligada a la seguridad de la información.
Applet. El applet se ofrece como una máquina de estados que sólo procesa los co-
mandos recibidos a través del dispositivo lector enviando y respondiendo con códigos
de estado y datos.
3.1. Introducción
A lo largo de la historia más reciente se han propuesto diferentes mecanismos de
protección para sistemas de agentes. En el capítulo 2 de esta tesis describimos un conjunto
amplio de ellos. Entre los que nos encontramos con un conjunto centrado en proteger a
las plataformas frente a agentes, mientras otros buscan proteger a los agentes de posibles
ataques de plataformas. Además se muestra la existencia de mecanismos para proporcionar
una protección en ambos sentidos, tanto hacia los agentes como hacia las plataformas,
que como he mencionado con anterioridad, representan el caso más completo.
En el capítulo 1 introductorio de esta tesis comentamos que el trabajo queda estruc-
turado en dos bloques bien diferenciados. El primero de ellos consiste en el diseño y
desarrollo de un mecanismo de seguridad para sistemas de agentes basado en un elemento
hardware y el segundo basado en la técnica de computación protegida al que dedicamos
el capítulo 4. Para ello se ha elaborado una librería basada en el uso de un dispositivo
hardware confiable. Usando este elemento he implementado un mecanismo de migración
confiable que aporta la seguridad necesaria al proceso de migración de los agentes de un
sistema.
Como vimos en el capítulo 2, un sistema multiagente se compone de una serie de
agentes que realizan tareas de manera autónoma o colaborando entre sí. Estos agentes
necesitan un entorno en el que ejecutarse, a este entorno lo conocemos como agencia. Una
agencia no es más que una ubicación que aloja agentes y les proporcionan los medios para
que estos se puedan ejecutar. En la figura B.2 podemos ver un ejemplo del despliegue
de un sistema multiagente clásico, en el que se muestran varias agencias distribuidas y
conectadas entre sí con un número variable de agentes ejecutándose en las mismas.
En un sistema como el de la figura B.2 los agentes han de disponer de los medios
necesarios y accesibles para realizar sus tareas en las agencias, desplazándose de una a
otra cuando fuera necesario de acuerdo a su itinerario programado. Sin embargo, como
ya he comentado, esta arquitectura implica una serie de problemas relacionados con la
seguridad. Esto se pone en práctica debido a que los agentes se ejecutan en el entorno
de una agencia remota, estando a merced del comportamiento de la misma. Y por otro
67
Protección basada en Hardware Criptográfico
lado los agentes podrían tener ciertos propósitos maliciosos bien contra otros agentes del
sistema o bien frente a las agencias mismas.
La seguridad puede definirse de formas muy variadas, habitualmente se designa un
sistema seguro como aquel que cumple algunas de las propiedades de seguridad tradicional
como son la confidencialidad, la autenticación, la integridad, el control de acceso, el no
repudio y la disponibilidad. Desde nuestro punto de vista estas propiedades deben darse
en un cualquier sistema que se denomine seguro y por lo tanto debe ser un objetivo
prioritario a perseguir en el momento del diseño de cualquier sistema.
Anteriormente comentábamos que en un sistema multiagente la seguridad puede verse
vulnerada por las agencias capaces de atacar a los agentes del sistema. Por esta razón un
agente no debe confiar en las agencias obviando que sean seguras. De la misma manera,
las agencias también pueden ver vulnerada su seguridad por los agentes que aloja [19].
Entre los posibles problemas de seguridad que pueden darse en un sistema multiagente
nos encontramos los siguientes, de una forma esquemática:
Desde el punto de vista de las agencias:
Los agentes pueden atacar a la agencia de manera que esta pierda su funcionalidad
total o de forma parcial.
Los agentes pueden acceder a datos privados de la agencia para los que no tienen
autorización.
Los agentes pueden engañar a la agencia proporcionando una identidad falsa, ha-
ciéndose pasar por otros agentes con privilegios sobre los recursos de la plataforma.
Los agentes pueden ser atacados por la agencia en la que se encuentran de manera
que dejen de funcionar.
Las agencias pueden acceder a datos privados de los agentes para los que no tienen
autorización.
Figura 3.2: Esquema de agencias distribuidas en una red junto a sus respectivos disposi-
tivos hardware confiables.
Los agentes pueden ser atacados por otros agentes de manera que dejen de funcionar.
Los agentes pueden acceder a datos privados de otros agentes para los que no tienen
autorización.
Nuestro modelo asume que un agente inicia su recorrido desde una agencia segura, y
aunque es posible, y de hecho bastante probable, que el agente requiera migrar a otras
agencias para llevar a cabo sus tareas y conseguir sus objetivos. Ello implica que el agente
debe asegurarse que cada una de las agencias a las que migra, y por tanto visita, son
confiables, previamente antes de realizar la migración en sí. Nuestro mecanismo se basa
en proteger el proceso de migración de los agentes móviles. Se puede evidenciar que está
especialmente diseñado para este tipo de tecnología, aunque puede ser extendido para
otros fines.
En este mecanismo, cada agencia dispone de una serie de valores almacenados que
determinan el estado de su configuración, a partir de los cuales se puede realizar una
estimación de si el estado de la agencia es confiable o no. La manera en la que cada
agencia obtiene y reporta estos valores es mediante el uso de funcionalidades del hardware
específico como se detalla a lo largo del presente capítulo.
Este hardware permite tomar ciertas medidas correspondientes al estado del sistema
y almacenarlas en registros internos del dispositivo, siendo únicamente accesibles median-
te las funcionalidades ofrecidas por el mismo. Los valores medidos son almacenados de
manera segura en el interior del propio hardware por lo que no pueden ser accedidos y
ni modificados sin autorización. De esta forma las agencias pueden comunicar los valores
de configuración previamente almacenados a otras agencias para que estas puedan de-
terminar su grado de seguridad. Siguiendo esta metodología, un agente antes de migrar
solicita a la agencia en la que se encuentra que determine la confiabilidad de la agencia
destino. Con lo cual un agente que se encuentra en una agencia que considera segura,
puede extender el ámbito de confianza incluyendo otra agencia, una vez comprobado que
es segura.
Un módulo de plataforma confiable (TPM) se comporta de la forma esperada para un
propósito particular [31]. Entre las múltiples funcionalidades que nos ofrece esta tecno-
logía estamos interesados en tres aspectos del Trusted Computing, la atestación remota,
la clave encadenada al estado y el aislamiento. La atestación remota es el proceso por
el cual una plataforma declara su estado de operativo de entorno/software actual y es
almacenado en un conjunto de registros dedicados del hardware confiable llamados “regis-
tros de configuración de plataforma” (Platform Configuration Registers “PCRs”). La clave
encadenada es el proceso mediante el que se pueden usar los datos únicamente si el estado
de la plataforma encaja perfectamente con un valor predefinido. Por último el aislamien-
to se refiere al soporte tanto hardware como software necesario para aislar la ejecución.
Recordamos al lector que los tres los tres mecanismos están perfectamente descritos en el
capítulo 2.
Los primeros trabajos en la aplicación de hardware confiable como método de protec-
ción de sistemas de agentes móviles se le atribuyen a Wilhelm en sus trabajos basados en
el uso de terceras partes confiables en los hosts de los sistemas [41]. A pesar de ser una
gran idea teórica, en su tiempo parecía demasiado futurista.
mecanismo de migración segura de agentes para JADE, de tal manera que el agente
pueda extender su límite de confianza añadiendo agencias seguras, tanto dentro de su
plataforma como de otras plataformas remotas [50] y [51].
Antes de continuar con este estudio hacemos referencia a ciertos aspectos que asumi-
mos como ciertos. En primer lugar, cada agencia contiene un módulo TPM instalado y
funcionando de forma correcta. Además el sistema operativo de esta agencia tiene soporte
para el uso de este hardware específico. En el inicio autenticado del sistema, una vez que la
máquina en la que está alojada la agencia es puesta en funcionamiento se toman medidas
del estado de la misma y se almacena en los PCRs del TPM. Se ha de tener confianza en
la plataforma en la que actualmente se está ejecutando el agente, en otras palabras, esta
plataforma ha de considerarse confiable.
Cualquier información estática del agente ha de estar firmada digitalmente por la
plataforma de origen del agente. La consistencia de los registros viene caracterizada porque
el uso de los PCRs para el almacenamiento de las medidas representativas del estado de
la plataforma ha de ser consistente con el resto de plataformas del sistema, aunque como
veremos más adelante, esta condición puede resultar muy rigurosa. Por último, hemos de
considerar que cada plataforma tiene asociada el uso de al menos una de las AIKs con
una CA privada que es conocida para todas las agencias confiables del sistema.
Como se describe en el capítulo 2, un sistema JADE está compuesto por una plata-
forma que contiene un contenedor principal, en el cual se despliegan los agentes. A esta
plataforma pueden añadirse contenedores adicionales, que podrían ser remotos y, a su vez,
diferentes plataformas tendrán la capacidad de interactuar entres sí, permitiendo así que
los agentes transiten de unas a otras. Por lo tanto, en JADE los contenedores jugarían el
papel de agencias sobre las que desplegar los agentes.
Para solucionar los problemas de seguridad en sistemas de agentes sobre la plataforma
JADE, hemos desarrollado una librería que permite a los agentes realizar la migración de
manera segura. Para ello la librería comprueba si el contenedor destino es seguro y lleva
a cabo la migración únicamente si puede confiar en la agencia destino.
También hemos de considerar el hecho de que cada agencia debe ofrecer cierta funcio-
nalidad local que permita a un agente migrar de manera segura a una plataforma destino.
Asimismo, cada agencia deberá ofrecer la posibilidad a que cualquier otra agencia del
sistema verifique que efectivamente es confiable. Hemos obtenido como resultado una li-
brería que implementa un protocolo que permite a una agencia intercambiar información
sobre su configuración con otra agencia, de manera que cada una de las agencias tenga
certeza de que la información proviene realmente de la agencia que la proporcionó. La
complejidad del problema provoca la aparición de soluciones bastante ineficientes basadas
en el uso de elementos software, por lo que nos planteamos el uso de hardware criptográ-
fico específico. Como indicamos anteriormente usamos un TPM, puesto que nos facilita,
en gran medida, la tarea de establecer un entorno seguro, permitiendo además almacenar
valores de la configuración de las agencias y comunicar de manera segura dichos valores
a las agencias que lo soliciten.
Hemos identificado una serie de características deseables de nuestra solución. Como
objetivo adicional, que consideramos de relativa importancia, tenemos la posibilidad de la
integración de nuestra solución en las plataformas actuales. En concreto dentro del marco
de la plataforma JADE, es decir, el mecanismo ha de resultar fácil de integrar en cualquier
solución existente basada en JADE. De forma que la utilización de nuestra solución no
implique modificaciones drásticas a la misma. Con idea de obtener un uso más extendido
de nuestra solución a medio plazo vista.
Otra característica importante de nuestra solución es la transparencia, de forma que el
funcionamiento de la librería no debe ser visible al usuario. No debemos de olvidarnos de
la genericidad, que es otra característica deseable que proporciona nuestra librería. Como
en cualquier solución de seguridad aplicada a sistemas distribuidos, la escalabilidad es
imprescindible, máxima si pensamos en el campo de aplicación que tienen los sistemas
basados en agentes en los emergentes sistemas de computación ubicuos. Por último, la
librería debe ser extensible, es decir, ha de permitir la introducción de futuras de mejoras
y ampliaciones de una forma sencilla y eficiente.
El resultado final es una librería que tiene como objetivo dotar de seguridad a los
sistemas de agentes móviles desarrollados con JADE, basado en la implementación de
un mecanismo de migración seguro. Esta migración segura se consigue mediante la com-
probación de la confiabilidad de la agencia destino antes de llevar a cabo la migración,
lo que permite que el agente se ejecute siempre en un entorno confiable. Por otra parte,
la librería debe integrarse en alguna de las plataformas de agentes que se están usando
actualmente.
Entre las distintas opciones nos decantamos por implementarla sobre JADE. Tras un
estudio de las alternativas observamos que JADE es la plataforma más utilizada por la
comunidad de desarrolladores de agentes. Parece obvio que para que la librería tenga una
acogida relevante en la comunidad de agentes es necesario que la utilización de la misma no
implique realizar modificaciones drásticas a la plataforma. La librería facilita la adaptación
de sistemas existentes para que hagan uso de los mecanismos de seguridad implicando
esto modificaciones mínimas. Así nuestra librería proporciona un mecanismo genérico, de
De aquí obtenemos que los casos de uso que definen la librería serían los que aparecen
en el diagrama de la figura 3.4.
En el diagrama se observa que existen dos casos de uso desde el punto de vista del
agente que representan la funcionalidad que ofrece la librería. Sin embargo, desde nuestro
punto de vista ambos son similares y la forma en que finalmente se realiza la migración
no es relevante. Como se ha comentado, vamos a explotar las distintas funcionalidades
que nos proporciona el TPM en nuestra librería. Concretamente, nos vamos a centrar en
el establecimiento de una raíz de confianza sobre la cual ejecutamos nuestro software.
En la figura 3.5 vemos un diagrama de clases que muestra cómo cada agencia puede
alojar varios agentes y dispone de las funcionalidades de un TPM. El TPM juega el papel
de elemento seguro dentro de la agencia, permitiendo que esta pueda demostrar a otras
agencias que es confiable [19].
Vamos a ver el camino seguido para obtener nuestro protocolo de migración segura,
para ello vamos a analizar con detalle una serie de protocolos que nos permiten la elabo-
ración de un nuevo protocolo que reúna las características apropiadas para que la librería
proporcione la seguridad necesaria en el proceso de migración. Como anteriormente co-
mentábamos, a partir de este momento usaremos el término migración para referirnos
tanto al desplazamiento como a la clonación de los agentes, ya que desde el punto de vista
de los protocolos analizados ambos son equivalentes.
En principio, contemplamos el uso de un dispositivo hardware de seguridad genérico,
sin cerrarnos las puertas al uso de uno determinado, para conseguir entornos seguros de
ejecución de los agentes móviles, por medio de la protección del propio proceso de migra-
ción. Aunque como indicamos anteriormente, para el desarrollo de la solución tuvimos que
hacer una elección, siendo el TPM el seleccionado. Analizamos el primer protocolo para
obtener la información de la configuración de una plataforma concreta de forma remota.
El protocolo de la figura 3.6 muestra los pasos a realizar para migrar de manera segura
a una agencia destino. Estos pasos son los siguientes:
1. El agente ag1 solicita a la agencia A1 que verifique si la migración a la agencia A2
es segura según unos requisitos (A2req).
2. A1 en colaboración con su TPM (tpm1), contacta con el TPM de la plataforma
destino (tpm2) y obtiene la configuración de la misma(A2conf).
3. Se analiza la configuración de la agencia A2 para ver si cumple los requisitos esta-
blecidos.
4. Si los requisitos se cumplen el agente ag1 migra a la agencia A2.
Se asume que el agente debe confiar en su plataforma, para permitir así la compro-
bación de la seguridad de la migración. Consideramos interesante mencionar el hecho de
que esto coincide con la filosofía de Trusted Computing, en la cual se parte de una raíz de
confianza para ir extendiendo el límite de confianza en base a los procesos de atestación.
Otra base importante que aparece en este protocolo es el uso de un TPM para que la ob-
tención y comunicación de los valores de configuración se realice de manera segura, ya que
las funcionalidades ofertadas por este encajan perfectamente con nuestras necesidades.
Puesto que hasta este punto teníamos claro que el uso de un hardware criptográfico
era necesario para implementar este modelo de migración segura, se decidió estudiar a
fondo la especificación de Trusted Computing Group. En el TGC Specification Archi-
tecture Overview [52], encontramos un documento que muestra una visión general de la
arquitectura propuesta por el TCG.
Figura 3.6: Descripción a alto nivel de la primera versión del protocolo de migración
segura.
Entre las ideas más relevantes que aporta a nuestra solución resaltamos el hecho de que
un agente de la agencia, usando el TPM, obtiene los valores firmados de los registros PCR.
Estos registros PCR forman parte del TPM y el valor almacenado en ellos es el resultado de
aplicar una función hash que toma como entrada información momentánea del estado del
sistema. En esta información se tiene constancia de las aplicaciones que están en ejecución
en dicho instante y la secuencia de activación de las mismas entre otras cosas. Por otro
lado, el protocolo muestra también la forma en que el agente obtiene las credenciales de
la plataforma, que junto con los valores firmados de los PCR permiten determinar si la
configuración de la agencia destino es confiable o no y por tanto determinar la seguridad
del proceso.
La idea del uso de credenciales es interesante, ya que unas credenciales certifican que
los valores PCR firmados pertenecen a la agencia que se toma como objeto de atestación.
Basándose en el mismo principio que una PKI. De este modo podemos considerar que
las credenciales se usan para autenticar a la agencia, mientras que los registros PCR
atestiguan el estado de la misma. Para entender la utilidad de estas credenciales vamos a
ver dos protocolos que nos permiten realizar una atestación remota de la configuración.
El primer protocolo, es un protocolo de atestación bidirecciónal. Este hace uso de una
Autoridad de Certificación (Certification Authority, CA). Vemos una descripción de cada
uno de los pasos del protocolo.
4. La agencia destino verifica los datos firmados que ha recibido usando la clave pública
de la AIK.
9. La agencia origen verifica los datos firmados que ha recibido usando la clave pública
de la AIK.
10. La agencia origen verifica que los valores de configuración recibidos se encuentran
dentro del conjunto de valores aceptados y que, por lo tanto, la configuración de
la agencia origen es confiable. En este momento existe una relación de confianza
mutua entre las agencias.
4. La agencia destino verifica los datos firmados que ha recibido usando la clave pública
de la AIK.
6. La agencia destino solicita los datos firmados de su configuración haciendo uso del
TPM.
9. La agencia origen verifica los datos firmados que ha recibido usando la clave pública
de la AIK.
10. La agencia origen verifica que los valores de configuración recibidos se encuentran
dentro del conjunto de valores aceptados y que por lo tanto la configuración de la
agencia origen es segura. En este momento existe una relación de confianza mutua
entre ambas agencias.
4. Junto con los valores firmados de los PCR la agencia proporciona las credenciales de
la AIK para que el solicitante pueda verificar correctamente que los datos provienen
del TPM de la agencia.
3. La agencia destino acepta la petición y envía un nonce (valor compuesto por bits
aleatorios usados para evitar ataques de repetición) y los índices de los PCR cuyos
valores desea conocer.
4. La agencia origen utiliza su TPM para obtener los valores de los PCR solicitados
por la agencia destino junto con el nonce todo en un valor de firma.
8. La agencia destino verifica la firma de los valores de los PCR y el nonce que ha
recibido usando la clave pública de la AIK.
Figura 3.8: Descripción del protocolo de migración segura basado en el uso de una CA.
9. La agencia destino verifica que los valores de los PCR recibidos se encuentran dentro
del conjunto de valores aceptados y que por lo tanto la configuración de la agencia
origen es segura.
10. La agencia destino usa su TPM para obtener la firma de los valores de los PCR
solicitados por la agencia origen junto con el valor de nonce.
12. La agencia destino envía a la agencia origen la firma completa junto con las creden-
ciales de la AIK, que contienen la clave pública correspondiente a la clave privada
con la que se firmaron los datos.
13. La agencia origen valida la autenticidad de la clave recibida verificando las creden-
ciales mediante la clave pública de la CA que generó dichas credenciales.
14. La agencia origen verifica la firma de los valores de los PCR y el nonce que ha
recibido usando la clave pública de la AIK.
15. La agencia origen verifica que los valores de los PCR recibidos se encuentran dentro
del conjunto de valores aceptados y que por lo tanto la configuración de la agencia
destino es segura. En este momento existe confianza mutua entre ambas agencias.
16. La agencia origen concede al agente la migración hacia la agencia destino solicitada.
Este protocolo cumple con los requisitos que mencionábamos al inicio del presente
capítulo. Por esta razón basamos nuestra solución en la seguridad proporcionada por este
protocolo.
Antes de continuar esta investigación hicimos un alto en el camino y nos replanteamos
las bases sobre las que habíamos creado nuestra solución, con idea de identificar posibles
puntos débiles y así poder reforzarla, en caso de que fuese posible, o plantear una nueva
alternativa si fuera necesario. Para ello decidimos someter a nuestro protocolo a un proceso
de estudio y validación formal que hemos descrito en este capítulo.
con lo cual este ataque queda frustrado. Es evidente que el hecho de disponer de una
agencia en la que se pueda ejecutar el agente es un requisito indispensable, precisamente
por su obviedad consideramos trivial este caso.
Asumimos que estamos en entornos muy restringidos de operación, de forma que vamos
a acotar la ejecución para evitar que se pueda dar el caso de que se ejecute otra agencia con
propósitos ilícitos en el mismo momento evitamos la ejecución simultánea de otro software
que no sea el de la agencia confiable junto con el Sistema Operativo. Para ello nuestro
Sistema Operativo interviene en la cadena de confianza, de forma que realiza una operación
PCRQuote en la cual se toma la medida de los PCRs que va a ser válida para la posterior
ejecución. Esta funcionalidad proporcionada por el TPM resulta de gran utilidad puesto
que permite almacenar el estado actual del sistema en estos registros internos del TPM,
conocidos como PCRs. El estado del sistema viene caracterizado tanto por el hardware
como por el software del sistema, considerando relevante el orden secuencial de instalación
de cada uno de los componentes software.
En realidad, esto supone una restricción muy importante en el uso, y más aún para
sistemas tan versátiles como son los basados en agentes. Puesto que ello implica que cada
una de las agencias debe tener el mismo software y en el mismo orden secuencial de insta-
lación. En ciertos casos se puede proporcionar un conjunto muy reducido de posibilidades,
por lo que nos planteamos otras formas para proporcionar un mayor grado de flexibilidad.
La siguiente estrategia permite incrementar el grado de flexibilidad de la atestación,
esta consiste en establecer una lista de software “confiable” que podamos ejecutar de forma
simultánea. Obviamente, esto acarrea una serie de inconvenientes, entre los que destaca-
mos el hecho de que tendremos muchas combinaciones distintas posibles de software. Este
número se ve ingentemente incrementado si se considera relevante la secuencia de los
mismos, puesto que esto queda reflejado a la hora de tomar las medidas de los PCRs y
la producción de la firma con el uso del TPM. No obstante, esto nos permite tener un
conjunto de valores de QUOTEs válidos. Sin embargo, esta solución también es bastante
limitada, puesto que el software a usar está muy restringido, lo cual no es conveniente
para situaciones reales. Por ello nos planteamos un paso más avanzado consistente en
tomar las medidas de PCRs necesarias para evitar que dos agencias puedan ejecutarse de
forma simultánea en la misma máquina, lo cual puede resultar una restricción muy fuerte,
especialmente si una de ellas no es confiable. Tomamos medidas de PCRs y averiguamos
cuáles son los valores de la agencia confiable, y cuáles los de la agencia no confiable. Se
mantiene un conjunto de valores posibles de PCRs que se ha demostrado confiable y lo
único que habrá que realizarse es una comprobación del valor a medir en este conjunto.
Aunque se están estudiando otras alternativas para dar solución a este problema. La
más avanzada se basa en el uso de entornos virtualizados, entre los cuales las características
del software y su secuencialidad pueden ser idénticos.
Otra iniciativa que nos planteamos está relacionada con un posible cambio de estado
del sistema que implique una pérdida en la confiabilidad de la agencia destino. Para
ilustrar este problema proponemos el ejemplo dado por la migración segura entre agentes
que hemos diseñado. Se realiza la comprobación de la migración posible, a continuación
se chequea que efectivamente todo funciona de forma correcta y se informa desde la
agencia destino a la agencia origen que la migración se puede iniciar (paso 14 de nuestro
protocolo). El ataque viene producido por que en ese preciso instante, un usuario con
intenciones maliciosas suplante la agencia con código confiable y se pone en marcha la
ejecución de otra agencia con intenciones maliciosas. Esta nueva agencia, con carácter
malicioso, podría pretender manipular al agente y obtener así algún tipo de beneficio de
esta práctica. Hasta este punto es el mismo problema descrito anteriormente. Sin embargo,
para solucionar este problema nos planteamos una solución más elegante, mediante la
introducción de una nueva estrategia de protección. Esta nueva estrategia consiste en la
protección de los propios agentes haciendo uso de una funcionalidad específica que nos
proporciona el TPM. La idea radica en el cifrado de parte del código del agente con una
clave generada en el TPM de la plataforma destino, de manera que esta quede ligada a
cierto valor de PCR, así en el supuesto de que las medidas tomadas no coincidan con los
valores de PCRs no se permitirá la ejecución del agente, puesto que el agente no está en
claro y no se puede lanzar.
El proceso se describe de la siguiente manera. Tenemos el agente ag que migra de la
agencia origen (O) a la agencia destino (D) y tenemos el TPM de la Agencia destino (T).
3.3. Evaluación
En esta sección presentamos la validación del trabajo realizado hasta el momento.
Este análisis lo hemos realizado a dos niveles distintos. En primer lugar, hemos llevado
a cabo un análisis formal de los protocolos que intervienen en nuestra solución, que se
han modelado mediante una herramienta de verificación formal. En segundo lugar, hemos
analizado la implementación de la librería en sí, mediante un estudio del código y se han
probado en escenarios reales.
Lamport.
Todas las comunicaciones que se realizan en AVISPA son síncronas y el mecanismo
de funcionamiento es el siguiente: El protocolo expresado en HLPSL es traducido a un
formato intermedio denominado IF (Intermediate Format). En este paso intermedio se
reescriben las reglas aplicadas para procesarlas en un paso posterior del proceso, de forma
que un protocolo escrito en este lenguaje intermedio se ejecuta mediante un número de
iteraciones finito, a menos que se encuentre algún bucle que se deba a algún tipo de ataque.
En el caso de no existir tal bucle, se considera que el protocolo es seguro, al menos en
el número de iteraciones indicadas. El comportamiento del sistema en HLPSL se modela
como un estado. Cada estado tiene variables que son las responsables de las transiciones.
Así cuando una de estas variables cambia, el estado toma una nueva forma. Por otro
lado, las entidades que se comunican son denominadas roles, y poseen variables propias.
Estas variables pueden ser de ámbito local o global. Aparte de la entidad iniciadora y la
receptora, el entorno y la sesión del protocolo de ejecución son modelados como roles en
HLPSL. Los roles pueden ser básicos o compuestos, en función de si están formados por un
agente o por más. Cada participante honesto o parte principal tiene un rol, este puede ser
paralelo, secuencial o compuesto. Toda comunicación entre roles e intruso son síncronas,
como antes se comentaba. Los canales de comunicación se representan por variables que
contienen propiedades de un entorno en concreto.
El lenguaje usado en AVISPA es muy expresivo y permite describir detalles de un
grano muy fino. Una de las ventajas principales de este conjunto de herramientas es que
los resultados en AVISPA están detallados y se obtienen tras un número alcanzable de
estados [53]. Por lo tanto, la interpretación de estos resultados no requiere de una destreza
ni un aprendizaje profundo de la herramienta en sí, a diferencia de otras herramientas
similares existentes, como es el caso de HERMES[54], en las que se requiere una destreza
contrastada para la obtención de conclusiones.
El conjunto de herramientas de AVISPA nos proporciona cuatro motores de ejecu-
ción distintos. El primero de ellos se conoce como On-the-fly Model-Checker (OFMC)
[55] que lleva a cabo una falsificación del protocolo y una verificación ligada mediante
la exploración del sistema de transición descrito por la especificación IF, es importante
destacar que se realiza de una forma dirigida por demanda. OFMC implementa cierto
número simbólico de técnicas correctas y completas. Además soporta la especificación de
las propiedades algebraicas de operadores criptográficos y modelos tanto tipados como
no-tipados. El segundo de ellos se conoce como el Constraint-Logic-based Attack Searcher
(CL-AtSe) que se basa en aplicar restricciones tal y como se muestra en [53], es intere-
sante la capacidad de reducir la redundancia y la simplificación heurística. CL-AtSe se
construye de forma modular y está abierta a extensiones para el manejo de propiedades
algebraicas de operadores criptográficos. El tercer motor se conoce como el SAT-based
Model-Checker (SATMC) [56] que se basa en la construcción de una fórmula proposicio-
nal que codifica una relación de transición especificada por el IF, se representa el estado
inicial y el conjunto de estados que representan una violación a las propiedades de seguri-
dad. Por último el TA4SP (Tree Automata based on Automatic Approximations for the
Analysis of Security Protocols) [57] que realiza una aproximación del conocimiento del
intruso mediante la construcción de un árbol.
En nuestra validación hemos utilizado el modelo OFMC dado que es el único que
utiliza valores nuevos para la generación de los nonce’s. Un nonce, es una cadena de bits
que se genera una única vez, es un mecanismo usado en algunas técnicas criptográficas
para evitar ciertos ataques basados en repetición.
A continuación vemos un ejemplo del código en HLPSL utilizado para la verificación
del protocolo de migración seguro basado en el uso de una CA que hemos desarrollado
para nuestro propósito, además de una explicación de los resultados obtenidos [58].
En el modelo HLPSL de nuestro protocolo hemos definido varios roles, agent, agency_A,
agency_B, TPM_agency_A, TPM_agency_B y environment. El rol agent tiene dos es-
tados distintos; 0 para dar comienzo a la migración, y 1 para realizar la migración en sí.
El modelo del agente es como sigue.
El código muestra cómo el conjunto de transiciones está formado por tres únicos
estados. El primero de ellos, caracterizado como estado 0 recibe la señal de comienzo y
envía migrar al rol origen (O) y pasa al segundo estado de este rol (estado 1). El segundo
estado espera a recibir el mensaje de migración del agente y pasa al tercer estado (estado
2).
El siguiente rol modela la Agencia origen de nuestro protocolo de migración segura.
Este tiene como parámetros a la agencia origen (O), la agencia destino (D) el agente (Ag),
el TPM de la plataforma de origen y los canales de envío y recepción. Consta de cuatro
estados que comentamos a continuación.
role agency_O(O,D,Ag,TPM_O:agent,SND,
RCV:channel(dy)) played_by O
def=
local
State : nat,
Nonced,Nonceo : message,
Value : message,
Pcrid : nat set,
AIKod,AIKdo : public_key,
TrustsetO : message set
const
migrate,remoteattestrequest,remoteattestagree,
getconfig : protocol_id,
getCredentials : public_key -> message,
hashf : hash_func,
pcria : message,
pcra,pcrb : message->message
init
TrustsetO := {pcrb(pcrio)} /\ State := 0
transition
1.State = 0 /\ RCV(migrate.O) =|>
SND(remoteattestrequest.D) /\ State’ := 1
2.State = 1 /\ RCV(remoteattestagree.Nonced’.
Pcrid’.O) =|>
SND(getconfig.Nonced’.Pcrid’.TPM_O) /\ State’ := 2
Para finalizar, cuando el flujo del programa esté en el estado 3 y se reciba la información
correspondiente, comprobando que los pares de claves son correctos se procederá a enviar el
mensaje de migrar el agente (migrate.Ag). La agencia destino del protocolo se modela por
medio del rol agency_D, que como vemos es simétrico al anterior y no vamos a entrar en
redundancia con más repetición del mismo mecanismo. Únicamente cabe resaltar el hecho
de que el último paso solamente tendrá sentido para el rol correspondiente a la agencia
origen, puesto que la agencia destino no tiene la capacidad de conceder la migración al
agente.
\scriptsize
\begin{verbatim}
role agency_B(O,D,TPM_D:agent,SND,
RCV:channel(dy)) played_by D
def=
local
State : nat,
Nonced,Nonceo : message,
Value : message,
Pcrio : nat set,
AIKod,AIKdo : public_key,
TrustsetD : message
const
migrate,remoteattendrequest,remoteattestagree,
getconfig:protocol_id,
getCredentials : public_key->message,
hashf : hash_func,
pcrid : message,
pcro,pcrd : message->message
init
TrustsetD := {pcro(pcrid)} /\ State := 0
transition
1.State = 0 /\ RCV(remoteattendrequest.
O) =|> Nonced’:=
new() /\ SND(remoteattestagree.Nonced’. pcrib.O) /\
State’ := 1
2.State = 1 /\ RCV(Value’.Nonced.
{hashf(Value’)}_inv(AIKod’).
AIKod’.getCredentials(AIKod’).
Nonceo’.Pcrid’.D)/\
in(Value’,TrustsetD) =|>
SND(getconfig.Nonceo’.
Pcrio’.TPM_D) /\ State’:=2
3.State = 2 /\ RCV(pcrd(Pcrio).
Nonceo.{hashf(pcrd(Pcrio).
Nonceo)}_inv(AIKdo’).AIKdo’.
TPM_D) =|>
SND(pcrd(Pcrio).Nonceo.
{hashf(pcrd(Pcrio).
Nonceo)}_inv(AIKdo).AIKdo’.
getCredentials(AIKdo’).O)
end role
se reciba una petición por el canal de entrada. A continuación tenemos el modelado del
rol del TPM de la agencia destino, que es análogo al anterior, por lo que no entramos en
más detalle.
role tpm_Agent_D(D,TPM_D:agent,
SND,RCV:channel(dy)) played_by TPM_D
def=
local
State : nat,
Noncea : message,
Pcria : nat set
const
getconfig : protocol_id,
pcrb : message -> message,
aikba : public_key,
hashf : hash_func
init
State := 0
transition
1.State = 0 /\ RCV(getconfig.
Nonceo’.Pcrio’) =|> SND(pcrd(Pcrio’).
Nonceo’.{hashf(pcrd(Pcrio’).Nonceo’)}_inv(aikdo).
aikdo.O) /\ State’ := 1
end role
role session(O,D,TPM_O,TPM_D,Ag:agent)
def=
local SND1,SND2,SND3,SND4,SND5,RCV1,
RCV2,RCV3,RCV4,RCV5:channel(dy)
composition
agent(O,Ag,RCV1,SND1)/\ agencyO(O,D,Ag,
TPM_A,SND2,RCV3)
/\ agency_B(O,D,TPM_D,SND3,RCV3)
/\ tpm_Agent_A(O,TPM_O,SND4,RCV4)
/\ tpm_Agent_B(D,TPM_D,SND5,RCV5)
end role
Por último, tenemos la codificación del rol que describe el proceso completo. Hemos
llamado a este rol “environment”, encargado de orquestrar todos los roles previamente
descritos. Este rol es indispensable para realizar la validación usando AVISPA.
role environment()
def=
const
o,d,tpm_o,tpm_d,ag:agent
intruder_knowledge = {o,d,tpm_o,tpm_d,ag,hashf}
composition
session(o,d,tpm_o,tpm_d,ag)
end role
environment()
En el modelo de atacante que hemos incluido, este no conocerá las claves generadas
en los propios TPMs ni tampoco es capaz de obtener información de las operaciones de
cifrado y descifrado realizadas por el dispositivo. Una vez ejecutamos este código con las
herramientas proporcionadas por AVISPA obtenemos los siguientes resultados.
SUMMARY
SAFE
DETAILS
BOUNDED_NUMBER_OF_SESSIONS
PROTOCOL
/home/anto/avispa/testsuite/protocolo_2.txt.if
GOAL
as_specified
BACKEND
OFMC
COMMENTS
STATISTICS
parseTime: 0.00s
searchTime: 3.23s
visitedNodes: 4 nodes
depth: 200 plies
environment()
Figura 3.12: Diagrama UML del circuito de refrigeración del sistema de monitorización.
En la ilustración 3.13 aparece un diagrama en UML con las clases que componen la
parte de seguridad del sistema completo “Seguridad” y “Gestión de Residuos Radiactivos”
son las clases principales. La primera de ellas contiene “ProtecciondelReactos”, “Barreras-
deContencion” y “Software”.
Todo este sistema está desarrollado sobre la base de SecMiLiA descrita a lo largo de
este capítulo. Defendemos la teoría de que para este tipos de sistemas críticos el uso de
hardware criptográfico específico aporta un nivel de seguridad elemental que consideramos
que es imprescindible para un sistema de estas características. Obviamente, las pruebas
realizadas con este sistema las he llevado a cabo mediante el desarrollo de un simulador,
dadas las condiciones específicas de este tipo de sistemas.
La aplicación de SecMiLiA en la protección de este sistema es directa. Para cada uno
de los agentes descritos hemos creado instancias de la clase SecureAgent en lugar de los
tradicionales de la clase agent Agent. La otra modificación que se ha tenido que realizar es
cambiar la invocación a migrate() por securemigration(). Evidentemente, antes de realizar
estos pasos se ha tenido que comprobar, en primer lugar la instalación correcta de JADE,
seguidamente la del TPM y por último la de SecMiLiA.
Aplicar una autoridad de revocación de host (HoRA.) Otra propuesta que nos
planteamos consiste en aplicar una autoridad de revocación de host. Esta propuesta con-
siste en la penalización de Agencias, una vez detectado su uso indebido en el sistema.
Esta propuesta tiene una serie de limitaciones. Ya que se puede dar el caso de que ocurra
un error no intencionado durante la ejecución de un agente, lo cual puede provocar que
una agencia sea revocado. Aunque en múltiples ocasiones esto puede ser un castigo des-
proporcionado. HoRA podría aplicar políticas de castigo más relajadas ya que es dicha
entidad la que controla quien debe ser revocado y quien no, e incluso revocar a los hosts
en función de la gravedad de los ataques o el beneficio obtenido por los hosts maliciosos.
Otra limitación radica en que la base de datos interna de HoRA crece indefinidamente, ya
que no se eliminan nunca los hosts revocados, lo cual es necesario para que HoRA pueda
controlar todo el historial de hosts revocados. En particular, se asume que la capacidad de
almacenamiento de la HoRA no debe ser una limitación para el sistema, ya que se trata
de un servidor cuya tarea principal es el alamcenamiento y gestión de la base de datos.
Otro aspecto es el problema planteado por la confidencialidad de los datos en ejecución. A
pesar de que HoRA debe considerarse una entidad de confianza, en caso de revocación se
le deben enviar los datos confidenciales. La dificultad que puede tener HoRA para realizar
alguna escucha de dicha información depende en gran medida del mecanismo de detección
utilizado.
4.1. Introducción
El objetivo principal de este capítulo es el de describir el problema de la seguridad de
los sistemas multiagentes (compuestos por agentes cooperativos), además de presentar una
solución al mismo. En nuestro caso, proporcionamos una solución basada en la protección
mutua entre todos los agentes del sistema, utilizando para ello ciertos elementos software
que describimos en las siguientes líneas.
Nuestra propuesta consiste en forzar que cada agente del sistema actúe como protector
de otro. Entrando en más detalle en el mecanismo de protección, podemos decir que
cada agente se encarga de ejecutar parte del código de otro (agente al que protege).
De esta forma, un ataque al sistema sólo sería efectivo mediante un ataque a todos los
97
Protección basada en Computación Protegida
agentes que componen el mismo, es decir, una confabulación entre todas las agencias que
intervienen contra el sistema global. En la práctica, este tipo de ataques no se producen
en un sistema real, ya que en la mayoría de los casos los intereses de cada agencia son
diferentes (frecuentemente las agencias compiten entre sí) y por tanto carece de sentido
que tales agencias se asocien para atacar al sistema.
La figura 4.1 ilustra la idea de la protección mutua entre agentes, en ella se muestra
cómo cada agente protege a otro y es protegido a su vez por un tercer agente. La idea es
que en este esquema subyace un grafo euleriano. Recordamos que la definición de grafo
euleriano corresponde con un grafo dirigido en el cual se recorren todas y cada una de
las aristas del grafo una única vez, existiendo un camino o ciclo euleriano, que a su vez
se define como un ciclo que contiene todas las aristas de un grafo una única vez, es decir,
cada uno de los agentes del sistema ha de proteger a otro agente y este ha de ser protegido,
a su vez, por otro agente del mismo y distinto del anterior, a excepción de tratarse de un
sistema con dos únicos agentes que evidentemente es un caso trivial.
Así el esquema de protección que se establece entre tres agentes se realiza de tal forma
que el agente1 es protegido por el agente3, y a su vez, el agente1 protege al agente2. Así
ocurre sucesivamente con los demás agentes del sistema, siendo este esquema escalable
a cualquier número de agentes para cualquier sistema sin que ello implique una mayor
complejidad. Destacamos la escalabilidad de este modelo, puesto que nuestro sistema
funcionaría de forma correcta sin depender del número de agentes del sistema. Toda la
comunicación se realiza mediante el paso de mensajes por la red.
Obviamente, el hecho de que un agente proteja a otro y a su vez sea protegido por otro
distinto conlleva una serie de consideraciones. En nuestra solución hemos hecho uso de
la técnica conocida como “computación protegida”. Esta técnica tiene como fundamento
la división del código en dos o más partes, de forma que las partes son ejecutadas en
procesadores distintos. Evidentemente, la división del código ha de realizarse con ciertos
requisitos que describimos a continuación. La parte que consideremos como código privado,
que se ejecutará en un procesador seguro (en el sentido de que no es accesible al atacante),
que no está bajo el dominio del usuario, no puede ser derivada a partir del código que
se ejecuta en la parte pública. Por tanto, el código etiquetado como público no podrá
aportar información de la parte de código privado.
Otra característica de esta solución es que la ejecución total del código necesita la
finalización de la ejecución de ambas partes. En nuestro caso particular, hemos aplicado
esta técnica para dividir el código de los agentes móviles que componen nuestro sistema.
Una vez aplicada la técnica obtendremos una nueva versión de los agentes que estarán
compuestos por la parte pública de su propio código y por una parte privada de código
perteneciente a otro agente al que protegen. De la misma forma, otro agente tendrá la
parte privada de este agente, constituyéndose así como agente protector de este.
En la figura 4.2 se muestra la transformación que sufre el código mediante el uso
de la computación protegida. Durante esta etapa el código se transforma con objeto de
protegerlo frente a un posible ataque por ingeniería inversa. Hacemos especial énfasis
en que la “computación protegida” no depende de los detalles específicos de esta etapa,
en el sentido de que cualquier esquema que ofrezca como resultado una aplicación con la
estructura mostrada en la figura 4.2, que sea equivalente funcionalmente a la original y con
una serie de secciones traducidas al código ejecutable por el procesador confiable, podría
ser usado aplicando esta técnica. De hecho, esta técnica se diseñó con independencia del
tipo de procesador seguro usado. Por lo que el esquema es equivalente tanto si hacemos
uso de un TPM, de una tarjeta inteligente de cualquier tipo, e incluso, como ocurre en
nuestro caso, si hacemos uso de los propios agentes software.
Continuamos con la descripción de esta técnica. La etapa de transformación se realiza
una única vez para cada agente protegido. Sin pérdida de generalidad, y con objeto de
facilitar la descripción del proceso, consideraremos que un código de un agente se compone
de una serie de secciones, que incluyen tanto instrucciones como datos.
Profundizando en la etapa de transformación. El primer paso de esta fase consiste
en la identificación y selección de ciertas secciones del software original que se van a
proteger. En esta fase se identifican las secciones protegidas que son las más adecuadas
para ser ejecutadas en el procesador seguro. Esta identificación se realiza en función de
varios criterios, como son el tipo de instrucciones que contiene, la entropía que poseen,
etc. A continuación, en el esquema original, las secciones seleccionadas son traducidas
al lenguaje ejecutable por el procesador seguro. Sin embargo, en nuestro caso esto no es
necesario ya que todas las agencias son iguales, aunque es necesario un proceso de carga
adaptativo debido a que el código se carga directamente cifrado en el agente. Durante
el proceso de traducción también se realizan transformaciones de ofuscación. Estas son
variantes de algunas de las transformaciones de ofuscación más relevantes. Entre las que
destacamos:
Identificación de dependencias entre las secciones protegidas. Estas dependencias se
utilizan para determinar qué resultados parciales, dentro de una sección se pueden
mantener en el procesador seguro para ser utilizados por la siguiente sección.
La reorganización del código es muchas veces necesaria para conseguir secciones más
robustas o para evitar sobrecargar la ejecución en el procesador seguro.
Una vez realizados los procesos de ofuscación y traducción, las secciones a proteger
están preparadas para ser cifradas. Para ello utilizamos un criptosistema simétrico, que
usa una clave generada de forma aleatoria que debe ser almacenada de forma segura por el
productor de software. En el esquema original esta clave será utilizada con posterioridad
para producir la licencia durante la fase de autorización. Es importante mencionar el hecho
de que esto no será necesario en nuestro esquema. Las secciones protegidas se añaden al
código original del agente como datos. Como veremos más adelante, es posible incluso
prescindir del cifrado en algunas de nuestras soluciones, simplificando la aplicación de la
metodología y obteniendo excelentes resultados.
El último paso de esta fase consiste en la sustitución del código de las secciones que
han sido protegidas por llamadas a una función que se encarga de solicitar la ejecución de
la correspondiente sección en el agente protector. En la computación protegida, el software
resultante del proceso de protección realizado en esta fase puede ser distribuido y copiado
libremente sin necesidad de ninguna medida adicional de protección. Esta característica
nos ha servido como inspiración en el uso de esta técnica para la protección de agentes
móviles, puesto que estos viajan de agencia en agencia quedando expuestos a sus ataques.
Sin embargo, como antes mencionamos, para usar esta técnica es imprescindible dis-
poner de un procesador seguro. En nuestro caso este papel de procesador seguro lo desem-
peñará otro agente del sistema el que actúe como tal.
En el estudio de esta tesis se ha determinado una clara diferencia entre dos solucio-
nes distintas. La primera de ellas, es un método que denominamos de protección mutua
estática. En este esquema se asume que el número de agentes en el sistema es fijo y está
preestablecido antes de la ejecución del mismo. En el caso de que algún agente abandonase
el sistema, se abortaría su ejecución. Por tanto, los agentes conocen tanto a sus agentes
protectores como sus respectivos códigos de ejecución en tiempo de compilación. Este
hecho limita la adaptabilidad práctica del sistema resultante. La adición o eliminación
de un agente provocaría la necesidad de cambiar el código de toda la aplicación. Este
método se ha desarrollado completamente y es el núcleo de este capítulo y a pesar de sus
restricciones inherentes existen escenarios en los que obtenemos excelentes resultados en
su aplicación.
El segundo método es una evolución del primero, con las mejoras suficientes para
aportar un alto grado de dinamismo y más acorde con las necesidades reales. Lo hemos
denominado método de protección mutua dinámica. Esta solución es más compleja que
la anterior, pero proporciona más escalabilidad y cierta capacidad de reacción dinámica.
El grafo de protección entre agentes se puede modificar en tiempo de ejecución, de la
misma forma que también se puede modificar el código que ejecutan los mismos. Debido
a las restricciones de tiempo fundamentalmente, hay que establecer ciertos límites en la
investigación, por lo que hemos decidido desarrollar esta estrategia únicamente a nivel
teórico, dejando su implementación como trabajos futuros de esta tesis. En definitiva,
hemos diseñado el método y los protocolos de protección dejando como tarea futura la
implementación de la misma.
En la implementación de estos mecanismos hemos utilizando la plataforma de agentes
JADE, principalmente por el hecho de que esta plataforma sigue el estándar FIPA (véase
la sección 2.3.4), además de ser la más extendida en el momento actual en la comunidad
de programadores de sistemas de agentes.
En la figura 4.3 se muestra el proceso completo de la generación de agentes protegidos
usando la metodología propuesta, a la que denominamos de forma genérica “técnica de
protección mutua”. En ella se aprecia cómo aparecen los dos esquemas descritos. En la
parte superior aparece un cuadro que engloba el esquema de protección estática y en
la inferior encontramos otro cuadro con el esquema de protección dinámica. También se
muestra el caso de uso en que un implementador programe un sistema de agentes sin
ningún mécanismo de seguridad.
El usuario (en este caso el desarrollador del sistema) hace uso de la herramienta de
protección de código “code partition tool”(CPT), junto con un “perfil de protección”. Como
se explica a continuación esto permite una mayor flexibilidad en el proceso completo.
Ambas herramientas se han diseñado e implementado como parte de esta tesis doctoral.
En las secciones siguientes encontramos una descripción de los aspectos más relevantes
de las mismas. De hecho, el propósito de estas herramientas es exclusivamente el apoyo
en la tarea de partición del código para los usuarios, de forma que estos no necesiten un
Protección mutua dinámica. Existen casos en los que la protección mutua estática
tiene un abanico de aplicación bastante reducido, ya que fue diseñada e implementada
como un prototipo meramente académico. Sin embargo, para poder explotar esta idea en
sistemas reales de agentes se desarrolló la estrategia de protección mutua dinámica. En
esta alternativa cada agente es capaz de ejecutar arbitrariamente secciones de código de
otros agentes de la sociedad. Cada agente incluye una parte pública, una parte privada,
que permanece cifrada, y una máquina virtual especifica. La máquina virtual permite a
los agentes ejecutar secciones de código (en concreto nos referimos a las partes privadas)
recibidas por otros agentes al instante.
Para realizar una llamada de ejecución remota de código, es decir, ejecución del código
protegido se han de usar las instrucciones que aparecen en la figura 4.7.
Para la creación y configuración de los mensajes ACL se hará uso de las tres primeras
instrucciones. La cuarta instrucción sirve para asignar al campo myArgs los argumentos
que pretendemos enviar al agente protector. Y por último, en la quinta instrucción da-
mos comienzo a la comunicación. El proceso de comunicación entre dos agentes queda
perfectamente descrito en el protocolo de la figura 4.9.
1. Un paquete que contiene clases que describen las limitaciones “estáticas” de los
ficheros de clase. Las clases deben ser utilizadas para leer y escribir ficheros de clase
desde o hacia un archivo. Esto es especialmente útil para analizar clases Java sin
tener el código fuente a mano. La clase principal de este paquete es JavaClass.
2. Un paquete para generar o modificar dinámicamente ficheros de clase que puede ser
utilizado para añadir o analizar código de los ficheros de clase, etc.
3. Además de estos dos paquetes, BCEL contiene varios ejemplos de código y utilidades
como un visor de ficheros de clase, una herramienta para convertir fichero de clase
El acceso a los datos del fichero de clase se realiza como se detalla a continuación.
La información de los componentes de los ficheros de clase se puede acceder Java Beans
mediante intuitivos métodos set/get. Además todos definen un método toString() que
permiten implementar un visor de clases de manera muy sencilla.
El análisis de los datos de la clase se realiza usando un componente bastante útil de
BCEL, este soporta el patrón de diseño Visitor. Este patrón nos permite recorrer de una
forma elegante toda la jerarquía de clases y analizar, en cada caso, el componente en
cuestión.
La clase ClassGen es una parte de la API (paquete org.apache.bcel.generic) que ofrece
un nivel de abstracción para la creación y/o transformación de ficheros de clase de forma
dinámica. La clase ConstantPool está implementada mediante la clase ConstantPoolGen,
esta ofrece métodos para añadir diferentes tipos de constantes. Por tanto, ClassGen ofrece
una interfaz para añadir métodos, campos y atributos a nuestras clases.
parte privada del agente seguro y si no está protegido estará en la parte pública. Una vez
descritas tanto las precondiciones como las postcondiciones vamos a presentar el escenario
de éxito principal para este caso de uso. En primera instancia el usuario selecciona un
campo a proteger/desproteger, en segundo lugar el campo modifica su estado y se cambia
la configuración de seguridad del agente al que pertenece.
En el siguiente caso de uso se presenta la selección del nivel de seguridad. El proceso
es el siguiente, el usuario selecciona un agente de los cargados en el sistema y establece su
porcentaje de seguridad (el porcentaje de instrucciones y de datos que formarán parte del
código privado). El actor principal es el usuario de la aplicación. La única precondición
para este caso de uso es que el dato introducido deberá estar entre cero y cien. También
presenta una única postcondición que consiste en que se establecerá el porcentaje indicado
por el usuario en la configuración de seguridad del agente seleccionado. El escenario de
éxito principal viene descrito por que el usuario seleccione un agente, previamente cargado
en el sistema, establece su porcentaje de seguridad, en relación datos e instrucciones, y se
guarda en la configuración de seguridad del agente seleccionado.
El último caso de uso es el de la creación de agentes protegidos. En este se comprueba
que todos los agentes que componen el sistema están correctamente configurados y se
procede a la creación de los nuevos agentes seguros. Al igual que ocurre en los casos
de uso anteriores el actor principal es el usuario de la aplicación. Únicamente hay una
precondición diferente que consiste en que el número de agentes cargados en el sistema
debe ser mayor que 1, puesto que en caso contrario no tendría sentido el uso de esta técnica.
Así como también sólo hay una postcondición que vendrá descrita por que habremos
creado un sistema multiagente con el esquema de la seguridad mutua estática integrado.
Para finalizar, el escenario de éxito principal viene descrito por que el usuario selecciona
la acción “Crear agentes seguros”, entonces el sistema comprueba que la configuración
de seguridad de cada agente es correcta. Seguidamente, se crearán dos nuevas clases por
cada uno de los agentes, una contendrá su código público y la otra su código privado. Se
reparten los campos entre el código público y privado dependiendo de su configuración
de seguridad, de forma similar con las instrucciones y se añaden las que sean necesarias
para la comunicación. Y por último se guardan los nuevos agentes protegidos.
2. FieldReady: Encapsula un campo de una clase. También cuenta con dos subclases:
AgentFields: Representa un campo de un agente JADE.
AgentInnerField: Representa un campo de una clase interna de un agente.
5. InformationVisitor: Hace uso del patrón de diseño Visitor para recolectar la infor-
mación de los diferentes métodos de una clase.
InformationAgentVisitor: Utilizado para los métodos de los agentes.
InformationInnerVisitor: Utilizado para los métodos de las clases internas.
Para la creación de este modelo nos hemos basado en el modelo que ofrece BCEL,
heredando algunas de nuestras clases directamente de sus clases para beneficiarnos de
sus características. Veamos a continuación mediante un diagrama de secuencia como se
produce la carga de una agente. Nótese que a pesar de no haber mencionado todavía las
clases de la interfaz gráfica, éstas aparecen en el diagrama y serán descritas en mayor
profundidad a lo largo de las siguientes líneas.
Podemos observar que a la hora de configurar las clases (tanto AgentClass como Agen-
tInnerClass) aplazamos la configuración de los métodos hasta la última acción. Esto es
debido a que, en el proceso de extracción de información de los métodos, es necesario
tener perfectamente configurados los campos.
La Configuración de seguridad es la fase más simple del comportamiento de nuestra
aplicación. En ella se distribuye el código de los diferentes agentes JADE cargados en el
sistema para proporcionarles el nivel de seguridad que el usuario crea conveniente. Toda
la información relativa a la configuración de seguridad se modela con una clase llamada
SecureAgentConfiguration, esta clase es el puente entre la primera fase, la correspondiente
a la carga de agentes y la tercera.
La clase SecureAgentConfiguration contiene tanto el porcentaje de seguridad de las
instrucciones, como las listas con los campos que van a ser protegidos y los que no. El
uso de este elemento es relativamente sencillo, en la figura 4.14 mostramos los pasos que
se realizan. En esta figura podemos ver cómo el usuario selecciona el nombre del campo
a proteger, haciendo uso de la interfaz gráfica. Se envía el nombre del campo a proteger
a la clase SecureAgentConfiguration. Esta clase obtiene el identificador de este campo y
seguidamente invoca al método protect de la clase FieldReady y devuelve si la operación
ha resultado exitosa.
Las acciones “desproteger un campo” y “seleccionar nivel de seguridad” tienen un
comportamiento muy parecido al anterior. Esta clase también nos permite seleccionar
el nivel de seguridad de un sistema de agentes a partir de un archivo XML. Esto nos
proporciona la capacidad de dotar a todos los agentes del mismo nivel de seguridad,
además de facilitarnos la tarea de protección de agentes por lotes, puesto que permite
una automatización del proceso. Lo hemos etiquetado como “perfil de protección”. En la
figura 4.15 se muestra una versión reducida como ejemplo de perfil de protección. A pesar
de que este ejemplo es bastante simple, podemos desarrollar un perfil de protección con
multitud de clausulas específicas para cada caso concreto.
Una vez realizada la carga de los agentes en el sistema y la configuración de seguridad
procedemos a la protección de los agentes. Por cada agente cargado en el sistema debemos
crear al menos dos ficheros de clase:
Las clases más relevantes que vamos a comentar de este diagrama son:
vez finalizado este paso, se crea el código privado, haciendo uso de la función “create-
PrivateCode”. A continuación se llama a “createinnerClasses”, se añaden los campos, con
la función “addFields” y por último se añaden los métodos “addFields” y se devuelve el
mensaje que muestra si el proceso se completó satisfactoriamente.
Una vez visto todo lo referente a la especificación del modelo de datos, comentaremos
la estructura de la interfaz gráfica, sin adentrarnos en los detalles de diseño que no consi-
deramos de especial interés, únicamente resaltar el hecho de que se ha pretendido utilizar
un diseño muy sencillo, con idea de minimizar el tiempo de aprendizaje en el uso de la
herramienta.
La interfaz gráfica realiza la función de puente de conexión entre el usuario de nuestra
aplicación y el conjunto de funciones que ofrece nuestro modelo de datos (formado por
cargar, configurar y crear agentes seguros). Para lograr cierta sencillez, hemos utilizado
el patrón de diseño Modelo-Vista-Controlador, donde el modelo corresponde al modelo
de datos previamente presentado, la vista es la GUI y el controlador es el encargado de
proporcionar la lógica de control para la interacción entre el modelo y la vista. Trasladando
este patrón de diseño a nuestro modelo concreto obtenemos el diagrama de clases que se
muestra en la parte derecha de la figura 4.18.
4.2.5. Implementación
El objetivo de este apartado es mostrar los aspectos más relevantes de la implemen-
tación de nuestra aplicación. Sin entrar en un nivel detallado de la misma, puesto que
queda fuera del objetivo de esta tesis. Aunque consideramos importante la inclusión de
ciertos aspectos derivados de la implementación que han enriquecido, mediante un proceso
iterativo, los resultados de la investigación.
La clase “InstructionReady” representa esta unidad mínima que puede ser protegida y
corresponde a una instrucción Java terminada en “;”. Para acotar el conjunto de instruc-
Crear el objeto (ClassGen) que represente al fichero de clase del agente seguro e ir
añadiéndole los campos e instrucciones que no estén protegidos.
Crear un objeto, por cada clase interna del agente original, que represente al fichero
de clase de la nueva clase interna y añadirle sus campos e instrucciones.
Crear el objeto que represente al fichero de clase del código privado e introducirle
su estructura básica (ver figura 4.22).
Hemos forzado a que sea la propia clase la que implemente la interfaz PrivateCode
y hemos añadido el método “execute()” que implemente la interfaz.
En este punto, hemos conseguido los objetos contenedores que representan a los ficheros
de clases, pero estos están vacíos. El siguiente paso consiste en introducirles el código y
los campos de la forma adecuada. Repartir los campos del agente original es una tarea
bastante sencilla. Dependiendo si están o no protegidos los introducimos en el ClassGen
La transferencia de las instrucciones se realiza con la ayuda del patrón Visitor que,
al igual que en la carga de agentes, nos ofrece una manera sutil de realizar dicha tarea.
El diagrama de actividad siguiente 4.27 nos proporciona una idea de cómo se produce el
traspaso de instrucciones. Si las instrucciones no están protegidas se introducen en el nuevo
agente seguro, si por el contrario, las instrucciones están protegidas las emplazaremos en
el método “execute()” del PrivateCode.
A modo de ejemplo mostramos algunos casos en los que el paso de instrucciones ha
sido especialmente complejo. Instrucción protegida utiliza campos no protegidos. Este es
uno de los casos más simples que nos podemos encontrar ya que, únicamente tenemos que
cambiar los accesos a campos por accesos a variables locales. Vamos a centrarnos en el
código de la figura 4.28 para realizar nuestro análisis. La instrucción marcada va a ser
protegida y al no estar protegido el campo contador enviará su valor con los parámetros
(Ver 6.1.5).
Esto hace que en el código protegido tengamos que extraer los parámetros en una
variable local e introducirlos en la nueva lista de instrucciónes. En la ilustración 4.29
4.3. Evaluación
Durante el desarrollo de cualquier solución o sistema van surgiendo diversos problemas
y contratiempos. Es importante encontrar soluciones de fácil implementación, versátiles
y robustas. Esto no siempre es posible, en muchas ocasiones al darle solución a un pro-
blema se están generando nuevos problemas que más tarde tendremos que resolver. Por
ello, hay que analizar cada caso individualmente y elegir la solución más afín a nuestras
necesidades. Debido a su importancia, hemos dedicado una secci ón para describir los
problemas más relevantes que han ido apareciendo en el transcurso de la tesis. Los hemos
dividido en secciones dependiendo del elemento software que provoca el problema. En el
funcionamiento de “SecureAgent” encontramos ciertos inconvenientes que hemos tenido
que solucionar que son inherentes a las tecnologías utilizadas.
Una vez aclarados estos aspectos de la solución, pasamos a la obtención de resultados.
Para ello imaginemos que tenemos dos agentes protegidos con la estrategia de protección
La primera vez que ejecutamos este código pudimos observar como el resultado que
se mostraba por pantalla era “null” éste no era el comportamiento deseado.
Tras esta ejecución del código tenemos constancia de que surge un problema. La ejecu-
ción remota posee un retardo intrínseco que no podemos controlar, por lo que la variable
“result” tarda cierto tiempo en capturar un valor adecuado y confiable. Hemos encon-
trado una solución elegante tras analizar algunas alternativas, esta consiste en dormir al
hilo que ejecuta la llamada hasta que el resultado estuviese actualizado. Esto hizo que
surgiese otro problema relacionado con los hilos y los comportamientos y que solucionare-
mos posteriormente. Este código lo introducimos dentro de un método al que llamaremos
waitToResult(), el cual crearemos automáticamente al construir un agente seguro.
Existen otros problemas relacionados con los hilos de ejecución y los comportamien-
tos. Al esperar el resultado llamando a la función java.lang.Thread.sleep(time) el hilo de
ejecución del agente pasa al estado “dormido”. Al dormirse el hilo también lo hacen los
comportamientos que el agente posee, provocándose una situación de interbloqueo. Para
que esto no ocurra, habría que separar el hilo que se encarga de la comunicación de los
agentes seguros, del hilo normal de ejecución. JADE nos proporciona una clase capaz
de ejecutar los comportamientos de un agente en un hilo independiente. La clase Th-
readedBehaviourFactory encapsula un conjunto de comportamientos mediante el método
wrap(comportamiento), y al añadirle los comportamientos al agente, éstos se ejecutan en
un hilo independiente.
Así pues, para solucionar nuestro problema hemos tenido que realizar varios cambios:
Modificar la inicialización de la clase jade.core.secureAgent.static.SecureAgent e in-
troducir todos los comportamientos dedicados a la comunicación de los agentes
seguros en un ThreadedBehaviourFactory.
Añadir el código del método “setup” del agente original en el método run() de un
nuevo Thread. En la figura 4.35 podemos ver cómo utilizamos este nuevo hilo. Su
ejecución comienza en la última instrucción del método.
La justificación de esta última modificación se basa en el modo de funcionamiento de
los agentes JADE. Los comportamientos no se empiezan a ejecutar hasta que el método
“setup” finalice, aunque estos comportamientos hayan sido introducidos en un hilo de
ejecución diferente mediante ThreadedBehaviourFactory.
Para realizar la ejecución en un solo método, la interfaz PrivateCode establece que las
instrucciones protegidas de un agente seguro deben ir encluidas en el método execute().
Cuando se solicita la ejecución de código protegido, los comportamientos de los agentes
realizan automáticamente el intercambio de información y llaman al método execute().
Sin embargo, nos encontramos con que el código protegido no tiene que ser contiguo,
este puede estar dividido en secciones, pertenecer a diferentes métodos e incluso a diferen-
tes clases internas. Esto hace que tengamos que diferenciar qué parte de código queremos
ejecutar en una llamada concreta y ser capaces de diferenciar estas secciones en el método
“execute()”.
Para solucionar este inconveniente hemos creado una estructura común para todos los
métodos execute() con la forma que se muestra en la siguiente ilustración 4.37. El único
problema que queda por solucionar es obtener el identificador de cada sección. Este deberá
venir en los parámetros que se envían al solicitar la ejecución de código protegido.
El acceso de campos protegidos se realiza de la siguiente forma. A parte de las secciones
de código que crean las respectivas llamadas de ejecución de código protegido, existen dos
casos de especial interés:
Consulta de campos protegidos por parte del agente seguro.
Variación de campos protegidos por parte del agente seguro.
Lista con los valores de los diferentes parámetros que necesita la sección de código.
agente. Para lo cual, tomamos la iniciativa de identificar los casos en los que ocurría
el problema e indicarlos como restricciones (como clases internas anónimas). No está
permitido cargar un fichero de clase de un agente que contenga clases internas anónimas.
Para resolver este problema diseñamos el siguiente código que aclara el concepto de clase
interna anónima mediante un ejemplo práctico. El compilador crea una clase Anonimous
que hereda de Thread. Los métodos de acceso son creados por el compilador cuando
existe en la clase interna un campo o método privado y se realiza un acceso a ese campo o
método desde la clase externa. Dichos métodos generados automáticamente no contienen
la tabla de variables locales correctamente configurada por lo que es complejo trabajar con
ellos. En consecuencia no están permitidos los campos y los métodos privados en las clases
internas. A pesar de haber tenido más problemas a lo largo del desarrollo los consideramos
menores siendo los anteriormente mencionados los más relevantes y con especial interés.
de la misma.
Otro campo en el que trabajar es el de las rutas de los agentes. Además de proporcionar
un grado extra en la seguridad el control de las rutas, sería deseable que los agentes que
colaboren en la realización de una misma tarea no pasen todos por la misma agencia.
Puede darse el caso de que todos los agentes pasen por la misma agencia y soliciten
desde ella una ejecución remota de su código privado. De forma remota esto podría pro-
vocar que una agencia con caracter malicioso pudiera reconstruir parte del código de los
agentes implicados y pudiera intuir qué tareas se están intentando realizar. Lo cual va
totalmente en contra de la filosofía de esta técnica que pretende proteger el sistema. Ha-
cemos referencia a que esto se hace de una forma muy remota puesto que las posibilidades
de estudio de comportamiento de un software de caja negra no son triviales, aunque bien
es cierto que si se repiten las mismas tareas con mucha frecuencia se podrían obtener
cierta información.
Si logramos que los agentes tengan conocimiento de la ruta que siguen sus colabora-
dores, podrían desplazarse sólo por agencias por las que no han pasado ellos. Esto sería
posible si diseñamos un sistema multiagente donde cada uno tiene una ruta inicial preasig-
nada, de forma que podamos realizar rutas disjuntas. Aunque también hay que hacer un
balance de hasta qué punto puede ser seguro que un agente tenga una ruta preasignada,
ya que esto podría entablar problemas de seguridad aún más severos que el planteado.
En este capítulo ofrecemos una reflexión del trabajo realizado en esta tesis, además de
presentar las conclusiones más relevantes y los trabajos futuros para continuar el fruto del
trabajo de la tesis. En primer lugar, revisamos los objetivos iniciales de nuestro trabajo,
describimos la forma en que se han conseguido y finalizamos con la identificación de los
trabajos futuros más relevantes. La estructura de este capítulo es la siguiente, en la primera
sección presentamos cómo se han conseguido los objetivos, la segunda sección presenta
una visión global del trabajo de la tesis y las secciones 5.3, 5.4 y 5.5 están dedicadas a
diferentes líneas futuras de trabajo.
Los dos primeros objetivos se han conseguido de forma simultánea ya que el estudio de
los mecanismos existentes hasta el momento ha ayudado en la identificación de los puntos
137
Conclusiones y Líneas Futuras
5.2. Conclusiones
Hemos llevado a cabo un estudio detallado del problema de la protección de sistemas
basados en agentes centrándonos en diferentes aspectos, además de describir los objetivos
a conseguir en cada uno de los diferentes casos. Las soluciones que se han desarrollado
se centran en dos iniciativas diferentes, una basada en proporcionar una solución segura
basada en el uso de un elemento externo y la otra propone una solución que hace uso de
la capacidad de colaboración entre los agentes para la resolución de un problema como la
base para asegurar un mínimo de seguridad, tal y como se describe en el capítulo 2. En
esta tesis se muestra cómo ambos mecanismos se pueden utilizar en diferentes escenarios
para la protección del sistema global.
También hemos llevado a cabo un análisis de los diferentes mecanismos de protección
existentes, tanto a nivel académico como industrial, y hemos hecho una clasificación de
estos en base a la naturaleza del propio mecanismo. Hemos mostrado cómo los mecanismos
existentes son inadecuados, y en la mayoría de los casos están basados en aplicaciones
directas de soluciones diseñadas para software en general y no para sistemas basados
en agentes. En otros casos, hemos observado que la aplicación de soluciones existentes
requiere que los desarrolladores tengan conocimientos avanzados de los mecanismos de
seguridad. Como parte de la revisión de los trabajos relacionados, hemos resaltado que
una alternativa para asegurar la protección de los sistemas basados en agentes se basa
en el uso de la tecnología de Trusted Computing. Hemos trabajado con la propiesta más
destacada dentro de este campo: la representada por el Trusted Computing Platform
Alliance. Esta iniciativa está guiada por el diseño de la solución presentada en el capítulo
2.
Para la validación de esta solución hemos decidido tomar dos caminos alternativos,
lo cual proporciona un nivel superior de robustez de la solución. En primer lugar, hemos
realizado una validación formal del protocolo de migración segura de nuestra solución.
Para ello, hemos hecho uso de un conjunto de herramientas conocido como AVISPA.
Además hemos aplicado la solución a un caso de uso del mundo real y hemos diseñado un
sistema que funciona como simulador de una planta nuclear en el que hemos construido
un sistema basado en agentes que realiza una monitorización del funcionamiento correcto
de cada una de las partes del sistema. Obviamente, este escenario requiere un alto nivel
de seguridad.
ingeniería del software orientada a agentes debe ser revisada y extendida para la ingeniería
de los sistemas de Ambientes Inteligentes.
Sin embargo, a pesar de la atención prestada por la comunidad investigadora, esta
tecnología no ha tenido una gran acogida, sobre todo a nivel industrial. De hecho, sólo se
ha aplicado en escenarios muy concretos y limitados del mundo real. Esto se debe, en gran
parte, por la existencia de ciertos problemas de seguridad que, de hecho, se considera la
dificultad más urgente a resolver en esta tecnología antes de estar lista para usarse en el
marco industrial. En lo referente a la seguridad, los agentes presentan características muy
interesantes y pueden cubrir requisitos de seguridad por parte de diferentes actores, con
un modelo para lograr los objetivos de cada parte en colaboración. Evidentemente, esta
tecnología no estará suficientemente madura para usarse de forma extendida hasta que
los problemas de seguridad más importantes se hayan solucionado. Esto consiste tanto
en encontrar los mecanismos apropiados como en la facilitación de la aplicación de estos
mecanismos.
Tradicionalmente se han aplicado algunos de los mecanismos de protección genérica
de software para la protección de sistemas de agentes. Sin embargo, las características
especiales de esta tecnología obligan al uso de soluciones específicas. Algunos mecanismos
de protección están orientados a la protección de los hosts del sistema frente a agentes
con carácter malicioso. La solución más relevante para este problema pensamos que viene
por la utilización del concepto del Sandbox, consistente en un contenedor que limita o
reduce el nivel de acceso que los agentes tienen y proporcionan ciertos mecanismos para
controlar la interacción entre ellos. Otra técnica que trata esta vertiente del problema
se conoce como proof carrying code (o código portador de prueba) [69], esta técnica se
basa en que cada fragmento de código incluye una prueba detallada que se puede usar
para determinar si la política de seguridad del host se satisface por parte del agente. Los
hosts sólo tienen que verificar que la prueba es correcta (lo que significa que corresponde
con el código) y que es compatible con la política de seguridad local, aunque hemos de
mencionar que la aplicación de esta técnica no resulta sencilla, de hecho en multitud de
ocasiones no es fácil encontrar estas políticas de seguridad.
Otros mecanismos están orientados a la protección de los agentes frente a posibles
agencia (hosts) maliciosos. La más representativa es la que se conoce como el uso de
santuarios [40], que consisten en entornos de ejecución en los que el agente móvil puede
ejecutarse de forma segura. La mayoría de estas propuestas se construyen asumiendo que
la plataforma donde se implementa el santuario es segura. Desgraciadamente, asumir esto
no funciona en la práctica para los sistemas basados en agentes, puesto que no podemos
basarnos en que todas las plataformas sean confiables.
Por otro lado, se pueden aplicar varias técnicas para verificar la propia integridad.
Esta idea resulta de utilidad para evitar que tanto el código como los datos del agente
puedan ser manipulados de forma inadvertida. Dentro de este conjunto de técnicas anti-
manipulación se incluyen otras como son las de cifrado, checksum, anti-depurado, anti-
emulación, etc.[70], que en definitiva comparten el mismo objetivo, pero que también están
orientadas a la prevención del análisis de la función que implementa el propio agente.
Todas estas técnicas presentan un grado de dificultad bastante alto en su aplicación,
especialmente para los programadores que utilicen esta tecnología, principalmente debido
al hecho de que la aplicación de estas técnicas implica ciertos conocimientos mínimos de
seguridad.
Una vez expuestas las diferentes alternativas, defendemos el hecho de que todas las
técnicas descritas proporcionan protección a corto plazo, además de requerir una base
de conocimiento mínima en temas de seguridad, por lo tanto, no son útiles para nuestro
propósito. En cambio, en ciertos escenarios, pueden representar una solución bastante
factible, especialmente combinada con otras soluciones. Existen algunas soluciones teóricas
al problema, de hecho se ha demostrado que la autoprotección de código no es viable, es
decir, que no se puede asegurar la fiabilidad de una solución que sólo se base en software
para la protección [71]. En algunos escenarios, la protección requerida está limitada a
algunas partes del software (código o datos). De esta forma, la función implementada
por el software o los datos han de estar ocultos para el host en el que se ejecuté el
software. Algunas de estas técnicas requieren un paso de procesamiento adicional externo
para obtener los resultados deseados. Entre estos esquemas, las técnicas de ocultación
permiten la evaluación de funciones cifradas [33]. Esta técnica se basa en proteger los datos
procesados para la protección del propio agente. Por esta razón, es una técnica apropiada
para la protección de los agentes. Sin embargo, sólo es aplicable para la protección de
funciones polinomiales.
El caso de los esquemas de colaboración en línea también es muy interesante. En estos
esquemas, parte de la funcionalidad del software se ejecuta en uno o más computadores
externos. La seguridad de esta solución depende de la imposibilidad de cada parte de iden-
tificar la función realizada por otros. Esta solución es muy apropiada para arquitecturas
de computación distribuidas como son los sistemas basados en agentes o la computación
grid.
Por último, existen técnicas que crean una protección bidireccional, protegen tanto al
agente como a la agencia. Entre ellas algunas se basan en el uso de soluciones basadas
en hardware, como algunas que usan el Trusted Computing Platform como elemento
base [17]. De hecho, con la reciente aparición de la computación ubicua, la necesidad de
una plataforma segura se ha consolidado como un hecho evidente. Esta solución añade un
componente confiable a la plataforma de computación, que normalmente consiste en cierto
hardware integrado en la placa madre del ordenador y que se utiliza para crear confianza
en los procesos software [72]. Otras técnicas se basan únicamente en elementos software,
como por ejemplo la que hace uso de la computación protegida [49]. Esta técnica se basa
en la partición de los elementos software en dos o más partes mutuamente dependientes,
de forma que el código será ejecutado de forma remota por diferentes agentes.
recursos que usan. Según el IEEE Computer Society, es un paradigma en el que la infor-
mación se almacena de manera permanente en servidores en Internet y se envía a cachés
temporales de cliente, lo que incluye equipos de escritorio, centros de ocio, portátiles, etc.
Esto se debe a que, pese a que las capacidades de los PC han mejorado sustancialmente,
gran parte de su potencial está desaprovechado, al ser máquinas de propósito general. La
computación en nube es un concepto que incorpora el software como servicio, tal como la
Web 2.0 y otros recientes, también conocidos como tendencias tecnológicas, en los que el
punto en común es la confianza en Internet para satisfacer las necesidades de cómputo de
los usuarios.
Como ejemplos de Computación en Nube destacan Amazon EC2, Google Apps, eyeOS
y Microsoft Azure que proveen aplicaciones comunes de negocios en línea accesibles desde
un navegador web, mientras el software y los datos se almacenan en los servidores.
El concepto cómputo cloud empezó con proveedores de servicio de Internet de gran
escala tales como Google y Amazon, así como otras que construyeron su infraestructura
previa. Así surge una arquitectura consistente en un sistema de recursos horizontalmente
distribuidos, introducidos como servicios virtuales. Este modelo arquitectónico fue in-
mortalizado por George Gilder en un artículo de 2006 publicado Wired y titulado “Las
Fábricas de Información´’. Las granjas de servidores acerca de las cuales Gilder escribió
eran similares en su arquitectura al cómputo grid, pero mientras que los grids son utiliza-
dos para aplicaciones de cómputo técnico “loosely coupled” (o sea un sistema compuesto
de subsistemas con cierta autonomía de acción a la par que mantienen una interrelación
continua con los otros componentes) este nuevo modelo de nube se estaba aplicando a los
servicios de Internet.
Tanto las nubes como los grids estan hechos para escalar horizontalmente muy eficien-
temente. Ambos están construidos para resistir fallos de los elementos o nodos individuales
y se cargan “por-uso”. Pero mientras que los grids típicamente procesan los trabajos en
batch, con un punto definido de inicio y final, los servicios nube pueden ser continuos. Lo
que es más, las nubes expanden los tipos de recursos disponibles como el almacenamiento
de archivos, las bases de datos, y los servicios web y extienden la aplicabilidad a la Web
y a las aplicaciones de la empresa.
Al mismo tiempo, el concepto de cómputo de programas utility llegó a ser el foco de
diseño y operaciones de las tecnologías de la información. Nick Carr describe en su libro
“The Big Switch” [73] que la infraestructura de los servicios de cómputo empieza a ser
comparable con el desarrollo de la electricidad como utilidad. El autor afirma que sería
grandioso si se pudieran comprar recursos de computación bajo demanda, sólo pagando
lo que se necesite y en el momento adecuado.
Dado que la computación en nube no permite a los usuarios poseer físicamente los
dispositivos de almacenamiento de sus datos (con la excepción de la posibilidad de copiar
los datos a un dispositivo de almacenamiento externo, como una unidad flash USB o un
disco duro), deja la responsabilidad del almacenamiento de datos y su control en manos
del proveedor.
La computación en nube ha sido criticada por limitar la libertad de los usuarios y
hacerlos dependientes del proveedor de servicios. Algunos han criticado este paradigma
afirmando que sólo es posible usar las aplicaciones y servicios que el proveedor esté dis-
puesto a ofrecer. Así, el London Times compara la computación en nube con los sistemas
centralizados de los años 50 y 60, en los que los usuarios se conectaban a través de termi-
nales con ordenadores centrales.
Generalmente, los usuarios no tenían libertad para instalar nuevas aplicaciones, y
necesitaban la aprobación de administradores para desempeñar determinadas tareas. En
definitiva, se limitaba tanto la libertad como la creatividad. El Times argumenta que la
computación en nube es un retorno a esa época. De forma similar, Richard Stallman,
fundador de la Free Software Foundation, cree que la computación en nube pone en
peligro las libertades de los usuarios, porque éstos dejan su privacidad y datos personales
en manos de terceros. Se ha afirmado que la computación en nube es simplemente una
trampa destinada a obligar a más gente a adquirir sistemas propietarios, bloqueados, que
les costar cada vez más caros.
Una vez claro el concepto de la computación en nube y las ventajas que proporciona
este modelo nos planteamos un paso más allá en la evolución de esta tecnología. Hasta el
momento la base de esta computación radicaba en el envío de una serie de datos a procesar
por la nube, con la consiguiente delegación de confianza en la misma nube por parte del
usuario. Sin embargo, este modelo queda restringido a las funcionalidades proporcionadas
por el proveedor de la nube. Por lo que el usuario únicamente podrá ejecutar los programas
que estén integrados en la nube, proponemos que el usuario pueda enviar a la nube además
de los datos sus propios programas.
Estableciendo un paralelismo con la tecnología de agentes, que básicamente son en-
tidades de computación que pueden englobar cualquier código. La principal ventaja que
encontramos en verlo de esta forma es que con los avances obtenidos en este trabajo de te-
sis tendremos solucionados varios de los problemas de seguridad derivados de la ejecución
del cierto código en un host ajeno.
todos los inconvenientes de las dos técnicas desarrolladas puesto que los requisitos de uso
de la misma son un conjunto formado por la unión de los conjuntos de requisitos de ambas
técnicas.
No obstante, defendemos la idea de que resultaría de gran interés el estudio de una
combinación de ambas técnicas para la obtención de un nivel superior de seguridad, espe-
cialmente para ciertos casos en los que la seguridad del sistema pueda verse cuestionada.
El principal argumento para la combinación de ambas técnicas en una misma solución
radica en obtener una solución capaz de proteger tanto al agente como a la agencia, es
decir, en conseguir una protección en ambos sentidos.
Thesis summary
145
Thesis summary
solve before this technology is mature to be used by the industry but this aspect is not
currently appropriately solved.
Moreover, current security mechanisms for agents such as sandboxing [1], ciphering
or encryption, are not enough to guarantee the necessary security, especially when we
consider the scenarios of malicious hosts. Security must be considered in every stage of
software life. In fact, several authors have proved that considering security as an addi-
tional or orthogonal aspect is an obsolete idea that produces systems with poor security.
Other relevant aspect to consider is that the security of agent-based systems needs to be
specifically adapted to these kind of systems and the technologies used to build them.
The most relevant feature to be consider from our perspective is the mobility. The main
goals of our work are:
Studying the weakest security points in the current agent-based systems, both for
agents and platforms.
Analyzing current mechanisms used to provide security to agent-based systems,
performing an evaluation of these, considering both security and usability aspects,
which are essential for the real acceptance of new my solution.
Designing a solution by means of which agent-based system developers can build
secure agent-based systems. Moreover, the implementation of the necessary tools to
facilitate the task to final users, a central are part of this objective. The analysis
carried out as our second goal revealed the convenience of addressing this lines of
protection: one based on software-only solutions, and another one that makes use
of a hardware element called Trusted Platform Module (TPM), as these solutions
complement each other and address needs of different application scenarios.
Validating our solution. This will be performed by means of a study of the use of
our solutions and tools both by means of formal analysis and by experience applying
the results in real world systems.
the way to facilitate the use of our migration protocol in the existent JADE framework
with no security expertise required.
Second methodology is based in the use of “protected computing” methodology, which
is completely different to the previous one and unique software based. The core of this
methodology is the performance of an intelligent division of code and distribute among the
agents in the system. We have developed assistant tools to implement this methodology at
user level, to facilitate this task of applying security expert techniques in agent protection.
Therefore, we have developed tools to split the code according to the needs in every case by
means of a “protection profile” that helps in the automatic procedure. We have analyzed
a wide set of possible requirements for code splitting and we have designed a set of tools
to capture analyzed requirements.
We have disseminated the result of our work in the scientific community by means of
certain number of publications. In the following we describe each part of the work this
thesis and relate it to the publication. We present the most relevant publications that
support the scientific value of this thesis. Thus, we structured this section in three parts.
Firstly, we describe the most relevant contributions focused on the use of TPM. Secondly,
we list the most relevant contributions related with the “protected computing” paradigm.
Finally, we listed a set of contributions oriented on future applications of the results of
this work.
Rudolph, Luca Compagna, Antonio Muñoz, and Jurgen Repp. This chapter is part of
the book ‘Security and Dependability for Ambient Intelligence”, edited by Spanoudakis
G., Maña A. and Kokolakis, and published by springer in Information Security Series
(ISBN-978-0-387-88775-3), in June 2009. We consider both of them specially interesting
contributions as they present tools used to perfrom a formal validation of the protocol we
use as basis of our solution.
Secure Migration Library for Mobile Agents based on cryptographic hardware is presen-
ted in this paper. In this paper we describe the most relevant libraries involved in this
work using TPM functionalities and based on the JADE platform. We propose for the
use of Trusted Computing technology as cornerstone for a secure solution. We actually
consider this work relevant due to the fact that this is a very strong conference with an
acceptance rate around of 30 %. The second paper highlighted in this year is authored
by Antonio Muñoz, Antonio Maña, Rajesh Harjani and Marioli Montenegro under the
title “Agent Protection based on the use of cryptographic hardware”, this work is part of
the proceedings of the 33rd Annual IEEE International Computer Software and Appli-
cations Conference, COMPSAC09 celebrated in Seattle,Washington. This is one of the
most significant conferences in security. Important constructive feedback was received,
this enhancing results presented in this thesis.
different points in order to achieve each partś goals in an important collaborative setting.
Of course, as mentioned above, we need to solve the most important security issues for
general multi-agent systems.
Some of the general software protection mechanisms can be applied to agent protec-
tion. However, the specific characteristics of agents mandate the use of tailored solutions.
First, agents are most frequently executed on potentially malicious pieces of software.
Therefore, we cannot simplify the problem as it is done in other scenarios by assuming
that some elements of the system are trusted. Then, the security of an agent system can
be defined in terms of many different properties such as confidentiality, non-repudiation,
etc. but it always depends on ensuring the correct execution of an agent on agent servers
(a.k.a agencies) within the context of global environments provided by the servers. Some
protection mechanisms are oriented to the protection of the host system against malicious
agents, such as sandboxing and proof-carrying code. Other mechanisms are oriented to-
wards protecting agents from malicious agencies, where one of the most recent approaches
is the concept of sanctuary. Nevertheless, most of these proposals are built with the as-
sumption that the platform where the sanctuary is implemented is secure. Unfortunately,
for agent-based systems this assumption is not applicable.
Several techniques can be applied to an agent to verify self-integrity avoiding that the
code or the data of an agent is inadvertently manipulated. Anti-tamper techniques, such
as encryption, checksum, anti-debugging, anti-emulation and some others [70] share the
same goal, but they also are oriented towards the prevention of analysis of the functions
an agent implements. Some protection schemes are based on self-modifying code and code
obfuscation. In agent systems, these techniques exploit the reduced execution time of the
agent in each platform. Software watermarking techniques [70] are also interesting. In this
case the purpose of protection is not to avoid the analysis or modification but to enable
the detection of such modification. The relation between all these techniques is strong.
Indeed, it has been demonstrated that neither perfect obfuscation nor perfect watermark
exists [76]. In summary, all these techniques provide short-term protection; therefore, in
general they are not applicable for our purposes. However, in some scenarios, they can
represent a suitable solution, especially, when combined with other approaches. Theoretic
approaches to the problem have been demonstrated that self-protection of the problem is
unfeasible [71].
In some scenarios, the required protection is limited to some parts of software (code
or data). In this way, a function performed by the software, or the data processed, must
be hidden from the host where the software is running. Some of these techniques require
an external offline processing step in order to obtain the desired results. Among these
schemes, function hiding techniques allow the evaluation of encrypted functions [33]. This
technique protects the data processed and the function performed. We consider that as
an appropriate technique for protecting agents. However, it can only be applied to the
protection of polynomial functions.
Another interesting approach is the case of online collaboration schemes where part of
software functionality is executed on one or more external computers. The security of this
approach depends on the impossibility of each party to identify the function performed
by the others. This approach is very appropriate for distributed computing architectures
such as agent-based systems or grid computing, but has the important disadvantage of
each agent has to be executed by another agent in another host. The scheme is suitable
for protecting a set of several mutually dependent agents. A conspiracy of all hosts is
necessary in order to attack the system.
To split the code into parts a developer uses an automatic Code Partitioning Tool
(CPT). Since code partitioning is a difficult task and specific expertise is required for
performing it, such a tool eases the code partitioning according to a set of rules that
we call protection profiles. The outcome of the operation of this tool is a set of public
parts and a set of private parts. These parts will be used in a different way depending
on the mutual protection scheme applied (static or dynamic). One can protect code by
means of data protection, i.e. by marking the data to be protected. For this purpose
the tool allocate the instructions to protect taking into account java labels such as final,
static, etc. One can protect code by means of instructions. In order to do that the tool
has a classification of instructions and a developer marks the type of instructions to be
protected (or a group of them). A combination of both techniques can be applied if the
code requires such. A developer sets up the protection profile and adjusts it to get the more
suitable configuration for his requirements. Another important approach is marking the
code to be protected while it is being developed, rather than performing the configuration
by means of a protection profile. One could even select parts of code to be protected.
Then the Java compiler marks those byte codes, by developer command, adding some
annotations. A developer according to the code and context restrictions must command
data protection. However, instructions protection is suitable to be automated. For this
purpose we grouped the byte code instruction set, currently consisting of 212 instructions.
Strategies for securing agents. There are two distinguished strategies for securing agents.
A Static Mutual Protection (SMP) strategy defines collaboration between agents in a
predefined manner so that every agent has the private parts of code of one or more agents
it is collaborating with. A Dynamic Mutual Protection (DMP) strategy defines any of the
collaborating agents to play the role of a secure coprocessor to any other agent. In this case,
interactions between agents are not predefined. This DMP strategy is more powerful and
flexible than the SMP strategy, but it also adds more complexity and reduces performance
of agents.
The SMP strategy increases the performance of agents by avoiding the transmission of
protected code sections over the network. It is suitable in those scenarios where the set of
agents to be protected is static and determined before their actual execution. An example
of possible application of this scheme is that of a competitive bidding. In this scenario a
client requests bids from several contractors to provide a good or a service. It is important
that the bidding takes place simultaneously, so that none of the contractors can access the
offer from the other contractors, because this would give it advantage over the others. The
client can use several single-hop agents to collect the offers from the contractors. Every
agent will protect each agent, using the SMP strategy.
We can also safely assume that a coalition of all contractors will not happen. In fact,
no technological solution can prevent all contractors to reach an external agreement. Be-
cause each agent is protected by other agents running in the hosts of the competitors,
and because the protected computing model ensures that it is neither possible to discover
nor to alter the function that the agents perform and it is also impossible to impersonate
the agents. We know that all agents will be able to safely collect the bids, guaranteeing
the fairness of the process. There are scenarios where it is not possible to foresee pos-
sible interactions between agents, or where agents are generated by different parts, or
involvement of very dynamic multi-hop agents. In these cases the DMP strategy is more
appropriate to apply where each agent will be able to execute arbitrary code sections on
behalf of other agents in the society.
We have defined a Dynamic Protection Tool (DPT) that allocates into every agent a
little virtual machine code. This virtual machine executes public and private code from
other agents on the fly. Doing this, there will be no necessity of fixed assignations between
agents because every agent is a potential secure processor for the rest of the agents in the
system [49]. Ongoing work is focused on two directions:
Prototyping automatic tools for code partitioning driven by a policy specification.
The focus of this direction is on flexibility and adaptability of those tools to different
parameters in policies.
Expanding the dynamic mutual protection approach in the context of DPT. The
main task here is to identify problems rose when put together concepts of dynamism,
virtual machine and agent private parts. This is because possible deadlocks or other
problems could rise from this paradigm.
Design of solutions for building secure agent-based systems, along with the necessary
tools to facilitate the use of these solutions by non-specialist developers.
solution is a library that implements the secure migration protocol designed. The imple-
mentation of the second solution in which a priori presents more difficulties has also been
realized by a set of tools designed to facilitate the application of this technique by average
developers.
A.6. Conclusions
We conducted a detailed study of the problem of protecting agent-based systems,
looking at different aspects, we have described the objectives to be covered in each case.
The solutions developed focus on two different approaches: one for providing a secure
solution based on the use of an external element and the other proposes a solution that
uses of the capacity for collaboration between agents to solve a problem, as the basis
for ensuring the security, as described in Chapter 2. In this thesis we show how both
mechanisms can be used in different scenarios for the protection of the global system.
We have also conducted an analysis of different existing protection mechanisms at
both academic and industrial levels, and we have classified them based on the nature
of the mechanism itself. We have shown how existing solutions are inadequate, in most
cases because they are based on the direct application of solutions designed for software
in general and not designed for multi-agent systems. In other cases we have observed that
the application of existing solutions requires that the developers have an exhaustive un-
derstanding of security mechanisms. As part of the review of relevant work, we have noted
that an alternative to ensure the protection of multi-agent systems is based on trusted
computing platforms. In particular, we have worked with the most relevant initiative in
this field: the one represented by the Trusted Computer Platform Alliance. That approach
has led to the design of the solution presented in Chapter 2.
For the validation of this solution we have decided to take two alternative paths, which
provide a higher level of robustness of the solution. First we performed a formal validation
of the secure migration protocol of our solution. We have done so using a powerful set of
tools known as AVISPA. On the other hand, we have applied the solution to a real world
use case and have designed a system that functions as a nuclear power plant simulator in
which we have built an agent-based system that monitors the proper functioning of each
of the parts of the system. Obviously, this scenario requires a high level of security.
lity, organic growth, mobility and many other features which will require more complete
software engineering methods and new software innovative modeling languages [74].
Ambient Intelligence (AmI) is focused on adapting our environment in a way that
is sensitive to our needs and responds intelligently to users behaviour and to changing
contexts [64]. It is expected that the objects that surround us in our daily lives act au-
tonomously without human intervention. This type of ambient intelligence environments
are intimately related to the concept of ubiquitous computing, as it is intended to provide
people services and utilities in a transparent way, without explicit requests from users.
The agent paradigm is very promising for the implementation of complex systems such as
electronic commerce, air traffic, enterprise resource planning, etc. [66]. Initially developed
within the field of Artificial Intelligence, the scientific community has found other areas in
which fruitful exploitation of the paradigm of the agent is possible. As advocated in [67]
and [68], this paradigm has received a special interest in software engineering because it
provides advantages over the paradigm of object orientation in distributed and autonomic
computing scenarios.
One of the weaknesses of Ambient Intelligence environments is the lack of models and
software engineering practices that aid in the analysis of requirements, design, verification,
testing, etc. So far research in this area is in its early stages, and the need for viable
development methodologies is becoming widely recognized. We believe that the agent
paradigm is useful not only for the implementation of AmI systems, but also in all phases of
the engineering and development cycle. We are aware that the new methodologies of agent-
oriented software engineering should be further reviewed and extended for engineering
Ambient Intelligence systems.
However, despite the attention given to agents by the research community, this techno-
logy has failed to gain wide acceptance, especially in industry, and has only been applied
in very specific and limited real world scenarios. This comes largely from the existence of
certain security issues, which indeed are considered the most urgent difficulty to solve in
this technology before it is ready to be used in the industrial landscape. Regarding secu-
rity, the agents exhibit interesting features and can cover security requirements coming
from different actors, with a natural model for achieving the objectives of each party in a
collaborative way. Clearly, this technology will not be mature enough to be used until the
most important security problems are solved. This consists both in finding the appropriate
mechanisms, as well as in facilitating the application of these mechanisms.
Traditionally, some of the protection mechanisms for general software systems have
been applied to the protection of agent-based systems. However, the special features of this
technology requires the use of specific solutions. Some protection mechanisms are oriented
to the protection of the hosts (agencies) against malicious agents. The most well-known
solution to this problem is the use of the concept of Sandbox. A Sandbox is a container
that limits or reduces the level of access that agents have and provides some mechanisms
to control the interaction between them. Another technique that addresses this aspect of
the problem is known as Proof Carrying Code (or PCC) [69], with this technique, each
code fragment includes a detailed test that can be used to determine if the security policy
the host is satisfied by the agent. The hosts need only to verify that the test is successful
(which means it matches the code) and is compatible with the local security policy, but
we must mention is that the application of this technique is not straightforward since
parties. Richard states that clouds is only a trap to force people to acquire proprietary
blocked systems, which will be increasingly more and more expensive.
However, there are a lot of advantages to this new technology, especially if we plan
a further step in the evolution of this technology. Hence “clouds computing” consists of
executing a set of data remotely by the clouds with the consequent user trustworthy
delegation in the cloud. Nevertheless, this model is restricted to functionalities offered by
provider and the user can only can execute those pieces of software included in the cloud.
We propose a step further allowing the user to send their own software establishing a
parallelism with agent technology, which are computation entities able to encapsulate any
code. Obviously, this new feature removes the limitations of current clouds criticized by
Stallman but the most important appeal is that the approaches in this thesis are perfectly
suitable to solve most of the security problems of this new model due to the fact that the
problem is a piece of code that is executed remotely in an external host.
Método de Trabajo
B.1. Investigación-Acción
En el año 1946 el investigador Kurt Lewin publica su trabajo titulado “Action Research
and minority problem” en el cual cita por primera vez el concepto de la Investigación-
Acción (IA). Lewin describe este método mediante un proceso de espiral de varios pasos
cada uno de los cuales está compuesto de los ciclos planificación, acción y búsqueda de
hechos acerca de los resultados de la acción [5]. Este método ha evolucionado considera-
blemente en los últimos años, en gran medida por la calurosa aceptación por parte de la
comunidad científica. La Investigación-Acción consiste en una clase de métodos que tienen
en común las siguientes características:
1. Orientación a la acción y al cambio.
2. Identificación de un problema.
3. Un modelo de proceso orgánico que engloba etapas sistemáticas y algunas veces
iterativas.
4. Colaboración entre los participantes.
La Investigación-Acción está orientada a la generación de cierto conocimiento de in-
vestigación relevante [6]. Es una forma colaborativa de investigación que pretende unir
159
Método de Trabajo
Otro problema es el del contexto de consultoría utilizado, ya que impone una pers-
pectiva demasiado restrictiva por la implicación de responsabilidades contractuales
e intereses organizacionales que pueden ir en contra de lo propuesto por la misma
IA.
Estas tres causas llevan asociada una consecuencia inherente que es una falta de rigu-
rosidad del proceso de investigación, que es inadmisible. Para resolverlo se han propuesto
las siguientes alternativas:
Existe otra propuesta de proyecto de IA-SI en la que se definen dos ciclos caracterís-
ticos:
Ciclo orientado a construir una solución para generar nuevo conocimiento útil a
profesionales y mejorar su práctica. El investigador interviene activamente en la
realidad y se utiliza la investigación para construir modelos, teorías o conocimiento
de manera informada y evidentemente influida por la realidad. En este ciclo, el
interés por resolver un problema es lo que origina el interés por la investigación.
el cuadro B.2. Para el caso particular de un solo investigador, en que la supervisión está
a cargo de un tutor con evidentes limitaciones de tiempo.
ción que sea realmente útil y de calidad. Se recomienda hacer un registro de los resultados
de las búsquedas. Esto puede servir para justificar la necesidad de investigar en algún área
específica, o para demostrar, cuantitativamente, que los trabajos de una determinada área
son escasos, o que son muy heterogéneos, o simplemente para demostrar la rigurosidad
con que se ha realizado el proceso de búsqueda.
Finalmente, es importante tener en cuenta que el proceso de búsqueda es perfectible,
por lo que el protocolo puede y debe ser mejorado durante el desarrollo de la búsqueda, por
ejemplo, se pueden incorporar otros términos de búsqueda o realizar otras combinaciones
de los términos usados.
Evaluación planificación
Esta etapa consiste en hacer una valoración objetiva de la planificación. Ya que esta
propuesta se enmarca en el contexto del desarrollo de una tesis doctoral la evaluación de
la planificación tendrá que realizarla el tutor de la tesis para comprobar que efectivamente
se van cumpliendo los plazos previstos y tener la capacidad de reaccionar en caso contrario
antes de continuar.
Síntesis de datos
En esta sub-etapa, al igual que en las anteriores, se debe aplicar el protocolo definido
en la revisión. Consiste en registrar la información extraída de los estudios primarios si-
guiendo alguna estrategia definida. Los datos pueden ser sintetizados considerando, por
ejemplo, el enfoque que se le desea dar a la presentación del estado del arte o la identi-
ficación del o de los fenómenos de interés. Una vez analizados los diferentes mecanismos
existentes realizamos un estudio minucioso de cada uno de ellos, estableciendo una clasi-
ficación de los mismos en función del objetivo a proteger, ya sea el agente o la agencia.
Asimismo realizamos un estudio de las debilidades y puntos fuertes de cada uno de estos
mecanismos.
detalla en el capítulo 2. El tercer rol a identificar es que se relaciona con el grupo crítico,
que es aquel para quien se investiga, en nuestro caso es el grupo GISUMSEC, subgrupo
perteneciente al grupo de investigación GISUM dentro del departamento de lenguajes y
ciencias de la computación de la Universidad de Málaga. Y por último no resta que iden-
tificar el rol del beneficiario, que en este caso es un grupo muy amplio de desarrolladores
pertenecientes a la comunidad de los agentes móviles, puesto que todo el esfuerzo puesto
en la mejora de esta tecnología va a repercutir en los beneficios obtenidos por la aplicación
de los mismos.
Previamente describíamos los diferentes tipos de Investigación-Acción que nos podía-
mos encontrar, de diagnóstico, participativa, empírica y experimental. En principio este
trabajo comenzó siendo un trabajo de diagnóstico que evolucionó a un trabajo con carác-
ter participativo. Vamos a describir cada una de las etapas que han guiado este trabajo de
investigación. Hemos de mencionar el hecho de que estas etapas forman uno de los ciclos
del proceso que se ha iterado varias veces hasta obtener los resultados esperados.
La primera de las etapas es la correspondiente a la planificación en la que obtuvimos
los puntos más importantes que guiaron nuestra investigación que, por su parte, están
en íntima relación con el objetivo que se tomó inicialmente para la investigación. En
esta etapa se pretendieron exponer las posibles alternativas para resolver el problema
planteado. El objetivo planteado proporciona cierto mecanismo de seguridad robusto para
los sistemas basados en agentes móviles, de manera que la utilización del mecanismo no
implicase profundos conocimientos en el área de la seguridad ni complicados métodos
de aplicación, que en definitiva no son viables en la práctica. Para ello se planteó la
utilización de un dispositivo criptográfico para la protección tanto de los agentes como de
las agencias, el siguiente paso era la elección del dispositivo. En gran medida debido a sus
propiedades nos decantamos por el uso de TPM y de tarjetas inteligentes. Sin embargo, en
el transcurso de esta disyuntiva y debido a los trabajos previos desarrollados con tarjetas
inteligentes, pensamos en el uso del sistema smartprot para el mismo objetivo. Lo cual
nos ofrecía otra vía alternativa de trabajo, que finalmente quedó abierta y se trabajó en
paralelo en ambas líneas. Por un lado una solución basada en TPM y otro modelo que
usa la “computación protegida”.
La siguiente etapa, correspondiente a la acción como hemos mencionado se trata de
una variación de la práctica cuidadosa, deliberada y controlada efectuando una simula-
ción de la solución. En nuestro caso de investigación realizamos dos soluciones, en conso-
nancia con la planificación obtenida. La primera de las soluciones utiliza como base un
hardware criptográfico específico y está completamente elaborada usando el lenguaje de
programación java, completamente integrado en la plataforma JADE. Y la segunda de las
soluciones, siguiendo la misma filosofía también ha sido completamente desarrollada en
java y sobre la plataforma JADE. Para esta segunda solución se han proporcionado una
serie de herramientas para facilitar la aplicación de la metodología desarrollada.
La observación, recogida de información, toma de datos y documentación de lo suce-
dido junto con la reflexión y análisis de los resultados, al igual que las etapas anteriores se
han ido realizando de forma iterativa y conjunta. Gracias a esta fase hemos podido apre-
ciar la importancia de las herramientas de soporte para la aplicación de la metodología de
“computación protegida” puesto que desde el punto de vista de un ingeniero de seguridad
la solución es fácilmente entendible, sin embargo son necesarios suficientes conocimientos
También hemos diseñado una serie de herramientas muy útiles para la obtención
de un sistema de agentes seguro haciendo uso de la metodología de la computación
protegida. La base de esta metodología consiste en establecer una serie de vínculos
de dependencia entre todos los agentes del sistema, que son fruto de una partición y
repartición del código de los agentes del sistema. Esta solución puede resultar más
compleja que la anterior, no obstante también se ha facilitado la tarea mediante el
desarrollo de herramientas automáticas de apoyo.
Hemos aplicado ambas tecnologías a sistemas de agentes móviles reales, para los
que hemos obtenido unas mejoras muy ventajosas en lo que a seguridad se refiere,
especialmente en comparación con los sistemas previos, sin verse perjudicado el
rendimiento del sistema.
173
Diseño de la Solución basada en Hardware
embargo al usar mensajes ACL sólo se detecta si existe el destino cuando transcurre
un tiempo y no se recibe respuesta.
Tanto el método doMove como el doClone pueden ser ejecutados por cualquiera que
tenga una instancia de la clase Agent, por lo que pueden ser llamados tanto por el propio
agente como por la plataforma que lo contiene.
Para crear un agente seguro, el programador únicamente deberá crear una clase que
herede de SecureAgent y redefinir los métodos secureMoveError y secureCloneError de-
finiendo el comportamiento esperado, ya que ambos son métodos abstractos. Con esto
tendremos definido el interfaz de uso de la librería, que como podemos ver es bastante
sencillo. Sin embargo, lo visto hasta el momento no ofrece directamente ninguna funciona-
lidad, por lo que la librería incluye más elementos importantes que realizan las acciones.
Entre estos elementos se encuentran los servicios que permiten llevar a cabo la migración
en sí de manera segura. Puesto que estamos trabajando sobre JADE, hemos de mencionar
que cualquier servicio JADE debe implementar:
Los interfaces Helper y Slice. En JADE, los agentes pueden usar los servicios pro-
porcionados por el contenedor. Para ello deben primero obtener un interfaz que les
permita acceder al servicio. Como vimos en el capítulo 3, este es el interfaz Helper,
al cual puede acceder el agente simplemente a través del nombre del servicio. Sin
embargo, no todos los servicios proporcionan un Helper. Además de este interfaz de
acceso, el servicio debe proporcionar el interfaz Slice, que sirve para que el servicio
pueda comunicarse con otros servicios pertenecientes a contenedores diferentes.
La clase ServiceComponent, que sirve para tratar los comandos de otros servicios
recibidos a través del proxy.
En la figura C.3 podemos ver el diagrama de clases de un servicio completo. Una vez
vista la estructura de las clases que componen un servicio vamos a pasar a realizar una
descripción de los servicios específicos de la librería de migración segura.
El interfaz SecureAgentMobility Slice define una serie de métodos que servirán para
que el servicio pueda interactuar con servicios pertenecientes a otros contenedores, ya que
el servicio, para poder realizar su funcionalidad, debe contactar con servicios de otros
contenedores. En la figura C.5 podemos ver el protocolo que sigue el servicio SecureA-
gentMobility para comunicarse con la instancia del mismo servicio perteneciente a otro
contenedor.
Este diagrama muestra un caso en el que el agente solicita al servicio que lo mueve a
un contenedor (C2). Los pasos son los siguientes:
En el diagrama de la figura C.5 se muestra al servicio como una entidad única. Sin embar-
go, para realizar la acción mostrada sería necesaria la participación de varios componentes
pertenecientes al servicio que se han omitido en aras de la claridad del protocolo. Otro
aspecto importante es que es el mismo servicio el que inicia la migración del agente in-
vocando al método doMoveOriginal, cuyo funcionamiento es exactamente el mismo al de
doMove de la clase Agent, es decir, migra al agente hacia el destino. Este método se
invoca sólo después de que se haya comprobado que la agencia destino efectivamente es
segura. De esta manera se consigue dotar al método doMove de la clase SecureAgent de
un comportamiento similar al doMove de la clase Agent.
El protocolo consta de cuatro mensajes básicos que describimos a continuación:
getAIKCredentials(): nos devuelve las credenciales de la AIK usadas para firmar los
PCR.
getPCRSelection(): nos devuelve los índices de los PCR cuyos valores se han firmado.
getNonce(): nos devuelve el valor nonce usado para evitar ataques de repetición.
getSignedPCR(): nos devuelve los datos de los PCR firmados con la clave privada
de la AIK.
Ambas clases encapsulan los datos de los mensajes que componen el protocolo para
realizar la atestación. En cada mensaje el contenedor correspondiente va completando los
datos necesarios usando los métodos “set”, para que el otro contenedor pueda seguir con
el proceso de atestación. Para completar los datos de los mensajes el servicio SecureA-
gentMobility hace uso de la clase AttestTool_Implement, como ilustra la figura C.6
ATT_BUSY: El servicio del contenedor origen o del contenedor destino está ocu-
pado y no puede atender la petición.
Este código de errores es el que permite al agente determinar lo sucedido cuando se recibe
una llamada a los métodos doMoveError y doCloneError.
Para poder generar y verificar los datos contenidos en los mensajes de atestación es
necesario el uso del TPM y de una CA. El TPM ofrece la funcionalidad necesaria para
poder generar los datos de atestación, la generación de la AIK, la producción de la firma
y la de valores nonce. Por su parte, la CA permite generar credenciales que certifiquen las
AIK para que los demás contenedores puedan confiar en los datos firmados por esas AIK.
El interfaz TPM_Interface proporciona acceso a las diferentes funcionalidades del
TPM:
reqData: esta llamada que será enviado a una CA para poder certificarla.
getNonce(): devuelve un valor nonce aleatorio, para evitar ataques por repetición.
getTPMQuoteInfo(byte[] nonce, int[] pcrs): devuelve los valores de los PCR cuyos
índices se indican en el parámetro pcrs junto con el nonce especificado en el pará-
metro.
getPCRSelection(): devuelve los índices de los PCR que se solicitarán a los conte-
nedores remotos para conocer su configuración.
Un aspecto importante del protocolo de la figura C.1 es el uso de una AIK para firmar
los datos de atestación. La AIK la genera el TPM y debe ser certificada por una CA. En
la figura C.7 vemos el protocolo que muestra la forma en la que se genera y certifica esta
clave.
Como se aprecia en el diagrama, los pasos son:
En este proceso intervienen una serie interfaces que se corresponden a los diferentes valores
que se envían y reciben en el protocolo. Estos interfaces son:
AIKResponse_Interface: contiene los datos necesarios para que el TPM pueda ob-
tener las credenciales generadas por la CA.
En la figura C.8 podemos ver cuál es el protocolo que sigue el servicio para realizar la
migración segura.
Los pasos que realiza el servicio para realizar la migración segura son:
2. El servicio S1 envía una solicitud de atestación remota al servicio S1M del contenedor
principal de su plataforma.
Como vemos, el servicio del contenedor origen necesita la participación del servicio
del contenedor principal para que contacte con el servicio de manejo de agentes (AMS)
de la plataforma destino. Esto es necesario ya que sólo es posible acceder a la clase que
implementa al AMS desde el contenedor principal. La comunicación entre los AMS de
la plataforma origen y destino se realiza mediante mensajes ACL. El AMS destino usa
la clase AttestTool_Implement para tratar los mensajes del servicio, mientras que en el
origen los mensajes son tratados por AttestTool_Implement en el servicio del contenedor
origen. El funcionamiento del servicio en lo que respecta a todos los demás componentes
es igual al del servicio SecureAgentMobility, por lo que los daremos por analizados.
1. Se realiza una llamada al método doMove de la clase SecureAgent, lo que provoca que
se llame al método secureMove de la clase SecureInterPlatformMobility HelperImpl
perteneciente al servicio SecureInterPlatformMobility del contenedor origen.
[6] F. Kock, N. Lau. Information systems action research: Serving demanding mas-
ters. Information Technology and People (special Action Research in Information
Systems)., 14(1):6–11, 2001.
[7] G. Padak, N. Padak. Guidelines for planing action research projects. Ohio Literacy
Resource Center., 1994.
[8] J. Estay, C. Pastor. Improving action research in information systems with project
management. Proceedings of the 2000 Americas Conference on Information Systems,
Long Beach, California (USA)., pages 1558–1561, 2000.
[10] F. Lau. A review on the use of action research in information systems studies. In
Information Systems and Qualitative Research. Chapman and Hill. London., pages
31–68, 1997.
193
Diseño de la Solución basada en Hardware
[15] D. Benos, K. Kirk, and J. Hall. How to review a paper. Advances in Physiology
Education., 27(2):47–52, 2003.
[16] Antonio Muñoz and Antonio Maña. Tpm-based protection for mobile agents. Inter-
national Journal of Security and Communication Networks and Information Security,
1, November 2009.
[17] A. Muñoz, A. Maña, and D. Serrano. The role of trusted computing in the secure
agent migration. ACM Computing Surveys, 6(5):30–58, November 2009.
[18] Antonio Maña, Antonio Muñoz, and Daniel Serrano. Towards secure agent computing
for ubiquitous computing and ambient intelligence. In Jadwiga Indulska, Jianhua Ma,
Laurence Tianruo Yang, Theo Ungerer, and Jiannong Cao, editors, UIC, volume 4611
of Lecture Notes in Computer Science, pages 1201–1212. Springer, 2007.
[19] Javier Lopez, Antonio Maña, and Antonio Muñoz. A secure and auto-configurable
environment for mobile agents in ubiquitous computing scenarios. In Jianhua Ma,
Hai Jin, Laurence Tianruo Yang, and Jeffrey J. P. Tsai, editors, UIC, volume 4159
of Lecture Notes in Computer Science, pages 977–987. Springer, 2006.
[20] N. Karnik. Security in Mobile Agents systems. PhD thesis, Department of Computer
Science, University of Minnesota., 1998.
[23] William M. Farmer, Joshua D. Guttman, and Vipin Swarup. Security for mobile
agents: Issues and requirements, 1996.
[24] W. Jansen and T. Karygiannis. Mobile agent security. Nist special publication 800-19,
National Institute of Standards Technology., 2000.
[25] Volker Roth. Mutual protection of co-operating agents. In Secure Internet Program-
ming: Security Issues for Mobile and Distributed Objects, pages 275–285. Springer-
Verlag Inc, 1999.
[27] J. Mir and J. Borrell. Protecting mobile agent itineraries. In Mobile Agents for
Telecommunication Applications (MATA), volume 2881 of LNCS, pages 275–285.
Springer-Verlag, 2003.
[28] E.Bierman and E. Cloete. Classification of malicious host threats in mobile agent
computing. In Proceedings of the anual research conference of the South African
institute of computer scientists and information technologist on Enablement through
technology. South Africa Institure for Computer Scientists and Information Techno-
logists., pages pages 141–148., 2002.
[29] Y. Minsky, R. van Renesse, F. Schneider, and S.D. Stoller. Cryptographic support for
fault-tolerant distributed computing. In Seventh ACM SIGOPS European Workshop.,
1996.
[30] F. Hohl. A framework to protect malicious hosts attacks by using reference states.
In International conference on distributed computing systems (ICDCS), 2000.
[31] G. Vigna. Cryptographic traces for mobile agents. In Mobile Agents and Security.,
volume 1419 of LNCS. Springer-Verlag., 1998.
[32] F. Hohl. Time limited blackbox security: Protecting mobile agents from malicious
hosts. In Mobile Agents and Security., volume 1419 of LNCS. Springer-Verlag., 1998.
[33] Sander and C.F. Tschudin. Protecting mobile agents against malicious hosts. Mobile
Agents and Security, 1419 of LNCS. Springer-Verlag., 1998.
[35] J. Ordille. When agents roam, who can you trust? In Technical report, Computing
Science Research Center, Bells Lab, 1996.
[36] H. Kim and L. Moreau. Trust relationships in a mobile agent system. In Springer-
Verlag, editor, 5th International Conference on Mobile Agents (MA), volume 2240 of
LNCS, 2001.
[37] S.Robles. Mobile Agent Systems and Trust, a Combined View Toward Secure Sea-of-
Data Applications. PhD thesis, Universitat Autonoma de Barcelona, 2002.
[38] Sau-Koon Ng. Protecting Mobile Agents Against Malicious Hosts. PhD thesis, The
Chinese University of Hong Kong, 2002.
[39] J. Riordan and B. Schneier. Environmental kay generation towards clueless agents.
In Springer-Verlag, editor, Mobile Agents and Security, volume 1419 of LNCS, 1998.
[40] Bennet S. Yee. A sanctuary for mobile agents. In Secure Internet Programming,
pages 261–273, 1997.
[55] David Basin, Sebastian Modersheim, and Luca Vigano. An on-the-fly model-checker
for security protocol analysis. In In Proceedings of Esorics, LNCS 2808, pages 253–
270. Springer-Verlag, 2003.
[56] Per Bjesse and Koen Claessen. Sat-based verification without state space traversal.
In In Formal Methods in Computer-Aided Design, pages 372–389. Springer, 2000.
[57] Y. Boichut, P-C. O Kouchnarenko, and F. Oehl. Improvements ont the genet and
klay technic to automatically verify security protocols. In AVIS, ENTCS, 2004.
[58] Antonio Muñoz, Antonio Maña, and Daniel Serrano. Avispa in the validation of
ambient intelligence scenarios. Availability, Reliability and Security, International
Conference on, 0:420–426, 2009.
[59] Iliano Cervesato. The dolev-yao intruder is the most powerful attacker. In Proceedings
of the Sixteenth Annual Symposium on Logic in Computer Science | LICS’01, pages
16–19. IEEE Computer Society Press. Short, 2001.
[60] Angelo Troina, Ro Aldini, and Roberto Gorrieri. The java virtual machine specifica-
tion, http://java.sun.com/docs/books/vmspec. In In Proc. of GC’04, volume 3267
of Springer LNCS, pages 77–92, 2005.
[61] Eric Bruneton, Romain Lenglet, and Thierry Coupaye. Asm: A code manipulation
tool to implement adaptable systems. In In Adaptable and extensible component
systems, 2002.
[62] Markus Dahm. Byte code engineering with the bcel api. 2001.
[63] Norbert A. Streitz, Achilles Kameas, and Irene Mavrommati, editors. The Disap-
pearing Computer, Interaction Design, System Infrastructures and Applications for
Smart Environments, volume 4500 of Lecture Notes in Computer Science. Springer,
2007.
[65] Julio Abascal. Ambient intelligence for people with disabilities and elderly people.
acm’s. In Special Interest Group on Computer-Human Interaction (SIGCHI), Am-
bient Intelligence for Scientific Discovery (AISD) Workshop, 2004.
[66] Anand S. Rao and Michael P. Georgeff. Bdi agents: From theory to practice. In In
proceedings of the first International Conference on Multi-Agent Systems (ICMAS-95,
pages 312–319, 1995.
[67] Michael Wooldridge, Nicholas R. Jennings, and David Kinny. A methodology for
agent-oriented analysis and design, 1999.
[70] J. Stern, G. Hachez, F. Koeune, and J.J Quisquater. Robust object watermarking:
Application to code. In Info Hiding, Springer-Verlag., volume LNCS 1768., pages
pp. 368–378, 1999.
[72] Siani Pearson. Trusted computing: Strengths, weaknesses and further opportunities
for enhancing privacy. In Peter Herrmann, Valérie Issarny, and Simon Shiu, editors,
iTrust, volume 3477 of Lecture Notes in Computer Science, pages 305–320. Springer,
2005.
[73] Nicholas Carr. The Big Switch: Rewiring the World, from Edison to Google. W.W.
Norton & Company, 2009.
[74] John Krogstie, Kalle Lyytinen, Andreas Lothe Opdahl, Barbara Pernici, Keng Siau,
and Kari Smolander. Research areas and challenges for mobile information systems.
Int. J. Mob. Commun., 2(3):220–234, 2004.
[76] Boaz Barak, Oded Goldreich, Russell Impagliazzo, Steven Rudich, Amit Sahai, Salil
Vadhan, and Ke Yang. On the (im)possibility of obfuscating programs. In Lecture
Notes in Computer Science, pages 1–18. Springer-Verlag, 2001.
[78] A. Maña, J. López, J. Ortega, E. Pimentel, and J. Troya. A framework for secure
execution of software. International Journal of Information Security, 3(2)(2004),
Novembre 2004. ISSN 1615-5262 (Print) 1615-5270 (Online).