¿Por qué las llaves maestras de PGP solo tienen una subclave y vinculan la certificación con la firma de forma predeterminada?

Question

¿Por qué las llaves maestras de PGP solo tienen una subclave y vinculan la certificación con la firma de forma predeterminada?

#1 de Diti (25 votos)
#2 de Simon Richter (8 votos)
#3 de Tom Leek (6 votos)

32

Después de aprender más sobre las subclaves PGP y cómo dividir las funciones de (S) igning, (E) ncryption, (A) uthentication y (C) ertification, descubrí que en la mayoría de los casos (?) una clave maestra predeterminada tiene una subclave para separar el trabajo de cifrado:

pub  2048R/AAAAAAAA  usage: SC
sub  2048R/BBBBBBBB  usage: E

Aquí, AAAAAAAA es la clave maestra. S permite firmar contenido, C permite crear nuevas subclaves. (Una ventaja de esto es que puede darle a AAAAAAAA un tiempo de vencimiento más largo que BBBBBBBB y luego crear una nueva clave de cifrado con AAAAAAAA porque tiene un permiso de uso de C ).

Sin embargo, me parece que lo siguiente no sería menos seguro para los usuarios que trabajan en una sola máquina, pero que proporcionará más seguridad para los usuarios que deseen recibir correo cifrado desde, por ejemplo, trabajo y domicilio:

pub  2048R/AAAAAAAA  usage: C
sub  2048R/BBBBBBBB  usage: E
sub  2048R/CCCCCCCC  usage: S

Con esta configuración, la clave maestra AAAAAAAA no puede firmar / verificar o cifrar / descifrar, pero puede cobrar la confianza. Por lo tanto, puede darle a la clave maestra AAAAAAAA un tiempo de vencimiento más largo y usarla para agregar nuevas subclaves. Al exportar BBBBBBBB y CCCCCCCC a, digamos, una computadora de trabajo separada que se mueve mucho más y es menos segura, sin la clave maestra, si la computadora de trabajo está comprometida, subclaves se pueden revocar y agregar nuevas claves, sin perder ninguna reputación.

(Incluso puede ir tan lejos como para mantener la parte secreta de la clave de certificación maestra en un Súper Secreto Bunker, por supuesto).

Sé que configurar esto parecía imposible a través de una GUI (no parecen estar interesados en las subclaves, ni en ver ni editar, y mucho menos en controlar lo que la clave maestra puede y no puede hacer), pero mi pregunta es :

¿Existe alguna razón específica para que esto no se haga con las implementaciones de PGP existentes? La exportación de claves secretas a otras máquinas sin privilegios de certificación parece ser una gran ganancia de seguridad. (Si solo las GUI lo hicieran más fácil). Mi único pensamiento posible es que la importación de subclaves secretas con una clave secreta maestra lisiada tal vez no sea ampliamente compatible, como --export-secret-subkeys (en la página de manual gpg(1) ) sugiere:

--export-secret-keys

--export-secret-subkeys
       Same  as --export, but exports the secret keys instead.  This is
       normally not very useful and a security risk.  The  second  form
       of  the  command  has  the special property to render the secret
       part of the primary key useless; this  is  a  GNU  extension  to
       OpenPGP  and  other  implementations can not be expected to suc‐
       cessfully import such a key.  See the option  --simple-sk-check‐
       sum  if  you  want  to import such an exported key with an older
       OpenPGP implementation.

Editar : ¿Parece que Debian sigue esta misma práctica? enlace

public-key-infrastructure cryptography encryption pgp

pregunta Adam Prescott 10.03.2013 - 21:38

fuente

3 respuestas

Lea otras preguntas en las etiquetas public-key-infrastructure cryptography encryption pgp

¿Por qué no funciona el protocolo TLS sin los conjuntos de cifrado SSLv3? ¿Cómo hacen los hackers para que la víctima acceda a una URL de ataque XSS?

score 25 · Answer 1

Tengo dos puntos de vista sobre este tema: uno se basa en hechos históricos (y es un poco técnico), mientras que el otro es puramente mi propia opinión original.

En cualquier caso, parece más seguro, o por lo menos más conveniente , usar una clave separada para las firmas; de esa manera, solo usa su clave maestra para las certificaciones (y puede almacenarla), y no tiene que revisar todo el proceso de certificación (reuniones de IRL) si su clave está comprometida.

Hechos históricos

Después de revisar cuidadosamente el código fuente C de las versiones GnuPG estables (1.4 y 2.0), encontré la función responsable de configurar las capacidades predeterminadas de las claves públicas; el código (en el archivo g10/misc.c ) tiene este aspecto:

476 int
477 openpgp_pk_algo_usage ( int algo )
478 {
479     int use = 0;
480
481     /* They are hardwired in gpg 1.0. */
482     switch ( algo ) {
483       case PUBKEY_ALGO_RSA:
484           use = (PUBKEY_USAGE_CERT | PUBKEY_USAGE_SIG
485                  | PUBKEY_USAGE_ENC | PUBKEY_USAGE_AUTH);
486           break;
487       case PUBKEY_ALGO_RSA_E:
488           use = PUBKEY_USAGE_ENC;
489           break;
490       case PUBKEY_ALGO_RSA_S:
491           use = PUBKEY_USAGE_CERT | PUBKEY_USAGE_SIG;
492           break;
...
509       default:
510           break;
511     }
512     return use;
513 }

