Experiencias con PGP en Unix


Este documento no ha sido actualizado desde 1996.
Consulte esta página para acceder a información más actualizada.

Introducción

Este documento ha sido elaborado dentro del Grupo de Trabajo sobre PGP y explica la experiencia que ha tenido el autor con la instalación, uso, problemas etc. de PGP.

Software: cómo y dónde.

 RedIRIS mantiene un mirror de software relacionado con PGP en su servidor de FTP anónimo. La dirección es:

Software PGP para máquinas UNIX

Software PGP en general

La última versión internacional de PGP para UNIX es la 2.6.3i, desarrollada por Stäle Schumacher a partir de su propia versión 2.6.2i que está basada a su vez en la versión 2.6.2 del MIT. No existe una versión 2.6.3 del MIT; la versión internacional puede ser compilada con RSAREF generando una versión 'americana' llamada 2.6.3, lo que tal vez puede conducir a equívocos.

Compilación.

Las pruebas han sido realizadas en estaciones Sun con arquitectura sun4 (sparc), sistemas operativos Solaris 2.4 y 2.5 y compiladores SparcWorks (oficial de Sun) y gcc. En todas ellas la compilación transcurre sin problemas. Nos gustaría saber de vuestras experiencias con otros entornos para incorporarlas a este documento.

  • Extraer el contenido del archivo tar. Dentro hay dos ficheros: otro tar y la firma PGP del mismo, con lo cual podéis (si ya tenéis PGP) verificar la integridad de la distribución. Si no tenéis aún PGP, siempre podéis hacerlo a posteriori.

  • Al extraer este segundo tar, tened en cuenta que os volcará toda la distribución en el directorio actual, es decir, no cuelga todo de un mismo directorio de trabajo por lo que tal vez prefiráis crearlo vosotros.

  • La generación ocurre dentro del subdirectorio src. No hay en principio necesidad de editar el makefile ni de ejecutar un script de configuración. Un 'make' a secas nos muestra todos los sistemas previstos. Por ejemplo, en nuestro caso es una Sparc1000 con Solaris y dos compiladores de C, el oficial (acc) y el de GNU (gcc). Por tanto, de las alternativas que se nos muestran hay dos válidas a priori:

    	sun4sunos5acc
	sun4sunos5gcc
Elegimos la segunda. Como he dicho no hay necesidad de editar el Makefile, pero lo hacemos para añadir la opción '-msupersparc' a la variable CFLAGS con lo que conseguiremos mayor optimización.

	make sun4sunos5gcc

Instalación.

 El makefile incluido con la distribución no incluye una opción 'install'. La instalación en sí es muy sencilla, consta de lo siguiente:

	- el binario (pgp):	en src
	- el manual (pgp.1):	en doc
	- el resto.
