Manual GPG

Gua de Gnu Privacy Guard
Gua de Gnu Privacy Guard Copyright 1999 por The Free Software Foundation Para cualquier duda, error, o sugerencia sobre este manual, dirjase al autor del mismo, Mike Ashley (<jashley@acm.org>). Para cualquier duda, correccin, o sugerencia sobre la versin en castellano, dirjase al traductor, Horacio (<homega@ciberia.es>). Tambin han contribuido a la creacin del manual Matthew Copeland, Joergen Grahn y David A. Wheeler. Se otorga permiso para copiar, distribuir y/o modicar este documento bajo los trminos de la Licencia de Documentacin Libre GNU, Versin 1.1 o cualquier otra versin posterior publicada por la Free Software Foundation; con las Secciones Invariantes siendo NONE, con los Textos de Portada siendo NONE, y con los Textos al respaldo de la pgina de ttulo siendo NONE. Una copia de la licencia es incluida en la seccin titulada "Licencia de Documentacin Libre GNU".
Tabla de contenidos
1. Primeros Pasos ................................................................................................................................................ 5 Generar un nuevo par de claves .................................................................................................................. 5 Generar un certicado de revocacin ................................................................................................ 7 Intercambiar claves ..................................................................................................................................... 8 Exportar una clave pblica ................................................................................................................ 8 Importar una clave pblica ................................................................................................................ 9 Cifrar y descifrar documentos................................................................................................................... 10 Firmar y vericar rmas............................................................................................................................ 11 Documentos con rmas ASCII........................................................................................................ 12 Firmas acompaantes ...................................................................................................................... 13 2. Conceptos....................................................................................................................................................... 14 Sistemas de cifrado simtrico ................................................................................................................... 14 Sistemas de cifrado asimtrico.................................................................................................................. 15 Sistemas de cifrado hbridos ..................................................................................................................... 16 Firmas digitales ......................................................................................................................................... 16 3. Gestin de Claves .......................................................................................................................................... 18 Gestionando nuestro par de claves ............................................................................................................ 18 Integridad de claves ......................................................................................................................... 19 Aadir y eliminar componentes a las claves ................................................................................... 20 Revocar componentes de una clave ................................................................................................. 21 Actualizar la fecha de caducidad de una clave ................................................................................ 23 Validar otras claves en nuestro anillo de claves pblicas.......................................................................... 23 Conanza en el propietario de una clave......................................................................................... 24 Usar la conanza para validar las claves ......................................................................................... 25 Distribucin de claves ............................................................................................................................... 27 4. Uso diario de GnuPG.................................................................................................................................... 29 Deniendo los requerimientos en seguridad ............................................................................................. 29 Seleccin del tamao de la clave ..................................................................................................... 29 Proteccin de la clave privada ......................................................................................................... 30 Seleccin de las fechas de caducidad y uso de subclaves ............................................................... 31 Gestin del anillo de conanza........................................................................................................ 32 Construccin del anillo de conanza ........................................................................................................ 32 Uso legal de GnuPG.................................................................................................................................. 33 5. Tpicos ........................................................................................................................................................... 35 Escribir interfaces de usuario .................................................................................................................... 35
Tabla de guras
3-1. Un anillo de conanza hipottico................................................................................................................ 26
Captulo 1. Primeros Pasos

GnuPG es una herramienta de seguridad en comunicaciones electrnicas. Este captulo es una gua rpida que cubre las funciones bsicas de GnuPG. Estas funciones incluyen generar un par de claves, intercambiar y comprobar la autenticidad de claves, cifrar y descifrar documentos, y rmar documentos y vericar rmas digitales. En este captulo no se detallan los conceptos de la criptografa de clave pblica, cifrado, y rmas digitales. Todo esto se cubrir en detalle en el Captulo 2. Tampoco se explica el uso avanzado the GnuPG. Esto se explica en los Captulos 3 y 4. GnuPG utiliza criptografa de clave pblica para que los usuarios puedan comunicarse de un modo seguro. En un sistema de claves pblicas cada usuario posee un par de claves, compuesto por una clave privada y una clave pblica. Cada usuario debe mantener su clave privada secreta; no debe ser revelada nunca. La clave pblica se puede entregar a cualquier persona con la que el usuario desee comunicarse. GnuPG implementa un esquema algo ms sosticado en el que un usuario tiene un par de claves primario, y ninguno o ms de un par de claves adicionales subordinadas1. Los pares de claves primarios y subordinados se encuentran agrupados para facilitar la gestin de claves, y el grupo puede ser considerado como un slo par de claves.
Generar un nuevo par de claves

La opcin de la lnea de rdenes -gen-key se usa para generar un nuevo par de claves primario.
javier:~$
gpg EgenEkey
gpg (GnuPG) 0.9.8; Copyright (C) 1999 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Please select what kind of key you want: (1) DSA and ElGamal (default) (2) DSA (sign only) (4) ElGamal (sign and encrypt) Your selection?
GnuPG es capaz de crear varios tipos diferentes de pares de claves, pero debe existir una clave primaria capaz de generar rmas. Por lo tanto, existen slo tres opciones. La opcin 1 genera dos pares de claves. Un par de claves DSA que es el par de claves primario que se usar slo para rmar. Un par de claves subordinadas ElGamal que se usar para el cifrado. La opcin 2 es parecida a la anterior, pero slo genera un par de claves DSA. La opcin 42 genera un nico par de claves ElGamal, que se usar tanto para rmar como para cifrar. En todos los casos existe la posibilidad de aadir subclaves adicionales para cifrar y rmar a posteriori. La mayora de los usuarios tienen suciente con la opcin por denicin.
1. 2. N. de T. En este y otros documentos se intercambia el trmino claves subordinadas con el de subclaves La opcin 3 es para generar un par de claves ElGamal que no puede ser usado para rmar.
Tambin hay que escoger un tamao para la clave. El tamao de una clave DSA debe estar entre los 512 y 1024 bits, y una clave ElGamal puede ser de cualquier tamao. Sin embargo, GnuPG requiere que las claves no sean menores de 768 bits. Por tanto, si se escogi la opcin 1 y tambin un tamao de claves mayor de 1024 bits, la clave ElGamal tendr el tamao deseado pero la DSA se limitar a 1024 bits.
DSA keypair will have 1024 bits. About to generate a new ELG-E keypair. minimum keysize is 768 bits default keysize is 1024 bits highest suggested keysize is 2048 bits What keysize do you want? (1024)
Cuanto ms larga sea la clave, ms segura ser contra ataques de fuerza bruta, pero por lo dems el tamao de la clave que se da por denicin es el adecuado, ya que sera ms barato circunvalar el cifrado que intentar entrar mediante ataques de fuerza. Adems, el cifrado y descifrado de mensajes se ralentizara a medida que se incrementara el tamao de la clave, y un tamao de clave ms grande podra afectar a la longitud de la rma digital. Una vez seleccionado, el tamao de una clave no se puede cambiar nunca. Para terminar, hay que escoger un fecha de caducidad. Si se escogi anteriormente la opcin 1, la fecha de caducidad se usar para sendos pares de claves, ElGamal y DSA.
Requested keysize is 1024 bits Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0) Key does not expire at all Is this correct (y/n)?
Para la mayora de los usuarios, una clave sin fecha de caducidad es la adecuada. Sin embargo, si se escoge con fecha de caducidad, el tiempo para sta debe ser escogido con cuidado, ya que, aunque es posible cambiar la fecha de caducidad posteriormente a la generacin de la clave, puede ser difcil comunicar un cambio a aquellos usuarios que posean esta clave pblica. Adems de los parmetros de la clave, el usuario debe dar un identicador. El identicador de usuario se usa para asociar la clave que se est creando con una usuario real.
You need a User-ID to identify your key; the software constructs the user id from Real Name, Comment and Email Address in this form: "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>" Real name: Email address: Comment:
Slo se crear un identicador de usuario al generar una clave, pero es posible crear identicadores adicionales si se desea usar la clave en dos o ms contextos, v.g., si se usa por una parte en la ocina como empleado
y por otra parte en casa como activista poltico. Hay que tener cuidado al crear un identicador de usuario, ya que despus ste no puede ser editado para introducir cambios. Aunque los caracteres especiales en iso-8859-1 son aceptados, GnuPG nos avisa si los usamos para rellenar estos campos3. Por ejemplo, si rellenramos los campos con los siguientes datos, Real name: Javier Email address: javier@mad.es Comment: Pramo S.L. Veramos lo siguiente: "Javier (P\xc3\xa1ramo S.L.) <javier@mad.es>". Por tanto es mejor evitar estos carcteres.
You are using the iso-8859-1 character set. You selected this USER-ID: "Javier (Paramo S.L.) <javier@casa.es>" Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?
An as, dependiendo de la versin que estemos usando, al listar las claves veremos una serie de carcteres extraos en lugar de vocales acentuadas, , , etc... GnuPG necesita una contrasea con el n de proteger las claves privadas, primarias y secundarias, que posea el usuario4.
You need a Passphrase to protect your private key. Enter passphrase:
No hay lmite para la longitud de una contrasea, y sta debe ser escogida con sumo cuidado. Desde un punto de vista de seguridad, la contrasea que desbloquea la clave privada es uno de los puntos ms dbiles en GnuPG (y en otros sistemas de cifrado de clave pblica), ya que es la nica proteccin que tiene el usuario si alguien se apoderara de su clave privada. Para una contrasea lo ideal es que no se usen palabras de un diccionario, y que se mezclen maysculas y minsculas, dgitos, y otros caracteres. Una buena contrasea es crucial para el uso seguro de GnuPG.
Repeat passphrase:
Como antes con los campos de identicacin del usuario, las contraseas aceptan caracteres especiales de iso-8859-1. No obstante, debemos tener en cuenta que si alguna vez tuviramos que usar nuestra contrasea desde una mquina con un teclado distinto al nuestro, nos veramos imposibilitados a menos que cambiramos la conguracin del sistema.
Generar un certicado de revocacin

3. 4. Se aceptan excepto en la direccin de correo electrnico. En el resto pueden dar problemas, as que se recomienda no usarlos. N. de T. Esta contrasea adopta la forma de una frase ("passphrase"), no de una sola palabra ("password").
Despus de haber generado un par de claves, el usuario debe, de forma inmediata, generar un certicado de revocacin para la clave pblica primaria, mediante el uso de la opcin -gen-revoke. Si el usuario olvidara la contrasea, o si su clave privada estuviera en peligro o extraviada, este certicado de revocacin podra ser hecho pblico para noticar a otros usuarios que la clave pblica no debe ser usada nunca ms. Una clave pblica revocada puede ser usada para vericar rmas 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 revocacin, siempre y cuando el usuario todava tenga acceso a la clave privada.
javier:~$
gpg Eoutput hSVUIIfUFs EgenErevoke HxhSVUIIfU

