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 utilizaal mismo tiempo un usuario ha crecido sustancialmente. Estos dispositivos son básicamenteordenadores, que aunque poseen distintas cualidades físicas y funcionales, ejecutan un sistemaoperativo convencional y están sometidos a las mismas necesidades de configuración y administraciónque 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 laautenticació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 proporcionandoobstrucción. Por otra parte, dependen de dispositivos lectores específicos que normalmenteno 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 anterioresno 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 ordenadoresque integran el espacio  con el que está interaccionando. Teniendo en cuenta que la aparición de nuevos dispositivos en el sistema tiende a crecerdebido a la progresiva miniaturización y el abaratamiento de los dispositivos móviles quedictó 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 hantratado 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 únicosistema. 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 arquitecturase 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ásadelante.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 relativosa la delegación de sus secretos y confirmar la delegación de determinadossecretos.  A su vez, el repositorio de secretos está ideado para obtenerse de  una tarjeta de memoriadirectamente 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 librede ejecutar su agente principal en cualquiera de sus máquinas, y de obtener su repositoriode 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 otrosdispositivos 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 sedelegarán secretos a agentes SHAD que no puedan autenticarse ante el agenteprincipal. Tampoco se podrán delegar secretos a agentes que no estén ejecutandoen 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 consu agente principal para obtener un secreto y no recibe respuesta, entoncesiniciará un protocolo para intentar obtener el secreto de otros agentesSHAD de su mismo tipo. Si finalmente no obtiene respuesta de algúnagente que posea dicho secreto, el agente intentará obtenerlodirectamente del usuario. En ese caso se  preguntará al usuario mostrandoun mensaje a travésde 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 tipotienen dos funciones principales: (i) describir la forma en la que los datosse 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 procesosy definir las entidades internas de los agentes SHAD\footnote{Sin embargo, en estasección no se pretende realizar un análisis o modelado exhaustivo del sistema.}. La figura \ref{arch0} muestralas entidades externas con las que los agentes de SHAD intercambianinformación. Por lo tanto esa figura es lequivalente a un diagrama de contexto (diagrama de flujo de datos de nivel cero). Las entidades externasa 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 comportamientodel agente de SHAD, debido a que aunque los agentes son exactamenteel mismo programa, pueden adoptar dos funcionalidades distintas dependiendode 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 SHADcomú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} sepueden 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 internasde 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 modoCBC. 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 

Lines 1–500 of 1008. Load more