Nitrokey Start in der Praxis unter CentOS 7.x

Dies ist eine alte Version des Dokuments!

Bild: Nitrokey Start USB-Stick In diesem Kapitel befassen wir uns eingehend mit dem Nitrokey Start (Daten-/Infoblatt) unter CentOS 7.x. Weitere Informationen zum Nitrokey-Stick findet findet man auch hier bzw. im Support Forum.

Mit Hilfe von asymmetrischen Schlüsselmaterials (PGP und S/MIME) können eMails sowie Dateien und ganze Festplatten verschlüsselt und natürlich auch wieder entschlüsselt werden. Hierzu verwenden wir den Nitrokey Start welcher hier für einen überschaubaren Betrag von ngerade mal 29€ erstanden werden kann. In dem folgenden Beitrag gehen wir auf die Besonderheiten bei der Verwendung unter CentOS 7.x ein.

Informationen über den Stick können wir mit Hilfe des Befehls usb-devices aus dem RPM-Paket usbutils dem System abverlangen.

 # usb-devices

T:  Bus=02 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=20a0 ProdID=4211 Rev=02.00
S:  Manufacturer=Nitrokey
S:  Product=Nitrokey Start
S:  SerialNumber=FSIJ-1.2.10-43243711
C:  #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=0b(scard) Sub=00 Prot=00 Driver=(none)

Mit Hilfe des Befehls lsusb aus dem RPM-Paket usbutils können wir auch die Produkt- und Hersteller-Identifikationsnummer des Nitrokey-Sticks ermitteln.

 # lsusb
Bus 002 Device 003: ID 20a0:4211 Clay Logic

Im Syslog wird uns beim Anstecken des Sticks dies entsprechend protokolliert:

Nov 24 12:03:55 T410 kernel: usb 2-1.2: new full-speed USB device number 3 using ehci-pci
Nov 24 12:03:55 T410 kernel: usb 2-1.2: New USB device found, idVendor=20a0, idProduct=4211
Nov 24 12:03:55 T410 kernel: usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Nov 24 12:03:55 T410 kernel: usb 2-1.2: Product: Nitrokey Start
Nov 24 12:03:55 T410 kernel: usb 2-1.2: Manufacturer: Nitrokey
Nov 24 12:03:55 T410 kernel: usb 2-1.2: SerialNumber: FSIJ-1.2.10-43243711
Nov 24 12:03:55 T410 mtp-probe: checking bus 2, device 3: "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2"
Nov 24 12:03:55 T410 mtp-probe: bus: 2, device: 3 was not an MTP device
Nov 24 12:03:55 T410 systemd: Reached target Smart Card.
Nov 24 12:03:55 T410 systemd: Starting Smart Card.

Für den Zugriff auf die SmartCard bzw. auf den Nitrokey Start benötigen wir z.B. für GPG den SmartCard-Daemon scdeamon welcher bei CentOS 7 mit Hilfe es Pakets gnupg2-smime bereitgestellt wird.

Dieses Paket installieren wir nun noch via yum.

 #  yum install gnupg2-smime -y

Leider ist das Paket an sich aus Sicht der Entwickler des Kryptostick in einer nicht aktuellen Version bei CentOS 7 verfügbar (CentOS 7: 2.0.22 - aktuelle Version: 2.2.11)¹⁾. Das hat leider zur Folge, dass wir die PGP-Schlüssel nicht direkt auf der SmartCard generieren können, sondern diesen wie gewohnt auf dem Rechner erzeugen und anschliessend auf den Nitrokey Start Stick verschoben werden muss.

Für den Betrieb unter CentOS 7 müssen wir uns noch passende udev-Definitionen hier besorgen und unserer Umgebung anpassen. Dies ist notwendig, da sonst die Gerätedatei nicht mit den entsprechenden Benutzer-Rechten angelegt wird! Wir wechseln also erst einmal in das entsprechende Konfigurationsverzeichnis /etc/udev/rules.d/.

 # cd /etc/udev/rules.d/

Dann holen wir uns die entsprechende Musterdatei auf unseren Rechner.

 # wget https://www.nitrokey.com/sites/default/files/41-nitrokey.rules

Unter CentOS 7 gibt es eine keine standardmässig angelegte Gruppe plugdev, daher werden wir diese erst einmal anlgen.

 # groupadd plugdev

Dann setzen wir unseren Benutzer django in diese Gruppe plugdev.

 # usermod -aG plugdev django

Nun passen wir noch die eingangs heruntergeladene udev-Regeldatei /etc/udev/rules.d/41-nitrokey.rules an. Der entscheidende Zusatz ist nun hier die Option OWNER=„django“.

 # vim /etc/udev/rules.d/41-nitrokey.rules

/etc/udev/rules.d/41-nitrokey.rules

# Nitrokey U2F
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0664", OWNER="django", GROUP="plugdev", ATTRS{idVendor}=="2581", ATTRS{idProduct}=="f1d0"
# Nitrokey FIDO U2F
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0664", OWNER="django", GROUP="plugdev", ATTRS{idVendor}=="20a0", ATTRS{idProduct}=="4287"
 
SUBSYSTEM!="usb", GOTO="gnupg_rules_end"
ACTION!="add", GOTO="gnupg_rules_end"
 
# USB SmartCard Readers
## Crypto Stick 1.2
ATTR{idVendor}=="20a0", ATTR{idProduct}=="4107", ENV{ID_SMARTCARD_READER}="1", ENV{ID_SMARTCARD_READER_DRIVER}="gnupg", GROUP+="plugdev", TAG+="uaccess"
## Nitrokey Pro
ATTR{idVendor}=="20a0", ATTR{idProduct}=="4108", ENV{ID_SMARTCARD_READER}="1", ENV{ID_SMARTCARD_READER_DRIVER}="gnupg", GROUP+="plugdev", TAG+="uaccess"
## Nitrokey Storage
ATTR{idVendor}=="20a0", ATTR{idProduct}=="4109", ENV{ID_SMARTCARD_READER}="1", ENV{ID_SMARTCARD_READER_DRIVER}="gnupg", GROUP+="plugdev", TAG+="uaccess"
## Nitrokey Start
#ATTR{idVendor}=="20a0", ATTR{idProduct}=="4211", ENV{ID_SMARTCARD_READER}="1", ENV{ID_SMARTCARD_READER_DRIVER}="gnupg", GROUP+="plugdev", TAG+="uaccess"
ATTR{idVendor}=="20a0", ATTR{idProduct}=="4211", ENV{ID_SMARTCARD_READER}="1", ENV{ID_SMARTCARD_READER_DRIVER}="gnupg", OWNER+="django", GROUP+="plugdev", TAG+="uaccess"
## Nitrokey HSM
ATTR{idVendor}=="20a0", ATTR{idProduct}=="4230", ENV{ID_SMARTCARD_READER}="1", ENV{ID_SMARTCARD_READER_DRIVER}="gnupg", GROUP+="plugdev", TAG+="uaccess"
 
