Hacia una PKI mejorada para Comercio Electrónico Móvil *

Transcripción

1 Hacia una PKI mejorada para Comercio Electrónico Móvil * Xisca Hinarejos 1, Jordi Forné 1, Florina Almenarez 2, Andrés Marín 2, Mildrey Carbonell 3, José A. Montenegro 3 1 Dpt. Ingeniería Telemática, Universitat Politècnica de Catalunya {mfcampos,jforne}@entel.upc.edu 2 Dpt. Ingeniería Telemática, Universidad Carlos III de Madrid {florina,amarin}@it.uc3m.es 3 Dpt. Lenguajes y Ciencias Computación, Universidad de Málaga {mildrey,monte}@lcc.uma.es Resumen La proliferación de dispositivos móviles extiende las posibilidades de nuevos modelos de negocio. Este artículo trata los aspectos de seguridad relacionados con dichos modelos, identificando los retos más importantes que surgen a partir de la heterogeneidad de las redes involucradas (Wifi, UMTS, Bluetooth, etc.), y de la presencia de usuarios nómadas y dispositivos limitados, que fomentan entornos muy dinámicos. PKI, como solución de seguridad, presenta algunas desventajas en cuanto a: escalabilidad, modelo estático de confianza, costos administrativos altos, y la necesidad de acuerdos globales. Además, PKI no es adecuado para proporcionar servicios de autorización y carece de capacidades de delegación. Por lo tanto, este artículo presenta el diseño de una PKI mejorada tanto para autenticación como para autorización, que supera las desventajas de PKI; centrándose en entornos desconectados, ya que imponen los requisitos de seguridad más rigurosos. 1. Introducción La popularidad de los dispositivos móviles incrementa cada día, permitiendo nuevos modelos de negocio, como el comercio electrónico móvil. De este modo, las transacciones comerciales se extienden a un mayor número de mercados y explotan distintas formas de interacción entre proveedores y clientes. Dichos modelos involucran múltiples tecnologías de red (Wifi, UMTS, Bluetooth, etc.), lo cual impone diversos retos para las soluciones de seguridad, ya que además de las típicas transacciones hechas por los clientes desde localizaciones fijas al proveedor, se añaden transacciones más dinámicas, hechas por o entre clientes * Este trabajo ha sido parcialmente financiado por la Comisión Europea ubicado dentro del 6 o Programa Marco, con cargo al proyecto UBISEC (IST-STREP ). [1]

2 móviles independientemente de la localización, el tiempo, el dispositivo y la red subyacente. Esto forma parte de los entornos de computación ubicua. Infraestructuras de clave pública (PKIs, Public Key Infrastructures) y certificados X.509 [2] [3] son los estándares utilizados hoy día para proporcionar seguridad en comercio electrónico. Dichos estándares son apoyados por un número creciente de herramientas de gestión y de usuario final, siendo la razón de su éxito sobre otras iniciativas como SPKI, etc. No obstante, PKI tiene problemas de escalabilidad, autorización y un modelo de confianza estático y restringido. Problemas de escalabilidad tanto con el número de usuarios como con el número de certificados emitidos. Además de autenticación, PKI fue originalmente propuesta para permitir autorización, usando extensiones en los certificados para expresar privilegios. La naturaleza dinámica de los privilegios demanda, con cierta frecuencia, la concesión y denegación de permisos, de modo que los problemas de escalabilidad se acentúan cuando un número creciente de certificados tienen que ser emitidos y luego revocados cuando los permisos dejan de ser necesarios o concedidos. El modelo de confianza es estático y restringido, ya que la confianza se basa en terceras partes fiables (TTPs, Trusted Third Parties), llamadas autoridades de certificación (CAs, Certificate Authorities), que forman una estricta jerarquía donde la confianza fluye desde la raíz hasta las hojas. Los certificados denotan relaciones de confianza directas para los propósitos expresados en las políticas de los certificados y de la CA emisora. Pero, este modelo deja de ser adecuado en redes P2P (peer-to-peer), ad hoc, y situaciones donde no hay un administrador disponible ni una CA alcanzable. Es así como, distintos modelos de confianza son propuestos, por ejemplo, distribuidos (como PGP [4]) para tratar el problema de escalabilidad. Infraestructuras de gestión de privilegios (PMIs, Privilege Managament Infrastructures) y certificados de atributo (ACs, Attribute Certificates) [3] surgen como la alternativa más prometedora para solucionar los problemas de escalabilidad para autorización en PKI. PMI ofrece, además, delegación de derechos, lo cual está claramente fuera del alcance de PKI. Sin embargo, no existe un modelo de confianza estándar que sea dinámico, distribuido y que automatice, tanto como sea posible, las relaciones entre CAs. En este artículo, se presenta una infraestructura de clave pública que proporciona servicios de autenticación y autorización en entornos de comercio electrónico móvil, es decir, transacciones comerciales que involucran dispositivos móviles. Teniendo en cuenta que las redes involucradas pueden ser redes con infraestructura o sin ella, se establece la diferencia entre dos modos de ejecución: modo conectado y modo desconectado. En el modo conectado los servidores TTP en línea están disponibles, por lo tanto, para validar las credenciales de los usuarios se realizan los procesos habituales. Por el contrario, en modo desconectado, la información necesaria para la validación de credenciales no está disponible. Por tal motivo, se utiliza la interacción entre distintas soluciones: un verificador de privilegios adaptado para servicios de autorización, un cliente PMI para dispositivos limitados, un nuevo modelo de confianza dinámico y distribui-

