Exportar e importar firmas digitales en GNU/Linux

Firma digital

Firma digital

Ando liado con trámites tributarios.

La firma digital es una de esas cosas de la tecnología que te hace preguntar: ¿cómo hemos podido vivir sin esto? Puede parecer una exageración, pero el hecho de poder hacer trámites de la Agencia Tributaria o de asuntos relacionados con tu ayuntamiento desde el PC de tu casa, no tiene precio. No tienes que pedir horas en tu trabajo, no haces colas, es muy rápido e indoloro. La pega que tiene es el soporte técnico. Tiene un soporte horrible. A pesar de haber cursado asignaturas en la carrera donde se ven los certificados, firmas y demás engendros digitales, tengo que reconocer que me cuesta un poco tanto “palabroto” técnico (X.509, PKCS12, PEM, etc). No quiero imaginar a mi madre haciendo esto.

El asunto es que ayer probé a usar mi firma digital y comprobé que estaba caducada (tenia que haberla renovado por la propia web meses antes de que caducara). Era necesario volver a solicitar una nueva. El proceso es sencillo:

  1. Entras en la web de CERES y solicitas un certificado de usuario (no sé como irá el tema de los DNIe)
  2. Te piden el NIF y te generan un código que tienes que guardar.
  3. Es necesario que te presentes con el DNI en la oficina más cercana que expida firmas digitales (hay un buscador que calcula la más cercana a tu dirección).
  4. Te presentas en la oficina, enseñas el código, el DNI y firmas el contrato de adhesión.
  5. Vuelves a tu casa, te conectas a la web de CERES y especificando tu DNI y el código previamente asignado, ¡voila! el certificado se instala en tu equipo.

El proceso anterior es la teoría. En la práctica hay una letra pequeña que cuando se lee ya es tarde. Cuando vuelves de firmar el contrato y pinchas en la opción de descarga, aparece un párrafo que dice: “El certificado se descargará en el navegador y PC con el que solicitó el certificado“. El gráfico “Uppss” aparece en mi cabeza: “PC el de siempre…, navegador web… Google Chrome Beta para GNU/Linux“. Por supuesto, Chrome todavía no está preparado para gestionar este tipo de certificados personales. La cuestión es que, aún sabiendas de que posiblemente no iba a funcionar, pulsé en “Descargar“. Ni el puntero del ratón se movió. Indagando un poco en cómo gestiona Chrome los certificados, me doy con una utilidad muy potente, certutil.

Resulta que Chrome guarda los certificados bajo la ruta ~/.pki/nssdb/ en varios ficheros que suelen ser bases de datos SQLite3.

Uno de los cometidos de certutil es mostrar los certificados que existen en esa base de datos. Para ser exacto, esta línea me mostró todos los certificados

certutil -L -d sql:~/.pki/nssdb 

Qué sorpresa me lleve cuando comprobé que la última línea correspondía con mi certificado personal. Resultó que cuando le di a descargar el certificado, Chrome lo guardo ahí.

Genial. Si el certificado está ahí, seguro que puedo exportarlo e importarlo en Firefox (que sí esta soportado). ¿Cómo?

Después de buscar un poco, encontré una opción para exportar certificados para LDAP que usaba la utilidad pk12util.

El nombre de esta utilidad viene del formato de documento, PKCS12, se trata simplemente de una forma de codificar un certificado digital que contiene tu clave pública y privada mediante una contraseña para que nadie te pueda usurpar. Era necesario por tanto establecer una contraseña y guardarla en un archivo (por ejemplo, /tmp/clave”). La sintaxis que usé para exportar mi certificado fue:

 pk12util -d sql:~/.pki/nssdb -n "<nombre-certificado-mostrado-por-certutil>" -o <nombre-fichero-salida>.p12  -w /tmp/clave -k /tmp/clave 

El mensaje de salida fue: pk12util: PKCS12 EXPORT SUCCESSFUL

Faltaba la prueba de fuego: ¿funcionará en Firefox?¿cargará por fin la Oficina Virtual?

Podéis imaginar que sí 🙂

