Dies ist eine alte Version des Dokuments!


GnuPG-Card Anleitung

Sogenannte Smart Cards können zur Authentifizierung, Verschlüsselung und Signatur mit unterschiedlichen Diensten und Programmen dienen.

Es gibt zwei unterschiedliche Konzepte:

Während erstere den Quasi-Standard für x509 Zertfikate und eine Public-Key-Infrastructure darstellen scheint die gnupg Variante unter Linux einfacher einzurichten und besser unterstützt zu sein.

Ähnliche Konzpete verfolgen auch

  • der Yubikey - eine Mischung aus USB-smartcard und One-Time-Password Generator
  • und der Cryptostick der Privacy-Foundation.

Ein Überblick über SmartCard, Cryptostick und Yubikey findet sich im Privacy-Handbuch

Unterschiede der verschiedenen Systeme:

System Vorteile Nachteile
Gnupg Card Karten leicher erhältlich und preiswerter. Unterstützung unter Linux einfacher Authentifizierung mit Clients wie Thunderbird etc. nicht so einfach
PKCS#11 De Facto Standard komplizierter in der Einrichtung, Karten teurer?, Beschaffung komplizierter, Kompatibilität nicht immer gegeben

Vor- und Nachteile sind z.B. hier diskutiert worden: http://lists.gnupg.org/pipermail/gnupg-users/2006-February/027936.html

Diese Anleitung beschäftigt sich nur mit der Einrichtung der Gnupg-Card.

Wir benötigen

Beides ist am einfachsten über den Shop von Kernel Concepts zu erhalten. Eine Gnupg-Card erhält auch, wer der Free Software Foundation Europe beitritt.

Als erstes installieren wir die Software. Wichtig: die gnupg-card funktioniert nur mit gnupg Version 2.

apt-get install gnupg2 scdaemon gpgsm pcscd

Wenn der PKCS#11-Support verwendet werden soll evtl. auch:

apt-get install gnupg-pkcs11-scd

In der Anleitung der Free Software Foundation Europe wird beschrieben, wie der Card-Reader so eingerichtet wird, dass das USB-Device die richtigen Rechte und Gruppenzugehörigkeit erhält.

Unter Debian Wheezy war das nicht nötig. Der Card-Reader funktionierte nach der Installation der Software „Out of the Box“.

Das Device des Card-Readers muss die richtigen Dateirechte erhalten, damit die User darauf zugreifen können. Das erfolgt mittels udev und wird hier beschrieben

Als schneller Workaroundzum Testen oder zur Nutzung innerhalb von Live-Systemen (zur sicheren Generierung der Schlüssel) kann das folgendermaßen getan werden

lsusb
Bus 001 Device 008: ID ... Card-Reader ....

damit wissen wir die Bus und Device ID:

ls -l /dev/bus/usb/001/008

als temporärer Workaround:

chmod 666 /dev/bus/usb/001/008

Es gibt grundsätzlich mehrere Möglichkeiten, die Schlüssel für die Karte zu erzeugen

  1. Keypair (Hauptkey) kann direkt auf der Karte erzeugt werden
  2. Ein Keypair wird außerhalb erzeugt werden. Anschließend werden Subkey generiert (für signieren, verschlüsseln und Authentifizieren) und auf die Karte importiert. Diese Variante ist die von der empfohlene und im Folgenden beschriebene.

Das Generieren der Schlüsselpaare findet vorzugsweise auf einem Live-System statt, damit sicher gestellt werden kann, dass die Schlüssel nicht bereits bei der Erstellung von Dritten gelesen werden können. Ist der geheime Schlüssel einmal auf der Karte, kann er, so zumindest die Theorie, diese nicht mehr verlassen. Alle Operationen finden auf der Karte statt. Daher lohnt es sich, bei der Erstellung der Schlüssel wirklich sehr sorgfältig vorzugehen:

  • vertrauensvolle Hardware
  • Live-System möglichst ohne Netzwerkverbindungen

Ein angepasstes Live-System mit aller nötigen Software sowohl zum Erzeugen der Keys als auch für die Verwendung der Gnupg-Karte kann beim Datenkollektiv bestellt werden.

Ihr erhaltet einen Bootbaren USB-Stick mit

  • angepasstem xfce4 Desktop und allen nötigen Crypto-Tools
  • einer zusätzlichen LUKS-verschlüsselten Partition, die z.B. für die Backups der privaten Schlüssel dienen kann.

Hauptschlüssel-Paar generieren:

Ist alles so weit vorbereitet, geht es jetzt an das eigentliche Erstellen der Schlüssel. In einem Terminal werden jeweils die markierten Kommandos ausgeführt.

