Cómo trabajar Pretty Good Privacy (PGP)

GENERACIÓN Y MANEJO DE CLAVES

El primer paso, una vez que hemos instalado el programa PGP es generar nuestro par de claves RSA. Para ello teclearemos : pgp -kg.

En primer lugar, el programa pide el tamaño de la clave. Lo normal es emplear un tamaño de 1024 bits, ya que así (siempre según los supuestos expuestos anteriormente sobre la seguridad de los algoritmos) obtendremos una clave impenetrable, y no tan grande que se vuelva inmanejable. Después se pide el userID, un identificador del propietario de la clave, que suele ser : Nombre completo <direccion de correo electrónico>. Por último, se pide la pass phrase, frase que servirá de password para cada vez que queramos utilizar la clave privada.

Después, el programa comienza la generación de los números aleatorios que necesita para crear el par de claves. Como parte del proceso pedirá que se teclee durante un tiempo cualquier cosa a distinta velocidad de tecleo, para generar diversos números aleatorios a partir del texto introducido y las distintas velocidades. Por tanto, no hay que teclear cosas como "AAAAAA" ni a la misma velocidad. Después de un tiempo, el programa terminará los cálculos necesarios, generando nuestro par de claves. La clave privada se guarda en un archivo llamado secring.pgp, y la pública en pubring.pgp. Este último archivo se denomina anillo de claves públicas, y será el lugar donde iremos almacenando las claves públicas de aquellos con los que nos comuniquemos.

Según diversos cálculos realizados por expertos en criptografía, éstos son los tiempos que necesitaría un ordenador de 5000 MIPS para penetrar el par de claves: clave de 429 bits, 1 año ; clave de 512 bits, 500 años ; clave de 700 bits, 1 millón de años ; clave de 1024 bits, 5*10^11 años (¡así que parece que por ahora estamos protegidos!). 

- Extracción de claves públicas.

A partir de ahora podemos empezar a distribuir nuestra clave pública, y para ello debemos extraer una copia del anillo. Para ello se utiliza la orden : 

pgp -kxa userID nombre de archivo

La "a" indica que la clave se extraerá en ASCII de 7 bits para poder ser enviada por e-mail. También se puede omitir la "a" y obtener una clave binaria.

El userID no tiene que ser necesariamente el userID completo, basta con introducir lo suficiente para que el programa pueda distinguirlo del resto.

Además de la distribución de la clave pública "de uno a uno" se puede recurrir a los servidores de claves públicas. Normalmente son una parte más de websites dedicados a PGP, por lo que se accede a ellos a través de la web, interactuando a través de formularios. Si queremos pedir una clave, le pasamos al servidor el nombre del propietario a través del formulario, y buscará la clave. Si queremos añadir nuestra clave al servidor, se rellenará un formulario con nuestro nombre, la clave en ASCII, y una dirección de correo para que el servidor pueda confirmarnos (normalmente unas horas después) que ha recibido la clave y la ha incorporado.

Este es el aspecto de una clave pública en ASCII :

Type Bits/KeyID Date User ID

pub 1024/BF152815 1996/09/10 Jose Luis Martin Mas <jlmartin@lander.es>

-----BEGIN PGP PUBLIC KEY BLOCK-----

Version: 2.6.3i

mQCNAzI1iicAAAEEAMm0XOb9WZcCwzNF1x8pT5Ky7yhZDTafEUt2lbWQdScMi+tl KhxSIZV0Q1690pABxJQ3O38fzIufpje4YpFhXRiUEe9SnhHaNnRSEGQYuvUbMUfa Mfmzyf+VO3NvllwFnfoe2KVB8Xiytbja8jdr3DtfasdQKd/7eCrxe1y/FSgVAAUT tClKb3NlIEx1aXMgTWFydGluIE1hcyA8amxtYXJ0aW5AbGFuZGVyLmVzPokAlQMF EDI1iicq8XtcvxUoFQEBWjYD/0N3eOC5dULMKkc0dnZ/CBbmHod39yp03YWswyo6 XNxNhTtT44u1p9cDOTYS5OY2nOdcRKp1cTWQhnRbi1q6piEbQQOOlv7+LTSwMJRA +bj7N/Sb2TJHpxk5uDICB+RyCN/ljHiajSuMa8eUEpvcP493cT+jr5paj3FHvskw 2BxD =7Pfm