3 do para servicios de autenticación y un mecanismo ligero y distribuido para obtener información sobre la revocación de certificados. La sección 2 referencia los trabajos relacionados de seguridad en comercio electrónico móvil y redes ad hoc. Luego, la sección 3 identifica los requisitos de la PKI mejorada (epki, enhanced PKI ). El diseño de dicha PKI es explicado en la sección 4 y los módulos necesarios incluida su interrelación son descritos en la sección 5. Finalmente, la sección 6 contiene las conclusiones. 2. Trabajos Relacionados Los trabajos relacionados han sido clasificados en dos vertientes: por un lado, las especificaciones realizadas por las empresas para comercio electrónico móvil, y por otro lado, las propuestas de investigación enfocadas en proporcionar servicios de autenticación y autorización en redes ad hoc. Diversos consorcios han surgido con el fin de estandarizar soluciones de seguridad para comercio electrónico móvil, asumiendo escenarios donde los dispositivos móviles actúan únicamente como clientes y siempre tienen conectividad global [5]. El resumen de las especificaciones es mostrado en el cuadro 1. Solución Entidades Propósito SIM Application SAT es un estándar del ETSI Toolkit (SAT) (European Telecommunications Forum (1996) Standard Institute): GSM transacciones. Radicchio (1999) EDS, Ericsson, Gemplus, MTN, Giesecke & Devrient, Smarttrust, Vodafone Desarrollar servicios de valor añadido y de comercio móvil usando teléfonos GSM para hacer las Definir una plataforma de seguridad estándar usando WPKI (Wireless PKI ): Java y WIMs (Wireless Identity Modules). Mobile Electronic Ericsson, Motorola Nokia, Desarrollar un marco común para comercio electrónico Transactions (MET) Siemens, Panasonic móvil. (2000) Mobey Forum Instituciones financieras y fabricantes Desarrollar servicios financieros inalámbricos en (2000) de dispositivos móviles. línea. Mobile 3D Secure(2001) Visa International Asegurar los pagos hechos con teléfonos móviles usando una tarjeta Visa. Open Mobile Alliance Más de 300 compañías: oper- Tratar aspectos de gestión de derechos digitales (OMA) adores móviles, suministradores (DRM) y otros aspectos de comercio móvil, con (2002) de dispositivos, compañías de TI, el fin de facilitar la adopción global de servicios y proveedores de contenido. de datos móviles. Mobile Electronic 25 compañías: HP, Siemens, Desarrollar una infraestructura de aplicaciones Signature (MEST) Mannesman, Cable & Wireless universal y segura capaz de utilizar firmas digitales HKT, Mitsubishi, etc. móviles. Simpay (2004) Orange, Telefónica Móviles, T- Ofrecer el servicio de pagos seguros a través de Mobile, Vodafone teléfonos móviles de bajo costo. Mobile Content Intel, Nokia, Panasonic, mm02, Permitir la entrega de contenido digital de alta Rights Management RealNetworks, Samsung, Warner calidad a dispositivos móviles: Content Management (2004) Bros Studios License Administrator (CMLA) Frame- work. Trusted Mobile Platform (2004) NTT DoCoMo, Intel Corporation, IBM Permitir servicios más seguros de comercio móvil como tickets y billeteras (e-wallets) electrónicas. Proteger a los dispositivos contra virus u otro software maligno. Cuadro 1. Soluciones de Seguridad para Comercio Móvil

