Asegúrate de estar recibiendo regularmente actualizaciones de las llaves

Si no refrescas regularmente tus llaves públicas implica que no recibas a tiempo la información sobre las llaves que han expirado o las revocaciones, lo cual es muy importante.

Si realizas un simple “gpg –refresh-keys”, revelas a cualquiera y al operador de servidor de llaves todo el conjunto de llaves que te interesa refrescar.

Para evitar esto puedes hacer actualizaciones regulares de llaves usando Parcimonie para refrescar tu llavero. Parcimonie es un daemon que refresca lentamente tu llavero desde un servidor de llaves a través de Tor. El propósito es hacer más difícil para un atacante correlacionar las actualizaciones de las llaves con tu llavero. Parcimonie es un paquete que se encuentra en Debian y Ubuntu.

También puedes usar un simple cronjob, como el siguiente para refrescar tus llaves, esto requiere que tu computadora este conectada a la red a la 1am, y potencialmente revela al mundo todas las llaves que estés actualizando en tu llavero.

No uses pgp.mit.edu

El servidor de llaves pgp.mit.edu ha estado sin funcionar adecuadamente por años, especialmente para cierto tipo de actualizaciones de llaves.

Depender específicamente de un único servidor de llaves te hace vulnerable a las posibles fallas de ese servidor de llaves, si el servidor de llaves se queda fuera de la piscina principal por cualquier razón, puede que nunca lleguen las actualizaciones al resto de la piscina. Utilizar la piscina es más robusto que usar un único servidor de llaves.

Considera mejor utilizar sks keyservers pool . En gpg.conf:

keyserver hkp://pool.sks-keyservers.net

La transición a una llave primaria más fuerte

Muchas personas siguen teniendo llaves DSA de 1024-bit. Debes considerar hacer la transición a un algoritmo de función hash más fuerte y de más bits. Ahora se sabe que este tamaño está dentro de lo que Well Funded Organizations pueden llegar a vulnerar. Este algoritmo de función hash ya está también envejeciendo.

Se recomienda hacer una llave 4096bit RSA con el algoritmo de función hash SHA512, realizando un aviso de transición que esté firmado por ambas llaves y hacerlo del conocimiento de todos. Este es un buen documento (EN) que detalla exactamente los pasos para que generes una llave así, asegurándose de obtener al algoritmo de función de digest adecuado.

Considera hacer que tu servidor de llaves por defecto use un servidor de llaves que tenga transporte HKPS

En lugar de un hkp sin cifrado por defecto puedes usar hkps. Esto hace menos evidente tu mapa de relaciones sociales de cualquiera que pueda estar fisgoneando el tráfico de tus datos por la red. Si realizas un gpg –refresh-keys en un servidor de llaves que es sólo hkp, entonces alguien monitoreando tu tráfico vera cada una de las llaves que tienes en tu llavero cuando pidas las actualizaciones de las llaves.

Nota: para poder utilizar el paquete hkps usuarios Debian/Ubuntu necesitarán instalar el paquete gnupg-curl

Puedes usar hkps.pool.sks-keyservers.net como tu servidor de llaves por defecto, este es un servidor piscina que contiene los servidores disponibles que usan hkps. Esta piscina contiene únicamente servidores que han sido certificados por sks-keyservers.net CA. Puede ser usado mediante los siguientes parámetros en gpg.conf:

~/.gnupg/gpg.conf:
 keyserver hkps://hkps.pool.sks-keyservers.net
 keyserver-options ca-cert-file=/path/to/CA/sks-keyservers.netCA.pem

Además, hkps:/keys.indymedia.org, hkps://keys.mayfirst.org and hkps://keys.riseup.net ofrecen esto (aunque es recomendable que mejor utilices la piscina).

Finalmente, si optas por designar la piscina como tu servidor de llaves, debes también agregar la siguiente opción:

~/.gnupg/gpg.conf:
 keyserver-options no-honor-keyserver-url

