PKI et signatures avec des clés protégées.

Le HSM protège une clé de signature dans la limite prévue ; il ne décide pas lui-même si un paquet logiciel doit être validé. Nous couplons donc les appels de signature à des applications identifiées, des autorisations et des validations. Lors de la signature de code, l'artefact et la validation sont liés entre eux, afin que toute modification ultérieure soit détectable. Le logiciel d'AC et le fournisseur cryptographique du HSM doivent prendre en charge conjointement l'algorithme utilisé et l'accès aux clés. Les trust stores, le contrôle de statut et le renouvellement sont testés avec des systèmes distants représentatifs.

Une carte d'administrateur perdue, des certificats expirés et une AC émettrice compromise sont des événements différents. Nous élaborons des procédures adaptées et testons le circuit de restauration convenu. La recette documente notamment l'émission, le renouvellement, la révocation et les demandes erronées. Les profils de certificats existants, les classes d'appareils et les relations de confiance aident à planifier une exploitation parallèle pendant la migration.

Nous vérifions la connexion prise en charge par le produit concerné, par exemple via un CNG Key Storage Provider, PKCS #11 ou un fournisseur Java. Un nom d'algorithme identique ne garantit pas à lui seul la compatibilité : les mécanismes, les attributs des clés, le padding et la version du fournisseur cryptographique doivent également correspondre. Pour les autorités de certification existantes, nous déterminons si un transfert de clé autorisé est possible ou si une nouvelle AC avec une phase de transition est nécessaire. La confiance des systèmes connectés est explicitement prise en compte lors du test.

Le pipeline ne devrait pas disposer en permanence d'une clé de production librement utilisable. Nous séparons le build et la validation de signature, rattachons les tâches à un système identifié et définissons quels artefacts peuvent être signés avec quelle clé. L'horodatage, la preuve du hachage de l'artefact et la journalisation sont prévus en fonction du format de signature. Le HSM constitue ici un composant de protection : le contrôle du code et la décision de publication restent des tâches du processus de développement et de validation.

Une organisation exploite déjà des certificats pour des appareils, des utilisateurs et des services internes. OTOKO® recense les profils de certificats, la distribution et les chaînes de confiance, puis met à l'essai la connexion HSM prévue, d'abord hors production. Nous planifions ensuite la bascule, y compris le renouvellement, les informations de révocation et les limites de repli. Avant le transfert, les systèmes distants concrets sont testés : un certificat émis n'est un succès que lorsque l'authentification, l'accès au service ou la vérification de signature fonctionnent dans le système prévu.