Como consecuencia de la generalización del ordenador personal y la aparición de la gran cantidad de dispositivos móviles disponibles hoy en día, el número de máquinas que utiliza al mismo tiempo un usuario ha crecido sustancialmente. Estos dispositivos son básicamente ordenadores, que aunque poseen distintas cualidades físicas y funcionales, ejecutan un sistema operativo convencional y están sometidos a las mismas necesidades de configuración y administración que un ordenador común. Entre esas necesidades se encuentra el proceso de identificación del usuario y su posterior autenticación. El proceso de autenticación se realiza normalmente mediante la introducción de contraseñas por teclado, aunque se han propuesto métodos que proporcionan menos obstrucción al usuario, como la autenticación mediante tarjetas Smartcard\cite{smartcard}, Ibuttons\cite{ibutton}, USB Tokens\cite{rsasecurity} o dispositivos biométricos como lectores de huellas digitales. Esos métodos, aun siendo menos incómodos para el usuario que la introducción de contraseñas, siguen proporcionando obstrucción. Por otra parte, dependen de dispositivos lectores específicos que normalmente no están integrados en los propios dispositivos. Esto supone un problema a la hora de usar dispositivos móviles y máquinas de propósito general. Los sistemas tradicionales que proporcionan entrada simple al sistema ({\em Single Sign-On}) están diseñados para entornos cliente/servidor en los que los usuarios trabajan con un único terminal, desde el que acceden a todos los servicios del entorno distribuido. Sin embargo, los usuarios de un entorno de computación como el presentado en capítulos anteriores no trabajan en un sólo ordenador, sino que utilizan e interaccionan físicamente con un grupo de ordenadores interconectados. De esta forma, el usuario necesitará autenticarse ante cada uno de los ordenadores que integran el espacio con el que está interaccionando. Teniendo en cuenta que la aparición de nuevos dispositivos en el sistema tiende a crecer debido a la progresiva miniaturización y el abaratamiento de los dispositivos móviles que dictó Moore\cite{moore65cramming}, el problema de la autenticación adquiere un importante papel en este tipo de entornos. Bajo estas circunstancias, los sistemas tradicionales de entrada simple al sistema que se han tratado en el capítulo dedicado al estado de la cuestión proporcionan una gran obstrucción al usuario. La autenticación explícita por parte del usuario rompe la ilusión de que el entorno ubicuo es un único sistema y no un grupo de sistemas interconectados. Por lo tanto, el uso de este tipo de sistemas de entrada simple al sistema no es propicio para un entorno ubicuo. SHAD propone una solución para este problema basada en agentes que actúan como servidores personales de claves para el usuario. Estos agentes tienen como objetivo proporcionar al usuario un acceso simple y sin obstrucción al entorno de computación ubicuo, haciendo el uso de varias máquinas a la vez cómodo, seguro y parcialmente transparente (dependiendo de las necesidades y preferencias plasmadas por el usuario) en lo que respecta a la autenticación. Mediante los agentes SHAD, los dispositivos que pertenecen a un mismo usuario pueden compartir sus secretos (claves, contraseñas, etc.), propiciando un acceso simple al entorno ubicuo y conservando la ilusión de que se está trabajando en un único sistema. A continuación, se presentará la arquitectura de SHAD para ofrecer una entrada simple al sistema. \section{Arquitectura del agente de SSO} \label{sso_cond} La arquitectura general del sistema se presenta en la figura \ref{arch0}. Como se puede observar, la arquitectura se compone de entidades principales: \begin{figure*}[t!] \centering \epsfig{file=figuras/sso_0.png, width=\textwidth} \caption{Arquitectura global del sistema de entrada simple (Single Sign-On) al sistema basada en SHAD} \label{arch0} \end{figure*} \begin{itemize} \item {\bf repositorio de secretos} del usuario es un fichero cifrado que contiene los secretos de usuario en un formato legible para los humanos. El repositorio de secretos además incluye información que describe y restringe el uso de los mismos. Este fichero se encuentra cifrado con un algoritmo fuerte, y su contenido nunca se almacena en un soporte no volátil en claro. El repositorio se puede almacenar de un soporte externo (p.e. de una tarjeta de memoria SD Card) o en un servidor centralizado \footnote{Nótese que si se obtiene de un servidor centralizado, el usuario deberá tener interconexión con esa partición de la red en el momento de obtenerlo, pudiendo peder la conectividad después de obtener el repositorio. En el caso de usar un soporte externo, como una tarjeta SD card, el repositorio se puede obtener sin tener conectividad con el resto del sistema}. Además de los secretos del usuario, el repositorio contendrá las claves necesarias para contactar y autenticar las máquinas del usuario. \item {\bf Aplicaciones.} Las aplicaciones son programas de usuario que acceden a los servicios disponibles en el entorno ubicuo y fuera del mismo.. Comúnmente, estas aplicaciones necesitan autenticarse de alguna forma (mediante contraseñas, respuestas de retos, obtención de credenciales, etc.) ante los servidores del sistema. Para llevar a cabo dicha autenticación, los programas necesitan conocer secretos que normalmente les proporciona el usuario mediante un dispositivo de entrada. Las aplicaciones pueden elegir entre: (i) intentarán obtener los secretos del agente SHAD local y gestionar ellas mismas la autenticación o (ii) delegar la autenticación en el agente SHAD local, de tal forma que la lógica de la aplicación esté totalmente desacoplada de la lógica de seguridad. En el caso de que el agente SHAD no responda o no pueda llevar a cabo la autenticación, las aplicaciones reclamarán el secreto al usuario de la forma tradicional. \item {\bf Sistema Operativo.} El sistema operativo proporcionará a las aplicaciones el acceso al agente SHAD local. \item {\bf El usuario.} El usuario del sistema es un humano que interacciona físicamente con el entorno ubicuo. El humano es el encargado de administrar sus propios dispositivos, como ya se ha explicado en el capítulo anterior. Además, debe realizar una primera y única autenticación explicita para entrar en el sistema, que servirá para descifrar el repositorio de secretos. También puede añadir nuevos secretos (que no están almacenados en el repositorio) a sus agentes. Por último, el usuario puede proporcionar confirmaciones, que pueden requerirse para permitir la delegación de ciertos secretos. El usuario puede cancelar y confirmar operaciones interactuando con el agente SHAD principal. \item {\bf El espacio inteligente} o entorno ubicuo, que puede ofrecer servicios tales como localización física de personas y objetos. El sistema de Single Sing-On puede sacar partido de la información de localización, por ejemplo para pedir confirmación al usuario en ciertas situaciones. En todo caso, la arquitectura no puede depender de la información suministrada por el espacio inteligente, ya que puede provocar dependencias de servicios centralizados. Por lo tanto, el agente de SHAD debe ser capaz de operar sin los servicios que le ofrece el entorno ubicuo. Ell agente principal accederá a dicha información usando mecanismos estándar que quedan fuera del ámbito de la arquitectura, por tanto la seguridad relacionada con dicha información no se tratará en este capítulo. Además, el agente SHAD principal podrá comunicar notificaciones al espacio inteligente para aprovechar las infrastructuras que ofrece para avisar al usuario de ciertas incidencias. \item{\bf Agentes SHAD.} Los agentes SHAD son los encargados de manejar la autenticación del usuario, normalmente sin la necesidad de interactuar con este, dependiendo de la configuración. Como se detallará más adelante, el usuario es capaz de configurar el comportamiento de los agentes según sus preferencias y su valoración del compromiso entre obstrucción y nivel de seguridad. Un agente SHAD puede actuar de dos formas distintas: como {\it agente principal} o como agente común. \end{itemize} Un agente de SHAD que actua como {\it agente principal} ofrece los secretos del usuario a los otros agentes SHAD, dependiendo de ciertas restricciones que serán tratadas más adelante. Cualquier agente puede asumir el rol de agente principal, dependiendo de los siguientes factores: %% solo puede haber un agente principal por partición de red <- falso, porque puede %% haber uniones posteriores y juntarse más de uno. \begin{itemize} \item El descubrimiento de otro agente SHAD actuando como agente principal. Cada dispositivo ejecutará su agente al arrancar, y este iniciará un proceso de descubrimiento del agente principal. Si el proceso de descubrimiento fracasa, el agente intentará adoptar el papel de agente principal. \item La capacidad de obtener el repositorio de claves del usuario. Si el repositorio de secretos se encuentra en un sistema remoto, el agente debe tener conectividad con dicho sistema. En caso de que el repositorio se encuentre en una tarjeta insertada en el dispositivo donde ejecuta el agente, este debe ser capaz de obtenerlo y copiar su contenido en la memoria principal. \item Una vez obtenido el repositorio, el agente debe ser capaz de descifrar su contenido. Para ello, el usuario debe realizar la {\bf única autenticación explícita} que se requiere para operar en el sistema. Si el usuario no se autentica explicitamente ante el agente SHAD, este no puede proclamarse como agente principal. Dicha autenticación explíta puede consistir en la introducción de una contraseña, o la utilización de alguna tecnoloía biométrica o de algún otro dispositivo de autenticación.. \end{itemize} Aunque cualquier dispositivo del usuario es capaz de ejecutar el agente principal, este está ideado para ejecutar en un dispositivo móvil que siempre se encuentra con el usuario. De esa forma, el usuario es capaz de atender a mensajes informativos relativos a la delegación de sus secretos y confirmar la delegación de determinados secretos. A su vez, el repositorio de secretos está ideado para obtenerse de una tarjeta de memoria directamente desde el dispositivo móvil, y de esa forma no depender de la conectividad para ofrecer {\em Single Sign-On} en una partición separada del resto del sistema. No obstante, el usuario es libre de ejecutar su agente principal en cualquiera de sus máquinas, y de obtener su repositorio de secretos desde un servidor centralizado si así lo desea. Una vez que un agente SHAD ha adoptado el papel de agente principal, entonces puede suministrar secretos a los agentes SHAD que ejecutan en otros dispositivos pertenecientes al usuario, que actuarán como clientes. Los agentes cliente solicitarán al agente principal los secretos requeridos por las aplicaciones que ejecutan en su dispositivo. La delegación de los secretos del usuario se lleva a cabo dependiendo de restricciones que tiene asociadas en el repositorio. En ningún caso se delegarán secretos a agentes SHAD que no puedan autenticarse ante el agente principal. Tampoco se podrán delegar secretos a agentes que no estén ejecutando en nombre del mismo usuario que el agente principal. En caso de fallo del agente principal, los agentes clientes pueden intentar contactar entre ellos para poder obtener secretos. Si un agente SHAD cliente intenta contactar con su agente principal para obtener un secreto y no recibe respuesta, entonces iniciará un protocolo para intentar obtener el secreto de otros agentes SHAD de su mismo tipo. Si finalmente no obtiene respuesta de algún agente que posea dicho secreto, el agente intentará obtenerlo directamente del usuario. En ese caso se preguntará al usuario mostrando un mensaje a través de la interfaz gráfica o de la consola del sistema local. \section{Diseño del Agente SHAD} \subsection{Modelado de flujo de datos } El diseño del prototipo se ha llevado a cabo mediante Diagramas de Flujo de Datos \cite{demarco79structured}. Los diagramas de este tipo tienen dos funciones principales: (i) describir la forma en la que los datos se transforman según pasan por el sistema, y (ii) definir las funciones que transforman o manejan los datos \cite{pressman97software}. Mediante estos diagramas, se pretende modelar la funcionalidad de los procesos y definir las entidades internas de los agentes SHAD\footnote{Sin embargo, en esta sección no se pretende realizar un análisis o modelado exhaustivo del sistema.}. La figura \ref{arch0} muestra las entidades externas con las que los agentes de SHAD intercambian información. Por lo tanto esa figura es lequivalente a un diagrama de contexto (diagrama de flujo de datos de nivel cero). Las entidades externas a un agente SHAD ya han sido definidas en la sección anterior. En los diagramas de nivel uno presentados en las figuras \ref{sso_dfdcli} y \ref{sso_dfdpri} se describe con más detalle el flujo de los datos entre las entidades internas de los agentes. Se han realizado dos diagramas distintos para describir el comportamiento del agente de SHAD, debido a que aunque los agentes son exactamente el mismo programa, pueden adoptar dos funcionalidades distintas dependiendo de las circunstancias que se den en tiempo de arranque. La figura \ref{sso_dfdcli} muestra el diagrama de flujo de datos de primer nivel de un agente SHAD común. Las entidades internas a un agente SHAD común son: \begin{itemize} \item {\bf Anillo de secretos (RI).} Es un almacén de datos que contiene los secretos del usuario. También almacena las claves de las máquinas pertenecientes al usuario. La memoria en la que se almacena el anillo de secretos debe estar lo más protegida posible (no debe poder depurarse ni volcarse a área de intercambio). \item {\bf Módulo de descubrimiento (DM).} Se encarga de descubrir al agente principal en tiempo de arranque. Cada dispositivo capaz de arrancar agentes de SHAD tiene que tener una clave privada asignada. Dicha clave privada ha debido asignarse en tiempo de configuración, y debe incluirse en el repositorio de secretos. De esta forma, el agente principal puede autenticar mensajes de cualquier dispositivo configurado para usar SHAD. La clave de la máquina se leerá de un componente hardware local. Si el módulo no es capaz de descubrir al agente principal, entonces intentará obtener el repositorio de secretos para convertirse él mismo en agente principal. Si logra descubrirlo, intentará establecer una sesión con él para poder reclamar secretos cuando sea necesario. \item {\bf Módulo de secretos (SM).} Es la entidad encargada de proporcionar autenticación a las aplicaciones. Puede proporcionar auteticación encargándose de la lógica de autenticación del servicio o proporcionando el secreto necesario para que la aplicación se encargue de ella. El usuario debe ser capaz de añadir nuevos secretos en el anillo a través de esta entidad. El módulo necesita usar un secreto para proporcionar autenticación a una aplicación. En primera instancia, intenta obtener el secreto del anillo. Si no es capaz de obtenerlo, insta al {\bf módulo recolector} para obtenerlo. \item {\bf Módulo recolector (RM).} Es el encargado de conseguir los secretos necesarios del agente principal. Para ello, se pone en contacto con el agente principal e inicia el protocolo de obtención de secretos. Si el protocolo no prospera, entonces pide al {\bf módulo Peer to Peer} que intente obtener el secreto.. \item {\bf Módulo Peer to Peer (P2PM).} Cuando el módulo recolector no es capaz de conseguir un secreto del agente principal, entonces el {\bf módulo de secretos} pide al {\bf módulo Peer to Peer} que intente conseguir el secreto de otros agentes SHAD comunes. El módulo P2P se pondrá en contacto con el módulo P2P de los otros agentes SHAD con este fin. El módulo P2P sólo podrá ofrecer los secretos marcados especialmente para ello mediante un atributo especial. \end{itemize} \begin{figure*}[t!] \centering \epsfig{file=figuras/sso_dfd1cli.png, width=\textwidth} \caption{Diagrama de flujo de datos de nivel correspondiente a un agente SHAD común.} \label{sso_dfdcli} \end{figure*} En la figura \ref{sso_dfd1pri} se pueden identificar las siguientes entidades internas dentro del agente principal: \begin{figure*}[t!] \centering \epsfig{file=figuras/sso_dfd1pri.png, width=\textwidth} \caption{Diagrama de flujo de datos de primer nivel del agente SHAD principal.} \label{sso_dfd1pri} \end{figure*} \begin{itemize} \item {\bf Anillo de secretos (RI).} Cumple la misma función que en un agente SHAD común. \item {\bf Módulo de secretos (SM).} Esta entidad cumple las mismas funciones que en un agente común, pero en el agente principa además obtiene el repositorio de secretos y lo descifra mediante la información obtenida mediante la única autenticación explícita del usuario. Acto seguido, almacena su contenido en el {\bf anillo de secretos}. \item {\bf Módulo proveedor (PM).} Esta entidad es la encargada de suministrar secretos a los agentes SHAD comunes, dependiendo de los atributos ligados a estos, la información de localización que obtiene del espacio inteligente, y la confirmación del usuario en los casos que sea necesario. \item {\bf Módulo de descubrimiento (DM).} Cumple la misma función que en un agente SHAD común. \item {\bf Módulo de anuncios (AM).} Es la entidad encargada de responder a los descubrimientos de los agentes del usuario que arrancan, y de establecer la sesión con ellos. \end{itemize} Varios de los flujos de datos mostrados en los diagramas de flujo se realizan entre entidades internas de distintos agentes: \begin{itemize} \item Descubrimiento del agente principal y establecimiento de sesión por parte del {\bf módulo de descubrimiento}, que es procesado por el {\bf módulo de anuncios} del agente principal. \item Petición de un secreto por parte del {\bf módulo recolector} de un agente común al {\bf módulo proveedor} del agente principal. \item Petición de un secreto por parte del {\bf módulo Peer to Peer} de un agente común al {\bf módulo Peer to Peer} de los agentes comunes disponibles. \end{itemize} Esos flujos de datos se deben implementar en un protocolo seguro, debido a que son flujos entre distintos dispositivos interconectados mediante una red insegura en la que puede haber terceros escuchando, replicando o inyectando mensajes, y donde la propia red puede perder o duplicar mensajes. En la siguiente sección se describirá en profundidad el protocolo diseñado para la transmisión segura de los secretos entre el agente servidor y los agentes clientes. \section{Protocolo} \subsection{Claves} El protocolo entre agentes SHAD se compone de varios tipos de mensajes, que a la vez se apoyan en tres claves privadas: \begin{itemize} \item \textbf{Clave dispositivo: } Cada dispositivo debe tener asignado un secreto que usará para autenticarse ante su agente principal. Ese secreto tiene que ser conocido por el agente principal del usuario para que se pueda establecer un canal seguro entre ambos. Para un terminal $Z$, la clave secreta de ese terminal será representada como $KT_{z}$. \item \textbf{Clave de sesión: } Es la clave que proporciona un canal seguro entre un agente común y su agente principal. Esta clave se genera aleatoriamente y se usa solo para una sesión. La clave la genera el agente principal de forma aleatoria, y se representa como $KS_{t^a}$ para un terminal $T^a$. \item \textbf{Clave de encarnación: } Junto con la clave de sesión, el agente principal proporciona una clave de encarnación a todos los agentes que inician una sesión con él. Esta es común para todos los agentes que inician su sesión con la misma encarnación del agente principal, y se utiliza para proporcionar seguridad al protocolo Peer to Peer realizado por el módulo MP2P. La encarnación del agente principal se define mediante el identificador de encarnación, que se representa como $E_{id}$, y su clave se representa como $KE_{id}$. Cuando el agente principal reinicia o decide cambiar de encarnación, genera otra clave de este tipo. Los agentes que arranquen desde ese momento obtendrán la nueva clave de encarnación. Los agentes que arrancaron en una encarnación anterior no podrán pedir servicio a la nueva encarnación. Un agente tampoco podrá usar su módulo MP2P con agentes de una encarnación diferente a la suya. \end{itemize} Para el diseño del protocolo, se usará el algoritmo de cifrado de clave simétrica AES~\cite{AES}, que es el algoritmo estándar de este tipo en la actualidad. Dicho algoritno se utilizará en modo CBC. A su vez, se usará el algoritmo SHA-1~\cite{SHA-1} para realizar los resúmenes. \subsubsection{ Terminología } \begin{itemize} \item El identificador del usuario $A$ se representa como $username_a$. \item El agente principal de un usuario $A$ se representa como $P^a$. \item Un agente cliente de un usuario $A$ se representa como $T^a$. \item Como ya se ha comentado con anterioridad, el algoritmo AES se usa en modo CBC, por lo que se necesitará utilizar un vector de inicialización. Este vector de inicialización se representa como $IV$, y se genera de forma aleatoria para cada mensaje enviado. \item Supongamos los datos $D$, \{$D$\}$_{K_s}$ representa los datos $D$ cifrados con el algoritmo AES usando $K_s$ como clave. \item Supongamos los datos $D$, \{$D$\}$_{SHA1}$ representa el resumen SHA-1 de los datos $D$. \item En todos los mensajes del protocolo se insertan datos generados aleatoriamente para evitar ciertos ataques relacionados con el vector de inicialización para el modo CBC de AES. Esos datos tendrán la longitud de un bloque AES y se representan como $random_b$. \item En el protocolo se usan números aleatorios que se incrementan en las respuestas, con el fin de verificar que la respuesta se corresponde con el mensaje enviado. Esos números, comúnmente denominados {\it nonces}, son números enteros sin signo de 32 bits de longitud. Se representan como $n_1$, $n_2$.. $n_n$. \item Con el fin de evitar ataques de replicación de mensajes, los agentes insertan marcas de tiempo en los mensajes. Esas marcas de tiempo se representan como $timestamp_{t^a}$ para una máquina $T^a$ . \end{itemize} \subsubsection{ Descarte de mensajes } Los mensajes se descartarán y el protocolo no prosperará siempre que: \begin{itemize} \item El número aleatorio ({\em nonce}) que se ha devuelto no coincide con el valor del {\em nonce} que se envió incrementado. \item El {\em nonce} que se recibe se encuentra en la lista (o cache) de {\em nonces} usados recientemente. Esa cache es lo suficientemente grande \footnote{ El número máximo de {\it nonces} en la cache se ha fijado en 2048, un número muy superior al que se llegaría a alcanzar en condiciones extraordinarias de uso. Ese valor ha sido por la experiencia y es un número razonable teniendo en cuenta la memoria que puede estar disponible en el dispositivo, incluso si es un dispositivo móvil.} como para albergar los números aleatorios usados en un intervalo de tiempo $\Delta$. Si en algún momento la cache de {\it nonces} llega a su límite, se entenderá que se está sufriendo un ataque de denegación de servicio mediante inundación y se abortará la ejecución del agente, informando antes al usuario de esta situación \footnote{ Nótese que para que un {\it nonce} llegue a entrar en cache, antes se ha tenido que verificar que el mensaje se ha creado con la clave necesaria (clave de terminal, clave de sesión, o clave de encarnación, dependiendo del tipo de mensaje). Por lo tanto, un ataque de estas características tan sólo puede llevarse a cabo generando mensajes maliciosos pero correctos (y eso implica el conocimiento de la clave utilizada para ese tipo de mensaje).}. \item La marca de tiempo insertada en el mensaje se considere desfasada. Siendo $time$ el reloj local, $timestamp$ estará desfasada sssi \begin{displaymath} |time - timestamp| \geq \Delta \end{displaymath} Por esa razón, los relojes de los dispositivos del entorno tienen que estar relativamente sincronizados \footnote{ La experiencia de uso nos muestra que un valor de 1800 segundos para $\Delta$ es razonable, ya que el margen de sincronización de relojes para los distintos dispositivos usados es bastante amplio (pueden estar desfasados un total de 30 minutos) y la cache de {\it nonces} es lo suficientemente grande como para no llenarse en ese tiempo incluso en situaciones de uso extremo.}. \item Los datos esperados en ciertas partes del mensaje no sean correctos. Por ejemplo, si la cadena de caracteres que identifica el tipo de mensaje no corresponde a ninguna de los tipos conocidos, se descarta el mensaje. \item Las firmas que se envían junto al mensaje no sean correctas. Una firma no es correcta si el receptor no puede crear una firma similar usando los mismos algoritmos, los mismos datos y la misma clave. \end{itemize} \subsection{ Protocolo de descubrimiento del agente principal} Supongamos que el usuario A posee un dispositivo que actúa como agente principal ($P^a$), y arranca un terminal $T^a$ que le pertenece. En este caso sólo se utilizan dos tipos de mensajes. Los mensajes se identifican mediante un identificador en forma de cadena de caracteres: \begin{itemize} \item \textbf{``ineedmainagent" (INMA)}: mensaje de descubrimiento del agente principal del usuario. Cuando un terminal arranca, debe localizar a su agente principal. Si pasa un tiempo determinado y no obtiene respuesta, el agente considerará que no existe un agente principal e intentará adoptar este papel él mismo. El agente podrá llegar a ser agente principal si y sólo si se cumplen las condiciones explicadas en la sección \ref{sso_cond}. \item \textbf{``iammainagent" (IAMA)}: mensaje con la respuesta al descubrimiento. En este mensaje se adjunta una clave de sesión $KS_{t^{a}}$ que se utiliza de aquí en adelante por $T^a$ para solicitar servicio a $P^a$. También se proporciona el identificador de la encarnación del agente principal $E_{id}$ y la clave de encarnación $KE_{eid}$, que se usa para el protocolo de compartición de secretos entre agentes comunes. El mensaje se compone de dos partes: (i) una parte en la que se se incluye la dirección del agente principal que se ofrece a dar servicio al agente que envió el mensaje INMA, y (ii) otra parte que contiene la clave de sesión que se va a utilizar para establecer contacto con el agente principal, el identificador de encarnación y la clave de encarnación. La descomposición del mensaje en dos partes se debe a razones de diseño; se desacopla la asignación de agente principal del servicio que procesa el mensaje INAM. De esta forma el protocolo puede seguir siendo válido en una arquitectura formada por diferentes agentes principales (este tipo de arquitectura se tratará más adelante). \end{itemize} Para envíar estos mensajes, $T^a$ tiene que tener asignada una clave $KT_{t^{a}}$, y $P^a$ debe conocerla. Esa clave se debe almacernar en el repositorio de claves que obtiene el agente principal al arrancar. El protocolo es el siguiente: \begin{quote} $T^a \longrightarrow BROADCAST$\\ $``ineedmainagent", username_a, T^a$\\ $IV$, \{$random_b, ``ineedmainagent", username_a, T^a, n_1, n_2, timestamp_{t^{a}}$\}$_{KT_{t^{a}}}$\\ \{\{$``ineedmainagent", username_a, T^a, n_1, n_2, timestamp_{t^a}$\}$_{SHA1}$\}$_{KT_{t^{a}}}$\\ $P^{a} \longrightarrow T^a $\\ $``iammainagent"$\\ $IV'$, \{$random_b',``iammainagent", username_a, T^a, address, n_1+1, timestamp_{p^{a}}$\}$_{KS_{t^{a}}}$\\ \{\{$``iammainagent", username_a, T^a, address, n_1+1, timestamp_{p^{a}}$\}$_{SHA1}$\}$_{KS_{t^{a}}}$\\ $IV''$, \{$random_b'', ``fromowner", username_a, T^a, n_2+1, timestamp_{P^{a}},KS_{t^{a}}, E_{id}, KE_{eid}$\}$_{KT_{t^{a}}}$\\ \{\{$``fromowner", username_a, T^a, n_2+1timestamp_{p^a}, KS_{t^{a}, E_{id}, KE_{eid}}$ \}$_{SHA1}$\}$_{KT_{t^{a}}}$\\ \end{quote} \subsection{ Protocolo de servicio de secretos } Este protocolo está formado por dos mensajes: \begin{itemize} \item \textbf{``tomainagent" (TMA)}: mensaje de petición de un secreto al agente principal. \item \textbf{``frommainagent" (FMA)}: mensaje con la respuesta a la petición. \end{itemize} Al agente principal se le envía un comando, representado como $cmd$. Ese comando puede ser: \begin{itemize} \item \textbf{listkeys}: pide al agente principal que le envíe la lista de secretos que tiene en su anillo. En la lista se envía la descripción de los secretos que tiene el agente principal, pero nunca la información secreta (claves y contraseñas). \item \textbf{haskey tupla}: pregunta al agente si posee el secreto representado por esa tupla. Los secretos se representan mediante tuplas de atributos de una manera similar al Factotum original. \item \textbf{givekey tupla}: le dice al agente que le devuelva el secreto correspondiente a esa tupla. Si el agente no posee ese secreto, le devolverá un mensaje de error. \end{itemize} En el mensaje ``frommainagent" se devuelve una respuesta al comando, que representamos como $cmdresponse$. Esa respuesta puede ser la tupla solicitada o un mensaje de error. \begin{quote} $T^a \longrightarrow PCM^a$\\ $``tomainagent", username_a, T^a$\\ $IV$, \{$random_b, ``tomainagent", username_a, T^a, n_4, timestamp_{t^a}, cmd$\}$_{KS_{t^{a}}}$\\ \{\{$``tomainagent", username_a, T^a, n_4, timestamp_{t^a}, cmd$\}$_{SHA1}$\}$_{KS_{t^{a}}}$\\ $PCM^{a} \longrightarrow T^a $\\ $``frommainagent", username_s$\\ $IV'$, \{$random_b',``frommainagent", username_a, T^a, n_4+1, timestamp_{p^a}, cmdresponse$\}$_{KS_{t^{a}}}$\\ \{\{$``frommainagent", username_a, T^a, n_4+1, timestamp_{p^a}, cmdresponse$\}$_{SHA1}$\}$_{KS_{t^{a}}}$\\ \end{quote} \subsection{Protocolo Peer to Peer} El protocolo está formado por dos mensajes: \begin{itemize} \item \textbf{``topeers" (TPE)}: mensaje de petición de un secreto a los agentes comunes. \item \textbf{``frompeer" (FPE)}: mensaje con la respuesta a la petición. \end{itemize} \begin{quote} $T^a$ y $Z^a$ son terminales de A. $T^{a} \longrightarrow BROADCAST$\\ $``topeers", username_a, E_{id}$\\ $IV$, \{$random_b, ``topeers", username_a, E_{id}, n_5, timestamp_t, tuple$\}$_{KE_{eid}}$\\ \{\{$``topeers", username_a, E_{id}, n_5, timestamp, tuple$\}$_{SHA1}$\}$_{KE_{eid}}$\\ $Z^{a} \longrightarrow T^a $\\ $``frompeer", E_{id}$\\ $IV'$, \{$random_b',``frompeer", username_a, E_{id}, n_5+1, timestamp_z, tuple$\}$_{KE_{eid}}$\\ \{\{$``frompeer", username_a, E_{id}, n_5+1, timestamp, tuple$\}$_{SHA1}$\}$_{KE_{eid}}$\\ \end{quote} \section{Implementación de prototipo: NetFactotum} En esta sección se comentarán detalles de una implementación del agente SHAD para el sistema operativo Plan B~\cite{3eov,3e}. Este prototipo se basa en Factotum~\cite{cox02security}, el agente de seguridad del sistema operativo Plan 9. En el capítulo \ref{facto} del capítulo dedicado al estado de la cuestión se describe el funcionamiento y el esquema que sigue Factotum. La arquitectura de la implementación del prototipo de SHAD se presenta en la figura \ref{sso_proto}. En concreto, Factotum conforma practicamente la totalidad del módulo de secretos de un agente SHAD. De ahora en adelante, nos referiremos al prototipo del agente SHAD como {\bf Netfactotum}. El resto del prototipo lo forman los siguientes componentes: \begin{itemize} \item Servidor {\it unicast}. Sólo está activo en el agente principal y posee flujo de ejecución propio. Se encarga de servir los secretos a los agentes principales procesando las peticiones que recibe en un puerto TCP bien conocido (tcp!unicast!10023) \footnote{Se utiliza una notación similar a la utilizada en el sistema operativo Plan 9: {\it protocolo!dirección!puerto}}. \item Servidor {\it broadcast}. Está activo tanto en agentes comunes como en el agente principal. El servidor posee flujo de ejecución propio y escucha en un puerto UDP bien conocido de la dirección de broadcast de la subred En el agente principal, se encarga de procesar los mensajes de descubrimiento de los agentes comunes (udp!broadcast!10023). En los agentes comunes, se encarga de procesar las peticiones Peer To Peer (udp!broadcast!10024). \item Módulo recolector (RM). Se encarga de intentar obtener las claves de los otros agentes. Se pone en contacto con los servidores descritos anteriormente a través de conexiones TCP (agente principal) o radiando datagramas UDP en la dirección de broadcast (agentes comunes). \item Módulo descubridor (DM). Su función es descubrir al agente principal radiando mensajes de broadcast en un puerto (udp!broadcast!10023). \end{itemize} Los distintos flujos de ejecución deben acceder concurrentemente a la estructura de datos que alberga las tuplas de Factotum (el anillo de secretos). Para coordinar el acceso concurrente se han utilizado cierres con espera activa ({\it spin locks}), debido a que la espera que deben realizar es corta. Por otra parte, la probabilidad de encontrar el cierre echado en el anillo es baja, debido a la naturaleza del propio agente y el tipo de uso para el que está diseñado. \begin{figure*}[t!] \centering \epsfig{file=figuras/sso_proto.png, width=\textwidth} \caption{Esquema del prototipo de agente SHAD para SSO (NetFactotum)} \label{sso_proto} \end{figure*} La implementación aprovecha los servicios que ofrece en espacio inteligente del Laboratorio de Sistemas~\cite{lssmartspace}, en concreto la infrastructura de localización y la de mensajes de voz. Aunque el prototipo haga uso de estos servicios, no depende de ellos para su funcionamiento, esto es, tolera el fallo o la ausencia de dichos servicios. \subsection{Representación de las claves} NetFactotum utiliza el mismo método para almacenar las claves que Factotum. Las claves se almacenan en tuplas, que además contienen atributos que aportan información sobre la clave. Las claves de Factotum tienen un atributo común, \texttt{proto}, que especifica el tipo de secreto. Los otros atributos varían según el tipo de clave (el servicio para el que sirve el secreto, o campo de una tupla)~\cite{factotum-man}). Los atributos secretos de una tupla van precedidos por el carácter '!'. Estos atributos secretos nunca se presentan en claro por pantalla. Factotum almacena las tuplas en su memoria principal. La memoria principal de Factotum está protegida contra depuración y nunca se vuelca a área de intercambio. \subsubsection{ Claves para el protocolo SHAD } Para almacenar los secretos relacionados con el protocolo de NetFactotum, se ha creado un nuevo tipo de tupla que se identifica mediante el campo \texttt{proto=shad}. Estas tuplas almacenan las claves privadas de las máquinas que pertenecen al usuario ($KT_z$ para un terminal $Z$): \begin{center} \texttt{ proto=shad type=term machine={\it máquinaZ} !tsecret=}$KT_z$ %%forrent=[yes|no] askforpermission=[opción] \end{center} \subsubsection{ Campos para claves convencionales } \label{restric} Se han añadido varios atributos a las tuplas convencionales de Factotum. Mediante el uso del estos atributos, el usuario es capaz de ajustar el nivel de seguridad para sus secretos. Ell usuario deberá aceptar el compromiso entre comodidad de uso y nivel de seguridad de sus secretos. Por tanto, el usuario tendrá que tener en cuenta que los secretos que no están disponibles desde ciertos terminales tendrán que proporcionarse explícitamente, con la obstrucción que conlleva. A la vez tendrá que asumir que los secretos que están disponibles desde terminales vulnerables a ataques estarán menos seguros que los no accesibles. Respecto a las restricciones, SHAD aplica siempre la más restrictiva. En el caso de los atributos que utilizan información de localización, si dicha información no está disponible, el agente principal no sirve el secreto. Supongamos la siguiente tupla que contiene un secreto para el protocolo SSH: \begin{center} \texttt{ proto=pass server=s1 service=ssh user={\it usuario} machine={\it máquina} [noremoteaccess] [nopeeraccess] [needconfirm] [samelocation] [userlocation={\it localización}] [clientlocation={\it localización}] [accesiblefrom={\it opción}] !password } \end{center} \begin{itemize} \item \texttt{noremoteaccess}: indica que ningún agente puede compartir ese secreto con otro agente. Si una tupla no contiene este atributo, el agente principal considera que puede enviarla a un agente común. \item \texttt{nopeeraccess}: indica que el secreto no puede compartirse entre agentes comunes a través del protocolo Peer to Peer. El agente principal sí puede enviar el secreto a los agentes que lo requieran. \item \texttt{needconfirm}: obliga a que la acción tenga que confirmarse explícitamente por el usuario en el agente principal. \item \texttt{userlocation={\it localización}}: el secreto se sirve sólo si el usuario se encuetra en la localización especificada en el atributo. En caso de que la tupla contenga también el atributo \texttt{needconfirm}, se pedirá confirmación sólo si el usuario se encuentra en esa ubicación. En caso contrario, se denegará el acceso al secreto. Puede haber más de una instancia de este atributo dentro de una tupla para especificar varias localizaciones desde donde el secreto está disponible. \item \texttt{clientlocation={\it localización}}: funciona igual que el atributo anterior pero comprobando la localización de la máquina cliente. Puede haber más de una instancia de este atributo en una tupla. \item \texttt{samelocation}: es accesible si la localización física del usuario y de la máquina cliente es la misma. Respecto a las confirmaciones, se aplica el mismo criterio que en los dos atributos anteriores. \item \texttt{accesiblefrom={\it máquina}}: el secreto sólo es accesible desde las máquina indicada en el atributo. Puede haber más de una instancia de este atributo en una tupla. \end{itemize} \subsection{Control de los agentes} Factotum ofrece una interfaz de control a través de un sistema de ficheros. El prototipo de SHAD posee la misma interfaz, pero con dos ficheros de control adicionales. El fichero \texttt{getkey} fichero proporciona una interfaz para ordenar a un agente común que adquiera un secreto. El fichero de control admite una cadena de caracteres con formato de tupla de Factotum, sin el atributo secreto especificado. . Si la cadena escrita en el fichero tiene una sintaxis correcta, entonces el agente intenta conseguir la tupla completa del agente principal o de los otros agentes comunes de su misma encarnación. Si el agente consigue obtener la tupla completa, la almacena en el anillo de secretos. El fichreo \texttt{getkey} no está disponible en el agente principal. El fichero \texttt{hold} hace que los hilos servidores del agente no acepten peticiones, y por tanto, el agente SHAD actúe como un agente Factotum convencional. \subsection{ Repositorio de claves } En el prototipo NetFactotum, el repositorio de claves se obtiene mediante Secstore\cite{secstore-man}, de la misma forma que lo hace Factotum. Cuando un agente NetFactotum arranca y asume el papel de agente principal , adquiere su almacén de claves de un servidor de autenticación a través de la red. La principal diferencia con Factotum radica en que sólo el primer agente en arrancar necesita obtener el Secstore. Por tanto, sólo se depende de una entidad centralizada (el servidor de Secstore) en el momento de arrancar el agente principal. Para eliminar esa dependencia, se podría obtener el almacén de claves de un dispositivo local, por ejemplo de una tarjeta de memoria SD Card. La tarjeta tendría el mismo fichero de Secstore, crifrado con un algoritmo fuerte de clave simétrica. \subsection{Confirmaciones: Oshad} El usuario necesita una interfaz para recibir avisos de su agente principal y poder consentir la cesión de un secreto cuando sea necesario. Para ello se ha desarrollado un programa, Oshad, que ofrece una interfaz gráfica a través del sistema gráfico de Plan B, Omero~\cite{omero}. Oshad ofrece una interfaz sencilla para que el usuario pueda confirmar las operaciones tan sólo pulsando un botón. A la vez, Oshad ofrece una interfaz para su control desde NetFactotum que se basa en un pequeño sistema de ficheros virtual, siguiendo con las lineas generales de diseño de Plan B. El sistema de ficheros de Oshad ofrece tres ficheros de control: \texttt{confirm}, \texttt{ads}, y \texttt{voice}. \texttt{Confirm} es el fichero de control en el que se indican las operaciones que el usuario debe confirmar. Este fichero de control espera una cadena de caracteres con el siguiente formato: \begin{center} \texttt{ ``nonce cliente protocolo servidor'' } \end{center} \texttt{Nonce} es un entero sin signo de 32 bits generado de forma aleatoria que identifica la petición de confirmación que se le pasa a Oshad. \texttt{Cliente} es el nombre de la máquina donde ejecuta el agente que está pidiendo servicio al principal. \texttt{Protocolo} especifica el tipo de secreto que solicita el agente remoto. Por último, \texttt{servidor} es el nombre de la máquina que ofrece el servicio para el que se va a usar el secreto reclamado. Cuando se escribe una cadena con esta sintaxis en el fichero \texttt{confirm}, Oshad pregunta al usuario a través de su interfaz gráfica integrada en Omero. En la figura \ref{oshad} se muestra una captura de pantalla de Oshad pidiendo confirmación para ceder un secreto a un agente SHAD que lo solicita. Cuando el usuario se pronuncia al respecto, su decisión se puede leer del mismo fichero: la lectura del fichero de control devuelve el \texttt{nonce} junto con la decisión del usuario. \begin{figure*}[t!] \centering \epsfig{file=figuras/oshad.png, width=\textwidth} \caption{Captura de pantalla de Oshad pidiendo confirmación para ceder al agente SHAD de la máquina 'osiris' la contraseña de acceso al servidor SSH de la máquina 'ronin' .} \label{oshad} \end{figure*} Por tanto, cuando una aplicación (que comúnmente será NetFactotum, aunque otras aplicaciones pueden usar Oshad de la misma manera, ya que están totalmente desacoplados) necesita confirmación, sigue los pasos enumerados a continuación: \begin{enumerate} \item Abre el fichero \texttt{confirm} en modo lectura/escritura. \item Escribe en el fichero \texttt{confirm} la cadena de control. \item Lee del fichero \texttt{confirm} en repetidas ocasiones la confirmación o cancelación de la operación, identificando en contenido mediante el \texttt{nonce} utilizado en la cadena de control. Cada aplicación definirá su tiempo de espera máximo (timeout) para considerar que la confirmación ha fallado. \end{enumerate} El fichero \texttt{ads} espera cadenas de caracteres correspondientes a avisos destinados al usuario. Estos avisos se imprimen en la interfaz gráfica de Oshad. Por otra parte, Oshad saca partido de la infrastructura de voz de Plan B~\cite{lssmartspace}, avisando a través de esta al usuario. Cuando un programa escribe un aviso en el fichero \texttt{ads}, Oshad lo reenvía a la infrastructura de voz del entorno inteligente. La infrastructura de voz de Plan B redirige el mensaje a la localización actual del usuario, donde un sintetizador de voz lo reproduce por un altavoz. Oshad es capaz de usar la infrastructura de voz si esta está disponible, pero no depende de ella para su funcionamiento: el usuario puede seguir confirmando operaciones y recibiendo mensajes a través de la interfaz aunque no esté disponible ninguna infrastructura del entorno inteligente (localización o voz). Por último, Oshad ofrece un fichero \texttt{voice} que sirve para indicar si el usuario desea utilizar la infrastructura de voz del espacio inteligente o no. El fichero admite sólo dos cadenas de control, \texttt{on} y \texttt{off}, que activan y desactivan el servicio de voz respectivamente. \subsection{Información de localización} Mediante el uso de información de localización y de las restricciones descritas en la sección \ref{restric}, el agente principal de SHAD es capaz de ceder secretos a los demás agentes en base al contexto físico de las personas y máquinas. El prototipo implementado accede a la información de localización que ofrece el espacio inteligente del Laboratorio de Sistemas mediante dos servicios: \texttt{/who} ofrece información de contexto sobre personas y \texttt{/what} ofrece información de localización sobre objetos. Estos servicios se describen en profundidad en otros trabajos~\cite{ballesteros04traditional,lssmartspace}. El servicio \texttt{/who} ofrece una interfaz de sistema de ficheros a través de la cual proporciona información de contexto sobre usuarios. El sistema ofrece los siguientes ficheros con información de localización para cada usuario del sistema: \begin{itemize} \item \texttt{status}: muestra si el usuario está presente en el sistema. \item \texttt{where}: ofrece la localización del usuario. \end{itemize} La infrastructura de localización obtiene dicha información de distintas fuentes, como sensores de X10~\cite{x10}, balizas emisoras de ultrasonidos, programas que implementan heurísticas definidas para usuarios concretos y otros métodos. Por otra parte, \texttt{/what} ofrece un sistema de ficheros con un directorio para cada uno de las máquinas del entorno ubicuo que contien una serie de ficheros con información de contexto. Dentro de ese directorio se sirve un fichero llamado \texttt{where} que indica la localización de dicha máquina. \subsection{Experiencia de uso}