jueves, 31 de diciembre de 2015

¿Cómo evito que se recaliente mi chip de video ATI/AMD Radeon en Ubuntu 14.04LTS?

A pesar de encontrarse en el ostracismo del exilio, Juan Perón se las arreglaba para ser el centro de la vida política en el país. Mediante una nota de color en la revista Panorama de principios de los setentas, el general abre sus quinta 17 de Octubre en Puerta de Hierro, y enseña cómo evitar que se recaliente nuestro chip de video ATI/AMD en Ubuntu.

(...)
Mis días en Puerta de Hierro son tranquilos. A diana me levanto, hago ejercicios, salgo a caminar con mis caniches, y riego mis rosas. Son espléndidas, no creo que nadie en los alrededores tenga unas más coloridas y perfumadas. Las trato con sumo cariño y les hablo. ¿Sabe usted que las rosas entienden? Me responden con este perfume.

Luego respondo correspondencia, y recibo a los visitantes que siempre vienen. Los argentinos son muchos y cada uno pasa a saludar. Parece que todos quieren sacarse de encima a ese tonto de Lanusse. ¡Si viera usted! Lo peor es que hasta quienes dicen ser sus aliados también quieren sacarlo volando. Yo por mí, no haré nada, todos lo harán ellos, y si siguen así hasta me pagarán el pasaje para que vuelva (guiña el ojo).

Al mediodía como liviano algo que yo mismo preparo, y a la tarde es hora de hacer mas ejercicio. Practico esgrima que es buena para los brazos y las piernas.

Lo importante es no recalentar el motor. Hay que hacer todo de a poco, y no fundirse.

Esto lo aprendí en mis años de Cadete, pero también tiene implicancias en todo los aspectos de la vida. Un equipo informático cuenta - por designio - con las mismas perrogativas. Entre los componentes que más calor generan en dichos sistemas se encuentran la Unidad Central de Proceso (CPU), pero por sobre todo la unidad de proceso Gráfico (GPU). El chip de video suele ser el punto flaco, y hay que cuidarlo para evitar percances, sobre todo en equipos portátiles.

Vea usted, durante años, el uso de Ubuntu con equipos de video ATI/AMD tuvo ciertos problemas, de los cuales he dado numerosa prueba. Amén de las trivialidades impuestas por un Capital sin Patria ni Bandera en la conducción de los conglomerados encargados de diseñar los chipsets, hemos tenido que enfrentar determinados errores de diseño o malas aplicaciones para el software libre. En ello hemos trabajado durante los 10 años, en los que dimos la mayor felicidad al Pueblo Argentino.

En particular, los productos ATI/AMD se suplieron en su momento con un controlador llamado Catalyst, cuyas librerías en el caso de Ubuntu se denominaron fglrx. Este controlador hubo de mejorarse paso a paso para lograr un efectivo uso del video, y en ello hemos estado todos. Lamentablemente, ciertos chipsets de video antiguos dejaron de actualizarse en aras de mejorar el hardware nuevo, y ello incluyó varios equipos de la línea Radeon y Radeon HD.

La ignominia de esta obsolescencia programada se hizo sentir sobre todo en mi querida Notebook Acer 5542-5241, munida del adaptador de video integrado ATI Radeon HD 4200 y chipset AMD RS780/RS880. En particular, me obligó a extender el uso de Ubuntu 10.10 durante un largo tiempo, pues las versiones 11.04, 11.10, y especialmente 12.04LTS eran parcialmente incompatibles con los nuevos controladores y su video ATI Radeon 4200 HD.

Ahora bien, la resistencia de los hombres que luchan ha dado sus frutos, y dichos problemas se solucionaron entonces para la siguiente iteración de Ubuntu, la 14.04LTS. Contando tal versión con una distribución armada con escritorio MATE (Ubuntu 14.04LTS Mate x64), lo he instalado en la Acer 5542, para encontrar por fin un muy buen desempeño en el área de video, sin requerir instalar controlador Catalist alguno, y por lo tanto facilitando enormemente la instalación, estabilidad y uso de dicho equipo.

Sólo un problema aquejaba mi existir: el controlador de video integrado recalentaba moderadamente el equipo. Normalmente esto hacía que fluctúe entre los 56ºC y 68ºC en invierno y unos 62ºc y 74ºC en verano (para revisar los valores de temperatura, podremos agregar indicadores de temperatura en el panel superior de Mate o de Gnome como ya he explicado).

Afortunadamente, como este recalentamiento se debe en parte al software, puede remediarse gracias a la funcionalidad de la Gestión de Potencia Dinámica (DPM) de dicho chip de video.

Esta función consiste en regular la potencia de uso del equipo según la demanda, y contribuye notablemente a mantener el equipo freco, disminuyendo la potencia de video en la mayoría de las condiciones.

Las placas de video ATI/AMD más recientes soportan el controlador Radeon que se encuentra integrado de fábrica en Ubuntu 14.04LTS y su función DPM debería activarse automáticamente al inicio del sistema, sin requerir pasos adicionales.

Sin embargo, algunas versiones del adaptador de video - sobre todo las más antiguas - requieren que la opción DPM sea activada de forma manual en el archivo de configuración de inicio del sistema.

Para ello abrimos una Terminal con Ctrl+Alt+T. Luego en la consola de texto ingresamos el comando de organización:

sudo nano /etc/default/grub

El sistema nos solicitará la contraseña de Ubuntu, y tras introducirla arrancará el editor GNU Nano y nos permitirá editar y modificarel archivo de configuración del arranque del sistema, Grub.

En el archivo propuesto, buscamos la línea GRUB_CMDLINE_LINUX_DEFAULT (debería estar entre las primeras).

A la misma debemos agregarle a la expresión entre comillas, la función radeon.dpm=1, de modo que quedará algo así:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash radeon.dpm=1"

Nota: Quienes posean específicamente las Acer 5536/5542 han de saber que la línea también debe contener la función i8042.nomux en el comando. En resumen, quienes tengan la Acer 5536 o 5542 con Ubuntu 14.04LTS Mate habrán editar la línea asegurándose que quede así: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i8042.nomux radeon.dpm=1"
No bien revisado que hemos introducido sin errores, guardamos las modificaciones realizadas con Ctrl+O y salimos del editor GNU Nano con Ctrl+X.

Finalmente, para efectivizar los cambios en el arrancador Grub, debemos entrar el siguiente comando:

sudo update-grub

Para disfrutar de los cambios es necesario rearrancar el sistema. Podremos hacerlo desde la terminal con:

sudo reboot

El proceso de arranque debería darse correctamente, y activar por defecto la función DRM de nuestro adaptador de video.

Para comprobarlo, podríamos buscar en el reporte de arranque del sistema en la terminal. Abrimos una terminal con Ctrl+Alt+T e ingresamos el siguiente comando:

dmesg | egrep 'drm|radeon'

...este comando nos listará todos las instrucciones de sistema que tienen que ver con el controlador Radeon. No rebería contener errores, y debería contener la línea que indica el arranque de la opción DRM.

En la práctica, debemos corroborar empíricamente si notamos diferencias en la temperatura del equipo:


En mi caso, noto que el promedio de temperatura descendió de los 66ºC en verano a unos 57ºC, y que el sistema es bastante más estable.

martes, 29 de diciembre de 2015

¿Cómo puedo enviar correo electrónico encriptado y firmado?


En una de sus clásicas disertaciones en la Escuela de Guerra, el General Juan Perón expone un fundamental esquema para mantener el secreto operativo para la victoria a través de correo electrónico firmado y encriptrado en Ubuntu, el sistema operativo del Pueblo.

(...)
Las condiciones en las que muchas veces se produce la lid política, nos encontrará en la realidad de batirnos en las posiciones menos aureoladas. La acción no siempre se da en el terreno que auguramos, y en tal caso un Conductor ha de mostrarse hábil en la planificación, pero sobre todo capaz de accionar en un terreno del cual podría carecer de un dominio total.
Sun Tzu decía que el conocimiento de la acción del enemigo no puede darse por consagración del espíritu, ni por pensamiento inductivo en base a la experiencia. El conocimiento sobre el accionar del oponente ha de obtenerse a través del mismo enemigo, espiando sabiamente su accionar.

En el campo telemático, la acción responde a los mismos principios. Quien crea en la idea mágica de una red neutral, que se levante y vaya a comprar facturas. No en vano en los frontispicios de los campamentos de Roma esculpían el Legio regnus Leges nulis, donde Reina el Legión, la Ley es Nula.  Nos encontraremos así que las oscuras fuerzas de la oligarquia - a través de sus tentáculos omnímodos - osarán leer todo mensaje de los Luchadores de la Libertad que circule por redes a las que considerarán propias. Tomarán todos los recaudos para interceptar y hacer uso de dicha información para apuntalar un objetivo que por inconfesable, no deja de ser cierto. Lo harán pretendiendo ser nuestro proveedor de correo electrónico, nuestro proveedor de tecnología de la información, proveedor de comunicaciones, o vendiéndonos esa libertad en cómodas latas a las que llaman software privativo.

A lo largo de la historia, todo yacaré que osó dormitar se ha convertido en cartera. Nosotros somos un Movimiento que ha de conocer esta triste realidad para prevenir su accionar, y emprender una vez más la lucha por la Auténtica Liberación de nuestra Patria y su Software, a fin de reencontrarnos victoriosos en un futuro que no guarda para nosotros sino la dicha y la felicidad de todos los Argentinos.

¿Cómo podemos proteger nuestro tráfico de información en la lucha enconada que hemos de dar?. Vean señores, por más remozada que esté, la técnica computada no deja de ser - en su esencia - mas vieja que mear en los portones. Emplearemos el arte de los criptosistemas. Esto es, codificar un mensaje para que sólo sirva a nuestros intereses.

¿Como funciona el sistema? Se trata de un mecanismo de cifrado de alta computación para mensajes de punto a punto. Cada punto (remitente y receptor) poseen dos tipos de clave: una llamada Clave Privada, y otra que se combina con la anterior pero que debe compartirse con el resto del nuestros destinatarios de correo: la Clave Pública.

Cuando un remitente desea enviar correspondencia electrónica cifrada, debe primero encriptarlo mediante la Clave Pública de la persona a quien desea enviarle el correo. Esto hace que ya - durante su viaje - el mensaje vaya cifrado y sea totalmente inintelegible. Al llegar el mensaje cifrado al destinatario, éste utilizará su propia Clave Privada para actuar en combinación con la clave pública del remitente; sólo así el mensaje se descifrará y resultará legible.

El Conductor de un Movimiento debe ser - ante todo - un didacta. Es por ello que concentraré mis esfuerzos en iluminar a la Masa entendiendo que el empleo masivo de encriptación a nivel táctico y estratégico es un multiplicador de fuerzas, tendiente a otorgar a nuestro Movimiento la sorpresa en en planeamiento estratégico y en la ejecución táctica de las acciones que hemos de emprender.

Han de saber que los objetivos fundamentales de este criptosistema son:

a) certificar profundamente las identidades de quienes lo envían y reciben. Sólo esta protección de la identidad podrá asegurar que sólo la persona a quien queremos enviar el correo lo reciba. Esta protección a la identidad también asegurará al receptor que quién ha emitido el mensaje es la persona que dice ser.

b) intercifrar el mensaje de modo que quienes carezcan de las claves correspondientes tengan totalmente vedado, en la práctica, loa imprescindible lectura descifrada el mensaje.


CREACIÓN DEL PAR DE CLAVES
Para crear las claves usaremos el herramental GnuPG, una serie de programas libres para todo el cometido estratégico de la alta encriptación bajo las banderas del Justicialismo. Estas comprenderán nuestras armas de campo, y de ellas no debemos desconfiar pues son realmente potente para afrontar los distintos esquemas de seguridad (encriptado directo, firma digital, y gestión de claves, todo protegido con diferentes algoritmos).
En primer lugar hemos de instrumentar el par de claves (privada y pública) necesarias para el criptosistema del que os he hablado. Tanto el remitente como el destinatario deberán tener su par de claves.

Nos crearemos un par de claves para nuestro uso personal. Podremos utilizar el sistema gráfico o el la terminal para hacerlo. En este caso, será más ágil explicarlo con la terminal de texto. Por ello abrimos una Terminal con Ctrl+Alt+T e ingresamos:

gpg --gen-key

El sistema nos irá indicando los pasos para generar una clave. En el primero de los pasos, debemos configurar el esquema de claves. El caso por defecto emplea el algoritmo RSA+RSA, el cual recomiendo ampliamente para mensajes de texto simple. Si deseamos codificar programas, fotografías, videos o gran cantidad de datos podríamos preferir emplear el esqueema DSA+Elgamal, de menor requerimiento computacional. Nos aparecerá el siguiente diálogo:

gpg (GnuPG) 1.4.16; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Por favor seleccione tipo de clave deseado:

   (1) RSA y RSA (predeterminado)
   (2) DSA y Elgamal
   (3) DSA (sólo firmar)
   (4) RSA (sólo firmar)

¿Su selección?:1

las claves RSA pueden tener entre 1024 y 4096 bits de longitud.
¿De qué tamaño quiere la clave? (2048) 4096

El tamaño requerido es de 4096 bits

Por favor, especifique el período de validez de la clave.

         0 = la clave nunca caduca
        = la clave caduca en n días
      w = la clave caduca en n semanas
      m = la clave caduca en n meses
      y = la clave caduca en n años
¿Validez de la clave (0)? 0

La clave nunca caduca
¿Es correcto? (s/n)s


Necesita un identificador de usuario para identificar su clave. El programa construye el identificador a partir del Nombre Real, Comentario y Dirección de Correo electrónico de esta forma:

    "Heinrich Heine (Der Dichter) "

Nombre y apellidos: Juan Perón
Dirección de correo electrónico: juanperon@puertadehierro.com.es
Comentario: Conductor

¿Cambia (N)ombre, (C)omentario, (D)irección o (V)ale/(S)alir?V


Si es la primera vez que utilicemos nuestro sistema de cifrado en esta computadora,, el programa nos solicitará una contraseña para el anillo de claves, que nos permitirá controlar los cifrados. Este funciona como mi anillo de ónix que tiene las claves de mis cajas secretas de Suiza.

