Bienvenido  Curso de PGP, dirigido y presentado por Arturo Quirantes Sierra. En él podrá usted aprender a manejar, configura y utilizar habitualmente el programa de cifrado de datos Pretty Good Privacy (PGP), uno de los más extendidos y usados en mensajería de correo electrónico.

¿Por qué necesita usted un curso sobre PGP? A fin de cuentas, hay manuales y archivos de ayuda. Pero la experiencia muestra que las cosas no son tan sencillas. Cuando un "newbie" (novato) descubre un nuevo programa, uno de sus primeros problemas consiste en averiguar cómo funciona. Los archivos de ayuda no solucionan todos los problemas ni entran en profundidad en conceptos. Y el manual que acompaña al programa puede resultar, con sus trescientas páginas, digamos amenazador. La mayoría de los textos de aprendizaje están en inglés, y esto incluye los manuales que acompañan el programa.

Creo que se puede hacer mejor, especialmente pensando en los recién llegados que apenas si aciertan a distinguir entre una clave y una firma digital. José Manuel Gómez, de Kriptópolis ha confeccionado un manual de instrucciones relámpago PGP en una hora. Yo mismo traduje el manual de PGP versión 5.5.3i al castellano, en colaboración con Juan Manuel Velázque. Y con el presente curso, quiero llevar el conocimiento sobre el programa de cifrado PGP un paso más allá.

Bienvenidos por tanto a este Curso sencillo sobre PGP. Es un Curso porque requiere ir algo más allá de un telegráfico "PGP, programa de cifrado, bueno, yo Tarzán, tú Chita"; sencillo porque estará enfocado al usuario con nociones escasas -o nulas- sobre criptografía, si bien intentaré dejar algunas referencias para los apetitos insaciables; sobre PGP, porque es éste uno de los programas más conocidos sobre cifrado de datos, hasta tal punto que resultó poco menos que revolucionario en su momento.

Este cursillo está redactado en formato html deliberadamente sencillo. Es decir, no habrá diagramas, dibujos, fotografías ni requiere de Java, javascript, ActiveX o cualquiera de esas zarandajas con que nos vuelven locos. De hecho, podría haberlo escrito en formato texto sencillo, pero con ello perderíamos las ventajas de los hipervínculos y los formatos. No soy partidario de complicar las cosas innecesariamente.


Prólogo a la tercera edición (Mayo 2002)

El Curso Sencillo de PGP tenía en su origen la estructura de lo que denomino un "curso telepresencial", en el que los alumnos se incorporan a una lista restringida de correo electrónico. El profesor publicaba los capítulos del curso a razón de uno por semana, y los alumnos disponían de siete días para lerlos, formular preguntas e incluso ayudarse mutuamente.

Este Curso vio la luz gracias a los esfuerzos de Arturo Quirantes (Taller de Criptografía) y Jesús Sanz de las Heras (RedIris). La verdad es que no teníamos ni idea de en qué nos metíamos, pero pensamos que el que no se arriesga no cruza la mar. Así que durante los meses de Junio y Julio de 2.000 los miembros de RedIris fueron invitados al primer curso de PGP interactivo. El lector interesado en obtener más referencias puede ver su estructura y resultados aquí:

http://www.rediris.es/pgp/ini/1tc-pgp.es.html. Página principal de introducción e instrucciones
http://www.rediris.es/rediris/boletin/53/actualidad.htm#Tele Curso Resumen de resultados (Boletín de RedIris nº 53)

No solamente sobrevivimos a la primera edición del curso, sino que todo fue mejor de lo esperado. La cifra de asistentes virtuales (más de novecientos) no fue obstáculo para que las clases se desarrollasen sin ningún inconveniente. Solamente un grupo de alumnos tuvo algún problema con su conexión a Internet, que logramos subsanar. Por cierto, no sé cómo, pero el Curso sencillo de PGP (primera edición) traspasó las fronteras de RedIris, extendiéndose a particulares y empresas externas, y llegando a lugares tan dispares como Cuba o la Armada norteamericana (¿cómo llegó el curso desde RedIris a un dominio navy.mil? Misterios del ciberespacio).

La segunda edición (Noviembre 2.001) se desarrolló sin el concurso de RedIris, en un entormo de suscripción mediante pago organizado en elistas.net. Pero si les soy sincero, no fue lo mismo. PGP es un programa desarrollado inicialmente sin ánimo de lucro, y me sentía algo incómodo de cobrar por ello. Así que el Curso Sencillo de PGP vuelve a la modalidad de gratistotalware. Pase y póngase cómodo.

Y ya basta de introducciones. Esta es la estructura del Curso Sencillo de PGP.

Capítulo 1: El cifrado, en pocas palabras

Este Curso sencillo de sobre el programa de cifrado PGP comienza con una introducción a los principales conceptos en criptografía. Se hará una breve introducción a los dos tipos principales de cifrado existentes en la actualidad: cifrado simétrico y cifrado asimétrico (o de clave pública). Se explicará asimismo cómo los sistemas modernos de cifrado utilizan una combinación de algoritmos simétricos y de clave pública. Si bien este capítulo no es preciso para usar PGP, su lectora resulta altamente recomendable para comprender los mecanismos básicos subyacentes a este y otros protocolos de cifrado (como, por ejemplo, el usado por los navegadores seguros). Asimismo, es un comienzo útil para todos aquellos interesados en la criptología en general.

Capítulo 2: Firmas y certificados

Como continuación de la exposición de ideas previas en criptografía, revisaremos en este capítulo la forma digital. Se hará una breve introducción al concepto que en PGP se denomina firma digital y en otros protocolos se conoce como certificado digital. Se indicará cómo una firma -o certificado- adosado a una clave de cifrado permite resolver problemas de suplantación y autenticación de usuarios. Como todo en esta vida, es cuestión de confianza.

Capítulo 3: Primeros pasos con PGP

El presente capítulo constituye la introducción al programa Pretty Good Privacy. Se dará una breve historia de PGP desde su origen en 1.991. Tras indicar las direcciones donde se puede descargar el programa, pasaremos al proceso de instalación. Tras ello, generaremos y analizaremos una clave PGP

Capítulo 4: La ventana PGPkeys

Este capítulo nos enseñará a manejar la aplicación PGPkeys, corazón del sistema PGP. Aprenderemos a configurar correctamente el programa. A continuación, procederemos a manipular y modificar nuestras claves, incluyendo las opciones de revocación y creación de copias de seguridad.

Capítulo 5: Usando PGP

Tras haber aprendido a configurar correctamente el programa, pasemos ahora a usar PGP. Se mostrarán las diversas formas en que se puede firmar, cifrar, verificar y descifrar: desde su programa de correo electrónico, el Explorador de Windows, e incluso desde cualquier ventana abierta, gracias a la funcionalidad de PGP en su aplicación PGPtray

Capítulo 6: Miscelánea PGPera

¿Tiene futuro PGP? ¿Cuántos usuarios hay en el mundo? ¿Por qué molestarse en cifrar, si no tengo nada que esconder? ¿Es realmente seguro? ¿Hay algún código de "netiqueta" adecuado para PGP? ¿Qué es una "reunión de firma de claves"? Esta y otras preguntas similares serán revisadas en el último capítulo del Curso sencillo de PGP, que servirá como cierre aunque espero- no como despedida.

Capítulo 2: Firmas y certificados

      2.1 - La firma digital
      2.2 - La función resumen (hash)
      2.3 - El problema de la suplantación
      2.4 - La certificación de claves
      2.5 - El problema de la confianza
      2.6 - Para ampliar conocimientos


Resumen Como continuación de la exposición de ideas previas en criptografía, revisaremos en este capítulo la forma digital. Se hará una breve introducción al concepto que en PGP se denomina firma digital y en otros protocolos se conoce como certificado digital. Se indicará cómo una firma -o certificado- adosado a una clave de cifrado permite resolver problemas de suplantación y autenticación de usuarios. Como todo en esta vida, es cuestión de confianza.


2.1 - La firma digital

Cuando se desarrolló la criptografía de clave pública, tardó poco en hacerse evidente que sus posibles aplicaciones iban más allá del cifrado de mensajes o de datos. No solamente se puede cifrar la información, sino que también se puede autentificar. Es decir, puede crearse una firma digital.

¿Por qué firmamos documentos en el mundo real? Básicamente para conseguir alguno, o varios, de estos resultados:

      Autentificación (o autenticación). La firma convence al que la ve que el firmante firmó el documento deliberadamente.

      Inalterabilidad. La firma es prueba de que el documento no será alterado con posterioridad.

      Autoría. La firma prueba que el firmante fue quien redactó el documento

      Adhesión. La firma prueba que el firmante está de acuerdo con lo que contiene el documento.


      No repudio. La firma es garante de que el firmante acepta lo que está escrito en el documento, y de que no se echará atrás en el futuro.

Sea larga o corta, sencilla o con rúbrica, y cualquiera que sea el motivo que da lugar a su generación, una firma tiene una característica inalterable: es producida por un solo firmante, es decir, es algo inherente a la persona que la produce. De modo similar, para producir una firma digital necesitamos algo relacionado con el firmante y solamente con él. Recordemos que la clave pública es conocida por todos pero la clave privada es conocida solamente por su dueño. Así que para producir una firma digital, usaremos la clave privada. Firmar digitalmente un documento no es sino cifrar dicho documento (o una parte de él) con la clave privada.

Puede que el lector haya quedado confundido al leer la última palabra del párrafo anterior. ¿No quedamos que se cifraba con una clave pública? ¿Cómo se puede cifrar con una clave privada? Quizá hubiese sido mejor decir "aplicar la clave privada" en lugar de "cifrar con la clave privada." Recordemos que las claves pública y privada forman un par y son complementarias. Pero no hay nada esencialmente distinto entre ambas. Si usamos una para cifrar y la otra para descifrar, es solamente por convenio; igual podríamos cifrar con la otra y descifrar con la una. Lo que una clave hace, la otra lo deshace.

De manera que es factible aplicar el algoritmo de cifrado usando la clave privada, en lugar de usar la clave pública como hacíamos en el proceso de cifrado. Eso permite al destinatario verificar la firma, es decir, comprobar que es realmente la del remitente. Esto es posible porque dicho destinatario tendrá la clave pública del remitente. Supongamos que Ana es la remitente/firmante y Belén la destinataria/verificante. Durante la firma Ana usa su clave privada para firmar el mensaje. Cuando llega a Belén, ésta aplica la clave pública de Ana al documento. Si el mensaje proviene realmente de Ana, la operación realizada por Belén le devuelve el documento original. Pero si la clave pública con la que se ha verificado el mensaje no es complementaria a la clave privada que se ha usado para firmarlo, resultará tan evidente como una patada en el ojo. Resumiendo: si la información puede ser descifrada con la clave pública de Ana, es porque la ha firmado Ana y nadie más.

Fantástico, ¿no? En teoría sí. En la práctica, hay que modificar algo este esquema.


2.2 - La función resumen (hash)

El sistema de firma digital tal y como se acaba de describir tiene algunos problemas. En primer lugar, recordemos que la criptografía de clave pública es muy poco eficiente. Firmar (es decir, aplicar un algoritmo de clave asimétrica, usando la clave privada) produce un documento de mucho mayor tamaño que el original. También puede ser el origen de ciertos ataques criptoanalíticos: si un atacante consiguiese que Ana firmase un mensaje cuidadosamente compuesto, podría obtener mucha información sobre la clave privada de Ana. Y no podríamos combinar la firma digital con el cifrado. Si ciframos y firmamos un documento -en ese orden o en el inverso- estaríamos aplicando la clave privada y la clave pública, con lo que ambas acciones se anularían: acabaríamos con el mensaje original. Así que habría que escoger: o cifrar, o firmar.