PGP necesita una serie de ficheros accesibles a nivel de host (config.txt, *.hlp, doc/*, etc). Esperará encontrarlos en /usr/local/lib/pgp entre otros sitios, aunque podemos ponerlos donde queramos y definir la variable PGPPATH que apunte a ellos.

Por coherencia decidimos usar /usr/local, luego la instalación se reduce a lo siguiente (aprovechamos para cambiar un par de parámetros de la configuración: idioma por defecto y aplicación de codificación ASCII para los binarios).

	mkdir -p /usr/local/bin
	mkdir -p /usr/local/man/man1
	mkdir -p /usr/local/lib/pgp
	mv src/pgp /usr/local/bin
	mv doc/pgp.1 /usr/local/man/man1
	mkdir /usr/local/lib/pgp
	sed 's/= en/= es/;s/# Armor/Armor/' config.txt
		>/usr/local/lib/pgp/config.txt
	mv * doc/*  /usr/local/lib/pgp
PGP se negará a funcionar si no encuentra los documentos originales.

Existe un directorio contrib, tal vez os interese algo de lo que hay allí. Por otro lado, no está de más comprobar que todos los archivos se han creado con el propietario/grupo/permisos adecuados (depende del umask de root, y de su grupo primario, por ejemplo).

Uso: Primeros pasos.

 Si un determinado usuario no tiene una variable PGPPATH en su entorno, PGP asume que los ficheros PGP de ese usuario (claves, etc) estarán en el directorio ~/.pgp (por convención casi todos los shells interpretan ~ como $HOME). PGP NO crea este directorio, así que antes de usarlo por primera vez deberemos crearlo a mano.

En cualquier caso, el directorio .pgp o equivalente deberá tener permisos drwx------. Los ficheros creados en él serán los 'llaveros' de claves públicas (pubring.pgp) y de claves privadas (secring.pgp), y además es posible tener una copia local de config.txt cuyas definiciones tendrán prioridad sobre la global.

Convenciones a seguir:

	- Comandos Unix:

	$ comando

	- Texto de salida de PGP

	Texto

	- Respuesta a preguntas de PGP

	[ respuesta ]

Lo primero que hay que hacer es crear una pareja de claves:

$ pgp -kg

Pretty Good Privacy(tm) 2.6.3i - Criptografía de clave pública para todos.
(c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-01-18
Versión internacional - no apta para los EE.UU. No utiliza RSAREF.
Hora actual: 1996/02/14 15:47 GMT

Elija un tamaño de clave RSA:
    1)   512 bits- Nivel comercial bajo, rápido pero menos seguro
    2)   768 bits- Nivel comercial alto, velocidad media con buena seguridad
    3)  1024 bits- Nivel "militar", lento con alta seguridad
Escoge 1, 2, 3, o el número requerido de bits:
  • Aconsejo que se usen claves de 1024 bits. La diferencia de velocidad no es grande en las máquinas actuales, y son mucho más seguras.

    Escoge 1, 2, 3, o el número requerido de bits: [3]

Generando una clave RSA con módulo de 1024 bits.

Necesitas un identificador para tu clave pública. El formato preferido
consiste en tu nombre, seguido de tu dirección de correo electrónico,
si tienes, entre <ángulos>.
Por ejemplo:  Nadie <nadie@limbo.org>
    

Introduce un identificador de usuario para tu clave pública:

  • El identificador puede ser cualquier cosa, pero se aconseja que no sea ambiguo y que incluya una dirección de email.

    Introduce un identificador de usuario para tu clave pública: 
[Ruben Martinez <ruben@rediris.es>]

Necesitas una contraseña para proteger tu clave secreta RSA.

  • Puede ser cualquier expresión formada por varias palabras, espacios, signos de puntuación o cualquier otro carácter imprimible.

    Introduce la contraseña:

    La contraseña será utilizada en cualquier operación de acceso a la clave privada (por ejemplo: para descifrar un fichero dirigido a nosotros, o para firmar un documento). Esta contraseña no se verá mientras se teclea.

    Introduce la contraseña: [no esperaras que te ponga la contraseña real]
Escríbela otra vez: [no esperaras que te ponga la contraseña real]

Ten en cuenta que la generación de claves es un proceso lento.

Necesitamos generar 882 bits aleatorios. Se hace midiendo los
intervalos de tiempo entre pulsaciones de tecla. Escribe
texto al azar en el teclado hasta que oigas un pitido:
    
 882
  • Vaya, esa contraseña no era lo bastante aleatoria (la mia sí lo es :) en estos casos, se nos pedirá introducir datos adicionales para alimentar al generador de números aleatorios. Simplemente teclea hasta que el número mostrado llegue a cero (y tranquilos, no hay que teclear 882 veces)

       0 * -Es suficiente.
........**** ............................................**** 
La contraseña es correcta.  Un momento....

Se ha añadido el certificado de firma.
Finalizada la generación de claves.
  • Y eso es todo. Comprobemos que la clave existe:

    $ pgp -kv ruben

Pretty Good Privacy(tm) 2.6.3i - Criptografía de clave pública para todos.
(c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-01-18
Versión internacional - no apta para los EE.UU. No utiliza RSAREF.
Hora actual: 1996/02/14 15:59 GMT

Anillo de claves: '/home/users/ruben/.pgp/pubring.pgp',
buscando el usuario "ruben"

Tipo Bits/Clave    Fecha      Identificador
pub  1024/146DE28D 1995/07/31 Ruben Martinez <ruben@rediris.es>
Se ha encontrado 1 clave.
  • Podemos añadir más identificadores a una clave nuestra, o cambiarle la contraseña, etc, editándola:

    $ ppg -ke ruben

Pretty Good Privacy(tm) 2.6.3i - Criptografía de clave pública para todos.
(c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-01-18
Versión internacional - no apta para los EE.UU. No utiliza RSAREF.
Hora actual: 1996/02/14 16:01 GMT

Se necesita el identificador de usuario para elegir la clave que quieras
modificar.
Introduce el identificador: [Ruben]

Modificación del identificador "Ruben"
en el anillo: '/home/users/ruben/.pgp/pubring.pgp'.

Clave del usuario: Ruben Martinez <ruben@rediris.es>
Clave de 1024 bits, con identificador 146DE28D, creada el 
También conocido como: Ruben Martinez <ruben.martinez@rediris.es>

Se necesita la contraseña para abrir la clave secreta RSA. 
Clave del usuario: Ruben Martinez <ruben.martinez@rediris.es>
Clave de 1024 bits, con identificador 146DE28D, creada el 

Introduce la contraseña: La contraseña es correcta.  
Identificador actual de usuario: Ruben Martinez <ruben@rediris.es>
¿Quieres añadir un nuevo identificador de usuario (s/N)? [n]

¿Quieres cambiar la contraseña (s/N)? [n]
(No se efectuará ningún cambio.)
  • Se aconseja sacar una copia de seguridad de .pgp/*.pgp y almacenarla en lugar seguro.

  • Podemos crear más claves: una por identidad. Por ejemplo, yo puedo tener una como Rubén Martínez y otra como IRIS-CERT. Eso no tiene nada que ver con el hecho de que además, una determinada identidad puede tener más de un identificador asociado (por ejemplo, varias direcciones de correo).

  • El fichero secring.pgp contendrá todas las claves secretas para todas estas identidades. El fichero pubring.pgp contendrá las claves públicas para estas identidades y para las de las claves públicas que vayamos recibiendo. Para extraer una versión ASCII de nuestra clave pública:

    $ pgp -kxa ruben

Pretty Good Privacy(tm) 2.6.3i - Criptografía de clave pública para todos.
(c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-01-18
Versión internacional - no apta para los EE.UU. No utiliza RSAREF.
Hora actual: 1996/02/14 16:11 GMT

Extrayendo del anillo de claves: '/home/users/ruben/.pgp/pubring.pgp', identificador "ruben".

Clave del usuario: Ruben Martinez <ruben@rediris.es>
Clave de 1024 bits, con identificador 146DE28D, creada el 
También conocido como: Ruben Martinez <ruben.martinez@rediris.es>

¿En qué fichero se extrae la clave anterior? [ruben.asc]
  • Este fichero podemos ahora enviarlo a un keyserver o a una persona cualquiera por email.

    Firma digital.

     Como ya se ha explicado en otro documento, la firma digital garantiza dos cosas: identidad del remitente e integridad del fichero firmado.

    $ pgp -s fichero

	Añade una firma digital usando mi clave privada por defecto
	(si tengo más de una identidad, puedo especificar una:
	pgp -s  -u ). Todos aquellos que tengan
	mi clave pública podrán verificarla.

(c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-01-18
Versión internacional - no apta para los EE.UU. No utiliza RSAREF.
Hora actual: 1996/02/14 16:15 GMT

Se necesita una clave secreta para generar la firma. 
Se necesita la contraseña para abrir la clave secreta RSA. 
Clave del usuario: Ruben Martinez <ruben@rediris.es>
Clave de 1024 bits, con identificador 146DE28D, creada el 

Introduce la contraseña: La contraseña es correcta.  Un momento....
Fichero normal con firma: fichero.asc

    Cifrado.

     Para cifrar un fichero especificamos el usuario o usuarios destino. La cifrado se realizará usando sus claves públicas (que deberemos tener obviamente), y sólo ellos podrán descifrarlo ya que sólo ellos tienen sus respectivas claves privadas.

    $ pgp -e fichero

Pretty Good Privacy(tm) 2.6.3i - Criptografía de clave pública para todos.
(c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-01-18
Versión internacional - no apta para los EE.UU. No utiliza RSAREF.
Hora actual: 1996/02/14 16:19 GMT


Se utilizan las claves públicas de los destinatarios para cifrar. 
Se necesita un identificador para encontrar la clave pública
del destinatario. 
Introduzca el identificador del destinatario: [simpson]


Clave del usuario: William Allen Simpson 
Clave de 1024 bits, con identificador 3022C951, creada el 
También conocido como: William Allen Simpson 
.
Fichero con armadura: fichero.asc

    Ambas cosas.

     Si queremos cifrado+garantía de integridad+autentificación de origen, podemos combinar ambas operaciones.

    $ pgp -es fichero

    Interpretando un mensaje PGP.

     Todo eso está muy bien, pero qué hago si me mandan claves públicas, o un fichero firmado, o cifrado, o de todo a la vez? La respuesta es la misma. Para interpretar un mensaje PGP ejecutamos:

    $ pgp fichero
    Y ya está. PGP analizará el mensaje, y puede pasar cualquiera, o varias, o ninguna de las siguientes cosas:

    • Encuentra firma digital.
    • Encuentra mensaje cifrado.
    • Encuentra clave.
    Dependiendo de lo cual seguirá alguna de las siguiente secuencias:

    Recibiendo nuevas claves.

     Cuando PGP encuentra una o más claves públicas en un fichero, intenta verificarlas y nos da la posibilidad de añadirlas a nuestro propia colección de claves. El procedimiento es más o menos como sigue:

    • Si ya tenemos una clave determinada, se mira si incluye información adicional (por ejemplo, más certificados), y de ser así, se actualiza nuestra versión.

    • Si no, se nos pregunta si queremos añadir esa clave. Supongamos que sí.

    • La clave está avalada por al menos una persona a la que hayamos concedido el máximo nivel de credibilidad, es aceptada inmediatamente. Es posible hacer que sean necesarios más de uno de estos avales modificando el parámetro "Completes_Needed" de config.txt.

    • Si la clave está avalada por al menos X personas a las que hayamos concedido el segundo nivel de credibilidad es aceptada inmediatamente. Por defecto X=2, y es el parámetro "Marginals_Needed" de config.txt.
    • Si no, se nos pregunta si queremos avalarla nosotros mismos. Para ello deberemos tener la COMPLETA SEGURIDAD de que la clave es auténtica. No puedo hacer bastante hincapié sobre este punto. Si queremos que PGP tenga alguna utilidad, no podemos romper la red de confianza certificando claves que 'suponemos que serán buenas, por qué no iban a serlo'. Para verificar una clave, hay varios métodos. Uno de ellos es extraer su 'huella dactilar' (16 números hexadecimales) y verificarlos por un canal independiente y seguro (por ejemplo, por teléfono).

    • Si certificamos una clave, estamos declarando que es de quien dice ser. Pero esto no dice nada acerca de la fiabilidad de dicho usuario a la hora de avalar nuevas claves. Por ejemplo, yo puedo estar completamente seguro de que una determinada clave A es de Pepe Usuario, pero Pepe Usuario puede a) ser un completo desastre con la gestión de claves b) ser una persona poco de fiar, por lo que no me fiaría de otra clave B que viniera avalada por él. Por eso, cuando certificamos una clave, PGP nos pregunta si nos fiaríamos de su dueño como aval para nuevas claves. Las respuestas posibles son: no sé, no, generalmente, siempre. Si contesto que me fiaré SIEMPRE de Pepe, las claves avaladas por él serán aceptadas sin más. Si contesto que me fiaré GENERALMENTE de Pepe, y he configurado el umbral de certificaciones marginales ("Marginals_Needed") como 3, se necesitarán al menos otros dos avales del mismo nivel, además del de Pepe, para que la clave sea dada por buena.

    Un ejemplo donde ocurre todo esto:

    $ pgp file

Pretty Good Privacy(tm) 2.6.3i - Criptografía de clave pública para todos.
(c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-01-18
Versión internacional - no apta para los EE.UU. No utiliza RSAREF.
Hora actual: 1996/02/19 16:28 GMT

El fichero contiene claves. Se muestran a continuación ...
Anillo de claves: 'file.$00',

Tipo Bits/Clave    Fecha      Identificador
pub  1024/12345678 1996/01/01 Pepito Grillo <insect@somewhere.net>
Se ha encontrado una clave.

¿Quieres añadir este fichero de claves al anillo '/home/users/ruben/.pgp/pubring.pgp' (s/N)?
[s]
  • Acto seguido PGP verificará los certificados que incorpora esta clave. Nótese que la nomenclatura puede ser algo confusa: para PGP, certificar una clave es 'firmar una clave', y no tiene nada que ver con 'firmar un documento'.

    Buscando nuevas claves...
pub  1024/12345678 1996/01/01  Pepito Grillo <insect@somewhere.net>

Comprobando las firmas...


El fichero de claves contiene:
   1 nueva(s) clave(s)

Una o más de las nuevas claves no están completamente certificadas.
¿Quieres certificar alguna de ellas tú mismo (s/N)?
  • Dado que los certificados incorporados en esta clave no eran suficientes (o no eran conocidos: yo tengo que tener la clave pública del 'certificante' para que sea válido), me pregunta si quiero certificarla yo.

    ¿Quieres certificar alguna de ellas tú mismo (s/N)? 
[s]

Clave del usuario: Pepito Grillo <insect@somewhere.net>
Clave de 1024 bits, con identificador 12345678, creada el 
Huella dactilar = 9D 77 C1 C6 E7 5D 37 C7  3C F7 24 3F 60 81 61 7E

Esta asociación clave/usuario no está certificada.

¿Quieres certificar esta clave tú mismo (s/N)?
  • ¿Tengo la seguridad de que esta clave es REALMENTE de quien dice ser? ¿REALMENTE? Si no es así, NO la puedo certificar. Llamo a Pepito y le digo que me diga los números de su huella dactilar. Coinciden, así que ya no tengo dudas.

    ¿Quieres certificar esta clave tú mismo (s/N)? 
[s] 

Buscando la clave del usuario 'Pepito Grillo <insect@somewhere.net>':

Clave del usuario: Pepito Grillo <insect@somewhere.net>
Clave de 1024 bits, con identificador 12345678, creada el 
            Huella dactilar = 9D 77 C1 C6 E7 5D 37 C7  3C F7 24 3F 60 81 61 7E

LEE ATENTAMENTE: Según tu conocimiento directo,

¿estás absolutamente seguro de poder certificar solemnemente que la
clave pública pertenece realmente al usuario especificado por
este identificador (s/N)? [s]
  • Vemos que insiste. Es un coñazo, pero es importante :) El procedimiento para certificar ('firmar') una clave es similar a la firma digital de documentos, y requiere acceso a nuestra clave secreta.

    Se necesita la contraseña para abrir la clave secreta RSA. 
Clave del usuario: Ruben Martinez <ruben@rediris.es>
Clave de 1024 bits, con identificador 146DE28D, creada el 

Introduce la contraseña: La contraseña es correcta.  Un momento....
Se ha añadido el certificado de firma.
  • Pepito es quien dice ser. Ok. Pero, si Pepito me garantiza con su certificado que una nueva clave de otro usuario es auténtica, ¿me lo creo? Son cosas distintas.

    Decide tú mismo si esta clave realmente pertenece, según la
evidencia a tu alcance, a la persona que crees.  Si es así,
contesta a la siguiente pregunta, basándote en tu estimación de la
integridad de esa persona y de su conocimiento sobre gestión de claves:
  • Dado que es un poco novato en esto y que no lo conozco mucho, de momento no me fío demasiado. Ya tendré oportunidad de cambiar esto más adelante, si tengo motivos.

    ¿Confiarías en "Pepito Grillo <insect@somewhere.net>"
como referencia y para certificar ante ti otras claves públicas?
(1=No sé. 2=No. 3=Normalmente. 4=Sí, siempre.) ? 
[1]
  • Y eso es todo. Hemos hecho tres cosas distintas:

    • interpretar un fichero: 
      	  	pgp 'fichero'
    • certificar una clave. Ocurre automáticamente como parte del proceso anterior. También podemos hacerlo aparte: 
      	  	pgp -ks 'fichero'
    • asignar nivel de confianza a una clave. Ocurre automáticamente como parte del proceso anterior. También podemos hacerlo aparte: 
      	  	pgp -ke 'fichero'

    Verificando una firma.

     Como de costumbre, pgp <fichero>. Pueden pasar tres cosas:

    • Clave pública del firmante desconocida: no se puede verificar.
    • Firma incorrecta de <id>: es una firma auténtica del usuario <id>, pero no concuerda con el contenido del documento (no se garantiza que dicho documento no haya sido modificado).
    • Firma correcta de <id>: es una firma auténtica del usuario <id>, y además concuerda con el contenido del fichero, que no ha sido modificado de ninguna forma después de hecha la firma. 
    $ pgp 'fichero'


El fichero tiene firma. Se necesita la clave pública para comprobarla.
Firma correcta de "Dixie <flatline@matrix.net>".
Firma realizada el 1996/02/16 12:21 GMT con una clave de 1024 bits, identificador 87654321
  • Vemos que la firma es auténtica, y que además el fichero está intacto. Bien.

    AVISO: Esta clave pública no está certificada con una firma de confianza,
por lo que no se sabe con seguridad si realmente pertenece a:
 "Dixie <flatline@matrix.net>".
    

Ya has permitido antes que se utilice esta clave pública.
  • Esto no tiene por qué salir siempre. Es un aviso que nos pone en guardia sobre el hecho de que la clave pública de Dixie nunca ha sido certificada, por lo que podría no ser de quien nosotros creemos. Al añadir nuevas claves, PGP nos permitirá añadir claves que no tengan certificación válida y nos permitirá no certificarlas nosotros. Pero en este caso, nos avisará siempre que las usemos de que podrían no ser fiables.

    Nombre del fichero normal: fichero
    
El fichero de salida 'fichero' ya existe. ¿Sobrescribir (s/N)?
[s]

    Verificando una firma en dos partes.

     En algunos casos la firma no está en el mismo fichero. Por ejemplo, no es raro encontrarse en los servidores de FTP con <fichero>.tar.gz y lt;fichero>.tar.gz.sig (por ejemplo). Eso quiere decir que ...sig es una firma digital del otro fichero. Para verificarla, daremos a PGP el fichero que contiene la firma, no el que contiene los datos (que podrá llamarse igual sin el .sig, o se nos preguntará su nombre):

    $ pgp <fichero>.tar.gz.sig
    Por lo demás, todo es igual.

    Descifrando un fichero.

     De nuevo el procedimiento es el mismo:

    $ pgp <fichero>

Pretty Good Privacy(tm) 2.6.3i - Criptografía de clave pública para todos.
(c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-01-18
Versión internacional - no apta para los EE.UU. No utiliza RSAREF.
Hora actual: 1996/02/19 16:49 GMT

El fichero está cifrado. Para leerlo se necesita la clave secreta. 
Clave del usuario: Ruben Martinez <ruben.martinez@rediris.es>
Clave de 1024 bits, con identificador 146DE28D, creada el 
También conocido como: Ruben Martinez <ruben@rediris.es>

Se necesita la contraseña para abrir la clave secreta RSA. 
Introduce la contraseña: La contraseña es correcta.  Un momento......
Nombre del fichero normal: fichero
El fichero de salida 'fichero' ya existe. ¿Sobrescribir (s/N)? 
[s]

    Gestión de claves.

     Hemos visto cómo añadir nuevas claves públicas. Podemos también eliminarlas (pgp -kr ), cuando ya no las queramos tener. Pero en general, ¿qué hacemos con todas esas claves públicas?

    • ¿Por qué no compartir los ficheros de claves?

      ¡No! Cada clave en tu pubring.pgp lleva implícita tu estimación de su credibilidad. Eso es una valoración subjetiva, y por lo tanto personal e intransferible.

    • ¿Por qué no compartir sólo las claves, dejando a los usuarios que se hagan copias locales con su propia estimación de credibilidad y sólo de aquellas que necesiten?.

      Eso está mejor. Puesto que las claves públicas son públicas, cualquier medio público de distribución es válido. Cada usuario podrá usar sólo las claves que tenga en su pubring.pgp, pero habrá un 'servidor' del que pueda obtener claves nuevas cuando sea necesario.

    • ¿Qué tipos de mecanismos de distribución de claves hay?

      Bajo demanda:

      • Email directo.
      • El grupo de News alt.pgp.keydist

      Servicio replicado (keyserver):

      • Interfaz email.
      • Interfaz ftp.
      • Interfaz WWW.

      Servicio distribuido (propuestas):

      • Asimilación de un protocolo distribuido similar a DNS (proyectado para PGP 3.0 o posterior).
      • Directorio X.500 (la recomendación X.509 ya contempla tal servicio, para PEM. La integración de PGP no es difícil, pero tampoco trivial)

        .

    No es la finalidad de este documento entrar más a fondo en el tema de la distribución de claves. Sólo haré una distinción básica:

    El mecanismo que te distribuye la clave puede a su vez garantizar que es fiable. En ese caso hablamos de una Autoridad de Certificación (CA).

    • Las CA estarían organizadas jerárquicamente. La certificación es top-down (de la raíz del árbol a las hojas).
    • Se confía en la integridad del sistema de certificación, lo que permite cierta relajación a la hora de verificar el contenido de las mismas claves (dicho de otra forma: una clave será sometida a un control estricto antes de ser aceptada por el sistema, pero una vez aceptada, el simple hecho de que el sistema te la ofrezca será garantía de fiabilidad).
    • Inconveniente: el mismo. El usuario no necesita hacer una verificación formal, ya que tiene la garantía del sistema. Por lo tanto, no la hará, y estará indefenso si la seguridad del sistema es comprometida.
    • El modelo de PEM sobre X.500 sigue este esquema.
    O bien dicho mecanismo puede actuar como simple agente distribuidor, dejando la cuestión de la certificación en manos del usuario.

    • Los servidores no están organizados jerárquicamente (no quiere decir que no puedan estarlo, pero no es un requisito). La certificación va incluida en las claves, por los mismos usuarios, por lo que es bottom-up (de las hojas a la raíz).
    • El sistema de distribución no garantiza nada. Los usuarios añaden sus propias certificaciones a las claves, que pueden ser creídas o no por otros usuarios. Esto es más flexible, y permite relajar la seguridad en cuanto al propio servidor de claves.
    • Inconveniente: el mismo. El usuario debe tomarse el trabajo extra de verificar y/o certificar las claves que recibe.
    • La mayor parte de los servidores de claves para PGP funcionan de esta manera.

    Revocación de claves.

     En algunos casos puede ser necesario dar de baja una clave. Los motivos pueden variar, por ejemplo: supongamos que alguien ha tenido acceso a nuestra clave secreta. Pero se plantean dos problemas:

    • Mucha gente puede tener ya nuestra clave antigua. Por no mencionar servidores de claves. Habría que notificar el cambio a todos ellos.
    • Además, hay que notificarlo de manera que sólo yo pueda dar de baja mi clave (o bien ese usuario que ha tenido acceso a la clave privada, pero eso nos da igual... si es eso lo que ha ocurrido, nos ahorra trabajo dándola de baja él mismo :)
    El procedimiento es emitir un certificado de revocación de clave. La forma es:

    $ pgp -kd ruben

Pretty Good Privacy(tm) 2.6.3i - Criptografía de clave pública para todos.
(c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-01-18
Versión internacional - no apta para los EE.UU. No utiliza RSAREF.
Hora actual: 1996/02/19 13:39 GMT

Clave del usuario: Ruben Martinez <ruben@rediris.es>
Clave de 1024 bits, con identificador 146DE28D, creada el 
También conocido como: Ruben Martinez <ruben.martinez@rediris.es>


¿Quieres revocar permanentemente tu clave pública
emitiendo un certificado de compromiso de clave secreta
para "Ruben Martinez <ruben.martinez@rediris.es>" (s/N)? [s]
  • Si decimos que sí, damos a entender una revocación definitiva. Si no, se nos preguntará si queremos 'desactivar' la clave. La desactivación es temporal, pudiendo reactivarla más adelante con el mismo comando. La desactivación puede ser aplicada también a claves públicas de otras personas (no se tendrán por válidas temporalmente). Obviamente, no ocurre lo mismo con la revocación.

    Se necesita la contraseña para abrir la clave secreta RSA. 
Clave del usuario: Ruben Martinez <ruben.martinez@rediris.es>
Clave de 1024 bits, con identificador 14F428CD, creada el 

Introduce la contraseña: La contraseña es correcta.  Un momento....
Creado el certificado de compromiso de clave.
  • Si miramos ahora, comprobaremos que la clave aún sigue ahí, pero está revocada. Para eliminarla permanentemente haríamos un 'pgp -kr '. Pero antes, extraeremos una versión ASCII de la clave revocada y la enviaremos a un keyserver, o bien a todos aquellos que pudieran tenerla.

    • Esta página ha sido firmada digitalmente usando PGP