¿Cómo administrar las claves GPG en múltiples sistemas?

Soy nuevo en el uso de GnuPG y trato de entender la mejor manera de usarlo. ¿He revisado la explicación breve y fácil de entender de GPG / PGP para personas no técnicas? , pero la mayoría de las guías explican PGP con una perspectiva de máquina única.

Quiero usar GnuPG en tres dispositivos informáticos: una PC con Linux, una computadora portátil con Linux y un teléfono con Android.

El caso de uso fundamental es cifrar / descifrar el correo electrónico administrado por un servicio IMAP, por lo que todos los dispositivos necesitan la misma clave privada para el descifrado.

Me imagino que mis opciones son:

1. Simplemente copie todas mis claves en el llavero de cada dispositivo y confíe principalmente en la contraseña de clave privada para su protección.

2. Cree una clave maestra (con --gen-key) para representar mi identidad, luego cree una clave desechable separada (nuevamente con --gen-key) para cifrar / descifrar correos electrónicos y firmar con la clave maestra. El primero reside solo en mi PC, el último se distribuye a cada dispositivo. Mientras mis dispositivos móviles no se vean comprometidos, la clave desechable seguirá siendo válida.

Puedo ser demasiado paranoico y hacer que esto sea más complicado de lo que tiene que ser, pero humoréeme, por favor. Creo en no poner todos tus huevos en una canasta.

Se supone que la clave maestra es mi identidad digital. Se dedicará mucho esfuerzo a generar confianza en torno a esa identidad, y prefiero sufrir las molestias de mi paranoia que perder mi llave por descuido y tener que construir confianza en torno a una nueva llave maestra (tal vez esto no sea tan malo como yo) pensar, pero soy nuevo en esto) .

Es más probable que pierda mi computadora portátil o mi teléfono que mi PC. Si pérdida == compromiso, prefiero perder un par de claves desechables (que puedo revocar) que mi par de claves maestras. Siempre puedo otorgar la confianza de mi llave maestra a una nueva llave desechable.

Perdón por la muy larga pregunta. :-)

TL; DR

¿Es una contraseña suficiente protección para almacenar mi clave privada maestra en múltiples dispositivos?

¿Es factible mi plan para la opción # 2? ¿Me equivoqué o puedo mejorarlo?

Si la opción # 2 es una mala idea, ¿cuáles son las mejores prácticas cuando se usa GnuPG para un solo usuario en múltiples dispositivos?

Bueno, esto es un poco vergonzoso. Pasé horas en el transcurso de una semana tratando de resolver este problema, y ​​la respuesta parece estar en las subclaves, un tema que el manual de GnuPG y las preguntas frecuentes pasan por alto.

Mientras investigaba qué son las subclaves y por qué podrían usarse en lugar de --gen-key, me topé con esta gema: http://wiki.debian.org/subkeys .

El wiki de Debian explica cómo implementar la opción # 2 (ver OP) usando una clave maestra con subclaves, y explica además cómo eliminar la clave maestra de cualquier sistema después de almacenarla en un medio de respaldo (por ejemplo, una unidad flash). Las subclaves se pueden distribuir entre mis llaveros en cada dispositivo.

Pros:

1. No se basa principalmente en la contraseña para proteger la clave maestra,

2. Si algún sistema se ve comprometido, la clave maestra no está disponible de inmediato (a menos que tontamente deje mi unidad flash conectada o conecte dicha unidad a un sistema comprometido),

3. Esta es una práctica implementada por el equipo de desarrollo de Debian.

4. Utiliza la función de subclave de GnuPG. ¿Qué parece un poco más organizado que tener un montón de llaves sueltas en tu llavero, sí?

Porción relevante de Debian Subkey Wiki

1. Realice copias de seguridad de sus archivos GnuPG existentes ($ HOME / .gnupg). Mantenlos a salvo. Si algo sale mal durante los siguientes pasos, es posible que necesite esto para regresar a un buen lugar conocido. (nota: umask 077 dará como resultado permisos restrictivos para la copia de seguridad).

   • umask 077; tar -cf $HOME/gnupg-backup.tar -C $HOME .gnupg

2. Cree una nueva subclave para firmar.

   • Encuentra tu ID clave: gpg --list-keys yourname
   • gpg --edit-key YOURMASTERKEYID
   • En el gpg>aviso:addkey
   • Esto le pide su frase de contraseña, escríbala.
   • Elija el tipo de clave "RSA (solo signo)".
   • Sería aconsejable elegir un tamaño de clave de 4096 (o 2048) bits.
   • Elija una fecha de caducidad (puede rotar sus subclaves con más frecuencia que las claves maestras, o conservarlas durante toda la vida útil de la clave maestra, sin caducidad).
   • GnuPG creará (eventualmente) una clave, pero es posible que tenga que esperar a que obtenga suficiente entropía para hacerlo.
   • Guarda la clave: save

3. Puede repetir esto y crear una subclave "RSA (solo encriptar)", si lo desea.

4. Ahora copie $HOME/.gnupga sus unidades USB.