Als erstes wird der Hauptschlüssel erstellt, der nur zum Signieren der Unterschlüssel dient:

gpg2 --gen-key

Bei der Auswahl:

RSA (sign only)
  • ggf. unbegrenzte Haltbarkeit

Erstellen der Unterschlüssel (Subkeys)

Mit

gpg --list-keys

finden wir unsere neue Key-ID heraus. Diese nutzen wir nun zum Editieren des Schlüssels:

gpg --expert --edit-key KEYIDXYZ

Im Anschluss generieren wir drei Subkeys für folgende Zwecke:

  1. Signieren
  2. Verschlüsseln
  3. Authentifizieren
gpg>  addkey

legt einen neuen Subschlüssel an. Wir müssen jetzt je einen zum Signieren, Verschlüsseln und Authentifizieren anlegen, d.h. die folgende Prozedur wird dreimal wiederholt.

Bei der folgenden Auswahl:

Please select what kind of key you want:
(3) DSA (sign only)
(4) RSA (sign only)
(5) Elgamal (encrypt only)
(6) RSA (encrypt only)
(7) DSA (set your own capabilities)
(8) RSA (set your own capabilities)
Your selection?

nutzen wir „8“ „Set your own capabilities“. Signieren und Verschlüsseln funktioniert zwar auch mit den vorgegebenen, Authentifizieren funktioniert aber nur mit benutzerdefinierten Fähigkeiten.

Jetzt kann mit den angegebenen Buchstaben jeweils eine Fähigkeit zu- oder abgeschaltet werden.

Zuletzt sichert ein

gpg> save

unsere Änderungen.

Im nächsten Schritt kopieren wir unsere Subkeys auf die gnupg-Karte. Hierfür benötigen wir das Passwort für den geheimen Hauptschlüssel und die Admin-Pin für die Karte.

gpg --expert --edit-key KEYIDXYZ

Ein

gpg> toggle

schaltet in die Ansicht der privaten Schlüssel um.

Jetzt markieren wir der Reihe nach unsere Subkeys:

gpg> key 1

und kopieren sie auf die Karte:

gpg> keytocard

Das wiederholen wir jetzt mit Schlüssel 2 u. 3. (Die Schlüssel müssen jeweils wieder entsperrt werden.)

Den öffentlichen Schlüssel (der nicht auf der Karte gespeichert ist) exportieren wir auf ein zugängliches Medium oder zu einem Keyserver. Wir brauchen diesen später.

gpg --export --armor KEYID > public_key.asc
  • Der gesamte Keyring (Unterverzeichnis .gnupg) sollte nach der Prozedur auf ein verschlüsseltes Medium bzw. in einem Container gesichert werden.
  • eine weitere Variante zum Backup von Keys ist paperkey - ein Programm um ausdruckbare Daten zu erhalten und den key auf Papier auszudrucken.

Die Gnupg-Card kann vielfältig genutzt werden:

  • Authentifizieren:
    • Login auf lokalen oder (per ssh) entfernten Servern
    • Signieren und Verschlüsseln von E-Mails und Dateien
    • In Zusammenarbeit mit Passwort-Managern als sichere Möglichkeit, Passwörter zu verwalten.

Die Nutzung der GPG-Funktion funktioniert genau wie gewohnt. Für die Nutzung ist es allerdings noch notwendig, den öffentlichen Schlüssel der beim Erstellen des Schlüsselpaares gewonnen wurde in den jeweiligen Keyring zu kopieren. Auf der Karte selbst sind nur die privaten Schlüssel.

Login in lokalen Linux-Rechner

Die Linux-Pam und die verschiedenen Session-Manager können mit GnuPG-Card umgehen.

Die dort verwendeten Optionen für poldi-ctrl scheinen in der wheezy-Version noch nicht zu existieren. Folgendes Information hilft weiter:

Einrichten des Poldi-Moduls:

Das Packet muss installiert werden:

apt-get install libpam-poldi

Ein

poldi-ctrl -d

testet, ob die Karte erkannt wird.

Mit

poldi-ctrl -s

finden wir die Seriennummer der Karte heraus (gnupg –card-status würde auch funktionieren).

Jetzt müssen wir unter /etc/poldi/localdb/users eine Kartei der User anlegen, für die die Authentifizierung mit der jeweiligen Karte eingerichtet werden soll. Z.B. mit:

echo "`poldi-ctrl -s` USERNAME" | tee -a /etc/poldi/localdb/users

Unter /etc/poldi/localdb/keys/ muss jetzt für jede Karte eine Datei mit der Seriennummer als Dateiname angelegt werden, die den public Key der Karte enthält. Das geht einfach mit:

poldi-ctrl -s > serialno.txt
poldi-ctrl -k | tee -a /etc/poldi/localdb/keys/`cat serialno.txt

Damit sollte Poldi fertig konfiguriert sein.

Nach der grundlegenden Einrichtung der Smartcard, kann das Pam-Poldi-Modul zur /etc/pam.d/common-auth hinzugefügt werden. Alle Authentifikationen, die auf die common-auth zurückgreifen (u.a. xscreensaver, sudo) können dann auch via smartcard authentifizieren. Wenn das Modul am Anfang der common-auth hinzugefügt wird und alle anderen Einträge bleiben, ist die Gnupg Card ein zusätzliches Authentifizierungsmittel. Bitte immer testen, so lange noch eine offene Konsole verfügbar ist, um die Änderungen ggf. zu korrigieren. Sonst sperrt mensch sich leicht aus.

--- a/pam.d/common-auth
+++ b/pam.d/common-auth
@@ -13,6 +13,8 @@
 # pam-auth-update to manage selection of other modules.  See
 # pam-auth-update(8) for details.
 
+# with smartcard
+auth sufficient pam_poldi.so
 # here are the per-package modules (the "Primary" block)
 auth   [success=1 default=ignore]      pam_unix.so nullok_secure
 # here's the fallback if no module succeeds

Nutzung für ssh

ssh über mehrere Server (ForwardAgent)

Damit das funktioniert, muss der ssh-client so konfiguriert werden, dass er „agent-forwarding“ untestützt:

  • /etc/ssh/ssh_config (sytemweit)
  • /home/user/.ssh/config (per user)
Host *
      ForwardAgent yes

Eine ausführliche Beschreibung findet sich hier:

Innerhalb von screen-sessions

Hier steht was dazu:

Aber mit debian-wheezy sollte das out of the box funktinieren.

Auch der x2goclient kann auf die ssh-Authentifizierung über gpg-agent mittels gpg-card zurück greifen. x2goclient muss dazu mit der Option:

x2goclient --pgp-card

gestartet werden.

Allerdings beherrscht der x2goclient kein ssh-agent Forwarding. D.h. innerhalb der x2go-Sitzung kann der lokale gpg-agent für die ssh-Authentifizierung nicht genutzt werden.

Eleganter ist daher die Nutzung des alternativen X2go-Clients: pyhoca-gui.

apt-get install pyhoca-gui python-cups

Dieser beherrscht nicht nur die Authentifizierung via smart-card out of the box - sondern auch ssh-forward-agent.

Praktisch wäre, die Gnupg-Card auch zum entschlüsseln von Luks-Partitionen beim Booten vollverschlüsselter Systeme nutzen zu können.

Ein kleines Howto für Debian Wheezy findet sich unter Luks mit Gnupg Card

Die dort beschriebene Lösung funktioniert offensichtlich nicht mehr. Schuld daran scheint zu sein, dass der über socat gebildete Socket keine Informationen über die Kodierung des zur Verfügung gestellten Files ausgibt, keepassx darauf aber zurück greifen will.

Davon abgesehen, ist die Lösung über pipes nicht unbedingt ideal, weil diese auf einem Multi-User-System nicht wirklich sicher sind.

Ein Kommandozeilen Passwort-Manager, der Passwörter mittels gpg verschlüsselt und daher auch „smart-card kompatibel“ ist: pass (in wheezy-backports)

apt-get install -t wheezy-backports pass

Dieses legt für jeden Passwort-Eintrag eine Datei unterhalb von .password-store an. Die Baumstruktur wird mittels Unterverzeichnissen erzeugt.

Features (Auswahl):

  • git-Integration
  • Mulitline-Passwörter (mit Kommentaren etc.)
  • Baum-Struktur
  • Suchen in Passwörtern und Namen des Eintrags
  • Verschlüsselung der Passwörter für mehrere User-IDs

Mittels git und der gpg-Encryption für mehrere User-Ids ist der Passwort-Manager Multi-User fähig. Für einzelne Unterordner können auch verschiedene gpg-IDs zum Verschlüsseln genutzt werden: Auf diese Art können Zugriffsbeschränkungen gesetzt werden.

Eine Konvertierung aus einer keepassx xml-Export-Datei gelingt mit folgendem Python-Script:

→ howto zu pass

Diese Website verwendet Cookies. Durch die Nutzung der Website stimmen Sie dem Speichern von Cookies auf Ihrem Computer zu. Außerdem bestätigen Sie, dass Sie unsere Datenschutzbestimmungen gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information