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

¿Por qué conviene utilizar diferentes certificados digitales para cada propósito?

Cada DNI electrónico contiene dos certificados digitales que corresponden al ciudadano, uno para autenticación y otro para firma. Desde el punto de vista técnico son muy parecidos, pero su uso es diferente. El primero (de AUTENTICACIÓN) se utiliza para identificarme y demostrar mi identidad digital cuando accedemos a sistemas o aplicaciones y no tiene vinculación legal. El segundo (de FIRMA) se emplea para firmar documentos o transacciones y su uso equivale a nuestra firma manuscrita.

En el caso del DNIe, se ha optado por crear estos dos certificados, por el diferente soporte legal y especialmente, porque cuando nos autenticamos ante una aplicación o sistema, lo que hace el sistema internamente es realizar una firma digital con nuestro certificado pero en este caso los datos a firmar no tienen importancia y se firma un conjunto de datos aleatorio o nulo. Un atacante podría alterar el servidor web para que enviase un conjunto de datos que no fuese aleatorio (p.e. un contrato o cualquier otros documento) y el usuario lo firmaría sin haber visualizado lo que firmaba. Al separar los certificados y dar validez legal solo al de firma y pedir el consentimiento explícito al usuario, le estamos protegiendo ante este tipo de ataques malintencionados.

Todo certificado que cumple la norma X509v3 contiene un atributo que indica el o los propósitos del certificado, es decir, para que usos ha sido emitido por la entidad que se encarga de su emisión.

Emplear un único certificado para todos los usos puede ser cómodo para el usuario, pero al mismo tiempo le expone innecesariamente a otras problemáticas. Utilizar el mismo certificado para autenticación web, smartcard logon, firma de documentos, firmar y cifrado de correos, etc.. tiene ciertas implicaciones que deben estudiarse con cuidado.

Pensemos que siempre que realizamos una operación con un certificado, es frecuente enviar al receptor junto con la firma, la parte pública de nuestro certificado para que pueda verificar con la clave pública la firma realizada. Esta parte pública puede contener información sensible que no queremos que se conozca publicamente.

Un ejemplo bastante frecuente, es incluir en el certificado digital único la dirección de correo electrónico para que pueda ser empleada para firmar correos. Supongamos que este certificado pertence a un alto cargo de una Administración Pública y que lo emplea también para firmar documentos. Al enviar fuera de la organización dichos documentos firmados, que contienen la parte pública de su certificado, cualquiera podría acceder a su dirección de correo electrónico, lo que lo expone a spam y otro tipos de ataques.

Cuando empleamos un certificado para realizar smartcard logon (acceso al puesto) y le incluimos, como es necesario, el UPN al certificado o información de logon (nombre de usuario y dominio), al firmar correos o documentos, cualquier receptor recibe también esta información interna de la organización.

Decidir cuantos certificados debe tener un usuario y que información debe contener es una tarea que requiere de una planificación detallada y comprender que datos son los estrictamente necesarios que contenga cada certificado en cada operación.

Un saludo
Rames

¿Debería la Policía ceder las CRL del DNIe?

Cuando una empresa privada se plantea la posibilidad de emplear el DNIe como elemento de autenticación para sus clientes en la web, especialmente aquellas que disponen de miles o incluso millones de clientes y prestan servicios habituales por Internet (vamos la Banca Electrónica), se encontrarán con un problema derivado que merece la pena analizar.