Firefox, después de solicitarme la clave que especifiqué en “/tmp/clave”, importó sin problemas el certificado y la oficina virtual por fin entró.

No sé si este post servirá para alguien o no. Por lo menos dejó registró en la web por si algún día necesito recurrir a estos comandos (ya sabéis eso de volver a tropezar con la misma piedra).

He obviado algunos detalles sobre la importación y solicitud de firma digital. En la Web hay bastante información al respecto. No obstante, si teneis dudas, preguntad 🙂

ACTUALIZACIÓN:

La versión 10.0.648 (y posterior) de Chrome soporta ya la gestión de  certificados.

Translate to:English
MenefanteMenéame TwitterTwitter

Anuncios

Análisis y desarrollo de un driver para Xorg: EloTouch (I)

Análisis y desarrollo de driver para Elo Touch

Análisis y desarrollo de driver para Elo Touch

EloTouch es una empresa que se dedica a la fabricación de pantallas táctiles.

No tengo queja de su hardware. Sus controladores tienen interfaz serie y/o USB. Particularmente me gusta más el controlador USB debido a que existe un perfil HID que recoge este tipo de periférico y GNU/Linux tiene un driver HID que no funciona mal.

El caso es que recientemente he tenido que desarrollar un driver para una pantalla resistiva de EloTouch que funciona bajo GNU/Linux con Xorg.

La motivación viene de la necesidad de poder asociar un controlador touch a una pantalla (screen) determinada. De este modo podemos tener un escritorio extendido con dos monitores, cada uno de ellos con una interfaz táctil. Tanto los monitores como los controladores de touch están conectados a una misma CPU.

El fabricante tiene un driver (bastante tedioso de instalar) que no contempla esta posibilidad: asociar un controlador a un screen arbitrario.

Lo primero que se me vino a la mente fue buscar un driver GPL que cumpliera con este requisito.

Para “mi sorpresa” encontré en el repositorio de Xorg, los siguientes drivers:

La estructura de ambos es muy parecida y para mi asombro sí que implementan la funcionalidad que demandaba.

¿funcionarán con mi controlador?

No hubo suerte. Ni uno ni otro funcionaba a pesar de establecer la configuración tal y como describía la documentación asociada.

No queda más remedio que hacer mi propio driver.

Leer más de esta entrada

¿Por qué GNU/Linux no triunfa?

 

GNU/Linux

GNU/Linux Box

 

 

GNU/Linux lleva ya unos años conmigo. Empecé a usarlo en 1998 en código compartido con Windows. Para la entrada al nuevo milenio, mi disco duro sólo tenia una partición, la de GNU/Linux (ejecutaba sw de Windows via Wine o VmWare). Por aquella fecha había muchas expectativas de que GNU/Linux al ser gratis (para mucha gente Windows también lo era) y no “colgarse” iba a derrotar a Mr. Gates.

A día de hoy, el uso de GNU/Linux sigue siendo minoritario. Sólo los que estamos en el círculo de las TI lo usamos.

Es cierto que iniciativas como Ubuntu han ayudado a que muchos usuarios usen GNU/Linux (a pesar de que sigan usando Windows también).

En la administración pública, proyectos como la distribución Guadalinex y GuadalInfo (del cúal fui dinamizador) ayudan a que el usuario vaya abriendo su mente hacia GNU/Linux o por lo menos saber que existe alternativa.

Hay otros proyectos gráficos que mejoran la experiencia de usuario (incluso mejor que los S.O. propietarios) como Beryl o Compiz.

Sin embargo, a pesar de todos estos esfuerzos, GNU/Linux no triunfa.