4 La segunda parte de los trabajos relacionados, como se mencionó previamente, incluye propuestas de investigación para proporcionar servicios de autenticación y autorización en redes ad hoc. Dichas propuestas pueden ser agrupadas en dos categorías para autenticación: 1) [6] [7] proponen compartir la clave privada del servicio entre todos o un subconjunto de los nodos que forman la red. Este tipo de solución está basado en Criptografía Umbral (del inglés, Threshold Cryptography [8]); y 2) [9] [10] proponen hacer una red fiable entre diferentes nodos similar a PGP, donde los certificados son emitidos, almacenados y distribuidos por los mismos usuarios, de modo que éstos construyen los caminos de confianza. Para autorización, no hay una propuesta específica, pero existen algunas propuestas para redes ad hoc y dispositivos móviles que incluyen este servicio, como son: 1) [11] especifica un grupo de políticas de autorización de acuerdo con los roles de los usuarios (por ejemplo, premio, normal, etc.); y 2) En [12] se propone mantener un certificado de políticas válido y un módulo de control que asegure el cumplimiento de las políticas sobre cada usuario del dispositivo. Como podemos notar, los trabajos que se acaban de mencionar no garantizan ambos servicios, autenticación y autorización para aplicaciones P2P. Además, estas soluciones no integran entornos en modo conectado y desconectado, considerando la movilidad del usuario. 3. Requisitos El principal objetivo de la PKI mejorada (epki) es proporcionar una infraestructura de autenticación y autorización para comercio móvil (sistemas ubicuos). La idea es concentrar todos los esfuerzos en adaptar los servicios tradicionales de la PKI para ser utilizados en los escenarios de computación ubicua y únicamente desarrollar nuevos servicios de PKI cuando sea necesario. Las características más importantes de los sistemas ubicuos que afectan al diseño de la PKI son: 1. Heterogeneidad. El acceso ubicuo permite a los usuarios establecer comunicaciones en cualquier momento y en cualquier lugar. Se pueden utilizar diferentes tipos de redes, topologías y tecnologías: Wifi, UMTS, Bluetooth, etc. Esta heterogeneidad implica la existencia de dominios de confianza que puedan encontrarse desconectados, cada uno aplicando sus propios mecanismos y políticas para llevar a cabo la autenticación y/o autorización de entidades. 2. Movilidad. La ITU-T define movilidad nómada como la habilidad de un usuario/terminal para cambiar de punto de acceso a la red a medida que se mueve mientras la sesión del servicio finaliza y se inicia de nuevo. La epki tiene que proporcionar servicios para facilitar la movilidad nómada de los usuarios. 3. Desconexión temporal de los servicios. Cuando los usuarios se mueven a través de diferentes redes, la conectividad global se puede perder y algunos servicios pueden estar no disponibles temporalmente. Esta situación tiene