LABEL="gnupg_rules_end"

Zum Aktivieren unserer geänderten udev-Regeldatei lassen wir diese nun erneut einlesen; hierzu verwenden wir folgenden Befehl:

 # udevadm control --reload-rules

Sobald wir nun unseren Nitrokey Pro-Stick in einen USB-Port stecken wird die zugehörige Gerätedate mit den richtigen Berechtigungen angelegt. Hierzu verwenden wir die zum Stick passenden ANgaben, die wir mit lsusb ermittelt haben.

 # lsusb

Bus 002 Device 006: ID 20a0:4211 Clay Logic

 # ll /dev/bus/usb/002/032

crw-rw-r--+ 1 django plugdev 189, 133 24. Nov 18:37 /dev/bus/usb/002/006

Da es sich bei der Chipkarte des Nitrokey Start um eine standardkompatible OpenPGP-Karte handelt, kann der Kryptostick mit Hilfe von GnuPG verwaltet werden. Hierzu installieren wir uns das Paket gnupg2, sofern es nicht bereits bei der Erstkonfiguration unseres Rechner installiert wurde.

 # yum install gnupg2

Alle Sicherheitsfunktionen wie z.B. das Erzeugen/Speichern von GPG-Schlüsseln, das Verschlüsseln/Entschlüsseln einer Datei, das Signieren einer Nachricht, die auf der Hardware ausgeführt werden, können mit Hilfe des Befehls gpg bzw. gpg2, welches identisch mit gpg ist (!) gesteuert werden.

Sollte beim Aufruf des Befehls gpg die Karte nicht sofort angesprochen werden können, einfach den Befehl nochmals ausführen:

 $ gpg --card-status

gpg: selecting openpgp failed: Karte nicht vorhanden
gpg: OpenPGP Karte ist nicht vorhanden: Karte nicht vorhanden

card-status

Mit der Option card-status können wir uns mit dem Befehl gpg –card-status den Kartenstatus ausgeben lassen.

 $ gpg2 --card-status

Application ID ...: D276000124010200FFFE432437110000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 43243711
Name of cardholder: [nicht gesetzt]
Language prefs ...: [nicht gesetzt]
Sex ..............: unbestimmt
URL of public key : [nicht gesetzt]
Login data .......: [nicht gesetzt]
Signature PIN ....: zwingend
Key attributes ...: 2048R 2048R 2048R
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 0
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]
General key info..: [none]

Die einzelnen Datenfelder haben hierbei folgende Bedeutung:

Datenfeld	Beschreibung
Application ID	Individuelle (unique) KartenID, diese beinhaltet: ° den Kartentyp ° die Version der Spezifikation ° den Hersteller und ° die Seriennummer des Cryptosticks Diese Application ID ist einmalig und bei jeder Karte anders.
Version	verwendete OpenPGP Version
Manufacturer	Hersteller der Karte
Serial number	Seriennummer der Karte, die vom Hersteller vergeben wurde.
Name of cardholder	Vorname und Nachname des Karteninhabers ( Es sind hier derzeit nur reines ASCII erlaubt, also keine deutschen Umlaute). Dieses Feld wird von GPG nicht verwendet.
Language prefs	Gewählte/bevorzugte Sprache (Muttersprache) des Karteninhabers. Dieses Feld wird von GPG nicht verwendet.
Sex	Geschlecht des Karteninhabers.: (Männlich (M), Weiblich (F) oder Leerzeichen)
URL of public key	Angabe einer URL, mit der der public-key mit Hilfe des Befehls fetch unter gpg --edit-card auf die Karte geladen werden kann.
Login data	Bei diesem Feld kann der Account-Name des Karteninhabers abgelegt werden, der bei Anmeldeversuchen genutzt werden kann. *GPG* führt hier keinerlei Abgleiche zwischen diesem Namen und dem Namen der in einem Schlüssel angegeben und verwendet wird durch!
Signature PIN	Hier kann über die beiden Schalter zwingend und nicht zwingend eingestellt werden, ob bei jedem Signatur-Vorgang die PIN abgefragt werden soll, oder nicht. Bei der Option nicht zwingend kann GPG die PIN zwischenspeichern, solange der Nitrokey-Stick angesteckt bleibt.
Key attributes	Angaben über Art und Umfang der hinterlegten Schlüssel
Max. PIN lengths	Maximale Länge der einzelnen PINs, kann nicht verändert werden!
PIN retry counter	Zähler für die verbleibenden Versuche zur Eingabe der richtigen PIN. Der max. Zählwert von 3 wird bei jeder Falscheingabe um eins heruntergesetzt. Sobald die richtige Admin-PIN eingegeben wurde, wir der max. Wert von 3 wieder zurück gesetzt. Die beiden ersten Werte (von links gesehen) werden für die User-PIN verwendet. GPG stellt hierbei sicher, dass beide werde synchronisiert werden. Der zweite (mittlere) Wert wird lediglich für Besonderheiten aus dem ISO-Standard 7816 (https://de.wikipedia.org/wiki/ISO_7816) verwendet. Der dritte (rechte) Wert wird als Fehlversuchszähler für die Admin_PIN verwendet.
Signature counter	Zähler der generierten Signaturen bzw. Signaturvorgänge mit der KArte. Der Zähler kann nicht manipuliert werden und wird lediglich zurückgesetzt, sobald ein neuer Signature-Schlüssel erzeugt oder auf die Karte geladen wird.
Signature key	Signatur-Schlüssel (primärer OpenPGP-Schlüssel)
created	Datum und Uhrzeit an dem der Schlüssel erzeugt wurde
Encryption key	Entschlüsselungs-Schlüssel (Unterschlüssel des primären (Signature-)Schlüssels.
created	Datum und Uhrzeit an dem der Schlüssel erzeugt wurde
Authentication key	Authentifizierung-Schlüssel (Unterschlüssel des primären (Signature-)Schlüssels.
created	Datum und Uhrzeit an dem der Schlüssel erzeugt wurde
General key info	Diese primäre USer ID wird angezeigt, sobald ein entsprechender öffentlicher Schlüssel (public-key) verfügbar ist.

card-edit

Mit Hilfe des Befehls gpg --card-edit haben wir entsprechend umfangreiche Zugriffs-, Erstellungs- und Änderungsoptionen auf die Daten und das Schlüsselmaterial, welches auf der Smartcard gespeichert wurden und werden. Viele hilfreiche Informationen zum Umgang mit den Befehlen die uns das Programm gpg bietet, findet man in der zugehörigen Dokumentation auf der Projektseite von https://www.gnupg.org/.

 $ gpg --card-edit

Application ID ...: D276000124010200FFFE432437110000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 43243711
Name of cardholder: [nicht gesetzt]
Language prefs ...: [nicht gesetzt]
Sex ..............: unbestimmt
URL of public key : [nicht gesetzt]
Login data .......: [nicht gesetzt]
Signature PIN ....: zwingend
Key attributes ...: 2048R 2048R 2048R
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 0
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]
General key info..: [none]

gpg/card>

User-Befehle

Mit Hilfe des Befehls help können wir uns anzeigen lassen, welche Optionen im jeweiligen Modus Benutzer oder Admin zur Verfügung stehen.

gpg/card> help

quit       Menü verlassen
admin      Zeige Admin-Befehle
help       Diese Hilfe zeigen
list       Alle vorhandenen Daten auflisten
fetch      Holen des Schlüssels mittels der URL auf der Karte
passwd     Menü für Ändern oder Entsperren der PIN
verify     überprüfe die PIN und liste alle Daten auf
unblock    die PIN mit dem Rückstellcode wieder freigeben

Admin-Befehle

Mit dem Befehl admin können wir in den Admin-Modus/-Bereich wechseln und auch dort alle Befehle mit Hilfe von help anzeigen lassen.

gpg/card> admin

Admin-Befehle sind erlaubt

gpg/card> help

quit       Menü verlassen
admin      Zeige Admin-Befehle
help       Diese Hilfe zeigen
list       Alle vorhandenen Daten auflisten
name       Kartenbesitzernamen ändern
url        Schlüssel-holen-URL ändern
fetch      Holen des Schlüssels mittels der URL auf der Karte
login      Ändern der Logindaten
lang       Ändern der Spracheinstellungen
sex        Ändern des Geschlechts des Kartenbesitzers
cafpr      Ändern des CA-Fingerabdrucks
forcesig   Umschalten des "Signature-force-PIN"-Schalters
generate   neue Schlüssel erzeugen
passwd     Menü für Ändern oder Entsperren der PIN
verify     überprüfe die PIN und liste alle Daten auf
unblock    die PIN mit dem Rückstellcode wieder freigeben

Individuelle Konfiguration - Stick personalisieren

Zunächst wollen wir unseren Stick personalisieren, also mit den Benutzerspezifischen Daten versorgen:

Name of cardholder	Vorname und Nachname des Karteninhabers (Es sind hier derzeit nur reines ASCII erlaubt, also keine deutschen Umlaute). Dieses Feld wird von GPG nicht verwendet.
Language prefs	Gewählte/bevorzugte Sprache (Muttersprache) des Karteninhabers. Dieses Feld wird von GPG nicht verwendet.
Sex	Geschlecht des Karteninhabers.: (Männlich (M), Weiblich (F) oder Leerzeichen)
URL of public key	Angabe einer URL, mit der der public-key mit Hilfe des Befehls fetch unter `gpg --edit-card` auf die Karte geladen werden kann.
Login data	Bei diesem Feld kann der Account-Name des Karteninhabers abgelegt werden, der bei Anmeldeversuchen genutzt werden kann. GPG führt hier keinerlei Abgleiche zwischen diesem Namen und dem Namen der in einem Schlüssel angegeben und verwendet wird durch!

Zum Ändern dieser Daten müssen wir nach der Anmeldung an der Karte mit dem Befehl adminin den Admin Bereich wechseln.

 $ gpg --card-edit

Application ID ...: D276000124010200FFFE432437110000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 43243711
Name of cardholder: [nicht gesetzt]
Language prefs ...: [nicht gesetzt]
Sex ..............: unbestimmt
URL of public key : [nicht gesetzt]
Login data .......: [nicht gesetzt]
Signature PIN ....: zwingend
Key attributes ...: 2048R 2048R 2048R
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 0
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]
General key info..: [none]

gpg/card>

 gpg/card> admin

Admin-Befehle sind erlaubt

Wir ändern zunächst den Namen des Karteninhabers Name of cardholder:

 gpg/card> name

Familienname des Kartenbesitzers:aka BOfH
Vorname des Kartenbesitzers:Django

Als nächstes definieren wir die Sprache des Kartenbenutzers:

 gpg/card> lang

Spracheinstellungen de

Im nächsten Schritt setzen wir das Geschlecht des Karteninhabers:

 gpg/card> sex

Geschlecht: (Männlich (M), Weiblich (F) oder Leerzeichen): m

Nun setzen wir noch den Anmelde-/Loginnamen entsprechend unserer Umgebung:

 gpg/card> login

Logindaten (Kontenname): django

Zu guter Letzt setzen wir nun die URL, von der der public-key mit Hilfe des Befehls fetch unter gpg --edit-card auf die Karte geladen werden kann.

 gpg/card> url

URL um den öffentlichen Schlüssel zu holen: https://keyserver.nausch.org/pks/lookup?op=get&search=0x074ECF6150A6BFED

Somit ergeben sich folgende benutzerindividuellen Daten auf der Karte:

 gpg/card> verify

Application ID ...: D276000124010200FFFE432437110000
Version ..........: 3.3
Manufacturer .....: unmanaged S/N range
Serial number ....: 43243711
Name of cardholder: Django aka BOfH
Language prefs ...: de
Sex ..............: männlich
URL of public key : https://keyserver.nausch.org/pks/lookup?op=get&search=0x074ECF6150A6BFED
Login data .......: django
Signature PIN ....: nicht zwingend
Key attributes ...: 2048R 2048R 2048R
Max. PIN lengths .: 64 64 64
PIN retry counter : 3 0 3
Signature counter : 0
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]
General key info..: [none]

