La orden crypt(1)
La orden crypt permite cifrar y descifrar ficheros en diferentes sistemas Unix; si no recibe parámetros lee los datos de la entrada estándar y los escribe en la salida estándar, por lo que seguramente habremos de redirigir ambas a los nombres de fichero adecuados. Un ejemplo simple de su uso puede ser el siguiente:
$ crypt <fichero.txt >fichero.crypt
Enter key:
$
En el anterior ejemplo hemos cifrado utilizando crypt el archivo fichero.txt y guardado el resultado en fichero.crypt; el original en texto claro se mantiene en nuestro directorio, por lo que si queremos evitar que alguien lo lea deberemos borrarlo.
Para descifrar un fichero cifrado mediante crypt (por ejemplo, el anterior) utilizamos la misma orden y la misma clave:
$ crypt <fichero.crypt>salida.txt
Enter key:
$
El anterior comando ha descifrado fichero.crypt con la clave tecleada y guardado el resultado en el archivo salida.txt, que coincidirá en contenido con el anterior fichero.txt.
crypt no se debe utilizar nunca para cifrar información confidencial; la seguridad del algoritmo de cifra utilizado por esta orden es mínima, ya que crypt se basa en una máquina con un rotor de 256 elementos similar en muchos aspectos a la alemana Enigma, con unos métodos de ataque rápidos y conocidos por todos ([RW84]). Por si esto fuera poco, si en lugar de teclear la clave cuando la orden nos lo solicita lo hacemos en línea de comandos, como en el siguiente ejemplo:
$ crypt clave < fichero.txt > fichero.crypt
$
Entonces a la debilidad criptográfica de crypt se une el hecho de que en muchos Unices cualquier usuario puede observar la clave con una orden tan simple como ps (no obstante, para minimizar este riesgo, el propio programa guarda la clave y la elimina de su línea de argumentos nada más leerla).
Obviamente, la orden crypt(1) no tiene nada que ver con la función crypt(3), utilizada a la hora de cifrar claves de usuarios, que está basada en una variante del algoritmo DES y se puede considerar segura en la mayoría de entornos.
PGP: Pretty Good Privacy
El software PGP, desarrollado por el criptólogo estadounidense Phil Zimmermann ([Zim95a],
[Zim95b]), es mundialmente conocido como sistema de firma digital para correo electrónico. Aparte de esta función, PGP permite también el cifrado de archivos de forma convencional mediante criptografía simétrica ([Gar95]); esta faceta de PGP convierte a este programa en una excelente herramienta para cifrar archivos que almacenamos en nuestro sistema; no es el mismo mecanismo que el que se emplea para cifrar un fichero que vamos a enviar por correo, algo que hay que hacer utilizando la clave pública del destinatario, sino que es un método que no utiliza para nada los anillos de PGP, los userID o el cifrado asimétrico. Para ello utilizamos la opción -c5.7 desde línea de órdenes:
anita:~$ pgp -c fichero.txt
No configuration file found.
Pretty Good Privacy(tm) 2.6.3i - Public-key encryption for the masses.
(c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-01-18
International version - not for use in the USA. Does not use RSAREF.
Current time: 2000/03/02 07:18 GMT
You need a pass phrase to encrypt the file.
Enter pass phrase:
Enter same pass phrase again:
Preparing random session key...Just a moment....
Ciphertext file: fichero.txt.pgp
anita:~$
Esta orden nos preguntará una clave para cifrar, una pass phrase, que no tiene por qué ser (ni es recomendable que lo sea) la misma que utilizamos para proteger la clave privada, utilizada en el sistema de firma digital. A partir de la clave tecleada (que obviamente no se muestra en pantalla), PGP generará un archivo denominado fichero.txt.pgp cuyo contenido es el resultado de comprimir y cifrar (en este orden) el archivo original. Obviamente, fichero.txt no se elimina automáticamente, por lo que es probable que deseemos borrarlo a mano.
Si lo que queremos es obtener el texto en claro de un archivo previamente cifrado simplemente hemos de pasar como parámetro el nombre de dicho fichero:
anita:~$ pgp fichero.txt.pgp
No configuration file found.
Pretty Good Privacy(tm) 2.6.3i - Public-key encryption for the masses.
(c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-01-18
International version - not for use in the USA. Does not use RSAREF.
Current time: 2000/03/02 07:24 GMT
File is conventionally encrypted.
You need a pass phrase to decrypt this file.
Enter pass phrase:
Just a moment....Pass phrase appears good. .
Plaintext filename: fichero.txt
anita:~$
Como vemos, se nos pregunta la clave que habíamos utilizado para cifrar el archivo, y si es correcta se crea el fichero con el texto en claro; como sucedía antes, el archivo original no se elimina, por lo que tendremos ambos en nuestro directorio.
PGP ofrece un nivel de seguridad muchísimo superior al de crypt(1), ya que utiliza algoritmos de cifra más robustos: en lugar de implementar un modelo similar a Enigma, basado en máquinas de rotor, PGP ofrece cifrado simétrico principalmente mediante IDEA, un algoritmo de clave secreta desarrollado a finales de los ochenta por Xuejia Lai y James Massey. Aparte de IDEA, en versiones posteriores a la utilizada aquí se ofrecen también Triple DES (similar a DES pero con una longitud de clave mayor) y CAST5, un algoritmo canadiense que hasta la fecha sólo ha podido ser atacado con éxito mediante fuerza bruta; este último es el cifrador simétrico utilizado por defecto en PGP 5.x.
TCFS: Transparent Cryptographic File System
TCFS es un software desarrollado en la Universidad de Salerno y disponible para sistemas Linux que proporciona una solución al problema de la privacidad en sistemas de ficheros distribuidos como NFS: típicamente en estos entornos las comunicaciones se realizan en texto claro, con la enorme amenaza a la seguridad que esto implica. TCFS almacena los ficheros cifrados, y son pasados a texto claro antes de ser leídos; todo el proceso se realiza en la máquina cliente, por lo que las claves nunca son enviadas a través de la red.
La principal diferencia de TCFS con respecto a otros sistemas de ficheros cifrados como CFS es que, mientras que éstos operan a nivel de aplicación, TCFS lo hace a nivel de núcleo, consiguiendo así una mayor transparencia y seguridad. Obviamente esto tiene un grave inconveniente: TCFS sólo está diseñado para funcionar dentro del núcleo de sistemas Linux, por lo que si nuestra red de Unix utiliza otro clon del sistema operativo, no podremos utilizar TCFS correctamente. No obstante, esta gran integración de los servicios de cifrado en el sistema de los ficheros hace que el modelo sea transparente al usuario final.
Para utilizar TCFS necesitamos que la máquina que exporta directorios vía NFS ejecute el demonio xattrd; por su parte, los clientes han de ejecutar un núcleo compilado con soporte para TCFS. Además, el administrador de la máquina cliente ha de autorizar a los usuarios a que utilicen TCFS, generando una clave que cada uno de ellos utilizará para trabajar con los ficheros cifrados; esto se consigue mediante tcfsgenkey, que genera una entrada para cada usuario en /etc/tcfspasswd:
rosita:~# tcfsgenkey
login: toni
password:
now we'll generate the des key.
press 10 keys:
Ok.
rosita:~# cat /etc/tcfspasswd
toni:2rCmyOUsM5IA=
rosita:~#
Una vez que un usuario tiene una entrada en /etc/tcfspasswd con su clave ya puede acceder a ficheros cifrados; para ello, en primer lugar utilizará tcfslogin para insertar su clave en el kernel, tras lo cual puede ejecutar la variante de mount distribuida con TCFS para montar los sistemas que el servidor exporta. Sobre los archivos de estos sistemas, se utiliza la variante de chattr de TCFS para activar o desactivar el atributo X (podemos visualizar los atributos de un fichero con lsattr), que indica que se trata de archivos que necesitan al demonio de TCFS para trabajar sobre ellos (cifrando o descifrando). Finalmente, antes de abandonar una sesión se ha de ejecutar tcfslogout, cuya función es eliminar la clave del kernel de Linux. También es necesaria una variante de passwd, proporcionada con TCFS, que regenera las claves de acceso a archivos cifrados cuando un usuario cambia su password.
TCFS utiliza uno de los cuatro modos de funcionamiento que ofrece el estándar DES ([oS80]) denominado CBC (Cipher Block Chaining). El principal problema de este modelo (aparte de la potencial inseguridad de DES) es la facilidad para insertar información al final del fichero cifrado, por lo que es indispensable recurrir a estructuras que permitan detectar el final real de cada archivo; otro problema, menos peligroso a priori, es la repetición de patrones en archivos que ocupen más de 34 Gigabytes (aproximadamente), que puede conducir, aunque es poco probable, a un criptoanálisis exitoso en base a estas repeticiones. Más peligroso es el uso del mismo password de entrada al sistema como clave de cifrado utilizando la función resumen MD5 (el peligro no proviene del uso de esta función hash, sino de la clave del usuario); previsiblemente en futuras versiones de TCFS se utilizarán passphrases similares a las de PGP para descifrar y descifrar.
Otros métodos de almacenamiento seguro
En los últimos años los usuarios de Unix se han concienciado cada vez más con la seguridad de los datos que poseen en sus sistemas, especialmente de la privacidad de los mismos: un sistema fiable ha de pasar necesariamente por un método de almacenamiento seguro; por supuesto, esta preocupación de los usuarios automáticamente se traduce en más investigaciones y nuevos desarrollos en este campo de la seguridad. En este capítulo hemos analizado las ventajas, las desventajas y el funcionamiento de algunos de estos sistemas, desde el modelo clásico y habitual en Unix hasta las últimas herramientas de análisis forense y su problemática, pasando por aplicaciones tan simples como crypt o tan complejas como PGP; aunque se ha pretendido dar una visión general de lo que se entiende por un almacenamiento seguro en Unix, es imposible tratar todas las implementaciones de sistemas que incrementan la seguridad en la actualidad. No obstante, antes de finalizar este capítulo hemos preferido comentar algunas de las características de sistemas que se han hecho ya, se están haciendo, o previsiblemente se harán en un futuro no muy lejano un hueco importante entre los mecanismos de almacenamiento seguro en Unix.
No podemos finalizar sin hablar del sistema CFS (Cryptographic File System), del experto en seguridad Matt Blaze ([Bla93]), que se ha convertido en el sistema más utilizado en entornos donde coexisten diferentes clones de Unix (ya hemos comentado el problema de TCFS y su dependencia con Linux). Provee de servicios de cifrado a cualquier sistema de ficheros habitual en Unix, NFS incluido, utilizando una combinación de varios modos de trabajo de DES que son lo suficientemente ligeros como para no sobrecargar demasiado a una máquina normal pero lo suficientemente pesados como para proveer de un nivel aceptable de seguridad. Los usuarios no tienen más que asociar una clave a los directorios a proteger para que CFS cifre y descifre sus contenidos de forma transparente utilizando dicha clave; el texto en claro de los mismos nunca se almacena en un dispositivo o se transmite a través de la red, y los procedimientos de copia de seguridad en la máquina no se ven afectados por el uso de CFS. Todo el proceso se realiza en el espacio de usuario (a diferencia de TCFS, que operaba dentro del kernel de Linux) utilizando principalmente el demonio cfsd en la máquina donde se encuentren los sistemas cifrados.
Peter Gutmann, del que ya hemos hablado en este capítulo, desarrolló en la primera mitad de los noventa SFS (Secure File System). Este modelo de almacenamiento seguro se diseñó originalmente para sistemas MS-DOS o Windows, donde funciona como un manejador de dispositivos más, aunque en la actualidad existen también versiones para Windows 95, Windows NT y OS/2. No está portado a Unix, pero aquí lo citamos porque existe un sistema de almacenamiento seguro para Unix denominado también Secure File System, SFS, pero no tiene nada que ver con el original de Gutmann. El SFS de Unix funciona de una forma similar a CFS pero utilizando el criptosistema Blowfish y una versión minimalista de RSA en lugar de DES; no vamos a entrar en detalles de este software principalmente porque su uso en entornos Unix no está ni de lejos tan extendido como el de CFS.
La criptografía es la herramienta principal utilizada en la mayoría de los sistemas de almacenamiento seguro; sin embargo, todos ellos plantean un grave problema: toda su seguridad reside en la clave de cifrado, de forma que el usuario se encuentra indefenso ante métodos legales - o ilegales - que le puedan obligar a desvelar esta clave una vez que se ha determinado la presencia de información cifrada en un dispositivo de almacenamiento. Esto, que nos puede parecer algo exagerado, no lo es en absoluto: todos los expertos en criptografía coinciden en afirmar que los métodos de ataque más efectivos contra un criptosistema no son los efectuados contra el algoritmo, sino contra las personas (chantaje, amenazas, presiones judiciales...). Intentando dar solución a este problema, durante los últimos años de la década de los noventa, prestigiosos investigadores de la talla de Roger Needham, Ross Anderson o Adi Shamir ([ANS98]) han establecido las bases de sistemas seguros basados en modelos esteganográficos, con desarrollos especialmente importantes sobre plataformas Linux ([MK99], [vSS98]...). La disponibilidad del código fuente completo de este clon de Unix unida a su política de desarrollo ha propiciado enormemente estos avances, hasta el punto de que existen en la actualidad sistemas de ficheros basados en esteganografía que se insertan en el kernel igual que lo hace un sistema normal como ufs o nfs, o que se añaden a ext2 proporcionando funciones de cifrado.
La idea es sencilla: si por ejemplo tenemos cinco archivos cifrados con una aplicación como PGP, cualquier atacante con acceso al dispositivo y que haga unas operaciones sobre ficheros puede determinar que tenemos exactamente esos archivos cifrados; con esta información, su labor para obtener la información está muy clara: se ha de limitar a obtener las cinco claves privadas usadas para cifrar los ficheros. Conocer el número exacto es de una ayuda incalculable para el atacante. Con los sistemas esteganográficos, a pesar de que es imposible ocultar la existencia de cierta información cifrada, alguien que la inspeccione no va a poder determinar si la clave de descifrado que el propietario le ha proporcionado otorga acceso a toda la información o sólo a una parte de la misma. Un atacante que no posea todas las claves no va a poder descifrar todos los ficheros, y lo más importante: no va a poder saber ni siquiera si otros archivos aparte de aquellos a los que ha accedido existen o no, aunque posea un acceso total al software y al soporte físico. Para conseguir esto se utiliza una propiedad de ciertos mecanismos de seguridad denominada plausible deniability, algo que se vendría a traducir como `negación creible'; dicha propiedad permitiría a un usuario negar de forma creible que en un dispositivo exista más información cifrada de la que ya se ha podido descubrir, o que cierta transacción se haya llevado a cabo. Volviendo al ejemplo de PGP, el usuario podría revelar la clave de cifrado de sólo uno o dos de los archivos, aquellos que no considere vitales, ocultando las claves y la existencia del resto sin que el atacante sea capaz de determinar que la información accedida no es toda la existente.
