DNI electrónico

Ayer fui a hacerme el DNI electrónico (DNIe para los amigos, si es que tiene alguno). Aproveché que tengo un cambio de domicilio pendiente para ir a renovármelo, pues en este caso la renovación sale gratis. Pedí cita previa en la web correspondiente, de manera que fue llegar y besar el santo. O casi, porque las fotos que tenía no valían (me dijeron que salían mis ojos muy oscuros) y tuve que hacerme unas fotos en el chino de al lado (menudo negocio debe tener el chino, desde luego). Por lo demás, el trámite fue rápido, no tuve que esperar y, a los pocos minutos (principalmente, los minutos que lleva generar las claves en la tarjeta), tenía mi nuevo DNIe en la mano.

DNI electronico

A continuación me dirigí al PAD, un terminal que tienen en las oficinas de expedición, que nos permite acceder a los datos que hay en el DNI y cambiar el PIN (contraseña de acceso y de desbloqueo de la clave privada). Está bien pensado: el terminal cuenta con un lector de huellas dactilares y así, en caso de que se nos bloquee el PIN, podemos resetearlo en el terminal sin más que identificarnos con nuestra huella dactilar. El problema es que, tanto el terminal como el PAD virtual (un software que permite cambiar el PIN en nuestro ordenador personal) necesitan estar conectados a los servidores de la Policía para proceder, cosa que no me explico (siendo malpensados, podría servir para que la Policía guarde siempre una copia de seguridad del PIN).

En cualquier caso, una vez cambiado el PIN me volví a casa con el DNIe, dispuesto a probarlo en mi portátil con la Ubuntu 8.10. Mi portátil es por ahora un Dell D430, que tiene lector de tarjetas integrado, y además reconocido por Linux, así que en principio deberá funcionar.

Efectivamente, siguiendo las instrucciones que dan en esta página para Ubuntu Gutsy, el DNIe puede usarse desde Firefox para autenticarnos o firmar peticiones. En realidad, en el manual han omitido un paso que si no se hace, impide a Firefox acceder al DNIe (cuando intentamos cargar el módulo criptográfico nos dará error). El paso que han omitido es instalar el paquete pcscd (algo que haremos con el comando “aptitude install pcscd“).

