Gu a de ``Gnu Privacy Guard'' Copyright ? 1999 The Free Software Foundation Para cualquier duda, error, o sugerencia sobre este manual, dir jase al autor del mismo, Mike Ashley (). Para cualquier duda, correcci n, o sugerencia sobre la versi n en castellano, dir jase al traductor, Horacio (< homega@ciberia.es>). Tambi n han contribuido a la creaci n del manual Matthew Copeland, Joergen Grahn y David A. Wheeler. Se otorga permiso para copiar, distribuir y/o modificar este documento bajo los t rminos de la Licencia de Documentaci n Libre GNU, Versi n 1.1 o cualquier otra versi n 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 p gina de t tulo siendo NONE. Una copia de la licencia es incluida en la secci n titulada "Licencia de Documentaci n Libre GNU". ------------------------------------------------------------------------------- Tabla de contenidos 1. Primeros Pasos Generar un nuevo par de claves Generar un certificado de revocaci n Intercambiar claves Exportar una clave p blica Importar una clave p blica Cifrar y descifrar documentos Firmar y verificar firmas Documentos con firmas ASCII Firmas acompa antes 2. Conceptos Sistemas de cifrado sim trico Sistemas de cifrado asim trico Sistemas de cifrado h bridos Firmas digitales 3. Gesti n de Claves Gestionando nuestro par de claves Integridad de claves A adir y eliminar componentes a las claves Revocar componentes de una clave Actualizar la fecha de caducidad de una clave Validar otras claves en nuestro anillo de claves p blicas Confianza en el propietario de una clave Usar la confianza para validar las claves Distribuci n de claves 4. Uso diario de GnuPG Definiendo los requerimientos en seguridad Selecci n del tama o de la clave Protecci n de la clave privada Selecci n de las fechas de caducidad y uso de subclaves Gesti n del anillo de confianza Construcci n del anillo de confianza Uso legal de GnuPG 5. T picos Escribir interfaces de usuario Lista de figuras 3-1. Un anillo de confianza hipot tico ------------------------------------------------------------------------------- Cap tulo 1. Primeros Pasos GnuPG es una herramienta de seguridad en comunicaciones electr nicas. Este cap tulo es una gu a r pida que cubre las funciones b sicas de GnuPG. Estas funciones incluyen generar un par de claves, intercambiar y comprobar la autenticidad de claves, cifrar y descifrar documentos, y firmar documentos y verificar firmas digitales. En este cap tulo no se detallan los conceptos de la criptograf a de clave p blica, cifrado, y firmas digitales. Todo esto se cubrir en detalle en el Cap tulo 2. Tampoco se explica el uso avanzado the GnuPG. Esto se explica en los Cap tulos 3 y 4. GnuPG utiliza criptograf a de clave p blica para que los usuarios puedan comunicarse de un modo seguro. En un sistema de claves p blicas cada usuario posee un par de claves, compuesto por una clave privada y una clave p blica. Cada usuario debe mantener su clave privada secreta; no debe ser revelada nunca. La clave p blica se puede entregar a cualquier persona con la que el usuario desee comunicarse. GnuPG implementa un esquema algo m s sofisticado en el que un usuario tiene un par de claves primario, y ninguno o m s de un par de claves adicionales subordinadas[1]. Los pares de claves primarios y subordinados se encuentran agrupados para facilitar la gesti n de claves, y el grupo puede ser considerado como un s lo par de claves. ------------------------------------------------------------------------------- Generar un nuevo par de claves La opci n de la l nea de rdenes --gen-key se usa para generar un nuevo par de claves primario. javier:~$ gpg --gen-key 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 firmas. Por lo tanto, existen s lo tres opciones. La opci n 1 genera dos pares de claves. Un par de claves DSA que es el par de claves primario que se usar s lo para firmar. Un par de claves subordinadas ElGamal que se usar para el cifrado. La opci n 2 es parecida a la anterior, pero s lo genera un par de claves DSA. La opci n 4[2] genera un nico par de claves ElGamal, que se usar tanto para firmar como para cifrar. En todos los casos existe la posibilidad de a adir subclaves adicionales para cifrar y firmar a posteriori . La mayor a de los usuarios tienen suficiente con la opci n por definici n. Tambi n hay que escoger un tama o para la clave. El tama o de una clave DSA debe estar entre los 512 y 1024 bits, y una clave ElGamal puede ser de cualquier tama o. Sin embargo, GnuPG requiere que las claves no sean menores de 768 bits. Por tanto, si se escogi la opci n 1 y tambi n un tama o de claves mayor de 1024 bits, la clave ElGamal tendr el tama o 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 m s larga sea la clave, m s segura ser contra ataques de fuerza bruta , pero por lo dem s el tama o de la clave que se da por definici n es el adecuado, ya que ser a m s barato circunvalar el cifrado que intentar entrar mediante ataques de fuerza. Adem s, el cifrado y descifrado de mensajes se ralentizar a a medida que se incrementara el tama o de la clave, y un tama o de clave m s grande podr a afectar a la longitud de la firma digital. Una vez seleccionado, el tama o de una clave no se puede cambiar nunca. Para terminar, hay que escoger un fecha de caducidad. Si se escogi anteriormente la opci n 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 = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0) Key does not expire at all Is this correct (y/n)? Para la mayor a 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 generaci n de la clave, puede ser dif cil comunicar un cambio a aquellos usuarios que posean esta clave p blica. Adem s de los par metros de la clave, el usuario debe dar un identificador. El identificador 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) " Real name: Email address: Comment: S lo se crear un identificador de usuario al generar una clave, pero es posible crear identificadores adicionales si se desea usar la clave en dos o m s contextos, v.g., si se usa por una parte en la oficina como empleado y por otra parte en casa como activista pol tico. Hay que tener cuidado al crear un identificador de usuario, ya que despu s 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 campos[3]. Por ejemplo, si rellen ramos los campos con los siguientes datos, * Real name: Javier * Email address: javier@mad.es * Comment: P ramo S.L. Ver amos lo siguiente: "Javier (P\xc3\xa1ramo S.L.) ". Por tanto es mejor evitar estos car cteres. You are using the `iso-8859-1' character set. You selected this USER-ID: "Javier (Paramo S.L.) " Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? A n as , dependiendo de la versi n que estemos usando, al listar las claves veremos una serie de car cteres extra os en lugar de vocales acentuadas, ?, ?, etc... GnuPG necesita una contrase a con el fin de proteger las claves privadas, primarias y secundarias, que posea el usuario[4]. You need a Passphrase to protect your private key. Enter passphrase: No hay l mite para la longitud de una contrase a, y sta debe ser escogida con sumo cuidado. Desde un punto de vista de seguridad, la contrase a que desbloquea la clave privada es uno de los puntos m s d biles en GnuPG (y en otros sistemas de cifrado de clave p blica), ya que es la nica protecci n que tiene el usuario si alguien se apoderara de su clave privada. Para una contrase a lo ideal es que no se usen palabras de un diccionario, y que se mezclen may sculas y min sculas, d gitos, y otros caracteres. Una buena contrase a es crucial para el uso seguro de GnuPG. Repeat passphrase: Como antes con los campos de identificaci n del usuario, las contrase as aceptan caracteres especiales de iso-8859-1. No obstante, debemos tener en cuenta que si alguna vez tuvi ramos que usar nuestra contrase a desde una m quina con un teclado distinto al nuestro, nos ver amos imposibilitados a menos que cambi ramos la configuraci n del sistema. ------------------------------------------------------------------------------- Generar un certificado de revocaci n Despu s de haber generado un par de claves, el usuario debe, de forma inmediata, generar un certificado de revocaci n para la clave p blica primaria, mediante el uso de la opci n --gen-revoke. Si el usuario olvidara la contrase a, o si su clave privada estuviera en peligro o extraviada, este certificado de revocaci n podr a ser hecho p blico para notificar a otros usuarios que la clave p blica no debe ser usada nunca m s. Una clave p blica revocada puede ser usada para verificar firmas hechas por el usuario en el pasado, pero no puede ser usada para cifrar datos. Esto tampoco afecta a la capacidad de descifrar mensajes que hayan sido cifrados con la clave antes de su revocaci n, siempre y cuando el usuario todav a tenga acceso a la clave privada. javier:~$ gpg --output D58711B7.asc --gen-revoke 0xD58711B7 sec 1024D/D58711B7 1999-09-24 Javier (Paramo S.L.) El argumento miclave debe ser un especificador de clave, ya sea ste el identificador de clave ("key ID") del par primario del usuario, o ya sea cualquier otra parte de un identificador de usuario ("user ID") que identifique el par de claves del susodicho usuario. El certificado que se genere se encontrar en el fichero revoke.asc. Si se omite la opci n --output, el resultado se pondr en la salida t pica. Dado que el certificado es corto, es posible que el usuario desee imprimir una copia en papel del certificado para guardarla en alg n sitio seguro, como por ejemplo una caja fuerte de seguridad. El certificado no deber a ser guardado en lugares a los que otros puedan tener acceso, ya que cualquiera podr a hacer p blico el certificado de revocaci n e inutilizar la correspondiente clave p blica. ------------------------------------------------------------------------------- Intercambiar claves Para poder comunicarse con otros, el usuario debe intercambiar las claves p blicas. Para obtener una lista de las claves en el fichero ( anillo ) de claves p blicas, se puede usar la opci n de la l nea de rdenes --list-keys. javier:~$ gpg --list-keys /home/javier/.gnupg/pubring.gpg -------------------------------- pub 1024D/D58711B7 1999-09-24 Javier (Paramo S.L.) sub 1024g/92F6C9E3 1999-09-24 ------------------------------------------------------------------------------- Exportar una clave p blica Para poder enviar una clave p blica a un interlocutor, antes hay que exportarla. Para ello se usar la opci n de la l nea de rdenes --export. Es necesario un argumento adicional para poder identificar la clave p blica que se va a exportar. Como en la opci n anterior --gen-revoke, hay que usar el identificador de clave o cualquier parte del identificador de usuario para identificar la clave que se desea exportar. javier:~$ gpg --output javi.gpg --export javier@casa.es La clave se exporta en formato binario, y esto puede no ser conveniente cuando se env a la clave por correo electr nico o se publica en una p gina web. Por tanto, GnuPG ofrece una opci n de la l nea de rdenes --armor[5] que fuerza que la salida de la orden sea generada en formato armadura-ASCII, parecido a los documentos codificados con uuencode. Por regla general, cualquier salida de una orden de GnuPG, v.g.. claves, documentos cifrados y firmas, pueden ir en formato armadura-ASCII a adiendo a la orden la opci n --armor. javier:~$ gpg --armor --output javi.asc --export javier@casa.es -----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 p blica Se puede a adir una clave p blica al anillo de claves p blicas mediante la opci n --import. javier:~$ gpg --import arancha.gpg gpg: key B63E132C: public key imported gpg: Total number processed: 1 gpg: imported: 1 javier:~$ gpg --list-keys /home/javier/.gnupg/pubring.gpg -------------------------------- pub 1024D/D58711B7 1999-09-24 Javier (Paramo S.L.) sub 1024g/92F6C9E3 1999-09-24 pub 1024D/B63E132C 1999-09-24 Aranzazu (A.G.deZ.) sub 1024g/581A915F 1999-09-24 Una vez que la clave haya sido importada, es necesario validarla. GnuPG usa un potente y flexible modelo de confianza 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 verificando la huella digital de la clave, y firmando dicha clave para certificar su validez. La huella digital se puede ver con la opci n de la l nea de rdenes --fingerprint, pero para certificar la clave hay que editarla. javier:~$ gpg --edit-key arancha@nav.es pub 1024D/B63E132C created: 1999-09-24 expires: never trust: -/q sub 1024g/581A915F created: 1999-09-24 expires: never (1) Aranzazu (A.G.deZ.) Command> fpr pub 1024D/B63E132C 1999-09-24 Aranzazu (A.G.deZ.) Fingerprint: 4203 82E2 448C BD30 A36A 9644 0612 8A0F B63E 132C La huella digital de una clave se verifica con el propietario de la clave. Esto puede hacerse en persona o por tel fono, o por medio de otras maneras, siempre y cuando el usuario pueda garantizar que la persona con la que se est comunicando sea el aut ntico 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 posesi n de una copia correcta de la clave. Despu s de comprobar la huella digital ya se puede firmar la clave con el fin de validarla. Debido a que la verificaci n es un punto d bil en criptograf a de clave p blica, es aconsejable ser cuidadoso en extremo y siempre comprobar la huella digital de una clave con la que nos d el propietario antes de firmar 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.) Are you really sure that you want to sign this key with your key: "Javier (Paramo S.L.) " Really sign? y You need a passphrase to unlock the secret key for user: "Javier (Paramo S.L.) " 1024-bit DSA key, ID D58711B7, created 1999-09-24 Enter passphrase: Una vez firmada, el usuario puede comprobar la clave para obtener un listado de las firmas que lleva y para ver la firma que le acaba de a adir. Cada identificador de usuario tendr una o m s autofirmas, as como una firma por cada usuario que haya validado la clave en cuesti n. Command> check uid Aranzazu (A.G.deZ.) sig! B63E132C 1999-09-24 [self-signature] sig! D58711B7 1999-09-24 Javier (Paramo S.L.) Command> quit ------------------------------------------------------------------------------- Cifrar y descifrar documentos Cada clave p blica y privada tiene un papel espec fico en el cifrado y descifrado de documentos. Se puede pensar en una clave p blica como en una caja fuerte de seguridad. Cuando un remitente cifra un documento usando una clave p blica, ese documento se pone en la caja fuerte, la caja se cierra, y el bloqueo de la combinaci n de sta se gira varias veces. La parte correspondiente a la clave privada, esto es, el destinatario, es la combinaci n que puede volver a abrir la caja y retirar el documento. Dicho de otro modo, s lo la persona que posee la clave privada puede recuperar un documento cifrado usando la clave p blica 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 har a usando la clave p blica de Javier, y l lo descifrar a con su propia clave privada. Si Javier quisiera enviar un mensaje al usuario, lo har a con la clave p blica del usuario, y ste lo descifrar a con su propia clave privada. Para cifrar un documento se usa la opci n --encrypt. El usuario debe tener las claves p blicas 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 t pica. El resultado cifrado se coloca en la salida t pica o donde se haya especificado mediante la opci n --output. El documento se comprime como medida adicional de seguridad, aparte de cifrarlo. javier:~$ gpg --output doc.gpg --encrypt --recipient arancha@nav.es doc La opci n --recipient se usa una vez para cada destinatario, y lleva un argumento extra que especifica la clave p blica con la que ser cifrado el documento. El documento cifrado s lo puede ser descifrado por alguien con una clave privada que complemente uno de las claves p blicas 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 p blica en la lista de destinatarios. Para descifrar un mensaje se usa la opci n --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 --output doc --decrypt doc.gpg You need a passphrase to unlock the secret key for user: "Aranzazu (A.G.deZ.) " 1024-bit ELG-E key, ID 581A915F, created 1999-09-24 (main key ID B63E132C) Enter passphrase: Tambi n es posible cifrar documentos sin usar criptograf a de clave p blica. En su lugar, se puede usar s lo una clave de cifrado sim trico para cifrar el documento. La clave que se usa para el cifrado sim trico deriva de la contrase a dada en el momento de cifrar el documento, y por razones de seguridad, no debe ser la misma contrase a que se est usando para proteger la clave privada. El cifrado sim trico es til para asegurar documentos cuando no sea necesario dar la contrase a a otros. Un documento puede ser cifrado con una clave sim trica usando la opci n --symmetric. javier:~$ gpg --output doc.gpg --symmetric doc Enter passphrase: ------------------------------------------------------------------------------- Firmar y verificar firmas Una firma digital certifica un documento y le a ade una marca de tiempo. Si posteriormente el documento fuera modificado en cualquier modo, el intento de verificar la firma fallar a. La utilidad de una firma digital es la misma que la de una firma escrita a mano, s lo que la digital tiene una resistencia a la falsificaci n. Por ejemplo, la distribuci n del c digo fuente de GnuPG viene firmada con el fin de que los usuarios puedan verificar que no ha habido ninguna manipulaci n o modificaci n al c digo fuente desde que fue archivado. Para la creaci n y verificaci n de firmas, se utiliza el par p blico y privado de claves en una operaci n que es diferente a la de cifrado y descifrado. Se genera una firma con la clave privada del firmante. La firma se verifica por medio de la clave p blica correspondiente. Por ejemplo, Javier har a uso de su propia clave privada para firmar digitalmente la entrega de su ltima ponencia a la Revista de Qu mica Inorg nica. El editor asociado que la recibiera, usar a la clave p blica de Javier para comprobar la firma, verificando de este modo que el env o proviene realmente de Javier, y que no ha sido modificado desde el momento en que Javier lo firm . Una consecuencia directa del uso de firmas digitales es la dificultad en negar que fue el propio usuario quien puso la firma digital, ya que ello implicar a que su clave privada ha sido puesta en peligro. La opci n de l nea de rdenes --sign se usa para generar una firma digital. El documento que se desea firmar es la entrada, y la salida es el documento firmado. javier:~$ gpg --output doc.sig --sign doc You need a passphrase to unlock the private key for user: "Javier (Paramo S.L.) " 1024-bit DSA key, ID D58711B7, created 1999-09-24 Enter passphrase: El documento se comprime antes de ser firmado, y la salida es en formato binario. Con un documento con firma digital el usuario puede llevar a cabo dos acciones: comprobar s lo la firma o comprobar la firma y recuperar el documento original al mismo tiempo. Para comprobar la firma se usa la opci n --verify. Para verificar la firma y extraer el documento se usa la opci n --decrypt. El documento con la firma es la entrada, y el documento original recuperado es la salida. arancha% gpg --output doc --decrypt doc.sig gpg: Signature made Fri Sep 24 12:02:38 1999 CDT using DSA key ID D58711B7 gpg: Good signature from "Javier (Paramo S.L.) " ------------------------------------------------------------------------------- Documentos con firmas ASCII Las firmas digitales suelen usarse a menudo para firmar mensajes de correo electr nicos o en los grupos de noticias. En estas situaciones no se debe comprimir el documento al firmarlo, ya que para aquellos que no dispongan de un sistema para procesarlo ser a ininteligible. javier:~$ gpg --clearsign doc You need a passphrase to unlock the secret key for user: "Javier (Paramo S.L.) " 1024-bit DSA key, ID D58711B7, created 1999-09-24 -----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 acompa antes Un documento firmado tiene una utilidad limitada. Los otros usuarios deben recuperar la versi n original del documento de la versi n firmada, y aun en el caso de los documento firmados en ASCII, el documento firmado debe ser editado para poder recuperar el original. Por tanto, existe un tercer m todo para firmar un documento, que genera una firma acompa ante. Para generar una firma acompa ante se usa la opci n --detach-sig. javier:~$ gpg --output doc.sig --detach-sig doc You need a passphrase to unlock the secret key for user: "Javier (Paramo S.L.) " 1024-bit DSA key, ID D58711B7, created 1999-09-24 Enter passphrase: Tanto el documento como la firma acompa ante son necesarios para poder verificar la firma. La opci n --verify se usar para comprobar la firma. arancha% gpg --verify doc.sig doc gpg: Signature made Fri Sep 24 12:38:46 1999 CEST using DSA key ID D58711B7 gpg: Good signature from "Javier (Paramo S.L.) " ------------------------------------------------------------------------------- Cap tulo 2. Conceptos GnuPG utiliza varios conceptos criptol gicos que incluyen sistemas de cifrado sim trico, sistemas de cifrado de clave p blica, 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 cap tulo es una introducci n a los conceptos b sicos de la criptograf a usada en GnuPG. Para una lectura m s detallada sobre esta materia, existen otros libros. Un buen libro para alcanzar un conocimiento m s avanzado es Bruce Schneier's ``Applied Cryptography''. ------------------------------------------------------------------------------- Sistemas de cifrado sim trico Un sistema de cifrado sim trico es un tipo de cifrado que usa una misma clave para cifrar y para descifrar. Las dos partes que se comunican mediante el cifrado sim trico deben estar de acuerdo en la clave a usar de antemano. Una vez de acuerdo, el remitente cifra un mensaje usando la clave, lo env a al destinatario, y ste lo descifra usando la misma clave. Como ejemplo de sistema sim trico est Enigma ; ste es un sistema que fue usado por Alemania, en el que las claves se distribu an a diario en forma de libros de c digos. Cada d a, un operador de radio, receptor o transmisor, consultaba su copia del libro de c digos para encontrar la clave del d a. Todo el tr fico enviado por ondas de radio durante aquel d a era cifrado y descifrado usando las claves del d a. Algunos ejemplos actuales de algoritmos sim tricos son 3DES, Blowfish e IDEA. Un buen sistema de cifrado pone toda la seguridad en la clave y ninguna en el algoritmo. En otras palabras, no deber a ser de ninguna ayuda para un atacante conocer el algoritmo que se est usando. S lo si el atacante obtuviera la clave, le servir a 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 dif cil 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 hab a en torno a l, llevaba encima un juego de herramientas que inclu an un estetoscopio. En realidad, utilizaba una gran variedad de trucos para reducir a un peque o n mero la cantidad de combinaciones que deb a probar, y a partir de ah simplemente probaba hasta que adivinaba la combinaci n correcta. En otras palabras, reduc a el tama o de posibilidades de claves. Inglaterra us m quinas para adivinar las claves durante la Segunda Guerra Mundial. El sistema alem n Enigma estaba provisto de un amplio abanico de claves, pero los ingleses dise aron m quinas de c mputo especializado, los Bombes, para probar las claves de un modo mec nico hasta que la clave del d a era encontrada. Esto significaba que algunas veces encontraban la clave del d a unas pocas horas despu s de que sta fuera puesta en uso, pero tambi n que otros d as no pod an encontrar la clave correcta. Los Bombes no fueron m quinas de c mputo general, sino los precursores de las computadoras (ordenadores) de hoy en d a. Hoy por hoy, los ordenadores pueden adivinar claves con extrema rapidez, y sta es la raz n por la cual el tama o de la clave es importante en los criptosistemas modernos. El algoritmo de cifrado DES usa una clave de 56 bits, lo que significa que hay 2^56 claves posibles. 2^56 son 72.057.594.037.927.936 claves. Esto representa un n mero muy alto de claves, pero una m quina computadora de uso general puede comprobar todo el espacio posible de claves en cuesti n de d as. Un m quina especializada lo puede hacer en horas. Por otra parte, algoritmos de cifrado de dise o m s reciente como 3DES, Blowfish e IDEA usan todos claves de 128 bits, lo que significa que existen 2^128 claves posibles. Esto representa muchas, much simas m s claves, y aun en el caso de que todas las m quinas del planeta estuvieran cooperando, todav a tardar an m s tiempo que la misma edad del universo en encontrar la clave. ------------------------------------------------------------------------------- Sistemas de cifrado asim trico El principal problema con los sistemas de cifrado sim trico 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 comunicaci n que sea seguro han usado para comunicar la clave entre ellos? Ser a mucho m s f cil para un atacante intentar interceptar una clave que probar las posibles combinaciones del espacio de claves. Otro problema es el n mero de claves que se necesitan. Si tenemos un n mero 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 ser a imposible llevarlo a cabo con grupos m s grandes. Los sistemas de cifrado de clave p blica se inventaron con el fin de evitar por completo el problema del intercambio de claves. Un sistema de cifrado de clave p blica usa un par de claves para el env o de mensajes. Las dos claves pertenecen a la misma persona a la que se ha enviado el mensaje. Una clave es p blica 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 p blica del destinatario para cifrar el mensaje, y una vez cifrado, s lo 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 sim tricos. 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 comunicaci n secreta, el remitente consiga una copia de la clave p blica del destinatario. Es m s, esa misma clave p blica puede ser usada por cualquiera que desee comunicarse con su propietario. Por tanto, se necesitar n s lo n pares de claves por cada n personas que deseen comunicarse entre ellas. Los sistemas de cifrado de clave p blica se basan en funciones-trampa de un s lo sentido. Una funci n de un s lo sentido es aqu lla cuya computaci n es f cil, mientras que invertir la funci n es extremadamente dif cil. Por ejemplo, es f cil multiplicar dos m meros primos juntos para sacar uno compuesto, pero es dif cil factorizar uno compuesto en sus componentes primos. Una funci n-trampa de un sentido es algo parecido, pero tiene una trampa. Esto quiere decir que si se conociera alguna pieza de la informaci n, ser a f cil computar el inverso. Por ejemplo, si tenemos un n mero compuesto por dos factores primarios y conocemos uno de los factores, es f cil computar el segundo. Dado un cifrado de clave p blica basado en factorizaci n de n meros primos, la clave p blica contiene un n mero 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 f cil si poseemos la clave privada que contiene uno de los factores, pero extremadamente dif cil en caso contrario. Como con los sistemas de cifrado sim tricos buenos, con un buen sistema de cifrado de clave p blica toda la seguridad descansa en la clave. Por lo tanto el tama o de la clave es una medida del seguridad del sistema, pero no se puede comparar el tama o del cifrado sim trico con el de un cifrado de clave p blica para medir la seguridad. En un ataque de fuerza bruta sobre un cifrado sim trico con una clave de un tama o de 80 bits, el atacante debe enumerar hasta 2^ 81-1 claves para encontrar la clave correcta. En un ataque de fuerza bruta sobre un cifrado de clave p blica con un clave de un tama o de 512 bits, el atacante debe factorizar un n mero compuesto codificado en 512 bits (hasta 155 d gitos decimales). La cantidad de trabajo para el atacante ser diferente dependiendo del cifrado que est atacando. Mientras 128 bits es suficiente para cifrados sim tricos, dada la tecnolog a de factorizaci n de hoy en d a, se recomienda el uso de claves p blicas de 1024 bits para la mayor a de los casos. ------------------------------------------------------------------------------- Sistemas de cifrado h bridos Los cifrados de clave p blica no son ninguna panacea. Muchos cifrados sim tricos son m s fuertes desde un punto de vista de seguridad, y el cifrado y descifrado con clave p blica son m s caros que las correspondientes operaciones en sistemas sim tricos. De todos modos, los cifrados de clave p blica son una herramienta efectiva para distribuir claves de cifrado sim trico, y de esta manera es como se usan en sistemas de cifrado h bridos. Un sistema de cifrado h brido usa tanto un cifrado sim trico como uno asim trico. Funciona mediante el uso de un cifrado de clave p blica para compartir una clave para el cifrado sim trico. El mensaje que se est enviando en el momento, se cifra usando la clave y envi ndolo al destinatario. Ya que compartir una clave sim trica no es seguro, la clave usada es diferente para cada sesi n. Tanto PGP como GnuPG usan sistemas de cifrado h bridos. La clave de sesi n es cifrada con la clave p blica, y el mensaje saliente es cifrado con la clave sim trica, todo combinado autom ticamente en un s lo paquete. El destinatario usa su clave privada para descifrar la clave de sesi n y acto seguido usa la clave de sesi n para descifrar el mensaje. Un sistema de cifrado h brido no es m s fuerte que el de cifrado asim trico o el de cifrado sim trico de los que hace uso, cualquiera que de los dos que sea el m s d bil. En PGP y GnuPG el sistema de clave p blica es probablemente la parte m s d bil de la combinaci n. Sin embargo, si un atacante pudiera descifrar un clave de sesi n, s lo ser a til para poder leer un mensaje, el cifrado con esa clave de sesi n. El atacante tendr a que volver a empezar y descifrar otra clave de sesi n para poder leer cualquier otro mensaje. ------------------------------------------------------------------------------- Firmas digitales Una funci n `hash' es una funci n m ltiple que asigna su entrada a un valor dentro de un grupo finito. Por regla general este grupo es un rango de n meros naturales. Un modelo simple de funci n `hash' es f(x) = 0 para todo entero x. Una funci n hash m s interesante es f(x) = x mod 37, que asigna x al resto de la divisi n x entre 37. Una firma digital en un documento es el resultado de aplicar una funci n `hash' al documento. Para que sea de utilidad, la funci n `hash' necesita satisfacer dos propiedades importantes. Primero, deber a ser dif cil encontrar dos documentos cuyo valor para una funci n `hash' sea el mismo. Segundo, dado un valor `hash' deber a ser dif cil de recuperar el documento que produjo es valor. Algunos sistemas de cifrado de clave p blica[6] se pueden usar para firmar documentos. El firmante cifra el documento con su clave privada. Cualquiera que quiera comprobar la firma y ver el documento, no tiene m s que usar la clave p blica del firmante para descifrarla. Este algoritmo satisface las dos propiedades necesarias para una buena funci n de `hash', pero en la pr ctica 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 firma con una funci n `hash', y el valor del `hash' es la firma. Otra persona puede comprobar la firma aplicando tambi n una funci n `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 id nticos. Claro que el problema est en usar una funci n `hash' para firmas digitales que no permita que un atacante interfiera en la comprobaci n de la firma. Si el documento y la firma se enviaran descifrados, un atacante podr a modificar el documento y generar una firma correspondiente sin que lo supiera el destinatario. Si s lo se cifrara el documento, un atacante podr a manipular la firma y hacer que la comprobaci n de sta fallara. Una tercera opci n es usar un sistema de clave p blica h brido para cifrar tanto la firma como el documento. El firmante usa su clave p blica, y cualquiera puede usar su clave p blica para comprobar la firma y el documento. Esto suena bien, pero en realidad no tiene sentido. Si este algoritmo hiciera el documento seguro tambi n lo asegurar a de manipulaciones, y no habr a necesidad de firmarlo. El problema m s serio es que esto no protege de manipulaciones ni a la firma, ni al documento. Con este algoritmo, s lo la clave de sesi n del sistema de cifrado sim trico, es cifrada usando la clave privada del firmante. Cualquiera puede usar la clave p blica y recuperar la clave de sesi n. Por lo tanto, es sencillo para un atacante recuperar la clave de sesi n y usarla para cifrar documentos substitutos y firmas para enviarlas a terceros en nombre del remitente. Un algoritmo que funciona es aqu l que hace uso de un algoritmo de clave p blica para cifrar s lo la firma. En particular, el valor `hash' se cifra mediante el uso de la clave privada del firmante, de modo que cualquiera pueda comprobar la firma usando la clave p blica correspondiente. El documento firmado se puede enviar usando cualquier otro algoritmo de cifrado, o incluso ninguno si es un documento p blico. Si el documento se modifica, la comprobaci n de la firma fallar , pero esto es precisamente lo que la verificaci n se supone que debe descubrir. El "Digital Signature Standard" (DSA) es un algoritmo de firmado de clave p blica que funciona como hemos descrito. DSA es el algoritmo principal de firmado que se usa en GnuPG. ------------------------------------------------------------------------------- Cap tulo 3. Gesti n de Claves En criptograf a de clave p blica la manipulaci n de claves es un punto flaco a tener en cuenta. Un escucha podr a manipular los ficheros con las claves, o falsificar la clave p blica y hacerla p blica para que la usaran otros como si fuera la aut ntica. Por ejemplo, supongamos que Jordi quisiera monitorizar los mensajes que Javier env a a Arancha. Jordi podr a montar lo que se conoce como un intermediario en el plan de ataque. En este ataque Jordi crea una nuevo par de claves p blica y privada, reemplazando la clave p blica de Arancha que posee Javier con la nueva clave p blica. A partir de ah intercepta los mensajes que Javier env a a Arancha. Cada mensaje que intercepte lo descifrar usando la nueva clave privada, lo volver a cifrar con la clave aut ntica de Arancha, y reenviar el mensaje cifrado a Arancha. As , todos los mensajes que Javier env e a Arancha pueden ser le dos por Jordi. Una buena gesti n de claves es crucial para asegurarse, no s lo de la integridad de nuestros ficheros de claves, sino tambi n de la integridad de los anillos de claves de otros. El punto central en la gesti n de claves en GnuPG es la noci n que hay detr s de firmar las claves. Firmar las claves tiene dos prop sitos principales: nos permite detectar una manipulaci n en nuestros anillos de claves, y nos permite certificar que una clave realmente pertenece a la persona cuyo nombre aparece en el identificador de usuario de la clave. Las firmas de las claves tambi n se usan en un esquema conocido como anillo de confianza para hacer extensiva la certificaci n de claves que no han sido firmadas directamente por el usuario, sino que han sido firmadas por otros en los que l conf a. Un usuario responsable que lleve a cabo una buena gesti n de claves puede contrarrestar los efectos pr cticos de la manipulaci n de claves con GnuPG. ------------------------------------------------------------------------------- Gestionando nuestro par de claves Un par de claves se compone de una clave p blica y otra privada. Una clave p blica se compone de la parte p blica de la clave de firmado maestra, las partes p blicas de las subclaves de firmado y cifrado, y de un juego de identificadores de usuario que se usa para asociar la clave p blica con una persona real. Cada una de estas partes contiene datos sobre s misma. Para una clave estos datos constan de su propio identificador, fecha de creaci n, fecha de caducidad, etc... Para un identificador de usuario, estos datos constan del nombre de la persona a la que identifica, un comentario opcional, y una direcci n de correo electr nico. La estructura de la claves privada es parecida, con la diferencia de que s lo contiene las partes privadas de las claves, y que no tiene la informaci n del identificador de usuario. La opci n de la l nea de rdenes --edit-key se puede usar para ver un par de claves. Por ejemplo, jordi% gpg --edit-key jordi@cat.es Secret key is available. pub 1024D/1208DD4F created: 1999-09-24 expires: never trust: -/u sub 1024g/B9688D9E created: 1999-09-24 expires: never sub 2016G/4D88ACC4 created: 1999-09-26 expires: 2002-09-25 sub 960D/412EAF0C created: 1999-09-26 expires: 2002-09-25 (1) Jordi (Castell S.L.) (2) Jordi (oficina) Command> La clave p blica se muestra junto con una indicaci n sobre si la clave privada se encuentra disponible o no. La informaci n sobre cada componente de la clave p blica se da en una lista. La primera columna indica el tipo de la clave. La palabra clave pub identifica a la clave p blica maestra de firmado, y la palabra clave sub identifica a una clave p blica subordinada a la anterior. La segunda columna informa sobre el tama o en "bits" de la clave, el tipo, y el identificador. El tipo es D para una clave DSA, g para una clave ElGamal que s lo se pueda usar para cifrar, y G para una clave ElGamal que se pueda usar tanto para cifrar como para firmar. La fecha de creaci n y la fecha de caducidad se muestran en las columnas tres y cuatro. Los identificadores de usuario aparecen en una lista a continuaci n de las claves. Se puede obtener m s informaci n sobre la clave mediante rdenes interactivas. La orden toggle sirve para conmutar entre los componentes p blico y privado de un par de claves, siempre y cuando ambos componentes est n presentes. Command> toggle sec 1024D/1208DD4F created: 1999-09-24 expires: never sbb 1024g/B9688D9E created: 1999-09-24 expires: never sbb 960D/412EAF0C created: 1999-09-26 expires: 2002-09-25 sbb 2016G/4D88ACC4 created: 1999-09-26 expires: 2002-09-25 (1) Jordi (Castell S.L.) (2) Jordi (oficina) Esta informaci n es parecida a la del componente para la clave p blica. La palabra clave sec identifica a la clave privada maestra de firmado, y la palabra clave sbb identifica las claves subordinadas privadas. Los identificadores de usuario de la clave p blica tambi n aparecen en este caso. ------------------------------------------------------------------------------- Integridad de claves Al distribuir nuestra clave p blica, estamos distribuyendo los componentes p blicos de nuestras claves maestra y subordinada, as como los identificadores de usuario. Sin embargo, por s sola, la distribuci n de este material constituye un riesgo para la seguridad ya que ser a posible que un atacante manipulara la clave. Se puede modificar una clave p blica a adiendo o substituyendo claves, o a adiendo o cambiando los identificadores de usuario. Al manipular un identificador de usuario, el atacante podr a cambiar la direcci n de correo del identificador de usuario y redireccionar as el correo a su propia direcci n. Al cambiar una de las claves de cifrado el atacante tambi n podr a descifrar los mensajes que le llegaran redireccionados. El uso de las firmas digitales es una soluci n a este problema. Cuando unos datos son firmados por una clave privada, la clave p blica correspondiente queda ligada a los datos firmados. En otras palabras, s lo la clave p blica correspondiente puede verificar la firma y asegurar que los datos no han sido modificados. Una clave p blica se puede proteger de la manipulaci n usando su correspondiente clave privada maestra, y firmando con sta los componentes de la clave p blica y los identificadores de usuario, ligando de este modo los componentes a la clave p blica maestra. La acci n de firmar los componentes de la clave p blica con la correspondiente clave privada maestra se conoce como autofirmar, y una clave p blica que contenga identificadores de usuario autofirmados ligados a ella se llama certificado. Como ejemplo, si Jordi tuviera dos identificadores de usuario y tres subclaves, las firmas en los identificadores de usuario se podr an comprobar con la orden check desde el men de edici n de la clave. jordi% gpg --edit-key jordi Secret key is available. pub 1024D/1208DD4F created: 1999-09-24 expires: never trust: -/u sub 1024g/B9688D9E created: 1999-09-24 expires: never sub 960D/412EAF0C created: 1999-09-26 expires: 2002-09-25 sub 2016G/4D88ACC4 created: 1999-09-26 expires: 2002-09-25 (1) Jordi (Castell S.L.) (2) Jordi (oficina) Command> check uid Jordi (Castell S.L.) sig! 1208DD4F 1999-09-24 [self-signature] uid Jordi (oficina) sig! 1208DD4F 1999-09-26 [self-signature] Como era de esperar, la clave firmante para cada firma es la clave de firmado maestra con el identificador de clave 0x26B6AAE1. La autofirma en las subclaves se encuentra presente en la clave p blica, pero en la interfaz de GnuPG no aparece. ------------------------------------------------------------------------------- A adir y eliminar componentes a las claves Tanto las nuevas subclaves como los nuevos identificadores de usuario, pueden ser a adidos a nuestro par de claves una vez que ste ya haya sido creado. Un identificador de usuario se a ade mediante la orden adduid. A continuaci n se nos pedir que introduzcamos un nombre real, una direcci n de correo electr nico, y un comentario, del mismo modo que cuando generamos el par de claves inicial. Una subclave se a ade 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 firmado DSA y una clave s lo para cifrado ElGamal, o una clave para firmado y cifrado ElGamal. Cuando se genera una subclave o un identificador de usuario, stos son autofirmados con nuestra clave de firmado maestra, por lo que se nos requerir que introduzcamos la contrase a. Los identificadores de usuario adicionales son tiles si necesitamos m ltiples identidades. Por ejemplo, puede darse el caso de que utilicemos una identidad para el trabajo y otra para nuestras actividades pol ticas. Los colegas de trabajo nos conocer n por nuestro identificador de usuario del trabajo. Los correligionarios pol ticos nos conocer n por nuestra identidad de usuario pol tica. Como es posible que estos grupos de personas no coincidan, cada grupo no se fiar del identificador que no corresponda. Por lo tanto, ambos identificadores de usuario son necesarios. Las subclaves adicionales son tambi n muy tiles. Los identificadores de usuario asociados con nuestra clave p blica maestra son validados por las personas con quien nos comunicamos y por tanto, cambiar la clave maestra requiere recertificaci n . Pero esto puede resultar dif cil y una p rdida de tiempo si nos comunicamos con muchas personas. Por otra parte, es bueno cambiar las subclaves de cifrado peri dicamente. Si una clave es descubierta, todos los datos cifrados con esa clave ser n vulnerables. De todos modos, al cambiar las claves s lo los datos cifrados con la clave descubierta ser n revelados. Tambi n es posible eliminar las subclaves y los identificadores de usuario. Para eliminar una subclave o un identificador de usuario es preciso seleccionarlo primero con las rdenes key o uid respectivamente. Estas rdenes act an como conmutadores. Por ejemplo, la orden key 2 selecciona la segunda subclave, e invocando key 2 de nuevo, desactiva la selecci n. Si no se da ning n otro argumento extra, todas las subclaves o identificadores de usuario son deseleccionados. Una vez que los identificadores de usuario que se van a eliminar son seleccionados, la orden deluid elimina los identificadores de usuario de la clave. De igual forma, la orden delkey elimina todas las subclaves previamente seleccionadas de nuestras claves p blica y privada. En la gesti n local de anillos de claves, el eliminar componentes innecesarios de una clave es una buena pr ctica para aliviar los anillos de claves p blicas de otros. Sin embargo, eliminar identificadores de usuarios y subclaves de nuestra propia clave no es siempre conveniente, ya que puede complicar la distribuci n de la clave. Por definici n, cuando un usuario importa nuestra clave p blica actualizada sta se fusiona con la copia de la clave p blica vieja en su anillo de claves, siempre que la vieja est all a priori . Los componentes de ambas claves se combinan con la fusi n, y el resultado de sta es que se a ade cualquier nuevo componente, pero tambi n que se restaura cualquier componente eliminado. Para actualizar de manera correcta la clave es necesario que el usuario elimine primero la versi n antigua de nuestra clave, y despu s que importe la versi n nueva. Esto significa una carga extra para la gente con la que nos comunicamos. Es m s, si envi ramos nuestra clave a un servidor de claves la fusi n ocurrir a a nuestro pesar, y cualquiera que se bajara nuestra clave del servidor no ver a 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 a adi ndole una autofirma de revocaci n. Al contrario que la opci n de la l nea de rdenes --gen-revoke, el efecto de revocaci n de una subclave es inmediato. Command> key 4D88ACC4 pub 1024D/1208DD4F created: 1999-09-24 expires: never trust: -/u sub 1024g/B9688D9E created: 1999-09-24 expires: never sub* 2016G/4D88ACC4 created: 1999-09-26 expires: 2002-09-25 sub 960D/412EAF0C created: 1999-09-26 expires: 2002-09-25 (1) Jordi (Castell S.L.) (2) Jordi (oficina) 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.) " 1024-bit DSA key, ID 1208DD4F, created 1999-09-24 pub 1024D/1208DD4F created: 1999-09-24 expires: never trust: -/u sub 1024g/B9688D9E created: 1999-09-24 expires: never sub 2016G/4D88ACC4 created: 1999-09-26 expires: 2002-09-25 rev! subkey has been revoked: 1999-09-26 sub 960D/412EAF0C created: 1999-09-26 expires: 2002-09-25 (1) Jordi (Castell S.L.) (2) Jordi (oficina) La revocaci n de un identificador de usuario funciona de modo diferente. Generalmente, un identificador de usuario recolecta firmas que atestig en que el identificador de usuario describe a la persona que sea la aut ntica propietaria de la clave asociada. En teor a un identificador de usuario describe a una persona para siempre, ya que la identidad de esa persona no cambiar nunca. En la pr ctica los elementos del identificador de usuario, como la direcci n de correo electr nico y el comentario, pueden cambiar con el tiempo, invalidando as el identificador de usuario. Las especificaciones de OpenPGP no preveen la revocaci n del identificador de usuario, pero un identificador de usuario puede ser revocado de modo efectivo, revocando la autofirma en el identificador de usuario. Por razones de seguridad descritas anteriormente, los corresponsales no confiar n en un identificador de usuario con una autofirma no v lida. Una firma puede ser revocada mediante la orden revsig. Como es posible que hayamos firmado cualquier cantidad de identificadores de usuario, la interfaz nos pedir que decidamos si queremos o no revocar cada una de las firmas. Command> revsig Command> revsig You have signed these user IDs: Jordi (Castell S.L.) signed by 1208DD4F at 1999-09-24 Jordi (oficina) signed by 1208DD4F at 1999-09-26 user ID: "Jordi (Castell S.L.) " signed with your key 1208DD4F at 1999-09-24 Create a revocation certificate for this signature? (y/N)n user ID: "Jordi (oficina) " 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) 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.) " 1024-bit DSA key, ID 1208DD4F, created 1999-09-24 Enter passphrase: pub 1024D/1208DD4F created: 1999-09-24 expires: never trust: -/u sub 1024g/B9688D9E created: 1999-09-24 expires: never sub 2016G/4D88ACC4 created: 1999-09-26 expires: 2002-09-25 rev! subkey has been revoked: 1999-09-26 sub 960D/412EAF0C created: 1999-09-26 expires: 2002-09-25 (1) Jordi (Castell S.L.) (2) Jordi (oficina) Un identificador de usuario revocado vendr indicado por la firma de revocaci n en el identificador, y se podr ver en las firmas en la lista de identificadores de usuario de las claves. Command< check uid Jordi (Castell S.L.) sig! 1208DD4F 1999-09-24 [self-signature] uid Jordi (oficina) 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 autofirmas en los identificadores de usuarios, a adimos autofirmas de revocaci n a la clave. Ya que las firmas son a adidas a la clave y no eliminamos nada, una revocaci n siempre estar visible para otros usuarios desde el momento en el que la actualizaci n de nuestra clave p blica sea distribuida y fusionada con las copias m s viejas de sta. Por lo tanto, la revocaci n garantiza que todos los usuarios tengan una copia consistente de nuestra clave p blica. ------------------------------------------------------------------------------- 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 edici n 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 autofirma de la clave. La fecha de caducidad se actualiza eliminando la autofirma antigua y a adiendo una nueva autofirma. Ya que los corresponsales no habr n eliminado la autofirma antigua, ver n una autofirma adicional en la clave cuando actualicen su copia de nuestra clave. La ltima autofirma es la que tiene precedencia, as que todos los corresponsales pueden saber sin ambig edad las fechas de caducidad de nuestras claves. ------------------------------------------------------------------------------- Validar otras claves en nuestro anillo de claves p blicas En el cap tulo 1 se introdujo un procedimiento para validar las claves p blicas de otros usuarios: la clave de otro usuario se valida comprobando personalmente la huella digital de su clave, y firmando su clave p blica con nuestra clave privada. Comprobando personalmente la huella digital podemos estar seguros de que la clave pertenece realmente al supuesto usuario y, dado que hemos firmado la clave, podemos estar seguros de que detectaremos cualquier manipulaci n o falsificaci n en un futuro. Desafortunadamente este proceso se complicado cuando debemos validar un gran n mero 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 confianza. En el modelo del anillo de confianza la responsabilidad de la validaci n de las claves p blicas recae en las personas en las que confiamos. Por ejemplo, supongamos que * Javier ha firmado la clave de Arancha y que, * Arancha ha firmado las claves de Jordi y de Ignacio. Si Javier conf a en Arancha lo suficiente como para validar las claves que l firma, entonces Javier puede deducir que las claves de Jordi y de Ignacio son v lidas sin llegar a comprobarlas personalmente. Javier se limitar a usar su copia validada de la clave p blica de Arancha para comprobar que las firmas de Arancha sobre Jordi e Ignacio son aut nticas. Por lo general, y asumiendo que Javier conf e plenamente en todos como para validar las claves que firmen, cualquier clave firmada por una clave v lida tambi n es considerada v lida. El origen es la clave de Javier, que se asumir axiom ticamente como v lida. ------------------------------------------------------------------------------- Confianza en el propietario de una clave En la pr ctica la confianza es algo subjetivo. Por ejemplo, la clave de Arancha es v lida para Javier ya que ha sido firmada por ella, pero Javier puede desconfiar de otras claves que hayan sido validadas por la firma de Arancha. En este caso, Javier no aceptar a las claves de Jordi e Ignacio como v lidas s lo porque hayan sido firmadas por Arancha. El modelo del anillo de confianza prevee este caso mediante un indicador que asocia nuestro nivel de confianza en el propieario de la clave, a cada clave p blica en nuestro anillo de claves. Existen cuatro niveles de confianza: unknown Desconocido. No se sabe nada sobre el due o de la clave firmante. Las claves en nuestro anillo de claves que no nos pertenezcan tendr n al principio este nivel de confianza. none Ninguno. Se sabe que el propietario firma otras claves de modo impropio. marginal Marginal. El propietario comprende las implicaciones de firmar una clave y valida las claves de forma correcta antes de firmarlas. full Absoluto. El propietario comprende perfectamente las implicaciones de firmar una clave y su firma sobre una clave es tan buena como la nuestra. El nivel de confianza en una clave es algo que s lo nosotros podemos asignar a la clave, y se considera informaci n privada. El nivel de confianza no se exporta con la clave, 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 confianza en el propietario de una clave. La orden es trust. En el siguiente ejemplo Javier edita su confianza en Arancha y actualiza la base de datos para recomputar qu claves son v lidas, bas ndose en su nuevo nivel de confianza en Arancha. javier:~$ gpg --edit-key Aranzanzu pub 1024D/B63E132C created: 1999-09-24 expires: never trust: q/f sub 1024g/581A915F created: 1999-09-24 expires: never (1) Ar\xc3\xa1nzazu (A.G.deZ.) Command> trust pub 1024D/B63E132C created: 1999-09-24 expires: never trust: q/f sub 1024g/581A915F created: 1999-09-24 expires: never (1) Ar\xc3\xa1nzazu (A.G.deZ.) Please decide how far you trust this user to correctly verify other users' keys (by looking at passports, checking fingerprints from different sources...)? 1 = Don't know 2 = I do NOT trust 3 = I trust marginally 4 = I trust fully s = please show me more information m = back to the main menu Your decision? 3 pub 1024D/B63E132C created: 1999-09-24 expires: never trust: m/f sub 1024g/581A915F created: 1999-09-24 expires: never (1) Ar\xc3\xa1nzazu (A.G.deZ.) Command> quit [...] La confianza en el propietario de la clave y la validez de la clave se indican a la derecha al mostrar la clave. La confianza en el propietario se muestra primero, y la validez despu s[7]. Los cuatro niveles de confianza/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 v lida ya que est firmada por Javier. Al principio el nivel de confianza que Javier tiene en Arancha es desconocido, por lo que no procede validar otras claves; pero luego decide confiar en ella de modo marginal. ------------------------------------------------------------------------------- Usar la confianza para validar las claves El anillo de confianza permite usar un algoritmo m s elaborado para validar una clave. Anteriormente, una clave s lo se consideraba v lida si la firm bamos nosotros personalmente. Ahora es posible usar un algoritmo m s flexible: una clave K se considera v lida si cumple dos condiciones: 1. si viene firmada por las suficientes claves v lidas, lo que quiere decir + que la hemos firmado nosotros personalmente, + o que ha sido firmada por una clave de plena confianza, + o que ha sido firmada por tres claves de confianza marginal; 2. y si el camino de claves firmadas que nos lleva desde K hasta nuestra propia clave es de cinco pasos o menos. La longitud del camino, en n mero de claves con confianza marginal requeridas, y el n mero de claves con confianza plena requeridas se pueden cambiar. Los n meros dados arriba son los valores por definici n usados por GnuPG. Figura 3-1 muestra un anillo de confianza cuyo origen est en Javier. El gr fico ilustra qui n ha firmado las claves de qui n. La tabla muestra qu claves son consideradas v lidas por Javier en base a su confianza en otros miembros del anillo. Este ejemplo asume que se necesitan dos claves de confianza marginal o una de confianza plena para validar otra clave. La longitud m xima del camino es tres. Al computar claves v lidas en el ejemplo, las de Arancha e Ignacio siempre son consideradas como totalmente v lidas, ya que est n directamente firmadas por Javier. La validez de las otras claves depende de la confianza. En el primer caso la confianza en Ignacio es plena, lo que implica que las claves de Jordi y Claudia se considerar n v lidas. En el segundo ejemplo la confianza en Arancha e Ignacio es marginal. Ya que son necesarias dos claves de confianza marginal para dar validez total a una clave, la clave de Jordi ser considerada como totalmente v lida, pero la clave de Claudia ser considerada s lo como marginalmente v lida. En el caso en el que Jordi e Ignacio tuvieran confianza marginal, la clave de Jordi ser a marginalmente v lida ya que la clave de Ignacio es totalmente v lida. Sin embargo, la clave de Claudia ser considerada marginalmente v lida ya que s lo se puede usar una clave completamente v lida para validar otras claves, y la clave de Ignacio es la nica clave v lida que se ha usado para firmar la clave de Claudia. Al a adir un nivel de confianza marginal a Arancha, la clave de Jordi se convierte en totalmente v lida y por tanto puede ser usada para validar totalmente la clave de Claudia, y validar marginalmente la clave de Jimena. Por ltimo, una confianza plena en Arancha, Jordi y Jimena es todav a insuficiente para validar la clave de Gonzalo ya que el camino m ximo de certificaci n es tres, pero la longitud del camino desde Gonzalo hasta Javier es cuatro. El modelo del anillo de confianza es una aproximaci n flexible al problema del intercambio seguro de claves p blicas. Nos permite poner a punto GnuPG para que refleje el modo en que lo usamos. Es posible llegar a insistir en m ltiples caminos cortos desde nuestra clave hasta otra clave K para cambiar el nivel de confianza. Por otra parte, puede ser que caminos m s largos nos satisfagan e incluso un s lo camino desde nuestra clave hasta la otra clave K. El requerimiento de m ltiples caminos cortos es una fuerte garant a de que K pertenece a quien nosotros creemos. El precio, por supuesto, es la dificultad a adida para validar claves, ya que debemos firmar personalmente m s claves que si acept ramos menos y m s largos caminos. Figura 3-1. Un anillo de confianza hipot tico [signatures] +-----------------------------------------------------------------------------+ | trust/confianza | validity/validez | |--------------------------------------+--------------------------------------| | marginal | full/plena | marginal | full/plena | |-------------------+------------------+-----------+--------------------------| | |Ignacio | |Arancha, Jordi, Ignacio, | | | | |Claudia | |-------------------+------------------+-----------+--------------------------| |Arancha, Ignacio | |Claudia |Arancha, Jordi, Ignacio | |-------------------+------------------+-----------+--------------------------| |Jordi, Ignacio | |Jordi, |Arancha, Ignacio | | | |Claudia | | |-------------------+------------------+-----------+--------------------------| |Arancha, Jordi, | |Jimena |Arancha, Jordi, Ignacio, | |Ignacio | | |Claudia | |-------------------+------------------+-----------+--------------------------| | |Arancha, Jordi, | |Arancha, Jordi, Jimena, | | |Jimena | |Claudia | +-----------------------------------------------------------------------------+ ------------------------------------------------------------------------------- Distribuci n de claves Lo ideal ser a que pudi ramos distribuir nuestra clave entreg ndosela en persona a nuestros corresponsales. Sin embargo, en la pr ctica las claves se distribuyen a menudo por correo electr nico o alg n otro medio de comunicaci n electr nica. La distribuci n por correo electr nico es una buena pr ctica s lo cuando tengamos unos pocos corresponsales, e incluso si tuvi ramos muchos corresponsales, podr amos usar un medio alternativo como puede ser publicar nuestra clave p blica en nuestra p gina en internet. Pero esto es in til si las personas que necesitan nuestra clave p blica no saben d nde encontrar nuestra p gina. Para solventar este problema existen los servidores de claves p blicas que recolectan y distribuyen las claves p blicas. Cuando un servidor recibe una clave p blica, bien la a ade a la base de datos o bien la fusiona con una copia de la clave. Cuando alguien requiere al servidor una clave p blica, ste la busca en la base de datos y, si la encuentra, la env a a quien se la haya solicitado. Los servidores de claves tambi n son tiles cuando hay muchas personas que firman las claves de otras con frecuencia. Sin un servidor de claves, cuando Arancha firmara la clave de Javier, deber a enviar a ste una copia de la clave firmada por ella de manera que Javier pudiera a adir la clave firmada a su anillo de claves, as como distribuirla a todos sus corresponsales. Mediante este proceso Javier y Arancha sirven a la totalidad de la comunidad construyendo lazos en forma de anillos de confianza o lo que es lo mismo, mejorando la seguridad de PGP. De todos modos esto es una molestia si se firman las claves con frecuencia. El uso de un servidor de claves facilita este proceso. Despu s de firmar la clave de Javier, Arancha puede enviar la copia firmada por ella al servidor de claves. El servidor de claves a ade la firma de Arancha a la copia que ya existente de la clave p blica de Javier. Las personas que est n interesadas en actualizar su copia de la clave de Javier consultan al servidor por propia iniciativa para obtener la clave actualizada. Javier no necesita distribuir la clave y puede obtener las firmas en su clave requiri ndolas al servidor. Se puede enviar una o m s claves usando la opci n de la l nea de rdenes --send-keys. Esta opci n toma uno o m s especificadores de clave, y env a las claves especificadas al servidor de claves. El servidor al que se env an las claves es especificado con la opci n de la l nea de orden --keyserver. Paralelamente, la opci n --recv-keys se usa para obtener claves desde un servidor de claves, pero la opci n --recv-keys requiere el uso de un identificador de clave para poder especificar la clave deseada. En el siguiente ejemplo Javier actualiza su clave p blica con nuevas firmas desde el servidor de claves certserver.pgp.com y acto seguido env a su copia de la clave p blica de Arancha al mismo servidor de claves para que se actualice con las claves que l mismo pueda haber a adido. javier:~$ gpg --keyserver certserver.pgp.com --recv-key D58711B7 gpg: requesting key D58711B7 from certserver.pgp.com ... gpg: key D58711B7: 1 new signature gpg: Total number processed: 1 gpg: new signatures: 1 javier:~$ gpg --keyserver certserver.pgp.com --send-key arancha@nav.es gpg: success sending to 'certserver.pgp.com' (status=200) Existen varios servidores de claves en funcionamiento en todo el mundo. Los servidores m s importantes est n 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. ------------------------------------------------------------------------------- Cap tulo 4. Uso diario de GnuPG GnuPG es una compleja herramienta que no est exenta de pol mica t cnica, social y legal. En el plano t cnico, ha sido dise ada para su uso en situaciones con diversos requerimientos de seguridad. Esto complica la gesti n de claves. En el plano social, el uso de GnuPG no es estricatamente una decisi n de tipo personal. Para que su uso tenga efectividad, GnuPG requiere que todas las partes en una comunicaci n sean usuarios del programa. En el plano legal, desde 1.999, las leyes que contemplan el uso de productos inform ticos criptol gicos, y en particular si el uso de GnuPG es legal, son diferentes seg n los pa ses y est n siendo actualmente debatidas por muchos gobiernos. Este cap tulo tratar sobre estos temas. Se intentar dar consejos pr cticos sobre el uso de GnuPG de cara a los requerimientos de seguridad del usuario. Tambi n se sugerir n v as para promocionar el uso de GnuPG con vistas a la comunicaci n 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 criptolog a y cifrado en el mundo. ------------------------------------------------------------------------------- Definiendo los requerimientos en seguridad GnuPG es una herramienta que utiliza el usuario para proteger su privacidad. La protecci n existe s lo 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 determinaci n y de los recursos de aqu llos que intenten, o puedan intentar, leer los mensajes cifrados del usuario. Un escucha podr a ser un administrador de sistemas sin escr pulos, que se encuentre, por casualidad , escaneando el correo del usuario, o podr a ser un esp a industrial que intentara acceder a los secretos de una compa a, o incluso podr a 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 fin ltimo debe ser el de que el conseguir los datos no cifrados resulte m s caro que el valor de los datos en s . La personalizaci n del uso de GnuPG se basa en los siguientes aspectos: * la elecci n del tama o del par de claves p blico y privado. * la protecci n de la clave privada, * la selecci n de la fecha de caducidad y el uso de subclaves, y * la gesti n del anillo de confianza. Una buena elecci n del tama o de la clave nos proteger contra ataques de fuerza bruta en los mensajes cifrados. La protecci n de nuestra clave privada ayudar a prevenir que un atacante pueda llegar a usarla para descifrar mensajes o firmar mensajes en nuestro nombre. Una gesti n correcta de nuestro anillo de confianza, ayudar a evitar que cualquier atacante pueda hacerse pasar por una persona de nuestra confianza. La consecuci n de estos aspectos seg n 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. ------------------------------------------------------------------------------- Selecci n del tama o de la clave La selecci n del tama o de la clave depende de la clave en s . En OpenPGP, un par de claves p blica y privada contienen generaralmente claves m ltiples. Como m nimo tiene una clave de firmado maestra, y probablemente una o m s subclaves de cifrado adicionales. Si usamos para la generaci n de claves los par metros por defecto en GnuPG, la clave maestra ser una clave DSA, y las subclaves ser n claves ElGamal. DSA nos permite un tama o de clave de hasta 1024 bits. Dada la tecnolog a de factorizaci n de hoy en d a, esto no es demasiado bueno, pero es lo que especifica el est ndar. Sin duda alguna, debemos usar claves DSA de 1024 bits. Por otra parte, las claves ElGamal pueden ser de cualquier tama o. Ya que GnuPG es un sistema de clave p blica h brido, la clave p blica se usa para cifrar una clave de sesi n de 128 bits, y la clave privada se usa para descifrarla. Sin embargo el tama o de la clave afecta a la velocidad del cifrado y descifrado, ya que el valor de estos algoritmos lleva como exponente el tama o de la clave. Una clave de mayor tama o tambi n tarda m s en ser generada, y ocupa m s espacio. Adem s, cuanto mayor tama o tenga una clave, la seguridad extra que nos ofrece, aumenta pero con una marcha decreciente. Tambi n hay que tener en cuenta que un escucha que se encuentre con una clave lo suficientemente grande como para resistir un ataque de fuerza bruta, se limitar a cambiar de m todo para poder obtener los datos no cifrados. Por lo tanto, 1024 bits es el tama o de clave recomendado. Si nuestros requerimientos de seguridad fueran tan grandes como para necesitar claves de gran tama o, entonces deber amos consultar a un experto en seguridad de datos. ------------------------------------------------------------------------------- Protecci n de la clave privada La protecci n de la clave privada es la parte m s importante en el uso de GnuPG. Si alguien obtuviera nuestra clave privada, todos los datos que hubieran sido cifrados para esa clave podr an ser descifrados y se podr a firmar documentos bajo nuestro nombre. Si perdi ramos la clave privada, ya no podr amos descifrar los documentos cifrados que nos hubieran enviado o que nos enviaran en un futuro, y no podr amos firmar los documentos. La p rdida de posesi n de nuestra clave privada podr a ser una cat stofre. Sea cual fuere el uso que hagamos de GnuPG, deber amos guardar siempre un certificado de revocaci n de nuestras claves p blicas, y una copia de seguridad de nuestra clave privada en un disco protegido contra la escritura, y en un lugar seguro. Por ejemplo, podr amos grabarlo en un CD-ROM y guardar ste en un cofre de dep sito de un banco, dentro de un sobre sellado. Alternativamente, podr amos guardarlo en un disquete y esconderlo en nuestra casa. Hagamos lo que hagamos, los certificados de revocaci n de las claves p blicas y las copias de seguridad de la clave privada deber amos tenerlos guardados en un medio lo suficientemente seguro, mucho m s 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 sim trico. Por esta raz n, para acceder a nuestra clave, necesitamos una contrase a. 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 ser a que guard ramos la clave en un disco que fuera port til y que tuviera protecci n contra la escritura, como un disquete, y que s lo lo us ramos en una m quina 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 m quina, y que debamos usar la de la universidad o la de la oficina, o puede significar que para ello tengamos que desconectar el modem cada vez que queramos usar GnuPG. Esto no quiere decir que no podamos o no debamos usar GnuPG. Tan s lo significa que debemos decidir si los datos que estamos protegiendo son lo suficientemente importantes para cifrarlos, pero no tan importantes como para tomar medidas extra de seguridad. La elecci n es nuestra. Una buena contrase a es absolutamente cr tica 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 contrase a. El motivo por el que intentar a adivinarla, es que la mayor a de personas escogen contrase as que son m s f ciles de adivinar que de sobrepasar una clave aleatoria de 128 bits. Si la contrase a es una palabra ("password"), es mucho m s f cil 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 m s f cil probar palabras de diccionario con un cat logo de permutaciones. Lo mismo ocurre con las citas. Aunque sea una contrase a formada por frases ("passphrase"), si sta tiene como base un lenguaje natural, ser una contrase a d bil, ya que existir poca aleatoriedad y muchas redundancias. Si es posible, debemos evitar contrase as basadas en lenguajes naturales. Una buena contrase a es aqu lla que podemos recordar, pero que es dif cli que otro pueda adivinar. Deber a incluir todos los car cteres imprimibles de nuestro teclado posibles. Esto incluye car cteres alfab ticos en may sculas y min sculas, n meros, y car cteres especiales como } o ?. Debemos ser creativos y perder un poco de tiempo inventando una contrase a; una buena elecci n es importante para asegurar nuestra privacidad. ------------------------------------------------------------------------------- Selecci n de las fechas de caducidad y uso de subclaves Por defecto, una clave de firmado 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 firmado maestra se usa para las firmas digitales, y tambi n recolectan las firmas de otras personas que hayan confirmado nuestra identidad. La clave de cifrado se usa s lo para descifrar los documentos cifrados que nos hayan enviado. Por lo general, una firma digital tiene una larga vida, v.g., para siempre, y tampoco queremos perder las firmas que tanto nos ha costado recolectar en nuestra clave. Por otra parte, la subclave de cifrado puede cambiar peri dicamente 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 intenci n de que la clave tenga una vida limitada. Por ejemplo, si la usamos para una campa a pol tica y no nos ser til una vez pasada la campa a. La segunda es que si perdemos el control de la clave, y no tenemos un certificado de revocaci n con el que revocarla, una fecha de caducidad sobre la clave maestra asegura que la clave caer finalmente 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 a adiremos una nueva subclave y publicaremos nuestra clave p blica actualizada. Una vez que la subclave haya caducado, aquellos que deseen comunicarse con nosotros deber n encontrar antes la clave actualizada, pues ya no podr n enviar datos cifrados para esa clave. El inconveniente depende de c mo distribuyamos la clave. Por fortuna, no es necesario firmas extras ya que la nueva clave habr sido firmada con con nuestra clave de firmado maestra, la cual ya hab a sido validada por nuestros corresponsales. Todo depende de que queramos o no tener una seguridad extra. Al igual que nosotros, un atacante todav a podr leer todos los documentos que hayan sido cifrados para una clave caducada. Cambiar las subclaves s lo protege los futuros documentos. Para poder leer documentos cifrados para la nueva subclave, el atacante necesitar a organizar un nuevo ataque, usando cualquier t cnica que hubiera usado la primera vez. Al final s lo tiene sentido tener una sola subclave de cifrado en un anillo de claves. No hay se gana seguridad adicional teniendo dos o m s subclaves activas. Por supuesto, puede existir cualquier n mero de claves caducadas en un anillo de claves, para que los datos que hubieran sido cifrados en el pasado puedan todav a ser descifrados, pero s lo es necesario activar una sola subclave en un momento dado. ------------------------------------------------------------------------------- Gesti n del anillo de confianza Al igual que con la protecci n de nuestra clave privada, la gesti n de nuestro anillo de confianza 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 interceptaci n casual o de una falsificaci n, entonces nos podemos permitir ser algo confiados con las firmas de otros. Si, por el contrario, nos preocupa que pueda haber un atacante determinado interesado en invadir nuestra privacidad, entonces deber amos confiar mucho menos en otras firmas, e invertir m s tiempo en verificarlas. Aparte de nuestras propias necesidades de seguridad, deber amos tener siempre cuidado al firmar las claves de otras personas. Firmar una clave sin el suficiente grado de confianza en la validez de la clave, s lo para satisfacer nuestras propias necesidades de seguridad, es una actitud ego sta. Otros, con otras necesidades de seguridad m s grandes, podr an fiarse de una clave que llevara nuestra firma. Si no pueden confiar en nosotros, entonces se debilita el anillo de confianza y se hace m s dif cil la comunicaci n para todos los usuarios de GnuPG. As pues, debemos poner el mismo cuidado al firmar una clave que el que nos gustar a que pusieran otras personas cuando dependamos de sus firmas. En la pr ctica, la gesti n de nuestro anillo de claves evita el tener que ajustar las opciones --marginals-needed y --completes-needed. Cualquier clave que firmemos personalmente ser considerada v lida, pero con la excepci n de grupos reducidos, no es pr ctico firmar la clave de cada persona con la que nos comuniquemos. Por lo tanto, tendremos que dejar que otros asignen el nivel de confianza. Es aconsejable ser precisos cuando asignemos el nivel de confianza y cuando usemos las opciones para configurar el cuidado con que GnuPG debe ir con la validaci n de claves. Por ejemplo, es posible que tengamos plena confianza con unos pocos amigos ntimos, que sabemos que ser n lo suficientemente cuidadosos cuando firmen una clave, y que otorguemos un nivel de confianza marginal al resto en nuestro anillo de claves. Desde esta perspectiva, podemos tener --completes-needed como 1 y --marginals-needed como 2. Si estuvi ramos m s preocupados por la seguridad, podr amos 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 fiabilidad razonable sobre la validez, escogeremos los valores 1 y 1. Por regla general, los n meros m s altos para estas opciones suponen que ser a necesario que hubiera m s gente conspirando contra nosotros para poder validar una clave que no pertenezca a la persona que nosotros creemos. ------------------------------------------------------------------------------- Construcci n del anillo de confianza No basta con que una persona quiera usar GnuPG. Para poder usarlo para comunicarse en modo seguro con otros, es necesario que tengamos un anillo de confianza. A primera vista, construir un anillo de confianza es una tarea desalentadora. Las personas con las que nos comunicamos necesitan usar GnuPG[8] , y es necesario que haya las suficientes firmas para que las clave sean consideradas v lidas. Estos no son problemas de tipo t cnico; son problemas de tipo social. Debemos superar estos problemas si queremos usar GnuPG. En nuestros primeros pasos con GnuPG, es importante darse cuenta de que no necesitamos comunicarnos de modo seguro con todas las personas. Empecemos con un peque o c rculo de amigos, tal vez s lo nosotros y uno dos m s que tambi n quieran ejercitarse en su derecho a la privacidad. Generemos nuestras claves, y firm moslas rec procamente. ste es nuestro anillo de confianza inicial. Al hacerlo as , apreciaremos el valor de un peque o, pero robusto anillo de confianza, y seremos m s cautos a medida que vaya creciendo nuestro anillo de confianza con el tiempo. Adem s de aqu llos en nuestro anillo de confianza inici tico, es posible que deseemos comunicarnos en modo seguro con otros que tambi n est n usando GnuPG. Sin embargo, esto puede ser problem tico por dos razones: (1) no siempre sabemos cu ndo alguien usa o estar a dispuesto a usar GnuPG; (2) si sabemos de alguien que lo usa, todav a es posible que tengamos problemas para validar su clave. El primer motivo sucede porque las personas no siempre hacen p blico que usan GnuPG. La forma de cambiar ese comportamiento es sentar ejemplo y hacer p blico que usamos GnuPG. Existen al menos tres maneras de hacer esto: firmar digitalmente los mensajes que enviamos a otros[9], publicar nuestra clave p blica en nuestra p gina en Internet, o, si la subimos a un servidor de claves, poner nuestro identificador de clave como parte de nuestra firma. Haciendo p blica nuestra clave, ayudamos a que sea m s aceptable para otras personas hacerla tambi n p blica. Adem s, hacemos m s f cil para otros el que puedan comenzar a comunicarse con nosotros en modo seguro, ya que habremos tomado la iniciativa, dejando claro que usamos GnuPG. La validaci n de la clave es m s dif cil. Si no conocemos personalmente a la persona cuya clave queremos firmar, no es posible que podamos firmar su clave personalmente. Debemos fiarnos de las firmas de otras personas y esperar que encontraremos una cadena de firmas que nos lleven desde la clave en cuesti n hasta la nuestra. Para poder encontrar una cadena, debemos tomar la iniciativa y conseguir que nuestra clave sea firmada por otras personas fuera de nuestro anillo de confianza inicial. Un modo efectivo de conseguir esto es participando en reuniones de firmas . De todos modos, debemos tener en cuenta que todo esto es opcional. No existe ning n tipo de obligaci n de hacer p blicas nuestras claves o de firmar las claves de otros. GnuPG es lo suficientemente flexible como para adaptarse a nuestros requerimientos de seguridad, sean stos los que sean. Sin embargo, la realidad social es que necesitaremos tomar la iniciativa si queremos engrosar nuestro anillo de confianza, y hacer todo el uso posible de GnuPG. ------------------------------------------------------------------------------- Uso legal de GnuPG El estado legal de los programas criptol gicos var a seg n pa ses, y las leyes que rigen estos programas evolucionan con rapidez. Bert-Japp Koops mantiene unos recursos sobre leyes y criptograf a, Crypto Law Survey, que podemos tomar como referencia para el status legal en cada pa s. ------------------------------------------------------------------------------- Cap tulo 5. T picos Este cap tulo trata temas miscel neos que no se ajustan a otros cap tulos del manual de usuario. A medida que se vayan a adiendo nuevos temas, se pueden ir creando nuevos cap tulos con stos. Sugerencias sobre temas que no han sido tratados son bienvenidas. Mejor a n si estas sugerencias vienen acompa adas por un boceto o esquema sobre el tema sugerido! ------------------------------------------------------------------------------- Escribir interfaces de usuario Alma Whitten y Doug Tygar han hecho un estudio sobre la interfaz de usuario de PGP 5.0 de NAI, llegando a la conclusi n de que los usuarios nuevos encuentran PGP confuso y frustrante. En su estudio sobre factores humanos, s lo 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 ning n tipo de cifrado. M s a n, la mitad de los sujetos del estudio pose an conocimientos t cnicos. Estos resultados no son sorprendentes. PGP 5.0 tiene una bonita interfaz de usuario que es excelente si ya comprendemos el funcionamiento de la criptograf a de clave p blica, y si estamos familiarizados con el modelo de gesti n de claves del anillo de confianza, especificado por OpenPGP. Por desgracia, los usuarios nuevos no entienden ni la criptolog a de clave p blica, ni la gesti n de claves, y la interfaz de usuario no es de ninguna ayuda en este caso. Alguien que estuviera dise ando una interfaz de usuario, deber a leer el estudio de Whitten y Tygar sin lugar a dudas. En l se dan detalles espec ficos sobre cada uno de los sujetos sometidos a estudio, y esos comentarios son interesantes. Por ejemplo, parece ser que muchos de los sujetos cre an que un mensaje enviado a otra persona, deb a ser cifrado con la clave p blica del remitente. Reflexionemos un minuto sobre esto, y nos daremos cuenta de que es un fallo muy f cil de cometer. Por lo general, los nuevos usuarios tienen dificultades en comprender los prop sitos diferentes de las claves p blicas y de las privadas en GnuPG. Un dise ador de una interfaz de usuario deber a intentar aclarar en todo momento cu ndo una de las dos claves debe ser usada. Se podr a usar ayudas guiadas, u otras t cnicas de interfaz gr fica de usuario (GUI), con el fin de guiar al usuario en tareas tan comunes como la generaci n de claves, donde pasos extras como la generaci n de un certificado de revocaci n y hacer una copia de seguridad, son esenciales para el uso correcto de GnuPG. Otros comentarios sobre el estudio se incluyen a continuaci n. * La seguridad es, generalmente, un objetivo secundario; los usuarios quieren enviar correo, enviarlo, y dem s... No se debe asumir que los usuarios tienen ning n tipo de motivaci n para la lectura de manuales, o que buscar n controles de seguridad. * La seguridad de una m quina en red es tan fuerte como el m s d bil de sus componentes. Los usuarios necesitan ser guiados para que presten atenci n a todos los aspectos de su seguridad, no se les puede dejar que procedan en exploraciones aleatorias, como podr an hacer con un procesador de texto o un hoja de c lculo. * Se debe ser consistente en el uso de los mismos t rminos para las mismas operaciones. No se deben alternar sin nimos como cifrar y encriptar [10] . * Se debe simplificar la vista en pantalla para los usuarios inexpertos. Un exceso de informaci n oculta la informaci n importante. La configuraci n inicial podr a concentrarse en dar al usuario el modelo correcto de la relaci n entre claves p blicas y privadas, y una clara explicaci n de las funciones para la adquisici n y distribuci n de claves. Dise ar una interfaz de usuario efectiva para la gesti n de claves es todav a m s dif cil. El modelo de anillos de confianza de OpenPGP es, por desgracia, bastante r gido. Por ejemplo, la especificaci n impones el uso de tres niveles de confianza arbitrarios: none (ninguna), marginal (idem), y complete (total). Todos los grados de confianza que pueda sentir el usuario deben ajustarse a esos tres. La validaci n del algoritmo tambi n es dif cil de comprender para aquellos que no sean muy expertos, en particular las nociones de ``marginals needed'' y ``completes needed''[11]. Pero ya que el modelo de anillos de confianza est bien especificado y no se puede cambiar, hay que hacerlo lo mejor posible y dise ar una interfaz de usuario que ayude a clarific rselo de cara al usuario. Por ejemplo, una mejora ser a generar un diagrama de c mo ha sido validada una clave, al ser requerida por el usuario. A continuaci n algunos comentarios relevantes del estudio. * Los usuarios tienden a tener incerteza sobre cu ndo y c mo pueden conceder accesos. * Asegurarse que los usuarios comprenden su propia seguridad lo suficientemente bien como para prevenirlos de que cometan errores que puedan suponer un alto coste, debe ser un m xima prioridad. Tales errores incluyen: eliminar la clave privada por accidente; hacer p blica una clave por error; revocar una clave por error; olvidar la contrase a; y no hacer copias de seguridad de sus anillos de claves. Notas [1] N. de T. En este y otros documentos se intercambia el t rmino claves subordinadas con el de subclaves [2] La opci n 3 es para generar un par de claves ElGamal que no puede ser usado para firmar. [3] Se aceptan excepto en la direcci n de correo electr nico. En el resto pueden dar problemas, as que se recomienda no usarlos. [4] N. de T. Esta contrase a adopta la forma de una frase ("passphrase"), no de una sola palabra ("password"). [5] Muchas opciones de la l nea de rdenes que se usan con frecuencia, tambi n se pueden configurar en un fichero de configuraci n. [6] El sistema de cifrado debe poseer la propiedad de que la clave p blica o la privada puedan ser usadas por el algoritmo de cifrado como clave p blica. RSA en un ejemplo de este tipo de algoritmo, mientras que ElGamal no. [7] N. de T.: GnuPG hace un uso excesivo de la palabra ``trust'', utiliz ndola en el sentido de confianza en el propietario y confianza en la clave . Esto puede llevar a confusi n. Algunas veces la confianza en un propietario viene referida como owner-trust para distinquirla de la confianza en una clave. Sin embargo, a lo largo de este manual ``trust'' se usa en el sentido de confianza en el propietario de la clave , y ``validity'' en el sentido de confianza en que una clave pertenece a la persona asociada con el identificador de clave . [8] En esta secci n, GnuPG se refiere a la implementaci n OpenPGP de GnuPG, as como a otras implementaciones como el producto PGP de NAI. [9] Se recomienda no hacerlo nunca en listas de correo de discusi n p blica, ya que esto podr a molestar a algunas personas. [10] Del documento original en ingl s, ya que en castellano la palabra encriptar es incorrecta, mientras que la correcta es cifrar . As pues, en este caso y en castellano, estas dos palabras no son sin nimos. [11] Cu ntas firmas que tengan asignada confianza marginal y cu ntas firmas que tengan asignada confianza completa son necesarias