Cuando se genera una llave, los usuarios pueden designar un servidor de llaves específico desde el cual se pueden descargar sus llaves. La opción de arriba va a omitir esa especificación y utilizará la piscina, lo cual es útil porque (1) previene que alguien designe un método inseguro para que podamos bajar su llave y (2) si el servidor designado usa hkps, refrescar las llaves no funcionará porque el ca-cert no va a coincidir y por lo tanto las llaves no se van a refrescar.

Asigna una fecha de vencimiento si no tienes una

Las personas suelen preferir que sus llaves no expiren, pero tú sí debes querer que expiren. ¿Porqué? Porque siempre podrás extender su fecha de vencimiento, aún después de que hayan expirado. Este “vencimiento” es de hecho una válvula de seguridad o un “sistema de seguridad de hombre-muerto” que automáticamente se activará en algún momento. Si tienes acceso a los datos secretos de tus llaves lo puedes desactivar. El objetivo es implementar algo que deshabilite tu llave en caso de que pierdas acceso a ella y que no tengas certificado de revocación.

Asignar una fecha de vencimiento significa que necesitarás extender esa fecha en algún punto del futuro. Es una pequeña tarea que necesitarás recordar hacer.

Puedes pensar que es molesto y que no quieres tener que lidiar con ello, pero de hecho es bueno hacerlo regularmente. Indica a los usuarios que su llave sigue estando activa, y que el propietario de la llave la utiliza. Además, mucha gente no firmará una llave que no tenga fecha de vencimiento.

Para asignar una fecha de vencimiento a tu llave, simplemente necesitas ejecutar:

gpg --edit-key <fingerprint>

Ahora selecciona la sub-llave a la que quieres asignar una fecha de vencimiento (por ejemplo, la primera), o ninguna para asignar el vencimiento en tu llave primaria y luego ejecuta el comando “expire”

gpg> key 1
gpg> expire

Ahora asigna un valor razonable, (por ejemplo, 2 años) guarda la llave y salga:

Key is valid for? (0) 2y
gpg> save

Ahora debes enviar tu llave a los servidores de llaves para publicar este cambio:

gpg --send-key

Agenda un evento en el calendario para recordarte sobre la fecha de vencimiento de tu llave

No lo vas a recordar, así que lo mejor es pedir un recordatorio. Agenda una alerta un mes o más antes de la fecha para que puedas hacer el cambio con algo de tiempo. No quieres tener que apresurarte cuando tengas que manejar tus llaves.

Siempre puedes extender la fecha de expiración (aún cuando la llave ya expiro), así que no necesitas generar una nueva llave cada vez, sólo necesitas extender a fecha de vencimiento para después.

¿Tienes un certificado de revocación?

Si llegas a olvidar tu frase de contraseña o si tu llave privada queda comprometida o la pierdes, la única esperanza que te queda es esperar a que expire la llave (esto no es una buena solución), o activar tu certificado de revocación publicándolo a los servidores de llaves. Al hacer esto notificarás a otros que esta llave ha sido revocada.

Una llave revocada puede seguir utilizándose para verificar firmas anteriores o descifrar datos (si es que sigues teniendo acceso a la llave privada), pero no puede ser usada para cifrar nuevos mensajes para ti.

Para saber como generar y utilizar el certificado haz clic aquí.

Utiliza únicamente tu llave primaria para certificación (y tal vez también firmar). Ten una subllave por separado para cifrar.*

(extra) Ten una subllave por separado para firmar y mantén tu llave primaria completamente fuera de linea.

En este escenario, tu llave primaria es utilizada solo para certificación, lo que no sucede con frecuencia.

No confíes en el ID de la llave

Los IDs de llaves que son cortas, por ejemplo 0x2861A790, son de 32 bits. Hemos visto que son fácilmente falsificadas por otra llave con el mismo ID. Las OpenPGP IDs largas (por ejemplo 0xA1E6148633874A3D) son de 64 bits. Son fáciles para un ataque de colisión (trivially collidable) (EN), lo que es potencialmente un serio problema (EN).

Si quieres tratar con un identificador criptográficamente fuerte para una llave, debes usar la huella digital completa. Nunca debes confiar en la ID corta de la llave.

Probablemente deberías al menos tener:

