?

Log in

Directo desde el Vaticano...

hit counter




"No sabemos qué sistema operativo usa Dios, pero nosotros usamos Linux"
Hermana Judith Zoebelein
Webmaster del Vaticano
Seguir a @facemar en Twitter

Fernando Acero Martin

Crea tu insignia

Licencia Creative Commons

Blog Fernando Acero por Fernando Acero Martín se encuentra bajo una Licencia Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. El presente blog no tiene finalidad informativa, de creación de opinión pública, o de entretenimiento, tiene como finalidad principal, la enseñanza y la divulgación de experiencias, proyectos, pensamientos y conocimientos del autor.

Se permite la copia textual, la traducción y la distribución de los artículos del presente blog en cualquier medio, a condición de que este aviso sea conservado, no se modifiquen.

Se permite la cita.

El autor no cobrará por el ejercicio de los dos derechos anteriores, siempre que no se haga uso comercial de los mismos.

No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre.

Basada en una obra en fernando-acero.livejournal.com.
"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."








Mi hija María ha abierto un despacho de abogados especializado en accidentes de tráfico y con especial atención los ciclistas. Además, como no podía ser de otro modo, también se dedica a temas relacionados con las nuevas tecnologías.

http://abogadosespecialistasenaccidentesdetrafico.com


Acero Campillo es un despacho de abogados ubicado en Madrid con experiencia en reclamaciones de indemnizaciones, que intentamos desde la pasión y el trabajo en equipo para conseguir la máxima indemnización para nuestros clientes.


Nuestro principal objetivo es dar un
servicio personalizado a nuestros clientes, con un trato individual para ofrecer soluciones a los problemas de nuestro cliente y el apoyo en aquellos momentos que en ocasiones son bastantes difíciles.

La consulta inicial y asesoramiento puedes hacerla:


  • En nuestro despacho las realizamos de forma GRATUITA y sin compromiso alguno por tu parte.


  • O si lo prefieres por vía telefónica: 911 138 348


  • Atención a domicilio en todos los casos que el cliente lo necesite (área metropolitana de Madrid).


Resolveremos tus dudas y prepararemos la documentación para que tengas éxito en tu caso y consigas la mayor indemnización.

Evaluación


  • Podrán intervenir todos los profesionales y especialistas en función del siniestro de manera GRATUITA.


Propuesta de Servicios indicando honorarios

  • Se realizará un presupuesto ajustado a tus necesidades, transparente y cerrado.


Documentación

  • Tenemos al cliente informado en todo momento entregándoles la documentación que se va creando ya sea por correo eléctronico, WhatsApp, fax o a través de correo ordinario.


Forma de pago

  • Nuestros honorarios son los fijados por el Ilustrisimo Colegio de Abogados.

  • Posibilidad de pago mediante cuotas mensuales.

Dirección del despacho:

Plaza Condesa de Gavía, 5, bajo,

28020 - Madrid

Atencion permanente 24 horas:

911 138 348 o a través del siguiente formulario.

"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."
No es la primera vez que hablo de Sinadura, en esta ocasión explicaré la forma de configurar el sistema para que Sinadura funcione correctamente en Ubuntu 14.04 y nos permita firmar archivos usando el DNIe o la tarjeta CERES, de la Fábrica Nacional de Moneda y Timbre.

Tal como se indica en la págína web de Sinadura, se trata de un proyecto opensource español liderado por la consultora TIC zylk.net ubicada en Erandio (Bizkaia), orientado a ofrecer productos y servicios para la identidad digital y firma electrónica, tanto para particulares como para empresas y AAPP.

Este proyecto ofrece herramientas de software, servicios y soporte a la comunidad. La herramienta más conocida del proyecto de llama Sinadura Desktop, que es una aplicación de escritorio basada en Java, por lo que es multiplataforma, líder en el mercado para la firma digital de cualquier tipo de archivo. El software de Sinadura garantiza la integridad, identidad y el no repudio en cualquier archivo, como pueden ser nóminas, contratos, facturas o certificaciones en archivos de texto, canciones en archivos de sonido o videoclips en archivos de vídeo.

Desde mi experiencia, disponer de una herramienta para firmar documentos en formato digital y con el mismo valor legal que una firma manuscrita y sello de tiempos, me ha facilitado mucho las cosas en mis relaciones con empresas y con las Administraciones Públicas. Basta con escribir un documento en Open Office, o Libre Office, guardarlo como PDF y luego usar Sinadura con nuestro DNIe, para firmar el documento antes de remitirlo por correo electrónico a su destino. De hecho, me gusta tanto este procedimiento y me ha funcionado tan bien cuando lo he usado, tanto con empresas como con las Administraciones Públicas, que es mi opción preferida cuando existe un correo electrónico de contacto.

Otro entorno en el que Sinadura es una aplicación casi imprescindible, es el de las PYMES ya que esta aplicación, que funciona prácticamente en cualquier sistema operativo, también nos permite firmar digitalmente nuestras facturas electrónicas, con solamente seleccionar dicha opción en la interfaz de usuario.

También considero muy útil, en un momento en el que no todo el mundo está acostumbrado a la firma electrónica de documentos, que Sinadura, a diferencia de otras aplicaciones similares, pueda mostrar en el documento una marca visible indicando que está firmado digitalmente. A pesar de ello, en el correo de remisión también añado siempre el siguiente texto al final, para que quede claro el estatus legal de los documentos remitidos adjuntos al mismo:




"NOTA LEGAL: Este correo y la documentación anexa al mismo, cuentan con firma electrónica reconocida del remitente realizada mediante su DNIe, por lo que según lo establecido en la Ley 59/2003, de 19 de diciembre, de firma electrónica, tanto el correo, como los documentos adjuntos al mismo, tienen la misma validez legal que la de documentos en papel con firma manuscrita."




Veamos el procedimiento para instalar y utilizar Sinadura en una distribución Ubuntu 14.04 LTS, que en mi caso usa el KDE como entorno gráfico, junto con el DNIe, o con la tarjeta CERES modelo "Kriptonita", en la que guardo mis certificados digitales de 2048 bits de CERES, CACERT y STARTCOM.

Como punto de partida consideraremos que tenemos un lector de tarjetas correctamente instalado en nuestro sistema, así como una máquina virtual JAVA, que en mi caso es Oracle versión 7.

Yo uso un lector de tarjetas inteligentes Castles Technologies EZ100PU, comprado en unos grandes almacenes de Madrid hace unos años. Este lector me gusta especialmente, aparte de por su excelente suporte para Linux de 32 y 64 bits (recomiendo bajar los controladores más actualizados para Linux de la página web del fabricante), por la información que proporciona su LED de funcionamiento. Dicho LED está en color verde cuando está alimentado, en color rojo cuando alguna aplicación está haciendo uso de la tarjeta inteligente insertada y parpadea en rojo, cuando dicha tarjeta está siendo utilizada por la aplicación.

De esta forma, evitaremos destruir nuestro DNIe por retirarlo del lector mientras está siendo utilizado, cosa, que por desgracia, suele se demasiado frecuente. El DNIe es relativamente lento y en algunas circunstancias, si el lector no proporciona información sobre el uso de la tarjeta, el usuario puede considerar que la aplicación o el DNIe se han bloqueado, retirando el DNIe antes de tiempo y provocando su destrucción. De hecho, yo voy un poco más lejos y tengo la precaución de salir de las aplicaciones que hacen uso del DNIe para que se ponga el LED del lector en verde, antes de extraer el DNIe.

Dicho lo anterior, considero imprescindible que el lector de tarjetas inteligentes que usemos, informe claramente de que la tarjeta está siendo utilizada por un programa, evitando así el tener que volver a la comisaría a renovar nuestro DNIe.

VERIFICANDO JAVA

En mi Ubuntu 14.04LTS, el archivo java del directorio /usr/bin es un enlace simbólico al archivo /etc/alternatives/java, que a su vez, es un enlace simbólico a la máquina virtual de java, que en mi caso, se encuentra instalada en /usr/lib/jvm/java-7-oracle/jre/bin/java.

Si ejecuto el mandato java -version obtengo lo siguiente:

java version "1.7.0_80"
Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
Java HotSpot(TM) Server VM (build 24.80-b11, mixed mode)

Ahora lo más importante, para que Sinadura funcione adecuadamente, es la correcta configuración de la variable de entorno JAVA_HOME. Para verificarlo, usaremos el mandato echo $JAVA_HOME, que en consonancia con lo anterior, nos debería devolver lo siguiente:

/usr/lib/jvm/java-7-oracle

Si no es así, podemos usar el mandato:

sudo apt-get install oracle-java7-set-default

NOTA: La instalación de oracle-java7-set-default, o oracle-java8-set-default, dependiendo de la versión de Java que tengamos instalada, funcionará si en el archivo /etc/profile no hay ninguna configuración relativa a JAVA_HOME. La instalación de oracle-javax-set-default, lo que hace es crear unos archivos en el directorio /etc/profile.d denominados jdk.sh y jdk.csh que configuran adecuadamente la variable de entorno JAVA_HOME.

Si se desea usar el archivo /etc/profile deberá contener en nuestro caso las lineas siguientes:

JAVA_HOME=/usr/lib/jvm/java-7-oracle/jre
PATH=$PATH:$HOME/bin:$JAVA_HOME/bin
export JAVA_HOMEexport PATH

Posteriormente, para evitar cualquier configuraciones erróneas, será necesario cualquier archivo java.sh, java.csh, jdk.sh o jdk.csh, que pudiera haber en el directorio /etc/profile.d

La siguiente vez que arranquemos el sistema, la variable JAVA_HOME debería apuntar al directorio adecuado.



INSTALAR EL CONTROLADOR DEL DNIe Y DE LA TARJETA CERES

Para ello iremos a la página de descarga de software de la Fábrica Nacional de Moneda y Timbre y descargaremos el archivo GNU/Linux Ubuntu 14.04 - 14.10 - 32 bits o GNU/Linux Ubuntu 14.04 - 14.10 - 64 bits, en función de nuestra distribución. Supongamos que la nuestra es de 32 bits. Para instalar el paquete usaremos el mandato:

sudo dpkg -i libpkcs11-fnmtdnie_1.2.2_Ubuntu_14.04_14.10_32bits.deb

Una vez que se abra el navegador Firefox, solamente habrá que seguir las instrucciones que aparecen en el mismo, que son las siguientes:

Para usar la tarjeta de la FNMT/DNIe en su navegador se requiere:

* Instalar el Módulo de Seguridad PKCS#11

Para instalar el módulo PCKS#11 debe ir a Editar/Preferencias/Avanzado/Cifrado/Dispositivos de seguridad

Seleccione "Cargar"

Dele un nombre al módulo. (Por ejemplo "FNMT-RCM Modulo PKCS # 11")

Indique manualmente la ruta del módulo: /usr/lib/libpkcs11-fnmtdnie.so

Pulse el botón "Aceptar"

* Instalar el Certificado Raíz de la Autoridad de Certificación de la FNMT-RCM

Para instalar el certificado raíz ir a Editar/Preferencias/Avanzado/Cifrado/Ver certificados

Seleccione "Importar".

Indique manualmente la ruta del certificado raíz: /usr/share/libpkcs11-fnmtdnie/FNMTClase2CA.crt

El asistente le pedirá que establezca la confianza para el certificado.

Marque las tres casillas de confianza.

Pulse el botón "Aceptar"

* Instalar el Certificado Raíz de la Autoridad de Certificación del DNIe

Para instalar el certificado raíz ir a Editar/Preferencias/Avanzado/Cifrado/Ver certificados

Seleccione "Importar".

Indique manualmente la ruta del certificado raíz: /usr/share/libpkcs11-fnmtdnie/ac_raiz_dnie.crt

El asistente le pedirá que establezca la confianza para el certificado.

Marque las tres casillas de confianza.

Pulse el botón "Aceptar"

Una vez realizado todo lo anterior y se cierre el navegador, finalizará la instalación del software necesario para que funcione la tarjeta CERES y el DNIe en Ubuntu 14.04 LTS.

INSTALACIÓN DE SINADURA

Para instalar Sinadura Desktop 4.2.0, accederemos a la página del proyecto y descargaremos la version de 32 o 64 bits, en función de la versión de nuestro Ubuntu 14.04. Como en el caso anterior, supondremos que nuestra versión es de 32 bits. Una vez descargado el archivo, usaremos el mandato.

sudo java -jar sinadura-ce-4.2.0-unix32-installer.jar

Pulsaremos "Next", luego aceptaremos la licencia y pulsaremos "Next", después dejaremos el directorio por defecto y pulsaremos "Next", luego aceptaremos la creación del directorio y cuando acabe la instalación de los archivos, volveremos a pulsar "Next". Seguidamente, seleccionaremos las opciones "Create shortcuts in the XDG-Menu", "Create additional shorcuts on the desktop" y "All users", dejaremos el "Program Group" por omisión y pulsaremos "Next". Cuando acabe el proceso, pulsaremos "Done" y con ello tendremos instalado Sinadura en nuestro sistema.

Sin embargo, las librerías gráficas SWT (Eclipse)que usa Sinadura, no se llevan especialmente bien con las librerías del entorno gráfico de Ubuntu, que en mi caso es el KDE. De hecho, cualquier intento de modificar la configuración de Sinadura provocará que Sinadura deje de funcionar y genere un "core". La solución, una vez identificado el problema, es sencilla, solamente hay que editar como root el archivo /usr/share/themes/oxygen-gtk/gtk-2.0/gtkrc, modificando la línea:

GtkComboBox::appears-as-list = 1

Para que muestre lo siguiente:

GtkComboBox::appears-as-list = 0

Una vez salvado el archivo, la próxima vez que ejecutemos Sinadura funcionará perfectamente y se acabarán los "core" de la aplicación.

USANDO EL CONTROLADOR DEL DNIe con SINADURA

En este punto Sinadura no funcionará con el DNIe ni con la tarjeta CERES ya que buscará el controlador en una ruta y con un nombre que no es adecuado para nuestra configuración. El software de la FNMT para Linux instala los controladores del DNIe en /us/lib con el nombre libpkcs11-fnmtdnie.so, mientras que Sinadura los busca en /usr/lib/opensc/ con el nombre opensc-pkcs11.so. Para solucionarlo, editaremos como root el archivo hardware-preferences.csv, que encontraremos en el directorio /usr/local/sinadura/resources/preferences, de forma que la segunda línea del archivo, en lugar de mostrar:

generic;Genérico (32-bit);/usr/lib/opensc/opensc-pkcs11.so;linux;

Muestre lo siguiente:

generic;Genérico (32-bit);/usr/lib/libpkcs11-fnmtdnie.so;linux;

Hecho esto ya podremos usar nuestro DNIe, o una tarjeta CERES, para firmar nuestros documentos o crear facturas electrónicas. Asimismo, Sinadura también puede usar un certificado software para firmar un documento, si se configura adecuadamente para ello, por lo que no es imprescindible disponer de una tarjeta inteligente para firmar documentos aunque en ese caso, los documentos firmados no tendrán el mismo valor legal que un documento con firma manuscrita.

En versiones anteriores de Sinadura este archivo se encontraba dentro de un contenedor "jar", por lo que era mucho más complicado de editar. Por ello, considero muy acertado que por parte de los responsables del proyecto se haya decidido facilitar esta tarea de forma que Sinadura se pueda utilizar con tarjetas, o en entornos, distintos a los considerados inicialmente por los desarrolladores, como ha sido nuestro caso.

