Remitido
La Dirección General de la Policía y la Guardia Civil ha publicado el código fuente del paquete opensc-dnie.
El código no incluye la clave privada de componente necesaria para el establecimiento del canal seguro, por lo que no se puede considerar funcional hasta que dicha clave se haga pública...
Las consultas relacionadas con éste y otros asuntos relativos al DNIe serán atendidas en oficinatecnica@dnielectronico.es.
El siguiente URI lleva al área de descargas donde se encuentra el producto: http://www.dnie.es/descargas/codigo_fuente.html
Un saludo.
Oficina Técnica del DNIe.
Cuerpo Nacional de Policía.
En que estado se encuentra??
Alex DTM2 Septiembre 2010 - 2:59pm
Hola amigos,
No hay novedad alguna sobre la liberación de la clave privada de componente necesaria para el establecimiento del canal seguro? Alguien ha intentado traducir el código a Java?? Estaría interesado en colaborar...
Saludos!!
Por mi opiñon no hay ningun sentido
drune8 Septiembre 2010 - 9:20am
Por mi opiñon no hay ningun sentido "traducir" el código a java tal qual. Los fuentes que tenemos son implementacion del PKCS11 ademas muy "juntado" con librerias de OpenSC. Así para mundo Java veo 2 opciones:
1. Usar implementacion PKCS11 nativa para cada sistema operativa desde el proveedor de sguridad de SUN.
2. Implementar PKCS15 en Java 6 (Realmente existe una buena parte emplementada en java que se puede encontrar en la pagina de OpenSC y falta implementar el Tokien para DNIe)
En fin tenemos el problema que necesito "Permiso Oficial de usar los certificados de establecimiento del canal seguro". Sin resolver este problema solo podemos "disfrutar" con la implementcion Oficial del PKCS11.
Saludos
problema dnie
anv27 Agosto 2010 - 12:54pm
Comento mi problema con el dnie.
Para empezar, lo tenía funcionando correctamente en Mandriva 2010.0 utilizando el driver propietario más el parche de versión.
En Mandriva 2010.1 esto no funciona. Firefox da un error de la conexión SSL.
Visto este problema, decidí hacer funcionar el driver libre. Hice un programa que puede extraer del shared object del driver oficial, las claves necesarias simplemente buscándolas por su nombre. Creo que podría distribuirlo porque en realidad no es un programa específicamente para esto sino que es una función capaz de interpretar la estructura de un archivo ELF y leer los datos de la sección que se le pida. Sabiendo el nombre de la sección, las claves se obtienen fácil.
Con esto, compilé el driver libre y aparentemente funciona bien porque pide el pin y lo acepta. De hecho, con openoffice puedo firmar documentos. Sin embargo Firefox da un error diferente.
Dado que antes el driver propietario funcionaba, decidí investigar más por ahí. Volví a una versión anterior de Firefox, y también volví a la versión anterior de Opensc pero la cosa sigue sin funcionar. Así que debo suponer que el problema es de incompatibilidad con alguna otra biblioteca.
Por otro lado, el driver libre funciona con openoffice pero no con firefox, y lo más curioso de todo es que la utilidad pkcs11-tool se queda colgada con el driver libre, mientras que con el propietario devuelve la información esperada.
¿Alguien está trabajando en esto actualmente? Tal vez se podría incluir la carga dinámica de las claves en el driver libre para evitar problemas legales.
Que chapuza ni en windows
serhost216 Julio 2010 - 8:42pm
Como pueden ser tan chapuceras las administraciones públicas! He tratado estos días (se me ha estropeado mi disco principal por el famoso bug de los seagate 7200.11) de generar otro certificado de la fnmt, es lo que queda en linux de momento... Pues bien, tras añadir los certificados raíz de la fnmt, veo que varias administraciones: www.sergas.es por ejemplo tienen mal los certificados (tienes que añadir el de la fnmt y permitir subdominios distintos para PODER usar el certificado del dnie).
Veo que los drivers para windows del dnie tampoco andan muy finos (ni funcionando con firefox ni con exploiter). NO puedo obtener el certificado de la fnmt usando el dnie. Pues bueno, habrá que hacerlo presencialmente en algún día que tenga libre.
Que GRAN chapuza el DNIE, que decepción la manera en que la administración pública aplica la criptografía/cifrados!
No desesperes
Andy16 Julio 2010 - 11:38pm
Yo he recuperado mi Seagate 7200.11 siguiendo esta guía. En mi caso, he utilizado una vieja interfaz USB para un teléfono Siemens que tiene los voltajes correctos (3.3V). Lo he hecho desde Linux sin mayores inconvenientes.
RE: Desesperado ya y esperando a sesperar de nuevo :D
serhost217 Julio 2010 - 8:24pm
Si, me tocó bastante las narices lo del disco, sobre todo porque el backup está corrupto. Si, copiarlo todo en sólo dos discos no es suficiente, pero lo he enviado a Seagate que se hacen cargo sin gastos de envío siquiera. A ver si tengo suerte y es sólo cosa del firmware :)
Pero lo que decía, me parece fatal la forma en que la administración aplica las herramientas de que dispone. En este caso el Sergas (Servicio gallego de Salud) solo te deja solicitar el historial clínico con el DNIe (no con el certificado de la FNMT) y usan un certificado de clase 2ca de la FNMT en un subdominio distinto al que aparece en el CommonName del certificado, vamos, para mear y no echar gota.
Y no sólo ellos, la práctica totalidad te dejan acceder con el certificado de firma y firmar con el de autenticación. No se pueden poner claves distintas, el API para acceder a los datos del DNIe ha sido tan oscuro al principio que casi nadie lo usa. Por ejemplo: en los hoteles para tomarte los datos: nombre, DNI y dirección sería mucho más cómodo leer el chip que escanearlo y usan OCR.
Correos te obliga a "firmar" en su PDA para recoger ciertos envíos, lo cual veo fatal por no tener el papel como antes, siempre me tengo que pasar en persona a la oficina porque no confío en su PDA y esa firma no puede ser legalmente válida. Correos iba a usar el DNIe, pues aún no lo han hecho. El chip del DNIe, en mi opinión, debería tener una interfaz de "autenticacion menos segura" para sin PIN verificar tu identidad, algo tan simple como tus datos (nombre, dni, fecha de expiración del documento y dirección) firmados por la CA correspondiente y lo mismo para acceso a ciertos edificios oficiales agilizando así los trámites de toma de datos.
Vamos, que la tecnología podría explotarse MUCHO más, es una lástima que esté tan infrautilizada.
Ah por cierto, gracias por lo de la recuperación, ya lo había leído pero haciéndolo Seagate de gratis... pues prefiero no arriesgarme mientras tenga opción, además, los datos están en una partición cifrada.
Aprovecho para hacer una sugerencia/petición a admin: ¿podrías poner esta noticia de la liberación de drivers del DNIe de nuevo en portada? me parece la mar de interesante porque desde este sitio se está gestando la actualización y soporte de los drivers para el DNIe. Si no puede ser lo entenderé :)
Estado claves privadas
metalpain19 Junio 2010 - 4:14am
Hola,
¿alguien ha solicitado a la DGP la liberación de las claves privadas? Estoy pensando en hacerlo. Tengo listo un paquete para la instalación del DNIe en Ubuntu/Debian, tan solo necesito que las claves sean públicas... ¿Alguien lo ha hecho ya? ¿Habéis obtenido alguna respuesta?
Saludos
Vreixo
I did it... no response
jonsito19 Junio 2010 - 2:02pm
En cuanto tuvimos un tar.gz ejecutable contacté con la DGP (tanto en sac@ como en oficinatecnica@ )
enviandoles una copia del tgz y solicitando información sobre licencia, y permisos de publicación, tanto del fuente "capado" como de las claves.
De esto hace una semana, y todavía no he recibido noticias.
No obstante hay una "tercera vía". Un amigo (que por cierto escribe tambien en este hilo, y no soy yo :-) me ha enviado un script que coge el binario de fedora 10, y le extrae "al vuelo" las claves. No sería demasiado complicado, hacer un makefile que automáticamente "inyectara" dichas claves al fichero trusted_channel.c, y de éste al compilador, generando un ".o" con las claves.
De esta manera, el usuario dispondría de un fuente "completo", que al compilar generaría un binario con las claves insertadas, sin necesidad de conocerls, almacenarlas, tenerlas en claro, o... No tengo muy claro cuál sería el status legal del binario, pero el fuente sería GPL sin problemas y sin necesidad de incluir clave alguna.
En argot Fedora, este tipo de "fuentes" se denominan "xxx-nosrc.rpm", y se usan para incluir binarios, firmwares, etc, etc
Estoy poniendo a punto un rpm que usa esta técnica... en cuanto tenga un poco de tiempo libre lo termino y lo publico.
Juan Antonio
Comienza el desarrollo de la versión de la comunidad
Edulix23 Junio 2010 - 5:43pm
Esta mañana me han avisado de que han subido la nueva versión del código bajo licencia GPLv3, y luego he encontrado este hilo en kriptópolis, que me he leído de pe a pa. He cogido el código que subió jonsito, lo he estado intentando compilar en linux y:
* Resulta que en Arch Linux tenemos una versión de lib-assuan 2.0 y el código usaba la 1.0, así que he parcheado dialog.c para que utiliza la nueva librería.
* El paquete opensc de arch linux en AUR estaba obsoleto y no soportaba 64 bits, he hablado con el maintainer y ahora soy yo el maintainer y funciona y está actualizado.
* He creado un repositorio en gitorious donde podemos colaborar en el desarrollo de la versión "de la comunidad" de opensc-dnie: http://gitorious.org/opensc-dnie . ¡Estáis todos invitados a colaborar! Pronto crearé también una lista de correo.
* He automatizado en el script gen.sh la extracción de los certificados a partir del .deb que ellos mismos proporcionan, utilizando nm y xxd, generando el fichero keys.inc. No obstante como he hecho todo esto sin un lector de dnie no he podido comprobar si extrae estos datos correctamente, por favor jonsito ¿puedes comprobarlo / arreglarlo?
Podéis si queréis crear una lista de correo en google groups o algún otro sitio y seguimos por ahí, o mandarme un correo. Quien quiera colaborar que me lo diga y le añado al grupo de desarrollo de gitorious.
Me temo que hay algún fallo....
jonsito23 Junio 2010 - 7:42pm
La idea es buena, pero creo que se te han ido un poco los calculos con las extracciones de los datos... los offsets que calculas -y que son correctos- los utlizas desde el comienzo del fichero, en lugar del comienzo de la sección "static", con lo que los datos están totalmente desplazados de sitio. En lugar de xxd te sugiero que busques otra utilidad que pueda manejar mejor los ficheros .o
Tengo que reconocer que los tienes muy bien puestos publicando ese script. Yo lo más que me atrevo es a decirte si genera o no las claves correctas.
Pista: en el artículo sobre ingeniería inversa del que se escribió hace poco un reportaje en KP, tienes publicados (en capturas) los códigos de los certificados. Si consigues arreglar el script para que los certificados te coincidan, conseguirás tambien que los datos de las claves te salgan correctos.
Desgraciadamente el script ni es mío, ni estoy autorizado a pasárselo a nadie. Es de un chico que sabe mucho de Firefox y de gpinentry y que escribe en este hilo... y que estoy seguro que nos leerá y se inscribirá en el web que indicas.
Y otra cosa: ahorrarás muchos problemas legales si en lugar de generar y guardar un fichero de claves, calculas los datos "al vuelo", y los insertas junto con el trusted_chanel_card.c "empipados" directamente en el gcc. Así no queda "rastro" y obtienes un binario con las claves insertadas on-the-fly
Por lo que tengo entendido, la idea de la DGP al publicar el código del dnie como GPL es "forzar" a que los "desarrolladores" proporcionen a la DGP el fuente de sus desarrollos. En el caso de que la DGP de el "placet" al código, procedería a dar las claves y a firmar el fuente... Es lo que deduzco de las conversaciones de los diversos foros de DNIe que hay por ahí, porque lo que es la DGP de manera oficial no sabe, no contesta...
Yo también procedo a inscribirme en el web.
Pero me gustaría que el tema legal acerca de las claves estuviera mucho más en "texto claro"
jonsito cagueta.
No veo yo porqué iba a haber
Edulix24 Junio 2010 - 12:53am
No veo yo porqué iba a haber tanto problema por publicar un código que en parte ya ha sido publicado en kriptópolis como bien dices. Ya tengo un script que sí que funciona, pero antes les he mandado un email (que caerá en saco roto...) informándoles, a ver si me dan el "placet".
Otra cosa: ¿A qué te refieres con insertar las claves on-the-fly, te refieres a meterlas mediante objcopy o algo asi?
Por último, si quieres colaborar puedes o bien crearte una rama de desarrollo tú o te añado al equipo de desarrollo, como veas. Necesitamos también una lista de correo, pronto la crearé.
On the fly
jonsito24 Junio 2010 - 12:21pm
Me refería a meter el script en el Makefile, de manera que sin generar fichero alguno, gcc recibiera por stdin el fichero "trusted_chanel_card.c" con las claves insertadas, de manera que "automágicamente" se generara el binario "pata negra"
En cuanto a participar... me he dado de alta como watcher, pero la verdad, no lo tengo claro. En mi opinión debería ser la gente de OpenSC , o incluso la propia DGP quien llevara la voz cantante con el tema repositorios.
He preguntado en la lista de OpenSC, pero me da que hasta que los temas legales no estén claros no van a meter ni un solo bit en su repositorio, ni siquiera en una rama separada... Y en cuanto a la DGP... de momento no sabe no contesta.
Por otro lado, dado que el código tiene "peculiaridades" específicas (como el manejo de ficheros comprimidos dentro de la tarjeta), sería muy difícil hacer un desarrollo LGPL paralelo e independiente del GPL publicado, como sugiere Alejandro en algunos mensajes. Mientras no se clarifiquen los temas legales, tenemos código, tenemos claves, pero poco podemos hacer mas que instalarlo en nuestras máquinas e ir preparando paquetes a la espera de que se abran las puertas.
Por cierto, Alejandro: antes de aplicar lo de que "el que calla otorga", te sugiero que leas el artículo 100 de la Ley de Propiedad Intelectual, o la Ley de Secretos oficiales. Eso de "avisar y si no hay respuesta publicar", teniendo a Rubalcaba enfrente... pues yo como que me lo pensaría....
Juan Antonio
Coincido contigo
admin24 Junio 2010 - 3:34pm
Si yo trabajara en el DNI-e no me perdería este foro (y menos ahora).
Por tanto, y supuesto que ellos están al día de lo que aquí se cuece (y que si no ya han sido informados), que muevan ficha y digan algo.
Me parece absurdo hacer el trabajo y enfrentarse -además- a posibles problemas legales.
No creo que termine
Edulix24 Junio 2010 - 6:46pm
No creo que termine publicando dicho script hasta que respondan. Si acaso mientras tanto publico un script que no funcione, con una línea que diga algo así...
# BUG: Hay un bug en la línea siguiente por lo que el script no funciona y por eso la he comentado. # ¿Igual en vez de "e xport" es "export"? no tuve tiempo para probarlo... #e xport offset=$[$(readelf -a trusted_channel_card.o | grep ".rodata " | head -1 | awk '{print "0x"$6}')]¿Totalmente legal no? al fin y al cabo el script publicado en sí (tal como el que si que hay en el repo de gitorious) no extrae más que datos aleatorios de un binario, qué maldad hay en eso.
A ver, que me parece que no
anv25 Junio 2010 - 9:44am
A ver, que me parece que no me queda claro exactamente qué es legal y qué no.
Por un lado, tenemos el driver binario que ellos distribuyen. Opensc lo carga en memoria y lo usa. Eso obviamente es legal.
Ahora bien. Es olbigatorio cargar el driver completo o por ejemplo podríamos cargar sólo una parte de él porque el resto ya lo tenemos implementado de otra forma?
Si esto es legal, entonces el driver libre podría cargar sólo la sección que contiene la clave.
No me refiero a lo que se ha hecho hasta ahora (un script que extrae la clave y genera un .inc para meter en el programa en C) ni a la posiblidad de extraer la clave y ponerla en un archivo aparte. Lo que digo es que se podría hacer que el driver libre no contuviera la clave en ningún lado sino que la extrajera del driver cerrado cuando fuera neceasrio.
¿Tampoco esto sería legal?
Artículo 100 LPI
jonsito25 Junio 2010 - 12:41pm
A ver, vamos a leer la ley:
Texto refundido de la Ley de Propiedad Intelectual.
http://civil.udg.es/normacivil/estatal/reals/Lpi.html
Sobre la ingeniería inversa
Artículo 100
Reconozco que no soy abogado, ni se me da bien la interpretación de textos jurídicos, pero según entiendo tenemos que:
- El punto 5b nos permite hacer ingeniería inversa para extraer la clave
- Peeeeeero el punto 6b nos impide hacer públicos los resultados.
- Por otro lado, el punto 6c nos prohibe distribuir el código con claves sin permiso de la DGP (no así el resto del código, que cae bajo la GPL)
- Y finalmente el punto 7 nos prohibe hacer programas derivados que hagan un uso ilegítimo del código (pe: meter un keylogger)
Adicionalmente, y por lo que se comenta en otros foros, las claves están afectadas también por la Ley de Secretos Oficiales, por lo que la cosa es un pelín más peliaguda.
En resumen, entiendo que si nos basamos solo en la LPI, y aplicado al DNIe
a) Podemos hacer ingeniería inversa y explicar cómo se hace, pero no publicar los resultados
b) No podemos publicar un binario que incluya las claves
c) No tengo claro si es legal o no publicar el script de extracción de claves
¿Algún abogado en la sala?
Según lo que has dicho,
anv28 Junio 2010 - 9:31am
Según lo que has dicho, entonces no habría prohibición alguna de que un programa cargue en el momento de su ejecución una sección extraída del driver propietario que se distribuye (la que contiene la clave)
Ya se que es sucio pero si no hay más remedio...
Pero es legal
Edulix26 Junio 2010 - 12:10pm
Pero es legal publicar un script que no extrae las claves porque contiene un bug ¿no? Un bug más o menos documentado, claro.
Por otra parte también es cierto lo que dice anv: es posible crear un binario que no contenga las claves, sino que la extraiga en tiempo de ejecución... pero para eso igualmente necesita ejecutar algo (un script, o un código dentro del binario) que extraiga las claves, que no sabemos si es legal publicar. Pero al menos resuelve el problema de distribución de binarios.
"el que calla otorga"
anv24 Junio 2010 - 11:54am
Tal vez se podría utilizar el método de "el que calla otorga", y mandarles un burofax o algo así informando que se ha creado un pequeño programa para extraer una sección de su driver oficial necesaria para que funcione el driver libre y que si en el plazo de "xxx" días no indican lo contrario, se interpretará que no tienen objeción al respecto.
Buena idea!
Edulix24 Junio 2010 - 3:20pm
Buena idea Alejandro, creo que tenemos que hacer eso. Yo me encargo de enviar el burofax, pero tenemos que escribirlo entre todos, mirad lo estoy escribiendo aquí: http://piratepad.net/TB6zpyLqZl . Por otra parte, ¿alguno puede crear un grupo de google groups para el "proyecto de la comunidad" de opensc-dnie? Yo lo he intentado pero me lleva a un bucle infinito de redirecciones.
¿A quien le enviamos el burofax? En http://www.dnielectronico.es hay un teléfono de información, pero no un fax. Por otra parte el "copyright notice" de los ficheros es de la "Dirección General de la Policía y de la Guardia Civil". Según http://www.policia.es/bit/contactar.htm su número de fax es: 915 822 756.
Buena idea!
Smart_comm4 Julio 2010 - 11:55am
El sitio adecuado parece la subdirección técnica; supongo que algo tendrán que ver con todo esto; y si no, al director:
http://www.mir.es/MIR/Directorio/Servicios_Centrales/Direccion_General_d...
http://www.mir.es/MIR/Directorio/Servicios_Centrales/Direccion_General_d...
Sobre burofax
serhost228 Junio 2010 - 8:53am
He escrito un pequeño texto que espero ayude, se podría pulir y eliminar lo que veáis innecesario. Espero que ayude.
Sobre burofax
Smart_comm4 Julio 2010 - 11:36am
No está mal, aunque no estoy seguro de que estén obligados a publicar instrucciones de compilación y demás; eso sólo es necesario si el contenido o parte de él se ofrece en forma de código objeto ya compilado que pudiera dejar de ser funcional tras algún cambio de dependencias. Por otra parte, la palabra "conminar" está un poco fuera de lugar; es sinónimo de "amenazar" y de "ordenar con potestad". Yo redactaría el párrafo así: "Con el fin de disponer de una versión funcional del middleware para DNIe independiente de la plataforma, se les solicita la publicidad inmediata de los componentes necesarios para ello, anexos al código fuente que ya han publicado, a saber, certificados y claves utilizados en las etapas de establecimiento de canal seguro."
Apoyo la postura de Admin. No parece adaptativo "provocarlos" con presiones que, aun siendo evidentes y justas para todos, puedan volverse contra nosotros. Ahora la pelota está en su tejado. Me consta que va a publicarlo pero según han dicho en alguna charla de INTECO, tienen problemas con no se qué producto que están desplegando para la publicación... además... es Julio, ya saabes, atascos, playa, parálisis administrativa,... :-)
Lo cierto es que la palabra
serhost28 Julio 2010 - 1:52pm
Lo cierto es que la palabra conminar en su segunda acepción: "2. tr. Apremiar con potestad a alguien para que obedezca.". Pero si, reconozco que quería que tuviese un poco de todas las connotaciones, que conste que miré la acepción antes de escribir el texto a ver si era la palabra adecuada. En un escrito de este estilo, tampoco me parece una palabra "tan" fuerte, realmente queremos que lo publiquen lo antes posible.
Pero si a alguien no le gusta, que corrija al gusto :) todo el mundo lo puede editar y proponer mejoras, yo sólo he hecho una versión preliminar a petición de un usuario.
Lo han actualizado
RedDwarf15 Junio 2010 - 9:57pm
Han actualizado el zip del código. Siguen sin estar las claves, pero ahora se indica que la licencia es GPLv3+.
Esto entiendo que impediría su integración en opensc. Aunque también entiendo que no pueden darle esa licencia después de haberse puesto a copiar código de opensc.
Licenciado como GPLv3+
jonsito16 Junio 2010 - 12:30pm
Esto entiendo que impediría su integración en opensc. Aunque también entiendo que no pueden darle esa licencia después de haberse puesto a copiar código de opensc.
Googleando un poco he visto que técnicamente sí se puede "promocionar" código LGPL a GPL.
Lo que no se puede hacer es al revés...
Pero en cualquier caso es un problema: el licenciar como GPL impide que la gente de OpenSC pueda integrar el DNIe en el mainstream (salvo como módulo independiente), sigue estando pendiente el tema de las claves... y tenemos el limbo legal de la semana de "ventana de exposición" sin licencia explicita. Con lo fácil que hubiera sido poner LGPL desde el principio.
!Quien fuera abogado con ganas de bronca...! :-)
si pueden cambiarle la licencia a GPLv3+ sin problemas
ferulo16 Junio 2010 - 12:29pm
La licencia del código LGPL 2.1 permite cambiar la licencia a GPLv3 sin ningún problema:
3. You may opt to apply the terms of the ordinary GNU General Public
License instead of this License to a given copy of the Library. To do
this, you must alter all the notices that refer to this License, so
that they refer to the ordinary GNU General Public License, version 2,
instead of to this License. (If a newer version than version 2 of the
ordinary GNU General Public License has appeared, then you can specify
that version instead if you wish.) Do not make any other change in
these notices.
Me corrijo
RedDwarf16 Junio 2010 - 12:09pm
La LGPL permite pasar a la GPL. Así que lo que han hecho es legal. Sólo que meter el código del DNIe en opensc convertiría a opensc en GPL... un opensc con soporte para DNIe (usando este driver) no podría usarse desde aplicaciones que no sean GPL.
En Mandriva ya funcionaba
gafe14 Junio 2010 - 3:39pm
En Mandriva, los colegas de blogdrake se han currado un rpm que tiene un apaño para que funcione con la versión de opensc que haya en el repositorio:
http://ftp.blogdrake.net/mandriva/2010.0/free/i586/dnie-0.1-1bdk2010.i58...
Aquí lo explica Alejandro Vargas:
http://blogdrake.net/pipermail/packagers_blogdrake.net/2010-June/001204....
Saludos...
He encontrado esto en meneame.net
jonsito12 Junio 2010 - 9:38pm
Dos enlaces:
http://www.meneame.net/story/incumple-policia-lgpl-dni-electronico
http://edulix.wordpress.com/2010/06/11/incumple-la-policia-la-lgpl-con-e...
No me atrevo a comentar los comentarios...
Quiero pensar que nadie de los que escriben en Kriptópolis está haciendo el imbécil...
Lo que se ha conseguido es un auténtico logro. Y todavía falta mucho camino por
recorrer. Comentarios y mensajes fuera de tono sobran, y más en un tema como éste
Gracias.
Aparte del problema de las licencias
Fernando Acero13 Junio 2010 - 12:00pm
Aparte del problema de las licencias del código publicado, que bien podrían haber sido libres para facilitar las cosas, está claro que esta publicación nos pone las cosas mucho más sencillas y representa un hito importante en el proyecto.
Me atrevo a decir que si se hubiera liberado antes, se habrían tenido menos problemas de soporte y con ello, una mayor aceptación y uso del dispositivo, pero eso es agua pasada y ahora se ha abierto otra etapa. Por lo tanto, no me queda más que agradecer que se haya tomado esta decisión.
Creo que a pesar de los problemas de las licencias, las claves y otras menudencias, que espero que se salven con el tiempo, se ha batido otro récord disponiendo de un código razonablemente funcional y solamente dos días después de la publicación. De nuevo, algo que debería hacer meditar a los responsables de este tipo de proyectos de la Administración y más en época de crisis.
Por mi parte he de decir que estoy teniendo algunos problemas para configurar y compilar bajo Mandriva 2010 tal como está el paquete, por lo que lo tengo que ver más despacio. De primeras es necesario actualizar autoconf y automake a las últimas versiones disponibles en el proyecto GNU y adaptar algunas cosas a las particularidades de esta distro, pero estoy en ello.
Respecto al problema con Firefox mi experiencia no es muy buena:
Problema con Firefox 3 y los certificados digitales.
Desgraciadamente, de poco sirve que el DNIe funcione si las aplicaciones que lo pueden usar no funcionan adecuadamente con él, así que habrá que tratar adecuadamente este problema que se lleva arrastrando desde hace mucho tiempo.
Un saludo, Fernando Acero
autotools
RedDwarf13 Junio 2010 - 12:43pm
No necesitas actualizar las autotools. Ese configure.ac se ha creado con autoscan, que ha añadido la linea "AC_PREREQ([2.65])" para jugar sobre seguro (dice que la versión mínima es la que el creador tiene instalada). Puedes borrarla sin problemas.
Por otro lado puedo confirmar que el paquete RPM de https://build.opensuse.org/package/files?package=opensc-dnie&project=hom... funciona sin cambios en Mandriva 2010.
De todas formas no tardará en estar integrado en opensc. No vale la pena darle muchas vueltas a hacerlo funcionar como módulo.
Mas sobre firefox
jonsito13 Junio 2010 - 5:13pm
Bueno, con el siguiente configure.ac
y modificando el libcard/Makefile.am la linea correspondiente para que quede así:
He conseguido que Firefox me presente la pantalla de "Su certificado es válido y está activo".
Pero cuando intentas desde esa página firmar un texto "hola mundillo", me dice que no ha podido firmar, y en la consola de errores, aparece el mensaje:
Con lo que hemos avanzado un pequeño pasito, pero le falta el casi,casi...
Por cierto, Fernando. Respecto de la integración, yo no las tengo todas conmigo: mientras no haya claves publicas y autorizadas, no creo que los de OpenSC estén por la labor de integrar. Aparte de eso, cuando se lleve a cabo la integración, me imagino que mezclarán el código del trusted channel con el que ellos tienen ya desarrollado... con lo que entiendo que la integración no será tan inmediata, y que tendremos módulo independiente durante al menos unos meses...
En cualquier caso coincido contigo: enhorabuena a todos, y ójala que esta experiencia haga reflexionar a más de uno
claves en archivo externo?
anv21 Junio 2010 - 3:09pm
Una alternativa sería poner la clave en un archivo externo (por ejemplo /etc/opensc/keys/dnie.key y hacer que la cargara cuando hace falta.
De esta forma se podría continuar con el desarrollo del software independientemente del problema de la clave. Cada distribución podría decidir si incluir o no la clave en su paquete y en caso de que no vaya incluida, se podría incluir un script capaz de descargar automáticamente uno de los paquetes distribuidos en la página oficial y extraer la clave. Ese programa se podría poner como proceso de post-instalación para que sea totalmente transparente para el usuario. La única salvedad sería que necesita estar conectado a internet para realizar el proceso pero el script quedaría disponible para ejecutarlo en otro momento de ser necesario.
De hecho, otros programas requieren una configuración adicional para poder usar el DNIe (como Firefox), y este script podría encargarse también del resto de las configuraciones.
No es la solución ideal pero sería funcional y resolvería todos los problemas de licencias.
Firma funcionando
ferulo14 Junio 2010 - 6:57pm
A mi este error que dices no me da:
av-dnie.cert.fnmt.es : potentially vulnerable to CVE-2009-3555
Yo ya he conseguido firmar en la página de validación del dnie. Lo que pasa es que algunas de las veces el firefox se queda pillado esperando la respuesta de /usr/bin/pinentry-gtk-2 con este backtrace:
#0 0x009ea416 in __kernel_vsyscall ()
#1 0x009a040b in read () from /lib/libpthread.so.0
#2 0x034147d6 in do_io_read () from /usr/lib/libopensc-dnie.so
#3 0x03414840 in _assuan_simple_read () from /usr/lib/libopensc-dnie.so
#4 0x0341565e in readline () from /usr/lib/libopensc-dnie.so
#5 0x03415706 in _assuan_read_line () from /usr/lib/libopensc-dnie.so
#6 0x03411e78 in _assuan_read_from_server () from /usr/lib/libopensc-dnie.so
#7 0x03412159 in assuan_transact () from /usr/lib/libopensc-dnie.so
#8 0x034112ba in ask_user_auth () at dialog.c:69
así que tiene pinta de que es un error de re-entrada. Voy a probar a enlazarlo con libassuan-pth.a en vez de con libassuan.a (que por cierto no sé por qué Fedora 13 no incluye la versión dinámica y encima /usr/bin/libassuan-config --libs devuelve -lassuan que no existe)
el problema esta en pinentry-gtk-2
ferulo14 Junio 2010 - 10:36pm
Mirando el backtrace del proceso pinentry-gtk-2 parece que es un problema de threads y el uso de los main loops de este helper que solo sale a relucir cuando la accesibilidad de GNOME está activada:
#0 0x00110416 in __kernel_vsyscall ()
#1 0x008abeeb in poll () from /lib/libc.so.6
#2 0x00a4664c in g_poll () from /lib/libglib-2.0.so.0
#3 0x00a39044 in ?? () from /lib/libglib-2.0.so.0
#4 0x00a39449 in g_main_context_iteration () from /lib/libglib-2.0.so.0
#5 0x044edd78 in link_main_iteration () from /usr/lib/libORBit-2.so.0
#6 0x044cfd74 in giop_recv_buffer_get () from /usr/lib/libORBit-2.so.0
#7 0x044d4e5c in ORBit_small_invoke_stub () from /usr/lib/libORBit-2.so.0
#8 0x044d5086 in ORBit_small_invoke_stub_n () from /usr/lib/libORBit-2.so.0
#9 0x044e1b38 in ORBit_c_stub_invoke () from /usr/lib/libORBit-2.so.0
#10 0x046d9865 in Accessibility_EventListener_notifyEvent () from /usr/lib/libspi.so.0
#11 0x00690ddc in ?? () from /usr/lib/gtk-2.0/modules/libatk-bridge.so
#12 0x00691568 in ?? () from /usr/lib/gtk-2.0/modules/libatk-bridge.so
#13 0x00b3dc70 in ?? () from /lib/libgobject-2.0.so.0
#14 0x00b3f65c in g_signal_emit_valist () from /lib/libgobject-2.0.so.0
#15 0x00b3faf7 in g_signal_emit () from /lib/libgobject-2.0.so.0
#16 0x002a320b in ?? () from /usr/lib/gtk-2.0/modules/libgail.so
#17 0x00b3691f in g_cclosure_marshal_VOID__UINT_POINTER () from /lib/libgobject-2.0.so.0
#18 0x00b296e3 in g_closure_invoke () from /lib/libgobject-2.0.so.0
#19 0x00b3e255 in ?? () from /lib/libgobject-2.0.so.0
#20 0x00b3f65c in g_signal_emit_valist () from /lib/libgobject-2.0.so.0
#21 0x00b3f92d in g_signal_emit_by_name () from /lib/libgobject-2.0.so.0
#22 0x0029afe4 in ?? () from /usr/lib/gtk-2.0/modules/libgail.so
#23 0x00b3dc70 in ?? () from /lib/libgobject-2.0.so.0
#24 0x00b3f65c in g_signal_emit_valist () from /lib/libgobject-2.0.so.0
#25 0x00b3faf7 in g_signal_emit () from /lib/libgobject-2.0.so.0
#26 0x03f53612 in gtk_widget_show () from /usr/lib/libgtk-x11-2.0.so.0
#27 0x03f533a2 in gtk_widget_show_all () from /usr/lib/libgtk-x11-2.0.so.0
#28 0x0804d1cc in create_window (pe=0x805c8a0) at pinentry-gtk-2.c:498
#29 gtk_cmd_handler (pe=0x805c8a0) at pinentry-gtk-2.c:513
#30 0x08053c92 in cmd_confirm (ctx=0xb7731004, line=0xb773103b "") at pinentry.c:927
#31 0x080566a9 in dispatch_command (ctx=0xb7731004) at assuan-handler.c:435
#32 process_request (ctx=0xb7731004) at assuan-handler.c:458
#33 0x08056a77 in assuan_process (ctx=0xb7731004) at assuan-handler.c:526
#34 0x080536a7 in pinentry_loop () at pinentry.c:1089
#35 0x0804de2c in main (argc=1, argv=0xbf92ded4) at pinentry-gtk-2.c:571
pinentry-gtk-2?
anv15 Junio 2010 - 11:00am
Yo opino que el pedido de pin no debería hacerse directametne a pinentry-gtk-2 sino mediante dbus y que lo resuelva quien corresponda, tal como lo hace bluetooth.
En realidad, yo diría que el pedido de pin debería ser resuelto por Opensc y no por el driver de la tarjeta. Opensc, por su parte, debería usar dbus. Habría que echar una mirada a los fuentes a ver cómo lo hacen para el bluetooth (ventajas del software libre). No me comprometo a mirarlo yo porque no tengo mucho tiempo.
pinentry-gtk-2 solo se utiliza para confirmar
ferulo15 Junio 2010 - 3:04pm
Si nos fijamos en los fuentes de dialog.c, pinetry solo se utliza para confirmar la firma. Del diálogo de intruducción de pin se encarga opensc directamente. No sé, a mi particularmente me parece excesivo meter la dependencia de libassuan solo para sacar un diálogo de confirmación. Miraré el API de opensc para ver si se puede hacer directamente ahí.
opensc usa tambien gpinentry
jonsito15 Junio 2010 - 12:36pm
Bueno, para ser más exactos: opensc tiene el Mozilla-signer-plugin, y si miras los fuentes,
verás que incluye un dialog.c (muy) sospechosamente parecido al dialog.c que ofrece la DGP
(¿He oído LGPL :-).
Como podréis ver comparando los fuentes, el del dni es una versión simplificada (quizás derivada
de una versión antigua) del de OpenSC. No conozco del todo el API, pero me da que en las pequeñas
diferencias de manejo de la biblioteca libassuan -en concreto, la llamada a assuan_transact()-
pueda estar la clave de los problemas
A estudiar... (En serio, esto envicia)
Funciona todo: autenticación y firmado
RedDwarf14 Junio 2010 - 6:54pm
Pues no sé que problema tendréis. Pero ahora que ya tengo un nuevo PIN he podido probarlo y al usar https://av-dnie.cert.fnmt.es/compruebacert/compruebacert con Firefox funciona tanto la autenticación como el firmado.
openSUSE 11.2 x86-64
Firefox 3.6.3
NSS 3.12.6
XUL 1.9.2.3
openSSL 0.9.8k
OpenSC 0.11.9
glib 2.22.4
assuan 1.0.5
zlib 1.2.3
pcsc-lite 1.5.5
Lector: "058f:9520 Alcor Micro Corp. EMV Certified Smart Card Reader" (de los que daba Tractis: plano, negro y con logo de Jazztel)
Si, la firma también funciona
metalpain18 Junio 2010 - 1:03am
Efectivamente, la firma también funciona. Mi problema era que AppArmor no permitía a firefox acceder a pin-entry. Ya lo he solucionado. Por cierto, tal y como alguien ha comentado en este foro, pin-entry no se utiliza para pedir el pin, si no tendría el mismo problema para autenticar, y no lo tenía.
Amarillismo
gossip12 Junio 2010 - 10:36pm
El amarillismo vende mas que la critica constructiva, que le vamos a hacer...
La firma también funciona
metalpain12 Junio 2010 - 4:41pm
Hola,
he conseguido que también funcione la firma digital, en OpenOffice. El problema era efectivamente que la librería no enlazaba con libassuan. es suficiente con añadir esta línea al configure.ac:
AM_PATH_LIBASSUAN
volver a compilar, y listo.
En el firefox sigo sin poder firmar, pero aparenta problema del navegador y no del módulo.
Gracias a todos!! Por fin puedo usar mi DNIe en Ubuntu Lucid. Ahora estaría bien que liberasen las claves y el paquete se pudiese distribuir libremente o, mejor aún, integrarlo en OpenSC. Todo se andará.
Saludos
Vreixo
Correcto
jonsito12 Junio 2010 - 7:06pm
He probado retocar el configure.ac con los cambios que habéis comentado
- Cambiar PKG_CHECK_MODULES(GLIB,glib) por:PKG_CHECK_MODULES(GLIB,glib-2.0)
- Incluir AM_PATH_LIBASSUAN
Y recompilar.
Resultado: ahora firefox ya no se cuelga ni se cierra, y llega hasta preguntarme si quiero firmar un texto... pero tras darle que sí, me aparece la fatídica ventana:
No me ha dado tiempo a probar la firma con otras aplicaciones, pero vamos, que si decís que funciona en OpenOffice la cosa pinta a error de Firefox :-(
Saludos y gracias por el report. Voy a mandar un emilio a la gente de OpenSC para confirmarles que la cosa funciona y que estamos pendientes del placet para que se puedan publicar las claves
No se como ha quedado todo
anv9 Agosto 2010 - 11:14am
No se como ha quedado todo este asunto. Y no se si alguien leerá este hilo todavía, pero recientemente he estado investigando esto y he llegado exactamente hasta este mismo lugar.
¿Hay algún lugar en que se esté discutiendo esto?
Funciona!!!
metalpain12 Junio 2010 - 4:24pm
Hola,
he probado a compilar e instalar el paquete de jonsito, y funciona perfectamente. Por cierto, a mi me funciona en firefox sin ningún problema!!
Lo único que no me funciona es la funcionalidad de firma, en el firefox me dice que el navegador no puede generar una firma válida, y en open office me lanza el error:
/usr/lib/openoffice/program/soffice.bin: symbol lookup error: /usr/lib/libopensc-dnie.so: undefined symbol: assuan_pipe_connect
Puede que haga falta lincar la librería a libassuan, no?
Finalmente, notar que el paquete compila perfectamente en Ubuntu 10.04, sólo hai que cambiar el configure.ac, donde dice:
PKG_CHECK_MODULES(GLIB,glib)
por
PKG_CHECK_MODULES(GLIB,glib-2.0)
Y por cierto, es necesario tener instalado libopenct1-dev, a pesar de que el configure no avisa de ello (igual estaría bien modificar eso).
Saludos
Vreixo
Lo hise!!
jonsito12 Junio 2010 - 2:54pm
He aquí la criatura:
http://www.megaupload.com/?d=CCFD1BG3
Pero ojo, antes del "make install" hay que tener en cuenta que he incluído un fichero de claves que NO ES VALIDO. Lo único válido son los dos certificados, que como ya han sido publicados en varios sitios, creo que con darlos no me meto en problemas legales...
Necesitaréis opensc-devel, glib-devel, assuan-devel, pcsclite-devel, ltdl-devel... y no sé si me dejo algun paquete más
Un triste comentario: el código (con las claves correctas :-) funciona sin problemas desde línea de comandos... pero al hacer la prueba con la página web del DNIe ("validar certificados"), me pide el pin, detecta el certificado sin problemas.... y acto seguido, Firefox se estrella y cierra miserablemente.
Desgraciadamente, esta vez el problema no es del código del DNI, sino de Firefox. Cada vez le tengo más manía a ese "navegador"
Creo que es el momento de hablar con la oficina técnica y pedir permiso oficial para publicar las claves.
Entretanto, hay que generar rpms, debs, preparar docs, autoinstalaciones... un curro de "la leshe", vamos
A disfrutar
Juan Antonio
Nuevas pruebas
metalpain11 Junio 2010 - 11:22pm
Hola otra vez,
Joer, que fácil era lo de las claves, ahora si que no entiendo nada... ¿por que no las publican? Si cualquiera las puede obtener fácilmente...
En fin, meto las claves y vuelvo a compilar. En el firefox, el mismo problema de antes, pero ahora puedo jugar algo:
$ pkcs11-tool --list-objects --login
me lanza un montón de errores (puede que sean normales)...
Luego me pide el PIN, y tras introducirlo me lista las claves, etc
Ahora quería probar a firmar algo con el pkcs11-tool, que parece ser la única app que me funciona, pero no se muy bien como hacerlo. ¿Alguien lo sabe? Tiene una opción de firma (-s), pero ni idea de como funciona. Tendré que documentarme algo más.
Saludos
Vreixo
A mi me compila
metalpain11 Junio 2010 - 4:35pm
Hola,
Yo si consigo compilar el dialog.c. Lo que he hecho ha sido descargar las fuentes del paquete opensc de ubuntu (es la distro que utilizo), y copiar sobre estas las fuentes del DNIe. Sólo he tenido tocar ligeramente el configure.ac original para que incluya el directorio libcard que viene con las fuentes del DNIe, y cablear los includes de la libreria glib (jonsito: ¿podría ser este el problema que tienes? fíjate si te aparece un missing header glib.h o similar en los errores). También he tenido que tocar el
#define MODULE_VERSION "0.11.8"
de base_card.h para que coincida con la version de opensc y me cargue la librería. El único problema que tengo es que al no tener las claves pues no me funciona, pero compilar, compila...
Saludos
Vreixo
Re: A mi me compila
jonsito11 Junio 2010 - 8:48pm
Aparentemente el problema se debe a que estoy usando un configure.in tan mínimo... que no reconoce los paths de instalación de las diversas librerías. Fedora 13 ofrece glib-1.2 y glib-2.0, con lo que voy a probar hasta dar con la configuración correcta
En cuanto a compilarlo integrado en opensc... a mí me parece más conveniente mantener un desarrollo separado. Si no, habría que meterse a personalizar los .specs del src.rpm estandard... y mientras la gente de OpenSC no se decida, creo que es mejor no mezclar dos códigos distintos.
Si no me equivoco, ubuntu usa OpenSC-0.11.9. Fedora usa 0.11.13: más razones para no mezclar... de hecho, habría que sacar todo el código OpenSC posible del fuente de la DGP, para no ir cargando con "includes" históricos ( en su caso cambiar #include "../xx" por #include <opensc/xx> )
En cuanto al MODULE_VERSION, creo que lo mejor es utilizar el truco que comento en el wrapper para que sea independiente de versión.
Respecto a las claves... !joer, que en KP se han publicado pistas más que suficientes para obtenerlas!.. por cierto, si te ha compilado, cuando lo intentes usar te tienen que salir unos preciosos "Symbol Not found" al intentar cargar la librería dinámica creada...
Joer, como curra la gente :-) habrá que ir pensando en pedir oficialmente a la DGP que publique las claves (o que le permita a la gente hacerlas públicas)
Admin: ¿Hace una porra-concurso entre los usuarios de KP para ver quién termina primero el desarrollo de un .tar.gz compilable e instalable? :-)