OpenSC-0.12.0 ¿El principio del fin del dnie en Linux?
El equipo de OpenSC está haciendo las pruebas finales a OpenSC-0.12.0.
Rebuscando en el ChangeLog me encuentro estas perlas:
* New card driver: Italian eID (CNS) by Emanuele Pucciarelli.
* New card driver: Portuguese eID by João Poupino.
Esto quiere decir que nuestros amigos portugueses ya han resuelto sus problemas de licencia y de versión propietara, Y que el DNI Italiano -que es clavado al español- con su "secure channel", sus claves privadas y tal y tal ya está integrado plenamente en OpenSC...
Pero siguiendo con el ChangeLog me encuentro con el desastre:
* Massive changes to libopensc. This library is now internal, only
used by opensc-pkcs11.so and command line tools. Header files are
no longer installed, library should not be used by other applications.
Please use generic PKCS#11 interface instead
Esto quiere decir que si bien se sigue permitiendo la carga dinámica de módulos, ya no se exporta el API a éstos, lo que en la práctica implica que no se pueden hacer callbacks del módulo al API....
En cristiano: el módulo opensc-dnie no se puede compilar "tal cual" con la nueva versión de OpenSC
Estoy intentando insertar el módulo del dnie dentro del código fuente de opensc, de manera que se pueda compilar "como un todo", generando a la vez el modulo y el opensc, pero falla por todos los lados.
(Por cierto, se recuerda que esto de arriba es ilegal: la DGP ha publicado el código como GPL, y mezclandolo con OpenSC -que es LGPL- estamos haciendo trizas la licencia)
Y para terminar de rematar la faena, el API tambien ha cambiado: las funciones que desde OpenSC se invocan en los módulos son distintas, con lo que hay que hacer de detective y ver cómo se pueden codificar los cambios del API en el módulo del dni
Y todo esto sin tener en cuenta el conflicto de licencias LGPL/GPL, y que todavía la DGP no ha liberado las claves privadas del canal seguro...
Entre tanto los italianos, no solo han liberado su código, sino que además han colaborado codo con codo con OpenSC para integrar todas las funcionalidades extras en el mainstream de OpenSC. Todo el desarrollo del Secure Channel y del almacenamiento comprimido de datos (características comunes con el dnie) es obra suya... y debido a la licencia GPL no podemos aprovechar tampoco su trabajo para integrar el dnie
Y para más recochineo, existe una página web oficial creada hace varios meses, donde se supone que se iba a desarrollar el módulo libre para OpenSC-dnie...
País.
En fin, sigo mirando a ver si se puede parchear la cosa... pero pinta muy negro.
- Conecta o crea cuenta para participar
- 9276 lecturas
Twitter
De ser así
es un gran palo y alguien con la responsabilidad suficiente debiera meditar sobre ello, porque es evidente que las cosas no se están haciendo bien.
Es de locos...
- La mitad de las estructuras han cambiado
- Las macros de log y depuración han cambiado
- Las rutinas de LibAssuan y PinEntry son incompatibles con la versión obsoleta que viene en los fuentes de la DGP
- Hay que revisar todo el código para evitar callbacks del modulo a la biblioteca
He conseguido integrar los fuentes del modulo con los de opensc,
de manera que se compila todo a la vez, pero hay errores en casi todos los ficheros,
hay que cambiar includes, campos en las estructuras, mensajes de logs...
Incluso aunque consiga compilar ni siquiera hay seguridad de que la cosa pueda ejecutar.
Esto es como los tiempos en que para compilar el PHP hacía falta tener los fuentes del
apache, y recompilar a cada cambio... pero en peor
Lo dicho: una auténtica pesadilla. Y lo peor es que con la licencia GPL ni siquiera podemos
pedir a la gente de OpenSC que nos ayuden con la integración. Y luego está el tema de las
claves...
En fin, si alguien más se anima... pues podemos empezar a usar el sistema de mensajería de KP :-)
Actualización 07/09/10 23:38
Finalmente he conseguido compilar e instalar, a base de modificar prácticamente todos los ficheros, especialmente el dialog.c y ( eliminando la internacionalización y dependencias con glib)...
Pero no funciona: han cambiado (entre otras muchas cosas) todo el modelo de logging y reporte de errores, y aparece el fatidico error:
symbol lookup error: /usr/lib/libopensc-dnie.so: undefined symbol: sc_error
(Que efectivamente: no existe en la 0.12.0 )
He reorganizado todo el fuente: eliminados includes copiados del opensc original, agrupados todos los fuentes en un único subdirectorio, añadido el fichero de claves... las modificaciones al OpenSC original se reducen a modificar el configure.ac y el src/libopensc/Makefile.am para indicar que se debe gestionar el directorio src/libopensc/dnie. No ha quedado un fichero sano.
Y claro: no funciona. No podía ser tan sencillo... Se me ocurren demasiadas interjecciones no publicables
Es evidente que la política de OpenSC al eliminar el paquete "opensc-devel" es la de limitar al máximo la posibilidad de módulos propietarios. La publicación como GPL del modulo del dnie,
junto con la necesidad de compilar "todo en uno" y luego distribuír por separado hace realmente
difícil un mantenimiento en las condiciones actuales
Y el ejemplo portugués liberando el código, y el italiano colaborando con el proyecto da una idea muy clara de las muchas cosas que en España se han hecho rematadamente mal
Me voy a dormir.
Gegen die Dummheit kämpfen selbst die Götter vergebens - Schiller
Nada, no hay manera
Despues de corregir el error de ayer, sigue sin funcionar.
No hace más que devolver "Unsupported card" al intentar abrir el secure channel ( si, he puesto el fichero de claves correcto )
Y encima, creo que me he cargado el DNIe: ya ni funciona en otro equipo con la versión anterior.
Me rindo. Si alguien quiere que le pase los parches, que me mande un mensaje.
Gegen die Dummheit kämpfen selbst die Götter vergebens - Schiller
Creo que una buena medida seria...
Hola,
Yo finalmente he desistido. Lo que hice en su momento fue sacarme un certificado digital con el DNIe y es lo que uso. Para que funcione el DNIe en las últimas versiones de Ubuntu (es el que uso) hay que hacer varias chapuzas que son un coñazo.
Creo que una buena medida sería hacer saber a esos impresentables lo que pensamos de sus chapuzas enviando correos a oficinatecnica@dnielectronico.es y/o escribir algún mensaje al respecto en el foro de Foros de discusión: Morfeo-Forge
Me quejo porque puedo...
Otro que ha desistido
Compilé en su momento el módulo que podía cargar otros módulos, luego probé con los fuentes pero faltaban las claves, probé con las claves porque aparecía como obtenerlas en cierto artículo y no me acabó de funcionar del todo y ahora otro cambio en opensc.
Diría que es culpa de opensc por andar jodiendo con el api, aunque reconozco que tienen motivo para haberlo hecho y debo darles la razón: evitar módulos propietarios, pero deberían haberlo hecho antes.
Por otra parte, que la oficina técnica aún no haya liberado las claves que ya se conocen, que no se hayan molestado en hacer ninguna gestión para habilitar todos estos procedimientos como legales y que no se hayan molestado en decir si están trabajando en una nueva versión me parece una chapuza y mal hacer por su parte.
Conclusión: El DNIe es un proyecto que ha nacido muerto, en linux certificado de la fnmt, acabas antes sin quemarte la cabeza.
How to go forward
Hello.
I've been following the thread via Google translate (not very effective, but at least I get the idea of what's going on)
Some thoughts about DNIe and OpenSC:
- work with OpenSC people on opensc-devel. We want to be able to support DNIe in 0.12.0 but the progress of OpenSC must not be hindered by the choices done by DNIe developers. But if there's surely something that can be done, but the community needs to know about what's going on, to support your activities.
- create a repository that tracks OpenSC 0.12.0 + DNIe. Create a github.com project, or fork the official SVN mirror of OpenSC on github, so that building the DNIe version can be closely tracked with the developments of the original OpenSC. I don't know how self-contained the DNIe code is but it would be nice to have a single and simple patch for OpenSC to build DNIe
- continue to work on OpenSC + DNIe integration, no matter what is the "official GPL status". The license issue is still not 100% clear and settled, but that requires actions and communication that is not yet done. I hope they will come to their senses and not try to knowingly work against the open source community.
@martinpaljak.net / Setec Astronomy
Glad to meet you, martin
I'll resume what i've done with dnie and OpenSC-0.12.x
- Got official DNIe sources from DGP site
- Download latest daily svn snapshot for OpenSC 0.12
- Created a directory src/libopensc/dnie
- Patch dnie sources to get it compile and install under opensc tree
(the patch is a single diff file. Only two one-line patches are needed to opensc tree,
to tell "make" that dnie directory exists and needs to be compiled)
- "Make install" creates two separate libs: standard libopensc.so, and libopensc-dnie.so. I've made
separate files because license concerns
- I'm sending you a patch file. AFAIK you already know how to extract private keys... :-)
Current state is just compile and installs, but doesn't work. Code needs a deep revision, update version changes, see how to reuse italian secure channel eID routines, and so...
I'm also sending a copy of this post to opensc-devel.
Cheers
Juan Antonio
Gegen die Dummheit kämpfen selbst die Götter vergebens - Schiller
For review purposes, the diff
For review purposes, the diff between original code as released by DNIe vs the changes you made for 0.12.0 could also be useful.
Does the original code work with 0.11.0? If that's the case, there's bigger hopes that the 0.11->0.12 transition is doable and there's light at the end of the tunnel. Changes between 0.11 and 0.12 are big (in terms of LOC changes) but actually pretty trivial and logical. It's just annoying to do.
A good idea would be to get the code into the compile-build-package cycle of OpenSC, so that also both Windows and Mac installers could be created and tested by those who want and can. I don't say that OpenSC will distribute such packages, but as the build process is pretty trivial, those who want can do that, and also distribute the packages on their own risk.
Merging the code and distributing it under a single package can be questionable but as long as it is all open source software, LGPL or GPL, I think it is legally OK (and personally I don't care) if it exists in a single public source repository (git) for people to fetch and build binaries from. Merging it into OpenSC is a different story though.
@martinpaljak.net / Setec Astronomy
1,2,3 check-check
Hello,
I merged the patch Jonsito sent to me and created a dnie branch on the official github mirror of the OpenSC SVN repository:
http://github.com/martinpaljak/OpenSC/tree/dnie
git clone git://github.com/martinpaljak/OpenSC.git -b dnie
Then I compared the changed files against the src.zip that can be downloaded from the official dnie page. The changes were mostly trivial (sc_error gone, sc_debug changes) except for some object der handling, that was unused in OpenSC but used by the DNIe code. The relevant change in OpenSC is r4008, it should not affect the overall behavior of DNIe code:
http://www.opensc-project.org/opensc/changeset/4008
Next to be removed was the display code that was used to trigger user consent from applications. That's not portable and has a relevant ticket on OpenSC trac. It is not critical to the functioning of the driver anyway.
Next was the change to link the card driver directly into OpenSC without the stupid module loading. That revealed that there are two missing functions:
int card_create_cert_file( sc_card_t *card, sc_path_t *path, size_t size )
int get_ckaid_from_certificate( sc_card_t *card, const u8 *data, const size_t data_size, sc_pkcs15_id_t *card_ckaid )
Also, the der object mapping code needed to be changed because the sc_der_clear was gone with r4008
I know nothing about the keys that are needed to use the card, nor have I one DNIe.
The most important thing to know: did the driver work for OpenSC 0.11.X ? If yes, this should also work with 0.12.0, if the missing functions are figured out or re-implemented o removed if not needed.
If not, it is not worth it trying to figure out what's wrong.
People with coding capabilities and DNIe cards, get invovled on opensc-devel, try the code, see where it crashes or fails (by enabling debugging and sending opensc-debug.log) and lets see if this can be moved further.
@martinpaljak.net / Setec Astronomy
I have just read briefly your comment
I have just read briefly your comment, I do not know if you know some peculiarities about the DNIe:
* They have two security areas: One only accessible from machines at the police station and one other accessible by the citizen at any point. The machines at the police station are able to generate new certificates, reset the password and read your photo and digital signature, they have a special driver and a special ciphered tunnel. You as a citizen can not do these actions, so you can not create a new certificate or export it (for "security reasons").
* If you want to change the password of your card, you must establish a secure channel between the card and the police server (you send the password to the police and they record it in the card).
Besides, the keys to establish the ciphered channel to perform sign operations and other stuff accessible by the normal citizen are not in these drivers because they are "secret", you can obtain them from an old binary but they are "secret" and protected by the law. From a legal point of view you can not publish them thats the reason because the police did not publish the drivers "complete", because of the law for "official secrets protection" and several other stupid laws applicable in this case.
I suppose that now you can begin to image all the problems that we are having.
We know that the keys are secret, but we also know that the police will not act against us though.