PKI: Verwenden eines HSM
Um den privaten Schlüssel einer RootCA sicher abzulegen kann man auch sog. „HSM“ (= Hardware Security Module) verwenden. Es gibt verschiedene Modelle von HSMs, manche haben die Größe eines Servers und sind für eine hohe Zugriffsanzahl ausgelegt, andere haben die Größe eines USB-Sticks. Für diesen Artikel habe ich eine Teststellung eines YubiHSM 2 | Hardware Security Module | USB-A (yubico.com) verwendet. Der YubiHSM kann entweder direkt in der CA verwendet werden oder es kann ein dedizierter Server mit dem Stick im Netzwerk bereitgestellt werden.
In diesem Artikel soll es zwei Szenarien geben:
- Das HSM soll direkt an der RootCA verwendet werden
- Das HSM soll zentral im Netzwerk bereitgestellt werden
- für die RootCA
- für die SubCA („IssuingCA“)
Hier ein paar Bilder zum YubiHSM:
Vorbereitung
Um die Szenarien darstellen zu können braucht es also mindestens folgende Server:
- 1x Domain Controller (= „WSDC01“)
- 1x RootCA (= „WSCAR1“)
- 1x SubCA (= „WSCAS1“)
- 1x HSM-Server (= „WSHSM1“)
Aus Mangel an genügend Hardware wird das Ganze virtuell dargestellt. Dabei stößt man auf das Problem, dass es leider nicht möglich ist, USB-Sticks in Hyper-V Umgebungen dauerhaft an VMs durchzureichen. Daher wird hierfür „VMware Workstation“ verwendet.
YubiHSM2 Treiber
Zuerst muss der Treiber für das YubiHSM2-Modul auf dem Server, der RootCA ist (also in meinem Fall „WSCAR1“) heruntergeladen werden. Diese sind auf der Herstellerseite erhältlich: Releases (yubico.com) . Anschließend natürlich installieren 😉 Dabei bin ich in dieser Reihenfolge vorgegangen:
YubiHSM Key Storage Provider
YubiHSM Connector
YubiHSM Shell (x64)
Szenario 1 – HSM an der RootCA
Nach der Treiber-Installation habe ich den Server neugestartet, um sicherzugehen, dass alle Treiber sauber geladen werden und zur Verfügung stehen.
Anschluss des HSM-Moduls am Server
Da ich mittels VMware Workstation (auf Windows 11) die Test-VMs laufen habe, erscheint ein Fenster, welches abfragt, wohin das USB-Gerät verbunden werden soll. Zur Auswahl stehen:
- Host (also die Hardware)
- Auflistung der VMs, wie bspw. mein „WSCAR1“
Da das HSM-Modul für die RootCA verwendet werden soll, wähle ich diese aus. Es erscheint in der Statusleiste des aktiven VMware Workstation Fensters ein USB-Symbol, bei welchem optional die Farbe geändert werden kann (rot = wichtiges Gerät 😉). Zudem wird das Modul im Geräte-Manager innerhalb der VM ordentlich aufgelistet.
Erstkonfiguration des HSM-Moduls
Für die Konfiguration muss der Connector-Dienst laufen. Das lässt sich durch aufrufen der URL „http://localhost:12345“ prüfen. Die restliche Konfiguration wurde entsprechend der Hersteller-Anleitung (yubico.com) durchgeführt:
- Im Pfad der Setup-Dateien wird das „YubiHSM-Setup“ mit dem Argument „ksp“ gestartet und mit dem Standardkennwort „password“ authentifiziert.
- Die Abfrage, ob man RSA-Decryption-Funktionalität haben möchte, wird mit „n“ verneint.
- Anschließend wird die Zahl „1“ eingetippt, da nur für eine Domäne der HSM verwendet werden soll.
- Jetzt wird der sog. „Wrap-Key“ erstellt. Hier kann man entweder einen „Slot“ wählen oder durch Eingabe der „0“ wird automatisch der nächste freie „Slot“ verwendet. In meinem Fall war das dann der mit der ID „0x2261“.
- Im nächsten Schritt wählt man die Anzahl der Shares in die der „Wrap-Key“ aufgeteilt werden soll, sowie die Anzahl der benötigten Shares für ein Verwendung des „Wrap-Key“. In meinem Bespiel habe ich
- Anzahl der Shares: 3
- Anzahl der anwesenden Shares: 2
- Jetzt wird für jeden der einzelnen Shares-Besitzer (= „Custodian“) ein Teil angezeigt, welcher sicher verwahrt werden soll und möglichst nicht den anderen Share-Besitzern bekannt sein sollte. Die Textdatei mit allein drei Shares ist nur für den Test bzw. diesen Artikel zur Übersicht.
- Nun wird ein „Application Authentication Key“ erzeugt, welcher für den Zugriff vom „Key Storage Provider“ zum HSM benötigt wird. Hier kann wieder entweder ein „Slot“ angegeben oder mit der „0“ automatisch der nächste freie (in meinem Fall „0xfa63“) verwendet werden.
- Für diesen Key wird jetzt ein Kennwort (mindestens 8 Zeichen!) vergeben. Dieses hier eintippen und sicher verwahren.
- Optional kann nun noch ein „Audit Authentication Key“ angelegt werden. Die Empfehlung ist, dass dies auch gemacht wird, sodass jederzeit die Möglichkeit besteht die Logfiles (die letzten 62 Aktionen) zu lesen, sowie das Logfile zurückzusetzen. Der Ablauf ist ähnlich:
- Zuerst einen „Slot“ angeben oder per „0“ automatisch wählen lassen. In meinem Fall „0x1a9c“.
- Kennwort (mindestens 8 Zeichen) festlegen, welches natürlich nicht dasselbe ist, wie für den „Application Authentication Key“ 😉
- Fertig!
Verifizierung des Setups
Nach Abschluss der Ersteinrichtung des HSM empfiehlt es sich, diese noch kurz zu Prüfen. Auch hier gibt es eine Hersteller-Anleitung (yubico.com), die folgende kurze Schritte umfasst:
- Starten der YubiHSM-Shell (lag bei mir nach der oben durchgeführten Installation aus Kapitel „YubiHSM Shell (x64)„) im Pfad „
C:\Program Files\Yubico\YubiHSM Shell\bin
“ . - Mit dem Befehl „
connect
“ eine Verbindung zum eingesteckten HSM herstellen - Anschließend mit dem Befehl „
session open NUMBER
“ eine Verbindung zum „Slot“ herstellen, den man bei der Ersteinrichtung verwendet hat. In meinem Fall war das „0xfa63“, was als Dezimalzahl die „64099“ ist. - Es wird dann das Passwort für den „Application Authentication Key“ benötigt – Ich hatte mich das erste Mal vertippt 🙈
- Eine kurze Auflistung aller Keys für diesen Slot werden mit dem Befehl „
list objects 0
“ aufgelistet:- Audit Authentication Key
- Wrap Key
- Application Authentication Key
- Optional kann mit dem Befehl „
get objectinfo 0 NUMBER authentication-key
“ (wobei „NUMBER“ der verwendete Application Authentication Key sein muss; das wäre in meinem Fall „0xfa63“) noch genauere Details anzeigen. Diesen Schritt habe ich nicht durchgeführt. - Zum Verlassen der Überprüfung einfach „
quit
“ eintippen und <ENTER> drücken.
RootCA – Vorbereitung der Registry & Connector-Configfile
Als nächstes müssen in der Registry ein paar Werte eingetragen bzw. angepasst werden. Dazu den Registrierungseditor starten (bspw. über das Startmenü und der Eingabe von „regedit“).
- Schritt: Den Pfad „
HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM
“ finden - Im Schlüssel „AuthKeysetID“ den oben erstellten „Application Authentication Key“ eintragen – in meinem Fall „0xfa63“
- Im Schlüssel „AuthKeysetPassword“ das festgelegte Passwort eintragen
- URL ggfs. anpassen – in meinem Fall bleibt die localhost IP, da die Connector-Software auf dem selbem Server läuft.
Anschließend im Pfad C:\programdata\yubiHSM\ das Configfile prüfen. Es sollte standardmäßig nur das drinstehen:
cer: ""
key: ""
listen: 127.0.0.1:12345
seccomp: false
serial: ""
syslog: true
RootCA einrichten
Das Einrichten der RootCA ist recht einfach und orientiert sich am Artikel Zweistufige PKI . Der große Unterschied ist jedoch, dass bei Schritt 6 „Cryptography for CA“ anstelle „RSA#Microsoft Software Key Storage Provider“ der „RSA#YubiHSM Key Storage Provider“ verwendet wird. Zudem wird abweichend der Hersteller-Anleitung (yubico.com) direkt auf eine Shclüssellänge von „4096 bit“ und der Hash-Algorhythmus „SHA512“ verwendet. Als Laufzeit der RootCA werden 10 Jahre gewählt, was ein gängiger Wert ist.
Szenario 2 – HSM zentral im Netzwerk
Im zweiten Szenario soll der HSM-Stick im Netzwerk bereitgestellt werden. Um dieses Ziel zu erreichen sind folgende Schritte notwendig:
- Vorbereiten des HSM-Servers
- Umstecken des HSM-Sticks
- Umstellung der RootCA (lokal HSM -> zentraler HSM)
- Installation SubCA mit Verwendung des zentralen HSM
Vorbereitung des HSM-Servers
Dafür wird die VM „WSHSM01“ verwendet. Hier müssen erstmal die gleichen Schritte, wie im Kapitel „YubiHSM2 Treiber“ aus dem ersten Szenario; also Installation von:
- YubiHSM Connector
- YubiHSM Shell (x64) – optional, nur für Konfiguration/Verfifizierung des YubiHSM-Sticks
Das Configurationfile (C:\programdata\yubiHSM\yubihsm-connector.yaml) für den Connector muss angepasst werden und die Zeile
- listen: 127.0.0.1:12345
geändert werden auf:
- listen: 192.168.128.15:12345
und anschließend der Dienst „YubiHSM Connector Service“ (= Displayname; der Servicename ist „yhconsrv“) neugestartet werden.
WICHTIG:
Vermutlich muss die eingehende Windows-Firewall noch so konfiguriert werden, dass TCP-Verbindungen von der RootCA (bei mir mit der IP: 192.18.128.13) akzeptiert werden.
Dafür wurde die Firewall-Regel „YubiHSM-Connector – INBOUND“ angelegt – hier als kurze Galerie:
Umstecken des HSM-Sticks
Jetzt muss der Stick umgesteckt werden. In der virtuellen Umgebung passiert dies durch Trennen von der VM „WSCAR1“ und Verbinden mit der VM „WSHSM1“
Wichtig:
Betreibt man den HSM-Stick direkt im Szenario 2 müssen noch der Schritt „Erstkonfiguration des HSM-Moduls“ und optiomaler Weise auch „Verifizierung des Setups“ durchgeführt werden.
Umstellung der RootCA (Lokal -> Zentral)
Bei der Umstellung der RootCA ist nur zu Beachten, dass in der Registry (Einstellungen für den „Key Storage Provider“) die IP-Adresse von „127.0.0.1“ umgestellt wird auf die IP-Adresse des HSM-Servers (also in meinem Fall „192.168.128.15“). Natürlich gibt es auch hierfür eine Hersteller-Anleitung (yubico.com).
Eine Installation von „YubiHSM Key Storage Provider“ und „YubiHSM Shell (x64)“ ist für die RootCA dann nicht mehr erforderlich.
Verifizierung der Einstellung – per YubiHSM-Shell
Nach der Umstellung empfiehlt es sich, diese noch kurz zu Prüfen. Der Ablauf ist ähnlich zum Verifizieren nach der Ersteinrichtung. Der Unterschied ist lediglich, dass angegeben werden muss, wo sich der Connector befindet. Hier der Ablauf:
- Starten der YubiHSM-Shell (lag bei mir nach der oben durchgeführten Installation aus Kapitel „YubiHSM Shell (x64)„) im Pfad „
C:\Program Files\Yubico\YubiHSM Shell\bin
“ durch Eingabe folgenden Befehls in die Commandozeile:yubihsm-shell.exe --connect http://192.168.128.15:12345
- Mit dem Befehl „
connect
“ eine Verbindung zum eingesteckten HSM herstellen - Anschließend mit dem Befehl „
session open NUMBER
“ eine Verbindung zum „Slot“ herstellen, den man bei der Ersteinrichtung verwendet hat. In meinem Fall war das „0xfa63“, was als Dezimalzahl die „64099“ ist. - Es wird dann das Passwort für den „Application Authentication Key“ benötigt.
- Eine kurze Auflistung aller Keys für diesen Slot werden mit dem Befehl „
list objects 0
“ aufgelistet:- Audit Authentication Key
- Wrap Key
- Asymmetric-Key (Wie am Label „WSCAR1-CA“ zu sehen ist, ist das der PrivateKey der RootCA)
- Application Authentication Key
- Optional kann mit dem Befehl „
get objectinfo 0 NUMBER authentication-key
“ (wobei „NUMBER“ der verwendete Application Authentication Key sein muss; das wäre in meinem Fall „0xfa63“) noch genauere Details anzeigen. Diesen Schritt habe ich nicht durchgeführt. - Zum Verlassen der Überprüfung einfach „
quit
“ eintippen und <ENTER> drücken.
Bei mir hat das auf Anhieb geklappt; sollte die Verbindung nicht hergestellt werden können, kann (wie in Verifying the Default Configuration of the YubiHSM 2 — YubiHSM 2 User Guide documentation (yubico.com) genannt) versucht werden, den Connector im Netzwerkmodus zu starten:
If the application is running on a VM or a different server, start the YubiHSM Connector on the host operating system in networking mode. For example, if the host machine’s IP address is
192.168.100.252
, launch the Connector on the host OS with the commandyubihsm-connector -l 192.168.100.252:12345
Verifizierung der Einstellung – per neuem RootCA-Zertifikat
Als weitere Prüfung kann ein neues Zertifikat der RootCA ausgestellt werden.
- In der RootCA einen Rechtsklick auf den Namen der CA machen und im Kontextmenü „All Tasks > Renew CA Certificate“ auswählen
- Die Meldung, dass die Zertifikatsdienste derweil angehalten werden mit einem Klick auf den Button <Yes> bestätigen
- Die Frage, ob ein neues Schlüsselpaar („Do you want to generate a new public and private key pair?“) erstellt werden soll, mit der Option „Yes“ auswählen und auf den Button <OK> klicken.
- Das neue RootCA-Zertifikat wird erstellt, das kann einen Moment dauern – insbesondere, da ja über Netzwerk mit dem HSM-Modul am HSM-Server („WSHSM1“) kommunziert werden muss. Anschließend wird automatisch der Zertifikatsdienst gestartet.
- Ein Blick in die Eigenschaften der RootCA zeigt, dass ein neues Zertifikat („Certificate #1“) erstellt wurde. Wenn man beide Zertifikate vergleich, sieht man auch die unterschiedlichen Datumangaben der Gültigkeitsdauer.
- Optional kann nochmal mittels der YubiHSM-Shell geprüft werden und es sind dann zwei „Asymmetric-key“-Einträge vorhanden – der mit dem Label „WSCAR1-CA(1)“ ist der neuere.
ACHTUNG:
Wenn ein neues RootCA-Zertifikat erstellt wurde, dann muss dieses allen Stellen bekannt gemacht werden, das bedeutet:
- Import ins Active Directory
- Neues SubCA-Zertifikat erstellen
- ggfs. auf Nicht-Domänen-Mitglieder importieren (bspw. Firewalls/Switche, NAS, Standalone-Server, etc.)
Der Ablauf noch als Galerie:
Einrichten der SubCA / IssuingCA
Vorbereitungen
In meinem Szenario wird der Server „WSCAS1“ als SubCA genommen und nach der Betriebssysteminstallation und Anpassung von Hostname und fester IP (192.168.128.14) wird der Server in die Domäne („demo.vmws“) aufgenommen.
Ähnlich wie beim Szenario 1 auf der RootCA muss als nächstes das Setup für den „Key Storage Provider“ ausgeführt werden.
Danach dann im Registry-Pfad Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM
diese Werte ändern:
- AuthKeysetID
- Alt: 0x00000001 (1)
- Neu: 0x0000fa63 (64099)
- AuthKeysetPassword
- Alt: password
- Neu: SuperHSMTutorial2024
- ConnectorURL
- Alt: http://127.0.0.1:12345
- Neu: http://192.168.128.15:12345
Diese Werte entsprechen natürlich nur meiner Testumgebung (siehe im oberen Teil bei „RootCA“).
Auf dem HSM-Server muss in der eingehende Firewall-Regel „YubiHSM-Connector – INBOUND“ natürlich noch die IP-Adresse der SubCA aufgenommen werden, ansonsten klappt die Kommunikation zum YubiHSM-Stick nicht.
Installation Rolle und Konfiguration
Das Einrichten der SubCA ist recht einfach und orientiert sich am Artikel Zweistufige PKI . Der große Unterschied ist auch hier wieder, dass bei Schritt 6 „Cryptography for CA“ anstelle „RSA#Microsoft Software Key Storage Provider“ der „RSA#YubiHSM Key Storage Provider“ verwendet wird, sowie direkt auf eine Schlüssellänge von „4096 bit“ gestellt und einen Hash-Algorhythmus von „SHA512“ verwendet wird. Als Laufzeit der SubCA werden 5 Jahre gewählt, was ein gängiger Wert ist.
Hier nur die wichtigen Screenshots:
Danach habe ich mich nochmal auf den YubiHSM verbunden und man kann sehen, dass hier wieder weitere PrivateKeys hinzugekommen sind:
Da ich einen kleinen Fehler bei mir hatte, musste ich das RootCA-Zertifikat erneut erstellen – dafür Private-Key „WSCAR1-CA(2)“ – und das SubCA-Zertifikat hat dadurch ebenfalls erst beim 2. Anlauf geklappt – dafür Private-Key „WSCAS1a-CA“.
Thank you for sharing this insightful article! I found the information really useful and thought-provoking. Your writing style is engaging, and it made the topic much easier to understand. Looking forward to reading more of your posts!