¿Por qué no puedo iniciar sesión en Windows con mi certificado de la FNMT?

Voy a tratar de dar una respuesta sencilla

Afirmaciones:

• El S.O. Windows soporta el inicio de sesión (logon) con smart card de forma nativa desde su versión 2000 - VERDADERO
• Es necesario que la smart card contenga al menos un certificado digital X.509 para hacer logon - VERDADERO
• Cualquier smartcard o tarjeta con chip es válida para iniciar sesión - FALSO (debe ser una smartcard criptográfica preparada para almacenar y operar con certificados digitales y que disponga de "drivers")
• Cualquier certificado digital me vale para hacer logon - FALSO (debe contener unos datos especiales para permitir al S.O. saber con que usuario se desea hacer logon y en que dominio)
• Puedo iniciar sesión aunque no tenga instalado el Directorio Activo de Microsoft - FALSO (Es imprescindible tener instalado el Directorio Activo o bien utilizar software de otras empresas)
• El certificado debe tener una extensión propietaria llamada UPN para iniciar sesión - VERDADERO (sirve para indicar al S.O. que usuario y dominio se usarán para hacer el logon, esta información debe incluirse al emitir el certificado y posteriormente no se puede modificar)
• Debo instalar los "drivers" de la smartcard antes de poder usarla - VERDADERO (estos "drivers" se llaman CSP o cardmodule y contienen las instrucciones que debe usar el S.O. para comunicarse con la tarjeta. Si no se instalan me aparecerá un mensaje al insertar la tarjeta en el lector. Se obtiene de la página del DNIe www.dnielectronico.es)

Si pero....:

