Uso diario de GnuPG

Guía de ``Gnu Privacy Guard''
Anterior |  | Siguiente

# 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.

Anterior | Inicio | Siguiente
Distribución de claves |  | Construcción del anillo de confianza