keyid-format 0xlong y with-fingerprint en las opciones gpg.conf para incrementar el tamaño en el que se muestra el ID de la llave a 64-bit bajo uso regular y para mostrar siempre la huella digital.

Asegúrate de que tu llave es OpenPGPv4

De acuerdo con el RFC4880 Las llaves V3 están ya desaprobadas, contienen 3 vulnerabilidades. Primero, es relativamente fácil construir una llave V3 que tenga el mismo ID que otra llave porque el ID de la llave son simplemente los 64 bits del módulo público. Segundo porque la huella digital de una llave V3 hace las funciones de digest del material de la llave pero no de su extensión, por lo que hay una mayor oportunidad para colisiones de huellas digitales. Tercero, hay puntos débiles en el algoritmo MD5 que hace que los desarrolladores prefieran otros algoritmos. Ver abajo la discusión sobre ID’s de llaves y huellas digitales.

Para determinar si tu llave es una llave V3 puedes hacer lo siguiente:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets |grep version

Las llaves primarias deben ser DSA-2 o RSA de 4096 bits o más. (RSA de preferencia)

Para revisar si estás utilizando DSA-2 o RSA puedes hacer lo siguiente:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets | grep -A2 '^:public key packet:$' | grep algo

Si el algoritmo reportado es 1, quiere decir que estas usando RSA. Si es 17 entonces es DSA y necesitarás confirmar que las siguientes revisiones reporten un tamaño de llave mayor a 1024, de otro modo no estás utilizando DSA-2.

Si el algoritmo reportado es 19, estás usando ECDSA, si es 18 es ECC. En ese caso la siguiente comprobación del tamaño de bits de la llave no es un criterio apropiado para este tipo de llaves ya que los tamaños de llave se reducirán significativamente.

Para revisar el tamaño de bits de la llave primaria puedes hacer lo siguiente:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets | grep -A2 'public key' | grep 'pkey\[0\]:'

Las auto-firmas no deben usar MD5, puedes revisar esto con:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets | grep -A 2 signature | grep 'digest algo 1,'

Si ves que se genera algún resultado ‘digest algo 1’, entonces tienes algunas auto-firmas que están usando MD5, ya que el algoritmo digest 1 es MD5. Ve el OpenPGP RFC 4880, section 9.4 (EN) que tiene una tabla que mapea algoritmos hash a números.

Para corregir esto, necesitas regenerar una llave después de agregar lo siguiente en tu gpg.conf:

cert-digest-algo SHA512

Las auto-firmas no deben usar SHA1, puedes revisar esto con:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets | grep -A 2 signature | grep 'digest algo 2,'

Si obtienes cualquier resultado ‘digest algo 2’ quiere decir que tienes algunas auto-firmas que están utilizando SHA1, ya que el algoritmo digest 2 es SHA1.

Ve el OpenPGP RFC 4880, section 9.4 que tiene una tabla que mapea algoritmos hash a números.

Para corregir esto, necesitas regenerar una llave después de agregar lo siguiente en tu gpg.conf:

cert-digest-algo SHA512

Las preferencias del algoritmo digest deben incluir al menos un miembro de la familia SHA-2 con una prioridad más alta que las MD5 y SHA1 juntas

Puedes revisar esto con:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets | grep 'pref-hash-algos'

e inspeccionar los resultados. El orden de preferencia está basado en cuál número está primero de izquierda a derecha. Si ves un número ‘3’, ‘2’, o ‘1’ antes del ‘11’, ‘10’, ‘9’ u ‘8’, quiere decir que has especificado en tus preferencias preferir un algoritmo digest más débil.

Para corregir esto, necesitas regenerar una llave después de agregar lo siguiente en tu gpg.conf:

default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed

Las llaves primarias deben tener una fecha de vencimiento razonable (no más de 2 años en el futuro) Puedes revisar cuáles son las fechas de vencimiento de tus llaves haciendo lo siguiente:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets | grep 'key expires after'

Después inspecciona visualmente cuáles son los resultados para confirmarlo, la fecha en la lista será relativa a la creación de la llave lo cual puede ser difícil de interpretar.

