Festplattenverschlüsselung auf fritzbox mit 2.6er kernel

hi leute,

da ich meine mit luks verschlüsselte USB-HDD mit der fritzbox nutzen wollte habe ich mich mal daran gemacht die fritzbox cryptsetup-tauglich zu machen (ohne den kernel zu modifizieren also alles als module!)

ist alles noch sehr experimentell und nicht sehr ausgiebig getestet, trotzdem wollte ich die community mal teilhaben lassen.

ich habe ein kleines paket zusammengestellt das alle benötigten kernelmodule, cryptsetup, ein paar tools wie fdisk und mkfs.ext2 und die quellen enthält. (enthält natürlich keine proprietären binaries!!!)

Informationen zu luks findet man z.B. in der gentoo wiki:
http://de.gentoo-wiki.com/DM-Crypt

kurze Anleitung:

1. kernelmodule und cryptsetup auf die fritzbox---
dazu gibt es sicher genug anleitungen und ich will mich darüber hier nicht auslassen!

2. benötigte module laden: (reihenfolge beachten!!!)
1. crypto.ko
2. crypto_algapi.ko
3. cryptomgr.ko
4. blkcipher.ko
5. gf128mul.ko (nur für LRW und XTS)
6. dm-mod.ko
7. dm-crypt.ko

dann sollte man sich für eine verschlüsselung entscheiden

beispiel: aes-lrw-benbi

also noch aes_generic.ko und lrw.ko laden

dann kanns los gehen mit cryptsetup:

dazu muss man als erstes eine partition auf seiner HDD entsprechend mit luks formatieren:
(darauf achten das diese nich autmatisch gemountet wurde)

./cryptsetup -c aes-lrw-benbi -s 384 luksFormat /dev/sda1

wenn man die so formatierte cryptodisk dann starten will benutzt man

./cryptsetup luksOpen /dev/sda1 beliebigername

achtung die device nodes werden nicht wie üblich unter /dev/mapper erzeugt sonduern unter /var/mapper da schreibzugriff benötigt ist

dann kan man seine verschlüsselte disk(/var/mapper/beliebigername) mounten, formatiern was auch immer.

stoppen kann man die cryptodisk mit ./cryptsetup remove beliebigername


informiert mich bitte über bugs oder wenn es probleme gibt!!!


Für die Entwickler unter euch:

1.
2.6.13 hat noch keine Unterstützung für die moderneren Verfahren(namentlich LRW und XTS) also habe ich die Quellen der Crypto Api des Kernels 2.6.24 benutzt und entsprechend modifiziert das sie in dem aktuellen avm-kernel tree compilieren/funktionieren.

2.
das devicemapper modul entsprechend modifizieren, da sich in der crypto-api einiges getan hat