Esta contraseña del anillo de claves será distinta a las de las firmas digitales. Es imporante contar con una clave que recordemos, o al menos anotarla y guardarla en un lugar seguro, como una caja de seguridad, sobre lacrado, etc.

El procedimiento de generación de claves es computacionalmente intensivo, por lo cual puede tardar un par de minutos dependiendo de la complejidad de la clave (en bits). Para ello, el algoritmo requiere generar muchos bytes aleatorios, y lo hará a través de la llamada "entropía" de distintos dispositivos de sistema. Para que estos bytes aleatorios se generen mas rápidamente, se aconseja trabajar en muchas cosas a la vez, usar la red y los discos, usar varias ventanas, ver streams de videos, etc), y durante todo este procedimiento se generarán números primos y diferentes acciones de cifrado. Todas esta generación pseudoaleatoria de alta computación hará que la clave sea realmente compleja. En tanto no tengamos los datos necesarios, se nos mostrará un mensaje similar a este:

No hay suficientes bytes aleatorios disponibles. Por favor, haga algún otro trabajo para que el sistema pueda recolectar más entropía (se necesitan xxx bytes más).

Una vez realizado esto, se nos informará mediante un comunicado similar a este:

gpg: clave 8F7FGBC6 marcada como de confianza absoluta
claves pública y secreta creadas y firmadas.

gpg: comprobando base de datos de confianza
gpg: 3 dudosa(s) necesarias, 1 completa(s) necesarias,
modelo de confianza PGP
gpg: nivel: 0  validez:   2  firmada:   0  confianza: 0-, 0q, 0n, 0m, 0f, 2u
pub   4096R/7F7FGBC6 aaaa-mm-dd
      Huella de clave = zzzz zzzz zzzz zzzzz zzzz  zzzz zzzz zzzz zzzz zzzz
uid                  Juan Peron (conductor) [juanperon@puertadehierro.com.es]
sub   4096R/69FGFE5C aaaa-mm-dd


Estudiemos momentáneamente este resultado de ejemplo. Se nos indica el identificador de la clave pública 7F7FGBC6 y de la clave privada 69FGFE5C, así como su fuerza de encriptación (4096R, que significa 4096 bits RSA). Alguno de los comandos dependen de estos identificadores, de modo que debemos tomar nota de ellos, e idealmente guardarlos en lugar seguro.


CERTIFICADO DE REVOCACIÓN DE CLAVE
Apenas creamos el Par de claves, conviene crearnos un Certificado de Revocación para la clave privada. Este ejercicio se debe a que si en algún momento la clave privada resulta comprometida, la cambiamos, etc, debemos revocar la antigua, y el certificado hará dicho trámite. Debemos pensar en él Certificado de Revocación como "la escritura de la casa". Si tuviésemos que "cambiar la cerradura por algo", esta será nuestra llave maestra. Para generar el certificado de la clave pública haremos:

gpg --output cert_revok_69FGFE5C.asc --gen-revoke 0x69FGFE5C

Este dará como resultado un archivo de texto llamado cert_revok_69FGFE5C.asc que contendrá una clave con el certificado de revocación. Este fichero conviene guardarlo en algún medio de almacenamiento y colocarlo en sitio seguro (imprimirlo y guardarlo en sobre lacrado/caja fuerte, o idealmente tomar los dos temperamentos), pues nos servirá en caso de emergencias graves con la clave privada. Conforme el certificado de revocación de clave privada esté en orden, podremos ya con confianza compartir la clave pública a terceros.


COMPARTIR NUESTRA CLAVE PUBLICA
Para poder darle a futuros remitentes nuestra clave pública, hay que exportarla. Para ello utilizaremos el comando:

gpg --armor --output juan_peron_publica.asc --export juanperon@puertadehierro.com.es

Ello nos creará un archivo ASCII blindado que contendrá la clave pública, llamado en este ejemplo juan_peron_publica.asc. El contenido íntegro de dicho archivo podremos hacerlo público de la manera que se nos ocurra. Podríamos mandarlo adjunto por correo electrónico, o subirlo a algún servidor de claves públicas, o acercarlo por medio de algún método de transferencia de información.

Si no tenemos tantos problemas con la privacidad, podríamos hacer uso de servidores especializados para hacer pública nuestra clave pública, y que la misma esté disponible para cualquiera que nos busque para entablar un contacto certificado. Uno de los míticos es el servidor de claves PGP del MIT, sito en https://pgp.mit.edu/.

Si deseamos emplear otros servidores de manera sencilla, podríamos hacer uso de la interfaz gráfica de nuestro Ubuntu. Vamos a Sistema / Preferencias / Contraseñas y Claves. Elegiremos entonces el menú Remota / Sincronizar Claves.

Si presionamos Servidores de Claves, podremos elegir alguno. En el caso de Ubuntu 14.04LTS nos ofrecerá tres servidores seguros y confiables a disposición, pero podremos agregar más si lo deseamos.




Al presionar Sincronizar se cargarán (subirán) las claves públicas que querramos al servidor elegido. Si quisiéramos buscar una clave pública, podríamos utilizar la función Remota / Buscar Clave Pública.

Si echamos un vistazo al contenido de nuestro archivo de clave pública juan_peron_publica.asc, veremos la clave que su contenido tendrá una apariencia similar a esta:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1

chorizodeletrasindescifrablesqueesnuestraclavepublicaimposiblederecordaretc
chorizodeletrasindescifrablesqueesnuestraclavepublicaimposiblederecordaretc
chorizodeletrasindescifrablesqueesnuestraclavepublicaimposiblederecordaretc
(...)

-----END PGP PUBLIC KEY BLOCK-----



AGREGARNOS LA CLAVE PÚBLICA DE UN TERCERO
Para poder enviarle correo electrónico cifrado a un tercero, debemos incorporar a nuestro critosistema la clave pública de dicha persona. Naturalmente, la misma tendrá la misma forma que nuestra propia clave pública: un archivo .asc, o eventualmente un archivo .gpg (la diferencia es que el .gpg no es blindado, pero para el caso es lo mismo).

Supongamos que nos hacen llegar por correo electrónico no cifrado la clave pública de nuestro destinatario jwk@orga.ar. La misma consiste en un archivo de clave pública llamado john_william_cooke.asc. La incorporamos a nuestro Movimiento con el comando:

gpg --import john_william_cooke.asc

Sólo si la clave está intacta, el sistema la incorporará. En tal caso nos devolverá algo como:

gpg: key 3DE3f869: Clave pública importada.
gpg: número total procesada: 1
gpg:              importada: 1



REVISAR Y VALIDAR LAS CLAVES ALMACENADAS EN EL CRIPTOSISTEMA

Podremos revisar las claves en nuestro sistema con el comando:

gpg --list-keys


...y este nos devolverá algo como:

/home/usuario/.gnupg/pubring.gpg
------------------------------
pub   4096R/7F7FGBC6 aaaa-mm-dd
uid                  Juan Peron (conductor)
sub   4096R/69FGFE5C aaaa-mm-dd

pub   2048R/3DE3f869 aaaa-mm-dd
uid                  John William Cooke
sub   2048R/C3CFF358 aaaa-mm-dd