-----END PGP PUBLIC KEY BLOCK-----

- Añadir una clave pública al anillo.

Si alguien nos pasa su clave pública, podemos añadirla al anillo con la orden : 

pgp -ka archivo que contiene la clave

- Eliminar una clave del anillo.

Se utiliza la orden pgp -kr userID

- Certificación de claves públicas.

Surge un problema con la autenticidad de las claves públicas que nos pasan similar al de la criptografía de clave única, aunque menos grave.

Si la persona con la que nos vamos a comunicar vive en nuestra ciudad o cerca, puede pasarnos la clave en mano y así tendremos una total garantía, pero ¿qué ocurre si vive demasiado lejos ? Alguien que sepa que nos vamos a comunicar con Pepe podría generar una clave con el userID de Pepe y mandárnosla por e-mail haciéndose pasar por él. Si está atento para interceptar los mensaje que le enviemos a Pepe, podrá desencriptarlos.

Tenemos dos opciones vara verificar la autenticidad de la clave pública :

a) Uso del fingerprint.

Si podemos reconocer por teléfono la voz de la persona con la que nos comunicamos, podemos pedirle el fingerprint de su clave para compararlo con el de la clave que tenemos nosotros. Este fingerprint es un pequeño extracto hexadecimal de la clave único para cada clave producido con MD5. El fingerprint se obtiene con la orden : pgp -kvc userID.

b) Uso de firmas

Supongamos que Pepe y Manolo son dos personas con las que nos vamos a comunicar utilizando PGP. Pepe vive bastante lejos y no podemos verle, y llamarle por teléfono nos saldría caro... Sin embargo, Manolo vive en nuestra ciudad y viaja frecuentemente a la ciudad de Pepe, por lo que puede conseguir con garantías una clave auténtica de Pepe. Manolo, aparte de proporcionarnos esa clave, puede firmarla para verificar su autenticidad.

La clave de la tercera persona es firmada con la clave de la persona que actúa de intermediaria. Al añadir la clave firmada al anillo, esta firma será comparada con la clave pública de la persona intermediaria, y si es auténtica, y hemos autorizado al programa para validar las claves que tengan firma de la persona intermediaria, se validará. 

Cada vez que añadimos una clave pública al anillo, el programa nos preguntará primero si podemos garantizar con absoluta seguridad que la clave pertenece a la persona en cuestión. Si respondemos que sí, la firmará. En el caso de que la hayamos firmado, también nos preguntará si queremos utilizar a esa persona como intermediaria, dándonos distintos "niveles de confianza" : total, parcial, nula, o indefinida.

En caso de que queramos firmar la clave después de haberla añadido, podemos hacerlo con la opción pgp -ks userID de la clave a firmar. Para poder firmar el programa nos pedirá la pass phrase. Si queremos eliminar una firma de una clave, podemos hacerlo con la opción pgp -krs userID de la clave. El programa irá recorriendo las firmas de la clave y preguntando una por una si las queremos quitar o no.

Suele ser costumbre firmar la propia clave pública (¡nadie mejor que nosotros mismos para certificarnos !).

La certificación de las claves es uno de los grandes problemas a los que se enfrenta la criptografía pública. En algunos sistemas se ha recurrido a una "autoridad central" que se encargue de certificar las claves, pero éste es un modelo sólo útil en sitios como empresas, pero no en el ambiente descentralizado de Internet.

De hecho, éste es el modelo del sistema oficial propuesto como standard de encriptación de mensajes por Internet, el PEM (Privacy Enhanced Mail), descrito en las Request For Comment 1421 a 1424. PEM tiene otro inconveniente además de ser centralizado. Al estar nuestras claves controladas por una "autoridad central" (un gobierno, alguna empresa...) no tenemos garantizado el que nuestro mail no pueda "pincharse". Curiosamente, el gobierno americano apoya con gran entusiasmo PEM...

Con PGP es responsabilidad de cada uno el controlar las claves que usa, teniendo siempre como norma fundamental el considerar como válidas y/o firmar únicamente las claves que nos han sido dadas en mano o aquellas de las que hemos podido verificar el fingerprint.

- Ver el contenido de un anillo.

La opción pgp -kv nos permite ver qué claves tenemos en el anillo.