Hecho esto, abrimos manualmente la página de configuración del navegador para DNIe (basta con abrir la URL “file:///usr/share/opensc-dnie/instal_dnie/instala_modulo.htm“), seguimos sus instrucciones y, si no da errores, ya podremos verificar el DNI en esta página, obteniendo el resultado esperado:

Verificacion DNIe OK

Esto es todo. Para detalles técnicos adicionales recomiendo leer otras fuentes que lo único que hacen es repetir el mismo procedimiento técnico que indica el portal oficial.

Ahora vamos a los inconvenientes:

En primer lugar, el DNIe tiene una funcionalidad muy limitada. Las claves generadas solo sirven para autenticar al usuario y firmar peticiones con el navegador. No permite, por ejemplo, firmar correo electrónico ya que la Policía decidió no incluir direcciones de correo electrónico del ciudadano en el dispositivo. Tampoco se permite cifrar información, es decir, las claves están ahí pero no se han definido para cifrar documentos.

Estas carencias son cubiertas por el certificado de la FNMT, por lo que recomiendo utilizarlo en su lugar.

Otra limitación es que, supuestamente, el DNI incluye en su interior versiones codificadas de la fotografía, la firma manuscrita  y la huella dactilar. Sin embargo ningún software permite extraer dicha información al usuario; solo se pueden visualizar utilizando los terminales PAD de la policía.

Por otro lado, no podemos negar que hay algunas deficiencias que generan desconfianza. La generación de claves ocurre (y solo puede ocurrir) en la oficina de expedición, teniendo una norma administrativa (y el uso de tarjetas que supuestamente solo pueden generar las claves privadas en su interior) como única garantía de que las claves no son copiadas por un tercero. Por otro lado, para cambiar la contraseña de acceso, es preciso usar un software que, como ya hemos indicado anteriormente, necesita conectarse al servidor de la Policía, sin que vea explicación para ello; o bien usar un PAD, ese dispositivo cerrado que se encuentra en las oficinas policiales y que presumiblemente también se encuentra conectado a sus servidores. Por tanto, no hay garantías tampoco de que la contraseña la conozca únicamente el usuario.

Pero existe una deficiencia más: el DNI electrónico solo se puede gestionar con el paquete opensc-dnie. Este paquete tiene bastante poco de open, porque ni la Policía ni sus posibles mantenedores (todo apunta a que son la misma gente que los responsables de CERES en la FNMT) suministran el código fuente del mismo. Esto obviamente genera desconfianza, pues nada nos asegura que no tenga algún tipo de manipulación para enviar información privada a un servidor gubernamental, por ejemplo. Y esto al margen de un posible incumplimiento de licencia, si el código estuviera basado en el paquete opensc, que se distribuye con licencia LGPL.

Por todas estas razones, creo que por ahora seguiré usando el certificado de la FNMT, que sirve para casi toda la administración electrónica española y además otorga al usuario las mismas garantías que cualquier otra infraestructura de clave pública “en condiciones“. El DNIe me puede servir para una emergencia, como puede ser generar un nuevo certificado de usuario FNMT desde casa, sin necesidad de acreditar mi identidad presencialmente.

12 Responses to “DNI electrónico” »»

  1. Comment by agutierr | 11/28/08 at 9:51 am

    Muy interesante tu nota!!

    Saludos,

    Antonio.

  2. Comment by Falaz | 07/01/09 at 1:12 pm

    LIEMA. No deberías confundir “funcionalidad limitada” o “deficiencia” con “especificación”. Según la DPC que han publicado la poli, la finalidad de los certificados DNIe (el KeyUsage) es la “digital signatura” y el “ContentCommitment”. No están previstos para otra cosa como el cifrado, aunque el chip podría hacerlo. Las razones mejor se las preguntas a ellos (posiblemente por no complicar la PKI con millones de claves que tendrían que mantener, revocar, validar,..). ¿Te imaginas a millones de usuarios perdiendo sus claves privadas y exigiendo a la Administración que mantenga dichas claves para garantizar que sus documentos cifrados son recuperables?. No. Definitivamente no. Para eso están otras AC con menos “volumen de carga”. Si quieres cifrar, búscate un certificado de cifra… y mantén tú la seguridad de tu clave. CERES no te va a descifrar tus ficheros si la pierdes ¿verdad?. ¡Apañados iríamos!.

    Los datos biométricos tienen una protección tan elevada que los maderos no dejan que se extraigan en equipos que no estén conectados a su red. Eso no es malo y no es una limitación. Es bueno que sea así porque si no se les echan encima los sabuesos de la APD. ¿Para qué quieres tú la huella de tus amiguetes o de tus clientes?.

    La generación de claves no se genera en la oficina de expedición… bueno, sí, pero no. Me explico. En un chip como el ST19WL34, las parejas de claves se generan *dentro_de_chip*. No interviene *nadie* en dicha generación. El sistema operativo se las apaña para calcular los primos necesarios y los parámetros privados se quedan dentro, en ficheros inaccesibles desde fuera. No hace falta una norma administrativa para eso. Lo dice el esquema EAL5+.

    En cuanto a lo que hace el opensc-dnie, deberias echar un vistazo a los términos de la licencia LGPL, y digo un vistazo en profundidad, porque está claro que sólo has leído la parte que nos interesa a todos ;-)

    Lo que pasa es que en cuanto vemos un madero o un pico por medio se nos encienden todas las alarmas… No necesitan tu PIN para nada. ¿para qué van a querer el PIN de tu DNIe si no tienen la tarjeta?. Vamos, tronk, no seas ciberparanoico. Hay ciertas cosas que ni siquiera ellos pueden hacer (aunque se echen el moco y digan que sí).

    No comentaré tu último párrafo. Con él me has dejao sin palabras :-)

  3. Comment by Juanjo | 07/02/09 at 4:54 am

    Falaz, lo primero es que no confundo nada. Opino, simplemente. Para mí es una funcionalidad limitada el no poder cifrar archivos o firmar e-mails. El hecho de permitir cifrar archivos no debería implicar la necesidad de que las autoridades tengan copias de las claves privadas, a menos que el funcionario de turno así lo creyera erróneamente (bueno, tampoco sería tan raro :-) ).

    En relación con esto, ¿qué razón me das para que el cambio de PIN tenga que hacerse, precisamente, en un servidor conectado con la red policial (PAD) o por internet con el PAD virtual? No quiero pensar que sea precisamente que pretenden guardar los pin por si acaso el usuario lo “olvida”. O se deja el carnet olvidado en la comisaría, vaya.

    Admito que tienes buenos argumentos para justificar que no sean accesibles los datos biométricos, si bien a mí me vendría fenomenal que estuvieran copiados, cifrados con tu clave privada, en la propia tarjeta, de forma que con mi PIN pudiese acceder a la foto (por ejemplo) y sacar copias para, no sé, para cuando las necesite. O de mi firma manuscrita para pegarla en un documento… qué se yo.

    Por supuesto, sé perfectamente que las claves se generan en el interior del chip. Pero como se hace de forma tan cerrada, permíteme sospechar en un cambio del hardware a propósito, por ejemplo. A ver, supongo que nuestra policía no maneja tanto como el FBI pero … muéstrenme las fuentes y me quedaré más tranquilo :-D

    Respecto a la LGPL, la conozco perfectamente. La cosa es que permite integrar software privativo con libre. Pero, ¿qué pasa si la DGP o la FNMT modifican una biblioteca libre de opensc para convertirla en la opensc-dnie y no distribuyen la fuente de la modificación? Estaríamos ante un claro incumplimiento de la licencia. No sabemos lo que han hecho realmente pero un examen de símbolos debería sacarnos de duda o aumentar la sospecha (me temo que esto último… :-( ).

    No soy paranoico con la policía ni la guardia civil. Soy simplemente desconfiado con un estado que en términos de seguridad informática no siempre se ha dejado aconsejar bien (yo diría que casi nunca :-D ).

    No sé por qué te he dejado sin palabras en mi último párrafo. Si no me he explicado bien te lo cuento con otras palabras ;-)

  4. Comment by Falaz | 07/02/09 at 9:46 am

    Sí. Afortunadamente sólo es una opinión. Confundida, pero al fin y al cabo una simple opinión. Se me ocurreo que GPG presenta una funcionalidad limitada porque podría (no, mejor debería) incluir soporte para el almacenamiento de claves en un HSM que cumpla con FIPS 140-1 level 3. ¿A que no te suena bien?. Pues claro. ¡Es que está fuera del ámbito de aplicación!. Lo mismo pasa con eso que tú opinas; está fuera del ámbito de aplicación del DNIe servir como cifrador o depósito de claves distintas a las que tiene previstas.

    Lo del cambio de PIN mejor se lo preguntas a ellos. Seguro que hay una razón, y no es la que tú te crees porque el PIN sin el DNIe no sirve de nada (y al revés tampoco). Créeme, algo sé de smart cards y de algoritmos match-on-cardAdemás… ¡Ellos pueden falsificar (perdón, quise decir fabricar) los DNIe que quieran!¡Incluido el tuyo sin que te enteres! ¿Para qué querrían guardarse tu PIN?. Creo que no deberías ver “Public enemy” antes de ir a la cama :-)

    Si los datos biométricos fueran tan fácilmente accesibles como los datos personales, tu foto acabaría diseminada por Internet. Quizás eso no te importe, pero seguro que no te haría gracia que hicieran lo mismo con ti firma manuscrita o con tu huella dactilar. Créeme: los datos biométricos están mejor así. Es más, yo propondría una recolecta de firmas para que los quitaran del chip.

    No necesitas las fuentes del sistema operativo del DNIe para estar tranquilo. ¿Necesitas las fuentes del software que controla el movimiento de los alerones de un Airbus? ¿Por qué no se las pides al fabricante? ¿Estarás así más seguro cuando vueles en uno de esos bichos?. Cuando se las pidas puedes alegar que te va la vida en ello y que tienes derecho a blah, blah, blah,… ya te puedes imaginar la cara con que te van a mirar.

    Si tienes pruebas de que se ha modificado un software licenciado LGPL y no se han cumplido los requisitos previstos, debes denunciarlo. (www.fsf.org, http://www.opensc-project.org). Pero te puedes ahorrar el trabajo. Ya lo habrían hecho los de OpenSC.

    Tu último párrafo me deja sin palabras habida cuenta de tu preocupación por la seguridad. ¿Pretendes comparar una firma hecha en un dispositivo seguro de creación de firma con una firma CERES creada en la intimidad de tu dormitorio?. ¡Venga ya! Estás de coña, claro.

  5. Comment by ikki | 07/02/09 at 10:38 am

    He estado leyendo vuestra conversación, creo que lo que dice Falaz tiene mucha razón, sobre todo en decir que el DNIe es mucho más seguro que un certificado CERES otorgado por la FNMT. Mira Juanjo si mañana alguien entra en tu equipo, te lo roba etc, y tienes un certificado CERES será relativamente facil poder hacer uso de tu certificado personal. En cambio con el DNIe deben de disponer de tu DNIe y del PIN para poder hacer uso de tus certificados personales del DNIe. Tu que estan tan obsesionado con la seguridad y no te has dado cuenta en eso?.
    Un saludo.

  6. Comment by Juanjo | 07/02/09 at 5:51 pm

    Hola, lamento que confundas opinión con equivocación. Yo al menos respeto la tuya, y además te comento:

    1. El que la funcionalidad esté fuera del ámbito de la aplicación no es impedimento para que yo opine que el DNIe me sería más útil como ciudadano si permitiera firmar correos electrónicos o cifrar información. El certificado FNMT me lo permite y sí me es útil. Pues uso este último y punto.

    2. La razón sobre el cambio de PIN en red ya fue consultada. Como ocurre en este país habitualmente, nunca recibí respuesta. Previamente consulté a la FNMT sobre otros asuntos relacionados con su certificado y tampoco recibí respuesta. Por ahí dicen que si el certificado de la FNMT no está en los navegadores es por dejadez, y no me extrañaría.

    3. Hay alternativas basadas en software libre, y no en la “seguridad con la oscuridad” que pueden proporcionar la misma seguridad que supuestamente proporciona el software de seguridad cerrado que se está utilizando. Permíteme que desconfíe por la elección de este último.

    4. Las claves generadas “en la intimidad de mi dormitorio”, las hago en mi propio equipo, con un software completamente libre. Permiteme que confíe más en esta solución que en los equipos y software cerrados y oscuros que manejan en las oficinas de expedición y en la propia tarjeta.

    5. Sí, me preocupa la seguridad muchísimo. Pero ciertamente, si encima de todo lo anterior, añadimos la falta de funcionalidad, mi decisión está bastante clara ;-)

    6. Para ikki: si alguien entra en mi equipo y me lo roba, tendrá que robarme también la tarjeta criptográfica donde tengo mis claves confiables (es decir, todas menos la del DNIe :D ) y en todo caso, descifrar mi disco duro para luego no encontrarlas. Créeme :-) es mucho peor perder el DNIe y que acabe en manos de alguna persona con pocos escrúpulos y con acceso a las posibles bases de datos de PINes para desbloquear mi clave privada.

  7. Comment by Falaz | 07/07/09 at 7:58 am

    Sí, Juanjo. Son los trillados argumentos de siempre en los foros de los partidarios del software libre a ultranza y son los que yo defiendo… pero en el escenario adecuado; una cosa es liberar el fuente de un paquete ofimático y otra el de un producto cuya ingeniería ha costado “n” veces más. No se trata de generalizar la utopía. Mal que nos pese, las empresas protegen sus derechos e inversiones en base a un modelo de mercado que hasta ahora les ha funcionado. No vamos a cambiarlo diciéndoles que “la seguridad por ocultación ha demostrado ser inútil” o cosas por el estilo. Mientras la ley proteja los intereses asegurados “por ocultación” con la misma eficacia que los asegurados “por tecnología”, creeme, no hay nada que hacer. Tienen que cambiar todavía muchas cosas para que una empresa fabricante de chips para smart-cards decida liberar el fuente de sus sistemas operativos. ¡Tienen que proteger su inversión!. ¡El conocimiento libre no es rentable desde el punto de vista de las grandes compañías, mal que nos pese!. Poco a poco van apareciendo nuevos escenarios en los que se demuestra lo contrario: cuanto más conocimiento se comparta más nos beneficiamos todos (¡Incluso Microchoofff!), pero por ahora te repito el argumento de los alerones del Airbus; no pidas el fuente de sus programas de control; no te hacen falta para volar seguro.

  8. Comment by Juanjo | 07/08/09 at 6:33 pm

    Sí, Falaz, es una pena que muchas compañías sigan con el obsoleto modelo de negocio basado en la venta de licencias. Espero, y creo que es solo cuestión de tiempo (aunque aun quede bastante), que ese modelo cambiará definitivamente pronto.

    Mientras tanto, esperemos y sigamos informando a la gente. :-)

  9. Comment by Pedro | 08/11/09 at 7:38 pm

    Vemos que hay más gente que da razones de peso para un DNIe totalmente gestionable con software libre:

    http://barrapunto.com/~trinuxfree/journal/31328

    Pero claro, la seguridad (con la oscuridad) es lo primero ;-)

  10. Comment by fernajuf | 10/29/09 at 7:27 pm

    Solo una cosa:

    El DNIe sí que permite firmar correos electrónicos.

    Saludos.

  11. Comment by Juanjo | 10/29/09 at 7:33 pm

    fernajuf: el certificado del DNIe no se emite para su uso en firma de correo electrónico, con lo que formalmente no se permite firmar correo-e con él.

    Sin embargo, como la decisión sobre si se firma o no, corresponde al software de tu PC, que puede ser modificado, siempre se pueden hacer firmas con ese certificado aunque formalmente no sean válidas.

  12. Comment by carla | 09/24/11 at 9:26 pm

    Buena información , interesante y completa . Ya tienes una fan mas

Leave a Reply »»