Ahora bien, ¿cómo sabemos que realmente dicha clave es de la persona que deseamos, y no de alguien que pretende serlo? Por medio de las validaciones. Nosotros podemos validar firmas que sabemos reales, o poner en duda las que creemos falsas. En una empresa, el empleador podría validar las cuentas que ha creado para sus propios usuarios. Similarmente, en toda organizaación o Movimiento político ha de poder validar las claves de quienes la componen.

Para validarla podermos utilizar la ventana gráfica pues es más sencillo. Vamos a Sistema / Preferencias / Contraseñas y Claves. Se abrirá el cuadro de diálogo que nos permite administrar las claves. Debemos ir al menú Ver / Mostrar todas para que nos muestre todas las claves que tengamos.
En el campo de la izquierda, hacemos clic el apartado Claves GPG / Claves GnuPG. Allí se listarán todas las claves.

Hacemos doble clic en aquella que nos interese validar. Se abrirá un cuadro con la respectiva Clave Pública. Debemos ir a la solapa Detalles y elegir en el apartado Indique Confianza un valor para el mismo (puede ser Desconocida, Nunca, Marginal, Completa). Si sabemos efectivamente que el propietario es quien dice (por ejemplo, nos transfirió el archivo en mano, presencialmente, etc) podemos indicar Completa.


CODIFICAR UN MENSAJE Y ENVIARLO POR CORREO ELECTRÓNICO COMÚN


En este ejemplo cifraremos un importante mensaje estratégico llamado carta.txt, y lo firmaremos digitalmente, para luego enviárselo a John William Cooke a través de un correo electrónico convencional a su cuenta jwc@orga.ar.
Para ello utilizaremos la siguiente sintaxis de comando:

gpg --output cartaencriptada.gpg --encrypt --recipient jwk@orga.ar carta.txt

El sistema cifrará el archivo carta.txt usando la clave pública asignada a jwk@orga.ar, y el resultado de dicha encriptación quedará en el archivo cartaencriptada.gpg. Dicho archivo ya será ininteligible.

En el caso que la clave pública de Montoneros no esté certificada aún, podremos cifrar el mensaje de todos modos, pero el sistema, en aras de la seguridad extrema, nos lo advertirá con el siguiente mensaje:

gpg: 3DE3f869: No hay seguridad de que esta clave pertenezca realmente
al usuario que se nombra

pub  2048R/3DE3f869 aaaa-mm-dd John William Cooke
 Huella de clave primaria: xxxx xxxx xxxx xxxx xxxx  xxxx xxxx xxxx xxxx xxxx
      Huella de subclave: yyyy yyyy yyyy yyyy yyyy  yyyy yyyy yyyy yyyy yyyy

No es seguro que la clave pertenezca a la persona que se nombra en el
identificador de usuario. Si *realmente* sabe lo que está haciendo,
puede contestar sí a la siguiente pregunta.

¿Usar esta clave de todas formas? (s/N) s


Ahora que tenemos el archivo cifrado cartaencriptada.gpg, opcionalmente podremos firmarlo digitalmente. La firma actúa también como certificado de inviolabilidad, y alerta al receptor si el mensaje no ha sido alterado de cualquier forma durante su traslado telemático.

Para firmarlo se utiliza la clave privada del usuario remitente. Para ello debemos usar:

gpg --output cartaencriptadayfirmada.sig --sign cartaencriptada.gpg

El sistema nos advertirá:

Necesita una frase contraseña para desbloquear la clave secreta
del usuario: "Juan Peron (Conductor) "
clave RSA de 4096 bits, ID 7F7FGBC6, creada el aaaa-mm-dd


Debemos ingresar entonces la contraseña que hayamos asignado al anillo de contraseñas de nuestro sistema para completar el criptofirmado.

Conforme hayamos realizado estos pasos, podremos ya enviar como adjunto el archivo cartaencriptadayfirmada.sig por correo electrónico convencional con suma confianza a la dirección jwk@orga.ar. Si cualquier espurio proveedor de internet deseara interceptar el archivo, solo recibiría basura ininteligible. Y si quisiera alterarlo por algo, alertaría al remitente que sin duda se produjo una modificación en el fichero...

Una vez recibido su correo electrónico, John William Cooke debe descargar el archivo cartaencriptadayfirmada.sig. Podrían entonces verificar la firma con:

gpg --verify cartaencriptadayfirmada.sig

...si todo es correcto, el sistema les devolverá el status de la firma. Si la firma está certificada ya por varias personas, podría indicarnos:

gpg: Firmado el ddd dd mmm aaaa hh:mm:ss TZ usando clave RSA ID 7F7FGBC6
gpg: Firma correcta de «Juan Perón (Conductor) »


...y si la firma no estuviese convenientemente certificada por terceros aún,, podría alertarnos al respecto:

gpg: Firmado el dd mmm aaaa hh:mm:ss TZ usando clave RSA ID 7F7FGBC6
gpg: Firma correcta de «Juan Perón (Conductor) »
gpg: AVISO: ¡Esta clave está certificada por una firma de confianza!
gpg:          No hay indicios de que la firma pertenezca al propietario.
Huellas dactilares de la clave primaria: zzzz zzzz zzzz zzzz zzzz  zzzz zzzz zzzz zzzz zzzz


Finalmente, John William Cooke utilizaría su propio criptosistema para descifrar el mensaje. En su equipo dotado con su propia clave privada, ingresaría los siguientes comandos de organización para descifrar la carta:

gpg --output cartacifrada.gpg --decrypt cartadescifradayfirmada.sig
gpg --output cartadescifrada.txt --decrypt cartacifrada.gpg


Esto ya nos dejaría el texto complemente descifrado. John William Cooke podría leer la carta de directivas estratégicas en la terminal Linux con:


less cartadescifrada.txt

...sabiendo que sólo él la ha leido, y que Fibertel la tiene adentro pero no le sirve de nada. Finalmente, podría borrar de forma segura la carta con:

shred cartadescifrada.txt

Método de Firma Acompañante:
El mecanismo anterior aporta una seguridad altamente eficiente para impedir que terceros vean el contenido del archivo, pero requiere aún así manipular un archivo cartacifrada.gpg intacto para poder descifrarla en cartadescifradayfirmada.sig y luego hacerlo legible.

Para certificar todo el camino del mensaje (en casos de seguridad de emergencia), debemos utilizar el esquema de firmas acompañantes, que prevee verificar que el archivo gpg esté intacto, por medio de un archivo de firma sig. Suponiendo que tenemos un archivo a codificar y firmar llamado carta.txt, en este caso como remitente Juan Domingo Perón indicaré:

gpg --output cartaencriptada.gpg --encrypt --recipient jwk@orga.ar carta.txt

...con lo cual se nos advertiría y cifraría el mensaje carta.txt en el archivo cifrado e ilegible cartaencriptada.gpg. Acto seguido empleamos el comando:

gpg --output firmademensaje.sig --detach-sig cartaencriptada.gpg

El criptosistema del remitente nos indicará algo como:

Necesita una frase contraseña para desbloquear la clave secreta
del usuario: "Juan Domingo Peron (conductor) [
juanperon@puertadehierro.com.es]"
clave RSA de 4096 bits, ID
7F7FGBC6, creada el dd mmm aaaa hh:mm:ss

...tras ingresar la contraseña de desbloqueo, el criptosistema y firmará el archivo firmademensaje.sig y lo encriptará. Para que el sistema de desencripción con firma acompañante funcione, debemos incluir ambos archivos en el correo electrónico, y ambos deben llegar intactos a John William Cooke (en casos muy extremos podríamos enviar cada archivo por vías diferentes).


Una vez que reciba ambos archivos adjuntos por correo electrónico convencional, John William Cooke primero verificará ambos archivos encriptados y su firma acompañante con el siguiente comando:

gpg --verify firmademensaje.sig cartaencriptada.gpg

...si el archivo no fue alterado de forma alguna y tanto las firmas públicas nuestras coiciden con las privadas del remitente, el criptosistema de John William Cooke debería devolverle algo como:

gpg: Firmado el
dd mmm aaaa hh:mm:ss usando clave RSA ID 7F7FGBC6
 gpg: Firma correcta de «Juan Domingo Peron (conductor) [juanperon@puertadehierro.com.es]»
Confirmada la verificación y estando seguro que el archivo fue firmado por quien lo origina y no por otro, ahora sólo John William Cooke en su criptosistema podrá proceder a desencriptar el mensaje y leerlo. Lo haría con:

gpg --output cartaencriptada.gpg --decrypt firmademensaje.sig
gpg --output cartadescifrada.txt --decrypt cartaencriptada.gpg
 
En su equipo naturalmente se solicitará contraseña para poder desencriptar. Una vez realizado el procedimiento, podrá leer el archivo con:
 
less cartadescifrada.txt
 
Asimismo, tras leer el archivo cartadescifrada.txt, John William Cooke podría eliminar con seguridad todos los archivos de su disco rígido de una forma en la cual sea imposible recuperarlos, empleando el comando shred:
 
shred cartadescifrada.txt cartaencriptada.gpg firmademensaje.sig 
Indudablemente, que todas estas acciones de cifrado y descifrado, firmado y verificación desde la terminal, pueden llevarse a cabo mucho más fácilmente desde un cliente libre de correo electrónico de interfaz gráfica como Thunderbird, pero tal acción la llevaremos a cabo en otra clase de este mismo gabinete.

lunes, 28 de diciembre de 2015

¿Cómo puedo encriptar archivos y mensajes de manera simple?

En una serie de exposiciones en el Círculo de Oficiales durante la primera semana de mayo de 1944, Juan Perón expone la necesidad de contar con un sistema de cifrado para los mensajes tácticos y estratégicos de la lucha, y dicta cómo realizar dicho cifrado táctico en Ubuntu.


¡Camaradas de armas!

Una oligarquía cipaya y vendepatria no ha hecho mas que encaramarse espuriamente en el poder, lo que nos llamó a aunar esfuerzos para combatirla. Para ello, hubimos de emplear todas las herramientas puestas a nuestra disposición.

Nuestras consignas son públicas y sabidas por todos. Sin embargo, nuestra acción de conducción ha de prevenir ciertos esquemas que podrían ser perjudiciales para la Acción de Masas que hemos de emprender.

Esto es así porque en conducción de la acción, ha de lograrse la condición potenciadora requerida para toda victoria, la condición de la sorpresa en tiempo y en terreno.

La sorpresa se plantea a nivel táctico, pero se decide a nivel estratégico. Es por ello que debemos plantearnos necesariamente un accionar sorpresivo en la mayor cantidad de niveles de la acción política si es que queremos vencer. Quien no tenga la sorpresa, será siempre derrotado o sufrirá un desgaste tal en su accionar que poco provecho obtendrá de lo que gane. Esto, que se conoce desde los tiempos de Aníbal, ha de repercutir hoy con mucho más fuerza que nunca.

Señores, a nivel táctico habremos de dar apreciaciones, analizar factibilidades de lugar, plantear acciones de conjunto y desarrollarlas de manera que hagan trastabillar a un enemigo que se cree seguro en pos de nuestro objetivo final. Es lo que se dice, planear con inteligencia. Para ello, hemos de estar mas seguros que el enemigo, aplomados en una organización embuida en defensiva u ofensiva según lo determine la estrategia que habremos de emplear.

Ahora bien, todo accionar político que se precie debe estar profundamente estudiado, y ese planeamiento a nivel táctico - que muchas veces es inmediato - debe sufrir un requerimiento indispensable: debe comunicarse exitosamente entre todos los elementos de cuadros. Y es esta comunicación la que proveerá el camino de la sorpresa. Un enemigo hábil en el dominio del terreno que pisa dificultará sin lugar a dudas la comunicación de los elementos de lucha a los que habrá de enfrentar. Por ello, los compañeros han de saber organizar un buen sistema de cifrado que permita gran agilidad y facilidad para lograr el secreto y la sorpresa, para todo estamento de la acción que hemos de realizar.

Un ejemplo suele aclararlo todo, como decía Napoleón.


En la guerra, los alemanes intentaron un dispositivo electromecánico llamado Enigma, que hacía las veces de codificador simétrico a través de permutaciones alfanuméricas cíclicas por medio de unos cilindros con piñones dotados de letras (los cuales a su vez debían disponerse según un código convencional militar). Estos dispositivos suelen tener un gran inconveniente: requieren gran potencia de cálculo para romper el código por medio de criptoanálisis o por medio de un ataque de fuerza bruta, pero siempre será posible hacerlo. Incluso con los primeros equipos computacionales modernos. La solución es imponer un cifrado computacionalmente tan complejo, que ahuyente la practicidad de intentar romperlo por medio de fuerza bruta de cálculo.

Vean señores, siempre es mejor un bruto que un malo. He visto brutos que se han vuelto buenos. Pero no he visto un malo que se haya vuelto bueno.

Por tanto, las encriptaciones modernas y prácticas han de ser de mayor complejidad para evitar a los brutos de la fuerza... Esto requiere que el código no sea una mera conversión a binario, sino que emplee una Clave Secreta específica para realizar (por medio de distintos algoritmos) la encriptación necesaria. Normalmente esto se logra a través de fórmulas de números compejos y primos grandes mutuamente recursivas.

 Este sistema es el de "encriptación simétrica por frase de paso", aunque también podríamos entenderla como "encriptación simple por contraseña", pueden emplearse en el nivel táctico en la acción que deseamos llevar a cabo, y ello es lo que enseñaré.

Ubuntu cuenta para estos menesteres con una excelente serie de herramientas, llamada GnuPG, o "Guardia de Privacidad". Este herramental consiste en una serie de funciones de seguridad para la Consola o integrada a nuestro escritorio gráfico, que permiten una comunicación electrónica y encriptación de archivos de variable complejidad, y nos aseguran ello a través de esquemas simples o los más complejos. También incluye funcionalidades avanzadas para protección de contraseñas.

Analicemos su uso práctico en un ejemplo simple y empleo táctico, pues ella es la mejor manera de aprender.