Javier (Paramo S.L.) <javier@casa.es>
sec
1024D/D58711B7 1999-09-24
El argumento milve debe ser un especicador de clave, ya sea ste el identicador de clave ("key ID") del par primario del usuario, o ya sea cualquier otra parte de un identicador de usuario (ser ID") que identique el par de claves del susodicho usuario. El certicado que se genere se encontrar en el chero revoke.asc. Si se omite la opcin -output, el resultado se pondr en la salida tpica. Dado que el certicado es corto, es posible que el usuario desee imprimir una copia en papel del certicado para guardarla en algn sitio seguro, como por ejemplo una caja fuerte de seguridad. El certicado no debera ser guardado en lugares a los que otros puedan tener acceso, ya que cualquiera podra hacer pblico el certicado de revocacin e inutilizar la correspondiente clave pblica.
Intercambiar claves
Para poder comunicarse con otros, el usuario debe intercambiar las claves pblicas. Para obtener una lista de las claves en el chero (anillo) de claves pblicas, se puede usar la opcin de la lnea de rdenes -list-keys.
javier:~$
gpg ElistEkeys
/home/javier/.gnupg/pubring.gpg --------------------pub 1024D/D58711B7 1999-09-24 Javier (Paramo S.L.) <javier@casa.es> sub 1024g/92F6C9E3 1999-09-24
Exportar una clave pblica

Para poder enviar una clave pblica a un interlocutor, antes hay que exportarla. Para ello se usar la opcin de la lnea de rdenes -export. Es necesario un argumento adicional para poder identicar la clave pblica que se va a exportar. Como en la opcin anterior -gen-revoke, hay que usar el identicador de clave o cualquier parte del identicador de usuario para identicar la clave que se desea exportar.
javier:~$
gpg Eoutput jviFgpg Eexport jvierdsFes
La clave se exporta en formato binario, y esto puede no ser conveniente cuando se enva la clave por correo electrnico o se publica en una pgina web. Por tanto, GnuPG ofrece una opcin de la lnea de rdenes -armor5 que fuerza que la salida de la orden sea generada en formato armadura-ASCII, parecido a los documentos codicados con uuencode. Por regla general, cualquier salida de una orden de GnuPG, v.g.. claves, documentos cifrados y rmas, pueden ir en formato armadura-ASCII aadiendo a la orden la opcin -armor.
javier:~$
gpg Ermor Eoutput jviFs Eexport jvierdsFes
---BEGIN PGP PUBLIC KEY BLOCK--Version: GnuPG v0.9.8 (GNU/Linux) Comment: For info see http://www.gnupg.org [...] ---END PGP PUBLIC KEY BLOCK---
Importar una clave pblica

Se puede aadir una clave pblica al anillo de claves pblicas mediante la opcin -import.
javier:~$
gpg Eimport rnhFgpg
gpg: key B63E132C: public key imported gpg: Total number processed: 1 gpg: imported: 1
javier:~$
gpg ElistEkeys
/home/javier/.gnupg/pubring.gpg --------------------pub 1024D/D58711B7 1999-09-24 Javier (Paramo S.L.) <javier@casa.es> sub 1024g/92F6C9E3 1999-09-24 pub sub 1024D/B63E132C 1999-09-24 Aranzazu (A.G.deZ.) <arancha@nav.es> 1024g/581A915F 1999-09-24
Una vez que la clave haya sido importada, es necesario validarla. GnuPG usa un potente y exible modelo de conanza que no requiere que el usuario d validez personalmente a cada clave que importe. Sin embargo, algunas claves pueden necesitar que el usuario les d validez de forma personal. Una clave se valida vericando la huella digital de la clave, y rmando dicha clave para certicar su validez. La huella digital se puede ver con la opcin de la lnea de rdenes -fingerprint, pero para certicar la clave hay que editarla.
javier:~$
gpg EeditEkey rnhdnvFes

trust: -/q
pub sub (1)
1024D/B63E132C created: 1999-09-24 expires: never 1024g/581A915F created: 1999-09-24 expires: never Aranzazu (A.G.deZ.) <arancha@nav.es>
Command>
fpr
5.
Muchas opciones de la lnea de rdenes que se usan con frecuencia, tambin se pueden congurar en un chero de conguracin.
pub
1024D/B63E132C 1999-09-24 Aranzazu (A.G.deZ.) <arancha@nav.es> Fingerprint: 4203 82E2 448C BD30 A36A 9644 0612 8A0F B63E 132C
La huella digital de una clave se verica con el propietario de la clave. Esto puede hacerse en persona o por telfono, o por medio de otras maneras, siempre y cuando el usuario pueda garantizar que la persona con la que se est comunicando sea el autntico propietario de la clave. Si la huella digital que se obtiene por medio del propietario es la misma que la que se obtiene de la clave, entonces se puede estar seguro de que se est en posesin de una copia correcta de la clave. Despus de comprobar la huella digital ya se puede rmar la clave con el n de validarla. Debido a que la vericacin es un punto dbil en criptografa de clave pblica, es aconsejable ser cuidadoso en extremo y siempre comprobar la huella digital de una clave con la que nos d el propietario antes de rmar dicha clave.
Command>
sign
pub
1024D/B63E132C created: 1999-09-24 expires: never trust: -/q Fingerprint: 4203 82E2 448C BD30 A36A 9644 0612 8A0F B63E 132C Aranzazu (A.G.deZ.) <arancha@nav.es>
Are you really sure that you want to sign this key with your key: "Javier (Paramo S.L.) <javier@casa.es>" Really sign? y You need a passphrase to unlock the secret key for user: "Javier (Paramo S.L.) <javier@casa.es>" 1024-bit DSA key, ID D58711B7, created 1999-09-24 Enter passphrase:
Una vez rmada, el usuario puede comprobar la clave para obtener un listado de las rmas que lleva y para ver la rma que le acaba de aadir. Cada identicador de usuario tendr una o ms autormas, as como una rma por cada usuario que haya validado la clave en cuestin.
Command>
hek
uid Aranzazu (A.G.deZ.) <arancha@nav.es> sig! B63E132C 1999-09-24 [self-signature] sig! D58711B7 1999-09-24 Javier (Paramo S.L.) <javier@casa.es> Command> quit
Cifrar y descifrar documentos

Cada clave pblica y privada tiene un papel especco en el cifrado y descifrado de documentos. Se puede pensar en una clave pblica como en una caja fuerte de seguridad. Cuando un remitente cifra un documento usando
10
una clave pblica, ese documento se pone en la caja fuerte, la caja se cierra, y el bloqueo de la combinacin de sta se gira varias veces. La parte correspondiente a la clave privada, esto es, el destinatario, es la combinacin que puede volver a abrir la caja y retirar el documento. Dicho de otro modo, slo la persona que posee la clave privada puede recuperar un documento cifrado usando la clave pblica asociada al cifrado. Con este modelo mental se ha mostrado el procedimiento de cifrar y descifrar documentos de un modo muy simple. Si el usuario quisiera cifrar un mensaje para Javier, lo hara usando la clave pblica de Javier, y l lo descifrara con su propia clave privada. Si Javier quisiera enviar un mensaje al usuario, lo hara con la clave pblica del usuario, y ste lo descifrara con su propia clave privada. Para cifrar un documento se usa la opcin -encrypt. El usuario debe tener las claves pblicas de los pretendidos destinatarios. El programa espera recibir como entrada el nombre del documento que se desea cifrar o, si ste se omite, una entrada tpica. El resultado cifrado se coloca en la salida tpica o donde se haya especicado mediante la opcin -output. El documento se comprime como medida adicional de seguridad, aparte de cifrarlo.
javier:~$
gpg Eoutput doFgpg Eenrypt Ereipient rnhdnvFes do
La opcin -recipient se usa una vez para cada destinatario, y lleva un argumento extra que especica la clave pblica con la que ser cifrado el documento. El documento cifrado slo puede ser descifrado por alguien con una clave privada que complemente uno de las claves pblicas de los destinatarios. El usuario, en este caso el remitente, no podr descifrar un documento cifrado por s mismo a menos que haya incluido su propia clave pblica en la lista de destinatarios. Para descifrar un mensaje se usa la opcin -decrypt. Para ello es necesario poseer la clave privada para la que el mensaje ha sido cifrado. De igual modo que en el proceso de cifrado, el documento a descifrar es la entrada, y el resultado descifrado la salida.
arancha%
gpg Eoutput do Ederypt doFgpg
You need a passphrase to unlock the secret key for user: "Aranzazu (A.G.deZ.) <arancha@nav.es>" 1024-bit ELG-E key, ID 581A915F, created 1999-09-24 (main key ID B63E132C) Enter passphrase:
Tambin es posible cifrar documentos sin usar criptografa de clave pblica. En su lugar, se puede usar slo una clave de cifrado simtrico para cifrar el documento. La clave que se usa para el cifrado simtrico deriva de la contrasea dada en el momento de cifrar el documento, y por razones de seguridad, no debe ser la misma contrasea que se est usando para proteger la clave privada. El cifrado simtrico es til para asegurar documentos cuando no sea necesario dar la contrasea a otros. Un documento puede ser cifrado con una clave simtrica usando la opcin -symmetric.
javier:~$
gpg Eoutput doFgpg Esymmetri do
Enter passphrase:
Firmar y vericar rmas

11
Una rma digital certica un documento y le aade una marca de tiempo. Si posteriormente el documento fuera modicado en cualquier modo, el intento de vericar la rma fallara. La utilidad de una rma digital es la misma que la de una rma escrita a mano, slo que la digital tiene una resistencia a la falsicacin. Por ejemplo, la distribucin del cdigo fuente de GnuPG viene rmada con el n de que los usuarios puedan vericar que no ha habido ninguna manipulacin o modicacin al cdigo fuente desde que fue archivado. Para la creacin y vericacin de rmas, se utiliza el par pblico y privado de claves en una operacin que es diferente a la de cifrado y descifrado. Se genera una rma con la clave privada del rmante. La rma se verica por medio de la clave pblica correspondiente. Por ejemplo, Javier hara uso de su propia clave privada para rmar digitalmente la entrega de su ltima ponencia a la Revista de Qumica Inorgnica. El editor asociado que la recibiera, usara la clave pblica de Javier para comprobar la rma, vericando de este modo que el envo proviene realmente de Javier, y que no ha sido modicado desde el momento en que Javier lo rm. Una consecuencia directa del uso de rmas digitales es la dicultad en negar que fue el propio usuario quien puso la rma digital, ya que ello implicara que su clave privada ha sido puesta en peligro. La opcin de lnea de rdenes -sign se usa para generar una rma digital. El documento que se desea rmar es la entrada, y la salida es el documento rmado.
javier:~$
gpg Eoutput doFsig Esign do
You need a passphrase to unlock the private key for user: "Javier (Paramo S.L.) <javier@casa.es>" 1024-bit DSA key, ID D58711B7, created 1999-09-24 Enter passphrase:
El documento se comprime antes de ser rmado, y la salida es en formato binario. Con un documento con rma digital el usuario puede llevar a cabo dos acciones: comprobar slo la rma o comprobar la rma y recuperar el documento original al mismo tiempo. Para comprobar la rma se usa la opcin -verify. Para vericar la rma y extraer el documento se usa la opcin -decrypt. El documento con la rma es la entrada, y el documento original recuperado es la salida.
arancha%
gpg Eoutput do Ederypt doFsig
gpg: Signature made Fri Sep 24 12:02:38 1999 CDT using DSA key ID D58711B7 gpg: Good signature from "Javier (Paramo S.L.) <javier@casa.es>"
Documentos con rmas ASCII

Las rmas digitales suelen usarse a menudo para rmar mensajes de correo electrnicos o en los grupos de noticias. En estas situaciones no se debe comprimir el documento al rmarlo, ya que para aquellos que no dispongan de un sistema para procesarlo sera ininteligible.
javier:~$
gpg Elersign do
You need a passphrase to unlock the secret key for user: "Javier (Paramo S.L.) <javier@casa.es>" 1024-bit DSA key, ID D58711B7, created 1999-09-24
12
---BEGIN PGP SIGNED MESSAGE--Hash: SHA1 [...] ---BEGIN PGP SIGNATURE--Version: GnuPG v0.9.8 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjdYCQoACgkQJ9S6ULt1dqz6IwCfQ7wP6i/i8HhbcOSKF4ELyQB1 oCoAoOuqpRqEzr4kOkQqHRLE/b8/Rw2k =y6kj ---END PGP SIGNATURE---
Firmas acompaantes
Un documento rmado tiene una utilidad limitada. Los otros usuarios deben recuperar la versin original del documento de la versin rmada, y aun en el caso de los documento rmados en ASCII, el documento rmado debe ser editado para poder recuperar el original. Por tanto, existe un tercer mtodo para rmar un documento, que genera una rma acompaante. Para generar una rma acompaante se usa la opcin -detach-sig.
javier:~$
gpg Eoutput doFsig EdethEsig do
You need a passphrase to unlock the secret key for user: "Javier (Paramo S.L.) <javier@casa.es>" 1024-bit DSA key, ID D58711B7, created 1999-09-24 Enter passphrase:
Tanto el documento como la rma acompaante son necesarios para poder vericar la rma. La opcin
-verify se usar para comprobar la rma.
arancha%
gpg Everify doFsig do
gpg: Signature made Fri Sep 24 12:38:46 1999 CEST using DSA key ID D58711B7 gpg: Good signature from "Javier (Paramo S.L.) <javier@casa.es>"
13
Captulo 2. Conceptos
GnuPG utiliza varios conceptos criptolgicos que incluyen sistemas de cifrado simtrico, sistemas de cifrado de clave pblica, y one-way hashing. Se puede usar GnuPG de un modo sencillo sin tener que entender estos conceptos en toda su amplitud, pero para el uso avanzado de GnuPG se hace necesario comprenderlos un poco. Este captulo es una introduccin a los conceptos bsicos de la criptografa usada en GnuPG. Para una lectura ms detallada sobre esta materia, existen otros libros. Un buen libro para alcanzar un conocimiento ms avanzado es Bruce Schneier (http://www.counterpane.com/schneier.html)s Applied Cryptography (http://www.counterpane.com/applied.html).
Sistemas de cifrado simtrico

Un sistema de cifrado simtrico es un tipo de cifrado que usa una misma clave para cifrar y para descifrar. Las dos partes que se comunican mediante el cifrado simtrico deben estar de acuerdo en la clave a usar de antemano. Una vez de acuerdo, el remitente cifra un mensaje usando la clave, lo enva al destinatario, y ste lo descifra usando la misma clave. Como ejemplo de sistema simtrico est Enigma; ste es un sistema que fue usado por Alemania, en el que las claves se distribuan a diario en forma de libros de cdigos. Cada da, un operador de radio, receptor o transmisor, consultaba su copia del libro de cdigos para encontrar la clave del da. Todo el trco enviado por ondas de radio durante aquel da era cifrado y descifrado usando las claves del da. Algunos ejemplos actuales de algoritmos simtricos son 3DES, Blowsh e IDEA. Un buen sistema de cifrado pone toda la seguridad en la clave y ninguna en el algoritmo. En otras palabras, no debera ser de ninguna ayuda para un atacante conocer el algoritmo que se est usando. Slo si el atacante obtuviera la clave, le servira conocer el algoritmo. Los algoritmos de cifrado usados en GnuPG tienen estas propiedades. Dado que toda la seguridad est en la clave, es importante que sea muy difcil adivinar el tipo de clave. Esto quiere decir que el abanico de claves posibles, o sea, el espacio de posibilidades de claves, debe ser amplio. Richard Feynman fue famoso en Los lamos por su habilidad para abrir cajas de seguridad. Para alimentar la leyenda que haba en torno a l, llevaba encima un juego de herramientas que incluan un estetoscopio. En realidad, utilizaba una gran variedad de trucos para reducir a un pequeo nmero la cantidad de combinaciones que deba probar, y a partir de ah simplemente probaba hasta que adivinaba la combinacin correcta. En otras palabras, reduca el tamao de posibilidades de claves. Inglaterra us mquinas para adivinar las claves durante la Segunda Guerra Mundial. El sistema alemn Enigma estaba provisto de un amplio abanico de claves, pero los ingleses disearon mquinas de cmputo especializado, los Bombes, para probar las claves de un modo mecnico hasta que la clave del da era encontrada. Esto signicaba que algunas veces encontraban la clave del da unas pocas horas despus de que sta fuera puesta en uso, pero tambin que otros das no podan encontrar la clave correcta. Los Bombes no fueron mquinas de cmputo general, sino los precursores de las computadoras (ordenadores) de hoy en da. Hoy por hoy, los ordenadores pueden adivinar claves con extrema rapidez, y sta es la razn por la cual el tamao de la clave es importante en los criptosistemas modernos. El algoritmo de cifrado DES usa una clave de 56 bits, lo que signica que hay 256 claves posibles. 256 son 72.057.594.037.927.936 claves. Esto representa un nmero muy alto de claves, pero una mquina computadora de uso general puede comprobar todo
14
el espacio posible de claves en cuestin de das. Un mquina especializada lo puede hacer en horas. Por otra parte, algoritmos de cifrado de diseo ms reciente como 3DES, Blowsh e IDEA usan todos claves de 128 bits, lo que signica que existen 2128 claves posibles. Esto representa muchas, muchsimas ms claves, y aun en el caso de que todas las mquinas del planeta estuvieran cooperando, todava tardaran ms tiempo que la misma edad del universo en encontrar la clave.
Sistemas de cifrado asimtrico

El principal problema con los sistemas de cifrado simtrico no est ligado a su seguridad, sino al intercambio de claves. Una vez que el remitente y el destinatario hayan intercambiado las claves pueden usarlas para comunicarse con seguridad, pero qu canal de comunicacin que sea seguro han usado para comunicar la clave entre ellos? Sera mucho ms fcil para un atacante intentar interceptar una clave que probar las posibles combinaciones del espacio de claves. Otro problema es el nmero de claves que se necesitan. Si tenemos un nmero n de personas que necesitan comunicarse entre ellos, entonces se necesitan n(n-1)/2 claves para cada pareja de personas que tengan que comunicarse de modo privado. Esto puede funcionar con un grupo reducido de personas, pero sera imposible llevarlo a cabo con grupos ms grandes. Los sistemas de cifrado de clave pblica se inventaron con el n de evitar por completo el problema del intercambio de claves. Un sistema de cifrado de clave pblica usa un par de claves para el envo de mensajes. Las dos claves pertenecen a la misma persona a la que se ha enviado el mensaje. Una clave es pblica y se puede entregar a cualquier persona. La otra clave es privada y el propietario debe guardarla para que nadie tenga acceso a ella. El remitente usa la clave pblica del destinatario para cifrar el mensaje, y una vez cifrado, slo la clave privada del destinatario podr descifrar este mensaje. Este protocolo resuelve el problema del intercambio de claves, que es inherente a los sistemas de cifrado simtricos. No hay necesidad de que el remitente y el destinatario tengan que ponerse de acuerdo en una clave. Todo lo que se requiere es que, antes de iniciar la comunicacin secreta, el remitente consiga una copia de la clave pblica del destinatario. Es ms, esa misma clave pblica puede ser usada por cualquiera que desee comunicarse con su propietario. Por tanto, se necesitarn slo n pares de claves por cada n personas que deseen comunicarse entre ellas. Los sistemas de cifrado de clave pblica se basan en funciones-trampa de un slo sentido. Una funcin de un slo sentido es aqulla cuya computacin es fcil, mientras que invertir la funcin es extremadamente difcil. Por ejemplo, es fcil multiplicar dos mmeros primos juntos para sacar uno compuesto, pero es difcil factorizar uno compuesto en sus componentes primos. Una funcin-trampa de un sentido es algo parecido, pero tiene una trampa. Esto quiere decir que si se conociera alguna pieza de la informacin, sera fcil computar el inverso. Por ejemplo, si tenemos un nmero compuesto por dos factores primarios y conocemos uno de los factores, es fcil computar el segundo. Dado un cifrado de clave pblica basado en factorizacin de nmeros primos, la clave pblica contiene un nmero compuesto de dos factores primos grandes, y el algoritmo de cifrado usa ese compuesto para cifrar el mensaje. El algoritmo para descifrar el mensaje requiere el conocimiento de los factores primos, para que el descifrado sea fcil si poseemos la clave privada que contiene uno de los factores, pero extremadamente difcil en caso contrario. Como con los sistemas de cifrado simtricos buenos, con un buen sistema de cifrado de clave pblica toda la seguridad descansa en la clave. Por lo tanto el tamao de la clave es una medida del seguridad del sistema, pero no se puede comparar el tamao del cifrado simtrico con el de un cifrado de clave pblica para medir
15
la seguridad. En un ataque de fuerza bruta sobre un cifrado simtrico con una clave de un tamao de 80 bits, el atacante debe enumerar hasta 281-1 claves para encontrar la clave correcta. En un ataque de fuerza bruta sobre un cifrado de clave pblica con un clave de un tamao de 512 bits, el atacante debe factorizar un nmero compuesto codicado en 512 bits (hasta 155 dgitos decimales). La cantidad de trabajo para el atacante ser diferente dependiendo del cifrado que est atacando. Mientras 128 bits es suciente para cifrados simtricos, dada la tecnologa de factorizacin de hoy en da, se recomienda el uso de claves pblicas de 1024 bits para la mayora de los casos.
Sistemas de cifrado hbridos

Los cifrados de clave pblica no son ninguna panacea. Muchos cifrados simtricos son ms fuertes desde un punto de vista de seguridad, y el cifrado y descifrado con clave pblica son ms caros que las correspondientes operaciones en sistemas simtricos. De todos modos, los cifrados de clave pblica son una herramienta efectiva para distribuir claves de cifrado simtrico, y de esta manera es como se usan en sistemas de cifrado hbridos. Un sistema de cifrado hbrido usa tanto un cifrado simtrico como uno asimtrico. Funciona mediante el uso de un cifrado de clave pblica para compartir una clave para el cifrado simtrico. El mensaje que se est enviando en el momento, se cifra usando la clave y envindolo al destinatario. Ya que compartir una clave simtrica no es seguro, la clave usada es diferente para cada sesin. Tanto PGP como GnuPG usan sistemas de cifrado hbridos. La clave de sesin es cifrada con la clave pblica, y el mensaje saliente es cifrado con la clave simtrica, todo combinado automticamente en un slo paquete. El destinatario usa su clave privada para descifrar la clave de sesin y acto seguido usa la clave de sesin para descifrar el mensaje. Un sistema de cifrado hbrido no es ms fuerte que el de cifrado asimtrico o el de cifrado simtrico de los que hace uso, cualquiera que de los dos que sea el ms dbil. En PGP y GnuPG el sistema de clave pblica es probablemente la parte ms dbil de la combinacin. Sin embargo, si un atacante pudiera descifrar un clave de sesin, slo sera til para poder leer un mensaje, el cifrado con esa clave de sesin. El atacante tendra que volver a empezar y descifrar otra clave de sesin para poder leer cualquier otro mensaje.
Firmas digitales
Una funcin hash es una funcin mltiple que asigna su entrada a un valor dentro de un grupo nito. Por regla general este grupo es un rango de nmeros naturales. Un modelo simple de funcin hash es f (x) = 0 para todo entero x. Una funcin hash ms interesante es f (x) = x mod 37, que asigna x al resto de la divisin x entre 37. Una rma digital en un documento es el resultado de aplicar una funcin hash al documento. Para que sea de utilidad, la funcin hash necesita satisfacer dos propiedades importantes. Primero, debera ser difcil encontrar dos documentos cuyo valor para una funcin hash sea el mismo. Segundo, dado un valor hash debera ser difcil de recuperar el documento que produjo es valor. Algunos sistemas de cifrado de clave pblica1 se pueden usar para rmar documentos. El rmante cifra el
1. El sistema de cifrado debe poseer la propiedad de que la clave pblica o la privada puedan ser usadas por el algoritmo de cifrado como clave pblica. RSA en un ejemplo de este tipo de algoritmo, mientras que ElGamal no.
16
documento con su clave privada. Cualquiera que quiera comprobar la rma y ver el documento, no tiene ms que usar la clave pblica del rmante para descifrarla. Este algoritmo satisface las dos propiedades necesarias para una buena funcin de hash, pero en la prctica este algoritmo es demasiado lento para que sea de utilidad. Como alternativa est el uso de funciones hash designadas para satisfacer estas dos importantes propiedades. SHA y MD5 son dos ejemplos de este tipo de algoritmos. Al usar uno de estos algoritmos, un documento se rma con una funcin hash, y el valor del hash es la rma. Otra persona puede comprobar la rma aplicando tambin una funcin hash a su copia del documento y comparando el valor hash resultante con el del documento original. Si concuerdan, es casi seguro que los documentos son idnticos. Claro que el problema est en usar una funcin hash para rmas digitales que no permita que un atacante interera en la comprobacin de la rma. Si el documento y la rma se enviaran descifrados, un atacante podra modicar el documento y generar una rma correspondiente sin que lo supiera el destinatario. Si slo se cifrara el documento, un atacante podra manipular la rma y hacer que la comprobacin de sta fallara. Una tercera opcin es usar un sistema de clave pblica hbrido para cifrar tanto la rma como el documento. El rmante usa su clave pblica, y cualquiera puede usar su clave pblica para comprobar la rma y el documento. Esto suena bien, pero en realidad no tiene sentido. Si este algoritmo hiciera el documento seguro tambin lo asegurara de manipulaciones, y no habra necesidad de rmarlo. El problema ms serio es que esto no protege de manipulaciones ni a la rma, ni al documento. Con este algoritmo, slo la clave de sesin del sistema de cifrado simtrico, es cifrada usando la clave privada del rmante. Cualquiera puede usar la clave pblica y recuperar la clave de sesin. Por lo tanto, es sencillo para un atacante recuperar la clave de sesin y usarla para cifrar documentos substitutos y rmas para enviarlas a terceros en nombre del remitente. Un algoritmo que funciona es aqul que hace uso de un algoritmo de clave pblica para cifrar slo la rma. En particular, el valor hash se cifra mediante el uso de la clave privada del rmante, de modo que cualquiera pueda comprobar la rma usando la clave pblica correspondiente. El documento rmado se puede enviar usando cualquier otro algoritmo de cifrado, o incluso ninguno si es un documento pblico. Si el documento se modica, la comprobacin de la rma fallar, pero esto es precisamente lo que la vericacin se supone que debe descubrir. El "Digital Signature Standard"(DSA) es un algoritmo de rmado de clave pblica que funciona como hemos descrito. DSA es el algoritmo principal de rmado que se usa en GnuPG.
17
Captulo 3. Gestin de Claves

En criptografa de clave pblica la manipulacin de claves es un punto aco a tener en cuenta. Un escucha podra manipular los cheros con las claves, o falsicar la clave pblica y hacerla pblica para que la usaran otros como si fuera la autntica. Por ejemplo, supongamos que Jordi quisiera monitorizar los mensajes que Javier enva a Arancha. Jordi podra montar lo que se conoce como un intermediario en el plan de ataque. En este ataque Jordi crea una nuevo par de claves pblica y privada, reemplazando la clave pblica de Arancha que posee Javier con la nueva clave pblica. A partir de ah intercepta los mensajes que Javier enva a Arancha. Cada mensaje que intercepte lo descifrar usando la nueva clave privada, lo volver a cifrar con la clave autntica de Arancha, y reenviar el mensaje cifrado a Arancha. As, todos los mensajes que Javier enve a Arancha pueden ser ledos por Jordi. Una buena gestin de claves es crucial para asegurarse, no slo de la integridad de nuestros cheros de claves, sino tambin de la integridad de los anillos de claves de otros. El punto central en la gestin de claves en GnuPG es la nocin que hay detrs de rmar las claves. Firmar las claves tiene dos propsitos principales: nos permite detectar una manipulacin en nuestros anillos de claves, y nos permite certicar que una clave realmente pertenece a la persona cuyo nombre aparece en el identicador de usuario de la clave. Las rmas de las claves tambin se usan en un esquema conocido como anillo de conanza para hacer extensiva la certicacin de claves que no han sido rmadas directamente por el usuario, sino que han sido rmadas por otros en los que l confa. Un usuario responsable que lleve a cabo una buena gestin de claves puede contrarrestar los efectos prcticos de la manipulacin de claves con GnuPG.
Gestionando nuestro par de claves

Un par de claves se compone de una clave pblica y otra privada. Una clave pblica se compone de la parte pblica de la clave de rmado maestra, las partes pblicas de las subclaves de rmado y cifrado, y de un juego de identicadores de usuario que se usa para asociar la clave pblica con una persona real. Cada una de estas partes contiene datos sobre s misma. Para una clave estos datos constan de su propio identicador, fecha de creacin, fecha de caducidad, etc... Para un identicador de usuario, estos datos constan del nombre de la persona a la que identica, un comentario opcional, y una direccin de correo electrnico. La estructura de la claves privada es parecida, con la diferencia de que slo contiene las partes privadas de las claves, y que no tiene la informacin del identicador de usuario. La opcin de la lnea de rdenes -edit-key se puede usar para ver un par de claves. Por ejemplo,
jordi %
gpg EeditEkey jordidtFes

never trust: -/u never 2002-09-25 2002-09-25
Secret key is available. pub sub sub sub (1) (2) 1024D/1208DD4F created: 1999-09-24 expires: 1024g/B9688D9E created: 1999-09-24 expires: 2016G/4D88ACC4 created: 1999-09-26 expires: 960D/412EAF0C created: 1999-09-26 expires: Jordi (Castell S.L.) <jordi@cat.es> Jordi (oficina) <jordi@castell.com>
18
Command>
La clave pblica se muestra junto con una indicacin sobre si la clave privada se encuentra disponible o no. La informacin sobre cada componente de la clave pblica se da en una lista. La primera columna indica el tipo de la clave. La palabra clave pub identica a la clave pblica maestra de rmado, y la palabra clave sub identica a una clave pblica subordinada a la anterior. La segunda columna informa sobre el tamao en "bits"de la clave, el tipo, y el identicador. El tipo es D para una clave DSA, g para una clave ElGamal que slo se pueda usar para cifrar, y G para una clave ElGamal que se pueda usar tanto para cifrar como para rmar. La fecha de creacin y la fecha de caducidad se muestran en las columnas tres y cuatro. Los identicadores de usuario aparecen en una lista a continuacin de las claves. Se puede obtener ms informacin sobre la clave mediante rdenes interactivas. La orden toggle sirve para conmutar entre los componentes pblico y privado de un par de claves, siempre y cuando ambos componentes estn presentes.
Command>
toggle
never never 2002-09-25 2002-09-25
sec sbb sbb sbb (1) (2)
1024D/1208DD4F created: 1999-09-24 expires: 1024g/B9688D9E created: 1999-09-24 expires: 960D/412EAF0C created: 1999-09-26 expires: 2016G/4D88ACC4 created: 1999-09-26 expires: Jordi (Castell S.L.) <jordi@cat.es> Jordi (oficina) <jordi@castell.com>
Esta informacin es parecida a la del componente para la clave pblica. La palabra clave sec identica a la clave privada maestra de rmado, y la palabra clave sbb identica las claves subordinadas privadas. Los identicadores de usuario de la clave pblica tambin aparecen en este caso.
Integridad de claves
Al distribuir nuestra clave pblica, estamos distribuyendo los componentes pblicos de nuestras claves maestra y subordinada, as como los identicadores de usuario. Sin embargo, por s sola, la distribucin de este material constituye un riesgo para la seguridad ya que sera posible que un atacante manipulara la clave. Se puede modicar una clave pblica aadiendo o substituyendo claves, o aadiendo o cambiando los identicadores de usuario. Al manipular un identicador de usuario, el atacante podra cambiar la direccin de correo del identicador de usuario y redireccionar as el correo a su propia direccin. Al cambiar una de las claves de cifrado el atacante tambin podra descifrar los mensajes que le llegaran redireccionados. El uso de las rmas digitales es una solucin a este problema. Cuando unos datos son rmados por una clave privada, la clave pblica correspondiente queda ligada a los datos rmados. En otras palabras, slo la clave pblica correspondiente puede vericar la rma y asegurar que los datos no han sido modicados. Una clave pblica se puede proteger de la manipulacin usando su correspondiente clave privada maestra, y rmando con sta los componentes de la clave pblica y los identicadores de usuario, ligando de este modo los componentes a la clave pblica maestra. La accin de rmar los componentes de la clave pblica con la correspondiente clave privada maestra se conoce como autormar, y una clave pblica que contenga identicadores de usuario autormados ligados a ella se llama certicado.
19
Como ejemplo, si Jordi tuviera dos identicadores de usuario y tres subclaves, las rmas en los identicadores de usuario se podran comprobar con la orden check desde el men de edicin de la clave.
jordi %
gpg EeditEkey jordi

Secret key is available. pub sub sub sub (1) (2) 1024D/1208DD4F created: 1999-09-24 expires: 1024g/B9688D9E created: 1999-09-24 expires: 960D/412EAF0C created: 1999-09-26 expires: 2016G/4D88ACC4 created: 1999-09-26 expires: Jordi (Castell S.L.) <jordi@cat.es> Jordi (oficina) <jordi@castell.com>
Command>
hek
uid Jordi (Castell S.L.) <jordi@cat.es> sig! 1208DD4F 1999-09-24 [self-signature] uid Jordi (oficina) <jordi@castell.com> sig! 1208DD4F 1999-09-26 [self-signature]
Como era de esperar, la clave rmante para cada rma es la clave de rmado maestra con el identicador de clave 0x26B6AAE1. La autorma en las subclaves se encuentra presente en la clave pblica, pero en la interfaz de GnuPG no aparece.
Aadir y eliminar componentes a las claves

Tanto las nuevas subclaves como los nuevos identicadores de usuario, pueden ser aadidos a nuestro par de claves una vez que ste ya haya sido creado. Un identicador de usuario se aade mediante la orden adduid. A continuacin se nos pedir que introduzcamos un nombre real, una direccin de correo electrnico, y un comentario, del mismo modo que cuando generamos el par de claves inicial. Una subclave se aade usando la orden addkey. La interfaz es parecida a la usada cuando generamos un par de claves nuevo. La subclave puede ser una clave para rmado DSA y una clave slo para cifrado ElGamal, o una clave para rmado y cifrado ElGamal. Cuando se genera una subclave o un identicador de usuario, stos son autormados con nuestra clave de rmado maestra, por lo que se nos requerir que introduzcamos la contrasea. Los identicadores de usuario adicionales son tiles si necesitamos mltiples identidades. Por ejemplo, puede darse el caso de que utilicemos una identidad para el trabajo y otra para nuestras actividades polticas. Los colegas de trabajo nos conocern por nuestro identicador de usuario del trabajo. Los correligionarios polticos nos conocern por nuestra identidad de usuario poltica. Como es posible que estos grupos de personas no coincidan, cada grupo no se ar del identicador que no corresponda. Por lo tanto, ambos identicadores de usuario son necesarios. Las subclaves adicionales son tambin muy tiles. Los identicadores de usuario asociados con nuestra clave pblica maestra son validados por las personas con quien nos comunicamos y por tanto, cambiar la clave maestra requiere recerticacin. Pero esto puede resultar difcil y una prdida de tiempo si nos comunicamos con muchas personas. Por otra parte, es bueno cambiar las subclaves de cifrado peridicamente. Si una clave es descubierta, todos los datos cifrados con esa clave sern vulnerables. De todos modos, al cambiar las claves slo los datos cifrados con la clave descubierta sern revelados.
20
Tambin es posible eliminar las subclaves y los identicadores de usuario. Para eliminar una subclave o un identicador de usuario es preciso seleccionarlo primero con las rdenes key o uid respectivamente. Estas rdenes actan como conmutadores. Por ejemplo, la orden key 2 selecciona la segunda subclave, e invocando key 2 de nuevo, desactiva la seleccin. Si no se da ningn otro argumento extra, todas las subclaves o identicadores de usuario son deseleccionados. Una vez que los identicadores de usuario que se van a eliminar son seleccionados, la orden deluid elimina los identicadores de usuario de la clave. De igual forma, la orden delkey elimina todas las subclaves previamente seleccionadas de nuestras claves pblica y privada. En la gestin local de anillos de claves, el eliminar componentes innecesarios de una clave es una buena prctica para aliviar los anillos de claves pblicas de otros. Sin embargo, eliminar identicadores de usuarios y subclaves de nuestra propia clave no es siempre conveniente, ya que puede complicar la distribucin de la clave. Por denicin, cuando un usuario importa nuestra clave pblica actualizada sta se fusiona con la copia de la clave pblica vieja en su anillo de claves, siempre que la vieja est all a priori. Los componentes de ambas claves se combinan con la fusin, y el resultado de sta es que se aade cualquier nuevo componente, pero tambin que se restaura cualquier componente eliminado. Para actualizar de manera correcta la clave es necesario que el usuario elimine primero la versin antigua de nuestra clave, y despus que importe la versin nueva. Esto signica una carga extra para la gente con la que nos comunicamos. Es ms, si enviramos nuestra clave a un servidor de claves la fusin ocurrira a nuestro pesar, y cualquiera que se bajara nuestra clave del servidor no vera nunca nuestra clave con los componentes eliminados. En consecuencia, para actualizar nuestra propia clave es mejor revocar los componentes de la clave que eliminarlos.
Revocar componentes de una clave

Para revocar una subclave antes tenemos que seleccionarla. Una vez seleccionada, puede ser revocada con la orden revkey. La clave se revoca aadindole una autorma de revocacin. Al contrario que la opcin de la lnea de rdenes -gen-revoke, el efecto de revocacin de una subclave es inmediato.
Command>
key 4D88ACC4
pub sub sub* sub (1) (2)
1024D/1208DD4F created: 1999-09-24 expires: 1024g/B9688D9E created: 1999-09-24 expires: 2016G/4D88ACC4 created: 1999-09-26 expires: 960D/412EAF0C created: 1999-09-26 expires: Jordi (Castell S.L.) <jordi@cat.es> Jordi (oficina) <jordi@castell.com>
Command>
revkey
Do you really want to revoke this key? y You need a passphrase to unlock the secret key for user: "Jordi (Castell S.L.) <jordi@cat.es>" 1024-bit DSA key, ID 1208DD4F, created 1999-09-24 pub sub sub rev! sub 1024D/1208DD4F 1024g/B9688D9E 2016G/4D88ACC4 subkey has been 960D/412EAF0C created: created: created: revoked: created: 1999-09-24 1999-09-24 1999-09-26 1999-09-26 1999-09-26 expires: never trust: -/u expires: never expires: 2002-09-25 expires: 2002-09-25
21
(1) (2)
Jordi (Castell S.L.) <jordi@cat.es> Jordi (oficina) <jordi@castell.com>
La revocacin de un identicador de usuario funciona de modo diferente. Generalmente, un identicador de usuario recolecta rmas que atestigen que el identicador de usuario describe a la persona que sea la autntica propietaria de la clave asociada. En teora un identicador de usuario describe a una persona para siempre, ya que la identidad de esa persona no cambiar nunca. En la prctica los elementos del identicador de usuario, como la direccin de correo electrnico y el comentario, pueden cambiar con el tiempo, invalidando as el identicador de usuario. Las especicaciones de OpenPGP no preveen la revocacin del identicador de usuario, pero un identicador de usuario puede ser revocado de modo efectivo, revocando la autorma en el identicador de usuario. Por razones de seguridad descritas anteriormente, los corresponsales no conarn en un identicador de usuario con una autorma no vlida. Una rma puede ser revocada mediante la orden revsig. Como es posible que hayamos rmado cualquier cantidad de identicadores de usuario, la interfaz nos pedir que decidamos si queremos o no revocar cada una de las rmas.
Command>
revsig
Command> revsig You have signed these user IDs: Jordi (Castell S.L.) <jordi@cat.es> signed by 1208DD4F at 1999-09-24 Jordi (oficina) <jordi@castell.com> signed by 1208DD4F at 1999-09-26 user ID: "Jordi (Castell S.L.) <jordi@cat.es>" signed with your key 1208DD4F at 1999-09-24 Create a revocation certificate for this signature? (y/N)n user ID: "Jordi (oficina) <jordi@castell.com>" signed with your key 1208DD4F at 1999-09-26 Create a revocation certificate for this signature? (y/N)y You are about to revoke these signatures: Jordi (oficina) <jordi@castell.com> signed by 1208DD4F at 1999-09-26 Really create the revocation certificates? (y/N)y You need a passphrase to unlock the secret key for user: "Jordi (Castell S.L.) <jordi@cat.es>" 1024-bit DSA key, ID 1208DD4F, created 1999-09-24 Enter passphrase: pub sub sub rev! sub (1) (2) 1024D/1208DD4F created: 1999-09-24 expires: 1024g/B9688D9E created: 1999-09-24 expires: 2016G/4D88ACC4 created: 1999-09-26 expires: subkey has been revoked: 1999-09-26 960D/412EAF0C created: 1999-09-26 expires: Jordi (Castell S.L.) <jordi@cat.es> Jordi (oficina) <jordi@castell.com> never trust: -/u never 2002-09-25 2002-09-25
22
Un identicador de usuario revocado vendr indicado por la rma de revocacin en el identicador, y se podr ver en las rmas en la lista de identicadores de usuario de las claves.
Command<
hek
uid Jordi (Castell S.L.) <jordi@cat.es> sig! 1208DD4F 1999-09-24 [self-signature] uid Jordi (oficina) <jordi@castell.com> rev! 1208DD4F 1999-09-26 [revocation] sig! 1208DD4F 1999-09-26 [self-signature] sig! B87DBA93 1999-06-28 [self-signature]
Al revocar tanto las subclaves como las autormas en los identicadores de usuarios, aadimos autormas de revocacin a la clave. Ya que las rmas son aadidas a la clave y no eliminamos nada, una revocacin siempre estar visible para otros usuarios desde el momento en el que la actualizacin de nuestra clave pblica sea distribuida y fusionada con las copias ms viejas de sta. Por lo tanto, la revocacin garantiza que todos los usuarios tengan una copia consistente de nuestra clave pblica.
Actualizar la fecha de caducidad de una clave

La fecha de caducidad de una clave puede ser actualizada con la orden expire desde el men de edicin de la clave. Si no se selecciona ninguna clave, se actualizar la fecha de caducidad de la clave primaria. De otro modo, se actualizar la fecha de caducidad de la clave subordinada que hayamos seleccionado. La fecha de caducidad de una clave est asociada con la autorma de la clave. La fecha de caducidad se actualiza eliminando la autorma antigua y aadiendo una nueva autorma. Ya que los corresponsales no habrn eliminado la autorma antigua, vern una autorma adicional en la clave cuando actualicen su copia de nuestra clave. La ltima autorma es la que tiene precedencia, as que todos los corresponsales pueden saber sin ambigedad las fechas de caducidad de nuestras claves.
Validar otras claves en nuestro anillo de claves pblicas

En el captulo 1 se introdujo un procedimiento para validar las claves pblicas de otros usuarios: la clave de otro usuario se valida comprobando personalmente la huella digital de su clave, y rmando su clave pblica 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 rmado la clave, podemos estar seguros de que detectaremos cualquier manipulacin o falsicacin en un futuro. Desafortunadamente este proceso se complicado cuando debemos validar un gran nmero de claves o cuando debemos comunicarnos con personas a las que no conocemos personalmente. GnuPG trata este problema con un mecanismo conocido como anillo de conanza. En el modelo del anillo de conanza la responsabilidad de la validacin de las claves pblicas recae en las personas en las que conamos. Por ejemplo, supongamos que Javier ha rmado la clave de Arancha y que, Arancha ha rmado las claves de Jordi y de Ignacio.
23
Si Javier confa en Arancha lo suciente como para validar las claves que l rma, entonces Javier puede deducir que las claves de Jordi y de Ignacio son vlidas sin llegar a comprobarlas personalmente. Javier se limitar a usar su copia validada de la clave pblica de Arancha para comprobar que las rmas de Arancha sobre Jordi e Ignacio son autnticas. Por lo general, y asumiendo que Javier confe plenamente en todos como para validar las claves que rmen, cualquier clave rmada por una clave vlida tambin es considerada vlida. El origen es la clave de Javier, que se asumir axiomticamente como vlida.
Conanza en el propietario de una clave

En la prctica la conanza es algo subjetivo. Por ejemplo, la clave de Arancha es vlida para Javier ya que ha sido rmada por ella, pero Javier puede desconar de otras claves que hayan sido validadas por la rma de Arancha. En este caso, Javier no aceptara las claves de Jordi e Ignacio como vlidas slo porque hayan sido rmadas por Arancha. El modelo del anillo de conanza prevee este caso mediante un indicador que asocia nuestro nivel de conanza en el propieario de la clave, a cada clave pblica en nuestro anillo de claves. Existen cuatro niveles de conanza: unknown Desconocido. No se sabe nada sobre el dueo de la clave rmante. Las claves en nuestro anillo de claves que no nos pertenezcan tendrn al principio este nivel de conanza. none Ninguno. Se sabe que el propietario rma otras claves de modo impropio. marginal Marginal. El propietario comprende las implicaciones de rmar una clave y valida las claves de forma correcta antes de rmarlas. full Absoluto. El propietario comprende perfectamente las implicaciones de rmar una clave y su rma sobre una clave es tan buena como la nuestra. El nivel de conanza en una clave es algo que slo nosotros podemos asignar a la clave, y se considera informacin privada. El nivel de conanza no se exporta con la clave, de hecho no se almacena en los anillos de claves sino en una base de datos aparte. El editor de claves de GnuPG puede ser usado para ajustar nuestra conanza en el propietario de una clave. La orden es trust. En el siguiente ejemplo Javier edita su conanza en Arancha y actualiza la base de datos para recomputar qu claves son vlidas, basndose en su nuevo nivel de conanza en Arancha.
javier:~$
gpg EeditEkey ernznzu

trust: q/f
pub sub (1)
1024D/B63E132C created: 1999-09-24 expires: never 1024g/581A915F created: 1999-09-24 expires: never Ar\xc3\xa1nzazu (A.G.deZ.) <arancha@nav.es>
Command>
trust
24
pub sub (1)
trust: q/f
Please decide how far you trust this user to correctly verify other users keys (by looking at passports, checking fingerprints from different sources...)? 1 2 3 4 s m = = = = = = Dont know I do NOT trust I trust marginally I trust fully please show me more information back to the main menu
Your decision?
Q
trust: m/f
pub sub (1)
Command>
quit
[...]
La conanza en el propietario de la clave y la validez de la clave se indican a la derecha al mostrar la clave. La conanza en el propietario se muestra primero, y la validez despus1. Los cuatro niveles de conanza/validez se encuentran abreviados: unknown (q), none (n), marginal (m), y full (f). O sea, desconocido, ninguno, marginal y absoluto. En este caso, la clave de Arancha es totalmente vlida ya que est rmada por Javier. Al principio el nivel de conanza que Javier tiene en Arancha es desconocido, por lo que no procede validar otras claves; pero luego decide conar en ella de modo marginal.
Usar la conanza para validar las claves

El anillo de conanza permite usar un algoritmo ms elaborado para validar una clave. Anteriormente, una clave slo se consideraba vlida si la rmbamos nosotros personalmente. Ahora es posible usar un algoritmo ms exible: una clave K se considera vlida si cumple dos condiciones:
1. si viene rmada por las sucientes claves vlidas, lo que quiere decir
que la hemos rmado nosotros personalmente,
1.
N. de T.: GnuPG hace un uso excesivo de la palabra trust, utilizndola en el sentido de conanza en el propietario y conanza en la clave. Esto puede llevar a confusin. Algunas veces la conanza en un propietario viene referida como owner-trust para distinquirla de la conanza en una clave. Sin embargo, a lo largo de este manual trust se usa en el sentido de conanza en el propietario de la clave, y validity en el sentido de conanza en que una clave pertenece a la persona asociada con el identicador de clave.
25
o que ha sido rmada por una clave de plena conanza, o que ha sido rmada por tres claves de conanza marginal; 2. y si el camino de claves rmadas que nos lleva desde K hasta nuestra propia clave es de cinco pasos o menos. La longitud del camino, en nmero de claves con conanza marginal requeridas, y el nmero de claves con conanza plena requeridas se pueden cambiar. Los nmeros dados arriba son los valores por denicin usados por GnuPG. Figura 3-1 muestra un anillo de conanza cuyo origen est en Javier. El grco ilustra quin ha rmado las claves de quin. La tabla muestra qu claves son consideradas vlidas por Javier en base a su conanza en otros miembros del anillo. Este ejemplo asume que se necesitan dos claves de conanza marginal o una de conanza plena para validar otra clave. La longitud mxima del camino es tres. Al computar claves vlidas en el ejemplo, las de Arancha e Ignacio siempre son consideradas como totalmente vlidas, ya que estn directamente rmadas por Javier. La validez de las otras claves depende de la conanza. En el primer caso la conanza en Ignacio es plena, lo que implica que las claves de Jordi y Claudia se considerarn vlidas. En el segundo ejemplo la conanza en Arancha e Ignacio es marginal. Ya que son necesarias dos claves de conanza marginal para dar validez total a una clave, la clave de Jordi ser considerada como totalmente vlida, pero la clave de Claudia ser considerada slo como marginalmente vlida. En el caso en el que Jordi e Ignacio tuvieran conanza marginal, la clave de Jordi sera marginalmente vlida ya que la clave de Ignacio es totalmente vlida. Sin embargo, la clave de Claudia ser considerada marginalmente vlida ya que slo se puede usar una clave completamente vlida para validar otras claves, y la clave de Ignacio es la nica clave vlida que se ha usado para rmar la clave de Claudia. Al aadir un nivel de conanza marginal a Arancha, la clave de Jordi se convierte en totalmente vlida y por tanto puede ser usada para validar totalmente la clave de Claudia, y validar marginalmente la clave de Jimena. Por ltimo, una conanza plena en Arancha, Jordi y Jimena es todava insuciente para validar la clave de Gonzalo ya que el camino mximo de certicacin es tres, pero la longitud del camino desde Gonzalo hasta Javier es cuatro. El modelo del anillo de conanza es una aproximacin exible al problema del intercambio seguro de claves pblicas. Nos permite poner a punto GnuPG para que reeje el modo en que lo usamos. Es posible llegar a insistir en mltiples caminos cortos desde nuestra clave hasta otra clave K para cambiar el nivel de conanza. Por otra parte, puede ser que caminos ms largos nos satisfagan e incluso un slo camino desde nuestra clave hasta la otra clave K . El requerimiento de mltiples caminos cortos es una fuerte garanta de que K pertenece a quien nosotros creemos. El precio, por supuesto, es la dicultad aadida para validar claves, ya que debemos rmar personalmente ms claves que si aceptramos menos y ms largos caminos.

26
Figura 3-1. Un anillo de conanza hipottico
trust/conanza marginal full/plena Ignacio Arancha, Ignacio Jordi, Ignacio Arancha, Jordi, Ignacio Arancha, Jordi, Jimena
validity/validez marginal full/plena Arancha, Jordi, Ignacio, Claudia Claudia Jordi, Claudia Jimena Arancha, Jordi, Ignacio Arancha, Ignacio Arancha, Jordi, Ignacio, Claudia Arancha, Jordi, Jimena, Claudia
Distribucin de claves
Lo ideal sera que pudiramos distribuir nuestra clave entregndosela en persona a nuestros corresponsales. Sin embargo, en la prctica las claves se distribuyen a menudo por correo electrnico o algn otro medio de comunicacin electrnica. La distribucin por correo electrnico es una buena prctica slo cuando tengamos unos pocos corresponsales, e incluso si tuviramos muchos corresponsales, podramos usar un medio alternativo como puede ser publicar nuestra clave pblica en nuestra pgina en internet. Pero esto es intil si las personas que necesitan nuestra clave pblica no saben dnde encontrar nuestra pgina. Para solventar este problema existen los servidores de claves pblicas que recolectan y distribuyen las claves pblicas. Cuando un servidor recibe una clave pblica, bien la aade a la base de datos o bien la fusiona con una copia de la clave. Cuando alguien requiere al servidor una clave pblica, ste la busca en la base de datos y, si la encuentra, la enva a quien se la haya solicitado. Los servidores de claves tambin son tiles cuando hay muchas personas que rman las claves de otras con frecuencia. Sin un servidor de claves, cuando Arancha rmara la clave de Javier, debera enviar a ste una
27
copia de la clave rmada por ella de manera que Javier pudiera aadir la clave rmada 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 conanza o lo que es lo mismo, mejorando la seguridad de PGP. De todos modos esto es una molestia si se rman las claves con frecuencia. El uso de un servidor de claves facilita este proceso. Despus de rmar la clave de Javier, Arancha puede enviar la copia rmada por ella al servidor de claves. El servidor de claves aade la rma de Arancha a la copia que ya existente de la clave pblica de Javier. Las personas que estn 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 rmas en su clave requirindolas al servidor. Se puede enviar una o ms claves usando la opcin de la lnea de rdenes -send-keys. Esta opcin toma uno o ms especicadores de clave, y enva las claves especicadas al servidor de claves. El servidor al que se envan las claves es especicado con la opcin de la lnea de orden -keyserver. Paralelamente, la opcin -recv-keys se usa para obtener claves desde un servidor de claves, pero la opcin -recv-keys requiere el uso de un identicador de clave para poder especicar la clave deseada. En el siguiente ejemplo Javier actualiza su clave pblica con nuevas rmas desde el servidor de claves certserver.pgp.com y acto seguido enva su copia de la clave pblica de Arancha al mismo servidor de claves para que se actualice con las claves que l mismo pueda haber aadido.
gpg Ekeyserver ertserverFpgpFom ErevEkey hSVUIIfU
javier:~$
gpg: requesting key D58711B7 from certserver.pgp.com ... gpg: key D58711B7: 1 new signature gpg: Total number processed: 1 gpg: new signatures: 1
gpg Ekeyserver ertserverFpgpFom EsendEkey rnhdnvFes

javier:~$
gpg: success sending to certserver.pgp.com (status=200)
Existen varios servidores de claves en funcionamiento en todo el mundo. Los servidores ms importantes estn sincronizados de modo que es posible elegir un servidor de claves cercano a nosotros en Internet y usarlo de forma regular para enviar y recibir claves.
28
Captulo 4. Uso diario de GnuPG

GnuPG es una compleja herramienta que no est exenta de polmica tcnica, social y legal. En el plano tcnico, ha sido diseada para su uso en situaciones con diversos requerimientos de seguridad. Esto complica la gestin de claves. En el plano social, el uso de GnuPG no es estricatamente una decisin de tipo personal. Para que su uso tenga efectividad, GnuPG requiere que todas las partes en una comunicacin sean usuarios del programa. En el plano legal, desde 1.999, las leyes que contemplan el uso de productos informticos criptolgicos, y en particular si el uso de GnuPG es legal, son diferentes segn los pases y estn siendo actualmente debatidas por muchos gobiernos. Este captulo tratar sobre estos temas. Se intentar dar consejos prcticos sobre el uso de GnuPG de cara a los requerimientos de seguridad del usuario. Tambin se sugerirn vas para promocionar el uso de GnuPG con vistas a la comunicacin segura entre el usuario y las personas con las que ste se comunique, aun cuando stos no sean usuarios de GnuPG. Finalmente, se resaltar el estado legal de GnuPG conforme con el estado actual de las leyes sobre criptologa y cifrado en el mundo.
Deniendo los requerimientos en seguridad

GnuPG es una herramienta que utiliza el usuario para proteger su privacidad. La proteccin existe slo si el usuario puede comunicarse con otros sin escuchas que puedan leer los mensajes. El modo en que se deba usar GnuPG depender de la determinacin y de los recursos de aqullos que intenten, o puedan intentar, leer los mensajes cifrados del usuario. Un escucha podra ser un administrador de sistemas sin escrpulos, que se encuentre, por casualidad, escaneando el correo del usuario, o podra ser un espa industrial que intentara acceder a los secretos de una compaa, o incluso podra ser un organismo legal que quisiera llevarnos a juicio. El uso de GnuPG para protegernos contra intromisiones casuales, ser diferente de su uso para protegernos contra un adversario determinado. Nuestro n ltimo debe ser el de que el conseguir los datos no cifrados resulte ms caro que el valor de los datos en s. La personalizacin del uso de GnuPG se basa en los siguientes aspectos: la eleccin del tamao del par de claves pblico y privado. la proteccin de la clave privada, la seleccin de la fecha de caducidad y el uso de subclaves, y la gestin del anillo de conanza. Una buena eleccin del tamao de la clave nos proteger contra ataques de fuerza bruta en los mensajes cifrados. La proteccin de nuestra clave privada ayudar a prevenir que un atacante pueda llegar a usarla para descifrar mensajes o rmar mensajes en nuestro nombre. Una gestin correcta de nuestro anillo de conanza, ayudar a evitar que cualquier atacante pueda hacerse pasar por una persona de nuestra conanza. La consecucin de estos aspectos segn las necesidades de nuestra propia seguiridad, es el modo de equilibrar el trabajo extra que se requiere para usar GnuPG con la privacidad que ofrece.
Seleccin del tamao de la clave
29
La seleccin del tamao de la clave depende de la clave en s. En OpenPGP, un par de claves pblica y privada contienen generaralmente claves mltiples. Como mnimo tiene una clave de rmado maestra, y probablemente una o ms subclaves de cifrado adicionales. Si usamos para la generacin de claves los parmetros por defecto en GnuPG, la clave maestra ser una clave DSA, y las subclaves sern claves ElGamal. DSA nos permite un tamao de clave de hasta 1024 bits. Dada la tecnologa de factorizacin de hoy en da, esto no es demasiado bueno, pero es lo que especica el estndar. Sin duda alguna, debemos usar claves DSA de 1024 bits. Por otra parte, las claves ElGamal pueden ser de cualquier tamao. Ya que GnuPG es un sistema de clave pblica hbrido, la clave pblica se usa para cifrar una clave de sesin de 128 bits, y la clave privada se usa para descifrarla. Sin embargo el tamao de la clave afecta a la velocidad del cifrado y descifrado, ya que el valor de estos algoritmos lleva como exponente el tamao de la clave. Una clave de mayor tamao tambin tarda ms en ser generada, y ocupa ms espacio. Adems, cuanto mayor tamao tenga una clave, la seguridad extra que nos ofrece, aumenta pero con una marcha decreciente. Tambin hay que tener en cuenta que un escucha que se encuentre con una clave lo sucientemente grande como para resistir un ataque de fuerza bruta, se limitar a cambiar de mtodo para poder obtener los datos no cifrados. Por lo tanto, 1024 bits es el tamao de clave recomendado. Si nuestros requerimientos de seguridad fueran tan grandes como para necesitar claves de gran tamao, entonces deberamos consultar a un experto en seguridad de datos.
Proteccin de la clave privada

La proteccin de la clave privada es la parte ms importante en el uso de GnuPG. Si alguien obtuviera nuestra clave privada, todos los datos que hubieran sido cifrados para esa clave podran ser descifrados y se podra rmar documentos bajo nuestro nombre. Si perdiramos la clave privada, ya no podramos descifrar los documentos cifrados que nos hubieran enviado o que nos enviaran en un futuro, y no podramos rmar los documentos. La prdida de posesin de nuestra clave privada podra ser una catstofre. Sea cual fuere el uso que hagamos de GnuPG, deberamos guardar siempre un certicado de revocacin de nuestras claves pblicas, y una copia de seguridad de nuestra clave privada en un disco protegido contra la escritura, y en un lugar seguro. Por ejemplo, podramos grabarlo en un CD-ROM y guardar ste en un cofre de depsito de un banco, dentro de un sobre sellado. Alternativamente, podramos guardarlo en un disquete y esconderlo en nuestra casa. Hagamos lo que hagamos, los certicados de revocacin de las claves pblicas y las copias de seguridad de la clave privada deberamos tenerlos guardados en un medio lo sucientemente seguro, mucho ms que la clave privada que utilizamos a diario. Como medida de seguridad, GnuPG no guarda nuestra clave privada en bruto en el disco duro, sino que la cifra mediante un algoritmo de cifrado simtrico. Por esta razn, para acceder a nuestra clave, necesitamos una contrasea. Por lo tanto, existen dos barreras que un atacante debe cruzar para poder acceder a nuestra clave privada: (1) debe conseguir la clave; (2) debe ser capaz de descifrarla. Esconder nuestra clave privada en un sitio seguro es importante, pero todo tiene un precio. Lo ideal sera que guardramos la clave en un disco que fuera porttil y que tuviera proteccin contra la escritura, como un disquete, y que slo lo usramos en una mquina con un solo usuario que no estuviera conectada a una red. Esto puede que no sea convenient o posible para nosotros. Por ejemplo, es posible que no tengamos nuestra propia mquina, y que debamos usar la de la universidad o la de la ocina, o puede signicar que para ello tengamos que desconectar el modem cada vez que queramos usar GnuPG.
30
Esto no quiere decir que no podamos o no debamos usar GnuPG. Tan slo signica que debemos decidir si los datos que estamos protegiendo son lo sucientemente importantes para cifrarlos, pero no tan importantes como para tomar medidas extra de seguridad. La eleccin es nuestra. Una buena contrasea es absolutamente crtica para el uso de GnuPG. Cualquier atacante que logre acceder a nuestra clave privada, deber sobrepasar el cifrado de nuestra clave privada. En lugar de usar un ataque de fuerza bruta, es casi seguro que un atacante intentar adivinar la contrasea. El motivo por el que intentara adivinarla, es que la mayora de personas escogen contraseas que son ms fciles de adivinar que de sobrepasar una clave aleatoria de 128 bits. Si la contrasea es una palabra ("password"), es mucho ms fcil probar con todas las palabras existentes en los diccionarios de todas las lenguas del mundo. Aun cuando la palabra sea permutada, v.g. k3wldood, ser ms fcil probar palabras de diccionario con un catlogo de permutaciones. Lo mismo ocurre con las citas. Aunque sea una contrasea formada por frases ("passphrase"), si sta tiene como base un lenguaje natural, ser una contrasea dbil, ya que existir poca aleatoriedad y muchas redundancias. Si es posible, debemos evitar contraseas basadas en lenguajes naturales. Una buena contrasea es aqulla que podemos recordar, pero que es difcli que otro pueda adivinar. Debera incluir todos los carcteres imprimibles de nuestro teclado posibles. Esto incluye carcteres alfabticos en maysculas y minsculas, nmeros, y carcteres especiales como } o . Debemos ser creativos y perder un poco de tiempo inventando una contrasea; una buena eleccin es importante para asegurar nuestra privacidad.
Seleccin de las fechas de caducidad y uso de subclaves

Por defecto, una clave de rmado maestra DSA y una subclave de cifrado ElGamal son generadas al crear un nuevo par de claves. Esto es conveniente porque cada clave juega un papel diferente, y por lo tanto es posible que necesitemos que las claves tengan fechas de caducidad diferentes. La clave de rmado maestra se usa para las rmas digitales, y tambin recolectan las rmas de otras personas que hayan conrmado nuestra identidad. La clave de cifrado se usa slo para descifrar los documentos cifrados que nos hayan enviado. Por lo general, una rma digital tiene una larga vida, v.g., para siempre, y tampoco queremos perder las rmas que tanto nos ha costado recolectar en nuestra clave. Por otra parte, la subclave de cifrado puede cambiar peridicamente por cuestiones de seguridad, ya que si una clave de cifrado es descifrada, el atacante puede leer todos los documentos que sean cifrados para esa clave. Suele ocurrir que no queramos que nuestra clave maestra caduque. Existen dos razones por las que debamos escoger una fecha de caducidad. La primera es que tengamos la intencin de que la clave tenga una vida limitada. Por ejemplo, si la usamos para una campaa poltica y no nos ser til una vez pasada la campaa. La segunda es que si perdemos el control de la clave, y no tenemos un certicado de revocacin con el que revocarla, una fecha de caducidad sobre la clave maestra asegura que la clave caer nalmente en desuso. Cambiar las subclaves de cifrado puede ser sencillo, pero puede que no sea del todo conveniente. Si generamos un nuevo par de claves con una fecha de caducidad en la subclave, sta caducar en su momento. Poco antes de la caducidad aadiremos una nueva subclave y publicaremos nuestra clave pblica actualizada. Una vez que la subclave haya caducado, aquellos que deseen comunicarse con nosotros debern encontrar antes la clave actualizada, pues ya no podrn enviar datos cifrados para esa clave. El inconveniente depende de cmo distribuyamos la clave. Por fortuna, no es necesario rmas extras ya que la nueva clave habr sido rmada con con nuestra clave de rmado maestra, la cual ya haba sido validada por nuestros corresponsales.
31
Todo depende de que queramos o no tener una seguridad extra. Al igual que nosotros, un atacante todava podr leer todos los documentos que hayan sido cifrados para una clave caducada. Cambiar las subclaves slo protege los futuros documentos. Para poder leer documentos cifrados para la nueva subclave, el atacante necesitara organizar un nuevo ataque, usando cualquier tcnica que hubiera usado la primera vez. Al nal slo tiene sentido tener una sola subclave de cifrado en un anillo de claves. No hay se gana seguridad adicional teniendo dos o ms subclaves activas. Por supuesto, puede existir cualquier nmero de claves caducadas en un anillo de claves, para que los datos que hubieran sido cifrados en el pasado puedan todava ser descifrados, pero slo es necesario activar una sola subclave en un momento dado.
Gestin del anillo de conanza

Al igual que con la proteccin de nuestra clave privada, la gestin de nuestro anillo de conanza es otro aspecto del uso de GnuPG que requiere equilibrar la seguridad y la facilidad de uso. Si estamos usando GnuPG para protegernos contra la posibilidad de una simple interceptacin casual o de una falsicacin, entonces nos podemos permitir ser algo conados con las rmas de otros. Si, por el contrario, nos preocupa que pueda haber un atacante determinado interesado en invadir nuestra privacidad, entonces deberamos conar mucho menos en otras rmas, e invertir ms tiempo en vericarlas. Aparte de nuestras propias necesidades de seguridad, deberamos tener siempre cuidado al rmar las claves de otras personas. Firmar una clave sin el suciente grado de conanza en la validez de la clave, slo para satisfacer nuestras propias necesidades de seguridad, es una actitud egosta. Otros, con otras necesidades de seguridad ms grandes, podran arse de una clave que llevara nuestra rma. Si no pueden conar en nosotros, entonces se debilita el anillo de conanza y se hace ms difcil la comunicacin para todos los usuarios de GnuPG. As pues, debemos poner el mismo cuidado al rmar una clave que el que nos gustara que pusieran otras personas cuando dependamos de sus rmas. En la prctica, la gestin de nuestro anillo de claves evita el tener que ajustar las opciones -marginalsneeded y -completes-needed. Cualquier clave que rmemos personalmente ser considerada vlida, pero con la excepcin de grupos reducidos, no es prctico rmar la clave de cada persona con la que nos comuniquemos. Por lo tanto, tendremos que dejar que otros asignen el nivel de conanza. Es aconsejable ser precisos cuando asignemos el nivel de conanza y cuando usemos las opciones para congurar el cuidado con que GnuPG debe ir con la validacin de claves. Por ejemplo, es posible que tengamos plena conanza con unos pocos amigos ntimos, que sabemos que sern lo sucientemente cuidadosos cuando rmen una clave, y que otorguemos un nivel de conanza marginal al resto en nuestro anillo de claves. Desde esta perspectiva, podemos tener -completes-needed como 1 y -marginals-needed como 2. Si estuviramos ms preocupados por la seguridad, podramos escoger valores de 1 y 3, o 2 y 3 respectivamente. Pero si no estamos tan preocupados por los posibles ataques sobre la privacidad, y simplemente queremos una abilidad razonable sobre la validez, escogeremos los valores 1 y 1. Por regla general, los nmeros ms altos para estas opciones suponen que sera necesario que hubiera ms gente conspirando contra nosotros para poder validar una clave que no pertenezca a la persona que nosotros creemos.
Construccin del anillo de conanza
32
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 conanza. A primera vista, construir un anillo de conanza es una tarea desalentadora. Las personas con las que nos comunicamos necesitan usar GnuPG1, y es necesario que haya las sucientes rmas para que las clave sean consideradas vlidas. Estos no son problemas de tipo tcnico; 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 pequeo crculo de amigos, tal vez slo nosotros y uno dos ms que tambin quieran ejercitarse en su derecho a la privacidad. Generemos nuestras claves, y rmmoslas recprocamente. ste es nuestro anillo de conanza inicial. Al hacerlo as, apreciaremos el valor de un pequeo, pero robusto anillo de conanza, y seremos ms cautos a medida que vaya creciendo nuestro anillo de conanza con el tiempo. Adems de aqullos en nuestro anillo de conanza inicitico, es posible que deseemos comunicarnos en modo seguro con otros que tambin estn usando GnuPG. Sin embargo, esto puede ser problemtico por dos razones: (1) no siempre sabemos cundo alguien usa o estara dispuesto a usar GnuPG; (2) si sabemos de alguien que lo usa, todava es posible que tengamos problemas para validar su clave. El primer motivo sucede porque las personas no siempre hacen pblico que usan GnuPG. La forma de cambiar ese comportamiento es sentar ejemplo y hacer pblico que usamos GnuPG. Existen al menos tres maneras de hacer esto: rmar digitalmente los mensajes que enviamos a otros2, publicar nuestra clave pblica en nuestra pgina en Internet, o, si la subimos a un servidor de claves, poner nuestro identicador de clave como parte de nuestra rma. Haciendo pblica nuestra clave, ayudamos a que sea ms aceptable para otras personas hacerla tambin pblica. Adems, hacemos ms fcil 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 validacin de la clave es ms difcil. Si no conocemos personalmente a la persona cuya clave queremos rmar, no es posible que podamos rmar su clave personalmente. Debemos arnos de las rmas de otras personas y esperar que encontraremos una cadena de rmas que nos lleven desde la clave en cuestin hasta la nuestra. Para poder encontrar una cadena, debemos tomar la iniciativa y conseguir que nuestra clave sea rmada por otras personas fuera de nuestro anillo de conanza inicial. Un modo efectivo de conseguir esto es participando en reuniones de rmas. De todos modos, debemos tener en cuenta que todo esto es opcional. No existe ningn tipo de obligacin de hacer pblicas nuestras claves o de rmar las claves de otros. GnuPG es lo sucientemente exible 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 conanza, y hacer todo el uso posible de GnuPG.
Uso legal de GnuPG

1. En esta seccin, GnuPG se reere a la implementacin OpenPGP de GnuPG, as como a otras implementaciones como el producto PGP de NAI. Se recomienda no hacerlo nunca en listas de correo de discusin pblica, ya que esto podra molestar a algunas personas.
2.
33
El estado legal de los programas criptolgicos vara segn pases, y las leyes que rigen estos programas evolucionan con rapidez. Bert-Japp Koops (http://cwis.kub.nl/~frw/people/koops/bertjaap.htm) mantiene unos recursos sobre leyes y criptografa, Crypto Law Survey (http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm), que podemos tomar como referencia para el status legal en cada pas.
34
Captulo 5. Tpicos
Este captulo trata temas miscelneos que no se ajustan a otros captulos del manual de usuario. A medida que se vayan aadiendo nuevos temas, se pueden ir creando nuevos captulos con stos. Sugerencias sobre temas que no han sido tratados son bienvenidas. Mejor an si estas sugerencias vienen acompaadas por un boceto o esquema sobre el tema sugerido!
Escribir interfaces de usuario

Alma Whitten (http://www.cs.cmu.edu/~alma) y Doug Tygar (http://www.cs.berkeley.edu/~tygar) han hecho un estudio (http://reports-archive.adm.cs.cmu.edu/anon/1998/abstracts/98-155.html) sobre la interfaz de usuario de PGP 5.0 de NAI, llegando a la conclusin de que los usuarios nuevos encuentran PGP confuso y frustrante. En su estudio sobre factores humanos, slo cuatro de cada doce de los sujetos en estudio consiguieron enviar correctamente correo cifrado a los miembros de su equipo, y tres de cada doce enviaron el correo secreto sin ningn tipo de cifrado. Ms an, la mitad de los sujetos del estudio posean conocimientos tcnicos. Estos resultados no son sorprendentes. PGP 5.0 tiene una bonita interfaz de usuario que es excelente si ya comprendemos el funcionamiento de la criptografa de clave pblica, y si estamos familiarizados con el modelo de gestin de claves del anillo de conanza, especicado por OpenPGP. Por desgracia, los usuarios nuevos no entienden ni la criptologa de clave pblica, ni la gestin de claves, y la interfaz de usuario no es de ninguna ayuda en este caso. Alguien que estuviera diseando una interfaz de usuario, debera leer el estudio de Whitten y Tygar sin lugar a dudas. En l se dan detalles especcos sobre cada uno de los sujetos sometidos a estudio, y esos comentarios son interesantes. Por ejemplo, parece ser que muchos de los sujetos crean que un mensaje enviado a otra persona, deba ser cifrado con la clave pblica del remitente. Reexionemos un minuto sobre esto, y nos daremos cuenta de que es un fallo muy fcil de cometer. Por lo general, los nuevos usuarios tienen dicultades en comprender los propsitos diferentes de las claves pblicas y de las privadas en GnuPG. Un diseador de una interfaz de usuario debera intentar aclarar en todo momento cundo una de las dos claves debe ser usada. Se podra usar ayudas guiadas, u otras tcnicas de interfaz grca de usuario (GUI), con el n de guiar al usuario en tareas tan comunes como la generacin de claves, donde pasos extras como la generacin de un certicado de revocacin y hacer una copia de seguridad, son esenciales para el uso correcto de GnuPG. Otros comentarios sobre el estudio se incluyen a continuacin. La seguridad es, generalmente, un objetivo secundario; los usuarios quieren enviar correo, enviarlo, y dems... No se debe asumir que los usuarios tienen ningn tipo de motivacin para la lectura de manuales, o que buscarn controles de seguridad. La seguridad de una mquina en red es tan fuerte como el ms dbil de sus componentes. Los usuarios necesitan ser guiados para que presten atencin a todos los aspectos de su seguridad, no se les puede dejar que procedan en exploraciones aleatorias, como podran hacer con un procesador de texto o un hoja de clculo. Se debe ser consistente en el uso de los mismos trminos para las mismas operaciones. No se deben alternar sinnimos como cifrar y encriptar1.
1. Del documento original en ingls, ya que en castellano la palabra encriptar es incorrecta, mientras que la correcta es cifrar. As
35
Captulo 5. Tpicos
Se debe simplicar la vista en pantalla para los usuarios inexpertos. Un exceso de informacin oculta la informacin importante. La conguracin inicial podra concentrarse en dar al usuario el modelo correcto de la relacin entre claves pblicas y privadas, y una clara explicacin de las funciones para la adquisicin y distribucin de claves. Disear una interfaz de usuario efectiva para la gestin de claves es todava ms difcil. El modelo de anillos de conanza de OpenPGP es, por desgracia, bastante rgido. Por ejemplo, la especicacin impones el uso de tres niveles de conanza arbitrarios: none (ninguna), marginal (idem), y complete (total). Todos los grados de conanza que pueda sentir el usuario deben ajustarse a esos tres. La validacin del algoritmo tambin es difcil de comprender para aquellos que no sean muy expertos, en particular las nociones de marginals needed y completes needed2. Pero ya que el modelo de anillos de conanza est bien especicado y no se puede cambiar, hay que hacerlo lo mejor posible y disear una interfaz de usuario que ayude a claricrselo de cara al usuario. Por ejemplo, una mejora sera generar un diagrama de cmo ha sido validada una clave, al ser requerida por el usuario. A continuacin algunos comentarios relevantes del estudio. Los usuarios tienden a tener incerteza sobre cundo y cmo pueden conceder accesos. Asegurarse que los usuarios comprenden su propia seguridad lo sucientemente bien como para prevenirlos de que cometan errores que puedan suponer un alto coste, debe ser un mxima prioridad. Tales errores incluyen: eliminar la clave privada por accidente; hacer pblica una clave por error; revocar una clave por error; olvidar la contrasea; y no hacer copias de seguridad de sus anillos de claves.
pues, en este caso y en castellano, estas dos palabras no son sinnimos. 2. Cuntas rmas que tengan asignada conanza marginal y cuntas rmas que tengan asignada conanza completa son necesarias
36

Manual GPG

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Manual GPG

Cargado por

Copyright:

Formatos disponibles

Gua de Gnu Privacy Guard

Captulo 1. Primeros Pasos

Generar un nuevo par de claves

Captulo 1. Primeros Pasos

Captulo 1. Primeros Pasos

Generar un certicado de revocacin

Captulo 1. Primeros Pasos

gpg Eoutput hSVUIIfUFs EgenErevoke HxhSVUIIfU

Exportar una clave pblica

gpg Eoutput jviFgpg Eexport jvierdsFes

Captulo 1. Primeros Pasos

gpg Ermor Eoutput jviFs Eexport jvierdsFes

Importar una clave pblica

gpg Eimport rnhFgpg

gpg EeditEkey rnhdnvFes

pub sub (1)

Captulo 1. Primeros Pasos

Cifrar y descifrar documentos

Captulo 1. Primeros Pasos

gpg Eoutput doFgpg Eenrypt Ereipient rnhdnvFes do

gpg Eoutput do Ederypt doFgpg

gpg Eoutput doFgpg Esymmetri do

Firmar y vericar rmas

Captulo 1. Primeros Pasos

gpg Eoutput doFsig Esign do

gpg Eoutput do Ederypt doFsig

Documentos con rmas ASCII

Captulo 1. Primeros Pasos

gpg Eoutput doFsig EdethEsig do

gpg Everify doFsig do

Sistemas de cifrado simtrico

Sistemas de cifrado asimtrico

Sistemas de cifrado hbridos

Captulo 3. Gestin de Claves

Gestionando nuestro par de claves

gpg EeditEkey jordidtFes

Captulo 3. Gestin de Claves

sec sbb sbb sbb (1) (2)

Captulo 3. Gestin de Claves

gpg EeditEkey jordi

Aadir y eliminar componentes a las claves

Captulo 3. Gestin de Claves

Revocar componentes de una clave

pub sub sub* sub (1) (2)

Captulo 3. Gestin de Claves

Jordi (Castell S.L.) <jordi@cat.es> Jordi (oficina) <jordi@castell.com>

Captulo 3. Gestin de Claves

Actualizar la fecha de caducidad de una clave

Validar otras claves en nuestro anillo de claves pblicas

Captulo 3. Gestin de Claves

Conanza en el propietario de una clave

gpg EeditEkey ernznzu

pub sub (1)

Captulo 3. Gestin de Claves

pub sub (1)

pub sub (1)

Usar la conanza para validar las claves

que la hemos rmado nosotros personalmente,

Captulo 3. Gestin de Claves

Captulo 3. Gestin de Claves

Figura 3-1. Un anillo de conanza hipottico

Captulo 3. Gestin de Claves

gpg Ekeyserver ertserverFpgpFom EsendEkey rnhdnvFes