Comunicaciones
Seguras con GNU-PG (GPG) en Linux
Este documento pretende ser una introducción a las comunicaciones
seguras usando GPG sobre Linux para no expertos en criptografía. Para
una explicación más detallada se puede consultar la Bibliografía (en inglés).
Deberemos tener instalado GPG en nuestro sistema. No trataremos aquí la
instalación de GPG. Normalmente se instala por defecto por la mayoría
de las distribuciones.
Supondremos que yo soy A y que
me quiero comunicar de forma segura con B. Las tareas esenciales que
veremos son:
- Intercambio de mensajes cifrados
que no puedan ser leídos por terceros si son interceptados.
- Firmar mensajes de forma que se
pueda estar seguro de que cuando reciba un mensaje de B sepa que
realmente lo ha enviado B y viceversa.
- Las dos anteriores.
- Cómo hacer las tareas anteriores de forma cómoda con Enigmail y Mozilla
- Crear relaciones de confianza sobre la autenticidad de las claves.
Para poder realizar las anteriores tareas es necesario generar un par de claves (pública y privada).
Supongamos que tanto A como B disponen cada uno de un par de llaves. El
principio de funcionamiento del sistema es que:
- Las claves públicas, son precisamente eso: públicas y por tanto
son disponibles para todo el mundo, apareceran publicadas en servidores
como veremos despues.
- La clave privada debe permanecer siempre bajo nuestro control,
esto es muy importante ya que si perdemos el control sobre ella,
alguien podria suplantar nuestra personalidad o bien leer nuestros
mensajes cifrados (aunque no inmediatamente ya que veremos que a su vez
las claves van encriptadas con un una PASS PRASE, que es como un passwd
pero mas largo y con posiblidad de varias palabras).
- Si B quiere enviar un mensaje crifrado a A, lo encriptará con la
clave publica de .A, y únicamente A lo podra abir con su clave privada.
- Si B quiere firmar un mensaje firmado, lo encriptara con su firma
privada y A lo podrá abrir con la clave publica de B.
Enviar y recibir mensajes encriptados
Emisión de mensajes encriptados
Para poder enviar un mensaje cifrado a B, debemos estar en posesión de la clave
pública de B.
Ésta se puede obtener por alguno de los siguientes procedimientos:
- B nos la entrega en un soporte (floppy, CD,...)
- B nos la entrega electrónicamente (correo electrónico).
- Podemos descargar la clave pública de un
servidor de claves. Para ello haremos:
gpg --keyserver pgp.mit.edu --search-key KeyID
Donde KeyID puede ser la direccion de correo de B, o el
apellido, o una parte de la direccion de correo. Entonces el servidor
nos mostrara todas las posibles alternativas y deberemos elegir una
clave. Por ejemplo si se que busco la clave de alguien del departamento
puedo hacer:
gpg
--keyserver pgp.mit.edu --search-key
.dcom.upv.es
y despues selecciono la clave de quien me interese y la guardo en mi
fichero de claves publicas.
La parte mas complicada del
procedimiento es que DEBEREMOS ESTAR SEGUROS DE LA CLAVE PUBLICA
REALMENTE PERTENECE A B.
Evidentemente, si B nos proporciona directamente su clave publica en un
diskette podemos estar seguros de que esa clave le pertenece, pero
pueden surgirnos dudas si bajamos esa clave de un servidor de claves.
Alguien podria poner una clave muy parecida a la de B y enviarle los
mensajes a el!, despues veremos cúal es el procedimiento para
asegurarnos de la autenticidad de la clave (en ingles validity).
Una vez obtenida la clave publica de B, si queremos enviarle un mensaje
cifrado usaremos su clave pública. Sólo B que posee la correspondiente
clave privada podrá
desencriptar el mensaje
Recepción de mensajes encriptados
Para que A pueda recibir mensajes cifrados, debemos generar
inicialmente el par de claves pública y privada de A. Lo haremos
ejecutando:
gpg --key-gen
Las opciones por defecto
son apropiadas para nuestras necesidades de seguirad, así que no las
cambiéis. El dato del comentario que se os requiere (comment), podría
ser algo asi como uno de los siguientes:
- UPV
- Universidad Politecnica de
Valencia
- GTS
- Direccion de correo de uso
personal
Cuando queramos descrifrar un mensaje que nos ha llegado deberemos
emplear nuestra clave privada, pero para acceder a ella se debe emplear
la PASSPRHASE (ya que las claves estan encriptadas empleando las
passprhase para evitar que nadie las pueda emplear con solo copiarse el
fichero de claves).
IMPORTANTE:
- No olvidar la passphrase y ponerla suficientemente larga y
segura. Es la única forma de poder seguir utilizando la clave privada.
- Mantener secreta la passphrase. Es la única forma de evitar que
si nuestra clave privada es robada, ésta sea usada por otros.
- No perder el archivo de claves privada y pública. Para prevenir
desastres físicos (crash del disco duro) es buena idea hacerse una
copia en CD y guardarla en lugar seguro. De lo contrario no podremos leer en el futuro ningun
mensaje que tengamos en el disco duro!!!!!!! y cuando digo no
podremos es que NO SE PUEDE, a no ser que sea valiosisimo el fichero y
que tengamos algún contacto en la CIA.
- Es conveniente generar un certificado de revocado,
imprimirlo en papel y dejarlo junto con el CD de backup. Este
certificado es como una carta de despido que uno firma al entrar en una
empresa... La idea es que si se nos olvida el passphrase en el futuro,
o se nos pierden las claves, o cualquier cosa, al menos podremos
revocar la clave publica en los servidores de forma que nadie emplee la
clave antigua.
Para facilitar el acceso a las personas que quieran enviarnos mensajes
cifrados, es buena idea el publicar nuestra clave pública en algún
servidor de claves. Lo haremos ejecutando:
gpg
--send-keys --keyserver pgp.mit.edu
Hay que tener en cuenta que una vez enviemos nuestra clave al
servidor de llaves, estas automáticamente ser reenvían a todos los
servidores de claves del mundo y que NO ES POSIBLE borrarla de ellos,
lo unico que podremos hacer es revocarla pero siempre aparecera en los
servidores de llaves aunque sea como revocada. Este comentario no es
para asustar, simplemente es para que comprobeis que teneis bien
escrito el nombre, direccion de correo y comentario antes de enviar la
clave (por ejemplo NO PONGAIS acentos ni ñ).
Firmando
Firmar mensajes
Yo, A, puedo firmar un mensaje que voy a enviar a B usando para
ello mi clave privada (de A).
B dispondrá de mi clave pública (en la que confía que es realmente
mía). Dicha clave pública le permite verificar a B que realmente el
mensaje firmado lo emitió A, que se supone que es la única persona que
dispone de la clave privada de A.
Comprobando autenticidad de claves
Firmar claves públicas de otros
Si estoy seguro de que cierta clave pública pertenece a B, puedo
firmar dicha clave pública con mi clave privada. De esta forma tendre
la certeza en el futuro de que la clave es de quien dice ser.
Antes de firmar una clave pública debo estar REALMENTE seguro de que
pertenece a la persona a la que supuestamente pertenece. Si no estas
con una seguridad del 100% NO
FIRMES la clave, esto seria engañarte a ti mismo y también
a los demás como explicaré después.
Para asegurarte de que una clave pertenece a B hay dos formas:
-1 De forma directa hablas con B en persona (o por telefono si
reconoces su voz) y veis que la clave es buena (esto es un poco
aburrido al principio cuando tienes pocas llaves, pero al final no nos
escribimos con tanta gente direfente y una vez hecho vale para toda la
vida)
-2 De forma indirecta a traves de amigos comunes
Para validar la clave de forma directa es necesario que ya sea medio
telefono, o con una tarjeta de visita o como sea que estes seguro de
hablar con B comprobeis los fingerprints
de las claves. El fingerprint es una version abreviada de la clave para
poder comparar rapidamente.
Para ver el fingerprint haz:
"gpg --fingerprint KeyID" o bien
"gpg --fingerprint direccion@de_correo
una vez comprobados ya puedes validar la clave y para eso hay que
firmarla:
gpg --edit-key KeyID
y despues puedes hacer unos comandos (haz help) entre ellos "sign"
De esta forma lo que dices es que: "estas completamente seguro de que
la clave de B que tienes realmente pertenece a B y que por tanto las
firmas de B seran de un usuario validado". Al recibir un mensaje de B
verás algo asi como: "Good signature from trusted B"
Si no firmas la clave no es demasiado grave, podras leer los mensajes
que te lleguen de B pero te quedará una pequeña duda de que no haya
nadie que este suplantando la identidad de B. A pesar de eso podrás
comprobar que el mensaje no a sido modificado desde que se envió,
porque la firma será buena y pondra algo asi al recibir un mensaje de
B: "Good signature from untrusted B".
Lo siguiente que puedes hacer es establecer un nivel de "trust" para la clave, es decir,
establecer un nivel de confianza de que B sabe lo que esta haciendo con
lo del PGP (lo que hemos hecho antes era establecer un nivel de
validity), por ejemplo
- Tu puedes estar seguro de que la clave de B y la mia pertenecen
realmente a cada uno de nosotros dos, pero sin embargo que te fies mas
de mi en cuanto a usuario de PGP que de B (cosa independiente de que te
fies de que B sea B, este concepto es validity)
La idea fundamental es que si tu te fias complentamente de mi buen uso
del PGP, las claves que yo valide quedan automaticamente validadas para
ti, sin necesiad de que establezcas comunicacion directa con las otras
personas, por ejemplo:
Si en una empresa hay alguien que se dedica meticulasmanete a verificar
las claves y todos confian en el con un nivel de trust muy alto, a
traves de el podeis establecer un nivel de confianza con los demas de
forma indirecta. Ademas en el momento que esta persona revoke una clave
y diga que no es fiable todos cambiaran su opinion sobre esa clave (por
ejemplo si alguien deja la empresa)
Supongamos que A conoce a B y B a C, y que A quiere enviar un mensaje a
C.
Si B ha validado la clave de C y A la de B, y ademas A se fia de B,
entonces puede estar seguro que la clave de C es de quien dice que es.
Para ello, lo que tiene que haber pasado anteriormente es lo siguiente:
-1- A comprueba la clave de B y la firma como hemos dicho antes, pero
ademas una vez firmada exporta sus claves al serividor pgp.rediris.es
Lo que hace entonces es enviar las claves que tiene firmadas por el,
pero NO los niveles de trust (eso
es algo privado y muy subjetivo que a nadie le interesa, por ejemplo B
se podria sentir molesto si ve en un servidor que no crees que controle
el PGP.... ,
Para enviar las claves: gpg --send-keys --keyserver
pgp.mit.edu
-2- B hace lo mismo de antes con C
-3- Cuando A quiere enviar un mensaje a C o comprobar su firma, debe importar la clave publica de C y
establecer un nivel de validity de la clave, como a traves de B llegas
a C, se hara un nivel de validity de C de TRUSTED, es decir que te
creeras que C es C por que B lo ha comprobado y tu te fias de B. Si B
no hubiera firmado la clave de C entonces lo tendrias como UNTRUSTED.
Fijate como lo que se establece de esta forma es el nivel de validity,
pero el nivel de TRUST de C lo tienes que poner tu de forma personal,
como decia antes eso es algo subjetivo y que no se exporta al servidor,
solo uno sabe en quien debe confiar.
Tambien date cuenta que a C se puede llegar a traves de otra gente,
quizas de la que te fias parcialmente, si esto es asi, generalmente dos
personas de las que te fias parcialmente (nivel de trust) hacen como
una de la que te fias totalmente. De vez en cuando las personas
intermedias pueden ir firmando claves (extendiendo la red), para
actualizar el anillo haz:
gpg --update-trustdb
gpg --refresh-keys
Ah y por ultimo para cambiar el nivel de confianza de una clave haz
gpg --edit-key keyID
y luego el comando trust"
Enigmail. Plugin para Mozilla
Para simplificar las tareas descritas en este documento, y suponiendo
que ya tenemos generadas nuestras claves pública y privada, es posible
instalar un plugin para el Navegador Mozilla.
Para ello, abriremos como root
el Navegador Mozilla y visitaremos la página:
y seguiremos las instrucciones. Yo lo he probado con Mozilla 1.5 y
funciona perfectamente.
Las opciones que yo uso, y que resultan prácticas son:
MIME
encrypt if possible
sign if encrypt
Existen soluciones similares para Evolution y Kmail, pero no las he
experimentado.
Bibliografía
Creado por Alberto Albiol y Antonio Albiol.
Departamento de Comunicaciones. Universidad Politécnica de Valencia.
ESPAÑA
Abril 2004