• ¿Se puede usar el DNIe como smartcard para iniciar sesión? - SI (pero necesito instalar antes su módulo criptográfico y el software SmartID o IDOne de SmartAccess)
• ¿Se puede emplear la tarjeta de la FNMT con certificado CERES Clase 2 CA para iniciar sesión? - SI (pero igualmente necesito el software SmartID de SmartAccess, estos certificados no incorporan la información de inicio de sesión Windows)
• ¿Qué smartcard y certificado puedo usar para iniciar sesión sin tener que usar el software de SmartAccess? - Un certificado profesional que contenga la información de inicio de sesión Windows (UPN) contenido en cualquier smartcard criptográfica con drivers para Windows
• Y ¿Quien emite estos certificados? Los puede emitir mi propia empresa poniendo en marcha una PKI o bien solicitarlos a la FNMT (certificados APE), FirmaProfesional, Camerfirma, CatCert, IZENPE, ACCV, etc. especificando el UPN o nombre de inicio de sesión del usuario en formato usuario@dominio
• ¿Es sencillo de poner en marcha? - DEPENDE (Por suerte existe una artículo en la web de Microsoft que lo explica "Guidelines for enabling smart card logon with third-party certification authorities" o como alternativa en SmartAccess nos ofrecemos a ayudarte a montarlo.

Un saludo

Rames

Comprobando en Windows si los certificados del DNIe estan revocados...

Cuando nos roban o perdemos una tarjeta bancaria, llamamos a la entidad emisora para anularla y su número es incluido en una lista negra para indicar que ya no es válida. En este caso confiamos en que las empresas que realizan cobros con tarjeta comprueben siempre dicha lista para evitar que puedan ser utilizadas esas tarjetas anuladas.

Con los certificados digitales es similar, la validación de certificados (es decir, comprobar su estado de revocación) es una función crítica en aquellas operaciones relacionadas con la tecnología PKI. Toda aplicación que utilice los certificados digitales para funciones de autenticación, firma o cifrado debería bien validar todos los certificados que utiliza o bien asumir el riesgo asociado a su no validación.

Las listas negras, se llaman en este caso Listas de Revocación de Certificados (o CRL por sus siglas en inglés) y a menudo se hacen accesibles de forma publica a través de Internet para que cualquier aplicación pueda consultarlas. Las listas contienen los número de serie de los certificados vigentes que han sido revocados y la fecha de su revocación, y son firmadas por la AC emisora de los certificados como prueba de su origen e integridad (nadie puede añadir ni quitar elementos de la lista).

El método de acceso a la lista puede ser diverso, bien se publican en un servidor web y son accesibles mediante protocolo HTTP, bien se publican en un directorio con protocolo de acceso LDAP o bien se implementa un protocolo de consulta online denominado OCSP (Online Certificate Status Protocol). Este último método OCSP resulta el más ventajoso, ya que evita la descarga de las listas y solo realiza una transacción de pregunta y recibe una respuesta firmada con el estado del certificado. Esta tarea se puede delegar en un tercero denominado Autoridad de Validación.

Algunas AC habiltan varios métodos de validación como HTTP, LDAP u OCSP, pero en el caso del DNIe se ha delegado la función de validación en la FNMT y el Ministerio de la Presidencia a través de la plataforma @firma. De forma pública solo se dispone del método OCSP para la validación de los certificados del DNIe (ocsp.dnie.es).

El protocolo OCSP está definido en el RFC 2560 del IETF y se implementa en la mayoría de plataformas de PKI para su uso. Debido a su Existe también una variante de este protocolo llamada Lightweight OCSP (RFC 5019) y definida en Septiembre de 2007 para aquellos entornos donde se gestiona una alto volumen de tráfico que ayuda a reducir el consumo de ancho de banda y minimizar el consumo de recursos en el cliente.

La validación de los certificados puede ser implementada directamente en las aplicaciones mediante el uso de librerías comerciales o de software libre o bien a través de los servicios que proporcionan de base algunos sistemas operativos, descargando a la aplicación de esta tarea.

En los sistemas operativos Windows, estas operaciones de validación están incluidos en los servicios criptográficos que incopora la plataforma denominada CryptoAPI y las aplicaciones comerciales y especialmente las desarrolladas por Microsoft como Internet Explorer, Microsoft Outlook, Microsoft Office en el cliente o Microsoft IIS, Microsoft Exchange Server o Microsoft SharePoint en el servidor, hacen uso de estos servicios de la plataforma.


Lamentablemente, el protocolo OCSP no se incluyó hasta la aparición de Windows Vista y Windows Server 2008. Por tanto, para poder utilizar este protocolo en aplicaciones que se ejecutan en Windows 2000, XP o Server 2003, bien se implementa directamente en la aplicación o bien se instala un plug-in que habilita esta función en CryptoAPI (SmartAccess ha desarrollado TrustID OCSP Client) y permite que aplicaciones como Microsoft Outlook puedan validar los certificados, por ejempo cuando recibimos un correo firmado digitalmente usando el DNIe.

En el caso de Windows Vista, Windows 7 y Windows Server 2008 (R2), ya incorporan el protocolo OCSP de serie en CryptoAPI y debería poder utilizarse para validar los certificados sin necesidad de instalar plug-ins. Sin embargo, el protocolo implementado es el Lightweight OCSP (basado en el RFC 5019) pensado para altas volumenes de transacciones pero el respondedor (servidor) público que gestiona la FNMT solo admite peticiones según el protocolo OCSP (RFC 2560). Esto nos coloca en la misma situación que con versiones antiguas de Windows para validar los certificados del DNIe a través de CryptoAPI.

Esta situación, provoca muchas veces comentarios que indican que Windows no es compatible con el OCSP o que las aplicaciones de Microsoft no son compatibles con la validación de certificados del DNIe, lo cual espero haber explicado. La solución pasa por cambiar Windows (algo dificil) o cambiar el respondedor OCSP de la FNMT para que también admita el RFC 5019. Creo que sería una ayuda a los desarrolladores de aplicaciones que utilicen el DNIe para que no necesiten integrar la validación en cada aplicación que desarrollan.

Un saludo
Rames

PKI at the door (La PKI llama a tu puerta)

Hasta ahora el control de acceso físico en las organizaciones (la apertura de puertas) se basa en el uso de una tarjeta de proximidad que utiliza la tecnología RFID (contactless card). Los lectores se encargan de leer en la mayoría de los casos el número de serie único que el fabricante graba en cada tarjeta, o bien alguna información grabada en la memoria del chip, para posteriormente verificar dichos datos contra una base de datos para obtener los permisos de acceso (día y horario, autorización, etc.) y proceder o no a la apertura de la puerta.

Este esquema de cerraduras electrónicas, que lleva años reemplazando a las cerraduras mecánicas, permite una mayor seguridad con un mayor control dejando registro de quien accede y limitando el acceso a determinados horarios o fechas (p.e. días laborables) y permitiendo la revocación de las tarjetas (o llaves electrónicas) a través de la base de datos. Es frecuente ver este funcionamiento en multitud de hoteles que utilizan tarjetas de banda magnética o chip de radiofrecuencia RFID para habilitar el acceso a las habitaciones y que se desactivan cuando finaliza el periodo contratado.

Una posible evolución de este funcionamiento es lo que se ha dado en llamar "PKI at the door" y que emplea un par de claves de cifrado asimétrico (contenidas en una tarjeta criptográfica en forma de certificado digital) y que hasta ahora se utilizaban para el control de acceso a equipos o aplicaciones, también para el control de acceso físico.

¿Pero que aporta esta nueva tecnología? ¿Por qué es necesaria esta evolución?. Pues bien, hasta ahora la emisión de llaves electrónicas estaba limitada a la propia organización mediante la edición de la base de datos de acceso (o el acceso a los equipos controladores de acceso) y la seguridad no incluía la validación de la autenticidad de la tarjeta. Es decir, que hoy es posible con un equipo sencillo, duplicar una tarjeta de acceso físico. La tecnologia PKI proporciona un nivel superior de seguridad, al permitir la emisión por terceros de confianza (Autoridades de Certificación) de elementos únicos sin posibilidad de duplicación, permitiendo la externalización de la emisión de llaves manteniendo el control de acceso a nuestras instalaciones.

Además, la tecnología PKI at the door, permite el uso del protocolo OCSP para realizar una validación del estado de revocación del certificado contenido en la tarjeta mediante una pequeña transaccion de red (< 1K) para comprobar la vigencia de dicha llave.

No obstante la adopción de esta nueva tecnología no está exenta de obstaculos, principalmente la necesidad de contar con una buena infraestrura de red, los costes de cambiar los lectores y tarjetas y la mayor complejidad de administración. Entre las ventajas, podemos destacar la unificación de las credenciales para el acceso físico y logico a los sistemas de información, obteniendo los beneficios de una seguridad unificada y convergente.

En los próximo años podremos ver si esta tecnología es aceptada y adoptada por las organizaciones, y si los beneficios que proporciona convencen para afrontar los posibles obtaculos para su adopción. De momento, parece que la especificación de seguridad FIPS 201, relacionada con tarjetas de identificación para los empleados del gobierno de Estados Unidos, incluirá PKI on the door.
Os dejo un video (en inglés) donde algunos importantes fabricantes del sector dan su visión acerca de esta tecnología.
http://www.secureidnews.com/2010/10/18/industry-discusses-pki-at-the-door?issue=secureidnews_20101019

También la revista re:ID publicó en su número de primavera un especial sobre PKI on the door
http://www.regardingid.com/images/reid_spring10_web.pdf
Un saludo
Rames