Supongamos que contamos con un archivo de texto con órdenes e instrucciones tácticas en formato ASCII (o sea, sin formato, texto plano) llamado resistencia.txt del que deseamos crear una copia cifrada para que sólo puedan leerlo quienes dispongan de la clave necesaria. Para ello usamos:

gpg -c resistencia.txt

Si es la primera vez que utilizamos nuestras herramientas GnuPG, el sistema nos devolverá algo como:

gpg: anillo «/home/usuario/.gnupg/secring.gpg» creado
gpg: datos cifrados CAST5
gpg: cifrado con 1 frase contraseña
gpg: AVISO: la integridad del mensaje no está protegida



Si estamos en modo gráfico, GnuPG arrancará un agente que nos solicitará contraseña (el sistema bloqueará otros programas en ejecución hasta que introduzcamos la contraseña para evitar filtrados):

Si cancelaramos el agente gráfico, o si estuviésemos en la Consola terminal, el sistema nos indicará:

Introduzca frase contraseña:
Repita frase contraseña:

Como ya es clásico en GNU con Linux, hemos de introducir una contraseña "a ciegas" y repetirla a fin de certificar que no existan errores de tipeo. Podremos utilizar caracteres alfanuméricos, y la clave es sensible a mayúsculas, por lo cual que las mismas también pueden utilizarse. Como en toda clave simple, cuanto mayor sea su longitud y menos palabras de diccionario utilice, mucha mayor será su seguridad relativa.

Conforme pongamos dos veces la misma contraseña, el sistema la utilizará el algoritmo de cifrado CAST5 y creará un nuevo archivo llamado resitencia.txt.gpg. El archivo .asc original todavía estará a mano, y podríamos triturarlo con el comando shred y luego borrarlo con el comando rm si deseamos solo conservar la versión cifrada.

Si deseáramos comprobar el encriptado, podríamos utilizar el comando cat para ver el contenido del archivo cifrado. Por ejemplo:

cat resistencia.txt.gpg

...pero ello no servirá de nada, pues lo que veamos será totalmente ininteligible.


Para descifrar el archivo, empleamos el comando:

gpg resistencia.txt.gpg

gpg: datos cifrados CAST5
gpg: cifrado con 1 frase contraseña

Introduzca la contraseña:
gpg: AVISO: la integridad del mensaje no está protegida


Al introducir la contraseña provista anteriormente, se descifrará el archivo .gpg y hará una copia del archivo original (tengamos en cuenta que si no la hubiésemos eliminado, naturalmente nos solicitará permiso para sobreescribirla).

Hemos de tener en cuenta que como nos informa el sistema, la integridad de este archivo .gpg no está garantizada. La codificación CAST5 es bastante potente para un esquema simple de transmisión de archivos a través de medios tácticos no telemáticos (o sea, sin transmisión en redes abiertas como Internet). Aunque por sí sola no impide que el archivo sea modificado/arruinado por un tercero durante su viaje a través de diferentes servidores, ni garantiza su autenticidad (no posee firma digital). Aún así, puede ser adecuado para codificar un archivo de forma fácil, para introducirlo en un medio de almacenamiento seguro, etc.

El problema de este esquema para la transmisión, es que ambas partes (remitente y receptor) deben estar de acuerdo en una única clave. Lograr esto en todas las condiciones tácticas no es problema, pero a nivel estratégico es una invitación al desastre. Convenir una clave entre dos que están al lado es fácil, el problema radica en transmitírsela a un tipo que no conocemos por medio de medios telemáticos que no dominamos ni podemos certificar en toda su extensión, o que para peor, están dominados por el enemigo.

Por ello, el tipo de cifrado expuesto sólo puede servir para cifrar documentos  locales de tipo táctico, material que revista importancia pero que no requiera transmitirse normalmente.

La transmisión de documentos cifrados a nivel estratégico necesita indudablemente un esquema más avanzado de seguridad. Este esquema más complejo para transmitir nos llevará a proponer pares de Claves Públicas y Privadas codificadas, sistema en el que nos extenderemos a continuación.

viernes, 25 de diciembre de 2015

¿Cómo instalo Libreboot en mi IBM Thinkpad X60 o Lenovo T60?

Vean señores; por lógica necesidad del actual estado de cosas, el software libre corre normalmente sobre un hardware privativo. Los controladores libres se escriben, las estructuras se consolidan, pero siempre frente a proveedores privativos de hardware.
Si el hardware es privativo y su diseño cerrado, qué otra cosa podemos esperar del software que se integra en él para su funcionamiento. Nos encontramos entonces frente a la paradoja de "lo menos malo": utilizar software libre en hardware cerrado, con firmware privativos.

En nuestro camino de Conducción Orgánica del Movimiento en un ambiente de absoluta libertad, nos topamos entonces con la realidad coyuntural de que en la enorme mayoría de los casos, por mas que instalemos software libre en nuestro sistema, el firmware o la BIOS del mismo suele ser privativa, y sólo dable de modificar por el fabricante... Esto ha de ser remediado, pero son pocos los equipos que cuentan con la posibilidad siquiera de montar BIOS libres.

La BIOS es el sistema básico de entrada/salida de nuestro ordenador, una supramemoria de configuración que actúa al más alto nivel; esto es, siquiera antes que el sistema operativo arranque. Es el cimiento sobre el cual se erige todo sistema computacional moderno. En muchos equipos informáticos complejos, esta BIOS se encuentra escrita en un chip tipo EEPROM alimentado por una pila botón que permite guardar su contenido aunque se apague el sistema.


La historia nos está demostrando  - y cada vez con mayor rapidez - que el hardware libre será, una realidad insoslayable. Hoy contamos con algunos equipos limitados: computadoras en plaqueta de arquitectura ARM, sistemas embebidos de diseño abierto, sistemas en un solo circuito integrado, etc. Con el tiempo no será extraño que cada individuo pueda disponer de arquitecturas abiertas de potencia para desarrollar su informática libre golpeando allí donde más duele al imperialismo: en el bolsillo.

Sin embargo, no todo queda en manos del futuro: existen posibilidades de contar hoy con hardware de aceptable potencia, con BIOS completa y absolutamente libre si nos damos maña con ellos. Tal es el caso de la notebook IBM ThinkPad X60, también comercializada con distinto identificador de hardware y marca, como Lenovo T60. Se trata de un equipo portátil de arquitectura x86_64, antiguo mas no obsoleto, e indudablemente más potente que otras plaquetas utilitarias de arquitectura ARM o MIPSel que podríamos conseguir también. Fundamentalmente debemos inclinarnos ante el hecho de ser una de las pocas laptops capaces de recibir una BIOS totalmente libre.

La X60/T60 nos permitirá realizar esta hazaña por la liberación total del pueblo, su hardware y su software. Se trata de una veterana notebook de trabajo que conseguimos usada pujando hasta conseguir un precio popular. Está dotada con pantalla TFT LCD 4:3 de 14 pulgadas y 1024x768 pixels de resolución. El video es Intel 945GMA con salida SVGA. Sin dudas destaca su excelente teclado resistente, unos 2GB de memoria, y disco rígido HDD SATA de 160GB. La CPU es un veterano Intel Core 2 Duo, de doble núcleo. Trae una lectograbadora de DVD, así como tres puertos USB2 y uno PCMCIA (no evaluado). El dispositivo señalador es un trackpoint especie de joystick en forma de bolita roja localizado en la parte central del teclado entre las teclas "v" y "b", provisto de dos botones. La BIOS original es privativa, ya sea nomenclada bajo marca IBM o Lenovo. El sistema operativo que se integraba originalmente en la misma era un mediocre y lento Micro$soft Window$ Vi$ta de 32 bits. La batería original es la anquilosada IBM ML-X61 con un cargador de 14,4 voltios.

