Distribution du certificat de signature de code - meilleures pratiques? [fermé]


-1

Distribution du certificat de signature de code - meilleures pratiques?

Remarque: je suis un débutant absolu en matière de signature de code et de certificats logiciels. J'ai essayé de chercher et de lire comment résoudre notre problème particulier, mais je n'ai rien trouvé qui ressemble à Internet.

Jusqu'à présent, la signature de code n'était pas un problème pour nous, car nous travaillons sur des systèmes embarqués, basés sur Windows, mais pour lesquels nous fournissons des solutions clé en main. Ensuite, notre antivirus (qui est obligatoire!) A détesté plusieurs de nos fichiers binaires (pour tous les projets), et il ne semble pas y avoir de véritable modèle dans ce qu’il n’aime pas. Après des semaines de discussions avec le fournisseur de l'antivirus, nous avons découvert que la solution à notre problème est que nos développeurs disposent d'un dossier exclu de l'analyse (utilisé pour la construction du logiciel) et que nous implémentons la signature de code tout en ayant notre certificat. sur la liste blanche dans l'application antivirus (utilisé pour la distribution interne limitée et les tests de nos logiciels).

Donc, pour le moment, nous allons utiliser la signature de code, pas pour la sécurité, mais simplement pour pouvoir faire notre travail. Le fournisseur d’antivirus nous a informés que les certificats auto-signés ne peuvent pas être inscrits sur la liste blanche, même si cela aurait eu un sens.

Nos développeurs sont répartis sur cinq sites à travers le monde et nous recherchons la solution la plus simple possible pour nous assurer qu'ils peuvent tous effectuer la signature de code (sinon, il ne leur sera pas possible de tester le code qu'ils ont généré).

Nous espérons qu'une sorte de distribution de certificats est possible, peut-être même en utilisant Active Directory?

Dans un avenir pas si lointain, nous devrons faire de la signature de code pour valider réellement la sécurité de notre logiciel. Par conséquent, si nous utilisons le certificat distribué, serait-il toujours "sûr" d'utiliser pour la validation? Je suppose que non - ce qui me fait me demander si nous pourrions avoir deux certificats et signer avec les deux? Un certificat serait alors distribué et nous permettrait de construire et de tester, puis un autre serait utilisé pour la publication.

Nous allons probablement utiliser un certificat Microsoft Authenticode - sauf s’il existe de bonnes raisons de ne pas le faire.

Toutefois, pour autant que je sache, Microsoft utilise depuis le 1er février 2017 un module de sécurité matérielle (HSM) dans le processus de signature de code. Nous espérons que cela ne signifie pas que chaque développeur doit avoir son propre HSM dans son ordinateur!

Donc, pour résumer mes questions:

  1. Pour la signature de code des fichiers binaires Windows, un certificat HSM est-il requis ou existe-t-il d'autres alternatives plus intéressantes (dans cette situation).
  2. Quelles sont les options pour distribuer un certificat entre développeurs? Utiliser AD serait bien, car il est déjà en place dans le monde entier.
  3. Dans une configuration distribuée, serait-il possible de garder le certificat de signature secret?
  4. La double signature serait-elle une option pour augmenter la sécurité? (Une signature pour battre l'antivirus lors des tests, une autre pour la sécurité réelle du logiciel fourni)
  5. Avez-vous une meilleure solution à envisager pour nous?

Merci d'avance.

Réponses:


1

Pour la signature de code des fichiers binaires Windows, un certificat HSM est-il requis ou existe-t-il d'autres alternatives plus intéressantes (dans cette situation).

Un module de sécurité matérielle (HSM) est simplement un outil matériel permettant d'effectuer des opérations cryptographiques telles que la gestion de clés, l'échange de clés, le cryptage, la vérification et la sécurité. Un certificat HSM n'existe pas, mais il existe des certificats générés par un HSM.

Je n'ai pas moi-même utilisé de HSM, mais je me méfierais des clés générées par un tel matériel. Ils peuvent convenir à un usage interne, mais pour un usage externe, vous devez utiliser des certificats créés par une autorité de certification reconnue.

Let's Encrypt est une autorité de certification gratuite largement utilisée. Dans mon entreprise, nous avons préféré payer pour une autorité de certification reconnue pour la distribution de nos logiciels.

Quelles sont les options pour distribuer un certificat entre développeurs? Utiliser AD serait bien, car il est déjà en place dans le monde entier.

Vous pouvez utiliser AD, mais cela peut être une surcharge pour seulement quelques programmeurs. Je ne l'utiliserais que pour le certificat de développement, tout en maintenant le certificat de publication très sécurisé, peut-être lui-même dans un conteneur crypté, et sous le contrôle intégral et non partagé d'une seule personne de confiance (et éventuellement d'une personne de sauvegarde).

Pour plus d'informations, voir:

Dans une configuration distribuée, serait-il possible de garder le certificat de signature secret?

Non, à partir du moment où un secret est partagé, ce n'est plus un secret. Gardez le certificat de distribution très sécurisé comme ci-dessus.

En cas de fuite, votre certificat sera répertorié dans la liste noire de tous les navigateurs et produits antivirus, de sorte que tous vos logiciels distribués deviendront inutilisables. Gardez-le en sécurité comme si votre vie en dépendait (au moins votre vie commerciale).

La double signature serait-elle une option pour augmenter la sécurité? (Une signature pour battre l'antivirus lors des tests, une autre pour la sécurité réelle du logiciel fourni)

Certainement, et je le verrais comme votre seule possibilité. Le certificat de développement risque de fuir, mais cela ne vous dérange pas, car les personnes qui le divulgueraient seraient également capables de faire fuir les modules non signés.

Avez-vous une meilleure solution à envisager pour nous?

On dirait que vous avez profondément réfléchi au sujet. Dans votre cas, j'aurais également opté pour une telle solution à double certificat.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.