A01. VERIFICAR SOFTWARE: Guía para todos los públicos

El quién es quién del software que descargamos de internet

Resumen

En este artículo exploramos qué es y por qué verificamos un software a través del uso de claves públicas y firmas criptográficas de sus desarrolladores. Analizamos los elementos que necesitamos para llevar a cabo este proceso en las dos variantes más comunes que encontramos en el software bitcoin:

con firmas realizadas sobre el ejecutable

con firmas realizadas sobre un archivo de hashes del ejecutable

Y también explicamos cómo verificar la clave pública de un desarrollador para saber que realmente es suya.

Si lo que buscas es conocer la parte práctica del "cómo" hacer una verificación de software, puedes saltar directamente a los artículos concretos de cada sistema operativo de a continuación.

Links a guías de verificación

Verificar en Windows

Link usando Kleopatra

Verificar en macOS

Link usando Terminal

Link usando gpgtools

Verificar en Linux

Link usando terminal

Introducción

Cuando instalamos un nuevo programa en nuestro ordenador:

¿cómo sabemos si lo que estamos instalando es realmente lo que queremos instalar y no una copia maliciosa que busca enviar información personal fuera de nuestro dispositivo?

¿estamos seguros de que la web desde donde nos hemos descargado el software es la verdadera y no una url de Phishing?

Esto que ya es preocupante de por sí cobra especial relevancia cuando hablamos de software bitcoin. En este artículo te contamos todo lo que has de saber para no caer en la trampa y mantener tu ordenador libre de software que pueda hacerte perder satoshis.

En esta guía desarrollamos:

qué es verificar software

por qué lo hacemos

qué elementos necesitamos

y cómo hacerlo en Windows, Mac y Linux

Qué es verificar software

Verificar software es el procedimiento por el cual conseguimos tener certeza de que el programa que vamos a instalar/ejecutar en nuestro ordenador es realmente el que queremos instalar y no una copia fraudulenta en búsqueda de datos, recursos de nuestro dispositivo o bitcoin.

Cuando verificamos software, conectamos en una operación la identidad criptográfica de uno o varios de sus creadores al ejecutable de una aplicación (.exe, .dmg, .deb, etc). Así, comprobamos si el grupo de desarrolladores que nosotros damos por válido, ha sido realmente el responsable de crear ese ejecutable concreto.

De esta forma, podemos instalar algo que hemos descargado de internet, sabiendo al 100% que nadie ha manipulado su contenido sin que los desarrolladores hayan dado su visto bueno.

Por qué verificamos

Verificamos software para:

instalar lo que esperamos instalar (y no una app de phishing maliciosa)

comprobar la integridad de lo descargado (que no le falte ni 1 byte)

y en definitiva, en un contexto bitcoin, para mantener nuestro ordenador lo más limpio posible de malwares, que pondrían en riesgo nuestro equipo, privacidad y seguridad de fondos.

Qué elementos necesitamos

Para verificar un software vamos a necesitar 4 o 5 cosas:

la clave pública del desarrollador lo más verificada posible

una herramienta de claves PGP para realizar la comprobación.

el ejecutable que vamos a verificar

un documento con la firma del desarrollador sobre ese ejecutable

posiblemente un archivo .txt con hashes en su interior

Claves públicas:

La clave pública es en cierta manera la cara visible de la identidad digital de una persona. Algo así como la foto de pasaporte que revisa un agente de fronteras para verificar si eres tu la persona que dice el documento, o no. En nuestro caso, de lo que nos sirve es para verificar si la firma que el desarrollador realizará sobre la aplicación que queremos instalar, coincide con esa identidad.

En la próxima sección se explica cómo identificar y descargar la clave pública correcta.

Herramienta PGP:

Para llevar a cabo las operaciones de comprobación, necesitaremos una aplicación de PGP (pretty good privacy) para nuestro sistema operativo. Esto nos añadirá un llavero para almacenar claves públicas de desarrolladores y también la lupa con la que verificaremos tener el software correcto.

Más abajo veremos su funcionamiento en cada sistema operativo (OS).

El ejecutable:

No tiene mayor secreto. Descargamos la aplicación que deseamos utilizar y la guardaremos en una carpeta común junto al documento de firma.

La firma:

La firma es el documento que tendremos que localizar en la misma web desde donde estamos descargando la aplicación. Este documento suele venir en extensión .sig o .asc y puede haberse aplicado sobre la App o un documento adicional con hashes. La teoría de estas dos formas de proceder se desarrolla más abajo.

Documento con hashes

El documento con el resumen de hashes suele ser un archivo de texto (o incluso sin extensión como en bitcoin core) donde se especifica el hash.

Como explica Cristina Pérez Solà y Jordi Herrera Joancomartí en https://criptografia.cat/, una función hash de tamaño n es una función que toma como entrada un mensaje (o cadena) de tamaño arbitrariamente grande y devuelve una cadena de tamaño fijo n. Además, una función hash es calculable eficientemente y determinista, es decir, dadas dos entradas iguales, siempre nos proporcionará la misma salida.