Nun können wir die Erstinitialisierung abschließen und den Einstellungsdialog mit dem Befehl quit verlassen.

 gpg/card> quit

Schlüssel generieren

Wir wollen uns nun einen neuen GPG-Schlüssel in der SmartCard erzeugen und rufen hierzu den Befehl generate auf. Wir werden nun menügeführt durch eine Reihe von Standardfragen geführt, welche alle relevante Daten abfragen, die zur Generierung des Hauptschlüssels wie auch der Unterschlüssel die für die Aufgaben Signatur, Verschlüsselung und Authentifizierung benötigt werden.

 $ gpg --card-edit

 gpg/card> admin

Admin-Befehle sind erlaubt

 gpg/card> generate

Sicherung des Verschlüsselungsschlüssel außerhalb der Karte erstellen? (J/n) n
Welche Schlüssellänge wünschen Sie für den Signatur-Schlüssel? (2048) 
Welche Schlüssellänge wünschen Sie für den Verschlüsselungs-Schlüssel? (2048) 
Welche Schlüssellänge wünschen Sie für den Authentisierungs-Schlüssel? (2048) 
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"): Django aka BOfH
Email-Adresse: secmail@mailserver.guru
Kommentar: Bastard Operator from Hell
Sie haben diese User-ID gewählt:
    "Django aka BOfH (Bastard Operator from Hell) <secmail@mailserver.guru>"

Ändern: (N)ame, (K)ommentar, (E)-Mail oder (F)ertig/(A)bbrechen? f

Leider bricht die Generierung des Schlüssels an dieser Stelle mit dem folgenden Fehler ab:

gpg: key generation failed: Kartenfehler
Schlüsselerzeugung fehlgeschlagen: Kartenfehler

Stand: November 2018.

Dabei ist es unerheblich ob nun eine Schlüssellänge von 2048 oder 4096 ausgewählt wird!

Ähnlich wie schon beim Vorgängermodell GPF Cryptostick sollte eigentlich das Schlüsselmaterial auf dem Nitrokey Pro-Stick generiert worden sein.

vorhandenen Schlüssel importieren

Da aktuell²⁾ die Generierung der Schlüsseldaten direkt auf der SmartCard scheitert, werden wir zunächst den Schlüssel wie gewohnt generieren und anschliessend in den Nitrokey Start verschieben.

PGP-Schlüssel generieren

Zunächst erzeugen wir uns also einen PGP-Schlüssel, wie wir das sonst auch auf der Konsole machen würden.

 $ gpg --gen-key

gpg (GnuPG) 2.0.22; Copyright (C) 2013 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)
Ihre Auswahl? 1
RSA-Schlüssel können zwischen 1024 und 4096 Bit lang sein.
Welche Schlüssellänge wünschen Sie? (2048) 4096
Die verlangte Schlüssellänge beträgt 4096 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"): Django aka Bastard Operator from Hell
Email-Adresse: django@mailserver.guru
Kommentar: 
Sie haben diese User-ID gewählt:
    "Django aka Bastard Operator from Hell <django@mailserver.guru>"

Ä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 2ADD88EB 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:   4  signiert:   0  Vertrauen: 0-, 0q, 0n, 0m, 0f, 4u
gpg: nächste "Trust-DB"-Pflichtüberprüfung am 2020-03-19
pub   4096R/2ADD88EB 2018-11-24
  Schl.-Fingerabdruck = EBCE 68E4 42BD 55B6 03A4  8613 2D4D 70B0 2ADD 88EB
uid                  Django aka Bastard Operator from Hell <django@mailserver.guru>
sub   4096R/B815F8ED 2018-11-24

PGP-Unterschlüssel - subkeys

Bei der Public-Key-Verschlüsselungsverfahren denken wir in erster Linie an die beiden Schlüssel, den public-key, den wir z.B. zum Verschlüsseln von Informationen verwenden und dem secret-key, den wir zum Signieren und zum Entschlüsseln verwenden. Ganz so trivial ist das aber bei genauerer Betrachtung doch nicht und wir müssen uns, bevor wir mit dem Verschieben der Schlüssel aus dem Dateisystem in Richtung SmarctCard des Nitrokeys beschäftigen, mit dem Konzept der Unterschlüssel vertraut machen!

Werfen wir zur genaueren Betrachtung einfach einen Blick in unseren öffentlichen Schlüsselbund mit Hilfe des Programms gpg, etweder mit der Option --list-keys bzw. alternativ dazu mit der Option -k.

 $ gpg2 --list-keys

/home/django/.gnupg/pubring.gpg
------------------------------
pub   4096R/2ADD88EB 2018-11-24
uid                  Django aka Bastard Operator from Hell <django@mailserver.guru>
sub   4096R/B815F8ED 2018-11-24

Obwohl wir zuvor „nur einen“ PGP-Schlüssel generiert generiert hatten, sehen wir nun aber plötzlich zwei Schlüssel. Der eine ist mit dem Wert pub gekennzeichnet und hat die Schlüssel-ID 2ADD88EB und der zweite Schlüssel ist als sub gekennzeichnet und hat die Schlüssel-ID B815F8ED.

Beide Schlüssel sehen wir auch, wenn wir uns den Inhalt des secrings anzeigen lassen. Hierzu verwenden wir die Option –list-secret-keys bzw. alternative dazu die Kurzform -K:

 $ gpg2 --list-secret-keys

/home/django/.gnupg/secring.gpg
------------------------------
sec   4096R/2ADD88EB 2018-11-24
uid                  Django aka Bastard Operator from Hell <django@mailserver.guru>
ssb   4096R/B815F8ED 2018-11-24