Podemos obtener más detalles y ver las firmas de las claves con pgp -kvv. 

- Anular una clave pública.

Puede ocurrir si no somos cautos que nuestra clave secreta sea robada, o que alguien descubra nuestra pass phrase, o ambas cosas. En ese caso, debemos avisar a la gente para que deje de usar nuestra clave pública.

PGP facilita las cosas emitiendo un certificado de anulación de la clave con la opción pgp -kd userID. El certificado contiene una firma hecha con la clave secreta que anulamos. Una vez lo reciban aquellos que se comunican con nosotros, han de añadirlo al anillo de clave públicas, y así, si intentan usar la clave anulada, el programa lo advertirá. Ya sólo queda generar un nuevo par de claves y distribuir la nueva clave pública.

Hay un inconveniente : hace falta la clave a anular para poder ser anulada, pero ¿y si ha sido robada o se ha perdido ? Por ahora no hay más solución que hablar directamente con las personas que tienen nuestra clave, aunque se están preparando futuras versiones de PGP que tienen previsto que los intermediarios que tengan un "nivel de confianza" total puedan certificar una clave como anulada.

ENCRIPTACIÓN

La orden para encriptar un archivo es : pgp -ea archivo userID del destinatario. Así, un texto como :

Esto es una prueba de encriptacion con PGP

pasa a ser :

-----BEGIN PGP MESSAGE-----

Version: 2.6.3i

hIwDuMLU1o8BiTEBBACrHUQmh72pZPeptKmUQxGCV8sQSPZy6OCWRUQmC4eGg3Kx 80T3wawd9UkEaZIR5ZHaE5Amg3AsXR41Ljp7vGo200sFgR4YYYndyMXuhp2XfEvY j8zRwIOJU3jkqRdMSsBukJmHseJG4JbMQFMELplkH1qkBOvgkcF4qtXwlmwsMaYA AABEbnWSr7tqz74eVcUK0fJLGFRvQ2vhc0vNlbKe2gF8wtLMQ07kgmXSy7Ez3Gcv a5s6ZQp0XwBpEYiZ6enUSiDDE6Dabys= =EZW3

-----END PGP MESSAGE-----

La opción "a" hace que el texto encriptado esté en ASCII de 7 bits para poder utilizarse en e-mail, aunque aumenta en un 33% la longitud final.

¿Cómo tiene lugar el proceso de encriptado ? Se realiza en tres pasos :

1. Se comprime el mensaje utilizando el método ZIP. Esto, aparte de reducir el tamaño del mensaje, hace que sea aún más difícil desencriptarlo.
2. El generador de números aleatorios crea, utilizando entre otras fuentes el reloj del sistema, una clave aleatoria IDEA única para ese mensaje, y el mensaje es encriptado con esa clave IDEA.
3. Por último, la clave IDEA es encriptada con la clave pública del destinatario y es añadida al mensaje.

Si se ha incluido la opción "a", además se traducirá el mensaje a ASCII.

Como se ve, PGP combina el algoritmo IDEA y el RSA, es decir, emplea un sistema híbrido de criptografía. Debido a la "veneración" que hay hacia el RSA, esto hace pensar a algunas personas que el sistema que emplea PGP es más débil, pero es todo lo contrario. Se ha calculado que debido a la "fuerza" del algoritmo IDEA, romper su pequeña clave de 128 bits equivale a romper una clave de 3100 bits de RSA. Teniendo en cuenta que romper una clave RSA de 1024 bits llevaba 5*10^11 años... El hecho de que la clave sea aleatoria y única para cada encriptación complica aún más las cosas. Por otro lado, usar únicamente el RSA haría todo unas 4000 veces más lento.

Volviendo al PEM del que se habló anteriormente, hay más problemas añadidos a su centralización, y es que es un "colador criptográfico". Emplea un sistema parecido al de PGP, sin embargo, su algoritmo de clave única es el algoritmo DES (Data Encryption Standard) con claves de 56 bits, suficientemente pequeñas para ser descubiertas por el "método bruto" de probar todas las claves posibles. Además, el algoritmo en sí es débil, y fue roto ya en 1992 por Biham y Shamir utilizando criptoanálisis. De hecho, según el estudio que presentó Michael Wiener en la conferencia Crypto '93, ya entonces podía fabricarse un chip que probara 50 millones de claves DES por segundo, consiguiendo encontrar la clave en un máximo de 7 horas, y costando 1 millón de doláres, algo al alcance de muchas empresas y gobiernos. Volviendo a las "curiosidades" del gobierno americano, que tanto apoya a PEM, no lo utiliza...

