Windows Provider

sslTrus propose deux modes d’intégration Windows Provider : KSP (Key Storage Provider) et CSP (Cryptographic Service Provider).

Grâce au Windows Provider, Microsoft SignTool, Visual Studio, MSBuild, les outils d’installation ainsi que tout autre logiciel prenant en charge les interfaces de cryptographie Windows peuvent utiliser les capacités de signature de code cloud de sslTrus.

La clé privée de signature reste toujours conservée dans le HSM cloud ; il n’est pas nécessaire de déployer le fichier de clé privée sur la machine locale.

L’installation, la configuration et la maintenance de KSP et CSP s’effectuent via l’interface de ligne de commande sslTrus SignTool CLI, téléchargeable depuis la page de publication du client sslTrus.

KSP et CSP

KSP et CSP correspondent respectivement aux deux générations d’interfaces de cryptographie Windows :

Provider	Interface Windows	Cas d’utilisation
KSP	CNG (Cryptography API : Next Generation)	Applications Windows modernes et outils de signature, à privilégier
CSP	CryptoAPI	Applications héritées ou logiciels exigeant explicitement l’utilisation de CSP

Pour les nouveaux scénarios d’intégration Windows, KSP est généralement privilégié.

Ce n’est que lorsque le logiciel cible ne prend pas en charge KSP, ou exige explicitement le CryptoAPI Provider traditionnel, qu’il convient d’utiliser CSP.

KSP

KSP est un Key Storage Provider basé sur Windows CNG.

Après l’installation de sslTrus KSP, les applications Windows prenant en charge CNG peuvent invoquer le service de signature de code distant via l’interface de clés Windows standard.

Le Provider local reçoit les demandes de signature initiées par l’application et envoie le résumé à signer au service de signature de code distant ; l’opération réelle sur la clé privée s’effectue dans le HSM cloud.

Cas d’utilisation applicables

KSP convient à :

• Microsoft SignTool.
• Visual Studio.
• MSBuild.
• Logiciels de construction et de signature prenant en charge Windows CNG.
• Applications nécessitant l’accès à une clé privée distante via un Windows Provider standard.

Installation de KSP

Exécutez dans un terminal administrateur :

signtool ksp install

Cette commande installera et enregistrera :

sslTrus Key Storage Provider

L’installation de KSP implique l’enregistrement du fournisseur système ainsi que les répertoires système de Windows, elle nécessite donc généralement des privilèges d’administrateur.

Ajout de la configuration du certificat

Exécutez :

signtool ksp add

Saisissez les informations demandées :

Access Key
Access Secret
Certificate Code

Le client récupère le certificat correspondant auprès du service de signature de code à distance, et enregistre l’adresse du service distant, les informations d’identification d’accès et la configuration du certificat.

Si vous utilisez l’environnement NICSRS (www.nicsrs.com), vous devez ajouter --address nicsrs :

signtool ksp add --address nicsrs

Enregistrer le certificat

Une fois la configuration KSP terminée, il est nécessaire d’enregistrer le certificat de signature de code dans l’inventaire des certificats Windows et de le lier au fournisseur KSP.

Exécutez :

signtool ksp register

Par défaut, enregistré dans l’inventaire des certificats personnel de l’utilisateur actuel.

Si vous devez l’enregistrer dans l’inventaire des certificats LocalMachine :

signtool ksp register --store local-machine

Une fois l’inscription terminée, Windows reconnaît le certificat correspondant comme disposant d’une clé privée disponible, mais la clé privée réelle reste stockée dans le HSM cloud.

Utilisation de Microsoft SignTool

Après la configuration de KSP, vous pouvez utiliser Microsoft signtool.exe fourni par le Windows SDK pour signer des fichiers.

Par exemple :

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"

Principaux paramètres :

Paramètre	Description
/csp	Spécifie le fournisseur KSP sslTrus
/kc	Spécifie le conteneur de clés correspondant au numéro de certificat
/f	Spécifie le certificat de signature de code
/fd	Spécifie l'algorithme de condensé du fichier
/tr	Spécifie le serveur d'horodatage RFC 3161
/td	Spécifie l'algorithme de condensé d'horodatage

