Neues HowTo auf Wikiseite

[weizenbier]

Hi Folks,

habe mich mal an einem HowTo probiert.
Thema: Erstellen einer Crypto Partition mit Authentifizierung ueber USB Stick.
http://www.debianforum.de/wiki/CryptoFsMitUsbStick

Wuerde mich ueber jedes Feedback freuen.

Gruss,

Weizenbier

[kain]

N1, Super Howto..

Leicht verständlich und easy.. Aber etwas zu unalgemein. Man muss keinen debian Kernel dazu verwenden. Geht genauso mit selbstgebakenen. Außerdem
solltest du noch einfügen wie man den usb stick mountet und einrichtet.. Haben imo viele Probs. mit.. Aber wie gesagt Super Howto..

MfG kain

[blackm]

Hi weizenbier,

gute Anleitung, bei mir funktioniert das mit dem /dev/random aber nicht :-/ geht das alles nicht auch nur mit gpg?

by, Martin

[weizenbier]

Außerdem solltest du noch einfügen wie man den usb stick mountet und einrichtet..

Ok, werde mich da mal heute abend dransetzen und das USB-Stick einrichten hinzufügen.

@blackm
Also, das mit dem /dev/random Problem ist mir schleierhaft.
Was kommt da für ne Fehlermeldung?
Was meinst du mit "Geht das alles nicht auch nur mit gpg?" ?
GPG verschlüsselt ja "nur" auf Dateibasis. Wir möchten ja aber die ganze Partition
verschlüsseln, um uns das Ent- und Verschlüsseln einzelner Dateien zu ersparen.

Gruß,

Weizenbier

[storm]

Moin,

@weizenbier
ich habs mal zum Testen nachvollzogen, war auch sehr einfach, dank deines HOWTOs. Arbeitest du schon ne Weile damit? Wie ist es denn von der Performance gegenüber dem normalen ext2?

Und ich glaub blackm meint, dass man den Schlüssel doch auch mit gpg selbst erzeugen kann.
Nur dass gpg bei der Key-Erzeugung ein asymmetrisches Verfahren einsetzt(2 Schlüssel) und im HOWTO ein symmetrisches Verfahren(default:CAST5) eingesetzt wird, also nur ein Schlüssel.


ciao, frank

[blackm]

Und ich glaub blackm meint, dass man den Schlüssel doch auch mit gpg selbst erzeugen kann.
Nur dass gpg bei der Key-Erzeugung ein asymmetrisches Verfahren einsetzt(2 Schlüssel) und im HOWTO ein symmetrisches Verfahren(default:CAST5) eingesetzt wird, also nur ein Schlüssel.

Ja, das meinte ich.

Nochmal zu meinem Problem: also es gibt /dev/random bei mir, das scheint aber nicht genug Ausgabe zu liefern (nachdem gpg nach dem Passwort gefragt hat passiert dann immer nix) Das Modul hw_random kann ich nicht laden, da bekomme ich immer

Code: Alles auswählen

FATAL: Error inserting hw_random (/lib/modules/2.6.7/kernel/drivers/char/hw_random.ko): No such device

Mit /dev/null kann ich aber den Schluessel bauen.

by, Martin

[storm]

Nochmal zu meinem Problem: also es gibt /dev/random bei mir, das scheint aber nicht genug Ausgabe zu liefern (nachdem gpg nach dem Passwort gefragt hat passiert dann immer nix) Das Modul hw_random kann ich nicht laden, da bekomme ich immer

Code: Alles auswählen

FATAL: Error inserting hw_random (/lib/modules/2.6.7/kernel/drivers/char/hw_random.ko): No such device

Mit /dev/null kann ich aber den Schluessel bauen.

doch, es funktioniert schon, nur es dauert eine Weile(bei mir gerade knapp 5min). Wenn du nur den ersten Teil des Befehls in ein Datei umlenkst:

Code: Alles auswählen

head -c 2880 > TESTRND

kannst du nach einer Weile schönen Müll in der Datei anschauen. Ich glaub auch, dass das noch zusätzlich von der System-Aktivität abhängt(IIRC).

hw-random ist leider nur für entsprechende Hardware nützlich: $KERNELSRC/drivers/char/hw_random.c

Hardware driver for the Intel/AMD/VIA Random Number Generators (RNG)
(c) Copyright 2003 Red Hat Inc <jgarzik@redhat.com>

derived from

Hardware driver for the AMD 768 Random Number Generator (RNG)
(c) Copyright 2001 Red Hat Inc <alan@redhat.com>

also taugt nur was, wenn du ein entsprechenden Chipsatz hast.
Und ein Schlüssel aus /dev/null ist sicherlich *sehr* schnell! :)

ciao, frank

[storm]

doch, es funktioniert schon, nur es dauert eine Weile(bei mir gerade knapp 5min)

Nachtrag: Mauswackeln und Fensterwechseln beschleunigt die Sache doch erheblich!

ciao, frank

[blackm]

also taugt nur was, wenn du ein entsprechenden Chipsatz hast.
Und ein Schlüssel aus /dev/null ist sicherlich *sehr* schnell!