5 un fuerte efecto en algunos de los servicios de la PKI, tales como la verificación del estado de revocación de los certificados y el procedimiento de descubrimiento de cadenas de certificados. La adaptación de las características arriba mencionadas, trata directamente con los requisitos siguientes para la epki: 1. La autenticación y la autorización se deben basar en certificados digitales. Mecanismos basados en PKI son adecuados para autenticación en dominios de confianza heterogéneos, al mismo tiempo que facilita la movilidad y la desconexión temporal de servicios en el sentido de que los usuarios transportan sus propias credenciales para poder autenticarse con independencia del momento y de su localización. Del mismo modo, se requieren mecanismos de autorización basados en credenciales, como pueda ser la utilización de una PMI que permita el uso de políticas de autorización descentralizadas más escalables (ver sección 4). 2. Diseño de un modelo de confianza adecuado para poblaciones dinámicas en modo desconectado. El procesamiento de caminos de certificación no se puede garantizar cuando se trabaja en modo desconectado, de hecho, usuarios desconocidos, probablemente certificados por diferentes CAs que pueden no ser reconocidas directamente por los usuarios, podrían querer interactuar. Por lo tanto, es necesario un nuevo modelo de confianza donde se contemple el caso en el que un certificado no pueda ser verificado o no se puedan establecer nuevas relaciones de confianza, por medio de mecanismos PKI tradicionales. Para estas situaciones, se crea un modelo de confianza ubicuo (ver sección 5.2.1). 3. Diseño de un mecanismo de verificación del estado de los certificados adecuado para modo desconectado. Protocolos tradicionales para la verificación del estado de los certificados no son adecuados para modo desconectado o para dispositivos limitados de usuario. Sistemas de revocación de certificados basados en árboles de Merkle (MHT, Merkle Hash Trees) pueden ser una solución aceptable para estos escenarios, como se expone en la sección Diseño de la epki En esta sección se presenta la infraestructura para la epki, un sistema para autenticación y autorización en redes ubicuas que cumple con los requisitos de seguridad descritos en la sección 3. La infraestructura representada en la figura 1 se puede dividir en dos partes: 1) la infraestructura ofreciendo los servicios de seguridad (bloques PKI y PMI) y 2) los clientes de la epki (bloques Usuario y Gestor de Recursos). A continuación se describen brevemente los componentes de la epki mencionados centrándonos en el funcionamiento en modo conectado. En el aparatado 5 se describirá con mayor detalle su funcinamiento en modo desconectado, siendo éste nuestra mayor aportación.

6 4.1. Infraestructura de la PKI Para la autenticación de las entidades en modo conectado se utiliza una PKI. Como es una infraestructura bastante extendida y uno de nuestros objetivos es centrarnos en el diseño de nuevas funcionalidades, se ha elegido la utilización de un software de código abierto para proporcionar las funcionalidades básicas de la PKI. OpenCA [13] permite proporcionar, principalmente, los servicios de: expedición, revocación y publicación tanto de certificados de clave pública como de información de revocación de los mismos. La solución para llevar acabo los servicios de autenticación en modo desconectado se explican en la sección 5. Figura 1. Infraestructura de la epki 4.2. Infraestructura de la PMI Para el servicio de autorización se utiliza una PMI basada en certificados de atributo X.509. La ITU-T define PMI como la infraestructura capaz de soportar la gestión de privilegios como soporte de un servicio de autorización y en relación con una Infraestructura de Clave Pública [3]. En la PMI se define un nuevo tipo de certificados, los certificados de atributo (AC-Attribute Certificate), que a diferencia de los certificados de clave pública, los cuales enlazan una clave pública a una identidad, los AC enlazan atributos (privilegios, rol, etc) a entidades. La infraestructura de la PMI se divide en cuatro componentes principales: Los usuarios, los cuales solicitan servicios al resto de componentes. Principalmente solicitan la expedición y revocación de certificados de atributo. La Autoridad de Atributos (AA-Attribute Authority /SoA-Source of Authority) es la entidad encargada de delegar/conceder privilegios a usuarios, o a otras AA, mediante la expedición de certificados de atributo.