Una vez configurado todo adecuadamente, no tendremos problemas para usar nuestro DNIe, o una tarjeta CERES con el navegador Firefox, o con el programa de correo electrónico Thunderbird. También podremos firmar documentos PDF con Sinadura, así como con Open Office o Libre Office, en formato Open Document Format (ODF) y en el caso de usar el DNIe, con la misma validez legal que un documento con firma manuscrita. Hay que señalar que Open Office y Libre Office usan el almacén de certificados de Firefox, por lo que si nuestro DNIe está correctamente configurado en Firefox, también nos funcionará sin problemas con Open Office, o con Libre Office.





"Copyleft Fernando Acero Martín. Se permite la copia textual, la traducción y la distribución de este artículo entero en cualquier medio, a condición de que este aviso sea conservado. Se permite la cita. El autor no reclamará ninguna cantidad por el ejercicio de las dos autorizaciones anteriores. No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre."


"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."
Muchos expertos han alertado en múltiples ocasiones de los riesgos y peligros de permitir ciertas patentes, como por ejemplo, las de programas de ordenador, que deberían quedar protegidos en exclusiva por la Ley de Propiedad Intelectual. Este tema parecía que había quedado zanjado en Europa en el año 2005, pero sin embargo, la legislación española, de aprobarse finalmente el texto del actual Proyecto de Ley de Patentes, podría llegar a permitir la patentabilidad de lo que antes no era patentable, como es el caso de los programas de ordenador, otorgando a corporaciones derechos que anteriormente estaban restringidos a las personas, lo que puede ser tan peligroso como restrictivo.

El próximo martes día 10 de marzo acaba el plazo para presentar enmiendas en el Congreso al Proyecto de Ley de Patentes. Si revisamos su contenido, veremos que en su Artículo 4, dedicado a definir las invenciones patentables, en sus puntos 4 y 5 dice lo siguiente:

4. No se considerarán invenciones en el sentido de los apartados anteriores, en particular:

a) Los descubrimientos, las teorías científicas y los métodos matemáticos.

b) Las obras literarias, artísticas o cualquier otra creación estética, así como las obras científicas.

c) Los planes, reglas y métodos para el ejercicio de actividades intelectuales, para juegos o para actividades económico-comerciales, así como los programas de ordenadores.

d) Las formas de presentar informaciones.

5. Lo dispuesto en el apartado anterior excluye la patentabilidad de las materias o actividades mencionadas en el mismo solamente en la medida en que la solicitud de patente o la patente se refiera exclusivamente a una de ellas considerada como tal.


En la redacción actualmente en vigor de 1985, el Artículo 4 apartado 5 dice lo siguiente, que sería lo más adecuado:

5. Lo dispuesto en el apartado anterior excluye la patentabilidad de las materias o actividades mencionadas en el mismo solamente en la medida en que la solicitud de patente o la patente se refiera exclusivamente a una de ellas.

El problema se encuentra en la expresión "como tal" del final del apartado 5 del Proyecto de Ley de Patentes, que en el ámbito internacional, se conoce como la cláusula "as such". Según la interpretación de la  Oficina Europea de Patentes, que normalmente es la que se usa como referencia en cualquier ámbito, incluido el judicial, el término "como tal", implicaría, simple y llanamente, que todas las excepciones no patentables que se mencionan en la ley, podrían ser patentables si van asociadas a algo más.

Es decir, "software" ya no sería lo mismo que "software como tal", o "teoría científica" tampoco sería lo mismo que "teoría científica como tal" cara a su posible patentabilidad.

Evidentemente, este artificio sería fácilmente utilizable por todo aquel que desee patentar cualquier cosa que en teoría no debiera poder patentarse y quedar protegido por la Ley de Propiedad Intelectual.

Los efectos de una patente pueden ser devastadores, como ya se ha demostrado en muchas ocasiones, cuando este concepto se aplica sobre cosas que generan derechos que anteriormente estaban restringidos a las personas y que deberían quedar protegidas y en exclusiva, mediante instrumentos de Propiedad Intelectual. Si no se hace adecuadamente, se pueden acabar restringiendo de forma grave, artificial e injusta, la libertad de expresión y creación, la innovación tecnológica, o los derechos fundamentales a la salud, alimentación o educación, o incluso, el libre mercado.

  
"Copyleft Fernando Acero Martín. Se permite la copia textual, la traducción y la distribución de este artículo entero en cualquier medio, a condición de que este aviso sea conservado. Se permite la cita. El autor no reclamará ninguna cantidad por el ejercicio de las dos autorizaciones anteriores. No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre."


ACTUALIZACIÓN: 12 DE MAYO DE 2015

Ayer recibí un interesante comentario de Alfredo José Muela Romero, que que por su longitud, no cabe como comentario, así que he decidido anexarlo al artículo para que todo el mundo lo pueda leer sin problemas:

Subject: Que no es por no ser alarmista, pero serlo para nada...

... es tontería. Como decía mi paisano Mota.


Para poner contexto en de dónde saco la información, decir que durante un año completo he trabajado en la Oficina Europea de Patentes, como examinador de patentes en el clúster de ordenadores, departamento de "métodos de negocio" (G06Q). Hablando en plata, solicitudes de patente de software. Sin esto convertirme en ningún experto como mis antiguos compañeros que llevan allí 15 años y han visto evolucionar todo, sí que sé de lo que hablo, he tenido que estudiar la EPC, PCT, guidelines, leer casos ocurridos, etc. Vamos, que podemos decir que ando informado de la legislación, pero sobre todo de cómo se trabaja desde dentro y cómo funciona la mente del examinador de patentes en este área (bueno, las mentes de algunos son bastante... peculiares, pero supongo que como en todos sitios). Espero que sepáis perdonarme si meto la gamba con algunas traducciones porque durante el día a día los idiomas usados en la oficina europea son el inglés, francés y alemán por lo que mi castellano en estas lides será rudimentario.

Tras este ladrillo introductorio en el que no pretendía alardear de nada, sino exponer de dónde viene lo que lo voy a decir, vamos al lío.

Por un lado, el cambio no refleja más que una adaptación de la legislación española a la EPC (European Patent Convention) que ya en su momento aceptó para formar parte del grupo y tener "cobertura". Desde mi punto de vista, lo que no tenía mucho sentido es que la legislación en España dijese A, la europea A'. Sobre todo, porque siempre se podía realizar la solicitud en la oficina europea pidiendo protección para España sólo... pero el debate de oficinas nacionales vs oficina europea es otro tema que da para muchas cervezas.

Por otro lado, el cambio que se menciona debido al "as such" efectivamente otorga la característica de patentabilidad al software. Sin embargo, el que el software vaya asociado a cualquier "sistema computador de propósito general" no implica que, aunque tu idea / software, sea nuevo el resultado final vaya a ser "inventivo" (aquí viene el meollo). Para que una invención se considere merecedora de una patente tiene que suponer un avance inventivo (inventive step) respecto al estado del arte existente y público(*) previo a la solicitud de la patente. Lo más frecuente, es caer en la siguiente situación:

"1) un ordenador capaz de ejecutar instrucciones es conocido en el estado del arte

2) la diferencia entre cualquier ordenador (invención) que ejecute instrucciones y la solicitud actual es el conjunto de instrucciones nuevas"

Ahora se llega a un punto crítico dónde hay que responder a las siguientes preguntas:

- ¿El conjunto de instrucciones nuevas describe un proceso mental, esquema de reglas / algo que cae en el grupo de las "cosas" no patentables? Si respondemos que sí, que será así en la mayoría de los casos puesto que al final los programas suelen ser un conjunto de reglas a seguir que se les podría dar al Fulanito de turno para ejecutar, entonces estamos ante algo que no es inventivo y la solicitud se denegará.

- ¿El conjunto de instrucciones nuevas provee de un efecto técnico/tecnológico (más allá que la transmisión de una corriente eléctrica al sistema) extra que no es "obvio"? entonces el conjunto de software más hardware descrito en la solicitud, merece la patente (según la EPC vigente, mi opinión la dejamos para otro momento ;D)

Como os podréis imaginar aquí hay infinidad de matices de gris, explicaciones e interpretaciones. Pero si estáis interesados, uno de los casos bases de todo este tinglado es el conocido como COMVIK, oficialmente T 641/00. Desde ahí, se puede empezar a hablar más y más.

"Resumen ejecutivo": sí, con la nueva modificación los programas que vayan asociado a un hardware se considerarán como invención patentable pero esto no es nada nuevo porque es lo que viene diciendo la EPC desde hace tiempo. A efectos prácticos, nada cambiará en la inmensa mayoría de las situaciones (podemos hablar en otro momento de cuales sí serán esas que afecten con ejemplos).

En lo que se refiere al software libre, la publicación del código, así cómo de qué es lo que pretende solucionar y la forma es el mejor arma posible contra las patentes de software porque se considerarán parte del estado del arte para cualquier solicitud. Por lo tanto, mi consejo es si os preocupa el asunto apoyad el software libre, publicad todo lo antes posible, incluso aunque no esté terminado ni sea funcional, ya veréis como los examinadores lo encuentran (son muy buenos en esto de buscar arte previo, creedme) e informan al solicitante que lo que están intentando no es novedoso. Si sois/tenéis una empresa y queréis solicitar una patente porque creéis en el asunto, pues también os aconsejo que lo publiquéis, eso sí justo al día siguiente de presentar la solicitud en la oficina pertinente.

No me enrollo más, espero haber aclarado algo o al menos haber dado un poco de información sobre el asunto :-)