Para evitar estos problemas, no se cifra todo el mensaje, sino solamente una parte de éste. ¿Pero qué parte? Cualquier parte del mensaje que no hayamos firmado puede alterarse impunemente, sin que tal alteración sea detectada. Imaginemos el mensaje "Debo a mi estupendo profesor de criptografía, Arturo Quirantes, mil euros" Si firmásemos digitalmente las palabras con número par de letras, solamente tendríamos la seguridad de que esas palabras han sido escrito por el firmante, y de que esas palabras no han sido alteradas. Un fisgón gracioso podría cambiar el texto, de manera que podría parecer que el profesor no soy yo sino Arturo Fernández, que el firmante me debe mil bofetadas ...o peor aún, que soy un profesor horroroso en lugar de estupendo

Debemos por tanto encontrar la manera de firmar un texto que sea más pequeño que el mensaje, pero que represente a éste en su totalidad. La manera de lograrlo es transformar dicho mensaje en un texto más pequeño. Matemáticamente, lo podemos representar por una función H que tome un mensaje M y produzca un condensado de éste H(M)=h. A esta función se la denomina función resumen, o función hash, y debe tener estas propiedades:

      Comodidad: ha de ser fácil obtener h partiendo de H

      Confidencialidad: para un resumen h dado, ha de ser difícil, si no imposible, obtener el mensaje M del que procede.

      No-colisión (débil): Para un mensaje M dado, ha de ser imposible (o al menos muy difícil) encontrar otro mensaje M´ con el mismo resumen, es decir, no ha de darse H(M)=H(M´)

      No-colisión: Ha de ser difícil hallar al azar dos mensajes M, M' tales que H(M)=H(M´)

La propiedad primera es evidente. La segunda evita que se pueda obtener información sobre el mensaje (el cual también puede ir cifrado). Las propiedades tercera y cuarta nos aseguran que la función resumen será única, ya que si dos mensajes tuviesen el mismo resumen h, una firma valdría para ambos. Es decir, si H(M)=H(M´) significa que la firma digital sobre ambos mensajes es exactamente la misma, de manera que bastaría con firmar un documento y "copiar+pegar" para tener el otro documento firmado. La ausencia de colisiones nos asegura que la firma digital solamente sirve para un documento concreto. Nadie, ni siquiera el firmante, podría trasladar la firma digital de un documento a otro sin que se note.

Hasta cierto punto recuerda a los códigos CRC que aseguran la integridad de un archivo, o a la letra del DNI. ¿Alguien sabe cómo se obtiene dicha letra? El procedimiento es sencillo. Basta con coger el número del DNI y dividirlo por el número 23. El número que sale del resto se hace corresponder con una letra, por medio de la siguiente correspondencia (haga la prueba con su propio número):

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
T R W A G M Y F P D  X  B  N  J  Z  S  Q  V  H  L  C  K  E


Véase como el número del DNI, de ocho cifras, es representado por una función resumen de solo una letra. No resulta muy confidencial, ya que aunque la letra no permite conocer el número, sí da cierta información sobre él. Y por supuesto es muy vulnerable a las colisiones. Con sólo veintipico letras, lo raro es que nuestra letra del DNI no coincidiese con la de ningún otro. Claro que la letra del DNI se diseñó como letra de control, no como función resumen. Para evitar que haya colisiones, una de las cosas que debemos asegurarnos es que la función resumen tenga muchos valores posibles.

Vamos a lo práctico. Para firmar digitalmente un mensaje, Ana hace lo siguiente:

- Toma el mensaje M y le aplica la función resumen, obteniendo H(M)=h
- Aplica al resumen su clave privada ks. El resultado es la firma digital: Cks(h)

A continuación envía el mensaje M y la firma Cks(h). Cuando Belén recibe el mensaje:

- Aplica la clave pública de Ana kp a la firma Cks(h) . El resultado es Ckp(Cks(h))=h
- Aplica al mensaje la función resumen, obteniendo H(M)=h'
- Compara el resultado de los dos pasos anteriores. Si coinciden (h=h´), la firma es correcta.

La verificación de la firma depende tanto de que haya sido realizada con la clave correcta como de que el mensaje no se haya alterado. Si las claves pública y privada son complementarias, lo que hace la una lo deshace la otra, de manera que se cumplirá que Ckp(Cks(h))=h. Por otro lado, una alteración siquiera mínima del mensaje hará que h´ (el resumen del mensaje alterado) sea distinto al resumen del mensaje original, y por tanto, h<>h´ significa M<>M´. De ese modo comprobamos de una sola tacada a) que el mensaje fue firmado efectivamente por Ana, b) que dicho mensaje no ha sido alterado con posterioridad.