7 El Gestor de Recursos es responsable de la validación de los atributos de un usuario (privilegios, rol, etc.), los cuales son transportados en certificados de atributo. Este componente consta principalmente de un elemento, el Verificador de Privilegios (PV) el cual gestiona el proceso completo de validación de los certificados de atributo de los usuarios. Los repositorios almacenan información, como: certificados de atributo expedidos, información de revocación, políticas, etc. Los servicios básicos de la PMI para modo conectado se proporcionan fácilmente, ya que tanto los usuarios como el Gestor de Recursos pueden conectarse a la AA y a los repositorios para acceder a los servicios ofrecidos. Sin embargo, el Gestor de Recursos debe ser adaptado para trabajar en modo desconectado, ya que el acceso a información, como pueda ser la revocación de un AC puede no estar disponible Clientes de la epki Definimos como cliente de la epki a cualquier entidad que requiere acceder a los servicios tanto de autenticación como de autorización. En nuestra infraestructura diferenciamos dos tipos de clientes: 1) aquellos incorporados en los dispositivos de los usuarios, que realizan, principalmente, peticiones de expedición y revocación de certificados a la epki; y 2) El Gestor de Recursos que se encarga de controlar el acceso de los usuarios a los recursos de la red, en base a los atributos contenidos en el AC del usuario. En modo desconectado esta diferenciación podría no existir, ya que algunos usuarios podrían actuar tanto como entidades solicitando servicios como servidores proporcionando los servicios. Esta situación implica que un usuario en determinados momentos podría ofrecer determinados servicios, lo que conllevaría la validación de las credenciales (PKC y/o AC) de otro usuario, realizando funciones de Gestor de Recursos, como se explica en la sección Soporte para autenticación y autorización en dispositivos de usuario para modo desconectado Tal como refleja la sección 3, ciertos servicios de la epki pueden estar temporalmente no disponibles por falta de conexión. La colaboración entre PTM y el PV permite que la PMI pueda trabajar, en determinados casos, en modo desconectado. En estas situaciones, PTM proporciona el servicio de verificación de la identidad del usuario utilizando certificados de clave pública (PKCs), mientras PV proporciona el servicio de verificación de privilegios del usuario contenidos en certificados de atributo Hipótesis de partida Para el diseño en modo desconectado se realizan las siguientes hipótesis:

8 Los certificados de clave pública del usuario se han expedido con anterioridad a la entrada del usuario en modo desconectado; es decir, los certificados de clave pública no se expiden sin la intervención de la CA en línea. Por otra parte, los certificados de atributo pueden ser expedidos por otros usuarios, de esta forma una entidad puede delegar todos o parte de sus privilegios a otra entidad sin la intervención de una AA centralizada. El usuario es responsable de presentar sus certificados de clave pública. El usuario es responsable de presentar los certificados de atributo que forman la cadena de delegación. Si no existe delegación, la cadena está formada por dos ACs, el AC del usuario y el AC de la SoA. En este caso, el PV debe confiar en la SoA. Las dos últimas hipótesis evitan tener que llevar a cabo el procedimiento del descubrimiento de cadenas de certificados. Aunque existen soluciones para llevar acabo este proceso en escenarios desconectados, este punto está fuera del alcance de este artículo Arquitectura Figura 2. Arquitectura de autenticación y autorización para dispositivos de usuario La figura 2 representa los módulos que componen la arquitectura de autenticación y autorización para dispositivos de usuario. Se pueden diferenciar cinco componentes principales: el componente PTM, el Verificador Privilegios, el Motor Control de Acceso, el Cliente PMI y el Cliente para la Verificación del Estado de Revocación. En el resto de esta sección se describen cada uno de los componentes que forman la arquitectura PTM, un modelo de confianza ubicuo. PTM define un modelo de confianza distribuido similar a PGP, donde los usuarios pueden ser sus propias