Si una gran parte de los clientes llegasen a utilizar el DNIe para autenticarse, y en virtud del uso recomendado, en cada transacción de autenticación se realizase una verificación del estado de revocación del certificado empleado para la autenticación, sería necesaria realizar una consulta al servicio público de consulta del estado de revocación del DNIe (http://ocsp.dnielectronico.es/) y gestionado actualmente por la FNMT-RCM.

Esto supone que el acceso a los servicios online de dichas entidades dependerán de los servicios que presta un tercero (en este caso la FNMT-RCM) y de los cuales no existe un SLA formal para garantizar su dimensionamiento y rendimiento esperados.
Parece que algunas asociaciones llevan varios años reclamando a la DGP la posibilidad de descarga de dichas CRL o listas de certificados revocados, para poder realizar dicha consulta bien localmente o bien a sistemas preparados para la alta carga de transacciones esperadas y con acuerdos de nivel de servicio.

Esta opción la ofrece la FNMT para sus certificados CERES, aunque requiere la firma de un convenio o encomienda de gestión con la FNMT y que supone una contraprestación económica en virtud del modelo de negocio de CERES que no cobra por la emisión de los certificados pero si lo hace a las empresas u organismos que necesitan verificar la revocación de los certificados (para los ciudadanos es gratuito a través de su página web).

La posibilidad de contar con las CRLs del DNIe parece una opcion necesaria e interesante, y a priori no supone riesgo adicional si se mantiene una distribución controlada y los ficheros CRL van firmados para asegurar su integridad. Asumo que esta posibilidad no ha implementado por que ello supone una modificación en los sistemas del DNIe.

Un saludo
Rames

Certificados APE (los certificados de funcionario) para logon

Los certificados APE (Administración Pública Española) son certificados emitidos por la FNMT-RCM y son para uso exclusivo del personal al servicio de las administraciones públicas en sus relaciones laborales con la misma.

Se consideran técnicamente Certificados Reconocidos según lo definido en la Ley de Firma Electrónica 59/2003 y son válidos para la realización de firma electrónica por parte del personal al servicio de las administraciones públicas y según lo definido en la Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos (LAECSP)

Existen 3 tipos de certificados APE:

• Certificado de personal adscrito a la administración o funcionario
• Es el certificado básico y se da al personal adscrito a la administración para el desarrollo de su trabajo. Es el equivalente al certificado de persona física o usuario de clase 2 pero dentro del ámbito de la administración.

• Certificado de sede electrónica
• Es el certificado cuya utilidad es identificar el organismo prestador del servicio. Permite la identificación de la identidad de los diferentes organismos. Es el equivalente al certificado de servidor.

• Certificado de sello electrónico para procesos automatizados
• El certificado de sello electrónico es un certificado emitido con el fin de que los sistemas de firma electrónica puedan actuar de forma autónoma permitiendo una actuación administrativa automatizada.

En el caso del certificado del personal adscrito a la administración o funcionario, también conocido como el certificado de funcionario, se trata de un certificado equivalente al certificado clase 2 CA (que emite la FNMT para los ciudadanos) que cuenta con una clave RSA de 2048 bits (en lugar de 1024 bits) y modificando las prácticas de certificación para:

• Incluir en el certificado datos adicionales como el cargo y el organismos al que pertenece el funcionario
• Indicar que la propiedad del certificado pertenece al organismo emisor en lugar de ser un certificado personal
• Dar la posibilidad de incluir en el certificado los datos necesarios para realizar el logon en Windows con dichos certificados cuando residen en una smartcard (smartcard logon)

Los certificados se emiten como una autoridad de certificación subordinada de la CA de la FNMT como puede verse en la imagen.

La pregunta más habitual que recibimos con respecto a estos certificados es: ¿Pero se pueden utilizar para realizar el logon en Windows sin adquirir nuevos software?

La respuesta a esta pregunta es algo más compleja que un si o un no. Los certificados cumplen los requisitos que establece Microsoft para poder ser empleados para  smartcard logon en Windows. ¿Entonces?

Hay que partir de la base que conseguir un smartcard logon con el software base de Windows no es sencillo y requiere experiencia y un conjunto de pasos para configurar adecuadamente todos los componentes:

• configurar la confianza de los servidores de Directorio Activo en la autoridad de certificación (en este caso APE)
• la emisión correcta de los certificados con todos los datos necesarios en la smartcard
• habilitar la comprobación de la revocación de los certificados desde los controladores de dominio
• instalar el software necesario en los puestos para que reconozcan la tarjeta (módulo criptográfico) y si procede el driver de los lectores.

Como dice un conocido anuncio, "para todo lo demás" casos existen las soluciones de SmartAccess (SmartID e IDOne) que nos permitirán conseguir la funcionalidad de smartcard logon de forma más sencilla y en especial en aquellos escenarios más complejos ( mejora de rendimiento, flexibilidad de configuración, integración con aplicaciones, etc...). 

Un saludo

Rames.

La revocación de certificados centralizada

Si una organización decide utilizar certificados x509v3 emitidos por un proveedor de servicios de certificación (PSC) para uso interno de sus empleados y colaboradores, normalmente existie un mecanismo por el cual, dicho organismo puede comprobar si alguno de estos certificados ha sido revocado. Esto es especialmente importante cuando lo que se emplean son certificados personales y se delega en las personas la responsabilidad de notificar al tercero si existe o se sospecha que existe una situación que pueda comprometer la clave privada del certificado.

Normalmente, el propio certificado continene la información necesaria para comprobar dicha revocación a través de Internet y mediante el uso de protocolos ampliamente aceptados pa la consulta o descarga de CRLs (Certificate Revocation List), una especie de lista negra que contiene habitualmente los números de serie de los certificados revocados por la entidad de certificación.

La complejidad se acentúa cuando el crece el número de certificados de diferentes PSC que la organización acepta. Aumenta con esto el número de protocolos de acceso a las CRL, algunos de ellos no estan implementados de serie en el sistema operativo o las aplicaciones y requieren adquirir software especial para ello como por ejemplo OCSP (Online Certificate Status Protocol) que se utiliza para validar el DNIe.

Con esta complejidad añadida a la necesidad que todos los puestos de la organización deban disponer de los protocolos y de acceso a Internet, no parece un escenario idoneo para una organización. No existe una auditoría centralizada de los accesos a la comprobación de revocación de certificados, no se puede revocar localmente un certificado, no podemos disponer con facilidad de un cache corporativo de CRLs descargadas que reduzca el tiempo de acceso, y un largo etc.

En Smart Access conscientes de esta situación, estamos actualmente desarrollando SmartID Revoke, que instalado en uno o varios servidores (depende de si la configuración es o no en alta disponibilidad) permite que los agentes de los puestos envíen todas sus peticiones a dichos servidores centrales en la organización y son estos los responsables de implementar todos los protocolos, acceder y registrar los accesos a las autoridades de validación o información de revocación de entidades de certificación, realizar un cache corporativo de la descarga de CRLs e incluso decidir revocar ciertos certificados solo para el ámbito de mi organización.

Este servicio puede instalarse en servidores de una organización o bien prestarse por un prestador de servicios como una autoridad de validación para aplicaciones del sistema (correo, navegador, etc) y para aplicaciones comerciales, al estilo que realizan para la Administración el Ministerio de Administraciones Públicas con la plataforma @firma.

Cualquier sugerencia, petición o comentario al respecto será bienvenido, asi como si hay empresas u organismos interesadas en participar en la fase de pruebas del producto. Esperamos disponer de una versión preliminar para el mes de Noviembre y una versión definitiva en el primer trimestre del proximo año.

Rames.