Saludos, Alfredo (@alfredomuela https://nl.linkedin.com/in/ajmuela)

(*) Hay algunas excepciones sobre esto, pero lo dejamos para otras cañas más.
++++++++++++++++++
72
"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."

Jugando con números aleatorios en Linux





En este mundo altamente digitalizado, nuestra seguridad lógica depende en gran medida de la calidad de los números aleatorios que se utilizan para generar claves criptográficas y para otras funciones relacionadas con la seguridad de los sistemas y de las comunicaciones. Los números aleatorios están presentes en los cajeros automáticos, en los chips inteligentes, cifradores, routers, etc. Por ello, no es de extrañar, que tras desvelarse las oscuras maniobras de la NSA para espiar a todo el mundo, rápidamente se sospechase de la seguridad real de los sistemas de generación de números aleatorios, tanto de software como de hardware. Pero este no es el único problema que tenemos que tener en cuenta en relación con los números aleatorios, puesto que además de la calidad, también afecta a nuestra seguridad la cantidad de números aleatorios a los que podemos acceder en un determinado momento.


LAS PISCINAS DE ENTROPÍA

Hay casos documentados de ataques exitosos a sistemas por un mal diseño de un generador de números aleatorios. Uno de los más famosos, es el que comenta Kevin Mitnick en el primer capítulo de su libro "El arte de la intrusión". Es una historia real en la que unos amigos realizando ingeniería inversa de varias máquinas de casino, descubren que el generador de números aleatorios utilizado en las mismas, es realmente una secuencia muy larga de números y que tarde o temprano se repite. De esta forma, logran predecir el momento exacto en el que la máquina dará el premio. Este descubrimiento les permitió entrar en los casinos y ganar grandes sumas de dinero, lo que se prolongó varios años hasta que uno de ellos fue pillado en un casino usando el ordenador que hacía los cálculos escondido entre su ropa.

Otro caso famoso, fue el fallo del navegador NETSCAPE a la hora de generar los números aleatorios necesarios para las sesiones SSL. Este fallo que hacía predecibles los números aleatorios usados, permitía que un atacante pudiera ver el tráfico cifrado entre el servidor y dicho navegador sin el conocimiento del usuario.

Cuando trabajamos con Linux, los números aleatorios están disponibles en dos dispositivos, también denominados piscinas de entropía, denominados /dev/random y /dev/urandom. Recordemos que Linux tiene el honor de ser el primer sistema operativo que disponía de un generador aleatorio integrado en el kernel del sistema, aunque también es cierto, que hay algunos estudios del año 2013 que sostienen que el generador de números aleatorios de Linux no es tan bueno como debiera. Estos estudios se basan en que un ordenador determinista y un programa no son la mejor forma de lograr números aleatorios. Es decir los ordenadores están diseñados para no ser aleatorios, más bien todo lo contrario, no deben serlo y ante una determinada entrada, siempre deben proporcionar de forma previsible una misma salida, lo que evidentemente no es demasiado aleatorio. Pero como veremos hay métodos para comprobar lo buenos que son nuestros números aleatorio y para mejorar su generación.

Para intentar paliar el problema del determinismo, el sistema operativo Linux recopila entropía de los contradores de dispositivo y de otras fuentes, como el teclado, ratón o el reloj del sistema y posteriormente, aplica algoritmos de hash para intentar generar unos números aleatorios, o lo que es lo mismo, impredecibles. Sin embargo, mediante este método, la cantidad disponible de números aleatorios es limitada. Es decir, cuando la fuente de entropía /dev/random está vacía, las lecturas de este dispositivo se bloquearán hasta que se logre llenar de nuevo con más números aleatorios. Es decir, /dev/random se comporta como una especie de "one-time-pad" que garantiza que los números aleatorios ya utilizados no se pueden volver a utilizar.

Por estas características el dispositivo /dev/random está pensado para ser usado cuando se requieran unos números aleatorios de elevada calidad. Como por ejemplo, cuando es necesario generar claves criptográficas, o cuando se desea borrar un disco o un archivo de forma segura mediante sobreescritura aleatoria bit a bit. El comportamiento de /dev/random lo podemos comprobar introduciendo el siguiente mandato en una consola:

hexdump -C /dev/random

Tras pulsar la tecla Enter, veremos que aparecen una serie de números aleatorios en hexadecimal, pero que al poco tiempo el listado en pantalla se para. Esto se debe a que se han gastado los números aleatorios disponibles en dicha piscina de entropía. Para continuar, tendremos que añadir más entropía al sistema, lo que se suele hacer moviendo el ratón por la pantalla, pero ¿es una buena fuente de entropía adicional el movimiento del ratón?. Luego veremos unas posibles soluciones al problema.

Si queremos saber la cantidad de entropía disponible en nuestro dispositivo /dev/random, debemos usar este mandato desde la consola:

cat /proc/sys/kernel/random/entropy_avail
568

Evidentemente, con el avance del tiempo, al aumentar el tamaño de las claves y con el uso de sistemas mas seguros que hacen un uso extensivo de funciones criptográficas, también han aumentado las necesidades de números aleatorios. De esta forma, en una Mandriva de 2010, lo normal era que el mandato anterior diera valores inferiores a 200, mientras que en una Ubuntu 14.04 LTS, la entropía disponible rondará un valor entre 650 y 780, aunque como veremos, puede que este valor sea pequeño para algunos usos, Un caso típico sería generar una clave RSA de 4096 bits.

Por otra parte, el dispositivo /dev/urandom devolverá tantos bytes como se soliciten. Como resultado, si no hay suficiente entropía, es decir, si no hay suficientes números en dicho dispositivo, la salida no se bloqueará y seguirá proporcionando valores, lo que puede provocar que no sean tan aleatorios como pensamos y haciéndolos vulnerables a determinados ataques.

Por este motivo, /dev/urandom no se debe utilizar cuando la seguridad sea fundamental, por ejemplo, cuando deseamos generar una clave de larga duración GPG o SSL. No es así, por ejemplo, cuando lo que queremos es crear un programa de simulación que necesite una entrada de valores razonablemente aleatorios. Usando /dev/urandom nos aseguramos de que el programa no se detiene por la falta de números aleatorios. Como en el caso anterior, podemos abrir una consola y usar el mandato para ver su comportamiento:

hexdump -C /dev/urandom

Como hemos anticipado, en este caso el listado de números no se detiene, pero también es posible que la calidad de los datos aleatorios generados no sea muy buena.


PROBANDO NUESTROS GENERADORES ALEATORIOS

¿Cómo podemos medir la calidad de nuestros números aleatorios generados por /dev/random y /dev/urandom?. El proceso es relativamente sencillo. Para ello podemos usar el mandato Linux ent, que se encarga de medir la entropía de archivos binarios. Para ello, generaremos dos archivos a partir de los valores de /dev/random y /dev/urandom. pero para que los datos estén generados en las mismas condiciones en las dos piscinas, lo primero que debemos hacer es comprobar la cantidad de entropía que tenemos disponible en /dev/random, lo que haremos mediante el mandato:

cat /proc/sys/kernel/random/entropy_avail
1100

Si usamos este mandato varias veces, veremos que la cifra cambia. Para no superar el valor de entropía disponible en /dev/random elegiremos un tamaño de archivo con un valor inferior a todos los valores obtenidos tras realizar varias pruebas. En este caso usaremos un valor de 1000 caracteres, que es inferior a 1100:

dd if=/dev/random of=rnd.test bs=1c count=1000
1000+0 registros leídos
1000+0 registros escritos
1000 bytes (1,0 kB) copiados, 0,0695683 s, 14,4 kB/s

Seguido del mandato:

dd if=/dev/urandom of=urnd.test bs=1c count=1000
1000+0 registros leídos
1000+0 registros escritos
1000 bytes (1,0 kB) copiados, 0,0739844 s, 13,5 kB/s

Una vez que hemos creado los archivos rnd.test y urnd.test de 1K de tamaño cada uno de ellos, usaremos los mandatos siguientes:

ent rnd.test
Entropy = 7.820170 bits per byte.

Optimum compression would reduce the size
of this 1000 byte file by 2 percent.

Chi square distribution for 1000 samples is 227.26, and randomly
would exceed this value 75.00 percent of the times.

Arithmetic mean value of data bytes is 131.8870 (127.5 = random).
Monte Carlo value for Pi is 2.915662651 (error 7.19 percent).
Serial correlation coefficient is 0.013190 (totally uncorrelated = 0.0).

Seguido de:

ent urnd.test
Entropy = 7.790775 bits per byte.

Optimum compression would reduce the size
of this 1000 byte file by 2 percent.

Chi square distribution for 1000 samples is 255.94, and randomly
would exceed this value 50.00 percent of the times.

Arithmetic mean value of data bytes is 129.5400 (127.5 = random).
Monte Carlo value for Pi is 3.349397590 (error 6.61 percent).
Serial correlation coefficient is 0.009675 (totally uncorrelated = 0.0).

Como podemos ver, el valor de la entropía es superior en el caso del archivo rnd.test. El nivel de compresión que permiten ambos archivos de un 2%, siendo lo ideal para una entropía absoluta una compresión de un 0%. Este valor es muy dependiente del tamaño del archivo, por lo que es más probable que se logre una compresión del 0% en archivos de mayor tamaño.

Asimismo, veremos los valores de la distribución Chi cuadrado (distribución de Pearson). Esta función es la prueba más utilizada para comprobar que una serie de datos es aleatoria y es muy sensible a los errores que se producen en con los generadores pseudoaleatorios. Esta función se calcula a partir de la secuencia de bytes del archivo y se expresa en la forma de un valor y de un porcentaje, que indica lo frecuente que un valor verdaderamente aleatorio debería exceder el valor calculado.

Dicho valor se debe interpretar como el porcentaje de veces en la que la secuencia probada es sospechosa de no ser aleatoria. Es decir, si el porcentaje es mayor de 99% o menor del 1% podemos decir que la secuencia no es aleatoria. Si el porcentaje está entre el 99% y el 95% o entre el 1% y el 5%, podemos decir que la secuencia es posiblemente no aleatoria. Porcentajes entre el 90% y el 95% o entre el 5% y el 10% nos indican que la secuencia podría ser no aleatoria.

Como referencia, estos son los valores que muestra dicha función, ante una secuencia procedente de un generador de números aleatorios reales basado en la descomposición radiactiva.

Chi square distribution for 32768 samples is 237.05, and randomly
would exceed this value 75.00 percent of the times.

Si comparamos este valor, procedente de un generador aleatorio de alta seguridad, con los valores que acabamos de obtener anteriormente con nuestros /dev/random y /dev/urandom, veremos que nuestros generadores aleatorios no son nada malos en base a los valores obtenidos para la distribución de Pearson.

Al margen de lo anterior, los valores obtenidos en este caso para la media aritmética, el valor de Pi (Monte Carlo) y para el coeficiente de correlación de la serie, aparentemente son mejores para la piscina de entropía /dev/urandom. Hay que señalar, que estos resultados comparativos no son demasiado significativos si solamente se obtienen una vez, sobre todo, si los ambos generadores son medianamente buenos, como parece que es el caso. Estos valores pueden cambiar de forma significativa entre pruebas consecutivas, por lo que se recomienda realizar varias mediciones y efectuar un análisis estadístico de las mismas, si queremos evaluar con más precisión o certeza la bondad de nuestros generadores de números aleatorios.

Como hemos visto, el mandato ent solamente sirve para archivos binarios, sin embargo, en ocasiones podemos disponer de listados de números aleatorios en formato hexadecimal en modo texto ASCII procedente de otras fuentes, por ejemplo de la página Random.org,, que es un servicio que proporciona números aleatorios con fines científicos o didácticos. Para poder verificar la calidad de los mismos, es necesario pasarlos a binario, para lo que podemos utilizar la utilidad SFK o en castellano, la "navaja suiza para ficheros".

Otro mandato que nos vendrá muy bien para convertir volcados hexadecimales de números aleatorios a binario y viceversa, es xxd. Por ejemplo, para convertir un binario a hexadecimal plano, debemos usar el mandato:

xxd -p RANDOM.BIN > RANDOM.TXT

La opción -p es la que indica que lo que deseamos es un volcado hexadecimal en formato plano, es decir, sin equivalencia de caracteres, espacios, ni posición en el archivo. Para la operación inversa usaremos el mandato:

xxd -p -r RANDOM.TXT > RANDOM.BIN

En este caso la opción -p indica que el origen es un volcado plano y la opción -r, que lo queremos es realizar la operación inversa, es decir, convertir un archivo de texto en binario.

También podemos concatenar archivos convertidos a texto o a binario usando >> en lugar de > en dichos mandatos y modificando el archivo de origen de forma sucesiva.

Este mandato nos será de mucha utilidad cuando trabajemos con los generadores de números aleatorios de las tarjetas inteligentes.


COMPROBANDO Y FILTRANDO UN FLUJO DE DATOS ALEATORIOS CON RNGTEST

Alternativamente, para comprobar nuestro generador de números pseudoaleatorios /dev/urandom, podemos usar el mandato rngtest, que está disponible en el paquete rng-tools de Linux, mediante el mandato:

cat /dev/urandom | rngtest -c 1
rngtest 2
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 20032
rngtest: FIPS 140-2 successes: 1
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=18.626; avg=18.626; max=18.626)Gibits/s
rngtest: FIPS tests speed: (min=136.239; avg=136.239; max=136.239)Mibits/s
rngtest: Program run time: 189 microseconds

En el mandato anterior hemos usado la opción -c 1, que limita el análisis a un único bloque, ya que se necesita como mínimo un bloque de 20.000 bits para pasar las pruebas FIPS 140-2 (monobit, póquer, rachas y rachas largas y ejecución continua).

En este caso, el mandato rngtest ejecuta una serie de pruebas estadísticas diseñadas por la NSA y publicadas por el NIST, que deben pasar con éxito los generadores de números pseudoaleatorios para considerarse seguros.

Una cosa interesante de este mandato, es que también lo podemos usar para mejorar nuestros generadores de números pseudoaleatorios mediante la opción -p que activa el modo "pipe" y que envía a la salida estándar solamente los bloques de 20.000 bits que han pasado con éxito las pruebas FIPS, lo que podemos probar mediante el mandato:

cat /dev/urandom | rngtest -p -c 10 | hexdump

Veamos ahora la forma en la que se realizan cada uno de estos tests FIPS:

a) Test monobit

Se cuenta el número de bits iguales a uno en una secuencia de datos aleatorios de como mínimo 20.000 bits. El test se pasa si dicho número está entre los valores 9.275 y 10.275.

b) Test póquer

En este caso se divide una secuencia de 20.000 bits en 5.000 segmentos contiguos de 4 bits. Después se cuenta y se almacena el número que ocurre cada uno de los 16 valores posibles, siendo f(v) el número de veces que apareció el valor v 0<=v<=15. Luego se calcula la expresión X = (16/5000) * ( f(1)^2 + f(2)^2 + ... + f(15)^2) – 5000. El test se pasa con éxito si 2,16 < X < 46,17.

c) Test de rachas

Una racha se define como una subsecuencia máxima de bits consecutivos de unos o de ceros y que forman parte de la secuencia inicial de 20.000 bits. Para el test se cuentan las ocurrencias para las rachas de 1 a 6 bits. El test se pasa si el número de rachas que ocurren (de longitudes 1 a 6) están en los intervalos especificados en la siguiente tabla, lo que se deberá verificar tanto para las rachas de ceros y de unos. Las rachas de longitud superior a 6 se considerarán de longitud 6.

Longitud Número de ocurrencias
1 2.343 - 2.657
2 1.135 - 1.365
3 542 - 708
4 251 - 373
5 111 - 201
6 111 - 201

d) Test de rachas largas

Una racha larga se define como una racha de longitud 26 o más, con independencia de que sea de ceros o de unos, el test se pasa si en el bloque de 20.000 bits no hay rachas largas.

e) Test de ejecución continua

Para este test se divide el flujo de entrada en bloques de como mínimo 16 bits, adaptándose al tamaño de bloque del generador si es superior a 16 bits. Para el test, el primer bloque de 16 bits se compara con el segundo bloque de 16 bits, el segundo bloque será válido si no es idéntico al primero, de otro modo se considerará un fallo del generador. El segundo bloque de 16 bits será comparado con el tercero y así sucesivamente hasta terminar todos los bits de entrada.


EL PROBLEMA DE LO ESTÁTICO

Cuando un sistema Linux arranca sin mucha interación con el operador, el almacén de entropía puede estar en un estado relativamente predecible, por la reducción en la cantidad de "ruido" presente en el sistema y que es lo que se usa principalmente para generar números aleatorios. Para evitar este problema, podemos usar varios trucos aprovechando que los dispositivos /dev/random y /dev/urandom son de lectura y escritura. Por ejemplo, podemos guardar la información que habría presente en la piscina de entropía para ser usada como "semilla" en el siguiente arranque. Para ello podemos hacer un script que se ejecute durante el apagado del sistema con los mandatos siguientes:

dd if=/dev/urandom of=/var/semilla_urandom count=1
dd if=/dev/random of=/var/semilla_andom count=1

Con ello hemos creado en el directorio del sistema /var/ dos archivos con el estado de /dev/random y /dev/urandom en el momento de apagar el sistema.

Después añadiremos otro script para el arranque del sistema con los mandatos:

if [ -f /var/semilla_urandom]; then
cat /var/semilla_urandom > /dev/urandom
fi
dd if=/dev/urandom of=/var/semilla_urandom count=1

if [ -f /var/semilla_random]; then
cat /var/semilla_random > /dev/random
fi
dd if=/dev/random of=/var/semilla_random count=1

Dicho script comprueba la existencia de los archivos /var/semilla_urandom y /var/semilla_random y en caso afirmativo, los copia en los dispositivos /dev/urandom y /dev/random y en caso contrario los crea adecuadamente.

Evidentemente este problema de seguridad relacionado con la falta de enotropía es especialmente grave en los sistemas "live", en los sistemas creados con herramientas para realizar un "snapshot" de sistemas, como Gost o similar, y en las imágenes virtualizadas, cuando se realizan arranques sucesivos. En todos estos casos las piscinas de entropía empiezan desde la misma situación inicial una y otra vez, por lo que los sistemas que las usan son vulnerables hasta que se genere entropía nueva, lo que puede tardar un poco si hay poca interacción con el usuario.

En estas situaciones y sobre todo, si vamos a usar dichas imágenes de los sistemas para tareas relacionadas con la seguridad o la criptografía, como generar claves criptográficas, acceder a páginas web seguras, o cualquier otra tarea que requiera disponer números aleatorios de cierta calidad, deberíamos obtener un archivo con entropía de calidad desde otro sistema e inyectarla en las piscinas de entropía del sistema estático, escribiendo sobre ellas, antes de comenzar a usar el sistema.


JUGANDO CON GENERADORES DE HARDWARE

Una forma sencilla de acceder a un generador de números aleatorios por hardware es mediante el uso de una tarjeta inteligente, puesto que todas ellas llevan uno integrado para la generación de claves. Para mis pruebas he usado una tarjeta CERES modelo "krirptonita" de la FNMT, ya que es una tarjeta que tiene unos controladores que funcionan perfectamente bajo mi Ubuntu 14.04 y que además, son compatibles con el dnie. Como es lógico, para que esto funcione también es necesario disponer de un lector de tarjetas inteligentes conectado a nuestro sistema y con sus controladores adecuadamente instalados.

Una vez insertada la tarjeta en el lector, usaremos el mandato siguiente para conectar con ella:

opensc-explorer --reader 0 -c dnie

En este mandato usamos el lector 0 y el controlador dnie, que es el que se corresponde al de la tarjeta CERES,

En el prompt que nos aparece, escribiremos el mandato random 128, puesto que este es el mayor número de números aleatorios que puede generar esta tarjeta cada vez. Cuando queramos salir del entorno de opensc-explorer, escribiremos exit seguido de intro:

OpenSC Explorer version 0.12.3-svn
OpenSC [3F00]> random 128
00000000: F2 AC 2A 78 C5 C2 B1 30 A4 41 B6 28 31 7F 46 C4 ..*x...0.A.(1.F.
00000010: FB A4 E9 AC 01 B4 B8 36 36 57 E3 84 7F 23 17 2F .......66W...#./
00000020: D9 28 70 7D 7F 56 85 99 80 58 E8 E7 10 C0 C1 64 .(p}.V...X.....d
00000030: CE 07 EB BB 3D 1A 29 B9 49 CF DE F6 66 97 EC 66 ....=.).I...f..f
00000040: 3B 74 2E 01 0B E9 5A CD D2 07 11 0C 78 DA 12 69 ;t....Z.....x..i
00000050: 26 E5 7F 7F 4D 18 C4 2C 84 89 18 BC B1 7F 11 0B &...M..,........
00000060: 21 4A E2 EB C1 F5 7B 14 27 12 8E 39 55 A4 EB B6 !J....{.'..9U...
00000070: E7 CA A1 1C 85 9A 6F 90 89 19 D8 F0 BF 6B D0 80 ......o......k..
OpenSC [3F00]> exit

Ahora podemos generar varios bloques y jugar con la opción -p (plain) del mandato xxd para generar un archivo de mayor tamaño, Por ejemplo,yo he concatenado 10 bloques random y he generado este archivo:

900a522fd7a1f317eecdd7d645938e7fbe6a8ceda037d7750bd6af9c7d0d
712ddf4d3aca9ecb7b9eec364df34416590e21b8bcc6a1706b807b0222bc
564406e5a21c13aa8c9a3d5d5df106ad45dd6a13092372a70d1d22a081ca
6a264ad08eca022d5b2f4f15829f4d856b5282d0d3932e2f41ac15ffdc9e
352f94165ad12cfffa20bd47c5a3f99dac69e4bcf135140338d32d12632e
9a3b60eb99e1c404cbe620ec09df62cb49080442d889e8849f7eb9840d17
4d62fc51e4423e7349f254bea443ab2f2c31f67aa97bd8f249d2ecac4d65
fa47be7f163ef5242456001e3b40606cafe54b4c14e3d547659526af973c
6f9438079404ef1fba5245d081d866576baf89d9b0313c47bd11566d38e3
8585a06f223bddcdba4dcb96c6b2469d5b0aae37dd4d2dd1365b59abf4a6
d115b273e6cfb6883cd0ac5fee64c93228109b4a2e5ee2d0bd287f53a97c
cefcfb82364b797fcc94c5400b97a4bb625f71c859e49bfd3632aecb8642
e6492cdfe9ed816e257c5c7e3a0c261a611faff7f81991f7819c9fbc8575
fc52644efdebc8e0eb5683396a9ae3c26c22aded3f9ad97c9f2133d902ef
b61284271f106cafb983413ff388992396b5cfcb4caf0c19994dc4ef7620
690142af8ce359d1916308781a366cef594ccf2177c1337327cab55c67fe
48183e2e8c96364a5b39d867da7846b4d55199844377f452e13f4f877b30
7edf4098ffd956fcafc75c317708d4a4bcd73bfe3c3e2eaa3062190d2196
c1117e25df37971432f41673f60b130b6ec369e5e02206ec38b06525ee12
8040b394f507e050dcc95fa11e8fbbd0535f611d836a0f21933dd9a4e634
f8aa8332f08a78ed5b985f023799c0cf7bff14040675b47d5f540e804a9f
de23027014a9258ba1472587d01c9d1befda8042f85ca471495426a0800b
e745552d8c33fca90120bead2bdf2dbab5c8a848518e53f3708de54bbcdb
2f0de596fc3a61d8e5112382f2a88d5cdc20d90bbcaeeaa4b43258adca88
e1b7a12f96d3b4e29b445873b05d870c532ab75a5f0662c28f89866f05a2
0b4a487f4c61752284aa559a0f7ba94581ae94f8d12e1f6956a4017be043

Posteriormente, he usado el mandato xxd con las opciones -r y -p para generar un binario que podemos analizar con el mandato ent:

ent fnmt_random.bin
Entropy = 7.889725 bits per byte.

Optimum compression would reduce the size
of this 1952 byte file by 1 percent.

Chi square distribution for 1952 samples is 326.03, and randomly
would exceed this value 0.50 percent of the times.

Arithmetic mean value of data bytes is 125.0840 (127.5 = random).
Monte Carlo value for Pi is 3.089230769 (error 1.67 percent).
Serial correlation coefficient is 0.002788 (totally uncorrelated = 0.0).

Hay que señalar, que si la muestra obtenida con el generador no es lo suficientemente grande, es posible que los resultados del análisis no sean demasiado buenos. Alternativamente, si concatenamos suficientes bloques de 128 números aleatorios (8 bits), como para poder obtener más de 20.000 bits lo podemos analizar en base a las pruebas FIPS con el mandato rngtest:

cat fnmt_random.bin | rngtest


AUMENTANDO LA CANTIDAD DE ENTROPÍA DISPONIBLE

Como hemos dicho, tan problemático es disponer de una entropía de calidad, como el disponer de una cantidad suficiente de entropía en la piscina /dev/random. Una solución al problema podría ser la utilización de un generador de entropía basado en hardware, entre los distintos modelos que hay en el mercado. De hecho, teniendo en cuenta los problemas para obtener números aleatorios de calidad a partir de soluciones de software, algunos fabricantes comenzaron a añadir en sus placas base dispositivos de generación de números aleatorios. Un ejemplo lo tenemos en el chip Bull Mountain. La polémica aparece, cuando en pleno debate sobre el espionaje de la NSA, se descubre que dicho chip cuando funciona en Linux no se usa realmente para aumentar la entropía de la piscina de Linux y mejorar su calidad. En su lugar, Intel añadió al núcleo de Linux una función denominada RdRand, que permite acceder directamente al chip, lo que algunos consideraron una amenaza al no poder auditar el chip.

Por cierto, si no queremos que el núcleo de Linux use esta función para obtener números aleatorios de una fuente no auditable, solamente tenemos que añadir en la configuración de grub el parámetro "norand" para el arranque del núcleo. Para ello, editaremos el archivo /etc/default/grub y modificaremos la línea GRUB_CMDLINE_LINUX, para que aparezca como GRUB_CMDLINE_LINUX="norand", tras grabar este archivo, la próxima vez que arranquemos el sistema ya no usará el generador de números aleatorios por hardware.

Visto lo anterior, una solución muy interesante y elegante podría ser la utilización en nuestro sistema de un generador aleatorio basado en hardware abierto, evitando así las dudas existentes con otros dispositivos de hardware cerrados.

Alternativamente también tenemos una solución por software que nos permitirá aumentar la entropía del sistema y mejorarla al considerar otras fuentes de ruido. Se trata del demonio Linux haveged, que como su nombre indica, se basa en el algoritmo havege. Dicho algoritmo se basa en el hecho de que el tiempo de ejecución de una pieza determinada de software no se puede repetir incluso en una máquina en reposo.

Para su funcionamiento usa algunas capacidades ocultas de los procesadores, tales como instrucciones ocultas y el caché de datos, así como las tablas de translación de memoria virtual asociadas. Havege usa las diferencias en el contador de tiempo de ejecución del procesador durante la ejecución de un bloque determinista de código, que recolecta estas variaciones en el sistema. El bucle está diseñado para que ejecute instrucciones y para que afecte al caché de datos, aumentando así la variación de la entropía.

Para usarlo, solamente hay que instalar el paquete haveged y posteriormente editar como root el archivo /etc/default/haveged para que genere la cantidad de entropía que queramos. Por ejemplo, para generar una piscina de entropía de 1024 usaremos el mandato:

DAEMON_ARGS="-w 1024"

Una vez definido este valor habrá que asegurarnos de que haveged tiene en cuenta estos cambios en el siguiente arranque, para lo que usaremos el siguiente mandato en una consola como root:

update-rc.d haveged defaults

Seguido de lo siguiente, también como root:

cd /etc/init.d
./haveged restart

Ahora notaremos dos cambios importantes, si usamos el mandato:

cat /proc/sys/kernel/random/entropy_avail

Veremos que ha aumentado el tamaño de nuestra piscina de entropía, asimismo, si usamos el mandato siguiente:

hexdump -C /dev/random

Es posible que el listado no se pare como ocurría antes de activar el demonio haveged. Asimismo, si probamos la calidad de los números aleatorios generados usando los métodos descritos anteriormente, es posible que podamos comprobar que la calidad de los mismos es mayor.


"Copyleft Fernando Acero Martín. Se permite la copia textual, la traducción y la distribución de este artículo entero en cualquier medio, a condición de que este aviso sea conservado. Se permite la cita. El autor no reclamará ninguna cantidad por el ejercicio de las dos autorizaciones anteriores. No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre."

"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."

En febrero de este año decidí cambiar la licencia de mis artículos y de mi página web, tras leer el Anteproyecto de Ley de Propiedad Intelectual (LPI) que se nos venía encima. El texto que elegí era el siguiente:

"Copyleft Fernando Acero Martín. Se permite la copia textual, la traducción y la distribución de este artículo entero en cualquier medio, a condición de que este aviso sea conservado. Se permite la cita. El autor no reclamará ninguna cantidad por el ejercicio de las dos autorizaciones anteriores. No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre."

Pues bien, creo que es el momento de cambiar un poco mi licencia a la vista del texto del Proyecto de Reforma de la LPI aprobado en el Congreso. Y si nos ceñimos a la realidad, también hay que decir que dicha aprobación no se hizo sin una buena dosis de indignación y malestar por parte de amplios sectores de la sociedad española, especialmente, al ver en vivo y en directo, la forma tan criticable en la que se desarrolló la polémica votación de un tema tan importante para todos.

Es una pena de la nueva LPI no considere que el autor es el único que debe y puede decidir sobre su obra y en especial, sobre la mejor forma de comercializarla y divulgarla, creando derechos "irrenunciables", que pueden ir claramente en contra de lo que desea para su obra y que por cierto, son una enorme traba a la cultura libre.

Y dicho así, no parece que en la LPI se considere la creación intelectual como un derecho humano, que es como debería ser considerada y con ello, respetar al autor y sus deseos para su obra por encima de cualquier otra consideración. Ya es triste, que me tenga que quebrar la cabeza para intentar proteger mi obra de una Ley que presuntamente está elaborada para defender mis derechos como autor. Señores yo quiero que mi obra se divulgue y se cite libremente y sin coste alguno para los que lo hacen.

De todos modos, eso solamente es un sentimiento personal, pero si me paro a analizar las consecuencias que puede tener este texto, solamente puedo decir que se me ponen los pelos de punta. Es una Ley diseñada para ir en contra de la corriente y en especial, en contra de los nuevos modelos de negocio que están apareciendo en la Red, que favorece más a las industrias que a los autores. No voy a insistir sobre ello puesto que otros muchos más doctos que yo han hecho este análisis antes y seguro que con mucho más tino que el que suscribe.

Cuando cambié mi licencia en febrero pasado, fue una modesta medida que para mi sorpresa tuvo una gran aceptación entre la audiencia y algunos autores que suelen poner sus obras a disposición del público con licencias libres, hicieron lo mismo que yo y modificaron sus licencias adecuadamente. Pues para todos ellos, aquí va una nueva propuesta, que espero que sea de su agrado. Ahora con Reforma de la LPI pasando sin problemas por el Congreso camino del Senado, le he dado una segunda lectura más detallada y me he parado a pensar en el Artículo 32.2, que dice lo siguiente:

“La puesta a disposición del público por parte de prestadores de servicios electrónicos de agregación de contenidos de fragmentos no significativos de contenidos, divulgados en publicaciones periódicas o en sitios Web de actualización periódica y que tengan una finalidad informativa, de creación de opinión pública o de entretenimiento, no requerirá autorización, sin perjuicio del derecho del editor o, en su caso, de otros titulares de derechos a percibir una compensación equitativa. Este derecho será irrenunciable y se hará efectivo a través de las entidades de gestión de los derechos de propiedad intelectual”.

Es evidente por lo tanto, que si queremos que nos enlacen y nos citen libremente y que nadie cobre por un trabajo que es nuestro, que ponemos a disposición de todos con licencias libres, es conveniente dejar bien claro que nuestro artículo, publicación, blog o página web, no tiene finalidad informativa, de creación de opinión pública, o de entretenimiento y pensando en ello, mi licencia queda como sigue:

"Copyleft Fernando Acero Martín. El presente artículo no tiene finalidad informativa, de creación de opinión pública o de entretenimiento. Tiene como finalidad principal, la enseñanza y la divulgación de experiencias, proyectos, pensamientos y conocimientos del autor. Se permite la copia textual, la traducción y la distribución de este artículo entero en cualquier medio, a condición de que este aviso sea conservado. Se permite la cita. El autor no reclamará ninguna cantidad por el ejercicio de las dos autorizaciones anteriores. No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre por el ejercicio de los dos derechos anteriores."

Asimismo, también recomiendo eliminar los blogs, o de nuestras páginas web, cualquier referencia, apartado o sección que introduzca la palabra "opinión", "entretenimiento", "noticias" o "información", especialmente, si la finalidad de nuestro blog o de nuestra página web, no es principalmente el informar, crear opinión pública o entretener, evitando así, cualquier confusión o ambigüedad a la hora de considerar por parte de terceros el el carácter del contenido de nuestro blog o página web.



"Copyleft Fernando Acero Martín. El presente artículo no tiene finalidad informativa, de creación de opinión pública o de entretenimiento. Tiene como finalidad principal, la enseñanza y la divulgación de experiencias, proyectos, pensamientos y conocimientos del autor. Se permite la copia textual, la traducción y la distribución de este artículo entero en cualquier medio, a condición de que este aviso sea conservado. Se permite la cita. El autor no reclamará ninguna cantidad por el ejercicio de las dos autorizaciones anteriores. No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre por el ejercicio de los dos derechos anteriores."

"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."


Después de que mi ordenador portátil, un "Packard Bell modelo EASYNOTE BG46-T-001 Limited Edition" sufriera de molestos cuelgues aleatorios, descubrí que tenía problemas con su módulo de memoria RAM de 4 Gb. Tras sustituirlo, decidí que también era momento de cambiar de sistema operativo, que era una más que obsoleta Mandriva. La decisión inicial fue la de probar con una Kubuntu 14.04 Long Time Suport.

La elección de Kubuntu en lugar de Ubuntu ha venido por el simple hecho de que siempre he usado KDE con mis sistemas Linux, a excepción de con mi querido Linex, que siempre lo he tenido con Gnome. Evidentemente, la elección de una distribución LTS, es decir, con soporte extendido de cinco años, ha sido por comodidad. El portátil lo uso cuando no tengo otra opción, por ejemplo, cuando tengo que hacer algo fuera de casa y salvo casos muy especiales, como cursos y otros eventos en los que hay desarrollo y programación por medio, el 80% de las veces lo uso para leer el correo, navegar por Internet y escribir texto más cómodamente. El tener la oportunidad de no tener que reinstalar el sistema operativo cada dos años más o menos, pero sin renunciar a que el sistema esté adecuadamente actualizado, me parecía una opción interesante y me proporcionaba cierta tranquilidad, por lo que una distribución LTS era la opción ideal.

Ante un cambio de sistema operativo siempre se considera que será un cambio a mejor, pero también hay cierta incertidumbre sobre el funcionamiento de determinado hardware, sobre todo, cuando está especialmente diseñado para funcionar con Windows y ante la posibilidad de perder opciones o funcionalidades que antes estaban disponibles. La instalación de una nueva distribución en un equipo siembre es una aventura. Por ejemplo, el EASYNOTE tiene un curioso problema con la WebCam Webcam Chicony Sonix 213, cuando se usa con algunas distribuciones Linux y que que tiene la mala costumbre de mostrar las imágenes del revés, problema que logré solucionar en su momento, por lo que cabe la posibilidad que este sea un trabajo que habría que repetir.

La instalación básica de Kubuntu 14.04 es muy sencilla. Solamente hay que seleccionar el idioma, la zona horaria, el particionado del disco y los datos de usuario. Tras introducir estos datos, el sistema se instala en unos 20 minutos y si se ha seleccionado la opción correspondiente durante la instalación, se conectará a Internet y se actualizará antes de acabar, más sencillo imposible,

He de decir que Kubuntu 14.04 me ha gustado mucho y también es cierto, que con esta distribución he ganado algunas cosas interesantes. Por ejemplo, ahora dispongo de cifrado de la partición /home, lo que aparece como opción durante la instalación cuando se introduce el nombre y la contraseña del usuario, o que permite que mis datos estén razonablemente a salvo de miradas indiscretas y de la manipulación en caso de robo, pérdida, o acceso no autorizado al portátil. Anteriormente esto lo tenía que hacer mediante Truecrypt, que aunque es un programa que funciona muy bien, no es tan sencillo de usar como arrancar el sistema introducir la contraseña y olvidarse. Por cierto, por si hay problemas en el futuro con esta partición cifrada, es conveniente copiar y poner a buen recaudo la clave de cifrado que muestra el programa la primera vez que se arranca. En caso necesario, se puede usar el mandato ecryptfs-unwrap-passphrase, seguido de nuestra contraseña de usuario. Otra cosa que he ganado es el soporte USB para teléfonos móviles Android, pudiendo acceder sin problemas tanto a la memoria del teléfono como de su tarjeta de memoria MicroSD.

Durante la instalación realicé el particionado a mano y algo tuvo que pasar con la partición de swap, que aunque estaba presente como /dev/sda6, no estaba activada en el sistema. Activarla no ha sido un problema demasiado grave. Primero he usado el mandato sudo swapon -s, para ver si estaba activada, comprobando que no era así y solamente he tenido que hacer lo siguiente:

Mediante el mandato sudo fstab -l /dev/sda he obtenido el listado de todas las particiones del disco, la que nos interesa es la que tiene aparece como sistema Linux swap / Solaris, que en mi caso, como he dicho, es la /dev/sda6. Después he obtenido el UUID de la partición mediante el mandato sudo mkswap /dev/sda6, que era UUID=cf71ef3e-4532-4593-843b-jpklw4a13bff. Una vez obtenido este dato, solamente he tenido que modificar el fichero /etc/fstab/ como root mediante un editor de textos como gedit o vim, para que muestre lo siguiente:


# swap was on /dev/sda6 during installation
UUID=cf71ef3e-4532-4593-843b-jpklw4a13bff none            swap    sw              0

Con ello, ya tendremos la swap activada la próxima vez que arranquemos nuestra Ubuntu 14.04, pero si no queremos arrancar el sistema otra vez en ese momento, solamente tenemos que usar el mandato sudo swapon /dev/sda6 para activarla, seguido de sudo swapon -s /dev/sda6, para comprobar que está activada. Otra forma de obtener la UUID para el disco es usando el Editor de Particiones de Ubuntu. Tras seleccionar la partición swap, debemos pulsar el botón derecho del ratón y seleccionar la opción Propiedades en el menú que aparece, nos aparecerá una ventana con los datos de dicha partición y entre ellos encontraremos el UUID.

Sin embargo, este procedimiento desactiva la swap cifrada que se debería activar con el cifrado de la partición de usuario, pudiendo exponer información del usuario si se necesitase usar el espacio de la swap. La solución es seguir estos dos procedimientos de forma consecutiva:

a) No se monta la partición swap

