1

GPG4WIN Para comprobar que los mensajes o archivos descargados de Internet son “validos” podemos utilizar dos métodos:

A. Código hash. B. Firma digital.

Código hash Constantemente estamos descargando archivos de Internet, sin embargo, los archivos que descargamos no siempre son los que en realidad queríamos descargar. Por múltiples razones (fallos en la descarga -corrupta o incompleta-, insertar código malicioso como malware, adware, spyware, troyanos, virus, etc.) el fichero final puede estar modificado sin que nosotros lo sepamos, por lo que una de las formas de garantizar la integridad de dichos archivos es mediante un código Hash.

Cuando hablamos de CheckSum o Suma de Verificación nos estamos refiriendo a una función hash computable mediante un algoritmo cuyo propósito principal es detectar cambios en una secuencia de datos (archivos) para proteger la integridad de estos, comprobando así que no haya diferencias entre los valores obtenidos al hacer una comprobación inicial y otra final luego de haber compartido dichos datos; es decir, es usado para verificar que un archivo o texto compartido a un usuario es idéntico bit a bit al publicado en su fuente original.

Un hash es una función algorítmica que nos permite generar a partir de un elemento de entrada (como un archivo, un texto…) un valor de salida: una cadena alfanumérica única (huella digital), de tamaño fijo e independiente de la dimensión del documento original. Gracias a estas funciones podremos tener la certeza de que la integridad de un archivo analizado no se ha visto modificada.

De tal forma, una vez descargado el archivo calculamos el valor hash del mismo, y lo comparamos con el original que estará mostrado en su web de descarga. Si ambos son iguales, se puede deducir que el archivo descargado no ha sido alterado, es idéntico al original y es fiable su ejecución…o eso esperamos.

¿Y qué pasaría si al intentar comprobar el hash no coincide?

Hay dos posibilidades: (1) El archivo que has descargado funcionará pero no como debería (esto dependerá de qué tan importante es aquella parte corrupta) o (2) El archivo simplemente no abrirá, no se ejecutará, o no se podrá grabar; es decir, es inservible. En ambos casos la accion general es volver a conseguir el archivo de su fuente original, es decir, volver a descargar.

2

Propiedades tienen que cumplir las funciones hash

1. Sea cual sea la longitud del texto o fichero base de entrada A, la longitud de su hash resultante B siempre va a ser la misma.

Por ejemplo, si la longitud de la salida B está definida en 128 bits (MD5), si aplicamos una función hash a un A de 5 bits nos dará un B de 128 bits, y si se la aplicamos a un A de 380 millones de bits, nos dará un B de 128 bits igualmente.

2. Para cada entrada A, la función generará una salida B única.

O lo que es lo mismo, es imposible que dos textos bases A y A' tengan un mismo hash B. Según estas dos primeras propiedades, nos damos cuenta enseguida de la utilidad de las funciones de hash. La más inmediata es usarla para generar un resumen de algo. De hecho, estas funciones se conocen también como funciones resumen. Un ejemplo real puede ser el del típico repositorio de documentos, así actúan los antivirus.

Además, como la salida B es única para cada A, se puede usar también para verificar la integridad de A. Podemos ver que muchos programas incluyen su hash junto con su descarga, de esta forma, podemos verificar que el programa no ha sido modificado ni le han introducido un virus o ha sido troyanizado. Si a los bytes de una aplicación A les calculo el hash B y lo adjunto, cuando alguien modifique la aplicación A, al calcular de nuevo su hash su valor habrá cambiado y será distinto de B. Podéis probar a calcular el hash de un documento, luego modificáis una simple coma del documento e incluso cambiar minúscula a mayúscula una letra y calculáis de nuevo el hash. Veréis como ha cambiado completamente.

3. Dado una entrada base, es fácil y rápido (para un ordenador) calcular su número resumen.

4. Es imposible reconstruir la entrada base a partir del número resumen.

Esto es lo que se conoce como One-Way hash functions. A partir del hash es imposible reconstruir la entrada base: A partir del numero hash es imposible reconstruir su entrada, quiere decir que no existe forma o es computacionalmente imposible, que mediante operaciones matemáticas inversas o no a las del algoritmo de hash, se llegue desde B a A. Si os dais cuenta, esto es muy distinto que usar fuerza bruta. No tiene nada que ver. Con fuerza bruta le aplicamos la función de hash a diferentes entradas hasta que obtenemos un hash similar al hash del texto que buscamos, con lo que por consecuencia tendremos una entrada similar a la buscada.

5. No puede presentar Colisiones.

3

Según la primera característica que hemos visto de las funciones hash, que nos dice que el tamaño del hash B resultante de A es siempre el mismo, deducimos que no puede cumplirse la segunda característica, que dice que el hash B tiene que ser único para cada A.

Es posible que existan huellas digitales iguales para objetos diferentes (colisión), porque una función hash tiene un número de bits definido (finito) y las entradas a resumir son infinitas. En el caso de MD5 es 128 bits (tenemos 2^128 hash) y de SHA-1 son 160bits (tenemos 2^160 hash).

Así que para hackear, en vez de buscar la contraseña se busca colisiones a ese hash: contraseñas alternativas que tenían el mismo hash que la contraseña verdadera (los ordenadores no guardan contraseñas, guardan los hashes de las contraseñas).

La fortaleza de una función hash requiere que estas colisiones sean las mínimas posibles y que encontrarlas sea lo más difícil posible. Por ello se crean algoritmos con más números de bits, para disminuir la probabilidad de colisión. Pero es solamente un parche. Estos algoritmos son todos monocultivo, y dándoles más bits solo incrementas el esfuerzo para encontrar colisiones.

¿Solución? Muy simple. Usando dobles hashes. La gente no le da la importancia que tiene al problema de las colisiones, y si se la dan, por ejemplo PHP, no lo solucionan como es debido. Si para firmar algo en vez de cifrar el MD5 o el SHA1 o el SHA256 del documento, se cifrara una concatenación por ejemplo de MD5+SHA1, habría que buscar una colisión doble para conseguir un documento alternativo, lo que actualmente es imposible.

Si tenéis que usar las firmas electrónicas para vuestros documentos, y se van a firmar por ejemplo usando MD5, añadidles un campo estilo fingerprint con el hash del documento en SHA1.

https://foro.elhacker.net/criptografia/funciones_de_hash-t100025.0.html

El Message-Digest Algorithm 5 o MD5

Message-Digest 5 (MD5) es un algoritmo criptográfico de 128 bits ampliamente difundido. MD5 no es seguro. Se conocen formas ingeniosas de revertirlo, y es factible crear dos archivos distintos con el mismo hash md5 (colisión).

La función MD5 nos devuelve un hash de 128 bits. Para que cada hash equivalga a un único texto base, tendría que existir solamente un texto por cada combinación del hash devuelto, o sea, tendría que haber solamente 2^128 textos distintos, lo cual no es cierto. Como textos distintos hay infinitos, podemos decir que hay infinitas posibilidades de que

4

dos textos tengan el mismo hash. Así que no deberías confiar en md5 para asegurarte de que un archivo no ha sido modificado de forma deliberada

Tenemos MD6: de 256 bit, se procesa mediante multitarea. Nuevo algoritmo, recomendado para la seguridad.

El Secure Hash Algorithm o SHA

El SHA o Secure Hash Algorithm es un sistema de funciones hash criptográficas. El primer miembro de la familia fue oficialmente llamado SHA, publicado en 1993. Sin embargo, hoy en día no oficialmente se le llama SHA-0 para evitar confusiones con sus sucesores. Dos años más tarde el primer sucesor del SHA fue publicado con el nombre de SHA-1, que actualmente es uno de los más usados al distribuir software. También existen cuatro variantes más que se han publicado desde entonces con algunas otras diferencias: SHA-224, SHA-256, SHA-384, y SHA-512 (llamándose SHA-2 a todos ellos).

SHA-1 Es parecido al famoso MD5, pero tiene un bloque de 160bits en lugar de los 128bits del MD5. La función de compresión es más compleja que la función de MD5, por tanto, SHA-1 es más lento que MD5 porque el número de pasos son de 80 (64 en MD5) y porque tiene mayor longitud que MD5 (160bits contra 128bits). SHA-1 es más robusto y seguro que MD5, pero ya se han encontrado colisiones, por tanto, actualmente esta función hash no es segura utilizarla, nunca se debe usar.

SHA-2 Las principales diferencias con SHA-1 radica en en su diseño y que los rangos de salida han sido incrementados. Dentro de SHA-2 encontramos varios tipos, el SHA-224, SHA-256, SHA-384 y SHA-512. El más seguro, es el que mayor salida de bits tiene, el SHA-512, que tiene 80 rondas (pasos), como el SHA-1 pero se diferencia de éste en:

Tamaño de salida 512 por los 160 de SHA-1. Tamaño del bloque, tamaño de la palabra y tamaño interno que es el doble que

SHA-1.

Como ocurre con todos los cifrados y hash, cuanto más seguro, más lento su procesamiento y uso, debemos encontrar un equilibrio entre seguridad y velocidad.

Tenemos SHA-3: de 256 bits (SHA3-256) y 512 bits (SHA3-512), existen otros. Nuevo algoritmo, recomendado para la seguridad.

El Cyclic Redundancy Check 32 o CRC32

Se trata de un código de detección de errores usado frecuentemente en redes digitales y en dispositivos de almacenamiento cuyo propósito principal es comprobar o detectar

5

cambios accidentales en los datos o alteración de los mismos en su transmision. Como se ha mencionado, es útil para detección de errores, pero en condiciones de seguridad no podemos confiar en que el CRC puede verificar plenamente que los datos son los correctos en caso de que se hayan producido cambios deliberados y no aleatorios.

A menudo se piensa que si cuando llega un mensaje, si éste y su CRC coinciden, quiere decir que el mensaje no ha podido ser alterado durante su transmisión. Esta suposición es falsa porque CRC es un mal método de cifrado de datos. De hecho, el CRC no se trata realmente de un método de cifrado, lo que realmente hace es utilizarse para el control de integridad de datos, pero en algunos casos se supone que se utilizarán para el cifrado.