Al modificar la ThinkPad X60/X60s para dotarla con una BIOS completamente libre llamada LibreBoot, y opcionalmente reemplazando su placa Wifi Intel 3945abg por una Atheros, contaremos ya con un hardware completamente libre de pies a cabeza, en la cual montaremos un sistema operativo derivado de Ubuntu, pero con un kernel Linux totalmente libre. Dicho sistema operativo es Trisquel 7 Belenos GNU/Linux.

Todo procedimiento de cambiar una BIOS original por una versión actuaizada suele ser riesgoso. Lo suele ser mucho más cambiar una BIOS original por otra libre. En este caso, os asistiré, pero tengan en cuenta que siempre radica la posibilidad de inutilizar completamente el equipo. Si se tienen dudas no debe hacerse el procedimiento. En particular el Justicialismo cree que hackear es libertar, por lo tanto procederemos con la valentía de quien sigue la senda del Socialismo Nacional. En este caso obligatoriamente conectamos el equipo a la red eléctrica por medio del cargador CA correspondiente, y lo conectamos a internet por medio de un cable LAN/Ethernet.

Primero reemplazaremos el peligroso Window$ Vi$ta e instalamos un sistema operativo libre, acorde para reescribir la BIOS. En este emplearemos como sistema operativo Trisquel 7 LTS Belenos de 64 bits con sus opciones normales, pero podremos utilizar cualquier distro basada en Debian

Trisquel 7LTS Belenos es una distribución afianzada por la Fundación de Software Libre, en la cual -  a diferencia de Ubuntu - nos encontraremos con un Kernel completamente libre, y la inexistencia total de software o controladores privativos. Podremos formatear el disco rígido e instalarla (20 minutos aproximadamente en este equipo) o podremos arrancarla en modo LiveCD y trabajar. En nuestro caso decidimos por formatear el disco para estar más seguros.

Por lo demás, es una distribución GNU/Linux totalmente funcional. Una vez arrancado Trisquel normalmente, nos encontraremos con un típico escritorio Gnome.
En primer lugar vendrá siempre bien descargar dependencias necesarias para operar en la programación de la BIOS, y ello lo haremos desde la conexión cableada a internet, pues la placa Wifi original no será detectada por Trisquel. . Abrimos una terminal con Ctrl+Alt+T e ingresamos:

sudo apt-get update
sudo apt-get upgrade
sudo ./deps-trisquel


En segundo lugar, descargaremos las utilidades de trabajo y el BIOS libre Libreboot (podremos encontrar la última versión sin complicaciones es la r20150208 aquí). Podremos descargarla utilizando la terminal Linux de Trisquel, con los comandos de organización que correspondan a nuestro equipo. Utilizamos entonces:



cd ~/Descargas/
wget http://mirrors.mit.edu/libreboot/20150208/libreboot_bin.tar.xz
tar -xJf libreboot_bin.tar.xz
cd ~/Descargas/libreboot_bin/

En la carpeta ~/Descargas/libreboot_bin/bin/ encontraremos multitud de archivos ROM, los cuales comprenden diferentes versiones de las BIOS libres para distintos tipos de placa madre/notebooks. En nuestro caso, al disponer de una IBM ThinkPad X60 o X60s emplearemos los archivos ROM contenidas dentro del directorio ~/Descargas/libreboot_bin/bin/x60/. Si tuviésemos una Lenovo T60 deberíamos emplear una de las ROMs dentro del directorio ~/Descargas/libreboot_bin/bin//t60/.

Para ello ingresamos ahora:

cd ~/Descargas/libreboot_bin/bin/x60/

...y buscamos la ROM que corresponda a nuestro equipo según el teclado y características generales. Encontraremos versiones de teclado QWERTY o Dvorak, tanto para los Estados Unidos (us), el Reino Unido (uk), Francia (fr), o Sueco (svenska). También encontraremos versiones de BIOS solo texto ("txtmode") o con gráfica Framebuffer VESA ("vesafb"). En nuestro caso, escogeremos la ROM para la IBM ThinkPad X60 con teclado QWERTY, en inglés estadounidense, con gráfica Framebuffer VESA. Dicho archivo es el designado x60_usqwerty_vesafb.rom.

Como tercer medida, procederemos al respaldar la BIOS original de nuestra Thinkpad X60/Lenovo T60, por las dudas. En vista de ello ingresamos:

cd ~/Descargas/libreboot_bin/flashrom/x86_64/

...y ejecutamos estos dos comandos:

sudo ./flashrom_lenovobios_sst -p internal -r factory.bin 
sudo ./flashrom_lenovobios_macronix -p internal -r factory.bin

Estos dos comandos hará que el sistema lea el contenido binario de la BIOS actual de nuestra portátil y lo grabe en el disco rígido, específicamente en un archivo binario de emergencia llamado factory.bin dentro de la carpeta ~/Descargas/libreboot_bin/flashrom/x86_64/. Conviene pasar este archivo en algún medio extraible como un pendrive, por si tenemos que hacer alguna acción de restauración posterior, o por si algo sale mal.

Primer escritura de la BIOS Libreboot
Completado la serie de pasos previos, escribiremos en la memoria FLash/EEPROM la BIOS libre Libreboot. Para eso debemos ejecutar dos instancias de escritura ("flasheo"). En el caso de la ThinkPad X60 la primer instancia consiste en ejecutar:

cd ~/Descargas/libreboot_bin/
sudo ./lenovobios_firstflash bin/x60/x60_usqwerty_vesafb.rom 

...en cambio, en el caso de la Lenovo T60 la primer instancia consiste ene ejecutar.

cd ~/Descargas/libreboot_bin/
sudo ./lenovobios_firstflash bin/t60/t60_usqwerty_vesafb.rom 

Es primordial aguardar que el proceso de escritura de la BIOS finalice completamente. Tengamos presentes que es normal que el sistema nos devuelva mensajes de error tipo "critical error" durante la ejecución de la escritura de la memoria Flash con la BIOS no original. Debemos ser peronistas y no temer a nada, pues todo habrá de hacerse en aras de la completa liberación. De hecho aparecerán errores si el proceso es exitoso. Por ejemplo podría aparecer el mensaje:
Updated BUC.TS=1 - 64kb address ranges at 0xFFFE0000 and 0xFFFF0000 are swapped.
Si este mensaje no apareciese, no apague la notebook, y corra nuevamente el script correspondiente, o llegado el caso, utilice una versión sin gráfica VESA Framebuffer (por ejemplo, el fichero de ROM llamado x60_usqwerty_txtmode.rom) para la acción de la escritura de la BIOS Libreboot.