Otro modo de revisar el vencimiento es simplemente:

gpg --list-keys <fingerprint>

Lo cual debe mostrar las fechas de creación y vencimiento de la llave primaria y de cada sub-llave asociada. Si no ves nada que mencione “expires” en este resultado, quiere decir entonces que no designaste una fecha de vencimiento apropiadamente.

Para corregirlo:

gpg --edit-key <fingerprint>
 gpg> expire
 ...
 gpg> save

Actualiza tu configuración GPG por defecto

Si estás utilizando GnuPG, asegúrate de tener las configuraciones optimas en gpg.conf, para esto puedes utilizar el siguiente script.

No incluyas un “comentario” en tu ID de usuario

Si crees que necesitas un lugar para un “comentario” en tu OpenPGP User ID piénsalo bien dos veces lee más sobre esto (EN). Probablemente no lo necesites ni lo quieras. Tener un espacio para un comentario dificulta a mucha gente saber qué es lo que están certificando.

Visto en riseup.net.

Leer más

Muchas personas no le dan la importancia requerida a un certificado de revocación hasta que es demasiado tarde, básicamente un certificado de revocación te permite cancelar tu llave pública en cualquier momento que pierda acceso a tu llave privada o esta se vea comprometida.

Si el certificado de revocación queda comprometido, la persona que lo comprometa podrá revocar la llave pública en circulación, sin embargo no podrá acceder a la llave secreta y tampoco podrá generar falsas firmas, descifrar mensajes o cualquier otra cosa que pueda hacer el usuario del par de llaves. Realmente lo único negativo de esto es que deshabilita el par de llaves.

Para generar el certificado de revocación solo debe ejecutar el siguiente comando:

gpg -a -o revoke.asc --gen-revoke <ID_Llave>

Para revocar la llave en caso de que haya sido comprometida solo debe ejecutar el siguiente comando:

gpg --import revoke.asc

Si se ejecuta “gpg –list-key” podrá ver que la llave ha sido cancelada, ahora solo falta subir de nuevo la llave a los servidores de llaves para que todos puedan ver que fue revocada, para esto solo hace falta ejecutar el siguiente comando:

gpg --keyserver pool.sks-keyservers.net --send-keys <ID_Llave>

Espero les sea útil, saludos…

Mas información:

Leer más

¿Qué es exactamente un grupo de firmas?

Un grupo de firmas es la forma de reunir a personas que utilizan sistemas criptográficos tipo PGP con el propósito de permitir a dichas personas el firmado mutuo. Los grupos de firmas sirven para extender la confianza por la red.

¿Qué es una llave firmada?

El firmado de llaves es el acto de firmar digitalmente una llave pública y un id asociado con dicha llave. La firma nos sirve para verificar que el id y la llave pública pertenecen realmente a la entidad que aparece en la firma que representa esa llave.

Cada uno puede firmar su propia llave pública y los id asociados a ella, en esencia, las firmas validan las llaves públicas. Es una forma de validar una llave pública y una identidad gracias a una tercera parte. Esta es la forma en la cuál las firmas crean un sistema de confianza.

¿Qué es un sistema de confianza?

Un sistema de confianza es el término utilizado para describir la relación de confianza entre un grupo de firmas. La firma es un enlace, o una ramificación, en el sistema de firmas de confianza. Estos enlaces son llamados vías de confianza (Trust Paths). Las vías de confianza pueden ser bidireccionales o de una única dirección. El ideal de un sistema de confianza es que cada uno esté conectado de forma bidireccional con los demás. De hecho, cada uno confía en que cada llave pertenece a su propietario legítimo.

¿Por qué debo firmar mi llave en grupo?

Existen tres razones principales para tener tantas firmas como se pueda.

La primera y la más importante, debes tener la mayor cantidad de firmas para expandir tus vías de confianza. Cuanto más profundo y estrechamente interconectado sea el sistema de confianza, más difícil será comprometerlo. Esto tiene un significado especial para las Comunidades de Software Libre, sean desarrolladores o usuarios. Los miembros de esta comunidad delegan sobre la tecnología criptográfica PGP la protección e integridad de sus paquetes de software, avisos de seguridad y anuncios. La fuerza y robustez del sistema de confianza es directamente proporcional a la fuerza de protección que PGP provee a la comunidad.

