nitrokey:arch:start

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
nitrokey:arch:start [03.06.2024 20:25. ] – [Öffentlichen Schlüssel ausgeben] djangonitrokey:arch:start [09.07.2025 12:05. ] (aktuell) – [Nitrokey Start und Thunderbird] django
Zeile 43: Zeile 43:
 /0/100/1f.6              generic        Wildcat Point-LP Thermal Management Controller</code> /0/100/1f.6              generic        Wildcat Point-LP Thermal Management Controller</code>
  
-Mit Hilfe des Befehls ''lsusb'' aus dem RPM-Paket **usbutils** können wir auch die **Produkt-** und **Hersteller**-Identifikationsnummer des Nitrokey-Sticks ermitteln.+Mit Hilfe des Befehls ''lsusb'' aus dem Arch-Linux-Paket **usbutils** können wir auch die **Produkt-** und **Hersteller**-Identifikationsnummer des Nitrokey-Sticks ermitteln.
    # lsusb | grep Nitrokey    # lsusb | grep Nitrokey
   Bus 002 Device 020: ID 20a0:4211 Clay Logic Nitrokey Start    Bus 002 Device 020: ID 20a0:4211 Clay Logic Nitrokey Start 
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 ==== ==== erster Test ====
Zeile 154: Zeile 154:
  
 ===== Anwendungsfälle - Software ===== ===== Anwendungsfälle - Software =====
 +==== Nitrokey Start und GnuPG  ====
 Da es sich bei der Chipkarte des **Nitrokey Start** um eine standardkompatible OpenPGP-Karte handelt, kann der Kryptostick mit Hilfe von **[[https://www.gnupg.org/|GnuPG]]** verwaltet werden.  Da es sich bei der Chipkarte des **Nitrokey Start** um eine standardkompatible OpenPGP-Karte handelt, kann der Kryptostick mit Hilfe von **[[https://www.gnupg.org/|GnuPG]]** verwaltet werden. 
  
Zeile 272: 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**!  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! 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 307: Zeile 308:
  
 Real name: Django aka [BOfH] Real name: Django aka [BOfH]
-Email address: secmail@mailserver.guru+Email address: secmail@nausch.org
 Comment: Bastard Operator from Hell Comment: Bastard Operator from Hell
 You selected this USER-ID: You selected this USER-ID:
-    "Django aka [BOfH] (Bastard Operator from Hell) <secmail@mailserver.guru>"+    "Django aka [BOfH] (Bastard Operator from Hell) <secmail@nausch.org>"
  
 Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
Zeile 317: Zeile 318:
 Nun wird auf der Karte der gewählte Schlüssel erzeugt.  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. 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> </WRAP>
Zeile 328: Zeile 329:
 pub   rsa2048 2020-08-04 [SC] pub   rsa2048 2020-08-04 [SC]
       E65B2BDF79A2E2E4C28F6E062E22436430385B49       E65B2BDF79A2E2E4C28F6E062E22436430385B49
-uid                      Django aka [BOfH] (Bastard Operator from Hell) <secmail@mailserver.guru>+uid                      Django aka [BOfH] (Bastard Operator from Hell) <secmail@nausch.org>
 sub   rsa2048 2020-08-04 [A] sub   rsa2048 2020-08-04 [A]
 sub   rsa2048 2020-08-04 [E]</code> sub   rsa2048 2020-08-04 [E]</code>
Zeile 341: Zeile 342:
   Reader ...........: 20A0:4211:FSIJ-1.2.19-43243711:0   Reader ...........: 20A0:4211:FSIJ-1.2.19-43243711:0
  
-Ferner muss auf dem Rechner, an dem der Stick angesteckt und administriert werden soll, GnuPG in Version 2.1.16 oder höher installiert sein. Bei open SUSE leap 15.ist dies kein Problem da aktuell((August 20)) die Version 2.2.5 bereitgestellt wird. Bei Bedarf können wir die Version z.B. wie folgt abfragen.+Ferner muss auf dem Rechner, an dem der Stick angesteckt und administriert werden soll, GnuPG in Version 2.1.16 oder höher installiert sein. Bei **[[https://archlinux.org/|Arch Linux]]** ist dies kein Problem da aktuell((August 24)) die Version 2.4.5 bereitgestellt wird. Bei Bedarf können wir die Version z.B. wie folgt abfragen.
    $ gpg2 --version | grep gpg    $ gpg2 --version | grep gpg
  
Zeile 481: Zeile 482:
  
 Real name: Django aka [BOfH] Real name: Django aka [BOfH]
-Email address: secmail@mailserver.guru+Email address: secmail@nausch.org
 Comment: Bastard Operator from Hell Comment: Bastard Operator from Hell
 You selected this USER-ID: You selected this USER-ID:
Zeile 547: Zeile 548:
 === Öffentlichen Schlüssel ausgeben === === Öffentlichen Schlüssel ausgeben ===
 Damit wir später unseren öffentlichen Schlüssel auch weitergeben oder zu einem [[https://keys.openpgp.org/|Keyserver]] hoch laden, exportieren wir diesen in eine Datei. Damit wir später unseren öffentlichen Schlüssel auch weitergeben oder zu einem [[https://keys.openpgp.org/|Keyserver]] hoch laden, exportieren wir diesen in eine Datei.
-  $ gpg --export --armor django@nausch.org > ~/.gnupg/secmail@mailserver.guru.pubkey+  $ gpg --export --armor django@nausch.org > ~/.gnupg/django@nausch.org.pubkey
  
 Diese Datei enthält unseren Schlüssel in ASCII-lesbarer Form. Diese Datei enthält unseren Schlüssel in ASCII-lesbarer Form.
-  $ cat ~/.gnupg/secmail@mailserver.guru.pubkey +  $ cat ~/.gnupg/django@nausch.org.pubkey 
-<file key secmail@mailserver.guru.pubkey>-----BEGIN PGP PUBLIC KEY BLOCK-----+<file key secmail@nausch.org.pubkey>-----BEGIN PGP PUBLIC KEY BLOCK-----
  
 mDMEZZXO7BYJKwYBBAHaRw8BAQdA++J6Astvcm2DsHDnzXGHKujQiokCxG+F3qPy mDMEZZXO7BYJKwYBBAHaRw8BAQdA++J6Astvcm2DsHDnzXGHKujQiokCxG+F3qPy
Zeile 582: Zeile 583:
    $ gpg --card-edit    $ gpg --card-edit
  
-<code>gpgdetected reader `Nitrokey Nitrokey Start (FSIJ-1.2.10-14081967) 00 00' +<code>Reader ...........: 20A0:4211:FSIJ-1.2.19-43243711:0 
-Application ID ...: D276000124010200FFFE140819670000+Application ID ...: D276000124010200FFFE432437110000 
 +Application type .: OpenPGP
 Version ..........: 2.0 Version ..........: 2.0
 Manufacturer .....: unmanaged S/N range Manufacturer .....: unmanaged S/N range
-Serial number ....: 14081967 +Serial number ....: 43243711 
-Name of cardholder: [not set] +Name of cardholder:  
-Language prefs ...: [not set] +Language prefs ...:  
-Sex ..............: unspecified+Salutation .......: 
 URL of public key : [not set] URL of public key : [not set]
 Login data .......: [not set] Login data .......: [not set]
Zeile 595: Zeile 597:
 Key attributes ...: ed25519 cv25519 ed25519 Key attributes ...: ed25519 cv25519 ed25519
 Max. PIN lengths .: 127 127 127 Max. PIN lengths .: 127 127 127
-PIN retry counter : 3 3 3 +PIN retry counter : 3 3 2 
-Signature counter : 17 +Signature counter : 
-Signature key ....: B9D7 123A 1FEF B68D B901  937C 4F5A E805 485F 5308 +KDF setting ......: off 
-      created ....: 2020-08-04 21:25:33 +UIF setting ......: Sign=off Decrypt=off Auth=off 
-Encryption key....: 57E6 DB7D 7A1C 5CA8 5373  C448 499C 2669 B5F5 7A76 +Signature key ....: 2C08 2445 CDFB 72DE CD65  0350 610E D9AE E553 353F 
-      created ....: 2020-08-04 21:25:33 +      created ....: 2024-01-03 21:17:32 
-Authentication key: 40CB FA55 DC16 F513 B5F8  7F9C 79BA 5416 C05A DFEB +Encryption key....: 9533 C548 589F F00B 8FFF  C93B B5E5 4345 BDA2 92A0 
-      created ....: 2020-08-04 21:25:33 +      created ....: 2024-01-03 21:17:32 
-General key info..: [none+Authentication key: D5AF 3627 1220 7A2A 54BD  6C47 C72E 74B8 1A5C 4549 
- +      created ....: 2024-01-03 21:17:32 
-gpg/card> </code>+General key info..:  
 +pub  ed25519/610ED9AEE553353F 2024-01-03 Django (Bastard Operator from Hell [BOfH]) <django@nausch.org> 
 +sec>  ed25519/610ED9AEE553353F  created: 2024-01-03  expires: never      
 +                                card-no: FFFE 43243711 
 +ssb>  ed25519/C72E74B81A5C4549  created: 2024-01-03  expires: never      
 +                                card-no: FFFE 43243711 
 +ssb cv25519/B5E54345BDA292A0  created: 2024-01-03  expires: never      
 +                                card-no: FFFE 43243711 
 +</code>
  
    gpg/card> admin    gpg/card> admin
Zeile 667: Zeile 677:
  
 === change-pin === === change-pin ===
-<WRAP center round alert 95%>+<WRAP center round alert 90%>
 **WICHTIG**: **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**. 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 680: 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. 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! 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 765: Zeile 775:
  
 gpg/card> quit</code> 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]
 +      2C082445CDFB72DECD650350610ED9AEE553353F
 +      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]
 +      2C082445CDFB72DECD650350610ED9AEE553353F
 +      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]
 +      2C082445CDFB72DECD650350610ED9AEE553353F
 +      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 ===  === Verschlüsseln und entschlüsseln === 
Zeile 780: Zeile 909:
 PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/" PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
 LOGO=archlinux-logo"</code> LOGO=archlinux-logo"</code>
-  - Nun verschlüsseln wir dieses Textdokument: <code> $ gpg2 -o testdatei.txt.pgp -a -r secmail@mailserver.guru -e testdatei.txt</code> <code>gpg: BF1EA3F703203D8A: There is no assurance this key belongs to the named user +  - Nun verschlüsseln wir dieses Textdokument: <code> $ gpg2 -o testdatei.txt.pgp -a -r django@nausch.org -e testdatei.txt</code>  Wir haben also nun zwei Dokumente auf der Platte liegen. <code> $ ll testdatei.txt*</code><code>-rw-r--r-- 1 django django 382 Jun  3 22:35 testdatei.txt 
-sub  cv25519/BF1EA3F703203D8A 2018-11-27 Django aka [BOfH] (Bastard Operator from Hell) <secmail@mailserver.guru> +-rw-r--r-- 1 django django 581 Jun  3 22:35 testdatei.txt.pgp</code>Die Datei **testdatei.txt.pgp** können wir nun soweit nicht mehr lesen.<code> $ cat testdatei.txt.pgp</code><code>-----BEGIN PGP MESSAGE-----
- Primary key fingerprint: 3E61 A503 47B5 2382 4132  EC06 9308 FC78 3868 63AC +
-      Subkey fingerprint: FB2B D8AD 4660 EADE 0108  852D BF1E A3F7 0320 3D8A +
- +
-It is NOT certain that the key belongs to the person named +
-in the user ID.  If you *really* know what you are doing, +
-you may answer the next question with yes. +
- +
-Use this key anyway? (y/N)</code> Wir haben also nun zwei Dokumente auf der Platte liegen. <code> $ ll testdatei.txt*</code><code>-rw-r--r-- 1 django users 265  4. Aug 20:02 testdatei.txt +
--rw-r--r-- 1 django users 525  4. Aug 20:23 testdatei.txt.pgp</code>Die Datei **testdatei.txt.pgp** können wir nun soweit nicht mehr lesen.<code> $ cat testdatei.txt.pgp</code><code>-----BEGIN PGP MESSAGE-----+
  
 hF4Dvx6j9wMgPYoSAQdAhvFZiNZWBjduajM7OWUr2yM2KC9jfzgvd0SEHael4zUw hF4Dvx6j9wMgPYoSAQdAhvFZiNZWBjduajM7OWUr2yM2KC9jfzgvd0SEHael4zUw
Zeile 802: Zeile 922:
 =9ebq =9ebq
 -----END PGP MESSAGE-----</code> -----END PGP MESSAGE-----</code>
-  - Nun entschlüsseln wir unser Dokument wieder.<code> $ gpg2 --decrypt testdatei.txt.pgp > testdatei-entschlüsselt.txt</code><code>gpg: encrypted with 256-bit ECDH key, ID BF1EA3F703203D8A, created 2018-11-27 +  - Nun entschlüsseln wir unser Dokument wieder.<code> $ gpg2 --decrypt testdatei.txt.pgp > testdatei-entschlüsselt.txt</code><code>gpg: encrypted with cv25519 key, ID B5E54345BDA292A0, created 2024-01-03 
-      "Django aka [BOfH] (Bastard Operator from Hell) <secmail@mailserver.guru>"</code> {{ :suse:nitrokey:nitrokey-start-suse-01.png?direct&350 |Bild: Bildschirmhardcopy der gpg-keyentry Abfrage}} Den Inhalt dieser Datei können wir nun nach erfolgter Entschlüsselung natürlich wieder lesen.<code> $ cat testdatei-entschlüsselt.txt</code><code> +      "Django (Bastard Operator from Hell [BOfH]) <django@nausch.org>"</code> {{ :suse:nitrokey:nitrokey-start-suse-01.png?direct&350 |Bild: Bildschirmhardcopy der gpg-keyentry Abfrage}} Den Inhalt dieser Datei können wir nun nach erfolgter Entschlüsselung natürlich wieder lesen.<code> $ cat testdatei-entschlüsselt.txt</code><code>>NAME="Arch Linux
-NAME="openSUSE Leap+PRETTY_NAME="Arch Linux
-VERSION="15.2+ID=arch 
-ID="opensuse-leap" +BUILD_ID=rolling 
-ID_LIKE="suse opensuse" +ANSI_COLOR="38;2;23;147;209
-VERSION_ID="15.2" +HOME_URL="https://archlinux.org/
-PRETTY_NAME="openSUSE Leap 15.2+DOCUMENTATION_URL="https://wiki.archlinux.org/
-ANSI_COLOR="0;32+SUPPORT_URL="https://bbs.archlinux.org/
-CPE_NAME="cpe:/o:opensuse:leap:15.2+BUG_REPORT_URL="https://gitlab.archlinux.org/groups/archlinux/-/issues
-BUG_REPORT_URL="https://bugs.opensuse.org" +PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/" 
-HOME_URL="https://www.opensuse.org/</code>+LOGO=archlinux-logo"</code>
  
 === Signieren ===  === Signieren === 
 Nun werden wir kurz einmal testen, ob wir mit Hilfe der Hardware-Schlüssel-Karte eine Datei signieren und die Signatur auch wieder prüfen können. Nun werden wir kurz einmal testen, ob wir mit Hilfe der Hardware-Schlüssel-Karte eine Datei signieren und die Signatur auch wieder prüfen können.
  
-  - Zunächst Wir legen uns erst einmal ein beliebiges Testdokument an. <code> $ date > textdatei.txt</code> Die Datei hat nun folgenden Inhalt:<code> $ cat textdatei.txt</code><code>Di 4. Aug 20:34:27 CEST 2020</code> +  - Zunächst Wir legen uns erst einmal ein beliebiges Testdokument an. <code> $ date > textdatei.txt</code> Die Datei hat nun folgenden Inhalt:<code> $ cat textdatei.txt</code><code>Mon Jun  3 10:49:04 PM CEST 2024</code> 
-  - Nun signieren wir dieses Textdokument: <code> $ gpg --sign textdatei.txt</code> {{ :suse:nitrokey:nitrokey-start-suse-01.png?direct&350 |Bild: Bildschirmhardcopy der gpg-keyentry Abfrage}} Wir haben also nun zwei Dokumente auf der Platte liegen. <code> $ ll textdatei.txt*</code><code>-rw-r--r-- 1 django users  29  4. Aug 20:57 textdatei.txt +  - Nun signieren wir dieses Textdokument: <code> $ gpg --sign textdatei.txt</code> {{ :nitrokey:arch:thunderbird_008.png?nolink&300 |Bild: Bildschirmhardcopy der gpg-keyentry Abfrage}} Wir haben also nun zwei Dokumente auf der Platte liegen. <code> $ ll textdatei.txt*</code><code>-rw-r--r-- 1 django django  33 Jun  3 23:19 textdatei.txt 
--rw-r--r-- 1 django users 177  4. Aug 20:57 textdatei.txt.gpg</code>Die Datei **textdatei.txt.pgp** können wir nun soweit nicht mehr lesen.<code> $ cat textdatei.txt.gpg</code><code>������!6��O�EF���5I�%�%)�%��z%%��W�d*��)8��+X��[+8��yF\�,b �b�,v�K�ݷ*79��a����2���S&�����Gq��}���o������u��Ȗ_�Wu_����&����y��G�P�z����ۙ��(;xn��4</code> Die Datei beinhaltet die Signatur zu unserer Datei, also entsprechender Zahlensalat.<code> $ file textdatei.txt.gpg</code><code>textdatei.txt.gpg: data</code>  Dieses Vorgehen macht jedoch nur Sinn, wenn mit der Option ''%%--%%encrypt'' gleichzeitig die Datei verschlüsselt werden soll. Wir signieren nun die Datei mit dem privat-key und verschlüsseln die Datei mit dem public-key unseres eigenen Schlüssels auf dem Nitrokey Start. So kann die Datei nur von uns selbst wieder aufgemacht werden, sofern man im Besitz des Nitrokey Start und der zugehörigen PIN ist!<code> $ gpg: BF1EA3F703203D8A: There is no assurance this key belongs to the named user +-rw-r--r-- 1 django django 182 Jun  3 23:19 textdatei.txt.gpg</code>Die Datei **textdatei.txt.pgp** können wir nun soweit nicht mehr lesen.<code> $ cat textdatei.txt.gpg</code><code>������!6��O�EF���5I�%�%)�%��z%%��W�d*��)8��+X��[+8��yF\�,b �b�,v�K�ݷ*79��a����2���S&�����Gq��}���o������u��Ȗ_�Wu_����&����y��G�P�z����ۙ��(;xn��4</code> Die Datei beinhaltet die Signatur zu unserer Datei, also entsprechender Zahlensalat.<code> $ file textdatei.txt.gpg</code><code>textdatei.txt.gpg: data</code>  Dieses Vorgehen macht jedoch nur Sinn, wenn mit der Option **''%%--%%encrypt''** gleichzeitig die Datei verschlüsselt werden soll. Wir signieren nun die Datei mit dem privat-key und verschlüsseln die Datei mit dem public-key unseres eigenen Schlüssels auf dem Nitrokey Start. So kann die Datei nur von uns selbst wieder aufgemacht werden, sofern man im Besitz des Nitrokey Start und der zugehörigen PIN ist!<code> $ gpg --encrypt --sign -r django@nausch.org textdatei.txt</code> {{ :nitrokey:arch:thunderbird_008.png?nolink&300 |Bild: Bildschirmhardcopy der gpg-keyentry Abfrage}} Wir haben nunmehr eine neue verschlüsselte und signierte Datei.<code> $ file textdatei.txt.gpg</code> 
-sub  cv25519/BF1EA3F703203D8A 2018-11-27 Django aka [BOfH] (Bastard Operator from Hell) <secmail@mailserver.guru> +  - Im nun folgendem Beispiel signieren wir unsere Datei und konvertieren sie so, dass wir sie einfach per eMail verschicken können. Hierzu nutzen wir die Option **''%%--%%armor''**.<code> $ gpg --sign --armor textdatei.txt</code> {{ :nitrokey:arch:thunderbird_008.png?nolink&300 |Bild: Bildschirmhardcopy der gpg-keyentry Abfrage}} Nun können wir uns die erstellte signierte Datei ansehen. <code> $ cat textdatei.txt.asc</code><code>-----BEGIN PGP MESSAGE-----
- Primary key fingerprint: 3E61 A503 47B5 2382 4132  EC06 9308 FC78 3868 63AC +
-      Subkey fingerprint: FB2B D8AD 4660 EADE 0108  852D BF1E A3F7 0320 3D8A +
- +
-It is NOT certain that the key belongs to the person named +
-in the user ID If you *really* know what you are doing, +
-you may answer the next question with yes. +
- +
-Use this key anyway? (y/N)</code> {{ :suse:nitrokey:nitrokey-start-suse-01.png?direct&350 |Bild: Bildschirmhardcopy der gpg-keyentry Abfrage}} Wir haben nunmehr eine neue verschlüsselte und signierte Datei.<code> $ file textdatei.txt.gpg</code>Im nun folgendem Beispiel signieren wir unsere Datei und konvertieren sie so, dass wir sie einfach per eMail verschicken können. Hierzu nutzen wir die Option ''%%--%%armor''.<code> $ gpg --sign --armor textdatei.txt</code> {{ :suse:nitrokey:nitrokey-start-suse-01.png?direct&350 |Bild: Bildschirmhardcopy der gpg-keyentry Abfrage}} Nun können wir uns die erstellte signierte Datei ansehen. <code> $ cat textdatei.txt.asc</code><code>-----BEGIN PGP MESSAGE-----+
  
-owGbwMvMwCE2meNPhUVG8hrGNQZJvCWpFSUpiSWpmXolFSXxmhs2uWQqmOgpOJam +owGbwMvMwCGWyHdz3dNgU3vGNSZJvCWpFSUpiSWpmXolFSVp8QnSIaWpCl6leQoK 
-KxgZWJmaWxkZKzi7BocAeUYGXB2lLAxiHAyyYoosdolLmd23Kjc5Gr1hg5nIygQy +JgoGFlbG5laG5goBvgrOrsEhCkYGRiZcHaUsDGIcDLJiiiw6HCquZ38X3TubyhwA 
-gYGLUwAmon6JkWHXDc+AWrfjeyokWNeoLrqruH9DfsNrPi7hRWdz9smcem/MyPCy +M5WVCWQKAxenAEzEYwXDPw0/ninLX283e//2sv+yjg/r9/lOPLKmI9zccMYltuJT 
-4YL17MjAT/Vm/NVllzI/Hphm4Kptt2rRI9FMm3LN97wA +FxUZ/pfN2Ddbnan3h5nysoDTVdK2k//GOnTeubN30pcUhwOynxkA 
-=BXv/ +=UkKj 
------END PGP MESSAGE-----</code> Soll die Originaldatei zusammen mit der Signatur in der erzeugten Datei stehen, so verwendet man die Option ''%%–-%%clearsign''.<code> $ gpg --clearsign --armor textdatei.txt</code> {{ :suse:nitrokey:nitrokey-start-suse-01.png?direct&350 |Bild: Bildschirmhardcopy der gpg-keyentry Abfrage}} Die erzeugte Testdatei.asc enthält dann sowohl den Originaltext, wie auch die Dateisignatur: <code> $ cat textdatei.txt.asc</code><code>-----BEGIN PGP SIGNED MESSAGE-----+-----END PGP MESSAGE-----</code> Soll die Originaldatei zusammen mit der Signatur in der erzeugten Datei stehen, so verwendet man die Option **''%%–-%%clearsign''**.<code> $ gpg --clearsign --armor textdatei.txt</code> {{ :nitrokey:arch:thunderbird_008.png?nolink&300 |Bild: Bildschirmhardcopy der gpg-keyentry Abfrage}} Die erzeugte Testdatei.asc enthält dann sowohl den Originaltext, wie auch die Dateisignatur: <code> $ cat textdatei.txt.asc</code><code>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA256 Hash: SHA256
  
-Di 4. Aug 20:57:23 CEST 2020+Tue Jun  08:37:17 PM CEST 2024
 -----BEGIN PGP SIGNATURE----- -----BEGIN PGP SIGNATURE-----
  
-iHUEARYIAB0WIQQ+YaUDR7UjgkEy7AaTCPx4OGhjrAUCXymw/AAKCRCTCPx4OGhj +iHUEARYIAB0WIQQsCCRFzfty3s1lA1BhDtmu5VM1PwUCZl9gfwAKCRBhDtmu5VM1 
-rBwEAP0dZtolkQCmLYuccDEjTWVK/Pa8we40nHyJ+SZgmxVlcQD/YT/H/X25TADr +P3TcAQDTPio3kyse3A6orXygqr5hP9etL25Lpq6ySzTjIDRcKgEA3qT4h/I6zm+
-eR1Z/bLn3y61laBbGLhOaElPSNtJfQ0+a1EoA/Azg/l0zEMxZlj2yzK7Omxczw4
-=76rm +=34mx 
------END PGP SIGNATURE-----</code> Mit ''gpg %%-–%%verify'' können wir die Signatur der Datei überprüfen:<code> $ gpg --verify textdatei.txt.asc</code><code>gpg: Signature made Di 04 Aug 2020 21:03:24 CEST +-----END PGP SIGNATURE-----</code> Mit der Option **''%%-–%%verify''** können wir die Signatur der Datei überprüfen:<code> $ gpg --verify textdatei.txt.asc</code><code>gpg: Signature made Tue 04 Jun 2024 08:44:15 PM CEST 
-gpg:                using EDDSA key 3E61A50347B523824132EC069308FC78386863AC +gpg:                using EDDSA key 2C082445CDFB72DECD650350610ED9AEE553353F 
-gpg: Good signature from "Django aka [BOfH] (Bastard Operator from Hell) <secmail@mailserver.guru>" [unknown] +gpg: Good signature from "Django (Bastard Operator from Hell [BOfH]) <django@nausch.org>" [ultimate
-gpg: WARNING: This key is not certified with a trusted signature! +gpg: WARNING: not a detached signature; file 'textdatei.txt' was NOT verified!</code> Wir verändern nun zu Testzwecken den Inhalt der Testdatei, in dem wir den Text verfälschen. (**''2099''** als Jahresangabe) <code> $ vim textdatei.txt.asc</code><code>-----BEGIN PGP SIGNED MESSAGE-----
-gpg:          There is no indication that the signature belongs to the owner. +
-Primary key fingerprint: 3E61 A503 47B5 2382 4132  EC06 9308 FC78 3868 63AC +
-gpg: WARNING: not a detached signature; file 'textdatei.txt' was NOT verified!Wir verändern nun zu Testzwecken den Inhalt der Testdatei, in dem wir den Text verfälschen. (**''2099''** als Jahresangabe) <code> $ vim textdatei.txt.asc</code><code>-----BEGIN PGP SIGNED MESSAGE-----+
 Hash: SHA256 Hash: SHA256
  
-Di 4. Aug 20:57:23 CEST 2099+Tue Jun  08:37:17 PM CEST 2099
 -----BEGIN PGP SIGNATURE----- -----BEGIN PGP SIGNATURE-----
  
-iHUEARYIAB0WIQQ+YaUDR7UjgkEy7AaTCPx4OGhjrAUCXymw/AAKCRCTCPx4OGhj +iHUEARYIAB0WIQQsCCRFzfty3s1lA1BhDtmu5VM1PwUCZl9gfwAKCRBhDtmu5VM1 
-rBwEAP0dZtolkQCmLYuccDEjTWVK/Pa8we40nHyJ+SZgmxVlcQD/YT/H/X25TADr +P3TcAQDTPio3kyse3A6orXygqr5hP9etL25Lpq6ySzTjIDRcKgEA3qT4h/I6zm+
-eR1Z/bLn3y61laBbGLhOaElPSNtJfQ0+a1EoA/Azg/l0zEMxZlj2yzK7Omxczw4
-=76rm +=34mx 
------END PGP SIGNATURE-----</code>Nun überprüfen wir die Signatur der Testdatei, was natürlich postwendend als **BAD signature** angeprangert wird. <code> $ gpg --verify textdatei.txt.asc</code><code>gpg: Signature made Di 04 Aug 2020 21:03:24 CEST +-----END PGP SIGNATURE-----</code>Nun überprüfen wir die Signatur der Testdatei, was natürlich postwendend als **BAD signature** angeprangert wird. <code> $ gpg --verify textdatei.txt.asc</code><code>gpg: Signature made Tue 04 Jun 2024 08:44:15 PM CEST 
-gpg:                using EDDSA key 3E61A50347B523824132EC069308FC78386863AC +gpg:                using EDDSA key 2C082445CDFB72DECD650350610ED9AEE553353F 
-gpg: BAD signature from "Django aka [BOfH] (Bastard Operator from Hell) <secmail@mailserver.guru>" [unknown]</code>+gpg: BAD signature from "Django (Bastard Operator from Hell [BOfH]) <django@nausch.org>" [ultimate]</code>
  
 ==== Nitrokey Start und Thunderbird ====  ==== Nitrokey Start und Thunderbird ==== 
Zeile 910: Zeile 1019:
 {{ :nitrokey:arch:thunderbird_007.png?nolink&874 |Bild: Menüfenster der Thunderbird individuellen Einstellungen}} {{ :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 ==== 
 +
 +<WRAP center round important 90%>
 +Ob man in Zeiten von Überwachungsphantasten in Unternehmen und vor allem auch bei einer NSA oder BND, noch **[[http://www.golem.de/news/elliptische-kurven-die-herkunft-der-nist-kurven-1309-101567.html|RSA-Schlüssel]]** einsetzen kann und mag, muss natürlich jeder verantwortungsbewusste Administrator für sich selbst entscheiden. 
 +
 +Der Sicherheitsguru Bruce Schneier hat in seinem **[[https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929|Blog]]** hierzu eine eindeutige Aussage getätigt: 
 +
 +<wrap em>//"On the crypto bits in your guardian piece, I found especially interesting that you suggest classic discrete log crypto over ecc. I want to ask if you could elaborate more on that." __I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry.__//</wrap>
 +
 +**[[https://de.wikipedia.org/wiki/Curve25519|EED25519]]** ist ein Elliptic Curve Signature Schema, welches beste Sicherheit bei vertretbaren Aufwand verspricht, als ECDSA oder DSA dies der Fall ist. Detaillierte Informationen zur **[[https://martin.kleppmann.com/papers/curve25519.pdf|Implementierung von Curve25519/X25519: Ein Tutorial zur elliptischen Kurvenkryptografie]]** finden sich in dem verlinktem Dokument von [[https://martin.kleppmann.com/|Martin Kleppmann]]. Zur Auswahl sicherer kryptografischer Kurven bei der //Elliptic-Curve Cryptography// findet man auf der Seite [[https://safecurves.cr.yp.to/|hier]] hilfreiche Erklärungen und eine Gegenüberstellung der möglichen verschiedenen Alternativen.
 +</WRAP>
 +
 +Auf RSA Schlüssel muss man aber nicht mehr zwingend zurückgreifen, stehen doch aktuellere und zeitgemässere Cipher, MACs, Schlüssel Typen und Key Exchange Algorithmen zur Verfügung. Als Alternative zu einem RSA-Keys haben wir uns bereits im Abschnitt **[[start#ed25519-schluessel_generieren|Nitrokey Start und GnuPG - ED25519-Schlüssel generieren]]** Schlüsselmaterial auf Basis elliptischer Kurven erstellt, unter anderem auch einen //**Authentication Key**// erstellt. 
 +Diesen Schlüssel wollen wir nun auch zur Serveradministration verwenden.
 +
 +=== SSH Client vorbereiten ===
 +Damit wir beim Verbindungsaufbau auf den Authentication Key zugreifen können, müssen wir unseren Client entsprechend vorbereiten.
 +
 +In der Konfigurationsdatei //**~/.gnupg/gpg.conf**// setzen wir als erstes die Option ''**use-agent**''.
 +   $ vim ~/.gnupg/gpg.conf
 +<file bash ~/.gnupg/gpg.conf># File re-created by pEp
 +# See backup in '/home/django/.gnupg/gpg.conf.1.pep.bkp'
 + 
 +# File re-created by pEp
 +# See backup in '/home/django/.gnupg/gpg.conf.0.pep.bkp'
 + 
 +# Created by pEpEngine
 +keyserver hkp://keys.gnupg.net
 +cert-digest-algo SHA256
 +no-emit-version 
 +no-comments 
 +personal-cipher-preferences AES AES256 AES192 CAST5
 +personal-digest-preferences SHA256 SHA512 SHA384 SHA224
 +ignore-time-conflict 
 +allow-freeform-uid
 + 
 +# Ansible generated, do not edit manual!
 +# Option use-agent für Authentication Key Nutzung des Nitrokey Start bei SSH
 +use-agent
 +</file>
 +
 +
 +Im nächsten Schritt aktivieren wir die Option ''**enable-ssh-support**'' in der Konfigurationsdatei //**~/.gnupg/gpg-agent.conf
 +**// des GPG-Agenten.
 +   $ vim ~/.gnupg/gpg-agent.conf
 +<file bash ~/.gnupg/gpg-agent.conf># File re-created by pEp                                                                                                                                                                              
 +# See backup in '/home/django/.gnupg/gpg-agent.conf.1.pep.bkp'
 + 
 +# File re-created by pEp
 +# See backup in '/home/django/.gnupg/gpg-agent.conf.0.pep.bkp'
 + 
 +default-cache-ttl 300
 +max-cache-ttl 999999
 + 
 +# Ansible generated, do not edit manual!
 +# SSH-Support activated for gnupg-agent
 +enable-ssh-support
 +</file>
 +
 +Nun werden wir noch die Datei //**~/.bashrc**// erweitern, damit der **SSH_AUTH_SOCK** für den Zugriff des SSH-Schlüssels auf dem Nitrokey Start genutzt werden kann.
 +   $ vim ~/.bashrc
 +<file bash ~/.bashrc># .bashrc
 +
 +# Source global definitions
 +if [ -f /etc/bashrc ]; then
 +        . /etc/bashrc
 +fi
 +
 +# User specific environment
 +PATH="$HOME/.local/bin:$HOME/bin:$PATH"
 +export PATH
 +
 +# Uncomment the following line if you don't like systemctl's auto-paging feature:
 +# export SYSTEMD_PAGER=
 +
 +# User specific aliases and functions
 +
 +# Django : 2024-05-25
 +#          Definition des SSH_AUTH_SOCK für den Zugriff des SSH-Schlüssels auf dem Nitrokey Start
 +unset SSH_AGENT_PID
 +        if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then
 +        export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"
 +fi</file>
 +
 +Damit unsere Änderungen aktiv werden, müssen wir nun zum Schluss noch den **pgp-agent** restarten bzw. einen Neustart des Clients erwirken. Wir entscheiden uns der Einfachheit halber von einen Neustart des Agenten mit Hilfe des Befehls ''**pkill gpg-agent**''.
 +   $ pkill gpg-agent
 +
 +Ein Blick in die Prozessliste zeigt, dass der Agent nicht mehr läuft.
 +   $ ps aux | grep gpg-agent
 +
 +  django    8752  0.0  0.0 215740   820 pts/1    S+   21:56   0:00 grep --color=auto gpg-agent
 +
 +Nun stecken wir unseren Nitrokey Start an den USB-Port und fragen den Kartenstatus ab.
 +   $ gpg2 --card-status
 +<code>Reader ...........: 20A0:4211:FSIJ-1.2.19-43243711:0
 +Application ID ...: D276000124010200FFFE432437110000
 +Application type .: OpenPGP
 +Version ..........: 2.0
 +Manufacturer .....: unmanaged S/N range
 +Serial number ....: 43243711
 +Name of cardholder: Michael Nausch
 +Language prefs ...: de
 +Salutation .......: Mr.
 +URL of public key : [not set]
 +Login data .......: [not set]
 +Signature PIN ....: forced
 +Key attributes ...: ed25519 cv25519 ed25519
 +Max. PIN lengths .: 127 127 127
 +PIN retry counter : 3 3 2
 +Signature counter : 23
 +KDF setting ......: off
 +UIF setting ......: Sign=off Decrypt=off Auth=off
 +Signature key ....: 2C08 2445 CDFB 72DE CD65  0350 610E D9AE E553 353F
 +      created ....: 2024-01-03 21:17:32
 +Encryption key....: 9533 C548 589F F00B 8FFF  C93B B5E5 4345 BDA2 92A0
 +      created ....: 2024-01-03 21:17:32
 +Authentication key: D5AF 3627 1220 7A2A 54BD  6C47 C72E 74B8 1A5C 4549
 +      created ....: 2024-01-03 21:17:32
 +General key info..: pub  ed25519/610ED9AEE553353F 2024-01-03 Django (Bastard Operator from Hell [BOfH]) <django@nausch.org>
 +sec>  ed25519/610ED9AEE553353F  created: 2024-01-03  expires: never     
 +                                card-no: FFFE 43243711
 +ssb>  ed25519/C72E74B81A5C4549  created: 2024-01-03  expires: never     
 +                                card-no: FFFE 43243711
 +ssb>  cv25519/B5E54345BDA292A0  created: 2024-01-03  expires: never     
 +                                card-no: FFFE 43243711
 +</code>
 +
 +Ein erneuter Blick in die Prozessliste zeigt nun den neu gestarteten Agenten.
 +   $ ps aux | grep gpg-agent
 +
 +  django    8766  0.0  0.0 364724   804 ?        Ss   21:57   0:00 gpg-agent --homedir /home/django/.gnupg --use-standard-socket --daemon
 +  django    8853  0.0  0.0 215740   828 pts/1    S+   22:00   0:00 grep --color=auto gpg-agent
 +
 +=== Public-Key des ED25519 SSH exportieren ===
 +Für den Zugriff auf unser Ziel-System mit Hilfe der SSH benötigen wir noch den öffentlichen Schlüssel unseres Authentication Keys, den wir nun exportieren werden.
 +Zunächst besorgen wir uns die betreffende Schlüsselkennung des Authentication Keys, genauer gesagt die 4 letzten Zahlenreihen des nachfolgenden Aufrufs.
 +   $ gpg2 --card-status | grep Authentication\ key
 +
 +  Authentication key: D5AF 3627 1220 7A2A 54BD  6C47 C72E 74B8 1A5C 4549
 +In diesem Konfigurationsbeispiel ist die Schlüssel-ID des Autentication Keys also die Nummer ''**C72E74B81A5C4549**''.
 +
 +Nun exportieren wir den öffentlichen Schlüssel und schreiben diesen in eine separate Datei.
 +   $ gpg2 --export-ssh-key C72E74B81A5C4549 >> ~/.ssh/C72E74B81A5C4549.pub
 +
 +Der Öffentliche Schlüssel in diesen Konfigurationsbeispiel lautet also:
 +   $ cat ~/.ssh/C72E74B81A5C4549.pub
 +
 +  ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHMD4OSvbbTRAs88C5jQeUX7HOR0TYd+EIQLcKmGCBll openpgp:0x1A5C4549
 +
 +Diesen Schlüssel kopieren wir nun auf das entsprechende Zielsystem an Ort und Stelle ''**~/.ssh/authorized_keys**''.
 +   $ scp ~/.ssh/C72E74B81A5C4549.pub zielhost.dmz.nausch.org: && ssh zielhost.dmz.nausch.org 'cat authorized_keys >> ~/.ssh/authorized_keys'
 +
 +=== SSH-Verbindung aufbauen ===
 +Nun können wir wie gewohnt eine Verbindung zu unserem entfernten System aufbauen, sofern der GPG-Agent am laufen ist. Wir können dazu entweder erst einmal abfragen, ob dieser gestartet wurde, mit Hilfe des folgenden Aufrufs:
 +   $ ps -aux | grep gpg-agent
 +
 +  django      1430  0.0  0.0 376092  3636 ?        SLsl 20:32   0:00 /usr/bin/gpg-agent --supervised
 +
 +Oder wir fragen einfach den Karten-Status ab, was unweigerlich den Neustart des GPG-Agenten nach sich zieht.
 +   $ gpg2 --card-status
 +
 +Nun können wir die gewünschte Verbindung zum Zielsystem aufbauen.
 +   $ ssh zielhost.dmz.nausch.org
 +
 +Da der SSH-Key zur Authentication nicht im Dateisystem liegt, sondern auf der SmartCard des Nitrokey werden wir nun nach der User-PIN gefragt, damit auf den privaten Schlüssel der Karte zugegriffen werden kann.
 +
 +{{ :nitrokey:arch:ssh_001.png?nolink&280 |Bild: PIN Abfrage beim Zugriff auf den Authentication Key der SmartCard des Nitrokeys}}
 +
 +Der entsperrte Schlüssel der SmartCard des Nitrokey Start wird nun im Speicher gehalten solange wir den USB-Hardwareschlüssel nicht abziehen. 
 +
 +<WRAP center round important 90%>
 +**WICHTIG:** \\
 +Da wir den Schlüssel **__nicht__** aus einer Datei geladen hatten, können wir diese auch nicht mit Hilfe von ''**ssh-add**'' wieder entladen! Wollen wir verhindern, dass auf den im Speicher vorgehaltenen Schlüssel zugegriffen wird, müssen wir manuell den GPG-Agenten beenden.
 +   $ pkill gpg-agent
 +
 +</WRAP>
 +
 +Anschliessend lassen sich Verbindungen zu unseren Remote-Systemen erst wieder aufbauen, wenn der GPG-Agent geladen und die Karte nach Eingabe der PIN entsperrt wurde!
 +
 +==== Nitrokey Start und Git/Gitlab ====
 +
 +<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>
 +
 +=== GPG Key-ID ermitteln ===
 +Zunächst holen wir uns die Key-ID unseres Users.
 +   $ gpg2 -K
 +<code>/home/django/.gnupg/pubring.kbx
 +-------------------------------
 +sec>  ed25519 2024-01-03 [SC]
 +      2C082445CDFB72DECD650350610ED9AEE553353F
 +      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>
 +
 +Die Key-ID unseres Adminusers **''<django@nausch.org>''** lautet also **''610ED9AEE553353F''** (die letzten 16 Stellen reichen hierfür aus).
 +
 +=== Git konfigurieren ===
 +
 +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!
 +
 +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%%->"%%''**. 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>
 +20:13 $ git commit -S -m "AIDE 19.0 - auf konfigurierbaren Timer umgestellt"
 +[AIDE-19.0 4c03596] AIDE 19.0 - auf konfigurierbaren Timer umgestellt
 + 6 files changed, 11 insertions(+), 3 deletions(-)
 +</pre>
 +</html>
 +
 +=== Unterschrift von Commits anzeigen ===
 +Zum Anzeigen der Signaturen verwenden wir die Option **''%%--%%show-signature''** beim Befehlsaufruf **''git log''**.
 +<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(25, 100, 5)">✔</font>
 +21:01 $ git log --show-signature -1
 +<font style="color: rgb(196, 160, 0)">commit 4c035960c07062227aa9e2a4832053e557085484 </font></font><font style="color: rgb(6, 152, 153)">HEAD </font>-> <font style="color: rgb(78, 154, 6">AIDE-19.0</font>, <font style="color: rgb(204, 0, 0)">origin/AIDE-19.0</font>)
 +<font style="color: rgb(6, 152, 153)">gpg: Signature made Sun 13 Apr 2025 08:14:51 PM CEST
 +gpg:                using EDDSA key 2C082445CDFB72DECD650350610ED9AEE553353F
 +gpg: Good signature from "Django (Bastard Operator from Hell [BOfH]) <django@nausch.org>" [ultimate]</font>
 +Author: django <django@nausch.org>
 +Date:   Sun Apr 13 20:14:51 2025 +0200
 +
 +    AIDE 19.0 - auf konfigurierbaren Timer umgestellt
 +</pre>
 +</html>
 +
 +Optional kann man mit der Option **''%G''** beim Aufruf von **''git log''** die Signaturen aller commits prüfen.
 +<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(25, 100, 5)">✔</font>
 +21:18 $ git log --pretty="format:%h %G? %aN  %s"
 +4c03596 G django  AIDE 19.0 - auf konfigurierbaren Timer umgestellt
 +8f04a39 N Django BOfH  Merge branch 'HIDS0325Logging' into 'main'
 +cdff19c N django  Logging nur noch 1x im syslog
 +</pre>
 +</html>
 +
 +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>
 + 
  
  
  • nitrokey/arch/start.1717446305.txt.gz
  • Zuletzt geändert: 03.06.2024 20:25.
  • von django