3. Cryptsetup hat auch eine kleine modifikation bekommen: neu ist die kommandozeilenoption -f womit man ein verzeichnis angeben kann wo die device-nodes erstellt werden. (ich habe es standartmäßig auf /var/ eingestellt da dort auf der fritzbox rw zugriff ist.


Grüße,

Christian

Benchmarks

hallo minze,

bin leider noch nicht zu benchmarks gekommen,

aber mp3's sind auf jeden kein problem...

und telefonieren ging sogar während der compiler lief noch ohne probleme.
wird halt prozesspriorität festgelegt.

kannst ja einfach mal nen test starten

time dd if=/dev/zero of=test.img bs=1024k count=128

damit schreibts 128 mbyte und gibt dir dann die zeit aus...(nimm fürs erste lieber mal nur 16mbyte oder so...)

bin leider grad unterwegs und hab die fritzbox zuhaus abgeschaltet.

nächste weekend bin ich wieder home,... dann mach ich mal nen benchmark.(so vom gefühl sag ich 500kbyte - 1mbyte/sec mit aes)

grüße, christian

@ cuma

hast du die richtige reihenfolge verwendet und alles der reihe nach geladen?

für aes brauchst du halt crypto und crypto_algapi

wenn aes trotzdem nicht lädt dann poste mal bitte deine firmwareversion und fb-typ

ausserdem mal 'insmod -m'

getestet habe ich blos auf 7170 mit 29.04.49


christian

[EDIT]

les grad erst deine signatur und sehe das du deinen kernel ersetzt hast.

hab nun leider keine ahnung welche veränderungen an diesem vorgenommen wurden.

da müsstest du mir sagen was du an deinem Kernel verändert hast.

[/EDIT]

ich nehm an das du diesen dahnisahne mod benutzt???..

ich werd mir mal die patches von dem geben... vielleicht find ich was...

werd auch mal die firmwareversion von dir ausprobieren...


grüsse

also die poblematik ist vermutlich die folgende:

in dem freetz-kernel ist die crypto-api bereits mit einkompiliert(die alte natürlich)
ist zwar verwunderlich das nur aes probleme macht, aber das sollte nicht weiter stören.

die kernelconfig liegt unter: freetz-trunk/make/linux
für die .49er firmware vermutlich Config.ohio-8mb_26.04.49

dort musst du CONFIG_CRYPTO entfernen.

zur sicherheit kannst du dann ja auch noch die .config in dem kernel-build-verzeichniss checken, hab nur keine zeit jetzte nen build zu starten.

allerdings entspricht das alles eigentlich nicht mehr meinem ansatz die sache ohne jegliche firmwareveränderungen zu realisieren.

alternativ kannst du in der .config die alte crypto-api aktivieren... nur dann ohne lrw und xts.

gruß, christian

die zwei module aus dem freetz tree habe ich auch dabei (sha1 und arc4)

ob nun dein vpn-server ohne veränderung mit der neuen api funktioniert kann ich nicht 100% sagen, aber ich denke es sollte keine probleme geben. (du musst halt vor dem starten des vpn dann crypto, crypto_algapi und sha1 /arc4 laden)

mein tipp: wenn du nur verschlüsseln willst und dir die modi xts und lrw egal sind dann behalte die api von dem freetz tree...
der 2.6.13er kernel unterstützt auch schon aes-cbc-essiv:sha256 und das wiederum ist ansich ausreichend sicher...
um das zu bewerkstelligen musst du eben die entsprechenden module in der .config aktivieren
(aes, sha256, dm-mod, dm-crypt)

grüsse christian

freut mich das das funktioniert....

also normalerweise kann man die crypto-api nicht als modul compilieren... nur fest in den kernel.
meine modifikation --> crypto.ko

die anderen module sind neu in der moderneren cryptoapi.
ich glaube die lassen sich sonst auch nur fest einkompilieren...

der sinn, warum man das nur fest einkompilieren kann ist mir nicht ganz klar.... eine einfache modifikation der initialisierungfunktion macht dies möglich... (__init ---> module_init)

der sinn meiner ganzen bemühungen war es halt die modis lrw und xts zu ermöglichen, da ich solche festplatten benutzte, und eine mod ohne kernel-replacement

die problematik mit dem cryptsetup ist die, das normalerweise die device-nodes in /dev/mapper erzeugt werden.
es gibt eine funktion im libdevmapper mit der man das setzen kann... diese rufst du einfach am anfang von cryptsetup.c auf.
bin leider mal wieder unterwegs, deswegen kann ich dir genaueres erst morgen sagen.
als build-environment hab ich debian-mipsel-etch genommen, da ich sowohl im cross-compile, als auch in meinem uclibc-mipsel-buildroot nur auf errors gestürzt bin.
achja, denk dran nen swap auf der box zu starten(32 meg oder so) sonst hängt der compile irgendwann...

@minze:

übrigens... bin mal zu nem schnellen benchmark gekommen....

aes-lrw-benbi auf usb1.1 macht ~600kbyte pro sekunde schreiben
unverschlüsselt sinds auch nur 1mbyte gewesen...

grüsse, christian

der patch von cryptsetup!

bevor du das compilierst brauchst da aber noch die ein oder andere library..

grüsse, christian