BULMA Bulma amb el projecta Defective by Desing
Bergantells Usuaris de GNU/Linux de Mallorca i Afegitons   |   Bisoños Usuarios de GNU/Linux de Mallorca y Alrededores
CONTENIDOS
. Jornadas de software libre
. Version para PDA
. Enlaces breves
. La asociacion
. Los mas leidos
. Autores [Actividad]
. Ultimos Comentarios
. Todos los titulares!
. Estadisticas
. Guia de estilo
. ¿Sugerencias?
. Wiki
. XML [Ayuda]
Listas de correo
. Archivos bulmailing
. Archivos BulmaGes
Radio libre :-)
. Des de la Xarxa (Archivos)
. Mallorca en Xarxa
Busquedas

+ Enlaces Linux
Ultimos kernels
(02/09/2010 20:12:57)
    
Google


En bulma.net
En internet
Cifrando un sistema de ficheros (20066 lectures)
Por Carles Pina i Estany
cpina (http://pinux.info)
Creado el 30/01/2004 01:05 modificado el 30/01/2004 01:05

En Linux tenemos soporte para muchos sistemas de ficheros, y también para sistemas de ficheros tipo "loopback" (es como un sistema de ficheros dentro de un fichero).

También, y sobretodo a partir de la versión 2.6 del Kernel que ya viene incluido de serie, tenemos muy buen soporte para sistemas de criptografía.

En este "breve" veremos como podemos unir las dos partes: criptografía y sistemas de ficheros. Y todo sin tener que reparticionar. Veremos como podemos trabajar de forma normal y transparente en un fichero que estará cifrado.

Versió en català disponible aquí (Catux)

Pagina1/1

Introducción

Con los sistemas de ficheros cifrados podremos montar un sistema de ficheros que se necesite contraseña para acceder en él. Sin la contraseña, nadie podrá ver su contenido (ni root ni nadie) ya que la información estará cifrada.

Aunque tenemos todo el sistema de permisos inherente de Linux (y cualquier Unix), eso puede ser útil por si nos roban físicamente el disco duro. O si somos algo descuidados y se puede arrancar mediante CD-ROM, pasarle parámetros a nuestro Kernel, etc.

Aquí explicaremos como usar los sistemas de ficheros cifrados en un Kernel 2.6.1 (aunque en cualquier 2.6.x debería ser muy parecido, hasta con los 2.4.x y con los parches de http://www.kerneli.org.

Compilación del Kernel

Supongamos que nos hemos bajado un Kernel 2.6.x y lo sabemos compilar de forma correcta.

Deberemos ir a la configuración del Kernel en el apartado Cryptographic options y activar los algoritmos de cifrado que deseemos. Útiles para hacer algunas pruebas podrian ser NULL, MD5, DES and Triple DES, Blowfish aunque podemos poner más. Los seleccionaremos, al menos de momento, todos como módulos.

También tenemos que ir en Device Drivers, después el menú Block devices y marcar la opción Loopback device support con la opción, como módulo de Cryptoloop Support.

Y herramientas de usuario

Necesitamos soporte para criptografía en al menos el paquete mount (lo estaremos usando con el losetup). El paquete de Debian no tiene el último parche para criptografía. Podemos descargarnos el paquete desde aquí. En Gentoo parece que al hacer el emerge ya pone el parche para soporte de criptografía.

Como nota curiosa, con el paquete mount que viene en Debian Sid, no hay problema para cifrar con el algoritmo blowfish pero en cambio con otros algoritmos no podremos hacerlo (nos dará un error)

Montando un fichero... sin cifrar

Lo que haremos ahora es crear un fichero y montarlo a través del dispositivo de loopback como si fuera una partición. En el otro punto haremos lo mismo pero cifrando el fichero.

Los pasos para montar el fichero pasando por el dispositivo de loopback y sin cifrar serian:

dd if=/dev/zero of=fichero.ext2 bs=1M count=100
De esa forma hacemos un fichero "en blanco" de 100 MB.

losetup /dev/loop0 fichero.ext2
Ahora hemos asociado el /dev/loop0 al fichero.ext2. Lo podemos comprobar si ejecutamos:

pinux:/mnt/dades# losetup /dev/loop0
/dev/loop0: [0308]:3 (fitxer.cripto)
Ahora podemos pensar que tenemos en /dev/loop0 una "nueva partición". Por tanto podemos hacer: mkfs -t ext2 /dev/loop0
Y ya habremos formateado la "nueva partición".

Después, como siempre en las particiones podemos hacer: mount -t ext2 /dev/loop0 prueba/
Para comprobar que ha ido bien, ejecutamos mount y veremos una línea como:

/dev/loop0 on /mnt/dades/prueba type ext2 (rw)
Y podemos trabajar en él de forma normal. Cuando terminemos: umount /dev/loop0 losetup -d /dev/loop0 Es importante recordar el losetup final porqué sinó queda "medio desmontado".

Montando un fichero... cifrado

Antes de todo, cargaremos el módulo cryptoloop (modprobe cryptoloop). También cargaremos el sistema de cifrado que deseemos, por ejemplo blowfish, des, twofish, etc.

Para crear el fichero, esa vez es mejor hacerlo así:
dd if=/dev/urandom of=fichero bs=1M count=10
(de esa forma no será todo "nulos", sinó que contendrá datos aleatorios desde el principio)

Seguidamente haremos:
losetup -e blowfish /dev/loop0 fichero.ext2
Donde nos pedirá la contraseña para el sistema de ficheros.

Después lo podemos formatear como antes y montar de forma normal:

mkfs -t ext2 /dev/loop0
mount -t ext2 /dev/loop0 prueba/
Y a partir de aquí tenemos de forma fácil un sistema de ficheros, contenido en un fichero y cifrado. Podemos trabajar en él de forma totalmente normal.

Cuando terminemos:

umount /dev/loop0
losetup -d /dev/loop0
Como última nota, cuando lo volvamos a montar:
losetup -e blowfish /dev/loop0 fichero.ext2
mount -t ext2 /dev/loop0 prueba/
Si en losetup nos equivocamos de contraseña no se "quejará", pero el mount fallará (ya que al no poder descifrar el sistema de ficheros no puede acceder al superblock y otra información necesaria para montarla).

Al ejecutable losetup le podemos pasar el algoritmo de cifrado y también el número de bits que queremos que se usen para el cifrado. Por ejemplo, valores válidos pueden ser des-64 3des_ede-192 blowfish-32 blowfish-256 twofish-256, etc. Cuantos más bits de cifrado, el algoritmo es más seguro pero también más lento.

Lo hemos hecho con ext2 pero lo podemos hacer con cualquier otro sistema de ficheros. Pero si lo hicieramos con ReiserFS recordar que él ya usa 30MB para hacer el Journaling, que en una partición normalmente no tiene mayor importancia pero si estamos haciendo un fichero de 50MB o 100MB puede ser demasiado.

Hay información de los sistemas de cifrado (a medida que vamos cargando más módulos) en /proc/crypto

¿Y la velocidad?

Evidentemente, el hecho de estar cifrando y descifrando tiene su penalización de rendimiento. He hecho un pequeño "benchmark" (si se puede llamar así). El ordenador es un Pentium 3 a 1000 Mhz portátil (Compaq Presario 1700) y el disco duro responde de esa forma:
pinux:/mnt/dades# hdparm -t /dev/hda

/dev/hda:
 Timing buffered disk reads:   50 MB in  3.08 seconds =  16.22 MB/sec
 pinux:/mnt/dades# hdparm -T /dev/hda

/dev/hda:
 Timing buffer-cache reads:   756 MB in  2.00 seconds = 377.11 MB/sec
 pinux:/mnt/dades#
Copiar un fichero de 67 MB sin usar el losetup tarda unos 19 segundos (origen y destino en el mismo disco duro, diferentes particiones).

Copiarlo dentro de un fichero con losetup, tarda más o menos lo mismo (unos 19-20 segundos).

Ya por último, en des-64, blowfish-32, blowfish-256, twofish-256, etc. tarda aproximadamente lo mismo (20-21 segundos; puede llegar a 22-23 segundos con twofish).

Y con 3des_ede-192 tarda unos 31 segundos aproximadamente (un 50% más que los otros).

La prueba es tan simple que no se pueden sacar conclusiones más allá que para un uso normal de los datos no penaliza mucho. Por ejemplo, se podria tener sin mucho problema el ~/mail y algun otro directorio montados de esa forma y trabajar de forma habitual.


Imprimir
Version para
imprimir

Imprimir
Version
PDF
Comentarios
Es posible que se hayan omitido algunos comentarios considerados poco constructivos
1.  Re: Cifrando un sistema de ficheros (30/01/2004 10:19, #19498)
  Por: teleyinex (http://www.sleon.org)
Interesante artículo, lo único que lo veo un poco pesado el tener que andar montando con dos comandos cada vez. Esto estaría bien usarlo en los memory stick USB, pero igual es más fácil encriptar con gpg el archivo. Es una idea.

De todas formas, genial el artículo.

 
2.  Re: Cifrando un sistema de ficheros (30/01/2004 19:26, #19515)
  Por: Count
De hecho se pueden simplificar los 'mounts' poniendo las opciones en el mismo fstab (y te ahorras el losetup)

noauto,user,loop=/dev/loop3,encryption=AES128

En quanto al GPG, se puede usar para encriptar de nuevo la llave AES-128. Para poner un ejemplo mi config:

- El dispositivo encriptado es un fichero imagen
- El password de la llave AES-128 és una cadena generada mediante /dev/urandom (256 caracteres)
- La cadena password anterior està encriptada con mi clave GPG (el password de la qual és más corta y me la sé de memoria).

Con esto sólo debo conocoer mi password GPG.

Añadiendo esto a las opciones del fstab:

gpgkey=/misc/usb/keychain.gpg,gpghome=...

Para poder acceder al dispositivo se requiere: Otro dispositivo removible (en este caso mi USB-stick /misc/usb) que contiene la llave AES-128 y conocer el password GPG para poder acceder a la llave AES-128 que desencripta el dispositivo. Resumiendo: Paranoico.

Si ademas usas autofs para montar el USB-stick montar el dispositivo cuesta lo mismo que montar qualquier otro.

(Hay disponible un par de HOWTOs muy interesnates en TLDP)

 
3.  Re: Cifrando un sistema de ficheros (31/01/2004 23:40, #19543)
  Por: Edgar
Podrías poner la dirección del howto para hacer eso? He buscado en tldp.org/howto pero nada... :S Me interesa ese nivel de paranoia :D

 
4.  Re: Cifrando un sistema de ficheros (03/02/2004 10:20, #19588)
  Por: Anònim
Autofs
Cryptoloop
Disk Encryption
Encr iptar /

Como puedes ver todos en TLDP (a ver si buscamos mejor)....

 
5.  Re: Cifrando un sistema de ficheros (08/02/2004 18:15, #19684)
  Por: Edgar
Bueno si, pero yo me refería a encriptar la clave con gnupg, y eso no lo encuentro... Gracias :)

 
6.  Re: Cifrando un sistema de ficheros (02/02/2004 14:17, #19570)
  Por: Pedro b
En mandrake al menos lo de loop no hace falta en el fstab, con poner una / al principio del fichero funciona ejemplo:

//mnt/removable/datos_confidenciales /home/pedro/confidencial ext3 user,exec,dev,suid,encrypted,encryption=AES256,noauto 0 0

 
7.  Re: Cifrando un sistema de ficheros (17/07/2006 21:25, #33784)
  Por: Anónimo
Tengo un problema, al intentar montar el dispositivo, con la entrada del fstab me lanza el siguiente error: mount: tipo de sistema de ficheros incorrecto, opción incorrecta, superbloque incorrecto en /dev/loop0, falta la página de códigos, o algún otro error Alguien sabe a que puede ser debido? La entrada en el fstab es esta: /home/marc/private /mnt/private ext2 noauto,encrypted,encryption=blowfish,user,exec,uid=marc 0 0

 
8.  Re: Cifrando un sistema de ficheros (30/01/2004 11:03, #19499)
  Por: Anónimo (http://www.shiru.org)
Excelente metodo de cifrado, muy util para las copias de seguridad , hace tiempo que buscaba algo similar

A pesar de que el metodo de montar y desmontar , es cierto que se hace un poco complejo


 
9.  Re: Cifrando un sistema de ficheros (30/01/2004 14:25, #19504)
  Por: cpina (http://pinux.info)
Más abajo he puesto un "mini-script" para no tener 2 comandos a la vez y no tener que ser root.

En copias de seguridad, y como podemos usar el "nuevo" sistema de ficheros de forma normal, hasta podemos hacerlo con rsync y copiar solo los cambios (o tar, etc.). Si lo hacemos con gpg o otros métodos deberiamos seguramnete descifrar todo para modificar los cambios y cifrar de nuevo.

Gracias


 
10.  Re: Cifrando un sistema de ficheros (30/01/2004 12:09, #19500)
  Por:
¿Que tal? Me parece muy interesante el articulo pero se me presentan algunas dudas, quiza sea falta de vision sobre el tema, pero ¿hay que estar siempre logeado como root para hacer estas operaciones?
Y si no es extrictamente necesario ser root que ¿permisos hay que conceder para que "cualquiera" o solo los usuarios que determine el administrador del sistema?

Espero aportar algo con mi pregunta.

 
11.  Re: Cifrando un sistema de ficheros (30/01/2004 13:40, #19501)
  Por: Anónimo
Para automatizar el montado/desmontado con un pequeño script con el losetup y el mount sirve. Para no tener que andar logeando como root basta con usar sudo. Ahi quedan mis 2¢

 
12.  Re: Cifrando un sistema de ficheros (30/01/2004 14:22, #19503)
  Por: cpina (http://pinux.info)
Eso iba a contestar, gracias!

Pongo por aqui el script y algo de sudo por si alguien le es útil

El script sería algo como:

-------------
#!/bin/bash

sudo losetup -e /dev/loop0 /home/pepe/fichero.cripto

mount -t ext2 /home/pepe/fichero.cripto
-----------

Para que el mount no necesite sudo, necesitaremos que en el fstab haya una entrada parecida a:

/dev/loop0 /home/pepe/directorio.cripto ext2 user 0 0

Para desmontar, parecido a eso (umount + sudo con losetup en un script).

Para configurar sudo tenemos un articulo muy bueno en Bulma.

De todas formas, y de forma muy mal puesto en el fichero /etc/sudoers (editarlo con visudo) debería haber una línea parecida a:

pepe ALL=NOPASSWD: /sbin/losetup

Así ya debería funcionar casi.


 
13.  y root? como nos protegemos de él? (30/01/2004 23:46, #19521)
  Por: deabru
hay algo que no entiendo: en cuanto el usuario, mediante el scipt o como sea, monte el fichero encriptado, root podrá acceder al contenido no?? y si no cuidamos los permisos el resto de los usuarios también? o se hace la desencriptación en tiempo real con autentificación de usuario? (esto último no seria tampoco un problema)

 
14.  Re: y root? como nos protegemos de él? (31/01/2004 00:09, #19522)
  Por: cpina (http://pinux.info)
Correcto, cuando está montado es como un sistema de ficheros más (y root podrá acceder en él, o quien "tenga permisos")

 
15.  Re: y root? como nos protegemos de él? (31/01/2004 20:41, #19539)
  Por: deabru
bueno... casi que da igual, si root quisiera ver los documentos de ese usuario le podría meter un keyloger y pillarle todas las pass. Y esto por diseño creo que no se puede evitar, y como root puede ser cualquier usuario sin necesidad de pass, pues autorización por uid tampoco funciona (algún nfs remoto donde root no fuese todopoderoso).

pero bueno, vamos a ver más claramente el tema de la criptografía :D

 
16.  Re: y root? como nos protegemos de él? (02/02/2004 05:56, #19563)
  Por: Anónimo
Root solo puede instalar un keylogger si puede cargar modulos en el kernel, y eso se puede limitar, incluso a root.

 
17.  Cómo sería en Hurd? (31/01/2004 19:38, #19535)
  Por: Anònim
Hurd es un sistema operativo completo que intenta mantener el mínimo de código en el kernel para que la mayoria de operaciones se ejecuten en espacio de usuario.
Por ejemplo, operaciones como montar un sistema de ficheros propio de un usuario se puede hacer sin los permisos de administrador. La pregunta es: como es que los UNIX tradicionales necesitan ejecutar código de sistema para las operaciones más elementales si solo afecta a su espació de usuario (entendiendo espacio de disco).
Hurd permite a los usuarios normales montar sus sistemas de ficheros sin tenen que gestionar permisos. Además incopora el concepto de traductor. De forma facil, dada una entrada de datos, la transforma en otra de forma total transparente. De forma que se pueden enlazar la salida de uno con la entrada del siguiente.
Por ejemplo, usando las dos possibilidades, un usuario puede acceder por NFS a los ficheros de otro PC sin los permisos de root.
Segun la idea de Hurd, un sistema de ficheros encriptado sería poner un traductor que se encarge de gestionar el algorismo de encriptación. Para el usuario seria tranparente de forma total.
Personalmente creo que este planteamiento es más elegante y evita muchos de los puntos a tener en cuenta en Linux. Solo hay un problema, el desarrollo de Hurd es muy lento y ahun no se ha conseguido muchas de las cosas que existen a linux des de hace tiempo.

 
18.  Re: Cómo sería en Hurd? (02/02/2004 06:01, #19564)
  Por: Anónimo
La pregunta es: como es que los UNIX tradicionales necesitan ejecutar código de sistema para las operaciones más elementales si solo afecta a su espació de usuario (entendiendo espacio de disco).

Por que en los sitemas monoliticos es las llamadas que se encargan de "hablar" con el hardware, interpretar sistemas de archivos, etc, etc, estan en el nucleo, aunque sea posible tener bibliotecas en espacio de usuario que hagan ciertas cosillas de ese tipo, como openssl ->cryptoapi, o implementaciones de NFS en espacio de usuario. Es una cuestion de diseño de los kernels monoliticos.


 
19.  Re: Cómo sería en Hurd? (02/02/2004 08:08, #19565)
  Por: cpina (http://pinux.info)
O ya que ponemos ejemplos, aprovecho para comentar que también hay lufs (Linux User File System). Sirve para tener sistemas de ficheros en la parte Usuario, podemos montar con eso un "sftp" como si fuera un directorio local (tipo NFS). O también FTP... queria ponerlo junto a este artículo pero se me alargó mucho :-) (parche al Kernel + utilidades en espacio de usuario).

A ver si tengo tiempo y lo explico en otro artículo...


 
20.  Re: Cifrando un sistema de ficheros (01/02/2004 16:20, #19555)
  Por: Anònim
Un apunte rápido acerca de criptografía. DES está oficialmente declarado obsoleto por la NSA y blowfish-32 no es muy seguro que digamos. 3-DES es lento. Blowfish-256 es bueno pero Twofish-256 es más moderno, rápido y de mayor calidad. Para los hiperparanoicos siempre queda AES-256. Mi recomendación: Twofish-256

 
21.  Re: Cifrando un sistema de ficheros (04/02/2004 16:17, #19604)
  Por: Anónimo (http://www.unsec.net)
Hola,

Solo un apunte, yo hace poco hice un mini-como bastante parecido, solo que añadiendo LVM al tema, esta disponible en mi wiki: aqui

Un saludo

 
22.  Re: Cifrando un sistema de ficheros (18/08/2005 00:39, #27918)
  Por: kagate_lorito
Solo queria decir una cosilla, puede ser que al intentar asociar el fichero que hemos creado con el dispositivo de loopback de un fallo

damon@kagate:~$ sudo losetup -e aes /dev/loop1 particio
Password:
ioctl: LOOP_SET_STATUS: L'argument passat no és vàlid


Esto no quiere decir que la hayamos cagado al poner el comando ni nada por el estilo, simplemente es que no hemos cargado el modulo 'cryptoloop'. Si lo cargamos y luego ponemos esa orden deberia ir todo sin problemas.

Otra cosa que nos puede dar error es si el dispositivo de loopback ya estaba siendo usado o se ha dejado en un estado jodido debido a que hemos desmontado pero no lo hemos desasociado del fichero que antes habiamos creado.

damon@kagate:~$ sudo losetup -e aes /dev/loop2 particio
Password:
ioctl: LOOP_SET_FD: El dispositiu o recurs es troba ocupat

En este caso, simplemente lo desasociamos con 'losetup -d /dev/loop2', o si nos da problemas nos buscamos otro libre xD

Vinga,AU

 
GRACIAS
Distribuciones Universal
Por el servidor
Dpto. de Matematicas e Informatica
Calificacion
***0
Vots: 24
Danos tu opinion:
**** Excelente
***0 Muy Bueno
**00 Bueno
*000 Regular
0000 Malo
Relacionados
. Cap.1: Introducción GnuPG
Necesidad y guía rápida de 7 pasos
SECCIONES
Noticia
Breve
Truco
Enlace
Participa
Proyecto
Articulo
Webbulma
Manoletada :-)
Seguridad
Modificado: 26/10/2009 09:36:53 | Tiempo Total: 0.075 segs | Kernel: Linux - i686 - 2.6.26-1-686 | Last boot: 02/09/2010 20:45 CEST
Powered by Apache    MySQL    PHP    Gimp