Windows Provider

sslTrus bietet zwei Windows-Provider-Integrationsmöglichkeiten: KSP (Key Storage Provider) und CSP (Cryptographic Service Provider).

Über Windows Provider können Microsoft SignTool, Visual Studio, MSBuild, Paketierungstools und andere Software, die Windows-Kryptografieschnittstellen unterstützen, die Cloud-Codesignierungsfunktionen von sslTrus nutzen.

Der private Signaturschlüssel bleibt stets im Cloud-HSM gespeichert; die Schlüsseldatei muss nicht auf dem lokalen Computer bereitgestellt werden.

Installation, Konfiguration und Wartung von KSP und CSP erfolgen vollständig über die sslTrus SignTool CLI, die auf der sslTrus-Client-Veröffentlichungsseite heruntergeladen werden kann.

KSP und CSP

KSP und CSP entsprechen zwei Generationen von Windows-Kryptografieschnittstellen:

Provider	Windows-Schnittstelle	Geeignete Szenarien
KSP	CNG (Cryptography API: Next Generation)	Moderne Windows-Anwendungen und Signaturtools; bevorzugte Wahl
CSP	CryptoAPI	Legacy-Anwendungen oder Software, die ausdrücklich CSP erfordert

Für neue Windows-Integrationsszenarien wird in der Regel KSP bevorzugt.

Nur wenn die Zielsoftware KSP nicht unterstützt oder ausdrücklich einen herkömmlichen CryptoAPI-Provider erfordert, wird CSP verwendet.

KSP

KSP ist ein Key Storage Provider auf Basis von Windows CNG.

Nach der Installation von sslTrus KSP können CNG-fähige Windows-Anwendungen den Remote-Codesignierungsdienst über die standardmäßigen Windows-Schlüsselschnittstellen aufrufen.

Der lokale Provider empfängt die von der Anwendung ausgelösten Signaturanforderungen und sendet den zu signierenden Digest an den Remote-Codesignierungsdienst; die eigentlichen Operationen mit dem privaten Schlüssel erfolgen im Cloud-HSM.

Geeignete Szenarien

KSP eignet sich für:

• Microsoft SignTool.
• Visual Studio.
• MSBuild.
• Build- und Signatursoftware mit Unterstützung für Windows CNG.
• Anwendungen, die über einen standardmäßigen Windows Provider auf entfernte private Schlüssel zugreifen müssen.

KSP installieren

Führen Sie in einem Administratoren-Terminal Folgendes aus:

signtool ksp install

Dieser Befehl installiert und registriert:

sslTrus Key Storage Provider

Die KSP-Installation umfasst die Registrierung des System-Providers sowie das Windows-Systemverzeichnis und erfordert daher in der Regel Administratorrechte.

Zertifikatskonfiguration hinzufügen

Ausführen:

signtool ksp add

Gemäß der Eingabeaufforderung:

Access Key
Access Secret
Certificate Code

Der Client ruft das entsprechende Zertifikat vom Remote-Codesignaturdienst ab und speichert die Remote-Dienst-URL, die Zugangsdaten und die Zertifikatskonfiguration.

Wenn Sie die NICSRS-Umgebung (www.nicsrs.com) verwenden, müssen Sie --address nicsrs hinzufügen:

signtool ksp add --address nicsrs

Zertifikat registrieren

Nach Abschluss der KSP-Konfiguration muss das Code-Signaturzertifikat im Windows-Zertifikatsbestand registriert und mit dem KSP-Provider verknüpft werden.

Ausführen:

signtool ksp register

Standardmäßig wird die Registrierung im persönlichen Zertifikatsbestand des aktuellen Benutzers vorgenommen.

Wenn eine Registrierung im LocalMachine-Zertifikatsbestand erforderlich ist:

signtool ksp register --store local-machine

Nach Abschluss der Registrierung erkennt Windows das entsprechende Zertifikat als mit verfügbarem privatem Schlüssel, der tatsächliche private Schlüssel bleibt jedoch weiterhin im Cloud-HSM gespeichert.

Verwenden von Microsoft SignTool

Nach Abschluss der KSP-Konfiguration können Sie das im Windows SDK enthaltene Microsoft signtool.exe zum Signieren von Dateien verwenden.

Beispiel:

signtool.exe sign /v ^
  /csp "sslTrus Key Storage Provider" ^
  /kc CERT_CODE ^
  /f "C:\ProgramData\sslTrusKSP\CERT_CODE.crt" ^
  /fd SHA256 ^
  /tr http://timestamp.acs.microsoft.com ^
  /td SHA256 ^
  ".\app.exe"

Hauptparameter:

Parameter	Beschreibung
/csp	Gibt den sslTrus KSP Provider an
/kc	Gibt den Schlüsselcontainer der Zertifikatsnummer an
/f	Gibt das Codesignatur-Zertifikat an
/fd	Gibt den Datei-Hashalgorithmus an
/tr	Gibt den RFC 3161 Zeitstempelserver an
/td	Gibt den Zeitstempel-Hashalgorithmus an