5. Aquí viene la parte difícil. Debe eliminar la clave maestra privada y, desafortunadamente, GnuPG no proporciona una forma conveniente de hacerlo. Necesitamos exportar la subclave, eliminar la clave privada e importar la subclave nuevamente.

   • Exportar las subclaves: gpg --export-secret-subkeys YOURMASTERKEYID >secret-subkeys(a elegir qué subclaves para exportar, especifique los identificadores de cada subclave siguió con un signo de exclamación: gpg --export-secret-subkeys SUBKEYID! [SUBKEYID! ..])
   • Retire su clave secreta maestra: gpg --delete-secret-key YOURMASTERKEYID
   • Importar las subclaves de nuevo: gpg --import secret-subkeys
   • Verifique que gpg -Kmuestre un en sec#lugar de solo secsu clave privada. Eso significa que la clave secreta no está realmente allí. (Vea también la presencia de un paquete OpenPGP ficticio en la salida de gpg --export-secret-key YOURMASTERKEYID | gpg --list-packets).
   • Opcionalmente, cambiar la contraseña proteger las subclaves: gpg --edit-key YOURMASTERKEYID passwd. (Tenga en cuenta que el material de la clave privada en la copia de seguridad, incluida la clave maestra privada, permanecerá protegido por la antigua frase de contraseña).

Su computadora ahora está lista para el uso normal.

Cuando necesite usar las claves maestras, monte la unidad USB cifrada y configure la variable de entorno GNUPGHOME:

export GNUPGHOME=/media/something
gpg -K

o use --home argumento de línea de comando:

gpg --home=/media/something -K

El último comando ahora debería enumerar su clave privada con secy no sec#.

Múltiples subclaves por máquina versus una sola subclave para todas las máquinas

Extracto de la subclave wiki de Debian. Originalmente señalado en los comentarios. [Parafraseando] y énfasis mío.

Uno podría tener la tentación de tener una subclave por máquina, de modo que solo necesite intercambiar la subclave potencialmente comprometida de esa máquina. En el caso de que se use una sola subclave en todas las máquinas, debe intercambiarse en todas las máquinas [cuando se sospecha que esa subclave está comprometida].

Pero esto solo funciona para firmar subclaves . Si tiene varias subclaves de cifrado, se dice que gpg solo cifra la subclave de cifrado más reciente y no todas las subclaves de cifrado conocidas y no revocadas.

Como alguien a quien tampoco le gustan los puntos únicos de falla (incluidas las claves maestras y especialmente las contraseñas), esta es la forma en que lo haría. Permite que los dispositivos funcionen a través de una red de confianza, al tiempo que permite una identidad descentralizada.

No sé si ya existe un sistema para esto, pero creo que probablemente podría ser scrobbled junto con un trabajo cron y algunas líneas de Bash.

En este sistema, tiene dos clases de pares de claves: pares de claves de dispositivo y pares de claves de marco temporal . Se genera un par de claves de dispositivo para el usuario en cada dispositivo, y permanece en ese dispositivo durante toda su vida útil. Un servidor central genera un par de claves de intervalo de tiempo a intervalos de rutina (mensual, diario, cada hora, depende de lo paranoico que desee ser). La clave pública se anuncia públicamente (el servidor tiene su propio par de claves de dispositivo para firmar), y la clave privada se distribuye encriptada con la clave pública de cada dispositivo que debe tener acceso a esta clave. (Esta distribución debe ser lo más privada posible, por ejemplo, tener dispositivos conectados directamente al servidor).

Para firmar mensajes, usaría la clave del dispositivo desde el dispositivo desde el que envía el mensaje. Si alguien quiere enviarle un mensaje, puede firmarlo con su clave de marco de tiempo público actual. (Deben tener un sistema automatizado para mantenerse al día con los anuncios). Luego puede leer su mensaje desde cualquier dispositivo.

Para leer mensajes cifrados más antiguos, los pares de claves de marcos temporales más antiguos se respaldan en cada dispositivo de acuerdo con una estrategia apropiada (incluido el servidor generador de pares de claves de marcos temporales, si así lo desea, nuevamente, dependiendo de su nivel de paranoia), donde tiene otro conjunto de pares de claves protegidas por contraseña que protegen las claves más antiguas (con la cantidad de contraseñas que tenga con el tiempo, ya que se siente cómodo recordando)

Si un dispositivo es robado o comprometido de alguna otra manera, puede usar otro de sus dispositivos de confianza pública para crear un mensaje firmado públicamente que verifique su identidad (por cualquier medio, por ejemplo, notando que estará en una reunión pública y / o tener un amigo de confianza que lo verifique en persona) y revocar la clave del dispositivo comprometida y cualquier clave de marco temporal a la que haya tenido acceso. Al revocar la clave, también elimina el dispositivo robado de la lista de dispositivos confiables del servidor (con una contraseña y la clave de su dispositivo confiable).

La política para confiar en las claves de dispositivo recién anunciadas debe seguir algo así como las políticas de confianza actuales: creo que una política adecuada es confiar en el servidor generador, un dispositivo móvil y un dispositivo grande y pesado, ya que es difícil robar / infiltrarse el teléfono de un usuario, una PC de escritorio y VPS en un atraco concertado antes de que el usuario se dé cuenta.

Si su servidor se ve comprometido, simplemente lo revoca mediante el mismo procedimiento descrito para cualquier otro dispositivo comprometido (posiblemente con una política más fuerte similar a la de agregar un nuevo dispositivo), y use un servidor seguro o completamente nuevo (con un nuevo dispositivo keypair) en el futuro.