b) Disk drive for dev/mapper/cryptswap 1 is not ready

Con el cambio de distribución también he ganado y mucho, con el soporte para la tarjeta WiFi de Qualcom Atheros AW-GE780 802.11bg Wireless Mini PCIe Card. El controlador que usaba con la Mandriva anterior era muy inestable y tenía tendencia a desconexiones, pérdidas de las DNS y molestos bloqueos ocasionales del sistema. Ahora, la conexión WiFi va como la seda y funciona sin problemas incluso tras muchas horas de conexión.

Una de las cosas que más me ha molestado tras la instalación, es que el Touchpad Synaptic PS/2 Pad, tiene problemas con el doble clic si se hace pulsando dos veces sobre el Touchpad. A pesar de haber tocado y retocado la configuración para controlar el comportamiento de este dispositivo, llegando incluso a bloquearse con algunas configuraciones, al final parece que es un poco "sordo" a la hora de reconocer un doble clic y sin importar los ajustes que se realicen en la configuración. La solución más rápida es relativamente sencilla, basta con usar el botón izquierdo del Touchpad, o alternativamente, pulsar la tecla Intro, una vez que se ha seleccionado lo que se desea.

Antes de la instalación tenía muchas incertidumbres con el uso de DNIe, pero he logrado hacer que funcione con esta distribución y sin demasiados problemas. Lo he usado para firmar correos, autenticarme con la página web de la AEAT y del 066 y para firmar documentos en formato Open Document Format con Libre Office. Para su configuración, he seguido paso a paso el tutorial de instalación del DNIe para Ubuntu 12.04, pero cuando tocaba compilar el módulo PKCS11 para el DNIe, lo que he hecho, es usar el paquete que hay disponible en la página oficial del DNI electrónico para la distribución Ubuntu 12.04.

A pesar de lo anterior, cuando he intentado usar la última versión de Sinadura con el DNIe, no he logrado que funcione por el momento. He modificado a mano el archivo /usr/local/sinadura/resources/preferences/preferences-sinadura-console.properties
para que apunte al módulo /usr/lib/libpkcs11-dnie.so, con el siguiente código:


Tarjeta criptografica=1; Certificado Software=0
preferencias.radioCertType.active=0
 
# dispositivo de firma hardware
# hardware.dispositive=/usr/lib/opensc/opensc-pkcs11.so
  hardware.dispositive=/usr/lib/libpkcs11-dnie.so

Pero cada vez que intento firmar algo, Sinadura siempre me responde: "No dispone de ningún driver instalado para el uso de tarjetas inteligentes.", por lo que lo tendré que ver este asunto más despacio. Creo que el problema puede estar que Sinadura espera encontrar los archivos en otro sitio, de hecho, tras compilar el móduloPKCS11 con Mandriva 2010.1, aparecía con el nombre opensc-pkcs11.so y estaba en el directorio opensc, pero cualquier cosa es posible.

Además de este problema con el DNIe, también he notado que esta versión de Sinadura es algo inestable, con Kubuntu 14.04 LTS, pero este problema es posible que se deba a que se me ha pasado algo por alto durante la configuración de Java. Hay que señalar, que con el paquete Openjdk 7u51, que es la versión por defecto que usa Kubuntu 14.04 LTS, ya tenía los mismos problemas, por lo que es posible que tenga que revisar la instalación de Java para estar seguro de que no se usan librerías que no se corresponden con la versión adecuada de Java. Hay un tutorial muy bueno sobre la configuración de Java en Ubuntu 14.04, que recomiendo leer detenidamente.

En relación con los lectores de tarjetas inteligentes, en este momento dispongo de dos. Uno es el C3PO LTC31 en su primera versión (carcasa de color azul), que es reconocido directamente por Kubuntu 14.04 LTS una vez que han sido instalados todos los paquetes necesarios. El segundo, es el lector Castles Technology Co., Ltd EZUSB PC/SC Smart Card Reader, que no he logrado hacer que funcione con la distribución Kubuntu 14.04.

También es cierto, que por falta de tiempo, me he limitado a instalar los controladores para Linux que proporciona el fabricante para este dispositivo (en la caja dice que es completamente compatible con Linux), por lo que será necesario ver este tema más despacio. Lo más probable es que sea un problema relacionado con los directorios en los que se instalan los archivos del controlador, o con la versiones de los paquetes que se están utilizando ya que dicho lector que me funciona sin problemas en otras distribuciones Linux, como la Mandriva 2010.1.

Realmente el hacer que funcione el lector de Castles es por simple curiosidad, ya que el lector de de la empresa C3PO es mucho más cómodo para usarlo con el portátil por ser más pequeño que el de Castles. Sin embargo, este dispositivo tiene un pequeño problema que debemos tener en cuenta cuando lo usemos y que a mí me costó tener que cambiar de DNIe. Antes de usarlo debemos saber que la luz verde de funcionamiento del dispositivo de C3PO no parpadea cuando el DNIe está siendo accedido por una aplicación y se enciende una luz roja, cuando está inactivo y es completamente seguro retirar el DNIe del lector.

Mi recomendación es no sacar el DNIe del lector mientras que no se encienda el led rojo del mismo del lector de C3PO. Para ello, hay que salir de la aplicación que está haciendo uso del DNIe y esperar unos segundos hasta que se encienda el led rojo. También debemos tener en cuenta, que el DNIe solamente puede atender a una aplicación a la vez, por lo que si abrimos al mismo tiempo varias aplicaciones que puedan hacer hacen uso de él, como el correo electrónico y el navegador, cuando cerremos una de ellas, la otra impedirá que se ponga en rojo el led que nos permitirá extraerlo sin problemas.

Sin embargo, tras instalar el DNIe comprobé que no podría firmar correos con openpgp con Thunderbird. Al parecer, gpg-agent no entregaba la contraseña correcta a openpgp para firmar el mensaje. En este punto no puedo decir si el problema estaba provocado por intentar reutilizar el archivo de configuración /home/usuario/.gnupg que tenía en la Mandriva enterior y que usaba algunas opciones incompatibles con la nueva versión de gpg, por una contraseña incorrecta o por un paquete pinentry inadecuado y que había instalado para trabajar con el DNIe.

Tras editar el archivo de configuración de gpg-agent, para que usase el módulo pinentry que tenía instalado en /usr/bin, comprobé que seguía sin funcionar, así para salir del paso y con la certeza de que el problema venía de la forma en la que gpg-agent pasaba la contraseña a gnupg, edité manualmente el archivo /home/usuario/.gnupg/gpg.conf y comenté con un símbolo "#" la línea "use-agent" del mismo. Con ello, ya pude enviar sin problemas correos firmados con con gnupg y con el DNIe.

Otra cosa que he comprobado, es que Kubuntu 14.04 LTS gestiona mucho mejor los recursos del sistema, con lo que se calienta menos y dura más la batería,que con la versión anterior de Mandriva. Este equipo dispone de dos botones táctiles que sirven para activar y desactivar la Wifi y el modo de funcionamiento de bajo consumo, lo que es muy útil cuando se está con baterías y se quiere alargar su funcionamiento. Dichos botones funcionan bien con esta versión, aunque en el caso de la luz del botón que controla la WiFi, se queda encendida o pagada, con independencia de la situación real de la tarjeta, por lo que es necesario recurrir al indicador de la conexión WiFi de la Barra de Tareas para comprobar su estado.

Otra cosa que he probado que funciona sin problemas, es la conexión Bluetooth que usa un adaptador RFCOM de Toshiba. Una vez vinculado el dispositivo que se desee, se pueden intercambiar archivos entre el ordenador y el teléfono, o se puede compartir una conexión de red sin cable con el teléfono, lo que he probado con un teléfono Samsung Galaxy S4. He de decir también que la integración del Bluetooth con el KDE es tan impecable como cómoda en esta distribución.

Después de revisar todo, desde el punto de vista del hardware, lo único que me queda por configurar es la WebCam, pero eso es algo que no me corre mucha prisa, ya que por comodidad suelo usar el móvil con el kit de manos libres para las videoconferencias y hangouts.

Sin embargo, puede que en este caso tenga más problemas que con Mandriva para hacer que funcione esta WebCam con Kubuntu 14.04. De primeras, aunque la reconoce perfectamente y carga el módulo uvcvideo sin problemas, cuando uso el mandato lsusb -d 04f2:b012 -v | grep "14 Video", el sistema me dice que no puede abrir el dispositivo:


Couldn't open device, some information will be missing
      bFunctionClass         14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video

No me cabe la menor duda de que la resolución de los problemas con la WebCam, del doble clic con el Touchpad, la configuración del lector de tarjetas de Castles y la activación de Sinadura para su uso con el DNIe, entrarán dentro de mis planes a corto plazo, pero cada cosa a su tiempo y sin muchos agobios. Pero también es cierto, que mientras que la WebCam no funcione, me ahorro el tener que taparla con cinta aislant. Asimismo, el tema del lector de Castles no corre mucha prisa ya que tengo otro que funciona perfectamente. Lo del tema de Sinadura, me corre más prisa, pero aunque por el momento no puedo firmar un documento PDF con Sinadura y la firma reconocida del DNIe, no tengo problemas para firmarlos con firma digital avanzada de la FNMT. A pesar del problema anterior con el uso del DNIe y Sinadura, en lo que se refiere al uso de la firma digital, creo que he ganado mucho con esta distribución, ya que por falta de un adecuado soporte por parte de la Administración, el DNIe nunca me funcionó con la Mandriva anterior y siempre tuve que recurrir a la firma avanzada de la FNMT cuando usaba el portátil.

ACTUALIZACIÓN 01MAY14

1) He solucionado el problema del lector EZ100 de Castles bajando la última versión de los controladores de la web del fabricante. Es un lector bastante bueno y que con los controladores nuevos, debería funcionar sin problemas con Linux. La URL de descarga es la siguiente:

http://www.casauto.com.tw/db/pictures/modules/PDT/PDT060207001/201181015...

2) También he solucionado el problema con la Web Cam, que por cierto en Ubuntu se visualiza la imagen correctamente y sin tener que parchear el controlador, la solución también ha sido muy sencilla. Desde Ekiga he seleccionado la secuencia de mandatos Editar | Preferencias | Vídeo | Dispositivos y en el cuadro de diálogo que aparece, he pulsado el botón Detectar dispositivos. En el cuadro de diálogo me aparece lo siguiente:

Dispositivo de entrada USB 2.0 1.3M UVC Web Cam (PTLIB/V4L2)
Tamaño 704x576
Formato PAL (Europa)
Canal 0

Curiosamente, a pesar de que funciona, si uso el mandato lsusb -d 04f2:b012 -v | grep "14 Video", el sistema me sigue diciendo que no puede abrir el dispositivo, por lo que parece que es el funcionamiento normal del mismo:


Couldn't open device, some information will be missing
      bFunctionClass         14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video

3) Lo del doble clic del Touchpad he comprobado que también me pasa con otras distribuciones virtualizadas mediante VirtualBox, por lo que no es un problema exclusivo de Ubuntu y como también me pasa con otros portátiles, por ejemplo, con un Toshiba en el trabajo, que usa otro touchpad, puede que sea un problema del KDE.

Dicho lo anterior, se puede decir que todo el hardware presente en el Packard Bell modelo EASYNOTE BG46-T-001 Limited Edition, funciona al 100% con Ubuntu 14.04, lo que desde mi punto de vista me ha facilitado mucho las cosas.

Lo que se está haciendo más de rogar es un problema de software, es decir,l tema de Sinadura. Desde el proyecto me han proporcionado una nueva versión del archivo sinaduraDesktop-3.3.3.jar para que Sinadura se adapte a la ubicación y el nombre del controlador del DNIe del paquete oficial para Ubuntu 12.04, pero no he logrado por el momento, ni con la inestimable y magnífica ayuda de los responsables del proyecto, que funcione adecuadamente todavía. También parece que hay algunos problemas con unas librerías que provocan una salida imprevista del programa en ciertas circunstancias:

/tmp/swtlib-32/libswt-atk-gtk-3655.so
/tmp/swtlib-32/libswt-pi.gtk-3655.so
/tmp/swtlib-32/libswt-gtk-3655.so

He configurado el sistema para que funcione con la última versión de Java 7 en lugar que con java-7-openjdk-i386, que es lo que instala Kubuntu por defecto. Partiendo de la base que Sinadura y el DNIe funcionan adecuadamente con Mandriva 2010.1 y una versión muy antigua de java-openjdk, es decir, sin necesidad de instalar Java 7, el problema no puede ser demasiado complicado, solamente que no hemos dado con la tecla adecuada.

El resultado tras cambiar el archivo sinaduraDesktop-3.3.3.jar, es que ahora Sinadura accede sin problemas al controlador del DNIe e intenta leer los certificados, pero luego no muestra pinetry para introducir el pin del mismo y devuelve (lo de la hora a la que estaba trabajando en el tema, es solamente es medida del vicio que tengo con estas cosas):

