Aller au contenu principal

Windows Provider

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

Grâce au fournisseur Windows, vous pouvez permettre à Microsoft SignTool, Visual Studio, MSBuild, aux outils de création de packages d’installation ainsi qu’à d’autres logiciels prenant en charge les interfaces cryptographiques Windows d’utiliser la capacité de signature de code cloud de sslTrus.

La clé privée de signature reste toujours stockée dans le HSM cloud, sans qu’il soit nécessaire de déployer le fichier de clé privée sur l’ordinateur local.

L’installation, la configuration et la maintenance de KSP et CSP s’effectuent toutes via la CLI sslTrus SignTool, qui peut être téléchargée depuis la page de publication du client sslTrus.

KSP et CSP

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

FournisseurInterface WindowsScénarios d’application
KSPCNG (Cryptography API: Next Generation)Applications et outils de signature Windows modernes, à privilégier
CSPCryptoAPIApplications traditionnelles ou logiciels exigeant explicitement l’utilisation de CSP

Pour les nouveaux scénarios d’intégration Windows, il est généralement recommandé d’utiliser KSP en priorité.

N’utilisez CSP que lorsque le logiciel cible ne prend pas en charge KSP, ou lorsqu’il exige explicitement l’utilisation du fournisseur CryptoAPI traditionnel.

KSP

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

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

Le fournisseur local est chargé de recevoir les demandes de signature lancées par l’application et d’envoyer le condensé à signer au service de signature de code à distance ; les opérations réelles sur la clé privée sont effectuées dans le HSM cloud.

Scénarios d’application

KSP convient pour :

  • Microsoft SignTool.
  • Visual Studio.
  • MSBuild.
  • Les logiciels de génération et de signature prenant en charge Windows CNG.
  • Les applications nécessitant l’accès à une clé privée distante via un fournisseur Windows standard.

Installation de KSP

Exécutez la commande suivante dans un terminal administrateur :

signtool ksp install

Cette commande installera et enregistrera :

sslTrus Key Storage Provider

L'installation du KSP implique l'enregistrement du fournisseur système et le répertoire système Windows, elle nécessite donc généralement des privilèges d'administrateur.

Ajouter une configuration de certificat

Exécutez :

signtool ksp add

Saisissez selon l’invite :

Access Key
Access Secret
Certificate Code

Le client récupère le certificat correspondant auprès du service distant de signature de code 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

Après avoir terminé la configuration du KSP, vous devez enregistrer le certificat de signature de code dans l’inventaire des certificats Windows et l’associer au fournisseur KSP.

Exécution :

signtool ksp register

Par défaut, il s'enregistre dans l’inventaire des certificats personnel de l'utilisateur actuel.

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

signtool ksp register --store local-machine

Après l’enregistrement, Windows reconnaît le certificat correspondant comme disposant d’une clé privée utilisable, mais la clé privée réelle reste stockée dans le HSM cloud.

Utilisation de Microsoft SignTool

Une fois le KSP configuré, vous pouvez utiliser l’outil Microsoft signtool.exe fourni par le SDK Windows 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"

Paramètres principaux :

ParamètreDescription
/cspSpécifie le fournisseur KSP sslTrus
/kcSpécifie le conteneur de clé correspondant au numéro de certificat
/fSpécifie le certificat de signature de code
/fdSpécifie l’algorithme de hachage du fichier
/trSpécifie le serveur d’horodatage RFC 3161
/tdSpécifie l’algorithme de hachage de l’horodatage

S’il est nécessaire d’ajouter une signature SHA-1 sur la base d’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 appelle le KSP sslTrus via Windows CNG, puis le KSP effectue la signature avec la clé privée à distance.

Gérer le KSP

Afficher les KSP déjà configurés :

signtool ksp list

Supprimer la configuration :

signtool ksp del

Dissocier le certificat du KSP :

signtool ksp deregister

Désinstaller KSP :

signtool ksp uninstall

Avant de désinstaller le fournisseur, assurez-vous qu’aucune autre application Windows n’en dépend encore.

CSP

Le CSP est le fournisseur de services cryptographiques utilisé par l’API CryptoAPI traditionnelle de Windows.

Il est principalement utilisé dans les flux de signature Windows qui nécessitent de spécifier le fournisseur et le conteneur de clé via les paramètres /csp et /kc. Le CSP sslTrus est installé et maintenu par le client, tandis que la signature réelle du fichier reste assurée par le composant Microsoft signtool.exe du SDK Windows.

Scénarios d’utilisation

Le CSP convient aux cas suivants :

  • Logiciels Windows prenant uniquement en charge l’API CryptoAPI traditionnelle.
  • Outils de signature exigeant explicitement la spécification d’un fournisseur CSP.
  • Environnements nécessitant l’exécution de signatures via les paramètres /csp et /kc de Microsoft SignTool.
  • Applications héritées ne pouvant pas utiliser CNG / KSP de Windows.

Pour les nouveaux systèmes capables d’utiliser correctement KSP, il n’est généralement pas nécessaire d’utiliser également le CSP.

Installation du CSP