9 CAs, formando dominios de confianza con sus dispositivos. Las relaciones de confianza entre usuarios se establecen de igual-a-igual. Los dispositivos actúan en representación de los usuarios (entidades físicas) y cada uno posee su propia pareja de claves, una lista protegida de entidades fiables y no fiables, su grado de confianza, su comportamiento, y sus PKCs. Además, si un usuario posee certificados emitidos por CAs previamente configuradas por el fabricante, dicha relación sería utilizada para autenticar al usuario. Para validar el certificado se utiliza el protocolo AD MHT (sección 5.2.5). No obstante, PTM no depende de la existencia de relaciones previamente establecidas, ya que un dispositivo podría establecer sus propias relaciones de confianza de manera ad hoc. La relación de confianza es expresada como una función continua entre 0 y 1, siendo los valores extremos de total desconfianza y total confianza, respectivamente; además, se incluyen estados intermedios. La lógica difusa nos permite mayor granularidad que la lógica boleana utilizada por PKI. Dichas relaciones pueden ser establecidas de manera directa o indirecta. En el primer caso, un usuario confía en otro sin intervención de TTPs; para ello, utiliza una máquina de inferencia que le permita interpretar las reglas establecidas en función del contexto de seguridad, el nivel de seguridad (Context Provider) y la sensibilidad de los recursos en riesgo. En el segundo caso, se requiere de la intervención de TTPs para emitir recomendaciones. Las recomendaciones pueden ser dadas en línea usando un protocolo de recomendación ubicuo (PRP, Pervasive Recommendation Protocol) entre entidades cercanas o usando directamente PKCs [14]. El valor de confianza se obtiene haciendo un promedio de todas las recomendaciones pesado con el valor de confianza del recomendador [14][15]. Este valor final de confianza representa nuestra opinión acerca de otro usuario, similar al modelo de Josang, el cual define dos espacios: creencia y evidencia. La evidencia sirve como retroalimentación para las creencias (opiniones) [16]. Sin embargo, nuestra opinión no es estática, ya que ésta podría cambiar a lo largo del tiempo de acuerdo con el comportamiento, proporcionándonos una retroalimentación sobre el desempeño del usuario durante la interacción. Cada interacción es considerada una evidencia, la cual es medida por las acciones ejecutadas (Action Monitoring). Así, cuando una nueva acción es ejecutada, el valor de confianza es recalculado, se toma como base el valor de confianza actual y se incrementa o decrementa de acuerdo con el valor de la acción. El valor de acción, a su vez, es multiplicado por un factor de severidad. La información de confianza y el almacen de certificados permite al Authentication Service (AS) autenticar usuarios tanto poseedores de privilegios como emisores de ACs. El AS se basa en el Trust Manager para extender sus funcionalidades y poder obtener certificados e información de confianza de forma automática. El almacen de certificados y claves puede ser el sistema de ficheros del propio dispositivo o una tarjeta inteligente, para ello utilizamos Java Card Certificate Management (JCCM) [17]. JCCM emplea tarjetas java cards como un token de seguridad para almacenar objetos PKCS#11.

10 Un verificador de privilegios adaptado. El verificador de privilegios (PV, Privilege Verifier) es el componente que se encarga de la verificación de los certificados de atributo, los cuales son presentados por los usuarios cuando solicitan acceso a los recursos. En modo conectado el PV ofrece los servicios de: a) validación de certificados de clave pública, o su delegación a un servidor de validación de cadenas de certificación, b) validación de privilegios de usuario, y c) toma de decisión de acceso a los recursos basada en ACs, políticas y variables de entorno. En modo desconectado el verificador de privilegios modifica su funcionamiento, ya que no se puede acceder a los servidores en línea de las autoridades de certificación. Los tres procesos críticos son: 1) el descubrimiento de caminos de delegación, es decir, obtener todos los certificados de atributo desde el AC del usuario al AC de la fuente de Autoridad (SoA); 2) la validación de la autenticación de entidades, como se ha explicado en la sección 3; y 3) la validación del estado de revocación tanto de PKCs como de ACs. Por lo tanto, para la validación de atributos o privilegios se realizan los siguientes pasos: El usuario proporciona los ACs necesarios para construir el camino de delegación, como se especifica en las hipótesis de partida (ver sección 5.1). La validación de certificados de clave pública se delega al componente PTM. Si existen PKCs válidos, el resultado de la autenticación es un valor booleano (0 - autenticación negativa del usuario, o 1 -autenticación positiva del usuario). En otro caso, el resultado es un nivel de confianza (grado de confianza asignado a la entidad) calculada por PTM (ver sección 5.2.1). Para validar los privilegios del usuario (módulo Credential Validation) en base a las políticas (módulo Policies Validation) y variables de entorno, el componente PV utiliza la información proporcionada por: a) el usuario; b) el módulo Localizer, el cual se encarga de obtener y gestionar la información local necesaria para el funcionamiento del PV; c) PTM, como se ha explicado en el punto anterior; y d) el RSCC (Cliente para Verificación del Estado de Revocación). Existen dos modelos diferentes para la validación del estado de revocación para ACs: 1) la validación utilizando la información de revocación proporcionada por el RSCC; o 2) no-validación, en el caso de que el periodo de validación se considere suficientemente corto para que la revocación se considere innecesaria. Finalmente, la decisión de acceso la toma un módulo común en la arquitectura, el ACE (Motor Control Acceso). Para ello, el ACE invoca al PV para obtener los privilegios certificados contenidos en el AC del usuario Motor de Control de Acceso (ACE). El ACE es el responsable de la toma de decisiones de control de acceso a los recursos, y cuya arquitectura está basada en XACML [18]. ACE invoca a la PTM para autentificar a los usuarios que solicitan el acceso, e invoca a PV para obtener los privilegios contenidos en el AC. Con esta información, ACE leerá previamente las políticas de control de acceso y establecerá las decisiones de acceso.

