Protegiendo tu autoría digital frente a fraudes
Imagen generada con ImageFX de acuerdo a sus condiciones
En cierta ocasión, un imberbe y bien intencionado profesional, oriundo de una región tercermundista, se vio en la penosa obligación de ser especialmente cuidadoso, (para ser más preciso, a un grado casi paranoico), con un archivo de texto que había creado, o más exactamente, con la forma de garantizar o verificar, primero, que él era el autor de ese escrito, y segundo, que su contenido era de la forma que él afirmaba. Todo esto más allá de la veracidad “incuestionable” de su palabra.
Esta situación podría producirse en varios contextos, pero vamos a suponer que sucedió de la siguiente manera. Un día cualquiera, este personaje debía enviar ese trabajo, de forma obligatoria, a personas que pertenecían a una institución cuyos máximos directivos gozaban de una reputación no muy buena: estaban implicados en todo tipo de embustes y falacias, con mucho éxito a decir verdad, y además, tomando en cuenta que poseían una destacada influencia en las instancias judiciales. Digamos que este pobre bisoño debía hacer aquello de enviar el fichero, ya sea porque era parte de su empleo, o más bien, debido a un descuido por el cual había terminado envuelto con esta gente en un trabajo colaborativo, que además iba a ser publicado 😬.
Ante esa espeluznante tesitura, el desventurado letrado decidió consultar diversas fuentes versadas, ya sea en propiedad intelectual o ciberseguridad, indagando sobre qué podría hacer para resguardar su autoría y reputación, tomando en cuenta el potencial manejo inadecuado de su obra y el posible uso deshonesto de su prestigio profesional.
Lo que le comunicaron esos eruditos queda registrado a continuación, con fines de archivo 😁.
Falsificación y falsedad ideológica
Las personas pueden usar de manera deshonesta la información, por ejemplo, sacando de contexto algunas frases para distorsionar el verdadero mensaje y manejar esto a su favor, esto se llama falsedad ideológica. Para evitar esta posibilidad, en el caso de un texto, se puede redactarlo de tal forma que los falaces se vean en la obligación de descartarlo.
Por ejemplo, si existe desconfianza de que un entrevistador vaya a hacer una interpretación errónea de las respuestas de su fuente, a favor de su propio punto de vista, el entrevistado puede previamente hacer una suposición de sus intenciones y actuar contra estas. Digamos que la entrevista se trata de los riesgos y beneficios de la ingesta de espinacas en la dieta diaria (un ejemplo aleatorio, no tengo nada en contra de las espinacas, de hecho me gustan 🙂), y el entrevistador es un promotor en contra de esta práctica. Ante esa circunstancia, habrá que evitar frases tipo “consumir espinaca tiene sus riesgos y beneficios, como tales y tales”. En este caso, el entrevistador deshonesto podría citar las partes del mensaje que se adecúan a su punto de vista y así distorsionar el verdadero sentido del mismo para reforzar su causa con este testimonio. Entonces, conociéndose previamente esta mala intención, al entrevistado le sería más útil citar solamente los puntos contrarios a la visión del entrevistador, provocando así, que este se vea en la obligación de descartar la totalidad de su mensaje o animarse a criticar abiertamente su sentido. En el ejemplo anterior, hablar solamente de los beneficios de consumir espinaca.
Pero este no es un tutorial acerca del arte del discurso, sino más bien para afrontar una amenaza más retorcida: que los adversarios, en vez de cometer falsedad ideológica se pongan creativos y directamente falsifiquen el texto, es decir, alteren de forma total o parcial el contenido original, re-adecuándolo a su favor y argumentando que esa distorsión es el escrito original y no el que realmente hizo el autor. Otra terrible opción también es el plagio y las recomendaciones que vienen a continuación, también son útiles en ese contexto, aunque no se aborda ese delito en este escrito. En este horrendo caso hipotético, el creador se vería en la penosa obligación de denunciar públicamente esa falsificación, sin embargo, aquí viene la gran pregunta del inicio de esta entrada, dado el talante moral de estas personas: ¿cómo puede alguien demostrar que el escrito que presentó es inequívocamente suyo y, además, que fue enviado y recibido por los falsificadores en las condiciones que asegura que fue enviado? 🙄. Una pregunta tan desmoralizante que da ganas de responderla con otra pregunta: ¿qué tan desalmado tiene que estar este mundo, para que un individuo se vea en la obligación de demostrar que lo verdadero es verdadero porque los que controlan las instituciones sostienen que lo falso es verdadero?
Si bien, tengo muchas ganas de desarrollar ese tema de naturaleza ética en una futura publicación, como mencioné, en esta ocasión me siento más pragmático y voy a presentar específicamente lo que se puede hacer respecto a lo anteriormente cuestionado: Primero, hay que obtener terceros “neutrales”, ya sean, personas o instituciones, que den fe de la transferencia real del archivo y su contenido; luego, para reforzar aquello, y tomando en cuenta que estamos lidiando con un documento de naturaleza digital, hay que utilizar herramientas de ciberseguridad.
Evidencia a través de personas naturales o jurídicas
Correo electrónico
El primer paso es el más fácil, con enviar el archivo de texto adjuntado a un correo electrónico dirigido al destinatario, y a su vez, con copia visible u oculta a terceros, se logra involucrar a otras personas en el proceso, como testigos. Y al mismo tiempo, estaría resuelta también la cuestión de la verificación institucional, porque las cuentas de correo, casi siempre, son usuarias de una institución, que es la que proporciona el servidor de correo; además, este procedimiento se realiza mediante la garantía de certificados digitales que verifican la emisión y recepción de los mensajes a través de los servidores asociados a un dominio institucional o personal.
Hasta ahí todo bien, pero donde se presenta cierta complicación técnica y jurídica es en que las cuentas de correo convencionales no certifican de manera digital: primero, la identidad de los usuarios dueños de las cuentas de correo; luego, si bien, verifican que el servidor de correo recibió el mensaje, no demuestran que el destinatario lo leyó; y finalmente, aunque existe una autenticación firmada, asociada a la identidad de dominio institucional del servidor del correo, y por tanto, de la integridad del mensaje, esta no está vinculada a la identidad del remitente. Esto último es bastante sensible, por ejemplo, en el marco del correo institucional de una empresa, donde personal informático corrompido, por citar un caso, podría enviar correos a nombre de un funcionario sin el conocimiento de este, el cual, lamentablemente poseería las credenciales institucionales de dominio válidas. En este ejemplo extremo, y seguramente poco probable en casos reales, aunque no imposible, se percibe la necesidad de obtener una certificación digital asociada a la identidad del usuario.
Llegándose al extremo de un litigio por falsificación, el demandante se vería obligado a encargar un peritaje informático de los certificados de un correo electrónico enviado, para verificar en este caso, SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) y DMARC (Domain-based Message Authentication, Reporting and Conformance). Es probable que una vez cotejadas estas verificaciones digitales y, sumados los testimonios de los testigos a los que se envió copias visibles u ocultas del archivo, a la par del destinatario original, esta sea suficiente evidencia para demostrar, tanto la integridad del documento como su autoría original, ante una extremadamente cínica falsificación por parte de los demandados. Sin embargo, y esto es sorprendente, existe la perversa posibilidad de que aquellas exhaustivas evidencias no sean suficientes, como lo demuestran ciertos ejemplos de la justicia española, en los que la defensa se puso demasiado ingeniosa con este tema de las identidades digitales 😨. Para este extremo sinuoso, son necesarias ciertas medidas adicionales de ciberseguridad.
La única forma de resolver plenamente esto es poseyendo una cuenta de correo electrónico que permita certificar la identidad del usuario a través de una firma criptográfica digital, la cual, como se mencionó antes, es distinta a la firma de dominio de la institución que brinda la cuenta de correo electrónico, y este tipo de cuentas no suelen ser proporcionadas por servicios convencionales como los de Gmail y similares. Estas cuentas de correo especializadas, además de los certificados anteriormente mencionados, permiten el cifrado y firmado de correos a partir de mecanismos de autenticación como S/MIME o GPG, que están vinculados a la identidad digital de los usuarios.
Yo personalmente cuento con un correo que permite cifrar y firmar los mensajes mediante GPG y tengo una firma digital creada hace años (esta es la clave pública), pero en realidad nunca me vi en la obligación de usarla con motivos legítimos. Durante un tiempo, firmé mis mensajes de correo sin necesidad, más por jugar con el mecanismo que por otra cosa, sin embargo, decidí dejar de hacerlo debido a que casi la totalidad de mis contactos usa Gmail como proveedor de correo, y como mencioné, este servicio no admite autenticaciones digitales vinculadas al usuario, por tanto, la firma que enviaba en mis correos se visibilizaba en las cuentas de mis destinatarios como un archivo adjunto con extensión .asc. Un administrador de correos adecuado, como Mozilla Thunderbird u Outlook, por ejemplo, al recibir un mensaje firmado visualizaría más bien una alerta que informe que el correo está certificado a mi nombre, ofreciendo opciones al receptor para verificar mi firma. En el caso de Gmail, con ese “archivo raro” adjunto a mis correos, mis receptores más bien solían interrogarme, con una razonable desconfianza, sobre la posibilidad de que les esté enviando un archivo malicioso 🥺.
Como afirmé anteriormente, si bien, una cuenta de correo convencional, como la de Gmail, proporciona una buena base de certificaciones para verificar la integridad del correo y con cierto esfuerzo adicional, se podría verificar, a partir de ella, incluso la identidad del usuario, no está de más contar con una firma digital personal como mecanismo adicional de seguridad, en el caso remoto, pero no imposible, de lidiar con psicópatas poderosos 😵. Más adelante, en este tutorial, indicaré como se puede convertir una cuenta de correo de Gmail en una cuenta con capacidad de firmado y cifrado de correos.
Mensajería instantánea y almacenamiento en la nube
Ahora, vamos a suponer que el archivo debe enviarse a través de un servicio de mensajería instantánea como Whastapp o Signal, y no por correo electrónico. Pues bien, en ese caso, por un lado, hay buenas noticias, porque esos servicios, además de ser muy amigables con el usuario, cuentan también con mecanismos sofisticados de cifrado y autenticación fuertemente vinculados a la identidad personal, específicamente a partir del número telefónico, registrado a su vez con relación al número de identidad personal del usuario, que tampoco es algo infalible, dando pie a todo tipo de suplantaciones.
Si bien, estas plataformas tienen mayores ventajas frente a un correo convencional, en cuanto a identificación del usuario, con eso no estoy sosteniendo que las instituciones deberían reemplazar sus comunicaciones a través de correo electrónico en favor de los servicios de mensajería instantánea, como sucede bastante en la actualidad. Si bien, los servicios de mensajería instantánea suelen tener, de forma predeterminada, mecanismos de identificación del usuario más robustos que un correo electrónico convencional, como Gmail, por ejemplo, un correo electrónico, certificado de la forma narrada en el anterior inciso, tiene verificaciones más complejas que un servicio de mensajería instantánea (desde las de dominio y firmas digitales explícitas, hasta las direcciones IP del emisor y receptor), que son más adecuadas para casos formales, sobre todo institucionales.
Dejando de lado estas cuestiones ya abordadas en el anterior apartado, creo que en este caso, la principal vulnerabilidad respecto a nuestro tema de autenticidad y verificación de un archivo enviado entre contactos, es el hecho de que al enviar un documento por mensaje, si el archivo original (en el caso del remitente), o el archivo descargado (en el caso del destinatario), es eliminado del almacenamiento interno del dispositivo, existe una alta posibilidad de que ya no se pueda recuperar. Centrándonos solo en el caso de Whatsapp, que es la aplicación de mensajería más popular en este momento, si sucede esto, la plataforma guardará por un tiempo limitado el archivo en sus servidores, y cuando pase ese tiempo, el momento en el que se desee volver a descargarlo, simplemente aparecerá el siguiente mensaje:
Captura de pantalla de una notificación de Whatsapp en Android
Continuando con el ejemplo de esta entrada, que es el caso de querer demostrar que un archivo fue enviado de la forma en que afirma el remitente, no poder recuperar el archivo mandado constituye un serio problema para su caso. Sin embargo, la solución es la siguiente: no hay que compartir el archivo mediante el mecanismo nativo de la aplicación, sino, enviarlo a través de un enlace a una cuenta de almacenamiento “en la nube”. Este tipo de cuenta no eliminará el archivo automáticamente y además guardará un excelente registro de la creación y modificaciones que se hacen al fichero de forma cronológica. Existen varios servicios, pero en este caso, solo comprobé personalmente el de Google Drive y me funcionó muy bien.
Es interesante que el enlace público que genera Google Drive para cada archivo compartido, posee un código único de archivo, el cual se encuentra luego de la sección "/d/" de la cadena de caracteres. Esto es importante para la identificación inequívoca del fichero, en caso de disputa legal. Pero existe una vulnerabilidad respecto a esta filiación, ese vínculo singular del fichero continúa siendo el mismo a pesar de que el creador del archivo modifique los datos, lo que permitiría que los acusados de falsificación argumenten que el creador cambió su fichero original para difamarlos. Para evitar esto, la cuenta de Google Drive proporciona un historial detallado de las modificaciones que se hicieron al archivo, por orden cronológico. Esa herramienta es tan fiable que, por ejemplo, si el administrador de la cuenta intentaría alterar manualmente los metadatos del archivo en su computadora, por citar un caso, falsificando la fecha de la última modificación del fichero, para luego subirlo a Drive y que la cuenta valide esa fecha errónea, Drive no tomaría en cuenta esta fecha falseada y registraría más bien la fecha de la carga del archivo, para expresarla como fecha de modificación real.
Entonces, ante una disputa por la autoría e integridad de un archivo enviado por Whatsapp se podría mostrar el chat de la aplicación, donde figura el enlace a una cuenta de almacenamiento, que como se mencionó, posee un código único que identifica el archivo. Este archivo presentará metadatos importantes como fecha de creación del archivo, de modificación y además el usuario propietario.
Probablemente, como en el caso del correo electrónico, ante una disputa legal estos procedimientos serían suficientes para demostrar la autoría e integridad de un archivo enviado, aunque, requerirían de cierto trabajo adicional de parte del propietario para validar su identidad en torno a la creación y propiedad del archivo, así como su envío al contacto con el que se tiene la disputa. Sin embargo, como sucedió en el caso de los correos, estos procedimientos adicionales podrían dar pie a otras controversias técnicas enrevesadas susceptibles de manipulación, como comparación de archivos, fechas de creación, modificación, contenido, usuarios de la aplicación de mensajería y usuario de la cuenta de almacenamiento en la nube, así como identidades. Posiblemente, también en este caso, no estaría de más adicionar mecanismos criptográficos y de autenticación digital a las verificaciones citadas, asociados a la identidad del usuario, para confirmar de forma directa, inequívoca, e incluso automática, su autoría sobre un fichero digital.
Integridad digital e identidad criptográfica
Existen dos formas muy certeras de, primero, garantizar la integridad de un archivo mediante un mecanismo que se llama suma de verificación, y luego, firmar el archivo de forma criptográfica, es decir, verificar el estado preciso de sus datos y asociarlos con la identidad digital de una persona, en este caso, el creador. Estos dos procedimientos son complementarios, si bien, la firma de un archivo garantiza que el fichero no fue modificado y esta situación está vinculada a la identidad del creador, este método suele ser un poco complejo de certificar por parte de la mayoría de los usuarios y al mismo tiempo, no hace explícito el informe de integridad de forma legible para humanos. Por tanto, ese proceso suele acompañarse de un segundo procedimiento de certificación de suma, que asocia un código único de forma explícita al estado del archivo sobre la base de sus bits, siendo relativamente fácil de comprobar para cualquier usuario y constituyendo, además, una capa extra de verificación.
Entiendo lo complejo del tema, pero para visualizar mejor estas ideas creo que es mucho mejor citar un ejemplo conocido actualmente, el cual, además servirá para demostrar la utilidad práctica de estos mecanismos.
Todos estamos acostumbrados a descargar programas de Internet, a tal punto que muchas personas ni siquiera tienen precauciones mínimas respecto a la fuente de donde están bajando esos instaladores, que de provenir de espacios alternativos a los de sus creadores podrían haber sido modificados por terceros de manera maliciosa, para que una vez alojados en el ordenador del usuario, inicien procedimientos nocivos distintos a los esperados, como publicidad no deseada o incluso mecanismos para espiar la actividad del propietario del ordenador o dañar el sistema en sí. Véase el dramático caso de Softonic, un sitio de descargas anteriormente exitoso que centralizaba instaladores para Windows, al modo de una AppStore, pero que cayó en desgracia al verificarse que distribuía configuradores modificados para alojar código dañino para los intereses de los usuarios. Luego de conocer ejemplos como este, los más precavidos saben que necesariamente hay que dirigirse a la página oficial de los creadores para descargar el instalador original, pero lo que pocos saben es que ni siquiera esto es una garantía segura de fiabilidad y a continuación presento un sobrecogedor ejemplo para demostrarlo 😱.
En 2016, los servidores de una de las distribuciones Linux más populares del mercado, llamada Linux Mint, sufrieron una vulneración a cargo de personas malintencionadas, que lograron reemplazar el instalador .iso de la distribución, publicado en su página web, por una copia modificada con código malicioso insertado, la cual, lamentablemente, fue descargada por varios usuarios en el lapso de tiempo anterior al que el equipo de Linux Mint denunció esto y demoró en recuperar su infraestructura para reponer la copia original. La gravedad de este evento marcó un punto de inflexión en la forma en la que ahora se distribuyen los instaladores, no solo de las distribuciones Linux, sino, sobre todo, del software de código abierto: ahora no solamente se suele publicar el instalador en sí, con información detallada de la fecha de su creación, sino que también se lo suele acompañar de otro archivo con extensión .sha256 u otros formatos, cuyo propósito es almacenar un código único llamado hash, el cual fue generado a partir de los bits del instalador. Este código, precisamente, garantiza la integridad del archivo a partir del cual fue generado, ya que si este sufriera alguna modificación, el hash que se obtiene a partir de él sería muy distinto al del original, porque este código es irrepetible, entonces de esta manera se comprobaría su vulneración. Y a su vez, a la par de esos archivos, se suele acompañar un tercer archivo que es una firma digital personal o institucional, en ciertas ocasiones, del instalador, y en otras (según criterio del creador), del archivo de verificación de integridad. Esta firma criptográfica, imposible de vulnerar, si se siguen los procedimientos correctos, es una segunda verificación, no solo de la integridad del archivo, sino una garantía de autoría del creador. Véase como ejemplo la forma en que la distribución Debian GNU/Linux dispone sus instaladores con los archivos de certificación narrados anteriormente y presenta un tutorial de verificación de la descarga.
Ahora bien, el propósito de este apartado no es seguir contando historias, sino explicar detalladamente cómo se puede generar el hash SHA256 de un archivo, a modo de verificar su integridad, y luego firmar dicha verificación con una clave digital. Por tanto, primero hay que aprender a generar una firma digital. Vamos por partes.
Firma GPG
Los procedimientos que narraré a continuación pueden realizarse en Linux, Windows o macOS, sin embargo, en todos los casos nos veremos en la necesidad de abrir la consola, al menos en la mayoría de los procedimientos. Por otro lado, explicaré los procesos priorizando su aplicación en Linux, pero, pueden replicarse en Windows y macOS una vez instalados los programas ahí.
Pretty Good Privacy (PGP), es un programa diseñado para generar claves criptográficas y firmas digitales y fue desarrollado por Phil Zimmermann en 1991. Lamentablemente, la creación inicial de ese software no tenía una licencia abierta, es decir, de distribución libre y sin restricciones de modificación, y, por tanto, acarreaba conflictos legales por sus altos impedimientos. En ese sentido, ante la necesidad masiva que existía de usar cifrado y firmas digitales, por parte de otros programas, el creador de PGP decidió desarrollar OpenPGP como un estándar abierto de Internet Engineering Task Force (IETF), el cual sirvió de base para el desarrollo de un nuevo software que se propuso reemplazar a PGP, pero esta vez bajo una licencia de software libre, a cargo del Proyecto GNU, de nombre GNU Privacy Guard (GPG).
La mayoría de las distribuciones Linux, entre las que están las más populares, como las derivadas de Debian, Fedora y OpenSUSE, tienen GPG instalado por defecto, ya que esta herramienta se usa precisamente para verificar la firma de los programas disponibles en sus repositorios. Así por ejemplo, si una aplicación descargada del centro de software de la distribución fue vulnerada o no fue correctamente firmada, el sistema operativo verificará esto y se negará a instalarla. De todas formas, la herramienta que explicaré a continuación puede instalarse tanto en Windows como en macOS.
En el caso de Windows se pueden descargar las utilidades GPG en un instalador acondicionado para este sistema (ver el siguiente tutorial), contando con una herramienta gráfica llamada Kleopatra, que está disponible también para Linux. Mientras que en macOS, necesariamente habrá que instalar Homebrew, el repositorio universal de paquetes compatible con macOS y Linux, para después instalar GPG con un procedimiento parecido al que se haría en Linux para instalar el programa. También existe una interfaz gráfica para macOS, llamada GPGTools la cual es explicada en este otro tutorial. Si bien, los recursos que se indicarán luego, pueden realizarse de una forma gráfica, además con diversos programas, en esta explicación se preferirá el uso del emulador de terminal: primero, debido a que ese es el procedimiento que yo me acostumbré a usar 😁; segundo, porque observo que la manera gráfica tampoco es más fácil que la anterior; y, tercero, los comandos que se enseñarán para Linux pueden replicarse tanto en Windows, a través del Símbolo del sistema o de PowerShell, como en macOS, en su propia terminal; en ambos casos, luego de haber instalado los programas anteriormente reseñados.
Asumiendo que GPG está correctamente instalado en el sistema, el primer paso es generar una nueva clave. Existe una forma fácil y resumida y una más detallada y profesional, vamos a optar por la segunda opción, debido a que la forma predeterminada no nos permite crear una clave de la manera más robusta posible, que es de 4096 bits.
Luego de ejecutar el comando, aparecerá el siguiente diálogo, que debe ser respondido de la siguiente manera, exceptuando la parte de los datos personales, claro está, nombre completo y correo electrónico:gpg (GnuPG) 2.2.40; Copyright (C) 2022 g10 Code GmbH
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 (por defecto)
(2) DSA y ElGamal
(3) DSA (sólo firmar)
(4) RSA (sólo firmar)
(14) Existing key from card
Su elección: 1
las claves RSA pueden tener entre 1024 y 4096 bits de longitud.
¿De qué tamaño quiere la clave? (3072) 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
<n> = la clave caduca en n días
<n>w = la clave caduca en n semanas
<n>m = la clave caduca en n meses
<n>y = la clave caduca en n años
¿Validez de la clave (0)? 0
La clave nunca caduca
¿Es correcto? (s/n) s
GnuPG debe construir un ID de usuario para identificar su clave.
Nombre y apellidos: Perico de los Palotes
Dirección de correo electrónico: flash@palotes.org
Comentario:
Ha seleccionado este ID de usuario:
"Perico de los Palotes <flash@palotes.org>" # (1)
¿Cambia (N)ombre, (C)omentario, (D)irección o (V)ale/(S)alir? V
Es necesario generar muchos bytes aleatorios. Es una buena idea realizar
alguna otra tarea (trabajar en otra ventana/consola, mover el ratón, usar
la red y los discos) durante la generación de números primos. Esto da al
generador de números aleatorios mayor oportunidad de recoger suficiente
entropía.
gpg: certificado de revocación guardado como '/home/perico/.gnupg/openpgp-revocs.d/9E1B339E5EB37200F48B9BCC498DABBF69B7C3DE.rev'
claves pública y secreta creadas y firmadas.
pub rsa4096 2025-03-17 [SC]
9E1B339E5EB37200F48B9BCC498DABBF69B7C3DE
uid Perico de los Palotes <flash@palotes.org>
sub rsa4096 2025-03-17 [E]
- En esta parte del procedimiento se solicitará la creación de la clave secreta de la firma, y se pedirá confirmación
En la parte del diálogo señalizada con el símbolo “+” desplegable, se solicitará la definición de la clave secreta de la firma, la cual, necesariamente debe cumplir los estándares mínimos de seguridad, que son: tener más de 20 caracteres; evitar palabras comunes o predecibles; incluir letras mayúsculas, minúsculas, números y símbolos especiales; guardarla en un lugar seguro (se recomienda escribirla en un papel o mejor aún recordarla de memoria; se desaconseja guardarla en un archivo digital, a no ser que se sepa lo que se está haciendo).
Como GPG está construido de acuerdo a los criterios de la criptografía asimétrica, el procedimiento anterior generará dos claves, una pública y otra privada, las cuales suelen almacenarse en dos archivos de extensión .asc que a continuación enseñaré como exportar desde la terminal. La segunda es accesible solo con la contraseña anteriormente creada. El asunto va así, si se quiere que otra persona verifique la autenticidad de nuestra firma hay que compartirle la clave pública (así como yo lo hice con la mía previamente en este texto), la cual debe ser importada a su sistema. Una vez se le envíe un archivo firmado, dicha persona podrá verificar que el documento es válido, luego de procesarlo a través de la firma que se le compartió previamente y que fue aprobada como confiable en su sistema.
Se pueden hacer cosas mucho más complejas con la firma personal, por ejemplo, yo puedo utilizar la clave pública que una persona me compartió para enviarle un archivo cifrado, es decir, codificado para que solo ella lo pueda abrir con su clave privada, y al mismo tiempo firmado por mí, para que verifique su autenticidad. En este caso, ambos tendríamos que haber intercambiado nuestras claves públicas previamente. Ese es un procedimiento utilizado bastante por periodistas, para intercambiarse información delicada con fuentes sensiblemente verificadas. Este ejemplo sirve también para demostrar que la clave privada y la contraseña no deben compartirse nunca con alguien y deben guardarse solo en un equipo de confianza. La clave privada sirve también para exportar la firma personal a otro equipo y poder utilizarla allí.
Para exportar la clave pública y privada, las cuales insisto, deben ser usadas y almacenadas responsablemente, se hace lo siguiente. Para exportar la clave privada necesariamente el sistema solicitará la contraseña creada anteriormente. Ambos archivos serán exportados a la carpeta desde donde se abrió la terminal, si no se cambió la ubicación predeterminada, esta será el fichero home del usuario.
$ gpg --export -a "Perico de los Palotes" > public.asc # (1)
$ gpg --export-secret-key -a "Perico de los Palotes" > private.asc
- En ambos casos, en vez del nombre del firmante también se puede usar el correo electrónico registrado
Por otro lado, para importar la clave pública de otro usuario, que como se dijo, sirve para comprobar la autenticidad de datos firmados, se aplica el siguiente comando:
Luego, hay que establecerle un grado de confianza a la clave, a la cual se le otorga el valor de “absoluta” cuando se tiene la certeza de que es auténtica, por ejemplo, cuando se transfirió dicho archivo por un individuo al que se conoce personalmente o se lo descargó de un sitio oficial comprobado.
Luego, se mostrarán los datos de la clave esperando que se especifique la acción que se desea hacer con ella, se debe escribirtrust, y luego se selecciona el grado de confianza de la clave:
1 = No lo sé o prefiero no decirlo
2 = NO tengo confianza
3 = Confío un poco
4 = Confío totalmente
5 = confío absolutamente
m = volver al menú principal
Se recomienda elegir la opción 5 para la clave propia (que recordemos, también contiene una clave privada) y para las que se tenga certeza que son auténticas (que solo son claves públicas). Finalmente, se escribe save y listo.
Esta sección de la entrada podría ser mucho más larga que la entrada misma, debido a que los procedimientos y usos de GPG son vastos y complejos, por ello me parece que lo que acabo de mostrar es lo mínimo necesario que se debe saber para lo que indicaré a continuación. Sin embargo, antes de continuar, encuentro oportuno señalar aquí que estas claves también sirven para manejar un correo electrónico firmado, como el que se demostró anteriormente y para ello se necesita importar las claves a un cliente de correo compatible con estos procedimientos, como es el caso de Mozilla Thunderbird. Incluso se puede hacer esto desde una cuenta de Gmail, siempre y cuando se la maneje desde Mozilla Thunderbird. He aquí, un tutorial en el que se muestra como firmar y cifrar correos electrónicos con GPG desde el programa mencionado.
Generación de hash SHA256 y firmado de un archivo
Como se indicó anteriormente, antes de hacerse la firma de un determinado fichero se debe realizar una comprobación de su integridad, obteniéndose finalmente dos archivos de verificación. Para este apartado se usará la herramienta sha256sum, la cual está disponible para Linux en el paquete coreutils, así como para macOS vía Homebrew. En Windows se pueden hacer los procedimientos que se indicarán a continuación, con herramientas nativas, a través de la PowerShell, tal como se muestra en este tutorial.
Lo primero que debemos determinar es si el archivo para el cual queremos generar la verificación es un archivo de texto o un archivo binario. La diferencia entre estos dos tipos de ficheros es simple, cuando uno abre el archivo de texto con un editor de texto, como Notepad en Windows por ejemplo, su contenido es visualizado inmediatamente, y lo más importante, puede ser comprendido por humanos, ya que está escrito, como su nombre lo indica, en texto. Por ejemplo, los archivos con extensión, .txt, .html, .mbox, etc. En cambio, si se quiere abrir el archivo con el mismo editor de texto mencionado, pero al ejecutarlo se tarda mucho, solo llega a mostrar caracteres ininteligibles o simplemente arroja un mensaje que indica no se puede abrir ese formato, es porque es un archivo construido para que solamente la máquina lo entienda, está escrito en binario y solo programas especializados pueden ejecutarlo. Por ejemplo, los archivos con extensiones .png, .jpg, .pdf, .docx, .exe, etc. Como puede verse, la mayoría de archivos que utilizamos diariamente, para guardar imágenes, u otros datos, incluidos textos, son archivos binarios.
Bien, entonces si el archivo es de texto, debe hacerse la verificación con un comando específico. Vamos a suponer que el archivo se llama Prueba.txt:
-b):
Esta operación lanzará el archivo llamado Prueba.sha256 el cual será un archivo de texto que contendrá un código único o hash, seguido del nombre del fichero del cual se verifica la integridad. Si se abre el archivo con un editor de texto tendrá la siguiente estructura:
Ahora, luego de obtener ese archivo, en este ejemplo Prueba.sha256, hay que firmarlo con la clave GPG anteriormente generada. Del mismo modo que con el comando sha256sum el comando gpg también tiene opciones diferenciadas en caso de que el archivo que se va a firmar fuera de texto o binario. Como acaba de apreciarse, el archivo Prueba.sha256 es un archivo de texto, porque cualquier editor de texto puede abrirlo y presentarlo de un modo legible, así que se usará la opción textual para firmarlo, de la siguiente manera:
Si el archivo fuera binario la orden fuera la siguiente, sin la opción -a:
El archivo Prueba.sig generado con el anterior comando, será un archivo de texto que de abrirse con un editor tendrá el siguiente formato:
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEMXgcOprVNZTZziCyZak5TWkCJEQFAmfZxwsACgkQZak5TWkC
JETqcA/+OYr9bkudMBaPYyDiDSQ5ye2NdotDtRg4HN5AADCLh/ODWsTDvX1n3Oiy
CMOcWzMcIb2RJkCaiQFPEPi4ST70vfcfemKXIjIzwpG0Cwr14ZA9fa8F7YwVeNUc
qj+rNxMfM3NKwNbDkqu4NgnMjrofG/AYoTx35KU8MMqNFRWXEuGBqsMqYplL86Rl
CzBEqQyVed4BtHSNW88mw6qGf8Yxx9kk9ayJb6yGjksvKCP99OmpLkaMc22dULQB
Q1tuHsOstATuEm9/edFRGZhxmaqMwt5zkiV2nh+mKUUUom4k3ZQrCLTqg0Mq34xW
uHdoVuoUaQrI+2YyjJOtpmHlmCLRmvBiDh3tQLqQItFBqB21FYTKW++QWDPpDTmc
5i7bfvktopmks/HRi0oYzmPdwSJzhFhJwqEtSo5EiBh3SM2p2XLajL6Ct6wkrq5U
CfDN+yCWftpaxWaQamdJM5KCyg5K3E998znLQco2px341z5jG49UBZq/g0EVk6zb
us5M94/jMESfaE8cmYdFTg3i1QA8y1miM/BogzLF4dkSfszMUh8MNOQr6BFvcYFA
/o9kpu6ulo4rA1tipGeus/goBJkRYcAnjMwUSkJKjEcqdjO07004+PIgfgJwnT1+
ZpjEH2+itW+miL82r1b+8cHxZv85k+r2TSXzjZWO1jzZjzjTiLM=
=IrNv
-----END PGP SIGNATURE-----
Entonces, por fin se tienen los dos archivos de verificación, Prueba.sha256 y Prueba.sig. El primero verifica la integridad de Prueba.txt, y el segundo vincula ese estado a la identidad de una persona a través de la firma GPG, en este caso, Perico de los Palotes. Para verificar ambos procesos se hace lo siguiente.
Para certificar la firma se hace lo siguiente:
La respuesta será:
gpg: Firmado el mar 18 mar 2025 15:18:35 -04
gpg: usando RSA clave
9E1B339E5EB37200F48B9BCC498DABBF69B7C3DE
gpg: Firma correcta de "Perico de los Palotes <flash@palotes.org>" [absoluta]
Palabras finales y curiosidades
Entonces, regresemos a nuestro ejemplo de la sección “Mensajería instantánea y almacenamiento en la nube” de esta entrada, y supongamos que el archivo a compartir por Whatsapp, a través de un enlace a Google Drive, será el archivo Prueba.txt del ejemplo anterior. Bien, primero, y de forma simultánea, se suben los tres archivos a la carpeta de Drive, es decir, Prueba.txt, Prueba.sha256 y Prueba.sig. El enlace para compartir el archivo solo se genera a partir de Prueba.txt, ya que no es necesario compartir inicialmente la carpeta donde se visualizarían los tres archivos. Tomando en cuenta la delicadeza hipotética de la situación, es importante no modificar esos archivos en momentos posteriores a cuando fueron compartidos con el destinatario, para que de este modo quede demostrado, no solo por la prueba de integridad y firma, sino por el historial de Google Drive, que el archivo es original, de acuerdo al testimonio del creador y que no fue alterado en un tiempo posterior al momento de la entrega del enlace a través de Whatsapp, como alega el falsificador en nuestro ejemplo ficticio. Solo en caso de controversia legal con el destinatario del archivo, se podría ya otorgar permisos públicos a la carpeta, donde se visualizarían los otros dos archivos de verificación y se tendría acceso público al historial que registró Google Drive del contenido de esa carpeta, para hacer las correspondientes verificaciones.
Sin embargo, existe una desventaja de esta solución frente a la de un correo electrónico con capacidad de cifrado y firmado, y es que no hay evidencia de que el destinatario haya recibido la prueba de integridad e identidad. El ideal máximo de esta prueba sería que el destinatario incluso confirme por escrito una verificación de ambos certificados. Esta recepción es importante como evidencia, ya que fulminaría completamente su ingenio a la hora de falsificar datos. Entonces, una segunda opción sería adjuntar estos archivos en el mensaje de Whatsapp junto al enlace de Google Drive, donde se hallan dispuestos los ficheros de la manera descrita en el anterior párrafo, para suplir esta carencia. Pero, esta acción nos obligaría a explicar la naturaleza de estos extraños archivos al destinatario, lo cual es sumamente incómodo porque tal situación implicaría admitir que se desconfía de su rectitud, aunque con seguridad, esto es preferible a adentrarse en futuras disputas legales. Lo que nos lleva a concluir que, probablemente, el primer ejemplo, de naturaleza más sigilosa, es el adecuado en casos de simple precaución porque, de todas formas, la triangulación entre el mensaje de Whatsapp con un vínculo único a Google Drive, un historial de modificaciones del archivo y dos métodos de verificación de integridad y firmado, constituye una evidencia muy sólida a favor del demandante.
Finalmente, y a modo de instar a la profundización en el conocimiento de estos fabulosos mecanismos de verificación, solo quiero mencionar que la suite ofimática LibreOffice, permite, desde su propia aplicación, firmar y verificar, con una clave GPG, documentos en sus formatos nativos (ODT, ODS, ODB, etc.) sin necesidad de generar o importar un archivo de firma externo, como en el ejemplo anteriormente citado; y también, permite firmar sus archivos PDF con una clave de tipo x.509, entre las que se encuentran las usadas para servidores web SSL/TLS y de correo S/MIME, que son de naturaleza centralizada, es decir, que son emitidas por una autoridad, y no descentralizada, como GPG.
Pero, probablemente el dato más espectacular respecto a estas tecnologías, es su exitoso empleo en la cadena de bloques de las criptomonedas. Al constituirse en activos de naturaleza digital y al mismo tiempo no regulados por una autoridad central, como un banco central, las criptomonedas necesitan un mecanismo de verificación de sus transacciones que sea inequívoco y también automático, y eso es precisamente lo que brindan estos procedimientos. Así, una transacción de criptomonedas implicará un almacenamiento público de sus datos, compartidos a través de una red de pares y verificados por pruebas de integridad y firmado. En el caso de Bitcoin, se usa como firma de criptografía asimétrica el mecanismo Elliptic Curve Digital Signature Algorithm (ECDSA), y como prueba de integridad de datos, el algoritmo SHA256, utilizado en los ejemplos de esta entrada.
Este tema de la cadena de bloques es demasiado apasionante, ya que a partir de esa tecnología se están empezando a hacer frecuentes los contratos de naturaleza digital o contratos inteligentes. El economista especializado en criptoactivos, Alvaro D. María, sostiene que en un futuro no muy lejano se podrían llegar a suscribir acuerdos digitales construidos a partir de una cadena de bloques, entre la ciudadanía de un país, su Estado, y una instancia de arbitraje internacional, a partir de los cuales, en caso de incumplimiento por parte del Estado, existan sanciones internacionales. Pero esta utopía, va más allá de los límites de este pequeño escrito...