00:51:44 Se ha producido un error en la carga del certificado, es posible que el dispositivo no este configurado correctamente.

Afortunadamente tengo un fin de semana largo para investigar y probar.

ACTUALIZACIÓN 03MAY14

En relación con la instalación del DNIe, he encontrado este procedimiento en la Red, explicando paso a paso como instalar y compilar una versión de OpenscDNIe para nuestra distribución Ubuntu 14.04 LTS, pero desgraciadamente a mi no me ha funcionado:

Instalar DNIe electrónico en Ubuntu 14.04

El problema es que yo dispongo de un DNIe V2, que es de los últimos modelos que están entregando y esta versión de OpenSCDNIe no es compatible con él. El problema es que una vez que se introduce el PIN de acceso, el controlador no es capaz de entregar los certificados a la aplicación.

La solución si tenemos un DNIe V2, es usar los paquetes compilados para Ubuntu 12.04 que hay disponibles en la página web DNIelectrónico.es, o en la página web de la FNMT.

Asimismo, ya he logrado solucionar el problema con pgp-agent y pinentry, simplemente lo he vuelto a activar en el archivo /home/usuario/.gnupg/gpg.conf y he creado un archivo /home/usuario/.gnupg/gpg-agent.conf con el siguiente contenido:


pinentry-program /usr/bin/pinentry-qt4
no-grab
default-cache-ttl 300




"Copyleft Fernando Acero Martín. Se permite la copia textual, la traducción y la distribución de este artículo entero en cualquier medio, a condición de que este aviso sea conservado. Se permite la cita. El autor no reclamará ninguna cantidad por el ejercicio de las dos autorizaciones anteriores. No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre."

"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."





Parece que la comunidad de software libre en particular, y los usuarios de Internet en general, no ganan para sustos y preocupaciones en los últimos días. A fecha de hoy han aparecido problemas en la práctica totalidad de las tecnologías que se usan para hacer que las conexiones sean seguras en Internet y en especial, GnuTLS y OpenSSL. Pero también debemos recordar que hace unos años también hubo serios problemas de seguridad con SSH.

Como ya se ha escrito y hablado mucho sobre el fallo de OpenSSL y llego un poco tarde con mi artículo, solamente resumiré e intentaré aclarar algunas cosas y en la medida de lo posible, aprovecharé para actualizar algo la situación y recomendar algunas acciones prácticas.

Un poco de lo que sabemos

En relación al fallo de OpenSSL sabemos, entre otras cosas, lo siguiente:

a) Es un fallo que lleva algo más de dos años en el código de OpenSSL y convierte inseguras desde la versión 1.0.1 a la 1.0.1f, siendo la versión 1.0.1g, la que resuelve el problema en este momento. Por ser un programa ampliamente utilizado para asegurar las conexiones en Internet, ha afectado a una gran cantidad de servidores y conexiones seguras de todo tipo. Entre los servidores que han podido estar afectados, se han incluido en algunas listas los de Google, Yahoo, Facebook o Twitter, etc. Pero dada la marcada polémica suscitada con la publicación de las listas de servidores afectados y pensando en lo que nos puede pasar en el peor de los casos, lo más razonable es pensar que cualquier servidor ha sido afectado, incluido el de nuestro banco y tomar a la mayor brevedad las medidas que recomendaré más adelante.

b) Este fallo permite obtener todo el contenido de la memoria de un servidor en bloques de 64 kB y ello incluye, entre otras cosas jugosas, las claves privadas usadas para identificar el servidor y asegurar las conexiones SSL. Una vez obtenidas, es posible suplantar dicho servidor y actuar como MitM. Pero como he adelantado en la primera frase de este párrafo, también se puede extraer cualquier otra información que esté siendo procesada en el servidor en ese momento. Eso incluye los datos personales de los usuarios, o sus claves de acceso al servidor. Asimismo, es importante saber, que si un servidor afectado ha sido atacado explotando este fallo en SSL, puede que no quede ningún rastro en el mismo que demuestre que ello ha sido así.

Si tenemos en cuenta lo que hemos dicho en el punto anterior y lo que hemos dicho en este, es posible que algunos responsables de servidores que fueron afectados por el fallo, no lo reconozcan abiertamente por problemas de reputación, o simplemente, aunque estuvieron afectados y es un hecho evidente para ellos por la versión de OpenSSL que utilizaban, desconocen si han sido atacados, o las consecuencias del ataque, por lo que no alertan a sus usuarios. Por lo tanto, mi recomendación en este caso, es ponerse siempre en el peor caso posible y actuar en consecuencia.

c) Aunque el fallo afecta principalmente a servidores y conexiones VPN (Redes Privadas Virtuales), lo que incluye infinidad de servicios en la nube, también puede afectar a otros dispositivos de nuestro entorno que pueden usar OpenSSL para asegurar ciertas conexiones. Por ejemplo: smartphones, puntos de acceso WIFI, tablets, routers ADSL, switches configurables, Smart TV's, receptores de satélite, reproductores multimedia o dispositivos de almacenamiento masivo (NAS) con conexión a Internet, etc.

Recordemos que Android se basa en el kernel de Linux y que tanto Android como Linux, están disponibles en varios miles de millones de dispositivos en este momento. Sin embargo, en muchas ocasiones, como meros usuarios de la tecnología, no somos conscientes del software que usa realmente nuestro flamante dispositivo.

Aprovecho para traer a estas líneas, algo que ya se está comentando con cierta preocupación en algunos foros. La llegada del Internet de las cosas provocará que este problema se multiplique de forma exponencial y más, si los fabricantes de hardware no se conciencian de que la seguridad de sus dispositivos debe estar en el ciclo de vida de los mismos como una de sus prioridades fundamentales. El problema para los fabricantes que opten por fabricar equipos que exploten las enormes posibilidades del Internet de las cosas, es que el ciclo de vida para muchos de estos dispositivos de uso común puede ser extremadamente largo en relación a los ciclos de vida del software.

d) Aunque Robin Seggelmann, el desarrollador que introdujo el error en 2012, ha declarado y en varias ocasiones, que no lo hizo de forma deliberada y que la NSA no estaba detrás del fallo, posteriormente, la agencia de noticias Bloomberg ha anunciado que la NSA conocía el fallo desde sus orígenes y que lo estaba explotando activamente. Como no podía ser de otro modo, la NSA ha negado posteriormente que esa noticia fuera cierta, por lo que cada uno puede pensar lo que quiera al respecto.

e) Aunque todos los expertos en seguridad coinciden al decir que el error es muy grave y que Bruce Schneier incluso ha llegado a decir textualmente lo siguiente:"Catastrophic is the right word. On the scale of 1 to 10, this is an 11", lo cierto es que el NIST ha clasificado esta vulnerabilidad como de riesgo medio CVSS v2 Base Score: 5.0 (MEDIUM) (AV:N/AC:L/AU:N/C:P/I:N/A:N), lo que puede llevar a cierta polémica.

f) Después de descubrirse el fallo, aparecieron una serie de noticias relacionadas con la explotación del mismo, como la relacionada con el joven canadiense arrestado por usar dicha vulnerabilidad de forma efectiva con los servidores de Canada Revenue Agency (CRA) o la relacionada con la explotación con éxito de la vulnerabilidad contra los servidores de Yahoo mail. Pero ¿cómo se han podido detectar este tipo de ataques, cuando decimos que no deja rastro en un servidor?. Evidentemente al mismo tiempo que han aparecido los programas que explotan el problema, también han aparecido las contramedidas especializadas para detectarlo y minimizarlo. Por lo que si alguien usa algún exploit relacionado con HeartBleed contra un servidor, debe saber que puede ser cazado en el intento y que igualmente, puede tener que responder por ello.

También se ha comentado, en base a un ataque realizado con éxito poco después de desvelarse la vulnerabilidad, que para explotarla con éxito era necesario que los servidores hubieran sido arrancados inmediatamente antes del ataque, lo que es improbable que ocurra en un sistema en producción. Pero desde mi punto de vista, lo único que se logra si ataca un servidor cuando acaba de ser arrancado, es facilitar la localización en la memoria de la información relevante para el atacante, por ejemplo, la posición en memoria de los certificados digitales del servidor. Si algo está en la memoria del servidor, dadas las características del fallo y con independencia del momento en el que se realice el ataque, siempre estará disponible para un eventual atacante que tenga paciencia para localizarla.

Más recientemente se ha usado dicha vulnerabilidad para saltarse la seguridad de Redes Privadas Virtuales, lo que abre una nueva y preocupante dimensión al problema de Heartbleed.

También se ha comentado algo que es muy preocupante para muchos usuarios de la Red Tor, la existencia de nodos de dicha Red, teóricamente segura, que eran vulnerables a Heartbleed. Dicho descubrimiento ha provocado que los responsables de la Red Tor, comiencen a rechazarlos mediante la creación de una "black list" de los mismos. Sin embargo, ¿cómo se puede tener la seguridad en una red abierta, como es el caso de Tor, de que los nodos que estamos usando en determinado momento no están afectados?. ¿Quién garantiza que en un momento determinado no se introduzca de forma maliciosa un nodo vulnerable en la Red Tor con el objeto de monitorizar el tráfico e la Red Tor?. Ante esta situación, hay algunos que aconsejan alejarse de la Red Tor, o incluso de Internet, durante un tiempo, si es que se necesita de privacidad.

g) El que no se haya actualizado al día de la fecha está en grave riesgo y va con tiempo negativo. En este momento no paran de salir a la luz pruebas de concepto (PoC) y exploits relacionados con esta grave vulnerabilidad del OpenSSL. Esto hace que el riesgo crezca de forma exponencial con el tiempo para los más retrasados. Como están las cosas, un eventual atacante, incluso con pocos conocimientos sobre el tema, dispone de todo lo necesario para tener éxito en un ataque:


  1. Sabe que existe una vulnerabilidad.

  2. Dispone de herramientas para saber si una determinada página es vulnerable.

  3. Dispone de software para atacar de forma efectiva un servidor vulnerable.

Qué podemos hacer

Las acciones a tomar para protegernos dependerán de si tenemos un servidor, somos clientes de un servidor seguro (https), o si tenemos hardware afectado, por lo que revisaremos cada caso de forma individual.

a) Si tenemos un servidor seguro, las acciones son cuatro y han de ser inmediatas:


  1. Revocar nuestros certificados digitales del servidor.

  2. Instalar la nueva versión de OpenSSL, la 1.0.1g o superior.

  3. Solicitar e instalar nuevos certificados digitales.

  4. Solicitar a todos los usuarios del servidor que cambien sus contraseñas lo antes posible.

b) Si somos usuarios o clientes de servidores seguros, lo que me atrevo a decir que somos todos los que usamos Internet, la acción es única y también ha de ser inmediata. No es otra que cambiar todas las contraseñas que usamos normalmente para conectarnos a servidores seguros a través de Internet. Por ejemplo: redes sociales, correo electrónico, servicios bancarios, administración electrónica, etc.

Los usuarios también deben tener en cuenta dos cosas en relación a la actualización de sus contraseñas:


  1. Si quieren saber si un determinado servicio está afectado en la actualidad, pueden usar esta página de McAfee para comprobarlo. Evidentemente si el servidor todavía está afectado, no tiene mucho sentido cambiar nuestra contraseña, por lo que en este caso lo que debemos hacer es enviar un correo a su administrador indicándole que su página es vulnerable y no conectarnos a dicha página, ni cambiar nuestra contraseña, hasta que no lo solucionen adecuadamente. Si usamos nuestras contraseñas, o intentamos actualizar nuestras contraseñas en este momento sobre un servidor que todavía no ha sido actualizado, lo más probable es que sean robadas sin remedio.

  2. Si recibimos un correo electrónico indicando que debemos cambiar nuestras contraseña en determinado servicio (red social, banco, etc) y dicho correo viene con un enlace, debemos desconfiar y no usar dicho enlace para cambiar nuestras contraseñas. Lo más probable es que sea un ataque de phishing que usa una URL falsa y su intención es robarnos limpiamente la contraseña que introduzcamos. Si queremos conectarnos a una página segura o cambiar nuestras contraseñas de acceso a las mismas, lo que debemos hacer siempre es acceder directamente a la página escribiendo la URL (https) en el navegador. No debemos usar nunca un enlace recibido mediante un correo electrónico, aunque nos parezca legítimo y la página a la que accedemos a través de él nos parezca la correcta primera vista.

  3. También es muy sano, tras conectarnos a una web segura (https), que antes de introducir nuestras credenciales, es decir, nuestro nombre de usuario y contraseña, que comprobemos el certificado digital de dicha página, para ver que se corresponde con la página que esperamos y que es válido.

c) Si tenemos hardware que pueda estar afectado, el problema se complica y mucho por dos motivos principalmente. El primero, es que es difícil saber, sin la ayuda del fabricante del mismo, si nuestro hardware es vulnerable ante un determinado problema de seguridad, como es el caso del OpenSSL. El segundo, es que siempre dependemos para su actualización de nuestro smartphone, tablet, router, etc, y en la mayoría de los casos de forma secuencial en el tiempo, del fabricante del software origen del problema, en este caso OpenSSL, del fabricante del software que lo integra, por ejemplo Google, del fabricante del hardware que lo usa, por ejemplo Samsung, o incluso, del proveedor de servicios de Internet que lo comercializa (por ejemplo, una compañía telefónica, que en ocasiones personalizan el software). Esta absurda cadena alarga los tiempos de actualización de los dispositivos más de lo necesario y hace que una vulnerabilidad, por pequeña que sea, se pueda convertir en una pesadilla para los usuarios, en especial si afecta, como es el caso, a su información sensible, o le provoca molestas denegaciones de servicio.

En estos casos debemos hacer lo siguiente:

Si no está disponible, consultar al fabricante o al proveedor de servicios de Internet que lo comercializa, sobre la forma de protegernos hasta que esté disponible la actualización que corrija el problema.


  1. Consultar al fabricante del dispositivo, o al proveedor de servicios de Internet que lo comercializa, sobre el problema y preguntarle si hay disponible una actualización de seguridad para el mismo en ese momento.

  2. Si la hay y está disponible para nosotros, instalarla lo antes posible y siguiendo las indicaciones del fabricante del dispositivo.

Tanto Microsoft como Apple han manifestado que tanto los dispositivos basados en Windows Mobile, como en iOS y OSx, así como sus servicios web, no están afectados por el problema del OpenSSL.

En el caso de Android, los móviles más vulnerables al fallo de OpenSSL son los que tienen versiones 4.1 de este sistema operativo, aunque también es cierto, que algunas versiones de Android 2.4 Jelly Bean, que han sido personalizadas por fabricantes u operadores, también pueden ser vulnerables.

Incluso móviles que se han actualizado recientemente a Android KitKat 4.4 pueden estar afectadas por este fallo, por usar versiones de OpenSSL tan antiguas como la 1.0.1e. Sin embargo, aunque tengan instalado un OpenSSL afectado en un dispositivo Android, la posibilidad de explotación del fallo también depende de la configuración del móvil, por lo que lo mejor es usar la aplicación indicada anteriormente para comprobarlo.

De todos modos, si nuestro smartphone está afectado por el fallo, lo más recomendable es no usarlo para realizar conexiones seguras, o manejar información sensible, hasta que dispongamos de una actualización adecuada, lo que puede tardar bastante, si además de Google, dependemos del fabricante y/o del operador para hacerlo.