Verificando la veracidad de una clave pública

En la aplicación PGP de nuestro sistema operativo vamos a ir añadiendo a nuestro llavero (así es como se llama) las claves públicas de los desarrolladores del software que queramos instalar.

Estas claves públicas representan la identidad de estos devs y nos servirán para contrastar que la firma que hemos descargado haya sido realizada por el desarrollador esperado. Por ello, añadir la clave pública correcta es capital para evitar instalar software malicioso de un tercero.

Pero ¿cómo podemos estar seguros que descargamos la clave pública correcta?, ¿y si un atacante ha tomado el control de su web y ha sustituido su clave pública?

Pues bien, para poder contrastar una clave pública hay varias formas. Algunas viables solo a través del mundo físico, y otras, a través del virtual. Pero antes de entrar en el "cómo", hablemos de la anatomía de las Claves Públicas.

Anatomía de una clave PGP

Las claves públicas PGP son un bloque de texto bastante grande:

Este es el formato que se utiliza para transportar la clave de un lado a otro. Puedes encontrarlas así en webs como la de Estudio Bitcoin o también, para mayor comodidad, ya almacenadas en un archivo de texto como un .pub.

Como las claves son bastante grandes, se utilizan 3 tipos de formatos comprimidos para poderlas identificar y referenciar de forma fácil

fingerprint: 0D69 E11F 12BD BA07 7B37 26AB 4E1F 799A A4FF 2279

long id: 4E1F 799A A4FF 2279 (los últimos 16 dígitos del fingerprint)

short id: A4FF 2279 (los últimos 8 dígitos del fingerprint)

Una Clave completa permite la generación de su fingerprint, long id y short id. Así, los desarrolladores pueden cargar su clave pública en su sitio web y promocionar solo el fingerprint en diversos canales como Twitter, Keybase u otras presentaciones públicas. Este enfoque evita la necesidad de mostrar un bloque completo de la clave pública, que puede ser difícil de recordar o identificar. Los usuarios pueden contrastar fácilmente el fingerprint proporcionado, por ejemplo, en Twitter, con el que calculan por sí mismos a partir de la Clave Pública completa descargada desde el sitio web del desarrollador.

Contrastando una clave pública

La mejor forma que tienes de contrastar una Clave Pública que has descargado de internet (por ejemplo de su web personal) es haciéndolo cara a cara con el desarrollador.

Como esta opción no es fácil de realizar, la idea es sumar tantas verificaciones online como sea posible, accediendo y revisando su Clave (o resumen de ella) en tantos canales de comunicación como sea posible.

Algunas ideas:

en su descripción de twitter

en su cuenta de Keybase

en su GitHub

en su web personal

al principio o final de una presentación publicada en vídeo en Youtube

Luego aprenderemos a cómo generar fingerprints, long y short ids desde una Clave Pública completa en cada sistema operativo y así podremos contrastar todas estas migas de pan que los desarrolladores nos van dejando, con las Claves Públicas que hemos descargado y que utilizaremos para verificar nuestro software.

Contrastar Claves Públicas es una parte clave en la verificación de software.

Dos formas de firmar

1- Firmas aplicadas directamente sobre el ejecutable

Cuando la firma se ha aplicado sobre el ejecutable, solo tenemos un documento a descargar (el .sig o .asc) y el desarrollador ha procedido de la siguiente forma:

ha compilado su código en un ejecutable de aplicación (la app)

ha practicado un proceso de firma criptográfica con su clave privada (solo él la tiene) sobre la aplicación

y esto le ha generado un archivo de firma .sig o .asc que a subido a su web o github

El resultado de este proceso son 2 archivos

1 archivo de aplicación (el ejecutable)

1 archivo de firma

Cuando un usuario va a verificar el origen de esta aplicación que descarga de internet:

primero añade la clave pública del desarrollador a su llavero PGP

le pide al verificador PGP que compruebe que ese archivo de firma se ha realizado sobre ese ejecutable (app) y no otro

y de ser así, comprueba si la clave privada que ha realizado esa firma es la misma que generó la clave pública que hemos descargado y añadido al llavero. Este último proceso lo podemos hacer sin tener la clave privada del desarrollador, solo sumando aplicación, firma y clave pública.

Este sistema tiene como inconveniente que si la aplicación sobre la que se ha hecho la firma es muy grande, entonces la verificación es más demandante a nivel CPU en todos los ordenadores que lo verifiquen. No debería ser traumático, pero es poco eficiente. Por esta razón se suele firmar un documento intermedio con un resumen de hashes.

2- Firmas aplicadas sobre un documento de texto intermedio con hashes

Cuando se ha aplicado sobre un documento intermedio con el resumen de hashes, el desarrollador ha procedido de la siguiente forma:

ha compilado su código en un ejecutable de aplicación (la app)

ha practicado un Hash sobre la aplicación (en bitcoin suele usarse el sha256) y ha anotado el resultado en un archivo de texto con título aleatorio (suele ser algo así como sha256sum.txt, hash.txt o similar)