Si vous devez ajouter une signature SHA-1 à une signature existante, vous pouvez utiliser le paramètre /as :

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 effectuera l’appel via Windows CNG au KSP sslTrus, et c’est le KSP qui réalisera la signature de la clé privée à distance.

Gérer le KSP

Afficher les KSP déjà configurés :

signtool ksp list

Suppression de la configuration :

signtool ksp del

Supprimer l’association entre le certificat et le KSP :

signtool ksp deregister

Désinstallation de KSP :

signtool ksp uninstall

Avant de désinstaller le Provider, vérifiez qu'aucune autre application Windows ne dépend encore de ce Provider.

CSP

Le CSP est le fournisseur de services cryptographiques (Cryptographic Service Provider) utilisé par la CryptoAPI traditionnelle de Windows.

Il est principalement utilisé pour les processus de signature Windows qui nécessitent de spécifier le Provider et le conteneur de clés via les paramètres /csp et /kc. Le CSP sslTrus est installé et maintenu par le client ; la signature réelle des fichiers est réalisée par le signtool.exe Microsoft du SDK Windows.

Scénarios d'utilisation

Le CSP convient aux cas suivants :

• Logiciels Windows prenant en charge uniquement la CryptoAPI traditionnelle.
• Outils de signature exigeant explicitement un Provider CSP spécifique.
• Environnements nécessitant une signature via Microsoft SignTool avec les paramètres /csp et /kc.
• Applications héritées ne pouvant pas utiliser Windows CNG / KSP.

Pour les nouveaux systèmes utilisant correctement KSP, le recours supplémentaire au CSP n'est généralement pas nécessaire.

Installation du CSP

Exécutez dans un terminal administrateur :

signtool csp install

Lors de l’installation, les éléments suivants seront enregistrés :

sslTrus Cryptographic Service Provider

Et installez la DLL du Provider dans le système Windows.

Le type de CSP Provider est :

PROV_RSA_AES

La configuration locale est enregistrée par défaut dans :

%ProgramData%\sslTrusKSP

Le fichier de configuration est protégé par DPAPI de Windows.

Si vous devez également installer KSP, vous pouvez exécuter :

signtool csp install --with-ksp

Ajout de la configuration du certificat

Exécutez :

signtool csp add

Selon les instructions, saisissez :

Access Key
Access Secret
Certificate Code

Une fois l’ajout terminé, le client téléchargera le certificat correspondant et le sauvegardera dans :

%ProgramData%\sslTrusKSP\CERT_CODE.crt

CERT_CODE sert à la fois d’identifiant du certificat distant et de nom du conteneur de clés utilisé ultérieurement par Microsoft SignTool.

Si vous utilisez l’environnement NICSRS (www.nicsrs.com), il est nécessaire d’ajouter --address nicsrs :

signtool csp add --address nicsrs

Enregistrement du certificat

Par défaut, le certificat est enregistré dans l’inventaire des certificats personnels de l’utilisateur actuel :

signtool csp register

Si vous devez vous enregistrer dans LocalMachine :

signtool csp register --store local-machine

Les magasins de certificats pris en charge sont les suivants :

Paramètre	Magasin de certificats Windows
current-user	CurrentUser\My
local-machine	LocalMachine\My

Une fois l’enregistrement terminé, le gestionnaire de certificats Windows affiche que le certificat correspondant est associé à une clé privée, mais la clé privée reste en réalité stockée dans le HSM cloud.

Utilisation de Microsoft SignTool

Lors d’une signature CSP, il est nécessaire de spécifier explicitement le fournisseur, le conteneur de clés et le fichier de certificat :

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"

Principaux paramètres :

Paramètre	Description
/csp	Spécifie le fournisseur CSP sslTrus
/kc	Spécifie le conteneur de clés correspondant au numéro de certificat
/f	Spécifie le certificat de signature de code
/fd	Spécifie l'algorithme de résumé du fichier
/tr	Spécifie le serveur d'horodatage RFC 3161
/td	Spécifie l'algorithme de résumé d'horodatage