Si deseamos efectuar ambas operaciones (cifrar y firmar), podemos hacerlo sin problemas. El orden seguido por muchos programas y protocolos (S/MIME, PKCS#7, PEM, PGP) es primero firmar, luego cifrar. Es decir, Ana primero creará su firma Cks(h), y posteriormente cifrará el paquete M´ = {M, Cks(h)}.

Las funciones resumen para criptografía habitualmente dan resúmenes h de entre 128 y 160 bits. Las más utilizadas son las denominadas MD4, MD5, RIPEMD-160 y SHA-1.


2.3 - El problema de la suplantación

En el capítulo anterior (1.4) se mencionaron dos problemas asociados a la criptografía de clave pública (CCP). Quedaba uno de ellos pendiente, a saber, el que denominaré problema de la suplantación. Recordemos que Ana necesita la clave pública de Belén para enviarle un mensaje cifrado. El problema que se plantea es: ¿cómo sabe Ana que la clave pública de Belén es realmente la clave pública de Belén? La belleza de la CCP consiste en que cualquiera puede obtener la clave pública de alguien, sin necesidad de pedirla a su propietario. Es como obtener el número de teléfono de alguien en la guía. ¿Qué pasa si alguien ha insertado un número de teléfono falso?

Los esquemas de CCP pueden volverse contra sus usuarios mediante el ataque del fisgón interpuesto [meet-in-the-middle]. Supongamos que Ana y Belén crean cada una su par de claves: (As, Ap) para Ana, (Bs, Bp) para Belén, (s indica clave privada; p, clave pública). Idealmente, Ana consigue la clave pública de Belén, Bp, en un servidor de claves (el análogo digital de la guía telefónica), y la usa para cifrar un mensaje; dicho mensaje será posteriormente descifrado por Belén con su clave privada Bs.
Pero nuestro fisgón Fausto entra en escena. Sin que las dos interlocutoras lo sepan, Fausto crea dos pares falsos de claves: Afs, Afp, Bfs y Bfp, y consigue sustituir las claves públicas verdaderas (Ap, Bp) por las que acaba de crear (Afp, Bfp). Cuando Ana o Belén vayan a cifrar un mensaje, lo hacen con las claves falsas, sin ser conscientes de ello. El proceso sería el siguiente:

- Ana cifra el mensaje con la clave pública falsa de Belén, Afp(M), y lo envía
- Fausto intercepta el mensaje y lo descifra con la clave privada falsa de Belén, Afs(Afp(M)) = M
- Fausto cifra el mensaje con la clave pública verdadera de Belén, Ap(M), y lo re-envía.
- Belén descifra el mensaje con su clave privada, As(Ap(M)) = M y recupera el mensaje.

Mediante esta suplantación, Ana cree estar protegiendo el mensaje con la clave pública de Belén, Belén cree haber recibido el mensaje directamente de Ana ... y Fausto está en medio, leyendo todos los mensajes e incluso componiendo mensajes falsos. El proceso de firma digital no sale mejor parado:

- Ana firma el mensaje con su clave privada, As(M), y lo envía.
- Fausto intercepta el mensaje, le retira la firma de Ana, firma el mensaje con la clave privada falsa de Ana, Afs(M), y lo re-envía.
- Belén recibe el mensaje, aplica la clave pública falsa de Ana a la firma y verifica correctamente el mensaje.

El talón de Aquiles, como puede verse, es que no hemos establecido una ligazón inequívoca entre la clave y el presunto propietario. Para asegurarnos de que Ana tiene la clave pública auténtica de Belén, ésta tendría que entregársela personalmente, o cuando menos enviársela mediante un canal seguro (no interceptable) de comunicación. Pero ese era el mismo problema que tenía la criptografía con clave simétrica. Incluso si se hace el esfuerzo de conseguir ese canal seguro o esa entrega en mano, no siempre sería factible, especialmente en estos tiempos de comunicaciones globales.


2.4 - La certificación de claves

El problema de la suplantación de claves delineado anteriormente se puede resolver si alguien de confianza nos asegura que la clave pública de Belén realmente pertenece a Belén. En el caso de la guía telefónica, nos creemos que el teléfono que aparece junto al nombre del abonado realmente pertenece a ese abonado. ¿En qué se basa esa creencia? Simplemente, en que confiamos que la empresa editora de la guía no nos engaña. Un nivel de confianza aún más alto podría venir de una certificación ante notario, ya que suponemos que el notario es una persona de confianza y que lo que él afirma es cierto.

En el mundo digital nos aprovechamos del hecho de que se puede firmar cualquier archivo o documento digital, incluida una clave pública. A fin de cuentas una clave pública ha de ser guardada en el ordenador en la forma de un archivo. ¿Por qué no se va a poder firmar ese archivo? La criptografía de clave pública contribuye así a reparar su propia debilidad.

El proceso para que Ana tenga la seguridad de poseer la clave pública auténtica de Belén sería el siguiente:

- Ana obtiene la clave pública del notario Np
- Ana recibe la clave pública de Belén Bp, firmada por el notario.
- Ana verifica (mediante el procedimiento indicado en el apartado 2.2) la firma digital del notario.
- Si la verificación es correcta, Ana sabe que la clave de Belén es auténtica. En ese caso se dice que la clave es válida. Esta validez proviene de la confianza depositada en el notario.

Este último paso se justifica considerando que el notario no firmará ninguna clave si no ha verificado antes que realmente pertenece a su dueño. Es como en el mundo de papel. Yo puedo firmar un contrato de hipoteca con el banco directamente. La intervención de un notario, sin embargo, le da mayor confianza a la transacción, ya que la firma del notario certifica muchas cosas: que los firmantes son efectivamente quienes afirman ser, que están legalmente capacitados para realizar la transacción, que han firmado el contrato libre y voluntariamente, que entienden lo que éste significa, etc.

El primer punto sigue siendo algo más escabroso. Necesitamos la clave pública del notario para verificar todo lo que éste firma, pero ¿cómo estar seguros de que no se trata de una clave falsa? A fin de cuentas, ¿cómo se que el notario frente al que me encuentro es realmente quien dice ser y no un falso notario? La paranoia no tiene límites, y como vemos la seguridad absoluta no existe.

En la práctica, suponemos que hay una forma razonablemente segura de obtener la clave pública verdadera del notario. Tal vez nos la ha entregado él personalmente, o quizá la hemos descargado de una página web segura. Pero tenemos una ventaja crucial: somos nosotros quienes decidimos cuánta confianza otorgar al notario. De hecho, podemos sustituir la palabra "notario" por "persona de confianza"

Una firma digital que atestigua la autenticidad de una clave pública se denomina genéricamente certificado digital. Habitualmente, un certificado digital consta de tres elementos: la clave pública que está siendo certificada, la información sobre el usuario y la firma digital (o firmas digitales) del notario o persona de confianza. Eso es lo que estamos acostumbrados a hacer. Saque el lector su DNI o pasaporte. ¿Qué contiene? Básicamente, información sobre el titular junto con ciertos elementos (marca de agua, firma policial, códigos diversos) que permiten verificar la autenticidad del documento. El mundo digital sigue las mismas pautas. Aunque con ciertas peculiaridades, como veremos a continuación


2.5 - El problema de la confianza

Imaginemos que tuviésemos que acudir a un notario cada vez que llamamos por teléfono. No resultaría muy práctico ¿verdad? Lo que hacemos es confiar en diversas personas o entidades: confiamos en que la guía telefónica es correcta, confiamos en que nos han dado bien el número cuando se lo pedimos a otra persona... en suma, decidimos en quién vamos a confiar para que nos cuente la verdad.

Un inconveniente de los esquemas de clave pública es que no existe una entidad o persona en quien todos confiemos ciegamente y sin restricciones. ¿Pero existe esa persona o entidad en el mundo real? No. Lo que hacemos es guiarnos por las informaciones y referencias de otras personas (que pueden a su vez ser de confianza o no) para decidir a quién creemos. Como resultado de ello, otorgamos nuestra confianza a unos y se la negamos a otros. Cuando usted estas palabras, está confiando implícitamente en que yo sé de lo que hablo y en que le estoy contando la verdad.

Hace algunos años una cadena de televisión italiana emitió un programa patrocinado por el "Cacao Maravigliao". Mucha gente, al ver dicho programa, confió en las propiedades -cualesquiera que fuesen- de dicho cacao, basándose quizá en los comentarios del presentador del programa, y a la mañana siguiente las amas de casa italianas asaltaron los comercios en busca de dicho cacao ... sin encontrarlo. Dicho "Cacao Maravigliao" simplemente no existía, era una inocente broma del presentador. Tiempo después, Emilio Aragón reprodujo dicho truco en su programa "Vip Noche". La película "Pijama para dos" trata de un tema similar: el protagonista (Rock Hudson) anuncia un inexistente producto, casualmente llamado Vip, mientras la inefable Doris Day intenta pisarle el negocio.

Si algo se puede sacar como moraleja, es que la confianza absoluta no existe, y que siempre hemos de andar por ahí con mirada crítica en lugar de tragarnos el primer anzuelo que se nos ponga por delante. Pero seamos realistas. No podemos construir un mundo en el que nadie se fíe de nadie. El agente Mulder tendría sus motivos para no confiar en nadie, pero eso nos pone a un mundo en contra y no nos lleva a ninguna parte. Y hasta Mulder confiaba de vez en cuando en alguien.

Así pues, si usted me pregunta ¿pero de quién puedo fiarme en este asunto de las claves públicas?, no puedo darle una respuesta satisfactoria. Nadie puede. Cada uno decide en quién confía, hasta que punto y con qué condiciones. Probablemente lo que ha leído vd. de este curso le permita confiar en mí como profesor, pero no como yerno o albacea testamentario.

Pero ese aparente inconveniente también conlleva un punto de fortaleza al sistema de criptografía mediante clave pública, ya que le permite elegir su agente de confianza. No hay nadie a quien estemos obligados a creer. No hay notarios impuestos por un tercero. Nosotros mismos construimos nuestra "red de confianza." De igual modo que una persona pueda confiar en todo lo que dice el periódico "El Mundo" mientras que a otro le dan sarpullidos con sólo tocarlo, cada uno de nosotros decidimos a quién otorgar nuestra confianza.

Los notarios digitales pueden ser cualesquiera, sean personas o entidades. Las entidades que se han creado para certificar claves públicas se denominan autoridades de certificación (AC, o CA por sus siglas en inglés). En la actualidad, impulsadas por la cornucopia del comercio electrónico, están surgiendo diversas AC. Mencionemos a modo de ejemplo Verisign (http://www.verisign.com) y Thawte (http://www.thawte.com) fuera de nuestras fronteras, ACE (http://www.ace.es) e IPS (http://www.ips.es) en España. Estas son una especie de "agencias notariales electrónicas" que certifican claves bajo pago. También existen AC sin ánimo de lucro, básicamente con fines de investigación o académicos, como la AC experimental de RedIris http://ca-tic.iec.csic.es . Estas AC están pensadas para certificar claves públicas en una conexión segura mediante navegador. Sus claves públicas (necesarias para que nuestro navegador pueda verificar los certificados emitidos por estas AC) se pueden descargar de la red, para lo cual hay que ir a la página web de dicha AC; algunas de estas claves públicas ya se encuentran en su navegador, ya que fueron entregadas por la AC directamente al fabricante. Los usuarios de Netscape Navigator, por ejemplo, pueden ver dichas claves en Seguridad/Certificados/Firmantes. Y ya que están, puden ver los algoritmos de cifrado simétrico que dicho navegador utiliza (Seguridad/ Navigator/ Configurar SSL v3).

En España la firma electrónica se ha usado a nivel oficial para, por ejemplo, rellenar la declaración de la Renta por Internet. Esto se hizo por primera vez en 1.999 dentro del marco del proyecto CERES de la Fábrica Nacional de Moneda y Timbre (FNMT), que fue la entidad que actuó como AC (http://www.cert.fnmt.es). Durante dicho año se aprobaron dos leyes sobre firma electrónica. Para los abogados y demás amantes de las leyes, son:


      Real Decreto 1290/1999 de 23 de Julio (BOE 10 Agosto 1.999), por el que se desarrolla el artículo 81 de la Ley 66/1997 de 30 Diciembre (BOE 31 Diciembre 1.997), por el cual se faculta a la FNMT para la prestación de los servicios técnicos necesarios para garantizar la seguridad de las comunicaciones electrónicas, informáticas y telemáticas entre los órganos de las administraciones del estado, y de las personas físicas y jurídicas con aquéllas. Ley disponible en http://www.map.es/csi/pdf/fnmt.pdf



      Real Decreto-Ley 14/1999 de 17 Septiembre (BOE 18 Septiembre 1.999) sobre firma electrónica. Trata sobre todo de las AC (llamados "prestadores de servicios de certificación") y está disponible en http://www.map.es/csi/pdf/electrnonica.pdf


El programa PGP es todavía más versátil, ya que cualquier persona puede hacer de notario digital. Ni siquiera es necesario que sea un notario real o que tenga un cargo oficial. Supongamos que Ana confía en Carlos. Puede que Ana no tenga acceso directo a la clave pública de Belén. Pero si Ana ve una clave presuntamente de Belén con la firma (equivalente al certificado digital) de Carlos, Ana aceptará dicha clave como propia, ya que confía en que Carlos es una persona que no va por ahí firmando claves alegremente, sino de forma responsable y comprobando qué es lo que firma.

La misma Ana puede convertirse en una otorgadora de confianza. Si recibe la clave de Belén y ha verificado que es auténtica, Ana puede firmar la clave de Belén. De ese modo, cualquiera que obtenga la clave de Belén y confíe en Ana aceptará dicha clave como válida. La confianza que inspira Belén en otros hace que esos otros aceptan las claves firmadas por Belén como válidas. De ese modo, cada persona va acumulando un conjunto de claves públicas, las cuales llevan adosadas diversas firmas que le otorgan una confianza mayor o menor. Es lo que se denomina "red de confianza" [web of trust].

PGP permite adaptarse igual de bien a una estructura jerárquica basada en ACs que a una red de confianza descentralizada, aunque fue creado pensado en esta última posibilidad. En palabras de su autor, "PGP es para aquellas personas que prefieren plegar su propio paracaidas." Permite una mayor flexibilidad y capacidad de elección. Y, puesto que este es un curso sencillo sobre PGP, es ya hora de pasar a ver el que espero se convierta en su programa de cifrado favorito. La introducción acaba aquí. Comienza la acción.

2.6 - Para ampliar conocimientos

http://www.cripto.es/informes/info003.htm (A. Quirantes) Los entresijos del firmado digital
http://www.cripto.es/informes/info010.htm (A. Quirantes) Pague sus impuestos ... digitalmente

Capítulo 4: PGPkeys


      4.1 - La ventana PGPkeys
      4.2 - Opciones de configuración
      4.3 - Antes de comenzar: copiar y revocar
      4.4 - Modificando claves
      4.5 - Para ampliar conocimientos


      Resumen Este capítulo nos enseñará a manejar la aplicación PGPkeys, corazón del sistema PGP. Aprenderemos a configurar correctamente el programa. A continuación, procederemos a manipular y modificar nuestras claves, incluyendo las opciones de revocación y creación de copias de seguridad.

4.1 - La ventana PGPkeys

Uno de los elementos más importantes en la criptografía de clave pública es la administración de claves. PGPkey nos ayuda grandemente en esa tarea. En primer lugar, veamos qué información nos da la ventana de dicho programa. Abra PGPkeys y active todas las opciones del menú View (ver). Verá las siguientes columnas (no necesariamente en este orden):

En primer lugar, la columna Keys (claves). Verá un conjunto de líneas con un icono en forma de llave y su nombre. Si siguió las instrucciones del capítulo anterior, verá la suya (en el ejemplo que usamos, se leería "Pepe Cripto " Este es el llamado Identificador de Usuario (User ID); no confundir con el identificador de clave (Key ID). Esta columna nos dará mucha información, así que la dejaremos para más adelante.

Las demás columnas nos representan lo siguiente:


      Validity (validez) Nos indica si la clave se considera "válida", es decir, si tenemos razones para creer que la clave realmente pertenece a la persona que aparenta pertenecer. Una clave válida viene representada por un círculo verde, una no válida por un círculo gris. Nótese que "no válida" no significa defectuosa o que no se pueda usar, sino que no tenemos certeza sobre su propietario. Compruebe que solamente una clave tiene validez: la suya propia. De hecho, aparece la figura de una cabeza junto al círculo (igual que aparece junto al icono en forma de llave de la izquierda). Eso indica que la clave le pertenece, es decir, que la clave privada correspondiente a esa clave pública está en su poder.


      Trust (confianza) Si la validez se refiere a la clave, la confianza se refiere a la persona dueña de ésta. Una clave de confianza (más correctamente, una clave perteneciente a una persona de confianza) vendrá representada mediante una barra gris oscura. Si la barra es mitad gris oscura y mitad gris clara, la confianza es "marginal", es decir, parcial. Si no tenemos confianza en el dueño de la clave, ésta vendrá con una barra gris claro. La clave que usted creó será gris oscura con franjas gris claro, inclinadas y delgadas; esto indica que la clave es de "confianza implícita", ya que la creó usted.


      Size (tamaño) Indica el tamaño de la clave, en bits. Si la clave es de tipo RSA (icono llave de color gris), aparecerá un solo número. Si es de tipo Diffie-Hellman (icono llave de color marrón), tendrá dos dígitos: el primero de ellos es el tamaño de la clave de cifrado, y el segundo el de la clave de firma.



      Creation (creación) y Expiration (caducidad) Indican, como puede imaginar, la fecha de creación de la clave y la de caducidad. Si la clave no caduca (lo más habitual), veremos un Never (nunca).



      Key ID (Identificador de clave) Es un conjunto de ocho caracteres hexadecimales, precedidos por "0x", y que identifican la clave. Es de la forma "0x2113D9F9"


      ADK (Clave de Descifrado Adicional)¿Recuerdan que la clave pública cifra una clave simétrica (clave de sesión), la cual a su vez cifra el mensaje? Bien, pues una de las cosas que se puede hacer es cifrar con más de una clave pública, con el objeto de que diversos destinatarios puedan descifrar el mismo mensaje. La ADK es un sistema por el que cualquier mensaje se cifra siempre con dos claves: la del destinatario y una segunda (la ADK) controlada por la empresa o el administrador de red. Este sistema está diseñado para entornos empresariales, con objeto de que la empresa pueda tener cierto control sobre los mensajes cifrados por el empleado (por ejemplo, en caso de ausencia de éste, fallecimiento, o despido). Aunque su programa PGP no tiene esta opción, es bueno saber cuándo una clave pública funciona bajo el sistema de ADK. Una clave con ADK viene indicada por un círculo rojo; sin ella, el círculo es gris. Esta es una opción que aún no es muy usada. Yo, cuando menos, todavía no he visto ninguna clave con ADK.


      Description (descripción) Nos indica qué tenemos ahí. Los mensajes indican claves públicas (RSA public key o DH/DSS public key), claves caducadas (Expired RSA public key o Expired DH/DSS public key) y nuestro propio par de claves (RSA key pair o DH/DSS key pair). Pero si pincha en el cuadradito que hay a la izquierda del icono con la llave, aparecerán más cosas (ID de usuario, firmas exportables y a veces hasta fotografías). Pronto veremos qué sorpresas nos guardan todavía. Pero antes tenemos que ajustar el programa a nuestro gusto.

      Nota: para los usuarios de PGP 7.0, las refencias específicas a claves RSA se entenderán hechas a las creadas con versiones anteriores del programa (las llamadas "RSA Legacy Keys"). En lo demás, no hay diferencias entre los formatos RSA y DH en PGP 7.0

4.2 - Opciones de configuración

Antes de poder seguir adelante, conviene configurar el programa. Para ello, vamos al menú Edit/Options. Aquí nos encontramos con siete pestañas. Vamos a por ellas, que son pocas y cobardes.

Primera pestaña: GENERAL. Primero nos encontramos con la opción Cifrar siempre con clave predeterminada (always encrypt to default key). Recordemos que, una vez cifrado un mensaje, ni siquiera la persona que acaba de cifrarlo puede descifrarlo. Eso resulta bastante molesto, porque no podemos guardar copias legibles de nuestros mensajes salientes. La solución es cifrar con dos claves: la del destinatario y la nuestra propia. Así podremos descifrar siempre los mensajes que hemos cifrado. Recomiendo activar esta opción.

En segundo lugar, la opción Generación rápida de clave (Faster key generation) Esto permite agilizar la generación de una clave Diffie-Hellman, gracias al uso de números primos precalculados. No parece que usar "primos enlatados" disminuya la seguridad, pero tampoco pasa nada por desactivar esta opción y esperar algo más de tiempo cuando creemos una clave. Cosa que, por otro lado, no va a ocurrir todos los días.

A continuación, la opción Frase de descifrado en caché durante ... (Cache decryption passphrase for ...) junto con un intervalo de tiempo. Como su nombre indica, permite que la contraseña permanezca en memoria durante el tiempo escogido. Esto permite poder descifrar diversos mensajes durante ese período de tiempo, sin necesidad de introducir la contraseña una y otra vez. Es una opción cómoda, pero con riesgos: cuanto más tiempo permanezca la contraseña en memoria, más facilidades se le están danto a un atacante potencial para capturarla mediante algún troyano o "fisgón". Si quiere ir a lo seguro, desactive esta opción. La casilla Frase de firmado en caché durante ... (Cache signing passphrase for ...) hace lo mismo, pero para los procesos de firma.

El espacio para el bloque de comentario (Comment block) permite introducir un pequeño comentario que aparecerá en los archivos o mensajes cifrados o firmados por usted. Puede poner su ID de clave, algún mensaje personal, o nada en absoluto.

Para terminar aquí, la opción Borrado de Archivos (File wiping) nos permite usar una opción de PGP: la de borrado seguro PGPWipe. Cuando se "borra" un archivo en Windows, el archivo no se ha borrado físicamente. Simplemente, el lugar que ocupaba en disco se marca como reutilizable. PGPWipe permite borrar realmente dicho lugar en disco sobreescribiéndolo. Tomando como analogía una cinta de video, sería la diferencia entre simplemente rotularla "para volver a grabar" y grabar sobre ella varias veces. Podemos elegir si el programa nos va a Avisar antes de borrar (Warn before wiping), así como el número de veces que se va a sobreescribir el archivo.

Segunda pestaña: FILES (ARCHIVOS). Nos indican la ubicación de tres archivos importantes. Dos de ellos almacenan nuestras claves públicas (Public Keyring File) y nuestras claves privadas (Private Keyring File), y llevan los nombres de pubring.pkr y secring.skr, respectivamente. De forma predeterminada, se hallan en el mismo directorio donde instalamos PGP, subdirectorio PGP Keyrings. El tercer archivo, ubicado en el mismo subdirectorio, se llama randseed.rnd (puede tener otra extensión, como .bin). Es el archivo (Random Seed File) que guarda información aleatoria, necesaria entre otras cosas para generar claves de sesión aleatorias. Puede indicar aquí una ubicación distinta para los tres archivos, !pero asegúrese de que dichos archivos realmente se encuentran donde usted cree!

Tercera pestaña: EMAIL (CORREO ELECTRÓNICO). La primera opción es la de usar PGP/MIME al enviar correo (Use PGP/MIME when sending email Esto permite utilizar de forma predeterminada el protocolo PGP/MIME, que no tiene sentido explicar aquí, pero que facilita las cosas al destinatario si el programa de correo electrónico soporta el estándar PGP/MIME ... y se las complica en caso contrario. Para no liar las cosas, por tanto, mejor no activar esta casilla de momento.

Las casillas Cifrar, firmar nuevos mensajes por defecto (Encrypt, Sign new messages by default) se explica por sí sola: automatiza el proceso de cifrado y de firmado, esto es, cualquier mensaje que envíe será cifrado y firmado de forma predeterminada. Como no siempre va a cifrar los mensajes o a firmarlos, no hace falta activarlas ... al menos, por ahora. En cuanto a la casilla Descifrar/verificar automáticamente al abrir mensajes (Automatically decrypt/verify when opening messages), es asimismo evidente: pasa automáticamente a descifrar el mensaje, o a verificar la firma, sin esperar a que usted lo ordene. Por supuesto, para descifrar se le pedirá la contraseña, a no ser que haya activado la opción de guardar contraseña en caché tal como se explicó para la pestaña anterior.

La opción Usar siempre Visor Seguro al descifrar (Always use Secure Viewer when decrypting) es solamente apta para ultraparanoicos. Al activarla, se utilizará un tipo de letra específialmente diseñado para evitar en lo posible la emisión de señales de radiofrecuencia por parte del monitor, señales que en teoría podrían ser recogidas por un fisgón electrónico con equipo adecuado (los denominados ataques Tempest). Una chuchería curiosa, pero seamos serios. Si el CESID tiene equipos Tempest (y dudo que alguien más en España tenga acceso a esa tecnología), seguro que tienen mejores cosas que hacer que aparcar una furgoneta Tempest en la puerta de su casa. Y si usted es lo bastante importante para merecer ese tipo de atenciones, créame, hay formas mucho más sencillas de intentar acceder a sus datos.

Mucho más importante es la siguiente opción: la del ajuste de línea (Word wrap) Esto indica qué longitud tendrán las líneas del mensaje, una vez cifrado o firmado con PGP. Puede elegir la longitud que desee (la que aparece predeterminada es de 70 caracteres/línea). Pero ATENCIÓN: asegúrese de que el ajuste de línea de PGP sea menor que el de su programa de correo electrónico . De lo contrario, éste introduciría retornos de carro adicionales que invalidarían la firma en un mensaje.

Cuarta pestaña: HOTLEKS (TECLAS RÁPIDAS). Facilitan el uso de PGP. Si, por ejemplo, activa la casilla Cifrar ventana actual (Encrypt current window), podremos cifrar el contenido de la ventana que se esté usando en ese momento (la de WordPad, de Word .. la que sea) sin más que teclear simultáneamente las teclas que usted indica, por ejemplo Control+Mayúsculas+E. Es una alternativa al uso de PGPtray, que veremos más adelante. Puede activar estas casillas o no, a su gusto.

Quinta pestaña: SERVERS (SERVIDORES). Un servidor de claves es un "depósito" donde podemos obtener la clave pública de la persona a la que queramos enviar un mensaje cifrado. Es un sistema muy cómodo, más aún desde que PGP permite hacer búsquedas desde el mismo PGPKeys (menú Server/Search). Uno de los servidores -puede tener más de uno- será el predeterminado y va señalado con letra negrilla; será aquél al que PGP se dirigirá para la búsqueda, a menos que determine vd. lo contrario. Podemos borrar un servidor ya existente, editarlo, o incluir uno nuevo. Ya que estamos, pruebe a introducir un servidor nuevo. Pondremos el de RedIris. Al añadir un servidor nuevo, indique el protocolo de transmisión de datos (en la mayoría de los casos, como ahora, http), el nombre (pgp.rediris.es) y el puerto de comunicación (11371). Para otros servidores, estos datos pueden variar.

A continuación, diversas opciones de sincronización (Synchronize). La sincronización significa sencillamente obtener del servidor de claves la versión más moderna de una clave pública con objeto de actualizarla. Recordemos que constantemente las claves pueden ser firmadas, modificadas, revocadas... es decir, se encuentra en evolución. Puede que hace seis días alguien en quien yo confío haya firmado una clave y la haya enviado al servidor. Si yo voy a usar dicha clave, la firma de esa persona de confianza me ayuda a establecer la validez. Podemos elegir que se actualicen claves (Synchronize keys upon...) en estos casos.

      Cuando queremos cifrar un mensaje a un destinatario cuya clave no tenemos en nuestro archivo (... encrypting to unknown keys).

      Cuando vayamos a firmar una clave. El servidor nos enviará la última versión de dicha clave antes de firmar, y enviará la clave de nuevo al servidor una vez vd. la haya firmado.

      Cuando queramos añadir nombres (IDs de usuario), fotos o revocadores; ver más adelante ese concepto (Adding Names/Photos/Revokers)

      Cuando queramos revocar una clave (Revokation)

      Cuando queramos verificar una firma en un mensaje (Verification)

Sincronizar resulta bastante cómodo, aunque no es necesario. Puede hacerlo "a mano" buscando en el servidor de claves, como ya veremos.

Sexta pestaña: CA (CA) Si fueron buenos lectores, recordarán que en un capítulo anterior hablamos de las Autoridades de Certificación (AC). Esta casilla permite elegir una AC para poder usar certificados X.509 similares a los usados por los navegadores en sus conexiones seguras. Parece un modo de uncir PGP al carro comercial de las AC. De todos modos, PGP suele usar las firmas de claves (paciencia, ya llegaremos) para establecer la validez de una clave. Así que "pasamos" de esta pestaña.

Séptima pestaña: ADVANCED (AVANZADAS) La opción algoritmos preferidos (preferred algorithm) nos permite decidir qué algoritmo de clave simétrica queremos como predeterminado. A menos que usted lo cambie (de momento, mejor que no), aparece el algoritmo CAST. Se puede elegir entre CAST, IDEA y TripleDES. También podemos decidir los algoritmos permitidos (allowed algorithms); esta opción es solamente útil si en el futuro alguno de estos algoritmos se demuestra que tiene graves fallos que lo hacen presa fácil de ataques criptoanalíticos (!esperemos que no!). Deje los tres activados.

Después viene un ajuste fino al modelo de confianza. Como nada es blanco o negro, puede que una clave sea solamente "semiválida". Esto puede suceder si está firmada por una persona en la que tenemos confianza media (marginal). Puesto que confiamos "a medias" en esa persona, aceptaremos "a medias" las claves firmadas por esa persona. Activar la casilla mostrar nivel de validez marginal (display marginal validity level) sustituye la bola gris/verde (validez/invalidez) en la columna "validity" por una barra donde la cantidad de gris oscuro indica el grado de validez de dicha clave. Por lo general, dicha barra será mitad gris oscura cuando solamente la haya firmado una persona que tiene confianza marginal; será oscura del todo cuando la haya firmado una persona de total confianza (incluyéndonos a nosotros), o al menos dos personas con confianza marginal. Le recomiendo que active de momento esta opción; así podrá familiarizarse mejor con el "modelo de confianza" de PGP.

Más ajuste fino. Si una clave está firmada por una sola persona con confianza marginal, se supone que la validez es marginal, y así aparece si hemos activado la casilla "mostrar nivel de validez marginal" mencionada anteriormente Pero si esta casilla no está activada, ¿cómo aparece la bola de la columna "validity", gris o verde? O, dicho de otra manera, ¿aceptamos la clave como válida o no? Activando la casilla tratar claves de validez marginal como no válidas (treat marginally valid keys as invalid) la respuesta es negativa; harán falta al menos dos personas de confianza marginal para que una clave quede marcada como válida.

Si está activada la casilla avisar cuando se cifra a claves con una ADK (Warn when encrypting keys with an ADK), el programa nos avisa cuando ciframos un mensaje a un destinatario cuya clave tiene una ADK asociada (ya hemos visto ese concepto antes). Esta opción es recomendable porque el remitente tiene derecho a saber si existe dicha ADK, esto es, si el mensaje puede en principio ser descifrado por alguien más.

Por último, una opción importante a efectos de compatibilidad. PGP versión 5.x y anteriores no tienen opciones tales como fotografías o certificados X.509 en las claves. Por tanto, si exporta su clave puede que un usuario de versiones anteriores a la 6.0 no pueda importarla en su archivo de claves. Para mantener la compatibilidad, y permitir que usuarios de versiones antiguas y modernas pueda intercambiarse claves, es conveniente activar la opción de formato de exportación Compatible. Si escoge el formato Completo (Complete), su clave incluirá fotos y certificados, pero un usuario de digamos la opción 5.5 no podrá usar dicha clave para enviarle mensajes a usted. Recomiendo exportar claves en formato compatible. A fin de cuentas, los certificados X.509 aún no se usan en PGP ... y la opción de incluir una fotografía con la clave, en mi opinión, no sirve más que para aumentar el tamaño del archivo de claves. Aunque si quiere usted mostrar su belleza al mundo, no seré yo quien se lo censure.

4.3 - Antes de comenzar: copiar y revocar

Sí, ya sé, ¿cuándo comenzamos a cifrar y firmar? Muy pronto, se lo prometo. Pero antes es necesario tomar precauciones. Parece innecesario, pero créame, a tenor de los muchos mensajes de ayuda del tipo "socorro, no sé que hacer, resulta que ..." que he leído, mejor prevenir que curar.

Lo primero que vamos a hacer es una copia de seguridad de los archivos de claves. Un despiste, un "cuelgue" inoportuno del sistema operativo, un borrado accidental ... y nuestros archivos de claves pueden quedar cuando menos dañados. La solución no puede ser más sencilla: copiar los archivos pubring.pkr y secring.skr que contienen, respectivamente, las claves públicas y privadas almacenadas por usted. Puede guardarlas donde quiera, pero le recomiendo prudencia, sobre todo en relación al archivo de claves privadas. Un atacante que tenga una copia del archivo secring.skr tiene la mitad del trabajo hecho. De todos modos, le resultará inútil sin una copia de su frase de contraseña (passphrase), pero ¿por qué ponérselo fácil? Guarde celosamente una copia de esos archivos. Lo mejor es tenerlos en una partición cifrada, o en su defecto en un disquete separado.

En cualquier caso, PGP está al loro. Si ha creado usted un par de claves (o más), cuando cierre PGPkeys se le preguntará si quiera grabar una copia de seguridad o no. Usted mismo.

A continuación, vamos a revocar la clave privada. Revocar no es más que decir al mundo: esta clave ya no está bajo mi control, no la uséis más. Esto sucede cuando tenemos la sospecha de que alguien más puede tener una copia de nuestra clave privada. Vale, usted tiene el celo guardián de un pitbull. Pero ¿qué tal andamos de memoria? El principal motivo de la pérdida de control sobre una clave es el olvido de la frase de contraseña. Si usted se olvida de dicha contraseña, se acabó el descifrar o verificar con esa clave. Lo mismo le daría haber tirado a la basura su clave privada. Pero los demás usuarios que tengan copias de la clave pública de usted generalmente no lo sabrán, y puede vd. encontrarse con múltiples mensajes que no puede descifrar.

La solución es la revocación. En lugar de simplemente tirar la clave privada a la basura, la revocación modifica la clave pública, de manera que una persona que tenga dicha clave no podría cifrar, ya que PGP se lo impedirá. Por supuesto, una de las cosas que no podemos hacer sin la clave privada es revocarla. Pero si no podemos usarla, ¿cómo vamos a revocarla? El truco es guardar una copia del certificado de revocación antes de que suceda lo irreversible.

Vamos a revocar la clave. Pero antes, una advertencia: asegúrese de que la casilla "synchronize keys upon revokation" (Menú Edit\Options\Servers) esté desactivada antes de comenzar. ¿Ya lo ha comprobado? Estupendo, porque de no ser así PGP enviaría a los servidores de claves el certificado de revocación, y eso no nos interesa.

Para empezar, lo primero que hay que hacer es una copia de ambos archivos de claves (llámelos, por ejemplo, secringr.skr y pubringr.pkr). Adopte éstos como sus archivos de claves en el menú Options/Files. A continuación, pinche sobre el ratón en la clave a revocar y elija Keys/Revoke (también vale usar el botón derecho del ratón). Tras un (sabio) aviso sobre si sabemos lo que vamos a hacer (respuesta: sí), se pedirá la contraseña. Y listo, la suerte está echada. Ahora su clave aparece en PGPkeys con letra cursiva, y el icono de llave que había a la izquierda tiene ahora una x roja.

Ahora, exporte la clave mediante la opción Keys/Export, con el nombre y en el directorio que desee (mejor en disquete). Si algún día ha de usarla, no tiene más que enviar dicho archivo a un servidor de claves. Guarde bien este certificado de revocación, porque si alguien lo consigue podría enviarlo a los servidores de claves, haciendo creer a todo el mundo que esa clave ya no se puede usar. Eso no le da acceso a mensajes cifrados o a suplantación alguna, pero le obligaría a usted a crear un nuevo par de claves, ya que todos creerán que la clave anterior ya no sirve. Un fastidio.

Y ahora, vuelva a dejar PGP como antes. Es decir, sustituya los archivos secring.skr y pubring.pkr de PGP por la copia que vd. hizo de esos archivos antes de la revocación. Y ahora, intente revocar una clave que no sea suya. Como ve, no es posible. Solamente se pueden revocar las claves propias. Y otra cosa: no es necesario perder el control de una clave para querer revocarla. Puede que simplemente deseemos usar otra clave.

4.4 - Modificando claves

Echemos un vistazo a la clave que hemos creado. Pinche sobre su clave y vaya al menú Edit/Expand Selection (o bien pinche sobre el cuadradito que hay a la izquierda del icono de la clave). Sorpresa, la clave se ha "abierto" y aparecen más elementos. Todo forma parte de la clave. La primera línea es la misma que teníamos antes: validez, confianza, tamaño, ID de clave, etc. En la columna Description aparece "DH/DSS key pair", lo que indica que representa un par de claves Diffie-Hellman (o RSA, si es el caso).

Después viene un icono con forma de sobre, que nos da el identificador de usuario (User ID). Este es el "nombre" que le damos a la clave, y que suele corresponder con el nombre (real o ficticio) del usuario y su dirección de correo electrónico. Podemos cambiar fácilmente ese ID por otro. Finalmente, aparece una tercera línea con un icono en forma de lápiz. Es la firma digital. Como ve, la clave (-ás correctamente, el identificador de la clave- está firmada por ella misma. Esto parece una tontería, pero nos asegura que dicha clave no puede alterarse (existen maneras de alterar una clave pública). Si usted no recuerda haber firmado su propia clave, es porque PGP la ha firmado tras el proceso de creación.

Vamos a "jugar" con nuestra clave privada. Ponga el ratón sobre la primera línea de la clave, y presione el botón derecho del ratón. Lo primero que vemos son los comandos Copiar (Copy) y Pegar (Paste), típicos de cualquier aplicación Windows. Después, la de Borrar (Delete). No se la recomiendo ... a no ser que se haya cansado de la criptografía de clave pública. A continuación, algo interesante: firmar (sign). Como recordará el atento lector, firmar una clave implica dar validez a ésta. No podemos validar nuestra propia clave (de hecho, ya está firmada), así que haga la prueba de firmar una clave cualquier. Pinche sobre cualquier otra clave y escoja la opción de firmar.

Aparece entonces una ventana PGP sign key. En la parte superior hay un mensaje recordándonos que, al firmar, certificamos que la clave que firmamos realmente pertenece al usuario que aparecen en el User ID. Luego aparece una casilla que dice "permitir que la firma sea exportable. Otros podrán así fiarse de la firma de usted" (Allow signature to be exported. Others may rely upon your signature). Si no activamos dicha casilla, la firma será no-exportable. Esto significa que si usted exporta posteriormente dicha clave (en forma de archivo, o enviándola a un servidor de claves), la firma no aparece. Es decir, la firma que vd. acaba de hacer no sale de PGPkeys. Existen algunas circunstancias en las que esto resulta aconsejable, pero lo habitual es hacer la firma exportable. De ese modo, la "red de confianza" se va tejiendo y quien confíe en usted aceptará la firma en una clave, dando por tanto dicha clave por válida. Le recomiendo que firme siempre con firma exportable.

Haga la prueba. Escoja una clave cualquiera y fírmela. De repente, la validez de dicha clave es total. Esto se debe a que, al firmarla, usted certifica que esa clave es de quien pretende ser. Firmar una clave es algo que no debe hacerse a menos que se esté seguro de ello. No la firme simplemente para que desaparezca el aviso de key invalid que aparece cuando comprobamos una firma hecha con una clave no válida. Si posteriormente desea quitarle la validez a una clave firmada por usted, basta con que borre esa firma. Para ello, despliegue la clave (Edit\Expand selection), y verá la firma que vd. hizo en la forma de icono con forma de lápiz. No tiene más que borrar dicho icono, y listo. Alternativamente, puede que la validez provenga de la firma de alguien en quien usted ha depositado su confianza, es decir, alguien cuya clave sea de confianza (trusted]). Borre esa firma si quiere usted eliminar la validez de la clave ... aunque no sé por qué querría usted hacer tal cosa.

También puede modificar la confianza de una clave -más correctamente, del dueño de una clave.- Para ello, hay que operar sobre la barra Trust model que aparece en las propiedades de dicha clave. Puede convertir una clave de confianza (trusted) en una clave no confiable (untrusted) o de confianza media, moviendo el indicador que allí aparece. No intente hacerlo con su propia clave, porque PGP no le dejará. Se supone que usted confía en usted mismo (!de no ser así, no debería ni firmar cheques!), por lo que las claves que usted creó aparecen siempre como de confianza irrevocable (implicit trust).

Sigamos con la ventana PGP sign key En la parte inferior izquierda hay un botón que reza Más opciones (More choices) Aparece aquí un ente nuevo: el "meta-presentador" (meta-introducer). Esto suena raro, pero la idea subyacente es sencilla. Recordemos que podemos otorgar validez y confianza a una clave. Cuando firmamos una clave (o cuando ésta contiene la firma de alguien de confianza), solamente la estamos validando. Para darle confianza, hemos de fijársela "a mano" (Key Properties/Trust Model/ Trusted-Marginal-Untrusted). Un meta-presentador es, por definición, alguien de confianza absoluta, de manera que cualquier clave firmada por él será automáticamente considerada como válida por nosotros. Puede probarlo firmando con firma Meta-Presentadora (exportable o no) la clave denominada "Network Associates TNS Division Employee Certification Key" (puede tener un nombre ligeramente diferente, si usa usted PGP 7.0). De repente, casi todas las claves aparecen como válidas. Son aquellas que han sido firmadas con la clave"Network...etc" Abra cualquiera de dichas claves (Edit/Expand Selection) y podrá comprobarlo.

Igual que con las firmas sencillas, que podían ser exportadas o no, los meta-presentadores podemos establecerlos de "puertas adentro" (Meta-Introducer Non-Exportable) o de "puertas afuera" (Trusted Introducer Exportable). Para simplificar, firmar una clave como meta-presentador es como firmar esa clave y, a continuación, otorgarle confianza máxima. Con una diferencia: en ese último caso podemos "ajustar" el nivel de confianza deseado (total, marginal o nulo), en tanto que un meta-presentador es siempre de confianza total. Si le parece complicado, simplemente olvídese de ellos y limítese a establecer la confianza del modo tradicional: mediante el menú de propiedades de clave (Key/Properties).

¿Qué, se va animando? Pues vamos a continuar con nuestra clave recién creada. Una de las cosas que podemos hacerle es añadirle elementos (Add). Podemos en primer lugar añadir un nuevo nombre (Name) a la clave. Esto resulta muy útil cuando se desea modificar el nombre de la clave (User ID), por ejemplo por un cambio de dirección de correo electrónico. Muchos usuarios preguntan "he cambiado de cuenta, ¿tengo que crear un nuevo par de claves?" La respuesta es que no.

Supongamos que nuestro Pepe Cripto quiere abandonar su dirección pepecripto@micasa.com, en favor de pepe@cripto.com. No tiene más que añadir el nombre (Add/Name) e introducir la contraseña. Y ahora aparece el nuevo nombre. Si "abrimos" la clave, comprobaremos que tiene dos iconos de sobre, correspondiente a los dos ID de usuario, el antiguo y el nuevo. El nuevo ID de Usuario está firmado por sí mismo, y el ID antiguo está firmado por el nuevo (esto es para relacionar ambos IDs). Es conveniente mantener el ID antiguo, porque si no los demás no sabrán que se trata de la misma clave con distinto collar. ¿Y si queremos cambiar de opinión y dejar el ID antiguo? Pues no hay más que pinchar sobre él y elegirlo como ID predeterminado (Set as Primary Name).

También podemos añadir una fotografía nuestra (Add/Photo), chuchería simpática pero poco útil. Y también se puede añadir un revocador (Revoker). ¿Y qué es un revocador? Pues una persona a quien otorgamos la facultad de revocar nuestra clave. Es decir, si usted pincha sobre su clave, elige Add/Revoker y seleccciona mi clave, significa que yo podré, con mi clave privada, revocar su clave. De hacer eso, en su clave (Key/Properties) aparecerá una tercera pestaña denominada Revocadores (Revokers). Puede tener todos los revocadores que desee, o ninguno en absoluto.

Esto resulta útil para aquellos usuarios que confíen tanto en otro como para depositar la prueba máxima de confianza: la capacidad de desactivar una clave permanentemente. Como entregarle un poder notarial, vamos. Personalmente, prefiero no otorgar tales poderes a nadie. A fin de cuentas, revocar una clave no es algo que precise usted hacer todos los días ... y recuerde que no se le puede "quitar los poderes" a un revocador. Esta opción, como la de meta-presentador, puede ser útil en entornos corporativos, donde un "maestro cerrajero" ha de tener poder reparar los desaguisados hechos por los usuarios. A nivel de usuario, basta con convertirnos en nuestros propios revocadores y, si llega lo peor, "rematar" nuestra clave nosotros mismos con la orden Revocar (Revoke).

Como penúltimos detalles, se puede añadir un certificado (Certificate) tipo X.509. Esto requiere tener designado una Autoridad de Certificación (AC) en las opciones. De hecho, yo nunca he podido usar dicha opción, y tampoco resulta necesaria. Es, con todo, un nexo de unión entre los mundos PGP y SSL. Otro detalle es que, si tenemos varios pares de claves de nuestra propiedad, uno de ellos aparece con letras negritas en la ventana PGPkeys. Esto designa la clave predeterminada, esto es, la que se usará para descifrar/firmar a menos que indiquemos otra cosa. Podemos elegir nuestra clave predeterminada sin más que pinchar sobre ella y elegir Establecer como Predeterminada (Set as Default)

Por cierto, como habrá podido comprobar, cualquier adición a nuestra clave requiere de la contraseña, ya que esos privilegios no están autorizados a nadie más. Usted no podrá añadir nada a una clave pública que no le pertenezca. Pruebe y verá.

Se nos está alargando el tema algo más de la cuenta, pero continuemos un poco y agotemos el tema. Siguiendo en nuestro "trasteo" de claves, lo que sigue podemos aplicarlo tanto a nuestras claves como a cualquier clave pública. Podemos verificar las firmas que tienen las claves, por ejemplo para comprobar que ninguna ha perdido validez por haber sido firmada con una clave caducada (Reverify signatures), actualizar dicha clave obteniendo la versión más actualizada en el servidor de claves (Update), enviarla a un servidor de claves (Sent to), ver sus propiedades (Key Properties) y exportarla como archivo (Export)

También podemos hacer algo que suena demoledor: dehabilitar una clave (Disable). La idea es la siguiente. Si usted cifra un mensaje de correo electrónico, aparecerán todas las claves públicas en una pantalla para elegir una, y esto puede resultar engorroso si vd. ha acumulado muchas de ellas. Puede borrar algunas de ellas, pero a lo mejor no desea desprenderse de ellas, no vaya a necesitarlas en el futuro. La solución es la deshabilitación. Al deshabilitar una clave se está diciendo al programa que no la tenga en cuenta a la hora de cifrar, de manera que no tendremos que tenerla en cuenta cuando cifremos mensajes. De todos modos sigue estando en nuestro archivo de claves y apareciendo en la ventana PGPkeys (aunque en letra cursiva, para distinguirla de las demás).

No confunda este término con otros. Deshabilitar no significa invalidar, revocar o perder la clave. Cuando nos haga falta, podemos re-habilitarla (Enable). Si el archivo de claves públicas fuese una agenda de teléfonos, imagínese el conjunto de claves habilitadas como esa agendita minúscula que llevamos en la cartera con solamente unos pocos números de teléfono de uso más frecuente. Inhabilitar es, simplemente, poner las hojitas con los teléfonos poco usados en un cajón, donde no molestan pero están a mano para cuando los necesitemos.

Y para terminar, una opción de lo más curiosa: la partición de claves (Share split). Supongamos que usted desea dejarle a sus hijos un documento digital importante, digamos un poder notarial, de forma que decide cifrar dicho documento. El problema es que usted quiere que todos ellos, o al menos unos cuantos, se pongan de acuerdo antes de descifrar el documento, de manera que no pueda uno de ellos usarlo para pulirse la herencia de la familia. Incluso si el depositario de la clave es de confianza, ¿qué hacemos si para su desgracia le atropella un autobús? La solución es "trocear" la clave mediante un procedimiento denominado separación de Blakely-Shamir. De esa forma, solamente mediante la unión de un número de "trozos" (no tienen por qué ser todos) se puede reconstruir la clave.

Ya ven, milagros de la criptografía moderna. Y es que los tiempos adelantan que es una barbaridad. El mero hecho de cifrar o firmar con una clave nos permite un gran número de posibilidades. Espero que no se haya visto usted abrumado con la cantidad de conceptos, opciones y posibilidades de PGPkeys. Mi intención no es confundirle, sino mostrarle todo lo que PGP permite hacer a un usuario. Y no hemos acabado todavía.

Pero el resto es cosa del siguiente capítulo. Mientras tanto, abra PGPkeys y familiarícese con él. Firme, revoque, añada IDs de usuario ... pero no lo haga como una obligación. Tómeselo con calma. Vaya a su propio ritmo, familiarizándose con el esquema de administración de PGP. Y sobre todo, disfrute con ello.

4.5 - Para ampliar conocimientos

Esta vez voy a incluir algunos "deberes". No son obligatorios, y nadie tendrá que repetir curso si suspende. Hace algún tiempo redacté un pequeño Informe donde intento aclarar los conceptos de confianza y validez. Cuenta con la participación estelar del señor Sherlock Holmes, su ayudante doctor Watson y demás personajes salidos de la pluma de Conan Doyle. Se incluye un archivo .zip con diversos archivos de claves públicas y privadas, para que pueda usted "trastear" por su cuenta:


      http://www.cripto.es/informes/info009.htm Informe 9: Confianza, validez y el doctor Watson


      http://www.cripto.es/informes/holmes.zip Archivo de prueba comprimido (holmes.zip). Incluye diversas claves públicas, y archivos de claves públicas y privadas (extensiones .asc, .pkr y .skr, respectivamente).

Todas las claves privadas tienen la misma frase de contraseña. Mención especial para el primero en averiguarla

Capítulo 6: Miscelánea PGPera


      6.1 - Netiqueta
      6.2 - ¿Es usted un terrorista?
      6.3 - Presente y futuro de PGP
      6.4 - Cajón desastre
      6.5 - Despedida


      Resumen ¿Tiene futuro PGP? ¿Cuántos usuarios hay en el mundo? ¿Por qué molestarse en cifrar, si no tengo nada que esconder? ¿Es realmente seguro? ¿Hay algún código de "netiqueta" adecuado para PGP? ¿Qué es una "reunión de firma de claves"? Esta y otras preguntas similares serán revisadas en el último capítulo del Curso sencillo de PGP, que servirá como cierre aunque -espero- no como despedida.

6.1 - Netiqueta

A estas alturas puede que se encuentre cansado de atenderme (aunque confío que no) y/o deseoso de lanzarse al mundo del cifrado digital. Pero ya que estamos, vamos a redondear la faena. En primer lugar, compartiré con usted un par de comentarios personales sobre cómo usar y no usar PGP, una especia de "código de buenas costumbres." Como todo en la vida, y especialmente en el ciberespacio, son recomendables algunas normas de comportamiento. Si nos negamos a ceder nuestro asiento a una viejecita en un autobús, nadie nos puede denunciar ante un juez; pero hacerlo demuestra buena crianza, mejor educación y una disposición a echar una mano a nuestros semejantes, lo que en último término redunda en beneficio de todos.

Quiere eso decir que los PGPeros tiene también sus normas de "netiqueta" Yo no las he visto escritas en ninguna parte, pero se me ocurren algunas a bote pronto. Helas aquí, sin orden ni concierto, y espero que le sean útiles.


      No envíe su clave pública de forma habitual, sea en el cuerpo del mensaje o como adjunto. Eso solamente contribuye a congestionar aún mas las redes. Si quiere dar a conocer su clave, es más eficiente insertar en el mensaje -como firma o comentario final- información sobre cómo conseguir su clave: dirección html, ID de clave, dirección de servidor de claves, lo que prefiera. Use en lo posible un servidor de claves, tanto para poner su propia clave como para obtener las de los demás. Y, ya que en las tarjetas de presentación se incluye la dirección de correo electrónico, incluya el ID de clave o la huella de su clave.


      No envíe a un servidor de claves una clave que no sea suya. Aunque recomiendo los servidores, la decisión sobre su uso debe corresponder a su dueño. Puede que alguien no desee ver su clave en un servidor por motivos de privacidad, miedo o cualquier otra razón pertinente. Respecto a si puede actualizarse una clave ya disponible en un servidor (porque acabe usted de firmarla, por ejemplo), tengo mis dudas, así que sugiero que envíe la firma actualizada a su dueño y deje que él tome la decisión.


      No cree claves a tontas y a locas. Hay quien se dedica a crear una clave tras otra, cambiándolas, revocándolas y sin decidirse a usar una en concreto. Recuerde (capítulo 4) que una clave puede tener más de un identificador de clave, así que si cambia de dirección de e-mail no es necesario crear una nueva clave. Y no sea travieso. Nada de crear claves falsas, con nombres y/o direcciones reales que no sean las suyas. Aunque diseminar claves tipo jmaznar@moncloa.es pueda resultarle divertido, hace un flaco favor en pro de la privacidad de las comunicaciones. Que no le pille yo imitando mis claves


      Mantenga su "red de confianza" en buen estado. Esto significa que no vaya firmando claves a tontas y a locas. Más de un novato, irritado porque una verificación de firma le sale "invalid", resuelve el problema firmando la clave usada para la firma. Con ello, estamos diciendo al mundo que la clave pertenece realmente a su pretendido dueño, algo que a lo peor no tenemos modo de comprobar. No firme claves a no ser que tenga seguridad en cuanto a su procedencia.



      No tenga miedo en dar a conocer su clave. Nadie le va a ridiculizar (bueno, mi jefe sí me toma el pelo, pero no le hago pastelero caso), ni a enviarle al FBI a su casa. Usar PGP es una decisión personal, pero si ya se ha decidido, ¿a qué ocultarlo? Me gustaría ver el día en el que usar cifrado de datos sea algo tan normal como usar código html.


      No haga conversión de infieles. Es bueno usar PGP, y también dar a conocer su existencia y ventajas a amigos y conocidos. Pero hágalo con educación. Establecer batallas sobre si mola más un cifrado u otro no conduce a ninguna parte. Incluya información sobre PGP y cifrado en su página personal, si lo desea. Tome hábitos como el de firmar mensajes por defecto. Deje caer en la conversación que usted protege sus comunicaciones mediante cifrado. Pero todo con buen rollo. En definitiva, sea un buen embajador de PGP, firme pero educado.

6.2 - ¿Es usted un terrorista?

Uno de los argumentos que más oigo cuando hago campaña en pro de la protección en las comunicaciones es el de "¿por qué cifrar, si yo no tengo nada que esconder?" Vivimos tan poco acostumbrados a defender nuestros derechos que muchas veces renunciamos a ellos a cambio de una pretendida sensación de seguridad. Que registren mi correo, si quieren. No hago nada ilegal. Ese es el razonamiento típico.

Sin embargo, hay una falacia oculta: que solamente aquellos con malas intenciones tienen necesidad de proteger sus datos. Por tanto, quien pretenda hacer tal cosa seguro que no es trigo limpio.

¿O acaso sí lo es? Aunque no le conozco, supongamos que usted es básicamente un honrado ciudadano, cumplidor de la ley (quitadas esas multas por exceso de velocidad, y tal vez alguna deducción "dudosa" en su declaración de la Renta). Mire usted a su alrededor. Vive en una casa con cerradura en la puerta. ¿Qué le parecería que la policía pudiese entrar en su domicilio cuando se le antojase, sin orden judicial? ¿O leer el correo que le llega usted al buzón? ¿O tal vez oír sus conversaciones telefónicas? Aunque usted sea un ciudadano modelo, seguro que una situación así le incomoda.

Todos tenemos algo que ocultar. Puede ser legal, ilegal o sencillamente inocuo. Puede que mi receta secreta de salsa de castañas no sea nada malo, pero es MI salsa de castañas. Si la policía quiere meterse en mi vida, tengo perfecto derecho a reclamar tutela judicial y a que mis derechos sean respetados. A eso lo llamamos derecho a la intimidad. Y lo consideramos tan importante que la propia Constitución tiene un artículo que lo protege. Hasta ahora no hemos tenido más medidas de protección que la esperanza en que los posibles infractores cumplan con la ley ... y como demuestra el caso de las escuchas ilegales del CESID, eso no siempre se cumple.

La cifrado o cifrado de datos permite una protección de alto nivel contra escuchas no autorizadas -legales o no-, y no es casualidad que haya constituido uno de los campos de batalla electrónicos más activos de la última década. Los esfuerzos en pro de la restriccion de cifrado por parte de gobiernos y agencias policiales darían para escribir libros enteros. Uno de los argumentos favoritos consiste en afirmar que pederastas, terroristas, narcos y demás gentes de mal vivir usan criptografía.

Durantes las secuelas del atentado contra el edificio federal de Oklahoma City, el director del FBI afirmó que el uso de criptografía debía estar controlada por el gobierno. Nadie pareció caer en la cuenta de que los terroristas no usaron ningún tipo de cifrado. Tras los atentados del 11 de Septiembre, la situación no ha mejorado. Durante los primeros días de la investigación, diversos artículos proclamaron que los terroristas habían usado cifrado de datos para esconder sus actividades. A pesar de que posteriormente el propio FBI tuvo que retractarse y admitir que no habían encontrado un solo mensaje cifrado, el Congreso de Estados Unidos estuvo a punto de promulgar una ley para restringir -si no prohibir de raiz- el cifrado de datos.

En la actualidad, tanto EEUU como otros países están preparando, o han aprobado ya, leyes para ampliar la vigilancia en las comunicaciones electrónicas de forma sin precedentes. A la fecha de escribir estas palabras, el Congreso Español está debatiendo el borrador de ley que regulará el futuro Centro Nacional de Inteligencia, cuyas funciones incluirán la obtención, evaluación e interpretación del "tráfico de señales de carácter estratégico." Todo ello en un clima en el que la seguridad parece tener preferencia absoluta, incluso a expensas de la libertad individual. Philip Zimmermann, creador de PGP, fue profético en sus palabras:

      ...la ley todavía requiere una orden judicial para una escucha. Pero mientras la infraestructura tecnológica puede persistir durante generaciones, las leyes y las políticas pueden cambiar de la noche a la mañana. Una vez que se ha establecido una infraestructura de comunicaciones optimizada para la vigilancia, un cambio en las condiciones políticas podría llevar a un abuso de este nuevo poder. Las condiciones políticas podrían variar con la elección de un nuevo gobierno, o quizá más abruptamente tras el atentado a un edificio federal

Durante la Segunda Guerra Mundial, cuando la propia existencia de Gran Bretaña estaba amenazada, dicho país firmó una alianza con EEUU para combinar sus esfuerzos contra los mensajes cifrados alemanes. El sistema desarrollado entonces para ganar la guerra ha continuado funcionando hasta la actualidad. Sistemas y redes como Echelon (severamente criticados recientemente por el Parlamento Europeo) continúan aspirando las comunicaciones mundiales para combatir nuevos enemigos, reales o fingidos. Prácticamente no hay país con capacidad técnica para espiar las comunicaciones que no lo haga. Añada a eso otros enemigos caseros de todo tipo (empresas, hackers, vecinos cotillas, cónyuges celosos, rivales comerciales...) y verá como no solamente tiene usted cosas que esconder, sino que es conveniente que lo haga.

Lo que le estoy intentando decir es lo siguiente. Si le da a usted lo mismo que registren su vida privada de arriba abajo, el cifrado de datos no tiene interés para usted. Si, por el contrario, desea usted proteger su intimidad, el cifrado le será tan útil como los sobres cerrados o las puertas con cerradura. Lo que nunca, NUNCA debe hacer es tragarse la píldora del "si te escondes, es que eres un criminal." Usar cifrado es una decisión legítima. No le pondrá fuera del alcance de la ley (un juez puede obligarle a usted a descifrar sus mensajes), pero sí le protegerá de forma legítima.

Cualquiera que sea su decisión, recuerde que es usted quien escoge. No deje que los demás decidan por usted.

6.3 - Presente y futuro de PGP

A despecho de los malos tiempos que soplan últimamente, parece que el cifrado de datos va a continuar. Simplemente, no existe forma eficaz de controlar la criptografía. Puede que ni siquiera sea inteligente intentarlo, toda vez que el comercio electrónico descansa en la existencia de canales seguros de comunicación, sea PGP en el e-mail o protocolos seguros (SSL) en los navegadores de Internet.

No obstante, han aparecido algunas nubes en el panorama. PGP ya no es la incontestable estrella en el panorama del cifrado. Uno de los puntos fuertes de PGP ha sido su virtual ausencia de fallos (bugs). Por desgracia, la complejidad de las últimas versiones para Windows ha hecho que algunos bugs se cuelen de vez en cuando. Tales bugs son escasos, y solamente el que hayan aparecido en PGP les ha dado cierta relevancia. Lo cierto es que encontrar un fallo de programación en PGP era considerado como una hazaña. Los fallos de cierta relevancia encontrados hasta la fecha son básicamente los siguientes:


      Bug aleatorio 5.0i. Un fallo en una sola línea de programación hizo que el generador de datos aleatorios de PGP 5.0i (versión para Linux) leyese de forma errónea. Como resultado, las claves usadas podrían ser averiguadas sin mucha dificultad.


      Fallos menores. Hay un bug en PGP 6.0.1 por el cual el cifrado de su componente PGPdisk es más débil de lo que debería ser (la clave usada, en teoría de 128 bits, es en la práctica más débil). Otro elemento en la versión 5.5.3i hacía que el borrado seguro (Wipe) no fuese realmente seguro. Ambos fallos fueron fácilmente corregidos en versiones posteriores.


      ADK bug Ralph Senderek descubrió en Agosto de 2000 un fallo asociado a la llamada clave de descifrado adicional (ADK, ya mencionada en el capítulo 4). Un nuevo formato de clave, incorrectamente diseñado, permitía incorporar subrepticiamente una clave ADK sin que la alteración fuese detectada. Este bug, grave desde el punto de vista de la seguridad, aparecía en las versiones 5.5.x a la 6.5.3. Tras estudios de las claves existentes en los servidores, parece ser que dicho bug nunca ha sido aprovechado por un atacante. El bug fue corregido en la versión 6.5.8. El lector interesado puede leer todos los detalles en mi Informe 24: Agujero en PGP (http://www.cripto.es/informes/info024.htm)


      Ataque checo (o ICZ) En Marzo de 2000, los investigadores checos Vladimir Klima y Tomas Rosa, publicaron un nuevo ataque no solamente contra PGP, sino también contra su estándar abierto OpenPGP. Este ya no era solamente un fallo de programación, sino un serio ataque criptográfico. Resulta muy interesante en teoría, pero en la práctica requiere acceso físico al ordenador de la persona atacada, y en ese caso sería más fácil obtener la clave mediante un troyano. Si se siguen las recomendaciones habituales sobre protección de las claves privadas, este ataque no es factible. Este ataque no funciona con versiones posteriores a la 7.0. El lector interesado puede leer todos los detalles en mi Informe 27: PGP y el ataque checo (http://www.cripto.es/informes/info027.htm)


      Armadura ASCII Descubierto en Abril de 2001, permite ocultar un fichero malicioso (un troyano, o una librería dinámica DLL) en un archivo "recubierto" con armadura ASCII. A pesar de la gravedad potencial del bug, hay que ser justo: este fallo no es de PGP en sí, sino del sistema operativo bajo el que opera (Windows). Esto nos recuerda algo muy importante: la seguridad global de una cadena es solamente la del eslabón más débil. Hay parche para las versiones 7.0.3 y 7.0.4; los usuarios de versiones anteriores para Windows pueden protegerse mediante el uso de elementos de seguridad adicional (cortafuegos y antivirus).


      Ataque de Otterloo En septiembre de 2001, Sieuwert van Otterloo mostró un fallo que permite "jugar" con la validez de una clave. En claves con más de un identificador, y bajo ciertas circunstancias, un usuario puede ser engañado a pensar que una clave es válida cuando realmente no lo es. El lector interesado puede obtener más detalles en http://www.bluering.nl/pgp

¿Cómo es posible que aparezcan tantos fallos en un programa antaño considerado ejemplo de perfección? Tal vez tenga que ver con la venta de PGP Inc. a Network Associates (NAI) en 1.997. Algunos criptólogos hablan de una "microsoftización", en alusión a la tendencia de añadir accesorios y entornos gráficos que multiplicaban los posibles fallos de seguridad y engordaban grandemente el código fuente. Tras el descubrimiento del ataque checo, Michel Boissou publicó su lamento "¿En qué se ha convertido PGP?" cuya lectura recomiendo (disponible en http://cryptome.org/pgp-what.htm) escribe:

      Reprochamos a NAI el haber transformado un programa de seguridad informática en un programa para marketing... el problema está relacionado con las elecciones técnicas y comerciales. PGP es la víctima del marketing de NAI ... de una versión a otra, PGP fue transformado en un gran continuación de seguridad, con más y más funciones, la mayoría de las cuales no son esenciales al cifrado y autenticación de datos. PGP parece crecer mes a mes. El problema es que no sabemos cuándo terminará.

Tampoco parecen haber sentado bien la decisión de no publicar el código fuente. Hasta ahora, toda versión de PGP venía acompañada de su código fuente (el conjunto de líneas de programación) para que cualquiera pudiera revisarlo e incluso recompilarlo si lo desease. Sin embargo, NAI ha dejado de hacer público dicho código fuente. Eso ha dado lugar a especulaciones sobre si van a incluirse "puertas traseras" en las nuevas versiones. Aunque no sea así, muchos usuarios ven esto como un movimiento en la dirección equivocada. Esta fue una de las causas que motivaron la salida de Philip Zimmermann de NAI en Enero de 2001.

Cualesquiera que fuesen los motivos de engordar PGP, no parece haberle sentado bien en el campo de la seguridad ... ni en el de las ventas. En Octubre de 2001, NAI anunció que no iba a seguir desarrollando nuevas versiones de PGP. La empresa aludió a motivos económicos para la puesta en venta de PGP. La verdad es que no es de extrañar: 250 desarroladores significan muchos salarios (pensar que no hace tanto que el "tío Phil" desarrollaba nuevas versiones él solito), y $179 -casi 200 Euros- probablemente sea un precio elevado para una licencia de uso comercial de dos años.

¿Es el fin del sueño PGP? ¿Les he estado vendiendo la moto equivocada durante los cinco anteriores capítulos? Sinceramente, opino que no. En primer lugar, PGP es un programa consolidado, con diez años de solera y varios millones de usuarios. Las versiones anteriores a la 7.0 pueden ser todavía consideradas fiables. En segundo lugar, sencillamente no hay nada mejor en términos de seguridad y fiabilidad.

En tercer lugar, puede que eso sea justamente lo que PGP necesita. Este programa nació como respuesta a los intentos del gobierno norteamericano por controlar la criptografía. Su autor quería ofrecer un programa "para las masas", de forma que cualquier usuario tuviese la protección anteriormente reservada a las entidades gubernamentales. En este sentido, soltar un poco de lastre será bueno. Michel Boissou sugería que PGP debería tener -más correctamente, recuperar- las siguientes características:


      ser ligero, conciso, fácil de controlar


      implementar algoritmos de cifrado fuertes y probados durante años



      evitar sobre todo cacharrería inútil o de utilidad debatible



      incorporar solamente lo necesario para cifrar, descifrar y autenticar



      limitarse a un producto de fácil codificación, separando la "maquinaria de cifrado" de las adiciones externas (plug-ins) para hacerlas controlables y evolucionarias.

En otro programa esto quedaría como un deseo y poco más, pero como dice su propio creador "PGP es una institución más grande que cualquier empresa individual, y seguirá adelante con o sin Network Associates." Ya en 1999 se presentaba la primera versión de una alternativa denominada GnuPG. Es éste un programa libre bajo licencia GNU, basado en el protocolo no propietario OpenPGP. Aunque fue originariamente diseñado para Windows, hay en desarrollo versiones compatibles con Windows y Mac, incluso con soporte gráfico (o sea, ventanitas). Muchos entusiastas de PGP, entre ellos el propio Zimmermann, están volcándose en OpenPGP para convertirlo en un estándar abierto, lo que evitará que quede a merced de los avatares de una empresa en concreto.

Mi compañero kriptopolero Manolo Gómez se ha pasado con armas y bagajes, de cabeza. Puede que un día de estos yo mismo me cambie a GnuPG. Pero sigue habiendo muchos usuarios potenciales de cifrado sin tiempo, ganas o conocimientos técnicos para aprender los entresijos de GnuPG. Para ellos he hecho este Curso Sencillo. Espero que haya cumplido su propósito... que siempre hay tiempo para cambiar, si es a mejor.

6.4 - Cajón desastre ... y hasta siempre

- ¿Hay algún archivo sobre preguntas frecuentes (FAQ)?

En efecto, haylos. Entre los que conozco, puedo mencionar:


      FAQ del grupo comp.security.pgp, de Arnoud Engelfriet.
http://www.uk.pgp.net/pgpnet/pgp-faq/
Es algo antiguo (1996), pero bastante extenso.

      FAQ sobre la frase de contraseña [passphrase], de Randall T. Williams (1997)
http://www.stack.nl/~galactus/remailers/passphrase-faq.html

      FAQ sobre ataques a PGP, de infiNity. Para interesados en profundizar ... o para paranoicos
http://axion.physics.ubc.ca/pgp-attack.html

      FAQ: ¿RSA o Diffie-Hellman? Documento con mucha chicha, actualizado (1999) y cortesía de Sam Simpson
http://www.scramdisk.clara.net/pgpfaq.html

      PGP: Preguntas y respuestas Interesante compilación de Tom McCune
http://www.mccune.cc/PGPpage2.htm
   

      FAQ sobre PGPi Cómo y por qué de las versiones Internacionales. Algo anticuado (1998), pero está en español.
http://www.cripto.es/expedien/hisparch/pgpfaq.htm

¿Existe manual de PGP en español?

Desafortunadamente, no. Puesto que hasta hace poco la exportación del programa (fuera de EEUU) era ilegal, Network Associates (propietaria de PGP) no podía dar soporte de ningún tipo fuera de las fronteras del tío Sam. Las traducciones que existen se realizaron de forma "guerrilla" mediante voluntarios. Sí existe una versión del manual para Windows, versión 5.5.3i, que puede resultaros de ayuda. Fue traducido por Juan Manuel Velázque y el que firma. Podéis encontrarlo en http://www.cripto.es/informes.htm (formatos Adobe Acrobat y WordPerfect).


Tengo el siguiente problema con PGP y mi programa de correo electrónico: resulta que ...

A este tipo de preguntas no puedo responder. Desafortunadamente, la proliferación de conectores y programas de correo electrónico, junto con la creciente complejidad de PGP, hace que resulte inevitable la aparición de errores (bugs). Unos se corrigen, otros aparecen. Podéis intentar solucionar vuestro problema particular leyendo accediendo a la sección "bugs" de www.pgpi.org o a la de pgp.com


¿Qué es una "fiesta de firma"?

Las fiestas o reuniones de firma vienen del inglés "keysigning party", y es un invento para ampliar la red de confianza. Resumiendo, es una reunión de usuarios de PGP para firmar claves. En tales reuniones, los usuarios se presentan unos a otros, confirman sus identidades y firman claves de otros. Es una extensión del típico "A y B se encuentran y se intercambian claves". Resulta una manera muy agradable no sólo por aumentar el número (y calidad, por las firmas asociadas) de nuestros archivos de claves, sino porque así los PGPeros se van conociendo. Puede que se intercambien físicamente las claves, pero en la mayoría de los casos basta con comprobar las identidades de las personas y su relación con sus respectivas claves. Este tipo de reuniones están muy extendidas en países como Estados Unidos, pero en España apenas ha arraigado. Quizá se deba al relativamente escaso número de usuarios de PGP. Todo se andará...


Ya puestos en ello, ¿cuántos usuarios de PGP hay?

Resulta difícil de cuantificar. Network Associates da una cifra de 10 millones de usuarios, pero tal vez sea solamente una estimación basada en el número de descargas.

Podemos hacernos una idea más fiable echando un vistazo a los servidores de claves. El servidor de RedIris, por ejemplo, tiene su página de estadísticas en http://www.rediris.es/cert/text/pgp/stats.es.html. Hay que tener en cuenta que algunas claves no tienen un dominio asociado, o tienen uno falso, y por supuesto muchos usuarios habrán decidido no enviar su clave al servidor. Y, aunque viene un desglose por dominios, no podemos decir cuántos usuarios españoles hay, ya que está muy de moda usar dominios .org o .com. Pero ahí va, por lo que valga:

A fecha de 22 Junio 2000, había en el servidor de RedIris un total de 847.853 claves PGP (aunque el número total de claves, según Francisco Montserrat, se aproxima al millón). El dominio .com es el más abundante (292.472). A nivel nacional, los PGPeros alemanes con los más abundantes (92.826 para .de), seguido por los "reinounidenses" (21.099) y los japoneses (16.311). A nivel hispano, los españones son los "pichichis" con 9.079 claves, lo que constituye un magro 1.1% del total. Siguen Argentina (1.477) y México (1.262). No parece gran cosa, pero repito que en los países hispanos existen muchos usuarios con dominios .com y .org, lo que puede distorsionar las cifras.

Esa era la situación cuando redacté mi primera edición de este Curso Sencillo de PGP. ¿Y ahora, qué tal? Pues a tenor de lo que dicen los números, bien, gracias. En Enero de 2002, el número total de claves había aumentado a más de 1.600.000, y los dominios .es sumaban un total de 15.400 claves, lo que nos deja en un 1% del número total de claves. Para que resulte más sencillo de visualizar, he aquí una tabla parcial de datos:



A juzgar por estas cifras, PGP goza de buena salud. ¿No cree usted?


¿Por qué usar PGP, en lugar de ...?

Pregunta truculenta, donde las haya. Eso debe decidirlo solamente el usuario, en función de sus gustos y necesidades. No puedo recomendarle PGP por encima de X, del mismo modo que no voy a defender las ventajas de Netscape Navigator sobre las del Internet Explorer (no aquí, al menos). Si después de este curso usted decide que PGP no satisface sus necesidades, bórrelo y tan amigos. Personalmente, me quedo con él. Pero eso depende crucialmente de la palabra "personalmente".


He oído que PGP tiene "puertas traseras". ¿Qué hay de cierto en eso?

Cada cierto tiempo aparece la noticia de que PGP ha sido "reventado". Vamos por partes. No hay constancia de que ningún mensaje cifrado con PGP haya sido jamás "reventado" en el sentido de "descifrado por otro medio que no sea la clave privada", excepto en casos aislados con fines de investigación y en los que se usaron claves públicas pequeñas (menos de 512 bits). El código fuente de PGP es abierto y ha sido revisado de arriba abajo, y nadie ha encontrado ninguna puerta trasera. Existe un programa llamado pgpcrak que, a pesar de su nombre, no revienta PGP, sino que se dedica a intentar "adivinar" la frase de contraseña. Escogiendo una frase de contraseña adecuada, pgpcrak fracasa. Y por supuesto, sigue siendo necesario acceder a la clave privada.

Los seguidores de este Curso recordarán cómo hablábamos de la opción denominada Clave de Descifrado Adicional, o ADK. Me limitaré a recordar que es una opción para leer mensajes cifrados (nunca para obtener claves privadas) en entornos empresariales. Esto no es una "puerta trasera", puesto que es perfectamente conocida y cumple una función corporativa concreta.

Un tema más grave es el siguiente. Existe una asociación de empresas de informática denominada "Alianza para la Recuperación de Claves" (Key Recovery Alliance), cuyo fin es el de idear y considerar diversas opciones para "meter las narices" en mensajes cifrados. Esto tiene una vertiente comercial (como la KRA), pero también tiene el fin de permitir, en determinadas condiciones, que las autoridades judiciales o policiales tuviesen acceso a mensajes cifrados o bien a las propias claves. No voy a entrar en debates sobre la conveniencia o no de dicho acceso policial, y recomiendo al lector interesado mi "Trilogía Key Escrow" para más información (disponible en http://www.cripto.es/informes.htm, Informes números 16, 17 y 18).

El caso es que se hace algún tiempo se descubrió que Network Associates, propietaria de PGP, era miembro de la KRA. Imagínense el clamor de la comunidad PGP. ¿Acaso su programa favorito sería modificado para permitir el acceso de policías, espías, jueces y demás gentes de mal vivir? ¿Para eso estuvo su creador al borde de la cárcel? Network Associates lo negaba, pero ¿cómo creerla si tenía el "carnet" de la KRA?

La explicación parece ser la siguiente. Network Associates (NAI) se formó tras la fusión de diversas empresas de informática. Dos de las empresas que adquirió posteriormente eran PGP Inc. (propiedad de Phil Zimmermann, creador del programa PGP) y TIS (Trusted Information Systems). Esta última era miembro de la KRA, de manera que su empresa "madre" NAI pasó a figurar en la lista de la KRA. Esto explica las vehementes negativas de NAI acerca de que PGP sería sometida a un régimen de recuperación de claves. Sabia política, ya que de lo contrario PGP perdería una buena parte de su encanto ... y de sus clientes. De hecho, la propia KRA parece estar en paradero desconocido: su página web http://www.kra.org resulta inaccesible, y las mismas políticas de recuperación de claves parecen haber sido abandonadas por la mayoría de los países industrializados.

Así que tranquilos, que por lo que parece hay "Pretty Good Privacy" (Intimidad Bastante Buena) para rato.

 

6.5 - Despedida

Y ahora sí. Hemos llegado al final del Curso Sencillo de PGP. Espero que le haya sido de utilidad y entretenimiento. Si le ha picado el gusanillo de la criptografía, siga aprendiendo. Yo pienso continuar en mi Taller de Criptografía, donde siempre será usted bien recibido: http://www.cripto.es. Gracias por su atención, y hasta siempre.
Fuente : http://www.cripto.es