Ok, auf n iBook werd ich damit dann wohl nicht so viel Erfolg haben....naja. auf den anderen Rechners sollte es ja klappen...

by, Martin

[Incom]

Hi!
Ich wollt nur mal schnell weizenbier loben, das ist das erste How-To mit dem ich fast keine schwierigkeiten hatte (auch wenn ich statt eines usb-sticks eine Diskette benutzen musste).

MfG
Incom

[weizenbier]

Hi Incom und die anderen,

danke für die Blumen.

Also, wer Lust hat kann ja mal seine Probleme mit seinem USB-Stick posten.
Werde bei nächster Gelegenheit diesen Teil im Wiki ausführlicher beschreiben.

IMHO wenn euer Stick sich sonst auch nutzen lässt (mounten, Daten speichern, unmounten)
sollte das Ablegen des Keys darauf auch keine Probleme bereiten.

Ahoi,

Weizenbier

PS:
Incoms Idee ist natürlich auch völlig valide. Die Idee ist ja das Speichern des Keys auf einem physikalisch anderen Medium, um es Angreifern
möglichst schwer zu machen an den Key zu kommen.

[weizenbier]

Okidok,

habe mal die Wikiseite erweitert und das Einrichten des USB-Stick hinzugefuegt.

Spass beim Ausprobieren,

Weizenbier

[Joghurt]

Nochmal zu meinem Problem: also es gibt /dev/random bei mir, das scheint aber nicht genug Ausgabe zu liefern (nachdem gpg nach dem Passwort gefragt hat passiert dann immer nix)

man 4 random

Kurzfassung: /dev/random erzeugt Zufallsdaten aus einem Entropiepool, der durch Tastendrücke, Netzwerk, Mouse, Festplatte etc. erzeugt wird. Wenn nicht genügend Entropie vorhanden ist, um sichere Zufallszahlen zu erzeugen, wird solange gewartet, bis genügend entropie vorhanden ist. /dev/urandom arbeitet genauso, nur benutzt es einen normalen Zufallszahlengeneraten in dem Fall, dass die Entropie zu klein ist.

probier mal od /dev/random und bewege die Maus

Anstatt zu warten hättest du also einfach weiterarbeiten müssen, dann wäre er irgendwann fertig geworden

[simtin]

Hallo,

das ganze hört sich auch für mich recht vielversprechend an, wie ich es mal so gelesen habe, denke ich, müsste ich damit klar kommen.

Aber eine Frage hätte ich noch:
Mir ist durchaus klar, dass es sicherer ist, den GPG-Key auf USB-Stick / Diskette zu speichern. Da aber ja selbst mit GPG-Key Brute-Force angewendet werden müsste, und es Jahre dauern würde, um das zu knacken, sollte es doch auch -- grundsätzlich -- kein allzugroßes Risiko darstellen, den Key einfach auf einer anderen, nicht verschlüsselten Partition der Festplatte zu speichern, oder?

Vielen Dank im Voraus!

[weizenbier]

Hallo,
Da aber ja selbst mit GPG-Key Brute-Force angewendet werden müsste, und es Jahre dauern würde, um das zu knacken, sollte es doch auch -- grundsätzlich -- kein allzugroßes Risiko darstellen, den Key einfach auf einer anderen, nicht verschlüsselten Partition der Festplatte zu speichern, oder?

Also die generelle Idee mit dem USB-Stick ist die physikalische Trennung des
Speicherortes des Crypto-Partitionskeys von der Platte mit der CryptoPartition. Man koennte zwar den Key wie du vorschlaegst
auch auf einer anderen Partition lassen, nur kann so jeder Angreifer, der auf deine Platte kommt, den Key auslesen. Dann kann man ne
Brute-Force Attacke starten, welche bei einem schlechten Passwort auch keine Jahre dauert.

Gruss,

Weizenbier

[Incom]

Mir ist noch etwas eingefallen: Wie siehts eigentlich mit den ganzen Temporären Dateien (Swap etc) aus? Die beste Verschlüsslung der Welt bringt mir ja nichts wenn ich die Dateien noch unabsichtlich irgendwo unverschlüsselt habe.

[DeletedUserReAsG]

Im Linuxmagazin wurde das mal beschrieben:
Mit 'grep swapon /etc/init.d' wird das zu ändernde Script ermittelt, dort wird dann vor der Zeile mit swapon folgendes eingefügt:

Code: Alles auswählen

/bin/dd if=/dev/urandom bs=1 count=16 | losetup -e twofish -k 128 -p 0 /dev/loop1 /dev/hda2
/sbin/mkswap /dev/loop1
/sbin/swapon -a

/dev/hda2 ist hier durch das Swap-Blockdevice des jeweiligen Systems zu ersetzen!
Cipher und Schlüssellänge können entsprechend angepasst werden. Falls loop1 auch schon belegt ist, nimmt man ein anderes freies Loopdevice.