L'interface de signature à distance prend actuellement en charge les algorithmes de résumé SHA1 et SHA256. Pour les nouveaux scénarios de signature, SHA256 doit être privilégié ; SHA1 ne doit être utilisé que pour la compatibilité avec les anciens systèmes.

Vérification de la signature

Une fois la signature terminée, vous pouvez utiliser Microsoft SignTool pour la vérifier :

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

La vérification de signature ne rappelle pas la clé privée distante et ne génère pas de nouveau nombre de signatures.

Gérer le CSP

Consulter la configuration existante :

signtool csp list

Suppression d’une configuration de certificat :

signtool csp del

Supprimer l’association de la clé privée entre le certificat et le CSP :

signtool csp deregister

Désinstallation du Provider :

signtool csp uninstall

Suppression de la configuration CSP ne supprime pas automatiquement les fichiers de certificat déjà téléchargés. Si le certificat et la configuration associés ne sont plus utilisés, il convient de les nettoyer après avoir confirmé qu'aucun autre Provider n'en dépend.

KSP ou CSP

En l'absence d'exigences de compatibilité particulières, vous pouvez choisir selon les modalités suivantes :

Scénario	Recommandation
Nouvel environnement de signature Windows	KSP
Prise en charge de Windows CNG	KSP
Outils Windows modernes tels que Microsoft SignTool	KSP
Le logiciel exige explicitement CSP	CSP
Applications CryptoAPI traditionnelles	CSP
L'outil nécessite l'utilisation de /csp et /kc	CSP

La principale différence entre KSP et CSP réside dans les interfaces de fournisseur cryptographique utilisées par Windows, le modèle de sécurité de la clé privée distante restant cohérent.

Que vous utilisiez KSP ou CSP, la clé privée de signature de code n'est jamais enregistrée sur le client local.

Nombre de signatures

Le nombre de signatures du Provider Windows est calculé en fonction des actions de signature distantes réellement effectuées au niveau sous-jacent.

Par exemple :

SHA256 签名一次 = 1 次

Si un fichier est d’abord signé avec SHA256, puis qu’une signature supplémentaire est ajoutée, une nouvelle opération de clé privée distante est déclenchée. Il est donc nécessaire de calculer séparément.

Dans le scénario KSP, l’exécution d’une double signature SHA256 et SHA1 sur le même fichier génère généralement deux appels de signature en couche inférieure.

Pour les règles spécifiques, veuillez consulter Documents de référence.

Horodatage

Il est généralement recommandé d’ajouter un horodatage de confiance à une signature Windows Authenticode.

Dans les scénarios modernes de signature de code, il est recommandé de privilégier l’horodatage RFC 3161, par exemple :

http://timestamp.acs.microsoft.com

Dans un environnement de production réel, le choix du TSA approprié doit être basé sur la version cible de Windows, la stratégie de certificat, l’environnement réseau et les exigences du fournisseur de services d’horodatage.

Veuillez consulter Références pour les détails concernant les serveurs d’horodatage spécifiques et les protocoles.

Consignes de sécurité

Lors de l’utilisation du Provider Windows, il convient de noter ce qui suit :

• L’Access Secret doit être protégé en tant que information d’identification sensible.
• Ne pas écrire les informations d’identification d’accès dans des scripts publics ou des journaux.
• Le fichier de configuration du Provider ne doit pas être diffusé publiquement.
• Les fichiers de certificat locaux ne contiennent pas la clé privée de signature de code.
• La clé privée de signature de code est toujours conservée dans le HSM cloud.
• Lorsque KSP/CSP lance une signature, il doit pouvoir accéder au service de signature de code à distance.
• Lors de l’utilisation du magasin de certificats LocalMachine, une attention particulière doit être portée aux autorisations utilisateur Windows et à la portée d’accès aux informations d’identification.

Le config.dat du CSP est protégé via DPAPI avec le profil utilisateur Windows actuel. L’enregistrement du certificat dans LocalMachine ne modifie pas automatiquement la portée de protection DPAPI de cette configuration.