Wenn eine SHA-1-Signatur zusätzlich zur bestehenden Signatur erforderlich ist, kann der Parameter /as verwendet werden:

signtool.exe sign /v ^
  /csp "sslTrus Key Storage Provider" ^
  /kc CERT_CODE ^
  /f "C:\ProgramData\sslTrusKSP\CERT_CODE.crt" ^
  /fd SHA1 ^
  /tr http://timestamp.acs.microsoft.com ^
  /td SHA256 ^
  /as ^
  ".\app.exe"

Microsoft signtool.exe ruft über Windows CNG den sslTrus KSP auf, und der KSP führt anschließend die Remotesignatur des privaten Schlüssels durch.

KSP verwalten

Anzeigen der bereits konfigurierten KSPs:

signtool ksp list

Konfiguration löschen:

signtool ksp del

Zertifikat von KSP trennen:

signtool ksp deregister

KSP deinstallieren:

signtool ksp uninstall

Vor der Deinstallation des Providers sollte bestätigt werden, dass keine andere Windows-Anwendung mehr von diesem Provider abhängig ist.

CSP

CSP ist der Cryptographic Service Provider, der von der herkömmlichen Windows CryptoAPI verwendet wird.

Er wird hauptsächlich für Windows-Signaturprozesse benötigt, bei denen der Provider und der Schlüsselcontainer über die Parameter /csp und /kc angegeben werden müssen. Der sslTrus CSP wird vom Client installiert und gewartet; die eigentliche Dateisignatur erfolgt weiterhin durch das Microsoft signtool.exe des Windows SDK.

Geeignete Szenarien

CSP eignet sich für:

• Windows-Software, die nur die herkömmliche CryptoAPI unterstützt.
• Signaturwerkzeuge, die ausdrücklich die Angabe eines CSP-Providers erfordern.
• Umgebungen, in denen die Signatur über die Microsoft SignTool-Parameter /csp und /kc ausgeführt werden muss.
• Ältere Anwendungen, die Windows CNG / KSP nicht verwenden können.

Auf neueren Systemen, die KSP normal verwenden können, ist die zusätzliche Verwendung von CSP in der Regel nicht erforderlich.

CSP installieren

Führen Sie im Administrator-Terminal Folgendes aus:

signtool csp install

Während der Installation werden registriert:

sslTrus Cryptographic Service Provider

Und installieren Sie die Provider-DLL in das Windows-System.

Der CSP-Provider-Typ ist:

PROV_RSA_AES

Die lokale Konfiguration wird standardmäßig gespeichert unter:

%ProgramData%\sslTrusKSP

Die Konfigurationsdatei wird durch Windows DPAPI geschützt.

Wenn der KSP gleichzeitig installiert werden muss, können Sie Folgendes ausführen:

signtool csp install --with-ksp

Zertifikatskonfiguration hinzufügen

Ausführen:

signtool csp add

Gemäß der Eingabeaufforderung:

Access Key
Access Secret
Certificate Code

Nach dem Hinzufügen lädt der Client das entsprechende Zertifikat herunter und speichert es unter:

%ProgramData%\sslTrusKSP\CERT_CODE.crt

Dabei dient CERT_CODE sowohl als Remote-Zertifikatskennung als auch als Schlüsselcontainer-Name, der später von Microsoft SignTool verwendet wird.

Bei Verwendung der NICSRS-Umgebung (www.nicsrs.com) muss --address nicsrs hinzugefügt werden:

signtool csp add --address nicsrs

Zertifikat registrieren

Standardmäßig wird das Zertifikat im persönlichen Zertifikatsbestand des aktuellen Benutzers registriert:

signtool csp register

Falls eine Registrierung bei LocalMachine erforderlich ist:

signtool csp register --store local-machine

Unterstützte Zertifikatsbestände umfassen:

Parameter	Windows-Zertifikatsbestand
current-user	CurrentUser\My
local-machine	LocalMachine\My

Nach Abschluss der Registrierung zeigt der Windows-Zertifikat-Manager an, dass das entsprechende Zertifikat über eine verknüpfte private Schlüsselbeziehung verfügt. Der private Schlüssel befindet sich jedoch weiterhin tatsächlich im Cloud-HSM.

Verwendung von Microsoft SignTool

Bei der CSP-Signatur müssen der Provider, der Schlüsselcontainer und die Zertifikatsdatei explizit angegeben werden:

signtool.exe sign /v ^
  /csp "sslTrus Cryptographic Service Provider" ^
  /kc CERT_CODE ^
  /f "C:\ProgramData\sslTrusKSP\CERT_CODE.crt" ^
  /fd SHA256 ^
  /tr http://timestamp.acs.microsoft.com ^
  /td SHA256 ^
  ".\app.exe"

Wichtigste Parameter:

Parameter	Beschreibung
/csp	Gibt den sslTrus CSP-Provider an
/kc	Gibt den Schlüsselcontainer zur Zertifikatsnummer an
/f	Gibt das Code-Signaturzertifikat an
/fd	Gibt den Datei-Digest-Algorithmus an
/tr	Gibt den RFC-3161-Zeitstempelserver an
/td	Gibt den Zeitstempel-Digest-Algorithmus an

Der sslTrus CSP unterstützt die Digest-Algorithmen SHA1, SHA256, SHA384 und SHA512. Für neue Signaturszenarien sollte in der Regel SHA-256 oder ein stärkerer Algorithmus verwendet werden.

Signatur überprüfen

Nach Abschluss der Signatur kann die Überprüfung mit Microsoft SignTool erfolgen:

signtool.exe verify /pa /v ".\app.exe"

Die Signaturprüfung ruft den entfernten privaten Schlüssel nicht erneut auf und erzeugt auch keine neuen Signaturvorgänge.

CSP verwalten

Vorhandene Konfigurationen anzeigen:

signtool csp list

Löschen einer Zertifikatskonfiguration:

signtool csp del

Private Key-Verknüpfung des Zertifikats mit dem CSP aufheben:

signtool csp deregister

Deinstallation des Providers:

signtool csp uninstall

Das Löschen der CSP-Konfiguration entfernt bereits heruntergeladene Zertifikatsdateien nicht automatisch. Wenn das zugehörige Zertifikat und die Konfiguration nicht mehr verwendet werden, sollten sie erst bereinigt werden, nachdem bestätigt wurde, dass keine anderen Provider davon abhängig sind.

KSP oder CSP

Wenn keine besonderen Kompatibilitätsanforderungen bestehen, kann die Auswahl wie folgt getroffen werden:

Szenario	Empfehlung
Neue Windows-Signaturumgebung	KSP
Unterstützung von Windows CNG	KSP
Moderne Windows-Tools wie Microsoft SignTool	KSP
Software erfordert ausdrücklich CSP	CSP
Legacy-CryptoAPI-Anwendungen	CSP
Tool erfordert die Verwendung von /csp und /kc	CSP

Der Hauptunterschied zwischen KSP und CSP liegt in der von Windows verwendeten Kryptografie-Provider-Schnittstelle; das Sicherheitsmodell für den entfernten privaten Schlüssel bleibt identisch.

Unabhängig davon, ob KSP oder CSP verwendet wird, wird der private Schlüssel für die Codesignatur nicht auf dem lokalen Client gespeichert.

Anzahl der Signaturen

Die Anzahl der Signaturen des Windows-Providers wird anhand der tatsächlich auf der zugrunde liegenden Ebene ausgeführten entfernten Signaturaktionen berechnet.

Beispiel:

SHA256 签名一次 = 1 次

Wenn dieselbe Datei zuerst mit SHA256 signiert und anschließend eine weitere Signatur angehängt wird, wird der Remote-Private-Key-Vorgang erneut ausgelöst, daher müssen die Berechnungen separat erfolgen.

Im KSP-Szenario führt die Doppelsignatur derselben Datei mit SHA256 und SHA1 in der Regel zu zwei zugrunde liegenden Signaturaufrufen.

Die spezifischen Regeln finden Sie in den Referenzmaterialien.

Zeitstempel

Bei Windows-Authenticode-Signaturen wird in der Regel empfohlen, einen vertrauenswürdigen Zeitstempel hinzuzufügen.

In modernen Codesignatur-Szenarien wird empfohlen, bevorzugt RFC-3161-Zeitstempel zu verwenden, zum Beispiel:

http://timestamp.acs.microsoft.com

In der tatsächlichen Produktionsumgebung sollte je nach Windows-Zielversion, Zertifikatsrichtlinie, Netzwerkumgebung und den Anforderungen des Zeitstempel-Dienstanbieters eine geeignete TSA gewählt werden.

Konkrete Angaben zu Zeitstempelservern und -protokollen finden Sie in den Referenzmaterialien.

Sicherheitshinweise

Bei Verwendung des Windows Providers ist Folgendes zu beachten:

• Access Secret sollte als vertrauliche Zugangsdaten geschützt werden.
• Schreiben Sie Zugangsdaten nicht in öffentliche Skripte oder Protokolle.
• Provider-Konfigurationsdateien sollten nicht öffentlich verbreitet werden.
• Lokale Zertifikatsdateien enthalten keinen privaten Schlüssel für die Codesignatur.
• Der private Schlüssel für die Codesignatur wird stets in der Cloud-HSM aufbewahrt.
• KSP/CSP benötigen beim Initiieren der Signatur Zugriff auf den Remote-Codesignaturdienst.
• Bei Verwendung des LocalMachine-Zertifikatsbestands ist besonders auf Windows-Benutzerrechte und den Zugriffsbereich der Zugangsdaten zu achten.

Die config.dat des CSP wird mit DPAPI des aktuellen Windows-Benutzerprofils geschützt. Die Registrierung des Zertifikats bei LocalMachine ändert den DPAPI-Schutzbereich dieser Konfiguration nicht automatisch.