Encontré esta función porque primero observé cómo se realizó la generación de claves ( g10/keygen.c ); de hecho, es durante la generación de (sub) claves que GnuPG puede asignar los "roles" para las claves. Una vez que se crea una clave maestra, no puede cambiar sus habilidades.

El código fuente no dijo mucho (excepto que una clave RSA para firmar también viene con la capacidad de certificar ), pero ejecutando una búsqueda en la web para el comentario (línea 481 arriba) me llevó a enviar un mensaje publicado el 2005-08-03 en la lista de correo gnupg-users , diciendo :

GnuPG aún no distingue entre C y S. Por lo tanto, no hace Tiene mucho sentido tener una forma de seleccionar esto.

Por lo tanto, parece que esas configuraciones predeterminadas existen solo porque GnuPG se utiliza para no hacer distinciones entre las claves de firma y las claves de certificación.

Además, estas configuraciones predeterminadas pueden estar en su lugar debido a DSA , como Simon Richter señaló :

Durante bastante tiempo, gpg usó claves DSA por defecto, que solo se pueden usar para firmar, y luego tuvo que adjuntar una subclave elGamal (que solo se puede usar para el cifrado) para obtener una clave completamente funcional.

Para RSA, eso no es necesario, pero se mantuvo por alguna razón.

Los subtipos RSA "solo signo" o "solo cifrado" no son limitaciones técnicas en el algoritmo.

Datos originales

Hoy en día, creo que la única razón de esto (las capacidades de clave primaria predeterminadas establecidas en SC y no solo C ) es para ayudar a usuarios regulares a verificar las firmas .

Digamos que tienes esas dos llaves en tu llavero:

pub  4096R/00000001  1970-01-01       usage: C
uid                  Alice Owl
sub  4096R/AE687A0C  1970-01-01       usage: S
sub  4096R/F77A9AF1  1970-01-01       usage: E

pub  4096R/FFFFFFFE  1970-01-01       usage: CS
uid                  Bob Penguin
sub  4096R/00FF42CD  1970-01-01       usage: E

Alice Owl es una usuaria habitual de GnuPG, tiene confianza en OpenPGP y generó un par de llaves con la bandera --expert de GnuPG, por lo que pudo establecer sus propias habilidades clave. La clave principal tiene el indicador C por supuesto , pero < fuerte> ella firma documentos con una subclave.
Bob Penguin apenas sabe nada sobre criptografía. Lo único que quiere es un poco de privacidad / intimidad. Generó su clave como lo haría cualquier usuario regular (sin tocar ningún ajuste que no entienda).

Ahora, supongamos que usted, el lector, también es un principiante. Usted recibe documentos firmados de Alice y Bob. Conoce los conceptos básicos de gnupg , y en particular:

Los usuarios se identifican con sus claves principales:
- Así que sé que Alice es 00000001 , y también sé que Bob es FFFFFFFE .
Uno puede verificar los mensajes con las opciones --verify o --verify-files de GnuPG.

Ahora, verifiquemos los documentos que te enviaron.

$ gpg --verify from-bob.txt.asc
gpg: Signature made <date> using RSA key ID FFFFFFFE
gpg: Good signature from "Bob Penguin"

$ gpg --verify from-alice.txt.asc
gpg: Signature made <date> using RSA key ID AE687A0C
gpg: Good signature from "Alice Owl"

Espera, ¿qué? Pensé que la clave de Alice era 00000001 ?

De hecho, las firmas en los documentos no se hacen necesariamente con la clave maestra; se hacen con la clave que tiene la capacidad de firma ( S ). Es poco probable que un principiante se entere de eso.

Tal vez la explicación real no tenga nada que ver con esta suposición ("cuantos más principiantes utilicen las teclas SC , mejor será para otros principiantes"), pero esa es la única explicación a la que puedo acudir. sin molestar a los colaboradores de GnuPG.

score 8 · Answer 2

Diti tiene casi razón con respecto al contexto histórico, pero la verdadera razón histórica está en la parte que omitió.

Durante bastante tiempo, gpg usó claves DSA por defecto, que solo se pueden usar para firmar, y luego tuvo que adjuntar una subclave elGamal (que solo se puede usar para el cifrado) para obtener una clave completamente funcional.

Para RSA, eso no es necesario, pero se mantuvo por alguna razón.

Los subtipos RSA "solo signo" o "solo cifrado" no son limitaciones técnicas en el algoritmo.

score 6 · Answer 3

Cuando crea diferentes claves para firmar datos y para firmar certificados, las personas que "firman su clave" deben firmar su clave certification , no su clave de firma de datos; de lo contrario, la Web of Trust no pasará de su clave. Sin embargo, cuando firma un correo electrónico, lo hace con su clave de firma de datos, no su clave de certificación, y esa es su clave pública de firma de datos que se copia en el correo electrónico.

Por lo tanto, la separación de las claves de firma y certificación es factible, pero requiere que las personas involucradas y / o las implementaciones de software sean más cuidadosas con lo que firman y distribuyen. Puedo imaginar que podría encontrar problemas de usabilidad.