zur Übersicht: Linux: meine Software und Konfigurationstipps
08.06.2010
digitale Signatur dieser Webseite von ECCB5814, digitale Signatur dieser Webseite von 7F637E7B
Ein meines Erachtens großes Sicherheitsproblem heutiger GNU/Linux-Systeme ist, dass die Anwendungen üblicherweise alles dürfen, was der User auch darf. Kaum hat sich der Browser irgendwas eingefangen – soll ja vorkommen –, stehen dem Angreifer alle Daten offen. Vertrauliche Informationen (natürlich nicht direkt als solche kenntlich) und Zugangsdaten (an bekannter Stelle). Und auch der Manipulation des Systems sind wenig Grenzen gesetzt.
Ich denke, dass ich bei mir die größten Probleme damit abgedeckt habe, dass meine Browser und mein Chatprogramm kaum Rechte haben. Die dürfen nur in ihrer eigenen Konfiguration rumschreiben (vermutlich noch schlimm genug, wenn man an die Installation von Add-ons denkt) und alles andere nicht mal lesen. Das ist natürlich unbequem, weil alles, was man hoch- oder runterlädt, erst mal über einen "Gatewayordner" gehen muss. Aber man gewöhnt sich dran. Es ist aber leider aufwendig, diese Profile zu erstellen, und auch kein Spaß für wenig computeraffine Leute. Ich verwende (wegen openSUSE) dafür AppArmor (ein Linux Security Module), einen "Kernelwächter", der auch root-Prozesse beschränken kann. Praktischerweise wird AppArmor nicht weiterentwickelt, so dass ich demnächst umlernen darf, wenn Novell auf SELinux umsteigt...
Ein Teil des Problems ist in meinen Augen, dass viele heikle Daten für einen Account zugänglich sind, die nur selten gebraucht werden. Natürlich können sich Schädlinge auf einem Rechner einnisten, aber schützenswerte Daten nur dann verfügbar zu machen, wenn sie benötigt werden, senkt auf jeden Fall das Risiko, vor allem, wenn sie nur selten benötigt werden.
Die folgende Beschreibung bezieht sich auf ein System mit openSUSE 11.2. Auf anderen Systemen mag es Abweichungen im Detail geben, aber auch dort sollte man diese Anleitung ohne große Probleme umsetzen können.
Ich habe diesen Gedanken folgendermaßen implementiert: Ich habe eine verschlüsselte Partition auf einem USB-Stick angelegt. Wenn ich ihn einstecke, wird die Partition automatisch entschlüsselt und eingebunden (nur lesbar). Außerdem wird ein Symlink umgebogen, so dass er nicht mehr auf Dummydaten zeigt. Das funktioniert über udev und LUKS. Ich wollte eine bequeme Lösung. Wer meinen Rechner von außen knackt, kommt sowieso an die Daten ran, deshalb sehe ich kein nennenswertes Risiko darin, dass die Schlüsseldatei in meinem Homeverzeichnis liegt. Ein Angreifer müsste mir den USB-Stick klauen, damit das zu einem Problem wird. Sehr unwahrscheinlich, selbst gemessen am Risiko eines Softwareeinbruchs.
LUKS ermöglicht die Entschlüsselung eines Volumes sowohl mittels einer Passphrase als auch mittels einer Schlüsseldatei. Sinnvollerweise verwendet man für den USB-Stick beides, damit man auch ohne die Schlüsseldatei an die Daten herankommt. Die Datei erlaubt die Automatisierung, erspart einem die Eingabe der (hoffentlich langen und zufälligen...) Passphrase. Diese Operationen muss man typischerweise als root ausführen. Der Benutzer heißt hl. Die Partition auf dem USB-Stick ist /dev/sdb5. Der Mountpunkt ist ~hl/.homeextension, der sinnvollerweise immer verwendete Symlink ist ~hl/homeextension, die Schlüsseldatei ist ~hl/.homeextension.key.
ec:0 01:13:17 root@inno:~ start cmd: # cd ~hl ec:0 01:13:23 root@inno:/home/hl start cmd: # dd if=/dev/random of=.homeextension.key bs=32 count=1 1+0 Datensätze ein 1+0 Datensätze aus 32 Bytes (32 B) kopiert, 0,000279335 s, 115 kB/s Sie haben neue Post in /var/mail/root. ec:0 01:14:45 root@inno:/home/hl start cmd: # chmod 600 .homeextension.key ec:0 01:16:19 root@inno:/home/hl start cmd: # cryptsetup --iter-time 1 luksFormat /dev/sdb5 .homeextension.key WARNING! ======== Daten auf /dev/sdb5 werden unwiderruflich überschrieben. Are you sure? (Type uppercase yes): YES Command successful. ec:0 01:19:56 root@inno:/home/hl start cmd: # cryptsetup luksDump /dev/sdb5 LUKS header information for /dev/sdb5 Version: 1 Cipher name: aes Cipher mode: cbc-essiv:sha256 Hash spec: sha1 Payload offset: 1032 MK bits: 128 MK digest: fc 9a 85 13 57 b1 66 24 52 f4 35 73 3b 7d f2 cd 1f b0 da 93 MK salt: 05 d2 a9 62 f7 18 53 ed d6 5f a1 f9 c6 45 e9 76 5d 91 7e 00 24 25 53 46 c5 ba 77 b0 8e 35 c5 83 MK iterations: 10 UUID: 6e38856c-9a6a-4060-b31c-2cb77e69731f Key Slot 0: ENABLED Iterations: 301 Salt: ca 3a 4c 1b 41 8b 5c 22 d0 08 c2 68 fa 4f d5 dc 72 af 72 9f 4b 01 d7 cf bc 73 62 b1 9a 8b d2 d9 Key material offset: 8 AF stripes: 4000 Key Slot 1: DISABLED Key Slot 2: DISABLED Key Slot 3: DISABLED Key Slot 4: DISABLED Key Slot 5: DISABLED Key Slot 6: DISABLED Key Slot 7: DISABLED ec:0 01:20:18 root@inno:/home/hl start cmd: # cryptsetup --key-file .homeextension.key luksAddKey /dev/sdb5 key slot 0 unlocked. Enter new passphrase for key slot: Verify passphrase: Command successful. ec:0 01:28:51 root@inno:/home/hl start cmd: # cryptsetup --key-file .homeextension.key luksOpen /dev/sdb5 homeextension-hl key slot 0 unlocked. Command successful. ec:0 01:30:36 root@inno:/home/hl start cmd: # dmsetup ls [...] homeextension-hl (253, 9) [...] ec:0 01:30:45 root@inno:/home/hl start cmd: # mke2fs /dev/mapper/homeextension-hl mke2fs 1.41.9 (22-Aug-2009) Dateisystem-Label= OS-Typ: Linux Blockgröße=1024 (log=0) Fragmentgröße=1024 (log=0) 24288 Inodes, 97140 Blöcke 4857 Blöcke (5.00%) reserviert für den Superuser Erster Datenblock=1 Maximale Dateisystem-Blöcke=67371008 12 Blockgruppen 8192 Blöcke pro Gruppe, 8192 Fragmente pro Gruppe 2024 Inodes pro Gruppe Superblock-Sicherungskopien gespeichert in den Blöcken: 8193, 24577, 40961, 57345, 73729 Schreibe Inode-Tabellen: erledigt Schreibe Superblöcke und Dateisystem-Accountinginformationen: erledigt Das Dateisystem wird automatisch nach jeweils 28 Einhäng-Vorgängen bzw. alle 180 Tage überprüft, je nachdem, was zuerst eintritt. Veränderbar mit tune2fs -c oder -t . ec:0 01:31:22 root@inno:/home/hl start cmd: # mkdir .homeextension ec:0 01:31:54 root@inno:/home/hl start cmd: # mount -t ext2 /dev/mapper/homeextension-hl .homeextension ec:0 01:32:58 root@inno:/home/hl start cmd: # ls -ld .homeextension drwxr-xr-x 3 root root 1024 4. Jun 01:32 .homeextension ec:0 01:33:25 root@inno:/home/hl start cmd: # mkdir .homeextension.dummy ec:0 01:33:32 root@inno:/home/hl start cmd: # chown hl: .homeextension .homeextension.dummy ec:0 01:33:43 root@inno:/home/hl start cmd: # chmod 700 .homeextension .homeextension.dummy ec:0 01:34:05 root@inno:/home/hl start cmd: # echo meinPasswort > .homeextension/geheime_datei.txt ec:0 01:41:13 root@inno:/home/hl start cmd: # umount .homeextension ec:0 01:42:05 root@inno:/home/hl start cmd: # cryptsetup luksClose homeextension-hl ec:0 01:42:20 root@inno:/home/hl start cmd: # ln -s .homeextension.dummy homeextension ec:0 01:42:51 root@inno:/home/hl start cmd: # touch homeextension/geheime_datei.txt ec:0 01:43:32 root@inno:/home/hl start cmd: # ls -ld homeextension* .homeextension* drwx------ 2 hl hauke 4096 3. Jun 03:10 .homeextension lrwxrwxrwx 1 hl hauke 19 3. Jun 07:37 homeextension -> .homeextension.dummy drwx------ 2 hl hauke 4096 4. Jun 01:43 .homeextension.dummy -rw------- 1 hl hauke 32 3. Jun 01:35 .homeextension.key ec:0 01:44:09 root@inno:/home/hl start cmd: #
Vielleicht ein bisschen viel, aber etwa so sieht es in der Shell aus, die ich – man ahnt es schon – in Schwarz mit grüner Schrift bevorzuge. Ich habe übrigens auch eine Seite, die sich mit der Konfiguration des Shell-Prompts befasst. Aber der Reihe nach:
cd ~hl
Wechsel ins Homeverzeichnis des Benutzers.
dd if=/dev/random of=.homeextension.key bs=32 count=1
32 Byte (256 Bit) Zufallsdaten werden in eine Datei geschrieben, die dann als Schlüsseldatei dient. Da LUKS standardmäßig sogar "nur"128 Bit zur Verschlüsselung nutzt, würden schon 16 Byte ausreichen.
chmod 600 .homeextension.key
Zugriff anderer Benutzer auf due Schlüsseldatei unterbinden.
cryptsetup --iter-time 1 luksFormat /dev/sdb5 .homeextension.key
Das LUKS-Volume wird erzeugt. Die Option --iter-time 1 sorgt dafür, dass nicht sinnlos Zeit vertrödelt wird, wenn das Volume mit der Schlüsseldatei geöffnet wird. Die ist sicher (lang) genug.
cryptsetup luksDump /dev/sdb5
Mal schauen, was wir jetzt haben. Acht Schlüssel (jeweils Passphrase oder Datei) sind möglich, einer ist jetzt belegt.
cryptsetup --key-file .homeextension.key luksAddKey /dev/sdb5
Jetzt die Passphrase als zweiten Schlüssel hinzufügen. Auf diese Weise kann man die Passphrase später "ändern": Mit demselben Kommando noch eine hinzufügen und dann die alte löschen (siehe man cryptsetup).
cryptsetup --key-file .homeextension.key luksOpen /dev/sdb5 homeextension-hl
Das Volume entschlüsseln. Es wird ein neues block device erzeugt (/dev/mapper/homeextension-hl), das den unverschlüsselten Inhalt zeigt. Solange dieses existiert, kann man auf die entschlüsselten Daten zugreifen (was in diesem Szenario nicht so wichtig ist), auch wenn das Laufwerk nicht gemountet ist!
dmsetup ls
Voila, da ist es. Die Nummern in Klammern sind die major number und die minor number. Über diese Nummernkombination identifiziert der Kernel Gerätetypen (die Namen sind dem Kernel egal).
mke2fs /dev/mapper/homeextension-hl
Dateisystem erzeugen. Wenn man ein Journal (ext3) haben will, braucht man mke2fs -j .... In meinem Fall (100 MiB Platz) erschien mir das aber unabgemessen.
mkdir .homeextension
Mountpunkt erzeugen.
mount -t ext2 /dev/mapper/homeextension-hl .homeextension
Volume mounten.
ls -ld .homeextension
Zugriffsrechte ansehen. Das Verzeichnis gehört nicht dem User, da wir ja gerade root sind. Außerdem sind die Standardrechte zu umfangreich.
mkdir .homeextension.dummy
Ein Verzeichnis erzeugen, das wir später noch brauchen.
chown hl: .homeextension .homeextension.dummy
Besitzer beider Verzeichnisse ändern (im ersten Fall ist es nicht das Verzeichnis im Homeverzeichnis, sondern das gemountete Volume!).
chmod 700 .homeextension .homeextension.dummy
Zugriffsrechte beschränken.
echo meinPasswort > .homeextension/geheime_datei.txt
Eine kleine Testdatei erzeugen.
umount .homeextension
Das gemountete Volume aushängen.
cryptsetup luksClose homeextension-hl
Die Entschlüsselung beenden.
ln -s .homeextension.dummy homeextension
Der symbolische Link homeextension.switch zeigt entweder auf das verschlüsselte Volume (wenn es gemountet ist) oder auf ein Dummyverzeichnis. In diesem Dummyverzeichnis können die Verzeichnisstruktur und die Dateien (als leere) nachgebildet werden, um Fehlermeldungen von Programmen zu vermeiden, wenn der USB-Stick nicht eingesteckt ist.
touch homeextension/geheime_datei.txt
Als Pendant zur Testdatei eine leere Datei im Dummyverzeichnis erzeugen, aber über den Symlink. Man sieht nun immer eine Datei ~hl/homeextension/geheime_datei.txt, die entweder leer ist (die Version im Homeverzeichnis) oder den schützenswerten Inhalt hat (die Version auf dem Stick).
ls -ld homeextension* .homeextension*
Alle relevanten Dateien und Verzeichnisse ansehen.
Warnung: Die Verwendung des Symlinks und eines Dummy-Verzeichnisses mag sinnvoll sein, allerdings muss man dann natürlich beim Beschreiben des verschlüsselten Laufwerks immer darauf achten, dass es auch wirklich aktiv ist und man nicht versehentlich wichtige Daten ins lokale Dummy-Verzeichnis schreibt!
Wenn man dieses Risiko vermeiden möchte, kann man das Dummy-Verzeichnis auch weglassen. Dann sollte der Mountpunkt schreibgeschützt werden (chmod 400 ~/.homeextension), ein fester Link angelegt werden (ln -s .homeextension homeextension) und sollte man im udev-Script die beiden /bin/ln
-Zeilen auskommentieren (d.h. ein #
voranstellen). Ausprobieren nicht vergessen. Alternativ kann man natürlich auch das Dummy-Verzeichnis schreibschützen (chmod 500 ~/.homeextension.dummy).
Zwei Dateien müssen heruntergeladen werden, der Einfachheit halber ins Homeverzeichnis des Benutzers, die udev-Regeldatei (digitale Signatur von ECCB5814, digitale Signatur von 7F637E7B) und das zugehörige Script (digitale Signatur von ECCB5814, digitale Signatur von 7F637E7B).
Jetzt ist noch dafür zu sorgen, dass der USB-Stick automatisch eingebunden wird. Dafür sind folgende Schritte erforderlich:
Den Stick als den richtigen erkennen.
LUKS-Volume entschlüsseln.
Luks-Volume mounten.
Symlink anpassen.
Und natürlich das umgekehrte Programm beim Entfernen des Sticks. In meinem Fall gehe ich davon aus, dass der Stick nur selten beschrieben wird, deshalb mounte ich ihn schreibgeschützt. Das hat den Vorteil, dass ich ihn stressfrei einfach abziehen kann.
Um den Stick zu erkennen, nimmt man am einfachsten seine Seriennummer und Hersteller-ID.
start cmd: # udevadm info --query=property --name=sdb5 [...] DEVNAME=/dev/sdb5 DEVTYPE=partition [...] ID_VENDOR_ID=1976 [...] ID_SERIAL_SHORT=1108170061426006 [...] ec:0 02:23:06 root@inno:~ start cmd: # l homeextension-script 85-homeextension.rules -rw-r--r-- 1 root root 344 5. Jun 02:56 85-homeextension.rules -rw-r--r-- 1 root root 1,2K 5. Jun 02:56 homeextension-script # jetzt müssen die beiden Dateien erst mal angepasst werden ec:0 02:57:42 root@inno:/home/hl start cmd: # chmod u+x homeextension-script ec:0 02:57:56 root@inno:/home/hl start cmd: # mv homeextension-script /etc/udev/scripts/ ec:0 03:03:01 root@inno:/home/hl start cmd: # mv 85-homeextension.rules /etc/udev/rules.d/ ec:0 03:03:16 root@inno:/home/hl start cmd: #
85-homeextension.rules sieht so aus:
ACTION=="add", KERNEL=="sd*5", ATTRS{idVendor}=="1976", ATTRS{serial}=="1108170061426006", SYMLINK+="homeextension-hl",
RUN="/etc/udev/scripts/homeextension-script $name add hl"
ACTION=="remove", KERNEL=="sd*5", ENV{ID_VENDOR_ID}=="1976", ENV{ID_SERIAL_SHORT}=="1108170061426006",
RUN="/etc/udev/scripts/homeextension-script $name remove hl"
Achtung: Beide Regeln müssen in jeweils nur einer Zeile stehen! Ich habe hier der Übersichtlichkeit halber vor RUN
einen Zeilenumbruch eingefügt. In dieser Datei muss nach dem Download allerlei angepasst werden:
sd*5
muss ggf. an die Nummer der Partition auf dem Stick angepasst werden.
1976
muss typischerweise an den Wert von ID_VENDOR_ID aus der udevadm-Ausgabe angepasst werden.
1108170061426006
muss auf jeden Fall an den Wert von ID_SERIAL_SHORT aus der udevadm-Ausgabe angepasst werden.
Das hl
in SYMLINK und RUN sollte sinnvollerweise an den jeweiligen Benutzernamen angepasst werden. Jeder Benutzer, der eine solche Funktion nutzt, braucht diese zwei Zeilen in einer passenden Variante.
Das Script kann unverändert übernommen werden, wenn jeder User nur einen USB-Stick für diesen Zweck nutzt bzw. mehrere abwechselnd an derselben Stelle gemountet werden sollen. Das Script ist dafür vorbereitet, für einzelne User leicht abweichende Einstellungen verwenden zu können.
Ein allgemeiner Hinweis: Das ist mein erstes udev-Experiment. Die Wahrscheinlichkeit ist hoch, dass man diese Regeln brillianter formulieren kann, aber sie scheinen zu funktionieren.
Nach diesen Schritten sollte das LUKS-Volume beim Anstecken des Sticks automatisch entschlüsselt und gemountet werden. Beim Abziehen sollte es ausgehängt und geschlossen werden.
Problematisch mag sein, dass die Partition nur lesbar eingehängt wird, man sie aber ab und zu beschreiben muss. Das lässt sich offenbar nur mit root-Rechten vernünftig machen. Es bietet sich also an, ein kleines Script zu schreiben, das das eingehängte Volume zwischen rw und ro umschaltet und per sudo aufgerufen wird. Das reiche ich vermutlich demnächst nach. Zur Erinnerung, das geht so (mit root-Rechten):
ec:0 01:16:23 root@inno:/home/hl start cmd: # grep /dev/mapper/homeextension-hl /proc/mounts /dev/mapper/homeextension-hl /crypto/home/hl/.homeextension ext2 ro,relatime,errors=continue 0 0 ec:0 01:16:57 root@inno:/home/hl start cmd: # mount -o remount,rw /dev/mapper/homeextension-hl ec:0 01:17:41 root@inno:/home/hl start cmd: # grep /dev/mapper/homeextension-hl /proc/mounts /dev/mapper/homeextension-hl /crypto/home/hl/.homeextension ext2 rw,relatime,errors=continue 0 0 ec:0 01:17:43 root@inno:/home/hl start cmd: # mount -o remount,ro /dev/mapper/homeextension-hl ec:0 01:17:50 root@inno:/home/hl start cmd: # grep /dev/mapper/homeextension-hl /proc/mounts /dev/mapper/homeextension-hl /crypto/home/hl/.homeextension ext2 ro,relatime,errors=continue 0 0 ec:0 01:17:52 root@inno:/home/hl start cmd: #
In /proc/mounts zeigt der Kernel an, ob ein Volume rw oder ro gemountet ist.
Private PGP-Schlüssel sind schon ein kostbares Gut. Idealerweise verwahrt man sie nur auf Smartcards und in sicheren (Offline-)Backups. Aber wer kann das schon?
Die einzelnen Teile eines Schlüssels sind zudem nicht gleich wichtig. Den größten Schaden kann man mit den Hauptschlüsseln anrichten, weil man damit neue Schlüssel (sowohl Unterschlüssel als auch Schlüssel anderer) signieren kann. Auch wenn man den Signaturschlüssel nicht hat: Man macht sich einfach einen. Wenn man zu einem Man-In-The-Middle-Angriff in der Lage ist, muss man dem Absender nur einen aktualisierten Schlüssel mit einem neuen Verschlüsselungs-Unterschlüssel unterschieben. Aufwendiger als die Möglichkeit des Mitlesens, aber dafür ist man nicht raus, sobald der aktuelle Verschlüsselungs-Unterschlüssel des Empfängers ungültig wird.
(Unter-)Schlüssel für Signaturen, Entschlüsselungen und (sofern verwendet) Authentisierungen muss man immer im direkten Zugriff (inklusive Smartcard) haben, aber Zertifizierungsschlüssel braucht man üblicherweise nur selten. Wie oft erzeugt man neue Unterschlüssel oder signiert Schlüssel anderer?
Aus diesem Umstand heraus schlage ich vor, die Hauptschlüssel nicht auf dem normalen Arbeitsrechner zu speichern, sondern extern. Wenn man keine Smartcard hat, dann tut es auch ein USB-Stick; vor allem über den oben vorgeschlagenen Mechanismus. Idealerweise macht man das gleich bei der Erzeugung eines Schlüssels, aber auch später ist das möglich. Erreicht wird das Ziel über die Verwendung unterschiedlicher keyring-Dateien. Man kann gpg beim Aufruf per Parameter die zu verwendenden Dateien übergeben. Benötigt wird zumindest eine für private und eine für öffentliche Schlüssel. Mehrere gleichzeitige sind möglich. Man erzeugt also eine geschützte Datei secring.gpg mit allen Schlüsseln und importiert in die Standarddatei (~/.gnupg/secring.gpg) nur die Unterschlüssel. Der Einfachheit halber kann man sich dann noch ein Alias erzeugen. Ich demonstriere beide Varianten (bestehender Schlüssel und neuer Schlüssel). Als Pfad für die geschützte Schlüsseldatei nehme ich ~/homeextension/.gnupg.secring.gpg.
ec:0 21:51:20 hl@inno:~ start cmd:> mkdir homeextension/.gnupg ec:0 21:51:37 hl@inno:~ start cmd:> gpg --list-secret-key eccb5814 Schlüsselbund: /home/hl/.gnupg/secring.gpg ------------------------------------------- sec 1024D/0xECCB5814 2005-09-05 uid Hauke Laging <hauke@laging.de> ssb 2048g/0xE623EF88 2005-09-05 [verfällt: 2010-04-03] ssb 2048R/0x51B279FA 2010-03-04 [verfällt: 2013-03-03] ssb 2048R/0x3A403251 2010-03-04 [verfällt: 2013-03-03] ssb 2048R/0x2282921E 2010-03-08 [verfällt: 2013-03-07] ec:0 21:53:52 hl@inno:~ start cmd:> gpg --armor --export-secret-key eccb5814 > homeextension/.gnupg/0xECCB5814.sec.asc ec:0 21:57:30 hl@inno:~ start cmd:> gpg --armor --export-secret-subkey eccb5814 > homeextension/.gnupg/0xECCB5814.ssk.asc ec:0 22:14:12 hl@inno:~ start cmd:> gpg --delete-secret-key eccb5814 gpg (GnuPG) 2.0.15; Copyright (C) 2009 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. sec 1024D/0xECCB5814 2005-09-05 Hauke Laging <hauke@laging.de> Diesen Schlüssel aus dem Schlüsselbund löschen? (j/N) j Dies ist ein privater Schlüssel! - Wirklich löschen? (j/N) j ec:0 22:16:57 hl@inno:~ start cmd:> gpg --list-secret-key eccb5814 gpg: error reading key: Kein geheimer Schlüssel ec:2 22:17:04 hl@inno:~ start cmd:> gpg --list-key eccb5814 Schlüsselbund: /home/hl/.gnupg/pubring.gpg ------------------------------------------- pub 1024D/0xECCB5814 2005-09-05 uid Hauke Laging <hauke@laging.de> sub 2048R/0x51B279FA 2010-03-04 [verfällt: 2013-03-03] sub 2048R/0x3A403251 2010-03-04 [verfällt: 2013-03-03] sub 2048R/0x2282921E 2010-03-08 [verfällt: 2013-03-07] ec:0 22:17:10 hl@inno:~ start cmd:> gpg --import homeextension/.gnupg/0xECCB5814.ssk.asc gpg: Schlüssel 0xECCB5814: geheimer Schlüssel importiert gpg: Schlüssel 0xECCB5814: "Hauke Laging <hauke@laging.de>" nicht geändert gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1 gpg: unverändert: 1 gpg: gelesene geheime Schlüssel: 1 gpg: geheime Schlüssel importiert: 1 ec:0 22:19:09 hl@inno:~ start cmd:> gpg --list-secret-key eccb5814 Schlüsselbund: /home/hl/.gnupg/secring.gpg ------------------------------------------- sec# 1024D/0xECCB5814 2005-09-05 uid Hauke Laging <hauke@laging.de> ssb 2048g/0xE623EF88 2005-09-05 [verfällt: 2010-04-03] ssb 2048R/0x51B279FA 2010-03-04 [verfällt: 2013-03-03] ssb 2048R/0x3A403251 2010-03-04 [verfällt: 2013-03-03] ssb 2048R/0x2282921E 2010-03-08 [verfällt: 2013-03-07] ec:0 22:19:13 hl@inno:~ start cmd:> gpg --no-default-keyring --secret-keyring ~/homeextension/.gnupg/secring.gpg --list-secret-key eccb5814 gpg: Schlüsselbund `/home/hl/homeextension/.gnupg/secring.gpg' erstellt gpg: error reading key: Kein geheimer Schlüssel ec:2 22:20:35 hl@inno:~ start cmd:> gpg --no-default-keyring --secret-keyring ~/homeextension/.gnupg/secring.gpg --import homeextension/.gnupg/0xECCB5814.sec.asc gpg: Schlüssel 0xECCB5814: geheimer Schlüssel importiert gpg: Schlüssel 0xECCB5814: "Hauke Laging <hauke@laging.de>" nicht geändert gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1 gpg: unverändert: 1 gpg: gelesene geheime Schlüssel: 1 gpg: geheime Schlüssel importiert: 1 ec:0 22:20:56 hl@inno:~ start cmd:> gpg --no-default-keyring --secret-keyring ~/homeextension/.gnupg/secring.gpg --list-secret-key eccb5814 Schlüsselbund: /home/hl/homeextension/.gnupg/secring.gpg --------------------------------------------------------- sec 1024D/0xECCB5814 2005-09-05 uid Hauke Laging <hauke@laging.de> ssb 2048g/0xE623EF88 2005-09-05 [verfällt: 2010-04-03] ssb 2048R/0x51B279FA 2010-03-04 [verfällt: 2013-03-03] ssb 2048R/0x3A403251 2010-03-04 [verfällt: 2013-03-03] ssb 2048R/0x2282921E 2010-03-08 [verfällt: 2013-03-07] ec:0 22:21:02 hl@inno:~ start cmd:> alias gpg-cert-with-eccb5814='gpg --no-default-keyring --secret-keyring ~/homeextension/.gnupg/secring.gpg --edit-key' ec:0 22:26:43 hl@inno:~ start cmd:>
mkdir homeextension/.gnupg
Verzeichnis für den geschützen keyring anlegen.
gpg --list-secret-key eccb5814
Status quo angucken. Wichtig ist das sec
. Es steht kein #
dahinter; das bedeutet, dass der geheime Schlüssel wirklich verfügbar ist.
gpg --armor --export-secret-key eccb5814 > homeextension/.gnupg/0xECCB5814.sec.asc
Alle geheimen Schlüssel in eine Datei exportieren (wenn diese Datei nicht auf dem USB-Stick liegt, sondern auf dem Rechner, dann sollte sie anschließend gelöscht (idealerweise mit z.B. wipe überschrieben) werden.
gpg --armor --export-secret-subkey eccb5814 > homeextension/.gnupg/0xECCB5814.ssk.asc
Nur die Unterschlüssel exportieren. Hinweis: Diese Datei kann nur von neueren gpg-Versionen (ich weiß leider nicht, ab welcher) importiert werden und wohl nicht von anderen OpenPGP-Programmen.
gpg --delete-secret-key eccb5814
Alle geheimen Schlüssel im normalen keyring löschen.
gpg --list-secret-key eccb5814
Nachgucken.
gpg --list-key eccb5814
Öffentliche Schlüssel sind noch da.
gpg --import homeextension/.gnupg/0xECCB5814.ssk.asc
Die geheimen Unterschlüssel (ohne den Hauptschlüssel) in den normalen keyring importieren.
gpg --list-secret-key eccb5814
Da sind sie. Das sec#
zeigt an, dass der Hauptschlüssel nicht zur Verfügung steht. ssb> würde übrigens anzeigen, dass der Unterschlüssel auf einer Smartcard ist.
gpg --no-default-keyring --secret-keyring ~/homeextension/.gnupg/secring.gpg --list-secret-key eccb5814
Wenn nur der neue (noch leere) keyring verwendet wird, ist der geheime Schlüssel nicht bekannt.
gpg --no-default-keyring --secret-keyring ~/homeextension/.gnupg/secring.gpg --import homeextension/.gnupg/0xECCB5814.sec.asc
Alle geheimen Schlüssel in den geschützten keyring importieren.
gpg --no-default-keyring --secret-keyring ~/homeextension/.gnupg/secring.gpg --list-secret-key eccb5814
Und da isser.
alias gpg-cert-with-eccb5814='gpg --no-default-keyring --secret-keyring ~/homeextension/.gnupg/secring.gpg --edit-key'
So eine Aliasdefinition sollte dann in die ~/.alias. Mit gpg-cert-with-eccb5814 12345678 kann man dann Schlüssel bearbeiten.
ec:0 22:26:43 hl@inno:~
start cmd:> gpg --no-default-keyring --secret-keyring ~/homeextension/.gnupg/secring.gpg --expert --gen-key
gpg (GnuPG) 2.0.15; Copyright (C) 2009 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Bitte wählen Sie, welche Art von Schlüssel Sie möchten:
(1) RSA und RSA (voreingestellt)
(2) DSA und Elgamal
(3) DSA (nur signieren/beglaubigen)
(4) RSA (nur signieren/beglaubigen)
(7) DSA (Leistungsfähigkeit selber einstellbar)
(8) RSA (Leistungsfähigkeit selber einstellbar)
Ihre Auswahl? 8
Mögliche Vorgänge eines RSA-Schlüssels: Signieren Zertif. Verschl. Authentisierung
Derzeit erlaubte Vorgänge: Signieren Zertif. Verschl.
(U) Umschalten der Signaturfähigkeit
(V) Umschalten der Verschlüsselungsfähigkeit
(A) Umschalten der Authentisierungsfähigkeit
(Q) Beenden
Ihre Auswahl? u
Mögliche Vorgänge eines RSA-Schlüssels: Signieren Zertif. Verschl. Authentisierung
Derzeit erlaubte Vorgänge: Zertif. Verschl.
(U) Umschalten der Signaturfähigkeit
(V) Umschalten der Verschlüsselungsfähigkeit
(A) Umschalten der Authentisierungsfähigkeit
(Q) Beenden
Ihre Auswahl? v
Mögliche Vorgänge eines RSA-Schlüssels: Signieren Zertif. Verschl. Authentisierung
Derzeit erlaubte Vorgänge: Zertif.
(U) Umschalten der Signaturfähigkeit
(V) Umschalten der Verschlüsselungsfähigkeit
(A) Umschalten der Authentisierungsfähigkeit
(Q) Beenden
Ihre Auswahl? q
RSA-Schlüssel können zwischen 1024 und 4096 Bit lang sein.
Welche Schlüssellänge wünschen Sie? (2048) 1024
Die verlangte Schlüssellänge beträgt 1024 Bit
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
0 = Schlüssel verfällt nie
<n> = Schlüssel verfällt nach n Tagen
<n>w = Schlüssel verfällt nach n Wochen
<n>m = Schlüssel verfällt nach n Monaten
<n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0)
Schlüssel verfällt nie
Ist dies richtig? (j/N) j
GnuPG erstellt eine User-ID um Ihren Schlüssel identifizierbar zu machen.
Ihr Name ("Vorname Nachname"): Test Schlüssel
Email-Adresse: test@key.invalid
Kommentar:
Sie benutzen den Zeichensatz `utf-8'
Sie haben diese User-ID gewählt:
"Test Schlüssel <test@key.invalid>"
Ändern: (N)ame, (K)ommentar, (E)-Mail oder (F)ertig/(A)bbrechen? F
Sie benötigen eine Passphrase, um den geheimen Schlüssel zu schützen.
Wir müssen eine ganze Menge Zufallswerte erzeugen. Sie können dies
unterstützen, indem Sie z.B. in einem anderen Fenster/Konsole irgendetwas
tippen, die Maus verwenden oder irgendwelche anderen Programme benutzen.
gpg: Schlüssel 0xB6A4593E ist als uneingeschränkt vertrauenswürdig gekennzeichnet
Öffentlichen und geheimen Schlüssel erzeugt und signiert.
gpg: "Trust-DB" wird überprüft
gpg: 3 marginal-needed, 1 complete-needed, PGP Vertrauensmodell
gpg: Tiefe: 0 gültig: 11 signiert: 5 Vertrauen: 0-, 0q, 0n, 0m, 0f, 11u
gpg: Tiefe: 1 gültig: 5 signiert: 15 Vertrauen: 1-, 0q, 2n, 2m, 0f, 0u
gpg: nächste "Trust-DB"-Pflichtüberprüfung am 2011-02-25
pub 1024R/0xB6A4593E 2010-06-07
Schl.-Fingerabdruck = 9C1D F374 2D6D 8DF8 F8C3 82F5 18F8 C397 B6A4 593E
uid Test Schlüssel <test@key.invalid>
ec:0 23:13:30 hl@inno:~
start cmd:> gpg --list-key B6A4593E
Schlüsselbund: /home/hl/.gnupg/pubring.gpg
-------------------------------------------
pub 1024R/0xB6A4593E 2010-06-07
uid Test Schlüssel <test@key.invalid>
ec:0 23:15:23 hl@inno:~
start cmd:> gpg --list-secret-key B6A4593E
gpg: error reading key: Kein geheimer Schlüssel
ec:2 23:15:30 hl@inno:~
start cmd:> gpg --no-default-keyring --secret-keyring ~/homeextension/.gnupg/secring.gpg --expert --edit-key B6A4593E
gpg (GnuPG) 2.0.15; Copyright (C) 2009 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Geheimer Schlüssel ist vorhanden.
pub 1024R/0xB6A4593E erzeugt: 2010-06-07 verfällt: niemals Aufruf: C
Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
[ uneing.] (1). Test Schlüssel <test@key.invalid>
gpg> addkey
Schlüssel ist geschützt.
Sie benötigen eine Passphrase, um den geheimen Schlüssel zu entsperren.
Benutzer: "Test Schlüssel <test@key.invalid>"
1024-Bit RSA Schlüssel, ID 0xB6A4593E, erzeugt 2010-06-07
Bitte wählen Sie, welche Art von Schlüssel Sie möchten:
(3) DSA (nur signieren/beglaubigen)
(4) RSA (nur signieren/beglaubigen)
(5) Elgamal (nur verschlüsseln)
(6) RSA (nur verschlüsseln)
(7) DSA (Leistungsfähigkeit selber einstellbar)
(8) RSA (Leistungsfähigkeit selber einstellbar)
Ihre Auswahl? 8
Mögliche Vorgänge eines RSA-Schlüssels: Signieren Verschl. Authentisierung
Derzeit erlaubte Vorgänge: Signieren Verschl.
(U) Umschalten der Signaturfähigkeit
(V) Umschalten der Verschlüsselungsfähigkeit
(A) Umschalten der Authentisierungsfähigkeit
(Q) Beenden
Ihre Auswahl? u
Mögliche Vorgänge eines RSA-Schlüssels: Signieren Verschl. Authentisierung
Derzeit erlaubte Vorgänge: Verschl.
(U) Umschalten der Signaturfähigkeit
(V) Umschalten der Verschlüsselungsfähigkeit
(A) Umschalten der Authentisierungsfähigkeit
(Q) Beenden
Ihre Auswahl? q
RSA-Schlüssel können zwischen 1024 und 4096 Bit lang sein.
Welche Schlüssellänge wünschen Sie? (2048) 1024
Die verlangte Schlüssellänge beträgt 1024 Bit
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
0 = Schlüssel verfällt nie
<n> = Schlüssel verfällt nach n Tagen
<n>w = Schlüssel verfällt nach n Wochen
<n>m = Schlüssel verfällt nach n Monaten
<n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0)
Schlüssel verfällt nie
Ist dies richtig? (j/N) j
Wirklich erzeugen? (j/N) j
Wir müssen eine ganze Menge Zufallswerte erzeugen. Sie können dies
unterstützen, indem Sie z.B. in einem anderen Fenster/Konsole irgendetwas
tippen, die Maus verwenden oder irgendwelche anderen Programme benutzen.
pub 1024R/0xB6A4593E erzeugt: 2010-06-07 verfällt: niemals Aufruf: C
Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub 1024R/0xDA487B48 erzeugt: 2010-06-07 verfällt: niemals Aufruf: E
[ uneing.] (1). Test Schlüssel <test@key.invalid>
gpg> save
ec:0 23:18:18 hl@inno:~
start cmd:> gpg --no-default-keyring --secret-keyring ~/homeextension/.gnupg/secring.gpg --armor \
--export-secret-subkey B6A4593E > homeextension/.gnupg/0xB6A4593E.ssk.asc
ec:0 23:19:26 hl@inno:~
start cmd:> gpg --import homeextension/.gnupg/0xB6A4593E.ssk.asc
gpg: Schlüssel 0xB6A4593E: geheimer Schlüssel importiert
gpg: Schlüssel 0xB6A4593E: "Test Schlüssel <test@key.invalid>" nicht geändert
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg: unverändert: 1
gpg: gelesene geheime Schlüssel: 1
gpg: geheime Schlüssel importiert: 1
ec:0 23:19:45 hl@inno:~
start cmd:> gpg --list-secret-key B6A4593E
Schlüsselbund: /home/hl/.gnupg/secring.gpg
-------------------------------------------
sec# 1024R/0xB6A4593E 2010-06-07
uid Test Schlüssel <test@key.invalid>
ssb 1024R/0xDA487B48 2010-06-07
ec:0 23:19:51 hl@inno:~
start cmd:>
gpg --no-default-keyring --secret-keyring ~/homeextension/.gnupg/secring.gpg --expert --gen-key
Bei den Einstellungen ist nur wichtig, dass der Hauptschlüssel nur zertifizieren (Schlüssel signieren) kann. Ich habe nur 1024 Bit gewählt, damit die Erzeugung schneller geht. Richtige Schlüssel sollten 2048 haben.
gpg --list-key B6A4593E
Öffentlicher Schlüssel ist im normalen keyring.
gpg --list-secret-key B6A4593E
Der geheime nicht.
gpg --no-default-keyring --secret-keyring ~/homeextension/.gnupg/secring.gpg --expert --edit-key B6A4593E
Unterschlüssel erzeugen. Da es ums Prinzip geht, habe ich nur einen erzeugt. Man bräuchte noch die für Signatur und Authentisierung bzw. müsste einem Unterschlüssel mehrere Fähigkeiten geben.
gpg --no-default-keyring --secret-keyring ~/homeextension/.gnupg/secring.gpg --armor \
--export-secret-subkey B6A4593E > homeextension/.gnupg/0xB6A4593E.ssk.asc
Nur den geheimen Unterschlüssel exportieren. Der Übersichtlichkeit halber mit \ umgebrochen.
gpg --import homeextension/.gnupg/0xB6A4593E.ssk.asc
Geheimen Unterschlüssel in den normalen keyring importieren.
gpg --list-secret-key B6A4593E
Und auch hier: sec#
statt sec
.