Existen algunas opciones para saber si nuestro smartphone está afectado por problemas con el SSL o con el TLS:

a) Apple (fallo en el TLS por goto fail).
b) Aplicación Android para comprobar el fallo de OpenSSL.

Pero esta seguridad en relación a los sistemas operativos de los smartphones es relativa. Aunque nuestro smartphone no se vea afectado por el problema de OpenSSL y esto es aplicable de forma indistinta a dispositivos Android, iOS, o Windows Mobile, eso no nos garantiza que no se haya utilizado para acceder a un servidor vulnerable. Por lo que debemos estar atentos a todas las actualizaciones de aplicaciones que se produzcan estos días en relación a este fallo de seguridad y si sabemos que una aplicación móvil ha sido afectada, ya sea por usar la librería afectada internamente, o por conectar con un servidor afectado, no debemos utilizarla hasta que se actualice la aplicación y/o el servidor del servicio y cuando todo esté en orden, deberemos cambiar la contraseña de acceso a dicho servicio lo antes posible.





"Copyleft Fernando Acero Martín. Se permite la copia textual, la traducción y la distribución de este artículo entero en cualquier medio, a condición de que este aviso sea conservado. Se permite la cita. El autor no reclamará ninguna cantidad por el ejercicio de las dos autorizaciones anteriores. No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre."


"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."

El grave fallo de seguridad en GnuTLS (y II)






En un artículo anterior ya hablamos del origen y de las consecuencias para la seguridad del fallo en la librería GnuTLS, ahora nos centraremos en la forma de solucionarlo y en las distintas estrategias en función de la situación en la que se encuentre nuestra distribución.

¿Qué es más seguro el software libre o el privativo?

Esta es una eterna pregunta eterna, que a lo largo de la historia, ha provocado encarnizadas discusiones en los foros más diversos, pero para no entrar en la polémica, no consideraremos el hecho de que en el caso del software libre el código fuente está disponible. Creo que es evidente, tras los sonados fallos de seguridad recientes, que la disponibilidad del código fuente no ha ayudado mucho a evitarlos, es más, considero que sin herramientas automatizadas como las que proporciona Coverity, es complicado auditar miles de líneas de código fuente. Por ello creo que hay que avanzar en este tipo de herramientas y al mismo tiempo, mejorar las pruebas que se realizan del código.

Si atendemos a las estadísticas de fallos detectados en el código fuente, como índice de la calidad y/o seguridad del software, creo que la mejor referencia es el Informe anual de Coverity 2013 [PDF]. Si tenemos en cuenta que el estándar de la industria del software para considerar que un programa tiene calidad suficiente, es de menos de 1 fallo por cada 1.000 líneas de código, hemos de decir, que tanto el software libre, como el software privativo, pasan ampliamente el corte, con una densidad media de 0,59 para el caso del software libre y de 0,72 para el software privativo, como vemos, unos datos relativamente similares y mejores que el estándar. Aunque hay proyectos de software libre, como Python, que destacan de forma notable sobre la media, con una densidad de fallos de solamente 0,005.

Sin embargo, creo que es justo decir que las empresas de software privativo han hecho un gran esfuerzo en los últimos años, al pasar de una densidad de 20 a 30 errores por cada 1.000 líneas de código que presentaban 2006, a los muy aceptables 0,72 de media de la actualidad. Hay que destacar, que esas mismas fechas el software libre presentaba una densidad de solamente 0.434 errores.

Pero ¿cuál es el motivo por el que ha aumentado el índice de fallos en el software libre y ha disminuido tan notablemente el del software privativo?. Creo que el problema está en el aumento de las líneas de código de los proyectos, algo que ocurre casi inevitablemente al madurar los mismos y aumentar las prestaciones de librerías y programas. El software libre, por su modelo de desarrollo distribuido y mayores dificultades para auditar el software, es muy propenso a que aumenten los fallos cuando aumentan las líneas de código si no se establecen estrategias adecuadas para evitarlo.

Lo que sí es cierto, es que normalmente, cuando son detectados, los fallos se reparan más rápidamente en el caso del software libre, algo que también se refleja en el informe. Este hecho fue evidente con los fallos de seguridad detectados durante el concurso Pwn2own, durante el que fueron hackeados los principales navegadores del mercado. En este caso, con un concurso que se llevó a cabo entre los días 12 y 13 de marzo de 2014, la versión de Mozilla Firefox que solucionaba los problemas detectados, la 28.0, ya se podía descargar de los servidores de Mozilla el día 18 de Marzo.

Pero este no es un caso aislado, esta rapidez en la resolución de fallos también fue detectada por Coverity en ediciones anteriores del informe, destacando el caso de Amanda (software libre para realizar copias de seguridad), que tras arrojar el mayor índice de fallos cuando se analizó el código, la comunidad de desarrolladores de dicha aplicación respondió rápidamente y en menos de una semana, se corrigieron todos los errores, pasando a ser el proyecto de software libre con menos errores de todos los revisados. Por lo tanto, si consideramos el tiempo de reacción dentro de la métrica, podemos decir que el software libre también es más seguro que el privativo.

Pero ¿qué ocurrió con GnuTLS?. Según los datos de Coverity, GnuTLS se comenzó a analizar con su herramienta Coverity Scan en abril de 2011, algo que se hizo regularmente hasta junio de 2011, pero pasó mucho tiempo sin auditorías, hasta la última, que se realizó el pasado día 17 de abril de 2014, posiblemente con un afán de mejorar el código tras el fallo "goto result". Los datos de esta auditoría son estos:

Último análisis: 17 de abril de 2014
Líneas de código analizadas: 150.350
Densidad cada 1.000 líneas: 0,55

Cambios desde la comprobación del 10 de junio de 2011
Nuevos fallos detectados 73
Eliminados 366

Fallos en la versión actual:
Totales: 487
Pendientes: 82
Solucionados: 403

Como se puede ver, no son unos datos malos, de hecho, son mejores que la media del privativo del informe de Coverity, que para los proyectos en c y c++. de entre 100.000 y 500.000 líneas de código muestran una densidad de errores 0,81, pero peores para el software libre, que para ese mismo número de líneas, muestra una densidad de 0,50.

Aunque es complicado ver si los fallos remanentes de GnuTLS en este momento, como ocurrió con el "goto result", son críticos o no para la funcionalidad y/o seguridad de la librería. De todos modos, creo que es sano realizar este tipo de auditorías del código de forma sistemática y evitar, como ocurrió con GnuTLS, el pasar varios años sin auditarlo de ninguna forma, puesto que como he indicado anteriormente, es complicado detectar fallos cuando crecen el número de líneas, o hay muchos desarrolladores en el proyecto.

Estrategia de actualización

Una vez que hemos tomado conciencia de que nuestro software es vulnerable, las dos vías son actualizar o parchear. Si nuestra distribución continua manteniendo soporte, la solución es sencilla, esperar que aparezca el paquete .dbm o .rpm correspondiente en los repositorios y actualizarlo lo antes posible. En este sentido, es muy recomendable considerar a la hora de elegir una distribución, el hacerlo sobre una LTS (Long Time Support), que como Ubuntu 14.04 LTS "Trusty Tahr", que está previsto que tenga 5 años de soporte.

Si nuestra distribución ya no tiene soporte, lo más recomendable es actualizarse a una que sí lo tenga. Si hemos tenido la precaución de tener una partición /home, dicho proceso no debe ser demasiado traumático ya que nuestros datos no se deberían ver afectados si tenemos cuidado durante la instalación y elegimos las opciones correctas.

Sin embargo, puede que no nos interese o no podamos, por los motivos que sea, el proceder a la actualización de toda la distribución, en ese caso la única opción pasa por actualizar el paquete o modificarlo adecuadamente, opción que no tienen los usuarios de software privativo cuando pierden el soporte, ya que para actualizarlo/compilarlo o para parcherarlo en estas circunstancias, es imprescindible contar con el código fuente del mismo.

Podemos pensar que para actualizarlo/compilarlo, nos bastará con bajarnos la última versión de la librería del repositorio correspondiente y usar la secuencia de mandatos:


./configure
make
make check
make install

Dicha secuencia es posible que nos sirva en muchos casos, puede que en la gran mayoría, pero tiene sus riesgos que debemos evaluar. Por ejemplo, si cogemos la última versión de OpenSSL, es decir, la 1.0.1g y usamos los mandatos anteriores para instalarla en una Mandriva 2010 (Mandriva usa la OpenSSL 0.9.8 de 25 Mar 2009 y no está afectada por el fallo "Heartbleed", pero la usaremos a modo de ejemplo de lo que estamos explicando), lo que lograremos realmente, es romper el sistema de paquetes que dependen de esta librería y con ello, no podremos instalar o desinstalar ningún paquete .rpm, lo que podemos considerar un desastre que nos puede llevar a tener que instalar todo el software, con todo lo que implica si nuestra distribución está muy "tocada" y no se han usado paquetes .rpm o .deb, para instalar todo lo que necesitamos o hemos modificado en ella y mantenemos copia de los mismos.

Hay que tener en cuenta, que cuantas más dependencias, más riesgos se corren y hay dos tipos de dependencias, las que tiene el programa o librerías para poder ser complilada y las de los otros paquetes que dependen de ella.

Por ejemplo, si intento compilar la última versión estable de la librería GnuTLS, la 3.2.9 en una Mandriva 2010, con mi configuración actual, compruebo que la única dependencia que tengo es una librería criptográfica denominada Nettle, en su versión 2.7.1. Nettle se añadió como dependencia a partir de la versión 2.10.5 de GnuTLS. Sin embargo, si yo intento desinstalar GnuTLS en Mandriva 2010 mediante su gestor de paquetes, el sistema me avisa de que hay 650 paquetes que dependen de GnuTLS, por lo que un poco de cautela no nos vendrá mal antes de decidirnos por instalar directamente la última versión de GnuTLS.

Podemos pensar que es tan sencillo como compilar e instalar Nettle y/o Gmplib, que también necesitaremos para compilar las últimas versiones de GnuTLS, si no la tenemos instalada. Pero también hay que tener en cuenta, que todo lo que instalemos puede tener otras dependencias, que pueden ser versiones más recientes de librerías existentes o de herramientas de compilación o nuevas versiones, por lo que cuanto menos dependencias generemos en nuestra actualización mejor que mejor.

En el caso de Nettle, cuando lo intento compilar solamente me lanza una dependencia, y aunque solamente se usa para las pruebas del código, es la OpenSSL 1.0.1g, que como hemos dicho, es incompatible con el sistema de paquetes .rpm de la Mandriva 2010, aunque también es cierto, que no es frecuente que una actualización a una versión más moderna de una librería genere este tipo de incompatibilidades en Linux.

En este punto hay dos opciones:

a) Tomar el código fuente de la misma versión de la librería GnuTLS que tenemos instalada en nuestro sistema, que en el caso de Mandriva 2010, es la 2.8.4, e intentar parchearla. Para ello, la tendremos que comparar con el código final del archivo /lib/x509/verify.c y con que es el parche que han generado los desarrolladores para resolver el problema, para ver si lo podemos hacer sin grandes problemas.

Para ello accedemos al ftp del proyecto y nos bajamos dicha versión, junto con su archivo de firma. Alternativamente nos podemos bajar el .rpm con el código fuente de Mandriva.

Ahora, lo primero que tenemos que hacer, es comprobar la firma. Para ello, con gpg (GnuPG) instalado en nuestro sistema, importaremos al anillo de confianza la clave de Simón, que es uno de los desarrolladores de GnuTLS y seguidamente usaremos el siguiente mandato desde el directorio en el que se encuentran los dos archivos anteriores:


gpg --verify gnutls-2.8.4.tar.bz2.sig
gpg: Firmado el vie 18 sep 2009 10:51:45 CEST usando clave RSA ID B565716F
gpg: Firma correcta de "Simon Josefsson "
gpg:                 alias "Simon Josefsson "

Una vez comprobada la firma mediante el mensaje "Firma correcta de "Simon Josefsson "", lo descomprimiremos mediante el mandato:

tar -xjvf gnutls-2.8.4.tar.bz2

Seguidamente analizaremos si es posible parchear el archivo sin problemas. Como premisa general consideraremos que el archivo no se podrá parchear directamente mediante el mandato patch de Linux, por lo que deberemos hacerlo a mano. Como sabemos, el archivo fuente del problema es "/lib/x509/verify.c", así que nos toca compararlo con el parche y el código fuente de la última versión disponible, en lo que al problema se refiere. Como veremos, la función "check_if_ca", se puede parchear sin problemas, ya que el código es casi idéntico a la de la versión anterior a la 3.2.9 de GnuTLS. En el caso de la función "_gnutls_verify_certificate2", veremos que aunque se puede parchear, las cosas se complican algo más, sobre todo, si no se tiene mucha experiencia de programación en C.

b) Por lo tanto, tendremos que recurrir a la segunda opción, es decir, instalar una versión de la librería más moderna que la que estamos usando.

El proceso de elección se basa en ir buscando en las distintas versiones disponibles de GnuTLS, hasta encontrar una que se parezca más a lo que tenemos que modificar, pero que no suponga un problema de dependencias. Por ejemplo, podemos probar con la ultima versión de GnuTLS que no necesitaba Nettle, es decir la 2.10.5. Si queremos conocer las diferencias entre las distintas versiones de GnuTLS, podemos recurrir a la Wikipedia.

En este caso, y para ahorrar trabajo a los lectores, una vez bajado el código fuente de esta versión y comprobada la firma, el parche que propongo aplicar para solucionar el problema de GnuTLS es este que muestro seguidamente. A pesar de esto, recomiendo echar un vistazo al código del archivo "verify.c" resultante tras aplicar el parche y compararlo con el de la versión 3.2.9 GnuTLS. Como se podrá comprobar, mi parche se parece mucho al creado para la versión 3.2.9 por el desarrollador Nikos Mavrogiannopoulos, que por otra parte, es el código en el que se basa el mismo, a excepción de la inicialización a cero de la variable "ret", que no aparece en el código de la versión 3.2.9:


--- verify.c 2010-12-06 14:04:44.000000000 +0100
+++ verify.nuevo 2014-03-09 18:24:37.489058578 +0100
@@ -116,7 +116,7 @@
   if (result < 0)
     {
       gnutls_assert ();
-      goto cleanup;
+      goto fail;
     }
 
   result =
@@ -125,7 +125,7 @@
   if (result < 0)
     {
       gnutls_assert ();
-      goto cleanup;
+      goto fail;
     }
 
   result =
@@ -133,7 +133,7 @@
   if (result < 0)
     {
       gnutls_assert ();
-      goto cleanup;
+      goto fail;
     }
 
   result =