Worin besteht nun der genaue Unterschied?
Nun, der erste Schlüssel ist der primäre Signierungs-Schlüssel und der zweite Schlüssel ist ein Unterschlüssel für die Verschlüsselung, der Verschlüsselung-Schlüssel.
Warum nun der ganze Aufstand mit diesem Unterschlüssel?
Stellen wir uns einmal folgendes Szenario vor: Eines Tagen wollen oder müssen wir den privaten Schlüssel wechseln, da dieser kompromittiert wurde, oder wir stellen fest, dass die ursprünglich gewählte Schlüssellänge nicht mehr unserem gesteigertem Sicherheitsbewusstsein entspricht. Wir können natürlich den alten Schlüssel verwerfen, zurückziehen und löschen, damit dieser unbrauchbar wird. Nur verlieren wir dadurch natürlich sämtliche beglaubigte Unterschriften unserer Kontaktpersonen und Freunde, die ja einen gewissen Vertrauensstatus bezeugen -der Hintergrund zum WoT-Gedanken³⁾. Als Folge daraus müssten wir erneut den ganzen Aufwand mit dem Key-Signing betreiben, was mit unter sehr aufwändig werden könnte!
Mit Unterschlüssel müssen wir nicht alles über Bord werden, sondern können z.B. weiterhin die beglaubigten Unterschriften unserer Freunde und Bekannten beibehalten und verwenden. Diese Signatur-Informationen sind, genau so wie die primäre User-ID, mit dem primären Signierungsschlüssel verknüpft! Subkeys selbst haben keine eigene Vertrauensstellung, sprich diese werden nicht selbst signiert. Der grosse Vorteil ist nun, dass wir diese Unterschlüssel für genau spezifizierte Einsatzzwecke definieren und nutzt können: Verschlüsselung, Signierung oder Authentifizierung. Diese Schlüssel können wir nun gezielt erneuern und dann an unsere Kontaktpersonen über den Master-Schlüssel verteilen können. Die Änderungen werden dann automatisch in deren Key-Rings als Aktualisierung des bestehenden Schlüssels übernommen, da die Unterschlüssel mit unserem Primary Signing Key signiert sind, dem unsere Kommunikationspartner ja schon bereits vertrauen.

Fragen wir den Status unseres Nitrokey Start ab, so sehen wir dort am Ende drei Speicherplätze für unterschiedliche Unterschlüssel, genauer gesagt der private Teil der Unterschlüssel, die auf dem Nitrokey Start gespeichert sind, nämlich den :

Signature key : Unterschlüssel zum Signieren
Encryption key : Unterschlüssel zum Verschlüsseln
Authentication key: Unterschlüssel zum Authentifizieren

 $ gpg2 --card-status

Application ID ...: D276000124010200FFFE432437110000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 43243711
Name of cardholder: [not set]
Language prefs ...: de
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: forced
Key attributes ...: 2048R 2048R 2048R
Max. PIN lengths .: 64 64 64
PIN retry counter : 3 0 3
Signature counter : 0
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]
General key info..: [none]

Damit wir nun die drei benötigten Unterschlüssel an die richtige Stelle unseres Nitrokey Start verschieben können, müssen wir noch ein paar Vorbereitungen treffen:

Erstellen weiterer Unterschlüssel für die Themen:
1. Signierung
2. Authentifizierung
Verschieben der privaten Unterschlüssel aus dem Schlüsselbund, der auf der Festplatte gespeichert waren in die SmartCard des Nitrokey Start.
Verschieben des primären Signierungs Schlüssel auf ein sicheres Sicherungsmedium.

Die öffentlichen Schlüssel bleiben nach wie vor im Schlüsselbund auf unserer Festplatte /home/~/.gnupg/pubring.gpg gespeichert, lediglich die privaten Unterschlüssel werden durch Proxy-Einträge im Schlüsselbund ersetzt!

Bevor wir nun zum Punkt 1. Erstellen weiterer Unterschlüssel widmen können rufen wir uns die ID des primären Signierungs-Schlüssel in Erinnerung.

 $ gpg2 --list-keys | grep pub

/home/django/.gnupg/pubring.gpg
pub   4096R/2ADD88EB 2018-11-24

In unserem Konfigurationsbeispiel hier ist dies die Key-ID: 2ADD88EB. Zunächst erstellen wir besagten Unterschlüssel zum Signieren:

$ gpg2 --expert --edit-key 2ADD88EB

gpg (GnuPG) 2.0.22; Copyright (C) 2013 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  4096R/2ADD88EB  erzeugt: 2018-11-24  verfällt: niemals     Aufruf: SC  
                     Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub  4096R/B815F8ED  erzeugt: 2018-11-24  verfällt: niemals     Aufruf: E   
[ uneing.] (1). Django aka Bastard Operator from Hell <django@mailserver.guru>

gpg>

Das Erzeugen von Unterschlüssel erfolgt mit Hilfe des Befehls addkey.

gpg> addkey

Schlüssel ist geschützt.

Sie benötigen eine Passphrase, um den geheimen Schlüssel zu entsperren.
Benutzer: "Django aka Bastard Operator from Hell <django@mailserver.guru>"
4096-Bit RSA Schlüssel, ID 2ADD88EB, erzeugt 2018-11-24

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?

Da wir einen RSA-Unterschlüssel zum Signieren erzeugen möchten, wählen wir hier die Option 4. Bei der Schlüssellänge verwenden wir wie auch schon bei der Erstellung des initialen Schlüsselpaares 4096; die Laufzeit des Unterschlüssels wählen wir entsprechend gleich oder kürzer wie beim primären Signierungs-Schlüssel, in inserem Beispiel also unendlich.

Ihre Auswahl? 4

RSA-Schlüssel können zwischen 1024 und 4096 Bit lang sein.
Welche Schlüssellänge wünschen Sie? (2048) 4096
Die verlangte Schlüssellänge beträgt 4096 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  4096R/2ADD88EB  erzeugt: 2018-11-24  verfällt: niemals     Aufruf: SC  
                     Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub  4096R/B815F8ED  erzeugt: 2018-11-24  verfällt: niemals     Aufruf: E   
sub  4096R/25704226  erzeugt: 2018-11-24  verfällt: niemals     Aufruf: S   
[ uneing.] (1). Django aka Bastard Operator from Hell <django@mailserver.guru>