Muchos usuarios avanzados de GNU/Linux han opinado ya sobre esto. Voy a hacer un análisis desde mi experiencia como usuario, profesor y desarrollador de aplicaciones para GNU/Linux.

  • Dispersión: hay demasiadas distribuciones de GNU/Linux, algunas sólo se diferencian por pequeños matices (Ej. Ubuntu vs Kubuntu).
  • Actualización del kernel: el kernel de GNU/Linux tiene un desarrollo muy activo, con cambios de revisión cada mes. Esto provoca confusión y crea dispersión. Es más, un usuario de GNU/Linux desktop no tiene por qué saber qué es el kernel.
  • Esclavos del .DOC: Ni Windows puede vivir sin Office, ni Office puede vivir sin Windows. Por desgracia el formato .doc de Microsoft Word se ha impuesto como estándar de facto. Es el formato de documento más usado e intercambiado por la red. OpenOffice soporta este formato de fichero, pero no al 100% (Ej: las fuentes de sistema no son las mismas). Esto provoca un rechazo del usuario a OpenOffice y por la “propiedad transitiva”, a GNU/Linux.
  • Incompatibilidad módulos/kernel: Los módulos kernel son el mecanismo que tiene el kernel monolítico de GNU/Linux para el soporte de drivers. Basta que cambie el nombre de la versión de kernel (Ojo! no las APIs del kernel) para que el kernel rechace el driver.
  • Disponer de Shell: La shell es sin duda la herramienta preferida por los usuarios avanzados de GNU/Linux. Sin embargo no es una ventaja para el usuario normal, y lo más importante, un usuario no tiene porqué usar la shell para hacer las tareas de su día a día. Ubuntu (junto a Gnome y KDE) ha ayudado mucho en esto, pero hay ocasiones en las que no queda más remedio que abrir una shell.

Después de analizar desde mi prisma el porqué, voy a enumerar las acciones que yo tomaría para llevar a GNU/Linux hacia la victoria.

  • Open Alliance/Foundation: es necesario que un grupo de empresas líderes creen un consorcio encargo de la definición de un estándar, parecido a POSIX pero orientado al usuario común y más genérico.
  • Congelación/separación del kernel y los drivers: el kernel va “demasiado” rápido. Actualmente el grueso de las actualizaciones al fuente consiste en añadir código para soportar nuevo hardware. Raramente se modifica el scheduler, el IPC, etc. Una nueva release de kernel debería ocurrir cada 3 o 4 años (como la mayoria de S.O.), por tanto en ese tiempo las APIs deberían quedar intactas. Los fabricantes desarrollarían sus drivers en base a una API en concreto según la versión.
  • Distribución “Root”: la organización citada anteriormente liberaría una distribución base con el kernel “congelado” y con un SDK para el desarrollo de drivers para fabricantes. Además puede agregar un kit de personalización de distribución para generar distribuciones corporativas con los paquetes de software que interesen (usando un análogo al AppleStore o Android Market).
  • Soporte a fabricantes: la principal línea de acción de dicha supuesta Open Alliance, sería dar soporte a los fabricantes para que éstos puedan poner su hardware a funcionar en GNU/Linux con los menores problemas posibles y con un time-to-market menor o igual que otros S.O.
  • De .DOC a .DOCX: parece que con la nueva versión de formato, DOCX, hay un rayo de luz para que la intercompatibilidad funcione. DOCX no es más que fichero comprimido XML juntos a los objetos incrustados que usa (como ODT de OpenOffice). Es necesario maximizar el uso de .DOCX (si se puede el .ODT mejor) y empezar a olvidar el .doc.
  • Linux Store: Existen muchas fuentes y respositorios de paquetes/aplicaciones para GNU/Linux. Cualquiera puede crear una aplicación GPL y ponerla a disposición de todo el mundo. Eso da lugar a aplicaciones de muy diversa calidad. La supuesta Open Alliance se encargaría de dar el visto bueno a aquellas aplicaciones que cumplan unos requisitos de calidad acorde una especificación previamente dada por dicha entidad. Con esto conseguiriamos que la experiencia de “ir al mercado” sea gratificante y aumente el consumo.

 

Estas son algunas propuestas que se me ocurren. Seguro que hay más y mejores. Hasta la fecha lo más parecido a esto se llama Android y lo regula la Open Handset Alliance. Posee un SDK y mercado de aplicaciones (Android Market).

¿se os ocurre algo más? ¿estáis de acuerdo?

 

Translate to:English
MenefanteMenéame TwitterTwitter