Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- nitrokey:arch:start [14.04.2025 16:51. ] – [Unterschrift von Commits anzeigen] django
+++ nitrokey:arch:start [09.07.2025 12:05. ] (aktuell) – [Nitrokey Start und Thunderbird] django
@@ Zeile 128: / Zeile 128: @@
 ++++
-Die erforderliche udev-Regel findet sich also in der Datei **''/usr/lib/udev/rules.d/41-nitrokey.rules''***.
+Die erforderliche udev-Regel findet sich also in der Datei **''/usr/lib/udev/rules.d/41-nitrokey.rules''**.
 ==== erster Test ====
@@ Zeile 273: / Zeile 273: @@
 Wir wollen uns nun einen neuen PGP-Schlüssel in der SmartCard erzeugen und rufen hierzu den Befehl **generate** auf. Der **Nitrokey Start** unterstützt **__RSA__-Schlüssellängen** von **1024** und maximal von **2048**!
-<WRAP center round important 80%>
+<WRAP center round important 90%>
 Mit Hinblick auf die möglichen Unsicherheiten im Bezug auf die [[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.pdf|RSA-Schlüssellänge]] werden wir uns später noch eingehend mit der Erstellung eines [[start#ed25519-schluessel_generieren|ED25519]] beschäftigen!
@@ Zeile 318: / Zeile 318: @@
 Nun wird auf der Karte der gewählte Schlüssel erzeugt.
-<WRAP center round tip 95%>
+<WRAP center round tip 90%>
 Die Erzeugung eines Schlüssels mit einer Länge von **2048** dauert ca. 5 Minuten, also keinesfalls den Nitrokey Start abziehen oder die Generierung abbrechen! Während der Erzeugung der Schlüssel leuchtet die rote LED im Stick.
 </WRAP>
@@ Zeile 677: / Zeile 677: @@
 === change-pin ===
-<WRAP center round alert 95%>
+<WRAP center round alert 90%>
 **WICHTIG**:
 Unbedingt vor dem ersten Ändern der PINs ist es notwendig, erst einmal Schlüssel zu generieren bzw. zu importieren! Denn sonst schlägt das Ändern der Benutzer-PIN fehl, bzw. wird die Benutzer-PIN beim Überschreiben von Schlüsseln auf den Default-Wert von **123456** zurückgesetzt. Die Default-PIN für den Admin lautet **12345678**.
@@ Zeile 690: / Zeile 690: @@
 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.
-<WRAP center round important 95%>
+<WRAP center round important 90%>
 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!
@@ Zeile 775: / Zeile 775: @@
 gpg/card> quit</code>
+=== Schlüssel umziehen bzw. auf weiterem Rechner nutzen ===
+Oft kommt es vor dass man entweder sein Schlüsselmaterial von einem Rechner auf einen anderen|neuen umziehen möchte, oder man benutzt ein und denselben Stick wahlweise auf mehreren Rechnern (Desktop, Laptop, etc.).
+<WRAP center round tip 90%>
+Nur wie bekommt man nun seinen privaten Schlüssel, der ja nur in der SmartCard des Kryptosticks sicher verwahrt wird, oder genauer gesagt seine Identität auf den neuen weiteren Rechner? Ganz einfach, man exportiert den OpenPGP-Schlüssel aus dem Schlüsselbund und importiert diesen dann auf dem neuen Rechner wieder mit GnuPG!
+Der Ablauf ist der Gleiche wie bei einem "normalen PGP-Key" welchen wir z.B. mit Hilfe von **''gpg %%--%%generate-key''** erzeugt hätten. Der private Schlüssel auf dem Kryptostick ist dabei so etwas wie ein "Dummy", der lediglich die Information enthält, dass der eigentlich richtige private Schlüssel auf dem Stick mit der **ID...** zu finden ist. Und genau dieser "Dummy" muss dann auf dem  weiteren Rechner in den **keyring** importiert werden.</WRAP>
+Zunächst werfen wir also einen Blick in unseren keyring:
+   $ gpg2 --list-secret-keys
+<code>/home/django/.gnupg/pubring.kbx
+-------------------------------
+sec>  ed25519 2024-01-03 [SC]
+C082445CDFB72DECD650350610ED9AEE553353F
+      Card serial no. = FFFE 43243711
+uid           [ultimate] Django (Bastard Operator from Hell [BOfH]) <django@nausch.org>
+ssb>  ed25519 2024-01-03 [A]
+ssb>  cv25519 2024-01-03 [E]
+sec>  ed25519 2024-12-15 [SC]
+      F5F0CD13074BA693D950F92A0A56C9A3A69FE291
+      Card serial no. = 000F 6447F253
+uid           [ultimate] Michael Nausch <michael@nausch.org>
+ssb>  ed25519 2024-12-15 [A]
+ssb>  cv25519 2024-12-15 [E]</code>
+Den privaten Schlüssel unseres Nitrokey mit der Karten Serien-Nummer **''000F 6447F253''** und der Key-ID **''0A56C9A3A69FE291''** wollen wir nun auf unseren weiteren Rechner holen. Hierzu stecken wir diesen an unseren "alten bzw. ersten" Rechner. Mit folgendem Aufruf können wir auch die benötigten Infos auslesen um sicherzustellen, dass auch wirklich der eine von unseren 13 Kryptosticks der richtige ist. 8-)
+   $ gpg --card-status | grep 'General key info'
+  General key info..: pub  ed25519/0A56C9A3A69FE291 2024-12-15 Michael Nausch <michael@nausch.org>
+Zunächst exportieren wir nun also die "Key-Dummy-Daten":
+   $ gpg -o ~/michael@nausch.org.sc_dummy_private_key.asc --export-secret-key 0A56C9A3A69FE291
+Diese Datei enthält nun alle nötigen Informationen.
+   $ file ~/michael@nausch.org.sc_dummy_private_key.asc
+  /home/django/michael@nausch.org.sc_dummy_private_key.asc: OpenPGP Secret Key Version 4, Created Sun Dec 15 17:08:38 2024, EdDSA; User ID; Signature; OpenPGP Certificate
+Diese Datei kopieren wir nun auf einem sicheren und geschützten Weg auf unseren neuen weiteren Rechner.
+Werfen wir zunächst noch einen Blick in den **keyring** auf unserem zweiten Rechner:
+   $ gpg2 --list-secret-keys
+<code>/home/django/.gnupg/pubring.kbx
+-------------------------------
+sec>  ed25519 2024-01-03 [SC]
+C082445CDFB72DECD650350610ED9AEE553353F
+      Card serial no. = FFFE 43243711
+uid           [ultimate] Django (Bastard Operator from Hell [BOfH]) <django@nausch.org>
+ssb>  ed25519 2024-01-03 [A]
+ssb>  cv25519 2024-01-03 [E]
+</code>
+Hier fehlt also **__noch__** die Information für unseren weiteren Kryptostick der die eMail-adresse **''michael@nausch.org''** bedient.
+Wir importieren also nun die kopierte Pseudo-Dummy-Keydatei, welche wir auf unseren neuen bzw. weiteren Rechner kopiert haben.
+   $ gpg --import Downloads/michael@nausch.org.sc_dummy_private_key.asc
+<code>gpg: key 0A56C9A3A69FE291: public key "Michael Nausch <michael@nausch.org>" imported
+gpg: To migrate 'secring.gpg', with each smartcard, run: gpg --card-status
+gpg: key 0A56C9A3A69FE291: secret key imported
+gpg: Total number processed: 1
+gpg:               imported: 1
+gpg:       secret keys read: 1</code>
+Wie uns aufgetragen migrieren wir nun für die neue smartcard den **''secring.gpg''** bei angestecktem Nitrokey:
+   ~$ gpg --card-status
+<code>Reader ...........: Nitrokey Nitrokey 3 [CCID/ICCD Interface] 00 00
+Application ID ...: D276000124010304000F6447F2530000
+Application type .: OpenPGP
+Version ..........: 3.4
+Manufacturer .....: unknown
+Serial number ....: 6447F253
+Name of cardholder: Michael Nausch
+Language prefs ...: de
+Salutation .......: Mr.
+URL of public key : https://keys.openpgp.org/search?q=get&search=0x0A56C9A3A69FE291
+Login data .......: django
+Signature PIN ....: forced
+Key attributes ...: ed25519 cv25519 ed25519
+Max. PIN lengths .: 127 127 127
+PIN retry counter : 3 0 3
+Signature counter : 10
+KDF setting ......: off
+Signature key ....: F5F0 CD13 074B A693 D950  F92A 0A56 C9A3 A69F E291
+      created ....: 2024-12-15 17:08:38
+Encryption key....: DBBD 5355 D9D0 334A A3FA  751F A89D D54D AE0E 394A
+      created ....: 2024-12-15 17:08:38
+Authentication key: EE7C 3807 4F0A 8F2A 5601  BF91 1E61 4A9A 36D4 DF53
+      created ....: 2024-12-15 17:08:38
+General key info..: pub  ed25519/0A56C9A3A69FE291 2024-12-15 Michael Nausch <michael@nausch.org>
+sec>  ed25519/0A56C9A3A69FE291  created: 2024-12-15  expires: never
+                                card-no: 000F 6447F253
+ssb>  ed25519/1E614A9A36D4DF53  created: 2024-12-15  expires: never
+                                card-no: 000F 6447F253
+ssb>  cv25519/A89DD54DAE0E394A  created: 2024-12-15  expires: never
+                                card-no: 000F 6447F253</code>
+Nun lassen wir uns erneut alle secret-key-Informationen unsere **keyring** anzeigen:
+   $ gpg2 --list-secret-keys
+<code>/home/django/.gnupg/pubring.kbx
+-------------------------------
+sec>  ed25519 2024-01-03 [SC]
+C082445CDFB72DECD650350610ED9AEE553353F
+      Card serial no. = FFFE 43243711
+uid           [ultimate] Django (Bastard Operator from Hell [BOfH]) <django@nausch.org>
+ssb>  ed25519 2024-01-03 [A]
+ssb>  cv25519 2024-01-03 [E]
+sec>  ed25519 2024-12-15 [SC]
+      F5F0CD13074BA693D950F92A0A56C9A3A69FE291
+      Card serial no. = 000F 6447F253
+uid           [ unknown] Michael Nausch <michael@nausch.org>
+ssb>  ed25519 2024-12-15 [A]
+ssb>  cv25519 2024-12-15 [E]
+</code>
+Voila, wir haben also nun alle benötigten Informationen in unserem keyring, so dass wir den weiteren Nitrokey auch auf unserem zusätzlichen Rechner nutzen können!
+<WRAP center round important 90%>
+**WICHTIG:** \\ \\ Wollen wir unseren transferierten Schlüssel auch in **[[#nitrokey_start_und_thunderbird|Thunderbird]]** nutzen reicht es **__nicht__** den Schlüssel wie soeben beschrieben nur "in" **''gpg''** zu im portieren, der Schlüssel muss zusätzlich über die **OpenPGP-Schlüsselverwaltung von Thunderbird** importiert werden! Ansonsten kommt es zu unliebsamen Fehlermeldungen wie z.B. **''Die konfigurierte Schlüssel-ID wurde nicht in Ihrem Schlüsselbund gefunden.''**!
+</WRAP>
 === Verschlüsseln und entschlüsseln ===
@@ Zeile 899: / Zeile 1018: @@
 {{ :nitrokey:arch:thunderbird_007.png?nolink&874 |Bild: Menüfenster der Thunderbird individuellen Einstellungen}}
+<WRAP center round important 90%>
+**WICHTIG:** \\ Haben wir generierte Schlüssel von einem anderen Rechner aus auf unserem aktuellen Rechner kopiert und diese, wie im Kapitel **[[#schluessel_umziehen_bzw_auf_weiterem_rechner_nutzen|Schlüssel umziehen bzw. auf weiterem Rechner nutzen]]** beschrieben, importiert **__müssen__** wir die secret-keys auch noch Thunderbird und dessen **OpenPGP-Schlüssel Verwaltung** bekannt machen! \\
+Ansonsten kommt es zu unliebsamen Fehlermeldungen wie z.B. **''Die konfigurierte Schlüssel-ID wurde nicht in Ihrem Schlüsselbund gefunden.''**, da Thunderbird von der Existenz der hinterlegten privaten schlüssel zwar Kenntnis hat, diese aber auf Grund der fehlenden Verknüpfung nicht nutzen kann.
+</WRAP>
+Zur Kontrolle ob alle privaten Schlüssel in Thunderbird verankert sind oder zum Importieren von neuen (umgezogenen) Private Keys klicken wir auf die Schaltfläche **[ OpenPGP-Schlüssel __v__erwalten ]** auf der Konfigurations-Seite **Ende-zu-Ende-Verschlüsselung** bei den **Kontoeinstellungen**.
+{{ :nitrokey:arch:thunderbird_007.png?nolink&874 |Bild: Menüfenster der Thunderbird individuellen Einstellungen}}
+Im Folgenden Konfigurationsbeispiel sehen wir nur den Schlüssel für einen User|Adresse **''django@nausch.org''**.
+{{ :nitrokey:arch:thunderbird_010.png?nolink&550 |Bild: Menüfenster der Thunderbird individuellen Einstellungen zu OpenPGP-Schlüssel verwalten}}
+Zum Importieren des Schlüssels für den User|Adresse **''michael@nausch.org''** wählen wir unter **Datei** den Punkt **Geheime(n) Schlüssel aus Datei importieren**
+{{ :nitrokey:arch:thunderbird_011.png?nolink&550 |Bild: Menüfenster der Thunderbird individuellen Einstellungen zu OpenPGP-Schlüssel verwalten}}
+Auf der Folgenden Seite klicken wir nun auf die Schaltfläche **[ __D__atei für den Import auswählen ]** und wählen dann die betreffende Schlüsseldatei aus
+{{ :nitrokey:arch:thunderbird_011a.png?nolink&450 |Bild: Menüfenster der Thunderbird individuellen Einstellungen zu OpenPGP-Schlüssel verwalten}}
+Nun präsentiert und Thunderbirds Schlüsselverwaltung den erkannten Schlüssel für den User|Adresse **''michael@nausch.org''**. Wichtig ist das der Haken bei **Diesen Schlüssel als persönlichen Schlüssel verwenden** gesetzt ist. Anschliessend wählen wir die Schaltfläche **[ Fortfahren ]** aus.
+{{ :nitrokey:arch:thunderbird_012.png?nolink&550 |Bild: Menüfenster der Thunderbird individuellen Einstellungen zu OpenPGP-Schlüssel verwalten}}
+Über den Menüpunkt **[ Schlüss__e__leigenschaften ]** können wir uns nochmal svergewissern ob der Schlüssel für unseren Einsatzzwek entsprechend passt.
+{{ :nitrokey:arch:thunderbird_013.png?nolink&550 |Bild: Menüfenster der Thunderbird individuellen Einstellungen zu OpenPGP-Schlüssel verwalten}}
+Mit einem Klick auf die Schatfläche **[ OK ]** kommen wir zurück zur vorherigen Anzeige.
+{{ :nitrokey:arch:thunderbird_014.png?nolink&550 |Bild: Menüfenster der Thunderbird individuellen Einstellungen zu OpenPGP-Schlüssel verwalten}}
+Dort klicken wir auf die Schlatfläche **[ S__c__hließen ]** und beenden damit den Import des Schlüsselmaterials bzw. des Dummy-Privatekey unseres Nitrokeys.
+Wir sehen nun unsere beiden aktiven Schlüssel:
+{{ :nitrokey:arch:thunderbird_015.png?nolink&550 |Bild: Menüfenster der Thunderbird individuellen Einstellungen zu OpenPGP-Schlüssel verwalten}}
 ==== Nitrokey Start und Secure Shell ====
@@ Zeile 1081: / Zeile 1243: @@
 ==== Nitrokey Start und Git/Gitlab ====
-<WRAP center round important 80%>
+<WRAP center round important 90%>
 Git ist an sich kryptographisch sicher, so dass Änderungen sicher nachprüfbar nachverfolgt werden können. Was damit aber noch nicht sichergestellt werden kann, stammt die Änderung auch wirklich von der Person, der wir vertrauen! Git unterstützt hier ein paar Möglichkeiten die Arbeiten an einem Repository zu unterschreiben und auch zu überprüfen.
 </WRAP>
@@ Zeile 1102: / Zeile 1264: @@
 Nun können wir  Git konfigurieren, damit bei einem Commit Änderungen signiert werden können. Hierzu setzen wir die globale Git Option **''user.signingkey''** - wir setzen diese Option nun auf den zuvor ermittelten Key-ID Wert **''610ED9AEE553353F''**
-   git config --global user.signingkey 610ED9AEE553353F!
+   $ git config --global user.signingkey 610ED9AEE553353F!
+Am besten aktivieren wir zusätzlich auch noch die Option, dass automatisch __alle__ Commits automatisch signiert werden.
+   $ git config --local commit.gpgsign true
 === Unterzeichnung von Commits ===
-Wir sind nun in der Lage einzelne Commits zu unterschreiben, wie in dem nachfolgendem Beispiel. **''git commit -S -m %%"<-%%commit-message%%->"%%''**
+Wir sind nun in der Lage einzelne Commits zu unterschreiben, wie in dem nachfolgendem Beispiel. **''git commit -S -m %%"<-%%commit-message%%->"%%''**. Die Option **''-S''** zum Signieren wird jedoch __nur__ benötigt, wenn wir nicht wie zuvor beschrieben, das automatische Signieren der Commits __nicht__ aktiviert wurde!
 <html><pre class="code">
 <font style="color: rgb(25, 100, 5)">✔ </font><font style="color: rgb(196, 160, 0)">~/devel/ansible </font>[<font style="color: rgb(163, 75, 177)">AIDE-19.0 </font>L|<font style="color: rgb(204, 0, 0)">● 6</font>]
@@ Zeile 1142: / Zeile 1308: @@
 Hier sehen wir, dass __**nur**__ der Commit mit der ID **''4c03596''** signiert wurde (gekennzeichnet mit einem **''G''**), die anderen beiden jedoch nicht!
+=== PGP-Public-Key und GitLab ===
+Damit die signierten Commits nun auch in Gitlab überprüft werden können, ist es nötig dass der öffentliche Schlüssel beim Gitlab-Konto hinterlegt wird. Hierzu speichern wir den PGP-Public-Key beim Menüpunkt  **GPG Keys** bei den **User Settings** ab.
+{{ :nitrokey:arch:git_signing_key.png?nolink&900 |Bild: Bildschirmhardcopy Gitlab User Einstellungen - PGP Schlüssel}}
+Bei der Anzeige der Commits in der GitLab Web-UI wird nun mit der Anzeige **Verfied Commit** entsprechend angezeigt, wenn der Commit entsprechend signiert wurde. Somit können wir zweifelsfrei feststellen, dass zum einen der Commit nicht verändert wurde und dass zum anderen der Urheber eben jener verifizierter Admin war|ist.
+{{ :nitrokey:arch:git_signed_commit.png?nolink&900 |Bild: Bildschirmhardcopy Gitlab Sigend Commit}}
+== Zusammenfassung ==
+<WRAP center round tip 90%>
+Ja, Commits oder auch Tags mit einer PGP-Signatur zu versehen, ist sicherlich eine gute und valide Idee. Allerdings nutzt dies wenig wenn nicht alle Beteiligten verstanden und verinnerlicht haben, warum dies in den Standardworkflows zu integrieren und umzusetzen ist. Hierzu ist es wichtig dass zum einen **alle Team-Mitglieder** über einen aktuellen und benutzbaren PGP-Schlüssel verfügen und ihre lokale Git-Umgebung entsprechend konfiguriert haben, dass eben **alle** Commits entsprechend automatisch signiert werden.
+</WRAP>