Exécutez la commande suivante dans un terminal administrateur :

signtool csp install

Pendant l'installation, les éléments suivants seront enregistrés :

sslTrus Cryptographic Service Provider

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

Le type de fournisseur CSP est :

PROV_RSA_AES

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

%ProgramData%\sslTrusKSP

Le fichier de configuration est protégé à l’aide de Windows DPAPI.

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

signtool csp install --with-ksp

Ajouter une configuration de certificat

Exécutez :

signtool csp add

Selon l’invite, saisissez :

Access Key
Access Secret
Certificate Code

Une fois l'ajout terminé, le client télécharge le certificat correspondant et l'enregistre dans :

%ProgramData%\sslTrusKSP\CERT_CODE.crt

Parmi eux, CERT_CODE sert à la fois d’identifiant de certificat distant et de nom de conteneur de clé utilisé par Microsoft SignTool.

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

signtool csp add --address nicsrs

Enregistrement du certificat

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

signtool csp register

Si vous devez vous enregistrer dans LocalMachine :

signtool csp register --store local-machine

Inventaires de certificats pris en charge :

ParamètreInventaire de certificats Windows
current-userCurrentUser\My
local-machineLocalMachine\My

Une fois l’enregistrement terminé, le gestionnaire de certificats Windows indique que le certificat correspondant est associé à une clé privée, mais celle-ci se trouve toujours dans le HSM cloud.

Utilisation de Microsoft SignTool

Lors de la signature avec un CSP, il est nécessaire de spécifier explicitement le fournisseur, le conteneur de clé 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ètreDescription
/cspSpécifie le fournisseur sslTrus CSP
/kcSpécifie le conteneur de clé correspondant au numéro de certificat
/fSpécifie le certificat de signature de code
/fdSpécifie l’algorithme de résumé du fichier
/trSpécifie le serveur d’horodatage RFC 3161
/tdSpécifie l’algorithme de résumé de l’horodatage

Le fournisseur sslTrus CSP prend en charge les algorithmes de résumé SHA1, SHA256, SHA384 et SHA512. Pour les nouveaux scénarios de signature, il est généralement recommandé d’utiliser SHA-256 ou un algorithme plus puissant.

Vérifier la signature

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

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 nouvelles signatures.

Gérer le CSP

Afficher les configurations existantes :

signtool csp list

Supprimer une configuration de certificat :

signtool csp del

Dissocier le certificat de la clé privée du CSP :

signtool csp deregister

Désinstaller le fournisseur :

signtool csp uninstall

La suppression de la configuration CSP n'entraîne pas automatiquement la suppression des fichiers de certificat déjà téléchargés. Si le certificat et la configuration correspondants 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'exigence de compatibilité particulière, vous pouvez faire votre choix selon le tableau suivant :

ScénarioRecommandation
Nouvel environnement de signature WindowsKSP
Prise en charge de Windows CNGKSP
Outils Windows modernes tels que Microsoft SignToolKSP
Le logiciel exige explicitement CSPCSP
Applications CryptoAPI traditionnellesCSP
L'outil requiert l'utilisation de /csp et /kcCSP

La principale différence entre KSP et CSP réside dans l'interface du fournisseur cryptographique utilisée par Windows, le modèle de sécurité des clés privées distantes restant identique.

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

Nombre de signatures

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

Par exemple :

SHA256 签名一次 = 1 次

Si un fichier est d'abord signé avec SHA256, puis une autre signature est ajoutée, une nouvelle opération de clé privée à distance sera à nouveau déclenchée. Il est donc nécessaire de les 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 sous-jacents.

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

Horodatage

La signature Windows Authenticode recommande généralement l'ajout d'un horodatage de confiance.

Dans les scénarios modernes de signature de code, il est conseillé d'utiliser en priorité l'horodatage RFC 3161, par exemple :

http://timestamp.acs.microsoft.com

En environnement de production réel, il convient de choisir une TSA adaptée en fonction de la version de Windows cible, de la politique de certificat, de l’environnement réseau et des exigences du fournisseur de service d’horodatage.

Pour plus de détails sur les serveurs d’horodatage et les protocoles, veuillez consulter les documents de référence.

Consignes de sécurité

Lors de l’utilisation du fournisseur Windows, veuillez noter les points suivants :

  • L’Access Secret doit être protégé en tant qu’information d’identification sensible.
  • N’inscrivez pas les informations d’identification d’accès dans des scripts publics ou des journaux.
  • Le fichier de configuration du fournisseur ne doit pas être diffusé publiquement.
  • Le fichier de certificat local ne contient 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 initie une signature, il doit pouvoir accéder au service de signature de code distant.
  • Lors de l’utilisation du magasin de certificats LocalMachine, portez une attention particulière aux autorisations des utilisateurs Windows et à l’étendue d’accès aux informations d’identification.

Le config.dat de CSP est protégé à l’aide de DPAPI du profil de l’utilisateur Windows actuel ; l’enregistrement du certificat dans LocalMachine ne modifie pas automatiquement l’étendue de protection DPAPI de cette configuration.