@@ -141,7 +141,7 @@
   if (result < 0)
     {
       gnutls_assert ();
-      goto cleanup;
+      goto fail;
     }
 
   /* If the subject certificate is the same as the issuer
@@ -181,6 +181,7 @@
   else
     gnutls_assert ();
 
+fail:
   result = 0;
 
 cleanup:
@@ -274,7 +275,7 @@
   gnutls_datum_t cert_signed_data = { NULL, 0 };
   gnutls_datum_t cert_signature = { NULL, 0 };
   gnutls_x509_crt_t issuer = NULL;
-  int ret, issuer_version, result;
+  int ret = 0, issuer_version, result=0;
 
   if (output)
     *output = 0;
@@ -307,7 +308,7 @@
   if (issuer_version < 0)
     {
       gnutls_assert ();
-      return issuer_version;
+      return 0;
     }
 
   if (!(flags & GNUTLS_VERIFY_DISABLE_CA_SIGN) &&
@@ -328,6 +329,7 @@
   if (result < 0)
     {
       gnutls_assert ();
+      result = 0;
       goto cleanup;
     }
 
@@ -336,6 +338,7 @@
   if (result < 0)
     {
       gnutls_assert ();
+      result = 0;
       goto cleanup;
     }
 

Para aplicarlo, nos bastará con crear un archivo denominado "verify.patch", con el contenido anterior y tras copiarlo al directorio en el que se encuentra "/lib/x509/verify.c", ejecutaremos el mandato:

patch < verify.patch

Una vez aplicado el parche, podremos proceder a compilar la librería, para ello, usaremos la siguiente secuencia de mandatos:


./configure --prefix=/usr --with-default-trust-store-file=/etc/ssl/ca-bundle.crt / 
--enable-gtk-doc
make
make check

Estos mandatos y en especial "configure", nos informarán si todo está bien para compilar y si la compilación tiene éxito. Si nos aparece algún error en este proceso, lo más probable es que sea un problema de dependencias que deberemos resolver adecuadamente. He de decir, que mi distribución está configurada como estación de trabajo de desarrollo, por lo que la mayoría de los paquetes necesarios para poder configurar y compilar un programa ya estaban instalados y también es cierto que estos paquetes están bastante actualizados, por lo que estos tres mandatos se ejecutaron sin problemas.

Ahora, si todo está bien, estamos en disposición para instalar nuestra librería y la documentación asociada, lo que podemos hacer con los mandatos:


make install
make -C doc/reference install-data-local
ldconfig

Sin embargo, el mandato "make install", aunque parece que es la opción más usada, tiene sus riesgos, sobre todo, si luego no está disponible la operación o regla "unistall" para "make", que nos permitiría eliminar el código que se acaba de instalar en caso de problemas.

Para solucionarlo de forma elegante yo suelo usar el mandato checkinstall. Que tras la configuración, compilación del programa, comprobación del programa e introducción de unos datos que nos pide, nos permite generar un paquete .rpm o .deb, según la distribución que usemos, que será más sencillo de instalar y desinstalar en caso necesario. En este caso, dadas las enormes dependencias de GnuTLS en Mandriva 2010, no se recomienda desinstalar directamente el .rpm de la versión anterior antes de usar "make install", lo que hace mucho más recomendable el hacerlo mediante un paquete .rpm, como si fuera una actualización más del sistema.

NOTA: Si hacemos varias pruebas de compilación antes de instalar, hay que seguir el procedimiento anterior en todas ellas y entre prueba y prueba, es necesario eliminar los archivos de la compilación anterior mediante el mandato "make clean".

Para los más osados, les diré que tras instalar Nettle 2.7.1 y obviando instalar la última versión de SSL, pude compilar e instalar sin problemas la versión 3.2.9 de GnuTLS, que por otra parte, funciona también sin problemas y con ello, de paso, tengo Nettle, que aunque no era necesaria antes de la instalación de GnuTLS, es una librería, que junto con gmplib, que es una librería de aritmética de precisión variable y que ya estaba instalada en mi sistema, son más que interesantes para trastear cosas relacionadas con la criptografía.

Finalmente, ya que estamos, podemos actualizar el archivo /etc/ssl/ca-bundle.crt, que contiene los certificados de las CA en el formato adecuado, para actualizarlo, podemos seguir este procedimiento, que nos garantizará que tenemos los certificados adecuados y que se han eliminado los que ya no son necesarios o los que son inseguros, por lo que recomiendo usarlo de vez en cuando.

Con este artículo he intentado explicar algo de lo que posiblemente se habla en muchos sitios y que es inherente al software libre, la posibilidad de adaptarlo a nuestras necesidades, pero también es cierto, es que no se hace en muchas ocasiones, principalmente por ser una opción de último recurso. Pero como hemos podido ver, es posible y relativamente accesible, incluso para personas que no tienen sólidos conocimientos de programación, si tienen acceso al código que se ha modificado para solucionar el problema.

Evidentemente este procedimiento será más complicado o incluso, imposible, cuanto más se alargue la línea temporal, básicamente por el problema las dependencias directas e inversas del paquete que tengamos que actualizar. Evidentemente, cuanto más cerca se encuentre la versión del paquete a actualizar a la versión que usamos en nuestro sistema, menos problemas tendremos. Por ello, he considerado interesante hablar del procedimiento a seguir para parchear un fuente e instalarlo en nuestro sistema sin demasiados riesgos y hablando de los posibles problemas que se nos pueden presentar en el proceso.

Del mismo modo, cuanto más sepamos de programación, más sencillo se nos hará modificar los fuentes y en caso necesario, incluso podremos hacer un parche a nuestra medida, si el que hay disponible no se adapta demasiado a nuestra versión del programa, lo que puede ser un buen paso previo para participar activamente en proyectos de programación en el futuro.

Complicado o no, hemos demostrado que es posible hacerlo y todo hay que decirlo, es una opción que no está disponible, ni siquiera como un último recurso, a los usuarios de software privativo, que tendrán que optar por pagar una nueva licencia y actualizarse a una nueva versión, aunque ello les suponga incluso, la necesidad de actualizar todo o parte de su hardware, o perder la posibilidad de usar determinado software que era de su interés. Evidentemente, si somos una empresa tenemos un serio problema de este tipo y no sabemos como solucionarlo, otra opción sería contratar los servicios de alguien que sepa hacerlo.

Desde mi punto de vista, el software libre, además de más seguro en este momento, nos proporciona opciones y oportunidades que deberíamos valorar seriamente desde el principio.









"Copyleft Fernando Acero Martín. Se permite la copia textual, la traducción y la distribución de este artículo entero en cualquier medio, a condición de que este aviso sea conservado. Se permite la cita. El autor no reclamará ninguna cantidad por el ejercicio de las dos autorizaciones anteriores. No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre."


"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."




Cuando he intentando configurar un ordenador con un Linux más bien antiguo (2010) para que funcione el DNIe, me he encontrado un problema con los demonios HALDAEMON (en algunos sistemas HALD) y PCSCD. El primero se encarga de mantener una base de datos con los dispositivos conectados al sistema en tiempo real. El demonio HALDAEMON conecta con el sistema D-bus de mensajes, para proporcionar una API (Application Programing Interface) que pueden usar los distintos programas para encontrar, controlar e invocar operaciones sobre los dispositivos conectados al sistema. El segundo es el demonio que se encarga de la gestión de las tarjetas inteligentes, tales como nuestro DNIe.

Después de un montón de intentos y comprobaciones, que requerían cada una de ellas un tedioso reinicio del sistema y un cambio de configuración, descubro que el demonio PCSCD no arrancaba adecuadamente.Tras verificar mediante el mandato siguiente, que el demonio arrancaba y funcionaba sin problemas de forma manual, pero fallaba al pararlo:

service pcscd restart

Decidí reiniciar de nuevo el sistema, pero sin tocar ninguna configuración y procedí a comprobar el estado del demonio mediante el mandato:

service pcscd status

A lo que el sistema me respondió con este preocupante mensaje:

pcscd dead but subsys locked

Lo que es un indicativo claro de que hay un problema con el arranque del demonio PCSCD, pero como veremos más adelante, este problema es un daño colateral de una secuencia de arranque no correcta para los demonios del sistema. El error sería comenzar a trastear con PCSCD sin hacer algún diagnóstico adicional de las causas del problema Para ello, decidí revisar el contenido del archivo /var/log/messages mediante el mandato:

less /var/log/messages/ | grep pcscd

Gracias a ello, localicé varias líneas en dicho archivo con el siguiente contenido relacionado con PCSCD y HALDAEMON, que creo que es bastante revelador:


Mar 03 21:08:58 localhost pcscd: 
hotplug_libhal.c:562:HPRegisterForHotplugEvents() 
Could not initialise connection to hald.
Mar 03 21:08:58 localhost pcscd: 
hotplug_libhal.c:563:HPRegisterForHotplugEvents() 
Normally this means the HAL daemon (hald)

Ahora parece que el problema está claro. El demonio PCSCD arranca antes que el demonio HALDAEMON, algo que debería ser al contrario para que todo funcionase correctamente. Como es lógico, primero hay que detectar el lector de tarjetas y luego la inclusión de la tarjeta en el lector y para que ello funcione así, HALDAEMON (HALD) tiene que arrancar por completo antes que PCSCD.

Una solución a este problema sería añadir un retardo, por ejemplo de 5 segundos, al arranque del demonio PCSCD. Para ello, habría que editar el archivo /etc/init.d/pcscd y modificar la sección start() añadiendo una línea sleep 5 de forma que aparezca así:


start() {
        gprintf "Starting smart card daemon: "
        sleep 5
        daemon pcscd
        RETVAL=$?
        echo
        [ $RETVAL -eq 0 ] && touch /var/lock/subsys/pcscd
        return $RETVAL
}

Y luego volver a arrancar el demonio con el mandato:

service pcscd restart

Pero sinceramente, aunque funciona, no es la solución más elegante y aunque lo probé en su momento, dicha solución no nos aporta nada al debido conocimiento que deberíamos tener de nuestro querido sistema Linux.

Como hemos dicho anteriormente, el problema es que PCSCD arranca antes que HALDAEMON, por lo que debemos comprobar algunas cosas en nuestro sistema en relación al proceso de arranque y las prioridades de los distintos demonios.

Si usamos cd /etc/rc3.d, accederemos al directorio que controla el arranque de los demonios en el runlevel 3 y desde dicho directorio, podemos usar el mandato siguiente, para comprobar las prioridades de arranque de estos dos demonios:


ls -1 /etc/rc3.d/S*{pcscd,haldaemon}
/etc/rc3.d/S12pcscd@
/etc/rc3.d/S54haldaemon@

El resultado significa que el demonio PCSCD arranca ("S" de start) con la prioridad 12, es decir, al principio del proceso. Sin embargo, HALDAEMON arranca con la prioridad 54, es decir, a mediados del proceso de arranque, que es precisamente lo que no nos conviene. Algo curioso, cuando he instalado ambos demonios con sus paquetes RPM respectivos y la configuración estándar de los mismos debería contemplar precisamente lo contrario.

La solución es modificar la prioridad de arranque. En nuestro caso podemos dejar que el demonio HALDAEMON siga arrancando más o menos a la mitad del proceso, pero PCSCD debemos configurarlo para que arranque al final del proceso de inicio del sistema. ¿Cómo lo hacemos?. Bueno, es relativamente sencillo si sabemos en la forma en la que funcionan los scripts de inicio de los demonios que aparecen en /etc/init.d. Comenzaremos por editar el archivo /etc/init.d/pcscd. En dicho archivo encontraremos una línea comentada (comienza por la almohadilla #) con el siguiente contenido:

# chkconfig: 2345 12 88

¿Qué significa esta línea?. Aunque esté comentada con la almohadilla delante, contiene la información necesaria para que se configure adecuadamente y con las prioridades necesarias en los distintos runlevel del sistema. En este caso estamos indicando al mandato chkconfig que PCSCD se activará en los runlevel 2, 3, 4 y 5, con la prioridad de arranque 12 y con la prioridad de apagado 88, en todos ellos.

Por ejemplo, si queremos que este demonio arranque casi al final del proceso de inicio del sistema, debemos cambiar el número 12, que es la fuente de nuestros problemas, por otro número mayor, por ejemplo 91. En todo caso, el número para PCSCD deberá ser ligeramente mayor que 54, que es la prioridad de arranque de HALDAEMON, ya que además de arrancar más tarde, debemos dar tiempo a que arranque el demonio HALDAEMON con normalidad antes de iniciar el arranque del demonio PCSCD. Así que la línea anterior del archivo /etc/init.d/pcscd, debería quedar de la forma siguiente:

# chkconfig: 2345 91 88

Hecho esto, usaremos el mandato siguiente, para eliminar los enlaces simbólicos a este demonio en los distintos runlevel en los que se encuentra configurado:

/sbin/chkconfig --del pcscd

Después usaremos el mandato siguiente, para volver a crear dichos enlaces simbólicos, pero en esta ocasión, con la prioridad adecuada:

/sbin/chkconfig --add pcscd

De esta forma, si volvemos al runlevel 3, mediante cd /etc/rc3.d/ y usamos el mandato siguiente:


ls -1 /etc/rc3.d/S*{pcscd,haldaemon}
/etc/rc3.d/S54haldaemon@
/etc/rc3.d/S91pcscd@

Comprobaremos que el orden de arranque de ambos demonios es ya es el adecuado y que están lo suficientemente separados, como para permitir el normal arranque de HALDAEMON antes de que se inicie el de PCSCD. Ahora si reiniciamos el sistema mediante el mandato reboot, en teoría, deberían arrancar sin problemas ambos demonios. Lo que podemos comprobar mediante el mandato:


service pcscd status
pcscd (pid 26480) está activo...

Que nos dice que el demonio está activo y nos informa del PID (Process ID) del mismo.

Como podemos ver, el mandato chkconfig es de mucha utilidad a la hora de controlar los servicios (demonios) que deben arrancar en los distintos runlevel del sistema, de esta forma, si usamos el mandato siguiente:


chkconfig --list | grep pcscd
pcscd           0:desactivado   1:desactivado   2:activo        3:activo        4:activo        5:activo        6:desactivado       7:desactivado

Podemos ver, que como aparecía en la configuración de chkconfig que aparecía en el archivo /etc/init.d/pcscd, este demonio se encuentra activado, ahora con la prioridad de arranque 91 y de apagado 88 en los runlevel del sistema con números 2, 3, 4 y 5 (/etc/rc2.d, /etc/rc3.d, /etc/rc4.d y /etc/rc5.d) .

En este punto aclararemos que los runlevel 0, 1, 6 y S están reservados para los siguientes usos:

0 - Parada
1 - Monousuario para mantenimiento del sistema
6 - Rearranque
S - Monousuario con la partición de root montada únicamente, con el objeto de comprobar reparar el sistema de archivos en caso necesario.

En algunos sistemas, como RedHat, el runlevel S es el mismo que el runlevel 1.

Los restantes runlevel son lo siguientes:

2- Multiusuario sin soporte de red.
3- Multiusuario con soporte de red. (Inicia el sistema normalmente)
4- Multiusuario con soporte de red. (Igual que el runlevel 3).
5- Multiusuario gráfico (X11). (Similar al nivel de ejecución 3 + display manager.)

Estos son los runlevel heredados de Unix SystemV, sin embargo, en la actualidad se pueden definir otros runlevel con los números 7, 8 y 9, para completar un total de 10.

Hay que señalar, que es posible que los problemas que experimentan algunos los usuarios a la hora de configurar el DNIe en sus sistemas, tengan un origen similar, que además, no es muy evidente y nos puede llevar mucho tiempo el diagnosticarlo y solucionarlo de forma adecuada.




"Copyleft Fernando Acero Martín 2014. Se permite la copia textual, la traducción y la distribución de este artículo entero en cualquier medio, a condición de que este aviso sea conservado. Se permite la cita. El autor no reclamará ninguna cantidad por el ejercicio de las dos autorizaciones anteriores. No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre."


"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."

Latest Month

July 2015
S M T W T F S
   1234
567891011
12131415161718
19202122232425
262728293031 

Syndicate

RSS Atom
Powered by LiveJournal.com
Designed by Tiffany Chow