gpg>

Das Gleiche machen wir nun erneut für unseren Authentifizierungs-Unterschlüssel.

 gpg> addkey

Schlüssel ist geschützt.

Sie benötigen eine Passphrase, um den geheimen Schlüssel zu entsperren.
Benutzer: "Django aka Bastard Operator from Hell <django@mailserver.guru>"
4096-Bit RSA Schlüssel, ID 2ADD88EB, erzeugt 2018-11-24

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?

Für unseren Verschlüsselungs-Unterschlüssel wählen wir nun eben hier entsprechend die Option 8.

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?

Uns wir nun angezeigt, dass aktuell Signierung und Verschlüsselung vorausgewählt wurde: Derzeit erlaubte Vorgänge: Signieren Verschl.. Wir wählen nun nacheinander die Optionen für Signierung mit „V“ und Verschlüsselung mit „U“ ab und Signierung mit „U“ an.

Ihre Auswahl? v

Mögliche Vorgänge eines RSA-Schlüssels: Signieren Verschl. Authentisierung 
Derzeit erlaubte Vorgänge: Signieren 

   (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: 

   (U) Umschalten der Signaturfähigkeit
   (V) Umschalten der Verschlüsselungsfähigkeit
   (A) Umschalten der Authentisierungsfähigkeit
   (Q) Beenden

Ihre Auswahl? a

Mögliche Vorgänge eines RSA-Schlüssels: Signieren Verschl. Authentisierung 
Derzeit erlaubte Vorgänge: Authentisierung 

   (U) Umschalten der Signaturfähigkeit
   (V) Umschalten der Verschlüsselungsfähigkeit
   (A) Umschalten der Authentisierungsfähigkeit
   (Q) Beenden

Ihre Auswahl?

An der nun definierten Option Derzeit erlaubte Vorgänge: Authentisierung sehen wir, dass nun nachfolgend ein Authentifizierungs-Unterschlüssel generiert werden soll. Mit Q Verlassen wir diesen Dialog und generieren den besagten Authentifizierungs-Unterschlüssel.

Ihre Auswahl? q

RSA-Schlüssel können zwischen 1024 und 4096 Bit lang sein.
Welche Schlüssellänge wünschen Sie? (2048) 4096
Die verlangte Schlüssellänge beträgt 4096 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  4096R/2ADD88EB  erzeugt: 2018-11-24  verfällt: niemals     Aufruf: SC  
                     Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub  4096R/B815F8ED  erzeugt: 2018-11-24  verfällt: niemals     Aufruf: E   
sub  4096R/25704226  erzeugt: 2018-11-24  verfällt: niemals     Aufruf: S   
sub  4096R/E8B122B0  erzeugt: 2018-11-24  verfällt: niemals     Aufruf: A   
[ uneing.] (1). Django aka Bastard Operator from Hell <django@mailserver.guru>

gpg>

GnuPG listet nun den Primary Schlüssel zum Signieren und alle Unterschlüssel auf mit dem jeweiligen Verwendungszweck usage auf. E steht für Verschlüsseln, S für Signieren und A für Athentifizierung.

Zu guter letzt speichern wir nun mit dem Befehl save unsere gerade erstellen Unterschlüssel im Schlüsselspeicher auf der Festplatte ab.

gpg> save

Fragen wir nun erneut den Schlüsselbund mit den secret-keys ab sehen wir nun unsere drei Unterschlüssel.

 $ gpg2 -K

/home/django/.gnupg/secring.gpg
------------------------------
sec   4096R/2ADD88EB 2018-11-24
uid                  Django aka Bastard Operator from Hell <django@mailserver.guru>
ssb   4096R/B815F8ED 2018-11-24
ssb   4096R/25704226 2018-11-24
ssb   4096R/E8B122B0 2018-11-24

backup des vorhandenen Keyrings aus dem Userverzeichnis

Bevor wir unseren Schlüsselspeicher im Userverzeichnis bei den späteren Verschiebeaktionen nicht versehentlich schrotten, kann für Restore-Zwecke ein Backup und ein sicheres Verwahren des Schlüsselspeichers angeraten sein.

 $ cp -a ~/.gnupg ~/.gnupg.$(date +%y%m%d)

Schlüssel in die ChipCard des Nitrokey Start verschieben

Nun werden wir die vorhin generierten Schlüssel an Ort und Stelle in die SmartCard des Nitrokey Start verschieben. Hierzu verwenden wir den Befehl keytocard des Programms gpg2. Wie schon beim Generieren der Unterschlüssel müssen wir angeben, welche primäre Schlüssel-ID bearbeitet oder genauer gesagt verschoben werden soll. In unserem Konfigurationsbeispiel ist das die ID 2ADD88EB.

 $ gpg2 --edit-key 2ADD88EB

gpg (GnuPG) 2.0.22; Copyright (C) 2013 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  4096R/2ADD88EB  erzeugt: 2018-11-24  verfällt: niemals     Aufruf: SC  
                     Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub  4096R/B815F8ED  erzeugt: 2018-11-24  verfällt: niemals     Aufruf: E   
sub  4096R/25704226  erzeugt: 2018-11-24  verfällt: niemals     Aufruf: S   
sub  4096R/E8B122B0  erzeugt: 2018-11-24  verfällt: niemals     Aufruf: A   
[ uneing.] (1). Django aka Bastard Operator from Hell <django@mailserver.guru>

gpg>

Für später merken wir uns nun in Welcher Reichenfolge die Unterschlüssel aufgelistet werden bzw. welche Key-ID zu welcher Aktion gehört. Die Key-ID 0 ist die des primären Signierungs-Schlüssel!

Sub-Key 1 - B815F8ED - E = encrypt = verschlüsseln
Sub-Key 2 - 25704226 - S = sign = signieren
Sub-Key 3 - E8B122B0 - A = authorize = authentifizieren

Da wir die privaten Schlüssel unserer drei Unterschlüssel verschieben wollen, wechseln wir von der Ansicht der öffentlichen in die Ansicht der privaten Schlüssel.

gpg> toggle

sec  4096R/2ADD88EB  erzeugt: 2018-11-24  verfällt: niemals   
ssb  4096R/B815F8ED  erzeugt: 2018-11-24  verfällt: niemals   
ssb  4096R/25704226  erzeugt: 2018-11-24  verfällt: niemals   
ssb  4096R/E8B122B0  erzeugt: 2018-11-24  verfällt: niemals   
(1)  Django aka Bastard Operator from Hell <django@mailserver.guru>

gpg>

Als erstes verschieben wir den privaten Verschlüsselungs-Unterschlüssel. Hierzu wählen wir diesen mit Eingabe von „1“ ein. Die Auswahl wird uns dann durch den * angezeigt.

gpg> key 1

sec  4096R/2ADD88EB  erzeugt: 2018-11-24  verfällt: niemals   
ssb* 4096R/B815F8ED  erzeugt: 2018-11-24  verfällt: niemals   
ssb  4096R/25704226  erzeugt: 2018-11-24  verfällt: niemals   
ssb  4096R/E8B122B0  erzeugt: 2018-11-24  verfällt: niemals   
(1)  Django aka Bastard Operator from Hell <django@mailserver.guru>

gpg>

Nun verschieben wir den ausgewählten Schlüssel in die SmartCard des Nitrokey. Als Ziel wählen wir dann richtiger Weise die Option 2 = Encryption key aus

gpg> keytocard

Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]