- Criptografía de clave única con PGP.

Puede interesarnos también a veces usar encriptación convencional para proteger textos nuestros. Para ello, se usa la opción pgp -c texto. El programa PGP generará una clave IDEA aleatoria y nos pedirá una pass phrase para protegerla, para después encriptar el texto sin utilizar para nada las claves RSA.

- Uso de PGP como un uuencode mejorado

En el sistema Unix se suele utilizar el programa uuencode para convertir archivos binarios en ASCII y poder mandarlos por e-mail. Dado que PGP emplea para su conversión al ASCII el mismo sistema que uuencode, puede usarse para el mismo fin sin necesidad de encriptar, usando la opción pgp -a archivo.

Hay además mejoras : si el archivo es demasiado grande para enviarlo, PGP puede dividirlo en archivos más pequeños, añadiendo un CRC a cada archivo, además de comprimirlos.

Para recomponer el archivo se usa la opción pgp -p archivo.

DESENCRIPTACIÓN

La orden para desencriptar es simplemente pgp archivo. El proceso es el inverso al de encriptado : se desencripta la clave IDEA con la clave secreta del destinatario, se desencripta el texto y se descomprime. Ya que se usa la clave secreta, el programa pedirá la pass phrase.

Asimismo, si el texto fue encriptado sólo con IDEA, el programa lo reconoce y pide la pass phrase de la clave IDEA que se creó.

FIRMAS DIGITALES

La orden para firmar digitalmente un texto es : pgp -s archivo. Esta opción tiene el inconveniente de, aparte de hacer una firma digital binaria, comprimir el texto haciéndolo ilegible directamente, por lo que se puede añadir la opción "a" para evitarlo, obteniendo un resultado como éste :

-----BEGIN PGP SIGNED MESSAGE-----

Esto es una prueba de firma digital con PGP

-----BEGIN PGP SIGNATURE-----

Version: 2.6.3i

Charset: noconv

iQCVAwUBM1zU/Crxe1y/FSgVAQFlOgP/XpzZyps3C+tzIri/b86y4G2LZOqfl0hJ nXyoCZSzplTwPKSlBks632GTSho/G/VQd7EnS5NZEm75SdRsl9MG+TsXvJiWDpUU 7wKlTFe15Kis0WBTS1X8tRBceNNuQdk5UG68KGXsrg7Gj9tqJqsBVrkJ0/tW0J3A kWk4NKqcIAg= =znhK

-----END PGP SIGNATURE-----

Por otro lado, también puede firmarse el texto para después encriptarlo con la clave pública de algún destinatario con la opción pgp -se texto userID del destinatario (pudiendo añadir "a").

El destinatario puede comprobar la validez de la firma (y desencriptar el mensaje si está encriptado) igual que al desencriptar normalmente : pgp archivo.

En la creación de una firma digital intervienen el algoritmo MD5 y el RSA. La firma, normalmente, debería consistir en una encriptación del texto a enviar con la clave secreta RSA del emisor que se añadiría al final del mensaje. Sin embargo, esto sería un proceso demasiado largo, por lo que se recurre a encriptar un message digest del mensaje.

En primer lugar, se obtiene un digest con el algoritmo MD5, para después ser encriptado con la clave secreta RSA del emisor, y es añadido al final del mensaje. El proceso de comprobación de la firma es el inverso. El programa desencripta el digest con la clave pública del emisor ; si no pudiera, daría un aviso de firma no válida. Si la desencriptación tiene éxito, produce un digest del mensaje recibido y lo compara con el digest que ha desencriptado para ver si son idénticos. Si todo va bien, dará un mensaje de firma válida. De esta forma, en primer lugar se comprueba la autenticidad del mensaje (en la desencriptación) y su integridad (en la comparación de digests). Se tiene además la ventaja de que sea cual sea el tamaño del mensaje, no habrá peligro de tener que encriptar un digest grande, ya que siempre será de 128 bits.