11 Cliente PMI. La sección 4.2 describe la AA como una de las entidades integrantes en la PMI. Esta entidad es la encargada de las tareas de administración de certificados de atributo. La principal tarea del cliente de PMI es proporcionar los certificados de atributo, por tanto el cliente tiene que realizar conexiones con la AA para la solicitud de ACs. Estas conexiones son realizadas cuando el sistema se encuentra en modo conectado. Acto seguido, el PTM y el PV podrán usar estos certificados para realizar las correspondientes tareas de autorización. Nuestro prototipo de PMI incluye un servidor AA que espera conexiones seguras mediante SSL y Cliente Visual AA en las funcionalidades para la petición/revocación de los certificados de atributos y la configuración de la AA. La versión inicial del prototipo exigió nuevas soluciones para establecer conexiones con la AA, que tuviera en cuenta las pesquisas de las redes ubicuas. La solución propuesta es una librería implementada en JAVA que puede incluirse fácilmente y de manera natural a los restantes elementos del sistema. La figura 3 muestra la arquitectura de la PMI, y como posibilita que los dispositivos con recursos limitados puedan acceder a la funcionalidad de la PMI. Figura 3. Flujo de Interacción de los componentes de la PMI El cliente PMI La librería cliente tiene como funciones principales: Establecer una conexión con la AA utilizando un puerto determinado P y una conexión SSL. Solicitud de Certificados de Atributo para obtener información del certificado. Obtener información de configuración sobre los atributos y extensiones disponibles. Obtener Certificados de Atributo de LDAP. El interfaz debido a su facilidad de uso, se convierte en un elemento que permite a los dispositivos con recursos limitados ser clientes de la PMI. Por ejemplo, cualquier dispositivo puede conectarse a un servidor LDAP para obtener los certificados de atributo utilizando la librería como elemento intermediario.

12 Cliente para la Verificación del Estado de Revocación. Se puede definir revocación de certificados como los mecanismos bajo los cuales una autoridad puede invalidar el enlace entre una identidad y una clave pública antes de la expiración del certificado que mantiene dicha relación. De este modo, la PKI necesita proporcionar a sus usuarios finales la capacidad de chequear si un certificado es todavía válido (no revocado), en el instante de utilización del mismo. Esta característica es comúnmente conocida en la PKI como status checking. Entre los mecanismos de revocación estandarizados se encuentran la CRL [2] y OCSP [13]. Una CRL es una lista digitalmente firmada que contiene una lista de los certificados revocados. La CRL puede ser publicada en un directorio de acceso público, de manera que sea accesible a los usuarios, los cuales deben bajar la lista completa y verificar la firma de manera local. Debido a que el tamaño de la CRL puede ser bastante elevado, el almacenamiento y el procesado de la CRL puede ser problemático para dispositivos limitados. Por otra parte, el protocolo OCSP se basa en una evidencia criptográfica representando el estado de los datos. Esta evidencia es generada en línea por el OCSP responder, el cual debe ser una TTP. En modo desconectado, no se puede garantizar que la TTP se encuentre accesible en línea y, por lo tanto, ni OCSP ni CRL son soluciones adecuadas para la verificación del estado de los certificados. Los sistemas de revocación de certificados basados en árboles de Merkle son una solución equilibrada para evitar la necesidad de la existencia de terceras partes de confianza en línea, y reducir el volumen de información a ser gestionada por los dispositivos del usuario. El protocolo AD MHT [19] ha sido seleccionado como protocolo para la verificación del estado de los certificados en modo desconectado, tanto para la PKI como para la PMI. 6. Conclusiones En este artículo se ha presentado la infraestructura de una PKI mejorada (epki) para entornos de computación ubicua móvil. Esta infraestructura permite la validación de credenciales de usuario en redes heterogéneas donde se puede perder la conectividad global, por lo que algunos de los servicios pueden ser no accesibles temporalmente. Además, la infraestructura permite movilidad nómada. La epki proporciona una infraestructura de autenticación y autorización para los usuarios móviles interviniendo en transacciones comerciales y otras aplicaciones. Para llevarlo a cabo, se utiliza la combinación de los servicios ofrecidos por la PKI tradicional y los nuevos servicios de la PMI. La naturaleza de los certificados de atributo junto con el modelo PTM permite la validación de credenciales de usuario en modo desconectado. Por lo tanto, se consigue llevar a cabo servicios tanto de autenticación como de autorización en algunos escenarios en los que antes no era posible.