Wählen Sie den Speicherort für den Schlüssel:
   (2) Verschlüsselungs-Schlüssel
Ihre Auswahl? 2

Sie benötigen eine Passphrase, um den geheimen Schlüssel zu entsperren.
Benutzer: "Django aka Bastard Operator from Hell <django@mailserver.guru>"
4096-Bit RSA Schlüssel, ID B815F8ED, erzeugt 2018-11-24


sec  4096R/2ADD88EB  erzeugt: 2018-11-24  verfällt: niemals   
ssb* 4096R/B815F8ED  erzeugt: 2018-11-24  verfällt: niemals   
                     Kartennummer:FFFE 43243711
ssb  4096R/25704226  erzeugt: 2018-11-24  verfällt: niemals   
ssb  4096R/E8B122B0  erzeugt: 2018-11-24  verfällt: niemals   
(1)  Django aka Bastard Operator from Hell <django@mailserver.guru>

gpg>

Als nächstes verschieben wir den privaten Signierungs-Unterschlüssel aus, in dem wir erst den bereits ausgewählten Verschlüsselungs-Key abwählen und dann den Signierungs-Key anwählen.

gpg> key 1

sec  4096R/2ADD88EB  erzeugt: 2018-11-24  verfällt: niemals   
ssb  4096R/B815F8ED  erzeugt: 2018-11-24  verfällt: niemals   
                     Kartennummer:FFFE 43243711
ssb  4096R/25704226  erzeugt: 2018-11-24  verfällt: niemals   
ssb  4096R/E8B122B0  erzeugt: 2018-11-24  verfällt: niemals   
(1)  Django aka Bastard Operator from Hell <django@mailserver.guru>

gpg> key 2

sec  4096R/2ADD88EB  erzeugt: 2018-11-24  verfällt: niemals   
ssb  4096R/B815F8ED  erzeugt: 2018-11-24  verfällt: niemals   
                     Kartennummer:FFFE 43243711
ssb* 4096R/25704226  erzeugt: 2018-11-24  verfällt: niemals   
ssb  4096R/E8B122B0  erzeugt: 2018-11-24  verfällt: niemals   
(1)  Django aka Bastard Operator from Hell <django@mailserver.guru>

Nun verschieben wir den privaten Signierungs-Unterschlüssel in Richtung SmartCard des Nitrokey Start. Hier wählen wir nun die 1 für Signature key aus.

gpg> keytocard

Signature key ....: [none]
Encryption key....: 7EDD 7456 77A7 F355 C4A8  930E 29E1 FED4 B815 F8ED
Authentication key: [none]

Wählen Sie den Speicherort für den Schlüssel:
   (1) Signatur-Schlüssel
   (3) Authentisierungs-Schlüssel
Ihre Auswahl? 1

Sie benötigen eine Passphrase, um den geheimen Schlüssel zu entsperren.
Benutzer: "Django aka Bastard Operator from Hell <django@mailserver.guru>"
4096-Bit RSA Schlüssel, ID 25704226, erzeugt 2018-11-24


sec  4096R/2ADD88EB  erzeugt: 2018-11-24  verfällt: niemals   
ssb  4096R/B815F8ED  erzeugt: 2018-11-24  verfällt: niemals   
                     Kartennummer:FFFE 43243711
ssb* 4096R/25704226  erzeugt: 2018-11-24  verfällt: niemals   
                     Kartennummer:FFFE 43243711
ssb  4096R/E8B122B0  erzeugt: 2018-11-24  verfällt: niemals   
(1)  Django aka Bastard Operator from Hell <django@mailserver.guru>

gpg>

Zu guter Letzt fehlt nun noch unser Authentifizierungs-Unterschlüssel. Wir wählen also wieder den Schlüssel 2 ab und den Schlüssel 3 aus.

gpg> key 2

sec  4096R/2ADD88EB  erzeugt: 2018-11-24  verfällt: niemals   
ssb  4096R/B815F8ED  erzeugt: 2018-11-24  verfällt: niemals   
                     Kartennummer:FFFE 43243711
ssb  4096R/25704226  erzeugt: 2018-11-24  verfällt: niemals   
                     Kartennummer:FFFE 43243711
ssb  4096R/E8B122B0  erzeugt: 2018-11-24  verfällt: niemals   
(1)  Django aka Bastard Operator from Hell <django@mailserver.guru>

gpg> key 3

sec  4096R/2ADD88EB  erzeugt: 2018-11-24  verfällt: niemals   
ssb  4096R/B815F8ED  erzeugt: 2018-11-24  verfällt: niemals   
                     Kartennummer:FFFE 43243711
ssb  4096R/25704226  erzeugt: 2018-11-24  verfällt: niemals   
                     Kartennummer:FFFE 43243711
ssb* 4096R/E8B122B0  erzeugt: 2018-11-24  verfällt: niemals   
(1)  Django aka Bastard Operator from Hell <django@mailserver.guru>