ha practicado un proceso de firma criptográfica con su clave privada sobre el archivo de texto del hash (no de la aplicación)

y esto le ha generado un archivo de firma .sig o .asc que a subido a su web o github (sha256sum.asc por ejemplo)

El resultado de este proceso son 3 archivos:

1 archivo de aplicación (el ejecutable)

1 archivo de resumen de hashes

1 archivo de firma

Cuando un usuario va a verificar el origen de esta aplicación que descarga de internet:

primero añade la clave pública del desarrollador a su llavero PGP

realiza una operación de hash sobre el ejecutable. Esta operación es mucho menos demandante a nivel CPU que verificar un archivo grande.

con el hash en pantalla, abre el archivo sha256sum.txt (o el nombre que tenga) y comprueba que coincidan. Si es así, está garantizando la integridad pero todavía no sabe si quien ha realizado el ejecutable y el hash es el desarrollador que espera.

entonces le pide al verificador PGP que compruebe si la firma hecha sobre el txt del hash es correcta y si se ha realizado utilizando la clave privada que generó la clave pública que hemos descargado y añadido al llavero. De nuevo, en este último no necesitamos la clave privada del desarrollador, solo sumamos aplicación + firma + clave pública.

Esta forma de proceder es mucho menos demandante a nivel CPU al tener el archivo de texto con el hash, mucho menor tamaño que el ejecutable. Igualmente, nos encontraremos con las dos formas de verificación y por eso es bueno conocerlas.

En conclusión, no deberiamos instalar ningún software sin antes verificar. Si el proveedor del ejecutable no facilita los elementos necesarios para tal fin (por ejemplo no suministra la firma o la clave pública), es bueno enviarle un mensaje o email y exigírselo. Es una buena práctica que todo creador de software debería seguir.

No deberiamos instalar ningún software sin antes verificar. Si el proveedor del ejecutable no facilita los elementos necesarios para tal fin (por ejemplo no suministra la firma o la clave pública), es bueno enviarle un mensaje o email y exigírselo. Es una buena práctica que todo creador de software debería seguir.

Lo que puede ir mal incluso verificando

Con todo esto sobre la mesa, también debes saber que aunque verifiques no te proteges 100% frente a un ataque. Varias cosas podrían haber ido mal como por ejemplo:

si hemos añadido a nuestro llavero PGP una clave pública incorrecta, estaremos verificando con la identidad incorrecta,

si al desarrollador le han sustraído su clave privada, cualquiera podría subir una aplicación fraudulenta en su nombre sin que la verificación nos salga errónea,

o si el desarrollador se vuelve malvado y desea crear un código malicioso, también pasaría desapercibido en la verificación.

Para que el primer punto, buscaremos diferentes fuentes online y físicas (si es posible), donde encontrar la clave pública del desarrollador y verificar que coinciden. La lógica detrás de esto es que quizá al desarrollador le puedan haber hackeado una cuenta, pero que lo hayan hecho con todas es más improbable.

Las fuentes online pueden ser diferentes redes sociales como twitter, telegram, keybase, etc, repositorios como github o apps de mensajería si es que tenemos un contacto directo con el desarrollador.

Las fuentes físicas pueden ser encuentros donde participen esos desarrolladores y donde podamos pedirle que nos verifique su clave pública. Esta es la mejor forma de tener certeza de que una clave pública realmente pertenece a un desarrollador concreto. Pero no siempre es posible. En estas "fiestas de firmado de claves" también se crea un "red de confianza" que permite confiar en claves públicas que uno de tus contactos verificados ya haya comprobado.

Para el segundo punto, es muy probable que el desarrollador haya emitido un certificado de revocación y que este sea accesible en redes sociales o un servidor de claves PGP. Pero a decir verdad, es bastante improbable que estemos verificando las claves que tenemos en nuestro llavero con lo que lo más razonable es echar un vistazo a las redes sociales del desarrollador antes de hacer alguna actualización importante o sensible.

En el caso de que el desarrollador se convierta en un mal actor, la única salida sería revisar el código en su repositorio y compilar desde la fuente (en caso de tener un repositorio abierto). De hacerlo así, sí podríamos detectar los cambios y valorar si se está haciendo un cambio malicioso. Y de hecho es lo que acaba sucediendo. Alguien acaba dándose cuenta y alertando al resto. Pero la gran mayoría de la gente no parte de este tipo de conocimiento, ni tiempo que dedicarle. La mejor forma de solucionar esta posible vulnerabilidad es no actualizar rápidamente a nuevas versiones a menos que te sea estrictamente necesario. Deja pasar un tiempo como para que alguien experimentado le eche un vistazo al código.

Conclusión

No deberiamos instalar ningún software sin antes verificar. Si el proveedor del ejecutable no facilita los elementos necesarios para tal fin (por ejemplo no suministra la firma o la clave pública), es bueno enviarle un mensaje o email y pedírselo. Es una buena práctica que todo creador de software debería seguir.