13 Referencias 1. UBISEC: Ubiquitous networks with a secure provision of services, access, and content delivery (2004) 2. PKIX: Public-key infrastructure (X.509) (1999) 3. ITU-T Recommendation X.509: Information technology - open systems interconnection - the directory: Public key and attribute certificate frameworks (2000) 4. Zimmermann, P.: The Official PGP User s Guide. MIT Press, Cambridge, MA, USA (95) 5. Cellular Online: Mobile commerce (m-commerce) (2005) 6. Kong, J., Zerfos, P., Luo, H., Lu, S., Zhang, L.: Providing robust and ubiquitous security support for MANET. In: 9th IEEE International Conference on Network Protocols (ICNP). (2001) 7. Zhou, L., Haas, Z.: Securing ad hoc networks. IEEE Network Magazine 13 (1999) Desmedt, Y., Frankel, Y.: Threshold cryptosystems - advances in cryptology (Crypto 89). In G. Brassard, Ed., S.V., ed.: 9th Annual International Cryptology Conference. Volume 435. (1989) Capkun, S., Buttyan, L., Hubaux, J.P.: Self-organized public-key management for mobile ad hoc networks. IEEE Transactions on Mobile Computing 2 (2003) 10. Hubaux, J., Buttyan, L., Capkun, S.: The quest for security in mobile ad-hoc networks. In: ACM Symposium on Mobile Ad Hoc Networking and Computing (MobiHOC 2001). (2001) 11. Loong, S., Lupu, E., Sloman, M.: PEACE: A policy-based establishment of ad-hoc communities. In: Computer Security Applications Conference. (2004) 12. Jansen, W., Karygiannis, T., Gravila, S., Korolev, V.: Assigning and enforcing security policies on handheld devices. In: Canadian Information Technology Security Symposium. (2002) 13. OpenCA Labs: OpenCA: Research & development labs (1998) Almenárez, F., Marín, A., Campo, C., Rubio, C.G.: Ptm: A pervasive trust management model for dynamic open environments. In: First Workshop on Pervasive Security, Privacy and Trust (PSPT 04) in conjunction with Mobiquitous (2004) 15. Josang, A., Daniel, M., Vannoorenberghe, P.: Strategies for combining conflicting dogmatic beliefs. In: International Conference on Information Fusion. (2003) 16. Josang, A.: An algebra for assessing trust in certification chains. In: Network and Distributed Systems Security (NDSS 99). (1999) 17. Campo, C., Marín, A., García, A., Díaz, I., Breuer, P., Delgado, C., García, C.: JCCM: Flexible certificates for smartcard with JavaCard. In: International Conference on Research in Smart Cards - E-Smart. (2001) 18. OASIS: extensible Access Control Markup Language (XACML) (2003) J.L.Muñoz, J.Forné, O.Esparza, M.Soriano: Certificate revocation system implementation based on the merkle hash tree. International Journal of Information Security (IJIS) (2004)