La segunda razón es que los grupos de firmas ayudan a otras personas a integrarse dentro de la cultura de la seguridad y les anima a adquirir conocimientos sobre PGP y otras tecnologías de criptografía. Para conseguir toda la fuerza de la criptografía la gente debe usarla y usarla correctamente.

Finalmente, los grupos de firmas ayudan a construir comunidades. Ayudan a juntar nuevos conocimientos y discusiones importantes sobre libertades civiles, cripto-derechos y regulación de internet. La discusión es importante por que no sólo es el primer paso, pero es el paso antes de la acción.

Organizando el Grupo

El Coordinador

No es difícil organizar y coordinar un grupo de firmas. Sin embargo a parte de las tareas normales de invitar a la gente, seleccionar un lugar y una fecha, el coordinador tiene otras tareas claves específicas a su responsabilidad. Eso, normalmente, incluye el suministro de una lista de llaves para cada participante y una determinación de la estructura del grupo.

¿Como debe de estar estructurado el grupo?

Hay dos formas de conducir un grupo de firmas de forma estructurada: de forma centralizada o de forma descentralizada. La mejor forma de determinar como hacerlo es dependiendo del número de participantes y la atmósfera del local donde se lleva a cabo la fiesta. Los requisitos básicos del grupo son que los participantes se verifiquen unos a otros las llaves y las identidades. Dados estos requisitos básicos el coordinador puede introducir algunas variaciones a estos dos tipos.

Un grupo centralizado es un asunto más organizado donde se trabaja bien con un grupo pequeño o medio de personas. Los participantes envían la información de sus llaves públicas al coordinador quién las anota en una lista. Cada participante, tal como van llegando al grupo, recibirá una copia de la lista, luego al estar reunidos todos, cada participante será llamado por el coordinador.

El participante comprobará que los datos son correctos respecto a la lista dada por el coordinador. Si el participante está seguro que su llave es la misma que la facilitada por el coordinador, entonces el participante leerá su huella digital ante los demás participantes para que estos puedan comprobar que sea la correcta. Si es correcta, los participantes deberán marcarlo en su hoja. Esto es necesario para evitar errores o falsedades en la hoja creada por el coordinador. Hasta que todos hayan comprobado la llave del participante, entonces el coordinador podrá llamar a otro participante y así sucesivamente.

Una vez que todas las llaves han sido verificadas, los participantes y el coordinador rogará a los participantes que formen una línea con sus identificaciones bien visibles. La persona en cabeza de la fila caminará hacia abajo de la fila comprobando los id. Si la id es correcta y se ha validado lo que se ha dicho sobre la llave al principio del encuentro, entonces se pondrá una segunda marca en su lista. Sólo la llave que tenga dos marcas será firmada.

Un grupo de firmas descentralizada es básicamente libre albedrío. Los participantes mezclan informalmente y buscarán a otros participantes cuyas llaves no hayan sido firmadas aún. Mientras duré el evento, cada uno verificará la llave y el id de cada persona, los grupos descentralizadas permiten incluir más fácilmente a gente nueva. En un grupo descentralizado, es importante que el coordinador anime a cada uno a que se asegure de que se ha reunido con todo el mundo, al menos para la validación de la llave. En este caso no es necesario hacer una lista de llaves y de huellas, aunque es una buena práctica.

Anunciando el Grupo

Si estas creando un sistema de confianza en tu comunidad, es buena idea intentar atraer a usuarios de PGP activos porque ellos son los principales interesados en mantener los grupos de firmas. La mejor forma de encontrar a la gente es hablando con aquellas personas que se encuentran en las listas de correo con firma PGP o buscando en el servidor de llaves aquellas cuentas de correo que puedan pertenecer a tu localidad. Por ejemplo, las cuentas de correo con el dominio de una universidad o una gran compañía de tu localidad.