Ahora bien, estos errores aparecieron durante el proceso de escritura correcto de LibreBoot.
...Si los errores devueltos en pantalla son aproximadamente los indicados, significará no obstante que se ha tenido éxito. Podrá apagar el equipo (no lo reinicie, apáguelo). Aguarde al menos unos 20 segundos , para asegurar que la memoria RAM se borre completamente. Y luego reencienda el equipo. Libreboot debería arrancar, y si instaló la versión gráfica, lo hará mostrando al fumanchero GNU levitando.

Será este el momento de gritar al cielo un estruendoso ¡VIVA PERÓN!

En la ThinkPad X60 es normal que al arrancar Libreboot por primera vez lo haga con el brillo de pantalla al mínimo. Utilizaremos la combinación de teclas Fn+Home para restituir el brillo al nivel deseado.

Trackpoint
Una vez que arranque Trisquel 7, podremos evaluar el sistema en general y  comprobar que todo funcione. En algunas ocasiones, puede que el que el trackpoint no funcione. En mi caso no me molesta pues el mouse USB funciona perfectamente. Pero en el caso de que deseemos dejarlo funcionando, entramos a la terminal con Ctrl+Alt+T e ingresamos:

cd ~/Descargas/libreboot_bin/nvramtool/


sudo ./nvramtool -w trackpoint=Enable

...y reiniciamos el equipo con:

reboot

Si al arrancar de nuevo aún no funcionase el trackpoint, habremos de hacer un procedimiento específico para nuestro modelo de portáil. Si tuviésemos la IBM Thinkpad X60 podremos probar con:

cd ~/Descargas/libreboot_bin/nvramtool/
sudo ./nvramtool -y ~/Descargas/libreboot_bin/x60cmos.layout -w trackpoint=Enable

...en cambio, si tuviésemos la Lenovo T60, usaríamos:

cd ~/Descargas/libreboot_bin/nvramtool/
sudo ./nvramtool -y ~/Descargas/libreboot_bin/t60cmos.layout -w trackpoint=Enable

Segunda escritura de la BIOS Libreboot
Ahora que tenemos instalado Libreboot, debemos escribir por segunda vez para remover la BIOS IBM/Lenovo original totalmente del sistema. Esto equivaldría a una segunda presidencia de Perón. Para ello abrimos una terminal e ingresamos:

cd ~/Descargas/libreboot_bin/
sudo ./lenovobios_secondflash bin/x60/x60_usqwerty_vesafb.rom

...o si tenemos la Lenovo T60 usamos:

cd ~/Descargas/libreboot_bin/
sudo ./lenovobios_secondflash bin/t60/t60_usqwerty_vesafb.rom

...la terminal debería devolvernos algo como:
Ahora apagamos completamente el equipo, esperamos unos veinte segundos, y lo volvemos a iniciar. Al arrancar nuevamente Trisquel, podremos decir que contamos con BIOS libre y sistema operativo absolutamente libre.
Es en este momento que aprovechamos para remover las etiquetas de Window$ que pululaban el equipo, y los reemplazamos por gran cantidad de stickers de la FSF, Libreboot, Kernel Libre, etc.

Otras mejoras:

Hasta aquí, ninguna de los procedimientos de cambio de la BIOS Libreboot requirió desarmar el equipo. Pero en nuestro caso el empleo del sistema ha demostrado ser tan sólido por medio de software y BIOS 100% libre, que nos hemos propuesto abrir la veterana portátil y hacerle algunas mejoras de hardware. En primer lugar reemplazamos la vieja placa inalámbrica Intel 3945bgn WiFi por una Atheros mPCI Wireless-N. La antigua placa Wifi requería blobs de software propietario (lo que la hacía incompatible con Trisquel GNU/Linux) y calentaba mucho, mientras que la nueva Atheros AR5B91 es reconocida por los controladores absolutamente libres de Trisquel, amén de ser mucho más fría y funcionar con los estandares Wifi N modernos. Su consumo es sensiblemente menor.
Su instalación en el equipo lleva unos 10 minutos, y requiere desatornillar el chassis inferior de la portátil, extraer la placa-teclado y la tapa-chassis con cuidado, y desatornillar la miniplaqueta provista de fábrica con sus dos cable-antenas, para luego reponer  la nueva en su lugar de la misma forma que estaba puesta la anterior.
Como el resto del equipo no presenta dificultades, aprovechamos para higienizar todo el interior del equipo con aire comprimido, colocar nueva grasa siiconada refrigerante al disipador/ventilador de la CPU, lubricar su funcionamiento, y ponerle 2GB SODIMM DDR2 más de memoria, para totalizar unos 4GB de RAM, lo máximo que acepta la placa madre. También cambiamos el disco rígido SATA de 160GB convencional por un rápido disco de estado sólido Kingston SSD de 120GB.
Asimismo, conseguimos una batería de nueva factura del modelo ML:X61, con 8 celdas y 5200 miliamperes de carga, provee y 75 watts/hora.
Volvemos a instalar Trisquel 7 en el SSD (solo tarda 8 minutos en el SSD), y ya contamos con Wifi N libre para mayor comodidad. La plaqueta de Wifi no requiere instalación de software alguna, Trisquel la reconoce sin problemas y nos permite conectarnos a todo tipo de redes wifi. Asimismo, el equipo reconoce la nueva memoria instalada. El buen resultado que nos da el disco SSD Kingston nos hace actualizar un segundo equipo con la misma facilidad que el primero
Solucionar el zumbido de la notebook.
La BIOS Libreboot provoca la emisión de ciertos ruidos de zumbidos agudos de la CPU en ocasiones, lo cual no deja de ser molesto. Afortunadamente tal problema está documentado y se soluciona a través de un software librellamado powertop.

En cualquier distribución derivada de Debian podremos instalar Powertop desde la terminal, con los siguientes comandos:

sudo apt-get update
sudo apt-get install powertop
sudo powertop --auto-tune

También lo podemos ejecutar sin parámetros, y luego ir a la opción "Tunables" y disponer todas las opciones que aparezcan en "good".

Ahora bien, si usamos Trisquel anterior a la versión 7, como por ejemplo el Trisquel 6 Tutatis, la versión de Powertop que cargue el sistema será algo vieja, debemos ejecutarla al arranque. Para ello Libreboot cuenta con un script específico. Abrimos una terminal y corremos los siguientes Comandos de Organización:

cd /Descargas/libreboot_bin/
./powertop.trisquel6

Este script preparará al comando powertop para que se ejecute toda vez que se dé inicio al sistema.

En todo caso, habremos de tener en cuenta que powertop no funcionará inmediatamente, debe recoger ciertos datos antes de implementar sus características, las cuales se almacenarán en /var/cache/powertop/saved_parameters.powertop. Deje al equipo trabajando con la batería por un tiempo, y powertop comenzará a funcionar correctamente luego de algunos minutos.

Actualizar Libreboot BIOS:

Una vez que tenemos instalado la BIOS Libreboot, será mas sencillo cargar una nueva versión de la misma en el futuro. Simplemente debemos descargar la nueva versión como hicimos inicialmente, y luego ejecutar el comando flash para escribir la BIOS, de la siguiente manera:


cd ~/Descargas/libreboot_bin/
sudo ./flash bin/ruta/de/bios/nueva/