E. Jacob, F. Liberal y J. Unzilla
Las infraestructuras de clave pública se perfilan como una de las soluciones más válidas para prestar los servicios de seguridad básicos por medio de certificados digitales. Sin embargo, el modo de operación tradicional a través de interfaz web y con envíos asíncronos, así como la complicación de los procedimientos de registro, ha supuesto que estén siendo sustituidas por otros sistemas en gran parte de los escenarios para los que fueron concebidas. Esas alternativas, más ágiles, presentan generalmente mecanismos de seguridad más laxos y requieren excesivos conocimientos por parte del usuario. El sistema planteado pretende servir de puente entre ambos enfoques por medio de una PKI automatizada, con procedimientos de interacción on- line, orientada a ámbitos de aplicación concretos, basándose en PKIX. Se ha desarrollado un prototipo sobre Linux, utilizando la librería criptográfica cryptlib©.
Palabras clave: PKI, Certificados, CA, RA, PKIX, cryptlib, Clave Pública
Public Key infrastructures are considered the most suitable systems to provide basic security services through digital certificates use. Nevertheless, traditional way of operation, based on web interface and asynchronous interactions, as well as the cost and difficulty of registration processes, have provoked their replacement with other systems in many of the scenarios PKIs were conceived for. These more efficient solutions present generally laxer security mechanisms and require too much user knowledge. The system we propose tries to provide a bridge between both approaches by defining an automated PKI focused on specific application scopes by using on-line interaction procedures based on PKIX. A prototype has been developed on Linux, using cryptlib© library as the cryptographic support.
Keywords: PKI, Certificates, CA, RA, PKIX, cryptlib, public key,
1.- Situación y antecedentes
La necesidad de establecer un agente de confianza que permitiera garantizar los servicios básicos de seguridad (integridad, confidencialidad, autenticación y no repudio) ha llevado a la definición de las Infraestructuras de Clave Pública (PKI): una combinación de elementos hardware, software, políticas y procedimientos que proporcionan mecanismos para la expedición, distribución, validación y revocación de certificados digitales, considerados como los elementos más válidos para la prestación de dichos servicios.
Los desarrollos clásicos de PKIs han chocado constantemente con las implicaciones para la seguridad del sistema de los procedimientos involucrados en cada una de las operaciones, sobre todo en los puntos críticos de registro de un usuario y protección de la información sensible (PSE).
Tradicionalmente, se ha pretendido dar solución a la cuestión de controlar las operaciones, tratando de proporcionar al usuario la mayor información posible acerca de los pasos a seguir, ofreciéndole una interfaz lo más amigable y completa posible, generalmente vía www. De este modo, se pretende involucrar al usuario final de forma activa en los procedimientos y que sea consciente del significado de cada una de esas operaciones.
Otro aspecto a considerar en los esquemas clásicos de PKI con interfaz web, es que generalmente las operaciones son asíncronas, debiendo esperar a que un operador procese la solicitud enviada y devuelva la respuesta. El proceso se complica aún más si la comprobación requiere la presencia en la RA del solicitante con los requisitos administrativos necesarios para comprobar su identidad.
Por otra parte, unida al hecho de que el usuario deba comprender los campos del certificado, está asociada la rigidez del formato de los mismos. Esto hace que corresponda al usuario, en la mayoría de los casos, la responsabilidad de cumplimentar los campos del certificado a solicitar. Generalmente, los tipos de certificados son fijos y restringidos por el diseño de la interfaz. Supone además que la tarea de añadir un nuevo servicio o un nuevo tipo de certificado resulta compleja, al tener que modificar tanto la interfaz en sí como los CGIs, el código embebido en HTML..., es decir, el procesamiento interno del sistema.
Estos procedimientos, unidos a las graves implicaciones legales del establecimiento de una PKI pública derivadas del Real Decreto de septiembre de 1999 [1], han supuesto en la práctica que las tareas de gestión de certificados resulten engorrosas y, en gran medida, lentas y costosas, con lo que se ha optado en muchos casos por sistemas más ágiles pero con unos procedimientos de seguridad más laxos. Estos sistemas, además, requieren muchas veces el conocimiento por parte de los usuarios de los fundamentos de la tecnología aplicada (como SSH y PGP).
Como se verá más adelante, el diseño planteado en este proyecto pretende facilitar las operaciones de interacción mediante la automatización de ciertas tareas, lo cual rompe de lleno con los procedimientos y con lo que se entiende como el funcionamiento clásico de una PKI, sobre todo en lo referente al modo de operación tradicional de la CA y a la protección de las claves. Las decisiones de diseño adoptadas en ese sentido se adaptan a la orientación del sistema que no es prestar servicios públicos como PKI a usuarios personales, sino que surge ante la necesidad de proporcionar mecanismos ágiles de expedición de certificados para entornos concretos, como el de un PSI dando servicio a empresas cuyo intercambio de información sea alto.
Muchos de los procedimientos desarrollados en el proyecto se derivan de las propuestas que, ante todos los problemas relacionados con la automatización de las interacciones con una PKI, ha venido planteando el grupo de trabajo PKIX [2]. Este grupo fue creado por el IETF en 1995 y está orientado a desarrollar los estándares de Internet necesarios para proporcionar una PKI basada en X.509.
Pero quizás la aportación más importante de PKIX es la definición de protocolos que gestionan las interacciones con la PKI y el hecho de que dichas gestiones se realicen sobre diferentes "medios de transporte", entre ellos de forma on-line mediante conexiones TCP. Para ello, PKIX define una serie de operaciones así como el formato de los mensajes utilizados, por ejemplo, para las tareas de inicialización/actualización y revocación (protocolo CMP/CRMF [3]) así como la validación a través del protocolo OCSP[4].
2.- Diseño
La arquitectura general del sistema se resume en la utilización de una o varias RAs subsidiarias de una CA central, y un sistema de directorio encargado del almacenamiento de las CRLs y certificados expedidos.
Para descentralizar la tarea de registro (y favorecer y abaratar la comprobación de la identidad del usuario durante la misma) se van a articular varias RAs en torno a una CA encargada únicamente de
certificar automáticamente las solicitudes que le van a enviar a modo de agentes proxy las RAs. En la CA, por tanto, únicamente se comprobará que la solicitud recibida ha sido cursada por una RA de confianza del sistema (delegando en ella la responsabilidad de comprobar la identidad del usuario).
Este esquema permite además la posibilidad que la empresa explotadora de la PKI utilice RAs gestionadas por otras entidades.
De este modo, el papel de la CA se limitaría a asegurar la integridad de su clave privada, sobre la que se sustenta todo el sistema y ejecutar las operaciones finales de expedición de certificados, aceptando automáticamente las peticiones de la RA.
Independientemente de si son gestionadas por la empresa que explota la CA u otra, las RAs van a ser las encargadas de recoger las solicitudes de los usuarios, constituyendo por tanto la interfaz exterior del sistema. Además, va a ser en las RAs donde se efectúe el procedimiento de registro: comprobación inicial de la identidad y posterior solicitud de certificación.
Con el objetivo de agilizar y facilitar al máximo el proceso de registro de cara al usuario, el diseño planteado contempla el siguiente mecanismo para la inicialización de un usuario: Inicialmente, el usuario o entidad solicitante se pone en contacto con la RA más cercana, para llevar a cabo la única interacción humana que va a requerir todo el proceso: el alta del usuario en el sistema.
El resto de operaciones a realizar para emitir los certificados pasan a automatizarse y ya no van a requerir la aprobación de ningún operador humano.
El proceso de alta consiste en que el operador de RA, tras comprobar según la política de seguridad de la RA descrita en su CPS la identidad del usuario, va a rellenar todos los campos del futuro certificado con los datos de éste y a almacenar una entrada con los mismos en la BD de la RA. Durante ese proceso el servidor de RA va a generar un ID y un password que el operador va a entregar fuera de banda al usuario. Esos datos son lo único que necesita el cliente para posteriormente realizar una solicitud de certificado (mediante el protocolo CMP/CRMF) a la RA.
Ésta, tras comprobar ID/passwd, va a recoger la pre- solicitud almacenada en la BD, generada a medida del usuario en el proceso de registro (con todos los campos cumplimentados), la va a rellenar con la clave pública que le ha proporcionado el usuario y la va a reenviar a la CA. Ésta será la encargada, finalmente, de generar el certificado, devolverlo a la RA y publicarlo en el servicio de directorio. Este esquema libera al usuario final de cualquier cuestión relacionada con los campos de la solicitud puesto que éstos son rellenados por el operador durante el registro, y el usuario sólo utiliza el ID/passwd, facilitando en extremo la operación de registro, la más problemática en este tipo de tecnologías.
Por otra parte, frente al enfoque clásico, cuyo interfaz web imponía serias restricciones a la hora de proporcionar diferentes tipos de certificados, en el diseño planteado la solicitud de un tipo de certificado u otro es completamente idéntica, puesto que el usuario únicamente debe introducir el ID y password que le han entregado en el procedimiento de registro.
Evidentemente, en algún punto se debe poder elegir entre un tipo de certificado u otro, así como cumplimentar los campos necesarios en cada caso. Ese punto va a ser precisamente el procedimiento de alta de un usuario por parte del operador de RA. Para ello, en la base de datos de RA se mantiene una tabla de tipos de certificados, en la que, para cada uno de los campos/extensiones contempladas en los certificados X.509v3, se va a codificar si el campo/extensión en cuestión es obligatorio u opcional, y si debe ser rellenado por el operador de RA o automáticamente por la RA misma. En ese caso se almacena además el valor del campo (caso típico de las extensiones de keyusage, extensiones propietarias de Netscape o Microsoft, etc, que para un determinado tipo de certificados serán fijas).
De este modo, en el procedimiento de registro, una vez que el operador de la RA ha introducido el tipo de certificado que se va a solicitar, el servidor de RA va a ir leyendo de la base de datos los posibles campos/extensiones asociados a ese tipo de certificados. Si el campo en cuestión lo debe rellenar el operador de RA le solicitará a éste el valor, y si lo debe rellenar la RA automáticamente lo incorporará a la pre-solicitud que genera con los datos introducidos por el operador. Una vez finalizado este proceso se almacenará la pre-solicitud en la base de datos y, cuando el usuario posteriormente realice la solicitud utilizando su ID/password, será dicha pre-solicitud la que se utilice para expedir el certificado.
El resto de operaciones con certificados a realizar con la PKI son más sencillas, puesto que el usuario ya dispone del certificado que permite autenticarle frente al sistema, realizándose los procesos de revocación y actualización de forma completamente automática.
El sistema proporciona además servicios de validación, a través de las RAs que actúan como respondedores OCSP autorizados. El esquema utilizado en las RAs, se asemeja al funcionamiento de los servidores DNS en los dominios de los que no son autoridad. De este modo, las EEs consultan el
Boletín de RedIRIS, nº 58-59, diciembre 2001-enero 2002
estado de un determinado certificado a la RA que conocen (generalmente porque la utilizaron para su registro) y en caso de que ésta no disponga de información lo suficientemente actualizada acerca del certificado en cuestión va a realizar una consulta a la CA emisora.
Finalmente y, puesto que en el desarrollo propuesto se considera usuario final (EE) a la aplicación que va a utilizar los servicios de certificación, la interfaz con éste va a consistir en una API de funciones, una capa de adaptación sobre la librería criptográfica utilizada. Esa capa de adaptación va a facilitar al programador y al usuario final el acceso a la PKI, al ocultar la complejidad de muchas de las operaciones.
Tanto para la librería como el resto de desarrollos se utiliza la librería criptográfica cryptlib© [5] y lenguaje C en sistemas Linux. En este momento el prototipo, desarrollada en su totalidad por Fidel Liberal, tiene alrededor de 9.000 líneas de código. Los principales problemas encontrados han estado ligados a la utilización de la mencionada librería, que no ofrece un acceso cómodo al bajo nivel.
3.- Conclusiones
En este proyecto se pretende dar un paso más en la prestación de servicios de certificación, por medio de la automatización de la mayoría de los procesos de interacción, con tres objetivos fundamentales:
- Agilizar los procedimientos a la vez que se reducen las operaciones que requieran operadores humanos.
- Flexibilizar la prestación de servicios de certificación, al homogeneizar el mecanismo de acceso, permitiendo añadir fácilmente nuevos tipos de certificados.
- Facilitar el acceso a los usuarios a la vez que se prestan servicios tan complicados como se desee.
La implementación, ha pretendido, por un lado, agilizar las operaciones de gestión de certificados, por medio de servidores multihilo que se adaptan a la carga, y flexibilizar las interfaces de administración mediante la definición de un sistema de comandos/respuestas sobre el que desarrollar clientes más o menos amigables.
4.- Referencias
[1] Real Decreto-Ley 14/1999, de 17 de septiembre, sobre Firma Electrónica. (B.O.E. 18-09-1999)
[2] IETF PKIX WORK-GROUP, Grupo de trabajo de IETF sobre PKIX. Consultado en http://www.ietf.org/html.charters/pkix-charter.html
[3] IETF, RFC2510 Internet X.509 Public Key Infrastructure. Certificate Management Protocols. Marzo 1999.
[4] IETF, RFC2560 Internet X.509 Public Key Infrastructure. Certificate Online Certificate Status Protocol - OCSP. Junio 1999.
[5] Librería cryptlib©. Consultado en http://www.cryptlib.com
(
jtpjatae [at] bi [dot] ehu.es)Fidel Liberal
(
jtblimaf [at] aintel [dot] bi.ehu.es)Juanjo Unzilla
(
jtpungaj [at] bi [dot] ehu.es)Dpto. de Electrónica y Telecomunicaciones
UPV/EHU