Generando la lista de llaves

Si vas a utilizar un formato de fiesta estructurada se necesita que cada participante tenga una lista de llaves de todo el mundo, el coordinador tendrá que imprimir muchos listados o enviar la lista por correo a todos los participantes. Dichos listados suelen recopilarse en el siguiente formato:

Llave id – Propietario – Huella – Tamaño – Tipo – ¿llave válida? – ¿id válido?

Participando en el Grupo

El Participante

Esta es una lista de los pasos que debe seguir cada participante del grupo:

  • Generar un par de llaves.
  • Enviar la llave pública al servidor de llaves.
  • Enviar los detalles de tu llave pública al coordinador.
  • Ir al grupo de firmas.
  • Verificar los detalles de su llave.
  • Verificar los detalles de la llave de los demás.
  • Verificar la identidad para los id que se va a firmar.
  • Firmar todos aquellos id y llaves que se hayan verificado.
  • Enviar todas las llaves que se han firmado al servidor de llaves.

¿Qué hay que llevar a el Grupo?

  • Dos identificaciones con foto.
  • Detalles de las llaves de su propiedad: id, Tipo, Huella y Tamaño.
  • Un bolígrafo o lápiz.

¿Qué no hay que llevar?

  • Un ordenador.

¿Por qué no se debe llevar un ordenador?

No se deben llevar ordenadores a los grupos porque los programas pueden haber sido alterados de tal forma que comprometan la seguridad del PGP. Si alguien llevase un ordenador y todos utilizaran ese ordenador para firmar las llaves, nadie sabría si en dicho ordenador hay un grabador de teclas (KeyLogger) activo, o la versión del GPG ha sido modificada o incluso el Kernel de Linux, o que el teclado está especialmente modificado, cualquiera de estas cosas pueden capturar las llaves secretas de aquellos que utilicen el ordenador.

Firmando otras llaves

Obtener un copia de la llave

Normalmente se obtiene de los servidores de llaves, sin embargo si la llave no está disponible en el servidor puedes importarla utilizando gpg –import. Si trabajas con servidores de llaves, el siguiente comando te servirá para descargar la llave publica e incorporarla en tu anillo público.

gpg --keyserver <servidor> --recv-keys <ID_Llave>

Huella y verificado de llave

gpg --fingerprint <ID_Llave>

GPG imprimirá la huella del usuario <ID_Llave> Comprobamos la huella con la que tenemos en el listado del grupo de firmas.

Nota: No compruebes la huella de tu listado contra la huella que aparece en la web del servidor, ya que puede no haberte enviado la misma llave.

Firmar una llave

gpg --sign-key <Key_ID>

Si tienes múltiples llaves privadas, debes especificar cuál de todas tu llaves privadas es la que va a firmar la llave pública, este es el comando:

gpg --default-key <ID_a_usar> --sign-key <ID_Llave>

Si tienes problemas con llaves tipo RSA es por que probablemente estés utilizando una versión antigua de GnuPg. Versiones anteriores a la 1.0.3 no incluye compatibilidad con RSA.

Nota: Debes desinstalar la versión antigua, para comprobar que versión estas utilizando usa el siguiente comando:

gpg --version

Devolver o subir la llave firmada

Si estas trabajando con una entidad que no quiere que su llave esté en un servidor público, deberás devolver la llave pública firmada a su propietario por el método que él elija (normalmente cifrada). No debes enviar la llave pública firmada al servidor sin el permiso de su propietario. Publicar una llave reduce levemente la seguridad del par de llaves, por lo tanto está mal visto publicar una llave si su propietario no lo desea.

Pero normalmente trabajarás con servidores de llaves. Si es el caso, deberás enviar la llave pública firmada de vuelta al servidor con el siguiente comando:

gpg --keyserver <servidor> --send-key <ID_Llave>

Verás un mensaje de éxito como este:

gpg: success sending to <servidor> (status=200)

Felicidades, el firmado de llave pública ha terminado y tu firma ha sido incluida en su llave pública. Se han establecido las vías de confianza. Saludos…

Leer más