Kurze Erklärung: Das Swapdevice wird ein mit einem 16 Zeichen langen, zufälligen Passwort aus /dev/urandom verschlüsselt, anschließend wird das Loopdevice als Swap gemountet. Das mkswap bei jedem Booten ist notwendig, da sich ja jedesmal der Schlüssel ändert und den außerdem keiner kennt.

/tmp sollte man normal verschlüsseln können und das Schreiben von Coredumps kann man deaktivieren: Mit 'ulimit -a | grep core' lässt sich rausfinden, wie groß die Datei eines Coredumps werden darf, wenn dort 0 steht, wird kein Dump geschrieben. Sollte der Wert größer als 0 sein, schreibt man

Code: Alles auswählen

* soft core 0

in die Datei /etc/security/limits.conf, bzw. entfernt das # davor.

cu
niemand

[kairo]

Es ist nicht nötig das init-Script zu patchen. Laut loop-aes readme reicht folgender Eintrag in der /etc/fstab

Code: Alles auswählen

/dev/hdb6 none swap sw,loop=/dev/loop0,encryption=AES128 0 0

mfg, Kairo

[weizenbier]

Mir ist noch etwas eingefallen: Wie siehts eigentlich mit den ganzen Temporären Dateien (Swap etc) aus? Die beste Verschlüsslung der Welt bringt mir ja nichts wenn ich die Dateien noch unabsichtlich irgendwo unverschlüsselt habe.

Ai, ai captain!!

Befehl ausgefuehrt.

Habe die Wikiseite um eine Beschreibung wie man Swap verschluesselt erweitert.

Gruss,

Weizenbier

[Incom]

In der aktuellen c't ist grad ein interessanter Artikel über hd-Verschlüsslung. (Auch wenn der Linux-Teil etwas knapp geraten ist)

Incom

[Voyager_MP]

gibts ne möglichkeit das crypt script als user laufen zu lassen ?

Ich möchte mich nicht jedesmal erst als root einlogen müssen, bevor es dann zur gpg passwort abfrage kommt.

[Voyager_MP]

habe es jetzt soweit geschafft, mein crypt script:

Code: Alles auswählen

#!/bin/sh -e 

KEY="/usb/gpg/.gnupg/diskkey" # ist auf dem usbstick (autofs) 
MOUNTPOINT="/home/michel/crypt" 

stick () { 
TEST=`cat /proc/bus/usb/devices | grep "NOMAD" | gawk '{print $2}'` 

if [ -z $TEST ]; then 
    TEST="1" 
fi 

if [ $TEST = "Product=NOMAD" ]; then 
        cat $KEY | /sbin/losetup -e AES128 /dev/loop0 /dev/hda7 -p 0 
    else 
        KEY="/var/local/key.gpg" 
        gpg --decrypt $KEY 2> /dev/null | /sbin/losetup -e AES128 /dev/loop0 /dev/hda7 -p 0 
fi 
} 

case "$1" in 
        start) 
        stick 
        /bin/mount $MOUNTPOINT 
        ;; 
        stop) 
        /bin/umount /dev/loop0 
        /sbin/losetup -d /dev/loop0 
        ;; 
esac

Wenn der USB-Stick eingesteckt ist, wird das loop device direkt gemounted und sollte ich den Stick nicht haben, werde ich nach einen gpg key pass gefragt.

Da ich meinen pass recht lang halte, sollte die sicherheit wohl reichen.

Um das script als user ausführen zu können mußte ich
chmod +s /usr/bin/gpg
chmod +s /sbin/losetup

machen, darin seh ich kein risiko, korrigiert mich bitte wenn ich da falsch liege.

[Friesi]

Hab alles nach der Anleitung gemacht, nur das ich anstatt eines USB Sticks eine Diskette nehme, doch wenn ich nun dies hier eingebe

Code: Alles auswählen

gpg --decrypt /floppy/key.gpg | /sbin/losetup -e AES128 /dev/loop0 /dev/hdd1 -p 0

kommt folgender Fehler:

Code: Alles auswählen

gpg: CAST5 encrypted data
gpg: encrypted with 1 passphrase
gpg: WARNING: message was not integrity protected

Was mach ich falsch?

[router]

Aus http://lists.gnupg.org/pipermail/gnupg- ... 14539.html

> "gpg: WARNING: message was not integrity protected"
>
> I was wondering is there anyway to remove this warning other than
> adding the option "no-mdc-warning" to my options file?

Sure, get people to send you integrity protected messages

That warning is to inform you that the message that was sent has no
MDC. If it's a file that you encrypted yourself, you might want to
re-encrypt it with a MDC.

[weizenbier]

Hi router und die anderen,

muss zu meiner Peinlichkeit gestehen, dass ich die Zeile "gpg: WARNING: message was not integrity protected" auch die ganze Zeit hatte und nicht wusste, was damit anzufangen.

Ein einfaches Hinzufuegen der Option "--force-mdc" beim Erstellen des Key-Files schafft aber Abhilfe.

Code: Alles auswählen

 gpg --symmetric --force-mdc -a > key.gpg 

Ahoi,

Weizenbier