El software que realiza los cálculos y las comprobaciones para estos, se denomina con el "nombre del algoritmo" terminado con prefijo "sum"; por ejemplo para "MD5" se diría “md5sum” o para "SHA-1" sería "sha1sum" (para "SHA" también se puede aludir al tamaño, como "sha256sum" o "sha512sum".

¿Siempre van a existir colisiones para cualquier “función hash”?

Claro que sí. Las colisiones es uno de los problemas de los códigos Hash, aunque siempre se intenta que las “funciones hash” creen códigos hash cuya probabilidad de colisión sean lo más mínima posible. A mayor longitud de hash menor probabilidad de colisión.

¿Por qué son tan importantes las colisiones?

Imagina que estás haciendo una transferencia de dinero a un amigo a través de Internet, pones la cuenta del amigo y pulsas en enviar dinero. Un ataque “Man in the Middle” de un tercero podría interceptar y modificar la orden de enviar dinero al banco por el camino, cambiando el número de cuenta del destino (a la cuenta del atacante evidentemente). Llega la orden al banco y comprueba que en número de destino no coincide con el Hash que generó el que lo envía, por lo que el banco protegería eficazmente la transferencia al rechazar el envío de dinero a alguien no solicitado.

Ahora lo mismo, pero quien realiza el ataque “Man in the Middle” pone un número de cuenta diferente, aunque esta vez coincide con el Hash generado por el número de cuenta original; llega la orden al banco y como los códigos Hash coinciden, el banco piensa que es una transferencia legítima, por lo que da la orden y el dinero va a la cuenta modificada. Esto es muy grave, y se consigue muy rápidamente teniendo tablas de traducción (de un código Hash con cuáles son sus mensajes que lo validan); así en cuestión de segundos se puede desvirtuar una comunicación.

6

Para que sirva de tranquilidad, es bastante complicado conseguir realizar este tipo de ataques contra un banco (u otras páginas webs debidamente protegidas); existen otros sistemas de seguridad que hay que superar previamente para llegar a realizar el engaño de códigos Hash, como el cifrado de la conexión, los tiempos (timeouts), el secreto de las funciones utilizadas, etc.

¿Los códigos Hash sólo sirven para enviar ficheros y mensajes entre ordenadores?

También sirven en local, sin tener que salir de tu propio ordenador. Como has tenido la oportunidad de entender, los códigos Hash sirven para comprobar que archivos no se hayan visto modificados (como trabajan los antivirus, que comprueban que nadie modifique los archivos con códigos Hash, así como la “base de datos de firmas” que contienen los códigos Hash de los virus).

http://www.informaticodelaverno.com/2017/07/?m=0

7

http://www.abelhadigital.com/multihasher

Descargamos el archivo zip (portable) y en la web tenemos los hash.

Ejecuto el programa y selecciono los hash deseados. Y pulso calcular.

Ahora en herramientas voy a comparar el hash de la web con el calculado del archivo descargado.

8

https://raylin.wordpress.com/downloads/md5-sha-1-checksum-utility/

9

http://implbits.com/products/hashtab/

A diferencia con la mayoría de herramientas de este tipo, a HashTab se puede acceder desde el menú contextual de Windows una vez que el usuario hace clic en la opción Propiedades. Para verificar la integridad de un archivo basta con hacer clic con el botón derecho del ratón sobre él, seleccionar la opción Propiedades y a continuación dirigirnos a la pestaña Hash de archivo.

10

https://quickhash-gui.org/

Hay webs que proporcionan varias hash. Elegimos uno y ya está. A mayor longitud de hash mayor seguridad.

Recordad que siempre hay que desconfiar de todo aquello que nos bajamos desde internet. ¡Es mejor prevenir que curar -o esperar a que el antivirus de turno sea capaz de neutralizar la amenaza- así que empezad ya a practicar con esos hashes!

https://blog-conocimientoadictivo.blogspot.com/2015/11/Que-es-el-CheckSum-Hash-MD5-SHA-1.html?m=1

http://msmanuelsanchez.blogspot.com.es/2015/10/tipos-de-cifrados-sha1-md5-rsa.html?m=1

https://www.redeszone.net/2010/11/09/criptografia-algoritmos-de-autenticacion-hash/amp/

https://jarroba.com/codigo-hash/

https://protegermipc.net/2016/11/22/como-calcular-el-hash-de-un-archivo-o-ejecutable/

11

Firma digital

Para entender esto hay que leer una buena introducción y entenderlo todo.

Hace unos años, a la hora de instalar software fuera de los repositorios oficiales la precaución era bien sencilla: acudir a la fuente original, huir como de la peste de la mayoría de portales especializados en descargas y no instalar software dudoso de cualquier fuente (amigos en concreto, hack de juegos y programas, KeyGen…).

La mayoría de usuarios no las utilizan, pero la comprobación de las sumas de verificación mediante diversos algoritmos es una realidad desde hace muchos años, pero si algo aprendimos de los ataques a Linux Mint y Transmissión (en su versión OS X), es que incluso eso puede no ser suficiente. Nada impide a un atacante una vez infectados los archivos de descarga en un servidor, manipular también las sumas de verificación para que coincidan.

Pero no sólo son descargas. Teniendo en cuenta que prácticamente todo cuanto ocurre en la red se resumen en el envío y recepción de paquetes de datos que pasan por varios servidores por todo el mundo, es normal tener cierto recelo y desconfiar de la seguridad o inviolabilidad de nuestras comunicaciones, no se trata de que tengas algo que esconder, si no de que tienes comunicaciones que no tienen por qué ser escuchadas o leídas por otras personas. La principal y más efectiva manera de proteger la seguridad de tus comunicaciones en Internet es usar cifrado.

Para proporcionar un grado de seguridad mayor se inventaron las firmas electrónicas en la verificación de software y mensajes, que nos permite comprobar que los archivos y mensajes que estamos descargando son auténticos, han sido creados por el desarrollador de la aplicación o enviados por un remitente verdadero (fiable).

El correo electrónico es actualmente menos seguro que el correo ordinario pues es habitual que un mensaje enviado a través de Internet pase por varias estafetas y un postmaster o cualquier usuario con privilegios puede acceder a estos mensajes, leerlos y/o alterarlos. Además de esto no es difícil falsificar las direcciones del emisor de un mensaje. Por eso en caso de que se desee obtener seguridad en el correo electrónico a través de Internet es necesario usar algún medio que nos proporcione garantías suficientes de confidencialidad, autentificación e integridad. Y lo mismo ocurre con las redes sociales.

El motivo de uso de cifrado es simplemente obtener privacidad en nuestras comunicaciones vía e-mail, pues a nadie le gusta que lean su correo, a pesar de que los temas tratados no sean confidenciales o ilegales.

12

¿Qué es una firma digital o firma electrónica?

Hoy día la firma digital de documentos está legalmente equiparada a la firma clásica. Una firma digital es un conjunto de datos asociados a un fichero, documento, mensaje, etc. que permite asegurar la identidad del firmante y la integridad del fichero firmado. Hablamos del equivalente "mejorado" a la firma en papel, pero para documentos electrónicos, es decir, ficheros de ordenador, pero conservando toda su validez legal, con lo que este "invento" nos permite desterrar el papel, las firmas a mano, los sobres con sellos, y el personal necesario para manejar todo esto, por ficheros enviados por correo electrónico.

El firmante generará mediante una función matemática un 'resumen' o huella digital (fingerprint) del fichero, que tendrá un tamaño determinado dependiendo del algoritmo utilizado. Este resumen o huella digital la cifrará con su clave privada y el resultado es lo que se denomina firma digital, que enviará adjunta al fichero original. Cualquier receptor del fichero podrá comprobar que el fichero no fue modificado desde su creación porque podrá generar el mismo resumen o misma huella digital aplicando la misma función al fichero.

Además, podrá comprobar su autoría descifrando la firma digital con la clave pública del firmante, lo que dará como resultado de nuevo el resumen o huella digital del fichero que debe ser idéntica a la recibida.

El cifrado de mensajes y archivos requiere que un mínimo de dos personas tenga llaves públicas para poder enviarse un correo o archivo cifrado y no fallar en el intento. Pero como muchas de las tecnologías que se veían complicadas, poco a poco hay más aplicaciones y servicios que ponen la seguridad por delante, ya sea haciendo extremadamente fácil el cifrar un email, o integrando en una aplicación cifrado por defecto.

La firma digital no implica que el fichero esté cifrado, esto es, un fichero firmado será legible en función de que esté o no cifrado.

Firma: nos permite que nuestro destinatario compruebe que el mensaje no fue modificado en el camino y que lo que lee es exactamente lo que redactamos.

Cifrado: nos permite ocultar el contenido del mensaje para que sólo el destinatario final pueda leerlo (crea un contenido ilegible).

No son excluyentes, se pueden usar para crear un email o fichero firmado y/o cifrado.

13

¿Qué utilidad práctica tiene la firma electrónica?

Lo que se le pide básicamente a una firma digital sería lo mismo que se le pide a una firma manual. La firma electrónica aporta 5 características en la comunicación por Internet:

No suplantación: La información del documento y su firma electrónica se corresponden indubitablemente con la persona que ha firmado. Poder asegurar que el documento realmente fue firmado por quien dice haberlo hecho (la firma la estampo personalmente la persona en cuestión).

Autenticidad: Poder comprobar que la firma es auténtica, en papel sería equivalente a poder diferenciar un garabato sin valor de una firma.

Integridad: La información contenida en texto electrónico, no ha sido modificada luego de su firma. Que nos asegure que el documento no fue manipulado una vez firmado (esto es más de lo que nos asegura una firma manual).

No repudio: La persona que ha firmado electrónicamente no puede decir que no lo ha hecho.

Confidencialidad: La información contenida ha sido cifrada y por voluntad del emisor, solo permite que el receptor pueda descifrarla.

Las aplicaciones prácticas de la firma electrónica son muchas y variadas. En general están orientadas a realizar operaciones por Internet que en la vida cotidiana requieren de una firma manuscrita para validarlas, es decir, legalizar sus operaciones:

Realización de la Declaración de la Renta a través de Internet. Solicitudes en los registros electrónicos administrativos Petición de la vida laboral. Recepción de notificaciones electrónicas. Firma/verificación de correos electrónicos y archivos. Firma de facturas electrónicas.

Todo esto es posible gracias a certificados, encriptaciones, firmas y demás mecanismos que no necesitamos comprender exactamente para utilizar, pero si estar familiarizados.

Criptografía simétrica

La criptografía simétrica solo utiliza una clave para cifrar y descifrar el mensaje, que tiene que conocer el emisor y el receptor previamente y este es el punto débil del sistema, la comunicación de las claves entre ambos sujetos, ya que resulta más fácil interceptar una clave que se ha transmitido sin seguridad (diciéndola en alto, mandándola por correo electrónico u ordinario o haciendo una llamada telefónica).

14

Criptografía asimétrica

La criptografía asimétrica se basa en el uso de dos claves: la pública (que se podrá difundir sin ningún problema a todas las personas que necesiten mandarte algo cifrado) y la privada (que no debe de ser revelada nunca).

Aquí la idea es que lo que se cifra con una clave sólo se descifra con la otra. Pero ojo, cada persona tiene su par de claves, de manera que si quieres hacer llegar un mensaje a Pedro tendrás que cifrar con su clave pública mientras que si quieren hacerte llegar un mensaje a ti se cifrará con tu clave pública. Y sólo la clave privada de su par las descifrará. Y si cifras con la clave privada, la clave pública será la que descifre.

Criptografía híbrida

Para empezar, la criptografía simétrica es más insegura ya que el hecho de pasar la clave es una gran vulnerabilidad, pero se puede cifrar y descifrar en menor tiempo del que tarda la criptografía asimétrica, que es el principal inconveniente y es la razón por la que existe la criptografía híbrida.

Este sistema es la unión de las ventajas de los dos anteriores, debemos de partir que el problema de ambos sistemas criptográficos es que el simétrico es inseguro y el asimétrico es lento. El proceso para usar un sistema criptográfico híbrido es el siguiente (para enviar un archivo):

Generar una clave pública y otra privada (en el receptor). Cifrar un archivo de forma síncrona. El receptor nos envía su clave pública. Ciframos la clave que hemos usado para encriptar el archivo con la clave pública del

receptor. Enviamos el archivo cifrado (síncronamente) y la clave del archivo cifrada

(asíncronamente y solo puede ver el receptor).

¿Qué es la encriptación o cifrado? La encriptación o cifrado es un mecanismo de seguridad que permite modificar un mensaje de modo que su contenido sea ilegible. De modo inverso, la desencriptación o descifrado permitirá hacer legible un mensaje que estaba cifrado, y ambos mediante una clave de seguridad o contraseña (que puede ser una palabra o una oración).

¿Qué diferencia hay entre cifrar y proteger por contraseña? No son sinónimos. Aunque para ambas haya que escribir una contraseña para poder abrir el documento, fichero o carpeta. Protegido por contraseña simplemente añade una contraseña para poder abrir el contenido, pero cifrar, altera realmente el contenido que permanece oculto.

15

Esquema PKI El acrónimo PKI deriva de "Public Key Infrastructure" (Infraestructura de Clave Pública) y es la forma común de referirse a un sistema complejo necesario para la gestión de certificados digitales y aplicaciones de la Firma Digital. Contiene 5 componentes:

1. Entidades Finales: Quien solicita la llave o se pretende identificar. 2. Autoridad de Certificación: La que emite los certificados y es la parte de la credibilidad de la llave pública. Firma los certificados con su llave privada, dando fe de que es en la verificación de las llaves asignadas son a quien corresponde. 3. Autoridad de Registro: Realiza el proceso de registro de las entidades finales, validad los atributos, genera los secretos compartidos que permiten el proceso de inicialización y certificación. 4. Repositorios: Método que permite guardar la información de PKI "Certificados y CRL", viendo también el status de revocación de los certificados. 5. Emisores CRLs "Certificate Revocation List Issuer": Son listas de certificados que han dejado de ser válidos.

El esquema PKI formalizado en el certificado X.509 sólo permite que cada certificado esté firmado por una única entidad: una autoridad de certificación (CA, en sus siglas en inglés). El certificado de la CA puede estar él mismo firmado por una CA diferente, subiendo en una jerarquía de certificados hasta un llegar a uno firmado por sí mismo, también llamado certificado raíz (en inglés, root certificate).

Los certificados raíz deben estar disponibles para aquellos que usen una CA de menor nivel y por tanto son ampliamente distribuidos. Por ejemplo, vienen incorporados en aplicaciones como navegadores, clientes de email, y en sistemas operativos como Mac OS X. De esta manera, aquellas páginas web o e-mails protegidos mediante el protocolo SSL/TLS pueden ser autenticados sin necesidad de que el usuario instale manualmente un certificado raíz.

Estas aplicaciones comúnmente incluyen más de un centenar de certificados raíz de una docena de PKIs diferentes, otorgando así por defecto confianza a toda la jerarquía de certificados que asciende de nuevo hasta ellos.

16

Esquema PGP

Pretty Good Privacy (PGP) es un programa creado por Phil Zimmermann que nos ayuda a proteger nuestra privacidad, para que todas las comunicaciones estén a buen seguro; al mismo tiempo, garantiza la autenticidad de los mensajes electrónicos que enviamos.

En un artículo escrito por Philip Zimmermann en la primera edición de la guía del usuario en 1994 cuenta las motivaciones que lo llevaron a crear PGP. En este artículo defiende el derecho constitucional de la intimidad y los problemas que ponía el gobierno de Estados Unidos en aquella época para conseguirla. Según Philip el simple hecho de querer tener privacidad en nuestro correo electrónico supone ser sospechosos de estar haciendo algo ilegal. Lo que él propone es que el uso de algún sistema de cifrado de mensajes sea algo extendido entre los usuarios de correo electrónico para que se convierta en algo tan normal como mandar las cartas en sobres y no en postales.

Podemos cifrar cualquier tipo de información personal (emails, archivos o el disco duro entero): siendo difícil para cualquier otra persona, que no seamos nosotros, intentar sacar información o interceptar el contenido de estos archivos. Hay también la opción de “firma digital” para enviar mensajes que serán verificados por el destinatario; así estaremos tranquilos porque el mensaje no ha sido modificado durante el proceso de envío y solo nosotros hemos podido enviarlo.

Imaginemos, por ejemplo, que todo el mundo firma sus mensajes electrónicos (es fácil imaginarlo): los ataques de phishing serían mucho más difíciles de llevar a cabo y la mayoría de los emails falsos o engañosos que recibimos cada día simplemente ya no existirían, porque para los cibercriminales ya no merecería la pena poner tanto esfuerzo en falsificar mensajes con firma.

Zimmermann diseñó PGP hace más de 20 años y desde entonces se han realizado muchas mejoras. Al principio, el gobierno estadounidense investigó a Zimmermann “por exportación de municiones sin licencia”, ya que los productos de encriptación más fuertes de 40 bits (PGP era un producto de 128 bit) se consideraban como municiones. Aunque se cerró el caso sin cargos para Zimmermann, se demostró cómo de potente puede ser una herramienta de encriptación y por qué algunos importantes accionistas de empresas tienen tanto interés en este asunto.

Al final, la versión completa de PGP con un sistema de encriptación fuerte llegó al gran público. La organización Free Software Foundation desarrolló su propio programa gratuito PGP llamado GNU Privacy Guard (abreviado como GnuPG o GPG), que proporciona una librería para encriptación, descifrado y funcionalidades de firma electrónica. Además, PGP se acompaña también con interfaces muy cómodas para el usuario (llamadas GUI), disponibles para la mayoría de los sistemas operativos disponibles.

17

Como el código fuente de PGP está disponible para la descarga, cualquier persona puede revisarlo, buscar errores y backdoor o solo echarle un vistazo. Aunque no todo el mundo esté familiarizado con este tema, hay una comunidad de expertos en el sector (no relacionados con ningún gobierno o empresa) que revisa continuamente el código fuente para que PGP no sufra alteraciones externas.

Es un aspecto muy importante a considerar, sobre todo después de las recientes revelaciones según las cuales algunas agencias de seguridad han intentado eludir la encriptación de los protocolos modernos de comunicación.

Gobiernos y agencias para la seguridad nacional han fundado sus programas sobre la privacidad, y también los criminales. ¿Qué pueden hacer los usuarios comunes? Antes, los que tenían dinero podían permitirse sistemas de encriptación muy avanzados, casi de nivel militar. Con la llegada de PGP, las cosas cambiaron.

Al principio el usuario común no sabía cómo mantener seguras sus comunicaciones e su información personal, ni tampoco empresas y otras entidades querían que se encontrara un método. Por suerte, después de 20 años, PGP ha colmado este vacío, demostrando ser un sistema capaz de garantizar privacidad y libertad.

En la actualidad, la tecnología es propiedad de Symantec, pero está disponible a través de una gran cantidad de programas distintos para diferentes plataformas. Además, existe una versión de código abierto cuyo principal representante es la aplicación GnuPG.

PGP es un criptosistema híbrido que combina técnicas de criptografía simétrica y criptografía asimétrica. Esta combinación permite aprovechar lo mejor de cada uno: el cifrado simétrico es más rápido que el asimétrico o de clave pública, mientras que este, a su vez, proporciona una solución al problema de la distribución de claves en forma segura y garantiza el no repudio de los datos y la no suplantación.

18

PGP y GPG se ocupan principalmente de los pequeños detalles de creación y uso de claves públicas y privadas. Puedes crear un par de claves pública / privada, proteger la clave privada con una contraseña y utilizarla junto a la clave pública para firmar y cifrar. También permitirá descargar las claves públicas de otras personas y subir tus claves públicas a "servidores de claves públicas", que son los repositorios donde otras personas puedan encontrar tu clave.

GPG no usa algoritmos de software que están restringidos por patentes, entre estos se encuentra el algoritmo de cifrado IDEA que está presente en PGP casi desde sus inicios. En su lugar usa una serie de algoritmos no patentados como ElGamal, CAST5, Triple DES (3DES), AES y Blowfish. También es posible usar IDEA en GPG descargando un plugin extra, sin embargo, este puede requerir una licencia para usuarios de algunos países en donde esté patentada IDEA.

GNUPG es una implementación del estándar OpenPGP en modo texto (consola). Diferentes implementaciones gráficas están disponibles, pero sólo algunas tienen implementadas todas sus características (por ejemplo: borrado de ID, usuarios o firmas). Debido a que todas las instrucciones deben ser pasadas a la línea de comandos, rápidamente llegan a dificultar el uso correcto de aspectos no triviales del programa.

Aclararemos también que PGP, al ser un sistema desarrollado en los EEUU, está sujeto a ciertas leyes sobre la exportación de programas que incluyen código criptográfico; por esta razón existe una versión internacional para casi todas las versiones numéricas, y estas vienen denotadas en su terminación por la letra “ i “(pgp - pgpi).

El esquema GPG formalizado en por lo que se denomina “anillo de confianza”, permite:

1. Certificación manual que cada persona pueda certificar un certificado que crea que es verdadero. De tal manera, un certificado cualquiera puede estar certificado (avalado) por muchas personas (varios certificadores).

2. Certificación automática Un certificado X (que no hemos certificado nosotros manualmente) se nos puede agregar automáticamente como válido si en el grupo de certificados que tenemos nosotros marcado como válidos en nuestro programa (de confianza), hay varios que tengan como válidos ese mismo certificado X.

GPG es un sistema de encriptación que se asemeja mucho en el funcionamiento a PKI, ya que también es un sistema de clave asimétrica, aunque no son compatibles entre ellos. PKI es un estándar en el que se definen los certificados x509 (ISO x.509), y es una de las diferencias entre el GPG y el PKI.

19

¿Qué es un certificado electrónico?

El Certificado Electrónico es la base de la firma electrónica. Para firmar un documento es necesario disponer de un certificado digital. El certificado electrónico contiene unas claves criptográficas que son los elementos necesarios para firmar. Los certificados electrónicos tienen el objetivo de identificar inequívocamente a su poseedor (identifica una clave pública con su propietario).

En el esquema PKI son emitidos por Proveedores de Servicios de Certificación y en el esquema GPG lo crea uno mismo.

Cada certificado está identificado por un número de serie único y tiene un periodo de validez (marca de tiempo = caducidad) que está incluido en el propio certificado.

Es un documento electrónico expedido por una Autoridad de Certificación e identifica a una persona (física o jurídica) con un par de claves únicas.

Tiene como misión validar y certificar que una firma electrónica se corresponde con una persona o entidad concreta.

Contiene la información necesaria para firmar electrónicamente e identificar a su propietario con sus datos: nombre, NIF, algoritmo y claves de firma, fecha de expiración y organismo que lo expide.

La Autoridad de Certificación dá fe de que la firma electrónica se corresponde con un usuario concreto. Esa es la razón por la que los certificados están firmados, a su vez, por la Autoridad de Certificación.

Contenido del Certificado. Es necesario poder vincular la clave pública de un usuario con su identidad y para esto surge el concepto de "Certificado Digital", que contiene la siguiente información:

Identidad del usuario (Nombre, NIF, etc...) Clave Pública del usuario. Periodo de Validez del Certificado Identidad de la Autoridad Certificadora (entidad que emite el certificado). Firma digital del certificado (los datos anteriores más otras posibles extensiones

personalizables, p.e. la dirección de correo electrónico), generada por la Autoridad Certificadora.

20

Tipos de Certificados PKI Certificados Clase 1: Son emitidos única/ a individuos, donde no se verifica la identidad, por lo tanto no permite autenticarla. Certificados Clase 2: Son emitidos únicamente a individuos que confirman la información proporcionada por el suscriptor. Son datos fiables. Certificados Clase 2 (no reconocidos):Usados para transacciones de bajo riesgo. Certificados clase 2 (reconocidos): Pueden usarse como soporte de firmas electrónicas legal/ reconocidas. Certificados Clase 3: Son los que requieren evidencias probatorias de la identidad del sujeto o de una URL PKI es un sistema de encriptación que se asemeja mucho en el funcionamiento al PGP, ya que también un sistema de clave asimétrica, aunque no son compatibles entre ellos. PKI es un stándard (ISO), en el que se definen los certificados x509, y es una de las diferencias entre el PGP y el PKI. Estos certificados no son más que los datos personales del propietario (DN o “Distinguised Name”), junto con su clave pública, todo ello firmado por una Autoridad Certificadora

Con este sistema, la clave pública de la que vayamos a hacer uso, es, con total seguridad, la clave de la persona que pretendíamos, ya que los datos que la acompañan así lo demuestran, y además y muy importante, está certificado por la Autoridad Certificadora en cuestión.

Debido a que tenemos gran seguridad de que la clave es auténtica, el PKI se suele usar en transacciones seguras a través de Internet (en conjunto con el SSL, que se encargará de cifrar los datos, ya que el PKI solo se usa a modo de identificación), o cualquier otro tipo de operación que requiera de una identificación segura.

El modus operandi con PKI es el siguiente: debes crear un PKCS 10 o “Certificate Request” autofirmado, que contendrá todos tus datos personales, y enviárselo a la autoridad certificadora que creas conveniente. Esta autoridad comprobará de alguna forma que los datos que le has proporcionado son verdaderos, bien citándose contigo, bien reclamando algún documento oficial que te identifique. Una vez que la autoridad se haya cerciorado de que los datos son correctos, creará un certificado x509 a partir del Certificate Request que tú le enviaste y lo firmará.

Para una mayor comodidad, podrás crear un objeto PKCS 12, que no es más que un conjunto de certificados y sus claves privadas correspondientes, todo ello protegido con una clave. Este tipo de ficheros es el que más se suele usar en el PKI, y es el sistema usado por Netscape y Explorer.

Cada vez que una página web requiera identificación a través de un certificado válido, el explorador te pedirá el password de la base de datos de certificados que posee, y irá

21

comprobando uno a uno hasta que encuentre alguno que le permita acceder. Todos los certificados que importes a la base de datos del navegador, serán comprobados a través de la autoridad certificadora correspondiente, y serás avisado si algún certificado no es correcto, o la autoridad certificadora que lo ha firmado no es de tu confianza.

Este sistema también se puede usar para el cifrado y firmado de correo, siendo su uso muy parecido al PGP, pero con la fiabilidad que le confiere las autoridades certificadoras.

Si estás interesado en usar PKI, puedes usar OpenSSL, que es una implementación libre de PKI y SSL, teniendo siempre en cuenta las leyes vigentes sobre el uso de la criptografía de tu país.

Obtención del Certificado en PKI

Obtener el Certificado Digital depende de si el certificado está contenido en una tarjeta, tarjetas con Chips como el DNIe, o de si el certificado se guarda en un fichero software.

En ambos procesos hay un paso que es la identificación del responsable o usuario del certificado, lo cual requiere que éste se persone o no en las oficinas de una Autoridad de Registro. Estas oficinas corroboran la identidad.

En el caso de los certificados software (usados en PGP), el propio navegador del usuario crea las claves. Pero, en el Certificado de tarjeta, quien crea e introduce las claves es el Proveedor de Certificación. PGP guarda dichas claves en dos archivos separados llamados llaveros; uno para las claves públicas y otro para las claves privadas.

Obtención de Certificado en tarjeta (DNIe) Los certificados contenidos en tarjetas deben ser entregados directamente al usuario. En el caso concreto del DNIe, hay que personarse en las oficinas de la Dirección General de Policía, que es la Autoridad Certificadora.

Solicitud de certificado software La solicitud y descarga del Certificado se realizan desde el navegador web.

Obtención del Certificado en GPG

En este caso sólo debemos descargar el programa y generar el par de claves. No se nos pide nada de datos personales. Pero ojo, esto es como el email: al final lo usas para fines personales “formales”, así que dale la importancia que se merece.

22

Plataformas de Validación (Autoridad de certificación) PKI Las plataformas de validación son sistemas online que permiten validar los certificados electrónicos mediante X509, suministra información sobre la vigencia de los certificados electrónicos que han sido registrados por una Autoridad de Registro y certificados por la Autoridad de Certificación.

Una Autoridad de certificación es una entidad de confianza, responsable de emitir y revocar los certificados digitales o electrónicos, utilizados en la firma electrónica. Jurídicamente es un caso particular de Prestador de Servicios de Certificación.

Como puedes deducir, estos organismos serán diferentes si el certificado es para tarjeta (normalmente nacional y hay que personarse) o para software (normalmente internacional de modo no presencial).

En general, la Autoridad de Certificación es también Autoridad de Validación, aunque ambas figuras pueden estar representadas por entidades diferentes.

Los usos de estas empresas suponen pagar por sus servicios. Necesitas autentificación (proceso de detectar y comprobar la identidad de una entidad de seguridad examinando las credenciales del usuario y validando esas credenciales contra alguna autoridad). Te proporcionan una clave y un usuario para validación.

PKI hace uso de estas plataformas. Gpg tiene posibilidad de hacer uso de los servicios de directorio X509 para validar con una autoridad de certificación, pero su idea de nacimiento es licencia GNU, por lo que nace la idea de “anillo de confianza”.

Plataformas de Validación (Anillo de confianza) GPG GPG nació bajo licencia GPL, por lo que elimina el gasto económico y nace la idea de “anillo de confianza”. El concepto de anillo de confianza fue propuesto por primera vez en 1992 por el creador de PGP Phil Zimmermann en el manual para la versión 2.0 de PGP:

Con el paso del tiempo, usted acumulará claves de otras personas que podría querer designar como introductores de confianza. Todos los demás elegirán sus propios introductores de confianza. Y todos gradualmente acumularán y distribuirán junto con su clave una colección de firmas certificadas por otras personas, en la expectativa de que quien quiera que la reciba confiará por lo menos en una o dos de las firmas. Esto llevará a la aparición (espontánea) de un anillo de confianza descentralizado y resistente a los fallos para todas las claves públicas.

23

Los participantes en un anillo de confianza deben firmar entre sí sus claves públicas, certificando que avalan la correspondencia entre el nombre atribuido a la clave y la clave en sí misma. Esto sucede a menudo en fiestas conocidas como fiestas de firmado de claves (key signing parties, en inglés).

De este modo se implementa un modelo de confianza descentralizado que contrasta con el modelo centralizado basado en PKI (que sólo considera certificados firmados por autoridades certificadoras). Existen multitud de anillos de confianza, y un usuario puede pertenecer a cuantos de ellos desee.

Las implementaciones compatibles con OpenPGP suelen incluir un sistema de recuento de votos que puede servir para determinar cuáles asociaciones entre dueño y clave pública serán de confianza para un usuario mientras esté usando PGP.

Por ejemplo, si tres avalistas parcialmente confiados por el usuario han garantizado un certificado (y por tanto la correspondencia que incluye entre clave pública y dueño), o si un avalista plenamente de confianza ha hecho lo mismo, entonces la correspondencia se tomará como cierta automaticamente. Los parámetros son ajustables por el usuario; por ejemplo, se puede requerir que no haya votos de avalistas solo parcialmente de confianza, o como mínimo 6 parciales sustituirán a un aval directo, o circunvalar el sistema de votos por completo.

El programa también permite la posibilidad de dar confianza a una clave sólo para uso particular, y no necesariamente subirla a un servidor para compartirla.

El mecanismo de anillo de confianza es flexible, al contrario que la mayoría de arquitecturas de PKI, y deja las decisiones acerca de la confianza en las manos de los usuarios individuales. No es un sistema perfecto y requiere al mismo tiempo precaución y supervisión inteligente por parte de los usuarios. Esencialmente todos los diseños de PKI son menos flexibles y requieren que el usuario siga la cadena de garantías de los certificados generados por la CA.

A cambio, el usuario gana en comodidad y en facilidad de uso con un esquema PKI, puesto que no necesita tener conocimientos técnicos para establecer una comunicación de confianza a través de los mecanismos ya establecidos en su navegador.

Construcción del anillo de confianza GPG No basta con que una persona quiera usar GnuPG. Para poder usarlo para comunicarse en modo seguro con otros, es necesario que tengamos un anillo de confianza. A primera vista, construir un anillo de confianza es una tarea desalentadora. Las personas con las que nos comunicamos necesitan usar GnuPG, y es necesario que haya las suficientes

24

firmas para que las clave sean consideradas válidas. Estos no son problemas de tipo técnico; son problemas de tipo social. Debemos superar estos problemas si queremos usar GnuPG.

En nuestros primeros pasos con GnuPG, es importante darse cuenta de que no necesitamos comunicarnos de modo seguro con todas las personas. Empecemos con un pequeño círculo de amigos, tal vez sólo nosotros y uno ó dos más que también quieran ejercitarse en su derecho a la privacidad. Generemos nuestras claves, y firmémoslas recíprocamente. Éste es nuestro anillo de confianza inicial. Al hacerlo así, apreciaremos el valor de un pequeño, pero robusto anillo de confianza, y seremos más cautos a medida que vaya creciendo nuestro anillo de confianza con el tiempo.

Además de aquéllos en nuestro anillo de confianza iniciático, es posible que deseemos comunicarnos en modo seguro con otros que también están usando GnuPG. Sin embargo, esto puede ser problemático por dos razones:

(1) no siempre sabemos cuándo alguien usa o estaría dispuesto a usar GnuPG.

(2) si sabemos de alguien que lo usa, todavía es posible que tengamos problemas para validar su clave.

El primer motivo sucede porque las personas no siempre hacen público que usan GnuPG. La forma de cambiar ese comportamiento es sentar ejemplo y hacer público que usamos GnuPG. Existen al menos tres maneras de hacer esto:

3. Firmar digitalmente los mensajes que enviamos a otros. 4. Publicar nuestra clave pública en nuestra página en Internet. 5. Si la subimos a un servidor de claves, poner nuestro identificador de clave

como parte de nuestra firma. Haciendo pública nuestra clave, ayudamos a que sea más aceptable para otras personas hacerla también pública.

Además, hacemos más fácil para otros el que puedan comenzar a comunicarse con nosotros en modo seguro, ya que habremos tomado la iniciativa, dejando claro que usamos GnuPG. La validación de la clave es más difícil. Si no conocemos personalmente a la persona cuya clave queremos firmar, no es posible que podamos firmar su clave personalmente con certeza.

Debemos fiarnos de las firmas de otras personas y esperar que encontraremos una cadena de firmas que nos lleven desde la clave en cuestión hasta la nuestra. Para poder encontrar una cadena, debemos tomar la iniciativa y conseguir que nuestra clave sea firmada por otras personas fuera de nuestro anillo de confianza inicial. Un modo efectivo de conseguir esto es participando en «reuniones de firmas».

25

De todos modos, debemos tener en cuenta que todo esto es opcional. No existe ningún tipo de obligación de hacer públicas nuestras claves o de firmar las claves de otros. GnuPG es lo suficientemente flexible como para adaptarse a nuestros requerimientos de seguridad, sean éstos los que sean. Sin embargo, la realidad social es que necesitaremos tomar la iniciativa si queremos engrosar nuestro anillo de confianza, y hacer todo el uso posible de GnuPG.

GPG tiene un repositorio de claves (anillo de claves) donde guarda todas las que tenemos almacenadas en nuestro sistema, ya sean privadas o públicas. Cuando veamos un anillo de claves debemos de recordar que pub hace referencia a la clave pública y sub hace referencia a la privada.

Cuando alguien te manda su llave o la descargas de un servidor de llaves o de una página web, puedes especificar un nivel de confianza que dé cuentas de que esa persona es realmente quien dice ser (a través de la firma de llaves). No estamos hablando de una confianza afectiva sino técnica, pero inevitablemente, el hecho de comunicarme con esta u otra persona también da cuentas de una confianza a nivel personal-humano. Si a mí esa persona me lo ha pasado en persona en una usb y la conozco, o al menos he sostenido una conversación en la que he llegado a conocerla, tengo bastante certeza de que es quien dice ser. Ahora bien, si me ha pasado la llave un amigo o un contacto de confianza, también puedo asignar a la llave un nivel alto de confianza. En cambio, si he descargado la llave de una web sin conocer la persona y no tengo métodos para comprobar su identidad, no puedo asignar a la llave una confianza alta.

Estas verificaciones van formando anillos de confianza, un sistema de referencias entre pares. De tal manera que puedo ver cuántas firmas en común tengo con esa llave. Ojo, por muchas herramientas técnicas que utilices, el hecho de decidir confiar en alguien para contarle información confidencial es una decisión que debe basarte en un espectro amplio de factores y sí, la intuición también.

Sin embargo, al igual que esos anillos de confianza nos dan información a nosotros de quién confía en quién y, en consecuencia, en quién confiamos nosotros, también brinda datos a cualquiera que acceda a esa llave pública puesto que las firmas son parte de este archivo.

Tenemos varias opciones que no son excluyentes:

Firmar determinadas llaves, las que sí queremos explicitar públicamente que confiamos en ellas, pero para contactos más "privados", "internos", optamos por otros métodos de referencias de confianza: comunicación en persona, por mail cifrado, etc.

En la medida que tengamos muchas firmas de personas muy variadas en las que sí confiamos que es quien dice ser, pero no necesariamente es alguien con la que

26

colaboramos o confiamos a otros niveles, ya no desvela los tramos de relaciones concretas. La práctica de firmado de llaves públicas y las cryptoparties cumplen con esta función de crear sistemas decentralizados de verificación de identidades digitales. No necesitamos un sistema centralizado como la policia que expida un carnet oficial sino que entre todxs nos avalamos.

Confianza en el anillo

La clave de otro usuario se valida comprobando personalmente la huella digital de su clave, y firmando su clave pública con nuestra clave privada. Comprobando personalmente la huella digital podemos estar seguros de que la clave pertenece realmente al supuesto usuario y, dado que hemos firmado la clave, podemos estar seguros de que detectaremos cualquier manipulación o falsificación en un futuro.

Desafortunadamente este proceso se complica cuando debemos validar un gran número de claves o cuando debemos comunicarnos con personas a las que no conocemos personalmente.

Uno de los mayores inconvenientes de este sistema es el propio funcionamiento del sistema, ya que al basarse en anillos de confianza no hay forma segura de acreditar que una clave es de quien dice ser, más que por la confianza que tengamos en el que haya firmado dicha clave y por las comprobaciones que hagamos antes de darle confianza.

Es decir, yo no tengo ninguna otra forma de comprobar que una clave es de alguien más que por un amigo común a ambos que me certifica que dicha clave es verdaderamente de quien dice ser, (a no ser que lo conozca personalmente). Si este esquema lo proyectamos a mayor tamaño, obtenemos un esquema de confianza mutua y cíclica, al que se le denomina “anillo de confianza”.

Debido a este problema, es totalmente imprescindible que no se firmen claves de las que su procedencia no sea totalmente segura, ya que sino se estaría introduciendo una clave falsa en el anillo, sería totalmente indetectable para los demás, con los riesgos que ello conlleva. Por eso se suele recomendar que las claves se intercambien mano a mano, y no por Internet…aunque hoy en día es imposible, cada uno vivimos en una parte del mundo.

Otro gran problema, aunque este sea relativo a todos los sistemas de seguridad basados en claves, es que el tiempo que transcurre desde que tú revocas una clave hasta que el resto de Internet sabe de ello puede ser muy grande, o incluso podría pasar que nunca sabrían que esto ha ocurrido. Durante dicho tiempo, podría haber alguien haciéndose pasar por otro, si la clave de éste hubiera sido comprometida. Todos los servidores se intercambian información de las claves, pero este problema no tiene solución fácil, y es uno de los puntos negros de los sistemas de claves asimétricas, en concreto de PGP.

27

Servidores de claves PKI

En PKI, en el momento del registro el propio servidor al darte de alta te incluye en su base de datos automáticamente.

Generalmente existirá un repositorio en el que se publican todos los certificados gestionados por la PKI y puede ser consultado por otros usuarios de la PKI que quieran enviar información cifrada o verificar firmas digitales.

Servidores de claves GPG

En PGP debemos subir personalmente nuestra clave para que pueda ser consultada. Esto quiere decir que podemos crear nuestras claves, utilizar GPG y no necesariamente estar registrados en un servidor de claves.

Para que nos cifren un mensaje tenemos que compartir la clave pública de nuestro par de claves para cifrar, y como es un poco engorroso difundir una clave a muchas personas existen los servidores de claves PGP (compatibles con GPG), donde subir nosotros mismos nuestra clave pública para el que necesite verificarla.

La utilidad de los servidores de claves públicas es que todo el mundo pueda acceder a ellas para corroborar tu identidad y crear anillos de confianza. Existen varios servidores que ofrecen el alojamiento de claves PGP. El utilizado por defecto en GPG es keys.gnupg.net.

La búsqueda de una persona concreta en un servidor podemos realizarla mediante nombre y apellidos, dirección de correo electrónico o ID de la clave PGP tanto en interfaz web como en una terminal de comando.

28

Las claves digitales En un Certificado, las claves digitales son los elementos esenciales para la firma e identificación del firmante. Existen dos claves, la clave privada y la clave pública, que trabajan de forma complementaria Lo que cifra o codifica una clave sólo lo puede descifrar o decodificar la otra.

La diferencia entre ellas es que la clave privada está pensada para que nunca salga del certificado y esté siempre bajo el control del firmante. En cambio, la clave pública se puede repartir o enviar a otros usuarios, e incluso publicar en servidores de validación de claves.

En ocasiones, se habla de Certificado Privado para referirse al certificado que contiene la clave privada y la pública y del Certificado para referirse al certificado que sólo contiene la clave pública.

Importante: Si envías tu certificado a un tercero, asegúrate de que es el certificado público (que contiene sólo la clave pública).

Revocación del Certificado

Después de haber generado un par de claves, el usuario debe, de forma inmediata, generar un certificado de revocación para la clave pública primaria.

Si el usuario olvidara la contraseña, o si su clave privada estuviera en peligro o extraviada, este certificado de revocación podría ser hecho público para notificar a otros usuarios que la clave pública no debe ser usada nunca más. Una clave pública revocada puede ser usada para verificar firmas hechas por el usuario en el pasado, pero no puede ser usada para cifrar datos. Esto tampoco afecta a la capacidad de descifrar mensajes que hayan sido cifrados con la clave antes de su revocación, siempre y cuando el usuario todavía tenga acceso a la clave privada.

Los Certificados electrónicos tienen un periodo de validez pasado el cual no sirven para firmar ni tampoco para identificarse. Cada Proveedor de Certificación establece unos plazos antes de que el certificado caduque para poder renovarlo sin necesidad de otra identificación. Si el Certificado caduca hay que volver a realizar todo el proceso de solicitud del certificado. Sin embargo, un certificado se puede renovar antes de que caduque y el proceso no requiere una solicitud nueva.

Para el caso de certificado por software, en la creación del certificado incluimos su periodo de validez. Puedes invalidar tu Certificado antes de que caduque por razones de seguridad. Una vez revocado, el certificado ya no puede ser reactivado y es necesario volver a iniciar todo el proceso de solicitud.

29

Estas son las principales causas de revocación de un Certificado:

Solicitud voluntaria del Suscriptor. Pérdida o daños en el soporte del Certificado. Fallecimiento del suscriptor o de su representado, incapacidad sobrevenida, total o

parcial, de cualquiera de ellos. Finalización de la representación o extinción de la entidad representada. Inexactitudes en los datos aportados por el suscriptor para la obtención del

certificado. Que se detecte que las claves del Suscriptor o de la Autoridad de Certificación han

sido comprometidas.

Visor de Firmas Electrónicas El visor es una herramienta que permite generar un informe de la firma y ver información de la propia firma electrónica y del documento firmado.

El documento que se genera no tiene el mismo valor legal que la firma. De hecho, puede ser válido en los términos que se determine para su uso. En general, en este caso, el documento impreso deberá contener un CSV o Código Seguro de Verificación que permite contrastar la copia impresa con la original electrónica.

30

El Proceso Básico de Firma Electrónica

El proceso básico que se sigue para la firma electrónica es el siguiente:

El usuario dispone de un documento electrónico (hoja de cálculo, un archivo -pdf, docx, imagen… incluso un formulario en una página web) y de un certificado que le pertenece y le identifica.

La aplicación o dispositivo digital utilizados para la firma realiza un resumen del documento (hash). El resumen de un documento de gran tamaño puede llegar a ser tan solo de unas líneas. Este resumen es único y cualquier modificación del documento implica también una modificación del resumen.

La aplicación utiliza la clave contenida en el certificado para codificar el resumen. La aplicación crea otro documento electrónico que contiene ese resumen

codificado. Este nuevo documento es la firma electrónica.

El resultado de todo este proceso es un documento electrónico obtenido a partir del documento original y de las claves del firmante. La firma electrónica, por tanto, es el mismo documento electrónico resultante. Este es el documento válido a efectos legales y el que debes conservar. Cualquier impresión o representación gráfica que se haga de él solo es válido en los términos que determine el destinatario de la firma. En general, en este caso, la firma impresa deberá contener un CSV o Código Seguro de Verificación que permite contrastar la copia impresa con la original electrónica.

En casos de particulares la firma es manuscrita, se hace de tres formas:

1. Firmando las partes ocupando la firma de cada uno ambos documentos, de manera que cada uno se lleva su documento y para comprobarlo se casan.

2. Ídem a anterior, pero con un sello tampón. 3. Firmando ambas partes en todos los documentos.

31

Ejemplo de firma

Supongamos que queremos mandar un mensaje firmado a nuestro amigo Pepe. Para ello, antes de nada, debemos recordar que Pepe debe tener nuestra clave pública.

Gracias a nuestra clave privada generaremos un correo firmado. Pepe recibirá nuestro correo firmado. Pepe usará nuestra clave pública para comprobar la validez de la firma.

Ejemplo de cifrado

Ahora supondremos que queremos mandar a Pepe un mensaje cifrado para que sólo él pueda ver el contenido. Para ello, previamente, dispondremos de la clave pública de Pepe.

Con la clave pública de Pepe cifraremos el mensaje. Pepe recibirá un mensaje cifrado. Pepe usará su clave privada para ver el contenido del mismo.

¿Cómo firmo un documento? Puesto que estamos hablando de firma electrónica, la firma debe realizarse obligatoriamente por medios electrónicos y la podrás realizar de dos formas:

Descargando una aplicación en tu PC: En este caso utilizas para firmar la aplicación que instalas en tu ordenador y no necesitas estar conectado a internet.

Firmar directamente en internet: Esta opción es usada sobre todo cuando firmas formularios o solicitudes. Para firmar debe descargarse un componente que funciona sobre el mismo navegador.

En ambos casos necesitas disponer de un certificado electrónico.

Validación de la firma digital

Si recibimos o descargamos un documento firmado nos interesa validar la firma. La validación de una firma electrónica es el proceso por el que se comprueba:

1. La identidad del firmante. 2. La integridad del documento firmado: comprobar que los datos firmados se

corresponden con los originales, la estructura del fichero es correcta. 3. La validez temporal del certificado utilizado: marca de tiempo.

32

Sabemos que, en el proceso de firma, el firmante utiliza su certificado electrónico, en concreto su clave privada, para obtener la firma electrónica. Pero ¿Cómo sabemos si una firma es válida? Para ello tenemos dos maneras de hacerlo:

1. Verificación Offline Descargar la clave de firma. Las dos primeras verificaciones se pueden realizar desde una aplicación sin conexión a internet simplemente utilizando el certificado incluido en la misma firma. Verificar, pero sin autentificar la clave de firma a través de un servidor de certificaciones online, se basa en la descarga de una clave de firma genuina desde la web del programa. Esto es un archivo con extensión “sig”. Se pone este archivo junto a la descarga que se desea comprobar y se verifica con un programa o una extensión de navegador. Pero, ¿cómo sabemos si ese certificado es válido?, ¿estaba revocado en el momento de la firma? ¿La Autoridad que lo emitió es de confianza?

2. Verificación Online Autentificar la clave de firma a través de un servidor de certificaciones.

El proceso de validación de la firma no puede separarse del proceso de validación del certificado usado para la firma. Y por eso, la validación de la firma, implica también la validación del certificado (certificado no caducado o revocado).

El certificado electrónico solamente se puede validar mientras esté activo, ya que una vez caducado desaparece de las listas de revocación de la Autoridad de Certificación y ya no se puede comprobar cuál era el estado en el momento de la firma.

Si el certificado no es válido (caducado o revocado), la firma no puede ser validada correctamente puesto que no podemos saber cuál era el estado del certificado en el momento de la firma.

Por tanto, las tres validaciones dependen de la capacidad de validar el certificado, para lo cual es necesaria una conexión a internet que permita acceder online a una plataforma de validación de certificados.

El punto 2 es la única técnica de verificación que asegura que una descarga es idéntica a la original y como tal puede proteger al usuario en caso de que un sitio web se vea comprometido. También es la técnica más complicada y pues debes tener una cuenta con tus claves.

33

Cómo funciona. Clave privada y clave pública. Con la criptografía asimétrica necesitamos dos claves separadas, una es privada (que sirve para el descifrado o la firma digital) y la otra es pública (para cifrar un archivo de texto o para verificar la firma digital).

En cuanto tengamos nuestra pareja de claves podemos proceder de esta forma:

Clave pública: se la enviaremos a todo el mundo que la quiera, la subiremos a un servidor, o a nuestra web... Esta clave permitirá a la gente verificar nuestra firma y crear mensajes cifrados para nosotros.

Clave privada: no se la daremos a nadie, ya que nos permitirá firmar y descifrar correo.

PGP genera las claves a través de muchos algoritmos de encriptación. Es necesario recordar que la clave pública y la privada están matemáticamente conectadas con este algoritmo; por esto, se pueden compartir partes de este algoritmo sin comprometer la seguridad del sistema. Es importante darse cuenta de que estas claves son dos archivos que se generarán en nuestro PC y que están íntimamente ligadas, pero no se puede averiguar una a través de la otra.

Es muy importante no dejar nunca a nadie la clave privada y es necesario elegir una contraseña que solo el usuario pueda recordar y que al mismo tiempo sea difícil de descifrar, así como recordar que la seguridad de las claves depende no sólo de la contraseña que se utiliza para su creación, sino también de cómo se guarda esta clave.

El algoritmo que se emplea para PGP, y el recomendable es el RSA con un tamaño de clave de 4096 bits. Para una mayor seguridad a largo plazo, lo ideal sería de 8.912 bit, pero hay que esperar un poco hasta que finalice la operación (aunque para PGP y GPG hay procesos diferentes para la generación de las claves).

Las claves se usan indistintamente para cifrar y descifrar bloques de información que pueden ser mensajes o bloques binarios, pero dependiendo con que clave cifres es el propósito del descifrado (cualquier clave Pública NO descifra lo que una clave Privada ha cifrado, solo descifra lo que ha cifrado su pareja una sola “Clave Pública” es pareja solo de una “Clave Privada”):

34

1. El uso de la clave pública (descifrar sólo por una persona con su clave privada)

Cifrado con clave pública (enviar mensaje privado) Cifrar y enviar un mensaje seguro que solo podrá ser leído por el destinatario y nadie más, por lo que no podrá ser descifrado jamás si no se tiene la clave privada. Esto garantiza que la información es totalmente confidencial y sólo lo descifra el destinatario.

2. El uso de la clave privada (descifrar por todos con clave pública)

Cifrado con clave privada (firma digital) La clave privada también puede cifrar un mensaje que podrá ser descifrado con quien tenga la clave pública. Ojo porque aquí el propósito cambia, ¿qué sentido tendría enviar un mensaje cifrado que puede ser descifrado con la clave que cualquiera puede obtener? Aquí la privacidad del mensaje no es tan importante, sino confirmar que el que envía el mensaje o publica un archivo es la persona que dice ser.

Como solamente el dueño de la clave privada conoce la clave privada, sólo él pudo haber cifrado ese mensaje o archivo. El que recibe el mensaje o descarga el archivo no tiene duda que quien lo manda es el dueño de la clave privada y es una prueba irrefutable de confiabilidad de que el mensaje o archivo proviene de quien dice ser (fuente fiable).

El Almacén de Certificados

Siempre que vayamos a realizar un proceso de firma electrónica o identificación digital basadas en certificados, será necesario que esos certificados estén disponibles en el ordenador para la aplicación que va a realizar la firma.

Los certificados se guardan en el “Almacén de Certificados”.

Para los certificados contenidos en una tarjeta digital, como el DNI electrónico, la propia tarjeta es el almacén.

Los certificados software se guardan en un almacén que estará ubicado en una ruta concreta del sistema de archivos dependiendo del programa utilizado. Para poder usarlo primero es necesario importar o cargar el certificado de un archivo o servidor a ese almacén.

35

Importar y exportar certificados

La importación de certificados es el proceso que permite cargar el certificado en el ordenador o en el navegador para su uso posterior en la firma o identificación. Los certificados pueden contener la clave privada y la pública, o sólo la pública. Eso depende del tipo de certificado que tengamos y de su extensión.

La exportación se debe hacer desde el almacén en el que está instalado el certificado. La exportación de certificados es el proceso que permite obtener una copia del certificado instalado en el ordenador o en el navegador. En ocasiones es necesario extraer del almacén un certificado para lo siguiente:

Hacer un backup o copia de seguridad del certificado. Instalarlo en otro ordenador. Enviar la parte pública a otra persona

36

Instalar certificados en Windows PKI

El almacén de certificados de Windows es utilizado por navegadores como Internet Explorer, Chrome y por otras aplicaciones como Office y Adobe Reader. La importación de certificados en este almacén se puede realizar desde cualquiera de los dos navegadores mencionados. La forma de acceder al almacén y a las herramientas de importación es la siguiente:

En Internet Explorer Opciones de Internet > Contenido > Certificados. En Google Chrome Opciones > Avanzada > HTTP/SSL > Gestionar Certificados.

Instalar certificados en Firefox

Firefox dispone de su propio almacén de certificados independiente del almacén del sistema operativo. Por tanto, si quieres firmar documentos desde Firefox debes realizar previamente la importación de certificados desde el mismo navegador.

En Firefox Opciones > Avanzado > Cifrado > Ver Certificados.

Validación de PDFs en Adobe

Las aplicaciones Adobe y Adobe Reader permiten la validación de las firmas contenidas en documentos pdf firmados electrónicamente. Sin embargo, para que esto sea posible, es necesario que Adobe reconozca y confíe en los certificados raíces de las Entidades Certificadoras que han emitido los certificados con que se ha firmado el documento.

Por ejemplo, para validar correctamente un documento pdf emitido por el BOE es necesario configurar el entorno Adobe para que reconozca el certificado raíz de la FNMT, ya que ha sido esta entidad la que ha emitido el certificado con el que se ha firmado el documento del BOE. En general, Adobe se puede configurar utilizando alguno de los siguientes métodos:

Usar el almacén de certificados de Windows. 1. Descargar el certificado raíz de la Autoridad de Certificación que ha emitido el

certificado. 2. Instalación del certificado en el almacén de Windows. Haz doble click sobre el

fichero descargado y se mostrará una ventana.

En la pestaña "Detalles" puedes comprobar los atributos indicados para confirmar que se trata del certificado correcto.

Pulsa el botón "Instalar Certificado"

37

Pulsa el botón "Siguiente >"

Pulsa el botón "Examinar" y selecciona "Entidades emisoras de confianza"

Pulsa el botón "Siguiente >" y en la última pantalla pantalla "Finalizar"

Dado que se trata del certificado de una Autoridad de Certificación raíz aparecerá una ventana para solicitar confirmación

Pulsa el botón "Si"

3. Configurar Adobe Acrobat Reader para confiar en el almacén de Windows.

Iniciar Adobe Reader e ir al menú "Edición > Preferencias".

Selecciona la sección "Seguridad" y pulsar el botón "Preferencias Avanzadas".

Selecciona la pestaña "Integración de Windows" y chequea la opción "Validando Firmas".

Pulsa el botón "Aceptar" para finalizar

Usar el almacén de certificados de Acrobat Reader.

Acrobat Reader dispone de su propio almacén de certificados de confianza, que por defecto, es el que utiliza.

El procedimiento de instalación y configuración es el siguiente:

1. Descargar el certificado raíz de la Autoridad de Certificación que ha emitido el certificado.

2. Importar el certificado de la autoridad certificación descargado.

Inicia Adobe Acrobat Reader y selecciona el menú "Avanzadas > Administrar identidades de Confianza".

En las versiones más modernas, este menú se encuentra en "Documentos > Administrar identidades de Confianza".

Pulsa el botón "Agregar Contacto"

Pulsa el botón "Examinar" y seleccione el certificado descargado anteriormente

38

En la ventana que se abre selecciona el Contacto recién importado.

A continuación se muestran los certificados contenidos en dicho fichero

Selecciona el certificado de la Autoridad de Certificación y pulsa el botón "Confiar"

Chequea la opción "Firmas y como una raíz de confianza" y pulsa el botón "Aceptar"

Pulsa el botón "Importar" y Pulsa el botón "Aceptar"

Después de todo este rollo y para los paranoicos decir:

Sólo el cifrado punto a punto es el seguro porque la comunicación es entre dos únicos puntos, y con sus consecuentes medidas de seguridad…claro. PGP y similares no son vulnerables como tal, sólo que dependes de terceros (un servidor o página web) para validar claves o darles confianza... Es decir, la vulnerabilidad no está a nivel de protocolo sino de uso. Y no olvidarse del clásico antivirus.

39

Infraestructura de clave pública PKI (navegadores web)

Cuando compramos en una tienda a través de internet realmente no conocemos a quién le estamos comprando. ¿Quién nos dice que al otro lado no hay un delincuente que simplemente se quedará con nuestro dinero a cambio de nada?

Para esto existe una infraestructura de autoridades de certificación, autoridades de registro, certificados, etc. A todo ello se le conoce como infraestructura de clave pública y nos permite certificar que una persona es quien dice ser, incluso si sufre el robo de sus claves. Toda la infraestructura de clave pública se basa en el uso los certificados digitales.

Un certificado es un fichero que aporta información sobre quién es el dueño de ese certificado. Es como el DNI con la excepción de que un certificado se puede aplicar casi a cualquier cosa, por ejemplo, a una página web. Así, el certificado de una página web informará de cosas como, quien es el dueño de una página web, el algoritmo de cifrado preferido para sus comunicaciones, la clave pública de la web y el periodo de validez del certificado (entre otras muchas cosas).

Por ejemplo, en la siguiente imagen podemos ver una conexión segura (en la que aparece el candado) y al hacer clic sobre el candado nos da información sobre la comunicación web:

40

Como vemos en la imagen anterior, el certificado (en este caso de la página web de Microsoft), nos indica que Microsoft está en Redmond, Washington, US, que la conexión utiliza el protocolo TLS 1.2, que para el cifrado se usa AES_256_CBC y que para la negociación ha utilizado una variante del algoritmo RSA (ECDHE_RSA).

Es más, en la parte de la derecha, nos permite conocer el tipo de clave pública del servicio web (que es una RSA de 2048 bits) y en la parte inferior nos la muestra (dado que es pública la puede conocer cualquiera). Ya veremos qué es cada una de estas cosas.

La entidad generadora de estos certificados es lo que se llama una Autoridad de Certificación (CA) y en certificados web algunos de los más conocidos son VeriSign o goDaddy. En el caso del ejemplo anterior la autoridad de Certificación el cometido de las autoridades de certificación es “certificar” que la información indicada en el certificado digital es cierta. También es responsable de emitir y revocar los certificados digitales.

¿Y cómo sabe esa “autoridad” de certificación que realmente esa web pertenece a esa persona?

La CA (ella misma o a través de otra entidad llamada Autoridad de Registro) hace una serie de comprobaciones y si todo es correcto, genera el certificado y lo cifra con su clave privada. De esta manera el que reciba el certificado sabrá que los datos que aparecen en ese certificado los ha validado una CA (El dato de la CA certificadora es público).

Pero volvemos a lo mismo. ¿Y si esa CA no es quien dice ser? Para certificar su autenticidad las CAs también tiene un certificado digital donde dice quiénes son (es lo que se llama un certificado raíz) y para verificar la autenticidad de este certificado, éste va cifrado por una CA, pero no por la propia CA sino por otras CAs reconocidas del mercado. Se genera de esta manera lo que se llama “Web of trust”, es decir existe una red de CAs que se certifican las unas a las otras. Es difícil suplantar una CA, pero suplantar una red entera de CAs es algo prácticamente imposible.

41

Revocación de certificados Si ocurriera que nuestra web se ve comprometida y descubre la clave privada del servidor, o si, por descuido alguien accede a nuestro correo y descubre nuestra clave privada, la infraestructura de clave pública ya no sería válida. Cualquiera podría hacerse pasar por nosotros, o por nuestro servidor, ya que es conocedor tanto de nuestra clave pública (que era ya conocida por todos), como de nuestra clave privada.

En esa situación es necesario revocar los certificados. Esto se consigue realizando una solicitud a la Autoridad de Certificación que nos los hubiera firmado en su momento. Tras la solicitud en apenas un rato podemos tener los certificados revocados. Si a partir de ese momento alguien monta una web haciéndose pasar por nosotros, el navegador al comprobar la validez del certificado, podrá ver que se encuentra en la lista de revocación de certificados de la autoridad de certificación y nos mostrará un aviso por pantalla:

Un certificado puede estar revocado por diferentes causas. Por ejemplo porque su plazo de validez haya expirado o porque se haya realizado una solicitud de revocación de certificado.

42

Cifrando comunicaciones web

Cuando hacemos una compra a través de Internet estamos enviando cierta información confidencial como los dígitos de la tarjeta de crédito, el usuario, la fecha de caducidad y el código CCV de la tarjeta. Con esta información, cualquier podría realizar una compra a través de internet, suplantando nuestra identidad, por lo que este tipo de datos sólo deben ser conocidos por el usuario y la tienda.

Sin embargo, hay un problema. Esa conexión está pasando por los servidores de nuestro proveedor de Internet, por servidores de comunicaciones alojados (generalmente) en USA, probablemente por otros sistemas de salto alojados en Inglaterra u Holanda hasta llegar a los servidores del hosting de la tienda donde esté alojada la página web donde estamos comprando. Es un largo camino y un montón de sistemas de los cuales no sabemos nada ni si han sido comprometidos o cuál es su configuración de seguridad.

Por esta razón es necesario proteger la comunicación de manera que viaje cifrada desde nuestro ordenador al servidor web de la tienda. Para conseguir esta comunicación cifrada, el primer requisito es que el servidor web este configurado para admitir conexiones HTTPS y que disponga de una certificado SSL que nos informe de quién es, cuál es su dueño y cuál es su clave pública.

Una conexión segura contra un servidor web que admitan conexiones HTTPS tiene 3 fases:

En una primera fase el navegador web y el servidor negocian el algoritmo de cifrado de la comunicación y otros parámetros que permitan realizar la conexión de una forma segura. Este proceso se llama Handshake. El cifrado de la conexión se hace utilizando un algoritmo de cifrado simétrico, con una clave compartida que ambos extremos conocen. Sin embargo, para el intercambio de esta clave conocida por ambos, se utiliza un algoritmo de cifrado asimétrico. Todo esto se negocia en la fase de Handshake.

Una vez terminada la negociación, la conexión segura es establecida. En ese

momento, el servidor web le envía su certificado, que almacena el nombre de la entidad certificadora (CA) del servidor web, el periodo de validez de ese certificado y la clave pública del servicio web. Ese certificado irá firmado (con la clave privada de la Autoridad de Certificacion-CA), por lo que el navegador deberá descifrarlo usando la clave pública de ésta, que como vimos antes, tiene almacenado en una base de datos. Una vez descifrada podrá leer toda la información albergada en el certificado, continuando con la conexión.

43

Si el navegador detecta que o bien el periodo de validez o la CA son inválidos, nos mostrará un mensaje de error indicándolo, pero nos dejará continuar bajo nuestra responsabilidad:

A continuación, el navegador generará una clave maestra de cifrado y se la enviará al servidor web usando la clave pública de éste, y a partir de este momento la comunicación irá cifrada usando la clave compartida (que solo el servidor y el navegador conocen puesto que el intercambio se ha producido de forma cifrada).

El resto de la conexión va cifrada utilizando el algoritmo de cifrado simétrico (cifrado y descifrado con la misma clave) que ha sido negociado en la primera fase de la conexión. El cifrado asimétrico se usa únicamente para la fase de negociación entre el navegador y el servidor.

Casos prácticos

Hasta aquí vale, pero, si yo soy un navegador y al visitar una web recibo un certificado que esté cifrado… ¿cómo lo descifro? Los navegadores vienen por defecto con las claves públicas de las autoridades de certificación más reconocidas. De hecho, lo que almacenan no son las claves, si no los propios certificados de las CAs.

Podemos consultar estos certificados en nuestro navegador preferido. Asi, por ejemplo en Internet Explorer si vamos a a ajustes, opciones de internet –> contenido –> certificados –> Entidades de certificación Raíz de Confianza

O en Google Chrome en Ajustes→Configuración→HTTPS/SSL →Administrar cer ficados, veremos un listado de unas 200 CAs que acepta nuestro navegador.

44

Para demostrar que una página web utiliza un certificado firmado por una entidad reconocida, los navegadores suelen mostrar un candado verde en la barra de direcciones del navegador (en la siguiente imagen, un ejemplo con los tres navegadores principales):

Puede ocurrir que el certificado utilizado para firmar no sea reconocido por el navegador (porque no ha sido instalado por defecto). Esto ocurre por ejemplo en la Sede Electrónica de la Administración Española, como podemos ver en la siguiente imagen.

No se trata de que el sitio no sea de confianza (pocas cosas considero que sean más confiables que una administración gubernamental). El problema en estos casos es que el navegador no lleva incorporado el certificado de la entidad que está firmando la página web.

45

En la imagen (es la página de la sede electrónica del MEC), la CA resulta ser “AC Administración Pública” pero como el navegador (en este caso Google Chrome) es de origen americano y se pretende que sea de uso universal, no incluyen por defecto a la administración española como CA. Esta es la razón por la que cada vez que tenemos que realizar trámites con la administración, nos pide que instalemos los certificados que la avalan.

En otros navegadores es más aparente. Por ejemplo, en Firefox o Internet Explorer en vez de tachar el candado lo dibujan en gris:

Existe por último la casuística en que, al acceder a un sitio web, el certificado es auto firmado. Esto quiere decir que no lo avala una autoridad de certificación. En esos casos los navegadores nos informan mediante un aviso muy explicativo:

46

Esto no tiene por qué significar error alguno. En estos casos la navegación será segura (los datos irán cifrados), pero simplemente nadie nos puede garantizar que este sitio es legítimo de la tienda que estamos visitando.

Los posibles errores que nos encontramos son muchísimos. Por eso es importante leerse el mensaje de error para entender lo que está pasando. En el siguiente ejemplo el mensaje nos avisa de que el certificado no es para el sitio web que se visita (en concreto se quiere visitar ixxxxc.com y el certificado es para lxxxxs.com). En este caso la explicación es que se ha contratado el desarrollo de la web ixxxxc.com a la empresa lxxxxs.com y ésta, para ahorrar costes ha subido su propio certificado en vez de contratar uno nuevo. La conexión

47

irá cifrada, sí, pero el mensaje (un poco exagerado) nos advierte de que posiblemente la web no pertenezca a ixxxc.com.

Resumen

Cuando visitamos una página web segura y nos aparece un aviso de error es importante leer el mensaje que nos aparece. Básicamente podemos resumir los errores en tres:

El certificado no es de confianza (no ha sido firmado por una CA) El certificado no es para quien dice ser El certificado ha sido revocado

En los tres casos podemos decirle al navegador que continuamos con la navegación. La conexión irá cifrada por lo que nadie podrá ver lo que se transmite, pero podría ocurrir que la web no es de quien dice ser y podríamos estar enviándoles información sensible pensando que se trata de una web legítima.

Cuando al visitar una web segura no nos salta el aviso, el cifrado asimétrico y la infraestructura de clave pública nos están asegurando de que la web es legítima, la persona que está detrás es quien dice ser y comunicación va cifrada y nadie puede escucharla.

48

Proceso exacto de firma digital Una firma digital se consigue calculando un valor “hash”, que es un valor único que cambia cada vez que se modifica lo más mínimo un documento (un espacio en blanco más o menos, implica un valor hash completamente diferente). Ese valor hash se adjunta al final del documento y se cifra para que nadie pueda leerlo más que el receptor.

De esta manera que el receptor del mensaje o documento, lo primero que hace es descifrar el hash, calcular el “hash” del mensaje o documento y comprobar si son iguales. Si son diferentes, advertirá al usuario de que podría haber habido una modificación del mensaje durante el tránsito.

Se pueden firmar todo tipo de documentos (PDFs, TXTs, DOCs, JPGs, etc) y también se pueden firmar correos electrónicos y cualquier cosa que se quiera enviar por internet.

En resumen, el proceso de firma es el siguiente:

1.- Creamos el documento que queramos firmar, ya sea un documento PDF, o lo que deseemos. En este ejemplo vamos a usar un documento PDF.

2.- Se obtiene el valor hash, único de ese documento. Hay distintas funciones Hash (MD5, SHA1, SHA-256, etc.). El más utilizado actualmente es el SHA-256. SHA-256 genera un valor de 256 bits (que en hexadecimal puede tener este aspecto: c6b6b0c4147befff952eabfdb9bdc0a0c25bc8204378aadf8e9c52f2b30cc3c1) y que es único para dicho documento. Para hacernos una idea, al documento anterior le añadí un espacio en blanco y el hash SHA-256 que obtuve fue 20dc443a2071c615d6e90594043af06357de8fa8f53eb39f03e11516508f8dd5. Como vemos no se parecen en nada.

A partir de este valor es imposible obtener ninguna información del documento original, pero siempre que lo calculemos (si no hemos modificado el documento), nos sacará el mismo valor hash.

3.- Se cifra, con nuestra clave privada, este hash SHA-256 que hemos obtenido del PDF. El texto obtenido que puede ser similar a:

lzODK0TwL2AUkdcJ7abiee3tc93jrMxqTxu7V0xJoNImKA105TzEHAOzeSUW1N/uudGwTLFZgQt4ejbpLCNwWzG6X8KwVaPPZW/zAwzB4DcnScn6zcz/uRnYs8iBBIabuRN7M1vRHoM77szsxA+hyQxwek/i702lyshkArtQ5Q4=

Es la firma digital del documento PDF. Esto generalmente se guarda en un pequeño archivo.

Si además queremos cifrar el documento para garantizar la confidencialidad y el no repudio, se continuaría con los siguientes pasos:

49

4.- Se cifra el documento PDF original usando la clave privada del emisor.

5.- Se cifra otra vez este documento PDF ya cifrado, pero esta vez usando la clave pública del destinatario.

Si sólo se quiere firmar el documento (por ejemplo queremos que el documento sea público pero que vea que lo hemos firmado nosotros) bien en el correo electrónico o por el medio que sea, se enviará el documento PDF en claro y el fichero de la firma digital.

Si por el contrario, se desea confidencialidad y no repudio, los siguientes tres documentos se unirán en un documento único y se envían por correo electrónico o el método que sea:

– El documento PDF doblemente cifrado.

– El fichero con la firma del documento original.

– La clave pública del emisor (este último no es necesario puesto que las claves públicas son eso, publicas, y están disponibles en los servidores de claves).

Este proceso esta descrito en el siguiente esquema:

50

¿Y por qué es necesario este proceso tan largo? Bien, veamos los pasos seguidos:

La firma digital (pasos 1-3) es un hash que varía con la menor modificación del documento y ese hash ha sido firmado con la clave privada del emisor. Con esto el receptor se asegura de que ese documento no ha sido modificado desde que el emisor lo firmó. A esto se le llama integridad.

El primer cifrado del PDF (paso 4), hecho con la clave privada del emisor, sólo puede ser descifrado con la clave pública del emisor. Con esto, el receptor puede estar seguro que ese documento fue cifrado por la persona que le manda el documento. A esto se le llama no repudio.

El segundo cifrado del PDF (paso 5), hecho con la clave pública del receptor, sólo puede ser descifrado con la clave privada del receptor. Con esto el emisor se asegura que sólo el receptor puede leer el documento. A esto se le conoce como confidencialidad.

Aunque el proceso es muy largo, un ordenador lo hace en cuestión de milisegundos. Quizás el cifrado, si el documento original es muy grande, pueda llevar unos segundos, pero no más.

El proceso de descifrado y comprobación de firma por tanto es el siguiente:

51

En resumen, el documento se descifra dos veces, usando primero la clave privada del receptor y luego la clave pública del emisor. Con eso nos aseguramos la confidencialidad y el no repudio. Si queremos comprobar la integridad del envío, deberemos realizar el mismo proceso que se realizó en el momento de la creación de la firma digital y comparar la firma obtenida con la recibida por correo electrónico. Si son iguales, aseguramos la integridad del envío.

Lo mismo que se ha realizado con un documento PDF, se pueden firmar correos electrónicos o mensajes de mensajería instantánea. En el fondo, tanto los correos electrónicos como los mensajes son pequeños ficheros que puede ser cifrado firmados igualmente.

52

EJEMPLO DE COMUNICACIÓN CON CIFRADO ASIMETRICO

Los algoritmos de cifrado asimétrico permiten realizar comunicaciones cifradas seguras entre actores que no se conocen entre sí a través de un medio inseguro. En Internet un actor puede ser un servidor web, un cliente de correo, un navegador web, etc. Para conseguir esta comunicación segura, cada uno de estos actores debe tener una clave pública (que todo el mundo puede conocer) y una clave privada (que sólo el propio actor debe conocer).

Estas claves tienen la característica especial de que un mensaje cifrado con una de esas claves (ya sea la pública o la privada) puede ser descifrado por la otra. Es decir, si ciframos un mensaje con nuestra clave privada sólo podremos descifrarlo con nuestra clave pública. Y viceversa. Por eso se llama cifrado asimétrico.

El cifrado asimétrico permite garantizar la autenticidad de cada uno de los actores, la confidencialidad de la comunicación y el no repudio en el envío de un mensaje (ya sea texto, o una imagen o lo que sea, en adelante se le llamará “mensaje”).

La autenticidad garantiza que cada actor es quien dice ser y no otro. La confidencialidad garantiza que si alguien intercepta el mensaje no podrá entender nada y el no repudio garantiza que si alguien envía un mensaje luego no puede negar que lo ha enviado.

Para conseguir estas tres características, el emisor cifrará el mensaje primero con su clave privada y el mensaje resultante a continuación lo cifrará de nuevo con la clave pública del receptor. Es decir, se cifrará dos veces.

Para descifrar el mensaje, el receptor (el legítimo receptor) deberá primero descifrar (es decir pasar el algoritmo de descifrado) usando su clave privada y al mensaje resultante (que aún será ilegible) se pasará de nuevo por el algoritmo de descifrado, esta vez usando la clave pública del emisor (que es conocida por todo el mundo).

Este proceso queda reflejado en la figura. Andrés quiere mandarle un mensaje secreto a Bea. Primero lo cifrará con su clave privada y luego con la clave pública de Bea. Nótese que a partir del momento en que lo cifra con la clave pública de Bea, sólo Bea podrá descifrar el mensaje. Ni siquiera el propio Andrés podría descifrar su mensaje si se olvida de lo que ha puesto.

Para descifrar el mensaje que le llega a Bea, ésta primero los descifra con su clave privada y el contenido resultante (aún ilegible) los descifrará de nuevo con la clave pública de Andrés.

Por supuesto el algoritmo de cifrado y descifrado debe ser el mismo (ya sea Diffie-Hellman, RSA, etc.).

53

Si alguien fuera capaz de interceptar el mensaje (por ejemplo cuando pasa por un servidor sobre el que no tenemos control en internet) nunca podrá descifrarlo. Lo que verá será una ristra de caracteres sin sentido (¿s4$’@”z…). Como no dispondrá de la clave privada de Bea, le será imposible descifrar lo que pone en ese mensaje. Con esto se consigue la confidencialidad.

Como Bea tiene la clave pública de Andrés, si consigue descifrar por completo el mensaje, puede estar segura de que ese mensaje lo ha escrito Andrés (Autenticidad) y es más, éste no puede rechazar su escritura (No repudio) porque nadie más que él tiene su clave privada por lo que ha tenido que escribirlo Andrés.

Lo cierto es que lo único que asegura este esquema es que el mensaje fue cifrado con la clave privada de Andrés, no que fuera él, libremente, quien lo escribió. Pudo ocurrir:

Andrés fue secuestrado y fue obligado a escribir el mensaje. La clave privada de Andrés fue robada y alguien escribió el mensaje por Andrés. Alguien se hizo pasar por Andrés y le mandó el mensaje a Bea.

Ante la primera hipótesis poco puede proteger el cifrado asimétrico. La segunda y tercera hipótesis sólo serían posibles si no se utiliza “una infraestructura de clave pública” (PKI en inglés), que permite, por una parte revocar las claves públicas y privadas y por otra parte certificar que una persona con una clave pública es físicamente quien dice ser.

54

Multifirma Puede ocurrir que un documento tenga varios autores y se desee que todos firmen. El proceso en ese caso depende de si el documento va cifrado o no.

Si el documento no va cifrado, el proceso consiste en calcular el hash del documento original y firmarlo por separado todos los firmantes con sus respectivas claves privadas. Es decir, todos los firmantes cifran el hash original del documento y en el documento finalmente generado, no hay una firma, sino tantas como firmantes haya.

Puede ocurrir que se desee por ejemplo firmar un documento por dos directores y luego por un interventor que dé fe de que ese documento es real y ha sido firmado por los dos directores.

En ese caso, el hash del documento será firmado por ambos directores, obteniéndose dos firmas. Esas dos firmas se unirían en un único documento que sería a su vez firmado por el interventor. Es decir, se recibiría el documento, sin cifrar, y otro documento de firma que habría que descifrar usando la clave pública del interventor para obtener las dos firmas digitales de ambos directores.

Si además hablamos de cifrado de documentos (o mensajes) multifirmados, en este caso el orden es importante. Así, se debe descifrar primero con la clave pública del último que cifró (y firmó) el documento. ¿Y cómo sabemos cuál es el último? En estos casos junto al documento “multicifrado” sólo se recibe una firma digital, de la que podemos obtener quién es el firmante. El firmante será también el cifrador. Es esa clave pública de ese cifrador la que debemos utilizar.

Al descifrar el documento con esa clave pública, se genera otro documento (cifrado) y otra firma digital, correspondiente otro firmante. Usaremos pues la clave pública de este segundo firmante para descifrar tanto el documento como la firma digital. Así se continúa con todos los firmantes.

Sello de tiempo El proceso de verificación de una firma electrónica debe poder repetirse en cualquier momento en el futuro, incluso años después de su generación.

A lo largo del tiempo los algoritmos de cifrado pueden llegar a ser vulnerables siendo posible obtener las claves privadas si el algoritmo es vulnerable.

55

La solución (a grandes rasgos) de estos problemas consiste en incluir un sello de tiempo en la firma de manera que esta fecha no sea incluida por el propio firmante sino por una entidad de certificación de sello de tiempo (TSA).

Por otra parte, es necesario que en el proceso de firma se compruebe que el certificado del firmante no haya caducado. Esto se consigue realizando una petición OCSP a un servidor de claves que nos asegure que el certificado es válido.

Por esta razón el proceso de firma se complica un poquito más, incluyendo dos pasos anteriores a la firma que son:

1. Petición de validez de certificado OCSP a un servidor de claves.

2. Solicitud de una sello de tiempo a una TSA.

Formato de firma digital Una de las preocupaciones que apareció posteriormente a la implantación de la firma digital fue que, por ejemplo en Europa, un documento firmado digitalmente en un país miembro de Europa, debía ser válido en cualquier otro país miembro.

El nivel de interoperabilidad debía ser establecido utilizando estándares abiertos y debían existir diferentes niveles de seguridad y confidencialidad según la importancia del documento. Todo ello se recogió en la Directiva Europea 1999/93/CE.

Esto se solucionó desde un punto de vista técnico estableciendo un formato de firma muy abierto.

Como hemos visto, una firma digital no deja de ser un fichero (o varios) que contiene(n) información sobre el documento original, el firmante, la fecha de la firma, algoritmos utilizados y posible caducidad de la firma.

En ocasiones ese fichero de firma va incrustado en el documento original y en otras se trata de ficheros separados.

La forma en que se estructura esta información dentro del archivo de firma (el orden de esa información dentro del fichero, las etiquetas que indican cuando empieza un campo y cuando termina, la opcionalidad de esos campos, etc.) viene determinado por el formato en que es enviada la firma. Existen distintos formatos actualmente como son CMS, CAdES, PAdES, XAdES, etc.

56

CMS (Criptographic Message Syntax) fue el primer estándar de mensajes protegidos criptográficamente y se basó en PKCS#7, que es el estándar para el cifrado y firmado de mensajes en una infraestructura PKI.

CMS es un marco general para la firma de documentos digitalmente, tales como E-Mail (S / MIME), PDF o cualquier otro tipo de documento.

CAdES (CMS Advanced Electronic Signatures). Este formato, del año 2000, es la evolución del formato CMS. Es apropiado para firmar ficheros grandes, especialmente si la firma contiene el documento original porque optimiza el espacio de la información.

Al poco de crear CMS

En el marco de esta directiva, CAdES especifica seis perfiles precisos de datos firmados para su uso con firma electrónica avanzada.

Esto quiere decir, a efectos prácticos, que el formato de la firma usando cada perfil es diferente, el receptor debe detectar con qué perfil viene el fichero de firma y ser capaz de extraer la firma en sí.

En 2001 aparece XAdES (XML Advanced Electronic Signatures). Se trató de una evolución paralela a CAdES. Mientras de CAdES se basó en CMS, XAdES se basó en XML-DSIG. Con XAdES, el resultado es un fichero de texto XML. Los documentos obtenidos suelen ser más grandes que en el caso de CAdES, por eso no es adecuado cuando el fichero original es muy grande. XAdES introduce también las adaptaciones y extensiones de la directiva 1999/93/CE, creando sus propios perfiles, incompatibles con CAdES. Aplicaciones como eCoFirma del Ministerio de Industria y Comercio, sólo firman en XAdES.

En 2009 aparece PAdES, que se basan directamente en PKCS#7 y el estándar 32000-1, que establecen un framework para la firma de digital de documentos. PAdES incorpora las mismas características de CAdES y XAdES, pero únicamente para ficheros PDF. Por esta razón es el formato más adecuado cuando el documento original es de este tipo.

Con PAdES, el destinatario de la firma puede comprobar fácilmente la firma y el documento firmado, ya que se trata de una firma visible y legible para el ser humano. Con los formatos anteriores esto no era posible si no se utilizan herramientas externas.

La estructura del documento de firma digital es diferente en cada uno de estos formatos y dentro de cada formato es diferente en función del perfil utilizado, incluyendo más o menos información en cada caso. No es objetivo de este artículo la descripción del formato de cada uno de estos estándares. La mayoría de las soluciones actuales soportan todos estos formatos.

57

Resumen La Ley 59/2003, de 19 de Diciembre sobre la Firma Electrónica establece los requisitos que una firma digital debe cumplir que son sobre todo tres, Identificar al firmante, Verificar la integridad del documento firmado y Garantizar el no repudio.

El proceso de firma se basa en la obtención de un valor hash del documento y el cifrado de este hash para su envío junto con el documento. Sin embargo, esta firma sólo garantiza la integridad, el resto de objetivos se consiguen cifrando ambos ficheros (el documento y la firma) con la clave privada del emisor y la clave pública del receptor.

Para poder verificar que una firma de un documento se ha realizado en una fecha determinada, y que esta firma es válida, al proceso de firma se le han incluido dos pasos más, una petición de validez de certificado al servidor de claves y una solicitud de un sello de tiempo a una entidad certificadora de tiempos.

Cabe mencionar, por último, que existen por ultimo diferentes formatos de firma digital (CAdES, XAdES, etc), y las aplicaciones de validación de firma deben estar preparados para la verificación de todos ellos.

El funcionamiento es muy simple, hagamos un resumen de tres pasos:

PASO 1: Adrián genera su par de claves, una pública y otra privada. Quique hace lo mismo en su propia computadora.

PASO 2: Adrián le envía a Quique un correo con su clave pública. Quique se lo responde entregándole su propia clave pública. Ambos guardan en secreto su clave privada para que sólo lo sepan ellos.

PASO 3: Desde este momento Adrián y Quique podrán comunicarse con cifrado GPG. Por ejemplo, si Adrián quiere escribirle o enviar un archivo a Quique lo cifrará con la clave pública de Quique. Al llegar el correo, Quique escribirá su contraseña (clave privada) y el mensaje será descifrado automáticamente. Cuando Quique quiera responder, lo hará cifrando el mensaje con la clave pública de Adrián.

Este método es muy seguro, pero obviamente solo funciona si Adrián y Quique se ponen de acuerdo en utilizarlo. El gran problema con GPG es que muy pocas personas lo utilizan. De nada nos sirve tener instalado GnuPG si desde la otra parte no saben usarlo.

58

https://es.scribd.com/document/285985426/Tutorial-Uso-Gpg4win-Cifrado-Ficheros

https://kingworldnet.wordpress.com/2015/09/28/tarea-3-cifrar-un-fichero-con-kleopatra-gpg4win/

https://programarivm.com/cifrar-archivos-en-windows-con-gpg4win-y-kleopatra/

http://www.lanacion.com.ar/1882653-la-historia-de-pgp-un-arma-que-muchos-tenemos-en-casa-sin-saberlo

https://militantepsr.wordpress.com/2017/02/07/gpg-la-mejor-arma-para-cuidar-nuestra-privacidad-digital/

https://ayudahispano-3000.blogspot.com.es/2015/10/criptografia_27.html?m=1

https://danielpecos.com/documents/seguridad-informatica/criptografia/

https://www.gnupg.org/gph/es/manual/c16.html

https://www.gnupg.org/gph/es/manual/x354.html

http://sabina.pntic.mec.es/lmuf0005/criptografia.html

http://www.hcsoft.net/lab/index.php?zona=comohacer&hoja=firmadigital

https://ssd.eff.org/es/module/como-usar-pgp-para-windows-pc

http://cerowarnings.blogspot.com.es/2011/11/proteger-nuestra-informacion-con_08.html

https://wiki.kefir.red/Categor%C3%ADa:GnuPG

https://www.emezeta.com/articulos/como-firmar-pdf-con-certificado-digital

http://realsec.com/novedades/cifrado-comunicaciones/?doing_wp_cron=1513067135.7404789924621582031250

http://realsec.com/novedades/digital-signature-time-stamping-encryption-documents/?doing_wp_cron=1510791579.0821859836578369140625

http://laboratoriolinux.es/index.php/-noticias-mundo-linux-/software/15423-verificar-la-integridad-de-archivos-firmados-mediante-gpg.html

https://wiki.kefir.red/Categor%C3%ADa:GnuPG

https://informantedimensional.wordpress.com/2016/09/05/cifra-tus-mensajes-y-archivos-con-gpg4win/

Y hasta aquí nuestra extensa introducción (y un poco repetitiva) de firma digital. Hay que tener claro que con PKI utilizamos las CA (los navegadores web hacen uso de este método) y con GPG los anillos de confianza. Ahora vamos comprobar algunos archivos descargados que poseen firma con PGP.

59

Verificar la integridad de archivos firmados mediante GPG con Windows

Antes de empezar obligatorio comprar un antivirus, nada de freeware.

GnuPG es una herramienta de línea de comandos sin interfaz gráfica de usuario. Es un motor criptográfico universal que se puede utilizar directamente desde un indicador de línea de comando, desde scripts de Shell o desde otros programas. Por lo tanto, GnuPG se usa a menudo como el backend criptográfico real de otras aplicaciones. De tal manera en Windows podemos utilizar GPG en modo ventana (Gpg4win) o modo consola (GnuPG).

Descargamos Gpg4win y su fichero “Gpg4win signature” (archivo con extensión sig).

Como no tenemos instalado GpG ni cuenta GpG para verificar la firma, lo primero que hay que hacer es verificar su hash de descarga.

Instalamos gpg4win.

60

GPG4Win es compatible con los dos estándares más extendidos: OpenPGP y S/MIME (X.509). Una vez descargamos e instalamos este software en nuestro sistema Windows dispondremos de una serie de componentes listos para ser utilizados:

GnuPG: El módulo encargado de cifrar los archivos. Kleopatra: Un administrador de certificados para los dos estándares compatibles. GPA: Un asistente administrador de certificados alternativo a Kleopatra. GpgOL: Un plugin para cifrar el correo desde Microsoft Outlook. GpgEX: Plug in de menú contextual en explorador de Windows.

Además, existen los correspondientes plugin para los diferentes navegadores web.

Seleccionarlos todos.

Ahora lo primero que tenemos que hacer es crear nuestras claves, tanto la privada como la pública. Para ello abrimos Kleopatra para acceder a la gestión de nuestros certificados, como vemos en la imagen de momento no tenemos ninguno, ya que es la primera vez que lo abrimos y no hemos generado ni importado ninguno.

61

Archivo>Nuevo par de claves

Lo siguiente que nos pregunta la aplicación es si deseamos crear un certificado de tipo OpenPGP o de tipo X.509. En el primero de los casos lo podemos crear nosotros mismos directamente. En el segundo, la aplicación nos permite crear la solicitud, pero no el certificado final, que deberá ser creado y firmado por una Autoridad de Certificación (CA).

62

Si necesitamos enviar correo cifrado o firmado con el estándar S/MIME necesitaremos un certificado de este segundo tipo. La ventaja del primer tipo es que es de tipo auto-servicio: nosotros nos creamos nuestro propio certificado con los datos que queremos y lo tenemos listo para usar de inmediato. La desventaja es que no hay un tercero que de fé de la veracidad de los datos, por lo que la “gestión de la confianza” del certificado de otras personas es más engorrosa. Es decir, corre de nuestra cuenta verificar que tanto los datos del certificado, como la titularidad del mismo y la identidad de su creador son ciertos. En nuestro caso, para no depender de terceros a la hora de generar los certificados, y por motivos de compatibilidad con más usuarios (OpenPGP es un estándar más usado a día de hoy que S/MIME con certificados X.509) vamos a crear certificados del primer tipo. Seleccionaremos la primera opción y se requerirá que coloquemos nuestros datos que figurarán en la clave pública. Los datos requeridos son el nombre y email. Desde luego puede utilizarse información falsa, y ni siquiera es necesario confirmar el email. La información que pongamos será visible para quien posea nuestra clave pública, así que la veracidad o no de la información depende de las necesidades de cada uno. Tan solo basta con que nuestros contactos sepan a quién pertenece la clave para cifrar así los correos que nos enviarán o simplemente tener una cuenta para poder verificar la firma de archivos descargados. En todo caso es importante señalar que se pueden crear y utilizar tantos certificados de cada tipo como sea necesario. De forma que podríamos crear y utilizar uno o varios certificados OpenPGP con aquellos usuarios que sólo puedan usar o prefieran ese tipo de certificados, y uno o varios certificados de tipo X.509 con aquellos otros que lo necesiten o lo prefieran. Según vamos rellenando los detalles, se nos muestra en la parte inferior como quedaría la identidad que se almacenará en el certificado, y que será lo que vean los demás.

63

Antes de continuar con el siguiente paso puede resultar útil tocar la “Configuración avanzada” y modificar los bits de la clave y pasarlos de los 2,048 que vienen por defecto a 4,096 para que nuestra clave sea aún más segura. GPG nos permite elegir el tipo de clave que queremos usar, hay opciones que solo permiten firmar y otras que permiten firmar y cifrar (elegir una de las dos primeras opciones: clave para firmar y subclave para cifrar). 1. RSA y RSA (firma y encripta) 2. DSA y El Gamal (firma y encripta) 3. DSA (sólo firma) 4. RSA (sólo firma)

GPG nos permite elegir la longitud de la clave, entre mayor sea la longitud, mayor encriptación tendrá. Elegir 4096 bits. Asimismo se recomenienda especificar que el certificado es tanto para firma (Signing) como para cifrado (Encryption), e indicar una fecha de caducidad es recomendable. Aquí ponemos la fecha en la que expirará la clave: sin fecha no caduca, a modo de ejemplo.

Por último, nos pedirá la contraseña que salvaguarda la clave privada. Podemos utilizar múltiples palabras o frases tan largas como queramos (que suelen ser más fáciles de recordar). Según la vamos introduciendo nos va indicando la calidad (robustez) de la contraseña.

64

Ya tenemos creado las claves (el certificado). En ella se nos muestra la huella digital (Fingerprint) de nuestro certificado. Este es uno de los datos que se pueden consultar más tarde y que se suelen usar para poder verificar la veracidad del certificado y la de su propietario.

Además, se nos da la opción de hacer una copia de seguridad del certificado, ahora es el mejor momento para hacer una copia de seguridad del mismo y almacenarla en un lugar seguro. Las llaves se pueden exportar a archivos para que las podamos distribuir entre la gente que queremos que nos cifre o firme cosas o bien porque vamos a formatear el equipo y necesitamos salvarlas y restaurarlas.

La primera opción nos permite guardar un archivo de respaldo con la clave privada. El proceso es muy simple, se nos abrirá una ventana donde debemos escoger la ruta donde queremos guardar nuestra clave, si queremos guardarla como texto seleccionamos ASCII, si no se guardara en un archivo de formato binario. Pulsamos OK, y listo. Nos crea un archivo con extensión “gpg” si es binario y con extensión “asc” si es ascii.

65

En ASCII al ser texto podemos abrir con notepad y veremos algo así:

-----BEGIN PGP PRIVATE KEY BLOCK-----

……….

-----END PGP PRIVATE KEY BLOCK-----

La segunda opción es para enviar el backup por correo electrónico. La tercera es para subir los certificados a un servidor (no recomendable esta

última opción, ni tampoco la segunda si el correo electrónico es inseguro o utiliza formato HTTP en vez del HTTPS).

Cuando esté todo listo le damos a “Terminar”. Ahora podremos ver en la pantalla principal de Kleopatra el certificado nuestro, que acabamos de generar. Veremos el nombre, la dirección de correo, la fecha desde la validez de las claves, los detalles y el Key-ID que utilizamos en el caso que se lo queramos dar a otro usuario para buscar nuestra clave pública sino la tiene ya, por ejemplo en un servidor como RedIris.

Ya tenemos nuestro certificado, y esto nos permitirá cifrar ficheros para nosotros mismos (esto es, que sólo podamos descifrar nosotros). Pero será habitual que tengamos que cifrar ficheros para terceros. En este caso necesitaremos una copia de sus certificados. En concreto, de la parte pública de sus certificados (puesto que la privada nunca debe ser publicada). En lo sucesivo en este apartado nos referiremos a “los certificados” cuando queramos decir “la parte pública de los certificados”, por simplicidad.

Y para que cifren ficheros para nosotros debemos enviar nuestro certificado. Para generar nuestra clave pública, la que compartiremos, en la pantalla principal de Kleopatra seleccionamos el certificado que acabamos de generar y pulsamos sobre Exportar. Se nos

66

abre una ventana de exploración donde debemos de indicarle donde debe de guardar la clave pública, le damos un nombre, pulsamos en Guardar, y ya está. Al igual que antes vamos a ver que ha generado un archivo ascii (extensión asc) y podremos ver algo como esto en notepad:

-----BEGIN PGP PUBLIC KEY BLOCK-----

……….

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

Publicar nuestro certificado GPG (Distribución de claves)

Lo ideal sería que pudiéramos distribuir nuestra clave entregándosela en persona a nuestros corresponsales. Sin embargo, en la práctica las claves se distribuyen a menudo por correo electrónico o algún otro medio de comunicación electrónica. La distribución por correo electrónico es una buena práctica sólo cuando tengamos unos pocos corresponsales, e incluso si tuviéramos muchos corresponsales, podríamos usar un medio alternativo como puede ser publicar nuestra clave pública en nuestra página en internet. Pero esto es inútil si las personas que necesitan nuestra clave pública no saben dónde encontrar nuestra página.

Para solventar este problema existen los servidores de claves públicas que recolectan y distribuyen las claves públicas. Cuando un servidor recibe una clave pública, bien la añade a la base de datos o bien la fusiona con una copia de la clave. Cuando alguien requiere al servidor una clave pública, éste la busca en la base de datos y, si la encuentra, la envía a quien se la haya solicitado.

Los servidores de claves también son útiles cuando hay muchas personas que firman las claves de otras con frecuencia. Sin un servidor de claves, cuando Arancha firmara la clave de Javier, debería enviar a éste una copia de la clave firmada por ella de manera que Javier pudiera añadir la clave firmada a su anillo de claves, así como distribuirla a todos sus corresponsales. Mediante este proceso Javier y Arancha sirven a la totalidad de la comunidad construyendo lazos en forma de anillos de confianza o lo que es lo mismo, mejorando la seguridad de PGP. De todos modos, esto es una molestia si se firman las claves con frecuencia.

Antes de subir tu clave pública a un servidor de claves, es bueno tomar un momento para considerar si deseas que todo el mundo sepa que tienes un certificado público sin la posibilidad de eliminar esta información en un momento posterior. Si nos decidimos a compartirla con todos, podemos:

67

1. Difusión de la clave usando un archivo. Para poder enviar una clave pública a otra persona (sin usar un servidor de claves), tenemos que exportarla a un archivo.

Se envía como adjunto en un correo electrónico a la persona que queramos que la tenga, copiar TODO el texto que hay en el archivo y enviarlo en el cuerpo del mensaje o copiar el archivo y entregárselo a dicha persona por medio de un soporte físico (memoria USB, cdrom, diskette, etc.)

2. Difusión de la clave usando un servidor de claves. Los servidores de claves suelen ser de acceso público (al no haber problema por difundir una clave pública) y en este caso se puede subir a cualquiera. La gente puede solicitarla de forma remota para poder enviarte datos cifrados y correos electrónicos. Publica la claves en cualquier servidor de claves, todos se sincronizan entre sí, por lo que la clave estará en cada uno de ellos.

Los servidores de claves facilitan la búsqueda y descarga de las claves públicas de otros. La mayoría de los servidores de claves modernos se sincronizan entre ellos, lo que significa que una clave pública subida a un servidor con el tiempo estará en todos los demás

Hay varias maneras. Una es desde Kleopatra seleccionamos nuestra cuenta y pulsamos sobre “Publicar en el servidor”, y se publica en el servidor que tenemos definido en el programa. Otra forma es publicar directamente en un servidor. Vamos a publicarla en el ordenador del MIT ( https://pgp.mit.edu/ ).

68

Para ello abrimos en nuestro notepad la clave pública, la copiamos en el portapapeles y después la pegamos en la web del MIT y publicamos. Vemos que tenemos opción de borrar un certificado, esto es la revocacion.

69

Crear certificado de revocación

Ten en cuenta que cuando exportas una clave PGP a un servidor público ya no se puede eliminar del mismo. En lugar de eliminarse, se revoca, ese es el término empleado para borrar certificados.

Así pues, antes de subir una clave a un servidor público se recomienda crear primero un certificado de revocación, aunque si haces una copia de seguridad de tu par de claves PGP, entonces uno puede crear el certificado de revocación más adelante. Puede ocurrir que perdamos la passphrase y no podamos utilizar la clave privada: en ese caso tendremos que revocar la clave, pero no podremos hacerlo por no disponer de la passphrase.

Dicho esto, vamos a generar el certificado de revocación. Abrimos Kleopatra, hacemos doble click en nuestra cuenta y pinchar en “Generar certificado de revocación”. No es posible retractarse de un certificado de revocación una vez que se haya publicado.

Funciona igual que un certificado cualquiera. Se importa o se publica y ya está.

70

En principio ya tenemos “cuenta y claves propias”, por lo que ya podemos verificar si el archivo descargado es el correcto. Los pasos para esta verificación son:

1. Descargar archivo deseado

Para el ejemplo: https://www.gpg4win.org/download.html y descargo “gpg4win-3.0.2.exe”

2. Descargar el archivo de firmas con extensión “sig” (puede estar comprimido en zip, rar…)

El archivo tiene el mismo nombre que el fichero a comprobar, la extensión puede ser cualquiera (sig, asc…): “gpg4win-3.0.2.exe.sig”. Si lo editamos podemos ver algo asi:

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1

…………

-----END PGP SIGNATURE-----

3. Conseguir la clave usada para la firma.

En este punto hay dos formas de conseguirlo: con el fichero sig o la web lo publica.

FICHERO sig Lo hallamos con el fichero sig. En Kleopatra pulsamos descifrar/verificar y seleccionamos el fichero sig.

71

Como no tenemos ningún certificado para verificar, sólo el nuestro, nos aparece el mensaje que nos indica las firmas detectadas (key o clave): nos dice que no puede comprobar la firma porque no disponemos de la clave pública. Y nos explica que podemos importarlo de un fichero o buscarlo en un servidor. Como no tenemos el fichero de certificado seleccionamos la primera key a buscar online. Y luego la segunda.

72

Seleccionamos la clave e importamos en ambos casos el certificado (clave pública = certificado).

Nada más importar nos aparece este mensaje. Aquí entra el proceso de verificación (anillo de confianza). Nos dice que para certificar usemos mejor un método “offline” para conocer a la persona del certificado importado: teléfono, carta…

Observar como ahora ya tenemos los dos archivos verificados, pero no certificados.

73

A veces la propia web publica su certificado y/o su fingerprint, por lo que podemos importar el certificado antes de su verificación. A modo de ejemplo vamos a importar el certificado de Qbittorrent ( https://www.qbittorrent.org/download.php ).

Si entramos a su web de descarga tenemos para descargar el instalador y su archivo de firma para verificar, y justo debajo el checksum del ejecutable de la descarga (ROJO). Desde Kleopatra podemos “Descifrar/Verificar” el archivo ejecutable con el archivo de firma descargado.

NOTA las extensiones son indiferentes, importa el contenido (recordar el formato contenido, identifican el tipo de certificado).

Pero si miráis bien encima está su Fingerprint junto con un enlace de su key (VERDE) (https://pgp.mit.edu/pks/lookup?op=get&search=0xA1ACCAE4520EC6F6 ), que nos lleva a un servidor de llaves GPG. Si hacemos click en este enlace se nos muestra su clave pública, es decir, su certificado.

74

Ahora copiamos su llave a un fichero sin formato (notepad). El contenido lo copiamos con el nombre de la key “5B7CC9A2.txt”:

-----BEGIN PGP PUBLIC KEY BLOCK-----

Version: SKS 1.1.6

Comment: Hostname: pgp.mit.edu

mQINBFcNIIwBEACpGHvHW9ku7rwCSc2Dv4gh3MO3HPoP7Ba4RiEKwa7SCbPzc0DLJypV4gNf

nrpiO7bWVh5v+otbZTkQeNXWbx6hDUa2e5GCCuJifIu3PxpmMcNJFvvFnk5QRf6dtz4Sm2x6

……………….

khsUWb20P8Eddrjzj2TgNW8VgJmSGr7/noUpl+hUHKEH7H7YZoyWwGbW4+eI7iUBqQU+kiLS

RpqnhRVrJD/tqT4GGxwAgdlTLo22BmS69bfF2nCnTstijaKWEwjxGfOa2hGa

=zFbD

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

Y ahora en Kleopatra pulsamos en importar. El mensaje de advertencia y observar la key importada con la de la web.

75

Ahora vamos al enlace del servidor ( https://pgp.mit.edu/ ) y buscamos por su fingerprint (D8F3DA77AAC6741053599C136E4A2D025B7CC9A2). Los buscadores no buscan todos igual. En este poner delante de la key o fingerprint “0X”.

Observar cómo ha salido la misma key. Si pinchamos en el enlace vemos su certificado público.

Copiamos y guardamos con el nombre de su fingerprint.

También podemos buscar por su Key, nos saldrá el mismo resultado.

76

También tenemos la posibilidad de buscar desde Kleopatra.

“Archivo>Búsqueda en el servidor” (probamos primero con “0X” delante y si no da resultado lo quitamos).

Ahora vamos a comparar los dos archivos. Nada más abrirlos se ve que son iguales, pero vamos a usar un programa para compararlos. Podemos usar Notepad++ 32bits y descargamos su plugin para comparar o descargar “Diffmerge”.

77

Vamos a importar el certificado desde uno de los archivos comparados. En Kleopatra pulsamos sobre Importar, seleccionamos un archivo y nos sale el mensaje de que se ha importado, pero no está certificado.

Ahora ya deberíamos de decidir si el archivo es válido o no. Podríamos guiarnos porque hay una conexión segura HTTPS, el hash coincide, la firma es válida, comprobamos la key y/o fingerprint en la web y… creemos que es segura. Si es válido podemos ejecutarlo. Ahora podemos pasar al punto “preparar la memoria USB”, pero explicaré un punto más sobre la firma digital.

Firmar una clave pública (Firmar la clave de otra persona) Ya tenemos la clave pública importada a nuestro "anillo de confianza". Antes de poder utilizar la clave pública de otra persona para cifrar los datos o enviarle correos electrónicos, tienes que firmar su clave pública con nuestra clave privada, de esta manera indicamos que confiamos en esta clave para su uso.

Para poder utilizar las claves públicas de otros usuarios debemos decirle a GPG que son válidas, cosa que podemos hacer de tres maneras:

1. Las claves públicas van acompañadas de un listado de certificados X509, el

primero de los cuales es del propietario de la clave Cada certificado está emitido

por un certificador, que es un usuario que ha considerado válida esa clave pública.

Yo tendré una base de datos de certificadores y a cada uno le asignaré un nivel de

confianza: Nula, Total o No lo conozco.

Cuando yo reciba una clave pública y a alguno de sus certificadores yo lo tenga catalogado

con un nivel de confianza Total, automáticamente GPG considerará esa clave válida. De lo

contrario, no será válida y no podré usarla, ya que no será de fiar, a no ser que yo mismo

confirme su validez.

Cualquier usuario puede certificar una clave, pero existen instituciones que se dedican

expresamente a la tarea de certificar claves públicas: son las llamadas Autoridades

Certificadoras(CA, Certificate Authority), como VeriSign, OpenCA, EnTrust, etc.

78

2. Confirmo yo su validez (yo la certifico firmando su clave pública con mi clave

privada) Si la clave pública recibida no viene firmada por ningún certificador de

confianza total, para usarla tendré que darle yo validez. Previamente tendré que

obtener el fingerprint por un medio alternativo y seguro (por ejemplo, por teléfono) y

comprobar si el fingerprint de dicha clave pública corresponde realmente al

remitente. Certificar una clave pública sin verificarla adecuadamente implica asumir

el riesgo de una posible suplantación. Si yo certifico con mi clave y exporto a un

servidor, mi nombre se añadirá al listado de certificadores que acompaña a la clave.

En ese caso, tengo la opción de reenviar la clave con mi firma a su dueño para que

disponga de ella.

I. Haz clic en certificados importados.

II. Haz clic en el certificado que desea firmar y haga clic en Certificar certificado … III. Selecciona el ID de usuario que deseas certificar y pulsa Siguiente. IV. Selecciona si deseas que esta certificación sea visible para los demás o sólo para ti mismo

y luego presiona el botón Certificar. Ahora has firmado su clave (has certificado el certificado) y está listo para comenzar el cifrado de datos o mensajes de correo electrónico que sólo se puede descifrar por el destinatario

Una vez firmada la clave debemos volver a subirla al servidor del cual la hemos sacado

para que nuestro certificado figure como avalista del que acabamos de firmar. Hay que

tener en cuenta que una vez enviemos nuestra clave al servidor de llaves, estas

automáticamente ser reenvían a todos los servidores de claves del mundo y que NO ES

POSIBLE borrarla de ellos, lo único que podremos hacer es revocarla, pero siempre

aparecerá en los servidores de llaves, aunque sea como revocada.

Y si no estoy seguro de que la clave sea suya, pero de todos modos quiero utilizarla para

cifrar un documento, lo que hare será certificar su clave para mí solo (así podré usarla)

pero de manera que mi certificado no se exporte a los servidores. Esto significa que

nuestro certificado es local y no se exportará. Confirmaremos que queremos certificar la

clave y guardaremos los cambios.

79

Observaciones Solo se debe firmar una clave cuando se esté totalmente seguro de que dicha clave es

auténtica. Esto solo puede suceder si se recibe la clave en mano. Por eso, normalmente el

procedimiento de firma se realiza presencialmente. Hay que asegurarnos de que quien nos da la clave es efectivamente quien dice ser (algo

imposible de verificar si nos descargamos su clave de un repositorio público o si nos la envía

por email.

Es importante entender y mantener la consistencia de las claves de confianza (y nunca

firmar si el canal por el que la hemos recibido no es fiable).

A diferencia de otros sistemas de criptografía de clave pública que confían en una autoridad

certificadora (CA), aquí todo se basa en un sistema descentralizado de fuentes de confianza

Firmar una clave pública es una forma de corroborar que esa clave corresponde a esa

persona, creando así anillos de confianza.

3. Usar la confianza para validar las claves En el punto anterior se introdujo un

procedimiento para validar las claves públicas de otros usuarios: la clave de otro

usuario se valida comprobando personalmente la huella digital de su clave, y

80

firmando su clave pública con nuestra clave privada. Comprobando personalmente

la huella digital podemos estar seguros de que la clave pertenece realmente al

supuesto usuario y, dado que hemos firmado la clave, podemos estar seguros de

que detectaremos cualquier manipulación o falsificación en un futuro.

Desafortunadamente este proceso se complica cuando debemos validar un gran

número de claves o cuando debemos comunicarnos con personas a las que no

conocemos personalmente.

En el modelo del anillo de confianza la responsabilidad de la validación de las claves públicas

recae en las personas en las que confiamos: la idea fundamental es que, si tú te fías

completamente de mi buen uso del PGP, las claves que yo valide quedan automáticamente

validadas para ti, sin necesidad de que establezcas comunicación directa con las otras

personas.

GnuPG trata este problema con un mecanismo conocido como anillo de confianza. En el modelo del anillo de confianza la responsabilidad de la validación de las claves públicas recae en las personas en las que confiamos. Por ejemplo, supongamos que

Javier ha firmado la clave de Arancha y que, Arancha ha firmado las claves de Jordi y de Ignacio.

Si Javier confía en Arancha lo suficiente como para validar las claves que ella firma, entonces Javier puede deducir que las claves de Jordi y de Ignacio son válidas sin llegar a comprobarlas personalmente. Javier se limitará a usar su copia validada de la clave pública de Arancha para comprobar que las firmas de Arancha sobre Jordi e Ignacio son auténticas. Por lo general, y asumiendo que Javier confíe plenamente en todos como para validar las claves que firmen, cualquier clave firmada por una clave válida también es considerada válida. El origen es la clave de Javier, que se asumirá axiomáticamente como válida.

81

Confianza en el propietario de una clave

En la práctica la confianza es algo subjetivo. Por ejemplo, la clave de Arancha es válida para Javier ya que ha sido firmada por ella, pero Javier puede desconfiar de otras claves que hayan sido validadas por la firma de Arancha. En este caso, Javier no aceptaría las claves de Jordi e Ignacio como válidas sólo porque hayan sido firmadas por Arancha.

El modelo del anillo de confianza prevee este caso mediante un indicador que asocia nuestro nivel de confianza en el propieario de la clave, a cada clave pública en nuestro anillo de claves. Existen cuatro niveles de confianza:

Unknown (Desconocido) No se sabe nada sobre el dueño de la clave firmante. Las claves en nuestro anillo de claves que no nos pertenezcan tendrán al principio este nivel de confianza.

None (Ninguno) Se sabe que el propietario firma otras claves de modo impropio. Marginal El propietario comprende las implicaciones de firmar una clave y valida

las claves de forma correcta antes de firmarlas. Full (Absoluto) El propietario comprende perfectamente las implicaciones de

firmar una clave y su firma sobre una clave es tan buena como la nuestra.

El nivel de confianza en una clave es algo que sólo nosotros podemos asignar a la clave, y

se considera información privada. El nivel de confianza no se exporta con la clave a ningún

servidor, de hecho, no se almacena en los anillos de claves sino en una base de datos

aparte.

Fíjate como lo que se establece de esta forma es el nivel de validez de un certificado,

pero el nivel de confianza lo tienes que poner tú de forma personal, como decía antes

eso es algo subjetivo y que no se exporta al servidor, solo uno sabe en quien debe confiar.

Usar la confianza para validar las claves automáticamente

El anillo de confianza permite usar un algoritmo más elaborado para validar una clave automáticamente. Anteriormente, una clave sólo se consideraba válida si la firmábamos nosotros personalmente. Ahora es posible usar un algoritmo más flexible: una clave K se considera válida si cumple dos condiciones:

82

1. si viene firmada por las suficientes claves válidas, lo que quiere decir: o que la hemos firmado nosotros personalmente, o o que ha sido firmada por una clave de plena confianza, o o que ha sido firmada por tres claves de confianza marginal;

2. Si el camino de claves firmadas que nos lleva desde K hasta nuestra propia clave es de cinco pasos o menos.

La longitud del camino, en número de claves con confianza marginal requeridas, y el

número de claves con confianza plena requeridas se pueden cambiar. Los números dados

arriba son los valores por defecto usados por GnuPG.

Esto es como la canción “los amigos de mis amigos son mis amigos”.

La figura 3-1 muestra un anillo de confianza cuyo origen está en Javier. El gráfico ilustra

quién ha firmado las claves de quién. La tabla muestra qué claves son consideradas válidas

por Javier en base a su confianza en otros miembros del anillo. Este ejemplo asume que se

necesitan dos claves de confianza marginal o una de confianza plena para validar otra

clave. La longitud máxima del camino es tres.

83

Al computar claves válidas en el ejemplo, las de Arancha e Ignacio siempre son

consideradas como totalmente válidas, ya que están directamente firmadas por Javier. La

validez de las otras claves depende de la confianza. En el primer caso la confianza en

Ignacio es plena, lo que implica que las claves de Jordi y Claudia se considerarán válidas.

En el segundo ejemplo la confianza en Arancha e Ignacio es marginal. Ya que son

necesarias dos claves de confianza marginal para dar validez total a una clave, la clave de

Jordi será considerada como totalmente válida, pero la clave de Claudia será considerada

sólo como marginalmente válida. En el caso en el que Jordi e Ignacio tuvieran confianza

marginal, la clave de Jordi sería marginalmente válida ya que la clave de Ignacio es

totalmente válida. Sin embargo, la clave de Claudia será considerada marginalmente

válida ya que sólo se puede usar una clave completamente válida para validar otras claves,

y la clave de Ignacio es la única clave válida que se ha usado para firmar la clave de

Claudia. Al añadir un nivel de confianza marginal a Arancha, la clave de Jordi se convierte

en totalmente válida y por tanto puede ser usada para validar totalmente la clave de

Claudia, y validar marginalmente la clave de Jimena. Por último, una confianza plena en

Arancha, Jordi y Jimena es todavía insuficiente para validar la clave de Gonzalo ya que el

camino máximo de certificación es tres, pero la longitud del camino desde Gonzalo hasta

Javier es cuatro.

El modelo del anillo de confianza es una aproximación flexible al problema del

intercambio seguro de claves públicas. Nos permite poner a punto GnuPG para que refleje

el modo en que lo usamos. Es posible llegar a insistir en múltiples caminos cortos desde

nuestra clave hasta otra clave K para cambiar el nivel de confianza. Por otra parte, puede

ser que caminos más largos nos satisfagan e incluso un sólo camino desde nuestra clave

hasta la otra clave K. El requerimiento de múltiples caminos cortos es una fuerte garantía

de que K pertenece a quien nosotros creemos. El precio, por supuesto, es la dificultad

añadida para validar claves, ya que debemos firmar personalmente más claves que si

aceptáramos menos y más largos caminos.

Publicar las claves El uso de un servidor de claves facilita este proceso. Después de firmar la clave de Javier, Arancha puede enviar la copia firmada por ella al servidor de claves. El servidor de claves añade la firma de Arancha a la copia ya existente de la clave pública de Javier. Las personas

84

que estén interesadas en actualizar su copia de la clave de Javier consultan al servidor por propia iniciativa para obtener la clave actualizada. Javier no necesita distribuir la clave y puede obtener las firmas en su clave requiriéndolas al servidor.

Nota.: GnuPG hace un uso excesivo de la palabra ``trust'', utilizándola en el sentido de

«confianza en el propietario y confianza en la clave». Esto puede llevar a confusión.

Algunas veces la confianza en un propietario viene referida como owner-trust para

distinquirla de la confianza en una clave. Sin embargo, a lo largo de este manual ``trust'' se

usa en el sentido de «confianza en el propietario de la clave», y ``validity'' en el sentido de

«confianza en que una clave pertenece a la persona asociada con el identificador de

clave».

Cifrar un texto

Con esto hemos terminado con el Kleopatra, y pasaremos a abrir el programa GPA.

Al abrirlo nos aparecerá una pantalla que dice “Portapapeles”, y si no

es así debemos ir a la opción “Windows” y seleccionar “Clipboard”. En

este portapapeles podremos pegar un texto ya redactado o escribir

uno desde allí.

85

Cuando hayamos terminado de escribir presionaremos el botón que dice “Encrypt”, luego

seleccionaremos la clave de la persona a la que le enviaremos el mensaje, y por arte de

magia (o de la tecnología) todo nuestro escrito se transforma en ilegibles e

incomprensibles letras y números sin significado aparente.

Basta con copiar y pegar el mensaje cifrado en un correo electrónico y enviárselo a

nuestro contacto. Si alguien interceptara el mensaje no podría saber de qué se trata.

Cuando nuestro conocido reciba el mensaje simplemente deberá pegar el texto en el

portapapeles del GPA, y presionar el botón que dice “Decrypt”. El programa detectará si

se posee la clave privada para desencriptar ese archivo. Si no se posee saldrá el siguiente

mensaje:

86

Si sí se posee, bastará con poner la contraseña para poder acceder al contenido del mensaje.

De esta forma, que sin duda es mucho más simple de lo que parece a primera vista, contaremos con un importante grado de privacidad en nuestras conversaciones vía internet.

Cifrar un archivo

Sin embargo, todavía no le hemos extraído todo el potencial a este maravilloso programa, pues también sirve para encriptar archivos: el modulo encargado es GpgEX.

Simplemente hay que hacer click derecho en el archivo que cifraremos, y vamos donde dice “Firmar y cifrar”. Si se prefiere cifrar sin firmar hay que ir a “Más opciones de GpgEX” y seleccionamos “Cifrar”.

87

Seleccionaremos a la persona a quien le enviaremos el archivo, luego presionamos “Firmar y cifrar” y listo, tenemos una copia encriptada para enviar de forma segura.

88

Para desencriptar el archivo simplemente hay que hacer click derecho en él y seleccionar “Descifrar y verificar”. Obviamente sólo podrá realizar esta operación el receptor del mensaje, quien tiene la clave privada y el creador del cifrado. Pulsamos sobre Salvar y nos aparece el archivo descifrado.

89

https://informantedimensional.wordpress.com/2016/09/

Hay otras opciones de correos electrónicos seguros. Analizaremos unos pocos para desmentir la creencia popular de que Gmail, Yahoo y Hotmail son lo único que existen.

Tutanota: Hablaremos primero de Tutanota, webmail que recomendamos totalmente. Cifrado de extremo a extremo desde el navegador, lo que significa que ni siquiera los dueños del servidor podrán acceder a nuestra correspondencia. Es seguro, de código abierto y está traducido al español. Ofrece una versión gratuita donde tendremos un 1GB de almacenamiento (que es bastante para esta clase de correos) y también versiones pagas para aumentar la cantidad. Los servidores están ubicados en Alemania.

Las desventajas de Tutanota pasan por no poder recuperar la contraseña si la perdemos (pues hasta eso está encriptado). Tampoco ofrece soporte IMAP, POP3 y SMTP porque arruinaría el cifrado de extremo a extremo, que por cierto solamente funciona fácilmente al enviar un correo a un dominio de Tutanota. Si enviásemos desde Tutanota un correo a un proveedor no seguro como Hotmail tendremos la opción de enviar el mensaje sin cifrar o cifrado. En este último caso deberemos brindarle una contraseña a nuestro contacto para que pueda desencriptarlo.

Utilizando además del cifrado que nos ofrece Tutanota el cifrado PGP podremos quedarnos tranquilos, pues contaremos con una seguridad muy alta. De más está decir que este servicio de correo electrónico no escanea nuestros mensajes ni nada parecido.

Sitio oficial: https://tutanota.com/

Hushmail: Otra opción es Hushmail, que sí ofrece cifrado PGP automáticamente, aunque en lo personal me gusta gestionar por mí mismo las claves que uso. La ventaja que tiene es que es compatible con otros servicios de correo cifrado que usen PGP. Es de código abierto y en el caso de que se envíe un correo a un servidor que no use PGP pasará lo mismo que con Tutanota y Protonmail (que enseguida veremos): enviará el correo sin cifrar o será necesario pasarle una contraseña a nuestro contacto para que lo desencripte.

La principal desventaja de Hushmail es que ofrece tan solo 25 MB de almacenamiento en su versión gratuita. Además, es necesario entrar a la cuenta cada 3 semanas o nos darán de baja; sin mencionar que sus servidores están en casa del Tío Sam: los Estados Unidos.

Sitio oficial: https://www.hushmail.com/

Protonmail: Protonmail es, seguramente, el más conocido de los correos electrónicos encriptados. Su funcionamiento en cuanto a la encriptación es similar al de Tutanota: se encripta en el navegador antes de pasar a internet. Sin embargo tiene algunas diferencias, como el hecho de tener dos contraseñas, una para entrar a la cuenta y otra para descifrar los correos. Una cuenta gratuita tiene una capacidad de 500 MB aunque también ofrece opciones de pago.

90

Los servidores están en Suiza, territorio neutral que no está bajo la jurisdicción legal de la Unión Europea.

Las desventajas de Protonmail son las mismas que las de los otros correos, aunque agregaríamos una extra y es el hecho de ser la “opción alternativa” más promocionada por los medios de comunicación.

Es extraño que los medios controlados por grandes empresas enemigas de la privacidad nos publiciten un servicio de este estilo. Es cierto que tampoco lo han anunciado con bombo y platillo, pero es verdad también que las noticias relacionadas con Protonmail salen en diarios y canales importantes. Como ejemplo dejamos un artículo del diario argentino “La Nación”, que recibe órdenes de la Embajada de Estados Unidos para publicar o no sus noticias: http://www.lanacion.com.ar/1880599-el-correo-ultra-privado-basado-en-suiza-esta-desde-hoy-disponible-para-todos-los-usuarios

Les aseguramos a nuestros lectores que el cifrado PGP es mucho más “ultra privado” que Protonmail, así que tampoco se confíen tanto porque lo diga La Nación.

Sitio oficial: https://protonmail.com/

Riseup: Llegamos al servicio que utilizaremos en Informante Dimensional para comunicarnos con nuestros lectores: Riseup. Se preguntarán qué tiene de especial, y comenzaremos diciendo que los servidores están en Estados Unidos y en el pasado fueron incautados por el FBI, ofrece poco espacio de almacenamiento (150 MB aunque es configurable), los correos enviados se borran luego de transcurrir 120 días, no ofrece ningún encriptado seguro más que el básico HTTPS, para registrarnos hay que enviar una solicitud y esperar que se apruebe, y encima de todo sus usuarios son homosexuales, anarquistas, feministas extremistas y en general gente vinculada a partidos de izquierda (sí, esxs muchachxs posmodernxs, lxs que escriben con la “X”).

¿Por qué demonios nosotros utilizamos un servicio de estas características? Porque tiene una ventaja que los otros no: tiene soporte IMAP, POP3 y SMTP, lo que nos permite utilizar nuestro método de encriptación y anonimato con Thunderbird y sus complementos.

No obstante, que usemos Riseup para este blog no significa que lo utilicemos para otras cosas…

Es importante añadir que al tener una cuenta en Riseup también podemos acceder a otros servicios como una VPN en Bitmask (no funciona en Windows), salas de chat, listas de correos, pastebins, y alguna que otra cosa más o menos útil.

Sitio oficial: https://riseup.net/

91

Correos Ocultos:

Los siguientes correos solo son accesibles desde la red anónima Tor. Ninguno de ellos es seguro aunque pueden ser útiles para registrarse en páginas de la “Deep Web”, enviar correos anónimos, y confirmar cuentas sin dar nuestro correo real, pues es fácil y sencillo registrarse en ellos.

Sigaint: Sigaint no depende del Proyecto Tor y dice estar en contra de las organizaciones policiales. Es el correo de la darknet Tor preferido por muchos delincuentes por este motivo, pues no colaboró con el FBI en operaciones como Onymous.

Cada tanto recibe algún ataque a sus servidores, pero lo como dijimos estos correos no son del todo seguros.

Ofrece una versión gratuita con 50 MB de almacenamiento, aunque puede incrementarse con versiones pagas. También permite enviar mails a correos “normales” como los que vimos hasta ahora y los ya conocidos.

Sigaint sería el mejor correo de la “Deep Web” de no ser porque los correos se envían cortados y faltando pedazos del mismo, haciendo ininteligible su lectura y comprensión. Una lástima.

Sitio: http://sigaintevyh2rzvw.onion/

Torbox: TorBox es una buena opción para enviar correos desde dentro de la Red Tor, porque no permite enviar ni recibir desde la web normal.

Junto con las carpetas enviados, recibidos, borradores y la papelera también aparece uno que es para la “Comunidad” (es decir todos los usuarios de TorBox). Allí cualquier usuario puede enviar correos electrónicos, y demás está decir que la mayor parte de las veces no son gente de bien…

Si usas TorBox evita los mensajes de la comunidad, y ni se te ocurra descargar ningún archivo de allí.

Sitio: http://torbox3uiot6wchz.onion/

Mail2Tor: es la última de nuestras opciones, y la más insegura. Cada tanto se cae y deja sin servicio a sus usuarios durante varias semanas. Corre el mito que cuando se cae es que la NSA está revisando el servidor…

Sin embargo Mail2Tor permite, al igual que Sigaint, enviar y recibir correos desde el internet normal sin complicaciones.

Sitio: http://mail2tor2zyjdctd.onion/