Estas aquiContenido / Mis impresiones con el proyecto Ceres y su uso con una smart card
Mis impresiones con el proyecto Ceres y su uso con una smart card
Como muchos sabréis Ceres es un proyecto de la Administración pública que -junto con la FNMT (Fábrica de Nacional de Moneda y Timbre)- tiene como fin proporcionar al ciudadano un sistema de autenticación y confidencialidad a la hora de conectarse con organismos del Estado u otras empresas que requieran comprobar la identidad del usuario de una manera segura y legítima.
Seguramente a más de uno le sonará de qué va la cosa, ya que en Kriptópolis se ha comentado; incluso hace poco Fernando Acero nos mostraba un fallo bastante importante en el diseño de PKI, que comprometía las firmas digitales y que, por consiguiente, afectaba al proyecto Ceres de una manera indirecta.Resulta que hace unos 4 meses cayó en mis manos el Cryptokit fabricado por la empresa C3PO. Ese kit incluye un lector usb para smart cards (en mi caso el modelo es el LTC31 v1) y también incluye un cd con software y una smart card de la FNMT...
Total, que me puse manos a la obra a experimentar con el Cryptokit. Mi primera sorpresa fue que el software que proporcionan para GNU/Linux es poco más que nulo y aunque lo incluyen en el cd, también se puede obtener desde aquí.
Sin desperdiciar el trabajo de Hispafuentes (encargados de dar soporte al proyecto Ceres en GNU/Linux) y de la empresa C3P0 (fabricante del lector y encargada de comercializar el Cryptokit), tengo que decir que las cosas se han hecho realmente mal.
Para empezar, no tiene sentido que proporcionen los drivers para Windows y sin embargo los usuarios de GNU/Linux tengamos que rellenar un formulario para que nos proporcionen un parche para que el lector funcione. Lo curioso es que ese parche sí está colgado en la web de pcsclite, y como se puede ver tampoco hace tanto como para proporcionarlo sólo tras rellenar un formulario.
He de decir que dicho lector ya funciona sin parche, algo que no está indicado en la Web del fabricante; al menos yo puedo garantizar que si funciona en mi Gentoo con kernel 2.6.17-rc4, sin la necesidad del parche. Tan sólo es necesario instalar el driver genérico para lectores (CCID) y tener en tu sistema la herramienta pcsclite para poder funcionar con el lector.Con el software indicado anteriormente tendrás funcionando la mitad de tu crypto kit, es decir, el lector usb para smart cards. Sin embargo la otra mitad de tu cryptokit es la que encierra sorpresas. Los que hayáis trabajado con smart cards bajo GNU/Linux conoceréis la aplicación opensc. Con ella se accede y se gestiona la smart card, ya sea para cambiar el pin, borrarla, trabajar con el certificado,etc.Como decía antes, siento tener que decir esto, pero el soporte que le han dado para GNU/Linux es una chapuza.
Primero, lo que han hecho ha sido coger la versión 0.8 de opensc, aplicarle algunos parches para que funcione con el lector y hacerla funcionar con los módulos correspondientes para Ceres.
Dichos módulos se publican como binarios, lo cual hace que nos olvidemos de entender prácticamente todo lo que pasa en nuestro cryptokit; no pongo en duda que la publicación de los binarios sea por "posibles motivos de seguridad" o porque la FNTM lo exigió así, no obstante no es una buena manera de hacer las cosas.El segundo fallo es que los parches que proporcionan para opensc en su difunta versión 0.8.1, dejan inutilizado el software para cualquier otra tarjeta que no sea la del proyecto Ceres. Esto no tiene sentido alguno; significa que si tienes dos smart cards, una para firmar tus documentos con el certificado proporcionado por la FNMT y otra para firmar tu correo con tu clave PGP, véte olvidándote de usar ambas en el mismo equipo, ya que si usas el software proporcionado para el proyecto Ceres en GNU/Linux, te encontraras con que opensc sólo funciona con la tarjeta de la FNTM. Esto es por culpa de los parches proporcionados por Hispafuentes; estos parches modifican opensc de tal manera que sólo funcione con los binarios de que ellos proporcionan.Actualmente estoy intentando que la tarjeta de la FNTM funcione con la versión actual de opensc (0.11) y con los binarios proporcionados por el proyecto opensc-ceres. Quiero que opensc siga funcionando con otras tarjetas y a la vez que tenga compatibilidad con Ceres, ya que no tiene sentido inutilizar opensc sólo por usar la tarjeta de la FNMT con los certificados del proyecto Ceres.Es una pena que esto ocurra, ya que la utilización de smart cards soluciona temporalmente el problema del que nos hablaba Fernando Acero, ya que si almacenas el certificado en la tarjeta sólo el que la posea físicamente podrá firmar documentos (siempre y cuando dicho certificado no se conserve también en la máquina); es cierto que siempre pueden robarte la tarjeta, pero siempre será necesario el pin para poder acceder a ella.Comentar que también me ha llamado la atención el proceso para obtener el certificado de la FNMT. Dicho proceso te exige rellenar un formulario en el segundo paso, en el cual debemos introducir nuestro NIF o NIE, estos datos no van cifrados por defecto. Es curioso, dado que el segundo paso sí que se puede realizar de manera cifrada. No entiendo por qué por defecto no redirigen hacia la conexión SSL. Como conclusiones generales puedo decir lo siguiente:- En la actualidad el proyecto OpenSC-Ceres, proyecto encargado de dar soporte al proyecto Ceres con la utilización de una smart card en GNU/Linux, está desactualizado, con una documentación muy pobre y con muy poco soporte.- Tanto Hispafuentes como C3PO deberían replantearse el desarrollo y soporte del Cryptokit. Concretamente la empresa C3P0 debería actualizar la web del lector LTC31 avisando del funcionamiento de este de manera nativa y sin la necesidad de parches en las nuevas versiones del kernel, y deberían realizar un manual actualizado para su puesta en funcionamiento en GNU/Linux.- Actualmente el proyecto Ceres ofrece certificados de 1024 bits u 2048 bits. Los certificados que tengan 2048 bits no pueden ser utilizados en la tarjeta proporcionada por la FNMT, ya que ésta sólo soporta el almacenamiento de certificados de 1024 bits. Algo que llama la atención, ya que en la actualidad sí hay tarjetas que soporten 2048 bits, por lo que deberían empezar a replantearse el cambio de modelo de la tarjeta.- La utilización de smart cards para la firma electrónica soluciona el fallo del que nos hablaba Fernando Acero, gracias a que es necesario poseer la tarjeta físicamente para firmar un documento.
GNU/DrinuS
"- La utilización de smart cards para la firma electrónica soluciona el fallo del que nos hablaba Fernando Acero, gracias a que es necesario poseer la tarjeta físicamente para firmar un documento."
Negativo:
Yo tengo una tarjeta Ceres, que tiene dos certificados distintos.... ¿cual es la diferencia entre importar un certificado a un contenedor software o uno hardware? Ninguna. De hecho, si configuras mozilla para que use la tarjeta, el procedimiento para importar certificados a la tarjeta es el mismo. En cristiano, puedo meter en la tarjeta Ceres ( o en cualquier otra ) no solo mi certificado sino el de mi pareja...
Y por supuesto, basta tener el PIN para tener acceso a TODOS los certificados de la tarjeta....
Y por supuesto, No sabes si van a usar el certificado de firma, o el de autenticación, pues los dos usan el mismo PIN....
¿Que hay que tener la tarjeta? No problemo. Mi compañero tiene un sistema basado en SingleSignOn, que le pide el pin al entrar y ya no lo vuelve a pedir... Todo es cuestión de convencerle para que se levante del puesto y se deje la tarjeta en el lector....
!Ah se me olvidaba!... que no tienes lector.... ¿cuántos pc's en españa tienen lector de smartcards? ¿Es entonces la tarjeta una solución? ¿No debería prohibir el gobierno vender equipos sin lector? ...
El problema no es el contenedor software o hardware. EL PROBLEMA ES QUE EL ESTANDARD PERMITA EL MANEJO DE CONTENEDORES, sean estos del tipo que sean.
El eDNI tiene una posible ventaja: no se pueden meter certificados nuevos... pero sigue el problema de que no sabes si la aplicación te abre el certificado de firma, el de autenticación.... o los dos
En el caso del DNIe, toda la interlocución con la smartcard la ha de realizar el driver "oficial", dado que las comunicaciones con la tarjeta van cifradas. Mientras nadie haga ingeniería inversa y sea capaz de suplantar al driver oficial, será este el que mostrará los popups. Y tengo entendido que los popups del driver oficial distinguen entre autenticación y firma, así que ese problema no existe "en condiciones normales".
Saludos. Krampo.
Por alusiones: yo fui uno de los culpables de que al menos exista el soporte para linux de Ceres. Pero mientras la FNMT (realmente el ministerio del interior) no autorice la publicación de la parte propietaria. OpenSC-Ceres está muerto. Yo no puedo realizar la actualización, mucho menos "por la cara". Y C3PO, que tenía medio comprometido el realizar el mantenimiento (para poder vender lectores :-) parece que tampoco está por la labor.
Por cierto, el site software-libre.org está muerto desde hace meses. Buscad el software en http://www.dit.upm.es/~jantonio/opensc-ceres. Aunque no garantizo que funcione con linuxes modernos...
Más por ciertos: Hay dos versiones del lector LTC31. Lo podéis verificar viendo el usbid: 0783:0003 (v1) y 0783:0006 (v2). El v2 funciona sin parche con kernels 2.6.x. el v1, al menos con kernels <2.6.16 necesita parche. En cualquier caso esto no afecta a la tarjeta Ceres, sino al lector, por lo que es un "pelin" offtopic
Jonsito en el caso al que yo me refería era tener una tarjeta por certificado, como bien dices en el momento que se comparta la tarjeta para tener varios certificados de una persona distinta volvemos a lo mismo que nos comentaba Fernando.
Sobre lo de la liberación pues decir que es una pena. Aun así me gustaría saber si hay manera de hacer funcionar la tarjeta con las nuevas versiones, es decir si hay posibilidad de jugar con los módulos o hay que meterse en código.
Sobre los lectores decirte que como bien dices hay dos versiones, según tengo entendido la v2 funciona también con el E-DNI. Y la v1 ya no necesita parche, al menos en kernels 2.6.16.X
Sobre lo de singlesingon ya entramos en temas de usabilidad y por tanto terreno pantanoso.
De todas formas para conseguir que una solución basada en smart card se tendrían que hacer comprobaciones de esta cada X minutos e implementando otro tipo de medidas que no fueran singlesingon.
Mi pregunta es ¿de quien es la culpa de que Opensc-Ceres este muerto?, ¿la FNMT? ¿C3PO?, ¿hay forma de lo vuelvan a reflotar? ¿o va a morir por culpa del E-DNI?.
Un saludo y gracias.
"Aun así me gustaría saber si hay manera de hacer funcionar la tarjeta
con las nuevas versiones, es decir si hay posibilidad de jugar con los
módulos o hay que meterse en código"
Tienes dos problemas:
- pcsc-lite está ya por la versión 1.3.1 en mi sitio web hay dos versiones: la 0.8.1-6 que funciona con pcsc-lite-1.2 y la 0.8.1-7 que funciona con pcsc-lite-1.2.9. No lo he probado -ni compilado- con versiones más modernas
- El problema para usar la parte propietaria es el enlazado con las librerias dinámicas, que está cableado a una determinada versión de zlib, openssl, etc. Si no quieres que el enlazador dinámico te dé errores, dichas versiones tienen que estar instaladas... el problema es que las distros modernas ya no las incluyen, por obsoletas. Habría que hacer un poco de softw-espeleologia
Alternativamente, podría ofrecer binarios precompilados ... para todas y cada una de las distros modernas... !!!! y mantenerlos.... !!!! . No gracias. Además hay que tener en cuenta, que por ejemplo OpenSC y Pcsc-Lite ya vienen de serie en Fedora, con lo que los conflictos de dependencias están servidos.
Eso no es correcto, los datos sí que van cifrados en el primer paso (mira el attributo action del formulario donde apunta), lo que no puedes asegurar es que la página que visualizas te ha llegado intacta tal y como la ha enviado el servidor de la FNMT (man-in-the-middle). Pero ese es otro problema distinto.
Me iba a comprar uno ¿alguien sabe si hay solucionado ya esto?. Es que a mi ni me funciona lo del cambio de PIN (con su aplicación) en mi gentoo (http://serhost.com/blog/comments.php?y=07&m=08&entry=entry070808-161830) y ya no hablemos de la web de opensc-ceres.software-libre.org que ahora ni conecta).
Me parece vergonzoso que no se hayan suministrado los fuentes desde un principio y que para cambiar el password haya que conectar con una web ¿acaso se les envía la contraseña por si la olvidas que ellos la puedan poner con tu huella digital desde las máquinas? ¿La huella generará un número que hará de puk mediante alguna fórmula biométrica?... no me está gustando nada esto del DNIe, sobre todo porque si me compro un lector es también para usar otro tipo de tarjetas (por ejemplo para meter mi llave gpg).
Llevo todo el día "ensuciando" mi gentoo y no he conseguido nada, es una pena que no faciliten los fuentes, pues el trabajo de jonsito parece muy bueno, es una lastima no haber sido capaz de hacer funcionar pam_pkcs11 con la tarjeta CERES.
Por otro lado, comprar? pásate por alguna feria de informática y es posible que consigas uno, yo me hice con el mio en una feria de mi ciudad, aunque para el uso que le voy a dar, objeto decorativo en la estantería.
Yo he conseguido que la tarjeta de la FNMT sobre un lector LTC31 (serie) funcione sobre Suse 10. Lo utilizo para leer un certificado de servidor para una aplicación web. Pues bien, puedo establecer conexión SSL con el servidor desde Firefox y desde Opera, pero desde Explorer, me da un error CKR_ATTRIBUTE_TYPE_INVALID, lo que me da la impresión de que es un problema del opensc-ceres.
Desgraciadamente, no sé por dónde tirar, porque la FNMT responde con monosílabos a todas las cuestiones.
Por cierto, ceres tampoco funciona sobre windows 2003 server (y esto está reconocido por la FNTM) :(
Yo llevo días intentándolo, y nada de nada.
Estoy utilizando openSUSE 10.3 (i586) kernel 2.6.22.16-0.1-default. Incluso he tenido que reinstalarlo, porque inicialmente tenía instalada la versión de 64 bits.
He instalado los paquetes que se indican en la escasa documentación de la página del DNI electrónico. El paquete específico para el DNI (opensc-dnie) lo he descargado de la misma página (versión Fedora, a falta de openSUSE o fuentes). La instalación funciona sin problemas (no se queja de dependencias), pero luego no funciona: si instalo la librería en Firefox, en cuanto introduzco el DNI en el lector me echa fuera. Además, si ejecuto el comando "opensc-tool --serial", me da una "Violación de segmento". El programa identifica correctamente la tarjeta, porque si ejecuto "opensc-tool -n" me responde "dnie".
No es problema del lector (LTC31 de C3PO), porque éste me funciona perfectamente con una tarjeta de la ACCV. Además, he probado con otro lector (OmniKey CardMan 3121), y el problema es el mismo. La tarjeta de la ACCV funciona con los dos.
He estado buscando si existían drivers genéricos para las tarjetas utilizadas para el DNI-e, pero por lo que he leído en este foro me da la impresión de que no.
Lo único que se me ocurre es intentar instalar versiones de software más antiguo, pero me da horror sólo pensarlo, por los problemas de dependencias.
También he enviado consultas a C3PO, FNMT y DNI-e. De momento, sólo me han respondido de C3PO para remitirme a la FNMT.