Nun verschieben wir den privaten Authentifizierungs-Unterschlüssel in Richtung SmartCard des Nitrokey Start. Hier wählen wir nun die 3 für Authentication key aus.

gpg> keytocard

Signature key ....: 9EF2 5BA7 4935 4D52 B2F7  0044 86AF 96F5 2570 4226
Encryption key....: 7EDD 7456 77A7 F355 C4A8  930E 29E1 FED4 B815 F8ED
Authentication key: [none]

Wählen Sie den Speicherort für den Schlüssel:
   (3) Authentisierungs-Schlüssel
Ihre Auswahl? 3

Sie benötigen eine Passphrase, um den geheimen Schlüssel zu entsperren.
Benutzer: "Django aka Bastard Operator from Hell <django@mailserver.guru>"
4096-Bit RSA Schlüssel, ID E8B122B0, erzeugt 2018-11-24


sec  4096R/2ADD88EB  erzeugt: 2018-11-24  verfällt: niemals   
ssb  4096R/B815F8ED  erzeugt: 2018-11-24  verfällt: niemals   
                     Kartennummer:FFFE 43243711
ssb  4096R/25704226  erzeugt: 2018-11-24  verfällt: niemals   
                     Kartennummer:FFFE 43243711
ssb* 4096R/E8B122B0  erzeugt: 2018-11-24  verfällt: niemals   
                     Kartennummer:FFFE 43243711
(1)  Django aka Bastard Operator from Hell <django@mailserver.guru>

gpg>

Zum Abschluss speichern wir nun unsere Änderungen im lokalen key-ring mit dem Befehl save.

gpg> save

Wenn wir jetzt den Kartenstatus abfragen, werden unsere drei Unterschlüssel entsprechend mit angezeigt.

 $ gpg2 --card-status

Application ID ...: D276000124010200FFFE432437110000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 43243711
Name of cardholder: Michael Nausch
Language prefs ...: de
Sex ..............: männlich
URL of public key : [nicht gesetzt]
Login data .......: django
Signature PIN ....: zwingend
Key attributes ...: 4096R 4096R 4096R
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 0
Signature key ....: 9EF2 5BA7 4935 4D52 B2F7  0044 86AF 96F5 2570 4226
      created ....: 2018-11-24 18:38:34
Encryption key....: 7EDD 7456 77A7 F355 C4A8  930E 29E1 FED4 B815 F8ED
      created ....: 2018-11-24 18:20:41
Authentication key: 5CE2 A469 770B F92A 7279  DB2E 494E 8C46 E8B1 22B0
      created ....: 2018-11-24 18:50:42
General key info..: pub  4096R/25704226 2018-11-24 Django aka Bastard Operator from Hell <django@mailserver.guru>
sec   4096R/2ADD88EB  erzeugt: 2018-11-24  verfällt: niemals   
ssb>  4096R/B815F8ED  erzeugt: 2018-11-24  verfällt: niemals   
                      Kartennummer:FFFE 43243711
ssb>  4096R/25704226  erzeugt: 2018-11-24  verfällt: niemals   
                      Kartennummer:FFFE 43243711
ssb>  4096R/E8B122B0  erzeugt: 2018-11-24  verfällt: niemals   
                      Kartennummer:FFFE 43243711

change-pin

Wie schon mit der Nitrokey App können wir auch mit Hilfe des Befehls gpg --change-pin die Benutzer- und die Admin-PIN, wie auch die PIN zum Zurücksetzen der Benutzer-PIN, ändern.

Die Benutzer-PIN (Menüpunkt 1) wird benötigt für den täglichen Betrieb wie z.B. zum Entsperren des Token, oder zum Signieren und Verschlüsseln. Die Mindestlänge für den User-Pin beträgt 6 Zeichen.

Die Admin-PIN (Menüpunkt 3) wird für die Karten-/Token-Verwaltung verwendet, so z.B. für das Laden von Schlüsseln auf den Krypto-Stick, das Erzeugen von Schlüsseln oder das Ändern von Informationen wie die Inhaberdaten auf der Karte. Die Mindestlänge für die Admin-PIN beträgt 8 Zeichen.

Wird die Benutzer-PIN 3x falsch eingeben, wird die Karte gesperrt und kann dann nur mit der Admin-PIN oder dem Reset-Code zurückgesetzt werden. Wenn Sie den falschen Admin-Pin dreimal eingeben, wird die Karte unbrauchbar und kann dann lediglich mit einem Factory-Reset (Verlußt aller Kartendaten!) zurück gesetzt werden!

Die Reset-PIN (Menüpunkt 4) kann nur zum Zurücksetzen der Benutzer-PIN verwendet werden. Die Mindestlänge für den Reset-Code beträgt 8 Zeichen. Der Reset-Code Fehlerzähler kann wiederum mit der Admin-PIN zurückgesetzt werden. Wird nach zweimaliger Falscheingabe der Benutzer- wie auch der Admin-PIN und dann die richtige PIN eingeben, wird der Fehlerzähler zurückgesetzt.

Worin besteht nun aber der genaue Unterschied zwischen dem Reset-Code und der Admin-PIN? Möchte man in einer Organisation Nitrokey Pro an seine Mitarbeiter ausgeben, werden bestimmte Daten, wie z.B. Namen, die Public Key URL oder auch das erzeugte Schlüsselmaterial zentral vorgegeben. Da der Benutzer selbst diese Daten nicht verändern können soll, wird dieser auch nicht Kenntnis von der Admin-PIN haben. Sperrt sich nun der Mitarbeiter aus, weil er die Benutzer-PIN 3x falsch eingegeben hat, kann der Neutzer natürlich nicht die Admin-PIN eingeben, da er diese nicht kennt. Hier kommt nun der Reset-Code ins Spiel. Mit Hilfe dieses Codes kann der Benutzer nun die Benutzer-PIN zurücksetzen.

 $ gpg --change-pin

gpg: OpenPGP Karte Nr. D276000124010200FFFE432437110000 erkannt

1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit

Ihre Auswahl?

Beim Menüpunkt 1 können wir z.B. die Benutzer-PIN abändern. Wir werden dann nach der aktuellen PIN gefragt und müssen die neue PIN 2x eingeben zum Abändern.

Bild: PIN-Eingabedialog beim Abändern der Benutzer-/Admin-PIN